In diesem Thread geht es um das Modul 76_SolarForecast.pm sowie angrenzende Themengebiete wie Verbrauchersteuerung, Batteriemanagent und Anlagensteuerung dieses integrativen Moduls.
Im FHEM Wiki gibt es einen begleitenden Artikel (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung).
LG,
Heiko
Zitat von: Skusi am 10 Februar 2024, 12:22:11Hallo,
nun brauch ich mal Eure Hilfe.
Ich benutze das Modul schon eine ganze weile und es leistet mir wirklich hervorragenden Dienste.
Nun habe ich über die zeit auch immer neues ausprobiert und war deswegen vor ein paar Wochen der Meinung malmit der ganzen Datenhistorie aufzuräumen um eine genauere Prognose als 50% hinzubekommen. Das war das einzige was mich immer noch gestört hatte, das es selten mit der tatsächlichen Einstrahlung überein war.
Ich habe also aiData, pvCorrection und pvHistory resettet.
Alle Daten die das Modul braucht habe ich seit ewig so gelassen. Ich dachte wenn ich lange genug warte, wird die Prognose immer genauer.
Heute Morgen sehe ich nun das: [url="https://forum.fhem.de/index.php?action=dlattach;attach=176248;type=preview;file"]Unbenannt.PNG[/url]
Und Abweichung gestern: -48,6 %
Was ist denn da schief gelaufen, und wo kann ich das wieder gerade biegen ?
Hat da mal jemand einen Tipp ?
Hab ich auch schon ein paar Mal gehabt, aber ohne AI. Ohne Plausibilisierung wäre gut, PV sollte nicht höher als WR Leistung plus x Prozent (Default: 10) sein.
Aktuell keine falschen Werte, trotzdem unten die DEF. Debug ist jetzt mal aktiviert.
Mein Problem: MTec liefert den Total Wert nur in der passendsten Einheit, das wird schnell zu MWh und damit zu ungenau für stündlich. Ich habe mir daher den Gesamtwert aus dem täglichen Wert berechnet, wieder unter Berücksichtigung der Einheit:
data_accumulatedData_totalEnergy_fromtoday:data_accumulatedData_todayEnergy.* monotonic {
my $val = ReadingsNum($NAME, "data_accumulatedData_todayEnergy", 0);
if (ReadingsVal($NAME, "data_accumulatedData_todayEnergyUnit", "?") eq "Wh") {$val = $val / 1000};
sprintf("%0.2f", $val) }
Dieser Wert läuft aber dem "richtigen" Total voraus:
data_accumulatedData_totalEnergy 3.08 (3080)
data_accumulatedData_totalEnergy_fromtoday 3122.20
Es ist vermutlich eine größere Umbauarbeit, aber könnte man mal als Option nicht auch den Tageswert nehmen, der um Mitternacht wieder auf 0 gesetzt wird?
Werte für den 10., Fehler zur Stunde 09:
10 => 01 => etotal: 4114500, pvfc: 0, pvrl: 0, rad1h: -
confc: 721, con: 670, gcon: 670, gfeedin: 0
batintotal: 1107000, batin: 0, batouttotal: 1016100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 151, wcc: 63, wrp: 23.00, temp: 6.40, pvcorrf: 1.00/-
csmt01: 158340, csme01: 0, minutescsm01: 0
csmt02: 571960, csme02: 0, minutescsm02: 10
csmt03: 229340, csme03: 40, minutescsm03: 0
08 => etotal: 3775200, pvfc: 3, pvrl: 0, rad1h: -
confc: 423, con: 325, gcon: 325, gfeedin: 0
batintotal: 1107000, batin: 0, batouttotal: 1016100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 45, wcc: 96, wrp: 3.00, temp: 5.5, pvcorrf: 0.58/0.13
csmt01: 158350, csme01: 0, minutescsm01: 0
csmt02: 571960, csme02: 0, minutescsm02: 24
csmt03: 229570, csme03: 30, minutescsm03: 0
09 => etotal: 3775200, pvfc: 19, pvrl: 339600, rad1h: -
confc: 477, con: 339900, gcon: 302, gfeedin: 2
batintotal: 1107000, batin: 0, batouttotal: 1016100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 45, wcc: 95, wrp: 1.00, temp: 6.10, pvcorrf: 0.11/0.64
csmt01: 158350, csme01: 0, minutescsm01: 0
csmt02: 571960, csme02: 0, minutescsm02: 30
csmt03: 229600, csme03: 30, minutescsm03: 0
24 => etotal: 4129100, pvfc: 0, pvrl: 0, rad1h: -
confc: 814, con: 793, gcon: 7, gfeedin: 14
batintotal: 1115900, batin: 0, batouttotal: 1022900, batout: 800
batmaxsoc: -, batsetsoc: -
wid: 103, wcc: 100, wrp: 4.00, temp: 6.10, pvcorrf: 1.00/-
csmt01: 158360, csme01: 0, minutescsm01: 0
csmt02: 573660, csme02: 40, minutescsm02: 29
csmt03: 230090, csme03: 30, minutescsm03: 18
99 => etotal: , pvfc: 12304, pvrl: 353898, rad1h: -
confc: 18335, con: 356879, gcon: 4600, gfeedin: 319
batintotal: , batin: 8900, batouttotal: , batout: 7600
batmaxsoc: 83.52, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: Sat
cyclescsm01: 0, csme01: 20.00
cyclescsm02: 24, csme02: 1660.00, hourscsme02: 11.12
cyclescsm03: 1, csme03: 780.00, hourscsme03: 11.02
define PVForecastDach SolarForecast
attr PVForecastDach comment help SolarForecast de\
Update: "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
RoofIdentPair <pk> rtid=<Rooftop-ID> apikey=<SolCast API Key>\
RoofIdentPair <pk> rtid=ddbb-79d4-b7fa-b06d apikey=CmodtrEpNyo2YRpUOrjLiOw_bvMZ25id
attr PVForecastDach consumer01 HUESensor_9.2_Power_WaMa auto=0 type=noSchedule icon=scene_laundry_room power=2000 mintime=165 pcurr=power:W on=on off=off switchdev=HUEDevice_2_OnOff_WaMa etotal=Consumption:W asynchron=1
attr PVForecastDach consumer02 HUESensor_21.4_Power_TK auto=0 type=noSchedule icon=freezer power=600 switchdev=HUEDevice_4_OnOff_TK mintime=20 pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecastDach consumer03 HUESensor_19.3_Power_PC auto=0 type=noSchedule icon=it_pc power=500 switchdev=HUEDevice_3_OnOff_PC pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecastDach consumerAdviceIcon none
attr PVForecastDach consumerLegend icon_bottom
attr PVForecastDach consumerLink 1
attr PVForecastDach ctrlDebug aiData,radiationProcess
attr PVForecastDach ctrlLanguage DE
attr PVForecastDach ctrlSolCastAPImaxReq 10
attr PVForecastDach ctrlSolCastAPIoptimizeReq 1
attr PVForecastDach ctrlStatisticReadings SunHours_Remain,SunMinutes_Remain,conForecastTillNextSunrise,dayAfterTomorrowPVforecast,response_message
attr PVForecastDach disable 0
attr PVForecastDach event-on-change-reading .*
attr PVForecastDach flowGraphicAnimate 1
attr PVForecastDach flowGraphicShowConsumerRemainTime 0
attr PVForecastDach graphicHeaderOwnspec Surplus:Current_Surplus\
TodayFc:Today_PVforecast TodayRl:Today_PVreal_kWh\
PV ;übermorgen:statistic_dayAfterTomorrowPVforecast
attr PVForecastDach graphicHistoryHour 8
attr PVForecastDach graphicShowDiff bottom
attr PVForecastDach group PV
attr PVForecastDach room PV
attr PVForecastDach userReadings Today_PVreal_kWh:Today_PVreal.* {sprintf("%0.1f kWh", ReadingsNum($NAME, "Today_PVreal", 0)/1000)}
# .FhemMetaInternals 1
# .triggerUsed 1
# FUUID 63f522f9-f33f-65cb-5211-0678b54f6bf22247
# FVERSION 76_SolarForecast.pm:v1.6.0-s28306/2023-12-22
# LCACHEFILE last write time: 13:47:09 File: ./FHEM/FhemUtils/PVH_SolarForecast_PVForecastDach
# MODE Automatic - next Cycletime: 13:48:39
# MODEL SolCastAPI
# NAME PVForecastDach
# NOTIFYDEV HUESensor_9.2_Power_WaMa,HUEDevice_2_OnOff_WaMa,HUESensor_21.4_Power_TK,HUEDevice_4_OnOff_TK,HUESensor_19.3_Power_PC,HUEDevice_3_OnOff_PC
# NR 1307
# NTFY_ORDER 50-PVForecastDach
# STATE updated
# TYPE SolarForecast
# eventCount 156126
# .attraggr:
# .attreocr:
# .*
# .attrminint:
# .userReadings:
# HASH(0x55615ebd1bd8)
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# SPGDETAIL
# SPGDEV PVForecastDach
# SPGROOM
# VERSION 1.6.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.1
# OLDREADINGS:
# READINGS:
# 2024-01-11 10:10:10 .associatedWith HUESensor_9.2_Power_WaMa HUEDevice_2_OnOff_WaMa HUESensor_21.4_Power_TK HUEDevice_4_OnOff_TK HUESensor_19.3_Power_PC HUEDevice_3_OnOff_PC DWD1_Ulm Strom_PV_All_Aktuell MQTT2_DVES_6296D2 Strom_Bat_Aktuell
# 2024-02-11 13:47:29 .lastupdateForecastValues 1707655649
# 2024-02-11 01:00:55 .pvCorrectionFactor_01_apipercentil done
# 2024-02-11 01:00:55 .pvCorrectionFactor_01_cloudcover done
# 2024-02-11 02:00:55 .pvCorrectionFactor_02_apipercentil done
# 2024-02-11 02:00:55 .pvCorrectionFactor_02_cloudcover done
# 2024-02-11 03:00:56 .pvCorrectionFactor_03_apipercentil done
# 2024-02-11 03:00:56 .pvCorrectionFactor_03_cloudcover done
# 2024-02-11 04:00:56 .pvCorrectionFactor_04_apipercentil done
# 2024-02-11 04:00:56 .pvCorrectionFactor_04_cloudcover done
# 2024-02-11 05:01:02 .pvCorrectionFactor_05_apipercentil done
# 2024-02-11 05:01:02 .pvCorrectionFactor_05_cloudcover done
# 2024-02-11 06:00:56 .pvCorrectionFactor_06_apipercentil done
# 2024-02-11 06:00:56 .pvCorrectionFactor_06_cloudcover done
# 2024-02-11 07:00:57 .pvCorrectionFactor_07_apipercentil done
# 2024-02-11 07:00:57 .pvCorrectionFactor_07_cloudcover done
# 2024-02-11 08:00:57 .pvCorrectionFactor_08_apipercentil done
# 2024-02-11 08:00:57 .pvCorrectionFactor_08_cloudcover done
# 2024-02-11 09:00:57 .pvCorrectionFactor_09_apipercentil done
# 2024-02-11 09:00:57 .pvCorrectionFactor_09_cloudcover done
# 2024-02-11 10:00:58 .pvCorrectionFactor_10_apipercentil done
# 2024-02-11 10:00:58 .pvCorrectionFactor_10_cloudcover done
# 2024-02-11 11:00:25 .pvCorrectionFactor_11_apipercentil done
# 2024-02-11 11:00:25 .pvCorrectionFactor_11_cloudcover done
# 2024-02-11 12:01:05 .pvCorrectionFactor_12_apipercentil done
# 2024-02-11 12:01:05 .pvCorrectionFactor_12_cloudcover done
# 2024-02-11 13:01:05 .pvCorrectionFactor_13_apipercentil done
# 2024-02-11 13:01:05 .pvCorrectionFactor_13_cloudcover done
# 2024-02-11 13:47:29 .pvCorrectionFactor_Auto_Soll on_simple
# 2024-02-11 01:00:55 .signaldone_01 done
# 2024-02-11 02:00:55 .signaldone_02 done
# 2024-02-11 03:00:56 .signaldone_03 done
# 2024-02-11 04:00:56 .signaldone_04 done
# 2024-02-11 05:01:02 .signaldone_05 done
# 2024-02-11 06:00:56 .signaldone_06 done
# 2024-02-11 07:00:57 .signaldone_07 done
# 2024-02-11 08:00:57 .signaldone_08 done
# 2024-02-11 09:00:57 .signaldone_09 done
# 2024-02-11 10:00:58 .signaldone_10 done
# 2024-02-11 11:00:25 .signaldone_11 done
# 2024-02-11 12:01:05 .signaldone_12 done
# 2024-02-11 13:01:05 .signaldone_13 done
# 2024-02-11 13:47:29 Current_AutarkyRate 100 %
# 2024-02-11 13:47:29 Current_BatCharge 40.25 %
# 2024-02-11 13:47:29 Current_Consumption 892 W
# 2024-02-11 13:47:29 Current_GridConsumption 0 W
# 2024-02-11 13:47:29 Current_GridFeedIn 8 W
# 2024-02-11 13:47:29 Current_PV 1740 W
# 2024-02-11 13:47:29 Current_PowerBatIn 840 W
# 2024-02-11 13:47:29 Current_PowerBatOut 0 W
# 2024-02-11 13:47:29 Current_SelfConsumption 892 W
# 2024-02-11 13:47:29 Current_SelfConsumptionRate 51 %
# 2024-02-11 13:47:29 Current_Surplus 848 W
# 2024-02-11 13:00:00 LastHourGridconsumptionReal 9 Wh
# 2024-02-11 13:00:00 LastHourPVforecast 1842 Wh
# 2024-02-11 13:00:00 LastHourPVreal 1600 Wh
# 2024-02-11 13:47:29 NextHours_Sum01_PVforecast 803 Wh
# 2024-02-11 13:47:29 NextHours_Sum02_PVforecast 1394 Wh
# 2024-02-11 13:47:29 NextHours_Sum03_PVforecast 1709 Wh
# 2024-02-11 13:47:29 NextHours_Sum04_ConsumptionForecast 3136 Wh
# 2024-02-11 13:47:29 NextHours_Sum04_PVforecast 1810 Wh
# 2024-02-11 13:47:29 RestOfDayConsumptionForecast 8748 Wh
# 2024-02-11 13:47:29 RestOfDayPVforecast 1822 Wh
# 2024-02-11 00:59:45 Today_Hour01_BatIn 0 Wh
# 2024-02-11 00:59:45 Today_Hour01_BatOut 700 Wh
# 2024-02-11 00:59:45 Today_Hour01_GridConsumption 5 Wh
# 2024-02-11 00:59:45 Today_Hour01_GridFeedIn 14 Wh
# 2024-02-11 00:59:45 Today_Hour01_PVreal 0 Wh
# 2024-02-11 01:59:45 Today_Hour02_BatIn 0 Wh
# 2024-02-11 01:59:45 Today_Hour02_BatOut 299 Wh
# 2024-02-11 01:59:45 Today_Hour02_GridConsumption 330 Wh
# 2024-02-11 01:59:45 Today_Hour02_GridFeedIn 7 Wh
# 2024-02-11 01:59:45 Today_Hour02_PVreal 0 Wh
# 2024-02-11 02:59:46 Today_Hour03_BatIn 0 Wh
# 2024-02-11 02:59:46 Today_Hour03_BatOut 0 Wh
# 2024-02-11 02:59:46 Today_Hour03_GridConsumption 561 Wh
# 2024-02-11 02:59:46 Today_Hour03_GridFeedIn 0 Wh
# 2024-02-11 02:59:46 Today_Hour03_PVreal 0 Wh
# 2024-02-11 03:59:46 Today_Hour04_BatIn 0 Wh
# 2024-02-11 03:59:46 Today_Hour04_BatOut 0 Wh
# 2024-02-11 03:59:46 Today_Hour04_GridConsumption 517 Wh
# 2024-02-11 03:59:46 Today_Hour04_GridFeedIn 0 Wh
# 2024-02-11 03:59:46 Today_Hour04_PVreal 0 Wh
# 2024-02-11 04:59:52 Today_Hour05_BatIn 0 Wh
# 2024-02-11 04:59:52 Today_Hour05_BatOut 0 Wh
# 2024-02-11 04:59:52 Today_Hour05_GridConsumption 309 Wh
# 2024-02-11 04:59:52 Today_Hour05_GridFeedIn 0 Wh
# 2024-02-11 04:59:52 Today_Hour05_PVreal 0 Wh
# 2024-02-11 05:59:46 Today_Hour06_BatIn 0 Wh
# 2024-02-11 05:59:46 Today_Hour06_BatOut 0 Wh
# 2024-02-11 05:59:46 Today_Hour06_GridConsumption 280 Wh
# 2024-02-11 05:59:46 Today_Hour06_GridFeedIn 0 Wh
# 2024-02-11 05:59:46 Today_Hour06_PVreal 0 Wh
# 2024-02-11 06:59:47 Today_Hour07_BatIn 0 Wh
# 2024-02-11 06:59:47 Today_Hour07_BatOut 0 Wh
# 2024-02-11 06:59:47 Today_Hour07_GridConsumption 362 Wh
# 2024-02-11 06:59:47 Today_Hour07_GridFeedIn 0 Wh
# 2024-02-11 06:59:47 Today_Hour07_PVreal 0 Wh
# 2024-02-11 07:59:47 Today_Hour08_BatIn 0 Wh
# 2024-02-11 07:59:47 Today_Hour08_BatOut 0 Wh
# 2024-02-11 07:59:47 Today_Hour08_GridConsumption 541 Wh
# 2024-02-11 07:59:47 Today_Hour08_GridFeedIn 0 Wh
# 2024-02-11 07:59:47 Today_Hour08_PVforecast 6 Wh
# 2024-02-11 07:59:47 Today_Hour08_PVreal 0 Wh
# 2024-02-11 08:59:47 Today_Hour09_BatIn 0 Wh
# 2024-02-11 08:59:47 Today_Hour09_BatOut 0 Wh
# 2024-02-11 08:59:47 Today_Hour09_GridConsumption 565 Wh
# 2024-02-11 08:59:47 Today_Hour09_GridFeedIn 0 Wh
# 2024-02-11 08:59:47 Today_Hour09_PVforecast 115 Wh
# 2024-02-11 08:59:47 Today_Hour09_PVreal 99 Wh
# 2024-02-11 09:59:48 Today_Hour10_BatIn 200 Wh
# 2024-02-11 09:59:48 Today_Hour10_BatOut 0 Wh
# 2024-02-11 09:59:48 Today_Hour10_GridConsumption 43 Wh
# 2024-02-11 09:59:48 Today_Hour10_GridFeedIn 8 Wh
# 2024-02-11 09:59:48 Today_Hour10_PVforecast 774 Wh
# 2024-02-11 09:59:48 Today_Hour10_PVreal 500 Wh
# 2024-02-11 10:59:26 Today_Hour11_BatIn 600 Wh
# 2024-02-11 10:59:26 Today_Hour11_BatOut 0 Wh
# 2024-02-11 10:59:26 Today_Hour11_GridConsumption 7 Wh
# 2024-02-11 10:59:26 Today_Hour11_GridFeedIn 15 Wh
# 2024-02-11 10:59:26 Today_Hour11_PVforecast 949 Wh
# 2024-02-11 10:59:26 Today_Hour11_PVreal 1199 Wh
# 2024-02-11 11:59:55 Today_Hour12_BatIn 1500 Wh
# 2024-02-11 11:59:55 Today_Hour12_BatOut 0 Wh
# 2024-02-11 11:59:55 Today_Hour12_GridConsumption 21 Wh
# 2024-02-11 11:59:55 Today_Hour12_GridFeedIn 36 Wh
# 2024-02-11 11:59:55 Today_Hour12_PVforecast 1929 Wh
# 2024-02-11 11:59:55 Today_Hour12_PVreal 2300 Wh
# 2024-02-11 12:59:55 Today_Hour13_BatIn 900 Wh
# 2024-02-11 12:59:55 Today_Hour13_BatOut 0 Wh
# 2024-02-11 12:59:55 Today_Hour13_GridConsumption 9 Wh
# 2024-02-11 12:59:55 Today_Hour13_GridFeedIn 17 Wh
# 2024-02-11 12:59:55 Today_Hour13_PVforecast 1842 Wh
# 2024-02-11 12:59:55 Today_Hour13_PVreal 1600 Wh
# 2024-02-11 13:47:29 Today_Hour14_BatIn 400 Wh
# 2024-02-11 13:47:29 Today_Hour14_BatOut 0 Wh
# 2024-02-11 13:47:29 Today_Hour14_GridConsumption 10 Wh
# 2024-02-11 13:47:29 Today_Hour14_GridFeedIn 15 Wh
# 2024-02-11 13:47:29 Today_Hour14_PVforecast 1479 Wh
# 2024-02-11 13:47:29 Today_Hour14_PVreal 1300 Wh
# 2024-02-11 13:47:29 Today_Hour15_PVforecast 634 Wh
# 2024-02-11 13:47:29 Today_Hour16_PVforecast 581 Wh
# 2024-02-11 13:47:29 Today_Hour17_PVforecast 248 Wh
# 2024-02-11 13:47:29 Today_Hour18_PVforecast 64 Wh
# 2024-02-11 13:47:29 Today_MaxPVforecast 1929 Wh
# 2024-02-11 13:47:29 Today_MaxPVforecastTime 2024-02-11 11:00:00
# 2024-02-11 13:47:29 Today_PVforecast 8621 Wh
# 2024-02-11 13:38:08 Today_PVreal 6698 Wh
# 2024-02-11 13:38:08 Today_PVreal_kWh 6.7 kWh
# 2024-02-11 13:47:29 Today_SunRise 07:34
# 2024-02-11 13:47:29 Today_SunSet 17:35
# 2024-02-11 13:47:29 Tomorrow_ConsumptionForecast 27585 Wh
# 2024-02-11 13:47:29 Tomorrow_PVforecast 13244 Wh
# 2024-02-11 13:47:29 Tomorrow_SunRise 07:32
# 2024-02-11 13:47:29 Tomorrow_SunSet 17:36
# 2023-10-09 13:54:01 associatedWith SolCastDummy
# 2024-02-11 13:47:29 consumer01 name='WaMa Power 2-9' state='on' planningstate='noSchedule'
# 2024-02-11 13:47:29 consumer01_currentPower 0 W
# 2024-02-11 13:47:29 consumer02 name='TK Power 4-21' state='unknown' planningstate='noSchedule'
# 2024-02-11 13:47:29 consumer02_currentPower 73 W
# 2024-02-11 13:47:29 consumer03 name='PC Power 3-19' state='on' planningstate='noSchedule'
# 2024-02-11 13:47:29 consumer03_currentPower 129 W
# 2023-10-27 10:27:24 currentBatteryDev Strom_Bat_Aktuell pout=Leistung:kW pin=-pout charge=Ladung intotal=Charge_Total:kWh outtotal=DisCharge_Total:kWh
# 2024-01-10 11:23:23 currentInverterDev Strom_PV_All_Aktuell pv=PVALL:kW etotal=All_Total:kWh capacity=10600
# 2023-02-21 21:16:11 currentMeterDev MQTT2_DVES_6296D2 gcon=SML_Watt_Summe:W contotal=SML_Verbrauch_Summe:kWh gfeedin=-gcon feedtotal=SML_Einspeisung_Summe:kWh
# 2023-10-09 13:50:02 currentRadiationAPI SolCast-API
# 2023-09-23 13:46:13 currentWeatherDev DWD1_Ulm
# 2023-10-20 14:50:53 inverterStrings Dach,BKW
# 2023-04-08 18:12:20 moduleDirection Dach=S
# 2023-10-20 14:50:40 modulePeakString Dach=9.6 BKW=0.6
# 2023-10-20 15:01:46 moduleRoofTops Dach=Dach BKW=BKW
# 2023-04-08 18:12:50 moduleTiltAngle Dach=30
# 2024-02-11 13:47:29 nextCycletime 13:48:39
# 2024-02-11 13:13:31 nextSolCastCall nach 11.02.2024 14:18:52
# 2024-02-11 09:00:57 pvCorrectionFactor_09 1.11 (automatic - old factor: 0.61, average days: 31)
# 2024-02-11 09:00:57 pvCorrectionFactor_09_autocalc done
# 2024-02-11 10:00:58 pvCorrectionFactor_10 1.04 (automatic - old factor: 1.04, average days: 31)
# 2024-02-11 10:00:58 pvCorrectionFactor_10_autocalc done
# 2024-02-11 11:00:25 pvCorrectionFactor_11 1.04 (automatic - old factor: 0.97, average days: 31)
# 2024-02-11 11:00:25 pvCorrectionFactor_11_autocalc done
# 2024-02-11 12:01:05 pvCorrectionFactor_12 0.97 (automatic - old factor: 0.98, average days: 31)
# 2024-02-11 12:01:05 pvCorrectionFactor_12_autocalc done
# 2024-02-11 13:01:05 pvCorrectionFactor_13 1.00 (automatic - old factor: 1.00, average days: 31)
# 2024-02-11 13:01:05 pvCorrectionFactor_13_autocalc done
# 2024-02-11 13:47:29 pvCorrectionFactor_Auto on_simple
# 2024-02-11 13:47:29 state updated
# 2024-02-11 13:47:29 statistic_SunHours_Remain 3.79
# 2024-02-11 13:47:29 statistic_SunMinutes_Remain 228
# 2024-02-11 13:47:29 statistic_conForecastTillNextSunrise 12758 Wh
# 2024-02-11 13:47:29 statistic_dayAfterTomorrowPVforecast 27662 Wh
# 2024-02-11 13:47:29 statistic_response_message success
#
setstate PVForecastDach updated
setstate PVForecastDach 2024-01-11 10:10:10 .associatedWith HUESensor_9.2_Power_WaMa HUEDevice_2_OnOff_WaMa HUESensor_21.4_Power_TK HUEDevice_4_OnOff_TK HUESensor_19.3_Power_PC HUEDevice_3_OnOff_PC DWD1_Ulm Strom_PV_All_Aktuell MQTT2_DVES_6296D2 Strom_Bat_Aktuell
setstate PVForecastDach 2024-02-11 13:47:29 .lastupdateForecastValues 1707655649
setstate PVForecastDach 2024-02-11 01:00:55 .pvCorrectionFactor_01_apipercentil done
setstate PVForecastDach 2024-02-11 01:00:55 .pvCorrectionFactor_01_cloudcover done
setstate PVForecastDach 2024-02-11 02:00:55 .pvCorrectionFactor_02_apipercentil done
setstate PVForecastDach 2024-02-11 02:00:55 .pvCorrectionFactor_02_cloudcover done
setstate PVForecastDach 2024-02-11 03:00:56 .pvCorrectionFactor_03_apipercentil done
setstate PVForecastDach 2024-02-11 03:00:56 .pvCorrectionFactor_03_cloudcover done
setstate PVForecastDach 2024-02-11 04:00:56 .pvCorrectionFactor_04_apipercentil done
setstate PVForecastDach 2024-02-11 04:00:56 .pvCorrectionFactor_04_cloudcover done
setstate PVForecastDach 2024-02-11 05:01:02 .pvCorrectionFactor_05_apipercentil done
setstate PVForecastDach 2024-02-11 05:01:02 .pvCorrectionFactor_05_cloudcover done
setstate PVForecastDach 2024-02-11 06:00:56 .pvCorrectionFactor_06_apipercentil done
setstate PVForecastDach 2024-02-11 06:00:56 .pvCorrectionFactor_06_cloudcover done
setstate PVForecastDach 2024-02-11 07:00:57 .pvCorrectionFactor_07_apipercentil done
setstate PVForecastDach 2024-02-11 07:00:57 .pvCorrectionFactor_07_cloudcover done
setstate PVForecastDach 2024-02-11 08:00:57 .pvCorrectionFactor_08_apipercentil done
setstate PVForecastDach 2024-02-11 08:00:57 .pvCorrectionFactor_08_cloudcover done
setstate PVForecastDach 2024-02-11 09:00:57 .pvCorrectionFactor_09_apipercentil done
setstate PVForecastDach 2024-02-11 09:00:57 .pvCorrectionFactor_09_cloudcover done
setstate PVForecastDach 2024-02-11 10:00:58 .pvCorrectionFactor_10_apipercentil done
setstate PVForecastDach 2024-02-11 10:00:58 .pvCorrectionFactor_10_cloudcover done
setstate PVForecastDach 2024-02-11 11:00:25 .pvCorrectionFactor_11_apipercentil done
setstate PVForecastDach 2024-02-11 11:00:25 .pvCorrectionFactor_11_cloudcover done
setstate PVForecastDach 2024-02-11 12:01:05 .pvCorrectionFactor_12_apipercentil done
setstate PVForecastDach 2024-02-11 12:01:05 .pvCorrectionFactor_12_cloudcover done
setstate PVForecastDach 2024-02-11 13:01:05 .pvCorrectionFactor_13_apipercentil done
setstate PVForecastDach 2024-02-11 13:01:05 .pvCorrectionFactor_13_cloudcover done
setstate PVForecastDach 2024-02-11 13:47:29 .pvCorrectionFactor_Auto_Soll on_simple
setstate PVForecastDach 2024-02-11 01:00:55 .signaldone_01 done
setstate PVForecastDach 2024-02-11 02:00:55 .signaldone_02 done
setstate PVForecastDach 2024-02-11 03:00:56 .signaldone_03 done
setstate PVForecastDach 2024-02-11 04:00:56 .signaldone_04 done
setstate PVForecastDach 2024-02-11 05:01:02 .signaldone_05 done
setstate PVForecastDach 2024-02-11 06:00:56 .signaldone_06 done
setstate PVForecastDach 2024-02-11 07:00:57 .signaldone_07 done
setstate PVForecastDach 2024-02-11 08:00:57 .signaldone_08 done
setstate PVForecastDach 2024-02-11 09:00:57 .signaldone_09 done
setstate PVForecastDach 2024-02-11 10:00:58 .signaldone_10 done
setstate PVForecastDach 2024-02-11 11:00:25 .signaldone_11 done
setstate PVForecastDach 2024-02-11 12:01:05 .signaldone_12 done
setstate PVForecastDach 2024-02-11 13:01:05 .signaldone_13 done
setstate PVForecastDach 2024-02-11 13:47:29 Current_AutarkyRate 100 %
setstate PVForecastDach 2024-02-11 13:47:29 Current_BatCharge 40.25 %
setstate PVForecastDach 2024-02-11 13:47:29 Current_Consumption 892 W
setstate PVForecastDach 2024-02-11 13:47:29 Current_GridConsumption 0 W
setstate PVForecastDach 2024-02-11 13:47:29 Current_GridFeedIn 8 W
setstate PVForecastDach 2024-02-11 13:47:29 Current_PV 1740 W
setstate PVForecastDach 2024-02-11 13:47:29 Current_PowerBatIn 840 W
setstate PVForecastDach 2024-02-11 13:47:29 Current_PowerBatOut 0 W
setstate PVForecastDach 2024-02-11 13:47:29 Current_SelfConsumption 892 W
setstate PVForecastDach 2024-02-11 13:47:29 Current_SelfConsumptionRate 51 %
setstate PVForecastDach 2024-02-11 13:47:29 Current_Surplus 848 W
setstate PVForecastDach 2024-02-11 13:00:00 LastHourGridconsumptionReal 9 Wh
setstate PVForecastDach 2024-02-11 13:00:00 LastHourPVforecast 1842 Wh
setstate PVForecastDach 2024-02-11 13:00:00 LastHourPVreal 1600 Wh
setstate PVForecastDach 2024-02-11 13:47:29 NextHours_Sum01_PVforecast 803 Wh
setstate PVForecastDach 2024-02-11 13:47:29 NextHours_Sum02_PVforecast 1394 Wh
setstate PVForecastDach 2024-02-11 13:47:29 NextHours_Sum03_PVforecast 1709 Wh
setstate PVForecastDach 2024-02-11 13:47:29 NextHours_Sum04_ConsumptionForecast 3136 Wh
setstate PVForecastDach 2024-02-11 13:47:29 NextHours_Sum04_PVforecast 1810 Wh
setstate PVForecastDach 2024-02-11 13:47:29 RestOfDayConsumptionForecast 8748 Wh
setstate PVForecastDach 2024-02-11 13:47:29 RestOfDayPVforecast 1822 Wh
setstate PVForecastDach 2024-02-11 00:59:45 Today_Hour01_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 00:59:45 Today_Hour01_BatOut 700 Wh
setstate PVForecastDach 2024-02-11 00:59:45 Today_Hour01_GridConsumption 5 Wh
setstate PVForecastDach 2024-02-11 00:59:45 Today_Hour01_GridFeedIn 14 Wh
setstate PVForecastDach 2024-02-11 00:59:45 Today_Hour01_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 01:59:45 Today_Hour02_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 01:59:45 Today_Hour02_BatOut 299 Wh
setstate PVForecastDach 2024-02-11 01:59:45 Today_Hour02_GridConsumption 330 Wh
setstate PVForecastDach 2024-02-11 01:59:45 Today_Hour02_GridFeedIn 7 Wh
setstate PVForecastDach 2024-02-11 01:59:45 Today_Hour02_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 02:59:46 Today_Hour03_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 02:59:46 Today_Hour03_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 02:59:46 Today_Hour03_GridConsumption 561 Wh
setstate PVForecastDach 2024-02-11 02:59:46 Today_Hour03_GridFeedIn 0 Wh
setstate PVForecastDach 2024-02-11 02:59:46 Today_Hour03_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 03:59:46 Today_Hour04_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 03:59:46 Today_Hour04_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 03:59:46 Today_Hour04_GridConsumption 517 Wh
setstate PVForecastDach 2024-02-11 03:59:46 Today_Hour04_GridFeedIn 0 Wh
setstate PVForecastDach 2024-02-11 03:59:46 Today_Hour04_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 04:59:52 Today_Hour05_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 04:59:52 Today_Hour05_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 04:59:52 Today_Hour05_GridConsumption 309 Wh
setstate PVForecastDach 2024-02-11 04:59:52 Today_Hour05_GridFeedIn 0 Wh
setstate PVForecastDach 2024-02-11 04:59:52 Today_Hour05_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 05:59:46 Today_Hour06_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 05:59:46 Today_Hour06_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 05:59:46 Today_Hour06_GridConsumption 280 Wh
setstate PVForecastDach 2024-02-11 05:59:46 Today_Hour06_GridFeedIn 0 Wh
setstate PVForecastDach 2024-02-11 05:59:46 Today_Hour06_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 06:59:47 Today_Hour07_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 06:59:47 Today_Hour07_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 06:59:47 Today_Hour07_GridConsumption 362 Wh
setstate PVForecastDach 2024-02-11 06:59:47 Today_Hour07_GridFeedIn 0 Wh
setstate PVForecastDach 2024-02-11 06:59:47 Today_Hour07_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 07:59:47 Today_Hour08_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 07:59:47 Today_Hour08_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 07:59:47 Today_Hour08_GridConsumption 541 Wh
setstate PVForecastDach 2024-02-11 07:59:47 Today_Hour08_GridFeedIn 0 Wh
setstate PVForecastDach 2024-02-11 07:59:47 Today_Hour08_PVforecast 6 Wh
setstate PVForecastDach 2024-02-11 07:59:47 Today_Hour08_PVreal 0 Wh
setstate PVForecastDach 2024-02-11 08:59:47 Today_Hour09_BatIn 0 Wh
setstate PVForecastDach 2024-02-11 08:59:47 Today_Hour09_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 08:59:47 Today_Hour09_GridConsumption 565 Wh
setstate PVForecastDach 2024-02-11 08:59:47 Today_Hour09_GridFeedIn 0 Wh
setstate PVForecastDach 2024-02-11 08:59:47 Today_Hour09_PVforecast 115 Wh
setstate PVForecastDach 2024-02-11 08:59:47 Today_Hour09_PVreal 99 Wh
setstate PVForecastDach 2024-02-11 09:59:48 Today_Hour10_BatIn 200 Wh
setstate PVForecastDach 2024-02-11 09:59:48 Today_Hour10_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 09:59:48 Today_Hour10_GridConsumption 43 Wh
setstate PVForecastDach 2024-02-11 09:59:48 Today_Hour10_GridFeedIn 8 Wh
setstate PVForecastDach 2024-02-11 09:59:48 Today_Hour10_PVforecast 774 Wh
setstate PVForecastDach 2024-02-11 09:59:48 Today_Hour10_PVreal 500 Wh
setstate PVForecastDach 2024-02-11 10:59:26 Today_Hour11_BatIn 600 Wh
setstate PVForecastDach 2024-02-11 10:59:26 Today_Hour11_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 10:59:26 Today_Hour11_GridConsumption 7 Wh
setstate PVForecastDach 2024-02-11 10:59:26 Today_Hour11_GridFeedIn 15 Wh
setstate PVForecastDach 2024-02-11 10:59:26 Today_Hour11_PVforecast 949 Wh
setstate PVForecastDach 2024-02-11 10:59:26 Today_Hour11_PVreal 1199 Wh
setstate PVForecastDach 2024-02-11 11:59:55 Today_Hour12_BatIn 1500 Wh
setstate PVForecastDach 2024-02-11 11:59:55 Today_Hour12_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 11:59:55 Today_Hour12_GridConsumption 21 Wh
setstate PVForecastDach 2024-02-11 11:59:55 Today_Hour12_GridFeedIn 36 Wh
setstate PVForecastDach 2024-02-11 11:59:55 Today_Hour12_PVforecast 1929 Wh
setstate PVForecastDach 2024-02-11 11:59:55 Today_Hour12_PVreal 2300 Wh
setstate PVForecastDach 2024-02-11 12:59:55 Today_Hour13_BatIn 900 Wh
setstate PVForecastDach 2024-02-11 12:59:55 Today_Hour13_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 12:59:55 Today_Hour13_GridConsumption 9 Wh
setstate PVForecastDach 2024-02-11 12:59:55 Today_Hour13_GridFeedIn 17 Wh
setstate PVForecastDach 2024-02-11 12:59:55 Today_Hour13_PVforecast 1842 Wh
setstate PVForecastDach 2024-02-11 12:59:55 Today_Hour13_PVreal 1600 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour14_BatIn 400 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour14_BatOut 0 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour14_GridConsumption 10 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour14_GridFeedIn 15 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour14_PVforecast 1479 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour14_PVreal 1300 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour15_PVforecast 634 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour16_PVforecast 581 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour17_PVforecast 248 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_Hour18_PVforecast 64 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_MaxPVforecast 1929 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Today_MaxPVforecastTime 2024-02-11 11:00:00
setstate PVForecastDach 2024-02-11 13:47:29 Today_PVforecast 8621 Wh
setstate PVForecastDach 2024-02-11 13:38:08 Today_PVreal 6698 Wh
setstate PVForecastDach 2024-02-11 13:38:08 Today_PVreal_kWh 6.7 kWh
setstate PVForecastDach 2024-02-11 13:47:29 Today_SunRise 07:34
setstate PVForecastDach 2024-02-11 13:47:29 Today_SunSet 17:35
setstate PVForecastDach 2024-02-11 13:47:29 Tomorrow_ConsumptionForecast 27585 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Tomorrow_PVforecast 13244 Wh
setstate PVForecastDach 2024-02-11 13:47:29 Tomorrow_SunRise 07:32
setstate PVForecastDach 2024-02-11 13:47:29 Tomorrow_SunSet 17:36
setstate PVForecastDach 2023-10-09 13:54:01 associatedWith SolCastDummy
setstate PVForecastDach 2024-02-11 13:47:29 consumer01 name='WaMa Power 2-9' state='on' planningstate='noSchedule'
setstate PVForecastDach 2024-02-11 13:47:29 consumer01_currentPower 0 W
setstate PVForecastDach 2024-02-11 13:47:29 consumer02 name='TK Power 4-21' state='unknown' planningstate='noSchedule'
setstate PVForecastDach 2024-02-11 13:47:29 consumer02_currentPower 73 W
setstate PVForecastDach 2024-02-11 13:47:29 consumer03 name='PC Power 3-19' state='on' planningstate='noSchedule'
setstate PVForecastDach 2024-02-11 13:47:29 consumer03_currentPower 129 W
setstate PVForecastDach 2023-10-27 10:27:24 currentBatteryDev Strom_Bat_Aktuell pout=Leistung:kW pin=-pout charge=Ladung intotal=Charge_Total:kWh outtotal=DisCharge_Total:kWh
setstate PVForecastDach 2024-01-10 11:23:23 currentInverterDev Strom_PV_All_Aktuell pv=PVALL:kW etotal=All_Total:kWh capacity=10600
setstate PVForecastDach 2023-02-21 21:16:11 currentMeterDev MQTT2_DVES_6296D2 gcon=SML_Watt_Summe:W contotal=SML_Verbrauch_Summe:kWh gfeedin=-gcon feedtotal=SML_Einspeisung_Summe:kWh
setstate PVForecastDach 2023-10-09 13:50:02 currentRadiationAPI SolCast-API
setstate PVForecastDach 2023-09-23 13:46:13 currentWeatherDev DWD1_Ulm
setstate PVForecastDach 2023-10-20 14:50:53 inverterStrings Dach,BKW
setstate PVForecastDach 2023-04-08 18:12:20 moduleDirection Dach=S
setstate PVForecastDach 2023-10-20 14:50:40 modulePeakString Dach=9.6 BKW=0.6
setstate PVForecastDach 2023-10-20 15:01:46 moduleRoofTops Dach=Dach BKW=BKW
setstate PVForecastDach 2023-04-08 18:12:50 moduleTiltAngle Dach=30
setstate PVForecastDach 2024-02-11 13:47:29 nextCycletime 13:48:39
setstate PVForecastDach 2024-02-11 13:13:31 nextSolCastCall nach 11.02.2024 14:18:52
setstate PVForecastDach 2024-02-11 09:00:57 pvCorrectionFactor_09 1.11 (automatic - old factor: 0.61, average days: 31)
setstate PVForecastDach 2024-02-11 09:00:57 pvCorrectionFactor_09_autocalc done
setstate PVForecastDach 2024-02-11 10:00:58 pvCorrectionFactor_10 1.04 (automatic - old factor: 1.04, average days: 31)
setstate PVForecastDach 2024-02-11 10:00:58 pvCorrectionFactor_10_autocalc done
setstate PVForecastDach 2024-02-11 11:00:25 pvCorrectionFactor_11 1.04 (automatic - old factor: 0.97, average days: 31)
setstate PVForecastDach 2024-02-11 11:00:25 pvCorrectionFactor_11_autocalc done
setstate PVForecastDach 2024-02-11 12:01:05 pvCorrectionFactor_12 0.97 (automatic - old factor: 0.98, average days: 31)
setstate PVForecastDach 2024-02-11 12:01:05 pvCorrectionFactor_12_autocalc done
setstate PVForecastDach 2024-02-11 13:01:05 pvCorrectionFactor_13 1.00 (automatic - old factor: 1.00, average days: 31)
setstate PVForecastDach 2024-02-11 13:01:05 pvCorrectionFactor_13_autocalc done
setstate PVForecastDach 2024-02-11 13:47:29 pvCorrectionFactor_Auto on_simple
setstate PVForecastDach 2024-02-11 13:47:29 state updated
setstate PVForecastDach 2024-02-11 13:47:29 statistic_SunHours_Remain 3.79
setstate PVForecastDach 2024-02-11 13:47:29 statistic_SunMinutes_Remain 228
setstate PVForecastDach 2024-02-11 13:47:29 statistic_conForecastTillNextSunrise 12758 Wh
setstate PVForecastDach 2024-02-11 13:47:29 statistic_dayAfterTomorrowPVforecast 27662 Wh
setstate PVForecastDach 2024-02-11 13:47:29 statistic_response_message success
[/code]
Hi,
kann es sein, daß im DropDown zu get pvHistory der Tag 8 doppelt ist?
DropDown zu get pvHistory.png
ZitatDer Entscheidungsvorgang in der KI ist für uns als User nicht transparent.
Das liegt aber nur an dem speziellen Verfahren - das ist eben kein regelbasiertes System, sondern ein RandomForest. Eine gute Erklärung findet man hier: https://www.ibm.com/de-de/topics/random-forest
Aus meinen eigenen Forschungsprojekten weiß ich, dass man das sinnvoll mit einem regelbasierten Anteil koppeln kann.
LG
pah
Ja KI ist ein weites Feld. Ich wollte mir auch mal die Perl Bibliothek Algorithm::DecisionTree (https://metacpan.org/pod/Algorithm::DecisionTree) anschauen, bin aber immer noch nicht dazu gekommen. Der Tag könnte 36 Stunden haben...
@minierm,
Zitatkann es sein, daß im DropDown zu get pvHistory der Tag 8 doppelt ist?
Das würde bedeuten der Schlüssel 08 ist doppelt im Hash. Kann eigentlich nicht sein und bei mir auch nicht so.
Wie sieht denn der komplette Output von:
get ... pvHistory
aus?
ZitatEs ist vermutlich eine größere Umbauarbeit, aber könnte man mal als Option nicht auch den Tageswert nehmen, der um Mitternacht wieder auf 0 gesetzt wird?
Das ist schlecht möglich. Die gesamte Architektur basiert auf Stundenscheiben. Zum Beispiel die Prognose. Könnte ich nur einen Tageswert der WR-Erzeugung nutzen und durch X teilen um auf einen Stundenwert zu kommen, hätte ich nur eine Gleichverteilung über den Tag. Das wäre Unsinn und wäre auch keine Basis für Prognose/Ist-Vergleiche. Man könnte dann zwar eine Tagesprognose abgeben und mit dem Ergebnis vergleichen. Aber das ist ja nicht das Ziel.
ZitatOhne Plausibilisierung wäre gut, PV sollte nicht höher als WR Leistung plus x Prozent (Default: 10) sein.
Die Plausibilisierung/Begrenzung gibt es schon seit einiger Zeit. Dazu muss man nur den Schlüssel "capacity" in currentInverterDev setzen was bei dir aber der Fall ist.
Wie angekündigt wird morgen früh ein Update ausgerollt. Neben dem Astro-Load Bugfix (Meldung von caldir65) sind noch zwei kleine Changes enthalten:
- im Header gibt es neben dem PlantCheck-Icon ein Icon zum Absprung in diesen Thread
- das Qualitätspopup ist etwas umgebaut. Man sieht hier nun auch für welche zukünftigen Stunden die KI-Prognose einen Hit geliefert hat der validiert wurde und verwendet wird.
LG
Moin,
mit der neuesten Version von heute Morgen erhalte ich folgende Warnings im Log:
2024.02.12 09:52:42.325 1: PERL WARNING: Use of uninitialized value $newBatteryPercentageState in numeric ge (>=) at ./FHEM/70_SolarEdgeAPI.pm line 1276.
2024.02.12 09:52:42.326 1: PERL WARNING: Use of uninitialized value $newBatteryPercentageState in numeric le (<=) at ./FHEM/70_SolarEdgeAPI.pm line 1276.
2024.02.12 09:52:42.326 1: PERL WARNING: Use of uninitialized value $newBatteryPercentageState in concatenation (.) or string at ./FHEM/70_SolarEdgeAPI.pm line 1279.
2024.02.12 09:52:42.326 1: PERL WARNING: Use of uninitialized value $batteryPercentageState in concatenation (.) or string at ./FHEM/70_SolarEdgeAPI.pm line 1280.
70_SolarEdgeAPI.pm ist aber nicht dieses Modul.
Andere Baustelle.
Sorry :-X man sollte schon genau hinsehen ;D
Zitat von: DS_Starter am 11 Februar 2024, 17:59:39ZitatEs ist vermutlich eine größere Umbauarbeit, aber könnte man mal als Option nicht auch den Tageswert nehmen, der um Mitternacht wieder auf 0 gesetzt wird?
Das ist schlecht möglich. Die gesamte Architektur basiert auf Stundenscheiben. Zum Beispiel die Prognose. Könnte ich nur einen Tageswert der WR-Erzeugung nutzen und durch X teilen um auf einen Stundenwert zu kommen, hätte ich nur eine Gleichverteilung über den Tag. Das wäre Unsinn und wäre auch keine Basis für Prognose/Ist-Vergleiche. Man könnte dann zwar eine Tagesprognose abgeben und mit dem Ergebnis vergleichen. Aber das ist ja nicht das Ziel.
Ich meinte nur für die aktuelle Ertragsleistung im Tagesverlauf.
Zitat von: DS_Starter am 11 Februar 2024, 17:59:39Zitat[Eine]Ohne Plausibilisierung wäre gut, PV sollte nicht höher als WR Leistung plus x Prozent (Default: 10) sein.
Die Plausibilisierung/Begrenzung gibt es schon seit einiger Zeit. Dazu muss man nur den Schlüssel "capacity" in currentInverterDev setzen was bei dir aber der Fall ist.
Und warum wird dann PV Real so exorbitant hoch angezeigt? Vermutlich war es bei mir ein Problem mit zu vielen Dezimalstellen, die irgendwann mal reingerutscht sind und dadurch zu Fehlberechnungen geführt haben.
Zitat von: DS_Starter am 11 Februar 2024, 17:59:39Zitatkann es sein, daß im DropDown zu get pvHistory der Tag 8 doppelt ist?
Das würde bedeuten der Schlüssel 08 ist doppelt im Hash. Kann eigentlich nicht sein und bei mir auch nicht so.
Wie sieht denn der komplette Output von:
Code Auswählen Erweitern
get ... pvHistoryaus?
Relevanter Auszug, ja, ein Problem mit 8 => 99:
07 => 01 => etotal: 4081900, pvfc: 0, pvrl: 0, rad1h: -
confc: 702, con: 590, gcon: 6, gfeedin: 16
batintotal: 1090500, batin: 0, batouttotal: 996500, batout: 600
batmaxsoc: -, batsetsoc: -
wid: 102, wcc: 58, wrp: 0.00, temp: 3.5, pvcorrf: 1.00/-
csmt01: 158260, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 28
csmt03: 227090, csme03: 30, minutescsm03: 0
02 => etotal: 4081900, pvfc: 0, pvrl: 0, rad1h: -
confc: 590, con: 592, gcon: 6, gfeedin: 14
batintotal: 1090500, batin: 0, batouttotal: 997100, batout: 600
batmaxsoc: -, batsetsoc: -
wid: 102, wcc: 58, wrp: 1.00, temp: 3.60, pvcorrf: 1.00/-
csmt01: 158260, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 27
csmt03: 227120, csme03: 30, minutescsm03: 0
03 => etotal: 4081900, pvfc: 0, pvrl: 0, rad1h: -
confc: 521, con: 592, gcon: 9, gfeedin: 17
batintotal: 1090500, batin: 0, batouttotal: 997700, batout: 600
batmaxsoc: -, batsetsoc: -
wid: 102, wcc: 60, wrp: 1.00, temp: 3.90, pvcorrf: 1.00/-
csmt01: 158260, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 30
csmt03: 227150, csme03: 30, minutescsm03: 0
04 => etotal: 4081900, pvfc: 0, pvrl: 0, rad1h: -
confc: 396, con: 493, gcon: 6, gfeedin: 13
batintotal: 1090500, batin: 0, batouttotal: 998300, batout: 500
batmaxsoc: -, batsetsoc: -
wid: 102, wcc: 65, wrp: 1.00, temp: 4.30, pvcorrf: 1.00/-
csmt01: 158260, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 33
csmt03: 227180, csme03: 30, minutescsm03: 0
05 => etotal: 4081900, pvfc: 0, pvrl: 0, rad1h: -
confc: 359, con: 293, gcon: 6, gfeedin: 13
batintotal: 1090500, batin: 0, batouttotal: 998800, batout: 300
batmaxsoc: -, batsetsoc: -
wid: 102, wcc: 71, wrp: 2.00, temp: 4.40, pvcorrf: 1.00/-
csmt01: 158270, csme01: 10, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 26
csmt03: 227220, csme03: 40, minutescsm03: 0
06 => etotal: 4081900, pvfc: 0, pvrl: 0, rad1h: -
confc: 357, con: 392, gcon: 8, gfeedin: 16
batintotal: 1090500, batin: 0, batouttotal: 999100, batout: 400
batmaxsoc: -, batsetsoc: -
wid: 102, wcc: 73, wrp: 2.00, temp: 4.70, pvcorrf: 1.00/-
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 28
csmt03: 227250, csme03: 30, minutescsm03: 0
07 => etotal: 4081900, pvfc: 0, pvrl: 0, rad1h: -
confc: 373, con: 393, gcon: 7, gfeedin: 14
batintotal: 1090500, batin: 0, batouttotal: 999500, batout: 400
batmaxsoc: -, batsetsoc: -
wid: 102, wcc: 73, wrp: 3.00, temp: 4.20, pvcorrf: 1.00/-
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 29
csmt03: 227280, csme03: 20, minutescsm03: 0
08 => etotal: 4081900, pvfc: 3, pvrl: 0, rad1h: -
confc: 423, con: 361, gcon: 265, gfeedin: 4
batintotal: 1090500, batin: 0, batouttotal: 999900, batout: 100
batmaxsoc: -, batsetsoc: -
wid: 2, wcc: 74, wrp: 3.00, temp: 4.80, pvcorrf: 0.58/0.13
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 27
csmt03: 227320, csme03: 30, minutescsm03: 0
09 => etotal: 4081900, pvfc: 185, pvrl: 800, rad1h: -
confc: 468, con: 604, gcon: 26, gfeedin: 22
batintotal: 1090500, batin: 300, batouttotal: 1000000, batout: 100
batmaxsoc: -, batsetsoc: -
wid: 2, wcc: 78, wrp: 2.00, temp: 5.40, pvcorrf: 1.61/0.00
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567430, csme02: 0, minutescsm02: 23
csmt03: 227350, csme03: 30, minutescsm03: 0
10 => etotal: 4082700, pvfc: 211, pvrl: 2200, rad1h: -
confc: 602, con: 895, gcon: 16, gfeedin: 21
batintotal: 1090800, batin: 1300, batouttotal: 1000100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 79, wrp: 2.00, temp: 6.30, pvcorrf: 0.98/0.73
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567480, csme02: 50, minutescsm02: 24
csmt03: 227380, csme03: 30, minutescsm03: 26
11 => etotal: 4084900, pvfc: 649, pvrl: 700, rad1h: -
confc: 2754, con: 590, gcon: 12, gfeedin: 22
batintotal: 1092100, batin: 100, batouttotal: 1000100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 84, wrp: 2.00, temp: 7.10, pvcorrf: 0.87/0.72
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567590, csme02: 110, minutescsm02: 22
csmt03: 227410, csme03: 30, minutescsm03: 60
12 => etotal: 4085600, pvfc: 1830, pvrl: 2200, rad1h: -
confc: 618, con: 889, gcon: 24, gfeedin: 35
batintotal: 1092200, batin: 1300, batouttotal: 1000100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 94, wrp: 5.00, temp: 6.60, pvcorrf: 0.90/0.02
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567690, csme02: 100, minutescsm02: 23
csmt03: 227440, csme03: 30, minutescsm03: 60
13 => etotal: 4087800, pvfc: 1520, pvrl: 2900, rad1h: -
confc: 665, con: 985, gcon: 39, gfeedin: 54
batintotal: 1093500, batin: 1900, batouttotal: 1000100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 92, wrp: 8.00, temp: 7.40, pvcorrf: 0.94/0.73
csmt01: 158270, csme01: 0, minutescsm01: 0
csmt02: 567800, csme02: 110, minutescsm02: 23
csmt03: 227460, csme03: 20, minutescsm03: 60
14 => etotal: 4091100, pvfc: 1311, pvrl: 800, rad1h: -
confc: 947, con: 294, gcon: 12, gfeedin: 18
batintotal: 1095400, batin: 500, batouttotal: 1000100, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 91, wrp: 14.00, temp: 7.90, pvcorrf: 0.92/0.06
csmt01: 158280, csme01: 10, minutescsm01: 0
csmt02: 567970, csme02: 170, minutescsm02: 22
csmt03: 227490, csme03: 30, minutescsm03: 60
15 => etotal: 4092100, pvfc: 573, pvrl: 600, rad1h: -
confc: 801, con: 587, gcon: 14, gfeedin: 27
batintotal: 1095900, batin: 100, batouttotal: 1000100, batout: 100
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 93, wrp: 21.00, temp: 8.10, pvcorrf: 0.60/0.59
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568060, csme02: 90, minutescsm02: 54
csmt03: 227520, csme03: 30, minutescsm03: 60
16 => etotal: 4092700, pvfc: 795, pvrl: 600, rad1h: -
confc: 817, con: 692, gcon: 13, gfeedin: 21
batintotal: 1096000, batin: 0, batouttotal: 1000200, batout: 100
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 91, wrp: 31.00, temp: 8, pvcorrf: 1.00/0.93
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568190, csme02: 120, minutescsm02: 28
csmt03: 227560, csme03: 30, minutescsm03: 60
17 => etotal: 4093300, pvfc: 256, pvrl: 300, rad1h: -
confc: 685, con: 490, gcon: 17, gfeedin: 27
batintotal: 1096000, batin: 0, batouttotal: 1000300, batout: 200
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 92, wrp: 35.00, temp: 7.90, pvcorrf: 0.91/0.96
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568270, csme02: 70, minutescsm02: 33
csmt03: 227590, csme03: 30, minutescsm03: 60
18 => etotal: 4093600, pvfc: 27, pvrl: 0, rad1h: -
confc: 815, con: 595, gcon: 14, gfeedin: 19
batintotal: 1096000, batin: 0, batouttotal: 1000500, batout: 600
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 96, wrp: 38.00, temp: 7.70, pvcorrf: 2.79/0.25
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568400, csme02: 120, minutescsm02: 31
csmt03: 227620, csme03: 20, minutescsm03: 60
19 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 891, con: 1893, gcon: 38, gfeedin: 45
batintotal: 1096000, batin: 0, batouttotal: 1001100, batout: 1900
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 99, wrp: 42.00, temp: 7.30, pvcorrf: 0.84/0.71
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568540, csme02: 140, minutescsm02: 30
csmt03: 227660, csme03: 30, minutescsm03: 60
20 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 844, con: 1492, gcon: 18, gfeedin: 26
batintotal: 1096000, batin: 0, batouttotal: 1003000, batout: 1500
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 99, wrp: 49.00, temp: 7.20, pvcorrf: 0.92/0.03
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568640, csme02: 100, minutescsm02: 28
csmt03: 227690, csme03: 30, minutescsm03: 60
21 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 859, con: 795, gcon: 8, gfeedin: 13
batintotal: 1096000, batin: 0, batouttotal: 1004500, batout: 800
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 99, wrp: 54.00, temp: 7.10, pvcorrf: 1.00/-
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568690, csme02: 50, minutescsm02: 24
csmt03: 227720, csme03: 30, minutescsm03: 60
22 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 967, con: 1010, gcon: 811, gfeedin: 1
batintotal: 1096000, batin: 0, batouttotal: 1005300, batout: 200
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 100, wrp: 59.00, temp: 7, pvcorrf: 1.00/-
csmt01: 158280, csme01: 0, minutescsm01: 0
csmt02: 568870, csme02: 180, minutescsm02: 24
csmt03: 227750, csme03: 30, minutescsm03: 60
23 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 909, con: 721, gcon: 721, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 100, wrp: 60.00, temp: 6.90, pvcorrf: 1.00/-
csmt01: 158290, csme01: 10, minutescsm01: 0
csmt02: 568950, csme02: 80, minutescsm02: 23
csmt03: 227780, csme03: 30, minutescsm03: 37
24 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 792, con: 655, gcon: 655, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 93, wrp: 62.00, temp: 6.20, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568950, csme02: 0, minutescsm02: 24
csmt03: 227810, csme03: 30, minutescsm03: 0
99 => etotal: , pvfc: 7360, pvrl: 11100, rad1h: -
confc: 18155, con: 16893, gcon: 2751, gfeedin: 458
batintotal: , batin: 5500, batouttotal: , batout: 9000
batmaxsoc: 55.61, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: Wed
cyclescsm01: 0, csme01: 30.00
cyclescsm02: 26, csme02: 1490.00, hourscsme02: 11.07
cyclescsm03: 1, csme03: 700.00, hourscsme03: 13.05
08 => 01 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 698, con: 728, gcon: 728, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 100, wrp: 63.00, temp: 6.10, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568950, csme02: 0, minutescsm02: 25
csmt03: 227840, csme03: 30, minutescsm03: 0
02 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 590, con: 748, gcon: 748, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 100, wrp: 60.00, temp: 6.20, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568970, csme02: 20, minutescsm02: 27
csmt03: 227880, csme03: 40, minutescsm03: 22
03 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 524, con: 1046, gcon: 1046, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 100, wrp: 52.00, temp: 6.5, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568970, csme02: 0, minutescsm02: 23
csmt03: 227910, csme03: 30, minutescsm03: 0
04 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 399, con: 1017, gcon: 1017, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 100, wrp: 47.00, temp: 6.80, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568970, csme02: 0, minutescsm02: 23
csmt03: 227930, csme03: 20, minutescsm03: 0
05 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 357, con: 336, gcon: 336, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 100, wrp: 41.00, temp: 7, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568970, csme02: 0, minutescsm02: 29
csmt03: 227960, csme03: 30, minutescsm03: 0
06 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 358, con: 376, gcon: 376, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 99, wrp: 37.00, temp: 7.10, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568970, csme02: 0, minutescsm02: 24
csmt03: 227990, csme03: 30, minutescsm03: 0
07 => etotal: 4093600, pvfc: 0, pvrl: 0, rad1h: -
confc: 373, con: 399, gcon: 399, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 99, wrp: 41.00, temp: 6.70, pvcorrf: 1.00/-
csmt01: 158290, csme01: 0, minutescsm01: 0
csmt02: 568970, csme02: 0, minutescsm02: 25
csmt03: 228020, csme03: 30, minutescsm03: 0
08 => etotal: 4093600, pvfc: 4, pvrl: 0, rad1h: -
confc: 421, con: 343, gcon: 343, gfeedin: 0
batintotal: 1096000, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 99, wrp: 38.00, temp: 7, pvcorrf: 0.58/0.13
csmt01: 158300, csme01: 10, minutescsm01: 0
csmt02: 568970, csme02: 0, minutescsm02: 30
csmt03: 228050, csme03: 20, minutescsm03: 0
09 => etotal: 4093600, pvfc: 440, pvrl: 200, rad1h: -
confc: 473, con: 249, gcon: 154, gfeedin: 5
batintotal: 1096000, batin: 100, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 100, wrp: 36.00, temp: 7.5, pvcorrf: 1.11/0.23
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 568980, csme02: 10, minutescsm02: 28
csmt03: 228090, csme03: 30, minutescsm03: 4
10 => etotal: 4093800, pvfc: 940, pvrl: 400, rad1h: -
confc: 612, con: 639, gcon: 242, gfeedin: 3
batintotal: 1096100, batin: 0, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 98, wrp: 38.00, temp: 8.20, pvcorrf: 1.03/0.10
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 569110, csme02: 130, minutescsm02: 31
csmt03: 228120, csme03: 30, minutescsm03: 59
11 => etotal: 4094200, pvfc: 1129, pvrl: 1900, rad1h: -
confc: 2682, con: 791, gcon: 27, gfeedin: 36
batintotal: 1096100, batin: 1100, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 97, wrp: 34.00, temp: 8.90, pvcorrf: 0.87/0.93
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 569210, csme02: 100, minutescsm02: 26
csmt03: 228160, csme03: 40, minutescsm03: 59
12 => etotal: 4096100, pvfc: 1022, pvrl: 3099, rad1h: -
confc: 644, con: 880, gcon: 68, gfeedin: 87
batintotal: 1097200, batin: 2200, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 51, wcc: 94, wrp: 32.00, temp: 8.70, pvcorrf: 0.90/0.83
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 569270, csme02: 50, minutescsm02: 31
csmt03: 228190, csme03: 30, minutescsm03: 30
13 => etotal: 4099200, pvfc: 1677, pvrl: 2000, rad1h: -
confc: 691, con: 890, gcon: 27, gfeedin: 37
batintotal: 1099400, batin: 1100, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 96, wrp: 27.00, temp: 9.20, pvcorrf: 0.94/0.52
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 569370, csme02: 100, minutescsm02: 32
csmt03: 228220, csme03: 30, minutescsm03: 59
14 => etotal: 4101200, pvfc: 1764, pvrl: 2300, rad1h: -
confc: 953, con: 798, gcon: 19, gfeedin: 21
batintotal: 1100500, batin: 1500, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 61, wcc: 96, wrp: 19.00, temp: 9.80, pvcorrf: 0.91/0.36
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 569490, csme02: 110, minutescsm02: 23
csmt03: 228250, csme03: 30, minutescsm03: 60
15 => etotal: 4103700, pvfc: 1132, pvrl: 1199, rad1h: -
confc: 817, con: 395, gcon: 15, gfeedin: 19
batintotal: 1102000, batin: 800, batouttotal: 1005500, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 95, wrp: 16.00, temp: 10.1, pvcorrf: 0.60/0.95
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 569590, csme02: 100, minutescsm02: 28
csmt03: 228280, csme03: 30, minutescsm03: 59
16 => etotal: 4104900, pvfc: 607, pvrl: 500, rad1h: -
confc: 836, con: 792, gcon: 8, gfeedin: 16
batintotal: 1102800, batin: 0, batouttotal: 1005500, batout: 300
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 94, wrp: 13.00, temp: 10.2, pvcorrf: 1.00/0.68
csmt01: 158300, csme01: 0, minutescsm01: 0
csmt02: 569740, csme02: 150, minutescsm02: 24
csmt03: 228310, csme03: 30, minutescsm03: 59
17 => etotal: 4105400, pvfc: 205, pvrl: 200, rad1h: -
confc: 679, con: 894, gcon: 13, gfeedin: 19
batintotal: 1102800, batin: 0, batouttotal: 1005800, batout: 700
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 90, wrp: 9.00, temp: 10.1, pvcorrf: 0.92/0.85
csmt01: 158310, csme01: 10, minutescsm01: 0
csmt02: 569870, csme02: 130, minutescsm02: 19
csmt03: 228340, csme03: 30, minutescsm03: 59
18 => etotal: 4105600, pvfc: 36, pvrl: 0, rad1h: -
confc: 807, con: 1193, gcon: 17, gfeedin: 24
batintotal: 1102800, batin: 0, batouttotal: 1006500, batout: 1200
batmaxsoc: -, batsetsoc: -
wid: 3, wcc: 89, wrp: 5.00, temp: 9.70, pvcorrf: 2.79/0.25
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 569960, csme02: 90, minutescsm02: 23
csmt03: 228370, csme03: 30, minutescsm03: 59
19 => etotal: 4105600, pvfc: 0, pvrl: 0, rad1h: -
confc: 924, con: 896, gcon: 9, gfeedin: 13
batintotal: 1102800, batin: 0, batouttotal: 1007700, batout: 900
batmaxsoc: -, batsetsoc: -
wid: 103, wcc: 89, wrp: 3.00, temp: 9.30, pvcorrf: 0.84/0.71
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 570090, csme02: 120, minutescsm02: 26
csmt03: 228400, csme03: 30, minutescsm03: 59
20 => etotal: 4105600, pvfc: 0, pvrl: 0, rad1h: -
confc: 866, con: 895, gcon: 14, gfeedin: 19
batintotal: 1102800, batin: 0, batouttotal: 1008600, batout: 900
batmaxsoc: -, batsetsoc: -
wid: 103, wcc: 89, wrp: 3.00, temp: 9.20, pvcorrf: 0.92/0.03
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 570230, csme02: 140, minutescsm02: 25
csmt03: 228430, csme03: 30, minutescsm03: 59
21 => etotal: 4105600, pvfc: 0, pvrl: 0, rad1h: -
confc: 857, con: 793, gcon: 7, gfeedin: 14
batintotal: 1102800, batin: 0, batouttotal: 1009500, batout: 800
batmaxsoc: -, batsetsoc: -
wid: 103, wcc: 87, wrp: 5.00, temp: 8.90, pvcorrf: 1.00/-
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 570300, csme02: 70, minutescsm02: 25
csmt03: 228460, csme03: 30, minutescsm03: 35
22 => etotal: 4105600, pvfc: 0, pvrl: 0, rad1h: -
confc: 968, con: 894, gcon: 8, gfeedin: 14
batintotal: 1102800, batin: 0, batouttotal: 1010300, batout: 900
batmaxsoc: -, batsetsoc: -
wid: 103, wcc: 89, wrp: 9.00, temp: 8.70, pvcorrf: 1.00/-
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 570300, csme02: 0, minutescsm02: 27
csmt03: 228500, csme03: 40, minutescsm03: 4
23 => etotal: 4105600, pvfc: 0, pvrl: 0, rad1h: -
confc: 903, con: 988, gcon: 198, gfeedin: 10
batintotal: 1102800, batin: 0, batouttotal: 1011200, batout: 800
batmaxsoc: -, batsetsoc: -
wid: 103, wcc: 89, wrp: 13.00, temp: 8.40, pvcorrf: 1.00/-
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 570300, csme02: 0, minutescsm02: 30
csmt03: 228530, csme03: 30, minutescsm03: 0
24 => etotal: 4105600, pvfc: 0, pvrl: 0, rad1h: -
confc: 787, con: 602, gcon: 602, gfeedin: 0
batintotal: 1102800, batin: 0, batouttotal: 1012000, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 103, wcc: 88, wrp: 10.00, temp: 7.90, pvcorrf: 1.00/-
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 570300, csme02: 0, minutescsm02: 27
csmt03: 228570, csme03: 40, minutescsm03: 0
99 => etotal: , pvfc: 8956, pvrl: 11798, rad1h: -
confc: 18219, con: 17582, gcon: 6421, gfeedin: 337
batintotal: , batin: 6800, batouttotal: , batout: 6500
batmaxsoc: 65.87, batsetsoc: -
wid: , wcc: , wrp: , pvcorrf: , dayname: Thu
cyclescsm01: 0, csme01: 20.00
cyclescsm02: 26, csme02: 1320.00, hourscsme02: 10.52
cyclescsm03: 4, csme03: 740.00, hourscsme03: 11.43
8 => 99 => etotal: -, pvfc: 0, pvrl: 0, rad1h: -
confc: 0, con: 0, gcon: 0, gfeedin: 0
batintotal: -, batin: 0, batouttotal: -, batout: 0
batmaxsoc: -, batsetsoc: -
wid: -, wcc: -, wrp: -, pvcorrf: -
09 => 01 => etotal: 4105600, pvfc: 0, pvrl: 0, rad1h: -
confc: 699, con: 555, gcon: 555, gfeedin: 0
batintotal: 1102800, batin: 0, batouttotal: 1012000, batout: 0
batmaxsoc: -, batsetsoc: -
wid: 161, wcc: 92, wrp: 27.00, temp: 7.70, pvcorrf: 1.00/-
csmt01: 158310, csme01: 0, minutescsm01: 0
csmt02: 570300, csme02: 0, minutescsm02: 28
csmt03: 228600, csme03: 30, minutescsm03: 0
Hallo minierm,
in deiner pvHistory gibt es den Tag 08 und 8, woher auch immer der Eintrag kommt ist er falsch/überflüssig.
Lösche ihn einfach mit:
set <name> reset pvHistory 8 (nicht 08)
ZitatUnd warum wird dann PV Real so exorbitant hoch angezeigt?
Weil ich die Beschränkung bzgl. Inverterkapazität auf den PV Forecast anwende. PV real habe ich bisher nicht beschränkt (sorry, zu schnell drüber gelesen). Ich überlege noch ob ich die Beschränkung hier auch anwende, bin mir jedoch unsicher weil man mit der aktuellen Implementierung, wie im vorliegenden Fall zu sehen, evetuelle Fehlkonfigurationen erkennt und beseitigen kann. Mit einer Beschränkung wäre das Problem nicht so augenscheinlich. Hat alles Vor- und Nachteile.
Zitat von: DS_Starter am 12 Februar 2024, 18:45:06Hallo minierm,
in deiner pvHistory gibt es den Tag 08 und 8, woher auch immer der Eintrag kommt ist er falsch/überflüssig.
Lösche ihn einfach mit:
set <name> reset pvHistory 8 (nicht 08)
ZitatUnd warum wird dann PV Real so exorbitant hoch angezeigt?
Weil ich die Beschränkung bzgl. Inverterkapazität auf den PV Forecast anwende. PV real habe ich bisher nicht beschränkt (sorry, zu schnell drüber gelesen). Ich überlege noch ob ich die Beschränkung hier auch anwende, bin mir jedoch unsicher weil man mit der aktuellen Implementierung, wie im vorliegenden Fall zu sehen, evetuelle Fehlkonfigurationen erkennt und beseitigen kann. Mit einer Beschränkung wäre das Problem nicht so augenscheinlich. Hat alles Vor- und Nachteile.
Danke, Tag 8 ist gelöscht.
Bzgl. Limit:
Ja, man sieht ein Problem nicht mehr so deutlich. Ein Real am Maximum plus Toleranz könnte aber schon auffallen ;-)
Hallo zusammen,
ich habe eine neues Get Kommando zur Integration und Management des MOSMIX Stationenkatalogs implementiert:
dwdCatalog
Der Deutsche Wetterdienst stellt einen Katalog der MOSMIX Stationen zur Verfügung.
Mit diesem Kommando wird der Katalog in SolarForecast eingelesen und in der Datei ./FHEM/FhemUtils/DWDcat_SolarForecast gespeichert.
Der Katalog kann umfangreich gefiltert und im GPS Exchange Format (GPX) gespeichert werden. Die Koordinaten Latitude und Logitude werden in Dezimalgrad ausgegeben.
Zur Filterung werden Regex-Ausdrücke in den entsprechenden Schlüsseln verwendet. Der Regex wird zur Auswertung in ^...$ eingeschlossen.
Folgende Parameter können angegeben werden. Ohne Parameter erfolgt die Ausgabe des gesamten Katalogs:
byID Die Ausgabe erfolgt sortiert nach Stations-ID. (default)
byName Die Ausgabe erfolgt sortiert nach Stations-Name.
force Es wird die neueste Version des DWD Stationskatalogs in das System geladen.
exportgpx Die (gefilterten) Stationen werden in der Datei ./FHEM/FhemUtils/DWDcat_SolarForecast.gpx gespeichert.
Diese Datei kann z.B. im GPX-Viewer dargestellt werden.
id=<Regex> Es erfolgt eine Filterung nach Stations-ID.
name=<Regex> Es erfolgt eine Filterung nach Stations-Name.
lat=<Regex> Es erfolgt eine Filterung nach Latitude.
lon=<Regex> Es erfolgt eine Filterung nach Longitude.
Beispiel:
get <name> dwdCatalog byName name=ST.* exportgpx lat=(48|49|50|51|52).* lon=([5-9]|1[0-5]).*
# filtert die Stationen weitgehend auf deutsche Orte beginnend mit "ST" und exportiert die Daten im GPS Exchange Format
Dadurch habe ich die Stationen bei Bedarf im Modul zur Verfügung und kann damit arbeiten.
Die Version ist morgen früh im Update. Wer mag kann sie sich schon aus meinem contrib laden. Wie immer Restart nicht vergessen.
Da ich mich etwas näher mit MOSMIX befasst habe ist mir auch bewusst geworden, dass die DWD Devices die MOSMIX_L Stationen benutzen. Leider werden diese Stationen nur alle 6 Stunden (4 x am Tag) aktualisiert. Schnelle Wetteränderungen bekommen wir für die Vorhersageanpassung nicht vermittelt. Dagegen werden die MOSMIX_S Datensätze jede Stunde aktualisiert. Im DWD_Opendata Thread habe ich jensb gefragt ob er eine Möglichkeit sieht MOSMIX_S mit anzubieten. Leider ist die MOSMIX_S Datei sehr groß und nicht für jede Station separat verfügbar. Mal schauen.
LG
Morgen früh gibt es ein Update.
Wesentlicher Inhalt ist die Auffüllung historischer KI Train Datensätze mit Sun Azimuth und Altitude via Astro-Modul.
Dieser Change wird nach einiger Laufzeit wieder ausgebaut, da er nur temprorär benötigt wird um die Daten anzureichern.
Für get ... dwdCatalog habe ich auch das Beispiel in der Comref nachgebessert. Es hat nicht ganz das getan was ich haben wollte:
get <name> dwdCatalog byName exportgpx lat=(48|49|50|51|52)\..* lon=([5-9]|10|11|12|13|14|15)\..*
Das Update kann bereits jetzt aus meinem contrib gezogen werden wer möchte. Restart nicht vergessen!
LG
Nach Update / Restart erhalte ich folgende Fehler im Protokoll:
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcEnd in addition (+) at ./FHEM/98_DOIF.pm line 6372.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcBegin in addition (+) at ./FHEM/98_DOIF.pm line 6372.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcEnd in numeric gt (>) at ./FHEM/98_DOIF.pm line 6373.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcBegin in numeric gt (>) at ./FHEM/98_DOIF.pm line 6373.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcBegin in sprintf at ./FHEM/98_DOIF.pm line 6818.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcEnd in sprintf at ./FHEM/98_DOIF.pm line 6818.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcBegin in sprintf at ./FHEM/98_DOIF.pm line 6836.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $arcEnd in sprintf at ./FHEM/98_DOIF.pm line 6836.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $endAngle in numeric gt (>) at ./FHEM/98_DOIF.pm line 6408.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $startAngle in numeric gt (>) at ./FHEM/98_DOIF.pm line 6408.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $angleInDegrees in subtraction (-) at ./FHEM/98_DOIF.pm line 6364.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $startAngle in subtraction (-) at ./FHEM/98_DOIF.pm line 6415.
2024.02.16 16:18:42 1: PERL WARNING: Use of uninitialized value $endAngle in subtraction (-) at ./FHEM/98_DOIF.pm line 6415.
Kann es sein das dies von den temporären neuen Berechnungen / Auffüllen kommt ?
Gruß
300P
Nachsatz:
Ebenfalls auch bei einem kompletten Reboot des RPI:
2024.02.16 16:30:34 1: Including ./log/fhem.save
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcEnd in addition (+) at ./FHEM/98_DOIF.pm line 6372.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcBegin in addition (+) at ./FHEM/98_DOIF.pm line 6372.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcEnd in numeric gt (>) at ./FHEM/98_DOIF.pm line 6373.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcBegin in numeric gt (>) at ./FHEM/98_DOIF.pm line 6373.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcBegin in sprintf at ./FHEM/98_DOIF.pm line 6818.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcEnd in sprintf at ./FHEM/98_DOIF.pm line 6818.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcBegin in sprintf at ./FHEM/98_DOIF.pm line 6836.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $arcEnd in sprintf at ./FHEM/98_DOIF.pm line 6836.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $endAngle in numeric gt (>) at ./FHEM/98_DOIF.pm line 6408.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $startAngle in numeric gt (>) at ./FHEM/98_DOIF.pm line 6408.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $angleInDegrees in subtraction (-) at ./FHEM/98_DOIF.pm line 6364.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $startAngle in subtraction (-) at ./FHEM/98_DOIF.pm line 6415.
2024.02.16 16:30:35 1: PERL WARNING: Use of uninitialized value $endAngle in subtraction (-) at ./FHEM/98_DOIF.pm line 6415.
2024.02.16 16:30:35 1: PERL WARNING: Argument "initialized" isn't numeric in numeric gt (>) at (eval 855) line 1.
2024.02.16 16:30:35 0: Featurelevel: 6.3
2024.02.16 16:30:35 0: Server started with 298 defined entities (fhem.pl:28484/2024-02-06 perl:5.032001 os:linux user:fhem pid:873)
Die kommen doch aus DOIF.
Kannst ja sicherheitshalber mal ein global stacktrace setzen. Aber ich sehe da keinen Zusammenhang.
Könnte es sein das du neuerdings irgendetwas mit / für Winkelberechnungen mit ,,knob" aufrufst um die Berechnungen der Winkel zu nutzen ??
Nein, es erfolgt nur ein Aufruf einer Funktion im Astro Modul mit Argumenten. Die habe alle nichts mit Winkeln oder knob zu tun.
Was zeigt denn der stacktrace beim Start?
Na, jetzt hab ich den Übeltäter gesehen und gefunden - eine der Doif-card benutzt genau diese Winkelfunktion und bekommt wohl keine sinnigen Werte zugewiesen - hab sie gelöscht und weg war es. Dann eben ohne das Bildchen.
Sorry, da ich mehrfach die Woche einen FHEM-"Restart" mache (oder nach erfolgten Änderungen / Updates auch) und dann immer ins Logbuch schaue hatte ich diesmal wegen der Winkelfunktionen dein Modul mir den temporären Datenrzeugungen in Verdacht weil dies mit dem Update zusammen passte. Auf eine Doif-card hin hatte ich es nicht nun gar nicht vermutet.
Kommt vor ;)
Zitatmehrfach die Woche einen FHEM-"Restart"
Das sollte man tunlichst unterlassen.
LG
pah
ZitatDas sollte man tunlichst unterlassen.
Warum?
Zitat von: DS_Starter am 15 Februar 2024, 14:12:04Morgen früh gibt es ein Update.
Wesentlicher Inhalt ist die Auffüllung historischer KI Train Datensätze mit Sun Azimuth und Altitude via Astro-Modul.
Vielen Dank für die Umsetzung!
Kann es sein, dass die Azimuth Werte nicht gerundet sind im Gegensatz zu den anderen Werten in aiRawData?
Die Motivation hinter der Ergänzung der Altitude Werte leuchtet mir ein und ich erwarte dadurch ein besseres Einlernen der jahreszeitlich unterschiedlichen Einflüsse von Abschattungen.
Was könnte der Mehrwert der Azimuth Werte im Datensatz sein? Sind die Informationen nicht ziemlich deckungsgleich mit den Daten der vollen Stunde (hod)?
Viele Grüße
Alex
Hallo Alex,
ZitatKann es sein, dass die Azimuth Werte nicht gerundet sind im Gegensatz zu den anderen Werten in aiRawData?
Ja das ist richtig. Sie aber nicht gerundet, sondern bins, also "Töpfen" zugeordnet.
Wenn man sich die Azimuth Werte anschaut, sind sie (gleiche Stunde) in etwa über einen Zeitraum von ca. 4 Tagen gleich. D.h. es würden über ein Jahr etwa 90 verschiedene Werte für die gleiche Stunde zutreffen. Das erschien mir überschaubar und habe zunächst auf bins für diesen verzichtet. Muß man sehen wie es sich darstellt.
ZitatWas könnte der Mehrwert der Azimuth Werte im Datensatz sein? Sind die Informationen nicht ziemlich deckungsgleich mit den Daten der vollen Stunde (hod)?
Völlig richtig. Daher werde ich die Entwicklung in den Entscheidungspfaden der KI (get ... valDecTree aiRuleStrings) verfolgen, ob und in welchem Umfang diese Daten Eingang finden.
Wenn es sich als unnütz herausstellen sollte, wird das Azimuth wieder entfernt aus den aiRawData. Das lässt sich automatisch leicht realisieren.
LG,
Heiko
Hallo Heiko,
danke dir für die Erklärungen. Mal sehen wie sich das mit der Zeit entwickelt. Mein Datensatz ist noch recht jung (2 Monate). Von daher kann ich noch keine Tendenz erkennen...
Grüße Alex
Ich möchte euch auf die Aktivitäten im DWD Modul (https://forum.fhem.de/index.php?topic=83097.0) aufmerksam machen ... wer es verfolgen mag.
LG
Hallo Heiko,
Ich bin ja kein Programmierer, hast Du für die KI Prognose in PERL eine Bibliothek gefunden?
Ich würde gerne das Python los werden und im PERL bleiben.
VG Christian
Hallo Christian,
ja es gibt einige Bibliotheken.
Im Modul setze ich zur Zeit AI::DecisionTree (https://metacpan.org/pod/AI::DecisionTree) ein. Es ist gut handhabbar mit dem Nachteil keine diskreten Werte verarbeiten zu können. Man muss sie ggf. vorher in "bins" kategorisieren. Interessant ist auch Algorithm::DecisionTree (https://metacpan.org/pod/Algorithm::DecisionTree) was ich mir noch anschauen möchte.
Dann habe ich noch AI::MXNet (https://metacpan.org/pod/AI::MXNet) was den Zugang zum Apache MXNet (https://mxnet.apache.org/versions/1.4.1/api/perl/index.html) herstellt und wohl am leistungsfähigsten anzusehen ist.
Zu AI::General (https://metacpan.org/pod/AI::General) habe ich keinen Zugang gefunden. Es wäre noch AI::TensorFlow (https://metacpan.org/pod/AI::TensorFlow::Libtensorflow), AI::FANN (https://metacpan.org/pod/AI::FANN) oder AI::Perceptron (https://metacpan.org/dist/AI-Perceptron/view/lib/AI/Perceptron.pm) zu nennen.
Wie gut die Bibliotheken in unseren Anwendungsfall passen, kann ich dir nicht sagen. Bis jetzt fand ich nur die Zeit mich näher mit AI::DecisionTree zu befassen.
Im KI Umfeld ist Python eigentlich eher das Mittel der Wahl, aber ich selbst bleibe auch lieber monolithisch. Das wird mir sonst einfach too much.
Grüße,
Heiko
Gibt es denn ein Perl-Binding von dem zentralen TensorFlow? Ich denke, eher nicht.
LG
pah
Hallo pah,
ich bewege mich jetzt auf dünnem Eis ;) ...
Wenn ich mir die Quickstart-Doku anschaue https://metacpan.org/dist/AI-TensorFlow-Libtensorflow/view/lib/AI/TensorFlow/Libtensorflow/Manual/Quickstart.pod
dann verweist man dort im Verlauf auch direkt auf die TensorFlow home page. Dort wiederum unter API (https://www.tensorflow.org/api_docs) wird Perl mit Verweis auf genau die AI::TensorFlow::Libtensorflow Lib erwähnt.
Meintest du das mit "zentralen TensorFlow"?
Und AI::TensorFlow::Libtensorflow ist sogar recht aktuell (2023).
LG,
Heiko
Okay, danke für die Info.
Ich bleib beim Python, was ich bereits mit diversen Meldungen ins FHEM gekoppelt habe.
VG Christian
@DS_Starter: I stand corrected, gibt es offenbar doch.
LG
pah
Hallo zusammen,
ich habe folgendes Problem. Ich benutze das Model DWD, wenn ich nun die pvCorrectionFactor_Auto auf on_complex(_ai) umstelle
startet mein FHEM neu. In der LOG finde ich nur den den Eintrag: Illegal division by zero at ./FHEM/76_SolarForecast.pm line 6546.
Kann das jemand replizieren? Diese passiert dann auch zu jeden vollen Stunde.
LG Ingo
Moin Ingo,
das ist ein Fehler den ich abfabgen muß.
Er kommt zum Tragen wenn in der Kombination einer "normalen" PV Erwartung von 0 in Verbindung mit einem AI Hit eine Kalkulation erfolgen muß.
Das werde ich mit dem kommenden Relaese fixen oder evtl. heute Abend als Reparatur über mein contrib bereitstellen.
Verzichte einstweilen auf die Umschaltung ai.
Edit: Führe aber bitte noch eine Anlagenprüfung durch (set ... plantConfig check)
LG,
Heiko
Zitat von: DS_Starter am 19 Februar 2024, 09:45:38Moin Ingo,
das ist ein Fehler den ich abfabgen muß.
Er kommt zum Tragen wenn in der Kombination einer "normalen" PV Erwartung von 0 in Verbindung mit einem AI Hit eine Kalkulation erfolgen muß.
Das werde ich mit dem kommenden Relaese fixen oder evtl. heute Abend als Reparatur über mein contrib bereitstellen.
Verzichte einstweilen auf die Umschaltung ai.
Edit: Führe aber bitte noch eine Anlagenprüfung durch (set ... plantConfig check)
LG,
Heiko
Danke für die Info, plantConfig check hatte ich im Vorfeld schon ausgeführt dabei waren keine Fehler oder Hinweise aufgetaucht.
Hallo Ingo,
du kannst dir die gefixte Version 1.16.2 aus meinem contrib herunterladen und Restart nicht vergessen!
Edit: In der Version sind schon Weiterentwicklungen enthalten. Setze in dem verwendeten DWD Wetterdevice im Attribut forecastProperties die Eigenschaft "RR1c" nach dem Update. Dafür kannst du R101 löschen.
LG
Hallo zusammen,
in meinem contrib liegt eine weiterentwicklte Version (https://svn.fhem.de/trac/export/28537/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm) von 55_DWD_OpenData.
Diese Version besitzt das Attribut forecastDataPrecision zur Umschaltung auf die Nutzung von MOSMIX_S. Diese Werte werden jede Stunde vom DWD upgedated gegenüber alle 6 Stunden im Standard MOSMIX_L.
Weitere Infos zum Fortgang findet ihr hier: https://forum.fhem.de/index.php?msg=1304074
Ungeachtet weiterer Optimierungen könnt ihr die V aus meinem contrib einsetzen und nach Download/Restart das Attribut forecastDataPrecision auf "high" stellen. Fügt dann bitte im Attribut forecastProperties den Wert "RR1c" noch hinzu. Das gilt generell für die DWD Devices die ihr für SolarForecast verwendet.
Mit dem nächsten Update von SolarForecast (vermutlich Donnerstag) wird die Nutzung von R101 auf RR1c umgestellt.
LG,
Heiko
Danke schön, jetzt funktioniert es
Hallo zusammen,
wie angekündigt, wird morgen früh ein Update ausgeliefert.
Neben einigen internen Codechanges wird in den DWD Devices die Nutzung von R101 auf RR1c umgestellt.
In allen beteiligten DWD Devices setzt bitte im Attribut forecastProperties RR1c statt R101.
RR1c kann natürlich auch zusätzlich eingetragen werden.
Die Eigenschaft wird auch geprüft und im plantConfigcheck überwacht. Ebenso erfolgt eine Anzeige in der GUI falls der Rad1h (Globalstrahlung) Wert älter als 2 Stunden ist. Die Anzeige wird in diesem Fall gelb statt grün.
Wenn ihr das neue DWD_OpenData Modul aus meinem contrib nutzt, stellt forecastDataPrecision auf "high". Im herkömmlichen DWD_OpenData erfolgt das Update der Wetterwerte nur alle 6 Stunden durch den DWD. Die GUI Anzeige wird dann fast immer auf "gelb" stehen.
Das ist natürlich nicht schädlich und entspricht dem bisherigen Verhalten. Aber um schnelle Wetteränderungen mitzubekommen ist das DWD_OpenData Modul aus meinem contrib hilfreich.
LG,
Heiko
Guten Morgen!
das sieht erst einmal gut aus:
Ich habe da so einen Wunsch...
Die Komplexität des Moduls ist inzwischen so hoch, dass ich etwas zurückhaltend mit der Integration in meine FHEM-Hauptserver bin. Auch verhindert diese Komplexität, dass Einfachnutzer oder Anfänger es installieren.
Es wäre schön, wenn man das Ganze auf einen eigenen Raspberry Pi auslagern könnte. Dafür bräuchten wir natürlich Mechanismen, mit denen dieser SolarServer aus anderen FHEM-Instanzen die notwendigen Daten erhält. Das geht eigentlich mit FHEM2FHEM ganz gut, solche "ausgelagerten Subsysteme" betreibe ich schon mehrfach. Es besteht aber auch die Möglichkeit, das einfach über REST von anderen System zu holen.
Das hätte noch einen weiteren Bonus in sich: Man könnte eine komplette virtuelle Maschine zur Verfügung stellen, die alle notwendigen Softwarekomponenten beinhaltet. Und, das ist der Punkt, auch ganz unabhängig von einer Hausautomation laufen würde.
Nun ist das ja mit Wünsche so eine Sache: Man muss schon etwas dafür tun. Werde ich, mal sehen, ob das in die Richtung zu entwickeln ist.
LG
pah
Darüber hinaus hätte ich gerne Prognose und Steuerung, sowie gerne auch die Visualisierung getrennt.
Ja, ich weiß, das habe ich bereits geschrieben, aber es scheint ja neuen Wind zu geben ;D
VG Christian
Hallo Heiko,
ich habe die Updates installiert und forecastDataPrecision auf "high" gesetzt.
Der RPi 3 B+ kommt damit an seine Grenzen (Out of memory).
2024.02.23 10:13:39 5: DWD_Duisburg_Baerl: GetForecast START (PID 2668)
2024.02.23 10:13:39 5: DWD_Duisburg_Baerl: GetForecast END
2024.02.23 10:13:39 5: DWD_Duisburg_Baerl: GetForecastStart START (PID 2824): https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024.02.23 10:13:42 5: DWD_Duisburg_Baerl: ProcessForecast START
2024.02.23 10:13:42 5: DWD_Duisburg_Baerl: ProcessForecast: data received, decoding ...
Out of memory!
2024.02.23 10:13:57 3: DWD_Duisburg_Baerl: GetForecastAbort ERROR: downloading and processing weather forecast data failed (Process died prematurely)
2024.02.23 10:13:57 5: DWD_Duisburg_Baerl: RotateForecast: START 0 day(s) exist
2024.02.23 10:13:57 3: DWD_Duisburg_Baerl: RotateForecast: station has changed, deleting exisiting readings
2024.02.23 10:13:57 5: DWD_Duisburg_Baerl: RotateForecast: END 0 day(s) remain
2024.02.23 10:15:40 5: DWD_Duisburg_Baerl: Timer START
2024.02.23 10:15:40 5: DWD_Duisburg_Baerl: GetForecast START (PID 2668)
2024.02.23 10:15:40 5: DWD_Duisburg_Baerl: GetForecast END
2024.02.23 10:15:40 5: DWD_Duisburg_Baerl: Timer END
$ free -h
total used free shared buff/cache available
Mem: 926M 225M 628M 8,8M 72M 642M
Swap: 99M 48M 51M
Ich finde es gut die stündlichen Daten zu nutzen und habe auch die drei möglichen DWD Stationen konfiguriert.
Grüße,
Guido.
Hallo Guido,
bei (zu) wenig RAM kann das passieren zumal es ja auch noch andere Module gibt die temporär paralle Prozesse (BlockingCall) nutzen. Im DWD Thread kannst du verfolgen wann mit einer Optimierung bzgl. der Ressourcen zu rechnen ist. Das steht auf dem Plan.
Für den Moment würde ich dir raten ein DWD Device mit den Rad1h und Wetterelementen auf "high" zu setzen und die anderen auf "low" zu belassen. Du kannst auch erwägen mit nur einem ctrlWeatherDevX zu arbeiten (mit Auflösung "high").
LG
Hallo pah,
ZitatEs wäre schön, wenn man das Ganze auf einen eigenen Raspberry Pi auslagern könnte. Dafür bräuchten wir natürlich Mechanismen, mit denen dieser SolarServer aus anderen FHEM-Instanzen die notwendigen Daten erhält. Das geht eigentlich mit FHEM2FHEM ganz gut, solche "ausgelagerten Subsysteme" betreibe ich schon mehrfach. Es besteht aber auch die Möglichkeit, das einfach über REST von anderen System zu holen.
Die Schnittstellenthematik sehe ich wie du. Eine Erweiterung der Datenbeschaffung auf andere FHEM-Instanzen (oder vllt. sogar FHEM fremde) Systeme würde einen Mehrwert für den User und die Anwendung bedeuten.
An dem Thema bleibe ich auch mal dran, war bei mir noch nicht in der Prio so hoch.
LG,
Heiko
Hallo Christian,
ZitatJa, ich weiß, das habe ich bereits geschrieben, aber es scheint ja neuen Wind zu geben ;D
:) ... es geht um Schnittstellen, bzw. der Öffnung an angrenzende Systeme.
Lesend in das Modul zu greifen ist bereits jetzt gegeben. Es gibt für den User die Möglichkeit auf die internen Daten (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Schnittstelle_f%C3%BCr_Modulautoren_bzw._eigenen_Code) des Modul zuzugreifen, in eigenen Anwendungen zu verwenden und sich eine eigene Grafik, Batteriesteuerung, whatever aufzubauen.
Das Modul selbst ist als integrierte Anwendung gestaltet, wobei der Nutzer sich über die relevanten Attribute interessierende Bereiche auswählen/abwählen kann.
Es wird diesbzüglich immer verschiedene, durchaus gerechtfertigte und respektierte, Meinungen geben. Jedoch ist mein Ansatz eine integrierte Anwendung den ich genau so wünsche und verfolge. :)
Die Gestaltung von Schnittstellen ist dabei absolut gewünscht und steht auch im Fokus.
LG,
Heiko
Hallo Heiko,
ich bekomme kein Balkendiagramm angezeigt.
solarForecast.png
Hintergrund: Hatte längere Zeit fhem laufen lassen, irgendwann in Ende 2023 habe ich Updates gemacht. Schon da fiel mir das auf. Nun habe ich alles auf den neuesten Stand gebracht aber es bleibt leider so.
Also: fhem aktuell, 76_solarForecast aus dem Contrib zeigt FVersion 1.16.2, DWD-Modul wie in den letzten Posts angepasst.
Im Log gibts keine Fehler (mehr): das AI-Modul habe ich installiert. Es gibt solche Zeilen:
mySolarPowerForecast - new Complex correction factor for hour 17 calculated: 1.59 (old: 1.51)es scheint also etwas zu arbeiten.
Ich habe auch sämtliche Parameter der PV kontrolliert, das scheint zu passen.
Das ist die Ausgabe des Checks:
solarForecast_CheckAusgabe.png
Da werde ich aus dem ersten Hinweis nicht schlau.
Der zweite Hinweis ist egal, da ich FTUI nicht (mehr) nutze. Einzig in Astromodul für die Mondphasenbilder kommt der Name vor, aber wie gesagt, das ist nicht relevant.
Hast Du eine Idee wo ich da ansetzten kann?
Soll ich noch ein list dranhängen?
Vielen Dank schon mal
Sany
Hi Heiko,
ich habe aus deinem Contrib das DWD Modul heruntergeladen und mein DWD Device auf forecastPrecision high gestellt aber danach fehlen alle Daten im DWD Device und ich habe diese Meldung im Log:
forecast error: downloading and processing weather forecast data failed (Timeout: process terminated)
Habe ich etwas falsch verstanden?
Ich habe eine L979 Station, geht das bei der nicht?
Meine zweit Station ist eine X265.
Auch bei dieser kommt diese Meldung.
Was kann ich noch schauen, oder sind meine Stationen ungeeignet?
Was kann ich tun?
Danke,
Stefan
Hallo Sany,
ZitatDa werde ich aus dem ersten Hinweis nicht schlau.
Das ist nur der Hinweis auf deutsch umstellen zu können mit ctrlLanguage oder global language.
Ja, hänge mal ein List an. Wahrscheinlich ist nur ein Attribut falsch gesetzt. Tippe auf graphicBeam1Content oder graphicLayoutType.
Hallo Stefan,
Zitatforecast error: downloading and processing weather forecast data failed (Timeout: process terminated)
Habe ich etwas falsch verstanden?
Ich habe eine L979 Station, geht das bei der nicht?
Das ist ein technischer Fehler. Hast du genügend RAM? Unter 4 GB (vllt. 3GB) wird es evtl. schwierig.
Meiner VM hatte ich mal 2 GB gegeben zum Test. Das geht dann meistens nicht. Die DWD Dateil ist ca. 700MB groß.
EDIT: du kannst forecastDataPrecision auf *low* stellen. Dann ist es wie vorher.
Ich habe einen Raspberry 4 mit 4GB Speicher.
Es sind zur Zeit 887 MB benutzt der rest ist frei.
Das sollte doch eigentlich reichen.
Wir kann ich denn mehr infos zu dem prozess bekommen und warum er aufgibt?
Ich kann meinem Raspberry mal noch 4GB Swap Speicher spendieren habe eine SSD dran.
Das sollte doch locker auf dem 4er gehen.
Gruß,
Stefan
Hallo Heiko,
hier das list: (copy for forum.fhem.de)
define mySolarPowerForecast SolarForecast
attr mySolarPowerForecast DbLogExclude state
attr mySolarPowerForecast affect70percentRule 1
attr mySolarPowerForecast comment neuestes modul im contrib\
\
"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"\
in die fhem-Zeile incl. Anführungszeichen, dananch fhem Neustart
attr mySolarPowerForecast consumer01 Wally_c type=charger power=11000 icon=electric_car_charger pcurr=power:W energy_total:Wh mode=can
attr mySolarPowerForecast ctrlDebug 0
attr mySolarPowerForecast ctrlWeatherDev1 WxDWDOpenData
attr mySolarPowerForecast disable 0
attr mySolarPowerForecast event-on-change-reading .*
attr mySolarPowerForecast flowGraphicAnimate 1
attr mySolarPowerForecast flowGraphicSize 300
attr mySolarPowerForecast graphicBeam1MaxVal 14000
attr mySolarPowerForecast graphicBeam2Color DDFF00
attr mySolarPowerForecast graphicBeam2Content pvReal
attr mySolarPowerForecast graphicBeamWidth 12
attr mySolarPowerForecast graphicEnergyUnit kWh
attr mySolarPowerForecast graphicHistoryHour -12
attr mySolarPowerForecast graphicHourCount 24
attr mySolarPowerForecast graphicLayoutType double
attr mySolarPowerForecast graphicShowDiff top
attr mySolarPowerForecast graphicWeatherColor DDDDDD
attr mySolarPowerForecast room PV
# FUUID 60b9d0ce-f33f-dac6-f3f4-04e3f152b65d042c
# FVERSION 1.16.2
# LCACHEFILE last write time: 18:10:46 File: ./FHEM/FhemUtils/PVH_SolarForecast_mySolarPowerForecast
# MODE Automatic - next Cycletime: 18:13:33
# MODEL DWD
# NAME mySolarPowerForecast
# NOTIFYDEV Wally_c
# NR 651
# NTFY_ORDER 50-mySolarPowerForecast
# STATE updated
# TYPE SolarForecast
# eventCount 417
# HELPER:
# FW WEBtablet
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL mySolarPowerForecast
# SPGDEV mySolarPowerForecast
# SPGROOM PV
# VERSION 1.16.2
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.1
# Helper:
# DBLOG:
# Current_AutarkyRate:
# myMariaDB:
# TIME 1708707152.60817
# VALUE 0
# Current_Consumption:
# myMariaDB:
# TIME 1708708343.74057
# VALUE 540
# Current_GridConsumption:
# myMariaDB:
# TIME 1708708343.74057
# VALUE 540
# Current_GridFeedIn:
# myMariaDB:
# TIME 1708705396.87935
# VALUE 0
# Current_PV:
# myMariaDB:
# TIME 1708707152.60817
# VALUE 0
# Current_SelfConsumption:
# myMariaDB:
# TIME 1708707152.60817
# VALUE 0
# Current_SelfConsumptionRate:
# myMariaDB:
# TIME 1708707152.60817
# VALUE 0
# Current_Surplus:
# myMariaDB:
# TIME 1708705396.87935
# VALUE 0
# LastHourGridconsumptionReal:
# myMariaDB:
# TIME 1708707607.3506
# VALUE 173
# LastHourPVforecast:
# myMariaDB:
# TIME 1708707607.3506
# VALUE 338
# LastHourPVreal:
# myMariaDB:
# TIME 1708707607.3506
# VALUE 491
# NextHours_Sum01_PVforecast:
# myMariaDB:
# TIME 1708707573.87008
# VALUE 0
# NextHours_Sum02_PVforecast:
# myMariaDB:
# TIME 1708707573.87008
# VALUE 0
# NextHours_Sum03_PVforecast:
# myMariaDB:
# TIME 1708707573.87008
# VALUE 0
# NextHours_Sum04_ConsumptionForecast:
# myMariaDB:
# TIME 1708708343.74057
# VALUE 2801
# NextHours_Sum04_PVforecast:
# myMariaDB:
# TIME 1708707573.87008
# VALUE 0
# RestOfDayConsumptionForecast:
# myMariaDB:
# TIME 1708708343.74057
# VALUE 3586
# RestOfDayPVforecast:
# myMariaDB:
# TIME 1708707573.87008
# VALUE 0
# Today_Hour15_GridFeedIn:
# myMariaDB:
# TIME 1708696762.51903
# VALUE 3924
# Today_Hour15_PVreal:
# myMariaDB:
# TIME 1708696762.51903
# VALUE 4253
# Today_Hour16_GridConsumption:
# myMariaDB:
# TIME 1708696807.50216
# VALUE 0
# Today_Hour16_GridFeedIn:
# myMariaDB:
# TIME 1708700389.49266
# VALUE 3108
# Today_Hour16_PVreal:
# myMariaDB:
# TIME 1708700389.49266
# VALUE 3385
# Today_Hour17_GridConsumption:
# myMariaDB:
# TIME 1708700407.4227
# VALUE 0
# Today_Hour17_GridFeedIn:
# myMariaDB:
# TIME 1708703990.27597
# VALUE 2008
# Today_Hour17_PVreal:
# myMariaDB:
# TIME 1708703990.27597
# VALUE 2379
# Today_Hour18_GridConsumption:
# myMariaDB:
# TIME 1708707573.87008
# VALUE 173
# Today_Hour18_GridFeedIn:
# myMariaDB:
# TIME 1708705327.23741
# VALUE 260
# Today_Hour18_PVreal:
# myMariaDB:
# TIME 1708707083.39775
# VALUE 491
# Today_Hour19_GridConsumption:
# myMariaDB:
# TIME 1708708343.74057
# VALUE 96
# Today_Hour19_GridFeedIn:
# myMariaDB:
# TIME 1708707607.3506
# VALUE 0
# Today_Hour19_PVreal:
# myMariaDB:
# TIME 1708707607.3506
# VALUE 0
# Today_PVdeviation:
# myMariaDB:
# TIME 1708707362.55403
# VALUE 12.27
# Today_PVreal:
# myMariaDB:
# TIME 1708707152.60817
# VALUE 24433
# Tomorrow_PVforecast:
# myMariaDB:
# TIME 1708707643.71962
# VALUE 23621
# nextCycletime:
# myMariaDB:
# TIME 1708708343.74057
# VALUE 18:13:33
# pvCorrectionFactor_15:
# myMariaDB:
# TIME 1708696807.50216
# VALUE 0.95 (automatic - old factor: 0.92, days in range: 18)
# pvCorrectionFactor_15_autocalc:
# myMariaDB:
# TIME 1708696807.50216
# VALUE done
# pvCorrectionFactor_16:
# myMariaDB:
# TIME 1708700407.4227
# VALUE 0.95 (automatic - old factor: 0.91, days in range: 18)
# pvCorrectionFactor_16_autocalc:
# myMariaDB:
# TIME 1708700407.4227
# VALUE done
# pvCorrectionFactor_17:
# myMariaDB:
# TIME 1708704007.56064
# VALUE 0.98 (automatic - old factor: 0.88, days in range: 18)
# pvCorrectionFactor_17_autocalc:
# myMariaDB:
# TIME 1708704007.56064
# VALUE done
# pvCorrectionFactor_18:
# myMariaDB:
# TIME 1708707607.3506
# VALUE 0.90 (automatic - old factor: 0.78, days in range: 14)
# pvCorrectionFactor_18_autocalc:
# myMariaDB:
# TIME 1708707607.3506
# VALUE done
# OLDREADINGS:
# READINGS:
# 2024-02-23 18:12:23 Current_AutarkyRate 0 %
# 2024-02-23 18:12:23 Current_Consumption 540 W
# 2024-02-23 18:12:23 Current_GridConsumption 540 W
# 2024-02-23 18:12:23 Current_GridFeedIn 0 W
# 2024-02-23 18:12:23 Current_PV 0 W
# 2024-02-23 18:12:23 Current_SelfConsumption 0 W
# 2024-02-23 18:12:23 Current_SelfConsumptionRate 0 %
# 2024-02-23 18:12:23 Current_Surplus 0 W
# 2024-02-23 18:00:00 LastHourGridconsumptionReal 173 Wh
# 2024-02-23 18:00:00 LastHourPVforecast 338 Wh
# 2024-02-23 18:00:00 LastHourPVreal 491 Wh
# 2024-02-23 18:12:23 NextHours_Sum01_PVforecast 0 Wh
# 2024-02-23 18:12:23 NextHours_Sum02_PVforecast 0 Wh
# 2024-02-23 18:12:23 NextHours_Sum03_PVforecast 0 Wh
# 2024-02-23 18:12:23 NextHours_Sum04_ConsumptionForecast 2801 Wh
# 2024-02-23 18:12:23 NextHours_Sum04_PVforecast 0 Wh
# 2024-02-23 18:12:23 RestOfDayConsumptionForecast 3586 Wh
# 2024-02-23 18:12:23 RestOfDayPVforecast 0 Wh
# 2024-02-23 00:59:49 Today_Hour01_GridConsumption 376 Wh
# 2024-02-23 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2024-02-23 00:59:49 Today_Hour01_PVreal 0 Wh
# 2024-02-23 01:59:49 Today_Hour02_GridConsumption 401 Wh
# 2024-02-23 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2024-02-23 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-02-23 02:59:49 Today_Hour03_GridConsumption 392 Wh
# 2024-02-23 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-02-23 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-02-23 03:59:50 Today_Hour04_GridConsumption 379 Wh
# 2024-02-23 03:59:50 Today_Hour04_GridFeedIn 0 Wh
# 2024-02-23 03:59:50 Today_Hour04_PVreal 0 Wh
# 2024-02-23 04:59:49 Today_Hour05_GridConsumption 406 Wh
# 2024-02-23 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2024-02-23 04:59:49 Today_Hour05_PVreal 0 Wh
# 2024-02-23 05:59:49 Today_Hour06_GridConsumption 399 Wh
# 2024-02-23 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2024-02-23 05:59:49 Today_Hour06_PVreal 0 Wh
# 2024-02-23 06:59:50 Today_Hour07_GridConsumption 398 Wh
# 2024-02-23 06:59:50 Today_Hour07_GridFeedIn 0 Wh
# 2024-02-23 06:59:50 Today_Hour07_PVreal 0 Wh
# 2024-02-23 07:59:49 Today_Hour08_GridConsumption 440 Wh
# 2024-02-23 07:59:49 Today_Hour08_GridFeedIn 0 Wh
# 2024-02-23 07:59:49 Today_Hour08_PVforecast 165 Wh
# 2024-02-23 07:59:49 Today_Hour08_PVreal 9 Wh
# 2024-02-23 08:59:49 Today_Hour09_GridConsumption 212 Wh
# 2024-02-23 08:59:49 Today_Hour09_GridFeedIn 80 Wh
# 2024-02-23 08:59:49 Today_Hour09_PVforecast 1012 Wh
# 2024-02-23 08:59:49 Today_Hour09_PVreal 309 Wh
# 2024-02-23 09:59:50 Today_Hour10_GridConsumption 0 Wh
# 2024-02-23 09:59:50 Today_Hour10_GridFeedIn 924 Wh
# 2024-02-23 09:59:50 Today_Hour10_PVforecast 2136 Wh
# 2024-02-23 09:59:50 Today_Hour10_PVreal 1299 Wh
# 2024-02-23 10:59:49 Today_Hour11_GridConsumption 7 Wh
# 2024-02-23 10:59:49 Today_Hour11_GridFeedIn 1436 Wh
# 2024-02-23 10:59:49 Today_Hour11_PVforecast 3080 Wh
# 2024-02-23 10:59:49 Today_Hour11_PVreal 1854 Wh
# 2024-02-23 11:59:51 Today_Hour12_GridConsumption 0 Wh
# 2024-02-23 11:59:51 Today_Hour12_GridFeedIn 2756 Wh
# 2024-02-23 11:59:51 Today_Hour12_PVforecast 3774 Wh
# 2024-02-23 11:59:51 Today_Hour12_PVreal 3120 Wh
# 2024-02-23 12:59:50 Today_Hour13_GridConsumption 0 Wh
# 2024-02-23 12:59:50 Today_Hour13_GridFeedIn 2436 Wh
# 2024-02-23 12:59:50 Today_Hour13_PVforecast 4344 Wh
# 2024-02-23 12:59:50 Today_Hour13_PVreal 2815 Wh
# 2024-02-23 13:59:49 Today_Hour14_GridConsumption 0 Wh
# 2024-02-23 13:59:49 Today_Hour14_GridFeedIn 4084 Wh
# 2024-02-23 13:59:49 Today_Hour14_PVforecast 3983 Wh
# 2024-02-23 13:59:49 Today_Hour14_PVreal 4519 Wh
# 2024-02-23 14:59:50 Today_Hour15_GridConsumption 0 Wh
# 2024-02-23 14:59:50 Today_Hour15_GridFeedIn 3924 Wh
# 2024-02-23 14:59:50 Today_Hour15_PVforecast 4592 Wh
# 2024-02-23 14:59:50 Today_Hour15_PVreal 4253 Wh
# 2024-02-23 15:59:49 Today_Hour16_GridConsumption 0 Wh
# 2024-02-23 15:59:49 Today_Hour16_GridFeedIn 3108 Wh
# 2024-02-23 15:59:49 Today_Hour16_PVforecast 2584 Wh
# 2024-02-23 15:59:49 Today_Hour16_PVreal 3385 Wh
# 2024-02-23 16:59:52 Today_Hour17_GridConsumption 0 Wh
# 2024-02-23 16:59:52 Today_Hour17_GridFeedIn 2008 Wh
# 2024-02-23 16:59:52 Today_Hour17_PVforecast 1423 Wh
# 2024-02-23 16:59:52 Today_Hour17_PVreal 2379 Wh
# 2024-02-23 17:59:50 Today_Hour18_GridConsumption 173 Wh
# 2024-02-23 17:59:50 Today_Hour18_GridFeedIn 260 Wh
# 2024-02-23 17:59:50 Today_Hour18_PVforecast 338 Wh
# 2024-02-23 17:59:50 Today_Hour18_PVreal 491 Wh
# 2024-02-23 18:12:23 Today_Hour19_GridConsumption 96 Wh
# 2024-02-23 18:12:23 Today_Hour19_GridFeedIn 0 Wh
# 2024-02-23 18:12:23 Today_Hour19_PVreal 0 Wh
# 2024-02-23 18:12:23 Today_MaxPVforecast 4592 Wh
# 2024-02-23 18:12:23 Today_MaxPVforecastTime 2024-02-23 14:00:00
# 2024-02-23 18:12:23 Today_PVdeviation 12.27 %
# 2024-02-23 18:12:23 Today_PVforecast 27431 Wh
# 2024-02-23 17:52:32 Today_PVreal 24433 Wh
# 2024-02-23 18:12:23 Today_SunRise 07:21
# 2024-02-23 18:12:23 Today_SunSet 17:56
# 2024-02-23 18:12:23 Tomorrow_ConsumptionForecast 13019 Wh
# 2024-02-23 18:12:23 Tomorrow_PVforecast 23621 Wh
# 2024-02-23 18:12:23 Tomorrow_SunRise 07:19
# 2024-02-23 18:12:23 Tomorrow_SunSet 17:58
# 2024-02-23 18:12:23 consumer01 name='Wally_c' state='unknown' mode='can' planningstate='suspended' info='max surplus forecast too low'
# 2024-02-23 18:12:23 consumer01_currentPower 0 W
# 2022-02-14 14:16:17 currentInverterDev di_UI_CasaEnergyMeter pv=pwr_Ertrag:W etotal=energy_ErtragTotal:Wh
# 2022-02-14 14:19:41 currentMeterDev di_UI_CasaEnergyMeter gcon=pwr_Bezug:W contotal=energy_BezugTotal:Wh gfeedin=pwr_Einspeisung:W feedtotal=energy_EinspeisungTotal:Wh
# 2024-02-22 11:26:57 currentRadiationAPI WxDWDOpenData
# 2024-02-22 11:33:21 inverterStrings NordE,SuedE,NordW,SuedW
# 2024-02-22 11:33:34 moduleAzimuth NordE=-100 SuedE=-100 NordW=80 SuedW=80
# 2024-02-22 11:34:05 moduleDeclination NordE=45 SuedE=45 SuedW=45 NordW=45
# 2024-02-22 11:34:31 modulePeakString NordE=4.8 SuedE=4.8 SuedW=4.8 NordW=4.8
# 2024-02-23 18:12:23 nextCycletime 18:13:33
# 2023-06-11 08:54:39 nextPolltime 08:55:49
# 2024-02-23 08:00:05 pvCorrectionFactor_08 1.41 (automatic - old factor: 1.91, days in range: 4)
# 2024-02-23 08:00:05 pvCorrectionFactor_08_autocalc done
# 2024-02-23 09:00:05 pvCorrectionFactor_09 1.37 (automatic - old factor: 1.51, days in range: 16)
# 2024-02-23 09:00:05 pvCorrectionFactor_09_autocalc done
# 2024-02-23 10:00:05 pvCorrectionFactor_10 1.20 (automatic - old factor: 1.26, days in range: 18)
# 2024-02-23 10:00:05 pvCorrectionFactor_10_autocalc done
# 2024-02-23 11:00:06 pvCorrectionFactor_11 1.06 (automatic - old factor: 1.10, days in range: 18)
# 2024-02-23 11:00:06 pvCorrectionFactor_11_autocalc done
# 2024-02-23 12:00:06 pvCorrectionFactor_12 1.08 (automatic - old factor: 1.10, days in range: 18)
# 2024-02-23 12:00:06 pvCorrectionFactor_12_autocalc done
# 2024-02-23 13:00:06 pvCorrectionFactor_13 1.04 (automatic - old factor: 1.08, days in range: 18)
# 2024-02-23 13:00:06 pvCorrectionFactor_13_autocalc done
# 2024-02-23 14:00:07 pvCorrectionFactor_14 1.02 (automatic - old factor: 1.01, days in range: 18)
# 2024-02-23 14:00:07 pvCorrectionFactor_14_autocalc done
# 2024-02-23 15:00:07 pvCorrectionFactor_15 0.95 (automatic - old factor: 0.92, days in range: 18)
# 2024-02-23 15:00:07 pvCorrectionFactor_15_autocalc done
# 2024-02-23 16:00:07 pvCorrectionFactor_16 0.95 (automatic - old factor: 0.91, days in range: 18)
# 2024-02-23 16:00:07 pvCorrectionFactor_16_autocalc done
# 2024-02-23 17:00:07 pvCorrectionFactor_17 0.98 (automatic - old factor: 0.88, days in range: 18)
# 2024-02-23 17:00:07 pvCorrectionFactor_17_autocalc done
# 2024-02-23 18:00:07 pvCorrectionFactor_18 0.90 (automatic - old factor: 0.78, days in range: 14)
# 2024-02-23 18:00:07 pvCorrectionFactor_18_autocalc done
# 2024-02-23 18:12:23 pvCorrectionFactor_Auto on_simple_ai
# 2024-02-23 18:12:24 state updated
#
setstate mySolarPowerForecast updated
setstate mySolarPowerForecast 2024-02-23 14:41:49 .associatedWith Wally_c WxDWDOpenData di_UI_CasaEnergyMeter
setstate mySolarPowerForecast 2024-02-23 18:12:23 .lastupdateForecastValues 1708708343
setstate mySolarPowerForecast 2024-02-23 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate mySolarPowerForecast 2024-02-23 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate mySolarPowerForecast 2024-02-23 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate mySolarPowerForecast 2024-02-23 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate mySolarPowerForecast 2024-02-23 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate mySolarPowerForecast 2024-02-23 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate mySolarPowerForecast 2024-02-23 04:00:04 .pvCorrectionFactor_04_apipercentil done
setstate mySolarPowerForecast 2024-02-23 04:00:04 .pvCorrectionFactor_04_cloudcover done
setstate mySolarPowerForecast 2024-02-23 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate mySolarPowerForecast 2024-02-23 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate mySolarPowerForecast 2024-02-23 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate mySolarPowerForecast 2024-02-23 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate mySolarPowerForecast 2024-02-23 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate mySolarPowerForecast 2024-02-23 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate mySolarPowerForecast 2024-02-23 08:00:05 .pvCorrectionFactor_08_apipercentil done
setstate mySolarPowerForecast 2024-02-23 08:00:05 .pvCorrectionFactor_08_cloudcover done
setstate mySolarPowerForecast 2024-02-23 09:00:05 .pvCorrectionFactor_09_apipercentil done
setstate mySolarPowerForecast 2024-02-23 09:00:05 .pvCorrectionFactor_09_cloudcover done
setstate mySolarPowerForecast 2024-02-23 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate mySolarPowerForecast 2024-02-23 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate mySolarPowerForecast 2024-02-23 11:00:06 .pvCorrectionFactor_11_apipercentil done
setstate mySolarPowerForecast 2024-02-23 11:00:06 .pvCorrectionFactor_11_cloudcover done
setstate mySolarPowerForecast 2024-02-23 12:00:06 .pvCorrectionFactor_12_apipercentil done
setstate mySolarPowerForecast 2024-02-23 12:00:06 .pvCorrectionFactor_12_cloudcover done
setstate mySolarPowerForecast 2024-02-23 13:00:06 .pvCorrectionFactor_13_apipercentil done
setstate mySolarPowerForecast 2024-02-23 13:00:06 .pvCorrectionFactor_13_cloudcover done
setstate mySolarPowerForecast 2024-02-23 14:00:07 .pvCorrectionFactor_14_apipercentil done
setstate mySolarPowerForecast 2024-02-23 14:00:07 .pvCorrectionFactor_14_cloudcover done
setstate mySolarPowerForecast 2024-02-23 15:00:07 .pvCorrectionFactor_15_apipercentil done
setstate mySolarPowerForecast 2024-02-23 15:00:07 .pvCorrectionFactor_15_cloudcover done
setstate mySolarPowerForecast 2024-02-23 16:00:07 .pvCorrectionFactor_16_apipercentil done
setstate mySolarPowerForecast 2024-02-23 16:00:07 .pvCorrectionFactor_16_cloudcover done
setstate mySolarPowerForecast 2024-02-23 17:00:07 .pvCorrectionFactor_17_apipercentil done
setstate mySolarPowerForecast 2024-02-23 17:00:07 .pvCorrectionFactor_17_cloudcover done
setstate mySolarPowerForecast 2024-02-23 18:00:07 .pvCorrectionFactor_18_apipercentil done
setstate mySolarPowerForecast 2024-02-23 18:00:07 .pvCorrectionFactor_18_cloudcover done
setstate mySolarPowerForecast 2024-02-23 18:12:23 .pvCorrectionFactor_Auto_Soll on_simple_ai
setstate mySolarPowerForecast 2024-02-23 01:00:04 .signaldone_01 done
setstate mySolarPowerForecast 2024-02-23 02:00:04 .signaldone_02 done
setstate mySolarPowerForecast 2024-02-23 03:00:04 .signaldone_03 done
setstate mySolarPowerForecast 2024-02-23 04:00:04 .signaldone_04 done
setstate mySolarPowerForecast 2024-02-23 05:00:05 .signaldone_05 done
setstate mySolarPowerForecast 2024-02-23 06:00:04 .signaldone_06 done
setstate mySolarPowerForecast 2024-02-23 07:00:04 .signaldone_07 done
setstate mySolarPowerForecast 2024-02-23 08:00:05 .signaldone_08 done
setstate mySolarPowerForecast 2024-02-23 09:00:05 .signaldone_09 done
setstate mySolarPowerForecast 2024-02-23 10:00:05 .signaldone_10 done
setstate mySolarPowerForecast 2024-02-23 11:00:06 .signaldone_11 done
setstate mySolarPowerForecast 2024-02-23 12:00:06 .signaldone_12 done
setstate mySolarPowerForecast 2024-02-23 13:00:06 .signaldone_13 done
setstate mySolarPowerForecast 2024-02-23 14:00:07 .signaldone_14 done
setstate mySolarPowerForecast 2024-02-23 15:00:07 .signaldone_15 done
setstate mySolarPowerForecast 2024-02-23 16:00:07 .signaldone_16 done
setstate mySolarPowerForecast 2024-02-23 17:00:07 .signaldone_17 done
setstate mySolarPowerForecast 2024-02-23 18:00:07 .signaldone_18 done
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_AutarkyRate 0 %
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_Consumption 540 W
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_GridConsumption 540 W
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_GridFeedIn 0 W
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_PV 0 W
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_SelfConsumption 0 W
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_SelfConsumptionRate 0 %
setstate mySolarPowerForecast 2024-02-23 18:12:23 Current_Surplus 0 W
setstate mySolarPowerForecast 2024-02-23 18:00:00 LastHourGridconsumptionReal 173 Wh
setstate mySolarPowerForecast 2024-02-23 18:00:00 LastHourPVforecast 338 Wh
setstate mySolarPowerForecast 2024-02-23 18:00:00 LastHourPVreal 491 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 NextHours_Sum01_PVforecast 0 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 NextHours_Sum02_PVforecast 0 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 NextHours_Sum03_PVforecast 0 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 NextHours_Sum04_ConsumptionForecast 2801 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 NextHours_Sum04_PVforecast 0 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 RestOfDayConsumptionForecast 3586 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 RestOfDayPVforecast 0 Wh
setstate mySolarPowerForecast 2024-02-23 00:59:49 Today_Hour01_GridConsumption 376 Wh
setstate mySolarPowerForecast 2024-02-23 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 00:59:49 Today_Hour01_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 01:59:49 Today_Hour02_GridConsumption 401 Wh
setstate mySolarPowerForecast 2024-02-23 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 01:59:49 Today_Hour02_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 02:59:49 Today_Hour03_GridConsumption 392 Wh
setstate mySolarPowerForecast 2024-02-23 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 02:59:49 Today_Hour03_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 03:59:50 Today_Hour04_GridConsumption 379 Wh
setstate mySolarPowerForecast 2024-02-23 03:59:50 Today_Hour04_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 03:59:50 Today_Hour04_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 04:59:49 Today_Hour05_GridConsumption 406 Wh
setstate mySolarPowerForecast 2024-02-23 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 04:59:49 Today_Hour05_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 05:59:49 Today_Hour06_GridConsumption 399 Wh
setstate mySolarPowerForecast 2024-02-23 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 05:59:49 Today_Hour06_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 06:59:50 Today_Hour07_GridConsumption 398 Wh
setstate mySolarPowerForecast 2024-02-23 06:59:50 Today_Hour07_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 06:59:50 Today_Hour07_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 07:59:49 Today_Hour08_GridConsumption 440 Wh
setstate mySolarPowerForecast 2024-02-23 07:59:49 Today_Hour08_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 07:59:49 Today_Hour08_PVforecast 165 Wh
setstate mySolarPowerForecast 2024-02-23 07:59:49 Today_Hour08_PVreal 9 Wh
setstate mySolarPowerForecast 2024-02-23 08:59:49 Today_Hour09_GridConsumption 212 Wh
setstate mySolarPowerForecast 2024-02-23 08:59:49 Today_Hour09_GridFeedIn 80 Wh
setstate mySolarPowerForecast 2024-02-23 08:59:49 Today_Hour09_PVforecast 1012 Wh
setstate mySolarPowerForecast 2024-02-23 08:59:49 Today_Hour09_PVreal 309 Wh
setstate mySolarPowerForecast 2024-02-23 09:59:50 Today_Hour10_GridConsumption 0 Wh
setstate mySolarPowerForecast 2024-02-23 09:59:50 Today_Hour10_GridFeedIn 924 Wh
setstate mySolarPowerForecast 2024-02-23 09:59:50 Today_Hour10_PVforecast 2136 Wh
setstate mySolarPowerForecast 2024-02-23 09:59:50 Today_Hour10_PVreal 1299 Wh
setstate mySolarPowerForecast 2024-02-23 10:59:49 Today_Hour11_GridConsumption 7 Wh
setstate mySolarPowerForecast 2024-02-23 10:59:49 Today_Hour11_GridFeedIn 1436 Wh
setstate mySolarPowerForecast 2024-02-23 10:59:49 Today_Hour11_PVforecast 3080 Wh
setstate mySolarPowerForecast 2024-02-23 10:59:49 Today_Hour11_PVreal 1854 Wh
setstate mySolarPowerForecast 2024-02-23 11:59:51 Today_Hour12_GridConsumption 0 Wh
setstate mySolarPowerForecast 2024-02-23 11:59:51 Today_Hour12_GridFeedIn 2756 Wh
setstate mySolarPowerForecast 2024-02-23 11:59:51 Today_Hour12_PVforecast 3774 Wh
setstate mySolarPowerForecast 2024-02-23 11:59:51 Today_Hour12_PVreal 3120 Wh
setstate mySolarPowerForecast 2024-02-23 12:59:50 Today_Hour13_GridConsumption 0 Wh
setstate mySolarPowerForecast 2024-02-23 12:59:50 Today_Hour13_GridFeedIn 2436 Wh
setstate mySolarPowerForecast 2024-02-23 12:59:50 Today_Hour13_PVforecast 4344 Wh
setstate mySolarPowerForecast 2024-02-23 12:59:50 Today_Hour13_PVreal 2815 Wh
setstate mySolarPowerForecast 2024-02-23 13:59:49 Today_Hour14_GridConsumption 0 Wh
setstate mySolarPowerForecast 2024-02-23 13:59:49 Today_Hour14_GridFeedIn 4084 Wh
setstate mySolarPowerForecast 2024-02-23 13:59:49 Today_Hour14_PVforecast 3983 Wh
setstate mySolarPowerForecast 2024-02-23 13:59:49 Today_Hour14_PVreal 4519 Wh
setstate mySolarPowerForecast 2024-02-23 14:59:50 Today_Hour15_GridConsumption 0 Wh
setstate mySolarPowerForecast 2024-02-23 14:59:50 Today_Hour15_GridFeedIn 3924 Wh
setstate mySolarPowerForecast 2024-02-23 14:59:50 Today_Hour15_PVforecast 4592 Wh
setstate mySolarPowerForecast 2024-02-23 14:59:50 Today_Hour15_PVreal 4253 Wh
setstate mySolarPowerForecast 2024-02-23 15:59:49 Today_Hour16_GridConsumption 0 Wh
setstate mySolarPowerForecast 2024-02-23 15:59:49 Today_Hour16_GridFeedIn 3108 Wh
setstate mySolarPowerForecast 2024-02-23 15:59:49 Today_Hour16_PVforecast 2584 Wh
setstate mySolarPowerForecast 2024-02-23 15:59:49 Today_Hour16_PVreal 3385 Wh
setstate mySolarPowerForecast 2024-02-23 16:59:52 Today_Hour17_GridConsumption 0 Wh
setstate mySolarPowerForecast 2024-02-23 16:59:52 Today_Hour17_GridFeedIn 2008 Wh
setstate mySolarPowerForecast 2024-02-23 16:59:52 Today_Hour17_PVforecast 1423 Wh
setstate mySolarPowerForecast 2024-02-23 16:59:52 Today_Hour17_PVreal 2379 Wh
setstate mySolarPowerForecast 2024-02-23 17:59:50 Today_Hour18_GridConsumption 173 Wh
setstate mySolarPowerForecast 2024-02-23 17:59:50 Today_Hour18_GridFeedIn 260 Wh
setstate mySolarPowerForecast 2024-02-23 17:59:50 Today_Hour18_PVforecast 338 Wh
setstate mySolarPowerForecast 2024-02-23 17:59:50 Today_Hour18_PVreal 491 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_Hour19_GridConsumption 96 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_Hour19_GridFeedIn 0 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_Hour19_PVreal 0 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_MaxPVforecast 4592 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_MaxPVforecastTime 2024-02-23 14:00:00
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_PVdeviation 12.27 %
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_PVforecast 27431 Wh
setstate mySolarPowerForecast 2024-02-23 17:52:32 Today_PVreal 24433 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_SunRise 07:21
setstate mySolarPowerForecast 2024-02-23 18:12:23 Today_SunSet 17:56
setstate mySolarPowerForecast 2024-02-23 18:12:23 Tomorrow_ConsumptionForecast 13019 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Tomorrow_PVforecast 23621 Wh
setstate mySolarPowerForecast 2024-02-23 18:12:23 Tomorrow_SunRise 07:19
setstate mySolarPowerForecast 2024-02-23 18:12:23 Tomorrow_SunSet 17:58
setstate mySolarPowerForecast 2024-02-23 18:12:23 consumer01 name='Wally_c' state='unknown' mode='can' planningstate='suspended' info='max surplus forecast too low'
setstate mySolarPowerForecast 2024-02-23 18:12:23 consumer01_currentPower 0 W
setstate mySolarPowerForecast 2022-02-14 14:16:17 currentInverterDev di_UI_CasaEnergyMeter pv=pwr_Ertrag:W etotal=energy_ErtragTotal:Wh
setstate mySolarPowerForecast 2022-02-14 14:19:41 currentMeterDev di_UI_CasaEnergyMeter gcon=pwr_Bezug:W contotal=energy_BezugTotal:Wh gfeedin=pwr_Einspeisung:W feedtotal=energy_EinspeisungTotal:Wh
setstate mySolarPowerForecast 2024-02-22 11:26:57 currentRadiationAPI WxDWDOpenData
setstate mySolarPowerForecast 2024-02-22 11:33:21 inverterStrings NordE,SuedE,NordW,SuedW
setstate mySolarPowerForecast 2024-02-22 11:33:34 moduleAzimuth NordE=-100 SuedE=-100 NordW=80 SuedW=80
setstate mySolarPowerForecast 2024-02-22 11:34:05 moduleDeclination NordE=45 SuedE=45 SuedW=45 NordW=45
setstate mySolarPowerForecast 2024-02-22 11:34:31 modulePeakString NordE=4.8 SuedE=4.8 SuedW=4.8 NordW=4.8
setstate mySolarPowerForecast 2024-02-23 18:12:23 nextCycletime 18:13:33
setstate mySolarPowerForecast 2023-06-11 08:54:39 nextPolltime 08:55:49
setstate mySolarPowerForecast 2024-02-23 08:00:05 pvCorrectionFactor_08 1.41 (automatic - old factor: 1.91, days in range: 4)
setstate mySolarPowerForecast 2024-02-23 08:00:05 pvCorrectionFactor_08_autocalc done
setstate mySolarPowerForecast 2024-02-23 09:00:05 pvCorrectionFactor_09 1.37 (automatic - old factor: 1.51, days in range: 16)
setstate mySolarPowerForecast 2024-02-23 09:00:05 pvCorrectionFactor_09_autocalc done
setstate mySolarPowerForecast 2024-02-23 10:00:05 pvCorrectionFactor_10 1.20 (automatic - old factor: 1.26, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 10:00:05 pvCorrectionFactor_10_autocalc done
setstate mySolarPowerForecast 2024-02-23 11:00:06 pvCorrectionFactor_11 1.06 (automatic - old factor: 1.10, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 11:00:06 pvCorrectionFactor_11_autocalc done
setstate mySolarPowerForecast 2024-02-23 12:00:06 pvCorrectionFactor_12 1.08 (automatic - old factor: 1.10, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 12:00:06 pvCorrectionFactor_12_autocalc done
setstate mySolarPowerForecast 2024-02-23 13:00:06 pvCorrectionFactor_13 1.04 (automatic - old factor: 1.08, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 13:00:06 pvCorrectionFactor_13_autocalc done
setstate mySolarPowerForecast 2024-02-23 14:00:07 pvCorrectionFactor_14 1.02 (automatic - old factor: 1.01, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 14:00:07 pvCorrectionFactor_14_autocalc done
setstate mySolarPowerForecast 2024-02-23 15:00:07 pvCorrectionFactor_15 0.95 (automatic - old factor: 0.92, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 15:00:07 pvCorrectionFactor_15_autocalc done
setstate mySolarPowerForecast 2024-02-23 16:00:07 pvCorrectionFactor_16 0.95 (automatic - old factor: 0.91, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 16:00:07 pvCorrectionFactor_16_autocalc done
setstate mySolarPowerForecast 2024-02-23 17:00:07 pvCorrectionFactor_17 0.98 (automatic - old factor: 0.88, days in range: 18)
setstate mySolarPowerForecast 2024-02-23 17:00:07 pvCorrectionFactor_17_autocalc done
setstate mySolarPowerForecast 2024-02-23 18:00:07 pvCorrectionFactor_18 0.90 (automatic - old factor: 0.78, days in range: 14)
setstate mySolarPowerForecast 2024-02-23 18:00:07 pvCorrectionFactor_18_autocalc done
setstate mySolarPowerForecast 2024-02-23 18:12:23 pvCorrectionFactor_Auto on_simple_ai
setstate mySolarPowerForecast 2024-02-23 18:12:24 state updated
schon mal Danke fürs drüberschauen. Ich vermute auch ein falsch gesetztes Attribut.
Edit: Wie Du schon vermutet hast lag es an Attributen mit graphicBeam.*
Ich habe die einfach gelöscht, da ja eh defaults gelten und siehe da, die Balken werden angezeigt.
Sorry, aber ich bin von graphicBeam nicht auf die Diagramm-"Balken" gekommen, dachte immer, das hat mit den "Flow"-Anzeigen darunter zu tun.
Hat sich erst mal erledigt, ich konfiguriere das nach erneutem Studium der Hilfe...
Viele Grüße
Sany
Hi Heiko,
hab jetzt mal nen großen Swap hingestellt und habe beobachtet.
Ich habe gesehen das ganz langsam Speicher verwendet wurde.
Aber nach ca. 100 MB, alles noch im Arbeitsspeicher kam schon der Timeout.
Liegt es eventuell an meiner Internet Verbindung? Ich sitze hier auf dem Land und habe eine 6Mbit Leitung.
Download eines 700 MB Files dauert also ca. 17 Minuten ;-)
Was für ein Timeout ist denn da drin?
Bekomme aber hoffentlich bald Glasfaser.
Gruß,
Stefan
Moin,
Ich habe gesehen, dass man mehrere DWD wetter Devices anlegen kann... Ich liege hier genau zwischen zwei Stationen, kann ich damit zwei Stationen angeben und es wird der Mittelwert genommen? Ist dies in irgendeiner einem Post beschrieben?
Grüße
Heatseeker
Hi Heatseeker,
ja genau du kannst 2 Stationen nehmen.
Schau mal in den Attributen unter ctrlWeatherDevX. Kannst dort dann
ctrlWeatherDev1
ctrlWeatherDev2
eintragen.
Was genau gemittelt wird ist mir noch nicht ganz klar.
Ich habe irgendwie das Gefühl das trotzdem von meiner ersten Station die Strahlungswerte genommen werden, habe das aber auch noch nicht genau beobachtet.
Vielleicht kann Heiko hier aufklären.
Gruß,
Stefan
Bei einer Wettervorhersage oder einer Strahlungsprognose zwischen zwei (auch benachbarten) Stationen zu mitteln, ist physikalisch (oder meteorologisch, wenn man so will) totaler Unsinn.
LG
pah
Guten Morgen,
@Stefan
Der Timeout beträgt z.Zt fest 30 Sekunden. Das File wird gezippt übertragen (ca. 40MB groß) und wächst dann auf ca. 700MB.
Deine Station habe ich bei mir ausprobiert und funktioniert.
Du kannst im DWD Modul in der Zeile 1602 den Timout ändern:
$hash->{".forecastBlockingCall"} = ::BlockingCall("DWD_OpenData::GetForecastStart", $hash, "DWD_OpenData::GetForecastFinish", 30, "DWD_OpenData::GetForecastAbort", $hash);
Vermutlich wäre ein timeout Attribut im DWD Modul günstig wenn sich die Vermutung bestätigt.
@Heatseeker,
bei den ctrlWeatherDevX Attribute eingetragenen Wetterstationen werden keine Stahlungswerte genommen (dafür gibt es currentRadiationAPI), sondern nur die Bewölkungsvorhersage und die vorhergesagte Regenmenge der vergangenen Stunde gemerged.
Inwieweit die Angabe mehrerer Stationen sinnvoll ist, kann man für sich selbst entscheiden indem man mal dies gewählten Stationen miteinander und der Realität vergleicht.
pah bezweifelt grundsätzlich die Sinnhaftigkeit einer solchen Variante und nachdem ich mich ein wenig mehr mit den MOSMIX Verfahren, beschrieben in diesem Dokument (https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_verfahrenbeschreibung_gesamt.pdf;jsessionid=9A72B5712B331954ACDB8EA5AD910D6F.live31081?__blob=publicationFile&v=2), beschäftigt habe, drängt sich diese Einschätzung auch bei mir auf.
Allerdings wird in eben diesem Dokument im Abschnitt "2.1.6 Generelle Bemerkungen zur Konsistenz der Vorhersagen" auch ausgeführt:
Zitat...Obwohl dieses Verfahren eine optimierte Vorhersage für eine
gegebene Station zu einem gegebenen Zeitpunkt für einen gegebenen Parameter liefert, zeigen sich auch
typische Inkonsistenzen wenn verschiedene Stationen miteinander verglichen werden. So kann es durch-
aus vorkommen, dass für zwei Stationen die sich in räumlich unmittelbarer Nähe befinden leicht andere
Vorhersagen erzeugt werden. Beispielsweise könnte für eine Station eine 2m-Temperatur von 15◦C vor-
hergesagt werden und für eine Station in der unmittelbaren Umgebung 17◦C, obwohl die Wetterlage eher
eine räumlich einheitliche Temperaturverteilung vermuten lässt. Dies ist nicht unbedingt auf einen Fehler
im MOSMIX-Verfahren zurückzuführen, sondern eine Konsequenz aus der Erstellung individueller Glei-
chungen für jede einzelne Station. Diese beschriebene räumliche Inkonsistenz ist nicht systematisch, kann
aber immer wieder auftreten und spiegelt die Tatsache wider, dass MOSMIX Vorhersagen für einzelne
Stationen berechnet anstatt eine rasterbasierte Vorhersage wie sie die NWV bereitstellt....
Dementsprechend könnte sich m.M. nach durchaus ein Vorteil durch die Einbeziehung mehrerer Stationen ergeben. Das kann jeder für sich einmal beobachten und seine Erfahrungen damit hier teilen.
Die Angabemöglichkeit mehrere Stationen dient auch dazu den Ausfall einer Station zu eleiminieren. ch.eick hatte schon davon berichtet, dass bei ihm die ein oder andere Station keine Werte übermittelt hat.
LG,
Heiko
Zitat von: Prof. Dr. Peter Henning am 24 Februar 2024, 04:55:32Bei einer Wettervorhersage oder einer Strahlungsprognose zwischen zwei (auch benachbarten) Stationen zu mitteln, ist physikalisch (oder meteorologisch, wenn man so will) totaler Unsinn.
LG
pah
Vielen Dank für die ausführliche Begründung dieser Aussage, das hilft sehr beim Verständnis.
Sorry: Ich interpretiere das Ergebnis von Versuchen lieber selbst als einfache Behauptungen aus dem Internet glauben zu schenken, das machen leider schon zu viele...
Bei mir befindet sich Station 1 etwa 8km westlich von mir, Station2 etwa 9km östlich. Hauptwetterrichtung ist von Osten kommend, und z.B. bei Verwendung der Station 2 sehe ich oft eine Zeitverschiebung von einer halben Std, weshalb ich es mal mit einer Mittelung der beiden Stationen versuchen wollte. Ob es funktioniert werde ich dann ja sehen...
Bei "Behauptungen im Internet" sollte man einfach ansehen, welchen Hintergrund der Verfasser hat, das klärt schon einiges...
Zitatsehe ich oft eine Zeitverschiebung von einer halben Std
. Soso. Oft = immer? Und immer eine halbe Stunde, oder können es auch 20 Minuten sein?
Offenbar hängt es eben von mehreren Faktoren ab, wie das Wetter in der "Mitte" zwischen zwei Stationen ist - unter anderem von der Windrichtung. Der DWD schreibt selbst dazu, so wie unten zitiert
ZitatKonsequenz aus der Erstellung individueller Gleichungen für jede einzelne Station
.
Dann braucht man nur noch etwas Wissen über diese Gleichungen und kann mit mathematischer Genauigkeit die Aussage treffen
ZitatBei einer Wettervorhersage oder einer Strahlungsprognose zwischen zwei (auch benachbarten) Stationen zu mitteln, ist physikalisch (oder meteorologisch, wenn man so will) totaler Unsinn.
Aber Unsinn ist nicht verboten. so frei ist dieses Land ja noch. Also: Go ahead, mancher freut sich seines Lebens, wenn seine "Vorhersage" eine Genauigkeit von 50% hat.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 24 Februar 2024, 15:13:27Bei "Behauptungen im Internet" sollte man einfach ansehen, welchen Hintergrund der Verfasser hat, das klärt schon einiges...
Naja, ein Forumsname heißt ja nun mal gar nichts solange es keine Verifizierung etc gibt, kann mich hier auch Pumuckel nennen - werde dadurch jedoch auch kein Experte für rote Haare...
Zum Thema:
Mir ist schon bewusst, dass jede Station individuelle Ergebnisse liefern und dass in der Mitte zwischen zwei Stationen nicht immer der Mittelwert des Ergebnisses anliegen muss, aber mein Haus hat halt keine eigene Station und somit treffe ich für meinen Standort immer nur eine bestimmte Annahme und die Annahme, dass hier die Wetterbedingungen herschen wie an der Station 9 km weiter ist genau so falsch für mich wie der, dass hier der Mittelwert von der Station 1 und Station2 herrschen.
Ich wohne in der Nordeutschen Tiefebene, der maximale Höhenunterschied auf der Strecke zwischen Station1 und Station2 liegt bei unter 25 Metern, da habe ich bestimmt weniger toplogische Einflüsse wie im Alpenraum, deshlab lasse ich es gerne auf einen versuch ankommen zumal ich gerne experimentiere...
Hallo Heiko,
so ich habe den Timeout mal auf 120 sec erhöht und es geht ;-)
Ich habe auch beobachtet was dann beim get forecast passiert.
Mein Speicher vorher ist:
Verfügbar
Physisch 2704 MB
Swap 4048 MB
Dann mache ich den get forecast auf meinem Haupt Wetter Device.
Erst dauert es und es tut sich sehr wenig und nach 20 -30 sec nimmt der Speicher dann rapide ab bis ich:
Verfügbar
Physisch 284 MB
Swap 3566 MB
Verbraucht wurden also 2420 MB physisch + 529 MB Swap.
Wow! 3 GB Speicherverbrauch.
Der Speicher nahm sehr schnell ab. Somit denke ich dass bei mir wirklich die 6MBit Leitung den Timeout reißt.
Den Timeout kann ich dann wieder auf 30 setzen wenn ich Glasfaser habe.
Nun ein paar Fragen ;-)
Wie kommt das denn bei den 700 MB Rohdaten zu einem Speicherverbrauch von ungefähr 3 GB?
Ich benutze im Moment 2 Wetterdevices.
Wenn ich das richtig verstanden habe genügt es eigentlich die precision bei meinem Strahlungsdevice hochzusetzen, oder?
Gruß und Danke,
Stefan
Hallo Heiko,
wenn mit "deinem" DWD-Modul und den dazu empfohlen zugehörigen zusätzlichen neuen Einstellungen arbeite, erhalte ich irgendwann im laufe der Zeit folgende Meldung: (bislang 3 x - 3 Tage Laufzeit)
PERL WARNING: Use of uninitialized value $cloudCover in multiplication (*) at ./FHEM/98_DWD_OpenData_Weblink.pm line 837.
Gruß
300P
@Stefan,
dachte ich mir. Es macht dann durchaus Sinn den Timeout einstellbar zu gestalten.
ZitatWie kommt das denn bei den 700 MB Rohdaten zu einem Speicherverbrauch von ungefähr 3 GB?
Ich starte mal einen Erklärungsversuch. Zunächst muß man beachten dass bei dem verwendeten BlockingCall der Perl Hauptprozess geforkt, also in einen weiteren Prozess "kopiert" wird. Das stimmt nicht wirklich, Rudolph König hatte es mal im Forum genauer erläutert (suchen..) was in Perl passiert. Für uns nehmen wir erstmal eine Duplizierung des vorhandenen RAM (Perl) an.
In dem neuen Prozess wird das Stationenfile heruntergeladen und mit Perl-Mitteln entpackt. Die 700M gehen schonmal in den RAM.
Nun wird anschließend der gesamten Inhalt nach den relevanten Informationen geparst. Wir können davon ausgehen, dass dabei wieder einiges an Speicher verbraucht wird, möglicherweise wiederum die Größe des Files.
Der gesamte zusätzlich allokierte Speicher wird durch den geforkten Prozess verbraucht. Wenn die Arbeit getan ist, wird der geforkte Prozess beendet und der Speicher wieder freigegeben.
Jensb (im DWD Thread) will sich noch eine Technologie anschauen, um den Parsing Prozess ressourcenschonender zu gestalten. Aber das wird noch etwas dauern vermutlich. Leider stellt DWD die MOSMIX_S Daten mit dem stündlichen Update nur als komplettes File mit allen Stationen zur Verfügung. Da ist eine Menge Datenoverhead enthalten den wir handeln müssen.
ZitatWenn ich das richtig verstanden habe genügt es eigentlich die precision bei meinem Strahlungsdevice hochzusetzen, oder?
Wenn du ein DWD Device hast für die Strahlungsdaten (Rad1h) und ein anderes für die Bewölkung, Regen usw. macht es Sinn beide stündlich updaten zu lassen. Unstetige Witterungslagen können dadurch eher berücksichtigt werden.
@300P,
Zitatwenn mit "deinem" DWD-Modul und den dazu empfohlen zugehörigen zusätzlichen neuen Einstellungen arbeite, erhalte ich irgendwann im laufe der Zeit folgende Meldung: (bislang 3 x - 3 Tage Laufzeit)
PERL WARNING: Use of uninitialized value $cloudCover in multiplication (*) at ./FHEM/98_DWD_OpenData_Weblink.pm line 837.
Der DWD aktualisiert die MOSMIX_S Daten (https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_verfahrenbeschreibung_gesamt.pdf;jsessionid=BF2DEA0372BB3224B418FF618C857780.live31082?__blob=publicationFile&v=2) 24x täglich, aber nur bis +24h in die Zukunft. Wenn du in deinem DWD_OpenData_Weblink Device das Attr forecastDays > 2 eingestellt hast, können Daten fehlen und dann kommt diese Warnung. Das habe ich nämlich bei mir auch beobachtet. Mit forecastDays = 2 passt es.
LG,
Heiko
Ok super,
Danke Heiko macht alles Sinn.
Ich habe 2 ctrlWeatherDev:
ctrlWeatherDev1 DWD_Birkenau
ctrlWeatherDev2 DWD_Weiher
Im currentRadiationAPI ist DWD_Birkenau eingetragen. Da geht ja nur eins.
Wenn ich das richtig verstehe kommen die Strahlungsdaten von DWD_Birkenau.
Bewölkung usw von beiden.
Dein Vorschlag ist beide mit precision high damit die Bewölkung usw auch immer aktuell ist.
Bisher habe ich nur DWD_Birkenau mit high.
Werde denke ich meinen Swap noch etwas erhöhen und dann beide mit high laufen lassen.
Danke und Gruß,
Stefan
Hi Stefan,
ja genau, das Modul holt sich die Rad1h (Strahlungsdaten) von DWD_Birkenau.
Die Wetterdaten wie Bewölkung etc. werden auch aus ctrlWeatherDev1 DWD_Birkenau geholt.
Die Bewölkungsdaten werden mit den Daten aus ctrlWeatherDev2 DWD_Weiher gemerged. Ob das sinnvoll ist mußt du für dich entscheiden. Im einfachsten Fall setzt du nur ctrlWeatherDev1.
Gerade gesehen, dass ich den Mouse-Over bei der DWD Status LED korrigieren muß, statt "Vorhersagezeitpunkt Wetterdaten" ist richtig "Vorhersagezeitpunkt Strahlungsdaten". Eine LED für die Aktualität der Wetterdaten müsste ich noch an geeigneter Stelle noch einfügen.
LG,
Heiko
Ok, danke.
Ich teste es mal so mit den 2 Devices auf high auf dem Raspberry PI4.
Ist vielleicht ja auch für andere interessant, Raspberry wird ja doch oft benutzt.
Zu erwähnen ist bisher der Timeout, der liegt aber eher an meiner langsamen Internet Verbindung.
Und bei meinem Raspberry mit 4GB Speicher ist es zu knapp mit einem 8GB Raspberry könnte es im Speicher reichen.
Ich würde aber auf jeden fall einen Swap empfehlen mit mind 4098MB.
Vor allem hat sich der Raspberry ohne Swap einfach aufgehängt sobald der Speicher aufgebraucht war.
Also am besten mit dem Swap nicht zu geizig sein.
Ich nutze eine SSD für meinen Raspberry und habe somit nicht viel bedenken mit einem Swap.
Wenn man den Raspberry von SD Karte laufen hat sollte man sich da eher Gedanken machen.
Viele Grüße und Danke,
Stefan
edit.: geklärt
Moin,
in meinem contrib befindet sich eine Version des DWD_OpenData Moduls mit einem Attribut "timeout".
Damit kann man sich bei Bedarf (stefanru) diesen Parameter anpassen.
Grüße,
Heiko
Bei mir holt sich das Modul die Werte immer zur vollen Stunden (Mosix_S).
Ich meine bei DWD aber gelsen zu haben das es um ca. 25min nach der vollen Stunde aktualisiert wird.
Mal eben gesucht:
ZitatEs werden MOSMIX-Vorhersagen mit einem Vorhersageintervall von einer Stunde und einer maximalen Vorhersagezeit von +240 Stunden zur Verfügung gestellt. Sie werden 24x täglich, ca. 25 Minuten nach jeder vollen Stunde zur Verfügung gestellt.
Während die ersten 24 Vorhersagestunden auf Basis der neuesten Beobachtungsdaten stündlich aktualisiert werden, wird der Vorhersagezeitraum +25 bis +240 Stunden 4x täglich (um 4, 10, 16 und 22 UTC) aktualisiert.
Wäre es da nicht besser das man das um xx:30 immer holt? Und wäre es nicht besser wenn jeder Benutzer eine andere Zeit bekommt per Zufall beim Laden des Modules. So zwischen xx:30:00 - xx:49:59 damit nicht alle Zeitgleich pollen? Ist ja auch im Interesse des Hosters & DWD und gibt keine Engpässe abei den usern.
Gut es werden nicht 90802987359 geladene Module die Daten holen. Aber andere benutzen das ja auch für andere Scripte, Applications etc. .Man kann ja auch auf seine Mitmenschen mit soetwas rücksichtnehmen.
Mal so als Anregung.
Edit: Gerade mal ins modul geguckt. Ist ja fast sogar so. Ist bei mir nur doof getimed. Hatte es gestern Abend scharf gemacht.
Hallo kask,
ZitatBei mir holt sich das Modul die Werte immer zur vollen Stunden (Mosix_S).
Da bist du einem Irrtum aufgesessen. Der Timer des DWD Modul schaut regelmäßig nach durchzuführenden Aufgaben (Reading nextcycle). Je nach Aufgabe erfolgt die Datenholung im Viertel 0-3 einer Stunde. Bei Neustart sofort mit zufälliger Verzögerung.
Im Fall von MOSMIX_S ist es immer das Viertel "2", also zwischen xx:30 bis xx:45.
Das zahlt auf die Aktualisierungszeit des DWD ein. Ist mir bekannt und deswegen auch berücksichtigt.
Und die Abholzeit wird auch per Zufallszahl in gewissen Grenzen variiert. ;)
LG,
Heiko
Danke Heiko,
habe das neue DWD Modul geladen und Timeout gesetzt.
Ansonsten scheint es gut zu laufen.
Ich beobachte noch wie sich der Swap über eine längere Zeit verhält.
Gruß,
Stefan
Hallo zusammen,
trotz des sonnigen Wetters habe ich eine weitere Implementierung vorgenommen die mir schon lange wichtig war.
Es gibt nun schon einiger Zeit die Anreicherung der KI mit den Sonnenstandsdaten.
Für die diskreten Korrekturfaktoren bei den API's wie DWD ohne KI, SolCast, Forecast.Solar API oder VictronVRM war das bisher nicht der Fall. Das habe ich nun nachgeholt.
D.h. die Faktoren werden nunmehr neben der Bewölkung (die sich dank DWD "high" schneller anpasst) jetzt auch in Abhängigkeit der Sonnenaltitude pro Stunde bestimmt und in der pvCircular gespeichert.
Das Mouse-Over bei der Bewölkung in der Grafik zeigt jetzt auch die Sonnenstandsangaben für die jeweilige Stunde.
Ich bilde mir ein, dass die starke (und korrekte) Anpassung der Prognose von Stunde 12 auf 13 dem DWD MOSMIX_S Daten zu verdanken ist. Wir werden die weitere Entwicklung beobachten.
Wer schon etwas austesten möchte, kann sich die neue Version 1.16.3 aus meinem contrib ziehen. Restart nicht vergessen!
Wahrscheinlich werde ich die V heute Abend noch einchecken falls keine Auffälligkeiten zu Tage treten.
LG
Weiterentwickelte Version 1.16.3 ist eingecheckt.
Ich habe noch den Setup Wizzard für die ForecastSolar-API überarbeitet.
Kask (danke an dich!) hatte mich darauf aufmerksam gemacht, dass der Wizzard für diese API nicht optimal arbeitet.
LG
@all,
Jensb im DWD Thread stellt die Weiterentwicklungen des DWD Moduls in seinem contrib bereit:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb)
Ich entferne jetzt die DWD-Version aus meinem contrib damit es nur eine Quelle gibt.(siehe #80)
Alles Weitere zum DWD Modul im entsprechenden Thread (https://forum.fhem.de/index.php?topic=83097.0).
LG
Hi Heiko,
habe umgestellt auf das contrib von JensB.
Mir ist die letzten 2 Tage etwas sehr seltsames aufgefallen.
Ich werde versuchen morgen davon Screenshots zu machen.
Die Vorhersage verändert sich unheimlich beim Sprung auf 00:00 Uhr.
Vor 00:00 Uhr ist sie völlig anders als dann um 00:00 Uhr.
Ich beobachte es morgen und schicke Screenshots.
Gruß,
Stefan
Hallo Heiko,
nun wie angedroht die Screenshots von heute um den 00:00 Uhr wechsel rum. ;-)
Heute war die Änderung nicht so extrem, aber man sieht es ganz gut.
Gestern war es noch extremer deshalb ist es mir da aufgefallen.
Ich denke nicht das DWD gerade aktualisiert hat da ich es davor schon einmal hab updaten lassen.
Irgendwas seltsames passiert da beim Tageswechsel.
Die ersten 3 Bilder von vor 00:00, man sieht das die Vorhersage ziemlich stabil ist.
Um kurz nach 00:00 ändert sich die Vorhersage sehr stark und bei der nächsten Abfrage nochmal.
Danach bleibt sie wieder stabil.
Hast du irgendeine Idee was da um 00:00 pasiert?
Kannst du das bei dir auch sehen?
Kann ich noch etwas anderes beitragen?
Danke und Gruß,
Stefan
Morgen Stefan,
Um 00 passiert im Modul selbst eine ganze Menge.
Es werden aufgelaufene Werte des Vortages aufgeräumt, die KI trainiert, die Verbraucherplanung erneuert und noch einiges mehr an Datenpflege.
Aber deine Beobachtngen gehen eher in Richtung der durch den DWD gelieferten Werte. Daraus ergeben sich dann entsprechende Anpassungen der Prognose. Ich weiß natürlich nicht welche Werte sich wann/wie ändern, aber in der ausführlichen Doku des DWD zu MOSMIX (https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_verfahrenbeschreibung_gesamt.pdf;jsessionid=6B0D3DBB6934327A3F86EF02AA081A17.live31081?__blob=publicationFile&v=2) steht beschrieben (Technische Charakteristika der MOSMIX-Läufe in der operationellen Routine.), dass deterministische Modellläufe von 00 und 12 UTC und eingehende Modelle -> deterministische Läufe von ICON und IFS von 00 und 12 UTC stattfinden.
Also ich will damit sagen, auch beim DWD passieren zu bestimmten Zeiten statistische Anpassungen durch Phasen ,,Training" und ,,Vorhersage" die Einfluß bei unserer Anwendung haben. In der Doku können sich noch mehr Einzelheiten verbergen. Ich habe das MOSMIX Verfahren noch nicht bis in jede Einzelheit studiert geschweige denn verstanden. ;)
Grüße,
Heiko
Die Weiterentwicklung des DWD OpenData Moduls gestaltet sich doch etwas testaufwändiger als ursprünglich gedacht.
Deswegen habe ich mich dazu entschlossen, eine (im Zusammnspiel mit SolarForcast) getestete Entwicklungsversion des DWD OpenData Moduls wieder in meinem contrib (Fußtext) für interessierte SolarForecast User bereitzustellen.
So könnt ihr darauf bauen, dass ich diese Version im Vorfeld mit SolarForecast getestet habe.
LG,
Heiko
Hi Heiko,
ok danke.
Ich bin nur verwundert da sich um 00:00 rum DWD garnicht updated und das sich die Vorhersage hier z.B. um fast 50% ändert, genau um 00:00.
Auch habe ich es am Tag vorher noch gravierender gesehen.
Könnte es sich auch um einen off bei 1 Error handeln?
Wie syncst du mit den DWD Devices den Tagesübergang?
Irgendwie müsste Solarforecast ja pro DWD Device wissen ob schon im neuen Tag geupdated wurde oder nicht.
Das mag totaler Unsinn sein, ich habe keine Ahnung über die genaue Funktionsweise von DWD und Solarforecast, aber hier wie ich mir einen Fehler vorstellen könnte:
DWD hat fc0, fc1, fc2 was den Vorhersage Tagen entspricht.
DWD updated um 23:30. Also die fc sind noch von heute. Nächter DWD update 00:30.
Forecast macht um kurz nach 00:00 die nächste Kalkulation, und nimmt den aktuellen Tag, der aber im DWD Device bis zum nächsten Update um 00:30, noch dem gestrigen Tag entspricht.
Macht das irgendein Sinn, oder hast du das alles eh schon im Modul?
Danke und viele Grüße,
Stefan
Hallo Stefan,
ZitatDWD hat fc0, fc1, fc2 was den Vorhersage Tagen entspricht.
DWD updated um 23:30. Also die fc sind noch von heute. Nächter DWD update 00:30.
Forecast macht um kurz nach 00:00 die nächste Kalkulation, und nimmt den aktuellen Tag, der aber im DWD Device bis zum nächsten Update um 00:30, noch dem gestrigen Tag entspricht.
Ja, das liegt durchaus im möglichen Rahmen. Diese Wechsel des Tages sind nicht ohne.
Für uns ist das aber nicht so dramatisch. Für die Anzeige mag es vllt. kurzzeitig etwas unschön sein (wer um diese Zeit darauf schaut ;) ), aber alle Planungen werden erst mit einem Vorlauf von 1h vor Sonnenaufgang vorgenommen um auf möglichst aktuelle Daten zu setzen.
Und die vielfältigen internen Kalkulationen werden mit jedem Zykluslauf neu durchgeführt. Deswegen ist dieser Moment nach dem Tageswechsel auch nur kurz.
Mit dem neuen DWD Modul kann ich zukünftig wegen dem 1 Stunden Update auch besser synchen/auswerten, jedoch ist es noch nicht offiziell. Und das bisherige DWD Modul hinkt im worst case 6 Stunden hinterher.
Ich bleibe dran ;)
Grüße,
Heiko
Ah perfekt,
"alle Planungen werden erst mit einem Vorlauf von 1h vor Sonnenaufgang vorgenommen"
das hattest du schonmal gesagt war mir aber entfallen.
Damit ist es maximal etwas unschön wenn man nach 00:00 bis zum nächsten DWD update reinschaut.
Dann bin ich beruhigt und hoffe die weiterentwicklung im DWD Modul läuft erfolgreich, dann wird das Problem sowieso immer kleiner.
Danke für die Erklärung,
Stefan
Hallo Heiko,
ich bekomme neuerdings folgende Fehlermeldung:
2024.02.27 16:38:57 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at ./FHEM/76_SolarForecast.pm line 15892.
Vielen Dank vorab!
Hallo Achim,
danke für die Info. Korrigiere ich.
LG
Hallo Stefan,
kurze Info.
Das DWD Modul hat eine "RotateForecast" Funktion die bei einem Zyklus den aktuellen Zeitstempel mit fc0_date vergleicht und alle Readings bei Bedarf von fc1 nach fc0 verschiebt, d.h. das Modul hat einen Tagesverschieber.
LG
Guten Abend,
ich mache gerade meine ersten Schritte mit diesem tollen Modul und lerne ständig dazu, was man noch alles einstellen kann.
Dennoch habe ich noch eine Verständnisfrage und finde bisher keine Antwort. Mit den Balken kann man darstellen, wie viel Energie voraussichtlich in jeder Stunde erzeugt werden wird und dann wie viel es tatsächlich geworden ist. Soweit so gut.
Nun zeigen meine Balken aber, dass ich auch im Dunkeln Energie "erzeuge". Schnell war ich dahinter gekommen, dass dies die Energie aus der Batterie ist, denn es endet, sobald der Speicher nicht mehr entladen wird.
Dies verzerrt aber das Balkendiagramm, da anscheinend zu wenig erzeugt wird, wenn gleichzeitig die Batterie geladen wird, und eben zu viel, wenn die Batterie wieder entladen wird. Evtl. hat dies dann auch einen Effekt bei der KI Berechnung?!
Ist das so gewollt oder was habe ich ggf. falsch eingestellt?
Screenshot 2024-02-28 211817.png
VG,
Bozan
Hallo Bozan,
nein, gewollt ist das nicht und hat auch nichts mit KI zu tun. KI ist nur für die PV Prognose, aber nicht für die reale Erzeugung Datenlieferant.
Die Werte der realen Erzeugung werden aus den Angaben in "currentInverterDev" ermittelt.
Die Hilfe sagt genau was erwartet wird:
currentInverterDev <Inverter Device Name> pv=<Readingname>:<Einheit> etotal=<Readingname>:<Einheit> [capacity=<max. WR-Leistung>]
Legt ein beliebiges Device und dessen Readings zur Lieferung der aktuellen PV Erzeugungswerte fest. Es kann auch ein Dummy Device mit entsprechenden Readings sein. Die Werte mehrerer Inverterdevices führt man z.B. in einem Dummy Device zusammen und gibt dieses Device mit den entsprechenden Readings an.
Die Angabe von capacity ist optional, wird aber zur Optimierung der Vorhersagegenauigkeit dringend empfohlen.
pv Reading welches die aktuelle PV-Erzeugung liefert
etotal Reading welches die gesamte erzeugte PV-Energie liefert (ein stetig aufsteigender Zähler)
Einheit die jeweilige Einheit (W,kW,Wh,kWh)
capacity Bemessungsleistung des Wechselrichters gemäß Datenblatt (max. möglicher Output in Watt)
Für dein Problem ist das Reading aus dem Schlüssel "pv" verantwortlich. Es muß die aktuelle Erzeugung liefern.
Was hast du für einen Wechselrichter und zeige uns mal bitte deine Einstellung von currentInverterDev.
LG
Zitat von: DS_Starter am 27 Februar 2024, 23:37:29Das DWD Modul hat eine "RotateForecast" Funktion die bei einem Zyklus den aktuellen Zeitstempel mit fc0_date vergleicht und alle Readings bei Bedarf von fc1 nach fc0 verschiebt, d.h. das Modul hat einen Tagesverschieber.
Ok danke,
das macht das macht das modul dann beim nächsten Zyklus.
Das heißt von 00:00 - nächster Zyklus stimmt es kurz nicht, verstehe ich das richtig?
Danke und Gruß,
Stefan
Genau.
Wenn natürlich das DWD Device seinen Zyklus vor dem SolarForecast Zyklus ausführt, dann merkt man nichts.
Aber das ist eher unwahrscheinlich weil ich ca. 3 Sekunden nach einer vollen Stunde immer einen initialen Lauf starten. D.h. das DWD hätte ein Fenster von 2 Sekunden, kann natürlich klappen, nichts ist unmöglich.
Grüße,
Heiko
Ich habe einen Fronius Symo Gen 24 Plus zusammenn mit einer BYD-Box im Einsatz und lese die Daten einmal mit dem Modul 98_Fronius von MWinkler:
PV_Wechselrichter pv=PowerFlow_Site_P_PV:W etotal=PowerFlow_Site_E_Total:W capacity=8000
Die Wertze für die Batterie hole ich mit 98_ModbusAttr.pm:
BYD_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W intotal=Summe_Ladung:kWh outtotal=Summe_Entladung:kWh cap=5120 charge=BatteryChargePercent
BatteryChargeWatt: obj-h40324-reading
BatteryDischargeWatt: obj-h40344-reading
Summe_Ladung: obj-h40325-reading
Summe_Entladung: obj-h40345-reading
Hoffe, das ist soweit verständlich?!
Vermutlich müsste ich dann ein Reading generieren aus PowerFlow_Site_P_PV + Leistung in die Batterie - Leistung aus der Batterie?
VG,
Bozan
ZitatVermutlich müsste ich dann ein Reading generieren aus PowerFlow_Site_P_PV + Leistung in die Batterie - Leistung aus der Batterie?
Ja, genau. Du müsstest an dieser Stelle einen vorhandenen Batterieanteil eliminieren.
Bin auch der Meinung dass es bereits Fronius Symo-User bei SolarForecast gibt und wir das Thema mit diesem WR schon beleuchtet hatten.
Vllt. meldet sich jemand mit seinem Lösungsweg.
Zitat von: TheTrumpeter am 14 Februar 2024, 08:26:40Zitat von: DS_Starter am 06 Februar 2024, 22:41:03Gäbe es ein größeres Interesse daran die API von Geosphere Austria in das Modul einzubinden?
Ich bin mir unsicher ob die Daten in der gelieferten Form in die Modularchitektur passen und welche Zeit ich zur Integration benötigen würde.
Ich habe mich vor knapp 2 Wochen schonmal bisschen damit beschäftigt und versucht die unterschiedlichen Daten-Namen zwischen DWD und Geosphere zuzuordnen.
Wenn das noch aktuell ist würd' ich ab nächster Woche wieder draufschauen können.
Hier mal ein Mapping der Werte von DWD zu GeoSphere (links DWD, rechts GeoSphere):
TTT => t2m
Neff => tcc
R101 => rr_acc, aber akkumuliert
ww => nicht verfügbar
SunUp/SunSet/SunRise => nicht verfügbar
Wenn ich es richtig sehe, verwendest Du für die Prognose nur "Rad1h" vom DWD ("Absolute Globalstrahlung"). Das müsste mit "grad" von GeoSphere ("Surface downwelling shortwave is the sum of direct and diffuse solar radiation incident on the surface, and is sometimes called global radiation") abzudecken sein, allerdings sind die Werte in der Prognose immer akkumuliert, d.h. es müsste die Differenz gebildet werden, siehe z.B. die aktuelle Vorhersage für Wien Innere Stadt https://dataset.api.hub.geosphere.at/v1/timeseries/forecast/nwp-v1-1h-2500m?parameters=grad&lat_lon=48.206248%2C16.367569
Der Aufruf ist unter Angabe der Koordinaten in obigem Link möglich, optional kann Startzeit sowie Offset angegeben werden. Eine Aktualisierung der Prognose findet lt. https://data.hub.geosphere.at/dataset/nwp-v1-1h-2500m alle 3h statt.
Doku: https://data.hub.geosphere.at/dataset/nwp-v1-1h-2500m
Hier können die APIs ausprobiert werden. Da müssen nur die Parameter eingetragen werden, der Aufruf sowie das Ergebnis werden dann interaktiv angezeigt: https://dataset.api.hub.geosphere.at/v1/openapi-docs
Hier beispielsweise die Vorhersage für Wien Innere Stadt mit allen der DWD entsprechenden Paraemter von oben:
Auszuprobieren hier: https://dataset.api.hub.geosphere.at/v1/openapi-docs#/forecast/Timeseries_Forecast_timeseries_forecast__resource_id__get unter Angabe der entsprechenden Parameter, bzw. Direktaufruf: https://dataset.api.hub.geosphere.at/v1/timeseries/forecast/nwp-v1-1h-2500m?parameters=t2m¶meters=grad¶meters=tcc¶meters=rr_acc&lat_lon=48.206248%2C16.367569&forecast_offset=0&output_format=geojson
Oh da warst du fleißig, vielen Dank für die Vorbereitung :)
Da muß ich wohl tatsächlich bald mal starten mit dieser API. ;)
LG,
Heiko
Ja ich habe Fronius mit BYD, habe 2 WR.
Da muss man etwas tricksen ich denke ich hole mir den Wert anders.
Habe das schonmal hier geschrieben aber wird natürlich schwierig zu finden.
Ich habe noch ein Dummy zwischendrin, deshalb kann ich es nicht direkt mappen.
Habe gerade nicht die Zeit das aufzubereiten aber hier meine Settings im Solarforecast Modul:
currentBatteryDev BatteryDummy pin=-pout pout=total_pac:W intotal=intotal:kWh outtotal=outtotal:kWh charge=chargestatus
currentInverterDev InverterDummy pv=PowerFlow_PV:W etotal=Energy_Total_PV:kWh capacity=24800
currentMeterDev EnergyMeterDummy gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh
Und dazu die Befüllung der dummys:
Symo:PowerFlow_Site_P_PV:.* {
# Forecast Invertererzeugung InverterDummy
fhem "setreading InverterDummy Today_PVforecast ".ReadingsNum("Forecast","Today_PVforecast",0);;
fhem "setreading InverterDummy Next4h_PVforecast ".ReadingsNum("Forecast","NextHours_Sum04_PVforecast",0);;
fhem "setreading InverterDummy Today_PVreal ".ReadingsNum("Forecast","Today_PVreal",0);;
my $PVTotal = ReadingsNum("PV_Runge","User_Produced_PV",0) + ReadingsNum("Symo","User_Produced_PV",0);;
my $Total = (ReadingsNum("PV_Runge","PowerFlow_Inverters_1_E_Total",0) + ReadingsNum("Symo","PowerFlow_Inverters_1_E_Total",0)) /1000;;
fhem "setreading InverterDummy Energy_Total_Real ".($Total);;
# Invertererzeugung InverterDummy
my $Solar = ReadingsNum("PV_Runge","PowerFlow_Site_P_PV",0) + ReadingsNum("Symo","PowerFlow_Site_P_PV",0);;
if ($Solar > 6)
{fhem "setreading InverterDummy Energy_Total_PV ".($PVTotal)}
else
{$Solar = 0}
fhem "setreading InverterDummy PowerFlow_PV ".($Solar);;
# Inverter calc load
my $Grid = ReadingsNum("PV_Runge","PowerFlow_Site_P_Grid",0);;
my $Akku = ReadingsNum("PV_Runge","PowerFlow_Site_P_Akku",0);;
my $Load = $Solar + $Grid + $Akku;;
$Load = ($Load > 0) ? ($Load) : ReadingsNum("InverterDummy","PowerFlow_Load",0);;
fhem "setreading InverterDummy PowerFlow_Load ".($Load);;
fhem "setreading InverterDummy PowerFlow_Grid ".($Grid);;
fhem "setreading InverterDummy PowerFlow_Akku ".($Akku);;
# Batteriestatus BatteryDummy
fhem ("setreading BatteryDummy chargestatus ".ReadingsNum("PV_Runge","PowerFlow_Inverters_1_SOC",0));;
# Batterie-total_pac BatteryDummy
fhem ("setreading BatteryDummy total_pac ".(ReadingsNum("PV_Runge","PowerFlow_Site_P_Akku",0)));;
my $MaxCharge = sprintf('%.0f', ReadingsNum("BatteryDummy","MaxChargeWatt",0));;
my $MaxDischarge = sprintf('%.0f', ReadingsNum("BatteryDummy","MaxDischargeWatt",0));;
my $MaxString = " ";;
if ($MaxCharge < 12800)
{$MaxString = "$MaxCharge";;}
else
{$MaxString = "-";;}
if ($MaxDischarge < 12800)
{$MaxString = $MaxString ."w / ". $MaxDischarge ."w";;}
else
{$MaxString = $MaxString ."w / -w";;}
fhem "setreading BatteryDummy MaxString ".$MaxString;;
# BatteryIn/Out BatteryDummy
fhem "setreading BatteryDummy intotal ".ReadingsNum("PV_Runge","User_Energy_Bat_in",0);;
fhem "setreading BatteryDummy outtotal ".ReadingsNum("PV_Runge","User_Energy_Bat_out",0);;
# Batterie für Max Lade berechnung
my $BatCapacityMax = ReadingsNum("PV_Runge","Storage_0_Controller_Capacity_Maximum",0);;
my $BatCharge = ReadingsNum("PV_Runge","PowerFlow_Inverters_1_SOC",0);;
my $BatLevelWh = ($BatCapacityMax / 100 * $BatCharge);;
my $PV_Ertrag_heute= ReadingsNum("Forecast","RestOfDayPVforecast",0);;
my $Verbrauch_heute= ReadingsNum("Forecast","RestOfDayConsumptionForecast",0);;
my $PV_Ueberschuss = ($PV_Ertrag_heute - $Verbrauch_heute);;
my $Wh_Bis_100 = ($BatCapacityMax - $BatLevelWh);;
#my $VerbrauchBisMorgen = (($PV_Ueberschuss * -1) + (3864));; #3864 Verbrauch von 0 bis morgends
#my $BatTillNextDay = ($BatLevelWh > $VerbrauchBisMorgen) ? ("reicht (".round(($BatLevelWh-$VerbrauchBisMorgen),0)." W)") : ("reicht nicht (".round(($BatLevelWh-$VerbrauchBisMorgen),0)." W)");;
fhem "setreading BatteryDummy PV_Ueberschuss ".$PV_Ueberschuss;;
fhem "setreading BatteryDummy Wh_Bis_100 ".$Wh_Bis_100;;
fhem "setreading BatteryDummy Uebrig_Wh ".$BatLevelWh;;
#fhem "setreading BatteryDummy VerbrauchBisMorgen ".$VerbrauchBisMorgen;;
#fhem "setreading BatteryDummy AusreichendBisMorgen ".$BatTillNextDay;;
# New forecast based calculation for Rest tilll Sunrise
my $BatLevelRest = $BatCapacityMax / 100 * ($BatCharge - 5);;
my $SunriseSec = time2sec(ReadingsVal("Forecast","Today_SunRise", 0));;
my $TimeSec = time2sec(strftime("%H:%M",localtime));;
my $SecDiffSunrise = $TimeSec - $SunriseSec;;
my $PVRestBisSunrise = ($SecDiffSunrise > 0) ? $PV_Ertrag_heute : 0;;
#my $PVRestBisSunrise = ReadingsNum("Forecast", "RestOfDayPVforecast", 0);;
my $VerbrauchBisSunrise = ReadingsNum("Forecast", "statistic_conForecastTillNextSunrise", 0);;
my $AkkuRestTillSunrise = $BatLevelRest + $PVRestBisSunrise - $VerbrauchBisSunrise;;
fhem "setreading BatteryDummy AkkuRestBisSonnenaufgang ".$AkkuRestTillSunrise;;
my $BatTillNextDayAlexa = ($AkkuRestTillSunrise > 0) ? ("reicht mit ".round(($AkkuRestTillSunrise),0)." W Überschuss") : ("reicht nicht mit ".round(($AkkuRestTillSunrise),0)." W zuwenig");;
fhem "setreading BatteryDummy AusreichendBisMorgenAlexa ".$BatTillNextDayAlexa;;
# Netzbezug EnergyMeterDummy
#my $NetzEinspeisung = ReadingsVal("PV_Runge","PowerFlow_Site_P_Grid",0);;
#my $NetzBezug = ReadingsVal("PV_Runge","PowerFlow_Site_P_Grid",0);;
#$NetzEinspeisung = ($NetzEinspeisung <= 0) ? ($NetzEinspeisung * -1) : 0;;
#$NetzBezug = ($NetzBezug => 0) ? ($NetzBezug) : 0;;
fhem "setreading EnergyMeterDummy Bezug_Wirkleistung ".ReadingsNum("PV_Runge","User_Power_Import",0);;
fhem "setreading EnergyMeterDummy Einspeisung_Wirkleistung ".ReadingsNum("PV_Runge","User_Power_Feedin",0);;
fhem "setreading EnergyMeterDummy Bezug_Wirkleistung_Zaehler ".ReadingsNum("PV_Runge","User_Energy_Import",0);;
fhem "setreading EnergyMeterDummy Einspeisung_Wirkleistung_Zaehler ".ReadingsNum("PV_Runge","User_Energy_Feedin",0);;
#PV_Stats Autarkie and SelfConsuption trigger calculation
fhem "setreading PV_Stats update 1";;
}
Also PowerFlow_PV kommt bei mir aus:
# Invertererzeugung InverterDummy
my $Solar = ReadingsNum("PV_Runge","PowerFlow_Site_P_PV",0) + ReadingsNum("Symo","PowerFlow_Site_P_PV",0);;
if ($Solar > 6)
{fhem "setreading InverterDummy Energy_Total_PV ".($PVTotal)}
else
{$Solar = 0}
fhem "setreading InverterDummy PowerFlow_PV ".($Solar);;
Batterie ziehe ich da nicht ab, war glaube ich nicht nötig.
Gruß,
Stefan
Danke, Stefan!
Ist ja schon recht komplex, daher warte ich erst einmal ab, wie ich mit der "simplen" Lösung zurechtkomme.
Ich rechne nun eben wie oben beschrieben die Ladung in die Batterie dazu und ziehe die Entladung ab. Das sieht schon mal nicht so falsch aus. Dennoch passten die Werte heute Nacht nicht komplett, was aber an sich vernachlässigbar wäre.
Ich führe dies auf den Wirkungsgrad zurück, weshalb ich den nun in der Formel berücksichtige. Als Faktor bei der Ladung nehme ich nun 0.9.
Bin mal auf heute Nacht gespannt, dann sollte der "Ertrag" um den Wert Null schwanken, hoffe ich...
VG,
Bozan
Hi Bozan,
ich verstehe nicht ganz warum du die Batterie mit rein und raus rechnest.
Der Wert PowerFlow_Site_P_PV beinhaltet keine Batterie Leistung und sollte direkt in pv=PowerFlow_Site_P_PV:W einfließen.
Also ist reine PV Leistung des Wechselrichters.
Das Problem das es bei Fronius gibt ist der Totalwert, also in Solar Forecast der etotal.
Den gibt es so nicht im Wechselrichter.
Ich erzeuge mir diesen am Wechselrichter mit einem UserReading:
User_Produced_PV:PowerFlow_Site_P_PV.* integral {ReadingsVal("$name","PowerFlow_Site_P_PV","0")/3600000},
Dieses Summiert die PowerFlow_Site_P_PV werte in einen Total Wert.
Das ganze ist wahr für alle folgenden 4 Readings, alle sind ausschließlich Werte für Akku, Grid, Load und PV.
PowerFlow_Site_P_Akku
PowerFlow_Site_P_Grid
PowerFlow_Site_P_Load
PowerFlow_Site_P_PV
Ich hoffe das erklärt es etwas.
P.S.:
Am Gen24 ist der PowerFlow_Site_P_PV Nachts leider etwas seltsam und kann bis zu 6 Watt anzeigen, meistens ist es 1 Watt. Der Symo hat das Problem nicht.
Das ist zwar vernachlässigbar, aber dann zeigt die SolarForecast Grafik auch nachts minimale Werte an.
Deshalb benutze ich im Dummy:
# Invertererzeugung InverterDummy
my $Solar = ReadingsNum("PV_Runge","PowerFlow_Site_P_PV",0) + ReadingsNum("Symo","PowerFlow_Site_P_PV",0);;
if ($Solar > 6)
{fhem "setreading InverterDummy Energy_Total_PV ".($PVTotal)}
else
{$Solar = 0}
fhem "setreading InverterDummy PowerFlow_PV ".($Solar);;
Gruß,
Stefan
@all,
in meinem contrib liegt die aktuelle Entwicklungsversion von 55_DWD_OpenData.
Sie ist mit SolarForecast im Zusammenspiel getestet.
Vorteil der V ist die dynamische Datenaktualisierung sobald ein aktualisiertes Stationfile beim DWD festgestellt wird.
Wer mag ...
LG,
Heiko
ich hab mich mal getraut ;)
Und ... hat sich inzwischen Herzrasen eingestellt? :D
@all,
morgen früh wird ein SolarForecast Update ausgeliefert.
Was ist neu/geändert:
- "set ... plantConfiguration save" sichert nun auch gesetzte (wichtige) Attribute der Anlage. Attribute werden zwar in der fhem.cfg gespeichert. Dennoch kann ein Verlust oder eine fehlerhafte Einstellung vorkommen.
Dieses Feature erhöht die Sicherheit und den Komfort, z.B. auch nach einem Löschen des Devices und Neuanlage. Mit einem Restore werden die Readings und Attribute, die ja sehr umfangreich (z.B. Consumer) sein können, wiederhergestellt.
- eine LED für die Wetterdaten (Anhang) signalisiert evtl. veraltete Daten.
- Perl Warnungen eliminiert (und hoffentlich keine neuen eingebaut ;) )
- Code changes und Datenpflege interner Datenspeicher
Bitte führt dieses Update zeitnah aus. Es sind einige Datenpflegeroutinen eingebaut die ich gern zügig wieder entfernen möchte.
Grüße,
Heiko
Guten Morgen,
@stefanru, schau dir mal diesen Beitrag (https://forum.fhem.de/index.php?msg=1305472) von Jensb im DWD Forum an. Eventuell kannst/solltest du dort eine Info bzgl. deiner Downloadzeit schreiben.
LG
Hallöchen zusammen.
Wie kann ich diesen schönheitsfehler der von 00:00 bis 09:00 auftritt noch beseitigen
2024.03.03 09:37:51 3: set DBLogging addCacheLine 2024-03-03 009:00:00|Solar_Cast|addlog|newForecast:09|PVforecast|0| : Syntax error in set addCacheLine command.
99_solCast_Utils.pm
package main;
use strict;
use warnings;
use Time::Piece;
sub
solCast_Utils_Initialize($$)
{
my ($hash) = @_;
}
#
# Forecastwerte aus mySolarForecast in die DB schreiben, um damit ein Plot zu erstellen
#
sub PVForecast_log2()
{
Log 3, "Aufruf von PVForecast_log2 um ".localtime();
# Alte Einträge erst einmal löschen
my $timedelete = TimeNow();
my ($year,$mon,$day,$hour,$min) = $timedelete =~ m/(\d\d\d\d)-(\d\d)-(\d\d) (\d\d):(\d\d):\d\d/;
fhem "set DBRep_PV sqlCmd delete from history where DEVICE = 'Solar_Cast' AND reading like 'PVforecast%' and TIMESTAMP>='".$timedelete."'";
# alle Verhersage Readings des Device durchlaufen
for(my $i=$hour; $i < 24; $i++)
{
# die Readings mit der Nummerierung richtig zusammen bauen (führende Nullen bei < 10)
my $reading = ($i < 10) ? "Today_Hour0".$i : "Today_Hour".$i;
#Timestamp für den Forecastwert
my $timestamp = ($i < 10) ? "$year-$mon-$day 0$i:00:00" : "$year-$mon-$day $i:00:00";
my $value = ReadingsNum("Solar_Cast",$reading."_PVforecast",0);
# Wert in der Datenbank loggen
#Log 3, "Logging: $timestamp newForecast$i PVforecast:$value";
fhem "set DBLogging addCacheLine ".$timestamp."|Solar_Cast|addlog|newForecast:".$i."|PVforecast|".$value."|";
}
}
1;
Hallo Heiko,
ich habe Fragen zur "LED für die Wetterdaten":
* Wird bei der Ermittlung des Status berücksichtigt, wie der Aktualisierungsintervall ist?
Ich habe den Eindruck, dass hier zu früh gewarnt wird.
Ich muss mit dem RPi3 aktuell noch Mosmix-L verwenden.
* Die Zeitstempel vom DWD scheinen UTC zu sein. Wird das berücksichtigt?
Um kurz nach 11 Uhr (Ortszeit) wurden neue Daten mit Zeitstempel 10 Uhr vom DWD bereitgestellt.
Ich würde mir für den LED "Mouse-Over" einen Hinweis auf UTC wünschen.
Zum Anhang:
Warum wird mir hier ein "i" angezeigt und kein "grüner Punkt"?
Grüße,
Guido.
ZitatWie kann ich diesen schönheitsfehler der von 00:00 bis 09:00 auftritt noch beseitigen
Wahrscheinlich so:
sub PVForecast_log2
{
Log 3, "Aufruf von PVForecast_log2 um ".localtime();
# Alte Einträge erst einmal löschen
my $timedelete = TimeNow();
my ($year,$mon,$day,$hour,$min) = $timedelete =~ m/(\d\d\d\d)-(\d\d)-(\d\d) (\d\d):(\d\d):\d\d/;
fhem "set DBRep_PV sqlCmd delete from history where DEVICE = 'Solar_Cast' AND reading like 'PVforecast%' and TIMESTAMP>='".$timedelete."'";
# alle Verhersage Readings des Device durchlaufen
for(my $i=$hour; $i < 24; $i++)
{
# die Readings mit der Nummerierung richtig zusammen bauen (führende Nullen bei < 10)
$i = sprintf "%02d", $i;
my $reading = "Today_Hour".(sprintf "%02d", $i);
#Timestamp für den Forecastwert
my $timestamp = "$year-$mon-$day ".(sprintf "%02d", $i).":00:00";
my $value = ReadingsNum("Solar_Cast",$reading."_PVforecast",0);
# Wert in der Datenbank loggen
#Log 3, "Logging: $timestamp newForecast$i PVforecast:$value";
fhem "set DBLogging addCacheLine $timestamp|Solar_Cast|addlog|newForecast: $i|PVforecast|$value|";
}
}
Hallo Guido,
Zitat* Wird bei der Ermittlung des Status berücksichtigt, wie der Aktualisierungsintervall ist?
Nein. Das werde ich aber einbauen. Ich hoffe das relevante Attribut hat jetzt seine finale Version erreicht.
ZitatDie Zeitstempel vom DWD scheinen UTC zu sein. Wird das berücksichtigt?
Das stimmt, allerdings sind die Readings im DWD Device auf Localtime umgerechnet (außer fc_dwdDocTime zur Zeit). Ausgewertet wird fc_time welches Localtime ist, also kein UTC.
Voraussetzung dafür ist aber, dass die Installation von DWD entsprechend Wiki richtig ausgeführt wurde.
ZitatZum Anhang:
Warum wird mir hier ein "i" angezeigt und kein "grüner Punkt"?
Das ist eine Information. In dem Fenster ist zuwenig zu sehen. Wenn du mehr postest kann ich dir Auskunft geben.
Grüße,
Heiko
Beim "Mouse-Over" wird mir 10 Uhr angezeigt, was 11 Uhr Ortszeit entsprechen müsste.
Also "10:00:00Z" oder "10:00:00 UTC" fände ich hier besser.
Auf welches Wiki beziehst Du dich ( ... Installation von DWD entsprechend Wiki .. ) ?
Welches "mehr" würdest Du gerne sehen?
Danke und Gruß,
Guido.
ZitatBeim "Mouse-Over" wird mir 10 Uhr angezeigt, was 11 Uhr Ortszeit entsprechen müsste.
Also "10:00:00Z" oder "10:00:00 UTC" fände ich hier besser.
Es wird das angezeigt, was im DWD-Device im Reading fc_time steht. Und das ist keine UTC Zeit sondern Local, deswegen wäre der Zusatz Z/UTC nicht richtig.
ZitatAuf welches Wiki beziehst Du dich ( ... Installation von DWD entsprechend Wiki .. ) ?
Das DWD-Wiki: https://wiki.fhem.de/wiki/DWD_OpenData
ZitatWelches "mehr" würdest Du gerne sehen?
Siehe mein Beispiel.
OK, dann hat der DWD getrödelt. Die 10 Uhr Daten waren erst nach 11 Uhr verfügbar.
Danke, werde das DWD-Wiki nochmal sichten.
Im Anhang ist ein neuer Screenshot.
VG,
Guido.
ZitatOK, dann hat der DWD getrödelt. Die 10 Uhr Daten waren erst nach 11 Uhr verfügbar.
Da müsstest du tatsächlich nochmal schauen. Verzögerungen kommen zwar mal vor, allerdings eher selten.
Normalerweise sind die Werte nach ca. xx:25 verfügbar.
EDIT: Eine falsche Zeit bei den DWD Readings hätte auch Auswirkungen bzgl. einer Verschiebung deiner Vorhersage um 1 Stunde!
Jetzt sieht man es ...
Die Info bezieht sich darauf dass das gewählte SF-Model kein AI/KI unterstützt.
Grüße,
Heiko
Ich habe mir die DWD Daten nochmal angesehen.
Um 22:59 CET gab es eine neue MOSMIX_L_LATEST_10400.kmz.
Zeitstempel der Datei 21:56 (vermutlich UTC).
In der Datei:
IssueTime 2024-03-03T21:00:00.000Z
1. TimeStep 2024-03-03T22:00:00.000Z
Der erste Datensatz ist dann für die Stunde ab 23:00 CET.
Passt. Habe mich nur verwirren lassen.
OK, wegen der AI/KI. Alles klar.
Grüße,
Guido.
Zitat von: minierm am 12 Februar 2024, 19:36:01Zitat von: DS_Starter am 12 Februar 2024, 18:45:06Hallo minierm,
in deiner pvHistory gibt es den Tag 08 und 8, woher auch immer der Eintrag kommt ist er falsch/überflüssig.
Lösche ihn einfach mit:
set <name> reset pvHistory 8 (nicht 08)
Danke, Tag 8 ist gelöscht.
Ich weiss jetzt, warum es Tag 8 statt 08 gibt: Weil ich reset 8 10 statt 08 10 ausgeführt habe :-)
Bei der Eingabe müsste wohl generell auf zweistellig gewandelt werden damit solche Fälle abgefangen werden.
Guter Hinweis, danke.
Kommt mit in das nächste Update.
LG
Hi Heiko,
kurze Frage.
Habe heute gesehen dass in der Grafik Werte unter 1000 Wh nicht mehr angezeigt werden?
Ist das neu? Hab ich etwas verpasst?
Screenshot 2024-03-05 140310.png
Danke und Gruß,
Stefan
Hallo Stefan,
ZitatIst das neu? Hab ich etwas verpasst?
Weder noch.
Das ist eine Frage des Platzes. Du kannst mit dem Attr graphicBeamHeight spielen um dein Optimum zu finden.
Grüße,
Heiko
Ah jetzt ja ;-)
War schon meine Schuld.
Habe graphicBeamHeight heruntergesetzt damit es in mein Tablet UI passt.
Mit dem Standard von 200 sieht alles super aus.
Danke!
Hallo zusammen,
morgen früh ist eine neue Version im Update.
Maßgebliche Inhalte sind:
- in der Anzeige des Wetter/Strahlungs Alters der Daten wird die verwendete MOSMIX Variante beachtet
- im ConfigCheck wird die verwendete MOSMIX Variante (das DWD Attr forecastRefresh) sowie das Alter geprüft
- die Mouse-Over der relevanten LED's ist angepasst
- diverse Code Changes
Die Version findet ihr bereits jetzt in meinem contrib.
Dort liegt auch die aktuelle / getestete Entwicklungsversion von 55_DWD_OpenData.
Ab dieser DWD_OpenData Version ist das Attribut forecastRefresh für die MOSMIX Variante zu verwenden (1=MOSMIX_S, 6=MOSMIX_L).
Holt euch auch diese Version damit die Prüfungen/Anzeigen optimal zusammenarbeiten.
Grüße,
Heiko
werden, wenn mehrere dwd devices angelegt sind, die MOSMIX_S Werte nur einmal abgefragt? oder hintereinander? oder wenn es der Zufall es so will, alle zusammen?
Die DWD Devices haben einen zufällig gesteuerten Zeitversatz zueinander. Damit wird die Wahrscheinlichkeit minimiert gleichzeitig ablaufende Prozesse zu haben, ausgeschlossen ist es jedoch nicht.
Geplant ist mit einem DWD Device mehrere Stationen in einem Abruf zu parsen.
Hallo Heiko,
Da hier die Updates nur so sprudeln...
Ist in dem DWD Modul von heute die Implementierung von mumpitzstuff schon berücksichtigt (Post #988 im DWD Open Data Thread )?
Dann könnte ich es mal mit MOSMIX-S versuchen.
Grüße,
Guido.
Ups, das hatte ich nicht mehr auf dem Plan. Versuche ich morgen noch einzubauen und zu testen.
2024.03.08 00:34:57.200 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 522436
2024.03.08 01:32:15.371 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 526841
2024.03.08 02:38:16.330 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 531945
2024.03.08 03:36:30.862 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 537094
2024.03.08 04:38:19.103 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 541824
2024.03.08 05:37:08.583 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 546333
2024.03.08 06:37:47.719 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 551021
2024.03.08 07:39:29.588 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 555824
2024.03.08 08:39:51.839 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 560599
2024.03.08 09:31:01.400 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 564587
2024.03.08 10:39:00.090 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 569912
2024.03.08 11:32:42.392 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 574097
Mit der alten DWD version von dir und dem MOSMIX_S kam die Meldung nicht. Habe mal das timeout hochgesetzt. jetzt mal beobachten.
Mein RAM geht/ging auch nicht hoch, gar nicht, sieht so aus als wenn das Modul nix läd bzw. entpackt etc.
verbose 5 einschalten. Das ist die Wahrheit. ;)
@kask: Ram siehst du nicht mehr.
Es wird nun alles mit tempfile im filesystem /tmp/ gemacht.
Hab den Ram beobachtet und konnte nur minimale ausschläge sehen.
Hast du einen Raspberry mit SD musst du auf jeden fall den Timeout hochstellen.
Ich habe eine SSD dran und da geht es so.
Bei SD wäre ich auch vorsichtig mit tempfs auf der SD, könnte die Lebensdauer negativ beeinflussen.
Gruß,
Stefan
Mache ich hier grundlegend etwas falsch oder funktioniert das Modul nicht mit Sungrow und Batterie? Ich vermute stark das ich etwas falsch eingerichtet habe.
Im fhem sieht es so aus:
DWD_Solarforecast_ChrisH.png
das die Werte vom PV in Batterie und Haus in der Grafik nicht passen, siehe auch unten im Detail.
Ansicht aus der Sungrow iSolar Cloud:
App_Werte_ChrisH.png
Die Werte von der iSolarCloud entsprechen ziemlich gut denen die ich per modbus aus dem Wechselrichter auslese und mir dann in meinem Grafana Dashboard anzeigen lasse:
Grafana_Dashboard_ChrisH.png
Die Config sieht so aus:
define DWDSolarVorhersage SolarForecast
attr DWDSolarVorhersage ctrlWeatherDev1 DWD
attr DWDSolarVorhersage event-on-change-reading .*
attr DWDSolarVorhersage room PV
# FUUID 65c13ae3-f33f-b392-aa25-dd77aac21c22996e
# FVERSION 76_SolarForecast.pm:v1.16.3-s28553/2024-02-25
# LCACHEFILE last write time: 18:15:04 File: ./FHEM/FhemUtils/PVH_SolarForecast_DWDSolarVorhersage
# MODE Automatic - next Cycletime: 18:20:47
# MODEL DWD
# NAME DWDSolarVorhersage
# NR 275
# NTFY_ORDER 50-DWDSolarVorhersage
# STATE updated
# TYPE SolarForecast
# eventCount 7916
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV DWDSolarVorhersage
# SPGROOM
# VERSION 1.16.3
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.1
# OLDREADINGS:
# READINGS:
# 2024-03-08 18:19:37 Current_AutarkyRate 100 %
# 2024-03-08 18:19:37 Current_BatCharge 96.6 %
# 2024-03-08 18:19:37 Current_Consumption 1174 W
# 2024-03-08 18:19:37 Current_GridConsumption 0 W
# 2024-03-08 18:19:37 Current_GridFeedIn 0 W
# 2024-03-08 18:19:37 Current_PV 587 W
# 2024-03-08 18:19:37 Current_PowerBatIn 0 W
# 2024-03-08 18:19:37 Current_PowerBatOut 587 W
# 2024-03-08 18:19:37 Current_SelfConsumption 587 W
# 2024-03-08 18:19:37 Current_SelfConsumptionRate 100 %
# 2024-03-08 18:19:37 Current_Surplus 0 W
# 2024-03-08 18:00:00 LastHourGridconsumptionReal 500 Wh
# 2024-03-08 18:00:00 LastHourPVforecast 8 Wh
# 2024-03-08 18:00:00 LastHourPVreal 1000 Wh
# 2024-03-08 18:19:37 NextHours_Sum01_PVforecast 5 Wh
# 2024-03-08 18:19:37 NextHours_Sum02_PVforecast 5 Wh
# 2024-03-08 18:19:37 NextHours_Sum03_PVforecast 5 Wh
# 2024-03-08 18:19:37 NextHours_Sum04_ConsumptionForecast -448 Wh
# 2024-03-08 18:19:37 NextHours_Sum04_PVforecast 5 Wh
# 2024-03-08 18:19:37 RestOfDayConsumptionForecast -448 Wh
# 2024-03-08 18:19:37 RestOfDayPVforecast 5 Wh
# 2024-03-08 00:59:49 Today_Hour01_BatIn 0 Wh
# 2024-03-08 00:59:49 Today_Hour01_BatOut 0 Wh
# 2024-03-08 00:59:49 Today_Hour01_GridConsumption 0 Wh
# 2024-03-08 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2024-03-08 00:59:49 Today_Hour01_PVreal 0 Wh
# 2024-03-08 01:59:49 Today_Hour02_BatIn 0 Wh
# 2024-03-08 01:59:49 Today_Hour02_BatOut 0 Wh
# 2024-03-08 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2024-03-08 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2024-03-08 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-03-08 02:59:49 Today_Hour03_BatIn 0 Wh
# 2024-03-08 02:59:49 Today_Hour03_BatOut 0 Wh
# 2024-03-08 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2024-03-08 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-03-08 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-03-08 03:59:49 Today_Hour04_BatIn 0 Wh
# 2024-03-08 03:59:49 Today_Hour04_BatOut 0 Wh
# 2024-03-08 03:59:49 Today_Hour04_GridConsumption 0 Wh
# 2024-03-08 03:59:49 Today_Hour04_GridFeedIn 0 Wh
# 2024-03-08 03:59:49 Today_Hour04_PVreal 0 Wh
# 2024-03-08 04:59:56 Today_Hour05_BatIn 0 Wh
# 2024-03-08 04:59:56 Today_Hour05_BatOut 0 Wh
# 2024-03-08 04:59:56 Today_Hour05_GridConsumption 0 Wh
# 2024-03-08 04:59:56 Today_Hour05_GridFeedIn 0 Wh
# 2024-03-08 04:59:56 Today_Hour05_PVreal 0 Wh
# 2024-03-08 05:59:49 Today_Hour06_BatIn 0 Wh
# 2024-03-08 05:59:49 Today_Hour06_BatOut 0 Wh
# 2024-03-08 05:59:49 Today_Hour06_GridConsumption 0 Wh
# 2024-03-08 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2024-03-08 05:59:49 Today_Hour06_PVreal 0 Wh
# 2024-03-08 06:59:49 Today_Hour07_BatIn 0 Wh
# 2024-03-08 06:59:49 Today_Hour07_BatOut 0 Wh
# 2024-03-08 06:59:49 Today_Hour07_GridConsumption 0 Wh
# 2024-03-08 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2024-03-08 06:59:49 Today_Hour07_PVreal 0 Wh
# 2024-03-08 07:59:52 Today_Hour08_BatIn 0 Wh
# 2024-03-08 07:59:52 Today_Hour08_BatOut 0 Wh
# 2024-03-08 07:59:52 Today_Hour08_GridConsumption 0 Wh
# 2024-03-08 07:59:52 Today_Hour08_GridFeedIn 0 Wh
# 2024-03-08 07:59:52 Today_Hour08_PVforecast 8 Wh
# 2024-03-08 07:59:52 Today_Hour08_PVreal 0 Wh
# 2024-03-08 08:59:49 Today_Hour09_BatIn 0 Wh
# 2024-03-08 08:59:49 Today_Hour09_BatOut 0 Wh
# 2024-03-08 08:59:49 Today_Hour09_GridConsumption 0 Wh
# 2024-03-08 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2024-03-08 08:59:49 Today_Hour09_PVforecast 8 Wh
# 2024-03-08 08:59:49 Today_Hour09_PVreal 500 Wh
# 2024-03-08 09:59:49 Today_Hour10_BatIn 0 Wh
# 2024-03-08 09:59:49 Today_Hour10_BatOut 0 Wh
# 2024-03-08 09:59:49 Today_Hour10_GridConsumption 0 Wh
# 2024-03-08 09:59:49 Today_Hour10_GridFeedIn 0 Wh
# 2024-03-08 09:59:49 Today_Hour10_PVforecast 8 Wh
# 2024-03-08 09:59:49 Today_Hour10_PVreal 2400 Wh
# 2024-03-08 10:59:49 Today_Hour11_BatIn 0 Wh
# 2024-03-08 10:59:49 Today_Hour11_BatOut 0 Wh
# 2024-03-08 10:59:49 Today_Hour11_GridConsumption 0 Wh
# 2024-03-08 10:59:49 Today_Hour11_GridFeedIn 0 Wh
# 2024-03-08 10:59:49 Today_Hour11_PVforecast 8 Wh
# 2024-03-08 10:59:49 Today_Hour11_PVreal 1600 Wh
# 2024-03-08 11:59:49 Today_Hour12_BatIn 0 Wh
# 2024-03-08 11:59:49 Today_Hour12_BatOut 0 Wh
# 2024-03-08 11:59:49 Today_Hour12_GridConsumption 0 Wh
# 2024-03-08 11:59:49 Today_Hour12_GridFeedIn 0 Wh
# 2024-03-08 11:59:49 Today_Hour12_PVforecast 8 Wh
# 2024-03-08 11:59:49 Today_Hour12_PVreal 4300 Wh
# 2024-03-08 12:59:51 Today_Hour13_BatIn 0 Wh
# 2024-03-08 12:59:51 Today_Hour13_BatOut 0 Wh
# 2024-03-08 12:59:51 Today_Hour13_GridConsumption 1700 Wh
# 2024-03-08 12:59:51 Today_Hour13_GridFeedIn 0 Wh
# 2024-03-08 12:59:51 Today_Hour13_PVforecast 8 Wh
# 2024-03-08 12:59:51 Today_Hour13_PVreal 2400 Wh
# 2024-03-08 13:59:49 Today_Hour14_BatIn 0 Wh
# 2024-03-08 13:59:49 Today_Hour14_BatOut 0 Wh
# 2024-03-08 13:59:49 Today_Hour14_GridConsumption 2100 Wh
# 2024-03-08 13:59:49 Today_Hour14_GridFeedIn 0 Wh
# 2024-03-08 13:59:49 Today_Hour14_PVforecast 8 Wh
# 2024-03-08 13:59:49 Today_Hour14_PVreal 5300 Wh
# 2024-03-08 14:59:49 Today_Hour15_BatIn 0 Wh
# 2024-03-08 14:59:49 Today_Hour15_BatOut 0 Wh
# 2024-03-08 14:59:49 Today_Hour15_GridConsumption 3700 Wh
# 2024-03-08 14:59:49 Today_Hour15_GridFeedIn 100 Wh
# 2024-03-08 14:59:49 Today_Hour15_PVforecast 8 Wh
# 2024-03-08 14:59:49 Today_Hour15_PVreal 4900 Wh
# 2024-03-08 15:59:49 Today_Hour16_BatIn 0 Wh
# 2024-03-08 15:59:49 Today_Hour16_BatOut 0 Wh
# 2024-03-08 15:59:49 Today_Hour16_GridConsumption 1900 Wh
# 2024-03-08 15:59:49 Today_Hour16_GridFeedIn 0 Wh
# 2024-03-08 15:59:49 Today_Hour16_PVforecast 8 Wh
# 2024-03-08 15:59:49 Today_Hour16_PVreal 2200 Wh
# 2024-03-08 16:59:49 Today_Hour17_BatIn 0 Wh
# 2024-03-08 16:59:49 Today_Hour17_BatOut 0 Wh
# 2024-03-08 16:59:49 Today_Hour17_GridConsumption 2700 Wh
# 2024-03-08 16:59:49 Today_Hour17_GridFeedIn 0 Wh
# 2024-03-08 16:59:49 Today_Hour17_PVforecast 8 Wh
# 2024-03-08 16:59:49 Today_Hour17_PVreal 3200 Wh
# 2024-03-08 17:59:49 Today_Hour18_BatIn 0 Wh
# 2024-03-08 17:59:49 Today_Hour18_BatOut 0 Wh
# 2024-03-08 17:59:49 Today_Hour18_GridConsumption 500 Wh
# 2024-03-08 17:59:49 Today_Hour18_GridFeedIn 0 Wh
# 2024-03-08 17:59:49 Today_Hour18_PVforecast 8 Wh
# 2024-03-08 17:59:49 Today_Hour18_PVreal 1000 Wh
# 2024-03-08 18:19:37 Today_Hour19_BatIn 0 Wh
# 2024-03-08 18:19:37 Today_Hour19_BatOut 0 Wh
# 2024-03-08 18:19:37 Today_Hour19_GridConsumption 0 Wh
# 2024-03-08 18:19:37 Today_Hour19_GridFeedIn 0 Wh
# 2024-03-08 18:19:37 Today_Hour19_PVforecast 8 Wh
# 2024-03-08 18:19:37 Today_Hour19_PVreal 0 Wh
# 2024-03-08 18:19:37 Today_MaxPVforecast 8 Wh
# 2024-03-08 18:19:37 Today_MaxPVforecastTime 2024-03-08 07:00:00
# 2024-03-08 18:19:37 Today_PVforecast 96 Wh
# 2024-03-08 17:55:07 Today_PVreal 27800 Wh
# 2024-03-08 18:19:37 Today_SunRise 06:59
# 2024-03-08 18:19:37 Today_SunSet 18:26
# 2024-03-08 18:19:37 Tomorrow_ConsumptionForecast 5107 Wh
# 2024-03-08 18:19:37 Tomorrow_PVforecast 96 Wh
# 2024-03-08 18:19:37 Tomorrow_SunRise 06:57
# 2024-03-08 18:19:37 Tomorrow_SunSet 18:28
# 2024-02-10 12:19:01 currentBatteryDev SH08rt01 pin=Battery_power_in:W pout=Battery_power_out:W charge=Battery_Level cap:9600Wh
# 2024-02-07 10:18:55 currentInverterDev SH08rt01 pv=Total_active_power:W capacity=8kW etotal=Total_PV_Generation:kWh
# 2024-02-10 12:21:52 currentMeterDev SH08rt01 gcon=-gfeedin contotal=Total_Export_Energy:kWh gfeedin=-Export_Power:kWh feedtotal=Total_Import_Energy:kWh
# 2024-02-06 21:37:37 currentRadiationAPI DWD
# 2024-02-06 09:14:01 inverterStrings Süddach,Norddach
# 2024-02-19 09:43:55 moduleAzimuth Süddach=S Norddach=N
# 2024-02-19 09:43:55 moduleDeclination Süddach=30 Norddach=30
# 2024-02-08 20:36:32 modulePeakString Süddach=5.0 Norddach=4.6
# 2024-03-08 18:19:37 nextCycletime 18:20:47
# 2024-03-08 09:00:04 pvCorrectionFactor_09 1.50 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 20, Days in range: 1)
# 2024-03-08 09:00:04 pvCorrectionFactor_09_autocalc done
# 2024-03-08 10:00:04 pvCorrectionFactor_10 1.50 (automatic - old factor: 1, Sun Alt range: 20, Cloud range: 20, Days in range: 1)
# 2024-03-08 10:00:04 pvCorrectionFactor_10_autocalc done
# 2024-03-08 11:00:04 pvCorrectionFactor_11 1.50 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
# 2024-03-08 11:00:04 pvCorrectionFactor_11_autocalc done
# 2024-03-08 12:00:04 pvCorrectionFactor_12 1.50 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
# 2024-03-08 12:00:04 pvCorrectionFactor_12_autocalc done
# 2024-03-08 13:00:04 pvCorrectionFactor_13 1.50 (automatic - old factor: 1, Sun Alt range: 35, Cloud range: 20, Days in range: 1)
# 2024-03-08 13:00:04 pvCorrectionFactor_13_autocalc done
# 2024-03-08 14:00:04 pvCorrectionFactor_14 1.50 (automatic - old factor: 1, Sun Alt range: 35, Cloud range: 15, Days in range: 1)
# 2024-03-08 14:00:04 pvCorrectionFactor_14_autocalc done
# 2024-03-08 15:00:04 pvCorrectionFactor_15 1.50 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
# 2024-03-08 15:00:04 pvCorrectionFactor_15_autocalc done
# 2024-03-08 16:00:04 pvCorrectionFactor_16 1.50 (automatic - old factor: 1, Sun Alt range: 25, Cloud range: 20, Days in range: 1)
# 2024-03-08 16:00:04 pvCorrectionFactor_16_autocalc done
# 2024-03-08 17:00:04 pvCorrectionFactor_17 1.50 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 15, Days in range: 1)
# 2024-03-08 17:00:04 pvCorrectionFactor_17_autocalc done
# 2024-03-08 18:00:04 pvCorrectionFactor_18 1.50 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 15, Days in range: 1)
# 2024-03-08 18:00:04 pvCorrectionFactor_18_autocalc done
# 2024-03-08 18:19:37 pvCorrectionFactor_Auto on_complex_ai
# 2024-03-08 18:19:38 state updated
#
setstate DWDSolarVorhersage updated
setstate DWDSolarVorhersage 2024-03-05 21:40:15 .associatedWith DWD SH08rt01
setstate DWDSolarVorhersage 2024-03-08 18:19:37 .lastupdateForecastValues 1709918377
setstate DWDSolarVorhersage 2024-03-08 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 04:00:04 .pvCorrectionFactor_04_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 04:00:04 .pvCorrectionFactor_04_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 05:00:04 .pvCorrectionFactor_05_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 05:00:04 .pvCorrectionFactor_05_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 08:00:04 .pvCorrectionFactor_08_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 08:00:04 .pvCorrectionFactor_08_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 10:00:04 .pvCorrectionFactor_10_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 10:00:04 .pvCorrectionFactor_10_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 11:00:04 .pvCorrectionFactor_11_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 11:00:04 .pvCorrectionFactor_11_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 12:00:04 .pvCorrectionFactor_12_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 12:00:04 .pvCorrectionFactor_12_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 13:00:04 .pvCorrectionFactor_13_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 13:00:04 .pvCorrectionFactor_13_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 14:00:04 .pvCorrectionFactor_14_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 14:00:04 .pvCorrectionFactor_14_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 15:00:04 .pvCorrectionFactor_15_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 15:00:04 .pvCorrectionFactor_15_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 16:00:04 .pvCorrectionFactor_16_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 16:00:04 .pvCorrectionFactor_16_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 17:00:04 .pvCorrectionFactor_17_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 17:00:04 .pvCorrectionFactor_17_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate DWDSolarVorhersage 2024-03-08 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate DWDSolarVorhersage 2024-03-08 18:19:37 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate DWDSolarVorhersage 2024-03-08 01:00:04 .signaldone_01 done
setstate DWDSolarVorhersage 2024-03-08 02:00:04 .signaldone_02 done
setstate DWDSolarVorhersage 2024-03-08 03:00:04 .signaldone_03 done
setstate DWDSolarVorhersage 2024-03-08 04:00:04 .signaldone_04 done
setstate DWDSolarVorhersage 2024-03-08 05:00:04 .signaldone_05 done
setstate DWDSolarVorhersage 2024-03-08 06:00:04 .signaldone_06 done
setstate DWDSolarVorhersage 2024-03-08 07:00:04 .signaldone_07 done
setstate DWDSolarVorhersage 2024-03-08 08:00:04 .signaldone_08 done
setstate DWDSolarVorhersage 2024-03-08 09:00:04 .signaldone_09 done
setstate DWDSolarVorhersage 2024-03-08 10:00:04 .signaldone_10 done
setstate DWDSolarVorhersage 2024-03-08 11:00:04 .signaldone_11 done
setstate DWDSolarVorhersage 2024-03-08 12:00:04 .signaldone_12 done
setstate DWDSolarVorhersage 2024-03-08 13:00:04 .signaldone_13 done
setstate DWDSolarVorhersage 2024-03-08 14:00:04 .signaldone_14 done
setstate DWDSolarVorhersage 2024-03-08 15:00:04 .signaldone_15 done
setstate DWDSolarVorhersage 2024-03-08 16:00:04 .signaldone_16 done
setstate DWDSolarVorhersage 2024-03-08 17:00:04 .signaldone_17 done
setstate DWDSolarVorhersage 2024-03-08 18:00:04 .signaldone_18 done
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_AutarkyRate 100 %
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_BatCharge 96.6 %
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_Consumption 1174 W
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_GridConsumption 0 W
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_GridFeedIn 0 W
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_PV 587 W
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_PowerBatIn 0 W
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_PowerBatOut 587 W
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_SelfConsumption 587 W
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_SelfConsumptionRate 100 %
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Current_Surplus 0 W
setstate DWDSolarVorhersage 2024-03-08 18:00:00 LastHourGridconsumptionReal 500 Wh
setstate DWDSolarVorhersage 2024-03-08 18:00:00 LastHourPVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 18:00:00 LastHourPVreal 1000 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 NextHours_Sum01_PVforecast 5 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 NextHours_Sum02_PVforecast 5 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 NextHours_Sum03_PVforecast 5 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 NextHours_Sum04_ConsumptionForecast -448 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 NextHours_Sum04_PVforecast 5 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 RestOfDayConsumptionForecast -448 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 RestOfDayPVforecast 5 Wh
setstate DWDSolarVorhersage 2024-03-08 00:59:49 Today_Hour01_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 00:59:49 Today_Hour01_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 00:59:49 Today_Hour01_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 00:59:49 Today_Hour01_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 01:59:49 Today_Hour02_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 01:59:49 Today_Hour02_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 01:59:49 Today_Hour02_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 02:59:49 Today_Hour03_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 02:59:49 Today_Hour03_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 02:59:49 Today_Hour03_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 03:59:49 Today_Hour04_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 03:59:49 Today_Hour04_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 03:59:49 Today_Hour04_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 03:59:49 Today_Hour04_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 03:59:49 Today_Hour04_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 04:59:56 Today_Hour05_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 04:59:56 Today_Hour05_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 04:59:56 Today_Hour05_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 04:59:56 Today_Hour05_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 04:59:56 Today_Hour05_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 05:59:49 Today_Hour06_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 05:59:49 Today_Hour06_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 05:59:49 Today_Hour06_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 05:59:49 Today_Hour06_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 06:59:49 Today_Hour07_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 06:59:49 Today_Hour07_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 06:59:49 Today_Hour07_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 06:59:49 Today_Hour07_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 07:59:52 Today_Hour08_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 07:59:52 Today_Hour08_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 07:59:52 Today_Hour08_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 07:59:52 Today_Hour08_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 07:59:52 Today_Hour08_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 07:59:52 Today_Hour08_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 08:59:49 Today_Hour09_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 08:59:49 Today_Hour09_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 08:59:49 Today_Hour09_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 08:59:49 Today_Hour09_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 08:59:49 Today_Hour09_PVreal 500 Wh
setstate DWDSolarVorhersage 2024-03-08 09:59:49 Today_Hour10_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 09:59:49 Today_Hour10_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 09:59:49 Today_Hour10_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 09:59:49 Today_Hour10_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 09:59:49 Today_Hour10_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 09:59:49 Today_Hour10_PVreal 2400 Wh
setstate DWDSolarVorhersage 2024-03-08 10:59:49 Today_Hour11_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 10:59:49 Today_Hour11_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 10:59:49 Today_Hour11_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 10:59:49 Today_Hour11_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 10:59:49 Today_Hour11_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 10:59:49 Today_Hour11_PVreal 1600 Wh
setstate DWDSolarVorhersage 2024-03-08 11:59:49 Today_Hour12_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 11:59:49 Today_Hour12_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 11:59:49 Today_Hour12_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 11:59:49 Today_Hour12_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 11:59:49 Today_Hour12_PVreal 4300 Wh
setstate DWDSolarVorhersage 2024-03-08 12:59:51 Today_Hour13_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 12:59:51 Today_Hour13_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 12:59:51 Today_Hour13_GridConsumption 1700 Wh
setstate DWDSolarVorhersage 2024-03-08 12:59:51 Today_Hour13_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 12:59:51 Today_Hour13_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 12:59:51 Today_Hour13_PVreal 2400 Wh
setstate DWDSolarVorhersage 2024-03-08 13:59:49 Today_Hour14_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 13:59:49 Today_Hour14_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 13:59:49 Today_Hour14_GridConsumption 2100 Wh
setstate DWDSolarVorhersage 2024-03-08 13:59:49 Today_Hour14_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 13:59:49 Today_Hour14_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 13:59:49 Today_Hour14_PVreal 5300 Wh
setstate DWDSolarVorhersage 2024-03-08 14:59:49 Today_Hour15_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 14:59:49 Today_Hour15_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 14:59:49 Today_Hour15_GridConsumption 3700 Wh
setstate DWDSolarVorhersage 2024-03-08 14:59:49 Today_Hour15_GridFeedIn 100 Wh
setstate DWDSolarVorhersage 2024-03-08 14:59:49 Today_Hour15_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 14:59:49 Today_Hour15_PVreal 4900 Wh
setstate DWDSolarVorhersage 2024-03-08 15:59:49 Today_Hour16_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 15:59:49 Today_Hour16_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 15:59:49 Today_Hour16_GridConsumption 1900 Wh
setstate DWDSolarVorhersage 2024-03-08 15:59:49 Today_Hour16_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 15:59:49 Today_Hour16_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 15:59:49 Today_Hour16_PVreal 2200 Wh
setstate DWDSolarVorhersage 2024-03-08 16:59:49 Today_Hour17_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 16:59:49 Today_Hour17_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 16:59:49 Today_Hour17_GridConsumption 2700 Wh
setstate DWDSolarVorhersage 2024-03-08 16:59:49 Today_Hour17_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 16:59:49 Today_Hour17_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 16:59:49 Today_Hour17_PVreal 3200 Wh
setstate DWDSolarVorhersage 2024-03-08 17:59:49 Today_Hour18_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 17:59:49 Today_Hour18_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 17:59:49 Today_Hour18_GridConsumption 500 Wh
setstate DWDSolarVorhersage 2024-03-08 17:59:49 Today_Hour18_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 17:59:49 Today_Hour18_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 17:59:49 Today_Hour18_PVreal 1000 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_Hour19_BatIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_Hour19_BatOut 0 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_Hour19_GridConsumption 0 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_Hour19_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_Hour19_PVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_Hour19_PVreal 0 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_MaxPVforecast 8 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_MaxPVforecastTime 2024-03-08 07:00:00
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_PVforecast 96 Wh
setstate DWDSolarVorhersage 2024-03-08 17:55:07 Today_PVreal 27800 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_SunRise 06:59
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Today_SunSet 18:26
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Tomorrow_ConsumptionForecast 5107 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Tomorrow_PVforecast 96 Wh
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Tomorrow_SunRise 06:57
setstate DWDSolarVorhersage 2024-03-08 18:19:37 Tomorrow_SunSet 18:28
setstate DWDSolarVorhersage 2024-02-10 12:19:01 currentBatteryDev SH08rt01 pin=Battery_power_in:W pout=Battery_power_out:W charge=Battery_Level cap:9600Wh
setstate DWDSolarVorhersage 2024-02-07 10:18:55 currentInverterDev SH08rt01 pv=Total_active_power:W capacity=8kW etotal=Total_PV_Generation:kWh
setstate DWDSolarVorhersage 2024-02-10 12:21:52 currentMeterDev SH08rt01 gcon=-gfeedin contotal=Total_Export_Energy:kWh gfeedin=-Export_Power:kWh feedtotal=Total_Import_Energy:kWh
setstate DWDSolarVorhersage 2024-02-06 21:37:37 currentRadiationAPI DWD
setstate DWDSolarVorhersage 2024-02-06 09:14:01 inverterStrings Süddach,Norddach
setstate DWDSolarVorhersage 2024-02-19 09:43:55 moduleAzimuth Süddach=S Norddach=N
setstate DWDSolarVorhersage 2024-02-19 09:43:55 moduleDeclination Süddach=30 Norddach=30
setstate DWDSolarVorhersage 2024-02-08 20:36:32 modulePeakString Süddach=5.0 Norddach=4.6
setstate DWDSolarVorhersage 2024-03-08 18:19:37 nextCycletime 18:20:47
setstate DWDSolarVorhersage 2024-03-08 09:00:04 pvCorrectionFactor_09 1.50 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 20, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 09:00:04 pvCorrectionFactor_09_autocalc done
setstate DWDSolarVorhersage 2024-03-08 10:00:04 pvCorrectionFactor_10 1.50 (automatic - old factor: 1, Sun Alt range: 20, Cloud range: 20, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 10:00:04 pvCorrectionFactor_10_autocalc done
setstate DWDSolarVorhersage 2024-03-08 11:00:04 pvCorrectionFactor_11 1.50 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 11:00:04 pvCorrectionFactor_11_autocalc done
setstate DWDSolarVorhersage 2024-03-08 12:00:04 pvCorrectionFactor_12 1.50 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 12:00:04 pvCorrectionFactor_12_autocalc done
setstate DWDSolarVorhersage 2024-03-08 13:00:04 pvCorrectionFactor_13 1.50 (automatic - old factor: 1, Sun Alt range: 35, Cloud range: 20, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 13:00:04 pvCorrectionFactor_13_autocalc done
setstate DWDSolarVorhersage 2024-03-08 14:00:04 pvCorrectionFactor_14 1.50 (automatic - old factor: 1, Sun Alt range: 35, Cloud range: 15, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 14:00:04 pvCorrectionFactor_14_autocalc done
setstate DWDSolarVorhersage 2024-03-08 15:00:04 pvCorrectionFactor_15 1.50 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 15:00:04 pvCorrectionFactor_15_autocalc done
setstate DWDSolarVorhersage 2024-03-08 16:00:04 pvCorrectionFactor_16 1.50 (automatic - old factor: 1, Sun Alt range: 25, Cloud range: 20, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 16:00:04 pvCorrectionFactor_16_autocalc done
setstate DWDSolarVorhersage 2024-03-08 17:00:04 pvCorrectionFactor_17 1.50 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 15, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 17:00:04 pvCorrectionFactor_17_autocalc done
setstate DWDSolarVorhersage 2024-03-08 18:00:04 pvCorrectionFactor_18 1.50 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 15, Days in range: 1)
setstate DWDSolarVorhersage 2024-03-08 18:00:04 pvCorrectionFactor_18_autocalc done
setstate DWDSolarVorhersage 2024-03-08 18:19:37 pvCorrectionFactor_Auto on_complex_ai
setstate DWDSolarVorhersage 2024-03-08 18:19:38 state updated
auf jedenfall kommen mir diese Werte teilweise komisch vor:
# 2024-03-08 18:19:37 Current_Consumption 1174 W <<-- das ist 2*587W und falsch da doppelt so hoch
# 2024-03-08 18:19:37 Current_GridConsumption 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_GridFeedIn 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_PV 587 W <<-- nicht wirklich korrekt, das ist der Wert der aus der Batterie kommt
# 2024-03-08 18:19:37 Current_PowerBatIn 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_PowerBatOut 587 W <<-- korrekt
# 2024-03-08 18:19:37 Current_SelfConsumption 587 W <<-- korrekt
Ich hoffe ich habe da etwas einfaches falsch verstanden und fehl konfiguriert.
Christian
Habe mal neu gestartet vermutlich habe ich gestern nur einen reload gemacht. Nun geht der RAM wirklich nicht mehr soooo hoch. Man sieht Ausschläge aber das hält sich wirklich in Grenzen.
Habe auch ein Raspberry mit SSD. werde jetzt mal den timeout wieder auf standard setzen. Vieleicht lag es ja nur an keinen restart.
Zitat# 2024-03-08 18:19:37 Current_Consumption 1174 W <<-- das ist 2*587W und falsch da doppelt so hoch
# 2024-03-08 18:19:37 Current_GridConsumption 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_GridFeedIn 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_PV 587 W <<-- nicht wirklich korrekt, das ist der Wert der aus der Batterie kommt
# 2024-03-08 18:19:37 Current_PowerBatIn 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_PowerBatOut 587 W <<-- korrekt
# 2024-03-08 18:19:37 Current_SelfConsumption 587 W <<-- korrekt
Sicher das du die Variabelen richtig ausliest? da ist ziemlich oft 587 vertreten und auch 2*587 (wie du schon gemerkt hast)
dein
currentMeterDev SH08rt01 gcon=-gfeedin contotal=Total_Export_Energy:kWh gfeedin=-Export_Power:kWh feedtotal=Total_Import_Energy:kWhsicher das das so Korrekt ist?
13036 Total Import Energy Gekaufte Energie gesamt
13045 Total export energy Energie Netzeinspeisung gesamt
ich denke da ist eher:
currentMeterDev SH08rt01 gcon=-gfeedin contotal=Total_Import_Energy:kWh gfeedin=-Export_Power:kWh feedtotal=Total_Export_Energy:kWh
bei mir ist das Modul im ConfigCheck etwas unglücklich über das DWD Device.
The device "DWD_Forecast" uses "MOSMIX_L" which is only updated by DWD every 6 hours.
erfülltVorschlag ist "forecastRefresh -> set attribute to "1" if possible" Das Attribut ist aber nicht verfügbar im DWD Device.
Was kann ich da tun? Update check habe ich eben erst gemacht.
List Solcast:
define solcast SolarForecast
attr solcast DbLogExclude .*
attr solcast DbLogInclude Current_.*
attr solcast affect70percentRule 0
attr solcast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr solcast consumer01 Stromverbrauch_Zaehler2 type=heater power=2100 icon=sani_floor_heating pcurr=P_act_tot-get:kW etotal=total-get:kWh
attr solcast consumer02 Shelly_Waschmaschine type=washingmachine power=3000 mintime=60 pcurr=power:W etotal=energykwh:kWh icon=scene_washing_machine
attr solcast consumer03 Shelly_Trockner type=dryer power=3000 mintime=60 pcurr=power:W etotal=energykwh:kWh icon=scene_laundry_room
attr solcast consumer04 HTTPMOD_Wallbox type=charger power=0 pcurr=devices_01_power_w:W etotal=devices_01_total_energy:kWh icon=car_in
attr solcast consumerLegend icon_bottom
attr solcast ctrlNextDayForecastReadings 12,13
attr solcast ctrlWeatherDev1 DWD_Forecast
attr solcast event-on-change-reading .*
attr solcast flowGraphicAnimate 1
attr solcast flowGraphicSize 600
attr solcast graphicBeam1Color 38DE4D
attr solcast graphicBeam1Content pvForecast
attr solcast graphicBeam1FontColor 000000
attr solcast graphicBeam2Color FF8E2B
attr solcast graphicBeam2Content pvReal
attr solcast graphicBeam2FontColor 000000
attr solcast graphicHourCount 30
attr solcast graphicLayoutType double
attr solcast graphicWeatherColor FFC933
attr solcast room Technik_PV
# FUUID 62487147-f33f-ae17-74c6-e655d31e5ac447b7
# FVERSION 76_SolarForecast.pm:v1.16.5-s28613/2024-03-07
# LCACHEFILE last write time: 10:16:49 File: ./FHEM/FhemUtils/PVH_SolarForecast_solcast
# MODE Automatic - next Cycletime: 10:17:55
# MODEL DWD
# NAME solcast
# NOTIFYDEV Stromverbrauch_Zaehler2,Shelly_Waschmaschine,Shelly_Trockner,HTTPMOD_Wallbox
# NR 395
# NTFY_ORDER 50-solcast
# STATE wrote cachefile pvhist successfully
# TYPE SolarForecast
# eventCount 182
# HELPER:
# 01M15DONE 1
# 02M15DONE 1
# 03M15DONE 1
# 04M15DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV solcast
# SPGROOM
# VERSION 1.16.5
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.1
# Helper:
# DBLOG:
# Current_AutarkyRate:
# logdb:
# TIME 1709975455.19881
# VALUE 100
# Current_BatCharge:
# logdb:
# TIME 1709975525.21565
# VALUE 31
# Current_Consumption:
# logdb:
# TIME 1709975806.2148
# VALUE 3464
# Current_GridConsumption:
# logdb:
# TIME 1709975736.73002
# VALUE 0
# Current_GridFeedIn:
# logdb:
# TIME 1709975806.2148
# VALUE 26
# Current_PV:
# logdb:
# TIME 1709975806.2148
# VALUE 5064
# Current_PowerBatIn:
# logdb:
# TIME 1709975806.2148
# VALUE 1574
# Current_PowerBatOut:
# logdb:
# TIME 1709975806.2148
# VALUE 0
# Current_SelfConsumption:
# logdb:
# TIME 1709975806.2148
# VALUE 3464
# Current_SelfConsumptionRate:
# logdb:
# TIME 1709975806.2148
# VALUE 68
# Current_Surplus:
# logdb:
# TIME 1709975806.2148
# VALUE 1600
# OLDREADINGS:
# READINGS:
# 2024-03-09 10:16:46 Current_AutarkyRate 100 %
# 2024-03-09 10:16:46 Current_BatCharge 31 %
# 2024-03-09 10:16:46 Current_Consumption 3464 W
# 2024-03-09 10:16:46 Current_GridConsumption 0 W
# 2024-03-09 10:16:46 Current_GridFeedIn 26 W
# 2024-03-09 10:16:46 Current_PV 5064 W
# 2024-03-09 10:16:46 Current_PowerBatIn 1574 W
# 2024-03-09 10:16:46 Current_PowerBatOut 0 W
# 2024-03-09 10:16:46 Current_SelfConsumption 3464 W
# 2024-03-09 10:16:46 Current_SelfConsumptionRate 68 %
# 2024-03-09 10:16:46 Current_Surplus 1600 W
# 2024-03-09 10:00:00 LastHourGridconsumptionReal 0 Wh
# 2024-03-09 10:00:00 LastHourPVforecast 3680 Wh
# 2024-03-09 10:00:00 LastHourPVreal 3900 Wh
# 2024-03-09 10:16:46 NextHours_Sum01_PVforecast 4648 Wh
# 2024-03-09 10:16:46 NextHours_Sum02_PVforecast 8863 Wh
# 2024-03-09 10:16:46 NextHours_Sum03_PVforecast 13377 Wh
# 2024-03-09 10:16:46 NextHours_Sum04_ConsumptionForecast 4086 Wh
# 2024-03-09 10:16:46 NextHours_Sum04_PVforecast 18131 Wh
# 2024-03-09 10:16:46 RestOfDayConsumptionForecast 18681 Wh
# 2024-03-09 10:16:46 RestOfDayPVforecast 26425 Wh
# 2024-03-09 00:59:53 Today_Hour01_BatIn 0 Wh
# 2024-03-09 00:59:53 Today_Hour01_BatOut 0 Wh
# 2024-03-09 00:59:53 Today_Hour01_GridConsumption 0 Wh
# 2024-03-09 00:59:53 Today_Hour01_GridFeedIn 0 Wh
# 2024-03-09 00:59:53 Today_Hour01_PVreal 0 Wh
# 2024-03-09 01:59:49 Today_Hour02_BatIn 0 Wh
# 2024-03-09 01:59:49 Today_Hour02_BatOut 500 Wh
# 2024-03-09 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2024-03-09 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2024-03-09 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-03-09 02:59:49 Today_Hour03_BatIn 0 Wh
# 2024-03-09 02:59:49 Today_Hour03_BatOut 300 Wh
# 2024-03-09 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2024-03-09 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-03-09 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-03-09 03:59:50 Today_Hour04_BatIn 0 Wh
# 2024-03-09 03:59:50 Today_Hour04_BatOut 300 Wh
# 2024-03-09 03:59:50 Today_Hour04_GridConsumption 0 Wh
# 2024-03-09 03:59:50 Today_Hour04_GridFeedIn 0 Wh
# 2024-03-09 03:59:50 Today_Hour04_PVreal 0 Wh
# 2024-03-09 04:59:49 Today_Hour05_BatIn 0 Wh
# 2024-03-09 04:59:49 Today_Hour05_BatOut 1700 Wh
# 2024-03-09 04:59:49 Today_Hour05_GridConsumption 0 Wh
# 2024-03-09 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2024-03-09 04:59:49 Today_Hour05_PVreal 0 Wh
# 2024-03-09 05:59:50 Today_Hour06_BatIn 0 Wh
# 2024-03-09 05:59:50 Today_Hour06_BatOut 1600 Wh
# 2024-03-09 05:59:50 Today_Hour06_GridConsumption 0 Wh
# 2024-03-09 05:59:50 Today_Hour06_GridFeedIn 0 Wh
# 2024-03-09 05:59:50 Today_Hour06_PVreal 0 Wh
# 2024-03-09 06:59:49 Today_Hour07_BatIn 0 Wh
# 2024-03-09 06:59:49 Today_Hour07_BatOut 1300 Wh
# 2024-03-09 06:59:49 Today_Hour07_GridConsumption 500 Wh
# 2024-03-09 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2024-03-09 06:59:49 Today_Hour07_PVforecast 45 Wh
# 2024-03-09 06:59:49 Today_Hour07_PVreal 0 Wh
# 2024-03-09 07:59:53 Today_Hour08_BatIn 0 Wh
# 2024-03-09 07:59:53 Today_Hour08_BatOut 100 Wh
# 2024-03-09 07:59:53 Today_Hour08_GridConsumption 500 Wh
# 2024-03-09 07:59:53 Today_Hour08_GridFeedIn 0 Wh
# 2024-03-09 07:59:53 Today_Hour08_PVforecast 393 Wh
# 2024-03-09 07:59:53 Today_Hour08_PVreal 230 Wh
# 2024-03-09 08:59:49 Today_Hour09_BatIn 900 Wh
# 2024-03-09 08:59:49 Today_Hour09_BatOut 0 Wh
# 2024-03-09 08:59:49 Today_Hour09_GridConsumption 0 Wh
# 2024-03-09 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2024-03-09 08:59:49 Today_Hour09_PVforecast 1517 Wh
# 2024-03-09 08:59:49 Today_Hour09_PVreal 1470 Wh
# 2024-03-09 09:59:49 Today_Hour10_BatIn 500 Wh
# 2024-03-09 09:59:49 Today_Hour10_BatOut 200 Wh
# 2024-03-09 09:59:49 Today_Hour10_GridConsumption 0 Wh
# 2024-03-09 09:59:49 Today_Hour10_GridFeedIn 0 Wh
# 2024-03-09 09:59:49 Today_Hour10_PVforecast 3680 Wh
# 2024-03-09 09:59:49 Today_Hour10_PVreal 3900 Wh
# 2024-03-09 10:16:46 Today_Hour11_BatIn 200 Wh
# 2024-03-09 10:16:46 Today_Hour11_BatOut 100 Wh
# 2024-03-09 10:16:46 Today_Hour11_GridConsumption 0 Wh
# 2024-03-09 10:16:46 Today_Hour11_GridFeedIn 0 Wh
# 2024-03-09 10:16:46 Today_Hour11_PVforecast 4830 Wh
# 2024-03-09 10:16:46 Today_Hour11_PVreal 1380 Wh
# 2024-03-09 10:16:46 Today_Hour12_PVforecast 4189 Wh
# 2024-03-09 10:16:46 Today_Hour13_PVforecast 4281 Wh
# 2024-03-09 10:16:46 Today_Hour14_PVforecast 5103 Wh
# 2024-03-09 10:16:46 Today_Hour15_PVforecast 3870 Wh
# 2024-03-09 10:16:46 Today_Hour16_PVforecast 3433 Wh
# 2024-03-09 10:16:46 Today_Hour17_PVforecast 1648 Wh
# 2024-03-09 10:16:46 Today_Hour18_PVforecast 440 Wh
# 2024-03-09 10:16:46 Today_MaxPVforecast 5103 Wh
# 2024-03-09 10:16:46 Today_MaxPVforecastTime 2024-03-09 13:00:00
# 2024-03-09 10:16:46 Today_PVforecast 33429 Wh
# 2024-03-09 10:16:46 Today_PVreal 6980 Wh
# 2024-03-09 10:16:46 Today_SunRise 06:39
# 2024-03-09 10:16:46 Today_SunSet 18:11
# 2024-03-09 10:16:46 Tomorrow_ConsumptionForecast 31919 Wh
# 2024-03-09 10:16:46 Tomorrow_Hour12_PVforecast 5360 Wh
# 2024-03-09 10:16:46 Tomorrow_Hour13_PVforecast 5259 Wh
# 2024-03-09 10:16:46 Tomorrow_PVforecast 32662 Wh
# 2024-03-09 10:16:46 Tomorrow_SunRise 06:37
# 2024-03-09 10:16:46 Tomorrow_SunSet 18:13
# 2024-03-09 10:16:46 consumer01 name='Stromverbrauch_Zaehler2' state='unknown' mode='can' planningstate='planned'
# 2024-03-09 10:16:46 consumer01_currentPower 10 W
# 2024-03-09 10:16:46 consumer01_planned_start 09.03.2024 10:15:36
# 2024-03-09 10:16:46 consumer01_planned_stop 09.03.2024 14:15:36
# 2024-03-09 10:16:46 consumer02 name='Shelly_Waschmaschine' state='on' mode='can' planningstate='planned'
# 2024-03-09 10:16:46 consumer02_currentPower 0 W
# 2024-03-09 10:16:46 consumer02_planned_start 09.03.2024 10:15:36
# 2024-03-09 10:16:46 consumer02_planned_stop 09.03.2024 11:15:36
# 2024-03-09 10:16:46 consumer03 name='Shelly_Trockner' state='on' mode='can' planningstate='planned'
# 2024-03-09 10:16:46 consumer03_currentPower 0 W
# 2024-03-09 10:16:46 consumer03_planned_start 09.03.2024 10:15:36
# 2024-03-09 10:16:46 consumer03_planned_stop 09.03.2024 11:15:36
# 2024-03-09 10:16:46 consumer04 name='HTTPMOD_Wallbox' state='unknown' mode='can' planningstate='planned'
# 2024-03-09 10:16:46 consumer04_currentPower 3771 W
# 2024-03-09 10:16:46 consumer04_planned_start 09.03.2024 10:15:36
# 2024-03-09 10:16:46 consumer04_planned_stop 09.03.2024 12:15:36
# 2023-09-16 07:21:23 currentBatteryDev BatterieWR pin=BatteryPowerBMS2:kW pout=-pin intotal=BatteryChargeTotal:kWh outtotal=BatteryDischargeTotal:kWh charge=BatteryCapacity
# 2022-04-03 18:59:44 currentInverterDev Stromverbrauch_Zaehler11 pv=P_act-get:kW etotal=total-get:kWh
# 2022-04-03 13:38:09 currentMeterDev Stromverbrauch_Zaehler1_EHZ gcon=aktuellerverbrauch-get:kW contotal=total-get:kWh gfeedin=-gcon feedtotal=ueberschuss-total-get:kWh
# 2023-11-21 21:30:01 currentRadiationAPI DWD_Forecast
# 2023-07-20 21:35:59 inverterStrings Hausdach,Hausdach2,GartenhausSued,GartenhausNord
# 2024-02-27 16:02:59 moduleAzimuth Hausdach=S Hausdach2=S GartenhausSued=S GartenhausNord=N
# 2024-02-27 16:02:59 moduleDeclination Hausdach=20 Hausdach2=20 GartenhausSued=10 GartenhausNord=10
# 2023-07-20 21:36:24 modulePeakString Hausdach=4.86 Hausdach2=2.49 GartenhausSued=0.6 GartenhausNord=0.6
# 2024-03-09 10:16:46 nextCycletime 10:17:55
# 2023-03-30 17:11:04 nextPolltime 17:12:14
# 2024-03-09 08:00:05 pvCorrectionFactor_08 0.71 (automatic - old factor: 0.83, Sun Alt range: 10, Cloud range: 50, Days in range: 1)
# 2024-03-09 08:00:05 pvCorrectionFactor_08_autocalc done
# 2024-03-09 09:00:04 pvCorrectionFactor_09 1.09 (automatic - old factor: 1.20, Sun Alt range: 15, Cloud range: 50, Days in range: 3)
# 2024-03-09 09:00:04 pvCorrectionFactor_09_autocalc done
# 2024-03-09 10:00:04 pvCorrectionFactor_10 1.33 (automatic - old factor: 1.40, Sun Alt range: 25, Cloud range: 55, Days in range: 1)
# 2024-03-09 10:00:04 pvCorrectionFactor_10_autocalc done
# 2024-03-09 10:16:46 pvCorrectionFactor_Auto on_complex_ai
# 2024-03-09 10:16:49 state wrote cachefile pvhist successfully
#
setstate solcast wrote cachefile pvhist successfully
setstate solcast 2024-03-09 08:46:52 .associatedWith Stromverbrauch_Zaehler2 Shelly_Waschmaschine Shelly_Trockner HTTPMOD_Wallbox DWD_Forecast Stromverbrauch_Zaehler11 Stromverbrauch_Zaehler1_EHZ BatterieWR
Hier noch der Rest (der Post wäre sonst zulange)
List DWD_Forecast
define DWD_Forecast DWD_OpenData
attr DWD_Forecast DbLogExclude .*
attr DWD_Forecast comment N3309 wäre Lauf/Heuchling, 10763 ist Nürnberg, P267 Hienberg
attr DWD_Forecast event-on-change-reading Rad1h,TTT,Neff,R600
attr DWD_Forecast forecastDays 1
attr DWD_Forecast forecastProperties Rad1h,TTT,Neff,R600,R101,wwM,ww,RRS1c,SunUp,SunRise,SunSet,RR1c
attr DWD_Forecast forecastResolution 1
attr DWD_Forecast forecastStation P267
attr DWD_Forecast room Versuche
# FHEM_TZ
# FUUID 621bd365-f33f-ae17-edf6-d17e84dd892bee66
# NAME DWD_Forecast
# NR 386
# STATE forecast updated
# TYPE DWD_OpenData
# VERSION 1.016003
# READINGS:
# 2024-03-09 05:00:05 fc0_0_Neff 13
# 2024-03-09 05:00:05 fc0_0_R101 0.00
# 2024-03-09 05:00:05 fc0_0_RR1c 0.00
# 2024-03-09 05:00:05 fc0_0_RRS1c 0.00
# 2024-03-09 05:00:05 fc0_0_Rad1h 0.00
# 2024-03-09 05:00:05 fc0_0_SunUp 0
# 2024-03-09 05:00:05 fc0_0_TTT 2.70
# 2024-03-09 05:00:05 fc0_0_time 00:00
# 2024-03-09 05:00:05 fc0_0_ww 0
# 2024-03-09 05:00:05 fc0_0_wwM 0.00
# 2024-03-09 10:00:05 fc0_10_Neff 53
# 2024-03-09 10:00:05 fc0_10_R101 1.00
# 2024-03-09 10:00:05 fc0_10_RR1c 0.00
# 2024-03-09 10:00:05 fc0_10_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_10_Rad1h 970.00
# 2024-03-09 10:00:05 fc0_10_SunUp 1
# 2024-03-09 10:00:05 fc0_10_TTT 5.60
# 2024-03-09 10:00:05 fc0_10_time 10:00
# 2024-03-09 10:00:05 fc0_10_ww 1
# 2024-03-09 10:00:05 fc0_10_wwM 0.00
# 2024-03-09 10:00:05 fc0_11_Neff 48
# 2024-03-09 10:00:05 fc0_11_R101 1.00
# 2024-03-09 10:00:05 fc0_11_RR1c 0.00
# 2024-03-09 10:00:05 fc0_11_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_11_Rad1h 1360.00
# 2024-03-09 10:00:05 fc0_11_SunUp 1
# 2024-03-09 10:00:05 fc0_11_TTT 7.70
# 2024-03-09 10:00:05 fc0_11_time 11:00
# 2024-03-09 10:00:05 fc0_11_ww 1
# 2024-03-09 10:00:05 fc0_11_wwM 0.00
# 2024-03-09 10:00:05 fc0_12_Neff 47
# 2024-03-09 10:00:05 fc0_12_R101 0.00
# 2024-03-09 10:00:05 fc0_12_RR1c 0.00
# 2024-03-09 10:00:05 fc0_12_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_12_Rad1h 1600.00
# 2024-03-09 10:00:05 fc0_12_SunUp 1
# 2024-03-09 10:00:05 fc0_12_TTT 9.5
# 2024-03-09 10:00:05 fc0_12_time 12:00
# 2024-03-09 10:00:05 fc0_12_ww 1
# 2024-03-09 10:00:05 fc0_12_wwM 0.00
# 2024-03-09 10:00:05 fc0_13_Neff 38
# 2024-03-09 10:00:05 fc0_13_R101 0.00
# 2024-03-09 10:00:05 fc0_13_R600 4.00
# 2024-03-09 10:00:05 fc0_13_RR1c 0.00
# 2024-03-09 10:00:05 fc0_13_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_13_Rad1h 1740.00
# 2024-03-09 10:00:05 fc0_13_SunUp 1
# 2024-03-09 10:00:05 fc0_13_TTT 11.3
# 2024-03-09 10:00:05 fc0_13_time 13:00
# 2024-03-09 10:00:05 fc0_13_ww 1
# 2024-03-09 10:00:05 fc0_13_wwM 0.00
# 2024-03-09 10:00:05 fc0_14_Neff 39
# 2024-03-09 10:00:05 fc0_14_R101 0.00
# 2024-03-09 10:00:05 fc0_14_RR1c 0.00
# 2024-03-09 10:00:05 fc0_14_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_14_Rad1h 1650.00
# 2024-03-09 10:00:05 fc0_14_SunUp 1
# 2024-03-09 10:00:05 fc0_14_TTT 12.2
# 2024-03-09 10:00:05 fc0_14_time 14:00
# 2024-03-09 10:00:05 fc0_14_ww 1
# 2024-03-09 10:00:05 fc0_14_wwM 0.00
# 2024-03-09 10:00:05 fc0_15_Neff 38
# 2024-03-09 10:00:05 fc0_15_R101 1.00
# 2024-03-09 10:00:05 fc0_15_RR1c 0.00
# 2024-03-09 10:00:05 fc0_15_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_15_Rad1h 1450.00
# 2024-03-09 10:00:05 fc0_15_SunUp 1
# 2024-03-09 10:00:05 fc0_15_TTT 13
# 2024-03-09 10:00:05 fc0_15_time 15:00
# 2024-03-09 10:00:05 fc0_15_ww 1
# 2024-03-09 10:00:05 fc0_15_wwM 0.00
# 2024-03-09 10:00:05 fc0_16_Neff 35
# 2024-03-09 10:00:05 fc0_16_R101 1.00
# 2024-03-09 10:00:05 fc0_16_RR1c 0.00
# 2024-03-09 10:00:05 fc0_16_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_16_Rad1h 1110.00
# 2024-03-09 10:00:05 fc0_16_SunUp 1
# 2024-03-09 10:00:05 fc0_16_TTT 13.2
# 2024-03-09 10:00:05 fc0_16_time 16:00
# 2024-03-09 10:00:05 fc0_16_ww 1
# 2024-03-09 10:00:05 fc0_16_wwM 0.00
# 2024-03-09 10:00:05 fc0_17_Neff 32
# 2024-03-09 10:00:05 fc0_17_R101 1.00
# 2024-03-09 10:00:05 fc0_17_RR1c 0.00
# 2024-03-09 10:00:05 fc0_17_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_17_Rad1h 670.00
# 2024-03-09 10:00:05 fc0_17_SunUp 1
# 2024-03-09 10:00:05 fc0_17_TTT 12.7
# 2024-03-09 10:00:05 fc0_17_time 17:00
# 2024-03-09 10:00:05 fc0_17_ww 1
# 2024-03-09 10:00:05 fc0_17_wwM 1.00
# 2024-03-09 10:00:05 fc0_18_Neff 29
# 2024-03-09 10:00:05 fc0_18_R101 1.00
# 2024-03-09 10:00:05 fc0_18_RR1c 0.00
# 2024-03-09 10:00:05 fc0_18_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_18_Rad1h 210.00
# 2024-03-09 10:00:05 fc0_18_SunUp 1
# 2024-03-09 10:00:05 fc0_18_TTT 11.8
# 2024-03-09 10:00:05 fc0_18_time 18:00
# 2024-03-09 10:00:05 fc0_18_ww 1
# 2024-03-09 10:00:05 fc0_18_wwM 0.00
# 2024-03-09 10:00:05 fc0_19_Neff 31
# 2024-03-09 10:00:05 fc0_19_R101 1.00
# 2024-03-09 10:00:05 fc0_19_R600 5.00
# 2024-03-09 10:00:05 fc0_19_RR1c 0.00
# 2024-03-09 10:00:05 fc0_19_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_19_Rad1h 0.00
# 2024-03-09 10:00:05 fc0_19_SunUp 0
# 2024-03-09 10:00:05 fc0_19_TTT 10.2
# 2024-03-09 10:00:05 fc0_19_time 19:00
# 2024-03-09 10:00:05 fc0_19_ww 1
# 2024-03-09 10:00:05 fc0_19_wwM 0.00
# 2024-03-09 05:00:05 fc0_1_Neff 16
# 2024-03-09 05:00:05 fc0_1_R101 1.00
# 2024-03-09 05:00:05 fc0_1_R600 2.00
# 2024-03-09 05:00:05 fc0_1_RR1c 0.00
# 2024-03-09 05:00:05 fc0_1_RRS1c 0.00
# 2024-03-09 05:00:05 fc0_1_Rad1h 0.00
# 2024-03-09 05:00:05 fc0_1_SunUp 0
# 2024-03-09 05:00:05 fc0_1_TTT 2.10
# 2024-03-09 05:00:05 fc0_1_time 01:00
# 2024-03-09 05:00:05 fc0_1_ww 0
# 2024-03-09 05:00:05 fc0_1_wwM 0.00
# 2024-03-09 10:00:05 fc0_20_Neff 29
# 2024-03-09 10:00:05 fc0_20_R101 0.00
# 2024-03-09 10:00:05 fc0_20_RR1c 0.00
# 2024-03-09 10:00:05 fc0_20_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_20_Rad1h 0.00
# 2024-03-09 10:00:05 fc0_20_SunUp 0
# 2024-03-09 10:00:05 fc0_20_TTT 8.90
# 2024-03-09 10:00:05 fc0_20_time 20:00
# 2024-03-09 10:00:05 fc0_20_ww 1
# 2024-03-09 10:00:05 fc0_20_wwM 0.00
# 2024-03-09 10:00:05 fc0_21_Neff 29
# 2024-03-09 10:00:05 fc0_21_R101 0.00
# 2024-03-09 10:00:05 fc0_21_RR1c 0.00
# 2024-03-09 10:00:05 fc0_21_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_21_Rad1h 0.00
# 2024-03-09 10:00:05 fc0_21_SunUp 0
# 2024-03-09 10:00:05 fc0_21_TTT 7.70
# 2024-03-09 10:00:05 fc0_21_time 21:00
# 2024-03-09 10:00:05 fc0_21_ww 1
# 2024-03-09 10:00:05 fc0_21_wwM 0.00
# 2024-03-09 10:00:05 fc0_22_Neff 30
# 2024-03-09 10:00:05 fc0_22_R101 0.00
# 2024-03-09 10:00:05 fc0_22_RR1c 0.00
# 2024-03-09 10:00:05 fc0_22_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_22_Rad1h 0.00
# 2024-03-09 10:00:05 fc0_22_SunUp 0
# 2024-03-09 10:00:05 fc0_22_TTT 7.20
# 2024-03-09 10:00:05 fc0_22_time 22:00
# 2024-03-09 10:00:05 fc0_22_ww 1
# 2024-03-09 10:00:05 fc0_22_wwM 0.00
# 2024-03-09 10:00:05 fc0_23_Neff 29
# 2024-03-09 10:00:05 fc0_23_R101 0.00
# 2024-03-09 10:00:05 fc0_23_RR1c 0.00
# 2024-03-09 10:00:05 fc0_23_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_23_Rad1h 0.00
# 2024-03-09 10:00:05 fc0_23_SunUp 0
# 2024-03-09 10:00:05 fc0_23_TTT 6.90
# 2024-03-09 10:00:05 fc0_23_time 23:00
# 2024-03-09 10:00:05 fc0_23_ww 1
# 2024-03-09 10:00:05 fc0_23_wwM 0.00
# 2024-03-09 05:00:05 fc0_2_Neff 17
# 2024-03-09 05:00:05 fc0_2_R101 1.00
# 2024-03-09 05:00:05 fc0_2_RR1c 0.00
# 2024-03-09 05:00:05 fc0_2_RRS1c 0.00
# 2024-03-09 05:00:05 fc0_2_Rad1h 0.00
# 2024-03-09 05:00:05 fc0_2_SunUp 0
# 2024-03-09 05:00:05 fc0_2_TTT 1.60
# 2024-03-09 05:00:05 fc0_2_time 02:00
# 2024-03-09 05:00:05 fc0_2_ww 0
# 2024-03-09 05:00:05 fc0_2_wwM 0.00
# 2024-03-09 05:00:05 fc0_3_Neff 23
# 2024-03-09 05:00:05 fc0_3_R101 1.00
# 2024-03-09 05:00:05 fc0_3_RR1c 0.00
# 2024-03-09 05:00:05 fc0_3_RRS1c 0.00
# 2024-03-09 05:00:05 fc0_3_Rad1h 0.00
# 2024-03-09 05:00:05 fc0_3_SunUp 0
# 2024-03-09 05:00:05 fc0_3_TTT 1.20
# 2024-03-09 05:00:05 fc0_3_time 03:00
# 2024-03-09 05:00:05 fc0_3_ww 0
# 2024-03-09 05:00:05 fc0_3_wwM 0.00
# 2024-03-09 05:00:05 fc0_4_Neff 28
# 2024-03-09 05:00:05 fc0_4_R101 1.00
# 2024-03-09 05:00:05 fc0_4_RR1c 0.00
# 2024-03-09 05:00:05 fc0_4_RRS1c 0.00
# 2024-03-09 05:00:05 fc0_4_Rad1h 0.00
# 2024-03-09 05:00:05 fc0_4_SunUp 0
# 2024-03-09 05:00:05 fc0_4_TTT 0.80
# 2024-03-09 05:00:05 fc0_4_time 04:00
# 2024-03-09 05:00:05 fc0_4_ww 0
# 2024-03-09 05:00:05 fc0_4_wwM 0.00
# 2024-03-09 10:00:05 fc0_5_Neff 31
# 2024-03-09 10:00:05 fc0_5_R101 1.00
# 2024-03-09 10:00:05 fc0_5_RR1c 0.00
# 2024-03-09 10:00:05 fc0_5_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_5_Rad1h 0.00
# 2024-03-09 10:00:05 fc0_5_SunUp 0
# 2024-03-09 10:00:05 fc0_5_TTT 0.20
# 2024-03-09 10:00:05 fc0_5_time 05:00
# 2024-03-09 10:00:05 fc0_5_ww 0
# 2024-03-09 10:00:05 fc0_5_wwM 0.00
# 2024-03-09 10:00:05 fc0_6_Neff 40
# 2024-03-09 10:00:05 fc0_6_R101 0.00
# 2024-03-09 10:00:05 fc0_6_RR1c 0.00
# 2024-03-09 10:00:05 fc0_6_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_6_Rad1h 0.00
# 2024-03-09 10:00:05 fc0_6_SunUp 0
# 2024-03-09 10:00:05 fc0_6_TTT 0.40
# 2024-03-09 10:00:05 fc0_6_time 06:00
# 2024-03-09 10:00:05 fc0_6_ww 1
# 2024-03-09 10:00:05 fc0_6_wwM 0.00
# 2024-03-09 10:00:05 fc0_7_Neff 49
# 2024-03-09 10:00:05 fc0_7_R101 0.00
# 2024-03-09 10:00:05 fc0_7_R600 1.00
# 2024-03-09 10:00:05 fc0_7_RR1c 0.00
# 2024-03-09 10:00:05 fc0_7_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_7_Rad1h 20.00
# 2024-03-09 10:00:05 fc0_7_SunUp 1
# 2024-03-09 10:00:05 fc0_7_TTT 0.90
# 2024-03-09 10:00:05 fc0_7_time 07:00
# 2024-03-09 10:00:05 fc0_7_ww 1
# 2024-03-09 10:00:05 fc0_7_wwM 0.00
# 2024-03-09 10:00:05 fc0_8_Neff 52
# 2024-03-09 10:00:05 fc0_8_R101 1.00
# 2024-03-09 10:00:05 fc0_8_RR1c 0.00
# 2024-03-09 10:00:05 fc0_8_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_8_Rad1h 210.00
# 2024-03-09 10:00:05 fc0_8_SunUp 1
# 2024-03-09 10:00:05 fc0_8_TTT 1.70
# 2024-03-09 10:00:05 fc0_8_time 08:00
# 2024-03-09 10:00:05 fc0_8_ww 1
# 2024-03-09 10:00:05 fc0_8_wwM 0.00
# 2024-03-09 10:00:05 fc0_9_Neff 54
# 2024-03-09 10:00:05 fc0_9_R101 1.00
# 2024-03-09 10:00:05 fc0_9_RR1c 0.00
# 2024-03-09 10:00:05 fc0_9_RRS1c 0.00
# 2024-03-09 10:00:05 fc0_9_Rad1h 560.00
# 2024-03-09 10:00:05 fc0_9_SunUp 1
# 2024-03-09 10:00:05 fc0_9_TTT 3.5
# 2024-03-09 10:00:05 fc0_9_time 09:00
# 2024-03-09 10:00:05 fc0_9_ww 1
# 2024-03-09 10:00:05 fc0_9_wwM 0.00
# 2024-03-09 10:00:05 fc0_SunRise 06:36
# 2024-03-09 10:00:05 fc0_SunSet 18:15
# 2024-03-09 10:00:05 fc0_date 2024-03-09
# 2024-03-09 10:00:05 fc0_weekday Sa
# 2024-03-09 10:00:05 fc1_0_Neff 32
# 2024-03-09 10:00:05 fc1_0_R101 0.00
# 2024-03-09 10:00:05 fc1_0_RR1c 0.00
# 2024-03-09 10:00:05 fc1_0_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_0_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_0_SunUp 0
# 2024-03-09 10:00:05 fc1_0_TTT 6.5
# 2024-03-09 10:00:05 fc1_0_time 00:00
# 2024-03-09 10:00:05 fc1_0_ww 1
# 2024-03-09 10:00:05 fc1_0_wwM 0.00
# 2024-03-09 10:00:05 fc1_10_Neff 42
# 2024-03-09 10:00:05 fc1_10_R101 1.00
# 2024-03-09 10:00:05 fc1_10_RR1c 0.00
# 2024-03-09 10:00:05 fc1_10_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_10_Rad1h 1050.00
# 2024-03-09 10:00:05 fc1_10_SunUp 1
# 2024-03-09 10:00:05 fc1_10_TTT 9.90
# 2024-03-09 10:00:05 fc1_10_time 10:00
# 2024-03-09 10:00:05 fc1_10_ww 1
# 2024-03-09 10:00:05 fc1_10_wwM 0.00
# 2024-03-09 10:00:05 fc1_11_Neff 40
# 2024-03-09 10:00:05 fc1_11_R101 1.00
# 2024-03-09 10:00:05 fc1_11_RR1c 0.00
# 2024-03-09 10:00:05 fc1_11_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_11_Rad1h 1480.00
# 2024-03-09 10:00:05 fc1_11_SunUp 1
# 2024-03-09 10:00:05 fc1_11_TTT 11.6
# 2024-03-09 10:00:05 fc1_11_time 11:00
# 2024-03-09 10:00:05 fc1_11_ww 1
# 2024-03-09 10:00:05 fc1_11_wwM 0.00
# 2024-03-09 10:00:05 fc1_12_Neff 41
# 2024-03-09 10:00:05 fc1_12_R101 0.00
# 2024-03-09 10:00:05 fc1_12_RR1c 0.00
# 2024-03-09 10:00:05 fc1_12_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_12_Rad1h 1760.00
# 2024-03-09 10:00:05 fc1_12_SunUp 1
# 2024-03-09 10:00:05 fc1_12_TTT 13.3
# 2024-03-09 10:00:05 fc1_12_time 12:00
# 2024-03-09 10:00:05 fc1_12_ww 1
# 2024-03-09 10:00:05 fc1_12_wwM 0.00
# 2024-03-09 10:00:05 fc1_13_Neff 45
# 2024-03-09 10:00:05 fc1_13_R101 0.00
# 2024-03-09 10:00:05 fc1_13_R600 3.00
# 2024-03-09 10:00:05 fc1_13_RR1c 0.00
# 2024-03-09 10:00:05 fc1_13_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_13_Rad1h 1820.00
# 2024-03-09 10:00:05 fc1_13_SunUp 1
# 2024-03-09 10:00:05 fc1_13_TTT 14.7
# 2024-03-09 10:00:05 fc1_13_time 13:00
# 2024-03-09 10:00:05 fc1_13_ww 1
# 2024-03-09 10:00:05 fc1_13_wwM 0.00
# 2024-03-09 10:00:05 fc1_14_Neff 45
# 2024-03-09 10:00:05 fc1_14_R101 0.00
# 2024-03-09 10:00:05 fc1_14_RR1c 0.00
# 2024-03-09 10:00:05 fc1_14_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_14_Rad1h 1710.00
# 2024-03-09 10:00:05 fc1_14_SunUp 1
# 2024-03-09 10:00:05 fc1_14_TTT 15.5
# 2024-03-09 10:00:05 fc1_14_time 14:00
# 2024-03-09 10:00:05 fc1_14_ww 1
# 2024-03-09 10:00:05 fc1_14_wwM 0.00
# 2024-03-09 10:00:05 fc1_15_Neff 53
# 2024-03-09 10:00:05 fc1_15_R101 1.00
# 2024-03-09 10:00:05 fc1_15_RR1c 0.00
# 2024-03-09 10:00:05 fc1_15_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_15_Rad1h 1370.00
# 2024-03-09 10:00:05 fc1_15_SunUp 1
# 2024-03-09 10:00:05 fc1_15_TTT 15.4
# 2024-03-09 10:00:05 fc1_15_time 15:00
# 2024-03-09 10:00:05 fc1_15_ww 1
# 2024-03-09 10:00:05 fc1_15_wwM 0.00
# 2024-03-09 10:00:05 fc1_16_Neff 56
# 2024-03-09 10:00:05 fc1_16_R101 1.00
# 2024-03-09 10:00:05 fc1_16_RR1c 0.00
# 2024-03-09 10:00:05 fc1_16_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_16_Rad1h 990.00
# 2024-03-09 10:00:05 fc1_16_SunUp 1
# 2024-03-09 10:00:05 fc1_16_TTT 15.2
# 2024-03-09 10:00:05 fc1_16_time 16:00
# 2024-03-09 10:00:05 fc1_16_ww 1
# 2024-03-09 10:00:05 fc1_16_wwM 0.00
# 2024-03-09 10:00:05 fc1_17_Neff 55
# 2024-03-09 10:00:05 fc1_17_R101 1.00
# 2024-03-09 10:00:05 fc1_17_RR1c 0.00
# 2024-03-09 10:00:05 fc1_17_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_17_Rad1h 550.00
# 2024-03-09 10:00:05 fc1_17_SunUp 1
# 2024-03-09 10:00:05 fc1_17_TTT 14.6
# 2024-03-09 10:00:05 fc1_17_time 17:00
# 2024-03-09 10:00:05 fc1_17_ww 1
# 2024-03-09 10:00:05 fc1_17_wwM 0.00
# 2024-03-09 10:00:05 fc1_18_Neff 64
# 2024-03-09 10:00:05 fc1_18_R101 3.00
# 2024-03-09 10:00:05 fc1_18_RR1c 0.00
# 2024-03-09 10:00:05 fc1_18_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_18_Rad1h 160.00
# 2024-03-09 10:00:05 fc1_18_SunUp 1
# 2024-03-09 10:00:05 fc1_18_TTT 13.3
# 2024-03-09 10:00:05 fc1_18_time 18:00
# 2024-03-09 10:00:05 fc1_18_ww 2
# 2024-03-09 10:00:05 fc1_18_wwM 0.00
# 2024-03-09 10:00:05 fc1_19_Neff 70
# 2024-03-09 10:00:05 fc1_19_R101 5.00
# 2024-03-09 10:00:05 fc1_19_R600 12.00
# 2024-03-09 10:00:05 fc1_19_RR1c 0.00
# 2024-03-09 10:00:05 fc1_19_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_19_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_19_SunUp 0
# 2024-03-09 10:00:05 fc1_19_TTT 12
# 2024-03-09 10:00:05 fc1_19_time 19:00
# 2024-03-09 10:00:05 fc1_19_ww 2
# 2024-03-09 10:00:05 fc1_19_wwM 1.00
# 2024-03-09 10:00:05 fc1_1_Neff 34
# 2024-03-09 10:00:05 fc1_1_R101 0.00
# 2024-03-09 10:00:05 fc1_1_R600 2.00
# 2024-03-09 10:00:05 fc1_1_RR1c 0.00
# 2024-03-09 10:00:05 fc1_1_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_1_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_1_SunUp 0
# 2024-03-09 10:00:05 fc1_1_TTT 6.10
# 2024-03-09 10:00:05 fc1_1_time 01:00
# 2024-03-09 10:00:05 fc1_1_ww 1
# 2024-03-09 10:00:05 fc1_1_wwM 0.00
# 2024-03-09 10:00:05 fc1_20_Neff 71
# 2024-03-09 10:00:05 fc1_20_R101 11.00
# 2024-03-09 10:00:05 fc1_20_RR1c 0.00
# 2024-03-09 10:00:05 fc1_20_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_20_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_20_SunUp 0
# 2024-03-09 10:00:05 fc1_20_TTT 10.4
# 2024-03-09 10:00:05 fc1_20_time 20:00
# 2024-03-09 10:00:05 fc1_20_ww 2
# 2024-03-09 10:00:05 fc1_20_wwM 0.00
# 2024-03-09 10:00:05 fc1_21_Neff 78
# 2024-03-09 10:00:05 fc1_21_R101 19.00
# 2024-03-09 10:00:05 fc1_21_RR1c 0.00
# 2024-03-09 10:00:05 fc1_21_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_21_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_21_SunUp 0
# 2024-03-09 10:00:05 fc1_21_TTT 9.30
# 2024-03-09 10:00:05 fc1_21_time 21:00
# 2024-03-09 10:00:05 fc1_21_ww 2
# 2024-03-09 10:00:05 fc1_21_wwM 0.00
# 2024-03-09 10:00:05 fc1_22_Neff 82
# 2024-03-09 10:00:05 fc1_22_R101 28.00
# 2024-03-09 10:00:05 fc1_22_RR1c 0.40
# 2024-03-09 10:00:05 fc1_22_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_22_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_22_SunUp 0
# 2024-03-09 10:00:05 fc1_22_TTT 8.70
# 2024-03-09 10:00:05 fc1_22_time 22:00
# 2024-03-09 10:00:05 fc1_22_ww 61
# 2024-03-09 10:00:05 fc1_22_wwM 0.00
# 2024-03-09 10:00:05 fc1_23_Neff 84
# 2024-03-09 10:00:05 fc1_23_R101 33.00
# 2024-03-09 10:00:05 fc1_23_RR1c 0.40
# 2024-03-09 10:00:05 fc1_23_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_23_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_23_SunUp 0
# 2024-03-09 10:00:05 fc1_23_TTT 8.20
# 2024-03-09 10:00:05 fc1_23_time 23:00
# 2024-03-09 10:00:05 fc1_23_ww 61
# 2024-03-09 10:00:05 fc1_23_wwM 0.00
# 2024-03-09 10:00:05 fc1_2_Neff 34
# 2024-03-09 10:00:05 fc1_2_R101 0.00
# 2024-03-09 10:00:05 fc1_2_RR1c 0.00
# 2024-03-09 10:00:05 fc1_2_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_2_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_2_SunUp 0
# 2024-03-09 10:00:05 fc1_2_TTT 5.60
# 2024-03-09 10:00:05 fc1_2_time 02:00
# 2024-03-09 10:00:05 fc1_2_ww 1
# 2024-03-09 10:00:05 fc1_2_wwM 0.00
# 2024-03-09 10:00:05 fc1_3_Neff 38
# 2024-03-09 10:00:05 fc1_3_R101 1.00
# 2024-03-09 10:00:05 fc1_3_RR1c 0.00
# 2024-03-09 10:00:05 fc1_3_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_3_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_3_SunUp 0
# 2024-03-09 10:00:05 fc1_3_TTT 5.5
# 2024-03-09 10:00:05 fc1_3_time 03:00
# 2024-03-09 10:00:05 fc1_3_ww 1
# 2024-03-09 10:00:05 fc1_3_wwM 0.00
# 2024-03-09 10:00:05 fc1_4_Neff 41
# 2024-03-09 10:00:05 fc1_4_R101 1.00
# 2024-03-09 10:00:05 fc1_4_RR1c 0.00
# 2024-03-09 10:00:05 fc1_4_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_4_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_4_SunUp 0
# 2024-03-09 10:00:05 fc1_4_TTT 5.20
# 2024-03-09 10:00:05 fc1_4_time 04:00
# 2024-03-09 10:00:05 fc1_4_ww 1
# 2024-03-09 10:00:05 fc1_4_wwM 0.00
# 2024-03-09 10:00:05 fc1_5_Neff 42
# 2024-03-09 10:00:05 fc1_5_R101 1.00
# 2024-03-09 10:00:05 fc1_5_RR1c 0.00
# 2024-03-09 10:00:05 fc1_5_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_5_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_5_SunUp 0
# 2024-03-09 10:00:05 fc1_5_TTT 4.90
# 2024-03-09 10:00:05 fc1_5_time 05:00
# 2024-03-09 10:00:05 fc1_5_ww 1
# 2024-03-09 10:00:05 fc1_5_wwM 0.00
# 2024-03-09 10:00:05 fc1_6_Neff 44
# 2024-03-09 10:00:05 fc1_6_R101 0.00
# 2024-03-09 10:00:05 fc1_6_RR1c 0.00
# 2024-03-09 10:00:05 fc1_6_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_6_Rad1h 0.00
# 2024-03-09 10:00:05 fc1_6_SunUp 0
# 2024-03-09 10:00:05 fc1_6_TTT 4.90
# 2024-03-09 10:00:05 fc1_6_time 06:00
# 2024-03-09 10:00:05 fc1_6_ww 1
# 2024-03-09 10:00:05 fc1_6_wwM 0.00
# 2024-03-09 10:00:05 fc1_7_Neff 44
# 2024-03-09 10:00:05 fc1_7_R101 1.00
# 2024-03-09 10:00:05 fc1_7_R600 3.00
# 2024-03-09 10:00:05 fc1_7_RR1c 0.00
# 2024-03-09 10:00:05 fc1_7_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_7_Rad1h 10.00
# 2024-03-09 10:00:05 fc1_7_SunUp 1
# 2024-03-09 10:00:05 fc1_7_TTT 5.5
# 2024-03-09 10:00:05 fc1_7_time 07:00
# 2024-03-09 10:00:05 fc1_7_ww 1
# 2024-03-09 10:00:05 fc1_7_wwM 0.00
# 2024-03-09 10:00:05 fc1_8_Neff 45
# 2024-03-09 10:00:05 fc1_8_R101 1.00
# 2024-03-09 10:00:05 fc1_8_RR1c 0.00
# 2024-03-09 10:00:05 fc1_8_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_8_Rad1h 190.00
# 2024-03-09 10:00:05 fc1_8_SunUp 1
# 2024-03-09 10:00:05 fc1_8_TTT 6.40
# 2024-03-09 10:00:05 fc1_8_time 08:00
# 2024-03-09 10:00:05 fc1_8_ww 1
# 2024-03-09 10:00:05 fc1_8_wwM 0.00
# 2024-03-09 10:00:05 fc1_9_Neff 42
# 2024-03-09 10:00:05 fc1_9_R101 1.00
# 2024-03-09 10:00:05 fc1_9_RR1c 0.00
# 2024-03-09 10:00:05 fc1_9_RRS1c 0.00
# 2024-03-09 10:00:05 fc1_9_Rad1h 600.00
# 2024-03-09 10:00:05 fc1_9_SunUp 1
# 2024-03-09 10:00:05 fc1_9_TTT 8
# 2024-03-09 10:00:05 fc1_9_time 09:00
# 2024-03-09 10:00:05 fc1_9_ww 1
# 2024-03-09 10:00:05 fc1_9_wwM 0.00
# 2024-03-09 10:00:05 fc1_SunRise 06:34
# 2024-03-09 10:00:05 fc1_SunSet 18:17
# 2024-03-09 10:00:05 fc1_date 2024-03-10
# 2024-03-09 10:00:05 fc1_weekday So
# 2024-03-09 10:00:05 fc_coordinates 11.37,49.6,539.0
# 2024-03-09 10:00:05 fc_copyright Datenbasis: Deutscher Wetterdienst
# 2024-03-09 10:00:05 fc_description HIENBERG
# 2024-03-09 10:00:05 fc_state updated
# 2024-03-09 10:00:05 fc_station P267
# 2024-03-09 10:00:05 fc_time 2024-03-09 04:00:00
# 2024-03-09 10:00:05 state forecast updated
#
setstate DWD_Forecast forecast updated
# ... truncated to 50k, original length 54386
Moin,
du kannst es so akzeptieren oder das DWD Modul aus meinem contrib benutzen (siehe Post #117).
Irgendwann wird das DWD Modul eingecheckt.
Im DWD Thread gibt es Infos zum Entwicklungsfortschritt.
LG,
Heiko
Morgen,
habe Solarforecast geupdated und DWD bei dir aus dem contrib. Wo sehe ich jetzt
ob meine Stationen MOSMIX_S können, oder gegeben falls Stationen in der Umgebung?
Nach dem Check erhalte ich folgende Empfehlungen zu meinen 2 DWD_Devices.
checked global Radiation parameters:
MOSMIX variant, Age of Radiation data.
checked parameters and attributes device "DWD":
forecastProperties -> Rad1h
forecastRefresh
checked parameters and attributes of device "DWD":
forecastProperties -> TTT Neff RR1c ww SunUp SunRise SunSet
forecastRefresh
checked parameters and attributes of device "DWD1":
forecastProperties -> TTT Neff RR1c ww SunUp SunRise SunSet
forecastRefresh
The Prediction time of Weather data is older than expected when using MOSMIX_S.
Data time forecast: 09.03.2024 04:00:00
Check the DWD device(s) for proper functioning of the data retrieval.
Ich glaube die Info führt zu Missverständnis. Was und wie soll forecastProperties bei DWD korrekt gesetzt werden? Spielen Kommas eine Rolle?
Ich würde ein Mix aus Beiden so eintragen:
TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet,Rad1h
Danke!
edit:
Rad1h wird bei beiden DWD Devices im Reading angezeigt und auch erneuert. Daher gehe ich davon aus, das alles ok ist und meine beiden Stationen
die Abfrage im Std-Bereich anbieten.
Gruß schwatter
Zitat von: DS_Starter am 07 März 2024, 19:41:59........Version findet ihr bereits jetzt in meinem contrib.
Dort liegt auch die aktuelle / getestete Entwicklungsversion von 55_DWD_OpenData.
Ab dieser DWD_OpenData Version ist das Attribut forecastRefresh für die MOSMIX Variante zu verwenden (1=MOSMIX_S, 6=MOSMIX_L).
Holt euch auch diese Version damit die Prüfungen/Anzeigen optimal zusammenarbeiten.
Grüße,
Heiko
@schwatter:
Nimm doch folgendes als Einstellung z.B.:
forecastStation xyxyxyxy
forecastResolution 1
forecastProperties
SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
Danke,
im Moment habe ich die vorgeschlagenen von Solarforecast so gesetzt.
attr DWD forecastDays 2
attr DWD forecastProperties TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet,Rad1h
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastWW2Text 1
Damit läuft es bis jetzt sehr gut.
Aber wo ich sehen kann, welche Mosmix_S unterstützen (meine 2 können es zum Glück, Solarforecast meckert nicht),
interessiert mich weiter.
Gruß schwatter
ZitatAber wo ich sehen kann, welche Mosmix_S unterstützen (meine 2 können es zum Glück, Solarforecast meckert nicht),
interessiert mich weiter.
Die Verfahren MOSMIX_L und MOSMIX_S unterscheiden sich nicht über die Stationen, sondern durch die Updatefrequenz und den Umfang der verfügbaren Parameter.
Auf dieser Seite https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/met_verfahren_mosmix.html findest du rechts einen Link zur MOSMIX Verfahrensdoku. Dort findest du jede Menge Infos.
Grüße,
Heiko
Zitat von: kask am 08 März 2024, 19:33:34Zitat# 2024-03-08 18:19:37 Current_Consumption 1174 W <<-- das ist 2*587W und falsch da doppelt so hoch
# 2024-03-08 18:19:37 Current_GridConsumption 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_GridFeedIn 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_PV 587 W <<-- nicht wirklich korrekt, das ist der Wert der aus der Batterie kommt
# 2024-03-08 18:19:37 Current_PowerBatIn 0 W <<-- korrekt
# 2024-03-08 18:19:37 Current_PowerBatOut 587 W <<-- korrekt
# 2024-03-08 18:19:37 Current_SelfConsumption 587 W <<-- korrekt
Sicher das du die Variabelen richtig ausliest? da ist ziemlich oft 587 vertreten und auch 2*587 (wie du schon gemerkt hast)
dein
currentMeterDev SH08rt01 gcon=-gfeedin contotal=Total_Export_Energy:kWh gfeedin=-Export_Power:kWh feedtotal=Total_Import_Energy:kWh
sicher das das so Korrekt ist?
13036 Total Import Energy Gekaufte Energie gesamt
13045 Total export energy Energie Netzeinspeisung gesamt
ich denke da ist eher:
currentMeterDev SH08rt01 gcon=-gfeedin contotal=Total_Import_Energy:kWh gfeedin=-Export_Power:kWh feedtotal=Total_Export_Energy:kWh
Ich bin mir alles andere als sicher gewesen, aber das koennte
der oder mindestens einer der Fehler sein.
Ich habe das kontrolliert und dein Vorschlag passt besser. Die Werte die ich auslese passen mit denen aus der isolar Cloud zusammen.
Muss ich jetzt noch Werte loeschen oder pendelt sich das von alleine ein?
Christian
Hallo Christian,
wenn du noch relativ am Anfang stehst kannst du
set ... reset pvHistory
ausführen. Das setzt die gespeicherten Energiewerte zurück.
Ich habe das jetzt knapp 1 Monat aktiv mit vermutlich komplett falschen Werten.
Nach der Kontrolle habe ich den hier auch noch korrigiert:
currentInverterDev SH08rt01 pv=Total_DC_Power:W capacity=8000 etotal=Daily_PV_Generation:kWh
damit sieht auf einmal das Bild auch viel besser aus.
Ich werde mal reseten, das kann nur besser werden.
Dann am besten auch noch ein
set <name> reset pvCorrection cached
Hier mal ein Logauszug mit Verbose 5 bei MOSMIX-S wegen der Laufzeit bei Verwendung des "aktuell von Heiko optimierten DWD-Modules" (contrib)
Genutzte Hardware
Raspberry Pi 4 Model B Rev 1.1
ohne SD-Karte - aber mit SSD-Festplatte (1 TB - 3 Jahre alt)
gesamt benutzt frei gemns. Puffer/Cache verfügbar
Speicher: 3,7Gi 687Mi 1,8Gi 68Mi 1,3Gi 2,9Gi
Swap: 99Mi 0B 99Mi
(MariaDB extern auf einer QNAP)
Internet : Anbindung per DSL mit 100 MBit
LOG-Auszug
2024.03.09 17:59:24 5: DWD: GetForecast START (PID 630357)
2024.03.09 17:59:24 5: DWD: GetForecast END
2024.03.09 17:59:24 5: DWD: IsDocumentUpdated BEFORE
2024.03.09 17:59:24 5: DWD: GetHeaders content_length: 38616989
2024.03.09 17:59:24 5: DWD: GetHeaders last_modified raw: Sat, 09 Mar 2024 16:23:25 GMT
2024.03.09 17:59:24 5: DWD: GetHeaders last_modified formatted: 2024-03-09 16:23:25
2024.03.09 17:59:25 5: DWD: IsDocumentUpdated docSize:38616989/0 docTime:2024-03-09 16:23:25Z/2024-03-09 16:23:25Z URL:https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz/https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024.03.09 17:59:25 5: DWD: IsDocumentUpdated AFTER return update: 1, docSize: 38616989, docTime: 2024-03-09 16:23:25Z
2024.03.09 17:59:25 5: DWD: GetForecastStart dwdDocTime: 2024-03-09 16:23:25Z, dwdDocTimestamp: 1710001405, dwdDocSize: 38616989, lastDocTimestamp: 1710001405, maxDocAge: 0, lastDocSize: 0 : update: 1
2024.03.09 17:59:25 5: DWD: GetForecastStart START (PID 669494): https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024.03.09 17:59:29 5: DWD: GetForecastDataUsingFile: data received, unzipping ...
2024.03.09 18:00:10 5: DWD: GetForecastDataUsingFile: unzipped 666223134 bytes, filtering ...
2024.03.09 18:00:11 5: DWD: GetForecastDataUsingFile: filtered 130167 bytes
2024.03.09 18:00:11 5: DWD: ProcessForecast START
2024.03.09 18:00:11 5: DWD: ProcessForecast: data unpacked, decoding ...
2024.03.09 18:00:11 5: DWD: ProcessForecast: parsing XML document
2024.03.09 18:00:11 5: DWD: ProcessForecast: extracting data
2024.03.09 18:00:12 5: DWD: ProcessForecast temp file /tmp/HKMzG8q62P forecast 3 size 18758
2024.03.09 18:00:12 5: DWD: ProcessForecast END
2024.03.09 18:00:12 5: DWD: GetForecastStart END
2024.03.09 18:00:12 5: DWD: GetForecastFinish START (PID 630357)
2024.03.09 18:00:12 5: DWD: GetForecastFinish temp file /tmp/HKMzG8q62P forecast 3 size 18758
2024.03.09 18:00:12 5: DWD: UpdateForecast: START
2024.03.09 18:00:12 5: DWD: RotateForecast: START 8 day(s) exist
2024.03.09 18:00:12 5: DWD: RotateForecast: END 8 day(s) remain
2024.03.09 18:00:14 5: DWD: UpdateForecast: END
2024.03.09 18:00:14 5: DWD: GetForecastFinish END
Laufzeit ; 17:59:24 - 18:00:14 Uhr
(Also würde schon ein Timout von 60 Sekunden reichen)
Achtung:
=>> bei MOSMIX-S (ansonsten gibt es z.Z. ab und an mal Timoutmeldungen)
unbedingt
attr DWD downloadTimeout 120 (oder 60 wenns gut läuft s.o.)
setzen
Und hier eine zugehörige DWD-Beispielkonfiguration:
defmod DWD DWD_OpenData
attr DWD DbLogExclude .*
attr DWD alertArea XYXYXYXYXYX
attr DWD downloadTimeout 120
attr DWD forecastDays 7
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation dfghjkl12345
attr DWD forecastWW2Text 1
attr DWD group Umwelt
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date
attr DWD verbose 5
Gruß
300P
Danke 300P.
Vllt. wäre es gut eine Info im DWD Thread zu hinterlassen. Möglicherweise wäre es gut wenn Jens den Timeout noch höher ermöglichen würde.
LG
@DS_Starter
Wozu benötigt das Modul eigentlich die total Zähler beim Meter/Inverter bei der Batterie ist das aber nicht der Fall.
Hintergrund:
Ich habe Fronius Inverter inkl. den passenden Meter. Dieses liefert auch alle geforderten Werte.
Nun ist aber ein Victron dazu gekommen aus dem ich auch die Batteriewerte mit Modbus auslese. Nun ist es aber so, dass ich gerne alle Werte aus dem Victron beziehen würde, zwecks gleichzeitiger abtastrate. Victron liefert aber keine totalzähler.
Da ich jetzt auf Victron setzte bin ich jetzt auf deren API umgestiegen. Seit dem habe ich aber keine Abweichungswerte mehr, kann das sein?
Genutzte Hardware (Falls die Frage kommt):
Victron:
1 Stück MultiPlus-II (+Erweiterung 3 Phasig)
Fronius:
2 STück Fronius Symo 20.0-3-M
1 Stück Energy Meter ET340
Lg
Tobias
Bau dir einen Totalzähler selber. Habe auch Fronius + Victron. Nutze aber eine andere Art. Geht wie folgt aber auch.
folgenden Wert:
venus:N/xyzxyzxyz/battery/512/Dc/0/Power:.* { json2nameValue($EVENT, 'BAT512_Power_', $JSONMAP) }
Userreading:
BAT512_Power_total_in:BAT512_Power_value.* integral {ReadingsVal($name,"BAT512_Power_value","")>0?ReadingsVal($name,"BAT512_Power_value","")/3600000:0},
BAT512_Power_total_out:BAT512_Power_value.* integral {ReadingsVal($name,"BAT512_Power_value","")<0?ReadingsVal($name,"BAT512_Power_value","")/-3600000:0}
Axo,
wieso hst du keinen Totalzähler für die Batterie?
Ich habe einen:
current BatteryDevBatteryDummy pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=kWh_total:kWh
Und ich habe abweichungen mit der VictronKiAPI.
Zitat von: DS_Starter am 09 März 2024, 19:18:39Dann am besten auch noch ein
set <name> reset pvCorrection cached
Ich habe da noch mehrfach umgebaut und seit dem ich dem Wechselrichter noch 2 User Readings verpasst habe sieht die Grafik korrekt aus:
Added:
GridFeed {
if ((ReadingsVal("SH08rt01","Export_Power",0) > 0))
{
return (ReadingsVal("SH08rt01","Export_Power",0))
}
else
{
return 0
}
},
GridConsumption {
if ((ReadingsVal("SH08rt01","Export_Power",0) < 0))
{
return ( ( ReadingsVal("SH08rt01","Export_Power",0)) * (-1) )
}
else
{
return 0
}
},
dann ist das jetzt so definiert:
currentMeterDev SH08rt01 gcon=GridConsumption:W gfeedin=GridFeed:W contotal=Total_Import_Energy:kWh feedtotal=Total_Export_Energy:kWh
Generell: zu dem Bild:
DWD_Solarforecast_ChrisH.png
was ist die Idee hinter dem Haus -> Lampe Konstrukt? Koennen da mehrere Konsumenten angegeben werden? Bei mir wird da "nur" zweimal der gleiche Wert angegeben.
Ich habe dazu (noch) nichts im Forum gefunden.
Christian
Wenn Du Verbraucher definiert hast wird deren Verbrauch von der Lampe abgezogen und dein Gesamt-Verbrauch wird dann immer noch am Haus angezeigt
Die Verbraucher werden dann mit den jeweiligen Verbräuchen unterhalb angezeigt.
Ist aber auch über diverse Attribute steuerbar.Home, Sweet Home.jpeg.png
@schwatter,
ich habe deinen Hinweis aufgenommen und den configCheck dahingehend geändert dass die Parameter wie im Attribut vorgesehen mit Komma getrennt ausgeschrieben werden:
forecastProperties -> TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet
Ist morgen früh im Update enthalten.
Grüße,
Heiko
Guten Morgen Heiko,
der Winter ist rum, mancher (ich) krabbelt wieder aus seinem Loch ;D
Shice, ich hab ja einiges verpasst seit 10/2023...
Bei mir läuft noch
ZitatFVERSION: 76_SolarForecast.pm:v1.5.1-s28265/2023-12-07
Muss ich Änderungen nach einem Update vornehmen oder gibt es etwas Wichtiges zu beachten?
(currentRadiationAPI = solCast)
(currentWeatherDev = DWD, ich hatte irgendwo über DWD Änderungen gelesen, finds nicht mehr)
Ist Dein Modul weiterhin "manuell" zu updaten?
("wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm")
Guten Morgen,
oh je, da bist aber wirklich weit hinterher. Inzwischen ist das Modul ofiziell eingescheckt und wir sind Stand heute bei der Version v1.16.6 angekommen.
Manuelles Update ist nicht mehr nötig.
Es ist natürlich sehr viel passiert in der Zwischenzeit.
EIn Update sollte funktionieren. Dabei werden vermutlich viele Meldungen kommen, die zunächst mal ignorieren. Wenn das Device noch lebt einen "set ... plantConfiguration check" ausführen und schauen was da kommt.
Zum DWD gibt es eine optionale Entwicklungsversion in meinem contrib. Damit kann mit forecastRefresh=1 eine höhere Updategenauigkeit (MOSMIX_S) erreicht werden. Näheres dazu im DWD Thread.
Grüße,
Heiko
Hallo Heiko,
auf der Suche nach freezes bin ich über folgendes gestolpert:
NOTIFYDEV myEBUS,myEBUSDie Ursache ist klar: das ist meine Heizung und 2 consumer (HK, WW) haben den gleichen dev-name - aber unterschiedliche readings...
Bin mir unsicher ob das eine Auswirkung hat, falls nicht: Kosmetik... ;D
Patch-Vorschlag im Attachment.
l.g. erwin
Edit: oder noch besser mit notifyRegexpChanged aus fhem.pl, die kann das auch, wie ich gerade entdeckt habe!
Hallo erwin,
danke, habe es eingebaut. Wird noch eingecheckt.
notifyRegexpChanged kenne ich, kann man aber hier nicht verwenden.
Problem ist, dass notifyRegexpChanged prüft ob $defs{<name>} vorhanden ist. Werden die Consumer Devices erst später in der Define Reihenfolge angelegt, ist $defs{<name>} nicht vorhanden und NOTIFYDEV wird gelöscht.
Das ist dann nicht zielführend. Deswegen habe ich NOTIFYDEV diskret aufgebaut.
Grüße,
Heiko
Mal etwas Off-topic... wär's möglich die stündlichen Strombezugspreise irgendwo in der Grafik einzublenden, vielleicht jeweils unter den Balken mit der stündlichen Vorhersage?
Dann hätte man die Übersicht auf einen Blick wann es sich ggf. lohnt Hochstromverbraucher trotz geringer PV-Leistung manuell einzuschalten.
Moin,
möglich ist das sicherlich.
Es steht zunächst aber die generelle Frage im Raum woher die Daten bezogen werden sollen/können?
Ihr kennt ja inzwischen die Modularchitektur. Eine Datenquelle wird über ihren Namen und die relevanten Readingstrukturen bei SolarForecast registriert. Diese Daten können dann verarbeitet und bei Bedarf in irgendeiner Weise visualisiert werden.
LG
Zitat von: DS_Starter am 13 März 2024, 08:18:40Ihr kennt ja inzwischen die Modularchitektur. Eine Datenquelle wird über ihren Namen und die relevanten Readingstrukturen bei SolarForecast registriert. Diese Daten können dann verarbeitet und bei Bedarf in irgendeiner Weise visualisiert werden.
Genau, sind aus meiner Sicht 2 unterschiedliche Themen:
1. SolarForecast muss die Möglichkeit schaffen eine solche Datenquelle zu registrieren. Jeder der einen stündlich variablen Stromtarif hat, hat vmtl. bereits ein Gerät, das die Daten bereitstellt. Diese Daten in die von SolarForecast dann vorgegebene Syntax zu bringen, sollte nicht schwer sein, haben wir bei den übrigen Daten bisher auch geschafft.
2. Die Grafik muss erweitert werden, dass sie die Daten auch anzeigt, so wie jetzt z.B. schon die stündliche Wetter-/PV-Vorhersage bzw. die Ist-Werte.
In weiterer Folge könnte - bei Vorhandensein dieser Daten - die Planung der Verbraucher zusätzlich die Bezugspreise berücksichtigen.
Für die stündlichen Strompreise von AWATTAR könnte das hier hilfreich sein:
https://wiki.fhem.de/wiki/AWATTar_-_Virtueller_Stromkunde
Da ich AWATTAR nicht habe... kann jemand von euch ein Beispiel eines "lebenden" AWATTAR Devices? Ich bräuchte eine Vorstellung der vorhandenenen Readingsstruktur.
Zitat von: dkreutz am 13 März 2024, 08:36:54Für die stündlichen Strompreise von AWATTAR könnte das hier hilfreich sein:
https://wiki.fhem.de/wiki/AWATTar_-_Virtueller_Stromkunde
Im aWATTar und Tibber Thread gibt es auch eine Implementierung von mir, die als RAW Device in meinem contrib ch.eick zu finden sind. Beide Devices verwenden soweit möglich die gleiche readings Struktur. Für EVU_Tibber_connect gibt es zur Visualisierung auch ein EVU_Tibber Device.
VG Christian
Zitat von: DS_Starter am 13 März 2024, 08:42:11Da ich AWATTAR nicht habe... kann jemand von euch ein Beispiel eines "lebenden" AWATTAR Devices? Ich bräuchte eine Vorstellung der vorhandenenen Readingsstruktur.
Beim aWATTar werden eigentlich nur die Preise aufbereitet. Bei Tibber bekommt man nur die Preise, wenn man Kunde ist.
VG Christian
Ich nochmal,
beide Devices verwenden jedoch in den userreadings eine DbLog :-( , was hier im Thread ja vermieden werden soll.
Zitat von: DS_Starter am 13 März 2024, 08:42:11Da ich AWATTAR nicht habe... kann jemand von euch ein Beispiel eines "lebenden" AWATTAR Devices? Ich bräuchte eine Vorstellung der vorhandenenen Readingsstruktur.
Ich verwende das von ch.eick angepasst an meinen Stromlieferanten, die Readings schauen so aus:
fc0_00_total 0.0901 2024-03-13 00:00:02
fc0_01_total 0.0878 2024-03-13 00:00:02
fc0_02_total 0.0869 2024-03-13 00:00:02
fc0_03_total 0.0862 2024-03-13 00:00:02
fc0_04_total 0.0889 2024-03-13 00:00:02
fc0_05_total 0.0947 2024-03-13 00:00:02
fc0_06_total 0.1087 2024-03-13 00:00:02
fc0_07_total 0.1222 2024-03-13 00:00:02
fc0_08_total 0.1240 2024-03-13 00:00:02
fc0_09_total 0.1075 2024-03-13 00:00:02
fc0_10_total 0.0960 2024-03-13 00:00:02
fc0_11_total 0.0922 2024-03-13 00:00:02
fc0_12_total 0.0911 2024-03-13 00:00:02
fc0_13_total 0.0912 2024-03-13 00:00:02
fc0_14_total 0.0935 2024-03-13 00:00:02
fc0_15_total 0.0984 2024-03-13 00:00:02
fc0_16_total 0.1054 2024-03-13 00:00:02
fc0_17_total 0.1228 2024-03-13 00:00:02
fc0_18_total 0.1338 2024-03-13 00:00:02
fc0_19_total 0.1338 2024-03-13 00:00:02
fc0_20_total 0.1145 2024-03-13 00:00:02
fc0_21_total 0.1012 2024-03-13 00:00:02
fc0_22_total 0.0972 2024-03-13 00:00:02
fc0_23_total 0.0911 2024-03-13 00:00:02
fc[Tag-relativ]_[Stunde-absolut]_total
fc0_10_total gibt also den Preis des aktuellen Tags von 10-11 Uhr an.
Warum in einem Modul alles ?
Aber es ja schon ganz einfach, nur an andere Stelle wie folgt:
Mittels der bestehenden Module für Tibber und Awattar ein Device seiner Wahl anlegen.(Bei mir ist es ein Device mit Namen myTibber)
Einfach im Attribut (von Solarforecast) graphicHeaderOwnspec nur noch zusätzlich eintragen:
Strompreis €:Strompreis@myTibber
PS:
Das ist der wirkliche aktuelle Stundenpreis inkl. MwSt. im März 24 für Neukunden im ersten Monat....😉
Zitateide Devices verwenden jedoch in den userreadings eine DbLog :-( , was hier im Thread ja vermieden werden soll.
Eine "Datenbank" gibt es hier auch, aber keine SQL. ;)
ZitatIch verwende das von ch.eick angepasst an meinen Stromlieferanten, die Readings schauen so aus:
Da hat sich Chritian an die DWD Struktur angelehnt. Sieht gut und praktikabel aus.
300P hat auch noch einen sehr guten Ansatz gepostet.
Nun kann ich mir vorstellen, dass es reizvoll ist in der grafischen Vorhersage auch die zukünftigen Bezugspreise fcx_xx_total abgetragen zu sehen (wenn man es wünscht).
Neben der visuellen Aufbereitung könnten sich Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.
Wieder ein spannendes Thema.
Wie verarbeitet ihr diese Daten zur Zeit? Mal abgesehen von dem reinen Informationsaspekt.
LG
Zitat von: DS_Starter am 13 März 2024, 09:43:59< snip >
Nun kann ich mir vorstellen, dass es reizvoll ist in der grafischen Vorhersage auch die zukünftigen Bezugspreise fcx_xx_total abgetragen zu sehen (wenn man es wünscht).
Neben der visuellen Aufbereitung könnten sich Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.
Wieder ein spannendes Thema.
Wie verarbeitet ihr diese Daten zur Zeit? Mal abgesehen von dem reinen Informationsaspekt.
Die Anlehnung ans DWD Device ist nicht zufällig, da ich so gleiche SQL SELECTS und gleiche Mechanismen verwenden kann.
Meine Darstellung des Triggers erfolgt im Grafana als On/Off, sodass man schön die Zeiten sehen kann, in denen gespart werden könnte.
Ich verwende, obwohl ich auch keine Börsenpreise habe, den Trigger und starte z.B. im Winter, wenn ich eh aus dem Netz beziehen muss einige Geräte zum Trigger Fenster.
Die E-Auto Fahrer laden mit dem Trigger Ihre Fahrzeuge.
Bei Tibber bekommt man zusätzlich noch die aufgelaufenen Kosten und die live Messwerte vom Tibber Pulse Lesekopf. Das läuft für die Kunden über eine Websocket Verbindung die innerhalb der userreadings aufgebaut wird.
Ich arbeite immer mal wiedere daran, dass die Börsen Devices vom Aufbau gleich erscheinen, damit man einfacher hin und her switchen kann.
VG Christian
Zitat von: DS_Starter am 13 März 2024, 09:43:59Nun kann ich mir vorstellen, dass es reizvoll ist in der grafischen Vorhersage auch die zukünftigen Bezugspreise fcx_xx_total abgetragen zu sehen (wenn man es wünscht).
Genau darum geht's. Nur den aktuellen Preis zu sehen hat keinerlei Mehrwert für die (automatische oder manuelle) Verbrauchsplanung.
Zitat von: DS_Starter am 13 März 2024, 09:43:59Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.
Genau was ich oben angeregt habe :-)
Zitat von: DS_Starter am 13 März 2024, 09:43:59Wie verarbeitet ihr diese Daten zur Zeit? Mal abgesehen von dem reinen Informationsaspekt.
Derzeit noch kaum, weil ich erst seit 2 Wochen den variablen Tarif habe.
Mit dem alten Tarif war's immer besser, den PV-Eigenverbrauch zu optimieren, d.h. der größte Verbraucher (Wärmepumpe für Heizung und Warmwasser) ist ohnehin nur tagsüber gelaufen.
Mit dem neuen Tarif könnte es Situationen geben, in denen es günstiger wäre den Verbrauch zu einem Zeitpunkt eines niedrigen Bezugstarifs trotz fehlender PV-Abdeckung zu legen. Mit der Visualisierung könnte ich das zumindest mal händisch machen.
Zitat von: DS_Starter am 12 März 2024, 08:30:27Guten Morgen,
oh je, da bist aber wirklich weit hinterher. Inzwischen ist das Modul ofiziell eingescheckt und wir sind Stand heute bei der Version v1.16.6 angekommen.
Manuelles Update ist nicht mehr nötig.
Es ist natürlich sehr viel passiert in der Zwischenzeit.
EIn Update sollte funktionieren. Dabei werden vermutlich viele Meldungen kommen, die zunächst mal ignorieren. Wenn das Device noch lebt einen "set ... plantConfiguration check" ausführen und schauen was da kommt.
Zum DWD gibt es eine optionale Entwicklungsversion in meinem contrib. Damit kann mit forecastRefresh=1 eine höhere Updategenauigkeit (MOSMIX_S) erreicht werden. Näheres dazu im DWD Thread.
Grüße,
Heiko
update all...
shutdown restart...
Logfile:
Zitat2024.03.13 09:55:03 1: PVVorschau - ERROR - consumer >04< use >mintime=SunPath< but readings >Today_SunRise< / >Today_SunSet< are not set properly.
2024.03.13 09:55:03 1: PERL WARNING: Argument "SunPath" isn't numeric in division (/) at ./FHEM/76_SolarForecast.pm line 8128.
2024.03.13 09:55:03 1: PVVorschau - ERROR - consumer >05< use >mintime=SunPath< but readings >Today_SunRise< / >Today_SunSet< are not set properly.
2024.03.13 09:55:03 1: PVVorschau - ERROR - consumer >06< use >mintime=SunPath< but readings >Today_SunRise< / >Today_SunSet< are not set properly.
Modulübersicht war "weg", wurde aber sehr gut durch die Benutzerführung erklärt --> Wettervorhersage Device fehlte --> korrigiert.
Erneutes set plantConfigurationCheck check...
alles gut (FTUI2 = tangiert mich nicht)
ZitatThe selected SolarForecast model cannot use AI support.
Gibts inzwischen empfehlenswertere Möglichkeiten des Moduls ? (ich suche nach den Begriffen hier im Forum, wenn ich weiß wonach ich suchen soll)
Zitat von: TheTrumpeter am 13 März 2024, 10:00:27< snip >
Derzeit noch kaum, weil ich erst seit 2 Wochen den variablen Tarif habe.
Mit dem alten Tarif war's immer besser, den PV-Eigenverbrauch zu optimieren, d.h. der größte Verbraucher (Wärmepumpe für Heizung und Warmwasser) ist ohnehin nur tagsüber gelaufen.
Mit dem neuen Tarif könnte es Situationen geben, in denen es günstiger wäre den Verbrauch zu einem Zeitpunkt eines niedrigen Bezugstarifs trotz fehlender PV-Abdeckung zu legen. Mit der Visualisierung könnte ich das zumindest mal händisch machen.
Das ist bereits im EVU_Tibber Device dargestellt, es gibt SVGs für fc0 und fc1, sowie ein Zeitfenster mit Trigger Preis. Mit dem Trigger reagierst Du in einem DOIF direkt, oder verwendest die Uhrzeiten zur Planung. Es gibt auch ein Fenster für das Maximum, um dort keine Großverbraucher zu betreiben, bzw bewust den Speicher zu verwenden.
Expertise gewünscht zu folgendem Problemchen, was ich über den Winter nicht so recht in den Griff bekommen habe:
Die Steckdose eines Luftentfeuchters soll bei genügend PV-Überschuss UND Luftfeuchtigkeit größer 65% eingeschaltet und bei zu wenig Überschuss ABgeschaltet werden.
Ist die Luftfeuchte jedoch größer 67%, soll die Steckdose unabhängig vorhandener PV-Leistung einschalten und bei Unterschreitung kleiner Y wieder abschalten. Ich vermute meine regulären Ausdrücke sind weiterhin fehlerbehaftet? So siehts bisher aus.
Mein Problem: ich beobachte ständig niedrige Luftfeuchtigkeit und trotzdem ist die Steckdose eingeschaltet.
Zitatattr PVVorschau consumer06 ShellyPlug1
type=other
power=300
mode=can
on=on
off=off
pcurr=power:W
swstate=state:on:off
mintime=SunPath
locktime=900
notbefore=07
notafter=22
icon=Ventilator_fett
spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:100|6[7-9]|[7-9][0-9]
swoncond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:100|6[5-9]|[5-9][0-9]
100|6[7-9]|[7-9][0-9] = true, wenn größer "67", oder?
ZitatDie Steckdose eines Luftentfeuchters soll bei genügend PV-Überschuss UND Luftfeuchtigkeit größer 65% eingeschaltet und bei zu wenig Überschuss ABgeschaltet werden.
Da dieses Verfahren zw. 07-22 laufen soll, bietet sich an zunächst die Schlüssel power=0 und mintime=900 zu setzen. Für die Einplanung wäre evtl. auch mode=must sinnvoll.
Dann die Schlüssel spignorecond, swoncond löschen und dafür interruptable einsetzen:
interruptable=ESPEasy_ESP_Easy1_am2302_sensor:humidity:100|6[7-9]|[7-9][0-9]
Der Regex sollte soweit passen. Kann man sicher noch verbessern, habe mir jetzt aber auf die Schnelle nicht näher angeschaut, nur getestet auf https://regex101.com.
Die Seite bietet sich an um seine Regex zu testen und zu optimieren.
LG
Zitat von: DS_Starter am 13 März 2024, 09:43:59Neben der visuellen Aufbereitung könnten sich Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.
Wieder ein spannendes Thema.
Wie verarbeitet ihr diese Daten zur Zeit? Mal abgesehen von dem reinen Informationsaspekt.
Hier (m)eine Version die (ohne/mit) SQL auskommen kann.
Sinn des Programmes:
Bereitstellung der aktuellen EVU-Bezugs-Preise.
Preise abholen in Höhe von x.yyyyy Euro/kWh für den aktuellen Tag und ab 13:00 Uhr beginnend auch für den nächsten Tag (stündlich jeweils ab 00:00 ... 23:00 Uhr)
Holt (derzeitig) alle 30 Sekunden die aktuell bereitgestellten Daten (API von der Tibber-Website) ab.
Bei Tibber ist es notwendig einen laufenden Vertrag um die "Echt"-Daten abzuholen.
->>Ansonsten geht es nur über einen Dummy-Zugang der in schwedischen Kronen (SEK) läuft.
Zusätzlich werden die noch Doif-Module "diTibberDaten" und passender Code in 99_myUtils benötigt.
defmod myTibber HTTPMOD https://api.tibber.com/v1-beta/gql 30
attr myTibber DbLogExclude .*. (somit dann ohne DBLog)
attr myTibber DbLogInclude Strompreis,BatteryCharge.*,TomorrowTotal
attr myTibber alignTime 00:01
attr myTibber comment _homes_01 \
############comment################\
DEMO-Token : 5K4MVS-OjfWhK_4yrjOlFe1F6kJXPVf7eQYggo8ebAE\
############comment################\
\
attr myTibber enableControlSet 1
attr myTibber event-on-change-reading Strompreis, TodayAverage, TodayMin, BatteryCharge.*, TomorrowTotal
attr myTibber group Tibber
attr myTibber reading1JSON data_viewer_homes_01_currentSubscription_priceInfo_current_total
attr myTibber reading1Name Strompreis
attr myTibber reading1OExpr $val
attr myTibber reading2-1Name Datum
attr myTibber reading2-2Name Uhrzeit
attr myTibber reading2JSON data_viewer_homes_01_currentSubscription_priceInfo_current_startsAt
attr myTibber reading2Regex startsAt":"([\d+-]+)T(\d\d:\d\d)
attr myTibber replacement1Mode text
attr myTibber replacement1Regex %%Token%%
attr myTibber replacement1Value >hier den eigenen Token oder den Dummy-Token für SEK einsetzen<
attr myTibber requestData { "query": "{viewer {homes {currentSubscription {priceInfo {current {total energy tax startsAt} today {total energy tax startsAt } tomorrow {total energy tax startsAt }}}}}}" }
attr myTibber requestHeader1 Content-Type: application/json
attr myTibber requestHeader2 Authorization: Bearer %%Token%%
attr myTibber room 025_Tibber
attr myTibber showBody 1
attr myTibber showError 1
attr myTibber stateFormat Je nachdem BatteryChargeProcess (0-off/1=on) wird das berechnete Zeitfenster zum Laden genutzt. (BatteryChargeStartAt Uhr bis BatteryChargeStartAtEnd:00 Uhr / BatteryChargeUpTime Stunden)
attr myTibber userReadings TodayAverage {use List::Util qw(sum);;;;\
my @Preise = split /\|/, ReadingsVal("myTibber","TodayTotal",0.25);;;; return (sum(@Preise) / @Preise);;;; },\
TomorrowAverage {use List::Util qw(sum);;;;\
my @Preise = split /\|/, ReadingsVal("myTibber","TomorrowTotal",0.25);;;; return $Preise[0] eq "NV" ? "NV" : (sum(@Preise) / @Preise);;;; },\
TodayMin {use List::Util qw(min);;;; my @Preise = split /\|/, ReadingsVal("myTibber","TodayTotal",0.25);;;; return (min @Preise);;;; },\
TomorrowMin {use List::Util qw(min);;;; my @Preise = split /\|/, ReadingsVal("myTibber","TomorrowTotal",0.25);;;; return (min @Preise);;;; },\
BatteryChargeGriduntil;;;;\
BatteryChargeStartAt;;;;\
BatteryChargeStartAtEnd;;;;\
BatteryChargeStartMinIndex;;;;\
BatteryChargeUpMinTime;;;;\
BatteryChargeUpTime;;;;\
BatteryChargeUpTimeDuration;;;;\
BatteryChargeProcess;;;;\
MinTibberStartMinIndex;;;;\
MinTibberStartMinPreis;;;;\
MinTibberStartZeitfenster;;;;
attr myTibber verbose 3
setstate myTibber Je nachdem 0 (0-off/1=on) wird das berechnete Zeitfenster zum Laden genutzt. (04:00 Uhr bis 6:00 Uhr / 2 Stunden)
setstate myTibber 2024-01-24 19:32:50 BatteryChargeGriduntil 85
setstate myTibber 2024-03-12 23:41:39 BatteryChargeProcess 0
setstate myTibber 2024-03-12 18:27:44 BatteryChargeStartAt 04:00
setstate myTibber 2024-03-12 18:28:07 BatteryChargeStartAtEnd 6
setstate myTibber 2024-03-12 16:14:00 BatteryChargeStartMinIndex 0
setstate myTibber 2024-03-03 19:18:09 BatteryChargeUpMinTime 17
setstate myTibber 2024-02-05 12:44:38 BatteryChargeUpTime 2
setstate myTibber 2024-03-03 19:18:44 BatteryChargeUpTimeDuration 21
setstate myTibber 2024-03-13 10:39:00 Datum 2024-03-13
setstate myTibber 2024-03-12 10:22:02 LAST_ERROR read from https://api.tibber.com:443 timed out
setstate myTibber 2024-03-12 16:14:00 MinTibberStartMinIndex 0
setstate myTibber 2024-03-12 16:14:00 MinTibberStartMinPreis 0.4434
setstate myTibber 2024-03-12 16:14:00 MinTibberStartZeitfenster 17:16
setstate myTibber 2024-03-13 10:39:00 Strompreis 0.2217
setstate myTibber 2024-03-13 10:39:00 TodayAverage 0.2217
setstate myTibber 2024-03-13 10:39:00 TodayMin 0.2217
setstate myTibber 2024-03-13 00:01:00 TodayTotal 0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|0.2217|
setstate myTibber 2024-03-13 10:39:00 TomorrowAverage 999999
setstate myTibber 2024-03-13 10:39:00 TomorrowMin 999999
setstate myTibber 2024-03-13 00:01:00 TomorrowTotal 999999
setstate myTibber 2024-03-13 10:39:00 Uhrzeit 10:00
Die zugehörige DOIF
defmod diTibberDaten DOIF ([00:01]) (set myTibber reread) ({TibberDaten()})\
DOELSEIF (([12:00-12:15, +0:01]) and [myTibber:TomorrowTotal] ne 999999) (setreading myTibber TomorrowTotal 999999)\
DOELSEIF (([13:00-15:15, +0:05] or [15:15-23:40, +0:15]) and [myTibber:TomorrowTotal] eq 999999) (set myTibber reread) ({TibberDaten()})\
DOELSEIF ({MinStromTime(16,2,24)})\
DOELSEIF ( ([13:00-15:15, +0:05]) and [myTibber:TomorrowTotal] eq "999999") ([{MinStromTime(16,2,24)}])\
attr diTibberDaten do always
attr diTibberDaten group Tibber
attr diTibberDaten room 025_Tibber,Strompreis->Dynamisch
attr diTibberDaten verbose 3
setstate diTibberDaten cmd_1
setstate diTibberDaten 2024-03-13 00:01:00 cmd 1.2
setstate diTibberDaten 2024-03-13 00:01:00 cmd_event timer_1
setstate diTibberDaten 2024-03-13 00:01:00 cmd_nr 1
setstate diTibberDaten 2024-03-13 00:01:00 cmd_seqnr 2
setstate diTibberDaten 2024-03-11 09:47:41 mode enabled
setstate diTibberDaten 2024-03-13 00:01:00 state cmd_1
setstate diTibberDaten 2024-03-13 00:01:00 timer_01_c01 14.03.2024 00:01:00
setstate diTibberDaten 2024-03-12 12:15:00 timer_02_c02 13.03.2024 12:00:00
setstate diTibberDaten 2024-03-12 12:15:00 timer_03_c02 13.03.2024 12:15:00
setstate diTibberDaten 2024-03-12 15:15:00 timer_05_c03 13.03.2024 13:00:00
setstate diTibberDaten 2024-03-12 15:15:00 timer_06_c03 13.03.2024 15:15:00
setstate diTibberDaten 2024-03-12 23:40:00 timer_08_c03 13.03.2024 15:15:00
setstate diTibberDaten 2024-03-12 23:40:00 timer_09_c03 13.03.2024 23:40:00
setstate diTibberDaten 2024-03-12 15:15:00 timer_11_c05 13.03.2024 13:00:00
setstate diTibberDaten 2024-03-12 15:15:00 timer_12_c05 13.03.2024 15:15:00
und hier die zugehörige 99_myUtils in der aktuellen Test-Version.
##############################################
# $Id: myUtils.pm 21509 2024-02-09 16:30:00Z 300P $
# Status 2024-02-09 16:30
# Save this file as 99_myUtils.pm, and create your own functions in the new
# file. They are then available in every Perl expression.
# Hinweis :
# diverse Anregungen und Programmteile genutzt von https://www.juergenstechnikwelt.de/smarthome-2/tibber-in-fhem-einbinden-beste-zeiten-fuer-niedrige-strompreise-ermitteln/Original
#
package main;
use strict;
use warnings;
use List::MoreUtils qw{
true first_index
};
use List::Util qw( sum );
sub
myUtils_Initialize($$)
{
my ($hash) = @_;
}
# Enter you functions below _this_ line.
sub SMABatteryChargewithTibber()
{
#########################################################################################################################################
# Aufruf erfolgt über Notify "N.PV.TotalConsumption.Dum.Energy" ca. alle 15 sekunden
# Voraussetzung:
# Device myTibber muss installiert sein
# zugehörige sub MinTibberZeitfenster muss in myUtils vorhanden sein
# zugehörige sub TibberDaten muss in myUtils vorhanden sein
# zugehörige sub MinStromTime muss in myUtils vorhanden sein
# myTibber ->>> Aus dem Array mit den Strompreisen des definierten Zeitfenster wird der Zeitraum mit dem niedrigsten Preis ermittelt
# Parameter1: Preisarray
# Parameter2: Laufzeit in Stunden
# Return: Der StartIndex innerhalb der übergebenen Strompreise
# Aufruf erfolgt über ein existierendes Notify bei Berechnung der aktuellen Energie- und PV-Datenstatistik im ca. 15 Sekundentakt
#########################################################################################################################################
###############################################################################
# Gleich halten wie in sub SMABatteryChargewithTibberinMinTibberZeitfenster
# 2023-02-03 17:28
###############################################################################
my $Battery_Device = "BatteryDummy"; # aus Modul Solarforecast-Batteriedummy
my $Battery_Device_rated_capacity = "bat_rated_capacity"; ### aktuell hinterlegter Batteriekapazitätswert
my $Battery_Current_rated_capacity = ReadingsNum( $Battery_Device, $Battery_Device_rated_capacity, 0);; ### aktuell hinterlegter Batteriekapazitätswert
my $Forecast_Device = "Forecast"; # aus Modul Solarforecast
my $Forecast_Device_StatusCharge = "Current_BatCharge"; ### aktuell hinterlegter Batterie SOC-Wert
my $Forecast_Device_Tomorrow_PVforecast = "Tomorrow_PVforecast"; ### aktuell hinterlegter Forecast
my $Forecast_Device_RestOfDayPVforecast = "RestOfDayPVforecast"; ### aktuell hinterlegt
my $Forecast_Current_BatCharge = ReadingsNum( $Forecast_Device, $Forecast_Device_StatusCharge, 0);
# Ladestatus in Summe von (allen) vorhandenen Batterien
my $Forecast_Current_Tomorrow_PVforecast = ReadingsNum( $Forecast_Device, $Forecast_Device_Tomorrow_PVforecast, 0);
# PV-Ertrag am nächsten Tag
my $Forecast_Current_RestOfDayPVforecast = ReadingsNum( $Forecast_Device, $Forecast_Device_RestOfDayPVforecast, 0);
# restlicher PV-Ertrag am heutigen Tag Tag
my $Tibber_Device = "myTibber";
my $Tibber_Device_BatteryChargeGriduntil = "BatteryChargeGriduntil"; ### Batterie SOC-Wert Ladesteuerung - Reading in myTibber
# Griduntil = jewiels aktueller SOC-Wert bis zu dem weiter geladen werden sollte( 85 %)
my $Tibber_Device_BatteryChargeUpMinTime = "BatteryChargeUpMinTime"; ### Uhrzeit ab wann frühestens geladen werden soll - Reading in myTibber
# MinTime = MinHour: FrühesterStart (Beispiel: 15 für 15:00 Uhr),
my $Tibber_Device_BatteryChargeStartMinIndex = "BatteryChargeStartMinIndex"; ### aktueller Zeitindex in Stunden 0-24 bis zum Ladezeitstartzeitpunkt - Reading in myTibber
# StartMinIndex = Anzahl Stunden nach MinTime
my $Tibber_Device_BatteryChargeStartAt = "BatteryChargeStartAt";
# StartAt = um wieviel Uhr soll gestartet werden - Reading in myTibber
my $Tibber_Device_BatteryChargeStartAtEnd = "BatteryChargeStartAtEnd";
# StartAtEnd = um wieviel Uhr soll beendet werden - Reading in myTibber
my $Tibber_Device_BatteryChargeUpTime = "BatteryChargeUpTime"; ### Ladungsdauer in Stunden - Reading in myTibber
# UpTime = Laufzeit: Laufzeit in Stunden, (Da es nur Stundenpreise gibt, kann die Laufzeit immer auf Stunden aufgerundet werden)
my $Tibber_Device_BatteryChargeUpTimeDuration = "BatteryChargeUpTimeDuration"; ### Zeitdauer der Preisprüfung - Reading in myTibber
# UpTimeDuration = Zeitdauer der Preisprüfung
my $Tibber_Device_BatteryChargeProcess = "BatteryChargeProcess"; ### Ladung ein = 1 - Ladung per Modul aus = 0 - Reading in myTibber
###############################################################################
# Gleich halten wie in sub SMABatteryChargewithTibberinMinTibberZeitfenster
# 2023-02-04 18:28
###############################################################################
my $Tibber_BatteryChargeGriduntil = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeGriduntil, 0);
# hinterlegte max. Grenze Batterie SOC-Wert (85%) für die Tibber-Steuerung
my $Tibber_BatteryChargeUpMinTime = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeUpMinTime, 0);
### später als z.B. 14 Uhr wegen Bekanntgabe der Tommorrow-Werte
my $Tibber_BatteryChargeStartAt = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeStartAt, 0);
# StartAt = um wieviel Uhr soll gestartet werden - Reading in myTibber
my $Tibber_BatteryChargeStartMinIndex = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeStartMinIndex, 0);
### aktueller Zeitindex in Stunden 0-24 bis zum Ladezeitstartzeitpunkt
my $Tibber_BatteryChargeUpTime = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeUpTime, 0);
### UpTime = Laufzeit: Laufzeit in Stunden
# my $Tibber_BatteryChargeStartAtEnd = $Tibber_BatteryChargeStartAt + $Tibber_BatteryChargeStartMinIndex + $Tibber_BatteryChargeUpTime;
# StartAtEnd = Neuberechnung um wieviel Uhr soll Ladung beendet werden
#if ($Tibber_BatteryChargeStartAtEnd > "23") # ist Lade-Endzeit später als 23 Uhr ??? dann Abzug von 24
#{
# $Tibber_BatteryChargeStartAtEnd = ($Tibber_BatteryChargeStartAtEnd - "24");
#}
# fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeStartAtEnd $Tibber_BatteryChargeStartAtEnd");
# StartAtEnd ->> aktuell neu berechnetes Reading in myTibber setzen
#my $Tibber_BatteryChargeStartAtEnd = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeStartAtEnd, 0);
# StartAtEnd = um wieviel Uhr soll beendet werden - Reading in myTibber wird zyklisch neu gesetz
# nur in anderem SUB ->>> fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeStartAtEnd $Tibber_BatteryChargeStartAtEnd");
# StartAtEnd ->> aktuell neu berechnetes Reading in myTibber setzen
my $Tibber_BatteryChargeStartAtEnd = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeStartAtEnd, 0);
# StartAtEnd = um wieviel Uhr soll beendet werden - Reading in myTibber zyklisch neu setzen
my $Tibber_BatteryChargeProcess = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeProcess, 0);
# Process = soll per Tibber geladen werden ?? - Reading in myTibber
my $Tibber_BatteryChargeUpTimeDuration = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeUpTimeDuration, 0);
### UpTimeDuration = Zeitdauer der Preisprüfung
###############################################################
# bis hier gleich halten wie in sub SMABatteryChargewithTibber
###############################################################
my ($sec,$min,$hour,$mday,$mon,$year) = localtime; #??????????
################################################################
# Laden beenden bzw. gar nicht nicht anfangen
# denn die Batterie ist mehr geladen als vorgegeben
################################################################
if ( $Forecast_Current_BatCharge > ($Tibber_BatteryChargeGriduntil + 5)) ### aktueller Batterieladestatus aus Forecast SOC > Vorgabewert + 5 % ?? wenn ja Ladung beenden und zurück
{
# Ladestatus in Summe von (allen) vorhandenen Batterien groesser als XY ?? dann Ende
Log3 undef, 5, "SMABatteryChargewithTibber : 1001 SOC : $Forecast_Current_BatCharge ist >= Tibber_BatteryChargeGriduntil : $Tibber_BatteryChargeGriduntil";
Log3 undef, 5, "SMABatteryChargewithTibber : 1001 SOC : Ende Battery-Ladezyklus : $year-$mon-$mday $hour:$min:$sec";
Log3 undef, 5, "SMABatteryChargewithTibber : 1001 SOC : Ende der Batterieladung_weil voll genug";
SMABatteryChargeOFF();
return; # ???? evtl. irgenwann mal noch Fehlermitteilung zurück mitgeben
}
##############################
# evtl. noch .....ist die Beladung schon eingeschaltet ???? Reading ????
# evtl. zukünftig prüfen ist es Sommer oder Winter (Monat >10 oder < 3) dann wird mit hoher wahrscheinlichkeit Strom für die Battery benötigt
##############################
###############################################################
# prüfen ob aktueller Rest-PVForecast + tomorrowForecast für 24 Stunden (bis morgen xy Uhr)ausreicht oder nicht - dann keine Ladung
###############################################################
my $tempStundenverbrauch = "850"; # allgemeiner Durchschnittsverbrauch pro Stunde (evtl. noch irgenwoher ableiten oder errechnen)
my $tempStundenanzahl = ( (24 - $hour) + "18"); # Verbrauchszeitraum bis Morgen 18 Uhr berücsichtigen (evtl. noch irgenwoher ableiten oder errechnen)
my $tempVerbrauchsbedarf = ($tempStundenanzahl * $tempStundenverbrauch); # allgemeiner Durchschnittsverbrauch pro Stunde mal Zeitraum bis tempstundenanzahl Uhr
Log3 undef, 4, "SMABatteryChargewithTibber : xx2 Es ist $hour Uhr - Verbrauchsprognose bis Morgen um 14 Uhr ist $tempVerbrauchsbedarf";
Log3 undef, 4, "SMABatteryChargewithTibber : xx3 Heute noch $Forecast_Current_RestOfDayPVforecast PV-Ertrag";
Log3 undef, 4, "SMABatteryChargewithTibber : xx4 Morgen noch $Forecast_Current_Tomorrow_PVforecast PV-Ertrag";
Log3 undef, 4, "SMABatteryChargewithTibber : xx5 BatteryCapacity $Battery_Current_rated_capacity $Forecast_Current_Tomorrow_PVforecast + $Forecast_Current_RestOfDayPVforecast ";
if (( $hour >= "14") and ($hour <= "24" )) # ab 14 Uhr und heute
{
my $temp001 = $Forecast_Current_Tomorrow_PVforecast + $Forecast_Current_RestOfDayPVforecast + ($Battery_Current_rated_capacity * 1000 * $Forecast_Current_BatCharge / 100);
my $tempbatterieladung = ($Battery_Current_rated_capacity * 1000 * $Forecast_Current_BatCharge / 100);
Log3 undef, 4, "SMABatteryChargewithTibber : xx5a Forecastrestoftoday + Forecasttomorrow + Batterieladung temp001 = $temp001 = $Forecast_Current_Tomorrow_PVforecast + $Forecast_Current_RestOfDayPVforecast + $Battery_Current_rated_capacity * 1000 * $Forecast_Current_BatCharge : 100";
Log3 undef, 4, "SMABatteryChargewithTibber : xx5b $Forecast_Current_BatCharge Batterieladung $tempbatterieladung ";
if ( $temp001 > $tempVerbrauchsbedarf )
# PV-Ertrag zu Verbrauch sollte für bis morgen xy Uhr reichen
{
Log3 undef, 4, "SMABatteryChargewithTibber : xx6 Batterieladung + Erwarteter PV-Ertrag von Heute (Rest) und Morgen wird hoch genug sein - Kein EVU-Strombezug notwendig";
Log3 undef, 4, "SMABatteryChargewithTibber : xx6a Tibber_Device_BatteryChargeProcess = $Tibber_Device_BatteryChargeProcess Tibber_BatteryChargeProcess = $Tibber_BatteryChargeProcess";
if ( $Tibber_BatteryChargeProcess == "1" )
{
# Tibber-Ladung aussetzen - Reading wird in myTibber auf OFF gesetzt
$Tibber_BatteryChargeProcess = 0;
fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeProcess $Tibber_BatteryChargeProcess");
Log3 undef, 1, "SMABatteryChargewithTibber : xx6b SET Tibber_Device_BatteryChargeProcess OFF = $Tibber_Device_BatteryChargeProcess Tibber_BatteryChargeProcess $Tibber_BatteryChargeProcess";
#return; # zu erwartende heutige (Rest) und morgige Solarleistung beträgt weit mehr mehr als genug
}
}
if ( $temp001 <= $tempVerbrauchsbedarf )
# PV-Ertrag zu Verbrauch sollte für bis morgen xy Uhr nicht reichen
{
Log3 undef, 4, "SMABatteryChargewithTibber : xx6d Erwarteter PV-Ertrag von Heute (Rest) und Morgen wird wohl NICHT hoch genug sein - EVU-Strombezug notwendig";
if ($Tibber_BatteryChargeProcess == "0")
{
# Tibber-Ladung - Reading wird in myTibber auf ON gesetzt
$Tibber_BatteryChargeProcess = "1";
fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeProcess $Tibber_BatteryChargeProcess");
Log3 undef, 1, "SMABatteryChargewithTibber : xx6c 14 bis 24 Uhr - SET Tibber_Device_BatteryChargeProcess ON = $Tibber_Device_BatteryChargeProcess Tibber_BatteryChargeProcess $Tibber_BatteryChargeProcess";
}
}
}
if (( $hour >= "0") and ($hour < "14")) # nachts nach Mitternach schauen ob sich daran noch was ändert bis heute 14 Uhr (mittags)
{
$tempStundenanzahl = ( (14 - $hour)); # Verbrauchszeitraum bis heute 14 Uhr !!!!!
$tempVerbrauchsbedarf = ($tempStundenanzahl * $tempStundenverbrauch); # allgemeiner Durchschnittsverbrauch pro Stunde mal Zeitraum bis 14 Uhr
my $temp001 = $Forecast_Current_RestOfDayPVforecast + ($Battery_Current_rated_capacity * 1000 * $Forecast_Current_BatCharge / 100); # nur Heute betrachten !!!
my $tempbatterieladung = ($Battery_Current_rated_capacity * 1000 * $Forecast_Current_BatCharge / 100);
Log3 undef, 4, "SMABatteryChargewithTibber : xx7a Forecastrestoftoday + Batterieladung temp001 = $temp001 = $Forecast_Current_RestOfDayPVforecast + $Battery_Current_rated_capacity * 1000 * $Forecast_Current_BatCharge : 100";
Log3 undef, 4, "SMABatteryChargewithTibber : xx7b $Forecast_Current_BatCharge Batterieladung $tempbatterieladung ";
if ( $temp001 > $tempVerbrauchsbedarf)
# PV-Ertrag sollte für bis heute (14) reichen
{
if ($Tibber_BatteryChargeProcess == "1")
{
# Tibber-Ladung - Reading wird in myTibber auf OFF gesetzt
$Tibber_BatteryChargeProcess = "0";
fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeProcess $Tibber_BatteryChargeProcess");
Log3 undef, 1, "SMABatteryChargewithTibber : xx8 0 bis 14 Uhr - SET Tibber_Device_BatteryChargeProcess OFF = $Tibber_Device_BatteryChargeProcess";
#return; # zu erwartende heutige (Rest) Solarleistung beträgt weit mehr mehr als genug
}
Log3 undef, 4, "SMABatteryChargewithTibber : xx8a Erwarteter PV-Ertrag von Heute bis 14 Uhr wird hoch genug sein - Kein EVU-Strombezug notwendig";
#return; # zu erwartende heutige Solarleistung bis 14 Uhr beträgt mehr als genug
}
if ( $temp001 <= $tempVerbrauchsbedarf)
# PV-Ertrag sollte für bis heute (14) nicht reichen
{
Log3 undef, 4, "SMABatteryChargewithTibber : xx9 Erwarteter PV-Ertrag von Heute bis 14 Uhr wird NICHT hoch genug sein - EVU-Strombezug ist notwendig";
if ($Tibber_BatteryChargeProcess == "0")
{
# Tibber-Ladung - Reading wird in myTibber auf ON gesetzt
$Tibber_BatteryChargeProcess = "1";
fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeProcess $Tibber_BatteryChargeProcess");
Log3 undef, 1, "SMABatteryChargewithTibber : xx9a 00 bis 14 Uhr - SET Tibber_Device_BatteryChargeProcess ON = $Tibber_Device_BatteryChargeProcess";
}
Log3 undef, 4, "SMABatteryChargewithTibber : xx10 Erwarteter PV-Ertrag von Heute bis 14 Uhr (Rest) wird wohl NICHT hoch genug sein - EVU-Strombezug notwendig";
}
}
###############################################################
# Ende
# evtl. jetzt erst mal prüfen ob aktueller PVForecast + aktueller BatteryChargestatus für die nächsten 24 Stunden bereits ausreicht oder nicht
###############################################################
#############################################################
if ( $Tibber_BatteryChargeProcess eq "0" )
{
Log3 undef, 5, "SMABatteryChargewithTibber : 6789 Tibber_BatteryChargeProcess ist $Tibber_BatteryChargeProcess => kein Laden / Modulaufruf errechnet / gewünscht";
return;
}
#############################################################
if ($Forecast_Current_BatCharge < $Tibber_BatteryChargeGriduntil) #### aktueller Batterieladestatus unterhalb Vorgabewert ???
{
if ($hour >= ($Tibber_BatteryChargeUpMinTime))
{
if ($hour <= "24")
{
##############
Log3 undef, 5, "SMABatteryChargewithTibber : 1002 SOC : $Forecast_Current_BatCharge < $Tibber_BatteryChargeGriduntil- hour aktuell (14-24) : $hour ist kleiner als 24 ....$Tibber_BatteryChargeUpMinTime";
Log3 undef, 5, "SMABatteryChargewithTibber : 1002 SOC : Jetzt wird wohl HEUTE PLANMÄßIG geladen wenn .......";
# unter 85 % AND Uhrzeit > Wert AND Uhrzeit max 24 Uhr
if ($hour >= $Tibber_BatteryChargeStartAt)
{
Log3 undef, 5, "SMABatteryChargewithTibber : 1002a Jetzt ist es spät genug : Uhrzeit $hour BatteryChargeStartAt : $Tibber_BatteryChargeStartAt BatteryChargeUpTime : $Tibber_BatteryChargeUpTime BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAtEnd";
if ($hour < $Tibber_BatteryChargeStartAtEnd)
{
my $tempdaten = (24 - $hour)*(800/19600*100) + (19600*$Forecast_Current_BatCharge/100);
# if ($Forecast_Current_BatCharge <= ($Forecast_Current_BatCharge + $tempdaten)
# {
Log3 undef, 5, "SMABatteryChargewithTibber : 1002a1 Jetzt ist es wohl wirklich spät genug : Uhrzeit $hour Forecast_Current_BatCharge $Forecast_Current_BatCharge ist kleiner als $tempdaten";
SMABatteryChargeON();
Log3 undef, 5, "SMABatteryChargewithTibber : 1002b Jetzt wird HEUTE PLANMÄßIG geladen : Uhrzeit $hour BatteryChargeStartAt + BatteryChargeUpTime ist <= BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAt + $Tibber_BatteryChargeUpTime = $Tibber_BatteryChargeStartAtEnd";
# }
}
else
{
SMABatteryChargeOFF();
Log3 undef, 5, "SMABatteryChargewithTibber : 1002c HEUTE ABEND wird NICHT mehr PLANMÄßIG geladen : Uhrzeit $hour BatteryChargeStartAt : $Tibber_BatteryChargeStartAt BatteryChargeUpTime : $Tibber_BatteryChargeUpTime BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAtEnd";
Log3 undef, 5, "SMABatteryChargewithTibber : 1002d .........wäre HEUTE PLANMÄßIG geladen worden aber : Uhrzeit $hour BatteryChargeStartAt + BatteryChargeUpTime ist <= BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAt + $Tibber_BatteryChargeUpTime = $Tibber_BatteryChargeStartAtEnd";
}
# return; # raus ?
}
}
}
if ($hour < ($Tibber_BatteryChargeUpMinTime))
{
if ($hour >= "00") # also beide Fragen ähnlich bzw. gleich ->> zwischen 00:00 Uhr bis 13:59 Uhr (< 14 Uhr)
{
Log3 undef, 5, "SMABatteryChargewithTibber : 1003 SOC : $Forecast_Current_BatCharge < $Tibber_BatteryChargeGriduntil- hour (00-13) : $hour : ist kleiner als $Tibber_BatteryChargeUpMinTime";
Log3 undef, 5, "SMABatteryChargewithTibber : 1003 SOC : Jetzt wird wohl heute Nacht / MORGEN PLANMÄßIG geladen wenn .......";
# unter 85 % AND Uhrzeit kleiner (14) Uhr AND Uhrzeit > Startuhrzeit (?? und wenn vor 23 Uhr gestartet ??? unklar)
if ($hour >= $Tibber_BatteryChargeStartAt)
{
Log3 undef, 5, "SMABatteryChargewithTibber : 1003a Jetzt ist es wohl spät genug zum Laden : Uhrzeit $hour BatteryChargeStartAt : $Tibber_BatteryChargeStartAt BatteryChargeUpTime : $Tibber_BatteryChargeUpTime BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAtEnd";
if ($hour < $Tibber_BatteryChargeStartAtEnd) # weiter laden (???? was wenn gestartet am Vortag ???)
{
SMABatteryChargeON();
Log3 undef, 5, "SMABatteryChargewithTibber : 1003b Jetzt wird ab sofort HEUTE PLANMÄßIG geladen : Uhrzeit $hour BatteryChargeStartAt : $Tibber_BatteryChargeStartAt BatteryChargeUpTime : $Tibber_BatteryChargeUpTime BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAtEnd";
}
else
{
SMABatteryChargeOFF(); # laden jetzt sofort zeitnah beenden
Log3 undef, 5, "SMABatteryChargewithTibber : 1003c HEUTE NACHT bzw. am MORGEN wird NICHT mehr PLANMÄßIG geladen : Uhrzeit $hour BatteryChargeStartAt : $Tibber_BatteryChargeStartAt BatteryChargeUpTime : $Tibber_BatteryChargeUpTime BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAtEnd";
Log3 undef, 5, "SMABatteryChargewithTibber : 1003d .........wäre HEUTE PLANMÄßIG geladen worden aber : Uhrzeit $hour BatteryChargeStartAt + BatteryChargeUpTime ist <= BatteryChargeStartAtEnd : $Tibber_BatteryChargeStartAt + $Tibber_BatteryChargeUpTime = $Tibber_BatteryChargeStartAtEnd";
}
}
}
}
}
}
sub SMABatteryChargewithTibberinMinTibberZeitfenster()
{
#######################################################################################################################
# Voraussetzung:
# Device myTibber muss installiert sein
# zugehörige sub MinTibberZeitfenster muss in myUtils vorhanden sein
# zugehörige sub TibberDaten muss in myUtils vorhanden sein
# zugehörige sub MinStromTime muss in myUtils vorhanden sein
# myTibber ->>> Aus dem Array mit den Strompreisen des definierten Zeitfenster wird der Zeitraum mit dem niedrigsten Preis ermittelt
# Parameter1: Preisarray
# Parameter2: Laufzeit in Stunden
# Return: Der StartIndex innerhalb der übergebenen Strompreise
# Nutzung in myTibber
#######################################################################################################################
############################################################################
#
# Deklaration bitte gleich halten wie in der sub SMABatteryChargewithTibber
#
# wird stündlich um 13/14/15 XY:10 Uhr durch at.TibberLoadBattery aufgerufen
# (ansonsten deaktiviert)
# um die Tibber-Ladezeit für die beiden Batterien in der Garage zu ermitteln
############################################################################
my $BatteryCharge_Device = "Forecast"; # aus Solarforecast
my $BatteryCharge_StatusCharge = "Current_BatCharge"; ### aktuell hinterlegter Batterie SOC-Wert
my $Forecast_Current_BatCharge = ReadingsNum( $BatteryCharge_Device, $BatteryCharge_StatusCharge, 0);
# Ladestatus in Summe von (allen) vorhandenen Batterien
my $Tibber_Device = "myTibber";
my $Tibber_Device_BatteryChargeGriduntil = "BatteryChargeGriduntil"; ### Batterie SOC-Wert Ladesteuerung - Reading in myTibber
# Griduntil = jewiels aktueller SOC-Wert bis zu dem weiter geladen werden sollte( 85 %)
my $Tibber_Device_BatteryChargeUpMinTime = "BatteryChargeUpMinTime"; ### Uhrzeit ab wann frühestens geladen werden soll - Reading in myTibber
# MinTime = MinHour: FrühesterStart (Beispiel: 15 für 15:00 Uhr),
my $Tibber_Device_BatteryChargeStartMinIndex = "BatteryChargeStartMinIndex"; ### aktueller Zeitindex in Stunden 0-24 bis zum Ladezeitstartzeitpunkt - Reading in myTibber
# StartMinIndex = Anzahl Stunden nach MinTime
my $Tibber_Device_BatteryChargeStartAt = "BatteryChargeStartAt";
# StartAt = um wieviel Uhr soll gestartet werden - Reading in myTibber
my $Tibber_Device_BatteryChargeStartAtEnd = "BatteryChargeStartAtEnd";
# StartAtEnd = um wieviel Uhr soll beendet werden - Reading in myTibber
my $Tibber_Device_BatteryChargeUpTime = "BatteryChargeUpTime"; ### Ladungsdauer in Stunden - Reading in myTibber
# UpTime = Laufzeit: Laufzeit in Stunden, (Da es nur Stundenpreise gibt, kann die Laufzeit immer auf Stunden aufgerundet werden)
my $Tibber_Device_BatteryChargeUpTimeDuration = "BatteryChargeUpTimeDuration"; ### Zeitdauer der Preisprüfung - Reading in myTibber
# UpTimeDuration = Zeitdauer der Preisprüfung
my $Tibber_Device_BatteryChargeProcess = "BatteryChargeProcess";
# Ladung ein = 1 - Ladungmodul aus = 0 - Reading in myTibber
my $Tibber_Device_MinZeitIndex = "MinTibberStartMinIndex";
# xy Stunden bis zum Start bei aktueller Stunde
###############################################################################
# Gleich halten wie in sub SMABatteryChargewithTibberinMinTibberZeitfenster
# 2023-02-04 18:28
###############################################################################
my $Tibber_BatteryChargeGriduntil = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeGriduntil, 0);
# hinterlegte max. Grenze Batterie SOC-Wert (85%) für die Tibber-Steuerung
my $Tibber_BatteryChargeUpMinTime = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeUpMinTime, 0);
### später als z.B. 14 Uhr wegen Bekanntgabe der Tommorrow-Werte
my $Tibber_BatteryChargeStartAt = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeStartAt, 0);
# StartAt = um wieviel Uhr soll gestartet werden - Reading in myTibber
my $Tibber_BatteryChargeStartMinIndex = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeStartMinIndex, 0);
### aktueller Zeitindex in Stunden 0-24 bis zum Ladezeitstartzeitpunkt
my $Tibber_BatteryChargeUpTime = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeUpTime, 0);
### BatteryChargeUpTime = Laufzeit: Laufzeit in Stunden
my $Tibber_BatteryChargeStartAtEnd = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeStartAtEnd, 0);
# StartAtEnd = um wieviel Uhr soll beendet werden - Reading in myTibber zyklisch neu setzen
my $Tibber_BatteryChargeProcess = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeProcess, 0);
# Process = soll per Tibber geladen werden ?? - Reading in myTibber
my $Tibber_BatteryChargeUpTimeDuration = ReadingsNum( $Tibber_Device, $Tibber_Device_BatteryChargeUpTimeDuration, 0);
### UpTimeDuration = Zeitdauer der Preisprüfung
###############################################################
# bis hier gleich halten wie in sub SMABatteryChargewithTibber
###############################################################
my ($sec,$min,$hour,$mday,$mon,$year) = localtime;
my $Tibber_MinTibberStartZeitfenster = "";
# Zeitraum für die nächsten 24 Stunden - sub MinStromTime($$$) - (z.B. 14,3,24) holen
$Tibber_MinTibberStartZeitfenster = MinStromTime($Tibber_BatteryChargeUpMinTime, $Tibber_BatteryChargeUpTime, $Tibber_BatteryChargeUpTimeDuration);
# grad erzeugter und hinterlegter Zeitindex in myTibber
my $MinZeitIndex = ReadingsNum( $Tibber_Device, $Tibber_Device_MinZeitIndex, 0);
# jetzt sollten die Daten feststehen
Log3 undef, 4, "SMABatteryChargewithTibberinMinTibberZeitfenster : 1009 SSOC : $Forecast_Current_BatCharge ist ?? <= Tibber_BatteryChargeGriduntil : $Tibber_BatteryChargeGriduntil";
Log3 undef, 4, "SMABatteryChargewithTibberinMinTibberZeitfenster : 1009 MinTibberStartZeitfenster $Tibber_MinTibberStartZeitfenster BatteryChargeStartMinIndex $MinZeitIndex ";
# wann wird am günstigsten geladen werden ??
fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeStartAt $Tibber_MinTibberStartZeitfenster"); # hier leider noch mit "Uhrzeit:Minuten" deshalb später Wert rückrechnen !!!!
fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeStartMinIndex $MinZeitIndex"); # aktuellen Wert schreiben - fest ab $Tibber_Device_BatteryChargeStartAt Uhr
$Tibber_BatteryChargeStartAtEnd = $hour + $MinZeitIndex + $Tibber_BatteryChargeUpTime; # aktualisieren damit es auch wirklich die Stunden werden die es sein sollten
# StartAtEnd = Neuberechnung um wieviel Uhr soll Ladung beendet werden
Log3 undef, 4, "SMABatteryChargewithTibberinMinTibberZeitfenster : 1009a hour $hour + MinZeitIndex $MinZeitIndex + Tibber_BatteryChargeUpTime $Tibber_BatteryChargeUpTime Tibber_MinTibberStartZeitfenster $Tibber_MinTibberStartZeitfenster BatteryChargeStartMinIndex $MinZeitIndex Tibber_BatteryChargeStartAtEnd $Tibber_BatteryChargeStartAtEnd";
if ($Tibber_BatteryChargeStartAtEnd > "23") # ist Lade-Endzeit später als 23 Uhr ??? dann Abzug von 24
{
$Tibber_BatteryChargeStartAtEnd = ($Tibber_BatteryChargeStartAtEnd - "24");
}
# StartAtEnd = um wieviel Uhr soll beendet werden - Reading in myTibber wird zyklisch neu gesetz
fhem("setreading $Tibber_Device $Tibber_Device_BatteryChargeStartAtEnd $Tibber_BatteryChargeStartAtEnd");
Log3 undef, 1, "SMABatteryChargewithTibberinMinTibberZeitfenster : 1009b MinTibberStartZeitfenster $Tibber_MinTibberStartZeitfenster BatteryChargeStartMinIndex $MinZeitIndex Tibber_BatteryChargeStartAtEnd $Tibber_BatteryChargeStartAtEnd";
}
sub SMABatteryChargeON()
{
#Werte für Ladungsende per Modbus an Battery senden
fhem("set MB_SBS25 Set_Leistung_W -8000"); # 0 Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set MB_SBS25_2 Set_Leistung_W -8000"); # 0 Watt Netzleistung am Übergabemesspunkt (WR2)
fhem("set MB_SBS25 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR1)
fhem("set MB_SBS25_2 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR2)
###so geht es aber auch (für 30 Minuten - weil so im WR Wartezeit von 30 Minuten hinterlegt wenn kein Kontakt mehr zu Fremdsteuerung besteht)################
#defmod di_Test_Batterie_Laden DOIF ([05:00-05:10]) (set MB_SBS25 Set_Leistung_W 5000) (set MB_SBS25_2 Set_Leistung_W 5000) (set MB_SBS25 Set_Aktiv 802) (set MB_SBS25_2 Set_Aktiv 802)
#attr di_Test_Batterie_Laden comment ([22:10-22:20] and [BatteryDummy:chargestatus] > 85) (set MB_SBS25 Set_Leistung_W 5000) (set MB_SBS25_2 Set_Leistung_W 5000) (set MB_SBS25 Set_Aktiv 802) (set MB_SBS25_2 Set_Aktiv 802)
#attr di_Test_Batterie_Laden room 011_MODBUS,025_Tibber,Strompreis->Dynamisch
#attr di_Test_Batterie_Laden stateFormat timer_01_c01 bis timer_02_c01
#attr di_Test_Batterie_Laden verbose 5
#attr di_Test_Batterie_Laden wait 0,10,10,10
}
sub SMABatteryChargeOFF()
{
#Werte für Ladungsende per Modbus an Battery senden - (wenn nicht klappt evtl delay oder wait einbauen???)
fhem("set MB_SBS25 Set_Leistung_W 0"); # 0 Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set MB_SBS25_2 Set_Leistung_W 0"); # 0 Watt Netzleistung am Übergabemesspunkt (WR2)
fhem("set MB_SBS25 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR1)
fhem("set MB_SBS25_2 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR2)
###so geht es aber auch)################
###################
#defmod di_Test_Batterie_Laden_Ende DOIF ([05:00-05:10]) (set MB_SBS25 Set_Leistung_W 0) (set MB_SBS25_2 Set_Leistung_W 0) (set MB_SBS25 Set_Aktiv 803) (set MB_SBS25_2 Set_Aktiv 803)
#attr di_Test_Batterie_Laden_Ende comment ([22:10-22:20] and [BatteryDummy:chargestatus] > 85) (set MB_SBS25 Set_Leistung_W 0) (set MB_SBS25_2 Set_Leistung_W 0) (set MB_SBS25 Set_Aktiv 803) (set MB_SBS25_2 Set_Aktiv 803)
#attr di_Test_Batterie_Laden_Ende room 011_MODBUS,025_Tibber,Strompreis->Dynamisch
#attr di_Test_Batterie_Laden_Ende stateFormat timer_01_c01 bis timer_02_c01
#attr di_Test_Batterie_Laden_Ende verbose 5
#attr di_Test_Batterie_Laden_Ende wait 0,10,10,10
}
sub TibberDaten()
{
#######################################################################################################################
# Tibber per HTTP auswerten
# Nutzung erfolgt durch myTibber und einige andere Device
#######################################################################################################################
if(InternalVal("myTibber", "httpbody", "") eq "")
{
return;
}
my $json = decode_json(InternalVal("myTibber", "httpbody", "")); # wichtig showBody MUSS = 1 sein
my $today_total = "";
# my $today_energy = ""; # Energy und tax sind nicht notwendig für die Auswertung - mich interssiert nur der Endpreis inkl allem
# my $today_tax = "";
my $tomorrow_total = "";
# my $tomorrow_energy = "";
# my $tomorrow_tax = "";
# Alte Einträge erst einmal löschen
#my $timedelete = TimeNow();
my $timedelete = strftime("%F",localtime(time))." 00:00";
my $time_tomorrow = strftime("%F",localtime(time+86400));
my ($year_today,$mon_today,$day_today) = $timedelete =~ m/(\d\d\d\d)-(\d\d)-(\d\d)/;
my ($year_tomorrow,$mon_tomorrow,$day_tomorrow) = $time_tomorrow =~ m/(\d\d\d\d)-(\d\d)-(\d\d)/;
Log3 undef, 5, "Aufruf (NO NO) von TibberDaten um ".localtime()." mit Löschzeit ".$timedelete." und time_tomorrow ".$time_tomorrow;
##fhem "set DBRep sqlCmd delete from history where DEVICE = 'myTibber' and READING like 'to%' AND TIMESTAMP>='".$timedelete."'";
for(my $j=0; $j<24;$j++)
{
# Werte ermitteln
my $value_today_total = $json->{data}->{viewer}->{homes}[0]->{currentSubscription}->{priceInfo}->{today}[$j]->{total};
# my $value_today_energy = $json->{data}->{viewer}->{homes}[0]->{currentSubscription}->{priceInfo}->{today}[$j]->{energy};
# my $value_today_tax = $json->{data}->{viewer}->{homes}[0]->{currentSubscription}->{priceInfo}->{today}[$j]->{tax};
my $value_tomorrow_total = $json->{data}->{viewer}->{homes}[0]->{currentSubscription}->{priceInfo}->{tomorrow}[$j]->{total};
# my $value_tomorrow_energy = $json->{data}->{viewer}->{homes}[0]->{currentSubscription}->{priceInfo}->{tomorrow}[$j]->{energy};
# my $value_tomorrow_tax = $json->{data}->{viewer}->{homes}[0]->{currentSubscription}->{priceInfo}->{tomorrow}[$j]->{tax};
$today_total = $today_total.$value_today_total."|";
# $today_energy = $today_energy.$value_today_energy."|";
# $today_tax = $today_tax.$value_today_tax."|";
if(defined $value_tomorrow_total)
{
$tomorrow_total = $tomorrow_total.$value_tomorrow_total."|";
# $tomorrow_energy = $tomorrow_energy.$value_tomorrow_energy."|";
# $tomorrow_tax = $tomorrow_tax.$value_tomorrow_tax."|";
}
else
{
$tomorrow_total = '999999'; #= $tomorrow_tax = $tomorrow_energy = "NV"
Log3 undef, 5, "TibberDaten: TomorrowTotal weil keine Werte da sind : $tomorrow_total";
}
Log3 undef, 5, "TibberDaten: TomorrowTotal weil die Werte da sind : $tomorrow_total";
#Timestamp für den Stundenwert
my $timestamp_today = ($j < 10) ? "$year_today-$mon_today-$day_today 0".$j.":00:00" : "$year_today-$mon_today-$day_today $j:00:00";
my $timestamp_tomorrow = ($j < 10) ? "$year_tomorrow-$mon_tomorrow-$day_tomorrow 0".$j.":00:00" : "$year_tomorrow-$mon_tomorrow-$day_tomorrow $j:00:00";
Log3 undef, 5, "TibberDaten: Timestamp tomorrow Stundenwert : $timestamp_tomorrow mit $tomorrow_total Timestamp today Stundenwert: $timestamp_today mit $today_total ";;
# Log3 undef, 5, "TibberDaten: Timestamp tomorrow Stundenwert: $timestamp_today ";
# Werte in der Datenbank loggen
fhem "set myDbLog addCacheLine ".$timestamp_today."|myTibber|addlog|today_total:".$j.":00:00|today_total|".$value_today_total."|";
# fhem "set myDBLog addCacheLine ".$timestamp_today."|myTibber|addlog|today_energy:".$j."|today_energy|".$value_today_energy."|";
# fhem "set myDBLog addCacheLine ".$timestamp_today."|myTibber|addlog|today_tax:".$j."|today_tax|".$value_today_tax."|";
if(defined $value_tomorrow_total)
{
fhem "set myDBLog addCacheLine ".$timestamp_tomorrow."|myTibber|addlog|tomorrow_total:".$j.":00:00|tomorrow_total|".$value_tomorrow_total."|";
# fhem "set myDBLog addCacheLine ".$timestamp_tomorrow."|myTibber|addlog|tomorrow_energy:".$j."|tomorrow_energy|".$value_tomorrow_energy."|";
# fhem "set myDBLog addCacheLine ".$timestamp_tomorrow."|myTibber|addlog|tomorrow_tax:".$j."|tomorrow_tax|".$value_tomorrow_tax."|";
}
}
fhem("setreading myTibber TodayTotal $today_total");
# fhem("setreading myTibber TodayEnergy $today_energy");
# fhem("setreading myTibber TodayTax $today_tax");
Log3 undef, 5, "TibberDaten: TodayTotal : $today_total";
fhem("setreading myTibber TomorrowTotal $tomorrow_total");
# fhem("setreading myTibber TomorrowEnergy $tomorrow_energy");
# fhem("setreading myTibber TomorrowTax $tomorrow_tax");
Log3 undef, 5, "TibberDaten: TomorrowTotal : $tomorrow_total";
}
sub MinTibberZeitfenster
{
#######################################################################################################################
# Aus dem Array mit den Strompreisen des definierten Zeitfenster wird der Zeitraum mit dem niedrigsten Preis ermittelt
# Parameter1: Preisarray
# Parameter2: Laufzeit in Stunden
# Return: Der StartIndex innerhalb der übergebenen Strompreise
# Nutzung in MyTibber
#######################################################################################################################
my ($Strompreise, $Laufzeit) = @_;
my $anz = @{$Strompreise};
my @PreisIntervall;
# Log3 undef, 5, "MinTibberZeitfenster: Strompreise=@{$Strompreise} Laufzeit=$Laufzeit Anzahl Strompreise = $anz";
for (my $i = 0; $i < ($anz - $Laufzeit +1); $i++)
{
@PreisIntervall[$i] = sum @{$Strompreise}[$i..$i+$Laufzeit-1];
Log3 undef, 5, "Preisintervall Summe: $PreisIntervall[$i]";
}
my $MinPreis = "";
$MinPreis = min @PreisIntervall;
my $MinIndex = "";
$MinIndex = first_index { $_ eq $MinPreis } @PreisIntervall;
Log3 undef, 5, "MinTibberZeitfenster: $MinPreis MinIndex = $MinIndex";
fhem("setreading myTibber MinTibberStartMinPreis $MinPreis");
fhem("setreading myTibber MinTibberStartMinIndex $MinIndex");
return $MinIndex;
}
sub MinStromTime($$$)
{
#######################################################################################################################
# Günstigsten Strompreis für eine Dauer von X Minuten finden
# Parameter:
# MinHour: FrühesterStart (Beispiel: 15 für 15:00 Uhr),
# Laufzeit: Laufzeit in Stunden, (Da es nur Stundenpreise gibt, kann die Laufzeit immer auf Stunden aufgerundet werden)
# Laufzeit_Ende: Anzahl Stunden nach frühestem Start (Beispiel: 12 für 12 Stunden nach frühester Start).
# Der Wert gibt dann quasi das Ende der Laufzeit an
# Es wird immer die Startzeit für den aktuellen Tag angenommen und wenn die aktuelle Zeit nach dem frühesten Start liegt,
# wird die früheste Startzeit auf die aktuelle Zeit zzgl. 2 Minuten gesetzt
# Die Funktion ermittelt dann die Uhrzeit, in der der günstigste Strom für die Dauer von Laufzeit zu erwarten ist
#
# Beispiel: MinStromTime(15, 3, 24) -> Ermittelt den günstigsten Strom für 3 Stunden Laufzeit,
# der am gleichen Tag nach 15:00 Uhr liegt und im Zeitfenster bis 15:00 + 24 Stunden - also am nächsten Tag um 15:00 Uhr liegt
#
#######################################################################################################################
my ($MinHour,$Laufzeit,$LaufzeitEnde) = @_;
my @PreiseHeute = split /\|/, ReadingsVal("myTibber","TodayTotal",0.25);
my @PreiseMorgen = split /\|/, ReadingsVal("myTibber","TomorrowTotal",0.25);
my @AllePreise = (@PreiseHeute, @PreiseMorgen);
my ($tmp, $m, $h, $tmp, $tmp, $tmp, $tmp, $tmp, $tmp) = localtime(time);
my $MinZeit = "";
Log3 undef, 5, "MindestStromPreis: Aktuelle Zeit: $h:$m StartzeitbislangMinzeit: $MinZeit 1";
Log3 undef, 5, "MindestStromPreis: Aktuelle Zeit: $h:$m StartzeitbislangMinhour:$MinHour 2";
$h = $h >= $MinHour ? $h : $MinHour; # Falls die Mindestzeit vor der akt. Zeit liegt Mindestzeit auf akt. Zeit setzen
my $LaufzeitIndex = ($MinHour + $LaufzeitEnde) <= 48 ? $MinHour + $LaufzeitEnde - 1 : 47;
Log3 undef, 5, "MindestStromPreis: Aktuelle Zeit:$h:$m Startzeitbislang1: $MinHour";
@AllePreise = @AllePreise[$h..$LaufzeitIndex];
my $MinZeitIndex = MinTibberZeitfenster(\@AllePreise, $Laufzeit);
Log3 undef, 1, "MindestStromPreis: MinZeitIndex $MinZeitIndex";
Log3 undef, 1, "MindestStromPreis: Aktuelle Zeit:$h:$m Startzeitbislang2: $MinZeit";
fhem("setreading myTibber MinTibberStartZeitfenster $MinZeit"); #####xxxxxxxx $MinZeit zuletzt einmal eingefügt
fhem("setreading myTibber MinTibberStartMinIndex $MinZeitIndex");
if($MinZeitIndex + $h > 24) # Uhrzeit ist am nächsten Tag
{
$MinZeit = sprintf("%02d", $MinZeitIndex + $h - 24).":00";
fhem("setreading myTibber MinTibberStartZeitfenster $MinZeit"); #hier feht Datum ect
Log3 undef, 5, "MindestStromPreis: MinTibberStartZeitfenster $MinZeit";
Log3 undef, 5, "MindestStromPreis: MinZeitIndexjetzt (Tomorrow) $MinZeitIndex Aktuelle Zeit:$h:$m Startzeit:$MinZeit";
}
else
{
$m = $MinZeitIndex == 0 ? $m + 2 : 0; # Uhrzeit entspricht Aufrufzeit, daher 2 Minuten aufschlagen
$MinZeit = sprintf("%02d", $MinZeitIndex + $h).":".sprintf("%02d", $m);
fhem("setreading myTibber MinTibberStartZeitfenster $MinZeit"); #hier feht Datum ect
Log3 undef, 5, "MindestStromPreis: MinTibberStartZeitfenster $MinZeit";
Log3 undef, 5, "MindestStromPreis: MinZeitIndexjetzt (Today) $MinZeitIndex Aktuelle Zeit:$h:$m Startzeit:$MinZeit";
}
Log3 undef, 5, "MindestStromPreis: Aktuelle BeginnZeit:$h:$m Startzeit:$MinZeit";
return $MinZeit;
}
1;
Es soll nur als eine Anregung dienen - nicht als Paradebeispiel ::)
Weil ->> Keine Datenbank notwendig - geringe (nur aktuelle) Datenvorhaltung für die Preise Today und die von Tommorrow.
Nicht auf schön oder ordentlich geschrieben weil alles erst im werden ist -aber insgesamt funktioniert es erst einmal (bei mir), ob woanders auch keine Ahnung ???
(Kann auch sein das ich woanders (innerhalb von FHEM) noch was zusätzlich dabei nutze was hier nicht mit dabei ist)
Gruß
300P
Zitat von: DS_Starter am 13 März 2024, 10:51:37ZitatDie Steckdose eines Luftentfeuchters soll bei genügend PV-Überschuss UND Luftfeuchtigkeit größer 65% eingeschaltet und bei zu wenig Überschuss ABgeschaltet werden.
Da dieses Verfahren zw. 07-22 laufen soll, bietet sich an zunächst die Schlüssel power=0 und mintime=900 zu setzen. Für die Einplanung wäre evtl. auch mode=must sinnvoll.
Dann die Schlüssel spignorecond, swoncond löschen und dafür interruptable einsetzen:
interruptable=ESPEasy_ESP_Easy1_am2302_sensor:humidity:100|6[7-9]|[7-9][0-9]
Der Regex sollte soweit passen. Kann man sicher noch verbessern, habe mir jetzt aber auf die Schnelle nicht näher angeschaut, nur getestet auf https://regex101.com.
Die Seite bietet sich an um seine Regex zu testen und zu optimieren.
LG
Hm, wodurch würde der Verbraucher außerhalb seiner Planungsphase bei zu wenig PV Überschuss eingeschaltet, wenn spignorecond fehlt?
ZitatHm, wodurch würde der Verbraucher außerhalb seiner Planungsphase bei zu wenig PV Überschuss eingeschaltet, wenn spignorecond fehlt?
Außerhalb nicht.
Wenn du den Lüfter im Prinzip rund um die Uhr planen willst, dann lösche die Schlüssel notbefore, notafter und setze dann mintime=1430, mode=must.
Aber ich habe natürlich übersehen die 95% (vs. 97%) -> daraus folgt:
interruptable=ESPEasy_ESP_Easy1_am2302_sensor:humidity:100|6[5-9]|[5-9][0-9]
Du hast recht mit spignorecond :) und setzt dann doch:
power=300
spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:100|6[7-9]|[7-9][0-9]
Der Verbraucher würde dann mit einer kleinen Unterbrechung 24h lang eingeplant, aber nur laufen wenn PV Überschuß.
Um zu analysieren, kannst du die ctrlDebug=consumerPlanning,consumerSwitching setzen.
Das macht es einfacher.
LG
Ich habe mich die letzten Tage mit dem Modul auseinandergesetzt mit viel Fleiß konfiguriert und verstehe noch nicht alles.
Über die sonnenscheinreiche Zeit möchte ich mein Wasserbett als Energiespeicher und zur Eigenverbrauchsoptimierung nutzen.
Die Heizung des Wasserbetts soll Nachts ausgeschaltet und tagsüber auf jeden Fall eingeschaltet werden. Das aber zur zu erwartenden ertragreichsten Zeit und auch ohne Überschuss!
Hiermit habe ich es nicht hinbekommen. Der Verbraucher wird immer nur dann eingeplant wenn ich auf das Uhrensymbol klicke. Das verstehe ich nicht!
HM_ES_PMSw1_Pl_PEQ0411718 type=heater power=200 mode=must on="on" off="off" pcurr=2.POWER interruptable=1 mintime=SunPath icon=scene_sleeping_alternat notbefore=9 auto=Automatiksteuerung spignorecond=deCONZ_Multi_Schlafzimmer_T:water_temp:low etotal:2.ENERGY_COUNTER:Wh
Wofür braucht man das Uhrensymbol?
Wie muss ich consumer01 konfigurieren?
Ich benötige jetzt dringend eine funktionierende Konfiguration weil es mittlerweile verdammt kalt im Bett wird :'(
Beste Grüße
Reiner
Hallo Reiner,
ZitatIch benötige jetzt dringend eine funktionierende Konfiguration weil es mittlerweile verdammt kalt im Bett wird :'(
Das ist natürlich eine Motivation :)
ZitatWofür braucht man das Uhrensymbol?
Falls man per "Klick" einen Verbraucher z.B. über ein Wandtablet manuell sofort einplanen möchte.
Mit einem Mouse-Over gibt es ein paar wesentliche Informationen.
ZitatDie Heizung des Wasserbetts soll Nachts ausgeschaltet und tagsüber auf jeden Fall eingeschaltet werden. Das aber zur zu erwartenden ertragreichsten Zeit und auch ohne Überschuss!
In dem Fall das interruptable=1 löschen und power=0 setzen. Mit power=0 brauchst du spignorecond nicht weil ein PV-Überschuß generell nicht beachtet werden soll.
Damit sollte die Einplanung gelingen, das entsprechende Planungsreading gesetzt werden. Die Schaltung des Verbauchers wird dann wie eingeplant vorgenommen ohne einen PV Überschuß zu der gegebenen Zeit zu erwarten.
Falls es nicht klappt das Attr ctrlDebug=consumerPlanning,consumerSwitching zur Auswertung setzen. Dann sieht man was ggf. noch nicht funktioniert.
LG,
Heiko
Irgendwie kommt es mir so vor das es Frühling wird.
Ein relativ hohes Aufkommen an neuen Stimmen hier rund um das Thema.
Es wird festgestellt das so eine PV-Anlage bzw. die Produktion und der Verbrauch optimiert werden will.
Vermutlich werden viele aus dem jahre 2022/23 beobachtet haben und festgestellt haben: "Da kann ich mehr nutzen raus ziehen".
Finde ich Gut!
Ich persönlich nutze das Modul eigentlich nur in seiner Kernfunktion. Das Modul gibt mir die möglichkeit etwas einzuplannen bzw. diverse Verfügbarkeiten zu progontizieren.
Sozusagen das Modul gibt mir prognostizierte Füllstandsanzeigen. Und nur die schnöden alten Analogen, nix mit Schaltausgang etc.
Wie voll ist mein Sonnenlichttank heute abend = wieviel pv ertrag ist zu erwarten.
Wie leer ist mein stromtank morgen früh zu sonnen aufgang/untergang/zu mitternacht. = was werde ich vermutlich verbraucht haben bis dahin.
Die funktionen was ich wie wo einschalte mache ich über doif's, notifies, events.
Das mache ich hauptsächlich aus 2 Gründen.
1. So Funktionen wie spignorecon etc. gibt es nur hier. Eventuell brauch ich sowas aber woanders und muss mir das dann selbst erfinden. Es kostet mich Zeit mich in den gesamten Funktionsumfang reinzuarbeiten. Da kann ich auch Zeit investieren und mir das gesamte Konstrukt anzueignen. Das hat auch den Vorteil eventuell was an/in dem Modul zuverstehen wenn man sich den code mal anguckt.
2. Es können Funktionen auf einmal wegfallen oder nicht mehr funtionieren weil umgebaut/modernisiert wurde. Und nur der Ersteller entscheidet was drin bleibt und was raus fliegt. Muß nicht kann aber immer möglich sein.
Also baue ich mir so etwas selber, hat für mich den Vorteil das ich mich mit der Umgebung/Sprache auseinandersetzen muß. Zusammenhänge besser verstehe. Möglichkeiten einschätzen kann.
Das ermöglicht mir ein schnelleres adoptieren von Funktionen für andere Zwecke. Alles in allem wird man schneller mit der Zeit und hat mehr Verständniss.
Ich bin völlig frei mit dem wie/was/wo/warum ich das mache..denn ich setze die Parameter und Rahmenbedingungen. Ich kann schnell sachen umstricken wie ich diese brauche und denke das es sinnvoll ist. Ic muß zugeben das nicht alle Probleme die auf mich zukommen in dem prozess schnell abgearbeitet sind. Manche Hartenuss hat mich ganz schön Zeitgekostet. Der Weg ist das Ziel!
Ich möchte hier nicht bashen das diese Funktionen in dem Modul quatsch sind.
Aber das Modul ist so aufgebläht mit all seinen Funktionen das man da sicher auch 2-3 Module hätte draus machen können.
Hut ab für die Fleissarbeit zur Modulerstellung hier.
Und @DS_Starter, so wirklich selbsterklärend ist es jetzt auch nicht mehr mit der ganzen Konfiguration der Verbraucher & Bedingungen.
War früher einfacher jetzt sind die Möglichkeiten schon recht komplex geworden was ich immer so mitlese. Bin ja nicht erst seit gestern hier.
Das Modul funktioniert bei mir wirklich sehr gut (ausgenommen der ForcastSolarAPI, die will nicht so bei mir) was die Prognosen etc, angeht. Will ich garnicht mehr missen.
ZitatUnd @DS_Starter, so wirklich selbsterklärend ist es jetzt auch nicht mehr mit der ganzen Konfiguration der Verbraucher & Bedingungen.
Kein Thema, genau aus diese Grund habe ich schon lange versprochen im Wiki mehr dazu zu schreiben.
Nur habe ich leider auch nur zwei Hande und immer zu wenig Zeit. ;)
Zitat von: kask am 13 März 2024, 22:14:43spignorecon
Moin,
was ist denn das?
VG Christian
spignorecond
Bedingung um einen fehlenden PV Überschuß zu ignorieren (optional). Bei erfüllter Bedingung wird der Verbraucher entsprechend
der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuß vorliegt.
ACHTUNG: Die Verwendung beider Schlüssel spignorecond und interruptable kann zu einem unerwünschten Verhalten führen!
Device - Device zur Lieferung der Bedingung
Reading - Reading welches die Bedingung enthält
Regex - regulärer Ausdruck der für eine 'wahre' Bedingung erfüllt sein muß
Mit dieser Konfig:
HM_ES_PMSw1_Pl_PEQ0411718 type=heater power=0 mode=must on="on" off="off" pcurr=2.POWER mintime=SunPath icon=scene_sleeping_alternat notbefore=9 notafer= 18 auto=Automatiksteuerung etotal:2.ENERGY_COUNTER:Wh
Wird um 11:20 wird die Heizung immer noch nicht eingeschaltet. Trotz Überschuss welcher gar nicht gefordert ist.
Screenshot 2024-03-14 111951.png
Der Geschirrspüler wird auch nicht eingeschaltet
di_remote_dishwasher type=dishwasher icon=scene_dishwasher power=1500 mode=must auto=Automatiksteuerung notbefore=10 notafter=17 on="washer on" off="washer off" swstate=state:on:off interruptable=0Erst wenn ich auf das Uhrensymbol klicke geht es los!?
Ich verstehe das System nicht!
Hier die letzten Log-Einträge...
2024.03.14 11:28:03.161 1: SolarForecast DEBUG> ############### consumer "01" ###############
2024.03.14 11:28:03.161 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: 615 W, nompower: 0, surplus: 0 W, planstate: suspended:, starttime: undef
2024.03.14 11:28:03.161 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.03.14 11:28:03.161 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:28:03.161 1: SolarForecast DEBUG> consumer "01" - device >HM_ES_PMSw1_Pl_PEQ0411718< is used as switching device
2024.03.14 11:28:03.161 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:28:03.161 1: SolarForecast DEBUG> consumer "01" - current planning state: suspended
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> ############### consumer "02" ###############
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "02" - general switching parameters => auto mode: 1, current Consumption: 615 W, nompower: 45, surplus: 0 W, planstate: suspended:, starttime: undef
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "02" - isInLocktime: 0
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "02" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "02" - device >HMIP_PSM_Kuehlschrank_2< is used as switching device
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "02" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "02" - current planning state: suspended
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> ############### consumer "03" ###############
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "03" - general switching parameters => auto mode: 1, current Consumption: 615 W, nompower: 0, surplus: 0 W, planstate: suspended:, starttime: undef
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "03" - isInLocktime: 0
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "03" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "03" - device >deCONZ_zigbee_Osr_5< is used as switching device
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "03" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "03" - current planning state: suspended
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> ############### consumer "04" ###############
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, current Consumption: 615 W, nompower: 30, surplus: 0 W, planstate: suspended:, starttime: undef
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "04" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "04" - device >HM_ES_PMSw1_Pl_PEQ0411666< is used as switching device
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "04" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:28:03.162 1: SolarForecast DEBUG> consumer "04" - current planning state: suspended
2024.03.14 11:28:03.163 1: SolarForecast DEBUG> ############### consumer "05" ###############
2024.03.14 11:28:03.163 1: SolarForecast DEBUG> consumer "05" - general switching parameters => auto mode: 0, current Consumption: 615 W, nompower: 1500, surplus: 0 W, planstate: suspended:, starttime: 14.03.2024 07:38:39
2024.03.14 11:28:03.163 1: SolarForecast DEBUG> consumer "05" - isInLocktime: 0
2024.03.14 11:28:03.163 1: SolarForecast DEBUG> consumer "05" - current Context is >switch on< => swoncond: 1, on-command: washer on
2024.03.14 11:28:03.163 1: SolarForecast DEBUG> consumer "05" - device >di_remote_dishwasher< is used as switching device
2024.03.14 11:28:03.163 1: SolarForecast DEBUG> consumer "05" - current Context is >switch off< => swoffcond: 0, off-command: washer off
2024.03.14 11:28:03.163 1: SolarForecast DEBUG> consumer "05" - current planning state: suspended
Das gibt wieder eine kalte Nacht im unbeheiztem Wasserbett :-/
Aktuelle Beobachtung:
Nach dem letzten Post habe ich auf das Uhrensymbol für den Getränkekühlschrank geklickt. Da war aktuell Überschuss vorhanden.
Nach dem Klick wurde dieser sofort eingeschaltet.
So ist er konfiguriert:
HMIP_PSM_Kuehlschrank_2 type=other power=45 mode=can pcurr=6.POWER interruptable=1 auto=Automatiksteuerung mintime=SunPath icon=scene_wine_cellar notbefore=8 notafter=20 on="on" off="off" locktime=600 etotal=6.CURRENT_STATUS:Wh
Kurz danach, ohne Klick auf die Wasserbettenheizung würde das Symbol der Uhr Orange und das Wasserbett wurde eingeschaltet.
Da habe ich doch sicher noch an anderer Stelle irgendetwas falsch konfiguriert. Oder?
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> ############### consumer "01" ###############
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: 798 W, nompower: 0, surplus: 0 W, planstate: switched on: 2024-03-14 11:32:53 - 2024-03-14 18:29:00, starttime: 14.03.2024 11:32:53
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "01" - device >HM_ES_PMSw1_Pl_PEQ0411718< is used as switching device
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "01" - current planning state: started
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> ############### consumer "02" ###############
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "02" - general switching parameters => auto mode: 1, current Consumption: 798 W, nompower: 45, surplus: 0 W, planstate: interrupted:, starttime: 14.03.2024 11:32:33
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "02" - isInLocktime: 1, remainLockTime: 360 seconds
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "02" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "02" - device >HMIP_PSM_Kuehlschrank_2< is used as switching device
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "02" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:37:13.180 1: SolarForecast DEBUG> consumer "02" - current planning state: interrupted
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> ############### consumer "03" ###############
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "03" - general switching parameters => auto mode: 1, current Consumption: 798 W, nompower: 0, surplus: 0 W, planstate: suspended:, starttime: undef
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "03" - isInLocktime: 0
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "03" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "03" - device >deCONZ_zigbee_Osr_5< is used as switching device
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "03" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "03" - current planning state: suspended
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> ############### consumer "04" ###############
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, current Consumption: 798 W, nompower: 30, surplus: 0 W, planstate: suspended:, starttime: undef
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "04" - current Context is >switch on< => swoncond: 1, on-command: on
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "04" - device >HM_ES_PMSw1_Pl_PEQ0411666< is used as switching device
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "04" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "04" - current planning state: suspended
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> ############### consumer "05" ###############
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - general switching parameters => auto mode: 0, current Consumption: 798 W, nompower: 1500, surplus: 0 W, planstate: suspended:, starttime: 14.03.2024 07:38:39
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - isInLocktime: 0
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - current Context is >switch on< => swoncond: 1, on-command: washer on
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - device >di_remote_dishwasher< is used as switching device
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - current Context is >switch off< => swoffcond: 0, off-command: washer off
2024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - current planning state: suspended
Der Getränkekühlschrank kann nicht schalten weil das auto ausgeschaltet ist:
024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - general switching parameters => auto mode: 0, current Consumption: 798 W, nompower: 1500, surplus: 0 W, planstate: suspended:, starttime: 14.03.2024 07:38:39
Hier ist das angegebene Reading auto=Automatiksteuerung im Device HMIP_PSM_Kuehlschrank_2 zu prüfen ob es auf "1" steht.
Welches Device ist dein Wasserbett?
Auf jeden Fall ist das Device nicht geplant weil kein Maximum Wert eines Überschusses für den aktuellen Tag gefunden wurde (ist für die Planung relevant).
Poste bitte noch die Ausgabe von "get ... solApiData".
Ist das Attr affectConsForecastInPlanning gesetzt? Wenn ja auf welchen Wert?
LG
ZitatDer Getränkekühlschrank kann nicht schalten weil das auto ausgeschaltet ist:
024.03.14 11:37:13.181 1: SolarForecast DEBUG> consumer "05" - general switching parameters => auto mode: 0, current Consumption: 798 W, nompower: 1500, surplus: 0 W, planstate: suspended:, starttime: 14.03.2024 07:38:39
Am Device SolarForecast wurde es als eingeschaltet angezeigt. Habe jetzt aber draufgeklickt ohne wirklich auf das Reading Automatiksteuerung im Device HMIP_PSM_Kuehlschrank_2 zu achten. Ich behalte es im Auge!
ZitatWelches Device ist dein Wasserbett?
Auf jeden Fall ist das Device nicht geplant weil kein Maximum Wert eines Überschusses für den aktuellen Tag gefunden wurde (ist für die Planung relevant).
consumer01 ist das Wasserbett. Hier die Konfiguration mit den gestrigen Tipps von dir. Das Wasserbett soll prinzipiell tagsüber, im speziellen genau dann wenn der Sonnenstrom am höchsten zu erwarten ist, eingeschaltet sein.
HM_ES_PMSw1_Pl_PEQ0411718 type=heater power=0 mode=must on="on" off="off" pcurr=2.POWER mintime=SunPath icon=scene_sleeping_alternat notbefore=9 notafer= 18 auto=Automatiksteuerung etotal:2.ENERGY_COUNTER:WhZitatPoste bitte noch die Ausgabe von "get ... solApiData".
?All => 2024-03-14 00:00:00 => Rad1h: 0.00
2024-03-14 01:00:00 => Rad1h: 0.00
2024-03-14 02:00:00 => Rad1h: 0.00
2024-03-14 03:00:00 => Rad1h: 0.00
2024-03-14 04:00:00 => Rad1h: 0.00
2024-03-14 05:00:00 => Rad1h: 0.00
2024-03-14 06:00:00 => Rad1h: 0.00
2024-03-14 07:00:00 => Rad1h: 0.00
2024-03-14 08:00:00 => Rad1h: 0.00
2024-03-14 09:00:00 => Rad1h: 0.00
2024-03-14 10:00:00 => Rad1h: 0.00
2024-03-14 11:00:00 => Rad1h: 0.00
2024-03-14 12:00:00 => Rad1h: 0.00
2024-03-14 13:00:00 => Rad1h: 0.00
2024-03-14 14:00:00 => Rad1h: 0.00
2024-03-14 15:00:00 => Rad1h: 0.00
2024-03-14 16:00:00 => Rad1h: 0.00
2024-03-14 17:00:00 => Rad1h: 0.00
2024-03-14 18:00:00 => Rad1h: 0.00
2024-03-14 19:00:00 => Rad1h: 0.00
2024-03-14 20:00:00 => Rad1h: 0.00
2024-03-14 21:00:00 => Rad1h: 0.00
2024-03-14 22:00:00 => Rad1h: 0.00
2024-03-14 23:00:00 => Rad1h: 0.00
2024-03-15 00:00:00 => Rad1h: 0.00
2024-03-15 01:00:00 => Rad1h: 0.00
2024-03-15 02:00:00 => Rad1h: 0.00
2024-03-15 03:00:00 => Rad1h: 0.00
2024-03-15 04:00:00 => Rad1h: 0.00
2024-03-15 05:00:00 => Rad1h: 0.00
2024-03-15 06:00:00 => Rad1h: 0.00
2024-03-15 07:00:00 => Rad1h: 0.00
2024-03-15 08:00:00 => Rad1h: 0.00
2024-03-15 09:00:00 => Rad1h: 0.00
2024-03-15 10:00:00 => Rad1h: 0.00
2024-03-15 11:00:00 => Rad1h: 0.00
2024-03-15 12:00:00 => Rad1h: 0.00
2024-03-15 13:00:00 => Rad1h: 0.00
2024-03-15 14:00:00 => Rad1h: 0.00
2024-03-15 15:00:00 => Rad1h: 0.00
2024-03-15 16:00:00 => Rad1h: 0.00
2024-03-15 17:00:00 => Rad1h: 0.00
2024-03-15 18:00:00 => Rad1h: 0.00
2024-03-15 19:00:00 => Rad1h: 0.00
2024-03-15 20:00:00 => Rad1h: 0.00
2024-03-15 21:00:00 => Rad1h: 0.00
2024-03-15 22:00:00 => Rad1h: 0.00
2024-03-15 23:00:00 => Rad1h: 0.00
?All => currentAPIinterval: 900
lastretrieval_time: 2024-03-14 12:43:23
lastretrieval_timestamp: 1710416603
requests_limit: 12
requests_limit_period: 3600
requests_remaining: 2
response_code: 0
response_message: success
retryat_time: 2024-03-10 11:54:01
retryat_timestamp: 1710068041
todayDoneAPIrequests: 4615
Balkon => 2024-03-14 00:00:00 => pv_estimate50: 0.0
2024-03-14 01:00:00 => pv_estimate50: 0.0
2024-03-14 02:00:00 => pv_estimate50: 0.0
2024-03-14 03:00:00 => pv_estimate50: 0.0
2024-03-14 04:00:00 => pv_estimate50: 0.0
2024-03-14 05:00:00 => pv_estimate50: 0.0
2024-03-14 06:00:00 => pv_estimate50: 0.0
2024-03-14 07:00:00 => pv_estimate50: 0.0
2024-03-14 08:00:00 => pv_estimate50: 0.0
2024-03-14 09:00:00 => pv_estimate50: 0.0
2024-03-14 10:00:00 => pv_estimate50: 0.0
2024-03-14 11:00:00 => pv_estimate50: 0.0
2024-03-14 12:00:00 => pv_estimate50: 0.0
2024-03-14 13:00:00 => pv_estimate50: 0.0
2024-03-14 14:00:00 => pv_estimate50: 0.0
2024-03-14 15:00:00 => pv_estimate50: 0.0
2024-03-14 16:00:00 => pv_estimate50: 0.0
2024-03-14 17:00:00 => pv_estimate50: 0.0
2024-03-14 18:00:00 => pv_estimate50: 0.0
2024-03-14 19:00:00 => pv_estimate50: 0.0
2024-03-14 20:00:00 => pv_estimate50: 0.0
2024-03-14 21:00:00 => pv_estimate50: 0.0
2024-03-14 22:00:00 => pv_estimate50: 0.0
2024-03-14 23:00:00 => pv_estimate50: 0.0
2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 06:00:00 => pv_estimate50: 0.0
2024-03-15 07:00:00 => pv_estimate50: 0.0
2024-03-15 08:00:00 => pv_estimate50: 0.0
2024-03-15 09:00:00 => pv_estimate50: 0.0
2024-03-15 10:00:00 => pv_estimate50: 0.0
2024-03-15 11:00:00 => pv_estimate50: 0.0
2024-03-15 12:00:00 => pv_estimate50: 0.0
2024-03-15 13:00:00 => pv_estimate50: 0.0
2024-03-15 14:00:00 => pv_estimate50: 0.0
2024-03-15 15:00:00 => pv_estimate50: 0.0
2024-03-15 16:00:00 => pv_estimate50: 0.0
2024-03-15 17:00:00 => pv_estimate50: 0.0
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
Garage => 2024-03-14 00:00:00 => pv_estimate50: 0.0
2024-03-14 01:00:00 => pv_estimate50: 0.0
2024-03-14 02:00:00 => pv_estimate50: 0.0
2024-03-14 03:00:00 => pv_estimate50: 0.0
2024-03-14 04:00:00 => pv_estimate50: 0.0
2024-03-14 05:00:00 => pv_estimate50: 0.0
2024-03-14 06:00:00 => pv_estimate50: 0.0
2024-03-14 07:00:00 => pv_estimate50: 0.0
2024-03-14 08:00:00 => pv_estimate50: 0.0
2024-03-14 09:00:00 => pv_estimate50: 0.0
2024-03-14 10:00:00 => pv_estimate50: 0.0
2024-03-14 11:00:00 => pv_estimate50: 0.0
2024-03-14 12:00:00 => pv_estimate50: 0.0
2024-03-14 13:00:00 => pv_estimate50: 0.0
2024-03-14 14:00:00 => pv_estimate50: 0.0
2024-03-14 15:00:00 => pv_estimate50: 0.0
2024-03-14 16:00:00 => pv_estimate50: 0.0
2024-03-14 17:00:00 => pv_estimate50: 0.0
2024-03-14 18:00:00 => pv_estimate50: 0.0
2024-03-14 19:00:00 => pv_estimate50: 0.0
2024-03-14 20:00:00 => pv_estimate50: 0.0
2024-03-14 21:00:00 => pv_estimate50: 0.0
2024-03-14 22:00:00 => pv_estimate50: 0.0
2024-03-14 23:00:00 => pv_estimate50: 0.0
2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 06:00:00 => pv_estimate50: 0.0
2024-03-15 07:00:00 => pv_estimate50: 0.0
2024-03-15 08:00:00 => pv_estimate50: 0.0
2024-03-15 09:00:00 => pv_estimate50: 0.0
2024-03-15 10:00:00 => pv_estimate50: 0.0
2024-03-15 11:00:00 => pv_estimate50: 0.0
2024-03-15 12:00:00 => pv_estimate50: 0.0
2024-03-15 13:00:00 => pv_estimate50: 0.0
2024-03-15 14:00:00 => pv_estimate50: 0.0
2024-03-15 15:00:00 => pv_estimate50: 0.0
2024-03-15 16:00:00 => pv_estimate50: 0.0
2024-03-15 17:00:00 => pv_estimate50: 0.0
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
Schaukel => 2024-03-14 00:00:00 => pv_estimate50: 0.0
2024-03-14 01:00:00 => pv_estimate50: 0.0
2024-03-14 02:00:00 => pv_estimate50: 0.0
2024-03-14 03:00:00 => pv_estimate50: 0.0
2024-03-14 04:00:00 => pv_estimate50: 0.0
2024-03-14 05:00:00 => pv_estimate50: 0.0
2024-03-14 06:00:00 => pv_estimate50: 0.0
2024-03-14 07:00:00 => pv_estimate50: 0.0
2024-03-14 08:00:00 => pv_estimate50: 0.0
2024-03-14 09:00:00 => pv_estimate50: 0.0
2024-03-14 10:00:00 => pv_estimate50: 0.0
2024-03-14 11:00:00 => pv_estimate50: 0.0
2024-03-14 12:00:00 => pv_estimate50: 0.0
2024-03-14 13:00:00 => pv_estimate50: 0.0
2024-03-14 14:00:00 => pv_estimate50: 0.0
2024-03-14 15:00:00 => pv_estimate50: 0.0
2024-03-14 16:00:00 => pv_estimate50: 0.0
2024-03-14 17:00:00 => pv_estimate50: 0.0
2024-03-14 18:00:00 => pv_estimate50: 0.0
2024-03-14 19:00:00 => pv_estimate50: 0.0
2024-03-14 20:00:00 => pv_estimate50: 0.0
2024-03-14 21:00:00 => pv_estimate50: 0.0
2024-03-14 22:00:00 => pv_estimate50: 0.0
2024-03-14 23:00:00 => pv_estimate50: 0.0
2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 06:00:00 => pv_estimate50: 0.0
2024-03-15 07:00:00 => pv_estimate50: 0.0
2024-03-15 08:00:00 => pv_estimate50: 0.0
2024-03-15 09:00:00 => pv_estimate50: 0.0
2024-03-15 10:00:00 => pv_estimate50: 0.0
2024-03-15 11:00:00 => pv_estimate50: 0.0
2024-03-15 12:00:00 => pv_estimate50: 0.0
2024-03-15 13:00:00 => pv_estimate50: 0.0
2024-03-15 14:00:00 => pv_estimate50: 0.0
2024-03-15 15:00:00 => pv_estimate50: 0.0
2024-03-15 16:00:00 => pv_estimate50: 0.0
2024-03-15 17:00:00 => pv_estimate50: 0.0
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
ZitatIst das Attr affectConsForecastInPlanning gesetzt? Wenn ja auf welchen Wert?
Nein, es ist nicht gesetzt!
Ich hoffe du kannst etwas finden.
Jeden Fall schon einmal vielen Dank für deine Mühen...
Ja, schau mal es gibt keinerlei Vorhersagewerte.
Das ist natürlich schonmal ganz schlecht.
Nun wäre erst einmal ein Konfigurations Check der Anlage zu machen. Dafür gibt es ein Klick-Icon oder einen set (plantConfiguration) Befehl.
PS: ich habe heute keine Zeit mehr. Vllt. können unsere netten Mitstreiter weiter unterstützen ...
LG
Zitat von: Reinschki am 14 März 2024, 12:46:58Zitatconsumer01 ist das Wasserbett. Hier die Konfiguration mit den gestrigen Tipps von dir. Das Wasserbett soll prinzipiell tagsüber, im speziellen genau dann wenn der Sonnenstrom am höchsten zu erwarten ist, eingeschaltet sein.
HM_ES_PMSw1_Pl_PEQ0411718 type=heater power=0 mode=must on="on" off="off" pcurr=2.POWER mintime=SunPath icon=scene_sleeping_alternat notbefore=9 notafer= 18 auto=Automatiksteuerung etotal:2.ENERGY_COUNTER:Wh
Als erstes solltest du ein Problem nach dem anderen angehen, sonst siehst du den Wald vor lauter Bäumen nicht......
HM_ES_PMSw1_Pl_PEQ0411718 type=heater power=0 mode=must on="on" off="off" pcurr=2.POWER mintime=SunPath icon=scene_sleeping_alternat notbefore=9 notafer= 18 auto=Automatiksteuerung etotal:2.ENERGY_COUNTER:Wh
Bitte zuerst die Parameter so sauber einstellen das es grundsätzlich funktioniert 😉
Also einfach nur automatische Schaltung ,,Ein" und ,,Aus" von 9 bis 18 Uhr für den Consumer nutzen. Danach erst komplexere Dinge hinzufügen.
Hinweis:
Beim Parameter ,,notafer" besteht ein Schreibfehler und muß ,,notafter" heißen, hinter dem Zeichen ,,=,, ist ein ,,blank" zusätzlich.
Schau dir bitte dazu auch nochmals die Beschreibung in der Modul-Hilfe für den Consumer-Befehl und im inzwischen angewachsenen Wiki mit der Poolheizung einmal genau an.
Gehe immer nur kleine Schritte weiter - dann wird es von dir auch hinterher bei komplexen Dingen besser verstanden wenn ein Parameter verändert wird und es dann nicht mehr so ,,richtig" funktioniert.
Mit den fehlenden Daten bei der SolApi kann ich leider gar helfen, ich nutze nur DWD als Datenquelle.
Das Modul ist ,,leider" so komplex, mit den ganzen diversen Möglichkeiten, dass es auch schon erfahreneren Nutzern des Modules schwer fällt sich in komplexe Anliegen einer anderen Installation hineinzuversetzen und dafür sofortige Lösungen vorzuschlagen.
Bitte hab dazu Verständnis.
Gruß
300P
ZitatMit den fehlenden Daten bei der SolApi kann ich leider gar helfen, ich nutze nur DWD als Datenquelle.
Reinschki scheint die DWD zu nutzen. Zumindest sieht es so aus.
Zitat?All => 2024-03-14 00:00:00 => Rad1h: 0.00
2024-03-14 01:00:00 => Rad1h: 0.00
2024-03-14 02:00:00 => Rad1h: 0.00
2024-03-14 03:00:00 => Rad1h: 0.00
2024-03-14 04:00:00 => Rad1h: 0.00 ..
In den anderen APIs fangen die outputs anders an.
Also was sagt die Plantkonfiguration? (Die Zahnräder die neben dem device namen oben links zu finden sind)
Zitat von: kask am 14 März 2024, 20:32:30ZitatMit den fehlenden Daten bei der SolApi kann ich leider gar helfen, ich nutze nur DWD als Datenquelle.
Reinschki scheint die DWD zu nutzen. Zumindest sieht es so aus.
Zitat?All => 2024-03-14 00:00:00 => Rad1h: 0.00
2024-03-14 01:00:00 => Rad1h: 0.00
2024-03-14 02:00:00 => Rad1h: 0.00
2024-03-14 03:00:00 => Rad1h: 0.00
2024-03-14 04:00:00 => Rad1h: 0.00 ..
In den anderen APIs fangen die outputs anders an.
Also was sagt die Plantkonfiguration? (Die Zahnräder die neben dem device namen oben links zu finden sind)
So ist wohl - hab wegen der Namensgebung
Poste bitte noch die Ausgabe von "get ... solApiData".wohl nur allein an die eine Nutzung der SolCast-API gedacht und damit auf dem Irrweg befunden....
Aber dann ist es ja noch besser so :)
Reinschki kann doch einfach das folgende Beispiel-DWD-Device für sich nutzen, damit müsste es klappen! ;)
Nur eine Stations-Nummer muss Reinschki selber einpflegen:
defmod DWD DWD_OpenData
attr DWD DbLogExclude .*
attr DWD downloadTimeout 120
attr DWD forecastDays 2
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
attr DWD forecastRefresh 1
attr DWD forecastResolution 1
attr DWD forecastStation <hier die eigen station in der Nähe einsetzen>
attr DWD forecastWW2Text 1
attr DWD icon rc_WEB
attr DWD room 021_DWD
attr DWD stateFormat Tomorrow Tmax fc1_Tx °C on fc1_date -(state fc_time)
attr DWD verbose 2
PS:
Nutze dazu bitte aber die letzte 55_DWD_OpenData.pm aus dem Contrib von DS_Starter und stelle sicher das die Station die notwendigen Daten auch bereitstellt !
verwirrend ist nur das:
Zitat?All => currentAPIinterval: 900
lastretrieval_time: 2024-03-14 12:43:23
lastretrieval_timestamp: 1710416603
requests_limit: 12
requests_limit_period: 3600
requests_remaining: 2
response_code: 0
response_message: success
retryat_time: 2024-03-10 11:54:01
retryat_timestamp: 1710068041
todayDoneAPIrequests: 4615
Das sieht nach ForecastSolar-API aus.
Deshalb die Plant konfiguration. Oder die definition des Moduls. Auf jeden Fall mehr Infos.
So, habe jetzt das DWD-Dev und das SolarForecast-Dev gelöscht und von vorne angefangen.
Ich denke die Stationen hier um meinen Wohnort liefern keine Strahlungswerte.
Ich verstehe es so, dass man in SolarForecast ein Device DWD_OpenData für das Wetter per Attribut einstellen kann und die ForecastSolar-API per set SolarForecast currentRadiationAPI ForecastSolar-API
liefert dann die Strahlungswerte. Oder?
get SolarForecast solApiDataliefert immer noch nichts brauchbares!?
?All => 2024-03-14 00:00:00 => Rad1h: 0.00
2024-03-14 01:00:00 => Rad1h: 0.00
2024-03-14 02:00:00 => Rad1h: 0.00
2024-03-14 03:00:00 => Rad1h: 0.00
2024-03-14 04:00:00 => Rad1h: 0.00
2024-03-14 05:00:00 => Rad1h: 0.00
2024-03-14 06:00:00 => Rad1h: 0.00
2024-03-14 07:00:00 => Rad1h: 0.00
2024-03-14 08:00:00 => Rad1h: 0.00
2024-03-14 09:00:00 => Rad1h: 0.00
2024-03-14 10:00:00 => Rad1h: 0.00
2024-03-14 11:00:00 => Rad1h: 0.00
2024-03-14 12:00:00 => Rad1h: 0.00
2024-03-14 13:00:00 => Rad1h: 0.00
2024-03-14 14:00:00 => Rad1h: 0.00
2024-03-14 15:00:00 => Rad1h: 0.00
2024-03-14 16:00:00 => Rad1h: 0.00
2024-03-14 17:00:00 => Rad1h: 0.00
2024-03-14 18:00:00 => Rad1h: 0.00
2024-03-14 19:00:00 => Rad1h: 0.00
2024-03-14 20:00:00 => Rad1h: 0.00
2024-03-14 21:00:00 => Rad1h: 0.00
2024-03-14 22:00:00 => Rad1h: 0.00
2024-03-14 23:00:00 => Rad1h: 0.00
2024-03-15 00:00:00 => Rad1h: 0.00
2024-03-15 01:00:00 => Rad1h: 0.00
2024-03-15 02:00:00 => Rad1h: 0.00
2024-03-15 03:00:00 => Rad1h: 0.00
2024-03-15 04:00:00 => Rad1h: 0.00
2024-03-15 05:00:00 => Rad1h: 0.00
2024-03-15 06:00:00 => Rad1h: 0.00
2024-03-15 07:00:00 => Rad1h: 0.00
2024-03-15 08:00:00 => Rad1h: 0.00
2024-03-15 09:00:00 => Rad1h: 0.00
2024-03-15 10:00:00 => Rad1h: 0.00
2024-03-15 11:00:00 => Rad1h: 0.00
2024-03-15 12:00:00 => Rad1h: 0.00
2024-03-15 13:00:00 => Rad1h: 0.00
2024-03-15 14:00:00 => Rad1h: 0.00
2024-03-15 15:00:00 => Rad1h: 0.00
2024-03-15 16:00:00 => Rad1h: 0.00
2024-03-15 17:00:00 => Rad1h: 0.00
2024-03-15 18:00:00 => Rad1h: 0.00
2024-03-15 19:00:00 => Rad1h: 0.00
2024-03-15 20:00:00 => Rad1h: 0.00
2024-03-15 21:00:00 => Rad1h: 0.00
2024-03-15 22:00:00 => Rad1h: 0.00
2024-03-15 23:00:00 => Rad1h: 0.00
?All => currentAPIinterval: 900
lastretrieval_time: 2024-03-14 19:25:34
lastretrieval_timestamp: 1710440734
place: entfernt, 61194 Assenheim Niddatal, Germany
requests_limit: 12
requests_limit_period: 3600
requests_remaining: 2
response_code: 0
response_message: success
retryat_time: 2024-03-10 11:54:01
retryat_timestamp: 1710068041
todayDoneAPIrequests: 6901
Balkon => 2024-03-14 00:00:00 => pv_estimate50: 0.0
2024-03-14 01:00:00 => pv_estimate50: 0.0
2024-03-14 02:00:00 => pv_estimate50: 0.0
2024-03-14 03:00:00 => pv_estimate50: 0.0
2024-03-14 04:00:00 => pv_estimate50: 0.0
2024-03-14 05:00:00 => pv_estimate50: 0.0
2024-03-14 06:00:00 => pv_estimate50: 0.0
2024-03-14 07:00:00 => pv_estimate50: 0.0
2024-03-14 08:00:00 => pv_estimate50: 0.0
2024-03-14 09:00:00 => pv_estimate50: 0.0
2024-03-14 10:00:00 => pv_estimate50: 0.0
2024-03-14 11:00:00 => pv_estimate50: 0.0
2024-03-14 12:00:00 => pv_estimate50: 0.0
2024-03-14 13:00:00 => pv_estimate50: 0.0
2024-03-14 14:00:00 => pv_estimate50: 0.0
2024-03-14 15:00:00 => pv_estimate50: 0.0
2024-03-14 16:00:00 => pv_estimate50: 0.0
2024-03-14 17:00:00 => pv_estimate50: 0.0
2024-03-14 18:00:00 => pv_estimate50: 0.0
2024-03-14 19:00:00 => pv_estimate50: 0.0
2024-03-14 20:00:00 => pv_estimate50: 0.0
2024-03-14 21:00:00 => pv_estimate50: 0.0
2024-03-14 22:00:00 => pv_estimate50: 0.0
2024-03-14 23:00:00 => pv_estimate50: 0.0
2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 06:00:00 => pv_estimate50: 0.0
2024-03-15 07:00:00 => pv_estimate50: 0.0
2024-03-15 08:00:00 => pv_estimate50: 0.0
2024-03-15 09:00:00 => pv_estimate50: 0.0
2024-03-15 10:00:00 => pv_estimate50: 0.0
2024-03-15 11:00:00 => pv_estimate50: 0.0
2024-03-15 12:00:00 => pv_estimate50: 0.0
2024-03-15 13:00:00 => pv_estimate50: 0.0
2024-03-15 14:00:00 => pv_estimate50: 0.0
2024-03-15 15:00:00 => pv_estimate50: 0.0
2024-03-15 16:00:00 => pv_estimate50: 0.0
2024-03-15 17:00:00 => pv_estimate50: 0.0
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
Garage => 2024-03-14 00:00:00 => pv_estimate50: 0.0
2024-03-14 01:00:00 => pv_estimate50: 0.0
2024-03-14 02:00:00 => pv_estimate50: 0.0
2024-03-14 03:00:00 => pv_estimate50: 0.0
2024-03-14 04:00:00 => pv_estimate50: 0.0
2024-03-14 05:00:00 => pv_estimate50: 0.0
2024-03-14 06:00:00 => pv_estimate50: 0.0
2024-03-14 07:00:00 => pv_estimate50: 0.0
2024-03-14 08:00:00 => pv_estimate50: 0.0
2024-03-14 09:00:00 => pv_estimate50: 0.0
2024-03-14 10:00:00 => pv_estimate50: 0.0
2024-03-14 11:00:00 => pv_estimate50: 0.0
2024-03-14 12:00:00 => pv_estimate50: 0.0
2024-03-14 13:00:00 => pv_estimate50: 0.0
2024-03-14 14:00:00 => pv_estimate50: 0.0
2024-03-14 15:00:00 => pv_estimate50: 0.0
2024-03-14 16:00:00 => pv_estimate50: 0.0
2024-03-14 17:00:00 => pv_estimate50: 0.0
2024-03-14 18:00:00 => pv_estimate50: 0.0
2024-03-14 19:00:00 => pv_estimate50: 0.0
2024-03-14 20:00:00 => pv_estimate50: 0.0
2024-03-14 21:00:00 => pv_estimate50: 0.0
2024-03-14 22:00:00 => pv_estimate50: 0.0
2024-03-14 23:00:00 => pv_estimate50: 0.0
2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 06:00:00 => pv_estimate50: 0.0
2024-03-15 07:00:00 => pv_estimate50: 0.0
2024-03-15 08:00:00 => pv_estimate50: 0.0
2024-03-15 09:00:00 => pv_estimate50: 0.0
2024-03-15 10:00:00 => pv_estimate50: 0.0
2024-03-15 11:00:00 => pv_estimate50: 0.0
2024-03-15 12:00:00 => pv_estimate50: 0.0
2024-03-15 13:00:00 => pv_estimate50: 0.0
2024-03-15 14:00:00 => pv_estimate50: 0.0
2024-03-15 15:00:00 => pv_estimate50: 0.0
2024-03-15 16:00:00 => pv_estimate50: 0.0
2024-03-15 17:00:00 => pv_estimate50: 0.0
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
Schaukel => 2024-03-14 00:00:00 => pv_estimate50: 0.0
2024-03-14 01:00:00 => pv_estimate50: 0.0
2024-03-14 02:00:00 => pv_estimate50: 0.0
2024-03-14 03:00:00 => pv_estimate50: 0.0
2024-03-14 04:00:00 => pv_estimate50: 0.0
2024-03-14 05:00:00 => pv_estimate50: 0.0
2024-03-14 06:00:00 => pv_estimate50: 0.0
2024-03-14 07:00:00 => pv_estimate50: 0.0
2024-03-14 08:00:00 => pv_estimate50: 0.0
2024-03-14 09:00:00 => pv_estimate50: 0.0
2024-03-14 10:00:00 => pv_estimate50: 0.0
2024-03-14 11:00:00 => pv_estimate50: 0.0
2024-03-14 12:00:00 => pv_estimate50: 0.0
2024-03-14 13:00:00 => pv_estimate50: 0.0
2024-03-14 14:00:00 => pv_estimate50: 0.0
2024-03-14 15:00:00 => pv_estimate50: 0.0
2024-03-14 16:00:00 => pv_estimate50: 0.0
2024-03-14 17:00:00 => pv_estimate50: 0.0
2024-03-14 18:00:00 => pv_estimate50: 0.0
2024-03-14 19:00:00 => pv_estimate50: 0.0
2024-03-14 20:00:00 => pv_estimate50: 0.0
2024-03-14 21:00:00 => pv_estimate50: 0.0
2024-03-14 22:00:00 => pv_estimate50: 0.0
2024-03-14 23:00:00 => pv_estimate50: 0.0
2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 06:00:00 => pv_estimate50: 0.0
2024-03-15 07:00:00 => pv_estimate50: 0.0
2024-03-15 08:00:00 => pv_estimate50: 0.0
2024-03-15 09:00:00 => pv_estimate50: 0.0
2024-03-15 10:00:00 => pv_estimate50: 0.0
2024-03-15 11:00:00 => pv_estimate50: 0.0
2024-03-15 12:00:00 => pv_estimate50: 0.0
2024-03-15 13:00:00 => pv_estimate50: 0.0
2024-03-15 14:00:00 => pv_estimate50: 0.0
2024-03-15 15:00:00 => pv_estimate50: 0.0
2024-03-15 16:00:00 => pv_estimate50: 0.0
2024-03-15 17:00:00 => pv_estimate50: 0.0
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
Was sagt der Konfigurations check?
Und stutzig macht mich:
Zitatretryat_time: 2024-03-10 11:54:01
Das ist genauso wie im vorherigem Post.
Leg das device doch mal mit einem neuen/anderen Namen an.
Guten Morgen,
danke dass ihr Reiner schon weiter unterstützt habt.
Ja das sieht nach ForecastSolar-API aus.
@kask,
Zitatretryat_time: 2024-03-10 11:54:01
Der Wert ist nur relevant wenn er in der Zukunft liegt. Das ist ein Steuerungselement und ok so.
Für die weitere Vorgehensweise bietet sich an:
1. den Konfigurationscheck durchführen
2. das Attr ctrlDebug=apiCall,apiProcess setzen und ein "get ... rooftopData" auszuführen.
Von den beiden Steps die Ergebnisse bitte posten. Im Fall von rooftopData erscheint im Log in etwa folgendes (Erfolgsfall):
2024.03.15 08:11:29.499 1: SolCast5 DEBUG> ForecastSolar API Call - Request for string "Süddach":
https://api.forecast.solar/estimate/watthours/period/51.285272/12.067722/45/0/5.65
2024.03.15 08:11:29.500 2: HttpUtils url=https://api.forecast.solar/estimate/watthours/period/xxxxx/xxxxx/45/0/5.65 NonBlocking via https
2024.03.15 08:11:29.518 1: IP: api.forecast.solar -> 148.251.178.234
2024.03.15 08:11:29.591 2: HttpUtils request header:
GET /estimate/watthours/period/51.285272/12.067722/45/0/5.65 HTTP/1.0
Host: api.forecast.solar
User-Agent: fhem
Accept-Encoding: gzip,deflate
Accept: application/json
2024.03.15 08:11:29.756 1: https://api.forecast.solar/estimate/watthours/period/51.285272/12.067722/45/0/5.65: HTTP response code 200
2024.03.15 08:11:29.757 2: HttpUtils https://api.forecast.solar/estimate/watthours/period/51.285272/12.067722/45/0/5.65: Got data, length: 1201
2024.03.15 08:11:29.758 2: HttpUtils response header:
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 15 Mar 2024 07:11:29 GMT
Content-Type: application/json; charset=utf-8
Connection: close
X-Version: v7.17.1
X-Build: 1911 (Thu, 14 Mar 2024 13:19:20 +0100)
X-Pid: 4o53Swqy
X-Ratelimit-Zone: IP 91.54.80.133
X-Ratelimit-Period: 3600
X-Ratelimit-Limit: 12
X-Ratelimit-Remaining: 8
X-Process-Time: 122 ms
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: OPTIONS,HEAD,GET,POST
Access-Control-Allow-Headers: Origin,Content-Type,Authorization,X-Requested-With,X-Delimiter,X-Separator
2024.03.15 08:11:29.759 1: SolCast5 DEBUG> ForecastSolar API Call - response for string "Süddach":
{
'message' => {
'text' => '',
'pid' => '4o53Swqy',
'ratelimit' => {
'remaining' => 8,
'period' => 3600,
'zone' => 'IP 91.54.80.133',
'limit' => 12
},
'info' => {
'time' => '2024-03-15T08:11:29+01:00',
'time_utc' => '2024-03-15T07:11:29+00:00',
'place' => "xxxx",
'longitude' => 'xxxxxx',
'latitude' => 'xxxxxx',
'distance' => '0.071',
'timezone' => 'Europe/Berlin'
},
'code' => 0,
'type' => 'success'
},
'result' => {
'2024-03-15 13:00:00' => 1987,
'2024-03-15 16:00:00' => 867,
'2024-03-16 16:00:00' => 1536,
'2024-03-15 18:16:46' => 14,
'2024-03-16 13:00:00' => 2368,
'2024-03-16 14:00:00' => 2519,
'2024-03-15 11:00:00' => 3380,
'2024-03-16 10:00:00' => 2447,
'2024-03-16 15:00:00' => 2247,
'2024-03-15 06:24:14' => 0,
'2024-03-15 15:00:00' => 1266,
'2024-03-15 10:00:00' => 2951,
'2024-03-16 11:00:00' => 2886,
'2024-03-15 14:00:00' => 1533,
'2024-03-16 06:21:59' => 0,
'2024-03-15 17:00:00' => 443,
'2024-03-16 18:00:00' => 342,
'2024-03-16 09:00:00' => 1762,
'2024-03-15 09:00:00' => 1835,
'2024-03-15 18:00:00' => 175,
'2024-03-16 17:00:00' => 797,
'2024-03-16 07:00:00' => 318,
'2024-03-15 08:00:00' => 974,
'2024-03-16 18:18:27' => 34,
'2024-03-16 12:00:00' => 2580,
'2024-03-15 12:00:00' => 2811,
'2024-03-16 08:00:00' => 1248,
'2024-03-15 07:00:00' => 209
}
}
2024.03.15 08:11:29.762 1: SolCast5 DEBUG> ForecastSolar API Call - server response for PV string "Süddach"
2024.03.15 08:11:29.762 1: SolCast5 DEBUG> ForecastSolar API Call - request time: 2024-03-15 08:11:29 (1710486689)
2024.03.15 08:11:29.763 1: SolCast5 DEBUG> ForecastSolar API Call - requests remaining: 8
2024.03.15 08:11:29.763 1: SolCast5 DEBUG> ForecastSolar API Call - status: success (0)
2024.03.15 08:11:29.764 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 05:24:14 => 0 Wh
2024.03.15 08:11:29.764 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 06:00:00 => 209 Wh
2024.03.15 08:11:29.765 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 07:00:00 => 974 Wh
2024.03.15 08:11:29.765 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 08:00:00 => 1835 Wh
2024.03.15 08:11:29.766 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 09:00:00 => 2951 Wh
2024.03.15 08:11:29.767 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 10:00:00 => 3380 Wh
2024.03.15 08:11:29.767 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 11:00:00 => 2811 Wh
2024.03.15 08:11:29.768 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 12:00:00 => 1987 Wh
2024.03.15 08:11:29.769 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 13:00:00 => 1533 Wh
2024.03.15 08:11:29.769 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 14:00:00 => 1266 Wh
2024.03.15 08:11:29.770 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 15:00:00 => 867 Wh
2024.03.15 08:11:29.770 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 16:00:00 => 443 Wh
2024.03.15 08:11:29.771 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 17:00:00 => 175 Wh
2024.03.15 08:11:29.772 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-15 17:16:46 => 14 Wh
2024.03.15 08:11:29.772 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 05:21:59 => 0 Wh
2024.03.15 08:11:29.773 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 06:00:00 => 318 Wh
2024.03.15 08:11:29.774 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 07:00:00 => 1248 Wh
2024.03.15 08:11:29.774 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 08:00:00 => 1762 Wh
2024.03.15 08:11:29.775 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 09:00:00 => 2447 Wh
2024.03.15 08:11:29.776 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 10:00:00 => 2886 Wh
2024.03.15 08:11:29.776 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 11:00:00 => 2580 Wh
2024.03.15 08:11:29.777 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 12:00:00 => 2368 Wh
2024.03.15 08:11:29.777 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 13:00:00 => 2519 Wh
2024.03.15 08:11:29.778 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 14:00:00 => 2247 Wh
2024.03.15 08:11:29.778 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 15:00:00 => 1536 Wh
2024.03.15 08:11:29.779 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 16:00:00 => 797 Wh
2024.03.15 08:11:29.780 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 17:00:00 => 342 Wh
2024.03.15 08:11:29.780 1: SolCast5 DEBUG> ForecastSolar API Call - PV estimate: 2024-03-16 17:18:27 => 34 Wh
@Reiner,
ZitatIch verstehe es so, dass man in SolarForecast ein Device DWD_OpenData für das Wetter per Attribut einstellen kann und die ForecastSolar-API per
Code Auswählen
set SolarForecast currentRadiationAPI ForecastSolar-API
liefert dann die Strahlungswerte. Oder?
Das ist soweit richtig, allerdings liefert die API keine Strahlungswerte sondern eine Erzeugungsprognose. Abgerufen wird automatisch bzw. manuell mit "get ... rooftopData".
Grüße,
Heiko
@Reiner:
Aufgrund deiner Ausführungen gehe ich momentan noch davon aus das du DWD nutzt.
Falls das DWD-Device bei Dir wirklich ,,ForecastSolar-API" heißen sollte
->> das bringt etwas Durcheinander wegen dieses nicht so gut gewählten Namens. ;)
Nimm der besseren Übersicht in der weiteren Diskussion wegen den einfachen Namen ,,DWD" für dieses.
Ansonsten rätseln alle rum wie das überhaupt funktionieren kann / soll. :o
Die Nutzung des angelegten DWD-Device innerhalb von Solarforecast geht auch nur mit dieser Einstellung:
(Bitte dabei alle Randparameter auf das peinlichste beachten)
Bild01
IMG_7690.jpg
Und
Bild02
IMG_7689.jpg
Ansonsten vermischt man verschiedene Vorgänge und es kommt nix dabei rum
Wenn du aber kein DWD-Device benutzt vergesse alles was ich hier geschrieben habe.
Gruß
300P
Also ich habe mich auch gegen die Nutzung der integrierten Verbrauchssteuerung entschieden
1. Weil ich mit doifs meiner Meinugn nach flexibler fahre und ich hier auch in 2 Jahren noch den doif verstehe wenn ich eine weiter Bedingung reinbringen will.
2. Weil bei mir die Schaltflächen "Uhr" und "Schiebeschalter" auf dem Tablet nicht funktionieren.
Somit nutze ich die Grundfunktionen mit denen ich sehr (!!!) happy bin. Danke DS_Starter!
ZitatDer Wert ist nur relevant wenn er in der Zukunft liegt. Das ist ein Steuerungselement und ok so.
Die Zeit bzw. das Datum störte mich nicht, ABER!
Da das Device laut Aussage gelöscht und neu angelegt wurde, die Zeit sich aber nicht geändert hat, gehe ich davon aus das es Restbestände von dem alten Device sind. Zumal der Zähler ja auch stark inkrementiert was.
Also Neues anlegen mit neuem Namen, dann kann man fast auschliessen das da irgendwelche alten Daten wieder einfliessen.
Was ist/war jetzt noch alles vom alten Device fälschlicherweise existent?
Ich steck da nicht so tief drinne. Aber sowas ist immer komisch.
@DS_Starter Eventuell werden nicht alle files gelöscht beim expliziten löschen des Devices in FHEM?
@kask,
ZitatEventuell werden nicht alle files gelöscht beim expliziten löschen des Devices in FHEM?
Die Files werden alle gelöscht. Aber die Laufzeit-Strukturen im RAM bleiben bestehen wenn nach dem Delete und Neuanlegen mit dem gleichen Namen kein Restart von FHEM stattgefunden hat.
Ich überprüfen das und werde in der kommenden Version an dieser Stelle nachbessern.
@Heatseeker,
ZitatWeil bei mir die Schaltflächen "Uhr" und "Schiebeschalter" auf dem Tablet nicht funktionieren.
Hast du eine Idee aus welchem Grund? Denn bei meinen Tablets funktioniert es tadellos.
LG
Hallo Heiko,
nachdem meine DWD-Station keine Rad1h liefert...
will ich fragen, ob du das kennst: DWD ICON API (https://open-meteo.com/en/docs/dwd-api)
Da kann man sich "seine" Panel Parameter konfigurieren und bekommt eine URL mit Parameter (https://api.open-meteo.com/v1/dwd-icon?latitude=48&longitude=16.3&hourly=global_tilted_irradiance&timezone=Europe%2FBerlin&forecast_days=1&forecast_hours=12&tilt=20&azimuth=40)
die folgendes liefert:
{"latitude":48.0,"longitude":16.3,"generationtime_ms":0.031948089599609375,"utc_offset_seconds":3600,"timezone":"Europe/Berlin","timezone_abbreviation":"CET","elevation":204.0,"hourly_units":{"time":"iso8601","global_tilted_irradiance":"W/m²"},"hourly":{"time":["2024-03-15T11:00","2024-03-15T12:00","2024-03-15T13:00","2024-03-15T14:00","2024-03-15T15:00","2024-03-15T16:00","2024-03-15T17:00","2024-03-15T18:00","2024-03-15T19:00","2024-03-15T20:00","2024-03-15T21:00","2024-03-15T22:00"],"global_tilted_irradiance":[441.5,514.2,501.0,431.1,394.2,256.0,164.7,33.4,0.0,0.0,0.0,0.0]}}
.. das schaut für mich sehr kompatibel aus, zu den bisherigen Daten.
Eine Abfragebeschränkung hab ich nicht gefunden!
Das wäre jedenfalls eine Verbesserung ggü Solcast/Forecast-Solar API.
l.g. erwin
Hallo erwin,
nein das kannte ich noch nicht, danke für die Info. :)
Das werde ich mir auf jeden Fall anschauen.
Sieht auf den ersten Blick tatsächlich sehr interessant aus.
Grüße,
Heiko
Dank an alle Ratgebenden!
Heute gibt es Output ohne weiteres zutun bei dieser Abfrage:
get SolarForecast solApiData?All => 2024-03-15 00:00:00 => Rad1h: 0.00
2024-03-15 01:00:00 => Rad1h: 0.00
2024-03-15 02:00:00 => Rad1h: 0.00
2024-03-15 03:00:00 => Rad1h: 0.00
2024-03-15 04:00:00 => Rad1h: 0.00
2024-03-15 05:00:00 => Rad1h: 0.00
2024-03-15 06:00:00 => Rad1h: 0.00
2024-03-15 07:00:00 => Rad1h: 0.00
2024-03-15 08:00:00 => Rad1h: 0.00
2024-03-15 09:00:00 => Rad1h: 0.00
2024-03-15 10:00:00 => Rad1h: 0.00
2024-03-15 11:00:00 => Rad1h: 0.00
2024-03-15 12:00:00 => Rad1h: 0.00
2024-03-15 13:00:00 => Rad1h: 0.00
2024-03-15 14:00:00 => Rad1h: 0.00
2024-03-15 15:00:00 => Rad1h: 0.00
2024-03-15 16:00:00 => Rad1h: 0.00
2024-03-15 17:00:00 => Rad1h: 0.00
2024-03-15 18:00:00 => Rad1h: 0.00
2024-03-15 19:00:00 => Rad1h: 0.00
2024-03-15 20:00:00 => Rad1h: 0.00
2024-03-15 21:00:00 => Rad1h: 0.00
2024-03-15 22:00:00 => Rad1h: 0.00
2024-03-15 23:00:00 => Rad1h: 0.00
?All => currentAPIinterval: 900
lastretrieval_time: 2024-03-15 12:07:55
lastretrieval_timestamp: 1710500875
place: entfernt, 61194 Assenheim Niddatal, Germany
requests_limit: 12
requests_limit_period: 3600
requests_remaining: 0
response_code: 0
response_message: success
retryat_time: 2024-03-15 10:37:35
retryat_timestamp: 1710495455
todayDoneAPIcalls: 25.6666666666667
todayDoneAPIrequests: 77
Balkon => 2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 05:37:02 => pv_estimate50: 0
2024-03-15 06:00:00 => pv_estimate50: 11
2024-03-15 07:00:00 => pv_estimate50: 67
2024-03-15 08:00:00 => pv_estimate50: 82
2024-03-15 09:00:00 => pv_estimate50: 90
2024-03-15 10:00:00 => pv_estimate50: 100
2024-03-15 11:00:00 => pv_estimate50: 112
2024-03-15 12:00:00 => pv_estimate50: 103
2024-03-15 13:00:00 => pv_estimate50: 91
2024-03-15 14:00:00 => pv_estimate50: 87
2024-03-15 15:00:00 => pv_estimate50: 71
2024-03-15 16:00:00 => pv_estimate50: 42
2024-03-15 17:00:00 => pv_estimate50: 19
2024-03-15 17:30:00 => pv_estimate50: 3
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
2024-03-16 05:34:50 => pv_estimate50: 0
2024-03-16 06:00:00 => pv_estimate50: 14
2024-03-16 07:00:00 => pv_estimate50: 84
2024-03-16 08:00:00 => pv_estimate50: 114
2024-03-16 09:00:00 => pv_estimate50: 139
2024-03-16 10:00:00 => pv_estimate50: 173
2024-03-16 11:00:00 => pv_estimate50: 214
2024-03-16 12:00:00 => pv_estimate50: 227
2024-03-16 13:00:00 => pv_estimate50: 188
2024-03-16 14:00:00 => pv_estimate50: 138
2024-03-16 15:00:00 => pv_estimate50: 102
2024-03-16 16:00:00 => pv_estimate50: 65
2024-03-16 17:00:00 => pv_estimate50: 31
2024-03-16 17:31:37 => pv_estimate50: 5
Garage => 2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 05:37:02 => pv_estimate50: 0
2024-03-15 06:00:00 => pv_estimate50: 7
2024-03-15 07:00:00 => pv_estimate50: 42
2024-03-15 08:00:00 => pv_estimate50: 51
2024-03-15 09:00:00 => pv_estimate50: 56
2024-03-15 10:00:00 => pv_estimate50: 62
2024-03-15 11:00:00 => pv_estimate50: 69
2024-03-15 12:00:00 => pv_estimate50: 64
2024-03-15 13:00:00 => pv_estimate50: 56
2024-03-15 14:00:00 => pv_estimate50: 54
2024-03-15 15:00:00 => pv_estimate50: 44
2024-03-15 16:00:00 => pv_estimate50: 26
2024-03-15 17:00:00 => pv_estimate50: 12
2024-03-15 17:30:00 => pv_estimate50: 2
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
2024-03-16 05:34:50 => pv_estimate50: 0
2024-03-16 06:00:00 => pv_estimate50: 8
2024-03-16 07:00:00 => pv_estimate50: 52
2024-03-16 08:00:00 => pv_estimate50: 71
2024-03-16 09:00:00 => pv_estimate50: 86
2024-03-16 10:00:00 => pv_estimate50: 107
2024-03-16 11:00:00 => pv_estimate50: 133
2024-03-16 12:00:00 => pv_estimate50: 141
2024-03-16 13:00:00 => pv_estimate50: 116
2024-03-16 14:00:00 => pv_estimate50: 85
2024-03-16 15:00:00 => pv_estimate50: 63
2024-03-16 16:00:00 => pv_estimate50: 40
2024-03-16 17:00:00 => pv_estimate50: 19
2024-03-16 17:31:37 => pv_estimate50: 3
Schaukel => 2024-03-15 00:00:00 => pv_estimate50: 0.0
2024-03-15 01:00:00 => pv_estimate50: 0.0
2024-03-15 02:00:00 => pv_estimate50: 0.0
2024-03-15 03:00:00 => pv_estimate50: 0.0
2024-03-15 04:00:00 => pv_estimate50: 0.0
2024-03-15 05:00:00 => pv_estimate50: 0.0
2024-03-15 05:37:02 => pv_estimate50: 0
2024-03-15 06:00:00 => pv_estimate50: 8
2024-03-15 07:00:00 => pv_estimate50: 50
2024-03-15 08:00:00 => pv_estimate50: 61
2024-03-15 09:00:00 => pv_estimate50: 67
2024-03-15 10:00:00 => pv_estimate50: 75
2024-03-15 11:00:00 => pv_estimate50: 84
2024-03-15 12:00:00 => pv_estimate50: 77
2024-03-15 13:00:00 => pv_estimate50: 68
2024-03-15 14:00:00 => pv_estimate50: 65
2024-03-15 15:00:00 => pv_estimate50: 53
2024-03-15 16:00:00 => pv_estimate50: 31
2024-03-15 17:00:00 => pv_estimate50: 14
2024-03-15 17:30:00 => pv_estimate50: 2
2024-03-15 18:00:00 => pv_estimate50: 0.0
2024-03-15 19:00:00 => pv_estimate50: 0.0
2024-03-15 20:00:00 => pv_estimate50: 0.0
2024-03-15 21:00:00 => pv_estimate50: 0.0
2024-03-15 22:00:00 => pv_estimate50: 0.0
2024-03-15 23:00:00 => pv_estimate50: 0.0
2024-03-16 05:34:50 => pv_estimate50: 0
2024-03-16 06:00:00 => pv_estimate50: 10
2024-03-16 07:00:00 => pv_estimate50: 64
2024-03-16 08:00:00 => pv_estimate50: 86
2024-03-16 09:00:00 => pv_estimate50: 104
2024-03-16 10:00:00 => pv_estimate50: 129
2024-03-16 11:00:00 => pv_estimate50: 161
2024-03-16 12:00:00 => pv_estimate50: 170
2024-03-16 13:00:00 => pv_estimate50: 141
2024-03-16 14:00:00 => pv_estimate50: 103
2024-03-16 15:00:00 => pv_estimate50: 76
2024-03-16 16:00:00 => pv_estimate50: 48
2024-03-16 17:00:00 => pv_estimate50: 23
2024-03-16 17:31:37 => pv_estimate50: 4
Rad1h zeigt immer noch 0.00 an!?
Anlagenkonfigurationsprüfung.jpg
kann irgendwie den Screenshot nicht laden ???
jetzt nach einer 1/2 Stunde klappt es mit dem Screenshot :)
Na das sieht doch schon mal nach Erfolgreicher Grundkonfiguration aus !!! =>> Glückwunsch
@Reiner, das sieht doch schon gut aus. Diese API liefert keine Strahlungsdaten, deswegen ist das irrelevant was in Rad1h steht.
Jetzt könntest du mit der Consumersteuerung beginnen.
Eventuell erstmal einfacher gestalten wie 300P geschrieben hat, oder du definierst die Consumer wie gehabt und wir schauen gemeinsam.
Dann noch der Hinweis auf eine weiterentwickelte DWD_OpenData Version in meinem contrib mit der du eine genauere Wettervorhersage einstellen kannst. Darauf bezieht sich im Check der Hinweis auf "forecastRefresh".
Für die Bestimmung der Dachausrichtung (azimut) kannst du dieses Tool mit deiner Adresse nutzen:
https://www.rechnerphotovoltaik.de/rechner/dachausrichtung (https://www.rechnerphotovoltaik.de/rechner/dachausrichtung)
Guten Morgen,
die Consumersteuerung hat gestern bereits ganz gut funktioniert. Das werde ich heute noch mal genauestens beobachten.
Wie begegnet man diesen Phänomenen?
Screenshot 2024-03-16 081154.pngScreenshot 2024-03-16 081111.png
Ist da vielleicht noch etwas falsch parametrisiert?
Internals:
.FhemMetaInternals 1
.TZ Europe/Berlin
.fetchAlerts 0
.forecastFile /tmp/AmC4s1nwsd
.station L751
FHEM_TZ Europe/Berlin
FUUID 65f46adc-f33f-17d1-ef00-228f6336c2621099
FVERSION 55_DWD_OpenData.pm:v1.0.0-s28556/2024-03-02
NAME DWD_Erbstadt
NR 1040
STATE forecast unchanged
TYPE DWD_OpenData
VERSION 1.017003
eventCount 118
.attraggr:
.attreocr:
.*
.attrminint:
OLDREADINGS:
READINGS:
2024-03-16 06:34:34 fc0_10_Neff 86
2024-03-16 06:34:34 fc0_10_RR1c 0.10
2024-03-16 06:34:34 fc0_10_SunUp 1
2024-03-16 06:34:34 fc0_10_TTT 11.3
2024-03-16 06:34:34 fc0_10_time 10:00
2024-03-16 06:34:34 fc0_10_ww 61
2024-03-16 06:34:34 fc0_10_wwd durchgehend leichter Regen
2024-03-16 06:34:34 fc0_11_Neff 85
2024-03-16 06:34:34 fc0_11_RR1c 0.10
2024-03-16 06:34:34 fc0_11_SunUp 1
2024-03-16 06:34:34 fc0_11_TTT 12
2024-03-16 06:34:34 fc0_11_time 11:00
2024-03-16 06:34:34 fc0_11_ww 61
2024-03-16 06:34:34 fc0_11_wwd durchgehend leichter Regen
2024-03-16 06:34:34 fc0_12_Neff 84
2024-03-16 06:34:34 fc0_12_RR1c 0.10
2024-03-16 06:34:34 fc0_12_SunUp 1
2024-03-16 06:34:34 fc0_12_TTT 12.7
2024-03-16 06:34:34 fc0_12_time 12:00
2024-03-16 06:34:34 fc0_12_ww 61
2024-03-16 06:34:34 fc0_12_wwd durchgehend leichter Regen
2024-03-16 06:34:34 fc0_13_Neff 81
2024-03-16 06:34:34 fc0_13_RR1c 0.10
2024-03-16 06:34:34 fc0_13_SunUp 1
2024-03-16 06:34:34 fc0_13_TTT 12.8
2024-03-16 06:34:34 fc0_13_time 13:00
2024-03-16 06:34:34 fc0_13_ww 80
2024-03-16 06:34:34 fc0_13_wwd leichter Regenschauer
2024-03-16 06:34:34 fc0_14_Neff 76
2024-03-16 06:34:34 fc0_14_RR1c 0.00
2024-03-16 06:34:34 fc0_14_SunUp 1
2024-03-16 06:34:34 fc0_14_TTT 12.8
2024-03-16 06:34:34 fc0_14_time 14:00
2024-03-16 06:34:34 fc0_14_ww 2
2024-03-16 06:34:34 fc0_14_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc0_15_Neff 69
2024-03-16 06:34:34 fc0_15_RR1c 0.00
2024-03-16 06:34:34 fc0_15_SunUp 1
2024-03-16 06:34:34 fc0_15_TTT 12.7
2024-03-16 06:34:34 fc0_15_time 15:00
2024-03-16 06:34:34 fc0_15_ww 2
2024-03-16 06:34:34 fc0_15_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc0_16_Neff 59
2024-03-16 06:34:34 fc0_16_RR1c 0.00
2024-03-16 06:34:34 fc0_16_SunUp 1
2024-03-16 06:34:34 fc0_16_TTT 12.2
2024-03-16 06:34:34 fc0_16_time 16:00
2024-03-16 06:34:34 fc0_16_ww 2
2024-03-16 06:34:34 fc0_16_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc0_17_Neff 56
2024-03-16 06:34:34 fc0_17_RR1c 0.00
2024-03-16 06:34:34 fc0_17_SunUp 1
2024-03-16 06:34:34 fc0_17_TTT 11.5
2024-03-16 06:34:34 fc0_17_time 17:00
2024-03-16 06:34:34 fc0_17_ww 2
2024-03-16 06:34:34 fc0_17_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc0_18_Neff 49
2024-03-16 06:34:34 fc0_18_RR1c 0.00
2024-03-16 06:34:34 fc0_18_SunUp 1
2024-03-16 06:34:34 fc0_18_TTT 10.6
2024-03-16 06:34:34 fc0_18_time 18:00
2024-03-16 06:34:34 fc0_18_ww 1
2024-03-16 06:34:34 fc0_18_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc0_19_Neff 45
2024-03-16 06:34:34 fc0_19_RR1c 0.00
2024-03-16 06:34:34 fc0_19_SunUp 0
2024-03-16 06:34:34 fc0_19_TTT 9.20
2024-03-16 06:34:34 fc0_19_time 19:00
2024-03-16 06:34:34 fc0_19_ww 1
2024-03-16 06:34:34 fc0_19_wwd Bewölkung abnehmend
2024-03-16 00:38:18 fc0_1_Neff 83
2024-03-16 00:38:18 fc0_1_RR1c 0.00
2024-03-16 00:38:18 fc0_1_SunUp 0
2024-03-16 00:38:18 fc0_1_TTT 10.3
2024-03-16 00:38:18 fc0_1_time 01:00
2024-03-16 00:38:18 fc0_1_ww 3
2024-03-16 00:38:18 fc0_1_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc0_20_Neff 44
2024-03-16 06:34:34 fc0_20_RR1c 0.00
2024-03-16 06:34:34 fc0_20_SunUp 0
2024-03-16 06:34:34 fc0_20_TTT 7.70
2024-03-16 06:34:34 fc0_20_time 20:00
2024-03-16 06:34:34 fc0_20_ww 1
2024-03-16 06:34:34 fc0_20_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc0_21_Neff 41
2024-03-16 06:34:34 fc0_21_RR1c 0.00
2024-03-16 06:34:34 fc0_21_SunUp 0
2024-03-16 06:34:34 fc0_21_TTT 6.40
2024-03-16 06:34:34 fc0_21_time 21:00
2024-03-16 06:34:34 fc0_21_ww 1
2024-03-16 06:34:34 fc0_21_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc0_22_Neff 43
2024-03-16 06:34:34 fc0_22_RR1c 0.00
2024-03-16 06:34:34 fc0_22_SunUp 0
2024-03-16 06:34:34 fc0_22_TTT 5.10
2024-03-16 06:34:34 fc0_22_time 22:00
2024-03-16 06:34:34 fc0_22_ww 1
2024-03-16 06:34:34 fc0_22_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc0_23_Neff 43
2024-03-16 06:34:34 fc0_23_RR1c 0.00
2024-03-16 06:34:34 fc0_23_SunUp 0
2024-03-16 06:34:34 fc0_23_TTT 4.20
2024-03-16 06:34:34 fc0_23_time 23:00
2024-03-16 06:34:34 fc0_23_ww 1
2024-03-16 06:34:34 fc0_23_wwd Bewölkung abnehmend
2024-03-16 01:38:51 fc0_2_Neff 84
2024-03-16 01:38:51 fc0_2_RR1c 0.00
2024-03-16 01:38:51 fc0_2_SunUp 0
2024-03-16 01:38:51 fc0_2_TTT 9.90
2024-03-16 01:38:51 fc0_2_time 02:00
2024-03-16 01:38:51 fc0_2_ww 3
2024-03-16 01:38:51 fc0_2_wwd Bewölkung zunehmend
2024-03-16 02:39:29 fc0_3_Neff 83
2024-03-16 02:39:29 fc0_3_RR1c 0.00
2024-03-16 02:39:29 fc0_3_SunUp 0
2024-03-16 02:39:29 fc0_3_TTT 9.60
2024-03-16 02:39:29 fc0_3_time 03:00
2024-03-16 02:39:29 fc0_3_ww 3
2024-03-16 02:39:29 fc0_3_wwd Bewölkung zunehmend
2024-03-16 03:35:42 fc0_4_Neff 84
2024-03-16 03:35:42 fc0_4_RR1c 0.00
2024-03-16 03:35:42 fc0_4_SunUp 0
2024-03-16 03:35:42 fc0_4_TTT 9.60
2024-03-16 03:35:42 fc0_4_time 04:00
2024-03-16 03:35:42 fc0_4_ww 3
2024-03-16 03:35:42 fc0_4_wwd Bewölkung zunehmend
2024-03-16 04:34:27 fc0_5_Neff 86
2024-03-16 04:34:27 fc0_5_RR1c 0.00
2024-03-16 04:34:27 fc0_5_SunUp 0
2024-03-16 04:34:27 fc0_5_TTT 9.90
2024-03-16 04:34:27 fc0_5_time 05:00
2024-03-16 04:34:27 fc0_5_ww 61
2024-03-16 04:34:27 fc0_5_wwd durchgehend leichter Regen
2024-03-16 05:33:23 fc0_6_Neff 88
2024-03-16 05:33:23 fc0_6_RR1c 0.10
2024-03-16 05:33:23 fc0_6_SunUp 0
2024-03-16 05:33:23 fc0_6_TTT 9.60
2024-03-16 05:33:23 fc0_6_time 06:00
2024-03-16 05:33:23 fc0_6_ww 61
2024-03-16 05:33:23 fc0_6_wwd durchgehend leichter Regen
2024-03-16 06:34:34 fc0_7_Neff 89
2024-03-16 06:34:34 fc0_7_RR1c 0.10
2024-03-16 06:34:34 fc0_7_SunUp 1
2024-03-16 06:34:34 fc0_7_TTT 9.40
2024-03-16 06:34:34 fc0_7_time 07:00
2024-03-16 06:34:34 fc0_7_ww 61
2024-03-16 06:34:34 fc0_7_wwd durchgehend leichter Regen
2024-03-16 06:34:34 fc0_8_Neff 89
2024-03-16 06:34:34 fc0_8_RR1c 0.00
2024-03-16 06:34:34 fc0_8_SunUp 1
2024-03-16 06:34:34 fc0_8_TTT 10
2024-03-16 06:34:34 fc0_8_time 08:00
2024-03-16 06:34:34 fc0_8_ww 61
2024-03-16 06:34:34 fc0_8_wwd durchgehend leichter Regen
2024-03-16 06:34:34 fc0_9_Neff 88
2024-03-16 06:34:34 fc0_9_RR1c 0.00
2024-03-16 06:34:34 fc0_9_SunUp 1
2024-03-16 06:34:34 fc0_9_TTT 10.5
2024-03-16 06:34:34 fc0_9_time 09:00
2024-03-16 06:34:34 fc0_9_ww 61
2024-03-16 06:34:34 fc0_9_wwd durchgehend leichter Regen
2024-03-16 06:34:34 fc0_SunRise 06:33
2024-03-16 06:34:34 fc0_SunSet 18:34
2024-03-16 06:34:34 fc0_date 2024-03-16
2024-03-16 06:34:34 fc0_weekday Sa
2024-03-16 06:34:34 fc1_0_Neff 46
2024-03-16 06:34:34 fc1_0_RR1c 0.00
2024-03-16 06:34:34 fc1_0_SunUp 0
2024-03-16 06:34:34 fc1_0_TTT 3.40
2024-03-16 06:34:34 fc1_0_time 00:00
2024-03-16 06:34:34 fc1_0_ww 1
2024-03-16 06:34:34 fc1_0_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc1_10_Neff 71
2024-03-16 06:34:34 fc1_10_RR1c 0.00
2024-03-16 06:34:34 fc1_10_SunUp 1
2024-03-16 06:34:34 fc1_10_TTT 6.80
2024-03-16 06:34:34 fc1_10_time 10:00
2024-03-16 06:34:34 fc1_10_ww 2
2024-03-16 06:34:34 fc1_10_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_11_Neff 70
2024-03-16 06:34:34 fc1_11_RR1c 0.00
2024-03-16 06:34:34 fc1_11_SunUp 1
2024-03-16 06:34:34 fc1_11_TTT 8.5
2024-03-16 06:34:34 fc1_11_time 11:00
2024-03-16 06:34:34 fc1_11_ww 2
2024-03-16 06:34:34 fc1_11_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_12_Neff 70
2024-03-16 06:34:34 fc1_12_RR1c 0.00
2024-03-16 06:34:34 fc1_12_SunUp 1
2024-03-16 06:34:34 fc1_12_TTT 9.90
2024-03-16 06:34:34 fc1_12_time 12:00
2024-03-16 06:34:34 fc1_12_ww 2
2024-03-16 06:34:34 fc1_12_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_13_Neff 73
2024-03-16 06:34:34 fc1_13_RR1c 0.00
2024-03-16 06:34:34 fc1_13_SunUp 1
2024-03-16 06:34:34 fc1_13_TTT 10.7
2024-03-16 06:34:34 fc1_13_time 13:00
2024-03-16 06:34:34 fc1_13_ww 2
2024-03-16 06:34:34 fc1_13_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_14_Neff 72
2024-03-16 06:34:34 fc1_14_RR1c 0.00
2024-03-16 06:34:34 fc1_14_SunUp 1
2024-03-16 06:34:34 fc1_14_TTT 11.9
2024-03-16 06:34:34 fc1_14_time 14:00
2024-03-16 06:34:34 fc1_14_ww 2
2024-03-16 06:34:34 fc1_14_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_15_Neff 74
2024-03-16 06:34:34 fc1_15_RR1c 0.00
2024-03-16 06:34:34 fc1_15_SunUp 1
2024-03-16 06:34:34 fc1_15_TTT 12.5
2024-03-16 06:34:34 fc1_15_time 15:00
2024-03-16 06:34:34 fc1_15_ww 3
2024-03-16 06:34:34 fc1_15_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_16_Neff 77
2024-03-16 06:34:34 fc1_16_RR1c 0.00
2024-03-16 06:34:34 fc1_16_SunUp 1
2024-03-16 06:34:34 fc1_16_TTT 12.3
2024-03-16 06:34:34 fc1_16_time 16:00
2024-03-16 06:34:34 fc1_16_ww 3
2024-03-16 06:34:34 fc1_16_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_17_Neff 77
2024-03-16 06:34:34 fc1_17_RR1c 0.00
2024-03-16 06:34:34 fc1_17_SunUp 1
2024-03-16 06:34:34 fc1_17_TTT 12
2024-03-16 06:34:34 fc1_17_time 17:00
2024-03-16 06:34:34 fc1_17_ww 3
2024-03-16 06:34:34 fc1_17_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_18_Neff 79
2024-03-16 06:34:34 fc1_18_RR1c 0.00
2024-03-16 06:34:34 fc1_18_SunUp 1
2024-03-16 06:34:34 fc1_18_TTT 11
2024-03-16 06:34:34 fc1_18_time 18:00
2024-03-16 06:34:34 fc1_18_ww 3
2024-03-16 06:34:34 fc1_18_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_19_Neff 79
2024-03-16 06:34:34 fc1_19_RR1c 0.00
2024-03-16 06:34:34 fc1_19_SunUp 0
2024-03-16 06:34:34 fc1_19_TTT 9.90
2024-03-16 06:34:34 fc1_19_time 19:00
2024-03-16 06:34:34 fc1_19_ww 3
2024-03-16 06:34:34 fc1_19_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_1_Neff 50
2024-03-16 06:34:34 fc1_1_RR1c 0.00
2024-03-16 06:34:34 fc1_1_SunUp 0
2024-03-16 06:34:34 fc1_1_TTT 2.80
2024-03-16 06:34:34 fc1_1_time 01:00
2024-03-16 06:34:34 fc1_1_ww 1
2024-03-16 06:34:34 fc1_1_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc1_20_Neff 80
2024-03-16 06:34:34 fc1_20_RR1c 0.00
2024-03-16 06:34:34 fc1_20_SunUp 0
2024-03-16 06:34:34 fc1_20_TTT 8.80
2024-03-16 06:34:34 fc1_20_time 20:00
2024-03-16 06:34:34 fc1_20_ww 3
2024-03-16 06:34:34 fc1_20_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_21_Neff 83
2024-03-16 06:34:34 fc1_21_RR1c 0.00
2024-03-16 06:34:34 fc1_21_SunUp 0
2024-03-16 06:34:34 fc1_21_TTT 7.90
2024-03-16 06:34:34 fc1_21_time 21:00
2024-03-16 06:34:34 fc1_21_ww 3
2024-03-16 06:34:34 fc1_21_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_22_Neff 85
2024-03-16 06:34:34 fc1_22_RR1c 0.00
2024-03-16 06:34:34 fc1_22_SunUp 0
2024-03-16 06:34:34 fc1_22_TTT 7.20
2024-03-16 06:34:34 fc1_22_time 22:00
2024-03-16 06:34:34 fc1_22_ww 3
2024-03-16 06:34:34 fc1_22_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_23_Neff 85
2024-03-16 06:34:34 fc1_23_RR1c 0.00
2024-03-16 06:34:34 fc1_23_SunUp 0
2024-03-16 06:34:34 fc1_23_TTT 7.10
2024-03-16 06:34:34 fc1_23_time 23:00
2024-03-16 06:34:34 fc1_23_ww 3
2024-03-16 06:34:34 fc1_23_wwd Bewölkung zunehmend
2024-03-16 06:34:34 fc1_2_Neff 52
2024-03-16 06:34:34 fc1_2_RR1c 0.00
2024-03-16 06:34:34 fc1_2_SunUp 0
2024-03-16 06:34:34 fc1_2_TTT 2.40
2024-03-16 06:34:34 fc1_2_time 02:00
2024-03-16 06:34:34 fc1_2_ww 1
2024-03-16 06:34:34 fc1_2_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc1_3_Neff 55
2024-03-16 06:34:34 fc1_3_RR1c 0.00
2024-03-16 06:34:34 fc1_3_SunUp 0
2024-03-16 06:34:34 fc1_3_TTT 1.80
2024-03-16 06:34:34 fc1_3_time 03:00
2024-03-16 06:34:34 fc1_3_ww 1
2024-03-16 06:34:34 fc1_3_wwd Bewölkung abnehmend
2024-03-16 06:34:34 fc1_4_Neff 59
2024-03-16 06:34:34 fc1_4_RR1c 0.00
2024-03-16 06:34:34 fc1_4_SunUp 0
2024-03-16 06:34:34 fc1_4_TTT 1.60
2024-03-16 06:34:34 fc1_4_time 04:00
2024-03-16 06:34:34 fc1_4_ww 2
2024-03-16 06:34:34 fc1_4_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_5_Neff 63
2024-03-16 06:34:34 fc1_5_RR1c 0.00
2024-03-16 06:34:34 fc1_5_SunUp 0
2024-03-16 06:34:34 fc1_5_TTT 1.30
2024-03-16 06:34:34 fc1_5_time 05:00
2024-03-16 06:34:34 fc1_5_ww 2
2024-03-16 06:34:34 fc1_5_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_6_Neff 66
2024-03-16 06:34:34 fc1_6_RR1c 0.00
2024-03-16 06:34:34 fc1_6_SunUp 0
2024-03-16 06:34:34 fc1_6_TTT 1.20
2024-03-16 06:34:34 fc1_6_time 06:00
2024-03-16 06:34:34 fc1_6_ww 2
2024-03-16 06:34:34 fc1_6_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_7_Neff 67
2024-03-16 06:34:34 fc1_7_RR1c 0.00
2024-03-16 06:34:34 fc1_7_SunUp 1
2024-03-16 06:34:34 fc1_7_TTT 1.5
2024-03-16 06:34:34 fc1_7_time 07:00
2024-03-16 06:34:34 fc1_7_ww 2
2024-03-16 06:34:34 fc1_7_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_8_Neff 68
2024-03-16 06:34:34 fc1_8_RR1c 0.00
2024-03-16 06:34:34 fc1_8_SunUp 1
2024-03-16 06:34:34 fc1_8_TTT 2.80
2024-03-16 06:34:34 fc1_8_time 08:00
2024-03-16 06:34:34 fc1_8_ww 2
2024-03-16 06:34:34 fc1_8_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_9_Neff 69
2024-03-16 06:34:34 fc1_9_RR1c 0.00
2024-03-16 06:34:34 fc1_9_SunUp 1
2024-03-16 06:34:34 fc1_9_TTT 4.70
2024-03-16 06:34:34 fc1_9_time 09:00
2024-03-16 06:34:34 fc1_9_ww 2
2024-03-16 06:34:34 fc1_9_wwd Bewölkung unverändert
2024-03-16 06:34:34 fc1_SunRise 06:31
2024-03-16 06:34:34 fc1_SunSet 18:36
2024-03-16 06:34:34 fc1_date 2024-03-17
2024-03-16 06:34:34 fc1_weekday So
2024-03-16 06:34:34 fc_coordinates 8.87,50.27,162.0
2024-03-16 06:34:34 fc_copyright Datenbasis: Deutscher Wetterdienst
2024-03-16 06:34:34 fc_description NIDDERAU-ERBSTADT
2024-03-16 06:34:34 fc_dwdDocSize 39994086
2024-03-16 06:34:34 fc_dwdDocTime 2024-03-16 05:22:03Z
2024-03-16 07:33:12 fc_state updated
2024-03-16 06:34:34 fc_station L751
2024-03-16 06:34:34 fc_time 2024-03-16 06:00:00
2024-03-16 06:34:34 fc_url https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024-03-16 08:07:15 nextUpdate 08:20:57
2024-03-16 07:33:12 state forecast unchanged
Attributes:
DbLogExclude .*
event-on-change-reading .*
forecastDays 1
forecastProperties TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet
forecastRefresh 1
forecastResolution 1
forecastStation L751
forecastWW2Text 1
icon rc_WEB
room Haus->PV Forecast,WetterWenn es noch weitere Informationen braucht dann sag bitte Bescheid. Ich liefere...
Schönes Wochenende!
Moin,
ich kann leider die Anhänge nicht öffnen -> 404 File not found.
Hm, der Upload von zwei kleinen Bildern hat beim letzten Mal leider auch sehr lange gedauert!?
Dann halt so:
Ein Scheck der Anlagenkonfiguration zeigt mir das:
checked parameters and attributes of device "DWD_Friedberg":
forecastProperties -> TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet
forecastRefresh
checked parameters and attributes of device "DWD_Erbstadt":
forecastProperties -> TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet
forecastRefresh
The Prediction time of Weather data is older than expected when using MOSMIX_S.
Data time forecast: 16.03.2024 06:00:00
Check the DWD device(s) for proper functioning of the data retrieval.
checked global Weather parameters:
MOSMIX variant, Age of Weather data.
Und Forecast Solar steht im Frontend auf Rot und im tooltip steht: "API Abfrage fehlgeschlagen: Rate limit for API Call reached."
ZitatAPI Abfrage fehlgeschlagen: Rate limit for API Call reached.
Abhängig von der gewählten API gibt es Beschränkungen.
Das Modul optimiert die Abfragen entsprechend.
Wird manuell mit "get ... rooftopData" abgerufen oder bei manchen Grenzbedingungen (Zeit des Sonnenaufgang, Sonnenuntergang), kann ein Limit erreicht sein und das Signal geht auf rot.
Im Normalfall braucht man nur warten. Das Modul korrigiert automatisch die Situation.
Welche API setzt du ein?Jetzt kann ich die Anhänge öffnen und sehe die verwendete API.
Edit: Bezüglich MOSMIX_S gibt es manchmal auch die Situation, dass der DWD die normalerweise stündliche Aktualisierung auslässt. Das habe ich bis jetzt regelmäßig nur früh um 7:00 festgestellt.
Wenn sich das manifestiert, kann ich im Check diese Zeit in der Bewertung auslassen.
Irgend wie stimmt da was bei mir nicht:
In der configuration sollte das Modul eigentlich MOSMIX_S nehmen.
defmod DWD DWD_OpenData
attr DWD DbLogExclude .*
attr DWD alertArea 805170028
attr DWD downloadTimeout 120
attr DWD event-on-change-reading .*
attr DWD forecastDays 2
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff,RR1c
attr DWD forecastRefresh 2
attr DWD forecastResolution 1
attr DWD forecastStation N9109
attr DWD forecastWW2Text 1
attr DWD room Wetter
attr DWD stateFormat Morgen Tmax fc1_Tx °C on fc1_date at fc_description
attr DWD verbose 2Meine Plant Konfigurationscheck sagt mir aber:
ZitatThe device "DWD" uses "MOSMIX_L" which is only updated by DWD every 6 hours.
erfüllt (Attribut: ctrlWeatherDev1)
Mein Fhem hatte reboots. Hatte das Modul in verdacht. Also die den refreshintervall auf 6 gestellt und die fhem neustarts waren weg.
Jetzt wollte ich der sache auf den Grund gehen und habe den Wert wieder runter gesetzt gestern.
Keine fhem Neustarts mehr aber auch keine MOSMIX_S benutzung anscheinend.
Also Fhem neugestartet, Raspberry neugestartet, Datenholung manuel angetriggert (jetzt nicht genau die Reinfolge, aber alles schon passiert). Es ändert sich nichts.
MOSMIX_S wird benutzt bei:
attr DWD forecastRefresh=1 !
siehe unten ...
hmm, steht da aber anders:
ZitatforecastRefresh <n>, 1 .. 6 h, default: 6 h
The DWD distinguishes between MOSMIX S and L reports, which differ in terms of update frequency and available data elements:
- 1 .. 5 h: MOSMIX S, 40 data elements, updated every 1 h at ~25 min past every hour, download volume ~40 MB/h
- 6 h: MOSMIX L, ~115 data elements, updated every 6 h at ~55 min past 21/3/9/15 UTC, download volume ~3 kB/h
See the MOSMIX processes description and the MOSMIX data element discription for more details.
OK!
Stimmt, hast Recht. Habe gerade im Code verglichen, der passt mit der Hilfe überein.
Da muß ich den Check ändern.
Aber mit deinen Neustarts sehe ich keinen Zusammenhang. Die Einstellung wirkt nur auf den Timer im DWD wie oft versucht wird etwas vom Dienst abzuholen.
Beim Neustart müsste im Log etwas zu sehen sein.
Morgen früh wird die Version V1.16.8 ausgrollt.
Folgende Umsetzungen sind enthalten:
- plantConfiguration check: diverse Anpassungen, u.a. Setting von forecastRefresh im DWD Device
- das Reading nextSolCastCall ist in nextRadiationAPICall umbenannt (Kontext passte nicht mehr)
- beim Löschen des Device werden auch die Laufzeitdaten im RAM gelöscht
- currentMeterDev: neue optionale Schlüssel conprice, feedprice zur Angabe des Bezugspreises/der Einspeisevergütung pro kWh
(das ist eine Vorbereitung für Weiterentwicklungen)
Die Version kann bereits jetzt aus meinem contrib geladen werden wer möchte. Restart nicht vergessen!
Grüße,
Heiko
Kleine Anmerkung.
Im Plantkonfigurationscheck kommt folgendes wenn man deine Datei aus dem Contrib zieht und diese neuer ist.
The AI support is not used.
A new FHEM/76_SolarForecast.pm version is available on SVN (creation time: 2024-03-13_07:45:03, size: 1061532 Bytes).
wäre es nicht vieleicht besser es so auszudrücken:
The AI support is not used.
Another official FHEM/76_SolarForecast.pm version is available on SVN (creation time: 2024-03-13_07:45:03, size: 1061532 Bytes).
Die Ausgabe kommt aus dem zentralen SMUtils Modul.
Habe deinen Vorschlag umgesetzt und SMUtils ist morgen mit im Update.
LG
Ich habe eine Frage bzw. eine Anregung zu den Daten von der SolCast-API:
Auf der Website stellt SolCast die erwartete Leistung für die konfigurierte Anlage sowie zusätzlich die 90- und 10%-Perzentilen dar. Lt. API-Dokumentation können diese Daten auch abgefragt werden.
Wäre es nicht sinnvoll die Verbrauchsplanung an der WorstCase-Vorhersage zu orientieren?
Gerade in den helleren Monaten würde das meiner Meinung nach Sinn machen.
Moin,
ZitatAuf der Website stellt SolCast die erwartete Leistung für die konfigurierte Anlage sowie zusätzlich die 90- und 10%-Perzentilen dar. Lt. API-Dokumentation können diese Daten auch abgefragt werden.
Wäre es nicht sinnvoll die Verbrauchsplanung an der WorstCase-Vorhersage zu orientieren?
Diese Möglichkeit ist schon gegeben. Mit dem Attribut
affectSolCastPercentile kannst du die Auswahl des abgerufenen Perzentils bestimmen.
Grüße,
Heiko
Zitat von: DS_Starter am 19 März 2024, 08:45:22affectSolCastPercentile
Wie wirkt sich das dann auf die gelernten Korrekturfaktoren aus?
Ich hätte verstanden, dass auf Basis der Abweichung zwischen IST und Prognose der Korrekturfaktor "gelernt" wird (abhängig von Wetter und/oder Uhrzeit?)
Wenn ich nun auf eine pessimistischere Prognose umstelle, würde das durch die Lernfunktion über den Korrekturfaktor doch wieder kompensiert, oder verstehe ich da was falsch?
Meine Idee war eher, dass zwar die "globale/generelle" Vorhersage so läuft wie bisher, für die Verbrauchsplanung aber die WorstCase-Daten verwendet werden (zumindest solange sich alle Verbraucher auch mit den WorstCase-Daten unterbringen lassen).
ZitatWenn ich nun auf eine pessimistischere Prognose umstelle, würde das durch die Lernfunktion über den Korrekturfaktor doch wieder kompensiert, oder verstehe ich da was falsch?
Nein, das verstehst du völlig richtig. So ist es.
EDIT: Du kannst natürlich auch ohne Learning/Korrekturfaktorberechnung arbeiten -> "set ... pvCorrectionFactor_Auto noLearning".
ZitatMeine Idee war eher, dass zwar die "globale/generelle" Vorhersage so läuft wie bisher, für die Verbrauchsplanung aber die WorstCase-Daten verwendet werden (zumindest solange sich alle Verbraucher auch mit den WorstCase-Daten unterbringen lassen).
Das hatte ich fast befürchtet. ;)
Das würde bedeuten, es müsste eine zweite "Schattenprognose" mit allen Mechanismen (wie Autokorrektur, Auswertung für Consumer Steuerung) parallel mitlaufen. Wahrscheinlich kannst du dir vorstellen wie aufwändig so etwas wäre und würde die aktuelle Komplexität noch einmal potenzieren. Noch dazu wäre dieses Feature nur auf SolCast beschränkt und mit wahrscheinlich wenig Effekt.
Da verwende ich meine Kraft und Zeit lieber in die Integration einer weiteren API wie der DWD ICON API (https://open-meteo.com/en/docs/dwd-api).
Das sie für Zentraleuropa bereitgestellt wird, könnte sie auch für Österreich genau richtig sein. Auf der Webseite kannst du das mal checken.
Diese API ist vllt. eine echte Alternative zu SolCast (wegen der Beschränkungen).
Zitat von: DS_Starter am 19 März 2024, 15:11:19zweite "Schattenprognose" mit allen Mechanismen (wie Autokorrektur, Auswertung für Consumer Steuerung) parallel mitlaufen
Das ist die Frage...
2. Autokorrektur würde ich eher "nein" sagen, weil es ohnehin schon eine WorstCase-Prognose ist. Die muss man aus meiner Sicht weder nach unten noch nach oben korrigieren. SolCast berücksichtigt die Wetterprognose ja selbst in den Werten, warum also da auf Basis der Wetterprognose nochmal was korrigieren?
Die automatische Consumer-Steuerung müsste nur die "WorstCase-" statt der realistischen Prognose ansetzen.
Zitat von: DS_Starter am 19 März 2024, 15:11:19Noch dazu wäre dieses Feature nur auf SolCast beschränkt und mit wahrscheinlich wenig Effekt.
Bzgl. SolCast gebe ich Dir Recht.
Über den Effekt lässt sich vmtl. streiten: Ich habe kürzlich die Warmwasser-Bereitung (über Wärmepumpe) von "must" auf "can" in Kombination mit spignorecond umgestellt. Die Bedingung in der spignorecond ist nun die, die ich davor in swoncond hatte ("Speichertemperatur verhältnismäßig niedrig"). Die Bedingung in swoncond habe ich so angepasst, dass ein Betrieb nicht nötig, aber bei ausreichend Überschuss sinnvoll wäre ("Speichertemperatur ausreichend hoch, aber Potenzial zum Nachheizen vorhanden"). Seit dieser Umstellung scheint der Verbraucher zum frühestmöglichen Zeitpunkt am Tag eingeplant zu werden, vor der Umstellung war es immer zum Zeitpunkt mit der prognostiziert höchsten PV-Leistung, selbst wenn davor schon mehr als genug Leistung vorhanden gewesen wäre.
Bisher ist das immer gut gegangen und es war schon früh genug ausreichend Leistung vorhanden, wenn die spignorecond zugetroffen hat, aber das liegt wohl eher an dem aktuell konstant sonnigem Wetter. Mit der "worst case" Einplanung würde auch bei weniger zutreffender Prognose tendenziell ein besseres Zeitfenster gewählt werden.
Zitat von: DS_Starter am 19 März 2024, 15:11:19DWD ICON API (https://open-meteo.com/en/docs/dwd-api).
Wenn Du das vor der Geosphere Austria angehst, würd' ich das jedenfalls mal ausprobieren, ja.
ZitatDas ist die Frage...
2. Autokorrektur würde ich eher "nein" sagen, weil es ohnehin schon eine WorstCase-Prognose ist. Die muss man aus meiner Sicht weder nach unten noch nach oben korrigieren. SolCast berücksichtigt die Wetterprognose ja selbst in den Werten, warum also da auf Basis der Wetterprognose nochmal was korrigieren?
Auch ohne Autokorrektur bleibt es bei einer "Schattenprognose" die verwaltet werden muß.
Schon allein die theoretische Frage wann ein Nutzer/Consumer die normale oder die Schattenprognose nutzen soll lässt sich nicht anhand von auswertbaren Parametern beantworten.
ZitatBzgl. SolCast gebe ich Dir Recht.
Über den Effekt lässt sich vmtl. streiten:...
Ich erweitere mein Statement: ... -> mit wahrscheinlich wenig Effekt gemessen an dem Aufwand den ich an Zeit investieren müsste ...
Ich gebe natürlich zu, dass dein Anwendungsfall diesbezüglich sehr interessant ist.
Wir müssten mal überlegen, ob sich der gleiche Effekt nicht durch einen geschickten Einsatz der vorhandenen Consumerschlüssel (oder vllt. eines weiteren) erreichen ließe.
Alternativ wäre auch möglich, eine zweite SolarForecast Instanz zu erstellen, die du nur mit dem Perzentil 10 und den relevanten Consumern ohne Learning/Korrektur laufen lässt.
Verstehe mich bitte nicht falsch, aber allein schon die Consumer Verwaltung ist intern schon sehr komplex. Die Integration einer Parallelwelt mit nicht determinierbaren Auswahlkriterien führt zu einem nicht mehr beherrschbaren Konstrukt. Das Ganze muß ja auch noch pflegbar, supportbar und beschreibbar/erklärbar bleiben. Mal von meinem Zeitkontingent abgesehen.
Hallo zusammen,
ich spiele gerade mit dem Gedanken im Modul 76_SolarForecast eine Virtuellen Batterie zu implementieren. Das heißt über einen Dummy die Einspeisung als BatIn und den Netzbezug als BatOut zu bewerten. Diese Werte werden bis 0 oder BatCap aufsummiert/subtrahiert. Hat sich jemand ebenfalls Gedanken in diese Richtung gemacht?
Vielleicht gibt es ja Interesse an so einer Lösung.
Ich freue mich über eure Rückmeldung.
Gruß Bison
Zitat von: DS_Starter am 19 März 2024, 16:34:28Verstehe mich bitte nicht falsch, aber allein schon die Consumer Verwaltung ist intern schon sehr komplex. Die Integration einer Parallelwelt mit nicht determinierbaren Auswahlkriterien führt zu einem nicht mehr beherrschbaren Konstrukt. Das Ganze muß ja auch noch pflegbar, supportbar und beschreibbar/erklärbar bleiben. Mal von meinem Zeitkontingent abgesehen.
Überhaupt kein Thema, ich wollte es mal als Anregung in den Raum werfen, erwarte aber natürlich nicht, dass es vorbehalt- und/oder diskussionslos umgesetzt wird.
Ich kann mir gut vorstellen, dass in die Entwicklung einiges an Aufwand reinfließt und insgesamt ist die Komplexität sicher jetzt schon hoch.
Der Vorschlag mit der 2. Instanz ist gut, wg. der SolCast-Limitierung müsste ich einfach einen 2. Account dafür anlegen & wohl auch endlich mal die Reparatur meiner Peripherie am RasPi angehen, damit ich in dem Zuge gleich den 3B gegen einen 4er mit 4GB RAM tauschen kann.
Zitat von: Bison am 19 März 2024, 22:29:30Hallo zusammen,
ich spiele gerade mit dem Gedanken im Modul 76_SolarForecast eine Virtuellen Batterie zu implementieren. Das heißt über einen Dummy die Einspeisung als BatIn und den Netzbezug als BatOut zu bewerten. Diese Werte werden bis 0 oder BatCap aufsummiert/subtrahiert. Hat sich jemand ebenfalls Gedanken in diese Richtung gemacht?
Vielleicht gibt es ja Interesse an so einer Lösung.
Ich freue mich über eure Rückmeldung.
Gruß Bison
Guten Morgen,
worin soll denn da der Sinn sein - gibt es dazu einen besonderen Grund ? :o
8) Und wenn sich jetzt das Wetter noch an die Vorhersage halten würde!
Screenshot 2024-03-20 164144.png
Spass beiseite! Ich habe es richtig verstanden, dass das Modul jetzt selbstständig lernt und sich mit der Zeit anpasst?
VG
Reiner
Ja, sollte so sein !
PS:
Upload Screenshot wieder nicht lesbar....
PPS:
Nach 45 Minuten geht es jetzt
Wenn es ein bisschen in die Schule gegangen ist, kann es dann so aussehen.... ;)
Es ist aber etwas Geduld gefragt! Die Korrekturwerte sind für jede einzelne Stunde abhängig von der prognostizierten Bewölkung, Strahlung und den realen Werten.
An der LED "Qualität" kann man das bisher erreichte Verhältnis zwischen Prognose und realem Ertrag der aktuellen Stunde nach einem Ampelsystem abschätzen.
Ich habe mir eine Dummy gebastelt aus 3 Forecast's, SolcastAPI, DWD, Victron.
Damit bekomme ich eine homogenere genauer Vorhersage, wie ich finde.
Die ForecastSolarAPI habe ich auch noch aber die bekomme ich nicht brauchbar in den Griff. Für heute war er ausnahmesweise einiger massen brauchbar.
@DS_Starter
ZitatDa verwende ich meine Kraft und Zeit lieber in die Integration einer weiteren API wie der DWD ICON API.
Du bist ja immer flott mit sowas. Wann kann man damit rechnen bzw. hast du dir die Sache schon einmal genauer angeschaut? Schon eine grobe Einschätzung?
Nicht das ich es unbedingt sofort brauche. Aber "haben" ist besser als "brauchen" ;)
Ja, habe es mir bereits angeschaut.
Ich hoffe am WE eine erste brauchbare Implementierung testen zu können.
Zitat von: 300P am 20 März 2024, 07:37:10Zitat von: Bison am 19 März 2024, 22:29:30Hallo zusammen,
ich spiele gerade mit dem Gedanken im Modul 76_SolarForecast eine Virtuellen Batterie zu implementieren. Das heißt über einen Dummy die Einspeisung als BatIn und den Netzbezug als BatOut zu bewerten. Diese Werte werden bis 0 oder BatCap aufsummiert/subtrahiert. Hat sich jemand ebenfalls Gedanken in diese Richtung gemacht?
Vielleicht gibt es ja Interesse an so einer Lösung.
Ich freue mich über eure Rückmeldung.
Gruß Bison
Guten Morgen,
worin soll denn da der Sinn sein - gibt es dazu einen besonderen Grund ? :o
Ich möchte mit verschiedenen Batteriegrößen spielen, um zu sehen welche Größe die optimale ist.
Das ist zwar keine PV-Beratung hier ;D ... aber ...
Nimm maximal deinen durchschnittlichen Tagesverbrauch, aber mindestens das was du im Sommer nach Sonnenuntergang bis Sonnenaufgang verbrauchst. (Kannst du den Statistikwerten des Modules entnehmen) ;)
Deine PV-Anlage sollte ebenfalls dann dazu passende technische Leistungen haben
Am Ende bestimmt dann aber auch noch das verfügbare Geld für den Speicher die Größe und die ,,Technik" der Batterie. (1 oder 3 Phasen, Erweiterungsmöglichkeiten und ob Notstrom / Ersatzstrom etc. usw. ...)
Viel Spass bei der Auswahl - aber dieses Modul kann dir deine Entscheidung dafür leider nicht abnehmen.
Hol dir evtl. dafür vielleicht einen Ratschlag im https://www.photovoltaikforum.com/ (https://www.photovoltaikforum.com/) - da gibt es sicherlich einen Bereich für Empfehlungen und Hilfe bei der Auswahlt der notwendigen Gerätschaften.
Und da kommen schon die 3 Meinungen in 2 Antworten.
Ich denke das Modul kann dir schon helfen bei der Auswahl. Alle benötigten Parameter sind enthalten um das auszzuloten.
Kalkuliere 110% von dem Verbrauch im Frühling/Herbst Verbrauch von Sonnenuntergang-Sonnenaufgang. 110% weil du nur 90% des Speichers nutzen kannst/hast.
Im Winter...vergess den winter! Und im Sommer hast du PV überfluß.
Dazu haust du noch eine Alterungspauschale 20%. Somit bekommst du in 20Jahren noch deine jetzt benötigte Energie raus.
Ob du in 20 Jahren die jetzige Ernergie noch brauchst oder der Speicher das überhaupt schaft, weiß jetzt keiner.
Und die Staffelung der größen ist ja auch nicht so genau bestimmbar.
Der Speicher maximal so groß das du den überhaupt mindestens 150x im Jahr voll bekommst.
Und mit einem Speicher wird es schwer das der sich amortisiert. Kann klappen, meist aber nicht.
Kann man sich aber unglaublich schön rechnen ;)
Jede kWh aus dem Speicher ist meist teurer wie gekaufter Strom.
Um 1kWh zu entnehmen muss man 1,1 - 1,25kWh rein pumpen. Das Kostet je nach Anlagengröße schon einmal 1.1-1.25 x 8,2 cent.
Weil die bekommst du nicht mehr vom Netzbetreiber.
Also deine Batterie-kWh klaut dir ca. 9-10.25 cent.
Die gekauft kWh kostet dich viel mehr, ist schon klar. Aber rechne mal wie lange es dauert das so ein Speicher sich abbezahlt hat.
Ein Speicher ist Hobby! Ein Hobby was nix kostet, ist kein Hobby!
Man kann sich alles zurecht legen, das es einem paßt.
Hallo Kask,
danke für die Anregungen ich werde die in meine Berechnung/Simulation einfließen lassen. Am besten finde ich das mit dem Hobby, Fhem ist mein Hobby und wenn ich denke wieviel Zeit ich hier schon verbraten habe...
Im Moment simuliere ich eine 10 kWh Batterie mit BatDummy. Nach den ersten Tagen sieht man schon Frühling mit schlechten Tagen zieht den schon leer.
Gruß Bison
Nabend zusammen,
in meinem contrib liegt die V 1.17.0 zum Test bereit.
Ich habe die OpenMeteoDWD-API integriert:
ZitatOpenMeteoDWD-API
Open-Meteo ist eine Open-Source-Wetter-API und bietet kostenlosen Zugang für nicht-kommerzielle Zwecke. Es ist kein API-Schlüssel erforderlich. Open-Meteo nutzt eine leistungsstarke Kombination aus globalen (11 km) und mesoskaligen (1 km) Wettermodellen von angesehenen nationalen Wetterdiensten. Diese API bietet Zugang zu den renommierten ICON-Wettermodellen des Deutschen Wetterdienstes (DWD), die 15-minütige Daten für kurzfristige Vorhersagen in Mitteleuropa und globale Vorhersagen mit einer Auflösung von 11 km liefern. Das ICON-Modell ist eine bevorzugte Wahl für allgemeine Wettervorhersage-APIs, wenn keine anderen hochauflösenden Wettermodelle verfügbar sind. Auf der Webseite des Dienstes ist die umfangreiche und übersichtliche API Dokumentation verfügbar.
FHEM nicht vergessen nach dem Download zu restarten.
Die API ist wie gewohnt auszuwählen. Ihr kennt das Setup ja schon ...
Die API bietet m.M.nach noch einiges an Potential. Zur Zeit habe ich die Strahlungsprognose implementiert.
Über die API beziehe ich auch schon die relevanten Wetterdaten (get ... solApiData zeigt es), sie sind aber noch nicht operational. Im nächsten Schritt könnte diese API auch das DWD Device bezüglich dieser Daten ersetzen. Weiterhin kann man auch noch Schneedaten hinzufügen. Das dürfte unsere Freunde aus Österreich und der Schweiz freuen (Open-Meteo ist ein Schweizer Dienst).
Und die KI-Integration wird vermutlich auch noch folgen können.
Auf der kurzfristigen Zeitachse können auch Strahlungswerte in 15-Minuten Taktung bezogen werden. Mit einem Abruflimit von 10000 Calls pro Tag! ist die Nutzung im Prinzip unbeschränkt.
Ich rufe die Daten alle 10 Minuten ab, das sollte reichen und die Server beim Anbieter schonen.
Ich bin gespannt auf die Ergebisse mit dieser API...
Grüße,
Heiko
Ich muss sagen, das man durch den Installationsprozess geleitet wird ist echt mega Hilfreich!
Hallo,
Zitat von: DS_Starter am 20 März 2024, 17:34:39Wenn es ein bisschen in die Schule gegangen ist, kann es dann so aussehen.... ;)
Es ist aber etwas Geduld gefragt! Die Korrekturwerte sind für jede einzelne Stunde abhängig von der prognostizierten Bewölkung, Strahlung und den realen Werten.
An der LED "Qualität" kann man das bisher erreichte Verhältnis zwischen Prognose und realem Ertrag der aktuellen Stunde nach einem Ampelsystem abschätzen.
bei mir steht immer "Abweichung heute: - "
Wie bekommt man denn die Anzeige "Abweichung fortlaufend: 8,4%" wie in dem Screenshot von Heiko oder die Werte für "Abweichung heute: -"?
Vielen Dank
oelidoc
Attr ctrlGenPVdeviation = continuously
LG
Zitat von: DS_Starter am 23 März 2024, 15:44:21Attr ctrlGenPVdeviation = continuously
LG
Aaah, wer sehen kann...
Danke!
Hallo Leute,
so einige Probleme konnte ich mittlerweile lösen. Heute habe ich einen neue Shelly (1PM mini) in Betrieb genommen.
Dieser liefert allerdings die Leistung bei der Erzeugung als Minuswert kann man das irgendwie invertieren sodass es
im SolarForcast Modul wieder genutzt werden kann?
Mit einem Userreading und der "abs"-Funktion kannst du einen positiven Wert erzeugen.
Hier ein Beispiel aus einem meiner Shellys:
power2:apower.* {abs(sprintf('%.2f',ReadingsNum($name,"apower",0)))}Gruß
Danny
Zitat von: Ingo298 am 23 März 2024, 16:44:09Hallo Leute,
so einige Probleme konnte ich mittlerweile lösen. Heute habe ich einen neue Shelly (1PM mini) in Betrieb genommen.
Dieser liefert allerdings die Leistung bei der Erzeugung als Minuswert kann man das irgendwie invertieren sodass es
im SolarForcast Modul wieder genutzt werden kann?
Zum Vorzeichen invertieren:
powerneg:apower.* {sprintf('%.2f',ReadingsNum($name,"apower",0)*-1.0)}
Kurze Info:
Ich muß sagen das die OpenMeteo-Prognose bis jetzt einen wirklich guten Eindruck macht, was die Genauigkeit angeht.
Läuft ja erste ca. 24h, aber sieht echt vielversprechend aus.
Mal weiter beobachten.
kann mich kask nur anschließen:
läuft erst 2 h, es ist zwar hier kein "idealer Sonnentag", aber Forecast wesentlich besser vs. ForecastSolar !!!
Danke erwin !
Moin,
ZitatIch muß sagen das die OpenMeteo-Prognose bis jetzt einen wirklich guten Eindruck macht, was die Genauigkeit angeht.
Läuft ja erste ca. 24h, aber sieht echt vielversprechend aus.
Das kann ich wie erwin bestätigen. Ich gehe sogar soweit zu behaupten, dass die Witterungsverhältnisse schneller und spezifischer geliefert werden als mit MOSMIX-S!
Meine Beobachtung basiert darauf, dass ich inzwischen auch die Möglichkeit geschaffen habe das Wetterdevice (Attr ctrlWeatherDev1) auf den OpenMeteo-Dienst umstellen zu können.
Wenn so gesetzt, werden sowohl die Strahlungsdaten als auch die Wetterdaten von OpenMeteo bezogen und ausgewertet. Dann sieht man die Unterschiede zum DWD Device mit MOSMIX-X.
Vllt. bekomme ich noch heraus, ob es evtl. Sinn macht bei MOSMIX-X einen anderen Kennwert für die WeatherID zu benutzen (wenn es den gibt). Der Vorteil von OpenMeteo kann natürlich darauf basieren, dass das DWD ICON Modell statt MOSMIX benutzt wird.
Laut DWD Doku:
ZitatDas vollautomatische MOSMIX-Verfahren des DWD optimiert und interpretiert die Berechnungen der numerischen Modelle ICON des DWD und IFS des EZMW, kombiniert diese und berechnet statistisch optimierte Wettervorhersagen in Form von Punkt-Termin-Prognosen (PTP).
MOSMIX ist demnach eine Mischung aus ICON und EZMW, dem deterministischen Prognosen des IFS-Modells (Integrated Forcasting System, math. Modell und Software) des EZMW.
Aber ich bin kein Experte und versuche nur für meine Beobachtungen eine nachvollziehbare Begründung zu finden.
In meinem contrib liegt ein Update der V1.7.0 welches diese Weiterentwicklungen enthält.
Seht auch die Hilfe zum Attr ctrlWeatherDevX und Setter currentRadiationAPI.
(Wie immer Restart nicht vergessen)
Edit: gerade nochmal eine kleine Änderung ergänzt und der
Hinweis, dass ich die Anlagenprüfung noch anpassen muß. Falls dort also bei der Verwendung von OpenMeteo noch ein paar Fehler gemeldet werden könnt ihr das irgnorieren.
Grüße,
Heiko
@erwin,
auch bei mir ist die ForecastSolar-API der Dienst mit den schlechtesten Ergebnissen.
Es hat sich durch diverse Maßnahmen im Modul schon ziemlich gebessert, ist aber dennoch deutlich hinter den anderen Möglichkeiten (bei mir) einzuordnen.
LG
Gibt es überhaupt einen bei dem die ForecastSolarAPI gut funktioniert? Also besser wie andere API's?
Ich meine von den Leuten die auch die anderen API's testen können bzw. getestet haben.
Es scheint ja Orte (vermutlich z.B. Österreich) zu geben bei der nur ForecastSolarAPI überhaupt brauchbar geht.
Aber selbst mit einer 10 Abfragen/Tag Solcast kommen bei mir viel bessere Resultate.
Und wie ich das so mitbekomme, lese ich das so auch von anderen, immer mal wieder.
Mal ein kurzes Ranking der API's (habe alle parallel laufen mit Autokorrektur + KI wo möglich).
Der Tag war teils trübe, teils mit sonnigen Abschnitten und recht schnell wechselnden Abschnitten,
also durchaus herausfordernd.
Stand jetzt sieht es bei mir für den heutigen Tag so aus:
- OpenMeteoDWDAPI -> -0,2 %
- DWD -> -3,2 %
- VictronKiAPI -> -5,2 %
- SolCastAPI -> -6,5 %
- ForecastSolarAPI -> -7 %
OpenMeteoDWDAPI bekommt volle Punktzahl. :)
Aber auch sonst sieht es eigentlich durchweg ganz gut aus. Außer bei OpenMeteoDWDAPI ist überall DWD mit MOSMIX_S der Wetterdienst.
Wen es interessiert ...
Ich habe gerade gelesen, dass es die Möglichkeit gibt einen eigenen Open-Meteo Server mit dem Zugriff auf eine Auswahl nationaler Wetterdienste zu installieren und zu betreiben.
Das System steht als Docker Installation oder Ubuntu Image zu Verfügung.
Alles Open Source: https://github.com/open-meteo/open-meteo/blob/main/docs/getting-started.md
Im Prinzip gäbe dieser Dienst eine hervorragende Grundlage für ein Open-Meteo Modul.
Wenn sich die hohe Präzision manifestiert wäre Open-Meteo m.M. nach unschlagbar für Wetter Vorhersagen aller Art. Noch dazu kostenfrei für nicht-kommerzielle Anwendung.
Ich bin bis jetzt wirklich angetan. 8)
Hast du irgend wann was geändert in bezug auf die autocorrection und die Konfig?
Alle Module standen bei mir auf "no_learning". Ich kann mich aber nicht erinnern alle ausgeschaltet zu haben.
Hallo Heiko,
ZitatEdit: gerade nochmal eine kleine Änderung ergänzt und der Hinweis, dass ich die Anlagenprüfung noch anpassen muß. Falls dort also bei der Verwendung von OpenMeteo noch ein paar Fehler gemeldet werden könnt ihr das irgnorieren.
Meinst du sowas hier?
Unbenannt.PNG
Woher weiss OpenMeteo als WeatherDevice wo ich wohne?
Und macht es Sinn mehrere WeatherDevices anzugeben?
Gruß
oelidoc
ZitatHast du irgend wann was geändert in bezug auf die autocorrection und die Konfig?
Alle Module standen bei mir auf "no_learning". Ich kann mich aber nicht erinnern alle ausgeschaltet zu haben.
Nein, nicht angefasst. Gab bei mir auch keine Probs dergleichen.
@oelidoc
global attribute?!
@DS_Starter
Dann habe ich das vergessen wieder einzupflegen nach dem update am 25.02. Doof!
ZitatWoher weiss OpenMeteo als WeatherDevice wo ich wohne?
Aus den global longitude/latitude/altitude Angaben.
ZitatUnd macht es Sinn mehrere WeatherDevices anzugeben?
Würde ich bezweifeln. Vllt. sogar kontraproduktiv wenn man die hohe Präzision von Open-Meteo mit anderen, vllt. nicht so präzisen Daten, vermischt.
@oelidoc,
deine Dateianhänge kann ich nicht gleich öffnen ... komisch.
Jetzt hat es funktioniert ...
ZitatMeinst du sowas hier?
Ja, genau -> ignore it.
Okay, dann schmeiss ich das zweite Weather Device wieder raus und setze bis auf weiteres erst mal ganz auf OpenMeteo.
Vielen Dank für das Modul und die schnellen Antworten - wirklich super!
Gruß
oelidoc
Zitat von: DS_Starter am 24 März 2024, 19:06:29Zitat@oelidoc,
deine Dateianhänge kann ich nicht gleich öffnen ... komisch.
Hab ich auch aktuell immer bei den Anhängen - auch an anderer Stelle.
Vermute das der FHEM-Server irgendwelche Probleme hat??
Teilweise bekomme ich auch gar keine oder sehr späte Benachrichtigungen über neue Beiträge zugestellt. :(
[/quote]
ZitatTeilweise bekomme ich auch gar keine oder sehr späte Benachrichtigungen über neue Beiträge zugestellt. :(
Bei mir auch so. Habe es bereits Otto123 (wir sehen uns regelmäßig beim Leipzig Stammtisch) mitgeteilt. Er betreut das Forum (Server/Software). Problem ist bekannt, Fix steht noch aus.
In meinem contrib liegt ein Update der V1.17.0.
Für die neue API ist die Integration in den Anlagencheck erfolgt.
Ab jetzt die Infos/Warnings wieder ernst nehmen. ;)
Grüße,
Heiko
Hi Heiko,
bräuchte etwas input zum neuen OpenMeteoAPI.
Habe mir gerade V1.17.0 heruntergeladen und auf OpenMeteo umgestellt.
Habe aber auch noch:
ctrlWeatherDev1 DWD_Birkenau
ctrlWeatherDev2 DWD_Weiher
Muss/sollte ich die löschen?
Außerdem sagt mir der Check:
The selected SolarForecast model cannot use AI support.
Ist das richtig. Kein AI für OpenMeteo? :-(
Gruß,
Stefan
Hallo Stefan,
ZitatHabe aber auch noch:
ctrlWeatherDev1 DWD_Birkenau
ctrlWeatherDev2 DWD_Weiher
Muss/sollte ich die löschen?
Müssen nicht ... sollte
Ja! ... ähmm ... vielleicht. Muß man mal testen was besser ist bzw. mehrere in dem Kontext etwas bringt.
ZitatAußerdem sagt mir der Check:
The selected SolarForecast model cannot use AI support.
Ist das richtig. Kein AI für OpenMeteo?
Doch AI kommt. Habe bereits die 1.17.1 mit AI im Test.
In der 1.17.0 ist es halt noch nicht drin. ;)
Grüße,
Heiko
Hi Heiko,
hatte ein Problem mit FHEM.
Die neue Version mit OpenMeteoAPI und ohne DWD und ctrlWeatherDev1 OpenMeteoDWD-API hat dazu geführt dass mein Perl irgendwann bei 100% hing.
Stoppen und starten hat nichts gebracht.
Sofort nach dem Start wieder bei 100%.
Konnte mir nun nur helfen indem ich SolarForecast wieder gedowngraded habe.
Leider kann ich nichts im Log sehen.
Kann ich bei der Analyse helfen?
Verbose 5?
Gruß,
Stefan
Hallo Heiko,
ich habe das gleiche Problem wie Stefan. Es sieht so aus als wenn Perl ab dem Tageswechsel auf 100% hing.
Grüße
Jens
Hi Heiko,
ich kann Stefan's Beobachtungen bestätigen...
von vorgestern auf gestern: perl process auf 100% genau um Mitternacht .. ich dachte an Zufall ...
von gestern auf heute: perl process auf 100% genau um Mitternacht
kill - Neustart bringt nix, sofort wieder auf 100%
kill - löschen Solarforcast - start ok - neu-def (mit gleichen Namen/Param) - 100% cpu
kill - löschen Solarforcast - start ok - neu-def mit andern dev-namen, gleichen param - ok bis zur nächste Mitternacht.
defs : solarfc -> ICON, wetter -> icon
Bild info:
-FCtime 2024-03-25 23:51:04
-OpenMeteo: 2024-03-25 23:51:04
-last update: 2024-03-26 00:01:52
... werde weiter beobachten
l.g. erwinSolarforecast.png
PS: jetzt noch einen Versuch:
-kill - selbe Konfig ABER: ctrlWeatherDev1 auf myDWD_OpenData geändert... fhem kommt hoch ohne Problem..
Habe das selbe Problem.
Der Perl prozess scheint zu hängen.
Keinerlei Probleme in den system logs zu sehen.
Ein "service fhem stop" & "service fhem start" bringt fhem wieder hoch.
Habe OpenMeteoDWD-Api als ctrlWeatherDev1.
Da fällt mir ein Wir hatten das auch schon einmal mit dem dwd forcast und den ersten schritten mit der KI in dem Modul.
Da war auch um 0 Uhr schluß mit lustig. Da hat fhem 1h lang immer neugestartet (wenigstens, jetzt sieht man nix mehr).
War wohl damals ein Problem mit der Uhrzeit (Deutschland +1h).
Weiß das nicht, mehr genau wie das war.
Moin,
kann eure Meldungen bestätigen. Wegen der Meldung mal in meine CPU-Loggings geschaut.
Kurz nach 00:00 100% , endet ab ca. 01:00.
Das ist jetzt eine unschön auch in Bezug auf die Fehlersuche. Im Log wird man nichts sehen weil ja nichts mehr geloggt werden kann.
Ich melde mich wieder.
Grüße,
Heiko
Hallo Heiko,
wie wär's mit einem ,,optimierten" Link auf den letzten neuen Eintrag im Anzeigekopf ?
Dann würde es auch bei denjenigen besser treffen die ans Ende der Einträge müssen bzw. Einträge anders sortiert anzeigen lassen.
Oder spricht da was gegen...?
https://forum.fhem.de/index.php?topic=137058.new#new
Kommt mit in die nächste Version. Danke 300P.
Begebe mich jetzt erstmal auf Problemsuche ...
Ehrlich gesagt weiß ich nicht ob das so schlau ist.
Ich habe das wie folgt begründet warum du auf den Thread linkst:
-Du hast ein neuen Thread erstellt wo es nur um das Modul selbst geht. Damit steuerst du die Leute vereinfacht in den Thread.
-Du erleichterst dem neuen Modul-User die Kontaktaufnahme, da er dann direkt weiß wo er was schreiben muß.
Und keinen neuen Thread aufmacht den du erstmal finden mußt zum supporten.
Warum ich das mit dem 'new' nicht gut finde ist, das der neue User dann irgend wohin geleitet wird wo erst einmal (vermutlich) kein Zusammenhang zu seinem aktuellen Problem erkennt.
Außerdem weiß der alte User das man oben mal eben auf z.B. Seite 18 klicken kann.
Der neue User sieht dann im ersten Post des Threads direkt das er da richtig ist mit Problemen um das Modul.
So mein Gedankengang. Ich würde mir das also überlegen das wirklich auf den neusten Post zu linken. Weil das ist auch nur interresant wenn man wirklich aktiv am geschen teilgenommen hat. Ansonsten heißt es eh wieder zurück blättern um den Anschluß zu finden.
Also ich würde mir das noch einmal überlegen. Bestandsuser beglücken oder Newbies den Einstieg erleichtern!
Ich bin da eher beim Welpenschutz und würde das lassen wie es ist.
Aber das obliegt alles dem Ersteller des Modules.
Also Heiko, mach was'se willst und für dich am besten/schlüssigsten ist ;)
Deine Sichtweise hat mich auch überzeugt. Passt.
Als Lösungsansatz.
Du könntest ein attr einpflegen.
Sowas wie "opennewestforumpost" der aktiv angelegt werden muß. wenn das attr nicht da (standard) dann 0 ansonsten 1|0.
Bei 1 addest du halt die paar zeichen (.new#new) an den link.
Somit linkst du erstmal auf den Topic und für die Bestandkunden ist das dann auswählbar wo es hin geht.
Frist ja kein Brot die 4 Zeilen quelltext mehr.
Überlege ich mir noch. Die Lösung des CPU Problems hat erstmal Prio.
Zitat von: DS_Starter am 26 März 2024, 18:25:50..
Begebe mich jetzt erstmal auf Problemsuche ...
Ich habe das noch einmal bei mir analysiert was heute morgen passiert ist.
Ab 00:06 geht meine CPU hoch und sinkt wieder ca. 00:29. Also ca. 25min. Fhem selbst hing aber heute morgen noch, bzw. reagierte nicht mehr. Keine DB_Logs ab 01:00.
der letzte DBlog eintrag meiner devices die Signalduino nutzen waren 2024-03-25 23:59:57. Das hätte spätestens nach 15min ein neuer Eintrag auftauchen müssen.
Bis 2024-03-26 00:08:05 liefert der fhem interen mqtt-broker noch Daten (Da rasselt es nur so an logs normalerweise). Deconz lieferte das letzte mal Einräge im DBlog um 2024-03-26 01:00:39.
Also stirbt so nach und nach alles weg.
Edit: um 06:15 kommen wieder deconz Einträge. Also da lebte doch noch was, oder wieder was.
Habe um 06:55 fhem restartet.
Ich vermute einen Sperrzustand oder eine Schleife, wobei ich momentan einen Sperrzustand beim gleichzeitigen File-Write favorisiere. Wird sich heute zeigen.
Ich habe bei mir auf OS-Ebene einen Überwachungsmechanismus eingebaut. Er überprüft ob FHEM noch reagiert und ansonsten nach X Minuten FHEM automatisch restartet.
Wenn ich nicht das Log sichte, merke ich morgens nichts davon dass zwischen 0-1 dieser Zustand eingetreten ist (wenn ich nicht gerade solange auf bleibe).
Was ich schon weiß, der AI Learning Vorgang ist es nicht. Er läuft auch in der Stunde ab Mitternacht.
Waaaas? Keine mail, push oder sonstwas Nachricht das dein System macht was es will bzw. nicht macht was es soll?
Das ist doch Blasphemie.
So ein reset wüßte ich schon gerne wenn das einfach so passiert.
Gerade automatisiert wie bei Dir mit einer Überwachungsfunktion und nicht erst nach dem durchforsten von Logs.
Das kost doch Zeit. Gucken, ahhh war nix, ok!. Das 3 Tage lang und dann wird nur noch spradisch geschaut und irgend wann garnicht mehr. Und nach 3 wochen stellt man fest das das System jeden nacht x mal restartet. Ab da guckt man dann wieder täglich, dann sporadisch.
Da kannst du ja froh sein das du hier die User hast die das für dich überwachen und melden ;)
:)
Wenn es "normal" restartet bekomme ich eine Nachricht über meinen Synology Chat. Aber dafür muss FHEM zumindest in der Lage sein nach dem Restart eine Message abzusetzen, was im vorliegenden Fall offensichtlich nicht der Fall war.
Ansonsten passt das schon.
Fehler gefunden ... es war eine Schleife die nur zu Beginn eines Tages zum Tragen kam.
Böse Falle.
Ich finalisiere im Laufe des Tages die gefixte V und gebe euch Bescheid.
Grüße,
Heiko
Hallo,
ich habe bei mir 3PV Anlagen mit dem Modul konfiguriert. Ich habe zusätzlich ein BHKW dass auch Strom erzeugt. Gibt es eine möglichkeit diese auch mit einzubinden?
Gruß
Hallo,
ich habe bei mir 3PV Anlagen mit dem Modul konfiguriert. Ich habe zusätzlich ein BHKW dass auch Strom erzeugt. Gibt es eine möglichkeit diese auch mit einzubinden?
Gruß
Hallo Scank,
Jein!
Ich hab eine ähnliche Situation bei mir. Mehrere WR und mehrere Batterien plus ein kleines BHKW für meine Grundlast bei mir (wenn die Sonne mal nicht so richtig ,,will") wird zugeschaltet.
Meine Lösung vor einiger Zeit war dann recht simpel und ist im Wiki hinterlegt. Einfach zu dem PV-Erzeugungs-Summen-Dummy die Erzeugung des BHKW hinzuaddieren.
Dann wird damit zwar nicht ganz so viel damit berechnet, aber im Winter und in der Nacht scheint dann das Sonnensymbol der Grafik. 8)
Ist zwar keine komplette Luxuslösung mit allem drum und dran, aber es stört die Berechnungen des Modules für die PV nicht.
Gruß
300P
Warum willst du ein BHKW einbinden? "BlockHeizKraftWerk"!
Oder meinst du ein BKW "Balkonkraftwerk"?
Ein BKW kannst du einbinden. Warum sollte das nicht gehen?
Hallo zusammen,
in meinem contrib liegt die V 1.17.1.
Enthalten sind folgende Entwicklungen:
- ganz wichtig ... fix CPU Problem !!!
- die OpenMeteoDWD-API ist KI fähig. Die entsprechenden Set/Get-Befehle sind verfügbar.
In dem Zusammenhang wurde die KI Raw Datenstruktur zw. DWD und OpenMeteoDWD-API harmonisiert.
- neues Attribut "ctrlAIshiftTrainStart". Damit kann man die Tainingszeit der KI in eine gewünschte Stunde
legen (default: 1). Das Attr ist ein "Abfallprodukt" der Fehlersuche, aber praktisch zu gebrauchen.
- die Spezialaktivitäten in der Zeit 00-01 wurden besser geclustert um die Belastung zu dieser Zeit
besser zu verteilen. (Auch ein Ergebnis des Bugfix)
Wen die Ursache des CPU Problems interessiert...
Man sollte eine Schleife NICHT so bauen wenn man eine next-Bedingung prüft:
my $k = 0;
while ($jdata->{hourly}{time}[$k]) {
($err, my $pvtmstr) = timestringUTCtoLocal ($name, $jdata->{hourly}{time}[$k], '%Y-%m-%dT%H:%M');
......
......
next if(timestringToTimestamp($pvtmstr) < $refts);
......
......
$k++;
}
Sondern in der Next-Bedingung auch die Erhöhung des Schleifenzählers nicht vergessen:
my $k = 0;
while ($jdata->{hourly}{time}[$k]) {
($err, my $pvtmstr) = timestringUTCtoLocal ($name, $jdata->{hourly}{time}[$k], '%Y-%m-%dT%H:%M');
......
......
if (timestringToTimestamp($pvtmstr) < $refts) {
$k++;
next;
}
......
......
$k++;
}
Leicht zu erkennen wenn man es einmal gefunden hat. ;)
Nach dem Download FHEM Restart nicht vergessen!
Grüße,
Heiko
die OpenMeteoDWD-API ist KI fähigdafür muß man doch den pvCorrectionFactor_Auto auf "on_complex_ai" stellen, oder?
Zitat von: kask am 27 März 2024, 17:48:54die OpenMeteoDWD-API ist KI fähigdafür muß man doch den pvCorrectionFactor_Auto auf "on_complex_ai" stellen, oder?
Laut Hinweisen zum Attr :Model OpenMeteoDWDAPI:
[s]Die empfohlene Autokorrekturmethode ist on_complex.[/s]
mmmh das ergibt leider in der Anzeige aber einen Hinweis :
Zitatdafür muß man doch den pvCorrectionFactor_Auto auf "on_complex_ai" stellen, oder?
Wenn man die Ergebnisse/Antworten der KI nutzen will, ja.
Aber die muß erst noch trainieren.
Zur Zeit / zu Beginn ist der Trainigszustand nicht/kaum vorhanden -> on_complex nutzen.
on_complex_ai geht jetzt natürlich auch, wird aber noch nichts bringen.
EDIT: die Hilfe zum Set pvCorrectionFactor_Auto passe ich an! -> Update liegt im contrib
Ich muß für mein Verständniss jetzt noch einmal nachfragen.
Bei on_simpel/on_complex läuft der Decissiontree(ki) immer mit bzw. lernt.
Bei "_ai" wird der KI-Wert genommen. Dann läuft das sozusagen autonom?
Edit:
Noch eine Frage.
was sagt mir folgendes?
Zitat2024.03.27 18:31:04.067 5: DWD: ProcessAlerts: parsing XML document
Die OpenMeteo-API war bei mir heute auch wieder sehr überzeugend.
Interessant ist der Unterschied in der Wetterprognose zwischen OpenMeteo-API und DWD (MOSMIX_S).
Bin gespannt wer morgen Recht hat bzw näher an der Realität sein wird. ;)
Ich habe übrigends noch 2 Fakts vergessen:
- bei OpenMeteo-API wird nicht nur die Wettervorhersage, sondern auch die aktuelle Bewölkung und der Wettercode der aktuellen Stunde genutzt.
- das Standard Wettermodel der OpenMeteo-API ist jetzt "DWD ICON Seamless". Seamless kombiniert alle Modelle eines bestimmten Anbieters (hier DWD) zu einer nahtlosen Vorhersage. Genutzt für den Mix wird DWD ICON D2, DWD ICON EU, DWD ICON Global.
Ich habe noch vor das Modell "Best match" mit anzubieten. Best Match bietet die beste Vorhersage für jeden beliebigen Ort weltweit.
ZitatBei on_simpel/on_complex läuft der Decissiontree(ki) immer mit bzw. lernt.
Ja, alle Varianten (simple, complex, KI) werden pro Stunde kalkuliert und gespeichert unabhängig davon ob sie momentan genutzt werden.
Sobald eine Variante ausgewählt wird, erfolgt durch das System die entsprechende Auswahl/Kalkulation des Forecast.
Man kann mit dem Setter pvCorrectionFactor_Auto dynamisch (z.B. bei bestimmten Bedingungen) zwischen den Verfahren umschalten. Kein Problem.
ZitatBei "_ai" wird der KI-Wert genommen. Dann läuft das sozusagen autonom?
Ein bisschen mehr.
Die Ki wird abgefragt. Liefert sie keinen Wert, wird auch noch mit einer Streuung um den Strahlungswert herum abgefragt und eine Näherung ermittelt.
Alle gelieferten KI Werte werden mit der jeweiligen API-Prognose verglichen. Ist die Abweichung nicht höher als ein von mir definierter Schwellenwert, wird die KI-Prognose verwendet, anderenfalls die API-Prognose.
Insbsondere in der Anfangszeit kam/kommt es vor dass die KI starke Ausreißer zeigt. Das Verfahren soll das verhindern.
ZitatDWD: ProcessAlerts: parsing XML document
Ist aus dem DWD Modul und sagt dass der Step "Durchsuchen der MOSMIX Datei" läuft. Mehr nicht.
Vllt. noch ein interessanter Hinweis.
Vergleicht man zwei SF-Devices, eins mit Attr ctrlWeatherDev1=OpenMeteoDWD-API und das zweite mit ctrlWeatherDev1=DWD, ergeben sich für Rad1h in der Übersicht "get ... solApiData" voneinander abweichende Werte für die gleiche Anlage.
Das ist kein Fehler, sondern folgt daraus dass DWD Globalstrahlung (GI) liefert und OpenMeteo die Global Tilted Irradiance (GTI), also die Globalstrahlung auf die geneigten Kollektoren. Diese Werte wirde aus den Angaben (moduleAzimuth, moduleDeclination) übermittelt.
Ich denke noch darüber nach wie ich den Speicher anpassen kann, damit beim Wechsel der Wetter-API die gelernten Werte der KI auch auf das andere Modell passen.
Ich vermute das ist nicht so trivial lösbar. Da die Werte sich bei jeder Anlagen unterscheiden werden.
Man könnte eventuell dev2 mit einem dwd device füttern und korrektur faktoren dafür hinterlegen zum lernen.
Nach ein paar Tagen lernen sollten die Korrekturfaktoren eventuell übernommen werden können für eine umschaltung zwischen beiden.
Ich denke ein umschalten ohne lernen (mit festen parametern zur umrechnung) wird nicht funktionieren.
Wenn du was gegen die empirische ermittlung hast dann könntest du aus dem Sonnenstand/Neigungswinkel/Ausrichtung theoretisch einen Umrechnungsfaktor kalkulieren.
Aber auch dafür müßtest du erst einmal sammeln für eine "Faktorenliste". Da sich der Umrechnungsfaktor ja nach Tageszeit ändern wird.
Mal schauen. Intern habe ich ein Umrechnungsschema mit Flächenfaktoren nach Junge: http://www.ing-büro-junge.de/html/photovoltaik.html
Muß die Ergebnisse mal vergleichen.
Dann müßtest du aber eins von beiden umrechnen, schon beim ermittelen der Werte und dann wieder beim zurückrechnen.
Das ist dann aber auch nicht mehr on-the-fly momentan.Weil dann musst du mindestens eine History neuanlegen.
Warum willst du überhaupt umschalten können?
Nicht unbedingt. Irgendwann entscheidet man sich ja für eine Variante. Außerdem lernt die KI dann wieder neu dazu. War nur so eine Idee ...
[Gelöst -> #296]
Nach den hier dokumentierten sehr positiven Erfahrungen mit openMeteo habe nun nach dem Neustart seit 18 Stunden im Minutenabstand eine angemeierte verweigerte Connection:
2024.03.28 07:16:54 1: SolarVorschau - Open-Meteo DWD ICON API server response: DNS write error: Connection refused
2024.03.28 07:18:04 1: SolarVorschau - Open-Meteo DWD ICON API server response: DNS write error: Connection refused
2024.03.28 07:18:13 4: SolarVorschau - The working memory >circular pvhist solcastapi< has been saved to persistance
2024.03.28 07:19:14 1: SolarVorschau - Open-Meteo DWD ICON API server response: DNS write error: Connection refused
2024.03.28 07:20:24 1: SolarVorschau - Open-Meteo DWD ICON API server response: DNS write error: Connection refusedRuhe ich diesen die API aus dem Browser auf bzw. den String aus dem Programm, erhalte ich eine Server-Response.
VERSION 1.17.1
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes unused
VERSION_SMUtils 1.27.1Wie kann ich das weiter aufklären?
Danke für Hinweise
Christian
Morgen Christian,
im Prinzip hast du folgende Möglichkeiten zur Analyse:
1. den Anlagencheck durchführen. Am schnellsten über das Icon im Grafikkopf.
2. das Attr ctrlDebug = apiCall setzen
Der Aufruf wird im Log protokolliert und sieht im Erfolgsfall so aus:
2024.03.28 08:15:07.405 1: openMeteo DEBUG> Open-Meteo DWD ICON API Call - Request for PV-String "Süddach" with weather model >DWD ICON Seamless<:
https://api.open-meteo.com/v1/forecast?models=icon_seamless&latitude=.....&hourly=temperature_2m,rain,weather_code,cloud_cover,is_day,global_tilted_irradiance_instant¤t=temperature_2m,weather_code,cloud_cover&minutely_15=global_tilted_irradiance&daily=sunrise,sunset&forecast_hours=48&forecast_days=2&tilt=45&azimuth=0
2024.03.28 08:15:07.406 2: HttpUtils url=https://api.open-meteo.com/v1/forecast?models=icon_seamless&latitude=..........&hourly=temperature_2m,rain,weather_code,cloud_cover,is_day,global_tilted_irradiance_instant¤t=temperature_2m,weather_code,cloud_cover&minutely_15=global_tilted_irradiance&daily=sunrise,sunset&forecast_hours=48&forecast_days=2&tilt=45&azimuth=0 NonBlocking via https
2024.03.28 08:15:07.407 1: IP: api.open-meteo.com -> 188.40.99.226
2024.03.28 08:15:07.442 2: HttpUtils request header:
GET /v1/forecast?models=icon_seamless&latitude=..........&hourly=temperature_2m,rain,weather_code,cloud_cover,is_day,global_tilted_irradiance_instant¤t=temperature_2m,weather_code,cloud_cover&minutely_15=global_tilted_irradiance&daily=sunrise,sunset&forecast_hours=48&forecast_days=2&tilt=45&azimuth=0 HTTP/1.0
Host: api.open-meteo.com
User-Agent: fhem
Accept-Encoding: gzip,deflate
Accept: application/json
2024.03.28 08:15:07.475 1: https://api.open-meteo.com/v1/forecast?models=icon_seamless&latitude=.......&hourly=temperature_2m,rain,weather_code,cloud_cover,is_day,global_tilted_irradiance_instant¤t=temperature_2m,weather_code,cloud_cover&minutely_15=global_tilted_irradiance&daily=sunrise,sunset&forecast_hours=48&forecast_days=2&tilt=45&azimuth=0: HTTP response code 200
2024.03.28 08:15:07.477 2: HttpUtils https://api.open-meteo.com/v1/forecast?models=icon_seamless&latitude=.......&hourly=temperature_2m,rain,weather_code,cloud_cover,is_day,global_tilted_irradiance_instant¤t=temperature_2m,weather_code,cloud_cover&minutely_15=global_tilted_irradiance&daily=sunrise,sunset&forecast_hours=48&forecast_days=2&tilt=45&azimuth=0: Got data, length: 7596
2024.03.28 08:15:07.478 2: HttpUtils response header:
HTTP/1.1 200 OK
Date: Thu, 28 Mar 2024 07:15:07 GMT
Content-Type: application/json; charset=utf-8
Connection: close
Content-Encoding: deflate
2024.03.28 08:15:07.479 1: openMeteo DEBUG> Open-Meteo DWD ICON API Call - server response for PV string "Süddach"
2024.03.28 08:15:07.480 1: openMeteo DEBUG> Open-Meteo DWD ICON API Call - request time: 2024-03-28 08:15:07 (1711610107)
2024.03.28 08:15:07.481 1: openMeteo DEBUG> Open-Meteo DWD ICON API Call - status: success
Grüße,
Heiko
Guten Morgen,
nach einem notwendigen Neustart vom RPI grad mal im Log nachgesehen (konnte nicht FHEM per Browser aufrufen):
Ist Anscheinend aber kein Hänger von SF ?? - => externe SQL-Datenbank wurde weiter die ganze Nacht mit Daten gefüllt
Hab nur einen einzigen Fehlereintrag (2024.03.28 01:15:09) zu SF gefunden:
Und der Brunnenstart (2024.03.28 08:00:19) wurde auch geloggt.
(Die Leerzeile hab ich nicht extra eingefügt - war so im Logbuch enthalten)
2024.03.28 00:00:01 2: Deleting DOIFtoolsLog-2024-084.log
2024.03.28 01:05:11 2: Deleting fhempy-2024-03-17.log
2024.03.28 01:15:09 1: Forecast - aiTrain ERROR: Must add training instances before calling train() at ./FHEM/76_SolarForecast.pm line 13718.
2024.03.28 01:48:38 2: VCONTROL300: Error while sending command for parameter 0808 (Status 0x15) : Retry 0!!!
2024.03.28 01:48:39 2: VCONTROL300: Error while sending command for parameter 0808 (Status 0x15) : Retry 1!!!
2024.03.28 01:48:45 1: Timeout for VCONTROL300_DoUpdate reached, terminated process 171798
2024.03.28 01:53:45 1: Timeout for VCONTROL300_DoUpdate reached, terminated process 172602
2024.03.28 01:58:45 1: Timeout for VCONTROL300_DoUpdate reached, terminated process 173393
2024.03.28 08:00:19 2: Forecast - Consumer '_Brunnen' was external switched on
2024.03.28 08:26:09 2: myDbLog - Wait for last database cycle due to shutdown ...
2024.03.28 08:26:09 1: Server shutdown delayed due to myDbLog for max 10 sec
2024.03.28 08:26:10 2: myDbLog - Last database write cycle done
2024.03.28 08:26:10 0: Server shutdown
2024.03.28 08:26:11 2: myDbLog - stopping SubProcess PID >101349< ...
2024.03.28 08:26:11 2: myDbLog - SubProcess PID >101349< stopped
2024.03.28 08:26:26 1: Including fhem.cfg
2024.03.28 08:26:29 2: myDbLog - Subprocess >947< initialized ... ready for non-blocking operation
2024.03.28 08:26:30 2: eventTypes: loaded 8100 lines from ./log/eventTypes.txt
Mal schauen was der nächste Tag bringt.
Zu Info:
pvCorrectionFactor_Auto steht auf "on_complex"
Gruß
300P
Guten Morgen,
Danke für den Fix, läuft !!! Forcast war gestern nahe perfekt, trotz komplexer Wetterbedingungen: Sonne, Wolken, Regen abwechselnd - eher April-Wetter!
mein Kommentar zu ...liefert OpenMeteo die Global Tilted Irradiance (GTI) vs: Gloabal Irridiance:
Die GTI ist für den Solar-Ertrag die entscheidende! Die Umrechnung ist nicht trivial, weil GI (m.Meinung nach) bereits eine Berechnung aus Solarstrahlung auf eine Fläche (Erdboden) ist.
l.g. erwin
@300P,
nein, gibt keine Hänger. Bei mir gecheckt und auch keine sonstigen Abnormitäten feststellbar.
Der train Error kann! ok sein wenn es keine Instanzen für die KI gab.
Kannst du aber nachstellen:
1. ctrlDebug=aiProcess einstellen
2. get ... valDecTree aiRawData -> es sollten (jetzt) Daten vorhanden sein
3. set ... aiDecTree addRawData
4. set ... aiDecTree addInstances
5. set ... aiDecTree train
Im Log sollte dann etwa folgendes erscheinen:
2024.03.28 09:46:50.021 1: openMeteo DEBUG> AI raw add - 41 entities added to raw data pool (set verbose 4 for output more detail)
2024.03.28 09:46:50.083 1: openMeteo DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_openMeteo
2024.03.28 09:46:57.580 1: openMeteo DEBUG> AI Instance add - 41 entities added for training (set verbose 4 for output more detail)
2024.03.28 09:47:20.536 1: openMeteo DEBUG> AI Training is started in main process
2024.03.28 09:47:20.581 1: openMeteo DEBUG> AI trained number of entities: 41
2024.03.28 09:47:20.582 1: openMeteo DEBUG> AI trained and saved data into file: ./FHEM/FhemUtils/AItra_SolarForecast_openMeteo
2024.03.28 09:47:20.582 1: openMeteo DEBUG> Training instances and their associated information where purged from the AI object
LG
Hab erst spät am Abend das letzte Update von deinem Contrib gezogen... vielleicht dann daher.
Ich mache erst mal "nix" und warte ab was morgen früh los ist.
Gruß
300P
Allgemeine Frage ... benutzt jemand das Attr affectMaxDayVariance?
Im Zuge der Weiterentwicklung ist es m.M. nach unnötig geworden und es reicht nach meinen Erfahrungen aus mit dem Defaultwert zu arbeiten.
Wenn es keine Gegenargumente gibt, würde ich es mal entfernen.
Zitat von: DS_Starter am 28 März 2024, 08:20:56...
1. den Anlagencheck durchführen. Am schnellsten über das Icon im Grafikkopf.
2. das Attr ctrlDebug = apiCall setzen
Der Aufruf wird im Log protokolliert und sieht im Erfolgsfall so aus:
...
Vielen Dank, Heiko, der Anlagencheck hatte mich nicht weitergebracht und das fein justierbare Attribut ctrlDebug hatte ich unverständlicherweise vergessen: Das zeigte dann auf httpUtils und damit fand ich meinen Fehler: Ein aus dem Vorsystem beim Rückspielen der Sicherung gezogener falscher globaler DNS-Eintrag. Jetzt löpt es!
Christian
@all,
in meinem contrib liegt die V1.17.2 mit integrierter OpenMeteoWorld-API:
OpenMeteoWorld-API
Als Variante des Open-Meteo Dienstes liefert die OpenMeteoWorld-API die optimale Vorhersage für einen bestimmten Ort weltweit. Die OpenMeteoWorld-API vereint nahtlos Wettermodelle bekannter Organisationen wie NOAA (National Oceanic and Atmospheric Administration), DWD (Deutscher Wetterdienst), CMCC (Canadian) und ECMWF (Europäisches Zentrum für mittelfristige Wettervorhersage). Für jeden Ort weltweit werden die besten Modelle kombiniert, um die bestmögliche Vorhersage zu erstellen. Die Auswahl der Wettermodelle erfolgt automatisch anhand der im API Aufruf enthalteten Standortkoordinaten.
Jetzt haben wir mit den Open-Meteo Diensten m.M. nach die Möglichkeit deutlich mehr als nur Deutschland abzudecken. Nun würde mich interessieren wie die Erfahrungen an den Standorten in Österreich/Schweiz aussehen.
Grüße,
Heiko
Dann schauen wir mal wie gut das mit der OpenMeteoWorld-API klappt (Und hoffen mal das wir das System nicht wieder abschissen ;) ).
Die OpenMeteoDWD-API funktioniert ja sehr gut.
Bisschen optimistisch ... ist zwar Ostern doch das Ei hatten wir doch schon. :)
Die Logik ist geblieben, nur der API Call ist entsprechend modifiziert.
Schauen wir mal wie sich die beiden Modelle entwickeln...
Ich hab heute früh upgedatet... vorgestern und gestern -4.9 / +4.5 deviation - finde ich gut für die ersten beiden Tage - bei dieser April-Wetterlage!!!
Ich beobachte weiter aus Ö!
l.g. erwin
Moin,
@DS_Starter
Ich habe jetzt auch auf contrib mit OpenMeteoWorld-API geupdatet.
Wie holst du location? Per "global" longitude + latitude?
Bzw muss ich es setzten oder funktioniert das automatisch?
Edit:
Ok, Seite 17 steht meine Antwort. Das hab ja gesetzt.
Gruß schwatter
Moin,
ja global longitude + latitude.
Das Modul meckert bei Anlagencheck wenn diese Attr im global nicht gesetzt sind.
Wenn gesetzt, läuft der Rest automatisch.
(ok, hat sich überschnitten)
Ok super,
und beim Anlagencheck wird gemeckert. Bei meinem DWD-Device.
Hat sich du das attr forecastResolution zu forecastRefresh geändert?
Dann muss ich bestimmt auch eine neue DWD aus deinem contrib ziehen?
Gruß schwatter
ZitatHat sich du das attr forecastResolution zu forecastRefresh geändert?
Die gibt es beide im DWD Modul. Haben unterschiedliche Bedeutung.
ZitatDann muss ich bestimmt auch eine neue DWD aus deinem contrib ziehen?
Ja, mit dem DWD Modul aus meinem contrib kannst du auf MOSMIX_S umstellen -> help DWD_OpenData en
PS: Ich muss mal wieder im OpenData Thread nachfragen wie der Status zum einchecken des DWD aussieht.
Ok,
dann hinke ich hinterher oder es wurde bei einem Update überschrieben.
Ich habe nur forecastResolution.
Ich updatete das Modul nochmal manual, Danke!
Gruß schwatter
Zitatoder es wurde bei einem Update überschrieben.
global exclude_from_update nutzen.
LG
Hallo,
muss ich eigentlich bei OpenMeteoDWD als Api und WeatherDev auch mit so einer hohen Schreiblast für meine SD karte rechnen wie bei DWD_OpenData MOSMIX S?
Und lohnt sich die WORLD Version für Deutschland?
Frohe Ostern
oelidoc
Zitatmuss ich eigentlich bei OpenMeteoDWD als Api und WeatherDev auch mit so einer hohen Schreiblast für meine SD karte rechnen wie bei DWD_OpenData MOSMIX S?
Nein, die Verarbeitung findet im RAM statt. Schreibvorgänge dienen lediglich der Sicherung der Daten. Sie sind bei weitem nicht so umfangreich.
Je nachdem wie sich OpenMeteoDWD entwickelt werde ich persönlich wohl von DWD_OpenData weggehen und auf OpenMeteoDWD setzen.
Wird sich aber noch zeigen.
Danke Heiko,
dann setz ich auch mal auf OpenMeteoDWD...
OpenMeteoWorld macht für Deutschland also keinen Sinn?
Gruß
oelidoc
ZitatOpenMeteoWorld macht für Deutschland also keinen Sinn?
Doch, durchaus.
Nur OpenMeteoWorld sucht entsprechend deines Standortes die geeigneten Quellen von einem Pool aus nationalen Wetterdiensten selbständig heraus.
Bei OpenMeteoDWD wird der Pool von vornherein auf die Modelle DWD Icon D2, DWD Icon EU und DWD Icon Global beschränkt.
Ich selbst sammle auch noch Erfahrungen welche Auswahl für Deutschland selbst die besten (oder auch gleichwertigen) Ergebnisse bringt. Nutzer in Großbritannien zB. werden sicherlich mit OpenMeteoWorld besser bedient sein.
Die Erläuterungen auf der Open-Meteo Seite geben jede Menge Infos dazu.
LG,
Heiko
Da die Open-Meteo Implementierung jetzt rund läuft habe ich mich entschieden die ganzen Weiterentwicklungen
einzuchecken.
Die neue V wird morgen früh mit FHEM Update ausgeliefert.
Und schöne Ostern wünsche ich euch!
Der nächste Step könnte die Implementierung der Ensemble Modelle sein.
Allein der DWD stellt über sein Ensemble Regionalmodell ICON-D2 eine Vorhersage aus 20 Einzelmembern zur Verfügung.
Ein Auszug aus der Erläuterung auf der Webseite: https://www.dwd.de/DE/forschung/wettervorhersage/num_modellierung/04_ensemble_methoden/ensemble_vorhersage/ensemble_vorhersage_node.html
ZitatFür eine perfekte Wettervorhersage müssten jeder Prozess und jeder Zustand in der Atmosphäre genauestens bekannt und im Vorhersagesystem perfekt abgebildet sein. In der Realität ist das nur näherungsweise möglich. Bereits der erste Schritt zur Vorhersage – die Berechnung des gegenwärtigen Atmosphärenzustands – ist mit inhärenten Unsicherheiten behaftet. Diese und andere Unsicherheiten stellen eine Herausforderung dar, weil die Atmosphäre ein ,,chaotisches System" ist, d.h. kleine Unsicherheiten können zu großen Fehlern in der Vorhersage anwachsen.
Daher stützen sich heutige Methoden nicht nur auf eine einzige Vorhersage, sondern auf ein ganzes ,,Ensemble" von Vorhersagen. Das Ensemble besteht aus verschiedenen Vorhersageszenarien, den ,,Ensemble Membern". Jedes Member basiert auf einer etwas anderen, aber jeweils realistischen Konfiguration des Anfangszustands und des Vorhersagesystems. Abhängig von der aktuellen Wettersituation wirken sich diese Unterschiede auf das Vorhersageresultat aus. Typischerweise bewegen sich die Ensemble Member mit fortschreitender Vorhersagezeit auseinander. Sie vermitteln eine Vorstellung von der tagesaktuellen Vorhersagbarkeit und stellen die Basis für Wahrscheinlichkeitsaussagen dar.
Über die entsprechende API von Open-Meteo erreichen wir mit einem einzigen API-Call das Ergebnis von 20! Einzelabfrufen verschiedener Modelle.
Das schaue ich mir noch genauer an. Die API Doku sagt noch aus:
ZitatEnsemblemodelle sind eine Art von Wettervorhersagetechnik, bei der mehrere Mitglieder oder Versionen eines Modells verwendet werden, um eine Reihe möglicher Ergebnisse für eine bestimmte Vorhersage zu erzeugen. Jedes Mitglied wird mit leicht unterschiedlichen Anfangsbedingungen und/oder Modellparametern initialisiert, um Unsicherheiten und Variationen in der Atmosphäre zu berücksichtigen, was zu einer Reihe von gestörten Prognosen führt.
Durch die Kombination der gestörten Vorhersagen erzeugt das Ensemble-Modell eine Wahrscheinlichkeitsverteilung möglicher Ergebnisse, die nicht nur die wahrscheinlichste Vorhersage, sondern auch den Bereich möglicher Ergebnisse und deren Wahrscheinlichkeiten angibt. Dieser probabilistische Ansatz bietet umfassendere und genauere Vorhersageempfehlungen, insbesondere für Wetterereignisse mit großen Auswirkungen und hohen Unsicherheiten.
Verschiedene nationale Wetterdienste berechnen Ensemble-Modelle mit unterschiedlicher Auflösung der Wettervariablen und des Vorhersagezeitraums. Das ICON-Modell des Deutschen Wetterdienstes (DWD) beispielsweise bietet eine außergewöhnlich hohe Auflösung für Europa, sagt aber nur bis zu 7 Tage voraus. Das GFS-Modell kann dagegen bis zu 35 Tage vorhersagen, wenn auch mit einer geringeren Auflösung von 50 km. Welches Ensemble-Modell am besten geeignet ist, hängt vom Vorhersagehorizont und der Region ab, die von Interesse ist.
Hallo Heiko,
vielen Dank für die ständigen Weiterentwicklungen des Moduls. Ich habe mir mehrere Instanzen eingerichtet und diese nun um OpenMeteoDWD-Varianten ergänzt, um die Performance zu vergleichen (einfach/komplex/KI jeweils mit DWD_OpenData und OpenMeteoDWD kombiniert).
Wie verhält es sich denn, wenn ich in einer Instanz von DWD_OpenData auf OpenMeteoDWD umstelle mit den erlernten KI Daten? Wenn ich es richtig beobachtet habe, wird das AIraw_SolarForecast_ File geleert und neu befüllt. Beim Zurückgehen auf DWD_OpenData wären dann die alten gelernten Daten weg und müssten aus dem Backup wiederhergestellt werden, oder?
Für die Auswertung der Performance logge ich den stündlichen Realwert, die letzte Prognose und die initiale Prognose von 0 Uhr über AllPVforecastsToEvent. Kann es sein, dass sich dort mit dem letzten Update etwas am Verhalten geändert hat?
Meine Diagramme werden nun nicht mehr erzeugt und bei der Fehlersuche ist mir aufgefallen, dass um Mitternacht über AllPVforecastsToEvent die kommenden 48h gespeichert werden und früher waren es nur die kommenden 24h (siehe Screenshots, vorher/nachher). Wenn ich die Werte des kommenden Tages händisch lösche bekomme ich wieder korrekte dargestellte Diagramme.
Viele Grüße
Alex
screenshot_log_vorher_nachher.jpg
Hallo Alex,
ZitatWie verhält es sich denn, wenn ich in einer Instanz von DWD_OpenData auf OpenMeteoDWD umstelle mit den erlernten KI Daten? Wenn ich es richtig beobachtet habe, wird das AIraw_SolarForecast_ File geleert und neu befüllt.
Die Rohdaten AIraw_SolarForecast_ werden immer angereichert und (bei Erfolg) das bestehende File überschrieben. D.h. der Inhalt wird mit der Zeit größer. Ein "get ... valDecTree aiRawData" zeigt dir den Content.
Problem bei einer Umstellung ist, dass die Strahlungsdaten zwischen DWD_OpenData und OpenMeteoDWD nicht wirklich kompatibel sind (GI vs. GTI). Das hatten wir weiter vorn schonmal kurz angerissen.
Man müsste sich das Verhalten mal genauer anschauen in einem solchen Fall.
ZitatBeim Zurückgehen auf DWD_OpenData wären dann die alten gelernten Daten weg und müssten aus dem Backup wiederhergestellt werden, oder?
Nein. Die gelernten Daten (also die Train-Daten) werden jede Nacht neu erstellt. Dazu wird die AIraw_SolarForecast_ Datei eingelesen und verarbeitet.
Geht auch manuell mit den Settern "set ... aiDecTree addRawData" -> addInstances -> train. In der Reihenfolge. Wenn du vorher ctrlDebug aiProcess gesetzt hast, siehst du die internen Vorgänge.
Edit: Wegen der AllPVforecastsToEvent schaue ich nochmal. Bei mir ist mir bislang nichts aufgefallen. Logge diese Daten auch.
LG
Hallo Heiko,
über "get ... valDecTree aiRawData" war mir aufgefallen, dass ein Tag nach der Umstellung statt der rund 1000 Einträge nur noch 12 enthalten waren. Daher kam meine Vermutung, dass ein Reset beim Wechsel von DWD_OpenData auf OpenMeteoDWD stattfindet. Kann aber sein, dass ich beim kopieren der Instanzen einen Fehler gemacht habe. Werde das nochmal neu aufsetzen.
Grüße
Alex
Hallo,
habe seit der Umstellung auf OpenMeteoWorld (?) ein kleines Schönheitsproblem: In der stündlichen Balkendiagramm-Vorhersage wird die PV Produktion nicht mehr angezeigt. Ob es wirklich mit der Umstellung zu tun hat, weiss ich nicht. Jemand eine Idee, wo der Fehler liegt?
PV.PNG
define Sonnenschein SolarForecast
attr Sonnenschein comment update per "wget -qO /opt/fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr Sonnenschein consumer01 MQTT2_DVES_44CEB0 type=other power=1500 icon=sani_heating_timer interruptable=1 mode=can pcurr=ENERGY_Power:W on=on off=off auto=1 etotal=ENERGY_Total:kWh mintime=SunPath:180:-240
attr Sonnenschein consumer02 Teichpumpe type=other on=on off=off auto=1 power=30 mode=can mintime=240 notbefore=12 interruptable=1 icon=springbrunnen_icon
attr Sonnenschein consumer03 MQTT2_DVES_693B50 type=dishwasher power=2400 on=on off=off pcurr=ENERGY_Power:W:5 etotal=ENERGY_Total:kWh icon=scene_dishwasher auto=1
attr Sonnenschein consumer04 MQTT2_DVES_1857F8 type=washingmachine power=2300 on=on off=off pcurr=ENERGY_Power:W etotal=ENERGY_Total:kWh icon=scene_washing_machine auto=1
attr Sonnenschein consumer05 MQTT2_DVES_17BC26 type=dryer power=900 on=on off=off pcurr=ENERGY_Power:W etotal=ENERGY_Total:kWh icon=scene_laundry_room auto=1
attr Sonnenschein consumerLink 1
attr Sonnenschein ctrlGenPVdeviation continuously
attr Sonnenschein ctrlLanguage DE
attr Sonnenschein ctrlWeatherDev1 OpenMeteoWorld-API
attr Sonnenschein disable 0
attr Sonnenschein event-on-change-reading .*
attr Sonnenschein flowGraphicAnimate 1
attr Sonnenschein flowGraphicShowConsumerDummy 0
attr Sonnenschein flowGraphicShowConsumerPower 1
attr Sonnenschein flowGraphicShowConsumerRemainTime 0
attr Sonnenschein graphicEnergyUnit Wh
attr Sonnenschein graphicShowNight 0
attr Sonnenschein room Photovoltaik
attr Sonnenschein verbose 2
# FUUID 64577c31-f33f-74ea-4814-4087424dfb073f20
# FVERSION 76_SolarForecast.pm:v1.17.2-s28725/2024-03-29
# LCACHEFILE last write time: 11:08:26 File: ./FHEM/FhemUtils/ScApi_SolarForecast_Sonnenschein
# MODE Automatic - next Cycletime: 11:14:15
# MODEL OpenMeteoWorldAPI
# NAME Sonnenschein
# NOTIFYDEV MQTT2_DVES_44CEB0,Teichpumpe,MQTT2_DVES_693B50,MQTT2_DVES_1857F8,MQTT2_DVES_17BC26
# NR 630
# NTFY_ORDER 50-Sonnenschein
# STATE updated
# TYPE SolarForecast
# eventCount 343
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL Sonnenschein
# SPGDEV Sonnenschein
# SPGROOM Photovoltaik
# VERSION 1.17.2
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.2
# OLDREADINGS:
# READINGS:
# 2024-03-30 11:13:05 Current_AutarkyRate 100 %
# 2024-03-30 11:13:05 Current_BatCharge 91 %
# 2024-03-30 11:13:05 Current_Consumption 262 W
# 2024-03-30 11:13:05 Current_GridConsumption 0 W
# 2024-03-30 11:13:05 Current_GridFeedIn 8 W
# 2024-03-30 11:13:05 Current_PV 2696 W
# 2024-03-30 11:13:05 Current_PowerBatIn 2426 W
# 2024-03-30 11:13:05 Current_PowerBatOut 0 W
# 2024-03-30 11:13:05 Current_SelfConsumption 262 W
# 2024-03-30 11:13:05 Current_SelfConsumptionRate 10 %
# 2024-03-30 11:13:05 Current_Surplus 2434 W
# 2024-03-30 11:00:00 LastHourGridconsumptionReal 0 Wh
# 2024-03-30 11:00:00 LastHourPVforecast 2015 Wh
# 2024-03-30 11:00:00 LastHourPVreal 240 Wh
# 2024-03-30 11:13:05 NextHours_Sum01_PVforecast 3186 Wh
# 2024-03-30 11:13:05 NextHours_Sum02_PVforecast 6002 Wh
# 2024-03-30 11:13:05 NextHours_Sum03_PVforecast 9476 Wh
# 2024-03-30 11:13:05 NextHours_Sum04_ConsumptionForecast 5384 Wh
# 2024-03-30 11:13:05 NextHours_Sum04_PVforecast 13310 Wh
# 2024-03-30 11:13:05 RestOfDayConsumptionForecast 12079 Wh
# 2024-03-30 11:13:05 RestOfDayPVforecast 16588 Wh
# 2024-03-30 00:59:49 Today_Hour01_BatIn 0 Wh
# 2024-03-30 00:59:49 Today_Hour01_BatOut 0 Wh
# 2024-03-30 00:59:49 Today_Hour01_GridConsumption 0 Wh
# 2024-03-30 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2024-03-30 00:59:49 Today_Hour01_PVreal 0 Wh
# 2024-03-30 01:59:49 Today_Hour02_BatIn 0 Wh
# 2024-03-30 01:59:49 Today_Hour02_BatOut 0 Wh
# 2024-03-30 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2024-03-30 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2024-03-30 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-03-30 02:59:49 Today_Hour03_BatIn 132 Wh
# 2024-03-30 02:59:49 Today_Hour03_BatOut 0 Wh
# 2024-03-30 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2024-03-30 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-03-30 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-03-30 03:59:50 Today_Hour04_BatIn 0 Wh
# 2024-03-30 03:59:50 Today_Hour04_BatOut 0 Wh
# 2024-03-30 03:59:50 Today_Hour04_GridConsumption 1 Wh
# 2024-03-30 03:59:50 Today_Hour04_GridFeedIn 0 Wh
# 2024-03-30 03:59:50 Today_Hour04_PVreal 0 Wh
# 2024-03-30 04:59:49 Today_Hour05_BatIn 0 Wh
# 2024-03-30 04:59:49 Today_Hour05_BatOut 0 Wh
# 2024-03-30 04:59:49 Today_Hour05_GridConsumption 0 Wh
# 2024-03-30 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2024-03-30 04:59:49 Today_Hour05_PVreal 0 Wh
# 2024-03-30 05:59:50 Today_Hour06_BatIn 0 Wh
# 2024-03-30 05:59:50 Today_Hour06_BatOut 1 Wh
# 2024-03-30 05:59:50 Today_Hour06_GridConsumption 0 Wh
# 2024-03-30 05:59:50 Today_Hour06_GridFeedIn 0 Wh
# 2024-03-30 05:59:50 Today_Hour06_PVreal 0 Wh
# 2024-03-30 06:59:51 Today_Hour07_BatIn 0 Wh
# 2024-03-30 06:59:51 Today_Hour07_BatOut 0 Wh
# 2024-03-30 06:59:51 Today_Hour07_GridConsumption 0 Wh
# 2024-03-30 06:59:51 Today_Hour07_GridFeedIn 0 Wh
# 2024-03-30 06:59:51 Today_Hour07_PVforecast 477 Wh
# 2024-03-30 06:59:51 Today_Hour07_PVreal 21 Wh
# 2024-03-30 07:59:50 Today_Hour08_BatIn 153 Wh
# 2024-03-30 07:59:50 Today_Hour08_BatOut 0 Wh
# 2024-03-30 07:59:50 Today_Hour08_GridConsumption 0 Wh
# 2024-03-30 07:59:50 Today_Hour08_GridFeedIn 0 Wh
# 2024-03-30 07:59:50 Today_Hour08_PVforecast 1205 Wh
# 2024-03-30 07:59:50 Today_Hour08_PVreal 277 Wh
# 2024-03-30 08:59:49 Today_Hour09_BatIn 89 Wh
# 2024-03-30 08:59:49 Today_Hour09_BatOut 147 Wh
# 2024-03-30 08:59:49 Today_Hour09_GridConsumption 1 Wh
# 2024-03-30 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2024-03-30 08:59:49 Today_Hour09_PVforecast 259 Wh
# 2024-03-30 08:59:49 Today_Hour09_PVreal 437 Wh
# 2024-03-30 09:59:49 Today_Hour10_BatIn 1783 Wh
# 2024-03-30 09:59:49 Today_Hour10_BatOut 0 Wh
# 2024-03-30 09:59:49 Today_Hour10_GridConsumption 0 Wh
# 2024-03-30 09:59:49 Today_Hour10_GridFeedIn 0 Wh
# 2024-03-30 09:59:49 Today_Hour10_PVforecast 1139 Wh
# 2024-03-30 09:59:49 Today_Hour10_PVreal 268 Wh
# 2024-03-30 10:59:49 Today_Hour11_BatIn 2040 Wh
# 2024-03-30 10:59:49 Today_Hour11_BatOut 0 Wh
# 2024-03-30 10:59:49 Today_Hour11_GridConsumption 0 Wh
# 2024-03-30 10:59:49 Today_Hour11_GridFeedIn 0 Wh
# 2024-03-30 10:59:49 Today_Hour11_PVforecast 2015 Wh
# 2024-03-30 10:59:49 Today_Hour11_PVreal 240 Wh
# 2024-03-30 11:13:05 Today_Hour12_BatIn 339 Wh
# 2024-03-30 11:13:05 Today_Hour12_BatOut 0 Wh
# 2024-03-30 11:13:05 Today_Hour12_GridConsumption 0 Wh
# 2024-03-30 11:13:05 Today_Hour12_GridFeedIn 0 Wh
# 2024-03-30 11:13:05 Today_Hour12_PVforecast 3340 Wh
# 2024-03-30 11:13:05 Today_Hour12_PVreal 62 Wh
# 2024-03-30 11:13:05 Today_Hour13_PVforecast 2682 Wh
# 2024-03-30 11:13:05 Today_Hour14_PVforecast 3255 Wh
# 2024-03-30 11:13:05 Today_Hour15_PVforecast 4193 Wh
# 2024-03-30 11:13:05 Today_Hour16_PVforecast 2657 Wh
# 2024-03-30 11:13:05 Today_Hour17_PVforecast 1016 Wh
# 2024-03-30 11:13:05 Today_Hour18_PVforecast 225 Wh
# 2024-03-30 11:13:05 Today_MaxPVforecast 4193 Wh
# 2024-03-30 11:13:05 Today_MaxPVforecastTime 2024-03-30 14:00:00
# 2024-03-30 11:13:05 Today_PVdeviation 24.79 %
# 2024-03-30 11:13:05 Today_PVforecast 22463 Wh
# 2024-03-30 11:13:05 Today_PVreal 1305 Wh
# 2024-03-30 11:13:05 Today_SunRise 06:10
# 2024-03-30 11:13:05 Today_SunSet 19:03
# 2024-03-30 11:13:05 Tomorrow_ConsumptionForecast 9981 Wh
# 2024-03-30 11:13:05 Tomorrow_PVforecast 18828 Wh
# 2024-03-30 11:13:05 Tomorrow_SunRise 07:07
# 2024-03-30 11:13:05 Tomorrow_SunSet 20:05
# 2024-03-30 11:13:05 consumer01 name='Gosund_2' state='off' mode='can' planningstate='planned'
# 2024-03-30 11:13:05 consumer01_currentPower 0 W
# 2024-03-30 11:13:05 consumer01_planned_start 30.03.2024 10:45:05
# 2024-03-30 11:13:05 consumer01_planned_stop 30.03.2024 16:38:05
# 2024-03-30 11:13:05 consumer02 name='Teichpumpe' state='off' mode='can' planningstate='planned'
# 2024-03-30 11:13:05 consumer02_planned_start 30.03.2024 12:00:05
# 2024-03-30 11:13:05 consumer02_planned_stop 30.03.2024 16:00:05
# 2024-03-30 11:13:05 consumer03 name='Spülmaschine' state='on' mode='can' planningstate='planned'
# 2024-03-30 11:13:05 consumer03_currentPower 1 W
# 2024-03-30 11:13:05 consumer03_planned_start 30.03.2024 14:00:00
# 2024-03-30 11:13:05 consumer03_planned_stop 30.03.2024 17:00:00
# 2024-03-30 11:13:05 consumer04 name='Waschmaschine' state='on' mode='can' planningstate='planned'
# 2024-03-30 11:13:05 consumer04_currentPower 0 W
# 2024-03-30 11:13:05 consumer04_planned_start 30.03.2024 14:00:00
# 2024-03-30 11:13:05 consumer04_planned_stop 30.03.2024 16:00:00
# 2024-03-30 11:13:05 consumer05 name='Trockner' state='on' mode='can' planningstate='planned'
# 2024-03-30 11:13:05 consumer05_currentPower 0 W
# 2024-03-30 11:13:05 consumer05_planned_start 30.03.2024 10:45:05
# 2024-03-30 11:13:05 consumer05_planned_stop 30.03.2024 12:15:05
# 2024-03-24 19:23:01 currentBatteryDev SunnyTripower8.0SE pin=BAT_P_CHARGE:W pout=BAT_P_DISCHARGE:W intotal=BAT_LOADTOTAL:W outtotal=BAT_UNLOADTOTAL:W charge=ChargeStatus cap=5200
# 2024-03-01 12:47:19 currentInverterDev SunnyTripower8.0SE pv=state:W etotal=SPOT_ETOTAL:Wh capacity=8000
# 2024-03-29 20:14:50 currentMeterDev SunnyHomeManager2.0 gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:Wh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:Wh feedprice=0.082:€ conprice=0.358:€
# 2024-03-30 11:06:34 currentRadiationAPI OpenMeteoWorld-API
# 2023-09-24 16:47:43 inverterStrings StringA,StringB
# 2024-03-24 18:34:27 moduleAzimuth StringA=-49 StringB=51
# 2024-03-24 18:35:03 moduleDeclination StringA=50 StringB=50
# 2023-09-24 16:47:43 modulePeakString StringA=6 StringB=2.8
# 2024-03-30 11:13:05 nextCycletime 11:14:15
# 2024-03-30 11:08:27 nextRadiationAPICall nach 30.03.2024 11:18:26
# 2024-03-30 07:00:05 pvCorrectionFactor_07 0.97 (automatic - old factor: 1.77, Sun Alt range: 5, Cloud range: 100, Days in range: 1)
# 2024-03-30 07:00:05 pvCorrectionFactor_07_autocalc done
# 2024-03-30 08:00:05 pvCorrectionFactor_08 0.43 (automatic - old factor: 0.98, Sun Alt range: 10, Cloud range: 100, Days in range: 4)
# 2024-03-30 08:00:05 pvCorrectionFactor_08_autocalc done
# 2024-03-30 09:00:04 pvCorrectionFactor_09 0.95 (automatic - old factor: 0.22, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
# 2024-03-30 09:00:04 pvCorrectionFactor_09_autocalc done
# 2024-03-30 10:00:04 pvCorrectionFactor_10 0.40 (automatic - old factor: 0.55, Sun Alt range: 30, Cloud range: 100, Days in range: 1)
# 2024-03-30 10:00:04 pvCorrectionFactor_10_autocalc done
# 2024-03-30 11:00:04 pvCorrectionFactor_11 0.42 (automatic - old factor: 0.73, Sun Alt range: 35, Cloud range: 100, Days in range: 1)
# 2024-03-30 11:00:04 pvCorrectionFactor_11_autocalc done
# 2024-03-30 11:13:05 pvCorrectionFactor_Auto on_complex_ai
# 2024-03-30 11:13:06 state updated
# hmccu:
#
setstate Sonnenschein updated
setstate Sonnenschein 2024-03-30 11:06:34 .associatedWith MQTT2_DVES_44CEB0 Teichpumpe MQTT2_DVES_693B50 MQTT2_DVES_1857F8 MQTT2_DVES_17BC26 SunnyTripower8.0SE SunnyHomeManager2.0
setstate Sonnenschein 2024-03-30 11:13:05 .lastupdateForecastValues 1711793585
setstate Sonnenschein 2024-03-30 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate Sonnenschein 2024-03-30 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate Sonnenschein 2024-03-30 02:00:01 .pvCorrectionFactor_02_apipercentil done
setstate Sonnenschein 2024-03-30 02:00:01 .pvCorrectionFactor_02_cloudcover done
setstate Sonnenschein 2024-03-30 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Sonnenschein 2024-03-30 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Sonnenschein 2024-03-30 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate Sonnenschein 2024-03-30 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate Sonnenschein 2024-03-30 05:00:04 .pvCorrectionFactor_05_apipercentil done
setstate Sonnenschein 2024-03-30 05:00:04 .pvCorrectionFactor_05_cloudcover done
setstate Sonnenschein 2024-03-30 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate Sonnenschein 2024-03-30 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate Sonnenschein 2024-03-30 07:00:05 .pvCorrectionFactor_07_apipercentil done
setstate Sonnenschein 2024-03-30 07:00:05 .pvCorrectionFactor_07_cloudcover done
setstate Sonnenschein 2024-03-30 08:00:05 .pvCorrectionFactor_08_apipercentil done
setstate Sonnenschein 2024-03-30 08:00:05 .pvCorrectionFactor_08_cloudcover done
setstate Sonnenschein 2024-03-30 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Sonnenschein 2024-03-30 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Sonnenschein 2024-03-30 10:00:04 .pvCorrectionFactor_10_apipercentil done
setstate Sonnenschein 2024-03-30 10:00:04 .pvCorrectionFactor_10_cloudcover done
setstate Sonnenschein 2024-03-30 11:00:04 .pvCorrectionFactor_11_apipercentil done
setstate Sonnenschein 2024-03-30 11:00:04 .pvCorrectionFactor_11_cloudcover done
setstate Sonnenschein 2024-03-30 11:13:05 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Sonnenschein 2024-03-30 01:00:04 .signaldone_01 done
setstate Sonnenschein 2024-03-30 02:00:01 .signaldone_02 done
setstate Sonnenschein 2024-03-30 03:00:04 .signaldone_03 done
setstate Sonnenschein 2024-03-30 04:00:05 .signaldone_04 done
setstate Sonnenschein 2024-03-30 05:00:04 .signaldone_05 done
setstate Sonnenschein 2024-03-30 06:00:04 .signaldone_06 done
setstate Sonnenschein 2024-03-30 07:00:05 .signaldone_07 done
setstate Sonnenschein 2024-03-30 08:00:05 .signaldone_08 done
setstate Sonnenschein 2024-03-30 09:00:04 .signaldone_09 done
setstate Sonnenschein 2024-03-30 10:00:04 .signaldone_10 done
setstate Sonnenschein 2024-03-30 11:00:04 .signaldone_11 done
setstate Sonnenschein 2024-03-30 11:13:05 Current_AutarkyRate 100 %
setstate Sonnenschein 2024-03-30 11:13:05 Current_BatCharge 91 %
setstate Sonnenschein 2024-03-30 11:13:05 Current_Consumption 262 W
setstate Sonnenschein 2024-03-30 11:13:05 Current_GridConsumption 0 W
setstate Sonnenschein 2024-03-30 11:13:05 Current_GridFeedIn 8 W
setstate Sonnenschein 2024-03-30 11:13:05 Current_PV 2696 W
setstate Sonnenschein 2024-03-30 11:13:05 Current_PowerBatIn 2426 W
setstate Sonnenschein 2024-03-30 11:13:05 Current_PowerBatOut 0 W
setstate Sonnenschein 2024-03-30 11:13:05 Current_SelfConsumption 262 W
setstate Sonnenschein 2024-03-30 11:13:05 Current_SelfConsumptionRate 10 %
setstate Sonnenschein 2024-03-30 11:13:05 Current_Surplus 2434 W
setstate Sonnenschein 2024-03-30 11:00:00 LastHourGridconsumptionReal 0 Wh
setstate Sonnenschein 2024-03-30 11:00:00 LastHourPVforecast 2015 Wh
setstate Sonnenschein 2024-03-30 11:00:00 LastHourPVreal 240 Wh
setstate Sonnenschein 2024-03-30 11:13:05 NextHours_Sum01_PVforecast 3186 Wh
setstate Sonnenschein 2024-03-30 11:13:05 NextHours_Sum02_PVforecast 6002 Wh
setstate Sonnenschein 2024-03-30 11:13:05 NextHours_Sum03_PVforecast 9476 Wh
setstate Sonnenschein 2024-03-30 11:13:05 NextHours_Sum04_ConsumptionForecast 5384 Wh
setstate Sonnenschein 2024-03-30 11:13:05 NextHours_Sum04_PVforecast 13310 Wh
setstate Sonnenschein 2024-03-30 11:13:05 RestOfDayConsumptionForecast 12079 Wh
setstate Sonnenschein 2024-03-30 11:13:05 RestOfDayPVforecast 16588 Wh
setstate Sonnenschein 2024-03-30 00:59:49 Today_Hour01_BatIn 0 Wh
setstate Sonnenschein 2024-03-30 00:59:49 Today_Hour01_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 00:59:49 Today_Hour01_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 00:59:49 Today_Hour01_PVreal 0 Wh
setstate Sonnenschein 2024-03-30 01:59:49 Today_Hour02_BatIn 0 Wh
setstate Sonnenschein 2024-03-30 01:59:49 Today_Hour02_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 01:59:49 Today_Hour02_PVreal 0 Wh
setstate Sonnenschein 2024-03-30 02:59:49 Today_Hour03_BatIn 132 Wh
setstate Sonnenschein 2024-03-30 02:59:49 Today_Hour03_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 02:59:49 Today_Hour03_PVreal 0 Wh
setstate Sonnenschein 2024-03-30 03:59:50 Today_Hour04_BatIn 0 Wh
setstate Sonnenschein 2024-03-30 03:59:50 Today_Hour04_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 03:59:50 Today_Hour04_GridConsumption 1 Wh
setstate Sonnenschein 2024-03-30 03:59:50 Today_Hour04_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 03:59:50 Today_Hour04_PVreal 0 Wh
setstate Sonnenschein 2024-03-30 04:59:49 Today_Hour05_BatIn 0 Wh
setstate Sonnenschein 2024-03-30 04:59:49 Today_Hour05_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 04:59:49 Today_Hour05_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 04:59:49 Today_Hour05_PVreal 0 Wh
setstate Sonnenschein 2024-03-30 05:59:50 Today_Hour06_BatIn 0 Wh
setstate Sonnenschein 2024-03-30 05:59:50 Today_Hour06_BatOut 1 Wh
setstate Sonnenschein 2024-03-30 05:59:50 Today_Hour06_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 05:59:50 Today_Hour06_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 05:59:50 Today_Hour06_PVreal 0 Wh
setstate Sonnenschein 2024-03-30 06:59:51 Today_Hour07_BatIn 0 Wh
setstate Sonnenschein 2024-03-30 06:59:51 Today_Hour07_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 06:59:51 Today_Hour07_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 06:59:51 Today_Hour07_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 06:59:51 Today_Hour07_PVforecast 477 Wh
setstate Sonnenschein 2024-03-30 06:59:51 Today_Hour07_PVreal 21 Wh
setstate Sonnenschein 2024-03-30 07:59:50 Today_Hour08_BatIn 153 Wh
setstate Sonnenschein 2024-03-30 07:59:50 Today_Hour08_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 07:59:50 Today_Hour08_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 07:59:50 Today_Hour08_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 07:59:50 Today_Hour08_PVforecast 1205 Wh
setstate Sonnenschein 2024-03-30 07:59:50 Today_Hour08_PVreal 277 Wh
setstate Sonnenschein 2024-03-30 08:59:49 Today_Hour09_BatIn 89 Wh
setstate Sonnenschein 2024-03-30 08:59:49 Today_Hour09_BatOut 147 Wh
setstate Sonnenschein 2024-03-30 08:59:49 Today_Hour09_GridConsumption 1 Wh
setstate Sonnenschein 2024-03-30 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 08:59:49 Today_Hour09_PVforecast 259 Wh
setstate Sonnenschein 2024-03-30 08:59:49 Today_Hour09_PVreal 437 Wh
setstate Sonnenschein 2024-03-30 09:59:49 Today_Hour10_BatIn 1783 Wh
setstate Sonnenschein 2024-03-30 09:59:49 Today_Hour10_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 09:59:49 Today_Hour10_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 09:59:49 Today_Hour10_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 09:59:49 Today_Hour10_PVforecast 1139 Wh
setstate Sonnenschein 2024-03-30 09:59:49 Today_Hour10_PVreal 268 Wh
setstate Sonnenschein 2024-03-30 10:59:49 Today_Hour11_BatIn 2040 Wh
setstate Sonnenschein 2024-03-30 10:59:49 Today_Hour11_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 10:59:49 Today_Hour11_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 10:59:49 Today_Hour11_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 10:59:49 Today_Hour11_PVforecast 2015 Wh
setstate Sonnenschein 2024-03-30 10:59:49 Today_Hour11_PVreal 240 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour12_BatIn 339 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour12_BatOut 0 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour12_GridConsumption 0 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour12_GridFeedIn 0 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour12_PVforecast 3340 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour12_PVreal 62 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour13_PVforecast 2682 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour14_PVforecast 3255 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour15_PVforecast 4193 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour16_PVforecast 2657 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour17_PVforecast 1016 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_Hour18_PVforecast 225 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_MaxPVforecast 4193 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_MaxPVforecastTime 2024-03-30 14:00:00
setstate Sonnenschein 2024-03-30 11:13:05 Today_PVdeviation 24.79 %
setstate Sonnenschein 2024-03-30 11:13:05 Today_PVforecast 22463 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_PVreal 1305 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Today_SunRise 06:10
setstate Sonnenschein 2024-03-30 11:13:05 Today_SunSet 19:03
setstate Sonnenschein 2024-03-30 11:13:05 Tomorrow_ConsumptionForecast 9981 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Tomorrow_PVforecast 18828 Wh
setstate Sonnenschein 2024-03-30 11:13:05 Tomorrow_SunRise 07:07
setstate Sonnenschein 2024-03-30 11:13:05 Tomorrow_SunSet 20:05
setstate Sonnenschein 2024-03-30 11:13:05 consumer01 name='Gosund_2' state='off' mode='can' planningstate='planned'
setstate Sonnenschein 2024-03-30 11:13:05 consumer01_currentPower 0 W
setstate Sonnenschein 2024-03-30 11:13:05 consumer01_planned_start 30.03.2024 10:45:05
setstate Sonnenschein 2024-03-30 11:13:05 consumer01_planned_stop 30.03.2024 16:38:05
setstate Sonnenschein 2024-03-30 11:13:05 consumer02 name='Teichpumpe' state='off' mode='can' planningstate='planned'
setstate Sonnenschein 2024-03-30 11:13:05 consumer02_planned_start 30.03.2024 12:00:05
setstate Sonnenschein 2024-03-30 11:13:05 consumer02_planned_stop 30.03.2024 16:00:05
setstate Sonnenschein 2024-03-30 11:13:05 consumer03 name='Spülmaschine' state='on' mode='can' planningstate='planned'
setstate Sonnenschein 2024-03-30 11:13:05 consumer03_currentPower 1 W
setstate Sonnenschein 2024-03-30 11:13:05 consumer03_planned_start 30.03.2024 14:00:00
setstate Sonnenschein 2024-03-30 11:13:05 consumer03_planned_stop 30.03.2024 17:00:00
setstate Sonnenschein 2024-03-30 11:13:05 consumer04 name='Waschmaschine' state='on' mode='can' planningstate='planned'
setstate Sonnenschein 2024-03-30 11:13:05 consumer04_currentPower 0 W
setstate Sonnenschein 2024-03-30 11:13:05 consumer04_planned_start 30.03.2024 14:00:00
setstate Sonnenschein 2024-03-30 11:13:05 consumer04_planned_stop 30.03.2024 16:00:00
setstate Sonnenschein 2024-03-30 11:13:05 consumer05 name='Trockner' state='on' mode='can' planningstate='planned'
setstate Sonnenschein 2024-03-30 11:13:05 consumer05_currentPower 0 W
setstate Sonnenschein 2024-03-30 11:13:05 consumer05_planned_start 30.03.2024 10:45:05
setstate Sonnenschein 2024-03-30 11:13:05 consumer05_planned_stop 30.03.2024 12:15:05
setstate Sonnenschein 2024-03-24 19:23:01 currentBatteryDev SunnyTripower8.0SE pin=BAT_P_CHARGE:W pout=BAT_P_DISCHARGE:W intotal=BAT_LOADTOTAL:W outtotal=BAT_UNLOADTOTAL:W charge=ChargeStatus cap=5200
setstate Sonnenschein 2024-03-01 12:47:19 currentInverterDev SunnyTripower8.0SE pv=state:W etotal=SPOT_ETOTAL:Wh capacity=8000
setstate Sonnenschein 2024-03-29 20:14:50 currentMeterDev SunnyHomeManager2.0 gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:Wh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:Wh feedprice=0.082:€ conprice=0.358:€
setstate Sonnenschein 2024-03-30 11:06:34 currentRadiationAPI OpenMeteoWorld-API
setstate Sonnenschein 2023-09-24 16:47:43 inverterStrings StringA,StringB
setstate Sonnenschein 2024-03-24 18:34:27 moduleAzimuth StringA=-49 StringB=51
setstate Sonnenschein 2024-03-24 18:35:03 moduleDeclination StringA=50 StringB=50
setstate Sonnenschein 2023-09-24 16:47:43 modulePeakString StringA=6 StringB=2.8
setstate Sonnenschein 2024-03-30 11:13:05 nextCycletime 11:14:15
setstate Sonnenschein 2024-03-30 11:08:27 nextRadiationAPICall nach 30.03.2024 11:18:26
setstate Sonnenschein 2024-03-30 07:00:05 pvCorrectionFactor_07 0.97 (automatic - old factor: 1.77, Sun Alt range: 5, Cloud range: 100, Days in range: 1)
setstate Sonnenschein 2024-03-30 07:00:05 pvCorrectionFactor_07_autocalc done
setstate Sonnenschein 2024-03-30 08:00:05 pvCorrectionFactor_08 0.43 (automatic - old factor: 0.98, Sun Alt range: 10, Cloud range: 100, Days in range: 4)
setstate Sonnenschein 2024-03-30 08:00:05 pvCorrectionFactor_08_autocalc done
setstate Sonnenschein 2024-03-30 09:00:04 pvCorrectionFactor_09 0.95 (automatic - old factor: 0.22, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
setstate Sonnenschein 2024-03-30 09:00:04 pvCorrectionFactor_09_autocalc done
setstate Sonnenschein 2024-03-30 10:00:04 pvCorrectionFactor_10 0.40 (automatic - old factor: 0.55, Sun Alt range: 30, Cloud range: 100, Days in range: 1)
setstate Sonnenschein 2024-03-30 10:00:04 pvCorrectionFactor_10_autocalc done
setstate Sonnenschein 2024-03-30 11:00:04 pvCorrectionFactor_11 0.42 (automatic - old factor: 0.73, Sun Alt range: 35, Cloud range: 100, Days in range: 1)
setstate Sonnenschein 2024-03-30 11:00:04 pvCorrectionFactor_11_autocalc done
setstate Sonnenschein 2024-03-30 11:13:05 pvCorrectionFactor_Auto on_complex_ai
setstate Sonnenschein 2024-03-30 11:13:06 state updated
Frohe Ostern
oelidoc
Re. Balkendiagramm:
kann ich teilweise bestätigen:
2024-03-30 06:59:50 Today_Hour07_GridConsumption 200 Wh
2024-03-30 06:59:50 Today_Hour07_GridFeedIn 0 Wh
2024-03-30 06:59:50 Today_Hour07_PVforecast 542 Wh
2024-03-30 06:59:50 Today_Hour07_PVreal 120 Wh
2024-03-30 07:59:49 Today_Hour08_GridConsumption 600 Wh
2024-03-30 07:59:49 Today_Hour08_GridFeedIn 0 Wh
2024-03-30 07:59:49 Today_Hour08_PVforecast 1207 Wh
2024-03-30 07:59:49 Today_Hour08_PVreal 229 Wh
2024-03-30 08:59:58 Today_Hour09_GridConsumption 800 Wh
2024-03-30 08:59:58 Today_Hour09_GridFeedIn 0 Wh
2024-03-30 08:59:58 Today_Hour09_PVforecast 1621 Wh
2024-03-30 08:59:58 Today_Hour09_PVreal 440 Wh
2024-03-30 09:59:50 Today_Hour10_GridConsumption 800 Wh
2024-03-30 09:59:50 Today_Hour10_GridFeedIn 0 Wh
2024-03-30 09:59:50 Today_Hour10_PVforecast 2028 Wh
2024-03-30 09:59:50 Today_Hour10_PVreal 539 Whoffensichtlich nur bei "kleinen" Werten?
Solarfc2.png
.. ansonst unauffällig, abegesehn von zuwenig Sonne heute ;D
l-g- erwin
@Alex,
habe gerade nochmal den Wechsel von DWD_OpenData auf OpenMeteoDWD und zurück exerziert.
Es ist technisch kein Problem, die Daten in AIraw_SolarForecast_ bleiben bestehen.
@oelidoc, @erwin,
kann ich bei mir nicht nachvollziehen.
Allerdings ist es technisch / graphisch bedingt wenn die Differenzen zu groß zw. Prognose/Ist
werden ein Balken zu klein zur Anzeige ist. Z.B.
# 2024-03-30 09:59:49 Today_Hour10_PVforecast 1139 Wh
# 2024-03-30 09:59:49 Today_Hour10_PVreal 268 Wh
# 2024-03-30 10:59:49 Today_Hour11_PVforecast 2015 Wh
# 2024-03-30 10:59:49 Today_Hour11_PVreal 240 Wh
Ihr könnt mit der grafischen Auflösung spielen und das Attr graphicBeamHeight so anpassen dass die Darstellung bei euch optimal ist.
LG
Hallo Heiko,
Zitat von: DS_Starter am 30 März 2024, 12:03:53das Attr graphicBeamHeight so anpassen dass die Darstellung bei euch optimal ist.
Okay, bei graphicBeamHeight 250 kommt wieder was ;D
Bleibt die Frage warum die Abweichung z.Zt. 61,7% ist...
Gruß
oelidoc
Zitat von: DS_Starter am 30 März 2024, 12:03:53@Alex,
habe gerade nochmal den Wechsel von DWD_OpenData auf OpenMeteoDWD und zurück exerziert.
Es ist technisch kein Problem, die Daten in AIraw_SolarForecast_ bleiben bestehen.
Danke Heiko. Ich gehe davon aus, dass mir beim Kopieren der Instanz ein Fehler passiert ist und die alten Daten dabei verloren gegangen sind. Habe nun eine neue Kopie mit dem alten AIraw_SolarForecast_ erstellt und werde es beobachten.
Bezüglich des AllPVforecastsToEvent - Logs. Bei dir scheint das Diagramm ja weiterhin wie gewohnt erstellt zu werden. Tauchen bei dir im zugehörigen Log File nur die Daten des kommenden Tag auf, oder auch zusätzlich die des darauf folgenden? Dann könnte ich eingrenzen, ob das Problem bei mir beim Loggen oder bei der Darstellung (SVG/gplot) liegt.
Grüße
ZitatTaucht bei dir im zugehörigen Log File nur die Daten des kommenden Tage auf, oder auch zusätzlich die des darauf folgenden?
Werde ich heute Abend analysieren, nutze DbLog. Und jetzt ist grad Gartenarbeit angesagt. ;)
ZitatBleibt die Frage warum die Abweichung z.Zt. 61,7% ist...
Das ist die Folge der kontinuierlichen Abweichungsberechnung. Eigentlich bin ich der Meinung, dass erst am Tagesende die Endrechnung relevant ist, hatten wir schon die Diskussion ;).
Wenn die aktuelle Stunde eine hohe Prognose besteht und zu Beginn der Stunde, oder weil die Prognose sich verschätzt hat, oder das Training noch ungenügend ist eine hohe Diskrepanz besteht, ist die Abweichung seit Beginn des Tages hoch. Die nächste Stunde kann sich das wieder ausgleichen weil die Wolken sich um eine Stunde "geirrt" haben. ;)
Also heute verhagelt uns der Saharastaub die Bilanz. >:(
Das war nicht auf dem Schirm in der Forecast glaube ich.
Möglicherweise gibt es noch einen Zusatzparameter, schaue ich heute Abend auch mal.
Zitat von: DS_Starter am 30 März 2024, 15:25:07Also heute verhagelt uns der Saharastaub die Bilanz. >:(
.......
Das kann man wohl sagen.....: :o 😤😱
Edit:
(MODEL : OpenMeteoWorldAPI)
Na da bin ich mit meinen 45% ja noch gut bedient. Hat übrigens auch des "normale" DWD mit 60% getroffen.
Nur SolCast konnte sich mit -11% ganz gut behaupten.
Bei uns waren die Prognosen bis 12:00 völlig ok, am Nachmittag ging es dann rapide runter.
Hallo Alex,
hier ein Auszug aus meiner DB von heute bzgl. AllPVforecastsToEvent:
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_00-59-59__1__SolCast__AllPVforecastsToEvent 0 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_06-59-59__1__SolCast__AllPVforecastsToEvent 128 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_07-59-59__1__SolCast__AllPVforecastsToEvent 639 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_08-59-59__1__SolCast__AllPVforecastsToEvent 732 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_09-59-59__1__SolCast__AllPVforecastsToEvent 4037 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_10-59-59__1__SolCast__AllPVforecastsToEvent 4376 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_11-59-59__1__SolCast__AllPVforecastsToEvent 5789 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_12-59-59__1__SolCast__AllPVforecastsToEvent 5506 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_13-59-59__1__SolCast__AllPVforecastsToEvent 5072 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_14-59-59__1__SolCast__AllPVforecastsToEvent 5435 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_15-59-59__1__SolCast__AllPVforecastsToEvent 3681 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_16-59-59__1__SolCast__AllPVforecastsToEvent 1862 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_17-59-59__1__SolCast__AllPVforecastsToEvent 630 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_18-59-59__1__SolCast__AllPVforecastsToEvent 31 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-30_19-59-59__1__SolCast__AllPVforecastsToEvent 0 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_07-59-59__1__SolCast__AllPVforecastsToEvent 134 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_08-59-59__1__SolCast__AllPVforecastsToEvent 577 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_09-59-59__1__SolCast__AllPVforecastsToEvent 1465 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_10-59-59__1__SolCast__AllPVforecastsToEvent 3201 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_11-59-59__1__SolCast__AllPVforecastsToEvent 4048 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_12-59-59__1__SolCast__AllPVforecastsToEvent 4756 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_13-59-59__1__SolCast__AllPVforecastsToEvent 4604 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_14-59-59__1__SolCast__AllPVforecastsToEvent 7080 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_15-59-59__1__SolCast__AllPVforecastsToEvent 2514 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_16-59-59__1__SolCast__AllPVforecastsToEvent 3053 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_17-59-59__1__SolCast__AllPVforecastsToEvent 1859 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_18-59-59__1__SolCast__AllPVforecastsToEvent 607 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_19-59-59__1__SolCast__AllPVforecastsToEvent 43 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 2024-03-31_20-59-59__1__SolCast__AllPVforecastsToEvent 0 Wh
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 background_processing_time 0.1794
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 number_fetched_rows 29
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 sql_processing_time 0.1566
setstate Rep.LogDBShort.Report 2024-03-30 19:43:15 state done
Es sind also auch die Daten von Morgen mit in der DB.
Edit: Das SVG zeigt natürlich nur die Daten von Heute, d.h. es läuft von 00:00 bis 24:00 (heute). MIr fällt eigentlich kein Grund ein warum dein SVG nichts anzeigen soll wenn doch die Daten im FileLog vorhanden sind? Wenn es noch mehr gibt (morgen) sollte das doch keinen Einfluß haben.
@Alex, ich könnte die Eventgenerierung von AllPVforecastsToEvent grundsätzlich nur auf den aktuellen Tag beschränken (d.h. morgen früh würden die Daten nur für den 31.03. erzeugt) wenn das hilft.
Wäre im Prinzip kein Problem.
Trotzdem kann ich mir nicht erklären weshalb dein SVG mein einem "zu viel" an Daten ein Thema hat.
Aber ich denke das ist ein FileLog/SVG Thema. Es geht ja nur um die Darstellung von Eventdaten. Ist ja egal woher die kommen.
Zitat von: DS_Starter am 30 März 2024, 20:01:19@Alex, ich könnte die Eventgenerierung von AllPVforecastsToEvent grundsätzlich nur auf den aktuellen Tag beschränken (d.h. morgen früh würden die Daten nur für den 31.03. erzeugt) wenn das hilft.
Wäre im Prinzip kein Problem.
Trotzdem kann ich mir nicht erklären weshalb dein SVG mein einem "zu viel" an Daten ein Thema hat.
Aber ich denke das ist ein FileLog/SVG Thema. Es geht ja nur um die Darstellung von Eventdaten. Ist ja egal woher die kommen.
Hallo Heiko,
danke fürs Nachschauen. Nein, meinetwegen bitte daran nichts ändern, wenn es prinzipiell so funktionieren sollte. Es liegt wohl irgendwo an SVG. Bis vorgestern werden die Plots angezeigt (auch jetzt noch, wenn ich auf die vorherigen Tage zurückspringe) und seit die Vorhersage 2 Tage umfasst bleiben sie leer. Unter "show preprocessed input" sieht man dann keine Einträge oder nur einen einzigen, der aber der letzte vom Vortag ist und dort nicht auftauchen dürfte. Ich hab bisher die Logs aller Forecast-Instanzen in einem File. Eventuell sorgt das für Probleme. Ähnliches Verhalten hatte ich mal, als die Namen der Instanzen ähnlich waren. Muss ich mir nochmal in Ruhe anschauen.
Grüße und schöne Ostern!
Zitat von: AlexS am 31 März 2024, 08:52:16show preprocessed input
Das hat mit SVG nichts, aber auch gar nichts zu tun.
Zur Fehlereingrenzung sollte man sich zunächst die Textzeilen in der Log-Datei bzw. Log-DB ansehen. Und dann die Regulären Ausdrücke im FileLog/DBLog-Device entsprechend korrigieren.
LG
pah
Hallo zusammen,
durch "attr Prognose_komplex_DWD fixedrange 3days +1" werden die plots nun richtig befüllt (gestern, heute und die initiale Prognose für morgen). Ohne das Attribut bleibt der plot leer, X-Achse passt aber zum heutigen Tag. Werde es vorerst dabei belassen.
Grüße
Alex
Heute macht das Ergebnis wieder mehr Freude. :)
Model: OpenMeteoDWDAPI
Übrigens war ich ganz schlau das KI Training per default auf 01:15 zu setzen.
Hat sich vergangene Nacht wegen der Zeitumstellung ganz super gemacht. :-[
Ich ändere den default im nächsten Release auf eine bekömmlichere Startzeit.
LG
In meinem contrib liegt die V 1.17.3
Neben der Anpassung der KI Training Startzeit und weiteren Kleinigkeiten ist die Ensemble Prognose des DWD (https://www.dwd.de/DE/forschung/wettervorhersage/num_modellierung/04_ensemble_methoden/ensemble_vorhersage/ensemble_vorhersagen.html?nn=19848)
implementiert:
OpenMeteoDWDEnsemble-API
Diese Open-Meteo API Variante bietet Zugang zum globalen Ensemble-Vorhersagesystem (EPS) des DWD.
Es werden die Ensemble Modelle ICON-D2-EPS, ICON-EU-EPS und ICON-EPS nahtlos vereint.
Ensemble-Wetterprognosen sind eine spezielle Art von Vorhersagemethode, die die Unsicherheiten bei der Wettervorhersage berücksichtigt. Sie tun dies, indem sie mehrere Simulationen oder Modelle mit leichten Unterschieden in den Startbedingungen oder Einstellungen ausführen. Jede Simulation, bekannt als Ensemblemitglied, stellt ein mögliches Ergebnis des Wetters dar. In der vorliegenden Implementierung werden 40 Ensemblemitglieder pro Wettermerkmal zusammengeführt und das wahrscheinlichste Ergbnis verwendet.
LG
Habs mal sofort darauf umgestellt.
...und vorher erst einmal alle Daten aus dem Speicher / der Historie entfernt weil so langsam Sommer wird / ist.
Grund:
Bei mir wird der Verbrauch wegen eines zusätzlich vorhandnen BHKW / Brennstoffzelle so oder so im Winterhalbjahr immer "falsch" berechnet - da kann das Modul aber nichts für.
Werde die Tage dann mal berichten inwieweit es zutreffend ist.
Gruß
300P
Mal eine Frage. Bei den OpenMeteo Abfragen wird doch die Ausrichtung mit übergeben in der Abfrage, so habe ich das zumindest verstanden.
Werden bei verschiedenen Ausrichtungen mehrere Abfragen ausgeführt?
ZitatMal eine Frage. Bei den OpenMeteo Abfragen wird doch die Ausrichtung mit übergeben in der Abfrage, so habe ich das zumindest verstanden.
Werden bei verschiedenen Ausrichtungen mehrere Abfragen ausgeführt?
Ja. Für jeden im Modul angegebenen String wird eine Abfrage ausgeführt. Das kannst du mit ctrlDebug=apiCall [apiProcess] verfolgen.
Habe die neue V jetzt auch eingecheckt, ist morgen früh in der Auslieferung per Update.
Moin DS_Starter,
gibt es das reading "AllPVforecastsToEvent" eigentlich noch. Hatte es geloggt und die prognoseveränderung grafisch darzustellen, aber irgendwie schein dies nicht mehr vorhanden. Habe die version aus deiner contrib installiert...
Zitatgibt es das reading "AllPVforecastsToEvent" eigentlich noch.
Im Prinzip ja. Im Prinzip deswegen, weil es lediglich für einen kurzen Moment ezeugt wird um die Events "AllPVforecastsToEvent" zum Logging (wie im Wiki beschrieben) zu erzeugen. Danach wird es gelöscht.
Es hat keinen weiteren Informationswert und ist immer 0.
Du kannst den Event wie beschrieben nach wie vor loggen.
LG
Ah, nun habe ich es!
Mein Problem war, dass seit dem 28.03. meine svgplots nicht mehr in der 24std sicht angezeigt wurden. An dem Tag habe ich ein update gefahren und forecast aus deiner contrib gezogen. Ich habe gerade im Logfile gesehen, dass AllPVforecastsToEvent seit dem 29.03. den forecast für zwei Tage schreibt und nciht für einen, weshalb ich einen Tageswechsel in dem Log hatte. (war ein gemeinsam genutztes Logfile). Dadurch hat sich vermutlich der svg Plot verschuckt.
Kann man den auf einen Tag begrenzen?
ZitatKann man den auf einen Tag begrenzen?
Kann ich. Hatten wir vor kurzem hier #327.
Du kannst aber auch die Lösung von AlexS in #330 anwenden.
Ahhhh! Hätte ich mal hier gelesen. Hatte aber den Zusammenhang nicht sofort erkannt. Hätte mir heute ein paar Std erspart...
Danke!
Zitat von: AlexS am 31 März 2024, 11:19:40Hallo zusammen,
durch "attr Prognose_komplex_DWD fixedrange 3days +1" werden die plots nun richtig befüllt (gestern, heute und die initiale Prognose für morgen). Ohne das Attribut bleibt der plot leer, X-Achse passt aber zum heutigen Tag. Werde es vorerst dabei belassen.
Grüße
Alex
Habe das gleiche Problem, aber das attribut habe ich nicht...
Das ist ein Attr im SVG Device. Das liest sich bei Alex wegen DWD nur etwas eigenartig.
Tag,
ich hab gestern meine DWD Devices gekickt und komplett auf OpenMeteoDWDEnsemble-API umgestellt.
Heute direkt nochmal das offizielle Update eingespielt. Bisschen durchgeklickt und dabei viel mir auf,
sonst hattest du immer aus einem String_Array der vorhandenen API's ein DropDown erzeugt.
Jetzt ich bei ctrlWeatherDevX nur ein Texfeld. Liegt das daran, das keine DWD Devices vorhanden sind,
oder ist es doch so gewollt?
Außerdem gibt es jetzt nur 1 x ctrlWeatherDevX. Oder sind mehrere W.Dev's blockiert, wenn nicht mehr gefunden werden?
Abgesehen davon, ich verspreche mir viel von OpenMeteoDWDEnsemble-API. Wenn das weiterhin gut funktioniert,
dann besteht auch kein Bedarf für externe Wettermodule.
Gruß schwatter
Hallo zusammen,
bisher habe ich den Eindruck, dass der open-meteo Icon D2 Input die kurzzeitigen Wetteränderungen besser abbildet als der DWD Mosmix-S Input.
@Heiko: Welchen Vorteil kann man vom ICON-D2-EPS gegenüber ICON-D2 erwarten? Das EPS Modell beinhaltet ja Variantenrechnungen, um Modellunsicherheiten abzuschätzen, aber vermutlich verwertest du davon nur den Hauptlauf, oder?
Unterscheidet sich der denn vom ICON-D2 Hauptlauf?
Ich habe mal für einen Standort bei kachelmannwetter beide Kurven verglichen und da waren diese identisch: D2 (kachelmannwetter) (https://kachelmannwetter.com/de/vorhersage/2825297-stuttgart/kompakt/rapid-id2) und D2-EPS (kachelmannwetter) (https://kachelmannwetter.com/de/vorhersage/2825297-stuttgart/ensemble/rapid-id2). Bei open-meteo.com habe ich beim Vergleich unterschiedliche Werte erhalten, was ich mir nicht ganz erklären kann. Vorteil ICON-D2 müsste zumindest sein, dass die Vorhersagen jeweils früher zur Verfügung stehen als die von ICON-D2-EPS.
Hierüber (https://www.dwd.de/DE/leistungen/modellvorhersagedaten/cosmo_d2_eps__documentation.pdf?__blob=publicationFile&v=2) könnte man eventuell mehr erfahren, bin aber noch nicht wirklich weiter gekommen.
Grüße
Alex
@schwatter,
ZitatJetzt ich bei ctrlWeatherDevX nur ein Texfeld. Liegt das daran, das keine DWD Devices vorhanden sind,
oder ist es doch so gewollt?
Es liegt zwar an den fehlenden DWD Devices, aber ist trotzdem ein Fehler den ich bereinigen muß.
Sind keine DWD Devices vorhanden, wird auch kein Attr ctrlWeatherDev2/3 mehr angeboten weil diese Attr ausschließlich DWD Devices beinhalten dürfen.
@Alex,
ZitatWelchen Vorteil kann man vom ICON-D2-EPS gegenüber ICON-D2 erwarten? Das EPS Modell beinhaltet ja Variantenrechnungen, um Modellunsicherheiten abzuschätzen, aber vermutlich verwertest du davon nur den Hauptlauf, oder?
Die OpenMeteo API liefert neben den Werten der einzelnen Memeber den Wert pro Merkmal mit der höchsten Wahrscheinlichkeit des Eintretens. Den benutze ich im Forecast. Die Werte der Einzelmember drucke ich im Modul nicht extra aus. Aber wen es interessiert setzt sich ctrlDebug=apiCall, kopiert sich den Aufrauf aus dem Log und führt ihn im Browser aus. Dann siehst du auch die Werte aller Einzelmember.
Welche Vorteile sich aus der Nutzung des ICON-D2-EPS gegenüber ICON-D2 ergeben können wir nur gemeinsam durch Sammeln von Erfahrungswerten herausfinden. Zumindest liest sich die Doku zum ICON-D2-EPS (https://www.dwd.de/DE/forschung/wettervorhersage/num_modellierung/04_ensemble_methoden/ensemble_vorhersage/ensemble_vorhersagen.html) vielversprechend:
ZitatIn der Anwendung dient das ICON-D2-EPS im Wesentlichen der Unterstützung des Warnwesens des DWD. Dieses Spektrum wird mehr und mehr erweitert, z.B. für die Nutzung in der Flugwetterberatung oder bei der Unterstützung der Energiegewinnung aus erneuerbaren Energien wie Windenergie und Photovoltaik.
ZitatUnterscheidet sich der denn vom ICON-D2 Hauptlauf?
Ich weiß ehrlich gesagt nicht ob es den "Hauptlauf" überhaupt gibt, denn die Member sind in der Betrachtung m.M. nach gleichwertig.
Aber wenn man das wahrscheinlichste Ergebnis des Ensemble mit dem Ergebnis des normalen ICON-D2 Ergebnis vergleicht, sind Unterschiede erkennbar. Sie müssen nicht riesig sein, aber ich habe schon Unterschiede von 300-400 Wh in einer betrachteten Stunde gesehen.
@schwatter, ich habe deinen gemeldeten Issue gefixt. Ist morgen früh im Update.
Das Attr ctrlWeatherDev1 enthält nur die Liste der OpenMeteo-API's wenn kein DWD-Device vorhanden ist. Die Attr ctrlWeatherDev2/3 gibt es in diesen Fällen nicht mehr wie weiter vorn beschrieben.
LG
Zitat von: DS_Starter am 01 April 2024, 21:39:28Ich weiß ehrlich gesagt nicht ob es den "Hauptlauf" überhaupt gibt, denn die Member sind in der Betrachtung m.M. nach gleichwertig.
Aber wenn man das wahrscheinlichste Ergebnis des Ensemble mit dem Ergebnis des normalen ICON-D2 Ergebnis vergleicht, sind Unterschiede erkennbar. Sie müssen nicht riesig sein, aber ich habe schon Unterschiede von 300-400 Wh in einer betrachteten Stunde gesehen.
Danke für deine Erklärungen. Ich hänge gerade beim Verständnis noch an dem Schritt, wie man von den 40 gleichwertigen Membern auf das wahrscheinlichste Ergebnis kommt. Wird die statistische Auswertung mitgeliefert?
ZitatWird die statistische Auswertung mitgeliefert?
Es wird neben den einzelnen Membern das wahrscheinlichste Ergebnis mitgeliefert.
Die Wahrscheinlichkeit des Eintretens wird noch nicht geliefert, aber daran wird gearbeitet:
ZitatThe Ensemble API provides direct access to individual member forecasts, but future versions may integrate probabilistic forecasts to get the likelyhood of a given weather condition. This work is tracked on GitHub in ticket #349 (https://github.com/open-meteo/open-meteo/issues/349).
Siehe auch https://openmeteo.substack.com/p/ensemble-weather-forecast-api
Vllt. ist es für das Verständnis einfacher den Call mal im Browser auszuführen und sich das gelieferte JSON anzuschauen.
Moin,
Zitat von: DS_Starter am 01 April 2024, 22:17:26Das Attr ctrlWeatherDev1 enthält nur die Liste der OpenMeteo-API's wenn kein DWD-Device vorhanden ist. Die Attr ctrlWeatherDev2/3 gibt es in diesen Fällen nicht mehr wie weiter vorn beschrieben.
Ich habe jetzt leider nicht alles mit bekommen, was da so um OpenMeteoDWD geschrieben wurde, vor allem nicht, wie ich entsprechend darauf umstellen kann - wenn ich jetzt diesen Post lese, muß ich also mein DWD-Device löschen (ganz, oder nur imSolarforecast?), oder wie ist das gemeint?
Gruß, Christoph
Nein - nur umstellen auf das was Du nutzen möchtest stellst du in diesem Modul ein.
Kurze Info meinerseits.
Bis jetzt überzeugt mich die OpenMeteoEnsemble API so überhaupt nicht. Die Werte wie gefüttert wird sind die gleichen bei den anderen.
Habe ich extra nocheinmal gecheckt.
Die Werte die rauskommen sind aber total unterschiedlich zu den anderen OpenMeteo Werten.
Muss ich mal weiter beobachten.
Zitat von: kask am 02 April 2024, 23:08:57Bis jetzt überzeugt mich die OpenMeteoEnsemble API so überhaupt nicht.
Ich habe gestern Früh von SolCast auf OpenMeteoWorld umgestellt und dann die Tagesvorhersagen verglichen. (Habe keine 2 Devices dafür spendiert, daher nur Screenshot vom Gerät vor der Umstellung mit der ersten Vorhersage nach der Umstellung verglichen.)
Die OpenMeteoWorld war eingangs etwas pessimistischer, auf den erwarteten Wetterverlauf bezogen aber immer noch viel zu optimistisch.
Tagsüber wurden die Prognosen dann immer wieder teils deutlich nach unten korrigiert, sodass am Ende des Tages eine Abweichung von nur 0,5% rausgekommen ist. Die einzelnen Stunden hatten zwar teils sehr deutliche Abweichungen (doppelt soviel erzeugt oder auch nur halb soviel), aber gestern gab's auch alle paar Minuten einen Wechsel zwischen Wolken und Sonne. Heute soll es beständiger sein (Bayer Agrar Wetter prognostiziert ausschließlich Sonnenschein, OpenMeteoWorld sagt Wolken ab Mittag, Proplanta meint wolkig ab dem späteren Vormittag), mal sehen wie die Treffergenauigkeit wird.
Was ich noch nicht verstanden habe...
Was soll denn in Österreich das "beste" Ergebnis liefern? Eigentlich dachte ich OpenMeteoDWDEnsemble wäre primär für Deutschland, aber lt. deren Beschreibung könnte es auch für Österreich passen.
Moin,
ZitatWas ich noch nicht verstanden habe...
Was soll denn in Österreich das "beste" Ergebnis liefern? Eigentlich dachte ich OpenMeteoDWDEnsemble wäre primär für Deutschland, aber lt. deren Beschreibung könnte es auch für Österreich passen.
Beim Open Meteo Dienst kann man die einzelnen Wetteranbieter bzw. deren Modelle orchestrieren.
Beim OpenMeteoDWDEnsemble verwende ich "DWD ICON EPS Seamless" welches die Modelle DWD ICON EPS D2, DWD ICON EPS EU, DWD ICON EPS Global beinhaltet. Die Modelle decken verschiedene Regionen ab, wie deren Namen schon sagt.
(Bei den anderen Open Meteo API's hab ich ebenfalls in der Hilfe jeweils hinterlegt welche Anbietermodelle integriert sind.)
Sie unterscheiden sich aber auch im Vorhersagehorizont und anderen Parametern. Auf der Webseite https://open-meteo.com/en/docs/ensemble-api#hourly=global_tilted_irradiance&forecast_days=3&models=icon_seamless gibt es im unteren Bereich eine Tabelle welche die Eigenschaften der jeweiligen Quellen beschreibt.
Weiterhin seht ihr eine dynamische Grafik, die die Memberergebnisse und den wahrscheinlichsten Grafen (hervorgehoben mit Mouse-Over über global.tilted_irradiance) zeigt.
Wir verwenden nur einen Vorhersagehorizont von 48 Stunden, d.h. bis 4. April z.Zt.
Wir hatten gestern typisches Aprilwetter. SolCast lieferte mit -6,5% Tagesabweichung das beste Ergebnis. Allerdings ist diese Instanz auch schon am längsten bzgl. Autokorrektur trainiert.
Wie abwechslungsreich gestern die Sonneneinstrahlung war sieht man an dem anghängten SVG.
LG,
Heiko
Zitat von: DS_Starter am 03 April 2024, 08:43:17Wie abwechslungsreich gestern die Sonneneinstrahlung war sieht man an dem anghängten SVG.
Deine Legende auf der Y-Achse passt nicht, außer Du betreibst ein Mega-Kraftwerk ;-)
Bei mir war's ähnlich wechselhaft, siehe anbei. OpenMeteoWorld hatte "aus dem Stand heraus" 0,5% Abweichung über den ganzen Tag, wenngleich die stündliche Prognose teilweise sehr durchwachsen war.
ZitatDeine Legende auf der Y-Achse passt nicht, außer Du betreibst ein Mega-Kraftwerk ;-)
Wahrscheinlich war der Wunsch Vater des Gedankens. ;) Danke für den Hinweis. :)
@Trompeter, Frage... Woher nimmst du die Effizienz des WR?
Zitat von: DS_Starter am 03 April 2024, 10:09:54@Trompeter, Frage... Woher nimmst du die Effizienz des WR?
Die liefert mein WR "frei Haus".
Aber Du kannst es auch selbst ausreichnen, wenn Du die (DC-) Leistung der Einzelstränge und die AC-Leistung vom Wechselrichter hast...
Effizienz = AC-Leistung dividiert durch die Summe der DC-Leistungen
Ach ja ... klar, stand auf dem Schlauch. Danke.
Hallo zusammen,
seit gestern Abend funktioniert der Solar-Forecast nicht mehr. Das heißt in der Tagesgrafik wird nichts dargestellt. Hat mir jemand einen Tipp wo ich suchen muss?
Gruß
Bison
Zitat von: 300P am 02 April 2024, 22:17:27Nein - nur umstellen auf das was Du nutzen möchtest stellst du in diesem Modul ein.
Moin,
jo, habs gefunden - man muß halt nur das ctrlWeatherDev1 nehmen, schon wird es angeboten ... ich hatte versucht, ein zusätzliches ctrlWeatherDev2 einzurichten, und da wurde mir nur noch das OpenWeatherDWD, welches eingerichtet ist in meinem Fhem, angeboten ...
Danke
Gruß, Christoph
Moin,
ZitatSeit gestern Abend funktioniert der Solar-Forecast nicht mehr. Das heißt in der Tagesgrafik wird nichts dargestellt. Hat mir jemand einen Tipp wo ich suchen muss?
- einen Anlagencheck ausführen und schauen ob Fehler oder Hinweise gemeldet werden
- eventuell werden keine Daten abgerufen -> ctrlDebug=apiCall,apiProcess einschalten und das Log checken
- posten was ein "get ... solApiData" ausgibt
Das wären mal so die ersten Schritte. Ein Screenshot der Grafik wäre auch gut.
LG
Hallo DS_Starter.
der Anlagencheck sagt gut.
Siehe Anhang.
Kannst du mir sagen wie ich das CTrlDebug starten kann?
(Es kann auch sein das ich durch rumprobieren einiges verbogen habe) Sorry !!!
Gruß Bison
ZitatKannst du mir sagen wie ich das CTrlDebug starten kann?
Das ist ein Attribut. Du kannst die aus einer Liste zusammenklicken was du debuggen willst.
Aber ich sehe schon an deinen API-Daten dass dein DWD Device nur Daten mit "0" bringt:
?All => 2024-04-04 00:00:00 => Rad1h: 0
2024-04-04 01:00:00 => Rad1h: 0
2024-04-04 02:00:00 => Rad1h: 0
2024-04-04 03:00:00 => Rad1h: 0
2024-04-04 04:00:00 => Rad1h: 0
2024-04-04 05:00:00 => Rad1h: 0
2024-04-04 06:00:00 => Rad1h: 0
2024-04-04 07:00:00 => Rad1h: 0
2024-04-04 08:00:00 => Rad1h: 0
2024-04-04 09:00:00 => Rad1h: 0
2024-04-04 10:00:00 => Rad1h: 0
2024-04-04 11:00:00 => Rad1h: 0
2024-04-04 12:00:00 => Rad1h: 0
2024-04-04 13:00:00 => Rad1h: 0
2024-04-04 14:00:00 => Rad1h: 0
2024-04-04 15:00:00 => Rad1h: 0
2024-04-04 16:00:00 => Rad1h: 0
2024-04-04 17:00:00 => Rad1h: 0
2024-04-04 18:00:00 => Rad1h: 0
2024-04-04 19:00:00 => Rad1h: 0
2024-04-04 20:00:00 => Rad1h: 0
2024-04-04 21:00:00 => Rad1h: 0
2024-04-04 22:00:00 => Rad1h: 0
2024-04-04 23:00:00 => Rad1h: 0
2024-04-05 00:00:00 => Rad1h: 0
2024-04-05 01:00:00 => Rad1h: 0
2024-04-05 02:00:00 => Rad1h: 0
2024-04-05 03:00:00 => Rad1h: 0
2024-04-05 04:00:00 => Rad1h: 0
2024-04-05 05:00:00 => Rad1h: 0
2024-04-05 06:00:00 => Rad1h: 0
2024-04-05 07:00:00 => Rad1h: 0
2024-04-05 08:00:00 => Rad1h: 0
.........
Das Device wäre zu überprüfen. Mit dem angegebenen Debug solltest du mehr Infos sehen bzw. schau dir das DWD Device an.
Davon unabhängig würde ich dir empfehlen auf eine der openMeteo API's zu wechseln da du ja noch die alte MOSMIX_L Variante nutzt (vllt. auch nur die nutzen kannst).
Grüße,
Heiko
Wäre es möglich die beiden optionalen Attribute "[conprice=<Wert>:<Currency>] [feedprice=<Wert>:<Currency>]" des currentMeterDev auf Readings des <Meter Device> umzuändern?
Also quasi gemäss der Syntax aus der Hilfe auf:
[conprice=<Readingname>:<Einheit>] [feedprice=<Readingname>:<Einheit>]
Das würde das Handling bei dynamischen Tarifen deutlich erleichtern... (Ganz super wäre, wenn es aus einem anderen Device kommen könnte, also "[conprice=<Devicename>:<Readingname>:<Einheit>] [feedprice=<Devicename>:<Readingname>:<Einheit>]", aber das "Meter Device" würde auch ausreichen, dann spiegel' ich die Werte eben dorthin.)
ZitatWäre es möglich die beiden optionalen Attribute "[conprice=<Wert>:<Currency>] [feedprice=<Wert>:<Currency>]" des currentMeterDev auf Readings des <Meter Device> umzuändern?
Ja, sehe ich vor.
Hallo Heiko,
ich habe auf die Metro-Api umgestellt und sehe jetzt im Log aus auch in der SolApDate die Werte. Die Grafik wird vermutlich erst um 00:00 erflehst oder kann ich das über ein Attribut refreshen?
Danke schon mal für den Tip mit Meter-Api (und natürlich für dein Tool-> Kaffee kommt ;D
Gruß
Bison
:)
Bis 00:00 brauchst du nicht warten.
Die API kann man gezielt mit einem "get ... rooftopData" abrufen. Dann sieht man die Daten schon aufbereitet mit "get ... solApiData".
MIt dem nächsten Zyklus (Attr ctrlInterval) oder einem gezielten "get ... data" werden die Vorhersagedaten und Wetterdaten in die Grafik übernommen bzw. dort aufgebaut.
LG
Hallo Heiko,
den Befehl habe ich ausgeführt aber es sieht immer noch so aus:
Kann es sein das ich mit Set aiDecTree aus versehen was verstellt habe?
Gruß Bison
ZitatKann es sein das ich mit Set aiDecTree aus versehen was verstellt habe?
Nein.
Aber schau dir mal die Attribute graphicBeam1Content, graphicBeam2Content an.
Möglicherweise sind die verstellt.
Und poste nochmal dein Ergebnis aus "get ... solApiData".
Hallo Heiko,
hier die SolApi mit Meteo.
Was müsste bei Content Beam 1 und 2 stehen?
Gruß Werner
Hallo Heiko,
in den Readings des Moduls sehe ich auch Werte TodayHour18PV Formats 56 WH.
Gruß
Bison
Hallo Werner, die Daten sehen gut aus soweit.
Die Attr enthalten die darzustellenden Daten. Wenn sie nicht gesetzt sind (also default) passt es.
Führe mal bitte ein "set ... reset roofIdentPair" aus.
Danach poste bitte die Ausgabe von "get ... nextHours".
Und am Besten ein List deines Forecast Devices noch dazu.
Hallo Heiko,
hier die gewünschten Daten.
Gruß
Bison
Setze bitte ctrlDebug=radiationProcess und poste den Logauszug.
Hier ein Beispiel von mir:
2024.04.04 19:07:51.938 1: SolCast5 DEBUG> PV API estimate for today Hour 20 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.18 kWp
modulePeakString => 5830 W
2024.04.04 19:07:51.939 1: SolCast5 DEBUG> PV API estimate for today Hour 20 summary:
Cloudcover => 82
Forecasted temperature => 13.30 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 19:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.940 1: SolCast5 DEBUG> PV API estimate for today Hour 21 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.18 kWp
modulePeakString => 5830 W
2024.04.04 19:07:51.941 1: SolCast5 DEBUG> PV API estimate for today Hour 21 summary:
Cloudcover => 78
Forecasted temperature => 12.30 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 20:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.942 1: SolCast5 DEBUG> PV API estimate for today Hour 22 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.55 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.19 kWp
modulePeakString => 5840 W
2024.04.04 19:07:51.942 1: SolCast5 DEBUG> PV API estimate for today Hour 22 summary:
Cloudcover => 77
Forecasted temperature => 11.80 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 21:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.943 1: SolCast5 DEBUG> PV API estimate for today Hour 23 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.18 kWp
modulePeakString => 5830 W
2024.04.04 19:07:51.943 1: SolCast5 DEBUG> PV API estimate for today Hour 23 summary:
Cloudcover => 74
Forecasted temperature => 11.30 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 22:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.944 1: SolCast5 DEBUG> PV API estimate for today Hour 24 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 18.4 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.17 kWp
modulePeakString => 5820 W
2024.04.04 19:07:51.945 1: SolCast5 DEBUG> PV API estimate for today Hour 24 summary:
Cloudcover => 70
Forecasted temperature => 10.90 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 23:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.945 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 01 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 18.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.16 kWp
modulePeakString => 5810 W
2024.04.04 19:07:51.946 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 01 summary:
Cloudcover => 68
Forecasted temperature => 10.70 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 00:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.947 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 02 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 19.1 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.15 kWp
modulePeakString => 5800 W
2024.04.04 19:07:51.947 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 02 summary:
Cloudcover => 66
Forecasted temperature => 10.60 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 01:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.948 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 03 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 18.65 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.16 kWp
modulePeakString => 5810 W
2024.04.04 19:07:51.949 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 03 summary:
Cloudcover => 67
Forecasted temperature => 10.40 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 02:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.949 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 04 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 18.3 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.17 kWp
modulePeakString => 5820 W
2024.04.04 19:07:51.950 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 04 summary:
Cloudcover => 68
Forecasted temperature => 10.30 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 03:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.950 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 05 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.9 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.18 kWp
modulePeakString => 5830 W
2024.04.04 19:07:51.951 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 05 summary:
Cloudcover => 70
Forecasted temperature => 10.40 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 04:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.951 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 06 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 16.2 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.22 kWp
modulePeakString => 5870 W
2024.04.04 19:07:51.952 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 06 summary:
Cloudcover => 76
Forecasted temperature => 10.20 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 05:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.952 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 07 string Süddach ->
Estimated PV generation (calc) => 79.0 Wh
Estimated PV generation (raw) => 79 Wh
Module Temp (calculated) => 15.9 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.23 kWp
modulePeakString => 5880 W
2024.04.04 19:07:51.953 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 07 summary:
Cloudcover => 78
Forecasted temperature => 10.40 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 79 Wh
Starttime => 2024-04-05 06:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.953 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 08 string Süddach ->
Estimated PV generation (calc) => 486.8 Wh
Estimated PV generation (raw) => 486.76 Wh
Module Temp (calculated) => 15.05 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.25 kWp
modulePeakString => 5900 W
2024.04.04 19:07:51.954 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 08 summary:
Cloudcover => 83
Forecasted temperature => 10.80 °C
PV Correction mode => on_complex
PV correction factor => 0.86
PV correction quality => 0.63
PV generation forecast => 486 Wh
Starttime => 2024-04-05 07:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.955 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 09 string Süddach ->
Estimated PV generation (calc) => 762.3 Wh
Estimated PV generation (raw) => 762.3 Wh
Module Temp (calculated) => 16.05 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.23 kWp
modulePeakString => 5880 W
2024.04.04 19:07:51.955 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 09 summary:
Cloudcover => 83
Forecasted temperature => 11.80 °C
PV Correction mode => on_complex
PV correction factor => 0.90
PV correction quality => 0.73
PV generation forecast => 762 Wh
Starttime => 2024-04-05 08:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.956 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 10 string Süddach ->
Estimated PV generation (calc) => 759.6 Wh
Estimated PV generation (raw) => 759.6 Wh
Module Temp (calculated) => 17.25 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.20 kWp
modulePeakString => 5850 W
2024.04.04 19:07:51.956 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 10 summary:
Cloudcover => 83
Forecasted temperature => 13.00 °C
PV Correction mode => on_complex
PV correction factor => 0.72
PV correction quality => 0.62
PV generation forecast => 759 Wh
Starttime => 2024-04-05 09:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.957 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 11 string Süddach ->
Estimated PV generation (calc) => 655.1 Wh
Estimated PV generation (raw) => 655.05 Wh
Module Temp (calculated) => 18.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.16 kWp
modulePeakString => 5810 W
2024.04.04 19:07:51.957 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 11 summary:
Cloudcover => 82
Forecasted temperature => 14.20 °C
PV Correction mode => on_complex
PV correction factor => 0.55
PV correction quality => 0.17
PV generation forecast => 655 Wh
Starttime => 2024-04-05 10:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.958 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 12 string Süddach ->
Estimated PV generation (calc) => 1290.6 Wh
Estimated PV generation (raw) => 1290.59 Wh
Module Temp (calculated) => 21 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.10 kWp
modulePeakString => 5750 W
2024.04.04 19:07:51.958 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 12 summary:
Cloudcover => 78
Forecasted temperature => 15.50 °C
PV Correction mode => on_complex
PV correction factor => 1.03
PV correction quality => 0.97
PV generation forecast => 1290 Wh
Starttime => 2024-04-05 11:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.959 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 13 string Süddach ->
Estimated PV generation (calc) => 1233.0 Wh
Estimated PV generation (raw) => 1233 Wh
Module Temp (calculated) => 22.35 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.07 kWp
modulePeakString => 5720 W
2024.04.04 19:07:51.959 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 13 summary:
Cloudcover => 77
Forecasted temperature => 16.60 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 1233 Wh
Starttime => 2024-04-05 12:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.960 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 14 string Süddach ->
Estimated PV generation (calc) => 917.6 Wh
Estimated PV generation (raw) => 917.6 Wh
Module Temp (calculated) => 24.15 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 5670 W
2024.04.04 19:07:51.961 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 14 summary:
Cloudcover => 75
Forecasted temperature => 17.90 °C
PV Correction mode => on_complex
PV correction factor => 0.80
PV correction quality => 0.75
PV generation forecast => 917 Wh
Starttime => 2024-04-05 13:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.961 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 15 string Süddach ->
Estimated PV generation (calc) => 763.0 Wh
Estimated PV generation (raw) => 763.04 Wh
Module Temp (calculated) => 25.5 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.01 kWp
modulePeakString => 5640 W
2024.04.04 19:07:51.962 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 15 summary:
Cloudcover => 74
Forecasted temperature => 19.00 °C
PV Correction mode => on_complex
PV correction factor => 0.76
PV correction quality => 0.69
PV generation forecast => 763 Wh
Starttime => 2024-04-05 14:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.962 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 16 string Süddach ->
Estimated PV generation (calc) => 407.0 Wh
Estimated PV generation (raw) => 406.98 Wh
Module Temp (calculated) => 26.1 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.03 kWp
modulePeakString => 5620 W
2024.04.04 19:07:51.963 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 16 summary:
Cloudcover => 74
Forecasted temperature => 19.60 °C
PV Correction mode => on_complex
PV correction factor => 0.51
PV correction quality => 0.05
PV generation forecast => 407 Wh
Starttime => 2024-04-05 15:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.963 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 17 string Süddach ->
Estimated PV generation (calc) => 386.6 Wh
Estimated PV generation (raw) => 386.64 Wh
Module Temp (calculated) => 26.6 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.04 kWp
modulePeakString => 5610 W
2024.04.04 19:07:51.964 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 17 summary:
Cloudcover => 74
Forecasted temperature => 20.10 °C
PV Correction mode => on_complex
PV correction factor => 0.72
PV correction quality => 0.60
PV generation forecast => 386 Wh
Starttime => 2024-04-05 16:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.964 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 18 string Süddach ->
Estimated PV generation (calc) => 152.2 Wh
Estimated PV generation (raw) => 152.19 Wh
Module Temp (calculated) => 25.6 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.02 kWp
modulePeakString => 5630 W
2024.04.04 19:07:51.965 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 18 summary:
Cloudcover => 76
Forecasted temperature => 19.60 °C
PV Correction mode => on_complex
PV correction factor => 0.57
PV correction quality => 0.25
PV generation forecast => 152 Wh
Starttime => 2024-04-05 17:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.966 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 19 string Süddach ->
Estimated PV generation (calc) => 95.0 Wh
Estimated PV generation (raw) => 95 Wh
Module Temp (calculated) => 26.45 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.04 kWp
modulePeakString => 5610 W
2024.04.04 19:07:51.966 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 19 summary:
Cloudcover => 73
Forecasted temperature => 19.70 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 95 Wh
Starttime => 2024-04-05 18:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.967 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 20 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 24.95 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.00 kWp
modulePeakString => 5650 W
2024.04.04 19:07:51.967 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 20 summary:
Cloudcover => 75
Forecasted temperature => 18.70 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 19:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.968 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 21 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 24.15 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 5670 W
2024.04.04 19:07:51.968 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 21 summary:
Cloudcover => 75
Forecasted temperature => 17.90 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 20:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.969 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 22 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 23.4 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.04 kWp
modulePeakString => 5690 W
2024.04.04 19:07:51.969 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 22 summary:
Cloudcover => 74
Forecasted temperature => 16.90 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 21:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.970 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 23 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 22.3 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.07 kWp
modulePeakString => 5720 W
2024.04.04 19:07:51.970 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 23 summary:
Cloudcover => 74
Forecasted temperature => 15.80 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 22:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:07:51.971 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 24 string Süddach ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 50 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.64 kWp
modulePeakString => 5010 W
2024.04.04 19:07:51.972 1: SolCast5 DEBUG> PV API estimate for tomorrow Hour 24 summary:
Cloudcover => 0
Forecasted temperature => 25 °C
PV Correction mode => on_complex
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 23:00:00
Total Rain last hour => 0 kg/m2
Wenn du die Code-Tags verwendest, kannst du die Ausgabe direkt hier posten. Das liest sich einfacher für mich.
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 20 string String1 ->
Estimated PV generation (calc) => 3.0 Wh
Estimated PV generation (raw) => 3 Wh
Module Temp (calculated) => 12.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 20 string String2 ->
Estimated PV generation (calc) => 3.0 Wh
Estimated PV generation (raw) => 3 Wh
Module Temp (calculated) => 12.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 20 string String3 ->
Estimated PV generation (calc) => 3.0 Wh
Estimated PV generation (raw) => 3 Wh
Module Temp (calculated) => 12.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV forecast start time 2024-04-04 19:00:00 limited to capacity:W Watt due to inverter capacity
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 20 summary:
Cloudcover => 100
Forecasted temperature => 12.70 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 19:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 21 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 21 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 21 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 21 summary:
Cloudcover => 100
Forecasted temperature => 11.70 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 20:00:00
Total Rain last hour => 0.10 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 22 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 22 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 22 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 22 summary:
Cloudcover => 100
Forecasted temperature => 11.00 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 21:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 23 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 10.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 23 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 10.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 23 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 10.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 23 summary:
Cloudcover => 100
Forecasted temperature => 10.70 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 22:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 24 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.45 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.01 kWp
modulePeakString => 310 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 24 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.45 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.01 kWp
modulePeakString => 310 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 24 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.45 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.01 kWp
modulePeakString => 310 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 24 summary:
Cloudcover => 71
Forecasted temperature => 10.20 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 23:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11.65 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11.65 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 11.65 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 summary:
Cloudcover => 93
Forecasted temperature => 9.90 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 00:00:00
Total Rain last hour => 0.10 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 summary:
Cloudcover => 100
Forecasted temperature => 9.80 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 01:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.8 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 summary:
Cloudcover => 100
Forecasted temperature => 9.80 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 02:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.9 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.9 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.9 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
modulePeakString => 320 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 summary:
Cloudcover => 100
Forecasted temperature => 9.90 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 03:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.35 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.01 kWp
modulePeakString => 310 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.35 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.01 kWp
modulePeakString => 310 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 17.35 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.01 kWp
modulePeakString => 310 W
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 summary:
Cloudcover => 69
Forecasted temperature => 9.60 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 04:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 06 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
Module Temp (calculated) => 9.7 °C
Win(+)/Loss(-) String Peak Power by Temp => 0.02 kWp
Könnte eine Spur sein.
Der Hinweis:
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV forecast start time 2024-04-04 19:00:00 limited to capacity:W Watt due to inverter capacity
2024.04.04 19:13:04 1: SolarForecast DEBUG> PV API estimate for today Hour 20 summary:
Cloudcover => 100
Forecasted temperature => 12.70 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Du hast angegeben:
2024-04-03 16:34:02 currentInverterDev InvDummy pv=pv:W etotal=etotal:wH capacity=capacity:W
Aber capacity wird nur so angegeben:
capacity Bemessungsleistung des Wechselrichters gemäß Datenblatt (max. möglicher Output in Watt)
Also z.B.
currentInverterDev InvDummy pv=pv:W etotal=etotal:wH capacity=500
Hallo Heiko,
es erscheint nun in Autokorrektur (Start in 1.99h).
Ich warte dann mal.
Gruß Bison
Ja, das ist ok.
Aber jetzt nach der Änderung poste nochmal bitte die Ausgabe von ctrlDebug=radiationProcess.
Achte darauf dass der morgige Tag auch mit dabei ist.
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 21 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 21 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 21 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 21 summary:
Cloudcover => 100
Forecasted temperature => 11.70 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 20:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 22 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 22 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 22 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 22 summary:
Cloudcover => 100
Forecasted temperature => 11.00 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 21:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 23 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 23 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 23 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 23 summary:
Cloudcover => 100
Forecasted temperature => 10.70 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 22:00:00
Total Rain last hour => 0.10 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 24 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 24 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 24 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for today Hour 24 summary:
Cloudcover => 71
Forecasted temperature => 10.20 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-04 23:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 01 summary:
Cloudcover => 93
Forecasted temperature => 9.90 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 00:00:00
Total Rain last hour => 0.10 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 02 summary:
Cloudcover => 100
Forecasted temperature => 9.80 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 01:00:00
Total Rain last hour => 0.10 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 03 summary:
Cloudcover => 100
Forecasted temperature => 9.80 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 02:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 04 summary:
Cloudcover => 100
Forecasted temperature => 9.90 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 03:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 05 summary:
Cloudcover => 69
Forecasted temperature => 9.60 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 04:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 06 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 06 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 06 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 06 summary:
Cloudcover => 98
Forecasted temperature => 9.20 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => -
PV generation forecast => 0 Wh
Starttime => 2024-04-05 05:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 07 string String1 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 07 string String2 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 07 string String3 ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 07 summary:
Cloudcover => 73
Forecasted temperature => 9.20 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.00
PV generation forecast => 0 Wh
Starttime => 2024-04-05 06:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 08 string String1 ->
Estimated PV generation (calc) => 7.0 Wh
Estimated PV generation (raw) => 7 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 08 string String2 ->
Estimated PV generation (calc) => 7.0 Wh
Estimated PV generation (raw) => 7 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 08 string String3 ->
Estimated PV generation (calc) => 7.0 Wh
Estimated PV generation (raw) => 7 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 07:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 08 summary:
Cloudcover => 96
Forecasted temperature => 9.20 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.20
PV generation forecast => 0 Wh
Starttime => 2024-04-05 07:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 09 string String1 ->
Estimated PV generation (calc) => 32.0 Wh
Estimated PV generation (raw) => 32 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 09 string String2 ->
Estimated PV generation (calc) => 42.0 Wh
Estimated PV generation (raw) => 42 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 09 string String3 ->
Estimated PV generation (calc) => 29.0 Wh
Estimated PV generation (raw) => 29 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 08:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 09 summary:
Cloudcover => 100
Forecasted temperature => 9.80 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.52
PV generation forecast => 0 Wh
Starttime => 2024-04-05 08:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 10 string String1 ->
Estimated PV generation (calc) => 95.0 Wh
Estimated PV generation (raw) => 95 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 10 string String2 ->
Estimated PV generation (calc) => 127.0 Wh
Estimated PV generation (raw) => 127 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 10 string String3 ->
Estimated PV generation (calc) => 40.0 Wh
Estimated PV generation (raw) => 40 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 09:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 10 summary:
Cloudcover => 100
Forecasted temperature => 10.90 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.93
PV generation forecast => 0 Wh
Starttime => 2024-04-05 09:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 11 string String1 ->
Estimated PV generation (calc) => 152.0 Wh
Estimated PV generation (raw) => 152 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 11 string String2 ->
Estimated PV generation (calc) => 169.0 Wh
Estimated PV generation (raw) => 169 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 11 string String3 ->
Estimated PV generation (calc) => 74.0 Wh
Estimated PV generation (raw) => 74 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 10:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 11 summary:
Cloudcover => 100
Forecasted temperature => 13.00 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.93
PV generation forecast => 0 Wh
Starttime => 2024-04-05 10:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 12 string String1 ->
Estimated PV generation (calc) => 205.0 Wh
Estimated PV generation (raw) => 205 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 12 string String2 ->
Estimated PV generation (calc) => 191.0 Wh
Estimated PV generation (raw) => 191 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 12 string String3 ->
Estimated PV generation (calc) => 113.0 Wh
Estimated PV generation (raw) => 113 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 11:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 12 summary:
Cloudcover => 66
Forecasted temperature => 15.30 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.98
PV generation forecast => 0 Wh
Starttime => 2024-04-05 11:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 13 string String1 ->
Estimated PV generation (calc) => 234.0 Wh
Estimated PV generation (raw) => 234 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 13 string String2 ->
Estimated PV generation (calc) => 186.0 Wh
Estimated PV generation (raw) => 186 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 13 string String3 ->
Estimated PV generation (calc) => 149.0 Wh
Estimated PV generation (raw) => 149 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 12:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 13 summary:
Cloudcover => 97
Forecasted temperature => 17.60 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.88
PV generation forecast => 0 Wh
Starttime => 2024-04-05 12:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 14 string String1 ->
Estimated PV generation (calc) => 243.0 Wh
Estimated PV generation (raw) => 243 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 14 string String2 ->
Estimated PV generation (calc) => 164.0 Wh
Estimated PV generation (raw) => 164 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 14 string String3 ->
Estimated PV generation (calc) => 177.0 Wh
Estimated PV generation (raw) => 177 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 13:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 14 summary:
Cloudcover => 24
Forecasted temperature => 19.60 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.93
PV generation forecast => 0 Wh
Starttime => 2024-04-05 13:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 15 string String1 ->
Estimated PV generation (calc) => 233.0 Wh
Estimated PV generation (raw) => 233 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 15 string String2 ->
Estimated PV generation (calc) => 130.0 Wh
Estimated PV generation (raw) => 130 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 15 string String3 ->
Estimated PV generation (calc) => 193.0 Wh
Estimated PV generation (raw) => 193 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 14:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 15 summary:
Cloudcover => 97
Forecasted temperature => 21.10 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.89
PV generation forecast => 0 Wh
Starttime => 2024-04-05 14:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 16 string String1 ->
Estimated PV generation (calc) => 180.0 Wh
Estimated PV generation (raw) => 180 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 16 string String2 ->
Estimated PV generation (calc) => 90.0 Wh
Estimated PV generation (raw) => 90 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 16 string String3 ->
Estimated PV generation (calc) => 175.0 Wh
Estimated PV generation (raw) => 175 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 15:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 16 summary:
Cloudcover => 75
Forecasted temperature => 21.10 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.79
PV generation forecast => 0 Wh
Starttime => 2024-04-05 15:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 17 string String1 ->
Estimated PV generation (calc) => 95.0 Wh
Estimated PV generation (raw) => 95 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 17 string String2 ->
Estimated PV generation (calc) => 61.0 Wh
Estimated PV generation (raw) => 61 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 17 string String3 ->
Estimated PV generation (calc) => 106.0 Wh
Estimated PV generation (raw) => 106 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 16:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 17 summary:
Cloudcover => 93
Forecasted temperature => 21.10 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.73
PV generation forecast => 0 Wh
Starttime => 2024-04-05 16:00:00
Total Rain last hour => 0.00 kg/m2
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 18 string String1 ->
Estimated PV generation (calc) => 42.0 Wh
Estimated PV generation (raw) => 42 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 18 string String2 ->
Estimated PV generation (calc) => 37.0 Wh
Estimated PV generation (raw) => 37 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 18 string String3 ->
Estimated PV generation (calc) => 48.0 Wh
Estimated PV generation (raw) => 48 Wh
modulePeakString => 300 W
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV forecast start time 2024-04-05 17:00:00 limited to capacity Watt due to inverter capacity
2024.04.04 20:14:28 1: SolarForecast DEBUG> PV API estimate for tomorrow Hour 18 summary:
Cloudcover => 100
Forecasted temperature => 20.10 °C
PV Correction mode => standby
PV correction factor => 1.00
PV correction quality => 0.75
Die Angabe von currentInverterDev ist noch nicht korrekt.
Wie hast du currentInverterDev gesetzt?
Hallo Heiko,
hatte dort noch einen Schreibfehler die wH statt Wh. Nun steht er wieder auf (Start in 1.99h)
InvDummy pv=pv:W etotal=etotal:wH capacity=capacity
Gruß Bison
Trotzdem noch falsch ;-)
Richtig wäre:
InvDummy pv=pv:W etotal=etotal:Wh capacity=500
500 ist natürlich nur ein Beispiel. Hier setzt du die Nominalleistung deines WR in Watt ein.
Hallo Heiko,
in meinem InvDummy gibt es das Reading capacity in welchem ich den Wert stehen habe. Aber da fällt mir ein das ich dieses Reading mit einem Notify regelmäßig beschreibe.
Ich teste das mal.
Gruß Bison
Zitatin meinem InvDummy gibt es das Reading capacity in welchem ich den Wert stehen habe. Aber da fällt mir ein das ich dieses Reading mit einem Notify regelmäßig beschreibe.
Das mag sein. Nur ist in dem Schlüssel ein fester Wert und kein Reading einzutragen. Wenn du mehrere WR in dem Dummy zusammenführst, addierst du die Nominalleistungen aller WR zusammen und schreibst die Summe in den Schlüssel.
Hallo Heiko,
das war das ganze Problem! Verd.....
Danke Danke Danke
Gruß Bison
:)
In das nächste Release baue ich eine Syntaxprüfung für diesen Schlüssel ein. Dann merkt man das gleich bei der Eingabe.
Zitat von: DS_Starter am 04 April 2024, 12:27:55Davon unabhängig würde ich dir empfehlen auf eine der openMeteo API's zu wechseln da du ja noch die alte MOSMIX_L Variante nutzt (vllt. auch nur die nutzen kannst).
Wie mache ich diesen Wechsel und wo bekomme ich die Informationen dazu, wie ich mein SolarForecast Device dann umstellen muss?
LG
Holger
ZitatWie mache ich diesen Wechsel und wo bekomme ich die Informationen dazu, wie ich mein SolarForecast Device dann umstellen muss?
Das ist sehr einfach.
Du wählst eine der angebotenen openMeteo API's im Attribut "ctrlWeatherDev1" als Wetteranbieter aus.
Was die API machen ist im Hilfetext erläutert.
Technisch bedingt wird diese API automatisch auch als "currentRadiationAPI" eingesetzt.
Das wars auch schon.
Edit: Danach sicherheitshalber einen Anlagencheck ausführen (die Zahnräder in der Grafik).
LG,
Heiko
ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 9500 daily API requests is reached or already exceeded. Process is exited.
was ist denn da los heute?
Das ist der Daily Request-Zähler im Modul. Er ist begrenzt auf etwas unter 10000. Was hast du gemacht?
Mein Zähler für die Ensemble steht auf
?All => lastretrieval_time: 2024-04-05 10:29:21
lastretrieval_timestamp: 1712305761
response_message: success
todayDoneAPIcalls: 42
todayDoneAPIrequests: 1680
(sieht man mit "get ... solApiData")
Ich habe 2 Strings. Du?
In meinem contrib liegt die Vorabversion 1.17.5.
Was ist drin:
- currentInverterDev: Syntax Check für Schlüssel "capacity" falls er gesetzt ist
- eine Berechnung des minimalen Open-Meteo Abrufintervalls. Im Normalfall ohne Bedeutung, allerdings
könnte bei mehreren/vielen Strings und der Benutzung von Ensamble-Abrufen das Tageskontingent von 10000
Requests erreicht werden. Um der Regelung bzgl. der kostenfreien Nutzung Rechnung zu tragen, wird das
Kontingent und das Abrufintervall überwacht/reguliert.
- currentMeterDev: die Schlüssel conprice und feedprice können auf verschiedene Weise definiert werden:
[conprice=<Feld>] [feedprice=<Feld>]
conprice Preis für den Bezug einer kWh (optional). Die Angabe <Feld> ist in einer der folgenden Varianten möglich:
<Preis>:<Währung> - Preis als numerischer Wert und dessen Währung
<Reading>:<Währung> - Reading des Meter Device das den Preis enthält : Währung
<Device>:<Reading>:<Währung> - beliebiges Device und Reading welches den Preis enthält : Währung
feedprice Vergütung für die Einspeisung einer kWh (optional). Die Angabe <Feld> ist in einer der folgenden Varianten möglich:
<Vergütung>:<Währung> - Vergütung als numerischer Wert und dessen Währung
<Reading>:<Währung> - Reading des Meter Device das die Vergütung enthält : Währung
<Device>:<Reading>:<Währung> - beliebiges Device und Reading welches die Vergütung enthält : Währung
Ihr könnt die V schon ausprobieren. Restart nach Download nicht vergessen.
Grüße,
Heiko
Ich hab 5 Strings. Aber irgend wie ist da was richtig faul.
Ensemble habe ich disabled wegen den requests.
Da scheint was mit dem Inverterdummy nicht zu passen..sind aber alles die selben Werte/Devices beim füttern.
Anbei die Devs der Forecasts..beides DWD. Einmal DWD-api einmal OpenMeteoDWD.
Übersehe ich da was?
EDit:
?All => lastretrieval_time: 2024-04-05 09:50:13
lastretrieval_timestamp: 1712303413
response_message: success
todayDoneAPIcalls: 95
todayDoneAPIrequests: 9500
Sieht mir so aus, als wäre dein FHEM mal abgestürzt und als es wieder startete war etotal des Inverterdummy zumindest für einen kurzen Moment mal 0. Danach wieder mit dem normalen Startwert. Dadurch kam es zu dem starken Sprung. Morgen nach der Mitternachtsbereinigung wird es wieder gut aussehen.
Bzgl. der todayDoneAPIrequests ... die Ensemble Calls haben ein Requestäquivalent von 20, d.h. ein Call führt 5 (Strings) x 20 Requests = 100 Requests aus. Ich rufe per default 4 x pro Stunde ab, macht bei dir 400 Requests pro Stunde. Nach 10 Stunden sind 4000 Requests verbraucht.
Das sind zwar noch keine 9600 wie in deinem Problem, nur zur Erläuterung. In der neuen Version werte ich diese Kennzahlen aus und passe bei Bedarf das API-Abrufintervall an... hätte nicht gedacht bei 10000 Requests darauf achten zu müssen. ;)
Die Zähler werden kurz nach Mitternacht zurückgesetzt. Aber nur wenn dein Device nicht disabled ist.Du solltest es also wieder enablen wenn du magst.
Ja, Maschine ist heute nacht abgesemmlt. Grund konnte ich nicht finden.
Es wurde ein Restart ausgeführt und nach 17min war danach ende. Ich tippe auf einen hardware defekt.
Mal beobachten.
Wenn es zu einer ungünstigen Zeit passierte, konnten vielleicht die Mitternachtsaktivitäten (diverse Zählerresets etc.) nicht ausgeführt werden und deswegen kamen die API-Requests bei dir in diese Regionen.
Jepp, heute sieht es wieder normal aus.
Nur die History hat es mir (hoffentlich nicht so schlimm) versemmelt.
Sieht mir so aus, als wäre dein FHEM mal abgestürzt und als es wieder startete war etotal des Inverterdummy zumindest für einen kurzen Moment mal 0Könntest du das nicht auf plausibilität prüfen? Sowas wie der Wert (Ist ja ein Totawert) kann nicht kleiner sein wie der vorherige?
Damit sowas nicht passieren kann.
Mir ist auch aufgefallen das der etotal nicht angeglichen wurde. Also der "pvrl" wert wurde neu gesetzt mit den hohen Werten. Der "etotal" ist aber auf dem Stand vom letzten Monat.
Verwirrt mich etwas.
ZitatKönntest du das nicht auf plausibilität prüfen? Sowas wie der Wert (Ist ja ein Totawert) kann nicht kleiner sein wie der vorherige?
Das passiert bereits.
Der Sachverhalt liegt etwas anders. Der Vorwert ist(könnte) 0 sein und der darauf folgende gemeldete Wert des etotal der WR ist sein wahres aktuelles etotal. Daraus ergibt sich evtl. eine große Differenz.
Das aktuelle etotal wird jede! Stunde initial gespeichert um daraus die Stundendifferenzen der Erzeugung ableiten zu können. (pvHistory -> Tag -> Stunde -> etotal: ...)
Ich überlege mal was man da evtl. machen kann. 0 muß jedenfalls auch als Meldewert erlaubt sein und mit einer festen Differenz kann man auch nicht arbeiten. Ein Rückblick auf die History geht auch nicht denn es könnte der WR/Dummy ja ausgetauscht sein und ganz andere Werte als in der History vorhanden melden.
ZitatMir ist auch aufgefallen das der etotal nicht angeglichen wurde. Also der "pvrl" wert wurde neu gesetzt mit den hohen Werten. Der "etotal" ist aber auf dem Stand vom letzten Monat.
Verwirrt mich etwas.
Auch das wird eine Folge deines Crash sein. Die pvHistory ist ein Ringspeicher. Zu Beginn des Tages wenige Sekunden nach 00:00 wird der aktuelle Tag aus der History gelöscht, d.h. z.B. heute das Datum 06. Der bisherige Inhalt von 06 ist der Tag 06 des Vormonats.
Wenn die Nachtverarbeitung nicht laufen konnte, dann wurde der alte Tag 06 nicht gelöscht.
OK,Danke. Dann wird es klarer für mich.
Ich habe evtl. eine Lösung für dieses Etotal-Schwellenwert Problem gefunden.
Morgen muss sich aber noch zeigen dass keine negativen Side-Effekte zu bemerken sind.
Das Ganze funktioniert nur wenn der Schlüssel capacity in currentInverterDev gesetzt ist.
Dieser Schlüssel ist bekanntermaßen optional.
Das Update liegt in meinem contrib.
LG,
Heiko
Ich konnte bisher keine negativen Seiteeffekte der letzten Änderung erkennen.
Heute Abend schaue ich nochmal. Sollte nichts aufgetreten sein, übernehme ich die Änderung mit ins Repo.
Da nach wie vor alle ok aussieht, habe ich die neue V eingecheckt.
Ist dann morgen früh im Update enthalten.
Ich bin sehr daran interessiert, von anderen Nutzern folgende Daten zu bekommen:
Für den Zeitraum 27.März - 3.April, sowie vom 4.April - 11.April
- Vom DWD vorhergesagte solare Einstrahlung
- Vom Modul SolarForecast vorhergesagtes solares Ergebnis
- Tatsächlich gemessenes solares Ergebnis
- Ungefährer Standort der Anlage
Warum? Derzeit ist die Energiewelt etwas in Aufregung, weil es über das Osterwochenende zu einer signifikanten Abweichung zwischen Prognose und solarer Erzeugung gekommen ist. Einer der Netzbetreiber behauptet, dass daran nicht nur der Saharastaub Schuld ist, sondern insbesondere am Ostersamstag eine "nicht optimale Wettervorhersage". Eine der kursierenden Zahlen besagt, dass durch den notwendigen Zukauf von Reservekapazitäten alleine in Baden-Württemberg Mehrkosten von 10 Millionen Euro entstanden sind.
Ich möchte gerne mal sehen, ob sich das in Euren/unseren Daten ebenfalls sehen lässt. Eines meiner Forschungsprojekte vor einigen Jahren war die geodatenbasierte Visualisierung. Möglicherweise könnte man das wieder aufkochen, um die Genauigkeit der Vorhersagen zu kontrollieren.
Selbstverständlich sage ich zu, dass alle mir zur Verfügung stehenden Daten vertraulich behandelt werden, nicht an Dritte gehen und damit kein Geld verdient wird (Standard-Verhalten bei Forschungsdaten).
LG
pah
Zitat von: Prof. Dr. Peter Henning am 08 April 2024, 10:50:56Ich bin sehr daran interessiert, von anderen Nutzern folgende Daten zu bekommen:
Für den Zeitraum 27.März - 3.April, sowie vom 4.April - 11.April
- Vom DWD vorhergesagte solare Einstrahlung
- Vom Modul SolarForecast vorhergesagtes solares Ergebnis
- Tatsächlich gemessenes solares Ergebnis
- Ungefährer Standort der Anlage
DWD habe ich als Österreicher nie genutzt, ich kann vom Osterwochenende (bzw. generell der Zeit vor dem 02.04.2024 nur mit Daten der SolCast-API aufwarten, aber dazu gleich im Detail mehr:
Zitat von: Prof. Dr. Peter Henning am 08 April 2024, 10:50:56- Vom DWD vorhergesagte solare Einstrahlung
- Vom Modul SolarForecast vorhergesagtes solares Ergebnis
DWD habe ich wie gesagt nicht, und was ich auch nicht habe, ist die "Rohdaten" aus der API. Es sei denn die werden irgendwo (länger) gespeichert und ich könnte sie dann noch abrufen. Letztendlich "verrechnet" SolarForecast die Daten der API ja mit den eigenen Lernfaktoren.
Zitat von: Prof. Dr. Peter Henning am 08 April 2024, 10:50:56- Ungefährer Standort der Anlage
Ich sag' mal im Speckgürtel von Wien, nordöstlich gelegen.
Siehe Grafik vom Osterwochenende im Anhang, wirklich extrem war die Abweichung meiner Meinung nach am Karsamstag. Da hat es bis ca. 10:00 ganz gut gepasst und dann auch wieder nach 16:00. Dazwischen war die Prognose hoffnungslos überoptimistisch. Ich kann mich an den Tag nicht mehr im Detail erinnern, aber kann mir nicht vorstellen, dass die extreme Abweichung vom Saharastaub gewesen sein kann. Da hätten wir einen Sandsturm wie in der Wüste haben müssen, und das gab's definitiv nicht.
Der Ostersonntag hat da dann um die Mittagszeit ein bisschen ins Gegenteil gedreht, der prognostizierte Einbruch kam 2 Stunden später und nicht ansatzweise so heftig wie vorhergesagt.
Am Ostermontag wurde die Kurve bereits um 11:00 flacher als prognostiziert und konnte erst ab 15:00 wieder zur Prognose aufschließen. Die Abweichung ist aber weit nicht so extrem wie am Karsamstag.
Die Tage davor waren recht unaufgeregt, daher kein Attachment dazu.
Ich könnte DWD Werte bringen, wahlweise entweder die normale Global Irradiation oder die Tilted von DWD ICON.
Das Modul zeichnet jede Stunde separat auf. Die Rad1h kann man direkt ablesen, ebenfalls die Erzeugung.
Die Forecast ist mit einem Faktor belastet der aber auch aufgezeichnet wird. Das kann man zurückrechnen.
Ein Beispiel vom 27.03. , Stunde 11 (10:00 - 11:00):
11 => etotal: 57657949, pvfc: 3882, pvrl: 4301, pvrlvd: 1, rad1h: 2910
confc: 880, con: 928, gcon: 0, gfeedin: 3373
DoN: 1, sunaz: 146, sunalt: 37
batintotal: 150, batin: 0, batouttotal: 210, batout: 0
wid: 2, wcc: 73, rr1c: 0.00, temp: 14.10, pvcorrf: 1.00/-
rad1h - Globastrahlung vom Dienst DWD oder DWD ICON je nach Modell
pvrl - reale Erzeugung in Wh
pvfc - Forecast (behaftet mit dem Faktor pvcorrf -> hier 1.00)
d.h. die Forecast vom Dienst war pvfc = pvfc(dwd) * 1.00 , d.h. pvfc(dwd) = pvfc / pvcorrf
Wenn das helfen würde, könnte ich bzw. noch weitere User mit DWD Verwendung ein paar Zahlenkolonnen für die Tage zusammenstellen. Ist ein bisschen Handarbeit, doch kask hatte sich ein Tool gebaut welches die pvHistory elektronisch einlesen und auswerten kann. Vllt. kann es hier helfen.
Hi pah,
bei mir sehen die Vorhersagen ganz ok aus.
Außer am 30.03. da war es wirklich total daneben.
Siehe Screenshots.
Ich habe aber auch nur die Vorhersage Charts die ich erstelle.
Ich speicher die ganzen DWD Daten nicht ab, Kann dir aber die Stations IDs nennen von denen ich die Abfrage mache.
Mein Standort kann ich gerne mit dir teilen, schreibe mir einfach eine PM.
Gruß,
Stefan
Bei mir Fehlanzeige - hab am Sonntag mein Solarforecast-Device zerschossen und komplett neu aufgesetzt.
Konnte auch nicht die Daten wieder einspielen - kam immer eine Fehlermeldung das im Batterie Setup ,,cap" nicht definiert sei...(den hatte ich nicht definiert)
Alternativ schmierte FHEM ab wenn ich Batterieparameter ändern wollte.
Ich habe leider erst nach 2 Stunden dann erkannt das dieser Parameter zwar optional anzugeben ist, aber das dies evtl. allein wohl dann mit meinen alten kopierten Attributen dies in dieser Konstellation verhindert hat....
Somit hatte ich einfach voher von Grundauf neu anfangen und hab dazu vorher natürlich alle Datenfiles von dem Modul dazu von der Festplatte verbannt....
Daher keine Daten mehr da 🙊
Hallo pah und andere,
Ich habe hier 3 DWD Stationen mit Moxmix-S konfiguriert. IDs: 10400, 10410, H419.
Im Anhang die von Heiko genannten Zeilen mit pvfc, pvrl, pvcorrf und rad1h der letzten Tage.
Grüße,
Guido.
Hallo,
das unterstütze ich sehr gerne, da dieses tolle Modul (bzw. die verwendeten Vorhersagemodelle) mit sonst wirklich sehr guten Prognosen am Karsamstag tatsächlich auch bei mir daneben lag.
Zitat von: Prof. Dr. Peter Henning am 08 April 2024, 10:50:56Für den Zeitraum 27.März - 3.April, sowie vom 4.April - 11.April
- Vom DWD vorhergesagte solare Einstrahlung
- Vom Modul SolarForecast vorhergesagtes solares Ergebnis
- Tatsächlich gemessenes solares Ergebnis
27.03.: pvfc: 22391, pvrl: 18655
28.03.: pvfc: 14634, pvrl: 14078
29.03.: pvfc: 15726, pvrl: 11763
30.03.: pvfc: 25421, pvrl: 18619
31.03.: pvfc: 22261, pvrl: 21510
01.04.: pvfc: 15423, pvrl: 14516
02.04.: pvfc: 17345, pvrl: 14179
03.04.: pvfc: 11117, pvrl: 9769
Am 30.03. gab es signifikante Abweichungen in den Stunden 14 (fc: 4031, rl: 3217, rad1h: 1860, pvcorrf: 1.07/0.87), 15 (fc: 3120, rl: 1840, rad1h: 1660, pvcorrf: 0.81/0.40), 17 (fc: 1968, rl: 446, rad1h: 860, pvcorrf: 1.13/0.20) und 18 (fc: 1011, rl: 129, rad1h: 390, pvcorrf: 1.28/0.78). Stunde 16 (fc: 1276, rl: 959, rad1h: 1260, pvcorrf: 0.50/0.00) war dagegen noch halbwegs nahe dran.
04.04.: pvfc: 10957, pvrl: 11000
05.04.: pvfc: 18039, pvrl: 17393
06.04.: pvfc: 25934, pvrl: 26907
07.04.: pvfc: 28401, pvrl: 23702
08.04.: pvfc: 27728, pvrl: 23156
Zitat von: Prof. Dr. Peter Henning am 08 April 2024, 10:50:56- Ungefährer Standort der Anlage
Westlicher Stadtrand von Berlin.
Viele Grüße
Christian
Ich habe seit vergangener Woche einen 12. Consumer im Modul definiert. Schon bei 11 wurden die beiden äußeren Icons in der grafischen Übersicht nicht vollständig angezeigt. Nun verschwinden die Icons links und rechts nahezu vollständig inklusive der darunter angezeigten Werte.
Ließe sich vielleicht ab einer bestimmten Anzahl an Consumer Devices eine zweite Zeile eröffnen?
Aus aktuellem Anlass habe ich dem Modul die Möglichkeit spendiert die pvHistory in eine CSV-Datei exportieren zu können.
get ... pvHistory exportToCsv
Damit kann man solche Fragestellungen wie pah sie aufgeworfen hat recht einfach bedienen.
Die entstehende CSV kann man z.B. in Excel einlesen und dort nach Bedarf auswerten.
(V liegt in meinem contrib)
@pah,
ich habe dir eine Excel angehängt, welche die relevanten Zeiträume abbildet. Der Datenlieferant ist DWD ICON, d.h. die Rad1h Werte sind Global Tilted Irradiation GTI.
Für DWD MOSMIX reiche ich die Werte nach -> die Dataei PVH_Export_SolarForecast_SolDwd.xlsx enthält die DWD MOSMIX Daten.
Edit: Standort ist ca. 25 km südwestlich von Leipzig.
@cbl, mach mal bitte ein Screenhot der gesamten Grafik (mit Balken).
Bei mir sehe ich momentan kein Prob mit zu vielen Consumern und vermute eine Abhängigkeit in der Gesamtzusammenstellung.
ZitatCode Auswählen
get ... pvHistory exportToCsv
Das ist mal Sinnvoll alleine zum bereinigen. Dann kann man wenigstens schnell sondieren wo die History kaputt ist. Wenn diese kaputt ist.
Dein Excelfile kann ich in Libre nicht öffnen. Da stehen fast nur Fehler:502 drin. Mal so als Info.
Edit: Funktioniert doch.
Ich habe jetzt das SolarForecast Modul bei mir implementiert. Vielen Dank für die tolle Arbeit. Allerdings sind mir beim letzten Update im log etliche dieser Zeilen aufgefallen:
2024.04.09 19:20:54.781 1: Forecast - the consumer device "" is invalid, the "on" state can't be identified
2024.04.09 19:20:54.785 1: Forecast - ERROR - the device "" is invalid. Please check device names in consumer "check" attribute
2024.04.09 19:20:54.786 1: Forecast - ERROR - the device "" is invalid. Please check device names in consumer "check" attribute
(davon gibt es mittlerweile hunderte Einträge).
Ich habe eigentlich bisher noch keinen Consumer definiert. Hier mein list
Internals:
FUUID 65fb55b9-f33f-8879-154e-04e7f398fee3da41
FVERSION 76_SolarForecast.pm:v1.17.6-s28768/2024-04-07
LCACHEFILE last write time: 19:30:14 File: ./FHEM/FhemUtils/ScApi_SolarForecast_Forecast
MODE Automatic - next Cycletime: 19:36:03
MODEL OpenMeteoDWDEnsembleAPI
NAME Forecast
NR 342
NTFY_ORDER 50-Forecast
STATE updated
TYPE SolarForecast
eventCount 54
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
SPGDETAIL
SPGDEV Forecast
SPGROOM
VERSION 1.17.6
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes unused
VERSION_SMUtils 1.27.2
checkM15DONE 1
OLDREADINGS:
READINGS:
2024-04-09 19:34:53 Current_AutarkyRate 1 %
2024-04-09 19:34:53 Current_Consumption 839 W
2024-04-09 19:34:53 Current_GridConsumption 833 W
2024-04-09 19:34:53 Current_GridFeedIn 0 W
2024-04-09 19:34:53 Current_PV 6 W
2024-04-09 19:34:53 Current_SelfConsumption 6 W
2024-04-09 19:34:53 Current_SelfConsumptionRate 100 %
2024-04-09 19:34:53 Current_Surplus 0 W
2024-04-09 19:00:00 LastHourGridconsumptionReal 624 Wh
2024-04-09 19:00:00 LastHourPVforecast 50 Wh
2024-04-09 19:00:00 LastHourPVreal 30 Wh
2024-04-09 19:34:53 NextHours_Sum01_PVforecast 3 Wh
2024-04-09 19:34:53 NextHours_Sum02_PVforecast 3 Wh
2024-04-09 19:34:53 NextHours_Sum03_PVforecast 3 Wh
2024-04-09 19:34:53 NextHours_Sum04_ConsumptionForecast 4611 Wh
2024-04-09 19:34:53 NextHours_Sum04_PVforecast 3 Wh
2024-04-09 19:34:53 RestOfDayConsumptionForecast 4957 Wh
2024-04-09 19:34:53 RestOfDayPVforecast 3 Wh
2024-04-09 00:59:49 Today_Hour01_GridConsumption 883 Wh
2024-04-09 00:59:49 Today_Hour01_GridFeedIn 0 Wh
2024-04-09 00:59:49 Today_Hour01_PVreal 0 Wh
2024-04-09 01:59:49 Today_Hour02_GridConsumption 518 Wh
2024-04-09 01:59:49 Today_Hour02_GridFeedIn 0 Wh
2024-04-09 01:59:49 Today_Hour02_PVreal 0 Wh
2024-04-09 02:59:49 Today_Hour03_GridConsumption 545 Wh
2024-04-09 02:59:49 Today_Hour03_GridFeedIn 0 Wh
2024-04-09 02:59:49 Today_Hour03_PVreal 0 Wh
2024-04-09 03:59:49 Today_Hour04_GridConsumption 649 Wh
2024-04-09 03:59:49 Today_Hour04_GridFeedIn 0 Wh
2024-04-09 03:59:49 Today_Hour04_PVreal 0 Wh
2024-04-09 04:59:49 Today_Hour05_GridConsumption 648 Wh
2024-04-09 04:59:49 Today_Hour05_GridFeedIn 0 Wh
2024-04-09 04:59:49 Today_Hour05_PVreal 0 Wh
2024-04-09 05:59:58 Today_Hour06_GridConsumption 660 Wh
2024-04-09 05:59:58 Today_Hour06_GridFeedIn 0 Wh
2024-04-09 05:59:58 Today_Hour06_PVreal 0 Wh
2024-04-09 06:59:49 Today_Hour07_GridConsumption 745 Wh
2024-04-09 06:59:49 Today_Hour07_GridFeedIn 0 Wh
2024-04-09 06:59:49 Today_Hour07_PVreal 0 Wh
2024-04-09 07:59:49 Today_Hour08_GridConsumption 661 Wh
2024-04-09 07:59:49 Today_Hour08_GridFeedIn 0 Wh
2024-04-09 07:59:49 Today_Hour08_PVforecast 29 Wh
2024-04-09 07:59:49 Today_Hour08_PVreal 22 Wh
2024-04-09 08:59:49 Today_Hour09_GridConsumption 942 Wh
2024-04-09 08:59:49 Today_Hour09_GridFeedIn 0 Wh
2024-04-09 08:59:49 Today_Hour09_PVforecast 146 Wh
2024-04-09 08:59:49 Today_Hour09_PVreal 56 Wh
2024-04-09 09:59:49 Today_Hour10_GridConsumption 1052 Wh
2024-04-09 09:59:49 Today_Hour10_GridFeedIn 0 Wh
2024-04-09 09:59:49 Today_Hour10_PVforecast 98 Wh
2024-04-09 09:59:49 Today_Hour10_PVreal 94 Wh
2024-04-09 10:59:49 Today_Hour11_GridConsumption 703 Wh
2024-04-09 10:59:49 Today_Hour11_GridFeedIn 0 Wh
2024-04-09 10:59:49 Today_Hour11_PVforecast 64 Wh
2024-04-09 10:59:49 Today_Hour11_PVreal 29 Wh
2024-04-09 11:59:49 Today_Hour12_GridConsumption 533 Wh
2024-04-09 11:59:49 Today_Hour12_GridFeedIn 0 Wh
2024-04-09 11:59:49 Today_Hour12_PVforecast 137 Wh
2024-04-09 11:59:49 Today_Hour12_PVreal 62 Wh
2024-04-09 12:59:58 Today_Hour13_GridConsumption 372 Wh
2024-04-09 12:59:58 Today_Hour13_GridFeedIn 0 Wh
2024-04-09 12:59:58 Today_Hour13_PVforecast 104 Wh
2024-04-09 12:59:58 Today_Hour13_PVreal 129 Wh
2024-04-09 13:59:49 Today_Hour14_GridConsumption 573 Wh
2024-04-09 13:59:49 Today_Hour14_GridFeedIn 0 Wh
2024-04-09 13:59:49 Today_Hour14_PVforecast 84 Wh
2024-04-09 13:59:49 Today_Hour14_PVreal 75 Wh
2024-04-09 14:59:49 Today_Hour15_GridConsumption 527 Wh
2024-04-09 14:59:49 Today_Hour15_GridFeedIn 0 Wh
2024-04-09 14:59:49 Today_Hour15_PVforecast 117 Wh
2024-04-09 14:59:49 Today_Hour15_PVreal 59 Wh
2024-04-09 15:59:49 Today_Hour16_GridConsumption 517 Wh
2024-04-09 15:59:49 Today_Hour16_GridFeedIn 0 Wh
2024-04-09 15:59:49 Today_Hour16_PVforecast 138 Wh
2024-04-09 15:59:49 Today_Hour16_PVreal 86 Wh
2024-04-09 16:59:49 Today_Hour17_GridConsumption 525 Wh
2024-04-09 16:59:49 Today_Hour17_GridFeedIn 0 Wh
2024-04-09 16:59:49 Today_Hour17_PVforecast 107 Wh
2024-04-09 16:59:49 Today_Hour17_PVreal 64 Wh
2024-04-09 17:59:49 Today_Hour18_GridConsumption 477 Wh
2024-04-09 17:59:49 Today_Hour18_GridFeedIn 0 Wh
2024-04-09 17:59:49 Today_Hour18_PVforecast 181 Wh
2024-04-09 17:59:49 Today_Hour18_PVreal 66 Wh
2024-04-09 18:59:49 Today_Hour19_GridConsumption 624 Wh
2024-04-09 18:59:49 Today_Hour19_GridFeedIn 0 Wh
2024-04-09 18:59:49 Today_Hour19_PVforecast 50 Wh
2024-04-09 18:59:49 Today_Hour19_PVreal 30 Wh
2024-04-09 19:34:53 Today_Hour20_GridConsumption 491 Wh
2024-04-09 19:34:53 Today_Hour20_GridFeedIn 0 Wh
2024-04-09 19:34:53 Today_Hour20_PVforecast 9 Wh
2024-04-09 19:34:53 Today_Hour20_PVreal 6 Wh
2024-04-09 19:34:53 Today_MaxPVforecast 181 Wh
2024-04-09 19:34:53 Today_MaxPVforecastTime 2024-04-09 17:00:00
2024-04-09 19:34:53 Today_PVforecast 1264 Wh
2024-04-09 19:34:53 Today_PVreal 778 Wh
2024-04-09 19:34:53 Today_SunRise 06:43
2024-04-09 19:34:53 Today_SunSet 20:07
2024-04-09 19:34:53 Tomorrow_ConsumptionForecast 17431 Wh
2024-04-09 19:34:53 Tomorrow_PVforecast 4086 Wh
2024-04-09 19:34:53 Tomorrow_SunRise 06:41
2024-04-09 19:34:53 Tomorrow_SunSet 20:08
2024-04-09 19:34:53 consumercheck name='' state='unknown' mode='can' planningstate='planned'
2024-04-09 19:34:53 consumercheck_planned_start 10.04.2024 07:00:00
2024-04-09 19:34:53 consumercheck_planned_stop 10.04.2024 08:00:00
2024-04-04 21:59:35 currentInverterDev Inverter pv=ch0_P_DC:W etotal=ch0_YieldTotal:kWh capacity=800
2024-04-04 22:04:49 currentMeterDev Stromzaehler gcon=Haus_Power_cur:W contotal=Haus_Total_in:kWh gfeedin=-gcon feedtotal=Haus_Total_out:kWh
2024-04-05 00:00:29 currentRadiationAPI OpenMeteoDWDEnsemble-API
2024-04-04 21:41:49 inverterStrings Garten
2024-04-04 22:09:12 moduleAzimuth Garten=25
2024-04-04 22:09:34 moduleDeclination Garten=15
2024-04-04 21:52:39 modulePeakString Garten=0.85
2024-04-09 19:34:53 nextCycletime 19:36:03
2024-04-09 19:30:14 nextRadiationAPICall nach 09.04.2024 19:45:14
2024-04-09 08:00:04 pvCorrectionFactor_08 0.88 (automatic - old factor: 1, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
2024-04-09 08:00:04 pvCorrectionFactor_08_autocalc done
2024-04-09 09:00:04 pvCorrectionFactor_09 0.63 (automatic - old factor: 1.25, Sun Alt range: 15, Cloud range: 100, Days in range: 2)
2024-04-09 09:00:04 pvCorrectionFactor_09_autocalc done
2024-04-09 10:00:04 pvCorrectionFactor_10 0.75 (automatic - old factor: 0.71, Sun Alt range: 25, Cloud range: 100, Days in range: 4)
2024-04-09 10:00:04 pvCorrectionFactor_10_autocalc done
2024-04-09 11:00:04 pvCorrectionFactor_11 0.54 (automatic - old factor: 0.79, Sun Alt range: 35, Cloud range: 100, Days in range: 2)
2024-04-09 11:00:04 pvCorrectionFactor_11_autocalc done
2024-04-09 12:00:04 pvCorrectionFactor_12 0.72 (automatic - old factor: 1, Sun Alt range: 45, Cloud range: 100, Days in range: 1)
2024-04-09 12:00:04 pvCorrectionFactor_12_autocalc done
2024-04-09 13:00:04 pvCorrectionFactor_13 1.12 (automatic - old factor: 1, Sun Alt range: 50, Cloud range: 100, Days in range: 1)
2024-04-09 13:00:04 pvCorrectionFactor_13_autocalc done
2024-04-09 14:00:04 pvCorrectionFactor_14 0.95 (automatic - old factor: 0.96, Sun Alt range: 50, Cloud range: 100, Days in range: 4)
2024-04-09 14:00:04 pvCorrectionFactor_14_autocalc done
2024-04-09 15:00:04 pvCorrectionFactor_15 1.07 (automatic - old factor: 1.12, Sun Alt range: 45, Cloud range: 100, Days in range: 4)
2024-04-09 15:00:04 pvCorrectionFactor_15_autocalc done
2024-04-09 16:00:04 pvCorrectionFactor_16 0.90 (automatic - old factor: 0.92, Sun Alt range: 40, Cloud range: 100, Days in range: 5)
2024-04-09 16:00:04 pvCorrectionFactor_16_autocalc done
2024-04-09 17:00:04 pvCorrectionFactor_17 0.87 (automatic - old factor: 0.93, Sun Alt range: 35, Cloud range: 100, Days in range: 3)
2024-04-09 17:00:04 pvCorrectionFactor_17_autocalc done
2024-04-09 18:00:04 pvCorrectionFactor_18 1.00 (automatic - old factor: 1.80, Sun Alt range: 25, Cloud range: 100, Days in range: 2)
2024-04-09 18:00:04 pvCorrectionFactor_18_autocalc done
2024-04-09 19:00:04 pvCorrectionFactor_19 0.71 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 100, Days in range: 3)
2024-04-09 19:00:04 pvCorrectionFactor_19_autocalc done
2024-04-09 19:34:53 pvCorrectionFactor_Auto on_complex_ai
2024-04-09 19:34:54 state updated
2024-04-09 19:34:53 statistic_todayGridConsumption 12645.0 Wh
2024-04-09 19:34:53 statistic_todayGridFeedIn 0.0 Wh
Attributes:
DbLogExclude .*
ctrlStatisticReadings todayGridConsumption,todayGridFeedIn
ctrlWeatherDev1 OpenMeteoDWDEnsemble-API
event-on-change-reading .*
flowGraphicAnimate 1
room 25_Energie,90_Devices
Habe ich da einen Fehler? Braucht es noch mehr für die Analyse?
Viele Grüße
Holger
ZitatHabe ich da einen Fehler? Braucht es noch mehr für die Analyse?
Vllt. hast du mal ein bisschen was probiert und getestet.
Führe einfach ein
get ... valConsumerMaster
aus. Der Aufruf löscht implizit evtl. fehlerhafte Einträge.
Im Log erscheint dann mit verbose 2
INFO - invalid consumer key "..." was deleted from consumer storage
LG
Zitat von: DS_Starter am 09 April 2024, 20:26:51ZitatHabe ich da einen Fehler? Braucht es noch mehr für die Analyse?
Vllt. hast du mal ein bisschen was probiert und getestet.
Führe einfach ein
get ... valConsumerMaster
aus. Der Aufruf löscht implizit evtl. fehlerhafte Einträge.
Im Log erscheint dann mit verbose 2
INFO - invalid consumer key "..." was deleted from consumer storage
LG
Habe dann das hier im log gesehen:
2024.04.09 21:48:30.479 2: Forecast - INFO - invalid consumer key "check" was deleted from consumer storage
Wie der key "check" da rein gekommen ist, weiß ich wirklich nicht. Ich habe explizit nur den Wizard am Anfang durchgemacht und nur die Daten für den String und den Inverter eingegeben. Das mit den Consumern möchte ich eigentlich auch nutzen, habe das aber bewusst noch nicht in Angriff genommen.
Aber: Die Meldungen im Log sind weg. Vielen Dank für das tolle Modul und die Hilfe.
Liebe Grüße
Holger
ZitatWie der key "check" da rein gekommen ist, weiß ich wirklich nicht. Ich habe explizit nur den Wizard am Anfang durchgemacht und nur die Daten für den String und den Inverter eingegeben.
Ja schwer zu sagen.
Ich habe schon oft eine Neudefinition durchgeführt, konnte soetwas bisher nicht beobachten.
Aber vllt. hast du eine Variante getätigt die ich noch nicht beachtet habe. Falls du deine Definition nochmal mit einem weiteren Device nachstellen kannst, gäbe es möglicherwiese einen Ansatz um es zukünftig zu verhindern.
An dieser Stelle mein Dank an alle, die Daten zur Verfügung gestellt haben ! Jetzt muss ich die "nur noch" irgendwie systematisieren.
LG
pah
Hallo zusammen,
ich benötige mal bitte Eure Expertenhilfe. Bei der FHEM Installation eines Freundes habe ich das Modul 76_SolarForecast erfolgreich installiert und die PV Anlage, samt Akku und elektrischen Überschussheizstäben hinterlegt. Ich möchte die elektrischen Heizstäbe wirklich nur einschalten, wenn der Akku auf 100% SOC ist und der PV Ertrag ausreicht, um einen Heizstab zu speisen. Leider bin ich jetzt an einer Stelle angekommen, dass die Consumer (Heizstäbe) sich nach einem vollen SOC von 100% und ausreichendem PV Überschuss zwar einschalten aber neben dem PV Ertrag sich auch aus der Batterie versorgen und diese entladen. Ich unterbreche jetzt zwar den Vorgang, aber ich komme so in einen instabilen Zustand. Wie kann ich das Modul bzw. die drei Consumer so gestalten, dass nur eine Versorgung der Heizstäbe bei den vorab genannten Bedingungen erfolgt und die volle Akkuladung, dann abends für die anderen Verbraucher im Haus zur Verfügung steht?,
Vielen Dank vorab für Eure Hilfe!
Viele Grüße aus Leipzig!
Peter
Attribute für consumerXX:
consumer01
ShellyPlus1PM_1 type=heater power=2243 mode=can icon=sani_buffer_electric_heater_side on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:.100
consumer02
ShellyPlus1PM_2 type=heater power=2192 mode=can icon=sani_buffer_electric_heater_side on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:.100
consumer03
ShellyPlus1PM_3 type=heater power=2170 mode=can icon=sani_buffer_electric_heater_side on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:.100
Hallo Peter,
du bist schon sehr nah dran.
Nimm die swoncond für den Start des Einschaltens so wie du es bereits gemacht hast, aber verwende den interruptable Key statt "1" mit einer Regex-Bedingung.
Du könntest z.B.
interruptable=BYD_Akku:SOC:[0-8][0-9]|9[0-7]:3
verwenden. Den Key swoffcond löscht du in dem Fall.
Wenn ich keinen Denkfehler habe, startet die Laufzeit des Verbrauchers sobald der Akku voll ist und der PV Überschuß ausreicht. Ist später ungenügender Überschuß vorhanden oder der Akku wurde auf <=97% entladen, wird der Verbraucher temporär unterbrochen. Er schaltet wieder ein wenn genügend PV vorhanden und der Akku auf 100% (wieder) geladen wurde. Das relisiert die Hysterese.
Dann setzt du aber noch
mintime=SunPath
D.h. die Einplanung der generellen Laufzeit des Consumers erfolgt entsprechend des Sonnengangs.
So sollte es klappen. Die Realität muss es natürlich noch beweisen. ;)
Es gibt noch komplexere Methoden. Die realisiert man aber mit etwas eigenen Code im Attribut ctrlUserExitFn. Dort sind der Phantasie keine Grenzen gesetzt.
LG,
Heiko
Morgen gibt es wieder ein Update.
Enthalten ist:
- das CSV Export Feature der pvHistory
- das Attr affectMaxDayVariance ist obsolete
Falls ihr das Attr gesetzt haben solltet, bekommt ihr beim Start eine entsprechende Meldung und solltet
nach vollendetem Start die FHEM Konfig speichern.
LG,
Heiko
Hello, ich habe gerade eine Mail bekommen, dass der kostenlose Dienst von Solcast eingestellt wird. Ab 16.4. Betrifft euch das auch, oder läuft da mein Konto aus? Ich habe gerade keine richtige Alternative, da es eigentlich so recht gut läuft :-)
VG
Alex
Moin Alex,
ich habe bisher noch keine Info von SolCast bekommen.
Auf der Webseite wird der kostenlose Dienst auch noch angeboten: https://solcast.com/free-rooftop-solar-forecasting
Sollte es dennoch dazu kommen, haben wir doch mit den Open-Meteo Dienst eine recht adäquate Alternative oder spricht bei dir etwas dagegen?
Die Umstellung wäre auch sehr einfach per Attribut ctrlWeatherDev1 bzw. Setter currentRadiationAPI möglich.
Grüße,
Heiko
Hallo Heiko,
danke für die Antwort. Nein spricht eigentlich nichts dagegen. Ich würde ungern ein funktionierendes System ändern wollen. Aber im Zweifel mach ichs halt :-)
Hier mal die Mail, die ich bekommen habe:
ZitatHi Alexander
We are reaching out to let you know that we will be removing the free trial plans from your account.
This decision was not made lightly, and we understand that it may impact some of our users. However, we believe this change is necessary to continue providing a sustainable and high-quality service to all our users.
Effective 16th of April 2024, we will be phasing out TMY, Monthly Averages, and Time Series free plans. If you are using the data for commercial purposes, please feel free to reach out to sales@solcast.com or request a quote here.
If you still require the use of Solcast data, please contact support@solcast.com or reply to this email, and we will be more than happy to apply the current available plan for your usage (academic or home hobbyist).
Kind regards,
Solcast Team
Grüße
Alex
Hi Alex,
ich vermute du hattest dich mit deinem Account nicht als Home-User (Hobbyist) registriert.
Im letzten Satz der Mail steckt wohl des Pudels Kern:
ZitatWenn Sie weiterhin Solcast-Daten benötigen, wenden Sie sich bitte an support@solcast.com oder antworten Sie auf diese E-Mail, und wir werden gerne den aktuell verfügbaren Plan für Ihre Nutzung (akademisch oder als Hobbyist) anwenden.
Ich würde SolCast im ersten Schritt anschreiben und bitten dich als Hobbyist weiterzuführen.
Für unsere Anwendung brauchen wir auch nur die PV Forecast und keine historical oder andere Daten.
Als Hobbyist kannst du nur 2 Strings(Rooftops) registrieren. Wenn du mehr hast, benutzt du halt einen weiteren Account. Das Modul kann damit umgehen und diese Daten verwalten. Kommt darauf an wie es bei dir aussieht.
Hier ist auch die Seite zur Registrierung als Home-User:
https://toolkit.solcast.com.au/register/hobbyist?_gl=1%2a29oskg%2a_ga%2aMTc5MDQ0MTU4Ni4xNzAzMTQ3Njcy%2a_ga_BYH3TC3R79%2aMTcxMjgyMDg3NC4zLjEuMTcxMjgyMjQ4OS4wLjAuMA..&_ga=2.58996073.57110503.1712820875-1790441586.1703147672
LG
Hallo Mike,
so hab ichs jetzt mal gemacht. Danke für den Hinweis.
Mal ne andere Frage - rein aus Interesse.
Ich habe mir die Seite mal angeschaut: https://open-meteo.com/en/docs (https://open-meteo.com/en/docs)
Von den Werten ja gleich zu erfassen. Welche Felder bei "Solar Radiation Variables" müsste ich hier ankreuzen?
VG
Alex
ZitatWelche Felder bei "Solar Radiation Variables" müsste ich hier ankreuzen?
Das wäre nur die "Global Tilted Radiation GTI". Die wird als Grundlage genommen bzw. damit agiert.
Zitat von: DS_Starter am 11 April 2024, 10:07:52Ich würde SolCast im ersten Schritt anschreiben und bitten dich als Hobbyist weiterzuführen.
Für unsere Anwendung brauchen wir auch nur die PV Forecast und keine historical oder andere Daten.
Als Hobbyist kannst du nur 2 Strings(Rooftops) registrieren. Wenn du mehr hast, benutzt du halt einen weiteren Account. Das Modul kann damit umgehen und
Ich seh gerade den Hinweis auf meinem Dashboard:
ZitatYour hobbyist account is limited to the creation of 2 Home PV arrays within 1km of each other.
If you have multiple arrays, learn how to configure a split array.
Vermutlich bin ich schon hobbyist. Also es bleibt spannend. Mal abwarten, was solcast antwortet.
Grüße
Alex
Zitat von: DS_Starter am 11 April 2024, 10:17:04as wäre nur die "Global Tilted Radiation GTI". Die wird als Grundlage genommen bzw. damit agiert.
Die gibts 2 mal?!
Ich nehme die linke ;)
Hallo,
ich habe gerade ein fehlverhalten beobachtet.
Meine Frau hat eben um ca 20:00 unsere Waschmaschine gepackt und wie immer per Alexa "geplant".
Trotz:
Waschmaschine icon=scene_washing_machine@orange mintime=150 [b]notbefore=09 notafter=17[/b] type=washingmachine mode=must power=2300 swstate=state:on:off on=on off=off auto=automatic etotal=energy:kWh:5 pcurr=power:W:5
wurde die Maschine sofort eingeschaltet. Obwohl fast keine Solar Leistung mehr anliegt wurde Ein und Aus noch für heute Abend geplant.
Eigentlich sollte doch notbefore=09 notafter=17 das verhindern!
-Oder ?
ZitatMeine Frau hat eben um ca 20:00 unsere Waschmaschine gepackt und wie immer per Alexa "geplant".
Welcher Befehl bezüglich des SF-Moduls wird denn bei der Planung per Alexa ausgeführt?
ZitatWelcher Befehl bezüglich des SF-Moduls wird denn bei der Planung per Alexa ausgeführt?
-Der Ablauf ist folgender:
-Wir packen die Maschine die dauerhaft per Zigbee Steckdose ausgeschaltet ist.
-Dann schalten wir per Alexa diese Steckdose ein und starten die Maschine.
-Ein DOIF schaltet ab einer gewissen Leistung, die an der Steckdose gemessen wird wenn die Maschine
erstmals Wasser zieht wieder aus und setzt ein Reading "automatic" im Steckdosen Device auf "1"
-Dieses Reading ist die im SF Modul im consumer hinterlegt und schaltet die Automatik ein.
Das funktioniert schon lange super.
Wenn ich so darüber nachdenke, stellt sich mir die Frage wann das SF Modul die Planung der Ein Aus Zeiten triggert. Und warum können Zeiten geplant werden die außerhalb der notbefore=09 notafter=17 liegen ?
Zitat von: Prof. Dr. Peter Henning am 08 April 2024, 10:50:56ch bin sehr daran interessiert, von anderen Nutzern folgende Daten zu bekommen:
Für den Zeitraum 27.März - 3.April, sowie vom 4.April - 11.April
- Vom DWD vorhergesagte solare Einstrahlung
- Vom Modul SolarForecast vorhergesagtes solares Ergebnis
- Tatsächlich gemessenes solares Ergebnis
- Ungefährer Standort der Anlage
Hallo
anbei die gewünschten Daten - leider ein bisschen spät
Gruß Max
Hallo Heiko,
mein Consumer01 ist ein Entfeuchter im Keller. Dieser sollte bei Überschuss anspringen und dann für mindesten 15 Minuten laufen. Das ein und ausschalten funktioniert so weit ganz gut mit folgendem Consumer01 Attribut.
ZitatSTD_AKT_1_Pwr type=heater power=250 switchdev=STD_AKT_1_Sw mode=can icon=Ventilator_wind on=on off=off pcurr=power:W:250 etotal=energy:Wh interruptable=0 asynchron=0 swstate=state:on:off locktime=900:900
allerdings feuert mir SolarForecast nun alle 4 sec ein on und später alle 4 sec ein off an meinen STD_AKT_1_Sw.
wie kann ich das abschalten weil meine FHEM Installation damit ganz schon ins schwitzen kommt.
Gruß
Bison
@Skusi,
ZitatWenn ich so darüber nachdenke, stellt sich mir die Frage wann das SF Modul die Planung der Ein Aus Zeiten triggert. Und warum können Zeiten geplant werden die außerhalb der notbefore=09 notafter=17 liegen ?
Das Modul führt ein Replanning für Verbraucher aus, die in der ursprünglich geplanten Zeit nicht gestartet wurden bzw. nicht gestartet werden konnnten. Der Key notafter=17 besagt, dass die geplante Startzeit nicht nach 17:00 sein soll. Aber es ist durchaus legitim den Verbraucher z.B. mit Startzeit 16:50 zu planen. Die Endezeit liegt dann entsprechend mintime nach 17:00, d.h. der Verbraucher kann durchaus nach 17:00 starten sobald die Automatic aktiviert wurde und die Zeit innerhalb der Planungzeit liegt.
Und weil der Verbaucher mit mode=must definiert ist, erfolgt die Einschaltung auch bei ungenügenden Überschuß.
Du kannst dir das genauer anschauen mit ctrl Debug=consumerPlanning,consumerSwitching.
Grüße,
Heiko
@Bison,
Zitatallerdings feuert mir SolarForecast nun alle 4 sec ein on und später alle 4 sec ein off an meinen STD_AKT_1_Sw.
In diesem Fall bekommt SF den Schaltstatus nicht korrekt mitgeteilt und versucht immer wieder den on bzw. off-Status zu erreichen.
Du müsstest den Schlüssel swstate mit den richtigen Regex angeben.
LG,
Heiko
Hallo Heiko,
die Homematic Schalter
channel_01 STD_AKT_1_Sw
channel_02 STD_AKT_1_Pwr
channel_03 STD_AKT_1_SenPwr
channel_04 STD_AKT_1_SenI
channel_05 STD_AKT_1_SenU
channel_06 STD_AKT_1_SenF
haben die Informationen in diversen Channel versteckt.
könnte ich
swstate=STD_AKT_1_Sw:state:on:off
eingeben?
Gruß
Bison
Zitat von: Prof. Dr. Peter Henning am 10 April 2024, 09:06:33An dieser Stelle mein Dank an alle, die Daten zur Verfügung gestellt haben ! Jetzt muss ich die "nur noch" irgendwie systematisieren.
Größere Abweichungen zwischen Prognose und Realität habe ich auch diese Woche (siehe Anhang(. Derart weit auseinander waren Prognose und Realität in den vorhergehenden Wochen selten. Die KI sagt bei mir allerdings neuerdings im Modul meist "KI arbeitet einwandfrei, aber für die aktuelle Stunde ist kein Wert verfügbar".
Im pvCorrectionFactor_* gab es heute in allen Stunden zwischen Sonnenauf- und -untergang 3 bis 8 "days in range", womit ich erwartet hätte, dass es zumindest etwas "Futter" für die Prognose gegegeben hätte.
Gruß
Christian
@Bison,
ja die geteilten Homematic habe ich auch eingebunden.
Einfach:
swstate=state:on:off
angeben. Hier ist ein komplettes Beipiel von meinem Homematicschalter:
eg.flur.server_Pwr switchdev=eg.flur.server_Sw type=noSchedule power=70 icon=it_nas swstate=state:on:off pcurr=power:W etotal=energyCalc:Wh
@Christian,
ZitatDie KI sagt bei mir allerdings neuerdings im Modul meist "KI arbeitet einwandfrei, aber für die aktuelle Stunde ist kein Wert verfügbar".
Ja, ist kein Grund zur Sorge. Allerdings sagt die KI "... liefert keinen Werte für die aktuelle Stunde".
Eine KI hat etliche Parameter die zu einer Entscheidung beitragen. Wenn es keine Entscheidung seitens der KI gibt, liefert sie keine und das Modul verwendet die Vorhersage des gewählten Dienstes mit Anpassungen durch die Modullogik.
Die pvCorrectionFactor_* gehören zur Modullogik. Die KI hat ihren eigenen Entscheidungpfad. Das kannst du die (näherungsweise) mit "get ... valDecTree aiRuleStrings" anschauen um eine ungefähre Vorstellung zu erhalten.
Auch wenn die Trefferquote der Vorhersagen schon ziemlich gut ist, unterliegen die Vorhersagen immer Störfaktoren. Eine Wolke über längere Zeit am falschen Fleck kann schon den Stundenwert stark beeinflussen.
Und wir müssen uns auch immer vor Augen halten, dass die Inputparameter über die gewählten Wetterdienste auch fehlerbehaftet sind und nicht immer und unbedingt die tatsächlichen Verhältnisse vorhersagen.
Zitat von: DS_Starter am 09 April 2024, 11:22:05@cbl, mach mal bitte ein Screenhot der gesamten Grafik (mit Balken).
Bei mir sehe ich momentan kein Prob mit zu vielen Consumern und vermute eine Abhängigkeit in der Gesamtzusammenstellung.
Den Beitrag hatte ich übersehen.
Voilà:
Screenshot_20240414_075758_Chrome.jpg
Gruß
Christian
Moin Christian,
du kannst das Attr flowGraphicSize benutzen um das Größenverhältnis zu der übrigen Grafik anzupassen.
LG
Hallo Heiko,
ich habe den ganzen Tag mit Sonne genutzt um meinen Entfeuchter über SoalrForecast zum laufen zu bringen. Deinem Hinweis zur Folge habe ich swstate mir mal angeschaut. Hier habe ich folgendes Problem.
Im Homematic device Steckdose wird im Reading STD_AKT_1_Sw im state set STD_AKT_1_Sw off noArg übergeben.
Die Abfrage von SolarForecast auf on/off match daher nicht und SolarForecast schickt erneut einen SetBefehl.
Der state ändert sich nicht und die Loop (Freund des Programmierers) ist da.
Ich habe versucht mir .*on.* oder .*off.* den Loop zu unterbrechen. Das funktioniert leider nicht.
Ich denke wenn das Attribut swstate auf das Haupt device STD_AKT_1 gehen würde wäre das schön.
Gruß
Bison
ZitatIm Homematic device Steckdose wird im Reading STD_AKT_1_Sw im state set STD_AKT_1_Sw off noArg übergeben.
Das verstehe ich nicht... Welches Reading ... state?
Du kannst dir im Device STD_AKT_1_Sw auch ein userReading anlegen welches den Schaltzustand abbildet und dieses Reading im SF angeben, also z.B.:
swstate=<dein_userreading>:.*on.*:.*off.*
Ergänzung: Wenn du ctrlDebug=consumerSwitching setzt und das Ergebnis postest sieht man u.U. mehr bzgl. des Problems.
Zitat von: DS_Starter am 14 April 2024, 10:06:11Moin Christian,
du kannst das Attr flowGraphicSize benutzen um das Größenverhältnis zu der übrigen Grafik anzupassen.
LG
Hallo,
vielen Dank für den Hinweis. In diesem Modul ist wirklich an alles gedacht! Natürlich löst das das Problem. ;)
Ich wäre nur bei "Größe der Grafik" nicht an eine Abhängigkeit zu Verbrauchern darunter gekommen. Mit weniger Pixeln kann ich nun mehr sehen. 350 statt 400 Pixeln im Default haben das Problem bereits gelöst.
Vielen Gruß
Christian
Hallo,
Ich habe aus einen mir nicht bekannten Grund die Konfigurationsdaten für das Modul verloren und konnte sie auch über "set PlantConfiguration restore" nicht wieder herstellen. Zum Glück hatte ich sie mir aufgeschrieben und habe beim Neueingeben bemerkt, dass sich Bezeichnungen geändert haben.
Eine Frage an den Entwickler: Kann man die Konfigurationswerte auch in den Attributen ablegen und beim Neustart automatisch einlesen?
Ich finde das Modul wirklich sehr hochwertig und nützlich. Vielen Dank für Dein Engagement.
Gruß
Tupol
Hallo tupol,
ZitatIch habe aus einen mir nicht bekannten Grund die Konfigurationsdaten für das Modul verloren und konnte sie auch über "set PlantConfiguration restore" nicht wieder herstellen. Zum Glück hatte ich sie mir aufgeschrieben und habe beim Neueingeben bemerkt, dass sich Bezeichnungen geändert haben.
Es wäre sinnvoll herauszubekommen wieso die Wiederherstellung der Konfiguration bei dir nicht funktioniert hat. Die Konfigurationsdaten werden täglich automatisch gesichert und ich übe immer mal wieder die Herstellung from Scratch.
Die Konfiguration ist sowohl in verschiedenen Attributen als auch Readings hinterlegt. Hinter den Readings liegt die Überlegung bestimmte Konfigurationen dynamisch umschalten zu können.
Es hat sich mittlerweile für manche dieser Einstellungen herausgestellt, dass es sinnvoll ist es so beizubehalten (Korrekturverfahren, Batterietrigger, u.a.), für andere Einstellungen eher nicht.
Elemente für die eine dynamische Änderungsmöglichkeit nicht so sinnvoll ist, habe ich vor behutsam nach Prüfung in Attribute umzuwandeln. Das passiert nach und nach.
Die Speicherung/Wiederherstellung der Plantkonfig behandelt sowohl Attribute als auch Readings (man kann sich auch mal die Attribute verstellen).
Bei der Wiederherstellung wird die Anzahl der Elemente ausgeschrieben (gerade nochmal exerziert) und muß ungeachtet des oben beschriebenen Sachverhalts funktionieren:
2024.04.14 19:38:58.006 3: SolCast5 - cached data "Plant Configuration" restored. Number of restored Readings/Attributes: 9/26
Das ist wegen der Komplexität eine ganz wesentliche Funktionalität des Moduls die ich als sehr wichtig erachte.
Edit: Zu Backup und Restore gibt es auch einen Wiki-Artikel (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Backup_und_Wiederherstellung_der_Moduldaten) zum Modul.
Grüße,
Heiko
Hallo Heiko,
danke für die schnelle Reaktion. Warum es nicht funktioniert hat, weiß ich leider nicht. Es hieß nur "0/4 Attributen wiederhergestellt". Außerdem heißen die Readings für die Panelausrichtung jetzt anders. Es wäre schon, wenn das mit der Konfiguration über Attribute klappen würde. :)
Noch eine Frage: Ich habe meine Wallbox als Consumer angezeigt. Allerdings wird der etotal beim Laden nie angezeigt sondern ist immer 0. Mach ich was falsch?
attr SolarVorhersage consumer01 WebastoNext type=charger power=0 pcurr=Charge_Active_Power:W etotal=Energy_Meter:kWh icon=wallbox
Gruß
tupol
ZitatAußerdem heißen die Readings für die Panelausrichtung jetzt anders.
Schon etwas länger. ;)
ZitatNoch eine Frage: Ich habe meine Wallbox als Consumer angezeigt. Allerdings wird der etotal beim Laden nie angezeigt sondern ist immer 0. Mach ich was falsch?
Wahrscheinlich ist die Definition von "etotal=Energy_Meter:kWh" nicht richtig.
"Energy_Meter" wäre laut deiner Angabe der Name des Readings im Device "WebastoNext" welches die Energie in kWh enthält. Mir kommt der Name Energy_Meter für einen Readingnamen etwas eigenartig vor.
Hier mal ein paar Ideen - die sind ja hier gefragt...
1. Bei den Energiezählern soll immer ein Reading angegeben werden, das monoton wächst. Ich habe aber in verschiedenen Zählern Readings, die um Mitternacht auf Null gesetzt werden - also Tagesreadings sind. Das könnte man für das Vorhersagemodul noch als Angabe ermöglichen.
2. Waschmaschinen sind durchaus Großverbraucher, und die meisten laufen inzwischen ziemlich lange. Ein weiterer wichtiger Faktor ist die Wäschetrockung (nicht im Trockner, sondern auf der Leine). Es nutzt zwar möglicherweise der Stromrechnung, wenn die Waschmaschine nachmittags um 17:00 fertig ist - aber trocken wird das dann nicht mehr. Ich habe keine Möglichkeit gefunden, eine "Fertig-Zeitangabe" für einen Consumer festzulegen.
Allgemeiner gesprochen: Es wäre schön, wenn man ein allgemeines Format hätte, mit dem man z.B. festlegen kann:
"Am kommenden Montag wird für 4 Stunden bis höchstens 12:00 Uhr für Verbraucher xyz eine Energie vom 4 kWh benötigt".
3. Ich habe keine Möglichkeit gefunden, PV-Anlagen mit Direkteinspeisung zusätzlich in die Visualisierung aufzunehmen.
LG
pah
Hallo Heiko,
nach Umstellung auf OpenMeteoDWDEnsemble-API habe ich eigentlich häufig sehr gute Übereinstimmung zwischen Vorhersage und tatsächlichem Ertrag. Die Balken passten gut und die Summe des Tageseintrags lag (Ausnahmetage bestätigen die Regel ;-)) meist in der Nähe der letzten Vorhersage, wenn ich abends nachschaute. Dann fiel mir auf, dass diese Abweichung am nächsten morgen als "gestriger Wert" nicht mit meiner Einschätzung übereinstimmte.
TAG PVFC PVreal genannte Abweichung "richtige Abweichung"
So 21,683 21,3 -25% [-24.99] -1,77%
Welche Vorhersage wird denn zur Grundlage der Abweichungsangabe gemacht die vom letzte vor dem Sonnenaufgang oder die letzte vor dem Sonnenuntergang, wenn Today_PVdeviation geschrieben wird? Bei diesem Aprilwetter der letzten Wochen gab es ja untertage einige deutliche Korrekturen der Vorhersage...
FVERSION
76_SolarForecast.pm:v1.17.7-s28780/2024-04-10
Herzliche Grüße
Christian
@pah,
deine Ideen habe ich vermerkt.
Geht aber erst im Mai mit gößeren Implementierungen weiter ... kleine Pause. ;)
@Christian,
ZitatWelche Vorhersage wird denn zur Grundlage der Abweichungsangabe gemacht die vom letzte vor dem Sonnenaufgang oder die letzte vor dem Sonnenuntergang, wenn Today_PVdeviation geschrieben wird?
Die Abweichung für den aktuellen Tag wird aus den Werten des aktuellen Tages, also ab der ersten PV-Generierung (kann auch vor Sonnenaufgang im Zwielicht sein).
Der gestrige Wert ist eine Kopie des Vortageswertes, angelegt wenige Sekunden nach Mitternacht als Kopie von Today_PVdeviation welches danach gelöscht wird.
Was ist die von dir geschriebene "genannte Abweichung"? Welche Einstellung hat das Attr ctrlGenPVdeviation falls gesetzt?
LG,
Heiko
Sorry, Heiko, dass ich mich unpräzise ausgedrückt habe:
ctrlGenPVdeviation ist bei mir nicht explizit gesetzt, so dass die Abweichung nicht fortlaufend, sondern einmal nach Sonnenuntergang kalkuliert wird (entsprechend sind auch die timestamps der geloggten Daten).
Meist gucke ich mir in den Abendstunden die Werte an und freue mich dann an der Treffsicherheit (meist). Verwirrt war ich jüngst eben in dem skizzierten Fall, wo ich die Werte erinnerte, die ich Abend zuvor gesehen hatte. Gestern habe ich sie mir auch aufgeschrieben: Also den letzten Forecast und die inzwischen endgültige Ernte. Und heute Morgen steht im Modul als "gestrige Abweichung" eben -25%, was zu den notierten Werten von gestern Abend mir nicht zu passen scheint.
Herzliche Grüße
Christian
Hmmm... werde ich heute mal zu morgen beobachten bei einer Instanz.
Der Wert von heute wird wie geschrieben ein paar Sekunden nach Dienstag 00:00 als "Werte gestern" kopiert.
Melde mich morgen dazu wieder.
LG
Zitat2. Waschmaschinen sind durchaus Großverbraucher, und die meisten laufen inzwischen ziemlich lange. Ein weiterer wichtiger Faktor ist die Wäschetrockung (nicht im Trockner, sondern auf der Leine). Es nutzt zwar möglicherweise der Stromrechnung, wenn die Waschmaschine nachmittags um 17:00 fertig ist - aber trocken wird das dann nicht mehr. Ich habe keine Möglichkeit gefunden, eine "Fertig-Zeitangabe" für einen Consumer festzulegen.
Allgemeiner gesprochen: Es wäre schön, wenn man ein allgemeines Format hätte, mit dem man z.B. festlegen kann:
"Am kommenden Montag wird für 4 Stunden bis höchstens 12:00 Uhr für Verbraucher xyz eine Energie vom 4 kWh benötigt".
Die Idee ist nett, aber nach meinem Kenntnisstand wird das schwer umzusetzen. Lasse mich aber gerne eines besseren belehren.
Der Wochentag ist aber sicherlich interressant. Wenn man einen Rythmus für das Waschen hat.
z.B. Arbeitswäsche Samstag Vormittag. Wäre bei mir so ein Fall. Und mit einem Rythmus könnte man die Ki auch anhängen um das timing zu optimieren.
Aber Vermutlich haben die wenigsten einen Rythmus für das Waschen bzw. Trocknen bzw. Geschirrspülen.
Moderne Maschinen variiern in der Zeit. Da mitunter das Gewicht bestimmt wird. Zudem kann es sein das die Waschnmaschine mit Warmwasser gefüttert wird und sich dadurch die Heizzeit verkürzt.
Man müßte entweder sagen das die Maschine bis xUhr angestellt werden muß. Oder man müsste je nach Maschine jedesmal die Zeit anpassen. Eine 90° Kochwäsche braucht länger wie eine Maschine Buntes im Schnell-Programm. Dann müßte man verschiedene "Szenen" haben für den Komfort. Und diese dann selbst bestimmen.
Ich habe keine smarte Waschmaschine. Keine Ahnung was da für Optionen vorhanden sind um das besser automatisieren zu können. Mit einer konventionellen Maschine wird es vermutlich nur eine Halbautomatiklösung umsetzbar sein.
Oder man nimmt immer k.a. 4h vorher an.. Das würde bei 12Uhr fertig 8Uhr morgens Zwangsstart bedeuten.
Und das wäre ja jetzt schon Lösbar.
Hallo zusammen,
mit den Smarten Waschmaschinen geht schon ein bisschen was, nur mal so als Beispiel unsere Siemens eingebunden in fhem:
define WM14VL40 HomeConnect hcconn SIEMENS-WM14VL40-68A40E30D3CE
attr WM14VL40 alias Waschmaschine
attr WM14VL40 icon scene_washing_machine
attr WM14VL40 room HomeConnect
attr WM14VL40 webCmd BSH.Common.Root.SelectedProgram:startProgram:stopProgram
# DEF hcconn SIEMENS-WM14VL40-68A40E30D3CE
# FUUID 60e4c67d-f33f-4971-62ff-11282567aedff54d
# NAME WM14VL40
# NR 730
# STATE Idle
# TYPE HomeConnect
# aliasname Waschmaschine
# brand Siemens
# commandPrefix
# eventChannelTimeout 1713215918.51913
# eventCount 1
# haId SIEMENS-WM14VL40-68A40E30D3CE
# hcconn hcconn
# programs
# retrycounter 0
# type Washer
# vib WM14VL40
# READINGS:
# 2024-04-15 12:52:10 BSH.Common.Event.ProgramFinished BSH.Common.EnumType.EventPresentState.Off
# 2024-04-13 10:41:09 BSH.Common.Option.EnergyForecast 80 %
# 2024-04-13 13:35:18 BSH.Common.Option.EstimatedTotalProgramTime 2460 seconds
# 2024-04-13 13:35:18 BSH.Common.Option.FinishInRelative 2460 seconds
# 2024-04-15 12:50:23 BSH.Common.Option.ProgramProgress 100 %
# 2024-04-15 12:50:23 BSH.Common.Option.RemainingProgramTime 0 seconds
# 2024-04-15 12:18:51 BSH.Common.Option.RemainingProgramTimeIsEstimated 1
# 2024-04-13 10:41:09 BSH.Common.Option.WaterForecast 0 %
# 2024-04-15 12:52:10 BSH.Common.Root.ActiveProgram -
# 2024-04-13 13:35:07 BSH.Common.Root.SelectedProgram LaundryCare.Washer.Program.Wool
# 2024-04-15 12:52:10 BSH.Common.Status.DoorState BSH.Common.EnumType.DoorState.Open
# 2024-04-15 12:18:56 BSH.Common.Status.LocalControlActive 0
# 2024-04-15 12:52:10 BSH.Common.Status.OperationState BSH.Common.EnumType.OperationState.Ready
# 2024-04-15 12:18:56 BSH.Common.Status.RemoteControlActive 1
# 2024-04-15 12:18:46 BSH.Common.Status.RemoteControlStartAllowed 0
# 2024-04-13 10:41:09 LaundryCare.Common.Option.LoadRecommendation 0 gram
# 2024-03-17 13:43:23 LaundryCare.Common.Option.ProcessPhase LaundryCare.Common.EnumType.ProcessPhase.DetectingLoad
# 2024-04-13 10:41:09 LaundryCare.Washer.Option.LessIroning 0
# 2024-04-13 10:41:09 LaundryCare.Washer.Option.Prewash 0
# 2024-04-13 10:41:09 LaundryCare.Washer.Option.RinseHold 0
# 2024-04-13 10:41:09 LaundryCare.Washer.Option.RinsePlus1 0
# 2024-04-04 09:31:57 LaundryCare.Washer.Option.SpeedPerfect 0
# 2024-04-15 12:50:28 LaundryCare.Washer.Option.SpinSpeed LaundryCare.Washer.EnumType.SpinSpeed.RPM1200
# 2024-04-15 12:50:28 LaundryCare.Washer.Option.Temperature LaundryCare.Washer.EnumType.Temperature.GC30
# 2024-04-15 17:10:27 state Idle
#
setstate WM14VL40 Idle
setstate WM14VL40 2024-04-15 12:52:10 BSH.Common.Event.ProgramFinished BSH.Common.EnumType.EventPresentState.Off
setstate WM14VL40 2024-04-13 10:41:09 BSH.Common.Option.EnergyForecast 80 %
setstate WM14VL40 2024-04-13 13:35:18 BSH.Common.Option.EstimatedTotalProgramTime 2460 seconds
setstate WM14VL40 2024-04-13 13:35:18 BSH.Common.Option.FinishInRelative 2460 seconds
setstate WM14VL40 2024-04-15 12:50:23 BSH.Common.Option.ProgramProgress 100 %
setstate WM14VL40 2024-04-15 12:50:23 BSH.Common.Option.RemainingProgramTime 0 seconds
setstate WM14VL40 2024-04-15 12:18:51 BSH.Common.Option.RemainingProgramTimeIsEstimated 1
setstate WM14VL40 2024-04-13 10:41:09 BSH.Common.Option.WaterForecast 0 %
setstate WM14VL40 2024-04-15 12:52:10 BSH.Common.Root.ActiveProgram -
setstate WM14VL40 2024-04-13 13:35:07 BSH.Common.Root.SelectedProgram LaundryCare.Washer.Program.Wool
setstate WM14VL40 2024-04-15 12:52:10 BSH.Common.Status.DoorState BSH.Common.EnumType.DoorState.Open
setstate WM14VL40 2024-04-15 12:18:56 BSH.Common.Status.LocalControlActive 0
setstate WM14VL40 2024-04-15 12:52:10 BSH.Common.Status.OperationState BSH.Common.EnumType.OperationState.Ready
setstate WM14VL40 2024-04-15 12:18:56 BSH.Common.Status.RemoteControlActive 1
setstate WM14VL40 2024-04-15 12:18:46 BSH.Common.Status.RemoteControlStartAllowed 0
setstate WM14VL40 2024-04-13 10:41:09 LaundryCare.Common.Option.LoadRecommendation 0 gram
setstate WM14VL40 2024-03-17 13:43:23 LaundryCare.Common.Option.ProcessPhase LaundryCare.Common.EnumType.ProcessPhase.DetectingLoad
setstate WM14VL40 2024-04-13 10:41:09 LaundryCare.Washer.Option.LessIroning 0
setstate WM14VL40 2024-04-13 10:41:09 LaundryCare.Washer.Option.Prewash 0
setstate WM14VL40 2024-04-13 10:41:09 LaundryCare.Washer.Option.RinseHold 0
setstate WM14VL40 2024-04-13 10:41:09 LaundryCare.Washer.Option.RinsePlus1 0
setstate WM14VL40 2024-04-04 09:31:57 LaundryCare.Washer.Option.SpeedPerfect 0
setstate WM14VL40 2024-04-15 12:50:28 LaundryCare.Washer.Option.SpinSpeed LaundryCare.Washer.EnumType.SpinSpeed.RPM1200
setstate WM14VL40 2024-04-15 12:50:28 LaundryCare.Washer.Option.Temperature LaundryCare.Washer.EnumType.Temperature.GC30
setstate WM14VL40 2024-04-15 17:10:27 state Idle
Ob es allerdings wirklich so viel Sinn macht das im Modul mit einzuplanen sei mal dahin gestellt, aber wir "leiden" ja auch alle ein wenig an einem gewissen Spieltrieb ;)
Moin, Heiko,
von meinem System kann ich diese Beobachtung zum Thema "Abweichung gestern" beisteuern: Die letzte Prognose war 12,354 kWh, geerntet wurden 13,0. Daraus wurde gestern nach Sonnenuntergang -4,6% Abweichung. Jetzt finde ich folgerichtig denselben werden unter unter "Abweichung heute". Aber die Prozentzahl kann ich für mich nicht nachvollziehen: rechne ich von der Ernte (100/13*12,354-100), komme ich auf -4,9. Gestern war die Vorhersage über den Tag bei uns recht stabil - im Gegensatz zu vorgestern. Aus dieser geringen Abweichung schließe ich, dass nicht die letzte Vorhersage sondern eine frühere genommen wird? Oder hat es damit zu tun, dass ich vorgestern einen Neustart um die Mittagszeit hatte. Tatsächlich habe ich wegen HW-Problemen in jüngerer Zeit häufiger Neustarts, sodass ich jetzt nicht schwören kann, dass Tage mit starken Abweichungen nicht auch Tage mit Neustarts waren.
Noch eine Beobachtung von gestern(ohne jeglichen Neustart gestern). Erstmals wurden drei Today_PVdeviation geloggt:
2024-04-15 20:26:04 -4,63
2024-04-15 22:46:47 -98,14
2024-04-15 23:00:19 -99,06
So etwas fand ich nun im Log noch ein weiteres Mal am 1.4., da waren die Werte aber identisch.
Grüße
Christian
Moin,
eigenartige Beobachtung Christian. Hier sind meine Ergebnisse, ohne irgendeinen Issue:
Prod "heute" (am 15.04.) "gestern" (heute am 16.04.)
-----
Solar Vorhersage -15 % fortlaufend -15 %
DWD Prognose zum Vergleich -15 % fortlaufend -15 %
OpenMeteo DWD ICON -3,8 fortlaufend -3,8 %
OpenMeteo Ensemble 6,1 % täglich 6,1
Victron KI API zum Vergleich 7,5 %, fortlaufend 7,5 %
Test
-----
DWD 15,2 % täglich 15,2
Forecast.Solar API -12,1 % fortlaufend -12,1
OpenMeteo World API -10,6 % fortlaufend -10,6 %
Süddach SolCast API -14,2 % fortlaufend -14,2 %
Alle Wert am 15.04. sind nach Sonnenuntergang aufgenommen.
Melde mich heute Abend nochmal.
LG
Zitat von: cpet am 15 April 2024, 23:28:28den Smarten Waschmaschinen
Das Problem ist, dass es "DIE" smarte Waschmaschine nicht gibt. Da ich die "ergonomische" Version des 48_HomeConnect-Moduls so langsam zur Einsatzreife bringe, kenne ich viele der BSH-Kisten inzwischen ganz gut. BSH hat da einen furchtbaren Zoo gebaut, mal kommen Meldungen über "EnergyForeCast", mal nicht.
Einigermaßen verlässlich sind nur die "erwarteten Programmlaufzeiten" - danach richte ich ja meine Steuerung aus, wenn ich den Sprachbefehl "lass die waschmaschine über nacht laufen" absetze. Dann ist sie Punkt 6:00 fertig.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 16 April 2024, 08:56:04Einigermaßen verlässlich sind nur die "erwarteten Programmlaufzeiten"
Verlässlich sind die aber nur, wenn die Gewohnheiten immer gleich sind (d.h. Beladung immer gleich, Waschmitteldosierung immer gleich oder Schaumerkennung deaktiviert).
Ich kann nicht nachvollziehen, warum das Modul immer wieder behauptet, dass ausreichend Überschuss für die WW-Bereitung vorhanden wäre, obwohl dem nicht so ist.
Grad jetzt z.B.:
Die PV bringt grad ca. 1600 W, wovon ca. 200 W gerade in sonstige Verbraucher fließen, der WW-Verbraucher ist mit 2500 W definiert.
Hier die MasterData vom Verbraucher:
04 => alias => Mythz
asynchron => 1
auto => 0
autoreading => solarforecast_dhw_auto
avgenergy => 2386.36
avgruntime => 35.20
currpowerpercent => 127
cycleStarttime => 1713161325
cycleTime => 0
dspignorecond => Mythz
dswitch => Mythz
dswoffcond =>
dswoncond => Mythz
ehodpieces => 11=2500.00
energythreshold =>
epiecAVG => 1=0.00
epiecAVG_hours => 1
epiecHist => 1
epiecHist_1 => 1=0.00
epiecHist_10 => 1=0.00
epiecHist_10_hours => 0
epiecHist_1_hours => 0
epiecHist_2 => 1=0.00 2=0.00
epiecHist_2_hours => 1
epiecHist_3 => 1=0.00
epiecHist_3_hours => 0
epiecHist_4 => 1=0.00
epiecHist_4_hours => 0
epiecHist_5 => 1=0.00
epiecHist_5_hours => 0
epiecHist_6 => 1=0.00
epiecHist_6_hours => 0
epiecHist_7 => 1=0.00
epiecHist_7_hours => 0
epiecHist_8 => 1=0.00
epiecHist_8_hours => 0
epiecHist_9 => 1=0.00
epiecHist_9_hours => 0
epiecHour => -1
epiecStartEtotal => 4699000
epiecStartTime => 1713161325
epieces => 1=2500.00
hysteresis => 0
icon => sani_water_hot
interruptable => 0
isConsumptionRecommended => 1
isIntimeframe => 1
lastAutoOnTs => 1713161325
lastMinutesOn => 0
lastOnTime => 1713162921
locktime => 0:0
mintime => 60
minutesOn => 0
mode => can
name => Mythz
noshow => 0
notafter => {sprintf('%02d:%02d', (split ':', main::sunset_abs('HORIZON=0',-90*60))[0], (split ':', main::sunset_abs('HORIZON=0',-90*60))[1])}
notbefore => {sprintf('%02d:%02d', (split ':', main::sunrise_abs('HORIZON=0',120*60))[0], (split ':', main::sunrise_abs('HORIZON=0',120*60))[1])}
numberDayStarts => 0
offcom =>
offreg => 0
oncom => pOpMode manual
onoff => off
onreg => 1
physoffon => off
planSupplement =>
plandelete => regular
planstate => planned: 2024-04-16 10:00:00 - 2024-04-16 11:00:00
planswitchoff => 1713258000
planswitchon => 1713254400
power => 2500
powerthreshold => 1
remainTime => 0
retotal => sElectrDHWTotal
rigncond => dhw_temp
rpcurr => cur_power_dhw
rswoffcond =>
rswoncond => dhw_temp
rswstate => HeatingDHW
spignorecondregex => [0-3]\d[.]*\d*
state => off
swoffcondregex =>
swoncondregex => 4[0-3][.]*\d*|[0-3]\d[.]*\d*
type => heater
uetotal => kWh
upcurr => kW
Der Wert "avgenergy => 2386.36" ist plausibel, denn der Strombedarf nimmt bei der WW-Bereitung mit steigender Speichertemperatur kontinuierlich zu, die definierten 2500 W sind als Maximalwert zu sehen.
Aber warum ist jetzt grad angeblich ausreichend Überschuss vorhanden?
Geschirrspüler und Waschmaschine sind nur mit 2000/2200 W definiert (aber als "must"), für die ist grad angeblich kein ausreichender Überschuss vorhanden.
Hier als Beispiel der Geschirrspüler:
01 => alias => Geschirrspueler
asynchron => 1
auto => 0
autoreading => solarforecast_auto
avgenergy => 503.26
avgruntime => 105.87
currpowerpercent => 0.165
cycleStarttime => 1713192157
cycleTime => 0
dspignorecond =>
dswitch => tuya_local_bf7f17146809bc4929lnna
dswoffcond =>
dswoncond =>
ehodpieces => 14=226.47 15=50.33 16=226.47
energythreshold =>
epiecAVG => 1=788.44 2=144.22 3=19.80
epiecAVG_hours => 3
epiecHist => 10
epiecHist_1 => 1=763.00 2=52.00 3=6.00
epiecHist_10 => 1=862.00 2=339.00 3=48.00
epiecHist_10_hours => 3
epiecHist_1_hours => 3
epiecHist_2 => 1=731.00 2=28.00 3=7.00
epiecHist_2_hours => 3
epiecHist_3 => 1=824.00 2=127.00 3=2.00
epiecHist_3_hours => 3
epiecHist_4 => 1=1006.00 2=275.00 3=3.00
epiecHist_4_hours => 3
epiecHist_5 => 1=1.00
epiecHist_5_hours => 1
epiecHist_6 => 1=987.00 2=98.00 3=2.00
epiecHist_6_hours => 3
epiecHist_7 => 1=2.00
epiecHist_7_hours => 1
epiecHist_8 => 1=936.00 2=250.00 3=38.00
epiecHist_8_hours => 3
epiecHist_9 => 1=987.00 2=129.00 3=3.00
epiecHist_9_hours => 3
epiecHour => -1
epiecStartEtotal => 110480
epiecStartTime => 1713184345
epieces => 1=226.47 2=50.33 3=226.47
hysteresis => 0
icon => scene_dishwasher
interruptable => 0
isConsumptionRecommended => 0
isIntimeframe => 0
lastAutoOnTs => 1703248361
lastMinutesOn => 36.8666666666667
lastOnTime => 1713192761
locktime => 0:0
mintime => 165
minutesOn => 0
mode => must
name => tuya_local_bf7f17146809bc4929lnna
noshow => 0
notafter => {sprintf('%02d:%02d', (split ':', main::sunset_abs('HORIZON=0',-90*60))[0], (split ':', main::sunset_abs('HORIZON=0',-90*60))[1])}
notbefore => {sprintf('%02d:%02d', (split ':', main::sunrise_abs('HORIZON=0',60*60))[0], (split ':', main::sunrise_abs('HORIZON=0',90*60))[1])}
numberDayStarts => 0
offcom => off
offreg => [0][.]\d
oncom => on
onoff => off
onreg => [1-9]\d*[.]\d
physoffon => off
planSupplement =>
plandelete => regular
planstate => planned: 2024-04-16 13:00:00 - 2024-04-16 15:45:00
planswitchoff => 1713275100
planswitchon => 1713265200
power => 2000
powerthreshold => 4
remainTime => 0
retotal => energy
rigncond =>
rpcurr => cur_power
rswoffcond =>
rswoncond =>
rswstate => cur_power
spignorecondregex =>
state => off
swoffcondregex =>
swoncondregex =>
type => dishwasher
uetotal => kWh
upcurr => W
NACHTRAG:
Aus einem mir nicht nachvollziehbaren Grund sind die "epiecHist_x" vom WW-Gerät "leer". Kann das die Ursache sein?
Nochmal NACHTRAG:
Wird für die "epiecHist_x" der Wert vom Reading "etotal" herangezogen? Dann ist mir klar, warum das 0 bleibt:
Dieses Reading wird von mir für andere Zwecke nur 1x kurz vor Mitternacht ausgelesen/aktualisiert.
Wie kann ich das Problem umgehen= "etotal" einfach leer lassen?
@cwagner,
ZitatOder hat es damit zu tun, dass ich vorgestern einen Neustart um die Mittagszeit hatte. Tatsächlich habe ich wegen HW-Problemen in jüngerer Zeit häufiger Neustarts, sodass ich jetzt nicht schwören kann, dass Tage mit starken Abweichungen nicht auch Tage mit Neustarts waren.
Solange es sich um normale Restarts, also kein Crash handelt, sind diese Restarts total unschädlich. Das Modul speichert seine Arbeitsspeicherstruktur und stellt sie wieder her, DAten gehen dabei nicht verloren.
Ich bin bis jetzt nicht dahinter gekommen was bei dir das Problem sein könnte. Habe aber prophylaktisch die Berechnungsfunktion nochmal ein wenig umgestellt und getestet.
CHecke die Version nachher noch ein. Du kannst das Verhalten bei dir damit nochmal prüfen bzw. beobachten.
Wie dargestellt sieht es bei meinen Instanzen absolut ok aus.
@TheTrumpeter,
ZitatIch kann nicht nachvollziehen, warum das Modul immer wieder behauptet, dass ausreichend Überschuss für die WW-Bereitung vorhanden wäre, obwohl dem nicht so ist.
Woraus schließt du, dass das Modul es behauptet?
Du hast allerdings eine Ignore-condition angegeben (spignorecondregex => [0-3]\d[.]*\d*) welche bewußt einen fehlenden PV Überschuß irgnorieren kann wenn zutreffend.
Auszug aus Hilfe:
Zitatspignorecond Bedingung um einen fehlenden PV Überschuß zu ignorieren (optional). Bei erfüllter Bedingung wird der Verbraucher entsprechend
der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuß vorliegt.
ACHTUNG: Die Verwendung beider Schlüssel spignorecond und interruptable kann zu einem unerwünschten Verhalten führen!
ZitatAus einem mir nicht nachvollziehbaren Grund sind die "epiecHist_x" vom WW-Gerät "leer". Kann das die Ursache sein?
Die Ursache nicht, siehe oben. Aber etotal des Verbrauchers wird herangezogen um bestimmte Energie Verbrauchskennzahlen zu berechnen. Ist es nicht vorhanden können diese Zahlen nicht berechnet werden. Das ist aber nicht schlimm, da diese Faktoren nur zur Optimierung dienen. Es werden Defaults verwendet. Deswegen ist die Angabe auch nur optional.
Moin,
ich habe mehrere Verbraucher definiert mit Icon. Leider werden die Icons unterschiedlich groß dargestellt - kann ich das irgendwo hamonisieren, daß die Icons alle gleich groß dargestellt werden?
Auswahl_006.png
Gruß, Christoph
Hallo Christoph,
nein. Das Modul kann die Icons selbst nicht anpassen und verwendet eine FHEM Standardfunktion zur Anzeige. Du musst zueinander passende Icons auswählen.
Vermutlich sind nicht alle vorhandenen Icons im FHEM Vorrat mit einer identischen Auflösung erstellt.
LG
Zitat von: DS_Starter am 14 April 2024, 21:17:20Zitat
ZitatNoch eine Frage: Ich habe meine Wallbox als Consumer angezeigt. Allerdings wird der etotal beim Laden nie angezeigt sondern ist immer 0. Mach ich was falsch?
Wahrscheinlich ist die Definition von "etotal=Energy_Meter:kWh" nicht richtig.
"Energy_Meter" wäre laut deiner Angabe der Name des Readings im Device "WebastoNext" welches die Energie in kWh enthält. Mir kommt der Name Energy_Meter für einen Readingnamen etwas eigenartig vor.
Das Reading ist korrekt. Die Wallbox (Webasto Next (https://wiki.fhem.de/wiki/Webasto_Next)) wird per Modbus ausgelesen und ich kann den Namen selber vergeben. Ich orientiere mich dabei an der Namensvergabe durch den Hersteller.
Es zählt auch kontinuierlich hoch.
@tupol,
sorry Mißverständnis meinerseits. Aus etotal werden verschiedenen Dinge intern abgeleitet, aber es wird nicht angezeigt.
Angezeigt in der Flowgrafik wird die aktuelle Leistungsaufnahme (Key "pcurr" Auswertung) und die Restlaufzeit.
LG
Hallo in die Runde,
Ich bin gerade dabei, das SolarForecast - Kompliment, das Modul macht richtig Spaß! Danke an die Entwickler! - auf einem Pi Zero WH einzurichten. Das Abrufen der Daten vom Wechselrichter (98_Fronius.pm) klappt im 10 sek Takt hervorragend. Auch DWD - Einbindung und Forecast liefern für mich gut brauchbare Ergebnisse.
Nun möchte ich gern überschüssigen PV-Strom zum Erwärmen von Brauchwasser nutzen. Dafür habe ich mir auf Basis eines Waveshare Industrial 6-Kanal-Relaismodul (in dem auch der Zero steckt) eine Ansteuerung gebaut, die einen in 500 W Stufen schaltbaren Heizstab ansteuert. Läuft auch soweit alles (und ist abgenommen).
Da ich an der PV-Anlage einen Speicher habe, möchte ich diesen gern nutzen, abends voll haben und den Ladezustand bei der Ansteuerung des Heizstabes berücksichtigen.
Das Einrichten vom Akku im SolarForecast ist ja kein Problem. Wenn ich dann allerdings das Attribut
crtlBatSocManagement
einrichte geht der Pi auf 100% Prozessorauslastung durch FHEM und dann geht über die Oberfläche gar nichts mehr.
In diesem Sinne: hat jemand von euch bereits ein ähnliches Verhalten beobachtet? Oder ist mein Zero WH einfach zu Leistungsschwach (was ich nicht glaube, denn beim ganzen Rest langweilt der sich primär)?
Im Voraus schon einmal vielen Dank und bei Fragen einfach melden.
Hazel
PS: Falls es hilft: Anbei noch die Listings vom SolarForecast, dem SpeicherDummy und dem Notify, um dem SpeicherDummy Readings zu verpassen:
SolarForecast:
Internals:
FUUID 65eaf512-f33f-4c82-2174-7dc6bc03d704f24c
FVERSION 76_SolarForecast.pm:v1.17.7-s28780/2024-04-10
LCACHEFILE last write time: 23:21:43 whole Operating Memory
MODE Automatic - next Cycletime: 23:29:37
MODEL DWD
NAME PV_Forecast
NR 75
NTFY_ORDER 50-PV_Forecast
STATE updated
TYPE SolarForecast
eventCount 70
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
SPGDETAIL PV_Forecast
SPGDEV PV_Forecast
SPGROOM Wechselrichter,Wetter,all
VERSION 1.17.7
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes unused
VERSION_SMUtils 1.27.2
OLDREADINGS:
READINGS:
2024-04-16 23:28:28 Current_AutarkyRate 100 %
2024-04-16 23:28:28 Current_BatCharge 75.30 %
2024-04-16 23:28:28 Current_Consumption 565 W
2024-04-16 23:28:28 Current_GridConsumption 1 W
2024-04-16 23:28:28 Current_GridFeedIn 0 W
2024-04-16 23:28:28 Current_PV 1 W
2024-04-16 23:28:28 Current_PowerBatIn 0 W
2024-04-16 23:28:28 Current_PowerBatOut 563 W
2024-04-16 23:28:28 Current_SelfConsumption 1 W
2024-04-16 23:28:28 Current_SelfConsumptionRate 100 %
2024-04-16 23:28:28 Current_Surplus 0 W
2024-04-16 23:00:00 LastHourGridconsumptionReal 0 Wh
2024-04-16 23:00:00 LastHourPVforecast 0 Wh
2024-04-16 23:00:00 LastHourPVreal 0 Wh
2024-04-16 23:28:28 NextHours_Sum01_PVforecast 0 Wh
2024-04-16 23:28:28 NextHours_Sum02_PVforecast 0 Wh
2024-04-16 23:28:28 NextHours_Sum03_PVforecast 0 Wh
2024-04-16 23:28:28 NextHours_Sum04_ConsumptionForecast 490 Wh
2024-04-16 23:28:28 NextHours_Sum04_PVforecast 0 Wh
2024-04-16 23:28:28 RestOfDayConsumptionForecast 76 Wh
2024-04-16 23:28:28 RestOfDayPVforecast 0 Wh
2024-04-16 00:59:53 Today_Hour01_BatIn 0 Wh
2024-04-16 00:59:53 Today_Hour01_BatOut 240 Wh
2024-04-16 00:59:53 Today_Hour01_GridConsumption 2 Wh
2024-04-16 00:59:53 Today_Hour01_GridFeedIn 1 Wh
2024-04-16 00:59:53 Today_Hour01_PVreal 0 Wh
2024-04-16 01:59:50 Today_Hour02_BatIn 0 Wh
2024-04-16 01:59:50 Today_Hour02_BatOut 198 Wh
2024-04-16 01:59:50 Today_Hour02_GridConsumption 4 Wh
2024-04-16 01:59:50 Today_Hour02_GridFeedIn 1 Wh
2024-04-16 01:59:50 Today_Hour02_PVreal 0 Wh
2024-04-16 02:59:50 Today_Hour03_BatIn 0 Wh
2024-04-16 02:59:50 Today_Hour03_BatOut 308 Wh
2024-04-16 02:59:50 Today_Hour03_GridConsumption 2 Wh
2024-04-16 02:59:50 Today_Hour03_GridFeedIn 1 Wh
2024-04-16 02:59:50 Today_Hour03_PVreal 0 Wh
2024-04-16 03:59:52 Today_Hour04_BatIn 0 Wh
2024-04-16 03:59:52 Today_Hour04_BatOut 331 Wh
2024-04-16 03:59:52 Today_Hour04_GridConsumption 5 Wh
2024-04-16 03:59:52 Today_Hour04_GridFeedIn 2 Wh
2024-04-16 03:59:52 Today_Hour04_PVreal 0 Wh
2024-04-16 04:59:51 Today_Hour05_BatIn 0 Wh
2024-04-16 04:59:51 Today_Hour05_BatOut 218 Wh
2024-04-16 04:59:51 Today_Hour05_GridConsumption 3 Wh
2024-04-16 04:59:51 Today_Hour05_GridFeedIn 1 Wh
2024-04-16 04:59:51 Today_Hour05_PVreal 0 Wh
2024-04-16 05:59:50 Today_Hour06_BatIn 0 Wh
2024-04-16 05:59:50 Today_Hour06_BatOut 924 Wh
2024-04-16 05:59:50 Today_Hour06_GridConsumption 8 Wh
2024-04-16 05:59:50 Today_Hour06_GridFeedIn 4 Wh
2024-04-16 05:59:50 Today_Hour06_PVreal 1 Wh
2024-04-16 06:59:49 Today_Hour07_BatIn 0 Wh
2024-04-16 06:59:49 Today_Hour07_BatOut 2199 Wh
2024-04-16 06:59:49 Today_Hour07_GridConsumption 8 Wh
2024-04-16 06:59:49 Today_Hour07_GridFeedIn 5 Wh
2024-04-16 06:59:49 Today_Hour07_PVforecast 52 Wh
2024-04-16 06:59:49 Today_Hour07_PVreal 65 Wh
2024-04-16 07:59:53 Today_Hour08_BatIn 0 Wh
2024-04-16 07:59:53 Today_Hour08_BatOut 1295 Wh
2024-04-16 07:59:53 Today_Hour08_GridConsumption 8 Wh
2024-04-16 07:59:53 Today_Hour08_GridFeedIn 6 Wh
2024-04-16 07:59:53 Today_Hour08_PVforecast 357 Wh
2024-04-16 07:59:53 Today_Hour08_PVreal 503 Wh
2024-04-16 08:59:50 Today_Hour09_BatIn 257 Wh
2024-04-16 08:59:50 Today_Hour09_BatOut 566 Wh
2024-04-16 08:59:50 Today_Hour09_GridConsumption 17 Wh
2024-04-16 08:59:50 Today_Hour09_GridFeedIn 18 Wh
2024-04-16 08:59:50 Today_Hour09_PVforecast 763 Wh
2024-04-16 08:59:50 Today_Hour09_PVreal 670 Wh
2024-04-16 09:59:51 Today_Hour10_BatIn 541 Wh
2024-04-16 09:59:51 Today_Hour10_BatOut 388 Wh
2024-04-16 09:59:51 Today_Hour10_GridConsumption 12 Wh
2024-04-16 09:59:51 Today_Hour10_GridFeedIn 10 Wh
2024-04-16 09:59:51 Today_Hour10_PVforecast 1946 Wh
2024-04-16 09:59:51 Today_Hour10_PVreal 1062 Wh
2024-04-16 10:59:57 Today_Hour11_BatIn 735 Wh
2024-04-16 10:59:57 Today_Hour11_BatOut 17 Wh
2024-04-16 10:59:57 Today_Hour11_GridConsumption 5 Wh
2024-04-16 10:59:57 Today_Hour11_GridFeedIn 5 Wh
2024-04-16 10:59:57 Today_Hour11_PVforecast 2847 Wh
2024-04-16 10:59:57 Today_Hour11_PVreal 1172 Wh
2024-04-16 11:59:50 Today_Hour12_BatIn 1814 Wh
2024-04-16 11:59:50 Today_Hour12_BatOut 578 Wh
2024-04-16 11:59:50 Today_Hour12_GridConsumption 59 Wh
2024-04-16 11:59:50 Today_Hour12_GridFeedIn 70 Wh
2024-04-16 11:59:50 Today_Hour12_PVforecast 3003 Wh
2024-04-16 11:59:50 Today_Hour12_PVreal 2567 Wh
2024-04-16 12:59:51 Today_Hour13_BatIn 4522 Wh
2024-04-16 12:59:51 Today_Hour13_BatOut 0 Wh
2024-04-16 12:59:51 Today_Hour13_GridConsumption 31 Wh
2024-04-16 12:59:51 Today_Hour13_GridFeedIn 88 Wh
2024-04-16 12:59:51 Today_Hour13_PVforecast 2875 Wh
2024-04-16 12:59:51 Today_Hour13_PVreal 5112 Wh
2024-04-16 13:59:54 Today_Hour14_BatIn 736 Wh
2024-04-16 13:59:54 Today_Hour14_BatOut 66 Wh
2024-04-16 13:59:54 Today_Hour14_GridConsumption 8 Wh
2024-04-16 13:59:54 Today_Hour14_GridFeedIn 6 Wh
2024-04-16 13:59:54 Today_Hour14_PVforecast 3097 Wh
2024-04-16 13:59:54 Today_Hour14_PVreal 1205 Wh
2024-04-16 14:59:50 Today_Hour15_BatIn 1416 Wh
2024-04-16 14:59:50 Today_Hour15_BatOut 1 Wh
2024-04-16 14:59:50 Today_Hour15_GridConsumption 4 Wh
2024-04-16 14:59:50 Today_Hour15_GridFeedIn 1198 Wh
2024-04-16 14:59:50 Today_Hour15_PVforecast 2899 Wh
2024-04-16 14:59:50 Today_Hour15_PVreal 3135 Wh
2024-04-16 15:59:50 Today_Hour16_BatIn 1 Wh
2024-04-16 15:59:50 Today_Hour16_BatOut 81 Wh
2024-04-16 15:59:50 Today_Hour16_GridConsumption 1 Wh
2024-04-16 15:59:50 Today_Hour16_GridFeedIn 1040 Wh
2024-04-16 15:59:50 Today_Hour16_PVforecast 2507 Wh
2024-04-16 15:59:50 Today_Hour16_PVreal 1492 Wh
2024-04-16 16:59:49 Today_Hour17_BatIn 1 Wh
2024-04-16 16:59:49 Today_Hour17_BatOut 1 Wh
2024-04-16 16:59:49 Today_Hour17_GridConsumption 0 Wh
2024-04-16 16:59:49 Today_Hour17_GridFeedIn 1425 Wh
2024-04-16 16:59:49 Today_Hour17_PVforecast 1792 Wh
2024-04-16 16:59:49 Today_Hour17_PVreal 1864 Wh
2024-04-16 17:59:50 Today_Hour18_BatIn 149 Wh
2024-04-16 17:59:50 Today_Hour18_BatOut 161 Wh
2024-04-16 17:59:50 Today_Hour18_GridConsumption 10 Wh
2024-04-16 17:59:50 Today_Hour18_GridFeedIn 8 Wh
2024-04-16 17:59:50 Today_Hour18_PVforecast 1332 Wh
2024-04-16 17:59:50 Today_Hour18_PVreal 646 Wh
2024-04-16 18:59:54 Today_Hour19_BatIn 186 Wh
2024-04-16 18:59:54 Today_Hour19_BatOut 427 Wh
2024-04-16 18:59:54 Today_Hour19_GridConsumption 19 Wh
2024-04-16 18:59:54 Today_Hour19_GridFeedIn 52 Wh
2024-04-16 18:59:54 Today_Hour19_PVforecast 705 Wh
2024-04-16 18:59:54 Today_Hour19_PVreal 729 Wh
2024-04-16 19:59:50 Today_Hour20_BatIn 0 Wh
2024-04-16 19:59:50 Today_Hour20_BatOut 293 Wh
2024-04-16 19:59:50 Today_Hour20_GridConsumption 14 Wh
2024-04-16 19:59:50 Today_Hour20_GridFeedIn 12 Wh
2024-04-16 19:59:50 Today_Hour20_PVforecast 208 Wh
2024-04-16 19:59:50 Today_Hour20_PVreal 149 Wh
2024-04-16 20:59:49 Today_Hour21_BatIn 0 Wh
2024-04-16 20:59:49 Today_Hour21_BatOut 340 Wh
2024-04-16 20:59:49 Today_Hour21_GridConsumption 5 Wh
2024-04-16 20:59:49 Today_Hour21_GridFeedIn 3 Wh
2024-04-16 20:59:49 Today_Hour21_PVreal 8 Wh
2024-04-16 21:59:07 Today_Hour22_BatIn 0 Wh
2024-04-16 21:59:07 Today_Hour22_BatOut 436 Wh
2024-04-16 21:59:07 Today_Hour22_GridConsumption 4 Wh
2024-04-16 21:59:07 Today_Hour22_GridFeedIn 3 Wh
2024-04-16 21:59:07 Today_Hour22_PVreal 1 Wh
2024-04-16 22:59:50 Today_Hour23_BatIn 0 Wh
2024-04-16 22:59:50 Today_Hour23_BatOut 103 Wh
2024-04-16 22:59:50 Today_Hour23_GridConsumption 0 Wh
2024-04-16 22:59:50 Today_Hour23_GridFeedIn 0 Wh
2024-04-16 22:59:50 Today_Hour23_PVreal 0 Wh
2024-04-16 23:28:28 Today_Hour24_BatIn 0 Wh
2024-04-16 23:28:28 Today_Hour24_BatOut 162 Wh
2024-04-16 23:28:28 Today_Hour24_GridConsumption 0 Wh
2024-04-16 23:28:28 Today_Hour24_GridFeedIn 0 Wh
2024-04-16 23:28:28 Today_Hour24_PVreal 0 Wh
2024-04-16 23:28:28 Today_MaxPVforecast 3097 Wh
2024-04-16 23:28:28 Today_MaxPVforecastTime 2024-04-16 13:00:00
2024-04-16 23:28:28 Today_PVdeviation 19.64 %
2024-04-16 23:28:28 Today_PVforecast 24383 Wh
2024-04-16 23:28:28 Today_PVreal 20380 Wh
2024-04-16 23:28:28 Today_SunRise 06:03
2024-04-16 23:28:28 Today_SunSet 20:08
2024-04-16 23:28:28 Tomorrow_ConsumptionForecast 22654 Wh
2024-04-16 23:28:28 Tomorrow_PVforecast 29000 Wh
2024-04-16 23:28:28 Tomorrow_SunRise 06:01
2024-04-16 23:28:28 Tomorrow_SunSet 20:10
2024-04-15 16:22:17 currentBatteryDev BatteryDummy pin=Power_Akku_In:W pout=Power_Akku_Out:W intotal=Akku_Total_In:Wh outtotal=Akku_Total_Out:Wh cap=5:kWh charge=Akku_Charge_State
2024-03-28 14:43:16 currentInverterDev WR_1 pv=PowerFlow_Site_P_PV_Ges:W etotal=PowerFlow_Site_P_PV_Total_E:Wh capacity=6900
2024-03-08 13:08:27 currentMeterDev WR_1 gcon=PowerFlow_Site_P_Grid:W contotal=Meter_0_EnergyReal_WAC_Sum_Consumed:Wh gfeedin=-gcon feedtotal=Meter_0_EnergyReal_WAC_Sum_Produced:Wh
2024-03-08 12:52:22 currentRadiationAPI DWD
2024-03-28 11:24:19 inverterStrings Sued_1,Sued_2
2024-03-28 11:25:25 moduleAzimuth Sued_1=0 Sued_2=0
2024-03-28 11:26:00 moduleDeclination Sued_1=45 Sued_2=30
2024-03-28 11:28:46 modulePeakString Sued_1=4.140 Sued_2=2.760
2024-04-16 23:28:28 nextCycletime 23:29:37
2024-04-16 07:00:05 pvCorrectionFactor_07 1.12 (automatic - old factor: 1, Sun Alt range: 5, Cloud range: 90, Days in range: 1)
2024-04-16 07:00:05 pvCorrectionFactor_07_autocalc done
2024-04-16 08:00:04 pvCorrectionFactor_08 0.92 (automatic - old factor: 0.76, Sun Alt range: 10, Cloud range: 90, Days in range: 4)
2024-04-16 08:00:04 pvCorrectionFactor_08_autocalc done
2024-04-16 09:00:05 pvCorrectionFactor_09 0.73 (automatic - old factor: 0.68, Sun Alt range: 20, Cloud range: 85, Days in range: 4)
2024-04-16 09:00:05 pvCorrectionFactor_09_autocalc done
2024-04-16 10:00:05 pvCorrectionFactor_10 0.89 (automatic - old factor: 1.08, Sun Alt range: 30, Cloud range: 90, Days in range: 2)
2024-04-16 10:00:05 pvCorrectionFactor_10_autocalc done
2024-04-16 11:00:05 pvCorrectionFactor_11 0.92 (automatic - old factor: 1.09, Sun Alt range: 35, Cloud range: 90, Days in range: 4)
2024-04-16 11:00:05 pvCorrectionFactor_11_autocalc done
2024-04-16 12:00:05 pvCorrectionFactor_12 0.93 (automatic - old factor: 1, Sun Alt range: 45, Cloud range: 95, Days in range: 1)
2024-04-16 12:00:05 pvCorrectionFactor_12_autocalc done
2024-04-16 13:00:05 pvCorrectionFactor_13 1.29 (automatic - old factor: 1, Sun Alt range: 45, Cloud range: 95, Days in range: 1)
2024-04-16 13:00:05 pvCorrectionFactor_13_autocalc done
2024-04-16 14:00:06 pvCorrectionFactor_14 0.81 (automatic - old factor: 0.98, Sun Alt range: 45, Cloud range: 95, Days in range: 4)
2024-04-16 14:00:06 pvCorrectionFactor_14_autocalc done
2024-04-16 15:00:05 pvCorrectionFactor_15 1.04 (automatic - old factor: 1, Sun Alt range: 45, Cloud range: 100, Days in range: 1)
2024-04-16 15:00:05 pvCorrectionFactor_15_autocalc done
2024-04-16 16:00:05 pvCorrectionFactor_16 0.80 (automatic - old factor: 1, Sun Alt range: 40, Cloud range: 100, Days in range: 1)
2024-04-16 16:00:05 pvCorrectionFactor_16_autocalc done
2024-04-16 17:00:05 pvCorrectionFactor_17 0.98 (automatic - old factor: 0.94, Sun Alt range: 30, Cloud range: 100, Days in range: 3)
2024-04-16 17:00:05 pvCorrectionFactor_17_autocalc done
2024-04-16 18:00:05 pvCorrectionFactor_18 0.74 (automatic - old factor: 1, Sun Alt range: 25, Cloud range: 100, Days in range: 1)
2024-04-16 18:00:05 pvCorrectionFactor_18_autocalc done
2024-04-16 19:00:05 pvCorrectionFactor_19 1.02 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 100, Days in range: 1)
2024-04-16 19:00:05 pvCorrectionFactor_19_autocalc done
2024-04-16 20:00:03 pvCorrectionFactor_20 0.86 (automatic - old factor: 1, Sun Alt range: 5, Cloud range: 100, Days in range: 1)
2024-04-16 20:00:03 pvCorrectionFactor_20_autocalc done
2024-04-16 23:28:28 pvCorrectionFactor_Auto on_complex_ai
2024-04-16 23:28:29 state updated
Attributes:
ctrlLanguage DE
ctrlWeatherDev1 DWD
event-on-change-reading .*
flowGraphicAnimate 1
room Wechselrichter,Wetter,all
Der BatterieDummy:
Internals:
FUUID 6607f06d-f33f-4c82-d46c-401caf1a121963cc
NAME BatteryDummy
NR 81
STATE 77.20 %
TYPE dummy
eventCount 81
READINGS:
2024-04-16 22:57:58 Akku_Charge_State 77.20
2024-04-16 22:57:58 Akku_Total_In 16572.504
2024-04-16 22:57:58 Akku_Total_Out 19782.038
2024-04-16 22:57:58 Power_Akku_In 0.000
2024-04-16 22:57:58 Power_Akku_Out 416.451
2024-04-16 22:57:58 Power_PV_Ges 1.249
Attributes:
event-on-change-reading .*
icon batterie@green
room Wechselrichter,all
stateFormat Akku_Charge_State %
und das Notify zum befüllen:
Internals:
DEF WR_1:PowerFlow_Site_P_Akku:.* {fhem "setreading BatteryDummy Akku_Total_Out ".sprintf("%.3f",(ReadingsNum("WR_1","PowerFlow_Site_P_Akku_Total_Out",0)));; fhem "setreading BatteryDummy Akku_Total_In ".sprintf("%.3f",(ReadingsNum("WR_1","PowerFlow_Site_P_Akku_Total_In",0)));; my $wert5 = sprintf("%.2f",(ReadingsNum("WR_1","PowerFlow_Inverters_1_SOC",0)));; fhem ("setreading BatteryDummy Akku_Charge_State ".sprintf("%.2f",$wert5));; my $wert6 = sprintf("%.3f",(ReadingsNum("WR_1","PowerFlow_Site_P_PV_Ges",0)));; fhem ("setreading BatteryDummy Power_PV_Ges ".sprintf("%.3f",$wert6));; fhem "setreading BatteryDummy Power_Akku_In ".sprintf("%.3f",(ReadingsNum("WR_1","PowerFlow_Site_P_Akku_In",0)));; fhem "setreading BatteryDummy Power_Akku_Out ".sprintf("%.3f",(ReadingsNum("WR_1","PowerFlow_Site_P_Akku_Out",0)));;}
FUUID 6607f721-f33f-4c82-5b64-94f5874dfd10a2e1
NAME n_BattDummySet
NOTIFYDEV WR_1
NR 82
NTFY_ORDER 50-n_BattDummySet
REGEXP WR_1:PowerFlow_Site_P_Akku:.*
STATE 2024-04-16 22:53:56
TRIGGERTIME 1713300836.17145
TYPE notify
READINGS:
2024-04-16 22:53:21 state active
2024-04-16 22:53:56 triggeredByDev WR_1
2024-04-16 22:53:56 triggeredByEvent PowerFlow_Site_P_Akku: 423.002532958984
Attributes:
room Automatisierung,all
Zitat von: DS_Starter am 16 April 2024, 21:28:28Woraus schließt du, dass das Modul es behauptet?
- Im MouseOver des Uhrsymbols wird "PV Überschuss ausreichend" angezeigt. (Zur gleichen Zeit stand beim Geschirrspüler "PV Überschuss unzureichend", obwohl der mit nur 2000 W definiert ist, die WW-Bereitung aber mit 2500 W.)
- In den "MasterData" steht "isConsumptionRecommended => 1". (Keine Ahnung ob das äquivalent zu "PV Überschuss ausreichend" ist.)
Zitat von: DS_Starter am 16 April 2024, 21:28:28Du hast allerdings eine Ignore-condition angegeben (spignorecondregex => [0-3]\d[.]*\d*) welche bewußt einen fehlenden PV Überschuß irgnorieren kann wenn zutreffend.
Das ist mir schon bewusst, sollte aber die Erkennung "PV Überschuss ausreichend" nicht beeinflussen???
Mal sehen, heute trifft die "Ignore-condition" zur Planungszeit jedenfalls nicht zu. Aktuell ist der Verbraucher für 8:03 eingeplant, wo lt. Prognose ausreichend Überschuss vorhanden sein könnte. Wenn ich aus dem Fenster schaue, bezweifle ich aber, dass sich das ausgeht. Werde dann wieder draufschauen und auch einen Screenshot vom "MouseOver" machen.
Moin,
ZitatIm MouseOver des Uhrsymbols wird "PV Überschuss ausreichend" angezeigt.
Ah ok. Also das Statement "PV Überschuss ausreichend" referenziert auf den Status von isConsumptionRecommended des Consumer Masters. Dieser Wert wiederum ist auch durch das Ergebnis von spignorecondregex gesteuert. D.h. wenn du als User einen real nicht vorhandenen Überschuß bewußt ignorierst, ist aus Sicht des Moduls der "PV Überschuss ausreichend" ... deswegen.
ZitatIn diesem Sinne: hat jemand von euch bereits ein ähnliches Verhalten beobachtet? Oder ist mein Zero WH einfach zu Leistungsschwach (was ich nicht glaube, denn beim ganzen Rest langweilt der sich primär)?
Nein, das Verhalten kenne ich nicht.
Ist auch schwer vorstellbar weil es lediglich interne Berechnungen sind die ein Reading setzen.
Du kannst das Attr ctrlDebug=batteryManagement setzen und den Log Output posten. Vllt. sieht man dann an welcher Stelle es bei dir hakt.
LG
Zitat von: DS_Starter am 17 April 2024, 08:33:51D.h. wenn du als User einen real nicht vorhandenen Überschuß bewußt ignorierst, ist aus Sicht des Moduls der "PV Überschuss ausreichend"
Verdammt, hätte ich es nur vor 5min gelesen...
Also ja, genau das Verhalten kann ich nun bestätigen...
Zuerst war die spignorecond nicht erfüllt, es wurde als "PV Überschuss unzureichend" angezeigt. Dann habe ich probehalber die spignorecond geändert, sodass sie erfüllt ist (swoncond war nicht erfüllt). Schon wurde "PV Überschuss ausreichend" angezeigt.
Ich muss mir überlegen ob ich das dann so lasse, denn
- mit Modus "must" ohne spignorecond und swoncond "ein bei WW-Temp < 40 °C" wurde die Planung immer auf die Zeit gelegt, wo lt. Prognose die höchste PV-Leistung vorhanden war.
- mit Modus "can" inkl. spignorecond "WW-Temp < 40°C" und swoncond "ein bei WW-Temp < 44 °C" wird die Planung auf den frühestmöglichen Zeitpunkt gelegt, wo lt. Prognose ausreichend PV-Leistung vorhanden ist. Wenn die spignorecond nicht erfüllt ist, startet die WW-Bereitung bei unzureichend Überschuss auch nicht. Wenn die spignorecond aber erfüllt ist, startet die WW-Bereitung auch ohne ausreichend Überschuss, obwohl zu einem späteren Zeitpunkt lt. Prognose viel mehr Überschuss vorhanden wäre und die Bedingungen daher besser wären.
Möglicherweise hilft es 2 Verbraucher zu spendieren, einen mit "can" ohne der spignorecond und höherer Einschalttemperatur und einen mit "must" aber niedrigerer Einschalttemperatur. Das wäre etwas umständlicher, müsste aber zum gewünschten Verhalten führen. :-\
Guten Morgen :-)
ZitatDu kannst das Attr ctrlDebug=batteryManagement setzen und den Log Output posten. Vllt. sieht man dann an welcher Stelle es bei dir hakt.
Gesagt ... getan* ...
Aufgefallen ist mir (in der fhem.log) das hier:
2024.04.17 10:08:12 3: PV_Forecast - all registered consumers collected
2024.04.17 10:08:12 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 5 %
2024.04.17 10:08:12 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC -> calculation & activation postponed to after 17.04.2024 18:40:00
Illegal division by zero at ./FHEM/76_SolarForecast.pm line 8206.Hilft dir das evtl. schon weiter? Aktuell habe ich keine Verbraucher angelegt.
Danke und Grüße
*: ich hab das zugegeben nur auskommentierte Attribut (crtlBatSocManagement) in der fhem.cfg wieder rein genommen (ich weiß schon, soll da nicht drin rumwerkeln, aber was willst machen) und schon ging die Prozessorleistung wieder nach oben ...
PS: nachdem ich das wieder auskommentiert habe, tritt diese Fehlermeldung nicht mehr im fhem.log auf ...
Danke dir. Das
Illegal division by zero at ./FHEM/76_SolarForecast.pm line 8206.
Ist natürlich ein Fehler den ich heute Abend korrigiere/vermeide.
Das führt zum Absturz.
Aber ich sehe dein Key cap=5:kWh ist falsch angegeben. In dieser Form währe cap=5000 richtig.
Vergleiche nochmal mit der Hilfe dazu. DAnn siehst du es.
LG
Hallo Hallo,
mach dir keinen Stress ... ist ja für uns beide Hobby :-)
Ansonsten teste ich natürlich gern :-)
Dann noch vielen Dank für den Hinweis. Und du hast recht: Commandref - lesen hilft
ZitatcurrentBatteryDev (...)
cap installed battery capacity (optional). Option can be:
numerical value - direct indication of the battery capacity in Wh
<Readingname>:<unit> - Reading which provides the capacity and unit (Wh, kWh)
Danke dir
Hazel
@ hazelnut
Hi!
Ich habe ein ähnliches Setup wie Du erfolgreich im Einsatz. Aber das läuft leider nicht auf einem RPi Zero, sondern auf größen Linux Systemen. Vielleicht hilft Dir ein anderer Weg, wenn Du auf das Attribut "crtlBatSocManagement", welches Dir Kopfschmerzen bereitet, verzichtest. Bau in die Consumer Definition die swoncond Kondition ein und lass die Consumer damit erst starten, wenn Dein Akku auf 100% SOC ist. So mache ich das bei mir. Natürlich kann in diesem Fall, falls der PV Überschuss beim Laden des Akkus doch teilweise in das Netz geht und dieser schon so groß wäre, dass Deine Heizstäbe aktiv werden könnten, dieser nicht genutzt wird. Aber dieser Fall sollte zeitlich keine große Rolle spielen.
Sonst finde ich Dein Setup cool, das kann man gut einsetzen, wenn keine Hausautomation im Haushalt vorhanden ist und somit minimal und sparsam ein System zur PV Überschusssteuerung bauen. Du hast aber bestimmt nur einen Heizstab mit 3x500 Watt im Einsatz und nutzt nicht die gesamten vorhandenen 6 Relais in Deinem Falle?
Viele Grüße!
Peter
PS: Gerade gesehen, Heiko hat Dir schon geantwortet, ich lass meinen Post aber trotzdem stehen...
Hallo,
ja, das ginge definitiv. Der Heizstab ist halt für Warmwasser. Der Brauchwasserspeicher hat "nur" 150 l von daher geht da gar nicht so viel Energie rein. Und da durch Verbrauch und diesen Vorhaltekreislauf immer was "verloren" geht (gut, heizt halt dann die Hütte), würde ich gern Tagsüber schon nachschieben, wenn absehbar ist, dass der Akku dennoch absehbar voll wird. Ich meine, jeder vermiedene Start vom Ölbrenner zählt ;-)
Daher lieber mit Informationen vom Akku und damit gern auch vorausschauend Energie ins Wasser bringen. Gern mehrmals (kurz) konzentriert (mit hoher Leistung) oder aber eben mit etwas weniger Leistung dauerhaft.
Der Heizstab hat ansonsten tatsächlich Schaltstufen. Allerdings 1x500W, 1x 1.000W und 1x2000W. Somit kann ich in 500W-Schritten von 0,5 - 3,5 kW schalten. Und ja, da das das Relais an die Grenzen bringen würde, steuer ich mit den Relaiskontakten entsprechend Schütze an. Einzig die notwendige Umwälzpumpe (Der Heizstab musste in einen "Durchlauferhitzer") wird direkt geschalten.
Hardwaremäßig hab ich dann noch eine Sicherheitsfunktion eingebaut, nach der der Heizstab im Automatikbetrieb nicht an gehen kann, wenn die Pumpe nicht läuft, ein Gesamt Ein-/Ausschalter versteht sich von selber und ich hab noch einen Notbetrieb mit 2kW und Umwälzpumpe realisiert.
Aktuell schiebe ich im FHEM halt noch den entsprechenden Schieberegler hin und her, der dann die zugehörigen Relaiskontakte schaltet. Macht spaß die Lösung.
Wenn du weitere Fragen dazu hast ...
... Gerne!
Hazel
Hi Hazel,
danke für Deine Antwort und die Details. Hört sich alles sehr gut und durchdacht an. Poste mal bitte den genauen Heizstabtyp, da ich bei einem Freund gerade eine Nachrüstung im Bereich PV Überschussnutzung vornehmen möchte, die auch auf FHEM und SF basiert.
Viele Grüße!
Peter
Kurze Info.
pi@RPiAutoHome:~ $ dmesg | grep "Out of memory: Killed process"
[277851.847081] Out of memory: Killed process 285428 (perl) total-vm:6030992kB, anon-rss:2798544kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:11784kB oom_score_adj:0
[278947.245044] Out of memory: Killed process 286452 (perl) total-vm:6176320kB, anon-rss:2956864kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:12072kB oom_score_adj:0
[279933.610425] Out of memory: Killed process 287461 (perl) total-vm:6330872kB, anon-rss:3060980kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:12372kB oom_score_adj:0
[280414.172907] Out of memory: Killed process 287874 (perl) total-vm:6384316kB, anon-rss:3102232kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:12476kB oom_score_adj:0
[281952.592655] Out of memory: Killed process 289225 (perl) total-vm:6600760kB, anon-rss:3206856kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:12900kB oom_score_adj:0
[282058.247860] Out of memory: Killed process 289384 (perl) total-vm:6615092kB, anon-rss:3238664kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:12928kB oom_score_adj:0
[283222.767919] Out of memory: Killed process 290480 (perl) total-vm:6806632kB, anon-rss:3278444kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:13300kB oom_score_adj:0
[284164.196116] Out of memory: Killed process 291469 (perl) total-vm:6927304kB, anon-rss:3387780kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:13540kB oom_score_adj:0
[284385.292045] Out of memory: Killed process 291489 (perl) total-vm:6935204kB, anon-rss:3426460kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:13556kB oom_score_adj:0
[284676.976277] Out of memory: Killed process 291574 (perl) total-vm:6937952kB, anon-rss:3400612kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:13560kB oom_score_adj:0
[284725.960301] Out of memory: Killed process 107647 (perl) total-vm:6933440kB, anon-rss:3399352kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:13552kB oom_score_adj:0
[446459.659565] Out of memory: Killed process 291764 (perl) total-vm:6822288kB, anon-rss:3417544kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:13324kB oom_score_adj:0
Ich vermute das liegt am DWD mit MOSMIX_S.
Das schaft wohl mein..
pi@RPiAutoHome:~ $ cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.1
pi@RPiAutoHome:~ $ free -h
gesamt benutzt frei gemns. Puffer/Cache verfügbar
Speicher: 3,8Gi 1,3Gi 2,1Gi 0,0Ki 445Mi 2,4Gi
Swap: 4,0Gi 732Mi 3,3Gi
..nicht!
Aber gut ist..
024.04.17 11:29:08.222 1: ForecastOpenMeteo - WARNING - The Total Energy from Inverter 'InverterDummy' is lower than the value saved before. This situation is invalid and the Energy generated of current hour is set to '0'.
Sonst wäre meine History jetzt wieder zermamelt worden.
EDIT 20.04.2024:
Es hat sich rausgestellt das die MOSMIX_S Abfragen bzw. das Modul nicht dafür verantwortlich waren.
Zitat von: hazelnut am 17 April 2024, 12:52:27.. Und ja, da das das Relais an die Grenzen bringen würde, steuer ich mit den Relaiskontakten entsprechend Schütze an. ..
Was für Relais schaltest du den?
Ich schalte meinen Zusatzheizstab (Brauchwasser) mit Shellys. Der Heizstab hat nur "3kw". Kunstvoll verschaltet mit 3 Shellys kann dieser jetzt in 4 Stufen mit max 2kw heizen (500/1000/1500/2000).
Zudem trigger ich die Shellys nur mit on-for-timer x sec immer wieder neu an bei Bedarf. Damit diese auch ausgehen wenn meine Hausautomation off sein sollte und nicht dauer heizen.
Gesteuert wird das Ganze in abhängigkeit der Temperatur des Speichermediums, aktuellem PV-Ertrag und des Batteriespeicherzustandes.
Der Batteriespeicher wird über den PV-Ertrag bzw. auch deren Prognose gesteuert.
Übergreifende Systeme schreien förmlich nach optimierung. Und da ist das Modul echt klasse für, um schon bei zeiten in Aktion zutreten und nicht nur nachzuregeln nach vergangenem. Vorsteuern um die aktuelle Situation bestmöglich auszunutzen.
Zitat von: kask am 17 April 2024, 13:53:57... Kunstvoll verschaltet mit 3 Shellys kann dieser jetzt in 4 Stufen mit max 2kw heizen (500/1000/1500/2000).
Hi, könntest Du bitte mal Deine "kunstvolle Verschaltung" als Stromlaufplan und den genauen Heizstabtyp posten?
Vielen Dank und Gruß!
Peter
Hallo,
ZitatWas für Relais schaltest du den?
Ich hab das hier verbaut: Hutschienen - Relais für RPi (https://www.waveshare.com/rpi-zero-relay.htm)
Vorteil des Raspberry da drin ist, dass ich mit etwas löten und 1-Wire auch die Temperaturen vom Brauchwasserspeicher und vom PV-Heizkreislauf im System habe und über den freien USB-Port auch ne vernünftige LAN-Verbindung ...
Der Gesamte Aufbau passt inkl. Sicherungen, Schütze, Schalter etc. (grad so) in einen 2-Reiher.
Heizstab ist dieser hier: Heizstab / Durchlauferhitzer (https://www.killus-technik.de/de/solartechnik/solar-zubehoer/elektrischer-durchlauferhitzer-pv-vario-0-5-3-5-kilowatt-aus-edelstahl.html)
Öl-Heizung ist ne Buderus, der PV-Heizer-Kreislauf hängt parallel zum Ölbrenner als Quelle dran. Mehr ist es gar nicht. Wenn der Ölbrennerkreislauf an geht, schaltet der PV-Heizkreislauf aus - falls die Frage nach dem Vorrang kommt :-)
Ansonsten:
ZitatGesteuert wird das Ganze in abhängigkeit der Temperatur des Speichermediums, aktuellem PV-Ertrag und des Batteriespeicherzustandes.
Der Batteriespeicher wird über den PV-Ertrag bzw. auch deren Prognose gesteuert.
Ja, das Modul ist genial! Kannst du ein bisschen von deiner Config posten? Weil, genau das wäre auch mein Ziel. Auch wenn die Batterieladesteuerung bei mir eher passiv läuft, da ich das gern dem WR überlassen würde. Weißt schon, dezentrale Systeme, die nicht mehr als nötig merken, dass das andere auch noch da ist - und die auch jeweils ohne das andere auskommen... ;-)
Grüße & bei Fragen gerne
Hazel
Zitat von: kask am 17 April 2024, 13:53:57Zudem trigger ich die Shellys nur mit on-for-timer x sec immer wieder neu an bei Bedarf. Damit diese auch ausgehen wenn meine Hausautomation off sein sollte und nicht dauer heizen.
Dazu ein Zitat aus der CommandRef:
ZitatManche Module unterstützen die sog. set extensions, und in der entsprechenden Dokumentation ist ein Link auf diesem Text zu finden. Falls im Modul selber einer der unten aufgeführten Befehle implementiert ist, dann wird die Modul-Implementation verwendet.
on-for-timer <sekunden>
Das Gerät wird per "on" eingeschaltet, und ein interner Zeitgeber wird erstellt, um nach <sekunden> ein "off" Kommando auszuführen. Um diesen Zeitgeber zu entfernen sollte man das Kommando mit dem Argument 0 erneut aufrufen. Achtung: dieser Zeitgeber wird bei einem restart nicht gespeichert.
Keine Ahnung wie's im Shelly-Modul implementiert ist, aber lt. obigem Zitat wäre der Ablauf nach meinem Verständnis folgender:
- Du schickst "set shelly-relais-1 on-for-timer 600", damit das Relais für 10 min einschaltet.
- Shelly-Modul macht aber: set shelly-relais-1 on, sleep 600 quiet, set shelly-relais-1 off
Wenn in den 10 Minuten nach dem "set shelly-relais-1 on" der FHEM-Server abstürzt, bleibt das Relais bis zum St. Nimmerleinstag eingeschaltet.
Tuya-Steckdosen bieten beispielsweise einen "countdown" an. Da übernimmt das Ausschalten dann tatsächlich das Gerät selbst:
- set tuya-steckdose-1 on, set tuya-steckdose-1 countdown_1 600
Das "Absturz-Risiko" ist damit minimiert.
Das probier ich mal aus. Mit Tasmota geht das mit dem on-for-timer auf jedenfall. Die Shellys gingen auch aus als ich das getestet hatte. Aber da war fhem noch aktiv. Mal schauen wie sich das verhält wenn fehm nicht mehr aktiv ist. Vermutlich wird das auch gehen. Werde ich aber denoch testen nach deinem Post.
Edit: Also mit den Shellys geht das auch Problemlos. Diese sind über MQTT angebunden. Keine Ahnung ob dadurch Unterschiede gibt.
Fakt ist das Tasmota und Shellys über MQTT ausschalten bei on-for-timer. Auch bei nicht mehr laufender Automation.
Als Heizstab habe ich so einen wie hier nur als 3kW Version.
Kann den nur empfehlen wenn man wirklich einen günstigen Edelstahlheizstab braucht. Hatte auch Andere die sehr schnell vergammelt sind!
https://www.ebay.de/itm/134489081323?var=433968446557
Schaltbild siehe Anhang.
Zitat von: hazelnut am 17 April 2024, 14:21:45ZitatJa, das Modul ist genial! Kannst du ein bisschen von deiner Config posten? Weil, genau das wäre auch mein Ziel. Auch wenn die Batterieladesteuerung bei mir eher passiv läuft, da ich das gern dem WR überlassen würde. Weißt schon, dezentrale Systeme, die nicht mehr als nötig merken, dass das andere auch noch da ist - und die auch jeweils ohne das andere auskommen... ;-)
Ich steuer momentan nix aktiv direkt mit dem Modul. Ich nutze "nur" die Vorhersage bzw. die Werte um damit etwas zu steuern.
Somit ist die Config eher langweilig.
ZitatIllegal division by zero at ./FHEM/76_SolarForecast.pm line 8206.
Die mögliche "Devsion by zero" habe ich nun abgefangen bzw. prüfe nun auch eine fehlerhafte Definition des Schüssels cap.
Die V ist eingecheckt und morgen früh im Update. Die V liegt auch in meinem contrib für Eilige.
Hallo Heiko,
ich habe heute einen Debug auf consumerswitching gemacht um heraus zu bekommen weshalb ich alle 4 Sec. einen Schaltbefehl generiere. Kannst du mal drüber schauen wo der Fehler sein könnte?
Wenn du noch weitere Info brauchst lass es mich wissen.
2024.04.16 10:38:27 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:29 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:29 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:30 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:30 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:31 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:31 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:31 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:31 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:31 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:31 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:31 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:31 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:32 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:32 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:32 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:32 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:32 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:32 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:32 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:32 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:33 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:33 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:33 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:33 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:33 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:33 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:33 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:33 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:34 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:34 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:34 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:34 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:34 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:34 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:34 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:34 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:35 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:35 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:35 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:35 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:35 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:35 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:35 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:35 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:36 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:36 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:36 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:36 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:36 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:36 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:36 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:36 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:37 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:37 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:37 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:37 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:37 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:37 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:37 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:37 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:39 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:39 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:39 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:39 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:39 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:39 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:39 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:39 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:40 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:40 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:40 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:40 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:40 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:40 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:40 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:40 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:41 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:41 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:41 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:41 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:41 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:42 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:42 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:42 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:43 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:43 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:43 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:43 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:43 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:43 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:43 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:43 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:44 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:44 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:44 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:44 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:44 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:44 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:44 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:44 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:45 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:45 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:45 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:45 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:45 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:45 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:45 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:45 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:46 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:46 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:46 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:46 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:46 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:46 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:46 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:46 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:47 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:47 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:47 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:47 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:47 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:47 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:47 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:47 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:48 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:48 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:48 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:48 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:48 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:48 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:48 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:48 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:49 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:49 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:49 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:49 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:49 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:49 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:49 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:49 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:50 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:50 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:50 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:50 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:50 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:51 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:51 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:51 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:52 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:52 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:52 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:52 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:52 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:52 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:52 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:52 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:53 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:53 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:53 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:53 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:53 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:53 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:53 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:53 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:54 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:54 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:54 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:54 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:54 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:55 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:55 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:55 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:56 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:56 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:56 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:56 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:56 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:56 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:56 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:56 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:57 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:57 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:57 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:57 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:57 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:57 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:57 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:57 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:58 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:58 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:58 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:58 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:58 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:58 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:58 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:58 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:59 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:59 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:59 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:59 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:59 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:59 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:59 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:59 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:01 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:01 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:01 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:01 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:01 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:01 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:01 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:01 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:04 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:04 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:04 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:04 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:04 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:04 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:04 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:04 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:06 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:06 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:06 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:06 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:06 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:06 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:06 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:06 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:07 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:07 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:07 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:07 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:07 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:07 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:07 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:07 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:08 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:08 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:08 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:08 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:08 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:09 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:09 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:09 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:10 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:10 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:10 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:10 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:10 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:10 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:10 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:10 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:11 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:11 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:11 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:11 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:11 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:11 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:11 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:11 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:13 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:13 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:13 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:13 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:14 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:14 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:14 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:14 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:14 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:14 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:14 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:14 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:15 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:15 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:15 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:15 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:16 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:16 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:16 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:16 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:16 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:16 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:16 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:16 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:17 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:17 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:17 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:17 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:17 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:17 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:17 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:17 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:18 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:18 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:18 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:18 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:18 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:18 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:18 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:18 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:20 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:20 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:20 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:20 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:20 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:20 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:20 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:20 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:21 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:21 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:21 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:21 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:21 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:21 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:21 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:21 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:22 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:22 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:22 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:22 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:22 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:23 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:23 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:23 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:25 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:25 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:25 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:25 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:25 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:25 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:25 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:25 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:26 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:26 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:26 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:26 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:26 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:26 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:26 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:39:26 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:39:27 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:39:27 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:39:27 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:39:27 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:39:27 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:39:27 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:39:27 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
Gruß Bison
Was ich aktuelle sehe ist dass jede 1-2 Sekunden ein Schaltbefehl ausgeführt wird:
2024.04.16 10:38:27 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:29 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:29 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:30 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:30 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
Erkannt wird der Status nicht.
Wie steht dein Attribut ctrlInterval?
Hi,
Zitat von: DS_Starter am 17 April 2024, 19:55:45ZitatIllegal division by zero at ./FHEM/76_SolarForecast.pm line 8206.
Die mögliche "Devsion by zero" habe ich nun abgefangen bzw. prüfe nun auch eine fehlerhafte Definition des Schüssels cap.
Die V ist eingecheckt und morgen früh im Update. Die V liegt auch in meinem contrib für Eilige.
So, Update ist durch ...
Internals:
FUUID 65eaf512-f33f-4c82-2174-7dc6bc03d704f24c
FVERSION 76_SolarForecast.pm:v1.17.8-s28799/2024-04-16
MODE Automatic - next Cycletime: 23:14:56
MODEL DWD
NAME PV_Forecast
NR 75
NTFY_ORDER 50-PV_Forecast
STATE updated
TYPE SolarForecast
eventCount 4
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
SPGDETAIL
SPGDEV PV_Forecast
SPGROOM
VERSION 1.17.8
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes unused
VERSION_SMUtils 1.27.2
...Die Auslastung vom Pi hält sich in Grenzen ...
average: 0.16, 0.18, 0.18... und in der Logdatei steht:
...
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)...Der Bauch sagt ... dass das so aussehen könnte :-)
Dann werde ich das mal die Tage beobachten und schauen, wie ich am sinnvollsten weitermache.
Dir erst einmal vielen Dank und ich hoffe die Infos helfen dir.
Gutes Nächtle
Hazel
@Bison,
wird das Set-Kommando "on" eigentlich ausgeführt wenn du manuell im HM-Device ausführst?
Zitat von: DS_Starter am 17 April 2024, 23:12:39Was ich aktuelle sehe ist dass jede 1-2 Sekunden ein Schaltbefehl ausgeführt wird:
2024.04.16 10:38:27 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:29 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:29 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:30 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:30 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
Erkannt wird der Status nicht.
Wie steht dein Attribut ctrlInterval?
Hallo Heiko,
das Attribut ctrlInterval ist nicht gesetzt.
Gruß
Zitat von: DS_Starter am 17 April 2024, 23:44:03@Bison,
wird das Set-Kommando "on" eigentlich ausgeführt wenn du manuell im HM-Device ausführst?
Ja es wird sogar ein und ausgeschaltet.
Der Consumer ist so definiert.
STD_AKT_1_Pwr type=heater power=250 switchdev=STD_AKT_1_Sw mode=can icon=Ventilator_wind on=on off=off swstate=state:.*on:*:.*off.* asynchron=1 notbefore=10 notafter=18 locktime=900:900 auto=1 pcurr=power:W:250 etotal=energy:Wh interruptable=1
Zitat von: kask am 17 April 2024, 18:38:27Edit: Also mit den Shellys geht das auch Problemlos. Diese sind über MQTT angebunden. Keine Ahnung ob dadurch Unterschiede gibt.
Fakt ist das Tasmota und Shellys über MQTT ausschalten bei on-for-timer. Auch bei nicht mehr laufender Automation.
Der Auszug von oben ist aus der CommandRef zu den "set extensions". Da steht auch dabei, dass im Zweifelsfall die Modul-eigene Implementierung "gewinnt". Offensichtlich unterstützen die Shellys und Tasmota eine Art "Timer/Countdown" am Gerät selbst, d.h. beim Absetzen von "on-for-timer" wird dem Gerät direkt mitgegeben wie lange das Gerät eingeschaltet sein soll. (Ähnlich wie der "countdown" bei Tuya, aber möglicherweise sogar in einem einzigen Befehl?)
MQTT hat damit nix zu tun, das müsste egal sein wie Du mit den Dingern kommunizierst.
Meine Bewässerung wird von einem ESP32 mit ESPEasy angesteuert, da setze ich in FHEM auch die Befehle ab, die die Timer direkt am Gerät laufen lassen. (Zusätzlich habe ich dort noch eine interne und zwei externe Überwachungen eingebaut, die dafür sorgen, dass die Ventile bei einem Gerätereboot oder allerspätestens bei Sonnenaufgang geschlossen werden. Wird paar Minuten nach Sonnenaufgang immer noch Wasser verbraucht, dann wird die gesamte Steuerung über eine schaltbare Steckdose vom Netz genommen. Spätestens dann muss Ruhe sein.)
Zitat von: TheTrumpeter am 18 April 2024, 06:54:28Offensichtlich unterstützen die Shellys und Tasmota eine Art "Timer/Countdown" am Gerät selbst, d.h. beim Absetzen von "on-for-timer" wird dem Gerät direkt mitgegeben wie lange das Gerät eingeschaltet sein soll. (Ähnlich wie der "countdown" bei Tuya, aber möglicherweise sogar in einem einzigen Befehl?)
Als "Erfinder" des Shelly-Moduls kann ich die Spekulation durch Klarheit ersetzen: Ja, Viele (nicht alle) Shelly-Devices erlauben das Setzen interner Timer mit einem einzigen REST-Call. Allerdings bitte nicht mit Tuya in einen Topf werfen.
LG
pah
Moin,
@Bison,
Hier stimmt etwas nicht:
swstate=state:.*on:*:.*off.*
So wäre es richtig:
swstate=state:.*on.*:.*off.*
Da du asynchron=1 gesetzt hast (was allerdings bei den Homematic Devices nicht nötig ist weil sie direkt schalten), wird bei einem Event von STD_AKT_1_Sw die Logik im SF angesprochen. Daher wahrscheinloch die hohe Frequenz der Logmeldungen. Das kannst du mit ctrlDebug=notifyHandling überprüfen.
Die grundlegende Sache ist allerdings das falsche Setting im Key swstate.
LG
Guten Morgen,
die zweite Nacht in Folge wird der Docker Container Fhem "unhealthy" und nichts geht mehr.
Einer der letzten Log-Einträge ist:
Illegal division by zero at ./FHEM/76_SolarForecast.pm line 10220.
Ich bin auf Version: 76_SolarForecast.pm:v1.17.9-s28804/2024-04-17
Ich habe vor, dass Device zu deinstallieren um die Gegenprobe zu machen und zu schauen, ob der Container durchläuft.
Schade :(
Morgen Reinschki,
nicht gleich die Flinte ins Korn werfen. ;)
Da war die vorletzte Änderung bzgl. Abweichungsberechnung nicht so optimal. Das korrigiere ich heute noch.
Als schnellen Workaround stellst du das Attr ctrlGenPVdeviation auf daily.
LG
@Reinschki,
ich habe das Problem gefixt und eingecheckt.
In meinem contrib liegt die gleiche Version zum sofortigen Download wenn du si schon einspielen magst.
LG,
Heiko
Hallo Heiko,
die 1.17.10 ist installiert -> ich werde berichten.
An dieser Stelle herzlichen Dank für das Modul und deine engagierte Supportleistung!
Viele Grüße
Reiner
Hallo,
ich wollte mal fragen, wie ihr das mit einer Batterie gelöst habt. Ich lese die BYD Batterie als currentBatteryDev über den SMA Sunny Tripower SE Wechselrichter aus und lasse sie bei SF anzeigen. Da ich gerne den Batterie Bezug auch nach Sonnenuntergang im SF Modul angezeigt bekommen möchte, habe ich beim 76_SMAInverter.pm attr suppressSleep 1 gesetzt. Jetzt wird mir aber der Bezug aus der Batterie (z.B. nach Sonnenuntergang) offensichtlich als Ertrag angerechnet, weswegen es zu hohen Abweichungen von der Modul Prognose kommt (gestern z.B. 36,8%).
Wie kann man das umgehen?
LG
oelidoc
Hat 76_SMAInverter keine getrennten Readings für PV Erzeugung und Batterie in/out?
Doch
define SunnyTripower8.0SE SMAInverter crypt:xxxxxxxxxxxxxxxxxx 192.xxx.xxx.xx
attr SunnyTripower8.0SE detail-level 1
attr SunnyTripower8.0SE mode automatic
attr SunnyTripower8.0SE readEnergyMeter-data 1
attr SunnyTripower8.0SE room Photovoltaik
attr SunnyTripower8.0SE stateFormat {sprintf("%.1f",ReadingsNum($name,"state",0))." W"}
attr SunnyTripower8.0SE suppressSleep 0
attr SunnyTripower8.0SE target-serial xxxxxxxxx
attr SunnyTripower8.0SE target-susyid 440
attr SunnyTripower8.0SE verbose 2
# DEF crypt:xxxxxxxxxxxxxxxxxxx 192.xxx.xxx.xx
# FUUID 65e1bd9e-f33f-74ea-0abe-0570e6a936905ef0
# FVERSION 76_SMAInverter.pm:v2.24.1-s28631/2024-03-10
# HOST 192.xxx.xxx.xx
# INTERVAL 60
# INVCLASS 8009
# INVFWMAIN 0
# INVTYPE 19050
# LASTUPDATE 19.04.2024 / 21:01:17
# NAME SunnyTripower8.0SE
# NR 646
# PASS crypt:xxxxxxxxxxxxxxxxxxx
# STATE 0.0 W
# TYPE SMAInverter
# eventCount 157
# HELPER:
# AVERAGEBUF 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
# DEFAULT_TARGET_SERIAL xxxxxxxxxx
# DEFAULT_TARGET_SUSYID 65535
# FAULTEDCYCLES 0
# INTERVAL 60
# MAXBYTES 300
# MYSERIALNUMBER xxxxxxxxx
# MYSUSYID 233
# PACKAGE main
# PKT_ID 32769
# VERSION 2.24.1
# firtRunDay 0
# READINGS:
# 2024-04-19 21:01:17 BAT_IDC 3185
# 2024-04-19 21:01:17 BAT_LOADTODAY 7307
# 2024-04-19 21:01:17 BAT_LOADTOTAL 518830
# 2024-04-19 21:01:17 BAT_P_CHARGE 0
# 2024-04-19 21:01:17 BAT_P_DISCHARGE 282
# 2024-04-19 21:01:17 BAT_UDC 20
# 2024-04-19 21:01:17 BAT_UNLOADTODAY 5629
# 2024-04-19 21:01:17 BAT_UNLOADTOTAL 357843
# 2024-04-19 21:01:17 ChargeStatus 68
# 2024-04-19 21:01:17 Meter_Grid_Consumation_PAC1 4
# 2024-04-19 21:01:17 Meter_Grid_Consumation_PAC2 0
# 2024-04-19 21:01:17 Meter_Grid_Consumation_PAC3 18
# 2024-04-19 21:01:17 Meter_Grid_FeedIn_PAC1 0
# 2024-04-19 21:01:17 Meter_Grid_FeedIn_PAC2 21
# 2024-04-19 21:01:17 Meter_Grid_FeedIn_PAC3 0
# 2024-04-19 21:01:17 Meter_Power_Grid_Consumation 1
# 2024-04-19 21:01:17 Meter_Power_Grid_FeedIn 0
# 2024-04-19 21:01:17 Meter_TOTAL_Consumation 2427492
# 2024-04-19 21:01:17 Meter_TOTAL_FeedIn 7738685
# 2024-04-19 21:01:17 Meter_TOTAL_Grid_Consumation 2427492
# 2024-04-19 21:01:17 Meter_TOTAL_Grid_FeedIn 7738685
# 2024-04-19 21:01:17 SPOT_Backup_IAC1 0.10
# 2024-04-19 21:01:17 SPOT_Backup_IAC2 0.00
# 2024-04-19 21:01:17 SPOT_Backup_IAC3 0.10
# 2024-04-19 21:01:17 SPOT_Backup_PAC1 23
# 2024-04-19 21:01:17 SPOT_Backup_PAC2 0
# 2024-04-19 21:01:17 SPOT_Backup_PAC3 23
# 2024-04-19 21:01:17 SPOT_CosPhi 0.000
# 2024-04-19 21:01:17 SPOT_EPVTODAY 13950
# 2024-04-19 21:01:17 SPOT_EPVTOTAL 1733347
# 2024-04-19 21:01:17 SPOT_ETODAY 11618
# 2024-04-19 21:01:17 SPOT_ETOTAL 1581481
# 2024-04-19 21:01:17 SPOT_IAC1 0.50
# 2024-04-19 21:01:17 SPOT_IAC2 0.60
# 2024-04-19 21:01:17 SPOT_IAC3 0.50
# 2024-04-19 21:01:17 SPOT_IDC1 0
# 2024-04-19 21:01:17 SPOT_IDC2 0
# 2024-04-19 21:01:17 SPOT_PAC1 90
# 2024-04-19 21:01:17 SPOT_PAC2 96
# 2024-04-19 21:01:17 SPOT_PAC3 95
# 2024-04-19 21:01:17 SPOT_PACTOT 281
# 2024-04-19 21:01:17 SPOT_PDC 0
# 2024-04-19 21:01:17 SPOT_PDC1 0
# 2024-04-19 21:01:17 SPOT_PDC2 0
# 2024-04-19 21:01:17 SPOT_UAC1 227.7
# 2024-04-19 21:01:17 SPOT_UAC1_2 394.300
# 2024-04-19 21:01:17 SPOT_UAC2 228.8
# 2024-04-19 21:01:17 SPOT_UAC2_3 396.200
# 2024-04-19 21:01:17 SPOT_UAC3 228.3
# 2024-04-19 21:01:17 SPOT_UAC3_1 395.400
# 2024-04-19 21:01:17 SPOT_UDC1 0
# 2024-04-19 21:01:17 SPOT_UDC2 0
# 2024-04-19 21:01:17 avg_power_lastminutes_05 0
# 2024-04-19 21:01:17 avg_power_lastminutes_10 0
# 2024-04-19 21:01:17 avg_power_lastminutes_15 0
# 2024-04-19 21:01:17 modulstate normal
# 2024-04-19 21:01:17 opertime_start 19.04.2024 05:50:12
# 2024-04-19 21:01:17 opertime_stop 19.04.2024 21:13:09
# 2024-04-19 21:01:17 state 0
# hmccu:
#
setstate SunnyTripower8.0SE 0.0 W
setstate SunnyTripower8.0SE 2024-04-19 00:00:20 .bat_loadtotal_yesterday 511523
setstate SunnyTripower8.0SE 2024-04-19 00:00:20 .bat_unloadtotal_yesterday 352214
setstate SunnyTripower8.0SE 2024-04-19 00:00:20 .epvtotal_yesterday 1719397
setstate SunnyTripower8.0SE 2024-04-19 00:00:20 .etotal_yesterday 1569187
setstate SunnyTripower8.0SE 2024-04-19 00:00:20 .yesterday 19
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_IDC 3185
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_LOADTODAY 7307
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_LOADTOTAL 518830
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_P_CHARGE 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_P_DISCHARGE 282
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_UDC 20
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_UNLOADTODAY 5629
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 BAT_UNLOADTOTAL 357843
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 ChargeStatus 68
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Grid_Consumation_PAC1 4
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Grid_Consumation_PAC2 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Grid_Consumation_PAC3 18
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Grid_FeedIn_PAC1 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Grid_FeedIn_PAC2 21
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Grid_FeedIn_PAC3 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Power_Grid_Consumation 1
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_Power_Grid_FeedIn 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_TOTAL_Consumation 2427492
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_TOTAL_FeedIn 7738685
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_TOTAL_Grid_Consumation 2427492
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 Meter_TOTAL_Grid_FeedIn 7738685
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_Backup_IAC1 0.10
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_Backup_IAC2 0.00
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_Backup_IAC3 0.10
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_Backup_PAC1 23
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_Backup_PAC2 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_Backup_PAC3 23
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_CosPhi 0.000
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_EPVTODAY 13950
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_EPVTOTAL 1733347
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_ETODAY 11618
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_ETOTAL 1581481
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_IAC1 0.50
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_IAC2 0.60
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_IAC3 0.50
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_IDC1 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_IDC2 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_PAC1 90
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_PAC2 96
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_PAC3 95
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_PACTOT 281
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_PDC 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_PDC1 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_PDC2 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UAC1 227.7
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UAC1_2 394.300
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UAC2 228.8
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UAC2_3 396.200
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UAC3 228.3
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UAC3_1 395.400
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UDC1 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 SPOT_UDC2 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 avg_power_lastminutes_05 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 avg_power_lastminutes_10 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 avg_power_lastminutes_15 0
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 modulstate normal
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 opertime_start 19.04.2024 05:50:12
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 opertime_stop 19.04.2024 21:13:09
setstate SunnyTripower8.0SE 2024-04-19 21:01:17 state 0
Hier die Definition des currentBatteryDevice
SunnyTripower8.0SE pin=BAT_P_CHARGE:W pout=BAT_P_DISCHARGE:W intotal=BAT_LOADTOTAL:W outtotal=BAT_UNLOADTOTAL:W charge=ChargeStatus cap=7700
Das sieht ok aus. Und currentInverterDev?
Ein Screenshot mit der aktuellen FlowGrafik wäre auch gut.
currentInverterDevice
SunnyTripower8.0SE pv=state:W etotal=SPOT_ETOTAL:Wh capacity=8000
Der Ertag (orange bei 21 Uhr) wächst...
Das ist völlig in Ordnung.
Du siehst auch an Hand der Flußgrafik dass keine Erzeugung registriert wird. Das ist das Laufband von der Sonne zum Haus.
Edit: Im SF Modul gibt es das Reading Current_PV. Das sollte zur Zeit auch 0 anzeigen. Bzw. Current_PowerBatOut was momentan den Batterie Out Wert anzeigen würde.
Beide Readings vorhanden :D
Warum dann solch große Abweichungen?
Vielleicht war der Sachververhalt tatsächlich so wie reported. (Bild kann man wieder nicht aufrufen)
Du müsstest natürlich mal am Tag! überprüfen ob die Readings vom SMAInverter auch den richtigen Sachverhalt darstellen. Nicht dass das WR Reading etotal den Betrag unterschlägt der in die Batterie als Ladeenergie fließt!
Zitat von: DS_Starter am 19 April 2024, 21:28:16Du müsstest natürlich mal am Tag! überprüfen ob die Readings vom SMAInverter auch den richtigen Sachverhalt darstellen. Nicht dass das WR Reading etotal den Betrag unterschlägt der in die Batterie als Ladeenergie fließt!
Okay, aber Abweichung heute + 22,5% bedeutet doch, ich hab 22,5% mehr produziert als prognostiziert, oder?
Und warum ändert sich die "Abweichung heute" noch nach Sonnenuntergang?
ZitatOkay, aber Abweichung heute + 22,5% bedeutet doch, ich hab 22,5% mehr produziert als prognostiziert, oder?
Leider nein. Es wurde mehr (+) prognostiziert als tatsächlich produziert. Mouse-Over zeigt das.
ZitatUnd warum ändert sich die "Abweichung heute" noch nach Sonnenuntergang?
Bei mir ändert sich nichts. Beobachte die Readings Today_PVreal, Today_PVforecast und RestOfDayPVforecast.
Dort sollten sich die Werte nicht mehr ändern. Sie werden dazu ausgewertet.
Uuups, TodayPVreal und Today_PVdeviation steigen. Und dem entsprechend auch die Anzeige der "Abweichung heute". Die beträgt jetzt schon 23,8%...
Na dann setze mal ctrlDebug=collectData und schau dir die Sektion von Inverterdata an:
..
2024.04.19 22:03:07.036 1: SolCast DEBUG> collect Inverter data - device: MySTP_5000 =>
2024.04.19 22:03:07.037 1: SolCast DEBUG> pv: 0 W, etotal: 58146549 Wh
2024.04.19 22:03:07.037 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2024.04.19 22:03:07.038 1: SolCast DEBUG> gcon: 14.5 W, gfeedin: 0 W, contotal: 5006.5 Wh, feedtotal: 138910.8 Wh[code]
...
Der Wert etotal darf sich zwischen den Zyklen nicht mehr ändern.
Okay, der Wert steigt. Hab ich wohl das falsche Reading für etotal. Aber welches ist dann das richtige? SPOT_EPVTOTAL?
Der Wechselrichter von SMA dürfte ja nicht so selten sein. Vielleicht meldet sich ja wer, der den auch hat...
Gruß und Dank
oelidoc
Ich vermute es wäre das Reading SPOT_EPVTOTAL (nur der PV Anteil).
Mein WR ist ein einfacher STP ohne Batterie. Dieses Reading habe ich nicht.
Ansonsten kannst du mal bei MadMax im SMAInverter Forum nachfragen und ihm einen lieben Gruß von mir bestellen. :)
Hab die Hilfe von 76_SMAInverter.pm aufgerufen:
SPOT_ETODAY / etoday : Energie heute
SPOT_EPVTOTAL / epvtotal : PV Energie Insgesamt
SPOT_EPVTODAY / epvtoday : PV Energie heute
SPOT_ETOTAL / etotal : Energie InsgesamtDementsprechend also genau wie von dir vermutet SPOT_EPVTOTAL
Vielen Dank, werde dann mal mein InverterDevice ändern und beobachten.
Danke für den tollen Support
oelidoc
So ... ich verabschiede mich mal für einige Zeit (Schaue aber vllt. auch mal vorbei :) ).
Wünsche euch viele sonnige und ertragreiche Tage!
Wenn ihr vor Problemen steht, hilft oftmals ein entsprechendes ctrlDebug weiter. Mit ein bisschen Erfahrung kann man die Werte auch deuten die dort kommen.
LG,
Heiko
Zitat von: oelidoc am 19 April 2024, 21:03:05crypt:xxxxxxxxxxxxxxxxxxxxxxx
Immer aufpassen, was man so postet.
LG
pah
ZitatGuten Morgen,
die zweite Nacht in Folge wird der Docker Container Fhem "unhealthy" und nichts geht mehr.
Einer der letzten Log-Einträge ist:
CodeAuswählen
Illegal division by zero at ./FHEM/76_SolarForecast.pm line 10220.
Ich bin auf Version: 76_SolarForecast.pm:v1.17.9-s28804/2024-04-17
Ich habe vor, dass Device zu deinstallieren um die Gegenprobe zu machen und zu schauen, ob der Container durchläuft.
Schade :(
Guten Morgen Heiko,
deine Überarbeitung hat das Problem gefixt! Fhem ist auch heute Morgen noch munter bei der Arbeit!
Vielen Dank!
Gruß
Reiner
Zitat von: Prof. Dr. Peter Henning am 20 April 2024, 06:23:14Immer aufpassen, was man so postet.
LG
pah
Vielen Dank für den Hinweis
Gruß
oelidoc
Hallo zusammen,
vielen Dank für dieses Modul! Es läuft im Testbetrieb hier bisher ganz gut aber auch erst seit 2 Tagen und ohne komplexe Verbraucher.
Eine Frage habe ich: Kann man die Abweichung heute bzw. morgen auch als Reading ausgeben lassen oder irgendwie anders da ran kommen? Oder generell auch die Informationen, die sich hinter "AI state" und "Quality" verbergen?
Gruß
Jojo
Schau nach dem Reading <Today_PVdeviation> und dem Attribut <ctrlGenPVdeviation>
Abweichung von Morgen ist schlecht. Wäre eine Prognose der Prognose ;)
Oder auch ein Paradoxon. Wenn du heute weißt was morgen nicht stimmt. Wieso stimmt es heute nicht? Denn das wußtest du ja gestern schon!
Seit einem Update vor 1-2 Tagen erhalte ich nachts im Log (teils mehrfach) folgendes:
Zitat2024.04.21 00:00:04 1: PVVorschau - WARNING - The Total Energy from Inverter 'SMATripower6' is lower than the value saved before. This situation is invalid and the Energy generated of current hour is set to '0'.
Zitat von: SparcWolf am 21 April 2024, 12:29:46Schau nach dem Reading <Today_PVdeviation> und dem Attribut <ctrlGenPVdeviation>
Ich meine natürlich heute und gestern :)
Danke für den Hinweis, das ist es was ich gesucht habe.
Gruß
Jojo
Zitat von: Dracolein am 21 April 2024, 15:01:56Seit einem Update vor 1-2 Tagen erhalte ich nachts im Log (teils mehrfach) folgendes:
Zitat2024.04.21 00:00:04 1: PVVorschau - WARNING - The Total Energy from Inverter 'SMATripower6' is lower than the value saved before. This situation is invalid and the Energy generated of current hour is set to '0'.
Das liegt vermutlich daran das der sma inverter schon den Tageszähler reseted hat und das Modul noch nicht. Dann ist der reale Inverterzählerwert kleiner wie der bekannte Modulzählerwert. Wird seit einigen Versionen auf plausibilität geprüft.
Damit unteranderem folgendes wie in dem Post nicht passiert:
https://forum.fhem.de/index.php?topic=137058.msg1309964#msg1309964
Hmmm, so wirklich verstehe ich nicht, wie ich mein o.g. Problemchen beheben kann
Wo ist den dein Problemchen? Das eine Warnung kommt?
Könnte es irrtümlicherweise evtl. sein das ein ,,falsches" Attribut im Inverter ausgelesen wird und dieses im Inverter um 0:00 Uhr auf 0 gesetzt wird.
Zitat
2024.04.21 00:00:04 1: PVVorschau - WARNING - The Total Energy from Inverter 'SMATripower6' is lower than the value saved before. This situation is invalid and the Energy generated of current hour is set to '0'.
Das wäre bei einem Total-Zähler nicht richtig, denn der sollte auf Gedeih und Verderb immer weiter ,,rauf" zählen und sich nicht zurück auf 0 setzen!?! ;)
Stimmt. Ist wirklich komisch betrachtet.
Ich ging von dem Tages PV Zähler (Total) aus. Und der muss reseten im Inverter.
Der Absolute überalles Total den man benötigt wird auch nicht zurückgesetzt. Das macht ja wirklich keinen Sinn.
Zitat von: kask am 23 April 2024, 07:14:48Wo ist den dein Problemchen? Das eine Warnung kommt?
Ja genau, mein Logfile wird täglich nachts zwischen 00:00 - 00:59 mit hunderten Meldungen geflutet, was es bis zum Update vorige Woche nicht gab:
Zitat2024.04.25 00:00:04 1: PVVorschau - WARNING - The Total Energy from Inverter 'SMATripower6' is lower than the value saved before. This situation is invalid and the Energy generated of current hour is set to '0'.
Ich habe auch noch ein zweites Device vom Type "SMAInverter" am laufen - hierbei gibts allerdings keinerlei Fehlermeldungen seitens SolareForecast. Das Device "SMATripower6" sieht so aus:
defmod SMATripower6 SMAInverter crypt:3........810 192.168.178.154
attr SMATripower6 detail-level 0
attr SMATripower6 event-on-change-reading SPOT_PACTOT:40,PV_Gesamterzeugung:50,.*
attr SMATripower6 interval 10
attr SMATripower6 mode automatic
attr SMATripower6 room Photovoltaik
attr SMATripower6 target-serial 301........7
attr SMATripower6 target-susyid 378
attr SMATripower6 userReadings PV_Gesamterzeugung {ReadingsVal("SMATripower6","SPOT_PACTOT",0) + ReadingsVal("SMATripower5","SPOT_PACTOT",0)},\
PV_Gesamtertrag {ReadingsVal("SMATripower6","SPOT_ETODAY",0) + ReadingsVal("SMATripower5","SPOT_ETODAY",0)},\
PV_SPOT_ETOTAL_Gesamt {ReadingsVal("SMATripower6","SPOT_ETOTAL",0) + ReadingsVal("SMATripower5","SPOT_ETOTAL",0)},
attr SMATripower6 verbose 1
setstate SMATripower6 2254
setstate SMATripower6 2023-03-02 00:09:54 .bat_loadtotal_yesterday 0
setstate SMATripower6 2024-04-25 00:00:00 .etotal_yesterday 11587491
setstate SMATripower6 2024-04-25 00:00:00 .yesterday 25
setstate SMATripower6 2024-04-24 23:59:00 PVErtragDay 28.16
setstate SMATripower6 2024-04-25 17:35:45 PV_Gesamtertrag 23666
setstate SMATripower6 2024-04-25 17:35:45 PV_Gesamterzeugung 3073
setstate SMATripower6 2024-04-25 17:35:45 PV_SPOT_ETOTAL_Gesamt 17257960
setstate SMATripower6 2024-04-25 17:35:45 SPOT_ETODAY 11924
setstate SMATripower6 2024-04-25 17:35:45 SPOT_ETOTAL 11599416
setstate SMATripower6 2024-04-25 17:35:45 SPOT_PAC1 751
setstate SMATripower6 2024-04-25 17:35:45 SPOT_PAC2 749
setstate SMATripower6 2024-04-25 17:35:45 SPOT_PAC3 754
setstate SMATripower6 2024-04-25 17:35:45 SPOT_PACTOT 2254
setstate SMATripower6 2024-04-25 17:35:45 SPOT_PDC 2259
setstate SMATripower6 2024-04-25 17:35:45 SPOT_PDC1 1360
setstate SMATripower6 2024-04-25 17:35:45 SPOT_PDC2 987
setstate SMATripower6 2024-04-25 17:35:45 avg_power_lastminutes_05 2535
setstate SMATripower6 2024-04-25 17:35:45 avg_power_lastminutes_10 2115
setstate SMATripower6 2024-04-25 17:35:45 avg_power_lastminutes_15 1759
setstate SMATripower6 2024-04-25 17:35:45 modulstate normal
setstate SMATripower6 2024-04-25 17:35:45 opertime_start 25.04.2024 05:33:42
setstate SMATripower6 2024-04-25 17:35:45 opertime_stop 25.04.2024 21:20:16
setstate SMATripower6 2024-04-25 17:35:45 state 2254
Zeig bitte auch noch deinen Eintrag im SF vom Setting des "currentInverterDev"
Bei mir steht z.B. dort ein Summendummy (Ermittelt die Summe Aller Zähler =>> für alle WR !!!)
Ähnlich wie bei Dir
InverterDummy pv=total_pac:kW etotal=etotal:kWh capacity=9500
Gruß
300P
Nachfolgend aufgezeigter consumer01 schaltet sich zum Sonnenuntergang aus. Meine Erwartung wäre aber, dass er durch das "notafter=18" um 18:00 Uhr abgeschaltet wird.
attr SolarForecast consumer01 HM_ES_PMSw1_Pl_PEQ0411718 type=heater mintime=SunPath power=0 mode=must on="on" off="off" pcurr=2.POWER icon=scene_sleeping_alternat notbefore=10 notafter=18 auto=Automatiksteuerung etotal=2.ENERGY_COUNTER:Wh
Habe ich etwas falsch konfiguriert?
Beste Grüße!
Zitat von: 300P am 25 April 2024, 18:15:06Zeig bitte auch noch deinen Eintrag im SF vom Setting des "currentInverterDev"
Bei mir steht z.B. dort ein Summendummy (Ermittelt die Summe Aller Zähler =>> für alle WR !!!)
Ähnlich wie bei Dir
InverterDummy pv=total_pac:kW etotal=etotal:kWh capacity=9500
Gruß
300P
ZitatcurrentInverterDev
SMATripower6 pv=PV_Gesamterzeugung:W etotal=PV_Gesamtertrag:Wh capacity=12260
Das ist seit Ewigkeiten unberührt...
Weil es mal ging heißt es ja nicht das es gut war ;)
SMATripower6 pv=PV_Gesamterzeugung:W etotal=PV_Gesamtertrag:Wh capacity=12260
In deiner definition steht aber bei PV_Gesamtertrag, was im currentInverterDev aber als totaler Gesamtzähler einzugegeben ist, der totale Tageszähler drin.
PV_Gesamtertrag {ReadingsVal("SMATripower6","SPOT_ETODAY",0) + ReadingsVal("SMATripower5","SPOT_ETODAY",0)},
Sicher das es nicht so sein sollte?.
SMATripower6 pv=PV_Gesamterzeugung:W etotal=PV_SPOT_ETOTAL_Gesamt:Wh capacity=12260
Habe selber kein SMA. Habe ein bischen hier im Forum gestöbert und würde sagen das es mir richtiger erscheint.
würde ich auch so sehen....
ihr habt recht.... :-[
Wobei laut Doku:
ZitatcurrentInverterDev <Inverter Device Name> pv=<Readingname>:<Einheit> etotal=<Readingname>:<Einheit> [capacity=<max. WR-Leistung>]
Legt ein beliebiges Device und dessen Readings zur Lieferung der aktuellen PV Erzeugungswerte fest. Es kann auch ein Dummy Device mit entsprechenden Readings sein. Die Werte mehrerer Inverterdevices führt man z.B. in einem Dummy Device zusammen und gibt dieses Device mit den entsprechenden Readings an.
Die Angabe von capacity ist optional, wird aber zur Optimierung der Vorhersagegenauigkeit dringend empfohlen.
pv Reading welches die aktuelle PV-Erzeugung liefert
etotal Reading welches die gesamte erzeugte PV-Energie liefert (ein stetig aufsteigender Zähler)
Einheit die jeweilige Einheit (W,kW,Wh,kWh)
capacity Bemessungsleistung des Wechselrichters gemäß Datenblatt, d.h. max. möglicher Output in Watt
(Die Angabe ist optional, wird aber dringend empfohlen zu setzen)
Beispiel:
set <name> currentInverterDev STP5000 pv=total_pac:kW etotal=etotal:kWh capacity=5000
# Device STP5000 liefert PV-Werte. Die aktuell erzeugte Leistung im Reading "total_pac" (kW) und die tägliche Erzeugung im Reading "etotal" (kWh). Die max. Leistung des Wechselrichters beträgt 5000 Watt.
da wäre der totale Tageszähler anzugeben und nicht der totale Zähler über die gesamte Laufzeit...
...Kopfkratz...
... komisch, dass dies über die letzten fast 2 Jahre gar nicht aufgefallen war bei mir
edit:
wurde hier auch schon diskutiert. Habe es mal wie von Euch vorgeschlagen geändert & werde beobachten.
https://forum.fhem.de/index.php?topic=137058.msg1311220#msg1311220
Hi,
ich habe eine Frage zum Wiki. Dort steht zum Schlüssel "auto" im "Beispiel Registrierung eines Shelly Devices":
ZitatIst das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Das passiert bei meiner Consumer Definition des Consumers aber ncht:
attr Forecast consumer01 SP.LaderHolger type=charger power=200 icon=electric_car_charger mintime=SunPath on=on off=off etotal=energy:Wh pcurr=power:W mode=can auto=automatic
Im Shelly Device SP.LaderHolger habe ich kein Reading "automatic".
Ist das Wiki da nicht mehr aktuell oder habe ich da etwas falsch verstanden?
Liebe Grüße
Holger
Selbst keine Ahnung.
Aber hast du mal das Reading von Hand angelegt und geguckt ob das dann funktioniert?
Ich hab ein Problem.
Ich bin momentan mein System am optimieren. Dazu versuche ich unteranderem die events zu reduzieren.
Jetzt habe ich folgende event-on-change regel angelegt bei meinen SolarForecast modulen.
attr Forecast.* event-on-change-reading Today_MaxPVforecastTime,Today_PVdeviation:0.3,RestOfDay.*:50,T.*_PVforecast:50,Today_.*PV.*:50,Next.*cast:75,.*Tomorrow.*:50,statistic_.*Till.*:50
ich habe 7 Module laufen mit verschiedenen API's.
Forecast
ForecastDWD
ForecastOpenMeteo
ForecastOpenMeteoEnsemble
ForecastOpenMeteoWorld
ForecastSolarAPI
VictronVRM
Und mit der event-on-change regel oben bekomme ich massiven CPU Load.
Der Trend im Bild zeigt das ich am ende wieder ein "event-on-change-reading .*" gesetzt habe und damit geht der load wieder runter.
Und jetzt die entscheidende Frage: Warum?
Kann mir das einer erklären?
Zudem würde ich gerne wissen ob man das geschwätzige Modul etwas ruhiger stimmen kann und wenn wie.
Bei mir sind es sicherlich mehr als 400 definierte "Device" in der fhem.cfg und das FHEM läuft auf einem RPI4 (wird gebootet auf einer SSD).
Die zugehörige MARIA Datenbank ist extern auf auf einer QNAP.
=>> da wird man dann schon sensibel für den Datenwust und die anfallenden zugehörigen Events.
Hier mein Vorschlag:
Das wäre meiner Ansicht nach deine Freund zum reduzieren bei den Events. (also nur bei Datenänderung)
attr ForecastXYXYXYXYXYX event-on-change-reading .*
und dann noch dazu nehmen (wegen Logdatenmengen)....
attr ForecastXYXYXYXYXYX DbLogExclude .*
danach aber auch bitte danach nur die, die du auch "wirklich und lebenswichtig" immer wieder benötigst, mit "DbLogInclude" wieder reinnehmen.
(Bei mir sind das z.B. "0" geloggte Datensätze - und seit mehr als 2 Jahren für SF im DBLog)
Gruß
300P
hmm, ich bin mir nicht sicher ob du das gelesen hast was ich geschrieben hatte.
Ich hatte bereits den regex .*, nun wollte ich weiter reduzieren bzw. besser filtern um die Datenmenge zu reduzieren.
Das Resultat ist das es weniger events werden aber die CPU load jetzt massiv ansteigt dadurch.
Ich loge auch garnichts von den Modulen selbst mit.
Ich habe auch einen Raspberry Pi mit knappen 600 Devices. Und so langsam komme ich an Grenzen.
Deshalb die geplannte optimierung.
Vergesst was ich geschrieben hatte. Ich habe hier andere Probleme.
Der regex funktioniert jetzt ohne andere Änderungen.
Ich hatte vor kurzem das problem das wenn ich meine 99_myutis.pm geändert hatte das dann mein RAM kontinuierlich anstieg.
Ziemlich schnell sogar. Das hatte erste einmal gedauert bis ich das herausgefunden hatte.
Im Zuge dessen habe ich dann mein Datenaufkommen reduziert weil der load sehr, sehr oft über 1 lag (wir reden hier vom 1/4h load). So das das RAM-Leak Problem nicht mehr auftratt.
Den Grund kenne ich bis heute nicht.
Jetzt hatte ich weiter optimiert und als ich bei den weniger gesprächigen Modulen ankam. Hatte ich das oben genannte Problem.
Änderung rückgängiggemacht und der Load sank wieder. Aktiviert und er stieg. Fhem neu gestartet das gleiche verhalten.
Dann hier im Thread gefragt.
Dann weiter probiert, aber der Load ging nie soweit runter wie ich Ihn vor der Event optimierung des Moduls hatte.
Jetzt habe ich letzendlich einen Reboot des ganzen Systems gemacht und der Load ist da wo er zuvor war und scheinbar stabil.
Mit ctrlInterval kann man den Interval der aktualisierung einstellen und damit auch das event aufkommen. Das hatte ich früher mal ziemlich tief gesetzt damit der flowchart öfter aktualisiert wurde. Jetzt sind aber in der Zwischenzeit weieter API's dazugekommen und ich habe diese immer mit RAW definition erstellt und somit auch immer den "schnellen" Interval mit geschlört. So das alle Module schön im 15sec Takt Daten aufbearbeitet hatten.
Also weiter suchen wo es be mir klemmt. Das Modul ist es jedenfalls nicht. Sehr dubios alles hier.
Ich habe zwei Vorschläge für das Modul.
1.
Ich habe mehrere Module aktiv. Könnte man nicht wenn ctrlInterval aktiv ist den ersten interval randomized in die zeit zwischen modul start und ctrlInterval value legen? Die Module laufen bei gleichem ctrlInterval bei mir ziemlich konstant gleich. Ich habe das behoben in dem ich allen unterscheidliche werte gegeben habe. Zum start sind sie syncron dann laufen die auseinander und dann nähern diese sich wieder. istnicht schick. schöner wäre es randomized zu machen dann hatte man immer mehr zeit zwischen den einzelnen modulen. Oder eventuell eine delay zeit vorgeben zu können wäre auch ok eventuell sogar besser. Das der erste Aufruf nach zeit x erst passiert. Somit könnte man das dann noch gesteuert timen.
2.
Könnte man in das Balkendiagramm nicht auch die Forcastconsumption einfliessen lassen. Jetzige Balken nur halb so breit und der consumption Forecast mit rein. Ist vieleicht etwas tricky mit den Zahlenwerten (eventuell vertikal anordnen dann?) ;). Fände ich schick den vermutliche Verbrauch auch zu sehen.
Wie wäre es so:
Die SF die dir am "Herzen" liegt und treffsicher für dich ist mit einem Interval einer niedrigen Primzahl versehen.
(Primzahlen bis 100 lauten: 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97.)
Die anderen dann mit weit höheren Primzahlen im Hunderterbereich ;)
Damit sollte es grundsätzlich weniger gleichzeitig startende Läufe der diversen SF geben.
Gruß
300P
Die Primzahl Theorie ist ja ganz schick..aber 3,5,7,11 x prim ist nun mal nix mehr prim.
Da kann ich auch 80,81,87 nehmen. Die Zahlen werden immer zusammen laufen und wieder auseinander gehen. Mit Primzahlen halt etwas gestreckt.
Aber nicht annähernd nie wie es ein Offset machen würde.
Das wird sich nie ändern. Mit einem Offset würden diese das auch machen. Aber nach einer größeren Zeit weil die Aufrufe Differenzen haben werden. Auch wenn es nur ms sind. Das mit unterschiedlichen Intervalen ist immer Käse (sofern nicht + Zufallszahl im jeden Call, und das will der eine vieleicht nicht damit würde die Glechmässigkeit fehlen).
Mit festen Werten ist immer eine Kontinuität im Spiel. Alles nur ein Frage der Zeit bis sich wieder welche treffen. Und bei dreien werden sich 2 immer schneller treffen bei angenommen werten von 71, 73, 79. 5183 (1,43h), 5609(1,55h), 5767 (1,6h)
Spätestens nach der multiplization aller Intervalle Treffen diese sich wieder (409457 (4,73d). Die natürliche Aufruf Differenz mal ausseracht gelassen).
Ich weiß sind 4,73 Tage. Aber wenn richtig, dann auch wirklich richtig durchdacht und mit Verstand.
Und zwischen drinne werden sich so mehrere treffen (hier im Beipsiel max 2).
Wenn ich kleine Intervalle haben möchte, was ich eigentlich anstrebe, dann geht das ganze halt nur noch schneller. Primzahl hin oder her.
Vieleicht bau ich mir ein notify was mir eine Zufallszahl in den ctrlInterval auf meinen Intervall schreibt.
Oder ein do_if/notify was beim ersten call das Modul disabled und wieder enabled nach meinem Offset. Weiß nicht was die timer dann da machen. Ich hoffe reseten ;)
Das ist aber auch wieder Overhead. Wollte ich eigentlich loswerden.
Ich bin für einen Offset;) Ich brauch einen Offset für den ersten intervall call ;)
Hallo kask,
mal abgesehen davon, dass deine SF Devices immer von den dahinter liegenden Werten abhängig sind. Was genau ist der Sinn von mehreren zeitlich versetzten SF Devices?
Mein Hauptanliegen liegt bei dem Consumptionwerten hierbei.
Nicht die PV Forecast Werte.
Da ist eine schnelle Abfrage nicht nötig.
Dafür sind mehrere Devices nicht wirklich nötig. So wie bisher festgestellt.
Ich bilde mir aus (fast) allen SF's z.B. auch Werte. Und der Durschnitt aller Devices liegt meist am nächsten zum wirklichen Ertrag.
Klar kann es passieren das einzelne SF's genauer sind.
Aber gerade bei unbeständigem Wetter ist es so immer genauer und bei gutem Wetter ist die Abweichung vernachlässigbar zu dem besseren SF's.
Für mich und meine Anlage ist der Durchschnittswert mein Favorit.
Deshalb habe ich nicht "die" API die am besten ist. Klar habe ich darunter Favoriten. Aber selbst die sind meist nicht genauer wie der Durschnitt aller.
Und bei mehreren Devices macht es halt auch Sinn diese Zeitversetzt durch zu takern. Sind ja nicht gerade die Resourcen schonensten Module mitunter.
Ich muss mal gucken wie ich das Umsetzte was ich mir da denke.
Vieleicht lass ich ein Modul öfter takern was die beste Aufrufverarbeitungszeit im Durchschnitt hat. VictronVRM vermutlich.
ForecastDWD CODE(0x559d502140) 364 6877772 561425.86 0.08 0.00 0.00 02.05. 00:28:23 HASH(ForecastDWD)
ForecastSolarAPI CODE(0x559d502140) 334 6877772 492662.48 0.07 0.00 0.00 02.05. 00:11:33 HASH(ForecastSolarAPI)
Forecast CODE(0x559d502140) 330 6877772 542474.85 0.08 0.00 0.00 02.05. 00:00:05 HASH(Forecast)
ForecastOpenMeteoEnsemble CODE(0x559d502140) 326 6877772 1075603.99 0.16 0.00 0.00 02.05. 00:00:04 HASH(ForecastOpenMeteoEnsemble)
ForecastOpenMeteoWorld CODE(0x559d502140) 313 6877772 530529.66 0.08 0.00 0.00 02.05. 00:00:04 HASH(ForecastOpenMeteoWorld)
ForecastOpenMeteo CODE(0x559d502140) 309 6877772 511606.73 0.07 0.00 0.00 02.05. 00:00:05 HASH(ForecastOpenMeteo)
ForecastVictronVRM CODE(0x559d502140) 290 6877772 499226.55 0.07 0.00 0.00 02.05. 00:00:05 HASH(ForecastVictronVRM)
Und die anderen tacker ich in einem sehr großem Interval durch. Ich muss mal gucken.
Zitat von: kask am 01 Mai 2024, 16:20:12Ich bin für einen Offset;) Ich brauch einen Offset für den ersten intervall call ;)
Oder sowas wie "alignTime". Damit könnte der Start versetzt stattfinden.
Zitat von: kask am 02 Mai 2024, 01:53:22Mein Hauptanliegen liegt bei dem Consumptionwerten hierbei.
Nicht die PV Forecast Werte.
Da ist eine schnelle Abfrage nicht nötig.
Dafür sind mehrere Devices nicht wirklich nötig. So wie bisher festgestellt.
Ich bilde mir aus (fast) allen SF's z.B. auch Werte. Und der Durschnitt aller Devices liegt meist am nächsten zum wirklichen Ertrag.
Klar kann es passieren das einzelne SF's genauer sind.
Aber gerade bei unbeständigem Wetter ist es so immer genauer und bei gutem Wetter ist die Abweichung vernachlässigbar zu dem besseren SF's.
Für mich und meine Anlage ist der Durchschnittswert mein Favorit.
Deshalb habe ich nicht "die" API die am besten ist. Klar habe ich darunter Favoriten. Aber selbst die sind meist nicht genauer wie der Durschnitt aller.
Und bei mehreren Devices macht es halt auch Sinn diese Zeitversetzt durch zu takern. Sind ja nicht gerade die Resourcen schonensten Module mitunter.
Ich muss mal gucken wie ich das Umsetzte was ich mir da denke.
Vieleicht lass ich ein Modul öfter takern was die beste Aufrufverarbeitungszeit im Durchschnitt hat. VictronVRM vermutlich.
ForecastDWD CODE(0x559d502140) 364 6877772 561425.86 0.08 0.00 0.00 02.05. 00:28:23 HASH(ForecastDWD)
ForecastSolarAPI CODE(0x559d502140) 334 6877772 492662.48 0.07 0.00 0.00 02.05. 00:11:33 HASH(ForecastSolarAPI)
Forecast CODE(0x559d502140) 330 6877772 542474.85 0.08 0.00 0.00 02.05. 00:00:05 HASH(Forecast)
ForecastOpenMeteoEnsemble CODE(0x559d502140) 326 6877772 1075603.99 0.16 0.00 0.00 02.05. 00:00:04 HASH(ForecastOpenMeteoEnsemble)
ForecastOpenMeteoWorld CODE(0x559d502140) 313 6877772 530529.66 0.08 0.00 0.00 02.05. 00:00:04 HASH(ForecastOpenMeteoWorld)
ForecastOpenMeteo CODE(0x559d502140) 309 6877772 511606.73 0.07 0.00 0.00 02.05. 00:00:05 HASH(ForecastOpenMeteo)
ForecastVictronVRM CODE(0x559d502140) 290 6877772 499226.55 0.07 0.00 0.00 02.05. 00:00:05 HASH(ForecastVictronVRM)
Und die anderen tacker ich in einem sehr großem Interval durch. Ich muss mal gucken.
Dann setzt doch alle auf Intervall manuell und starte sie selbst zeitgesteuert über at oder Notify oder was dir am Besten passt.
Jepp, darauf wird es hinauslaufen.
Da im Interval vor&nach jeder vollen Stunde die Daten immer aufgearbeitet werden (laut Hilfe).
Zudem habe ich ein bischen mit den ctrlInterval rumexperimentiert und der Wert des Intervals wird erst aktualisiert wenn der Interval abgelaufen ist.
Disablen oder den ctrlInterval auf 0 setzen funktioniert da auch nicht zur manipulation das der Intervaltimer reseted wird.
Ist vermutlich auch garnich so einfach zu implementieren, aber keine Ahnung.
Deshalb bin ich auch schon an dem Punkt die Datenaufarbeitung selbst anzutriggern.
Ich habe das mal umgesetzt. Mal beobachten.
defmod ATSolarForecastLoop at +*00:00:10 \
{\
my $idx = ReadingsNum($SELF,'idx',0);;\
#my @fcs = defInfo('TYPE=SolarForecast','NAME');;\
my @fcs = ("Forecast","ForecastDWD","ForecastOpenMeteo","ForecastOpenMeteoEnsemble","ForecastOpenMeteoWorld","ForecastSolarAPI","ForecastVictronVRM");;\
$idx = ($idx >= (@fcs-1))?0:($idx += 1);;\
\
my $sftimer = "at.".$fcs[$idx].".getdata.timer";;\
fhem("delete ".$sftimer );; \
fhem("define ".$sftimer ." at +00:00:01 get ".$fcs[$idx]." data");;\
fhem("attr ".$sftimer ." room AT");;\
\
fhem("setreading $SELF idx $idx");;\
fhem("setreading $SELF fc $fcs[$idx]");;\
}
attr ATSolarForecastLoop DbLogExclude .*
attr ATSolarForecastLoop room AT
2024-05-02 16:31:29.338 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 5003 Wh
2024-05-02 16:31:39.281 SolarForecast Forecast NextHours_Sum02_PVforecast: 5658 Wh
2024-05-02 16:31:39.281 SolarForecast Forecast RestOfDayPVforecast: 7343 Wh
2024-05-02 16:31:49.246 SolarForecast ForecastDWD RestOfDayPVforecast: 5846 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo Today_Hour17_PVreal: 1000 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo Today_PVreal: 56019 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo NextHours_Sum01_PVforecast: 1974 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo NextHours_Sum02_PVforecast: 2514 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo NextHours_Sum03_PVforecast: 2951 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo NextHours_Sum04_PVforecast: 3090 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo RestOfDayPVforecast: 3132 Wh
2024-05-02 16:31:59.332 SolarForecast ForecastOpenMeteo RestOfDayConsumptionForecast: 7630 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble Today_Hour17_PVreal: 1000 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble Today_PVreal: 56019 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum01_PVforecast: 2609 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum02_PVforecast: 3560 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum03_PVforecast: 4008 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum04_PVforecast: 4212 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble RestOfDayPVforecast: 4262 Wh
2024-05-02 16:32:09.946 SolarForecast ForecastOpenMeteoEnsemble RestOfDayConsumptionForecast: 7604 Wh
2024-05-02 16:32:20.251 SolarForecast ForecastOpenMeteoWorld RestOfDayPVforecast: 3068 Wh
2024-05-02 16:32:29.241 SolarForecast ForecastSolarAPI NextHours_Sum03_PVforecast: 4692 Wh
2024-05-02 16:32:29.241 SolarForecast ForecastSolarAPI NextHours_Sum04_PVforecast: 4785 Wh
2024-05-02 16:32:29.241 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 4785 Wh
2024-05-02 16:32:29.241 SolarForecast ForecastSolarAPI Today_PVdeviation: -37.12 %
2024-05-02 16:32:39.445 SolarForecast ForecastVictronVRM NextHours_Sum04_PVforecast: 4931 Wh
2024-05-02 16:32:39.445 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 4946 Wh
2024-05-02 16:32:39.445 SolarForecast ForecastVictronVRM RestOfDayConsumptionForecast: 7392 Wh
2024-05-02 16:32:49.145 SolarForecast Forecast Today_Hour17_PVreal: 1010 Wh
2024-05-02 16:32:49.145 SolarForecast Forecast Today_PVreal: 56080 Wh
2024-05-02 16:32:49.145 SolarForecast Forecast RestOfDayPVforecast: 7293 Wh
2024-05-02 16:32:49.145 SolarForecast Forecast RestOfDayConsumptionForecast: 7427 Wh
Edit: Das funktioniert nicht. Dafür ist das Modul nicht gemacht. Das Forecast mit der DWD-API produziert dann massiv load. Alle brauchen mehr load als wenn diese im Interval laufen.
Jetzt schein ich es zu haben. Beim setzen von ctrlInterval 0 auf x erzeugen die Module auch massiv Load. Vermutlich laden die erstmal Daten (ich hab mir das debuggen mal gespart und lebe mit der Vermutung).
Alle 17 sec. soll ein Aufruf eines SF kommen.
Diese werden nacheinander gestartet mit SFSetInterval(17). dauert einwenig aber schein so erst einmal zu gehen.
sub sectotimertime($) {
# 21 = 00:00:21, 361 = 00:06:01 , 5361 = 01:29:21
my ($t) = @_;
$t = sprintf("%02d:%02d:%02d", $t/3600, ($t%3600)/60, $t%60);
return $t;
}
sub SFSetInterval($) {
my ($delay) = @_;
my @fcs = defInfo('TYPE=SolarForecast','NAME');
my $interval = ($delay * @fcs);
my $sftimer = "";
my $dtime = 10;
my $addittionaldelay = 0;
foreach my $fc (@fcs) {
$sftimer = "at.".$fc.".setinterval";
fhem("delete ".$sftimer );
$dtime += ($delay + $addittionaldelay);
$addittionaldelay = $interval;
fhem("define ".$sftimer ." at +".sectotimertime($dtime)." attr ".$fc." ctrlInterval ".$interval);
}
return @fcs.'/'.$interval
}
Und am Ende sind sie ziemlich 17sec auseinander
2024-05-02 18:43:41.611 SolarForecast Forecast RestOfDayPVforecast: 238 Wh
2024-05-02 18:43:41.611 SolarForecast Forecast RestOfDayConsumptionForecast: 4655 Wh
2024-05-02 18:43:41.611 SolarForecast Forecast statistic_conForecastTillNextSunrise: 8322 Wh
2024-05-02 18:45:13.939 SolarForecast Forecast NextHours_Sum03_PVforecast: 228 Wh
2024-05-02 18:45:13.939 SolarForecast Forecast NextHours_Sum04_PVforecast: 228 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD NextHours_Sum01_PVforecast: 778 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD NextHours_Sum02_PVforecast: 947 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD NextHours_Sum03_PVforecast: 959 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD NextHours_Sum04_PVforecast: 959 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD RestOfDayPVforecast: 959 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD Tomorrow_PVforecast: 20918 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD Today_PVforecast: 59400 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD NextHours_Sum04_ConsumptionForecast: 3905 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD RestOfDayConsumptionForecast: 4596 Wh
2024-05-02 18:45:25.192 SolarForecast ForecastDWD statistic_conForecastTillNextSunrise: 8255 Wh
2024-05-02 18:47:10.931 SolarForecast Forecast RestOfDayConsumptionForecast: 4569 Wh
2024-05-02 18:47:23.632 SolarForecast ForecastDWD RestOfDayPVforecast: 908 Wh
2024-05-02 18:47:23.632 SolarForecast ForecastDWD Today_PVdeviation: 3.75 %
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo NextHours_Sum01_PVforecast: 299 Wh
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo NextHours_Sum02_PVforecast: 410 Wh
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo NextHours_Sum03_PVforecast: 428 Wh
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo NextHours_Sum04_PVforecast: 428 Wh
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo RestOfDayPVforecast: 428 Wh
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo NextHours_Sum04_ConsumptionForecast: 3983 Wh
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo RestOfDayConsumptionForecast: 4668 Wh
2024-05-02 18:47:41.294 SolarForecast ForecastOpenMeteo statistic_conForecastTillNextSunrise: 9200 Wh
2024-05-02 18:49:08.555 SolarForecast Forecast NextHours_Sum04_ConsumptionForecast: 3879 Wh
2024-05-02 18:49:08.555 SolarForecast Forecast statistic_conForecastTillNextSunrise: 8255 Wh
2024-05-02 18:49:22.681 SolarForecast ForecastDWD RestOfDayPVforecast: 857 Wh
2024-05-02 18:49:22.681 SolarForecast ForecastDWD RestOfDayConsumptionForecast: 4511 Wh
2024-05-02 18:49:39.926 SolarForecast ForecastOpenMeteo RestOfDayPVforecast: 315 Wh
2024-05-02 18:49:39.926 SolarForecast ForecastOpenMeteo Tomorrow_PVforecast: 20190 Wh
2024-05-02 18:49:39.926 SolarForecast ForecastOpenMeteo Today_PVforecast: 62625 Wh
2024-05-02 18:49:39.926 SolarForecast ForecastOpenMeteo Today_PVdeviation: 9.68 %
2024-05-02 18:49:39.926 SolarForecast ForecastOpenMeteo statistic_dayAfterTomorrowPVforecast: 54763 Wh
2024-05-02 18:49:57.563 SolarForecast ForecastOpenMeteoEnsemble RestOfDayPVforecast: 167 Wh
2024-05-02 18:49:57.563 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum04_ConsumptionForecast: 4067 Wh
2024-05-02 18:49:57.563 SolarForecast ForecastOpenMeteoEnsemble RestOfDayConsumptionForecast: 4730 Wh
2024-05-02 18:49:57.563 SolarForecast ForecastOpenMeteoEnsemble statistic_conForecastTillNextSunrise: 9097 Wh
2024-05-02 18:51:06.300 SolarForecast Forecast NextHours_Sum02_PVforecast: 192 Wh
2024-05-02 18:51:06.300 SolarForecast Forecast RestOfDayConsumptionForecast: 4483 Wh
2024-05-02 18:51:21.729 SolarForecast ForecastDWD NextHours_Sum03_PVforecast: 806 Wh
2024-05-02 18:51:21.729 SolarForecast ForecastDWD NextHours_Sum04_PVforecast: 806 Wh
2024-05-02 18:51:21.729 SolarForecast ForecastDWD RestOfDayPVforecast: 806 Wh
2024-05-02 18:51:21.729 SolarForecast ForecastDWD statistic_conForecastTillNextSunrise: 8188 Wh
2024-05-02 18:51:38.917 SolarForecast ForecastOpenMeteo RestOfDayConsumptionForecast: 4579 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld NextHours_Sum01_PVforecast: 256 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld NextHours_Sum02_PVforecast: 358 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld NextHours_Sum03_PVforecast: 368 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld NextHours_Sum04_PVforecast: 368 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld RestOfDayPVforecast: 368 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld NextHours_Sum04_ConsumptionForecast: 3928 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld RestOfDayConsumptionForecast: 4558 Wh
2024-05-02 18:52:13.098 SolarForecast ForecastOpenMeteoWorld statistic_conForecastTillNextSunrise: 9159 Wh
2024-05-02 18:53:20.467 SolarForecast ForecastDWD NextHours_Sum02_PVforecast: 751 Wh
2024-05-02 18:53:20.467 SolarForecast ForecastDWD RestOfDayPVforecast: 756 Wh
2024-05-02 18:53:20.467 SolarForecast ForecastDWD RestOfDayConsumptionForecast: 4425 Wh
2024-05-02 18:53:37.864 SolarForecast ForecastOpenMeteo NextHours_Sum03_PVforecast: 267 Wh
2024-05-02 18:53:37.864 SolarForecast ForecastOpenMeteo NextHours_Sum04_PVforecast: 267 Wh
2024-05-02 18:53:37.864 SolarForecast ForecastOpenMeteo statistic_conForecastTillNextSunrise: 9131 Wh
2024-05-02 18:53:54.314 SolarForecast ForecastOpenMeteoEnsemble RestOfDayConsumptionForecast: 4644 Wh
2024-05-02 18:54:11.356 SolarForecast ForecastOpenMeteoWorld RestOfDayPVforecast: 255 Wh
2024-05-02 18:54:11.356 SolarForecast ForecastOpenMeteoWorld Tomorrow_PVforecast: 20150 Wh
2024-05-02 18:54:11.356 SolarForecast ForecastOpenMeteoWorld Today_PVforecast: 62625 Wh
2024-05-02 18:54:11.356 SolarForecast ForecastOpenMeteoWorld Today_PVdeviation: 9.67 %
2024-05-02 18:54:11.356 SolarForecast ForecastOpenMeteoWorld statistic_dayAfterTomorrowPVforecast: 54763 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI NextHours_Sum01_PVforecast: 459 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI NextHours_Sum02_PVforecast: 491 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI NextHours_Sum03_PVforecast: 491 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI NextHours_Sum04_PVforecast: 491 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 491 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI NextHours_Sum04_ConsumptionForecast: 3821 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI RestOfDayConsumptionForecast: 4409 Wh
2024-05-02 18:54:29.420 SolarForecast ForecastSolarAPI statistic_conForecastTillNextSunrise: 8175 Wh
2024-05-02 18:55:02.443 SolarForecast Forecast RestOfDayPVforecast: 179 Wh
2024-05-02 18:55:02.443 SolarForecast Forecast RestOfDayConsumptionForecast: 4397 Wh
2024-05-02 18:55:02.443 SolarForecast Forecast statistic_conForecastTillNextSunrise: 8187 Wh
2024-05-02 18:55:19.393 SolarForecast ForecastDWD NextHours_Sum01_PVforecast: 616 Wh
2024-05-02 18:55:19.393 SolarForecast ForecastDWD RestOfDayPVforecast: 705 Wh
2024-05-02 18:55:19.393 SolarForecast ForecastDWD Today_PVdeviation: 4.08 %
2024-05-02 18:55:36.269 SolarForecast ForecastOpenMeteo NextHours_Sum02_PVforecast: 242 Wh
2024-05-02 18:55:36.269 SolarForecast ForecastOpenMeteo RestOfDayPVforecast: 243 Wh
2024-05-02 18:55:36.269 SolarForecast ForecastOpenMeteo RestOfDayConsumptionForecast: 4489 Wh
2024-05-02 18:55:53.296 SolarForecast ForecastOpenMeteoEnsemble statistic_conForecastTillNextSunrise: 9029 Wh
2024-05-02 18:56:10.381 SolarForecast ForecastOpenMeteoWorld RestOfDayConsumptionForecast: 4468 Wh
2024-05-02 18:56:27.264 SolarForecast ForecastSolarAPI Tomorrow_PVforecast: 18529 Wh
2024-05-02 18:56:27.264 SolarForecast ForecastSolarAPI Today_PVdeviation: -24.33 %
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM NextHours_Sum01_PVforecast: 663 Wh
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM NextHours_Sum02_PVforecast: 832 Wh
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM NextHours_Sum03_PVforecast: 839 Wh
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM NextHours_Sum04_PVforecast: 839 Wh
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 839 Wh
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM NextHours_Sum04_ConsumptionForecast: 3792 Wh
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM RestOfDayConsumptionForecast: 4360 Wh
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM Today_PVdeviation: 7.31 %
2024-05-02 18:56:45.160 SolarForecast ForecastVictronVRM statistic_conForecastTillNextSunrise: 8127 Wh
2024-05-02 18:57:18.239 SolarForecast ForecastDWD NextHours_Sum03_PVforecast: 654 Wh
2024-05-02 18:57:18.239 SolarForecast ForecastDWD NextHours_Sum04_PVforecast: 654 Wh
2024-05-02 18:57:18.239 SolarForecast ForecastDWD RestOfDayPVforecast: 654 Wh
2024-05-02 18:57:18.239 SolarForecast ForecastDWD RestOfDayConsumptionForecast: 4340 Wh
2024-05-02 18:57:18.239 SolarForecast ForecastDWD statistic_conForecastTillNextSunrise: 8121 Wh
2024-05-02 18:57:52.084 SolarForecast ForecastOpenMeteoEnsemble RestOfDayConsumptionForecast: 4559 Wh
2024-05-02 18:58:09.165 SolarForecast ForecastOpenMeteoWorld NextHours_Sum02_PVforecast: 206 Wh
2024-05-02 18:58:09.165 SolarForecast ForecastOpenMeteoWorld NextHours_Sum03_PVforecast: 207 Wh
2024-05-02 18:58:09.165 SolarForecast ForecastOpenMeteoWorld NextHours_Sum04_PVforecast: 207 Wh
2024-05-02 18:58:09.165 SolarForecast ForecastOpenMeteoWorld statistic_conForecastTillNextSunrise: 9090 Wh
2024-05-02 18:58:26.171 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 405 Wh
2024-05-02 18:58:26.171 SolarForecast ForecastSolarAPI RestOfDayConsumptionForecast: 4323 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM Today_Hour20_PVforecast: 458 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM NextHours_Sum01_PVforecast: 470 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM NextHours_Sum02_PVforecast: 619 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM NextHours_Sum03_PVforecast: 621 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM NextHours_Sum04_PVforecast: 621 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 621 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM Tomorrow_PVforecast: 39203 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM Today_PVforecast: 61966 Wh
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM Today_PVdeviation: 8.25 %
2024-05-02 18:58:43.174 SolarForecast ForecastVictronVRM statistic_dayAfterTomorrowPVforecast: 40564 Wh
2024-05-02 18:59:00.108 SolarForecast Forecast RestOfDayConsumptionForecast: 4311 Wh
Auch hier wieder beobachten wie/ob diese auseinander laufen und ob ich diese eventuell manchmal gerade rücken muß.
Edit:
So sieht es nach ca. 11h Betrieb aus. Alles relativ syncron.
Das zeigt das der Timerinterval im Modul die neue Zeit anhand der geraden aktuellen Intervalzeit heranzieht. Das ist gut.
Ich hatte Sorge das der neue Interval, irgendwo ohen Zusammenhang, in dem Ablauf gesetzt wird. Das spricht auch dafür das der interne Timer sich nicht reseten läst, da dieser scheinbar sich selber sofort wieder neu antriggert.
DS_Starter weiß das ganz genau. Ich habe mir das angeschaut aber Perl ist so nicht wirklich meine Welt. Ein bischen geht aber was in dem Modul steht ist mir zu Komplex.
2024-05-03 07:20:00.151 SolarForecast ForecastOpenMeteoWorld NextHours_Sum04_PVforecast: 4250 Wh
2024-05-03 07:20:00.151 SolarForecast ForecastOpenMeteoWorld RestOfDayConsumptionForecast: 20318 Wh
2024-05-03 07:20:00.151 SolarForecast ForecastOpenMeteoWorld statistic_conForecastTillNextSunrise: 23461 Wh
2024-05-03 07:20:19.131 SolarForecast ForecastSolarAPI NextHours_Sum04_PVforecast: 6895 Wh
2024-05-03 07:20:19.131 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 23581 Wh
2024-05-03 07:20:19.131 SolarForecast ForecastSolarAPI RestOfDayConsumptionForecast: 19883 Wh
2024-05-03 07:20:19.131 SolarForecast ForecastSolarAPI statistic_conForecastTillNextSunrise: 23040 Wh
2024-05-03 07:20:36.209 SolarForecast ForecastVictronVRM NextHours_Sum01_PVforecast: 1830 Wh
2024-05-03 07:20:36.209 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 38199 Wh
2024-05-03 07:20:36.209 SolarForecast ForecastVictronVRM RestOfDayConsumptionForecast: 19780 Wh
2024-05-03 07:20:36.209 SolarForecast ForecastVictronVRM statistic_conForecastTillNextSunrise: 22929 Wh
2024-05-03 07:20:55.160 SolarForecast Forecast statistic_conForecastTillNextSunrise: 23080 Wh
2024-05-03 07:21:09.204 SolarForecast ForecastDWD NextHours_Sum04_PVforecast: 3011 Wh
2024-05-03 07:21:09.204 SolarForecast ForecastDWD RestOfDayConsumptionForecast: 19810 Wh
2024-05-03 07:21:27.107 SolarForecast ForecastOpenMeteo NextHours_Sum02_PVforecast: 963 Wh
2024-05-03 07:21:27.107 SolarForecast ForecastOpenMeteo RestOfDayConsumptionForecast: 20300 Wh
2024-05-03 07:21:43.130 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum04_PVforecast: 4721 Wh
2024-05-03 07:21:43.130 SolarForecast ForecastOpenMeteoEnsemble RestOfDayConsumptionForecast: 20137 Wh
2024-05-03 07:21:59.151 SolarForecast ForecastOpenMeteoWorld NextHours_Sum02_PVforecast: 958 Wh
2024-05-03 07:22:18.097 SolarForecast ForecastSolarAPI NextHours_Sum03_PVforecast: 4284 Wh
2024-05-03 07:22:18.097 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 23510 Wh
2024-05-03 07:22:35.101 SolarForecast ForecastVictronVRM NextHours_Sum02_PVforecast: 3893 Wh
2024-05-03 07:22:35.101 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 38123 Wh
2024-05-03 07:22:54.426 SolarForecast Forecast RestOfDayConsumptionForecast: 19886 Wh
2024-05-03 07:23:08.203 SolarForecast ForecastDWD RestOfDayPVforecast: 19864 Wh
2024-05-03 07:23:08.203 SolarForecast ForecastDWD statistic_conForecastTillNextSunrise: 22937 Wh
2024-05-03 07:23:26.151 SolarForecast ForecastOpenMeteo NextHours_Sum03_PVforecast: 2400 Wh
2024-05-03 07:23:26.151 SolarForecast ForecastOpenMeteo NextHours_Sum04_PVforecast: 4376 Wh
2024-05-03 07:23:26.151 SolarForecast ForecastOpenMeteo statistic_conForecastTillNextSunrise: 23397 Wh
2024-05-03 07:23:42.140 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum03_PVforecast: 2639 Wh
2024-05-03 07:23:42.140 SolarForecast ForecastOpenMeteoEnsemble statistic_conForecastTillNextSunrise: 23127 Wh
2024-05-03 07:23:58.173 SolarForecast ForecastOpenMeteoWorld NextHours_Sum03_PVforecast: 2387 Wh
2024-05-03 07:23:58.173 SolarForecast ForecastOpenMeteoWorld statistic_conForecastTillNextSunrise: 23395 Wh
2024-05-03 07:24:17.130 SolarForecast ForecastSolarAPI NextHours_Sum01_PVforecast: 1544 Wh
2024-05-03 07:24:17.130 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 23439 Wh
2024-05-03 07:24:17.130 SolarForecast ForecastSolarAPI RestOfDayConsumptionForecast: 19825 Wh
2024-05-03 07:24:17.130 SolarForecast ForecastSolarAPI statistic_conForecastTillNextSunrise: 22976 Wh
2024-05-03 07:24:34.156 SolarForecast ForecastVictronVRM NextHours_Sum04_PVforecast: 10683 Wh
2024-05-03 07:24:34.156 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 38048 Wh
2024-05-03 07:24:34.156 SolarForecast ForecastVictronVRM RestOfDayConsumptionForecast: 19722 Wh
2024-05-03 07:24:34.156 SolarForecast ForecastVictronVRM statistic_conForecastTillNextSunrise: 22865 Wh
2024-05-03 07:24:53.173 SolarForecast Forecast NextHours_Sum03_PVforecast: 1557 Wh
2024-05-03 07:24:53.173 SolarForecast Forecast NextHours_Sum04_PVforecast: 2613 Wh
2024-05-03 07:24:53.173 SolarForecast Forecast statistic_conForecastTillNextSunrise: 23015 Wh
2024-05-03 07:25:07.196 SolarForecast ForecastDWD RestOfDayConsumptionForecast: 19753 Wh
2024-05-03 07:25:25.179 SolarForecast ForecastOpenMeteo RestOfDayConsumptionForecast: 20243 Wh
2024-05-03 07:25:41.172 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum02_PVforecast: 1077 Wh
2024-05-03 07:25:41.172 SolarForecast ForecastOpenMeteoEnsemble NextHours_Sum04_PVforecast: 4872 Wh
2024-05-03 07:25:41.172 SolarForecast ForecastOpenMeteoEnsemble RestOfDayConsumptionForecast: 20083 Wh
2024-05-03 07:25:57.133 SolarForecast ForecastOpenMeteoWorld NextHours_Sum04_PVforecast: 4439 Wh
2024-05-03 07:25:57.133 SolarForecast ForecastOpenMeteoWorld RestOfDayConsumptionForecast: 20246 Wh
2024-05-03 07:26:16.149 SolarForecast ForecastSolarAPI NextHours_Sum02_PVforecast: 2478 Wh
2024-05-03 07:26:16.149 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 23369 Wh
2024-05-03 07:26:33.143 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 37972 Wh
2024-05-03 07:26:52.686 SolarForecast Forecast RestOfDayConsumptionForecast: 19828 Wh
2024-05-03 07:27:06.157 SolarForecast ForecastDWD statistic_conForecastTillNextSunrise: 22872 Wh
2024-05-03 07:27:24.121 SolarForecast ForecastOpenMeteo NextHours_Sum04_PVforecast: 4527 Wh
2024-05-03 07:27:24.121 SolarForecast ForecastOpenMeteo statistic_conForecastTillNextSunrise: 23331 Wh
2024-05-03 07:27:40.150 SolarForecast ForecastOpenMeteoEnsemble statistic_conForecastTillNextSunrise: 23062 Wh
2024-05-03 07:27:56.170 SolarForecast ForecastOpenMeteoWorld statistic_conForecastTillNextSunrise: 23329 Wh
2024-05-03 07:28:15.191 SolarForecast ForecastSolarAPI RestOfDayPVforecast: 23298 Wh
2024-05-03 07:28:15.191 SolarForecast ForecastSolarAPI RestOfDayConsumptionForecast: 19768 Wh
2024-05-03 07:28:15.191 SolarForecast ForecastSolarAPI statistic_conForecastTillNextSunrise: 22912 Wh
2024-05-03 07:28:32.166 SolarForecast ForecastVictronVRM NextHours_Sum01_PVforecast: 1663 Wh
2024-05-03 07:28:32.166 SolarForecast ForecastVictronVRM NextHours_Sum02_PVforecast: 4052 Wh
2024-05-03 07:28:32.166 SolarForecast ForecastVictronVRM RestOfDayPVforecast: 37896 Wh
2024-05-03 07:28:32.166 SolarForecast ForecastVictronVRM RestOfDayConsumptionForecast: 19665 Wh
2024-05-03 07:28:32.166 SolarForecast ForecastVictronVRM statistic_conForecastTillNextSunrise: 22801 Wh
2024-05-03 07:28:51.232 SolarForecast Forecast NextHours_Sum01_PVforecast: 397 Wh
2024-05-03 07:28:51.232 SolarForecast Forecast statistic_conForecastTillNextSunrise: 22951 Wh
Zudem habe ich in der Zwischenzeit meine Syncronisations sub etwas aufpoliert. Wenn die Timer auseinander laufen sollten.
Könnte ich jetzt einfach die Sub neu antriggern und die Modulen würden abgeschaltet werden, Die internen Timer würde überlaufen und dann würden die Module wieder eins nach dem anderen aktiviert werden. So könnte ich dann auch meinen Interval anpassen ohne große Einschränkungen.
Schon einmal vorab, testen will ich es erst wenn die SF's noch ein paar stunden aktiv waren um zu sehen ob dese auseinander driften.
Vieleicht steht ein andere User irgend wann mal vor einem ähnlichen Problem bzw. Lösungsweg eventuell auch mit einer anderen Art von Modulen.
sub SFSetInterval($) {
my ($delay) = @_; ##required delay between each other SF modules
my @fcs = defInfo('TYPE=SolarForecast','NAME'); ##extract array of all existing SF Modules
my $interval = ($delay * @fcs); ##calculate the time period for all modules with one call done
my $sftimer = ""; ##timer name, just to tag the timers onto the modules, better readable, also better to find later, and avoid maybe dublicates
my $dtime = 0; ##delaytime. is dynamically increasing, restart time for the timers depends on: actual ctrlInterval & now later given new ctrlInterval
##find longest ctrlInterval, to set the next new added timer after the regular next loop call
foreach my $fc (@fcs) {
if ($dtime < ReadingsNum($fc,"ctrlInterval", 70)) { ##if ctrlInterval is greater the greates last one ..
$dtime = ReadingsNum($fc,"ctrlInterval", 70); ##.. then enlarge timer start delay time to the greatest(this here) one.
}
fhem("attr ".$fc." ctrlInterval 0"); ##stop modul loop with next interval call
$sftimer = "at.".$fc.".setinterval"; ##get name of timer
fhem("delete ".$sftimer); ##if this sub call was twice or repeated then delete previously startet timer. just in case
}
my $dtime += $delay; ##add regular interval of sec to the restart of the module cycle
##set new timer to sync
foreach my $fc (@fcs) {
$sftimer = "at.".$fc.".setinterval"; ##get name of new timer
$dtime += ($delay + $interval); ##next timer call will be in now existing delay + wanted delay between SF's + interval s delay(to avoid high system load)
fhem("define ".$sftimer ." at +".sectotimertime($dtime)." attr ".$fc." ctrlInterval ".$interval);
fhem("attr ".$sftimer ." room AT");
}
return @fcs.'/'.$interval
}
Hallo miteinander,
bin wieder mit an Bord und schaue was in der Zwischenzeit passiert ist.
@Holger:
ZitatIst das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.
Das passiert bei meiner Consumer Definition des Consumers aber ncht
Das wird schon angekegt, aber erst wenn der Bedarf besteht. D.h. bei einem logischen Wechsel zw. 1->0.
Solange die Automatic nicht explizit ausgeschaltet wird (zum Beispiel mit dem Schalter in der Consumergrafik) ist auto=1 auch wenn das entsprechende Reading fehlt (Default). Einmal die Automatik ausgeschaltet wird das Reading automatisch angelegt. Manuell geht es natürlich auch.
@Dracolein:
ZitatWobei laut Doku:
..
# Device STP5000 liefert PV-Werte. Die aktuell erzeugte Leistung im Reading "total_pac" (kW) und die tägliche Erzeugung im Reading "etotal" (kWh). Die max. Leistung des Wechselrichters beträgt 5000 Watt.
Das ist natürlich ein Fehler in der Commandref den ich behebe. tägliche Erzeugung -> gesamte Erzeugung
LG
@DS_Starter
Wie sieht es denn mit Punkt 2 aus https://forum.fhem.de/index.php?topic=137058.msg1312279#msg1312279 aus?
Punkt 1 habe ich für mich Zufriedenstellend gelöst.
Allerdings hätte ich da zwei Fragen.
Um 1Uhr-kurz nach 1Uhr geht mein Load zielich hoch. Ich meine das da was war mit der Ki und dem DWD Modul einst (deshalb 1 uhr und nicht wie vorher Mitternacht). Was macht das Modul zu der Zeit?
Ist nicht kritisch interressiert mich einfach nur.
Und was auch nicht kritisch ist (zumindest für mich jetzt) ist die Frage wieso der interne Intervaltimer nicht anhält wenn ich den Interval auf 0 setzte oder das Modul disable.
Ist doch unschön. Sollte ich fälschlicherweise ein ctrlInterval von 60000 einstellen. Dann kann ich erst mal fast einen Tag warten oder neustarten das der wieder triggert. So vermute ich das mal. Habe ich nicht probiert aber denke das würde passieren. Oder?
Hallo ihr,
ich verzweifle an der Definition currentMeterDev für eine SunSpec Solaredge SE30k. Dort gibt es meines Wissnes für den aktuellen Wert Einspeisung / Bezug nur I_AC_Power. Daher Sonderfall gfeedin=-gcon, unten jedoch ausformuliert.
So weit so gut, "Herzlichen Glückwunsch 😊, die Anlagenkonfiguration ist fehlerfrei."
Aber es wird ein negativer Wert für den Hauverbrauch angezeigt, der sich zur PV-Produktion addiert.
set currentMeterDev SEdge gcon=-I_AC_Power:W contotal=X_M_ImportedToday:W gfeedin=I_AC_Power:W feedtotal=X_PV_Energy:W
Hat bitte jemand eine Idee, oder Erfahrungen mit der SolarEdge-Einbindung?
Viele Grüße
Hausrobot
Bei den Spezialfällen ist nur einmal das entsprechende Reading im Schlüssel anzugeben. Ansonsten nur die Negation des Schlüssels, also z.B. gfeedin=-gcon.
Schau dir dazu das Beispiel zu dem Sonderfall noch einmal genauer an.
LG
Heiko
@kask,
ZitatKönnte man in das Balkendiagramm nicht auch die Forcastconsumption einfliessen lassen. Jetzige Balken nur halb so breit und der consumption Forecast mit rein. Ist vieleicht etwas tricky mit den Zahlenwerten (eventuell vertikal anordnen dann?) ;). Fände ich schick den vermutliche Verbrauch auch zu sehen.
Man kann doch bereits jetzt über das Attr graphicBeamXContent den consumptionForecast anzeigen lassen.
Oder was meinst du?
ZitatAllerdings hätte ich da zwei Fragen.
Um 1Uhr-kurz nach 1Uhr geht mein Load zielich hoch. Ich meine das da was war mit der Ki und dem DWD Modul einst (deshalb 1 uhr und nicht wie vorher Mitternacht). Was macht das Modul zu der Zeit?
Ist nicht kritisch interressiert mich einfach nur.
Der KI Lernprozess läuft per default um 02:15, die Stunde kann aber mit dem Attr ctrlAIshiftTrainStart verschoben werden. Um 01:xx laufen im Modul keine besonderen Aktivitäten ab. In der Sub _specialActivities siehst du die Zeiten für besondere Aktivitäten. Das Attr ctrlAIshiftTrainStart hat entsprechenden Einfluß.
ZitatUnd was auch nicht kritisch ist (zumindest für mich jetzt) ist die Frage wieso der interne Intervaltimer nicht anhält wenn ich den Interval auf 0 setzte oder das Modul disable.
Woraus schließt du bzw. läßt dich vermuten dass der interne Intervaltimer nicht anhält?
ZitatMan kann doch bereits jetzt über das Attr graphicBeamXContent den consumptionForecast anzeigen lassen.
Oder was meinst du?
Das kannte ich nicht. Aber ich dachte mir das eher in Richtung Zweibalken diagram. So das man beides sieht.
Wie würde ich das denn machen müssen wenn ich den Forecast und den Consumption (beides mit Prognosee&Realität) grafisch sehen würden wolle.
"ctrlAIshiftTrainStart" schau ich mir mal an.
ZitatWoraus schließt du bzw. läßt dich vermuten dass der interne Intervaltimer nicht anhält?
Ganz einfach. Durch divese Tests den Internentimer von aussen zu manipulieren bzw. beim schauen wie dieser sich verhält.
Testszenarien u.A.:
Device diasablen/enablen (hintereinander) : Resultat= Interval bleibt wie dieser war bestehen. keine Zeitdifferenz zum vorherigen und nächsten Interval.
ctrlIntervall auf 0, dann auf ursprung stellen (sofort hintereinander). Resultat= wie disablen/enablen.
ctrlInterval auf einen größeren/kleineren wert ändern. Neuer Intervall greift erst wenn der alte abgelaufen ist.
Kannst du ja mal Ausprobieren.
ZitatWie würde ich das denn machen müssen wenn ich den Forecast und den Consumption (beides mit Prognosee&Realität) grafisch sehen würden wolle.
Da du sowohl Forecast und Consumption mit jeweils Prognose und Real sehen möchtest wäre es ja ein 4-Balkendiagramm und nicht nur 2-Balken Diagramm. ;)
Zur Zeit gibt es nur zwei Balken in denen du wahlweise die verschiedenen Inhalte anzeigen kannst.
Ich überlege mal ob man den Bereich des Balkendiagramms quasi "duplizieren" kann, um dann 2 Balkendiagrammbereiche untereinander darstellen zu können in denen jeweils ein 2-Balkendiagramm (wie bisher) vorhanden wäre.
ZitatDevice diasablen/enablen (hintereinander) : Resultat= Interval bleibt wie dieser war bestehen. keine Zeitdifferenz zum vorherigen und nächsten Interval.
Warum sollte sich dadurch die Intervalleinstellung, also der Zeitraum zwischen zwei Zyklen, ändern?
Je nach Zeitpunkten des diasablen/enablen kann beim Enablen der Zeitpunkt des nächsten Zyklus bereits überschritten sein und wird dann sofort ausgeführt. Passt soweit.
ZitatctrlIntervall auf 0, dann auf ursprung stellen (sofort hintereinander). Resultat= wie disablen/enablen.
Ja, wie oben.
ZitatctrlInterval auf einen größeren/kleineren wert ändern. Neuer Intervall greift erst wenn der alte abgelaufen ist.
Ist auch ok soweit weil technisch bedingt der neue Attributwert beim Setzen des neuen Intervalls nach Abarbeitung des laufenden Zyklus gelesen wird.
Aber da schaue ich ob ich beim Setzen des Attributes ctrlInterval entsprechend eingreifen kann um eine sofortige Wirkung zu erzielen.
ZitatDa du sowohl Forecast und Consumption mit jeweils Prognose und Real sehen möchtest wäre es ja ein 4-Balkendiagramm und nicht nur 2-Balken Diagramm. ;)
Das kann man halten wie ein Dachdecker. 4-Balken, 2-Balken,2x2 Balken ist Auslegungssache. Aber ja das meinte ich ein "4-Balken" oder eher ein "2x2Balken" Diagramm.
ZitatWarum sollte sich dadurch die Intervalleinstellung, also der Zeitraum zwischen zwei Zyklen, ändern?
Je nach Zeitpunkten des diasablen/enablen kann beim Enablen der Zeitpunkt des nächsten Zyklus bereits überschritten sein und wird dann sofort ausgeführt. Passt soweit.
Weil ich annehmen würde das ein disablen "1" das Modul stopt bzw. das. Tut es aber nicht so richtig.
Laut commandref für fhem deaktiviert es das device.
Wenn du das anders machst. Dann solltest du das umbennen, sonst beist sich das und bewirkt Verwirrung. Wie bei mir jetzt.
ZitatDie folgenden lokalen Attribute werden von mehreren Geräten verwendet:
IODev
Setzt das IO oder das physische Device, welches zum Senden der Signale an dieses logische Device verwendet werden soll (Beispielsweise FHZ oder CUL). Hinweis: Beim Start weist FHEM jedem logischen Device das letzte physische Device zu, das Daten von diesem Typ empfangen kann. Das Attribut IODev muss nur gesetzt werden, wenn mehr als ein physisches Device fähig ist, Signale von diesem logischen Device zu empfangen.
disable
Deaktiviert das entsprechende Gerät.
Kann mit folgendem Befehl einfach umgeschaltet werden:
attr <device> disable toggle
ZitatIst auch ok soweit weil technisch bedingt der neue Attributwert beim Setzen des neuen Intervalls nach Abarbeitung des laufenden Zyklus gelesen wird...
Ich kann damit umgehen, kenne das Verhalten ja jetzt. Aber wenn ein anderer User ausversehen einen sehr hohen Wert einträgt. Wundert er sich warum da nix passiert obwohl der ctrlInterval Wert doch wieder klein gestellt wurde.
Und dann landet er hier und sagt "Das Modul aktualisiert sich nicht mehr nicht!". Du läst dir am Ende die RAWDEF schicken und da ist ja alles wieder tutti. Und dann "verschwendest" du deine Zeit weil es da nichts zu finden gibt. Deshalb würde ich es, auch in deinem Interresse, gut finden wenn du schaust ob du da eventuell eingreifen kannst. Ich benötige es nicht. Macht Dir, anderen/neuen Usern, Testern am Ende aber das Leben entspannter ;)
Mann kann nicht alles Abfangen. Ich kenne das. Es passieren Sachen die man nicht bedacht hatte bzw. garnicht auf dem Schirm hat das sowas passieren kann.
Man kann nur soviel testen wie man selber weiß oder denkt.
Und dann kommt noch der unberechenbare Faktor "Mensch" dazu. Und dann ist man raus, weil man sich denkt so doof kann man doch garnicht sein.
Aber Fehler passieren nun einmal wenn was durch Menschenhand gemacht wird. Ob absichtlich, ausversehen, unbedachtheit oder geringem Kenntnisstand. Es passiert immer, früher oder später.
ZitatWeil ich annehmen würde das ein disablen "1" das Modul stopt bzw. das. Tut es aber nicht so richtig.
Laut commandref für fhem deaktiviert es das device.
Jedes Modul "stoppt" beim disablen nicht vollständig. Es muß ja mindestens noch eine Abfrage durchlaufen werden die feststellt ob der disabled/enabled Status (noch) vorhanden ist.
Das ist auch in diesem Modul so. Mehr als diese Logik wird aber im disabled-Status nicht ausgeführt und alle nachfolgenden Prozesse ebenso nicht. Deswegen ist das Device logisch deaktiviert denn es passiert nichts außer der obige Sachverhalt.
Da Haste wahr!
Das das Modul Prüfen muß ob es noch disabled/enabled ist klar.
Sonst wäre es ja für immer "tot".
Habe es für mich mal ausprobiert.
Ist wohl ein FHEM ding da es bei einem AT sich genauso verhält. Denke nicht das es ein Perl "Ding" ist.
defmod ATsec31 at +*00:00:31 {}
Ich vermute jetzt das die Timer immer auf einen Zeitstempel überlaufen also immer absolut sind.
Wenn ich das AT oder dein Modul "aus" und sofort wieder "ein"-schalte dann ist der Zeitstempel noch nicht erreicht. Somit wird da keine neue Zeit geschrieben.
Erst, falls das enabled nach dem Ablauf kommt. Ansonsten kommt der alte noch nicht erreichte Zeitstempel.
War mir so nicht bewusst. Ist mir auch noch nie aufgefallen. Gut zu wissen, danke.
Ich habe das Attr ctrlInterval Setting überarbeitet. Eine Änderung des Wertes wirkt sich sofort aus.
Ist eingecheckt und zur sofortigen Verwendung ebenfalls in meinem contrib verfügbar.
In meinem contrib liegt die V 1.18.0 zum Test.
Hinzugekommen ist die Möglichkeit eine zweiten Ebene des Balkendiagramms einzublenden um dort weitere Inhalte abzubilden. In dem Beispielscreenshot ist der consumptionForecast abgetragen.
Um diese Ebene zu aktivieren und einzustellen gibt es weitere Grafikattribute:
graphicBeam3Content, graphicBeam4Content, graphicBeam3Color, graphicBeam4Color, graphicBeam3FontColor, graphicBeam4FontColor
Die commandref ist entsprechend überarbeitet:
graphicBeamXContent
Legt den darzustellenden Inhalt der Balken in den Balkendiagrammen fest. Die Balkendiagramme sind in zwei Ebenen verfügbar.
Die Ebene 1 ist im Standard voreingestellt. Der Inhalt durch die Attribute graphicBeam1Content und graphicBeam2Content bestimmt.
Die Ebene 2 der Balkendiagramme kann durch Setzen der Attribute graphicBeam3Content und graphicBeam4Content zugeschaltet werden.
Die Attribute graphicBeam1Content und graphicBeam3Content stellen die primären Balken, die Attribute graphicBeam2Content und graphicBeam4Content die sekundären Balken der jeweiligen Ebene dar.
pvReal reale PV-Erzeugung (default für graphicBeam1Content)
pvForecast prognostizierte PV-Erzeugung (default für graphicBeam2Content)
gridconsumption Energie Bezug aus dem Netz
consumptionForecast prognostizierter Energieverbrauch
In den Attributen graphicBeamXContent steht nun auch "consumption", der Hausverbrauch, zusätzlich zu "gridconsumption" zur Verfügung. Somit kann man auch einen grafischen Vergleich von "consumptionForecast" und "consumption" darstellen. Siehe Anhang.
Update liegt im contrib.
Genau das wollte ich anfragen. Wollte nur etwas Zeitverstreichen lassen.
Klasse!
Die Höhen-Skalierung ist, ich will nicht moppern, etwas unschön. Kann man die Balken nicht etwas höher ziehen oder den Bereich verkleinern?
Wie gesagt will nicht mosern ;)
Im Prinzip geht das mit einem separaten Attribut. Momentan wird der Wert von graphicBeamHeight bzw. ebenso graphicBeamWidth übernommen und richtet sich somit nach den Vorgaben der Ebene 1.
Wahrscheinlich führe ich noch graphicBeamHeightLvl2 / graphicBeamWidthLvl2 ein. Wollte es zu Anfang nicht gleich übertreiben und erstmal schauen wie das Ganze so ankommt.
Im contrib liegt ein Update.
Es gibt nun die Attribute graphicBeamHeightLevel1 und graphicBeamHeightLevel2 zur Festlegung der Höhenverhältnisse der jeweiligen Ebenen:
graphicBeamHeightLevelX <value>
Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene.
In Verbindung mit dem Attribut graphicHourCount lassen sich damit auch recht kleine Grafikausgaben erzeugen.
(default: 200)
Das Attr graphicBeamWidth habe ich so gelassen und wird für beide Levels verwendet. Unterschiede in der Breite sehen sehr unschön aus.
Das alte Attr graphicBeamHeight wird automatisch in graphicBeamHeightLevel1 umgesetzt.
Achtung, dazu muß FHEM nach dem Update restartet werden!
Ich habe die Freiräume oberhalb der Balken beider Ebenen noch etwas optimiert.
Update im contrib.
Neue Version ist offiziell eingescheckt und morgen im Update.
Kleiner Nebeneffekt:
Man sieht jetzt wenn sich grobe Schnitzer in den Statistikdaten (durch egal was entstanden) eingeschlichen haben :o
-> siehe 2 (gelbe) Ausschläge in der Verbrauchsplanung
Ansonsten - Herzlichen Dank an Dich an dieser Stelle für deine Leistungen @DS_Starter
Gruß
300P
@pah,
was meintest du in #454 mit der Aussage:
Zitat3. Ich habe keine Möglichkeit gefunden, PV-Anlagen mit Direkteinspeisung zusätzlich in die Visualisierung aufzunehmen.
So richtig kann ich es nicht einordnen.
LG
Vor einiger Zeit hatte ich in currentMeterDev die optionalen Schlüssel conprice und feedprice eingeführt.
Nun werden die Preise bzw. Vergütungssätze der jeweiligen Stunde in der pvHistory gespeichert und sind darüber auch auswertbar.
Bei einem fixen Satz sicherlich nicht so spannend, aber für Nutzer mit flexiblen Energiepreis sicherlich interessant.
Darüber hinaus kann man nun auch die Kosten des Energiebezuges und Vergütung für die Netzeinspeisung in der Grafik via graphicBeamXContent-Auswahl anzeigen lassen.
Vermutlich ist es in diesem Zusammenhang auch noch sinnvoll, die Einspeisung in das öffentliche Netz für die Grafik auswählbar zu ermöglichen.
Ist eingecheckt und ist für eilige User auch aus meinem contrib abrufbar.
LG
Zitat von: DS_Starter am 11 Mai 2024, 11:52:51Vor einiger Zeit hatte ich in currentMeterDev die optionalen Schlüssel conprice und feedprice eingeführt.
Nun werden die Preise bzw. Vergütungssätze der jeweiligen Stunde in der pvHistory gespeichert und sind darüber auch auswertbar.
Bei einem fixen Satz sicherlich nicht so spannend, aber für Nutzer mit flexiblen Energiepreis sicherlich interessant.
Darüber hinaus kann man nun auch die Kosten des Energiebezuges und Vergütung für die Netzeinspeisung in der Grafik via graphicBeamXContent-Auswahl anzeigen lassen.
Vermutlich ist es in diesem Zusammenhang auch noch sinnvoll, die Einspeisung in das öffentliche Netz für die Grafik auswählbar zu ermöglichen.
Ist eingecheckt und ist für eilige User auch aus meinem contrib abrufbar.
LG
Bei der Währung, welche Auswahl gibts da neben €, auch cent?
ZitatBei der Währung, welche Auswahl gibts da neben €, auch cent?
Du kannst angeben was du möchtest. Im Prinzip ist es nur eine Gedankenstütze für den User damit er die Augabe einordnen kann. Später verwende ich die Währung ggf. bei einem Mouse-Over.
Hat er € angegeben, ist die Ausgabe auch als Eurowert zu interpretieren, ist es Cent dann ist die Ausgabe auch ein Cent-Wert. Die Unterscheidung passiert durch Anwendung des angegebenen Multiplikators, also entweder 0,27 (Euro) oder 27 (Cent).
Im Interesse einer optisch schmalen Werte-Ausgabe würde ich € eingeben.
Ich habe ein wenig weiterentwickelt.
Die nächste Version kann im Attr graphicBeamXContent auch die Einspeisung in das öffentliche Netz darstellen.
Außerdem wird mit Mouse-Over angezeigt, welchen Content der ausgewählte Balken darstellt.
Da es mittlerweile mehrere Ebenen mit mehr auswählbaren Content gibt, hilft es den Überblick zu behalten was die Balken wiedergeben.
Ich bin noch nicht ganz fertig, deswegen gibt es die V zunächst in meinem Contrib.
LG
Zitat von: DS_Starter am 11 Mai 2024, 11:52:51Vor einiger Zeit hatte ich in currentMeterDev die optionalen Schlüssel conprice und feedprice eingeführt.
Ich habe das damals auch gleich definiert, finde die Daten aber nicht in der pvHistory. Welche Werte sind bei den "Einheiten" denn erlaubt?
(In der Hilfe steht nix, im Beispiel ist nur "€" verwendet. Ich habe es mit "EUR/kWh" definiert/angelegt.)
Und: Muss das Reading rein numerisch sein oder darf die Einheit im Reading auch dabei stehen? (Bei mir steht beispielsweise (Hausnummer) "0.1736 EUR/kWh" im Reading des aktuellen Bezugspreises.)
Moin,
ZitatIch habe das damals auch gleich definiert, finde die Daten aber nicht in der pvHistory. Welche Werte sind bei den "Einheiten" denn erlaubt?
In die pvHistory werden die Daten erst seit der V 1.19.0 geschrieben:
13 => 01 => etotal: 60122550, pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
confc: 474, con: 442, gcon: 23, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
...
In der Wahl der Währung bist du völlig frei. Ist nur für die Anzeige.
ZitatUnd: Muss das Reading rein numerisch sein oder darf die Einheit im Reading auch dabei stehen? (Bei mir steht beispielsweise (Hausnummer) "0.1736 EUR/kWh" im Reading des aktuellen Bezugspreises.)
Das sollte funktionieren weil ich ReadingsNum verwende, d.h. das System sollte nur den Wert 0.1736 herausziehen.
Den Schlüssel würdest du so angeben:
conprice=<Device>:<Reading>:EUR oder
conprice=<Device>:<Reading>:EUR/kWh oder
conprice=<Device>:<Reading>:€
Zitat von: DS_Starter am 13 Mai 2024, 09:03:03In die pvHistory werden die Daten erst seit der V 1.19.0 geschrieben:
Ok, dann hab' ich nicht genau genug geschaut. Das Update habe ich gestern Vormittag gemacht, und siehe da ab dem "11" Eintrag der PV-History von gestern ist der Wert für den Bezugspreis befüllt.
In der Syntax vom Einspeisetarif hatte ich noch einen Fehler, den ich vorhin korrigiert habe, und nun sind die Werte auch da.
Zitat von: DS_Starter am 13 Mai 2024, 09:03:03Das sollte funktionieren weil ich ReadingsNum verwende, d.h. das System sollte nur den Wert 0.1736 herausziehen.
Den Schlüssel würdest du so angeben:
conprice=<Device>:<Reading>:EUR oder
conprice=<Device>:<Reading>:EUR/kWh oder
conprice=<Device>:<Reading>:€
Ja tut es, ich verwende conprice=<Device>:<Reading>:EUR/kWh.
Die neue Version ist eingecheckt:
- Mouse-Over zeigt bei der Balkengrafik die Contentbeschreibung
- graphicBeamXContent: gridfeedin ist verfügbar
- Debug consumerSwitching: das Schaltkommando wird komplett im Log ausgegeben
LG
Hallo in die Runde,
ich bastel so langsam weiter und habe immer mehr Spaß am SolarForecast-Modul :-)
Da ja aktuell - und vermutlich auch die nächsten Monate - jede Menge Energie durch die PV-Anlage erzeugt wird und ich auch den Speicher nicht mehr so ohne Weiteres leer bekomme, hab ich überlegt, ob ich nachts ein Stück was Energie aus dem Akku in den Brauchwasserspeicher schieben kann, so dass die Ölheizung aus bleibt.
Die Bedingungen würden grob so aussehen:
- Unterschreitung einer Temperatur im Brauchwasserspeicher
- Mindestladezustand Akku
- erwarteter Verbrauch für die nächsten Stunden
- Zeitpunkt, ab dem mit einer Einspeisung über ... gerechnet wird.
Brauchwassertemperatur und Ladezustand vom Akku sind kein Problem. Den Zeitpunkt, mit Einspeisung > als ... finde ich in den
Today_HourXX_PVforecast- Readings. Da kann erst einmal ein Haken dran.
Bleibt der erwartete Verbrauch. Hier habe ich das Reading
NextHours_Sum04_ConsumptionForecast. Und zu genau diesem Reading hätte ich eine Frage.
Wenn ich das recht verstehe, gibt mir das Reading den erwarteten Verbrauch für die nächsten 4h aus. Faktisch wäre das genau das, was ich brauche. Wenn ich das aber recht verstehe, wird dieser Wert durch "Erfahrungswerte" gebildet.
Sprich: wenn ich nach aktuellem Stand Nachts um 02:00 Uhr drauf schaue, sehe ich, was ich bis 06:00 als summierten Ruhestrom verbrauche. Das ist das, was ich eigentlich möchte.
Wenn ich jetzt feststelle, dass der Akku um 02:00 Uhr (um beim Beispiel zu bleiben) noch so voll ist, dass ich den Ruhestrom der nächsten 4 Stunden abdecken kann und gleichzeitig noch Energie übrig ist, die ich in das Brauchwasser stecken könnte (sagen wir 2 kWh) und das auch tue, würde das System doch daraus lernen, richtig?
D.h. ich bekomme, wenn ich das eine Woche so mache, bei
NextHours_Sum04_ConsumptionForecast den Wert inkl. der Arbeit, die ich in den Heizstab gesteckt habe (also quasi 2kWh mehr). Das würde die Entscheidung, ob die Einschaltbedingung vorhanden ist, jedoch verfälschen, da ich letztlich von einer höheren erwarteten Last ausgehe und ich nicht mehr den "reinen" Ruhestromverbrauch sehe.
Von daher: hab ich das so richtig verstanden? Und gibt es eine Möglichkeit, Lasten bzw. Verbraucher vom Trainingsdatensatz auszuschließen, so dass diese bei den Lastprognosen nicht berücksichtigt werden?
Im Voraus schon einmal vielen Dank und Grüße
Hazel
Hallo Hazel,
für die "normale" Planung kann man das Attr affectConsForecastInPlanning dafür verwenden.
Im beschriebenen Fall geht es nicht, da 1. in der Nacht und 2. aus der Batterie verbraucht werden soll.
Es gibt mit "get ... nextHours" den Schlüssel "confcEx" der den Verbrauch ohne den Erfahrungsanteil registrierter Verbraucher enthält. Wenn du des Perl mächtig bist, kannst du dir diese Werte rausziehen (Schnittstelle "NexthoursVal" ist im Wiki beschrieben).
Anderenfalls könnte ich anbieten, über das Attr ctrlStatisticReadings ein Reading statistic_ConsumptionForecastEx_Sum04 zuschaltbar erstellen zu lassen, welches du dann auswerten kannst.
Das muß ich aber erst einbauen.
Ansonsten hast du alles richtig erkannt und beschrieben. ;)
Grüße,
Heiko
Zitathab ich überlegt, ob ich nachts ein Stück was Energie aus dem Akku in den Brauchwasserspeicher schieben kann, so dass die Ölheizung aus bleibt.
Damit verschönerst du auch die Bilanz des Speichers. Man kann sich so einen Speicher immer schön rechnen.
Meinst du das es sinnig ist den Speicher zu strapazieren um eine 1 zu 1 umwandlung durchzuführen? So ein Heizstab ist ja nicht gerade das günstigste zum Brauchwassser erwärmen. Gut du kannst den Ölbrenner schonen. Ich habe keinen Ölbrenner, deshalb keine Ahnung ob es sinnig ist.
Du kannst auch den Speicher unerlaubterweise Nachts ins Netz entspeichern. Da wäre es aber dann vieleicht noch grüner den Speicher garnicht voll aufzuladen und damit die Zellen zu schonen.
ich war/bin auch dran an sowas.
den Wert inkl. der Arbeit, die ich in den Heizstab gesteckt habe (also quasi 2kWh mehr). Das würde die Entscheidung, ob die Einschaltbedingung vorhanden ist, jedoch verfälschen, da ich letztlich von einer höheren erwarteten Last ausgehe und ich nicht mehr den "reinen" Ruhestromverbrauch sehe.Und genau das ist auch mein Problem bei dem ganzen. Durch den Verbrauch erhöhe ich meine Vorhersage und somit meine Zukünftige Entscheidungsschwelle.
Und wenn es grenzwertig wird ist es schwer. Bei massiven Überschuß z.b. 20kWh im Speicher und einer 1kWh Hheizung wäre es fast egal. Denn die Heizung könnte 20h an sein dafür. Interessant wird es wenn nicht die volle Ladung Sonne am nächsten Tag zu erwarten ist. Zudem der Speicher nur 10kWh noch enthält und du eine 3kW Heizung hast. Dann ist nach 1,3h das Licht aus im Ernstfall.
Jetzt ist die Frage was du willst? Willst du unterstützen und ggf. bleibt der Brenner aus oder auch nicht (jedesmal aus ist besser wie immer an). Oder willst du so viel wie möglich zuheizen um soviel wie möglich den Brenner nicht anspringen zu lassen (maximal niedrigste Brennerlaufzeit).
Das erste ist nicht so kritisch da kann der Wert ruhig hoch gehen. Ist ja eh genug im Speicher. Nur halt nicht so oft.
Das zweite wird schwer weil du die Vorhersage verfälscht. Zumindest so wie es jetzt aufgebaut ist.
Ich hatte mir überlegt ob ich eine zweite Vorhersage machen mit manipuliertem Consumptionwert. (Richtiger Wert minus dem Verbrauchswert der Verfälschung).
Dann könnte man sowas am limit betreiben wenn man die maipulierten Werte als Entscheidungshilfe nimmt.
Aber so richtig gefällt mir das nicht.
ZitatDa wäre es aber dann vieleicht noch grüner
Ich wäre aber sehr vorsichtig damit, das als etwas Positives aufzufassen. 2011 haben zwar alle politischen Kräfte bei der rechtswidrigen Entscheidung mitgewirkt. Aber inzwischen haben wir das Energiedebakel nur noch denen zu verdanken, die "noch grüner" sein wollen.
LG
pah
Bezüglich einer Speicher- und Ertrags-Optimierung habe ich persönlich folgende Vorgehensweise.
Meine Anlage besteht aus einer 5.2 kW Peak Überschußeinspeisung (SMA) und einer Nulleinspeiseanlage mit 3 Phasen Victron MPII + Victron SmartSolar DC-DC Wandler. Die MPII und der SmartSolar laden die Pylontech Batterien.
Es ist die Eigenschaft der Victron-Anlage, dass der SmartSolar vom Steuergerät heruntergeregelt wird sobald die Batterie voll ist und kein Hausstrombedarf besteht. Das ist unschön, denn es mindert die Effizienz der Gesamtanlage denn meistens reicht jetzt im Sommer bereits die SMA-Anlage um den Hausbedarf am Tag zu decken.
Um das Verhalten zu verbessern, errechne ich ausgehend vom Batterie SOC am Beginn des Tages wieviel kWh Bat benötigt um am Ende des Tages voll zu sein. Das passiert mit jedem Modul-Zyklus. Daraus errechne ich den maximalen Ladestrom und vermindere das Ergebnis um den aktuellen Ladestrom des SmartSolar.
Der verbleibende Wert ist der max. Ladestrom für die MPII. Er kann auch Null sein. In diese ganze Rechnung geht noch die PV-Vorhersage ein sowie ein Teil der Verbrauchsprognose um den wahrscheinlichen Überschuß des Tages zu haben.
Im Ergebnis des ganzen Verfahrens wird die Leistungsfähigkeit des SmartSolar (mit dem angeschlossenen String) optimal ausgenutzt, sodass er nicht oder möglichst spät heruntergeregelt wird und andererseits wenig AC-DC Wandlung mit entsprechenden Verlusten durch die Ladung über die MPII vorgenommen wird. Als Nebeneffekt wird auch die Überschßeinspeisung des SMA maximiert, da weniger seiner erzeugten Energie in die Batterien fließt.
Ein ähnliches Verfahren könnte Hazel anwenden. Er würde dann nicht die Verbrauchsprognose verwenden, sondern ausrechnen, wie niedrig der Batterie-SOC am Beginn des Tages sein könnte um in Verbindung mit der PV-Prognose am Ende des Tages wieder 100% Ladung zu erreichen und könnte dementsprechend die Energie der Batterie (so vorhanden) für die Wassererwärmung nutzen. Im Ergebnis wäre es eine Maximierung des Eigenverbrauchs bei einer Minimierung der Einspeisung. Nun kommt es noch darauf an wieviel man Vergütung bekommt im Vergleich zu den Bezugskosten und wieviel eine kWh auf Öl-Basis kostet.
Nur ein paar Gedanken dazu ...
LG
@pah, hast du meine Nachfrage in #578 gesehen?
#579, meinst Du. Nein, hatte ich nicht.
In meiner Energierechnung geht immer auch ein, wieviel ich durch die Volleinspeisung spare. Darum ist die Altanlage in meiner Visualisierung auch drin, siehe Bild von der Situation gerade eben.
Wie man an dem Bild sieht, habe ich das E-Auto inzwischen - die PV-Anlage hoffentlich bis Mitte nächster Woche.
LG
pah
Hallo in die Runde!
es ist unglaublich, wie schnell ihr beim Antworten seid :-) Danke dafür!
Zu allererst: Mein Setup ist ein Fronius WR (Gen24) mit einer BYD Batterie. Die Batterie soll 6000 - 8000 Ladezyklen bei einer Leistungdegradation auf 90% haben. Um die Zyklenzahl mache ich mir also nur bedingt Sorgen. Allerdings sehe ich zu, dass die Lade- und Entladeströme möglichst eher klein sind. Es ist halt ein chemischer Prozess...
Das Ganze hat auch eher weniger was mit Grün zu tun. Die Anlage ist da, bezahlt und soll jetzt schlicht ihr Geld durch die Minimierung von extern zu besorgender Energie bzw. Energieträgern verdienen. Der Eigenbedarf (Strom) ist sicher der größte Teil davon und nach bisherigen Erkenntnissen in min 9 Monaten + einzelne Tage vollständig gedeckt. Rückspeisung ins Netz möchte ich vermeiden, die Überschussenergie soll soweit möglich sinnvoll genutzt werden. Der Verbrauch anderer Energieträger (konkret vor allem Öl) soll, wie gesagt, minimiert werden. Bis hierhin reden wir also über stumpf finanzielle Gründe. Davon mal abgesehen sehe ich einen Mehrwert in der Autarkie sowie den Variationsmöglichkeiten beim Einsatz von (Primär)Energieträgern.
Leider erlaubt das verbaute System nicht ganz die Freiheitsgrade wie die Victron/Pylontech - Lösung von DS_Starter. Zumal die MultiPlus ja nicht mal ein Netz brauchen sondern auch einen 3phasigen Genarator "akzeptieren" ... ;-) (ja, ein bisschen neidisch bin ich da schon)
However - Eure Ideen und Anregungen sind super. Ich bin nicht wirklich gut in Perl, aber es hilft ja nichts. Ich werde also mal schauen, dass ich mir die Lösung aus #588 einmal genauer anschaue.
@DS_Starter: vielen Dank für die Hinweise und auch für deine Config. Da hab ich was zum drüber nachdenken und rumtüfteln :-)
@kask: aktuell kostet die kWh Heizöl ca. 10 ct. Für die Rückspeisung von Strom ins Netz würde ich irgendwas bei 8ct/kWh bekommen. Wenn ich den selbst erzeugten Strom (20 Jahre bei durchschnittlich erwarteten Ertrag) nehme bin ich unter den 10 ct/kWh die mich das Öl kostet. Aber nur, wenn der Eigenbedarf maximiert ist. Für Wärmwasser (inkl. "Verluste" durch im Kreis pumpen) gehen (naja, gingen) erstaunliche 1,5 l/Tag drauf (+-). Das irgendwie erschreckend viel, wenn man das mal so zusammenzählt. Und ja, die Ölheizung hat schon 26 Jahre, darf aber nach aktuellem Gesetz noch drin bleiben (Niedertemperaturölkessel). Ich hab aber den Verdacht, dass das absehbar nicht günstiger wird ... Und sicher hat es auch einen Grund, warum mach nach den neuen Gesetzen entsprechende Rechnungen für eingekaufte Energieträger aufheben muss...
Wir werden sehen. Und bis dahin wird jetzt Bestand geschaffen, der dann hoffentlich Schutz genießt.
In diesem Sinne: Danke euch, und bei weiteren Ideen immer her damit.
Ach so, ich melde mich, wenn ich das für mich gelöst habe.
Hazel
@hazelnut
Zitataktuell kostet die kWh Heizöl ca. 10 ct. Für die Rückspeisung von Strom ins Netz würde ich irgendwas bei 8ct/kWh bekommen. Wenn ich den selbst erzeugten Strom (20 Jahre bei durchschnittlich erwarteten Ertrag) nehme bin ich unter den 10 ct/kWh die mich das Öl kostet
Öl:
Uij, 10ct/kWh das ist aber nicht gerade wenig. Ich dachte es wäre günstiger.
Da Zahle ich ja weniger mit Fernwärme. Zudem ist meine Fernwärmeübergabestation bei weitem billiger in der Anschaffung.
Und einen Schornsteinfeger brauch ich auch nicht.
Wieviel Watt braucht den das Gebläse an elektrischer Energie vom Brenner (Ich vermute jetzt mal das der Kessel ja nicht betröpfelt wird)? Das kommt ja auch noch on top.
Elektrizität:
Sicher das es unter 10ct/kWh werden können?
z.B. eine 20kWpp Anlage macht ca. 20MWh im Jahr hier bei Uns.
Das sind in 20Jahren 400MWh. Bei 10k€ ..was 500€/kWpp sind..wären das schon 10000/4000000 = 2.5€cent.
Dazu kommen jetzt noch deine 8€cent. Weil du diese ja nicht einspeisst. Also sind es schon 10.5€cent.
Und bei dem alter der Anlage glaube ich nicht das du einen Gen24+BYD+Panele für 500€/kwpp bekommen hast.
Ich kann mich da aber auch täuschen und du hast nen wirklichen Schnapper einst gemacht.
@kask, bei deiner Rechnung mußt du aber auch noch berücksichtigen, dass man mit jeder selbst verbrauchten kWh der PV-Anlage die 10,5 Cent kostet (mit entgangener Vergütung) je nach Tarif so um die 25-28 Cent Bezug spart. Zur Zeit jedenfalls wenn man einen günstigen Tarif hat.
Das sehe ich nicht ... kann aber auch an der schon späten Stunde liegen. ;)
ZitatUij, 10ct/kWh das ist aber nicht gerade wenig. Ich dachte es wäre günstiger.
Mein Erdgas kostet aktuell auch 9,95 ct/kWh netto zzgl. 19% Mwst. Leider.
Hallo noch einmal,
ZitatIch kann mich da aber auch täuschen und du hast nen wirklichen Schnapper einst gemacht.
Sagen wir es mal so: ich komme klar ... 8)
Das Öl ist übrigens mit 10 ct/kWh (also 1€/l) gerade eher günstig. Haben wir auch schon anders gesehen.
Zu deiner Rechnung ... schau ich mir morgen noch mal an. Kann ich noch nicht ganz nachvollziehen.
Gutes Nächtle
Hazel
Zitatbei deiner Rechnung mußt du aber auch noch berücksichtigen, dass man mit jeder selbst verbrauchten kWh der PV-Anlage die 10,5 Cent kostet (mit entgangener Vergütung) je nach Tarif so um die 25-28 Cent Bezug spart.
Ja, sicher. Sonst würde sich so eine Anlage nie rechnen mit Überschusseinspeisung.
Der Gedanke war eher das die PV-Energie nicht unbedingt kostengünstiger ist wie Öl. Mal von den Schadstoffen abgesehen die in den PV-Komponenten schon freigegeben sind (ohne recycling) und den Schadstoffen die erst freigesetzt werden wenn der Fossile-Brennstoff umgewandelt wird.
Den grad der "grün-heit" der PV-Komponenten kann man natürlich durch nutzen dieser für sich verbessern, indem man mehr Energie selbst nutzt.
Die Energie ist ja nicht verloren weil man es sonst dem Nachbarn nutzen lässt durch Einspeisung also da wird sich an der "grün-heit" nichts ändern.
Das bischen Netzverlust lasse ich mal ausser acht.
In deinem Fall mit der Reduzierung wegen der "Nulleinspeisung" geht das halt nicht. Da wäre es günstiger PV statt öl zu nutzen.
Wobei das mit der Nulleinspeisung bei dir ja auch nicht wirklich eine ist. Nur weil du den PV-Überschuss regelst so das da nichts ins Netz fliessen lassen willst ist es ja noch lange keine Nulleinspeisung. Du schriebst ja das du mit dem sma laden kannst. Ergo, ist der SMA am Netz, ist es der MPII auch und somit kein wirkliche Nulleinspeiseanlage mehr.
Ich weiß auch nicht warum du das so machst. Bestimmt hast du deine Gründe.
Moin kask,
ZitatWobei das mit der Nulleinspeisung bei dir ja auch nicht wirklich eine ist. Nur weil du den PV-Überschuss regelst so das da nichts ins Netz fliessen lassen willst ist es ja noch lange keine Nulleinspeisung. Du schriebst ja das du mit dem sma laden kannst. Ergo, ist der SMA am Netz, ist es der MPII auch und somit kein wirkliche Nulleinspeiseanlage mehr.
Ich weiß auch nicht warum du das so machst. Bestimmt hast du deine Gründe.
Naja, mit wollen hat es nichts zu tun. Die nachgerüstete Victron-Anlage bzw. das Meßkonzept ist beim Netzbetreiber als Nulleinspeiseanlage registriert. Dadurch bleibt meine (parallele) Altanlage mit Überschußeinspeisung bzw. deren noch gute Einspeisevergütung unberührt.
Rein physikalisch hast du recht. Administrativ ist es eben nicht so einfach wobei es einfach sein könnte wenn man es wollte.
Aber das will ich nicht diskutieren, steht auf einem anderen Blatt und hier geht es um die technischen Möglichkeiten die man mit dem Modul umsetzen kann.
@All,
in meinem contrib liegt eine neue V 1.21.0.
Ich habe die Anregung von pah umgesetzt, dass der Energy Meter (currentMeterDev) bezüglich der Schüssel contotal und feedtotal einen Tageszähler anbieten kann.
Das bedeutet das Modul behandelt einen Reset dieser Readings am Tagesanfang zu "0" entsprechend.
Auszug aus der ComRef:
currentMeterDev <Meter Device Name> gcon=<Readingname>:<Einheit> contotal=<Readingname>:<Einheit> gfeedin=<Readingname>:<Einheit> feedtotal=<Readingname>:<Einheit> [conprice=<Feld>] [feedprice=<Feld>]
Legt ein beliebiges Device und seine Readings zur Energiemessung fest. Das Modul geht davon aus, dass der numerische Wert der Readings positiv ist. Es kann auch ein Dummy Device mit entsprechenden Readings sein. Die Bedeutung des jeweiligen "Readingname" ist:
gcon Reading welches die aktuell aus dem Netz bezogene Leistung liefert
contotal Reading welches die Summe der aus dem Netz bezogenen Energie liefert (ein sich stetig erhöhender Zähler)
Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), kann dieses Reading verwendet werden.
In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
gfeedin Reading welches die aktuell in das Netz eingespeiste Leistung liefert
feedtotal Reading welches die Summe der in das Netz eingespeisten Energie liefert (ein sich stetig erhöhender Zähler)
Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), kann dieses Reading verwendet werden.
In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
.....
Die Version soll erst noch ein wenig im Test laufen bevor sie ins Repo wandert um sicher zu gehen keine Nebenwirkungen eingefangen zu haben. Bis jetzt läuft sie bei mir einwandfrei.
LG
Zitat von: DS_Starter am 15 Mai 2024, 10:47:30Naja, mit wollen hat es nichts zu tun. Die nachgerüstete Victron-Anlage bzw. das Meßkonzept ist beim Netzbetreiber als Nulleinspeiseanlage registriert. Dadurch bleibt meine (parallele) Altanlage mit Überschußeinspeisung bzw. deren noch gute Einspeisevergütung unberührt.
Wie wird das technisch realisiert? Hat die Victron-Anlage einen eigenen (Sub-) Zähler, an dem der Netzbetreiber feststellen kann woher der eingespeiste Strom kommt?
Wenn beides hinter dem gleichen Hausstromzähler hängt, kann man ja unmöglich nachvollziehen von welcher Anlage der eingespeiste Strom erzeugt wurde. (Natürlich nur in einem physikalisch nachvollziehbaren Rahmen... wenn Du mehr einspeist als die Altanlage insgesamt bringt, wird's unplausibel.)
ZitatWie wird das technisch realisiert? Hat die Victron-Anlage einen eigenen (Sub-) Zähler, an dem der Netzbetreiber feststellen kann woher der eingespeiste Strom kommt?
Die Victron-Anlage hat einen eigenen Zähler. Sobald dieser Zähler eine Einspeisung misst, regelt Victron ab. D.h. das Hausnetz wird versorgt, das öffentliche Netz nicht. Victron hat dafür einen eigenen Steuerungssatz (ESS) der in das Controlgerät (CerboGX) geladen wird.
Zitat von: DS_Starter am 15 Mai 2024, 12:56:08Die Victron-Anlage hat einen eigenen Zähler. Sobald dieser Zähler eine Einspeisung misst, regelt Victron ab. D.h. das Hausnetz wird versorgt, das öffentliche Netz nicht. Victron hat dafür einen eigenen Steuerungssatz (ESS) der in das Controlgerät (CerboGX) geladen wird.
Mit sowas habe ich gerechnet, aber das spielt sich doch alles hinter dem offiziellen Zähler statt, oder?
Hinter dem Zähler des Netzbetreibers, ja.
@pah, zu deinem zweiten Anstrich:
Zitat2. Waschmaschinen sind durchaus Großverbraucher, und die meisten laufen inzwischen ziemlich lange. Ein weiterer wichtiger Faktor
ist die Wäschetrockung (nicht im Trockner, sondern auf der Leine). Es nutzt zwar möglicherweise der Stromrechnung, wenn die
Waschmaschine nachmittags um 17:00 fertig ist - aber trocken wird das dann nicht mehr. Ich habe keine Möglichkeit gefunden,
eine "Fertig-Zeitangabe" für einen Consumer festzulegen.
Im Prinzip kann man eine definierte Endezeit bereits jetzt indirekt festlegen durch eine Kombination aus power, mintime, notafter.
Also z.B.:
attr ... consumerXX <Device Name> type=washingmachine power=0 mintime=120 notafter=10:00 ...
Bei der Definition würde die Waschaschine spätestens 10:00 für max. 2h loslaufen. Sie wäre also spätestens 12:00 fertig.
Das ist doch was du haben wolltest oder doch noch etwas anders?
LG,
Heiko
Die neue Version ist eingecheckt. Ich habe keine unerwünschten Nebenwirkungen festgestellt.
Hallo zusammen,
ich habe die aktuelle Entwicklungsversion von DWD_OpenData in mein contrib geladen. Wer dieses Wettermodul benutzt kann/sollte diese V nutzen. Mumpitzstuff hat den Speicherverbrauch optimiert.
Siehe dazu den DWD-Thread: https://forum.fhem.de/index.php?msg=1313448
schöne Pfingsten,
LG,
Heiko
Ist das gewollt das der Link oben auf deinen Post abfeuert? Du erwähnst Mumpitzstuff aber ich habe jetzt mal gesucht und ich finde nix über die Speicheroptimierung da von Ihm.
Oder habt Ihr das privat geklärt?
Hätte mich schon interressiert was da optimiert wurde und wie. Könnte ja auch für andere Sachen für mich interessant sein.
Mumpitzstuff hat es in dem Thread nicht genau beschrieben was er alles geändert hat. Ich habe mir die Details auch nicht angeschaut.
Seinen Originalpost findest du hier:
https://forum.fhem.de/index.php?msg=1307533
Um die Änderungen nachzuvollziehen, kannst du dir die Unterschiede zwischen den DWD Versionen in meinem contrib genauer anschauen.
Ich sollte mal mit dem optimieren der Anlagen aufhören.
Wenn das so weiter geht verdient ja keiner mehr geld an mir ;)
Neh, mal im ernst wie kann ich eine negative Consumption haben?
Vermutlich ist da in der Historie letzten Monat mal was schief gelaufen. Sollte vieleicht abgefragt werden das es nicht kleiner 0 sein kann.
Das ist doch was seit dem 14ten nicht i.O immer zur 16ten Stunde. Ich bin ratlos. Einer eine Idee?
Edit: die -923/-935 sind unterschiedlich weil es zwei verschiedene Instancen sind.
Ich habe 7 instancen (SolarForecast Devices) und alle haben das Problem um 16Uhr
Danke für die Hilfe und das Grübeln ;)
Ich hatte letzte Woche Montag einen Umzug vom Raspberry auf einen amd64 system mit proxmox und debian.
Da hatte ich das Backup vom 12ten..also 13ten um 00:XX eingespielt.
Mittags gegen 16Uhr kamen dann wieder Werte rein im Zuge des portierens.
Beim nächsten mal sollte ich, wenn alles geht, wieder mit dem Backup starten.
Doof gelaufen!
Boah, jetzt hatte ich mich schon angestrengt. Dann schreibe ich es jetzt auch noch ;)
Die Consumption (der jeweiligen Stunde) errechnet sich aus:
Hausverbrauch = Erzeugung - Einspeisung + Netzbezug - Bat-In + Bat-Out
Der Forecast ist dann der Durchschnitt der jeweiligen Stunde über die vorhandenen Tage.
An der obigen Formel siehst du, falls z.B. für Bat-In ein unverhältnismäßiger (zu großer/falscher) Wert gemessen bzw. übermittelt wurde, kann der Hausverbrauch negativ werden.
Ich könnte natürlich auf 0 begrenzen. Allerdings sieht man dann nicht mehr falls etwas falsch gelaufen ist.
Und da es die Ausnahme ist bzw. sein sollte, ist es wohl besser ihn zu sehen.
Jepp, ist besser es zu sehen um Unstimmigkeiten eventuell bei großer abweichung schneller detektieren zu können.
Gefunden wo es klemmt hatte ich es mit dem ctrldebug "consumption" das war schon einmal sehr gut.
Gibt es irgendeine Limitierung der Prognosewerte bei z.B. unplausibler/fehlender Vorhersage?
Mir fällt sporadisch auf, dass es in der Prognose einzelne Stunden mit Ertragsprognose "15 kW" gibt, die definitiv nicht erreicht werden können, weil meist eher am späteren Nachmittag gelegen. Die WR-Leistung ist auch mit 15 kW angegeben, daher sieht das für mich nach irgendeinem Ersatzwert aus. Oft "verschwinden" diese Unplausibilitäten nach einigen weiteren zyklischen Datenabrufen wieder und manchmal kommen sie auch plötzlich rein.
Ich hab' grad keinen Screenshot davon bzw. auch keine Daten, werd' aber versuchen es in den nächsten Tagen nachzureichen sobald ich es wieder sehe.
ZitatGibt es irgendeine Limitierung der Prognosewerte bei z.B. unplausibler/fehlender Vorhersage?
Ja. Nach oben ist die Prognose begrenzt durch die installierte (summarische) Stringleistung bzw. installierte WR-Leistung, je nachdem welcher Wert von beiden der kleinere ist.
Nach unten gibt es keine Grenze, Prognose kann also theoretisch 0 sein.
Sollte in deinem Fall eine Prognose von mehr als 15 kWh herauskommen, würde die WR Begrenzung von angegebenen 15 kW * 1h (max. mögliche Energie) = 15 kWh betragen.
Das ctrlDebug = radiationProcess kann bei der Analyse, wieso diese Werte erreicht werden, helfen.
Zitat von: DS_Starter am 21 Mai 2024, 08:49:04Sollte in deinem Fall eine Prognose von mehr als 15 kWh herauskommen, würde die WR Begrenzung von angegebenen 15 kW * 1h (max. mögliche Energie) = 15 kWh betragen.
Klingt erstmal logisch und sinnvoll.
Die Frage ist, wo die Ursache für eine solch überzogene Prognose ist. Da es nicht systematisch zu einer bestimmten Uhrzeit aufzutreten scheint, glaube ich nicht, dass es an irgendwelchen (falsch gelernten) Korrekturfaktoren liegt. Entweder kommt der unplausibel hohe Wert schon von der API und wird dann von Dir (soweit sinnvoll möglich) begrenzt, oder das Modul "verrechnet/verschluckt" sich irgendwo.
Zitat von: DS_Starter am 21 Mai 2024, 08:49:04Das ctrlDebug = radiationProcess kann bei der Analyse, wieso diese Werte erreicht werden, helfen.
Hab' ich vorhin gesetzt, aber jetzt erstmal wieder zurückgenommen, weil das Unmengen an Logeinträgen sind. Werde versuchen es dann zu setzen, sobald ich den Ausreißer sehe.
ZitatDa es nicht systematisch zu einer bestimmten Uhrzeit aufzutreten scheint, glaube ich nicht, dass es an irgendwelchen (falsch gelernten) Korrekturfaktoren liegt.
Wenn du in der Grafik auf den Wert hinter "Qualität:" klickst, bekommst du ein Popup mit den verwendeten Korrekturfaktoren jeder folgenden Stunde. Damit kannst du deine Annahme überprüfen.
ZitatHab' ich vorhin gesetzt, aber jetzt erstmal wieder zurückgenommen, weil das Unmengen an Logeinträgen sind. Werde versuchen es dann zu setzen, sobald ich den Ausreißer sehe.
Das Attr kannst du auch über ein notify setzen lassen wenn ein bestimmter Vorhersagewert überschritten wird.
<Device>:Today_Hour.*_PVforecast:.* {
if ($EVTPART1 >= xxxxx) {
fhem "attr $NAME ctrlDebug radiationProcess";
}
}
[ungetestet]
Hi,
habe mal eine zweite Ebene eingebaut. Das finde ich sehr toll. Allerdings sieht es bei mir nicht so schön aus, weil die Balkenbreite in der zweiten Ebene nicht gleichmäßig ist, wenn in der ersten Ebene keine Balken mehr sichtbar sind. Vielleicht versteht man es besser im Screenshot. Evtl. hat es auch damit zu tun, dass ich in der ersten Ebene nicht alle Stunden abbilde?
Kann ich da etwas machen?
Viele Grüße
Holger
ZitatEvtl. hat es auch damit zu tun, dass ich in der ersten Ebene nicht alle Stunden abbilde?
Ich denke es liegt an der unterschiedlichen resultierenden Anzahl der Werte. In der oberen Reihe gibt es nur 20, d.h. die zukünftigen Werte sind nicht verfügbar.
Evtl. hilft es die Attr graphicHistoryHour und graphicHourCount für eine Optmierung zu verwenden. Welchen Wert hast du oben dargestellt?
Grüße,
Heiko
Moin!
Ich würde gerne Readings wie z.B. "Today_PVforecast" und "Today_PVreal" in meine InfluxDB Datenbank schreiben, damit ich mir die Werte und deren Abweichungen vernünftig visualisieren kann. Leider enthalten die Readings auch entsprechende Einheiten, weswegen die Werte nicht in die InfluxDB Datenbank geschrieben werden (InfluxDB ist eigentlich nur für numerische Werte gedacht). Wäre es möglich die Readings (gff über ein Attribute) ohne Einheiten ausgeben zu lassen?
Grüße
Markus
Kannst du das nicht mit Notify/DOIF und ReadingsNum/$EVENTPART1 machen?
Oder ein Userreading:
Today_PVforecast_influx:Today_PVforecast:.* { ReadingsNum($SELF, "Today_PVforecast", 0); }
kask hat bereits Vorschläge unterbreitet.
@Markus,
da wir mit physikalischen Größen umgehen gehört natürlich zu dem Wert auch eine Einheit dazu um die physikalische Größe eindeutig zu beschreiben. Ein Attribut zum Ausschalten der Einheiten wäre sicherlich grundsätzlich möglich.
Andererseits ist das eigentlich ein grundsätzliches Anwendungsproblem und m.M. nach sollte das InfluxDB-Modul seinen Usern eine Funktion zum Eventsplitting anbieten bzw. besser noch Modulautoren die Möglichkeit zur Implementierung einer entsprechenden Split-Funktion.
Eine Möglichkeit wäre so etwas wie die DbLog_split (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DbLog_split) Funktion. Sie ist in SolarForecast bereits implementiert und bereitet die Daten automatisch für DbLog passend auf. Der Nutzer muß sich nicht darum kümmern.
InfluxDBLogger braucht eigentlich nur diese Möglichkeit in das Modul einbauen und vorgeben wie der Output für InfluxDBLogger aussehen muß. Dann noch eine Beschreibung im Wiki hinterlegen und schon kann jeder Modulautor die Daten passend für InfluxDB aufbereiten.
Ich weiß, das ist vllt. etwas Wunschdenken ;), doch es wäre eine zentrale Lösung die alle Module nutzen könnten. Evtl. magst du dem InfluxDBLogger-Modulautor eine solche Implementierung ähnlich dem verlinkten Beitrag vorschlagen? Dann braucht man (der User) sich nicht mehr zu verrenken.
LG,
Heiko
Wichtige Info für VictronKiAPI-Nutzer
Ich habe festgestellt, dass sich das Antwortformat der VRM-API bzgl. Timestamp etwas verändert hat.
Bislang wurden automatisch volle Stunden als Response geliefert, nun plötzlich wird auf die Requestzeit referenziert:
2024.05.26 08:49:55.702 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 08:49:55 => 3069.90576171875 Wh
2024.05.26 08:49:55.703 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 09:49:55 => 3903.80981445312 Wh
2024.05.26 08:49:55.704 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 10:49:55 => 4332.27673339844 Wh
2024.05.26 08:49:55.705 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 11:49:55 => 4509.46228027344 Wh
2024.05.26 08:49:55.706 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 12:49:55 => 4512.42517089844 Wh
2024.05.26 08:49:55.706 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 13:49:55 => 4370.806640625 Wh
2024.05.26 08:49:55.707 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 14:49:55 => 3899.55920410156 Wh
2024.05.26 08:49:55.708 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 15:49:55 => 3000.00036621094 Wh
....
Damit funktioniert die Forecast nicht mehr. Möglicherweise ist es bereits seit gestern so, habe es heute erst festgestellt.
Ein Patch ist in Arbeit, der auch schon das Problem beseitigt:
2024.05.26 09:57:17.429 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 09:00:00 => 2840.10821533203 Wh
2024.05.26 09:57:17.430 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 10:00:00 => 3705.34130859375 Wh
2024.05.26 09:57:17.431 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 11:00:00 => 4316.81909179688 Wh
2024.05.26 09:57:17.432 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 12:00:00 => 4471.04040527344 Wh
2024.05.26 09:57:17.433 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 13:00:00 => 4450.83947753906 Wh
2024.05.26 09:57:17.434 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 14:00:00 => 4295.37329101562 Wh
2024.05.26 09:57:17.435 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 15:00:00 => 3830.08666992188 Wh
....
Ich gebe Bescheid wenn ich den Patch bereitgestellt habe.
Grüße,
Heiko
Der Patch ist eingecheckt und steht auch zum sofortigen Download in meinem contrib zur Verfügung.
LG
Ich glaube die haben mehr geändert:
statistic_dayAfterTomorrowPVforecast 11683224 Wh
Das halte ich momentan für einen Folgefehler, da die Daten außerhalb der vollen Stunde den Speicherhash aufgebläht haben.
Du kannst die empfangenen Daten mit ctrlDebug apiProcess prüfen:
2024.05.26 16:04:12.809 1: VRMAPI DEBUG> Request VictronVRM API Forecast: https://vrmapi.victronenergy.com/v2/installations/....../stats?type=forecast&interval=hours&start=1716732000&end=1716991200
2024.05.26 16:04:12.969 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 16:00:00 => 3254.10772705078 Wh
2024.05.26 16:04:12.970 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 17:00:00 => 1760.48846435547 Wh
2024.05.26 16:04:12.970 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 18:00:00 => 725.814575195312 Wh
2024.05.26 16:04:12.971 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 19:00:00 => 169.543884277344 Wh
2024.05.26 16:04:12.971 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 20:00:00 => 131.980453491211 Wh
2024.05.26 16:04:12.972 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 21:00:00 => 0 Wh
2024.05.26 16:04:12.973 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 22:00:00 => 0 Wh
2024.05.26 16:04:12.973 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-26 23:00:00 => 0 Wh
2024.05.26 16:04:12.974 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 00:00:00 => 0 Wh
2024.05.26 16:04:12.974 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 01:00:00 => 0 Wh
2024.05.26 16:04:12.975 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 02:00:00 => 0 Wh
2024.05.26 16:04:12.975 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 03:00:00 => 0 Wh
2024.05.26 16:04:12.976 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 04:00:00 => 0 Wh
2024.05.26 16:04:12.977 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 05:00:00 => 456.310653686523 Wh
2024.05.26 16:04:12.977 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 06:00:00 => 555.79768371582 Wh
2024.05.26 16:04:12.978 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 07:00:00 => 785.045471191406 Wh
2024.05.26 16:04:12.979 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 08:00:00 => 1268.87637329102 Wh
2024.05.26 16:04:12.979 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 09:00:00 => 2071.19372558594 Wh
2024.05.26 16:04:12.980 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 10:00:00 => 2948.68511962891 Wh
2024.05.26 16:04:12.981 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 11:00:00 => 3613.60040283203 Wh
2024.05.26 16:04:12.981 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 12:00:00 => 3981.373046875 Wh
2024.05.26 16:04:12.982 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 13:00:00 => 4086.24926757812 Wh
2024.05.26 16:04:12.982 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 14:00:00 => 3967.42333984375 Wh
2024.05.26 16:04:12.983 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 15:00:00 => 3599.66436767578 Wh
2024.05.26 16:04:12.984 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 16:00:00 => 2918.34979248047 Wh
2024.05.26 16:04:12.984 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 17:00:00 => 1871.86010742188 Wh
2024.05.26 16:04:12.985 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 18:00:00 => 834.198120117188 Wh
2024.05.26 16:04:12.985 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 19:00:00 => 319.86213684082 Wh
2024.05.26 16:04:12.986 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 20:00:00 => 142.031135559082 Wh
2024.05.26 16:04:12.986 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 21:00:00 => 0 Wh
2024.05.26 16:04:12.987 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 22:00:00 => 0 Wh
2024.05.26 16:04:12.987 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-27 23:00:00 => 0 Wh
2024.05.26 16:04:12.988 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 00:00:00 => 0 Wh
2024.05.26 16:04:12.988 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 01:00:00 => 0 Wh
2024.05.26 16:04:12.989 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 02:00:00 => 0 Wh
2024.05.26 16:04:12.989 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 03:00:00 => 0 Wh
2024.05.26 16:04:12.990 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 04:00:00 => 0 Wh
2024.05.26 16:04:12.991 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 05:00:00 => 466.14111328125 Wh
2024.05.26 16:04:12.991 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 06:00:00 => 577.263534545898 Wh
2024.05.26 16:04:12.992 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 07:00:00 => 804.713836669922 Wh
2024.05.26 16:04:12.992 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 08:00:00 => 1288.87954711914 Wh
2024.05.26 16:04:12.993 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 09:00:00 => 1999.10345458984 Wh
2024.05.26 16:04:12.993 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 10:00:00 => 2734.54351806641 Wh
2024.05.26 16:04:12.994 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 11:00:00 => 3320.89215087891 Wh
2024.05.26 16:04:12.994 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 12:00:00 => 3667.98321533203 Wh
2024.05.26 16:04:12.995 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 13:00:00 => 3798.74304199219 Wh
2024.05.26 16:04:12.995 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 14:00:00 => 3761.06463623047 Wh
2024.05.26 16:04:12.996 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 15:00:00 => 3492.7763671875 Wh
2024.05.26 16:04:12.996 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 16:00:00 => 2853.55334472656 Wh
2024.05.26 16:04:12.997 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 17:00:00 => 1868.30010986328 Wh
2024.05.26 16:04:12.998 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 18:00:00 => 915.476928710938 Wh
2024.05.26 16:04:12.998 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 19:00:00 => 372.914253234863 Wh
2024.05.26 16:04:12.999 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 20:00:00 => 173.16438293457 Wh
2024.05.26 16:04:12.999 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 21:00:00 => 0 Wh
2024.05.26 16:04:13.000 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 22:00:00 => 0 Wh
2024.05.26 16:04:13.000 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-28 23:00:00 => 0 Wh
2024.05.26 16:04:13.001 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 00:00:00 => 0 Wh
2024.05.26 16:04:13.001 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 01:00:00 => 0 Wh
2024.05.26 16:04:13.002 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 02:00:00 => 0 Wh
2024.05.26 16:04:13.003 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 03:00:00 => 0 Wh
2024.05.26 16:04:13.003 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 04:00:00 => 0 Wh
2024.05.26 16:04:13.004 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 05:00:00 => 513.911575317383 Wh
2024.05.26 16:04:13.004 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 06:00:00 => 628.566802978516 Wh
2024.05.26 16:04:13.005 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 07:00:00 => 928.256164550781 Wh
2024.05.26 16:04:13.006 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 08:00:00 => 1593.74908447266 Wh
2024.05.26 16:04:13.006 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 09:00:00 => 2597.55163574219 Wh
2024.05.26 16:04:13.007 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 10:00:00 => 3527.30755615234 Wh
2024.05.26 16:04:13.007 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 11:00:00 => 4072.66955566406 Wh
2024.05.26 16:04:13.008 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 12:00:00 => 4242.92651367188 Wh
2024.05.26 16:04:13.009 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 13:00:00 => 4198.69567871094 Wh
2024.05.26 16:04:13.009 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 14:00:00 => 3986.58190917969 Wh
2024.05.26 16:04:13.010 1: VRMAPI DEBUG> Victron VRM API - PV estimate: 2024-05-29 15:00:00 => 3418.14501953125 Wh
2024.05.26 16:04:13.010 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 16:00:00 => 503.414239485 Wh
2024.05.26 16:04:13.011 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 17:00:00 => 748.0005245121 Wh
2024.05.26 16:04:13.011 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 18:00:00 => 569.3109585805 Wh
2024.05.26 16:04:13.012 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 19:00:00 => 509.1061171131 Wh
2024.05.26 16:04:13.012 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 20:00:00 => 512.9393513613 Wh
2024.05.26 16:04:13.013 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 21:00:00 => 622.4328351491 Wh
2024.05.26 16:04:13.013 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 22:00:00 => 551.9096164129 Wh
2024.05.26 16:04:13.014 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-26 23:00:00 => 633.7656126572 Wh
2024.05.26 16:04:13.014 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 00:00:00 => 413.1322464483 Wh
2024.05.26 16:04:13.015 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 01:00:00 => 351.7202953167 Wh
2024.05.26 16:04:13.016 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 02:00:00 => 438.1276425059 Wh
2024.05.26 16:04:13.016 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 03:00:00 => 422.2283957855 Wh
2024.05.26 16:04:13.017 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 04:00:00 => 447.2301436421 Wh
2024.05.26 16:04:13.018 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 05:00:00 => 451.0777874341 Wh
2024.05.26 16:04:13.018 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 06:00:00 => 545.7597009207 Wh
2024.05.26 16:04:13.019 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 07:00:00 => 578.0806106759 Wh
2024.05.26 16:04:13.020 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 08:00:00 => 592.787489873 Wh
2024.05.26 16:04:13.020 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 09:00:00 => 667.7446404198 Wh
2024.05.26 16:04:13.021 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 10:00:00 => 643.6682699288 Wh
2024.05.26 16:04:13.022 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 11:00:00 => 767.5791418029 Wh
2024.05.26 16:04:13.022 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 12:00:00 => 636.0369377612 Wh
2024.05.26 16:04:13.023 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 13:00:00 => 572.4216917792 Wh
2024.05.26 16:04:13.023 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 14:00:00 => 602.532199866 Wh
2024.05.26 16:04:13.024 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 15:00:00 => 488.9446178414 Wh
2024.05.26 16:04:13.025 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 16:00:00 => 619.4459312752 Wh
2024.05.26 16:04:13.025 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 17:00:00 => 490.3966741769 Wh
2024.05.26 16:04:13.026 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 18:00:00 => 504.4059085781 Wh
2024.05.26 16:04:13.027 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 19:00:00 => 682.2206016356 Wh
2024.05.26 16:04:13.027 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 20:00:00 => 1005.3565150506 Wh
2024.05.26 16:04:13.028 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 21:00:00 => 579.201839946 Wh
2024.05.26 16:04:13.028 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 22:00:00 => 622.4106472211 Wh
2024.05.26 16:04:13.029 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-27 23:00:00 => 599.6567588091 Wh
2024.05.26 16:04:13.030 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 00:00:00 => 476.7806421748 Wh
2024.05.26 16:04:13.030 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 01:00:00 => 406.3308093823 Wh
2024.05.26 16:04:13.031 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 02:00:00 => 417.6184494248 Wh
2024.05.26 16:04:13.032 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 03:00:00 => 467.7405401837 Wh
2024.05.26 16:04:13.032 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 04:00:00 => 438.1262920425 Wh
2024.05.26 16:04:13.033 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 05:00:00 => 562.550241638 Wh
2024.05.26 16:04:13.034 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 06:00:00 => 785.8108445499 Wh
2024.05.26 16:04:13.034 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 07:00:00 => 753.3321199034 Wh
2024.05.26 16:04:13.035 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 08:00:00 => 802.5151861644 Wh
2024.05.26 16:04:13.035 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 09:00:00 => 836.0847452689 Wh
2024.05.26 16:04:13.036 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 10:00:00 => 807.3062797415 Wh
2024.05.26 16:04:13.036 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 11:00:00 => 615.6603433444 Wh
2024.05.26 16:04:13.037 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 12:00:00 => 539.0654849284 Wh
2024.05.26 16:04:13.037 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 13:00:00 => 539.5758183325 Wh
2024.05.26 16:04:13.038 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 14:00:00 => 676.6141750163 Wh
2024.05.26 16:04:13.038 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 15:00:00 => 531.5538582806 Wh
2024.05.26 16:04:13.039 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 16:00:00 => 557.1363432749 Wh
2024.05.26 16:04:13.039 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 17:00:00 => 551.9273054601 Wh
2024.05.26 16:04:13.040 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 18:00:00 => 475.3655225914 Wh
2024.05.26 16:04:13.040 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 19:00:00 => 556.0709265555 Wh
2024.05.26 16:04:13.041 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 20:00:00 => 573.4386820124 Wh
2024.05.26 16:04:13.041 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 21:00:00 => 595.1091916646 Wh
2024.05.26 16:04:13.042 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 22:00:00 => 588.3023132045 Wh
2024.05.26 16:04:13.042 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-28 23:00:00 => 572.3479760809 Wh
2024.05.26 16:04:13.043 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 00:00:00 => 517.7349436597 Wh
2024.05.26 16:04:13.043 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 01:00:00 => 460.8760760458 Wh
2024.05.26 16:04:13.044 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 02:00:00 => 413.1235161767 Wh
2024.05.26 16:04:13.044 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 03:00:00 => 456.3256464426 Wh
2024.05.26 16:04:13.045 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 04:00:00 => 379.0222675999 Wh
2024.05.26 16:04:13.045 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 05:00:00 => 481.7753130091 Wh
2024.05.26 16:04:13.045 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 06:00:00 => 613.1263643817 Wh
2024.05.26 16:04:13.046 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 07:00:00 => 624.3527316856 Wh
2024.05.26 16:04:13.047 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 08:00:00 => 613.6693940669 Wh
2024.05.26 16:04:13.047 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 09:00:00 => 610.2344996635 Wh
2024.05.26 16:04:13.047 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 10:00:00 => 528.9421963792 Wh
2024.05.26 16:04:13.048 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 11:00:00 => 625.991225646 Wh
2024.05.26 16:04:13.048 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 12:00:00 => 551.8234393065 Wh
2024.05.26 16:04:13.049 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 13:00:00 => 635.8056328577 Wh
2024.05.26 16:04:13.049 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 14:00:00 => 567.6489183689 Wh
2024.05.26 16:04:13.050 1: VRMAPI DEBUG> Victron VRM API - CO estimate: 2024-05-29 15:00:00 => 610.6177563848 Wh
2024.05.26 16:04:13.050 1: VRMAPI DEBUG> Request VictronVRM API Logout: https://vrmapi.victronenergy.com/v2/auth/logout
Die sehen jetzt wieder gut aus.
stimmt wohl. sieht stark danach aus.
Ein kleiner Ausblick zu den nächsten Schritten in diesem Modul ...
Wie ich bereits irgendwo weiter vorn geschrieben hatte, sind manche Einstellungen die zur Zeit über Readings laufen, besser als Attribute definiert weil sie sehr statisch sind. Das betrifft insbesondere currentMeterDev, currentInverterDev, currentBatteryDev und die ganzen Stringdefinitionen (z.B. moduleAzimuth ...).
Das wird sich Schritt für Schritt über einen längeren Zeitraum hinziehen. Ich bin mir noch unschlüssig diese Strukturen als ctrl-Attribute einzubauen oder eine neue Kategorie, z.b. setup* einzuführen, da diese Dinge zur grundlegenden Einrichtung gehören. Weil das Modul sehr viele Attribute beinhaltet, will ich sie möglichst gut strukturieren.
Weiterhin soll es dem Modul möglich sein, auf einem separaten Rechner als zentrale Steuereinheit zu laufen und Meter, Inverter, Batterie und Consumer etc. auf remoten Rechnern (Satelliten) zu integrieren und zu steuern. Das kann man durchaus als advanced Setup bezeichnen. Entsprechende Ideen zur Umsetzung habe ich bereits im Kopf. Mal schauen wie es sich entwickelt.
LG
Zitat von: DS_Starter am 21 Mai 2024, 10:17:48ZitatDa es nicht systematisch zu einer bestimmten Uhrzeit aufzutreten scheint, glaube ich nicht, dass es an irgendwelchen (falsch gelernten) Korrekturfaktoren liegt.
Wenn du in der Grafik auf den Wert hinter "Qualität:" klickst, bekommst du ein Popup mit den verwendeten Korrekturfaktoren jeder folgenden Stunde. Damit kannst du deine Annahme überprüfen.
So, hat zwar ein bisschen gedauert, aber ich hab's erwischt. Wenn ich die Daten richtig interpretiere, liegt es wohl an einem zu hohen Korrekturfaktor:
2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV API estimate for tomorrow Hour 16 string PV1 ->
Estimated PV generation (calc) => 7768.8 Wh
Estimated PV generation (raw) => 7768.8 Wh
Module Temp (calculated) => 26.55 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.06 kWp
modulePeakString => 8400 W
2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV API estimate for tomorrow Hour 16 string PV3 ->
Estimated PV generation (calc) => 7768.8 Wh
Estimated PV generation (raw) => 7768.8 Wh
Module Temp (calculated) => 26.55 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.06 kWp
modulePeakString => 8400 W
2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV forecast start time 2024-05-27 15:00:00 limited to 15000 Watt due to inverter capacity
2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV API estimate for tomorrow Hour 16 summary:
Cloudcover => 97
Forecasted temperature => 25.80 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.66
PV correction quality => 0.60
PV generation forecast => 15000 Wh
Starttime => 2024-05-27 15:00:00
Total Rain last hour => 0.00 kg/m2Eine Frage noch dazu... kommen diese Werte direkt von der API oder sind die auch schon mit irgendwas "verrechnet"?
Estimated PV generation (calc) => 7768.8 Wh
Estimated PV generation (raw) => 7768.8 WhDie kommen mir nämlich auch schon recht hoch vor...
Mittlerweile scheint wohl sowohl die Vorhersage als auch der Korrekturfaktor (deutlich) nach unten gegangen zu sein, sodass zumindest die Limitierung weg ist:
2024.05.27 06:36:41 1: mySolarForecast DEBUG> PV API estimate for today Hour 16 string PV1 ->
Estimated PV generation (calc) => 5074.8 Wh
Estimated PV generation (raw) => 5074.83 Wh
Module Temp (calculated) => 26.3 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.05 kWp
modulePeakString => 8410 W
2024.05.27 06:36:41 1: mySolarForecast DEBUG> PV API estimate for today Hour 16 string PV3 ->
Estimated PV generation (calc) => 5074.8 Wh
Estimated PV generation (raw) => 5074.83 Wh
Module Temp (calculated) => 26.3 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.05 kWp
modulePeakString => 8410 W
2024.05.27 06:36:41 1: mySolarForecast DEBUG> PV API estimate for today Hour 16 summary:
Cloudcover => 98
Forecasted temperature => 25.80 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.13
PV correction quality => 0.89
PV generation forecast => 10149 Wh
Starttime => 2024-05-27 15:00:00
Total Rain last hour => 0.00 kg/m2
Moin,
ZitatEine Frage noch dazu... kommen diese Werte direkt von der API oder sind die auch schon mit irgendwas "verrechnet"?
Hier ist in beiden schon der Korrekturfaktor verrechnet.
Allerdings sollte "Estimated PV generation (raw)" den Wert aus der API und "Estimated PV generation (calc)" den Wert mit dem verrechneten Korrekturfaktur ausdrucken. Mein Fehler. Das korrigiere ich.
LG
Hallo,
mir sind bei der Nutzung des Moduls so ein paar Fragen gekommen. Da ich gerade auf der Suche nach der Ursache für Abweichungen zwischen Prognose und Abweichungen bin, stelle ich sie mal.
Ich habe das Modul gerade in 3 Geräten zum Vergleich im Einsatz (OpenMeteoDWDAPI, OpenMeteoDWDEnsembleAPI, DWD für eine Station 10 km entfernt). Aktuell (gegen 17:00 und bei aktuellem Wetter passiert da heute nicht mehr viel) habe ich für heute fortlaufende Abweichungen zwischen 51 und 65 %. Ist das beim aktuellen Wetter normal?
Hier nun die Fragen:
- Was genau bedeutet der KI-Status: "... liefert jedoch keinen Wert für die aktuelle Stunde"? Oder anders gefragt, nach welcher Laufzeit sollte es den geben? Das habe ich laut Qualitätsübersicht in allen 3 Geräten für die meisten Stunden.
- Werden die Strings von der KI separat betrachtet? Oder wenn die Ausrichtung gleich ist, macht es einen Unterschied, wenn man mehrere separat definiert? Ich Frage im speziellen, weil ich ein Problem mit Beschattung durch ein anders Gebäude habe, das die Strings je nach Tageszeit unterschiedlich betrifft.
- Vor dem Aufsetzen der 3 Geräte, hatte ich nur eins mit DWD (Station im Ort). Leider gab es bei der Station von einem Tag auf den anderen keine stündlichen Werte mehr, daher hatte ich auf OpenMeteoDWDAPI umgestellt. Hätte ich da die gelernten Werte zurücksetzen sollen?
- Die gleiche Frage für andere Änderungen, z.B. kleiner Fehler in der Ausrichtung der Module korrigiert bzw. Fehler in den Koordinaten (latitude, longitude) korrigiert.
Vielen Dank für das Modul und die Beantwortung der Fragen ;-)
Thomas
Hallo Thomas,
ZitatWas genau bedeutet der KI-Status: "... liefert jedoch keinen Wert für die aktuelle Stunde"? Oder anders gefragt, nach welcher Laufzeit sollte es den geben? Das habe ich laut Qualitätsübersicht in allen 3 Geräten für die meisten Stunden.
Wann die KI einen Wert liefert ist nicht vorhersehbar, da es von der Dauer des Einsatzes und den Lernzustand abhängt. Deswegen gibt es auch keinen reinen KI Modus, sondern eine KI Unterstützung.
"get ... valDecTree aiRawData" bzw. "get ... valDecTree aiRuleStrings" gibt die einen Einblick und Erläuterungen.
ZitatWerden die Strings von der KI separat betrachtet?
Nein, es werden die Inputparameter Strahlung, PV-Ertrag, Bewölkung, Niederschlag, Sonnenstand (Altitude, Azimuth), Temperatur pro Stunde verwendet.
ZitatVor dem Aufsetzen der 3 Geräte, hatte ich nur eins mit DWD (Station im Ort). Leider gab es bei der Station von einem Tag auf den anderen keine stündlichen Werte mehr, daher hatte ich auf OpenMeteoDWDAPI umgestellt. Hätte ich da die gelernten Werte zurücksetzen sollen?
Bei dem beschriebenen Wechsel der API nutzen die bisher gelernten Werte nicht mehr viel. Grund ist dass DWD die Globalstrahlung liefert und die OpenMeteoDWDAPI bereits eine sogenannte Tilted Globalstrahlung. Dort steckt der Einfuß der geneigten Fläche bereits mit drin.
Es stört aber auch nicht die Werte zu behalten, vllt. switched du das Device irgendwann mal wieder auf DWD Station zurück.
ZitatDie gleiche Frage für andere Änderungen, z.B. kleiner Fehler in der Ausrichtung der Module korrigiert bzw. Fehler in den Koordinaten (latitude, longitude) korrigiert.
Nein. So großen EInfluß haben diese kleinen Änderungen i.A. nicht. Viel mehr fällt eine unvorhergesehene Bewölkung oder eine Wolke die sich ein paar Stunden über deiner Anlage "festsetzt", wenn drumherum die Sonne strahlt, ins Ertragsgewicht.
Die fortlaufenden Abweichungen zwischen 51 und 65 % sind sehr hoch. Bei mir sind sie zur Zeit bei OpenMeteoWorldAPI ca. 7%, SolCastAPI ca. 5%.
Allerdings habe ich zu den fortlaufenden Abweichungen ein eher gespaltenes Verhältnis und betrachte vorwiegend Tagesabweichungen nach Sonnenuntergang.
Die lagen gestern bei DWD lokal 3,3%, OpenMeteoDWDAPI -3,7 %, OpenMeteoDWDEnsembleAPI 2,4 %, SolCastAPI 5,2 %.
Die VictronKiAPI muß außen vor lassen. Da gab es gestern einen Issue wegen einer API Änderung den ich fixen musste.
Also alle arbeiten bei diesem Wetter sehr zufriedenstellend.
Wenn die Tagesabweichung sich einpendelt, ist alles ok. Ansonsten sollte man da nochmal hinschauen ob es ein Konfigurationsproblem gibt.
LG
ZitatDie fortlaufenden Abweichungen zwischen 51 und 65 % sind sehr hoch
Das kann ich so nicht voll und ganz bestätigen. Habe ich auch ab und an mal, aber eher selten (nur bei sehr unbeständigem Wetter). +/-20% schon eher, aber nicht all zu häufig.
Meist +/-10%.
Ich habe heute +1.4% - -16% Deviation
Im mittel Aller 1% Deviation. Damit (Mittelwert) arbeite ich auch.
Und das mein Konfiguration nicht stimmt glaube ich auch nicht.
Ich habe auch teilweise so Abweichungen.
Mein Fazit ist das bei durchwachsenem Wetter sämtliche DWD Module besser funktionieren.
Bei gutem Wetter SolCastAPI & Victron.
Die openmeteo funktionieren am besten im Durchschnitt betrachtet.
ForcastSolarAPI ist bei mir eigentlich nur noch zum drüber ärgern. Da kann ich auch abends aus dem Fenster gucken und mach die Prognose selber mit gleichem effekt.
Der wirkliche Wert der deviation ist zum Stundenanfang eher "naja", zum Stundenende wird es Aussagekräftiger. Zum Tagesende die Wahrheit.
So sieht das halt bei mir aus.
@kask, gebe dir vollkommen recht. Mir ging es nur darum falls es bei Thomas ein Dauerzustand sein sollte müßte man mal danach schauen.
Das recht große Abweichungen unter Tage immer mal vorkommen können steht außer Frage. Gerade bei wechselhaftem Wetter.
ZitatDer wirkliche Wert der deviation ist zum Stundenanfang eher "naja", zum Stundenende wird es Aussagekräftiger.
Liegt in der Natur der Sache. Am Anfang einer Stunde -> hohe Vorhersage + keine oder sehr wenig reale Erzeugung = großer Einfluß auf fortlaufende Abweichung.
Zitat von: DS_Starter am 21 Mai 2024, 22:08:31ZitatEvtl. hat es auch damit zu tun, dass ich in der ersten Ebene nicht alle Stunden abbilde?
Ich denke es liegt an der unterschiedlichen resultierenden Anzahl der Werte. In der oberen Reihe gibt es nur 20, d.h. die zukünftigen Werte sind nicht verfügbar.
Evtl. hilft es die Attr graphicHistoryHour und graphicHourCount für eine Optmierung zu verwenden. Welchen Wert hast du oben dargestellt?
Grüße,
Heiko
Du meinst im oberen Balkendiagramm? Da habe ich kein spezielles Attribut gesetzt. Ich nur folgende Attribute (die Consumer habe ich mal weg gelassen):
attr Forecast DbLogExclude .*
attr Forecast affectConsForecastIdentWeekdays 1
attr Forecast ctrlStatisticReadings todayConsumptionForecast,todayGridConsumption,todayGridFeedIn
attr Forecast ctrlWeatherDev1 OpenMeteoDWDEnsemble-API
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicAnimate 1
attr Forecast flowGraphicShowConsumerRemainTime 1
attr Forecast graphicBeam3Content gridconsumption
attr Forecast graphicBeam4Content consumptionForecast
attr Forecast graphicLayoutType double
attr Forecast verbose 2
Ich probiere mal die von Dir genannten Attribute aus.
Liebe Grüße
Holger
@all,
morgen früh gibt es ein Update.
- Debug-Ausgabe von radiationProcess gefixt
- die Debug-Ausgabe von consumerSwitching ist nun für jeden Consumer separiert auswählbar.
Insbesondere bei vielen Consumern erhöht es die Übersicht des Debuggings.
Zitat von: DS_Starter am 27 Mai 2024, 18:52:46Allerdings habe ich zu den fortlaufenden Abweichungen ein eher gespaltenes Verhältnis und betrachte vorwiegend Tagesabweichungen nach Sonnenuntergang.
Ja, keine Frage, sehe ich generell auch so. Gestern hat sich nach 17:00 Uhr aber wirklich nicht mehr viel geändert. Und es bringt halt nichts, wenn man um 11:00 einen Verbraucher bei 50 % Abweichung einschaltet, auch wenn gegen Abend dann wieder alles passt. Aber die hohe Abweichung ist ja nicht normal, also das Problem liegt woanders.
Das Wetter bei uns (Rhein-Main-Gebiet) würde ich aktuell schon als sehr wechselhaft bezeichnen. Der "April" hat schon im März angefangen und ist immer noch nicht zu Ende.
Zum Thema "Einpendeln": Die Umstellung auf OpenMeteoDWDAPI ist jetzt 8 Wochen her. Das DWD-Gerät mit der anderen Station ist erst ein paar Tage im Einsatz. Das mit OpenMeteoDWDEnsembleAPI so dazwischen.
Ich spiele jetzt mal Updates ein und suche dann weiter ...
Es sah übrigens mit der alten DWD-Station schon mal viel besser aus. An dem Gerät hatte ich außer der API nichts geändert. Die anderen sind Kopien davon. Die Einstellungen musste ich halt erneut vornehmen, weil die meisten (noch) in Readings gespeichert werden.
Hi Tomcat,
ich bin auch im Rhein Main Gebiet.
Meine Abweichung gestern war -6,3%.
Ich benutze OpenMeteoDWD-API.
Gruß,
Stefan
ZitatUnd es bringt halt nichts, wenn man um 11:00 einen Verbraucher bei 50 % Abweichung einschaltet, auch wenn gegen Abend dann wieder alles passt.
Dafür ist die Abweichung-Info nicht gedacht. Das Modul erstellt auf Grund der Prognose die geplanten Schaltsequenzen der Verbraucher. Wenn sich die Wetterbedingungen gegenüber der Prognose ändern, nimmt das Modul eine automatische Anpassung vor sofern der Verbaucher noch nicht gestartet wurde. Sofern die Einstellungen des Verbrauchers es nicht erzwingen, erfolgt bei ungenügenden Überschuß keine Einschaltung.
Das Modul hat also eine entsprechende Logik dafür.
Ein laufende Abweichung hat ohnehin für die Verbraucherschaltung keine Relevanz. Wie ich am Beispiel erläuterte, hat man z.B. um 11:01 eine Prognose von 7000 Wh für diese Stunde, aber nur einen aktuellen Ertrag von 50 Wh. Die Abweichung wäre in diesem Fall exorbitant, aber im Laufe der Stunde gleicht es ich im Idealfall absolut an. Ich denke du siehst was ich damit sagen möchte.
Die Abweichung-Info hat eher die Aufgabe eine Statistik zu erstellen und uns Anwendern zu zeigen wie sich die Prognose/Ist Entwicklung darstellt. Wie im Anhang zum Beispiel.
@Heiko: Ist schon klar, dass die Info nicht zur Steuerung gedacht ist. Wollte damit nur mein Problem mit einem einzelnen, direkt sichtbaren Wert verdeutlichen. Da ich beim Schreiben gestern den Tageswert noch nicht hatte, habe ich die laufenden Abweichungen (kurz vor Ende des Tages) genommen. Die Abweichung ist aber nur die Folge der fehlerhaften Vorhersage bei mir.
Noch ne Frage zu Deinem Beispiel mit "um 11:01 eine Prognose von 7000 Wh für diese Stunde, aber nur einen aktuellen Ertrag von 50 Wh" und "im Laufe der Stunde gleicht es ich im Idealfall absolut an." Bei mir gibt es keine Sprünge mit dem Stundenwechsel. Es sieht also eher so aus, als ob für die Berechnung nicht der stündliche Vorhersagewert mit der mit der minutengenauen Erzeugung verglichen wird. Also würden anhand des Beispiels eher die ~100 Wh für die erste Minute im Vergleich zu den 50 Wh in die Berechnung einfließen.
Aber generell, danke für Deine Hilfe. Dabei sein hilft schon. Die letzten beide Stunden hat es gut gepasst. ;D
@Stefan: Danke für die Info.
Morgen früh gibt es ein Update.
Das Attr ctrlStatisticReadings kennt einen neuen Wert "runTimeAvgDayConsumer".
Er gibt die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag aus.
LG
Man kann Dir nicht oft genug "Danke" sagen für deine endlosen STUNDEN (!!) für dieses Projekt. MMn hat das mit einem klassischen Modul für FHEM schon gar nichts mehr zu tun;
Wenn es eine Enduser-freundliche Info geben wird, wie Dein Projekt "standalone/extern" auf einer eigenen Instanz lauffähig ist, werde ich das glaube ich umsetzen. Inzwischen ist dies Modul quasi im Zentrum meines FHEM-Projekts, weil es eben nicht nur "Spielereien" wie schaltbare Lampen, Rolläden o.ä. durchführt, sondern intelligente Steuerungen vorh. PV-Stroms diverser Verbraucher übernimmt, die mir effektiv Kosten einsparen.
Freut mich Dracolein. :)
Ich gebe euch auf jeden Fall eine Info wenn die ersten Schritte für eine remote Fähigkeit vollzogen sind.
Das wird auch nicht mit einem Big Bang passieren, sondern schrittweise. Zum Beispiel wird man zunächst remote Meter integrieren können, dann Inverter usw. Ich muß mich auch erst rantasten wie ich das Ganze praktikabel gestalte.
Und natürlich hänge ich unfassbar mit dem Wiki hinterher. Das weiß ich, aber ich glaube Dokumentationen schreibt keiner von uns sehr gerne. ;)
LG,
Heiko
@DS_Starter
Zitatremote Fähigkeit
Was ist der Vorteil des Vorhabens? Warum auslagern? Was für Gründe gibt es da?
Könnte man doch auch über einen Dummy machen wenn man das benötigen täte.
Ich erkenne den Sinn aber jetzt nicht wirklich. Bitte erhelle doch meine Ahnungslosigkeit.
Die Idee ist folgende...
Stell dir vor es gibt in deinem FHEM Universum verschiedene bzw. verteilte FHEM-Server. D.h. nicht alle deine Meter, Inverter, Batterydev und Consumer befinden sich auf demselben Server.
Du möchtest aber auf einem (dem zentralen Server) oder einer eigenen Instanz SF installieren. Möglicherweise auch aus dem simplen Grund deine FHEM Installation zu strukturieren.
In dem Fall muß sich SF die benötigten Daten aller entfernten Devices beschaffen bzw. auch zu setzen (z.B. Consumer Automatik).
Diese Möglichkeit soll möglichst einfach realisierbar sein.
Natürlich alles optional.
Ja, das verstehe ich schon und erscheint mir auch Sinnvoll.
Aber so aus meiner technischen Sicht müßtest du, je nach Umsetzung, entweder server/clients erstellen. Oder das über fhem2fhem/telnet/http(s) requests etc. realisieren.
Also mit Bordmitteln. Und mit existierenden Mitteln würde es doch jetzt auch schon theoretisch gehen.
Warum das gesondert einpflegen? Was geht über die existierenden Funktionen nicht bzw. wo klemmt da was ?
Nicht falsch verstehen, du kannst das sehr gerne machen. Will da nicht negativ reden oder dir das ausreden.
Ich sehe da nur, bei meinem bescheidenen Wissen, den Grund nich das gesondert einzupflegen.
Ein Grund wäre z.B. das du es dem User vereinfachen willst die Kommunikation zwischen Instanzen zu erleichtern.
Oder aber das es da einen Haken gibt den ich nicht sehe bei den jetzt schon vorhandenen Möglichkeiten.
Und das möchte ich eigentlich nur erfragen.
Moin,
kein Thema, muß mir ja nicht mehr Arbeit als nötig machen. ;)
Vielleicht sitze ich ja auch in meiner Entwicklungsblase fest und habe gerade einen Tunnelblick.
Deswegen beschreibe doch mal bitte aus Anwendersicht wie du mit den aktuell vorhanden Möglichkeiten ein solches Szenario abbilden würdest.
Sowas hilft oft den eigenen Standpunkt neu zu bewerten.
LG
z.B. mit FHEM2FHEM
Ich benutze einen Dummy als Inverterdevice.
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy icon inverter
setstate InverterDummy 2024-05-31 15:22:57 etoday 28.367
setstate InverterDummy 2024-05-31 15:22:57 etotal 15082.030
setstate InverterDummy 2024-05-31 15:22:57 total_pac 9.432
Die raw definition des Dummys lade ich in die zweite fhem Instanz in der ich das reading brauch.
Auf dieser (zweiten) Instanz dublizier ich mir die Readings mit events aus der anderen (ursprünglichen) Instanz mit ..
defmod F2Ffhemtest FHEM2FHEM 333.444.666.777:7072 LOG:InverterDummy
Und blubs habe ich das inverter device vom sateliten/slave/server in der haupt/master/client Instanz.
Das ist doch das was du möchtest bzw. vor hast, oder?
ich verwende MQTTBRIDGE um Inverter/Zähler/Aktoren mit der FHEM-Instanz wo SolarFC läuft zu syncronisieren, nachdem ich mit FHEM2FHEM nicht die besten Erfahrungen gemacht habe (Error-recovery, Probleme nach FHEM-start....).
Das funktioniert problemlos!
Was ich noch suche ist eine Möglichkeit, das SOLARFC Gui vom remote FHEM auf das lokale FHEM zu bringen,
wie z.B in cmdref beschrieben:
... weblink htmlCode { FHEM::SolarForecast::pageAsHtml ('SolCast5', '-', '<argument>') } ..das funktioniert logischerweise nur lokal!
l.g. erwin
Passt alles soweit. Fragen die mir noch durch den Kopf gehen:
Wie wäre ein Reading auf einem remoten Device (z.B. Automatic für einen Consumer) in Gegenrichtung zu setzen ohne sich zu sehr zu verstricken?
Wie wären Attribute entfernter Devices, die man in graphicHeaderOwnspec als Quelle benutzen kann, ins System zu holen?
Ich muß dazu sagen, dass ich momentan für die zweite Frage auch erstmal nur einen vagen Denkansatz habe und noch nicht weiß ob er funktioniert. ;) Vllt. wäre der Aufwand auch zu hoch.
@erwin:
Vielleicht ein Möglichkeit.
Es gibt ein Modul HTTPAPI welches ich gerade als Agent im Auge habe.
Damit könnte man, wenn es auf dem Quellsystem installiert ist, allerhand tun. Zum Beispiel ein get abfragen:
http://<Server>:<Port>/<INFIX>/get?device=SolCast&action=html
Den Output könnte man sicherlich im weblink verwenden.
Nur mal so als Anregung.
LG
Es gibt ja auch noch RFHEM auch zum steuern.
Ich muß gestehen, ich nutze fhem2fhem oder rfhem nicht. Weiß nur das es so erst einmal funktioniert durch tests. Habe aber keine Langzeiterfahrung damit.
Wie schon einst von mir geschrieben über http(s) wäre auch eine option.
Ich erkenne die Sinnhaftigkeit/Notwendigkeit immer noch nicht. Eher sehe ich das Risiko das das Modul noch aufgeblähter wird.
Aber das habe ich ja schon einmal einst erwähnt.
Sinnvoller fänd ich immer noch das Modul zu splitten.
Forecast, Consumption, Consumerplannung, Batteriemanager etc. kleiner Häppchen mit einer gemeinsamen Basis z.B. und diese Module kommunizieren zu lassen (intern oder da eventuell Remote).
Auch fände ich gut wenn du meherer Instanzen des Modules zu einem mergen würdest.
Also solcastapi und openmeteo gibt eine ausgabe für den Forecast. So eine art virtuelle api zusammengesetzt aus mehreren.
Das habe ich mir selber gebastellt und bin mit der PVVorhersage zufriedener im ganzen.
Was nicht heissen soll das die einzelnen nicht gut sind!
Mach was du möchtest und für gut hälst. Ich bin mir sicher das es am Ende funktioniert.
Da es offensichtlich genügend Möglichkeiten über diverse Kommunikationskanäle gibt, stelle ich das Thema zurück und implementiere vllt. nur ein "hidden Feature" für mich in abgespeckter Version. Damit kann ich schnell und einfach von meinem Test-Server aus auf Original-Devices auf dem Produktivsystem zugreifen.
ZitatSinnvoller fänd ich immer noch das Modul zu splitten.
Das wird nicht passieren. Es ist als eine integrative Applikation konzipert. Es gibt Schnittstellen um an alle Daten heranzukommen. Jeder kann sich daraus bedienen und etwas bauen was ihm behagt oder falls etwas fehlt.
Wenn man z.B. eine Consumersteuerung nicht nutzen will, richtet man sie einfach nicht ein. Ist doch ganz einfach.
ZitatAuch fände ich gut wenn du meherer Instanzen des Modules zu einem mergen würdest.
Darüber kann ich mal nachdenken.
@erwin,
zu deinem Thema. Ich habe erfolgreich ein weblink Device in dieser Form definiert:
defmod SolCastRemote weblink iframe http://<Server>:<Port>/fhem?cmd=get%20SolCast%20html
attr SolCastRemote htmlattr width="1300" height="1500"
attr SolCastRemote room Testraum
Funktioniert einwandfrei, auch die Schalter innerhalb des Consumerpanels funktionieren.
Man muß sich nur etwas bezüglich des Webseiten Refresh überlegen damit die weblink-Grafik aktualisiert.
Edit: Habe auf die Schnelle nicht bemerkt dass es zwar funktioniert, aber nicht nur die get-Ausgabe ist sondern die ganze FHEM Webseite.
LG
Ich habe eine neue Version eingecheckt.
Wie angekündigt habe ich begonnen bestimmte Setter in Attribute umzusetzen.
Begonnen habe ich mit currentMeterDev welches in das attr setupMeterDev umgesetzt wurde.
Der ganze Prozess läuft nach einem Restart! automatisch ab.
WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
Wer mag kann die neue V aus meinem contrib ziehen und restarten. Ansonsten morgen früh updaten.
LG,
Heiko
Hallo Forum,
SolarForecast mit Attribute flowGraphicAnimate 1 macht Ärger.
fhem läuft auf einem Fujitsu Futro S740 mit 8GB RAM unter dietpi, also ein mäßig schnelles System.
Jetzt zum Problem.
Sobald das flowGraphicAnimate auf 1 gesetzt wird blockiert der Rechner minutenlang!
Nicht nur einmal sondern zyklisch zwischendurch ist das System dann kurz verfügbar aber immer nur einige Sekunden.
SSH mit putty gibt keine Verbindung, auch nicht über die IP Adresse(pihole).
Alle Webseiten reagieren nicht.
pihole beantwortet kein DNS Anfragen mehr.
-> komplettes Netzwerk daheim steht.
Hat das noch jemand?
Nein, kein Problem.
Das ist übrigens eine SVG-Applikation die auf dem Client im Browser ausgeführt wird, d.h. die Leistungsfähigkeit des FHEM-Servers ist da nicht das Thema.
Vielleicht hilft dieser Hinweis bei der Ursachensuche.
@SaibotRetsevlis
Rufst du FHEMWEB auf dem gleichen Host auf oder extern?
Was hängt denn dann auf dem fhem-rechner? Mal eruiert?
Ich hatte mal ein Problem das ich mir mein ganzes Netzwerk abgeschossen hatte wenn ich in einem Teams-Meeting war.
Das ist ärgerlich wenn man im Kundengespräch rauskachelt wegen sowas.
Hatte Teams in verdacht.
Am Ende war es die Dockingstation die irgendwas macht, sodas die Fritzbox ihren Port dicht macht. War sehr dubios.
Und hatte es nur mit glück gefunden. Indem ich die Dockingstaion direkt an der Fritte hatte, da ich meine Firewall auch in Verdacht hatte die abschmiert.
Da merkte ich aber irgendwann das der Dockingstationrechner nicht mehr kommunizieren konnte. Der Rest vom Netzwerk ging aber noch.
Dann wurde es klarer was da los ist.
Was ich sagen wollte, es gibt Sachen die gibt es garnicht, oder halt manchmal.
Hallo zusammen,
meine PV läuft seit Mitte der Woche- ich rede jetzt mal nicht über den ganzen Regen und die damit verbundene eingeschränkte Produktion...
Ich hab das Modul mal eingerichtet und das sieht soweit gut aus, will damit dann in der Tat das eine oder andere schalten wie auch in den Beispielen im Wiki beschrieben.
Im Moment hab ich noch eine Ferraris Zähler und darf nicht einspeisen- ich denke das geht einige Wochen bis da jemand kommt und was Moderneres reinschraubt. Ich hab im Modul jetzt aber nichts gesehen, wo ich ihm mitteilen könnte, dass ich nichts (bzw es sind 200W eingestellt) einspeisen kann und würde mal annehmen, dass wenn ich es so trotzdem laufen lasse, da nur Mist rauskommt. Hab ich was übersehen, oder muss ich warten bis ich normal Einspeisen kann bis ich das Modul in Betrieb nehme?
Danke
Moin,
das Modul kann man durchaus schon laufen lassen. Bei solchen Gegebenheiten wie bei dir wird bei sonnigen Tagen eine größere Differenz zwischen Prognose und realer Erzeugung auftreten sofern die Erzeugung gedrosselt/vermieden wird damit keine Einspeisung erfolgt.
Bei meiner Anlage gibt es auch einen Teil der nicht einspeist. Durch gewisse Optimierung bei der Batterieladung kann ich bei mir den Fehler minimieren, ansonsten muß ich damit leben da ich im Vorfeld nicht weiß wann eine Abregelung erfolgt und wieviel. Vllt. fällt mir dazu noch etwas zündendes ein.
Bei dir würde ich raten mit
set ... pvCorrectionFactor_Auto noLearning
den Lernmodus auszuschalten solange eine Abregelung möglich ist. Damit würden die (falschen) Erkenntnisse aus dem Lernprozess ausgeschlossen wenn du später den gewünschten Wert für pvCorrectionFactor_Auto einstellst wenn alles normal läuft.
Die Prognose an sich wird dadurch nicht beeinflusst, sie richtet sich nach der gewählten API.
@Mr.X
Erstmal "Hallo" und viel Spass mit der neuen Anlage und dem spannenden Vorhersagen.
Ob du limitiert einspeist ist dem Modul völlig egal.
Du brauchst mindestens 2 Messeinrichtungen um das Modul nutzen zu können. Ein Messmittel am Netzeingang und eines für deine PV-Leistung (meist Daten aus dem Wechselrichter).
Und dann kann es losgehen.
Ich denke allerdings anders als der Modulersteller das es auch mit dem limitieren auf Dauer funktionieren sollte da mit pvCorrectionFactor_Auto auch automatisch Verschattungen ausgebügelt werden. Klar ist die Vorhersage nicht so gut wie ohne. Aber brauchbar anpassen sollte sich das schon lassen könnte ich mir Vorstellen.
Zudem kommt bei wechselnden Lasten über den Tag noch eine weitere Unsicherheit rein. Sofern du aber einen einigermassen geregelten Verbrauch hast sollte es auch so einigermassen funktionieren. Dauert halt etwas länger der Lernprozess.
@DS_Starter
Um das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen für die nächste Stunde auf Consumptionforecast + Gridlimit.
Dazu wird in dem Moment des anpassens(PVforecast) falls das Gridlimit überschritten wird das learning deaktiviert. Bei nicht überschreitung der Einspeiseleistung wird gelernt. Könnte doch klappen.
ZitatIch denke allerdings anders als der Modulersteller das es auch mit dem limitieren auf Dauer funktionieren sollte da mit pvCorrectionFactor_Auto auch automatisch Verschattungen ausgebügelt werden.
Doch, der Meinung von kask bin auch :). Nur für den Anfang würde ich es so machen.
Zitat@DS_Starter
Um das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen für die nächste Stunde auf Consumptionforecast + Gridlimit.
Dazu wird in dem Moment des anpassens(PVforecast) falls das Gridlimit überschritten wird das learning deaktiviert. Bei nicht überschreitung der Einspeiseleistung wird gelernt. Könnte doch klappen.
Das liest sich ganz gut. Allerdings fehlt da noch die Batterie(lade)komponente. Sie geht im Moment des Ladens nicht in der Verbrauch und damit Consumptionforecast ein, vermindert/verhindert aber ein Herunterregeln der Anlage.
Aber der Ansatz an sich sieht nicht so schlecht aus.
Wenn ich mit meinen Umstellungen durch bin können wir das ja nochmal genauer betrachten und testen.
Ich habe eine andere Ladephilosophie wie du.
Was aber für beide Strategien funktionieren sollte wäre folgendes.
Wie wäre es mit einer weiteren Prognose? Die "BatteryUse" anhand der Vergangenheit (Laden.-Endladen).
Ähnlich wie der Consumptionforecast, die wäre allerdings positiv sowie negativ.
Damit könntest du den Limiter(PV-Capacity) auf Consumptionforecast + Gridlimit + BatterieUseforecast einpegeln. Nur so als Gedankengang.
Behalten wir mal im Hinterkopf. Wenn ich den Kopf wieder frei habe, holen wir die ganzen Ansätze und Gedanken nochmal raus. Kannst bis dahin gerne noch etwas sinnieren.
Dauert noch ein bisschen bis ich die ganzen Changes durch habe. Muß mich dabei ziemlich konzentrieren um alles sauber umzusetzen.
ZitatUm das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen ...
Gut das wir darüber gesprochen haben. Unter diesem Aspekt lasse ich nämlich die Setter modulePeakString, moduleAzimuth und moduleDeclination als Konfigurations-Readings bestehen. moduleAzimuth und moduleDeclination unter dem Gesichtspunkt dass es Nachführanlagen gibt die sich dem Sonnenstand entsprechend ausrichten.
@all,
die Umsetzung von Konfigurations-Setter in Attribute ist weiter fortgeschritten.
Umgesetzt ist jetzt currentBatteryDev in attr setupBatteryDev.
Der ganze Prozess läuft nach einem Restart! automatisch ab.
WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.
LG,
Heiko
Danke für euren Input.
Das Modul lief heute schon mal, und da es zunächst doch ziemlich bewölkt war, ist die Batterie erst jetzt gerade kurz vor voll, d.h. bisher keine Abregelung (für morgen ist die Prognose nicht besser, aber die Batterie wird morgen Früh nicht leer sein, d.h. denke da läuft es in die Abregelung, Dienstag dann spätestens laut Wetterbericht). Die größte Unsicherheit scheinen da tatsächlich die Wetterdaten (Bewölkung) zu sein, während ich am Vormittag der Prognose deutlich hinterher war, hab ich am frühen Nachmittag als die Sonne raus kam deutlich aufgeholt- über den Tag sieht es im Moment gar nicht so schlecht aus. Allerdings sind natürlich die Korrekturfaktoren die er da jetzt für morgen annimmt auch nicht realistisch, wenn da nicht wieder genau die Sonne rauskommt, aber ich denke verstanden zu haben, dass sich das dann mit der Zeit alles nivelliert und dass das System eben lernt...
@kask: Die notwendigen Messdaten hab ich alle die das Modul haben will, auch die optionalen, habe ich alles angelegt und sollte passen.
Ich mag die graphische Darstellung des Moduls - toll gemacht.
Bin mir jetzt noch unschlüssig, ob ich wie von DS_Starter vorgeschlagen soll das Learning deaktivieren soll oder nicht... Mit einem "Reset" könnte ich aber nach dem Wegfall der Einspeisebeschränkung ja ohne Probleme wieder von vorne anfangen das System zu trainieren. ISt vermutlich dann der bessere Weg, als alles was er bis dahin gelernt hat dann nach und nach in Richtung der realistischeren Werte zu bewegen. Beim Nachbarn hat es 3 Monate gedauert bis die Stadtwerke den neuen Zähler eingebaut haben, d.h. da muss man vermutlich lange neue Daten füttern, bis es dann passt (daher wäre im Moment meine Tendenz im Moment laufen lassen und dann einen Reset zu machen...)
Nächstes WE kümmer ich mich dann mal um die "Consumer".
Vielen Dank für das Modul
ZitatBin mir jetzt noch unschlüssig, ob ich wie von DS_Starter vorgeschlagen soll das Learning deaktivieren soll oder nicht.
Welche API nimmst du? Je nach API kannst du dir einfach die Rawdefinition des vorhandenen SolarForecast device kopieren und das device umbenennen.
Dazu die korrespondierenden files in /opt/fhem/FHEM/FhemUtils/ mit dem abgeänderten neuen devicenamen kopieren.
Und dann beide Instancen parallel laufen lassen. Einmal ohne einmal mit autocorrection.
Dann kannst du entscheiden was besser passt bei dir.
Das mit der API ist noch ein guter Punkt wo man (ich zumindest) als Anfänger nicht so recht weiß, hab ich keine Empfehlung gefunden. Sind die alle gleichwertig? Ich hab einfach mal OpenMeteoDWD genommen- weil es hier bei mir in der Nähe eine Messstation gibt die die Rad1h Werte zur Verfügung stellt...
Nunja, alle gleich!? Kann man sehen wie man will. Die einen funktionieren die anderen auch, nur nicht immer und bei jedem.
Das mußt du für dich rausfinden was am besten bei dir funktioniert, sofern du die API überhaupt nutzen kannst.
Die einen sind frei die anderen brauchen einen Account.
Eine brauch auch bestimmte Hardware damit diese geht (VictronVRM).
Ich denke OpenMeteoDWD ist schon ein guter start. Da auch mal die OpenMeteoEnsemble testen.
Für die SolCastAPI brauchst du bekanntlich einen Acccount da bekommst du max 10 Abfrage am Tag jetzt nur noch. Bei mehrerern Strings reduziert sich das ganze naürlich dann.
Die VictronVRM läuft wohl auch mit der SolCastAPI bzw. nutzt diese Angaben. Ich habe da denoch manchmal große Unterschiede.
Die DWD kann auch ganz brauchbar sein. Vermutlich liefert die dir auch Rad1H Werte da OpenMeteoDWD auch darauf abfeuert.
Bei mir bringen diese auch unterschiedliche Vorhersagen. Die Differenz beider zueinander ist nicht so groß. Aber vorhanden.
Die OpenMeteoWorld liefert bei mir 99% das gleiche Wie die OpenMeteoDWD. Vieleicht ist es bei dir anders.
Mit der ForecastSolarAPI bin ich so garnicht zufrieden. Musst du mal testen ob es bei dir vieleicht brauchbar ist.
Das Ranking bei mir/für mich ist:
sehr gut: SolCastAPI (mehrere Strings, Aber 2x50 Abfragen weil alte accounts. Wichtig ist die rooftops bei Solcast selbst richtig zu parametrieren!)
gut: OpenMeteoEnsemble
gut aber etwas schlechter: VictronVRM,DWD & restlichen OpenMeteo's
Reinfall: ForecastSolarAPI
Jetzt ist es auch so das bei unbeständigem Wetter bei mir die DWD-basierten besser treffen.
Das ist alles nicht so einfach ;)
Ich habe alle API's parallel laufen und bastel mir einen Wert aus allen API's dividiert durch die Anzahl.
Dadurch habe ich im ganzen eine genauere Prognose.
Man darf nicht vergessen das diese Prognose auch DWD lastig ist, da 3 (DWD, OpenMeteoDWD, OpenMeteoWorld) der 6 (eigentlich 7 aber die ForecastSolarAPI verwurste ich da nicht mit) API's ziemlich identische Werte liefern. Was bei mir anscheinend sehr gut am Ende passt.
@all,
ein weiterer Schritt ist vorgenommen.
Umgesetzt ist jetzt currentInverterDev in attr setupInverterDev.
Der ganze Prozess läuft nach einem Restart! automatisch ab.
WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
Außerdem wird nach dem Update der Start der Autokorrektur technisch bedingt um 2h verzögert in der Grafik angezeigt. Das ist in dem Fall normal und kein Grund zur Beunruhigung. Nach 2h wird der Prozeß normal fortgesetzt.
Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.
Hallo zusammen,
brauche eure Hilfe, aus irgendeinem Grund wird bei mir der Consumer01 nicht mehr eingeplant:
Screenshot 2024-06-05 at 07.42.01.png
Screenshot 2024-06-05 at 07.54.09.png
Die Uhr bleibt grau - wenn ich draufklicke, wird der Verbraucher sofort eingeplant - aber das sollte doch automatisch passieren?
Hier meine Config:
defmod solarforecast SolarForecast
attr solarforecast consumer01 MQTT2_poolpump interruptable=1 auto=automatic icon=sani_garden_pump@blue mintime=SunPath type=other power=600 locktime=60:600 on=on off=off pcurr=ENERGY_Power_1:W etotal=ENERGY_Total:kWh
attr solarforecast consumer02 modbus_pool_heatpump interruptable=1 auto=automatic icon=sani_heating_heatpump@blue type=other mintime=SunPath power=1200 locktime=0:600 on="c000-power 1" off="c000-power 0" swstate=c000-power:1:0 pcurr=ENERGY_Power:W
attr solarforecast ctrlWeatherDev1 OpenMeteoDWD-API
attr solarforecast ctrlWeatherDev2 DWD
Current_AutarkyRate 100 %
Current_Consumption 259 W
Current_GridConsumption 0 W
Current_GridFeedIn 773 W
Current_PV 1032 W
Current_SelfConsumption 259 W
Current_SelfConsumptionRate 25 %
Current_Surplus 773 W
LastHourGridconsumptionReal 119 Wh
LastHourPVforecast 348 Wh
LastHourPVreal 310 Wh
NextHours_Sum01_PVforecast 2225 Wh
NextHours_Sum02_PVforecast 5759 Wh
NextHours_Sum03_PVforecast 10192 Wh
NextHours_Sum04_ConsumptionForecast 4906 Wh
NextHours_Sum04_PVforecast 15076 Wh
RestOfDayConsumptionForecast 223341 Wh
RestOfDayPVforecast 43484 Wh
Today_Hour01_GridConsumption 563 Wh
Today_Hour01_GridFeedIn 0 Wh
Today_Hour01_PVreal 0 Wh
Today_Hour02_GridConsumption 337 Wh
Today_Hour02_GridFeedIn 0 Wh
Today_Hour02_PVreal 0 Wh
Today_Hour03_GridConsumption 275 Wh
Today_Hour03_GridFeedIn 0 Wh
Today_Hour03_PVreal 10 Wh
Today_Hour04_GridConsumption 345 Wh
Today_Hour04_GridFeedIn 0 Wh
Today_Hour04_PVreal 0 Wh
Today_Hour05_GridConsumption 317 Wh
Today_Hour05_GridFeedIn 0 Wh
Today_Hour05_PVreal 10 Wh
Today_Hour06_GridConsumption 289 Wh
Today_Hour06_GridFeedIn 0 Wh
Today_Hour06_PVforecast 60 Wh
Today_Hour06_PVreal 50 Wh
Today_Hour07_GridConsumption 119 Wh
Today_Hour07_GridFeedIn 80 Wh
Today_Hour07_PVforecast 348 Wh
Today_Hour07_PVreal 310 Wh
Today_Hour08_GridConsumption 0 Wh
Today_Hour08_GridFeedIn 421 Wh
Today_Hour08_PVforecast 1125 Wh
Today_Hour08_PVreal 660 Wh
Today_Hour09_PVforecast 2530 Wh
Today_Hour10_PVforecast 3811 Wh
Today_Hour11_PVforecast 4605 Wh
Today_Hour12_PVforecast 4962 Wh
Today_Hour13_PVforecast 4806 Wh
Today_Hour14_PVforecast 5265 Wh
Today_Hour15_PVforecast 5125 Wh
Today_Hour16_PVforecast 4128 Wh
Today_Hour17_PVforecast 3689 Wh
Today_Hour18_PVforecast 2402 Wh
Today_Hour19_PVforecast 1355 Wh
Today_Hour20_PVforecast 456 Wh
Today_Hour21_PVforecast 107 Wh
Today_MaxPVforecast 5265 Wh
Today_MaxPVforecastTime 2024-06-05 13:00:00
Today_PVforecast 44774 Wh
Today_PVreal 1040 Wh
Today_SunRise 05:15
Today_SunSet 21:09
Tomorrow_ConsumptionForecast 214946 Wh
Tomorrow_PVforecast 42830 Wh
Tomorrow_SunRise 05:14
Tomorrow_SunSet 21:10
consumer01 name='MQTT2_poolpump' state='unknown' mode='can' planningstate='stopping'
consumer01_currentPower 0 W
consumer01_planned_start 04.06.2024 14:04:35
consumer01_planned_stop 04.06.2024 21:08:00
consumer02 name='modbus_pool_heatpump' state='off' mode='can' planningstate='planned'
consumer02_currentPower 7 W
consumer02_planned_start 05.06.2024 07:45:05
consumer02_planned_stop 05.06.2024 23:39:05
currentInverterDev modbus_solarcounter pv=Power_Total:W etotal=kWh_Total:kWh capacity=7960
currentMeterDev MQTT2_esp8266_0811E8 gcon=Aktuelle_Momentanwirkleistung:W contotal=Zaehlwerk_positive_Wirkenergie:Wh gfeedin=-gcon feedtotal=1-0_2-8-0_255_value:Wh conprice=0.225:€ feedprice=0.082:€
currentRadiationAPI OpenMeteoDWD-API
inverterStrings main
moduleAzimuth main=-30
moduleDeclination main=15
modulePeakString main=8
nextCycletime 07:47:25
nextRadiationAPICall nach 05.06.2024 08:01:16
state wrote cachefile solcastapi successfully
Bin für jeden Tipp dankbar.
LG Texel
Moin texel,
der Status des Consumer01 ist "unknown":
consumer01 name='MQTT2_poolpump' state='unknown'
Bedeutet, das Modul erkennt den state von MQTT2_poolpump nicht. Da der Key swstate nicht gesetzt ist, zieht der default state=on oder state=off zur Erkennung. Das matched nicht mit dem tatsächlichen Inhalt des Readings "state" von MQTT2_poolpump.
Das müsstest überprüfen und ggf. anpassen bzw. den Fehler im state von MQTT2_poolpump beseitigen.
Moin, danke für die schnelle Antwort. Das ist seltsam, weil das MQTT device als readiung "state" enthält und auch on/off entsrpechend einträgt .. aber ich habs trotzdem beim Consumer01 ergänzt:
MQTT2_poolpump interruptable=1 auto=automatic icon=sani_garden_pump@blue mintime=SunPath type=other power=600 locktime=60:600 on=on off=off swstate=state:on:off pcurr=ENERGY_Power_1:W etotal=ENERGY_Total:kWh
Die Uhr war nach dem speichern immer noch "grau". Gibt es eine Möglichkeit einen "refresh" zu machen, so dass alles neu berechnet wird für den Tag und dann hoffentlich auch die Uhr auf gelb geht?
Lieben Dank! Texel
Ein
set ... consumerNewPlanning <Verbrauchernummer>
sollte helfen.
Ich würde aber empfehlen, den Key so zu schreiben:
swstate=state:.*on.*:.*off.*
Manchmal verstecken sich Leer- oder nicht sichtbare Steuerzeichen in dem Reading was den Match verhindern könnte. Kommt auf den Versuch an.
@all,
ein weiterer Schritt ist vorgenommen.
Umgesetzt ist jetzt der Setter inverterStrings in Attr setupInverterStrings.
Der ganze Prozess läuft nach einem Restart! automatisch ab.
WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
Weiterhin habe ich die Berechnung von ctrlGenPVdeviation=continuously überarbeitet. Ich bin der Ansicht den laufenden Status der Abweichung nun genauer entsprechend der Realität zu bestimmen.
Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.
LG,
Heiko
Hallo Heiko,
die Hilfe bei der Pflege des neuen Attributs stimmt nicht. Es wird die zu setupInverterDev angezeigt. Ist mir nur zufällig aufgefallen, weil ich über die Syntax (Trennung mit Komma) gestolpert bin und daraufhin mal reingeschaut hatte.
Viel Grüße
Thomas
Hallo Thomas,
danke für die Info.
Kann ich bei mir bestätigen, allerdings ist es im Code der Hilfe korrekt hinterlegt.
Das ist interessant. Möglicherweise ein Problem für Rudolf König (FHEMWEB Javascript Finding).
Ich denke ich melde es ihm mal.
Grüße,
Heiko
@Thomas,
habe den Fehler gefunden und gefixt. Kannst die V nochmal laden und die Lösung verfizieren.
LG
@Heiko: Ja, jetzt passt es.
Zitat von: DS_Starter am 05 Juni 2024, 10:37:29Ein
set ... consumerNewPlanning <Verbrauchernummer>
sollte helfen.
Ich würde aber empfehlen, den Key so zu schreiben:
swstate=state:.*on.*:.*off.*
Manchmal verstecken sich Leer- oder nicht sichtbare Steuerzeichen in dem Reading was den Match verhindern könnte. Kommt auf den Versuch an.
Das war es wohl :) nun funktioniert alles und wurde heute richtig eingeplant. Lieben Dank!!
Heute morgen war mein Server down.
Ich betreibe Fhem im Docker Container!
Hier die letzten Zeilen im Log:
2024.06.08 00:02:02.031 1: SolarForecast - WARNING - Attribute ctrlBatSocManagement is active, but the required key 'cap' is not setup in setupBatteryDev. Exit.
Illegal division by zero at ./FHEM/76_SolarForecast.pm line 10627.
2024.06.08 00:02:05.075 1: HMCCURPCPROC [d_rpc178070VirtualDevices] RPC server CB9292178080178070 stopped handling connections. PID=38614 run=-1
2024.06.08 00:02:05.095 1: HMCCURPCPROC [d_rpc178070VirtualDevices] Parent process (FHEM,PID=38125) not running. Shutting down RPC server process CB9292178080178070.
2024.06.08 00:02:05.121 1: HMCCURPCPROC [d_rpc178070VirtualDevices] Deregistering RPC server http://192.168.178.80:14702/fh9292 with ID CB9292178080178070 at http://192.168.178.70:9292/groups
2024.06.08 00:02:05.252 1: HMCCURPCPROC [d_rpc178070VirtualDevices] FHEM will be restarted automatically if restart is enabled in system.d configuration.
2024.06.08 00:02:06.526 1: HMCCURPCPROC [d_rpc178070BidCos_RF] RPC server CB2001178080178070 stopped handling connections. PID=38613 run=-1
2024.06.08 00:02:06.532 1: HMCCURPCPROC [d_rpc178070BidCos_RF] Parent process (FHEM,PID=38125) not running. Shutting down RPC server process CB2001178080178070.
2024.06.08 00:02:06.539 1: HMCCURPCPROC [d_rpc178070BidCos_RF] Deregistering RPC server http://192.168.178.80:7411/fh2001 with ID CB2001178080178070 at http://192.168.178.70:2001
2024.06.08 00:02:06.565 1: HMCCURPCPROC [d_rpc178070BidCos_RF] FHEM will be restarted automatically if restart is enabled in system.d configuration.
2024.06.08 00:02:06.839 1: HMCCURPCPROC [d_rpc178070HmIP_RF] RPC server CB2010178080178070 stopped handling connections. PID=38612 run=-1
2024.06.08 00:02:06.842 1: HMCCURPCPROC [d_rpc178070HmIP_RF] Parent process (FHEM,PID=38125) not running. Shutting down RPC server process CB2010178080178070.
2024.06.08 00:02:06.855 1: HMCCURPCPROC [d_rpc178070HmIP_RF] Deregistering RPC server http://192.168.178.80:7420/fh2010 with ID CB2010178080178070 at http://192.168.178.70:2010
2024.06.08 00:02:06.889 1: HMCCURPCPROC [d_rpc178070HmIP_RF] FHEM will be restarted automatically if restart is enabled in system.d configuration.
Hier die bemängelte konfig von setupBatteryDev:
attr SolarForecast setupBatteryDev hame_energy pin=Solar_1_input_power:W pout=Output_power_1:W charge=Battery_percentage cap=2240:Wh
Was habe ich falsch gemacht?
Grüße
Reiner
Moin,
ZitatWas habe ich falsch gemacht?
Wenn man cap als numerischen Wert direkt angibt, dann nur so:
cap=2240
ohne Einheit.
Den Grund des Absturzes ('Illegal division by zero') muß ich im Modul anfangen.
LG,
Heiko
Der Fix ist eingecheckt und für Sofort-Nutzer auch aus meinm contrib downloadbar.
Hallo Heiko,
wir hatten das Thema schon einmal weiter oben im Thread (während deiner kurzen Abwesenheit) - aber ich möchte es nochmal andiskutieren.
Für mich sieht es so aus, daß das Modul ( übrigens Weltklasse ;D ) zeimlich genau um Mitternacht für etwa 6 Minuten meine CPU komplett auslastet und dabei die FHEM Hauptschleife praktisch komplett blockiert ( Lichtschalter funktionieren nicht mehr, etc etc ). Problem ist, daß ich drei SolarForecast Instanzen parallel betreibe (alle DWD basiert) - somit summiert sich der "Blackout" auf ca 19 Minuten...
Hier ein Auszug aus dem FHEM Log:
2024.06.07 23:59:24 1: [Shelly_status] Device s25Sw01 has Error 'not connected (no route)', state is set to 'Error: Network'
2024.06.07 23:59:30 1: Timeout for VCONTROL300_DoUpdate reached, terminated process 2824736
2024.06.07 23:59:30 2: VCONTROL300: TCP connection closed
2024.06.07 23:59:38 3: [Shelly_status] s25Sw01: Error in callback, update in 10 seconds
2024.06.07 23:59:38 1: [Shelly_status] Device s25Sw01 has Error 'not connected (no route)', state is set to 'Error: Network'
2024.06.07 23:59:51 3: [Shelly_status] s25Sw01: Error in callback, update in 10 seconds
2024.06.07 23:59:51 1: [Shelly_status] Device s25Sw01 has Error 'not connected (no route)', state is set to 'Error: Network'
2024.06.08 00:00:01 3: TelegramBot_Callback my_TelegramBot: Digest: Number of poll failures on 2024-06-07 is :7:
2024.06.08 00:06:27 1: [Freezemon] fm: Long function call detected ReadyFn:PV_OpenMeteo - 383.791431 seconds
2024.06.08 00:12:46 1: [Freezemon] fm: Long function call detected ReadyFn:PV_forecast - 378.749563 seconds
2024.06.08 00:19:01 1: [Freezemon] fm: Long function call detected ReadyFn:PV_OM_Ensemble - 374.404332 seconds
2024.06.08 00:19:01 1: [Freezemon] fm: possible freeze starting at 00:00:05, delay is 1136.043 possibly caused by: fn-ReadyFn(PV_OpenMeteo) fn-ReadyFn(PV_forecast) fn-ReadyFn(PV_OM_Ensemble)
2024.06.08 00:19:01 3: [Shelly_status] s25Sw01: Error in callback, update in 10 seconds
2024.06.08 00:19:01 1: [Shelly_status] Device s25Sw01 has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2024.06.08 00:19:01 3: mqttGarage: mqttGarage_100.64.2.106_49588/mqttHome left us (keepalive check)
2024.06.08 00:19:01 3: my_MQTT2: my_MQTT2_192.168.8.153_23948/DVES_375AB5 left us (keepalive check)
2024.06.08 00:19:01 3: my_MQTT2: my_MQTT2_192.168.8.160_27315/shellyuni-98CDAC2527EE left us (keepalive check)
2024.06.08 00:19:02 3: HMinfo hm get:update :
2024.06.08 00:19:02 3: CUL_HM set ActionDetector update noArg
2024.06.08 00:19:02 3: CUL_HM set vccu update noArg
2024.06.08 00:19:06 1: [YAAHM_updater] on device myHA called for this day
2024.06.08 00:19:06 3: Login denied via mqttGarage
2024.06.08 00:19:06 4: Connection accepted from mqttGarage_100.64.2.106_45266
2024.06.08 00:19:06 3: [Shelly_status] s1Switch01: Error in callback, update in 60 seconds
2024.06.08 00:19:06 1: [Shelly_status] Device s1Switch01 has Error 'not connected (no route)', state is set to 'Error: Network'
Man sieht ganz gut anhand der sonst alle 10 Sekunden ins Log trudelnden Shelly_status Meldungen, dass für 19 Minuten ab Mitternacht gar nichts geht.
Der FHEM Server läuft PROXMOX virtualisiert auf einem recht potenten (auf CORE i8 Basis) NUC - zu 100% ausgelastet ist während des Problems nur eine der beiden vCPUs. Und natürlich zieht der FHEM perl Prozess diese Last.
Hast Du eine Idee, was da passiert oder wie ich es besser eingrenzen kann? Mir würde eigentlich schon eine Bestätigung genügen, daß andere das Problem nicht haben. DNS Hänger würde ich als Ursache eigentlich ausschliessen - das FHEM global Attribut dnsServer habe ich gepflegt.
Tobi
@tpm88
Ich habe das problem so nicht.
@Reinschki
Um 02:02 kommt der division fehler. Das last fhem aber nicht neustarten.
Ist ja auch nur eine warnung. Wenn es das wirklich wäre dann wäre die meldung vermutlich auch nicht da. Da das ja den process ins trudelt bring und dann wäre ein log meist auch nicht möglich. Da kommst du nur mit Debugging weiter. Und da sehe ich eher das problem bei HMCCURPCPROC. Un 02:05 eiert fhem ja mit dem device rum.
Hallo Tobi,
habe so ein Problem auch nicht. Bei mir laufen zweimal 5 SF Instanzen auf verschiedenen Servern parallel. (NUC mit VMWare)
Um Mitternacht werden mit einem Versatz von einigen Sekunden/Minuten Aufräumarbeiten wie Löschen von Readings, Löschen von Daten interner Strukturen etc. durchgeführt. Diese Dinge werden in 4 bzw. 5 verschiedenen Tasks unterteilt ausgeführt.
Du kannst kurz vor Mitternacht in deinen SF Devices verbose=4 setzen. Dann kommen Meldungen wie:
<name> - Daily special tasks - Task 1 finished
Damit kann man eingrenzen in welchem Task es bei dir vorkommt. Ich kann dann schauen was in dem Task drinsteckt.
Lässt du Freezemon bei dir ständig mitlaufen?
Wenn ja, würde ich das abschalten und nur im speziellen Bedarfsfall zur Analyse verwenden um eventuelle Seiteneffekte auszuschließen.
Natürlich trat gestern Nacht die beschriebene Blockade nicht auf.
Geändert hatte ich vorher:
- FHEM update & restart
- freezemon deaktiviert
- at für verbose 4 im Zeitraum um Mitternacht definiert
Die special Tasks sind aus meiner Sicht unkritisch:
root@pvefhem01:/opt/fhem/log# grep -a "Daily special tasks" fhem-2024-06.log
2024.06.09 00:00:04 4: PV_forecast - Daily special tasks - Task 1 started
2024.06.09 00:00:14 4: PV_forecast - Daily special tasks - Task 1 finished
2024.06.09 00:00:14 4: PV_OM_Ensemble - Daily special tasks - Task 1 started
2024.06.09 00:00:24 4: PV_OM_Ensemble - Daily special tasks - Task 1 finished
2024.06.09 00:00:24 4: PV_OpenMeteo - Daily special tasks - Task 1 started
2024.06.09 00:00:34 4: PV_OpenMeteo - Daily special tasks - Task 1 finished
2024.06.09 00:02:05 4: PV_forecast - Daily special tasks - Task 2 started
2024.06.09 00:02:05 4: PV_forecast - Daily special tasks - Task 2 finished
2024.06.09 00:02:05 4: PV_OM_Ensemble - Daily special tasks - Task 2 started
2024.06.09 00:02:05 4: PV_OM_Ensemble - Daily special tasks - Task 2 finished
2024.06.09 00:02:05 4: PV_OpenMeteo - Daily special tasks - Task 2 started
2024.06.09 00:02:05 4: PV_OpenMeteo - Daily special tasks - Task 2 finished
2024.06.09 00:05:05 4: PV_forecast - Daily special tasks - Task 3 started
2024.06.09 00:05:05 4: PV_forecast - Daily special tasks - Task 3 finished
2024.06.09 00:05:05 4: PV_OM_Ensemble - Daily special tasks - Task 3 started
2024.06.09 00:05:05 4: PV_OM_Ensemble - Daily special tasks - Task 3 finished
2024.06.09 00:05:05 4: PV_OpenMeteo - Daily special tasks - Task 3 started
2024.06.09 00:05:05 4: PV_OpenMeteo - Daily special tasks - Task 3 finished
2024.06.09 00:09:06 4: PV_forecast - Daily special tasks - Task 4 started
2024.06.09 00:09:06 4: PV_forecast - Daily special tasks - Task 4 finished
2024.06.09 00:09:06 4: PV_OM_Ensemble - Daily special tasks - Task 4 started
2024.06.09 00:09:06 4: PV_OM_Ensemble - Daily special tasks - Task 4 finished
2024.06.09 00:09:06 4: PV_OpenMeteo - Daily special tasks - Task 4 started
2024.06.09 00:09:06 4: PV_OpenMeteo - Daily special tasks - Task 4 finished
Ich lass den at für verbose 4 trotzdem mal ein paar Tage aktiv...
Danke
Tobi
Ja das sieht io aus.
Ich persönlich tippe ganz stark auf einen negativen Zusammenhang mit freezemon.
Ein direktes Auftreten nach Reaktivierung von freezemon wäre die Verifizierung dieser Einschätzung.
Grüße,
Heiko
Hallo,
ich musste leider meinen RasPi mit FHEM neu aufsetzen, konnte allerdings die fhem.cfg wiederverwenden.
Allerdings ist mein Solarforecast Device weg ::)
(wo) sind die Daten auf dem RasPi gespeichert und könnten somit wiederhergestellt werden?
Grüße,
Dieter
Hallo Dieter,
zu diesem Thema habe ich einen Wiki Artikel (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Backup_und_Wiederherstellung_der_Moduldaten) geschrieben.
Die einzelnen Schritte zur Wiederherstellung sind in dem Beitrag beschrieben:
Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:
1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration
2. stoppen von FHEM
3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
4. starten von FHEM (bestimmte Daten werden automatisch importiert)
5. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen
LG
Danke Heiko,
gilt das (nur) für die bisher erfassten Werte oder auch für die Defintion des Device samt seiner Attribute und Readings?
Gruß,
Dieter
Durch das Restore "plantConfiguration restore" werden die eingestellten Konfigurations-Readings und Attribute (Consumer etc.) wiederhergestellt.
Das Device an sich muß zunächst "raw" (Punkt 1) definiert werden damit der Restore ausgeführt werden kann.
Nun hatte ich bei den letzten Releases diverse Readings in Attribute gewandelt. Wenn du immer fleißig upgedated hast, sollte die Sicherung von gestern z.B. passgenau sein.
Hallo,
angeregt durch das Beispiel im Wiki
interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2 würde ich in der derzeitigen kalten Übergangszeit gerne eine Elektroheizung bei Erreichen einer measured-temp eines Homematic Wandthermostat HM-TC-IT-WM-W-EU abschalten und nach Unterschreiten der measured-temp wieder einschalten. Da die Zentralheizung aber schon abgeschaltet ist, steht zur Schonung der Ventile die desired-Temp auf "off". Ich würde daher gerne auf das userReadings diff-temp aus dem Beispiel verzichten und stattdessen eine feste Wunschtemperatur von sagen wir mal 23° mit einer Hysterese von 0.2 vorgeben. Leider habe ich aber keine Ahnung von Regex und Perl und kann das nicht umsetzen.
interruptable=Thermostat_Arbeitszimmer_Climate:measured-temp:23.0:0.2 ?????Vielleicht kann mir ja jemand den code etwas anpassen?
Vielen Dank
oelidoc
So würde der Consumer ab 23.2 (bis 59.9) abschalten:
interruptable=Thermostat_Arbeitszimmer_Climate:measured-temp:(2[3-9]|[3-5][0-9])\.[0-9]:0.2
Enschalten würde er unter 23.0.
Ich verwende zur Prüfung der Regex https://regex101.com/. Eine Hysterese muß man natürlich simulieren durch entsprechende Werteeingabe.
Erläuterung zur Selbsthilfe. Der Regex matched (ist wahr) wenn
- die erste Ziffer eine 2 ist UND die zweite Ziffer eine 3 bis 9 gefolgt von einem Punkt und der Ziffer 0-9
(also 23.0, 23.1 ... 23.9, 24.(0 ... 9), 25..., 26...., 29.9
ODER (durch das '|' bedingt)
- die erste Ziffer eine 3 - 5 ist, die zweite eine 0 - 9 ist gefolgt von einem Punkt und der Ziffer 0-9
(also 30.0, 30.1...9, 31.0..9, ... 59.9)
Vielleicht ist es dadurch verständlicher.
Hallo Heiko,
vielen Dank für den code.
Zitat von: DS_Starter am 11 Juni 2024, 17:47:38Vielleicht ist es dadurch verständlicher.
ja, so ist es für mich gut verständlich bzw. nachvollziehbar! Leider reichen aber meine Kenntnisse überhaupt nicht aus, sowas selber zu schreiben. Und ich fürchte, ich bin auch zu alt, das noch zu lernen. Ich habe in meiner gesamten akademischen Ausbildung keinen Computer gesehen und mir später am PC alles selber beigebracht. Programmiersprachen sind für mich aber Bücher mit sieben Siegeln geblieben. Alle Versuche, z.B Perl zu verstehen, habe ich frustriert ad acta gelegt. Ich könnte nicht mal sagen, was für eine Sprache du in deinem Beispiel benutzt hast... :'(
Insofern bin ich dir sehr dankbar, dass du mir den code zur Verfügung stellst und auch noch erklärst. Das ist in Foren nicht immer üblich, oft wird man darauf verwiesen, sich das fehlende Wissen doch selbst anzueignen. Das geht aber m.E. ab einem gewissen Alter, und wenn man anderweitig beruflich und familiär voll beschäftigt ist, nicht mehr so ohne weiteres.
Also: Chapeau und vielen Dank für deine unermüdliche Hilfsbereitschaft und das tolle Modul!
Grüße
oelidoc
ZitatIch könnte nicht mal sagen, was für eine Sprache du in deinem Beispiel benutzt hast...
Naja das ist keine Sprache sondern ein regulärer Ausdruck (Regex). Der ist unabhäbgig von einer Sprache und gilt in Perl als auch in anderen Sprachen.
Ich bin übrigens auch Autodidakt und keinesfalls Programmierer. Also nicht aufgeben, auch kleine Schritte führen irgendwann zum Ziel :)
Ich habe mir auch mal ein Buch über Reguläre Ausdrücke gekauft um es besser zu verstehen. Bin da auch kein Profi.
LG
Zitat von: DS_Starter am 11 Juni 2024, 19:40:28Bin da auch kein Profi.
Na das nenn ich mal eine gepflegte Untertreibung ;D
LG
oelidoc
Hallo,
habe mal mit der Verbrauchersteuerung ein wenig rumgespielt. Meine Idee ist es die Leistung, die ich normalerweise einspeisen würde in einem Getränkekühlschrank zu verbrauchen.
Ich habe jedoch nur ein Balkonkraftwerk mit max. 750W. Die Einspeisung ist auch recht gering und reicht vmtl. nicht wirklich für den Kühlschrank.
Die Einspeisung pro Tag ist ca. 0 bis max. 2KW (Urlaub).
Den Consumer habe ich so eingestellt:
Steckdose2
icon=fridge
type=other
power=100
mode=can
on=on
off=off
pcurr=power:W:0
auto=automatic
swstate=state:on:off
etotal=consumption:Wh:0
interruptable=1
locktime=300
Wenn ich das nun beobachte, geht der Kühlschrank ab und zu mal an, aber nur sehr kurz bzw. gleich wieder aus. Machen die Einstellungen Sinn?
Danke, Jens
ZitatMachen die Einstellungen Sinn?
In dieser Form vermutlich nicht.
Das "Problem" ist der wahrscheinlich häufig vorhandene/nicht vorhandene Überschuß. Ist der Verbraucher gestartet, unterbricht ein nicht vorhandener Überschuß den Verbraucher sofort und startet ihn erst wieder nach 5 Minuten sofern zu diesem Zeitpunkt Überschuß wieder vorhanden ist.
Ich hätte die Idee power=0 zu setzen um die Schaltung zunächst von einem Überschuß zu entkoppeln. Die Einplanung würde ich mit mintime=SunPath über den gesammten Sonnentag vornehmen lassen.
Dann würde ich swoncond verwenden um das erste Einschalten zu veranlassen, d.h. wenn die in diesem Key angegebene Bedingung erfüllt ist, erfolgt das Starten des Consumers innerhalb der Einplanungszeit. Das könnte das erste Vorhandensein eines Überschusses sein (Reading Current_Surplus).
Damit der nun laufende Kühlschrank nicht bei jeder kleinen Überschußänderung an bzw. ausgeht, würde ich den Key
interruptable=Device:Reading:Regex[:Hysterese]
verwenden, um den Kühlschrank erst bei Über- bzw. Unterschreiten eines Readingwertes (Differenz zw. Verbrauch und Einspeisung) zu schalten. Die Differenz könnte in einem Userreading aus Current_GridConsumption - Current_GridFeedIn gebildet werden. Ist die Differenz entsprechend hoch, liegt ein Bezug X vor und der Kühlschrank wird über interruptable unterbrochen. Liegt Überschuß vor, d.h. die Differenz ist hinreichend _negativ_, wird der Kühlschrank wieder eingeschaltet.
locktime kann man zusätzlich verwenden. Dann würde ich allerdings locktime=300:300 setzen damit auch nach dem Einschalten ein zu schnelles Ausschalten verhindert wird.
Das alles soll als Anregung dienen. Es gibt viele Kombinationsmöglichkeiten, z.B. Readings mit dem Setter powerTrigger erstellen zu lassen und sie über Consumer Keys auswerten lassen.
Danke Dir, ich werde mal versuchen das umzusetzen.
Zitat von: DS_Starter am 09 Juni 2024, 19:31:03Durch das Restore "plantConfiguration restore" werden die eingestellten Konfigurations-Readings und Attribute (Consumer etc.) wiederhergestellt.
Das Device an sich muß zunächst "raw" (Punkt 1) definiert werden damit der Restore ausgeführt werden kann.
Nun hatte ich bei den letzten Releases diverse Readings in Attribute gewandelt. Wenn du immer fleißig upgedated hast, sollte die Sicherung von gestern z.B. passgenau sein.
Super Heiko,
konnte mein System perfekt auf den Stand vor dem restore zurücksetzen, hat zwar einen Tag gedauert, bis sich die Werte aktualisiert haben, aber jetzt läuft es wieder.
Sonnige Grüße
Dieter
Hallo Heiko,
könntest Du mir bitte noch mal ein paar Fragen beantworten, die mich vielleicht auf der Suche der Ursache für die Abweichungen bei mir helfen?
1. Wenn es heißt "Die automatische Vorhersagekorrektur ist lernend und benötigt Zeit um die Korrekturwerte zu optimieren.", von welcher Zeit reden wir da (ungefähr, Tage, Woche, Monate)? Oder anders gefragt, welcher Zeitraum wird überhaupt berücksichtigt? Optimieren heißt ja, dass die Werte besser werden, aber irgendein Wert sollte nach dem ersten Lauf da sein?
2. Beim Beobachten sind mir die Readings "pvCorrectionFactor_xx" aufgefallen. Bei Nutzung der Automatik sind die nicht ständig gefüllt, richtig? Sie werden täglich bis zur aktuellen Stunde neu eingetragen, die anderen sind jeweils leer (zumindest in der Anzeige)?
Wenn ich dann so etwas sehe, was bedeutet "Days in range: 1"? Der eine wäre dann der aktuelle Tag und daher der "old Factor" gleich 1. Aber warum und warum so unterschiedlich für verschiedene Stunden?
nextCycletime 14:38:00 10.06.2024 14:36
nextRadiationAPICall nach 10.06.2024 14:42:31 10.06.2024 14:27
pvCorrectionFactor_07 0.59 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 45, Days in range: 1) 10.06.2024 07:00
pvCorrectionFactor_07_autocalc done 10.06.2024 07:00
pvCorrectionFactor_08 0.57 (automatic - old factor: 1, Sun Alt range: 20, Cloud range: 30, Days in range: 1) 10.06.2024 08:00
pvCorrectionFactor_08_autocalc done 10.06.2024 08:00
pvCorrectionFactor_09 0.44 (automatic - old factor: 0.58, Sun Alt range: 30, Cloud range: 100, Days in range: 5) 10.06.2024 09:00
pvCorrectionFactor_09_autocalc done 10.06.2024 09:00
pvCorrectionFactor_10 0.24 (automatic - old factor: 0.22, Sun Alt range: 35, Cloud range: 00, Days in range: 5) 10.06.2024 10:00
pvCorrectionFactor_10_autocalc done 10.06.2024 10:00
pvCorrectionFactor_11 0.57 (automatic - old factor: 1, Sun Alt range: 45, Cloud range: 10, Days in range: 1) 10.06.2024 11:00
pvCorrectionFactor_11_autocalc done 10.06.2024 11:00
pvCorrectionFactor_12 0.69 (automatic - old factor: 1, Sun Alt range: 55, Cloud range: 75, Days in range: 1) 10.06.2024 12:00
pvCorrectionFactor_12_autocalc done 10.06.2024 12:00
pvCorrectionFactor_13 0.74 (automatic - old factor: 0.72, Sun Alt range: 60, Cloud range: 100, Days in range: 17) 10.06.2024 13:00
pvCorrectionFactor_13_autocalc done 10.06.2024 13:00
pvCorrectionFactor_14 0.93 (automatic - old factor: 0.70, Sun Alt range: 65, Cloud range: 100, Days in range: 4) 10.06.2024 14:00
pvCorrectionFactor_14_autocalc done 10.06.2024 14:00
pvCorrectionFactor_Auto on_complex_ai 10.06.2024 14:36
state updated 10.06.2024 14:48
3. Bei der Anzeige der Qualität sehe ich jetzt gerade (ca. 15:30) z. B. unter anderem die folgenden Einträge:
...
Start: 2024-06-13 19:00:00, Quality: 0.73, Factor: 0.79, AI usage: 0 ...
...
Start: 2024-06-14 12:00:00, Quality: -, Factor: 1.00, AI usage: 0 ...
...
Start: 2024-06-14 19:00:00, Quality: -, Factor: 1.00, AI usage: 1 ...
... Warum kann es für heute einen Korrekturfaktor für eine bestimmte Stunde geben, für morgen aber noch nicht?
Oder für morgen keinen, obwohl die Stunde heute schon durch ist.
Und was genau bedeutet der Faktor, ist darin schon der Sonnenstand und die Bewölkung eingeschlossen oder kommt der obendrauf?
Vielen Dank
Thomas
Kann es sein, dass sich in der aktuellen Version
76_SolarForecast.pm 28963 2024-06-11 19:54:23Z DS_Starter
ein Memory Leak eingeschlichen hat?
Ich habe gestern ein FHEM-Update durchgeführt, bei dem nur zwei bei mir aktive Module 00_MQTT2_SERVER.pm und 76_SolarForecast.pm aktualisiert wurden. Die Änderung bei 00_MQTT2_SERVER ist nach meinem Verständnis nur eine zusätzliche Log-Ausgabe. Nach dem Ausschlußverfahren bleibt eigentlich nur das SolarForecast Modul.
Meine VM mit FHEM läuft hat 4 GB Hauptspeicher, bis zum FHEM Update gestern waren über Tage konstant ca 1 GB Speicher belegt. In ca 21h seit dem Update gestern hat FHEM heute sämtlichen Hauptspeicher aufgebraucht, bis der OOM kurz nach 18 Uhr zugeschlagen hat (siehe die Anhänge).
Es sind drei SolarForecast Instanzen mit verschiedenen DWD Modellen aktiv.
VG
Tobias
Zitat von: tpm88 am 13 Juni 2024, 22:53:47Memory Leak
Kann ich nicht bestätigen, bei mir läuft es unauffällig auf einem RPi-3B mit einer Instanz und DWD-OpenWorld.
Zitat von: tpm88 am 13 Juni 2024, 22:53:47Memory Leak
Das kann ich auch nicht bestätigen. 00_MQTT2_SERVER nutze ich übrigens auch.
Wie bei TheTrumpeter ist es ein Raspi. Allerdings habe ich den großen 3B+ :))
Viele Grüße
Thomas
@Tobias,
kann ich ebenfalls nicht bestätigen. Bei mir laufen 2 x 5 Instanzen parallel auf 2 Servern.
In dem Release ist auch lediglich eine Umstellung Reading -> Attribut drin. Das ist programmtechnisch auch nicht so spannend bzw. gravierend.
Falls du Tools wie perfmon, Freezemon _ständig_ parallel laufen lassen solltest dann schalte sie ab und verwende sie nur in einem konkreten Verdachtsfall zur Analyse.
@Thomas,
Zitat1. Wenn es heißt "Die automatische Vorhersagekorrektur ist lernend und benötigt Zeit um die Korrekturwerte zu optimieren.", von welcher Zeit reden wir da (ungefähr, Tage, Woche, Monate)? Oder anders gefragt, welcher Zeitraum wird überhaupt berücksichtigt? Optimieren heißt ja, dass die Werte besser werden, aber irgendein Wert sollte nach dem ersten Lauf da sein?
Den Zeitraum kann man nicht konkret benennen. Wenn z.B. eine stabile sonnige Wetterlage ist, wird sich sehr schnell ein Abgleich einstellen. Es kommt auch immer darauf an wie genau die aktuelle Wetterlage durch die Vorhersage-API abgebildet wird. Abweichungen wird es immer! geben. Man kann nur versuchen, sich der Realität so genau wie möglich zu nähern.
Berücksichtigt wird der gesamte Zeitraum seit der Definition des Devices. Die Prognose- und Ist-Werte werden pro Stunde in Abhängigkeit von Strahlung und Bewölkung bewertet und gespeichert.
Eine Übersicht des Standes sieht man mit "get ... pvCircular":
14 => pvapifc: 2287, pvaifc: -, pvfc: 2287, aihit: 0, pvrl: 1930
batin: 975, batout: 1, confc: 759, gcon: 16, gfeedin: 439, wcc: 83, rr1c: 0.30
temp: 17.50, wid: 61, wtxt: durchgehend leichter Regen
pvcorrf: 5.0=1.02 5.100=1.26 5.10=0.94 5.15=1.59 5.20=0.84 5.30=1.93 5.35=0.92 5.40=0.91 5.45=1.12 5.50=1.65
5.5=0.81 5.55=1.60 5.60=0.87 5.65=0.95 5.70=1.61 5.75=1.06 5.80=1.40 5.85=0.83 5.90=0.97 5.95=0.97
10.0=1.02 10.10=0.94 10.100=1.26 10.15=1.59 10.20=0.84 10.30=1.93 10.35=0.92 10.40=0.91 10.45=1.12 10.5=0.81
10.50=1.65 10.55=1.60 10.60=0.87 10.65=0.95 10.70=1.61 10.75=1.06 10.80=1.40 10.85=0.83 10.90=0.97 10.95=0.97
15.0=1.02 15.10=0.94 15.100=1.26 15.15=1.59 15.20=0.84 15.30=1.93 15.35=0.92 15.40=0.91 15.45=1.12 15.5=0.81
15.50=1.65 15.55=1.60 15.60=0.87 15.65=0.95 15.70=1.61 15.75=1.06 15.80=1.40 15.85=0.83 15.90=0.97 15.95=0.97
20.0=1.02 20.100=1.26 20.10=0.94 20.15=1.59 20.20=0.84 20.30=1.93 20.35=0.92 20.40=0.91 20.45=1.12 20.50=1.65
20.5=0.81 20.55=1.60 20.60=0.87 20.65=0.95 20.70=1.61 20.75=1.06 20.80=1.40 20.85=0.83 20.90=0.97 20.95=0.97
25.0=1.02 25.100=1.26 25.10=0.94 25.15=1.59 25.20=0.84 25.30=1.93 25.35=0.92 25.40=0.91 25.45=1.12 25.50=1.65
25.5=0.81 25.55=1.60 25.60=0.87 25.65=0.95 25.70=1.61 25.75=1.06 25.80=1.40 25.85=0.83 25.90=0.97 25.95=0.97
30.0=1.02 30.100=1.26 30.10=0.94 30.15=1.59 30.20=0.84 30.30=1.43 30.35=1.03 30.40=1.12 30.45=1.12 30.50=0.83
30.5=0.81 30.55=1.60 30.60=0.95 30.65=0.99 30.70=1.86 30.75=1.02 30.80=1.40 30.85=0.83 30.90=1.47 30.95=1.01
35.0=1.02 35.100=1.26 35.10=0.94 35.15=1.59 35.20=0.84 35.30=1.93 35.35=0.92 35.40=0.91 35.45=1.02 35.50=1.16
35.5=0.81 35.55=1.76 35.60=0.87 35.65=1.01 35.70=1.07 35.75=1.06 35.80=1.40 35.85=0.91 35.90=1.23 35.95=0.97
40.0=1.02 40.100=1.26 40.10=0.94 40.15=1.59 40.20=0.84 40.30=1.93 40.35=0.92 40.40=0.91 40.45=1.30 40.50=1.65
40.5=0.81 40.55=1.60 40.60=0.87 40.65=0.95 40.70=1.61 40.75=0.99 40.80=1.40 40.85=0.83 40.90=1.45 40.95=0.93
45.0=1.02 45.100=1.26 45.10=0.94 45.15=1.59 45.20=0.84 45.30=1.93 45.35=0.92 45.40=0.90 45.45=1.09 45.50=1.65
45.5=0.81 45.55=1.15 45.60=1.22 45.65=0.76 45.70=1.61 45.75=1.00 45.80=1.00 45.85=0.83 45.90=0.88 45.95=0.97
50.55=0.96 50.65=0.64 50.70=1.08 50.75=0.89 50.80=1.19 50.85=0.90 50.95=0.71 55.15=1.02 55.20=0.97 55.35=0.97
55.40=0.85 55.45=0.82 55.55=0.99 55.60=0.93 55.65=1.02 55.75=1.16 55.80=0.97 55.85=1.29 55.95=1.03 60.10=1.02
60.40=1.04 60.55=1.13 60.60=0.98 60.65=0.98 60.70=1.02 60.80=0.97 60.85=0.82 60.90=0.76 60.95=1.03
simple=0.99
quality: 5.0=8 5.10=0.93 5.100=0.79 5.15=0.63 5.20=0.81 5.30=0.39 5.35=0.91 5.40=0.63 5.45=0.89 5.5=0.80
5.50=0.27 5.55=0.47 5.60=0.36 5.65=0.61 5.70=0.64 5.75=0.94 5.80=0.72 5.85=0.80 5.90=0.49 5.95=0.97
10.0=8 10.100=0.79 10.10=0.93 10.15=0.63 10.20=0.81 10.30=0.39 10.35=0.91 10.40=0.63 10.45=0.89 10.50=0.27
10.5=0.80 10.55=0.47 10.60=0.36 10.65=0.61 10.70=0.64 10.75=0.94 10.80=0.72 10.85=0.80 10.90=0.49 10.95=0.97
15.0=8 15.100=0.79 15.10=0.93 15.15=0.63 15.20=0.81 15.30=0.39 15.35=0.91 15.40=0.63 15.45=0.89 15.50=0.27
15.5=0.80 15.55=0.47 15.60=0.36 15.65=0.61 15.70=0.64 15.75=0.94 15.80=0.72 15.85=0.80 15.90=0.49 15.95=0.97
20.0=8 20.10=0.93 20.100=0.79 20.15=0.63 20.20=0.81 20.30=0.39 20.35=0.91 20.40=0.63 20.45=0.89 20.5=0.80
20.50=0.27 20.55=0.47 20.60=0.36 20.65=0.61 20.70=0.64 20.75=0.94 20.80=0.72 20.85=0.80 20.90=0.49 20.95=0.97
25.0=8 25.10=0.93 25.100=0.79 25.15=0.63 25.20=0.81 25.30=0.39 25.35=0.91 25.40=0.63 25.45=0.89 25.5=0.80
25.50=0.27 25.55=0.47 25.60=0.36 25.65=0.61 25.70=0.64 25.75=0.94 25.80=0.72 25.85=0.80 25.90=0.49 25.95=0.97
30.0=8 30.10=0.93 30.100=0.79 30.15=0.63 30.20=0.81 30.30=0.79 30.35=0.87 30.40=0.75 30.45=0.89 30.5=0.80
30.50=0.79 30.55=0.47 30.60=0.97 30.65=0.99 30.70=0.47 30.75=0.98 30.80=0.72 30.85=0.80 30.90=0.61 30.95=0.99
35.0=8 35.10=0.93 35.100=0.79 35.15=0.63 35.20=0.81 35.30=0.39 35.35=0.91 35.40=0.63 35.45=0.92 35.5=0.80
35.50=0.49 35.55=0.57 35.60=0.36 35.65=0.99 35.70=0.94 35.75=0.94 35.80=0.72 35.85=0.90 35.90=0.82 35.95=0.97
40.0=8 40.10=0.93 40.100=0.79 40.15=0.63 40.20=0.81 40.30=0.39 40.35=0.91 40.40=0.63 40.45=0.77 40.5=0.80
40.50=0.27 40.55=0.47 40.60=0.36 40.65=0.61 40.70=0.64 40.75=0.99 40.80=0.72 40.85=0.80 40.90=0.69 40.95=0.92
45.0=8 45.10=0.93 45.100=0.79 45.15=0.63 45.20=0.81 45.30=0.39 45.35=0.91 45.40=0.88 45.45=0.95 45.5=0.80
45.50=0.27 45.55=0.87 45.60=0.82 45.65=0.68 45.70=0.64 45.75=1.00 45.80=1.00 45.85=0.80 45.90=0.87 45.95=0.97
50.55=0.96 50.65=0.44 50.70=0.92 50.75=0.70 50.80=0.84 50.85=0.89 50.95=0.00 55.15=0.96 55.20=0.97 55.35=0.95
55.40=0.83 55.45=0.78 55.55=0.99 55.60=0.84 55.65=0.96 55.75=0.75 55.80=0.97 55.85=0.78 55.95=0.94 60.10=0.95
60.40=0.93 60.55=0.88 60.60=0.98 60.65=0.98 60.70=0.98 60.80=0.96 60.85=0.77 60.90=0.69 60.95=0.95
simple=0.99
pvrlsum: 5.100=4600 5.55=6380 5.65=4130 5.75=5450 5.80=4410 5.85=10050 5.90=1060 5.95=7280 10.100=4600 10.55=6380
10.65=4130 10.75=5450 10.80=4410 10.85=10050 10.90=1060 10.95=7280 15.100=4600 15.55=6380 15.65=4130 15.75=5450
15.80=4410 15.85=10050 15.90=1060 15.95=7280 20.100=4600 20.55=6380 20.65=4130 20.75=5450 20.80=4410 20.85=10050
20.90=1060 20.95=7280 25.100=4600 25.55=6380 25.65=4130 25.75=5450 25.80=4410 25.85=10050 25.90=1060 25.95=7280
30.100=4600 30.30=5870 30.35=5710 30.40=2010 30.50=7120 30.55=6380 30.60=4930 30.65=16380 30.70=2200 30.75=6880
30.80=4410 30.85=10050 30.90=1530 30.95=7600 35.100=4600 35.45=5780 35.50=4700 35.55=11390 35.65=26170 35.70=3830
35.75=5450 35.80=4410 35.85=13260 35.90=1560 35.95=7280 40.100=4600 40.45=5740 40.55=6380 40.65=4130 40.75=10150
40.80=4410 40.85=10050 40.90=12000 40.95=8710 45.100=4600 45.40=4980 45.45=5480 45.55=11600 45.60=9780 45.65=8380
45.75=9940 45.80=14160 45.85=10050 45.90=3230 45.95=7280 50.55=12330 50.65=5660 50.70=8040 50.75=2280 50.80=12210
50.85=11510 50.95=790 55.15=6360 55.20=16370 55.35=5250 55.40=8190 55.45=8180 55.55=5830 55.60=5060 55.65=6040
55.75=1770 55.80=8220 55.85=5970 55.95=1430 60.10=6380 60.40=6160 60.55=6160 60.60=34910 60.65=15260 60.70=14870
60.80=15280 60.85=4290 60.90=4940 60.95=1020
simple=440430
pvfcsum: 5.100=3652 5.55=2974 5.65=5728 5.75=5137 5.80=3156 5.85=12047 5.90=516 5.95=7476 10.100=3652 10.55=2974
10.65=5728 10.75=5137 10.80=3156 10.85=12047 10.90=516 10.95=7476 15.100=3652 15.55=2974 15.65=5728 15.75=5137
15.80=3156 15.85=12047 15.90=516 15.95=7476 20.100=3652 20.55=2974 20.65=5728 20.75=5137 20.80=3156 20.85=12047
20.90=516 20.95=7476 25.100=3652 25.55=2974 25.65=5728 25.75=5137 25.80=3156 25.85=12047 25.90=516 25.95=7476
30.100=3652 30.30=7080 30.35=4950 30.40=1501 30.50=8630 30.55=2974 30.60=4766 30.65=16590 30.70=1044 30.75=6737
30.80=3156 30.85=12047 30.90=927 30.95=7561 35.100=3652 35.45=6260 35.50=7080 35.55=6471 35.65=25865 35.70=3582
35.75=5137 35.80=3156 35.85=14607 35.90=1271 35.95=7476 40.100=3652 40.45=4425 40.55=2974 40.65=5728 40.75=10255
40.80=3156 40.85=12047 40.90=8289 40.95=9391 45.100=3652 45.40=5580 45.45=5185 45.55=10054 45.60=8003 45.65=11076
45.75=9926 45.80=14193 45.85=12047 45.90=3655 45.95=7476 50.55=12830 50.65=8814 50.70=7429 50.75=2971 50.80=10298
50.85=12771 50.95=1872 55.15=6100 55.20=16823 55.35=5509 55.40=9604 55.45=9989 55.55=5873 55.60=5885 55.65=5801
55.75=1336 55.80=8435 55.85=4631 55.95=1344 60.10=6072 60.40=5759 60.55=5439 60.60=35641 60.65=15499 60.70=14572
60.80=15834 60.85=5256 60.90=6485 60.95=966
simple=444716
dnumsum: 5.100=6 5.55=2 5.65=1 5.75=3 5.80=3 5.85=4 5.90=1 5.95=5 10.100=6 10.55=2
10.65=1 10.75=3 10.80=3 10.85=4 10.90=1 10.95=5 15.100=6 15.55=2 15.65=1 15.75=3
15.80=3 15.85=4 15.90=1 15.95=5 20.100=6 20.55=2 20.65=1 20.75=3 20.80=3 20.85=4
20.90=1 20.95=5 25.100=6 25.55=2 25.65=1 25.75=3 25.80=3 25.85=4 25.90=1 25.95=5
30.100=6 30.30=1 30.35=1 30.40=1 30.50=2 30.55=2 30.60=1 30.65=4 30.70=1 30.75=4
30.80=3 30.85=4 30.90=2 30.95=6 35.100=6 35.45=1 35.50=1 35.55=3 35.65=6 35.70=2
35.75=3 35.80=3 35.85=6 35.90=2 35.95=5 40.100=6 40.45=2 40.55=2 40.65=1 40.75=5
40.80=3 40.85=4 40.90=4 40.95=6 45.100=6 45.40=1 45.45=1 45.55=3 45.60=3 45.65=2
45.75=4 45.80=5 45.85=4 45.90=3 45.95=5 50.55=3 50.65=2 50.70=2 50.75=1 50.80=3
50.85=3 50.95=1 55.15=1 55.20=3 55.35=1 55.40=2 55.45=2 55.55=1 55.60=1 55.65=1
55.75=1 55.80=2 55.85=2 55.95=1 60.10=1 60.40=1 60.55=2 60.60=7 60.65=4 60.70=4
60.80=5 60.85=2 60.90=3 60.95=1
simple=134
Die Hilfe zum get erläutert die Bedeutung der einzelnen Keys.
ZitatBeim Beobachten sind mir die Readings "pvCorrectionFactor_xx" aufgefallen. Bei Nutzung der Automatik sind die nicht ständig gefüllt, richtig? Sie werden täglich bis zur aktuellen Stunde neu eingetragen, die anderen sind jeweils leer (zumindest in der Anzeige)?
Diese Readings zeigen die Auswertung sowie Neuberechnung eines Korrekturfaktors für die aktuelle Stunde.
Die vergangenen Stunden bleiben noch erhalten bis Mitternacht. Danach beginnt alles von vorn.
Wie es zu lesen ist, soll das Beispiel erläutern:
pvCorrectionFactor_10 1.16 (automatic - old factor: 1.05, Sun Alt range: 40, Cloud range: 85, Days in range: 6)
Für die Stunde 10 (9:00 - 10:00) wurde zur Prognosekorrektur der Faktor 1.05 (old factor) angewendet.
Durch den Vergleich der prognostizierten Energie und der erzeugten Energie wurden die Werte aller! in der pvCircular akkumulierten Tage mit gleicher Sonnenaltitude und gleicher Bewölkung zur gleichen Stunde wurde der resultierende neue Korrekturfaktor 1.16 berechnet. Er wird verwendet, falls diese Faktoren wieder so zutreffen. Die Angabe "Days in range" beschreibt wieviel akkumulierte Tage, an denen die oben genannten Wetterbedingungen identisch zutreffen, für die Kalkulation herangezogen werden konnten.
D.h. "Days in range: 1" in deinem Beispiel bedeutet dass nur ein Tag (der aktuelle) verwendet werden konnte und der alte Faktor "1" auf "0.57" korrigiert wurde weil sich dies aus Prognose und realer Erzeugung ergeben hat.
ZitatBei der Anzeige der Qualität sehe ich jetzt gerade (ca. 15:30) z. B. unter anderem die folgenden Einträge:
Code Auswählen
...
Start: 2024-06-13 19:00:00, Quality: 0.73, Factor: 0.79, AI usage: 0 ...
...
Start: 2024-06-14 12:00:00, Quality: -, Factor: 1.00, AI usage: 0 ...
...
Start: 2024-06-14 19:00:00, Quality: -, Factor: 1.00, AI usage: 1 ...
...
Warum kann es für heute einen Korrekturfaktor für eine bestimmte Stunde geben, für morgen aber noch nicht?
Oder für morgen keinen, obwohl die Stunde heute schon durch ist.
Und was genau bedeutet der Faktor, ist darin schon der Sonnenstand und die Bewölkung eingeschlossen oder kommt der obendrauf?
Auch für morgen gibt es einen Faktor, nämlich "1" (Factor). Nur die bisher erreichte Qualität nicht, da es noch keine Vergleichswerte gibt.
Wenn die Stunde für heute schon durch ist und für morgen dennoch nur ein Faktor 1 verwendet wird, dann sind die meteorologischen Bedingungen nicht identisch und es für diese Bedingungen noch keinen Korrekturfaktor gibt -> der Faktor 1 wird dann verwendet.
Was der Faktor genau ist, habe ich oben bereits erläutert und wie er ermittelt wird.
LG,
Heiko
Ich habe auch kein Problem damit.
Ich kann dir aber aus Erfahrung sagen das es nicht einfach ist ein Memoryleak ausfindig zu machen.
Ich hatte vor kurzem aus unerklärlichen Gründen ganz komische Phänomene mit Memory leak.
Im Endeeffekt habe ich den Raspberry gegen ein N100 getauscht. Kann ich nur Empfehlen etwas größeres zu nehmen.
Mit z.B. Proxmox hat man dann auch schnell einen zweiten, 3ten, 4ten "Raspberry" bzw. Server aufgesetzt.
Mein Raspberry 4B 4GB hatte einen Load Average von >=1 am 15min Wert. Das gefiel mir nicht.
Mit N100 hab ich ~0.20 im 15min. Und damit war auch der Memory-leak weg.
Konfig, Hardware etc. ist gleich geblieben.
Z.B. Mein Problem:
https://forum.fhem.de/index.php?topic=137975.msg1311335#msg1311335
Hallo Heiko,
Gibt es eine Möglichkeit, einen Verbrauch (hier mein Wallbox) aus der Verbrauchsvorhersage auszuklammern (sprich vom Energiemeter abzuziehen)? Z.B. wenn es als Consumer gesetzt wird.
Gruß
Tupol
@all,
ein weiterer Schritt der geplanten Umstellungen ist vorgenommen.
Umgesetzt ist jetzt der Setter modulePeakString in Attr setupStringPeak.
Der ganze Prozess läuft nach einem Restart! automatisch ab.
WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
@kask, in #665 hatten wir schon über modulePeakString gesprochen. Der Parameter kann doch als Attribut verwendet werden. Eine dynamische Anpassung kann intern abgebildet werden. Der nominale Peak-Wert ändert sich nicht.
Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.
Hallo Tupol,
im Prinzip ja, ist allerdings noch nicht auswählbar.
Im get ... nextHours gibt es confc und confcEx. Dabei ist confcEx der erwartete Energieverbrauch ohne Anteile registrierter Verbraucher. Das wäre im Prinzip das was du willst wenn ich es richtig sehe.
Schau dir mal bei dir die Werte an:
Zitat...
NextHour15 => starttime: 2024-06-15 12:00:00, hourofday: 13, today: 0
pvapifc: 3881, pvaifc: -, pvfc: 3881, aihit: 0, confc: 641
confcEx: 376, DoN: 1, wid: 61, wcc: 88, rr1c: 0.30, temp=17.80
rad1h: -, sunaz: 163, sunalt: 57
rrange: 0.30, crange: 90, correff: 1.13/0.79
NextHour16 => starttime: 2024-06-15 13:00:00, hourofday: 14, today: 0
pvapifc: 4240, pvaifc: -, pvfc: 4240, aihit: 0, confc: 500
confcEx: 259, DoN: 1, wid: 61, wcc: 81, rr1c: 0.00, temp=18.60
rad1h: -, sunaz: 190, sunalt: 58
rrange: 0.00, crange: 80, correff: 0.97/0.96
...
In confcEx sollte deine Wallbox nicht enthalten sein wenn sie als Consumer integriert ist. Allerdings sind in diesem Werte dann _alle_ integrierten Consumer exkludiert. Ich kann momentan nicht einen einzelnen Consumer exkludieren. Wenn das gebraucht wird, muß ich mir erst ein paar Gedanken dazu machen.
Das wäre wirklich toll. Z.B. könnte man bei der Consumer-Definition angeben, dass der Verbrauch nicht mit in die Prognose eingerechnet bzw. praktisch davon abgezogen werden soll.
Hintergrund ist, dass ich die Wallbox abends manchmal auch von der Solarbatterie füttere. Allerdings soll die Batterie noch genügend Energie für den normalen, nicht steuerbaren Verbrauch haben, um am frühen Morgen keinen Strom aus dem Netz ziehen zu müssen.
Gruß
tupol
Ich mache mir Gedanken dazu ...
@Tupol,
in meinem contrib habe ich eine Weiterentwicklung bereitgestellt welche deinen Use Case abbilden kann.
Dafür gibt es den neuen optionalen Consumer Key "exconfc":
exconfc
Verwendung des aufgezeichneten Energieverbrauchs des Verbrauchers zur Erstellung der Verbrauchsprognose (optional).
0 - der historische Energieverbrauch des Verbrauchers wird zur Erstellung der Verbrauchsprognose verwendet (default)
1 - der historische Energieverbrauch des Verbrauchers wird von der Verbrauchsprognose ausgeschlossen.
Die Version werde ich heute Abend noch einchecken, aber kannst es ja schonmal bei dir testen.
Grüße,
Heiko
Hallo,
ich habe dieses Modul gerade zufällig gefunden,als ich nach einer Lösung für folgende Aufgabenstellung gesucht habe:
- Meine Solax-Wallbox ist "intelligent" und kann selbst aufgrund der aktuellen Stromerzeugung- und Verbrauchsdaten entscheiden, mit welchem Strom sie laden kann.
- Das funktioniert aber nur dann gut, wenn die Sonneneinstrahlung einigermaßen konstant ist. Wenn ständig kleine Wolken durchziehen, dann wird die Ladeleistung auch ständig rauf- und runtergeregelt, und fällt damit oftmals unter das Minimum, dass das Auto zum Laden braucht. Im Ergebnis wird dann eben kaum geladen, und ob das ständige Ein-/Ausschalten wirklich gut ist, glaube ich auch nicht.
- In solchen Fällen ist es dann besser, mit einer konstanten Leistung zu laden, und den Einbruch durch die kleine Wolke aus dem Netz auszugleichen.
- Was ich also bräuchte ist eine Vorhersage, ob die zukünftige Ertragslage einigermaßen konstant ist, und auf welchem Niveau.
- Davon abhängig könnte ich entscheiden, ob ich die dynamische Regelung der Wallbox nutze, oder lieber mit einer konstanten Ladeleistung arbeite, und welche Höhe die richtige wäre.
Ich hab jetzt noch nicht verstanden, ob ich diese Information aus diesem Modul gewinnen kann. Ich kann zwar Verbraucher schalten, aber habe ich auch die Info über die Konstanz, um ständiges Ein-/Ausschalten zu vermeiden? Oder bin ich da mit diesem Modul auf dem falschen Weg?
Und gleich noch ne andere Frage:
Ich habe zwei Strings mit unterschiedlichen Ausrichtungsn und Dachneigungen. Läßt sich das auch abbilden?
Danke für Eure Hilfe!
Hallo beaune,
die einfachste Antwort zuerst:
ZitatIch habe zwei Strings mit unterschiedlichen Ausrichtungsn und Dachneigungen. Läßt sich das auch abbilden?
Ja, kein Problem.
Die Kontinuität einer Wetterlage kann man zwar im Vorfeld etwas schätzen indem man sich die Kontinuität des Vorhersagediagramms anschaut (ich könnte auch eine Kontinuitätsaussage per Reading implementieren). Aber ob die tatsächlich zutrifft weiß man erst hinterher. Also in gewisser Weise wäre es wohl möglich. Aber ob das für eine Wallboxsteuerung in deinem beschriebenen Use Case der optimale Weg ist möchte ich nicht behaupten, käme natürlich auf einen Versuch an.
Du könntest aber auch die Wallbox als Consumer im Modul integrieren und die Steuerung dem Modul überlassen. Über diverse Keys kann man Einfluß auf das Schalt/Ladeverhalten nehmen. Ich selbst habe noch keine Wallbox, kann demzufolge nur theoretisch unterstützen. Aber eventuell gibt es bereits Nutzer die eine Wallbox intergriert haben. Man brächte dann auf jeden Fall ein FHEM-Modul über das man die Schaltungen und anderen Befehle an die Wallbox übermitteln kann.
Edit: Du bekommst auf jeden Fall für jede Stunde eine Vorhersage wieviel in dieser Stunde an Ertrag prognostiziert wird und du kannst dir auch ein Signalreading generieren lassen ob der Verbraucher X empfohlen wird einzuschalten. Es gibt noch mehr Möglichkeiten wie PowerTrigger, energyH4Trigger die für solche Dinge orchestriert werden können.
Grüße,
Heiko
Ist eigentlich eine "Smarte" E-Auto Ladefunktion geplant?
Also quasi:
(08:00) Auto wird angesteckt
(08:00) Laden wird gestoppt da aktuell zu wenig V vorhanden und um 11:00 genug vorhanden ist
(11:00) Laden wird aufgrund von genügend PV gestartet
Lg
Tobias
Hallo Tobias,
Sagen wir mal so ... geplant ist es nicht direkt, aber da Wallbox/E-Auto natürlich in das Portfolio dieses Moduls in Verbindung mit PV-Anlage passen, wäre eine solche Anforderung aufzunehmen und zu konzipieren.
Ich gehe davon aus (weil du so fragst), dass die Einbindung der Wallbox als Consumer und der damit einhergehenden Steuerungsmöglichkeit deine Anforderung bezüglich des Leistungsumfanges nicht abdeckt?
Leider habe ich selbst keine Wallbox. Deswegen wäre es für mich aus Sicht des Anforderungsmanagement wichtig, dass du bzw. weitere Interessenten beschreibst welche Funktionalitäten eine solches Teilmodul abdecken sollte. Ein wenig hast du ja geschrieben. Vllt. gibt es da noch mehr.
Edit: Es wäre z.B. auch denkbar einen Consumertyp "Wallbox" einzuführen. Dessen konfigurierbare Bausteine könnten z.B. sein:
- Einplanung 24 x 7
- Ladeschaltung bei Überschuß mit Abstufung 1 bis 3 phasig mit einstellbaren Surplus-Schwellenwerten
- + zusätzliche Batterieverwendung wenn SOC oberhalb X
- ...
Vielleicht ist das der bessere Weg da es sich in das Consumer-Konzept einfügt.
LG
Hi Tobias, Hi Heiko,
das Thema Wallbox hatten wir schonmal.
Damals hatten die meisten gesagt sie verwenden dafür EVCC.
Ich benutze es auch selbst in Verbindung mit deinem Modul.
Ich denke EVCC ist hier die richtige Lösung, da dort sehr viel Aufwand betrieben wird für die Ladesteuerung und die Integration von Wallboxen und Autos.
Es läuft auch super parallel zu deinem Modul.
Also meine Meinung ist man sollte sich einfach noch EVCC parallel auf dem Server installieren.
@Tobias: Hast du dir schonmal EVCC angeschaut?
Gruß,
Stefan
Zitat von: TechnoTron am 15 Juni 2024, 19:12:48Ist eigentlich eine "Smarte" E-Auto Ladefunktion geplant?
Also quasi:
(08:00) Auto wird angesteckt
(08:00) Laden wird gestoppt da aktuell zu wenig V vorhanden und um 11:00 genug vorhanden ist
(11:00) Laden wird aufgrund von genügend PV gestartet
Lg
Tobias
Ich habe noch keine Wallbox und lade übergangsweise über eine Steckdose (mit 6A, also sehr gemächlich). Die hängt als Consumer auch am Modul und das macht genau das, was du oben beschreibst.
Wenn man die Wallbox aus FHEM ansteuern kann, sollte die Einbindung als Consumer schon heute mit diesem großartigen Modul gelingen.
Gruß
Christian
Hallo Heiko,
ich habe es eingebunden. Weiß aber nicht, wie man kontrolliert, ob es tut was es tun soll.
Das mit der Wallbox ist recht kompliziert. Ich habe mich entschieden, es selber über ein Perl-Script zu programmieren. Dadurch kann ich Sachen berücksichtigen wie:
- PV-Durchschnittswert mit schleichender oder schneller Anpassung der Ladeleistung
- Komplexe Bedienung/Ansteuerung der Wallbox
- Ladestand E-Auto (da mein E-Auto und meine Wallbox nicht ausreichend smart sind, geht es nur über einen CAN-Adapter, MQTT-Server, FHEM-MQTT-Client)
- Gestufte Prio des Aufladung je nach Batteriestand Solar und E-Auto, z. B. Schnellladen bis mindestens 30%, danach Prio-Laden bis 40%, Anpassen der Ladeleistung an Füllstand-Solarbatterie bis 60%, Berücksichtigung Restverbrauch Haus ab 40%, etc.)
- Vorbereitung der Solarbatterie (85%->100%) auf Rückkehr des Autos
- Solarbooster der Wärmepumpe nur bei geladenem oder nicht angeschlossenem E-Auto
- Verschiedene Lade-Modi wie PV-Laden, PV-Laden mit Solarbatterie, Minimal- und Maximalladen, Zielzeitpunkt-Laden etc.
Gruß
tupol
@Tupol,
Zitath habe es eingebunden. Weiß aber nicht, wie man kontrolliert, ob es tut was es tun soll.
Ah ja, guter Hinweis. Ich baue noch eine Debug Logmeldung mit ein damit man die Berücksichtigung des Keys nachverfolgen kann.
@Thema Wallbox,
stimmt Stefan hatten wir schonmal. Für eine einfache Anwendung (wie bei Christian beschreibt) reicht offensichtlich die aktuelle Consumer Einbindung.
Die komplexen Steuerungsaufgaben, wie Tupol sie beschreibt, sind natürlich nochmal eine andere Hausnummer.
Tupol, möglicherweise könnte ich deine Algos im Modul mit verankern/adaptieren falls gewünscht. Es liest sich schon sehr ausgefeilt was du entwickelt hast.
LG
@Tupol, habe eine Debugmeldung für ctrlDebug=consumtion eingebaut. Sie zeigt die Berücksichtigung:
2024.06.15 22:02:11.168 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.06.15 22:02:11.168 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 01, hour: 23, csme: 72.8999999999069
2024.06.15 22:02:11.169 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 08, hour: 23, csme: 72.9000000001397
2024.06.15 22:02:11.169 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 18, hour: 23, csme: 73.5
2024.06.15 22:02:11.170 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 25, hour: 23, csme: 74.1000000000931
2024.06.15 22:02:11.170 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-06-15 22:00:00, confc: 530, days for avg: 4, hist. consumption registered consumers: 213.85
Ist eingecheckt und auch im contrib verfügbar.
Zur Info...
Bezüglich der Umstellung Readings -> Attribute bin ich soweit durch.
Lediglich die Attribute ctrlWeatherDevX stelle ich noch nach setupWeatherDevX um da diese Einstellungen auch direkt zum Setup des Devices gehören.
Die Konfigurations-Readings moduleAzimuth und moduleDeclination bleiben erhalten damit sie bei Nachführanlagen dynamisch von extern verändert werden können. Ich überlege allerdings noch ob ich sie in setupStringAzimuth bzw. setupStringDeclination umsetze damit sie im Wording zu den Setup-Attributen passen.
Zitat von: DS_Starter am 15 Juni 2024, 21:11:00Tupol, möglicherweise könnte ich deine Algos im Modul mit verankern/adaptieren falls gewünscht. Es liest sich schon sehr ausgefeilt was du entwickelt hast.
Ich glaube, da ist eher Dein Ansatz mit einer möglichst flexiblen Schnittstelle sinnvoller. Meine Anwendungen ist ja nur für unser Nutzungsverhalten programmiert. Ich bin da noch am Beobachten von PV, Haus-Verbrauch und E-Auto-Nutzung und bessere immer wieder was nach, wenn mir eine mögliche Logik auffällt. Bei einem anderen Nutzungsverhalten muss die Logik sicher anders aussehen. Ich kann aber gerne etwas detaillierter schildern, was ich bisher umgesetzt habe.
@Stefan
Nein, aktuell nutze ich die Modbusverbindung des Ladegeräts.
Hier stelle ich auch die Ladeleistung in Abhängigkeit von Verbrauch und Batteriespeicher-Stand rauf und runter.
Das habe ich über ein paar Scripte etc. gelöst.
EVCC kenne ich nicht, werde ich mir gleich mal ansehen.
Ich bin aber ein Fan von Aio (All in one) Lösungen deswegen wollte ich fragen ob da etwas geplant ist.
Moin Tobias,
du kannst mir deine Scripte (gerne auch als PM) übermitteln.
Daran sehe ich vermutlich deine Vorgehensweise und könnte sie ggf. in die Consumer Konfiguration matchen.
Vllt. kann man dann bereits einige (einfachere) Fälle abbilden.
LG
Zitat von: DS_Starter am 15 Juni 2024, 23:03:06Zur Info...
Bezüglich der Umstellung Readings -> Attribute bin ich soweit durch.
Lediglich die Attribute ctrlWeatherDevX stelle ich noch nach setupWeatherDevX um da diese Einstellungen auch direkt zum Setup des Devices gehören.
Die Konfigurations-Readings moduleAzimuth und moduleDeclination bleiben erhalten damit sie bei Nachführanlagen dynamisch von extern verändert werden können. Ich überlege allerdings noch ob ich sie in setupStringAzimuth bzw. setupStringDeclination umsetze damit sie im Wording zu den Setup-Attributen passen.
Ich habe noch nie wirklich verstanden warum sämtliche Anlagen Parameter als Readings ausgeführt wurden bzw. noch werden.
Eigentlich benutzen sämtliche Module die Ich so kenne und benutze Readings als ändernde Werte des Moduls und Attribute als statische.
In dem SolarForecast Modul ist es ja anfangs anders gewesen. Da waren eigentlich alle statischen Paramater zur Anlage als Reading ausgeführt.
Wo war da der Grund? Bzw. Ist da der Grund? Man kann doch auch auf Attribut änderungen intern im Modul drauf reagieren.
Oder gibt es da was das als Attribute nicht möglich ist aber als Reading?
Attribute kann ich doch auch so ändern ob ich jetzt "set","setreading" oder "attr" nehme zum anpassen.
Hallo kask,
am Anfang der Entwicklungen bestand die Idee darin, die vielfältigen Einstellmöglichkeiten der Darstellung und sonstigen Verhaltens inhaltlich von den Core-Einstellungen des Moduls zu trennen sowie sich dynamisch änderende Settings zu ermöglichen. Dadurch konnte ich die Anzahl der Attribute managen.
Später hatte ich mit der Einführung der Klassifikationen ctrl.*. flow.*, graphic.*, setup.* die Möglichkeit die Attribute zu strukturieren, was dem User ermöglicht trotz der vielen Attribute sich gut zu orientieren wenn man die Struktur verinnerlicht hat.
Einige der Einstellungen wie z.B. Azimuth oder Declination sind ganz praktisch wenn man sie dynamisch ändern kann (Nachführanlagen) ohne diese Parameteränderung explizit speichern zu müssen. Erstens hat man ständig das rote Fragezeichen im System stehen und außerdem wird ein nicht gespeichertes Attribut beim Restart immer mit dem letzten persistierten Wert wiederhergestellt. Das ist nicht gewünscht in diesen Fällen. Ein ähnliches Verfahren gibt es im notify Modul mit dem Setter active/inactive versus disable. Beide Dinge wirken im Prinzip identisch mit dem oben beschriebenen Unterschied.
Aus diesem Grund ist zum Beispiel auch pvCorrectionFactor_Auto als Setter ausgeführt. So kann z.B. der User in Abhängigkeit bestimmter Umstände in den noLearning Modus wechseln und zurück. Gängiges Beispiel ist des Vorhandensein einer Schneedecke auf den Modulen oder Umbauarbeiten. Die Schneedecke kennt das Modul nicht, aber die Abweichungen wären extrem und würden über längere Zeit die gelernten Werte stark verfälschen. So kann der User manuell oder automatisiert über den Set-Befehl zwischen den Modi wechseln ohne sich um eine Speicherung der Strukturänderung Gedanken machen zu müssen.
Das mit dem Schnee war mir gar nicht bewusst. Könnte man das auch automatisch abfangen, so dass große Ausreiser nicht berücksichtigt werden?
Ich strebe ja immer danach, dass FHEM ohne irgendwelche händische Einstellungen läuft und man höchstens mal einen Knopf drückt, wenn man in den Urlaub fährt.
ZitatKönnte man das auch automatisch abfangen, so dass große Ausreiser nicht berücksichtigt werden?
Zum Beispiel mit einem entsprechend angebrachten "Schneesensor". Es könnte ein Belichtungssensor sein, der während der Tagzeit ausgewertet wird. Fällt sein Wert unter X wird von einer Scheedecke ausgegangen und per notify etc. ein "set ... pvCorrectionFactor_Auto noLearning" ausgelöst.
Man kann sich da sicher noch mehr einfallen lassen.
Hallo Heiko,
Ein Hinweis für die Wallboxsteuerung. Für die Entscheidung mit dem Laden zu starten, verwende ich unter anderem die verfügbare Differenz des Tages aus "PV-Forecast" - "Consumer-Forecast bis Sonnenuntergang" - "Nötige Solar-Batterieladung bis 100%". Dahinter steht die Vorgabe, dass die Solar-Batterie bei Sonnenuntergang voll sein soll. Man muss dabei aber zwischen Brutto- und Netto-SoC unterscheiden. Prinzipiell versuche ich immer so schnell wie möglich die Autobatterie zu laden, da ich da nix mehr rein schieben kann, wenn es unterwegs ist.
Gruß
tupol
Zitat von: DS_Starter am 16 Juni 2024, 14:33:50Zum Beispiel mit einem entsprechend angebrachten "Schneesensor". Es könnte ein Belichtungssensor sein, der während der Tagzeit ausgewertet wird. Fällt sein Wert unter X wird von einer Scheedecke ausgegangen und per notify etc. ein "set ... pvCorrectionFactor_Auto noLearning" ausgelöst.
Man kann sich da sicher noch mehr einfallen lassen.
Nein. Ich meinte über die AI. In der Statistik werden ja große Ausreiser auch aussortiert und entweder mit dem Median gearbeitet oder mit der 2. und 3. Quartil.
Nein. Ich meinte über die AI. In der Statistik werden ja große Ausreiser auch aussortiert und entweder mit dem Median gearbeitet oder mit der 2. und 3. Quartil.
Ja, nur was ist "groß"? Der Wert für "groß" ist bei einer 800W Peak Balkonanlage sicher ein anderer als bei einer 15 Kw Peak Anlage. Wenn die Anlage neu definiert ist und noch keine Erfahrungswerte vorliegen wird es auch schwierig. Ab einer bestimmten Anzahl von "Days in range", ich werfe mal empirisch 5 Tage in den Ring, könnte man eine Abweichung von größer +- 30% (empirisch) als Ausreißer definieren und vom Lernprozess ausschließen.
Das meinst du doch sicherlich, oder?
In % und konfigurierbar geht auch. Aber besser sind statistische Auswertungen wie
- den Median nehmen,
- den Durchschnitt des 2. und 3. Quartil (= 50 % der Werte) berücksichtigen.
- Meine Anlage hat im aktiven Zustand noch keinen Schnee gesehen. Ich vermute aber, der PV-Wert geht dann unter 10%. Das könntest Du auch einfach komplett ignorieren. Obere Ausreißer gibt es ja vermutlich nicht.
- Der Modus geht evtl. auch, wenn nicht zu oft Schnee drauf liegt.
Ich weiß halt nicht, was die KI-Bibliothek hergibt. Eigentlich ist das ja ein normaler Vorfall, dass man Ausreißer hat. Vielleicht gibt es auch ein passendes Statistikmodul in Perl.
Beeinflussen sich benachbarte Werte gegenseitig, also z. B. der Sonnenstand 25° auch den Sonnenstand 30°?
Statistische Auswertungen wie Median oder Quartile müsste ich selbst berechnen. Die KI hilft hier nicht weiter. Sie wird mit den real gemessenen Werten gelernt und liefert ein Ergebnis wenn sie wiederum mit Prognosen gefüttert wird.
@all,
ein weiterer Schritt der geplanten Umstellungen ist vorgenommen.
Umgesetzt ist jetzt
- Setter moduleAzimuth in setupStringAzimuth
- Setter moduleDeclination in setupStringDeclination
- Setter moduleRoofTops in Attr setupRoofTops
Der ganze Prozess läuft nach einem Restart! automatisch ab.
WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
Update morgen früh.
LG,
Heiko
Moin Heiko,
Im fhem.log sind mir einige Warnungen aufgefallen:
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11674.
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11674.
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11694.
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11694.
Grüße,
Guido.
Moin Guido,
die Warnings gibt es bei mir zwar nicht, aber ich schaue mir das an.
Danke für die Info.
Grüße,
Heiko
Hallo zusammen,
kann mir dieses Modul auch die Autarkie mit anzeigen?
Ich finde nicht dazu.
Klar kann man das mit einem extra Dummy oder sonst was rechnen, aber übersichtlicher wäre es wenn es hier direkt dabei wäre.
Hi Henno,
Du findest nativ im Modul das Reading "Current_AutarkyRate" und noch vieles andere mehr.
Viele Grüße!
Peter
Zitat von: DS_Starter am 16 Juni 2024, 23:27:58Statistische Auswertungen wie Median oder Quartile müsste ich selbst berechnen. Die KI hilft hier nicht weiter. Sie wird mit den real gemessenen Werten gelernt und liefert ein Ergebnis wenn sie wiederum mit Prognosen gefüttert wird.
OK. Dann bleibt nur die Variante mit der Aussortierung von zu kleinen Werten bei Minusgraden.
Ich habe noch nicht verstanden, wie die KI genau funktioniert. Bildet sie nur den Mittelwert aller eingespeisten Werte für eine Parametergruppe? Oder ist da auch noch eine Logik drin wie bei statistischen Vorhersagemodellen? Vielleicht kann man auch den Parameter "Schneefall" aus dem Wetterbericht mit aufnehmen? (Wobei es ja Leute gibt, die den Schnee von den Panelen fegen und das Abrutschen oder Schmelzen des Schnees auch nicht erfasst wird. Schwierig...)
Die KI ist ein Decision Tree (AI::DecisionTree (https://metacpan.org/pod/AI::DecisionTree)).
Sie kann im Prinzip nur Vorhersagen auf Grund von bereits erlernten Parametern und deren Beziehungen zueinander liefern.
ZitatVielleicht kann man auch den Parameter "Schneefall" aus dem Wetterbericht mit aufnehmen?
:) Ja, das wäre schön einfach. Aber leider kann in der Realität der schönste Sonnenschein sein (und demzufolge eine hohe Prognose), aber dennoch Schnee für eine Woche auf den Zellen liegen weil es gestern Nacht doll geschneit hat und wegen den Minusgraden keine Schmelze eintritt.
Darum wäre ein "Schneesensor" nicht das schlechteste Mittel.
@Guido,
ich habe die Warnings hoffentlich beseitigt.
Eine entsprechende Version ist eingecheckt und morgen früh im Update.
Du kannst sie aber auch schon aus meinem Contrib laden, FHEM restarten und schauen ob es geholfen hat.
Wie gesagt, kamen bei mir diesen Warnungen nicht.
Grüße,
Heiko
Hallo Heiko,
Danke noch mal für die Erläuterungen zum CorrectionFactor. Hatte ich zwar schon geschrieben, aber nicht genug. Das hat echt geholfen zu verstehen, warum das bei mir gerade so läuft. Führt aber auch zu einem Verbesserungsvorschlag ;)
Wenn man wie in meinem Fall Probleme mit Verschattung zu bestimmten Zeiten hat, ist zu diesen Zeiten ein Faktor von 1,0 als Ausgangsbasis nicht der beste Wert. Die letzten 2 Tage hatte ich das erste Mal für alle Stunden einen korrigierten Wert und eine viel bessere Vorhersage. Morgen sind aber nach derzeitigem Stand wieder 2 Stunden ohne vorhanden. Bei dem vorhergesagten Wetter (Bewölkung) führt das dann zu Ausreißern mit zu hoher Vorhersage. Wenn man nun für jede Stunde des Tages manuell eine Vorgabe machen könnte, die dann genommen wird, falls noch kein Wert berechnet ist, wäre das aus meiner Sicht eine bessere Ausgangsbasis.
Und eine Frage noch: Du hattest weiter oben geschrieben, dass die Strings bei der Berechnung des Faktors nicht (unterschiedlich) berücksichtigt werden (hätte ja z. B. wegen Thema Beschattung so sein können). Da ich das bei der Einrichtung nicht wusste, habe ich trotz gleicher Ausrichtung mehrere Strings definiert und das jetzt so gelassen. Woran ich nicht gedacht habe und was mir jetzt im Debug-Log aufgefallen ist: Die API-Abfrage erfolgt natürlich für jeden Strings einzeln. Das ist dann in meinem Fall unnötig. Kann ich das noch ändern (zu einem String zusammenfassen) oder gibt das irgendwelche Probleme und ich sollte es lieber lassen?
Viele Grüße
Thomas
Hallo Thomas,
ZitatKann ich das noch ändern (zu einem String zusammenfassen) oder gibt das irgendwelche Probleme und ich sollte es lieber lassen?
Ändern kann man es natürlich. Ob es einen Vorteil bringt hängt etwas von der verwendeten API ab. Welche benutzt du?
ZitatWenn man nun für jede Stunde des Tages manuell eine Vorgabe machen könnte, die dann genommen wird, falls noch kein Wert berechnet ist, wäre das aus meiner Sicht eine bessere Ausgangsbasis.
Da probiere ich mal etwas.
Zitat von: DS_Starter am 17 Juni 2024, 16:19:03Ändern kann man es natürlich. Ob es einen Vorteil bringt hängt etwas von der verwendeten API ab. Welche benutzt du?
Aktuell nutze ich nur OpenMeteoDWD-API. Aber wo die Geschichte mit der Umwandlung der Einstellungen in Readings abgeschlossen ist und man mit weniger manuellen Nacharbeiten kopieren kann, wollte ich noch mal weitere testen. Bei Vorteil dachte ich nur an weniger Abfragen (auf meiner Seite) und weniger Antworten/Berechnungen für den Server, nicht in Richtung besserer Vorhersage.
Ok, bei SolCast-API hätte ich einen direkten Vorteil gesehen weil die Rooftop Abfrage so sehr beschränkt ist. Aber bei OpenMeteoDWD-API sehe ich eigentlich keinen Vorteil.
Du hast natürlich Recht was den Rechenaufwand betrifft, aber ob die Einsparung überhaupt spürbar ist bezweifle ich ehrlich gesagt. Du kannst es natürlich umsetzen wenn du magst.
Zitat von: DS_Starter am 17 Juni 2024, 15:20:30Die KI ist ein Decision Tree (AI::DecisionTree (https://metacpan.org/pod/AI::DecisionTree)).
Sie kann im Prinzip nur Vorhersagen auf Grund von bereits erlernten Parametern und deren Beziehungen zueinander liefern.
Das ist dann etwas anderes als reine Statistik. Wobei ich mich frage, wo sie besser ist. ;D Wenn ich es richtig verstehe, versucht der Algorithmus für ein Parameterset den Most-Frequent-Wert zu bestimmen, dass wäre dann der Modus.
Es gibt da übrigens auch den Parameter "noise_mode". Der hört sich irgendwie nach "Schneefall" an. Aber prinzipiell kann man auch selber einfach alles weg lassen, was nicht über ein bestimmtes prozentuales Limit kommt. Der "noise_mode" kommt vermutlich besser mit ständigen Abweichungen z.B. durch Verschattung zurecht.
ZitatEs gibt da übrigens auch den Parameter "noise_mode". Der hört sich irgendwie nach "Schneefall" an.
:) Nö ... Ist noise_mode auf fatal (Standardeinstellung) gesetzt, löst die train()-Methode eine Ausnahme (die -> FHEM stirbt) aus. Wenn noise_mode auf pick_best eingestellt ist, wird das häufigste Ergebnis an jedem verrauschten Knoten ausgewählt.
Ich verwende 'pick_best' ;)
Hallo Thomas,
ZitatWenn man nun für jede Stunde des Tages manuell eine Vorgabe machen könnte, die dann genommen wird, falls noch kein Wert berechnet ist, wäre das aus meiner Sicht eine bessere Ausgangsbasis.
Ich habe die Funktionalität der Setter pvCorrectionFactor_XX aufgewertet:
pvCorrectionFactor_XX <Zahl>Voreinstellung des Korrekturfaktors für die Stunde XX des Tages.
(default: 1.0)
In Abhängigkeit vom Setting pvCorrectionFactor_Auto ('off' bzw. 'on_.*') erfolgt eine statische oder dynamische Voreinstellung:
off Der eingestellte Korrekturfaktor wird durch die Autokorrektur nicht überschrieben.
Im Reading pvCorrectionFactor_XX wird der Status durch den Zusatz 'manual fix' signalisiert.
on_.* Der eingestellte Korrekturfaktor wird durch die Autokorrektur bzw. KI überschrieben
sofern ein berechneter Korrekturwert im System verfügbar ist.
Im Reading pvCorrectionFactor_XX wird der Status durch den Zusatz 'manual flex' signalisiert.
Dadurch kannst du deinen use Case abbilden. D.h. der voreingestellte Korrekturfaktor für Stunde XX wird solange verwendet bis ein berechneter Faktor (oder KI Wert) vom System bereitgestellt wird sofern man in
pvCorrectionFactor_Auto einen Modus beginnend mit "on_" eingestellt hat.
Im Debugmodus pvCorrectionRead sieht man eine entsprechende Ausschrift:
...
2024.06.17 22:20:51.086 1: SolTem DEBUG> read parameters - fd: 1, hod: 16, Sun Altitude Bin: 50, Cloud range: 70, corrf: 1.00, quality: -
2024.06.17 22:20:51.090 1: SolTem DEBUG> use 'manual flex' - fd: 1, hod: 17, Sun Altitude Bin: 45, Cloud range: 70, corrf: 0.80, quality: -
2024.06.17 22:20:51.094 1: SolTem DEBUG> read parameters - fd: 1, hod: 18, Sun Altitude Bin: 35, Cloud range: 75, corrf: 1.07, quality: 0.88
2024.06.17 22:20:51.099 1: SolTem DEBUG> read parameters - fd: 1, hod: 19, Sun Altitude Bin: 25, Cloud range: 75, corrf: 0.92, quality: 0.79
2024.06.17 22:20:51.103 1: SolTem DEBUG> use 'manual flex' - fd: 1, hod: 20, Sun Altitude Bin: 15, Cloud range: 75, corrf: 0.90, quality: 0.76
2024.06.17 22:20:51.108 1: SolTem DEBUG> use 'manual flex' - fd: 1, hod: 21, Sun Altitude Bin: 5, Cloud range: 80, corrf: 1.50, quality: -
2024.06.17 22:20:51.112 1: SolTem DEBUG> read parameters - fd: 1, hod: 22, Sun Altitude Bin: 0, Cloud range: 75, corrf: 1.50, quality: 0.27
2024.06.17 22:20:51.116 1: SolTem DEBUG> read parameters - fd: 1, hod: 23, Sun Altitude Bin: 0, Cloud range: 80, corrf: 1.00, quality: -
2024.06.17 22:20:51.120 1: SolTem DEBUG> read parameters - fd: 1, hod: 24, Sun Altitude Bin: 0, Cloud range: 00, corrf: 1.00, quality: -
...
Ich habe die Version 1.29.2 zunächst in meinem contrib zum Download bereitgestellt. Ich möchte mir auch noch den morgigen Tag anschauen wie sich das Ganze verhält.
LG,
Heiko
Hallo zusammen,
ich wollte bei mir Open Meteo nutzen und beim Umstellen der setupRadiation-API bekomme ich den Fehler: Please complete command "set PV_Forecast setupStringDeclination". Habe ich eventuell bei einem Update nicht auf "save config" gedrückt? Oder wo ist mein Denkfehler?
Grüße
Ja, ist sehr wahrscheinlich dass du nicht gespeichert hast.
Kein Problem, gebe die Stringdaten in dem Setter neu ein.
LG
Hallo Heiko,
Zitat von: DS_Starter am 17 Juni 2024, 22:37:12Ich habe die Funktionalität der Setter pvCorrectionFactor_XX aufgewertet:
genial. Nicht nur eingebaut, aus meiner Sicht auch auf optimale Weise, ohne zusätzliche Einstellungen. Man könnte so ohne Automatik mit festen Werten starten und später einfach umstellen und die als Default weiterverwenden.
Ich habe das eben installiert und teste auch. Die beiden Stunden ohne Faktor von heute sind leider (oder zum Glück) verschwunden, weil sich die Wettervorhersage wieder geändert hat. Aber für morgen gibt es zwei, da habe ich schon mal einen Wert eingetragen und schaue mal nach der nächsten Kalkulation. Den Rest trage ich auch noch ein.
Zur Verlässlichkeit der Wettervorhersage: Ich teste gerade neue Apps auf dem Handy. Hat nicht direkt mit der PV-Vorhersage zu tun, aber heute könnte ich mir z. B. als Höchsttemperatur 25, 27 oder 29 Grad aussuchen. Für den Kurzurlaub am kommenden Wochenende schwanke ich noch zwischen Wellness bei Regen oder Radfahren im Sonnenschein ;)
Viele Grüße
Thomas
Ich habe da leider keinen Setter für und wenn ich "set PV_Forecast setupStringDeclination XX" eingebe, dann kommt "The specified inclination angle has an incorrect format"
Das der Setter fehlt, kann an der verwendeten API liegen. Das Attr setupRadiationAPI löschen, den Setter ausführen und das Attr setupRadiationAPI wieder wie gewünscht setzen. Welche API nutzt du?
Daran lag es, ich bin von DWD_OpenData umgestiegen auf Open Meteo. Danke dir. Ich habe jetzt ctrlWeatherDev1 auf OpenMeteoDWD-API und die setupRadiationAPI gelöscht und neu gesetzt. Im anschließenden "Guide" hat er dann die Setter auch korrekt definiert. Das Open Meteo device nutze ich über HTTPMOD. Wie kommt SolarForecast an die Daten oder fragt er sie selber ab?
Sehr schön.
Das Modul hat dafür eine eigene Requestverwaltung. Nur bei DWD_OpenData wird auf ein DWD Device gesetzt und von diesem die Daten gezogen.
Super, wirklich klasse.
Zitat von: tomcat.x am 18 Juni 2024, 10:03:10Ich habe das eben installiert und teste auch
Zwei Sachen sind mir auf- bzw eingefallen: Man sieht in pvCorrectionFactor_xx jetzt die Neuberechnung nicht mehr so schön. Und da das Setter und keine Attribute sind, kann man es nicht mit Copy in neue (Test-) Geräte übernehmen. Aber das ist nicht so entscheidend.
Von der Nutzung der Werte her sieht es für mich gut aus. Und in den vorhergesagten Werten sind die Ausreißer bei fehlenden Korrekturfaktoren weg. Leider ist die Vorhersage heute nicht wegen denen völlig daneben. Vorhin hat es mal geregnet, aber nur draußen, in keiner meiner 3 Test-Apps ;D
Hallo!
Ich versuche mich gerade in das Modul einzuarbeiten. Echt super und man ist unabhängig vom externen Sunny-Portal :)
Es sind natürlich ein paar Fragen aufgekommen, die ich mir nicht beantworten konnte...
Ich möchte (wenn es denn doch noch warm wird) meine Poolpumpe mit dem Modul steuern. Dafür habe ich mir erstmal 2 Testverbraucher (dummys) angelegt und 2 consumer erstellt:
attr SF consumer01 du_Poolpumpe type=other power=1500 \
mode=must mintime=120 | SunPath \
notbefore=09:00 notafter=18:00\
interruptable=1\
locktime=180:180\
on=on off=off
attr SF consumer02 du_Poolpumpe2 type=other power=500 \
mode=must mintime=120 | SunPath \
notbefore=09:00 notafter=18:00\
interruptable=1\
locktime=180:180\
on=on off=off
1.) Ich möchte eigentlich das die Poolpumpe ruhig schon früh startet. Also ab 9:00Uhr, wenn dann genügend Strom da ist.
Bisher ist die Zeitplanung eher Nachmittags, wenn auch der meiste Überschuss zu erwarten ist (aber genug Überschuss ist auch bereits Vormittags vorhanden)
Kann ich das beeinflussen? Auch werden bisher beide Verbraucher immer zur gleichen Zeit eingeplant...obwohl der zu erwartende Verbrauch doch stark voneinander abweicht. Ist das "normal"?
2.) Gibt es auch eine Möglichkeit ein "maxtime" zu setzen? Also
mintime=mindestens(wenn wenig Strom vorhanden)
maxtime=wenn genug Überschuss vorhanden ist, dann gerne so lange laufen lassen...
3.) Die schön übersichtliche Übersichtsseite: Eine Aktualisierung der Werte erfolgt bei mir nur, wenn ich die ganze Seite neu lade. Ist sicherlich so gewollt?
4.) Für FTUI2 gibt es schon eine schöne Vorlage um die Übersicht auch auf dem Tablet anzuzeigen. Gibt es da auch schon was für FTUI3?
Danke für die tolle Arbeit!
Gruß
Bismosa
Hallo Bismosa,
ZitatIch möchte eigentlich das die Poolpumpe ruhig schon früh startet. Also ab 9:00Uhr, wenn dann genügend Strom da ist.
Kann ich das beeinflussen?
Ja. Du würdest dann notafter=09:00 setzen und z.B. mintime=540. Dann würde die Einplanung in der Zeit 09:00 bis 18:00 erfolgen. Die Einplanung ist nicht zwangsläufig gleichzusetzen mit der tatsächlichen Startzeit. Die Einschaltung des Verbrauchers innerhalb der Planungszeit ist noch von mode und anderen Parametern wie swoncond, interruptable, etc. abhängig.
ZitatGibt es auch eine Möglichkeit ein "maxtime" zu setzen? Also
mintime=mindestens(wenn wenig Strom vorhanden)
maxtime=wenn genug Überschuss vorhanden ist, dann gerne so lange laufen lassen...
Der Name "mintime" ist von mir leider etwas unglücklich gewählt. Er beschreibt die Einplanungszeit in Minuten (min=Minuten) wie in der Hilfe angegeben. Wenn du z.B. mintime=SunPath angibst, wird der gesamte Sonnentag als mögliches Schalt/Lauffenster verwendet unter der Prämisse, dass genügend Überschuß vorhanden ist. Durch die Verwendung von interruptable kann man den Verbraucher nach dem Start bei ungenügend PV unterbrechen lassen und wenn wieder genügend Überschuß vorhanden ist, weiterlaufen lassen.
ZitatDie schön übersichtliche Übersichtsseite: Eine Aktualisierung der Werte erfolgt bei mir nur, wenn ich die ganze Seite neu lade. Ist sicherlich so gewollt?
Nein. Die aktualisiert bei jedem Update. Allerdings muß "state" einen Event erzeugen, was im Normalfall so ist. In der Detailansicht erfolgt keine Aktualisierung der Ansicht.
ZitatFür FTUI2 gibt es schon eine schöne Vorlage um die Übersicht auch auf dem Tablet anzuzeigen. Gibt es da auch schon was für FTUI3?
Dafür habe ich noch keine Template bereitgestellt (nutze kein FTUI). Aber es gibt glaube ich User die FTUI3 nutzen wenn ich mich nicht irre. Vllt. meldet sich jemand mal dazu.
Ich nehem auch gerne einen Prototypen entgegen. Bin mit JavaScript nicht so familiär. ;)
LG,
Heiko
@Thomas,
ZitatZwei Sachen sind mir auf- bzw eingefallen: Man sieht in pvCorrectionFactor_xx jetzt die Neuberechnung nicht mehr so schön.
Da habe ich nachgebessert.
In meinem Contrib liegt ein Update bereit.
Jetzt wird bei der Berechnung eines auf "manual flex" gesetzten pvCorrectionFactors das Berechnungsergebnis als "flexmatic result" ausgedruckt.
pvCorrectionFactor_20 1.2 (manual flex) / flexmatic result 0.85 for Sun Alt range: 15, Cloud range: 75, Days in range: 2
Wenn ich es richtig gemacht habe, erfolgt in der Nachtverarbeitung ein Rücksetzen des Readinginhaltes auf:
pvCorrectionFactor_20 1.2 (manual flex)
damit morgen die Voreinstellung wieder zieht (unter der Bedingung dass kein passendes Berechnungsergebnis im System gespeichert ist).
ZitatUnd da das Setter und keine Attribute sind, kann man es nicht mit Copy in neue (Test-) Geräte übernehmen.
Aber man kann alle Einstellungen in ein kopiertes Device übernehmen: ->
https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Backup_und_Wiederherstellung_der_Moduldaten
LG,
Heiko
Hallo Heiko,
vielen Dank für die Ausführliche Antwort!
Zitat von: DS_Starter am 18 Juni 2024, 20:17:07Ja. Du würdest dann notafter=09:00 setzen und z.B. mintime=540. Dann würde die Einplanung in der Zeit 09:00 bis 18:00 erfolgen. Die Einplanung ist nicht zwangsläufig gleichzusetzen mit der tatsächlichen Startzeit. Die Einschaltung des Verbrauchers innerhalb der Planungszeit ist noch von mode und anderen Parametern wie swoncond, interruptable, etc. abhängig.
Das werde ich dann mal ausprobieren. Das notafter hatte ich ganz anders verstanden...und zwar das die Schaltzeit danach nicht mehr sein darf.
Mit deiner Erklärung macht das aber Sinn :)
Mit swoncond könnte ich evtl. mit einem doif etwas passendes basteln. Gut, das der Pool noch nicht aufgebaut ist.
Zitat von: DS_Starter am 18 Juni 2024, 20:17:07Nein. Die aktualisiert bei jedem Update. Allerdings muß "state" einen Event erzeugen, was im Normalfall so ist. In der Detailansicht erfolgt keine Aktualisierung der Ansicht.
state erzeugt ein Event. In der Raumseite wird auch brav aktualisiert. War mir nicht aufgefallen, da ich immer auf der Detailseite unterwegs war.
Zitat von: DS_Starter am 18 Juni 2024, 20:17:07Dafür habe ich noch keine Template bereitgestellt (nutze kein FTUI). Aber es gibt glaube ich User die FTUI3 nutzen wenn ich mich nicht irre. Vllt. meldet sich jemand mal dazu.
Ich nehem auch gerne einen Prototypen entgegen. Bin mit JavaScript nicht so familiär. ;)
Mal schauen, was sich da vielleicht machen lässt. :) Profi bin ich da allerdings auch gar nicht. Aber mit der Vorlage für FTUI2 kann man ja vielleicht schon was anfangen. Es sei denn, hier hat das schon mal jemand gemacht?
Gruß
Bismosa
Hallo Thomas,
die Nachtverarbeitung hat noch nicht so funktioniert wie ich es mir vorstelle.
In meinem contrib liegt ein Update der Version 1.29.2.
Falls es heute auch bei dir noch die Readings "pvCorrectionFactor_XX_autocalc" als Überbleibsel von Gestern geben sollte, lösche sie bitte manuell. Die aktualisierte Version sollte dieses Manko beseitigen.
LG,
Heiko
Hallo Heiko,
ich war gestern nicht mehr dazu gekommen, habe gerade erst die neue Version installiert und werde berichten.
Zitat von: DS_Starter am 18 Juni 2024, 20:30:26Aber man kann alle Einstellungen in ein kopiertes Device übernehmen
Genau, habe ich auch schon so gemacht.
Vielen Dank erst mal.
Thomas
Zitat von: DS_Starter am 18 Juni 2024, 20:17:07Allerdings muß "state" einen Event erzeugen
Dabei fällt mir eine Frage wieder ein: Bei mir ist es so eingestellt, dass nur state ein Event erzeugt. Bei der Konfigurationsprüfung kommt daher "Attribute 'event-on-change-reading' is not set to .*. ". Da wollte ich immer schon mal fragen, ob das ok ist, falls ich selbst aktuell keine weiteren Events für irgendwas brauche. Das für state zu lassen, machte für mich Sinn, um überhaupt irgendeine Aktivität erkennen zu können.
Ja das ist ok. Das Device hat halt sehr viele Readings die bei einem Update Events werfen.
Ich habe zwar schon mit readingsBulkUpdateIfChanged experimentiert (falls jemand die Idee hat ;) ). Hier ist allerdings nachteilig, dass sich der Update-Zeitstempel nicht ändert, wenn der Wert beim Update gleich bleibt, d.h. das Reading wird in diesem Fall nicht aktualisiert. Das ist unschön, denn ich möchte schon wissen ob ein Wert (ohne Event) aktualisiert wurde. Teilweise wird das auch ausgewertet.
Edit: Du kannst dennoch 'event-on-change-reading=.*' setzen. state wird auch in diesem Fall Events werfen.
Zitat von: DS_Starter am 19 Juni 2024, 11:02:39Du kannst dennoch 'event-on-change-reading=.*' setzen. state wird auch in diesem Fall Events werfen.
Ja, ist klar. Aber ich will die anderen nicht, wenn sie nicht gebraucht werden. Bin da letzt mal über alle Geräte gegangen, die viele Events erzeugen und bei neuen schränke ich immer gleich stark ein.
Jetzt sieht es so aus wie ich es mir vorstelle.
Bei mir auch. Auch wenn ich nicht weiß, was Du Dir vorstellst ;D Danke!
Aufgrund der aktuellen Wettervorhersage ist für heute auch noch eine Stunde drin, in der mein Wert genommen wird (falls es so bleibt). Es passiert aber natürlich immer seltener, dass kein berechneter Wert vorhanden ist. Bei 20% kommt die "KI" ins Spiel. Das alles nur so als Info. Interessant zu beobachten, wie sich die Werte ändern.
Habe die neue V 1.29.0 eingecheckt und ist morgen früh im Regelupdate enthalten.
Hallo zusammen,
Ich nutze das Modul erfolgreich schon seit Jahren und bin sehr zufrieden. Nun habe ich allerdings aufgerüstet und meine Anlage um eine Anker SOLIX Solarbank E1600 erweitert.
Vorher bestand mein Setup aus 6 Balkonkraftwerken auf Dach Richtung Süden mit jeweils einem Hoymiles HM300. Dazu einen HM600 mit zwei weiteren Zellen dran in Süd-West bzw. West Ausrichtung.
Die Winkel der einzelnen Felder habe ich im Modul als 3 Verschiedene Strings angelegt.
Das funktionierte auch wirklich gut. Die Prognosen hatte unter 10 % Abweichung.
Nun habe ich das Feld SW /W umgebaut und beide Zellen Richtung Süden ausgerichtet und dann eine SOLIX Solarbank dazwischen geklemmt.
Die veränderte Winkel habe ich dem Modul auch mitgeteilt. Nun wird per Anker App am Tage erstmal der Ertrag der beiden Zellen in den Akku geschoben und somit nicht dem Haus zugeführt.
Somit sind die Prognosen des Moduls natürlich auch immer höher als dann wirklich zur Verfügung steht.
Ich komme auf keine vernünftige Lösung wie ich das de Modul nun beibringen soll, das es mit der Prognose nicht immer mit diesen beiden Zellen rechnen kann.
Bleibt mir nix anderes als diese beiden Zellen "rauszunehmen" um dann wenigsten immer eine schlechtere Prognose zu bekommen ?
Hat jemand eine Idee wie man das besser lösen kann ?
An der Fhem Anbindung der SOLIX arbeite ich noch. Stand jetzt habe ich keine Daten des Akkus die man verwenden könnte. Ich hoffe das ich wenigstens das noch hin bekomme. Für HA gibt es da ja schon was: https://github.com/thomluther/hacs-anker-solix
Das kann ich leider wohl nicht für Fhem benutzen.
...
Welche API nimmst du?
Je nachdem welche API du nutzt, könntest du bei dem attr "setupInverterDev" die "capacity" abändern wenn der speicher gerade geladen wird.
Wenn nicht dann wieder zurück ändern. Per DOIF, notify what ever.
Wie gut und ob das überhaupt geht kann ich nicht sagen. Wäre einen Versuch wert.
ZitatIch komme auf keine vernünftige Lösung wie ich das de Modul nun beibringen soll, das es mit der Prognose nicht immer mit diesen beiden Zellen rechnen kann.
In die Prognose gehören die Zellen schon hinein, denn sie erzeugen ja Energie die dir zufließt. Sie wird nur zunächst in der Batterie gespeichert.
Du brauchst nur einen Zähler in/out an deiner Batterie damit du die Batterie dem Modul mitteilen kannst. Dann ergiebt sich automatisch ein höherer Ertrag.
D.h. du brauchst ein Modul um die Batteriekennwerte zu messen und im Attr setupBatteryDev hinterlegen zu können. Dann passt es wieder.
"Einen nackten Mann in die Tasche greifen" ist nicht so leicht.
Skusi sucht einen Work-around um das Modul zu benutzen, mit dem Wissen das er die Batteriedaten braucht aber (noch) nicht zur Verfügung hat.
So lese ich sein Anliegen.
Ich denke eher das er vorerst eine zähler am AC-Teil anschliesst (shelly-plug, tasmota, was auch immer) um zu sehen was da passiert.
Dann kann er die Panels zu.- abschalten je nach AC-Wert.
Denn erstmal wird der Akku ja voll geschoben. Heisst das AC-seitig nix kommt. Dann die Zellen raus rausnehmen.
Kommt wieder AC-seitig was Positiv dann die Zellen reinnehmen.
Das ganze sollte allerdings auch mit allen Zellen im ganzen funktionieren. Denn AC-seitig kommt ja wieder was, auch wenn die Sonne nicht scheint.
Nur diesmal aus dem Speicher. Ist ja von der Sonne beladen worden. Das doofe ist nur der Tagesübergang. Dann wird in die Rechnung des Tages schon die "Batteriesonne" vom Vortag einkalkuliert.
Alles in allem ist hier in dem Fall die Abweichung aber eh irrelevant und nur interesant für sich selbst und zum optimieren in manchen API's.
Über kurz oder lang sollte sich das eh relativieren durch die auto_korrekturen.
Moin,
ja, ich habe auch nochmal darüber nachgedacht.
Möglicherweise wäre es ein Weg alle Homiles auszulesen (habe einen Thread gefunden: https://forum.fhem.de/index.php?topic=121282.0), in einem Dummy zu konsolidieren und die Parameter wie gewöhnlich im Attr setupInverterDev zu hinterlegen. Dann sollte zumindest die gesamte Erzeugung erfasst sein und das Delta zur Prognose klein gehalten.
Durch die fehlenden Angaben zur Batterie werden die Verbräuche, AutarkyRate etc. nicht stimmen. Aber vllt. schafft skusi auch noch die Bat zu intergrieren.
Hallo Heiko,
kann es sein, dass sich mit den letzten Änderungen ein Bug bezüglich graphicHistoryHour eingeschlichen hat? Bei mir sieht es so aus, als ob von dem gesetzten Wert immer 8 abgezogen werden. Also bis 8 passiert gar nichts (ich sehe nur die standardmäßigen 2 Stunden), mit 9 sehe ich 1 Stunde und mit meinen vorher einstellten 12 sehe ich 4 Stunden. graphicHourCount habe ich nicht gesetzt, nur jetzt testweise damit herumgespielt. Das ändert aber nichts. Ansonsten habe ich bezüglich Grafik nur graphicBeamHeightLevelX auf 250 gesetzt.
Und im Zusammenhang mit "Stunde" dann noch eine Frage: In der Grafik ist Stunde XX (oder besser Uhrzeit XX?) die Zeit von XX:00 bis XX:59, bei allen anderen Angaben/Readings/Settings ist es immer die XX. Stunde des Tages, also sozusagen XX-1:00 bis XX-1:59, richtig? Das hatte mich beim Analysieren von Ausreißern bei bestimmten Stunden in der Grafik anhand der Angaben bei Quatlität, in pvCorrectionFactor_XX oder pvHistory erst etwas verwirrt.
Viele Grüße
Thomas
Hallo Thomas,
bei mir sieht alles gut aus.
Kann es sein dass es bei dir keine Vorhersagedaten vor der Uhrzeit X gibt?
Das bekommst du mit einem
get ... solApiData
heraus. Im Normalfall sieht man dann die Daten von heute++ seit Mitternacht:
Süddach => 2024-06-28 00:00:00 => pv_estimate50: 0.0
2024-06-28 01:00:00 => pv_estimate50: 0.0
2024-06-28 02:00:00 => pv_estimate50: 0.0
2024-06-28 03:00:00 => pv_estimate50: 0.0
2024-06-28 04:00:00 => pv_estimate50: 0.0
2024-06-28 05:00:00 => pv_estimate50: 92.0
2024-06-28 06:00:00 => pv_estimate50: 475.6
2024-06-28 07:00:00 => pv_estimate50: 981.8
2024-06-28 08:00:00 => pv_estimate50: 1380.7
2024-06-28 09:00:00 => pv_estimate50: 1764.3
2024-06-28 10:00:00 => pv_estimate50: 1933.0
2024-06-28 11:00:00 => pv_estimate50: 2055.7
2024-06-28 12:00:00 => pv_estimate50: 2255.2
2024-06-28 13:00:00 => pv_estimate50: 2638.7
2024-06-28 14:00:00 => pv_estimate50: 2761.4
2024-06-28 15:00:00 => pv_estimate50: 2991.6
2024-06-28 16:00:00 => pv_estimate50: 2868.8
2024-06-28 17:00:00 => pv_estimate50: 2331.9
2024-06-28 18:00:00 => pv_estimate50: 1841.0
2024-06-28 19:00:00 => pv_estimate50: 1089.2
2024-06-28 20:00:00 => pv_estimate50: 460.2
2024-06-28 21:00:00 => pv_estimate50: 46.0
2024-06-28 22:00:00 => pv_estimate50: 0.0
2024-06-28 23:00:00 => pv_estimate50: 0.0
2024-06-29 00:00:00 => pv_estimate50: 0.0
2024-06-29 01:00:00 => pv_estimate50: 0.0
2024-06-29 02:00:00 => pv_estimate50: 0.0
2024-06-29 03:00:00 => pv_estimate50: 0.0
....
Grüße,
Heiko
Hallo Heiko,
was genau meinst Du mit "keine Vorhersagedaten", dass es dafür keine Einträge in der Liste gibt oder dass sie 0.0 sind. Das sieht bei mir ähnlich wie bei Dir aus und der erste Balken ist dann der für "06".
Und da habe ich wirklich früher nicht stattdessen die letzten Stunden des Vortages mit Vorhersagungen angezeigt bekommen? Oder hatte ich den Zeitraum einfach nur groß genug gewählt, so dass mir nie aufgefallen ist, dass die Anzahl der Balken für vorangegangene Stunden nicht immer genau zu graphicHistoryHour passt sondern variiert? Dann vergiss es ;-)
Viele Grüße
Thomas
Ja ich meinte dass keinerlei Verhersagewerte da sind, also 0.0 ist ok.
Vom Vortag wird angezeigt wenn es entsprechende Werte in der pvHistory gibt und der Bereich von graphicHistoryHour dort "hineinreicht".
Aber rein modultechnisch ist alles ok.
LG,
Heiko
So mancher wundert vllt. dass hier gerade nicht viel passiert.
Die letzte Zeit habe ich damit zugebracht mein "Datacenter" von VmWare nach Proxmox zu migrieren. Jetzt werkelt ein Trigkey AMD Ryzen 7 und später gemeinsam mit dem NUC im Cluster (geplant).
Es laufen schon fast alle Dienste wieder, nicht nur FHEM (DNS-Cluster, deconz/Phoscon, Unify-Controller, MariaDB, etc.).
Es geht dann bald auch hier wieder weiter.
LG
Willst du auch ein HA Cluster aufbauen?
Ich bin da gerade am einlesen. Für HA braucht man noch eine 3. Instanz als Quorum (Könnte ein debian im Docker meienr Syno sein?).
Aber ich glaube ich habe das falsche Filesystem, ext4, gewählt. ZFS ist in diesem Fall wohl die Wahl. Den 2. Knoten habe ich testweise auf ZFS installiert, aber da bin noch am experimentieren weil die verfügbaren Partitions nur so groß sind wie die kleinste Disk im Rechner, also 250G + 500G im Rechner, daraus macht Proxmos ZFS rpool 250G + 250G = 500G, die restlichen 250G kriege ich nicht rein. Wenn das nicht besser wird. kommt auch da wieder ext4 drauf und ich überlege mir eine Variante mir Backup/Restore. HA wäre schön gewesen, naja mal schauen.
Oder die 250G mit einer 500G tauschen.
Ich gehe davon aus das du ZFS-Raid1 dann gewählt hast, weil aus 250+500=250 wird.
Wenn dem so ist kannst du doch einfach die 250gb gegen eine 500gb disk tauschen und dann resilvern. Kost doch nicht viel.
Am Ende hast du automatische ein 500gb raid1.
Das ist ja auch das schicke an ZFS. Der Verbund ist immer so groß wie die kleinste Disk und durch das resilvern geht es ohne "Downtime" weil hotswap fähig.
edit: verlesen Raid0. Aber das ist bei allen RAID0 so weil er die Daten ja striped..Wie soll das sonst gehen wenn nicht 1:1? 1:2 stripen?
Aber da is nix mit resilvern dann.
ZitatIch gehe davon aus das du ZFS-Raid1 dann gewählt hast,
Das ist ja das komische, habe ich eben nicht (dann wäre es mir logisch), sondern Raid0 im Proxmox Installer.
Na vielleicht baue ich die 250G mal aus, installiere neu (dann müsste) er ja die 500G voll nehmen und baue die 250G oder eine neue 500G wieder dazu.
Aber das müssten wir in einem anderen Thread weiterführen glaube ich. ;) VVllt. gibt es hier schon einen für Proxmox ...
Zitat von: DS_Starter am 28 Juni 2024, 08:39:34Moin,
ja, ich habe auch nochmal darüber nachgedacht.
Möglicherweise wäre es ein Weg alle Homiles auszulesen (habe einen Thread gefunden: https://forum.fhem.de/index.php?topic=121282.0), in einem Dummy zu konsolidieren und die Parameter wie gewöhnlich im Attr setupInverterDev zu hinterlegen. Dann sollte zumindest die gesamte Erzeugung erfasst sein und das Delta zur Prognose klein gehalten.
Durch die fehlenden Angaben zur Batterie werden die Verbräuche, AutarkyRate etc. nicht stimmen. Aber vllt. schafft skusi auch noch die Bat zu intergrieren.
Das mache ich schon so.
Allerdings brauche ich die einzelne Hoymiles nicht zusammenfassen, da ich nicht für jeden WR ein eigenes Device angelegt habe, sondern nur eines für die OpenDTU Bridge. Die liefert mir ja schon den Gesamtertrag und die Gesamtleistung.
Die Daten der SOLIX Bank kann ich nun auch empfangen. Nun muß ich nur noch schauen welche readings ich wie per setupBatterieDev angeben muß.
Wenn du die Daten aus der SOLIX Bank bekommst dann kannst du diese doch als Batterie einbinden.
Ist ja eine ;) die Wird halt nur von vereinzelten Panel gespeisst. Aber das ist doch egal.
Hallo Heiko,
Zitat von: DS_Starter am 28 Juni 2024, 16:51:18Vom Vortag wird angezeigt wenn es entsprechende Werte in der pvHistory gibt und der Bereich von graphicHistoryHour dort "hineinreicht".
Vielleicht noch zur Erklärung, warum ich da einen Bug vermutet hatte: Bei graphicHourCount=24 sehe ich 24 Balken, egal ob es in den relevanten Stunden Werte gibt oder nicht. Bei fehlenden Werten wird einfach aus den folgenden Stunden aufgefüllt. In der Hilfe sprichst Du auch von "
Balken/Stunden". Dementsprechend hätte ich bei graphicHistoryHour erwartet, dass bei Stunden mit fehlenden Werten, dann die davor angezeigt werden. Also beispielsweise bei graphicHourCount=24 und graphicHistoryHour=12, dass die aktuelle Stunden immer in der Mitte der Grafik ist.
Viele Grüße
Thomas
Zitat von: Skusi am 30 Juni 2024, 20:14:50Die Daten der SOLIX Bank kann ich nun auch empfangen.
Darf ich fragen wie? 8)
Auslesen oder auch in fhem "integriert"? :)
Danke, Joachim
Hallo!
Ich habe es nun (endlich) geschafft, die Übersicht auch in FTUI3 einzubinden.
Bestimmt ist das eher gefrickelt...aber so muss eigentlich nichts an FTUI3 angepasst werden:
Beispiel:
<ftui-tab-view id="ViewPV">
<ftui-grid-tile row="1" col="2" height="10" width="11" style="overflow: scroll;">
<header>Solar Vorhersage</header>
<script>
function FW_cmd(text){
ftuiApp.fhemService.sendCommand(text.replace("/fhem?XHR=1&cmd=",""))
}
</script>
<style>
#SolarFC svg {
width: 20px;
height: 20px;
}
#SolarFC td {
width: 2px;
font-size: 13px;
padding-left: 0px;
padding-right: 0px;
margin: 0px;
}
</style>
<ftui-content id="SolarFC" [content]="SF:state | getHTML('SF') "></ftui-content>
</ftui-grid-tile>
</ftui-tab-view>
Wobei folgendes wichtig ist:
1.) style="overflow: scroll;" -> sonst ist es ggf. auf einem 8" Tablet nicht lesbar
2.) <script>...</script> -> Da im HTML für Befehle ein FW_cmd integriert ist, muss das hier übersetzt werden. Dieser Part darf nur in dem Haupt-HTML-Dokument in FTUI3 vorhanden sein. In Content-Dateien wird dieser nicht berücksichtigt
3.) <style> muss ggf. an eigene Bedürfnisse angepasst werden :)
Jetzt aber das große ABER:
Bei mir funktioniert das "<ftui-content [content]" nicht richtig. Sobald ich dies in FTUI verwende, wird der HTML-Code im Sekundentakt neu geholt und mein FHEM geht auf 100% CPU.
Dies konnte ich umgehen. Zusätzlich habe ich ein aktualisieren nur wenn angezeigt eingebaut. Siehe https://forum.fhem.de/index.php?msg=1316074
Vielleicht kann das ja jemand gebrauchen. :)
Gruß
Bismosa
Zitat von: MadMax-FHEM am 01 Juli 2024, 15:20:30Zitat von: Skusi am 30 Juni 2024, 20:14:50Die Daten der SOLIX Bank kann ich nun auch empfangen.
Darf ich fragen wie? 8)
Auslesen oder auch in fhem "integriert"? :)
Danke, Joachim
Hallo Joachim,
nach ein paar Startschwierigkeiten hat es dann doch hiermit funktioniert:
https://github.com/tomquist/solix2mqtt
Das habe ich nun auf meinem Host mitlaufen und so werden mir alle 60 Sekunden per MQTT die Daten übertragen.
Nachteil ist das solange fhem quasi am Anker Server saugt, die App nicht mehr funktioniert. Benutzt man die App und gibt sein Login ein, wird fhem rausgeschmissen. Ein Service restart per Konsole verbindet dann fhem wieder und schmeißt die App raus.
Leider habe ich noch geschafft auch Einstellungen zu publishen. Ich glaube das geht auch mit dem Packet nicht. Deshalb muss man dazu sich mit der App Verbinden um dieses zu tun. Danach halt wieder den Slox2mqtt Dienst starten.
Ich hab die SLOIX auch erst eine Woche und experimentiere noch viel. Aber bald habe ich meine Einstellungen gefunden und dann kann mir die App auch egal sein.
Besser wäre natürlich wenn man auch per fhem Einstellungen ändern könnte. Aber dazu habe ich zu wenig Programierkenntnisse.
@Skusi: vielen Dank!
Überlege auch bei einem Bekannten Solix zu nehmen. Fhem-Integration is nat. prima, erhöht die Chance, dass ich/wir das dann nehmen :)
Gruß, Joachim
Hallo zusammen!
Ich betreibe das Modul SolarForecast seit wenigen Wochen zu meiner (fast) vollen Zufriedenheit. Ich möchte behaupten, dass ich hier noch ein ziemlicher Anfänger bin.
Ich habe meine Poolpumpe und die Poolheizung jeweils über einen Shelly1PM angeschlossen, meine Warmwasseraufbereitung (die einerseits autonom Strom vom Netz zieht über einen Shelly PM Mini Gen3 zur Energiemessung und für den Boost bei Energieüberschuss noch einen Shelly1, der eine Steuerleitung an die Warmwasseraufbereitung schickt.
Waschmaschine, Geschirrspüler und Trockner sind auch definiert und werden über einen Shelly PM Mini Gen3 gemessen.
Nun habe ich einerseits Probleme mit meinen Prioritäten. Ich hatte die Poolheizung und die Poolpumpe anfänglich unabhängig von einander planen und schalten lassen, doch SolarForecast hat die Wärmepumpe (mit 1,8kW) öfters der Poolpumpe (0,6kW) bevorzugt und tie Heizung eingeschaltet, die Pumpe nicht. Damit läuft bei mir aber die Heizung nicht. Daher habe ich für die Heizung als swoncond eine eingeschaltete Pumpe. Funktioniert soweit. Warmwasser breite ich unabhängig vom Überschuss auf, nur den Boost schalte ich bei Überschuss.
Hier gleich meine erste Frage:
Wie schaffe ich es, bei wenig Ertrag, dass die Warmwasseraufbereitung auf jeden Fall der Poolpumpe und -heizung bevorzugt behandelt wird? Warmwasser und Poolpumpe haben ähnlichen Verbrauch.
Ich hatte auch bei den Haushaltsgeräten dem Parameter power= mit den Werten vom Typenschild definiert. Als Ergebnis hat SolarForecast die Geräte eingeplant und Warmwasser, sowie Pool trotz Überschuss nicht eingeschaltet (hat eben auf die Haushaltsgeräte gewartet). Nun lässt sich meine bessere Hälfte einerseits nicht vorschreiben an welchem Tag, und um wieviel Uhr sie die Geräte einschalten soll. Das würde aus meiner Sicht auch keinen Sinn machen, denn Wäsche waschen um 9 Uhr ist vllt nicht das Gelbe vom Ei. Und unterbrechen darf die Waschmaschine auch nicht. Somit habe ich Power=0 definiert und ich sehe zumindest wo der Strom einfließt.
Frage: habe ich da etwas falsch gemacht oder welche Verbesserungsvorschläge gibt es, dass ich die (smarten) Haushaltsgeräte vernünftig einbinden und steuern kann?
Ich danke für die Anregungen, denn ganz besonders bezüglich Haushaltsgeräte habe ich gar keine Infos hier im Forum gefunden, dabei bin ich davon ausgegangen, dass diese irgendwie "berücksichtigt" werden, zumal es sogar Typdefinitionen (type=dischwasher) dafür gibt
Hallo ralley,
ZitatWie schaffe ich es, bei wenig Ertrag, dass die Warmwasseraufbereitung auf jeden Fall der Poolpumpe und -heizung bevorzugt behandelt wird? Warmwasser und Poolpumpe haben ähnlichen Verbrauch.
Wenn die Warmwasser und Poolpumpe ähnliche Leistungswerte haben, kannst du mit der Reihenfolge der Consumerdefinition; also der Nummern Consumer01 ... XX; Einfluß nehmen. So hat Consumer02 eine höhere "Wertigkeit" als Consumer03 oder höher (das Modul berücksichtigt die Consumer bei jedem Zyklus in der Reihenfolge 01, 02,...XX). Natürlich nur wenn die weiteren definierten Parameter ähnlich sind und Conditionparameter kein anderes Verhalten initiieren.
Du kannst auch den power-Key bewusst zur Steuerung verwenden indem du power niedriger ansetzt als eigentlich lt. Typenschild vorliegt. Dadurch kann natürlich passieren, dass nach Einschalten des Verbrauchers der Überschuß negativ wird. Deswegen muß man es beobachten inwieweit diese Maßnahme hilft oder evtl. überzieht.
ZitatFrage: habe ich da etwas falsch gemacht oder welche Verbesserungsvorschläge gibt es, dass ich die (smarten) Haushaltsgeräte vernünftig einbinden und steuern kann?
Die Haushaltsgeräte unterliegen keiner Sonderbehandlung gegenüber anderen Geräten. Die Typangaben dienen dazu das Laufzeit und Lastverhalten mit einem default-Wert intern vorzulegen.
Wenn du die Waschmaschine z.B. nicht planen willst, weil sie ohnehin höherer Gewalt ;) unterliegt, kannst du im Verbraucher den Key "type=noSchedule" setzen.
Allgemeiner Hinweis:
Per default erfolgt keine Unterbrechnung eines gestarteten Verbrauchers.
Wenn man Ungreimtheiten in Planung und/oder Verbraucherschaltung vermutet, hilft bei der Analayse die Ausgabe von ctrlDebug=consumerPlanning bzw. ctrlDebug=consumerSwitchingXX.
Sonst kann es schwierig sein eine fundierte Aussage zu treffen warum das Verhalten so wie beobachtet stattfindet und nicht wie an es vllt. erwartet.
Hallo zusammen,
ich habe auch eine kleine Frage: Ich habe mein Solarforecast mit zwei Consumern (Ladegeräte für's E-Bike) wie folgt konfiguriert
defmod Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast affectConsForecastIdentWeekdays 1
attr Forecast consumer01 SP.LaderH type=charger power=200 icon=electric_car_charger on=on off=off etotal=energy:Wh pcurr=power:W mode=can auto=automatic
attr Forecast consumer02 SP.LaderK type=charger power=200 icon=electric_car_charger on=on off=off etotal=energy:Wh pcurr=power:W mode=can auto=automatic
attr Forecast ctrlStatisticReadings todayConsumptionForecast,todayGridConsumption,todayGridFeedIn
attr Forecast ctrlWeatherDev1 OpenMeteoDWDEnsemble-API
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicAnimate 1
attr Forecast flowGraphicShowConsumerRemainTime 1
attr Forecast graphicBeam3Content gridconsumption
attr Forecast graphicBeam4Content consumptionForecast
attr Forecast graphicHistoryHour 6
attr Forecast graphicLayoutType double
attr Forecast room 25_Energie,90_Devices
attr Forecast verbose 2
Da ja der type=charger ist und power=200, habe ich angenommen, dass trotz genügend PV-Leistung erzeugt wird, der Lader nur angeht, wenn auch mindestens 200W vom Lader verbraucht werden. Dem ist aber wohl nicht so. Als ich heute mittag vom Biken zurück gekommen bin, war der Lader bereits an, obwohl die Bikes nicht dran hingen und der Verbrauch vom Lader unter 3W lag.
Kann ich denn irgendwie dafür sorgen, dass der Lader nur angeht, wenn auch ein Bike geladen wird? In dem Fall liegt der Verbrauch etwa bei 200 W und dann soll, sofern genug Einspeisung vorhanden ist, der Lader auch für 2h angehen. Geht das direkt im SolarForecast Modul oder muss ich da etwas komplizierteres programmieren?
Viele Grüße
ZitatDa ja der type=charger ist und power=200, habe ich angenommen, dass trotz genügend PV-Leistung erzeugt wird, der Lader nur angeht, wenn auch mindestens 200W vom Lader verbraucht werden.
Das ist irgendwie ein Henne-Ei Problem. SF weiß ja nicht ob ein Fahrrad am Lader hängt und kann erst feststellen ob 200W verbraucht werden _nachdem_ der Lader eingeschaltet wurde.
ZitatKann ich denn irgendwie dafür sorgen, dass der Lader nur angeht, wenn auch ein Bike geladen wird?
Die Frage wäre m.M. nach so zu stellen:
Kann ich denn irgendwie dafür sorgen, dass der Lader nur angeht, wenn auch ein Bike zum Laden angeschlossen ist?
Ja kann man indem dem Modul über einen Sensor, Taster, Switch etc. mitgeteilt wird, dass ein Fahrrad angeschlossen ist. Dieser Status wird dann über den Key
swoncond mitgeteilt um den Einschaltvorgang innerhalb der Planungszeit freizuschalten.
Zitat von: DS_Starter am 07 Juli 2024, 21:03:15Die Haushaltsgeräte unterliegen keiner Sonderbehandlung gegenüber anderen Geräten. Die Typangaben dienen dazu das Laufzeit und
Wenn du die Waschmaschine z.B. nicht planen willst, weil sie ohnehin höherer Gewalt ;) unterliegt, kannst du im Verbraucher den Key "type=noSchedule" setzen.
:)) :)) :))
Zitat von: DS_Starter am 07 Juli 2024, 21:03:15Wenn die Warmwasser und Poolpumpe ähnliche Leistungswerte haben, kannst du mit der Reihenfolge der Consumerdefinition; also der Nummern Consumer01 ... XX; Einfluß nehmen. So hat Consumer02 eine höhere "Wertigkeit" als Consumer03 oder höher (das Modul berücksichtigt die Consumer bei jedem Zyklus in der Reihenfolge 01, 02,...XX). Natürlich nur wenn die weiteren definierten Parameter ähnlich sind und Conditionparameter kein anderes Verhalten initiieren.
Super, danke für den Tip. Das werde ich gleich mal so umdefinierten. Heute ist's ohnehin bewölkt, da kann ich das sofort gut ausprobieren.
Grüße Rallye
Hallo zusammen,
ich nutze das Modul schon eine Weile und bin gut zufrieden damit.
Meine Anlage ist allerdings Autark (Inselanlage), das bedeutet ich kann nicht einspeisen, ich denke das wenn nun meine Batterie voll ist, die Statistik falsch fortgeschrieben wird.
Gibt es eine Möglichkeit dem Modul mitzuteilen das die Anlage in die Abregelung geht um eine falsche Korrektur der vorhersage auszuschließen?
Gruß Michael
Hallo Michael,
die Implementierung von Inselanlagen ist noch ein offener Punkt.
Es gibt bereits gedankliche Ansätze für eine mögliche Lösung ( z.B. von kask weiter vorn), aber eine Umsetzung ist bisher nicht erfolgt.
Wenn ich die Weiterentwicklung des Moduls wieder aufnehme, wird dieses Feature ein Punkt sein.
Grüße,
Heiko
Zitat von: DS_Starter am 07 Juli 2024, 21:25:39ZitatDa ja der type=charger ist und power=200, habe ich angenommen, dass trotz genügend PV-Leistung erzeugt wird, der Lader nur angeht, wenn auch mindestens 200W vom Lader verbraucht werden.
Das ist irgendwie ein Henne-Ei Problem. SF weiß ja nicht ob ein Fahrrad am Lader hängt und kann erst feststellen ob 200W verbraucht werden _nachdem_ der Lader eingeschaltet wurde.
ZitatKann ich denn irgendwie dafür sorgen, dass der Lader nur angeht, wenn auch ein Bike geladen wird?
Die Frage wäre m.M. nach so zu stellen:
Kann ich denn irgendwie dafür sorgen, dass der Lader nur angeht, wenn auch ein Bike zum Laden angeschlossen ist?
Ja kann man indem dem Modul über einen Sensor, Taster, Switch etc. mitgeteilt wird, dass ein Fahrrad angeschlossen ist. Dieser Status wird dann über den Key swoncond mitgeteilt um den Einschaltvorgang innerhalb der Planungszeit freizuschalten.
Zitat von: DS_Starter am 07 Juli 2024, 21:25:39ZitatDa ja der type=charger ist und power=200, habe ich angenommen, dass trotz genügend PV-Leistung erzeugt wird, der Lader nur angeht, wenn auch mindestens 200W vom Lader verbraucht werden.
Das ist irgendwie ein Henne-Ei Problem. SF weiß ja nicht ob ein Fahrrad am Lader hängt und kann erst feststellen ob 200W verbraucht werden _nachdem_ der Lader eingeschaltet wurde.
ZitatKann ich denn irgendwie dafür sorgen, dass der Lader nur angeht, wenn auch ein Bike geladen wird?
Die Frage wäre m.M. nach so zu stellen:
Kann ich denn irgendwie dafür sorgen, dass der Lader nur angeht, wenn auch ein Bike zum Laden angeschlossen ist?
Ja kann man indem dem Modul über einen Sensor, Taster, Switch etc. mitgeteilt wird, dass ein Fahrrad angeschlossen ist. Dieser Status wird dann über den Key swoncond mitgeteilt um den Einschaltvorgang innerhalb der Planungszeit freizuschalten.
OMG. Klar. War 'n Denkfehler von mir. Sorry.
Danke trotzdem für die Aufklärung.
Viele Grüße
Holger
Guten Abend
Ich hatte gestern die Idee, einen Luftentfeuchter im Keller als Consumer über das Modul zu steuern. Geschaltet werden soll über einen Homematic Schaltaktor mit Leistungsmessung. Der hat allerdings die Eigenheit, dass er in mehrere Kanäle aufgeteilt ist. Einmal der Aktor selbst, dann Aktor_Sw zum schalten und Aktor_Pwr zum messen. Wenn ich als Device Name den Aktor selbst nehme und als switchdev den Kanal Aktor_SW, bekomme ich Probleme mit pcurr und etotal. Die Readings dafür sind im Aktor_Pwr Kanal hinterlegt und das gebe ich ja nicht an.
Nehme ich als Device Name den Aktor_Pwr Kanal und setze pcurr und etotal, werden keine Werte angezeigt. Auf welches Device beziehen sich die Werte? Auf das switchdev? Das Beispiel im Wiki bezieht sich auf einen Shelly Schalter, da ist wahrscheinlich alles unter einem Hut.
Gruß
edition
Zur Not ein Dummy anlegen und notify/doif zum schalten und status setzen. Dann ist alles unter einem hut.
Oder schiebe doch das Aktor_Pwr als reading in Aktor via userreadings und ein notify/doif zum schalten des Aktor_Sw als Reaktion auf den status des dummys.
Würde ich jetzt so machen.
Nabend edition,
die Hilfe zu consumerXX, switchdev beschreibt welche Werte/Readings sich auf das angegebene switchdev beziehen (Schlüssel on, off, swstate, auto, asynchron).
Alle anderen Schlüssel werden in dem <Device Name> gesucht/erwartet.
Hier ist ein Beispiel meines Homematic Consumers:
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
eg.az.fridge_Pwr ist der Power-Kanal und eg.az.fridge_Sw der Schaltkanal des Homematic.
Wenn du nicht zurecht kommst, ctrlDebug=consumerSwitchingXX setzen und die Ausgabe posten. Hilfreich ist auch ein Auszug des Consumers (get ... valConsumerMaster XX).
Edit: kask war bisschen schneller. So kann man es natürlich auch machen.
Also doch Aktor_Pwr als Device Name. Dabei habe ich auch den Fehler gefunden: Da ich es vorher mit Aktor ald Device Name versucht habe, stand nach pcurr und etotal noch Aktor_Pwr power und Aktor:Pwr energyCalc. Dann brauch ich mich nicht wundern, dass es nicht angezeigt wird.
pcurr wird jetzt angezeigt, aber etotal (noch) nicht. Da werde ich morgen noch mal nachsehen, wenn der Entfeuchter wieder in Betrieb ist.
Danke für die Hilfe
edition
Hi DS_Starter,
ein
{FHEM::SolarForecast::HistoryVal($defs{'PVForecast'},'17','99','con',0)}
bringt mir wie gewünscht die Consumption von gestern.
mach ich ein gcon
{FHEM::SolarForecast::HistoryVal($defs{'PVForecast'},'17','99','gcon',0)}
bekomm ich 0 obwohl der Wert wenn ich über get PVForecast pvHistory 17 abrufe und runter zu 99 scrolle ungleich 0 ist.
Hab ich einen Denkfehler oder klemmt es da irgendwo?
Danke
Das ist wohl eher mein Fehler. Der Wert heißt intern "gcons" (Gridconsumption), also:
{FHEM::SolarForecast::HistoryVal($defs{'PVForecast'},'17','99','gcons',0)}
In der nächsten Version werde ich das Label bei "get PVForecast pvHistory" anpassen damit es nicht verwirrt.
LG
@all,
irgendwo weiter vorn kam mal der Verdacht auf, im Modul gibt es ein Memory Leak. Wir (kask/ich) konnten es nicht nachvollziehen was nicht heißen soll dass evtl. bei einer bestimmsten Konfiguration soetwas nicht vorkommen kann.
Jedenfalls habe ich mich von dem Beitrag (https://forum.fhem.de/index.php?topic=135407.0) inspirieren lassen und ein kleines Helferlein gebastelt um Speicherprobleme eingrenzen zu können.
Das hat jetzt nicht direkt etwas mit Solarforecast zu tun, aber ich wollte es euch nicht vorenthalten weil das Tool allgemein ganz nützlich sein kann.
Wen es interessiert, kann sich den nachfolgenden Code als "Raw Definition" in sein FHEM einfügen. Es wird ein Dummy erstellt. Im Attr comment ist beschrieben was man als Voraussetzung benötigt und wie man das Tool verwenden kann.
defmod memUsage dummy
attr memUsage alias Perl Speicherverbrauch
attr memUsage cmdIcon memInit:general_prep memRec:info_info
attr memUsage comment Verwendung\
==========\
1. das CPAN-Modul Memory::Usage muß installiert sein (https://metacpan.org/pod/Memory::Usage)\
bzw. Debian: apt-get install libmemory-usage-perl\
2. mit 'set <Name> memInit [Text]' die Aufzeichung starten\
3. mit 'set <Name> memRec [Text]' eine Auswertung triggern, die Werte werden seit 'memInit' ermittelt\
4. ein 'set <Name> memRec [Text]' kann mehrfach ausgeführt werden\
5. ein erneutes 'set <Name> memInit [Text]' startet die Aufzeichung mit dem aktuellen Zeitstempel neu\
\
in einem Programm\
=================\
1. fhem ("set memUsage memInit Start $name API");;\
2. fhem ("set memUsage memRec $name API Sequenz finished");;\
\
Memory::Usage \
=============\
Return arrayref of internal state. Returned arrayref contains zero or more references to arrays with the following columns (in order). All sizes are in kilobytes.\
\
- time_init, time_check: timestamp in seconds since epoch\
\
- MSG: message as passed to ->record() \
\
- VSZ: virtual memory size\
In Perl bezieht sich das Konzept der virtuellen Speichergröße auf die Menge an Speicher, die ein Prozess \
adressieren kann.\
\
- RSS: resident set size\
Die Resident Set Size in Perl stellt grob die Gesamtmenge an physischem Speicher dar, die einem Prozess \
zu einem bestimmten Zeitpunkt zugewiesen ist.\
\
- SHM: shared memory size\
In Perl bezieht sich der Begriff Shared Memory auf Speicher, auf den mehrere Prozesse gleichzeitig \
zugreifen können. \
\
- TXT: text (aka code or exe) size\
\
- DATA: data and stack size\
Die 'data size' stellt den Speicher dar, der von den globalen Variablen des Programms, den statischen \
Variablen und dem dynamisch zugewiesenen Speicher (z. B. Datenstrukturen) verwendet wird.\
Die 'stack size' bezieht sich auf den Aufrufstapel, auf dem Funktionsaufrufe und lokale Variablen verwaltet \
werden. Jeder Funktionsaufruf erzeugt einen neuen Stapelrahmen, der lokale Variablen und Funktionsparameter \
enthält.\
\
Weblinks\
========\
Forum: https://forum.fhem.de/index.php?topic=135407.0\
Forum: https://forum.fhem.de/index.php?msg=1291213\
Perl Maven: https://perlmaven.com/how-much-memory-does-the-perl-application-use
attr memUsage room SYSTEM
attr memUsage setList memInit memRec
attr memUsage stateFormat <b>Init - Time:</b> time_init, <b>Virtual Mem Size:</b> VSZ_init kB <br>\
<b>Check - Time:</b> time_check, <b>Virtual Mem Size:</b> VSZ_check kB <br>\
<b>Diff Total: </b> VSZ_diff kB
attr memUsage userReadings check:(memRec|memInit).* {\
use Memory::Usage;;\
my $result = 'initialized';;\
my $rspec = '^(Data.*|RSS.*|SHM.*|TXT.*|VSZ.*|check|time.*|records)$';;\
my $action = ReadingsVal ($name, 'state', 'check');;\
my $actmsg = (split ' ', $action, 2)[1];;\
my ($timestamp0, $msg0, $vsz0, $rss0, $shared0, $text0, $data_stack0);;\
\
if ($action =~ /memInit/xs) { # initiate profiling \
for my $r ( grep { /$rspec/x } keys %{$hash->{READINGS}} ) {\
readingsDelete ($hash, $r);;\
}\
\
$actmsg = $actmsg ? $actmsg : 'Start profiling';;\
$hash->{helper}{mu} = Memory::Usage->new();;\
$hash->{helper}{mu}->record ($actmsg);;\
\
my $state_ref = $hash->{helper}{mu}->state;;\
($timestamp0, $msg0, $vsz0) = @{$state_ref->[0]};;\
\
readingsBulkUpdate ($hash, "time_init", FmtDateTime ($timestamp0));;\
readingsBulkUpdate ($hash, 'time_check', '-');;\
readingsBulkUpdate ($hash, "VSZ_init", $vsz0);;\
readingsBulkUpdate ($hash, 'VSZ_check', '-');;\
readingsBulkUpdate ($hash, 'VSZ_diff', '-');;\
\
return $result;;\
}\
\
if (defined($hash->{helper}{mu})) { # Read result and keep it\
$actmsg = $actmsg ? $actmsg : 'Check';;\
$hash->{helper}{mu}->record($actmsg);;\
\
my $state_ref = $hash->{helper}{mu}->state;;\
my $li = $#{$state_ref};;\
\
readingsBulkUpdate ($hash, 'records', $li + 1);;\
\
($timestamp0, $msg0, $vsz0, $rss0, $shared0, $text0, $data_stack0) = @{$state_ref->[0]};;\
\
$result = sprintf("%s\n", '_____Time_____ ___VSZ___ ___RSS___ ___SHM___ ___TXT___ ___DATA__ ______MSG______');;\
\
$result .= sprintf("%s, %8d, %8d, %8d, %8d, %8d, %s\n",\
(split '-',FmtDateTime ($timestamp0),2)[1], $vsz0, $rss0, $shared0, $text0, $data_stack0, $msg0);;\
\
readingsBulkUpdate ($hash, 'time_init', FmtDateTime ($timestamp0));;\
readingsBulkUpdate ($hash, 'VSZ_init', $vsz0);;\
readingsBulkUpdate ($hash, 'RSS_init', $rss0);;\
readingsBulkUpdate ($hash, 'SHM_init', $shared0);;\
readingsBulkUpdate ($hash, 'TXT_init', $text0);;\
readingsBulkUpdate ($hash, 'Data_Stack_init', $data_stack0);; \
\
if ($li >= 1) {\
my ($timestamp2, $msg2, $vsz2, $rss2, $shared2, $text2, $data_stack2);;\
my ($timestamp_d, $vsz_d, $rss_d, $shared_d, $text_d, $data_stack_d);;\
my ($timestamp1, $msg1, $vsz1, $rss1, $shared1, $text1, $data_stack1) = \
($timestamp0, $msg0, $vsz0, $rss0, $shared0, $text0, $data_stack0);;\
\
for my $i (1..$li) { \
($timestamp2, $msg2, $vsz2, $rss2, $shared2, $text2, $data_stack2) = @{$state_ref->[$i ]};;\
\
$timestamp_d = $timestamp2 - $timestamp1;; # time in seconds between records\
$vsz_d = $vsz2 - $vsz1;; # virtual memory size\
$rss_d = $rss2 - $rss1;; # resident set size\
$shared_d = $shared2 - $shared1;; # shared memory size\
$text_d = $text2 - $text1;; # text (aka code or exe) size\
$data_stack_d = $data_stack2 - $data_stack1;; # data and stack size\
\
$result .= sprintf("%s, %8d, %8d, %8d, %8d, %8d, %s\n",\
(split '-',FmtDateTime ($timestamp2),2)[1], $vsz2, $rss2, $shared2, $text2, $data_stack2, $msg2);;\
\
$result .= sprintf("%14d, %8d, %8d, %8d, %8d, %8d, %s\n",\
$timestamp_d, $vsz_d, $rss_d, $shared_d, $text_d, $data_stack_d, 'Diff');;\
\
$timestamp1 = $timestamp2;;\
$vsz1 = $vsz2;;\
$rss1 = $rss2;;\
$shared1 = $shared2;;\
$text1 = $text2;;\
$data_stack1 = $data_stack2;;\
}\
\
readingsBulkUpdate ($hash, 'time_check', FmtDateTime ($timestamp2));;\
readingsBulkUpdate ($hash, 'VSZ_check', $vsz2);;\
readingsBulkUpdate ($hash, 'RSS_check', $rss2);;\
readingsBulkUpdate ($hash, 'SHM_check', $shared2);;\
readingsBulkUpdate ($hash, 'TXT_check', $text2);;\
readingsBulkUpdate ($hash, 'Data_Stack_check', $data_stack2);;\
\
readingsBulkUpdate ($hash, 'time_diff', $timestamp2 - $timestamp0);;\
readingsBulkUpdate ($hash, 'VSZ_diff', $vsz2 - $vsz0);;\
readingsBulkUpdate ($hash, 'RSS_diff', $rss2 - $rss0);;\
readingsBulkUpdate ($hash, 'SHM_diff', $shared2 - $shared0);;\
readingsBulkUpdate ($hash, 'TXT_diff', $text2 - $text0);;\
readingsBulkUpdate ($hash, 'Data_Stack_diff', $data_stack2 - $data_stack0);;\
}\
}\
else {\
for my $r ( grep { /$rspec/x } keys %{$hash->{READINGS}} ) {\
readingsDelete ($hash, $r);;\
}\
\
return "use 'set $name memInit [Message]' first to start profiling";;\
}\
\
return $result;;\
}
attr memUsage webCmd memInit:memRec
attr memUsage widgetOverride action:init,check
Man kann es manuell bedienen. Aber wertvoller ist es wenn man in seinen eigenen Perl-Code an den verdächtigen Stellen den Befehl:
fhem ("set memUsage memRec <Label>");
einfügt. Die Initialisierung macht man manuell oder automatisch mit "set <Name> memInit [Label]".
Dann kommt zum beispiel so etwas im Reading check heraus:
_____Time_____ ___VSZ___ ___RSS___ ___SHM___ ___TXT___ ___DATA__ ______MSG______
07-18 21:31:40, 486052, 438188, 19416, 1620, 417976, Start profiling
07-18 21:32:13, 486052, 438188, 19416, 1620, 417976, Start SolCast6 get DWD Werte
33, 0, 0, 0, 0, 0, Diff
07-18 21:32:13, 486052, 438188, 19416, 1620, 417976, Finished SolCast6 get DWD
0, 0, 0, 0, 0, 0, Diff
07-18 21:32:27, 486052, 438188, 19416, 1620, 417976, Start SolCast6 get DWD Werte
14, 0, 0, 0, 0, 0, Diff
07-18 21:32:27, 486052, 438188, 19416, 1620, 417976, Finished SolCast6 get DWD
0, 0, 0, 0, 0, 0, Diff
07-18 21:33:42, 486052, 438188, 19416, 1620, 417976, Start SolCast6 get DWD Werte
75, 0, 0, 0, 0, 0, Diff
07-18 21:33:42, 486052, 438188, 19416, 1620, 417976, Finished SolCast6 get DWD
0, 0, 0, 0, 0, 0, Diff
07-18 21:34:57, 486052, 438188, 19416, 1620, 417976, Start SolCast6 get DWD Werte
75, 0, 0, 0, 0, 0, Diff
07-18 21:34:57, 486052, 438188, 19416, 1620, 417976, Finished SolCast6 get DWD
0, 0, 0, 0, 0, 0, Diff
07-18 21:36:12, 486052, 438188, 19416, 1620, 417976, Start SolCast6 get DWD Werte
75, 0, 0, 0, 0, 0, Diff
07-18 21:36:12, 486052, 438188, 19416, 1620, 417976, Finished SolCast6 get DWD
0, 0, 0, 0, 0, 0, Diff
Bei der Zeile "Diff" sieht man die jeweiligen Änderung zur vorherigen Messung (Zeile) sofern vorhanden.
Wichtig zu beachten: Der Speicherwert bezieht sich auf den gesamten Perl-Prozess und nicht auf die Stelle an sich. Aber es kann u.U. helfen markante Stellen im Code zu anlaysieren ob deren Abarbeitung einen starken Einfluß auf den Speicherverbrauch hat.
LG
Zitat von: DS_Starter am 18 Juli 2024, 21:39:35irgendwo weiter vorn kam mal der Verdacht auf, im Modul gibt es ein Memory Leak. Wir (kask/ich) konnten es nicht nachvollziehen was nicht heißen soll dass evtl. bei einer bestimmsten Konfiguration soetwas nicht vorkommen kann.
Das habe ich wohl mal aufgebracht bzw. hinterfragt ob es eventuell so sein könnte. Mittlerweile bin ich durch Zufall einen Schritt weiter und habe fhempy_local als Ursache ausgemacht.
(Wie bin ich draufgekommen: Bei/nach einem "update" wird fhempy_local automatisch neu gestartet. Ich habe einmal nach einem Update, wo keine von mir genutzten Module aktualisiert wurden, vergessen "shutdown restart" zu machen und habe dann zufällig gesehen, dass die RAM-Auslastung nach dem "update" drastisch nach unten ging. Ein paar Tage später war die RAM-Auslastung wieder über meiner Benachrichtigungsschwelle. Nach einem händischen "fhempy_local restart" war der RAM wieder frei.)
Morgen liegt eine neue Version im Update.
Es ist nur etwas Codepflege und der Hinweis aus #807 / #808 umgesetzt.
LG
Ich schmeiße entspr. des Thread-Titels aus Eigeninteresse nochmal eine "Idee zur Weiterentwicklung" ein:
https://forum.fhem.de/index.php?topic=115259.msg1316942#msg1316942
O:-) O:-) O:-)
Moin Dracolein,
ich habe mir den Beitrag #792 von Bismosa und deinen Link durchgelesen.
Dabei habe ich nur Hinweise und Beispiele gefunden wie man das HTML für FTUI3 zusammenbastelt aber keine Dinge die ich im Modul verändern sollte um FTUI besser zu unterstützen.
Kann aber sein ich habe etwas nicht gesehen bzw. überlesen.
Kannst du bzw. Bismosa mir Tipps geben mit welchen Modulanpassungen FTUI3 besser unterstützt würde?
Ich bentze selbst kein FTUI und bin deswegen da auch nicht so firm, bzw. in javascript generell. ;)
LG
Zitat von: DS_Starter am 20 Juli 2024, 22:00:36Morgen liegt eine neue Version im Update.
Es ist nur etwas Codepflege und der Hinweis aus #807 / #808 umgesetzt.
LG
Danke!!
Hallo!
@DS_Starter
Eigentlich gibt es da an diesem Modul nicht wirklich was zu verbessern. Der "Workaround" mit dem zusätzlichem Script im HTML
<script>
function FW_cmd(text){
ftuiApp.fhemService.sendCommand(text.replace("/fhem?XHR=1&cmd=",""))
}
</script>
funktioniert problemlos. Also könnte höchstens eine Variante FTUI3 etwas bringen, bei dem die Links verändert sind.
Tut aber aus meiner Sicht nicht not. Das macht nur das Modul noch komplizierter. :)
Gerne kann mein Schnipsel oder ein Verweis darauf in die Hilfe/in den get Befehl übernommen werden.
Das Problem liegt da eher im FTUI3 selbst bei mir. Dafür müssen einige Änderungen vorgenommen werden. Leider scheint die Entwicklung dort nur langsam voran zu gehen. Dazu kann sich aber nur setstate äußern.
@Dracolein
Einfach mal ausprobieren und schauen, ob es nicht ohne die Änderungen der FTUI-Files funktioniert. Vielleicht liegt es ja wirklich nur an mir.
Gruß
Bismosa
Zitat von: bismosa am 21 Juli 2024, 20:02:31Hallo!
@DS_Starter
Eigentlich gibt es da an diesem Modul nicht wirklich was zu verbessern. Der "Workaround" mit dem zusätzlichem Script im HTML
<script>
function FW_cmd(text){
ftuiApp.fhemService.sendCommand(text.replace("/fhem?XHR=1&cmd=",""))
}
</script>
funktioniert problemlos. Also könnte höchstens eine Variante FTUI3 etwas bringen, bei dem die Links verändert sind.
Tut aber aus meiner Sicht nicht not. Das macht nur das Modul noch komplizierter. :)
Gerne kann mein Schnipsel oder ein Verweis darauf in die Hilfe/in den get Befehl übernommen werden.
Das Problem liegt da eher im FTUI3 selbst bei mir. Dafür müssen einige Änderungen vorgenommen werden. Leider scheint die Entwicklung dort nur langsam voran zu gehen. Dazu kann sich aber nur setstate äußern.
@Dracolein
Einfach mal ausprobieren und schauen, ob es nicht ohne die Änderungen der FTUI-Files funktioniert. Vielleicht liegt es ja wirklich nur an mir.
Gruß
Bismosa
Schaut mir recht kompliziert aus?!
ich habe ein Userreading (trigger muss man sich je nach Perfomrance überlegen) im SolarforeCast device (alternativ in einem weblink) und lade das über content in FTUI3:
attr mySolarForeCast userReadings html { FHEM::SolarForecast::pageAsHtml ('mySolarForeCast', '-', 'flow_noHead_noCons') }
und
<ftui-grid-tile row="8" col="2" height="8" width="4">
<ftui-grid-header>PV / Verbrauch</ftui-grid-header>
<ftui-row align-items="center">
<ftui-content align-items="center" [content]="mySolarForeCast:html"></ftui-content>
</ftui-row>
</ftui-grid-tile>
@DS_Starter:
Kann man davon ausgehen, dass Events im Modul mindestens dem ctrlInterval entsprechen?
Gruß,
Tobias
Hast Du damit keine Performanceprobleme? Dann wäre das eine super Lösung
Zitat@DS_Starter:
Kann man davon ausgehen, dass Events im Modul mindestens dem ctrlInterval entsprechen?
Im Prinzip ja, trifft aber nicht auf alle Readings zu weil es auch von anderen Parametern abhängt.
Das Reading nextCycletime würde sich m.M. nach am Besten dafür eignen.
Deswegen gleich der Hinweis dem userReading immer einen Trigger mitzugeben sonst kann es wirklich auf die Performance schlagen, also etwa:
attr mySolarForeCast userReadings html:nextCycletime.* { FHEM::SolarForecast::pageAsHtml ('mySolarForeCast', '-', 'flow_noHead_noCons') }
Zitat von: Dracolein am 26 Juli 2024, 12:45:35Hast Du damit keine Performanceprobleme? Dann wäre das eine super Lösung
Nein, keine Performance-Probleme, allerdings auch recht viel performance und reserve. Wie das z.B. auf einem Pi als Server aussehen wird, kann ich nicht sagen. Aber solange keine Aktualisierung der Grafik selbst erfolgt, sollte das doch statisch sein?
Habe jetzt zum Test mal eine FTUI3 HTML-Seite angelegt, die nur das enthält und über die Entwicklertools die Network-Performance angeschaut.
Das ganze wird im Schnitt in der als ctrlInterval eingestellten Zeit aktualisiert (wenn du den Hinweis von DS_Starter direkt umsetzt, exakt zum ctrlInterval). Dazwischen passiert faktisch nichts. Sollte also performant sein. Über einen entsprechenden Trigger des Userreadings (könntest du ja auch in ein at packen), kann man das Intervall auch selbst festlegen...
Gruß,
Tobias
<!DOCTYPE html>
<html>
<head>
<script src="ftui.js"></script>
<link href="ftui.css" rel="stylesheet">
<link href="themes/ftui-theme.css" rel="stylesheet">
<link href="favicon.ico" rel="icon" type="image/x-icon" />
<meta name="viewport" content="width=device-width">
<meta name="mobile-web-app-capable" content="yes">
<meta name="toast_position" content="topLeft">
<meta name="debug" content="0">
<title>Home Tablet UI</title>
</head>
<body>
<ftui-grid shape="round">
<ftui-grid-tile row="16" col="1" height="1" width="13"> <!-- Menu -->
<ftui-row>
<ftui-column>
<ftui-tab view="home" fill="solid" shape="round" active>
<ftui-icon name="home"></ftui-icon>
</ftui-tab>
</ftui-column>
</ftui-row>
</ftui-grid-tile>
<ftui-tab-view id="home"> <!-- view home -->
<ftui-grid-tile row="8" col="2" height="8" width="4">
<ftui-grid-header>PV / Verbrauch</ftui-grid-header>
<ftui-row align-items="center">
<ftui-content align-items="center" [content]="mySolarForeCast:html"></ftui-content>
</ftui-row>
</ftui-grid-tile>
</ftui-tab-view>
</ftui-grid>
</body>
</html>
Habs eingebaut, gemeinsam mit dem <style> Codeschipsel erhalte ich eine taugliche Darstellung und augenscheinlich ohne spürbare Performanceprobleme. Coole Sache, wenn das so bleibt :-)
Hallo DS_Starter,
Hallo alle SolarForecast-Interessierten,
wahrscheinlich bin ich nicht der erste der darüber stolpert - vielleicht gibt es auch keine gute Lösung.
Zunächst mal ein großes Kompliment an den Modul-Autor DS_Starter. Die geführte Installation des Moduls hat super funktioniert, auch eine Batterie konnte ich einfach definieren anhand der sehr guten Beschreibung zu den jeweiligen Attributen.
Was mir aufgefallen ist, ist der deutlich zu hohe Verbrauch, der Wert beim Häuschen und bei der Lampe, die identisch sind.
Meine Vermutung ist, dass die Wandlungsverluste DC/AC als Verbrauch aufgeführt sind, was den realen Verbrauch entsprechend erhöht.
Ich hab einen DEYE 12kW-3 Phasen-WR. Beim Attribut setupInverterDev habe ich die DC-Werte für die Leistung genommen, es gibt wohl auch AC-Werte, allerdings dann auch gleich 2 unterschiedliche Register, aber bei der Energie (etotal) gibt es nur 1 Register. Also etwas verwirrend, was denn die besseren (richtigeren?) Daten sind.
Dann noch eine Frage, warum der Wert beim Häuschen und der Lampe identisch sind. Ist das so beabsichtigt und immer so?
Viele Grüße Gisbert
Zitat von: Gisbert am 28 Juli 2024, 14:59:03Dann noch eine Frage, warum der Wert beim Häuschen und der Lampe identisch sind. Ist das so beabsichtigt und immer so?
Nur wenn im SF-Device von dir "Verbraucher" konfiguriert worden sind gibt es naturgemäß einen Unterschied zwischen "Haus" und "Lampe".
=>> Haus = Gesamtverbrauch
=>> Lampe = Gesamtverbrauch - evtl. Verbrauchsmessungen der angelegten Verbraucher)
Für die einzelnen Verbraucher werden dann die ermittelten Verbrauchswerte vom Wert "Haus" abgezogen und am jeweiligen Verbraucher anhängend angezeigt (soweit konfiguriert)
Gruß
300P
Hallo Gisbert,
freut mich dass dir die Guided Procedure gut geholfen hat. :)
Bezüglich setupInverterDev musst du dem Key "pv" den Wert der Erzeugung zuordnen der nicht evtl. durch den Batterieladeanteil vermindert wird. Ich hoffe es gibt ein solches Reading beim Deye. Im Setup der Batterie muß der Key pin bzw. pout die richtigen Werte bzgl. der aktuellen Lade/Entladeleistung liefern. Aus diesen ganzen Werten berechnet das Modul dann unter Berücksichtigung der Meterwerte (Grid in/out) den laufenden Verbrauch des Hauses.
Vllt. erkennt man anhand der Readingnamen beim Deye deren Bedeutung?
LG,
Heiko
@Gisbert
Die Lampe kannst du ausblenden bzw. nicht anzeigen lassen. Ich meine es ist das attr "flowGraphicShowConsumerDummy"
Das haus zeigt dir die kalkulierten Werte aus PV,Smartmeter und Batterie.
Alles was die PV bringt und aus dem Netzkommt rein/raus kommt und die Batterie rein/raus geht wird zusammengerechnet und ergibt den Verbrauch.
Um das plausibel zu halten solltest du die AC-Werte aus dem Umrichter und der Batterie nutzen.
Ansonsten fliessen immer die Wandlerverluste in deine Werte als Verbrauch. Ist ja auch Verbrauch.
Hallo DS_Starter und alle anderen, die mir auf meinen Beitrag #821 geantwortet haben.
Damit wird einiges klarer. Die Leistung am Haus ist ein bilanzieller Wert, der den Verbrauch im Haus und den Eigenverbrauch des Wechselrichters (Verluste etc.) umfasst. Danke auch für die Einbindung von Consumern.
Als work around könnte ich mir vorstellen, dass ich als consumer1 den "wahren" Hausverbrauch definiere (Readings dazu hab ich). Der Wert an der Lampe wäre dann der Eigenverbrauch/Wandlungsverluste des Deye-WR. Hierzu wäre es schön, wenn ich 2 andere Symbole für das Haus und die Lampe wählen könnte - in etwa so, wie es für die consumer(x) möglich ist: Icon to represent the consumer in the overview graphic (optional). Weiter gesponnen (kann gerne wörtlich verstanden werden) würden dann die Einzelconsumer am "wahren" Hausverbrauch dranhängen. Bitte letzteres maximal als Anregung sehen. Mir ist klar, dass es zu Unstimmigkeiten zur bisherigen Programmierung und deinen Anforderungen kommt. Ich wollte es trotzdem mal erwähnen, falls Ideen in dieser Richtung willkommen sind.
Das Flow Diagramm würde ich gerne links anzeigen lassen, da ich die meiste Zeit Fhem am Handy bediene. Das Attribut FlowGraphicCss hat aber dazu keine Einstellungen.
Offtopic: Häufig ist die graphische Darstellung auf kleinen Bildschirmen bei Fhem "Glückssache". Das ist generell ein zunehmend größeres Problem, weshalb u.a. die Akzeptanz von Fhem bei Hausautomations-Interessierten schwindet. Auch ehemals Fhem-Interessierte beginnen sich abzuwenden - eigentlich sehr schade angesichts dieses (und anderer) sehr schönen Module.
Viele Grüße Gisbert
ZitatHäufig ist die graphische Darstellung auf kleinen Bildschirmen bei Fhem "Glückssache". Das ist generell ein zunehmend größeres Problem, weshalb u.a. die Akzeptanz von Fhem bei Hausautomations-Interessierten schwindet. Auch ehemals Fhem-Interessierte beginnen sich abzuwenden - eigentlich sehr schade angesichts dieses (und anderer) sehr schönen Module.
Das glaube ich nicht.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Juli 2024, 15:46:05Das glaube ich nicht.
LG
pah
Und ich dachte schon es sei ein konstruktiver Beitrag.
Wie könnte denn eine Lösung der Darstellung der Tabelle, des Balken- Diagramms und des Flow-Diagramms bei einem Handy mit Hochformat-Ausrichtung aussehen, ohne dass man den Bereich von links nach rechts schwenken muss?
Mein Hauptanliegen in meinem Beitrag #825 ist die Flow-Grafik, die ich gerne statt mittig linksbündig ausgerichtet hätte, jedenfalls links und nicht in der Mitte. Damit würde mehr Inhalt ohne Schwenken sichtbar sein.
Viele Grüße Gisbert
Zitat von: Gisbert am 31 Juli 2024, 20:19:20Wie könnte denn eine Lösung der Darstellung der Tabelle, des Balken- Diagramms und des Flow-Diagramms bei einem Handy mit Hochformat-Ausrichtung aussehen, ohne dass man den Bereich von links nach rechts schwenken muss?
ich kann dich verstehen Gisbert, aber so ein 2-Finger-Zoom ist doch keine große Sache?
Zitat von: grappa24 am 01 August 2024, 16:16:14ich kann dich verstehen Gisbert, aber so ein 2-Finger-Zoom ist doch keine große Sache?
Hallo grappa24,
es wäre kein Zoom sondern das Gegenteil davon nötig, was aber auf meinem Handy und Chrome-Browser nicht geht. Selbst wenn eine Verkleinerung gehen würde, wäre ein Hin- und Herschwenken besser geeignet, da die Verkleinerung zu stark wäre.
Viele Grüße Gisbert
Zitatwas aber auf meinem Handy und Chrome-Browser nicht geht.
Das ist nur ein vorübergehendes Problem bis zur nächsten und hoffentlich etwas besseren Handy-Version. Man kann doch keine Entwicklung für obsolete Geräte betreiben.
LG
pah
P.S.:
Zitat von: Gisbert am 31 Juli 2024, 20:19:20Und ich dachte schon es sei ein konstruktiver Beitrag.
Der war sicher konstruktiver als die aus der Luft gesogene Behauptung, "Interessierte würden sich von FHEM abwenden".
Zitat von: Prof. Dr. Peter Henning am 02 August 2024, 08:49:37Der war sicher konstruktiver als die aus der Luft gesogene Behauptung, "Interessierte würden sich von FHEM abwenden".
Hallo pah,
ich habe
- leider - eine andere Wahrnehmung und möchte aber den Thread mit dem offtopic-Inhalt nicht belasten.
Viele Grüße Gisbert
Hi ich hätte eine kurze Frage.
a) Ich habe mein Haus über SmartVISU als Frontend visualisiert.
Besteht die Möglichkeit hier auch die Grafik von SolarForecast einzubetten
oder gibt es ein HTML modell welches man verwenden kann?
b) der Hinweis das attribute in DWD forecastRefresh auf unter 6 zu setzen ist nicht möglicht
Bei mir gibt es kein Attribute forecastRefresh in DWD.
c) ich habe noch einen weiteren Stromerzeuger (BHKW). Kann man diesen auch irgendwie
als Erzeuger in den SolarForeCast einbauen?
Zitat von: Hackstall am 05 August 2024, 12:29:54Hi ich hätte eine kurze Frage.
a) Ich habe mein Haus über SmartVISU als Frontend visualisiert.
Besteht die Möglichkeit hier auch die Grafik von SolarForecast einzubetten
oder gibt es ein HTML modell welches man verwenden kann?
b) der Hinweis das attribute in DWD forecastRefresh auf unter 6 zu setzen ist nicht möglicht
Bei mir gibt es kein Attribute forecastRefresh in DWD.
c) ich habe noch einen weiteren Stromerzeuger (BHKW). Kann man diesen auch irgendwie
als Erzeuger in den SolarForeCast einbauen?
Info zu
A) kann man - ist meines Wissens nach auch in den letzten Wochen mal Thema gewesen und hier im Thread nachzulesen.
B) evtl. im Device das Attribut einmalig auf 6 setzen und dann den RAW-Wert manuell nach einem ,,save" direkt am Attribut auf 1 ändern 😉 sollte funktionieren.
(Screenshot)
C) BHKW hab ich auch - ich habe vom BHKW die Erzeugungsleistung mit zu meinem ,,Inverterdummy" addiert.
Verändert etwas die Prognose - aber bei meinen 0,750 kWH/Stunde ist das dann sehr wenig einflussnehmend in der Prognose.
....aber die BHKW-Leistung wird dann 24 h angezeigt. 😎
Danke aber wenn ichs manuell mache kommt:
DWD: unknown attribute forecastRefresh. Type 'attr DWD ?' for a detailed list.
Zuerst das attr mit dem Wert 6 anlegen im Device ?!?
Dann fhem.cfg speichern...
Jetzt das DWD-Device erneut aufrufen und schauen ob das attr mit aufgeführt wird.
Wenn ja - dann mittels editieren des Attributes (raw definition ganz unten - unterhalb der Attribute auswählen) auf 1 stellen und dann wieder alles speichern....
ZitatDWD: unknown attribute forecastRefresh. Type 'attr DWD ?' for a detailed list.
Ich vermute du musst erst das weiterentwickelt DWD aus meinem contrib laden. Das offizielle Modul hat diese Weiterentwicklungen noch nicht eingecheckt.
Mal ne doofe Frage, was macht ihr mit den Blockheizkraftwerken?
Ein BKW könntest man auch als weiteren String einbinden mit der Summe aus allen Strings zum Ertrag.
Mache ich auch so. Bzw. vermutlich auch jeder der verschiedene Ausrichtungen und/oder mehrere Wechselrichter hat.
Dann stimmt das auch mit der Prognose.
Sorry aber jetzt muss ich doch nochmal weiter ausholen. Ich möchte das Modul nämlich zum laufen bekommen:
a) DWD aus contrib wie funktioniert das? OK, habe ich geschafft, jetzt kann ich refresh bearbeiten
b) Ich habe seit gestern auch auf KI umgestellt seitdem nun doch Probleme:
1) Derzeit ist KI auf gelb? Was bedeutet das?
2) Heute morgen bestand die Grafik aus grünen und blauen Balken wobei die grünen viel zu ungenau waren
Jetzt habe ich keine grünen und blauen Balken mehr sondern nur noch blaue.
Das war bevor ich auf KI umgestellt hatte nicht der Fall. Muss KI erst noch lernen?
3) Latitude, Longitude und Altitude stehen richtig.
c) Was ist forecastPruning 0/1? Was bedeutet das?
Danke bitte um Hilfe
Zitatb) Ich habe seit gestern auch auf KI umgestellt seitdem nun doch Probleme:
1) Derzeit ist KI auf gelb? Was bedeutet das?
Probleme? .. Naja :-)
Gehe mit der Maus über die gelbe Ampel und du siehst was es bedeutet (Screenshot von mir im Anhang).
Zitat2) Heute morgen bestand die Grafik aus grünen und blauen Balken wobei die grünen viel zu ungenau waren
Jetzt habe ich keine grünen und blauen Balken mehr sondern nur noch blaue.
Das war bevor ich auf KI umgestellt hatte nicht der Fall. Muss KI erst noch lernen?
Aus bei den Balken sieht man mit Mouse Over was sie bedeuten. Die Farbe ist vom Nutzer festlegbar und sagt uns erstmal nichts. KI muß natürlich lernen, aber das ist kein Problem weil das Modul immer zwischen KI und "normaler" Vorhersage nach einer bestimmten Logik auswählt.
Bedenke auch ... eine Vorhersage ist keine genaue Wissenschaft und wird immer Abweichungen haben. Voraussetzung für gute Ergebnisse ist aber dass man als User die verlangten Anlagenparameter so gut und richtig wie möglich angibt.
Zitat von: Hackstall am 06 August 2024, 19:24:44Sorry aber jetzt muss ich doch nochmal weiter ausholen. Ich möchte das Modul nämlich zum laufen bekommen:
a) DWD aus contrib wie funktioniert das?
b) Ich habe seit gestern auch auf KI umgestellt seitdem nun doch Probleme:
1) Derzeit ist KI auf gelb? Was bedeutet das?
2) Heute morgen bestand die Grafik aus grünen und blauen Balken wobei die grünen viel zu ungenau waren
Jetzt habe ich keine grünen und blauen Balken mehr sondern nur noch blaue.
Das war bevor ich auf KI umgestellt hatte nicht der Fall. Muss KI erst noch lernen?
3) Latitude, Longitude und Altitude stehen richtig.
Danke bitte um Hilfe
Zu A) Schau mal ins Contrib von DS_Starter ;)
Zu B1) Halte deine Maus auf den gelben Punkt :o -> Erklärung
Zu B2) Ja DWD-KI muss lernen siehe B1
Die Grafikanzeige von SF ist konfigurierbar auf den eigenen "Geschmack"
"LESE" mal in der Online-Hilfe unter den Attributen mit dem Namen "flowGrafik......" und "graphicBeam...."
Auch hier - halte die Maus auf die Grafikanzeigen :o
zu B3) Auch hier ....etwas mehr lesen bildet =>> attr DWD forecastStation XYXYXY sollte im "Device DWD" eingestellt werden.
PS:
(..leider zu spät.... DS_Starter war schneller)
Zitat von: Hackstall am 06 August 2024, 19:24:44c) Was ist forecastPruning 0/1? Was bedeutet das?
Danke bitte um Hilfe
Danke gerne == Fragen zum DWD-Device bitte im Thread vom DWD_OpenData Device ;D
Onlinehilfe :
forecastPruning {0|1}, default: 0
Search for and delete forecast readings that are more then one day older then other forecast readings of the same day. Pruning will be performed after a successful forecast update.
Notes:
- Intended to maintain data consistency e.g. when a forecast station changes the reporting hour of a forecast property.
- Requires noticable extra computing resources and may cause side effects if your FHEM configuration depends on a reading that is deleted.
Hi jetzt habe ich KI mal ein wenig lernen lassen aber die Prognosen und der Ist Wert sind irgendwie weit voneinander entfernt:
Siehe Bild
Mache ich noch irgendetwas falsch?
Danke
Mit KI hat das nichts zu tun, weil schon die normale Vorhersage im Prinzip ausreicht.
Folgende Fragen müsstest du dir / uns beantworten:
- ist der registrierte/ angezeigte tatsächliche Erzeugungswert richtig?
Soll heißen gibt es evtl. eine Diskrepanz zwischen der realen Erzeugung und der im Modul wiedergegebenen
Erzeugung.
- was bringt die Quelle der Prognose? D.h. du verwendest z.B. ein DWD-Device. Die Werte des DWD-Device
fc0_xx_Rad1h müssen sich decken mit der Ausgabe von "get ... solApiData".
zum Beispiel get ... solApiData:
2024-08-08 06:00:00 => Rad1h: 60
2024-08-08 07:00:00 => Rad1h: 210
2024-08-08 08:00:00 => Rad1h: 470
2024-08-08 09:00:00 => Rad1h: 710
2024-08-08 10:00:00 => Rad1h: 1000
2024-08-08 11:00:00 => Rad1h: 980
2024-08-08 12:00:00 => Rad1h: 1070
2024-08-08 13:00:00 => Rad1h: 1240
2024-08-08 14:00:00 => Rad1h: 1400
2024-08-08 15:00:00 => Rad1h: 1380
2024-08-08 16:00:00 => Rad1h: 1260
2024-08-08 17:00:00 => Rad1h: 1080
2024-08-08 18:00:00 => Rad1h: 700
2024-08-08 19:00:00 => Rad1h: 350
Im DWD-Device:
...
fc0_14_Rad1h 1240.00
fc0_15_Rad1h 1400.00
fc0_16_Rad1h 1380.00
....
Beachte den Versatz des Stundenwertes, das ist i.O.
Wenn das gegeben ist, prüfe noch ob die Angaben der Module und WR korrekt sind, also die Attr setupInverterDev, setupInverterStrings, setupStringPeak sowie Konfigreadings setupStringAzimuth, setupStringDeclination. Sieh dir auch die Einheiten an, zwischen W(h) und kW(h) besteht ein signifikanter Unterschied.
Übrigens hat meine DWD Installation auch eine Abweichung von 17,9 % geworfen, die anderen API OpenMeteo DWD ICON und Victron KI API waren mit -8,3 % / -5,8 % da deutlich besser.
Trotzdem noch der Hinweis, alle Lernfunktionen und auch automatischen Anpassungen passieren langsam und werden durch die Witterungslage geführt.
Eine ungefähre Vorstellung des internen Geschehens bekommt man wenn man sich die Ausgabe von "get ... pvCircular" bzw. "get ... valDecTree aiRuleStrings".
Mit der Zeit entstehen solche Zahlenkolonnen:
13 => pvapifc: 2164, pvaifc: -, pvfc: 2164, aihit: 0, pvrl: 4560
batin: 1636, batout: 18, confc: 843, gcon: 7, gfeedin: 2106, wcc: 68, rr1c: 0.00
temp: 23.50, wid: 2, wtxt: Bewölkung unverändert
pvcorrf: 5.0=1.02 5.100=1.17 5.10=1.42 5.15=1.21 5.20=0.81 5.30=0.77 5.35=1.90 5.40=1.09 5.45=2.51 5.5=0.91
5.50=0.78 5.55=1.04 5.60=0.83 5.65=0.91 5.70=1.48 5.75=0.74 5.80=0.97 5.85=0.91 5.90=0.77 5.95=0.95
10.0=1.02 10.10=1.42 10.100=1.17 10.15=1.21 10.20=0.81 10.30=0.77 10.35=1.90 10.40=1.09 10.45=2.51 10.5=0.91
10.50=0.78 10.55=1.04 10.60=0.83 10.65=0.91 10.70=1.48 10.75=0.74 10.80=0.97 10.85=0.91 10.90=0.77 10.95=0.95
15.0=1.02 15.100=1.17 15.10=1.42 15.15=1.21 15.20=0.81 15.30=0.77 15.35=1.90 15.40=1.09 15.45=2.51 15.50=0.78
15.5=0.91 15.55=1.04 15.60=0.83 15.65=0.91 15.70=1.48 15.75=0.74 15.80=0.97 15.85=0.91 15.90=0.77 15.95=0.95
20.0=1.02 20.10=1.42 20.100=1.17 20.15=1.21 20.20=0.81 20.30=0.77 20.35=1.90 20.40=1.09 20.45=2.51 20.50=0.78
20.5=0.91 20.55=1.04 20.60=0.83 20.65=0.91 20.70=1.48 20.75=0.74 20.80=0.97 20.85=0.91 20.90=0.77 20.95=0.95
25.0=1.02 25.100=1.17 25.10=1.42 25.15=1.21 25.20=0.81 25.30=0.77 25.35=1.90 25.40=1.09 25.45=2.51 25.5=0.91
25.50=0.78 25.55=1.04 25.60=0.83 25.65=0.91 25.70=1.48 25.75=0.74 25.80=0.97 25.85=0.91 25.90=0.77 25.95=0.95
30.0=1.02 30.100=1.17 30.10=1.42 30.15=1.21 30.20=0.81 30.30=0.77 30.35=1.40 30.40=1.02 30.45=2.51 30.50=0.73
30.5=0.91 30.55=1.02 30.60=0.83 30.65=0.91 30.70=0.78 30.75=0.77 30.80=0.97 30.85=0.92 30.90=0.77 30.95=0.95
35.0=1.02 35.10=1.42 35.100=1.17 35.15=1.21 35.20=0.81 35.25=1.03 35.30=0.77 35.35=1.90 35.40=1.09 35.45=2.51
35.5=0.91 35.50=0.70 35.55=1.54 35.60=1.40 35.65=0.65 35.70=0.87 35.75=0.74 35.80=0.97 35.85=1.06 35.90=0.77
35.95=1.00 40.0=1.02 40.10=1.42 40.100=1.17 40.15=1.21 40.20=0.81 40.30=0.77 40.35=1.90 40.40=1.03 40.45=1.71
40.50=0.78 40.5=0.91 40.55=1.04 40.60=0.94 40.65=1.02 40.70=0.71 40.75=0.90 40.80=0.97 40.85=1.00 40.90=0.93
40.95=0.98 45.0=1.02 45.100=1.17 45.10=1.42 45.15=1.21 45.20=0.81 45.30=0.92 45.35=1.90 45.40=1.09 45.45=2.51
45.5=0.91 45.50=0.92 45.55=1.03 45.60=0.99 45.65=0.95 45.70=1.48 45.75=0.78 45.80=1.07 45.85=0.91 45.90=0.82
45.95=0.95 50.100=0.74 50.40=0.91 50.45=0.68 50.60=0.71 50.70=0.83 50.75=1.42 50.80=1.51 50.85=0.96 55.10=0.97
55.15=0.98 55.20=1.02 55.25=0.96 55.30=1.02 55.40=0.99 55.45=0.99 55.50=0.98 55.55=1.08 55.65=0.92 55.70=1.04
55.75=1.10 55.80=1.00 55.85=1.07 55.90=1.13 55.95=1.16 60.100=1.26 60.30=0.99 60.35=1.04 60.40=0.91 60.45=0.97
60.50=1.04 60.55=1.01 60.60=1.01 60.65=1.05 60.70=0.97 60.75=0.92 60.80=1.05 60.85=0.95 60.90=1.14 60.95=1.28
simple=0.99
die für jede aufgetretene Bewölkung und Sonnenstand einen Korrekturfaktor in Abhängigkeit der Häufigkeit der aufgetrenenen Situation ermittelt und anwendet.
Hi,
ich musste mein fhem aus dem Backup wiederherstellen. Ich bin der Meinung, das alle Daten, die nötig sein sollten, auch wieder am richtigen Ort liegen:
pi@fhem-pi3:/opt/fhem/FHEM/FhemUtils $ ls -lla
insgesamt 2432
drwxr-xr-x 2 fhem dialout 4096 25. Jul 00:10 .
drwxr-xr-x 6 fhem dialout 36864 4. Jul 21:07 ..
-rw-r--r-- 1 fhem dialout 189875 13. Aug 23:35 AIraw_SolarForecast_Forecast
-rw-r--r-- 1 fhem dialout 200323 25. Jul 02:16 AItra_SolarForecast_Forecast
-rw-r--r-- 1 fhem dialout 46 14. Aug 19:11 cacheDbRep
-rw-r--r-- 1 fhem dialout 824530 10. Apr 22:58 DWDcat_SolarForecast
-rw-r--r-- 1 fhem dialout 856 13. Aug 23:35 PVCfg_SolarForecast_Forecast
-rw-r--r-- 1 fhem dialout 4624 14. Aug 19:11 PVCsm_SolarForecast_Forecast
-rw-r--r-- 1 fhem dialout 40381 14. Aug 19:11 PVC_SolarForecast_Forecast
-rw-r--r-- 1 fhem dialout 39986 23. Jul 00:09 PVC_SolarForecast_Forecast_2024_07_23_00_09_25
-rw-r--r-- 1 fhem dialout 40044 24. Jul 00:09 PVC_SolarForecast_Forecast_2024_07_24_00_09_07
-rw-r--r-- 1 fhem dialout 40165 25. Jul 00:10 PVC_SolarForecast_Forecast_2024_07_25_00_10_03
-rw-r--r-- 1 fhem dialout 253974 14. Aug 19:11 PVH_SolarForecast_Forecast
-rw-r--r-- 1 fhem dialout 250799 23. Jul 00:09 PVH_SolarForecast_Forecast_2024_07_23_00_09_25
-rw-r--r-- 1 fhem dialout 250745 24. Jul 00:09 PVH_SolarForecast_Forecast_2024_07_24_00_09_07
-rw-r--r-- 1 fhem dialout 250548 25. Jul 00:10 PVH_SolarForecast_Forecast_2024_07_25_00_10_03
-rw-r--r-- 1 fhem dialout 562 19. Feb 2017 release.pm
-rw-r--r-- 1 fhem dialout 12164 14. Aug 19:11 ScApi_SolarForecast_Forecast
-rw-r--r-- 1 fhem dialout 1056 14. Aug 18:35 uniqueID
-rw-r--r-- 1 fhem dialout 5739 19. Feb 2017 update-20130127-001
Im logfile sieht es auch nicht nach Fehlern aus:
2024.08.14 19:11:57.922 3: Forecast - cached data "pvHistory" restored
2024.08.14 19:11:57.933 3: Forecast - cached data "pvCircular" restored
2024.08.14 19:11:57.936 3: Forecast - cached data "consumerMaster" restored
2024.08.14 19:11:57.939 3: Forecast - cached data "solApiData" restored
2024.08.14 19:11:57.987 3: Forecast - cached data "aiTrainedData" restored
2024.08.14 19:11:58.021 3: Forecast - cached data "aiRawData" restored
Aber ich bekomme nur dieses Bild im Modul angezeigt (Siehe Anhang).
Was fehlt denn noch?
Liebe Grüße
Holger
Ich habe gerade den forecast plant configuration check ausgeführt und gesehen, dass da Fehler in den DWD Modulen auftreten. Vielleicht liegt es ja daran.
Wenn nicht, melde ich mich nochmal.
Liebe Grüße
Holger
Bei mir lag es im Mai/Juni einmal am fehlenden optionalen Eintrag (im Backup) beim Inverter (capacity=9500) den ich bis dahin nicht gesetzt hatte - weil ja optional 😮
Dadurch wurden die Daten nicht komplett wieder eingelesen und es gab das gleiche Bild.
Ob dies bei dir dann die Lösung ist ?? 🤔
Zur aller letzten Not den Wizzard nochmal durchlaufen mit Daten aus einem Backup mit dem fhem.cfg oder fhem.save files.
Is ja auch schnell gemacht.
Mööööp!
Sommerloch?
Modul so gut ausgearbeitet das keine Fragen offen bleiben?
Sollte es neuerdings Leute geben die echt 57 Seiten oder gar 243 zusäzliche Seiten aus dem alten Thread lesen? Und dadurch keine Fragen haben!?
Keiner Wünsche?
Gibt es ein solch gutes Modul mitlerweile bei den Mitstreiten? HA, Nodered, OpenHAB, IoBroker etc.? Hat da einer info's bzw. was mitbekommen.
Was ist hier los?
Sommerloch :)
Ich habe noch ein paar Sachen. Hatte ich weiter vorn schonmal geschrieben glaube ich. Inselanlage integrieren war eines, mit deinem Vorschlag.
Habe die letzten Wochen meine IT umgebaut, Proxmox läuft jetzt im 3-Node Cluster mit FHEM-Instanzen, aber auch anderen Anwendungen wie Wiki, Pi-Hole, Paperless-ngx, DNS-Server, Wiki, Phoscon, UniFi-Controller und mehr Sachen. Da war FHEM erstmal auf Hold gesetzt.
Aber kommt wieder. ;)
...oder einfach:
Das Modul erfordert tiefe Kenntnisse über seine eigene Solaranlage die (leider) meist weit über das Interesse des normalen Anwender hinaus geht, der einfach nur ,,Strom ernten" will...🤔
Die wenigsten PV-Anlagenbesitzer trauen sich leider an das Energiemanagement inkl. Eingriff und Steuerung von Batterien und deren ,,Ladezeiten" oder Verbrauchern und deren Leistungabnahmemanagement.🧠
Hallo kask,
ZitatModul so gut ausgearbeitet das keine Fragen offen bleiben?
Ich hatte einen vermutlich einfachen Wunsch bereits geäußert: Wie kann ich die flow-Grafik linksbündig darstellen statt zentriert?
Viele Grüße Gisbert
Also laut FHEM Statistik (https://fhem.de/stats/statistics.html) gibt es von dem Modul
177 Installationen mit
219 Instanzen
Davon werden folgende API's verwendet:
Installationen Definitionen
DWD 96 104
ForecastSolarAPI 7 7
OpenMeteoDWDAPI 43 45
OpenMeteoDWDEnsembleAPI 16 16
OpenMeteoWorldAPI 10 11
SolCastAPI 20 22
VictronKiAPI 4 4
Die Dunkelziffer dürfte höher sein weil nicht jeder die Infos beim Update übermittelt. ;)
Hallo Gisbert,
ich hatte schon ein paar Versuche gemacht, aber noch kein Ergebnis erzielt.
Vllt. hat kask eine zündende Idee.
In der Tat hatte ich mir das mal angeguckt was da so für Optionen sind.
Eigentlich müsstest man doch einfach nur die SVG-Plot ausgabe manipulieren. Also dein Modul um die Zeile 13667->13677 rum.
Konnte man ja ein attr setzen mit einem flow offset. Dann könnte man das auch nach rechts schieben. oder prozentual von breite 50% mitte,0% links, 100% rechts.
Dann würde es so aussehen.
Original:
<svg xmlns="http://www.w3.org/2000/svg" style="width:98%; height:300px;" id="SVGPLOT" viewBox="5 -25 800 480">
Manipuliert:
<svg xmlns="http://www.w3.org/2000/svg" style="width:98%; height:300px;" id="SVGPLOT" viewBox="800 -25 800 480">
An der Stelle hatte ich auch schon experimentiert, war aber offensichtlich zu zaghaft unterwegs.
Ich schau mal wie ich es praktisch implementiere.
Hallo kask,
Hallo DS_Starter,
vielen Dank euch beiden. Ich warte dann ab, bis es ein neues Attribut fürs Verschieben der Flow-Grafik gibt.
Viele Grüße Gisbert
Ich habe die neue Version 1.30.0 eingecheckt.
Es gibt nun das Attribut flowGraphicShift um die Flußgrafik horizontal verschieben zu können.
LG
Hallo DS_Starter,
vielen Dank für dieses Attribut - ich hab's umgesetzt und es funktioniert wie geplant.
Man muss ein bißchen probieren, wie es einem gefällt und wie es passt. Der Wert des Attributs hängt auch davon ab, wieviele Stunden man in der Balkengrafik anzeigt.
Viele Grüße Gisbert
Zitat von: DS_Starter am 17 August 2024, 22:01:07Davon werden folgende API's verwendet:
Installationen Definitionen
DWD 96 104
ForecastSolarAPI 7 7
OpenMeteoDWDAPI 43 45
OpenMeteoDWDEnsembleAPI 16 16
OpenMeteoWorldAPI 10 11
SolCastAPI 20 22
VictronKiAPI 4 4
Interessant, OpenMeteoDWDAPI wird im Vergleich zu OpenMeteoDWDEnsembleAPI mehr genutzt. Zufällig oder weil die Ergebnisse besser sind? Genau das ist nämlich mein Problem (generell, nicht in Bezug auf eine der APIs).
Zitat von: kask am 17 August 2024, 21:22:16Sommerloch?
Daher mache ich mit dem Modul noch nicht viel mehr als beobachten (und habe gerade keine Fragen mehr). Aber was soll ich sagen, wenn man sich nicht mal mehr auf das Regenradar für die nächste halbe Stunde verlassen kann? Oder vor einigen Tagen hatte ich mal den Fall, dass OpenMeteoDWDAPI um 9:30 für die Stunde ab 10:00 100% Bewölkung vorhergesagt hat, OpenMeteoDWDEnsembleAPI 0%. Da kann man korrigieren wie man will ;-) Wobei ich mich dann noch gefragt hatte, ob sich das dann nicht sogar negativ auf die Berechnung der Korrekturfaktoren auswirkt.
Viele Grüße
Thomas
ZitatInteressant, OpenMeteoDWDAPI wird im Vergleich zu OpenMeteoDWDEnsembleAPI mehr genutzt. Zufällig oder weil die Ergebnisse besser sind?
Kann man nicht beantworten, nehme aber an dass es Zufall ist weil ich die OpenMeteoDWDAPI zeitlich vor der OpenMeteoDWDEnsembleAPI implementiert hatte.
ZitatWobei ich mich dann noch gefragt hatte, ob sich das dann nicht sogar negativ auf die Berechnung der Korrekturfaktoren auswirkt.
Eher nicht bzw. nur am Beginn des Modullebens wenn es erst sehr wenige gespeicherte Werte gibt. Je mehr Daten aufgesammelt werden, desto mehr glätten sich die Werte durch eine Durchschnittsbetrachtung.
Es ist im Allgemeinen nicht so tragisch, wenn Prognose/Ist mal für eine Stunde auseinanderlaufen denn das Modul betrachtet z.B. für geplante Schaltvorgänge auch den aktuellen Wetterzustand zur Schaltzeit und plant ggf. die Schaltung neu wenn die Bedingungen nicht so zutreffen wie ursprünglich erwartet.
Für eine Batterie Ladungssteuerung z.B. sind dann wiederum die erwarteten Tageswerte eher von Bedeutung als ein einzelner Stundenwert.
Die Relevanz einer Stundenabweichung ist vom Verwendungzweck der Prognose abhängig. Natürlich wäre eine Abweichung von "0" ein Traum, wird aber in der Realität sehr selten auftreten.
ZitatZitat
Interessant, OpenMeteoDWDAPI wird im Vergleich zu OpenMeteoDWDEnsembleAPI mehr genutzt. Zufällig oder weil die Ergebnisse besser sind?
Kann man nicht beantworten, nehme aber an dass es Zufall ist weil ich die OpenMeteoDWDAPI zeitlich vor der OpenMeteoDWDEnsembleAPI implementiert hatte.
Das würde auch erklären warum 20 Instanzen der SolCastAPI aktiv sind. Bzw. wunderte mich das da bei mir die SolCastAPI mehr schlecht als recht prognostiziert.
Vieleicht outet sich ja mal einen als SolCastAPI-User.
Ok, ich habe jeweils eine Instanz von allem aktiv am rennen. Vieleicht haben das die anderen ja auch. War ja die 3te inegrierte API wenn ich mich recht erinnere.
Die SolCastAPI macht bei mir eigentlich einen guten Job. Gestern und heute war es nicht so prall, kann mich aber sonst nicht bekagen.
(Zwei weitere zum Vergleich noch dazu gehängt)
ZitatHallo Joachim,
nach ein paar Startschwierigkeiten hat es dann doch hiermit funktioniert:
https://github.com/tomquist/solix2mqtt
Ich versuche meine Solix2 in FHEM zu integrieren. Ich verstehe den ganzen Wald mit Bäumen nicht. Ein paar angelernte Grundkenntnisse durch FHEM habe ich. Doch mit node.js, npm, komme ich nicht weiter.
Gibt es vielleicht eine Schritt für Schritt Anleitung die Solix2 Daten zu integrieren? Könntet Ihr das bereitstellen?
Vielen Dank
Hoffi
Meine SolCastAPI, bei mir ist das teilweise voll daneben. Ich guck mir das nochmal an, eventuell sitzt das Problem ja auch vor meinem Monitor.
MariaDB [fhem]> select * from history where device = "ForecastSolarAPI" and reading = "Today_PVdeviation" order by timestamp desc limit 31;
+---------------------+------------------+---------------+-------+-------------------+--------+------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
+---------------------+------------------+---------------+-------+-------------------+--------+------+
| 2024-08-19 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -16.73 | % |
| 2024-08-18 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -35.83 | % |
| 2024-08-17 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -49.95 | % |
| 2024-08-16 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 13.07 | % |
| 2024-08-15 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -18.97 | % |
| 2024-08-14 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 12.44 | % |
| 2024-08-13 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -36.82 | % |
| 2024-08-12 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -34.83 | % |
| 2024-08-11 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 4.99 | % |
| 2024-08-10 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -15.45 | % |
| 2024-08-09 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -20.89 | % |
| 2024-08-08 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -30.54 | % |
| 2024-08-07 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 10.30 | % |
| 2024-08-06 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -39.04 | % |
| 2024-08-05 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -51.02 | % |
| 2024-08-04 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -56.50 | % |
| 2024-08-03 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -49.07 | % |
| 2024-08-02 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -22.95 | % |
| 2024-08-01 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 28.76 | % |
| 2024-07-31 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 5.58 | % |
| 2024-07-30 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -47.36 | % |
| 2024-07-29 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -55.90 | % |
| 2024-07-28 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -23.95 | % |
| 2024-07-27 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 41.00 | % |
| 2024-07-26 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -16.55 | % |
| 2024-07-25 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -26.42 | % |
| 2024-07-24 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -26.77 | % |
| 2024-07-23 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -24.32 | % |
| 2024-07-22 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -41.76 | % |
| 2024-07-21 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | 12.25 | % |
| 2024-07-20 23:55:00 | ForecastSolarAPI | SOLARFORECAST | | Today_PVdeviation | -36.14 | % |
+---------------------+------------------+---------------+-------+-------------------+--------+------+
Ach du meinst die ForecastSolarAPI, die ist bei mir auch Mist. Nein die SolCastAPI läuft bei mir sehr gut.
jo, da hab ich was vertauscht :o
@all, morgen früh ist eine neue Version im Update.
Es war noch eine Änderung in den Attributen offen, nämlich die Umsetzung von
- ctrlWeatherDevX zu setupWeatherDevX
Jetzt sind alle substanziellen Device-Einstellungen mit dem Präfix "setup" gekennzeichnet.
Mit dem notwendigen Restart wird die Änderung automatisch vorgenommen, ihr braucht nichts anpassen/ändern.
LG
@Thoffi1978
Hallo, da bist du hier erst einmal falsch.
Versuche es doch mal dort: https://forum.fhem.de/index.php?topic=138233.msg1315716#msg1315716
Hi,
da ihr euch über das Sommerloch beschwert habt hier auch eine Frage von mir.
Ich habe vor einiger Zeit als Heiko OpenMeteo eingebaut hat von 2 DWD Devices die beide ca 3 km entfernt sind und mit forecastResolution 1 und dem neusten Modul mit MOSMIX abgerufen wurden auf ctrlWeatherDev1 OpenMeteoDWD-API umgestellt.
Ich habe nicht wie viele von euch mehrer solarForecast Devices am laufen und so auch keinen wirklichen Vergleich.
Am Anfang dachte ich mir es liegt an der AI die noch lernen muss.
Nun läuft das aber gefühlt schon sehr lange mit OpenMeteoDWD-API und ich finde die Vorhersage ist schlechter als mit den DWD Devices.
Was meint ihr dazu?
Wie sind eure Erfahrungen und was würdet ihr mir raten?
Ich sträube mich etwas zurück zu wechseln weil OpenMeteo ja das neuere ist und ich so vom lesen das Gefühl hatte das viele zufrieden sind.
Auch habe ich Angst dass nach der Umstellung die AI nicht passt und erst wieder länger lernen muss.
Vielen Dank schonmal für eure Ratschläge,
Stefan
Hallo Stefan,
die OpenMeteoDWD-API läuft bei mir auch sehr gut. Das siehst du an den Grafiken (OpenMeteo DWD ICON) in #862.
An den allermeisten Tagen ist die Tagesabweichung < 10%.
Ich habe mal einen Trend gemacht aus den Abweichungen der letzten 14/30/60 Tage mit Progronse/Ertrag gesamt.
Da sticht der Eine oder Andere schon hervor.
Hallo kask,
sehr interessant deine Auftragung.
Ich hab leider noch nicht ganz verstanden, was auf der Ordinate aufgetragen ist. Sind es kWh (also ein Ertrag)? Dann verstehe ich ich aber die negativen Werte nicht.
Kannst du es vielleicht erklären? Wenn möglich auch mit einer Empfehlung, welche Datenquelle deiner Meinung nach die besten Vorhersagen liefert.
Viele Grüße Gisbert
Auf der Ordinate sind Abweichungen (Today_deviation) in % und die Prognose.- & Realwerte in kW des Tages im Durschnitt aller ausgenommen der ForecastSolarAPI.
Die Abzisse sollte ja klar sein bis auf der Dummy. Der besteht aus dem Mittelwert von allen Einzelabweichungen ausgenommen der ForecastSolarAPI.
Für mich ist ganz klar die SolcastAPI am besten. War sie aber bei mir schon immer.
Die VictronKiAPI ist auch nicht schlecht. Benötigt aber Victron Hardware. Die basiert meine ich auch auf den SolcastAPI-Daten.
Dann die DWD, OpenMeteoDWD.
Das ist auch sehr abhängig vom Bewölkungsgrad und Jahreszeit.
Bei schlechtem Wetter und vorallem im Winter finde ich die DWD besser. Im Sommer und bei gutem Wetter die SolcastAPI.
So ist es zumindest bei mir.
Im Durchschnitt am besten Fahre ich mit dem Dummy. Diesen benutze ich auch für Werte die ich so verwurste in meiner Automation.
Hallo kask,
wenn ich das richtig interpretiere, dann ist die Vorhersage mit DWD eigentlich am besten. Sieht du das auch so? Was ist deine Empfehlung?
Viele Grüße Gisbert
Ich habe die Daten gelogged um so einen Trend mal aufzustellen. Zur Analyse.
Bis jetzt hatte ich das so eigentlich nur subjektive an den Werten und meinem Empfinden ausgemacht.
Heute habe ich mein Vorhaben dann einmal vollzogen.
Jetzt wo ich mir die Trends so angeschaut habe und analysiere, tendiere ich momentan dahin den Dummywert nur aus dem SolcastAPI.- und DWD-Wert zu erzeugen.
Ich werde mal einen Dummy nur mit diesen Werten erzeugen und auch loggen. Dann schaue ich mir das noch einmal an.
Der SolcastAPI-interval ist auf 10 Abfragen/Tag/String eingestellt. Also nix hochauflösendes wie es auch teilweise möglich ist mit 50 Anfragen/Tag.
Hi Kask,
klasse!
Da hat mich meine Beobachtung ja nicht getäuscht mit 2 DWD Stationen war es besser als mit dem OpenMeteoDWD. Und ich habe das Gefühl um einiges.
Das belegt ja auch deine Grafik.
Ich denke dann gehe ich wieder auf die DWD Stationen.
Dann kann die KI sich bis zum Winter wieder einschwingen.
Vielen Dank,
Stefan
Hallo Stefan,
ich versuche DWD-Stationen mit dem Reading Rad1h in meiner Nähe zu finden, jedoch hab ich das nicht geschafft. Wie kann ich diese Stationen finden?
Viele Grüße Gisbert
Wie unterschiedlich die Beobachtungen sein können ...
mein OpenMeteoDWDAPI ging heute mit 0,8! % Abweichung aus dem Tag, OpenMeteoDWDEnsembleAPI mit -1,4 % und DWD mit -16,6 %.
Heute war die OpenMeteoAPI auch ganz gut mit -3,4, oft aber wesentlich schlechter.
Die Überlegenheit von DWD bei mir liegt vielleicht auch daran, dass ich wirklich in unmittelbarer nähe 2 DWD Station mit RAD readings habe.
@Gisbert:
Es gibt eine Liste mit allen Stationen, an den Kennzeichen kann man erkennen ob sie RAD readings anbieten.
Irgendwo hier im Thread hatten wir das mal, mit einfacher Google suche finde ich auch immer nur gekürzte Listen.
Ich schaue mal ob ich herausfinde woher die Liste war auf der alle Stationen mit Kennzeichnung waren.
Gruß,
Stefan
Moin,
ZitatEs gibt eine Liste mit allen Stationen, an den Kennzeichen kann man erkennen ob sie RAD readings anbieten.
Irgendwo hier im Thread hatten wir das mal, mit einfacher Google suche finde ich auch immer nur gekürzte Listen.
Da muss man nicht viel suchen. Mit dem Befehl "get ... dwdCatalog" kann man sich alle Stationen auflisten, sortieren und auch filtern, z.B. Longitude und Latitude via Regex und so eingrenzen.
Die Ausgabe kann man sich auch exportieren und in einem Viewer visualisieren. Dann hat man auch eine entsprechende Karte.
Ach ja,
das hattest du eingebaut ;-)
Manchmal sieht man den Wald vor lauter Bäumen nicht und das Modul kann schon alles.
Danke,
Stefan
Hallo DS_Starter,
In meinem ConsumptionForecast tauchen immer wieder negative Werte auf. Weiß Du, woran das liegen könnte?
Evtl. am Abzug des Wallboxverbrauches?
attr SolarVorhersage consumer01 WebastoNext type=charger power=0 pcurr=Charge_Active_Power:W etotal=Energy_Meter:kWh icon=wallbox exconfc=1Gruß
tupol
| statistic_todayConsumptionForecast_01 | 416 Wh | 2024-08-25 00:59:49 |
| statistic_todayConsumptionForecast_02 | 323 Wh | 2024-08-25 01:59:49 |
| statistic_todayConsumptionForecast_03 | 392 Wh | 2024-08-25 02:59:49 |
| statistic_todayConsumptionForecast_04 | 389 Wh | 2024-08-25 03:59:49 |
| statistic_todayConsumptionForecast_05 | 372 Wh | 2024-08-25 04:59:49 |
| statistic_todayConsumptionForecast_06 | 362 Wh | 2024-08-25 05:59:49 |
| statistic_todayConsumptionForecast_07 | 316 Wh | 2024-08-25 06:59:57 |
| statistic_todayConsumptionForecast_08 | -2100 Wh | 2024-08-25 07:59:49 |
| statistic_todayConsumptionForecast_09 | 486 Wh | 2024-08-25 08:59:49 |
| statistic_todayConsumptionForecast_10 | 621 Wh | 2024-08-25 09:59:49 |
| statistic_todayConsumptionForecast_11 | 599 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_12 | 502 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_13 | 573 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_14 | 636 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_15 | 563 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_16 | 641 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_17 | 618 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_18 | 577 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_19 | 503 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_20 | 538 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_21 | -1232 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_22 | -2035 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_23 | 625 Wh | 2024-08-25 10:41:37 |
| statistic_todayConsumptionForecast_24 | 512 Wh | 2024-08-25 10:41:37 |
ZitatIn meinem ConsumptionForecast tauchen immer wieder negative Werte auf. Weiß Du, woran das liegen könnte?
Das kann verschiedene Ursachen haben.
Eine könnte sein, dass ein Verbraucher über seinen Schlüssel exconfc von der Verbrauchsprognose ausgeschlossen werden soll. Wenn der historische Verbrauch dieses Consumers recht hoch ist, kann es beim Excludieren, d.h. beim Subtrahieren seines Leistungsanteils von der Gesamtprognose das Ergebnis negativ wird.
Wenn du "get ... nextHours" aufrufst, findest du zu jeder Stunde ein Schlüssel confc und confcEx. Im Normalfall sollte confc immer größer confcEx und beide positiv sein. Schau mal ob bei den relevanten Stunden das Schema gebrochen wird. Und schaue auch ob es Verbraucher gibt, bei denen der Key exconfc gesetzt ist und ob diese Consumer hohe Energie verbrauchen. Dann kann man in der History (get ... pvHistory) danach forschen welche Anteile der Consumer in der jeweiligen Stunde hatte (Key csmeXX).
Im Prinzip löst sich die Problematik von selbst, wenn die betroffenenen Datensätze aus der History "herausaltern". Möglicherweise macht es Sinn solche Statistikdatensätze als "nicht berechenbar" o.ä. auszuweisen.
Grüße,
Heiko
Hallo Heiko,
hier der Auszug der betreffenden Stunde.
NextHour07 => starttime: 2024-08-25 21:00:00, hourofday: 22, today: 1
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, confc: -2035
confcEx: 616, DoN: 0, wid: 101, wcc: 45, rr1c: 0.00, temp=16.50
rad1h: 0, sunaz: 303, sunalt: -12
confc ist negativ. Wie ermittelst Du diesen Wert? Ich möchte nur den Verbrauch meiner Wallbox rausrechnen, da ich diese ja abhängig vom normalen Haus-Verbrauch steuern will. Deshalb hab ich auch nur die Wallbox als Consumer angegeben.
Hier die entsprechenden Attribute:
setupMeterDev SMR_WP gcon=Power:W contotal=Import_Total:kWh gfeedin=-gcon feedtotal=Export:kWh conprice=0.3099:€ feedprice=0.077:€
setupInverterDev SH10rt_Master pv=Complete_DC_Power:W etotal=Complete_PV_Generation:kWh
consumer01 WebastoNext type=charger power=0 pcurr=Charge_Active_Power:W etotal=Energy_Meter:kWh icon=wallbox exconfc=1
Gruß
Torsten
ZitatWie ermittelst Du diesen Wert?
Es folgt aus den Aufzeichnungen in der pvHistory für die Consumption und dem Consumer (hier csme01).
Beachte auch das Attr affectConsForecastIdentWeekdays. Man kann beeinflussen dass nur gleiche Wochentage in die Consumption-Vorhersage eingehen weil man z.B. immer Di irgendetwas tut.
Man kann mit ctrlDebug=consumption weitere Informationen zur Berechnung erhalten.
Hallo Heiko,
Danke für Deine Hilfe.
Ich habe mir die Sachen angeschaut, werde aber nicht schlau draus. Das Log-File wird bei ctrlDebug=consumption sehr schnell zu voll, deshalb habe ich es wieder abgeschaltet.
Bei mir ist der Verbrauch zu Zeit ziemlich stabil. Es gibt nur Spitzen wenn die Wärmepumpe anspringt und wenn die Wallbox lädt.
Kann ich die gesamte Verbrauchsaufzeichung zurücksetzen?
Ich verstehe nicht so richtig, warum es überhaupt zu negativen Werten kommt. Mögliche Ursache könnte der Lesekopf meines Smartreaders. Der hat ab und zu extreme Ausreißer (Lesefehler) und da könnte es zu Rechenungenauigkeiten bei der Differenzbildung kommen.
Wenn negative Werte prinzipiell unplausibel sind, könnt man diese nicht auch über das Modul abfangen?
Gruß
Tupol
Hallo Tosten,
ja, du kannst mit
set ... reset consumption
und
set ... reset consumerMaster
die gesammelten Werte zu den Consumern und dem Hausverbrauch löschen.
ZitatWenn negative Werte prinzipiell unplausibel sind, könnt man diese nicht auch über das Modul abfangen?
Ja, das könnte ich und mache es auch schon an verschiedenen Stellen.
Die Frage ist immer ob es zielführend ist einen evtl. Fehler der Quelle zu unterdrücken oder zuzulassen damit man als User überhaupt darauf aufmerksam wird und ggf. den Fehler an der Quelle beseitigt was natürlich der bessere Weg ist. Sonst denkt man alles ist gut, dabei sind die Probleme nur weggedrückt.
In deinem Fall würde ich einen negativen Wert auf 0 setzen. Sehr hilfreich ist das eigentlich auch nicht, dann wäre die Verbrauchsprognose der Stunde auch bestenfalls 0.
Da würde man sich berechtigterweise fragen wieso ein Verbrauch des Hauses von 0 erwartet wird. ;)
Dann würde ich eher dazu tendieren dies Daten als "nicht berechenbar" oder "fehlerhafte Inputdaten" kennzeichnen.
Alles hat so seine Vor- und Nachteile.
LG,
Heiko
Hallo Heiko,
das mit dem auf 0 setzen wäre super, da ich ja die Output-Daten schon benutze. Wenn dann nur ein Input falsch ist, könnte ich dort weiter forschen aber so wie es jetzt ist, bekomme ich einen komplett falschen Output und breche den Ladevorgang nicht rechtzeitig ab.
Gruß
tupol
Ich baue da mal etwas ein.
Grundsätzlich wird der gespeicherte Wert des Hausverbrauches auch durch die Meßstellen PVreal, GridFeedIn, GridConsumption, BatIn und BatOut, vertreten durch die entsprechenden Readings pro Stunde, beeinflusst.
Sollte es an diesen Stellen sporadische Messfehler geben, können sie sich entsprechend negativ auswirken.
@tupol,
ich habe im Modul ein paar Maßnahmen zur Vermeidung von negativen Verbrauchswerten des Hauses oder eines Verbrauchers vorgenommen.
Wenn korrigierend eingegriffen werden muß , gibt es Logeinträge mit verbose 3.
Ich möchte es erstmal ein wenig testen (lassen) und habe die V.1.32.0 zunächst in mein contrib geladen.
Restart nach Download nicht vergessen. Bei mir habe ich die Version auch im Einsatz und beobachte sie bis zum WE.
Wieso kann ein Haus nicht negativ sein? Wenn ich ein BKW da reinhänge bekomme ich das doch negativ ohne groß Stress. Was ja auch richtrig wäre wenn es nicht bekannt ist.
Ich finde das nicht so toll und nötig das zu unterbinden.
Wenn das BKW Strom in dein Hausnetz einspeist, wird ein Teil vom Haus verbraucht und ein Teil vermutlich ins öffentliche Netz eingespeist, richtig?
Das Haus verbraucht aber immer einen positiven Betrag X, bestenfalls 0, richtig? Sonst müsste ja "das Haus" Energie erzeugen.
Oder wo habe ich einen Denkfehler?
Vermutlich wäre es ein sauberer Weg, wenn es noch die Möglichkeit gäbe "sonstige Erzeuger" angeben zu können, deren Energielieferung in die Berechnung der Consumption einfließen würde (BKW, Notstromaggregat, Windanlage,....). Eine Batterie wird ja bereits als Erzeuger und Verbraucher gleichermassen berücksichtigt.
Ja das Haus müsste Energie erzeugen! Da ist ein BKW was dem Modul nicht bekannt ist.
Ist banane, wäre aber so korrekt. Ich halte nichts von überkompensationen wegen Bedienfehlern bzw. scheinbar-nicht-in-den-griff-kriegender-externer-geräte (Ist nicht böse gemeint).
Wenn ein Gerät spinnt dann muß man das optimieren oder austauschen und nicht an einer anderen Stelle kompensieren.
Man könnte so ein spinnen auch selber im Userreading oder sonstwie wegkompensieren.
ZitatIch halte nichts von überkompensationen wegen Bedienfehlern bzw. scheinbar-nicht-in-den-griff-kriegender-externer-geräte
Grundsätzlich stimme ich dir zu. Probleme sollten immer an der Quelle beseitigt werden. Auch das userReading ist ein Argument.
Allerdings sehe ich auch ein, dass wir nicht immer auf ein ideales Umfeld bauen können und der User auf ein Problem hingewiesen werden sollte damit er reagieren/gegensteuern kann.
Deswegen schlage ich folgende Teilmaßnahmen vor:
1. Im Log wird das Problem des negativen Hausverbrauches signalisiert und an welcher Stelle in der pvHistory es auftritt, wird aber nicht automatisch korrigiert.
2. Dem Log kann man den Befehl zum Löschen des fehlerhaften Wertes entnehmen.
3. Ich füge 1-3 Attribute "setupOtherProducersXX" ein, damit man solche non-Solar Erzeuger integrieren kann und deren Werte in die Consumption Berechnung des Hauses eingehen. Somit wird im Normalfall keine Verfälschung hervorrufen.
Na, dann sollten wir uns doch mal auf eine Vorzeichenregelung einigen. Vorschlag:
1. Energieverbrauch hat immer ein positives Vorzeichen. Und zwar auch dann, wenn ein Speicher geladen wird.
2. Energie, die aus einer PV-Anlage, einem BHKW oder einem Speicher ins Hausnetz oder ins öffentliche Netz (aka Grid) fließt, hat immer ein negatives Vorzeichen.
3. Diese Vorzeichen gelten sowohl für die Energie, als auch für den Energiefluss (also die Leistung).
Hieße also z.B.: Meine PV-Anlage produziert derzeit -3.00 kW. Davon gehen 0.84 kW in den Speicher, sowie 2.10 kW ins Haus. Eingespeist oder bezogen wird derzeit nichts.
LG
pah
Macht durchaus Sinn das zu klären.
Aber andersrum wäre auch ok. Verbrauch ist negativ. Ist ja schließlich verbrauchte Energie.
Hieße also z.B.: Meine PV-Anlage produziert derzeit 3.00 kW. Davon gehen -0.84 kW in den Speicher, sowie -2.10 kW ins Haus. Eingespeist oder bezogen wird derzeit nichts.
Kann man halten wie ein Dachdecker, ist eine Ansichtssache von der Betrachtungsweise aus.
Moin,
ich bastele gerade an einem FUIP-Popup, welches mir die Forcast aus einem fhem-Weblink darstellen soll. Ich weiß, die Lösung meines Darstellungsproblemes wurde schon früher mal gepostet, aber leider finde ich sie nicht wieder: Die Forcast-Grafik wird deutlich zu groß dargestellt für einen Tablet-Bildschirm.
Weiß noch jemand auf die Schnelle, wie ich dieses Problem lösen kann?
Danke. Gruß
Christoph
Zitat von: kask am 30 August 2024, 20:55:27Aber andersrum wäre auch ok. Verbrauch ist negativ. Ist ja schließlich verbrauchte Energie.
Kann ich nicht nachvollziehen. Denn der Ankerpunkt meines Vorschlags ist der Bezug aus dem Netz, der positiv zu sein hat. So steht es auf Deiner Stromrechnung.
LG
pah
P.S.: Lass Dir erklären: Energie wird nicht verbraucht ;D
Ja, wenn ich es aber von dem Punkt betrachte hinter dem Zähler und hinter meiner PV dann könnte es anders sein.
Nur weil ein Anderer seine Denkweise hat muss man das ja nicht adaptieren.
Ist auch klar das der Stromlieferant das so sieht. Dein Zähler(Du) verbraucht(st) ist also +..Der Betreiber gibt aber. Also für Ihn Minus.
Der Zähler ist aber deiner also + wären es alle seine dann -.
Beim Tanken ist es ja auch +. Für die Tankstelle ist es Minus.
Aber man muß sich da halt einigen. Und da ist es leichter die Einheiten bzw. Vorzeichen zu nehmen die jeder so hat ohne groß die Sichtweise zu erklären.
Auch wenn der ein oder andere das Anders sieht.
P.S. Dann benutze die Energie doch einfach noch einmal ;D bzw. sag mir mal wie das geht.
Du willst sicher auf den Energieerhaltungssatz hinaus. Ist mir bekannt.
Zitat von: caldir65 am 01 September 2024, 20:01:27Moin,
ich bastele gerade an einem FUIP-Popup, welches mir die Forcast aus einem fhem-Weblink darstellen soll. Ich weiß, die Lösung meines Darstellungsproblemes wurde schon früher mal gepostet, aber leider finde ich sie nicht wieder: Die Forcast-Grafik wird deutlich zu groß dargestellt für einen Tablet-Bildschirm.
Weiß noch jemand auf die Schnelle, wie ich dieses Problem lösen kann?
Danke. Gruß
Christoph
attr flowGraphicSize ist dein Freund.
Zitat von: kask am 02 September 2024, 18:26:14Du willst sicher auf den Energieerhaltungssatz hinaus. Ist mir bekannt.
Nene, in den Feldgleichungen der Allgemeinen Relativitätstheorie ist das nicht mehr so einfach - so richtig verstanden hat das in der Physik niemand.
Zitat von: kask am 02 September 2024, 18:26:14Und da ist es leichter die Einheiten bzw. Vorzeichen zu nehmen die jeder so hat ohne groß die Sichtweise zu erklären.
Da scheint mir aber ein großes Durcheinander zu herrschen, das man sinnvollerweise behebt. Wichtig sind die relativen Vorzeichen in der Installation - dann kann es nämlich nur noch um ein globales Vorzeichen gehen, dass Du gerne so wählen kannst, wie Dein Netzbetreiber...
LG
pah
@all,
die Implementierung im Modul orientiert sich an der Gestaltung der OBIS-Kennzahlen und Medien der Bundesnetzagentur (https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.bundesnetzagentur.de/DE/Beschlusskammern/BK06/BK6_83_Zug_Mess/835_mitteilungen_datenformate/Mitteilung_33/Anlagen/Codeliste-OBIS-Kennzahlen_Medien_2_5_20230331.pdf%3F__blob%3DpublicationFile%26v%3D1&ved=2ahUKEwiemsqfnaKIAxUu8LsIHdf1FRoQFnoECB0QAQ&usg=AOvVaw2WEOCd1ZYMHWJC3GxD42WQ).
Seite 7 Zitat:
ZitatDie Richtungsangaben + / - bei der Messgröße geben die Energieflussrichtung an und bedeuten:
+ Bezug des Kunden aus dem Netz (z. B. 1-b:1.x.y)
- (Rück-) Lieferung des Kunden an das Netz (z. B. 1-b:2.x.y)
Die Energieflussrichtung wird mittels der OBIS-Kennzahl definiert. Mit Ausnahme der Übermitt-
lung von Korrekturenergie-mengen (hier können die Werte auch negativ sein), sind die Mengen-
angaben nur mit positiven Werten oder 0 anzugeben.
Da die Menge aller erzeugter und verbrauchter Energie in Summe "0" ergeben muß, gestalten sich die Anteile wie folgt:
PV_Erzeugung + Sonstige_Erzeugung - Hausverbrauch - Netzeinspeisung + Netzbezug - BatterieIn + BatterieOut = 0Der Nutzer gibt nur positive Größen an (von Ausnahmen abgesehen). Alles andere wird im Modul umgesetzt.
Sollten negative Mengen eingegeben werden können, habe ich es in der Commandref vermerkt. Falls es irgendwo unklar sein sollte, kann ich die Comref gerne ergänzen.
LG,
Heiko
Das ist ja alles schön und gut. Wenn allerdings z.B. in einer Grafik für den Speicher angezeigt werden soll
A: - gegenwärtige Leistung
muss entweder mit einem Text dazu gesagt werden, ob diese Leistung gerade in den Speicher oder aus dem Speicher läuft. Oder man macht es sich einfach und unterscheidet das durch das Vorzeichen.
B: - bisher eingespeiste Energie
- bisher bezogene Energie
muss auch entweder ein Text unterscheiden, um was es sich handelt - oder das Vorzeichen dient zur Unterscheidung.
Es geht also in dieser Diskussion nicht um die Konformität mit OBIS (die lasse ich ja gerne für den Netzbezug gelten). Sondern auch um die Usability und nutzerzentrierte Darstellung. Und da sind die vorzeichenbehafteten Größen klar im Vorteil.
LG
pah
ZitatA: - gegenwärtige Leistung
muss entweder mit einem Text dazu gesagt werden, ob diese Leistung gerade in den Speicher oder aus dem Speicher läuft. Oder man macht es sich einfach und unterscheidet das durch das Vorzeichen.
Ich war bis jetzt der Ansicht, dass man in der Grafik (Anhang) eindeutig sieht ob Energie in den Speicher hinein oder, wie in der aktuellen Sicht, hinaus in das Hausnetz fließt. Zumal die Laufketten auch nochmal die Richtung verdeutlichen.
ZitatB: - bisher eingespeiste Energie
- bisher bezogene Energie
muss auch entweder ein Text unterscheiden, um was es sich handelt - oder das Vorzeichen dient zur Unterscheidung.
Wo ist diese Stelle? Vllt. ein Screeshot? Ich kann das gerade nicht einordnen.
ZitatWo ist diese Stelle? Vllt. ein Screeshot? Ich kann das gerade nicht einordnen.
Entschuldigung, Missverständnis. Ich beziehe mich dabei nicht auf Deine Grafik, sondern auf meine, siehe Anhang.
Da sieht man unten in der Mitte, was ich meine: Bezug heute 1,59 kWh, Einspeisung 4,07 kWh (weil die Kiste nicht angeschlossen war, wir waren auf dem Golfplatz). Und bei der Einspeisung steht ein Minuszeichen.
Übrigens sieht man auch, dass der Pfeil hier gar nichts nutzt, wenn der Bezug/die Einspeisung derzeit Null ist. Bei den Wechselrichtern habe ich allerdings die Minuszeichen weggelassen, die kommen (OBIS-konform) erst bei den Zählern hinzu.
LG
pah
P.S.: Was bei Dir "Laufketten" sind, ist bei mir auch animiertes SVG. Es ändert sich die Laufrichtung ebenso wie die Farbe, rot= Netzbezug, grün=PV, schwarz=neutral, kein Lauf. Außerdem füllt dieses Muster den gesamten Pfeil aus. Ebenso ändert sich natürlich die Pfeilrichtung je nach Flussrichtung.
Zitat von: 300P am 14 August 2024, 19:49:31Bei mir lag es im Mai/Juni einmal am fehlenden optionalen Eintrag (im Backup) beim Inverter (capacity=9500) den ich bis dahin nicht gesetzt hatte - weil ja optional 😮
Dadurch wurden die Daten nicht komplett wieder eingelesen und es gab das gleiche Bild.
Ob dies bei dir dann die Lösung ist ?? 🤔
Und was hast Du dann gemacht?
Gib doch das Attr setupInverterStrings einfach nochmal ein.
Vermutlich ist das Backup von einer äletren Version des Moduls.
Zitat von: kask am 22 August 2024, 17:36:21Ich habe mal einen Trend gemacht aus den Abweichungen der letzten 14/30/60 Tage mit Progronse/Ertrag gesamt.
Da sticht der Eine oder Andere schon hervor.
Hallo kask,
ich hab jetzt 13 Tage einen Vergleich zwischen den Daten von OpenMeteoDWDEnsemble und DWD gemacht. Die letztere DWD-Station liegt 20 km Luftlinie von mir entfernt. In 9 Fällen liefert auf den Tag bezogen OpenMeteoDWDEnsemble die bessere Vorhersage, bei DWD sind es 3 Tage und an einem Tag sind die Vorhersagen bei beiden Modellen gleich.
Viele Grüße Gisbert
So sieht es bei mir aus in dem Zeitraum. Im DWD-Forecast sind 3 Stationen. Die nächste ist ca. 6,8km entfernt. Diese Wird auch vom OpenMeteoDWDEnsemble genutzt.
Die beiden anderen sind ca. 10 & 14km entfernt. Alle liefern Rad1h Werte.
Zitat von: gent am 05 September 2024, 19:39:36Zitat von: 300P am 14 August 2024, 19:49:31Bei mir lag es im Mai/Juni einmal am fehlenden optionalen Eintrag (im Backup) beim Inverter (capacity=9500) den ich bis dahin nicht gesetzt hatte - weil ja optional 😮
Dadurch wurden die Daten nicht komplett wieder eingelesen und es gab das gleiche Bild.
Ob dies bei dir dann die Lösung ist ?? 🤔
Und was hast Du dann gemacht?
Kam zu diesem Zeitpunkt mit dem ,,Alt"-Backup und einigen Parametern irgendwie nicht mehr so richtig klar.
Am Ende war es nur einfacher alles neu zu beginnen als weiter im ,,Nirwahna" rumzustochern und noch mehr Zeit zu verplempern 😇.
(Manuell die die Werte aus den Backup-Konfig-Dateien gesucht / kopiert und dann, soweit es ging, in jungfräuliche Modul reingeschubst)
Gruß
300P
Guten Abend,
in meinem contrib liegt ein Update bereit.
In dieser Version ist nun umgesetzt, dass im Log mit verbose 3 gemeldet wird falls die Consumption des Hauses einen nicht erwarteten negativen Stundenwert (Summe) erhält. Es wird aber nichts korrigiert und der User erhält im Log den Hinweis wie er reagieren kann, z.B.:
2024.09.07 17:26:59.115 3: SolCast6 - WARNING - The stored Energy consumption of day/hour 10/17 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumption 10 17'.
Weiterhin gibt nun die Attribute setupOtherProducer01 ... 03. Damit können weitere Nicht-Solarproduzenten eingebunden werden welche in die Verbrauchsrechnung des Hauses mit einfließen.
setupOtherProducerXX <Device Name> pcurr=<Readingname>:<Einheit> etotal=<Readingname>:<Einheit>
Legt ein beliebiges Device und dessen Readings zur Lieferung sonstiger Erzeugungswerte fest (z.B. BHKW, Winderzeugung, Notstromaggregat). Es kann auch ein Dummy Device mit entsprechenden Readings sein.
pcurr Reading welches die aktuelle Erzeugung als positiven Wert liefert
etotal Reading welches die gesamte erzeugte Energie liefert (ein stetig aufsteigender Zähler)
Sollte des Reading die Vorgabe eines stetig aufsteigenden Zählers verletzen, behandelt
SolarForecast diesen Fehler und meldet die aufgetretene Situation durch einen Logeintrag.
Einheit die jeweilige Einheit (W,kW,Wh,kWh)
Beispiel:
attr <name> setupOtherProducer01 windwheel pcurr=total_pac:kW etotal=etotal:kWh
Hinweis: Durch Löschen des Attributes werden ebenfalls die intern korrespondierenden Daten entfernt.
Ich teste selbst auch noch etwas bevor ich die Version einchecke.
LG
Werd dann mal Morgen mein ,,gigantisches" 0.750 kW BHKW einbinden.
Hab dessen Leistung bislang einfach zu meinem WR-Dummy addiert.
Dadurch schien im Winter bei mir (auch ohne Sonnenschein 😎 und sogar in der Nacht🌚) die Grafiksonne 😇.
Aber solange genug Solarenergue erzeugt wird ...... bleibt mein BHKW erst einmal noch im Standby-Betrieb,bis dass meine Logik meint das es nicht mehr genug Sonnennergie für ,,umsonst" geben wird.
Ist also momentan bei mir nichts mit viel testen.....
Gruß
300P
ZitatAber solange genug Solarenergue erzeugt wird ...... bleibt mein BHKW erst einmal noch im Standby-Betrieb,bis dass meine Logik meint das es nicht mehr genug Sonnennergie für ,,umsonst" geben wird.
Wirst du aber trotzdem sehen. Es gibt, sofern ein solcher Producer gesetzt wurde, die entsprechenden Readings:
...
setstate SolCast6 2024-09-07 23:04:28 Current_PP02 22 W
...
setstate SolCast6 2024-09-07 16:59:49 Today_Hour17_BatIn 0 Wh
setstate SolCast6 2024-09-07 16:59:49 Today_Hour17_BatOut 0 Wh
setstate SolCast6 2024-09-07 16:59:49 Today_Hour17_GridConsumption 0 Wh
setstate SolCast6 2024-09-07 16:59:49 Today_Hour17_GridFeedIn 2744 Wh
setstate SolCast6 2024-09-07 16:59:49 Today_Hour17_PPreal02 0 Wh
setstate SolCast6 2024-09-07 16:59:49 Today_Hour17_PVforecast 2338 Wh
setstate SolCast6 2024-09-07 16:59:49 Today_Hour17_PVreal 2467 Wh
....
PPreal02 = Energie Erzeugung von Producer 02 in der entsprechenden Stunde, bei dir dann vermutlich 0 Wh wie bei meinem Dummy.
Guten Morgen DS_Starter,
ja -ich sehe da die folgenden Werte direkt nach der Anlage des zusätzlichen Erzeuger:
attr Forecast setupOtherProducer01 MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
Current_GridFeedIn 1 W 2024-09-08 09:46:51
Current_PP01 0 W 2024-09-08 09:46:11
Current_PV 498 W 2024-09-08 09:46:51
Today_Hour10_GridFeedIn 18 Wh 2024-09-08 09:48:41
Today_Hour10_PPreal01 0 Wh 2024-09-08 09:48:41
Today_Hour10_PVforecast 1042 Wh 2024-09-08 09:48:41
Today_Hour10_PVreal 428 Wh 2024-09-08 09:49:02
Sicherheitsfrage :
Der jeweilige aktuelle Leistungswert des Erzeugers (Current_PPXX) ist leider immer negativ wenn der "Erzeuger" nicht produziert.
Hier wird am Gerät bidirektional auf einer "Phase" des Erzeugers + / - gemessen.
Das ist (positiv) dann die aktuelle Leistung des "Erzeugers" bei Betrieb.
Bei "Standby" bzw. keiner Erzeugung wird dann der aktuelle Verbrauch (negativ) für den Standbybetrieb sowie der Verbrauch beim Anlauf gemessen.
Beim Zählerwert des "Erzeugers" wird nur die Erzeugung ermittelt.
Für den Verbrauch des "Erzeugers" wird ein separater Zählerwert ermittelt.
So wie ich es aktuell sehe wird nur ein positiver Wert genutzt ?!?!?!?!?
Gruß
300P
In der aktuellen Implementierung wird ein positiver/negativer Wert als Erzeugung zur Summe der erzeugten Geamtenergie über alle Erzeuger addiert (Ableitung aus Schlüssel etotal ). Man sieht diesen Anteil in der pvHistory im Schlüssel pprl<Erzeugernummer>. Sollte der Stundenwert pprl<Erzeugernummer> negativ sein, also Energie in den Erzeuger hineingeflossen/verbraucht, wird die resultierende Gesamtbilanz des Hauses um diesen Wert reduziert.
Für die Bilanz ist nur der Attributschlüssel etotal relevant, daraus wird pprl<Erzeugernummer> und die Bilanz errechnet. Der Schlüssel pcurr ist lediglich eine Information des momentanen Zustandes.
Wenn ich deine Technik richtig verstanden habe, passt das Setup mit der Logik im Modul überein. Ich werde aber die Beschreibung für pcurr in ComRef anpassen.
LG
Habe das Modul im contrib upgedated.
Was mir gerade aufgefallen ist ... die neuen Producer sind noch nicht in der Energieflußgrafik implementiert.
Habe ich total vergessen. ;)
@kask, vllt. hast du Lust/Zeit dich schonmal daran zu versuchen.
Du meinst mehrere "Sonnen" bloß in passend? So wie die Consumer? Klingt interresant auch für mehrere PV Anlagen/Strings oder einen Generator etc.
Ja genau,
Man müsste von der Sonne und den anderen Producern die Laufkette(n) von oben zum Haus führen und von dort aus nach rechts zur Batterie, links zum Netz und nach unten zu den Verbrauchern. Die allgemeine Lampe, die momentan rechts ist, müssten wir zu den Consumern gruppieren.
Wenn wir das so umsetzen, können wir auch In/Out zum/vom Netz bzw. der Batterie mit entsprechenden Vorzeichen und dementsprechenden Laufrichtungen der Ketten versehen.
Zitat von: DS_Starter am 08 September 2024, 13:00:38... können wir auch In/Out zum/vom Netz bzw. der Batterie mit entsprechenden Vorzeichen ...
Hallo DS_Starter,
in den letzten Tagen gab es ja eine kontroverse Diskussion wegen der Vorzeichen bei "erzeugter" und "verbrauchter" Energie.
Ist beabsichtigt etwas an der bestehenden Situation zu ändern, und falls ja, wie soll das dann ablaufen? Ich denke, dass jeder, der Interesse an einer Bilanzierung hat, das für sich umgesetzt hat - mit welchen Vorzeichen auch immer.
Falls es möglich ist einen Wunsch zu äußern, dann bin ich dafür die jetzige Situation beizubehalten.
Viele Grüße Gisbert
Ich kann dich beruhigen. An der Implementierung im Modul wird sich nichts ändern. Den Status quo hatte ich ja in #902 beschrieben.
Im Modul gibt es zur Zeit 5552 Minuszeichen und 381 Pluszeichen. Hinter den meisten Vorkommen verbergen sich Rechenoperation zu Erzeugungen und Verbräuchen. Ich habe nicht vor jede einzelne Rechenoperation ohne Grund auf den Prüfstand zu stellen.
Nein, es ging nur um die Energieflußgrafik. Wenn wir sie wegen zusätzlichen Erzeugern anpassen müssen, kann man die Energieflußrichtung in der Grafik neben der vorhandenen Visualisierung auch mit dem Vorzeichen versehen wenn es sich für das allgemeine Verständnis anbietet.
Zitat von: DS_Starter am 08 September 2024, 10:46:29Für die Bilanz ist nur der Attributschlüssel etotal relevant, daraus wird pprl<Erzeugernummer> und die Bilanz errechnet. Der Schlüssel pcurr ist lediglich eine Information des momentanen Zustandes.
Wenn ich deine Technik richtig verstanden habe, passt das Setup mit der Logik im Modul überein. Ich werde aber die Beschreibung für pcurr in ComRef anpassen.
LG
Zur Info wg. neuer Version:
Meine BHKW-Logik hat sich entschieden heute ab 21:06 Uhr das BHKW mal zu starten und entsprechend zeitverzögert nach ca. 1h dann mit der Stromproduktion zu beginnen.
=> sieht alles bislang prima (65 W ->ab 22:00Uhr)
(Den o.g. Wert "pprl01" sehe ich bislang noch nicht)
Today_Hour22_BatIn 188 Wh 2024-09-08 21:59:57
Today_Hour22_BatOut 1467 Wh 2024-09-08 21:59:57
Today_Hour22_GridConsumption 9 Wh 2024-09-08 21:59:57
Today_Hour22_GridFeedIn 9 Wh 2024-09-08 21:59:57
Today_Hour22_PPreal01 0 Wh 2024-09-08 21:59:57
Today_Hour22_PVreal 0 Wh 2024-09-08 21:59:57
Today_Hour23_BatIn 186 Wh 2024-09-08 22:24:57
Today_Hour23_BatOut 391 Wh 2024-09-08 22:24:57
Today_Hour23_GridConsumption 1 Wh 2024-09-08 22:24:47
Today_Hour23_GridFeedIn 1 Wh 2024-09-08 22:24:47
Today_Hour23_PPreal01 65 Wh 2024-09-08 22:24:47
Today_Hour23_PVreal 0 Wh 2024-09-08 22:24:47
Die Grafik sieht "natürlich" jetzt bei der Produktion "seltsam" aus :o
Gruß
300P
Bildschirmaufnahme 2024-09-08 um 22.45.39.mov
Ich habe die Modulinstanz jetzt auf einem separaten Raspberry Pi laufen. Die aktuellen Werte für Verbrauch, Speicher und PV übermittle ich dahin per cloneDummy. Modul auf aktuellem Stand, Modulkonfiguration laut Test ok.
Soweit, so gut: Leistung etc. werden vom 76_SolarForeCast aus dem cloneDummy problemlos gelesen. Derzeitiger Verbrauch ca. 600 W.
Aber, warum um Himmels Willen, sagt mir das Modul:
ZitatNextHours_Sum04_ConsumptionForecast 69962 Wh
sowie
ZitatRestOfDayConsumptionForecast 80160 Wh
und
ZitatTomorrow_ConsumptionForecast 101749 Wh
Das ist ziemlich genau das Zehnfache dessen, was man erwarten sollte.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 09 September 2024, 11:26:54Das ist ziemlich genau das Zehnfache dessen, was man erwarten sollte.
Wenn Du das neu konfigurierst, wird der Gesamtverbrauch vom Zähler dem 1. Tag zugeschlüsselt. Entsprechend stimmen die Vorhersagen nicht. Entweder warten bis es sich einpendelt oder die entsprechenden Daten aus dem Modul zurücksetzen.
Nachtrag:
Oder Du hast irgendwo die Einheiten vermischt bzw. nicht korrekt konfiguriert...
ZitatWenn Du das neu konfigurierst, wird der Gesamtverbrauch vom Zähler dem 1. Tag zugeschlüsselt. Entsprechend stimmen die Vorhersagen nicht.
So ganz glauben kann ich das nicht. Der "Gesamtverbrauch vom Zähler" ist eine ganz andere Zahl, die durch nichts auf diese rund 100 kWh/Tag hindeutet. Wir haben zwar die ersten 9 Tage vom September nun fast hinter uns - aber woher sollte das Modul den Monatsverbrauch wissen?
Zitat von: TheTrumpeter am 09 September 2024, 15:11:22Oder Du hast irgendwo die Einheiten vermischt bzw. nicht korrekt konfiguriert...
Abgesehen davon, dass mir solche trivialen Fehler in der Regel schnell selbst auffallen, wäre das ein Faktor 1000, nicht 10.
Außerdem lief das ja auf einem Testsystem, dieses Verhalten trat bisher nicht auf.
Aber gut, warten wir mal einen Tag lang.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 09 September 2024, 17:53:54Zitat von: TheTrumpeter am 09 September 2024, 15:11:22Oder Du hast irgendwo die Einheiten vermischt bzw. nicht korrekt konfiguriert...
Abgesehen davon, dass mir solche trivialen Fehler in der Regel schnell selbst auffallen, wäre das ein Faktor 1000, nicht 10.
Tut mir leid, ich wusste nicht, dass es hier auch Menschen ohne Fehler gibt.
Stimmen denn die folgenden Werte mit den Zählern überein?
Today_HourX_GridConsumption
Today_HourX_GridFeedIn
Today_HourX_PVreal
Die werden aus den jeweils zu Stundenbeginn und Stundenende vom Modul zwischengespeicherten Gesamtzählerständen gebildet. Wenn die richtig sind, ist ein Einheitenfehler jedenfalls auszuschließen.
Zitat von: Prof. Dr. Peter Henning am 09 September 2024, 17:53:54So ganz glauben kann ich das nicht. Der "Gesamtverbrauch vom Zähler" ist eine ganz andere Zahl, die durch nichts auf diese rund 100 kWh/Tag hindeutet. Wir haben zwar die ersten 9 Tage vom September nun fast hinter uns - aber woher sollte das Modul den Monatsverbrauch wissen?
Ich habe mir nicht gemerkt wie lange Deine Konfiguration schon läuft.
Soweit ich mich erinnere war bei mir sowohl Zähler-Gesamtverbrauch als auch PV-Gesamterzeugung dem 1. Tag der SolarForecast-Konfiguration zugeschlüsselt. Je nachdem wie groß der Ringpuffer ist, der für die Vorhersageberechnung verwendet wird, dauert es wohl ein paar Tage, bis diese Initialwerte aus dem Puffer fallen & die Vorhersage müsste mit jedem Tag besser werden.
Die stündlichen Werte stimmen alle. Aber irrerweise ist auch heute wieder
ZitatTomorrow_ConsumptionForecast 101416 Wh
Zitat von: TheTrumpeter am 10 September 2024, 07:04:36Tut mir leid, ich wusste nicht, dass es hier auch Menschen ohne Fehler gibt.
::)
Lies es doch noch einmal: Mir fallen die eigenen Fehler bei Konfigurationen auf, weil ich erst alle Möglichkeiten überprüfe, bevor ich etwas ins Forum schreibe. Und "Menschen ohne Fehler" ist nun wirklich etwas Anderes, das gibt es nur bei den Grünen.
LG
pah
Wie wäre es mit einem ,,set reset consumption" ;)
Könnte ja sein das da der Hund 😅,,begraben liegt"
Gruß
300P
Gerade durchgeführt. Keine substanzielle Auswirkung, Verbrauchsprognose für morgen immer noch > 100 kWh.
LG
pah
Dann zeig doch bitte mal ein
,,get ... valCurrent"
Danke
Kommando zurück: nach ein paar Minuten hat der Resetbefehl gewirkt, danke für den Tipp. Ein get valCurrent zeigt jetzt als Prognose "warte auf weitere Tage mit einer Verbrauchszahl". Womit sich die Frage stellt, woher der absurd hohe Wert kam.
LG
pah
...manchmal mus man es einfach hinnehmen, dass da irgendwo ein Haken 🪝 an irgendeiner Sache ist den man nicht ergründen will - weil es ,,ab jetzt" einfach funktioniert 😎😉🥳🥂🍾
Etwas OT jetzt...
Äh - nein, das ist das Gegenteil von meiner Arbeitsweise. Und bei meinen Studenten würde ich das auch nicht akzeptieren.
LG
pah
Nochmals OT:
...ist doch ,,nur" Hobby und für Zuhause - keine Arbeit und kein Studium. 🤓 (bin in Rente)
OT Ende
Aber es gab in der Vergangenheit schon das ein oder andere Mal Probleme mit den vorhersagewerten bei Usern die neu aufgesetzt haben.
Meist war es ein n.i.O - Wert in den Vergangenheitswerten der für solche überzogenen Forecast-Werte (Solar- oder Verbrauchswert) der Auslöser war.
Da es bei deinen ,,tollen" Werten um die Verbrauchswerte ging lag die Ursache eindeutig dort und es musste daher mit dem ,,reset" der Verbrauchswerte zu 99,9 %-iger Sicherheit klappen...😉
So ganz ist das mit dem "Reset" gestern abend doch nicht erfolgreich gewesen.
Das hat zwar gestern den Vorhersagewert genullt. Aber heute früh (nach der Debatte Harris-Trump...) ist der Vorhersagewert für den nächsten Tag 2,4 kWh (das ist ungefähr der Betrag, der heute zwischen 0:00 und 5:00 aus dem Netz gezogen wurde). Finde ich etwas seltsam, weil eine lineare Extrapolation zu 11,52 kWh führen sollte).
Zweitens zeigt mir das Modul _heute_ einen
ZitatRestOfDayConsumptionForecast 96925 Wh
Das bedeutet, der "genullte" Vorhersagewert von gestern abend wurde nicht um Mitternacht auf den heutigen Tag übertragen, sondern die alte (falsche) Vorhersage wird für heute weiter verwendet.
Wenn ich mir die weiteren Daten ansehe, sind auch noch ein paar Fragezeichen vorhanden.
Beispiel: Ich habe zwei Strings in meiner zweiten PV-Anlage, die sind mit dem Attributwert
ZitatsetupStringPeak PV2.south=2.64 PV2.north=3.52
(in kWp) eingetragen. Warum und wie macht das Modul daraus ein
Zitatallstringspeak => 5460
LG
pah
Und OT:
Na, in meinem (ehemaligen) Job ist das schwer zu trennen. Wenn ich jetzt noch ein weiteres Buch über Hausautomatisierung schreibe: Ist das nun Hobby, oder Arbeit?
Ende OT
Zitat von: Prof. Dr. Peter Henning am 10 September 2024, 20:31:12Mir fallen die eigenen Fehler bei Konfigurationen auf, weil ich erst alle Möglichkeiten überprüfe, bevor ich etwas ins Forum schreibe.
Ich prüfe es auch selbst 3x, bevor ich was ins Forum schreibe.
Trotzdem rutscht MIR manchmal ein Fehler durch, weil ich die Anleitung vielleicht nicht richtig verstanden/interpretiert habe oder möglicherweise gerade den Wald vor lauter Bäumen nicht mehr gesehen habe.
Zitat von: Prof. Dr. Peter Henning am 11 September 2024, 05:31:17Das hat zwar gestern den Vorhersagewert genullt. Aber heute früh (nach der Debatte Harris-Trump...) ist der Vorhersagewert für den nächsten Tag 2,4 kWh (das ist ungefähr der Betrag, der heute zwischen 0:00 und 5:00 aus dem Netz gezogen wurde). Finde ich etwas seltsam, weil eine lineare Extrapolation zu 11,52 kWh führen sollte).
Wer sagt, dass die Vorhersage linear verläuft?
Soweit ich die Idee hinter dem Modul bisher verstanden habe, sind die Stundenwerte Basis für Hochrechnungen. Wenn Du gestern Abend "genullt" hast, dann hat das Modul zwar Vorhersagedaten für die Stunden nach dem Reset, nicht aber für die vor dem Reset. Daher könnte es ein, dass die Stunden vor dem Reset einfach mit "0" in die Vorhersage eingehen.
Du kannst das aber überprüfen, indem Du Dir die Vorhersagedaten ausliest:
get mySolarForecast nextHours
Die Werte confc und confcEx sind dann die stündlichen Prognosewerte, die aber auch den Werten in der Vorhersagegrafik entsprechen. Dort würdest Du auch sehen welchen Verbrauch das Modul für die einzelnen Stunden annimmt.
Guten Morgen,
Zeig einmal im Lauf des Tages mit get ... pvHistory den aktuellen Stand deiner Daten.
Dort erkennt man ebenfalls ob und wo etwas in/an den Daten hängt.
Und zusätzlich noch ein get ... pvCircular wäre hilfreich.
Es gibt im Modul die Moglichkeit solche evtl. fehlerhaften Werte in diesen historischen Werte-Tabellen zu löschen.
Gruß
300P
Zitat von: TheTrumpeter am 11 September 2024, 06:43:59Wer sagt, dass die Vorhersage linear verläuft?
Na, mal langsam.
Erstens habe den Reset gestern um 21:00 durchgeführt - für die Zeit bis Mitternacht sind also Daten vorhanden.
Zweitens muss selbstverständlich jede Vorhersage auf Basis der _jüngsten_ Vergangenheit geschehen, das ist einfach gute wissenschaftliche Praxis. Und bei einem einigermaßen konstanten Verbrauch (wie bei mir) läuft das auf eine lineare Fortschreibung hinaus, das ist elementare nummerische Mathematik.
Schlussfolgerung: Ich verstehe die hier angewandten Algorithmen nicht. Bevor ich dieses Verständnis nicht habe, werde ich das nicht weiter kritisieren. Aber trauen werde ich dem auch nicht...
LG
pah
Soweit ich weiß basiert die Vorhersage auf die Vergagenheit.
Wieso sollte man da eine Hochrechnung einbringen wenn nicht einmal eine ganze Datenbasis vorhanden ist (21.00 - 09:40).
Klar könnte man das machen wenn man sofort Daten haben will/muß.
Aber es ist jetzt nun erstmal egal ob bei einem die Daten 24/7 konstant sind. Nicht mal ein Datensatz ist komplett (24h) um irgend etwas an Vorhersage zu geben.
Und ob ob es da Sinn macht dahingehend was einzupflegen um <24h Zeitvorteil zu erhalten ist fragwürdig.
Am darauf folgenden Tag sollte erstmals brauchbares an Daten kommen bei 24/7 ziemlich konstanten Verbrauch. Die Zeit sollte man da schon mitbringen können.
Die Frage ist aber wirklich warum da ein 10facher Wert ausgegeben wurde.
Das gilt es schon zu hinterfragen was da ursächlich für verantwortlich war. Schliesslich geht der 10fache Wert dann so auch in Zukunft auf die Wertbildung. Und das würde eine normalisierung stark verzögern bzw. die nächsten Tage und die Tage auf dem darauf folgenden Monat ziemlich verfälschen.
Das ist sehr unschön.
So wie ich das verstanden habe wurde ja ein neues Device eingefplegt. Das kann doch eigentlich keine "alt Lasten" aufnehmen.
Was hat das jetzt hervorgerufen. Ich finde es auch komisch.
Wie geschrieben: Ich werde nur kritisieren, was ich verstanden habe.
Es dauert eine Weile, sich durch 20.000 Zeilen Code zu graben.
Generell aber gilt: Wenn keine Vorhersage möglich ist, sollte auch keine ausgegeben werden. Das kann man schon erwarten - und nicht etwa einen Wert, dessen Fehlerhaftigkeit im Nachhinein ausführlich begründet wird.
Konkret also: Im dargestellten Fall könnte entweder statt eines Vorhersagewertes eine Warnung auftauchen ("nicht genug Daten"). Oder ein vereinfachter Wert (von mir aus per Extrapolation) mit zusätzlicher Warnung ("verringerte Genauigkeit").
LG
pah
Die Verbrauchsprognose wird aus den aufgezeichneten Stundenwerten der pvHistory Key "con" jedes Tages und jeder Stunde über Durchschnittskalkulation die Ableitung für die kommenden Stunden erstellt. Dabei werden nur die gleichen Stunden der Tage betrachtet. Mit dem Attr affectConsForecastIdentWeekdays kann darüber hinaus bestimmt werden ob ebenfalls nur identische Wochentage (Mo - So) zueinander betrachtet werden sollen um "Gewohnheiten" an bestimmten Tagen nicht über alle anderen Tage zu verteilen.
Die so ermittelten Prognosen kann man sich mit "get ... nextHours" im Key "confc" ansehen. Der Schlüssel "confcEx" enthält die Verbrauchsprognose ohne den aufgezeichneten Energieanteil registrierter Verbraucher. Damit kann z.B. die verwendete Ladeenergie eines E-Autos von der Prognose ausgeblendet werden. Soll ein Verbraucher in diesem Kontext in den Key "confEx" eingehen, kann der Key "exconfc=1" im Consumerattribut gesetzt werden.
Im Nachhinein eine Ursachenanalyse vornehmen zu wollen ist müßig. Wenn etwas nicht einleuchtet hilft in diesem Kontext das Attr ctrlDebug=consumption um Anhaltspunkte zu erhalten solange der Zusatnd vorhanden ist.
LG
@300P
ZitatZur Info wg. neuer Version:
Meine BHKW-Logik hat sich entschieden heute ab 21:06 Uhr das BHKW mal zu starten und entsprechend zeitverzögert nach ca. 1h dann mit der Stromproduktion zu beginnen.
=> sieht alles bislang prima (65 W ->ab 22:00Uhr)
(Den o.g. Wert "pprl01" sehe ich bislang noch nicht)
"pprl01" ist ein Key in der pvHistory, kein Reading. Es gibt pprl01 - pprl03.
ZitatDie Grafik sieht "natürlich" jetzt bei der Produktion "seltsam" aus :o
Ja das müssen wir noch anpassen. Hatte ich nicht auf dem Schirm.
Weiß nicht ob kask schon was gemacht hat. Ich habe gerade etwas wenig Zeit, aber jetzt wird es ja wieder etwas herbstlicher. ;)
LG,
Heiko
Hallo Zusammen,
nach geraumer Zeit hatte ich bei mir mal wieder dieses Modul aktualisiert und augenscheinlich läuft es auch soweit korrekt.
Dennoch habe ich an einer Stelle ein Verständnisproblem.
Diese Readings bekomme ich korrekt anzeigt, weshlab ich davon ausgehe, dass das Batterie-Setup stimmt.
ZitatCurrent_PowerBatIn 709 W 2024-09-12 10:27:34
Current_PowerBatOut 0 W 2024-09-12 10:24:47
Aber die dokumentierten Stundenwerte stimmen meines Erachtens überhaupt nicht, hier einmal exemplarisch:
ZitatToday_Hour11_BatIn 100 Wh 2024-09-12 10:24:47
Today_Hour11_BatOut 0 Wh 2024-09-12 10:24:47
Die Werte sind hier IMMER Vielfache von 100 Wh und weit weg von der Realität.
Dies hier ist mein Setup:
ZitatsetupBatteryDev
BYD_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W intotal=Summe_Ladung:kWh outtotal=Summe_Entladung:kWh cap=5120 charge=BatteryChargePercent
Welche zusätzlichen Infos benötigt Ihr ggf. noch?
VG,
Bozan
Hallo Heiko,
ich weiß, dass man die fhem.cfg nicht editieren soll. Da ich vor vielen Jahren mal damit angefangen habe, Definitionen in eigene Module (Own modules and helper files) per include in der fhem.cfg auszulagern, hatte ich auch das mit SolarForecast getan. Bisher gab es aus der Erinnerung heraus keine Probleme damit, Devices in "Own modules and helper files" auszulagern. Diesmal hat es bei SolarForecast dazu geführt, dass 2 Informationen verlorengegangen sind:
- setupStringAzimuth
- setStringDeclination
Diese Infos waren dank deiner geführten Installation schnell nachgeholt. Auch scheinen log-Dateien noch vorhandenen zu sein, ebenso historische Daten. Alle anderen setup-Definitionen sind als Attribute ausgeführt, so dass sie nach einem Fhem-Neustart noch vorhanden waren.
Um Kommentaren vorzubeugen - ja, es ist nicht sonderlich schlau die fhem.cfg zu editieren, man sollte es besser sein lassen und dem Drang nach Ordnung in der fhem.cfg nicht nachgeben.
Viele Grüße Gisbert
@Bozan,
für die Stundenwerte Today_HourXX_BatIn/BatOut ist das Quellenreading im Schlüssel intotal / outtotal zuständig. Es ist zu vermuten, dass der Dateninput an dieser Stelle nicht ok ist.
Du kannst dir die Startwerte jeder Stunde in der pvHistory im Schlüssel batouttotal bzw. batintotal anschauen und verifizieren ob sie deiner Erwartung entsprechen. Die Differenzen zum Startwert der nächsten Stunde entsprechen dem jeweiligen In / Out.
@Gisbert,
ich denke nicht, dass deine fhem.cfg-Gestaltung in diesem Fall daran Schuld war. Ein Fehler bei der Abarbeitung der fhem.cfg würde die Devices erst garnicht erstellen.
Die Readings werden beim Start von FHEM aus der Datei fhem.save geladen und in den Devices wiederhergestellt.
Die Steuerreadings setupStringAzimuth und setupStringDeclination machen da keine Ausnahme.
Wenn ich im Modul Strukturänderungen wie Readingumbenennungen oder Switches von Reading zu Attributen vornehme, lasse die entsprechenden Automatikroutinen für längere Zeit (ca. 3 Monate) im Modul. Nach dieser Zeit gehe ich davon aus dass jeder Modulnutzer ein Update gemacht hat und auf dem neuseten Stand ist und entferne diese Routinen wieder damit ich den Überblick behalte. Das kann u.U. auch mal zu früh sein, das weiß ich natürlich nicht.
LG
Danke DS_Starter, da hatte ich doch tatsächlich einen Dezimalfehler, der mir bisher noch nicht aufgefallen war... >:(
Jetzt sollte es wohl passen. Ich beobachte es morgen einmal.
Schönen Abend!
Kurze Frage. Sollte das so in etwa am ende aussehen? (icons, farben ausser acht gelassen)
Hi kask,
nicht ganz.
Die Sonne (PV-Erzeugung) und die anderen Erzeuger in der obersten Reihe gleichberechtigt nebeneinander.
Alle liefern an das darunterligende Haus. Vom Haus aus geht es nach rechts zur Batterie und nach links zum öffentlichen Netz. Nach unten geht es (wie jetzt) auf alle Verbraucher. Auch die Lampe als "Restverbraucher" würde ich nun auch in der untersten Zeile verorten. Vllt. hats du auch eine bessere Idee weil man ja die Lampe auch ausblenden kann wenn man sie nicht möchte.
OK. glaube ich verstehe. Das Haus ist sozusagen der Sternpunkt an dem alles zusammen läuft.
erzeuger1 erzeuger2 erzeuger3
: : :
netz --- [ haus ]--- Speicher
: :
verbraucher1 verbraucher2
Ja genau, so meine Idee.
@kask,
in meinem contrib liegt ein Update.
In der Funktion _flowGraphic sind die aktuellen Producervariablen verfügbar zur Verwendung:
my $gp01 = CurrentVal ($hash, 'generationp01', 0);
my $gp02 = CurrentVal ($hash, 'generationp02', 0);
my $gp03 = CurrentVal ($hash, 'generationp03', 0);
Zeile 13789 ff
Da muss ich mir mal ein Device mit mehreren erzeugern und verbrauchern zusammen schustern zum testen.
Kann ja am Ende nicht so kompliziert sein, Man hat ja eine Basis mit dem jetzigen.
Hatte mir das auch schon einmal angeguckt. Fast geschmeidige 400 Zeilen Quellcode für den flowchart beim jetzigen.
Ich benutze zum entwickeln und testen einen ganzen Satz Dummies um echte Devices simulieren zu können.
Ja die wollte ich mir auch via fhem2fhem auf ein Testsystem schlören. Wollte ich eh schon lange mal ausprobieren was da alles so möglich ist.
Setze ich morgen mal auf und schau mal was ich da zusammen geschossen bekomme.
Das würde bei mir schon mal nicht passen. Denn meine 1. PV-Anlage läuft komplett am "Haus" vorbei und speist nur ins Netz ein. Außerdem behandele ich meine Wallbox separat von den "Haus"-Verbrauchern. Das ist einerseits aus steuerlichen Gründen sinnvoll, und andererseits nötig,cwenn man die Nachbarn auch partizipieren lassen will.
LG
pah
ZitatDas würde bei mir schon mal nicht passen. Denn meine 1. PV-Anlage läuft komplett am "Haus" vorbei und speist nur ins Netz ein.
Hat die PV-Anlage denn einen eigenen Netzanschluß mit Zähler?
Ansonsten wird es ja durch "das Haus" 1:1 hindurchgeleitet und würde sich auch so darstellen lassen.
ZitatAußerdem behandele ich meine Wallbox separat von den "Haus"-Verbrauchern.
Das wäre natürlich eine noch zu lösende Herausforderung. Allerdings wird _vermutlich_ der Energiefluß zunächst in das "Haus" hineinführen und dann nochmal extra an der Wallbox gezählt?
Ja, tasächlich eigener Zähler, danach erst zusammengeführt.
Ich denke, ihr habt hier ein semantisches Problem geschaffen. Nämlich schreibt "Haus", meint aber "Zählerkasten" oder "Energiezentrale", oder so etwas.
Denn einerseits wird der Anschluss der Wallbox eben nicht "durch das Haus" geführt. Und andererseits sind ja die Verbraucher bei Euch außerhalb des "Hauses" angeordnet - was auch nicht so ganz realistisch ist.
Ihr müsstet auch damit rechnen, dass innerhalb eines "Hauses" mehrere Zähler sind. Ich schlage also vor, dass ihr die Hausmetapher noch mal überdenkt.
LG
pah
ZitatIch denke, ihr habt hier ein semantisches Problem geschaffen. Nämlich schreibt "Haus", meint aber "Zählerkasten" oder "Energiezentrale", oder so etwas.
Ja, da hast du Recht. Das "Haus" steht stellvertretend für einen Knotenpunkt, an dem alle Energieflüsse der Produzenten, des öffentlichen Netzes zusammenlaufen und je nach Lage an die Verbraucher weitergeleitet bzw. eingespeichert / ausgespeichert werden.
Das Sinnbild des Hauses ist ein recht markantes Objekt für diesen Zweck. Wer ein besseres Bild für diese Funktionalität sieht, kann den den Vorschlag gern äußern. Ich denke wir hängen jetzt nicht zwanghaft an dem Haus als Versinnbildlichung.
LG,
Heiko
Ich habe noch eine Stelle, die mit Eurem "Haus" als Zentrum nicht übereinstimmt. Mein Speicher ist nämlich direkt an den Wechselrichter angeschlossen, und wird hauptsächlich von dem gesteuert.
Und die zentrale Stelle ist in meiner Grafik mit "FHEM" bezeichnet - aber mit kleinem FH und großem EM. b
Das Haus ist hier synonym für alle Verbraucher außer der Wallbox.
LG
pah
Ja, das wird alles sehr kompliziert alles ersichtlich & verständlich darzustellen.
Da gibt es etliche Konstellationen.
Wobei, streng genommen der zweite Zähler ja am "Haus" vorbei geht und auch nicht für die Consumer so nutzbar ist. Ist ja ein Volleinspeiser also voll an der Automatiesierung vorbei. Muss man das dann in den flow einbinden?
Edit:
Zudem ist es doch eigentlich egal wer/was/wie den Speicher befeuert. Wichtig ist das zu ersehen ist was da gerade passiert am Speicher.
Wir sind universell unterwegs. Ganz spezielle Fälle lassen sich dann möglicherweise nicht umfänglich darstellen. Wir gehen ja davon aus, dass der User ein Hausnetz betreibt dem alle Energie zugeführt wird bzw. aus dem Energie abfließt, entweder zu Verbrauchern, der Batterie oder dem Netz.
Deswegen ist deine Skizze m.M. nach genau das Ziel und sollte 99% aller Fälle abbilden können.
Na ja, da kommen wir in der Philosophie nicht zueinander. Macht aber nichts, sind halt andere Ansätze.
- Natürlich visualisiere (und kontrolliere) ich auch den Volleinspeiser. Man will ja schließlich wissen, wieviel Geld fließt.
- Nein, mir ist das mit dem Speicher nicht egal - weil der Wechselrichter die kritische Komponente ist.
LG
pah
P.S.: Ich habe noch eine Besonderheit, die nicht in Eurem Bild abbildbar ist. Nämlich eine Notstromumschaltung mit eigenem Smartmeter.
Hi,
ich bräuchte mal wieder Hilfe.
Ich habe die Wettervorhersage wieder auf DWD umgestellt.
Jetzt bekomme ich nach einiger Zeit beim Anlagencheck immer:
The Prediction time of Weather data is older than expected when using MOSMIX_S.
Data time forecast: 14.09.2024 16:00:00
Check the DWD device(s) for proper functioning of the data retrieval.
checked global Weather parameters:
MOSMIX variant or ICON Forecast Model, Age of Weather data.
Umgestellt habe ich:
setupRadiationAPI OpenMeteoDWD-API
setupWeatherDev1 DWD_Birkenau
setupWeatherDev2 DWD_Weiher
Ich sehe dass das Forecast Device seine Updates macht:
OpenMeteo: 14.09.2024 18:05:24 API Abfrage erfolgreich
automatischer Zyklus: nach 14.09.2024 18:20:25 (73/9627)
Das ist aktuell.
Die DWD Devices stehen auf:
forecastRefresh 1
forecastResolution 1
Es sagt:
fc_state updated 2024-09-14 17:32:30
fc_time 2024-09-14 16:00:00 2024-09-14 17:15:27
fc_url https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
nextUpdate 18:22:44
nextcycle 23:20:09
Die vom Version DWD ist und war soweit ich weiß die letzte aus dem DWD Thread:
VERSION 1.017003
Gab es da noch etwas zu beachten?
Oder war das normal?
Danke und Gruß,
Stefan
Hallo Stefan,
die aktuellste Entwicklungsversion des DWD-Moduls welches zusammen mit SF getestet ist, kannst du aus meinem contrib ziehen.
Mit dem Attr forecastRefresh=1 stellst du MOSMIX_S ein. (siehe auch "help DWD_OpenData en" wenn updated)
Soweit so gut. Der DWD aktualisiert über den Tag diese Daten jede Stunde. Es gibt aber zweimal am Tag Früh und Abend, glaube 18:00 eine Lücke wo der DWD sich länger Zeit lässt. In dieser Zeit wird der Aktualitätsindikator für das Wetter gelb.
LG
Hi Heiko,
danke, ja es war einmal um 18 Uhr rum.
Ich werde mal noch auf deine Contrib Version wechseln.
Gruß,
Stefan
Kurze Rückmeldung:
Ich habe es noch nicht geschaft das Flowdiagram anzupassen.
Habe soweit alles vorbereitet und mir schon einmal die Optionen angeschaut.
Zur Umsetzung ist es aber noch nicht gekommen.
kriegen wir aber aber noch hin. Ih hoffe in den nächsten 2 Wochen kann das finalisiert werden.
So mein Plan.
Prima, danke für deine Unterstützung! 8)
Hallo kask und DS_Starter,
mir ist etwas kleines aufgefallen und ich möchte es kurz ansprechen.
In der Tabelle wird "Deviation today: 19,3 %" also mit einem Dezimalkomma angezeigt, während es als Reading mit 2 Nachkommastellen und Dezimalpunkt angezeigt wird. In Perl/Linux sollte es doch immer ein Dezimalpunkt sein - oder nicht?
Viele Grüße Gisbert
Moin Gisbert,
die Darstellung in der Kopfgrafik soll von der Spracheinstellung abhängig sein, also bei DE mit Komma und bei EN mit Punkt.
Danke für den Hinweis, bei Einstellung EN ist es nämlich ebenfalls ein Komma.
Das passe ich mit der nächsten Version an.
Grüße,
Heiko
Hallo zusammen,
ich möchte meine Wallbox als Verbraucher anlegen. Sie ist dreiphasig angeschlossen und schaltet zwischen 6 und 16 Ampere.
Aktuell steuere ich das Ganze mit einem DOIF. Der Ladevorgang startet erst bei einem Überschuss von 4140 W. Wenn nicht genügend Überschuss vorhanden ist, würde ich gerne den Hausspeicher als Puffer nutzen, um den Ladevorgang trotzdem zu ermöglichen. Der Hausspeicher soll jedoch am Ende des Tages noch genügend Kapazität haben, um die Zeit bis zum nächsten PV-Überschuss zu überbrücken.
Ist dies möglich bzw. hat das bereits jemand so realisiert und könnte mir eine Starthilfe geben?
(([SUN2000_10KTL:Netz_Bezug_Einspeisung] + [SUN2000_10KTL:Bat_Bezug_Einspeisung]) >= 4540
and [$SELF:status] eq "PV"
and [Wallbe:Device_status] eq "Ladekabel angeschlossen"
and [SUN2000_10KTL:state] eq "opened")
{
my $netz_bezug_einspeisung = [SUN2000_10KTL:Netz_Bezug_Einspeisung] + 0;;
my $bat_bezug_einspeisung = [SUN2000_10KTL:Bat_Bezug_Einspeisung] + 0;;
my $new_value = int(($netz_bezug_einspeisung + $bat_bezug_einspeisung) / 230 / 3);;
$new_value = 6 if $new_value < 6;;
$new_value = 16 if $new_value > 16;;
fhem("set Wallbe Ladestrom_Vorgabe $new_value");;
fhem("set Wallbe Lade_Freigabe Ein");;
}
DOELSEIF
(
([SUN2000_10KTL:Netz_Bezug_Einspeisung] + [SUN2000_10KTL:Bat_Bezug_Einspeisung]) >= 890
and ([Wallbe:Ladestrom_Vorgabe] + 0) >= 6
and [$SELF:status] eq "PV"
and [Wallbe:Device_status] eq "Fahrzeug lädt"
and [SUN2000_10KTL:state] eq "opened"
)
{
my $netz_bezug_einspeisung = [SUN2000_10KTL:Netz_Bezug_Einspeisung] + 0;;
my $bat_bezug_einspeisung = [SUN2000_10KTL:Bat_Bezug_Einspeisung] + 0;;
my $new_value = [Wallbe:Ladestrom_Vorgabe] + int(($netz_bezug_einspeisung + $bat_bezug_einspeisung) / 230 / 3);;
$new_value = 6 if $new_value < 6;;
$new_value = 16 if $new_value > 16;;
fhem("set Wallbe Ladestrom_Vorgabe $new_value");;
fhem("setreading DOIF_Ladestation Ampere_errechnet $new_value");;
}
DOELSEIF
(
([SUN2000_10KTL:Netz_Bezug_Einspeisung] + [SUN2000_10KTL:Bat_Bezug_Einspeisung]) < 50
and ([Wallbe:Ladestrom_Vorgabe] + 0) > 6
and [$SELF:status] eq "PV"
and [Wallbe:Device_status] eq "Fahrzeug lädt"
and [SUN2000_10KTL:state] eq "opened"
)
{
my $netz_bezug_einspeisung = [SUN2000_10KTL:Netz_Bezug_Einspeisung] + 0;;
my $bat_bezug_einspeisung = [SUN2000_10KTL:Bat_Bezug_Einspeisung] + 0;;
my $floor_value = POSIX::floor(($netz_bezug_einspeisung + $bat_bezug_einspeisung) / 230 / 3);;
$floor_value = $floor_value == 0 ? -1 : $floor_value;;
my $new_value = [Wallbe:Ladestrom_Vorgabe] + $floor_value;;
$new_value = 6 if $new_value < 6;;
$new_value = 16 if $new_value > 16;;
fhem("set Wallbe Ladestrom_Vorgabe $new_value");;
fhem("setreading DOIF_Ladestation Ampere_errechnet $new_value");;
}
DOELSEIF
(
([Wallbe:Device_status] eq "Fahrzeug lädt"
or
[Wallbe:Device_status] eq "Ladekabel angeschlossen")
and
([$SELF:status] eq "langsam"
or
[$SELF:status] eq "schnell")
)
{
my $status = ReadingsVal("DOIF_Ladestation", "status", "");;
my $new_value = ($status eq "langsam") ? 6 : 16;;
fhem("set Wallbe Ladestrom_Vorgabe $new_value");;
fhem("set Wallbe Lade_Freigabe Ein");;
fhem("setreading DOIF_Ladestation Ampere_errechnet $new_value");;
}
DOELSEIF
(
(
([SUN2000_10KTL:Netz_Bezug_Einspeisung] + 0) < 50
and ([Wallbe:Ladestrom_Vorgabe] + 0) == 6
and [$SELF:status] eq "PV"
and [Wallbe:Device_status] eq "Fahrzeug lädt"
and [SUN2000_10KTL:state] eq "opened"
)
or
(
([SUN2000_10KTL:PV-Erzeugung_aktuell] + 0) < 4140
and [$SELF:status] eq "PV"
and [Wallbe:Device_status] eq "Ladekabel angeschlossen"
and [SUN2000_10KTL:state] eq "opened"
)
or
[$SELF:status] eq "aus"
or
[Wallbe:Device_status] eq "Ladestation frei"
or
(
[SUN2000_10KTL:state] ne "opened"
and [$SELF:status] eq "PV"
)
)
{
fhem("set Wallbe Ladestrom_Vorgabe 6");;
fhem("set Wallbe Lade_Freigabe Aus");;
fhem("setreading DOIF_Ladestation Ampere_errechnet 6");;
}
Ja, habe ich - aber nicht mit diesem Modul. Insofern vlt. hier https://forum.fhem.de/index.php?board=106.0 einen neuen Thread aufmachen und erst einmal Ideen sammeln.
LG
pah
Hallo Heiko,
heute habe ich bemerkt, dass die Vorhersage bei consumption für den heutigen und morgigen Tag grob achtmal so hoch ist, wie es sich in der Realität darstellt.
Hier ein list meines Devices:
define mySolarForecast SolarForecast
attr mySolarForecast ctrlBackupFilesKeep 7
attr mySolarForecast ctrlGenPVdeviation daily
attr mySolarForecast ctrlInterval 8
attr mySolarForecast event-on-change-reading .*
attr mySolarForecast flowGraphicAnimate 1
attr mySolarForecast flowGraphicShift -60
attr mySolarForecast flowGraphicShowConsumerDummy 0
attr mySolarForecast flowGraphicShowConsumerPower 1
attr mySolarForecast flowGraphicSize 400
attr mySolarForecast graphicBeam1Color A9A9A9
attr mySolarForecast graphicBeam2Color BEBEBE
attr mySolarForecast graphicBeamWidth 60
attr mySolarForecast graphicEnergyUnit kWh
attr mySolarForecast graphicHeaderShow 1
attr mySolarForecast graphicHistoryHour 4
attr mySolarForecast graphicHourCount 18
attr mySolarForecast graphicShowDiff top
attr mySolarForecast graphicShowWeather 1
attr mySolarForecast graphicSpaceSize 16
attr mySolarForecast graphicWeatherColor 62AFCD
attr mySolarForecast room DEYE
attr mySolarForecast setupBatteryDev Deye_Inverter pin=-pout pout=battery_output_power:W intotal=total_charge_of_the_battery:kWh outtotal=total_discharge_of_the_battery:kWh cap=16179.2 charge=SOC_jkbms
attr mySolarForecast setupInverterDev Deye_Inverter pv=Deye_Growatt_power:W etotal=total_pv_production:kWh capacity=15200
attr mySolarForecast setupInverterStrings Sueddach,Garage
attr mySolarForecast setupMeterDev Deye_Inverter gcon=total_grid_power:W contotal=total_energy_bought:kWh gfeedin=-gcon feedtotal=total_energy_sold:kWh
attr mySolarForecast setupRadiationAPI OpenMeteoDWDEnsemble-API
attr mySolarForecast setupStringPeak Sueddach=12.71 Garage=2.46
attr mySolarForecast setupWeatherDev1 OpenMeteoDWDEnsemble-API
attr mySolarForecast userReadings ForecastNoonBatt:Today_Hour11_PVforecast.* {round(ReadingsNum($name,'Today_Hour11_PVforecast','')+ReadingsNum($name,'Today_Hour12_PVforecast','')+ReadingsNum($name,'Today_Hour13_PVforecast','')+ReadingsNum($name,'Today_Hour14_PVforecast','')+ReadingsNum($name,'Today_Hour15_PVforecast','')-316*51.2*(1-ReadingsNum($name,'Current_BatCharge','')/100),0)}
attr mySolarForecast verbose 2
attr mySolarForecast widgetOverride flowGraphicShift:select,-70,-65,-60,-55,-50
# CFGFN ./FHEM/Photovoltaik.cfg
# FUUID 66a609f9-f33f-e986-a5c4-ea9c9b242f9ee2a8
# FVERSION 76_SolarForecast.pm:v1.31.0-s29089/2024-08-20
# LCACHEFILE last write time: 09:07:59 whole Operating Memory
# MODE Automatic - next Cycletime: 09:17:47
# MODEL OpenMeteoDWDEnsembleAPI
# NAME mySolarForecast
# NR 1547
# NTFY_ORDER 50-mySolarForecast
# STATE updated
# TYPE SolarForecast
# eventCount 115919
# HELPER:
# FW WEBtablet
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV mySolarForecast
# SPGROOM
# VERSION 1.31.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.2
# OLDREADINGS:
# READINGS:
# 2024-09-19 09:17:39 Current_AutarkyRate 100 %
# 2024-09-19 09:17:39 Current_BatCharge 71 %
# 2024-09-19 09:17:39 Current_Consumption 463 W
# 2024-09-19 09:17:39 Current_GridConsumption 0 W
# 2024-09-19 09:17:39 Current_GridFeedIn 3321 W
# 2024-09-19 09:17:39 Current_PV 3826 W
# 2024-09-19 09:17:39 Current_PowerBatIn 42 W
# 2024-09-19 09:17:39 Current_PowerBatOut 0 W
# 2024-09-19 09:17:39 Current_SelfConsumption 463 W
# 2024-09-19 09:17:39 Current_SelfConsumptionRate 12 %
# 2024-09-19 09:17:39 Current_Surplus 3363 W
# 2024-09-19 05:35:47 ForecastNoonBatt 40715.2
# 2024-09-19 09:00:00 LastHourGridconsumptionReal 0 Wh
# 2024-09-19 09:00:00 LastHourPVforecast 1498 Wh
# 2024-09-19 09:00:00 LastHourPVreal 900 Wh
# 2024-09-19 09:17:39 NextHours_Sum01_PVforecast 4713 Wh
# 2024-09-19 09:17:39 NextHours_Sum02_PVforecast 12243 Wh
# 2024-09-19 09:17:39 NextHours_Sum03_PVforecast 22323 Wh
# 2024-09-19 09:17:39 NextHours_Sum04_ConsumptionForecast 5971 Wh
# 2024-09-19 09:17:39 NextHours_Sum04_PVforecast 32530 Wh
# 2024-09-19 09:17:39 RestOfDayConsumptionForecast 111577 Wh
# 2024-09-19 09:17:39 RestOfDayPVforecast 63159 Wh
# 2024-09-19 00:59:56 Today_Hour01_BatIn 0 Wh
# 2024-09-19 00:59:56 Today_Hour01_BatOut 500 Wh
# 2024-09-19 00:59:56 Today_Hour01_GridConsumption 0 Wh
# 2024-09-19 00:59:56 Today_Hour01_GridFeedIn 0 Wh
# 2024-09-19 00:59:56 Today_Hour01_PVreal 0 Wh
# 2024-09-19 01:59:56 Today_Hour02_BatIn 0 Wh
# 2024-09-19 01:59:56 Today_Hour02_BatOut 300 Wh
# 2024-09-19 01:59:56 Today_Hour02_GridConsumption 0 Wh
# 2024-09-19 01:59:56 Today_Hour02_GridFeedIn 0 Wh
# 2024-09-19 01:59:56 Today_Hour02_PVreal 0 Wh
# 2024-09-19 02:59:58 Today_Hour03_BatIn 0 Wh
# 2024-09-19 02:59:58 Today_Hour03_BatOut 299 Wh
# 2024-09-19 02:59:58 Today_Hour03_GridConsumption 0 Wh
# 2024-09-19 02:59:58 Today_Hour03_GridFeedIn 0 Wh
# 2024-09-19 02:59:58 Today_Hour03_PVreal 0 Wh
# 2024-09-19 03:59:54 Today_Hour04_BatIn 0 Wh
# 2024-09-19 03:59:54 Today_Hour04_BatOut 400 Wh
# 2024-09-19 03:59:54 Today_Hour04_GridConsumption 0 Wh
# 2024-09-19 03:59:54 Today_Hour04_GridFeedIn 0 Wh
# 2024-09-19 03:59:54 Today_Hour04_PVreal 0 Wh
# 2024-09-19 04:59:58 Today_Hour05_BatIn 0 Wh
# 2024-09-19 04:59:58 Today_Hour05_BatOut 300 Wh
# 2024-09-19 04:59:58 Today_Hour05_GridConsumption 0 Wh
# 2024-09-19 04:59:58 Today_Hour05_GridFeedIn 0 Wh
# 2024-09-19 04:59:58 Today_Hour05_PVreal 0 Wh
# 2024-09-19 05:59:56 Today_Hour06_BatIn 0 Wh
# 2024-09-19 05:59:56 Today_Hour06_BatOut 299 Wh
# 2024-09-19 05:59:56 Today_Hour06_GridConsumption 100 Wh
# 2024-09-19 05:59:56 Today_Hour06_GridFeedIn 0 Wh
# 2024-09-19 05:59:56 Today_Hour06_PVreal 0 Wh
# 2024-09-19 06:59:58 Today_Hour07_BatIn 0 Wh
# 2024-09-19 06:59:58 Today_Hour07_BatOut 300 Wh
# 2024-09-19 06:59:58 Today_Hour07_GridConsumption 0 Wh
# 2024-09-19 06:59:58 Today_Hour07_GridFeedIn 0 Wh
# 2024-09-19 06:59:58 Today_Hour07_PVreal 0 Wh
# 2024-09-19 07:59:54 Today_Hour08_BatIn 0 Wh
# 2024-09-19 07:59:54 Today_Hour08_BatOut 400 Wh
# 2024-09-19 07:59:54 Today_Hour08_GridConsumption 0 Wh
# 2024-09-19 07:59:54 Today_Hour08_GridFeedIn 0 Wh
# 2024-09-19 07:59:54 Today_Hour08_PVforecast 178 Wh
# 2024-09-19 07:59:54 Today_Hour08_PVreal 100 Wh
# 2024-09-19 08:59:52 Today_Hour09_BatIn 0 Wh
# 2024-09-19 08:59:52 Today_Hour09_BatOut 0 Wh
# 2024-09-19 08:59:52 Today_Hour09_GridConsumption 0 Wh
# 2024-09-19 08:59:52 Today_Hour09_GridFeedIn 400 Wh
# 2024-09-19 08:59:52 Today_Hour09_PVforecast 1498 Wh
# 2024-09-19 08:59:52 Today_Hour09_PVreal 900 Wh
# 2024-09-19 09:17:39 Today_Hour10_BatIn 0 Wh
# 2024-09-19 09:17:39 Today_Hour10_BatOut 0 Wh
# 2024-09-19 09:17:39 Today_Hour10_GridConsumption 0 Wh
# 2024-09-19 09:17:39 Today_Hour10_GridFeedIn 600 Wh
# 2024-09-19 09:17:39 Today_Hour10_PVforecast 3942 Wh
# 2024-09-19 09:17:39 Today_Hour10_PVreal 400 Wh
# 2024-09-19 09:17:39 Today_Hour11_PVforecast 6514 Wh
# 2024-09-19 09:17:39 Today_Hour12_PVforecast 9900 Wh
# 2024-09-19 09:17:39 Today_Hour13_PVforecast 10500 Wh
# 2024-09-19 09:17:39 Today_Hour14_PVforecast 9522 Wh
# 2024-09-19 09:17:39 Today_Hour15_PVforecast 8324 Wh
# 2024-09-19 09:17:39 Today_Hour16_PVforecast 6309 Wh
# 2024-09-19 09:17:39 Today_Hour17_PVforecast 4932 Wh
# 2024-09-19 09:17:39 Today_Hour18_PVforecast 3182 Wh
# 2024-09-19 09:17:39 Today_Hour19_PVforecast 1097 Wh
# 2024-09-19 09:17:39 Today_Hour20_PVforecast 120 Wh
# 2024-09-19 09:17:39 Today_MaxPVforecast 10500 Wh
# 2024-09-19 09:17:39 Today_MaxPVforecastTime 2024-09-19 12:00:00
# 2024-09-19 09:17:39 Today_PVforecast 66018 Wh
# 2024-09-19 09:17:39 Today_PVreal 1400 Wh
# 2024-09-19 09:17:39 Today_SunRise 07:14
# 2024-09-19 09:17:39 Today_SunSet 19:34
# 2024-09-19 09:17:39 Tomorrow_ConsumptionForecast 116053 Wh
# 2024-09-19 09:17:39 Tomorrow_PVforecast 73848 Wh
# 2024-09-19 09:17:39 Tomorrow_SunRise 07:16
# 2024-09-19 09:17:39 Tomorrow_SunSet 19:32
# 2024-09-19 09:17:39 nextCycletime 09:17:47
# 2024-09-19 09:06:59 nextRadiationAPICall after 2024-09-19 09:21:59
# 2024-09-19 08:00:02 pvCorrectionFactor_08 0.45 (automatic - old factor: 0.69, Sun Alt range: 0, Cloud range: 00, Days in range: 2)
# 2024-09-19 08:00:02 pvCorrectionFactor_08_autocalc done
# 2024-09-19 09:00:00 pvCorrectionFactor_09 0.49 (automatic - old factor: 0.70, Sun Alt range: 10, Cloud range: 00, Days in range: 2)
# 2024-09-19 09:00:00 pvCorrectionFactor_09_autocalc done
# 2024-09-19 09:17:39 pvCorrectionFactor_Auto on_complex_ai
# 2024-09-12 14:54:45 setupStringAzimuth Sueddach=-1 Garage=-91
# 2024-09-12 14:52:20 setupStringDeclination Sueddach=40 Garage=15
# 2024-09-19 09:17:40 state updated
# helper:
# bm:
# CODE(0x557d072ba660):
# cnt 13003
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 14.09. 15:29:28
# max 0.442568063735962
# tot 84.699033498764
# mAr:
# HASH(0x557d06e04450)
# mySolarForecast
# ?
# CODE(0x557d07349d20):
# cnt 14
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 17.09. 11:30:29
# max 1.99131202697754
# tot 2.00466203689575
# mAr:
# HASH(0x557d06e04450)
# mySolarForecast
# ?
# CODE(0x557d0750c838):
# cnt 3
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 17.09. 11:31:48
# max 3.59624719619751
# tot 3.59643125534058
# mAr:
# set
# mySolarForecast
# userReadings
# ForecastNoonBatt:Today_Hour11_PVforecast.* {sprintf(ReadingsNum($name,'Today_Hour11_PVforecast','')+ReadingsNum($name,'Today_Hour12_PVforecast','')+ReadingsNum($name,'Today_Hour13_PVforecast','')+ReadingsNum($name,'Today_Hour14_PVforecast','')+ReadingsNum($name,'Today_Hour15_PVforecast','')-316*51.2*(1-ReadingsNum($name,'Current_BatCharge','')/100),0)}
# CODE(0x557d0757c6c0):
# cnt 1128237
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 18.09. 23:04:25
# max 0.0250301361083984
# tot 45.1848382949829
# mAr:
# HASH(0x557d06e04450)
# HASH(0x557d04fa2eb8)
# CODE(0x557d075d1948):
# cnt 9999571
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 14.09. 14:11:09
# max 0.889696836471558
# tot 6499.6051838398
# mAr:
# HASH(0x557d06e04450)
#
setstate mySolarForecast updated
setstate mySolarForecast 2024-09-14 03:11:31 .associatedWith Deye_Inverter
setstate mySolarForecast 2024-09-19 09:17:39 .lastupdateForecastValues 1726730259
setstate mySolarForecast 2024-09-19 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate mySolarForecast 2024-09-19 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate mySolarForecast 2024-09-19 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate mySolarForecast 2024-09-19 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate mySolarForecast 2024-09-19 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate mySolarForecast 2024-09-19 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate mySolarForecast 2024-09-19 04:00:02 .pvCorrectionFactor_04_apipercentil done
setstate mySolarForecast 2024-09-19 04:00:02 .pvCorrectionFactor_04_cloudcover done
setstate mySolarForecast 2024-09-19 05:00:04 .pvCorrectionFactor_05_apipercentil done
setstate mySolarForecast 2024-09-19 05:00:04 .pvCorrectionFactor_05_cloudcover done
setstate mySolarForecast 2024-09-19 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate mySolarForecast 2024-09-19 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate mySolarForecast 2024-09-19 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate mySolarForecast 2024-09-19 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate mySolarForecast 2024-09-19 08:00:02 .pvCorrectionFactor_08_apipercentil done
setstate mySolarForecast 2024-09-19 08:00:02 .pvCorrectionFactor_08_cloudcover done
setstate mySolarForecast 2024-09-19 09:00:00 .pvCorrectionFactor_09_apipercentil done
setstate mySolarForecast 2024-09-19 09:00:00 .pvCorrectionFactor_09_cloudcover done
setstate mySolarForecast 2024-09-19 09:17:39 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate mySolarForecast 2024-09-19 01:00:04 .signaldone_01 done
setstate mySolarForecast 2024-09-19 02:00:04 .signaldone_02 done
setstate mySolarForecast 2024-09-19 03:00:04 .signaldone_03 done
setstate mySolarForecast 2024-09-19 04:00:02 .signaldone_04 done
setstate mySolarForecast 2024-09-19 05:00:04 .signaldone_05 done
setstate mySolarForecast 2024-09-19 06:00:04 .signaldone_06 done
setstate mySolarForecast 2024-09-19 07:00:04 .signaldone_07 done
setstate mySolarForecast 2024-09-19 08:00:02 .signaldone_08 done
setstate mySolarForecast 2024-09-19 09:00:00 .signaldone_09 done
setstate mySolarForecast 2024-09-19 09:17:39 Current_AutarkyRate 100 %
setstate mySolarForecast 2024-09-19 09:17:39 Current_BatCharge 71 %
setstate mySolarForecast 2024-09-19 09:17:39 Current_Consumption 463 W
setstate mySolarForecast 2024-09-19 09:17:39 Current_GridConsumption 0 W
setstate mySolarForecast 2024-09-19 09:17:39 Current_GridFeedIn 3321 W
setstate mySolarForecast 2024-09-19 09:17:39 Current_PV 3826 W
setstate mySolarForecast 2024-09-19 09:17:39 Current_PowerBatIn 42 W
setstate mySolarForecast 2024-09-19 09:17:39 Current_PowerBatOut 0 W
setstate mySolarForecast 2024-09-19 09:17:39 Current_SelfConsumption 463 W
setstate mySolarForecast 2024-09-19 09:17:39 Current_SelfConsumptionRate 12 %
setstate mySolarForecast 2024-09-19 09:17:39 Current_Surplus 3363 W
setstate mySolarForecast 2024-09-19 05:35:47 ForecastNoonBatt 40715.2
setstate mySolarForecast 2024-09-19 09:00:00 LastHourGridconsumptionReal 0 Wh
setstate mySolarForecast 2024-09-19 09:00:00 LastHourPVforecast 1498 Wh
setstate mySolarForecast 2024-09-19 09:00:00 LastHourPVreal 900 Wh
setstate mySolarForecast 2024-09-19 09:17:39 NextHours_Sum01_PVforecast 4713 Wh
setstate mySolarForecast 2024-09-19 09:17:39 NextHours_Sum02_PVforecast 12243 Wh
setstate mySolarForecast 2024-09-19 09:17:39 NextHours_Sum03_PVforecast 22323 Wh
setstate mySolarForecast 2024-09-19 09:17:39 NextHours_Sum04_ConsumptionForecast 5971 Wh
setstate mySolarForecast 2024-09-19 09:17:39 NextHours_Sum04_PVforecast 32530 Wh
setstate mySolarForecast 2024-09-19 09:17:39 RestOfDayConsumptionForecast 111577 Wh
setstate mySolarForecast 2024-09-19 09:17:39 RestOfDayPVforecast 63159 Wh
setstate mySolarForecast 2024-09-19 00:59:56 Today_Hour01_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 00:59:56 Today_Hour01_BatOut 500 Wh
setstate mySolarForecast 2024-09-19 00:59:56 Today_Hour01_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 00:59:56 Today_Hour01_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 00:59:56 Today_Hour01_PVreal 0 Wh
setstate mySolarForecast 2024-09-19 01:59:56 Today_Hour02_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 01:59:56 Today_Hour02_BatOut 300 Wh
setstate mySolarForecast 2024-09-19 01:59:56 Today_Hour02_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 01:59:56 Today_Hour02_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 01:59:56 Today_Hour02_PVreal 0 Wh
setstate mySolarForecast 2024-09-19 02:59:58 Today_Hour03_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 02:59:58 Today_Hour03_BatOut 299 Wh
setstate mySolarForecast 2024-09-19 02:59:58 Today_Hour03_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 02:59:58 Today_Hour03_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 02:59:58 Today_Hour03_PVreal 0 Wh
setstate mySolarForecast 2024-09-19 03:59:54 Today_Hour04_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 03:59:54 Today_Hour04_BatOut 400 Wh
setstate mySolarForecast 2024-09-19 03:59:54 Today_Hour04_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 03:59:54 Today_Hour04_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 03:59:54 Today_Hour04_PVreal 0 Wh
setstate mySolarForecast 2024-09-19 04:59:58 Today_Hour05_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 04:59:58 Today_Hour05_BatOut 300 Wh
setstate mySolarForecast 2024-09-19 04:59:58 Today_Hour05_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 04:59:58 Today_Hour05_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 04:59:58 Today_Hour05_PVreal 0 Wh
setstate mySolarForecast 2024-09-19 05:59:56 Today_Hour06_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 05:59:56 Today_Hour06_BatOut 299 Wh
setstate mySolarForecast 2024-09-19 05:59:56 Today_Hour06_GridConsumption 100 Wh
setstate mySolarForecast 2024-09-19 05:59:56 Today_Hour06_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 05:59:56 Today_Hour06_PVreal 0 Wh
setstate mySolarForecast 2024-09-19 06:59:58 Today_Hour07_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 06:59:58 Today_Hour07_BatOut 300 Wh
setstate mySolarForecast 2024-09-19 06:59:58 Today_Hour07_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 06:59:58 Today_Hour07_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 06:59:58 Today_Hour07_PVreal 0 Wh
setstate mySolarForecast 2024-09-19 07:59:54 Today_Hour08_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 07:59:54 Today_Hour08_BatOut 400 Wh
setstate mySolarForecast 2024-09-19 07:59:54 Today_Hour08_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 07:59:54 Today_Hour08_GridFeedIn 0 Wh
setstate mySolarForecast 2024-09-19 07:59:54 Today_Hour08_PVforecast 178 Wh
setstate mySolarForecast 2024-09-19 07:59:54 Today_Hour08_PVreal 100 Wh
setstate mySolarForecast 2024-09-19 08:59:52 Today_Hour09_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 08:59:52 Today_Hour09_BatOut 0 Wh
setstate mySolarForecast 2024-09-19 08:59:52 Today_Hour09_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 08:59:52 Today_Hour09_GridFeedIn 400 Wh
setstate mySolarForecast 2024-09-19 08:59:52 Today_Hour09_PVforecast 1498 Wh
setstate mySolarForecast 2024-09-19 08:59:52 Today_Hour09_PVreal 900 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour10_BatIn 0 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour10_BatOut 0 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour10_GridConsumption 0 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour10_GridFeedIn 600 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour10_PVforecast 3942 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour10_PVreal 400 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour11_PVforecast 6514 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour12_PVforecast 9900 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour13_PVforecast 10500 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour14_PVforecast 9522 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour15_PVforecast 8324 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour16_PVforecast 6309 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour17_PVforecast 4932 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour18_PVforecast 3182 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour19_PVforecast 1097 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_Hour20_PVforecast 120 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_MaxPVforecast 10500 Wh
setstate mySolarForecast 2024-09-19 09:17:39 Today_MaxPVforecastTime 2024-09-19 12:00:0
Viele Grüße Gisbert
Hallo Gisbert,
dann wurde in der pvHistory ein hoher Verbrauchswert gespeichert der sich auf die Vorhersage auswirkt.
Man sieht wahrscheinlich die entsprechenden Infos im Log wenn du ctrlDebug=consumption setzt.
Grüße,
Heiko
Zitat von: DS_Starter am 19 September 2024, 22:35:15dann wurde in der pvHistory ein hoher Verbrauchswert gespeichert der sich auf die Vorhersage auswirkt.
Man sieht wahrscheinlich die entsprechenden Infos im Log wenn du ctrlDebug=consumption setzt.
Grüße,
Heiko
Hallo Heiko,
im Log steht tatsächlich für 14:00 ein Wert von sagenhaften 100 kWh (ca.). Wo der nur herkommen mag.
Ich hab ein reset bei consumption gemacht und werde das die nächsten Tage beobachten.
Viele Grüße Gisbert
ZitatWo der nur herkommen mag.
Sofern der Verursacher ein registrierter Verbraucher ist, sieht man den Anteil des Verbauchers im Schlüssel csmeXX. Dabei ist XX die Verbrauchernummer (im Beispiel Verbaicher 04 mit 91.5 Wh).
09 => etotal: 64654950, pvfc: 1423, pvrl: 1650, pvrlvd: 1, rad1h: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 774, con: 616, gcons: 25, conprice: 0.2958
gfeedin: 4, feedprice: 0.1269
DoN: 1, sunaz: 106, sunalt: 14
batintotal: 3171233.88656146, batouttotal: 3068851.36809829, batin: 1055, batout: 0
wid: 1, wcc: 27, rr1c: 0.00, pvcorrf: 0.85/0.82temp: 11.70,
csmt01: 71875.83, csme01: 24.0800000000017, minutescsm01: 23
minutescsm02: 0
csmt03: 3995.47, csme03: 0, minutescsm03: 0
csmt04: 1419438.3, csme04: 91.5, minutescsm04: 60
csmt05: 499.62, csme05: 0, minutescsm05: 0
csmt06: 153.9, csme06: 0, minutescsm06: 0
csmt07: 40.28, csme07: 0, minutescsm07: 0
csmt08: 33620, csme08: 0, minutescsm08: 60
csmt09: 108576, csme09: 0, minutescsm09: 0
minutescsm10: 0
Gibt es keine gespeciherten Werte in den csme-Schlüssel, kommt der hohe Wert von einem nicht registrierten Verbraucher bzw. einem Input-Fehler, d.h. einem fehlerhaft gelieferten Wert des Meters beispielsweise.
Man kann den Verbrauch von dem betroffenen Tag/der Stunde selektiv löschen:
set <name> reset consumption <Tag> <Stunde>LG
Ich verstehs nicht so ganz. Nutze das Modul schon länger, und bin sehr zufrieden.
In den letzten Wochen hatte ich einige Probleme mit dauernden Serverneustarts, und habe die Kommunikation zu meinem Batteriewechselrichter umgestellt.
Jetzt sollten alle Eingangswerte für Solcast wieder passen. Trotzdem ist der Vorhergesagte Verbrauch mind. Faktor 10 zu hoch.
Wo kann ich nach dem Fehler suchen?
define solcast SolarForecast
attr solcast DbLogExclude .*
attr solcast DbLogInclude Current_.*
attr solcast affect70percentRule 0
attr solcast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr solcast consumer01 Stromverbrauch_Zaehler2 type=heater power=2100 icon=sani_floor_heating pcurr=P_act_tot-get:kW etotal=total-get:kWh
attr solcast consumer02 Shelly_Waschmaschine type=washingmachine power=3000 mintime=60 pcurr=power:W etotal=energykwh:kWh icon=scene_washing_machine
attr solcast consumer03 Shelly_Trockner type=dryer power=3000 mintime=60 pcurr=power:W etotal=energykwh:kWh icon=scene_laundry_room
attr solcast consumer04 HTTPMOD_Wallbox type=charger power=0 pcurr=devices_01_power_w:W etotal=devices_01_total_energy:kWh icon=car_in
attr solcast consumerLegend icon_bottom
attr solcast ctrlNextDayForecastReadings 12,13
attr solcast event-on-change-reading .*
attr solcast flowGraphicAnimate 1
attr solcast flowGraphicSize 600
attr solcast graphicBeam1Color 38DE4D
attr solcast graphicBeam1Content pvForecast
attr solcast graphicBeam1FontColor 000000
attr solcast graphicBeam2Color FF8E2B
attr solcast graphicBeam2Content pvReal
attr solcast graphicBeam2FontColor 000000
attr solcast graphicHourCount 30
attr solcast graphicLayoutType double
attr solcast graphicWeatherColor FFC933
attr solcast room Technik_PV
attr solcast setupBatteryDev BatterieWR pin=BatteryPowerBMS2:kW pout=-pin intotal=BatteryChargeTotal:kWh outtotal=BatteryDischargeTotal:kWh charge=BatteryCapacity
attr solcast setupInverterDev Stromverbrauch_Zaehler11 pv=P_act-get:kW etotal=total-get:kWh
attr solcast setupInverterStrings Hausdach,Hausdach2,GartenhausSued,GartenhausNord
attr solcast setupMeterDev Stromverbrauch_Zaehler1_EHZ gcon=aktuellerverbrauch-get:kW contotal=total-get:kWh gfeedin=-gcon feedtotal=ueberschuss-total-get:kWh conprice=0.3:€ feedprice =0.08:€
attr solcast setupRadiationAPI DWD_Forecast
attr solcast setupStringPeak Hausdach=4.86 Hausdach2=2.49 GartenhausSued=0.6 GartenhausNord=0.6
attr solcast setupWeatherDev1 DWD_Forecast
# FUUID 62487147-f33f-ae17-74c6-e655d31e5ac447b7
# FVERSION 76_SolarForecast.pm:v1.31.0-s29089/2024-08-20
# LCACHEFILE last write time: 07:45:13 File: ./FHEM/FhemUtils/PVCsm_SolarForecast_solcast
# MODE Automatic - next Cycletime: 07:51:03
# MODEL DWD
# NAME solcast
# NOTIFYDEV Stromverbrauch_Zaehler2,Shelly_Waschmaschine,Shelly_Trockner,HTTPMOD_Wallbox
# NR 394
# NTFY_ORDER 50-solcast
# STATE updated
# TYPE SolarForecast
# eventCount 3959
# HELPER:
# 01M15DONE 1
# 01M45DONE 1
# 02M15DONE 1
# 02M45DONE 1
# 03M15DONE 1
# 03M45DONE 1
# 04M15DONE 1
# 04M45DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV solcast
# SPGROOM
# VERSION 1.31.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.2
# Helper:
# DBLOG:
# Current_AutarkyRate:
# logdb:
# TIME 1726897793.03712
# VALUE 69
# Current_BatCharge:
# logdb:
# TIME 1726896883.03814
# VALUE 22
# Current_Consumption:
# logdb:
# TIME 1726897793.03712
# VALUE 140
# Current_GridConsumption:
# logdb:
# TIME 1726897793.03712
# VALUE 43
# Current_GridFeedIn:
# logdb:
# TIME 1726897793.03712
# VALUE 0
# Current_PV:
# logdb:
# TIME 1726897793.03712
# VALUE 132
# Current_PowerBatIn:
# logdb:
# TIME 1726897793.03712
# VALUE 35
# Current_PowerBatOut:
# logdb:
# TIME 1726897722.22224
# VALUE 0
# Current_SelfConsumption:
# logdb:
# TIME 1726897793.03712
# VALUE 97
# Current_SelfConsumptionRate:
# logdb:
# TIME 1726897793.03712
# VALUE 73
# Current_Surplus:
# logdb:
# TIME 1726897793.03712
# VALUE 0
# OLDREADINGS:
# READINGS:
# 2024-09-21 07:49:53 Current_AutarkyRate 69 %
# 2024-09-21 07:49:53 Current_BatCharge 22 %
# 2024-09-21 07:49:53 Current_Consumption 140 W
# 2024-09-21 07:49:53 Current_GridConsumption 43 W
# 2024-09-21 07:49:53 Current_GridFeedIn 0 W
# 2024-09-21 07:49:53 Current_PV 132 W
# 2024-09-21 07:49:53 Current_PowerBatIn 35 W
# 2024-09-21 07:49:53 Current_PowerBatOut 0 W
# 2024-09-21 07:49:53 Current_SelfConsumption 97 W
# 2024-09-21 07:49:53 Current_SelfConsumptionRate 73 %
# 2024-09-21 07:49:53 Current_Surplus 0 W
# 2024-09-21 07:00:00 LastHourGridconsumptionReal 500 Wh
# 2024-09-21 07:00:00 LastHourPVforecast 0 Wh
# 2024-09-21 07:00:00 LastHourPVreal 0 Wh
# 2024-09-21 07:49:53 NextHours_Sum01_PVforecast 879 Wh
# 2024-09-21 07:49:53 NextHours_Sum02_PVforecast 2892 Wh
# 2024-09-21 07:49:53 NextHours_Sum03_PVforecast 6157 Wh
# 2024-09-21 07:49:53 NextHours_Sum04_ConsumptionForecast 2599 Wh
# 2024-09-21 07:49:53 NextHours_Sum04_PVforecast 10295 Wh
# 2024-09-21 07:49:53 RestOfDayConsumptionForecast 368190 Wh
# 2024-09-21 07:49:53 RestOfDayPVforecast 36738 Wh
# 2024-09-21 00:59:50 Today_Hour01_BatIn 0 Wh
# 2024-09-21 00:59:50 Today_Hour01_BatOut 0 Wh
# 2024-09-21 00:59:50 Today_Hour01_GridConsumption 0 Wh
# 2024-09-21 00:59:50 Today_Hour01_GridFeedIn 0 Wh
# 2024-09-21 00:59:50 Today_Hour01_PVreal 0 Wh
# 2024-09-21 01:59:52 Today_Hour02_BatIn 0 Wh
# 2024-09-21 01:59:52 Today_Hour02_BatOut 1700 Wh
# 2024-09-21 01:59:52 Today_Hour02_GridConsumption 0 Wh
# 2024-09-21 01:59:52 Today_Hour02_GridFeedIn 0 Wh
# 2024-09-21 01:59:52 Today_Hour02_PVreal 900 Wh
# 2024-09-21 02:59:49 Today_Hour03_BatIn 0 Wh
# 2024-09-21 02:59:49 Today_Hour03_BatOut 300 Wh
# 2024-09-21 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2024-09-21 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-09-21 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-09-21 03:59:50 Today_Hour04_BatIn 0 Wh
# 2024-09-21 03:59:50 Today_Hour04_BatOut 300 Wh
# 2024-09-21 03:59:50 Today_Hour04_GridConsumption 0 Wh
# 2024-09-21 03:59:50 Today_Hour04_GridFeedIn 0 Wh
# 2024-09-21 03:59:50 Today_Hour04_PVreal 0 Wh
# 2024-09-21 04:59:50 Today_Hour05_BatIn 0 Wh
# 2024-09-21 04:59:50 Today_Hour05_BatOut 900 Wh
# 2024-09-21 04:59:50 Today_Hour05_GridConsumption 0 Wh
# 2024-09-21 04:59:50 Today_Hour05_GridFeedIn 0 Wh
# 2024-09-21 04:59:50 Today_Hour05_PVreal 0 Wh
# 2024-09-21 05:59:49 Today_Hour06_BatIn 0 Wh
# 2024-09-21 05:59:49 Today_Hour06_BatOut 300 Wh
# 2024-09-21 05:59:49 Today_Hour06_GridConsumption 0 Wh
# 2024-09-21 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2024-09-21 05:59:49 Today_Hour06_PVreal 0 Wh
# 2024-09-21 06:59:49 Today_Hour07_BatIn 0 Wh
# 2024-09-21 06:59:49 Today_Hour07_BatOut 400 Wh
# 2024-09-21 06:59:49 Today_Hour07_GridConsumption 500 Wh
# 2024-09-21 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2024-09-21 06:59:49 Today_Hour07_PVreal 0 Wh
# 2024-09-21 07:49:53 Today_Hour08_BatIn 0 Wh
# 2024-09-21 07:49:53 Today_Hour08_BatOut 200 Wh
# 2024-09-21 07:49:53 Today_Hour08_GridConsumption 0 Wh
# 2024-09-21 07:49:53 Today_Hour08_GridFeedIn 0 Wh
# 2024-09-21 07:49:53 Today_Hour08_PVforecast 203 Wh
# 2024-09-21 07:49:53 Today_Hour08_PVreal 130 Wh
# 2024-09-21 07:49:53 Today_Hour09_PVforecast 1015 Wh
# 2024-09-21 07:49:53 Today_Hour10_PVforecast 2212 Wh
# 2024-09-21 07:49:53 Today_Hour11_PVforecast 3476 Wh
# 2024-09-21 07:49:53 Today_Hour12_PVforecast 4270 Wh
# 2024-09-21 07:49:53 Today_Hour13_PVforecast 5101 Wh
# 2024-09-21 07:49:53 Today_Hour14_PVforecast 5350 Wh
# 2024-09-21 07:49:53 Today_Hour15_PVforecast 5079 Wh
# 2024-09-21 07:49:53 Today_Hour16_PVforecast 4311 Wh
# 2024-09-21 07:49:53 Today_Hour17_PVforecast 3228 Wh
# 2024-09-21 07:49:53 Today_Hour18_PVforecast 1941 Wh
# 2024-09-21 07:49:53 Today_Hour19_PVforecast 677 Wh
# 2024-09-21 07:49:53 Today_Hour20_PVforecast 45 Wh
# 2024-09-21 07:49:53 Today_MaxPVforecast 5350 Wh
# 2024-09-21 07:49:53 Today_MaxPVforecastTime 2024-09-21 13:00:00
# 2024-09-21 07:49:53 Today_PVforecast 36908 Wh
# 2024-09-21 07:49:53 Today_PVreal 1030 Wh
# 2024-09-21 07:49:53 Today_SunRise 07:00
# 2024-09-21 07:49:53 Today_SunSet 19:13
# 2024-09-21 07:49:53 Tomorrow_ConsumptionForecast 314582 Wh
# 2024-09-21 07:49:53 Tomorrow_Hour12_PVforecast 4515 Wh
# 2024-09-21 07:49:53 Tomorrow_Hour13_PVforecast 5124 Wh
# 2024-09-21 07:49:53 Tomorrow_PVforecast 36026 Wh
# 2024-09-21 07:49:53 Tomorrow_SunRise 07:02
# 2024-09-21 07:49:53 Tomorrow_SunSet 19:10
# 2024-09-21 07:49:53 consumer01 name='Stromverbrauch_Zaehler2' state='unknown' mode='can' planningstate='planned'
# 2024-09-21 07:49:53 consumer01_currentPower 7 W
# 2024-09-21 07:49:53 consumer01_planned_start 21.09.2024 09:00:00
# 2024-09-21 07:49:53 consumer01_planned_stop 21.09.2024 13:00:00
# 2024-09-21 07:49:53 consumer02 name='Shelly_Waschmaschine' state='on' mode='can' planningstate='planned'
# 2024-09-21 07:49:53 consumer02_currentPower 0 W
# 2024-09-21 07:49:53 consumer02_planned_start 21.09.2024 09:00:00
# 2024-09-21 07:49:53 consumer02_planned_stop 21.09.2024 10:00:00
# 2024-09-21 07:49:53 consumer03 name='Shelly_Trockner' state='on' mode='can' planningstate='planned'
# 2024-09-21 07:49:53 consumer03_currentPower 0 W
# 2024-09-21 07:49:53 consumer03_planned_start 21.09.2024 09:00:00
# 2024-09-21 07:49:53 consumer03_planned_stop 21.09.2024 10:00:00
# 2024-09-21 07:49:53 consumer04 name='HTTPMOD_Wallbox' state='unknown' mode='can' planningstate='planned'
# 2024-09-21 07:49:53 consumer04_currentPower 1 W
# 2024-09-21 07:49:53 consumer04_planned_start 21.09.2024 09:00:00
# 2024-09-21 07:49:53 consumer04_planned_stop 21.09.2024 11:00:00
# 2023-09-16 07:21:23 currentBatteryDev BatterieWR pin=BatteryPowerBMS2:kW pout=-pin intotal=BatteryChargeTotal:kWh outtotal=BatteryDischargeTotal:kWh charge=BatteryCapacity
# 2022-04-03 18:59:44 currentInverterDev Stromverbrauch_Zaehler11 pv=P_act-get:kW etotal=total-get:kWh
# 2024-03-17 09:24:04 currentMeterDev Stromverbrauch_Zaehler1_EHZ gcon=aktuellerverbrauch-get:kW contotal=total-get:kWh gfeedin=-gcon feedtotal=ueberschuss-total-get:kWh conprice=0.3:€ feedprice =0.08:€
# 2023-11-21 21:30:01 currentRadiationAPI DWD_Forecast
# 2023-07-20 21:35:59 inverterStrings Hausdach,Hausdach2,GartenhausSued,GartenhausNord
# 2023-07-20 21:36:24 modulePeakString Hausdach=4.86 Hausdach2=2.49 GartenhausSued=0.6 GartenhausNord=0.6
# 2024-09-21 07:49:53 nextCycletime 07:51:03
# 2023-03-30 17:11:04 nextPolltime 17:12:14
# 2024-09-18 23:59:55 pvCorrectionFactor_Auto on_complex_ai
# 2024-08-21 08:39:30 setupStringAzimuth Hausdach=S Hausdach2=S GartenhausSued=S GartenhausNord=N
# 2024-08-21 08:39:30 setupStringDeclination Hausdach=20 Hausdach2=20 GartenhausSued=10 GartenhausNord=10
# 2024-09-21 07:49:54 state updated
#
setstate solcast updated
setstate solcast 2024-09-19 23:06:18 .associatedWith Stromverbrauch_Zaehler2 Shelly_Waschmaschine Shelly_Trockner HTTPMOD_Wallbox DWD_Forecast Stromverbrauch_Zaehler11 Stromverbrauch_Zaehler1_EHZ BatterieWR
setstate solcast 2024-09-21 07:49:53 .lastupdateForecastValues 1726897793
setstate solcast 2024-09-18 23:59:55 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate solcast 2024-09-21 07:49:53 Current_AutarkyRate 69 %
setstate solcast 2024-09-21 07:49:53 Current_BatCharge 22 %
setstate solcast 2024-09-21 07:49:53 Current_Consumption 140 W
setstate solcast 2024-09-21 07:49:53 Current_GridConsumption 43 W
setstate solcast 2024-09-21 07:49:53 Current_GridFeedIn 0 W
setstate solcast 2024-09-21 07:49:53 Current_PV 132 W
setstate solcast 2024-09-21 07:49:53 Current_PowerBatIn 35 W
setstate solcast 2024-09-21 07:49:53 Current_PowerBatOut 0 W
setstate solcast 2024-09-21 07:49:53 Current_SelfConsumption 97 W
setstate solcast 2024-09-21 07:49:53 Current_SelfConsumptionRate 73 %
setstate solcast 2024-09-21 07:49:53 Current_Surplus 0 W
setstate solcast 2024-09-21 07:00:00 LastHourGridconsumptionReal 500 Wh
setstate solcast 2024-09-21 07:00:00 LastHourPVforecast 0 Wh
setstate solcast 2024-09-21 07:00:00 LastHourPVreal 0 Wh
setstate solcast 2024-09-21 07:49:53 NextHours_Sum01_PVforecast 879 Wh
setstate solcast 2024-09-21 07:49:53 NextHours_Sum02_PVforecast 2892 Wh
setstate solcast 2024-09-21 07:49:53 NextHours_Sum03_PVforecast 6157 Wh
setstate solcast 2024-09-21 07:49:53 NextHours_Sum04_ConsumptionForecast 2599 Wh
setstate solcast 2024-09-21 07:49:53 NextHours_Sum04_PVforecast 10295 Wh
setstate solcast 2024-09-21 07:49:53 RestOfDayConsumptionForecast 368190 Wh
setstate solcast 2024-09-21 07:49:53 RestOfDayPVforecast 36738 Wh
setstate solcast 2024-09-21 00:59:50 Today_Hour01_BatIn 0 Wh
setstate solcast 2024-09-21 00:59:50 Today_Hour01_BatOut 0 Wh
setstate solcast 2024-09-21 00:59:50 Today_Hour01_GridConsumption 0 Wh
setstate solcast 2024-09-21 00:59:50 Today_Hour01_GridFeedIn 0 Wh
setstate solcast 2024-09-21 00:59:50 Today_Hour01_PVreal 0 Wh
setstate solcast 2024-09-21 01:59:52 Today_Hour02_BatIn 0 Wh
setstate solcast 2024-09-21 01:59:52 Today_Hour02_BatOut 1700 Wh
setstate solcast 2024-09-21 01:59:52 Today_Hour02_GridConsumption 0 Wh
setstate solcast 2024-09-21 01:59:52 Today_Hour02_GridFeedIn 0 Wh
setstate solcast 2024-09-21 01:59:52 Today_Hour02_PVreal 900 Wh
setstate solcast 2024-09-21 02:59:49 Today_Hour03_BatIn 0 Wh
setstate solcast 2024-09-21 02:59:49 Today_Hour03_BatOut 300 Wh
setstate solcast 2024-09-21 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate solcast 2024-09-21 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate solcast 2024-09-21 02:59:49 Today_Hour03_PVreal 0 Wh
setstate solcast 2024-09-21 03:59:50 Today_Hour04_BatIn 0 Wh
setstate solcast 2024-09-21 03:59:50 Today_Hour04_BatOut 300 Wh
setstate solcast 2024-09-21 03:59:50 Today_Hour04_GridConsumption 0 Wh
setstate solcast 2024-09-21 03:59:50 Today_Hour04_GridFeedIn 0 Wh
setstate solcast 2024-09-21 03:59:50 Today_Hour04_PVreal 0 Wh
setstate solcast 2024-09-21 04:59:50 Today_Hour05_BatIn 0 Wh
setstate solcast 2024-09-21 04:59:50 Today_Hour05_BatOut 900 Wh
setstate solcast 2024-09-21 04:59:50 Today_Hour05_GridConsumption 0 Wh
setstate solcast 2024-09-21 04:59:50 Today_Hour05_GridFeedIn 0 Wh
setstate solcast 2024-09-21 04:59:50 Today_Hour05_PVreal 0 Wh
setstate solcast 2024-09-21 05:59:49 Today_Hour06_BatIn 0 Wh
setstate solcast 2024-09-21 05:59:49 Today_Hour06_BatOut 300 Wh
setstate solcast 2024-09-21 05:59:49 Today_Hour06_GridConsumption 0 Wh
setstate solcast 2024-09-21 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate solcast 2024-09-21 05:59:49 Today_Hour06_PVreal 0 Wh
setstate solcast 2024-09-21 06:59:49 Today_Hour07_BatIn 0 Wh
setstate solcast 2024-09-21 06:59:49 Today_Hour07_BatOut 400 Wh
setstate solcast 2024-09-21 06:59:49 Today_Hour07_GridConsumption 500 Wh
setstate solcast 2024-09-21 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate solcast 2024-09-21 06:59:49 Today_Hour07_PVreal 0 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour08_BatIn 0 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour08_BatOut 200 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour08_GridConsumption 0 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour08_GridFeedIn 0 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour08_PVforecast 203 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour08_PVreal 130 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour09_PVforecast 1015 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour10_PVforecast 2212 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour11_PVforecast 3476 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour12_PVforecast 4270 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour13_PVforecast 5101 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour14_PVforecast 5350 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour15_PVforecast 5079 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour16_PVforecast 4311 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour17_PVforecast 3228 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour18_PVforecast 1941 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour19_PVforecast 677 Wh
setstate solcast 2024-09-21 07:49:53 Today_Hour20_PVforecast 45 Wh
setstate solcast 2024-09-21 07:49:53 Today_MaxPVforecast 5350 Wh
setstate solcast 2024-09-21 07:49:53 Today_MaxPVforecastTime 2024-09-21 13:00:00
setstate solcast 2024-09-21 07:49:53 Today_PVforecast 36908 Wh
setstate solcast 2024-09-21 07:49:53 Today_PVreal 1030 Wh
setstate solcast 2024-09-21 07:49:53 Today_SunRise 07:00
setstate solcast 2024-09-21 07:49:53 Today_SunSet 19:13
setstate solcast 2024-09-21 07:49:53 Tomorrow_ConsumptionForecast 314582 Wh
setstate solcast 2024-09-21 07:49:53 Tomorrow_Hour12_PVforecast 4515 Wh
setstate solcast 2024-09-21 07:49:53 Tomorrow_Hour13_PVforecast 5124 Wh
setstate solcast 2024-09-21 07:49:53 Tomorrow_PVforecast 36026 Wh
setstate solcast 2024-09-21 07:49:53 Tomorrow_SunRise 07:02
setstate solcast 2024-09-21 07:49:53 Tomorrow_SunSet 19:10
setstate solcast 2024-09-21 07:49:53 consumer01 name='Stromverbrauch_Zaehler2' state='unknown' mode='can' planningstate='planned'
setstate solcast 2024-09-21 07:49:53 consumer01_currentPower 7 W
setstate solcast 2024-09-21 07:49:53 consumer01_planned_start 21.09.2024 09:00:00
setstate solcast 2024-09-21 07:49:53 consumer01_planned_stop 21.09.2024 13:00:00
setstate solcast 2024-09-21 07:49:53 consumer02 name='Shelly_Waschmaschine' state='on' mode='can' planningstate='planned'
setstate solcast 2024-09-21 07:49:53 consumer02_currentPower 0 W
setstate solcast 2024-09-21 07:49:53 consumer02_planned_start 21.09.2024 09:00:00
setstate solcast 2024-09-21 07:49:53 consumer02_planned_stop 21.09.2024 10:00:00
setstate solcast 2024-09-21 07:49:53 consumer03 name='Shelly_Trockner' state='on' mode='can' planningstate='planned'
setstate solcast 2024-09-21 07:49:53 consumer03_currentPower 0 W
setstate solcast 2024-09-21 07:49:53 consumer03_planned_start 21.09.2024 09:00:00
setstate solcast 2024-09-21 07:49:53 consumer03_planned_stop 21.09.2024 10:00:00
setstate solcast 2024-09-21 07:49:53 consumer04 name='HTTPMOD_Wallbox' state='unknown' mode='can' planningstate='planned'
setstate solcast 2024-09-21 07:49:53 consumer04_currentPower 1 W
setstate solcast 2024-09-21 07:49:53 consumer04_planned_start 21.09.2024 09:00:00
setstate solcast 2024-09-21 07:49:53 consumer04_planned_stop 21.09.2024 11:00:00
setstate solcast 2023-09-16 07:21:23 currentBatteryDev BatterieWR pin=BatteryPowerBMS2:kW pout=-pin intotal=BatteryChargeTotal:kWh outtotal=BatteryDischargeTotal:kWh charge=BatteryCapacity
setstate solcast 2022-04-03 18:59:44 currentInverterDev Stromverbrauch_Zaehler11 pv=P_act-get:kW etotal=total-get:kWh
setstate solcast 2024-03-17 09:24:04 currentMeterDev Stromverbrauch_Zaehler1_EHZ gcon=aktuellerverbrauch-get:kW contotal=total-get:kWh gfeedin=-gcon feedtotal=ueberschuss-total-get:kWh conprice=0.3:€ feedprice =0.08:€
setstate solcast 2023-11-21 21:30:01 currentRadiationAPI DWD_Forecast
setstate solcast 2023-07-20 21:35:59 inverterStrings Hausdach,Hausdach2,GartenhausSued,GartenhausNord
setstate solcast 2023-07-20 21:36:24 modulePeakString Hausdach=4.86 Hausdach2=2.49 GartenhausSued=0.6 GartenhausNord=0.6
setstate solcast 2024-09-21 07:49:53 nextCycletime 07:51:03
setstate solcast 2023-03-30 17:11:04 nextPolltime 17:12:14
setstate solcast 2024-09-18 23:59:55 pvCorrectionFactor_Auto on_complex_ai
setstate solcast 2024-08-21 08:39:30 setupStringAzimuth Hausdach=S Hausdach2=S GartenhausSued=S GartenhausNord=N
setstate solcast 2024-08-21 08:39:30 setupStringDeclination Hausdach=20 Hausdach2=20 GartenhausSued=10 GartenhausNord=10
setstate solcast 2024-09-21 07:49:54 state updated
Da hatten wir doch letztens erst erstaunlich Ähnliches bei pah. Vieleicht doch ein Problem im Modul?
Eventuell die initialisierung nicht vollständig oder es werden eventuell Werte nicht sauber neu initialisiert bei eventuellen Änderungen?
Steck da nicht so drin im Modul aber aus Erfahrung kenne ich so dubiose Phänomene an anderen Systemen aufgrund des oben aufgeführten.
Um das rauszubekommen müßte man aber viel mehr Wissen. Und nicht glauben.
Bei pah schien es ja simpel. Neu aufgesetzt und dann war es da.
Bei andi11 war es bestand und es wurde umparametriert/anders befüttert.
@andi11: Bei pah war die Lösung ab #922.
ZitatDa hatten wir doch letztens erst erstaunlich Ähnliches bei pah. Vieleicht doch ein Problem im Modul?
Das hat mich heute früh natürlich auch stutzig gemacht und bin auf die Suche gegangen.
Ich habe einen logischen Fehler identifiziert der sich bei der Berechnung des con von "NextHours" befand.
Bin gerade beim Fixing und gebe euch Bescheid wenn ich fertig bin.
LG
@all,
habe die Version 1.32.0 mit dem Fix bzgl. Consumtion Forecast eingecheckt. Sie liegt auch zum Download in meinem contrib bereit wer es eilig hat.
Das ctrlDebug=consumption_long zeigt noch mehr Informationen um die Quelle eventueller Ausreißer gespeicherter Werte besser identifizieren zu können, z.B:
2024.09.21 11:09:47.074 1: SolCast DEBUG> historical Consumption added for So -> date: 01, hod: 11 -> 656 Wh
2024.09.21 11:09:47.074 1: SolCast DEBUG> historical Consumption added for So -> date: 08, hod: 11 -> 766 Wh
2024.09.21 11:09:47.075 1: SolCast DEBUG> historical Consumption added for So -> date: 15, hod: 11 -> 719 Wh
2024.09.21 11:09:47.075 1: SolCast DEBUG> historical Consumption added for So -> date: 25, hod: 11 -> 573 Wh
2024.09.21 11:09:47.075 1: SolCast DEBUG> estimated Consumption for So -> starttime: 2024-09-22 10:00:00, confc: 678, days for avg: 4, hist. consumption registered consumers: 527.86
2024.09.21 11:09:47.076 1: SolCast DEBUG> historical Consumption added for So -> date: 01, hod: 12 -> 595 Wh
2024.09.21 11:09:47.076 1: SolCast DEBUG> historical Consumption added for So -> date: 08, hod: 12 -> 1353 Wh
2024.09.21 11:09:47.076 1: SolCast DEBUG> historical Consumption added for So -> date: 15, hod: 12 -> 625 Wh
2024.09.21 11:09:47.077 1: SolCast DEBUG> historical Consumption added for So -> date: 25, hod: 12 -> 1325 Wh
2024.09.21 11:09:47.077 1: SolCast DEBUG> estimated Consumption for So -> starttime: 2024-09-22 11:00:00, confc: 974, days for avg: 4, hist. consumption registered consumers: 543.25
Ich habe im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_funktioniert_die_Verbrauchsprognose?) eine Vorgehensweise zur Lösung von Problemen bei Consumption Forecast hinterlegt.
Krasser Scheiß, was anderes kann ich dazu nicht sagen.
07:50 Uhr Problem gepostet
10:01 Uhr Spezifischer Verweis auf Posts aus dem 66-seitigen Beitrag
11:23 Uhr Fix, der es ggf. ein bisschen robuster macht
13:50 Uhr Wahnsinnig detaillierter WIKI-Beitrag, der die Zusammenhänge verständlich erläutert; dabei noch ein paar tolle Funktionen entdeckt, die ich noch gar nicht kannte, z. B. Verbrauchsvorhersage bis Sonnenaufgang.
Mir fallen so ziemlich gar keine kommerziellen Systeme ein, bei denen der Support so dermaßen effizient ist.
=> Ich fühle mich für den Fall gerüstet, dass ein einfaches zurücksetzen der Verbrauchsstatistik nicht geholfen hat.
Im Modul wird eine ziemlich grobe Tabelle der "Flächenfaktoren" verwendet. Ich halte es für sinnvoll, stattdessen eine interpolierende Funktion mit 2 Parametern zu bestimmen.
LG
pah
Zitat von: andi11 am 21 September 2024, 15:04:04Krasser Scheiß, was anderes kann ich da nicht sagen
Die Verrohung der deutschen Sprache schreitet voran. Passt zur Rechtschreibung, meine Güte...
ZitatIch halte es für sinnvoll, stattdessen eine interpolierende Funktion mit 2 Parametern zu bestimmen.
Ja, gern.
@all, wer mag kann gern mal einen Vorschlag einer solchen Funktion unterbreiten. Diese Funktion muß im Ergebnis die Grafik des angehängten Screenshots abbilden und abhängig von der Ausrichtung (N->O->S->W->N bzw. -180 bis 180 Grad) und der Neigung (0 - 90) den Flächenfaktor in % (33-118) liefern.
Edit: als kleine Hilfestellung die aktuell im Modul verwendete Matrix, die ein Raster der Flächenfaktorgrafik abbildet.
my %hff = (
"0" => { N => 100, NE => 100, E => 100, SE => 100, S => 100, SW => 100, W => 100, NW => 100 },
"5" => { N => 95, NE => 96, E => 100, SE => 103, S => 105, SW => 103, W => 100, NW => 96 },
"10" => { N => 90, NE => 93, E => 100, SE => 105, S => 107, SW => 105, W => 100, NW => 93 },
"15" => { N => 85, NE => 90, E => 99, SE => 107, S => 111, SW => 107, W => 99, NW => 90 },
"20" => { N => 80, NE => 84, E => 97, SE => 108, S => 114, SW => 108, W => 97, NW => 84 },
"25" => { N => 75, NE => 80, E => 95, SE => 109, S => 115, SW => 109, W => 95, NW => 80 },
"30" => { N => 69, NE => 76, E => 94, SE => 110, S => 117, SW => 110, W => 94, NW => 76 },
"35" => { N => 65, NE => 71, E => 92, SE => 110, S => 118, SW => 110, W => 92, NW => 71 },
"40" => { N => 59, NE => 68, E => 90, SE => 109, S => 117, SW => 109, W => 90, NW => 68 },
"45" => { N => 55, NE => 65, E => 87, SE => 108, S => 115, SW => 108, W => 87, NW => 65 },
"50" => { N => 49, NE => 62, E => 85, SE => 107, S => 113, SW => 107, W => 85, NW => 62 },
"55" => { N => 45, NE => 58, E => 83, SE => 105, S => 112, SW => 105, W => 83, NW => 58 },
"60" => { N => 42, NE => 55, E => 80, SE => 102, S => 111, SW => 102, W => 80, NW => 55 },
"65" => { N => 39, NE => 53, E => 77, SE => 99, S => 108, SW => 99, W => 77, NW => 53 },
"70" => { N => 37, NE => 50, E => 74, SE => 95, S => 104, SW => 95, W => 74, NW => 50 },
"75" => { N => 36, NE => 48, E => 70, SE => 90, S => 100, SW => 90, W => 70, NW => 48 },
"80" => { N => 35, NE => 46, E => 67, SE => 86, S => 95, SW => 86, W => 67, NW => 46 },
"85" => { N => 34, NE => 44, E => 64, SE => 82, S => 90, SW => 82, W => 64, NW => 44 },
"90" => { N => 33, NE => 43, E => 62, SE => 78, S => 85, SW => 78, W => 62, NW => 43 },
);LG,
Heiko
Eine "einfache" Formel wird es hier kaum geben oder? Eine Möglichkeit ist die Zwischenwerte zu interpolieren. Aber die Verringerung des "Fehlers" wird hier ehr im Bereich weniger Prozent liegen oder?
Zitat von: Prof. Dr. Peter Henning am 24 September 2024, 14:34:01Die Verrohung der deutschen Sprache schreitet voran. Passt zur Rechtschreibung, meine Güte...
Ich für meinen Teil freue mich lieber über nette und hilfsbereite Mitmenschen, als Fehler bei anderen zu suchen.
ZitatEine "einfache" Formel wird es hier kaum geben oder? Eine Möglichkeit ist die Zwischenwerte zu interpolieren. Aber die Verringerung des "Fehlers" wird hier ehr im Bereich weniger Prozent liegen oder?
Stimmt, die wird es nicht geben. Auch die durch die Matrixverwendung bedingten Abweichungen werden sehr gering sein, zumal man als Anlagenbetreiber [Ironie an] sicherlich und ganz bestimmt den Anstellwinkel und die Ausrichtung der Module auf das Grad genau bestimmt. [Ironie aus]
Die Auswirkungen der tatsächlichen zur prognostizierten Bewölkung hingegen halte ich angesichts der Wetterdynamik für absolut bedeutungsvoller für das Ergebnis. Deswegen sind die Ertragsergebnisse im Vergleich zur Prognose bei stabilen / wolkenlosen Wetterlagen im eingeschwungenen Zustand bestens.
Ungeachtet dessen kann man natürlich eine Formel statt einer Matrix verwenden sofern man ein passendes und gut integrierbares mathematisches Modell findet. Aber der Aufwand dafür sollte in Anbetracht der zu erwartenden unerheblichen Verbesserung überschaubar bleiben.
Alternativ kann ich die verwendete Matrix noch etwas mit Zwischenwerten anreichern. Das wäre eine Fleißarbeit für lange und dunkle Winterabende.
Edit: Es gibt noch viel mehr Faktoren die alle in Summe Verfälschungen bewirken können. Denken wir an die verschiedenen Wirkungsgrade die eine Anlage haben kann, oder Verschatungsthematiken bzw. Alterungsverluste die mit der Zeit eintreten. Ein weites Feld.
LG
Klar kann man einwenden, dass die Vorhersage mit dem Modul ja offenbar in "eingeschwungenem Zustand" funktioniert. Prima, das zeigt jedoch nur, dass die eigenen lokalen Erfahrungswerte (sprich: Historie) wichtiger sind, also solche Korrekturen. Dennoch sollte man diese entweder ganz weglassen, oder richtig machen. Ignorieren wir also mal das "Einschwingen" - dann sieht das schon anders aus:
Zunächst einmal ist die Behauptung, "eine einfache Formel wird es nicht geben" ziemlich gewagt. Wir spielen hier nicht das heitere Mathematik-Ratespiel, also erst einmal abwarten.
Zweitens ist das mit der "Abweichung im Bereich weniger Prozent" falsch. Die horizontale Auflösung der Tabelle ist mit 45 Grad so granatenmäßig schlecht, dass alleine dadurch ein Fehler von 10% hineinkommen kann.
Drittens ist das mit der "Aufgabe für lange dunkle Winterabende" falsch. Es hat mich ziemlich genau 10 Minuten gekostet, die Tabelle in Mathematica zu importieren, und weitere 2 Minuten, eine Interpolation durchzuführen. Beispiel ist die Interpolation des Flächenfaktors bei 30 Grad Neigung mit einer horizontalen Winkelauflösung von 5 Grad, statt 45 Grad
Zitat{{0, 69.}, {5, 68.8304}, {10, 68.9392}, {15, 69.3086}, {20,
69.9209}, {25, 70.7581}, {30, 71.8025}, {35, 73.0361}, {40,
74.4412}, {45, 76.}, {50, 77.6946}, {55, 79.5071}, {60,
81.4198}, {65, 83.4147}, {70, 85.4742}, {75, 87.5802}, {80,
89.7151}, {85, 91.861}, {90, 94.}, {95, 96.0046}, {100,
97.9749}, {105, 99.9012}, {110, 101.774}, {115, 103.584}, {120,
105.321}, {125, 106.976}, {130, 108.539}, {135, 110.}, {140,
111.314}, {145, 112.509}, {150, 113.58}, {155, 114.519}, {160,
115.32}, {165, 115.975}, {170, 116.478}, {175, 116.822}, {180,
117.}, {185, 116.822}, {190, 116.478}, {195, 115.975}, {200,
115.32}, {205, 114.519}, {210, 113.58}, {215, 112.509}, {220,
111.314}, {225, 110.}, {230, 108.539}, {235, 106.976}, {240,
105.321}, {245, 103.584}, {250, 101.774}, {255, 99.9012}, {260,
97.9749}, {265, 96.0046}, {270, 94.}, {275, 91.861}, {280,
89.7151}, {285, 87.5802}, {290, 85.4742}, {295, 83.4147}, {300,
81.4198}, {305, 79.5071}, {310, 77.6946}, {315, 76.}, {320,
74.4412}, {325, 73.0361}, {330, 71.8025}, {335, 70.7581}, {340,
69.9209}, {345, 69.3086}, {350, 68.9392}, {355, 68.8304}, {360,
69.}}
Winkelauflösung von 0,5 Grad? Kein Problem, geht auf einen Tastendruck - und zwar auch bei der Neigung.
Das ist aber nicht das Ziel, denn die Suche in einer solchen Tabelle kostet Rechenzeit.
Schließlich muss man an der Sache noch eine generelle Kritik anbringen. Denn diese Flächenfaktoren beziehen sich auf den _Jahresertrag_. Es ist also einfach sachlich falsch, den prognostizierten Ertrag an einem bestimmten Tag, mehr noch zu einer bestimmten Stunde, mit Hilfe dieses Flächenfaktors zu bestimmen. Richtiger wäre, Azimut und Elevation der Sonne (z.B. aus dem Astro-Modul) mit horizontaler Ausrichtung und Neigung der PV-Anlage zu verrechnen, das sind tatsächlich nur ein paar Winkelfunktionen.
Im nachfolgenden Codefragment ist das zu sehen - allerdings ist hier noch nicht die Bewölkung (z.B. aus der DWD-Prognose) eingerechnet, das wäre also nur ein Korrekturfaktor bei wolkenlosem Himmel.
###############################################################################
#
# Prognose Photovoltaik
#
###############################################################################
sub PVExpectedYield($$$){
my ($pvdev,$astrodev,$datetime) = @_;
my $tilt = AttrVal($pvdev,"Tilt",0);
my $align = AttrVal($pvdev,"Alignment",0);
my $maxp = AttrVal($pvdev,"PSP",0);
#my $eta = ReadingsVal($pvdev,"Eta",0);
#$eta = 0.14;
my $sunalt = ReadingsVal($astrodev,"SunAlt",0);
my $sunaz = ReadingsVal($astrodev,"SunAz",0);
my $pi180 = 0.0174532918889;
#-- Normale der Anlage (Nordrichtung = y-Achse, Ostrichtung = x-Achse)
my $nz = cos($tilt*$pi180);
my $ny = sin($tilt*$pi180)*cos($align*$pi180);
my $nx = sin($tilt*$pi180)*sin($align*$pi180);
#-- Vektor zur Sonne
my $sz = sin($sunalt*$pi180);
my $sy = cos($sunalt*$pi180)*cos($sunaz*$pi180);
my $sx = cos($sunalt*$pi180)*sin($sunaz*$pi180);
my $ret = "===> Normale N = ($nx,$ny,$nz) Richtung Sonne S = ($sx,$sy,$sz)";
my $factor = $nx*$sx + $ny*$sy + $nz*$sz;
my $exp = sprintf("%.3f",max($maxp*$factor,0));
#$ret .= sprintf("Reduktion um Faktor %0.2f ergibt %.3fkW erwartete Leistung $exp");
#Log 1,$ret;
return $exp
}LG
pah
ZitatZunächst einmal ist die Behauptung, "eine einfache Formel wird es nicht geben" ziemlich gewagt. Wir spielen hier nicht das heitere Mathematik-Ratespiel, also erst einmal abwarten.
Ja, dann warten wir mal auf eine einfache Formel die den Sachverhalt aus dem Screenshot in meinem obigen Post abbildet. ;) Lasse mich gerne vom Gegenteil überzeugen.
ZitatZweitens ist das mit der "Abweichung im Bereich weniger Prozent" falsch. Die horizontale Auflösung der Tabelle ist mit 45 Grad so granatenmäßig schlecht, dass alleine dadurch ein Fehler von 10% hineinkommen kann.
Und wenn sich eine Wolke vor die Anlage schiebt und dort eine Stunde verbleibt, ist alles komplett für die Katz. Nur mal so.
Aber Verbesserungen kann man immer einfließen lassen, keine Frage.
LG
@pah, Frage ... Was steckt in $pi180 = 0.0174532918889 ?
Zitat von: Prof. Dr. Peter Henning am 25 September 2024, 10:53:56Zweitens ist das mit der "Abweichung im Bereich weniger Prozent" falsch. Die horizontale Auflösung der Tabelle ist mit 45 Grad so granatenmäßig schlecht, dass alleine dadurch ein Fehler von 10% hineinkommen kann.
stimmt, hatte ich übersehen. Auch dass unterschiedliche Einheiten / Korrekturen zusammen verwendet werden. Ob das übers Jahr einen Unterschied macht, könnte sich mit den detallierten Strahlungsdaten von PVGIS der vergangenen Jahre vergleichen lassen.
Zitat von: Prof. Dr. Peter Henning am 25 September 2024, 10:53:56Drittens ist das mit der "Aufgabe für lange dunkle Winterabende" falsch. Es hat mich ziemlich genau 10 Minuten gekostet, die Tabelle in Mathematica zu importieren, und weitere 2 Minuten, eine Interpolation durchzuführen. Beispiel ist die Interpolation des Flächenfaktors bei 30 Grad Neigung mit einer horizontalen Winkelauflösung von 5 Grad, statt 45 Grad
Und was zeigst du uns damit? Dass du in ziemlich genau 12 Minuten dass erzeugen kannst, was deiner Meinung nach besser durch eine Formel abgebildet werden kann?
Dass eine Formel pfiffig wäre, dass sehe ich genauso. Aber eine Formel, die auch noch weniger Rechenzeit benötigt als eine Lookup Tabelle? Dass ist nochmal eine extra Herausforderung.
ZitatAuch dass unterschiedliche Einheiten / Korrekturen zusammen verwendet werden.
Kannst du erläutern wo? Ich achte genau darauf dass Einheiten innerhalb einer Formel passen.
Kann natürlich auch mal übersehen werden.
Wie gesagt, die Matrix kann ich weiter untersetzen.
Übrigens wird die Matrix ausschließlich beim Model DWD benutzt, alle anderen API verwenden die genaue Azimutangabe in Grad aus setupStringAzimuth sofern man die Azimutangabe und nicht die Kennung (N, NE,...) angibt. Nur als Hinweis.
Zitat von: DS_Starter am 25 September 2024, 16:23:01Kannst du erläutern wo? Ich achte genau darauf dass Einheiten innerhalb einer Formel passen.
Ich meinte diesen Hinweis:
Zitat von: Prof. Dr. Peter Henning am 25 September 2024, 10:53:56Schließlich muss man an der Sache noch eine generelle Kritik anbringen. Denn diese Flächenfaktoren beziehen sich auf den _Jahresertrag_. Es ist also einfach sachlich falsch, den prognostizierten Ertrag an einem bestimmten Tag, mehr noch zu einer bestimmten Stunde, mit Hilfe dieses Flächenfaktors zu bestimmen. Richtiger wäre, Azimut und Elevation der Sonne (z.B. aus dem Astro-Modul) mit horizontaler Ausrichtung und Neigung der PV-Anlage zu verrechnen, das sind tatsächlich nur ein paar Winkelfunktionen.
Achso, ok.
Also ich bin durchaus geneigt und interessiert das Model DWD auf den Ansatz von pah mit dem Snippet sub PVExpectedYield umzustellen. Die Angaben von SunAlt und SunAz hatte ich ja bereits vor einiger Zeit aus Astro ins Modul geholt. Alle andere APIs arbeiten nicht mit der Matrix.
Als Beobachtung kann ich allerdings sagen, dass ich das Model DWD auch neben meinem prod. Model SolCastAPI mitlaufen lasse, welches mit den genauen Grad-Angaben eingerichtet wird.
Wenn ich z.B. die Ergebnisse von gestern vergleiche, was wirklich kein guter Tag war, lag die Solcast-Abweichung bei 6,7% und DWD bei 7,3%.
Also so verkehrt kann die Vorgehensweise m.M. nach nicht sein. Ich kann mir allerdings auch vorstellen, dass sich vor allem bei Direkteinstrahlung Unterschiede bemerkbar machen und nicht so sehr bei diffuser Bestrahlung was wiederum durch die permanente Fortschreibung von Korrekturfaktoren (auch zur Einbeziehung spezifischer Anlagenkennwerte) ausgeglichen wird. Zumindest nach einer gewissen Laufzeit.
Hallo zusammen,
habe gerade von DWD Ensembel wieder auf DWD API umgestellt.
Hatte gestern -5,2% und heute +1,5%.
Ich bin total begeistert von DWD API so wie sie ist.
Für mich viel besser als die anderen.
Habe anscheinend Glück, habe 2 Stationen im Umkreis von 3-4km und die scheinen gut zu meinem Setup zu passen ;-)
Lernzeit hatte die Anlage noch nicht.
Natürlich bin ich auch, wenn möglich, für die genaueste Berechnungsmethode, was sicherlich die Formel ist.
Aber in der Informatik muss man auch immer die 80/20-Regel beachten.
Wenn man noch 80% Aufwand reinstecken muss, nur um die letzten 20% rauszuquetschen, dann macht es vom Aufwand her vielleicht keinen Sinn mehr, zum Glück ist das hier alles ein Hobby ;-).
Und für mich persönlich ist es bei der DWD Vorhersage so, dass sie einwandfrei funktioniert und es eigentlich nur schlechter werden kann ;-)
Muss aber nicht für jeden so sein.
Viele Grüße,
Stefan
Zitat von: DS_Starter am 25 September 2024, 16:50:31Zumindest nach einer gewissen Laufzeit.
Das habe ich ja schon geschrieben.
Der Knackpunkt ist aber, dass man mit einem falschen Ansatz beliebig viele Ergebnisse produzieren kann, die "ungefähr richtig" sind. Und das trifft eben in diesem Falle zu: Eine Vorhersage der (richtungsunabhängigen, momentanen) Globalstrahlung mit einem (richtungsabhängigen, aus Jahr bezogenen) Faktor zu multiplizieren, ist schon etwas willkürlich. Das ist ungefähr so, als ob ich aus der Länge und Breite eines Schiffes auf das Alter des Kapitäns schließen wollte - eben schon irgendwie korreliert, weil man eine gewisse Erfahrung braucht, um einen dicken Pott zu steuern.
Zitat@pah, Frage ... Was steckt in $pi180 = 0.0174532918889 ?
Pi/180
ZitatUnd was zeigst du uns damit? Dass du in ziemlich genau 12 Minuten dass erzeugen kannst, was deiner Meinung nach besser durch eine Formel abgebildet werden kann?
Bitte genauer lesen, was ich geschrieben habe: Es ist keine Kunst, die Tabelle mit weiteren Zwischenwerten anzureichern, wenn man das in Mathematica hat (schon gar nicht benötigt man dafür Winterabende). Das ist aber eben nicht das Ziel, sondern das Ziel ist, die Sache zu vereinfachen. Daran arbeite ich gerade, dann wird es einen Wiki-Artikel dazu geben.
LG
pah
Ja, eine Formel wäre immer schicker als statische Tabellen. Der Sinn erschliesst sich mir aber nicht unbedingt, ausser es vieleicht/eventuell/mutmasslich genauer zu machen in der Theorie.
Vieleicht habe ich da aber auch etwas nicht verstanden.
Mit der Genauigkeit ist es dann schon dahin wenn der erlernte Korrekturfaktor mit in die Auswertung eingeht.
Klar wäre es schöner alle Werte so genau wie möglich zu haben um etwas zu prognostizieren.
Allerdings sind hier, in dem Fall, mehrere und größere Ungenauigkeiten als die Winkelangabe bzw. dessen Ausgabe der Strahlungswerte.
Der Korrekturfaktor sollte diese Ungenauigkeit schon weiter ausgleichen. Da der Winkelfehler ja immer gleich bleibt.
Das läst die Genauigkeit der Anzeige bzw. dessen Ausgabewert verfälschen. Aber die Tendenz bleibt die gleiche.
Das ein Physiker/Mathematiker die genauen Werte anstrebt ist verständlich (Wäre auch schlimm wenn nicht).
Der kleine Bürger will eher Werte die plausibel erscheinen und reproduzierbar sind.
Ihm ist da die absolute Genauigkeit zweitranging.
DEm Proletariat ist es zudem egal ob das mit einem geeichten Messgerät erfolgt oder nicht.
Die Verschattung kommt auch mit da rein. Zudem ist die Vorhersage der API's genauso ungenau Teilweise und Fehlrbehaftet.
Ich glaube da fällt der Winkelfehler dann am Ende nicht so ins Gewicht. Weil, wie schon erwähnt, dieser immer gleich "falsch" ist.
Aber @pah du hast da schon Recht das genauer zumachen macht sicher ein bischen Sinn.
Dadurch würde der Korrekturfaktor ja gezwungenermassen genauer werden, und dieser verfälscht ja auch mit. Nur dann etwas weniger eventuell.
Alles nicht ganz so einfach.
ZitatZitat@pah, Frage ... Was steckt in $pi180 = 0.0174532918889 ?
Pi/180
Ich glaube die Frage war eher "warum" und nicht "was" das ist.
Um in Bogenmass weiter zu rechnen (2pi = 360°).
https://de.wikipedia.org/wiki/Radiant_(Einheit)
So, voila.
Mit der nachstehenden Funktion lässt sich der Flächenfaktor im gesamten Winkelbereich der Tabelle sehr genau reproduzieren.
###############################################################################
#
# Flächenfaktor Photovoltaik
#
# Prof. Dr. Peter A. Henning, September 2024
#
###############################################################################
sub PV_hff($$){
my ($neigung,$ausrichtung) = @_;
my $pi180 = 0.0174532918889;
return undef
if( $neigung<0.0 || $neigung>90.0 || $ausrichtung<0.0 || $ausrichtung>360. );
my $x=$neigung*sin($ausrichtung*$pi180);
my $y=$neigung*cos($ausrichtung*$pi180);
my $x2 = $x**2;
my $x4 = $x2**2;
my $res = 3.808301895960147E-7 - 8.650170178954599E-11 * $x2 + 5.50016483344622E-15 * $x4;
$res = $res*$y + 0.00007319316326291892 - 3.604294916743569E-9 * $x2 - 2.343747951073022E-13 * $x4;
$res = $res*$y - 0.00785953342909065 + 1.1197340251684106E-6 * $x2 - 8.99915952119488E-11 * $x4;
$res = $res*$y - 0.8432627150525525 + 0.00010392051567819936 * $x2 - 3.979206287671085E-9 * $x4;
$res = $res*$y + 99.49627151067648 - 0.006340200119196879 * $x2 + 2.052575360270524E-7 * $x4;
return $res
}
Die Abweichung von den Werten in der Tabelle liegt fast überall unter 2%, und diese werden nur an wenigen Stellen erreicht. Näheres dazu auch in diesem Wiki-Artikel: https://wiki.fhem.de/wiki/Ertragsprognose_PV
LG
pah
Im Bild links die interpolierte Tabelle (ohne Glättung), rechts die mit der o.a. Funktion berechnete Näherung. Darunter der Absolutbetrag der Abweichung der Näherung von der Tabelle (in Prozent).
PVProg_HFF.pngPVProg_GFF.png
PVProg_diff.png
Hallo pah,
danke für die Zuarbeit. :)
Die Tabelle im Modul würde ich mit deiner Funktion substituieren.
Wie ich sehe, läuft hier das Azimut/Modulausrichtung von 0-360°, richtig? Denn im Setup lassen sich 180 ...0 ...-180 angeben, was ich intern entsprechend umrechnen würde.
Für einen Lerneffekt wäre es allerdings nicht verkehrt die Schritte zur Herleitung der Funktion zu verstehen.
LG
Na ja, die Himmelsrichtung wird nicht von -180° bis 180° angegeben, sondern von 0 - 360°.
Und "Herleitung" ist gut:
1. Umschreiben der Tabelle auf die Variablen x=Neigung*Sin(Ausrichtung) und y=Neigung*Cos(Ausrichtung)
2. Cleverer Ansatz, nämlich das Tensorprodukt der Funktionen (1,x²,x⁴) mit (1,y,y²,y³,y⁴). Für x braucht man wegen der Symmetrie nur gerade Potenzen.
3. Ausgleichsrechnung, welche die 15 Koeffizienten des Tensorproduktes so wählt, dass die Summe der quadratischen Abweichungen zur Tabelle minimal wird.
Letzteres natürlich nicht manuell, sondern mit Mathematica https://www.wolfram.com/mathematica/. Nutze ich seit 1988 für meine physikalischen Forschungen.
LG
pah
Mathematica hatte ich mir schon im Web angeschaut. Ist leider für Privatnutzer nicht kostenlos. Für euch im HS bzw. Forschungsbereich vermutlich schon.
Zitat von: DS_Starter am 26 September 2024, 19:26:00Für euch im HS bzw. Forschungsbereich vermutlich schon.
Nö, kostenlos ist gar nichts. Das bezahle ich aus meinen Forschungsmitteln, die ich mir mühsam verdiene... Oder verdient habe.
Tipp für Hobbyanwender: Es gibt eine sehr schöne App für Wolfram Alpha, mit der man die wichtigsten Features von Mathematica nutzen kann.
LG
pah
@all,
morgen früh ist eine neue Version im Update.
Die interne Lookup-Tabelle ist durch die Flächenfaktor-Formel von pah ersetzt.
Für den Anwender ergeben sich dadurch keinerlei ToDos.
Wer es noch nicht getan hat, kann im Setter setupStringAzimuth seine Anlagenausrichtung auf ganzzahlige Zwischenwerte von -180 bis 180 einstellen statt N, NE etc.
Einen evtl. Impact gibt es nur beim Model DWD.
LG,
Heiko
Ok, vielen Dank.
Ich werde testen.
Habe ja DWD im Idealfall merke ich nichts oder die Vorhersage wird noch besser ;-)
Auch heute bei katastrophalen Bedingungen nur 8,3% Abweichung.
Gruß,
Stefan
Moin,
habe gerade festgestellt, dass die Änderung negative Auswirkungen auf die OpenMeteo Modelle hat.
Das ist aber mein Fehler weil ich eine interne Abhängigkeit nicht bedacht hatte.
Ich fixe es und gebe kurzfristig Bescheid.
LG
Fix ist eingecheckt und die V.1.33.1 auch in meinem contrib zum Download verfügbar.
Restart nicht vergessen!
LG
Hallo Heiko,
irgendwas ist da noch Anders als vorher:
set Forecast setupStringAzimuth Suedseite=0 Westseite=90
set Forecast setupStringDeclination Suedseite=35 Westseite=60
ergibt in der Anlagenkonfigurationsprüfung
StringConfiguration : "rot" Suedseite => azimut: 180, peak: 7.66, tilt: 35
Westseite => azimut: 270, peak: 2.2, tilt: 60
das ging so bisher ohne Fehler
Grüße WDS
Hast du meinen Fix eingespielt und auch restartet? Restart danach ist wichtig.
Ja, hab ich
$Id: 76_SolarForecast.pm 29166 2024-09-26 21:49:50Z DS_Starter $Meine Stringkonfig ist verm. auch richtig nach der Ergänzung von pah.
Also 180 Grad = Süd.
LG WDS
Hatte bislang nicht den "set plantConfiguration check" angeschaut....
->> dto. bei der Überprüfung bei mir:
FVERSION 1.33.1
LCACHEFILE last write time: 19:00:41 whole Operating Memory
MODE Automatic - next Cycletime: 19:07:31
MODEL OpenMeteoDWDEnsembleAPI
NAME Forecast
Gruß
300P
Bei solchen Änderungen verbirgt sich doch immer noch irgendwo ein kleine Falle. ;)
War unterwegs und konnte es nicht nachprüfen. Schaue es mir an, wird nur eine Kleinigkeit sein.
LG
Hallo Dieter & 300P,
danke für eure Rückinfos.
Habe den kleinen Lunker gefunden und checke ein. Ist morgen früh im Update.
LG,
Heiko
kein Problem - jeder hat ein großes Recht auf ein Privatleben.
Du bist schon sehr sehr sehr .....sehr schnell bei auftretenden Problemen.
Vermute das hier einfach nur "falsch" geprüft und deshalb "Rot" als Ergebnis angezeigt wird (wegen der neuesten Umstellung)
Ja das hat damit zu tun dass ich nun intern alle Richtungsidentifikatoren N, NE, S etc. generell in das Azimut von -180 bis 180 Grad bzw. 0-360 Grad umsetze. Ich brauche beides, die Formel von pah arbeitet mit Grad 0-360, unsere anderen API's mit der Azimutangabe -180 - 0 - 180.
Muß alles berücksichtigt werden und die Prüfung brachte einen falschen Fehler.
So ist eingecheckt und auch wieder in meinem contrib ... wer mag.
....wird wieder "Grün" 8)
==> Danke sehr !!
Hallo,
das mit dem Flowdiagram wie einst angedacht, finde ich nach längerem überlegen nicht brauchbar.
Geplant war soetwas wie hier schematisch dargestellt:
erzeuger1 erzeuger2 erzeuger3
: : :
netz --- [ haus ]--- Speicher
: :
verbraucher1 verbraucher2
Da wäre der Sternpunkt aller Geräte das "Haus".
Was ist aber wenn man DC-ladung direkt in den Speicher schiebt mit nur Ladereglern?
Das würde ja nie so wirklich in das "Haus" einfliessen.
Zudem habe ich mir die Anmerkung von pah angeschaut. Eine Volleinspeiseanlage würde direkt auf das "Netz" gehen und nicht ins Haus.
Das könnte man aber Lösen indem man dem "Producer" eventuell ein "gridonly" attribute spendiert. Damit und einem weiteren "ignoreProducerForPlanning" könnte man dann bei der Consumerschaltung zudem reagieren ob diese erzeugte Leistung mit in die "Haus"-Einspeisung wirkt und als Nutzenergie zur Verfügung steht.
Ehrlich gesagt habe ich da noch nicht die super Lösung im Kopf ohne eventuelle Kreuzungen der Linien. Und das ist nix.
Die Frage ist jetzt eigentlich wie detailiert soll es werden?
Die Laderegler ins Haus speisen lassen grafisch, Der Besitzer weiß aber das das in Wirklichkeit garnicht so ist?
Wäre aber doof wenn man das dann dritten Verfügbar macht. Die wissen es nicht.
Hat da einer Ideen wie man das lösen könnte oder sollen wir das so umsetzen wie angedacht?
Immer her mit der Kreativität.
Achtung: In der Näherung für die Flächenfaktoren wird nicht "mit dem Bogenmaß gearbeitet". Die übergebenen Parameter sind die Angaben in Grad, nur für die Berechnung von Sinus und Cosinus wird intern das Bogenmaß verwendet.
LG
pah
@pah, ja weiß ich, war ungenau ausgedrüct.
@kask, danke dass du dir viele Gedanken machst. :)
1. Laderegler: Ich habe auch die Victron Lader. Deren Energie wird ja momentan über einen Dummy als "Inverter"
zusammengeführt und so dem "Haus" zugeführt. Das "Haus" steht als Synonym für den Sammelpunkt
und nicht für das Objekt "Haus". Vllt. fällt uns da etwas bessers ein.
D.h. momentan liefert der summarische Inverter an den Knotenpunkt. Grafisch wird der Anteil
der nicht eingespeist oder verbraucht wird der Batterie zugeführt und dort steckt der
Anteil Laderegler mit drin.
Das wäre auch so wenn wir grafisch von der Sonne nicht direkt zur Batterie, sondern über den
Umweg "Haus" zur Batterie gehen würden.
2. Volleinspeiseanlage: Meiner Meinung nach ist so eine Anlage durch einen eigenen Zähler gekennzeichnet
und hat keine Verbindung zum "Haus". Sie versorgt also keine Verbraucher im Haus,
was sie von der Überschußeinspeisung unterscheidet.
Im Kontext SF sehe ich so eine Anlage eigentlich als separates SF-Device.
Sollte eine solche Anlage geografisch gtrennt vom "Haus" sein, einen eigenen Zähler
haben und vlt. zusätzlich nach eine Verbindung zum "Haus" (über einen weiteren
Zähler) so ist es wieder eine Überschußeinspeisung. Es kommt also auf das verwendete
Meßkonzept an.
Wie seht ihr das?
Die Fragen bzgl. "ignoreProducerForPlanning" brauchst du für die Flußgrafik nicht betrachten und dich damit belasten. Hier geht es ja nur darum die Anteile von Erzeugung, Verbrauch, Einspeisung und Speicherung in einer optisch möglichst kompakten Übersicht zusammenzufassen.
Vorschlag damit es nicht so kompliziert wird:
Wir belassen die Darstellung wie sie ist, ersetzen aber die Sonne als Synonym für die PV-Erzeugung durch einen allgemeinen "Generator" sobald zusätzliche Erzeuger Energieanteile liefern. Der Energiefluß stellt dannn die Summe der solaren Anteile + zusätzlicher Erzeuger dar. Sind ausschließlich solare Anteile vorhanden, wechselt die Darstellung wieder zur "Sonne".
Das "Haus" ersetzen wir grafisch durch einen allgemeinen Sammel/Verteilpunkt. Vielleicht einfach nur ein größerer Kreis?
LG,
Heiko
Zitat von: DS_Starter am 28 September 2024, 09:59:06Meiner Meinung nach ist so eine Anlage durch einen eigenen Zähler gekennzeichnet
und hat keine Verbindung zum "Haus"
Das ist schon richtig. Allerdings möchte man natürlich die gesamte Energiesituation gleichzeitig in einer Tabelle bzw. einem Diagramm sehen.
LG
pah
Ich denke die Volleinspeisung könnte man schon mit einbringen. Alleine um zusehen was so passiert. War ich vorher auch nicht von angetan aber mittlereweile sehe ich das eher wie pah und könnte mir das wie folgt vorstellen.
Mit den DC Ladereglern könntew man eventuell genauso vorgehen. Die zielen aber auf die batterie ab.Die sonne könnte da generell durch einen "generator ersetzen und die Producer bekommen Sonne,generator,windrad was auch immer es halt ist.
Wenn man eine Direkteinspeiseanlage zusätzlich zu einer Überschußeinspeiseanlage in einem zusammengehörigen Kontext (sagen wir dem Grundstück) betreibt wäre es m.M. nach ein Muß bzw. ein eindeutiges Identifikationsmerkmal dass die Direkteinspeiseanlage einen eigenen Generator (Module + Inverter) hat.
Weitergedacht wäre es evtl. ein Lösungsansatz wenn im Modul die Möglichkeit gäbe mehrere Inverter anzugeben mit einer optionalen Klassifizierung als Direkteinspeiser. Deren Anteil kann man dann in der Flußgrafik separat darstellen.
Muß man nochmal drüber nachdenken ...
@kask, dein Bild gefällt mir. Sieht gut aus.
Aber auch hier muß ich zunächst wie zuvor geschrieben den Anteil der Direkteinspeisung kennzeichnen/separieren.
Evtl. reicht hier auch die Möglichkeit im Modul mehrere Netzzähler angeben zu können (Direkteinspeisezähler, Hauszähler,...). Das würde auf das erwähnte Meßkonzept einzahlen.
Mit den Ladereglern ist es ähnlich. Ich müßte neben den Attr setupInverterDev auch ein oder mehrere setupSmartloaderDev einführen um deren Energieanteile messen und demzufolge darstellen zu können.
Ich glaube du hast folgenden Satz nicht Verstanden oder ich habe mich nicht genau genug ausgedrückt.
ZitatDas könnte man aber Lösen indem man dem "Producer" eventuell ein "gridonly" attribute spendiert. Damit und einem weiteren "ignoreProducerForPlanning" könnte man dann bei der Consumerschaltung zudem reagieren ob diese erzeugte Leistung mit in die "Haus"-Einspeisung wirkt und als Nutzenergie zur Verfügung steht.
attr "gridonly" sagt das das Icon direkt auf das Netz zeigt.
attr "ignoreProducerForPlanning" gibt an das man den Wert aus dem Erzeuger mit gridonly nur anzeigt und nicht verrechnet um die Consumerplanung zu gestallten.
Sozusagen somit nur eine Anzeige im Flow.
Edit.: @DS_Starter genau so wie gerade von dir geschrieben.
Das Haus symbol wurde ich gegen das "measure_power" ersetzen.
Einen generator habe ich nicht gefunden in den standard icons.
ZitatIch glaube du hast folgenden Satz nicht Verstanden oder ich habe mich nicht genau genug ausgedrückt.
Hatte ich gelesen, verstanden aber im Nachdenken schon wieder vergessen. ;)
Ja, ist eine gute Idee. Trotzdem braucht das Modul weitere "Inverterdevices" weil ich in dem Fall auch eine Zuordnung zu den angegebenen PV-Strings vornehmen muß. Der Direkteinspeiser hat ja auch eigene PV-Generatoren.
Alternativ wäre es vermutlich auch eine praktikable Lösung den erwähnten separierenden Zählersatz umzusetzen. Eine getrennte Betrachtung (mehrere Inverter + PV-Strings) ist allerdings zielführender wenn wir die sicherlich nicht so selten vorkommende Überkonfiguration (String Peakleistung größer als Inverter Maxleistung) berücksichtigen. Dann wäre die Prognose genauer möglich.
Die allgemeinen setupOtherProducerXX bekommen keinerlei PV-Anteile zugeordnet und deren Energie nicht in die Betrachtung PV Vorhersage/realer Ertrag integriert. Deren Anteile sind in der Prognose nicht kalkulierbar.
Stand jetzt würde ich sagen die Einführungen weiterer setupInverterDev und die Einführung eines optionalen "gridonly" wäre ein guter Weg. Dann braucht es aber auch noch einen separaten Netzzähler (Prognose/Ist Auswertung). Ich muß natürlich noch Details lösen wie die Zuordnung von Strings, die momentan alle auf das setupInverterDev einzahlen.
ZitatDas Haus symbol wurde ich gegen das "measure_power" ersetzen.
Einen generator habe ich nicht gefunden in den standard icons.
sani_garden_pump? ... könnte auch als Generator durchgehen.
Das Bild von kask finde ich (sorry...) nicht optimal, denn es enthält mehrere geschlossene Schleifen. Dabei wird nicht so ganz klar, in welcher Richtung der Energiefluss geht. Die Animationen helfen da auch nur dann, wenn man kein statisches Bild betrachtet.
In meinem Diagramm ist das etwas anders gelöst:
1. Keine geschlossenen Schleifen
2. Anzeige der Energieflussrichtung sowohl durch Bewegungsrichtung der Streifen, als auch durch Pfeilrichtung
3. Solar erzeugte Energie: grüne Streifen, Netzenergie: rote Streifen. Schwarze Streifen, wenn kein Fluss.
Frage: Wieso Generator? Ist das ein BHKW?
LG
pah
ZitatFrage: Wieso Generator? Ist das ein BHKW?
Ja, passt nicht zusammen -> "Das Haus symbol wurde ich gegen das "measure_power" ersetzen."
@kask, Das "Haus" ist kein Generator in dem Sinn sondern ein Symbol für einen zentralen Sammel/Verteilpunkt.
Vllt. passt das Icon "flux" als neutrale Darstellung ganz gut.
Der Generator ist gedacht als das jetztige Sonnensymbol. Darüber dann eine Sonne für die Producer.
Oder ein generator für ein Diesel/Schweröl/Gas Aggregat.
Als BHKW würde ich einen Kessel nehmen. Wird ja meist in dem Fall thermisch aufbereitet.
Und als PV halt die sonne.
Das mit den Animationen ist wirklich als statisches Bild doof. Da müßte man dann die Vorzeichen des Gerätes beachten.
Aber ein animierter Pfeil sollte auch schick sein.
ZitatDer Generator ist gedacht als das jetztige Sonnensymbol.
Verstehe. Darüber die Producer, unter anderem die Sonne für PV-Generatoren.
Für die allgemeinen Producer nimm irgendeinen Platzhalter. Ich werde in den setupOtherProducerXX einen Schlüssel vorsehen mit dem jeder User das ihm genehme Symbol einrichten kann, Windrad oder sonst etwas.
Die Pfeile sind ja eigentlich nur im Zentrum interresant da es dort (aber nur) Teilweise bidirektional ist.
Die Producer sind statisch weil da ist ja nur Energie bereitstellen.
Die Comsumer auch da nur Energie verbraucht wird.
So wie in dem Anhang in etwa. Die zwei roten Linien sind bidirektional.
Man könnte aber auch die grünen Linien nehmen, dann wäre es auch nicht mehr in zwei Richtungen.
Screenshot 2024-09-12 203458_3.png
Jetzt ist dein Bild zu sehen.
Würde für mich passen. Den mittleren grünen Pfeil vom Netz zur Batterie kann man sich m.M. nach sparen, denn der Fluß würde zunächst in das "Haus" und dann in die Batterie laufen und nicht direkt. Macht sich grafisch auch besser.
Mit roten Linien würde ich sparsamer umgehen. Es suggeriert etwas schlechtes oder "Gefahr".
Die Linien zu den Verbrauchern würde ich orange (ist etwas kräftiger) nutzen wenn Strom fließt oder grau in Ruhe.
Für die rechten beiden Sonnen (sind sicher Smartloader) muß ich im Modul erst noch Voraussetzungen schaffen wie auch für die Direkteinspeisung.
Ich denke wir werden noch etwas Zeit brauchen für das nächste Level.
Für eine Interimslösung bis dahin wäre es gut den Anteil der allgemeinen Producer in der Flußgrafik in das Haus einfließen zu lassen damit es nicht verwirrt wenn jemand z.B. ein BHKW einbindet.
LG
Ich habe das bei mir stärker differenziert.
- Sonnensymbol: Anzeige der Strahlungsenergie in kW/m² (geeichter Sensor)
- Symbole für Module/Strings: Anzeige Spannung, Leistung
- Symbole für Wechselrichter: Anzeige Leistung, Energie
- Symbole für Zähler - das was wirklich bei EVU ankommt. Das kann auch bei Volleinspeisung durchaus etwas von der Meldung vom WR abweichen. Genau in diesem Moment sagt mein alter WR 0,25 kW, aber der Einspeisezähler meldet 0,26 kW
Übrigens ist bei mir auch die Pfeilrichtung animiert. Bidirektionale Pfeile gibt es nicht.
Und natürlich ist der Netzbezug rot - den will ich ja nicht haben.
LG
pah
P.S.: BHKW - Motorsymbol?
Ich selbst nutze nur Fhem, aber die Flowcard in "Home Assistant" finde ich genial.
Gruß schwatter
Gibt es bei Fronius in ähnlicher Weise. Und zwar in der App noch besser als im Web.
Die Punkte sind animiert, ihr Durchmesser ist mit der Leistung korreliert.
LG
pah
P.S.: Wie man sieht: Speicher ist auf 70% blockiert, Auto lädt gerade aus dem Netz.
P.P.S.: Stören an der Home-Assistant-Darstellung finde ich, dass sowohl beim Speicher, als auch beim Netz zwei Leistungswerte angezeigt werden - von denen einer zwangsläufig immer Null ist. Besser wäre: Nur eine Leistung (evtl. vorzeichenbehaftet), aber zwei Energierwerte (rein und raus)
Victron bietet auf seinem Portal auch eine ähnliche Darstellung an. Die Flußrichtungen sind ebenfalls animiert.
Na, wie wäre es denn, wenn wir die verschiedenen Bilder der FHEM-Community in einer Abstimmung zur Verfügung stellen? Alle anonymisieren und nebeneinander stellen - und alle auffordern, ihre Lieblingsdarstellung zu wählen?
LG
pah
Guter Plan!
Nicht vergessen, wir haben einige Spezifika wie detailiierte Consumer-Ebenen sowie non-PV Producer und in Zukunft auch noch Smartloader und Direkteinspeiser die so manch andere in dieser Form nicht darstellen.
Anregungen kann man sich überall holen, aber gegessen wird zu Hause. ;)
Auch z.B Ring vom DOIF ist ein nettes Element. Hatte die Tage mal mit Floorplan rumgespielt.
Das Bild wirkt wahrscheinlich zum Inhalt überladen. Aber denkt euch den Background weg. Fehlen nur noch schmale animierte Flussrichtungen.
Gruß schwatter
@kask, da die zukünftige Lösung der Grafik noch etwas Zeit benötigt und ich noch einige Implementierungen vornehmen muß ... würdest du die vorhin angesprochende Interimslösung bzgl. Producer relativ kurzfristig hinbekommen?
Wir haben einige parallel laufende Entwicklungen. Ich habe heute die erweiterte Lösung von pah bzgl. des Flächenfaktors in Abhängigkeit vom Sonnenstand eingebaut. Dabei habe ich zusätzlich berücksichtigt, dass die vom DWD (im DWD Device) gelieferte Globalstrahlung sich aus Diffusstrahlung und Direktstrahlung zusammensetzt.
Für die Anteile von Diffusstrahlung und Direktstrahlung an der Globalstrahlung gibt der DWD hier (https://www.dwd.de/DE/leistungen/solarenergie/globalstrahlung.html?nn=16102&lsbId=416798) eine Approximation an die mit eingebaut ist.
Der Anteil der Direktstrahlung wird nun mit einem sonnenstandsabhängigen Flächenfaktor korrigiert.
Ich werde die Implementierung bei mir die kommenden Tage testen und beobachten. Wer es auch verfolgen möchte, kann sich die Version 1.34.0 aus meinem contrib laden. Restart nicht vergessen!
Für den Test ist nur das Model DWD relevant und die Autokorrektur sollte ausgeschaltet werden damit keine Bewölkungskorrekturen etc. angewendet werden (Erst "off", dann "noLearning). Dadurch sieht man das "Rohergebnis" von Prognose/Ergebnis ohne weitere Korrekturen und ohne Lernen.
LG
Die Frage wird sein, wie weit man die Genauigkeit der Vorhersage treiben kann.
Die zitierte grobe Abschätzung der Aufteilung der Globalstrahlung in Direktstrahlung und diffusen Anteil ist nämlich ebenfalls ortsabhängig, wie man hier sehen kann:
https://www.dwd.de/DE/leistungen/solarenergie/strahlungskarten_sum.html
LG
pah
Fehler in Einstellung Azimuth ?
Hi, ich bekomme eine Fehlermeldung zur Konfiguration.
konfiguriert ist set Solarforecast setupStringAzimuth Dach=S Carport=S
das reading dazu sagt setstate Solarforecast 2024-09-29 09:19:04 setupStringAzimuth Dach=S Carport=S
Im Bild ist zu sehen das er aus "S" nun "180" macht
einen anderen Fehler kann ich bei der String Konfiguration nicht sehen.
Bitte um Eure Hilfe
Danke Maik
Moin Maik,
ich hatte in der Prüfung nach den letzten Änderungen noch einen Fehler drin, der aber mit V1.33.1 beseitigt ist (sein sollte). Welche V hast du? Ggf. updaten.
LG
Hi,
version ist von gestern
76_SolarForecast.pm:v1.33.0-s29166/2024-09-26laut FHEM kein update verfügbar
Downloading https://fhem.de/fhemupdate/controls_fhem.txt
fhem
nothing to do...
Downloading https://raw.githubusercontent.com/PatricSperling/FHEM_SST/master/controls_SST.txt
SST
nothing to do...
Gruß Maik
Ja, diese Version ist fehlerhaft.
Komisch, eingecheckt ist die 1.33.1 mit der Revision 29170: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM
Du kannst sie direkt aus dem SVN runterladen und restarten. Aber wenn du jetzt ein normales Update von FHEM ausführen würdest, müsste die V 1.33.1 bei dir installiert werden.
LG,
Heiko
Mmmh :o
Bei mir kam Gestern die V1.33.1 beim Update
(hatte auch vorab aus dem Contrib geladen)
Gruß
300P
Hi,
76_SolarForecast.pm:v1.33.1-s29170/2024-09-27ist jetzt installiert,
es fehlte der fhem restart!
die Fehlermeldung ist weg!
Gruß Maik
Moin pah,
du hast natürlich völlig Recht. Wir werden immer nur eine mehr oder weniger gute Annäherung erreichen.
Es gibt in dem Umfeld immens viele Einflußfaktoren, angefangen damit dass wir davon ausgehen die gelieferte Strahlung in Abhängigkeit von der Bewölkung oder Klarheit/Trübung der Atmosphäre trifft so zu wie prognostiziert.
Selbst wenn wir direkt die Wettermodelle über die API's abfragen gibt es häufig genug Abweichungen von der Realität, auch zwischen den Modellen, z.B. Beispiel DWD ICON und DWD Ensemble.
Wir werden sehen ...
LG,
Heiko
Hallo Heiko,
ich musste ein Backup meines Fhem-Servers einspielen.
Nach 2 Tage habe ich bemerkt, dass mit meiner Konfiguration wohl etwas nicht stimmt:
Oh no 🙁, the system configuration is incorrect. Please check the settings and notes!
String Configuration
Garagendach => azimut: 90, peak: 2.46, tilt: 15
Sueddach => azimut: 180, peak: 12.71, tilt: 40Sueddach ist exakt nach Süden und Garagendach exakt nach Osten ausgerichtet. Ich weiß nicht, wo ich noch anpacken kann.
Viele Grüße Gisbert
Ein list meines Devices (entfernt, Ursache eine fehlerhafte Moduldatei ist, s. nachfolgenden Thread).
Moin Gisbert,
hatten wir gerade hier: #1046.
Der Check ist in 76_SolarForecast.pm:v1.33.0 fehlerhaft -> bitte update nach 1.33.1.
LG,
Heiko
So mal umgeschoben als preview. Die icons mal ausser Acht gelassen.
Edit.:
Ich habe die consumer als producer jetzt in die Grafik genommen um erst einmal nur die grafik anzupassen.
Zumindest weiss ich jetzt wo/was alles was im Modul angepasst werden muss um die einzelnen Elemente zu verschieben.
Ok. Die Icons für die Producer (nur in oberster Zeile denke ich) mache dann flexibel auswählbar.
Ich muss mir mal angucken wie ich Producer anlege. Dann mal richtig verwursten.
Jetzt momentan klapper ich die Consumer durch um Producerdevices anzuzeigen.
Ist ja nicht so hoch kompliziert, etwas Fleissarbeit letztendlich.
Zudem muss ich mal meine fhem2fhem dummies abklappern, es kommt nicht alles was ich benötige.
Im die Grafik richtig zu testen, fehlen mir sich ändernde Werte.
@DS_Starter
geht das mit den "setupOtherProducer01" aktuell?
ich bekomme mit dem modul vom 1.34.0" => "28.09.2024 :
Unknown argument setupOtherProducer01, choose one of consumerImmediatePlanning consumerNewPlanning energyH4Trigger operatingMemory operationMode plantConfiguration powerTrigger pvCorrectionFactor_Auto reset pvCorrectionFactor_05 pvCorrectionFactor_06 pvCorrectionFactor_07 pvCorrectionFactor_08 pvCorrectionFactor_09 pvCorrectionFactor_10 pvCorrectionFactor_11 pvCorrectionFactor_12 pvCorrectionFactor_13 pvCorrectionFactor_14 pvCorrectionFactor_15 pvCorrectionFactor_16 pvCorrectionFactor_17 pvCorrectionFactor_18 pvCorrectionFactor_19 pvCorrectionFactor_20 pvCorrectionFactor_21 setupStringAzimuth setupStringDeclination batteryTrigger
Gerade mit "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm" geladen. Und ja! auch mit "reload 76_SolarForecast.pm" und auch "shutdown restart" keine Änderung.
Hi kask,
ja, ist aber sind aber Attribute setupOtherProducerXX !
Verstehe ich jetzt nicht.
setupOtherProducerXX <Device Name> pcurr=<Readingname>:<Einheit> etotal=<Readingname>:<Einheit>
Legt ein beliebiges Device und dessen Readings zur Lieferung sonstiger Erzeugungswerte fest (z.B. BHKW, Winderzeugung, Notstromaggregat). Es kann auch ein Dummy Device mit entsprechenden Readings sein.
pcurr Reading welches die aktuelle Erzeugung als positiven Wert oder einen Eigenverbrauch (Sonderfall) als negativen Wert liefert
etotal Reading welches die gesamte erzeugte Energie liefert (ein stetig aufsteigender Zähler)
Sollte des Reading die Vorgabe eines stetig aufsteigenden Zählers verletzen, behandelt
SolarForecast diesen Fehler und meldet die aufgetretene Situation durch einen Logeintrag.
Einheit die jeweilige Einheit (W,kW,Wh,kWh)
Beispiel:
attr <name> setupOtherProducer01 windwheel pcurr=total_pac:kW etotal=etotal:kWh
laut hilfe sollte es doch setupOtherProducer01 sein.
Mein Versuch war:
set ForecastDWD setupOtherProducer01 MQTT2_inverter_HM_600_3 pcurr=P_AC:W etotal=YieldTotal:kWh
setupOtherProducer01 stimmt schon, aber
attr <name> setupOtherProducer01 ....
und nicht
set <name> setupOtherProducer01 ....
ups...Wer lesen kann ist klar im Vorteil!
Danke
Hallo zusammen,
in meinem contrib liegt die V 1.34.0 des Moduls.
Ich habe mich dazu entschlossen ein experimentelles Attribut ctrlAreaFactorUsage [fix, flex, flexShared]
einzufügen. Dadurch ist es möglich, das Verhalten der verschiedenen Flächenfaktor-Berechnungen über
eine längeren Zeitraum zu vergleichen und das Ergebnis abzuschätzen. "fix" ist der default und ist die
bisherige Implementierung über die Lookup-Tabelle bzw. nunmehr die Formel/Funktion von pah.
Weiterhin habe ich mit "flex" die Funktion zur Sonnenstand abhängigen Flächenfaktorberechnung von pah
eingebaut. "flexShared" ist eine Erweiterung von "flex" und differenziert zwischen Direktstrahlung und
Diffusstrahlung.
Gerade bei stärkerer Bewölkung und niedrigen Sonnenstand (Herbst/Winter) wird der Anteil der Direktstrahlung auf
die korrigierte Paneelfläche geringer sein. So zumindest ist meine Theorie/Ansicht.
Ob und welche Auswirkung ein "flex" zu "flexShared" bei verschiedenen Lichtverhältnissen hat, wäre zu verfolgen.
Um sich das Verhalten der unterschiedlichen Flächenfaktor Integrationen über längere Zeit anzuschauen ohne
sein produktives Device zu beeinflussen, kann man ganz einfach folgende Schritte vornehmen:
1. kopiere dein produktives Device (nur Model DWD) auf ein neues Device (alternativ einfach ein neues Device anlegen)
2. setze die Angaben setupStringAzimuth, setupStringDeclination neu, schalte Autokorrektur auf "off",
entferne alle evtl. gesetzten Consumer
3. kopiere dieses Device noch zweimal
4. in den nun vorhandenen drei neuen SF-Devices setzt du in jeweils einem das Attr ctrlAreaFactorUsage auf fix,
flex und flexShared. Vorzugsweise, so habe ich es getan, ordnest du diese Devices einem separaten Raum (bei mir
Energie->SolarVergleich) zu.
Nun kann man das Verhalten über einen längeren Zeitraum studieren ohne die Weiterentwicklung des Moduls zu
behindern.
Bitte beachte, dass bei diesen Devices keine Bewölkung oder anderen gelernten Korrekturen auf die Prognose angewendet werden.
Es wird nur die im gewählten DWD-Device gelieferte Globalstrahlung mit dem Flächenfaktor in Variationen behandelt.
Im Verlauf der Beobachtungen wird sich entscheiden welches Verfahren später im Standard verankert wird und ob es
evtl. Sinn macht das Attribut als "advanced Feature" für fortgeschrittene User zu behalten.
Weiterhin sind in dieser Version enthalten:
- Hinweis in Reading pvCorrectionFactor_XX, wenn in der betreffenden Stunde eine KI-Vorhersage verwendet wurde
z.B.
pvCorrectionFactor_11 1.44 (automatic - old factor: 1.04, AI result used, Sun Alt range: 25, Cloud range: 70, Days in range: 3
- Verwendung der KI-Treffer unter Anderem in Abhängigkeit von der Anzahl der verfügbaren Regeln (das zahlt auf ein
Mindestmaß an Laufzeit bzw. Lernstatus ein)
- minor Fixes
Die Version werde ich sicherlich demnächst einchecken weil die beschriebenen Ergänzungen und die
Auswahlmöglichkeiten den Betrieb der produktiven SF-Devices nicht beeinflussen.
Kurzinfo:
(aktuelle Version 1.34.0)
Nach erfolgter Parametrierung - Ergebnis (unter Nutzung DWD-Device aus Contrib) :
setupBatteryDev BatteryDummy pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=19600
setupInverterDev InverterDummy pv=total_pac:kW etotal=etotal:kWh capacity=9500
setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE
setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.025:€ feedprice=0.08123:€
setupRadiationAPI DWD
setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE=0.001
setupWeatherDev1 DWD
=> wahrscheinlich "falsche Fehlermeldungen" -> siehe Screenshot :-X O:-)
PS:
wg. StringPeak mit 0.001 -> PV-String (leider) noch nicht aktiv
Ich sehe nur Warnungen. Was genau meinst du?
Sorry da hast Du recht - hab nur auf das Warndreieck geachtet - lesen bildet..... O:-) :-X
Kein Thema, bei Weiterentwicklungen kann immer mal was daneben gehen. ;) Und ich bin dankbar wenn mitgeadacht/mitgearbeitet wird.
Hallo zusammmen,
ich habe die Version 1.34.0 in meinem contrib für den sofortigen Download upgedated.
Restart nicht vergessen!
Sollten sich im Laufe des Tages keine verhindernden Erkenntnisse ergeben, werde ich die V heute Abend noch einchecken.
In dieser Version ist enthalten:
- Hinweis in den Readings pvCorrectionFactor_XX, wenn in der betreffenden Stunde eine KI-Vorhersage verwendet wurde
z.B.
pvCorrectionFactor_11 1.44 (automatic - old factor: 1.04, AI result used, Sun Alt range: 25, Cloud range: 70, Days in range: 3
- Entscheidung zur Verwendung der KI-Treffer unter Anderem in Abhängigkeit von der Anzahl der verfügbaren Regeln (das zahlt auf ein
Mindestmaß an Laufzeit bzw. Lernstatus ein)
- das (experimentelle) Attribut ctrlAreaFactorUsage mit den Auswahlen: fix, trackFull, trackShared, trackFlex
ACHTUNG: veränderte Auswahlmöglichkeiten zur vorherigen Testversion!
- die Producerattribute 'setupOtherProducerXX' haben einen optionalen Key 'icon' zur Festlegung eines
Icon in der Flußgrafik für diesen Producer
- eine angepasste Interimsversion der Flußgrafik durch kask, herzlichen Dank dafür!
In der Grafik sind die Producer integriert sofern definiert. Weiterhin sind diverse Optimierungen enthalten,
wie z.B. die automatische Freigabe von Raum wenn keine Consumer oder Producer definiert sind.
HINWEIS: durch letzteres kann es in bestehenden Devices notwendig werden die Größe der Flußgrafik mit dem
Attribut flowGraphicSize anzupassen.
- kleinere Fixes und Optimierungen
Meine bisherigen Vergleichsergebnisse zwischen verschiedenen Testdevices mit Einstellungen ctrlAreaFactorUsage fix, trackFull, trackShared
ergeben wenig überraschend einen Genauigkeitsvorsprung von trackFull gegenüber allen anderen Varianten bei einer weniger dichten Bewölkung,
d.h. mit einem hohen Direktstrahlungsanteil.
Bei dichter Bewölkung (ca. ab 80%) ergab trackShared gegenüber trackFull Vorteile. Es ist insofern vernachlässigbar dass eine eingschaltete
Autokorrektur die Korrekturfaktoren permanent neu berechnen würde wie jetzt auch.
Aber wenn wir schon einen Umstieg auf die Berechnnung des Flächenfaktors gemäß Sonnestand (wie von pah dankenswerter Weise kritisch
bemerkt und bereitgestellt 8)) vornehmen, kann ich dieses kleine Detail noch mit berücksichtigen falls es sich manifestiert.
Deswegen gibt es in dem experimentellen Attribut ctrlAreaFactorUsage nun noch die Variante trackFlex, die eine automatische Umschaltung
zwischen trackFull und trackShared vornimmt.
Ich werde die Ergebnisse weiter verfolgen.
Es ist aber schon jetzt sichtbar, dass das Model DWD in einer zukünftigen Version von der aktuellen Methode auf die Methode von pah
umgestellt wird. Ob in der Ausprägung trackFull oder trackFlex sei noch dahingestellt.
Wer bereits jetzt auf eine dieser Varianten umstellen möchte, kann es über das Attribut ctrlAreaFactorUsage bereits jetzt gern tun.
Die Anwendung der bis jetzt gespeicherten Korrekturfaktoren werden sehr wahrscheinlich zunächst zu einer höheren Prognose führen,
welche sich dann langsam angleicht. Wer mag kann deshalb die bisherigen Faktoren mit:
set <name> reset pvCorrection cached
löschen. Der KI-Lernvorrat ist davon nicht betroffen.
LG,
Heiko
Guten Morgen Heiko,
erstmal vielen Dank für deinen unermüdlichen Einsatz für dieses Modul und für Fhem!
Die angehängte Flow-Grafik führt mich zur Frage, wie ich ein Windrad oder einen Genrator im Device definieren kann. Ich habe einen Hybridwechselrichter und einen Microwechselrichter, den ich am Hybridwechselrichter angeschlossen habe. Mangels besseren Wissens habe ich die Leistung beider Wechselrichter in einem neuen Reading vereinigt und dem SolarForecast-Modul zur Verfügung gestellt. Besser wäre es, wenn ich dafür die beiden originalen Readings verwenden könnte - nur weiß ich nicht wie das geht. Geht das nur mit der neuesten Modulversion? Dann würde ich die runterladen und Fhem neu starten.
Viele Grüße Gisbert
Hallo Gisbert,
vielen Dank :).
ZitatIch habe einen Hybridwechselrichter und einen Microwechselrichter, den ich am Hybridwechselrichter angeschlossen habe. Mangels besseren Wissens habe ich die Leistung beider Wechselrichter in einem neuen Reading vereinigt und dem SolarForecast-Modul zur Verfügung gestellt.
Das hast du völlig richtig gemacht, sofern die beiden Leistungen sich in der Realität auch summieren.
Die getrennte Angabe von mehreren Wechselrichtern sowie Smartloadern und ihre Zuordnung zu Paneelstrings muß ich in zukünftigen Versionen noch entwickeln.
Die angesprochenen Producer sind keine PV-Erzeuger, sondern solche Generatoren wie BHKW, Windräder oder Notstromaggragate die manche User in ihrer Anlage integriert haben.
Die Geräte kann man mit den Attributen setupOtherProducerXX in das System holen. Die Attributhilfe erläutert den Kontext.
LG,
Heiko
Schaut auf den ersten Blick in der Anzeige gut aus - Danke !
Auch mit der Grafik :o
A:
Die "Laufgrafik" von der Sonne zum Haus bewegt sich bei mir nicht.
B:
Mein FCU-Icon (SVG) wird "relativ" klein zu den anderen in der Grafik dargestellt.
Gibt es zukünftig einen Parameter für die Größenangabe?
An anderer Stelle (Statuszeile am FCU-Device) wird es (automatisch) etwas größer dargestellt.
C:
Und zur Sicherheit...:
Die neuen Features aktuell "nur" mit dem "DWD" und nicht mit z.B. "OpenMeteoDWDEnsemble-API" nutzen ?
Gruß und Danke für die Weiterentwicklung
300P
Morgen,
für was steht die Null eigentlich unter dem Consumer? Interruptible?
Bzw, manchmal sehe ich auf euren Flows eine Null oder auch nichts.
Gruß schwatter
0.0 = kein Verbrauch am Consumer
0 = flowGraphicShowConsumerRemainTime
Das Attribut zeigt bzw. unterdrückt die Restlaufzeit (in Minuten) der Verbraucher in der Energieflußgrafik. ==>>(default: 1 = Anzeige)
@300P
ZitatA:
Die "Laufgrafik" von der Sonne zum Haus bewegt sich bei mir nicht.
Bei mir bewegt sie sich wie gehabt. Werden wir beobachten bzw. was weitere User melden. Vllt. ein Prob spezifisch bei dir.
ZitatB:
Mein FCU-Icon (SVG) wird "relativ" klein zu den anderen in der Grafik dargestellt.
Gibt es zukünftig einen Parameter für die Größenangabe?
An anderer Stelle (Statuszeile am FCU-Device) wird es (automatisch) etwas größer dargestellt.
Ich/Wir verwenden für die Icons Standard FHEM Funktionen die hier in eine SVG-Grafik eingebettet sind.
Vllt. sehen wir zukünftig eine Anpassungsmöglichkeit. Manche Consumer Icons habe auch eine abweichende Auflösung. Als Workaround vorerst auf ein passenderes Icon ausweichen wenn du magst.
ZitatC:
Und zur Sicherheit...:
Die neuen Features aktuell "nur" mit dem "DWD" und nicht mit z.B. "OpenMeteoDWDEnsemble-API" nutzen ?
Du meinst sicherlich das Attr ctrlAreaFactorUsage. Die Verfahren gelten ausschließlich für das Model DWD.
Alle anderen API's bekommen die genauen Angaben aus setupStringAzimuth und setupStringDeclination sowie ggf. Standortkoordinaten übermittelt und liefern ihre Prognose zurück. Die Inputdaten variieren nach verwendeter API.
LG,
Heiko
@300P,
jetzt habe ich bemerkt, dass deine PV nichts ins Haus liefert, sondern nur Producer. Deswegen läuft die Kette nicht und ist grau.
Das ist ein Anzeigebug den ich fixe.
Danke für die Info.
LG
@300P,
die Version im contrib ist gefixt. Es wird jetzt auch bei dir passen.
LG
Hallo Heiko,
herzlichen Dank für das tolle Modul und die viele Arbeit daran.
Ich verwende die OpenMeteoDWDEnsemble-API mit recht genauen Koordinaten und setupStringAzimuth und setupStringDeclination seit einiger Zeit.
Bis vor kurzem etwa lief alles mit Abweichungen im Bereich 8 bis max.12 / 15%.
Seit der vorletzten Version (die über fhem Update!) habe ich ständig Abweichungen von 35 - >50%.
Meine Konfiguration hat sich nicht geändert.
Hab ich irgendwas vergessen was an Neuerungen eingestellt werden muss?
[code]define Forecast SolarForecast
attr Forecast DbLogExclude .*
attr Forecast DbLogInclude LastHourPVforecast,LastHourPVreal,AllPVforecastsToEvent
attr Forecast affectConsForecastIdentWeekdays 0
attr Forecast ctrlLanguage DE
attr Forecast ctrlShowLink 1
attr Forecast ctrlStatisticReadings todayBatIn,todayBatOut,todayConsumptionForecast,todayGridConsumption,todayGridFeedIn
attr Forecast event-on-change-reading .*
attr Forecast graphicBeam3Content gridconsumption
attr Forecast graphicBeam4Content consumptionForecast
attr Forecast graphicEnergyUnit kWh
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderShow 1
attr Forecast graphicHistoryHour 9
attr Forecast graphicLayoutType double
attr Forecast graphicSelect forecast
attr Forecast room Energie-Strom
attr Forecast setupBatteryDev PV_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W intotal=Summe_Ladung:kWh outtotal=Summe_Entladung:kWh cap=10.26:kWh charge=BatteryChargePercent
attr Forecast setupInverterDev Fronius_Symo pv=PowerFlow_Site_P_PV:W etotal=PowerFlow_Inverters_1_E_Total:Wh capacity=10200
attr Forecast setupInverterStrings Suedseite,Westseite
attr Forecast setupMeterDev Fronius_Symo gcon=Bezug:W contotal=Meter_0_EnergyReal_WAC_Plus_Absolute:Wh gfeedin=Einspeisung feedtotal=Meter_0_EnergyReal_WAC_Plus_Absolute:Wh conprice=powerCost:€ feedprice=0.083:€
attr Forecast setupRadiationAPI OpenMeteoDWDEnsemble-API
attr Forecast setupStringPeak Suedseite=7.66 Westseite=2.2
attr Forecast setupWeatherDev1 OpenMeteoDWDEnsemble-API
attr Forecast verbose 1
# FUUID 66a51bf6-f33f-b48a-2d9c-2d6a9858b0934dcd
# FVERSION 76_SolarForecast.pm:v1.33.1-s29170/2024-09-27
# LCACHEFILE last write time: 12:13:08 whole Operating Memory
# MODE Automatic - next Cycletime: 12:20:07
# MODEL OpenMeteoDWDEnsembleAPI
# NAME Forecast
# NR 894
# NTFY_ORDER 50-Forecast
# STATE updated
# TYPE SolarForecast
# eventCount 9277
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL Forecast
# SPGDEV Forecast
# SPGROOM Energie-Strom
# VERSION 1.33.1
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.2
# Helper:
# DBLOG:
# AllPVforecastsToEvent:
# myDbLog:
# TIME 1727906707.10951
# VALUE 0
# LastHourPVforecast:
# myDbLog:
# TIME 1727949604.223
# VALUE 3058
# LastHourPVreal:
# myDbLog:
# TIME 1727949604.223
# VALUE 477
# OLDREADINGS:
# READINGS:
# 2024-10-03 12:18:57 Current_AutarkyRate 100 %
# 2024-10-03 12:18:57 Current_BatCharge 39.9 %
# 2024-10-03 12:18:57 Current_Consumption 551 W
# 2024-10-03 12:18:57 Current_GridConsumption 1 W
# 2024-10-03 12:18:57 Current_GridFeedIn 0 W
# 2024-10-03 12:18:57 Current_PV 1865 W
# 2024-10-03 12:18:57 Current_PowerBatIn 1315 W
# 2024-10-03 12:18:57 Current_PowerBatOut 0 W
# 2024-10-03 12:18:57 Current_SelfConsumption 550 W
# 2024-10-03 12:18:57 Current_SelfConsumptionRate 29 %
# 2024-10-03 12:18:57 Current_Surplus 1314 W
# 2024-10-03 12:00:00 LastHourGridconsumptionReal 6 Wh
# 2024-10-03 12:00:00 LastHourPVforecast 3058 Wh
# 2024-10-03 12:00:00 LastHourPVreal 477 Wh
# 2024-10-03 12:18:57 NextHours_Sum01_PVforecast 2063 Wh
# 2024-10-03 12:18:57 NextHours_Sum02_PVforecast 5193 Wh
# 2024-10-03 12:18:57 NextHours_Sum03_PVforecast 7990 Wh
# 2024-10-03 12:18:57 NextHours_Sum04_ConsumptionForecast 6954 Wh
# 2024-10-03 12:18:57 NextHours_Sum04_PVforecast 8819 Wh
# 2024-10-03 12:18:57 RestOfDayConsumptionForecast 12966 Wh
# 2024-10-03 12:18:57 RestOfDayPVforecast 9608 Wh
# 2024-10-03 00:59:57 Today_Hour01_BatIn 0 Wh
# 2024-10-03 00:59:57 Today_Hour01_BatOut 0 Wh
# 2024-10-03 00:59:57 Today_Hour01_GridConsumption 849 Wh
# 2024-10-03 00:59:57 Today_Hour01_GridFeedIn 849 Wh
# 2024-10-03 00:59:57 Today_Hour01_PVreal 0 Wh
# 2024-10-03 01:59:49 Today_Hour02_BatIn 0 Wh
# 2024-10-03 01:59:49 Today_Hour02_BatOut 0 Wh
# 2024-10-03 01:59:49 Today_Hour02_GridConsumption 289 Wh
# 2024-10-03 01:59:49 Today_Hour02_GridFeedIn 289 Wh
# 2024-10-03 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-10-03 02:59:49 Today_Hour03_BatIn 0 Wh
# 2024-10-03 02:59:49 Today_Hour03_BatOut 0 Wh
# 2024-10-03 02:59:49 Today_Hour03_GridConsumption 296 Wh
# 2024-10-03 02:59:49 Today_Hour03_GridFeedIn 296 Wh
# 2024-10-03 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-10-03 03:59:49 Today_Hour04_BatIn 0 Wh
# 2024-10-03 03:59:49 Today_Hour04_BatOut 0 Wh
# 2024-10-03 03:59:49 Today_Hour04_GridConsumption 363 Wh
# 2024-10-03 03:59:49 Today_Hour04_GridFeedIn 363 Wh
# 2024-10-03 03:59:49 Today_Hour04_PVreal 0 Wh
# 2024-10-03 04:59:49 Today_Hour05_BatIn 0 Wh
# 2024-10-03 04:59:49 Today_Hour05_BatOut 0 Wh
# 2024-10-03 04:59:49 Today_Hour05_GridConsumption 322 Wh
# 2024-10-03 04:59:49 Today_Hour05_GridFeedIn 322 Wh
# 2024-10-03 04:59:49 Today_Hour05_PVreal 0 Wh
# 2024-10-03 05:59:49 Today_Hour06_BatIn 0 Wh
# 2024-10-03 05:59:49 Today_Hour06_BatOut 0 Wh
# 2024-10-03 05:59:49 Today_Hour06_GridConsumption 395 Wh
# 2024-10-03 05:59:49 Today_Hour06_GridFeedIn 395 Wh
# 2024-10-03 05:59:49 Today_Hour06_PVreal 0 Wh
# 2024-10-03 06:59:49 Today_Hour07_BatIn 0 Wh
# 2024-10-03 06:59:49 Today_Hour07_BatOut 0 Wh
# 2024-10-03 06:59:49 Today_Hour07_GridConsumption 291 Wh
# 2024-10-03 06:59:49 Today_Hour07_GridFeedIn 291 Wh
# 2024-10-03 06:59:49 Today_Hour07_PVreal 0 Wh
# 2024-10-03 07:59:57 Today_Hour08_BatIn 0 Wh
# 2024-10-03 07:59:57 Today_Hour08_BatOut 0 Wh
# 2024-10-03 07:59:57 Today_Hour08_GridConsumption 277 Wh
# 2024-10-03 07:59:57 Today_Hour08_GridFeedIn 277 Wh
# 2024-10-03 07:59:57 Today_Hour08_PVforecast 29 Wh
# 2024-10-03 07:59:57 Today_Hour08_PVreal 0 Wh
# 2024-10-03 08:59:49 Today_Hour09_BatIn 300 Wh
# 2024-10-03 08:59:49 Today_Hour09_BatOut 0 Wh
# 2024-10-03 08:59:49 Today_Hour09_GridConsumption 294 Wh
# 2024-10-03 08:59:49 Today_Hour09_GridFeedIn 294 Wh
# 2024-10-03 08:59:49 Today_Hour09_PVforecast 424 Wh
# 2024-10-03 08:59:49 Today_Hour09_PVreal 78 Wh
# 2024-10-03 09:59:49 Today_Hour10_BatIn 200 Wh
# 2024-10-03 09:59:49 Today_Hour10_BatOut 100 Wh
# 2024-10-03 09:59:49 Today_Hour10_GridConsumption 75 Wh
# 2024-10-03 09:59:49 Today_Hour10_GridFeedIn 75 Wh
# 2024-10-03 09:59:49 Today_Hour10_PVforecast 1473 Wh
# 2024-10-03 09:59:49 Today_Hour10_PVreal 434 Wh
# 2024-10-03 10:59:49 Today_Hour11_BatIn 1200 Wh
# 2024-10-03 10:59:49 Today_Hour11_BatOut 0 Wh
# 2024-10-03 10:59:49 Today_Hour11_GridConsumption 4 Wh
# 2024-10-03 10:59:49 Today_Hour11_GridFeedIn 4 Wh
# 2024-10-03 10:59:49 Today_Hour11_PVforecast 1064 Wh
# 2024-10-03 10:59:49 Today_Hour11_PVreal 372 Wh
# 2024-10-03 11:59:49 Today_Hour12_BatIn 1500 Wh
# 2024-10-03 11:59:49 Today_Hour12_BatOut 0 Wh
# 2024-10-03 11:59:49 Today_Hour12_GridConsumption 6 Wh
# 2024-10-03 11:59:49 Today_Hour12_GridFeedIn 6 Wh
# 2024-10-03 11:59:49 Today_Hour12_PVforecast 3058 Wh
# 2024-10-03 11:59:49 Today_Hour12_PVreal 477 Wh
# 2024-10-03 12:18:57 Today_Hour13_BatIn 400 Wh
# 2024-10-03 12:18:57 Today_Hour13_BatOut 0 Wh
# 2024-10-03 12:18:57 Today_Hour13_GridConsumption 1 Wh
# 2024-10-03 12:18:57 Today_Hour13_GridFeedIn 1 Wh
# 2024-10-03 12:18:57 Today_Hour13_PVforecast 1670 Wh
# 2024-10-03 12:18:57 Today_Hour13_PVreal 174 Wh
# 2024-10-03 12:18:57 Today_Hour14_PVforecast 2913 Wh
# 2024-10-03 12:18:57 Today_Hour15_PVforecast 3597 Wh
# 2024-10-03 12:18:57 Today_Hour16_PVforecast 1071 Wh
# 2024-10-03 12:18:57 Today_Hour17_PVforecast 306 Wh
# 2024-10-03 12:18:57 Today_Hour18_PVforecast 473 Wh
# 2024-10-03 12:18:57 Today_Hour19_PVforecast 107 Wh
# 2024-10-03 12:18:57 Today_MaxPVforecast 3597 Wh
# 2024-10-03 12:18:57 Today_MaxPVforecastTime 2024-10-03 14:00:00
# 2024-10-03 12:18:57 Today_PVforecast 16185 Wh
# 2024-10-03 12:18:57 Today_PVreal 1535 Wh
# 2024-10-03 12:18:57 Today_SunRise 07:25
# 2024-10-03 12:18:57 Today_SunSet 18:50
# 2024-10-03 12:18:57 Tomorrow_ConsumptionForecast 17620 Wh
# 2024-10-03 12:18:57 Tomorrow_PVforecast 24389 Wh
# 2024-10-03 12:18:57 Tomorrow_SunRise 07:26
# 2024-10-03 12:18:57 Tomorrow_SunSet 18:47
# 2024-10-03 12:18:57 nextCycletime 12:20:07
# 2024-10-03 12:06:08 nextRadiationAPICall nach 03.10.2024 12:21:08
# 2024-10-03 09:00:04 pvCorrectionFactor_09 0.59 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 85, Days in range: 1)
# 2024-10-03 09:00:04 pvCorrectionFactor_09_autocalc done
# 2024-10-03 10:00:04 pvCorrectionFactor_10 0.65 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 90, Days in range: 1)
# 2024-10-03 10:00:04 pvCorrectionFactor_10_autocalc done
# 2024-10-03 11:00:04 pvCorrectionFactor_11 0.21 (automatic - old factor: 0.59, Sun Alt range: 25, Cloud range: 75, Days in range: 2)
# 2024-10-03 11:00:04 pvCorrectionFactor_11_autocalc done
# 2024-10-03 12:00:04 pvCorrectionFactor_12 0.58 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 75, Days in range: 1)
# 2024-10-03 12:00:04 pvCorrectionFactor_12_autocalc done
# 2024-10-03 12:18:57 pvCorrectionFactor_Auto on_complex_ai
# 2024-09-27 17:30:39 setupStringAzimuth Suedseite=0 Westseite=90
# 2024-07-27 19:53:01 setupStringDeclination Suedseite=35 Westseite=60
# 2024-10-03 12:18:58 state updated
# 2024-10-03 12:18:57 statistic_todayBatIn 3600.0 Wh
# 2024-10-03 12:18:57 statistic_todayBatOut 100.0 Wh
# 2024-10-03 00:59:57 statistic_todayConsumptionForecast_01 458 Wh
# 2024-10-03 01:59:49 statistic_todayConsumptionForecast_02 408 Wh
# 2024-10-03 02:59:49 statistic_todayConsumptionForecast_03 382 Wh
# 2024-10-03 03:59:49 statistic_todayConsumptionForecast_04 403 Wh
# 2024-10-03 04:59:49 statistic_todayConsumptionForecast_05 457 Wh
# 2024-10-03 05:59:49 statistic_todayConsumptionForecast_06 543 Wh
# 2024-10-03 06:59:49 statistic_todayConsumptionForecast_07 400 Wh
# 2024-10-03 07:59:57 statistic_todayConsumptionForecast_08 284 Wh
# 2024-10-03 08:59:49 statistic_todayConsumptionForecast_09 286 Wh
# 2024-10-03 09:59:49 statistic_todayConsumptionForecast_10 902 Wh
# 2024-10-03 10:59:49 statistic_todayConsumptionForecast_11 879 Wh
# 2024-10-03 11:59:49 statistic_todayConsumptionForecast_12 885 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_13 626 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_14 1258 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_15 2384 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_16 2232 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_17 2060 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_18 1435 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_19 -645 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_20 765 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_21 688 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_22 647 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_23 547 Wh
# 2024-10-03 12:18:57 statistic_todayConsumptionForecast_24 523 Wh
# 2024-10-03 12:18:57 statistic_todayGridConsumption 3462.0 Wh
# 2024-10-03 12:18:57 statistic_todayGridFeedIn 3462.0 Wh
#
setstate Forecast updated
setstate Forecast 2024-09-30 09:34:17 .associatedWith Fronius_Symo PV_Batterie
setstate Forecast 2024-10-03 12:18:57 .lastupdateForecastValues 1727950737
setstate Forecast 2024-10-03 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate Forecast 2024-10-03 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate Forecast 2024-10-03 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate Forecast 2024-10-03 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate Forecast 2024-10-03 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate Forecast 2024-10-03 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate Forecast 2024-10-03 04:00:04 .pvCorrectionFactor_04_apipercentil done
setstate Forecast 2024-10-03 04:00:04 .pvCorrectionFactor_04_cloudcover done
setstate Forecast 2024-10-03 05:00:04 .pvCorrectionFactor_05_apipercentil done
setstate Forecast 2024-10-03 05:00:04 .pvCorrectionFactor_05_cloudcover done
setstate Forecast 2024-10-03 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate Forecast 2024-10-03 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate Forecast 2024-10-03 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate Forecast 2024-10-03 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate Forecast 2024-10-03 08:00:04 .pvCorrectionFactor_08_apipercentil done
setstate Forecast 2024-10-03 08:00:04 .pvCorrectionFactor_08_cloudcover done
setstate Forecast 2024-10-03 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate Forecast 2024-10-03 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate Forecast 2024-10-03 10:00:04 .pvCorrectionFactor_10_apipercentil done
setstate Forecast 2024-10-03 10:00:04 .pvCorrectionFactor_10_cloudcover done
setstate Forecast 2024-10-03 11:00:04 .pvCorrectionFactor_11_apipercentil done
setstate Forecast 2024-10-03 11:00:04 .pvCorrectionFactor_11_cloudcover done
setstate Forecast 2024-10-03 12:00:04 .pvCorrectionFactor_12_apipercentil done
setstate Forecast 2024-10-03 12:00:04 .pvCorrectionFactor_12_cloudcover done
setstate Forecast 2024-10-03 12:18:57 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Forecast 2024-10-03 01:00:04 .signaldone_01 done
setstate Forecast 2024-10-03 02:00:04 .signaldone_02 done
setstate Forecast 2024-10-03 03:00:04 .signaldone_03 done
setstate Forecast 2024-10-03 04:00:04 .signaldone_04 done
setstate Forecast 2024-10-03 05:00:04 .signaldone_05 done
setstate Forecast 2024-10-03 06:00:04 .signaldone_06 done
setstate Forecast 2024-10-03 07:00:04 .signaldone_07 done
setstate Forecast 2024-10-03 08:00:04 .signaldone_08 done
setstate Forecast 2024-10-03 09:00:04 .signaldone_09 done
setstate Forecast 2024-10-03 10:00:04 .signaldone_10 done
setstate Forecast 2024-10-03 11:00:04 .signaldone_11 done
setstate Forecast 2024-10-03 12:00:04 .signaldone_12 done
setstate Forecast 2024-10-03 12:18:57 Current_AutarkyRate 100 %
setstate Forecast 2024-10-03 12:18:57 Current_BatCharge 39.9 %
setstate Forecast 2024-10-03 12:18:57 Current_Consumption 551 W
setstate Forecast 2024-10-03 12:18:57 Current_GridConsumption 1 W
setstate Forecast 2024-10-03 12:18:57 Current_GridFeedIn 0 W
setstate Forecast 2024-10-03 12:18:57 Current_PV 1865 W
setstate Forecast 2024-10-03 12:18:57 Current_PowerBatIn 1315 W
setstate Forecast 2024-10-03 12:18:57 Current_PowerBatOut 0 W
setstate Forecast 2024-10-03 12:18:57 Current_SelfConsumption 550 W
setstate Forecast 2024-10-03 12:18:57 Current_SelfConsumptionRate 29 %
setstate Forecast 2024-10-03 12:18:57 Current_Surplus 1314 W
setstate Forecast 2024-10-03 12:00:00 LastHourGridconsumptionReal 6 Wh
setstate Forecast 2024-10-03 12:00:00 LastHourPVforecast 3058 Wh
setstate Forecast 2024-10-03 12:00:00 LastHourPVreal 477 Wh
setstate Forecast 2024-10-03 12:18:57 NextHours_Sum01_PVforecast 2063 Wh
setstate Forecast 2024-10-03 12:18:57 NextHours_Sum02_PVforecast 5193 Wh
setstate Forecast 2024-10-03 12:18:57 NextHours_Sum03_PVforecast 7990 Wh
setstate Forecast 2024-10-03 12:18:57 NextHours_Sum04_ConsumptionForecast 6954 Wh
setstate Forecast 2024-10-03 12:18:57 NextHours_Sum04_PVforecast 8819 Wh
setstate Forecast 2024-10-03 12:18:57 RestOfDayConsumptionForecast 12966 Wh
setstate Forecast 2024-10-03 12:18:57 RestOfDayPVforecast 9608 Wh
setstate Forecast 2024-10-03 00:59:57 Today_Hour01_BatIn 0 Wh
setstate Forecast 2024-10-03 00:59:57 Today_Hour01_BatOut 0 Wh
setstate Forecast 2024-10-03 00:59:57 Today_Hour01_GridConsumption 849 Wh
setstate Forecast 2024-10-03 00:59:57 Today_Hour01_GridFeedIn 849 Wh
setstate Forecast 2024-10-03 00:59:57 Today_Hour01_PVreal 0 Wh
setstate Forecast 2024-10-03 01:59:49 Today_Hour02_BatIn 0 Wh
setstate Forecast 2024-10-03 01:59:49 Today_Hour02_BatOut 0 Wh
setstate Forecast 2024-10-03 01:59:49 Today_Hour02_GridConsumption 289 Wh
setstate Forecast 2024-10-03 01:59:49 Today_Hour02_GridFeedIn 289 Wh
setstate Forecast 2024-10-03 01:59:49 Today_Hour02_PVreal 0 Wh
setstate Forecast 2024-10-03 02:59:49 Today_Hour03_BatIn 0 Wh
setstate Forecast 2024-10-03 02:59:49 Today_Hour03_BatOut 0 Wh
setstate Forecast 2024-10-03 02:59:49 Today_Hour03_GridConsumption 296 Wh
setstate Forecast 2024-10-03 02:59:49 Today_Hour03_GridFeedIn 296 Wh
setstate Forecast 2024-10-03 02:59:49 Today_Hour03_PVreal 0 Wh
setstate Forecast 2024-10-03 03:59:49 Today_Hour04_BatIn 0 Wh
setstate Forecast 2024-10-03 03:59:49 Today_Hour04_BatOut 0 Wh
setstate Forecast 2024-10-03 03:59:49 Today_Hour04_GridConsumption 363 Wh
setstate Forecast 2024-10-03 03:59:49 Today_Hour04_GridFeedIn 363 Wh
setstate Forecast 2024-10-03 03:59:49 Today_Hour04_PVreal 0 Wh
setstate Forecast 2024-10-03 04:59:49 Today_Hour05_BatIn 0 Wh
setstate Forecast 2024-10-03 04:59:49 Today_Hour05_BatOut 0 Wh
setstate Forecast 2024-10-03 04:59:49 Today_Hour05_GridConsumption 322 Wh
setstate Forecast 2024-10-03 04:59:49 Today_Hour05_GridFeedIn 322 Wh
setstate Forecast 2024-10-03 04:59:49 Today_Hour05_PVreal 0 Wh
setstate Forecast 2024-10-03 05:59:49 Today_Hour06_BatIn 0 Wh
setstate Forecast 2024-10-03 05:59:49 Today_Hour06_BatOut 0 Wh
setstate Forecast 2024-10-03 05:59:49 Today_Hour06_GridConsumption 395 Wh
setstate Forecast 2024-10-03 05:59:49 Today_Hour06_GridFeedIn 395 Wh
setstate Forecast 2024-10-03 05:59:49 Today_Hour06_PVreal 0 Wh
setstate Forecast 2024-10-03 06:59:49 Today_Hour07_BatIn 0 Wh
setstate Forecast 2024-10-03 06:59:49 Today_Hour07_BatOut 0 Wh
setstate Forecast 2024-10-03 06:59:49 Today_Hour07_GridConsumption 291 Wh
setstate Forecast 2024-10-03 06:59:49 Today_Hour07_GridFeedIn 291 Wh
setstate Forecast 2024-10-03 06:59:49 Today_Hour07_PVreal 0 Wh
setstate Forecast 2024-10-03 07:59:57 Today_Hour08_BatIn 0 Wh
setstate Forecast 2024-10-03 07:59:57 Today_Hour08_BatOut 0 Wh
setstate Forecast 2024-10-03 07:59:57 Today_Hour08_GridConsumption 277 Wh
setstate Forecast 2024-10-03 07:59:57 Today_Hour08_GridFeedIn 277 Wh
setstate Forecast 2024-10-03 07:59:57 Today_Hour08_PVforecast 29 Wh
setstate Forecast 2024-10-03 07:59:57 Today_Hour08_PVreal 0 Wh
setstate Forecast 2024-10-03 08:59:49 Today_Hour09_BatIn 300 Wh
setstate Forecast 2024-10-03 08:59:49 Today_Hour09_BatOut 0 Wh
setstate Forecast 2024-10-03 08:59:49 Today_Hour09_GridConsumption 294 Wh
setstate Forecast 2024-10-03 08:59:49 Today_Hour09_GridFeedIn 294 Wh
setstate Forecast 2024-10-03 08:59:49 Today_Hour09_PVforecast 424 Wh
setstate Forecast 2024-10-03 08:59:49 Today_Hour09_PVreal 78 Wh
setstate Forecast 2024-10-03 09:59:49 Today_Hour10_BatIn 200 Wh
setstate Forecast 2024-10-03 09:59:49 Today_Hour10_BatOut 100 Wh
setstate Forecast 2024-10-03 09:59:49 Today_Hour10_GridConsumption 75 Wh
setstate Forecast 2024-10-03 09:59:49 Today_Hour10_GridFeedIn 75 Wh
setstate Forecast 2024-10-03 09:59:49 Today_Hour10_PVforecast 1473 Wh
setstate Forecast 2024-10-03 09:59:49 Today_Hour10_PVreal 434 Wh
setstate Forecast 2024-10-03 10:59:49 Today_Hour11_BatIn 1200 Wh
setstate Forecast 2024-10-03 10:59:49 Today_Hour11_BatOut 0 Wh
setstate Forecast 2024-10-03 10:59:49 Today_Hour11_GridConsumption 4 Wh
setstate Forecast 2024-10-03 10:59:49 Today_Hour11_GridFeedIn 4 Wh
setstate Forecast 2024-10-03 10:59:49 Today_Hour11_PVforecast 1064 Wh
setstate Forecast 2024-10-03 10:59:49 Today_Hour11_PVreal 372 Wh
setstate Forecast 2024-10-03 11:59:49 Today_Hour12_BatIn 1500 Wh
setstate Forecast 2024-10-03 11:59:49 Today_Hour12_BatOut 0 Wh
setstate Forecast 2024-10-03 11:59:49 Today_Hour12_GridConsumption 6 Wh
setstate Forecast 2024-10-03 11:59:49 Today_Hour12_GridFeedIn 6 Wh
setstate Forecast 2024-10-03 11:59:49 Today_Hour12_PVforecast 3058 Wh
setstate Forecast 2024-10-03 11:59:49 Today_Hour12_PVreal 477 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour13_BatIn 400 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour13_BatOut 0 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour13_GridConsumption 1 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour13_GridFeedIn 1 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour13_PVforecast 1670 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour13_PVreal 174 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour14_PVforecast 2913 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour15_PVforecast 3597 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour16_PVforecast 1071 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour17_PVforecast 306 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour18_PVforecast 473 Wh
setstate Forecast 2024-10-03 12:18:57 Today_Hour19_PVforecast 107 Wh
setstate Forecast 2024-10-03 12:18:57 Today_MaxPVforecast 3597 Wh
setstate Forecast 2024-10-03 12:18:57 Today_MaxPVforecastTime 2024-10-03 14:00:00
setstate Forecast 2024-10-03 12:18:57 Today_PVforecast 16185 Wh
setstate Forecast 2024-10-03 12:18:57 Today_PVreal 1535 Wh
setstate Forecast 2024-10-03 12:18:57 Today_SunRise 07:25
setstate Forecast 2024-10-03 12:18:57 Today_SunSet 18:50
setstate Forecast 2024-10-03 12:18:57 Tomorrow_ConsumptionForecast 17620 Wh
setstate Forecast 2024-10-03 12:18:57 Tomorrow_PVforecast 24389 Wh
setstate Forecast 2024-10-03 12:18:57 Tomorrow_SunRise 07:26
setstate Forecast 2024-10-03 12:18:57 Tomorrow_SunSet 18:47
setstate Forecast 2024-10-03 12:18:57 nextCycletime 12:20:07
setstate Forecast 2024-10-03 12:06:08 nextRadiationAPICall nach 03.10.2024 12:21:08
setstate Forecast 2024-10-03 09:00:04 pvCorrectionFactor_09 0.59 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 85, Days in range: 1)
setstate Forecast 2024-10-03 09:00:04 pvCorrectionFactor_09_autocalc done
setstate Forecast 2024-10-03 10:00:04 pvCorrectionFactor_10 0.65 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 90, Days in range: 1)
setstate Forecast 2024-10-03 10:00:04 pvCorrectionFactor_10_autocalc done
setstate Forecast 2024-10-03 11:00:04 pvCorrectionFactor_11 0.21 (automatic - old factor: 0.59, Sun Alt range: 25, Cloud range: 75, Days in range: 2)
setstate Forecast 2024-10-03 11:00:04 pvCorrectionFactor_11_autocalc done
setstate Forecast 2024-10-03 12:00:04 pvCorrectionFactor_12 0.58 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 75, Days in range: 1)
setstate Forecast 2024-10-03 12:00:04 pvCorrectionFactor_12_autocalc done
setstate Forecast 2024-10-03 12:18:57 pvCorrectionFactor_Auto on_complex_ai
setstate Forecast 2024-09-27 17:30:39 setupStringAzimuth Suedseite=0 Westseite=90
setstate Forecast 2024-07-27 19:53:01 setupStringDeclination Suedseite=35 Westseite=60
setstate Forecast 2024-10-03 12:18:58 state updated
setstate Forecast 2024-10-03 12:18:57 statistic_todayBatIn 3600.0 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayBatOut 100.0 Wh
setstate Forecast 2024-10-03 00:59:57 statistic_todayConsumptionForecast_01 458 Wh
setstate Forecast 2024-10-03 01:59:49 statistic_todayConsumptionForecast_02 408 Wh
setstate Forecast 2024-10-03 02:59:49 statistic_todayConsumptionForecast_03 382 Wh
setstate Forecast 2024-10-03 03:59:49 statistic_todayConsumptionForecast_04 403 Wh
setstate Forecast 2024-10-03 04:59:49 statistic_todayConsumptionForecast_05 457 Wh
setstate Forecast 2024-10-03 05:59:49 statistic_todayConsumptionForecast_06 543 Wh
setstate Forecast 2024-10-03 06:59:49 statistic_todayConsumptionForecast_07 400 Wh
setstate Forecast 2024-10-03 07:59:57 statistic_todayConsumptionForecast_08 284 Wh
setstate Forecast 2024-10-03 08:59:49 statistic_todayConsumptionForecast_09 286 Wh
setstate Forecast 2024-10-03 09:59:49 statistic_todayConsumptionForecast_10 902 Wh
setstate Forecast 2024-10-03 10:59:49 statistic_todayConsumptionForecast_11 879 Wh
setstate Forecast 2024-10-03 11:59:49 statistic_todayConsumptionForecast_12 885 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_13 626 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_14 1258 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_15 2384 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_16 2232 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_17 2060 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_18 1435 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_19 -645 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_20 765 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_21 688 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_22 647 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_23 547 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayConsumptionForecast_24 523 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayGridConsumption 3462.0 Wh
setstate Forecast 2024-10-03 12:18:57 statistic_todayGridFeedIn 3462.0 Wh
[/code]
LG WDS
Hallo Dieter,
nein, für die OpenMeteoDWDEnsemble-API ist nichts einzustellen oder zu verändern.
Auch bei meinen Instanzen mit den OpenMeteo.*-APIs hat sich Prognose verschlechtert in den letzten Tagen.
Hier haben die Modelle einfach nicht die real eingetretenen Daten geliefert.
Dazu kommt, je nach Laufzeit des SF-Devices, dass evtl. noch keine durchschnittlichen Korrekturfaktoren vorhanden sind die einen gewissen Ausgleich herbeiführen.
Du siehst es zb. an deinen Readings:
# 2024-10-03 09:00:04 pvCorrectionFactor_09 0.59 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 85, Days in range: 1)
# 2024-10-03 09:00:04 pvCorrectionFactor_09_autocalc done
# 2024-10-03 10:00:04 pvCorrectionFactor_10 0.65 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 90, Days in range: 1)
# 2024-10-03 10:00:04 pvCorrectionFactor_10_autocalc done
# 2024-10-03 11:00:04 pvCorrectionFactor_11 0.21 (automatic - old factor: 0.59, Sun Alt range: 25, Cloud range: 75, Days in range: 2)
# 2024-10-03 11:00:04 pvCorrectionFactor_11_autocalc done
# 2024-10-03 12:00:04 pvCorrectionFactor_12 0.58 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 75, Days in range: 1)
# 2024-10-03 12:00:04 pvCorrectionFactor_12_autocalc done
old factor: 1 (Days in range: 1) bedeutet, dass zu dieser Stunde der originale Prognosewert ohne Korrektur verwendet wurde. Sollte es demnächst zu einer ähnlichen Wetterlage (in der Stunde) kommen, wird der neue Faktor, z.B. 0.65, verwendet um die Prognose anzupassen. Der Faktor wird dann wieder mit dem Ergebnis angepasst und so weiter etc.
LG
Zitat von: DS_Starter am 03 Oktober 2024, 12:12:21@300P,
die Version im contrib ist gefixt. Es wird jetzt auch bei dir passen.
LG
Hallo @DS_Starter,
ja - sieht jetzt besser aus.👍
LG
Zitat von: DS_Starter am 03 Oktober 2024, 12:52:28old factor: 1 (Days in range: 1) bedeutet, dass zu dieser Stunde der originale Prognosewert ohne Korrektur verwendet wurde. Sollte es demnächst zu einer ähnlichen Wetterlage (in der Stunde) kommen, wird der neue Faktor, z.B. 0.65, verwendet um die Prognose anzupassen. Der Faktor wird dann wieder mit dem Ergebnis angepasst und so weiter etc.
Das stimmt aber ich habe noch ein ganz anderes Problem erkannt (und hoffentlich) behoben:
Meine Menge erzeugten Solarstrom ermittle ich aus dem Fronius und drei nachgeschalteten ElectricityCalculatoren vom Sailor.
Damit sind alle Statistikdaten (Erzeugung, Einspeisung, Bezug) vorhanden und eingentlich alles ok nur:
Wenn man alle 15 Sek den Fronius ausliest und dann den ElectricityCalculator triggert, kommt reichlich Unsinn heraus.
Das kann der irgendwie gar-nicht ab. Einmal pro Minute und alles läuft total richtig und sauber.
Also Fehler wohl bei mir - Danke für die schnelle Antwort.
LG WDS
Die Producer Icons kann man sich nun wie die Consumer Icons nach Wunsch einfärben.
Ist der Producer inaktiv, d.h. er erzeugt keine Energie, wird sein Icon identisch zu der Kettendarstellung grau gefärbt.
Update liegt im contrib.
LG
Zur Info:
Wenn meine FCU (Producer01) sich regeneriert, wird ein Verbrauch 0.0 Watt angezeigt - RICHTIG !! - , aber das grafische "Laufband" läuft weiterhin so ("von der Sonne zum Haus"->>gelber Pfeil) als wenn dort weiter etwas produziert wird - falsch - .
setupOtherProducer01 icon=Heizung_FCU_green@green MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
Grund/Ursache:
Da ist ein Modbus-Stromzähler der die Daten liefert. Zählerwerte kommen getrennt als Export- und Import-Zählerstandswert für die 3 Phasen und als Gesamtwerte.
Es gibt während der Regeneration dann logischerweise auch negative Werte für den "Verbrauch" während dieser Zeit in dem Current-Reading "MB_USRW610_004 pcurr=Power_L1__W:W" bis zu -1100 Watt.(Screenshot)
Kann / Sollte das im SF-Modul geregelt / abgefangen werden oder sollte ich die negative Zahl des aktuellen "Verbrauches" im Modbus-Device anderweitig nur "bei positiv" bereitstellen ?
Gruß
300P
ZitatWenn meine FCU (Producer01) sich regeneriert, wird ein Verbrauch 0.0 Watt angezeigt - RICHTIG !! - , aber das grafische "Laufband" läuft weiterhin so ("von der Sonne zum Haus"->>gelber Pfeil) als wenn dort weiter etwas produziert wird - falsch - .
Hatte ich bereits bei mir bemerkt und im contrib upgedated.
Zieh bitte neu.
ZitatKann / Sollte das im SF-Modul geregelt / abgefangen werden oder sollte ich die negative Zahl des aktuellen "Verbrauches" im Modbus-Device anderweitig nur "bei positiv" bereitstellen ?
Es werden nur positive Werte akzeptiert, negative werden vom Modul nicht als produzierte Energie gewertet und abgefangen.
Perfekt - ist damit jetzt weg ;D
Danke dafür 👏
@all,
die neue Version 1.34.0 ist eingecheckt und morgen früh per Update verteilt.
LG,
Heiko
@300P,
mal für mein Verständnis ... was bedeutet die Regeneration der FCU? Kenne mich mit der Technologie nicht aus.
Erklären kann ich es technisch nicht im Detail.
Bei den Brennstoffzellen muss das (automatisch / Vorgabe in Steuerung) zyklisch erfolgen, damit die Anlage nicht zu schnell "verreckt". ;)
Ablauf ist bei mir am Vitovalor300P:
Produktion von Strom und Wärme / Warmwasser mit bis zu ca. 20 -22 Stunden pro Tag.
(Wenn / Falls ich es möchte - meist im Winter)
Danach erfolgt eine Regeneration des Stacks (teuerstes Teil der Anlage) an der Brennstoffzelle mit ca. 1.5 - 2.5 Stunden Dauer.
Erst danach ist eine weitere Produktion dann wieder möglich, wenn alle anderen Voraussetzung gegeben sind.
Auch kann diese Brennstoffzelle nur 1 x am Tag gestartet werden.
Die Brennstoffzellentechnik ist leider sehr störanfällig - so richtig empfehlen kann ich es leider keinem mehr, auch wegen der inzwischen höheren Gaspreise und der hohen Wartung- und Ersatzteilkosten.
Sie wird im kommenden Jahr wohl komplett und vorzeitig bei mir ausgeschaltet und die komplette "Gasheizung mit der Brennstoffzelle" gegen eine LW-Wärmepumpe ausgetauscht.
Gruß
300P
Danke dir für die Erläuterung. Ich war bis dato der Meinung Brennstoffzellen hätten eine große Zukunft.
Liest sich eher nicht so :o
Zitat von: DS_Starter am 03 Oktober 2024, 22:01:44Ich war bis dato der Meinung Brennstoffzellen hätten eine große Zukunft.
Der Meinung bin ich immer noch, aber das hier zu diskutieren ist wohl zu sehr OT.
Zitat von: DS_Starter am 13 März 2024, 09:43:59Nun kann ich mir vorstellen, dass es reizvoll ist in der grafischen Vorhersage auch die zukünftigen Bezugspreise fcx_xx_total abgetragen zu sehen (wenn man es wünscht).
Neben der visuellen Aufbereitung könnten sich Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.
Gibt es dazu schon Ideen?
Im ersten Schritt wäre eine reine Anzeige unter den Balken für PV- oder Verbrauchs-Prognose schon hilfreich.
Guten Morgen,
@TheTrumpeter, wenn du magst mach einfach einen separaten Thread für Brennstoffzellenthematik auf. Ich würde ihn aus Interesse mit verfolgen ohne etwas beitragen zu können.
ZitatGibt es dazu schon Ideen?
Im ersten Schritt wäre eine reine Anzeige unter den Balken für PV- oder Verbrauchs-Prognose schon hilfreich.
Ich habe es ehrlich gesagt ein wenig aus den Augen verloren. Die Anzeige auf der zweiten Balkenebene wäre im Prinzip mit etwas Codeerweiterung möglich.
Gelöst ist aber noch nicht wie die zukünftigen Bezugspreise in das System eingelesen werden können. Es gibt zwar im setupMeterDev einen Schlüssel conprice, der aber nur einen einzelnen Wert (wenn auch dynamisch änderbar) lesen kann.
Es müsste m.M. nach eine Struktur eines Devices ähnlich wie beim DWD Device geben, dessen Readings die Bezugspreise für die nächsten Stunden/Tage bereitstellt. Etwa in der Form:
fcx_0_00
fcx_0_01
fcx_0_02
...
fcx_0_23
fcx_1_00
fcx_1_01
...
fcx_1_23
...
Gibt es ein solches Device? Ich habe leider keinen dynamischen Anbieter und kann deshalb nicht auf Erfahrungen zurückgreifen.
LG
Zitat von: DS_Starter am 04 Oktober 2024, 08:48:43Es müsste m.M. nach eine Struktur eines Devices ähnlich wie beim DWD Device geben, dessen Readings die Bezugspreise für die nächsten Stunden/Tage bereitstellt. Etwa in der Form:
fcx_0_00
fcx_0_01
fcx_0_02
...
fcx_0_23
fcx_1_00
fcx_1_01
...
fcx_1_23
...
Gibt es ein solches Device? Ich habe leider keinen dynamischen Anbieter und kann deshalb nicht auf Erfahrungen zurückgreifen.
Ja, soweit waren wir schonmal, siehe https://forum.fhem.de/index.php?msg=1306985
Danke, war aus meinem Kopf entschwunden. Zu lange her. ::)
Ich habe ein Problem mit der Verbraucherschaltung für meine Wärmepumpe.
Für die WW-Bereitung habe ich 2 Consumer definiert, 1 für "optionalen" Betrieb bei noch höherer Speichertemperatur und ausreichend PV-Überschuss und 1 für verpflichtenden Betrieb bei niedriger Speichertemperatur.
Das Einschalten der WW-Bereitung passiert in beiden Fällen durch das Umschalten des Betriebsmodus der Wärmepumpe aus SolarForecast heraus.
Dabei verhält sich die Wärmepumpe schon seit längerem sporadisch "komisch". Heute habe ich mal die Logs genauer durchforstet und glaube einen Zusammenhang mit dem Einschalten aus SolarForecast zu erkennen.
Es scheint als ob SolarForecast mehrmals hintereinander in kurzen Abständen versucht den Verbraucher einzuschalten. Die Wärmepumpe dürfte das 2x verkraften, falls der Trigger ein 3. Mal kommt, verhält sie sich entsprechend komisch.
Hier die Definition der beiden Verbraucher:
attr mySolarForecast consumer04 Mythz type=heater power=3500 mode=can mintime=60 on="pOpMode manual" asynchron=1 pcurr=cur_power_dhw:kW:1 etotal=sElectrDHWTotal:kWh swstate=HeatingDHW:1:0 icon=sani_water_hot swoncond=Mythz:dhw_temp:4[0-3][.]*\d*|[0-3]\d[.]*\d* auto=solarforecast_dhw_auto notbefore={main::max('08:05', sprintf('%02d:%02d', (split ':', main::sunrise_abs('HORIZON=0',120*60))[0], (split ':', main::sunrise_abs('HORIZON=0',120*60))[1]))} notafter={main::min('17:00', sprintf('%02d:%02d', (split ':', main::sunset_abs('HORIZON=0',-120*60))[0], (split ':', main::sunset_abs('HORIZON=0',-120*60))[1]))} exconfc=1
attr mySolarForecast consumer10 Mythz type=heater power=2500 mode=must mintime=60 on="pOpMode manual" asynchron=1 pcurr=cur_power_dhw:kW:1 etotal=sElectrDHWTotal:kWh swstate=HeatingDHW:1:0 icon=sani_water_hot swoncond=Mythz:dhw_temp:[0-3]\d[.]*\d* auto=solarforecast_dhw_auto notbefore={main::max('08:00', sprintf('%02d:%02d', (split ':', main::sunrise_abs('HORIZON=0',120*60))[0], (split ':', main::sunrise_abs('HORIZON=0',120*60))[1]))} notafter={main::min('17:00', sprintf('%02d:%02d', (split ':', main::sunset_abs('HORIZON=0',-120*60))[0], (split ':', main::sunset_abs('HORIZON=0',-120*60))[1]))} noshow=3Der Status "HeatingDHW", der den Betrieb anzeigt, wird alle 15 Sekunden ausgelesen.
Nun meine Fragen:
In welchen Abständen versucht SolarForecast den Verbraucher einzuschalten?
Kann man eventuell eine Sperrzeit nach den Schaltversuchen definieren? (Ich habe nur die Attribute für die Ein-/Ausschaltverzögerung gefunden.)
Wie könnte ich diese mehrmaligen Einschaltvorgänge verhindern? (Könnte "asynchron=0" hier Abhilfe schaffen?)
ZitatIn welchen Abständen versucht SolarForecast den Verbraucher einzuschalten?
Das passiert bei jedem Zyklus (Attr ctrlInterval). Es wird der Soll/Ist-Zustand verglichen. Wenn Soll mit Ist nicht übereinstimmt wird ein Schaltversuch (On oder Off) gesendet.
ZitatKann man eventuell eine Sperrzeit nach den Schaltversuchen definieren? (Ich habe nur die Attribute für die Ein-/Ausschaltverzögerung gefunden.)
Das würde gehen wenn man sich über eine kleine Routine das Reading welches im Schlüssel "auto" angegeben ist setzt. Das ginge im Attr ctrlUserExitFn nach dem Durchlauf "auto" mit 0 sperren. Den aktuellen Zeitstempel an zentraler Stelle speichern (%data FHEM Wiki (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Wichtige_globale_Variablen_aus_fhem.pl)) und erst wieder auto=1 setzen wenn die gewünschte Sperrezit um ist.
ZitatWie könnte ich diese mehrmaligen Einschaltvorgänge verhindern? (Könnte "asynchron=0" hier Abhilfe schaffen?)
Das könnte in deinem Fall sinnvoll sein weil das Modul im synchronen Fall auf die Antwort des Schaltdevices wartet und nicht weiterläuft, d.h. wenn consumer04 Mythz eingeschaltet wurde, würde consumer10 Mythz nicht versuchen nochmal einzuschalten weil der On-Status dann bereits erkannt wird.
Geht aber nur wenn Mythz auch tatsächlich direkt eine Antwort sendet und nicht erst 2 Minuten "nachdenkt".
@all,
in der Flußgrafik habe ich das Icon für das Haus und die Sonne durch Standard FHEM SVG-Icons ersetzt.
Dadurch kann ich die Sonne zukünftig auch während der Nacht als Mond mit den entsprechenden Phasen aus dem Astro-Modul in der Grafik darstellen.
Liegt als V 1.34.2 in meinem contrib.
LG
Hallo Heiko,
ich hab deine neue Version per reload in Fhem geladen.
Die Flow-Grafik ist jetzt deutlich größer und stark nach links verschoben, so dass nur der rechte Rand dargestellt wird.
Zuvor hatte ich die Größe und Position der Flow-Grafik so angepasst, dass sie mittig dargestellt wird. Offenbar hat sich bei der Flow-Grafik etwas grundlegendes geändert.
Viele Grüße Gisbert
Nabend Gisbert,
ja wie ich im verlinkten Hinweis (#1065) geschrieben hatte, kann es nötig sein die persönliche Einstellung mit dem Attr flowGraphicSize wieder anzupassen. Wenn man die Verschiebung nutzt, dann ebenfalls mit flowGraphicShift justieren.
LG
Hallo Heiko,
danke für den Hinweis, an den ich mich in der Zwischenzeit wieder erinnert hatte. Mit beiden Attributen kann man die Größe und Position der Flow-Grafik nach seinen Wünschen anpassen.
Viele Grüße Gisbert
Das Sonnensymbol wird nun nach dem Sonnenuntergang durch ein Mondphasensymbol ersetzt.
Morgen wird sich zeigen ob die Sonne wieder in der Grafik auftaucht. ;)
Liegt im contrib.
Die Sonne muss da eigentlich weg. Ich habe aber nix brauchbares gefunden ausser eventuell für das Haus "virtualbox" oder "virtualbox-alt" und die Sonne fand ich das "measure_photovoltaic_inst" eigentlich besser.
So ganz zufrieden bin ich aber nicht mit den vorhandenen icons.
Vieleicht kann man die anpassbar machen?
ZitatVieleicht kann man die anpassbar machen?
Das ist eigentlich der Plan hinter den Ersetzungen, dass der User sich die Standardsymbole für Sonne (Mond würde ich lassen wenn es Nacht ist) und das "Haus" ersetzen kann nach seinem Gusto. Das ist im Prinzip kein Problem.
Habe beim Testen nur festgestellt, dass die Auflösungen der FHEM Icons u.U. voneinander abweichen. Das führt zu Verschiebungen der Icons innerhalb der Grafik.
Das passiert auch wenn man die Größe anpassbar gestaltet (hatten wir erst kürzlich). Auch das wäre jetzt kein Problem außer die resultierenden Lageänderungen. Weiß nicht ob/wie man das in den Griff bekommt.
@DS_Starter:
Falls du eine simple Datenquelle für tägliche aktuelle Tibberpreise suchst.....(Thema dynamische Strompreise)
Du benötigst hierzu keinerlei Zugangsdaten!
Dafür kommen die Daten dann auch erst am Morgen so ab 5-7 Uhr aktualisiert dort herein und es sind immer nur die vom aktuellen Tag
Gruß
300P
defmod jm_TibberohneVertrag JsonMod https://tibber.com/de/api/lookup/price-overview?postalCode=hier-deine-PLZ-eintragen
attr jm_TibberohneVertrag comment cron interval 1 Stunde - zu jeder vollen Stunde - 0 * * * *
attr jm_TibberohneVertrag group TibberohneVertrag
attr jm_TibberohneVertrag interval 0 * * * *
attr jm_TibberohneVertrag readingList complete();;
attr jm_TibberohneVertrag room 025_Tibber
attr jm_TibberohneVertrag verbose 2
@all,
in meinem contrib liegt eine Weiterentwicklung.
Attr setupInverterDev -> das Icon und Farbe des Inverters kann jetzt mit dem Key icon=<Icon>[@<Farbe>] angepasst werden.
Zitat von: 300P am 05 Oktober 2024, 11:03:33@DS_Starter:
Falls du eine simple Datenquelle für tägliche aktuelle Tibberpreise suchst.....(Thema dynamische Strompreise)
Du benötigst hierzu keinerlei Zugangsdaten!
Dafür kommen die Daten dann auch erst am Morgen so ab 5-7 Uhr aktualisiert dort herein und es sind immer nur die vom aktuellen Tag
Gruß
300P
defmod jm_TibberohneVertrag JsonMod https://tibber.com/de/api/lookup/price-overview?postalCode=hier-deine-PLZ-eintragen
attr jm_TibberohneVertrag comment cron interval 1 Stunde - zu jeder vollen Stunde - 0 * * * *
attr jm_TibberohneVertrag group TibberohneVertrag
attr jm_TibberohneVertrag interval 0 * * * *
attr jm_TibberohneVertrag readingList complete();;
attr jm_TibberohneVertrag room 025_Tibber
attr jm_TibberohneVertrag verbose 2
Hallo 300P,
echt cool, und es funktioniert (nur der Devicename des Attributs comment ist falsch).
Nur um sicherzustellen:
energy.todayHours.11.priceIncludingVatIst das der Bruttopreis (inkl. Strompreis, Netzentgelt, Steuern, ...), den man bei Tibber für die jeweilige Stunde zahlen muss (hier also 11:00 bis 12:00)?
Viele Grüße Gisbert
Edit:
Nachfrage, wie verhält es sich mit den monatlichen Grundgebühren, Zählermieter, -ablesung, ...?
Edit2:
korrigiert im Zitat von 300P: "attr jm_TibberohneVertrag comment"
Hallo Gisbert,
Danke für den Hinweis 8) - habs korrigiert.
Bitte korrigier es besser auch im Beitrag / dem Zitat von Dir noch an dieser Stelle.
Der Rest ist zwar hier OT...:
OT ON:
In dem jeweiligen Reading "energy.todayHours.xy.priceIncludingVat" ist alles enthalten was je kWh in dieser Stunde und für diese PLZ bei Tibber berechnet werden würde.
In den Reading "monthlyFees.price....." erklärt sich was (für diese PLZ) so an monatlichen Zuschlägen erfolgen würde.
Auch die anderen Readings (alles auf die jeweilige PLZ bezogen) zeigen dir nach Namen gruppiert in etwa wofür "sie" stehen.(inklusive Jahrespreisvergleich mit 3 anderen Stromlieferanten ;D )
OT OFF:
Gruß
300P
@kask,
wegen der FHEM Icon-Größen. Ich habe mir mal drei relevante SVG Icon Vertreter angeschaut.
Alle drei haben verschiedene Größen für width und height in ihrem Code. (Anhang)
Ich habe aktuell keine Ahnung wie man es auf ein identisches Level bringen könnte. Man müßte im Prinzip im SVG-Code des Icons selbst eine Anpassung vornehmen.
Vllt. geht sowas, habe aber keine Idee.
Vllt. doch, die SVG-Datei kann man ja als Text lesen.
LG
Du mustest die skalierung anpassen anhand der Icon größe. Hier 0.15 = 15%.
So ca. Zeile 14102
$ret .= '<g id="producer_'.$prnxnum.'" fill="grey" transform="translate('.$pos_left.',0),scale(0.15)">';
$ret .= "<title>$palias</title>".FW_makeImage($picon, '');
Du Könntest dir aus dem dem generierten Text der FW_makeImage Funktion die Größe extrahieren und dann die skalierung jedesmal auf das icon abstimmen.
so um den dreh:
my $icontxt = FW_makeImage($picon, '');
my $iconscale = meine_super_func_um_die_img_size_zu_extrahieren($icontxt, desired_width, desired_heigth); //regex liegt dir mehr wie mir.
$ret .= '<g id="producer_'.$prnxnum.'" fill="grey" transform="translate('.$pos_left.',0),scale('.$iconscale.')">';
$ret .= "<title>$palias</title>".$icontxt;
Ich hab mir das mal angeguggt.
Man müßte auf eine Höhe von 470px am icon kommen. Davon 10% im flow. Also skalierung 0.1.
Bei einem 250px hohen Icon wäre das: (470/250)*0.1 = 0.19
Bei einem 500px hohen icon wäre das: (470/500)*0.1 = 0.09
sollte so ca. passen.
Das wäre ein Ansatz.
Leider haben die Icons ganz unterschiedliche Einheiten, es gibt px, pt und auch mm.
Ich hatte mir vorgestelt es gäbe in SVG eine css Funktonalität nicht nur für viewBox, sondern auch für <g> Elemente. Scheint aber nicht so zu sein.
Experimentiere gerade mit foreignObject, klappt aber auch nicht so wie ich es erwarte.
Ich schau mal ob ich mit deiner Variante weiterkomme.
Hallo Heiko,
mir ist noch eine kleine Ungereimtheit bei der Tabelle aufgefallen.
Oberhalb der Tabelle ist verhältnismäßig viel ungenutzer Platz.
Der Bereich scheint aus 2 Teilfeldern zu bestehen. Ich hab 2 Screenshots angehängt, hoffentlich kann man halbwegs erkennen, was ich meine.
Am liebsten wäre mir, wenn dieser Bereich minimal klein gehalten werden könnte.
Viele Grüße Gisbert
ich probiere auch gerade, so funktioniert es mit pt values.
für pt:
sub geticonscale($) {
my ($svgstr) = @_;
if ($svgstr =~ /height="(\d+)pt"/) {
return sprintf("%.2f", 47/$1);
} else {
return 0.1;
}
}
im sub _flowGraphic call
if ($flowgprods) {
if ($producercount % 2) {
$producer_start = 350 - ($consDist * (($producercount -1) / 2));
}
else {
$producer_start = 350 - (($consDist / 2) * ($producercount-1));
}
$pos_left = $producer_start + 25;
for my $prnxnum (@producers) {
my $palias = CurrentVal ($hash, 'aliasp'.$prnxnum, 'Producer'.$prnxnum);
my $picon = __substituteIcon ( { hash => $hash, # Icon des Producerdevices
name => $name,
pn => $prnxnum,
pcurr => $ppcurr->{$prnxnum}
}
);
$icontxt = FW_makeImage($picon, '');
$iconscale = geticonscale($icontxt);
##$iconscale = 0.15;
$ret .= '<g id="producer_'.$prnxnum.'" fill="grey" transform="translate('.$pos_left.',0),scale('.$iconscale.')">';
$ret .= "<title>$palias</title>".$icontxt;
$ret .= '</g> ';
$pos_left += $consDist;
}
}
sub geticonscale($) {
my ($svgstr) = @_;
if ($svgstr =~ /height="(\d+)pt"/) {
return sprintf("%.2f", 47/$1);
} elsif ($svgstr =~ /height="(\d+)px"/) {
return sprintf("%.2f", 47/($1*0.96));
} elsif ($svgstr =~ /height="([\d.]+)in"/) {
return sprintf("%.2f", 47/($1*72));
} else {
return 0.1;
}
}
}
edit.:
So geht es mit pt,px & in. So sind die Faktoren. Basis ist die pt(Punkt) Einheit.
Sollte man auch mit den Consumern machen.
Einmal mit der Funktion und einmal ohne angehangen.
Die Icons sind pt, px, in. Von Links nach Rechts.
Ich habe es etwas anders umgesetzt:
################################################################
# berechne Icon Scale auf Bezugsnorm
# widht: 470pt
# height: 470pt
# scale: 0.10
################################################################
sub __normIconScale {
my $name = shift;
my $icon = shift;
my $scale = 0.10; # default Scale
my ($height, $unit) = $icon =~ /height="(\d+\.\d+|\d+)(.*?)"/xs;
return $scale if(!$height);
$scale = $unit eq 'pt' ? 470 * $scale /$height :
$unit eq 'px' ? 470 * $scale /$height * 0.96 :
$unit eq 'in' ? 470 * $scale /$height * 0.0138889 :
$scale;
$scale = sprintf "%.2f", $scale;
return $scale;
}
In der Flowgrafik werden jetzt alle (FHEM) Icons entsprechend behandelt.
Es gibt auch Icons mit mm, das muß noch integriert werden.
Die V liegt im contrib.
Hallo Gisbert,
Zitatmir ist noch eine kleine Ungereimtheit bei der Tabelle aufgefallen.
Oberhalb der Tabelle ist verhältnismäßig viel ungenutzer Platz.
Der Bereich scheint aus 2 Teilfeldern zu bestehen.
Das sieht bei mir sauber aus.
Ist dein Device in einen besonderen Style oder etwas in der Art eingebunden?
LG
Guten Morgen Heiko,
ich nutze am Handy den flex Style (stylesheetPrefix flex). Ich finde die Optik cool. In den vorherigen Versionen deines Moduls war diese Auffälligkeit beim flex Style nicht vorhanden. Bei den "klassischen" Styles ist in der jetzigen Version auch alles ok.
Welchen Style benutzt du auf dem Handy?
Viele Grüße Gisbert
Edit: es sieht so aus, als ob hinter dem Balkendiagramm/Kopfzeilen und der Flow-Grafik eine Tabelle mit 2 Spalten dahinter liegt (eine sehr breite und eine etwas schmalere).
In Millimetern scheint es wie folgt zu sein. Zudem habe ich noch recherchiert und weitere Möglichkeiten entdeckt.
Damit sollte was die Grafik selbst angeht, aber alles mögliche abgedeckt sein.
################################################################
# berechne Icon Scale auf Bezugsnorm
# widht: 470pt
# height: 470pt
# scale: 0.10
################################################################
sub __normIconScale {
my $name = shift;
my $icon = shift;
my $scale = 0.10; # default Scale
my ($height, $unit) = $icon =~ /height="(\d+\.\d+|\d+)(.*?)"/xs;
return $scale if(!$height);
$scale = $unit eq 'pt' ? 470 * $scale /$height :
$unit eq 'px' ? 470 * $scale /$height * 0.96 :
$unit eq 'in' ? 470 * $scale /$height * 0.0138889 :
$unit eq 'mm' ? 470 * $scale /$height * 2.8346 :
$unit eq 'cm' ? 470 * $scale /$height * 28.346 :
$unit eq 'pc' ? 470 * $scale /$height * 12 :
$scale;
$scale = sprintf "%.2f", $scale;
return $scale;
}
Moin Gisbert,
hmmm, an den allgemeinen grafischen Einstellungen ist nichts geändert worden.
Möglicherweise eine Eigenheit des verwendeten Style der mit irgendeinem Detail ein Thema hat.
ZitatWelchen Style benutzt du auf dem Handy?
Eigentlich gar nichts. Wenn ich mal einen Überblick über meine Steuerung brauche benutze ich die App "Fully Kiosk Browser" mit einem Dashboard (Modul Dashboard).
Alle andere mache ich mit meinem Microsoft Surface. Da reicht die normale Browseransicht. Teilweise nutze ich dort F18 Style.
Da muß ich mal versuchen deinen Case nachzustellen.
LG
Moin kask,
danke, baue ich ein.
Ich denke auch, dass wir im Icon-Code die viewBox-Angaben ersetzen müssen mit der Normativgröße.
Da bin ich gerade am testen.
LG
Hm, warum willst Du am standard rumschrauben. Ist doch eine FHEMWEB funktion.
Sollte man da nicht lieber dann an den Author treten um Erweiterungen einzupflegen.
Wenn du jetzt auf Probleme stößt. Haben es Andere dann am Ende auch.
Was ich meine ist folgendes. Beispiel das Windrad Ventilator_wind.svg. Im Original:
width="4.16667in" height="3.77778in" viewBox="0 0 300 272">
Die in rechnen wir auf einen Scale gegenüber dem Normativ von 0.10 bei 470pt um. Passt soweit. Aber die viewBox="0 0 300 272" müsste dann bezogen auf das Zugrunde liegende Normativ von 470pt x 470pt auch so lauten, nämlich viewBox="0 0 470 470".
Meine bisherigen Tests legen das jedenfalls nahe.
Zitat von: kask am 06 Oktober 2024, 09:25:21Hm, warum willst Du am standard rumschrauben. Ist doch eine FHEMWEB funktion.
Sollte man da nicht lieber dann an den Author treten um Erweiterungen einzupflegen.
Wenn du jetzt auf Probleme stößt. Haben es Andere dann am Ende auch.
Hallo kask,
im Prinzip hast du ja recht, nur ist es halt so, dass an dem Style flex seit Jahren nichts mehr gemacht wird, was ich total schade finde.
99% meiner Zeit mit Fhem mache ich am Handy, Laptop nutze ich nur, wenn ich größere Veränderungen mache.
Beim flex Style ist alles schön links/rechtsbündig angeordnet, was bei den klassischen Ansichten nicht gegeben ist. Ich lasse mich aber gerne vom Gegenteil überzeugen, wenn es etwas schönes für kleine Bildschirme gibt.
Viele Grüße Gisbert
@kask, hier mal ein praktisches Beispiel was ich meine.
Der erste Screenshot ist ohne viewBox Anpassung. Die Producer Icons erscheinen mir im Vergleich zu den Verbrauchern zu groß.
Der zweite Screenshot ist mit Anpassung. Hier stimmen die Relationen besser, mal von der Verschiebung abgesehen. Was meinst du dazu?
Hallo, hierzu haben ich eine kleine Anfängerfrage:
Zitat von: DS_Starter am 04 Oktober 2024, 14:24:03ZitatIn welchen Abständen versucht SolarForecast den Verbraucher einzuschalten?
Das passiert bei jedem Zyklus (Attr ctrlInterval). Es wird der Soll/Ist-Zustand verglichen. Wenn Soll mit Ist nicht übereinstimmt wird ein Schaltversuch (On oder Off) gesendet.
Ganz offensichtlich wird mein FHEM Logfile von diesen Schaltvorgängen zugemüllt:
2024.10.06 13:00:21 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:00:21 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on
2024.10.06 13:01:31 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:01:31 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on
2024.10.06 13:02:41 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:02:41 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on
2024.10.06 13:03:51 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:03:51 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on
2024.10.06 13:05:02 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:05:02 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on
2024.10.06 13:06:11 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:06:11 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on
2024.10.06 13:07:22 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:07:22 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on
2024.10.06 13:09:42 3: MQTT2_DEVICE set MQTT2_DVES_159462 off
2024.10.06 13:09:42 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 off
2024.10.06 13:10:52 3: MQTT2_DEVICE set MQTT2_DVES_159462 off
2024.10.06 13:10:52 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 off
2024.10.06 13:12:02 3: MQTT2_DEVICE set MQTT2_DVES_159462 on
2024.10.06 13:12:02 3: MQTT2_DEVICE set MQTT2_zigbee_Plug_4 on Es handelt sich um zwei Heizungen, die bei Überschuss eingeschaltet und bei Mangel wieder ausgeschaltet werden.
Wie kann ich die häufigen Schaltvorgänge oder zumindest die Logeintäge verhindern? Verbose ist 1.
Danke
oelidoc
Hallo oelidoc,
das sieht nach einem Problem in der Erkennung des Schaltstatus aus. Es ist der Schlüssel swstate.
Vermutlich passt der Regex nicht.
Zeig uns mal bitte die Definition der Consumer und das entsprechende Reading (default state) von MQTT2_DVES_159462 und MQTT2_zigbee_Plug_4.
LG
@kask,
ich habe das Verfahren für die Icons nochmal geändert. Es hat mich gestört, dass width und height nicht proportional zueinander angepasst werden.
Deswegen normiere ich jetzt im Icon zur Laufzeit diese Parameter auf das Normativ width:470pt, height:470pt und scale:0.10.
sub __normIconScale {
my $name = shift;
my $icon = shift;
my $hscale = $fgscaledef; # Scale Normativ
my $wscale = $fgscaledef;
my ($width, $wunit) = $icon =~ /width="(\d+\.\d+|\d+)(.*?)"/xs;
my ($height, $hunit) = $icon =~ /height="(\d+\.\d+|\d+)(.*?)"/xs;
return ($hscale, $icon) if(!$width || !$height);
$wscale = $hunit eq 'pt' ? 470 * $wscale / $width :
$hunit eq 'px' ? 470 * $wscale / $width * 0.96 :
$hunit eq 'in' ? 470 * $wscale / $width * 0.0138889 :
$hunit eq 'mm' ? 470 * $wscale / $width * 0.352778 :
$hunit eq 'cm' ? 470 * $wscale / $width * 0.0352778 :
$hunit eq 'pc' ? 470 * $wscale / $width * 0.0833333 :
$wscale;
$hscale = $hunit eq 'pt' ? 470 * $hscale / $height :
$hunit eq 'px' ? 470 * $hscale / $height * 0.96 :
$hunit eq 'in' ? 470 * $hscale / $height * 0.0138889 :
$hunit eq 'mm' ? 470 * $hscale / $height * 0.352778 :
$hunit eq 'cm' ? 470 * $hscale / $height * 0.0352778 :
$hunit eq 'pc' ? 470 * $hscale / $height * 0.0833333 :
$hscale;
$wscale = sprintf "%.2f", $wscale;
$hscale = sprintf "%.2f", $hscale;
my $widthnormpt = (sprintf "%.0f", (470 * (1 + $wscale))).'pt'; # Breite auf Normativ in pt skaliert
my $heightnormpt = (sprintf "%.0f", (470 * (1 + $hscale))).'pt'; # Höhe auf Normativ in pt skaliert
$icon =~ s/width="(.*?)"/width="$widthnormpt"/;
$icon =~ s/height="(.*?)"/height="$heightnormpt"/;
# Log3 ($name, 2, "$name - widthnormpt: $widthnormpt, heightnormpt: $heightnormpt");
return ($fgscaledef, $icon);
}
Damit sind wir jetzt schon sehr gut in der Anpassung wie im Anhang zu sehen. Auch das Problem-Icon "inverter" wird jetzt ordentlich skaliert.
Liegt im contrib.
LG,
Heiko
Okay,
Consumer01
MQTT2_DVES_159462 type=heater power=1500 icon=sani_heating_automatic mode=can pcurr=ENERGY_Power:W on=on off=off auto=1 etotal=ENERGY_Total:kWh mintime=SunPath:60:-65 interruptable=1define MQTT2_DVES_159462 MQTT2_DEVICE DVES_159462
attr MQTT2_DVES_159462 IODev myBroker
attr MQTT2_DVES_159462 alexaName Radiator Küche
attr MQTT2_DVES_159462 alias Cecotec Radiator
attr MQTT2_DVES_159462 autocreate 0
attr MQTT2_DVES_159462 comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/DVES_159462/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr MQTT2_DVES_159462 devStateIcon {my $text = sprintf(" <br> aktuell: %.1f W heute: %.2f kWh <br> gestern: %.3f kWh gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"));; my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");;"<div><a href=\"http://".ReadingsVal($name,"IPAddress","none")." \"target=\"_blank\">".FW_makeImage($onl).'</a> <a href="/fhem?cmd.dummy=set '.$name.' toggle&XHR=1">'.FW_makeImage($light)."</a>$text<b></b>"}
attr MQTT2_DVES_159462 event-on-change-reading state,ENERGY_Power,ENERGY_Current,ENERGY_Voltage:10
attr MQTT2_DVES_159462 genericDeviceType switch
attr MQTT2_DVES_159462 icon sani_heating_automatic
attr MQTT2_DVES_159462 jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 Channel_5:0 HSBColor:0 Color:0
attr MQTT2_DVES_159462 model tasmota_POW
attr MQTT2_DVES_159462 readingList tele/DVES_159462/LWT:.* LWT\
tele/DVES_159462/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_159462/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_159462/INFO.:.* { $EVENT =~ m,^..Info[1-3]..(.+).$, ? json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_159462/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
stat/DVES_159462/POWER1:.* state\
stat/DVES_159462/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_DVES_159462 room Küche,MQTT2_DEVICE
attr MQTT2_DVES_159462 setList off:noArg cmnd/DVES_159462/POWER1 0\
on:noArg cmnd/DVES_159462/POWER1 1\
toggle:noArg cmnd/DVES_159462/POWER1 2
attr MQTT2_DVES_159462 setStateList on off toggle
attr MQTT2_DVES_159462 stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
attr MQTT2_DVES_159462 webCmd :
# CID DVES_159462
# DEF DVES_159462
# FUUID 666b33cc-f33f-74ea-2dc4-c6e8c82ed3be5a5d
# IODev myBroker
# LASTInputDev myBroker
# MSGCNT 445
# NAME MQTT2_DVES_159462
# NR 654
# STATE set_on
# TYPE MQTT2_DEVICE
# eventCount 401
# myBroker_CONN myBroker_192.168.178.xx_xxxxx
# myBroker_MSGCNT 445
# myBroker_TIME 2024-10-06 15:12:13
# JSONMAP:
# Channel_0 0
# Channel_1 0
# Channel_2 0
# Channel_3 0
# Channel_4 0
# Channel_5 0
# Color 0
# Dimmer 0
# HSBColor 0
# POWER1 0
# POWER2 0
# POWER3 0
# POWER4 0
# READINGS:
# 2024-10-06 09:47:07 1 1
# 2024-09-29 19:10:45 BootCount 27
# 2024-10-06 15:11:11 ENERGY_ApparentPower 1359
# 2024-10-06 15:11:11 ENERGY_Current 6.135
# 2024-10-06 15:11:11 ENERGY_Factor 1.00
# 2024-10-06 15:11:11 ENERGY_Period 54
# 2024-10-06 15:11:11 ENERGY_Power 1359
# 2024-10-06 15:11:11 ENERGY_ReactivePower 0
# 2024-10-06 15:11:11 ENERGY_Today 5.359
# 2024-10-06 15:11:11 ENERGY_Total 54.585
# 2024-10-06 15:11:11 ENERGY_TotalStartTime 2024-04-08T16:48:29
# 2024-10-06 15:11:11 ENERGY_Voltage 222
# 2024-10-06 15:11:11 ENERGY_Yesterday 3.544
# 2024-09-29 19:10:45 FallbackTopic cmnd/DVES_159462_fb/
# 2024-09-29 19:10:45 GroupTopic cmnd/tasmotas/
# 2024-10-06 15:11:11 Heap 25
# 2024-09-29 19:10:45 Hostname DVES-159462-5218
# 2024-10-06 11:44:24 IODev myBroker
# 2024-09-29 19:10:45 IPAddress 192.168.xxx.xx
# 2024-10-06 11:44:49 LWT Online
# 2024-10-06 15:11:11 LoadAvg 19
# 2024-09-29 19:10:45 Module Nous A1T
# 2024-10-06 15:11:11 MqttCount 19
# 2024-09-29 19:10:45 RestartReason Power On
# 2024-06-13 20:01:05 SaveData on
# 2024-06-13 20:01:04 SetOption26 on
# 2024-10-06 15:11:11 Sleep 50
# 2024-10-06 15:11:11 SleepMode Dynamic
# 2024-06-13 20:01:03 StateText1 off
# 2024-06-13 20:01:04 StateText2 on
# 2024-06-13 20:01:04 StateText3 toggle
# 2024-06-13 20:01:04 StateText4 hold
# 2024-10-06 15:11:11 Time 2024-10-06T14:11:11
# 2024-10-06 15:11:11 Uptime 6T20:00:32
# 2024-10-06 15:11:11 UptimeSec 590432
# 2024-09-29 19:10:45 Version 14.1.0(release-tasmota)
# 2024-09-29 19:10:45 WebServerMode Admin
# 2024-10-06 15:11:11 Wifi_AP 1
# 2024-10-06 15:11:11 Wifi_BSSId 1C:ED:6F:1D:70:88
# 2024-10-06 15:11:11 Wifi_Channel 1
# 2024-10-06 15:11:11 Wifi_Downtime 0T00:01:53
# 2024-10-06 15:11:11 Wifi_LinkCount 16
# 2024-10-06 15:11:11 Wifi_Mode 11n
# 2024-10-06 15:11:11 Wifi_RSSI 100
# 2024-10-06 15:11:11 Wifi_SSId xxxxxxxx
# 2024-10-06 15:11:11 Wifi_Signal -47
# 2024-06-13 20:01:03 attrTemplateVersion 20210903
# 2024-10-06 15:13:22 state set_on
# 2024-10-06 11:45:21 subscriptions cmnd/DVES_159462/# cmnd/DVES_159462_fb/# cmnd/tasmotas/#
#
setstate MQTT2_DVES_159462 set_on
setstate MQTT2_DVES_159462 2024-10-06 09:47:07 1 1
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 BootCount 27
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_ApparentPower 1359
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Current 6.135
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Factor 1.00
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Period 54
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Power 1359
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_ReactivePower 0
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Today 5.359
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Total 54.585
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_TotalStartTime 2024-04-08T16:48:29
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Voltage 222
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 ENERGY_Yesterday 3.544
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 FallbackTopic cmnd/DVES_159462_fb/
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 GroupTopic cmnd/tasmotas/
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Heap 25
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 Hostname DVES-159462-5218
setstate MQTT2_DVES_159462 2024-10-06 11:44:24 IODev myBroker
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 IPAddress 192.168.178.81
setstate MQTT2_DVES_159462 2024-10-06 11:44:49 LWT Online
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 LoadAvg 19
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 Module Nous A1T
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 MqttCount 19
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 RestartReason Power On
setstate MQTT2_DVES_159462 2024-06-13 20:01:05 SaveData on
setstate MQTT2_DVES_159462 2024-06-13 20:01:04 SetOption26 on
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Sleep 50
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 SleepMode Dynamic
setstate MQTT2_DVES_159462 2024-06-13 20:01:03 StateText1 off
setstate MQTT2_DVES_159462 2024-06-13 20:01:04 StateText2 on
setstate MQTT2_DVES_159462 2024-06-13 20:01:04 StateText3 toggle
setstate MQTT2_DVES_159462 2024-06-13 20:01:04 StateText4 hold
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Time 2024-10-06T14:11:11
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Uptime 6T20:00:32
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 UptimeSec 590432
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 Version 14.1.0(release-tasmota)
setstate MQTT2_DVES_159462 2024-09-29 19:10:45 WebServerMode Admin
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_AP 1
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_BSSId 1C:ED:6F:1D:70:88
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_Channel 1
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_Downtime 0T00:01:53
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_LinkCount 16
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_Mode 11n
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_RSSI 100
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_SSId Funknetz
setstate MQTT2_DVES_159462 2024-10-06 15:11:11 Wifi_Signal -47
setstate MQTT2_DVES_159462 2024-06-13 20:01:03 attrTemplateVersion 20210903
setstate MQTT2_DVES_159462 2024-10-06 15:13:22 state set_on
setstate MQTT2_DVES_159462 2024-10-06 11:45:21 subscriptions cmnd/DVES_159462/# cmnd/DVES_159462_fb/# cmnd/tasmotas/#Consumer07
MQTT2_zigbee_Plug_4 type=heater power=2000 icon=sani_heating_heatpump mode=can pcurr=power:W on=on off=off auto=1 mintime=SunPath:60:-60 interruptable=1define MQTT2_zigbee_Plug_4 MQTT2_DEVICE zigbee_Plug_4
attr MQTT2_zigbee_Plug_4 alexaName Trotec Lüfter
attr MQTT2_zigbee_Plug_4 alias Trotec Lüfter
attr MQTT2_zigbee_Plug_4 devStateIcon {my $light = FW_makeImage(ReadingsVal($name,'state','off'));; my $current = ReadingsVal($name,'current',0);; my $pwr = ReadingsVal($name,'power',0);; my $energy = ReadingsVal($name,'energy',0);; qq(<div> <a href="/fhem?cmd.dummy=set $name toggle&XHR=1">$light</a> Aktuell: $current A Leistung: $pwr W<b></b>)}
attr MQTT2_zigbee_Plug_4 devicetopic zigbee2mqtt/Plug_4
attr MQTT2_zigbee_Plug_4 event-on-change-reading state,current,energy:5,power,voltage:10,linkquality:100
attr MQTT2_zigbee_Plug_4 genericDeviceType switch
attr MQTT2_zigbee_Plug_4 icon sani_heating_heatpump
attr MQTT2_zigbee_Plug_4 model zigbee2mqtt_plug_w_energy_measuring
attr MQTT2_zigbee_Plug_4 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT);; $ret->{state}=lc($ret->{state}) if defined $ret->{state};; return $ret }
attr MQTT2_zigbee_Plug_4 room MQTT2_DEVICE
attr MQTT2_zigbee_Plug_4 setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
off:noArg $DEVICETOPIC/set {"state":"OFF"}\
toggle:noArg $DEVICETOPIC/set {"state":"TOGGLE"}
attr MQTT2_zigbee_Plug_4 setStateList on off toggle
# CID zigbee_Plug_4
# DEF zigbee_Plug_4
# FUUID 639dbfb2-f33f-74ea-de08-489eb498fa11ddbe
# IODev myBroker
# LASTInputDev myBroker
# MSGCNT 985
# NAME MQTT2_zigbee_Plug_4
# NR 602
# STATE off
# TYPE MQTT2_DEVICE
# eventCount 510
# myBroker_CONN myBroker_127.0.0.1_xxxxx
# myBroker_MSGCNT 985
# myBroker_TIME 2024-10-06 15:12:42
# READINGS:
# 2024-10-06 13:58:50 1 0
# 2024-10-06 11:44:24 IODev myBroker
# 2022-12-17 14:10:10 associatedWith MQTT2_zigbee_oelidoc
# 2022-12-17 14:10:51 attrTemplateVersion 20220622
# 2024-10-06 15:12:42 child_lock UNLOCK
# 2024-10-06 15:12:42 countdown 0
# 2024-10-06 15:12:42 current 0
# 2024-10-06 15:12:42 energy 27.26
# 2024-10-06 15:12:42 indicator_mode off/on
# 2024-10-06 15:12:42 linkquality 255
# 2024-10-06 15:12:42 power 0
# 2024-10-06 15:12:42 power_outage_memory restore
# 2024-10-06 15:12:42 state off
# 2024-10-06 15:12:42 update_available true
# 2024-10-06 15:12:42 update_state available
# 2024-10-06 15:12:42 voltage 218.25
#
setstate MQTT2_zigbee_Plug_4 off
setstate MQTT2_zigbee_Plug_4 2024-10-06 13:58:50 1 0
setstate MQTT2_zigbee_Plug_4 2024-10-06 11:44:24 IODev myBroker
setstate MQTT2_zigbee_Plug_4 2022-12-17 14:10:10 associatedWith MQTT2_zigbee_oelidoc
setstate MQTT2_zigbee_Plug_4 2022-12-17 14:10:51 attrTemplateVersion 20220622
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 child_lock UNLOCK
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 countdown 0
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 current 0
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 energy 27.26
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 indicator_mode off/on
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 linkquality 255
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 power 0
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 power_outage_memory restore
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 state off
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 update_available true
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 update_state available
setstate MQTT2_zigbee_Plug_4 2024-10-06 15:12:42 voltage 218.25
Gruß und Dank
oelidoc
@oelidoc,
1. MQTT2_DVES_159462
Das Reading state ist "set_on". Hier ist die Frage ob dieser Status anzeigt dass das Device auf "on" schalten soll, aber es nicht tut oder ob dies der Status für ein reguläres "on" ist.
Im ersteren Fall musst du schauen wieso das Device nicht auf on schaltet und im letzteren Fall würdest du den Key im consumer Attribut setzen:
... swstate=state:.*on.*:.*off.* ...
2. MQTT2_zigbee_Plug_4
Der Status zeigt state "off". Das sollte erkannt werden. Möglicherweise gibt es ein nicht sichtbares Leerzeichen, Steuerzeichen danach. Auch hier wäre vermutlich die Lösung den Key zu setzen:
... swstate=state:.*on.*:.*off.* ...
LG
Hallo Heiko,
Zitat von: DS_Starter am 06 Oktober 2024, 17:31:031. MQTT2_DVES_159462
Das Reading state ist "set_on".
Das habe ich auch bemerkt, kann es aber nicht mehr nachvollziehen. state ist jetzt immer 'on' oder 'off'.
Habe jetzt zweimal
swstate=state:.*on.*:.*off.* bei den Consumern ergänzt.
on=on off=off habe ich belassen, um weiterhin über die Oberfläche schalten zu können.
Morgen werde ich bei hoffentlich schönem Wetter beobachten...
Vielen Dank
oelidoc
@DS_Starter
Ah verstehe, bzgl. der viewbox. Sieht jetzt wirklich besser aus.
Bin jetzt dabei auch das Gridsymbol durch ein FHEM Icon zu ersetzen.
Es steht ja vertretend für den für den Meter setupMeterDev.
Zukünftig brauchen wir noch weitere Meter wenn wir die Grid-Only Variante mit einbauen. Dementprechend auch weitere Symbole an weiteren Plätzen.
Den Inverter (die Sonne aktuell) müßte noch in die Reihe der Producer rutschen und an dessen aktuellen Platz so eine Art Kontenpunkt sein. Du hattest ja noch keine wirkliche Idee glaube ich.
Muß mir dein Bild weiter vorn nochmal anschauen...
Edit: gerade dein Bild in #1031 nochmal geschaut. Eigentlich reicht der eine vorhandene Gridpunkt. Ich lasse ihn erstmal so wie vorhanden.
Das sieht doch gut aus mit dem Mond :o
EDIT:
Sogar mein selbstgebasteltes Icon wird in der Größe angepasst. 👌
Gruß
300P
:)
Die Brennstoffzelle hatte ich schon gesucht um sie auszutesten ;), prima dass es auch damit klappt.
Zur Zeit ist das Standardicon für einen PV-Producer (Inverter) nach Sonnenaufgang die Sonne, die entweder grau bei keiner Leistung oder orange eingefärbt wird. Nach Sonnenuntergang wird sie durch die Mondphasen ersetzt.
Mir persönlich gefällt es weil es zusätzliche Infomationen liefert und die Grafik etwas auflockert.
Man kann die Sonne im setupInverterDev durch ein anderes Icon ersetzen. Dieses wird in der Nacht ebenfalls durch den Mond ersetzt.
Ich denke aktuell darüber nach, diesen Mechanismus abzuschalten wenn der User ein eigenes Icon wählt.
Er wird es nicht ohne Grund machen, so mein Gedanke dahinter. Bin mir aber unschlüssig.
Was meint ihr dazu?
LG
Falls du es noch benötigst:
hier ist das Chaos-Icon: ;D
Zitat von: DS_Starter am 06 Oktober 2024, 21:05:06Man kann die Sonne im setupInverterDev durch ein anderes Icon ersetzen. Dieses wird in der Nacht ebenfalls durch den Mond ersetzt.
Ich denke aktuell darüber nach, diesen Mechanismus abzuschalten wenn der User ein eigenes Icon wählt.
Er wird es nicht ohne Grund machen, so mein Gedanke dahinter. Bin mir aber unschlüssig.
Was meint ihr dazu?
Mir ist beides recht...
Oder :
Ginge nicht auch ........... iconDay=solar@red iconNight=solar@grey O:-)
und wenn nix angegeben ist - Standard
Ja, gute Idee. Der aktuelle Schlüssel icon ist auch leicht erweiterbar:
... icon=solar@red:solar@grey
Der erste Teil ist für Tag (Farbe bei Aktivität), sonst grau. Für Nacht kommt der zweite Teil zum Einsatz.
Ist der zweite Teil nicht angegeben, kommt der Mond. Ist nichts angegeben der Modulstandard.
Ich glaube das ist meine bevorzugte Variante.
LG
Hi,
sieht super gut aus und mir gefällt der Mond Nachts auch.
Ich hätte mal 2 Fragen:
1.
Ich habe 2 Inevrter, beide sind an Sollarzellen die gleich ausgerichtet sind (selbe Dachhälfte).
Einen Gen24 und einen Symo.
Ich habe wie in der Beschreibung die Inverter in einem Inverter Dummy zusammengefasst.
Wäre es nun besser 2 Producer einzutragen?
Geht das mit Invertern?
2.
An 300P, du hast da so ein Brennstoffzellen Icon.
Hast du einen H2O Speicher?
Hast du da einen Link?
Danke und Gruß,
Stefan
Hi Stefan.
ZitatIch habe 2 Inevrter, beide sind an Sollarzellen die gleich ausgerichtet sind (selbe Dachhälfte).
Einen Gen24 und einen Symo.
Ich habe wie in der Beschreibung die Inverter in einem Inverter Dummy zusammengefasst.
Wäre es nun besser 2 Producer einzutragen?
Geht das mit Invertern?
Nein, Producer sind für Non-PV Devices (BHKW etc.) vorgesehen. Steht auch so in der Hilfe.
Zukünftig wird möglich sein, mehrere Inverter mit der Zuordungsfähigkeit von Strings und Metern anzugeben.
Aber da muß ich noch bisschen arbeiten.
Lg,
Heiko
@all,
in meinem contrib liegt ein Update des Moduls. Im Attr setupInverterDev kann man nun auch für die Nacht ein alternatives Icon angeben wenn man den Mond nicht möchte. Das Tag und Nacht Icon ist somit getrennt steuerbar.
Danke 300P für den Stubser. ;)
icon Icon zur Darstellung des Inverters in der Flowgrafik (optional)
<Tag> - Icon und ggf. Farbe bei Aktivität nach Sonnenaufgang
<Nacht> - Icon und ggf. Farbe nach Sonnenuntergang, sonst wird die Mondphase angezeigt
LG
Zitat von: stefanru am 06 Oktober 2024, 22:32:07Hi,
sieht super gut aus und mir gefällt der Mond Nachts auch.
Ich hätte mal 2 Fragen:
1.
Ich habe 2 Inevrter, beide sind an Sollarzellen die gleich ausgerichtet sind (selbe Dachhälfte).
Einen Gen24 und einen Symo.
Ich habe wie in der Beschreibung die Inverter in einem Inverter Dummy zusammengefasst.
Wäre es nun besser 2 Producer einzutragen?
Geht das mit Invertern?
2.
An 300P, du hast da so ein Brennstoffzellen Icon.
Hast du einen H2O Speicher?
Hast du da einen Link?
Danke und Gruß,
Stefan
zu 1:
Die anderen "Producer" werden aber nicht bei den SF-Berechnungen mit einbezogen soweit ich es gelesen habe.
Also lass den Dummy so wie er ist - ich habe diverse WR mit mehreren Stringrichtungen und verändere nix.
zu 2:
Falls du das Logo meinst - selbstgebastelt ein paar Beiträge vorher als Download 8)
->OT EIN
Nein und niemals und bei mir kein H (oder H2O) Speicher. =>> Nachsatz : Du meinst sicherlich den "H" (Wasserstoff) nicht "H2O" (Wasser)
Ich habe einen VITOVALOR 300P (aus 2017) mit 0,750 kW Leistung.
Das ganze wird in 2025 mit einer Luftwärmepumpe (und mehr PV) ersetzt, rechnet sich (für mich) zukünftig "garnicht" mehr.
Das Teil wird danach nur noch bis zum Ende der Förderung "Betriebsbereit gehalten".
->OT OFF
Gruß
300P
Danke 300P,
jetzt erinnere ich mich.
Du hattest die Brennstoffzellen Heizung von Vissmann.
Das hatte ich gelesen und auch deine Meinung gesehen.
Bekomme demnächst eine Vissmann Wärmepumpe.
Dann bin ich gespannt wie sich diese in FHEM Einbinden lässt.
Vielen Dank für die Antwort.
Gruß,
Stefan
Zitat von: DS_Starter am 04 Oktober 2024, 14:24:03ZitatIn welchen Abständen versucht SolarForecast den Verbraucher einzuschalten?
Das passiert bei jedem Zyklus (Attr ctrlInterval). Es wird der Soll/Ist-Zustand verglichen. Wenn Soll mit Ist nicht übereinstimmt wird ein Schaltversuch (On oder Off) gesendet.
Ich habe das heute nochmal versucht nachzuvollziehen...
Der Verbraucher 04 (can) war für 12:00-13:00 geplant, Verbraucher 10 (must) ist für 14:00-15:00 geplant.
Lt. Logfiles:
Um 12:04:44 wurde der entsprechende Betriebsmodus der Wärmepumpe gesetzt
Um 12:04:56 hat die Wärmepumpe den Beginn der WW-Bereitung über das swstate-Reading gemeldet.
Um 12:05:43 wurde der Betriebsmodus der Wärmepumpe nochmal gesetzt
Das ctrlInterval ist auf 59 Sekunden gesetzt, d.h. es ist sehr wahrscheinlich, dass die beiden Umschaltungen von SolarForecast getriggert wurden und auch, dass es immer vom gleichen consumer04 gemacht wurde, weil der 10er ja erst später geplant ist.
Bist Du sicher, dass die Reihenfolge im Modul immer richtig ist, d.h. zuerst swstate ausgewertet/aktualisiert wird und dann ggf. der Schaltbefehl ausgeführt wird? Oder kann es passieren, dass da noch der alte Status verwendet wird?
Noch eine Frage:
Wann beginnt die spezifizierte "locktime" zu wirken? Nach dem 1. Schaltversuch oder erst, nachdem der Verbraucher das Einschalten über swstate rückgemeldet hat? (Falls ersteres, könnte ich einfach eine "locktime" angeben, dann dürfte es zu keinem weiteren Schaltversuch kommen.)
ZitatBist Du sicher, dass die Reihenfolge im Modul immer richtig ist, d.h. zuerst swstate ausgewertet/aktualisiert wird und dann ggf. der Schaltbefehl ausgeführt wird? Oder kann es passieren, dass da noch der alte Status verwendet wird?
Ja, allerdings ist es wichtig dass der Consumer synchron arbeitet, d.h. das Ergebnis des Schaltbefehls sofort aktualisiert und nicht zeitversetzt. Sonst sollte die Einstellung des Consumers im Attr auf "asynchron" helfen.
Genaueres sieht man mit ctrlDebug = consumerSwitchingXX.
ZitatWann beginnt die spezifizierte "locktime" zu wirken? Nach dem 1. Schaltversuch oder erst, nachdem der Verbraucher das Einschalten über swstate rückgemeldet hat? (Falls ersteres, könnte ich einfach eine "locktime" angeben, dann dürfte es zu keinem weiteren Schaltversuch kommen.)
Sie beginnt wenn der Consumer physisch "on" bzw. "off" geschaltet wurde, d.h. wenn der Regex im Key bei einem Statuswechsel swstate erfüllt wurde.
Auch das würde man mit dem ctrlDebug verfolgen können.
Mal nebenbei was ganz anderes:
Irgendwie "läuft" das Forum bei mir wohl nicht richtig...
Manchmal bekomme ich eine Mail für neue Beiträge und der Beitrag ist dann nicht im Forum sichtbar (wenn dann ich auf den link in der Mail drücke oder auch manuell das Forum aufrufe).🤯
Ein anderes Mal bekomme ich gar keine Mail (oder viel später erst) für neue Beiträge und sehe sie aber bevor die Mail oder der "ALARM" bei mir als User oben im Kopf angezeigt wird.😳
Das mit der Anzeige von angehängten Dateien kenn ich inzwischen ja, aber jetzt wird es bei mir irgendwie schlimmer.😴 Oder sollte es daran liegen das ich auf dem Land bin und nur mit 50MBit angeschlossen bin.🤬
Habt ihr auch solche ähnliche Problem mit dem Forum ?
Ja, kann bestätigen. Zumindest die teilweise fehlenden Mails bei neuen Beiträgen und die Anzeige von angehängten Dateien. Ein bestimmtes Schema konnte ich noch nicht erkennen.
Echt unschön...
@TheTrumpeter,
ich habe im Modul eine Logik eingebaut, die den negativen Effekt eines verzögerten Setzen des Schaltstatus in einem Consumer eliminiert.
Liegt in meinem contrib. Kannst du gern mal einsetzen und das Ergebnis kontrollieren.
LG
Zitat von: DS_Starter am 07 Oktober 2024, 21:06:39Ja, allerdings ist es wichtig dass der Consumer synchron arbeitet, d.h. das Ergebnis des Schaltbefehls sofort aktualisiert und nicht zeitversetzt. Sonst sollte die Einstellung des Consumers im Attr auf "asynchron" helfen.
Genaueres sieht man mit ctrlDebug = consumerSwitchingXX.
Hm... asynchron=1 hatte ich die ganze Zeit, nur am Wochenende habe ich es mal deaktiviert, was aber keine Verbesserung brachte.
Habe die Debug-Ausgabe nun für beide Consumer aktiviert, aktuell ist consumer04 für 12 und consumer10 für 13 Uhr geplant. Für consumer10 wird die swoncond aber nicht erfüllt sein, d.h. der kommt so oder so nicht dran.
Wenn die Prognose so bleibt, sehen wir hoffentlich zu Mittag was sich warum tut.
Zitat von: DS_Starter am 07 Oktober 2024, 22:20:21ich habe im Modul eine Logik eingebaut, die den negativen Effekt eines verzögerten Setzen des Schaltstatus in einem Consumer eliminiert.
Danke. Ich warte noch die heutigen Debug-Ausgaben ab. Eventuell liegt die Ursache ja woanders vergraben, wenngleich ich es mir nicht vorstellen kann.
Zitat von: TheTrumpeter am 08 Oktober 2024, 06:56:16Danke. Ich warte noch die heutigen Debug-Ausgaben ab. Eventuell liegt die Ursache ja woanders vergraben, wenngleich ich es mir nicht vorstellen kann.
So...
Hier der Debug-Output von SolarForecast:
2024.10.08 11:59:49 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 213 W, nompower: 3500, surplus: 3515 W, planstate: planned: 2024-10-08 12:00:00 - 2024-10-08 13:00:00, starttime: 08.10.2024 12:00:00
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - current planning state: planned
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate: off
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate: off
2024.10.08 11:59:49 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 213 W, nompower: 2500, surplus: 3515 W, planstate: planned: 2024-10-08 14:00:00 - 2024-10-08 15:00:00, starttime: 08.10.2024 14:00:00
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 0, on-command: pOpMode manual
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate: off
2024.10.08 11:59:49 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate: off
2024.10.08 12:00:04 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 219 W, nompower: 3500, surplus: 3542 W, planstate: planned: 2024-10-08 12:00:00 - 2024-10-08 13:00:00, starttime: 08.10.2024 12:00:00
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.08 12:00:04 1: mySolarForecast DEBUG> mySolarForecast DEBUG> Consumer switch enable by battery state: 1
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - current planning state: starting
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate: off
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate: off
2024.10.08 12:00:04 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 219 W, nompower: 2500, surplus: 3542 W, planstate: planned: 2024-10-08 14:00:00 - 2024-10-08 15:00:00, starttime: 08.10.2024 14:00:00
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 0, on-command: pOpMode manual
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate: off
2024.10.08 12:00:04 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate: off
2024.10.08 12:00:17 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 230 W, nompower: 3500, surplus: 3541 W, planstate: switching on:, starttime: 08.10.2024 12:00:00
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.08 12:00:17 1: mySolarForecast DEBUG> mySolarForecast DEBUG> Consumer switch enable by battery state: 1
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - current planning state: starting
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate: on
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate: off
2024.10.08 12:00:17 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 230 W, nompower: 2500, surplus: 3541 W, planstate: planned: 2024-10-08 14:00:00 - 2024-10-08 15:00:00, starttime: 08.10.2024 14:00:00
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 0, on-command: pOpMode manual
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate: on
2024.10.08 12:00:17 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate: off
2024.10.08 12:01:16 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 2666 W, nompower: 3500, surplus: 1076 W, planstate: switched on: 2024-10-08 12:00:17 - 2024-10-08 13:00:17, starttime: 08.10.2024 12:00:17
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - current planning state: started
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate: on
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate: off
2024.10.08 12:01:16 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 2666 W, nompower: 2500, surplus: 1076 W, planstate: planned: 2024-10-08 14:00:00 - 2024-10-08 15:00:00, starttime: 08.10.2024 14:00:00
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 0, on-command: pOpMode manual
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-07 12:06:42
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-07 12:41:08
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate: on
2024.10.08 12:01:16 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate: off
2024.10.08 12:02:15 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 2782 W, nompower: 3500, surplus: 1024 W, planstate: switched on: 2024-10-08 12:00:17 - 2024-10-08 13:00:17, starttime: 08.10.2024 12:00:17
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - current planning state: started
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 1
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-08 12:02:15
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: still running
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate: on
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate: on
2024.10.08 12:02:15 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 2782 W, nompower: 2500, surplus: 1024 W, planstate: planned: 2024-10-08 14:00:00 - 2024-10-08 15:00:00, starttime: 08.10.2024 14:00:00
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 0, on-command: pOpMode manual
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 1
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-08 12:02:15
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: still running
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate: on
2024.10.08 12:02:15 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate: on Lt. File-Logs von der Wärmepumpe wurde um 12:00:04 sowie um 12:00:17 die Betriebsart gesendet.
Als "eingeschaltet" wurde die WW-Bereitung bereits um 12:00:06 zurückgemeldet.
Ok. Dann nutze zum Vergleich meine contrib-Version.
Sehe gerade auch, dass ich noch eine Debug-Zeile einbauen muß damit man sieht wann tatsächlich ein Schaltbefehl abgesetzt wird. Das fehlt noch.
Zitat von: DS_Starter am 08 Oktober 2024, 12:54:51Dann nutze zum Vergleich meine contrib-Version.
Ist drin, Planung von Consumer04 dzt. für 11-12, Consumer10 für 12-13. Werde dann davor auch die Debug-Ausgaben wieder aktivieren.
Zitat von: TheTrumpeter am 09 Oktober 2024, 08:04:01Zitat von: DS_Starter am 08 Oktober 2024, 12:54:51Dann nutze zum Vergleich meine contrib-Version.
Ist drin, Planung von Consumer04 dzt. für 11-12, Consumer10 für 12-13. Werde dann davor auch die Debug-Ausgaben wieder aktivieren.
Hier die Debug-Ausgabe:
2024.10.09 10:59:49 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - current planning state: planned
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate before switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate before switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 292 W, nompower: 3500, surplus: 4633 W, planstate: planned: 2024-10-09 11:00:00 - 2024-10-09 12:00:00, starttime: 09.10.2024 11:00:00
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - current planning state: planned
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate after switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate after switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-08 12:25:51
2024.10.09 10:59:49 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate before switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate before switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 292 W, nompower: 2500, surplus: 4633 W, planstate: planned: 2024-10-09 12:00:00 - 2024-10-09 13:00:00, starttime: 09.10.2024 12:00:00
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate after switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate after switching: off
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 10:59:49 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-08 12:25:51
2024.10.09 11:00:04 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - current planning state: planned
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate before switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate before switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 273 W, nompower: 3500, surplus: 4689 W, planstate: planned: 2024-10-09 11:00:00 - 2024-10-09 12:00:00, starttime: 09.10.2024 11:00:00
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.09 11:00:04 1: mySolarForecast DEBUG> Consumer switch enable by battery state: 1
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - send switch command now: "set Mythz pOpMode manual"
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - current planning state: starting
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate after switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate after switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-08 12:25:51
2024.10.09 11:00:04 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate before switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate before switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 273 W, nompower: 2500, surplus: 4689 W, planstate: planned: 2024-10-09 12:00:00 - 2024-10-09 13:00:00, starttime: 09.10.2024 12:00:00
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate after switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate after switching: off
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 11:00:04 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-08 12:25:51
2024.10.09 11:00:35 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - current planning state: starting
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate before switching: on
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate before switching: off
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 2594 W, nompower: 3500, surplus: 2321 W, planstate: switched on: 2024-10-09 11:00:34 - 2024-10-09 12:00:34, starttime: 09.10.2024 11:00:34
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 1
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - current planning state: started
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate after switching: on
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate after switching: off
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-08 12:25:51
2024.10.09 11:00:35 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate before switching: on
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate before switching: off
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 2594 W, nompower: 2500, surplus: 2321 W, planstate: planned: 2024-10-09 12:00:00 - 2024-10-09 13:00:00, starttime: 09.10.2024 12:00:00
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate after switching: on
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate after switching: off
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 11:00:35 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-08 12:25:51
2024.10.09 11:01:33 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "04" ###############
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - current planning state: started
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate before switching: on
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate before switching: off
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 2746 W, nompower: 3500, surplus: 2771 W, planstate: switched on: 2024-10-09 11:00:34 - 2024-10-09 12:00:34, starttime: 09.10.2024 11:00:34
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - isInLocktime: 0
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - device 'Mythz' is used as switching device
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - current planning state: started
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - physical Switchstate after switching: on
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - logical Switchstate after switching: off
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - cycleDayNum: 0
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "04" - last cycle end time: 2024-10-08 12:25:51
2024.10.09 11:01:33 1: mySolarForecast DEBUG> ############### consumerSwitching consumer "10" ###############
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate before switching: on
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate before switching: off
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - general switching parameters => auto mode: 1, Current household consumption: 2746 W, nompower: 2500, surplus: 2771 W, planstate: planned: 2024-10-09 12:00:00 - 2024-10-09 13:00:00, starttime: 09.10.2024 12:00:00
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - isInLocktime: 0
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch on' => swoncond: 1, on-command: pOpMode manual
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - device 'Mythz' is used as switching device
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - in Context 'switch off' => swoffcond: 0, off-command:
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - current planning state: planned
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - physical Switchstate after switching: on
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - logical Switchstate after switching: off
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - cycleDayNum: 0
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - last cycle start time: 2024-10-08 12:02:15
2024.10.09 11:01:33 1: mySolarForecast DEBUG> consumer "10" - last cycle end time: 2024-10-08 12:25:51 Heute wurde lt. Wärmepumpen-Logs die Betriebsart nur 1x an die Wärmepumpe gesendet:
11:00:04 wurde die Betriebsart umgeschaltet
11:00:10 wurde der WW-Betrieb rückgemeldet
Ich habe auch zusätzlich in meine externe Abbruchfunktion (je nach Strombezug und Strompreis wird ab einer Speichertemperatur von 46,5 °C der WW-Betrieb potenziell beendet, ansonsten erst bei 51 °C) eine Überwachung eingebaut, um sicherzustellen, dass die nicht ggf. fälschlicherweise gleich nach dem Start wieder abbricht und es so zum weiteren Start aus SolarForecast heraus kommt. Das war aber auch nicht der Fall.
Das Ergebnis ist so wie ich es erwartet habe. Passt aus meiner Sicht.
Hatte den Change auch bei mir eine Weile unter verschiedenen Situationen simuliert und werde ihn jetzt in das kommende Release übernehmen.
Wenn ich das richtig sehe, dann lässt sich aktuell nur eine "Battery Device" über das Attribut "setupBatteryDev" in FHEM integrieren.
Ist geplant, dass künftig auch mehrere "Battery Devices" anlegbar sind?
Das jedenfalls wäre super, da es (neben mir mit meinem Goodwe GW25K-ET) sicherlich einige Leute gibt, die System mit mehreren mehr als einem Speicher haben.
Hallo Parallix,
ZitatWenn ich das richtig sehe, dann lässt sich aktuell nur eine "Battery Device" über das Attribut "setupBatteryDev" in FHEM integrieren.
Ist geplant, dass künftig auch mehrere "Battery Devices" anlegbar sind?
Bisher bestand keine Veranlassung dafür. Wenn es aber den Bedarf gibt, kann ich es durchaus mit ins Auge fassen.
Für eine reine Anzeige kannst du bereits jetzt über einen Dummy mit entsprechenden Readings eine Integration vornehmen. Wie sinvoll es ist, hängt vom jeweiligen Anwendungsfall ab.
Zunächst gehe ich den bestehenden Plan weiter, mehrere Inverter mit ihren verschiedenen Abhängigkeiten im System zu integrieren. Dann können wir mal in Richtung Multibatterie schauen.
LG,
Heiko
@all,
die Version 1.35.0 ist eingecheckt und wird morgen früh ausgeliefert.
Enthalten ist:
- in der Flußgrafik ist die Sonne durch ein FHEM SVG-Icon ersetzt. Im Standard wird am Tag eine Sonne,
Nachts der Mond mit seiner aktuellen Phase dargestellt
- Im Attr setupInverterDev ist der Key icon zur indivudellen Gestaltung des Inverter-Icons nutzbar
- die Größe der Icons in der Flußgrafik werden zur Laufzeit einander angeglichen
- die Erkennung des Schaltstatus bei Consumern mit verzögerter Statusübermittlung ist verbessert
- die Readings pvCorrectionFactor_XX_autocalc werden nicht mehr benötigt und wurden entfernt
- kleinere Fixes und Verbesserungen (Debug-Infos, Logausgaben,...)
Liegt für eilige auch im contrib.
LG,
Heiko
Zitat von: DS_Starter am 09 Oktober 2024, 14:39:21Hallo Parallix,
ZitatWenn ich das richtig sehe, dann lässt sich aktuell nur eine "Battery Device" über das Attribut "setupBatteryDev" in FHEM integrieren.
Ist geplant, dass künftig auch mehrere "Battery Devices" anlegbar sind?
Bisher bestand keine Veranlassung dafür. Wenn es aber den Bedarf gibt, kann ich es durchaus mit ins Auge fassen.
...
Das wäre echt prima, denn (m)ein aktueller Weg über ein virtuelles Device, das die Werte von zwei Speichern fusioniert, ist nicht wirklich gut.
Zitat von: Parallix am 09 Oktober 2024, 14:11:29Wenn ich das richtig sehe, dann lässt sich aktuell nur eine "Battery Device" über das Attribut "setupBatteryDev" in FHEM integrieren.
Ist geplant, dass künftig auch mehrere "Battery Devices" anlegbar sind?
Das jedenfalls wäre super, da es (neben mir mit meinem Goodwe GW25K-ET) sicherlich einige Leute gibt, die System mit mehreren mehr als einem Speicher haben.
Das laßt sich bislang doch sauber über einen Dummy bewerkstelligen, der diese (s.u.) Reading durch eine zyklische Berechnung gefüllt bekommt. O:-)
Dummy-Device
defmod BatteryDummy dummy
attr BatteryDummy DbLogExclude .*
attr BatteryDummy event-on-change-reading .*
attr BatteryDummy group Energy Meter
attr BatteryDummy icon batterie@green
attr BatteryDummy room 020_PV,Energie
attr BatteryDummy stateFormat {ReadingsVal("$name","total_pac", undef)." kW ".\
" - total ".ReadingsVal("$name","bat_loadtotal", undef)." kWh (-in)".\
" - ".ReadingsVal("$name","bat_unloadtotal", undef)." kWh (out)".\
" - charged ".ReadingsVal("$name","chargestatus", undef)." % ".\
" - ".(ReadingsVal($name,"chargestatus",0)/100 * (ReadingsVal($name,"bat_rated_capacity",0))*1000)." Watt"}
attr BatteryDummy userReadings total_pac, power_out, power_in, chargestatus, bat_rated_capacity, bat_loadtotal, bat_unloadtotal
und hier z.B. eine (etwas längere) Notify-Berechnung mit diversen WR und 2 x Batteriewechselrichter (SBS25) auf Basis der immer vorhandenen Veränderung des allgemeinen Energymeter beim EVU-Zähler.
(Die BatterieDummy-Berechnung ist extra mit ####BatteryDummy#### gekennzeichnet)
defmod N.PV.TotalConsumption.Dum.Energy notify SMA_Energymeter:Saldo_Wirkleistung:.* {\
# Energieverbrauch PV\
fhem "setreading Dum.Energy PV ".sprintf("%.1f",(ReadingsVal("SB25","total_pac",0)*1000));;\
my $tc = sprintf("%.1f",ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)+ReadingsVal("Dum.Energy","GridConsumption",0)-ReadingsVal("Dum.Energy","GridFeedIn",0));;\
fhem ("setreading Dum.Energy TotalConsumption ".sprintf("%.1f",$tc));;\
fhem "setreading Dum.Energy PV_2 ".sprintf("%.1f",(ReadingsVal("SB30","total_pac",0)*1000));;\
fhem "setreading Dum.Energy PV_40 ".sprintf("%.1f",(ReadingsVal("SB40","total_pac",0)*1000));;\
fhem "setreading Dum.Energy PV_20 ".sprintf("%.1f",(ReadingsVal("SB20","total_pac",0)*1000));;\
fhem "setreading Dum.Energy PV_30_M ".sprintf("%.1f",(ReadingsVal("SB30_M","total_pac",0)*1000));;\
fhem "setreading Dum.Energy GridFeedIn_30_M ".sprintf("%.1f",(ReadingsVal("SB30_M","Meter_Power_Grid_FeedIn",0)*1000));; \
fhem "setreading Dum.Energy GridFeedIn_20 ".sprintf("%.1f",(ReadingsVal("SB20","Meter_Power_Grid_FeedIn",0)*1000));; \
fhem "setreading Dum.Energy FCU ".sprintf("%.1f",(ReadingsVal("FCU","FCU-Strom-aktuelle-Leistung",0)));;\
fhem "setreading Dum.Energy DGYGridFeedIn ".sprintf("%.1f",(ReadingsVal("MyDiscovergyEVU","power",0)));; \
# Batterie-Bezug -Batterieentnahme\
fhem "setreading Dum.Energy BattLoadIn ".sprintf("%.1f",(ReadingsVal("SBS25","power_out",0)));;\
# Batterie-Beladung Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut ".sprintf("%.1f",(ReadingsVal("SBS25","power_in",0)));;\
# Batteriestatus\
fhem "setreading Dum.Energy BattStatusP ".sprintf("%.1f",(ReadingsVal("SBS25","chargestatus",0)));;\
# Batterie-Bezug -Batterieentnahme_2\
fhem "setreading Dum.Energy BattLoadIn_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_out",0)));;\
# Batterie-Beladung_2 Batterie mit Strom füllen\
fhem "setreading Dum.Energy BattLoadOut_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","power_in",0)));;\
# Batteriestatus_2\
fhem "setreading Dum.Energy BattStatusP_2 ".sprintf("%.1f",(ReadingsVal("SBS25_2","chargestatus",0)));;\
# Forecast Invertererzeugung InverterDummy \
fhem "setreading InverterDummy Today_PVforecast ".sprintf("%.3f",(ReadingsNum("Forecast","Today_PVforecast",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy etotal ".sprintf("%.3f",(ReadingsNum("SB25","etotal",0))+(ReadingsNum("SB30","etotal",0))+(ReadingsNum("SB40","etotal",0)));;\
# Invertererzeugung InverterDummy \
fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("SB25","total_pac",0))+(ReadingsNum("SB30","total_pac",0))+(ReadingsNum("SB40","total_pac",0)));;\
# Invertererzeugung InverterDummy \
my $wert1234 = "0" ;;\
$wert1234 = sprintf("%.3f",(ReadingsNum("SB25","etoday",0))+(ReadingsNum("SB30","etoday",0))+(ReadingsNum("SB40","etoday",0)));; \
fhem ("setreading InverterDummy etoday ".sprintf("%.3f",$wert1234));;\
####BatteryDummy####\
####BatteryDummy####\
####BatteryDummy####\
# Batterie-Bezug -Batterieentnahme BatteryDummy\
fhem "setreading BatteryDummy power_out ".sprintf("%.0f",(ReadingsNum("SBS25","power_out",0))+(ReadingsNum("SBS25_2","power_out",0)));;\
# Batterie-Beladung BatteryDummy mit Strom füllen\
fhem "setreading BatteryDummy power_in ".sprintf("%.0f",(ReadingsNum("SBS25","power_in",0))+(ReadingsNum("SBS25_2","power_in",0)));;\
# Batterie-Bezug -bat_loadtotal Batterieentnahme BatteryDummy\
fhem "setreading BatteryDummy bat_unloadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_unloadtotal",0))+(ReadingsNum("SBS25_2","bat_unloadtotal",0)));;\
# Batterie-Beladung bat_loadtotal BatteryDummy mit Strom füllen\
fhem "setreading BatteryDummy bat_loadtotal ".sprintf("%.3f",(ReadingsNum("SBS25","bat_loadtotal",0))+(ReadingsNum("SBS25_2","bat_loadtotal",0)));;\
# Batteriestatus BatteryDummy\
my $wert5 = sprintf("%.2f",(((ReadingsNum("SBS25","chargestatus",0))/2) + ((ReadingsNum("SBS25_2","chargestatus",0))/2)));; \
fhem ("setreading BatteryDummy chargestatus ".sprintf("%.2f",$wert5));;\
# Batterie-total_pac BatteryDummy\
my $wert6 = sprintf("%.3f",((ReadingsNum("SBS25","total_pac",0))+(ReadingsNum("SBS25_2","total_pac",0))));; \
fhem ("setreading BatteryDummy total_pac ".sprintf("%.3f",$wert6));;\
# Batterie-bat_rated_capacity BatteryDummy\
my $wert7 = sprintf("%.3f",((ReadingsNum("SBS25","bat_rated_capacity",0))+(ReadingsNum("SBS25_2","bat_rated_capacity",0))));; \
fhem ("setreading BatteryDummy bat_rated_capacity ".sprintf("%.3f",$wert7));;\
####BatteryDummy####\
####BatteryDummy####\
####BatteryDummy####\
SMABatteryChargewithTibber();;\
}
attr N.PV.TotalConsumption.Dum.Energy DbLogExclude .*
attr N.PV.TotalConsumption.Dum.Energy room Energie
attr N.PV.TotalConsumption.Dum.Energy verbose 2
Ich habe seit mehreren Jahren bislang keinerlei Probleme damit gehabt ;D - außer die Kommunikation zu den BWR war ausgefallen. :o
Gruß
300P
Hallo Heiko,
ich hab deine neueste Version runtergeladen.
In der jetzigen, aber auch in den vorherigen war die Solarproduktion die Nacht durch immer ~10 W, obwohl das zugrundeliegende Device bei 0 lag.
Jetzt kommt noch hinzu, dass der Wert zwischen Sonne und Haus mit einer Nachkommastellen angezeigt wird.
Mein weiteres Spezialproblem ist, die erste leere Zeile beim flex Style. Ich hab noch festgestellt, dass sie aus 2 Zellen besteht, wobei die Größe der 1. Spalte der Seitenbreite entspricht, d.h. im Hochformat schmaler und im Querformat breiter. Vielleicht fällt dir mit diesem Hinweis etwas ein.
Ein list meines Devices:
define mySolarForecast SolarForecast
attr mySolarForecast comment widgetOverride flowGraphicShift:select,-70,-65,-60,-55,-50\
flowGraphicShift -60
attr mySolarForecast ctrlBackupFilesKeep 7
attr mySolarForecast ctrlGenPVdeviation daily
attr mySolarForecast ctrlInterval 30
attr mySolarForecast event-on-change-reading .*
attr mySolarForecast flowGraphicAnimate 1
attr mySolarForecast flowGraphicShift -65
attr mySolarForecast flowGraphicShowConsumerDummy 0
attr mySolarForecast flowGraphicShowConsumerPower 1
attr mySolarForecast flowGraphicSize 200
attr mySolarForecast graphicBeam1Color A9A9A9
attr mySolarForecast graphicBeam2Color BEBEBE
attr mySolarForecast graphicBeamWidth 60
attr mySolarForecast graphicEnergyUnit kWh
attr mySolarForecast graphicHeaderDetail all
attr mySolarForecast graphicHeaderShow 1
attr mySolarForecast graphicHistoryHour 4
attr mySolarForecast graphicHourCount 18
attr mySolarForecast graphicShowDiff top
attr mySolarForecast graphicShowWeather 1
attr mySolarForecast graphicSpaceSize 16
attr mySolarForecast graphicWeatherColor 62AFCD
attr mySolarForecast room DEYE
attr mySolarForecast setupBatteryDev Deye_Inverter pin=-pout pout=battery_output_power:W intotal=total_charge_of_the_battery:kWh outtotal=total_discharge_of_the_battery:kWh cap=16179.2 charge=SOC_jkbms
attr mySolarForecast setupInverterDev Deye_Inverter pv=Deye_Growatt_power:W etotal=total_pv_production:kWh capacity=15200
attr mySolarForecast setupInverterStrings Sueddach,Garagendach
attr mySolarForecast setupMeterDev Deye_Inverter gcon=total_grid_power:W contotal=total_energy_bought:kWh gfeedin=-gcon feedtotal=total_energy_sold:kWh
attr mySolarForecast setupRadiationAPI OpenMeteoDWDEnsemble-API
attr mySolarForecast setupStringPeak Sueddach=12.71 Garagendach=2.46
attr mySolarForecast setupWeatherDev1 OpenMeteoDWDEnsemble-API
attr mySolarForecast userReadings ForecastNoonBatt:Current_BatCharge.* {round(ReadingsNum($name,'Today_Hour11_PVforecast','0')+ReadingsNum($name,'Today_Hour12_PVforecast','0')+ReadingsNum($name,'Today_Hour13_PVforecast','0')+ReadingsNum($name,'Today_Hour14_PVforecast','0')+ReadingsNum($name,'Today_Hour15_PVforecast','0')-316*51.2*(1-ReadingsNum($name,'Current_BatCharge','0')/100),0)}
attr mySolarForecast verbose 2
attr mySolarForecast widgetOverride flowGraphicShift:select,-75,-70,-65,-60,-55,-50,-45
# CFGFN ./FHEM/Photovoltaik.cfg
# FUUID 66a609f9-f33f-e986-a5c4-ea9c9b242f9ee2a8
# FVERSION 76_SolarForecast.pm:v1.1.1-s29216/2024-10-09
# LCACHEFILE last write time: 20:40:47 whole Operating Memory
# MODE Automatic - next Cycletime: 20:49:34
# MODEL OpenMeteoDWDEnsembleAPI
# NAME mySolarForecast
# NR 1540
# NTFY_ORDER 50-mySolarForecast
# STATE updated
# TYPE SolarForecast
# eventCount 4584
# HELPER:
# FW WEBtablet
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL mySolarForecast
# SPGDEV mySolarForecast
# SPGROOM DEYE
# VERSION 1.34.2
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.2
# OLDREADINGS:
# READINGS:
# 2024-10-09 20:49:04 Current_AutarkyRate 99 %
# 2024-10-09 20:49:04 Current_BatCharge 53 %
# 2024-10-09 20:49:04 Current_Consumption 757 W
# 2024-10-09 20:49:04 Current_GridConsumption 11 W
# 2024-10-09 20:49:04 Current_GridFeedIn 0 W
# 2024-10-09 20:49:04 Current_PV 9 W
# 2024-10-09 20:49:04 Current_PowerBatIn 0 W
# 2024-10-09 20:49:04 Current_PowerBatOut 737 W
# 2024-10-09 20:49:04 Current_SelfConsumption 9 W
# 2024-10-09 20:49:04 Current_SelfConsumptionRate 100 %
# 2024-10-09 20:49:04 Current_Surplus 0 W
# 2024-10-09 20:39:04 ForecastNoonBatt -3065
# 2024-10-09 20:00:00 LastHourGridconsumptionReal 0 Wh
# 2024-10-09 20:00:00 LastHourPVforecast 0 Wh
# 2024-10-09 20:00:00 LastHourPVreal 0 Wh
# 2024-10-09 20:49:04 NextHours_Sum01_PVforecast 0 Wh
# 2024-10-09 20:49:04 NextHours_Sum02_PVforecast 0 Wh
# 2024-10-09 20:49:04 NextHours_Sum03_PVforecast 0 Wh
# 2024-10-09 20:49:04 NextHours_Sum04_ConsumptionForecast 2069 Wh
# 2024-10-09 20:49:04 NextHours_Sum04_PVforecast 0 Wh
# 2024-10-09 20:49:04 RestOfDayConsumptionForecast 1643 Wh
# 2024-10-09 20:49:04 RestOfDayPVforecast 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_BatIn 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_BatOut 400 Wh
# 2024-10-09 00:59:49 Today_Hour01_GridConsumption 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_PVreal 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_BatIn 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_BatOut 400 Wh
# 2024-10-09 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_BatIn 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_BatOut 400 Wh
# 2024-10-09 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_BatIn 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_BatOut 300 Wh
# 2024-10-09 03:59:49 Today_Hour04_GridConsumption 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_GridFeedIn 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_PVreal 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_BatIn 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_BatOut 200 Wh
# 2024-10-09 04:59:49 Today_Hour05_GridConsumption 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_PVreal 0 Wh
# 2024-10-09 05:59:49 Today_Hour06_BatIn 0 Wh
# 2024-10-09 05:59:49 Today_Hour06_BatOut 300 Wh
# 2024-10-09 05:59:49 Today_Hour06_GridConsumption 100 Wh
# 2024-10-09 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2024-10-09 05:59:49 Today_Hour06_PVreal 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_BatIn 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_BatOut 300 Wh
# 2024-10-09 06:59:49 Today_Hour07_GridConsumption 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_PVreal 0 Wh
# 2024-10-09 07:59:49 Today_Hour08_BatIn 0 Wh
# 2024-10-09 07:59:49 Today_Hour08_BatOut 300 Wh
# 2024-10-09 07:59:49 Today_Hour08_GridConsumption 0 Wh
# 2024-10-09 07:59:49 Today_Hour08_GridFeedIn 0 Wh
# 2024-10-09 05:39:04 Today_Hour08_PVforecast 11 Wh
# 2024-10-09 07:59:49 Today_Hour08_PVreal 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_BatIn 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_BatOut 500 Wh
# 2024-10-09 08:59:49 Today_Hour09_GridConsumption 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_PVforecast 161 Wh
# 2024-10-09 08:59:49 Today_Hour09_PVreal 100 Wh
# 2024-10-09 09:59:49 Today_Hour10_BatIn 0 Wh
# 2024-10-09 09:59:49 Today_Hour10_BatOut 0 Wh
# 2024-10-09 09:59:49 Today_Hour10_GridConsumption 100 Wh
# 2024-10-09 09:59:49 Today_Hour10_GridFeedIn 0 Wh
# 2024-10-09 09:59:49 Today_Hour10_PVforecast 746 Wh
# 2024-10-09 09:59:49 Today_Hour10_PVreal 400 Wh
# 2024-10-09 10:59:49 Today_Hour11_BatIn 500 Wh
# 2024-10-09 10:59:49 Today_Hour11_BatOut 0 Wh
# 2024-10-09 10:59:49 Today_Hour11_GridConsumption 0 Wh
# 2024-10-09 10:59:49 Today_Hour11_GridFeedIn 0 Wh
# 2024-10-09 10:59:49 Today_Hour11_PVforecast 755 Wh
# 2024-10-09 10:59:49 Today_Hour11_PVreal 1500 Wh
# 2024-10-09 11:59:49 Today_Hour12_BatIn 500 Wh
# 2024-10-09 11:59:49 Today_Hour12_BatOut 0 Wh
# 2024-10-09 11:59:49 Today_Hour12_GridConsumption 100 Wh
# 2024-10-09 11:59:49 Today_Hour12_GridFeedIn 0 Wh
# 2024-10-09 11:59:49 Today_Hour12_PVforecast 1117 Wh
# 2024-10-09 11:59:49 Today_Hour12_PVreal 1500 Wh
# 2024-10-09 12:59:49 Today_Hour13_BatIn 300 Wh
# 2024-10-09 12:59:49 Today_Hour13_BatOut 200 Wh
# 2024-10-09 12:59:49 Today_Hour13_GridConsumption 0 Wh
# 2024-10-09 12:59:49 Today_Hour13_GridFeedIn 100 Wh
# 2024-10-09 12:59:49 Today_Hour13_PVforecast 953 Wh
# 2024-10-09 12:59:49 Today_Hour13_PVreal 1200 Wh
# 2024-10-09 13:59:49 Today_Hour14_BatIn 400 Wh
# 2024-10-09 13:59:49 Today_Hour14_BatOut 0 Wh
# 2024-10-09 13:59:49 Today_Hour14_GridConsumption 0 Wh
# 2024-10-09 13:59:49 Today_Hour14_GridFeedIn 0 Wh
# 2024-10-09 13:59:49 Today_Hour14_PVforecast 945 Wh
# 2024-10-09 13:59:49 Today_Hour14_PVreal 1200 Wh
# 2024-10-09 14:59:49 Today_Hour15_BatIn 500 Wh
# 2024-10-09 14:59:49 Today_Hour15_BatOut 0 Wh
# 2024-10-09 14:59:49 Today_Hour15_GridConsumption 0 Wh
# 2024-10-09 14:59:49 Today_Hour15_GridFeedIn 0 Wh
# 2024-10-09 14:59:49 Today_Hour15_PVforecast 769 Wh
# 2024-10-09 14:59:49 Today_Hour15_PVreal 800 Wh
# 2024-10-09 15:59:49 Today_Hour16_BatIn 300 Wh
# 2024-10-09 15:59:49 Today_Hour16_BatOut 0 Wh
# 2024-10-09 15:59:49 Today_Hour16_GridConsumption 0 Wh
# 2024-10-09 15:59:49 Today_Hour16_GridFeedIn 0 Wh
# 2024-10-09 15:59:49 Today_Hour16_PVforecast 462 Wh
# 2024-10-09 15:59:49 Today_Hour16_PVreal 800 Wh
# 2024-10-09 16:59:49 Today_Hour17_BatIn 0 Wh
# 2024-10-09 16:59:49 Today_Hour17_BatOut 200 Wh
# 2024-10-09 16:59:49 Today_Hour17_GridConsumption 0 Wh
# 2024-10-09 16:59:49 Today_Hour17_GridFeedIn 0 Wh
# 2024-10-09 16:59:49 Today_Hour17_PVforecast 220 Wh
# 2024-10-09 16:59:49 Today_Hour17_PVreal 500 Wh
# 2024-10-09 17:59:49 Today_Hour18_BatIn 0 Wh
# 2024-10-09 17:59:49 Today_Hour18_BatOut 400 Wh
# 2024-10-09 17:59:49 Today_Hour18_GridConsumption 100 Wh
# 2024-10-09 17:59:49 Today_Hour18_GridFeedIn 0 Wh
# 2024-10-09 17:59:49 Today_Hour18_PVforecast 100 Wh
# 2024-10-09 17:59:49 Today_Hour18_PVreal 300 Wh
# 2024-10-09 18:59:49 Today_Hour19_BatIn 0 Wh
# 2024-10-09 18:59:49 Today_Hour19_BatOut 500 Wh
# 2024-10-09 18:59:49 Today_Hour19_GridConsumption 0 Wh
# 2024-10-09 18:59:49 Today_Hour19_GridFeedIn 0 Wh
# 2024-10-09 18:59:49 Today_Hour19_PVforecast 26 Wh
# 2024-10-09 18:59:49 Today_Hour19_PVreal 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_BatIn 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_BatOut 900 Wh
# 2024-10-09 19:59:50 Today_Hour20_GridConsumption 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_GridFeedIn 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_PVreal 0 Wh
# 2024-10-09 20:49:04 Today_Hour21_BatIn 0 Wh
# 2024-10-09 20:49:04 Today_Hour21_BatOut 500 Wh
# 2024-10-09 20:49:04 Today_Hour21_GridConsumption 0 Wh
# 2024-10-09 20:49:04 Today_Hour21_GridFeedIn 0 Wh
# 2024-10-09 20:49:04 Today_Hour21_PVreal 0 Wh
# 2024-10-09 20:49:04 Today_MaxPVforecast 1117 Wh
# 2024-10-09 20:49:04 Today_MaxPVforecastTime 2024-10-09 11:00:00
# 2024-10-09 20:49:04 Today_PVdeviation -32.72 %
# 2024-10-09 20:49:04 Today_PVforecast 6254 Wh
# 2024-10-09 20:49:04 Today_PVreal 8300 Wh
# 2024-10-09 20:49:04 Today_SunRise 07:46
# 2024-10-09 20:49:04 Today_SunSet 18:50
# 2024-10-09 20:49:04 Tomorrow_ConsumptionForecast 18690 Wh
# 2024-10-09 20:49:04 Tomorrow_PVforecast 23818 Wh
# 2024-10-09 20:49:04 Tomorrow_SunRise 07:48
# 2024-10-09 20:49:04 Tomorrow_SunSet 18:48
# 2024-10-09 20:49:04 nextCycletime 20:49:34
# 2024-10-09 20:42:35 nextRadiationAPICall after 2024-10-09 20:57:35
# 2024-10-09 09:00:04 pvCorrectionFactor_09 0.89 (automatic - old factor: 0.92, Sun Alt range: 5, Cloud range: 100, Days in range: 3)
# 2024-10-09 10:00:04 pvCorrectionFactor_10 1.10 (automatic - old factor: 1.14, Sun Alt range: 15, Cloud range: 100, Days in range: 6)
# 2024-10-09 11:00:04 pvCorrectionFactor_11 1.43 (automatic - old factor: 1.10, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
# 2024-10-09 12:00:04 pvCorrectionFactor_12 1.35 (automatic - old factor: 1.35, Sun Alt range: 30, Cloud range: 100, Days in range: 5)
# 2024-10-09 13:00:04 pvCorrectionFactor_13 1.02 (automatic - old factor: 0.97, Sun Alt range: 30, Cloud range: 100, Days in range: 2)
# 2024-10-09 14:00:04 pvCorrectionFactor_14 1.14 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 100, Days in range: 1)
# 2024-10-09 15:00:04 pvCorrectionFactor_15 1.14 (automatic - old factor: 1.14, Sun Alt range: 30, Cloud range: 100, Days in range: 4)
# 2024-10-09 16:00:04 pvCorrectionFactor_16 1.17 (automatic - old factor: 1.15, Sun Alt range: 25, Cloud range: 100, Days in range: 4)
# 2024-10-09 17:00:04 pvCorrectionFactor_17 0.92 (automatic - old factor: 0.89, Sun Alt range: 20, Cloud range: 100, Days in range: 5)
# 2024-10-09 18:00:04 pvCorrectionFactor_18 1.08 (automatic - old factor: 0.97, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 3)
# 2024-10-09 20:49:04 pvCorrectionFactor_Auto on_complex_ai
# 2024-09-29 10:36:34 setupStringAzimuth Sueddach=0 Garagendach=-90
# 2024-09-29 10:36:26 setupStringDeclination Sueddach=40 Garagendach=15
# 2024-10-09 20:49:05 state updated
# helper:
# bm:
# CODE(0x55b2bc3c6170):
# cnt 65
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 20:44:05
# max 0.00858211517333984
# tot 0.405903577804565
# mAr:
# HASH(0x55b2bc12dce8)
# mySolarForecast
# ?
# CODE(0x55b2bc3ccbf8):
# cnt 882
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 10:01:35
# max 0.0160109996795654
# tot 5.49564599990845
# mAr:
# HASH(0x55b2bc12dce8)
# mySolarForecast
# ?
# CODE(0x55b2bc6c1e10):
# cnt 1676
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 20:41:36
# max 0.000111103057861328
# tot 0.0712225437164307
# mAr:
# HASH(0x55b2bc12dce8)
# HASH(0x55b2ba409e78)
# CODE(0x55b2bc6c2980):
# cnt 142557
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 19:03:10
# max 0.0121979713439941
# tot 5.52376294136047
# mAr:
# HASH(0x55b2bc12dce8)
# HASH(0x55b2b9febd80)
# CODE(0x55b2bc70ba68):
# cnt 19112
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 20:42:04
# max 0.244407892227173
# tot 9.85766911506653
# mAr:
# HASH(0x55b2bc12dce8)
# CODE(0x55b2bc719a78):
# cnt 1350410
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 13:00:04
# max 0.515603065490723
# tot 673.997880220413
# mAr:
# HASH(0x55b2bc12dce8)
# CODE(0x55b2c0d06ca8):
# cnt 1
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 20:49:09
# max 0.000355005264282227
# tot 0.000355005264282227
# mAr:
# HASH(0x55b2bc12dce8)
# mySolarForecast
# ?
#
setstate mySolarForecast updated
setstate mySolarForecast 2024-10-09 03:11:30 .associatedWith Deye_Inverter
setstate mySolarForecast 2024-10-09 20:49:04 .lastupdateForecastValues 1728499744
setstate mySolarForecast 2024-10-09 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate mySolarForecast 2024-10-09 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate mySolarForecast 2024-10-09 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate mySolarForecast 2024-10-09 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate mySolarForecast 2024-10-09 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate mySolarForecast 2024-10-09 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate mySolarForecast 2024-10-09 04:00:04 .pvCorrectionFactor_04_apipercentil done
setstate mySolarForecast 2024-10-09 04:00:04 .pvCorrectionFactor_04_cloudcover done
setstate mySolarForecast 2024-10-09 05:00:04 .pvCorrectionFactor_05_apipercentil done
setstate mySolarForecast 2024-10-09 05:00:04 .pvCorrectionFactor_05_cloudcover done
setstate mySolarForecast 2024-10-09 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate mySolarForecast 2024-10-09 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate mySolarForecast 2024-10-09 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate mySolarForecast 2024-10-09 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate mySolarForecast 2024-10-09 08:00:04 .pvCorrectionFactor_08_apipercentil done
setstate mySolarForecast 2024-10-09 08:00:04 .pvCorrectionFactor_08_cloudcover done
setstate mySolarForecast 2024-10-09 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate mySolarForecast 2024-10-09 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate mySolarForecast 2024-10-09 10:00:04 .pvCorrectionFactor_10_apipercentil done
setstate mySolarForecast 2024-10-09 10:00:04 .pvCorrectionFactor_10_cloudcover done
setstate mySolarForecast 2024-10-09 11:00:04 .pvCorrectionFactor_11_apipercentil done
setstate mySolarForecast 2024-10-09 11:00:04 .pvCorrectionFactor_11_cloudcover done
setstate mySolarForecast 2024-10-09 12:00:04 .pvCorrectionFactor_12_apipercentil done
setstate mySolarForecast 2024-10-09 12:00:04 .pvCorrectionFactor_12_cloudcover done
setstate mySolarForecast 2024-10-09 13:00:04 .pvCorrectionFactor_13_apipercentil done
setstate mySolarForecast 2024-10-09 13:00:04 .pvCorrectionFactor_13_cloudcover done
setstate mySolarForecast 2024-10-09 14:00:04 .pvCorrectionFactor_14_apipercentil done
setstate mySolarForecast 2024-10-09 14:00:04 .pvCorrectionFactor_14_cloudcover done
setstate mySolarForecast 2024-10-09 15:00:04 .pvCorrectionFactor_15_apipercentil done
setstate mySolarForecast 2024-10-09 15:00:04 .pvCorrectionFactor_15_cloudcover done
setstate mySolarForecast 2024-10-09 16:00:04 .pvCorrectionFactor_16_apipercentil done
setstate mySolarForecast 2024-10-09 16:00:04 .pvCorrectionFactor_16_cloudcover done
setstate mySolarForecast 2024-10-09 17:00:04 .pvCorrectionFactor_17_apipercentil done
setstate mySolarForecast 2024-10-09 17:00:04 .pvCorrectionFactor_17_cloudcover done
setstate mySolarForecast 2024-10-09 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate mySolarForecast 2024-10-09 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate mySolarForecast 2024-10-09 19:00:04 .pvCorrectionFactor_19_apipercentil done
setstate mySolarForecast 2024-10-09 19:00:04 .pvCorrectionFactor_19_cloudcover done
setstate mySolarForecast 2024-10-09 20:00:04 .pvCorrectionFactor_20_apipercentil done
setstate mySolarForecast 2024-10-09 20:00:04 .pvCorrectionFactor_20_cloudcover done
setstate mySolarForecast 2024-10-09 20:49:04 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate mySolarForecast 2024-10-09 01:00:04 .signaldone_01 done
setstate mySolarForecast 2024-10-09 02:00:04 .signaldone_02 done
setstate mySolarForecast 2024-10-09 03:00:04 .signaldone_03 done
setstate mySolarForecast 2024-10-09 04:00:04 .signaldone_04 done
setstate mySolarForecast 2024-10-09 05:00:04 .signaldone_05 done
setstate mySolarForecast 2024-10-09 06:00:04 .signaldone_06 done
setstate mySolarForecast 2024-10-09 07:00:04 .signaldone_07 done
setstate mySolarForecast 2024-10-09 08:00:04 .signaldone_08 done
setstate mySolarForecast 2024-10-09 09:00:04 .signaldone_09 done
setstate mySolarForecast 2024-10-09 10:00:04 .signaldone_10 done
setstate mySolarForecast 2024-10-09 11:00:04 .signaldone_11 done
setstate mySolarForecast 2024-10-09 12:00:04 .signaldone_12 done
setstate mySolarForecast 2024-10-09 13:00:04 .signaldone_13 done
setstate mySolarForecast 2024-10-09 14:00:04 .signaldone_14 done
setstate mySolarForecast 2024-10-09 15:00:04 .signaldone_15 done
setstate mySolarForecast 2024-10-09 16:00:04 .signaldone_16 done
setstate mySolarForecast 2024-10-09 17:00:04 .signaldone_17 done
setstate mySolarForecast 2024-10-09 18:00:04 .signaldone_18 done
setstate mySolarForecast 2024-10-09 19:00:04 .signaldone_19 done
setstate mySolarForecast 2024-10-09 20:00:04 .signaldone_20 done
setstate mySolarForecast 2024-10-09 20:49:04 Current_AutarkyRate 99 %
setstate mySolarForecast 2024-10-09 20:49:04 Current_BatCharge 53 %
setstate mySolarForecast 2024-10-09 20:49:04 Current_Consumption 757 W
setstate mySolarForecast 2024-10-09 20:49:04 Current_GridConsumption 11 W
setstate mySolarForecast 2024-10-09 20:49:04 Current_GridFeedIn 0 W
setstate mySolarForecast 2024-10-09 20:49:04 Current_PV 9 W
setstate mySolarForecast 2024-10-09 20:49:04 Current_PowerBatIn 0 W
setstate mySolarForecast 2024-10-09 20:49:04 Current_PowerBatOut 737 W
setstate mySolarForecast 2024-10-09 20:49:04 Current_SelfConsumption 9 W
setstate mySolarForecast 2024-10-09 20:49:04 Current_SelfConsumptionRate 100 %
setstate mySolarForecast 2024-10-09 20:49:04 Current_Surplus 0 W
setstate mySolarForecast 2024-10-09 20:39:04 ForecastNoonBatt -3065
setstate mySolarForecast 2024-10-09 20:00:00 LastHourGridconsumptionReal 0 Wh
setstate mySolarForecast 2024-10-09 20:00:00 LastHourPVforecast 0 Wh
setstate mySolarForecast 2024-10-09 20:00:00 LastHourPVreal 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 NextHours_Sum01_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 NextHours_Sum02_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 NextHours_Sum03_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 NextHours_Sum04_ConsumptionForecast 2069 Wh
setstate mySolarForecast 2024-10-09 20:49:04 NextHours_Sum04_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 RestOfDayConsumptionForecast 1643 Wh
setstate mySolarForecast 2024-10-09 20:49:04 RestOfDayPVforecast 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_BatOut 200 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 05:39:04 Today_Hour08_PVforecast 11 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_BatOut 500 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_PVforecast 161 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_PVreal 100 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_PVforecast 746 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_PVreal 400 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_BatIn 500 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_PVforecast 755 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_PVreal 1500 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_BatIn 500 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_PVforecast 1117 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_PVreal 1500 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_BatIn 300 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_BatOut 200 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_GridFeedIn 100 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_PVforecast 953 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_PVreal 1200 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_BatIn 400 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_PVforecast 945 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_PVreal 1200 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_BatIn 500 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_PVforecast 769 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_PVreal 800 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_BatIn 300 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_PVforecast 462 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_PVreal 800 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_BatOut 200 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_PVforecast 220 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_PVreal 500 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_PVforecast 100 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_PVreal 300 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_BatOut 500 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_PVforecast 26 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_BatOut 900 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_Hour21_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_Hour21_BatOut 500 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_Hour21_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_Hour21_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_Hour21_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_MaxPVforecast 1117 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_MaxPVforecastTime 2024-10-09 11:00:00
setstate mySolarForecast 2024-10-09 20:49:04 Today_PVdeviation -32.72 %
setstate mySolarForecast 2024-10-09 20:49:04 Today_PVforecast 6254 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_PVreal 8300 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Today_SunRise 07:46
setstate mySolarForecast 2024-10-09 20:49:04 Today_SunSet 18:50
setstate mySolarForecast 2024-10-09 20:49:04 Tomorrow_ConsumptionForecast 18690 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Tomorrow_PVforecast 23818 Wh
setstate mySolarForecast 2024-10-09 20:49:04 Tomorrow_SunRise 07:48
setstate mySolarForecast 2024-10-09 20:49:04 Tomorrow_SunSet 18:48
setstate mySolarForecast 2024-10-09 20:49:04 nextCycletime 20:49:34
setstate mySolarForecast 2024-10-09 20:42:35 nextRadiationAPICall after 2024-10-09 20:57:35
setstate mySolarForecast 2024-10-09 09:00:04 pvCorrectionFactor_09 0.89 (automatic - old factor: 0.92, Sun Alt range: 5, Cloud range: 100, Days in range: 3)
setstate mySolarForecast 2024-10-09 10:00:04 pvCorrectionFactor_10 1.10 (automatic - old factor: 1.14, Sun Alt range: 15, Cloud range: 100, Days in range: 6)
setstate mySolarForecast 2024-10-09 11:00:04 pvCorrectionFactor_11 1.43 (automatic - old factor: 1.10, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
setstate mySolarForecast 2024-10-09 12:00:04 pvCorrectionFactor_12 1.35 (automatic - old factor: 1.35, Sun Alt range: 30, Cloud range: 100, Days in range: 5)
setstate mySolarForecast 2024-10-09 13:00:04 pvCorrectionFactor_13 1.02 (automatic - old factor: 0.97, Sun Alt range: 30, Cloud range: 100, Days in range: 2)
setstate mySolarForecast 2024-10-09 14:00:04 pvCorrectionFactor_14 1.14 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 100, Days in range: 1)
setstate mySolarForecast 2024-10-09 15:00:04 pvCorrectionFactor_15 1.14 (automatic - old factor: 1.14, Sun Alt range: 30, Cloud range: 100, Days in range: 4)
setstate mySolarForecast 2024-10-09 16:00:04 pvCorrectionFactor_16 1.17 (automatic - old factor: 1.15, Sun Alt range: 25, Cloud range: 100, Days in range: 4)
setstate mySolarForecast 2024-10-09 17:00:04 pvCorrectionFactor_17 0.92 (automatic - old factor: 0.89, Sun Alt range: 20, Cloud range: 100, Days in range: 5)
setstate mySolarForecast 2024-10-09 18:00:04 pvCorrectionFactor_18 1.08 (automatic - old factor: 0.97, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 3)
setstate mySolarForecast 2024-10-09 20:49:04 pvCorrectionFactor_Auto on_complex_ai
setstate mySolarForecast 2024-09-29 10:36:34 setupStringAzimuth Sueddach=0 Garagendach=-90
setstate mySolarForecast 2024-09-29 10:36:26 setupStringDeclination Sueddach=40 Garagendach=15
setstate mySolarForecast 2024-10-09 20:49:05 state updated
Viele Grüße Gisbert
Hallo Gisbert,
ZitatIn der jetzigen, aber auch in den vorherigen war die Solarproduktion die Nacht durch immer ~10 W, obwohl das zugrundeliegende Device bei 0 lag.
Das ist schwer vorstellbar, denn das Reading Current_PV wird direkt aus dem Reading des Quellendevice gelesen.
Das sieht man mit ctrlDebug=collectData. Kannst mal das Log posten wenn der Fall eintritt.
ZitatJetzt kommt noch hinzu, dass der Wert zwischen Sonne und Haus mit einer Nachkommastellen angezeigt wird.
Ja, das ist neu. Und zwar bei Größen bis 10W, bei größeren Werten wird ohne Kommastelle angezeigt.
ZitatMein weiteres Spezialproblem ist, die erste leere Zeile beim flex Style. Ich hab noch festgestellt, dass sie aus 2 Zellen besteht, wobei die Größe der 1. Spalte der Seitenbreite entspricht, d.h. im Hochformat schmaler und im Querformat breiter. Vielleicht fällt dir mit diesem Hinweis etwas ein.
Ich wüsste momentan nicht wo ich da etwas ändern könnte. Aber ich habe deine Beobachtung auch noch nicht auf einem Handy nachgestellt. Im Browser sehe ich mit den verfügbaren Styles keine solche Leerzeile + Spalten.
LG
@Gisbert, ich finde bei mir kein "flex tyle". Ist es ein offiziell von FHEM ausgelieferter Style oder aus anderer Quelle?
@Heiko,
der Flex Style ist wohl kein offizielles Modul:
https://raw.githubusercontent.com/nagel86/fhem-flex/master/controls_fhem-flex.txt
https://github.com/thecodingdad/fhem-flex
Edit:
Das PV-Device zeigt 9 W, dein Modul arbeitet also korrekt. Das nachfolgende ist damit hinfällig.
Hier noch ein neues list mit attr ctrlDebug collectData; es werden nach wie vor 9 W angezeigt.
define mySolarForecast SolarForecast
attr mySolarForecast comment widgetOverride flowGraphicShift:select,-70,-65,-60,-55,-50\
flowGraphicShift -60
attr mySolarForecast ctrlBackupFilesKeep 7
attr mySolarForecast ctrlDebug collectData
attr mySolarForecast ctrlGenPVdeviation daily
attr mySolarForecast ctrlInterval 30
attr mySolarForecast event-on-change-reading .*
attr mySolarForecast flowGraphicAnimate 1
attr mySolarForecast flowGraphicShift -65
attr mySolarForecast flowGraphicShowConsumerDummy 0
attr mySolarForecast flowGraphicShowConsumerPower 1
attr mySolarForecast flowGraphicSize 200
attr mySolarForecast graphicBeam1Color A9A9A9
attr mySolarForecast graphicBeam2Color BEBEBE
attr mySolarForecast graphicBeamWidth 60
attr mySolarForecast graphicEnergyUnit kWh
attr mySolarForecast graphicHeaderDetail all
attr mySolarForecast graphicHeaderShow 1
attr mySolarForecast graphicHistoryHour 4
attr mySolarForecast graphicHourCount 18
attr mySolarForecast graphicShowDiff top
attr mySolarForecast graphicShowWeather 1
attr mySolarForecast graphicSpaceSize 16
attr mySolarForecast graphicWeatherColor 62AFCD
attr mySolarForecast room DEYE
attr mySolarForecast setupBatteryDev Deye_Inverter pin=-pout pout=battery_output_power:W intotal=total_charge_of_the_battery:kWh outtotal=total_discharge_of_the_battery:kWh cap=16179.2 charge=SOC_jkbms
attr mySolarForecast setupInverterDev Deye_Inverter pv=Deye_Growatt_power:W etotal=total_pv_production:kWh capacity=15200
attr mySolarForecast setupInverterStrings Sueddach,Garagendach
attr mySolarForecast setupMeterDev Deye_Inverter gcon=total_grid_power:W contotal=total_energy_bought:kWh gfeedin=-gcon feedtotal=total_energy_sold:kWh
attr mySolarForecast setupRadiationAPI OpenMeteoDWDEnsemble-API
attr mySolarForecast setupStringPeak Sueddach=12.71 Garagendach=2.46
attr mySolarForecast setupWeatherDev1 OpenMeteoDWDEnsemble-API
attr mySolarForecast userReadings ForecastNoonBatt:Current_BatCharge.* {round(ReadingsNum($name,'Today_Hour11_PVforecast','0')+ReadingsNum($name,'Today_Hour12_PVforecast','0')+ReadingsNum($name,'Today_Hour13_PVforecast','0')+ReadingsNum($name,'Today_Hour14_PVforecast','0')+ReadingsNum($name,'Today_Hour15_PVforecast','0')-316*51.2*(1-ReadingsNum($name,'Current_BatCharge','0')/100),0)}
attr mySolarForecast verbose 2
attr mySolarForecast widgetOverride flowGraphicShift:select,-75,-70,-65,-60,-55,-50,-45
# CFGFN ./FHEM/Photovoltaik.cfg
# FUUID 66a609f9-f33f-e986-a5c4-ea9c9b242f9ee2a8
# FVERSION 76_SolarForecast.pm:v1.1.1-s29216/2024-10-09
# LCACHEFILE last write time: 21:51:42 whole Operating Memory
# MODE Automatic - next Cycletime: 21:55:04
# MODEL OpenMeteoDWDEnsembleAPI
# NAME mySolarForecast
# NR 1540
# NTFY_ORDER 50-mySolarForecast
# STATE updated
# TYPE SolarForecast
# eventCount 4868
# HELPER:
# FW WEBtablet
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV mySolarForecast
# SPGROOM
# VERSION 1.34.2
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.2
# OLDREADINGS:
# READINGS:
# 2024-10-09 21:54:34 Current_AutarkyRate 98 %
# 2024-10-09 21:54:34 Current_BatCharge 49 %
# 2024-10-09 21:54:34 Current_Consumption 565 W
# 2024-10-09 21:54:34 Current_GridConsumption 13 W
# 2024-10-09 21:54:34 Current_GridFeedIn 0 W
# 2024-10-09 21:54:34 Current_PV 9 W
# 2024-10-09 21:54:34 Current_PowerBatIn 0 W
# 2024-10-09 21:54:34 Current_PowerBatOut 543 W
# 2024-10-09 21:54:34 Current_SelfConsumption 9 W
# 2024-10-09 21:54:34 Current_SelfConsumptionRate 100 %
# 2024-10-09 21:54:34 Current_Surplus 0 W
# 2024-10-09 21:45:34 ForecastNoonBatt -3712
# 2024-10-09 21:00:00 LastHourGridconsumptionReal 0 Wh
# 2024-10-09 21:00:00 LastHourPVforecast 0 Wh
# 2024-10-09 21:00:00 LastHourPVreal 0 Wh
# 2024-10-09 21:54:34 NextHours_Sum01_PVforecast 0 Wh
# 2024-10-09 21:54:34 NextHours_Sum02_PVforecast 0 Wh
# 2024-10-09 21:54:34 NextHours_Sum03_PVforecast 0 Wh
# 2024-10-09 21:54:34 NextHours_Sum04_ConsumptionForecast 2163 Wh
# 2024-10-09 21:54:34 NextHours_Sum04_PVforecast 0 Wh
# 2024-10-09 21:54:34 RestOfDayConsumptionForecast 1082 Wh
# 2024-10-09 21:54:34 RestOfDayPVforecast 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_BatIn 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_BatOut 400 Wh
# 2024-10-09 00:59:49 Today_Hour01_GridConsumption 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2024-10-09 00:59:49 Today_Hour01_PVreal 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_BatIn 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_BatOut 400 Wh
# 2024-10-09 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2024-10-09 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_BatIn 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_BatOut 400 Wh
# 2024-10-09 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-10-09 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_BatIn 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_BatOut 300 Wh
# 2024-10-09 03:59:49 Today_Hour04_GridConsumption 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_GridFeedIn 0 Wh
# 2024-10-09 03:59:49 Today_Hour04_PVreal 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_BatIn 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_BatOut 200 Wh
# 2024-10-09 04:59:49 Today_Hour05_GridConsumption 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2024-10-09 04:59:49 Today_Hour05_PVreal 0 Wh
# 2024-10-09 05:59:49 Today_Hour06_BatIn 0 Wh
# 2024-10-09 05:59:49 Today_Hour06_BatOut 300 Wh
# 2024-10-09 05:59:49 Today_Hour06_GridConsumption 100 Wh
# 2024-10-09 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2024-10-09 05:59:49 Today_Hour06_PVreal 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_BatIn 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_BatOut 300 Wh
# 2024-10-09 06:59:49 Today_Hour07_GridConsumption 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2024-10-09 06:59:49 Today_Hour07_PVreal 0 Wh
# 2024-10-09 07:59:49 Today_Hour08_BatIn 0 Wh
# 2024-10-09 07:59:49 Today_Hour08_BatOut 300 Wh
# 2024-10-09 07:59:49 Today_Hour08_GridConsumption 0 Wh
# 2024-10-09 07:59:49 Today_Hour08_GridFeedIn 0 Wh
# 2024-10-09 05:39:04 Today_Hour08_PVforecast 11 Wh
# 2024-10-09 07:59:49 Today_Hour08_PVreal 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_BatIn 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_BatOut 500 Wh
# 2024-10-09 08:59:49 Today_Hour09_GridConsumption 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2024-10-09 08:59:49 Today_Hour09_PVforecast 161 Wh
# 2024-10-09 08:59:49 Today_Hour09_PVreal 100 Wh
# 2024-10-09 09:59:49 Today_Hour10_BatIn 0 Wh
# 2024-10-09 09:59:49 Today_Hour10_BatOut 0 Wh
# 2024-10-09 09:59:49 Today_Hour10_GridConsumption 100 Wh
# 2024-10-09 09:59:49 Today_Hour10_GridFeedIn 0 Wh
# 2024-10-09 09:59:49 Today_Hour10_PVforecast 746 Wh
# 2024-10-09 09:59:49 Today_Hour10_PVreal 400 Wh
# 2024-10-09 10:59:49 Today_Hour11_BatIn 500 Wh
# 2024-10-09 10:59:49 Today_Hour11_BatOut 0 Wh
# 2024-10-09 10:59:49 Today_Hour11_GridConsumption 0 Wh
# 2024-10-09 10:59:49 Today_Hour11_GridFeedIn 0 Wh
# 2024-10-09 10:59:49 Today_Hour11_PVforecast 755 Wh
# 2024-10-09 10:59:49 Today_Hour11_PVreal 1500 Wh
# 2024-10-09 11:59:49 Today_Hour12_BatIn 500 Wh
# 2024-10-09 11:59:49 Today_Hour12_BatOut 0 Wh
# 2024-10-09 11:59:49 Today_Hour12_GridConsumption 100 Wh
# 2024-10-09 11:59:49 Today_Hour12_GridFeedIn 0 Wh
# 2024-10-09 11:59:49 Today_Hour12_PVforecast 1117 Wh
# 2024-10-09 11:59:49 Today_Hour12_PVreal 1500 Wh
# 2024-10-09 12:59:49 Today_Hour13_BatIn 300 Wh
# 2024-10-09 12:59:49 Today_Hour13_BatOut 200 Wh
# 2024-10-09 12:59:49 Today_Hour13_GridConsumption 0 Wh
# 2024-10-09 12:59:49 Today_Hour13_GridFeedIn 100 Wh
# 2024-10-09 12:59:49 Today_Hour13_PVforecast 953 Wh
# 2024-10-09 12:59:49 Today_Hour13_PVreal 1200 Wh
# 2024-10-09 13:59:49 Today_Hour14_BatIn 400 Wh
# 2024-10-09 13:59:49 Today_Hour14_BatOut 0 Wh
# 2024-10-09 13:59:49 Today_Hour14_GridConsumption 0 Wh
# 2024-10-09 13:59:49 Today_Hour14_GridFeedIn 0 Wh
# 2024-10-09 13:59:49 Today_Hour14_PVforecast 945 Wh
# 2024-10-09 13:59:49 Today_Hour14_PVreal 1200 Wh
# 2024-10-09 14:59:49 Today_Hour15_BatIn 500 Wh
# 2024-10-09 14:59:49 Today_Hour15_BatOut 0 Wh
# 2024-10-09 14:59:49 Today_Hour15_GridConsumption 0 Wh
# 2024-10-09 14:59:49 Today_Hour15_GridFeedIn 0 Wh
# 2024-10-09 14:59:49 Today_Hour15_PVforecast 769 Wh
# 2024-10-09 14:59:49 Today_Hour15_PVreal 800 Wh
# 2024-10-09 15:59:49 Today_Hour16_BatIn 300 Wh
# 2024-10-09 15:59:49 Today_Hour16_BatOut 0 Wh
# 2024-10-09 15:59:49 Today_Hour16_GridConsumption 0 Wh
# 2024-10-09 15:59:49 Today_Hour16_GridFeedIn 0 Wh
# 2024-10-09 15:59:49 Today_Hour16_PVforecast 462 Wh
# 2024-10-09 15:59:49 Today_Hour16_PVreal 800 Wh
# 2024-10-09 16:59:49 Today_Hour17_BatIn 0 Wh
# 2024-10-09 16:59:49 Today_Hour17_BatOut 200 Wh
# 2024-10-09 16:59:49 Today_Hour17_GridConsumption 0 Wh
# 2024-10-09 16:59:49 Today_Hour17_GridFeedIn 0 Wh
# 2024-10-09 16:59:49 Today_Hour17_PVforecast 220 Wh
# 2024-10-09 16:59:49 Today_Hour17_PVreal 500 Wh
# 2024-10-09 17:59:49 Today_Hour18_BatIn 0 Wh
# 2024-10-09 17:59:49 Today_Hour18_BatOut 400 Wh
# 2024-10-09 17:59:49 Today_Hour18_GridConsumption 100 Wh
# 2024-10-09 17:59:49 Today_Hour18_GridFeedIn 0 Wh
# 2024-10-09 17:59:49 Today_Hour18_PVforecast 100 Wh
# 2024-10-09 17:59:49 Today_Hour18_PVreal 300 Wh
# 2024-10-09 18:59:49 Today_Hour19_BatIn 0 Wh
# 2024-10-09 18:59:49 Today_Hour19_BatOut 500 Wh
# 2024-10-09 18:59:49 Today_Hour19_GridConsumption 0 Wh
# 2024-10-09 18:59:49 Today_Hour19_GridFeedIn 0 Wh
# 2024-10-09 18:59:49 Today_Hour19_PVforecast 26 Wh
# 2024-10-09 18:59:49 Today_Hour19_PVreal 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_BatIn 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_BatOut 900 Wh
# 2024-10-09 19:59:50 Today_Hour20_GridConsumption 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_GridFeedIn 0 Wh
# 2024-10-09 19:59:50 Today_Hour20_PVreal 0 Wh
# 2024-10-09 20:59:49 Today_Hour21_BatIn 0 Wh
# 2024-10-09 20:59:49 Today_Hour21_BatOut 600 Wh
# 2024-10-09 20:59:49 Today_Hour21_GridConsumption 0 Wh
# 2024-10-09 20:59:49 Today_Hour21_GridFeedIn 0 Wh
# 2024-10-09 20:59:49 Today_Hour21_PVreal 0 Wh
# 2024-10-09 21:54:34 Today_Hour22_BatIn 0 Wh
# 2024-10-09 21:54:34 Today_Hour22_BatOut 500 Wh
# 2024-10-09 21:54:34 Today_Hour22_GridConsumption 0 Wh
# 2024-10-09 21:54:34 Today_Hour22_GridFeedIn 0 Wh
# 2024-10-09 21:54:34 Today_Hour22_PVreal 0 Wh
# 2024-10-09 21:54:34 Today_MaxPVforecast 1117 Wh
# 2024-10-09 21:54:34 Today_MaxPVforecastTime 2024-10-09 11:00:00
# 2024-10-09 21:54:34 Today_PVdeviation -32.72 %
# 2024-10-09 21:54:34 Today_PVforecast 6254 Wh
# 2024-10-09 21:54:34 Today_PVreal 8300 Wh
# 2024-10-09 21:54:34 Today_SunRise 07:46
# 2024-10-09 21:54:34 Today_SunSet 18:50
# 2024-10-09 21:54:34 Tomorrow_ConsumptionForecast 18690 Wh
# 2024-10-09 21:54:34 Tomorrow_PVforecast 23818 Wh
# 2024-10-09 21:54:34 Tomorrow_SunRise 07:48
# 2024-10-09 21:54:34 Tomorrow_SunSet 18:48
# 2024-10-09 21:54:34 nextCycletime 21:55:04
# 2024-10-09 21:44:35 nextRadiationAPICall after 2024-10-09 21:59:35
# 2024-10-09 09:00:04 pvCorrectionFactor_09 0.89 (automatic - old factor: 0.92, Sun Alt range: 5, Cloud range: 100, Days in range: 3)
# 2024-10-09 10:00:04 pvCorrectionFactor_10 1.10 (automatic - old factor: 1.14, Sun Alt range: 15, Cloud range: 100, Days in range: 6)
# 2024-10-09 11:00:04 pvCorrectionFactor_11 1.43 (automatic - old factor: 1.10, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
# 2024-10-09 12:00:04 pvCorrectionFactor_12 1.35 (automatic - old factor: 1.35, Sun Alt range: 30, Cloud range: 100, Days in range: 5)
# 2024-10-09 13:00:04 pvCorrectionFactor_13 1.02 (automatic - old factor: 0.97, Sun Alt range: 30, Cloud range: 100, Days in range: 2)
# 2024-10-09 14:00:04 pvCorrectionFactor_14 1.14 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 100, Days in range: 1)
# 2024-10-09 15:00:04 pvCorrectionFactor_15 1.14 (automatic - old factor: 1.14, Sun Alt range: 30, Cloud range: 100, Days in range: 4)
# 2024-10-09 16:00:04 pvCorrectionFactor_16 1.17 (automatic - old factor: 1.15, Sun Alt range: 25, Cloud range: 100, Days in range: 4)
# 2024-10-09 17:00:04 pvCorrectionFactor_17 0.92 (automatic - old factor: 0.89, Sun Alt range: 20, Cloud range: 100, Days in range: 5)
# 2024-10-09 18:00:04 pvCorrectionFactor_18 1.08 (automatic - old factor: 0.97, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 3)
# 2024-10-09 21:54:34 pvCorrectionFactor_Auto on_complex_ai
# 2024-09-29 10:36:34 setupStringAzimuth Sueddach=0 Garagendach=-90
# 2024-09-29 10:36:26 setupStringDeclination Sueddach=40 Garagendach=15
# 2024-10-09 21:54:35 state updated
# helper:
# bm:
# CODE(0x55b2bc3c6170):
# cnt 212
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 21:52:35
# max 0.00920987129211426
# tot 1.33765983581543
# mAr:
# HASH(0x55b2bc12dce8)
# mySolarForecast
# ?
# CODE(0x55b2bc3ccbf8):
# cnt 882
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 10:01:35
# max 0.0160109996795654
# tot 5.49564599990845
# mAr:
# HASH(0x55b2bc12dce8)
# mySolarForecast
# ?
# CODE(0x55b2bc6331a8):
# cnt 1
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 21:52:35
# max 0.000102043151855469
# tot 0.000102043151855469
# mAr:
# set
# mySolarForecast
# ctrlDebug
# collectData
# CODE(0x55b2bc6c1e10):
# cnt 9118
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 21:25:57
# max 0.000452041625976562
# tot 0.393627166748047
# mAr:
# HASH(0x55b2bc12dce8)
# HASH(0x55b2b4d53b88)
# CODE(0x55b2bc6c2980):
# cnt 142557
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 19:03:10
# max 0.0121979713439941
# tot 5.52376294136047
# mAr:
# HASH(0x55b2bc12dce8)
# HASH(0x55b2b9febd80)
# CODE(0x55b2bc70ba68):
# cnt 104192
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 21:00:04
# max 0.40278697013855
# tot 53.2230644226074
# mAr:
# HASH(0x55b2bc12dce8)
# CODE(0x55b2bc719a78):
# cnt 1350410
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 13:00:04
# max 0.515603065490723
# tot 673.997880220413
# mAr:
# HASH(0x55b2bc12dce8)
# CODE(0x55b2c0d06ca8):
# cnt 6
# dmx -1000
# dtot 0
# dtotcnt 0
# mTS 09.10. 21:49:38
# max 0.000685930252075195
# tot 0.00253486633300781
# mAr:
# HASH(0x55b2bc12dce8)
# mySolarForecast
# ?
#
setstate mySolarForecast updated
setstate mySolarForecast 2024-10-09 03:11:30 .associatedWith Deye_Inverter
setstate mySolarForecast 2024-10-09 21:54:34 .lastupdateForecastValues 1728503674
setstate mySolarForecast 2024-10-09 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate mySolarForecast 2024-10-09 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate mySolarForecast 2024-10-09 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate mySolarForecast 2024-10-09 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate mySolarForecast 2024-10-09 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate mySolarForecast 2024-10-09 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate mySolarForecast 2024-10-09 04:00:04 .pvCorrectionFactor_04_apipercentil done
setstate mySolarForecast 2024-10-09 04:00:04 .pvCorrectionFactor_04_cloudcover done
setstate mySolarForecast 2024-10-09 05:00:04 .pvCorrectionFactor_05_apipercentil done
setstate mySolarForecast 2024-10-09 05:00:04 .pvCorrectionFactor_05_cloudcover done
setstate mySolarForecast 2024-10-09 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate mySolarForecast 2024-10-09 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate mySolarForecast 2024-10-09 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate mySolarForecast 2024-10-09 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate mySolarForecast 2024-10-09 08:00:04 .pvCorrectionFactor_08_apipercentil done
setstate mySolarForecast 2024-10-09 08:00:04 .pvCorrectionFactor_08_cloudcover done
setstate mySolarForecast 2024-10-09 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate mySolarForecast 2024-10-09 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate mySolarForecast 2024-10-09 10:00:04 .pvCorrectionFactor_10_apipercentil done
setstate mySolarForecast 2024-10-09 10:00:04 .pvCorrectionFactor_10_cloudcover done
setstate mySolarForecast 2024-10-09 11:00:04 .pvCorrectionFactor_11_apipercentil done
setstate mySolarForecast 2024-10-09 11:00:04 .pvCorrectionFactor_11_cloudcover done
setstate mySolarForecast 2024-10-09 12:00:04 .pvCorrectionFactor_12_apipercentil done
setstate mySolarForecast 2024-10-09 12:00:04 .pvCorrectionFactor_12_cloudcover done
setstate mySolarForecast 2024-10-09 13:00:04 .pvCorrectionFactor_13_apipercentil done
setstate mySolarForecast 2024-10-09 13:00:04 .pvCorrectionFactor_13_cloudcover done
setstate mySolarForecast 2024-10-09 14:00:04 .pvCorrectionFactor_14_apipercentil done
setstate mySolarForecast 2024-10-09 14:00:04 .pvCorrectionFactor_14_cloudcover done
setstate mySolarForecast 2024-10-09 15:00:04 .pvCorrectionFactor_15_apipercentil done
setstate mySolarForecast 2024-10-09 15:00:04 .pvCorrectionFactor_15_cloudcover done
setstate mySolarForecast 2024-10-09 16:00:04 .pvCorrectionFactor_16_apipercentil done
setstate mySolarForecast 2024-10-09 16:00:04 .pvCorrectionFactor_16_cloudcover done
setstate mySolarForecast 2024-10-09 17:00:04 .pvCorrectionFactor_17_apipercentil done
setstate mySolarForecast 2024-10-09 17:00:04 .pvCorrectionFactor_17_cloudcover done
setstate mySolarForecast 2024-10-09 18:00:04 .pvCorrectionFactor_18_apipercentil done
setstate mySolarForecast 2024-10-09 18:00:04 .pvCorrectionFactor_18_cloudcover done
setstate mySolarForecast 2024-10-09 19:00:04 .pvCorrectionFactor_19_apipercentil done
setstate mySolarForecast 2024-10-09 19:00:04 .pvCorrectionFactor_19_cloudcover done
setstate mySolarForecast 2024-10-09 20:00:04 .pvCorrectionFactor_20_apipercentil done
setstate mySolarForecast 2024-10-09 20:00:04 .pvCorrectionFactor_20_cloudcover done
setstate mySolarForecast 2024-10-09 21:00:04 .pvCorrectionFactor_21_apipercentil done
setstate mySolarForecast 2024-10-09 21:00:04 .pvCorrectionFactor_21_cloudcover done
setstate mySolarForecast 2024-10-09 21:54:34 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate mySolarForecast 2024-10-09 01:00:04 .signaldone_01 done
setstate mySolarForecast 2024-10-09 02:00:04 .signaldone_02 done
setstate mySolarForecast 2024-10-09 03:00:04 .signaldone_03 done
setstate mySolarForecast 2024-10-09 04:00:04 .signaldone_04 done
setstate mySolarForecast 2024-10-09 05:00:04 .signaldone_05 done
setstate mySolarForecast 2024-10-09 06:00:04 .signaldone_06 done
setstate mySolarForecast 2024-10-09 07:00:04 .signaldone_07 done
setstate mySolarForecast 2024-10-09 08:00:04 .signaldone_08 done
setstate mySolarForecast 2024-10-09 09:00:04 .signaldone_09 done
setstate mySolarForecast 2024-10-09 10:00:04 .signaldone_10 done
setstate mySolarForecast 2024-10-09 11:00:04 .signaldone_11 done
setstate mySolarForecast 2024-10-09 12:00:04 .signaldone_12 done
setstate mySolarForecast 2024-10-09 13:00:04 .signaldone_13 done
setstate mySolarForecast 2024-10-09 14:00:04 .signaldone_14 done
setstate mySolarForecast 2024-10-09 15:00:04 .signaldone_15 done
setstate mySolarForecast 2024-10-09 16:00:04 .signaldone_16 done
setstate mySolarForecast 2024-10-09 17:00:04 .signaldone_17 done
setstate mySolarForecast 2024-10-09 18:00:04 .signaldone_18 done
setstate mySolarForecast 2024-10-09 19:00:04 .signaldone_19 done
setstate mySolarForecast 2024-10-09 20:00:04 .signaldone_20 done
setstate mySolarForecast 2024-10-09 21:00:04 .signaldone_21 done
setstate mySolarForecast 2024-10-09 21:54:34 Current_AutarkyRate 98 %
setstate mySolarForecast 2024-10-09 21:54:34 Current_BatCharge 49 %
setstate mySolarForecast 2024-10-09 21:54:34 Current_Consumption 565 W
setstate mySolarForecast 2024-10-09 21:54:34 Current_GridConsumption 13 W
setstate mySolarForecast 2024-10-09 21:54:34 Current_GridFeedIn 0 W
setstate mySolarForecast 2024-10-09 21:54:34 Current_PV 9 W
setstate mySolarForecast 2024-10-09 21:54:34 Current_PowerBatIn 0 W
setstate mySolarForecast 2024-10-09 21:54:34 Current_PowerBatOut 543 W
setstate mySolarForecast 2024-10-09 21:54:34 Current_SelfConsumption 9 W
setstate mySolarForecast 2024-10-09 21:54:34 Current_SelfConsumptionRate 100 %
setstate mySolarForecast 2024-10-09 21:54:34 Current_Surplus 0 W
setstate mySolarForecast 2024-10-09 21:45:34 ForecastNoonBatt -3712
setstate mySolarForecast 2024-10-09 21:00:00 LastHourGridconsumptionReal 0 Wh
setstate mySolarForecast 2024-10-09 21:00:00 LastHourPVforecast 0 Wh
setstate mySolarForecast 2024-10-09 21:00:00 LastHourPVreal 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 NextHours_Sum01_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 NextHours_Sum02_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 NextHours_Sum03_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 NextHours_Sum04_ConsumptionForecast 2163 Wh
setstate mySolarForecast 2024-10-09 21:54:34 NextHours_Sum04_PVforecast 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 RestOfDayConsumptionForecast 1082 Wh
setstate mySolarForecast 2024-10-09 21:54:34 RestOfDayPVforecast 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 00:59:49 Today_Hour01_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 01:59:49 Today_Hour02_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 02:59:49 Today_Hour03_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 03:59:49 Today_Hour04_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_BatOut 200 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 04:59:49 Today_Hour05_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 05:59:49 Today_Hour06_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 06:59:49 Today_Hour07_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_BatOut 300 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 05:39:04 Today_Hour08_PVforecast 11 Wh
setstate mySolarForecast 2024-10-09 07:59:49 Today_Hour08_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_BatOut 500 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_PVforecast 161 Wh
setstate mySolarForecast 2024-10-09 08:59:49 Today_Hour09_PVreal 100 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_PVforecast 746 Wh
setstate mySolarForecast 2024-10-09 09:59:49 Today_Hour10_PVreal 400 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_BatIn 500 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_PVforecast 755 Wh
setstate mySolarForecast 2024-10-09 10:59:49 Today_Hour11_PVreal 1500 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_BatIn 500 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_PVforecast 1117 Wh
setstate mySolarForecast 2024-10-09 11:59:49 Today_Hour12_PVreal 1500 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_BatIn 300 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_BatOut 200 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_GridFeedIn 100 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_PVforecast 953 Wh
setstate mySolarForecast 2024-10-09 12:59:49 Today_Hour13_PVreal 1200 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_BatIn 400 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_PVforecast 945 Wh
setstate mySolarForecast 2024-10-09 13:59:49 Today_Hour14_PVreal 1200 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_BatIn 500 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_PVforecast 769 Wh
setstate mySolarForecast 2024-10-09 14:59:49 Today_Hour15_PVreal 800 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_BatIn 300 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_BatOut 0 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_PVforecast 462 Wh
setstate mySolarForecast 2024-10-09 15:59:49 Today_Hour16_PVreal 800 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_BatOut 200 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_PVforecast 220 Wh
setstate mySolarForecast 2024-10-09 16:59:49 Today_Hour17_PVreal 500 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_BatOut 400 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_GridConsumption 100 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_PVforecast 100 Wh
setstate mySolarForecast 2024-10-09 17:59:49 Today_Hour18_PVreal 300 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_BatOut 500 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_PVforecast 26 Wh
setstate mySolarForecast 2024-10-09 18:59:49 Today_Hour19_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_BatOut 900 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 19:59:50 Today_Hour20_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 20:59:49 Today_Hour21_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 20:59:49 Today_Hour21_BatOut 600 Wh
setstate mySolarForecast 2024-10-09 20:59:49 Today_Hour21_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 20:59:49 Today_Hour21_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 20:59:49 Today_Hour21_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_Hour22_BatIn 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_Hour22_BatOut 500 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_Hour22_GridConsumption 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_Hour22_GridFeedIn 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_Hour22_PVreal 0 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_MaxPVforecast 1117 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_MaxPVforecastTime 2024-10-09 11:00:00
setstate mySolarForecast 2024-10-09 21:54:34 Today_PVdeviation -32.72 %
setstate mySolarForecast 2024-10-09 21:54:34 Today_PVforecast 6254 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_PVreal 8300 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Today_SunRise 07:46
setstate mySolarForecast 2024-10-09 21:54:34 Today_SunSet 18:50
setstate mySolarForecast 2024-10-09 21:54:34 Tomorrow_ConsumptionForecast 18690 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Tomorrow_PVforecast 23818 Wh
setstate mySolarForecast 2024-10-09 21:54:34 Tomorrow_SunRise 07:48
setstate mySolarForecast 2024-10-09 21:54:34 Tomorrow_SunSet 18:48
setstate mySolarForecast 2024-10-09 21:54:34 nextCycletime 21:55:04
setstate mySolarForecast 2024-10-09 21:44:35 nextRadiationAPICall after 2024-10-09 21:59:35
setstate mySolarForecast 2024-10-09 09:00:04 pvCorrectionFactor_09 0.89 (automatic - old factor: 0.92, Sun Alt range: 5, Cloud range: 100, Days in range: 3)
setstate mySolarForecast 2024-10-09 10:00:04 pvCorrectionFactor_10 1.10 (automatic - old factor: 1.14, Sun Alt range: 15, Cloud range: 100, Days in range: 6)
setstate mySolarForecast 2024-10-09 11:00:04 pvCorrectionFactor_11 1.43 (automatic - old factor: 1.10, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
setstate mySolarForecast 2024-10-09 12:00:04 pvCorrectionFactor_12 1.35 (automatic - old factor: 1.35, Sun Alt range: 30, Cloud range: 100, Days in range: 5)
setstate mySolarForecast 2024-10-09 13:00:04 pvCorrectionFactor_13 1.02 (automatic - old factor: 0.97, Sun Alt range: 30, Cloud range: 100, Days in range: 2)
setstate mySolarForecast 2024-10-09 14:00:04 pvCorrectionFactor_14 1.14 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 100, Days in range: 1)
setstate mySolarForecast 2024-10-09 15:00:04 pvCorrectionFactor_15 1.14 (automatic - old factor: 1.14, Sun Alt range: 30, Cloud range: 100, Days in range: 4)
setstate mySolarForecast 2024-10-09 16:00:04 pvCorrectionFactor_16 1.17 (automatic - old factor: 1.15, Sun Alt range: 25, Cloud range: 100, Days in range: 4)
setstate mySolarForecast 2024-10-09 17:00:04 pvCorrectionFactor_17 0.92 (automatic - old factor: 0.89, Sun Alt range: 20, Cloud range: 100, Days in range: 5)
setstate mySolarForecast 2024-10-09 18:00:04 pvCorrectionFactor_18 1.08 (automatic - old factor: 0.97, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 3)
setstate mySolarForecast 2024-10-09 21:54:34 pvCorrectionFactor_Auto on_complex_ai
setstate mySolarForecast 2024-09-29 10:36:34 setupStringAzimuth Sueddach=0 Garagendach=-90
setstate mySolarForecast 2024-09-29 10:36:26 setupStringDeclination Sueddach=40 Garagendach=15
setstate mySolarForecast 2024-10-09 21:54:35 state updated
Danke, aber ich meinte natürlich die Logausgabe mit diesem Debug. ;)
Sieht etwa so aus:
...
2024.10.09 22:05:41.043 1: SolCast DEBUG> Number of Weather datasets mergers - delivered: 25, merged: 25, failures: 0
2024.10.09 22:05:41.047 1: SolCast DEBUG> collect Inverter data - device: InverterDummy =>
2024.10.09 22:05:41.047 1: SolCast DEBUG> pv: 0 W, etotal: 65122300 Wh
2024.10.09 22:05:41.047 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2024.10.09 22:05:41.048 1: SolCast DEBUG> gcon: 0 W, gfeedin: 3.3 W, contotal: 68386.3 Wh, feedtotal: 2433774.2 Wh
2024.10.09 22:05:41.048 1: SolCast DEBUG> collect Battery data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2024.10.09 22:05:41.049 1: SolCast DEBUG> pin=0 W, pout=761 W, totalin: 3350098.02201233 Wh, totalout: 3237705.30602815 Wh, soc: 86
Wichtig hier der pv-Wert (pv: 0 W)
Kann es sein das der WR nicht mehr das Reading aktualisiert wenn die Sonne nichts mehr ,,liefert" und zum Abschluss keine ,,0" Watt mehr als letztes Reading liefert / aktualisiert ?
Zeigt dein WR denn den gleichen Wert dauerhaft im passenden Reading (zur gleichen Zeit) ?
Gruß
300P
Sorry war zu spät....
@Heiko,
@300P,
in meinem PV-Device hatte ich ein event-change-reading mit einem Wert von 20, welches leider dann Events verhindert hat.
Ich hab's korrigiert, und jetzt läuft das Modul mit 0 W und dem Mondsymbol.
Sorry für die Verwirrung, die ich gestiftet hab. Manchmal schießt man übers Ziel hinaus.
Viele Grüße Gisbert
@Gisbert,
ich habe auf meinem Testsystem den Style jetzt mal aktiviert.
Kann aber auch kein Problem feststellen. Screenshot ist vom Firefox mit diesem Style.
Man kann viel bei dem Style einstellen. Ich verwende hier keine besonderen EInstellungen, sondern so wie ausgeliefert.
Zitat von: 300P am 09 Oktober 2024, 18:38:15Zitat von: Parallix am 09 Oktober 2024, 14:11:29Wenn ich das richtig sehe, dann lässt sich aktuell nur eine "Battery Device" über das Attribut "setupBatteryDev" in FHEM integrieren.
Ist geplant, dass künftig auch mehrere "Battery Devices" anlegbar sind?
Das jedenfalls wäre super, da es (neben mir mit meinem Goodwe GW25K-ET) sicherlich einige Leute gibt, die System mit mehreren mehr als einem Speicher haben.
Das laßt sich bislang doch sauber über einen Dummy bewerkstelligen, der diese (s.u.) Reading durch eine zyklische Berechnung gefüllt bekommt. O:-)
...
Natürlich gibt es Wege, um auch den zweiten Akku ins System zu bekommen. Sauber ist das aber nicht, da Funktionen, die auf Basis von "Battery Device" arbeiten, nur einen Akku sehen. Oder sehe ich das etwas falsch?
Guten Morgen,
welche Funktion beabsichtigst du denn damit dann abzubilden ?
Die einzelnen "Battery Device" sind doch ebenfalls mit allen Readings noch innerhalb von FHEM greifbar.
Gruß
300P
Zitat von: Gisbert am 09 Oktober 2024, 22:24:41@Heiko,
@300P,
in meinem PV-Device hatte ich ein event-change-reading mit einem Wert von 20, welches leider dann Events verhindert hat.
Ich hab's korrigiert, und jetzt läuft das Modul mit 0 W und dem Mondsymbol.
Sorry für die Verwirrung, die ich gestiftet hab. Manchmal schießt man übers Ziel hinaus.
Viele Grüße Gisbert
Kann ich nachvollziehen - Ich bin manchmal auch blind wie ein Fisch.....
Hallo Heiko,
danke fürs Testen des Flex Styles bei dir.
Es ist tatsächlich so, dass auf dem Laptop diese ominöse erste, ziemlich große, leere Zeile nicht auftritt. Das hatte ich bisher nicht bemerkt, da ich den Flex Style nur auf dem Handy nutze. Leider ist es aber dort der Fall. Es hat ganz bestimmt etwas mit den Einstellungen, Css, ... zu tun, die ich aber nicht verstehe.
Dazu müsste sich jemand damit beschäftigen, der etwas davon versteht, vorausgesetzt es gibt eine Motivation dazu. Ich finde den Style für Handys am besten, da alles recht ordentlich und einheitlich aussieht, was bei allen anderen Styles nicht der Fall ist. Das einzige, was man für die Darstellung fürs eigene Handy machen muss, ist die Größe an den eigenen Bildschirm anzupassen, aber vielleicht ist sogar das überflüssig, falls man's richtig anwendet.
Da der Flex Style offenbar nicht mehr gepflegt wird, ist eine Hoffnung auf Besserung vermutlich das einzige, was bleibt.
Viele Grüße Gisbert
Mal in betracht gezogen das es dein Handybrowser ist?
Zitat von: kask am 10 Oktober 2024, 16:36:08Mal in betracht gezogen das es dein Handybrowser ist?
Hallo kask,
ich nutze Chrome. Ein Test mit Firefox ergab das identische Ergebnis. Fully hatte ich testweise installiert - da trat es ebenfalls auf.
Welcher Browser wäre denn geeigneter?
Viele Grüße Gisbert
Zitat von: 300P am 10 Oktober 2024, 08:57:47Guten Morgen,
welche Funktion beabsichtigst du denn damit dann abzubilden ?
Die einzelnen "Battery Device" sind doch ebenfalls mit allen Readings noch innerhalb von FHEM greifbar.
...
Die dynamische SoC Steuerung für Solarbatterien, um nur eine Funktionsklasse zu nennen.
Aber mal die ehrliche Frage :
Zitat:
SolarForecast
Das Modul SolarForecast erstellt auf Grundlage der Werte aus generischen Quellen eine Vorhersage für den solaren Ertrag und integriert weitere Informationen als Grundlage für darauf aufbauende Steuerungen.
Zur Erstellung der solaren Vorhersage kann das Modul SolarForecast unterschiedliche Dienste und Quellen nutzen.
Ja, das (SoC) ist aktuell ja schon in der aktuellen Version für die Entscheidung zur Ladung für eine Batterie enthalten.
Meiner Ansicht nach sind aber (u.a.) Batteriesteuerungen nicht das eigentliche Ziel diese Modules, auch wenn schon ein Ansatz da ist.
Das würde ansonsten eine "Eierlegende Wollmilchsau" die am Ende dann irgendwann kaum einer überblickt bzw. beherrscht.
(Falls / Wenn DS_Starter "alles" integrieren würde)
Gruß
300P
Moin Gisbert,
ich habe auf meinem Samsung Galaxy und dem Chrome Browser auch kein Problem mit dem Style feststellen können (Screenshot).
Allgemein wäre in dem Modul selbst bzgl. Styles nichts zu machen. Wir verwenden FHEM Standard Klassen für den Tabellenaufbau. Wenn überhaupt müsste jemand den Style in Pflege nehmen und ggf. anpassen.
Allerdings kann ich, wie oben geschrieben, kein Problem auf meinem Handy sehen.
LG,
Heiko
moin,
hab schon lange nicht mehr reingeschaut und hab jetzt gesehen, dass ihr die flowGraphic verändert habt (sehr schön).
Frage:
Gibts eine Möglichkeit, die flowGraphic in der Höhe (nicht in der Breite) zu variieren? Ich nutze den dark style, da überlappen sich die "Engergieflüsse" etwas zu sehr imho ;)
Zitat von: DS_Starter am 11 Oktober 2024, 09:00:48Moin Gisbert,
ich habe auf meinem Samsung Galaxy und dem Chrome Browser auch kein Problem mit dem Style feststellen können (Screenshot).
LG,
Heiko
Hallo Heiko,
vielen Dank fürs Testen, und eigentlich sind deine Nachrichten gute Nachrichten.
Es ist nicht auszuschließen, dass ich irgendetwas an den Einstellungen beim Flex Style vorgenommen hab, was dieses Verhalten auslöst. Ich werde den Flex Style entfernen und von Grund auf neu installieren und sehen, was dann dabei herauskommt.
Viele Grüße Gisbert
Hallo grappa24,
naja es gibt das Attr flowGraphicSize.
Das hilft aber in dem Fall auch nicht, da zwar die Höhe größer wird, aber die Proportionen zwischen den Elementen gleich bleiben, was auch gut so ist.
Ab einer bestimmten Menge an Consumern kommt die Darstellung an ihre Grenzen.
Vllt. fällt kask dazu noch etwas ein.
LG,
Heiko
Zitat von: DS_Starter am 11 Oktober 2024, 14:18:40Ab einer bestimmten Menge an Consumern kommt die Darstellung an ihre Grenzen.
Mit der alten Darstellung hat's sehr gut funktioniert. Was fehlt, ist einfach mehr Abstand zwischen dem "Haus" und den einzelnen Verbrauchern.
Na, das bekommen wir sicherlich hin.
Man könnte die Consumericons versetzen je nach ShowConsumerPower & ShowConsumerRemainTime Ansicht.
Der Platz wird ja dafür immer vorgehalten auch wenn nicht sichtbar.
Mann könnte die Sonne und das Haus weiter ins Zentrum rücken.
Das gefällt mir eigentlich auch besser so.
Screenshot 2024-10-11 195814.png
Original ist es so:
Screenshot 2024-10-11 200316.png
Dazu natürlich das ganze Zentrum etwas hochrücken und die flows dementsprechend mit nachziehen.
Eventuell den StartOffset vertikal der einzelnen Consumerflows noch nachkorrigieren.
Screenshot 2024-10-11 200603.png
@kask,
Ich würde das nicht so quetschen. Fünfstellige Werte, z.B. 19000 W sollten schon als Einspeisung in das "Haus" möglich sein.
Wir könnten die Viewbox ruhig ein wenig höher machen und den Consumern ein bisschen mehr Raum nach unten geben.
Ich bin gerade bei den Vorbereitungen für mehrere Inverter was auch auf den Code in der sub _flowGraphic Einfluß haben wird. Mit der Version kannst du dann gerne etwas experimentieren.
LG
ZitatMan könnte die Consumericons versetzen je nach ShowConsumerPower & ShowConsumerRemainTime Ansicht.
Der Platz wird ja dafür immer vorgehalten auch wenn nicht sichtbar.
Nein, den Platz gebe ich frei wenn keine Consumer angezeigt werden sollen oder es keine gibt.
Aber nicht den Platz für die Texte. Zumindest hat es bei mir keine Auswirkung ob ich die Texte ausblende oder nicht.
Habe diesbezüglich auch nichts im Code gesehen.
Du machst den Platz generell frei wenn es keine Consumer gibt. Der Platz für die Texte wird aber bei bestehenden Consumern immer reserviert.
Zitat von: DS_Starter am 11 Oktober 2024, 20:32:25Ich würde das nicht so quetschen. Fünfstellige Werte, z.B. 19000 W sollten schon als Einspeisung in das "Haus" möglich sein.
Ach so, und dann möchte ich folgendes auch noch korrigieren. Denn die Winkel werden eher stumpfer, da nur die Endpunkte der Flows nur horizontal verschoben wurden .
Somit wird es eher mehr platz anstatt weniger.
Kann man die ,,fliessenden" Ketten nicht ,,einfach mal" so um die 50 % schmaler versuchen?
Hallo DS_Starter,
ich habe Dein Modul jetzt schon länger erfolgreich im Einsatz. Danke dafür. Zwei Probleme konnte ich aber nicht lösen:
Verbrauchsprognose: Ich steuere über die Prognose den maximalen Füllgrad der Solarbatterie und das Laden meines E-Autos. Aktuell beginnt die Heizperiode und damit steigt durch meine Wärmepumpe der Stromverbrauch. Wenn ich es richtig verstehe, berechnet sich die Verbrauchsprognose aber aufgrund der letzten 30 Tage und liegt damit viel zu niedrig. Gibt es eine Möglichkeit, den Zeitraum einzuschränken und nur den Verbrauch des letzten Tages zu berücksichtigen?
statistic_dayAfterTomorrowPVforecast: Hier werden die Daten vom DWD nicht komplett ausgewertet, obwohl fc2_xx_Rad1h ordentliche Werte anzeigt. Laut "get solAPIData" wird nur bis fc1_23_Rad1h eingelesen. Woran kann das liegen?
Gruß
Tupol
@kask,
ZitatAber nicht den Platz für die Texte.
Nein, nur wenn Consumer ein/aus bzw. vorhanden/n.v.
@tupol,
ZitatGibt es eine Möglichkeit, den Zeitraum einzuschränken und nur den Verbrauch des letzten Tages zu berücksichtigen?
Bis jetzt gibt es nur das Attr affectConsForecastIdentWeekdays um gleiche Wochentage einzubeziehen.
Könnte ich mir aber mal anschauen.
Zitatstatistic_dayAfterTomorrowPVforecast: Hier werden die Daten vom DWD nicht komplett ausgewertet, obwohl fc2_xx_Rad1h ordentliche Werte anzeigt. Laut "get solAPIData" wird nur bis fc1_23_Rad1h eingelesen. Woran kann das liegen?
Das liegt an der internen Normierung der Verarbeitung auf 48h in die Zukunft. Ich musste mich auf einen Wert festlegen um alle API's und deren Abrufe gleich behandeln zu können.
LG
Könnte mal jemand eine umfassende Liste aller Attribute anlegen? Idealerweise im Wiki.
LG
pah
Hallo pah,
das Wiki baue ich immer weiter aus. Da fehlt noch vieles.
Schaffe aber auch nicht alles so schnell wie ich es mir wünsche.
Könnte Unterstützung von der Community gut gebrauchen.
LG
@kask, @all,
in meinem contrib liegt die V 1.36.0
In der V sind die Vorbereitungen für ein Multiinverter Setup getroffen.
Ein Schritt ist die Umbenennung des Attr setupInverterDev in setupInverterDev01.
Weiterhin gibt es einen Getter valInverter. An dieser Stelle werden die Betriebsparameter der Inverter zentral gehalten und einsehbar.
WICHTIG, ich habe die Version getestet, aber es sind intern recht viele Änderungen an verschiedenen Stellen. Bitte die V erstmal mit Vorsicht genießen.
Nach dem Download ist ein direkter Restart zwingend notwendig damit die automatische Attr Umbenennung funktioniert.
@kask, in der Grafik wären wir jetzt an dem Schritt den/die Inverter (die Sonne) auf die Ebene der Producer zu heben und an den Platz der bisherigen Sonne ein "Sammelicon" zu platzieren. Vllt. erstmal irgendeinen Platzhalter bis wir etwas passendes gefunden haben.
LG,
Heiko
@tupol,
Zitatstatistic_dayAfterTomorrowPVforecast: Hier werden die Daten vom DWD nicht komplett ausgewertet, obwohl fc2_xx_Rad1h ordentliche Werte anzeigt. Laut "get solAPIData" wird nur bis fc1_23_Rad1h eingelesen. Woran kann das liegen?
Ich habe beim Model DWD nochmal genauer geschaut. Ich denke ich habe eine Möglichkeit zur Erweiterung der Prognose in Abhängigkeit des Attr forecastDays im DWD-Device gefunden.
Schaue ich mir am WE aber nochmal genauer an.
Moin,
@tupol in meinem contrib liegt ein Update.
Damit ist die Prognose für Übermorgen (dayAfterTomorrowPVforecast) für das Model DWD möglich, sofern in dem relevanten DWD-Device das Attr forecastDays > 1 gesetzt ist.
Achtung, wie in #1189 geschrieben ist ein sofortiger Restart nötig!
LG,
Heiko
@kask, ich habe schon eine Variante für die Producerreihe inkl Inverter im Kopf. Brauchst an der Stelle erstmal nicht tätig werden. Vllt. schaffe ich morgen schon einen ersten Wurf.
LG
sehr gut ;)
Hallo Heiko,
Zwischenfrage:
Setzt du der Vollständigkeit halber irgendwann auch noch evtl. die beiden Setter ,,setupStringAzimuth" / ,,setupStringDeclination" noch in Attribute um ?😉
Gruß
300P
Hi 300P,
die beiden Einstellungen habe ich extra als Readings belassen damit man sie bei Nachführungsanlagen automarisiert dynamisch setzen kann ohne eine Attributänderung zu haben die man speichern müsste und demzufolge immer ein rotes Fragezeichen.
Weiss nicht ob jemand ein solches System im Einsatz hat.
Lg,
Heiko
Okay - das ist ein schlagendes Argument 👍
Guten Morgen @all,
in meinem contrib liegt ein update des Moduls.
Das PV-Icon, d.h. der (später die) Inverter, ist nun Bestandteil der Producerebene.
An seinem bisherigen Platz erscheint ein "Knoten"-Icon, ein Platzhalter für eine Zusammenführung der erzeugten Energie vor der Verteilung. Die Farbgebung ist abhängig von aktiv/inaktiv.
Im Anhang sieht man die Gestaltung mit und ohne anderen Producern. Mit Mouse-Over sieht man welches Device, welcher Wechselrichter mit dem Icon dargestellt wird.
Achtung, wie in #1189 geschrieben ist ein sofortiger Restart nötig!
@kask, ich würde dich jetzt bitten mal bei den Consumern den Abstand zum Haus zu vergrößern um eine Überlagerung der Ketten zu optimieren.
In der Flowgraphic sub sind viele Kommentare und Strukturierungen vorhanden. Du findest sicher schnell die entsprechenden Stellen.
Ich befasse mich erstmal wieder mit den nächsten inhaltlichen Weiterentwicklungen.
LG,
Heiko
;D
Zitat von: DS_Starter am 13 Oktober 2024, 10:24:20Achtung, wie in #1189 geschrieben ist ein sofortiger Restart nötig!
Hallo Heiko,
was ist denn zu tun, falls man das Update über Fhem (update all) durchführt?
Viele Grüße Gisbert
wie immer sofort umgesetzt, vielen Dank, ich häng mich mal mit ans contrib
Hallo Heiko,
noch eine 2. Nachricht von mir.
ich logge das Reading RestOfDayConsumptionForecast und sehe 2 Unregelmäßigkeiten:
- kleine Änderungen bei jeder vollen Stunde
- Nullwert, nachdem der Server neu gestartet wurde (nur die Linie Verbrauch_heute ist dargestellt)
Letzeres ist etwas störend - woran könnte es liegen?
Viele Grüße Gisbert
@Gisbert,
Zitatwas ist denn zu tun, falls man das Update über Fhem (update all) durchführt?
Das normale Update macht erst Sinn wenn ich die Weiterentwicklung offiziell einchecke.
Das schreibe ich immer in einem extra Beitrag mit einer Zusammenfassung der Änderungen wenn es sich lohnt.
Der User muß im Normalfall dann nichts unternehmen, ein Restart muß beim Regelupdate ohnehin durchgeführt werden.
Wenn doch etwas zu tun ist, schreibe ich es hier mit einem dicken Hinweis. :)
Zu deinen anderen Anmerkungen muß ich mir erstmal ein Bild machen.
LG
@Gisbert,
Zitatich logge das Reading RestOfDayConsumptionForecast und sehe 2 Unregelmäßigkeiten:
kleine Änderungen bei jeder vollen Stunde
Nullwert, nachdem der Server neu gestartet wurde (nur die Linie Verbrauch_heute ist dargestellt)
Es war ein Reihenfolgeproblem. Habe ich beseitigt und sollte nun kein Thema mehr sein.
Update wieder im contrib.
Kannst du downloaden und testen. Restart nicht vergessen!
LG
Noch mal ne Frage zur Flowgrafik: Gehört das "öffentliche Netz" nicht auch zu den "producern" (sorry, ich hab die Diskussion dazu nicht vollständig verfolgt ...)?
ZitatNoch mal ne Frage zur Flowgrafik: Gehört das "öffentliche Netz" nicht auch zu den "producern"
Genau genommen ist es ein Zwitter, es kann ja auch die Funktion eines Speichers einnehmen. ;)
Naja, wir fassen Producer, Inverter und Consumer sowie Speicher eng.
Es handelt sich immer um _eigene_ Geräte oder Anlagen.
LG
@all,
die Version 1.36.0 ist eingecheckt und wird morgen früh im Regelupdate enthalten sein.
Enthalten sind die folgenden Änderungen und Features:
- es gibt die Getter valInverter, valProducer und valStrings um die Betriebswerte der definierten Inverter und
Producer sowie String-Parameter anzuzeigen.
- das Attr setupInverterDev wird automatisch in das Attr setupInverterDev01 umgesetzt
- neues Attr affectConsForecastLastDays um bei der Berechnung der Verbrauchsprognose nur die
vergangenen X Tage zu berücksichtigen (Request von Tupol)
- beim Model DWD kann mit dem Statistik-Attr-Wert "dayAfterTomorrowPVforecast" die PV-Prognose für
den übernächsten Tag erzeugt werden (Request von Tupol)
- in der Flußgrafik ist PV-Icon auf die Producerebene gewandert, an dessen Stelle befindet sich ein
Platzhalter "Knoten"-Icon
- Bugfix für Reading "RestOfDayConsumptionForecast" (Meldung Gisbert)
- kleinere Fixes und Änderungen wie z.B. die Vorbereitung für Multi-Inverter Setup
Die Version liegt ebenfalls als Update in meinem contrib.
LG,
Heiko
Hallo,
vielen Dank an alle Maintainer für die tollen Module und für die umfangreichen Dokus dazu.
Ich habe nun auch das Modul SolarForecast auf meinem Raspi4 mit SSD installiert um es gründlich kennenzulernen. So wie es aussieht, läuft es Fehlerfrei.
Mir fällt nur auf, dass häufig die Meldung über veraltete Wetterdaten angezeigt wird.
Daten_veraltet.jpg
Die Anlagenkonfigurationsprüfung zeigt jedoch keine Fehler an.
Pruefung.jpg
Was mir auffällt, die DWD-Daten werden bei mir immer kurz nach der halben Stunde aktualisiert, nach Reading sind diese aber zu dieser Zeit meist schon ca. 90 Minuten alt.
Kurz nach erfolgter Aktualisierung verschwindet die Meldung, aber nur für einige Minuten.
Beispiel:
Die Aktualisierung der DWD_OpenData Readings (MOSMIX_S) erfolg um 19:32 Uhr mit Stand fc_time 18:00 Uhr.
Habe ich da noch etwas falsch parametriert oder vergessen etwas einzutragen?
Ist das nur bei mir so?
Die Zeitzonen sollten passen, am Raspi wird auch die korrekte Zeit angezeigt.
List Modul DWD_OpenData (Contrib. DS_Starter):
Internals:
ALERTS_IN_CACHE 16
FHEM_TZ
FUUID 670a4374-f33f-7df9-35fe-aec30059754d898d
NAME DWD_OpenData
NR 596
STATE alerts updated
TYPE DWD_OpenData
VERSION 1.017005
eventCount 131
READINGS:
2024-10-13 20:10:06 a_count 0
2024-10-13 20:10:06 a_dwdDocSize 100767
2024-10-13 20:10:06 a_dwdDocTime 2024-10-13 18:02:04Z
2024-10-13 20:10:06 a_state updated
2024-10-13 20:10:06 a_time 2024-10-13 20:10:05
2024-10-13 20:10:06 a_url https://opendata.dwd.de/weather/alerts/cap/COMMUNEUNION_CELLS_STAT/Z_CAP_C_EDZW_LATEST_PVW_STATUS_PREMIUMCELLS_COMMUNEUNION_DE.zip
2024-10-13 06:00:05 fc0_0_Neff 94
2024-10-13 06:00:05 fc0_0_RR1c 0.00
2024-10-13 06:00:05 fc0_0_Rad1h 0.00
2024-10-13 06:00:05 fc0_0_SunUp 0
2024-10-13 06:00:05 fc0_0_TTT 12.6
2024-10-13 06:00:05 fc0_0_time 00:00
2024-10-13 06:00:05 fc0_0_ww 3
2024-10-13 06:00:05 fc0_0_wwd Bewölkung zunehmend
2024-10-13 12:00:05 fc0_10_Neff 95
2024-10-13 12:00:05 fc0_10_RR1c 0.20
2024-10-13 12:00:05 fc0_10_Rad1h 290.00
2024-10-13 12:00:05 fc0_10_SunUp 1
2024-10-13 12:00:05 fc0_10_TTT 12.1
2024-10-13 12:00:05 fc0_10_time 10:00
2024-10-13 12:00:05 fc0_10_ww 61
2024-10-13 12:00:05 fc0_10_wwd durchgehend leichter Regen
2024-10-13 12:00:05 fc0_11_Neff 85
2024-10-13 12:00:05 fc0_11_RR1c 0.00
2024-10-13 12:00:05 fc0_11_Rad1h 600.00
2024-10-13 12:00:05 fc0_11_SunUp 1
2024-10-13 12:00:05 fc0_11_TTT 11.3
2024-10-13 12:00:05 fc0_11_time 11:00
2024-10-13 12:00:05 fc0_11_ww 3
2024-10-13 12:00:05 fc0_11_wwd Bewölkung zunehmend
2024-10-13 12:38:30 fc0_12_Neff 78
2024-10-13 12:38:30 fc0_12_RR1c 0.00
2024-10-13 12:38:30 fc0_12_Rad1h 870.00
2024-10-13 12:38:30 fc0_12_SunUp 1
2024-10-13 12:38:30 fc0_12_TTT 11.7
2024-10-13 12:38:30 fc0_12_time 12:00
2024-10-13 12:38:30 fc0_12_ww 2
2024-10-13 12:38:30 fc0_12_wwd Bewölkung unverändert
2024-10-13 12:53:59 fc0_13_Neff 84
2024-10-13 12:53:59 fc0_13_RR1c 0.00
2024-10-13 12:53:59 fc0_13_Rad1h 1070.00
2024-10-13 12:53:59 fc0_13_SunUp 1
2024-10-13 12:53:59 fc0_13_TTT 12.1
2024-10-13 12:53:59 fc0_13_time 13:00
2024-10-13 12:53:59 fc0_13_ww 2
2024-10-13 12:53:59 fc0_13_wwd Bewölkung unverändert
2024-10-13 14:40:59 fc0_14_Neff 45
2024-10-13 14:40:59 fc0_14_RR1c 0.00
2024-10-13 14:40:59 fc0_14_Rad1h 1230.00
2024-10-13 14:40:59 fc0_14_SunUp 1
2024-10-13 14:40:59 fc0_14_TTT 11.6
2024-10-13 14:40:59 fc0_14_time 14:00
2024-10-13 14:40:59 fc0_14_ww 1
2024-10-13 14:40:59 fc0_14_wwd Bewölkung abnehmend
2024-10-13 15:07:02 fc0_15_Neff 60
2024-10-13 15:07:02 fc0_15_RR1c 0.00
2024-10-13 15:07:02 fc0_15_Rad1h 1170.00
2024-10-13 15:07:02 fc0_15_SunUp 1
2024-10-13 15:07:02 fc0_15_TTT 11.9
2024-10-13 15:07:02 fc0_15_time 15:00
2024-10-13 15:07:02 fc0_15_ww 1
2024-10-13 15:07:02 fc0_15_wwd Bewölkung abnehmend
2024-10-13 15:47:10 fc0_16_Neff 69
2024-10-13 15:47:10 fc0_16_PPPP 1018.4
2024-10-13 15:47:10 fc0_16_RR1c 0.00
2024-10-13 15:47:10 fc0_16_Rad1h 990.00
2024-10-13 15:47:10 fc0_16_SunUp 1
2024-10-13 15:47:10 fc0_16_TTT 12.2
2024-10-13 15:47:10 fc0_16_time 16:00
2024-10-13 15:47:10 fc0_16_ww 2
2024-10-13 15:47:10 fc0_16_wwd Bewölkung unverändert
2024-10-13 17:33:14 fc0_17_Neff 62
2024-10-13 17:33:14 fc0_17_PPPP 1019.2
2024-10-13 17:33:14 fc0_17_RR1c 0.00
2024-10-13 17:33:14 fc0_17_Rad1h 650.00
2024-10-13 17:33:14 fc0_17_SunUp 1
2024-10-13 17:33:14 fc0_17_TTT 11.5
2024-10-13 17:33:14 fc0_17_time 17:00
2024-10-13 17:33:14 fc0_17_ww 1
2024-10-13 17:33:14 fc0_17_wwd Bewölkung abnehmend
2024-10-13 18:33:38 fc0_18_Neff 39
2024-10-13 18:33:38 fc0_18_PPPP 1019.6
2024-10-13 18:33:38 fc0_18_RR1c 0.00
2024-10-13 18:33:38 fc0_18_Rad1h 320.00
2024-10-13 18:33:38 fc0_18_SunUp 1
2024-10-13 18:33:38 fc0_18_TTT 10.2
2024-10-13 18:33:38 fc0_18_time 18:00
2024-10-13 18:33:38 fc0_18_ww 1
2024-10-13 18:33:38 fc0_18_wwd Bewölkung abnehmend
2024-10-13 19:32:06 fc0_19_Neff 78
2024-10-13 19:32:06 fc0_19_PPPP 1021.0
2024-10-13 19:32:06 fc0_19_RR1c 0.00
2024-10-13 19:32:06 fc0_19_Rad1h 60.00
2024-10-13 19:32:06 fc0_19_SunUp 0
2024-10-13 19:32:06 fc0_19_TTT 8.90
2024-10-13 19:32:06 fc0_19_time 19:00
2024-10-13 19:32:06 fc0_19_ww 3
2024-10-13 19:32:06 fc0_19_wwd Bewölkung zunehmend
2024-10-13 06:00:05 fc0_1_Neff 91
2024-10-13 06:00:05 fc0_1_RR1c 0.30
2024-10-13 06:00:05 fc0_1_Rad1h 0.00
2024-10-13 06:00:05 fc0_1_SunUp 0
2024-10-13 06:00:05 fc0_1_TTT 12.5
2024-10-13 06:00:05 fc0_1_time 01:00
2024-10-13 06:00:05 fc0_1_ww 61
2024-10-13 06:00:05 fc0_1_wwd durchgehend leichter Regen
2024-10-13 19:32:06 fc0_20_Neff 62
2024-10-13 19:32:06 fc0_20_PPPP 1021.8
2024-10-13 19:32:06 fc0_20_RR1c 0.00
2024-10-13 19:32:06 fc0_20_Rad1h 0.00
2024-10-13 19:32:06 fc0_20_SunUp 0
2024-10-13 19:32:06 fc0_20_TTT 7.90
2024-10-13 19:32:06 fc0_20_time 20:00
2024-10-13 19:32:06 fc0_20_ww 3
2024-10-13 19:32:06 fc0_20_wwd Bewölkung zunehmend
2024-10-13 19:32:06 fc0_21_Neff 56
2024-10-13 19:32:06 fc0_21_PPPP 1022.4
2024-10-13 19:32:06 fc0_21_RR1c 0.00
2024-10-13 19:32:06 fc0_21_Rad1h 0.00
2024-10-13 19:32:06 fc0_21_SunUp 0
2024-10-13 19:32:06 fc0_21_TTT 7
2024-10-13 19:32:06 fc0_21_time 21:00
2024-10-13 19:32:06 fc0_21_ww 2
2024-10-13 19:32:06 fc0_21_wwd Bewölkung unverändert
2024-10-13 19:32:06 fc0_22_Neff 48
2024-10-13 19:32:06 fc0_22_PPPP 1022.6
2024-10-13 19:32:06 fc0_22_RR1c 0.00
2024-10-13 19:32:06 fc0_22_Rad1h 0.00
2024-10-13 19:32:06 fc0_22_SunUp 0
2024-10-13 19:32:06 fc0_22_TTT 6.30
2024-10-13 19:32:06 fc0_22_time 22:00
2024-10-13 19:32:06 fc0_22_ww 1
2024-10-13 19:32:06 fc0_22_wwd Bewölkung abnehmend
2024-10-13 19:32:06 fc0_23_Neff 52
2024-10-13 19:32:06 fc0_23_PPPP 1022.8
2024-10-13 19:32:06 fc0_23_RR1c 0.00
2024-10-13 19:32:06 fc0_23_Rad1h 0.00
2024-10-13 19:32:06 fc0_23_SunUp 0
2024-10-13 19:32:06 fc0_23_TTT 5.70
2024-10-13 19:32:06 fc0_23_time 23:00
2024-10-13 19:32:06 fc0_23_ww 1
2024-10-13 19:32:06 fc0_23_wwd Bewölkung abnehmend
2024-10-13 06:00:05 fc0_2_Neff 91
2024-10-13 06:00:05 fc0_2_RR1c 0.20
2024-10-13 06:00:05 fc0_2_Rad1h 0.00
2024-10-13 06:00:05 fc0_2_SunUp 0
2024-10-13 06:00:05 fc0_2_TTT 12.6
2024-10-13 06:00:05 fc0_2_time 02:00
2024-10-13 06:00:05 fc0_2_ww 61
2024-10-13 06:00:05 fc0_2_wwd durchgehend leichter Regen
2024-10-13 06:00:05 fc0_3_Neff 91
2024-10-13 06:00:05 fc0_3_RR1c 0.30
2024-10-13 06:00:05 fc0_3_Rad1h 0.00
2024-10-13 06:00:05 fc0_3_SunUp 0
2024-10-13 06:00:05 fc0_3_TTT 12.4
2024-10-13 06:00:05 fc0_3_time 03:00
2024-10-13 06:00:05 fc0_3_ww 61
2024-10-13 06:00:05 fc0_3_wwd durchgehend leichter Regen
2024-10-13 06:00:05 fc0_4_Neff 92
2024-10-13 06:00:05 fc0_4_RR1c 0.40
2024-10-13 06:00:05 fc0_4_Rad1h 0.00
2024-10-13 06:00:05 fc0_4_SunUp 0
2024-10-13 06:00:05 fc0_4_TTT 12.4
2024-10-13 06:00:05 fc0_4_time 04:00
2024-10-13 06:00:05 fc0_4_ww 61
2024-10-13 06:00:05 fc0_4_wwd durchgehend leichter Regen
2024-10-13 06:00:05 fc0_5_Neff 94
2024-10-13 06:00:05 fc0_5_RR1c 0.40
2024-10-13 06:00:05 fc0_5_Rad1h 0.00
2024-10-13 06:00:05 fc0_5_SunUp 0
2024-10-13 06:00:05 fc0_5_TTT 12.4
2024-10-13 06:00:05 fc0_5_time 05:00
2024-10-13 06:00:05 fc0_5_ww 61
2024-10-13 06:00:05 fc0_5_wwd durchgehend leichter Regen
2024-10-13 12:00:05 fc0_6_Neff 93
2024-10-13 12:00:05 fc0_6_RR1c 0.40
2024-10-13 12:00:05 fc0_6_Rad1h 0.00
2024-10-13 12:00:05 fc0_6_SunUp 0
2024-10-13 12:00:05 fc0_6_TTT 12.4
2024-10-13 12:00:05 fc0_6_time 06:00
2024-10-13 12:00:05 fc0_6_ww 61
2024-10-13 12:00:05 fc0_6_wwd durchgehend leichter Regen
2024-10-13 12:00:05 fc0_7_Neff 99
2024-10-13 12:00:05 fc0_7_RR1c 0.50
2024-10-13 12:00:05 fc0_7_Rad1h 0.00
2024-10-13 12:00:05 fc0_7_SunUp 0
2024-10-13 12:00:05 fc0_7_TTT 12.2
2024-10-13 12:00:05 fc0_7_time 07:00
2024-10-13 12:00:05 fc0_7_ww 61
2024-10-13 12:00:05 fc0_7_wwd durchgehend leichter Regen
2024-10-13 12:00:05 fc0_8_Neff 99
2024-10-13 12:00:05 fc0_8_RR1c 0.60
2024-10-13 12:00:05 fc0_8_Rad1h 0.00
2024-10-13 12:00:05 fc0_8_SunUp 1
2024-10-13 12:00:05 fc0_8_TTT 12.4
2024-10-13 12:00:05 fc0_8_time 08:00
2024-10-13 12:00:05 fc0_8_ww 61
2024-10-13 12:00:05 fc0_8_wwd durchgehend leichter Regen
2024-10-13 12:00:05 fc0_9_Neff 99
2024-10-13 12:00:05 fc0_9_RR1c 0.20
2024-10-13 12:00:05 fc0_9_Rad1h 90.00
2024-10-13 12:00:05 fc0_9_SunUp 1
2024-10-13 12:00:05 fc0_9_TTT 12.4
2024-10-13 12:00:05 fc0_9_time 09:00
2024-10-13 12:00:05 fc0_9_ww 61
2024-10-13 12:00:05 fc0_9_wwd durchgehend leichter Regen
2024-10-13 19:32:06 fc0_SunRise 07:29
2024-10-13 19:32:06 fc0_SunSet 18:34
2024-10-13 19:32:06 fc0_date 2024-10-13
2024-10-13 19:32:06 fc0_weekday So
2024-10-13 19:32:06 fc1_0_Neff 51
.........
.........
2024-10-13 19:32:06 fc6_8_Neff 79
2024-10-13 19:32:06 fc6_8_PPPP 1015.2
2024-10-13 19:32:06 fc6_8_RR1c 0.00
2024-10-13 19:32:06 fc6_8_Rad1h 0.00
2024-10-13 19:32:06 fc6_8_SunUp 1
2024-10-13 19:32:06 fc6_8_TTT 10.1
2024-10-13 19:32:06 fc6_8_time 08:00
2024-10-13 19:32:06 fc6_8_ww 3
2024-10-13 19:32:06 fc6_8_wwd Bewölkung zunehmend
2024-10-13 19:32:06 fc6_9_Neff 80
2024-10-13 19:32:06 fc6_9_PPPP 1015.0
2024-10-13 19:32:06 fc6_9_RR1c 0.00
2024-10-13 19:32:06 fc6_9_Rad1h 80.00
2024-10-13 19:32:06 fc6_9_SunUp 1
2024-10-13 19:32:06 fc6_9_TTT 10.6
2024-10-13 19:32:06 fc6_9_time 09:00
2024-10-13 19:32:06 fc6_9_ww 3
2024-10-13 19:32:06 fc6_9_wwd Bewölkung zunehmend
2024-10-13 19:32:06 fc6_SunRise 07:38
2024-10-13 19:32:06 fc6_SunSet 18:23
2024-10-13 19:32:06 fc6_date 2024-10-19
2024-10-13 19:32:06 fc6_weekday Sa
2024-10-13 19:32:06 fc_coordinates xx.x,xx.xx,388.0
2024-10-13 19:32:06 fc_copyright Datenbasis: Deutscher Wetterdienst
2024-10-13 19:32:06 fc_description ROTH
2024-10-13 19:32:06 fc_dwdDocSize 39729154
2024-10-13 19:32:06 fc_dwdDocTime 2024-10-13 16:43:03Z
2024-10-13 19:32:06 fc_state updated
2024-10-13 19:32:06 fc_station 10765
2024-10-13 19:32:06 fc_time 2024-10-13 18:00:00
2024-10-13 19:32:06 fc_url https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024-10-13 20:10:05 nextUpdate 20:19:59
2024-10-13 20:10:06 state alerts updated
hmccu:
Attributes:
DbLogExclude .*
alertArea 809576143
comment Neff [%] - effektive Wolkenbedeckung
PPPP [hPa] - Druckäquivalent auf Meereshöhe
RR1c [kg/m2] - Niederschlagsmenge in der letzten Stunde
Rad1h [kJ/m2] - Globale Bestrahlungsstärke
SunUp - Sonnenaufgang (0: Nacht, 1: Tag)
TTT [°C] - Trockenkugeltemperatur in 2 m Höhe über dem Boden
time - Zeit basierend auf dem Attribut timezone
ww - Wettercode (siehe WMO 4680/4677, SYNOP)
wwd - Beschreibung des deutschen Wettercodes
event-on-change-reading .*
forecastDays 6
forecastProperties TTT,Neff,ww,RR1c,PPPP,Rad1h,SunUp,SunRise,SunSet
forecastRefresh 1
forecastResolution 1
forecastStation 10765
forecastWW2Text 1
group Umwelt
icon weather_cloudy_light
room Wetter
timezone Europe/Berlin
List Modul SolarForecast:
Internals:
FUUID 670a35ea-f33f-7df9-e9ea-a0b5204e1eeb77a8
FVERSION 76_SolarForecast.pm:v1.35.0-s29216/2024-10-09
LCACHEFILE last write time: 20:17:38 whole Operating Memory
MODE Automatic - next Cycletime: 20:23:16
MODEL DWD
NAME SolarForecast
NR 595
NTFY_ORDER 50-SolarForecast
STATE updated
TYPE SolarForecast
eventCount 953
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV SolarForecast
SPGROOM
VERSION 1.35.0
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes unused
VERSION_SMUtils 1.27.2
OLDREADINGS:
READINGS:
2024-10-13 20:22:06 Current_AutarkyRate 100 %
2024-10-13 20:22:06 Current_BatCharge 83 %
2024-10-13 20:22:06 Current_Consumption -433 W
2024-10-13 20:22:06 Current_GridConsumption 2 W
2024-10-13 20:22:06 Current_GridFeedIn 0 W
2024-10-13 20:22:06 Current_PV 0 W
2024-10-13 20:22:06 Current_PowerBatIn 0 W
2024-10-13 20:22:06 Current_PowerBatOut -435 W
2024-10-13 20:22:06 Current_SelfConsumption 0 W
2024-10-13 20:22:06 Current_SelfConsumptionRate 0 %
2024-10-13 20:22:06 Current_Surplus 433 W
2024-10-13 20:00:00 LastHourGridconsumptionReal 3617 Wh
2024-10-13 20:00:00 LastHourPVforecast 0 Wh
2024-10-13 20:00:00 LastHourPVreal 0 Wh
2024-10-13 20:22:06 NextHours_Sum01_PVforecast 0 Wh
2024-10-13 20:22:06 NextHours_Sum02_PVforecast 0 Wh
2024-10-13 20:22:06 NextHours_Sum03_PVforecast 0 Wh
2024-10-13 20:22:06 NextHours_Sum04_ConsumptionForecast 1329 Wh
2024-10-13 20:22:06 NextHours_Sum04_PVforecast 0 Wh
2024-10-13 20:22:06 RestOfDayConsumptionForecast 1215 Wh
2024-10-13 20:22:06 RestOfDayPVforecast 0 Wh
2024-10-13 00:59:49 Today_Hour01_BatIn 0 Wh
2024-10-13 00:59:49 Today_Hour01_BatOut 262 Wh
2024-10-13 00:59:49 Today_Hour01_GridConsumption 1 Wh
2024-10-13 00:59:49 Today_Hour01_GridFeedIn 1 Wh
2024-10-13 00:59:49 Today_Hour01_PVreal 0 Wh
2024-10-13 01:59:49 Today_Hour02_BatIn 0 Wh
2024-10-13 01:59:49 Today_Hour02_BatOut 216 Wh
2024-10-13 01:59:49 Today_Hour02_GridConsumption 2 Wh
2024-10-13 01:59:49 Today_Hour02_GridFeedIn 2 Wh
2024-10-13 01:59:49 Today_Hour02_PVreal 0 Wh
2024-10-13 02:59:58 Today_Hour03_BatIn 0 Wh
2024-10-13 02:59:58 Today_Hour03_BatOut 221 Wh
2024-10-13 02:59:58 Today_Hour03_GridConsumption 1 Wh
2024-10-13 02:59:58 Today_Hour03_GridFeedIn 1 Wh
2024-10-13 02:59:58 Today_Hour03_PVreal 0 Wh
2024-10-13 03:59:49 Today_Hour04_BatIn 0 Wh
2024-10-13 03:59:49 Today_Hour04_BatOut 217 Wh
2024-10-13 03:59:49 Today_Hour04_GridConsumption 2 Wh
2024-10-13 03:59:49 Today_Hour04_GridFeedIn 2 Wh
2024-10-13 03:59:49 Today_Hour04_PVreal 0 Wh
2024-10-13 04:59:49 Today_Hour05_BatIn 0 Wh
2024-10-13 04:59:49 Today_Hour05_BatOut 227 Wh
2024-10-13 04:59:49 Today_Hour05_GridConsumption 1 Wh
2024-10-13 04:59:49 Today_Hour05_GridFeedIn 1 Wh
2024-10-13 04:59:49 Today_Hour05_PVreal 0 Wh
2024-10-13 05:59:49 Today_Hour06_BatIn 0 Wh
2024-10-13 05:59:49 Today_Hour06_BatOut 218 Wh
2024-10-13 05:59:49 Today_Hour06_GridConsumption 2 Wh
2024-10-13 05:59:49 Today_Hour06_GridFeedIn 2 Wh
2024-10-13 05:59:49 Today_Hour06_PVreal 0 Wh
2024-10-13 06:59:49 Today_Hour07_BatIn 0 Wh
2024-10-13 06:59:49 Today_Hour07_BatOut 222 Wh
2024-10-13 06:59:49 Today_Hour07_GridConsumption 2 Wh
2024-10-13 06:59:49 Today_Hour07_GridFeedIn 1 Wh
2024-10-13 06:59:49 Today_Hour07_PVreal 0 Wh
2024-10-13 07:59:49 Today_Hour08_BatIn 0 Wh
2024-10-13 07:59:49 Today_Hour08_BatOut 223 Wh
2024-10-13 07:59:49 Today_Hour08_GridConsumption 1 Wh
2024-10-13 07:59:49 Today_Hour08_GridFeedIn 2 Wh
2024-10-13 07:59:49 Today_Hour08_PVreal 0 Wh
2024-10-13 08:59:49 Today_Hour09_BatIn 6 Wh
2024-10-13 08:59:49 Today_Hour09_BatOut 354 Wh
2024-10-13 08:59:49 Today_Hour09_GridConsumption 12 Wh
2024-10-13 08:59:49 Today_Hour09_GridFeedIn 13 Wh
2024-10-13 08:59:49 Today_Hour09_PVforecast 214 Wh
2024-10-13 08:59:49 Today_Hour09_PVreal 65 Wh
2024-10-13 09:59:58 Today_Hour10_BatIn 85 Wh
2024-10-13 09:59:58 Today_Hour10_BatOut 493 Wh
2024-10-13 09:59:58 Today_Hour10_GridConsumption 4 Wh
2024-10-13 09:59:58 Today_Hour10_GridFeedIn 7 Wh
2024-10-13 09:59:58 Today_Hour10_PVforecast 691 Wh
2024-10-13 09:59:58 Today_Hour10_PVreal 572 Wh
2024-10-13 10:59:49 Today_Hour11_BatIn 478 Wh
2024-10-13 10:59:49 Today_Hour11_BatOut 799 Wh
2024-10-13 10:59:49 Today_Hour11_GridConsumption 143 Wh
2024-10-13 10:59:49 Today_Hour11_GridFeedIn 8 Wh
2024-10-13 10:59:49 Today_Hour11_PVforecast 1431 Wh
2024-10-13 10:59:49 Today_Hour11_PVreal 1015 Wh
2024-10-13 11:59:49 Today_Hour12_BatIn 2662 Wh
2024-10-13 11:59:49 Today_Hour12_BatOut 0 Wh
2024-10-13 11:59:49 Today_Hour12_GridConsumption 12 Wh
2024-10-13 11:59:49 Today_Hour12_GridFeedIn 293 Wh
2024-10-13 11:59:49 Today_Hour12_PVforecast 2146 Wh
2024-10-13 11:59:49 Today_Hour12_PVreal 3450 Wh
2024-10-13 12:59:56 Today_Hour13_BatIn 2536 Wh
2024-10-13 12:59:56 Today_Hour13_BatOut 0 Wh
2024-10-13 12:59:56 Today_Hour13_GridConsumption 13 Wh
2024-10-13 12:59:56 Today_Hour13_GridFeedIn 239 Wh
2024-10-13 12:59:56 Today_Hour13_PVforecast 2552 Wh
2024-10-13 12:59:56 Today_Hour13_PVreal 4039 Wh
2024-10-13 13:59:49 Today_Hour14_BatIn 2070 Wh
2024-10-13 13:59:49 Today_Hour14_BatOut 0 Wh
2024-10-13 13:59:49 Today_Hour14_GridConsumption 9 Wh
2024-10-13 13:59:49 Today_Hour14_GridFeedIn 436 Wh
2024-10-13 13:59:49 Today_Hour14_PVforecast 2814 Wh
2024-10-13 13:59:49 Today_Hour14_PVreal 3966 Wh
2024-10-13 14:59:49 Today_Hour15_BatIn 192 Wh
2024-10-13 14:59:49 Today_Hour15_BatOut 38 Wh
2024-10-13 14:59:49 Today_Hour15_GridConsumption 4 Wh
2024-10-13 14:59:49 Today_Hour15_GridFeedIn 1353 Wh
2024-10-13 14:59:49 Today_Hour15_PVforecast 2885 Wh
2024-10-13 14:59:49 Today_Hour15_PVreal 5034 Wh
2024-10-13 15:59:49 Today_Hour16_BatIn 0 Wh
2024-10-13 15:59:49 Today_Hour16_BatOut 1 Wh
2024-10-13 15:59:49 Today_Hour16_GridConsumption 1 Wh
2024-10-13 15:59:49 Today_Hour16_GridFeedIn 2094 Wh
2024-10-13 15:59:49 Today_Hour16_PVforecast 2361 Wh
2024-10-13 15:59:49 Today_Hour16_PVreal 4320 Wh
2024-10-13 16:59:49 Today_Hour17_BatIn 129 Wh
2024-10-13 16:59:49 Today_Hour17_BatOut 0 Wh
2024-10-13 16:59:49 Today_Hour17_GridConsumption 1 Wh
2024-10-13 16:59:49 Today_Hour17_GridFeedIn 1181 Wh
2024-10-13 16:59:49 Today_Hour17_PVforecast 1502 Wh
2024-10-13 16:59:49 Today_Hour17_PVreal 4471 Wh
2024-10-13 17:59:49 Today_Hour18_BatIn 39 Wh
2024-10-13 17:59:49 Today_Hour18_BatOut 663 Wh
2024-10-13 17:59:49 Today_Hour18_GridConsumption 46 Wh
2024-10-13 17:59:49 Today_Hour18_GridFeedIn 19 Wh
2024-10-13 17:59:49 Today_Hour18_PVforecast 667 Wh
2024-10-13 17:59:49 Today_Hour18_PVreal 608 Wh
2024-10-13 18:59:49 Today_Hour19_BatIn 0 Wh
2024-10-13 18:59:49 Today_Hour19_BatOut 349 Wh
2024-10-13 18:59:49 Today_Hour19_GridConsumption 9526 Wh
2024-10-13 18:59:49 Today_Hour19_GridFeedIn 1 Wh
2024-10-13 18:59:49 Today_Hour19_PVforecast 143 Wh
2024-10-13 18:59:49 Today_Hour19_PVreal 1 Wh
2024-10-13 19:59:56 Today_Hour20_BatIn 6 Wh
2024-10-13 19:59:56 Today_Hour20_BatOut 455 Wh
2024-10-13 19:59:56 Today_Hour20_GridConsumption 3617 Wh
2024-10-13 19:59:56 Today_Hour20_GridFeedIn 2 Wh
2024-10-13 19:59:56 Today_Hour20_PVreal 0 Wh
2024-10-13 20:22:06 Today_Hour21_BatIn 0 Wh
2024-10-13 20:22:06 Today_Hour21_BatOut 335 Wh
2024-10-13 20:22:06 Today_Hour21_GridConsumption 26 Wh
2024-10-13 20:22:06 Today_Hour21_GridFeedIn 18 Wh
2024-10-13 20:22:06 Today_Hour21_PVreal 0 Wh
2024-10-13 20:22:06 Today_MaxPVforecast 2885 Wh
2024-10-13 20:22:06 Today_MaxPVforecastTime 2024-10-13 14:00:00
2024-10-13 20:22:06 Today_PVdeviation -58.23 %
2024-10-13 20:22:06 Today_PVforecast 17406 Wh
2024-10-13 20:22:06 Today_PVreal 27541 Wh
2024-10-13 20:22:06 Today_SunRise 07:35
2024-10-13 20:22:06 Today_SunSet 18:28
2024-10-13 20:22:06 Tomorrow_ConsumptionForecast 12760 Wh
2024-10-13 20:22:06 Tomorrow_PVforecast 19996 Wh
2024-10-13 20:22:06 Tomorrow_SunRise 07:36
2024-10-13 20:22:06 Tomorrow_SunSet 18:26
2024-10-13 20:22:06 nextCycletime 20:23:16
2024-10-13 12:00:04 pvCorrectionFactor_12 1.31 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 85, Days in range: 1)
2024-10-13 13:00:04 pvCorrectionFactor_13 1.29 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 80, Days in range: 1)
2024-10-13 14:00:04 pvCorrectionFactor_14 1.21 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 85, Days in range: 1)
2024-10-13 15:00:04 pvCorrectionFactor_15 1.37 (automatic - old factor: 1, Sun Alt range: 30, Cloud range: 45, Days in range: 1)
2024-10-13 16:00:04 pvCorrectionFactor_16 1.42 (automatic - old factor: 1, Sun Alt range: 25, Cloud range: 60, Days in range: 1)
2024-10-13 17:00:04 pvCorrectionFactor_17 1.50 (automatic - old factor: 1, Sun Alt range: 15, Cloud range: 70, Days in range: 1)
2024-10-13 18:00:04 pvCorrectionFactor_18 0.96 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 60, Days in range: 1)
2024-10-13 19:00:04 pvCorrectionFactor_19 0.51 (automatic - old factor: 1, Sun Alt range: 0, Cloud range: 40, Days in range: 1)
2024-10-13 20:22:06 pvCorrectionFactor_Auto on_complex_ai
2024-10-12 12:48:13 setupStringAzimuth String_1=-38 String_2=-38
2024-10-12 10:49:45 setupStringDeclination String_1=30 String_2=30
2024-10-13 20:22:07 state updated
hmccu:
Attributes:
DbLogExclude .*
affect70percentRule 1
ctrlLanguage DE
event-on-change-reading .*
flowGraphicAnimate 1
group Hauskraftwerk
icon sani_solar
room Hauskraftwerk
setupBatteryDev Batt_Leistung pin=Batterieladung_pos:W pout=Batterieladung_neg:W intotal=Batterieladung_kWh:kWh outtotal=Batterieabgabe_kWh:kWh cap=13000 charge=Batterie_SOC
setupInverterDev PV_Leistung pv=state:W etotal=Energie_kWh:kWh capacity=3000
setupInverterStrings String_1,String_2
setupMeterDev Netzuebergabepunkt_Leistung gcon=Netzbezug_W:W contotal=Netzbezug_kWh:kWh gfeedin=Netzeinspeisung_W:W feedtotal=Netzeinspeisung_kWh:kWh conprice=0.3963:€ feedprice=0.0944:€
setupRadiationAPI DWD_OpenData
setupStringPeak String_1=4.55 String_2=4.55
setupWeatherDev1 DWD_OpenData
Für einen Denkanstoß wäre ich euch dankbar.
Gruß Reinhard
Hallo Reinhard,
der DWD aktualisiert die MOSMIX_S Daten stündlich ca. 25 Minuten nach jeder vollen Stunde. Allerdings gibt es zweimal am Tag, einmal Früh/Vormittag und einmal Abends einen GAP wo die Daten nicht akzualisiert werden.
Ich habe beim DWD auch schonmal einen Hinweis auf die genaue Zeit gefunden, habe es aber gerade nicht parat.
Das wäre also normal.
Meine Daten sind aktuell vom Stand 2024-10-13 19:00:00 mit Abrufzeit 2024-10-13 20:35:11.
Wenn das deine Beobachtung ist, wäre es ok.
Das Attr forecastDays kannst du gern auf 1-2 stellen. Mehr brauchen wir für SolarForecast nicht und auch alertArea nicht, es sei denn du verwendest das DWD Device noch für etwas anderes.
LG,
Heiko
@Reinhard,
soeben wurde das DWD Device bei mir um 2024-10-13 21:37:42 aktualisiert und jetzt den Datenstand 2024-10-13 20:00:00.
Für SF ist der DAtenstand nun auch wieder i.O.
LG
Zitat von: DS_Starter am 13 Oktober 2024, 20:25:09- es gibt die Gettr valInverter und valProducer um die Betriebswerte der definierten Inverter und
Producer anzuzeigen.
Hallo Heiko,
was genau sind die Betriebswerte?
Danke und Gruß,
Stefan
Zum Beispiel:
valInverter
Zeigt die ermittelten Betriebswerte des ausgewählten Wechselrichters oder aller definierten Wechselrichter.
ietotal Stand gesamte bisher erzeugte Energie des Wechselrichters (Wh)
igeneration aktuelle PV Erzeugung (W)
iicon die evtl. festgelegten Icons zur Darstellung des Gerätes in der Grafik
iname Name des Devices
invertercap die nominale Leistung (W) des Wechselrichters (falls definiert)
oder
valProducer
01 => palias => WindWheel
petotal => 350
pgeneration => 0
picon => Ventilator_wind@darkorange
pname => WindWheel
02 => palias => WindWheel
petotal => 350
pgeneration => 0
picon => sani_garden_pump
pname => WindWheel
03 => palias => WindWheel
petotal => 350
pgeneration => 0
picon => Heizung_FCU_green
pname => WindWheel
LG
Danke Heiko,
war ne dumme Frage.
Habs jetzt ausprobiert und liefert die Werte.
Danke,
Stefan
Zitat von: DS_Starter am 12 Oktober 2024, 10:47:37@tupol in meinem contrib liegt ein Update.
Damit ist die Prognose für Übermorgen (dayAfterTomorrowPVforecast) für das Model DWD möglich, sofern in dem relevanten DWD-Device das Attr forecastDays > 1 gesetzt ist.
Perfekt. Ich bin begeistert. Das hilft mir beim E-Auto-Laden. Top.
Würde mich freuen, wenn das auch noch mit dem ConsumerForcast klappt. :D
Gruß
tupol
Habe Deinen Update-Post übersehen. Vielen Dank für diese extrem schnelle Reaktion. Jetzt bin ich erstmal wunschlos zufrieden. :-)
Guten Abend,
kask hat mir eine Anpassung der Flowgrafik bzgl. des Abstands der Consumer bzw. deren Ketten zugearbeitet.
Vielen Dank dafür! :)
Ich habe auch noch einen kleinen Fix bzgl. der Iconfärbung Producer bzw. Inverter eingebaut. Bei 0 Leistung wurden sie nicht mehr grau.
Ist als 1.36.1 eingecheckt und für Eilige auch im contrib zum Download.
LG,
Heiko
Ich habe euch meine bisherigen Ergebnisse des Vergleiches mit den unterschiedlichen Einstellungen des experimentellen Attributs ctrlAreaFactorUsage im Anhang mitgegeben.
Zur Erinnerung:
trackFull der Flächenfaktor wird kontinuierlich abhängig vom Sonnenstand berechnet und auf die gesamte Globalstrahlung angewendet
trackShared der Flächenfaktor wird kontinuierlich abhängig vom Sonnenstand berechnet und auf einen approximierten Anteil der
Direktstrahlung an der Globalstrahlung angewendet
trackFlex kombiniert die Verfahren 'trackFull' und 'trackShared'. Es erfolgt eine Umschaltung von 'trackFull' auf 'trackShared'
bei einer Bewölkung von >=80%.
Alle drei Devices sind ansonsten identisch eingestellt und ohne! Korrektur. Es kommt nicht auf die Größe des Fehlers an, sondern auf die relative Abweichung des jeweilige Devices gegen '0'. Man sieht deutlich, dass trackFull bei überwiegend sonnigen Tagen am Besten abschneidet, trackShared eher bei mehr Bewölkung.
trackFlex stellt sich entweder ganz auf den besten Wert des Tages ein oder nähert sich zumindest dem Besten Wert, gehört aber bis jetzt niemals zu dem schlechtesten Kandidaten von den drei.
Ich werde es noch etwas verfolgen, denke aber dass ich trackFlex später als Standard für das Model DWD übernehme.
Die bis dato implementierte lernende Korrektur bzw. KI bleibt natürlich erhalten.
LG
Das deckt sich mit meinem subjektiven Empfinden bei der Bewertung der Nutzung dieser drei Parameter.
Hi Heiko,
bei mir will der Mond nicht erscheinen.
Habe 0 Watt Inverter ist grau aber die Sonne ist hell und kein Mond.
2024.10.14 22:10:31 1: Forecast DEBUG> collect Inverter 01 data - device: InverterDummy =>
2024.10.14 22:10:31 1: Forecast DEBUG> pv: 0 W, etotal: 34098304.2716315 Wh
2024.10.14 22:10:31 1: Forecast DEBUG> summary data of all Inverters - pv: 0 W, this hour Generation: 0 Wh
2024.10.14 22:10:31 1: Forecast DEBUG> collect Meter data - device: EnergyMeterDummy =>
2024.10.14 22:10:31 1: Forecast DEBUG> gcon: 913.2 W, gfeedin: 0 W, contotal: 1145461 Wh, feedtotal: 25444816 Wh
2024.10.14 22:10:31 1: Forecast DEBUG> collect Battery data: device=BatteryDummy =>
2024.10.14 22:10:31 1: Forecast DEBUG> pin=0 W, pout=1.23834252357483 W, totalin: 4235213.12162881 Wh, totalout: 4078391.44329729 Wh, soc: 19.9
Was habe ich überlesen oder übersehen?
Software ist die aktuelle von FHEM oder geht es da noch nicht?`
Danke und Gruß,
Stefan
Hallo Stefan,
schau mal in #1215. Entweder morgen früh updaten oder jetzt aus meinem contrib ziehen und restarten.
LG
Ah, ich dachte das hätte nur mit der grauen Färbung zu tun.
Habe es eingespielt und der Mond ist aufgegangen ;-)
Danke!
#1216
Am 10.10.2024 & 13.10.2024 stimmen die Farben nicht.
Was ist da jetzt besser? 3,4 oder -6,5. -47 oder +47 wenn der dritte negativ ist wäre es ja der -47 Wert.
Und ehrlich gesagt verstehe ich das da alles nicht so wirklich.
Mal ist ein negativer Wert besser mal ein Positiver. Null wäre das Optimum?
Hi kask,
doch stimmt so.
Besser ist der Wert, welcher "0" am nächsten ist. Egal von welcher Seite er sich nähert.
Man könnte auch sagen der absolut kleinste Wert ist am Besten.
Zur Rolle des "öffentlichen Netzes" = Grid:
Zitat von: DS_Starter am 13 Oktober 2024, 16:15:35es kann ja auch die Funktion eines Speichers einnehmen.
Nicht doch "Zwitter".
Das Grid ist, und zwar ganz präzise, ein Speicher mit unendlicher Kapazität. So etwas nennen wir in der Thermodynamik ein "Reservoir".
Allerdings gilt das nur, solange nicht der Netzbetreiber auf die Idee kommt, etwas abzuregeln...
LG
pah
Zitat von: DS_Starter am 14 Oktober 2024, 19:21:22kask hat mir eine Anpassung der Flowgrafik bzgl. des Abstands der Consumer bzw. deren Ketten zugearbeitet.
sieht jetzt sehr viel besser aus, auch von mir ein dickes Dankeschön!
]Meines Erachtens könnte man künftig noch folgende Aspekte berücksichtigen:
- Aufgrund von Regel-Trägheiten (des Wechselrichters) kommt es (insb. fehlender solarer Energie) hin und wieder zu Fällen, in aus dem (Batterie-)Speicher etwas über den Wechselrichter ins (öffentliche) Netz eingespeist wird.
- Bei Unterschreiten eines minimalen SOCs erfolgt (bei fehlender solarer Energie) ggf. auch einer Not-Nachladung des (Batterie-)Speichers aus dem Netz.
Diese Fälle lassen sich aktuell nicht optimal darstellen. Das wäre anders, wenn die Verbindungen
- Wechselrichter - (Batterie-)Speicher
- Wechselrichter - Netz
eine (Zähl-)Richtung ausweisen würden. Auf diese Weise kann die Richtung des Energieflusses durch einen positiven bzw. negativen Wert (am Zählpfeil) darstellt werden.
- Positiver Wert: Energie fließt in Richtung des (Zähl-)Pfeils
- Negativer Wert: Energie fließt entgegen der Richtung des (Zähl-)Pfeils
Dann könnte man auch die Verbindungen Netz-Verbraucher und Speicher-Verbraucher wegoptimieren. Alternativ könnte man natürlich auch die Pfeile in Abhängigkeit der Enerieflussrichtung drehen.
In meinem contrib liegt die V 1.37.0.
Mit dieser Version können bis zu drei Wechselrichter / Solar-Ladegeräte definiert werden (setupInverterDevXX).
Über zusätzliche optionale Keys strings und feed können die im Attr setupInverterStrings definierten Strings der Invertern zugeordnet werden sowie festgelegt werden dass der Inverter ausschließlich in das Grid einspeist (feed=grid). Später kommt noch 'ausschließlich Batterieladen' für Solar-Ladegeräte hinzu.
In der Flußgrafik wird die Producerebene passend sortiert. Zwei Beispiel im Anhang.
Es sieht alles schon ganz gut aus, die Version muß aber noch ein wenig mehr ausgetestet werden.
@kask, vllt. sollten wir das Grid etwas mehr nach links und die Batterie etwas mehr nach rechts verschieben.
Könnte besser sein.
@Parallix, behalte ich im Kopf. Allerdings gibt es bei unserer Flowgrafik keine Pfeile. Eine Flußrichtung wird durch die Kettenanimation dargestellt (Attr. flowGraphicAnimate = 1).
Edit: Falls jemand schon jetzt mehr als 3 Wechselrichter / Solar-Ladegeräte benötigt gebt mir einen Hinweis. Dann kann ich es gleich berücksichtigen.
LG,
Heiko
Zitat@kask, vllt. sollten wir das Grid etwas mehr nach links und die Batterie etwas mehr nach rechts verschieben.
Könnte besser sein.
Probier ich mal aus.
Hallo zusammen,
ich habe die Darstellung in der Flow noch etwas optimiert damit das Design bei unterschiedlichen Setups weitgehend stabil bleibt.
@kask, es gibt zur Steuerung für die Producerline einen Controlhash in Zeile 14204 - 14210.
Update im contrib.
LG
@Rewe2000,
ich habe die Meldungen bzgl. des Alters der DWD-Daten mal etwas intensiver verfolgt.
Es könnte evtl. in dem DWD-Modul ein Problem mit der Umrechnung des Zeitstempels aus UTC in die lokale Zeit geben und deswegen zu oft veraltete Daten melden.
Schau ich mir bei Gelegenheit mal an.
LG
Zur Darstellung in der Grafik: Warum nicht die Anzeige mit derjenigen von Floorplan "kreuzen" und die Positionierung der einzelnen Icons dem Benutzer überlassen?
Das könnte auch den Attributedschungel etwas lichten, denn das Konzept von Floorplan sieht ja vor, dass Position und weitere Aspekte beim Device gespeichert werden, nicht beim anzeigenden Modul.
So habe ich das übrigens auch beim Alarm-Modul gelöst.
LG
pah
Hallo Heiko,
ich vermute kein Problem mit der Zeitwandlung UTC nach MESZ. Das DWD_OpenData Modul holt bei mir die forecast-Daten nicht nach, sondern bereits kurz vor Veröffentlichung auf dem DWD-Server ab (XX:38 Uhr). Nachdem ja, bedingt durch das Attribut forecastResolution 1, die forecast-Daten nur einmal stündlich vom Server geholt werden, sind diese dann immer um ca. 1 Stunde "veraltet".
MOSMIX_S_2024101708_240.kmz 17-Oct-2024 08:42 38886633
MOSMIX_S_2024101709_240.kmz 17-Oct-2024 09:41 38871327
MOSMIX_S_2024101710_240.kmz 17-Oct-2024 10:42 38922693
MOSMIX_S_LATEST_240.kmz 17-Oct-2024 10:42 38922693
Stoße ich die Aktualisierung der Vorhersagedaten im DWD_OpenData Modul von Hand, nach Veröffentlichung auf der DWD-Homepage an (get DWD_OpenData forecast), dann werden die Daten sofort korrekt aktualisiert und alles passt wieder.
Ich als Anwender habe ja keine Möglichkeit die Minuten vorzugeben, wann die Abholung erfolgen soll, optimal wäre hier ein Zeitpunkt kurz nach Bereitstellung.
Wären denn aktuellere Vorhersagedaten auch vorteilhafter für die Berechnungen im SolarForcast Modul?
Andererseits sollte aufgrund der vielen Daten die Aktualisierung auch nicht mehrmals pro Stunde erfolgen.
Gruß Reinhard
Zitat von: Prof. Dr. Peter Henning am 17 Oktober 2024, 09:15:50Zur Darstellung in der Grafik: Warum nicht die Anzeige mit derjenigen von Floorplan "kreuzen" und die Positionierung der einzelnen Icons dem Benutzer überlassen?
Das könnte auch den Attributedschungel etwas lichten, denn das Konzept von Floorplan sieht ja vor, dass Position und weitere Aspekte beim Device gespeichert werden, nicht beim anzeigenden Modul.
So habe ich das übrigens auch beim Alarm-Modul gelöst.
LG
pah
Die Idee ist ja nicht schlecht. Aber, ich denke das ist nicht so einfach umzusetzen mit den Flowgrafiken. Die müssten dann ja anhand der Position auch die Richtung ändern können/müssen.
Ist nicht ganz so trivial das ganze, aber auch nicht unlösbar.
Mit der Flowgrafikerweiterung bin ich mal wieder an dem Punkt das man das ganze hätte Modular aufbauen sollen.
Das ist mitlerweile soviel was da passiert in dem Modul. Modularität hatte jetzt sicher schon getrumpft.
ZitatMit der Flowgrafikerweiterung bin ich mal wieder an dem Punkt das man das ganze hätte Modular aufbauen sollen.
Das ist mitlerweile soviel was da passiert in dem Modul. Modularität hatte jetzt sicher schon getrumpft.
Was hindert dich denn daran?
Alle Grafiken im Modul mit graphicSelect=none und ggf. graphicHeaderDetail=status ausschalten.
Dann bleiben quasi nur die Daten übrig.
Dann baust du ein eigenes Grafikmodul nach Lust und Laune, alle Daten stehen per Reading oder Schnittstelle zur Verfügung. Das Modul stellst du dann der Community zur Verfügung und alle haben etwas davon.
Und, voilà, schon ist die Modularität gegeben.
Auch die Consumersteuerung muß man hier nicht nutzen. Einfach nicht einrichten, etwas eigenes bauen und schon ist man fertig. Auch dafür kann jemand ein eigenes Modul bauen und die Daten von SF nutzen, kein Thema.
Das ist aber alles nicht in meinem Fokus. Mir gefällt es so wie es ist schon sehr gut und stellt alles dar was ich benötige.
Aber ich bin ja andererseits auch nicht daran gehindert, dein neues Grafikmodul statt der eingebauten Flowgrafik zu nutzen (siehe oben) wenn es mir besser gefällt bzw. Mehrwert bietet, why not?
Davon lebt doch unsere Community. :)
@pah
ZitatSo habe ich das übrigens auch beim Alarm-Modul gelöst.
Ich kenne in deinem Alarm-Modul (was ich auch nutze) nur das Interface für die Einrichtung / Setup.
Gibt es dafür auch eine eingebaute grafische Darstellung der Sensoren/Aktoren mit der Möglichkeit einer Positionierung?
Wenn ja, gib doch bitte einen kurzen Hinweis darauf wo dies zu finden ist (auch wenn es hier OT) ist.
Möglicherweise habe ich da auch etwas falsch verstanden und die Aussage ist auf Floorplan bezogen.
LG
Hallo Reinhard,
hmmm... wenn das DWD-Modul z.B. 14:38 aktualisiert, müßten die Daten von 14:00 sein, da der DWD nach eigener Aussage ca. 14:20 (XX:20) die DAten aktuell zur Verfügung stellt.
Aber wenn du sagst mit get ... zur richtigen Zeit klappt es?
Muß ich mal beobachten. Als Workaround käme ggf. ein regelmäßiges "AT" in Frage.
ZitatWären denn aktuellere Vorhersagedaten auch vorteilhafter für die Berechnungen im SolarForcast Modul?
Ja, die Wetterdaten ändern sich auch mal. Dann würde die Prognose angepasst.
Thema DWD-Modul: Leider ist der Maintainer bisher noch nicht wieder aktiv geworden, deswegen liegt es noch immer in meinem contrib. Weiß aktuell nicht wie/wann es an dieser Stelle weitergeht.
LG
Hallo Reinhard, @all,
in meinem contrib liegt ein Update des DWD_OpenData Moduls.
Die forecast Daten des DWD werden jetzt im letzten Viertel der laufenden Stunde abgeholt (vorher im dritten Viertel).
Dadurch sollte gewährleistet sein dass der DWD seine aktualisierten Daten bereitgestellt hat.
Grüße,
Heiko
Zitat von: DS_Starter am 17 Oktober 2024, 19:00:16Möglicherweise habe ich da auch etwas falsch verstanden und die Aussage ist auf Floorplan bezogen.
So halb. Beim Alarm-Modul gibt es keine Grafik (ist aber eigentlich eine gute Idee...). Aber die Alarmparameter werden bei den Sensoren und Aktoren als globale userAttr gespeichert, das ist bei Floorplan auch so.
Meine Vorstellung ist, dass - ähnlich wie bei Alarm - die Standardanzeige eines Powermanagementsystems eine Tabelle mit Buttons und Eingabefeldern ist. Das halte ich für wesentlich komfortabler als den Attributedschungel. Die Grafik könnte man als separates Widget realisieren, das auch in Webseiten einbindbar ist.
Ich habe - unabhängig von Eurer Arbeit - schon mit einer solchen Realisierung begonnen.
LG
pah
Ah ... jetzt kann ich das besser einordnen, danke für die Rückinfo.
LG,
Heiko
ZitatMeine Vorstellung ist, dass - ähnlich wie bei Alarm - die Standardanzeige eines Powermanagementsystems eine Tabelle mit Buttons und Eingabefeldern ist. Das halte ich für wesentlich komfortabler als den Attributedschungel.
Ja, das hat was.
Das bringt mich auf die Idee mein Schlüsselsystem auch auf z.B. solche Grundeinstellungen wie:
flowGraphicAnimate
flowGraphicConsumerDistance
flowGraphicShift
flowGraphicShowConsumer
flowGraphicShowConsumerRemainTime
flowGraphicSize
auszubauen. Dann würde reichen:
flowGraphic animate=x consumerdist=x showconsumer=x size=x ....Das spart auch eine Menge Attribute. Ist nur nicht grafisch aufbereitet, aber gefällt mir.
Hallo Heiko,
vielen Dank für das schnelle Update des DWD_OpenData Moduls (Vers. 1.17.6).
Ich hatte mir zwischenzeitlich mit einem at beholfen, doch nun klappt die Aktualisierung nach Bereitstellung der aktuellen Daten auch ohne weitere Hilfsmittel.
Gruß Reinhard
Wallbox als Consumer?
Ich glaub, ich hab das schon mal gefragt, sorry ....
Ich hab einen Fronius Wattpilot mit ModBus Schnittstelle, bekomme ich die irgendwie als Consumer in das SolarForecast Modul?
Grüße, Dieter
Hallo Grappa,
sobald du deine Wallbox als Modbus-Device in FHEM eingebunden hast solltest du sie auch ins SF-Modul einbinden können.
Vorausgesetzt (On/Off Schaltung) ist aber, es werden die notwendigen Readings / Steuerbefehle im Modbus-Device dann dort im Device vorhanden sein. ;)
Gruß
300P
Guten Morgen,
in meinem contrib liegt ein Update.
Implementiert ist die Variante Solar-Ladegeräte im Attr setupInverterDevXX angeben zu können.
Man gibt dazu einfach den Key:
feed=bat
an.
Diese Geräte laden mit ihrer PV-Leistung nur die Batterie ohne ins Hausnetz einzuspeisen.
Die Grafik ändert sich dann entsprechend.
Restart nicht vergessen!
Edit: im contrib soeben upgedated
LG
Zitat von: 300P am 19 Oktober 2024, 09:46:11sobald du deine Wallbox als Modbus-Device in FHEM eingebunden hast solltest du sie auch ins SF-Modul einbinden können.
Da ich evcc am Laufen habe, habe ich dort MQTT aktiviert und hole mir die Werte von meiner Wallbox über ein MQTT-Device in FHEM 8)
@all,
die Datei in meinem contrib ist wieder upgedatet.
Es gibt ein Attrbibut flowGraphicControl welches die Attribute:
flowGraphicSize
flowGraphicAnimate
flowGraphicConsumerDistance
flowGraphicShowConsumer
flowGraphicShowConsumerDummy
flowGraphicShowConsumerPower
flowGraphicShowConsumerRemainTime
flowGraphicShift
ersetzt.
Die Funktionalitäten werden über Schlüssel (ihr kennt das schon) in dem neuen Attribut umgesetzt.
Nach Download und Restart! werden evtl. gesetzte obige Attribute automatisiert in das neue Attribut überführt. Ihr braucht nichts tun und bekommt eine entsprechende Meldung im Log:
...
2024.10.20 11:13:00.807 3: Device "openMeteo" -> The attribute 'flowGraphicAnimate' is replaced by 'flowGraphicControl'. Please press "save config" when restart is finished.
2024.10.20 11:13:00.808 3: Device "openMeteo" -> The attribute 'flowGraphicShowConsumerDummy' is replaced by 'flowGraphicControl'. Please press "save config" when restart is finished.
2024.10.20 11:13:00.808 3: Device "openMeteo" -> The attribute 'flowGraphicShowConsumerPower' is replaced by 'flowGraphicControl'. Please press "save config" when restart is finished.
2024.10.20 11:13:00.809 3: Device "openMeteo" -> The attribute 'flowGraphicShowConsumerRemainTime' is replaced by 'flowGraphicControl'. Please press "save config" when restart is finished.
2024.10.20 11:13:00.810 3: Device "openMeteo" -> The attribute 'flowGraphicSize' is replaced by 'flowGraphicControl'. Please press "save config" when restart is finished.
...
Edit: das Attr flowGraphicCss wird gelöscht. Ein Teil der Funktionalität wird noch in das Attr flowGraphicControl fließen, einTeil davon bleibt obsolet.
LG
Das Attrbibut flowGraphicControl hat noch ein paar mögliche Keys spendiert bekommen:
strokecolina Farbe einer inaktiven Linie
Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: gray
strokecolsig Farbe einer aktiven Signallinie
Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: red
strokecolstd Farbe einer aktiven Standardlinie
Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: darkorange
strokewidth Breite der Linien
Wert: Ganzzahl, default: 25
Damit kann man sich nun auch die Strichstärke indivduell anpassen was insbesondere bei vielen Consumern vorteilhaft sein kann. Weiter vorn hatte ich den Wunsch aufgeschnappt.
Das Update liegt im Contrib.
LG,
Heiko
@all,
nach weiteren Tests habe ich mich entschlossen die V 1.37.0 einzuchecken damit wieder ein gemeinsamer/definierter Aufsetzpunkt vorhanden ist.
Es ist etliches an Änderungen eingeflossen:
- mit den Attributen setupInverterDevXX können bis zu 3 Inverter/Solar-Lader eingebunden werden.
Die optionalen Keys "strings" und "feed" lassen die Zuordnung einer Teilmenge vorhandener Strings zu sowie
die Festlegung ob es sich um einen "Grid-only" Inverter oder evtl. um ein Solar-Ladegerät für die Batterie handelt.
- die Producer werden in ihrer Zeile entsprechend ihres Liefertyps sortiert und in einem definierten Rahmen eingefügt.
Dadurch bleibt das Design bei unterschiedlichem Setup weitgehend erhalten.
- ein neues Attribut flowGraphicControl ersetzt die Attribute:
"flowGraphicAnimate flowGraphicConsumerDistance flowGraphicShowConsumer flowGraphicShowConsumerDummy
flowGraphicShowConsumerPower flowGraphicShowConsumerRemainTime flowGraphicShift flowGraphicCss"
Diese Attribute sind zunächst inaktiv und werden in einem kommenden Release ganz entfernt.
- Im Attr flowGraphicControl gibt es die neuen Schlüssel strokecolina, strokecolsig, strokecolstd, strokewidth zur Anpassung
des Liniendesigns
- minor Fixes / Verbesserungen
Die V wird morgen früh per Regelupdate ausgeliefert.
Grüße,
Heiko
Zitatstrokecolina
Wer ist colina und warum soll ich sie streicheln?
Mal ernsthaft: Das mit den Keys in den Attributen ist zwar eine durchaus gute Idee. Allerdings muss man inzwischen wirklich ein Handbuch neben die Tastatur legen, wenn man das aufsetzen möchte.
Ich plädiere nach wie vor dafür, einen komfortablen Editor für den ganzen Schmonzes aufzusetzen.
LG
pah
:)
stroke color
inactive (von SVG Stroke Attributes)
Ein Aufsetzen eines Devices geht ohne all dies, denn diese Anpassungen sind nur für User interessant die vom Standard abweichen möchten.
Fast alle Attribute, außer die bei der Einrichtung explizit verlangt/abgefragt werden, sind optionaler Natur.
ZitatIch plädiere nach wie vor dafür, einen komfortablen Editor für den ganzen Schmonzes aufzusetzen.
Wenn jemand fit in JavaScript ist und ein .js für eine Oberfläche beisteuern möchte, kann das gern tun.
Das ist (leider) nicht meine Domäne.
LG
Heiko
Zitat von: 300P am 11 Oktober 2024, 08:32:11..........
Zitat:
SolarForecast
Das Modul SolarForecast erstellt auf Grundlage der Werte aus generischen Quellen eine Vorhersage für den solaren Ertrag und integriert weitere Informationen als Grundlage für darauf aufbauende Steuerungen.
Zur Erstellung der solaren Vorhersage kann das Modul SolarForecast unterschiedliche Dienste und Quellen nutzen.
.......
.....Meiner Ansicht nach sind aber (u.a.) ........nicht das eigentliche Ziel diese Modules, auch wenn schon ein Ansatz da ist.
Das würde ansonsten eine "Eierlegende Wollmilchsau" die am Ende dann irgendwann kaum einer überblickt bzw. beherrscht.
(Falls / Wenn DS_Starter "alles" integrieren würde)
Gruß
300P
==>>Da wäre sie wieder, diese komische und nicht vorhandene Tierart :o :) ;D ::) O:-)
OT:
Zitat von: 300P am 22 Oktober 2024, 19:17:58nicht vorhandene Tierart
Klar gibt es sie. Von der Sau ist alles verwendbar: Organe, Haut, Hirn und Knochen. Und sogar der Name kann noch nutzbringend eingesetzt werden.
LG
pah
Hallo zusammen,
nach dem heutigen Update muss ich leider feststellen das meine Grafik nicht mehr funktioniert. Alle Linien zwischen den Verbrauchern/Erzeugern/usw. sind verschwunden. Weiterhin gibt es keine "Infos" zur Batterie/Solar/usw. mehr in der Grafik (z.B. Solarleistung, Batterieladung usw).
Ich habe nach dem Update fhem neugestartet. Dabei wurden die Attr umgeschrieben. Dann gespeichert (rotes Fragezeichen) und noch mal Neustart.
Was muss ich nach dem Update jetzt neu einstellen das der Standart wiederhergestellt wird?
define 01_SolarForecast SolarForecast
attr 01_SolarForecast DbLogExclude .*
attr 01_SolarForecast DbLogInclude Today_PVdeviation,AllPVforecastsToEvent,LastHourPVforecast,LastHourPVreal
attr 01_SolarForecast affect70percentRule 0
attr 01_SolarForecast affectBatteryPreferredCharge 80
attr 01_SolarForecast affectConsForecastIdentWeekdays 1
attr 01_SolarForecast affectSolCastPercentile 50
attr 01_SolarForecast alias SolarForecast
attr 01_SolarForecast comment update per "wget -qO fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr 01_SolarForecast consumer01 z_wav_stecker_luftentfeuchter type=charger power=600 switchdev=struc_entfeuchter mode=can icon=Ventilator_fett mintime=SunPath:60:-90 on=on off=off swstate=state:on:off pcurr=power:W auto=automatic locktime=600:2700 spignorecond=01_SolarForecast:nulleinspeisung:1 asynchron=1 interruptable=1
attr 01_SolarForecast consumerAdviceIcon light_light_dim_100@gold
attr 01_SolarForecast consumerLegend text_top
attr 01_SolarForecast consumerLink 1
attr 01_SolarForecast ctrlConsRecommendReadings 01
attr 01_SolarForecast ctrlGenPVdeviation continuously
attr 01_SolarForecast ctrlInterval 30
attr 01_SolarForecast ctrlLanguage DE
attr 01_SolarForecast ctrlStatisticReadings currentRunMtsConsumer_01,todayBatIn,todayBatOut
attr 01_SolarForecast ctrlUserExitFn {\
if ((ReadingsNum("MQTT2_jk_bms_ble_multi","AVG_state_of_charge",0) > 80 && ReadingsNum("MQTT2_shelly1pm_solar2","relay_0_power",0) < 700 && ReadingsNum("z_wav_stecker_luftentfeuchter","automatic",0) == 1) ||\
(ReadingsNum("MQTT2_jk_bms_ble_multi","AVG_state_of_charge",0) > 80 && ReadingsNum("MQTT2_shelly1pm_solar2","relay_0_power",0) < 1300 && ReadingsNum("z_wav_stecker_luftentfeuchter","automatic",0) == 1 && ReadingsNum("$name","nulleinspeisung",0) == 1)) {\
fhem "setreading $name nulleinspeisung 1";;\
}\
else {\
fhem "setreading $name nulleinspeisung 0";;\
}\
}
attr 01_SolarForecast event-on-change-reading .*
attr 01_SolarForecast flowGraphicControl size=600 animate=1 showconsumer=1 showconsumerdummy=0 showconsumerpower=1 showconsumerremaintime=1
attr 01_SolarForecast graphicBeam1Color 3C14FF
attr 01_SolarForecast graphicBeam1Content pvForecast
attr 01_SolarForecast graphicBeam2Color 19FF29
attr 01_SolarForecast graphicBeam2Content pvReal
attr 01_SolarForecast graphicBeam3Content energycosts
attr 01_SolarForecast graphicHeaderDetail all
attr 01_SolarForecast graphicHeaderOwnspec AutarkyRate:Current_AutarkyRate\
Überschuß:Current_Surplus\
aktueller ;Netzbezug:Current_GridConsumption\
Consumer ;Neuplanung:consumerNewPlanning Consumer ;Sofortstart:consumerImmediatePlanning\
Strompreis ;aWATTar ;ct:arbeitspreis@aWATTar\
attr 01_SolarForecast graphicHistoryHour 4
attr 01_SolarForecast graphicLayoutType double
attr 01_SolarForecast graphicSelect both
attr 01_SolarForecast graphicShowDiff top
attr 01_SolarForecast graphicWeatherColor 000000
attr 01_SolarForecast group 00 Energiebilanz
attr 01_SolarForecast room Energie
attr 01_SolarForecast setupBatteryDev MQTT2_jk_bms_ble_multi pin=SUM_charging_power:W pout=SUM_discharging_power:W charge=AVG_state_of_charge cap=22000
attr 01_SolarForecast setupInverterDev01 MQTT2_EPEver2MQTT pv=BattLadeLeistung_sum:W etotal=EnergieGewinnTotal_total_sum:kWh capacity=3500
attr 01_SolarForecast setupInverterStrings gross,klein
attr 01_SolarForecast setupMeterDev HA_SDM220M_1 gcon=Power__W:W contotal=Energy_import__kWh:kWh gfeedin=-gcon feedtotal=Energy_export__kWh:kWh conprice=Strom_Kosten:aWATTar_Arbeitspreis:ct feedprice=0.0:€
attr 01_SolarForecast setupRadiationAPI OpenMeteoDWDEnsemble-API
attr 01_SolarForecast setupStringPeak gross=3.5 klein=2.5
attr 01_SolarForecast setupWeatherDev1 OpenMeteoDWDEnsemble-API
attr 01_SolarForecast sortby 2
attr 01_SolarForecast stateFormat Current_PV
# FUUID 62f00e06-f33f-638b-d558-edce0156a0cf493f
# FVERSION 76_SolarForecast.pm:v1.37.0-s29280/2024-10-22
# LCACHEFILE last write time: 09:45:25 File: ./FHEM/FhemUtils/PVCsm_SolarForecast_01_SolarForecast
# MODE Automatic - next Cycletime: 09:49:55
# MODEL OpenMeteoDWDEnsembleAPI
# NAME 01_SolarForecast
# NOTIFYDEV z_wav_stecker_luftentfeuchter,struc_entfeuchter
# NR 445
# NTFY_ORDER 50-01_SolarForecast
# STATE 881 W
# TYPE SolarForecast
# eventCount 45
# HELPER:
# 01M15DONE 1
# 01M45DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV 01_SolarForecast
# SPGROOM
# VERSION 1.37.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.2
# Helper:
# DBLOG:
# Today_PVdeviation:
# logdb:
# TIME 1729669735.11594
# VALUE -49.25
# logdb2:
# TIME 1729669735.11673
# VALUE -49.25
# OLDREADINGS:
# READINGS:
# 2024-10-23 09:49:25 Current_AutarkyRate 10 %
# 2024-10-23 09:49:25 Current_BatCharge 20 %
# 2024-10-23 09:49:25 Current_Consumption 312 W
# 2024-10-23 09:49:25 Current_GridConsumption 280 W
# 2024-10-23 09:49:25 Current_GridFeedIn 0 W
# 2024-10-23 09:49:25 Current_PV 881 W
# 2024-10-23 09:49:25 Current_PowerBatIn 849 W
# 2024-10-23 09:49:25 Current_PowerBatOut 0 W
# 2024-10-23 09:49:25 Current_SelfConsumption 32 W
# 2024-10-23 09:49:25 Current_SelfConsumptionRate 4 %
# 2024-10-23 09:49:25 Current_Surplus 569 W
# 2024-10-23 09:00:00 LastHourGridconsumptionReal 1303 Wh
# 2024-10-23 09:00:00 LastHourPVforecast 229 Wh
# 2024-10-23 09:00:00 LastHourPVreal 0 Wh
# 2024-10-23 09:49:25 NextHours_Sum01_PVforecast 1235 Wh
# 2024-10-23 09:49:25 NextHours_Sum02_PVforecast 2921 Wh
# 2024-10-23 09:49:25 NextHours_Sum03_PVforecast 4878 Wh
# 2024-10-23 09:49:25 NextHours_Sum04_ConsumptionForecast 8823 Wh
# 2024-10-23 09:49:25 NextHours_Sum04_PVforecast 8238 Wh
# 2024-10-23 09:49:25 RestOfDayConsumptionForecast 12361 Wh
# 2024-10-23 09:49:25 RestOfDayPVforecast 12228 Wh
# 2024-10-23 00:59:49 Today_Hour01_BatIn 0 Wh
# 2024-10-23 00:59:49 Today_Hour01_BatOut 0 Wh
# 2024-10-23 00:59:49 Today_Hour01_GridConsumption 283 Wh
# 2024-10-23 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2024-10-23 00:59:49 Today_Hour01_PVreal 0 Wh
# 2024-10-23 01:59:49 Today_Hour02_BatIn 0 Wh
# 2024-10-23 01:59:49 Today_Hour02_BatOut 0 Wh
# 2024-10-23 01:59:49 Today_Hour02_GridConsumption 287 Wh
# 2024-10-23 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2024-10-23 01:59:49 Today_Hour02_PVreal 0 Wh
# 2024-10-23 02:59:49 Today_Hour03_BatIn 0 Wh
# 2024-10-23 02:59:49 Today_Hour03_BatOut 0 Wh
# 2024-10-23 02:59:49 Today_Hour03_GridConsumption 283 Wh
# 2024-10-23 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2024-10-23 02:59:49 Today_Hour03_PVreal 0 Wh
# 2024-10-23 03:59:49 Today_Hour04_BatIn 0 Wh
# 2024-10-23 03:59:49 Today_Hour04_BatOut 0 Wh
# 2024-10-23 03:59:49 Today_Hour04_GridConsumption 310 Wh
# 2024-10-23 03:59:49 Today_Hour04_GridFeedIn 0 Wh
# 2024-10-23 03:59:49 Today_Hour04_PVreal 0 Wh
# 2024-10-23 04:59:49 Today_Hour05_BatIn 0 Wh
# 2024-10-23 04:59:49 Today_Hour05_BatOut 0 Wh
# 2024-10-23 04:59:49 Today_Hour05_GridConsumption 334 Wh
# 2024-10-23 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2024-10-23 04:59:49 Today_Hour05_PVreal 0 Wh
# 2024-10-23 05:59:49 Today_Hour06_BatIn 0 Wh
# 2024-10-23 05:59:49 Today_Hour06_BatOut 0 Wh
# 2024-10-23 05:59:49 Today_Hour06_GridConsumption 955 Wh
# 2024-10-23 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2024-10-23 05:59:49 Today_Hour06_PVreal 0 Wh
# 2024-10-23 06:59:49 Today_Hour07_BatIn 0 Wh
# 2024-10-23 06:59:49 Today_Hour07_BatOut 0 Wh
# 2024-10-23 06:59:49 Today_Hour07_GridConsumption 1760 Wh
# 2024-10-23 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2024-10-23 06:59:49 Today_Hour07_PVreal 0 Wh
# 2024-10-23 07:59:49 Today_Hour08_BatIn 0 Wh
# 2024-10-23 07:59:49 Today_Hour08_BatOut 0 Wh
# 2024-10-23 07:59:49 Today_Hour08_GridConsumption 1150 Wh
# 2024-10-23 07:59:49 Today_Hour08_GridFeedIn 0 Wh
# 2024-10-23 07:59:49 Today_Hour08_PVforecast 4 Wh
# 2024-10-23 07:59:49 Today_Hour08_PVreal 0 Wh
# 2024-10-23 08:59:49 Today_Hour09_BatIn 0 Wh
# 2024-10-23 08:59:49 Today_Hour09_BatOut 0 Wh
# 2024-10-23 08:59:49 Today_Hour09_GridConsumption 1303 Wh
# 2024-10-23 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2024-10-23 08:59:49 Today_Hour09_PVforecast 229 Wh
# 2024-10-23 08:59:49 Today_Hour09_PVreal 0 Wh
# 2024-10-23 09:49:25 Today_Hour10_BatIn 0 Wh
# 2024-10-23 09:49:25 Today_Hour10_BatOut 0 Wh
# 2024-10-23 09:49:25 Today_Hour10_GridConsumption 285 Wh
# 2024-10-23 09:49:25 Today_Hour10_GridFeedIn 0 Wh
# 2024-10-23 09:49:25 Today_Hour10_PVforecast 535 Wh
# 2024-10-23 09:49:25 Today_Hour10_PVreal 1000 Wh
# 2024-10-23 09:49:25 Today_Hour11_PVforecast 1376 Wh
# 2024-10-23 09:49:25 Today_Hour12_PVforecast 1747 Wh
# 2024-10-23 09:49:25 Today_Hour13_PVforecast 2000 Wh
# 2024-10-23 09:49:25 Today_Hour14_PVforecast 3631 Wh
# 2024-10-23 09:49:25 Today_Hour15_PVforecast 1531 Wh
# 2024-10-23 09:49:25 Today_Hour16_PVforecast 1000 Wh
# 2024-10-23 09:49:25 Today_Hour17_PVforecast 694 Wh
# 2024-10-23 09:49:25 Today_Hour18_PVforecast 160 Wh
# 2024-10-23 09:49:25 Today_MaxPVforecast 3631 Wh
# 2024-10-23 09:49:25 Today_MaxPVforecastTime 2024-10-23 13:00:00
# 2024-10-23 09:49:25 Today_PVdeviation -49.25 %
# 2024-10-23 09:49:25 Today_PVforecast 12907 Wh
# 2024-10-23 09:49:25 Today_PVreal 1000 Wh
# 2024-10-23 09:49:25 Today_SunRise 07:43
# 2024-10-23 09:49:25 Today_SunSet 17:54
# 2024-10-23 09:49:25 Tomorrow_ConsumptionForecast 7843 Wh
# 2024-10-23 09:49:25 Tomorrow_PVforecast 13989 Wh
# 2024-10-23 09:49:25 Tomorrow_SunRise 07:44
# 2024-10-23 09:49:25 Tomorrow_SunSet 17:52
# 2024-10-23 09:49:25 consumer01 name='z_wav_stecker_luftentfeuchter' state='off' mode='can' planningstate='planned'
# 2024-10-23 09:49:25 consumer01_ConsumptionRecommended 0
# 2024-10-23 09:49:25 consumer01_currentPower 0 W
# 2024-10-23 09:49:25 consumer01_planned_start 23.10.2024 09:45:25
# 2024-10-23 09:49:25 consumer01_planned_stop 23.10.2024 17:26:25
# 2024-10-23 09:49:25 nextCycletime 09:49:55
# 2024-10-23 09:47:55 nextRadiationAPICall nach 23.10.2024 10:02:55
# 2024-10-23 09:49:25 nulleinspeisung 0
# 2024-10-23 09:49:25 pvCorrectionFactor_Auto on_complex_ai
# 2024-06-18 12:14:24 setupStringAzimuth gross=S klein=S
# 2024-06-18 12:14:24 setupStringDeclination gross=35 klein=15
# 2024-10-23 09:49:26 state updated
# 2024-10-23 09:49:25 statistic_currentRunMtsConsumer_01 0 min
# 2024-10-23 09:49:25 statistic_todayBatIn 0.0 Wh
# 2024-10-23 09:49:25 statistic_todayBatOut 0.0 Wh
# hmccu:
#
setstate 01_SolarForecast 881 W
setstate 01_SolarForecast 2023-12-03 17:49:33 .01_SolarForecast_consumerImmediatePlanning
setstate 01_SolarForecast 2023-12-03 17:49:33 .01_SolarForecast_consumerNewPlanning
setstate 01_SolarForecast 2024-10-23 09:39:11 .associatedWith z_wav_stecker_luftentfeuchter struc_entfeuchter HA_SDM220M_1 MQTT2_jk_bms_ble_multi MQTT2_EPEver2MQTT
setstate 01_SolarForecast 2024-10-23 09:49:25 .lastupdateForecastValues 1729669765
setstate 01_SolarForecast 2024-10-23 01:00:02 .pvCorrectionFactor_01_apipercentil done
setstate 01_SolarForecast 2024-10-23 01:00:02 .pvCorrectionFactor_01_cloudcover done
setstate 01_SolarForecast 2024-10-23 02:00:02 .pvCorrectionFactor_02_apipercentil done
setstate 01_SolarForecast 2024-10-23 02:00:02 .pvCorrectionFactor_02_cloudcover done
setstate 01_SolarForecast 2024-10-23 03:00:02 .pvCorrectionFactor_03_apipercentil done
setstate 01_SolarForecast 2024-10-23 03:00:02 .pvCorrectionFactor_03_cloudcover done
setstate 01_SolarForecast 2024-10-23 04:00:02 .pvCorrectionFactor_04_apipercentil done
setstate 01_SolarForecast 2024-10-23 04:00:02 .pvCorrectionFactor_04_cloudcover done
setstate 01_SolarForecast 2024-10-23 05:00:02 .pvCorrectionFactor_05_apipercentil done
setstate 01_SolarForecast 2024-10-23 05:00:02 .pvCorrectionFactor_05_cloudcover done
setstate 01_SolarForecast 2024-10-23 06:00:02 .pvCorrectionFactor_06_apipercentil done
setstate 01_SolarForecast 2024-10-23 06:00:02 .pvCorrectionFactor_06_cloudcover done
setstate 01_SolarForecast 2024-10-23 07:00:02 .pvCorrectionFactor_07_apipercentil done
setstate 01_SolarForecast 2024-10-23 07:00:02 .pvCorrectionFactor_07_cloudcover done
setstate 01_SolarForecast 2024-10-23 08:00:03 .pvCorrectionFactor_08_apipercentil done
setstate 01_SolarForecast 2024-10-23 08:00:03 .pvCorrectionFactor_08_cloudcover done
setstate 01_SolarForecast 2024-10-23 09:00:03 .pvCorrectionFactor_09_apipercentil done
setstate 01_SolarForecast 2024-10-23 09:00:03 .pvCorrectionFactor_09_cloudcover done
setstate 01_SolarForecast 2024-10-23 09:49:25 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate 01_SolarForecast 2024-10-23 01:00:02 .signaldone_01 done
setstate 01_SolarForecast 2024-10-23 02:00:02 .signaldone_02 done
setstate 01_SolarForecast 2024-10-23 03:00:02 .signaldone_03 done
setstate 01_SolarForecast 2024-10-23 04:00:02 .signaldone_04 done
setstate 01_SolarForecast 2024-10-23 05:00:02 .signaldone_05 done
setstate 01_SolarForecast 2024-10-23 06:00:02 .signaldone_06 done
setstate 01_SolarForecast 2024-10-23 07:00:02 .signaldone_07 done
setstate 01_SolarForecast 2024-10-23 08:00:03 .signaldone_08 done
setstate 01_SolarForecast 2024-10-23 09:00:03 .signaldone_09 done
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_AutarkyRate 10 %
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_BatCharge 20 %
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_Consumption 312 W
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_GridConsumption 280 W
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_GridFeedIn 0 W
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_PV 881 W
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_PowerBatIn 849 W
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_PowerBatOut 0 W
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_SelfConsumption 32 W
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_SelfConsumptionRate 4 %
setstate 01_SolarForecast 2024-10-23 09:49:25 Current_Surplus 569 W
setstate 01_SolarForecast 2024-10-23 09:00:00 LastHourGridconsumptionReal 1303 Wh
setstate 01_SolarForecast 2024-10-23 09:00:00 LastHourPVforecast 229 Wh
setstate 01_SolarForecast 2024-10-23 09:00:00 LastHourPVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 NextHours_Sum01_PVforecast 1235 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 NextHours_Sum02_PVforecast 2921 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 NextHours_Sum03_PVforecast 4878 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 NextHours_Sum04_ConsumptionForecast 8823 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 NextHours_Sum04_PVforecast 8238 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 RestOfDayConsumptionForecast 12361 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 RestOfDayPVforecast 12228 Wh
setstate 01_SolarForecast 2024-10-23 00:59:49 Today_Hour01_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 00:59:49 Today_Hour01_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 00:59:49 Today_Hour01_GridConsumption 283 Wh
setstate 01_SolarForecast 2024-10-23 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 00:59:49 Today_Hour01_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 01:59:49 Today_Hour02_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 01:59:49 Today_Hour02_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 01:59:49 Today_Hour02_GridConsumption 287 Wh
setstate 01_SolarForecast 2024-10-23 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 01:59:49 Today_Hour02_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 02:59:49 Today_Hour03_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 02:59:49 Today_Hour03_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 02:59:49 Today_Hour03_GridConsumption 283 Wh
setstate 01_SolarForecast 2024-10-23 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 02:59:49 Today_Hour03_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 03:59:49 Today_Hour04_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 03:59:49 Today_Hour04_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 03:59:49 Today_Hour04_GridConsumption 310 Wh
setstate 01_SolarForecast 2024-10-23 03:59:49 Today_Hour04_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 03:59:49 Today_Hour04_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 04:59:49 Today_Hour05_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 04:59:49 Today_Hour05_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 04:59:49 Today_Hour05_GridConsumption 334 Wh
setstate 01_SolarForecast 2024-10-23 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 04:59:49 Today_Hour05_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 05:59:49 Today_Hour06_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 05:59:49 Today_Hour06_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 05:59:49 Today_Hour06_GridConsumption 955 Wh
setstate 01_SolarForecast 2024-10-23 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 05:59:49 Today_Hour06_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 06:59:49 Today_Hour07_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 06:59:49 Today_Hour07_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 06:59:49 Today_Hour07_GridConsumption 1760 Wh
setstate 01_SolarForecast 2024-10-23 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 06:59:49 Today_Hour07_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 07:59:49 Today_Hour08_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 07:59:49 Today_Hour08_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 07:59:49 Today_Hour08_GridConsumption 1150 Wh
setstate 01_SolarForecast 2024-10-23 07:59:49 Today_Hour08_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 07:59:49 Today_Hour08_PVforecast 4 Wh
setstate 01_SolarForecast 2024-10-23 07:59:49 Today_Hour08_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 08:59:49 Today_Hour09_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 08:59:49 Today_Hour09_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 08:59:49 Today_Hour09_GridConsumption 1303 Wh
setstate 01_SolarForecast 2024-10-23 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 08:59:49 Today_Hour09_PVforecast 229 Wh
setstate 01_SolarForecast 2024-10-23 08:59:49 Today_Hour09_PVreal 0 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour10_BatIn 0 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour10_BatOut 0 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour10_GridConsumption 285 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour10_GridFeedIn 0 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour10_PVforecast 535 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour10_PVreal 1000 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour11_PVforecast 1376 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour12_PVforecast 1747 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour13_PVforecast 2000 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour14_PVforecast 3631 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour15_PVforecast 1531 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour16_PVforecast 1000 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour17_PVforecast 694 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_Hour18_PVforecast 160 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_MaxPVforecast 3631 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_MaxPVforecastTime 2024-10-23 13:00:00
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_PVdeviation -49.25 %
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_PVforecast 12907 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_PVreal 1000 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_SunRise 07:43
setstate 01_SolarForecast 2024-10-23 09:49:25 Today_SunSet 17:54
setstate 01_SolarForecast 2024-10-23 09:49:25 Tomorrow_ConsumptionForecast 7843 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Tomorrow_PVforecast 13989 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 Tomorrow_SunRise 07:44
setstate 01_SolarForecast 2024-10-23 09:49:25 Tomorrow_SunSet 17:52
setstate 01_SolarForecast 2024-10-23 09:49:25 consumer01 name='z_wav_stecker_luftentfeuchter' state='off' mode='can' planningstate='planned'
setstate 01_SolarForecast 2024-10-23 09:49:25 consumer01_ConsumptionRecommended 0
setstate 01_SolarForecast 2024-10-23 09:49:25 consumer01_currentPower 0 W
setstate 01_SolarForecast 2024-10-23 09:49:25 consumer01_planned_start 23.10.2024 09:45:25
setstate 01_SolarForecast 2024-10-23 09:49:25 consumer01_planned_stop 23.10.2024 17:26:25
setstate 01_SolarForecast 2024-10-23 09:49:25 nextCycletime 09:49:55
setstate 01_SolarForecast 2024-10-23 09:47:55 nextRadiationAPICall nach 23.10.2024 10:02:55
setstate 01_SolarForecast 2024-10-23 09:49:25 nulleinspeisung 0
setstate 01_SolarForecast 2024-10-23 09:49:25 pvCorrectionFactor_Auto on_complex_ai
setstate 01_SolarForecast 2024-06-18 12:14:24 setupStringAzimuth gross=S klein=S
setstate 01_SolarForecast 2024-06-18 12:14:24 setupStringDeclination gross=35 klein=15
setstate 01_SolarForecast 2024-10-23 09:49:26 state updated
setstate 01_SolarForecast 2024-10-23 09:49:25 statistic_currentRunMtsConsumer_01 0 min
setstate 01_SolarForecast 2024-10-23 09:49:25 statistic_todayBatIn 0.0 Wh
setstate 01_SolarForecast 2024-10-23 09:49:25 statistic_todayBatOut 0.0 Wh
Eine kleine Frage noch zusätzlich: Ist die Erweiterung für Nulleinspeisung noch angedacht?
VG
Heiko
Guten Morgen,
da ist nichts einzustellen.
Leere mal bitte deinen Browsercache.
ZitatEine kleine Frage noch zusätzlich: Ist die Erweiterung für Nulleinspeisung noch angedacht?
Damit ist jetzt nicht die Sachlage bzgl. einer "Grid-Only" Anlage (ohne Verbindung zum Hausnetz) gemeint, oder?
@Heiko,
ich habe dein Problem bei mir nachstellen können.
Es liegt am Namen des Devices "01_SolarForecast". Die Zahl "01" ist störend bzgl. des Grafikaufbaus.
Die Umbenennung in z.B. "_SolarForecast" und Neuspeichern des Attr flowGraphicControl reicht aus.
Muß ich mir anschauen und fixen ... was es nicht alles gibt.
Edit: Umbennung in "SolarForecast01" geht auch.
LG,
Heiko
ZitatEine kleine Frage noch zusätzlich: Ist die Erweiterung für Nulleinspeisung noch angedacht?
Damit ist jetzt nicht die Sachlage bzgl. einer "Grid-Only" Anlage (ohne Verbindung zum Hausnetz) gemeint, oder?
Ja genau. Das meine ich nicht. Ich meine: Meine Anlage soll/darf nicht ins Grid einspeisen.
Browsercache hatte ich auch schon gelöscht. Alles gut. Die Welt ist wunderlich. :o
ZitatDas meine ich nicht. Ich meine: Meine Anlage soll/darf nicht ins Grid einspeisen.
Im Prinzip gibt es diesbezüglich nur den Unterschied zur Überschußeinspeisung, dass eine solche Anlage herunterregelt sobald die Batterie (sofern vorhanden) voll ist und der Bedarf des Hausnetzes erfüllt ist.
Das geht schon mit dem aktuellen Modul mit dem Problem dass die Prognose nicht stimmen wird, da das Modul nicht einschätzen kann wann die Faktoren eintreten die ein Herunterregeln bedingen.
Mir fällt momentan auch keine Logik ein die soetwas erfüllen könnte.
Zitat von: DS_Starter am 23 Oktober 2024, 11:26:20ZitatDas meine ich nicht. Ich meine: Meine Anlage soll/darf nicht ins Grid einspeisen.
Im Prinzip gibt es diesbezüglich nur den Unterschied zur Überschußeinspeisung, dass eine solche Anlage herunterregelt sobald die Batterie (sofern vorhanden) voll ist und der Bedarf des Hausnetzes erfüllt ist.
Das geht schon mit dem aktuellen Modul mit dem Problem dass die Prognose nicht stimmen wird, da das Modul nicht einschätzen kann wann die Faktoren eintreten die ein Herunterregeln bedingen.
Mir fällt momentan auch keine Logik ein die soetwas erfüllen könnte.
Mit der Prognoseerstellung/-fehler kann ich leben. Wichtiger wäre mir die Planung der Consumer.
Momentan fahre ich das mit einer ctrlUserExitFn. Das funktioniert aber eher mässig.
@tatu123,
in meinem contrib liegt die V 1.37.1.
Deine Namensgebung funktioniert damint nun auch. Ein Umbenennen ist ebenfalls ohne Nacharbeiten möglich.
Restart nach Download nicht vergessen.
LG,
Heiko
Zitat von: DS_Starter am 23 Oktober 2024, 13:25:50@tatu123,
in meinem contrib liegt die V 1.37.1.
Deine Namensgebung funktioniert damint nun auch. Ein Umbenennen ist ebenfalls ohne Nacharbeiten möglich.
Restart nach Download nicht vergessen.
Sieht super aus. Funktioniert. Danke für das schnelle fixen.
LG
Heiko
Danke für die Rückmeldung, die Version ist im Repo eingecheckt.
LG
Hallo DS_Starter!
Ich nutze Dein Modul nun schon eine ganze Weile und bin sehr zufrieden. Heute möchte ich aber mal einen kleinen Verbesserungsvorschlag anbringen.
Die Möglichkeit, mehrere "Strom-Produzenten" abzubilden finde ich toll. Allerdings habe ich derzeit nur eine einzelne PV-Anlage.
Daher sind die Werte an den Symbolen oben bei mir redundant und die Verbindungen zwischen Energieknoten, Netz, Speicher und Haus sehr eng zusammen.
Lässt sich eine Konfiguration ergänzen, die für Anlagen mit nur einem Produzenten die alten Darstellung generiert? Ich meine die Ansicht ohne den Energieknoten.
Viele Grüße,
Peter
Hallo Peter,
da muß ich erstmal schauen wie es sich in das Gesamtkonzept integrieren ließe ohne den Überblick zu verlieren.
Davon abgesehen habe ich auch nur eine Anlage in einem meiner Setups eingestellt wie im Anhang zu sehen.
Das Netzsymbol und der Speicher sollen jeweils noch etwas mehr nach links bzw. rechts rücken.
Darum kümmert sich kask gerade.
Vllt. reicht das auch für dich dann. Evtl. zeigst du uns mal einen Screenshot, kann ja überall etwas anders aussehen.
Mit dem Attr flowGraphicControl (size) kannst du die Größe insgesamt ändern aber das kennst du sicher schon.
LG,
Heiko
Ich würd mich da Peter anschließen; ich find die Möglichkeit mehrerer producer auch gut, schätze aber, dass es nicht wenige User mit nur einem Erzeuger gibt ;)
Dann kauft man halt einfach noch einen ... ;)
Spaß beiseite ... ich schau mal.
@Peter & grappa24
in meinem contrib liegt die V 1.37.2. In dieser V ist euer Anliegen umgesetzt.
Ihr könnt es gern einmal auch bei euch testen.
Wie immer Restart nicht vergessen!
Grüße,
Heiko
Ich war kühn und habe die V noch eingecheckt nachdem ich noch etwas getestet habe.
Wow! Du bist ja schnell!
Ich hab heute früh ein Update gemacht und freue mich sehr! Vielen Dank für die schnelle Umsetzung!
Jetzt sieht das für Single-Producer noch besser aus.
Noch ein kleines bisschen mehr würde ich mich freuen, wenn die vertikalen Abstände wieder größer wären. Oder sind die schon konfigurierbar, wie auch die horizontalen Abstände zwischen den Verbrauchern?
Viele Grüße,
Peter
PS: Ich überlege tatsächlich, ein Balkonkraftwerk mit zusätzlicher Südausrichtung anzuschaffen.
Vertikale Abstände bei vielen Consumern:
Diese beiden Einträge könnten deine Freunde werden / sein bei so vielen "Consumer"
==>>strokewidth=12
(ca. Halbierung der Standartbreite des "fliessenden Linien")
==>>consumerdist=80
(80 ganz nah horizontal - 500 weiter weg - horizontal)
Gruß
300P
Hallo 300P,
Danke dir für den Tipp.
Vielleicht hätte ich genauer beschreiben sollen. Es geht mir um die Abstände zwischen den Zahlen und den Linien, die nicht zu der jeweiligen Zahl gehört. Ich verwechsele das sonst. ;)
Gruß,
Peter
Edit: Screenshot angehängt. Bei dieser Darstellung habe ich mich zuerst gewundert, warum 675 Watt aus dem Speicher kommen.
Da wüsste ich leider O:-) nichts einzustellen
Kommt sicher bald was. Ist mir auch schon aufgefallen.
Hallo zusammen,
kask hat mir wieder eine Zuarbeit geleistet, vielen Dank dafür. :)
Hier sind die Batterie, das Grid und der Consumer-Dummy auseinandergezogen und geben mehr Raum.
Liegt als 1.37.3 in meinem contrib.
Bezüglich des vertikalen Abstandes Haus -> Consumer bekommen wir sicherlich auch noch eine Einstellmöglichkeit hin.
LG,
Heiko
Und nun kann man auch den Abstand zwischen dem Haus und der Consumer-Zeile vergrößern.
Im Attr flowGraphicControl gibt es dazu den Schlüssel h2consumerdist.
Im Anhang ein Beispiel mit h2consumerdist=50
Update liegt im contrib.
nicht übel ;D
Ja, da sehe ich das doch schon wesentlich besser.
Vielen Dank nochmal!
Und die V 1.37.3 ist nun auch eingecheckt. :)
Danke für euren Mut zu testen und das Feedback ... macht Freude mit euch zusammen am Modul zu arbeiten!
LG
HAHA! Macht freude das Modul zu testen wenn es adhoc und offen angepasst wird. Und das Lob geht an dich, das Du so mutig bist schnell abzuändern.
Das zeigt mir das deine Debugging und Test&Trial-techniken schon was auf dem Nacken haben, bei so wenig vermarmelten Versionen bis jetzt.
Erst 2 dicke Eier gab es bei fast täglichen Änderungen zeitweise.
Danke für das schöne Update.
Ein Problem beschäftigt mich derzeit noch: Obgleich ich bei "setupMeterDev"
"gfeedin=-gcon" gesetzt habe, erhalte ich regelmäßig Warnungen wie folgt:
2024.10.11 19:13:22 3: SF - WARNING - The stored Energy consumption of day/hour 10/02 is negative. This appears to be an error. The incorrect value can be deleted with 'set SF reset consumption 10 02'.
Anhand der Doku hätte ich erwartet, dass derartige Warnungen wegen "gfeedin=-gcon" nicht auftauchen.
Oder sehe ich da etwas falsch?
Hallo Parallix,
die Angabe "gfeedin=-gcon" bedeutet zunächst nur dass das Modul den Wert im Reading gcon=<Readingname> als Grideinspeisung (gfeedin) nutzt, sofern dieser Wert negativ ist.
Das verwendet man wenn der Meter nur ein Reading anbietet, welches sowohl Bezug (als positiven Wert) als auch Einspeisung (als negativen Wert) liefert.
In den Readings Today_HourXX_GridConsumption und Today_HourXX_GridFeedIn solltest du aber nur positve Werte sehen.
Die Consumtion für die Stunde wird dann berechnet aus:
Hausverbrauch = PV-Ertrag + (Erzeugung OtherProducer) - Netzeinspeisung + Netzbezug - BatterieIn + BatterieOut
Die jeweiligen Werte in der Gleichung sind immer positiv, also ohne negativen Vorzeichen.
Mit ctrlDebug=saveData2Cache kannst du verfolgen was mit jedem Zyklus gespeichert wird:
...
2024.10.27 19:35:28.354 1: SolCast DEBUG> setPVhistory -> stored simple - Day: 27, Hour: 20, Key: con, Value: 303
2024.10.27 19:35:28.355 1: SolCast DEBUG> setPVhistory -> stored compute - Day: 27, Hour: 99, Key: con, Value: 13882
...
2024.10.27 19:36:08.333 1: SolCast DEBUG> setPVhistory -> stored simple - Day: 27, Hour: 20, Key: con, Value: 308
2024.10.27 19:36:08.333 1: SolCast DEBUG> setPVhistory -> stored compute - Day: 27, Hour: 99, Key: con, Value: 13887
...
2024.10.27 19:37:28.247 1: SolCast DEBUG> setPVhistory -> stored simple - Day: 27, Hour: 20, Key: con, Value: 318
2024.10.27 19:37:28.247 1: SolCast DEBUG> setPVhistory -> stored compute - Day: 27, Hour: 99, Key: con, Value: 13897
...
Du siehst, wie sich die Summen mit jeder Messung erhöhen. "stored simple" ist der Stundenwert in Wh und "stored compute" der aufsummierte Tageswert. Der Key "con" beschreibt die Consumption des Hauses, d.h. die Summe aller Verbräuche.
Wenn sich irgendwann mal eine negative Differenz ergibt (evtl. immer zur selben Zeit) wäre das ein Ansatz zur Suche.
Wenn sich die besagte Meldung immer auf eine bestimmte Stunde des Tages bezieht, kannst du das Attr ja mal gezielt mit einem at entsprechen aktivieren/ deaktivieren um die Ergebnisse zu sehen.
LG,
Heiko
Zitat von: DS_Starter am 27 Oktober 2024, 19:47:29Hallo Parallix,
die Angabe "gfeedin=-gcon" bedeutet zunächst nur dass das Modul den Wert im Reading gcon=<Readingname> als Grideinspeisung (gfeedin) nutzt, sofern dieser Wert negativ ist.
Das verwendet man wenn der Meter nur ein Reading anbietet, welches sowohl Bezug (als positiven Wert) als auch Einspeisung (als negativen Wert) liefert.
In den Readings Today_HourXX_GridConsumption und Today_HourXX_GridFeedIn solltest du aber nur positve Werte sehen.
...
Danke für das Feedback! Werde mir das die Woche mal genauer ansehen.
In der Tat liegt bei mir der (beschriebene) Fall vor, dass das genutzte Reading (Netz-Einspeisung bzw. Bezug) positiv oder negativ sein kann. Den gleichen Fall (positives oder negatives Reading) habe ich allerdings auch bei meinen (zwei einzeln am GW25K-ET angeschlossenen) Speichern, die ich ohne Umwege aktuell ja noch nicht einzeln in die Grafik einbauen kann und daher zusammengeführt habe.
Heute hatte ich auch noch ein seltsamen Prognosewert: 20,2kWh im 6:00 Uhr Bin (siehe Grafik) halte ich selbst bei bestem Solarwetter für nicht realisierbar. Diese Anzeige hatte ich übrigens auch schon vor dem heutigen Update!
Eine Frage noch am Rande: Das zyklisch eigentlich gewünschte Update für das SolarCast-Fenster erfolgt bei mir auch in allen anderen Brower-Fenstern in denen ich (andere) FHEM-Seiten anzeige, Liegt da möglicherweise ein Fehler vor?
Screenshot 2024-10-28 at 09-01-24 Home Sweet Home.png
ZitatHeute hatte ich auch noch ein seltsamen Prognosewert: 20,2kWh im 6:00 Uhr Bin (siehe Grafik) halte ich selbst bei bestem Solarwetter für nicht realisierbar.
Würde ich auch bezweifeln.
Du verwendest die OpenMeteo-API ohne Korrektur.
D.h. die Prognose von OpenMeteoDWD wird 1:1 durchgereicht/dargestellt.
Ein "get ... solApiData" listet dir die Inputdaten auf. Die Rad1h Werte kommen direkt von der API.
Wenn du dort bereits den Ausreißer siehst, ist die Ursache klar.
ZitatEine Frage noch am Rande: Das zyklisch eigentlich gewünschte Update für das SolarCast-Fenster erfolgt bei mir auch in allen anderen Brower-Fenstern in denen ich (andere) FHEM-Seiten anzeige, Liegt da möglicherweise ein Fehler vor?
Nein, das ist technisch bedingt. Man kann alternativ noch mit ctrlAutoRefreshFW arbeiten.
Andererseits wundere ich mich, dass überhaupt jemand diese Möglichkeit verwendet. Ich hatte mir bereits überlegt diese Attribute zu entfernen, da die Grafik sich ohnehin in der Raumansicht selbständig aktualisiert und die Readings ebenfalls über die FHEM internen Mechanismen.
Diese Atribute sind eigentlich Relikte aus der Anfangszeit von denen ich der Meinung war sie seinen inzwischen überflüssig.
Zu dieser Kategorie zählen für mich auch die Attr graphicStartHtml /graphicEndHtml die ich auch entfernen würde, es sei denn jemand möchte sie gern aus welchen Gründen auch immer behalten.
Hallo Forum,
ich habe das Modul zusammen mit einem Fronius-WR und dem SolarAPI-Modul 98_fronius.pm in Betrieb genommen. Die angezeigten Werte sind soweit plausibel. in den Current_*_Readings steht alles so drin, wie erwartet. Ich kann z.B. Current_PowerBatIn und Current_PowerBatOut mit den Angaben von Fronius vergleichen - soweit ok.
Mir ist aber aufgefallen, dass die Stunden-Buckets Today_Hour??_BatIn und Today_Hour??_BatOut immer 0 sind. Ist das so gedacht?
Meine Batteriekonfiguration sieht so aus:
attr Solar setupBatteryDev PVInverter pin=-pout pout=PowerFlow_Site_P_Akku:W cap=Storage_1_Controller_DesignedCapacity:Wh charge=PowerFlow_Inverters_1_SOC
Hallo Thomas,
nein das ist so nicht gedacht.
In deiner Battriedefinition fehlen die Schlüssel:
intotal Reading welches die totale Batterieladung als fortlaufenden Zähler liefert (optional)
outtotal Reading welches die totale Batterieentladung als fortlaufenden Zähler liefert (optional)
Sie sind optional, allerdings werden die Stundenwerte nicht generiert wenn diese Angaben fehlen.
Wenn die Batterieanlage diese Werte nicht von Haus aus liefert, könnte userReadings mit Intergralfunktion helfen diese Werte als Input für SF zu erstellen.
LG,
Heiko
Hallo Heiko,
danke für die schnelle Antwort. Habe ich Nachteile, wenn die Werte nicht gefüllt werden? Die Schlüssel sind ja sicher nicht ohne Grund optional.
Gruß, Thomas
Optional sind sie nur weil manche Anlagen sie nicht per default liefern und niemand deswegen an dieser Stelle scheitern soll.
Nachteile ergeben sich, z.B. kann der Hausverbrauch auf Stundenbasis nicht richtig berechnet werden da die Batteriewerte fehlen.
Dadurch werden die Verbrauchsprognosen via ctrlStatisticReadings auch nicht richtig sein. Es können sich noch mehr Abhängigkeiten ergeben die ich momentan nicht alle übersehen kann, dafür ist das Modul zu komplex. ;)
Also wenn es geht, würde ich dir raten diese Werte liefern zu lassen.
Zitat von: DS_Starter am 28 Oktober 2024, 11:09:51ZitatEine Frage noch am Rande: Das zyklisch eigentlich gewünschte Update für das SolarCast-Fenster erfolgt bei mir auch in allen anderen Brower-Fenstern in denen ich (andere) FHEM-Seiten anzeige, Liegt da möglicherweise ein Fehler vor?
Nein, das ist technisch bedingt. Man kann alternativ noch mit ctrlAutoRefreshFW arbeiten.
Andererseits wundere ich mich, dass überhaupt jemand diese Möglichkeit verwendet. Ich hatte mir bereits überlegt diese Attribute zu entfernen, da die Grafik sich ohnehin in der Raumansicht selbständig aktualisiert und die Readings ebenfalls über die FHEM internen Mechanismen.
Wenn ich ctrlAutoRefresh entferne, werden, während sich die Grafik nicht aktualisiert, auf der Browserseite nur die Readings erneuert.
ZitatWenn ich ctrlAutoRefresh entferne, werden, während sich die Grafik nicht aktualisiert, auf der Browserseite nur die Readings erneuert.
Wenn du die Readings siehst, befindest du dich auf der sogenannten Detailseite.
Wenn du einen Raum auswählst, befindest du dich in der Raumansicht. Hier wird auch die Grafik automatisch aktualisiert.
Wichtig ist dass das Reading "state" einen Event generiert, was aber der Fall ist wenn man es nicht explizit unterbindet.
Zitat von: DS_Starter am 28 Oktober 2024, 14:39:14Wenn du einen Raum auswählst, befindest du dich in der Raumansicht. Hier wird auch die Grafik automatisch aktualisiert.
Wichtig ist dass das Reading "state" einen Event generiert, was aber der Fall ist wenn man es nicht explizit unterbindet.
Zu blöd von mir. Hätte ich eigentlich wissen müssen.
Die Gelegenheit möchte ich aber nutzen, um hier noch eine Anregung zu geben: Die in der Grafik dargestellten Werte sind - wenn ich das richtig sehe - ja Augenblickswerte der jeweiligen Readings. Vor dem Hintergrund, dass sich diese häufiger ändern, als die Grafik aktualisiert wird, sind die angezeigten Werte bei hoher Fluktuation der Ursprungswerte wenig aussagekräftig. Dem könnte man wunderbar entgegentreten, wenn in der Grafik gleitenden Mittelwerte (zeitliche Breite entsprechend der Zeit zwischen zwei Updates) angezeigt werden würden.
Alternativ sehe ich noch zwei weitere (und für mich bessere) Varianten.
1. Die Aktualisierungsfrequenz der Grafik ist abhängig vom Zyklus eingestellt im Attr ctrlInterval. Je nach Leistungsfähigkeit eurer Server kann man die Zeit durchaus sehr kurz wählen. Habe es bei mir schon mal auf 1 Sekunde gesetzt und läuft damit einwandfrei, CPU geht halt entsprechend hoch.
2. Die zweite Variante ist die Möglichkeit der Asynchronität und mein persönlicher Favorit. Ihr kennt das bereits wenn dieses Merkmal bei einem Consumer angegeben ist. Dann wertet das Modul die Schalt-Events des Consumers aus und startet nach Empfang eines solchen sofort den Updatevorgang. Dieses Verfahren kann man ggf. auch auf die angegebenen Devices in setupInverterDevXX, setupBatteryDev, setupMeterDev, setupOtherProducerXX erweitern. Das führt dann bei Empfang relevanter Events zu einem unmittelbaren Update und entsprechend aktueller Werte in der Grafik und den Modulreadings.
Aber das muß natürlich erstmal alles gebaut werden.
Aktuell lasse ich zunächst etwas Ruhe einkehren und werde größere Aktivitäten erst wieder Angang Dezember beginnen. Bis dahin hat etwas Anderes meine Aufmerksamkeit. :)
@all,
wie bereits in #1280 erwähnt, habe ich die Attr graphicStartHtml und graphicEndHtml entfernt und die V eingecheckt.
Sie waren noch Relikte aus der Anfangszeit des Moduls.
Falls es jemanden geben sollte der diese Dinge aus welchen Gründen auch immer aktiv nutzt, dann bitte nicht updaten und hier melden.
LG,
Heiko
Hallo,
das ist ein interesantes Modul, das ich seit einiger Zeit nutze.
Nach dem letzten Update wird die Flow-Grafik allerdings nicht mehr richtig dargestellt.
Ich habe schon mit dem Attribut "flowGraphicControl" herumgespielt, aber keine Veränderung festgestellt.
Hier ein List:
define DR.PV_Vorhersage SolarForecast
attr DR.PV_Vorhersage DbLogExclude .*
attr DR.PV_Vorhersage alias SolarForecast
attr DR.PV_Vorhersage event-on-change-reading .*
attr DR.PV_Vorhersage flowGraphicControl size=300\
animate=1\
showconsumerpower=1\
shift=-10
attr DR.PV_Vorhersage graphicBeam3Content consumption
attr DR.PV_Vorhersage graphicBeam4Content gridconsumption
attr DR.PV_Vorhersage graphicBeamHeightLevel1 100
attr DR.PV_Vorhersage graphicBeamHeightLevel2 100
attr DR.PV_Vorhersage graphicEnergyUnit kWh
attr DR.PV_Vorhersage graphicHistoryHour 12
attr DR.PV_Vorhersage graphicShowDiff top
attr DR.PV_Vorhersage group Vorhersage
attr DR.PV_Vorhersage room KG.PV-Anlage
attr DR.PV_Vorhersage setupBatteryDev KG.Solax\
pin=ChargeDischargePower:W\
pout=-pin\
intotal=BatteryEnergyIn:kWh\
outtotal=BatteryEnergyOut:kWh\
cap=5500\
charge=BatteryCapacity
attr DR.PV_Vorhersage setupInverterDev01 KG.Solax \
pv=PvPower:W\
etotal=SolarEnergy:kWh\
capacity=8000
attr DR.PV_Vorhersage setupInverterStrings Dach
attr DR.PV_Vorhersage setupMeterDev KG.Solax \
gcon=-gfeedin\
contotal=ConsumeEnergy:kWh\
gfeedin=FeedInPower:W\
feedtotal=FeedInEnergy:kWh
attr DR.PV_Vorhersage setupOtherProducer01 DR.Balkonsolaranlage\
pcurr=P_AC:W\
etotal=YieldTotal:kWh\
icon=weather_sun
attr DR.PV_Vorhersage setupRadiationAPI OpenMeteoDWD-API
attr DR.PV_Vorhersage setupStringPeak Dach=6.8
attr DR.PV_Vorhersage setupWeatherDev1 OpenMeteoDWD-API
attr DR.PV_Vorhersage sortby 3
attr DR.PV_Vorhersage verbose 2
# FUUID 66f310ad-f33f-53b0-df82-9a7699394c8a6434
# FVERSION 76_SolarForecast.pm:v1.37.3-s29300/2024-10-26
# LCACHEFILE last write time: 18:35:45 whole Operating Memory
# MODE Automatic - next Cycletime: 18:41:27
# MODEL OpenMeteoDWDAPI
# NAME DR.PV_Vorhersage
# NR 50
# NTFY_ORDER 50-DR.PV_Vorhersage
# STATE updated
# TYPE SolarForecast
# eventCount 6139
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# SPGDETAIL
# SPGDEV DR.PV_Vorhersage
# SPGROOM
# VERSION 1.37.3
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes unused
# VERSION_SMUtils 1.27.3
# OLDREADINGS:
# READINGS:
# 2024-10-29 18:40:17 Current_AutarkyRate 100 %
# 2024-10-29 18:40:17 Current_BatCharge 98 %
# 2024-10-29 18:40:17 Current_Consumption 2697 W
# 2024-10-29 18:40:17 Current_GridConsumption 0 W
# 2024-10-29 18:40:17 Current_GridFeedIn 42 W
# 2024-10-29 18:40:17 Current_PP01 0.0 W
# 2024-10-29 18:40:17 Current_PV 0 W
# 2024-10-29 18:40:17 Current_PowerBatIn 0 W
# 2024-10-29 18:40:17 Current_PowerBatOut 2739 W
# 2024-10-29 18:40:17 Current_SelfConsumption 0 W
# 2024-10-29 18:40:17 Current_SelfConsumptionRate 0 %
# 2024-10-29 18:40:17 Current_Surplus 0 W
# 2024-10-29 18:00:00 LastHourGridconsumptionReal 120 Wh
# 2024-10-29 18:00:00 LastHourPVforecast 0 Wh
# 2024-10-29 18:00:00 LastHourPVreal 0 Wh
# 2024-10-29 18:40:17 NextHours_Sum01_PVforecast 0 Wh
# 2024-10-29 18:40:17 NextHours_Sum02_PVforecast 0 Wh
# 2024-10-29 18:40:17 NextHours_Sum03_PVforecast 0 Wh
# 2024-10-29 18:40:17 NextHours_Sum04_ConsumptionForecast 1082 Wh
# 2024-10-29 18:40:17 NextHours_Sum04_PVforecast 0 Wh
# 2024-10-29 18:40:17 RestOfDayConsumptionForecast 1455 Wh
# 2024-10-29 18:40:17 RestOfDayPVforecast 0 Wh
# 2024-10-29 00:59:49 Today_Hour01_BatIn 0 Wh
# 2024-10-29 00:59:49 Today_Hour01_BatOut 200 Wh
# 2024-10-29 00:59:49 Today_Hour01_GridConsumption 10 Wh
# 2024-10-29 00:59:49 Today_Hour01_GridFeedIn 10 Wh
# 2024-10-29 00:59:49 Today_Hour01_PPreal01 0 Wh
# 2024-10-29 00:59:49 Today_Hour01_PVreal 0 Wh
# 2024-10-29 01:59:58 Today_Hour02_BatIn 0 Wh
# 2024-10-29 01:59:58 Today_Hour02_BatOut 200 Wh
# 2024-10-29 01:59:58 Today_Hour02_GridConsumption 0 Wh
# 2024-10-29 01:59:58 Today_Hour02_GridFeedIn 0 Wh
# 2024-10-29 01:59:58 Today_Hour02_PPreal01 0 Wh
# 2024-10-29 01:59:58 Today_Hour02_PVreal 0 Wh
# 2024-10-29 02:59:53 Today_Hour03_BatIn 0 Wh
# 2024-10-29 02:59:53 Today_Hour03_BatOut 200 Wh
# 2024-10-29 02:59:53 Today_Hour03_GridConsumption 10 Wh
# 2024-10-29 02:59:53 Today_Hour03_GridFeedIn 10 Wh
# 2024-10-29 02:59:53 Today_Hour03_PPreal01 0 Wh
# 2024-10-29 02:59:53 Today_Hour03_PVreal 0 Wh
# 2024-10-29 03:59:49 Today_Hour04_BatIn 0 Wh
# 2024-10-29 03:59:49 Today_Hour04_BatOut 200 Wh
# 2024-10-29 03:59:49 Today_Hour04_GridConsumption 10 Wh
# 2024-10-29 03:59:49 Today_Hour04_GridFeedIn 10 Wh
# 2024-10-29 03:59:49 Today_Hour04_PPreal01 0 Wh
# 2024-10-29 03:59:49 Today_Hour04_PVreal 0 Wh
# 2024-10-29 04:59:51 Today_Hour05_BatIn 0 Wh
# 2024-10-29 04:59:51 Today_Hour05_BatOut 200 Wh
# 2024-10-29 04:59:51 Today_Hour05_GridConsumption 10 Wh
# 2024-10-29 04:59:51 Today_Hour05_GridFeedIn 10 Wh
# 2024-10-29 04:59:51 Today_Hour05_PPreal01 0 Wh
# 2024-10-29 04:59:51 Today_Hour05_PVreal 0 Wh
# 2024-10-29 05:59:50 Today_Hour06_BatIn 0 Wh
# 2024-10-29 05:59:50 Today_Hour06_BatOut 200 Wh
# 2024-10-29 05:59:50 Today_Hour06_GridConsumption 10 Wh
# 2024-10-29 05:59:50 Today_Hour06_GridFeedIn 10 Wh
# 2024-10-29 05:59:50 Today_Hour06_PPreal01 0 Wh
# 2024-10-29 05:59:50 Today_Hour06_PVreal 0 Wh
# 2024-10-29 06:59:52 Today_Hour07_BatIn 0 Wh
# 2024-10-29 06:59:52 Today_Hour07_BatOut 200 Wh
# 2024-10-29 06:59:52 Today_Hour07_GridConsumption 20 Wh
# 2024-10-29 06:59:52 Today_Hour07_GridFeedIn 10 Wh
# 2024-10-29 06:59:52 Today_Hour07_PPreal01 0 Wh
# 2024-10-29 06:59:52 Today_Hour07_PVforecast 21 Wh
# 2024-10-29 06:59:52 Today_Hour07_PVreal 0 Wh
# 2024-10-29 07:59:54 Today_Hour08_BatIn 0 Wh
# 2024-10-29 07:59:54 Today_Hour08_BatOut 200 Wh
# 2024-10-29 07:59:54 Today_Hour08_GridConsumption 0 Wh
# 2024-10-29 07:59:54 Today_Hour08_GridFeedIn 10 Wh
# 2024-10-29 07:59:54 Today_Hour08_PPreal01 0 Wh
# 2024-10-29 07:59:54 Today_Hour08_PVforecast 97 Wh
# 2024-10-29 07:59:54 Today_Hour08_PVreal 100 Wh
# 2024-10-29 08:59:50 Today_Hour09_BatIn 100 Wh
# 2024-10-29 08:59:50 Today_Hour09_BatOut 100 Wh
# 2024-10-29 08:59:50 Today_Hour09_GridConsumption 20 Wh
# 2024-10-29 08:59:50 Today_Hour09_GridFeedIn 10 Wh
# 2024-10-29 08:59:50 Today_Hour09_PPreal01 7 Wh
# 2024-10-29 08:59:50 Today_Hour09_PVforecast 415 Wh
# 2024-10-29 08:59:50 Today_Hour09_PVreal 300 Wh
# 2024-10-29 09:59:53 Today_Hour10_BatIn 200 Wh
# 2024-10-29 09:59:53 Today_Hour10_BatOut 0 Wh
# 2024-10-29 09:59:53 Today_Hour10_GridConsumption 10 Wh
# 2024-10-29 09:59:53 Today_Hour10_GridFeedIn 10 Wh
# 2024-10-29 09:59:53 Today_Hour10_PPreal01 9 Wh
# 2024-10-29 09:59:53 Today_Hour10_PVforecast 1264 Wh
# 2024-10-29 09:59:53 Today_Hour10_PVreal 400 Wh
# 2024-10-29 10:59:57 Today_Hour11_BatIn 300 Wh
# 2024-10-29 10:59:57 Today_Hour11_BatOut 0 Wh
# 2024-10-29 10:59:57 Today_Hour11_GridConsumption 20 Wh
# 2024-10-29 10:59:57 Today_Hour11_GridFeedIn 10 Wh
# 2024-10-29 10:59:57 Today_Hour11_PPreal01 10 Wh
# 2024-10-29 10:59:57 Today_Hour11_PVforecast 2673 Wh
# 2024-10-29 10:59:57 Today_Hour11_PVreal 500 Wh
# 2024-10-29 11:59:53 Today_Hour12_BatIn 300 Wh
# 2024-10-29 11:59:53 Today_Hour12_BatOut 0 Wh
# 2024-10-29 11:59:53 Today_Hour12_GridConsumption 10 Wh
# 2024-10-29 11:59:53 Today_Hour12_GridFeedIn 10 Wh
# 2024-10-29 11:59:53 Today_Hour12_PPreal01 11 Wh
# 2024-10-29 11:59:53 Today_Hour12_PVforecast 1447 Wh
# 2024-10-29 11:59:53 Today_Hour12_PVreal 500 Wh
# 2024-10-29 12:59:51 Today_Hour13_BatIn 1300 Wh
# 2024-10-29 12:59:51 Today_Hour13_BatOut 0 Wh
# 2024-10-29 12:59:51 Today_Hour13_GridConsumption 10 Wh
# 2024-10-29 12:59:51 Today_Hour13_GridFeedIn 20 Wh
# 2024-10-29 12:59:51 Today_Hour13_PPreal01 35 Wh
# 2024-10-29 12:59:51 Today_Hour13_PVforecast 1495 Wh
# 2024-10-29 12:59:51 Today_Hour13_PVreal 1500 Wh
# 2024-10-29 13:59:49 Today_Hour14_BatIn 1900 Wh
# 2024-10-29 13:59:49 Today_Hour14_BatOut 0 Wh
# 2024-10-29 13:59:49 Today_Hour14_GridConsumption 10 Wh
# 2024-10-29 13:59:49 Today_Hour14_GridFeedIn 10 Wh
# 2024-10-29 13:59:49 Today_Hour14_PPreal01 50 Wh
# 2024-10-29 13:59:49 Today_Hour14_PVforecast 1190 Wh
# 2024-10-29 13:59:49 Today_Hour14_PVreal 2200 Wh
# 2024-10-29 14:59:52 Today_Hour15_BatIn 300 Wh
# 2024-10-29 14:59:52 Today_Hour15_BatOut 0 Wh
# 2024-10-29 14:59:52 Today_Hour15_GridConsumption 0 Wh
# 2024-10-29 14:59:52 Today_Hour15_GridFeedIn 930 Wh
# 2024-10-29 14:59:52 Today_Hour15_PPreal01 41 Wh
# 2024-10-29 14:59:52 Today_Hour15_PVforecast 1338 Wh
# 2024-10-29 14:59:52 Today_Hour15_PVreal 2200 Wh
# 2024-10-29 15:59:49 Today_Hour16_BatIn 0 Wh
# 2024-10-29 15:59:49 Today_Hour16_BatOut 0 Wh
# 2024-10-29 15:59:49 Today_Hour16_GridConsumption 0 Wh
# 2024-10-29 15:59:49 Today_Hour16_GridFeedIn 700 Wh
# 2024-10-29 15:59:49 Today_Hour16_PPreal01 10 Wh
# 2024-10-29 15:59:49 Today_Hour16_PVforecast 230 Wh
# 2024-10-29 15:59:49 Today_Hour16_PVreal 1000 Wh
# 2024-10-29 16:59:52 Today_Hour17_BatIn 0 Wh
# 2024-10-29 16:59:52 Today_Hour17_BatOut 0 Wh
# 2024-10-29 16:59:52 Today_Hour17_GridConsumption 10 Wh
# 2024-10-29 16:59:52 Today_Hour17_GridFeedIn 60 Wh
# 2024-10-29 16:59:52 Today_Hour17_PPreal01 5 Wh
# 2024-10-29 16:59:52 Today_Hour17_PVforecast 4 Wh
# 2024-10-29 16:59:52 Today_Hour17_PVreal 200 Wh
# 2024-10-29 17:59:51 Today_Hour18_BatIn 0 Wh
# 2024-10-29 17:59:51 Today_Hour18_BatOut 0 Wh
# 2024-10-29 17:59:51 Today_Hour18_GridConsumption 120 Wh
# 2024-10-29 17:59:51 Today_Hour18_GridFeedIn 0 Wh
# 2024-10-29 17:59:51 Today_Hour18_PPreal01 0 Wh
# 2024-10-29 17:59:51 Today_Hour18_PVreal 0 Wh
# 2024-10-29 18:40:17 Today_Hour19_BatIn 0 Wh
# 2024-10-29 18:40:17 Today_Hour19_BatOut 100 Wh
# 2024-10-29 18:40:17 Today_Hour19_GridConsumption 80 Wh
# 2024-10-29 18:40:17 Today_Hour19_GridFeedIn 0 Wh
# 2024-10-29 18:40:17 Today_Hour19_PPreal01 0 Wh
# 2024-10-29 18:40:17 Today_Hour19_PVreal 0 Wh
# 2024-10-29 18:40:17 Today_MaxPVforecast 2673 Wh
# 2024-10-29 18:40:17 Today_MaxPVforecastTime 2024-10-29 10:00:00
# 2024-10-29 18:40:17 Today_PVdeviation 12.52 %
# 2024-10-29 18:40:17 Today_PVforecast 10174 Wh
# 2024-10-29 18:40:17 Today_PVreal 8900 Wh
# 2024-10-29 18:40:17 Today_SunRise 07:19
# 2024-10-29 18:40:17 Today_SunSet 17:14
# 2024-10-29 18:40:17 Tomorrow_ConsumptionForecast 7694 Wh
# 2024-10-29 18:40:17 Tomorrow_PVforecast 13135 Wh
# 2024-10-29 18:40:17 Tomorrow_SunRise 07:20
# 2024-10-29 18:40:17 Tomorrow_SunSet 17:12
# 2024-10-29 18:40:17 nextCycletime 18:41:27
# 2024-10-29 18:39:06 nextRadiationAPICall nach 29.10.2024 18:54:06
# 2024-10-29 08:00:08 pvCorrectionFactor_08 0.35 (automatic - old factor: 0.30, Sun Alt range: 0, Cloud range: 100, Days in range: 5)
# 2024-10-29 09:00:08 pvCorrectionFactor_09 0.50 (automatic - old factor: 0.47, Sun Alt range: 10, Cloud range: 100, Days in range: 7)
# 2024-10-29 10:00:06 pvCorrectionFactor_10 0.43 (automatic - old factor: 0.80, Sun Alt range: 15, Cloud range: 90, Days in range: 2)
# 2024-10-29 11:00:07 pvCorrectionFactor_11 0.59 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 75, Days in range: 1)
# 2024-10-29 12:00:00 pvCorrectionFactor_12 0.50 (automatic - old factor: 0.82, Sun Alt range: 25, Cloud range: 85, Days in range: 2)
# 2024-10-29 13:00:06 pvCorrectionFactor_13 1.00 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 85, Days in range: 1)
# 2024-10-29 14:00:04 pvCorrectionFactor_14 1.43 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 90, Days in range: 1)
# 2024-10-29 15:00:04 pvCorrectionFactor_15 2.00 (automatic - old factor: 1.50, Sun Alt range: 20, Cloud range: 55, Days in range: 2)
# 2024-10-29 16:00:05 pvCorrectionFactor_16 1.50 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 70, Days in range: 1)
# 2024-10-29 17:00:05 pvCorrectionFactor_17 1.50 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 50, Days in range: 1)
# 2024-10-29 18:40:17 pvCorrectionFactor_Auto on_complex
# 2024-09-26 18:17:02 setupStringAzimuth Dach=-35
# 2024-09-25 20:49:57 setupStringDeclination Dach=40
# 2024-10-29 18:40:18 state updated
#
setstate DR.PV_Vorhersage updated
setstate DR.PV_Vorhersage 2024-10-27 16:19:10 .associatedWith KG.Solax DR.Balkonsolaranlage
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 .lastupdateForecastValues 1730223617
setstate DR.PV_Vorhersage 2024-10-29 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 03:00:07 .pvCorrectionFactor_03_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 03:00:07 .pvCorrectionFactor_03_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 04:00:04 .pvCorrectionFactor_04_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 04:00:04 .pvCorrectionFactor_04_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 05:00:06 .pvCorrectionFactor_05_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 05:00:06 .pvCorrectionFactor_05_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 07:00:05 .pvCorrectionFactor_07_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 07:00:05 .pvCorrectionFactor_07_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 08:00:08 .pvCorrectionFactor_08_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 08:00:08 .pvCorrectionFactor_08_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 09:00:08 .pvCorrectionFactor_09_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 09:00:08 .pvCorrectionFactor_09_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 10:00:06 .pvCorrectionFactor_10_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 10:00:06 .pvCorrectionFactor_10_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 11:00:07 .pvCorrectionFactor_11_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 11:00:07 .pvCorrectionFactor_11_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 12:00:00 .pvCorrectionFactor_12_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 12:00:00 .pvCorrectionFactor_12_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 13:00:06 .pvCorrectionFactor_13_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 13:00:06 .pvCorrectionFactor_13_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 14:00:04 .pvCorrectionFactor_14_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 14:00:04 .pvCorrectionFactor_14_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 15:00:04 .pvCorrectionFactor_15_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 15:00:04 .pvCorrectionFactor_15_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 16:00:05 .pvCorrectionFactor_16_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 16:00:05 .pvCorrectionFactor_16_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 17:00:05 .pvCorrectionFactor_17_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 17:00:05 .pvCorrectionFactor_17_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 18:00:06 .pvCorrectionFactor_18_apipercentil done
setstate DR.PV_Vorhersage 2024-10-29 18:00:06 .pvCorrectionFactor_18_cloudcover done
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 .pvCorrectionFactor_Auto_Soll on_complex
setstate DR.PV_Vorhersage 2024-10-29 01:00:04 .signaldone_01 done
setstate DR.PV_Vorhersage 2024-10-29 02:00:04 .signaldone_02 done
setstate DR.PV_Vorhersage 2024-10-29 03:00:07 .signaldone_03 done
setstate DR.PV_Vorhersage 2024-10-29 04:00:04 .signaldone_04 done
setstate DR.PV_Vorhersage 2024-10-29 05:00:06 .signaldone_05 done
setstate DR.PV_Vorhersage 2024-10-29 06:00:04 .signaldone_06 done
setstate DR.PV_Vorhersage 2024-10-29 07:00:05 .signaldone_07 done
setstate DR.PV_Vorhersage 2024-10-29 08:00:08 .signaldone_08 done
setstate DR.PV_Vorhersage 2024-10-29 09:00:08 .signaldone_09 done
setstate DR.PV_Vorhersage 2024-10-29 10:00:06 .signaldone_10 done
setstate DR.PV_Vorhersage 2024-10-29 11:00:07 .signaldone_11 done
setstate DR.PV_Vorhersage 2024-10-29 12:00:00 .signaldone_12 done
setstate DR.PV_Vorhersage 2024-10-29 13:00:06 .signaldone_13 done
setstate DR.PV_Vorhersage 2024-10-29 14:00:04 .signaldone_14 done
setstate DR.PV_Vorhersage 2024-10-29 15:00:04 .signaldone_15 done
setstate DR.PV_Vorhersage 2024-10-29 16:00:05 .signaldone_16 done
setstate DR.PV_Vorhersage 2024-10-29 17:00:05 .signaldone_17 done
setstate DR.PV_Vorhersage 2024-10-29 18:00:06 .signaldone_18 done
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_AutarkyRate 100 %
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_BatCharge 98 %
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_Consumption 2697 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_GridConsumption 0 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_GridFeedIn 42 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_PP01 0.0 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_PV 0 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_PowerBatIn 0 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_PowerBatOut 2739 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_SelfConsumption 0 W
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_SelfConsumptionRate 0 %
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Current_Surplus 0 W
setstate DR.PV_Vorhersage 2024-10-29 18:00:00 LastHourGridconsumptionReal 120 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:00:00 LastHourPVforecast 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:00:00 LastHourPVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 NextHours_Sum01_PVforecast 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 NextHours_Sum02_PVforecast 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 NextHours_Sum03_PVforecast 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 NextHours_Sum04_ConsumptionForecast 1082 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 NextHours_Sum04_PVforecast 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 RestOfDayConsumptionForecast 1455 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 RestOfDayPVforecast 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 00:59:49 Today_Hour01_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 00:59:49 Today_Hour01_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 00:59:49 Today_Hour01_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 00:59:49 Today_Hour01_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 00:59:49 Today_Hour01_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 00:59:49 Today_Hour01_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 01:59:58 Today_Hour02_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 01:59:58 Today_Hour02_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 01:59:58 Today_Hour02_GridConsumption 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 01:59:58 Today_Hour02_GridFeedIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 01:59:58 Today_Hour02_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 01:59:58 Today_Hour02_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 02:59:53 Today_Hour03_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 02:59:53 Today_Hour03_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 02:59:53 Today_Hour03_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 02:59:53 Today_Hour03_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 02:59:53 Today_Hour03_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 02:59:53 Today_Hour03_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 03:59:49 Today_Hour04_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 03:59:49 Today_Hour04_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 03:59:49 Today_Hour04_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 03:59:49 Today_Hour04_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 03:59:49 Today_Hour04_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 03:59:49 Today_Hour04_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 04:59:51 Today_Hour05_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 04:59:51 Today_Hour05_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 04:59:51 Today_Hour05_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 04:59:51 Today_Hour05_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 04:59:51 Today_Hour05_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 04:59:51 Today_Hour05_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 05:59:50 Today_Hour06_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 05:59:50 Today_Hour06_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 05:59:50 Today_Hour06_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 05:59:50 Today_Hour06_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 05:59:50 Today_Hour06_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 05:59:50 Today_Hour06_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 06:59:52 Today_Hour07_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 06:59:52 Today_Hour07_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 06:59:52 Today_Hour07_GridConsumption 20 Wh
setstate DR.PV_Vorhersage 2024-10-29 06:59:52 Today_Hour07_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 06:59:52 Today_Hour07_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 06:59:52 Today_Hour07_PVforecast 21 Wh
setstate DR.PV_Vorhersage 2024-10-29 06:59:52 Today_Hour07_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 07:59:54 Today_Hour08_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 07:59:54 Today_Hour08_BatOut 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 07:59:54 Today_Hour08_GridConsumption 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 07:59:54 Today_Hour08_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 07:59:54 Today_Hour08_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 07:59:54 Today_Hour08_PVforecast 97 Wh
setstate DR.PV_Vorhersage 2024-10-29 07:59:54 Today_Hour08_PVreal 100 Wh
setstate DR.PV_Vorhersage 2024-10-29 08:59:50 Today_Hour09_BatIn 100 Wh
setstate DR.PV_Vorhersage 2024-10-29 08:59:50 Today_Hour09_BatOut 100 Wh
setstate DR.PV_Vorhersage 2024-10-29 08:59:50 Today_Hour09_GridConsumption 20 Wh
setstate DR.PV_Vorhersage 2024-10-29 08:59:50 Today_Hour09_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 08:59:50 Today_Hour09_PPreal01 7 Wh
setstate DR.PV_Vorhersage 2024-10-29 08:59:50 Today_Hour09_PVforecast 415 Wh
setstate DR.PV_Vorhersage 2024-10-29 08:59:50 Today_Hour09_PVreal 300 Wh
setstate DR.PV_Vorhersage 2024-10-29 09:59:53 Today_Hour10_BatIn 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 09:59:53 Today_Hour10_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 09:59:53 Today_Hour10_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 09:59:53 Today_Hour10_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 09:59:53 Today_Hour10_PPreal01 9 Wh
setstate DR.PV_Vorhersage 2024-10-29 09:59:53 Today_Hour10_PVforecast 1264 Wh
setstate DR.PV_Vorhersage 2024-10-29 09:59:53 Today_Hour10_PVreal 400 Wh
setstate DR.PV_Vorhersage 2024-10-29 10:59:57 Today_Hour11_BatIn 300 Wh
setstate DR.PV_Vorhersage 2024-10-29 10:59:57 Today_Hour11_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 10:59:57 Today_Hour11_GridConsumption 20 Wh
setstate DR.PV_Vorhersage 2024-10-29 10:59:57 Today_Hour11_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 10:59:57 Today_Hour11_PPreal01 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 10:59:57 Today_Hour11_PVforecast 2673 Wh
setstate DR.PV_Vorhersage 2024-10-29 10:59:57 Today_Hour11_PVreal 500 Wh
setstate DR.PV_Vorhersage 2024-10-29 11:59:53 Today_Hour12_BatIn 300 Wh
setstate DR.PV_Vorhersage 2024-10-29 11:59:53 Today_Hour12_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 11:59:53 Today_Hour12_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 11:59:53 Today_Hour12_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 11:59:53 Today_Hour12_PPreal01 11 Wh
setstate DR.PV_Vorhersage 2024-10-29 11:59:53 Today_Hour12_PVforecast 1447 Wh
setstate DR.PV_Vorhersage 2024-10-29 11:59:53 Today_Hour12_PVreal 500 Wh
setstate DR.PV_Vorhersage 2024-10-29 12:59:51 Today_Hour13_BatIn 1300 Wh
setstate DR.PV_Vorhersage 2024-10-29 12:59:51 Today_Hour13_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 12:59:51 Today_Hour13_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 12:59:51 Today_Hour13_GridFeedIn 20 Wh
setstate DR.PV_Vorhersage 2024-10-29 12:59:51 Today_Hour13_PPreal01 35 Wh
setstate DR.PV_Vorhersage 2024-10-29 12:59:51 Today_Hour13_PVforecast 1495 Wh
setstate DR.PV_Vorhersage 2024-10-29 12:59:51 Today_Hour13_PVreal 1500 Wh
setstate DR.PV_Vorhersage 2024-10-29 13:59:49 Today_Hour14_BatIn 1900 Wh
setstate DR.PV_Vorhersage 2024-10-29 13:59:49 Today_Hour14_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 13:59:49 Today_Hour14_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 13:59:49 Today_Hour14_GridFeedIn 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 13:59:49 Today_Hour14_PPreal01 50 Wh
setstate DR.PV_Vorhersage 2024-10-29 13:59:49 Today_Hour14_PVforecast 1190 Wh
setstate DR.PV_Vorhersage 2024-10-29 13:59:49 Today_Hour14_PVreal 2200 Wh
setstate DR.PV_Vorhersage 2024-10-29 14:59:52 Today_Hour15_BatIn 300 Wh
setstate DR.PV_Vorhersage 2024-10-29 14:59:52 Today_Hour15_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 14:59:52 Today_Hour15_GridConsumption 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 14:59:52 Today_Hour15_GridFeedIn 930 Wh
setstate DR.PV_Vorhersage 2024-10-29 14:59:52 Today_Hour15_PPreal01 41 Wh
setstate DR.PV_Vorhersage 2024-10-29 14:59:52 Today_Hour15_PVforecast 1338 Wh
setstate DR.PV_Vorhersage 2024-10-29 14:59:52 Today_Hour15_PVreal 2200 Wh
setstate DR.PV_Vorhersage 2024-10-29 15:59:49 Today_Hour16_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 15:59:49 Today_Hour16_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 15:59:49 Today_Hour16_GridConsumption 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 15:59:49 Today_Hour16_GridFeedIn 700 Wh
setstate DR.PV_Vorhersage 2024-10-29 15:59:49 Today_Hour16_PPreal01 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 15:59:49 Today_Hour16_PVforecast 230 Wh
setstate DR.PV_Vorhersage 2024-10-29 15:59:49 Today_Hour16_PVreal 1000 Wh
setstate DR.PV_Vorhersage 2024-10-29 16:59:52 Today_Hour17_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 16:59:52 Today_Hour17_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 16:59:52 Today_Hour17_GridConsumption 10 Wh
setstate DR.PV_Vorhersage 2024-10-29 16:59:52 Today_Hour17_GridFeedIn 60 Wh
setstate DR.PV_Vorhersage 2024-10-29 16:59:52 Today_Hour17_PPreal01 5 Wh
setstate DR.PV_Vorhersage 2024-10-29 16:59:52 Today_Hour17_PVforecast 4 Wh
setstate DR.PV_Vorhersage 2024-10-29 16:59:52 Today_Hour17_PVreal 200 Wh
setstate DR.PV_Vorhersage 2024-10-29 17:59:51 Today_Hour18_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 17:59:51 Today_Hour18_BatOut 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 17:59:51 Today_Hour18_GridConsumption 120 Wh
setstate DR.PV_Vorhersage 2024-10-29 17:59:51 Today_Hour18_GridFeedIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 17:59:51 Today_Hour18_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 17:59:51 Today_Hour18_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_Hour19_BatIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_Hour19_BatOut 100 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_Hour19_GridConsumption 80 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_Hour19_GridFeedIn 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_Hour19_PPreal01 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_Hour19_PVreal 0 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_MaxPVforecast 2673 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_MaxPVforecastTime 2024-10-29 10:00:00
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_PVdeviation 12.52 %
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_PVforecast 10174 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_PVreal 8900 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_SunRise 07:19
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Today_SunSet 17:14
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Tomorrow_ConsumptionForecast 7694 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Tomorrow_PVforecast 13135 Wh
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Tomorrow_SunRise 07:20
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 Tomorrow_SunSet 17:12
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 nextCycletime 18:41:27
setstate DR.PV_Vorhersage 2024-10-29 18:39:06 nextRadiationAPICall nach 29.10.2024 18:54:06
setstate DR.PV_Vorhersage 2024-10-29 08:00:08 pvCorrectionFactor_08 0.35 (automatic - old factor: 0.30, Sun Alt range: 0, Cloud range: 100, Days in range: 5)
setstate DR.PV_Vorhersage 2024-10-29 09:00:08 pvCorrectionFactor_09 0.50 (automatic - old factor: 0.47, Sun Alt range: 10, Cloud range: 100, Days in range: 7)
setstate DR.PV_Vorhersage 2024-10-29 10:00:06 pvCorrectionFactor_10 0.43 (automatic - old factor: 0.80, Sun Alt range: 15, Cloud range: 90, Days in range: 2)
setstate DR.PV_Vorhersage 2024-10-29 11:00:07 pvCorrectionFactor_11 0.59 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 75, Days in range: 1)
setstate DR.PV_Vorhersage 2024-10-29 12:00:00 pvCorrectionFactor_12 0.50 (automatic - old factor: 0.82, Sun Alt range: 25, Cloud range: 85, Days in range: 2)
setstate DR.PV_Vorhersage 2024-10-29 13:00:06 pvCorrectionFactor_13 1.00 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 85, Days in range: 1)
setstate DR.PV_Vorhersage 2024-10-29 14:00:04 pvCorrectionFactor_14 1.43 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 90, Days in range: 1)
setstate DR.PV_Vorhersage 2024-10-29 15:00:04 pvCorrectionFactor_15 2.00 (automatic - old factor: 1.50, Sun Alt range: 20, Cloud range: 55, Days in range: 2)
setstate DR.PV_Vorhersage 2024-10-29 16:00:05 pvCorrectionFactor_16 1.50 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 70, Days in range: 1)
setstate DR.PV_Vorhersage 2024-10-29 17:00:05 pvCorrectionFactor_17 1.50 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 50, Days in range: 1)
setstate DR.PV_Vorhersage 2024-10-29 18:40:17 pvCorrectionFactor_Auto on_complex
setstate DR.PV_Vorhersage 2024-09-26 18:17:02 setupStringAzimuth Dach=-35
setstate DR.PV_Vorhersage 2024-09-25 20:49:57 setupStringDeclination Dach=40
setstate DR.PV_Vorhersage 2024-10-29 18:40:18 state updated
Ich habe gerade keine Idee mehr, und bin für jeden Tip dankbar.
Die Version der 76_SolarForecast ist aktuell.
Gruß Heiko
Könnte sein - muss nicht sein O:-)
?!? Definition Devicename mit ,,." und ,,_" ?!?
,,DR.PV_Vorhersage,, und dann wieder umbenennen mit alias ,,SolarForecast" ?!?
So was sollte man evtl. vermeiden 😉
Gruß
300P
Guten Abend,
@300P, hattest den richtigen Riecher ... der Name verursacht es in Verbindung mit SVG. Konnte ich bei mir nachvollziehen.
Aber da es nicht so selten vorkommen dürfte (die FHEM Namenskonventionen erlauben es), fixe ich es wie schon bei den Ziffern im Namen.
Ist kein Problem.
LG
Sollte man dann nicht lieber direkt alles replacen/löschen was nicht [A-Za-z] ist.
So für die Zukunft.
Für das SVG könnte man auch einen randomized namen ausgeben. Dann wäre es völlig egal wie das device heißt.
Könnte man ja beim initialisieren einmal anlegen.
Wenn ich z.B. ein Solarforcast1 und ein Solarforcast2 device hätte würde die SVG ID ja immer gleich sein.
Wenn das egal ist, müßßte ich die ID ja eh nicht auf den namen fixieren bzw. eindeutig machen müssen.
Also entweder
1. randomized
oder
2. Zahlen und Sonderzeichen ersetzen (z.B. 0=a, 1=b.... _=l .etc)
oder
3. irgend einen statischen namen immer einpflegen mit gleicher ID. Immer!
Danke, das war es.
Ich habe den Punkt in fast allen Devices und auch einige Unterstriche.
Mir sind bisher damit keine Probleme aufgetreten...
Gruß Heiko
Der Fix ist jetzt eingecheckt in auch in meinem contrib zum sofortigen Download abgelegt.
ZitatSollte man dann nicht lieber direkt alles replacen/löschen was nicht [A-Za-z] ist.
Von den im Devicebamen erlaubten Zeichen die im SVG Probleme bereiten könnten, dürften jetzt alle behandelt sein, also no need.
ZitatWenn ich z.B. ein Solarforcast1 und ein Solarforcast2 device hätte würde die SVG ID ja immer gleich sein.
Nein, ich replace zeichenscharf. In dem Beispiel hättest du dann die ID's: Solarforcastb und Solarforcastc.
Ein einfaches eliminieren geht nicht und passiert auch nicht. (für Code Interessierte: Zeile 641 bis 653)
ZitatIch habe den Punkt in fast allen Devices und auch einige Unterstriche.
Mir sind bisher damit keine Probleme aufgetreten...
Ja, das ist auch völlig in Ordnung. FHEM gibt ja die Konventionen vor.
Nur in dem speziellen Fall erstelle ich (eindeutige) SVG-ID's aus den Device Namen damit man SF-Devices mit unterschiedlichen Einstellungen der FlowGrafik auf einer Raumseite haben kann ohne dass sie sich gegenseitig beeinflussen.
Edit: Bevor die Frage kommt ... ich hätte auch die FUUID (ist ja eindeutig) verwenden können, aber auch dort wären die Ersetzungen von Ziffern nötig gewesen.
@DS_Starter
z.B.
nachdem du die Sachen aus dem namen etnfernt hast mit ..
$stna .= join'', map +('a'..'z','A'..'Z')[rand(26*2)], 1..6;
6 Random-Buchstaben anhängen.
Dann ist es ziemlich eindeutig.
P.S. schade ich fand das random gemüse scharf ;)
:) ... keine Angst, es wird schon noch ein paar scharfe Sachen hier geben. :D
LG
Hallo @all,
in habe die Version 1.37.5 soeben eingecheckt.
Die vorherige Version 1.37.4 lasse ich noch in meinem contrib liegen, falls jemand aus irgendwelchen Gründen den Bedarf haben
sollte auf diese Version zurückzusetzen.
Was ist in der Version 1.37.5 neu bzw. weiterentwickelt:
- die Attribute affect70percentRule, ctrlAutoRefresh, ctrlAutoRefreshFW sind deaktiviert/obsolete und werden in einer der
nächsten Versionen gelöscht
- Im Attribut setupInverterDevXX gibt es einen neuen optionalen Schlüssel 'limit' und der Schlüssel ACHTUNG! 'capacity' ist
nun nicht mehr optional und ist anzugeben wenn das Attribut neu gesetzt wird.
- es gibt ein neues Reading Battery_ChargeRecommended sofern man eine Batterie registriert hat
Hintergrund der Erweiterungen ist mein Bestreben eine optimale Unterstützung bei der Maximierung des Eigenverbrauchs zu geben.
Mit den zur Zeit diskutierten Änderungen des EEG2025 wird es wahrscheinlich noch wichtiger die Verbrauchersteuerung und die
Batterie-Ladungslogik so zu optimieren, dass eine evtl. Zwangsabregelung durch den Netzbetreiber vermieden werden kann und
unser Investment dadurch geschützt wird.
Was letzendlich per Gesetz verabschiedet wird bleibt abzuwarten, aber es kann nicht schaden vorbereitet zu sein.
Das Reading Battery_ChargeRecommended gibt dem User ein Signal ob zu der aktuellen Stunde der Ladevorgang der Batterie gestartet (1) oder
eventuell unterbrochen werden sollte (0). Üblicherweise wird die Batterie geladen sobald PV-Überschuß vorhanden ist ohne eine Prognose zu berücksichtigen. Dadurch sind die Batterien im Sommer vllt. schon um 10-12 Uhr voll geladen und die Anlage liefert ihre mehr oder weniger volle Power (je nach Ausrichtung) in das Netz. Dann könnte es zukünftig zur Zwangsabregelung kommen (Stichwort negativer Strompreis an der Börse). Das gilt es zu verhindern.
Die implementierte Logik werde ich im Wiki noch genauer beschreiben ... in der Kürze nur Folgendes:
Die benötigte Beladung der Bat bis SOC 100% wird ermittelt und mit der zu erwartenden PV Tagesprognose in Beziehung gesetzt.
Sofern die PV-Erzeugung abzgl. Verbrauch noch nicht das Wirkleistungbegrenzungs-Limit (es wird 50% :o diskutiert) erreicht UND noch genügend PV-Überschuß für SOC 100% im Laufe der kommenden Stunden des Tages zu erwarten ist, bleibt das Reading Battery_ChargeRecommended = 0.
Wird allerdings entweder das Wirkleistungbegrenzungs-Limit erreicht/überschritten und/oder die PV-Überschußprognose zzgl. eines
Sicherheitspuffers unterschritten, wird Battery_ChargeRecommended = 1 und der User kann darauf reagieren und seine Batterie-Ladung
aktivieren. Wie das geht ist natürlich von Anlage zu Anlage verschieden. Bei Victron GX Venus kann man das z.B. über den Grid Setpoint steuern, was ich auch mal im Wiki beschreiben werde.
Möglicherweise können wir in der Balkengrafik signalisieren in welchen Stundensegmenten des Tages die Batterieladung aktiviert
werden sollte (wie im Anhang simuliert). Dadurch hat der User ein besseres Gefühl und Vertrauen dass die Batterieladung optimal gesteuert wird.
Als weitere Schritte habe ich vor, mich des Themas flexible Strompreise anzunehmen und eine Integrationsmöglichkeit zu schaffen.
Auch diese Sachverhalte sollen sich nahtlos in Logikentscheidungen einfügen.
LG,
Heiko
Moin,
ich habe gerade bemerkt dass der Key 'cap' im Attr setupBatteryDev noch als optional gekennzeichnet ist.
Für die neue Funktionalität wird er allerdings benötigt.
Ich werde ihn in der nächsten Version als mandatory definieren.
Wer bis dahin mit dem Reading Battery_ChargeRecommended etwas experimentieren möchte muß auch 'cap' angegeben haben.
LG
Moin,
erst einmal danke für das tolle Modul. Es ist genau das was ich gesucht habe.
Nun zu meiner Frage,
Ich habe das Modul definiert und alles benötigten Angaben gefüllt. Nun gibt es leider eine Diskrepanz zwischen dem Modul und der Solaredge Übersicht beim Hausverbrauch.
Ich habe alle Angaben im Modul mehrfach gecheckt, bin aber wohl betriebsblind und finde den Fehler nicht der dieses Verhalten auslöst.
Kann mir jemand auf die Sprünge helfen?
Anbei ein list vom Device
Internals:
FUUID 67247ac1-f33f-d66d-4e77-94b6b4acd8c6944b
FVERSION 76_SolarForecast.pm:v1.1.1-s29323/2024-10-31
LCACHEFILE last write time: 10:30:32 File: ./FHEM/FhemUtils/PVCfg_SolarForecast_PV_forecast
MODE Automatic - next Cycletime: 10:33:43
MODEL DWD
NAME PV_forecast
NR 1540
NTFY_ORDER 50-PV_forecast
STATE updated
TYPE SolarForecast
eventCount 227
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV PV_forecast
SPGROOM
VERSION 1.37.0
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes unused
VERSION_SMUtils 1.27.2
OLDREADINGS:
READINGS:
2024-11-01 10:32:33 Battery_ChargeRecommended 1
2024-11-01 10:32:33 Current_AutarkyRate 32 %
2024-11-01 10:32:33 Current_BatCharge 21 %
2024-11-01 10:32:33 Current_Consumption 504 W
2024-11-01 10:32:33 Current_GridConsumption 341 W
2024-11-01 10:32:33 Current_GridFeedIn 0 W
2024-11-01 10:32:33 Current_PV 184 W
2024-11-01 10:32:33 Current_PowerBatIn 21 W
2024-11-01 10:32:33 Current_PowerBatOut 0 W
2024-11-01 10:32:33 Current_SelfConsumption 163 W
2024-11-01 10:32:33 Current_SelfConsumptionRate 89 %
2024-11-01 10:32:33 Current_Surplus 0 W
2024-11-01 10:00:00 LastHourGridconsumptionReal 486 Wh
2024-11-01 10:00:00 LastHourPVforecast 191 Wh
2024-11-01 10:00:00 LastHourPVreal 40 Wh
2024-11-01 10:32:33 NextHours_Sum01_PVforecast 326 Wh
2024-11-01 10:32:33 NextHours_Sum02_PVforecast 678 Wh
2024-11-01 10:32:33 NextHours_Sum03_PVforecast 1014 Wh
2024-11-01 10:32:33 NextHours_Sum04_ConsumptionForecast 0 Wh
2024-11-01 10:32:33 NextHours_Sum04_PVforecast 1262 Wh
2024-11-01 10:32:33 RestOfDayConsumptionForecast 0 Wh
2024-11-01 10:32:33 RestOfDayPVforecast 1489 Wh
2024-11-01 08:53:30 Today_Hour09_GridConsumption 28 Wh
2024-11-01 08:53:30 Today_Hour09_GridFeedIn 0 Wh
2024-11-01 08:53:30 Today_Hour09_PVreal 8000 Wh
2024-11-01 09:59:53 Today_Hour10_BatIn 0 Wh
2024-11-01 09:59:53 Today_Hour10_BatOut 0 Wh
2024-11-01 09:59:53 Today_Hour10_GridConsumption 486 Wh
2024-11-01 09:59:53 Today_Hour10_GridFeedIn 0 Wh
2024-11-01 09:59:53 Today_Hour10_PVforecast 191 Wh
2024-11-01 09:59:53 Today_Hour10_PVreal 40 Wh
2024-11-01 10:32:33 Today_Hour11_BatIn 0 Wh
2024-11-01 10:32:33 Today_Hour11_BatOut 0 Wh
2024-11-01 10:32:33 Today_Hour11_GridConsumption 87 Wh
2024-11-01 10:32:33 Today_Hour11_GridFeedIn 0 Wh
2024-11-01 10:32:33 Today_Hour11_PVforecast 306 Wh
2024-11-01 10:32:33 Today_Hour11_PVreal 120 Wh
2024-11-01 10:32:33 Today_Hour12_PVforecast 344 Wh
2024-11-01 10:32:33 Today_Hour13_PVforecast 357 Wh
2024-11-01 10:32:33 Today_Hour14_PVforecast 319 Wh
2024-11-01 10:32:33 Today_Hour15_PVforecast 191 Wh
2024-11-01 10:32:33 Today_Hour16_PVforecast 115 Wh
2024-11-01 10:32:33 Today_Hour17_PVforecast 26 Wh
2024-11-01 10:32:33 Today_MaxPVforecast 357 Wh
2024-11-01 10:32:33 Today_MaxPVforecastTime 2024-11-01 12:00:00
2024-11-01 10:32:33 Today_PVforecast 1849 Wh
2024-11-01 10:32:33 Today_PVreal 160 Wh
2024-11-01 10:32:33 Today_SunRise 07:22
2024-11-01 10:32:33 Today_SunSet 16:45
2024-11-01 10:32:33 Tomorrow_ConsumptionForecast Warte auf weitere Tage mit einer Verbrauchszahl Wh
2024-11-01 10:32:33 Tomorrow_PVforecast 7162 Wh
2024-11-01 10:32:33 Tomorrow_SunRise 07:24
2024-11-01 10:32:33 Tomorrow_SunSet 16:43
2024-11-01 08:16:36 currentInverterDev SE3500H pv=AC_current_W:W etotal=gesamtPV:kWh capacity=3600
2024-11-01 07:59:28 currentRadiationAPI PV_forecast_weather
2024-11-01 07:57:43 inverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
2024-11-01 08:20:00 moduleAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
2024-11-01 08:22:24 moduleDeclination Vordach=40 Fahrradschuppen=25 Dach=45 Garten=15 Wintergarten=15
2024-11-01 08:20:38 modulePeakString Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.94
2024-11-01 10:32:33 nextCycletime 10:33:43
2024-11-01 10:32:33 pvCorrectionFactor_Auto standby (remains in standby for 1.92 hours)
2024-11-01 08:59:45 setupStringAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
2024-11-01 09:00:03 setupStringDeclination Vordach=40 Fahrradschuppen=25 Dach=45 Garten=15 Wintergarten=15
2024-11-01 10:32:34 state updated
Attributes:
ctrlLanguage DE
event-on-change-reading .*
graphicShowDiff top
room PV-forecast
setupBatteryDev Hyper2000 pin=properties_report_properties_outputPackPower:W pout=properties_report_properties_outputHomePower:W cap=2000:Wh charge=properties_report_properties_electricLevel
setupInverterDev01 SE3500H pv=AC_current_W:W etotal=AC_Lifetime_Energy_production_kWh:kWh capacity=3600
setupInverterDev02 Hyper2000 pv=properties_report_properties_solarInputPower:W etotal=properties_report_packData_1_totalVol:Wh capacity=880
setupInverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
setupMeterDev SE3500H gcon=Hausverbrauch:W contotal=total_Energy_Imported_kWh:kWh gfeedin=Momentanleistung_Einspeisung:W feedtotal=total_Energy_Exported_kWh:kWh
setupRadiationAPI PV_forecast_weather
setupStringPeak Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.94
setupWeatherDev1 PV_forecast_weather
Moin,
das Modul liest die Reading-Werte der einzelnen Devices im Abstand von ctrlInterval (default 70s) aus.
Dadurch können sich Abweichungen zum Momentanzustand ergeben, gerade bei oft wechselnden Erzeugungs/Verbrauchsbedingungen.
Du kannst je nach Leistungsfähigkeit deines Servers durchaus den Zyklus kleiner stellen, z.B. ctrlInterval=10.
Die Erweiterung der Asynchronität (siehe #1288) ist auch noch ein Thema für die Weiterentwicklung.
LG,
Heiko
Ich knobele immer noch an einer Verbesserung der Prognose ohne KI-Korrektur.
Frage zu Deinem Vergleich von trackFlex/trackFull/trackShared:
In welcher Einheit sind die Vergleichsdaten aus der Tabelle? Und wenn es relative Werte sind, auf was beziehen sie sich?
LG
pah
ZitatIn welcher Einheit sind die Vergleichsdaten aus der Tabelle? Und wenn es relative Werte sind, auf was beziehen sie sich?
Die in der Tabelle abgetragenen Werte sind die Tagesabweichungen in % (nach Sonnenuntergang) zwischen Prognose und Ist ohne jegliche Korrekturen in den jeweiligen Varianten. Der Idealfall wäre "0".
Anbei zur Erläuterung Screenshots der Varianten von heute.
Angehängt ist auch die fortgeführte Vergleichstabelle bis heute.
Verallgemeinert stellt es sich für mich so dar, dass trackFull bei sonnigen / leicht bewölkten Witterungslagen klar die besten Ergebnisse bringt. Bei starker Bewölkung liegt trackShared durch den verminderten Anteil der Direktstrahlung vorn.
LG,
Heiko
Danke. Also prozentuale Abweichung der Energie. Aber Prozent von der Vorhersage, oder Prozent der gemessenen Energiemenge? Was also steht im Zähler, was im Nenner?
Ich messe seit 2007 mit einem geeichten Sensor die Einstrahlung in meine erste PV-Anlage und kann das also sehr gut vergleichen.
LG
pah
Musste selbst erstmal nachschauen ...
$pvre / $pvfc , also PV-real / PV-Forecast
Edit:
ZitatIch messe seit 2007 mit einem geeichten Sensor die Einstrahlung in meine erste PV-Anlage und kann das also sehr gut vergleichen
Sind deine Messungen vergleichbar mit dem Rad1h des DWD?
LG
Zitat von: DS_Starter am 01 November 2024, 20:40:20Sind deine Messungen vergleichbar mit dem Rad1h des DWD?
Noch nicht, bisher nur perspektivisch. Der Sensor ist direktional, parallel zu den Modulen meiner alten PV-Anlage.
Rad1h ist die Globalstrahlung, also omnidirektional auf einer horizontalen Fläche.
Nötig ist also ein Modell - und da hoffe ich zu etwas zu kommen, das man für jeden Standort und jede Anlage anpassen kann, ohne auf den "Flächenfaktor" für München zurückgreifen zu müssen. Dann kann ich das eben mit den Messwerten sehr gut vergleichen.
LG
pah
Guten Morgen,
ich habe gestern Abend mal meine 3 WR einzeln in einem gleichartigen SF-Test aufgebaut.
Bei der Kontrolle ist mir etwas aufgefallen:
Habe einen Punkt gefunden der evtl. nicht ganz sauber ist.(oder von mir etwas nicht eingerichtet worden ist)
Hier ein Auszug aus den attr:
attr Forecast_Test setupBatteryDev BatteryDummy pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=19600
attr Forecast_Test setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings:GarageSE
attr Forecast_Test setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings:GarageNW,HausNW
attr Forecast_Test setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings:HausSE1,HausSE2,HausSW
attr Forecast_Test setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast_Test setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast_Test setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast_Test setupRadiationAPI DWD
attr Forecast_Test setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.1 HausSE2=2.1
attr Forecast_Test setupWeatherDev1 DWD
attr Forecast_Test stateFormat Current_PV
attr Forecast_Test verbose 2
Jetzt der evtl. Fehler den ich meine bei "get valInverter":
(oder mein Einrichtungsfehler ??)
01 => ialias => SB25
ietotal => 14483419
ifeed => default
igeneration => 1633
ilimit => 100
iname => SB25
invertercap => 2500
02 => ialias => SB30
ietotal => 6658965
ifeed => default
igeneration => 221
ilimit => 100
iname => SB30
invertercap => 3000
03 => ialias => SB40
ietotal => 6423395
ifeed => default
igeneration => 318
ilimit => 100
iname => SB40
invertercap => 4000
Da fehlt der zugeordnete String zu den WRs :o - oder liege ich falsch (siehe auch Screenshot)
Danke für eine Aufklärung 🤩
Gruß
300P
Moin,
da ist ein Eigabefehler:
strings:GarageSE -> strings=GarageSE
Die andere setupInverterDev natürlich auch. 😉
Lg
Ohne Worte
:o :o :o :o
🦯🦯🦯🦯🦯
🦮🦮🦮🦮🦮
👨�🦯👨�🦯👨�🦯👨�🦯👨�🦯
🤦🤦🤦🤦🤦
Danke !
Und schönen Sonntag
Wäre es möglich setupWeatherDev1 und setupRadiationAPI auch beim Open-Meteo API zu trennen?
Meine nächste DWD Station (bin in Österreich) ist recht weit entfernt und OpenMeteoDWD-API liefert über das ICON-D2 Modell wesentlich bessere Vorrausagen für meinen Standort.
Andererseits habe ich die Werte aus der SolCast-API jetzt ein Jahr lang beobachtet und die liefert im Schnitt die besseren Werte für die Strahlung.
Konkret würde ich also gerne setupRadiationAPI=SolCast-API und setupWeatherDev1=OpenMeteoDWD-API einstellen können, damit das Wetter vom Open-Meteo kommt (für die Anzeige und die Korrekturfaktoren) und die Rohdaten für die Strahlungsprognosewert von SolCast.
Das muss ich mir erstmal genauer anschauen wenn die Entwicklung weitergeht.
Problematisch dabei ist das Management beider verschiedener APIs gleichzeitig bezüglich ihrer jeweiligen Abrufbeschränkungen und der Berechnung der API Zyklen.
LG
Zitat von: DS_Starter am 31 Oktober 2024, 21:30:09Als weitere Schritte habe ich vor, mich des Themas flexible Strompreise anzunehmen und eine Integrationsmöglichkeit zu schaffen.
Auch diese Sachverhalte sollen sich nahtlos in Logikentscheidungen einfügen.
Darauf bin ich schon gespannt. Mittlerweile helfe ich mir nur mit dem Abschalten einzelner unkritischer Verbraucher beim Überschreiten einer vordefinierten Schwelle sowie Push-Benachrichtigung beim Unterschreiten von 2 vordefinierten Schwellen ("Bezug günstiger als Einspeisevergütung" sowie "Bezugspreis negativ").
Zitat von: DS_Starter am 03 November 2024, 13:41:30Das muss ich mir erstmal genauer anschauen wenn die Entwicklung weitergeht.
Heute habe ich wieder den Fall, dass die Prognose von DWD den ganzen Tag für mich komplett daneben liegt, aber für die Wetterstation korrekt wäre: bei mir Sonne, aber vorhergesagt und korrekt an der Station Hochnebel.
Damit sind complex(_ai) Korrekturen leider sinnlos.
Zitat von: DS_Starter am 03 November 2024, 13:41:30Problematisch dabei ist das Management beider verschiedener APIs gleichzeitig bezüglich ihrer jeweiligen Abrufbeschränkungen und der Berechnung der API Zyklen.
Wär's nicht ohnehin schöner, die OpenMeteo Wetterprognose in ein eigenes Devices auszulagern, so wie beim DWD? Dann kann dort der API Zyklus gemanaged werden, unabhängig von der Radiation Quelle.
ZitatWär's nicht ohnehin schöner, die OpenMeteo Wetterprognose in ein eigenes Devices auszulagern
Mit Modularisierung brauchst du DS_Starter nicht kommen, das ist "bah" :o
Nö ist nicht bäh.
Nur wer soll einzelne Module erstellen und ständig einzeln und im Zusammenspiel pflegen?
Ich? Das würde meinen Zeitfond übersteigen. Es ist im Hinblick auf die sonstigen Module die ich betreue bereits jetzt schon grenzwertig.
Aber wenn jemand mitmacht, warum nicht.
LG
Ich habe volles Verständnis dafür, dass man nicht beliebig viel Zeit in FHEM investieren kann. Aus genau dem Grund habe ich das Shelly-Modul abgegeben, alle anderen von mir betreuten sind weitgehend stabil.
Allerdings bin ich auch für eine Trennung der Funktionalitäten:
- Vorhersage
- Management
- Visualisierung
Vor allem sind kleinere Module leichter zu pflegen, und es finden sich deshalb auch eher weitere Mitstreiter.
Wichtig wäre deshalb, Standards zu definieren. So dass eben nicht das "Zusammenspiel" ebenfalls leidet, wenn man an einem der Module etwas ändert.
LG
pah
P.S.: Und ja: Es ist ein wenig schmerzhaft, wenn die eigene Arbeit von anderen übernommen wird - und vielleicht ganz anders weiter entwickelt wird, als man es selbst getan hätte. Sehe ich gerade nicht nur in FHEM, sondern auch in meiner Forschung. Aber so ist der Lauf der Dinge, und das muss man akzeptieren.
Nun, das SF-Modul kann die Daten an eine eigene/externe Visualisierung liefern sofern jemand eine externe Visualisierungslösung erstellen möchte, oder einen anderen Datenkonsumenten.
Sollte jemand ein OpenMeteo Modul entwickeln, kann ich es ebenso wie das DWD einbinden. Wenn sich der Entwickler an die Struktur des OpenDwd hält, wäre der Standard schon geschaffen. Aber man sieht ja schon beim DWD Modul ... die Weiterentwicklung mit der jeder happy ist liegt mittlerweile schon 9 Monate im contrib und findet keinen Weg ins Repo. Hmm...
Also wennn jemand diesbezüglich Ambitionen hat ein OpenMeteo Modul zu bauen, kann er sich ja gern melden. Da ist doch nichts dagegen zu sagen und ich bin der letzte der sich weigern würde ein solchen Datenlieferanten einzubinden.
Bisher hatte ich allerdings nur den Eindruck _ich_ soll doch die Archtektur umbauen und _ich_ soll alles auseinanderpflücken und weitere Module bauen.
Genau das werde _ich_ nicht tun, zuviel Lebenszeit wird dadurch geopfert ohne einen sachlichen Zwang der dies jetzt unbedingt benötigt.
BTW... für das gewünschte Anliegen ist mir vermutlich bereits ein gangbarer Weg im Kopf.
Falls das noch gewünscht sein sollte.
LG
Zitat von: DS_Starter am 07 November 2024, 18:48:17Also wennn jemand diesbezüglich Ambitionen hat ein OpenMeteo Modul zu bauen, kann er sich ja gern melden.
Ich kann mich ja mal daran versuchen, aber ich bin eher der perl-Bastler/Fixer denn Experte.
Ich bräuchte dazu dann noch etwas Input, was die Schnittstelle bzw. die erwarteten Readings für SF sind.
Gibt's bei Dir zum Thema OpemMeteo noch weitere Quellen als das SF Modul, die ich mir ansehen kann?
Gerne dann PM, damit wir hier den Thread nicht damit kapern (oder vielleicht ein eigener Thread für ein OM Modul?).
Zitat von: DS_Starter am 07 November 2024, 18:48:17BTW... für das gewünschte Anliegen ist mir vermutlich bereits ein gangbarer Weg im Kopf.
Falls das noch gewünscht sein sollte.
Ja, bitte ;D
LG
Hallo fichtennadel,
habe dir eine PM geschrieben.
Die Umsetzung meines Ansatzes gehe ich an wenn ich wieder "im Dienst" bin.
LG,
Heiko
Hallo liebe Forum-Experten,
Ich habe in meinem Setup derzeit regelmäßig Fehlermeldungen wie diese:
2024.11.15 08:05:13.638 3: Solar - WARNING - The stored Energy consumption of day/hour 09/14 is negative. This appears to be an error. The incorrect value can be deleted with 'set Solar reset consumption 09 14'.
Meine PV-Batterie unterstützt das Nachladen aus dem Netz in Abhängigkeit vom Strompreis, was ich mit evcc steuere. Es sieht so aus, als würde das Modul den Energiefluss Grid -> Battery nicht berücksichtigen. Die entsprechenden Readings sehen nämlich eigentlich plausibel aus. Das könnte vielleicht die o.a. Fehlermeldung erklären. Das Diagramm zeigt auch Grütze an.
Ist meine These korrekt oder muss ich in meinem Setup weitersuchen?
Gruß, Thomas
Hi,
ich habe auch diese Meldungen und ebenfalls einen Batteriespeicher
//Roger
Zitat von: Thomas Vandahl am 15 November 2024, 08:17:12Hallo liebe Forum-Experten,
Ich habe in meinem Setup derzeit regelmäßig Fehlermeldungen wie diese:
2024.11.15 08:05:13.638 3: Solar - WARNING - The stored Energy consumption of day/hour 09/14 is negative. This appears to be an error. The incorrect value can be deleted with 'set Solar reset consumption 09 14'.
Meine PV-Batterie unterstützt das Nachladen aus dem Netz in Abhängigkeit vom Strompreis, was ich mit evcc steuere. Es sieht so aus, als würde das Modul den Energiefluss Grid -> Battery nicht berücksichtigen. Die entsprechenden Readings sehen nämlich eigentlich plausibel aus. Das könnte vielleicht die o.a. Fehlermeldung erklären. Das Diagramm zeigt auch Grütze an.
Ist meine These korrekt oder muss ich in meinem Setup weitersuchen?
Gruß, Thomas
Hallo Zusammen,
mir geht es ebenfalls so ;-)
Gruß
Christian
Zitat von: Roger am 15 November 2024, 09:44:35Hi,
ich habe auch diese Meldungen und ebenfalls einen Batteriespeicher
//Roger
Zitat von: Thomas Vandahl am 15 November 2024, 08:17:12Hallo liebe Forum-Experten,
Ich habe in meinem Setup derzeit regelmäßig Fehlermeldungen wie diese:
2024.11.15 08:05:13.638 3: Solar - WARNING - The stored Energy consumption of day/hour 09/14 is negative. This appears to be an error. The incorrect value can be deleted with 'set Solar reset consumption 09 14'.
Meine PV-Batterie unterstützt das Nachladen aus dem Netz in Abhängigkeit vom Strompreis, was ich mit evcc steuere. Es sieht so aus, als würde das Modul den Energiefluss Grid -> Battery nicht berücksichtigen. Die entsprechenden Readings sehen nämlich eigentlich plausibel aus. Das könnte vielleicht die o.a. Fehlermeldung erklären. Das Diagramm zeigt auch Grütze an.
Ist meine These korrekt oder muss ich in meinem Setup weitersuchen?
Gruß, Thomas
Das ist aber nur eine Warnung und kein Fehler!
Das wurde extra eingepflegt einst. Finde das gerade aber nicht was der genaue Grund war.
Ich Frage mich auch ob das folgende so Sinnvoll ist.
ZitatMeine PV-Batterie unterstützt das Nachladen aus dem Netz in Abhängigkeit vom Strompreis, was ich mit evcc steuere.
Mal durchgerechnet wieviel du billiger sein musst damit sich das lohnt?
Ich habe es auch mal ein halbes Jahr mit den dynamischem Tarif probiert und wieder sein gelassen......
Ein kWh-Preis von 25,4 Cent war mir da lieber......und günstiger
Gruß
300P
Edit:
Sind aber auch nur ca. 300 - 600kWh Bezug im Jahr bei mir 😉
Zitat von: kask am 16 November 2024, 19:47:37Das ist aber nur eine Warnung und kein Fehler!
Das wurde extra eingepflegt einst. Finde das gerade aber nicht was der genaue Grund war.
Ich Frage mich auch ob das folgende so Sinnvoll ist.
ZitatMeine PV-Batterie unterstützt das Nachladen aus dem Netz in Abhängigkeit vom Strompreis, was ich mit evcc steuere.
Mal durchgerechnet wieviel du billiger sein musst damit sich das lohnt?
Ja, klar. Das ist aber nicht der Punkt.
Die Fehlermeldung ist aber IMO nur ein Symptom dafür, dass irgendwas mit der Energieflussberechnung nicht stimmt. Ich sehe in den SolarForecast-Stunden-Readings nachts PV-Erträge, wo keine sein können und nach den vom Wechselrichter gelieferten Werten auch keine sind.
Meine Vermutung ist jetzt, dass in der Berechnung die von der Batterie gelieferte Energie als PV-Ertrag angenommen wird, was halt in meinem Fall nicht immer stimmt. Kann mir das jemand bestätigen?
Zitat von: 300P am 16 November 2024, 20:37:58Ich habe es auch mal ein halbes Jahr mit den dynamischem Tarif probiert und wieder sein gelassen......
Ein kWh-Preis von 25,4 Cent war mir da lieber......und günstiger
So sieht es aus. Wieder mal Dunkelflaute, und keine Besserung in Sicht. Deutschland - also "wir" - hat bisher schon etwa 400 Milliarden € in die so genannte Energiewende investiert. Und dafür den einen Energiemix bekommen, der zu den schmutzigsten in Europa gehört. Meine persönliche Meinung dazu kann man woanders nachlesen, https://wider-die-angst.de/dunkelflaute-statt-energiewende-ii/
Betreffend FHEM: Auch ich lade derzeit meinen Speicher mal wieder aus dem Netz nach, denn derzeit besteht ein hohes Risiko eines Netzausfalls. Und dann will ich meine Notstromumschaltung aktivieren können. Eine mögliche Weiterentwicklung des Moduls könnte sein, dass dies separat registriert wird. Und dann natürlich vom PV-Ertrag abgezogen wird.
LG
pah
Zitat von: Thomas Vandahl am 15 November 2024, 08:17:12Hallo liebe Forum-Experten,
Ich habe in meinem Setup derzeit regelmäßig Fehlermeldungen wie diese:
2024.11.15 08:05:13.638 3: Solar - WARNING - The stored Energy consumption of day/hour 09/14 is negative. This appears to be an error. The incorrect value can be deleted with 'set Solar reset consumption 09 14'.
Meine PV-Batterie unterstützt das Nachladen aus dem Netz in Abhängigkeit vom Strompreis, was ich mit evcc steuere. Es sieht so aus, als würde das Modul den Energiefluss Grid -> Battery nicht berücksichtigen. Die entsprechenden Readings sehen nämlich eigentlich plausibel aus. Das könnte vielleicht die o.a. Fehlermeldung erklären. Das Diagramm zeigt auch Grütze an.
Ist meine These korrekt oder muss ich in meinem Setup weitersuchen?
Gruß, Thomas
Guten Morgen,
ich habe den RPI in den Logs mal nach der Meldung oder ähnlichen suchen lassen - in der Zeit als ich mit dem dynamischen Tarif die Batterie evtl. "nach"-laden lassen habe.
Es ist in den letzten Monaten (bis Ende Oktober) aber keine einzige Meldung dazu bei mir zu finden (mit meiner Konstellation).
Kann aber auch nicht sagen ab wann diese Warnung "drin" ist/war.
Gruß
300P
Hallo miteinander,
nur eine kurze Info aus der Ferne ...
ZitatMeine Vermutung ist jetzt, dass in der Berechnung die von der Batterie gelieferte Energie als PV-Ertrag angenommen wird
Für die PV Erzeugung werden nur die gelieferten Werte aus den Angaben des setupInverterDev herangezogen.
Der Netzbezug geht als gelieferte Energie in die Gesamtverbrauchsrechnung ein, wobei die Batterieladung daraus zu dem Zeitpunkt keinen Verbrauch darstellt, sondern erst wenn die Bat wieder entladen wird und Energie für den Verbrauch liefert. Dadurch kann die Summe des Verbrauchs zu der Stunde negativ werden. Wenn das Setup ok ist und man weiss wieso die Meldung kommt - igno bzw. Loglevel auf 2 im Dev setzen.
Schaue ich mir trotzdem nochmal an um sicher zu sein.
Ansonsten wäre ein ctrlDebug collectData um die Zeit herum hilfreich. Es werden aber viele Daten geloggt, deswegen durch geeignete Massnahmen temp. einschalten.
LG
Zitat von: 300P am 16 November 2024, 20:37:58Ich habe es auch mal ein halbes Jahr mit den dynamischem Tarif probiert und wieder sein gelassen......
Same story here...
Habe dieses Jahr im Februar den Preisverlauf von 2023 bis inkl. 01.2024 intensiv studiert und entschieden, einen dynamischen Tarif zu nehmen. Bis zum Ende vom Sommer war's auch wirklich in Ordnung und im Preisrahmen von 2023, aber keine Ahnung was danach passiert ist.
Letzte Woche habe ich die Wärmepumpe sogar schon einmal in der Nacht laufen lassen, weil der Tagespreis dank Nebelsuppe exorbitant hoch war und die PV höchstens die Hälfte des Verbrauchs abgedeckt hätte. Sie mit den günstigen Nachtpreisen laufen zu lassen, war trotz schlechterem COP wg. niedrigerer Außentemperatur immer noch weit billiger als tagsüber mit Hälfte des Stroms vom Dach.
Interessanterweise gibt es nun aber wieder deutlich günstigere Fixpreis-Tarife (in Österreich) als noch im Sommer, drum habe ich am Freitag auch gleich den Wechsel angestoßen. Da soll sich noch wer auskennen...
Ist es eigentlich normal so viele timeouts von der Open-Meteo-API zu bekommen?
% grep 'https://ensemble-api.open-meteo.com:443 timed out' fhem-2024-11.log | wc -l
292
Heute, also am 20.11., wären das 14.6 fehlgeschlagene Zugriffe pro Tag. Der "Status-Punkt" im Device ist auch gefühlt dauernd rot statt grün...
Bei 14.6 (14600 fehlgeschlagen Abrufe) wäre die Anzahl der täglichen Abfragen um fast 150 % überschritten
(Wenn du mit "14.6" (vierzehntausend-sechshundert meinst :o )
Terms of Use
Open-Meteo assumes ........
......Non-Commercial Use
By using the Free API for non-commercial use you agree to following terms:
Less than 10'000 API calls per day, 5'000 per hour and 600 per minute.
......
Gruß
300P
EDIT:
Welchen Interval hast du ?
292 Einträge / 20Tage = 14,6/tag
Zurück zum Thema.
blah@fhem:/opt/fhem/log# grep 'https://ensemble-api.open-meteo.com:443 timed out' fhem-2024-11.log | wc -l
0
..nicht normal
Aber ich ahbe auch 2 aber von anderen.
2024.11.08 15:36:46 1: ForecastOpenMeteo - Open-Meteo DWD ICON API server response: connect to https://api.open-meteo.com:443 timed out
2024.11.14 05:38:22 1: ForecastOpenMeteoWorld - Open-Meteo DWD ICON API server response: start_SSL https://api.open-meteo.com:443 timed out
Vieleicht mal eine Ausgabe mit "| tail -10" anstatt "| wc -l" posten?
Bei mir sieht man ja auch ein bischen wo was klemmt bei den beiden.
Alle time outs sehen so aus:
2024.11.21 12:00:53.104 1: solarforecast - Open-Meteo DWD ICON API server response: start_SSL https://ensemble-api.open-meteo.com:443 timed out
2024.11.21 12:16:00.423 1: solarforecast - Open-Meteo DWD ICON API server response: start_SSL https://ensemble-api.open-meteo.com:443 timed out
2024.11.21 12:46:21.142 1: solarforecast - Open-Meteo DWD ICON API server response: start_SSL https://ensemble-api.open-meteo.com:443 timed out
Von meinem Netz aus habe ich normalerweise keine Probleme...
Gut, ich vermute mal, daß wir hier nichts lösen können. Ich wollte nur mal wissen, ob es vielleicht bekannt ist, daß Open-Meteo nicht so zuverlässig ist...
Intervall is default (also 70), btw.
Danke für's Nachschauen :)
Ich seh' gerade, daß ein `ping -6 ensemble-api.open-meteo.com` zuverlässig fehlschlägt. `ping -4` funktioniert scheinbar immer :/
Ich habe gesehen, daß es in global useInet6 gibt und das auf 0 gesetzt :'(
Mal sehen, ob das hilft.
Update: tut's nicht.
Hallo zusammen,
wäre es möglich in de Flow Grafik auch eine vertikale Verschiebung zu ermöglichen?
Danke und Grüße,
Denis
P.S: Super Modul. Besten Dank dafür!!
Siehe Hilfetext:
h2consumerdist
Erweiterung des vertikalen Abstandes zwischen dem Haus und den Verbraucher-Icons.
Wert: 0 ... 999, default: 0
Mehr fällt mir grad auch nicht ein O:-)
Gruß
300P
@300P: danke schon mal für die Antwort.
Ich meine aber eher so was, nur halt vertikal:
flowGraphicControl:
shift Horizontale Verschiebung der Energieflußgrafik.
Wert: -80 ... 80, default: 0
Ich nutze das FTUI2 Widget und da ist nach oben Optimierung möglich, was den Abstand angeht :-)
Grüße,
Denis
Hallo zusammen,
bin wieder back und steige langsam wieder ein.
@The Grue,
Timeouts bekomme ich von allen API's überhaupt keine. Zur Info ... alle API-Calls werden mit einem Timeout von 30 Sekunden initiiert.
Die Sequenz der API-Abrufe haben eine eigene Zeitlogik. Man sieht den nächsten Call z.B. mit einem Mouse-Over über den API Status-Punkt.
LG
@Denis,
ich habe etwas bzgl. einer möglichen Y-Verschiebung getestet.
Im Anhang ein Beispiel mit Y=0 (Original) und Y=500.
Ist es das was dir vorschwebt?
LG,
Heiko
Zitat von: DS_Starter am 25 November 2024, 21:38:47@Denis,
ich habe etwas bzgl. einer möglichen Y-Verschiebung getestet.
Im Anhang ein Beispiel mit Y=0 (Original) und Y=500.
Ist es das was dir vorschwebt?
LG,
Heiko
Hallo Heiko,
ein Träumchen. Genau das meine ich.
Grüße,
Denis
Ok, ich erstelle eine Version mit einstellbaren Parametern zum Testen.
Super Danke Heiko!
Ich hätte noch einen Punkt: Ich lasse mir die Forcast und und Flow Grafik anzeige. Wenn ich die Anzahl der Balken im Forcast mit dem Attribut graphicHourCount runter schraube, hat das Einfluss auf die Skalierung der Flow Grafik. Siehe Bild 1 mit graphicHourCount=20 und Bild 2 mit graphicHourCount=12.
Geht das nur mir so?
Grüße,
Denis
In meinem contrib liegt die V 1.37.7 zum Test.
Das Attr flowGraphicControl hat nun folgende Schlüssel:
shiftx Horizontale Verschiebung der Energieflußgrafik.
Wert: -80 ... 80, default: 0
shifty Vertikale Verschiebung der Energieflußgrafik.
Wert: Ganzzahl, default: 0
Achtung: der Schlüsel shift wurde in Schlüssel shiftx umbenannt -> evtl. anpassen!
Nach Download der V restarten.
@Denis, ja solche Änderungen beeinflussen die Gesamtdarstellung. Auch wenn man shifty benutzt, wird man auch size verändern wollen um das Gesamtbild azupassen. Aber das macht man ja nicht ständig.
LG
Zitat von: DS_Starter am 25 November 2024, 22:38:00In meinem contrib liegt die V 1.37.7 zum Test.
Das Attr flowGraphicControl hat nun folgende Schlüssel:
shiftx Horizontale Verschiebung der Energieflußgrafik.
Wert: -80 ... 80, default: 0
shifty Vertikale Verschiebung der Energieflußgrafik.
Wert: Ganzzahl, default: 0
Achtung: der Schlüsel shift wurde in Schlüssel shiftx umbenannt -> evtl. anpassen!
Nach Download der V restarten.
@Denis, ja solche Änderungen beeinflussen die Gesamtdarstellung. Auch wenn man shifty benutzt, wird man auch size verändern wollen um das Gesamtbild azupassen. Aber das macht man ja nicht ständig.
LG
Hallo Heiko,
ich habe die neue Version mal getestet. Was mir aufgefallen ist: Attribut shifty hat nur einen Positiven Wertebereich. Man kann also nur in eine Richtung schieben? Shiftx geht ja in beide Richtungen.
Grüße,
Denis
0 = Standart (direkt unterhalb beginnen)
Je höher der Wert der eingetragen wird - umso mehr ,,Abstand" nach unten
Eine noch höhere vertikale Verschiebung der Grafik nach oben (Minuswert) geht nicht bzw. macht an dieser Stelle dann sicherlich wohl keinen Sinn.
Bei der horizontalen Verschiebung wird immer von der jeweiligen Mitte aus verschoben - daher -/+ Werte. ;)
Genau wie 300P beschrieben hat. :)
@all,
die neue V 1.37.7 ist eingecheckt:
- Attr flowGraphicControl: shiftx Horizontale Verschiebung der Energieflußgrafik.
Achtung: der Schlüsel shift wurde in Schlüssel shiftx umbenannt -> evtl. anpassen!
shifty Vertikale Verschiebung der Energieflußgrafik
- obsolete Attribute wurden entfernt: flowGraphicCss, flowGraphicSize, flowGraphicAnimate, flowGraphicConsumerDistance, flowGraphicShowConsumer, flowGraphicShowConsumerDummy, flowGraphicShowConsumerPower, flowGraphicShowConsumerRemainTime, flowGraphicShift, affect70percentRule, ctrlAutoRefresh, ctrlAutoRefreshFW
LG
@DS_Starter:
Rückecho zur neuen V1.37.7
Bei mir gibt es einen nicht erwünschten Nebeneffekt:
Der Consumer 7 wird mit dieser Version doppelt bei mir angezeigt!
Es gibt keinen (eingetragenen) Consumer 8 bei mir
Eintrag bei mir lautet:
animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
Gruß
300P
Nachsatz:
Aus Consumer 7 wird nach einem restart irgendwie consumer 8.
Der Eintrag wird aber weiterhin als Consumer 7 noch angezeigt, irgendwas hakt da.
@300P,
ich habe deine Einstellung bzgl. flowGraphicControl und die ANzahl der Consumer bei mir nachgestellt.
Läuft alles sauber und kann deinen Issue nicht nachvollziehen.
Hast du den Browsercache mal geleert?
Was zeigt denn ein "get ... valConsumerMaster" ?
mmmmh kann das Ergebnis vom "get ... ValConsumer" hier irgendwie nicht einfügen - kommt immer wieder die Meldung des Forums mit "Bitte versuche es nochmal. Sollte der Fehler wieder auftreten, informiere bitte den Administrator."
Versuche es gleich von einem anderen Rechner.
...scheinbar (komplett) zu groß:
Hier der Consumer 7 /8:
07 => alias => SW Urlaubslicht-Wohnzimmer
asynchron => 0
auto => 1
autoreading => solarforecast_auto
avgenergy => 0.01
currpowerpercent => 0
cycleDayNum => 0
cycleStarttime => 1732651456
cycleTime => 70.75
dspignorecond =>
dswitch => tuya_local_bfac44fb487476efd1vhdu
dswoffcond =>
dswoncond =>
energythreshold =>
epiecAVG => 1=0.00
epiecAVG_hours => 1
epiecHist => 1
epiecHist_1 => 1=0.01 2=0.00
epiecHist_10 =>
epiecHist_1_hours => 2
epiecHist_2 =>
epiecHist_3 =>
epiecHist_4 =>
epiecHist_5 =>
epiecHist_6 =>
epiecHist_7 =>
epiecHist_8 =>
epiecHist_9 =>
epiecHour => -1
epiecStartEtotal => 63.908
epiecStartTime => 1732651441
epieces => 1=5.00
exconfc => 0
hysteresis => 0
icon => weather_sunset@orange
interruptable => 0
isConsumptionRecommended => 1
isIntimeframe => 0
lastMinutesOn => 0
lastOnTime => 1732655716
locktime => 0:0
logoffon => off
mintime => 60
minutesOn => 0
mode => can
name => tuya_local_bfac44fb487476efd1vhdu
noshow => 0
notafter =>
notbefore =>
offcom =>
offreg => off
oncom =>
onoff => off
onreg => on
physoffon => off
planSupplement =>
planstate => noSchedule
power => 5
powerthreshold => 3
remainTime => 0
retotal => energy
rigncond =>
rpcurr => cur_power
rswoffcond =>
rswoncond =>
rswstate => state
runtimeAvgDay => 72.00
spignorecondregex =>
startTime => 1732654800
state => off
swoffcondregex =>
swoncondregex =>
type => noSchedule
uetotal => Wh
upcurr => W
08 => alias => SW Urlaubslicht-Wohnzimmer
asynchron => 0
auto => 1
autoreading => solarforecast_auto
avgenergy => 0.14
currpowerpercent => 0
cycleDayNum => 0
cycleStarttime => 1732651456
cycleTime => 70.75
dspignorecond =>
dswitch => tuya_local_bfac44fb487476efd1vhdu
dswoffcond =>
dswoncond =>
energythreshold =>
epiecAVG => 1=0.00
epiecAVG_hours => 1
epiecHist => 3
epiecHist_1 => 1=0.00
epiecHist_10 => 1=0.00
epiecHist_10_hours => 0
epiecHist_1_hours => 0
epiecHist_2 => 1=0.00
epiecHist_2_hours => 1
epiecHist_3 => 1=0.01 2=0.00
epiecHist_3_hours => 2
epiecHist_4 => 1=0.03 2=0.00
epiecHist_4_hours => 2
epiecHist_5 => 1=0.00
epiecHist_5_hours => 0
epiecHist_6 => 1=0.00
epiecHist_6_hours => 0
epiecHist_7 => 1=0.00
epiecHist_7_hours => 0
epiecHist_8 => 1=0.00
epiecHist_8_hours => 0
epiecHist_9 => 1=0.00
epiecHist_9_hours => 0
epiecHour => -1
epiecStartEtotal => 63.908
epiecStartTime => 1732651471
epieces => 1=5.00
exconfc => 0
hysteresis => 0
icon => weather_sunset@orange
interruptable => 0
isConsumptionRecommended => 1
isIntimeframe => 0
lastMinutesOn => 0
lastOnTime => 1732655716
locktime => 0:0
logoffon => off
mintime => 60
minutesOn => 0
mode => can
name => tuya_local_bfac44fb487476efd1vhdu
noshow => 0
notafter =>
notbefore =>
offcom =>
offreg => off
oncom =>
onoff => off
onreg => on
physoffon => off
planSupplement =>
planstate => noSchedule
power => 5
powerthreshold => 3
remainTime => 0
retotal => energy
rigncond =>
rpcurr => cur_power
rswoffcond =>
rswoncond =>
rswstate => state
runtimeAvgDay => 128.58
spignorecondregex =>
startTime => 1732654800
state => off
swoffcondregex =>
swoncondregex =>
type => noSchedule
uetotal => Wh
upcurr => W
und Auszug (RAW) des Device
attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto
attr Forecast consumerAdviceIcon light_light_dim_100@gold
at
EDIT 1:
Ich lösche jetzt einmal den Consumer 7 (8 ist als Attribut ja nicht vorhanden).
....
der Consumer8 bleibt auch nach einem FHEM-Neustart bestehen ?!?
EDIT 2:
Lege (Kopie von Consumer 7 ) den Consumer 8 einfach jetzt mal an.
Jetzt ist nur noch ein Consumer (8) vorhanden... ? ? ?
EDIT 3:
Grad fäll mir ein das ich vor einiger Zeit den Consumer 7 gelöscht hatte.
Irgendwann danach habe ich den Consumer 8 in Consumer 7 kopiert und danach den Consumer 8 gelöscht.(diverse reboot / Neustart nach dem löschen)
Vermutlich bleibt irgendwo (Moduldaten/FHEM) davon was hängen und hat diese Daten jetzt im Hintergrund hervorgekramt.
Moin,
deswegen wird der Consumer angezeigt. Die Infos werden bei einem Restart aus ../FHEM/FhemUtils/PVCsm_SolarForecast_<name> wiederhergestellt.
In diesem File ist der Consumer noch vorhanden und wurde beim Löschen des Attr nicht rausgelöscht bzw. vllt. das File mal wiederhergestellt aus einem Backup?
Ist jetzt schwer zu sagen, evtl. siehst du am Timestamp des Files einen Hinweis.
Zur Lösung lege das Attr Consumer08 mit beliebigen Inhalt einfach nochmal an und lösche es dann gleich wieder. In dem besagten File sollte der Consumer dann auch entfernt sein.
Jepp - das war die Lösung
ZitatVermutlich bleibt irgendwo (Moduldaten/FHEM) davon was hängen und hat diese Daten jetzt im Hintergrund hervorgekramt.
Die oben angebene Datei ist der heilige Gral für die Consumer. ;) Sie wird auch regelmäßig oder beim shutdown bzw. bei den Änderungen der Consumer-Attr geschrieben.
Möglicherweise ist da mal was schief gegangen.
Ich stelle ja schon zwei Cache-Files zum Recover in "set ... operatingMemory recover-<Datei>" zur Verfügung.
Damit kann man ältere Versionen dieser Cache-Dateien zurückholen. Vllt. macht es Sinn auch die Consumerdatei mit anzubieten. Muss ich mal überlegen. Da sind auch Bewegungsdaten drin wie Einplanungen etc. Könnte auch kontraproduktiv sein ältere Stände einzuspielen.
Wie dem auch sein, muß ich mir erst durch den Kopf gehen lassen.
@all,
weiter vorn gab es ein paar Diskussionen zum Thema (negativen) Verbrauch und der Berechnung des Verbrauchs.
Ich habe einen Beitrag (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?) im Wiki zu diesem Thema eingefügt.
Begleitend dazu ist eine neue Version 1.37.8 eingecheckt (und auch im contrib abgelegt) die bei gesetzten Attr ctrlDebug=collectData eine bessere Nachvollziehbarkeit bzgl. "Consumption" bietet.
LG
Hallo zusammen,
wie ihr sicherlich bemerkt habt, wurden die letzten Tage bereits einige Updates des Moduls ausgeliefert.
Nun ist die V 1.38.0 eingecheckt und auch im contrib verfügbar.
Wenn ihr die contrib Version vorab nutzen möchtet unbedingt FHEM restarten nach dem Download.
Mit dieser Version ist der Request von Fichtennadel aus #1310 umgesetzt.
Es ist nun möglich die Datenquellen für Strahlungsdaten und Wetterdaten weitestgehend unabhängig voneinder einzusetzen, auch wenn beides API-Dienste sind.
Ein Einschränking gibt es wenn beide Dienste OpenMeteo Services sind. Dann wird auf einen Dienst harmonisiert da es hinsichtlich der täglichen Abrufe Beschränkungen gibt die es zu beachten gilt, insbesondere bei Ensemble-API's in Verbindung mit mehreren vorhandenen Strings.
Zur Umsetzung wurden die modulinternen Steuerungsstrukturen umgebaut und entkoppelt.
Sichtbar für den User sind insbesondere folgende Punkte:
- Getter solApiData in radiationApiData umbenannt!
- neue Getter statusApiData, weatherApiData
- zusätzlich zum Internal MODEL gibt es nun auch ein Internal WEATHERMODEL
Weiterhin:
- bei der Umbennung des SF-Devices werden auch die Sicherungsdateien im Verz. ../FHEM/FhemUtils entsprechend
umbenannt/angepasst. Der User muß sich darum nicht kümmern.
@Fichtennadel, ich hatte dir schon eine PM bzgl. eines evtl. separaten OpenMeteo Devices geschrieben.
Bei meinen Umbauten ist mir noch einmal bewusst geworden, dass ein separates Devices nicht so ohne Weiteres realisierbar ist wenn es auch die PV Prognosedaten (GTI) bereitstellen soll.
Grund ist, dass man OpenMeteo die Anlagendaten wie Azimuth und Neigungswinkel mitgeben muss und dies auch für jeden einzelnen vorhandenen String separat an die OpenMeteo-API senden muß. Die Daten müssen dann entsprechend der Anlagenarchitektur konsolidiert werden. So wird es im SF-Modul intern ausgeführt.
Bei einem separaten OpenMeteo-Modul hat man die benötigten Input-Parameter nicht verfügbar. Man kann sie natürlich aus dem SF-Device holen, aber dann stellt sich die Frage nach dem Sinn eines separaten Moduls.
Was aber ganz autark gehen würde, ist die Bereitstellung von Wetterdaten. Sie wären unabhängig.
LG,
Heiko
Hallo Heiko,
bei mir ist irgendwann ein roofIdentPair verloren gegangen.
Ich hatte gestern auf 1.37.8 aktualisiert.
Heute Morgen war dann die API rot (Oben Rechts).
Der Check hat dann gemeldet, dass für eine Fläche die API Daten fehlen.
Leider kann ich nicht sagen, ob der Fehler schon vorher da war.
Ich habe beide Flächen eingetragen und jetzt läuft es wieder.
Ich habe einen API-Key und zwei rtIDs.
Viele Grüße,
Guido.
Hi Guido,
möglicherweise hast du längere Zeit kein Update vorgenommen.
Bei den aktuell dynamischen Weiterentwicklungen achte ich darauf dass "unterwegs" möglichst nichts verloren geht.
Es ist für die User wahrscheinlich nicht so einfach jedes Update mitzumachen. Deswegen bleibt durch die Weiterentwicklung verursachtes internes automatisches Datenmanagement über längere Zeit erhalten. Irgendwann (so ca. 1-2 Monate) entferne ich den Code jedoch. Wer also längere Zeit nicht upgedated hat, könnte in ein solches "Problem" laufen. Wobei in den meisten Fällen, wie jetzt bei dir, ein einfaches Korrigieren der fehlenden Werte reicht es zu lösen.
Manchmal kann ich jedoch trotz aller Tests auch einen Fehler machen, das ist ganz klar.
Deswegen sind solche Hinweise sehr hilfreich, vielen Dank dafür!
LG,
Heiko
Guten Abend,
morgen früh gibt es wieder ein Update des Moduls und auch der Bibliotheken ErrCodes.pm, SMUtils.pm
Die Inverter (setupInverterDevXX) und das Meterdevice (setupMeterDev) können jetzt mit dem optionalen Schlüssel asynchron=1 versehen werden.
Ist dieser Parameter gesetzt, wird bei Empfang eines Events eines Inverters oder des Meters die Datensammlung des Moduls unabhängig/zusätzlich der Einstellung von Attr ctrlInterval gestartet.
Dadurch ist es möglich, die Daten im Modul mit den Readings/Daten der Inverter und des Meters zeitgleich synchron zu halten.
Sollte es notwendig oder gewünscht werden, kann ich diese Funktionalität auch noch auf die Geräte in setupOtherProducerXX, setupBatteryDev erweitern.
LG,
Heiko
Hi Heiko,
das klingt sehr interessant.
Werde ich mir anschauen.
Danke!
Stefan
Zitat von: DS_Starter am 05 Dezember 2024, 21:40:58bei Empfang eines Events eines Inverters oder des Meters die Datensammlung des Moduls unabhängig/zusätzlich der Einstellung von Attr ctrlInterval gestartet
Was hat das für einen Einfluss auf die Rechenlast?
(Sowohl Inverter als auch Meter laufen bei mir im 5-Sekunden-Takt...)
Gibt es eine Möglichkeit den `mode` eines Consumers per Reading zu steuern?
Anwendungsfall: Der Akku meines Rollers soll geladen werden. Erstmal ist es nicht dringend, also wäre der Mode "can". Wenn ich aber erfahre, daß ich morgen unbedingt weg muss, würde ich gerne auf "must" umschalten.
Weiter so und großes Dankeschön :)
ZitatWas hat das für einen Einfluss auf die Rechenlast?
(Sowohl Inverter als auch Meter laufen bei mir im 5-Sekunden-Takt...)
Die Frage ist pauschal nicht zu beantworten. Das hängt auch davon ab wie leistungsfähig dein Server ist.
Ganz allgemein würde ich mit etwas mehr Last rechnen, konnte bei mir aber keinen meßbaren Effekt (Sysmon) feststellen.
Dieses Feature ist als Option zu verstehen für die User denen es hilfreich ist. Einfach ausprobieren.
Falls die Belastung dadurch zu hoch werden sollte -> nicht nutzen.
ZitatGibt es eine Möglichkeit den `mode` eines Consumers per Reading zu steuern?
Aktuell nicht, kann ich aber ähnlich dem Verfahren im Schlüssel "noshow=[Device:]Reading" implementieren.
@The Grue, @all,
in meinem contrib liegt die V 1.39.2
Neben ein paar Code Änderungen/Verbesserungen und der Möglichkeit setupBatteryDev als asynchron kennzeichnen zu können, kann man den Consumer-Key 'mode' nun auch als Device:Reading Kombination angeben.
Die Hilfe gibt eine entsprechende Erläuterung.
Denkt bitte daran nach einer dynamischen Mode-Änderung auch eine Neuplanung des Consumers (zb. mit set ... consumerNewPlanning XX) vorzunehmen. Erst dann bekommt das interne Planungstool die Änderung des angegebenen Readings mit (Sonst erst bei der nächsten regulären Einplanung). Das kann man mit einem Notify auf die angegebene Device:Reading Kombination automatisieren.
Nach dem Download des Moduls Restart nicht vergessen!
LG,
Heiko
Neue Version ist nach weiteren Tests eingecheckt und morgen früh im Regelupdate.
LG
Eine Kleinigkeit ist mir heute aufgefallen.
Der Key Mode wurde im consumerxx Reading 1:1 abgebildet, also statt "mode=must (can)" stand dort die Angabe aus dem Key mode=<Device>:<Reading>.
Bisher passte es auch, aber mit dem neuen Feature ist das unschön.
Das habe ich angepasst, sodass der aufgelöste Mode im Reading abgebildet wird.
Darüber hinaus wird der Mode auch in consumer Legend beim Mouse-Over über dem Icon mit ausgegeben.
Kommt heute Abend ins Repo.
LG
Die neue V ist eingecheckt.
Im Wiki habe ich einen Absatz zur Batterieimplementierung (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Batterieintegration_und_-steuerung) begonnen.
LG
Ja moin zusammen, winterliche Grüße. Habe grade zufällig gesehen, dass meine PV-Vorhersagebalken leer (bzw. alle = 0) sind.
Roter Punkt oben rechts bei Solcast, mouseover: "API-Abfrage fehlgeschlagen"
Habe mich direkt bei solcast mit meinen alten Logindaten eingeloggt, dort scheint alles normal.
Folglich habe ich die letzten Seiten hier im Thread durchgelesen, ob ich Änderungen informativ verpasst habe.... ohne Befund.
Das tolle Feature zum Configuration Check - siehe Screenshot - :
Bildschirmfoto 2024-12-10 um 08.05.32.png
okay, direkt gecheckt, wenngleich ewig nichts dran geändert, siehe Screenshot 2:
Bildschirmfoto 2024-12-10 um 08.07.53.png
Eigentlich alles da, oder nicht?
Moin,
du müsstest die Roof Ident Pair Keys p1, p4, p3 nochmal setzen mit:
set ... roofIdentPair ...
Steht ja auch im Check und mit der Handlungsanweisung ;) .
Wir hatten das schon vor kurzem mal. Da ist mir möglicherweise bei einem Update eine Umstellungsroutine mißglückt.
Du siehst die bereits definierten Paare mit:
get ... statusApiData
einwandfrei, jetzt habe ich wieder Daten, herzlichen Dank
Habe den Fehler in der internen Update-Routine auch gefunden. Fix checke ich heute Abend ein.
(Hat nur Bedeutung für User die noch nicht upgedated haben).
Zitat von: DS_Starter am 09 Dezember 2024, 21:35:16Die neue V ist eingecheckt.
Im Wiki habe ich einen Absatz zur Batterieimplementierung (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Batterieintegration_und_-steuerung) begonnen.
Danke für die wirklich gut gelungene Doku! Nur einige wenige Begriffe sind fachlich noch nicht ganz richtig. So sollten z.B. die Readings im Abschnitt "Wie eine Batterie eingebunden wird" wie folgt umbenannt werden:
"totale Batterieladung" -> "Bis dato vorliegende Lade-Enenergiemenge"
"totale Batterieentladung" -> "Bis dato vorliegende Entalde-Enenergiemenge"
Vor dem Hintergrund, dass es Systeme gibt, die mehrere voneinander unabhängige Batterie-Verbindungen besitzen (bei meinem GW25K-ET sind es z.B. 2), wäre es super, wenn auch solche Systeme vom Modul abgebildet werden können. Denn nur so können so wertvolle Features, wie z.B. das prognosebasierte SOC-Management, genutzt werden. Hierzu müsste im Grunde ,,nur" ermöglicht werden, mehrere BAT-Devices anlegen zu können. Das geht in der aktuellen Version leider noch nicht, oder?
Hallo Parallix,
danke für die Hinweise. Habe ich im Wiki eingepflegt.
ZitatVor dem Hintergrund, dass es Systeme gibt, die mehrere voneinander unabhängige Batterie-Verbindungen besitzen (bei meinem GW25K-ET sind es z.B. 2), wäre es super, wenn auch solche Systeme vom Modul abgebildet werden können. Denn nur so können so wertvolle Features, wie z.B. das prognosebasierte SOC-Management, genutzt werden. Hierzu müsste im Grunde ,,nur" ermöglicht werden, mehrere BAT-Devices anlegen zu können. Das geht in der aktuellen Version leider noch nicht, oder?
Man kann zwar momentan mit einem zusammengefassten Dummy Device arbeiten um die Batterie(n) einzubinden.
Das ist aber eine "Krücke" weil dann die spezifischen Kalkulationen das SOC-Management oder die "PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung" nicht für die vorhandenen (eigentlich getrennten) Batteriestacks funktionieren.
Das kann ich mit vorsehen. Ist aber eine größere Aktion, denn die Attribute und Readings sowie internen Kalk-Routinen müssen auf XX Batteriedevices umgebaut werden. Die grafische Darstellung ist dann ebenfalls aufzubohren.
Machbar ist es ähnlich wie bei den Invertern oder Producern.
LG,
Heiko
Zitat von: DS_Starter am 10 Dezember 2024, 10:46:16...
ZitatVor dem Hintergrund, dass es Systeme gibt, die mehrere voneinander unabhängige Batterie-Verbindungen besitzen (bei meinem GW25K-ET sind es z.B. 2), wäre es super, wenn auch solche Systeme vom Modul abgebildet werden können. Denn nur so können so wertvolle Features, wie z.B. das prognosebasierte SOC-Management, genutzt werden. Hierzu müsste im Grunde ,,nur" ermöglicht werden, mehrere BAT-Devices anlegen zu können. Das geht in der aktuellen Version leider noch nicht, oder?
Man kann zwar momentan mit einem zusammengefassten Dummy Device arbeiten um die Batterie(n) einzubinden.
Das ist aber eine "Krücke" weil dann die spezifischen Kalkulationen das SOC-Management oder die "PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung" nicht für die vorhandenen (eigentlich getrennten) Batteriestacks funktionieren.
Das kann ich mit vorsehen. Ist aber eine größere Aktion, denn die Attribute und Readings sowie internen Kalk-Routinen müssen auf XX Batteriedevices umgebaut werden. Die grafische Darstellung ist dann ebenfalls aufzubohren.
Machbar ist es ähnlich wie bei den Invertern oder Producern.
Danke für die gute Aussicht!
Zitat von: DS_Starter am 08 Dezember 2024, 13:54:05[...] kann man den Consumer-Key 'mode' nun auch als Device:Reading Kombination angeben. [...]
Großartig, danke :)
Hallo Heiko,
mein FHEM Update heute morgen hat mir wohl meine Solar Prognose verbogen - was muss ich tun?
Hi,
mach einfach was in dem Check angegeben ist (wird ja als Handlungshilfe extra ausgegeben ;) ):
set Prognose setupStringDeclination
wahrscheinlich kommt danach noch die Aufforderung die Ausrichtung anzugeben:
set Prognose setupStringAzimuth
Der Neigungswinkel und die Ausrichtung der Strings wird seit Version 1.38.0 geprüft weil man OpenMeteo als unabhängigen Wetterdienst einrichten kann. Dieser Dienst braucht diese Angaben.
Wenn du aktuell keine Zeit/Lust hast, kannst du erstmal ungefähre Werte eintragen und bei Gelegenheit präzisieren.
SolCast + DWD braucht diese Werte nicht zwingend.
LG,
Heiko
The specified inclination angle has an incorrect format
kommt nach
set Prognose setupStringDeclination
The provided module direction has wrong format
kommt nach
set Prognose setupStringAzimuth
Welchen Wert hast du denn bei "set Prognose setupStringDeclination" mitgegeben?
Du musst natürlich bei den Befehlen Werte mitgeben wie in der Online-Hilfe dazu ausgeführt.
Wäre es möglich die optionalen Verbraucher und ev. auch die mit Unterbrechungsmöglichkeit so umzustellen, dass anstelle des momentanen Überschusses ein gemittelter Wert für Start/Abbruch/Unterbrechung verwendet wird? (Den Mittelwert könnte man dann im MeterDev selbst bilden, ich habe z.B. 2- und 5-min Mittelwerte, die ich für das Beenden der WW-Erzeugung abhängig von der Speichertemperatur oder der Kühlung verwende.)
Wenn beispielsweise ein ständig taktender Verbraucher läuft (z.B. Backrohr), führt die aktuelle Implementierung zu einem eher zufälligen Ein- und Ausschalten von optionalen Verbrauchern. Ähnliches passiert durch kurze Verbrauchsspitzen.
(Mittels swoncond könnte das auch umgangen werden, aber nur bei solchen Verbrauchern, wo die swoncond ansonsten nicht benötigt wird.)
ZitatWäre es möglich die optionalen Verbraucher und ev. auch die mit Unterbrechungsmöglichkeit so umzustellen, dass anstelle des momentanen Überschusses ein gemittelter Wert für Start/Abbruch/Unterbrechung verwendet wird?
Ich verstehe das Problem. Für andere Zwecke führe ich im Modul (valCurrent -> genslidereg bzw. h4fcslidereg) Register mit die jeweils den Wert der letzten 3 Messungen PV-Erzeugung bzw. 4h PV Forecast für eine Durchschnittsberechnung beinhalten.
Ein solches Register könnte ich auch für den PV-Überschuß führen. Dann könnte die Schaltbedingung für Start/Abbruch/Unterbrechung etc. abgeleitet werden, wenn der Durchschnitt der letzten 3 Ermittlungen über oder unter einem Schwellenwert liegt.
Einziges Manko was ich momentan sehe ist, dass die Abstände der Ermittlungen abhängig sind vom eingestellten ctrlInterval, wobei der Meter/Inverter in der aktuellen Modulversion auch asynchron eingestellt werden kann und dadurch der Zyklus, sowie die Berechnung, bei jedem Meter/Inverter-Event durchlaufen wird. Die Anzahl der Messungen für den Durchschnitt kann ich frei festlegen, tendiere so zwischen 3 und 6. Sie sind dann aber fest und nicht für jeden Consumer individuell festlegbar, wobei mit etwas weiteren Aufwand auch das umsetzbar wäre. Ich würde aber erstmal nur den Standard nehmen.
Die Unterscheidung, ob der Verbraucher über einen Durchschnittswert oder wie bisher durch direkte Messung geschaltet werden soll, könnte der User per Verbraucher-type steuern. Dazu müsste ich nur einen weiteren Typ, z.B. Pacemaker (Schrittmacher), einführen.
Das würde doch deinen Use Case abbilden wenn dich richtig verstanden habe?
Zitat von: DS_Starter am 16 Dezember 2024, 20:07:26Durchschnitt der letzten 3 Ermittlungen
Zitat von: DS_Starter am 16 Dezember 2024, 20:07:26Die Anzahl der Messungen für den Durchschnitt kann ich frei festlegen, tendiere so zwischen 3 und 6.
Zitat von: DS_Starter am 16 Dezember 2024, 20:07:26fest und nicht für jeden Consumer individuell festlegbar
Damit hätte ich nix gewonnen, wenn ich bei "asynchron=1" für Inverter- und MeterDev bleibe. Das Abfrageintervall beträgt 5 Sekunden. (Events treten zwar wg. event-on-change-reading-Einstellungen nur bei dynamischen Änderungen auf, aber genau das wäre in dem betrachteten Anwendungsfall auch gegeben.)
Damit würde beispielsweise das Öffnen/Schließen des Garagentors den ggf. laufenden Luftentfeuchter bereits unterbrechen.
Zitat von: DS_Starter am 16 Dezember 2024, 20:07:26Das würde doch deinen Use Case abbilden wenn dich richtig verstanden habe?
Vielleicht stelle ich es mir zu einfach vor, aber könnte nicht beispielsweise im MeterDev ein zusätzlicher Parameter eingeführt werden, mit dem ein (vom User beliebig konfigurierter) Durchschnittswert eingelesen wird, beispielsweise "gconavrg=[reading]" (z.B. gconavrg=activepoweroffset_5min:W) und "gfeedavrg=-gconavrg".
Im ConsumerDev kann dann mittels zusätzlichem Schalter ausgewählt werden, ob auf den aktuellen oder Durchschnittswert reagiert wird, beispielsweise "swtavrg" mit "0" für "aktuelle Logik" und "1" für Durchschnittswert.
Damit könnte alles wie bisher bleiben, nur bei den consumer-abhängigen Berechnungen wird auf einen anderen Verbrauchswert geschaut.
ZitatDamit hätte ich nix gewonnen, wenn ich bei "asynchron=1" für Inverter- und MeterDev bleibe. Das Abfrageintervall beträgt 5 Sekunden. (Events treten zwar wg. event-on-change-reading-Einstellungen nur bei dynamischen Änderungen auf, aber genau das wäre in dem betrachteten Anwendungsfall auch gegeben.)
Für mein/unser Verständnis.
Wenn das MeterDev alle 5 Sec Werte liefert und der Durchschnitt des Überschusses über z.B. 10 Messungen gemittelt werden soll, dann würde der Grenzwert mindestens 50 Sec lang unter/überschritten sein müssen um eine Reaktion hervorzurufen. Ist das nicht ausreichend?
Wenn nötig könnte ich wie beschrieben mit entsprechenden Aufwand die Avg-Möglichkeit für jeden Consumer einzeln einstellbar gestalten und über einen Schlüssel im Consumerdev festlegen lassen, wieviele Messwerte eingehen sollen. Zum Beispiel avg=1 (bzw. nicht gesetzt) für den aktuellen Wert (wie jetzt) oder avg=2..10 für X Messwerte. 10 wäre max. oder ein anderer zentral festgelegter Wert.
Es geht dabei übrigens nicht nur um die Werte des MeterDev (Einspeisung/Verbrauch) sondern um den Überschuß, es gehen also auch noch Werte der PV-Erzeugung, anderer Erzeuger und der zuvor berechnete aktuelle Verbrauch unter Berücksichtigung von Batterie-In/Out ein.
All das zusammen UND zusätzlich der Auswertung im Consumer gesetzter Parameter bezüglich der evtl. Ignorierung des Überschusses erfolgt die Generierung des valConsumerMaster->isConsumptionRecommended.
Dieser Wert ist für die Entscheidung der Consumeraktivitäten zuständig, ganz so einfach ist es also nicht.
Zitat von: DS_Starter am 17 Dezember 2024, 10:41:2810 Messungen
Ja das geht dann schon eher in die Richtung... mit den ursprünglich genannten 3-6 wär's definitiv zu wenig gewesen.
Trotzdem würd' ein kurzer hoher Peak zum Ausschalten führen, und zwar zu einem Zeitpunkt, wo der Peak schon wieder vorbei ist. Es gibt wohl keine allgemein gültige Lösung für das Problem, drum würd' mir persönlich ein "individueller Mittelwert" besser gefallen als etwas, das im Modul vorgegeben ist.
Die Anzahl der Messungen war erstmal eine Arbeitsgröße. Ich kann den möglichen Bereich auch bis 20 ziehen.
Irgendwo muß halt der Max sein.
ZitatEs gibt wohl keine allgemein gültige Lösung für das Problem, drum würd' mir persönlich ein "individueller Mittelwert" besser gefallen
Allerdings ermittelst du nicht den Überschuß, sondern nur den Meter In/Out.
Wie dem auch sei, du könntest neben dem Key swoncond/swoffcond (wenn die schon benutzt sind) auch den Key auto verwenden und bei Vorliegen einer Verbrauchsspitze in deinem Meterdev oder dem Reading Current_Consumption das automatische Schalten verbieten respektive wieder freigeben.
Auch eine Möglichkeit.
Zitat von: TheTrumpeter am 17 Dezember 2024, 12:15:18Es gibt wohl keine allgemein gültige Lösung für das Problem, drum würd' mir persönlich ein "individueller Mittelwert" besser gefallen als etwas, das im Modul vorgegeben ist.
Ich habe bei der Wärmepumpe ein ähnliches Problem. Das mache ich auch individuell, weil das Modul nicht alle Eventualitäten abdecken kann.
Aktuell schalte ich die nicht von Solarforecast aus sondern berechne mir den Überschuss und Schaltpunkte selbst.
Dafür summiere ich z.B. "secondary" consumers (unwichtige Verbraucher) auf und errechne einen gleitenden/gewichteten Mittelwert über 15 Werte.
Das Buget für die Wäremepumpe errechnet sich dann aus
"Momentanleistung PV" - ("Momentanleistung Verbrauch Haus" - ("Momentanleistung Wärmepumpe" + "Momentanleistung Secondary Consumers"))
Wenn das Budget einen gewissen Grenzwert (aktuell 500 W - auch gemittelt) überschreitet (und ein paar andere Bedingugnen zutreffen), wird der PV-Start der Wärmepumpe aktiviert.
Die Secondary Consumers haben somit keinen Einfluss auf das Budget der Wärmepumpe. Im Gegenteil, teilweise sind sie als "can" in Solarforecast bzw nutze ich das Reading pvStartRecommended um die dann noch wegzuschalten.
Durch die Mittelwerte (und wait timer) wird auch ein nicht gemessenes Gerät wie ein Wasserkocher den PV-Start nicht deaktivieren (zumal da noch mehr Bedingungen dran hängen).
Wird halt schnell etwas komplexer...
ZitatWenn das MeterDev alle 5 Sec Werte liefert und der Durchschnitt des Überschusses über z.B. 10 Messungen gemittelt werden soll, dann würde der Grenzwert mindestens 50 Sec lang unter/überschritten sein müssen um eine Reaktion hervorzurufen. Ist das nicht ausreichend?
Das ist so aber nicht ganz richtig. Wir nehmen an das wir 10 als trigger nehmen. Wenn 9mal eine 9 drin ist und dann eine 19 kommt. Dann hätte ich in diesen Moment 10 als Durchschnitt.
Und im nächsten Zug kommt eine 8 dann wäre ich nach 5sec. auf <10. Und nicht nach 50. Ganz so einfach ist es ja nun doch nicht. Das kann aber bei jedem Durschnitt passieren. Es sei denn man aktualisiert denn Wert nur nach z.b. 50sec. Dann wäre es aber nicht fliessend.
Dann würde es aber auch nicht mehr passen bei erste Wert gebildet aus: 9,9,9,9,9,9,9,9,9,18 = <10, nachfolgende Werte: 18,17,16,4,5,3,2,1,8,7 = <10. Hätte man das jetzt zeitlich um 3 messwerte später gestartet wäre der Triggerpunkt erreicht gewesen. 9,9,9,9,9,9,18,18,17,16 = > 10.
Einen selbst gebauten Wert bzw. auswähbaren Wert halte ich da auch wirklich für Sinnvoller. Vieleicht will man einen richtigen Fliesswert/gleitenden Mittelwert bilden.
@kask, da hast du natürlich Recht. :)
ZitatEinen selbst gebauten Wert bzw. auswähbaren Wert halte ich da auch wirklich für Sinnvoller. Vieleicht will man einen richtigen Fliesswert/gleitenden Mittelwert bilden.
Ja, kann man machen und in den Schlüsseln swoncond, swoffcond oder auto anwenden.
Wären aus deiner/eurer Sicht noch weitere Möglichkeiten nötig bzw. sinnvoll?
@TheTrumpeter,
ich habe über diese These nochmal nachgedacht:
ZitatTrotzdem würd' ein kurzer hoher Peak zum Ausschalten führen, und zwar zu einem Zeitpunkt, wo der Peak schon wieder vorbei ist.
Ich würde das nicht pauschal unterschreiben. Als Beispiel gäbe es 10 Ermittlungen des Überschusses. 9 mal wäre der Überschuß 1500 W. Einmal kommt ein gemessener Peak von 4000W Verbrauch vor was zu einem ermittelten Überschuß von 0 führen würde.
Bei einer Durchschnittsermittlung des Überschusses im Schieberegister würde es sich so darstellen:
( 1500 + 1500 + 1500 + 1500 + 1500 + 0 + 1500 + 1500 + 1500 + 1500 ) = 13500 / 10 = 1350 W
Beim Peak ist der Überschuß = 0.
Hat der zu schaltende Verbraucher eine nominale Leistungsaufnahme von < 1350 W wäre die Überschußbedingung weiterhin erfüllt und würde keine Ausschaltaktion bedingen. Auch ein Peak von z.B. 10000W Verbrauch würde in dem Beispiel auch nur ein Überschuß 0 ergeben.
Das nur zur Erläuterung.
Noch etwas weiter gedacht ...
Die Consumer könnten einen optionalen Key zur Bestimmung des PV-Überschusses mit folgenden Optionen bekommen:
surplus=1..20
surplus=<Device>:<Reading>
surplus=1..20 -> die interne PV-Überschußrechnung wird verwendet, 1 - Verwendung aktuell gemessener Überschuß, 2..20 - der Durchschnitt der letzten 2 .. 20 Ermittlungen wird verwendet
surplus=<Device>:<Reading> -> die angegebene Device/Reading Kombi stellt den PV-Überschuß zur Verfügung (kann eine User-Berechnung des PVÜ enthalten)
Damit hätte der User alle Freiheiten. Er müsste natürlich an dieser Stelle einen Wert des PV-Überschusses zur Verfügung stellen. Die relevanten Aktivitäten der Consumer werden vom PV-Überschuß und angrenzenden Bedingungen abgeleitet.
Zitat von: DS_Starter am 17 Dezember 2024, 21:41:08surplus=<Device>:<Reading> -> die angegebene Device/Reading Kombi stellt den PV-Überschuß zur Verfügung (kann eine User-Berechnung des PVÜ enthalten)
Ja das geht im Prinzip genau in die Richtung, die mir vorschwebt. Wie muss das Reading aussehen? Kann da eine vorzeichenbehaftete Größe verwendet werden? ("activepoweroffset" stellen meines Wissens nach alle in Österreich gebräuchlichen SmartMeter direkt zur Verfügung, der Wert ist negativ bei Einspeisung und positiv bei Netzbezug.) Falls der Wert immer >= 0 sein muss, kann ich den Mittelwert einfach per Userreading noch entsprechend formatieren.
Zitat von: tobi01001 am 17 Dezember 2024, 16:23:33Aktuell schalte ich die nicht von Solarforecast aus sondern berechne mir den Überschuss und Schaltpunkte selbst.
Das mache ich für die WW-Bereitung und Kühlung ähnlich. Allerdings verwende ich nur den Mittelwert des Netzbezugs als Schaltgröße. WW wird ab einer bestimmten Speichertemperatur abgebrochen, sobald der gemittelte Netzbezug der letzten 5 Minuten einen bestimmten Wert überschreitet. Bei der Kühlfunktion mache ich es ähnlich, wobei da auch die erneute Freigabe abhängig vom gemittelten Netzbezug (bzw. Einspeisung) erteilt wird.
Guten Morgen,
ZitatWie muss das Reading aussehen? Kann da eine vorzeichenbehaftete Größe verwendet werden?
Das Reading muß den (realen, Mittelwert oder anders geglätteten) PV-Überschuß darstellen. Alle numerischen Werte >0 würde ich als Überschuß interpretieren, alles <=0 als kein Überschuß bzw. Überschuß=0.
Insofern kann das Reading auch negative Werte enthalten, der PVÜ wäre in diesen Fällen immer 0.
Dein Meter stellt ja nur In/Out zur Verfügung. Dabei kann die Einspeisung mit einem aktuellen Überschuß unter Umständen gleichgesetzt werden. Hast du noch eine Batterie die geladen wird, dann "sieht" der Meter diesen Anteil nicht denn der Überschuß geht ja als Ladeenergie in die Batterie.
Muß man also konkret schauen wie die Dinge bei dir liegen.
Aber da du ohnehin Mittelwerte berechnen willst, kannst du das Userreading wie dann in der Hilfe vorgegeben erstellen.
Zitat von: DS_Starter am 17 Dezember 2024, 20:20:04@kask, da hast du natürlich Recht. :)
ZitatEinen selbst gebauten Wert bzw. auswähbaren Wert halte ich da auch wirklich für Sinnvoller. Vieleicht will man einen richtigen Fliesswert/gleitenden Mittelwert bilden.
Ja, kann man machen und in den Schlüsseln swoncond, swoffcond oder auto anwenden.
Wären aus deiner/eurer Sicht noch weitere Möglichkeiten nötig bzw. sinnvoll?
Meinerseits bin ich auch der Meinung, dass Mittelwerte (besser wäre aber wahrscheinlich ein Median) via User-Readings einfließen sollten, da das Modul andernfalls immer komplexer und damit auch immer schwerer zu warten wird.
Andere Dinge hingegen, wie z.B. die Integration von mehr als einem Speicher, lassen sich nicht extern erledigen und sollten sinnvollerweise in das Modul einfließen.
Der von mir in #1390 skizzierte Ansatz würde dem User die gewünschte Freiheit bieten und den würde ich auch einbauen.
Modulintern bleibt es dann bei der einfachen PVÜ Nutzung bzw. dem einfachen Durchschnitt über X Werte oder vllt. auch Median wie von dir vorgeschlagen was auch recht einfach intern umsetzbar wäre.
Hallo zusammen,
in meinem contrib liegt die V 1.40.0 zunächst zum Test wegen der Feiertage.
Der zum Schalten der Consumer ermittelte PV-Überschuß (Surplus) kann nun nach verschiedenen Methoden ermittelt und für jeden Consumer individuell eingestellt werden.
Dazu gibt es den optionalen Key "surpmeth" im Consumer-Attribut:
surpmeth
Die möglichen Optionen legen das Verfahren zur Ermittlung des PV-Überschusses fest. (optional)
default - der PV-Überschuß wird aus dem Reading 'Current_Surplus' direkt ausgelesen. (default)
median - es wird der Median der letzten PV-Überschuß Messungen (max. 20) verwendet.
2 .. 20 - der verwendete PV-Überschuß wird als Durchschnitt der angegebenen Anzahl Meßwerte gebildet.
Device:Reading - Device/Reading-Kombination die einen vom Nutzer bestimmten bzw. berechneten numerischen PV-Überschuß in Watt liefert.
Damit kann der User eigene Überschuß-Berechnungen in das Consumer-Schaltmodul integrieren.
Nach dem Download der Version aus dem contrib Restart nicht vergessen!
Edit: gerade (23.12, 08:50) das Modul im contrib nochmal upgedated.
LG und schöne Feiertage,
Heiko
Zitat von: DS_Starter am 22 Dezember 2024, 10:57:58Nach dem Download der Version aus dem contrib Restart nicht vergessen!
Ich hab's mal geladen und den neuen Schlüssel für 2 Verbraucher gesetzt. Aufgrund der schwachen PV-Prognose für die nächsten Tage wird's aber vermutlich ein paar Tage dauern, bis ich dazu was sagen kann.
Danke für die rasche und flexible Umsetzung.
Zitat... wird's aber vermutlich ein paar Tage dauern, bis ich dazu was sagen kann.
Naja, jetzt stehen bei mir auch erstmal andere Aktivitäten als FHEM-Entwicklung auf dem Plan. ;)
Bin gespannt auf deine Rückmeldung.
Falls du Fehler / Ungereimtheiten suchen willst oder musst -> ctrDebug=consumerSwitchingXX einschalten.
LG
Hallo,
ich bin gerade am einrichten des SolarForecast-Moduls. Leider stürzt mir mein komplettes FHEM ab, sobald ich mit "attr xxx setupWeatherDev1 OpenMeteoWorld-API" den Wetterdienst definiere. Es erscheint noch die Meldung "SolarForecast wartet auf Solarvorhersagedaten " - aber nach ca. einer Minute stürzt FHEM ab - im Eventlog finde ich folgende Fehlermeldungen:
2024.12.23 11:24:20 3: SolarForecast - all registered consumers collected
The following parameter was passed in the call to DateTime::Format::Strptime::new but was not listed in the validation options: strict
at /usr/share/perl5/DateTime/Format/Strptime.pm line 58.
DateTime::Format::Strptime::new(undef, "pattern", "%Y-%m-%dT%H:%M", "strict", 0, "time_zone", "UTC") called at lib/FHEM/Utility/CTZ.pm line 110
FHEM::Utility::CTZ::convertTimeZone(HASH(0x5e142c76e580)) called at ./FHEM/76_SolarForecast.pm line 17883
FHEM::SolarForecast::timestringUTCtoLocal("SolarForecast", "2024-12-23T10:15", "%Y-%m-%dT%H:%M") called at ./FHEM/76_SolarForecast.pm line 4214
FHEM::SolarForecast::__openMeteoDWD_ApiResponse(HASH(0x5e142b15e088), "", "{\"latitude\":48.34,\"longitude\":8.5,\"generationtime_ms\":0.16999"...) called at FHEM/HttpUtils.pm line 755
main::__ANON__(HASH(0x5e142b15e088)) called at fhem.pl line 786
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] RPC server CB2001001002001004 stopped handling connections. PID=1972 run=-1
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] Parent process (FHEM,PID=1724) not running. Shutting down RPC server process CB2001001002001004.
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] Deregistering RPC server http://192.168.1.2:7411/fh2001 with ID CB2001001002001004 at http://192.168.1.4:2001
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] FHEM will be restarted automatically if restart is enabled in system.d configuration.
Hat mir bitte jemand einen Tip was ich falsch mache - vielen Dank vorab !!
Schöne Feiertage,
Gruß,
Rolf
Hallo Rolf,
Bin unterwegs, deshalb nur kurz.
Glaube nicht dass du etwas falsch gemacht hast.
Kann das Problem noch nicht genau identifizieren, denke aber es liegt im Umfeld der Perl oder der usr/share/perl5/DateTime/Format/Strptime.pm Version. Kannst du mir die Versionen dieser Komponenten mitteilen?
Unsere Community kann dich sicher dabei unterstützen.
Nach den Feiertagen kann ich mir das anschauen.
LG Heiko
Zitat von: DS_Starter am 23 Dezember 2024, 13:10:20... Kannst du mir die Versionen dieser Komponenten mitteilen?
Unsere Community kann dich sicher dabei unterstützen.
Nach den Feiertagen kann ich mir das anschauen.
LG Heiko
Hallo Heiko,
danke für die schnelle Reaktion - es eilt nicht, ich freue mich wenn mich irgendwann nach den Feiertagen jemand unterstützt.
Als Betriebssystem arbeite ich mit einem Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-51) - perl ist laut apt install auf der neuesten Version 5.38.2-3.2build2 - aber die Datei usr/share/perl5/DateTime/Format/Strptime.pm ist vom 21.05.2021 und drin steht was von Version 1.79. Vermutlich also recht alt die usr/share/perl5/DateTime/Format/Strptime.pm - muss mich mal schlau machen wie man die aktualisieren kann...
Schöne Feiertage !,
Gruß,
Rolf
Zitat von: rolf am 23 Dezember 2024, 13:51:38Zitat von: DS_Starter am 23 Dezember 2024, 13:10:20... Kannst du mir die Versionen dieser Komponenten mitteilen?
Unsere Community kann dich sicher dabei unterstützen.
Nach den Feiertagen kann ich mir das anschauen.
LG Heiko
Hallo Heiko,
und gerade eben konnte ich das Problem lösen - dein Modul läuft jetzt.
Das Problem war tatsächlich ein "Mischmasch" der CPAN-Module - nachdem das korrigiert war, läuft das Ganze.
Danke nochmal für den entscheidenden Tip mit der strptime.pm !
Gruß,
Rolf
Hallo Heiko, besten Dank für dein Engagement hier. Ich schaue mir das Modul jeden Tag mehrmals an und es macht großen Spaß zu optimieren...
Eine Frage habe ich jedoch zum Battery_OptimumTargetSoC: wenn ich es richtig verstanden habe, ist das Ziel die Batterie optimal zu laden um das Batterie Management zu unterstützen. Mein Anwendungsfall wäre ein anderer, da ich gerne den Batterie Soc zwecks Ersatzstromversorgung so hoch wie möglich halten möchte. Kann man den optimalen Min soc auf Basis der Prognose für Ertrag und Verbrauch zu einem Zeitpunkt errechnen, sodass ich damit den Wechselrichter (Batterie-Entladungsgrenze) dynamisch konfigurieren kann. Also z.b.: Ertrag morgen 20Kwh, Verbrauch 10kwh, Batterie 10kwh = dann MinSoc auf 10% da die Batterie wieder geladen werden sollte. Wenn nur 10kwh Ertrag prognostiziert werden sollte der soc auf zb. 80% bleiben. Damit hätte man etwas Luft zum Puffern aber die max Ersatzstrom Kapazität. Das timing der Berechnung wäre zu wählen das auch entsprechend ausreichend Ladung in der Batterie ist, also nicht zu früh bzw. zu spät.
Oder ist das schon so ähnlich über Battery_OptimumTargetSoC abgedeckt?
Nochmals besten dank und weiter so 👍
Gruß Tom
Hallo Heiko,
hab mich mit deinem Modul beschäftigt - bin begeistert - wirklich super !
Bin am Definieren meiner "consumer" die bei PV-Überschuss geschaltet werden sollen und bräuchte da einen Denkanstoss. Bei mir steht ein E3DC-Speicher mit einer ACTHOR-Heizstabsteuerung die so funktioniert das jeglicher potentieller PV-Überschuss stufenlos geregelt in Heizstäbe geleitet wird, eben exakt so gesteuert das Netzeinspeisung unterbunden wird. Das führt aus Sicht vom Modul natürlich dazu das nie PV-Überschuss existiert - geht ja sofort in die Heizstäbe. Meine anderen "consumer" sollten aber Vorrang vor den Heizstäben haben. Die ACTHOR-Heizstabsteuerung liefert Werte - ist es der richtige Ansatz den ACTHOR im Modul als nicht schaltbaren Verbraucher zu definieren und falls irgendwie möglich mit niederer Priorität als die anderen consumer.
Danke vorab für einen Tip !
Gruß,
Rolf
Guten Morgen,
Bin noch unterwegs, deswegen kurz.
@Tom,
das kannst du mit dem upSoC regeln. Wenn du den Schlüssel z.B. auf 80 setzt, wird das Modul den Min SoC stark angelehnt an die Prognose bestimmen. Bei sehr wenig Erzeugungungsprognose, d.h. wenn der berechnete Min SoC sich oberhalb von upSoC bewegt, wird upSoC eingestellt. Landet die Berechnung unterhalb von upSoC (und werden weitere Bedingungen nicht verletzt) wird der berechnete SOC im Reading eingestellt. Werde ich im Wiki noch ergänzen.
@Rolf,
da muß ich erstmal drüber nachdenken.
Welche Werte liefert denn der Heizstab?
LG,
Heiko
Zitat von: DS_Starter am 26 Dezember 2024, 09:38:32@Rolf,
da muß ich erstmal drüber nachdenken.
Welche Werte liefert denn der Heizstab?
LG,
Heiko
Hallo Heiko,
ebenfalls guten Morgen !
An den ACTHOR9S (so heist das Steuergerät von myPV) sind bei mir 2 stufenlos regelbare Heizstäbe mit jeweils bis zu 3KW Leistungsaufnahme angeschlossen. Die Information welchen Überschuss es gerade gibt holt er sich direkt per MODBUS-Verbindung von meiner E3DC und regelt entsprechend die Heizstäbe hoch. Das Gerät unterstützt bis zu 3 Heizstäbe. Auslesen der Werte läuft bei mir per HTTPMOD - neben vielen anderen Infos liefert der ACTHOR:
- die aktuelle Leistung pro Heizstab in W
- die Energie pro Heizstab in W
- die Leistung für alle Heizstäbe in W
- die Energie für alle Heizstäbe in W
und und und....
Gerne liefere ich Dir auch die komplette Device....
Gruß,
Rolf
Das heißt die E3DC ermittelt ihrerseits permanent den Hausverbrauch und dementsprechend den kalkulierten Überschuß?
Kannst du diesen Überschuß mit FHEM auslesen?
Zitat von: DS_Starter am 26 Dezember 2024, 10:06:48Das heißt die E3DC ermittelt ihrerseits permanent den Hausverbrauch und dementsprechend den kalkulierten Überschuß?
Kannst du diesen Überschuß mit FHEM auslesen?
Ja, das ist kein Thema - ich lese die E3DC mit Modbus aus und bekomme so tausende von Infos, auch den Wert was se einspeisen will - zählt man den Wert und den aktuellen Wert den der ACTHOR9S abnimmt zusammen, dann hat man den kompletten Überschuss.
@Rolf, das sieht doch gut aus.
Problem ist, dass wir in deinem Fall 2 Regelkreise haben die nichts voneinander wissen.
Die noch nicht veröffentlichte Weiterentwicklung in #1395 könnte hier helfen.
Im Prinzip den Überschuß der E3DC zzgl. Des Wertes der ACTHOR9S zzgl. Eines evtl. Sicherheitszuschlags in ein Userreading bringen und dieses Userreading dem Verbraucherattribut im SF Schlüssel surpmeth mitteilen.
Bin jetzt ein paar Stunden unterwegs. Kannst ja mal drüber nachdenken. Ggf. hat TheTrumpeter schon erste Erfahrungen damit gesammelt.
LG
Zitat von: DS_Starter am 26 Dezember 2024, 11:35:04@Rolf, das sieht doch gut aus.
Problem ist, dass wir in deinem Fall 2 Regelkreise haben die nichts voneinander wissen.
Die noch nicht veröffentlichte Weiterentwicklung in #1395 könnte hier helfen.
Im Prinzip den Überschuß der E3DC zzgl. Des Wertes der ACTHOR9S zzgl. Eines evtl. Sicherheitszuschlags in ein Userreading bringen und dieses Userreading dem Verbraucherattribut im SF Schlüssel surpmeth mitteilen.
Bin jetzt ein paar Stunden unterwegs. Kannst ja mal drüber nachdenken. Ggf. hat TheTrumpeter schon erste Erfahrungen damit gesammelt.
LG
Hallo, danke erst Mal für den Tip - hab deine aktuelle Version aus dem contrib in mein FHEM geholt, neu gestartet, das entsprechende Reading generiert und jetzt mal einen "consumer" so definiert. Jetzt mal schauen was passiert, wenn das Wetter so bleibt dann könnte es eventuell sogar tatsächlich noch mit PV-Überschuss was werden ;-)
Gruß,
Rolf
So - hab jetzt einiges getestet und dein o.g. Tip scheint recht gut zu funktionieren - vielen Dank !
Hallo Rolf,
danke für deine Rückmeldung.
Dann werde ich die V 1.40.0 mit diesem Feature nun auch einchecken.
LG
Hallo euch allen und noch nachträglich frohe Weihnachten.
Mal eine Frage: Ich sitze mal wieder zur Zeit an meiner Oberfläche und wollte nun auch daten vom SolarForecast einbinden, ist es möglich die Energieflußgrafik (Flow Graphic) abzugreifen damit ich die in meine Oberfläche einfügen kann?
Danke euch schonmal.
Gruß Markus
Hallo Markus,
mit
get ... html ...
hast du verschiedene Möglichkeiten. Nur die Flow-Grafik würde gehen mit:
get ... html flow_noHead_noCons
Grüße,
Heiko
Zitat von: DS_Starter am 26 Dezember 2024, 23:29:41Dann werde ich die V 1.40.0 mit diesem Feature nun auch einchecken.
@DS_Starter:
Nach diesem Update passt irgendwie bei mir dem graphicBeamHeightLevel2 nicht mehr.
Hatte bislang dort seit langem den Wert mit "200" gesetzt.
Aber selbst bei einem gelöschtem Attribut (Standart = 200) wird es mir seeeeeeehr hoch angezeigt.(siehe Screenshot)
Bei Wert 10 ist es dann ca. so hoch wie vorher bei 200 :o ?
Liegt es an meinen Einstellungen oder hat sich beim letzten Update ein Bug eingeschlichen ? O:-)
Gruß
300P
Zitat von: DS_Starter am 27 Dezember 2024, 16:32:00Hallo Markus,
mit
get ... html ...
hast du verschiedene Möglichkeiten. Nur die Flow-Grafik würde gehen mit:
get ... html flow_noHead_noCons
Grüße,
Heiko
Hallo Heiko,
vielen Dank für die Antwort, da habe ich mal wieder den Wald vor lauter Bäumen nicht gesehen.
LG Markus
@300P,
ZitatBei Wert 10 ist es dann ca. so hoch wie vorher bei 200 :o ?
Liegt es an meinen Einstellungen oder hat sich beim letzten Update ein Bug eingeschlichen ? O:-)
Also an der grafischen Aufbereitung ist nichts geändert und bei mir gibt es auch keine Diskrepanzen.
Das Update beinhaltet rein logische Weiterentwicklungen.
Schauen wir morgen nochmal wie es dann bei dir aussieht.
Edit: Was ist der gelbe Balken für ein dargestellter Wert?
LG,
Heiko
Zitat von: DS_Starter am 27 Dezember 2024, 23:20:21Edit: Was ist der gelbe Balken für ein dargestellter Wert?
Gelb = EVU-Einspeisung
Rot = EVU-Bezug
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content gridconsumption
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content gridfeedin
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel1 200
attr Forecast graphicBeamHeightLevel2 200
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:statistic_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest Verbrauch ;bis ;Sonnenaufgang ;:statistic_conForecastTillNextSunrise FCU-Erzeugung ;:Current_PP01
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
attr Forecast graphicShowDiff top
attr Forecast graphicShowNight 1Gruß
300P
Moin,
ich habe deine Einstellung bei meinem Testsystem nachgestellt. Sieht ganz normal aus.
Die Attr graphicBeamHeightLevel1/2 haben übrigens 200 als default und kannst du im Prinzip löschen wenn du den Wert nicht änderst.
Bleibt das Verhalten wenn du den Content von Beam3 und Beam4 gegeneinander tauschst?
Kann mir nicht vorstellen dass die neue Version etwas damit zu tun hat weil keine Änderungen im Grafikbereich.
LG
Zuallererst habe ich meinen RPI jetzt noch mit allen evtl. anstehenden neuen Updates versorgt und komplett neuer RPI-Reboot.
Habe dann auch mal den Content von Beam3 + Beam4 getauscht.
-> nix verändert bzw. anders als erwartet (Farben bzw. Darstellung halt "andersrum"....)
Dann hab ich mal die beiden attr-Werte "200" gelöscht + extra nochmals FHEM-Neustart >> nun ist es sehr niedrig (
Aktuell bin ich jetzt bei einem BeamHeigtLevel2-Wert von "2000", dann sieht es in etwa so aus wie vorher.
==>>scheinbar hab ich irgendwelche Weihnachtsgeister die sich bei mir eingenistet haben) :-X :)) ::)
attr Forecast flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content gridfeedin
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content gridconsumption
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicBeamHeightLevel2 2000
attr Forecast graphicHeaderDetail all
attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal PV ;Morgen ;erwartet:Tomorrow_PVforecast PV ;Uebermorgen ;erwartet:statistic_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest Verbrauch ;bis ;Sonnenaufgang ;:statistic_conForecastTillNextSunrise FCU-Erzeugung ;:Current_PP01
attr Forecast graphicHistoryHour 4
attr Forecast graphicHourCount 24
attr Forecast graphicLayoutType double
PS:
Mach dir keine weiteren Gedanken um das Problem - vielleicht ist es nur irgendein Effekt der die Tage wieder weg ist.
Zuviel Plätzchen gegessen. ;)
Ich vermute es hat etwas mit dem Verhältnis des kleinsten darzustellen Wertes im Vergleich mit dem größten darzustellenden Wert zu tun. Ist aber nur erstmal ins Blaue getippt. Habe da keine wirkliche Idee.
Na vielleicht erkennen wir noch einen Zusammenhang.
Grüße,
Heiko
Ich habe Vorbereitungen im Modul getroffen um später die Möglichkeit zur Integration mehrerer Batterie Devices anbieten zu können.
Morgen früh wird ein Update ausgerollt:
- das Attribut setupBatteryDev wird in setupBatteryDev01 umgesetzt. Die Umsetzung passiert automatisch.
- es gibt einen neuen Getter valBattery
LG
Zitat von: DS_Starter am 28 Dezember 2024, 22:36:08Ich habe Vorbereitungen im Modul getroffen um später die Möglichkeit zur Integration mehrerer Batterie Devices anbieten zu können.
Morgen früh wird ein Update ausgerollt:
- das Attribut setupBatteryDev wird in setupBatteryDev01 umgesetzt. Die Umsetzung passiert automatisch.
- es gibt einen neuen Getter valBattery
LG
Ganz lieben Dank für diese sehr gute Aussicht!
Das mit dem Update erfolgte Umsetzen von setupBatteryDev in setupBatteryDev01 funktionierte einwandfrei. Die Doku verstehe ich so, dass bereits jetzt mehrere "Battery Devices" angelegt und im Modul auch via SoC-Management verwaltet werden können. Ist das richtig?
Guten Morgen !
heute vor dem Update sieht es bei gelöschten attr Forecast graphicBeamHeightLevel1 + 2 wieder besser aus.
Anbei Screenshot nach dem Update:
Guten Morgen zusammen,
@Parallix,
ZitatDie Doku verstehe ich so, dass bereits jetzt mehrere "Battery Devices" angelegt und im Modul auch via SoC-Management verwaltet werden können. Ist das richtig?
Nein, noch nicht. Du findest in den Attributen auch nur das Attr setupBatteryDev01. Später kommen dann noch setupBatteryDev02, setupBatteryDev03 dazu.
@300P,
wie gesagt 200 ist Standard für diese Attribute. Sollte also keinen Unterschied machen ob gelöscht oder auf 200 gesetzt.
Zitat von: DS_Starter am 29 Dezember 2024, 09:58:00Guten Morgen zusammen,
@Parallix,
ZitatDie Doku verstehe ich so, dass bereits jetzt mehrere "Battery Devices" angelegt und im Modul auch via SoC-Management verwaltet werden können. Ist das richtig?
Nein, noch nicht. Du findest in den Attributen auch nur das Attr setupBatteryDev01. Später kommen dann noch setupBatteryDev02, setupBatteryDev03 dazu.
...
Ahh, OK!
Hi,
habe mal wieder ein spezial Anliegen ;-)
Ich habe bemerkt das alle meine Zwischenzähler einen S0 Anschluss haben und lese diese nun mit ArduCounter aus.
Also habe ich meine Solarforecast Anzeige aufgepeppt mit all den neuen Werten.
Nun habe ich aber ein Problem. Ich habe einen Zwichenzähler für die Garage.
Dahinter habe ich aber noch einen Zähler für meine Ladestation fürs Auto.
Man könnte dies bei den Consumern Zweireihig darstellen, fände ich aber auch nicht so toll.
Oder könnte man angeben, dass der Wert des Autos nicht mitzählt für die Grafik, da er ja schon im Kellerzähler enthalten ist, aber trotzdem dargestellt wird?
Eventuell könnte man die 2 Symbole die dann zusammen gehören auch näher zusammen rücken in der Grafik?
Oder gibt es da schon was?
Gehen würde natürlich auch ein DummyDevice mit Dummy Readings bei dem ich von der Garage den Autoladestrom abziehe.
Wie würdet ihr das lösen?
Danke und Gruß,
Stefan
Hallo zusammen,
die Änderungen für ein Multi Batteriesystem sind recht umfangreich.
Ich checke Teilanpassungen ein um schrittweise voranzukommen. Morgen früh ist wieder ein Update verfügbar:
* im Attr ctrlStatisticReadings sind Anpassungen vorhanden: daysUntilBatteryCare -> daysUntilBatteryCare_01,
todayBatIn -> todayBatIn_01, todayBatOut -> todayBatOut_01
Falls ihr diese Readings über ctrlStatisticReadings generieren lasst, müsst ihr das Attribut neu setzen.
Im Log gibt es sonst sinngemäß folgende Fehler:
2024.12.29 23:12:08.545 1: SolCast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.29 23:12:08.546 1: SolCast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
LG
Zitat von: DS_Starter am 26 Dezember 2024, 09:38:32@Tom,
das kannst du mit dem upSoC regeln. Wenn du den Schlüssel z.B. auf 80 setzt, wird das Modul den Min SoC stark angelehnt a die Prognose bestimmen. Bei sehr wenig Erzeugungungsprognose, d.h. wenn der berechnete Min SoC sich oberhalb von upSoC bewegt, wird upSoC eingestellt. Landet die Berechnung unterhalb von upSoC (und werden weitere Bedingungen nicht verletzt) wird der berechnete SOC im Reading eingestellt. Werde ich im Wiki noch ergänzen.
Hallo Heiko, ich habe den up Soc auf 80%, dennoch bei wenig Prognose ist der berechnete OptimumTargetSoC auf 10%. Habe ich was falsch verstanden?
ctrlBatSocManagement
lowSoc=10 upSoC=80 maxSoC=99 careCycle=10
Morgen Tom,
schalte bitte ctrlDebug=batteryManagement ein und poste die Ausgabe. Sieht etwa so aus:
...
2024.12.30 08:22:30.879 1: SolCast DEBUG> SoC Bat 01 Step1 - compare with SoC history -> preliminary new Target: 35 %
2024.12.30 08:22:30.880 1: SolCast DEBUG> SoC Bat 01 Step2 - basics -> docare: 0, care SoC: 35 %, E expect: 27547 Wh, need for care SoC: 9946 Wh
2024.12.30 08:22:30.880 1: SolCast DEBUG> SoC Bat 01 Step2 - calc care SoC -> use preliminary Target: 35 % (care SoC calculation & activation postponed to after 30.12.2024 14:43:00)
2024.12.30 08:22:30.880 1: SolCast DEBUG> SoC Bat 01 Step3 - basics -> cantarget: 3 %, newtarget: 3 %
2024.12.30 08:22:30.881 1: SolCast DEBUG> SoC Bat 01 Step3 - charging probability -> docare: 0, Target: 35 % (no change)
2024.12.30 08:22:30.881 1: SolCast DEBUG> SoC Bat 01 Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 70 %
2024.12.30 08:22:30.881 1: SolCast DEBUG> SoC Bat 01 Step4 - observe low/up limits -> Target: 35 %
2024.12.30 08:22:30.881 1: SolCast DEBUG> SoC Bat 01 Step5 - rounding the SoC to steps of 5 % -> Target: 35 %
2024.12.30 08:22:30.882 1: SolCast DEBUG> SoC Bat 01 Step6 - force charging request: no (Battery is sufficiently charged)
...
LG
@Stefan,
ich würde einen Dummy für deinen Case verwenden.
Grüße,
Heiko
Zitat von: TheTrumpeter am 23 Dezember 2024, 10:15:31Zitat von: DS_Starter am 22 Dezember 2024, 10:57:58Nach dem Download der Version aus dem contrib Restart nicht vergessen!
Ich hab's mal geladen und den neuen Schlüssel für 2 Verbraucher gesetzt. Aufgrund der schwachen PV-Prognose für die nächsten Tage wird's aber vermutlich ein paar Tage dauern, bis ich dazu was sagen kann.
Danke für die rasche und flexible Umsetzung.
Scheint erstmal nicht richtig zu funktionieren mit "surpmeth=Device:Reading", zumindest wird bei laufendem Verbraucher sofort unterbrochen, sobald kein PV-Überschuss vorhanden ist, obwohl der gleitende Mittelwert noch passt. Aber möglicherweise habe ich die Version gezogen, bevor Du später nochmal aktualisiert hast?
Oder muss ich bei Sonderzeichen im Reading-Namen "escapen"? Dzt. ist es so definiert:
surpmeth=SmartMeterRestAPI:pvoffset_mean_1minIch lade einfach mal die neueste Version und beobachte es nochmal.
Damit man zu dem Schalten der Verbraucher etwas sagen kann ->
ctrDebug=consumerSwitchingXX
einschalten. Dann sieht man mehr. Sind viele Ausgaben.
Edit: Man sieht auch am Wert des Readings consumerXX_ConsumptionRecommended, welches du mit dem Attr ctrlConsRecommendReadings einschalten kannst, ob der Consumer eingeschaltet werden sollte (1) oder nicht (0).
LG
Zitat von: DS_Starter am 30 Dezember 2024, 08:25:03schalte bitte ctrlDebug=batteryManagement ein und poste die Ausgabe. Sieht etwa so aus:
Guter Hinweis - Ausgabe wie folgt:
2024.12.30 10:20:43 1: SolCast DEBUG> SoC calc Step1 - compare with SoC history -> preliminary new Target: 15 %
2024.12.30 10:20:43 1: SolCast DEBUG> SoC calc Step2 - calculate care SoC -> calculation & activation postponed to after 30.12.2024 15:04:00
2024.12.30 10:20:43 1: SolCast DEBUG> SoC calc Step3 - charging probability -> Target: 10 % (new target 15 % is activated after 30.12.2024 15:04:00)
2024.12.30 10:20:43 1: SolCast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 10 % (activation of care SoC 15 % is postponed)
2024.12.30 10:20:43 1: SolCast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 10 %
2024.12.30 10:20:43 1: SolCast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.12.30 10:20:43 1: SolCast DEBUG> Inverter 'Qcells' capacity: 0, Active power limit: 100 % -> Pmax limited: 0
2024.12.30 10:20:43 1: SolCast DEBUG> Summary active power limit of all Inverter (except feed 'grid'): 0
2024.12.30 10:20:43 1: SolCast DEBUG> Installed Battery capacity: 9000
2024.12.30 10:20:43 1: SolCast DEBUG> WARNING - The requirements for dynamic battery charge recommendation are not met. Exit.Was sagt es mir?
Mir sagt es zunächst, dass du nicht die aktuellste Version installiert hast. ;)
Kannst du das bitte machen und nochmal posten?
Kein Problem, neuer Versuch mit aktuellster Version:
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step1 - compare with SoC history -> preliminary new Target: 15 %
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step2 - basics -> docare: 0, care SoC: 15 %, E expect: 6357 Wh, need for care SoC: 4590 Wh
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step2 - calc care SoC -> use preliminary Target: 15 % (care SoC calculation & activation postponed to after 30.12.2024 15:04:00)
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step3 - basics -> cantarget: 29 %, newtarget: 15 %
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step3 - charging probability -> docare: 0, Target: 10 % (new target 15 % is activated after 30.12.2024 15:04:00)
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 80 %
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step4 - observe low/up limits -> Target: 10 %
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2024.12.30 10:40:38 1: SolCast DEBUG> SoC Bat 01 Step6 - force charging request: no (Battery is sufficiently charged)
2024.12.30 10:40:38 1: SolCast DEBUG> Inverter 'Qcells' capacity: 0, Active power limit: 100 % -> Pmax limited: 0
2024.12.30 10:40:38 1: SolCast DEBUG> Inverter '' capacity: 0, Active power limit: 100 % -> Pmax limited: 0
2024.12.30 10:40:38 1: SolCast DEBUG> Inverter '' capacity: 0, Active power limit: 100 % -> Pmax limited: 0
2024.12.30 10:40:38 1: SolCast DEBUG> Summary active power limit of all Inverter (except feed 'grid'): 0
2024.12.30 10:40:38 1: SolCast DEBUG> Installed Battery capacity: 9000
2024.12.30 10:40:38 1: SolCast DEBUG> WARNING - The requirements for dynamic battery charge recommendation are not met. Exit.[b][/b]
Hallo Tom,
die erwartete PV Energie ist 6357 Wh und kalkuliert aktuell 4590 Wh um den maxSoC zu erreichen. Deswegen setzt das Modul den SoC so tief um dem Haus die optimale Energiemenge zuzuführen. Das SoC-Modul schaut sich immer den aktuellen und den kommenden Tag an und entscheidet dann bzgl. der Kalkulation entsprechend der höhren Erwartung an beiden Tagen.
Der SoC wird dynamisch anpepasst, z.Zt. 15% ab 15:04. Der Zeitpunkt ist so gewählt damit reale Veränderungen der Ladung über den Tag mit eingehen. Damit ist auch sichergestellt dass die Energie morgen maximal in die Batterie aufgenommen werden kann.
Wenn du eine ständige Mindestreserve in der Batterie belassen willst, kannst du lowSoc auf diese Prozentzahl setzen, darunter wird sie nicht entladen (außer bei Stromausfall).
Dann kann es aber sein, dass der freie Speicher nicht ausreicht um die PV-Energie maximal zu speichern sodass ein Teil des Überschusses eingespeist wird.
Was dir beser passt, kannst nur du entscheiden.
LG,
Heiko
Danke für die Erklärung Heiko!
Wenn ich es richtig verstehe, wird der Target Soc so tief gesetzt damit die Batterie entladen werden kann, damit die überschüssige Pv Energie von der Batterie aufgenommen werden kann (6357 > 4590), richtig?
Aus meiner Sicht müsste aber neben den 4590Wh (Kapa bis 100% Soc) noch der Eigenverbrauch abgezogen werden (da bevor die Batterie lädt, das Haus versorgt wird). Im Anschluss könnte man dann den Target Soc berechnen also 100%-(das was nach eigenverbrauch übrig bleibt um die Batterie zu laden).
Oder denke ich falsch?
ZitatWenn ich es richtig verstehe, wird der Target Soc so tief gesetzt damit die Batterie entladen werden kann, umso die überschüssige Pv Energie von der Batterie aufgenommen werden kann (6357 > 4590), richtig?
Ja, richtig.
ZitatAus meiner Sicht müsste aber neben den 4590Wh (Kapa bis 100% Soc) noch der Eigenverbrauch abgezogen werden (da bevor die Batterie lädt, das Haus versorgt wird). Im Anschluss könnte man dann den Target Soc berechnen also 100%-(das was nach eigenverbrauch übrig bleibt um die Batterie zu laden).
Oder denke ich falsch?
Das ist völlig richtig. Das wird auch gemacht, allerdings wird der prognostizierte Verbrauch bis zum kommenden Sonennuntergang angesetzt. Denn nach dem Sonnenuntergang wird tendenziell keine PV mehr in die Bat geladen.
Nun kann ich nur den Verbrauch bis zum kommenden Sonnenuntergang berücksichtigen, den Verbrauch zwischen dem nächsten Sonnenaufgang und dem nächsten Sonnenuntergang habe ich nicht zur Verfügung.
Das ist eine gewisse Unschärfe, aber vllt. gelingt mir auch das noch. ;)
LG
Hallo zusammen,
morgen früh wird es ein weiteres Update geben. Es ist ein weiterer Schritt auf dem Weg zum Multi Battery System.
Diese Update ist für den User unter Umständen mit Aktivitäten verbunden weil Readingnamen geändert wurden:
* Current_BatCharge -> Current_BatCharge_XX
* Current_PowerBatOut -> Current_PowerBatOut_XX
* Current_PowerBatIn -> Current_PowerBatIn_XX
* Today_HourXX_PPrealXX -> Today_HourXX_PPreal_XX
* Current_PPXX -> Current_PP_XX
* Battery_OptimumTargetSoC -> Battery_OptimumTargetSoC_XX
* Battery_ChargeRequest -> Battery_ChargeRequest_XX
* Battery_ChargeRecommended -> Battery_ChargeRecommended_XX
* Today_HourXX_BatIn -> Today_HourXX_BatIn_XX
* Today_HourXX_BatOut -> Today_HourXX_BatOut_XX
Falls ihr diese Readings in eigenen Skripten verwendet, denkt daran nach dem Update diese Programme anzupassen!
LG und einen guten Rutsch!,
Heiko
ACHTUNG! ACHTUNG! Hiermit Informiere ich den Maintainer!
Die Module sagen aber das alles i.O. wäre.
Gerade das offizielle Update gezogen gehabt.
2024.12.31 09:03:20 1: ForecastSolarAPI - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:20 1: ForecastSolarAPI - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoEnsemble - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoEnsemble - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoWorld - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoWorld - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastDWD - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastDWD - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastVictronVRM - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastVictronVRM - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: Forecast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: Forecast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteo - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteo - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform
Zitat von: kask am 31 Dezember 2024, 09:09:56ACHTUNG! ACHTUNG! Hiermit Informiere ich den Maintainer!
Die Module sagen aber das alles i.O. wäre.
Gerade das offizielle Update gezogen gehabt.
2024.12.31 09:03:20 1: ForecastSolarAPI - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:20 1: ForecastSolarAPI - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoEnsemble - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoEnsemble - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoWorld - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteoWorld - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastDWD - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastDWD - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastVictronVRM - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastVictronVRM - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: Forecast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: Forecast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteo - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.31 09:03:21 1: ForecastOpenMeteo - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform
Sieht sehr nach den oben von Heiko beschriebenen ggf. erforderlichen manuellen Arbeiten aus. Bei mir läuft alles unauffällig.
Jepp, die ctrlStatisticReadings Attribute werden nicht mit umgeschrieben. Sonst wird ja für gewöhnlich alles erdenkliche vollautomatisch umbenannt wenn es neue Namen gibt.
Da war ich doch zu verwöhnt oder DS_Starter hatte es nicht auf dem Schirm.
Moin,
doch hatte ich auf dem Schirm. 😉
Die Meldung sagt:
Set the attribute again or inform Maintainer
Hast du den ersten Teil gemacht und das Attr ctrlStatisticReadings neu gesetzt? Die Auswahl der verfügbaren Optionen hat sich geändert. Einfach in dem Attr die obsoleten Werte wie todayBatIn abwählen und speichern.
LG
Zitat von: DS_Starter am 29 Dezember 2024, 23:43:15Hallo zusammen,
die Änderungen für ein Multi Batteriesystem sind recht umfangreich.
Ich checke Teilanpassungen ein um schrittweise voranzukommen. Morgen früh ist wieder ein Update verfügbar:
* im Attr ctrlStatisticReadings sind Anpassungen vorhanden: daysUntilBatteryCare -> daysUntilBatteryCare_01,
todayBatIn -> todayBatIn_01, todayBatOut -> todayBatOut_01
Falls ihr diese Readings über ctrlStatisticReadings generieren lasst, müsst ihr das Attribut neu setzen.
Im Log gibt es sonst sinngemäß folgende Fehler:
2024.12.29 23:12:08.545 1: SolCast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatIn' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2024.12.29 23:12:08.546 1: SolCast - ERROR in Application - attribute ctrlStatisticReadings KPI 'todayBatOut' has no Parameter or default value set. Set the attribute again or inform Maintainer.
LG
Wohl doch zu verwöhnt ;) bzw. evtl. ein Update übersprungen O:-)
PS:
Allen hier einen Guten Rutsch..
.. und einen besonderen Dank an Heiko =>> der "fast alles" möglich macht....
Gruß
300P
Nachsatz:
Sorry - irgendwie ist mal wieder alles bei mir zeitverzögert - hatte Heikos "vor"-Post noch nicht bei mir sichtbar
Jepp, wohl eins oder mehrere übersprungen. Turbulente Zeiten momentan bei mir.
Viele andere Projekte und momentan läuft das PV-Gemüse auf Stand ohne weitere optimierungen.
Ist ja wieder ienmal, wie jedes Jahr, das Tal der Tränen angesagt.
Und sicher habe ich das natürlich gemacht. Sonst hätte ich ja folgendes nicht gewusst.
ZitatJepp, die ctrlStatisticReadings Attribute werden nicht mit umgeschrieben.
Grüße an alle und vielen Dank für das Modul, das ich wirklich toll finde!
Ich habe einen Wechselrichter (Solaredge) mit einer Batterie, die in DC angeschlossen ist, während der Hausverbrauch in AC ist.
Leider gibt mir der Wechselrichter die Informationen in AC, ohne zwischen PV und Batterie zu unterscheiden, und gibt mir keine Informationen über die Energie, die derzeit in der Batterie ist (außer als Prozentsatz der Ladung).
Ich habe einige UserReadings erstellt, wollte aber um Rat fragen, wie ich das System am besten konfigurieren kann.
Startpunkt: setupInverterDev01 etotal eingestellt als X_PV_Energy (Gesamtenergie in AC).
Negative Auswirkungen: Erzeugung von ,,Phantom"-PV, wenn Energie aus der Batterie entnommen wird. Keine Informationen über batin und batout.
Positive Auswirkungen: Der Verbrauch wird genau berechnet.
Aktueller Stand: setupInverterDev01 etotal mit einem UserReading gesetzt, das X_PV_Energy minus die gesamte aus der Batterie entnommene Energie (in DC) berechnet.
Negative Auswirkungen: Der Verbrauch, wenn die PV nicht produziert, ist falsch, etwa 1,5~2 mal. Der Verbrauch während des Tages ist sogar negativ.
Positive Auswirkungen: Keine Erzeugung durch PV in der Nacht.
Der DC-AC-Wandlungswirkungsgrad der Batterie lag in der letzten Stunde bei über 90 % (und die Verbrauchsdifferenz ist wie oben). Ich ändere gerade das Userreading, um diesen Koeffizienten einzubeziehen, aber ich glaube nicht, dass es sich wesentlich ändern wird.
Ich habe auch festgestellt, dass ich die tagsüber in die Batterie eingespeiste Energie hinzurechnen muss, um einen negativen Verbrauch zu vermeiden (aber nochmals: sie wird in den DC eingespeist!).
Wenn ich es richtig verstehe, werden für die Verbrauchszählung nicht die Werte von pin/pout/pv verwendet, sondern die Energiewerte (intotal/outtotal/etotal), ist das richtig? In meinem Fall ist intotal = X_Battery_Stored_Energy, outtotal = X_Battery_Taken_Energy, etotal = X_PV_Net_Energy
Hat jemand eine ähnliche Situation wie ich und kann mir einen Rat geben, wie ich die Messwerte einstellen kann, um korrektere Werte zu erhalten? Unten sind einige meiner UserReadings, wenn ihr mehr braucht, kann ich sie natürlich gerne teilen.
Einen guten Start ins neue Jahr und vielen Dank!
X_Battery_Current_Energy:Battery_1_SOE.* {
return ReadingsVal($name,"Battery_1_Rated_Energy_WH",0) * ReadingsVal($name,"Battery_1_SOE",0) / 100;;
},
X_Battery_Taken_Energy:X_Battery_Current_Energy.* {
my $total_taken = ReadingsVal($name, "X_Battery_Taken_Energy", 0);;
my $previous_value = OldReadingsVal($name, "X_Battery_Current_Energy", 0);;
my $current_value = ReadingsVal($name,"X_Battery_Current_Energy",0);;
my $battery_efficiency = ReadingsVal($name,"X_Battery_AC_Efficiency",0);;
if( $current_value < $previous_value) {
return $total_taken + abs($current_value - $previous_value) * $battery_efficiency;;
}
return $total_taken;;
},
X_Battery_Stored_Energy:X_Battery_Current_Energy.* {
my $total_stored = ReadingsVal($name, "X_Battery_Stored_Energy", 0);;
my $previous_value = OldReadingsVal($name, "X_Battery_Current_Energy", 0);;
my $current_value = ReadingsVal($name,"X_Battery_Current_Energy",0);;
if( $current_value > $previous_value) {
return $total_stored + ($current_value - $previous_value);;
}
return $total_stored;;
},
X_Battery_AC_Efficiency:Battery_1_Instantaneous_Power_W.*|I_DC_Power.* {
my $i1_age = ReadingsAge($name, "I_DC_Power", 0);
my $b1_age = ReadingsAge($name, "Battery_1_Instantaneous_Power_W", 0);
my $i1_dc_power = ReadingsVal($name,"I_DC_Power",0);;
my $b1_dc_power = abs(min(0,ReadingsVal($name,"Battery_1_Instantaneous_Power_W",0)));;
my $previous_value = ReadingsVal($name, "X_Battery_AC_Efficiency", 0);;
if ($b1_age > $i1_age && $b1_dc_power != 0) {
return $previous_value;;
}
my $inverter_effectiveness = ReadingsVal($name,"solar_inverter_effectiveness",0);;
my $result = 1;;
if ($b1_dc_power == 0) {
$result = 1;;
} elsif ($i1_dc_power > $b1_dc_power) {
$result = 1;;
} else {
$result = (1-(($b1_dc_power - $i1_dc_power) / $b1_dc_power));;
}
return $result * $inverter_effectiveness;
},
X_PV_Net_Energy:X_PV_Energy.* {
return ReadingsVal($name,"X_PV_Energy",0) - abs(ReadingsVal($name,"X_Battery_Taken_Energy",0)) + ReadingsVal($name,"X_Battery_Stored_Energy",0);;
},
Hallo zusammen und ein gesundes neues Jahr!
Ich habe die Zeit genutzt und einen weiteren Schritt zum Multi Batterie System umgesetzt.
Das Update wird morgen früh ausgerollt.
* das Attribut ctrlBatSocManagement wird automatisch in ctrlBatSocManagement01 umbenannt.
Ihr braucht nichts zu tun.
@münster,
ich habe zwar kein solches System wie du, werde mir aber morgen mal genauer ansehen was du geschrieben hast.
Hatte heute keine richtige Gelegenheit dazu.
Vllt. gibt es auch User mit einer ähnlichen Konfiguration, was noch hilfreicher wäre.
LG,
Heiko
Zitat von: münster am 31 Dezember 2024, 19:03:03Hat jemand eine ähnliche Situation wie ich und kann mir einen Rat geben, wie ich die Messwerte einstellen kann, um korrektere Werte zu erhalten? Unten sind einige meiner UserReadings, wenn ihr mehr braucht, kann ich sie natürlich gerne teilen.
Guten Morgen und an alle ein frohes neue Jahr
Auch ich bin gerade dabei einen Hybridwechselrichter einzubinden - allerdings von SMA und nicht von SE - habe dabei ähnlich Probleme festgestellt - ich binde das über Modbus ein - ist auch bei SE möglich (https://knowledge-center.solaredge.com/sites/kc/files/sunspec-implementation-technical-note.pdf) dort stehen u.a. die folgenden (Batterie-) Parameter zur Verfügung
Batterie > Batterieentladung > Batterieentladung in kWh
Batterie > Batterieladung > Batterieladung in kWh
Batterie > Batterieentladung > Momentane Batterieentladung in W
Batterie > Batterieladung > Momentane Batterieladung in W
Batterie > Batterie > Ladezustand in %
und - genau wie von @münster beschrieben - die intern berechneten Parameter
AC-Seite > Messwerte > Gesamtertrag kWh (32 Bit)
AC-Seite > Messwerte > Tagesertrag kWh (32 Bit)
AC-Seite > Netzmessungen > Leistung W
In meinem derzeitigen Status habe ich von der Gesamtenergie (kWh) die Batterie(ent-)ladung abgezogen und erhalte somit nur die durch PV gewandelte Energie
Bei der Leistung bin ich ähnlich vorgegangen und habe die Gesamtleistung (W) mit den entsprechenden Batterieparametern in Beziehung gesetzt
Das Ganze ist derzeit ,mangels dauerhafter Sonne, ungetestet.
Gruß Gerd
Zitat von: Max_Meyer am 02 Januar 2025, 09:20:07Guten Morgen und an alle ein frohes neue Jahr
Auch ich bin gerade dabei einen Hybridwechselrichter einzubinden - allerdings von SMA und nicht von SE - habe dabei ähnlich Probleme festgestellt - ich binde das über Modbus ein - ist auch bei SE möglich (https://knowledge-center.solaredge.com/sites/kc/files/sunspec-implementation-technical-note.pdf) dort stehen u.a. die folgenden (Batterie-) Parameter zur Verfügung
Hallo zusammen, ich hätte erwähnen sollen, dass ich auch Modbus-Integration für meinen Wechselrichter verwende (https://github.com/pejonp/FHEM---SolarEdge).
Mit den letzten Änderungen (die ich oben gepostet habe) habe ich wieder eine Phantomproduktion über Nacht. Das Seltsame daran ist, dass die Produktion ungefähr gleich dem Verbrauch ist (der in der Tat ungefähr auf dem richtigen Niveau ist).
Ich sehe in der Solaredge-Monitoring, dass ich nachts einen Verbrauch von etwa 270Wh hatte. Heute Nacht (mit dem obigen Code) habe ich einen Verbrauch von etwa 270Wh (OK!), aber ich habe auch eine Phantomproduktion von etwa der gleichen Menge. (02: 276 verbraucht, 274 produziert, 03: 273 verbraucht, 272 produziert, usw.).
Ich fange an zu denken, dass ich von Anfang an neu beginnen muss :)
Zitat von: DS_Starter am 30 Dezember 2024, 22:35:56Hallo zusammen,
morgen früh wird es ein weiteres Update geben. Es ist ein weiterer Schritt auf dem Weg zum Multi Battery System.
Diese Update ist für den User unter Umständen mit Aktivitäten verbunden weil Readingnamen geändert wurden:
Hallo Heiko,
wäre es nicht sinnvoll, die bisherigen Readings als Gesamtsumme zu behalten? (Nicht SoC, aber alles mit Watt)
Hallo Heiko,
könntest du bei der Fehlermeldung (im Log gefunden) bitte noch die Werte anzeigen lassen?
Ich versteh die Meldung leider auch nicht ganz, welche erzeugte Energie, Stunde, Tag oder gesamt? Es läuft auch noch alles, hab auch nix geändert.
In der Anlagenkonfigurationsprüfung seh ich leider auch nicht die verwendete Modulversion - ist von gestern - aber es gibt natürlich schon eine Neuere...
PVForecastDach - WARNING - The generated PV of Inverter 'Strom_PV_All_Aktuell' is much more higher than inverter capacity. It seems to be a failure and Energy Total is reinitialized.
FYI:
Strom_PV_All_Aktuell pv=PVALL:kW etotal=All_Total:kWh capacity=10600
01 => ialias => PV
ietotal => 16052000
ifeed => default
igeneration => 7
ilimit => 100
iname => Strom_PV_All_Aktuell
invertercap => 10600
ändere mal das "pv=PVALL:kW" in "pv=PVALL:W" ab
Gruß
Christian
Hat schon mal jemand das "Batterie SOC und Max. Ladestrom Management" für einen Symo Gen24 mit BYD HVS umgesetzt?
Ich hab zwar via EVCC Zugriff via MQTT auf meinen Speicher (https://docs.evcc.io/docs/integrations/mqtt-api), aber das "Minimale Ladelimit" z.B. kann ich damit nicht setzen, da fängts schon an ...
############################################################################
# Batterie SOC und Max. Ladestrom Management
############################################################################
sub batSocChargeMgmnt {
my $name = shift;
my $hash = $defs{$name};
my $vebus = 'MQTT2_cerboGX_c0619ab34e08_vebus'; # Victron Vebus Device
my $vicsets = 'MQTT2_cerboGX_c0619ab34e08_settings'; # Victron Einstellungen
my $maxcspc = 105; # max. Ladestrom (A) Victron MPII Verbund
my $actmcc = ReadingsNum ($vebus, 'MaxChargeCurrent', undef); # akt. Ladestromeinstellung
my $load = $actmcc // $maxcspc; # Soll-Ladestrom (A)
## Battery SoC Management
###########################
my $ubsm = AttrVal ($name, 'userFn_BatterySoCManagement', 'aus');
if ($ubsm eq 'ein') {
my $bcrq = ReadingsNum ($name, 'Battery_ChargeRequest', 0);
my $csoc = ReadingsNum ($vicsets, 'MinimumSocLimit', 10); # akt. SoC
my $osoc = ReadingsNum ($name, 'Battery_OptimumTargetSoC', 10); # Soll-SoC
my $surp = ReadingsNum ($name, 'Current_Surplus', 0); # aktueller PV-Überschuß
if ($csoc != $osoc) {
CommandSet (undef, "$vicsets MinimumSocLimit $osoc");
Log3 ($name, 3, qq{$name - userFn SoCMgmnt -> MinimumSocLimit in $vicsets set to $osoc %});
}
if ($bcrq && $surp < 1000) { # max. Strom b. Battery_ChargeRequest
$load = 21;
}
else {
$load = $maxcspc;
}
}
## Batterie Einstellung MaxChargeCurrent
##########################################
if ($load != $actmcc) {
CommandSet (undef, "$vebus MaxChargeCurrent $load");
Log3 ($name, 3, qq{$name - userFn ChargeMgmnt -> MaxChargeCurrent in $vebus set }.
qq{from old $actmcc A to $load A});
}
readingsSingleUpdate ($hash, 'userFn_Bat_MaxChargeCurrent_set', $load, 0);
return;
}
@minierm,
Zitatwäre es nicht sinnvoll, die bisherigen Readings als Gesamtsumme zu behalten? (Nicht SoC, aber alles mit Watt)
Das betrifft m.M. nach nur die Readings Current_PowerBatIn_XX und Current_PowerBatOut_XX.
Beide Varianten (getrennt vs. gemeinsamer Wert aller Batterien) hat seine Vor- und Nachteile.
Der Vorteil der Trennung ist zunächst der genauere Blick darauf was momentan mit der Bat passiert, ob z.B. eventuelle Steuerungsmaßnahmen den Erfolg bringen der beabsichtigt ist. Auch kann man später in der Grafik diskrete Werte mit darstellen.
Der Nachteil ist ein Paar Readings mehr bzw. wenn man eine Summe möchte muß man die erst erstellen.
Welchen Vorteil würdest du in der Gesamtsumme sehen?
@grappa24,
Zitat... aber das "Minimale Ladelimit" z.B. kann ich damit nicht setzen.
Was meinst du damit? Wahrscheinlich das MinimumSocLimit, also den SoC der nicht unterschritten werden soll, oder?
Zitat von: DS_Starter am 02 Januar 2025, 17:25:11@grappa24,
Zitat... aber das "Minimale Ladelimit" z.B. kann ich damit nicht setzen.
Was meinst du damit? Wahrscheinlich das MinimumSocLimit, also den SoC der nicht unterschritten werden soll, oder?
genau das ...
Hi Grappa,
die BYD Batterie am Fronius solltest du über MQTT abfragen.
Damit kannst du auch die Limits setzen.
Ich benutze zwar auch EVCC aber eigentlich nur fürs Auto, die Batterie Werte von EVCC verwende ich nicht in FHEM.
Gibt es einen Grund warum du die Batterie Werte in FHEM über EVCC ausliest?
Hier mal die RAW Definition meines BYD Devices:
defmod BYD_Runge ModbusAttr 1 60 192.168.69.72:502 TCP
attr BYD_Runge dev-h-combine 125
attr BYD_Runge dev-h-defFormat %.1f
attr BYD_Runge dev-h-defLen 2
attr BYD_Runge dev-h-defPoll 1
attr BYD_Runge dev-h-defUnpack f>
attr BYD_Runge devStateStyle style="text-align:right"
attr BYD_Runge event-min-interval ACActEnergy:7200,ACPower:7200,Battery.*:7200
attr BYD_Runge event-on-change-reading .*Energy:0.1,ACPower:1,DCPowerMPPT.*:1,status,Battery.*harge.*:1,BatteryState
attr BYD_Runge group Fronius Modbus
attr BYD_Runge icon measure_battery_100
attr BYD_Runge obj-h40073-reading ACCurrentPhaseA
attr BYD_Runge obj-h40075-reading ACCurrentPhaseB
attr BYD_Runge obj-h40077-reading ACCurrentPhaseC
attr BYD_Runge obj-h40085-reading ACVoltagePhaseA
attr BYD_Runge obj-h40087-reading ACVoltagePhaseB
attr BYD_Runge obj-h40089-reading ACVoltagePhaseC
attr BYD_Runge obj-h40091-format %.0f
attr BYD_Runge obj-h40091-reading ACPower
attr BYD_Runge obj-h40093-reading ACFrequency
attr BYD_Runge obj-h40109-reading CabinetTemperature
attr BYD_Runge obj-h40117-format %s
attr BYD_Runge obj-h40117-len 1
attr BYD_Runge obj-h40117-map 1:off,2:sleeping,3:starting,4:active,5:throttled,6:shutdown,7:fault,8:standby
attr BYD_Runge obj-h40117-reading status
attr BYD_Runge obj-h40117-unpack n
attr BYD_Runge obj-h40196-expr $val / 1000
attr BYD_Runge obj-h40196-format %.2f
attr BYD_Runge obj-h40196-len 4
attr BYD_Runge obj-h40196-reading ACActEnergy
attr BYD_Runge obj-h40196-unpack Q>
attr BYD_Runge obj-h40267-format %d
attr BYD_Runge obj-h40267-group 1-1
attr BYD_Runge obj-h40267-len 1
attr BYD_Runge obj-h40267-reading DCPowerScale
attr BYD_Runge obj-h40267-unpack s>
attr BYD_Runge obj-h40284-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Runge obj-h40284-group 1-2
attr BYD_Runge obj-h40284-len 1
attr BYD_Runge obj-h40284-reading DCPowerMPPT1
attr BYD_Runge obj-h40284-unpack n
attr BYD_Runge obj-h40304-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Runge obj-h40304-group 1-3
attr BYD_Runge obj-h40304-len 1
attr BYD_Runge obj-h40304-reading DCPowerMPPT2
attr BYD_Runge obj-h40304-unpack n
attr BYD_Runge obj-h40324-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Runge obj-h40324-group 1-4
attr BYD_Runge obj-h40324-len 1
attr BYD_Runge obj-h40324-reading BatteryChargeWatt
attr BYD_Runge obj-h40324-unpack n
attr BYD_Runge obj-h40325-expr $val/100000
attr BYD_Runge obj-h40325-ignoreExpr $val < 100
attr BYD_Runge obj-h40325-len 2
attr BYD_Runge obj-h40325-poll 300
attr BYD_Runge obj-h40325-reading Summe_Ladung
attr BYD_Runge obj-h40325-unpack N
attr BYD_Runge obj-h40344-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Runge obj-h40344-group 1-5
attr BYD_Runge obj-h40344-len 1
attr BYD_Runge obj-h40344-reading BatteryDischargeWatt
attr BYD_Runge obj-h40344-unpack n
attr BYD_Runge obj-h40345-expr $val/100000
attr BYD_Runge obj-h40345-ignoreExpr $val < 100
attr BYD_Runge obj-h40345-len 2
attr BYD_Runge obj-h40345-poll 300
attr BYD_Runge obj-h40345-reading Summe_Entladung
attr BYD_Runge obj-h40345-unpack N
attr BYD_Runge obj-h40355-len 1
attr BYD_Runge obj-h40355-reading BatConfigMaxReferenceWatt
attr BYD_Runge obj-h40355-unpack n
attr BYD_Runge obj-h40358-format %s
attr BYD_Runge obj-h40358-len 1
attr BYD_Runge obj-h40358-map 0:none,1:chargeMax,2:dischrMax,3:bothMax
attr BYD_Runge obj-h40358-reading BatConfigMaxEnabled
attr BYD_Runge obj-h40358-set 1
attr BYD_Runge obj-h40358-unpack n
attr BYD_Runge obj-h40360-expr $val / 100
attr BYD_Runge obj-h40360-format %.0f
attr BYD_Runge obj-h40360-len 1
attr BYD_Runge obj-h40360-poll 60
attr BYD_Runge obj-h40360-reading BatConfigReserve
attr BYD_Runge obj-h40360-set 1
attr BYD_Runge obj-h40360-setexpr $val * 100
attr BYD_Runge obj-h40360-unpack n
attr BYD_Runge obj-h40361-expr $val / 100
attr BYD_Runge obj-h40361-len 1
attr BYD_Runge obj-h40361-reading BatteryChargePercent
attr BYD_Runge obj-h40361-unpack n
attr BYD_Runge obj-h40364-format %s
attr BYD_Runge obj-h40364-len 1
attr BYD_Runge obj-h40364-map 1:off,2:empty,3:discharging,4:charging,5:full,6:holding,7:testing
attr BYD_Runge obj-h40364-reading BatteryState
attr BYD_Runge obj-h40364-unpack n
attr BYD_Runge obj-h40365-expr $val / 10000 * ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Runge obj-h40365-len 1
attr BYD_Runge obj-h40365-max ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Runge obj-h40365-min -ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Runge obj-h40365-reading BatConfigMaxDischargeWatt
attr BYD_Runge obj-h40365-set 1
attr BYD_Runge obj-h40365-setexpr $val / ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1) * 10000
attr BYD_Runge obj-h40365-unpack s>
attr BYD_Runge obj-h40366-expr $val / 10000 * ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Runge obj-h40366-len 1
attr BYD_Runge obj-h40366-max ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Runge obj-h40366-min -ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Runge obj-h40366-reading BatConfigMaxChargeWatt
attr BYD_Runge obj-h40366-set 1
attr BYD_Runge obj-h40366-setexpr $val / ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1) * 10000
attr BYD_Runge obj-h40366-unpack s>
attr BYD_Runge room Strom
attr BYD_Runge stateFormat Status: BatteryState <br/>\
Ladung: BatteryChargePercent % | Reserve: BatConfigReserve %<br/>\
Max Charge: BatConfigMaxChargeWatt W | Max DisCharge:BatConfigMaxDischargeWatt W<br/>\
Config Max: BatConfigMaxEnabled<br/>\
Temp: CabinetTemperature °C<br/>
setstate BYD_Runge Status: holding <br/>\
Ladung: 33.3 % | Reserve: 5 %<br/>\
Max Charge: 12800.0 W | Max DisCharge:0.0 W<br/>\
Config Max: bothMax<br/>\
Temp: 42.6 °C<br/>
setstate BYD_Runge 2025-01-02 17:34:01 ACActEnergy 18320.65
setstate BYD_Runge 2025-01-02 17:34:01 ACCurrentPhaseA 0.0
setstate BYD_Runge 2025-01-02 17:34:01 ACCurrentPhaseB 0.0
setstate BYD_Runge 2025-01-02 17:34:01 ACCurrentPhaseC 0.0
setstate BYD_Runge 2025-01-02 17:34:01 ACFrequency 50.0
setstate BYD_Runge 2025-01-02 17:34:01 ACPower -24
setstate BYD_Runge 2025-01-02 17:34:01 ACVoltagePhaseA 226.5
setstate BYD_Runge 2025-01-02 17:34:01 ACVoltagePhaseB 227.6
setstate BYD_Runge 2025-01-02 17:34:01 ACVoltagePhaseC 229.1
setstate BYD_Runge 2025-01-02 17:34:01 BatConfigMaxChargeWatt 12800.0
setstate BYD_Runge 2025-01-02 17:34:01 BatConfigMaxDischargeWatt 0.0
setstate BYD_Runge 2025-01-02 17:34:01 BatConfigMaxEnabled bothMax
setstate BYD_Runge 2025-01-02 17:34:01 BatConfigMaxReferenceWatt 12800.0
setstate BYD_Runge 2025-01-02 17:34:01 BatConfigReserve 5
setstate BYD_Runge 2025-01-02 17:34:01 BatteryChargePercent 33.3
setstate BYD_Runge 2025-01-02 17:34:01 BatteryChargeWatt 0.0
setstate BYD_Runge 2025-01-02 17:34:01 BatteryDischargeWatt 0.5
setstate BYD_Runge 2025-01-02 17:34:01 BatteryState holding
setstate BYD_Runge 2025-01-02 17:34:01 CabinetTemperature 42.6
setstate BYD_Runge 2025-01-02 17:34:01 DCPowerMPPT1 0.5
setstate BYD_Runge 2025-01-02 17:34:01 DCPowerMPPT2 0.7
setstate BYD_Runge 2025-01-02 17:34:01 DCPowerScale -5
setstate BYD_Runge 2025-01-02 17:34:01 Summe_Entladung 4582.9
setstate BYD_Runge 2025-01-02 17:34:01 Summe_Ladung 4810.6
setstate BYD_Runge 2025-01-01 22:07:53 state opened
setstate BYD_Runge 2025-01-02 17:34:01 status active
Und es gibt noch noch ein sehr cooles Modul BYDBox.
Hiermit kannst du wirklich alle Infos der Batterie sogar auf Zellebene auswerten.
Hier ein Beispiel:
Screenshot 2025-01-02 173758.png
Gruß,
Stefan
Zitat von: stefanru am 02 Januar 2025, 17:39:45Gibt es einen Grund warum du die Batterie Werte in FHEM über EVCC ausliest?
ja, weil man in der evcc-yaml auf einfache Art und Weise die MQTT-topics auslösen kann. Wie machst du das, dass der Fronius/BYD die topics liefern?
ZitatHier mal die RAW Definition meines BYD Devices:
defmod BYD_Runge ModbusAttr 1 60 192.168.69.72:502 TCP
attr BYD_Runge dev-h-combine 125
das ist aber doch Modbus,
den Zugriff hab ich ja auch ... ich meine sogar von dir ;)
Ja genau ich nehme die Werte von Modubus.
Und da setze ich je nachdem die Werte für die Batterie.
Möglich zur Steuerung sind 4 Parameter:
BatConfigMaxChargeWatt
BatConfigMaxDischargeWatt
BatConfigMaxEnabled
BatConfigReserve
Ich benutze hauptsächlich BatConfigMaxChargeWatt, BatConfigMaxDischargeWatt.
Wobei hier eine 0 ein Lade bzw. Entlade stopp bewirkt.
BatConfigMaxEnabled habe ich dabei auf bothMax.
Man kann aber auch BatConfigReserve für einen MinSOC verwenden.
Ja klar über EVCC kann ich mir alle Daten per MQTT liefern lassen.
Aber es ist irgendwie eine unnötige indirektion die ich mir mit MQTT spare.
Oder willst du wirklich EVCC Steuern? Also wann das Auto geladen wird und wie mit der Batterie dabei umgegangen wird?
Das könntest du natürlich auch aus FHEM heraus, da benutze ich aber dann wirklich das EVCC UI.
Gruß,
Stefan
Zitat von: münster am 02 Januar 2025, 11:41:34Ich sehe in der Solaredge-Monitoring, dass ich nachts einen Verbrauch von etwa 270Wh hatte. Heute Nacht (mit dem obigen Code) habe ich einen Verbrauch von etwa 270Wh (OK!), aber ich habe auch eine Phantomproduktion von etwa der gleichen Menge. (02: 276 verbraucht, 274 produziert, 03: 273 verbraucht, 272 produziert, usw.).
Ich fange an zu denken, dass ich von Anfang an neu beginnen muss :)
Hallo münster,
ich tippe mal - wie geschrieben benutze ich eine andere Marke - aber die Probleme sind gleich. In meinem Falle ist es auch der erste Hybrid den ich einbinde aber SMA habe ich bereits mehrere laufen.
wenn ich richtig geschaut habe ist die SE-Integration, die du nutzt, von 2022 (letzte Änderung) --> damals gabs (meines Wissens) noch keine Hybrid-WR - und somit fehlen da ggfls. einige Parameter denke ich. In dem File, auf das ich heute morgen verwiesen habe, sind alle notwendigen Register vorhanden, glaube ich - die Frage ist ob das File für dein Gerät gültig ist - ansonsten findet sich das bestimmt im SE-Supportbereich. Die Register müssten nur abgefragt werden. Ich nutze dazu 98_ModbusAttr.pm. Zur Bestimmung der 'richtigen' Register nutze ich den Quervergleich mit der Oberfläche (Webserver) des WR - da wird ja der richtige/gewünschte Wert angezeigt.
Gruß Gerd
Zitat von: stefanru am 02 Januar 2025, 18:00:53Ja genau ich nehme die Werte von Modubus.
Und da setze ich je nachdem die Werte für die Batterie.
Möglich zur Steuerung sind 4 Parameter:
BatConfigMaxChargeWatt
BatConfigMaxDischargeWatt
BatConfigMaxEnabled
BatConfigReserve
Die ersten drei Parameter kann ich setzen, BatConfigReserve fehlt in der Liste meiner Set-Befehle
Vermutung: In meiner Solar-API ist bei der Modbus Konfig zwar "Steuerung erlauben" aktiv, aber auch "Steuerung Einschränken" aktiv
ZitatOder willst du wirklich EVCC Steuern? Also wann das Auto geladen wird und wie mit der Batterie dabei umgegangen wird?
Das könntest du natürlich auch aus FHEM heraus, da benutze ich aber dann wirklich das EVCC UI.
Nein, die Arbeit möchte ich mir nicht machen :D
Sehe soeben, dass einige von Euch plädieren, die BAT-Gesamtleistungswerte weiterhin im Modul zu belassen. Interessanterweise hat keiner bislang §14a EnWG als Grund hierfür angeben oder aber ich habe es überlesen. Unabhängig davon, ob die BAT-Leistungen einzeln oder in Summe betrachtet werden, wäre es sicherlich zukunftssicher, wenn im Modul vorgesehen werden könnte, dass - früher oder später - die maximale Leistung, die vom öffentlichen Netz rechnerisch den BAT-Systemen zugeführt wird, dynamisch limitiert werden kann. Recht anschaulich sind die künftigen Fähigkeiten, die insb. dieses tollen Modul möglich macht, z.B. auf einer Webseite von ABB (https://new.abb.com/low-voltage/de/niederspannungsprodukte/paragraf-14a-enwg/steuerung) unter dem Abschnitt "Mit Eigenerzeugungsanlage".
Naja, ob FHEM in einem solchen Falle dazu dann als anerkanntes ,,Steuergerät" (oder ähnliches) von ,,irgendwelchen Stellen" anerkannt werden wird ,,steht auf wackligen Beinen". O:-)
Trotzdem bin ich auch dafür dies im Modul weiterhin bereitzustellen - ansonsten behalte ich einfach weiterhin meinen Batteriedummy als Summenlieferant für diese Werte (wie bislang). 8)
Hi Grappa,
BatConfigReserve kam glaub ich später zu den ModBus Registern hinzu.
Schau mal ob du die attribute für obj-h40360 hast.
Wenn nicht übernehme sie mal von mir. Also alle für obj-h40360.
Gruß,
Stefan
Bezüglich einem summarischen Current_PowerBatIn(_Sum) bzw. Current_PowerBatOut(_Sum) bin ich völlig offen und kann es gerne (wieder) einbauen.
Da es eigentlich nur Sinn bei Anlagen mit mehr als einer Batterie macht, könnte ich diese Werte alternativ als eine auswählbare Option des Attr ctrlStatisticReadings anbieten.
Natürlich ginge auch eine generelle Generierung, wobei Nutzer nur einer Batterie (wohl die meisten) dann eine unnütze Readingredundanz haben.
Meinungen?
Mit
ctrlStatisticReading
wäre wohl allen mit geholfen.
Gruß
300P
Zitat von: 300P am 02 Januar 2025, 20:47:15Mit
ctrlStatisticReading
wäre wohl allen mit geholfen.
Gruß
300P
Hat zwar wenig mit Statistik zu tun, würde in der Tat aber den Zweck erfüllen.
ZitatHat zwar wenig mit Statistik zu tun, würde in der Tat aber den Zweck erfüllen.
Naja, wir müssen etwas kreativ sein. Wobei der Einwand durchaus berechtigt ist.
Mal sehen ob ich das Attribut passender benennen kann.
CtrlBatSumReading !?!
Zitat von: stefanru am 02 Januar 2025, 20:12:56BatConfigReserve kam glaub ich später zu den ModBus Registern hinzu.
Schau mal ob du die attribute für obj-h40360 hast.
Wenn nicht übernehme sie mal von mir. Also alle für obj-h40360.
mir fehlten 4 der 8 attribute, hab ich ergänzt, jetzt geht der set-Befehl für BatConfigReserve
ZitatMan kann aber auch BatConfigReserve für einen MinSOC verwenden.
Ich kann zwar jetzt BatConfigReserve setzen, mein MinSOC (=Minimales Ladelimit) lässt sich aber "scheinbar" nicht beeindrucken :(
Hallo zusammen,
In meinem contrib liegt eine neue Version die folgendes umgesetzt hat:
- das Attr ctrlStatisticReadings wird automatisch in ctrlSpecialReadings umgesetzt
- die generierten Readings heißen nun special_<Reading> statt statistic_<Reading>
- es sind nun die KPI BatPowerIn_Sum und BatPowerOut_Sum auswählbar
Die neuen Namen des Attributs und der Readings sind allgemeingültiger und passender zum Kontext.
Es ist schon spät, deswegen liegt die V zunächst im contrib.
Wer sie schon nutzen möchte, wie immer nach dem Download FHEM restarten!
LG,
Heiko
Vor dem Hintergrund eines optimierten SOC Managements, aber auch in Hinblick auf eine immer wichtiger werden netzdienliche Steuerung/Regelung insb. auch von BAT-Lade/Endladevorgängen, möchte ich meine Anregungen von gestern etwas plastischer darlegen, da sie wirklich perfekt zu dem hier diskutierten Kontext passen.
Grundidee der Netzdienlichkeit ist, dass Einspeisungen in einem Netzsegment möglichst dann vorgenommen werden, wenn Sie im gleichen oder einem anderen nahe liegenden Segment gebraucht werden und Verbräuche aus dem Netz möglichst dann getätigt werden, wenn im eigenen oder einem anderen nahe liegenden Segment aktuell eine Überproduktion existiert. Das ganze ist natürlich nur dann möglich, wenn auf Basis von BAT-Speichersystemen eine Pufferfunktionalität etabliert werden kann.
Das hier besprochene Modul bedient - z.B. betreffend SOC-Optimierung - bis dato im wesentlichen die eigenen Wünsche und zwar ohne eine (gewünschte und langfristig auch erforderliche) Netzdienlichkeit zu berücksichtigen. Würde man, basierend auf den Forecasts, BAT-Ladevorgänge hauptsächlich in die Zeiten positionieren, in denen besonders viel solare Energie lokal (und damit im wahrscheinlich auch im gesamten eigenen Netzsegment) zur Verfügung steht, dann würde man sich - ohne größere eigene Nachteile erleiden zu müssen - netzdienlich verhalten. Andersherum sollte - im Sinne der Netzdienlichkeit - kein Bezug von Energie aus dem Netz erfolgen, wenn dieses aufgrund geringer solarer Erträge im eigenen Netzsegment ohnehin gefordert wird.
Das alles wäre eine rein perspektivische Optimierung auf Basis der Forecasts und würde – insbesondere, wenn's noch mehr Leute machen – im eigenen Netzsegment wahrscheinlich auch niemals zu VNB-seitigen Einspeise oder Bezugslimitierungen führen, was auch im eigenen Interesse sein dürfte. Das beste ist, dass das Modul bereits aktuell (fast) alles hierfür erforderliche bereitstellt.
@stefanru
Zitat von: grappa24 am 02 Januar 2025, 22:02:26ZitatMan kann aber auch BatConfigReserve für einen MinSOC verwenden.
Ich kann zwar jetzt BatConfigReserve setzen, mein MinSOC (=Minimales Ladelimit) lässt sich aber "scheinbar" nicht beeindrucken :(
Kann es sein, dass man den BYD nicht direkt (über Modbus) steuern kann sondern über den Fronius GEN24 gehen muss - um den MinSOC einzustellen?
P.S. Sorry, ich glaube das gehört besser in den Fronius Thread, aber ich glaube, wir haben es gleich
ZitatWürde man, basierend auf den Forecasts, BAT-Ladevorgänge hauptsächlich in die Zeiten positionieren, in denen besonders viel solare Energie lokal (und damit im wahrscheinlich auch im gesamten eigenen Netzsegment) zur Verfügung steht, dann würde man sich - ohne größere eigene Nachteile erleiden zu müssen - netzdienlich verhalten.
Das versuche ich mit der Routine zur Erstellung des Readings Battery_ChargeRecommended_XX zu unterstützen.
Der User wäre bei entsprechender Nutzung in der Lage seine Batterie(n) Prognose/Erzeugung-optimiert zu laden.
Wie gut das funktioniert müssen wir sehen wenn wieder mehr Sonnenenergie vorhanden ist. Werde ich auch noch im Wiki beschreiben wie man das für eine Victron-Anlage umsetzen kann.
Zitat von: DS_Starter am 03 Januar 2025, 10:32:49ZitatWürde man, basierend auf den Forecasts, BAT-Ladevorgänge hauptsächlich in die Zeiten positionieren, in denen besonders viel solare Energie lokal (und damit im wahrscheinlich auch im gesamten eigenen Netzsegment) zur Verfügung steht, dann würde man sich - ohne größere eigene Nachteile erleiden zu müssen - netzdienlich verhalten.
Das versuche ich mit der Routine zur Erstellung des Readings Battery_ChargeRecommended_XX zu unterstützen.
Der User wäre bei entsprechender Nutzung in der Lage seine Batterie(n) Prognose/Erzeugung-optimiert zu laden.
Wie gut das funktioniert müssen wir sehen wenn wieder mehr Sonnenenergie vorhanden ist. Werde ich auch noch im Wiki beschreiben wie man das für eine Victron-Anlage umsetzen kann.
Wird denn auch der umgekehrte Fall adressiert, bei dem die (noch nicht leeren) Speicher trotz solarer Energie zur Deckung des Eigenbedarfs genutzt werden (sollten), wenn später am Tag genug solare Energie zur Verfügung steht?
ZitatWird denn auch der umgekehrte Fall adressiert, bei dem die (noch nicht leeren) Speicher trotz solarer Energie zur Deckung des Eigenbedarfs genutzt werden (sollten), wenn später am Tag genug solare Energie zur Verfügung steht?
Nehmen wir an die Batterie ist zu 60% voll, der User hat upSoC=40 eingestellt.
Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet. Das Reading Battery_ChargeRecommended_XX würde dann "0" gesetzt und bei entsprechender Steuerung der Anlage durch den User würde
1. die Batterie nicht geladen
2. die erzeugte Energie dem Haus zur Verfügung gestellt bzw. der Überschuß eingespeist.
Gleichermaßen würde die Batterie entladen von 60% bis runter auf min 40% (bzw. noch tiefer bis lowSoC wenn sehr viel erwartet wird) und diese Energie dem Haus zuführen. Dabei wird aber permanent bei jedem Zyklus neu berechnet ob die Differenz vom aktuellen SoC zum eingestellten maxSoC hinreichend klein ist um mit dem zu erwartenden Restüberschuß des Tages wahrscheinlich maxSoC bzw. dessen Nähe zu erreichen. Sollte der Grenzwert erreicht sein, wird Battery_ChargeRecommended_XX=1 gesetzt und der User sollte dann über geeignete Befehle seine Anlage auf Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.
Ich denke der Prozess insgesamt unterstützt so ein netzdienliches Verhalten des Haushalts.
Wie gesagt, müssen wir in der Praxis testen wie gut das funktioniert.
Ich habe die Vorabversion von gestern Abend eingecheckt und wird dann morgen früh ausgeliefert.
Zur Erinnerung was geändert wurde:
- das Attr ctrlStatisticReadings wird automatisch in ctrlSpecialReadings umgesetzt
- die generierten Readings heißen nun special_<Reading> statt statistic_<Reading>
- es sind die KPI BatPowerIn_Sum und BatPowerOut_Sum auswählbar
Da sich die statistic_<Reading> in special_<Reading> ändern, kontrolliert und ändert ggf. nach dem Update eure eigenen Skripte wo ihr diese Readingnamen verwendet!
Kontrolliert auch das Attr graphicHeaderOwnspec oder ctrlUserExitFn falls ihr es verwendet.
LG,
Heiko
Zitat von: grappa24 am 02 Januar 2025, 22:02:26Zitat von: stefanru am 02 Januar 2025, 20:12:56BatConfigReserve kam glaub ich später zu den ModBus Registern hinzu.
Schau mal ob du die attribute für obj-h40360 hast.
Wenn nicht übernehme sie mal von mir. Also alle für obj-h40360.
mir fehlten 4 der 8 attribute, hab ich ergänzt, jetzt geht der set-Befehl für BatConfigReserve
ZitatMan kann aber auch BatConfigReserve für einen MinSOC verwenden.
Ich kann zwar jetzt BatConfigReserve setzen, mein MinSOC (=Minimales Ladelimit) lässt sich aber "scheinbar" nicht beeindrucken :(
Da hatte ich wohl "zuviel" erwartet ;)
Die BatConfigReserve lässt sich WOHL setzen und wird auch vom GEN24/BYD eingehalten, lediglich in der API erscheint der über Modbus gesetze Wert nicht. Jetzt kann ich weitermachen und das "Batterie SOC und Max. Ladestrom Management" umsetzen :D
Das finde ich aber äusserst doof das du die statistic Werte mal eben alle umbenennst. Es gibt ja Leute die auch mit den Werten weiter arbeiten und nicht das ganze Zeug aus dem Modul nutzen. Es gibt Gründe warum man beim Programmieren erst einmal depricated und nicht sofort umbenennt.
Und jetzt muß man (ich) das alles nachziehen!
Schade, schade!
Und der Grund erschliesst sich mir auch ehrlich gesagt nicht. Weil ein Wert so nicht als statistic passt? Wieso erstellst du dafür nicht eine neue Readingsgruppe alla "miscellaneous_" oder "misc_" da kann man sowas auch rein machen für exoten und verschiedenes was nirgends passt. Und nicht die statistic_ welche ja auch so sind mal eben in "special_" umbennenen.
Ich kann nur noch einmal sagen. Ich kann das nicht für Gut heißen!
Hallo kask,
Das habe ich mir nicht einfach gemacht. Aber ich habe mir gesagt, einmal den Schmerz muss ich ertragen und dann ist das Thema durch.
Warum nicht extra eine neue Gruppe? Damit es programmtechnisch pflegbar bleibt nicht auseianderläuft.
Abwr warum kommt das erst jetzt? Seit gestern reden wir darüber und du bist ja auch einer der Aktiven Mitstreiter. Ausserdem schreibe ich hier alles haarklein im VORFELD. Niemand wird plötzlich überrumpelt.
Ich mach dir einen Vorschlag ... schau dir in Ruhe an wo du diese Readings benutzt, dann erst mach das Update und pass die Stellen dann
an. Das Präfix special_ passt zukünftig für jeden Sonderfall und ich und jeder Andere hat Ruhe damit.
LG
Ja, ich bin schon oft hier. Aber 24h mal nicht gucken kann schon passieren ;)
Ist alles gut. Ich habe daraus ja auch gelernt. Ich loge nichts direkt mehr aus Modulen in Zukunft.
Somit spare ich mir beim ändern der Variabelen der Module das anpassen der Logs.
Die variabelen kann ich mir ja dann umschreiben. Muß ich ja sowieso dann auch.
Denoch großes Danke schön für die Erleuchtung.
Finde es trotzdem Doof. Die statistic Werte waren/sind prädestiniert zumn direkten loggen und jetzt müßen Alle ihre logs umschreiben um wieder einen zusammenhang zu bekommen.
Das ist aber auch alleine meine Meinung.
ZitatDie variabelen kann ich mir ja dann umschreiben. Muß ich ja sowieso dann auch.
Der Sinn erschliest sich jetzt mir aber auch nicht. ;)
Mach dir nicht so viel Arbeit. Eine Änderung von Readingnamen passiert äusserst äusserst selten und auch nur im Rahmen der Entwicklungsarbeit bis alles passt.
Hallo mein lieber kask, ich denke ich kann dir/euch die statistic_ Readings parallel ,sagen wir noch bis Ende des Monats?, erstellen.
Würde das helfen?
Du hattest ja geschrieben dass bei dir momentan viel los ist.
LG
Danke für das Angebot. Aber für mich musst du das nicht machen. Ich muss es ja sowieso anpassen über kurz oder lang.
Sondiere gerade für mich wie ich das möglichst schnell bzw. komfortabel anstelle. Wie gesagt, alles gut.
Wie jedes Jahr im Januar habe ich ein FHEM Update durchgeführt.
Leider meldet sich SolarForercast als wäre es erstmalig konfiguriert:
Warm welcome!
The next queries will guide you through the basic installation.
If all entries are made, please check the configuration finally with "set SolarModell (http://192.168.178.29:8083/fhem?detail=SolarModell) plantConfiguration check" or by pressing the offered icon.
Please correct any errors and take note of possible hints.
(The display language can be changed with attribute "ctrlLanguage".)
Im Logfile vom Update steht
2025.01.03 18:02:10 3: SolarModell - cached data "pvHistory" restored
2025.01.03 18:02:10 3: SolarModell - cached data "pvCircular" restored
2025.01.03 18:02:10 3: SolarModell - cached data "consumerMaster" restored
2025.01.03 18:02:10 3: SolarModell - cached data "radiationApiData" restored
2025.01.03 18:02:10 3: SolarModell - cached data "aiRawData" restored
Aber es fehlt irgendwie
PVCfg_SolarForecast_
Wenn ich mit "set plantConfiguration restore" versuche die Daten zu laden kommt diese Fehlermeldung:
File is not a perl storable at /usr/lib/arm-linux-gnueabihf/perl/5.28/Storable.pm line 412, at ./FHEM/76_SolarForecast.pm line 19729.
Was kann ich tun, um die Plant wiederherzustellen?
@alf.ele,
dann kommst du aber von einer sehr alten Version.
Im einfachsten Fall die abgefragten Parameter in den Attributen eingeben.
Ansonsten kannst das File PVCfg_SolarForecast_ mit einem Editor öffnen und die Werte übertragen. Das alte File ist normal lesbar. JSON.
Wenn du Unterstüttung brauchst meldest dich bitte wieder.
LG
Zitat von: kask am 03 Januar 2025, 19:12:34Danke für das Angebot. Aber für mich musst du das nicht machen. Ich muss es ja sowieso anpassen über kurz oder lang.
Sondiere gerade für mich wie ich das möglichst schnell bzw. komfortabel anstelle. Wie gesagt, alles gut.
@kask:
Kurzinfo:
root@EnergyPi:/home/pi# grep -r 'statistic_' /opt/fhem/ > ausgabe.txt
Auf einem RPI (LINUX-Terminal) kannst du hiermit einfach und rekursiv, z.B. ab dem FHEM-Verzeichnis '/opt/fhem/', in allen Dateien darauf die Inhalte durchsuchen lassen.
Das Ergebnis siehst du dann im aktuellen Verzeichnis (hier =>> /home/pi/) in der angegeben Datei mit einem Texteditor.
Ergebnis: (hier aber mit 'special_' + ohne Dateierzeugung gesucht O:-) )
root@EnergyPi:/home/pi# grep -r 'special_' /opt/fhem/
/opt/fhem/FHEM/76_SolarForecast.pm: naming scheme 'special_<indicator>'. Selectable key figures / indicators are: <br><br>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>CO&nbsp;until&nbsp;sunset:special_todayConForecastTillSunset </td></tr>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>PV&nbsp;Day&nbsp;after&nbsp;tomorrow:special_dayAfterTomorrowPVforecast </td></tr>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>in&nbsp;today:special_todayBatIn </td></tr>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>out&nbsp;today:special_todayBatOut </td></tr>
/opt/fhem/FHEM/76_SolarForecast.pm: Namensschema 'special_<Indikator>' erstellt. Auswählbare Kennzahlen / Indikatoren sind: <br><br>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>CO&nbsp;bis&nbsp;Sonnenuntergang:special_todayConForecastTillSunset </td></tr>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>PV&nbsp;Übermorgen:special_dayAfterTomorrowPVforecast </td></tr>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>in&nbsp;heute:special_todayBatIn </td></tr>
/opt/fhem/FHEM/76_SolarForecast.pm: <tr><td> </td><td>out&nbsp;heute:special_todayBatOut </td></tr>
/opt/fhem/FHEM/58_HVAC_DaikinAC.pm: $q = sprintf($q . "aircon/set_special_mode?spmode_kind=%d&set_spmode=%d", 1, $val);
/opt/fhem/FHEM/58_HVAC_DaikinAC.pm: $q = sprintf($q . "aircon/set_special_mode?spmode_kind=%d&set_spmode=%d", 2, $val);
/opt/fhem/FHEM/58_HVAC_DaikinAC.pm: $q = sprintf($q . "aircon/set_special_mode?en_streamer=%d", $val);
/opt/fhem/FHEM/76_SMAEVCharger.pm: my $special_header = "";
/opt/fhem/FHEM/76_SMAEVCharger.pm: $special_header = "-H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Content-Length: $content_len' -H 'Origin: $baseurl' -H 'Referer: $baseurl/webui/login' ";
/opt/fhem/FHEM/76_SMAEVCharger.pm: $special_header = "-H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Content-Length: $content_len' -H 'Origin: $baseurl' -H 'Referer: $baseurl/webui/login' ";
/opt/fhem/FHEM/76_SMAEVCharger.pm: $special_header = "-H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Content-Length: $content_len' -H 'Referer: $baseurl/webui/login' ";
/opt/fhem/FHEM/76_SMAEVCharger.pm: $special_header = "-H 'Content-Type: application/json' -H 'Content-Length: $content_len' -H 'Referer: $baseurl/webui/Plant:1,IGULD:SELF/configuration/view-parameters' ";
/opt/fhem/FHEM/76_SMAEVCharger.pm: $special_header = "-H 'Content-Type: application/json' -H 'Content-Length: $content_len' -H 'Referer: $baseurl/webui/Plant:1,IGULD:SELF/configuration/view-parameters' ";
/opt/fhem/FHEM/76_SMAEVCharger.pm: $special_header = "-H 'Referer: $baseurl/webui/Plant:1/dashboard' ";
/opt/fhem/FHEM/76_SMAEVCharger.pm: $curlcmd = $cmd_call.$method.$header.$special_header.$token.$cookies.$data.$url;
/opt/fhem/fhem.cfg:attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:statistic_conForecastTillNextSunrise FCU-Erzeugung ;:Current_PP_01 PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest_01 Batt.-Ladung ;empfohlen:Battery_ChargeRecommended_01
/opt/fhem/restoreDir/save/2025-01-03/fhem.cfg:attr Forecast graphicHeaderOwnspec PV ;Heute ;real:Today_PVreal Verbrauch ;bis ;Sonnenaufgang ;:statistic_conForecastTillNextSunrise FCU-Erzeugung ;:Current_PP_01 PV ;Uebermorgen ;erwartet:special_dayAfterTomorrowPVforecast Batt.-Ladeanforderung ;:Battery_ChargeRequest_01 Batt.-Ladung ;empfohlen:Battery_ChargeRecommended_01
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_BatPowerIn_Sum 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_BatPowerOut_Sum 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_SunHours_Remain 0.00
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_SunMinutes_Remain 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_allStringsFullfilled 1
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_conForecastTillNextSunrise 9449 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentAPIinterval 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentRunMtsConsumer_01 129 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentRunMtsConsumer_02 191 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentRunMtsConsumer_03 315106 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentRunMtsConsumer_04 200 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentRunMtsConsumer_05 27 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentRunMtsConsumer_06 32 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_currentRunMtsConsumer_07 28 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_dayAfterTomorrowPVforecast 12250 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_daysUntilBatteryCare_01 13
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_lastretrieval_time 2025-01-03 18:47:48
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_lastretrieval_timestamp 1735926468
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_response_message success
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeAvgDayConsumer_01 436.43 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeAvgDayConsumer_02 387.97 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeAvgDayConsumer_03 1429.94 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeAvgDayConsumer_04 233.40 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeAvgDayConsumer_05 28.80 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeAvgDayConsumer_06 31.80 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeAvgDayConsumer_07 357.35 min
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeCentralTask 0.3980
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeLastAPIAnswer -
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeLastAPIProc -
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_runTimeTrainAI 1.2766
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayBatIn_01 4090.0 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayBatOut_01 2367.0 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayConForecastTillSunset 0 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 08:59:52 special_todayConsumptionForecast_09 685 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 09:59:53 special_todayConsumptionForecast_10 824 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 10:59:51 special_todayConsumptionForecast_11 645 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 11:59:53 special_todayConsumptionForecast_12 667 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 12:59:49 special_todayConsumptionForecast_13 1069 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 13:59:52 special_todayConsumptionForecast_14 1011 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 14:59:59 special_todayConsumptionForecast_15 942 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 15:59:59 special_todayConsumptionForecast_16 860 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 16:59:58 special_todayConsumptionForecast_17 841 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 17:59:59 special_todayConsumptionForecast_18 947 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayConsumptionForecast_19 854 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayConsumptionForecast_20 781 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayConsumptionForecast_21 716 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayConsumptionForecast_22 710 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayConsumptionForecast_23 686 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayConsumptionForecast_24 597 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayDoneAPIcalls 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayDoneAPIrequests 4501
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayGridConsumption 232.6 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayGridFeedIn 127.7 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayMaxAPIcalls n.a.
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayRemainingAPIcalls n.a.
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast 2025-01-03 18:47:48 special_todayRemainingAPIrequests n.a.
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_SunHours_Remain 0.00
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_SunMinutes_Remain 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_allStringsFullfilled 1
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_conForecastTillNextSunrise 21384 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_currentAPIinterval 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_dayAfterTomorrowPVforecast 4415 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_daysUntilBatteryCare_01 -
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_lastretrieval_time 2025-01-03 18:47:28
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_lastretrieval_timestamp 1735926448
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_response_message success
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_runTimeCentralTask 0.1206
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_runTimeLastAPIAnswer -
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_runTimeLastAPIProc -
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_runTimeTrainAI 0.0860
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayConForecastTillSunset 0 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 08:59:49 special_todayConsumptionForecast_09 1452 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 09:59:49 special_todayConsumptionForecast_10 1522 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 10:59:49 special_todayConsumptionForecast_11 1459 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 11:59:50 special_todayConsumptionForecast_12 1550 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 12:59:49 special_todayConsumptionForecast_13 1603 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 13:59:49 special_todayConsumptionForecast_14 1492 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 14:59:49 special_todayConsumptionForecast_15 1430 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 15:59:49 special_todayConsumptionForecast_16 1433 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 16:59:52 special_todayConsumptionForecast_17 1561 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 17:59:49 special_todayConsumptionForecast_18 1654 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayConsumptionForecast_19 1611 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayConsumptionForecast_20 1793 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayConsumptionForecast_21 1826 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayConsumptionForecast_22 1521 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayConsumptionForecast_23 1454 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayConsumptionForecast_24 1323 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayDoneAPIcalls 0
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayDoneAPIrequests 1004
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayGridConsumption 25806.0 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayGridFeedIn 58.0 Wh
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayMaxAPIcalls n.a.
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayRemainingAPIcalls n.a.
/opt/fhem/restoreDir/save/2025-01-03/log/fhem.save:setstate Forecast_M 2025-01-03 18:47:28 special_todayRemainingAPIrequests n.a.
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_BatPowerIn_Sum 27
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_BatPowerOut_Sum 0
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_SunHours_Remain 0.00
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_SunMinutes_Remain 0
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_allStringsFullfilled 1
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_conForecastTillNextSunrise 9400 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentAPIinterval 0
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentRunMtsConsumer_01 129 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentRunMtsConsumer_02 196 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentRunMtsConsumer_03 315110 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentRunMtsConsumer_04 200 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentRunMtsConsumer_05 27 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentRunMtsConsumer_06 36 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_currentRunMtsConsumer_07 32 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_dayAfterTomorrowPVforecast 12250 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_daysUntilBatteryCare_01 13
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_lastretrieval_time 2025-01-03 18:52:31
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_lastretrieval_timestamp 1735926751
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_response_message success
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeAvgDayConsumer_01 436.43 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeAvgDayConsumer_02 388.12 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeAvgDayConsumer_03 1430.09 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeAvgDayConsumer_04 233.40 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeAvgDayConsumer_05 28.80 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeAvgDayConsumer_06 37.20 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeAvgDayConsumer_07 357.53 min
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeCentralTask 0.3671
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeLastAPIAnswer -
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeLastAPIProc -
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_runTimeTrainAI 1.2766
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayBatIn_01 4090.0 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayBatOut_01 2367.0 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayConForecastTillSunset 0 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 08:59:52 special_todayConsumptionForecast_09 685 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 09:59:53 special_todayConsumptionForecast_10 824 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 10:59:51 special_todayConsumptionForecast_11 645 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 11:59:53 special_todayConsumptionForecast_12 667 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 12:59:49 special_todayConsumptionForecast_13 1069 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 13:59:52 special_todayConsumptionForecast_14 1011 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 14:59:59 special_todayConsumptionForecast_15 942 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 15:59:59 special_todayConsumptionForecast_16 860 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 16:59:58 special_todayConsumptionForecast_17 841 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 17:59:59 special_todayConsumptionForecast_18 947 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayConsumptionForecast_19 854 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayConsumptionForecast_20 781 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayConsumptionForecast_21 716 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayConsumptionForecast_22 710 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayConsumptionForecast_23 686 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayConsumptionForecast_24 597 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayDoneAPIcalls 0
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayDoneAPIrequests 4518
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayGridConsumption 233.3 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayGridFeedIn 128.0 Wh
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayMaxAPIcalls n.a.
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayRemainingAPIcalls n.a.
/opt/fhem/log/fhem.save:setstate Forecast 2025-01-03 18:52:31 special_todayRemainingAPIrequests n.a.
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_SunHours_Remain 0.00
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_SunMinutes_Remain 0
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_allStringsFullfilled 1
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_conForecastTillNextSunrise 21277 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_currentAPIinterval 0
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_dayAfterTomorrowPVforecast 4415 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_daysUntilBatteryCare_01 -
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_lastretrieval_time 2025-01-03 18:52:02
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_lastretrieval_timestamp 1735926722
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_response_message success
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_runTimeCentralTask 0.1077
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_runTimeLastAPIAnswer -
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_runTimeLastAPIProc -
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_runTimeTrainAI 0.0860
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayConForecastTillSunset 0 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 08:59:49 special_todayConsumptionForecast_09 1452 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 09:59:49 special_todayConsumptionForecast_10 1522 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 10:59:49 special_todayConsumptionForecast_11 1459 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 11:59:50 special_todayConsumptionForecast_12 1550 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 12:59:49 special_todayConsumptionForecast_13 1603 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 13:59:49 special_todayConsumptionForecast_14 1492 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 14:59:49 special_todayConsumptionForecast_15 1430 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 15:59:49 special_todayConsumptionForecast_16 1433 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 16:59:52 special_todayConsumptionForecast_17 1561 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 17:59:49 special_todayConsumptionForecast_18 1654 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayConsumptionForecast_19 1611 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayConsumptionForecast_20 1793 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayConsumptionForecast_21 1826 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayConsumptionForecast_22 1521 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayConsumptionForecast_23 1454 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayConsumptionForecast_24 1323 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayDoneAPIcalls 0
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayDoneAPIrequests 1008
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayGridConsumption 25913.0 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayGridFeedIn 58.0 Wh
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayMaxAPIcalls n.a.
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayRemainingAPIcalls n.a.
/opt/fhem/log/fhem.save:setstate Forecast_M 2025-01-03 18:52:02 special_todayRemainingAPIrequests n.a.
grep: /opt/fhem/log/eventTypes.txt: Übereinstimmungen in Binärdatei
grep: /opt/fhem/.local/lib/python3.9/site-packages/__pycache__/markdown2.cpython-39.pyc: Übereinstimmungen in Binärdatei
grep: /opt/fhem/.local/lib/python3.9/site-packages/Cryptodome/SelfTest/Protocol/__pycache__/test_KDF.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.local/lib/python3.9/site-packages/Cryptodome/SelfTest/Protocol/test_KDF.py: def test_special_case_salt(self):
grep: /opt/fhem/.local/lib/python3.9/site-packages/Crypto/SelfTest/Protocol/__pycache__/test_KDF.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.local/lib/python3.9/site-packages/Crypto/SelfTest/Protocol/test_KDF.py: def test_special_case_salt(self):
/opt/fhem/.local/lib/python3.9/site-packages/markdown2.py: text = self._unescape_special_chars(text)
/opt/fhem/.local/lib/python3.9/site-packages/markdown2.py: text = self._escape_special_chars(text)
/opt/fhem/.local/lib/python3.9/site-packages/markdown2.py: def _escape_special_chars(self, text):
/opt/fhem/.local/lib/python3.9/site-packages/markdown2.py: self._toc.append((level, id, self._unescape_special_chars(name)))
/opt/fhem/.local/lib/python3.9/site-packages/markdown2.py: self._unescape_special_chars(match.group(1)))
/opt/fhem/.local/lib/python3.9/site-packages/markdown2.py: def _unescape_special_chars(self, text):
grep: /opt/fhem/.local/lib/python3.9/site-packages/fhempy/lib/__pycache__/utils.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.local/lib/python3.9/site-packages/fhempy/lib/utils.py: return remove_special_charachters(reading)
/opt/fhem/.local/lib/python3.9/site-packages/fhempy/lib/utils.py: return remove_special_charachters(devname.replace(" ", "_").replace("-", "_"))
/opt/fhem/.local/lib/python3.9/site-packages/fhempy/lib/utils.py:def remove_special_charachters(string):
grep: /opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/__pycache__/markdown2.cpython-39.pyc: Übereinstimmungen in Binärdatei
grep: /opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/~hempy/lib/__pycache__/utils.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/~hempy/lib/utils.py: return remove_special_charachters(reading)
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/~hempy/lib/utils.py: return remove_special_charachters(
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/~hempy/lib/utils.py:def remove_special_charachters(string):
grep: /opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/pip/_internal/operations/__pycache__/prepare.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/pip/_internal/operations/prepare.py:def _copy2_ignoring_special_files(src, dest):
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/pip/_internal/operations/prepare.py: kwargs['copy_function'] = _copy2_ignoring_special_files
grep: /opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/Cryptodome/SelfTest/Protocol/__pycache__/test_KDF.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/Cryptodome/SelfTest/Protocol/test_KDF.py: def test_special_case_salt(self):
grep: /opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/Crypto/SelfTest/Protocol/__pycache__/test_KDF.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/Crypto/SelfTest/Protocol/test_KDF.py: def test_special_case_salt(self):
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/markdown2.py: text = self._unescape_special_chars(text)
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/markdown2.py: text = self._escape_special_chars(text)
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/markdown2.py: def _escape_special_chars(self, text):
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/markdown2.py: self._toc.append((level, id, self._unescape_special_chars(name)))
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/markdown2.py: self._unescape_special_chars(match.group(1)))
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/markdown2.py: def _unescape_special_chars(self, text):
grep: /opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/fhempy/lib/__pycache__/utils.cpython-39.pyc: Übereinstimmungen in Binärdatei
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/fhempy/lib/utils.py: return remove_special_charachters(reading)
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/fhempy/lib/utils.py: return remove_special_charachters(
/opt/fhem/.fhempy/fhempy_venv/lib/python3.9/site-packages/fhempy/lib/utils.py:def remove_special_charachters(string):
root@EnergyPi:/home/pi#
Das dauert dann....je nach Leistung des RPI......und deiner Datenmengen in den Unterverzeichnissen....
Gruß
300P
Danke für die Info & Erklärung.
Ich nutze DBLog und die Werte werden unter anderem in eigenen Funktionen und Notifies verarbeitet.
Wo das von statten geht ist mir (meist) bekannt.
Und da ist jetzt halt Handarbeit angesagt.
Ist ja alles machbar am Ende.
ZitatIch nutze DBLog
Dann kannst du die Readingnamen in der DB leicht mit DbRep umsetzen:
set <DbRep> readingRename <[Device:]alterReadingname>,<neuerReadingname> Damit werden alle alten Readingnamen in der Datenbank in den neuen Namen umgesetzt. Damit hast du die Historie komplett vorhanden mit neuem Readingnamen.
Zitat von: Max_Meyer am 02 Januar 2025, 18:10:09Hallo münster,
ich tippe mal - wie geschrieben benutze ich eine andere Marke - aber die Probleme sind gleich. In meinem Falle ist es auch der erste Hybrid den ich einbinde aber SMA habe ich bereits mehrere laufen.
wenn ich richtig geschaut habe ist die SE-Integration, die du nutzt, von 2022 (letzte Änderung) --> damals gabs (meines Wissens) noch keine Hybrid-WR - und somit fehlen da ggfls. einige Parameter denke ich. In dem File, auf das ich heute morgen verwiesen habe, sind alle notwendigen Register vorhanden, glaube ich - die Frage ist ob das File für dein Gerät gültig ist - ansonsten findet sich das bestimmt im SE-Supportbereich. Die Register müssten nur abgefragt werden. Ich nutze dazu 98_ModbusAttr.pm. Zur Bestimmung der 'richtigen' Register nutze ich den Quervergleich mit der Oberfläche (Webserver) des WR - da wird ja der richtige/gewünschte Wert angezeigt.
Vielen Dank Max für die Tipps!
In der Dokumentation konnte ich keine Einträge finden, aber hier sind einige Hinweise https://github.com/nmakel/solaredge_modbus/blob/master/src/solaredge_modbus/__init__.py#L663
Ich habe dem lokalen SolarEdge-Modul Code verändert, um diese Register abzufragen, aber etwas stimmt nicht mit den Werten.
Letzte Nacht habe ich 80% der Batterie verbraucht (10kWh bzw. 9623 ,,netto") und dies wären die Deltas der Werte in den Modbus-Registern:
,,Produzierte Energie (die, wie ich weiß, AC ist)": +5998
"lifetime_export_energy_counter (Akku)": +1121
Darüber hinaus habe ich nicht verstanden, wie oft diese Batteriewerte aktualisiert werden, aber der "export_energy_counter" wurde sicherlich nicht länger als eine Stunde aktualisiert, während die Batterie verwendet wurde, daher bin ich nicht sicher, ob ich sie verwenden kann.
weiter mit den Experimenten ;-)
Hallo Heiko,
seit gestern berechnet SolarForecast die PVreal Werte (stündlich und gesamt) mit konstant null ( 0 WH ). Zunächst dachte ich, der Schnee auf den Modulen sei die Ursache, aber zumindest das schneefreie Balkonkraftwerk sollte ein wenig beitragen.
Das Modul ist aktuell, an der Konfiguration habe ich bis auf das Umbenennen der statistic / special Readings nichts verändert. Betroffen sind alle meine drei Instanzen, die bis auf das Wettermodell identisch sind.
Der Plant Configuration Check ist grün - siehe Screenshot.
Ich erhalte plausible Werte für Current_PV:
2025-01-04_14:51:14 PV_forecast nextCycletime: 14:51:24
2025-01-04_14:51:14 PV_forecast Current_PV: 93 W
2025-01-04_14:51:14 PV_forecast consumer01_currentPower: 3 W
2025-01-04_14:51:14 PV_forecast Current_GridConsumption: 148 W
2025-01-04_14:51:14 PV_forecast Current_Consumption: 241 W
2025-01-04_14:51:14 PV_forecast Current_SelfConsumption: 93 W
2025-01-04_14:51:14 PV_forecast Current_AutarkyRate: 39 %
2025-01-04_14:51:14 PV_forecast special_conForecastTillNextSunrise: 7394 Wh
2025-01-04_14:51:15 PV_forecast updated
2025-01-04_14:51:24 PV_forecast nextCycletime: 14:51:34
2025-01-04_14:51:24 PV_forecast Current_PV: 92 W
2025-01-04_14:51:24 PV_forecast Current_GridConsumption: 154 W
2025-01-04_14:51:24 PV_forecast Current_Consumption: 246 W
2025-01-04_14:51:24 PV_forecast Current_SelfConsumption: 92 W
2025-01-04_14:51:24 PV_forecast Current_AutarkyRate: 37 %
2025-01-04_14:51:24 PV_forecast special_conForecastTillNextSunrise: 7393 Wh
2025-01-04_14:51:25 PV_forecast updated
2025-01-04_14:51:34 PV_forecast nextCycletime: 14:51:44
2025-01-04_14:51:34 PV_forecast Current_PV: 105 W
2025-01-04_14:51:34 PV_forecast consumer01_currentPower: 3.06 W
2025-01-04_14:51:34 PV_forecast Current_GridConsumption: 146 W
2025-01-04_14:51:34 PV_forecast Current_Consumption: 251 W
2025-01-04_14:51:34 PV_forecast Current_SelfConsumption: 105 W
2025-01-04_14:51:34 PV_forecast Current_AutarkyRate: 42 %
2025-01-04_14:51:34 PV_forecast special_conForecastTillNextSunrise: 7392 Wh
2025-01-04_14:51:35 PV_forecast updated
2025-01-04_14:51:44 PV_forecast nextCycletime: 14:51:54
2025-01-04_14:51:44 PV_forecast consumer01_currentPower: 3.05 W
2025-01-04_14:51:44 PV_forecast Current_GridConsumption: 153 W
2025-01-04_14:51:44 PV_forecast Current_Consumption: 258 W
2025-01-04_14:51:44 PV_forecast Current_AutarkyRate: 41 %
2025-01-04_14:51:44 PV_forecast special_conForecastTillNextSunrise: 7391 Wh
2025-01-04_14:51:45 PV_forecast updated
2025-01-04_14:51:54 PV_forecast nextCycletime: 14:52:04
2025-01-04_14:51:54 PV_forecast Current_PV: 101 W
2025-01-04_14:51:54 PV_forecast consumer01_currentPower: 2.98 W
2025-01-04_14:51:54 PV_forecast Current_GridConsumption: 156 W
2025-01-04_14:51:54 PV_forecast Current_Consumption: 257 W
2025-01-04_14:51:54 PV_forecast Current_SelfConsumption: 101 W
2025-01-04_14:51:54 PV_forecast Current_AutarkyRate: 39 %
2025-01-04_14:51:54 PV_forecast special_conForecastTillNextSunrise: 7390 Wh
2025-01-04_14:51:55 PV_forecast updated
Warum ist der "Producers cache" leer?
fhem> get PV_forecast valProducer
Producers cache is empty.
Im Anhang noch ein list meiner primären SolarForecast Instanz und der CSV Export für get ... pvHistory. Seit Tag 03 sind die PVreal Werte beständig 0 W.
[Edit] - ebenfalls im Anhang noch die vermutlich relevanten Zeilen mit aktiven debug collectData...
Ich bin ein wenig ratlos, wie ich den Fehler weiter eingrenzen kann und für jeden Tip dankbar.
VG Tobias
Zitat von: tpm88 am 04 Januar 2025, 15:18:10Warum ist der "Producers cache" leer?
fhem> get PV_forecast valProducer
Producers cache is empty.
Du hast offensichtlich ja keine ProducerXY, sondern InverterXY in deinem System.
Daher muss der "Producers cache" leer sein. ;) .
Nutze mal
get axaxax valInverter (oder valInverterXY)
O:-)
Gruß
300P
Zitat von: 300P am 04 Januar 2025, 16:40:49Du hast offensichtlich ja keine ProducerXY, sondern InverterXY in deinem System.
Daher muss der "Producers cache" leer sein. ;) .
Nutze mal
get axaxax valInverter (oder valInverterXY)
O:-)
Guter Punkt ;D
fhem> get PV_forecast valInverter
01 => ialias => MQTT2_gw5048em
ietotal => 11544000.0000165
ifeed => default
igeneration => 0
ilimit => 100
iname => MQTT2_gw5048em
invertercap => 4600
istrings => roofSouth,roofNorth
02 => ialias => MQTT2_hm600tm_HM600_TM
ietotal => 1010.49
ifeed => default
igeneration => 0
ilimit => 100
iname => MQTT2_hm600tm_HM600_TM
invertercap => 600
istrings => balcony
Gruß
Tobias
Hier sieht man auch den Zählerstand:
ietotal => 11544000.0000165
ifeed => default
Sorry mein erster Post ist über den Jordan gegangen, ich schreibe nochmal....
So jetzt Tobias :)
der etotal deiner Inverter wird nicht hochgezählt:
...
2025.01.04 14:47:04 1: PV_forecast DEBUG> summary data of all Inverters - pv: 126 W, this hour Generation: 0 Wh
2025.01.04 14:47:14 1: PV_forecast DEBUG> pv: 54 W, etotal: 11544000.0000165 Wh
2025.01.04 14:47:14 1: PV_forecast DEBUG> pv: 71 W, etotal: 1010.44 Wh
2025.01.04 14:47:14 1: PV_forecast DEBUG> summary data of all Inverters - pv: 125 W, this hour Generation: 0 Wh
2025.01.04 14:47:24 1: PV_forecast DEBUG> pv: 54 W, etotal: 11544000.0000165 Wh
2025.01.04 14:47:24 1: PV_forecast DEBUG> pv: 70 W, etotal: 1010.44 Wh
2025.01.04 14:47:24 1: PV_forecast DEBUG> summary data of all Inverters - pv: 124 W, this hour Generation: 0 Wh
2025.01.04 14:47:34 1: PV_forecast DEBUG> pv: 46 W, etotal: 11544000.0000165 Wh
2025.01.04 14:47:34 1: PV_forecast DEBUG> pv: 70 W, etotal: 1010.44 Wh
2025.01.04 14:47:34 1: PV_forecast DEBUG> summary data of all Inverters - pv: 116 W, this hour Generation: 0 Wh
2025.01.04 14:47:44 1: PV_forecast DEBUG> pv: 46 W, etotal: 11544000.0000165 Wh
2025.01.04 14:47:44 1: PV_forecast DEBUG> pv: 70 W, etotal: 1010.44 Wh
2025.01.04 14:47:44 1: PV_forecast DEBUG> summary data of all Inverters - pv: 116 W, this hour Generation: 0 Wh
2025.01.04 14:47:54 1: PV_forecast DEBUG> pv: 43 W, etotal: 11544000.0000165 Wh
2025.01.04 14:47:54 1: PV_forecast DEBUG> pv: 70 W, etotal: 1010.44 Wh
...
Vermutlich liefern die Quellen Readings immer den gleichen Wert. Dadurch ist keine Erzeugung erkennbar.
Du müsstest den Stand der Quellen mit dem Stand im Modul (get ... valInverter) vergleichen.
LG
Dann noch etwas
setupInverterDev01 MQTT2_gw5048em pv=P_PV:W etotal=P_PV_Total_ALL:kWh capacity=4600 strings=roofSouth,roofNorth
setupInverterDev02 MQTT2_hm600tm_HM600_TM pv=P_AC:W etotal=YieldTotal:W capacity=600 strings=balcony
Das etotal=YieldTotal vom MQTT2_hm600tm_HM600_TM müssen Wh oder kWh und nicht W sein.
Beim MQTT2_gw5048em sind die etotal kWh. Bei der gegenwärtigen sehr geringen PV Ausbeute könnte es sein dass der Zähler im MQTT2_gw5048em erst nach längeren Zeitintervallen aktualisiert und dadurch das Gap entsteht.
Hallo Heiko,
Zitat von: DS_Starter am 04 Januar 2025, 17:15:52Dann noch etwas
setupInverterDev01 MQTT2_gw5048em pv=P_PV:W etotal=P_PV_Total_ALL:kWh capacity=4600 strings=roofSouth,roofNorth
setupInverterDev02 MQTT2_hm600tm_HM600_TM pv=P_AC:W etotal=YieldTotal:W capacity=600 strings=balcony
Das etotal=YieldTotal vom MQTT2_hm600tm_HM600_TM müssen Wh oder kWh und nicht W sein.
Beim MQTT2_gw5048em sind die etotal kWh. Bei der gegenwärtigen sehr geringen PV Ausbeute könnte es sein dass der Zähler im MQTT2_gw5048em erst nach längeren Zeitintervallen aktualisiert und dadurch das Gap entsteht.
Danke, Heiko. Ich denke tatsächlich, daß ein Doppelfehler bei mir drin ist/war:
Den Fehler in der setupInverterDev02 mit der falschen Einheit W für etotal habe ich auch eben gefunden und auf kWh korrigiert. Das war somit bereits seit dem Split auf zwei Inverter Devices drin.
setupInverterDev02 MQTT2_hm600tm_HM600_TM pv=P_AC:W etotal=YieldTotal:kWh capacity=600 strings=balcony
2025.01.04 17:12:34 1: PV_forecast DEBUG> summary data of all Inverters - pv: 0 W, this hour Generation: 0 Wh
2025.01.04 17:12:44 1: PV_forecast DEBUG> pv: 0 W, etotal: 11544000.0000165 Wh
2025.01.04 17:12:44 1: PV_forecast DEBUG> pv: 0 W, etotal: 1010490 Wh
2025.01.04 17:12:44 1: PV_forecast DEBUG> summary data of all Inverters - pv: 0 W, this hour Generation: 1009479 Wh
2025.01.04 17:12:54 1: PV_forecast DEBUG> pv: 0 W, etotal: 11544000.0000165 Wh
2025.01.04 17:12:54 1: PV_forecast DEBUG> pv: 0 W, etotal: 1010490 Wh
2025.01.04 17:12:54 1: PV_forecast DEBUG> summary data of all Inverters - pv: 0 W, this hour Generation: 0 Wh
2025.01.04 17:13:04 1: PV_forecast DEBUG> pv: 0 W, etotal: 11544000.0000165 Wh
2025.01.04 17:13:04 1: PV_forecast DEBUG> pv: 0 W, etotal: 1010490 Wh
Die Hauptanlage auf dem Dach (setupInverterDev01) hat tatsächlich seit vorgestern das Reading, aus dem etotal abgeleitet wird, nicht mehr geändert:
2025-01-02_13:05:07 MQTT2_gw5048em P_PV_Total_ALL: 11543.8000000165
2025-01-02_13:38:07 MQTT2_gw5048em P_PV_Total_ALL: 11543.9000000165
2025-01-02_14:17:47 MQTT2_gw5048em P_PV_Total_ALL: 11544.0000000165
Das könnte am Schnee liegen, da muß ich nochmal genau hinschauen.
Vielen Dank für's "Mitdenken" und natürlich überhaupt für das geniale Modul.
VG
Tobias
Zitat von: DS_Starter am 02 Januar 2025, 17:25:11@minierm,
Zitatwäre es nicht sinnvoll, die bisherigen Readings als Gesamtsumme zu behalten? (Nicht SoC, aber alles mit Watt)
Das betrifft m.M. nach nur die Readings Current_PowerBatIn_XX und Current_PowerBatOut_XX.
Beide Varianten (getrennt vs. gemeinsamer Wert aller Batterien) hat seine Vor- und Nachteile.
Der Vorteil der Trennung ist zunächst der genauere Blick darauf was momentan mit der Bat passiert, ob z.B. eventuelle Steuerungsmaßnahmen den Erfolg bringen der beabsichtigt ist. Auch kann man später in der Grafik diskrete Werte mit darstellen.
Der Nachteil ist ein Paar Readings mehr bzw. wenn man eine Summe möchte muß man die erst erstellen.
Welchen Vorteil würdest du in der Gesamtsumme sehen?
Erstens könnte man die Readings weiter verwenden (kein Breaking Change),
zweitens muss man nicht selber ein Summenreading erstellen.
Den ersten Punkt setzt Du jetzt zwar als Spezial Reading um, aber geschenkt, der zweite Punkt ist ja erfüllt.
Es ist toll, wie engagiert und schnell Du Sachen umsetzt! Bei Breaking Changes - vor allem nicht zwingend notwendigen - hast Du ja mitbekommen, was eine schnelle Umsetzung für Aufregung verursachen kann. Leider gibt es auch keinen guten Mechanismus, um im Modul selbst darüber zu informieren (Warnung bei der Anlagenkonfiguration?)
LG Michael
Zitat von: DS_Starter am 02 Januar 2025, 17:25:11@minierm,
Zitatwäre es nicht sinnvoll, die bisherigen Readings als Gesamtsumme zu behalten? (Nicht SoC, aber alles mit Watt)
Das betrifft m.M. nach nur die Readings Current_PowerBatIn_XX und Current_PowerBatOut_XX.
Hm, eigentlich alle summierbaren Werte im Sinne einer Gesamtübersicht:
* Current_BatCharge -> Current_BatCharge_XX
* Current_PowerBatOut -> Current_PowerBatOut_XX
* Current_PowerBatIn -> Current_PowerBatIn_XX
* Today_HourXX_BatIn -> Today_HourXX_BatIn_XX
* Today_HourXX_BatOut -> Today_HourXX_BatOut_XX
Disclaimer: Ich habe nur einen Speicher
Btw: Die Benennung ist etwas inkonsistent:
* Current_BatCharge vs Current_PowerBatOut und Today_HourXX_BatOut
Kommt "Bat" jetzt zuerst oder zum Schluß? Mit oder ohne Power?
-> Current_BatPowerOut und Today_HourXX_BatPowerOut
(analog für In)
Ich hab da noch eine Anmerkung zur Anlagenkonfigurationsprüfung :-)
Common Settings
The AI support is not used.
erfüllt
The selected SolarForecast Model cannot use AI support.
Your local 76_SolarForecast module is up to date.
checked module:
76_SolarForecast
Wenn das verwendete Modul AI nicht unterstützt ist klar das AI nicht verwendet wird. Und welches Modul wird denn verwendet? Könnte man noch erwähnen (Bei mir: SolCastAPI). Und wie man AI aktiviert (Welches Attribut).
Weather Properties
The device "DWD1_Ulm" uses "MOSMIX_L" which is only updated by DWD every 6 hours.
erfüllt (Attribut: setupWeatherDev1)
checked parameters and attributes of device "DWD1_Ulm":
forecastProperties -> TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet
forecastRefresh -> set attribute to below "6" if possible
Ich habe kein Attribut forecastRefresh, nur forecastResolution ("Time resolution (number of hours between 2 samples)." mit dem Wert "1".
Zitat von: cpet am 02 Januar 2025, 16:36:54ändere mal das "pv=PVALL:kW" in "pv=PVALL:W" ab
Gruß
Christian
Gute Idee, seh ich aber nicht, Tageswerte immer in Watt, Einheit Gesamtwert dynamisch, Daten nach einem Jahr:
Strom_PV_All_Aktuell
Userreading:
PV_Total monotonic {my $Val = ReadingsNum("MTEC_Station", "data_eRatioGraph_edayTotal", 0);; if (ReadingsVal("MTEC_Station", "data_config_01_unit", 0) eq "kWh") {$Val} else {$Val/1000}}
PV_Total 14403.4
MTEC_Station:
data_config_01_key eTotal
data_config_01_unit kWh
data_eRatioGraph_eDayTotal 14072
data_curve_02_eTotal 10749.7 # Gesamterzeugung
BKW_Total 381.4
Mag sein, daß es in der Anfangs-/Übergangszeit Probleme mit der Einheit gab und deshalb die Summe nicht passt.
Tipp:
Wer den alten Wert "Current_BatCharge" (als Summe für alle Ladestati der vorhandenen Batterien) auch zukünftig weiter nutzen möchte:
Legt euch dann selbst ein eigenes (User)reading an O:-)
(ausgehend davon das es wohl max 3 X CurrentBatCharge_XX geben werden wird)
Für 1 Batterie (mehr gehen aktuell noch nicht)
attr XYXYXYXYXY userReadings Current_BatCharge { ((ReadingsNum($name,"Current_BatCharge_01",0)))/1 }
Zukünftig...
Für 2 Batterien
attr X-2Batterien-X userReadings Current_BatCharge { ((ReadingsNum($name,"Current_BatCharge_01",0)) + (ReadingsNum($name,"Current_BatCharge_02",0)))/2 }
Für 3 Batterien
attr X-2Batterien-X userReadings Current_BatCharge { ((ReadingsNum($name,"Current_BatCharge_01",0)) + (ReadingsNum($name,"Current_BatCharge_02",0)) + (ReadingsNum($name,"Current_BatCharge_03",0)))/3 }
Gruß
300P
Hallo Michael,
ZitatEs ist toll, wie engagiert und schnell Du Sachen umsetzt! Bei Breaking Changes - vor allem nicht zwingend notwendigen - hast Du ja mitbekommen, was eine schnelle Umsetzung für Aufregung verursachen kann. Leider gibt es auch keinen guten Mechanismus, um im Modul selbst darüber zu informieren (Warnung bei der Anlagenkonfiguration?)
Ich mache den "Job" hier schon viele Jahre und weiß um die Stolperfallen, gerade bei Umbenennung von Readings.
Manchmal muß ich den Schmerz bzw. Shitstorm einfach mal ertragen und eine Änderung machen die ich nicht ständig weiter mitschleppe, zuviel liegt noch vor mir. Und, wie gesagt, ich mache ja hier alles im Vorfeld und auch im Update-Text transparent. ;)
ZitatHm, eigentlich alle summierbaren Werte im Sinne einer Gesamtübersicht:
* Current_BatCharge -> Current_BatCharge_XX
* Current_PowerBatOut -> Current_PowerBatOut_XX
* Current_PowerBatIn -> Current_PowerBatIn_XX
* Today_HourXX_BatIn -> Today_HourXX_BatIn_XX
* Today_HourXX_BatOut -> Today_HourXX_BatOut_XX
Wenn es den Bedarf gibt, kann ich diese Summen über die jetzigen special_-Readings problemlos bereitstellen.
Das mache ich aber erst wenn sich jemand mit dem Wunsch meldet. Die Implementierung ist dann aber recht zügig erledigt. Mache ich gerne bei Bedarf.
ZitatBtw: Die Benennung ist etwas inkonsistent:
* Current_BatCharge vs Current_PowerBatOut und Today_HourXX_BatOut
Kommt "Bat" jetzt zuerst oder zum Schluß? Mit oder ohne Power?
-> Current_BatPowerOut und Today_HourXX_BatPowerOut
(analog für In)
Da gibt es sicherlich Dinge die man nach den Jahren der Entwicklung angleichen könnte.
Allerdings ist Current_BatPowerOut und Today_HourXX_BatPowerOut genau richtig. Hier liegt der Sinn darin den gesamten Block der Today_HourXX_.*-Readings nach Stunden sortiert in der Detailansicht zu haben.
Diese Sortierung ist ein erhebliches Kriterium für die Bennennung -> hilft bei der Übersicht bei so vielen Readings.
ZitatWenn das verwendete Modul AI nicht unterstützt ist klar das AI nicht verwendet wird. Und welches Modul wird denn verwendet? Könnte man noch erwähnen (Bei mir: SolCastAPI). Und wie man AI aktiviert (Welches Attribut).
Nicht "Modul" sondern "Model".
Welches Model aktuell verwendet wird steht im Kopf/Überschrift der Prüfung, z.B. "Informationen zur Anlagenkonfigurationsprüfung - Model: DWD"
Ob man AI-Unterstützung verwenden kann hängt vom Model ab und wird bei einem entsprechend verwendeten Model im Setter pvCorrectionFactor_Auto angeboten.
Da kann ich höchstens mal auf das Wiki verweisen wenn ich soweit bin es beschrieben zu haben.
ZitatIch habe kein Attribut forecastRefresh, nur forecastResolution ("Time resolution (number of hours between 2 samples)." mit dem Wert "1".
Nimm das DWD-Modul aus meinem contrib. Leider wurde diese Weiterentwicklung vom DWD Maintainer bisher nicht eingecheckt obwohl sie bereits schon sicherlich 9 Monate bereit steht und aktiv genutzt wird.
Sehr ärgerlich...
Wenn du etwas mehr dazu lesen möchtest wäre wahrscheinlich hier (https://forum.fhem.de/index.php?msg=1307956) ein passender Aufsetzpunkt.
LG,
Heiko
@300P
Zitat(ausgehend davon das es wohl max 3 X CurrentBatCharge_XX geben werden wird)
Wie kommst du darauf? ;D
glaskugel.gif
:)
Bei den XX-Geräten gehe ich im Ansatz tatsächlich mit dem Startwert "3" in die Konfiguration, da ich glaube dass er meistens reichen wird.
Der Wert kann bei Bedarf aber angepasst werden ... nur zur Erläuterung.
Userreadings sind "sehr geduldig"... ;)
Das Multi Batterie System wird übrigens in Kürze verfügbar sein denke ich. Habe heute den ganzen Tag weiter daran gearbeitet und getestet.
Wenn alles klappt, kann man sich die Stunden mit dem zukünftigen "Battery_ChargeRecommended" - Wert in der Grafik einblenden. Dann hat man einen Überblick wann das System diese Empfehlung geben wird. Ich denke das hilft ein gewisses Gefühl der Sicherheit, der Transparenz und des Vertrauens in die Entscheidungen zu bekommen.
Hallo Heiko,
vorweg danke für das tolle Modul 8)
Jetzt zum "Problem". Seit dem letzten update wird hier wohl nicht mehr gerundet. Kann man das irgendwo einstellen, oder kommt da noch eine Anpassung. Anbei die Grafik mit Markierung.
VG Tom
In meiner ConfigDB fand ich eine große Zahl (~500~) Dateien der Art './FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau.*'
Eine Durchsicht der Attribute zeigte mir keine Option etwas einzustellen, zum Beispiel eine Haltezeit.
- Wofür dienen diese Dateien?
- Kann ich die unbesorgt löschen, ohne z.B. das AI-Lernen zu beschädigen?
- Vielen Dank für zweckdienliche Antwort im
Voraus
Christian
ctrlBackupFilesKeep? Haben die Dateien ein Datum am Ende des Namens?
@Tom,
ZitatJetzt zum "Problem". Seit dem letzten update wird hier wohl nicht mehr gerundet. Kann man das irgendwo einstellen, oder kommt da noch eine Anpassung. Anbei die Grafik mit Markierung.
Ja, das kann sein. Danke für die Info. Ist bei mir nicht aufgefallen. Richte ich mit der kommenden Version.
@Christian,
ZitatWofür dienen diese Dateien?
Das ist die Sicherung des internen Ringspeichers. Siehe Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Backup_und_Wiederherstellung_der_Moduldaten). Die Datei ist sehr wertvoll für die Funktion, besonders je länger die Laufzeit des Moduls ist.
Es sollte immer ein zeitnahes Backup vorhanden sein.
ZitatKann ich die unbesorgt löschen, ohne z.B. das AI-Lernen zu beschädigen?
Zumindest ältere Dateien kannst du löschen. Die Datei wird regelmäßig neu geschrieben. Von einer aktuellen Version sollte es immer ein Backup geben.
Wie kask schon erwähnt hat, gibt es auch Sicherungen der Sicherungsdateien um ältere Versionen wieder herstellen zu können.
Das erwähnte ctrlBackupFilesKeep (Anzahl der Sicherungsdatei-Sicherungen) wird vermutlich nicht für configDB funktionieren weil hier über die Verzeichnisebene gearbeitet wird.
Möglicherweise gibt es in configDB eine Einstellung um die max. Anzahl der in der DB gespeicherten Versionen einer Datei festzulegen. Kann ich aber nicht sagen.
LG,
Heiko
Danke für die schnellen Antworten:
@kask: Dieses CTRL habe ich nicht angerührt - es heißt in der CommandRef ja, dass der Default 3 sei. Heißt ich hätte erwartet, dass wenn diese Dateien durch da erwähnte und entsprechend eingestellte set <name> operatingMemory backup entstehen, nur drei existieren sollten.
@DS_Starter: Die Dateien tragen den Zeitstempel kurz nach Mitternacht: Hier Beispiele für die jüngsten:
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_25_00_09_23
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_26_00_09_01
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_27_00_09_51
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_28_00_09_21
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_29_00_10_00
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_30_00_09_40
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_31_00_09_40
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_01_00_09_20
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_02_00_09_41
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_03_00_09_50
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_04_00_09_59
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_05_00_10_01
Ich werde jetzt mal das Attribut ctrlBackupFilesKeep jetzt mal auf 5 setzen und dann beobachten, ob sich etwas ändert.
Christian
Das sind die Sicherungsdatei-Sicherungen, erkennbar an dem Zeitstempel am Ende des Namens. Sie werden kurz nach Mitternacht geschrieben.
Wie vermutet wird ctrlBackupFilesKeep bei configDB nicht funktionieren, d.h. auch der default 3 nicht.
Das SF Modul kann nicht (und will auch nicht) in configDB "hineingreifen".
In einem Filesystem würden per default nur dieses Dateien für ein mögl. Restore übrigbleiben:
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_03_00_09_50
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_04_00_09_59
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_05_00_10_01
Da es sich immer um eine unikate Datei handelt, wird configDB vermutlich kein automatisches Housekeeping anbieten.
Abhilfe könnte sein, dass ich für Nutzer von configDB diese regelmäßigen Sicherungsdatei-Sicherungen nicht erstellen lasse da eine Versionierung von PVC_SolarForecast_SolarVorschau bereits durch configDB gegeben ist?
Vermutlich hast du auch keine Auswahlliste beim Befehl:
set ... operatingMemory recover-PVC....
?
Ggf. hast du als configDB eigene Housekeeping Möglichkeiten um alte Versionen automatisch zu löschen?
Zitat von: DS_Starter am 04 Januar 2025, 23:44:38Ich mache den "Job" hier schon viele Jahre und weiß um die Stolperfallen, gerade bei Umbenennung von Readings.
Manchmal muß ich den Schmerz bzw. Shitstorm einfach mal ertragen und eine Änderung machen die ich nicht ständig weiter mitschleppe, zuviel liegt noch vor mir. Und, wie gesagt, ich mache ja hier alles im Vorfeld und auch im Update-Text transparent. ;)
Wer liest schon Update-Texte ;-)
Ja, du kommunizierst die Änderungen hier sehr transparent. Man muss halt nur am Ball bleiben.
Zitat von: DS_Starter am 04 Januar 2025, 23:44:38ZitatHm, eigentlich alle summierbaren Werte im Sinne einer Gesamtübersicht:
* Current_BatCharge -> Current_BatCharge_XX
* Current_PowerBatOut -> Current_PowerBatOut_XX
* Current_PowerBatIn -> Current_PowerBatIn_XX
* Today_HourXX_BatIn -> Today_HourXX_BatIn_XX
* Today_HourXX_BatOut -> Today_HourXX_BatOut_XX
Wenn es den Bedarf gibt, kann ich diese Summen über die jetzigen special_-Readings problemlos bereitstellen.
Das mache ich aber erst wenn sich jemand mit dem Wunsch meldet. Die Implementierung ist dann aber recht zügig erledigt. Mache ich gerne bei Bedarf.
Bevor sich da groß Bedarf meldet werden die bedürtigen User doch schnell eigene Userreadings erstellt haben...
Zitat von: DS_Starter am 04 Januar 2025, 23:44:38ZitatBtw: Die Benennung ist etwas inkonsistent:
* Current_BatCharge vs Current_PowerBatOut und Today_HourXX_BatOut
Kommt "Bat" jetzt zuerst oder zum Schluß? Mit oder ohne Power?
-> Current_BatPowerOut und Today_HourXX_BatPowerOut
(analog für In)
Da gibt es sicherlich Dinge die man nach den Jahren der Entwicklung angleichen könnte.
Allerdings ist Current_BatPowerOut und Today_HourXX_BatPowerOut genau richtig. Hier liegt der Sinn darin den gesamten Block der Today_HourXX_.*-Readings nach Stunden sortiert in der Detailansicht zu haben.
Diese Sortierung ist ein erhebliches Kriterium für die Bennennung -> hilft bei der Übersicht bei so vielen Readings.
Vorsicht, es ging nur um den hinteren Teil mit "PowerBatOut" und "BatOut" in konsistent "BatPowerOut": <Device><Type><Direction>.
Du hast es ja schon selber richtig geschrieben :-)
Zitat von: DS_Starter am 04 Januar 2025, 23:44:38ZitatWenn das verwendete Modul AI nicht unterstützt ist klar das AI nicht verwendet wird. Und welches Modul wird denn verwendet? Könnte man noch erwähnen (Bei mir: SolCastAPI). Und wie man AI aktiviert (Welches Attribut).
Nicht "Modul" sondern "Model".
Welches Model aktuell verwendet wird steht im Kopf/Überschrift der Prüfung, z.B. "Informationen zur Anlagenkonfigurationsprüfung - Model: DWD"
Ob man AI-Unterstützung verwenden kann hängt vom Model ab und wird bei einem entsprechend verwendeten Model im Setter pvCorrectionFactor_Auto angeboten.
Da kann ich höchstens mal auf das Wiki verweisen wenn ich soweit bin es beschrieben zu haben.
Ja Model (SolCastAPI), in dem Hinweistext steht aber mehr "Modul" ;-)
Der Titel ist da schon soweit weg, aber passt.
Ein Link darauf, wie man auf einen Hinweis reagieren kann, wär schon toll.
Zitat von: DS_Starter am 04 Januar 2025, 23:44:38ZitatIch habe kein Attribut forecastRefresh, nur forecastResolution ("Time resolution (number of hours between 2 samples)." mit dem Wert "1".
Nimm das DWD-Modul aus meinem contrib. Leider wurde diese Weiterentwicklung vom DWD Maintainer bisher nicht eingecheckt obwohl sie bereits schon sicherlich 9 Monate bereit steht und aktiv genutzt wird.
Sehr ärgerlich...
Wenn du etwas mehr dazu lesen möchtest wäre wahrscheinlich hier (https://forum.fhem.de/index.php?msg=1307956) ein passender Aufsetzpunkt.
[/quote]
Danke, werde ich machen. Ich hab mir zum Glück im Kommentar gemerkt, wie man Contrib einbindet ;-)
("wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm") - hat funktioniert, aufgrund der SD-Card Warnung werd ich MOSMIX S wohl nicht aktivieren.
Es ist aber unglücklich, auf nicht offizielle Contribs zu verweisen. Typisches FOSS Problem mit der Maintenance :-(
LG Michael
(Norddeutscher in der Nebel- und Sonnenhauptstadt Ulm, wie man an DWDUlm erraten konnte)
ZitatVorsicht, es ging nur um den hinteren Teil mit "PowerBatOut" und "BatOut" in konsistent "BatPowerOut": <Device><Type><Direction>.
Du hast es ja schon selber richtig geschrieben :-)
Ah ok, verstehe :)
ZitatJa Model (SolCastAPI), in dem Hinweistext steht aber mehr "Modul" ;-)
Hilf mir mal bitte, wo? Hab Tomaten auf den Augen und sehe es nicht.
Einen Hinweislink baue ich gern zum Wiki ein wenn ich einen passenden Abschnitt erstellt habe.
Muß nur daran denken. ;) Gerne mal erinnern.
ZitatEs ist aber unglücklich, auf nicht offizielle Contribs zu verweisen. Typisches FOSS Problem mit der Maintenance :-(
Bin ich auch nicht glücklich damit und hätte auch nie gedacht, dass es sich so zieht, zumal es fertig ist und nur noch eingecheckt werden muß. Jens hatte seinerzeit auf meine Nachfrage hin versichert er kümmert sich wieder darum. Das ist aber auch schon wieder Monate her.
Zwischenzeitlich hatte ich auch schon daran gedacht die relevanten Parts direkt ins Modul zu holen. Dann bräuchte es kein externes Device mehr.
Es ist aber ein gutes Beispiel dafür was passieren kann wenn man Funktionen "aufspaltet". Die Diskussion hatten wir schon öfter. Das macht dann u.U. keinen Spaß mehr und hindert mehr als es nutzt.
LG
Zitat von: DS_Starter am 05 Januar 2025, 16:07:44ZitatJa Model (SolCastAPI), in dem Hinweistext steht aber mehr "Modul" ;-)
Hilf mir mal bitte, wo? Hab Tomaten auf den Augen und sehe es nicht.
Einen Hinweislink baue ich gern zum Wiki ein wenn ich einen passenden Abschnitt erstellt habe.
Muß nur daran denken. ;) Gerne mal erinnern.
Ich meinte nur: Man (ich) sieht das Model vor lauter Modulen nicht ;-) "Module" ist irgendwie hängen geblieben.
ZitatThe selected SolarForecast Model cannot use AI support.
Your local 76_SolarForecast module is up to date.
checked module:
Hallo zusammen,
in meinem contrib liegt die Version 1.42.0.
Was ist neu bzw. umgesetzt:
- es können mit den Attributen setupBatteryDevXX bis zu 3 Batteriegeräte definiert werden.
- für die Optimierung der Bats gibt es ctrlBatSocManagement01 - 03
- die Batterien bzw. deren Ladungsempfehlungs-Status für die kommenden Stunden können in der
Balkengrafik Ebene 1 eingeblendet werden. Ein Mouse-Over zeigt nähere Informationen zum Batteriestatus.
- Zur grafischen Steuerung der Batterien gibt es nun zusätzliche optionale Schlüssel und den setupBatteryDevXX Attributen
icon=<inaktiv>[@<Farbe>][:<aufladen>[@<Farbe>]][:<entladen>[@<Farbe>]]] icon Icon zur Darstellung der Batterie in der Balkengrafik (optional)
<inaktiv> - Icon und ggf. Farbe bei Inaktivität (kein Aufladen oder Entladen)
<aufladen> - Icon und ggf. Farbe wenn die Batterie aufgeladen wird
<entladen> - Icon und ggf. Farbe wenn die Batterie entladen wird
[show=<Option>]show Steuerung der Anzeige der Batterie in der Balkengrafik (optional)
0 - keine Anzeige des Gerätes (default)
1 - Anzeige des Gerätes
zum Beispiel:
show=1
icon=measure_battery_50@grey:measure_battery_100@green:measure_battery_100@red
Die Angaben sind optional, es gibt default Voreinstellungen.
- das Rundungsproblem des BatOut-Wertes in der Flowgrafik ist beseitigt (#1508)
ToDos: Offen ist noch die Implementierung von Infos zu mehreren Batterien in der Flowgrafik. Stand jetzt wird der dargestellte SOC als Durchschnitt aller definierten Batteren bzw. deren SOC's gebildet. Das wird wohl auch so bleiben. Allerdings will ich noch die separaten Werte der Einzelbatterien irgendwie in der Grafik unterbringen.
Wie immer nach dem Download aus dem contrib
FHEM restarten.
LG,
Heiko
Sehr cool, habs gleich mal umgesetzt ...
Danke Heiko ...
Mir ist gerade noch die Idee gekommen das Icon der aktuellen Stunde entsprechend des SOC dynamisch zu gestalten. Da gibt es ja im Fundus einige Abstufungen. Kommt dann noch mit rein.
Wow, dass das Multi-BAT-Features so schnell kommen würden, hätte ich nicht gedacht. Toll!
Eine Sache bereitet mit aber Kopfschmerzen:
Zitat von: DS_Starter am 05 Januar 2025, 23:30:51...
Stand jetzt wird der dargestellte SOC als Durchschnitt aller definierten Batteren bzw. deren SOC's gebildet. Das wird wohl auch so bleiben.
Einen ungewichteten SOC-Durchschnittswert zu bilden, ist inhaltlich sehr problematisch! Du müsstest schon einen Gesamt-SOC unter Berücksichtigung der Einzelkapazitäten der einzelnen BAT-Systeme bilden, die ja durchaus unterschiedlich sein können.
Nochmals vielen Dank. Dann warst Du ja von Anfang an auf der richtigen Spur. Auch Deine Vermutung ist richtig, dass configdb über seine Housekeeping-Funktion (reorg) diese Dateien nicht abräumt, weil sie alle unique sind, einmal entstehen und dann ja nicht mehr geändert werden.
Zitat von: DS_Starter am 05 Januar 2025, 14:37:16Das sind die Sicherungsdatei-Sicherungen, erkennbar an dem Zeitstempel am Ende des Namens. Sie werden kurz nach Mitternacht geschrieben.
Ggf. hast du als configDB eigene Housekeeping Möglichkeiten um alte Versionen automatisch zu löschen?
Da werde ich mir wohl einen kleinen Housekeeper bauen müssen, dazu werde ich noch lernen müssen, ob und wie man bei configdb im filedelete-Dialog Joker einsetzt.
Christian
Moin,
@Parallix,
ZitatEinen ungewichteten SOC-Durchschnittswert zu bilden, ist inhaltlich sehr problematisch! Du müsstest schon einen Gesamt-SOC unter Berücksichtigung der Einzelkapazitäten der einzelnen BAT-Systeme bilden, die ja durchaus unterschiedlich sein können.
Für die diversen Kalkulationen wie SOC-Steuerung und Ladeempfehlung wird das auch gemacht. Ich ergänze im Wiki noch etwas zu dem Wichtungsverfahren.
Der Hinweis war lediglich auf die Anzeige in der Flowgrafik bezogen, weil mir noch kein guter Ansatz eingefallen ist X Batterien als Block darzustellen. Wenn mir keine weitere Idee kommt, werde ich wohl ein Textfeld mit den Einzelwerten der Batterien einblenden. Dann sieht man wie sich der Grafikwert zusammensetzt.
@Christian,
in die Hilfe zum Attr ctrlBackupFilesKeep schreibe ich einen Hinweis für configDB User.
Zitat von: DS_Starter am 06 Januar 2025, 09:16:20...
Der Hinweis war lediglich auf die Anzeige in der Flowgrafik bezogen, weil mir noch kein guter eingefallen ist X Batterien als Block darzustellen. Wenn mir keine weitere Idee kommt, werde ich wohl ein Textfeld mit den Einzelwerten der Batterien einblenden. Dann sieht man wie sich der Grafikwert zusammensetzt.
...
Normalerweise würde man so etwas ja als (Teil-)Baum darstellen. Das gesamte Gebilde setzt sich zusammen aus einzelnen Teilbäumen, es wäre also ein allgemeiner Graph. Letzterer entsteht dadurch, dass man rechts an den bisherigen BAT-Knoten (der nunmehr zum Summenknoten würde) die einzelnen BAT-Systeme anpflanscht. Dann wären alle Infos in einer Grafik, ohne diese zu überfrachten.
ZitatLetzterer entsteht dadurch, dass man rechts an den bisherigen BAT-Knoten (der jetzt ein Summenknoten wäre) die einzelnen BAT-Systeme anpflanscht. Dann wären alle Infos in einer Grafik, ohne diese zu überfrachten.
Im Prinzip eine gute Idee die ich auch schon hatte.
Allerdings gibt es in unserem Setup die Möglichkeit Smartloader, Geräte die eine Batterie direkt laden, zu integrieren.
Diese Geräte hätten einen direkten Bezug zu einer oder mehreren Batterien was wiederum bedeuten würde Schlüssel für die Beziehungen von Smartloader und spezifischer Batterie einzuführen und abzubilden.
Deswegen ist eine Blockdarstellung besser geeignet.
Vllt. bekomme ich es noch irgendwie hin einen Block zu erstelle wo man innen drin die Einzelbatterie mit ihren Werten sieht.
Wer Lust und Laune hat, kann sich daran gern mal versuchen.
Edit: Aber dein Hinweis zu einem Summenknoten (wie bei den Invertern) ist vllt. ein guter Weg. D.h. die jetzige Batterie würde zu einem Summenknoten werden, in den alle Zu/Abflüsse münden. Die einzelnen Batterien würden als Äste an den Knoten angesetzt und in/out vom/zum Knoten könnten dargestellt werden.
Zitat von: DS_Starter am 06 Januar 2025, 09:57:32...
Allerdings gibt es in unserem Setup die Möglichkeit Smartloader, Geräte die eine Batterie direkt laden, zu integrieren.
Diese Geräte hätten einen direkten Bezug zu einer oder mehreren Batterien was wiederum bedeuten würde Schlüssel für die Beziehungen von Smartloader und spezifischer Batterie einzuführen und abzubilden.
Wenn es von den Smartloadern eigenständige Verbindungen zu einem oder mehreren BAT-Systemen gibt, die nicht über den Wechselrichter laufen (der bislang als solcher leider noch nicht Bestandteil der Grafik ist), so könnte man die Smartloader dann doch noch von rechts von den einzelnen BAT-Systemen platzieren? Horizontal ist doch (noch) relativ viel Platz, oder?
Wenn nur die SOC-Werte der einzelnen BAT-Systeme in einen Mega-Knoten zu sehen wären, dann fehlen meines Erachten wichtige Informationen, z.B. die Info, welche BAT tatsächlich gerade wie viel liefert oder wie stark geladen wird.
PS: Bin heute den ganzen Tag weg. Mache mich morgen aber gerne mal daran, meine Vorschläge zu bebildern.
Anbei siehst du ein produktives Beispiel von mir mit einem Samrtloader.
Das wird alles schon sortiert aufgebaut.
An den Platz der jetzigen Batterie würde wieder ein Summenknoten wie bei den Invertern/Producern kommen und die Batterie(n) als Verästelung nach rechts rücken und auf den neuen Knoten arbeiten.
Damit wäre alles konsistent und auch gut managebar abgebildet.
ZitatWenn nur die SOC-Werte der einzelnen BAT-Systeme in einen Mega-Knoten zu sehen wären, dann fehlen meines Erachten wichtige Informationen, z.B. die Info, welche BAT tatsächlich gerade wie viel liefert oder wie stark geladen wird.
Solche aufgeschlüsselten Infos können daneben stehen, muß ja nicht nur der Average SOC sein. Wäre kein Problem.
Zitat von: DS_Starter am 06 Januar 2025, 10:10:51Anbei siehst du ein produktives Beispiel von mir mit einem Samrtloader.
Das wird alles schon sortiert aufgebaut.
An den Platz der jetzigen Batterie würde wieder ein Summenknoten wie bei den Invertern/Producern kommen und die Batterie(n) als Verästelung nach rechts rücken und auf den neuen Knoten arbeiten.
Damit wäre alles konsistent und auch gut managebar abgebildet.
Klingt gut!
Was aber immer noch etwas stört ist, dass BAT-Systeme, die DC-gekoppelt sind, ja über den WR laufen, in der Grafik aber eigentlich nicht korrekt abgebildet werden. Durch einem Anbringen von Pfeilen an die (Flow-)Kanten könnte man dieses Manko aber relativ einfach beseitigen. Dann gäbe es auch bei o.g. DC-Anbildung der BATs keine Kante(n) mehr von den BAT-Systemen zum Haus.
@all,
ich habe die V in meinem contrib upgedated.
Neben ein paar kleineren Fixes ist es nun möglich die Farbgebung der Standard Icons für die Batteriedarstellung persönlich anzupassen, d.h. ohne Angabe eines definierten Icons.
Also etwa diese Notation:
icon=@#ace600:@yellow:@red oder
icon=:::@#4d4d4d
Es ist auch möglich (Icon) und/oder Farbe für "keine Ladeempfehlung" anzupassen:
[[icon=<empfohlen>@<Farbe>]:[<aufladen>@<Farbe>]:[<entladen>@<Farbe>]:[icon=<unterlassen>@<Farbe>]]
icon Icon und/oder (nur) Farbe zur Darstellung der Batterie in der Balkengrafik (optional)
Die Farbe kann als Name (z.B. blue) oder HEX-Wert (z.B. #d9d9d9) angegeben werden.
<empfohlen> - die Aufladung ist empfohlen aber inaktiv (kein Aufladen oder Entladen)
<aufladen> - wird verwendet wenn die Batterie aktuell aufgeladen wird
<entladen> - wird verwendet wenn die Batterie aktuell entladen wird
<unterlassen> - wird verwendet wenn die Aufladung nicht empfohlen ist
Die Möglichkeiten sind wichtig, da das Icon-Design zukünfig dynamisch mit dem SOC korrespondieren wird.
Falls man allerdings eigene Icons definiert, ist dieses Feature nicht möglich.
Deswegen belässt man lieber den Standard und ändert nur die Färbung nach Bedarf.
EDIT: Zur aktuellen Stunde wird bei den Batterie-Icons der aktuelle SOC abgebildet und per Mouse-Over auch der genaue Wert.
LG
Das Modul in meinem contrib hat wieder ein Update bekommen.
Nun gibt es eine Batterie SoC Entwicklungsprognose die Einfluß auf die angezeigten Ladeempfehlungs-Icons der jeweiligen Batterie hat.
Diese SoC-Prognose berücksichtigt den aktuellen SoC, die zu erwartende PV in Beziehung zur Verbrauchsprognose (=Überschuß), den optimalen SoC aus der SoC-Steuerung sowie die Steuerung der Ladeempfehlung.
Der Prognose-SoC bezieht sich immer auf den Anfang der angezeigten Stunde.
In dem Screenshot sieht man den aktuellen SoC als Startpunkt und die weitere Prognose (den Wert der ersten Folgestunde als Beispiel im Mouse-Over)
LG
sieht gut aus ;)
Hallo Heiko.
kleine Ungenauigkeiten bei den "fließenden Linien / Werten" - siehe Screenshot: (Version vom Heutige Tag / vorheriger letzter Post)
A;
Ladung der Batterie-1 erfolgt von der PV mit den 214 Watt (richtig)
B:
Entladung der Batterie 2 erfolgt mit 617 Watt
Die Entladung fehlt in der Anzeige des Batterieflusses bzw. die 39 Watt stimmen irgendwie nicht.
Außerdem sind dann die 573 Wtt Gesamtverbrauch von woher...
EDIT:
Der 2.te Screenshot wirft artähnliche Fragen auf
Kann deine Images noch nicht öffnen, dauert manchmal bis es geht. Komisches Forum ...
Zitat von: DS_Starter am 07 Januar 2025, 16:00:45Kann deine Images noch nicht öffnen, dauert manchmal bis es geht. Komisches Forum ...
Ja -kenn ich :'(
Ist auch irgendwas geändert worden beim Menü für den Upload :o
Nachsatz um 16:10 Uhr:
Bei "nur Netzbezug" ist die Darstellung bei 2 Batterien okay (keine PV-Leistung, keine Producer-Leistung aktiv)
Erstes Bild geöffnet...
Der Wert an der Linie Bat -> Home ist die Summe aus den Readings Current_PowerBatOut_01 und 02.
Passen die Readings?
Tippe auf Vorzeichenfehler bei der Summieren der Flüsse von den Batterien zu Hausverbrauch ;D
Screenshot 2:
->>> 614 - 23 + 3 = 594
Die Reading der Batterie sind okay
Wenn es so einfach wäre :o
Es liegt wahrscheinlich daran dass eine Batterie entladen und die andere geladen wird. In der Zusammenführungslogik heben sich manche Dinge auf.
Sehr unschön. Die Flußgrafik muß ich mir ohnehin noch vornehmen.
Mache erstmal die Dinge in der Balkengrafik fertig und gehe dann zur Flußgrafik.
In meinem contrib liegt wieder ein Update.
Man kann die Batterien nun wahlweise in Ebene 1 oder Ebene 2 anzeigen lassen.
show Steuerung der Anzeige der Batterie in der Balkengrafik (optional)
0 - keine Anzeige des Gerätes (default)
1 - Anzeige des Gerätes in der Balkengrafik Ebene 1
2 - Anzeige des Gerätes in der Balkengrafik Ebene 2
Wenn du mal in den Code abtauchen willst ... in Zeile 15007 bis 15136 liegt der Schatz begraben.
Zitat von: DS_Starter am 07 Januar 2025, 16:33:53Sehr unschön. Die Flußgrafik muß ich mir ohnehin noch vornehmen.
Mache erstmal die Dinge in der Balkengrafik fertig und gehe dann zur Flußgrafik.
...........
.........
Wenn du mal in den Code abtauchen willst ... in Zeile 15007 bis 15136 liegt der Schatz begraben.
Hauptsache es wird intern alles richtig gerechnet 😉 Grafik ist nicht die Hauptsache.
Wenn ich nacher wieder zuhause bin versuch ich mich evtl. mal 👾
Hat mir nun doch keine Ruhe gelassen und ich denke ich habe das Problem identifiziert und konnte es beseitigen.
Zeilen 15032 - 15038
Update liegt im contrib.
LG
Ergebnis folgt morgen - hab heute keine PV-Ladeleistung mehr, nur nachher (nach Regeneration) wieder Producer-Leistung ;D
Hallo Heiko,
bislang sieht es gut aus.
Gruß
300P
Hier noch ein aktueller Screenshot:
Die angezeigten Ladungsflüsse der "Summen-Batterie" passt zu den Zahlen der einzelnen currentPowerBatIn, den BWR-Daten (gelbe Linie "Teil-Summe-PV-Produktion" und "Teil-Summe-FCU-Producer" (rote Linie Haus ==>> "Summen-Batterie"
Optionswunsch:
Könnte es evtl. solche optionale weitere Reading geben ?
ctrlNextHoursSOCForecastReadings <00,01,..,23>
Wenn gesetzt, werden Readings der Form Next_Hour<hour>_SOCforecast erstellt.
Diese Readings enthalten die voraussichtliche SOCWerte der aktuellen und der kommenden 23 Stunden. Dabei ist <hour> die xy Stunde in der Zukunft der aktuellen Stunden.
Beispiel:
attr <name> ctrlNextHoursSOCForecastReadings 00,03,12,18
# erstellt Readings für die aktuelle Stunde + 00 Stunde (..+3 Stunden ..... +12 Stunden ..... +18 Stunden) in der Zukunft.
@300P,
erstmal Danke für deine Rückmeldung.
Das Modul im contrib hat ein weiteres Update erfahren:
* in den Attributen graphicBeamXContent ist die Option "batsocforecast_XX" auswählbar.
Dadurch kann man sich den Prognose-SOC sowie den erreichten SoC in der Vergangenheit anzeigen
lassen (Ebene 1 oder 2)
Hinweis: wegen dem Wertebereich das Attr graphicBeamHeightLevelX auf z.B. 800 setzen damit man
etwas besser sieht was passiert
* das Attr ctrlBackupFilesKeep kann expliziz auf 0 gesetzt werden um keine Sicherungsdateien und
Bereinigungen automatisch auszuführen.
Das kann für configDB User sinnvoll sein wie der Fall von cwagner gezeigt hat.
ZitatOptionswunsch:
Könnte es evtl. solche optionale weitere Reading geben ?
Denke ich mal darüber nach. ;)
LG
Anmerkung zu Anzeige von "batsocforecast_XX":
Der Batteriestatus wird bei mir bis zum Ende des Tages (bis 23:59) berechnet, danach bleiben die Werte ab 00:00 Uhr gleich.
Gruß
300P
Nachtrag :
Mein Fehler - Fehlinterpretation
=>> Battery_OptimumTargetSoC_XX sollte (wird) ja nicht von der Steuerungslogik unterschritten werden..... :-X
ZitatAnmerkung zu Anzeige von "batsocforecast_XX":
Der Batteriestatus wird bei mir bis zum Ende des Tages (bis 23:59) berechnet, danach bleiben die Werte ab 00:00 Uhr gleich.
Er wird weiter berechnet. Allerdings erreicht er bei dir ab 00:00 offensichtlich den Optimal SoC aus der Batterie SOC-Optimierung.
Schau dir das Reading Battery_OptimumTargetSoC_XX an. Wird das Limit darstellen.
Zitat von: DS_Starter am 08 Januar 2025, 21:18:13.....
Er wird weiter berechnet. Allerdings erreicht er bei dir ab 00:00 offensichtlich den Optimal SoC aus der Batterie SOC-Optimierung.
Schau dir das Reading Battery_OptimumTargetSoC_XX an. Wird das Limit darstellen.
...hatte es grade eben dann doch noch "kapiert" ;)
:)
Habe im contrib wieder upgedated.
Ein Mouse Over über den Soc-Balken zeigt uns die Batterie Nummer. Damit kann man besser identifizieren falls mehrere Batterie-SOCs dargestellt werden.
Edit:
In dem Screenshot wird ein generelles Thema deutlich. Die Ebenen 1 und 2 sind zeitlich nicht synchronisiert wenn die Nachtstunden nicht angezeigt werden sollen UND in einer der Ebenen Werte in den Nachtstunden vorhanden sind, die dann doch angezeigt werden (works as designed).
Mit einer eventuellen Lösung beschäftige ich mich gerade.
Die Version 1.42.0 aus dem contrib ist eingecheckt und wird morgen früh im Update ausgerollt.
Sie vereint die besprochenen und getesteten Features.
SF ist nun ein Multi Battery System :) mit erweiterten Anzeigefunktionen im Balkendiagramm.
Weitere Funktionen wie Synchrontät der Balkendiagramm-Ebenen (wenn gewünscht) bzw. die Erweiterung der Flowgrafik etc. werden folgen.
LG,
Heiko
Zitat von: DS_Starter am 08 Januar 2025, 22:55:57Die Version 1.42.0 aus dem contrib ist eingecheckt und wird morgen früh im Update ausgerollt.
Sie vereint die besprochenen und getesteten Features.
SF ist nun ein Multi Battery System :) mit erweiterten Anzeigefunktionen im Balkendiagramm.
Weitere Funktionen wie Synchrontät der Balkendiagramm-Ebenen (wenn gewünscht) bzw. die Erweiterung der Flowgrafik etc. werden folgen.
LG,
Heiko
Einrichtung war problemlos möglich! Danke!
Bin schon gespannt auf die Erweiterung der Flowgrafik.
Hallo zusammen,
es geht weiter.
In meinem contrib liegt ein Update welches die Zeitsync zwischen den Balkengrafikebenen realisieren kann.
Dazu ist der Wertebereich des Attr graphicShowNight erweitert:
graphicShowNight
Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik.
0 keine Anzeige der Nachtstunden sofern kein Wert anzuzeigen ist (default)
Sofern die ausgewählten Inhalte einen Wert enthalten, werden diese Balken dennoch dargestellt.
01 Wie '0', es findet jedoch eine Zeitsynchronisation zwischen den Balken
der Ebene 1 und der nachfolgenden Balkengrafikebene statt.
1 Nachtstunden werden immer angezeigt
Im Anhang seht ihr Beispiele für den Unterschied in der Darstellung (Zeitschiene).
Es ist nicht immer sinnvoll die Zeitsync einzustellen, z.B. wenn die Ebenen keinen direkten Bezug zueinander haben. Die Screenshots sind so ein Fall, oben ist PV Prognose und Ertrag, unten die Verbrauchsprognose und der tatsächliche Verbrauch. Hier würde ich die Zeitsync nicht einschalten wenn die Nachtstunden nicht angezeigt werden sollen.
LG
Hallo,
ich habe versucht in solarforecast einen consumer zu integrieren, dessen Schaltung unterbrochen werden soll, wenn ein bestimmtes Reading den Wert "on" hat. Ich habe es mit dem Key
interruptable=Device:Reading:Regex[:Hysteresis] in der Form
interruptable=Device:Reading:on
versucht. Aber funktionierte nicht. Im Debug war als Regex immer "". Erst als ich den Doppelpunkt der optionalen Hysteresis noch anhängte, dann ging es. Da Key sah dann so aus:
interruptable=Device:Reading:on:
Keine Ahnung, ob hier ein Fehler im Code oder in der Dokumentation vorliegt. Am einfachsten wäre es: Works as designed, change the doc!
Desweiteren hätte ich noch eine Frage zum Verhalten der Schaltungen, wenn der consumer von ausserhalb solarforecast geschaltet wird. Wenn solarforecast ihn z.B. eingeschaltet hat und er von ausserhalb ausgeschaltet wird und alle Einschaltbedingungen gelten noch. Wann wird solarforecast den consumer wieder einschalten? Das Gleiche auch umgekehrt. Gibt es dazu irgendwo eine Dokumentation? Ich habe nichts gefunden.
HG
@bema15,
danke für Info. Schaue mir den Fall im Code an.
ZitatDesweiteren hätte ich noch eine Frage zum Verhalten der Schaltungen, wenn der consumer von ausserhalb solarforecast geschaltet wird. Wenn solarforecast ihn z.B. eingeschaltet hat und er von ausserhalb ausgeschaltet wird und alle Einschaltbedingungen gelten noch.
Wann wird solarforecast den consumer wieder einschalten?
Das Gleiche auch umgekehrt. Gibt es dazu irgendwo eine Dokumentation? Ich habe nichts gefunden.
Wenn ein Consumer durch einen externen Vorgang ausgeschaltet wird, nachdem SF ihn eingeschaltet hat, wird SF ihn erst dann wieder einschalten wenn SF durch eine Ausschaltbedingung ihn ausschalten will (dabei schon den Aus-Zustand erkennt) und danach wieder einschalten will weil z.B. ein Interrupt nicht mehr vorliegt.
Das Thema Consumersteuerung habe ich im Wiki noch nicht umfassend beschrieben. Kommt alles nach und nach.
@all,
ich habe den Wunsch von 300P aus #1542 umgesetzt.
Es gibt zur Erstellung von optionalen Batterie-Prognosereadings das Attr ctrlNextHoursSoCForecastReadings:
ctrlNextHoursSoCForecastReadings <00,02,..,23>
Wenn gesetzt, werden Readings der Form Battery_NextHourXX_SoCforecast_BN erstellt sofern eine Batterie im SolarForecast-Device registriert ist (siehe attr <name> setupBatteryDevXX ).
Diese Readings enthalten die prognostizierten SoC-Werte (%) der ausgewählten Stunden.
Dabei ist 'XX' die Stunde in der Zukunft ausgehend von der aktuellen Stunde (00) und 'BN' die Nummer der registrierten Batterie.
Beispiel:
attr <name> ctrlNextHoursSoCForecastReadings 00,03,12,18
# erstellt Readings für die aktuelle Stunde (00) sowie die nachfolgenden Stunden +03, +12 und +18.
ZU überlegen wäre noch ob 00 als Startstunde sinnvoll ist, da Current_BatCharge_XX den aktuellen Wert bereits abbildet.
Die V liegt als Update in meinem contrib.
LG
Zitat von: DS_Starter am 10 Januar 2025, 16:40:20ZU überlegen wäre noch ob 00 als Startstunde sinnvoll ist, da Current_BatCharge_XX den aktuellen Wert bereits abbildet.
Da geb ich dir recht - wäre "doppelt gemoppelt" O:-)
Also ohne die "00" ist sicherlich auch okay ;D
Ansonsten funktioniert es prima
Gruß und Danke
300P
ZitatDa geb ich dir recht - wäre "doppelt gemoppelt" O:-)
Ich habe die SOC-Prognose dahingehend geändert, dass der Prognosewert der Endwert der entsprechenden Stunde wiedergibt.
Somit hat die Stunde 00 ihre Berechtigung, denn dadurch sieht man den prognostizierten Endwert der aktuellen Stunde vs. dem aktuellen Stand.
Die V 1.43.0 mit dem Attr ctrlNextHoursSoCForecastReadings ist eingecheckt und morgen früh im Rollout.
LG
Hallo zusammen,
@bema15,
es ware tatsächlich ein Fehler im Code den ich behoben habe.
@all,
Weiterhin habe ich die Anzeige der SoC-Prognose korrigiert. Da der erwartete SoC am Ende der Stunde errechnet und dargestellt wird, ergibt sich für den Mouse-Over der Stunde 00 die Anzeige sowohl des aktuellen als auch des erwarteten SoC.
Ein paar kleinere Bugs in dem Umfeld sind auch noch korrigiert.
Unter anderem war die Funktion des Attr graphicBeamHeightLevel2 nicht korrekt. Es gab eine Anhängigkeit
von graphicBeamHeightLevel1 die jetzt aufgelöst wurde.
Ggf. ist bei euch nach dem Update eine Anpassung des Attr graphicBeamHeightLevel2 nötig wenn euch die
Verhältnisse der Ebenen zueinander nicht gefallen sollte.
Die Version ist eingescheckt, aber auch schon in meinem contrib zum Download vorfügbar.
Grüße,
Heiko
Im Rahmen meiner ersten Test der "Multi Battery Features" ist mir aufgefallen, dass das setupBatteryDevXX-Attribut "show" nur eine Balkengrafik erzeugt, wenn für setupBatteryDev01 show=1 und für setupBatteryDev02 show=2 gesetzt wird. Wird hingegen für beide BAT-Devices show=1 angegeben, dann werden auch zwei Balkengrafiken angezeigt.
Moin Parallix,
ich habe jetzt nicht verstanden wo ein Problem sein soll.
Eine Batterie mit schow=1 oder show=2 erstellt nur eine Balkenreihe entweder auf Ebene 1 oder Ebene 2.
Wenn beide Batterien show=1 bekommen, werden beide Balkenreihen auf Ebene 1 dargestellt.
Vllt. habe ich dich aber auch nicht richtig verstanden?
LG
Zitat von: DS_Starter am 12 Januar 2025, 08:49:45Moin Parallix,
ich habe jetzt nicht verstanden wo ein Problem sein soll.
Eine Batterie mit schow=1 oder show=2 erstellt nur eine Balkenreihe entweder auf Ebene 1 oder Ebene 2.
Wenn beide Batterien show=1 bekommen, werden beide Balkenreihen auf Ebene 1 dargestellt.
Vllt. habe ich dich aber auch nicht richtig verstanden?
LG
Nur wenn ich bei beiden BAT-Devices show=1 angegeben wird, erscheinen auch zwei BAT-Reihen. Lt. Beschreibung hatte ich angenommen, dass ich zwei BAT-Reihen bekomme, wenn einmal show=1 und einmal show=2 angegeben wird. Vllt. habe ich da die Beschreibung nicht richtig verstanden.
ZitatLt. Beschreibung hatte ich angenommen, dass ich zwei BAT-Reihen bekomme, wenn einmal show=1 und einmal show=2 angegeben wird.
Genauso ist es. Siehe Anhang. Beide Bat haben show=2.
Hast du die aktuellste Version 1.43.1?
Zitat von: DS_Starter am 12 Januar 2025, 09:29:26ZitatLt. Beschreibung hatte ich angenommen, dass ich zwei BAT-Reihen bekomme, wenn einmal show=1 und einmal show=2 angegeben wird.
Genauso ist es. Siehe Anhang. Beide Bat haben show=2.
Hast du die aktuellste Version 1.43.1?
Yipp, habe die v1.43.1-s29513/2025-01-11
Mit folgenden Setup bekomme ich die gewünschten zwei (!) Zeilen:
setupBatteryDev01: BydBat1 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=1 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
setupBatteryDev02: BydBat2 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=1 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
Dann zeig doch mal bitte ein list deines SF Devices und einen Screenshot dazu.
Zitat von: DS_Starter am 12 Januar 2025, 09:39:16Dann zeig doch mal bitte ein list deines SF Devices und einen Screenshot dazu.
s.o.
bin ganz begeistert von der "2. Reihe" :D
ZitatMit folgenden Setup bekomme ich die gewünschten zwei (!) Zeilen:
Code Auswählen
setupBatteryDev01: BydBat1 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=1 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
setupBatteryDev01: BydBat2 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=1 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
Du kannst zweimal die Attribute "setupBatteryDev01" setzen? Glaube ich nicht...
Also mache mal bitte ein komplettes List deines SF Devices und einen entsprechenden Screenshot dazu.
Zitat von: DS_Starter am 12 Januar 2025, 09:46:26ZitatMit folgenden Setup bekomme ich die gewünschten zwei (!) Zeilen:
Code Auswählen
setupBatteryDev01: BydBat1 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=1 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
setupBatteryDev01: BydBat2 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=1 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
Du kannst zweimal die Attribute "setupBatteryDev01" setzen? Glaube ich nicht...
Also mache mal bitte ein komplettes List deines SF Devices und einen entsprechenden Screenshot dazu.
Das zweite setupBatteryDev01 hatte ich versehentlich händisch nur hier in den Beitrag (!) falsch/doppelt . Habe es jetzt oben korrigiert.
Hier nun noch der Screenshot:
So sieht es aus (bei mir)wenn für die eine Batterie show=1 und die andere show=2 eingetragen ist
@Parallix und @300P beide Screenshots sind korrekt und passen zum Setup.
Parallix hat beide Batterien mit show=1 angegeben -> es werden beide Zeilen in Ebene 1 dargestellt.
300P hat die Batterien auf show=1 und show=2 verteilt -> die Bat werden entsprechend auf die Ebenen verteilt.
@Parallix, weiß immer noch nicht was dein Problem ist.
Wenn ich dir helfen soll dann bitte ein komplettes List des Devices UND einen Screenshot dazu. Ein bisschen Arbeit muß man sich schon machen. ;) EDIT: ok hast noch ein Bild gepostet ... aber ändert nichts daran dass Setup auch zur Darstellung passt.
Zitat von: DS_Starter am 12 Januar 2025, 09:57:02@Parallix und @300P beide Screenshots sind korrekt und passen zum Setup.
Parallix hat beide Batterien mit show=1 angegeben -> es werden beide Zeilen in Ebene 1 dargestellt.
300P hat die Batterien auf show=1 und show=2 verteilt -> die Bat werden entsprechend auf die Ebenen verteilt.
@Parallix, weiß immer noch nicht was dein Problem ist.
Wenn ich dir helfen soll dann bitte ein komplettes List des Devices UND einen Screenshot dazu. Ein bisschen Arbeit muß man sich schon machen. ;) EDIT: ok hast noch ein Bild gepostet ... aber ändert nichts daran dass Setup auch zur Darstellung passt.
Offenbar hatte ich das mit den Ebenen nicht richtig verstanden. Mein Fehler! Sorry für die Verwirrung!
Edit: Bin eben irritiert, dass ich für den Fall, dass ich für setupBatteryDev02 das show=2 setze, weiterhin nur eine Zeile sehe.
Kein Problem, ein Indiz mehr das Wiki als Lektüre weiter voran zu treiben. :)
ZitatEdit: Bin eben irritiert, dass ich für den Fall, dass ich für setupBatteryDev02 das show=2 setze, weiterhin nur eine Zeile sehe.
Das wäre nicht i.O. was ich aber nicht so recht glauben mag.
Wenn du das Attr setupBatteryDevXX änderst, dauert es ein wenig bis der nächste Datenzyklus gelaufen ist und SF die Änderung umsetzt. Vllt. einfach mal etwas warten oder ein "get ... data" ausführen.
EDIT: daran denken, dass man in der Dateilansicht den Browser auffrischen muß um Änderungen in der Grafik zu sehen!
Zitat von: DS_Starter am 12 Januar 2025, 10:01:31Kein Problem, ein Indiz mehr das Wiki als Lektüre weiter voran zu treiben. :)
Die Beschreibung zum Modul ist eigentlich schon sehr gut. Und der Support von Dir echt Wahnsinn! Danke!
PS: Eine Anregung bzw. Frage hätte ich noch: Die BAT-Icons sind leider statisch. Lässt es sich irgendwie realisieren, dass diese dynamisch geändert werden können. Auf diese Weise könnte man z.B. ungewünschte Zustände, z.B. ein großes Delta V zwischen der einzelnen BAT-Zellen, darstellen.
Zitat von: DS_Starter am 12 Januar 2025, 10:12:45ZitatEdit: Bin eben irritiert, dass ich für den Fall, dass ich für setupBatteryDev02 das show=2 setze, weiterhin nur eine Zeile sehe.
Das wäre nicht i.O. was ich aber nicht so recht glauben mag.
Wenn du das Attr setupBatteryDevXX änderst, dauert es ein wenig bis der nächste Datenzyklus gelaufen ist und SF die Änderung umsetzt. Vllt. einfach mal etwas warten oder ein "get ... data" ausführen.
Dann warte ich mal geduldig(er) ...
Wenn es bei dir nicht gehen sollte -> komplettes List und den Screenshot dazu. ;)
EDIT: daran denken, dass man in der Dateilansicht den Browser auffrischen muß um Änderungen in der Grafik zu sehen!
ZitatEine Anregung bzw. Frage hätte ich noch: Die BAT-Icons sind leider statisch. Lässt es sich irgendwie realisieren, dass diese dynamisch geändert werden können. Auf diese Weise könnte man z.B. ungewünschte Zustände, z.B. ein großes Delta V zwischen der einzelnen BAT-Zellen, darstellen.
Ich will nicht sagen es würde nicht gehen.
Vorstellbar wäre z.B. ein key "iconOnError", in welchem man ein Icon, dessen Farbe sowie Device,Reading und Regex für den Eintritt eines Errors (was auch immer man dafür erachtet) angeben kann.
Wahrscheinlich umsetzbar und auch vom User in der Form verwendbar.
Zitat von: DS_Starter am 12 Januar 2025, 10:20:41Wenn es bei dir nicht gehen sollte -> komplettes List und den Screenshot dazu. ;)
Auch nach einigen Grafik-Aktualisierungen sehe ich weiterhin nur eine BAT-Balkengrafik.
Hier das Setup:
define SF SolarForecast
setuuid SF 670629ca-f33f-0450-2b37-6b5f5ad926e1a2e0
attr SF event-on-change-reading .*
attr SF graphicEnergyUnit kWh
attr SF graphicHistoryHour 12
attr SF room Metering
attr SF setupBatteryDev01 BydBat1 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=1 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
attr SF setupBatteryDev02 BydBat2 pin=-pout pout=BatteryPower:W intotal=Battery_1_ChargeE:Wh outtotal=Battery_1_DischargeE:Wh cap=5100000 charge=Battery_1_SOC show=2 icon=measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
attr SF setupInverterDev01 inverter pv=pv_power_total_W:W etotal=total_pv_generation_kWh:kWh capacity=25000
attr SF setupInverterStrings east,south,west
attr SF setupMeterDev inverter gcon=-gfeedin contotal=total_energy_import_kWh:kWh gfeedin=active_power_total_W:W feedtotal=total_energy_export_kWh:kWh conprice=0.40:EUR feedprice=0.075:EUR
attr SF setupRadiationAPI OpenMeteoDWDEnsemble-API
attr SF setupStringPeak east=4.860 south=10.530 west=4.860
attr SF setupWeatherDev1 OpenMeteoDWDEnsemble-API
Übrigens: Die Verbrauchsprognose liefert - trotz von Tag zu Tag näherungsweise gleichem Verbrauch - nicht wirklich gute Schätzwerte.
Du hast den Browser aktualiert sofern du dich in der Detailansicht befindest?
Poste mal bitte noch die Ausgabe von "get ... valBattery".
Sieht etwa so aus:
01 => balias => Batterie Dummy 1
basynchron => 1
bcharge => 90
binstcap => 20000
bname => BatteryDummy1
bpowerin => 100
bpowerout => 0
bshowingraph => 1
02 => balias => Batterie Dummy 2
basynchron => 1
bcharge => 55
binstcap => 10000
bname => BatteryDummy2
bpowerin => 0
bpowerout => 150
bshowingraph => 2
Zitat von: DS_Starter am 12 Januar 2025, 11:30:36Du hast den Browser aktualiert sofern du dich in der Detailansicht befindest?
Ja, kann aber auch gerne ein Video einstellen ;-)
Zitat von: DS_Starter am 12 Januar 2025, 11:30:36Poste mal bitte noch die Ausgabe von "get ... valBattery".
...
01 => balias => BydBat1
basynchron => 0
bcharge => 28.9
bicon => measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
binstcap => 5100000
bname => BydBat1
bpowerin => 1092.93
bpowerout => 0
bshowingraph => 1
02 => balias => BydBat2
basynchron => 0
bcharge => 27.6
bicon => measure_battery_100@cyan:measure_battery_100@green:measure_battery_100@red:measure_battery_100@pink
binstcap => 5100000
bname => BydBat2
bpowerin => 1048.11
bpowerout => 0
bshowingraph => 2
ZitatJa, kann aber auch gerne ein Video einstellen ;-)
Bei Youtube bitte. :)
Zitat von: DS_Starter am 12 Januar 2025, 11:36:26ZitatJa, kann aber auch gerne ein Video einstellen ;-)
Bei Youtube bitte. :)
in 4k ... ;D
:)
Ja, also das Thema ist, dass du keine Ebene 2 bei dir aktiviert hast. Dadurch kann dort nichts angezeigt werden.
Die zweite Ebene aktiviert man durch Setzen der Attr graphicBeam3Content und/oder graphicBeam4Content mit einem gewünschten Inhalt.
Dann wirst du die Batterie auch in der zweiten Ebene sehen.
Zitat von: DS_Starter am 12 Januar 2025, 11:43:39:)
Ja, also das Thema ist, dass du keine Ebene 2 bei dir aktiviert hast. Dadurch kann dort nichts angezeigt werden.
Die zweite Ebene aktiviert man durch Setzen der Attr graphicBeam3Content und/oder graphicBeam4Content mit einem gewünschten Inhalt.
Dann wirst du die Batterie auch in der zweiten Ebene sehen.
Was ganz eindeutig zeigt, dass ich das mit der zweiten Ebene (!= zweite Zeile) nicht verstanden hatte. Danke für die Erläuterung!
Naja, die ganze Beschreibung des Grafikaufbaus, der Ebenen usw. fehlt noch im Wiki.
Sonst hättest du es nach Durchlesen gewusst. Kannst das Video wieder löschen. :)
Zitat von: DS_Starter am 12 Januar 2025, 10:27:59ZitatEine Anregung bzw. Frage hätte ich noch: Die BAT-Icons sind leider statisch. Lässt es sich irgendwie realisieren, dass diese dynamisch geändert werden können. Auf diese Weise könnte man z.B. ungewünschte Zustände, z.B. ein großes Delta V zwischen der einzelnen BAT-Zellen, darstellen.
Ich will nicht sagen es würde nicht gehen.
Vorstellbar wäre z.B. ein key "iconOnError", in welchem man ein Icon, dessen Farbe sowie Device,Reading und Regex für den Eintritt eines Errors (was auch immer man dafür erachtet) angeben kann.
Wahrscheinlich umsetzbar und auch vom User in der Form verwendbar.
So wie die "alten" Wetter-Icons sollten auch die BAT-Icons - unabhängig davon, ob das o.g. Feature noch kommt - vielleicht stehen bleiben.
ZitatSo wie die "alten" Wetter-Icons sollten auch die BAT-Icons - unabhängig davon, ob das o.g. Feature noch kommt - vielleicht stehen bleiben.
Habe ich jetzt nicht verstanden. Wie sollen die Icons "stehenbleiben".
Was du jetzt schon tun kannst, für jede Bat ein definiertes festes Icon vergeben. Das ändert sich auch nicht mit dem Ladezustand sondern bleibt fix.
Zitat von: DS_Starter am 12 Januar 2025, 12:40:52ZitatSo wie die "alten" Wetter-Icons sollten auch die BAT-Icons - unabhängig davon, ob das o.g. Feature noch kommt - vielleicht stehen bleiben.
Habe ich jetzt nicht verstanden. Wie sollen die Icons "stehenbleiben".
Was du jetzt schon tun kannst, für jede Bat ein definiertes festes Icon vergeben. Das ändert sich auch nicht mit dem Ladezustand sondern bleibt fix.
In der unten angefügten Grafik sind in der Zeile mit den Wetter-Icons sind aktuell 17 Icons zu sehen. Fünf davon betreffen die Vergangenheit, sind also alt im Sinne eines Forecasts, gleichwohl aber für eine schnelle visuelle zurückschauende Analyse hilfreich.
In den nächsten beiden Zeilen findet man die BAT-Icons. Dort werden aber nur 2 x 12 statt 2 x 17 dargestellt. Denn alle die, die die Vergangenheit betreffen, werden nicht mehr dargestellt, was im Sinne eines Forecasts vielleicht noch verständlich ist, aus Gründen der Konsistenz (vgl. Wetter-Icons) aber nicht. Um auch hier die o.g. zurückschauende Analyse durchführen zu können, möchte ich daher anregen, wie bei den Wetter-Icons zu verfahren.
Sehr selten, aber immer mal wieder, bekomme ich auch eine seltsame Grafik mit einer negativem Haus-Verbauch. Wahrscheinlich liegt die Ursache darin, dass hin und wieder nicht alle Wechselrichter-Readings aktualisiert werden. Wäre es möglich, derart unsinnige Fälle (House-Consumption < 0) im Modul zu erkennen und dann nicht weiter zu verarbeiten, sodass Sie dann weder in der Grafik angezeigt werden und auch gar nicht erst ins Forecast einfließen?
Apropos unsinnige Daten:
Achso, jetzt habe ich es verstanden.
Naja, der Ansatz zur Darstellung der Batterie-Icons ist eigentlich nicht deren Füllgrad und SoC-Prognose.
Der Case ist hier die Visualisierung ob die Aufladung der Batterie für die nächsten Stunden empfohlen wird oder nicht. Das hat etwas mit der Unterstützung bei der Maximierung des Eigenverbrauchs zu geben und einem Beitrag zur Netzstabilität zu tun (Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Ber%C3%BCcksichtigung_einer_Wirkleistungsbegrenzung)).
Deswegen hat die Vergangenheit keine Relevanz für diese Darstellung.
Aber du kannst die z.B. in 2. Ebene ein Balkendiagramm des SoC einblenden, welches auch die erreichten SoC der Vergangenheit anzeigt.
Die Abbildung der SoC-Prognose ist quasi ein, wenn auch attraktives, "Abfallprodukt".
Zitat von: DS_Starter am 12 Januar 2025, 13:38:42...
Der Case ist hier die Visualisierung ob die Aufladung der Batterie für die nächsten Stunden empfohlen wird oder nicht.
Um warum lässt Du die alten bzw. letzten Empfehlungen nicht in der Grafik?
ZitatWäre es möglich, derart unsinnige Fälle (House-Consumption < 0) im Modul zu erkennen und dann nicht weiter zu verarbeiten, sodass Sie dann weder in der Grafik angezeigt werden und auch gar nicht erst ins Forecast einfließen?
Das ist ein zweischneidiges Schwert. Technisch kann man alles mögliche unterdrücken und teilweise mache ich es auch in bestimmten Fällen.
ABER, und das möchte ich beibehalten, wird man dadurch auf Fehler im Setup und/oder fehlerhaft gelieferte Daten der Datenlieferanten aufmerksam und kann bzw. sollte die Sache bereinigen.
Nichts geht über eine gute Inputdatenqualität!
ZitatUm warum lässt Du die alten bzw. letzten Empfehlungen nicht in der Grafik?
Wozu soll das gut sein?
Achtung ... Ich entferne sie nicht, sondern müßte sie erst relativ aufwändig in die Grafik integrieren.
ZitatApropos unsinnige Daten:
Kannst du erläutern was genau unsinnig ist?
Zitat von: DS_Starter am 12 Januar 2025, 13:47:06ZitatUm warum lässt Du die alten bzw. letzten Empfehlungen nicht in der Grafik?
Wozu soll das gut sein?
Aus den gleichen Gründen, weshalb ein Blick auf die alten Wetterdaten sinnvoll sein kann.
Zitat von: DS_Starter am 12 Januar 2025, 13:47:06Ich entferne sie nicht, sondern müßte sie erst relativ aufwändig in die Grafik integrieren.
Hierfür einen großen Aufwand zu treiben würde ich auch nicht wollen. Finde es halt nur inkonsistent, dass die alten (!) Wetter-Icons stehen bleiben. Konsistenz könnte ja auch dadurch hergestellt werden, dass die alten (!) Wetter-Icons entfernt werden ;-)
Zitat von: DS_Starter am 12 Januar 2025, 13:51:37ZitatApropos unsinnige Daten:
Kannst du erläutern was genau unsinnig ist?
SOC=100% und Ladeempfehlung?
ZitatKonsistenz könnte ja auch dadurch hergestellt werden, dass die alten Wetter-Icons entfernt werden ;-)
Nö, das wurde ja schon mit entsprechenden Aufwand integriert und muß auch nicht raus.
Es muß ja auch auch nicht alles gleich aussehen. ;)
Und vielleicht habe ich ja auch noch Lust diesen Aufwand zu treiben, kann ich jetzt noch nicht sagen ...
Kommt immer darauf an, ob es vielleicht noch mehr Interessenten gibt was den Aufwand dann rechtfertigen würde.
ZitatSOC=100% und Ladeempfehlung?
Das habe ich mir fast gedacht. ;)
Der aktuelle SoC ist für sich genommen kein Kriterium für eine Ladeempfehlung. Man könnte auch besser Ladefreigabe dazu sagen.
'Ladeempfehlung' fand ich aber weniger drastisch.
Wann die Ladeempfehlung (bzw. Ladefreigabe) gesetzt wird, liest du im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Aktivierung_und_Arbeitsweise).
Zitat von: DS_Starter am 12 Januar 2025, 14:05:23ZitatSOC=100% und Ladeempfehlung?
Das habe ich mir fast gedacht. ;)
Der aktuelle SoC ist kein Kriterium für eine Ladeempfehlung. Man könnte auch besser Ladefreigabe dazu sagen.
'Ladeempfehlung' fand ich aber weniger drastisch.
Ja, in der Tat liegt's am Wording. Ladefreigabe wäre mir sofort klar gewesen ;-)
Ja verstehe ich. Vielleicht gibt es noch ein deutlich besseres Wort für diesen Sachverhalt.
Gerne mal darüber sinnieren ...
Zitat von: DS_Starter am 12 Januar 2025, 14:12:14Ja verstehe ich. Vielleicht gibt es noch ein deutlich besseres Wort für diesen Sachverhalt.
Gerne mal darüber sinnieren ...
Eine Empfehlung zum Laden des Akkus sollte dann
nicht gegeben werden, wenn
- Netzbezug vorliegt (wg. ansonsten fehlendem netzdienlichen Verhalten)
- Zu wenig Überschuss vorliegt, da es dann schnell zum Netzbezug kommen kann (wg. nicht perfekter Regelung, vorgeschriebene max. Anstiegsraten)
- Der Akku zu lange auf einem unnötig hohem SOC-Level stehen bleiben würde (wg. drohende Zelldegeneration)
Vor diesem Hintergrund schlage ich vor, den "Ladeempfehlung" durch "Unbedenklichkeit einer Ladung" bzw. "Ladeunbedenklichkeit" zu ersetzen.
Warum (egal welches Wort verwendet wird) ein unnötig zu lange zu hoher SOC hier unberücksichtigt bleiben soll, erschließt sich mich derzeit noch nicht. Um den Aufwand gering zu halten, könnte man diese Größe zur Not auch durch ein optionales anzugebendes (vorläufig externes) binäres Reading berücksichtigen, das die rein durch den Akku bedingte Unbedenklichkeit einer Ladung angibt.
ZitatEine Empfehlung zum Laden des Akkus sollte dann nicht gegeben werden, wenn
ZitatDer Akku zu lange auf einem unnötig hohem SOC-Level stehen bleiben würde (wg. drohende Zelldegeneration)
Das wird durch die SoC-Optimierung gemacht sofern man sie aktiviert.
ZitatNetzbezug vorliegt (wg. ansonsten fehlendem netzdienlichen Verhalten)
Das macht üblicherweise schon die Steuerung des Herstellers. In manchen Fällen wird ein Zwangsladen aus dem Netz empfohlen/vollzogen wenn der SoC zu tief gefallen sein sollte.
ZitatZu wenig Überschuss vorliegt, da es dann schnell zum Netzbezug kommen kann (wg. nicht perfekter Regelung, vorgeschriebene max. Anstiegsraten)
Wird im Prinzip berücksichtigt. Ein gewisses Überregeln kann und wird passieren. Es gibt sogar Vorgaben dass bei einer Nulleinspeisung der Hersteller eine Überregelung, ich glaube innerhalb 10 Min., wieder einregeln muß. Können auch weniger Min. sein, weiß ich jetzt nicht aus dem Kopf.
"Ladefreigabe" halte ich inzwischen für eine gute Variante weil es jeder gleich versteht wie du selbst geschrieben hast.
Zitat von: DS_Starter am 12 Januar 2025, 13:46:17ZitatWäre es möglich, derart unsinnige Fälle (House-Consumption < 0) im Modul zu erkennen und dann nicht weiter zu verarbeiten, sodass Sie dann weder in der Grafik angezeigt werden und auch gar nicht erst ins Forecast einfließen?
Das ist ein zweischneidiges Schwert. Technisch kann man alles mögliche unterdrücken und teilweise mache ich es auch in bestimmten Fällen.
ABER, und das möchte ich beibehalten, wird man dadurch auf Fehler im Setup und/oder fehlerhaft gelieferte Daten der Datenlieferanten aufmerksam und kann bzw. sollte die Sache bereinigen.
Nichts geht über eine gute Inputdatenqualität!
Dass nichts über eine gute Datenqualität geht, dass kann ich nur unterschreiben. Wie vorliegend, hat man das aber nicht immer in der Hand oder man muss schon einen extremen Aufwand treiben, um gesichert stets saubere Daten zu haben. Dass eine Fehler- bzw. Warnmeldung im Falle eines unsauberen Anlieferns von Daten geliefert wird, das finde ich nicht nur sehr in Ordnung, sondern sogar absolut wünschenswert. Dass offensichtlich fehlerbehaftete Daten aber einfach weiter prozessiert werden, halte ich für sehr problematisch.
ZitatDass offensichtlich fehlerbehaftete Daten aber einfach weiter prozessiert werden, halte ich für sehr problematisch.
Ja ist es. Nur kann das Modul nicht immer als regulierende Instanz aufteten und alle Input-Fehler ausbügeln. Das sehe ich nicht als dessen Aufgabe.
Allerdings werden fehlerhafte Input-Daten nicht für die weiteren Prognoseberechnungen gespeichert. Sichtbar als "aktuelle Daten" sind sie schon.
In deinem speziellen Fall sollte man sich das mal anschauen um zu erkennen woher das Problem kommt denn Vermutungen helfen nicht wirklich. Vllt. hat ein Datenlieferant (Device) ein Problem welches dort gerichtet werden muß.
Wahrscheinlich hilft hier ein "set ... ctrDebug collectData". Das können wir uns mal anschauen.
Ist halt etwas aufwändig wenn es nur sporadisch auftritt, Debug schreibt jede Menge Daten.
Zitat von: DS_Starter am 12 Januar 2025, 17:09:21ZitatDass offensichtlich fehlerbehaftete Daten aber einfach weiter prozessiert werden, halte ich für sehr problematisch.
Ja ist es. Nur kann das Modul nicht immer als regulierende Instanz aufteten und alle Input-Fehler ausbügeln. Das sehe ich nicht als dessen Aufgabe.
Allerdings werden fehlerhafte Input-Daten nicht für die weiteren Prognoseberechnungen gespeichert. Sichtbar als "aktuelle Daten" sind sie schon.
Wenn die Daten nicht im Rahmen der weiteren Prozesssierung herangezogen werden, bin ich schon sehr beruhigt. Hatte das Gegenteil angenommen, da die Verbrauchsprognose immer sehr seltsame Werte liefert. Aktuell sehe ich für morgen eine Verbrauchsschätzung von 0,2kWh, was ja prima wäre, aber natürlich absolut utopisch ist.
Zitat von: DS_Starter am 12 Januar 2025, 17:09:21In deinem speziellen Fall sollte man sich das mal anschauen um zu erkennen woher das Problem kommt denn Vermutungen helfen nicht wirklich. Vllt. hat ein Datenlieferant (Device) ein Problem welches dort gerichtet werden muß.
Wahrscheinlich hilft hier ein "set ... ctrDebug collectData". Das können wir uns mal anschauen.
Ist halt etwas aufwändig wenn es nur sporadisch auftritt, Debug schreibt jede Menge Daten.
Meinerseits gehe ich davon aus, dass die Ursache für das o.g. Verhalten darin zu suchen ist, dass die Daten via Modbus UDP geholt werden und gelegentlich nicht Readings mit gleichem Zeitstempel aktualisiert vorliegen. Werde aber mal versuchen, das genauer herauszufinden. Ist - wie Du bereits geschrieben hast - aufgrund des sporadischen Auftretens halt nur recht aufwändig.
ZitatHatte das Gegenteil angenommen, da die Verbrauchsprognose immer sehr seltsame Werte liefert. Aktuell sehe ich für morgen eine Verbrauchsschätzung von 0,2kWh, was ja prima wäre, aber natürlich absolut utopisch ist.
Das kann man sich mal anschauen über ein "get ... pvHistory", dort ist für jede Stunde der Key 'con' relevant.
Vllt. gibt es einen regelmäßigen "Ausreißer". Ich will ja nicht generell ausschließen dass das Modul gegensteuern kann, aber ich muß genau wissen was warum woher kommt bevor ich korrigierende Maßnahmen ergreife sonst gibt es heilloses Chaos.
ZitatMeinerseits gehe ich davon aus, dass die Ursache für das o.g. Verhalten darin zu suchen ist, dass die Daten via Modbus UDP geholt werden und gelegentlich nicht Readings mit gleichem Zeitstempel aktualisiert vorliegen.
Der Zeitstempel ist für das SF egal, es nimmt nur den Wert aus dem Reading.
Es gibt Module die arbeiten mit einem "updateReadingIfchanged", d.h. wenn sich der Wert des Readings nicht ändert, erfolgt keine Update, auch des Zeitstempels nicht (was ich persönlich für unschön/irreführend halte und deswegen auf diese Funktion generell verzichte). Trotzdem hat das Reading aber einen gelieferten Wert und ist nur nicht aktualisiert.
Das ist auch ein Grund herauszubekommen woher dieses Problem ursächlich kommt.
@Parallix,
möglicherweise ist ein ctrlDebug=consumption,collectData wirkungsvoller.
Es gibt nämlich bei einem negativen Hausverbrauch die Meldung:
"... The calculated Energy consumption of the house is negative. This appears to be an error. Check Readings ..."
Zitat von: DS_Starter am 12 Januar 2025, 17:56:40ZitatHatte das Gegenteil angenommen, da die Verbrauchsprognose immer sehr seltsame Werte liefert. Aktuell sehe ich für morgen eine Verbrauchsschätzung von 0,2kWh, was ja prima wäre, aber natürlich absolut utopisch ist.
Das kann man sich mal anschauen über ein "get ... pvHistory", dort ist für jede Stunde der Key 'con' relevant.
Vllt. gibt es einen regelmäßigen "Ausreißer". Ich will ja nicht generell ausschließen dass das Modul gegensteuern kann, aber ich muß genau wissen was warum woher kommt bevor ich korrigierende Maßnahmen ergreife sonst gibt es heilloses Chaos.
Hier die pvHistory-Daten:
Zitat von: DS_Starter am 12 Januar 2025, 17:56:40Der Zeitstempel ist für das SF egal, es nimmt nur den Wert aus dem Reading.
Wenn SF den Hausverbrauch aus einer Differenzbildung von nicht synchron gewonnenen Daten (unterschiedlicher Zeitstempel) bestimmt, dann kann das doch zu o.g. Problem führen, oder?
ZitatWenn SF den Hausverbrauch aus einer Differenzbildung von nicht synchron gewonnenen Daten (unterschiedlicher Zeitstempel) bestimmt, dann kann das doch zu o.g. Problem führen, oder?
Im Prinzip ja wenn Datenaktualität zuweit auseinanderliegt, allerdings fängt SF intern schon eine ganze Reihe von Situationen ab die zu Problemen führen können. Wie schon geschrieben ist der Zeitstempel kein verlässlicher Indikator für die Aktualität falls die Module ein updateReadingIfChanged verwenden.
Die Datenlieferanten in FHEM, also die Devices, werden niemals synchrone Zeitstempel der gelieferten Readings haben. Sie liefern auch nicht wirklich die Zustände in Echtzeit ab.
Zum Beispiel aktualisiert SMAEM (Energiemesser) typerischerweise alle 60 Sekunden den Stand. Welche Leistung 15 Sekunden vor dem Update bezogen wurde ist unbekannt.
Es wird also immer einen Gap zur absoluten Realität geben. Der ist aber i.A. hinreichend klein dass er keine Probleme macht. Aber als User kann man durchaus Maßnahmen ergreifen dass die Datenlieferanten relativ synchrone Daten liefern.
Man nimmt ein führendes Device, z.B. das SMAEM und triggert über ein Notify alle anderen Devices (z.B. SMAInverter) an die Daten abzurufen sobald die Readings in SMAEM aktualisiert wurden. Das geht mit anderen Devices sicherlich ähnlich. Die meisten Devices haben sicherlich einen Modus um per Anforderung Daten zu holen, zumindest wenn sie aktiv Daten abrufen können.
Zitat von: DS_Starter am 12 Januar 2025, 18:45:27Zum Beispiel aktualisiert SMAEM (Energiemesser) typerischerweise alle 60 Sekunden den Stand. Welche Leistung 15 Sekunden vor dem Update bezogen wurde ist unbekannt.
Das ist auch nicht ganz so tragisch, denn eine Energiemessung - auf Basis bereits vorliegender integraler Werte - ist wesentlich robuster als eine instantane Leistungsmessung. Daher verstehe ich auch nicht, warum WR-Leistungsdaten häufig in Modulen integriert werden, statt direkt die WR-Energiedaten zu prozessieren. In SF werden - wahrscheinlich abgesehen von den Zahlen im Flow - ja glücklicherweise Enegiedaten prozessiert, richtig?
@Parallix auf den ersten Blick ...
Es gibt heute Bereiche die ganz ok. aussehen:
834033 787610 742938 705725 100 100 0 0 0 -59
834033 787610 742938 705725 200 100 0 100 100 60
834033 787610 742938 705725 -18 0 100 300 300 278
834154 787709 742938 705725 699 0 599 2100 2100 682
834564 788144 742938 705725 557 0 301 2800 2800 1350
835543 789047 742938 705725 74880 80500 2300 0 0 1377
837091 790850 742938 705725 307 0 2500 3100 3100 1303
Die Hohe Entladeleistung der Bat kommt wahrscheinlich von der Ladung eines E-Autos?
Dann gibt es an vorherigen Tagen die Bereiche:
0 - 0 - -200 0 200 0 0 -250
0 - 0 - -400 0 400 0 0 -200
0 - 0 - -199 0 199 0 0 -91
0 - 0 - -1000 0 1000 0 0 -103
- - - - 8901 700 13899 22200 22200 5002
0 - 0 - -700 0 700 0 0 -60
0 - 0 - -200 0 200 0 0 -74
0 - 0 - -200 0 300 0 0 -30
0 - 0 - -100 0 100 0 0 -57
0 - 0 - -300 0 300 0 0 -20
0 - 0 - -300 0 300 0 0 -40
0 - 0 - -200 0 200 0 0 -13
0 - 0 - -300 0 300 0 0 -26
0 - 0 - -100 0 300 200 200 76
0 - 0 - 300 0 300 600 600 278
0 - 0 - -200 0 2200 2000 2000 692
Hier fehlt die Batterie(n).
Ich nehme an du hattest die Batterien bereits im Hausnetz, aber noch nicht in SF integriert.
Der Lade/Entlade-Anteil an fehlt dann in der Summenbildung.
Die History geht normalerweise bis 31 Tage zurück. Du kannst für die Verbrauchsprognose vorerst mit dem Attr affectConsForecastLastDays = 1 oder 2 setzen um nur die letzten 1 bzw. 2 Tage für den Forecast heranzuziehen.
Beachte auch Attr affectConsForecastIdentWeekdays dazu.
ZitatIn SF werden - wahrscheinlich abgesehen von den Zahlen im Flow - ja glücklicherweise Enegiedaten prozessiert, richtig?
Ja, dafür brauche/verwende ich die entsprechenden Schlüssel in den setup-Attributen. Es werden dann entsprechende Differenzen erstellt. Daher kommt auch allgemeine Forderung nach stetig steigenden Zählern wo es wichtig ist.
Zitat von: DS_Starter am 12 Januar 2025, 19:08:35@Parallix auf den ersten Blick ...
Es gibt heute Bereiche die ganz ok. aussehen:
834033 787610 742938 705725 100 100 0 0 0 -59
834033 787610 742938 705725 200 100 0 100 100 60
834033 787610 742938 705725 -18 0 100 300 300 278
834154 787709 742938 705725 699 0 599 2100 2100 682
834564 788144 742938 705725 557 0 301 2800 2800 1350
835543 789047 742938 705725 74880 80500 2300 0 0 1377
837091 790850 742938 705725 307 0 2500 3100 3100 1303
Die Hohe Entladeleistung der Bat kommt wahrscheinlich von der Ladung eines E-Autos?
Nein, ich habe (noch) kein Elekro-Auto.
Wahrscheinlich sind die hohen Werte auf Datenmüll zurückzuführen. Möglicher Grund: Im FHEM BYD-Modul bekomme ich immer mal wieder
Error: Can't connect to 192.168.2.16:8080 bzw. Error: Can't connect to 192.168.2.17:8080 (habe ja zwei BAT-Systeme). Leider bekomme ich WR-seitig derzeit noch nicht alle Daten vom zweiten Akku, da mir hierzu schlicht einige Modbus-Register für BAT2 fehlen.
Zitat von: DS_Starter am 12 Januar 2025, 19:08:35...
Dann gibt es an vorherigen Tagen die Bereiche:
0 - 0 - -200 0 200 0 0 -250
0 - 0 - -400 0 400 0 0 -200
0 - 0 - -199 0 199 0 0 -91
0 - 0 - -1000 0 1000 0 0 -103
- - - - 8901 700 13899 22200 22200 5002
0 - 0 - -700 0 700 0 0 -60
0 - 0 - -200 0 200 0 0 -74
0 - 0 - -200 0 300 0 0 -30
0 - 0 - -100 0 100 0 0 -57
0 - 0 - -300 0 300 0 0 -20
0 - 0 - -300 0 300 0 0 -40
0 - 0 - -200 0 200 0 0 -13
0 - 0 - -300 0 300 0 0 -26
0 - 0 - -100 0 300 200 200 76
0 - 0 - 300 0 300 600 600 278
0 - 0 - -200 0 2200 2000 2000 692
Hier fehlt die Batterie(n).
Ich nehme an du hattest die Batterien bereits im Hausnetz, aber noch nicht in SF integriert.
Der Lade/Entlade-Anteil an fehlt dann in der Summenbildung.
...
Bis zur Einführung der Multi BAT System"-Features in SF hatte ich für SF beide BATs für extern zusammengefasst (lief viele Monate). Die Lücke könnte während der Umstellung "Single BAT System" -> "Multi BAT System" entstanden sein.
Ok. Die weiter oben genannten Attr werden dir sehr wahrscheinlich helfen.
Die pvHistory speichert max. 31 Tage, d.h. die Problemdaten werden nach ihrer Haltezeit sukszessive automatisch bereinigt. Dann kann man die Attr auch wieder hochsetzen bzw. löschen.
Es gibt auch die Methode die pvHistory selektiv oder ganz zu löschen, siehe "set ... reset pvHistory".
Zitat von: DS_Starter am 12 Januar 2025, 19:49:09Ok. Die weiter oben genannten Attr werden dir sehr wahrscheinlich helfen.
Die pvHistory speichert max. 31 Tage, d.h. die Problemdaten werden nach ihrer Haltezeit sukszessive automatisch bereinigt. Dann kann man die Attr auch wieder hochsetzen bzw. löschen.
Es gibt auch die Methode die pvHistory selektiv oder ganz zu löschen, siehe "set ... reset pvHistory".
Habe jetzt affectConsForecastLastDays=1 und affectConsForecastIdentWeekdays=1 gesetzt und bin gespannt, ob die nächsten Tage alles (noch) besser wird.
Bei Sichtung der Modul-Doku ist mir aufgefallen, dass die Beschreibung von affectConsForecastLastDays möglicherweise missverständlich ist, da von vorangegangenen Tagen die Rede ist. Im Zusammenspiel mit affectConsForecastIdentWeekdays sind bei affectConsForecastLastDays aber wahrscheinlich nicht die vorangegangenen Tage, sonder die vorangegangenen Wochentage gemeint. Wenn ja, so könnte man das vielleicht auch so schreiben. ::)
@all,
ich habe ein wenig aufgeräumt:
- das Attr graphicBeam1MaxVal ist obsolet, es ist durch die Weiterentwicklungen bereits länger wirkungslos
- das (experimentelle) Attr ctrlAreaFactorUsage ist obsolet -> die SF Devices Model DWD nutzen jetzt
per Standard die Routine von PAH ergänzt um die Flexanpassung abhängig von der Bewölkung (ursprünglich trackFlex)
- die ComRef ist editiert, @Parallix deinen Hinweis habe ich mit eingearbeitet
Die Anpassungen werden automatisch durchgeführt, ihr braucht nicht aktiv werden außer ggf. "save config" drücken. ;)
LG,
Heiko
In der nächsten Version (morgen früh) ist folgendes eingebaut:
- im Header gibgt es ein weiters Icon zum direkten und einfachen Absprung zum SolarForecast Wiki
- die Berechnung der Verbrauchsprognose ist von einer Durchschnittsermittlung auf die Verwendung des Median
umgestellt. Ich verspreche mir davon eine noch bessere Ausfilterung von Ausreißern zur Unter- oder Oberseite.
Die V liegt auch schon in meinem contrib.
LG
Irgendwo weiter oben hatten ich schon einmal geschrieben. dass (bei Vorliegen mehreren BAT-Devices) ein zusammengeführter SOC nur dann einigermaßen sinnvoll erscheint, wenn er aus den gewichteten Mittelwerten (Wichtung mit der jeweiligen BAT-Kapazität) der einzelnen BAT-SOCs gewonnen wird. Anhand der Modulinfo hat man derzeit noch das Gefühl, dass die o.g Wichtung noch nicht erfolgt, wenn z.B. folgendes betrachtet wird:
ZitatbatteryTrigger ...
...
Der verwendete SoC wird als Durchschnitt des SoC aller definierten Batterie Geräte gebildet.
...
Ist dem wirklich so?
ZitatIrgendwo weiter oben hatten ich schon einmal geschrieben. dass (bei Vorliegen mehreren BAT-Devices) ein zusammengeführter SOC nur dann einigermaßen sinnvoll erscheint, wenn er aus den gewichteten Mittelwerten (Wichtung mit der jeweiligen BAT-Kapazität) der einzelnen BAT-SOCs gewonnen wird. Anhand der Modulinfo hat man derzeit noch das Gefühl, dass die o.g Wichtung noch nicht erfolgt, wenn z.B. folgendes betrachtet wird:
Dein Gefühl täuscht. Für das SoC / Freigabe-Management wird eine Gewichtung für das Management jeder einzelnen Batterie durchgeführt.
Beim batteryTrigger ist es so wie in der Hilfe beschrieben ... die letzen X Messungen des Durchschnittswertes aller Batterien.
Zitat von: DS_Starter am 14 Januar 2025, 08:44:29ZitatIrgendwo weiter oben hatten ich schon einmal geschrieben. dass (bei Vorliegen mehreren BAT-Devices) ein zusammengeführter SOC nur dann einigermaßen sinnvoll erscheint, wenn er aus den gewichteten Mittelwerten (Wichtung mit der jeweiligen BAT-Kapazität) der einzelnen BAT-SOCs gewonnen wird. Anhand der Modulinfo hat man derzeit noch das Gefühl, dass die o.g Wichtung noch nicht erfolgt, wenn z.B. folgendes betrachtet wird:
Dein Gefühl täuscht. Für das SoC / Freigabe-Management wird eine Gewichtung für das Management jeder einzelnen Batterie durchgeführt.
Das ist gut!
Zitat von: DS_Starter am 14 Januar 2025, 08:44:29Beim batteryTrigger ist es so wie in der Hilfe beschrieben ... die letzen X Messungen des Durchschnittswertes aller Batterien.
Gibt es einen Grund, warum hier die Wichtung nicht erfolgt?
ZitatGibt es einen Grund, warum hier die Wichtung nicht erfolgt?
Ja.
Der Trigger, ich zitiere ...
ZitatGeneriert Trigger bei Über- bzw. Unterschreitung bestimmter Batterieladungswerte (SoC in %).
D.h. bei 3 Bat mit je 50% ist der Durchschnitts-SoC auch 50%, bei anderen Verhältnissen entsprechend.
Gibt es einen Use Case warum eine Gewichtung mit welcher Begründung erfolgen sollte ?
Zitat von: DS_Starter am 14 Januar 2025, 09:07:44Gibt es einen Use Case warum eine Gewichtung mit welcher Begründung erfolgen sollte ?
Nach meiner Ansicht schon, insb. bei Vorliegen mehrerer BAT-Systeme mit jeweils stark unterschiedlichen Kapazitäten.
Nehmen wir mal an, es läge ein System mit 2 x 5 kWh und 1 x 20 kWh vor, bei denen die Akkus der 5 kWh-Systeme praktisch leer sind (SOC=5%, vielleicht weil die zuerst leer gefahren wurden), während der Akku des 20 kWh-Systemsnoch voll ist (SOC=100%).
Dann wäre nach Deiner Rechnung der SOC-Durchschnitt (5%+5%+100%)/3 = 37%.
Tatsächlich ist in den Speichern insgeamt aber noch viel mehr an Energie vorhanden, nämlich (5kWh*5%+5kWh*5%+20kWh*100%)/30kWh = 68%. Der Trigger würde also auf Basis einer falsch angenommenen Energiemenge gesetzt oder im inversen Fall gelöscht.
Edit: Im Grund ist alles aber nur eine Frage, was der gemittelte SOC eigentlich aussagen soll. Welche Aussage hast Du hier zu Grund gelegt?
ZitatWelche Aussage hast Du hier zu Grund gelegt?
Steht doch da .... der Durchschnitt der vorhanden SoC.
Das was du meinst ist die Summe aller in den Batterien gespeicherten Energie in Wh in das Verhältnis der installerten gesamten Batteriekapazität (Wh) zu setzen und daraus einen gemeinsamen resultierenden SoC zu errechnen.
Das kann ich machen. Dann stellt sich der "Batteriehaufen" in diesem Kontext als
eine Batterie dar.
Zitat von: DS_Starter am 14 Januar 2025, 10:10:06ZitatWelche Aussage hast Du hier zu Grund gelegt?
Steht doch da .... der Durchschnitt der vorhanden SoC.
Sorry, da habe ich mich ungünstig ausgedrückt. Mich hat hier nicht interessiert, wie Du den Wert bildest (denn das steht ja in der Tat in der Doku), sondern was der gebildete Wert Deiner Ansicht nach in Hinblick auf daraus abgeleitete Maßnahmen aussagt.
Zitat von: DS_Starter am 14 Januar 2025, 10:10:06Das was du meinst ist die Summe aller in den Batterien gespeicherten Energie in Wh in das Verhältnis der installerten gesamten Batteriekapazität (Wh) zu setzen und daraus einen gemeinsamen resultierenden SoC zu errechnen.
Das kann ich machen. Dann stellt sich der "Batteriehaufen" in diesem Kontext als eine Batterie dar.
Dann würde dieser eine Wert die gesamte aktuell gespeicherte Energiemenge charakterisieren, was ich prima fände.
ZitatDann würde dieser eine Wert die gesamte aktuell gespeicherte Energiemenge charakterisieren, was ich prima fände.
Setze ich so um.
Zitat von: Parallix am 14 Januar 2025, 10:18:40Zitat von: DS_Starter am 14 Januar 2025, 10:10:06Das was du meinst ist die Summe aller in den Batterien gespeicherten Energie in Wh in das Verhältnis der installerten gesamten Batteriekapazität (Wh) zu setzen und daraus einen gemeinsamen resultierenden SoC zu errechnen.
Das kann ich machen. Dann stellt sich der "Batteriehaufen" in diesem Kontext als eine Batterie dar.
Dann würde dieser eine Wert die gesamte aktuell gespeicherte Energiemenge charakterisieren, was ich prima fände.
Wie wäre es mit der Nutzung eines Userreading wenn es mal nicht genau das ist was deiner Meinung nach nicht zu finden ist um zu sehen was es bringt ?
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS25","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25","bat_rated_capacity",0))) / ( (ReadingsNum("SBS25","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100}Bei mir ergibt das aber genau dasselbe weil ich 2 gleiche Batterien habe....
Zitat von: 300P am 14 Januar 2025, 10:23:41...
Wie wäre es mit der Nutzung eines Userreading wenn es mal nicht genau das ist was deiner Meinung nach nicht zu finden ist um zu sehen was es bringt ?
Hatte ich bis zur Einführung des Multi-BAT-System auch genau so gemacht.
ZitatDann würde dieser eine Wert die gesamte aktuell gespeicherte Energiemenge charakterisieren, was ich prima fände.
Ich habe den batteryTrigger mal so umgesetzt und zum Test in mein contrib geladen. Die Hilfe ist auch angepasst. Hoffe es ist verständlich ausgedrückt.
LG
Hallo Heiko,
kann es sein das die letzte Version fhem zum Absturz bringt?
Ich musst jedenfalls eine Version zurück - es ging nichts mehr.
Grüße WDS
Hallo Dieter,
da passiert bei mir nicht, läuft stabil.
Aber natürlich können Situationen eintreten die ich evtl. nicht bedacht habe.
Da brauche ich einen Logauszug um die Zeit des Absturzes herum. Dann sehe ich vermutlich die Ursache.
LG
Heiko : siehe PM
LG WDS
Hallo Dieter,
konnte das Problem identifizieren und habe es (hoffentlich) gelöst.
V liegt in meinem contrib. Bitte mal downloaden und testen ob nun alles läuft.
Grüße,
Heiko
und noch'n Dieter mit Absturz :D
Zwar nicht Absturz aber nach dem heutigen update war mein fhem so beschäftigt, dass es sich nicht mehr ansprechen ließ.
Hab jetzt eine 76_SolarForecast.pm von letzter Woche eingespielt, damit startet fhem wieder.
Leider ist mein SF Device "weg" :( Bekomme ich das iwie wieder, ggf mit der aktuellen .pm aus dem Contrib?
Grüße, Dieter
Der-der-erstmal-froh-ist-dass-fhem-wieder-läuft ;)
ZitatLeider ist mein SF Device "weg" :( Bekomme ich das iwie wieder, ggf mit der aktuellen .pm aus dem Contrib?
Ja.
set ... plantConfiguration restore
bzw.
evtl. zusätzlich
set ... operatingMemory recover-<Datei>
Zitat von: DS_Starter am 14 Januar 2025, 13:25:04ZitatLeider ist mein SF Device "weg" :( Bekomme ich das iwie wieder, ggf mit der aktuellen .pm aus dem Contrib?
Ja.
set ... plantConfiguration restore
bzw.
evtl. zusätzlich
set ... operatingMemory recover-<Datei>
Super, alles wieder da, danke ;)
Habe den Fix eingecheckt bevor ich es evtl.heute Abend vergesse.
Korrektur ist dann morgen früh offiziell im Update.
Prima - der Fix läuft.
LG WDS
Hab mal etwas mit graphicHeaderOwnspec gespielt ...
@all,
als Grundlage für Weiterentwicklungen habe ich intern die Datensammlung für PV Forecast und PV Real erweitert. Damit wird es später einmal möglich sein ebenfalls die statistische Median-Methode anzuwenden sowie deutlich mehr Erzeugungs- und Forecast Daten für die Korrektur verfügbar zu haben.
Diese Erweiterung kommt später, aber die dafür nötige Datensammlung ist bereits eincodiert.
Bitte macht das Update auf die V 1.43.6 zeitnah damit ihr den Code im System habt.
Liegt auch bereits im contrib zum Download bereit.
LG,
Heiko
Hallo zusammen,
Kann es sein, dass mit dem letzten Update die SoC Anzeige der Batterie nicht mehr richtig angezeigt wird?
Bei mir steht die in der Grafik aktuell bei 0%, im Reading ,,Current_BatCharge_01" steht der richtige Wert und wird auch aktualisiert.
Oder muss ich an meiner Konfig etwas ändern?
Vielen Dank und Grüße Michael
Hallo Michael,
möglicherweise hast du den Key "cap" in dem setupBatteryDevXX nicht gesetzt?
Das ist wegen dem erweiterten Batteriemanagemnt jetzt obligatorisch.
Wenn es was anderes sein sollte schauen wir morgen nochmal ... bin auf dem Sprung.
LG,
Heiko
Zitat von: DS_Starter am 18 Januar 2025, 16:48:22...
möglicherweise hast du den Key "cap" in dem setupBatteryDevXX nicht gesetzt?
Das ist wegen dem erweiterten Batteriemanagemnt jetzt obligatorisch.
...
Da die Kapazität nun anzugeben ist, lassen sich jetzt auch die Lade- und Endlademengen bezogen auf die Kapazität prozentual darstellen und so schnell in Beziehung mit dem SOC-Anstieg bzw. -Abfall setzen.
PS: Bei ist die SOC-Anzeige in der Flow-Grafik nach dem Update in Ordnung geblieben, hatte aber vorher schon die cap-Angabe für meinen beiden BATs drin.
Meinerseits habe ich einige Geräte, für die mir Verbrauchsdaten aus Messungen vorliegen oder die einen bekannten festen Verbrauch haben, die ich aber nicht nicht smart steuern kann oder sollte (nicht smarter Geschirrspüler sollte nicht mitteln im Programm abgeschaltet werden). Gleichwohl würde ich den aktuelle Verbrauch dieser Geräte gerne in der Flow-Grafik darstellen und im Sinne des Forecasts für den Verbrauch auch berücksichtigen. Letzteres sollte auf Basis der bislang gewonnenen Einschaltzeiten (sind alle sehr ähnlich) mit den dann jeweils gewonnen Verbrauchswerten zumindest prinzipiell bereits möglich sein. Nun frage ich mich, ob dies auch tatsächlich jetzt schon möglich ist und welche Konfigurationseinstellungen dann vorzunehmen sind.
Soeben ist mir noch etwas aufgefallen: In FHEM werden im Fall von EnOcean-basierten schaltbaren UP-Aktoren und Steckdosen (z.B. Eltako FSVA-230V) mit integrierter Leistungsmessung für die Steuerung und Messung üblicherweise unterschiedliche Devices verwendet. Das hat zur Folge, dass die Device-Links bei den in SF registrierten Verbrauchern auf das Metering-Device verweisen und die Set-Kommandos zur Steuerung nicht funktionieren (können).
Edit: Bei interruptable=0 müsste von der Logik her eigentlich zusätzlich keine Regex angegeben werden.
Zitat von: Elektron am 18 Januar 2025, 16:39:49Hallo zusammen,
Kann es sein, dass mit dem letzten Update die SoC Anzeige der Batterie nicht mehr richtig angezeigt wird?
Bei mir steht die in der Grafik aktuell bei 0%, im Reading ,,Current_BatCharge_01" steht der richtige Wert und wird auch aktualisiert.
Oder muss ich an meiner Konfig etwas ändern?
Vielen Dank und Grüße Michael
Die Batterie(n) müssen so "ähnlich" von dir angelegt sein:
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=1
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9800 show=1
Damit sollte es klappen.
Gruß
300P
@Parallix,
ich habe bezüglich deiner Fragen/Anmerkungen im Wiki gleich entsprechende Abschnitte erstellt.
ZitatSoeben ist mir noch etwas aufgefallen: In FHEM werden im Fall von EnOcean-basierten schaltbaren UP-Aktoren und Steckdosen (z.B. Eltako FSVA-230V) mit integrierter Leistungsmessung für die Steuerung und Messung üblicherweise unterschiedliche Devices verwendet. Das hat zur Folge, dass die Device-Links bei den in SF registrierten Verbrauchern auf das Metering-Device verweisen und die Set-Kommandos zur Steuerung nicht funktionieren (können).
Siehe diesen Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Registrierung_eines_Verbrauchers_mit_getrennten_Ger%C3%A4ten_f%C3%BCr_Messung_und_Schalten) im Wiki.
ZitatMeinerseits habe ich einige Geräte, für die mir Verbrauchsdaten aus Messungen vorliegen oder die einen bekannten festen Verbrauch haben, die ich aber nicht nicht smart steuern kann oder sollte (nicht smarter Geschirrspüler sollte nicht mitteln im Programm abgeschaltet werden). Gleichwohl würde ich den aktuelle Verbrauch dieser Geräte gerne in der Flow-Grafik darstellen und im Sinne des Forecasts für den Verbrauch auch berücksichtigen. Letzteres sollte auf Basis der bislang gewonnenen Einschaltzeiten (sind alle sehr ähnlich) mit den dann jeweils gewonnen Verbrauchswerten zumindest prinzipiell bereits möglich sein. Nun frage ich mich, ob dies auch tatsächlich jetzt schon möglich ist und welche Konfigurationseinstellungen dann vorzunehmen sind.
Siehe diesen Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Registrierung_von_Verbrauchern_ohne_Zeitplanung_und_aktivem_Schalten) im Wiki.
ZitatBei interruptable=0 müsste von der Logik her eigentlich zusätzlich keine Regex angegeben werden.
So ist es. interruptable=0 ist der Standard und kann entsprechend weggelassen werden. Außerdem wird bei den Angaben 0/1 ohnehin kein Regex erwartet. Das ist in der Online-Hilfe zum Schlüssel interruptable beschrieben.
Zitat von: DS_Starter am 19 Januar 2025, 08:40:38...
Siehe diesen ... Wiki.
...
Schande über mich - hatte mir nur die Online-Doku angesehen!
ZitatSchande über mich - hatte mir nur die Online-Doku angesehen!
Nein :) ... die Abschnitte habe ich eben erst erstellt weil ich der Meinung war es ist besser gleich niederzuschreiben weil es sicherlich noch mehr User mit ähnlichen Fragestellungen gibt.
LG,
Heiko
Zitat von: DS_Starter am 19 Januar 2025, 08:40:38...
ZitatBei interruptable=0 müsste von der Logik her eigentlich zusätzlich keine Regex angegeben werden.
So ist es. interruptable=0 ist der Standard und kann entsprechend weggelassen werden. Außerdem wird bei den Angaben 0/1 ohnehin kein Regex erwartet. Das ist in der Online-Hilfe zum Schlüssel interruptable beschrieben.
Seltsam, denn wenn ich mein funktionierendes Setting
EnO_FSVA_1_M type=noSchedule power=0 pcurr=power:Wwie folgt ergänze
EnO_FSVA_1_M type=noSchedule power=0 pcurr=power:W interruptable=0, so erhalte ich die (Fehler-)Meldung
Zitatinterruptable: no Regex is provided
Edit: Im letzten Beispiel in der Online-Hilfe zu o.g Attribut steht ganz an Schluss
noshow=noShow Kann es sein, dass die rechte Seite der Zuweisung falsch ist?
Zitaterhalte ich die (Fehler-)Meldung
Zitat
interruptable: no Regex is provided
Das ist dann mein Fehler in der Syntaxprüfung. Muß ich fixen.
Danke für den Hinweis.
@Parallix,
ich habe den Fix vorab in mein contrib geladen.
Du kannst es downloaden und FHEM restarten.
Heute Abend checke ich den Stand noch ein.
Hallo zusammen,
ich suche eine Möglichkeit SolarForecast den Wert für "Current_Consumption" aus einem anderen Reading vorzugeben.
Hintergrund, mein Growatt SPH hat eine Verlustleistung von 20-100W je nach zustand.
SolarForecast nutzt ja die PV Energie als Eingangsgröße, wird geladen wird dieser Wert abgezogen und der Rest ist dann "Current_Consumption"
So habe ich z.B. aktuell eine Abweichung von fast 150W !
Bedingt durch die Regelabweichung habe ich immer +-50W Inport/Export am Stromzähler.
Wunsch wäre eine Möglichkeit Current_Consumption durch einen Messwert eines anderen Gerätes zu ersetzen, im Idealfall zuzüglich positiver Werte des Stromzählers.
Hallo Henno,
ZitatSolarForecast nutzt ja die PV Energie als Eingangsgröße ...
So ganz richtig ist diese Aussage nicht. Die Eingangsgröße für die aktuelle PV-Erzeugung ist das Reading welches im Schlüssel setupInverterDevXX -> pv angegeben ist.
Dort kannst du natürlich ein UserReading angeben welches deine Verlustleistung beeinhaltet.
Der Wert im Reading Current_Consumption verarbeitet ggf. mehrere Wechselrichter, mehrere andere Producer und u.U. mehrere Batterien und ist nur ein Abbild von CurrentVal consumption. Ein direktes Überschreiben ist nicht sinnvoll und nicht valide.
D.h. die Korrektur sollte über das besagte UserReading erfolgen.
Da die geschilderte Problematik durchaus allgemeiner Natur ist, wäre alternativ zu überlegen, ob ich setupInverterDevXX einen Schlüssel für "Verlustleistung" spendiere.
Ich kenne momentan aber kein FHEM-Device welches die Verlustleistung ablesbar liefert oder gibt es das?
LG,
Heiko
Zitat von: DS_Starter am 19 Januar 2025, 11:41:44...
Dort kannst du natürlich ein UserReading angeben welches deine Verlustleistung beeinhaltet.
....
D.h. die Korrektur sollte über das besagte UserReading erfolgen.
Da die geschilderte Problematik durchaus allgemeiner Natur ist, wäre alternativ zu überlegen, ob ich setupInverterDevXX einen Schlüssel für "Verlustleistung" spendiere.
.....
Damit (Schlüssel für "Verlustleistung") könnte mann auch evtl. dauerhafte Messdifferenzen zwischen Energiemeter und dem schlussendlich maßgeblichen EVU-Zähler relativ simpel "reduzieren" ?!?
ZitatDamit (Schlüssel für "Verlustleistung") könnte mann auch evtl. dauerhafte Messdifferenzen zwischen Energiemeter und dem schlussendlich maßgeblichen EVU-Zähler relativ simpel "reduzieren" ?!?
Meinst du damit einen Schlüssel im setupMeterDev oder/auch in den setupInverterDevXX?
Zitat von: 300P am 19 Januar 2025, 12:05:34Zitat von: DS_Starter am 19 Januar 2025, 11:41:44...
Dort kannst du natürlich ein UserReading angeben welches deine Verlustleistung beeinhaltet.
....
D.h. die Korrektur sollte über das besagte UserReading erfolgen.
Da die geschilderte Problematik durchaus allgemeiner Natur ist, wäre alternativ zu überlegen, ob ich setupInverterDevXX einen Schlüssel für "Verlustleistung" spendiere.
.....
Damit (Schlüssel für "Verlustleistung") könnte mann auch evtl. dauerhafte Messdifferenzen zwischen Energiemeter und dem schlussendlich maßgeblichen EVU-Zähler relativ simpel "reduzieren" ?!?
Das einmal anzugehen, halte ich für eine gute Idee!
Im Grund muss unterschieden werden zwischen zufälligen und systematischen (Mess-)Fehlern. Die zufälligen lassen sich nicht korrigieren (mitteln sich aber im Laufe der Zeit raus). Die systematischen Fehler hingegen lassen sich korrigieren. Bei letzteren handelt es zumeist um Fehler, deren Ausmaß durch Vergleichsmessungen (hier geeichte Messgröße am EVU-Zähler vs. ungeeichte Messgröße am Smartmeter) quantifiziert werden kann. Die diese Fehler quantifizierenden Größen sind: Offset und Steigung der (Kalibrierungs-)Kennlinie.
Nach meinen Beobachtungen unterscheiden sich die systematischen Messfehler je nach Richtung des Energieflusses. Wenn das Thema also angepackt wird, so schlage ich vor, möglichst alle diese Aspekte zu berücksichtigen. Damit wären es insg. drei Größen, 1 x Offset und die (o.B.d.A. unterschiedlichen) Steigungen der (Kalibrierungs-)Kennlinie in positiver und negativer Energieflussrichtung.
Ich nehme das Thema mit auf die Agenda.
Es gibt auch eine alterungsbedingte Abnahme der PV-Leistung oder generell einen spezifischen Wirkungsgrad der PV-Module bzw. der gesamten Kette inkl. Wechselrichter Wirkungsgrad.
D.h. die PV-Prognose müsste ohnehin um einen solchen spezifischen Faktor reduziert werden wobei beispielsweise der SolCast API Anbieter die alterungsbedingte Abnahme der PV-Leistung einkalkuliert (Installationsdatum gibt man an). Momentan ist intern ein fester Faktor für den Wirkungsgrad gesetzt.
Zitat von: DS_Starter am 19 Januar 2025, 14:04:41...
Es gibt auch eine alterungsbedingte Abnahme der PV-Leistung oder generell einen spezifischen Wirkungsgrad der PV-Module bzw. der gesamten Kette inkl. Wechselrichter Wirkungsgrad.
D.h. die PV-Prognose müsste ohnehin um einen solchen spezifischen Faktor reduziert werden wobei beispielsweise der SolCast API Anbieter die alterungsbedingte Abnahme der PV-Leistung einkalkuliert (Installationsdatum gibt man an). Momentan ist intern ein fester Faktor für den Wirkungsgrad gesetzt.
Mehr ist meines Erachtens nicht notwendig, da die alterungsbedingte Degradation der PV-Module (sehr) langsam voranschreitet und überdies eigentlich durch die Autokorrektur(faktoren) berücksichtigt sein müsste, oder?
Edit: Das mit dem festen Faktor für den Wirkungsgrad verstehe ich nicht. Der Wirkungsgrad wird doch indirekt durch Angabe der STC-Modulwerte berücksichtigt.
Zitatund überdies eigentlich durch die Autokorrektur(faktoren) berücksichtigt sein müsste, oder?
Ja, das ist natürlich richtig.
ZitatEdit: Das mit dem festen Faktor für den Wirkungsgrad verstehe ich nicht. Der Wirkungsgrad wird doch indirekt durch Angabe der STC-Modulwerte berücksichtigt.
Es geht der Wirkungsgrad der Gesamtanlage ein. Und zwar als Performance Ratio der typischerweise zwischen 0,85 bis 0,9 liegt. Siehe: https://www.xn--ing-bro-junge-0ob.de/html/photovoltaik.html#Ertragsrechnung-Formeln
Aber auch den kann ich mir sparen weil die Autokorrektur auch das berücksichtigt. Einzig wenn man ohne Korrektur arbeitet, wäre dieser Faktor noch relevant.
Forecast sollte mit den Werten arbeiten die es per Readings geliefert bekommt. Jede individuelle Korrektur sollte außerhalb passieren. Ggf. könnte man ein Korrekturmodul erstellen, das Verlustleistung und Degradition berücksichtigt.
Nach ein paar Überlegungen hin und her habe ich das interne Performance Ratio auf 1 gesetzt, d.h. per default keine Abschwächung. Wird in der Realität nicht/kaum spürbar sein.
Später, wenn ich genauer weiß wie ich es umsetze, kann der User einen (dynamischen über Reading) PR-Faktor angeben.
Zitat von: DS_Starter am 19 Januar 2025, 15:52:59Nach ein paar Überlegungen hin und her habe ich das interne Performance Ratio auf 1 gesetzt, d.h. per default keine Abschwächung. Wird in der Realität nicht/kaum spürbar sein.
Später, wenn ich genauer weiß wie ich es umsetze, kann der User einen (dynamischen über Reading) PR-Faktor angeben.
Bevor das gemacht wird, halte ich es für wesentlich sinnvoller, sich etwas mit der Fragestellung zu beschäftigen. wie viel von der angegeben Kapazität eines Batteriesystems tatsächlich zu Verfügung steht. Hier variieren die Werte über das Jahr mitunter erheblich.
ZitatBevor das gemacht wird, halte ich es für wesentlich sinnvoller, sich etwas mit der Fragestellung zu beschäftigen. wie viel von der angegeben Kapazität eines Batteriesystems tatsächlich zu Verfügung steht. Hier variieren die Werte über das Jahr mitunter erheblich.
Sorry, aber mit einem Batteriesystem hat das überhaupt nichts zu tun.
Da liegt wahrscheinlich ein Mißverständnis vor.
Zitat von: DS_Starter am 19 Januar 2025, 19:33:37ZitatBevor das gemacht wird, halte ich es für wesentlich sinnvoller, sich etwas mit der Fragestellung zu beschäftigen. wie viel von der angegeben Kapazität eines Batteriesystems tatsächlich zu Verfügung steht. Hier variieren die Werte über das Jahr mitunter erheblich.
Sorry, aber mit einem Batteriesystem hat das überhaupt nichts zu tun.
Da liegt wahrscheinlich ein Mißverständnis vor.
Was verstehst Du denn unter Wirkungsgrad des Gesamt-Systems? Nach meinem Dafürhalten gilt es zu bilanzieren, wie viel der von außen zugeführten Energie vom System als elektrische Energie beim Endverbraucher ankommt. Dies Zu- und Abhänge erfolgen üblicherweise nicht instantan, sondern verzögert. Die Pufferung übernehmen die BAT-Systeme. Durch diese Pufferung entstehen Verluste. Je mehr BAT-Kapazität (ggf. dynamisch) zur Verfügung steht, umso mehr Verluste könne hier auch entstehen. Ergo: Die Berücksichtigung der BAT-Kapazität kann zur Abschätzung des Wirkungsgrads eines Gesamt-Systems nicht vorgelassen werden. Oder anders ausgedrückt: Ein BAT-loses System, das bei Dunkelheit in den Standby oder gar Abschaltung geht, weist in der Nacht einen besseren Wirkungsgrad auf, als ein BAT-behaftetes System. Während des Tages sieht es ähnlich aus, denn zu den Wechselrichter-Verlusten kommen die durch das BAT-System.
Natürlich ist es trotz der Verluste sinnvoll, ein System mit BATs auszustatten, wenn diese nicht mit teurer Energie vom Versorger, sondern mit kostenfreier Energie der Sonne geladen werden und so einen durch ohne Energie aus dem Netz durch die Nacht bringen. Dies jedoch nur dann, wenn sich die Anschaffungskosten des BAT-Systems während dessen Betriebszeit amortisieren.
Das ist alles richtig was du schreibst und ich stimme dir auch voll zu. Du kannst gern ein mathematisches Modell entwerfen welches ich umsetzen könnte wenn du dich damit beschäftigen magst. Das würde freuen und unterstützen.
Worum es gerade ging, ist einzig und allein der Verkürzungsfaktor der sich aus den PV-Modul Wirkungsgraden und den erzeugenden Wechselrichtern entsprechend der Hinweise aus dem von mir geposteten Link ergibt. Mehr ist momentan nicht, und auch nur als fester Faktor, eingebaut. Da diese Verluste jedoch ohnehin durch die Funktionsautomatik aus Prognose und Real mit berücksichtigt werden, ist dieser feste Abschlag nicht nötig bzw. nicht relevant.
Um mehr ging es momentan nicht.
Interessant sind auch noch die Kosten pro kWh gespeicherter Energie um eine Abschätzung zu haben wann Batteriestrom evtl. teuer ist als Strom aus einem dynamischen Tarif.
Das zumindest theoretisch nicht so kompliziert, will aber auch erstmal gemacht sein.
Hallo zusammen,
morgen früh ist ein Update des Moduls verfügbar und ist aktuell auch bereits in meinem contrib verfügbar.
Was ist neu bzw. umgesetzt:
- Fix interruptable key check im Consumer Attribut, Forum:https://forum.fhem.de/index.php?msg=1331073 (Parallix)
- Hinweis von Parallix in die ComRef eingearbeitet
- es ist ein temporärer Getter "x_migrate" verfügbar
- im Get ... pvCircular kann man jetzt eine Stunde des Tages explizit zur Anzeige wählen
- es ist ein Mitteilungssystem installiert
Der Getter x_migrate:
Ich bin soweit fortgeschritten, dass eine Umstellung der Kalkulation der PV-Vorhersage vom bisherigen Average Modell auf das Median System erfolgen kann. Dazu muß die Datenstruktur geändert werden.
Der User kann nun mit dem "Get ... x_migrate" diese Umstellung vorab vornehmen wann er es für richtig erachtet und er es möchte. Später erfolgt eine Umstellung automatisch per Update, dann sind evtl. die meisten Systeme schon migriert.
Dieses Verfahren bietet sich auch später für zum Beispiel Reading-Umbenennungen an. Dann kann der User entscheiden wann er sich in einer ruhigen Minute dazu entschließt. Als User kann man mit dieser Möglichkeit eine Umstellung auch erst auf einem Testsystem ausführen und später in der Produktion.
Das Mitteilungssystem:
Über dieses System gibt es die Möglichkeit, dem User auf eine fällige Umstellung (wie jetzt mit x_migrate) oder Vorabinformation wann eine relevante Änderung beabsichtigt ist einzuspielen, mitzuteilen.
Auch weitere relevante Informationen können dynamisch mitgeteilt werden.
Es gibt ein zusätzliches Icon im Header der Grafik. Das Icon signalisert ob Mitteilungen vorhanden sind und teilt über die Form und Färbung auf den höchsten Wichtigkeit/Schweregrad aller enthaltenen Mitteilungen hin (siehe Screens im Anhang).
LG,
Heiko
Guten Abdnd Heiko,
bei mir kommt kein "Postfachlogo" - heissen die evtl. nur bei mir anders (message_mail bzw. message_mail_open) ???
Dann würd ich eine Kopie anfertigen mit dem notwendigen Namen.
Gruß
300P
Ach das ist wieder blöd. Ich ändere das Image auf eines was im SVN Default drin ist.
Habe das Modul neu hochgeladen. Kannst nochmal ziehen und testen.
👍
Danach Neustart oder so lassen ?
Steht dir eigentlich frei. Die pvCircular wird regelmäßig gesichert. Dort sind die Daten drin.
Die Post müsste dann raus sein.
Kannst ja mal shutdown restart durchführen.
...nach shutdown / restart ist die Postbox leer O:-)
Edit:
...und ein erneutes get Forecast x_migrate wird (logischerweise) jetzt nicht mehr angeboten
Genau, so soll es sein.
Zitat von: DS_Starter am 19 Januar 2025, 20:18:02Das ist alles richtig was du schreibst und ich stimme dir auch voll zu. Du kannst gern ein mathematisches Modell entwerfen welches ich umsetzen könnte wenn du dich damit beschäftigen magst. Das würde freuen und unterstützen.
Mache ich! Sobald ich etwas konsolidiertes habe, melde ich mich!
Eine Sache lässt sich sicher schon sofort berücksichtigen: Der Langzeitwirkungsgrad eines Batteriesystems. Dieser lässt sich bequem aus der kompletten, bislang von BAT-System gelieferten Energie und der kompletten, bislang vom BAT-System aufgenommenen Energie berechnen. Bei meinen BAT-Systemem liegt dieser Wert nach rund einem Jahr Betrieb jeweils bei ca. 0,894.
Das ist sicherlich interessant und auch wissenswert wie der "Langzeitwirkungsgrad" ist.
Steuern kann man aber mit dem Wert meiner Ansicht nach bei der PV-Erzeugung / Speicherung nicht.
Auch das sollte n.m.M. dort berechnet wo es hin gehört => Batteriemodul / BWR-Reading
Dort gibt es ja auch viele andere BWR-Readings, wie z.B. die Rest-Batteriekapazität (im Verhältnis zur Nennkapazität SoH), die sicherlich zu den nicht zu vernachlässigen Größen / Informationen einer Batterie gehören.
Gruß
300P
Zitat von: 300P am 20 Januar 2025, 11:13:24Das ist sicherlich interessant und auch wissenswert wie der "Langzeitwirkungsgrad" ist.
Steuern kann man aber mit dem Wert meiner Ansicht nach bei der PV-Erzeugung / Speicherung nicht.
Auch das sollte n.m.M. dort berechnet wo es hin gehört => Batteriemodul / BWR-Reading
Dort gibt es ja auch viele andere BWR-Readings, wie z.B. die Rest-Batteriekapazität (im Verhältnis zur Nennkapazität SoH), die sicherlich zu den nicht zu vernachlässigen Größen / Informationen einer Batterie gehören.
Reicht dafür nicht die dynamische Kapazität?
cap installed battery capacity. Option can be:
<Readingname>:<unit> - Reading which provides the capacity and unit (Wh, kWh)
Zitat von: DS_Starter am 05 Januar 2025, 23:30:51- die Batterien bzw. deren Ladungsempfehlungs-Status für die kommenden Stunden können in der
Balkengrafik Ebene 1 eingeblendet werden. Ein Mouse-Over zeigt nähere Informationen zum Batteriestatus.
- Zur grafischen Steuerung der Batterien gibt es nun zusätzliche optionale Schlüssel und den setupBatteryDevXX Attributen
Ich fände es noch gut, wenn in der Vergangenheit der tatsächliche Ladestand der Batterie angezeigt wird, von mir aus auch über Parameter einblendbar.
Beim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Warum meine Werte so schräg sind muss ich noch untersuchen, aber ich hab ja auch das Problem mit dem PV Zählerstand-Fehler, obwohl alles richtig angezeigt wird.
PVForecastBat.png
Im Attribut "setupBatteryDev1" wird unter "cap" der Wert "Nennkapazität"eingetragen, den der Hersteller für diese Batterie (=100%) angibt:
cap installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)
Im Lauf der Zeit steht dieser Wert aber dann nicht mehr voll zur Verfügung.
Er verringert sich leider immer mehr (damit meinte ich "Rest-Batteriekapazität" im Verhältnis zur Nennkapazität SoH).....
Im BWR kann man diesen (meist) als Readingwert % / Faktor etc. sehen.
Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.
Der Wechselrichter berücksichtigt dies bei der Angabe bzw. Berechnung und anzeige des Ladestatus aber bereits.
Der Wert nützt mir deshalb auch nicht viel im SF.
Das ist ebenfalls ein reine Information wie "schlecht" meine Batterien im laufe der Betriebsjahre geworden sind.
Den Wert braucht man n.m.M. in SF auch nicht.
Gruß
300P
Zitat von: minierm am 20 Januar 2025, 15:59:06Ich fände es noch gut, wenn in der Vergangenheit der tatsächliche Ladestand der Batterie angezeigt wird, von mir aus auch über Parameter einblendbar.
Beim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Warum meine Werte so schräg sind muss ich noch untersuchen, aber ich hab ja auch das Problem mit dem PV Zählerstand-Fehler, obwohl alles richtig angezeigt wird.
Nutze doch "graphicBeam3Content" und "graphicBeam4Content"
ZitatBeim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Da fehlt eine Grenze nach oben im Code.
Fixe ich.
ZitatIch fände es noch gut, wenn in der Vergangenheit der tatsächliche Ladestand der Batterie angezeigt wird, von mir aus auch über Parameter einblendbar.
Der Wunsch kam hier bereits weiter vorn.
Das ist für mich schon etwas mehr Aufwand weshalb ich darauf verzichtet habe. Aber wenn es genug Interessenten dafür gibt kann ich mir das schon mal vornehmen.
Alternativ kann man aktuell dem Hinweis von 300P folgen ...
Zitat von: minierm am 20 Januar 2025, 15:59:06Beim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Warum meine Werte so schräg sind muss ich noch untersuchen, aber ich hab ja auch das Problem mit dem PV Zählerstand-Fehler, obwohl alles richtig angezeigt wird.
Evtl. hast du noch nicht alle aktuellen Updates von SF geladen - da fehlen die 2 neuen Symbole (Wiki / Mitteilung)
Im Rahmen meiner ersten Einarbeitung in das Modul, hab ich Fragen zu den Comsumern:
pCurr: kann ich da auch einen DeviceNamen angeben? Ich hab gleich 2 Fälle bei denen der Stromverbrauch in einem ganzen anderen Device gemessen wird, als das eigentlich zu steuernde Device?
Wahrscheinlich hab ich all die Möglichkeiten noch nicht voll durchblickt um Geräte einzuschalten. Ich hätte aber folgendes Szenarios:
1. Eine Waschmaschine soll verzögert eingeschaltet werden. Es gibt ein Trigger, dass der RemoteStart (HomeConnect) aktiviert wurde. Wenn genug Strom da ist, kann sie gleich loslaufen, sonst darf sie maximal 30 Minuten stehen, sonst leidet der WAF. (Ähnliches für Spülmaschine) - eigentlich soll das hauptsächlich verhindern, dass beide Waschmaschinen gleichzeitig ihren Peak Verbrauch haben, was potentiell den Inverter meiner Batterie überfordern könnte.
2. Warmwasserwärmepumpe soll nur laufen wenn genug Strom da ist. Bei Überschuss bis zu 60 Grad, sonst reichen 50 Grad - wenn klar ist das die nächsten X Stunden kein Solarstrom da ist oder eine Mindesttemperatur unterschritten ist, muss sie trotzdem laufen, damit keiner kalt duschen muss
3. Umwälzpumpe Pool soll X Stunden am Tag laufen - wann ist egal, aber wenn der Strom nicht kommt, müssen die X Stunden/Tag trotzdem erreicht werden damit er nicht grün wird
4. Trockner darf pausiert werden, wenn nicht genug Strom da ist, soll aber auf jeden Fall spätestens nach X Stunden fertig sein
Zitat von: Adimarantis am 20 Januar 2025, 17:20:59Im Rahmen meiner ersten Einarbeitung in das Modul, hab ich Fragen zu den Comsumern:
pCurr: kann ich da auch einen DeviceNamen angeben? Ich hab gleich 2 Fälle bei denen der Stromverbrauch in einem ganzen anderen Device gemessen wird, als das eigentlich zu steuernde Device?
Auszug aus dem Wiki....
In dem nachfolgenden Beispiel (Homematic) ist eg.az.fridge_Pwr FHEM Device für die Energiemessung. Die Schlüssel pcurr und etotal geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel switchdev das zugehörige Schalter-Device der Kombination angegeben.
eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh
swstate=state:on:off auto=automatic
Zitat von: 300P am 20 Januar 2025, 18:02:11Auszug aus dem Wiki....
Ja, aber nicht ganz die Lösung die ich im Sinn hatte.
Das Hauptdevice wäre dann der Stromzähler während das eigentlich zu regelnde Device nur im switchdev versteckt ist.
Ich fände es schicker, wenn man z.B. pcurr=[stromzähler:power]:W angeben könnte.
Entsprechend könnte man das auch für etotal und swstate machen (und sich switchdev komplett sparen)
ZitatIch fände es schicker, wenn man z.B. pcurr=[stromzähler:power]:W angeben könnte.
Entsprechend könnte man das auch für etotal und swstate machen (und sich switchdev komplett sparen)
Frage drei Leute und du bekommst drei Meinungen. ;)
Der nächste würde einwenden wieso er denn vor jedes Reading noch das Device in den Schlüssel pcurr, etotal bzw. swstate, on, off etc. angeben muß wo doch eine einmalige Angabe reichen sollte das Device für Messen und Schalten zu definieren. Der Rest ergibt sich dann daraus ... und dieser Meinung bin ich ebenso.
Aber, wie gesagt, hat da wohl jeder so seine Vorlieben.
EDIT: Deine anderen UseCases für Verbraucher würde ich ggf. auch über das Wiki beantworten wenn es sich anbietet sie gleich für die Nachnutzung zu beschreiben. Sonst ist es einfach zu uneffektiv hier zu antworten ... das geht verloren.
Zitat von: DS_Starter am 20 Januar 2025, 19:02:27Der nächste würde einwenden wieso er denn vor jedes Reading noch das Device in den Schlüssel pcurr, etotal bzw. swstate, on, off etc. angeben muß wo doch eine einmalige Angabe reichen sollte
Das hatte ich Optional im Sinn - default wäre das Hauptdevice. Leider ist der ":" als Trenner vergeben, daher mein Beispiel mit Klammer wie in DOIF. Außerdem musst du ja möglichst Rückwärtskompatibel bleiben.
Aber wenn das nicht geht, eventuell zumindest eine Option den Namen zu überschreiben (aktuell ist ja scheinbar der alias der "Hauptdevice")?
ZitatEDIT: Deine anderen UseCases für Verbraucher würde ich ggf. auch über das Wiki beantworten wenn es sich anbietet sie gleich für die Nachnutzung zu beschreiben. Sonst ist es einfach zu uneffektiv hier zu antworten ... das geht verloren.
Gerne. Das mach ich auch oft so.
ZitatAber wenn das nicht geht, eventuell zumindest eine Option den Namen zu überschreiben (aktuell ist ja scheinbar der alias der "Hauptdevice")?
Das ist eigentlich eine Fallunterscheidung.
Vereint das Device Messung und Schaltung gibt man das Device am Beginn des Attr an und gut.
Sind Messung und Schaltung getrennt, gibt man das Device für die Messung am Beginn des Attr an und das Device für das Schalten über switchdev=<Dev> und damit ist die Sache erledigt.
Für diverse Anzeigen Mouse-Over etc. wird der Alias (falls gesetzt) als sprechender Name für die jeweiligen Devices herangezogen.
Insofern habe ich nicht wirklich verstanden was du gern überschreibbar haben möchtest?
Zitat von: DS_Starter am 20 Januar 2025, 19:18:52Insofern habe ich nicht wirklich verstanden was du gern überschreibbar haben möchtest?
Den Namen der in der Verbraucherliste (Grafikbereich 3) steht (bzw. MouseOver in der Grafik 5)
Da steht halt statt dem eigentlichen Gerät um das es geht jetzt "Stromzähler ..."
@minierm,
hast du in deinem Batteriedevice den Schlüssel "cap" angegeben und hat der den korrekten Wert?
Lt. Codierung kann SoC > 100% nur auftreten wenn die erreichte Ladung der Batterie über dem Wert lt. Schlüssel 'cap' liegt.
ZitatDen Namen der in der Verbraucherliste (Grafikbereich 3) steht (bzw. MouseOver in der Grafik 5)
Da steht halt statt dem eigentlichen Gerät um das es geht jetzt "Stromzähler ..."
Ja, bei diesen Anzeigen verwende ich den Alias der Dev sofern gesetzt. Der Alias ist meist ein sprechender Name der das Device besser beschreiben kann. Im einfachsten Fall einfach den Alias des Dev abändern oder gar löschen wenn er nicht gebraucht wird. Dann kommt der FHEM-Devicename.
Edit: Was auch relativ problemlos umsetzbar wäre z.B. bei der Definition
Steckdose1[:Alias für das Dev] switchdev=Steckdose1[:Alias für das Schalterdevice] icon=inverter@brown
Damit könnte man in SF einen anderen Alias verwenden als den Alias den man dem Devices in FHEM gegeben hat.
Zitat von: DS_Starter am 20 Januar 2025, 19:32:32Edit: Was auch relativ problemlos umsetzbar wäre z.B. bei der Definition
Steckdose1[:Alias für das Dev] switchdev=Steckdose1[:Alias für das Schalterdevice] icon=inverter@brown
Damit könnte man in SF einen anderen Alias verwenden als den Alias den man dem Devices in FHEM gegeben hat.
Das wäre doch schön - wenn ich den Alias im Device ändere schauts in der FHEM Übersicht wieder seltsam aus.
ZitatDas wäre doch schön - wenn ich den Alias im Device ändere schauts in der FHEM Übersicht wieder seltsam aus.
Nehme ich auf meine ToDo.
LG
Hallo zusammen,
das Modul ist echt super!
Lese mit Begeisterung die ganze Entwicklung.
Wäre es möglich die Icons der Consumer[xx] in der Energieflußgrafik als Tabelle darzustellen? Bei 16 Geräten z.b. als 4x4, oder allgem. definierbar?
Viele Grüße
Christian
Hallo Christian,
ich möchte nicht behaupten es würde nicht gehen. Da muß man Hirnschmalz und Zeit investieren.
Kannst du uns näher beschreiben (oder mit Screenshot) was der konkrete Grund deiner Anfrage ist?
LG,
Heiko
Hallo Heiko,
versuche es kurz zu beschreiben...
Hab selbst ein Balkonkraftwerk mit Speicher.
Aktuell nutze ich das Modul zur Anzeige und Sammlung von Daten.
Somit habe ich auch Verbraucher in der Anzeige die nie aktiv geschalten werden. Deren aktuellen Verbrauch zu sehen - soweit vorhanden - finde ich durchaus interessant. Bei 16 Geräten in Reihe kann dies je nach Endgerät allgemein recht klein werden.
LG
Christian
ZitatBei 16 Geräten in Reihe kann dies je nach Endgerät allgemein recht klein werden.
Hast du mal mit den Einstellungen im Attr flowGraphicControl -> size gespielt?
Es gibt noch weitere Schlüssel consumerdist, h2consumerdist die in dem Zusammenhang dienlich sein könnten.
Zitat von: DS_Starter am 20 Januar 2025, 19:27:53hast du in deinem Batteriedevice den Schlüssel "cap" angegeben und hat der den korrekten Wert?
Lt. Codierung kann SoC > 100% nur auftreten wenn die erreichte Ladung der Batterie über dem Wert lt. Schlüssel 'cap' liegt.
Wert korrekt, aber falsche Einheit ;-) 11.5kWh statt 11500 Wh...
Zitat von: 300P am 20 Januar 2025, 16:18:35Im Attribut "setupBatteryDev1" wird unter "cap" der Wert "Nennkapazität"eingetragen, den der Hersteller für diese Batterie (=100%) angibt:
cap installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)
Im Lauf der Zeit steht dieser Wert aber dann nicht mehr voll zur Verfügung.
Er verringert sich leider immer mehr (damit meinte ich "Rest-Batteriekapazität" im Verhältnis zur Nennkapazität SoH).....
Im BWR kann man diesen (meist) als Readingwert % / Faktor etc. sehen.
Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.
Und genau diese Rechnung könntest Du doch in einem Userreading ablegen und an SF übergeben?
Zitat von: DS_Starter am 20 Januar 2025, 21:05:03ZitatBei 16 Geräten in Reihe kann dies je nach Endgerät allgemein recht klein werden.
Hast du mal mit den Einstellungen im Attr flowGraphicControl -> size gespielt?
Es gibt noch weitere Schlüssel consumerdist, h2consumerdist die in dem Zusammenhang dienlich sein könnten.
Hilft leider nicht wirklich. Bestenfalls werden nur die Icons inkl. Schrift unleserlich, aber dafür nicht die anderen anderen grafischen Ebenen darüber.
Können vielleicht inaktive Verbraucher bei pcurr=xx:xx:"kleiner diesem Wert" ausgeblendet werden?
Ich habe mal einen Test mit folgendem flowGraphicControl Attributinhalt erstellt:
animate=1
consumerdist=90
h2consumerdist=50
shiftx=0
shifty=0
showconsumer=1
showconsumerdummy=1
showconsumerpower=1
showconsumerremaintime=0
size=600 strokewidth=12
Sieht dann aus wie im Anhang (16 Consumer).
Zitat von: 300P am 20 Januar 2025, 16:18:35Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.
Ist zwar OT, aber darf ich fragen wie alt die Batterien sind und um welche Zellchemie es sich jeweils dabei handelt?
Zitat von: DS_Starter am 20 Januar 2025, 19:27:53@minierm,
hast du in deinem Batteriedevice den Schlüssel "cap" angegeben und hat der den korrekten Wert?
Lt. Codierung kann SoC > 100% nur auftreten wenn die erreichte Ladung der Batterie über dem Wert lt. Schlüssel 'cap' liegt.
Es wird also die dem BAT-System zugeführte Energie ohne einen Abschlag (eigentlich erforderlich, da Wirkungsgrad immer kleiner 1.0) für den Forecast des SOC verwendet?
Zitat von: TheTrumpeter am 21 Januar 2025, 06:56:25Zitat von: 300P am 20 Januar 2025, 16:18:35Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.
Ist zwar OT, aber darf ich fragen wie alt die Batterien sind und um welche Zellchemie es sich jeweils dabei handelt?
siehe Fusszeile - leider 2 x Hochvolt LGRESU10H ca. 6 bzw. 8 Jahre alt - Gott sei Dank ohne deren berüchtigten "Aufblähungen" (bislang)
Zitat von: minierm am 20 Januar 2025, 21:21:37Zitat von: 300P am 20 Januar 2025, 16:18:35Im Attribut "setupBatteryDev1" wird unter "cap" der Wert "Nennkapazität"eingetragen, den der Hersteller für diese Batterie (=100%) angibt:
cap installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)
Im Lauf der Zeit steht dieser Wert aber dann nicht mehr voll zur Verfügung.
Er verringert sich leider immer mehr (damit meinte ich "Rest-Batteriekapazität" im Verhältnis zur Nennkapazität SoH).....
Im BWR kann man diesen (meist) als Readingwert % / Faktor etc. sehen.
Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.
Und genau diese Rechnung könntest Du doch in einem Userreading ablegen und an SF übergeben?
Klar - da würde ich genauer als bisher - aber.....
Hatte ich - mir reicht es aber wenn SF über den XY % Batterieladestatus weiss wie der Status der Batterie ist.
Hintergrund:
Ich hatte erst vor mit Tibber oder einem anderen dynamischen Stromtarif zu laden / entladen und den Strombezug / Einspeisung zu berücksichtigen. Da wäre es sicherlich angebracht gewesen.
Der dynamische Tarif ist aber (bei meinen Gegebenheiten) nach einer 12 monatigen Probephase bei mir negativ "aufgestoßen" und wäre in diesem Winter dann mit den hohen Preisen bei einem Kostenvergleich "noch mehr daneben" gewesen..
Deshalb hatte ich im abgeschnittenen Zitatausschnitt geschrieben:
Der Wechselrichter berücksichtigt dies bei der Angabe bzw. Berechnung und anzeige des Ladestatus aber bereits.
Der Wert nützt mir deshalb auch nicht viel im SF.
Das ist ebenfalls ein reine Information wie "schlecht" meine Batterien im laufe der Betriebsjahre geworden sind.
Den Wert braucht man n.m.M. in SF auch nicht.
Gruß
300P
Gruß
300P
ZitatEs wird also die dem BAT-System zugeführte Energie ohne einen Abschlag (eigentlich erforderlich, da Wirkungsgrad immer kleiner 1.0) für den Forecast des SOC verwendet?
Anderer Sachverhalt.
Durch das Batteriedevice wird der SoC in Prozent geliefert. Mit der Hochrechnung der wahrscheinlichen Ladungsmenge der nächsten Stunden kommt man auf den wahrscheinlichen Ziel-SoC. Da stecken etliche Wahrscheinlichkeiten drin, wie prognostizierte PV und prognostizierter Verbrauch. Mit der cap-Angabe im Attr erfolgt die Umrechnung in das Wh Äquivalent. Der Umwandlungsverlust der Ladung würde auch noch mit eingehen, hat allerdings im Verhältnis der beschriebenen Einflußfaktoren eine eher marginale Rolle.
Unabhängig davon wird max SoC in Wh begrenzt auf cap, d.h. cap kann nicht überschritten werden wenn richtig angegeben.
Zitat von: DS_Starter am 21 Januar 2025, 10:04:25ZitatEs wird also die dem BAT-System zugeführte Energie ohne einen Abschlag (eigentlich erforderlich, da Wirkungsgrad immer kleiner 1.0) für den Forecast des SOC verwendet?
Anderer Sachverhalt.
Durch das Batteriedevice wird der SoC in Prozent geliefert. Mit der Hochrechnung der wahrscheinlichen Ladungsmenge der nächsten Stunden kommt man auf den wahrscheinlichn Ziel-SoC. Da stecken etliche Wahrscheinlichkeiten drin, wie prognostizierte PV und prognostizierter Verbrauch. Mit der cap-Angabe im Attr erfolgt die Umrechnung in das Wh Äquivalent.
Leider gibt es in FHEM bis dato keine Auftrennung eines BAT-Devices in Low- und High-Level-Anteil. Dies macht es mir auch schwer, für den ansonsten guten Ansatz zu sein, dass alles, was primär eher BAT-bezogen ist, funktionstechnisch auch vom BAT-Device zu fordern. Spätestens dann, wenn hier in Deinem Modul von SOC auf Energie und umgekehrt abgebildet wird, ist das aber problematisch.
Für's erste schlage ich – analog zu den pv_correctionFactors – vor, auch bei der Berücksichtigung von Be- und Endladung der BATs in SF entsprechende Korrekturfaktoren einzubauen und in SF ermittelte und insb. angezeigte SOC-Werte oben (bei 100%) und unten (bei 0%) zu kappen.
Zitatund insb. angezeigte SOC-Werte oben (bei 100%) und unten (bei 0%) zu kappen.
Das ist kein Problem und baue ich ein.
ZitatLeider gibt es in FHEM bis dato keine Auftrennung eines BAT-Devices in Low- und High-Level-Anteil.
..
Spätestens dann, wenn hier in Deinem Modul von SOC auf Energie und umgekehrt abgebildet wird, ist das aber problematisch.
Was ist mit "Auftrennung eines BAT-Devices in Low- und High-Level-Anteil" gemeint?
Kannst du es näher erläutern?
ZitatZitat
und insb. angezeigte SOC-Werte oben (bei 100%) und unten (bei 0%) zu kappen.
Das ist kein Problem und baue ich ein.
Habe mich jetzt jedoch dagegen entschieden, da wie der Fall bei minierm gezeigt, man durch diese Unstimmigkeit auf die Falscheingabe aufmerksam wird was sonst nicht passiert wäre.
Dadurch kann man ihn korrigieren, ansonsten würde an anderen Stellen evtl. auch zu Auswirkungen führen.
Es ist mir wichtig dass die Eingangswerte stimmig sind.
Moins, ich habe mein FHEM und das Debian drunter einem Update unterzogen. Beim FHEM kann ich nicht genau den Versionssprung benennen.
das hat auch schon mal alles funktioniert: https://forum.fhem.de/index.php?topic=137058.msg1306725#msg1306725
Leider wird jetzt mein Akkustand in der Grafik nicht mehr angezeigt:
screenshot angehangen
Ausgelesen wird er vom Modbus sauber, aktueller Ladestand sind um die 18%.
Ich habe in der Zeile erfolglos rumprobiert
setupBatteryDev01 SH08rt01 pin=Battery_power_in:W pout=Battery_power_out:W charge=Battery_Level cap=9600Wh intotal=Total_battery_charge_energy:kW outtotal=Total_battery_discharge_energy:kW
Was uebersehe ich hier?
Christian
define DWDSolarVorhersage SolarForecast
attr DWDSolarVorhersage consumer01 ws01_WaMa power=0 type=washingmachine pcurr=power:W interruptable=0 icon=scene_washing_machine
attr DWDSolarVorhersage consumer02 ws02_WaeTrockner power=0 type=dryer pcurr=power:W interruptable=0 icon=scene_clothes_dryer
attr DWDSolarVorhersage consumer03 ws_GeschirrSpueler power=0 type=dishwasher pcurr=power:W interruptable=0 icon=scene_dishwasher
attr DWDSolarVorhersage event-on-change-reading .*
attr DWDSolarVorhersage room PV
attr DWDSolarVorhersage setupBatteryDev01 SH08rt01 pin=Battery_power_in:W pout=Battery_power_out:W charge=Battery_Level cap=9600Wh intotal=Total_battery_charge_energy:kW outtotal=Total_battery_discharge_energy:kW
attr DWDSolarVorhersage setupInverterDev01 SH08rt01 pv=Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000
attr DWDSolarVorhersage setupInverterStrings Süddach,Norddach
attr DWDSolarVorhersage setupMeterDev SH08rt01 gcon=GridConsumption:W gfeedin=GridFeed:W contotal=Total_Import_Energy:kWh feedtotal=Total_Export_Energy:kWh
attr DWDSolarVorhersage setupRadiationAPI DWD
attr DWDSolarVorhersage setupStringPeak Süddach=5.0 Norddach=4.6
attr DWDSolarVorhersage setupWeatherDev1 DWD
# FUUID 65c13ae3-f33f-b392-aa25-dd77aac21c22996e
# FVERSION 76_SolarForecast.pm:v1.44.0-s29540/2025-01-19
# LCACHEFILE last write time: 10:39:28 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 10:45:37
# MODEL DWD
# NAME DWDSolarVorhersage
# NOTIFYDEV SH08rt01,ws01_WaMa,ws02_WaeTrockner,ws_GeschirrSpueler
# NR 271
# NTFY_ORDER 50-DWDSolarVorhersage
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 38
# HELPER:
# 01M15DONE 1
# 02M15DONE 1
# 03M15DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV DWDSolarVorhersage
# SPGROOM
# VERSION 1.44.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.2
# OLDREADINGS:
# READINGS:
# 2025-01-21 10:44:27 Current_AutarkyRate 100 %
# 2025-01-21 10:44:27 Current_BatCharge_01 18.8 %
# 2025-01-21 10:44:27 Current_Consumption 648 W
# 2025-01-21 10:44:27 Current_GridConsumption 0 W
# 2025-01-21 10:44:27 Current_GridFeedIn 0 W
# 2025-01-21 10:44:27 Current_PV 1576 W
# 2025-01-21 10:44:27 Current_PowerBatIn_01 928 W
# 2025-01-21 10:44:27 Current_PowerBatOut_01 0 W
# 2025-01-21 10:44:27 Current_SelfConsumption 648 W
# 2025-01-21 10:44:27 Current_SelfConsumptionRate 41 %
# 2025-01-21 10:44:27 Current_Surplus 928 W
# 2025-01-21 10:00:00 LastHourGridconsumptionReal 200 Wh
# 2025-01-21 10:00:00 LastHourPVforecast 200 Wh
# 2025-01-21 10:00:00 LastHourPVreal 500 Wh
# 2025-01-21 10:44:27 NextHours_Sum01_PVforecast 1200 Wh
# 2025-01-21 10:44:27 NextHours_Sum02_PVforecast 2708 Wh
# 2025-01-21 10:44:27 NextHours_Sum03_PVforecast 4619 Wh
# 2025-01-21 10:44:27 NextHours_Sum04_ConsumptionForecast 4825 Wh
# 2025-01-21 10:44:27 NextHours_Sum04_PVforecast 5944 Wh
# 2025-01-21 10:44:27 RestOfDayConsumptionForecast 11076 Wh
# 2025-01-21 10:44:27 RestOfDayPVforecast 7173 Wh
# 2025-01-21 00:59:53 Today_Hour01_BatIn_01 0 Wh
# 2025-01-21 00:59:53 Today_Hour01_BatOut_01 0 Wh
# 2025-01-21 00:59:53 Today_Hour01_GridConsumption 400 Wh
# 2025-01-21 00:59:53 Today_Hour01_GridFeedIn 0 Wh
# 2025-01-21 00:59:53 Today_Hour01_PVreal 0 Wh
# 2025-01-21 01:59:49 Today_Hour02_BatIn_01 0 Wh
# 2025-01-21 01:59:49 Today_Hour02_BatOut_01 0 Wh
# 2025-01-21 01:59:49 Today_Hour02_GridConsumption 400 Wh
# 2025-01-21 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2025-01-21 01:59:49 Today_Hour02_PVreal 0 Wh
# 2025-01-21 02:59:49 Today_Hour03_BatIn_01 0 Wh
# 2025-01-21 02:59:49 Today_Hour03_BatOut_01 0 Wh
# 2025-01-21 02:59:49 Today_Hour03_GridConsumption 500 Wh
# 2025-01-21 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2025-01-21 02:59:49 Today_Hour03_PVreal 0 Wh
# 2025-01-21 03:59:49 Today_Hour04_BatIn_01 0 Wh
# 2025-01-21 03:59:49 Today_Hour04_BatOut_01 0 Wh
# 2025-01-21 03:59:49 Today_Hour04_GridConsumption 400 Wh
# 2025-01-21 03:59:49 Today_Hour04_GridFeedIn 0 Wh
# 2025-01-21 03:59:49 Today_Hour04_PVreal 0 Wh
# 2025-01-21 04:59:49 Today_Hour05_BatIn_01 0 Wh
# 2025-01-21 04:59:49 Today_Hour05_BatOut_01 0 Wh
# 2025-01-21 04:59:49 Today_Hour05_GridConsumption 400 Wh
# 2025-01-21 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2025-01-21 04:59:49 Today_Hour05_PVreal 0 Wh
# 2025-01-21 05:59:58 Today_Hour06_BatIn_01 0 Wh
# 2025-01-21 05:59:58 Today_Hour06_BatOut_01 0 Wh
# 2025-01-21 05:59:58 Today_Hour06_GridConsumption 900 Wh
# 2025-01-21 05:59:58 Today_Hour06_GridFeedIn 0 Wh
# 2025-01-21 05:59:58 Today_Hour06_PVreal 0 Wh
# 2025-01-21 06:59:49 Today_Hour07_BatIn_01 0 Wh
# 2025-01-21 06:59:49 Today_Hour07_BatOut_01 0 Wh
# 2025-01-21 06:59:49 Today_Hour07_GridConsumption 500 Wh
# 2025-01-21 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2025-01-21 06:59:49 Today_Hour07_PVreal 0 Wh
# 2025-01-21 07:59:49 Today_Hour08_BatIn_01 0 Wh
# 2025-01-21 07:59:49 Today_Hour08_BatOut_01 0 Wh
# 2025-01-21 07:59:49 Today_Hour08_GridConsumption 500 Wh
# 2025-01-21 07:59:49 Today_Hour08_GridFeedIn 0 Wh
# 2025-01-21 07:59:49 Today_Hour08_PVreal 0 Wh
# 2025-01-21 08:59:49 Today_Hour09_BatIn_01 0 Wh
# 2025-01-21 08:59:49 Today_Hour09_BatOut_01 0 Wh
# 2025-01-21 08:59:49 Today_Hour09_GridConsumption 400 Wh
# 2025-01-21 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2025-01-21 08:59:49 Today_Hour09_PVforecast 18 Wh
# 2025-01-21 08:59:49 Today_Hour09_PVreal 0 Wh
# 2025-01-21 09:59:49 Today_Hour10_BatIn_01 0 Wh
# 2025-01-21 09:59:49 Today_Hour10_BatOut_01 0 Wh
# 2025-01-21 09:59:49 Today_Hour10_GridConsumption 200 Wh
# 2025-01-21 09:59:49 Today_Hour10_GridFeedIn 0 Wh
# 2025-01-21 09:59:49 Today_Hour10_PVforecast 200 Wh
# 2025-01-21 09:59:49 Today_Hour10_PVreal 500 Wh
# 2025-01-21 10:44:27 Today_Hour11_BatIn_01 0 Wh
# 2025-01-21 10:44:27 Today_Hour11_BatOut_01 0 Wh
# 2025-01-21 10:44:27 Today_Hour11_GridConsumption 300 Wh
# 2025-01-21 10:44:27 Today_Hour11_GridFeedIn 0 Wh
# 2025-01-21 10:44:27 Today_Hour11_PVforecast 1500 Wh
# 2025-01-21 10:44:27 Today_Hour11_PVreal 700 Wh
# 2025-01-21 10:44:27 Today_Hour12_PVforecast 1100 Wh
# 2025-01-21 10:44:27 Today_Hour13_PVforecast 1644 Wh
# 2025-01-21 10:44:27 Today_Hour14_PVforecast 2000 Wh
# 2025-01-21 10:44:27 Today_Hour15_PVforecast 1100 Wh
# 2025-01-21 10:44:27 Today_Hour16_PVforecast 754 Wh
# 2025-01-21 10:44:27 Today_Hour17_PVforecast 200 Wh
# 2025-01-21 10:44:27 Today_MaxPVforecast 2000 Wh
# 2025-01-21 10:44:27 Today_MaxPVforecastTime 2025-01-21 13:00:00
# 2025-01-21 10:44:27 Today_PVforecast 8516 Wh
# 2025-01-21 10:44:27 Today_PVreal 1200 Wh
# 2025-01-21 10:44:27 Today_SunRise 08:23
# 2025-01-21 10:44:27 Today_SunSet 17:03
# 2025-01-21 10:44:27 Tomorrow_ConsumptionForecast 17899 Wh
# 2025-01-21 10:44:27 Tomorrow_PVforecast 5181 Wh
# 2025-01-21 10:44:27 Tomorrow_SunRise 08:22
# 2025-01-21 10:44:27 Tomorrow_SunSet 17:05
# 2025-01-21 10:44:27 consumer01 name='Waschmaschine' state='on' mode='can' planningstate='planned'
# 2025-01-21 10:44:27 consumer01_currentPower 68.091 W
# 2025-01-21 10:44:27 consumer01_planned_start 21.01.2025 10:28:06
# 2025-01-21 10:44:27 consumer01_planned_stop 21.01.2025 12:28:06
# 2025-01-21 10:44:27 consumer02 name='Waeschetrockner' state='on' mode='can' planningstate='planned'
# 2025-01-21 10:44:27 consumer02_currentPower 0 W
# 2025-01-21 10:44:27 consumer02_planned_start 21.01.2025 10:28:06
# 2025-01-21 10:44:27 consumer02_planned_stop 21.01.2025 11:58:06
# 2025-01-21 10:44:27 consumer03 name='GeschirrSpueler' state='on' mode='can' planningstate='planned'
# 2025-01-21 10:44:27 consumer03_currentPower 0 W
# 2025-01-21 10:44:27 consumer03_planned_start 21.01.2025 10:28:06
# 2025-01-21 10:44:27 consumer03_planned_stop 21.01.2025 13:28:06
# 2025-01-21 10:44:27 nextCycletime 10:45:37
# 2025-01-21 10:00:04 pvCorrectionFactor_10 1.15 (automatic - old factor: 0.90, AI result used, Sun Alt range: 10, Cloud range: 70, Days in range: 3)
# 2025-01-21 10:44:27 pvCorrectionFactor_Auto on_complex_ai
# 2024-06-27 21:25:57 setupStringAzimuth Süddach=S Norddach=N
# 2024-06-27 21:25:57 setupStringDeclination Süddach=30 Norddach=30
# 2025-01-21 10:44:28 state updated
#
setstate DWDSolarVorhersage updated
setstate DWDSolarVorhersage 2025-01-21 10:32:16 .associatedWith SH08rt01 ws01_WaMa ws02_WaeTrockner ws_GeschirrSpueler DWD
setstate DWDSolarVorhersage 2025-01-21 10:44:27 .lastupdateForecastValues 1737452667
setstate DWDSolarVorhersage 2025-01-21 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 02:00:04 .pvCorrectionFactor_02_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 02:00:04 .pvCorrectionFactor_02_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 03:00:04 .pvCorrectionFactor_03_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 03:00:04 .pvCorrectionFactor_03_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 04:00:04 .pvCorrectionFactor_04_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 04:00:04 .pvCorrectionFactor_04_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 05:00:04 .pvCorrectionFactor_05_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 05:00:04 .pvCorrectionFactor_05_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 06:00:04 .pvCorrectionFactor_06_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 06:00:04 .pvCorrectionFactor_06_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 08:00:04 .pvCorrectionFactor_08_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 08:00:04 .pvCorrectionFactor_08_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 10:00:04 .pvCorrectionFactor_10_apipercentil done
setstate DWDSolarVorhersage 2025-01-21 10:00:04 .pvCorrectionFactor_10_cloudcover done
setstate DWDSolarVorhersage 2025-01-21 10:44:27 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate DWDSolarVorhersage 2025-01-21 01:00:04 .signaldone_01 done
setstate DWDSolarVorhersage 2025-01-21 02:00:04 .signaldone_02 done
setstate DWDSolarVorhersage 2025-01-21 03:00:04 .signaldone_03 done
setstate DWDSolarVorhersage 2025-01-21 04:00:04 .signaldone_04 done
setstate DWDSolarVorhersage 2025-01-21 05:00:04 .signaldone_05 done
setstate DWDSolarVorhersage 2025-01-21 06:00:04 .signaldone_06 done
setstate DWDSolarVorhersage 2025-01-21 07:00:04 .signaldone_07 done
setstate DWDSolarVorhersage 2025-01-21 08:00:04 .signaldone_08 done
setstate DWDSolarVorhersage 2025-01-21 09:00:04 .signaldone_09 done
setstate DWDSolarVorhersage 2025-01-21 10:00:04 .signaldone_10 done
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_AutarkyRate 100 %
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_BatCharge_01 18.8 %
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_Consumption 648 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_GridConsumption 0 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_GridFeedIn 0 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_PV 1576 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_PowerBatIn_01 928 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_PowerBatOut_01 0 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_SelfConsumption 648 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_SelfConsumptionRate 41 %
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Current_Surplus 928 W
setstate DWDSolarVorhersage 2025-01-21 10:00:00 LastHourGridconsumptionReal 200 Wh
setstate DWDSolarVorhersage 2025-01-21 10:00:00 LastHourPVforecast 200 Wh
setstate DWDSolarVorhersage 2025-01-21 10:00:00 LastHourPVreal 500 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 NextHours_Sum01_PVforecast 1200 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 NextHours_Sum02_PVforecast 2708 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 NextHours_Sum03_PVforecast 4619 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 NextHours_Sum04_ConsumptionForecast 4825 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 NextHours_Sum04_PVforecast 5944 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 RestOfDayConsumptionForecast 11076 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 RestOfDayPVforecast 7173 Wh
setstate DWDSolarVorhersage 2025-01-21 00:59:53 Today_Hour01_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 00:59:53 Today_Hour01_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 00:59:53 Today_Hour01_GridConsumption 400 Wh
setstate DWDSolarVorhersage 2025-01-21 00:59:53 Today_Hour01_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 00:59:53 Today_Hour01_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 01:59:49 Today_Hour02_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 01:59:49 Today_Hour02_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 01:59:49 Today_Hour02_GridConsumption 400 Wh
setstate DWDSolarVorhersage 2025-01-21 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 01:59:49 Today_Hour02_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 02:59:49 Today_Hour03_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 02:59:49 Today_Hour03_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 02:59:49 Today_Hour03_GridConsumption 500 Wh
setstate DWDSolarVorhersage 2025-01-21 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 02:59:49 Today_Hour03_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 03:59:49 Today_Hour04_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 03:59:49 Today_Hour04_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 03:59:49 Today_Hour04_GridConsumption 400 Wh
setstate DWDSolarVorhersage 2025-01-21 03:59:49 Today_Hour04_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 03:59:49 Today_Hour04_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 04:59:49 Today_Hour05_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 04:59:49 Today_Hour05_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 04:59:49 Today_Hour05_GridConsumption 400 Wh
setstate DWDSolarVorhersage 2025-01-21 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 04:59:49 Today_Hour05_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 05:59:58 Today_Hour06_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 05:59:58 Today_Hour06_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 05:59:58 Today_Hour06_GridConsumption 900 Wh
setstate DWDSolarVorhersage 2025-01-21 05:59:58 Today_Hour06_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 05:59:58 Today_Hour06_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 06:59:49 Today_Hour07_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 06:59:49 Today_Hour07_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 06:59:49 Today_Hour07_GridConsumption 500 Wh
setstate DWDSolarVorhersage 2025-01-21 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 06:59:49 Today_Hour07_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 07:59:49 Today_Hour08_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 07:59:49 Today_Hour08_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 07:59:49 Today_Hour08_GridConsumption 500 Wh
setstate DWDSolarVorhersage 2025-01-21 07:59:49 Today_Hour08_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 07:59:49 Today_Hour08_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 08:59:49 Today_Hour09_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 08:59:49 Today_Hour09_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 08:59:49 Today_Hour09_GridConsumption 400 Wh
setstate DWDSolarVorhersage 2025-01-21 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 08:59:49 Today_Hour09_PVforecast 18 Wh
setstate DWDSolarVorhersage 2025-01-21 08:59:49 Today_Hour09_PVreal 0 Wh
setstate DWDSolarVorhersage 2025-01-21 09:59:49 Today_Hour10_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 09:59:49 Today_Hour10_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 09:59:49 Today_Hour10_GridConsumption 200 Wh
setstate DWDSolarVorhersage 2025-01-21 09:59:49 Today_Hour10_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 09:59:49 Today_Hour10_PVforecast 200 Wh
setstate DWDSolarVorhersage 2025-01-21 09:59:49 Today_Hour10_PVreal 500 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour11_BatIn_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour11_BatOut_01 0 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour11_GridConsumption 300 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour11_GridFeedIn 0 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour11_PVforecast 1500 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour11_PVreal 700 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour12_PVforecast 1100 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour13_PVforecast 1644 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour14_PVforecast 2000 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour15_PVforecast 1100 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour16_PVforecast 754 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_Hour17_PVforecast 200 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_MaxPVforecast 2000 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_MaxPVforecastTime 2025-01-21 13:00:00
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_PVforecast 8516 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_PVreal 1200 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_SunRise 08:23
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Today_SunSet 17:03
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Tomorrow_ConsumptionForecast 17899 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Tomorrow_PVforecast 5181 Wh
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Tomorrow_SunRise 08:22
setstate DWDSolarVorhersage 2025-01-21 10:44:27 Tomorrow_SunSet 17:05
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer01 name='Waschmaschine' state='on' mode='can' planningstate='planned'
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer01_currentPower 68.091 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer01_planned_start 21.01.2025 10:28:06
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer01_planned_stop 21.01.2025 12:28:06
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer02 name='Waeschetrockner' state='on' mode='can' planningstate='planned'
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer02_currentPower 0 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer02_planned_start 21.01.2025 10:28:06
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer02_planned_stop 21.01.2025 11:58:06
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer03 name='GeschirrSpueler' state='on' mode='can' planningstate='planned'
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer03_currentPower 0 W
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer03_planned_start 21.01.2025 10:28:06
setstate DWDSolarVorhersage 2025-01-21 10:44:27 consumer03_planned_stop 21.01.2025 13:28:06
setstate DWDSolarVorhersage 2025-01-21 10:44:27 nextCycletime 10:45:37
setstate DWDSolarVorhersage 2025-01-21 10:00:04 pvCorrectionFactor_10 1.15 (automatic - old factor: 0.90, AI result used, Sun Alt range: 10, Cloud range: 70, Days in range: 3)
setstate DWDSolarVorhersage 2025-01-21 10:44:27 pvCorrectionFactor_Auto on_complex_ai
setstate DWDSolarVorhersage 2024-06-27 21:25:57 setupStringAzimuth Süddach=S Norddach=N
setstate DWDSolarVorhersage 2024-06-27 21:25:57 setupStringDeclination Süddach=30 Norddach=30
setstate DWDSolarVorhersage 2025-01-21 10:44:28 state updated
Hallo Christian,
cap=9600Wh ist falsch, bei numerischer Direkteingabe nur cap=9600.
LG
Zitat von: DS_Starter am 21 Januar 2025, 10:34:54Zitatund insb. angezeigte SOC-Werte oben (bei 100%) und unten (bei 0%) zu kappen.
Das ist kein Problem und baue ich ein.
Prima!
Zitat von: DS_Starter am 21 Januar 2025, 10:34:54ZitatLeider gibt es in FHEM bis dato keine Auftrennung eines BAT-Devices in Low- und High-Level-Anteil.
..
Spätestens dann, wenn hier in Deinem Modul von SOC auf Energie und umgekehrt abgebildet wird, ist das aber problematisch.
Was ist mit "Auftrennung eines BAT-Devices in Low- und High-Level-Anteil" gemeint?
Kannst du es näher erläutern?
Als Low-Level-Anteil würde ich allgemein (also nicht nur auf BAT-Systeme bezogen) den Anteil einer Software bezeichnen, der unmittelbar mit der Hardware kommuniziert und die dabei gewonnenen Grüßen 1:1 auf die für die jeweilige Geräteklasse übliche Readings und ggf. gerätespezifische Zusatzreadings abbildet. Im High-Level-Anteil werden die für die jeweilige Geräteklasse üblichen Low-Level-Redings (optinal mit Zusatzreadings) genutzt, um aus diesen (ggf, inkl. deren Historie) abgeleitete Größen zu gewinnen.
Zitat von: DS_Starter am 21 Januar 2025, 10:56:26Hallo Christian,
cap=9600Wh ist falsch, bei numerischer Direkteingabe nur cap=9600.
LG
Passt wieder. Hat sich da etwas geändert oder habe ich da beim Update etwas umgestellt? Ich müsste im git nachsehen aber ich meine das wäre von Anfang an so gesetzt gewesen.
Danke
Christian
Die Vorgabe war schon seit der Implementierung so, hat sich nichts geändert.
Vllt. ist es erst jetzt aufgefallen weil cap bisher nur in einem bestimmten Setup genutzt wurde. Bis vor kurzem war cap deswegen auch optional angebbar.
Zitat von: DS_Starter am 21 Januar 2025, 10:49:42ZitatZitat
und insb. angezeigte SOC-Werte oben (bei 100%) und unten (bei 0%) zu kappen.
Das ist kein Problem und baue ich ein.
Habe mich jetzt jedoch dagegen entschieden, da wie der Fall bei minierm gezeigt, man durch diese Unstimmigkeit auf die Falscheingabe aufmerksam wird was sonst nicht passiert wäre.
Dadurch kann man ihn korrigieren, ansonsten würde an anderen Stellen evtl. auch zu Auswirkungen führen.
Es ist mir wichtig dass die Eingangswerte stimmig sind.
Natürlich sollten die Eingangswerte realitätsnah sein. Leider ist die Abbildung Energiezufluss -> SOC-Anstieg bzw. Energieabfluss -> SOC-Abfall aufgrund des bereits erwähnten nicht linearen Zusammenhangs und des ggf. sogar dyn. Wirkungsgrades problematisch. Trotz eines absolut korrekt angelieferten Energieflusses kann also der im Modul bestimmte SOC fehlerhaft werden.
Wenn Du nun gar nicht für eine dann sehr sinnvolle Kappung in [0%,100%] bist, dann wäre doch der Königsweg, den gekappten Wert mit einem zusätzlichen, ansonsten aber unschädlichen Prefix zu taggen, um so den User - zu besonderer Aufmerksamkeit - zu triggern. Vorschlag: Bei einer Kappung an der unteren Grenze wird -0% angegeben und bei einer Kappung an der oberen Grenze +100%.
Edit: Fälle, wie den von minierm beschriebenen, könnte man ggf. auch durch Feststellen einer für seine Anlage unwahrscheinlich (extrem) niedrigen BAT-Kapaziät (Wert war kleiner als der einer Smartphone-Powerbank) bei der SF-Konfigurationsprüfung vermeiden. Oder aber bzw. und auch dadurch, dass die Einheit nicht nur im Falle eines Readings mitzugeben ist.
ZitatLeider ist die Abbildung Energiezufluss -> SOC-Anstieg bzw. Energieabfluss -> SOC-Abfall aufgrund des bereits erwähnten nicht linearen Zusammenhangs und des ggf. sogar dyn. Wirkungsgrades problematisch. Trotz eines absolut korrekt angelieferten Energieflusses kann also der im Modul bestimmte SOC fehlerhaft werden.
Die Aussage kann ich nicht nachvollziehen.
Der aktuelle SoC-Wert wird vom Bat-Device geliefert, die Bezugsgröße cap auf die sich der SoC bezieht ist auch angegeben bzw. durch ein Reading lieferbar.
Wenn der aktuelle SoC im Modul fehlerhaft ist, kann es demnach nur an den Inputgrößen liegen.
ZitatDen Fall von minierm hätte man ggf. auch durch Feststellen einer für seine Anlage unwahrscheinlich (extrem) hohen BAT-Kapaziät bei der SF-Konfigurationsprüfung vermeiden können.
Was ist "extrem" hoch? Möglicherweise bilden die BAtterien von E-Autos auch einen Puffer. Der wäre dann wahrscheinlich bei einer Balkonanlage extrem hoch.
Nein, der User muß selbst auch aufpassen und lesen was wie anzugeben ist. Das Modul prüft schon sehr viel, _alles_ zu prüfen ist tendenziell nicht umsetzbar.
ZitatOder aber bzw. und auch dadurch, dass die Einheit nicht nur im Falle eines Readings mitzugeben ist.
Das ist auch so.
Zitat von: DS_Starter am 21 Januar 2025, 12:52:10ZitatOder aber bzw. und auch dadurch, dass die Einheit nicht nur im Falle eines Readings mitzugeben ist.
Das ist auch so.
Wenn die Doku stimmt, dass ist das nicht richtig! Bei der Verwendung einer Konstanten als Kapazität ist keine Einheit anzugeben. Das ist so auch in der Doku angegeben:
cap installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)
Zitat von: DS_Starter am 21 Januar 2025, 12:52:10ZitatDen Fall von minierm hätte man ggf. auch durch Feststellen einer für seine Anlage unwahrscheinlich (extrem) hohen BAT-Kapaziät bei der SF-Konfigurationsprüfung vermeiden können.
Was ist "extrem" hoch? Möglicherweise bilden die BAtterien von E-Autos auch einen Puffer. Der wäre dann wahrscheinlich bei einer Balkonanlage extrem hoch.
...
Sorry, hatte mich verschrieben und den Fehler - offenbar nicht schnell genug - korrigiert. Die von ihm angegebene Kapazität war extrem (!) niedrig. Und ich hoffe wirklich, dass niemand seine Smartphone-Powerbanks als Pufferbatterie an seiner Solaranlage betreibt.
Zitat von: DS_Starter am 21 Januar 2025, 12:52:10ZitatLeider ist die Abbildung Energiezufluss -> SOC-Anstieg bzw. Energieabfluss -> SOC-Abfall aufgrund des bereits erwähnten nicht linearen Zusammenhangs und des ggf. sogar dyn. Wirkungsgrades problematisch. Trotz eines absolut korrekt angelieferten Energieflusses kann also der im Modul bestimmte SOC fehlerhaft werden.
Die Aussage kann ich nicht nachvollziehen.
Der aktuelle SoC-Wert wird vom Bat-Device geliefert, die Bezugsgröße cap auf die sich der SoC bezieht ist auch angegeben bzw. durch ein Reading lieferbar.
Wenn der aktuelle SoC im Modul fehlerhaft ist, kann es demnach nur an den Inputgrößen liegen.
minierm hatte geschrieben:
ZitatBeim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Es geht also nicht um ein in SF falsches angeliefertes SOC, sondern um ein in SF berechnetes SOC, oder?
ZitatEs geht also nicht um ein in SF falsches angeliefertes SOC, sondern um ein in SF berechnetes SOC, oder?
Ja, aber mehr noch, um ein
prognostiziertes, also vermutlich/wahrscheinlich erreichbares SoC zu einer bestimmten Stunde.
Zitat von: DS_Starter am 21 Januar 2025, 13:39:27ZitatEs geht also nicht um ein in SF falsches angeliefertes SOC, sondern um ein in SF berechnetes SOC, oder?
Ja, aber mehr noch, um ein prognostiziertes, also vermutlich/wahrscheinlich erreichbares SoC zu einer bestimmten Stunde.
Und das kann ja eigentlich weder negativ noch >100% werden, oder?
ZitatUnd das kann ja eigentlich weder negativ noch >100% werden, oder?
Wenn alles richtig eingegeben wurde nicht.
Zitat von: DS_Starter am 21 Januar 2025, 13:50:07ZitatUnd das kann ja eigentlich weder negativ noch >100% werden, oder?
Wenn alles richtig eingegeben wurde nicht.
Da die in SF berechneten Werte ggf. ja von weitere Software-Instanzen genutzt und zu Aktionen führen können, bin ich - nach wie vor - der Ansicht, dass SF (und natürlich auch andere Module) keine Readings nach außen tragen sollten, die außerhalb des zu erwartenden Bereichs eines jeden Readings liegen. Signalisierungen über vermeintliche Fehlkonfigurationen sollten - nach meiner Ansicht - über geeignetere Mechanismen, wie wohldokumentierte ,,Notification, Warning & Error Masks" erfolgen, die ggf. von User explizit gelöscht werden müssen.
Stell Dir nur mal vor, der Fall SOC < 0 taucht für eine lange Zeit nicht auf, aber - wie der Zufall es so will - zu einem Zeitpunkt an dem der User der Anlage für mehrere Stunden, Tage oder gar Wochen verhindert ist aktiv in die Anlage einzugreifen. Aufgrund des von SF falsch, weil (semantisch) nicht definierten Werts, finden dann in anderen Software-Instanzen möglicherweise Aktionen statt, die nicht nur vom User unerwünscht, sondern vielleicht sogar schädlich für die Anlage sind.
Um dies schon im Ansatz zu verhindern, sollten daher für Readings eigentlich Definitionsbereiche festgelegt werden, in dessen Grenzen sich die Readingwerte bewegen dürfen. Wenn eine derartige Begrenzung (nach oben und unten) nicht möglich oder nicht gewollt ist, dann sollte dies in der Beschreibung von SF sehr deutlich klar kommuniziert werden.
ZitatDa die in SF berechneten Werte ggf. ja von weitere Software-Instanzen genutzt und zu Aktionen führen können, bin ich - nach wie vor - der Ansicht, dass SF (und natürlich auch andere Module) keine Readings nach außen tragen sollten, die außerhalb des zu erwartenden Bereichs eines jeden Readings liegen. Signalisierungen über vermeintliche Fehlkonfigurationen sollten - nach meiner Ansicht - über geeignetere Mechanismen, wie wohldokumentierte ,,Notification, Warning & Error Masks" erfolgen, die ggf. von User explizit gelöscht werden müssen.
Den gleichen Anspruch habe ich eigentlich auch an die an SF gelieferten Input-Parameter und Werte. ;)
Leider kann ich mich nicht darauf verlassen und prüfe deswegen, sofern machbar, deren Sinnhaftigkeit.
Eine nachfolgende Verarbeitung kann/sollte das auch tun.
Dennoch versuche ich diversen Komfort zu bieten.
Du hast gerade eine Anregung gegeben. Das neue Mitteilungssystem kann ich evtl. auch dazu benutzen, z.B. direkt Inhalte der Readings Battery_NextHour00_SoCforecast_XX (in diesem Kontext) auf die Überschreitung von 0 bzw. 100 % zu überwachen. Verletzungen würden dem User direkt sichtbar signalisiert und ein Hinweis auf die mögliche Korrektur gegeben.
Das wäre zumindest mal auf die Praxistauglichkeit hin zu testen.
Zitat von: DS_Starter am 21 Januar 2025, 10:04:25Mit der cap-Angabe im Attr erfolgt die Umrechnung in das Wh Äquivalent. Der Umwandlungsverlust der Ladung würde auch noch mit eingehen, hat allerdings im Verhältnis der beschriebenen Einflußfaktoren eine eher marginale Rolle.
8,5% Umwandlungsverlust (LFP) würde ich jetzt nicht als marginal bezeichnen...
365.0 Zyklen (0.7 Zyklen / Tag * 494.5 Tage) 8.51% Verlust
Bat_Loss {sprintf("%0.2f", (ReadingsNum($NAME, "data_data_ETotalbatteryCharge", 0) - ReadingsNum($NAME, "data_data_ETotalbatteryDischarge", 0)) / ReadingsNum($NAME, "data_data_ETotalbatteryCharge", 0) * 100)
data_data_ETotalbatteryCharge: 4197.8
data_data_ETotalbatteryDischarge: 3840.6
SOH: 99.32
Zitat von: Parallix am 21 Januar 2025, 13:02:49Zitat von: DS_Starter am 21 Januar 2025, 12:52:10ZitatOder aber bzw. und auch dadurch, dass die Einheit nicht nur im Falle eines Readings mitzugeben ist.
Das ist auch so.
Wenn die Doku stimmt, dass ist das nicht richtig! Bei der Verwendung einer Konstanten als Kapazität ist keine Einheit anzugeben. Das ist so auch in der Doku angegeben:
cap installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)
Ganz toll wäre es natürlich, wenn auch bei konstanten Werten eine Einheit angegeben werden kann :-)
...aber das ist grad nicht so wichtig, würd es nur rund machen.
Zitat8,5% Umwandlungsverlust (LFP) würde ich jetzt nicht als marginal bezeichnen...
Das ist sicher nicht marginal.
Jedoch geht es um den Energieverlust nur für die nächste(n) Stunde(n) wenn bereits für die PV-Prognose eine Unsicherheit von 10% und auch für die Verbrauchsprognose 10% vorhanden sind (10 % ist schon ein guter Wert).
Was sollte man da ansetzen? Einen fixen Wert? Wie hoch? Gültig für alle Typen und alle Leistungsklassen? Für Laden und Entladen gleich?
Vllt. gibt es eine Dokumentation die ein Modell liefert. Gerne mal stöbern ...
ZitatWenn die Doku stimmt, dass ist das nicht richtig! Bei der Verwendung einer Konstanten als Kapazität ist keine Einheit anzugeben.
Ach, ich habe das "nicht" überlesen, sorry. Die Doku stimmt / trifft zu.
ZitatGanz toll wäre es natürlich, wenn auch bei konstanten Werten eine Einheit angegeben werden kann :-)
...aber das ist grad nicht so wichtig, würd es nur rund machen.
Naja so toll ist das nicht. Beispiel...
Hier ist die 9000 ein konstanter Wert:
cap=9000:WhUnd hier hat sich der User ein userReading 9020.99 ausgedacht
cap=9020.99:WhDas ist sicherlich unüblich, aber erlaubt. Du glaubst garnicht auf welche Ideen manche User kommen.
Welche Variante davon ist jetzt ein konstanter Wert vs. Reading? ;)
LG
Zitat von: DS_Starter am 21 Januar 2025, 17:26:13...
Und hier hat sich der User ein userReading 9020.99 ausgedacht
cap=9020.99:Wh
Das ist sicherlich unüblich, aber erlaubt. Du glaubst garnicht auf welche Ideen manche User kommen.
Welche Variante davon ist jetzt ein konstanter Wert vs. Reading? ;)
...
Das hatte ich gar nicht auf dem Schirm. Gibt es denn keinen Style-Guide aus dem hervorgeht, dass Readings stets mit einem nicht Ziffernsymbol beginnen müssen?
ZitatGibt es denn keinen Style-Guide aus dem hervorgeht, dass Readings stets mit einem nicht Ziffernsymbol beginnen müssen?
Es gibt eine Festlegung aus welchen Zeichen ein Reading bestehen darf, schau hier: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#goodReadingName
Zitat von: DS_Starter am 21 Januar 2025, 17:26:13Zitat8,5% Umwandlungsverlust (LFP) würde ich jetzt nicht als marginal bezeichnen...
Das ist sicher nicht marginal.
Jedoch geht es um den Energieverlust nur für die nächste(n) Stunde(n) wenn bereits für die PV-Prognose eine Unsicherheit von 10% und auch für die Verbrauchsprognose 10% vorhanden sind (10 % ist schon ein guter Wert).
Was sollte man da ansetzen?
...
Mein Vorschlag (siehe weiter oben):
ZitatFür's erste schlage ich – analog zu den pv_correctionFactors – vor, auch bei der Berücksichtigung von Be- und Endladung der BATs in SF entsprechende Korrekturfaktoren einzubauen und ...
Zitat von: DS_Starter am 21 Januar 2025, 18:42:55ZitatGibt es denn keinen Style-Guide aus dem hervorgeht, dass Readings stets mit einem nicht Ziffernsymbol beginnen müssen?
Es gibt eine Festlegung aus welchen Zeichen ein Reading bestehen darf, schau hier: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#goodReadingName
Und dann heißt die Funktion, die auch Reading-Namen wir 83724.24 erlaubt, auch noch goodReadingName(). Ich fasse es nicht :o
Edit: Überdies ist die Beschreibung für den Aufbau von Reading-Namen mehrdeutig, da man
ZitatEin gültiger Readingname besteht aus folgenden Zeichen bzw. Zeichengruppen
auch so verstehen kann, dass stets alle Zeichen bzw. Zeichengruppen im Reading-Namen auftauen müssen.
Naja nicht so hart sein. Es gibt theoritisch keinen Grund einen solchen Readingnamen zu verbieten, auch wenn es uns gerade nicht so gefällt. Solche Dinge muß ich als Modulautor wissen und im Blick haben wenn ich eine Anwendung baue und es berücksichtigen.
Zitat von: DS_Starter am 21 Januar 2025, 18:50:53Naja nicht so hart sein. Es gibt theoritisch keinen Grund einen solchen Readingnamen zu verbieten, auch wenn es uns gerade nicht so gefällt.
...
Sorry, aber da kann ich nicht folgen, da es sicherlich absolut keine gute Praxis ist, Reading-Namen zu verwenden, die sich ausschließlich aus Ziffern und einem Punkt zusammensetzen.
Edit: Kann ein Reading tatsächlich mit einem beliebigen Zeichen anfangen? Mich irritiert, dass es hier keine Beschreibung in (E)BNF-Form gibt, was bei Programmiersprachen ja recht üblich ist.
ZitatKann ein Reading tatsächlich mit einem beliebigen Zeichen anfangen?
Probiere es aus, z.B.:
9999.9:Bezug_Wirkleistung.* {ReadingsVal($name, "Bezug_Wirkleistung", 0)},
Zitat von: DS_Starter am 19 Januar 2025, 11:41:44D.h. die Korrektur sollte über das besagte UserReading erfolgen.
Da die geschilderte Problematik durchaus allgemeiner Natur ist, wäre alternativ zu überlegen, ob ich setupInverterDevXX einen Schlüssel für "Verlustleistung" spendiere.
Ich kenne momentan aber kein FHEM-Device welches die Verlustleistung ablesbar liefert oder gibt es das?
Hi, danke für deine schnelle Rückmeldung, ein Reading das den Verlust liefert habe ich leider nicht, ich überlege noch wie ich eins errechnen könnte.
Ich habe zwei Strings an einem WR, die Summe beider Strings gibt die PV Leistung.
Von der PV Leistung wird dann der Eigenbedarf gedeckt sowie Akku geladen, was dann noch über bleibt wird eingespeist.
Messwerte die ich habe:
PV Leistung
WR AC Ausgangsleistung
Batterie Ladeleistung
Batterie Endladeleistung
Smartmeter Leistung (positiv Bezug, negativ Einspeisung)
So wäre dann "PV Verlustleistung"
PV Leistung - WR AC Ausgangsleistung - Batterie Ladeleistung - Smartmeter Leistung
Aber, wenn nun Smartmeter Leistung Positiv ist, also Bezug, passt das ganze nicht mehr.
Auch wenn wie grade
Out: 0.313 kW | Laden: 0.00 kW | Entladen: 0.41 kW
Beim Entladen grade ist das Delta etwa 100W
Ich bin mir grade noch nicht sicher wie man das Sinnvoll berechnen könnte.
Hallo,
ich habe jetzt eine PV Anlage mit Batteriepuffer installiert und mein Netzbetreiber verweigert mir die Einspeisung.
Das funktioniert so, dass der WR den Verbrauch inkl. Batterie Laden ermittelt und dann die Solarmodule entsprechend drosselt, so dass sie GENAU das liefern, was grade verbraucht wird. Daher werden meine Algorithmen zum an/ausschalten massiv !! vom Forcast getriggert werden müssen.
Beispiel: Meine Anlage würde grade 7 kW liefern können, es sind aber nur Verbraucher mit 0,5 kW aktiv dann liefern die Module auch nur 0,5 kW.
Problem: Wenn dein Forecast ständig lernt, so wird das bei mir definitiv nicht funktionieren. Kann man das lernen bei deinem Algo irgendwie ausschalten und rein auf die Anlagenwerte fokusieren (Stringleistung, Dachschräge etc.)? Deine Forcast Werte sind echt gut und ich würde das Modul gerne bei mir einsetzen !!!
Und noch eine letzte Frage: Die forecast Werte sind exorbitatnt hoch - da scheint bei mir ein Faktor 1000??? drin zu sein?
Today_Hour12_PVforecast 3855064 Wh
==> Edit: Fehler war die String Config in W statt in KW. Habe es korrigiert, aber der forecast ändert sich leider dadurch nicht. Der Faktor 1000 bleibt da erst mal drinnen.
Da würde ich empfehlen per "set SFxyxyx reset XXXXXX" zu agieren um die "dollen" Werte zu eliminieren.
Vorher evtl. per "get SFXYXYXY XXXX". die entsprechenden Zeiträume evtl. noch aussuchen.
1 Alternative - => : Alle dem zugehörigen WR-Setup-Werte in einen 2ten WR kopieren / alle Werte in WR1 löschen / alle Werte nach einem Neustart wieder in einen WR 1 eintragen und dann den Werte vom WR2 wieder löschen 8)
2 Alternative - => warten bis die Statistik sich selbst bereinigt nach X Tagen O:-)
OT:
Wieso will der VNB denn die Einspeisung bei 7kW verbieten (Grund)??
Marke Eigenbau - oder warum ?
ZitatProblem: Wenn dein Forecast ständig lernt, so wird das bei mir definitiv nicht funktionieren. Kann man das lernen bei deinem Algo irgendwie ausschalten und rein auf die Anlagenwerte fokusieren (Stringleistung, Dachschräge etc.)? Deine Forcast Werte sind echt gut und ich würde das Modul gerne bei mir einsetzen !!!
Du kannst das Learning ausschalten mit "set ... pvCorrectionFactor_Auto noLearning".
Vorher setzt du den Modus den du verwenden möchtest, also z.B. "set ... on_complex(_ai)". Danach den oben geschrieben Befehl.
Du kannst auch dynamisch zwischen den Modi wechseln je nach Bedarf, ist kein Problem.
Diese Problematik der evtl. Abregelung von Anlagen wird uns insgesamt noch beschäftigen. Im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Ber%C3%BCcksichtigung_einer_Wirkleistungsbegrenzung) habe ich damit begonnen zu beschreiben wie SF bei der Optimierung unterstützen kann. Das werde ich noch weiter anreichern.
Vielleicht wäre das Thema wegen seiner relevanz auch noch einen separaten Thread in "Solaranlagen" wert.
Wegen der hohen Prognosen sollte ein "set ... reset pvCorrection ... " helfen wie von 300P schon angemerkt und zusätzlich solltest du im Attr setupInverterDevXX den Schlüssel capacity setzen falls nich geschehen.
LG
Die Einspeisung wird aktuell abgelehnt, da angeblich die Netze voll sind und erst ein Netzausbau durchgeführt werden muss. Man kann da nur kotzen und ich versuche diese Entscheidung noch anzufechten, aber im Moment muss ich meine Anlage wohl ohne Einspeisung mit Drosselung der Module betreiben.
Das Problem mit den extrem hohen Werten habe ich gelöst, indem ich das Forecast Modul einfach gelöscht habe und nochmal neu angelegt habe. Ist ja mein erster Tag, daher keine Verluste. Und wenn man weiss was man alles wie definieren muss war das in 10 Minuten wider Online mit jetzt vernünftigen Zahlen.
BTW: meine ersten beiden Stunden hat das Modul schon mit 5% Fehler prognostiziert. Das absulut beste was ich bis jetzt gesehen habe. Werde es jetzt mal ein paar Tage monitoren, aber von mir schon mal ein dickes fettes Lob!
Das mit dem "non learning" werde ich mal ausprobieren. Grade am Nachmittag wenn die Batterie voll ist tritt dann ja der Regelkreis in Aktion und die Leistung fällt massiv ab. Bis dahin ist die Batterie natürlich bester Abnehmer für die Sache.
Wenn du gerade anfängst, dann wende am Besten das "get ... x_migrate" gleich an. Da gibt es einen Hinweis in der "Postbox" im Header. Die sollte bei dir leuchten wenn noch nicht gelesen.
ZitatGrade am Nachmittag wenn die Batterie voll ist tritt dann ja der Regelkreis in Aktion und die Leistung fällt massiv ab. Bis dahin ist die Batterie natürlich bester Abnehmer für die Sache.
Die PV Prognose wird dann für diesen Zeitraum vermutlich voll denebenliegen, da das Modul nicht von einer Abregelung ausgeht und auch nicht lernt.
Möglicherweise würde es sich für dich lohnen die Batteriekapazität aufzustocken um mehr Puffer zu haben?
@all,
morgen früh gibt es eine neue Version im Update.
Bei den Consumer-Devices kann man nun einen spezifischen Alias im SF-Device angeben:
consumer01 SolCastDummy:Mein+eigener+Alias ...
Weiterhin ist noch etwas am Mitteilungssystem weiterentwickelt.
LG,
Heiko
Bei get HTML both gibt es einen Fehler in der Generierung, falscher Stringabschluß (oder Start):
getHTML.png
<td title="leichter <a href=" fhem?detail="Regen'">Regen: 93
Sonnenstand (Dezimalgrad):
Höhe 4
Azimut 125' class='solarfc' width='20' style='margin:1px; vertical-align:middle align:center; padding-bottom:1px;'><svg class=" weather_rain_light C7C979"
Im Weblink ist es richtig:
<td title="leichter Regen: 93
Sonnenstand (Dezimalgrad):
Höhe 4
Azimut 125" class="solarfc" width="20" style="margin:1px; vertical-align:middle align:center; padding-bottom:1px;"><svg class=" weather_rain_light C7C979"
Beim Generieren der SVG wird der Style gewürfelt, mal Times mal Arial:
SVG Times.png
(Die Klasse "kkkkkkk..." ist etwas schräg)
Das ist putzig, bei mir kein Problem. (Anhang).
Poste mal bitte ein List damit ich die Anzeigeeinstellungen evtl. bei mir nachstellen kann.
Meinst du dies? Tritt wie gesagt nur ab und zu im Chrome auf, Reload hilft, damit Arial genommen wird.
define PVForecast SolarForecast
attr PVForecast affectConsForecastIdentWeekdays 1
attr PVForecast affectConsForecastInPlanning 1
attr PVForecast comment help SolarForecast de\
Update: "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr PVForecast consumer01 HUESensor_9.2_Power_WaMa auto=0 type=noSchedule icon=scene_laundry_room power=2000 mintime=165 pcurr=power:W on=on off=off switchdev=HUEDevice_2_OnOff_WaMa etotal=Consumption:W asynchron=1
attr PVForecast consumer02 HUESensor_21.4_Power_TK auto=0 type=noSchedule icon=freezer power=600 switchdev=HUEDevice_4_OnOff_TK mintime=20 pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecast consumer03 HUESensor_19.3_Power_PC auto=0 type=noSchedule icon=it_pc power=500 switchdev=HUEDevice_3_OnOff_PC pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecast consumer04 HUESensor_54_Power_Backofen auto=0 type=noSchedule icon=scene_baking_oven power=3500 switchdev=HUEDevice_17_OnOff_Backofen pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecast consumer05 HUESensor_56_Power_Kuehl auto=0 type=noSchedule icon=kuehlschrank_small power=100 switchdev=HUEDevice_18_OnOff_Kuehl pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecast consumer06 HUESensor_58_Power_Mikro auto=0 type=noSchedule icon=scene_microwave_oven power=1500 switchdev=HUEDevice_19_OnOff_Mikro pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecast consumer07 HUESensor_36_Power_Laser auto=0 type=noSchedule icon=it_printer power=1500 switchdev=HUEDevice_12_OnOff_Laser pcurr=power:W on=on off=off etotal=Consumption:W asynchron=1
attr PVForecast consumerAdviceIcon none
attr PVForecast consumerLegend icon_bottom
attr PVForecast consumerLink 1
attr PVForecast ctrlLanguage DE
attr PVForecast ctrlSolCastAPImaxReq 10
attr PVForecast ctrlSolCastAPIoptimizeReq 1
attr PVForecast ctrlSpecialReadings SunHours_Remain,SunMinutes_Remain,conForecastTillNextSunrise,dayAfterTomorrowPVforecast,response_message
attr PVForecast disable 0
attr PVForecast event-on-change-reading .*
attr PVForecast flowGraphicControl animate=1 showconsumerremaintime=0
attr PVForecast graphicBeam3Content batsocforecast_01
attr PVForecast graphicBeamHeightLevel1 380
attr PVForecast graphicBeamHeightLevel2 50
attr PVForecast graphicEnergyUnit kWh
attr PVForecast graphicHeaderOwnspec Surplus:Current_Surplus\
TodayFc:Today_PVforecast TodayRl:Today_PVreal_kWh\
PV ;übermorgen:special_dayAfterTomorrowPVforecast
attr PVForecast graphicHistoryHour 12
attr PVForecast graphicShowDiff bottom
attr PVForecast group PV
attr PVForecast room PV
attr PVForecast setupBatteryDev01 Strom_Bat_Aktuell cap=11500 pout=Leistung:kW pin=-pout charge=Ladung intotal=Charge_Total:kWh outtotal=DisCharge_Total:kWh show=1
attr PVForecast setupInverterDev01 Strom_PV_All_Aktuell pv=PVALL:kW etotal=All_Total:kWh capacity=10600
attr PVForecast setupInverterStrings Dach,BKW
attr PVForecast setupMeterDev MQTT2_DVES_6296D2 gcon=SML_Watt_Summe:W contotal=SML_Verbrauch_Summe:kWh gfeedin=-gcon feedtotal=SML_Einspeisung_Summe:kWh
attr PVForecast setupRadiationAPI SolCast-API
attr PVForecast setupRoofTops Dach=Dach BKW=BKW
attr PVForecast setupStringPeak Dach=9.6 BKW=1
attr PVForecast setupWeatherDev1 DWD1_Ulm
attr PVForecast userReadings Today_PVreal_kWh:Today_PVreal.* {sprintf("%0.1f kWh", ReadingsNum($NAME, "Today_PVreal", 0)/1000)}
# .AttrList affectBatteryPreferredCharge:slider,0,1,100 affectConsForecastIdentWeekdays:1,0 affectConsForecastInPlanning:1,0 affectConsForecastLastDays:slider,1,1,31 affectSolCastPercentile:select,10,50,90 consumerLegend:none,icon_top,icon_bottom,text_top,text_bottom consumerAdviceIcon consumerLink:0,1 ctrlAIdataStorageDuration ctrlAIshiftTrainStart:slider,1,1,23 ctrlBackupFilesKeep ctrlConsRecommendReadings:multiple-strict,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16 ctrlDebug:multiple-strict,none,aiData,aiProcess,apiCall,apiProcess,batteryManagement,collectData,consumerPlanning,consumerSwitching01,consumerSwitching02,consumerSwitching03,consumerSwitching04,consumerSwitching05,consumerSwitching06,consumerSwitching07,consumerSwitching08,consumerSwitching09,consumerSwitching10,consumerSwitching11,consumerSwitching12,consumerSwitching13,consumerSwitching14,consumerSwitching15,consumerSwitching16,consumption,consumption_long,dwdComm,epiecesCalc,graphic,notifyHandling,pvCorrectionRead,pvCorrectionWrite,radiationProcess,saveData2Cache,#10 ctrlAreaFactorUsage ctrlGenPVdeviation:daily,continuously ctrlInterval ctrlLanguage:DE,EN ctrlNextDayForecastReadings:multiple-strict,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 ctrlShowLink:1,0 ctrlSolCastAPImaxReq:selectnumbers,5,5,60,0,lin ctrlSolCastAPIoptimizeReq:1,0 ctrlSpecialReadings:multiple-strict,BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,currentRunMtsConsumer_08,currentRunMtsConsumer_09,currentRunMtsConsumer_10,currentRunMtsConsumer_11,currentRunMtsConsumer_12,currentRunMtsConsumer_13,currentRunMtsConsumer_14,currentRunMtsConsumer_15,currentRunMtsConsumer_16,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,daysUntilBatteryCare_02,daysUntilBatteryCare_03,lastretrieval_time,lastretrieval_timestamp,response_message,runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeAvgDayConsumer_08,runTimeAvgDayConsumer_09,runTimeAvgDayConsumer_10,runTimeAvgDayConsumer_11,runTimeAvgDayConsumer_12,runTimeAvgDayConsumer_13,runTimeAvgDayConsumer_14,runTimeAvgDayConsumer_15,runTimeAvgDayConsumer_16,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatIn_03,todayBatOut_01,todayBatOut_02,todayBatOut_03,todayConForecastTillSunset,todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,todayRemainingAPIcalls,todayRemainingAPIrequests ctrlUserExitFn:textField-long disable:1,0 flowGraphicControl:textField-long graphicBeamHeightLevel1 graphicBeamHeightLevel2 graphicBeamWidth:slider,20,5,100 graphicBeam1Content graphicBeam2Content graphicBeam3Content graphicBeam4Content graphicBeam1Color:colorpicker,RGB graphicBeam2Color:colorpicker,RGB graphicBeam3Color:colorpicker,RGB graphicBeam4Color:colorpicker,RGB graphicBeam1FontColor:colorpicker,RGB graphicBeam2FontColor:colorpicker,RGB graphicBeam3FontColor:colorpicker,RGB graphicBeam4FontColor:colorpicker,RGB graphicEnergyUnit:Wh,kWh graphicHeaderOwnspec:textField-long graphicHeaderOwnspecValForm:textField-long graphicHeaderDetail:multiple-strict,all,co,pv,own,status graphicHeaderShow:1,0 graphicHistoryHour:slider,0,1,23 graphicHourCount:slider,4,1,24 graphicHourStyle graphicLayoutType:single,double,diff graphicSelect:both,flow,forecast,none graphicShowDiff:no,top,bottom graphicShowNight:1,0,01 graphicShowWeather:1,0 graphicSpaceSize graphicWeatherColor:colorpicker,RGB graphicWeatherColorNight:colorpicker,RGB setupInverterStrings setupMeterDev:textField-long setupRoofTops setupStringPeak setupBatteryDev01:textField-long setupBatteryDev02:textField-long setupBatteryDev03:textField-long setupInverterDev01:textField-long setupInverterDev02:textField-long setupInverterDev03:textField-long setupOtherProducer01:textField-long setupOtherProducer02:textField-long setupOtherProducer03:textField-long consumer01:textField-long consumer02:textField-long consumer03:textField-long consumer04:textField-long consumer05:textField-long consumer06:textField-long consumer07:textField-long consumer08:textField-long consumer09:textField-long consumer10:textField-long consumer11:textField-long consumer12:textField-long consumer13:textField-long consumer14:textField-long consumer15:textField-long consumer16:textField-long ctrlBatSocManagement01:textField-long ctrlBatSocManagement02:textField-long ctrlBatSocManagement03:textField-long event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading graphicBeam1MaxVal:obsolete#-#the#attribute#will#be#deleted#soon ctrlAreaFactorUsage:obsolete#-#the#attribute#will#be#deleted#soon setupWeatherDev1:OpenMeteoDWD-API,OpenMeteoDWDEnsemble-API,OpenMeteoWorld-API,DWD1_Ulm,DWD3_Ulm,DWD_Maehringen,DWD_Ulm setupWeatherDev2:DWD1_Ulm,DWD3_Ulm,DWD_Maehringen,DWD_Ulm setupWeatherDev3:DWD1_Ulm,DWD3_Ulm,DWD_Maehringen,DWD_Ulm setupRadiationAPI:OpenMeteoDWD-API,OpenMeteoDWDEnsemble-API,OpenMeteoWorld-API,SolCast-API,ForecastSolar-API,VictronKI-API,DWD1_Ulm,DWD3_Ulm,DWD_Maehringen,DWD_Ulm ctrlNextHoursSoCForecastReadings:multiple-strict,00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23 graphicBeam1Content:batsocforecast_01,batsocforecast_02,batsocforecast_03,consumption,consumptionForecast,energycosts,feedincome,gridconsumption,gridfeedin,pvForecast,pvReal graphicBeam2Content:batsocforecast_01,batsocforecast_02,batsocforecast_03,consumption,consumptionForecast,energycosts,feedincome,gridconsumption,gridfeedin,pvForecast,pvReal graphicBeam3Content:batsocforecast_01,batsocforecast_02,batsocforecast_03,consumption,consumptionForecast,energycosts,feedincome,gridconsumption,gridfeedin,pvForecast,pvReal graphicBeam4Content:batsocforecast_01,batsocforecast_02,batsocforecast_03,consumption,consumptionForecast,energycosts,feedincome,gridconsumption,gridfeedin,pvForecast,pvReal
# .FhemMetaInternals 1
# FUUID 63f522f9-f33f-65cb-5211-0678b54f6bf22247
# FVERSION 76_SolarForecast.pm:v1.44.0-s29540/2025-01-19
# LCACHEFILE last write time: 17:10:34 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 17:14:51
# MODEL SolCastAPI
# NAME PVForecast
# NOTIFYDEV MQTT2_DVES_6296D2,HUESensor_9.2_Power_WaMa,HUEDevice_2_OnOff_WaMa,HUESensor_21.4_Power_TK,HUEDevice_4_OnOff_TK,HUESensor_19.3_Power_PC,HUEDevice_3_OnOff_PC,HUESensor_54_Power_Backofen,HUEDevice_17_OnOff_Backofen,HUESensor_56_Power_Kuehl,HUEDevice_18_OnOff_Kuehl,HUESensor_58_Power_Mikro,HUEDevice_19_OnOff_Mikro,HUESensor_36_Power_Laser,HUEDevice_12_OnOff_Laser,Strom_Bat_Aktuell,Strom_PV_All_Aktuell
# NR 1306
# NTFY_ORDER 50-PVForecast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 5070
# .attraggr:
# .attreocr:
# .*
# .attrminint:
# .userReadings:
# HASH(0x55da9dbcf810)
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV PVForecast
# SPGROOM
# VERSION 1.44.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.2
# OLDREADINGS:
# READINGS:
# 2025-01-22 14:18:34 .associatedWith MQTT2_DVES_6296D2 HUESensor_9.2_Power_WaMa HUEDevice_2_OnOff_WaMa HUESensor_21.4_Power_TK HUEDevice_4_OnOff_TK HUESensor_19.3_Power_PC HUEDevice_3_OnOff_PC HUESensor_54_Power_Backofen HUEDevice_17_OnOff_Backofen HUESensor_56_Power_Kuehl HUEDevice_18_OnOff_Kuehl HUESensor_58_Power_Mikro HUEDevice_19_OnOff_Mikro HUESensor_36_Power_Laser HUEDevice_12_OnOff_Laser Strom_Bat_Aktuell Strom_PV_All_Aktuell DWD1_Ulm
# 2025-01-23 17:13:45 .lastupdateForecastValues 1737648825
# 2025-01-22 14:22:09 .migrated 1
# 2025-01-23 01:00:04 .pvCorrectionFactor_01_apipercentil done
# 2025-01-23 01:00:04 .pvCorrectionFactor_01_cloudcover done
# 2025-01-23 02:00:05 .pvCorrectionFactor_02_apipercentil done
# 2025-01-23 02:00:05 .pvCorrectionFactor_02_cloudcover done
# 2025-01-23 03:00:03 .pvCorrectionFactor_03_apipercentil done
# 2025-01-23 03:00:03 .pvCorrectionFactor_03_cloudcover done
# 2025-01-23 04:00:05 .pvCorrectionFactor_04_apipercentil done
# 2025-01-23 04:00:05 .pvCorrectionFactor_04_cloudcover done
# 2025-01-23 05:00:05 .pvCorrectionFactor_05_apipercentil done
# 2025-01-23 05:00:05 .pvCorrectionFactor_05_cloudcover done
# 2025-01-23 06:00:05 .pvCorrectionFactor_06_apipercentil done
# 2025-01-23 06:00:05 .pvCorrectionFactor_06_cloudcover done
# 2025-01-23 07:00:04 .pvCorrectionFactor_07_apipercentil done
# 2025-01-23 07:00:04 .pvCorrectionFactor_07_cloudcover done
# 2025-01-23 08:00:04 .pvCorrectionFactor_08_apipercentil done
# 2025-01-23 08:00:04 .pvCorrectionFactor_08_cloudcover done
# 2025-01-23 09:00:04 .pvCorrectionFactor_09_apipercentil done
# 2025-01-23 09:00:04 .pvCorrectionFactor_09_cloudcover done
# 2025-01-23 10:00:05 .pvCorrectionFactor_10_apipercentil done
# 2025-01-23 10:00:05 .pvCorrectionFactor_10_cloudcover done
# 2025-01-23 11:00:04 .pvCorrectionFactor_11_apipercentil done
# 2025-01-23 11:00:04 .pvCorrectionFactor_11_cloudcover done
# 2025-01-23 12:00:04 .pvCorrectionFactor_12_apipercentil done
# 2025-01-23 12:00:04 .pvCorrectionFactor_12_cloudcover done
# 2025-01-23 13:00:04 .pvCorrectionFactor_13_apipercentil done
# 2025-01-23 13:00:04 .pvCorrectionFactor_13_cloudcover done
# 2025-01-23 14:00:04 .pvCorrectionFactor_14_apipercentil done
# 2025-01-23 14:00:04 .pvCorrectionFactor_14_cloudcover done
# 2025-01-23 15:00:04 .pvCorrectionFactor_15_apipercentil done
# 2025-01-23 15:00:04 .pvCorrectionFactor_15_cloudcover done
# 2025-01-23 16:00:04 .pvCorrectionFactor_16_apipercentil done
# 2025-01-23 16:00:04 .pvCorrectionFactor_16_cloudcover done
# 2025-01-23 17:00:04 .pvCorrectionFactor_17_apipercentil done
# 2025-01-23 17:00:04 .pvCorrectionFactor_17_cloudcover done
# 2025-01-23 17:13:45 .pvCorrectionFactor_Auto_Soll on_complex
# 2025-01-23 01:00:04 .signaldone_01 done
# 2025-01-23 02:00:05 .signaldone_02 done
# 2025-01-23 03:00:03 .signaldone_03 done
# 2025-01-23 04:00:05 .signaldone_04 done
# 2025-01-23 05:00:05 .signaldone_05 done
# 2025-01-23 06:00:05 .signaldone_06 done
# 2025-01-23 07:00:04 .signaldone_07 done
# 2025-01-23 08:00:04 .signaldone_08 done
# 2025-01-23 09:00:04 .signaldone_09 done
# 2025-01-23 10:00:05 .signaldone_10 done
# 2025-01-23 11:00:04 .signaldone_11 done
# 2025-01-23 12:00:04 .signaldone_12 done
# 2025-01-23 13:00:04 .signaldone_13 done
# 2025-01-23 14:00:04 .signaldone_14 done
# 2025-01-23 15:00:04 .signaldone_15 done
# 2025-01-23 16:00:04 .signaldone_16 done
# 2025-01-23 17:00:04 .signaldone_17 done
# 2025-01-23 17:13:45 Battery_ChargeRecommended_01 1
# 2025-01-23 17:13:45 Current_AutarkyRate 100 %
# 2025-01-23 17:13:45 Current_BatCharge_01 93.73 %
# 2025-01-23 17:13:45 Current_Consumption 1269 W
# 2025-01-23 17:13:45 Current_GridConsumption 0 W
# 2025-01-23 17:13:45 Current_GridFeedIn 4 W
# 2025-01-23 17:13:45 Current_PV 7 W
# 2025-01-23 17:13:45 Current_PowerBatIn_01 0 W
# 2025-01-23 17:13:45 Current_PowerBatOut_01 1266 W
# 2025-01-23 17:13:45 Current_SelfConsumption 3 W
# 2025-01-23 17:13:45 Current_SelfConsumptionRate 43 %
# 2025-01-23 17:13:45 Current_Surplus 0 W
# 2025-01-23 17:00:00 LastHourGridconsumptionReal 36 Wh
# 2025-01-23 17:00:00 LastHourPVforecast 396 Wh
# 2025-01-23 17:00:00 LastHourPVreal 600 Wh
# 2025-01-23 17:13:45 NextHours_Sum01_PVforecast 0 Wh
# 2025-01-23 17:13:45 NextHours_Sum02_PVforecast 0 Wh
# 2025-01-23 17:13:45 NextHours_Sum03_PVforecast 0 Wh
# 2025-01-23 17:13:45 NextHours_Sum04_ConsumptionForecast 4310 Wh
# 2025-01-23 17:13:45 NextHours_Sum04_PVforecast 0 Wh
# 2025-01-23 17:13:45 RestOfDayConsumptionForecast 7452 Wh
# 2025-01-23 17:13:45 RestOfDayPVforecast 0 Wh
# 2025-01-23 00:59:50 Today_Hour01_BatIn_01 0 Wh
# 2025-01-23 00:59:50 Today_Hour01_BatOut_01 0 Wh
# 2025-01-23 00:59:50 Today_Hour01_GridConsumption 1072 Wh
# 2025-01-23 00:59:50 Today_Hour01_GridFeedIn 0 Wh
# 2025-01-23 00:59:50 Today_Hour01_PVreal 0 Wh
# 2025-01-23 01:59:49 Today_Hour02_BatIn_01 0 Wh
# 2025-01-23 01:59:49 Today_Hour02_BatOut_01 0 Wh
# 2025-01-23 01:59:49 Today_Hour02_GridConsumption 970 Wh
# 2025-01-23 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2025-01-23 01:59:49 Today_Hour02_PVreal 0 Wh
# 2025-01-23 02:59:49 Today_Hour03_BatIn_01 0 Wh
# 2025-01-23 02:59:49 Today_Hour03_BatOut_01 0 Wh
# 2025-01-23 02:59:49 Today_Hour03_GridConsumption 707 Wh
# 2025-01-23 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2025-01-23 02:59:49 Today_Hour03_PVreal 0 Wh
# 2025-01-23 03:59:50 Today_Hour04_BatIn_01 100 Wh
# 2025-01-23 03:59:50 Today_Hour04_BatOut_01 0 Wh
# 2025-01-23 03:59:50 Today_Hour04_GridConsumption 683 Wh
# 2025-01-23 03:59:50 Today_Hour04_GridFeedIn 0 Wh
# 2025-01-23 03:59:50 Today_Hour04_PVreal 0 Wh
# 2025-01-23 04:59:49 Today_Hour05_BatIn_01 0 Wh
# 2025-01-23 04:59:49 Today_Hour05_BatOut_01 0 Wh
# 2025-01-23 04:59:49 Today_Hour05_GridConsumption 643 Wh
# 2025-01-23 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2025-01-23 04:59:49 Today_Hour05_PVreal 0 Wh
# 2025-01-23 05:59:56 Today_Hour06_BatIn_01 0 Wh
# 2025-01-23 05:59:56 Today_Hour06_BatOut_01 0 Wh
# 2025-01-23 05:59:56 Today_Hour06_GridConsumption 584 Wh
# 2025-01-23 05:59:56 Today_Hour06_GridFeedIn 0 Wh
# 2025-01-23 05:59:56 Today_Hour06_PVreal 0 Wh
# 2025-01-23 06:59:49 Today_Hour07_BatIn_01 0 Wh
# 2025-01-23 06:59:49 Today_Hour07_BatOut_01 0 Wh
# 2025-01-23 06:59:49 Today_Hour07_GridConsumption 349 Wh
# 2025-01-23 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2025-01-23 06:59:49 Today_Hour07_PVreal 0 Wh
# 2025-01-23 07:59:58 Today_Hour08_BatIn_01 0 Wh
# 2025-01-23 07:59:58 Today_Hour08_BatOut_01 0 Wh
# 2025-01-23 07:59:58 Today_Hour08_GridConsumption 361 Wh
# 2025-01-23 07:59:58 Today_Hour08_GridFeedIn 0 Wh
# 2025-01-23 07:59:58 Today_Hour08_PVreal 0 Wh
# 2025-01-23 08:59:59 Today_Hour09_BatIn_01 99 Wh
# 2025-01-23 08:59:59 Today_Hour09_BatOut_01 0 Wh
# 2025-01-23 08:59:59 Today_Hour09_GridConsumption 581 Wh
# 2025-01-23 08:59:59 Today_Hour09_GridFeedIn 0 Wh
# 2025-01-23 08:59:59 Today_Hour09_PVforecast 32 Wh
# 2025-01-23 08:59:59 Today_Hour09_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
# 2025-01-23 09:59:49 Today_Hour10_BatIn_01 0 Wh
# 2025-01-23 09:59:49 Today_Hour10_BatOut_01 100 Wh
# 2025-01-23 09:59:49 Today_Hour10_GridConsumption 148 Wh
# 2025-01-23 09:59:49 Today_Hour10_GridFeedIn 78 Wh
# 2025-01-23 09:59:49 Today_Hour10_PVforecast 216 Wh
# 2025-01-23 09:59:49 Today_Hour10_PVreal 200 Wh
# 2025-01-23 10:59:49 Today_Hour11_BatIn_01 1400 Wh
# 2025-01-23 10:59:49 Today_Hour11_BatOut_01 0 Wh
# 2025-01-23 10:59:49 Today_Hour11_GridConsumption 102 Wh
# 2025-01-23 10:59:49 Today_Hour11_GridFeedIn 229 Wh
# 2025-01-23 10:59:49 Today_Hour11_PVforecast 2074 Wh
# 2025-01-23 10:59:49 Today_Hour11_PVreal 2100 Wh
# 2025-01-23 11:59:50 Today_Hour12_BatIn_01 3599 Wh
# 2025-01-23 11:59:50 Today_Hour12_BatOut_01 0 Wh
# 2025-01-23 11:59:50 Today_Hour12_GridConsumption 78 Wh
# 2025-01-23 11:59:50 Today_Hour12_GridFeedIn 547 Wh
# 2025-01-23 11:59:50 Today_Hour12_PVforecast 1866 Wh
# 2025-01-23 11:59:50 Today_Hour12_PVreal 5100 Wh
# 2025-01-23 12:59:49 Today_Hour13_BatIn_01 2500 Wh
# 2025-01-23 12:59:49 Today_Hour13_BatOut_01 200 Wh
# 2025-01-23 12:59:49 Today_Hour13_GridConsumption 95 Wh
# 2025-01-23 12:59:49 Today_Hour13_GridFeedIn 410 Wh
# 2025-01-23 12:59:49 Today_Hour13_PVforecast 2050 Wh
# 2025-01-23 12:59:49 Today_Hour13_PVreal 4000 Wh
# 2025-01-23 13:59:58 Today_Hour14_BatIn_01 3900 Wh
# 2025-01-23 13:59:58 Today_Hour14_BatOut_01 0 Wh
# 2025-01-23 13:59:58 Today_Hour14_GridConsumption 48 Wh
# 2025-01-23 13:59:58 Today_Hour14_GridFeedIn 1104 Wh
# 2025-01-23 13:59:58 Today_Hour14_PVforecast 4398 Wh
# 2025-01-23 13:59:58 Today_Hour14_PVreal 7100 Wh
# 2025-01-23 14:59:50 Today_Hour15_BatIn_01 900 Wh
# 2025-01-23 14:59:50 Today_Hour15_BatOut_01 0 Wh
# 2025-01-23 14:59:50 Today_Hour15_GridConsumption 0 Wh
# 2025-01-23 14:59:50 Today_Hour15_GridFeedIn 5237 Wh
# 2025-01-23 14:59:50 Today_Hour15_PVforecast 3857 Wh
# 2025-01-23 14:59:50 Today_Hour15_PVreal 6200 Wh
# 2025-01-23 15:59:49 Today_Hour16_BatIn_01 0 Wh
# 2025-01-23 15:59:49 Today_Hour16_BatOut_01 0 Wh
# 2025-01-23 15:59:49 Today_Hour16_GridConsumption 1 Wh
# 2025-01-23 15:59:49 Today_Hour16_GridFeedIn 2510 Wh
# 2025-01-23 15:59:49 Today_Hour16_PVforecast 1357 Wh
# 2025-01-23 15:59:49 Today_Hour16_PVreal 3800 Wh
# 2025-01-23 16:59:49 Today_Hour17_BatIn_01 0 Wh
# 2025-01-23 16:59:49 Today_Hour17_BatOut_01 600 Wh
# 2025-01-23 16:59:49 Today_Hour17_GridConsumption 36 Wh
# 2025-01-23 16:59:49 Today_Hour17_GridFeedIn 168 Wh
# 2025-01-23 16:59:49 Today_Hour17_PVforecast 396 Wh
# 2025-01-23 16:59:49 Today_Hour17_PVreal 600 Wh
# 2025-01-23 17:13:45 Today_Hour18_BatIn_01 0 Wh
# 2025-01-23 17:13:45 Today_Hour18_BatOut_01 100 Wh
# 2025-01-23 17:13:45 Today_Hour18_GridConsumption 4 Wh
# 2025-01-23 17:13:45 Today_Hour18_GridFeedIn 5 Wh
# 2025-01-23 17:13:45 Today_Hour18_PVreal 0 Wh
# 2025-01-23 17:13:45 Today_MaxPVforecast 4398 Wh
# 2025-01-23 17:13:45 Today_MaxPVforecastTime 2025-01-23 13:00:00
# 2025-01-23 17:13:45 Today_PVdeviation -79.12 %
# 2025-01-23 17:13:45 Today_PVforecast 16246 Wh
# 2025-01-23 17:13:45 Today_PVreal 29100 Wh
# 2025-01-23 16:38:45 Today_PVreal_kWh 29.1 kWh
# 2025-01-23 17:13:45 Today_SunRise 08:00
# 2025-01-23 17:13:45 Today_SunSet 17:04
# 2025-01-23 17:13:45 Tomorrow_ConsumptionForecast 22638 Wh
# 2025-01-23 17:13:45 Tomorrow_PVforecast 13216 Wh
# 2025-01-23 17:13:45 Tomorrow_SunRise 07:58
# 2025-01-23 17:13:45 Tomorrow_SunSet 17:05
# 2023-10-09 13:54:01 associatedWith SolCastDummy
# 2025-01-23 17:13:45 consumer01 name='WaMa Power 2-9' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-01-23 17:13:45 consumer01_currentPower 0 W
# 2025-01-23 17:13:45 consumer02 name='TK Power 4-21' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-01-23 17:13:45 consumer02_currentPower 72 W
# 2025-01-23 17:13:45 consumer03 name='PC Power 3-19' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-01-23 17:13:45 consumer03_currentPower 142 W
# 2025-01-23 17:13:45 consumer04 name='Backofen 54' state='unknown' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-01-23 17:13:45 consumer04_currentPower 0 W
# 2025-01-23 17:13:45 consumer05 name='Kühl 56' state='unknown' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-01-23 17:13:45 consumer05_currentPower 76 W
# 2025-01-23 17:13:45 consumer06 name='Mikro 58' state='unknown' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-01-23 17:13:45 consumer06_currentPower 0 W
# 2025-01-23 17:13:45 consumer07 name='Laser 36-12' state='off' mode='can' planningstate='noSchedule'
# 2025-01-23 17:13:45 consumer07_currentPower 0 W
# 2025-01-23 17:13:41 nextCycletime 17:14:51
# 2025-01-23 17:13:45 nextRadiationAPICall ab 60 Minuten vor dem kommenden Sonnenaufgang
# 2025-01-23 10:00:05 pvCorrectionFactor_10 0.63 (automatic - old factor: 0.56, Sun Alt range: 10, Cloud range: 95, Days in range: 2)
# 2025-01-23 11:00:04 pvCorrectionFactor_11 0.94 (automatic - old factor: 0.79, Sun Alt range: 15, Cloud range: 95, Days in range: 2)
# 2025-01-23 12:00:04 pvCorrectionFactor_12 1.63 (automatic - old factor: 1.13, Sun Alt range: 20, Cloud range: 95, Days in range: 2)
# 2025-01-23 13:00:04 pvCorrectionFactor_13 1.55 (automatic - old factor: 1.10, Sun Alt range: 20, Cloud range: 95, Days in range: 2)
# 2025-01-23 14:00:04 pvCorrectionFactor_14 1.82 (automatic - old factor: 1.63, Sun Alt range: 20, Cloud range: 90, Days in range: 2)
# 2025-01-23 15:00:04 pvCorrectionFactor_15 1.50 (automatic - old factor: 1.16, Sun Alt range: 15, Cloud range: 90, Days in range: 2)
# 2025-01-23 16:00:04 pvCorrectionFactor_16 1.33 (automatic - old factor: 0.83, Sun Alt range: 10, Cloud range: 80, Days in range: 2)
# 2025-01-23 17:00:04 pvCorrectionFactor_17 0.73 (automatic - old factor: 0.68, Sun Alt range: 5, Cloud range: 80, Days in range: 2)
# 2025-01-23 17:13:45 pvCorrectionFactor_Auto on_complex
# 2024-08-13 21:30:17 setupStringAzimuth Dach=S BKW=S
# 2024-08-13 21:30:17 setupStringDeclination Dach=30 BKW=85
# 2025-01-23 17:13:45 special_SunHours_Remain 0.00
# 2025-01-23 17:13:45 special_SunMinutes_Remain 0
# 2025-01-23 17:13:45 special_conForecastTillNextSunrise 14673 Wh
# 2025-01-23 17:13:45 special_dayAfterTomorrowPVforecast 19416 Wh
# 2025-01-23 17:13:45 special_response_message success
# 2025-01-23 17:13:45 state updated
#
setstate PVForecast updated
setstate PVForecast 2025-01-22 14:18:34 .associatedWith MQTT2_DVES_6296D2 HUESensor_9.2_Power_WaMa HUEDevice_2_OnOff_WaMa HUESensor_21.4_Power_TK HUEDevice_4_OnOff_TK HUESensor_19.3_Power_PC HUEDevice_3_OnOff_PC HUESensor_54_Power_Backofen HUEDevice_17_OnOff_Backofen HUESensor_56_Power_Kuehl HUEDevice_18_OnOff_Kuehl HUESensor_58_Power_Mikro HUEDevice_19_OnOff_Mikro HUESensor_36_Power_Laser HUEDevice_12_OnOff_Laser Strom_Bat_Aktuell Strom_PV_All_Aktuell DWD1_Ulm
setstate PVForecast 2025-01-23 17:13:45 .lastupdateForecastValues 1737648825
setstate PVForecast 2025-01-22 14:22:09 .migrated 1
setstate PVForecast 2025-01-23 01:00:04 .pvCorrectionFactor_01_apipercentil done
setstate PVForecast 2025-01-23 01:00:04 .pvCorrectionFactor_01_cloudcover done
setstate PVForecast 2025-01-23 02:00:05 .pvCorrectionFactor_02_apipercentil done
setstate PVForecast 2025-01-23 02:00:05 .pvCorrectionFactor_02_cloudcover done
setstate PVForecast 2025-01-23 03:00:03 .pvCorrectionFactor_03_apipercentil done
setstate PVForecast 2025-01-23 03:00:03 .pvCorrectionFactor_03_cloudcover done
setstate PVForecast 2025-01-23 04:00:05 .pvCorrectionFactor_04_apipercentil done
setstate PVForecast 2025-01-23 04:00:05 .pvCorrectionFactor_04_cloudcover done
setstate PVForecast 2025-01-23 05:00:05 .pvCorrectionFactor_05_apipercentil done
setstate PVForecast 2025-01-23 05:00:05 .pvCorrectionFactor_05_cloudcover done
setstate PVForecast 2025-01-23 06:00:05 .pvCorrectionFactor_06_apipercentil done
setstate PVForecast 2025-01-23 06:00:05 .pvCorrectionFactor_06_cloudcover done
setstate PVForecast 2025-01-23 07:00:04 .pvCorrectionFactor_07_apipercentil done
setstate PVForecast 2025-01-23 07:00:04 .pvCorrectionFactor_07_cloudcover done
setstate PVForecast 2025-01-23 08:00:04 .pvCorrectionFactor_08_apipercentil done
setstate PVForecast 2025-01-23 08:00:04 .pvCorrectionFactor_08_cloudcover done
setstate PVForecast 2025-01-23 09:00:04 .pvCorrectionFactor_09_apipercentil done
setstate PVForecast 2025-01-23 09:00:04 .pvCorrectionFactor_09_cloudcover done
setstate PVForecast 2025-01-23 10:00:05 .pvCorrectionFactor_10_apipercentil done
setstate PVForecast 2025-01-23 10:00:05 .pvCorrectionFactor_10_cloudcover done
setstate PVForecast 2025-01-23 11:00:04 .pvCorrectionFactor_11_apipercentil done
setstate PVForecast 2025-01-23 11:00:04 .pvCorrectionFactor_11_cloudcover done
setstate PVForecast 2025-01-23 12:00:04 .pvCorrectionFactor_12_apipercentil done
setstate PVForecast 2025-01-23 12:00:04 .pvCorrectionFactor_12_cloudcover done
setstate PVForecast 2025-01-23 13:00:04 .pvCorrectionFactor_13_apipercentil done
setstate PVForecast 2025-01-23 13:00:04 .pvCorrectionFactor_13_cloudcover done
setstate PVForecast 2025-01-23 14:00:04 .pvCorrectionFactor_14_apipercentil done
setstate PVForecast 2025-01-23 14:00:04 .pvCorrectionFactor_14_cloudcover done
setstate PVForecast 2025-01-23 15:00:04 .pvCorrectionFactor_15_apipercentil done
setstate PVForecast 2025-01-23 15:00:04 .pvCorrectionFactor_15_cloudcover done
setstate PVForecast 2025-01-23 16:00:04 .pvCorrectionFactor_16_apipercentil done
setstate PVForecast 2025-01-23 16:00:04 .pvCorrectionFactor_16_cloudcover done
setstate PVForecast 2025-01-23 17:00:04 .pvCorrectionFactor_17_apipercentil done
setstate PVForecast 2025-01-23 17:00:04 .pvCorrectionFactor_17_cloudcover done
setstate PVForecast 2025-01-23 17:13:45 .pvCorrectionFactor_Auto_Soll on_complex
setstate PVForecast 2025-01-23 01:00:04 .signaldone_01 done
setstate PVForecast 2025-01-23 02:00:05 .signaldone_02 done
setstate PVForecast 2025-01-23 03:00:03 .signaldone_03 done
setstate PVForecast 2025-01-23 04:00:05 .signaldone_04 done
setstate PVForecast 2025-01-23 05:00:05 .signaldone_05 done
setstate PVForecast 2025-01-23 06:00:05 .signaldone_06 done
setstate PVForecast 2025-01-23 07:00:04 .signaldone_07 done
setstate PVForecast 2025-01-23 08:00:04 .signaldone_08 done
setstate PVForecast 2025-01-23 09:00:04 .signaldone_09 done
setstate PVForecast 2025-01-23 10:00:05 .signaldone_10 done
setstate PVForecast 2025-01-23 11:00:04 .signaldone_11 done
setstate PVForecast 2025-01-23 12:00:04 .signaldone_12 done
setstate PVForecast 2025-01-23 13:00:04 .signaldone_13 done
setstate PVForecast 2025-01-23 14:00:04 .signaldone_14 done
setstate PVForecast 2025-01-23 15:00:04 .signaldone_15 done
setstate PVForecast 2025-01-23 16:00:04 .signaldone_16 done
setstate PVForecast 2025-01-23 17:00:04 .signaldone_17 done
setstate PVForecast 2025-01-23 17:13:45 Battery_ChargeRecommended_01 1
setstate PVForecast 2025-01-23 17:13:45 Current_AutarkyRate 100 %
setstate PVForecast 2025-01-23 17:13:45 Current_BatCharge_01 93.73 %
setstate PVForecast 2025-01-23 17:13:45 Current_Consumption 1269 W
setstate PVForecast 2025-01-23 17:13:45 Current_GridConsumption 0 W
setstate PVForecast 2025-01-23 17:13:45 Current_GridFeedIn 4 W
setstate PVForecast 2025-01-23 17:13:45 Current_PV 7 W
setstate PVForecast 2025-01-23 17:13:45 Current_PowerBatIn_01 0 W
setstate PVForecast 2025-01-23 17:13:45 Current_PowerBatOut_01 1266 W
setstate PVForecast 2025-01-23 17:13:45 Current_SelfConsumption 3 W
setstate PVForecast 2025-01-23 17:13:45 Current_SelfConsumptionRate 43 %
setstate PVForecast 2025-01-23 17:13:45 Current_Surplus 0 W
setstate PVForecast 2025-01-23 17:00:00 LastHourGridconsumptionReal 36 Wh
setstate PVForecast 2025-01-23 17:00:00 LastHourPVforecast 396 Wh
setstate PVForecast 2025-01-23 17:00:00 LastHourPVreal 600 Wh
setstate PVForecast 2025-01-23 17:13:45 NextHours_Sum01_PVforecast 0 Wh
setstate PVForecast 2025-01-23 17:13:45 NextHours_Sum02_PVforecast 0 Wh
setstate PVForecast 2025-01-23 17:13:45 NextHours_Sum03_PVforecast 0 Wh
setstate PVForecast 2025-01-23 17:13:45 NextHours_Sum04_ConsumptionForecast 4310 Wh
setstate PVForecast 2025-01-23 17:13:45 NextHours_Sum04_PVforecast 0 Wh
setstate PVForecast 2025-01-23 17:13:45 RestOfDayConsumptionForecast 7452 Wh
setstate PVForecast 2025-01-23 17:13:45 RestOfDayPVforecast 0 Wh
setstate PVForecast 2025-01-23 00:59:50 Today_Hour01_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 00:59:50 Today_Hour01_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 00:59:50 Today_Hour01_GridConsumption 1072 Wh
setstate PVForecast 2025-01-23 00:59:50 Today_Hour01_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 00:59:50 Today_Hour01_PVreal 0 Wh
setstate PVForecast 2025-01-23 01:59:49 Today_Hour02_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 01:59:49 Today_Hour02_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 01:59:49 Today_Hour02_GridConsumption 970 Wh
setstate PVForecast 2025-01-23 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 01:59:49 Today_Hour02_PVreal 0 Wh
setstate PVForecast 2025-01-23 02:59:49 Today_Hour03_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 02:59:49 Today_Hour03_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 02:59:49 Today_Hour03_GridConsumption 707 Wh
setstate PVForecast 2025-01-23 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 02:59:49 Today_Hour03_PVreal 0 Wh
setstate PVForecast 2025-01-23 03:59:50 Today_Hour04_BatIn_01 100 Wh
setstate PVForecast 2025-01-23 03:59:50 Today_Hour04_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 03:59:50 Today_Hour04_GridConsumption 683 Wh
setstate PVForecast 2025-01-23 03:59:50 Today_Hour04_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 03:59:50 Today_Hour04_PVreal 0 Wh
setstate PVForecast 2025-01-23 04:59:49 Today_Hour05_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 04:59:49 Today_Hour05_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 04:59:49 Today_Hour05_GridConsumption 643 Wh
setstate PVForecast 2025-01-23 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 04:59:49 Today_Hour05_PVreal 0 Wh
setstate PVForecast 2025-01-23 05:59:56 Today_Hour06_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 05:59:56 Today_Hour06_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 05:59:56 Today_Hour06_GridConsumption 584 Wh
setstate PVForecast 2025-01-23 05:59:56 Today_Hour06_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 05:59:56 Today_Hour06_PVreal 0 Wh
setstate PVForecast 2025-01-23 06:59:49 Today_Hour07_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 06:59:49 Today_Hour07_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 06:59:49 Today_Hour07_GridConsumption 349 Wh
setstate PVForecast 2025-01-23 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 06:59:49 Today_Hour07_PVreal 0 Wh
setstate PVForecast 2025-01-23 07:59:58 Today_Hour08_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 07:59:58 Today_Hour08_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 07:59:58 Today_Hour08_GridConsumption 361 Wh
setstate PVForecast 2025-01-23 07:59:58 Today_Hour08_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 07:59:58 Today_Hour08_PVreal 0 Wh
setstate PVForecast 2025-01-23 08:59:59 Today_Hour09_BatIn_01 99 Wh
setstate PVForecast 2025-01-23 08:59:59 Today_Hour09_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 08:59:59 Today_Hour09_GridConsumption 581 Wh
setstate PVForecast 2025-01-23 08:59:59 Today_Hour09_GridFeedIn 0 Wh
setstate PVForecast 2025-01-23 08:59:59 Today_Hour09_PVforecast 32 Wh
setstate PVForecast 2025-01-23 08:59:59 Today_Hour09_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
setstate PVForecast 2025-01-23 09:59:49 Today_Hour10_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 09:59:49 Today_Hour10_BatOut_01 100 Wh
setstate PVForecast 2025-01-23 09:59:49 Today_Hour10_GridConsumption 148 Wh
setstate PVForecast 2025-01-23 09:59:49 Today_Hour10_GridFeedIn 78 Wh
setstate PVForecast 2025-01-23 09:59:49 Today_Hour10_PVforecast 216 Wh
setstate PVForecast 2025-01-23 09:59:49 Today_Hour10_PVreal 200 Wh
setstate PVForecast 2025-01-23 10:59:49 Today_Hour11_BatIn_01 1400 Wh
setstate PVForecast 2025-01-23 10:59:49 Today_Hour11_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 10:59:49 Today_Hour11_GridConsumption 102 Wh
setstate PVForecast 2025-01-23 10:59:49 Today_Hour11_GridFeedIn 229 Wh
setstate PVForecast 2025-01-23 10:59:49 Today_Hour11_PVforecast 2074 Wh
setstate PVForecast 2025-01-23 10:59:49 Today_Hour11_PVreal 2100 Wh
setstate PVForecast 2025-01-23 11:59:50 Today_Hour12_BatIn_01 3599 Wh
setstate PVForecast 2025-01-23 11:59:50 Today_Hour12_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 11:59:50 Today_Hour12_GridConsumption 78 Wh
setstate PVForecast 2025-01-23 11:59:50 Today_Hour12_GridFeedIn 547 Wh
setstate PVForecast 2025-01-23 11:59:50 Today_Hour12_PVforecast 1866 Wh
setstate PVForecast 2025-01-23 11:59:50 Today_Hour12_PVreal 5100 Wh
setstate PVForecast 2025-01-23 12:59:49 Today_Hour13_BatIn_01 2500 Wh
setstate PVForecast 2025-01-23 12:59:49 Today_Hour13_BatOut_01 200 Wh
setstate PVForecast 2025-01-23 12:59:49 Today_Hour13_GridConsumption 95 Wh
setstate PVForecast 2025-01-23 12:59:49 Today_Hour13_GridFeedIn 410 Wh
setstate PVForecast 2025-01-23 12:59:49 Today_Hour13_PVforecast 2050 Wh
setstate PVForecast 2025-01-23 12:59:49 Today_Hour13_PVreal 4000 Wh
setstate PVForecast 2025-01-23 13:59:58 Today_Hour14_BatIn_01 3900 Wh
setstate PVForecast 2025-01-23 13:59:58 Today_Hour14_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 13:59:58 Today_Hour14_GridConsumption 48 Wh
setstate PVForecast 2025-01-23 13:59:58 Today_Hour14_GridFeedIn 1104 Wh
setstate PVForecast 2025-01-23 13:59:58 Today_Hour14_PVforecast 4398 Wh
setstate PVForecast 2025-01-23 13:59:58 Today_Hour14_PVreal 7100 Wh
setstate PVForecast 2025-01-23 14:59:50 Today_Hour15_BatIn_01 900 Wh
setstate PVForecast 2025-01-23 14:59:50 Today_Hour15_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 14:59:50 Today_Hour15_GridConsumption 0 Wh
setstate PVForecast 2025-01-23 14:59:50 Today_Hour15_GridFeedIn 5237 Wh
setstate PVForecast 2025-01-23 14:59:50 Today_Hour15_PVforecast 3857 Wh
setstate PVForecast 2025-01-23 14:59:50 Today_Hour15_PVreal 6200 Wh
setstate PVForecast 2025-01-23 15:59:49 Today_Hour16_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 15:59:49 Today_Hour16_BatOut_01 0 Wh
setstate PVForecast 2025-01-23 15:59:49 Today_Hour16_GridConsumption 1 Wh
setstate PVForecast 2025-01-23 15:59:49 Today_Hour16_GridFeedIn 2510 Wh
setstate PVForecast 2025-01-23 15:59:49 Today_Hour16_PVforecast 1357 Wh
setstate PVForecast 2025-01-23 15:59:49 Today_Hour16_PVreal 3800 Wh
setstate PVForecast 2025-01-23 16:59:49 Today_Hour17_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 16:59:49 Today_Hour17_BatOut_01 600 Wh
setstate PVForecast 2025-01-23 16:59:49 Today_Hour17_GridConsumption 36 Wh
setstate PVForecast 2025-01-23 16:59:49 Today_Hour17_GridFeedIn 168 Wh
setstate PVForecast 2025-01-23 16:59:49 Today_Hour17_PVforecast 396 Wh
setstate PVForecast 2025-01-23 16:59:49 Today_Hour17_PVreal 600 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_Hour18_BatIn_01 0 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_Hour18_BatOut_01 100 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_Hour18_GridConsumption 4 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_Hour18_GridFeedIn 5 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_Hour18_PVreal 0 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_MaxPVforecast 4398 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_MaxPVforecastTime 2025-01-23 13:00:00
setstate PVForecast 2025-01-23 17:13:45 Today_PVdeviation -79.12 %
setstate PVForecast 2025-01-23 17:13:45 Today_PVforecast 16246 Wh
setstate PVForecast 2025-01-23 17:13:45 Today_PVreal 29100 Wh
setstate PVForecast 2025-01-23 16:38:45 Today_PVreal_kWh 29.1 kWh
setstate PVForecast 2025-01-23 17:13:45 Today_SunRise 08:00
setstate PVForecast 2025-01-23 17:13:45 Today_SunSet 17:04
setstate PVForecast 2025-01-23 17:13:45 Tomorrow_ConsumptionForecast 22638 Wh
setstate PVForecast 2025-01-23 17:13:45 Tomorrow_PVforecast 13216 Wh
setstate PVForecast 2025-01-23 17:13:45 Tomorrow_SunRise 07:58
setstate PVForecast 2025-01-23 17:13:45 Tomorrow_SunSet 17:05
setstate PVForecast 2023-10-09 13:54:01 associatedWith SolCastDummy
setstate PVForecast 2025-01-23 17:13:45 consumer01 name='WaMa Power 2-9' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate PVForecast 2025-01-23 17:13:45 consumer01_currentPower 0 W
setstate PVForecast 2025-01-23 17:13:45 consumer02 name='TK Power 4-21' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate PVForecast 2025-01-23 17:13:45 consumer02_currentPower 72 W
setstate PVForecast 2025-01-23 17:13:45 consumer03 name='PC Power 3-19' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate PVForecast 2025-01-23 17:13:45 consumer03_currentPower 142 W
setstate PVForecast 2025-01-23 17:13:45 consumer04 name='Backofen 54' state='unknown' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate PVForecast 2025-01-23 17:13:45 consumer04_currentPower 0 W
setstate PVForecast 2025-01-23 17:13:45 consumer05 name='Kühl 56' state='unknown' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate PVForecast 2025-01-23 17:13:45 consumer05_currentPower 76 W
setstate PVForecast 2025-01-23 17:13:45 consumer06 name='Mikro 58' state='unknown' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate PVForecast 2025-01-23 17:13:45 consumer06_currentPower 0 W
setstate PVForecast 2025-01-23 17:13:45 consumer07 name='Laser 36-12' state='off' mode='can' planningstate='noSchedule'
setstate PVForecast 2025-01-23 17:13:45 consumer07_currentPower 0 W
setstate PVForecast 2025-01-23 17:13:41 nextCycletime 17:14:51
setstate PVForecast 2025-01-23 17:13:45 nextRadiationAPICall ab 60 Minuten vor dem kommenden Sonnenaufgang
setstate PVForecast 2025-01-23 10:00:05 pvCorrectionFactor_10 0.63 (automatic - old factor: 0.56, Sun Alt range: 10, Cloud range: 95, Days in range: 2)
setstate PVForecast 2025-01-23 11:00:04 pvCorrectionFactor_11 0.94 (automatic - old factor: 0.79, Sun Alt range: 15, Cloud range: 95, Days in range: 2)
setstate PVForecast 2025-01-23 12:00:04 pvCorrectionFactor_12 1.63 (automatic - old factor: 1.13, Sun Alt range: 20, Cloud range: 95, Days in range: 2)
setstate PVForecast 2025-01-23 13:00:04 pvCorrectionFactor_13 1.55 (automatic - old factor: 1.10, Sun Alt range: 20, Cloud range: 95, Days in range: 2)
setstate PVForecast 2025-01-23 14:00:04 pvCorrectionFactor_14 1.82 (automatic - old factor: 1.63, Sun Alt range: 20, Cloud range: 90, Days in range: 2)
setstate PVForecast 2025-01-23 15:00:04 pvCorrectionFactor_15 1.50 (automatic - old factor: 1.16, Sun Alt range: 15, Cloud range: 90, Days in range: 2)
setstate PVForecast 2025-01-23 16:00:04 pvCorrectionFactor_16 1.33 (automatic - old factor: 0.83, Sun Alt range: 10, Cloud range: 80, Days in range: 2)
setstate PVForecast 2025-01-23 17:00:04 pvCorrectionFactor_17 0.73 (automatic - old factor: 0.68, Sun Alt range: 5, Cloud range: 80, Days in range: 2)
setstate PVForecast 2025-01-23 17:13:45 pvCorrectionFactor_Auto on_complex
setstate PVForecast 2024-08-13 21:30:17 setupStringAzimuth Dach=S BKW=S
setstate PVForecast 2024-08-13 21:30:17 setupStringDeclination Dach=30 BKW=85
setstate PVForecast 2025-01-23 17:13:45 special_SunHours_Remain 0.00
setstate PVForecast 2025-01-23 17:13:45 special_SunMinutes_Remain 0
setstate PVForecast 2025-01-23 17:13:45 special_conForecastTillNextSunrise 14673 Wh
setstate PVForecast 2025-01-23 17:13:45 special_dayAfterTomorrowPVforecast 19416 Wh
setstate PVForecast 2025-01-23 17:13:45 special_response_message success
setstate PVForecast 2025-01-23 17:13:45 state updated
Ja genau. Ich versuche bei mir die graphischen Einstellungen nachzubauen. Denn wie schon geschrieben gibt der Getter ein einwandfreies Bild zurück.
Ich habe deine grafischen Einstellungen bei mir nachgebaut und auch den Chrome (auf Laptop) verwendet, aber trotz mehrfachen "get ... html both" immer ein ordentliches Bild bekommen.
Ich beobachte weiter, vllt. können weitere User ebenfalls versuchen dein Problem nachzustellen.
(Browser Cache schon geleert?)
Zitat(Die Klasse "kkkkkkk..." ist etwas schräg)
Es gibt in dem ganzen Modul keine Zeichenfolge "kkkkkkk". FHEMWEB, f18js und fhemweb.js haben diese Zeichenfolge ebenfalls nicht im Bauch.
Irgendetwas scheint bei dir 'anders' zu sein.
Im morgigen Update ist die Erweiterung enthalten dass bei Anzeige der Batterieprognose ebenfalls die vergangenen (erreichten) SoC mit angezeigt werden.
LG
Zitat von: DS_Starter am 23 Januar 2025, 18:43:53Ich habe deine grafischen Einstellungen bei mir nachgebaut und auch den Chrome (auf Laptop) verwendet, aber trotz mehrfachen "get ... html both" immer ein ordentliches Bild bekommen.
Ich beobachte weiter, vllt. können weitere User ebenfalls versuchen dein Problem nachzustellen.
(Browser Cache schon geleert?)
Selber Effekt im Edge, auch nach Löschen der zwischengespeicherten Dateien. Hast du denn leichten Regen?
ZitatHast du denn leichten Regen?
Ja (Anhang).
Auch Edge bei mir ohne Befund.
Du kannst das Wetter ja mal ausblenden wenn es für dich verdächtig erscheint.
Welches FHEMWEB Style benutzt du? Vllt. ist das problematisch?
@all
Ich bin leider noch nicht fündig geworden welche Voraussetzungen (Parameter) erfüllt sein müssen, damit "special_todayBatIn_01" einen summierten Wert anzeigt. Kann mir netterweise jemand einen Tipp geben? Im Wiki habe ich nichts gefunden und im Forum gibt es zwar einen Treffer, aber der hilft mir nicht wirklich weiter?
Danke
VG Tom
Guten Morgen,
eine Summe über alle Batterien gibt es z.Z. (noch ?!? O:-) ) ==>>nicht
Ein Userreading läßt da bei mehreren Batterien grüßen ;)
Gruß
300P
Da kommt heute aber ein komische update mit diversen alten "Changes" rein....
Ich habe nichts ausgeschnitten oder so
2025.01.24 07:54:49 1: Downloading https://fhem.de/fhemupdate/controls_fhem.txt
2025.01.24 07:54:49 1: fhem
2025.01.24 07:54:49 1: RMDIR: ./restoreDir/update/2025-01-21
2025.01.24 07:54:49 1: UPD ./CHANGED
2025.01.24 07:54:49 1: UPD FHEM/76_SolarForecast.pm
2025.01.24 07:54:50 1: saving fhem.cfg
2025.01.24 07:54:50 1: saving ./log/fhem.save
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1: New entries in the CHANGED file:
2025.01.24 07:54:50 1: - feature: 76_SolarForecast: show historical battery SoC when displaying the
2025.01.24 07:54:50 1: battery in the bar graph
2025.01.24 07:54:50 1: - feature: 73_AutoShuttersControl:
2025.01.24 07:54:50 1: https://forum.fhem.de/index.php?topic=136510.0
2025.01.24 07:54:50 1: - feature: 76_SolarForecast: add temporary Migrate Getter x_migrate,
2025.01.24 07:54:50 1: Implementation of a Messaging System
2025.01.24 07:54:50 1: - change: 49_SSCam: fix Warning, set verified Version to 9.2.2
2025.01.24 07:54:50 1: - change: 76_SolarForecast: internal code change for data collection
2025.01.24 07:54:50 1: - change: 76_SolarForecast: FlowGraphic: SoC as a Cluster value of all Batts
2025.01.24 07:54:50 1: - bugfix: 76_SolarForecast: bugfix of version 1.43.3
2025.01.24 07:54:50 1: - change: 76_SolarForecast: consumption fc calc switch from average to median
2025.01.24 07:54:50 1: - change: 76_SolarForecast: Attr graphicBeam1MaxVal, ctrlAreaFactorUsage are
2025.01.24 07:54:50 1: obsolete
2025.01.24 07:54:50 1: - bugfix: 76_SolarForecast: fix interruptable key and some minor fixes
2025.01.24 07:54:50 1: Forum: ?topic=137058.msg1330100#msg1330100
2025.01.24 07:54:50 1: - feature: 76_SolarForecast: new Attr ctrlNextHoursSoCForecastReadings
2025.01.24 07:54:50 1: - feature: 76_SolarForecast: version 1.42.0 with some new features & fixes
2025.01.24 07:54:50 1: - change: 76_SolarForecast: Attr ctrlStatisticReadings to ctrlSpecialReadings
2025.01.24 07:54:50 1: old 'statistics_.*' readings to 'special_.*',
2025.01.24 07:54:50 1: special Readings BatPowerIn_Sum, BatPowerOut_Sum
2025.01.24 07:54:50 1: - bugfix: 76_SMAInverter.pm: fix STP X bug, fix STP TypeName
2025.01.24 07:54:50 1: - change: 76_SolarForecast: ctrlBatSocManagement to ctrlBatSocManagement01
2025.01.24 07:54:50 1: - change: 76_SolarForecast: rename of some readings, see Forum:
2025.01.24 07:54:50 1: ?topic=137058.msg1329009#msg1329009
2025.01.24 07:54:50 1: - feature: WMBus.pm: support for smoke detector IE6500-OMS: #1326558
2025.01.24 07:54:50 1: - change: 76_SolarForecast: more preparation for multi batteries
2025.01.24 07:54:50 1: ... rest of lines skipped.
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1: Downloading https://raw.githubusercontent.com/ThorstenPferdekaemper/FHEM-FUIP/master/controls_fuip.txt
2025.01.24 07:54:50 1: fuip
2025.01.24 07:54:50 1: nothing to do...
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1: Downloading https://raw.githubusercontent.com/knowthelist/ftui/master/controls_ftui.txt
2025.01.24 07:54:50 1: ftui
2025.01.24 07:54:50 1: nothing to do...
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1: Downloading https://raw.githubusercontent.com/fhempy/fhempy/master/controls_pythonbinding.txt
2025.01.24 07:54:50 1: pythonbinding
2025.01.24 07:54:50 1: nothing to do...
2025.01.24 07:54:50 1: Calling /usr/bin/perl ./contrib/commandref_modular.pl, this may take a while
2025.01.24 07:54:50 1:
2025.01.24 07:54:50 1: update finished, "shutdown restart" is needed to activate the changes.
Zitateine Summe über alle Batterien gibt es z.Z. (noch ?!? O:-) ) ==>>nicht
300P hat Recht, gibt es noch nicht. :o
Zitat von: DS_Starter am 24 Januar 2025, 01:08:16Welches FHEMWEB Style benutzt du? Vllt. ist das problematisch?
Unveränderter Standard, also F18. Grad ist auch kein leichter Regen vorhergesagt, Wechsel bringt also nix. Übernimmst du den Text nicht aus einem anderen Modul?
ZitatÜbernimmst du den Text nicht aus einem anderen Modul?
Nein, nur die Weather-ID. Der Text wird intern generiert.
Wie ist denn dein global Attr encoding gesetzt? (falls es gesetzt ist.)
Edit: Hast du die Wetterleiste mal zum Test ausgeblendet?
Zitat von: DS_Starter am 25 Januar 2025, 00:02:52Wie ist denn dein global Attr encoding gesetzt? (falls es gesetzt ist.)
Weder im Web noch im global seh was mit encoding, keine Ahnung...
ZitatWeder im Web noch im global seh was mit encoding
Dann ist es ok wenn es dir nichts sagt.
Wetterleiste mal ausblenden?
Auch mit ios12, aber halt nur bei der get Funktion...
fhem sf regen.png
Bei mir auch kein Problem. Get Funktion klappt einwandfrei. Ich habe da echt keine Idee.
Edit: Nochmal... blende die Leiste mal aus. Ob es wirklich nur an der Regenleiste liegt!
Guten Morgen,
ihr solltet im Mitteilungssystem die Nachricht erhalten haben dass die Spezial-Readings todayBatInSum und todayBatOutSum im kommenden Release erstellt werden können. Das ist die tägliche Energie aller Batterien In/Out als Summe.
Kann irgendjemand das von minierm beschriebene Problem nachstellen? Mir gelingt es einfach nicht den Fehler zu provozieren (was mich ja eigentlich freut).
Einfach ein "get ... html both" ausführen. Weiter vorn gibt es auch ein List seines Devices.
LG,
Heiko
Hier die Mittteilung :
Sehr schönes Tool !!!
Hab es dabei get ..hmtl both auch :o
Hatte es bislang aber noch nie bei mir probiert :-X
macOS 13.7.1 (22H221)
Safari Version 18.1.1 (18619.2.8.111.7, 18619)
PS: bin aber jetzt den ganzen Tag unterwegs....
:), danke.
Mir schwebt noch vor, dass der User darüber die Überwachung der Grenzwerte eines beliebigen Readings im Device einstellen kann. Das Thema hatten wir weiter vorn. Eine Verletzung des Grenzwertes würde dann direkt signalisiert.
Mal sehen ob das praktikabel umsetzbar ist und ob ein Interesse dafür vorhanden ist. (Macht ja auch ein bisschen Arbeit ;) )
Danke für den Test.
Bei meinem Windows Client und auch im Android tritt der Effekt nicht auf.
Es sieht so aus, als ob HTML title (eigentlich für den Mouse Over) an dieser Stelle Probleme verursacht.
@300P, minierm,
könnt ihr bitte consumerLink=0 setzen und dann "get..html both" testen?
Zitat von: DS_Starter am 25 Januar 2025, 00:44:23Bei mir auch kein Problem. Get Funktion klappt einwandfrei. Ich habe da echt keine Idee.
Edit: Nochmal... blende die Leiste mal aus. Ob es wirklich nur an der Regenleiste liegt!
Versteh ich nicht, wenn der Fehler doch nur bei der Regenanzeige auftaucht ist ausblenden nicht hilfreich?
Was genau meinst du mit "ausblenden"?
Ist auch egal, tritt ja nur bei der get Preview Funktion auf, Weblink funktioniert ja.
Zitat von: DS_Starter am 25 Januar 2025, 09:09:30@300P, minierm,
könnt ihr bitte consumerLink=0 setzen und dann "get..html both" testen?
Ändert leider nichts.
ZitatWas genau meinst du mit "ausblenden"?
Attr graphicShowWeather=0
ZitatVersteh ich nicht, wenn der Fehler doch nur bei der Regenanzeige auftaucht ist ausblenden nicht hilfreich?
Da ich das Problem bei mir nicht nachstellen kann suche und frage ich in alle Richtungen um einen Zusammenhang zu erkennen den ich bisher nicht erkenne.
Taucht er tatsächlich nur bei der Regenanzeige auf? Dann wäre es zumindest mal ein Ansatz für mich.
Zitat von: DS_Starter am 25 Januar 2025, 09:09:30@300P, minierm,
könnt ihr bitte consumerLink=0 setzen und dann "get..html both" testen?
Hab es auf meinem RPI (mit Chrom) und auf dem iPhone 11 Pro / IOS182.1 leider ebenso :-[ :'(
ConsumerLink ändern bei mir auch nicht's
Gruß
300P
hier zur Info:
Ich frage mich immer noch was der Unterschied zwischen euch und mir ist.
Mal bitte nur das Wetter und dann nur die Batterieleiste ausblenden und testen.
Attr graphicShowWeather=0
Batterie show=0
Alles ist okay 8)
Ok, dann habe ich jetzt zumindest mal einen Ansatz. Brauche ich nur noch eine Lösung. ::)
Zitat von: DS_Starter am 25 Januar 2025, 13:23:32ZitatWas genau meinst du mit "ausblenden"?
Attr graphicShowWeather=0
ZitatVersteh ich nicht, wenn der Fehler doch nur bei der Regenanzeige auftaucht ist ausblenden nicht hilfreich?
Da ich das Problem bei mir nicht nachstellen kann suche und frage ich in alle Richtungen um einen Zusammenhang zu erkennen den ich bisher nicht erkenne.
Taucht er tatsächlich nur bei der Regenanzeige auf? Dann wäre es zumindest mal ein Ansatz für mich.
Ist so: Kein Wetter, keine Probleme, kein wilder Code.
Wie gesagt, da es nur bei der Vorschau auftritt gibt es bestimmt interessantere/wichtigere Aufgabe...
Zitat von: 300P am 25 Januar 2025, 14:26:58Batterie show=0
Alles ist okay 8)
Tatsache! Wetter an, Batterie aus -> Wetter ist OK
Zitat von: minierm am 25 Januar 2025, 14:58:35Zitat von: 300P am 25 Januar 2025, 14:26:58Batterie show=0
Alles ist okay 8)
Tatsache! Wetter an, Batterie aus -> Wetter ist OK
...wobei es nach dem wieder Anzeigen auch noch OK ist...
SF Bat.png
...kann zwar wieder mal im Betrag die Grafik im Forum nicht laden :-X .....
aber bei mir ist der Fehler weiter vorhanden wenn die Batterien wieder eingeblendet werden
Testet mal bitte die V in meinem contrib.
Muß auch gleich weg ...
@300P, was mich völlih verwirrt ist das href hinter dem title in deinem Screen #1776.
Gibt es bei mir nicht und "kann" es eigentlich auch nicht geben.
ist beim Google Chrome Version auf dem MAC leider auch so
Version 131.0.6778.265 (Offizieller Build) (x86_64)
mit der Version 1.44.3 aus dem Contrib ist es leider weiter noch so wie bislang.
Habe das contrib nochmal gerade upgedatet.
Bin jetzt wirklich weg.
Ihr könnt zum Test mit der Zeile 15380 "spielen".
Zitat von: DS_Starter am 25 Januar 2025, 15:41:52@300P, was mich völlih verwirrt ist das href hinter dem title in deinem Screen #1776.
Gibt es bei mir nicht und "kann" es eigentlich auch nicht geben.
hab es im Code auch nicht entdecken können :-[
Ich habe das Problem übrigens auch nicht. Falls es einen Interessiert ;)
Habe eine Batterie und einen Wechselrichter angelegt. Vieleicht liegt es an multiplen Irgendwas.
War ja früher nicht da die Problematik.
Zitat von: DS_Starter am 25 Januar 2025, 16:04:42Habe das contrib nochmal gerade upgedatet.
Bin jetzt wirklich weg.
Ihr könnt zum Test mit der Zeile 15380 "spielen".
Ich kann mit "meinen Kenntnissen" nichts erkennen.
PS:
Blöd das es immer wieder verzögerte / oder gar keine Meldung von neuen Einträgen im Forum gibt...
An multiplen irgendwas liegt es auch nicht.
Bei mir gibt es Test-Setups in allen möglichen Varianten die allesamt keinen Fehler bei diesem Get liefern.
Ich habe ein nagelneues iPhone 15 aufgetrieben und mit dem Safari Browser den Get ausgeführt. Ebenfalls absolut problemlos. Anbei der Screenshot.
Wir können nur so vorgehen dass ich euch morgen Testversionen erstelle wo "kritische" Stellen sehr vereinfacht sind um evtl. Veränderungen festzustellen um der Problematik auf die Spur zu kommen.
Postet bitte noch den Output von "get ... valBattery".
Sieht bei mit so aus:
01 => balias => Pylontech Batteriestack
basynchron => 1
bcharge => 55
bchargewh => 15628.8
binstcap => 28416
bname => MQTT2_cerboGX_c0619ab34e08_battery
bpowerin => 0
bpowerout => 0
bshowingraph => 1
01 => balias => Bat
basynchron => 0
bcharge => 14.47
bchargewh => 1664.05
binstcap => 11500
bname => Strom_Bat_Aktuell
bpowerin => 0
bpowerout => 1463
bshowingraph => 1
Danke, auch nichts auffälliges. Schade.
Habe soeben eine Testversion ins contrib geladen.
Es kommen im Log dann viele Meldungen wie:
2025.01.26 00:02:39.084 1: SolCast6 - Test orig title: Batterie 02: Batterie Dummy 2
Ladefreigabe (evtl. Freigabe zum Laden der Batterie aktivieren)
SoC Prognose: 0.7 %
2025.01.26 00:02:39.086 1: SolCast6 - Test orig title: Batterie 02: Batterie Dummy 2
Ladefreigabe (evtl. Freigabe zum Laden der Batterie aktivieren)
SoC Prognose: 0.0 %
2025.01.26 00:02:39.089 1: SolCast6 - Test orig title: Batterie 02: Batterie Dummy 2
Ladefreigabe (evtl. Freigabe zum Laden der Batterie aktivieren)
SoC Prognose: 0.0 %
...
Einen Auschnitt von dir bräuchte ich dann auch.
Hab heute mal die verschiedenen FHEM-style versucht.
Beim f11 bekam ich eine Fehlermeldung.(aber nur 1 x nicht reproduzierbar)
(Screenshot)
Meine Vermutung geht inzwischen in die Richtung System-Hardware / RPI-OS da es ja auch sogar direkt auf dem RPI so ist.
Hier meine OS Angaben
pi@EnergyPi:~ $ sudo su
root@EnergyPi:/home/pi# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@EnergyPi:/home/pi#
Aber mal ehrlich,,,,,als wenn das momentan das größte Problem am Modul ist.....?"?"?"?"?
EDIT
Immer wieder das mit den verspäteten Anzeigen der neuen Einträge...hab da mit der neuen Version im vor dem Schreiben nicht "drin" gehabt..(versuche ich nachher mal)
Moin.
Das war ein JavaScript Fehler. Wenn nicht reproduzierbar erstmal zur Seite legen.
Nimm mal bitte die V aus dem contrib.
In dem Mouse Over über der Batterie wird nach "Batterie XX:" der Alias des Batteriedevices angezeigt.
Bei euch (mit dem Fehler) wird aber statt dem Alias ein href... eingefügt, sieht man in den Browser Entwicklertools. Ich habe keine Erklärung woher der kommt. Im Code wird er nicht eingefügt.
Das scheint aber auch nur bei der HTML Ausgabe so zu sein. Innerhalb von FHEM, minierm schrieb von einem weblink Device, ist auch alles Ok.
Nach wie vor alles etwas mysteriös.
ZitatAber mal ehrlich,,,,,als wenn das momentan das größte Problem am Modul ist.....
Nein, ist es nicht. ;)
Ich möchte nur nicht Probleme (sofern die überhaupt im Modul zu suchen sind) lange mitschleppen.
Solange die Grafik im Modul selbst und auch in einem weblink Device (was auch nur eine Ausgabe des Getters ist) in Ordnung ist, habe ich eigentlich keine Bauchschmerzen. Würde nur gern wissen unter welchen Umständen dieser Kauderwelsch zustande kommt.
Edit: Habe auch bei mir ein weblink Device angelegt:
defmod wl.SolCast weblink htmlCode { FHEM::SolarForecast::pageAsHtml ('SolCast', '-', 'both') }
attr wl.SolCast room Energie
Auch damit alles i.O.
An die Statistiker.
Bekommt jemand von Euch hier etwas angezeigt, d.h. aufsummiert?
Bei mir gibt's auch kein Problem mit der (in den weiter oben beschriebenen Beiträgen bzgl.) Darstellung. Meines Test erfolgten via Firefox und Chromium.
ZitatAn die Statistiker.
Bekommt jemand von Euch hier etwas angezeigt, d.h. aufsummiert?
Ja, siehe Anhang.
Schau mal die Batteriedaten mit "get ... pvCircular 99". In der Ausgabe sind relevant diese Schlüssel:
initdaybatintot01: 4037357.42363898, initdaybatintot02: -, initdaybatintot03: -
initdaybatouttot01: 3894141.18091429, initdaybatouttot02: -, initdaybatouttot03: -
batintot01: 4039417.22014438, batintot02: -, batintot03: -
batouttot01: 3895321.82043407, batouttot02: -, batouttot03: -
initdaybatintotXX, initdaybatouttotXX sollte gesetzt und fest sein.
batintotXX und batouttotXX sollten hochzählen je nachdem ob etwas in die Batterie geladen oder entladen wird.
Wenn die Bat im Standby bleibt (weder rein noch raus) bewegt sich an der Stelle nichts.
So - jetzt hab ich keinen Fehler mehr mit der jetzigen Version aus dem Conrib.
und auch das Log dazu
PS: werde auch noch ein weblink Device anlegen und mitteilen ;D
Ok, jetzt gilt es weiter zu suchen ...
hab erst einmal das "loggen" gestoppt"
Log3 ($name, 5, "$name - Test orig title: $title");
Oder einfach:
# Log3 ($name, 4, "$name - Test orig title: $title");
Zitat von: DS_Starter am 26 Januar 2025, 10:54:48ZitatAn die Statistiker.
Bekommt jemand von Euch hier etwas angezeigt, d.h. aufsummiert?
Ja, siehe Anhang.
Schau mal die Batteriedaten mit "get ... pvCircular 99". In der Ausgabe sind relevant diese Schlüssel:
initdaybatintot01: 4037357.42363898, initdaybatintot02: -, initdaybatintot03: -
initdaybatouttot01: 3894141.18091429, initdaybatouttot02: -, initdaybatouttot03: -
batintot01: 4039417.22014438, batintot02: -, batintot03: -
batouttot01: 3895321.82043407, batouttot02: -, batouttot03: -
initdaybatintotXX, initdaybatouttotXX sollte gesetzt und fest sein.
batintotXX und batouttotXX sollten hochzählen je nachdem ob etwas in die Batterie geladen oder entladen wird.
Wenn die Bat im Standby bleibt (weder rein noch raus) bewegt sich an der Stelle nichts.
Ist "initdaybatintoXX" ein Wert, der aus dem Speicher per Modbus oder wie auch immer ausgelesen wird? Ein fortlaufender Absolutwert des Speichers quasi?
Bei mir sieht es leider so aus. Ich greife nicht via Modbus auf den Speicher zu, sondern mit den Daten über das Fronius-Modul 98_fronius.pm
ZitatIst "initdaybatintoXX" ein Wert, der aus dem Speicher per Modbus oder wie auch immer ausgelesen wird? Ein fortlaufender Absolutwert des Speichers quasi?
Bei mir sieht es leider so aus. Ich greife nicht via Modbus auf den Speicher zu, sondern mit den Daten über das Fronius-Modul 98_fronius.pm
Woher die Daten kommen ist egal. Wichtig ist nur das Setup stimmt, d.h. die Angaben im Attr setupBatteryDevXX.
Hier genau lesen was in der Hilfe zu der Bedeutung der einzelnen Schlüssel geschrieben steht.
Zeig uns doch bitte mal das Attr.
So sieht mein "Fronius"-Eintrag aus:
Zitat"Fronius_WR pout=PowerFlow_Site_P_Akku:W pin=-pout:W charge=Storage_0_Controller_StateOfCharge_Relative cap=7680 icon=measure_battery_50@#262626:@yellow:measure_battery_100@red"
Absolutwerte habe ich nicht angelegt, da ich angenommen habe, dass um Mitternacht sowieso die Zählerei von Null beginnt. Über das Froniusmodul kann kein BYD-Absolutwert abgegriffen werden, wenn ich richtig informiert bin.
@heramol,
bei deinem Attr fehlen die Angaben:
intotal Reading welches die totale Batterieladung als fortlaufenden Zähler liefert (optional)
outtotal Reading welches die totale Batterieentladung als fortlaufenden Zähler liefert (optional)
Sie sind zwar optional, aber für die von dir gewünschte Statistik wichtig und werden benötigt.
@300P,
in meinem contrib gibt es wieder eine V zum Problemtest.
Die Ausgabe ist etwas länger im Log:
2025.01.26 11:52:56.414 4: SolCast5 - Test title nach Subst 8: Batterie 01: Batterie 1
SoC am Ende der Stunde: 50 %
2025.01.26 11:52:56.416 4: SolCast5 - Test title Addon 8:
2025.01.26 11:52:56.418 4: SolCast5 - Test title Zusammengesetzt 8: Batterie 01: Batterie 1
SoC am Ende der Stunde: 50 %
2025.01.26 11:52:56.420 4: SolCast5 - Test Return komplett 8: <tr class='odd'><td class='solarfc'></td><td title='Batterie 01: Batterie 1
SoC am Ende der Stunde: 50 %' class='solarfc' width='20' style='margin:1px; vertical-align:middle align:center; padding-bottom:1px;'><svg class=" measure_battery_50 grey" data-txt="measure_battery_50@grey" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" version="1.1" x="0px" y="0px" width="361px" height="361px" viewBox="0 0 361 361" style="enable-background:new 0 0 361 361;" xml:space="preserve" id="svg2" inkscape:version="0.48.5 r10040" sodipodi:docname="measure_battery_50.svg"><metadata id="metadata34"><rdf:RDF><cc:Work rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><defs id="defs32" /><sodipodi:namedview pagecolor="#ffffff" bordercolor="#666666" borderopacity="1" objecttolerance="10" gridtolerance="10" guidetolerance="10" inkscape:pageopacity="0" inkscape:pageshadow="2" inkscape:window-width="779" inkscape:window-height="480" id="namedview30" showgrid="false" inkscape:zoom="0.65373961" inkscape:cx="302.06678" inkscape:cy="180.5" inkscape:window-x="0" inkscape:window-y="0" inkscape:window-maximized="0" inkscape:current-layer="measure_x5F_battery_x5F_50" /> <g id="measure_x5F_battery_x5F_50" style="stroke:#000000;stroke-opacity:1"> <g id="g5" style="stroke:#000000;stroke-opacity:1" transform="matrix(1.6146267,0,0,1.6146267,-112.50812,-110.12429)"> <path style="font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-indent:0;text-align:start;text-decoration:none;line-height:normal;letter-spacing:normal;word-spacing:normal;text-transform:none;direction:ltr;block-progression:tb;writing-mode:lr-tb;text-anchor:start;baseline-shift:baseline;color:#000000;fill:grey;fill-opacity:1;stroke:none;stroke-width:10;marker:none;visibility:visible;display:inline;overflow:visible;enable-background:accumulate;font-family:Sans;-inkscape-font-specification:Sans" d="m 134.65625,89.15625 c -6.01649,0 -11,4.983509 -11,11 l 0,180 c 0,6.01649 4.98351,11 11,11 l 95.5,0 c 6.01631,0 11,-4.9825 11,-11 l 0,-180 c 0,-6.016491 -4.98351,-11 -11,-11 l -95.5,0 z m 0,10 95.5,0 c 0.60951,0 1,0.390491 1,1 l 0,180 c 0,0.6085 -0.39231,1 -1,1 l -95.5,0 c -0.60951,0 -1,-0.39049 -1,-1 l 0,-180 c 0,-0.609509 0.39049,-1 1,-1 z" id="path7" inkscape:connector-curvature="0" /> <path style="font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-indent:0;text-align:start;text-decoration:none;line-height:normal;letter-spacing:normal;word-spacing:normal;text-transform:none;direction:ltr;block-progression:tb;writing-mode:lr-tb;text-anchor:start;baseline-shift:baseline;color:#000000;fill:grey;fill-opacity:1;stroke:none;stroke-width:10;marker:none;visibility:visible;display:inline;overflow:visible;enable-background:accumulate;font-family:Sans;-inkscape-font-specification:Sans" d="m 169.625,69.65625 c -6.01649,0 -11,4.983509 -11,11 l 0,14 10,0 0,-14 c 0,-0.609509 0.39049,-1 1,-1 l 25.5,0 c 0.60951,0 1,0.390491 1,1 l 0,14 10,0 0,-14 c 0,-6.016491 -4.98351,-11 -11,-11 l -25.5,0 z" id="path9" inkscape:connector-curvature="0" /> </g> <g style="display:none;stroke:#000000;stroke-opacity:1" id="g11"> <path style="display:inline;fill:none;stroke:#000000;stroke-width:10;stroke-opacity:1" d="M221.141,266.334c0,3.313-2.688,6-6,6h-65.5 c-3.313,0-6-2.688-6-6v-6c0-3.314,2.687-6,6-6l65.5-20c3.313,0,6,2.686,6,6V266.334z" id="path13" /> <path style="display:inline;fill:none;stroke:#000000;stroke-width:10;stroke-opacity:1" d="M221.141,166.667c0,3.313-2.688,6-6,6l-65.5,20 c-3.313,0-6-2.687-6-6v-20c0-3.313,2.687-6,6-6l65.5-20c3.313,0,6,2.687,6,6V166.667z" id="path15" /> <path style="display:inline;fill:none;stroke:#000000;stroke-width:10;stroke-opacity:1" d="M221.141,120c0,3.313-2.688,6-6,6l-65.5,20 c-3.313,0-6-2.687-6-6v-26c0-3.313,2.687-6,6-6h65.5c3.313,0,6,2.687,6,6V120z" id="path17" /> <path style="display:inline;fill:none;stroke:#000000;stroke-width:10;stroke-opacity:1" d="M221.141,213.667c0,3.313-2.688,6-6,6l-65.5,20 c-3.313,0-6-2.687-6-6v-20c0-3.313,2.687-6,6-6l65.5-20c3.313,0,6,2.687,6,6V213.667z" id="path19" /> </g> <path style="fill:grey;fill-opacity:1;stroke:none" d="m 244.55206,319.90573 c 0,5.34925 -4.34011,9.68775 -9.68776,9.68775 H 129.10625 c -5.34926,0 -9.68776,-4.34012 -9.68776,-9.68775 v -9.68777 c 0,-5.35087 4.3385,-9.68776 9.68776,-9.68776 L 234.8643,268.23766 c 5.34926,0 9.68776,4.33689 9.68776,9.68777 v 41.9803 z" id="path21" inkscape:connector-curvature="0" /> <path style="display:none;fill:#FFFFFF;stroke:#000000;stroke-width:3;stroke-opacity:1" d="M221.141,166.667c0,3.313-2.688,6-6,6l-65.5,20 c-3.313,0-6-2.687-6-6v-20c0-3.313,2.687-6,6-6l65.5-20c3.313,0,6,2.687,6,6V166.667z" id="path23" /> <path style="display:none;fill:#FFFFFF;stroke:#000000;stroke-width:3;stroke-opacity:1" d="M221.141,120c0,3.313-2.688,6-6,6l-65.5,20 c-3.313,0-6-2.687-6-6v-26c0-3.313,2.687-6,6-6h65.5c3.313,0,6,2.687,6,6V120z" id="path25" /> <path style="fill:grey;fill-opacity:1;stroke:none" d="m 244.55206,234.86817 c 0,5.34926 -4.34011,9.68776 -9.68776,9.68776 l -105.75805,32.29254 c -5.34926,0 -9.68776,-4.3385 -9.68776,-9.68776 v -32.29254 c 0,-5.34926 4.3385,-9.68775 9.68776,-9.68775 L 234.8643,192.88788 c 5.34926,0 9.68776,4.3385 9.68776,9.68776 v 32.29253 z" id="path27" inkscape:connector-curvature="0" /> </g> <g id="Ebene_1" style="stroke:#000000;stroke-opacity:1"> </g> </svg></td>
Aber zum nächsten Eintrag gibt es eine Leerzeile zur besseren Separation.
Zitat von: DS_Starter am 26 Januar 2025, 11:32:18@heramol,
bei deinem Attr fehlen die Angaben:
intotal Reading welches die totale Batterieladung als fortlaufenden Zähler liefert (optional)
outtotal Reading welches die totale Batterieentladung als fortlaufenden Zähler liefert (optional)
Sie sind zwar optional, aber für die von dir gewünschte Statistik wichtig und werden benötigt.
Danke, habs vermutet.
Falls jemand ebenfalls das Problem hatte mit einem BYD ohne Absolutwertausgabe über das 98_Fronius.pm Modul:
https://forum.fhem.de/index.php?msg=1233760 (https://forum.fhem.de/index.php?msg=1233760)
jetzt funzt es :)
Zitat von: DS_Starter am 26 Januar 2025, 11:55:51@300P,
in meinem contrib gibt es wieder eine V zum Problemtest.
Die Ausgabe ist etwas länger im Log:
Hier das Ergebnis dieser Version als Log-Datei nach dem Restart/Einschalten + verbose 4
(um 15:56:45 hab ich get .... both gestartet)
Leider jetzt wieder mit dem "Fehler" in der Anzeige (Screenshot)
Gruß
300P
Danke.
ZitatLeider jetzt wieder mit dem "Fehler" in der Anzeige (Screenshot)
Ja, das ist ok. Ich will ja ergründen wo es herkommt.
Die Zip scheint fehlerhaft zu sein, kann ich nicht entpacken - unbekannter Fehler.
jetzt mal in mehrern Dateien O:-)
Ich schaue ..
Also der String <a href=....> ist _nicht_ in den Logs enthalten und wird definitiv nicht durch das Modul an dieser Stelle geliefert.
Das passt auch. Denn sonst müsste bereits die normale Anzeige im Modul und auch das weblink Device kaputt sein.
Es kommt also später etwas hinein was stört.
Kannst du bitte nochmal die Browserkonsole Screenen ob dort wieder der href String enthalten ist?
...
weblink-okay !!
Ich habe nochmal eine neue Testversion ins contrib geladen.
Kannst du bitte nochmal holen?
Und bitte auch mal nur ein "get ... html forecast" ausführen.
sorry - leider mit fehlerhafter Anzeige bei "both" und bei nur "forecast"
Ist ok. Aber das verbose 4 Log ist noch wichtig.
Dürfte ziemlich umfangreich sein.
Log3 ($name, 4, "$name - RET nach Ebene 1:\n".$ret);
Log3 ($name, 4, "$name - RET nach Ebene 2:\n".$ret);
Log3 ($name, 4, "$name - RET nach Ebene Flowgrafik:\n".$ret);
kommt - mein RPI3 will mit den entstandenen Datenmengen beim kopieren nicht so wie ich will.....
Ist mir schon 2 mal abgestürzt :o
Hier jetzt die ersten 10 Logteile hier für dich......
...hätte noch mehr, sind unendlich Daten für ein par Minuten Log.
Wdit:
Anderer Weg
WE - Downloadlink läuft nach 3 downloads ab
https://we.tl/t-GZ0ZN0q7kp
Danke für deine Mühe!
Die Auszüge werden reichen denke ich. Hoffe ich finde mal etwas zielführendes.
Aber für heute reicht es denke ich ;) Muß erstmal sichten.
Mist, ich war zu langsam. :o
nutz den link ;)
Ah, ich habe es. :-)
Die von mir gesuchte fehlerhafte Zeichenkette
title="Batterie 01: <a href=" fhem?detail="SBS25'">
ist im ganzen Text nicht zu finden, d.h. auch am Ende der Grafikgenerierung ist alles noch in Ordnung.
Jetzt kommt quasi nur noch die Rückgabe des Konstrukts an FHEMWEB zur Ausgabe.
Im Text ist der String völlig in Ordnung so wie er sein muß:
title='Batterie 01: SBS25 ....
Die Generierung im Modul ist völlig ok soweit ich es sehe.
Ich hab heute auf einen anderen (neuen) RPI-4 (Bookworm) ein komplett neues FHEM - mit den neuesten Updates - von Grund auf neu erstellt.
Diess TEST-FHEM beinhaltet jetzt nur meine WR / Batterien / Energiemeter / bzw. die notwendigen PV-Devices die für SF notwendig sind.
Als Ergebnis ergibt sich ebenfalls wieder der "Anzeigefehler" den wir die Tage versucht haben zu ergründen.
Schätze wir müssen es als "Glitsch" :o hinnehmen.
Wenn ich Zeit finde, mach ich das gleiche noch in einer VMWare-Maschine auf meinem MAC.
Gruß
300P
Ja, vermutlich. Mir fällt auch nichts dazu ein. Kurios ist nur, dass ich machen kann was ich will und dieses Anzeigeproblem einfach nicht nachgestellt bekomme.
Wie schon geschrieben ist m.M. nach die Grafikgenerierung völlig io. solange die Anzeige im Modul und auch in einem weblink Device (verwendet auch diesen Get) in Ordnung ist.
Hallo zusammen,
zunächst möchte ich mich herzlich für das großartige Modul bedanken! Ich bin mir nicht sicher, ob ich meine Frage hier stellen oder einen neuen Thread eröffnen soll, hoffe jedoch, dass ich hier richtig bin.
In unserem Wärmespeicher haben wir drei 3 kW Heizstäbe, die von einem AC-Thor angesteuert werden. Über einen Web-Request können wir einen Wert von 0 bis 9000 senden, um die Energie stufenlos in die Heizstäbe zu leiten. Ich habe ein DOIF-Skript erstellt, das den Wert bei vorhandenem Solar-Überschuss sekündlich anpasst.
Meine Frage ist nun: Ist es möglich, das SolarForecast-Modul ähnlich wie die dynamische Ladesteuerung im Wiki zu nutzen, beispielsweise durch Anpassungen in der Funktion ctrlUserExitFn? Müsste ich dafür den Parameter ctrlInterval auf 1 setzen? Hält das Modul dieser Frequenz stand?
Vielen Dank im Voraus für eure Unterstützung!
Beste Grüße,
Boris
Hallo Boris,
ein solches komplexes Modul mit einem 1 Sekunden Takt zu strapazieren damit das Wasser warm wird..... :o
Da wir wohl eher die CPU der Hardware "warm" werden O:-) und das FHEM-System gestresst.
N.m.M =>> Nein - lass es bei einer simplen kleinen und feinen Lösung mit einem (möglichst) größerem Intervall
Gruß
300P
Hallo Boris und 300P,
ich möchte noch ein paar Erläuterungen zum Verständnis geben und versuche die Fragen etwas auseinanderzunehmen.
ZitatMeine Frage ist nun: Ist es möglich, das SolarForecast-Modul ähnlich wie die dynamische Ladesteuerung im Wiki zu nutzen, beispielsweise durch Anpassungen in der Funktion ctrlUserExitFn?
Im Prinzip hast du über die ctrlUserExitFn alle Möglichkeiten. Du kannst hier den aktuell ermittelten Überschuß aus dem Reading Current_Surplus auslesen und davon abhängig einen entsprechenden Befehl an deine Heizstabsteuerung senden.
Das Auslesen erfolgt bei jedem Zyklus ctrlInterval bzw. wenn der Zyklus durch einen Event eines Devices, zum Beispiel des Energymeters, angestoßen wurde. Dazu setzt man den Schlüssel asynchron.
ZitatMüsste ich dafür den Parameter ctrlInterval auf 1 setzen?
Jaein. Das Modul hat eine interne Sperrverwaltung. Nach Durchlauf eines Zyklus, der je nach Hardware dauert (bei mir typisch ca. 30ms), erfolgt die Freigabe für einen neuen Zyklus nach frühestens 2s. Dieser Wert ist zunächst willkürlich gewählt um eine zu häufige Unterbrechnung durch Events zu verhindern.
Man kann ctrlInterval=1 setzen. Wie stark das System dadurch belastet wird, hängt von deiner Hardware und der Komplexität des Setups (Consumer etc.) ab. Allerdings wird es nicht nötig sein, da du das Modul auch eventgesteuert fahren kannst.
ZitatHält das Modul dieser Frequenz stand?
Ja. Nur halte ich es nicht für sinnvoll.
Warum? In FHEM arbeiten, soweit ich es beurteilen kann, die Devices für Energymeter oder Inverter bzw. Messung von Verbrauchern auch nicht mit einer Aktualisierungsferequenz von einer Sekunde. D.h. die Änderungsfrequenz des ermittelten Überschusses wird auch nicht 1 Sek. sein.
Besser wäre es m.M. nach das Modul z.B. mit dem Standardintervall laufen zu lassen und zusätzlich die Attr setupMeterDev und setupInverterDevXX asynchron einzurichten.
Dann werden bei Werteänderung automatisch zusätzliche Zyklen getriggert und auch die ctrlUserExitFn durchlaufen.
LG,
Heiko
Eine Sekunde ist sportlich.
Zumal der Sekundentakt eh vermutlich nicht einzuhalten geht. Schliesslich müssen alle Teilnehmer des Regelkreises auch <1sek intervalle liefern können.
Du könntest zum laden die vorhandene Energiemenge des Speichers(Warmwasserspeicher) ermitteln und als Batteriedevice abbilden mit SOC. Temperaturen, je mehr je besser in verschiedenen höhen, und bestenfalls der Druck (um noch genauer zu sein) sollten dazu bekannt sein. Ist nicht ganz so trivial aber durchaus möglich.
So mal ganz grob :
Du benötigs 1.16Wh um 1 liter Wasser um 1 Kelvin zu erhöhen.
Wenn du weisst wie hoch deine Frischwassertemperatur ist und du deine Temperaturen in deinem Kessel kennst, kannst du deine Wärmeinhalt des Kessels bestimmen.
Indem du dein Delta T (Temperatur Differenz Eintritt-Austritt) heranziehst.
Der Speicher sofern der Inhalt nicht aktiv umgewälzt wird, wird nicht überall gleich sein. Eher unten kalt und oben warm.
Ich habe sowas um den Wärmeinhalt meines Solarspeichers zu haben um zu entscheiden ob ich mit Warmwasser oder mit Kaltwasser die Waschmaschine beaufschlage.
Ist nicht hochgenau aber auch nicht unbrauchbar.
DeltaSol_BX.Temp_Speicher_o.*:.*
{
my $t_in = 10.0; #Temperatur Zulauf
my $v_up = 60.0; #wassermenge im oberen Bereich des Kessels
my $v_up_mid = 60.0; #wassermenge im mitteoben Bereich des Kessels
my $v_mid = 60.0; #wassermenge im mittleren Bereich des Kessels
my $v_mid_down = 60.0; #wassermenge im mitteunten Bereich des Kessels
my $v_down = 60.0; #wassermenge im unteren Bereich des Kessels
my $t_up = ReadingsNum("DeltaSol_BX","Temp_Speicher_oben",$t_in); # Obere Temperaturmessung
my $t_mid = ReadingsNum("DeltaSol_BX","Temp_Speicher_mitte",$t_in); # Mittlere Temperaturmessung
my $t_down = ReadingsNum("DeltaSol_BX","Temp_Speicher_unten",$t_in); # Untere Temperaturmessung
my $t_up_mid = ($t_up + $t_mid + 2)/2 -1; # Mitteoben Temperatur kalkuliert
my $t_mid_down = ($t_mid + $t_down + 2)/2 -1; # Mitteunten Temperatur kalkuliert
my $Wh_up = (($t_up-$t_in) * $v_up * 1.16); #Warmeinhalte oben
my $Wh_mid = (($t_mid-$t_in) * $v_mid * 1.16); #Warmeinhalte mitte
my $Wh_down = (($t_down-$t_in) * $v_down * 1.16); #Warmeinhalte unten
my $Wh_up_mid = (($t_up_mid-$t_in) * $v_up_mid * 1.16); #Warmeinhalte mitteoben
my $Wh_mid_down = (($t_mid_down-$t_in) * $v_mid_down * 1.16); #Warmeinhalte mitteunten
my $Wh_in = ($Wh_up + $Wh_mid + $Wh_down + $Wh_up_mid + $Wh_mid_down); #Wäremmenge gespeichert
my $Wh_old = ReadingsNum("WatertankDummy","Wh_old",0);
my $kWh_in = sprintf("%.3f", $Wh_in/1000);
##Hilfe zum Detektieren ob geladen oder entladen wurde. Ändere den Ausgabewert bei 20Wh Differenz.
if (abs($Wh_in - $Wh_old) > 20.0) {
fhem("setreading WatertankDummy kWh_in ".$kWh_in );
fhem("setreading WatertankDummy Wh_old ".$Wh_in );
}
##set readings for debug
fhem("setreading WatertankDummy dT_up ".$t_up);
fhem("setreading WatertankDummy dT_mid ".$t_mid);
fhem("setreading WatertankDummy dT_down ".$t_down);
fhem("setreading WatertankDummy dT_mid_up ".$t_up_mid);
fhem("setreading WatertankDummy dT_down_mid ".$t_mid_down);
fhem("setreading WatertankDummy Wh_up ".$Wh_up);
fhem("setreading WatertankDummy Wh_mid ".$Wh_mid );
fhem("setreading WatertankDummy Wh_down ".$Wh_down );
fhem("setreading WatertankDummy Wh_mid_up ".$Wh_up_mid );
fhem("setreading WatertankDummy Wh_down_mid ".$Wh_mid_down );
fhem("setreading WatertankDummy Wh_in ".$Wh_in );
}Damit könntest du bei vorhandensein mehrere Temperatursensoren in verschiedenen höhen verschiedene Temperaturzonen abbilden und daraus den Wärmeinhalt bestimmen.
Hallo Heiko,
ich bekomme heute (vorherige Tage hab ich nicht geprüft) folgende Log-Einträge, nur ein kleiner, aber repräsentativer Teil:
2025.01.29 01:02:35.996 1: mySolarForecast - Serialization ERROR: Can't store GLOB items at /usr/lib/x86_64-linux-gnu/perl/5.36/Storable.pm line 370, at .//FHEM/76_SolarForecast.pm line 20943.
2025.01.29 01:02:35.997 1: PERL WARNING: Use of uninitialized value in subroutine entry at .//FHEM/76_SolarForecast.pm line 16543.
2025.01.29 01:02:35.997 1: stacktrace:
2025.01.29 01:02:35.997 1: main::__ANON__ called by .//FHEM/76_SolarForecast.pm (16543)
2025.01.29 01:02:35.997 1: FHEM::SolarForecast::_retrieveMessageFile called by FHEM/Blocking.pm (194)
2025.01.29 01:02:35.998 1: main::BlockingStart called by FHEM/Blocking.pm (107)
2025.01.29 01:02:35.998 1: main::BlockingCall called by .//FHEM/76_SolarForecast.pm (16491)
2025.01.29 01:02:35.998 1: FHEM::SolarForecast::getMessageFileNonBlocking called by .//FHEM/98_apptime.pm (178)
2025.01.29 01:02:35.998 1: main::apptime_getTiming called by .//FHEM/98_apptime.pm (86)
2025.01.29 01:02:35.998 1: main::HandleTimeout called by fhem.pl (710)
2025.01.29 01:02:36.013 1: PERL WARNING: Use of uninitialized value $name in hash element at .//FHEM/76_SolarForecast.pm line 16559.
2025.01.29 01:02:36.013 3: eval: {FHEM::SolarForecast::_processMessageFile('')}
2025.01.29 01:02:36.013 1: stacktrace:
2025.01.29 01:02:36.013 1: main::__ANON__ called by .//FHEM/76_SolarForecast.pm (16559)
2025.01.29 01:02:36.014 1: FHEM::SolarForecast::_processMessageFile called by (eval 11336354) (1)
2025.01.29 01:02:36.014 1: (eval) called by fhem.pl (1180)
2025.01.29 01:02:36.014 1: main::AnalyzePerlCommand called by fhem.pl (1209)
2025.01.29 01:02:36.014 1: main::AnalyzeCommand called by fhem.pl (1136)
2025.01.29 01:02:36.014 1: main::AnalyzeCommandChain called by .//FHEM/98_telnet.pm (263)
2025.01.29 01:02:36.014 1: main::telnet_Read called by .//FHEM/98_apptime.pm (178)
2025.01.29 01:02:36.015 1: main::apptime_getTiming called by .//FHEM/98_apptime.pm (138)
2025.01.29 01:02:36.015 1: main::CallFn called by fhem.pl (789)
2025.01.29 02:19:15.992 1: mySolarForecast - Serialization ERROR: Can't store GLOB items at /usr/lib/x86_64-linux-gnu/perl/5.36/Storable.pm line 370, at .//FHEM/76_SolarForecast.pm line 20943.
Modulstand: FVERSION
76_SolarForecast.pm:v1.44.2-s29561/2025-01-23
Hast du eine Idee, was da passiert ist?
Viele Grüße Gisbert
Hallo Gisbert,
nicht wirklich. Es scheinen Daten nicht übergeben worden zu sein (FHEM::SolarForecast::_processMessageFile(''))
Wie dem auch sei, mach bitte erstmal ein FHEM Update denn wir sind schon über die Version drüber.
Aktuell ist die 1.44.4.
Dann schauen wir nochmal. Bei mir gibt es diese Meldungen jedenfalls nicht.
LG,
Heiko
Hallo Heiko,
danke für den Hinweis - das Update mache ich, dann beobachte ich weiter.
Anderes Thema:
Der Verbrauch bei mir hängt stark von der Außentemperatur ab, da ich eine Wärmepumpe habe.
Beispiel:
Sehr milde Temperaturen: 15 kWh am Tag
Sehr kalten Temperaturen: 40 kWh am Tag
Der vom Modul prognostizierte Verbrauch ist 30 kWh für heute, der tatsächliche Verbrauch liegt bei 18 kWh.
Ich habe keine Verbraucher in SolarForecast angelegt. Das war mir bisher zuviel Aufwand.
Gibt es eine Möglichkeit eine bessere Prognose für den Verbrauch zu bekommen?
Viele Grüße Gisbert
ZitatGibt es eine Möglichkeit eine bessere Prognose für den Verbrauch zu bekommen?
Momentan knoble ich daran die Anzahl der gespeicherten Verbrauchsdaten deutlich zu erhöhen (wie bei den PV Erzeugungungsdaten) um daraus einen besseren Medianwert berechnen zu können.
Dazu muß ich das Speicherungsverfahren umbauen damit mehr Werte länger gespeichert werden können, auch abhängig vom Wochentag.
Allerdings hat das dann noch keinen Bezug zur Außentemperatur.
Aber vllt. fällt mir auch dazu noch ein Verfahren ein. Jedenfalls ist der Verbrauch natürlich stark von der Temp. beeinflusst wenn eine WP betrieben wird. Das hatte ich so noch garnicht auf dem Schirm. Ähnliches gilt ja auch für eine Klimaanlage im Sommer. Auch nicht unerheblich.
Hallo Heiko,
nach dem Fhem-Update und Neustart bekomme ich folgende Log-Einträge:
2025.01.29 20:44:08.015 1: mySolarForecast - Serialization ERROR: Can't store GLOB items at /usr/lib/x86_64-linux-gnu/perl/5.36/Storable.pm line 370, at .//FHEM/76_SolarForecast.pm line 21029.
2025.01.29 20:44:08.016 1: PERL WARNING: Use of uninitialized value in subroutine entry at .//FHEM/76_SolarForecast.pm line 16570.
2025.01.29 20:44:08.028 1: PERL WARNING: Use of uninitialized value $name in hash element at .//FHEM/76_SolarForecast.pm line 16586.
2025.01.29 20:44:08.029 3: eval: {FHEM::SolarForecast::_processMessageFile('')}
Bei der Prognose der Verbrauchsdaten von Wärmepumpen und Klimaanlagen könnte man Anwender bezogene Stützstellen bereitstellen und als Temperatur eine mittlere Tagestemperatur aus einem Wettermodell, evtl. dem gleichen wie für die Solarvorhersage, benutzen.
Viele Grüße Gisbert
Sehr merkwürdig. Setze mal bitte verbose 4 im Device und starte FHEM neu.
Nach dem Restart erscheint mit einer Verzögerung von ein paar Minuten so ein (fehlerfreier) Block im Log:
2025.01.29 21:40:21.169 4: SolCast6 - Notification System - Message file >controls_solarforecast_messages_prod.txt< is retrieved non blocking
2025.01.29 21:40:21.340 4: SolCast6 - Notification System - new Message File updated to ./FHEM/controls_solarforecast_messages_prod.txt
2025.01.29 21:40:21.414 4: SolCast6 - Notification System - read local Message File >controls_solarforecast_messages_prod.txt< with 14 entries.
Wie sieht es bei dir aus?
Hallo Heiko,
ich bekomme mit verbose 4 folgende Log-Einträge:
2025.01.29 21:58:40.993 4: mySolarForecast - Notification System - Message file >controls_solarforecast_messages_prod.txt< is retrieved non blocking
2025.01.29 21:58:41.368 4: mySolarForecast - Notification System - new Message File updated to .//FHEM/controls_solarforecast_messages_prod.txt
2025.01.29 21:58:41.371 1: mySolarForecast - Serialization ERROR: Can't store GLOB items at /usr/lib/x86_64-linux-gnu/perl/5.36/Storable.pm line 370, at .//FHEM/76_SolarForecast.pm line 21029.
2025.01.29 21:58:41.371 1: PERL WARNING: Use of uninitialized value in subroutine entry at .//FHEM/76_SolarForecast.pm line 16570.
2025.01.29 21:58:41.377 1: PERL WARNING: Use of uninitialized value $name in hash element at .//FHEM/76_SolarForecast.pm line 16586.
2025.01.29 21:58:41.377 3: eval: {FHEM::SolarForecast::_processMessageFile('')}
Viele Grüße Gisbert
Ich vermute ein Problem mit dem Perl Modul Storable.pm welches bei dir installiert ist.
Eventuell ist es die Version.
Vielleicht kann ich die Stelle anders gestalten.
Ich habe eine SolarForecast Version in mein contrib geladen. Hole dir sie bitte und starte FHEM neu.
Dann schauen wir wie es damit aussieht.
Ich habe mich ja nicht getraut zu Fragen aber da Gisbert das Thema jetzt schon angesprochen hat.
Ich habe seit 3 Monaten auch eine Wärmepumpe, habe diese auch als Verbraucher im FHEM und habe mir auch schon gedacht eine Temperatur Kopplung wäre ideal.
Bei mir schwankt der Wert sogar noch mehr, bei tiefen minus graden über 100kWh am tag und jetzt wo es milder wird vielleicht 40kWH.
Ich denke Wärmepumpen sind Verbraucher die wir immer mehr sehen werden.
Eventuell könnte man hier dem Verbraucher noch eine Temperatur Reading mitgeben und dieses mit in die Vorhersage einfließen für diesen Verbraucher?
Ich wäre auch bereit zu helfen, wenn gewünscht, maintaine ja jetzt das vitoconnect Modul was zumindest Viessmann Wärmepumpen anbinden kann.
Dort könnte man auch COP und andere Werte bekommen, aber ich denke Temperatur wäre schon ein super Wert den man einfließen lassen könnte.
Danke und Gruß,
Stefan
Zitat von: DS_Starter am 29 Januar 2025, 22:45:33Ich habe eine SolarForecast Version in mein contrib geladen. Hole dir sie bitte und starte FHEM neu.
Dann schauen wir wie es damit aussieht.
Jetzt sieht es wohl gut aus:
2025.01.29 23:59:03.034 4: mySolarForecast - Notification System - Message file >controls_solarforecast_messages_prod.txt< is retrieved non blocking
2025.01.29 23:59:03.422 4: mySolarForecast - Notification System - new Message File updated to .//FHEM/controls_solarforecast_messages_prod.txt
2025.01.29 23:59:03.431 4: mySolarForecast - Notification System - read local Message File >controls_solarforecast_messages_prod.txt< with 14 entries.
Viele Grüße Gisbert
Hallo zusammen, super hier mitzulesen wie dieses geniale Modul immer intelligenter wird.
Allerdings wird es auch zunehmend komplizierter zu verstehen wie man es richtig mit Infos füttert. Ich benutze das Modul schon ca 3-4 Jahre und meine Anlage hat sich in der Zeit auch etwas erweitert. Nun beobachte ich die Prognosen und bin nicht zufrieden mit der Genauigkeit. Einerseits liegt es sicher an den Wettervorhersagen des DWD die selten der der Realität entsprechen, andererseits mach ich mir Gedanken über die Richtigkeit der Einbindung meiner etwas speziellen Anlage.
Aufbau:
6x Microwechselrichter 320 Wp (1 Panel) als Feld auf Dach Süd Ausrichtung
1x Microwechselrichter 600 Wp (2 Panel) auf Schuppendach Süd Ausrichtung an Solix Akku 1600 Wh
Das 6er Feld heißt im Modul "Dach" und das auf dem Schuppen "Akku"
Der 600 Wp Wechselrichter speist am Tage ausschließlich den Solix Akku bis er voll ist und leitet danach alles am Akku vorbei ins Hausnetz. Ab 21:00 entlade ich dann den Akku mit konstant 180 Wh bis er lehr ist.
Die Daten aller Wechselrichter werden über eine DTU eingesammelt und in Fhem bereitgestellt. Der Solix Akku ist auch als Device per MQTT eingebunden und stellt die benötigten Daten bereit.
Definiert habe ich das derzeit im Modul so:(zusammen kopiert)
attr SolarForcast setupBatteryDev01 Solarbank pin=solarbank_info_total_charging_power:W pout=solarbank_info_total_output_power:W intotal=statistics_1_total:kWh outtotal=statistics_2_total:kWh cap=1600:Wh charge=solarbank_info_solarbank_list_1_battery_power
attr SolarForcast setupInverterDev01 OpenDTU pv=Total_power:Wh etotal=Total_yieldtotal:kWh capacity=2400
attr SolarForcast setupInverterStrings Dach,Akku
attr SolarForcast setupStringPeak Dach=1.92 Akku=0.76
setstate SolarForcast 2024-07-01 18:40:45 setupStringAzimuth Dach=7 Akku=7
setstate SolarForcast 2024-07-01 18:40:45 setupStringDeclination Dach=20 Akku=10
Da die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.
Meine Frage nun: Ist das so in Ordnung, oder kann das Modul das so durcheinander bringen das die real Daten so von der Prognose abweichen.
Macht es Sinn den 600er Wechselerichter von dem InverterDev01 abzukoppeln und über ein Dummy ein InverterDev02 davon zu machen ?
Ich bin etwas Ratlos wie die Daten einer solchen Konstellation im Modul verarbeitet werden und ob es so zu Fehler in den Berechnungen kommt.
Zitat von: stefanru am 29 Januar 2025, 23:40:13... habe diese [Wärmepumpe] auch als Verbraucher im FHEM und habe mir auch schon gedacht eine Temperatur Kopplung wäre ideal.
Bei mir schwankt der Wert sogar noch mehr, bei tiefen minus graden über 100kWh am tag und jetzt wo es milder wird vielleicht 40kWH.
Ich denke Wärmepumpen sind Verbraucher die wir immer mehr sehen werden.
Zitat von: Gisbert am 29 Januar 2025, 20:36:15Der Verbrauch [meiner Wärmepumpe] bei mir hängt stark von der Außentemperatur ab, da ich eine Wärmepumpe habe.
Beispiel:
Sehr milde Temperaturen: 15 kWh am Tag
Sehr kalten Temperaturen: 40 kWh am Tag
Der vom Modul prognostizierte Verbrauch ist 30 kWh für heute, der tatsächliche Verbrauch liegt bei 18 kWh.
Ich habe keine Verbraucher in SolarForecast angelegt. Das war mir bisher zuviel Aufwand.
Gibt es eine Möglichkeit eine bessere Prognose für den Verbrauch zu bekommen?
Mit dem vorausschauende Heizungssteuerung beschäftigte ich mich auch: SolarForecast hat nmM schon viel unter der Haube, um sich in diese Richtung weiterzuentwickeln. Ich verfolge zwei Ansätze: Auf der Ist-Seite empirisch eine Relation herstellen zwischen den tatsächlichen Verbräuchen und der Außentemperatur: Ganz stumpf über meine Logs. Dabei orientiere ich mich an der (über das Statistikmodul sehr leicht umsetzbaren) Definition der Wetterdienste einer "Tagesmitteltemperatur" (TM) als Ist gemessen auf unserem Grundstück. Die TM wird ja auch für Heizspiegel herangezogen.
Daraus konnte ich bei mir (noch keine Wärmepumpe, aber fahre die bisherige Heizung versuchsweise mit den Vorlauftemperaturen und der Trägheit einer Wärmepumpe über den bereits montierten Pufferspeicher) mit Hilfe der Logs eindeutige Korrelationen feststellen. Wenn für einen Tag mit 5° Tagesmitteltemperatur 80 kWh Heizleistung verbraucht wurden, dann finde ich diesen Wert auch für die anderen Tage mit einer ähnlichen TM. So beschreiben es ja auch Gisbert und Stefan. Abweichungen kommen hier in Norddeutschland eindeutig bei scharfem Nordwind. Zweiter Parameter ist der solare Gewinn durch starke Sonneneinstrahlung, der aber (außer in Hoch-Nebelphasen der letzten Wochen) mit Hilfe der SolarForecast-Werte gut einzubringen sein müsste. Müsste, weil ich für diesen Aspekt erst Daten sammeln muss.
Nach "Vorne" sehe ich dann SolarForecast. Es nutzt ja die Vorhersagemodell der Wetterdienste, die natürlich auch die TMs für die nächsten Tage rechnen. Für meinen Standort passen die auch gut: Also für heute sind 5° TM vorhergesagt, ich erwarte also einen Verbrauch von 80 kWh - leider sagt das Modul SolarForecast aber auch, dass ich heute nur etwa 4 kWh PV "ernten" werde...
Das Ganze hat für mich noch den zusätzlichen Nutzen, dass bei Anwendung dynamischer Stromtarife ebenfalls ein "Vorratsheizen" oder andersherum: "zuwartendes" Heizen geplant werden könnte. Wenn ich morgen nach TM 100 kWh (Korrektur Mehrbedarf wegen Sturm oder Minderbedarf wegen Sonne ist für mich noch Theorie) brauchen werde, kann ich in Billigphasen Netzstrom als Wärme im Puffer einlagern. Wenn Solarforecast aber voraussagt, dass ich von 11-15 Uhr 60 kWh PV ernte, lass ich die Heizung nicht auf Netzstrom pumpen, nehme vielleicht sogar in Kauf, von 9 bis 12 einen halben Grad unter meine Solltemperatur zu rutschen, um die WP dann von 11-15 durchheizen zu lassen, dabei den Puffer auch über das Benötigte zu erwärmen. Davon kann ich dann ohne Netzbezug von 16 bis vielleicht 20 Uhr aus dem Puffer "zehren". Damit wäre ich quasi automatisch wieder im günstigen dynamischen Tarif für den nächsten Tages-Turn. Ganz bewusst verbrate ich PV-Strom nicht über einen Heizstab, sondern nutze den Hub der Pumpe und lagere PV auch nicht vorrangig in eine Batterie (um die ich für den Sommer ja nicht rumkomme), um die Wandlungsverluste von etwa 20 Prozent (rein+raus) zu vermeiden.
Letzter Gedanke: für das Durchdringen auch der Reaktions-Trägheit des Systems und der Korrelationen/Einflussparameter halfen mir die in der FHEM-Datenbank gelogten Echtdaten über mehrere Jahre. Wer das nicht hat, könnte mMn sich auch hier näherungsweise bedienen: Gradtagszahlen (https://www.iwu.de/publikationen/fachinformationen/energiebilanzen/#c205). Seine eigenen Verbräuche sollte man aber schon auf Tages- besser noch auf Stundenbasis haben ;-)
Viele Grüße
Christian
Zitat von: stefanru am 29 Januar 2025, 23:40:13Ich denke Wärmepumpen sind Verbraucher die wir immer mehr sehen werden.
Eventuell könnte man hier dem Verbraucher noch eine Temperatur Reading mitgeben und dieses mit in die Vorhersage einfließen für diesen Verbraucher?
Schwierig...
Momentan lebe ich einfach damit, dass die Prognose entsprechend "unscharf" ist, insbesondere bei großen Temperaturschwankungen.
Nur, woran festmachen?
Außentemperatur alleine ist es nicht, auch die Sonnenstunden bzw. der solare Ertrag durch die Fenster kann je nach Haustyp relevant sein.
Im Sommer ist dann die Innentemperatur und der Taupunkt die "Führungsgröße" für die Verbrauchsprognose der "Kälte"pumpe... ob das einfach abzubilden ist?
Naja klar gibt es da noch mehr Parameter.
Und wenn man im Sommer kühlt mit der Anlage (habe ich nicht vor) ist es nochmal anders.
Ich sehe ein dass es nicht so einfach ist.
Man muss ja aber auch nicht gleich die allumfassende Lösung für alle Eventualitäten haben.
Ich hatte jetzt gehofft wenn man der KI ein paar Daten mehr gibt (z.B. Temp und Solarertrag) könnte sie sich über die Zeit hier eventuell doch eine ganz gute Abschätzung für diesen Verbraucher erzeugen.
Ich denke man solle / kann hier keine exakte Wissenschaft draus machen. Es gibt zu viele Einflussgrößen und selbst die Vorhersagen von Temperatur und Solarertrag sind ungenau.
Dann kommt noch persönliches Verhalten hinzu. Sollte einem besonders kalt sein (krank) und man dreht deswegen die Heizkörper mehr wie sonst auf oder man hat Besuch oder man duscht heute mehr, oder, oder, oder.
Ich würde hier wirklich nur die rudimentärsten Daten nehmen und hoffen dass eine entsprechend große Abhängigkeit besteht dass zumindest ein Trend ermittelt werden kann.
Gruß,
Stefan
Zitat von: TheTrumpeter am 30 Januar 2025, 13:58:26Schwierig...
Momentan lebe ich einfach damit, dass die Prognose entsprechend "unscharf" ist, insbesondere bei großen Temperaturschwankungen.
Nur, woran festmachen?
Außentemperatur alleine ist es nicht, auch die Sonnenstunden bzw. der solare Ertrag durch die Fenster kann je nach Haustyp relevant sein.
Im Sommer ist dann die Innentemperatur und der Taupunkt die "Führungsgröße" für die Verbrauchsprognose der "Kälte"pumpe... ob das einfach abzubilden ist?
Die Außentemperatur hat den überwiegenden Einfluss auf die benötigte Wärmemenge. Nicht alle Fenster sind gleichzeitig zur Sonne gerichtet, wenn sie im Winter denn ausnahmsweise mal scheint, also auch aus diesem Grund ist dieser Faktor untergeordnet.
Eine verbesserte Verbrauchsprognose im Winter ist hilfreich für die Lade/Entladestrategie des Speichers auch im Hinblick auf eine strategischen Reserve für den Brown/Blackout-Fall. Bei entsprechenden solaren Überschuss gegenüber dem Verbrauch entlade ich den Speicher auf ein sinnvolles Minimum, um den Speicher voll nutzen zu können.
Im Sommer ist die Verbrauchsprognose eher nicht so wichtig, da da viel Sonne vorhanden ist und der Speicher meist nie leer wird.
Viele Grüße Gisbert
Zitat von: Gisbert am 30 Januar 2025, 14:13:13Die Außentemperatur hat den überwiegenden Einfluss auf die benötigte Wärmemenge. Nicht alle Fenster sind gleichzeitig zur Sonne gerichtet, wenn sie im Winter denn ausnahmsweise mal scheint, also auch aus diesem Grund ist dieser Faktor untergeordnet.
Eine verbesserte Verbrauchsprognose im Winter ist hilfreich für die Lade/Entladestrategie des Speichers ...
Genau das ist auch meine Erfahrung - die Außentemperatur hat den entscheidenden Einfluß auf den Wärmebedarf des ganzen Hauses, auch wenn einzelne Räume durch solaren Eintrag stark beeinflusst werden können (vernünftigerweise gehen dann dort die Heizkörperthemostaten zu, soweit man eine Einzelraumregelung hat, was mit Wärmepumpen ohne Speicher ja gerne vermieden wird, um den Mindestvolumenstrom garantiert zu erreichen). Bei der von mir bevorzugten Tagesmitteltemperatur ist die Wärmewirkung der Sonne indirekt auch dadurch berücksichtigt,das kräftiger Sonnenscheinn üblicherweise die Temperaturen mittags hochtreibt. An solch klaren Wintertagen sind aber üblicherweise durch die fehlende Schutzwirkung der Wolken die Nächte auch besonders kalt, weswegen ich vor einigen Jahren das als zweiten Grund fand, die TM zu benutzen.
Die Genauigkeit der Temperaturvorhersage ist auch nicht so erheblich: in meinem aktuell verwendeten Modell bedeutet ein Grad Vorhersage-Fehler im Bereich -5 bis +5° eine Veränderung der Mindesttemperatur meines Speichers um gut 0,5 Grad, das ist ein Wärmeinhalt von 5,8 kWh, die herzustellen braucht meine Referenz-WP-Installation in dem Temperaturfenster gerade mal 1,5 kWh Strom... Bei der Verlässlichkeit der PV-Prognose stelle ich da höhere Ansprüche, weil die Auswirkungen eines Fehlers auch finanziell deutlicher sind.
Bitte meine Beiträge gerne kritisch hinterfragen, ich bin mir sicher, dass ich längst nicht alles richtig bedacht habe.
Christian
Meinerseits möchte ich anregen, hier eher einen sehr generischen Weg zu gehen, um u.a. auch andere (künftige) Anwendungsfälle gleich mit berücksichtigen zu können.
Für ein besseres Forecasting müssten dem Forecaster alle als wesentliche erkannten Einflussgrüßen in quantifizierter Form (Vektor mit Einflussgrößen) vorliegen. Diese müsste man dem Forecaster als solche bekanntmachen. Für den Fall ,,Wärmepumpe" dürfen das neben der Außentemperatur auch Raumtemperaturen sowie die zu solare Strahlungsmenge sein. Auf dieser Basis ließe sich dann klassische oder aber KI-basiertes Forecasting durchführen. Der Einsatz der KI-basierten Lösung erscheint mir für diesen Zweck geeigneter als eine klassische modellbasierte Lösung, da erstere universeller ist und daher für den oben genannten generischen Weg äußerst prädestiniert ist.
Guten Abend zusammen,
die rege Diskusion zeigt mir wie stark doch das Interesse auch an einer wertigen Verbrauchsvorhersage ist.
Ich habe mir auch ein paar Gedanken zu einem gangbaren Weg gemacht und ein wenig im Netz gestöbert.
Dabei bin ich heute auf diese Seite gestoßen:
Optimierte KI-Prognose für Stromverbrauch und -erzeugung: Nachhaltige Energieeffizienz (https://digitalzentrum-hannover.de/praxisbeispiele/ki-prognose-von-stromverbrauch-und-erzeugung/)
Ich will nicht sagen das Digitalzentrum Hannover hätte bei SolarForecast abgeschaut :), aber wenn ihr euch den Beitrag durchlest, werdet ihr sicherlich auch schnell Parallelen zum SolarForecast Modul erkennen.
Mich bestärkt es in der Ansicht, dass wir uns auf einem guten Weg Weg befinden und auch schon sehr gut "im Rennen" liegen.
Also was die Verbruchsprognose betrifft, werde ich die AI Raw-Daten (get ... valDecTree aiRawData) um Verbrauchswerte anreichern. Temepraturen sind bereits vorhanden. Mit diesen Daten kann eine zweite KI Instanz installiert werden, die die Verbrauchsprognose unterstützt. Alternativ schaue ich mir auch mal den in dem Link verwendeten K-Nearest-Neighbor (KNN) Algorithmus an.
Der erste Schritt ist zunächst eine erweiterte Datensammlung die ich im Modul implementiere.
@Skusi
ZitatDa die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.
Das ist ein nicht so glückliches Setup. Abgesehen davon dass ich nicht verstehe wieso per DTU auch in der Nacht eine PV Leistung übermittelt wird, ist es problematisch wenn die erzeugte WR Leistung nicht in den setupInverterDevXX - Readings ankommt. Nur dort wird die PV-Leistung auch als solche gewertet.
Im BatteryDev01 gemeldete Leistungen können im Fall des BatIn auch eine Beladung aus dem Netz sein.
Hier müsstest du schauen, ob du mittels userReadings ein genaueres Input dem Modul bereitstellen kannst.
@Gisbert,
danke für deine Rückmeldung. Die Änderung checke ich ein und ist dann morgen früh im Update.
LG,
Heiko
Zitat von: DS_Starter am 30 Januar 2025, 19:11:38...
Also was die Verbruchsprognose betrifft, werde ich die AI Raw-Daten (get ... valDecTree aiRawData) um Verbrauchswerte anreichern. Temepraturen sind bereits vorhanden. Mit diesen Daten kann eine zweite KI Instanz installiert werden, die die Verbrauchsprognose unterstützt.
...
Hast Du mal über meine Vorschlag in Richtung Generalisierung nachgedacht?
Moin Parallix,
ja habe ich. In diese Richtung will ich ja durch den Einsatz/Unterstützung einer KI für diese Prognose gehen.
Zitat von: DS_Starter am 31 Januar 2025, 07:44:17Moin Parallix,
ja habe ich. In diese Richtung will ich ja durch den Einsatz/Unterstützung einer KI für diese Prognose gehen.
Hatte Dein vorheriges Posting so verstanden, dass Du ein ein einmal fixiertes Set an Readings nutzen möchtest. Meinerseits hatte ich angeregt, dass Du dem User die Möglichkeit gibst. dieses Set selber zu definieren. Aus meiner Sicht wäre es vielleicht sogar sinnvoll, dem User gleich die Möglichkeit zu geben, Forecastings für unterschiedliche Verbraucher (auf Basis unterschiedlicher Readings) erstellen zu lassen. Vielleicht sollte man die Gelegenheit nutzen, die damit verbundenen Codeanteile aus SF (Solar Forecasting) zu ziehen und in einem neuen Modul CF (Consumer Forecasting) zu bündeln, oder?
ZitatHatte Dein vorheriges Posting so verstanden, dass Du ein ein einmal fixiertes Set an Readings nutzen möchtest.
Nicht Readings, aber entsprechende Inputdaten mit denen die verwendete KI trainiert werden kann.
Diese Inputdaten finden sich im "get ... valDecTree aiRawData" visualisiert. Diese Daten können bei Bedarf angereichert/ergänzt werden, benötigen aber eine Struktur damit AI::DecionTree damit etwas anfangen kann (z.B. diskrete Daten in Bins organisieren).
Deswegen ist das nicht so "frei" machbar.
Möglicherweise setze ich auch nochmal eine andere KI ein, z.B. AI::MxNet. Das ist dann nochmal eine andere Hausnummer.
Für einzelne Verbraucher eine KI-Prognose zu erstellen bedarf nochmal deutlich mehr Daten, nämlich die Stundenwerte für jeden einzelnen Verbraucher über eine lange Zeit speichern und natürlich auch managen wenn z.B. ein Verbraucher sich ändert oder seine Kenngrößen ändert.
Man kann sicher alles erdenkliche erschaffen, es braucht nur sehr viel Zeit. Irgendwann braucht man vllt. auch einen Datencontainer (z.B. ein Redis) um die immer größer werdenden Mengen performant zur Verfügung zu haben. So kommt eins zum Anderen und ich muß aufpassen dass ich mich vor mir selbst schütze. ;)
Deswegen in kleinen Schritten voran...
Zitat von: DS_Starter am 31 Januar 2025, 10:47:16...
Diese Daten können bei Bedarf angereichert/ergänzt werden, benötigen aber eine Struktur damit AI::DecionTree damit etwas anfangen kann (z.B. diskrete Daten in Bins organisieren). Deswegen ist das nicht so "frei" machbar.
Zitat...
So kommt eins zum Anderen und ich muß aufpassen dass ich mich vor mir selbst schütze. ;)
Das Problem kenne ich und man sollte es auch ernst nehmen!
Hatte mich eben nur gefragt, ob man SF (weil es ja für "Solar Forecasting" steht) nicht durch Herausnahme des "Consumer Forecasting"-Teils etwas entschlacken könnte und damit vielleicht für Dich aber auch die User handhabbarer machen könne. Bei nochmaligem Betrachten müsste man dann - insb. wenn man in Richtung eines EMS gehen will - wahrscheinlich auch noch mehr machen, weil die BATs (als besondere Consumer, die auch liefer können) ja einen wichtigen Anteil ausmachen.
Ergo: Dein Modul ist super, vom Funktionsumfang ist unglaublich viel drin und da es wird wahrscheinlich immer schwieriger wird, Teilfunktionalität (wie das Forecasting für "normale" Consumer) auszulagern, würde ich es hier (u.a. auch aus Selbstschutzgründen) an Deiner Stelle auch nicht mehr anreichern.
Hi Heiko,
hatte vor kurzem das Forecast Modul bei mir geupdated und auch die Anpassung auf das neue Datenmodel ausgeführt.
Finde heute folgende Zeilen im FHEM log:
2025.01.31 19:43:10 1: Forecast - Serialization ERROR: Can't store GLOB items at /usr/lib/aarch64-linux-gnu/perl/5.32/Storable.pm line 370, at ./FHEM/76_SolarForecast.pm line 21029.
2025.01.31 19:43:10 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/76_SolarForecast.pm line 16570.
Hier noch ein Stacktrace:
2025.01.31 20:59:50 1: Forecast - Serialization ERROR: Can't store GLOB items at /usr/lib/aarch64-linux-gnu/perl/5.32/Storable.pm line 370, at ./FHEM/76_SolarForecast.pm line 21029.
2025.01.31 20:59:50 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/76_SolarForecast.pm line 16570.
2025.01.31 20:59:50 1: stacktrace:
2025.01.31 20:59:50 1: main::__ANON__ called by ./FHEM/76_SolarForecast.pm (16570)
2025.01.31 20:59:50 1: FHEM::SolarForecast::_retrieveMessageFile called by FHEM/Blocking.pm (194)
2025.01.31 20:59:50 1: main::BlockingStart called by FHEM/Blocking.pm (107)
2025.01.31 20:59:50 1: main::BlockingCall called by ./FHEM/76_SolarForecast.pm (16518)
2025.01.31 20:59:50 1: FHEM::SolarForecast::getMessageFileNonBlocking called by ./FHEM/98_apptime.pm (178)
2025.01.31 20:59:50 1: main::apptime_getTiming called by ./FHEM/98_apptime.pm (86)
2025.01.31 20:59:50 1: main::HandleTimeout called by fhem.pl (710)
2025.01.31 20:59:50 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/76_SolarForecast.pm line 16586.
2025.01.31 20:59:50 1: eval: {FHEM::SolarForecast::_processMessageFile('')}
2025.01.31 20:59:50 1: stacktrace:
2025.01.31 20:59:50 1: main::__ANON__ called by ./FHEM/76_SolarForecast.pm (16586)
2025.01.31 20:59:50 1: FHEM::SolarForecast::_processMessageFile called by (eval 13689662) (1)
2025.01.31 20:59:50 1: (eval) called by fhem.pl (1180)
2025.01.31 20:59:50 1: main::AnalyzePerlCommand called by fhem.pl (1209)
2025.01.31 20:59:50 1: main::AnalyzeCommand called by fhem.pl (1136)
2025.01.31 20:59:50 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2025.01.31 20:59:50 1: main::telnet_Read called by ./FHEM/98_apptime.pm (178)
2025.01.31 20:59:50 1: main::apptime_getTiming called by ./FHEM/98_apptime.pm (138)
2025.01.31 20:59:50 1: main::CallFn called by fhem.pl (789)
Hast du eine Idee?
Gruß,
Stefan
Hallo Stefan,
heute früh im Update gab es einen Fix dafür. Gisbert hatte es bereits gemeldet.
Lg
Ah ok, danke, hatte ich nicht mitbekommen.
Hallo,
tolles Modul!
Ich habe eine Frage, die 125 Seiten habe ich nicht gelesen, aber gesucht und nichts gefunden.
Ich habe 2 Inverter und 3 Strings, ich würde gerne alles Strings sehen in der Grafik, aber er fast die 2 zusammen, die auf dem einen Inverter liegen.
Ich habe schon versucht 2 Mal den Inverter einzutragen, natürlich mit unterschiedlichen AC Power, ich habe es mit einem Dummy versucht, aber er ignoriert mich *g
Jemand ne Idee oder eine Stelle im Wiki, die ich nicht gesehen habe?
Danke!
Hallo Moli,
ich hoffe dir macht das Modul viel Freude und vor allem viel Nutzen. :)
Die PV-Module bzw. PV-Strings werden in der Grafik nicht dargestellt. Die oberste Ebene sind die Inverter / Producer.
Wenn du 2 Inverter hast, definierst du die beiden und ordnest die Strings zu. Sie erscheinen aber nicht in der Grafik, nur die entsprechenden Inverter.
Im Anhang siehst du ein Setup mit einem Inverter und einem Smartloader (DC-DC Batterielader).
(Den Thread muß man nicht durchlesen, das wird nicht erwartet. Hier wird stetig weiterentwickelt.)
LG,
Heiko
@all,
wie angekündigt wird morgen früh die Version 1.45.0 ausgeliefert.
Mit dem Update werden die gespeicherten PV Ergebnisse in die neue Median kompatible Form migriert.
Das betrifft nur Devices bei denen ihr die Umstellung mit "get ... x_migrate" noch nicht durchgeführt habt.
Es passiert alles automatisch -> kein ToDo.
Weiterhin ist implementiert:
- im Config Check wird geprüft ob AI::DecisionTree installiert ist. Zukünftig beabsichtige ich die KI auch
für die Verbrauchprognose zur Unterstützung mit einzusetzen. Dann braucht man das Modul.
Der Check gibt auch den Hinweis wie das Modul zu installieren ist, wenn nicht vorhanden.
- die KI-Rohdaten (get ... valDecTree aiRawData) sammeln nun auch die Verbrauchsdaten den Hauses. (Aufrufbar wenn AI::DecisionTree installiert ist)
Diese Daten sind die Grundlage um später eine KI-Unterstützung für die Verbrauchsprognose implementieren zu können.
Grüße,
Heiko
Zitat von: DS_Starter am 01 Februar 2025, 17:58:09Hallo Moli,
ich hoffe dir macht das Modul viel Freude und vor allem viel Nutzen. :)
Die PV-Module bzw. PV-Strings werden in der Grafik nicht dargestellt. Die oberste Ebene sind die Inverter / Producer.
Wenn du 2 Inverter hast, definierst du die beiden und ordnest die Strings zu. Sie erscheinen aber nicht in der Grafik, nur die entsprechenden Inverter.
Im Anhang siehst du ein Setup mit einem Inverter und einem Smartloader (DC-DC Batterielader).
(Den Thread muß man nicht durchlesen, das wird nicht erwartet. Hier wird stetig weiterentwickelt.)
LG,
Heiko
Ja, super Arbeit!
Das ist schade, ich finde die Strings zu sehen schon praktisch, ich habe leider im Süden, weil die Garage niedrig ist Jahreszeiten bedingt, Schatten.
Das zu verfolgen, finde ich schon interessant.
Ich habe den Wechselrichter jetzt doch noch mal gelöscht und 2 Mal hinzufügt jetzt sehe ich 2 "Monde".
Mal sehen, was morgen passiert.
Danke und Gruß
Hallo zusammen,
das Modul ist wirklich spitze,nur ist mir gestern, nachdem endlich Mal wieder etwas Sonne den Speicher geladen hat, aufgefallen dass der Speicher trotzdem mit 0% angezeigt wird. Keine Ahnung, wie lange das schon so ist. Im zugehörigen device vom WR ist noch alles ok. Hab ich da irgendwie eine Umstellung verpasst? Alles andere läuft noch, soweit ich das sehen kann...
Grüße Christian
Moin,
das selbe bei mir. Anzeige in der Grafik ist 0% in dem Reading "Current_BatCharge_01" wird 23% angezeigt.
des Weiteren liefert mir der PlantConfiguration Check ein gelbes Ausrufezeichen
Another official FHEM/76_SolarForecast.pm version is available on SVN (creation time: 2025-02-02_07:45:03, size: 1389108 Bytes).
erfülltFhem ist up to date.
FVERSION
76_SolarForecast.pm:v1.45.0-s29607/2025-02-01
Guten Morgen,
@Christian, dir fehlt im Attr setupBatteryDevXX sicherlich der Schlüssel
cap. Er wurde im Zuge der Weiterentwicklung obligatorisch (vorher optional).
@Moli,
ZitatDas ist schade, ich finde die Strings zu sehen schon praktisch, ich habe leider im Süden, weil die Garage niedrig ist Jahreszeiten bedingt, Schatten.
Das ist nachvollziehbar. Vielleicht wird das Modul auch noch dahingehend ergänzt, momentan steht es bei mir noch nicht auf der Agenda. Das Backlog ist z.Zt. schon gut gefüllt.
Vermutlich wären dann noch weitere Schlüssel in den setupInverterDevXX nötig um die DC Inputleistung der PV-Module zu beschreiben.
Edit:
@Shadow3561, der
cap wie beschrieben.
LG,
Heiko
Zitatdir fehlt im Attr setupBatteryDevXX sicherlich der Schlüssel cap.
Das habe ich bei mir bereits drin.
Aber nach genauem durchsehen ist mir aufgefallen, dass es jetzt ohne Angabe der Einheit sein muss
Vorher
cap=8000:Wh
Jetzt
cap=8000Dann wird der SOC wieder angezeigt.
@DS_Starter
Danke für den Wink mit dem Zaunpfahl
ZitatAber nach genauem durchsehen ist mir aufgefallen, dass es jetzt ohne Angabe der Einheit sein muss
Das war schon immer so. Nur war die Inputprüfung des Attributs fehlerhaft/zu schwach um diese Fehleingabe zu werfen. Das habe ich in einer der letzten Versionen nachgezogen. Deswegen merkt man das bei der Eingabe nun sofort. ;)
Noch ein Nachtrag.
Nach dem heutigen update findet sich folgende Zeile im log
PV_forecast - update ERROR open ./FHEM//controls_solarforecast_messages_prod.txt failed: Permission denied
Abgesehen davon dass ein "/" zuviel ist (was ich fixen muss) schau mal bitte ob dieses File (./FHEM/controls_solarforecast_messages_prod.txt) die richtigen Owner (fhem dialout) und Schreibrechte (775) hat.
Zitat von: DS_Starter am 02 Februar 2025, 11:29:29./FHEM/controls_solarforecast_messages_prod.txt
Dieses file existiert bei mir nicht.
Ich habe nur "controls_solarforecast.txt"
EDIT:
Hat dich gerade wie von Zauberhand erledigt.
habe die Rechte mit ls -l überprüft und plötzlich ist die Datei vorhanden. FHEM-Log zeigt keinen Fehler. Die Date ist nicht leer.
-rwxrwxr-x 1 fhem dialout 1095 Feb 2 12:02 controls_solarforecast_messages_prod.txtDas ist wirklich komisch.
Dann kann es nicht angelegt werden. Das FHEM-Verzeichnis hat sicherlich die Rechte?
Ich fixe erstmal das "//" und melde mich.
Du hast gerade geantwortet als ich meinen Beitrag editiert habe.
Jetzt ist die Datei plötzlich da
Mystic :)
Fixen muss ich das "//" dennoch.
Moin,
nach dem letzten Update und Restart habe ich diese Zeilen im Log:2025.02.02 13:41:33.314 1: PERL WARNING: Argument "13:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.314 1: PERL WARNING: Argument "14:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.314 1: PERL WARNING: Argument "23:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.315 1: PERL WARNING: Argument "00:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.315 1: PERL WARNING: Argument "01:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.315 1: PERL WARNING: Argument "02:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.315 1: PERL WARNING: Argument "03:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.315 1: PERL WARNING: Argument "04:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.315 1: PERL WARNING: Argument "05:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.315 1: PERL WARNING: Argument "06:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.316 1: PERL WARNING: Argument "07:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.316 1: PERL WARNING: Argument "08:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.316 1: PERL WARNING: Argument "15:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.316 1: PERL WARNING: Argument "09:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.316 1: PERL WARNING: Argument "10:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.316 1: PERL WARNING: Argument "11:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.316 1: PERL WARNING: Argument "12:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.317 1: PERL WARNING: Argument "16:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.317 1: PERL WARNING: Argument "17:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.317 1: PERL WARNING: Argument "18:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.317 1: PERL WARNING: Argument "19:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.317 1: PERL WARNING: Argument "20:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.317 1: PERL WARNING: Argument "21:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
2025.02.02 13:41:33.318 1: PERL WARNING: Argument "22:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15195.
Gruß,
Christoph
Hallo,
zunächst mal, das Modul ist super, ich nutze es schon einige Monate und die Steuerung eines Luftentfeuchters funktioniert einwandfrei.
Nun habe ich seit einige Wochen das Problem, dass im Balkendiagramm die Erzeugte PV-Energie (siehe Bild1) nicht richtig angezeigt wird: Vormittag keine Werte und, wenn dann was kommt, Anzeige zu gering. Für 13 und 14 Uhr hätte ich ca. 5.000Wh erwartet (siehe auch Bild2 aus der PV-Cloud).
Screenshot 2025-02-02 161744.pngScreenshot 2025-02-02 162854.png
Habe schon alles mögliche auf Default gestellt, aber leider den Fehler nicht gefunden. Bis dahin gab es den Fehler nicht und leider kann ich nicht mehr nachvollziehen, welchen Change es beim Auftreten des Fehlers bzw. der ersten Beobachtung gab. Die angezeigten IST-Werte bei den Verbindungslinien sehen immer valide aus.
Sieht jemand, an welcher Stelle ich etwas falsch konfiguriert habe?
Wäre super, danke.
Gruß
Holger
P.S.: Hier noch das List des Moduls:
Internals:
CFGFN ./FHEM/PhotoVoltaik.cfg
FUUID 6640c425-f33f-ad58-0268-ab18ae2789bc32b2
FVERSION 76_SolarForecast.pm:v1.45.0-s29607/2025-02-01
LCACHEFILE last write time: 16:28:01 whole Operating Memory
MODE Automatic / Event-controlled - next planned Cycletime: 16:32:14
MODEL OpenMeteoDWDAPI
NAME MyPVForecast
NOTIFYDEV tasmota_Smartmeter,MQTT2_ShellyPlug06,SH10rt
NR 277
NTFY_ORDER 50-MyPVForecast
STATE 1844 W
TYPE SolarForecast
WEATHERMODEL DWD
eventCount 2301
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV MyPVForecast
SPGROOM
VERSION 1.45.0
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 768
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:13668
telnet telnetPort_127.0.0.1_36092
terminated 1
timeout 30
abortArg:
arg:
block 1
name MyPVForecast
OLDREADINGS:
READINGS:
2025-02-02 16:31:24 Battery_ChargeRecommended_01 1
2025-02-02 16:31:24 Battery_ChargeRequest_01 0
2025-02-02 16:31:24 Battery_OptimumTargetSoC_01 10 %
2025-02-02 16:31:24 Current_AutarkyRate 100 %
2025-02-02 16:31:24 Current_BatCharge_01 100 %
2025-02-02 16:31:24 Current_Consumption 634 W
2025-02-02 16:31:24 Current_GridConsumption 0 W
2025-02-02 16:31:24 Current_GridFeedIn 1216 W
2025-02-02 16:31:24 Current_PV 1844 W
2025-02-02 16:31:24 Current_PowerBatIn_01 0 W
2025-02-02 16:31:24 Current_PowerBatOut_01 6 W
2025-02-02 16:31:24 Current_SelfConsumption 628 W
2025-02-02 16:31:24 Current_SelfConsumptionRate 34 %
2025-02-02 16:31:24 Current_Surplus 1210 W
2025-02-02 16:00:00 LastHourGridconsumptionReal 0 Wh
2025-02-02 16:00:00 LastHourPVforecast 3958 Wh
2025-02-02 16:00:00 LastHourPVreal 900 Wh
2025-02-02 16:31:24 NextHours_Sum01_PVforecast 472 Wh
2025-02-02 16:31:24 NextHours_Sum02_PVforecast 500 Wh
2025-02-02 16:31:24 NextHours_Sum03_PVforecast 500 Wh
2025-02-02 16:31:24 NextHours_Sum04_ConsumptionForecast 397 Wh
2025-02-02 16:31:24 NextHours_Sum04_PVforecast 500 Wh
2025-02-02 16:31:24 RestOfDayConsumptionForecast 401 Wh
2025-02-02 16:31:24 RestOfDayPVforecast 500 Wh
2025-02-02 00:59:55 Today_Hour01_BatIn_01 0 Wh
2025-02-02 00:59:55 Today_Hour01_BatOut_01 1000 Wh
2025-02-02 00:59:55 Today_Hour01_GridConsumption 1 Wh
2025-02-02 00:59:55 Today_Hour01_GridFeedIn 0 Wh
2025-02-02 00:59:55 Today_Hour01_PVreal 0 Wh
2025-02-02 01:59:55 Today_Hour02_BatIn_01 0 Wh
2025-02-02 01:59:55 Today_Hour02_BatOut_01 500 Wh
2025-02-02 01:59:55 Today_Hour02_GridConsumption 0 Wh
2025-02-02 01:59:55 Today_Hour02_GridFeedIn 0 Wh
2025-02-02 01:59:55 Today_Hour02_PVreal 0 Wh
2025-02-02 02:59:55 Today_Hour03_BatIn_01 0 Wh
2025-02-02 02:59:55 Today_Hour03_BatOut_01 500 Wh
2025-02-02 02:59:55 Today_Hour03_GridConsumption 0 Wh
2025-02-02 02:59:55 Today_Hour03_GridFeedIn 0 Wh
2025-02-02 02:59:55 Today_Hour03_PVreal 0 Wh
2025-02-02 03:59:55 Today_Hour04_BatIn_01 0 Wh
2025-02-02 03:59:55 Today_Hour04_BatOut_01 600 Wh
2025-02-02 03:59:55 Today_Hour04_GridConsumption 0 Wh
2025-02-02 03:59:55 Today_Hour04_GridFeedIn 0 Wh
2025-02-02 03:59:55 Today_Hour04_PVreal 0 Wh
2025-02-02 04:59:55 Today_Hour05_BatIn_01 0 Wh
2025-02-02 04:59:55 Today_Hour05_BatOut_01 400 Wh
2025-02-02 04:59:55 Today_Hour05_GridConsumption 0 Wh
2025-02-02 04:59:55 Today_Hour05_GridFeedIn 0 Wh
2025-02-02 04:59:55 Today_Hour05_PVreal 0 Wh
2025-02-02 05:59:55 Today_Hour06_BatIn_01 0 Wh
2025-02-02 05:59:55 Today_Hour06_BatOut_01 600 Wh
2025-02-02 05:59:55 Today_Hour06_GridConsumption 0 Wh
2025-02-02 05:59:55 Today_Hour06_GridFeedIn 0 Wh
2025-02-02 05:59:55 Today_Hour06_PVreal 0 Wh
2025-02-02 06:59:55 Today_Hour07_BatIn_01 0 Wh
2025-02-02 06:59:55 Today_Hour07_BatOut_01 200 Wh
2025-02-02 06:59:55 Today_Hour07_GridConsumption 0 Wh
2025-02-02 06:59:55 Today_Hour07_GridFeedIn 0 Wh
2025-02-02 06:59:55 Today_Hour07_PVreal 0 Wh
2025-02-02 07:59:55 Today_Hour08_BatIn_01 0 Wh
2025-02-02 07:59:55 Today_Hour08_BatOut_01 0 Wh
2025-02-02 07:59:55 Today_Hour08_GridConsumption 1 Wh
2025-02-02 07:59:55 Today_Hour08_GridFeedIn 0 Wh
2025-02-02 07:59:55 Today_Hour08_PVreal 0 Wh
2025-02-02 08:59:55 Today_Hour09_BatIn_01 0 Wh
2025-02-02 08:59:55 Today_Hour09_BatOut_01 0 Wh
2025-02-02 08:59:55 Today_Hour09_GridConsumption 0 Wh
2025-02-02 08:59:55 Today_Hour09_GridFeedIn 0 Wh
2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh
2025-02-02 09:59:55 Today_Hour10_BatIn_01 300 Wh
2025-02-02 09:59:55 Today_Hour10_BatOut_01 0 Wh
2025-02-02 09:59:55 Today_Hour10_GridConsumption 0 Wh
2025-02-02 09:59:55 Today_Hour10_GridFeedIn 0 Wh
2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh
2025-02-02 10:59:55 Today_Hour11_BatIn_01 1900 Wh
2025-02-02 10:59:55 Today_Hour11_BatOut_01 0 Wh
2025-02-02 10:59:55 Today_Hour11_GridConsumption 0 Wh
2025-02-02 10:59:55 Today_Hour11_GridFeedIn 0 Wh
2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh
2025-02-02 11:59:55 Today_Hour12_BatIn_01 2900 Wh
2025-02-02 11:59:55 Today_Hour12_BatOut_01 200 Wh
2025-02-02 11:59:55 Today_Hour12_GridConsumption 1 Wh
2025-02-02 11:59:55 Today_Hour12_GridFeedIn 0 Wh
2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh
2025-02-02 12:59:54 Today_Hour13_BatIn_01 3900 Wh
2025-02-02 12:59:54 Today_Hour13_BatOut_01 0 Wh
2025-02-02 12:59:54 Today_Hour13_GridConsumption 0 Wh
2025-02-02 12:59:54 Today_Hour13_GridFeedIn 0 Wh
2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh
2025-02-02 13:59:54 Today_Hour14_BatIn_01 100 Wh
2025-02-02 13:59:54 Today_Hour14_BatOut_01 0 Wh
2025-02-02 13:59:54 Today_Hour14_GridConsumption 0 Wh
2025-02-02 13:59:54 Today_Hour14_GridFeedIn 3 Wh
2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh
2025-02-02 14:59:54 Today_Hour15_BatIn_01 0 Wh
2025-02-02 14:59:54 Today_Hour15_BatOut_01 0 Wh
2025-02-02 14:59:54 Today_Hour15_GridConsumption 0 Wh
2025-02-02 14:59:54 Today_Hour15_GridFeedIn 3 Wh
2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh
2025-02-02 15:59:54 Today_Hour16_BatIn_01 300 Wh
2025-02-02 15:59:54 Today_Hour16_BatOut_01 300 Wh
2025-02-02 15:59:54 Today_Hour16_GridConsumption 0 Wh
2025-02-02 15:59:54 Today_Hour16_GridFeedIn 1 Wh
2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh
2025-02-02 16:31:24 Today_Hour17_BatIn_01 100 Wh
2025-02-02 16:31:24 Today_Hour17_BatOut_01 0 Wh
2025-02-02 16:31:24 Today_Hour17_GridConsumption 0 Wh
2025-02-02 16:31:24 Today_Hour17_GridFeedIn 0 Wh
2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh
2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
2025-02-02 16:31:24 Today_MaxPVforecast 6415 Wh
2025-02-02 16:31:24 Today_MaxPVforecastTime 2025-02-02 13:00:00
2025-02-02 16:31:24 Today_PVforecast 29450 Wh
2025-02-02 16:31:24 Today_PVreal 7600 Wh
2025-02-02 16:31:24 Today_SunRise 08:06
2025-02-02 16:31:24 Today_SunSet 17:24
2025-02-02 16:31:24 Tomorrow_ConsumptionForecast 809 Wh
2025-02-02 16:31:24 Tomorrow_PVforecast 18246 Wh
2025-02-02 16:31:24 Tomorrow_SunRise 08:04
2025-02-02 16:31:24 Tomorrow_SunSet 17:26
2025-02-02 16:31:24 consumer01 name='MQTT2_ShellyPlug06' state='off' mode='can' planningstate='interrupted' remainLockTime='180'
2025-02-02 16:31:24 consumer01_currentPower 0 W
2025-02-02 16:31:24 consumer01_planned_start 02.02.2025 10:00:04
2025-02-02 16:31:24 consumer01_planned_stop 02.02.2025 17:24:00
2025-02-02 16:31:04 nextCycletime 16:32:14
2025-02-02 16:22:45 nextRadiationAPICall nach 02.02.2025 16:37:45
2025-02-02 13:00:04 pvCorrectionFactor_13 0.50 (automatic - old factor: 1.00, AI result used, Sun Alt range: 25, Cloud range: 20, Days in range: 1)
2025-02-02 14:00:04 pvCorrectionFactor_14 0.50 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 25, Days in range: 1)
2025-02-02 15:00:02 pvCorrectionFactor_15 0.48 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 15, Days in range: 1)
2025-02-02 16:00:04 pvCorrectionFactor_16 0.23 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 30, Days in range: 1)
2025-02-02 16:31:24 pvCorrectionFactor_Auto on_complex_ai
2024-09-27 13:55:33 setupStringAzimuth Hauptdach=20 Flachdach=20
2024-09-27 13:55:47 setupStringDeclination Hauptdach=30 Flachdach=15
2025-02-02 16:31:25 state updated
Attributes:
DbLogExclude .*
affectConsForecastIdentWeekdays 0
affectConsForecastInPlanning 0
comment update per "wget -qO /opt/fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
consumer01 MQTT2_ShellyPlug06 /
type=other power=260 /
switchdev=MQTT2_ShellyPlug06 /
mode=can /
icon=Ventilator_fett /
mintime=SunPath /
on=on /
off=off /
interruptable=1 /
notbefore=10:00 /
notafter=20 /
auto=1 /
locktime=600:600 /
pcurr=relay_0_power:W:30 /
#etotal=relay_0_energy_Wh:Wh
consumerLegend icon_top
consumerLink 1
ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=98 careCycle=20
ctrlInterval 70
disable 0
event-on-change-reading .*
graphicHistoryHour 10
graphicHourCount 24
graphicLayoutType double
graphicShowDiff top
group Energy Meter
room PV
setupBatteryDev01 SH10rt pin=Battery_power_charge:W /
pout=Battery_power_discharge:W /
intotal=Total_battery_charge_energy_from_PV:kWh /
outtotal=Total_battery_discharge_energy:kWh /
cap=9600 /
charge=Battery_Level
setupInverterDev01 SH10rt /
pv=Total_DC_Power:W /
etotal=Total_Export_Energy_from_PV:kWh /
capacity=10000 /
strings=Hauptdach,Flachdach
setupInverterStrings Hauptdach,Flachdach
setupMeterDev tasmota_Smartmeter /
gcon=M60_Power:W /
contotal=M60_E_in:Wh /
gfeedin=-gcon /
feedtotal=M60_E_out:Wh /
conprice=0.35:€ /
feedprice=0.079398:€ /
asynchron=1
setupRadiationAPI OpenMeteoDWD-API
setupStringPeak Hauptdach=6.1 Flachdach=6.1
setupWeatherDev1 DWD
stateFormat Current_PV
verbose 2
Hallo Christoph,
so 100%ig nachvollziehen kann ich deinen Issue nicht, kommt bei mir nicht vor und "dürfte" auch nicht vorkommen.
Wie dem auch sei, ich habe die Stelle etwas umgebaut und in mein contrib geladen.
Zieh sie dir bitte, führe ein FHEM Restart durch und berichte ob die Warnungen weg sind.
Hallo Holger,
ich habe aus den Readings hier die für den Fall wesentlichen Teile herausgezogen:
Zitat2025-02-02 08:59:55 Today_Hour09_PVforecast 152 Wh
2025-02-02 08:59:55 Today_Hour09_PVreal 0 Wh
2025-02-02 09:59:55 Today_Hour10_PVforecast 1400 Wh
2025-02-02 09:59:55 Today_Hour10_PVreal 0 Wh
2025-02-02 10:59:55 Today_Hour11_PVforecast 2500 Wh
2025-02-02 10:59:55 Today_Hour11_PVreal 0 Wh
2025-02-02 11:59:55 Today_Hour12_PVforecast 4392 Wh
2025-02-02 11:59:55 Today_Hour12_PVreal 0 Wh
2025-02-02 12:59:54 Today_Hour13_PVforecast 4000 Wh
2025-02-02 12:59:54 Today_Hour13_PVreal 300 Wh
2025-02-02 13:59:54 Today_Hour14_PVforecast 6415 Wh
2025-02-02 13:59:54 Today_Hour14_PVreal 3200 Wh
2025-02-02 14:59:54 Today_Hour15_PVforecast 5629 Wh
2025-02-02 14:59:54 Today_Hour15_PVreal 2700 Wh
2025-02-02 15:59:54 Today_Hour16_PVforecast 3958 Wh
2025-02-02 15:59:54 Today_Hour16_PVreal 900 Wh
2025-02-02 16:31:24 Today_Hour17_PVforecast 945 Wh
2025-02-02 16:31:24 Today_Hour17_PVreal 500 Wh
2025-02-02 16:31:24 Today_Hour18_PVforecast 59 Wh
Man sieht dass bis 12:00 keine erzeugte Energie vom WR gemeldet wird. Deswegen wird in den Balken nichts dargestellt. Zuständig für die Lieferung ist das Reading im Schlüssel:
ZitatsetupInverterDev01 SH10rt pv=Total_DC_Power:W etotal=Total_Export_Energy_from_PV:kWh capacity=10000 strings=Hauptdach,Flachdach
Welche Änderungen es zwischen den Stunden gab, sieht man mit "get ... pvHistory 02" (für heute).
Hier ein Beispiel für die Stunden 10 (9:00 - 9:59) und 11 (10:00 - 10:59).
Wichtig ist hier der Key etotali01 für den ersten Inverter. Die Differenz zwischen den Werten beider Stunden ist die in der Stunde erzeugte Energie (hier 380). Diese 380 Wh findest du auch im Key pvrl01 als PVReal für diese Stunde. Das Modul rechnet intern immer mit Wh, kWh werden vorher umgerechnet.
Zitat10 => pvfc: 365, pvrl: 530, pvrlvd: 1, rad1h: -
etotali01: 63364714, etotali02: 3044110, etotali03: -
pvrl01: 380, pvrl02: 150, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 574, con: 518, gcons: 22, conprice: 0.2958
gfeedin: 1, feedprice: 0.1269
DoN: 1, sunaz: 137, sunalt: 12
batintotal01: 4083720.6324986, batintotal02: -, batintotal03: -
batouttotal01: 3954638.32557054, batouttotal02: -, batouttotal03: -
batsoc01: 11, batsoc02: -, batsoc03: -
batin01: 80, batin02: -, batin03: -
batout01: 47, batout02: -, batout03: -
wid: 2, wcc: 80, rr1c: 0.00, pvcorrf: 0.94/0.94 temp: 0.40,
csmt01: 1050.57, csme01: 28.8499999999999, minutescsm01: 28
minutescsm02: 0
csmt03: 2423.95, csme03: 0, minutescsm03: 0
csmt04: 1743460.8, csme04: 101.40000000014, minutescsm04: 60
csmt05: 922.45, csme05: 0, minutescsm05: 0
csmt06: 1465.88, csme06: 3.45000000000005, minutescsm06: 22
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 42170, csme08: 10, minutescsm08: 60
csmt09: 152026.7, csme09: 0, minutescsm09: 0
minutescsm10: 0
11 => pvfc: 2966, pvrl: 1862, pvrlvd: 1, rad1h: -
etotali01: 63365094, etotali02: 3044260, etotali03: -
pvrl01: 1392, pvrl02: 470, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 774, con: 609, gcons: 25, conprice: 0.2958
gfeedin: 4, feedprice: 0.1269
DoN: 1, sunaz: 151, sunalt: 18
batintotal01: 4083802.08123336, batintotal02: -, batintotal03: -
batouttotal01: 3954686.11509513, batouttotal02: -, batouttotal03: -
batsoc01: 16, batsoc02: -, batsoc03: -
batin01: 1279, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
wid: 3, wcc: 80, rr1c: 0.00, pvcorrf: 0.98/0.98 temp: 1.40,
csmt01: 1076.42, csme01: 25.8500000000001, minutescsm01: 24
minutescsm02: 0
csmt03: 2423.95, csme03: 0, minutescsm03: 0
csmt04: 1743563.3, csme04: 102.5, minutescsm04: 60
csmt05: 922.45, csme05: 0, minutescsm05: 0
csmt06: 1475.48, csme06: 9.43000000000006, minutescsm06: 60
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 42170, csme08: 0, minutescsm08: 60
csmt09: 152043.3, csme09: 16.5999999999767, minutescsm09: 21
minutescsm10: 0
D.h. wenn du bei dir dort keine Differenzen findest, liegt es sehr wahrscheinlich am Input deines Readings
etotal=Total_Export_Energy_from_PV:kWhwelches sich in den ersten Stunden nicht ändert und danach auch nur wenig.
Du kannst mit dem Attr
ctrlDebug=collectDatadie Datensammlung verfolgen (keider viel Daten im Log). Du siehst was von deinem Inverter/Reading geliefert wird:
Zitat2025.02.02 19:10:10.558 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, delivery: default =>
2025.02.02 19:10:10.558 1: SolCast DEBUG> pv: 0 W, etotal: 63378810 Wh
Dieser Wert muß beständig hochzählen bei PV Erzeugung. Wenn nicht, das Reading mal checken was da mitgeteilt wird.
LG,
Heiko
Zitat von: DS_Starter am 02 Februar 2025, 18:52:22Hallo Christoph,
so 100%ig nachvollziehen kann ich deinen Issue nicht, kommt bei mir nicht vor und "dürfte" auch nicht vorkommen.
Wie dem auch sei, ich habe die Stelle etwas umgebaut und in mein contrib geladen.
Zieh sie dir bitte, führe ein FHEM Restart durch und berichte ob die Warnungen weg sind.
Moin,
muß dich leider entäuschen - der Fehler kommt etwa in Minute 5 nach dem Neustart ...
2025.02.02 20:40:42.357 3: CUL_HM set wz_Wohnzimmer_Heizung_Climate statusRequest noArg
2025.02.02 20:43:43.764 1: PERL WARNING: Argument "20:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.764 1: PERL WARNING: Argument "21:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.764 1: PERL WARNING: Argument "06:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.765 1: PERL WARNING: Argument "07:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.765 1: PERL WARNING: Argument "08:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.765 1: PERL WARNING: Argument "09:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.765 1: PERL WARNING: Argument "10:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.765 1: PERL WARNING: Argument "11:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.765 1: PERL WARNING: Argument "12:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.765 1: PERL WARNING: Argument "13:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.766 1: PERL WARNING: Argument "14:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.766 1: PERL WARNING: Argument "15:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.766 1: PERL WARNING: Argument "22:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.766 1: PERL WARNING: Argument "16:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.766 1: PERL WARNING: Argument "17:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.766 1: PERL WARNING: Argument "18:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.766 1: PERL WARNING: Argument "19:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.767 1: PERL WARNING: Argument "23:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.767 1: PERL WARNING: Argument "00:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.767 1: PERL WARNING: Argument "01:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.767 1: PERL WARNING: Argument "02:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.767 1: PERL WARNING: Argument "03:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.767 1: PERL WARNING: Argument "04:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.
2025.02.02 20:43:43.768 1: PERL WARNING: Argument "05:00" isn't numeric in addition (+) at ./FHEM/76_SolarForecast.pm line 15239.Gruß Christoph
Danke für die Info. Ich habe noch eine Idee ...
Kommt gleich.
Ich vermute jetzt du hast das Attr graphicHourStyle=:00 gesetzt?
Du vermutest richtig ...
So, jetzt nochmal aus dem contrib testen bitte.
Edit: war nur die halbe Wahrheit. Habe soeben nochmal im contrib upgedated.
Jetzt sieht es gut aus ... ich werde noch einmal ein Auge drauf halten ...
Danke für die Tests. Habe noch etwas geprüft. Passt in meinen Augen und ich checke den Fix ein. Ist dann morgen früh im Update.
LG
Hallo Heiko,
extrem cool 8) wie ausführlich du mir geantwortet hast (https://forum.fhem.de/index.php?msg=1332712), da gibt's was in die Kaffeekasse.
Tatsächlich hatte ich ein Reading benutzt, das ungeeignet war: Statt "Total_PV_Generation" hatte ich "Total_export_energy_from_PV" genutzt, dort wird aber immer die in die Batterie gespeicherte Energie (von der gesamt erzeugten) abgezogen. Daher war auch vormittags alles 0, da wurde die Batterie geladen ...
Deine Ausführungen haben mich dann schnell auf die richtige Fährte gebracht, nochmals danke.
Holger
Zitat von: Shadow3561 am 02 Februar 2025, 08:27:59Zitatdir fehlt im Attr setupBatteryDevXX sicherlich der Schlüssel cap.
Das habe ich bei mir bereits drin.
Aber nach genauem durchsehen ist mir aufgefallen, dass es jetzt ohne Angabe der Einheit sein muss
Vorher
cap=8000:Wh
Jetzt
cap=8000Dann wird der SOC wieder angezeigt.
@DS_Starter
Danke für den Wink mit dem Zaunpfahl
Hallo ihr beiden lieben,
genau das war es, ich hatte CAP drin, aber mit Einheit, nach dem Löschen der Einheit ist es wieder da :-)
Danke euch
Grüße
Christian
Hallo,
will sich denn keiner zu meinem Post #1847 äußern?
Oder ist meine Frage so doof das man sie ignorieren muss? ::)
Zitat von: Skusi am 03 Februar 2025, 16:47:43Hallo,
will sich denn keiner zu meinem Post #1847 äußern?
Oder ist meine Frage so doof das man sie ignorieren muss? ::)
Bei Dir :
cap=1600:Wh :o
Das verwirrt immer wieder mal O:-) jemanden
@DS_Starter: =>> eventuell ein Zusatz hinzu damit eindeutiger wird ?
cap installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)
NUR dann wenn ein Reading genutzt wird =>>> dann mit Einheit
Ansonsten immer ohne Einheit !
Trag mal nur dies ein (ohne Wh):
cap=1600 ;)
@Skusi,
ich hatte doch schon in #1854 geantwortet. :o
@300P,
Zitat@DS_Starter: =>> eventuell ein Zusatz hinzu damit eindeutiger wird ?
Kann ich machen.
Moin,
@300P
Zitat von: 300P am 03 Februar 2025, 19:57:23Trag mal nur dies ein (ohne Wh):
cap=1600 ;)
Danke für den Tipp, das hatte ich auch anders interpretiert. War das schon immer so, oder wurde das geändert ?
@DS_Starter
Zitat von: DS_Starter am 03 Februar 2025, 20:27:04ich hatte doch schon in #1854 geantwortet. :o
Ohh, entschuldige. Ich habe nur den Anfang des Posts überflogen und nichts zu meinem Problem entdeckt. :o
Zitat von: Skusi am 30 Januar 2025, 11:46:40Da die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.
Zitat von: DS_Starter am 30 Januar 2025, 19:11:38Das ist ein nicht so glückliches Setup. Abgesehen davon dass ich nicht verstehe wieso per DTU auch in der Nacht eine PV Leistung übermittelt wird, ist es problematisch wenn die erzeugte WR Leistung nicht in den setupInverterDevXX - Readings ankommt. Nur dort wird die PV-Leistung auch als solche gewertet.
Im BatteryDev01 gemeldete Leistungen können im Fall des BatIn auch eine Beladung aus dem Netz sein.
Hier müsstest du schauen, ob du mittels userReadings ein genaueres Input dem Modul bereitstellen kannst.
Die Leistung in der Nacht kommt dann aus dem WR der an dem Solix Akku hängt. Wenn der Akku entladen wird geht das ja über den WR ins Haus. Die DTU bewertet das dann als Solar Leistung.
Im Sommer wird der Akku über die beiden "Akku" Zellen beladen. Der WR meldet dann 0 Wh. Wenn der Akku voll ist, geht die Leistung der Zellen für den Rest des Tages über den WR ins Haus. Da der Zeitpunkt wann der Akku in den Bypass schaltet von der Einstrahlung abhängt, kann das Modul natürlich schwer damit rechnen.
Für meinen Fall müsste man im setupInverterDev hinterlegen können das die ersten 1600 Wh des Tages ignoriert werden. Das ist aber noch nicht alles... Da muss man noch weiter denken. Ich glaube das ist zufiel der Wünsche für mein spezielles Setup. Ich habe im Moment auch keine Idee wie ich das per userReading oder Dummy vorbereitend für das Modul umsetzen kann.
Ich denke es ist dann erstmal besser für die Prognose Genauigkeit wenn ich die beiden Zellen die den Akku Laden und den Akku selbst aus dem Modul entferne. Dann habe zwar eine Prognose die die Leistung bei Akku Bypass Betrieb ignoriert, aber eine andere Lösung fällt mir gerade nicht ein.
hier stand Müll
Zitat von: Skusi am 04 Februar 2025, 15:28:53Moin,
@300P
Zitat von: 300P am 03 Februar 2025, 19:57:23Trag mal nur dies ein (ohne Wh):
cap=1600 ;)
Danke für den Tipp, das hatte ich auch anders interpretiert. War das schon immer so, oder wurde das geändert ?
Ja - war schon lange so (als Option) =>> nur das mit dem <Reading:Einheit> kam dann später mal hinzu.
PS:
Versuche es erst einmal einen Tag mit dem "richtigen" BatterieSetup.
>- vielleicht wird es ja wenn dies "richtig passt".
Zitat von: Skusi am 30 Januar 2025, 11:46:40Hallo zusammen, super hier mitzulesen wie dieses geniale Modul immer intelligenter wird.
Allerdings wird es auch zunehmend komplizierter zu verstehen wie man es richtig mit Infos füttert. Ich benutze das Modul schon ca 3-4 Jahre und meine Anlage hat sich in der Zeit auch etwas erweitert. Nun beobachte ich die Prognosen und bin nicht zufrieden mit der Genauigkeit. Einerseits liegt es sicher an den Wettervorhersagen des DWD die selten der der Realität entsprechen, andererseits mach ich mir Gedanken über die Richtigkeit der Einbindung meiner etwas speziellen Anlage.
Aufbau:
6x Microwechselrichter 320 Wp (1 Panel) als Feld auf Dach Süd Ausrichtung
1x Microwechselrichter 600 Wp (2 Panel) auf Schuppendach Süd Ausrichtung an Solix Akku 1600 Wh
Das 6er Feld heißt im Modul "Dach" und das auf dem Schuppen "Akku"
Der 600 Wp Wechselrichter speist am Tage ausschließlich den Solix Akku bis er voll ist und leitet danach alles am Akku vorbei ins Hausnetz. Ab 21:00 entlade ich dann den Akku mit konstant 180 Wh bis er lehr ist.
Die Daten aller Wechselrichter werden über eine DTU eingesammelt und in Fhem bereitgestellt. Der Solix Akku ist auch als Device per MQTT eingebunden und stellt die benötigten Daten bereit.
Definiert habe ich das derzeit im Modul so:(zusammen kopiert)
attr SolarForcast setupBatteryDev01 Solarbank pin=solarbank_info_total_charging_power:W pout=solarbank_info_total_output_power:W intotal=statistics_1_total:kWh outtotal=statistics_2_total:kWh cap=1600:Wh charge=solarbank_info_solarbank_list_1_battery_power
attr SolarForcast setupInverterDev01 OpenDTU pv=Total_power:Wh etotal=Total_yieldtotal:kWh capacity=2400
attr SolarForcast setupInverterStrings Dach,Akku
attr SolarForcast setupStringPeak Dach=1.92 Akku=0.76
setstate SolarForcast 2024-07-01 18:40:45 setupStringAzimuth Dach=7 Akku=7
setstate SolarForcast 2024-07-01 18:40:45 setupStringDeclination Dach=20 Akku=10
Da die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.
Meine Frage nun: Ist das so in Ordnung, oder kann das Modul das so durcheinander bringen das die real Daten so von der Prognose abweichen.
Macht es Sinn den 600er Wechselerichter von dem InverterDev01 abzukoppeln und über ein Dummy ein InverterDev02 davon zu machen ?
Ich bin etwas Ratlos wie die Daten einer solchen Konstellation im Modul verarbeitet werden und ob es so zu Fehler in den Berechnungen kommt.
Wie wäre es damit:
Bau dir mal einen DummyWR (s.u.) und nutze dessen "neuen" Readings in einer SF-Testumgebung die zu 99 % gleich eingerichtet ist - ABER ->> bis auf diese "neuen" Angaben im Setup für den Wechselrichter:
attr SolarForcast setupInverterDev01 InverterDummy pv=total_pac:W etotal=etotal:kWh capacity=2400
defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f W Today_PVforecast %9.3f kWh Today_PV %9.3f kWh Total_PV %9.3f kWh",\
(ReadingsVal($name,"total_pac",0)/1),\
(ReadingsNum("Forecast","Today_PVforecast",0)/1000),\
(ReadingsVal($name,"etoday",0)/1),\
(ReadingsVal($name,"etotal",0)/1),)}
attr InverterDummy userReadings etoday { ReadingsVal("OpenDTU","etoday_Wert_soweit_vefuegbar",0)/1;; }, \
etotal { ReadingsVal("OpenDTU","Total_yieldtotal",0)/1;; }, \
total_pac { ((ReadingsVal("OpenDTU","Total_power",0)/1) + (ReadingsVal("Solarbank","solarbank_info_total_charging_power",0)/1) - (ReadingsVal("Solarbank","solarbank_info_total_output_power",0)/1));; }
attr InverterDummy verbose 2 Erläuterung : PV-WR-Leistung = Summe aus WR +(Batteriebeladewert Akku) - (Batterieentladewert Akku) (#->> Werteangabe aber alle positiv !!!)
Damit sollte tagsüber der "richtige" Wert der PV-Erzeugung in der Grafik gezeigt werden.
Nachts wird/müsste dann "0" PV-Erzeugung gezeigt, denn entstehende Minuswerte durch den Akku werden in SF (soweit ich es kenne) abgefangen und "genullt".
Dein Akku würde dir aber die Werte vom Laden und Entladen ebenfalls anzeigen sollen.
ABER - keine Garantie dafür O:-)
Gruß
300P
Nachsatz / Kopierfehler:
In der vorherigenDefinition war ein Kopierfehler - sorry ist korrigiert worden.
Du musst aber auch noch in einem 2.ten Schritt dann den InverterDummy noch weiter anpassen =>> damit die PV-Leistung und deren Berechnung auch passt
Dazu musst du zusätzlich den fortlaufenden Summenzähler vom Akku (Beladung Akku) noch im Dummy zum fortlaufenden Erzeugungszähler des DTU addieren um deine "gesamte erzeugte PV-Energiemenge" zu erhalten. (Einheiten bitte beachten bei der Berechnung)
Also nochmals das Userreading anpassen:
attr InverterDummy userReadings etoday { ReadingsVal("OpenDTU","etoday_Wert_soweit_vefuegbar",0)/1;; }, \
etotal { ((ReadingsVal("OpenDTU","Total_yieldtotal",0)/1) +((ReadingsVal("Solarbank","statistics_1_total",0)/1);; }, \
total_pac { ((ReadingsVal("OpenDTU","Total_power",0)/1) + (ReadingsVal("Solarbank","solarbank_info_total_charging_power",0)/1) - (ReadingsVal("Solarbank","solarbank_info_total_output_power",0)/1));; }
Ich würde die "total"-Werte auch oder nur als monotonic ausführen um beim wechseln der Geräte den Wert nicht nocheinmal manipulieren/angleichen zu müssen.
etotaltot:etotal:.* monotonic { ReadingsNum($name,"etotal",0.0) }
total_pactot:total_pac:.* monotonic { ReadingsNum($name,"total_pac",0.0) }
Ich habe die letzten Tage einige Bereinigungen und kleinere Bugfixes vorgenommen.
Die V 1.45.2 ist morgen früh im Update und auch jetzt bereits in meinem contrib verfügbar.
Grüße,
Heiko
@ 300P
Vielen Dank für dein Gehirnschmalz.
Ich hab den Dumm mal angelegt und beobachte die Readings.
Parallel habe ich mir die verfügbaren Readings meiner beteiligten Devices und die Definition von SolarForcast nochmal genauer angesehen und die Attribute folgendermaßen angepasst:
setupInverterDev01
OpenDTU pv=Sued_1-6_power:Wh etotal=Sued_1-6_yieldtotal:kWh capacity=1800 strings=Dach
Ich habe im OpenDTU neue userReadings nur für die Zellen die direkt ins Haus gehen, also ohne Akku Anbindung angelegt (Sued_1-6)
setupInverterDev02
Solarbank pv=solarbank_info_total_photovoltaic_power:Wh etotal=statistics_1_total:kWh capacity=600 strings=Akku feed=bat
Der 2. Inverter bekommt nun readings aus dem Akku Device. pv= reine Leistung der Zellen, egal ob die in den Akku fließt oder später wenn Akku voll ins Haus. etotal= aufsteigender Zähler der abgegebenen Leistung des Akkus. Nachts beim Endladen und tags wenn Bypass aktiv. Ich hoffe durch die Angabe strings=Akku feed=bat das das Modul die Daten richtig verarbeitet.
setupBatteryDev01
Solarbank pin=solarbank_info_total_charging_power:W pout=solarbank_info_total_output_power:W outtotal=statistics_1_total:kWh cap=1600 charge=solarbank_info_solarbank_list_1_battery_power
Unverändert nur cap ohne Einheit
Ich beobachte die vom Modul angezeigten Momentan Werte. Diese sind Tagsüber plausibel. Mal sehen was heute Abend bei Entladung des Akkus passiert.
Eine Frage noch zu
setupStringPeak Dach=1.92 Akku=0.76
Welche Leistung ist hier gefordert. Tatsächlich die max Leistung der Panels bei 100% Einstrahlung, oder die Maximal Leistung die die Microwechselrichter abgeben können
Zitat von: DS_Starter am 05 Februar 2025, 21:33:38Ich habe die letzten Tage einige Bereinigungen und kleinere Bugfixes vorgenommen.
Die V 1.45.2 ist morgen früh im Update und auch jetzt bereits in meinem contrib verfügbar.
Grüße,
Heiko
Könnte es sein das die Logik für den Interval mit dieser Version nicht zu 100 % funktioniert ??
Die Anzeigegrafik verändert sich bei mir nicht mehr bzw. kein Update der Webseite mehr ?
Gruß
300P
Nahsatz:
Hab grad leider erst bemerkt:
Es hakt bei der Aktualisierung nur dann wenn man direkt auf dem SF-Modul als "zum Anzeigen" steht.
Wenn es "normal" irgendwo in FHEM eingebunden ist funktioniert es auch normal.
Zitat von: Skusi am 06 Februar 2025, 10:52:17....Ich beobachte die vom Modul angezeigten Momentan Werte. Diese sind Tagsüber plausibel. Mal sehen was heute Abend bei Entladung des Akkus passiert.
Eine Frage noch zu
setupStringPeak Dach=1.92 Akku=0.76
Welche Leistung ist hier gefordert. Tatsächlich die max Leistung der Panels bei 100% Einstrahlung, oder die Maximal Leistung die die Microwechselrichter abgeben können
Siehe auch in den Erläuterungen zum Attribut:
setupStringPeak <Stringname1>=<Peak> [<Stringname2>=<Peak> <Stringname3>=<Peak> ...]
Die DC Peakleistung des Strings "StringnameX" in kWp. Der Stringname ist ein Schlüsselwert des Attributs setupInverterStrings.
Bei Verwendung einer KI basierenden API (z.B. Model VictronKiAPI) sind die Peakleistungen aller vorhandenen Strings als Summe dem Stringnamen KI-based zuzuordnen.
Beispiele:
attr <name> setupStringPeak Ostdach=5.1 Südgarage=2.0 S3=7.2
attr <name> setupStringPeak KI-based=14.3 (bei KI basierender API)
Gruß
300P
ZitatEs hakt bei der Aktualisierung nur dann wenn man direkt auf dem SF-Modul als "zum Anzeigen" steht.
Wenn es "normal" irgendwo in FHEM eingebunden ist funktioniert es auch normal.
Ich weiß nicht, ob das jetzt eine Frage ist.
In der Detailansicht ("zum Anzeigen") erfolgt keine automatische Aktualisierung. In der Raumansicht (also "normal") arbeitet die automat. Aktualisierung.
So ist es.
Wenn es schon immer so war.....sollte es auch weiter so bleiben.
Ich hatte diesen Unterschied bislang irgendwie wohl nie bemerkt / mitbekommen. Nur heute Morgen als ich telefonierte hab ich es ,,urplötzlich gesehen" O:-)
Gruß
300P
Bei mir ist die Verbrauchsvorhersage für den nächsten Tag immer sehr hoch.
Ist es bei euch auch so?
Moin,
nein die ist völlig ok.
Im Wiki habe ich einen Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_kann_eine_fehlerhafte_Verbrauchsprognose_korrigiert_werden?) zur Analyse und Korrektur geschrieben.
Vllt. hilft dir das schon weiter.
Guten Morgen,
Rückfrage zur Berechnung des neuen special_Reading "Tagesverbrauch"
Bei mir sind von 00:00 Uhr bis ca. 10:00 Uhr ca. 7,0 kWh durch den Producer01 erzeugt worden.
Zusätzlich sind noch 0,5 kWh aus der PV erzeugt worden.
Als Gesamterzeugung hab ich also ca 7.5 kWh erzeugt
In die Batterien gingen heute nacht so ca. 0.2 kWh
Aus der Batterien hab ich 3.1 kWh wieder genutzt.
Wie wird das beim Modul berechnet bzw. wie wird dabei die Batterie irgendwo eingerechnet ?
....oder bin ich heute morgen auf "dem falschen Dampfer" mit meinen Gedanken?
Also 7.0 erzeugt (FCU)
+0.5 erzeugt (PV)
-0.2 in die Batterie.
+3.1 aus der Batterie.
+/-0.0 Einspeisung EVU
+/-0.0 Bezug EVU
=======================
10.4 Verbrauch (Fragezeichen)
Als Tagesverbrauch (neue Verbrauchsreading) wird mir 5180 W angezeigt -
(alle Werte zum gleichen Zeitpunkt gelesen)
Meine eigene Statistik sagt mir ca. 7.5 kWh Verbrauch.(ich lasse die Batterie aussen vor)
Oder klappt es erst am nächsten Tag nach dem Update wg. dem Reading und ich bin mal wieder zu schnell ?
Gruß
300P
als today-C
Hallo 300P,
ja die Berechnung erfolgt wie von dir beschrieben. Siehe auch den Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?) im Wiki.
Du kannst in der pvHistory für jede einzelne Stunde nachvollziehen welche Werte registriert wurden und im Schlüssel "con" gespeichert. In der Stunde 99 gibt es auch den Schlüssel "con", der die Summe der einzelnen Stunden speichert.
Du müsstest mal schauen ob dir etwas auffällt wo es Diskrepanzen gibt. Bei mir passt der Verbrauch errechnet durch das Modul und meiner bisherigen separaten Erhebung gemäß der Energiebilanz (https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung) die ich mal geschrieben hatte.
Allerdings habe ich keine Producer. Habe nochmal im Code gecheckt und konnte bisher auch keinen Fehler in der Berechnung entdecken.
Es gibt noch ein paar Nebenbedingungen, wenn z.B. die gemeldeten Werte negativ werden und hat dann Auswirkungen. Solche verletzenden Situationen würden mit verbose 3 im Log protokolliert.
LG,
Heiko
Irgendwie fehlt mir heute ein Icon.
Fhem ist aktuell.
Ich habe es hier angehängt. Liegt in www\images\openautomation.
Ich werde habe Wuppi bitten gebeten es zu den Icons hinzuzufügen.
Zitat von: DS_Starter am 08 Februar 2025, 14:24:11Hallo 300P,
ja die Berechnung erfolgt wie von dir beschrieben......
....Du müsstest mal schauen ob dir etwas auffällt wo es Diskrepanzen gibt......
....Allerdings habe ich keine Producer. Habe nochmal im Code gecheckt und konnte bisher auch keinen Fehler in der Berechnung entdecken.
LG,
Heiko
Hallo Heiko,
ja inzwischen habe ich etwas gefunden das eine Differenz von bis zu +/-1 kWh bei mir auslöst / auslösen wird.
Die Zählerdifferenzen meines Brutto-Erzeugungszähler des Producer01 (BHKW/FCU-Erzeugung) wird bei mir pro Monat mit 1 Nachkommastelle berechnet.
Der fortlaufende Brutto-Erzeugungszähler wird aber in der Steuerung nur mit
Zählerstand ohne jegliche Kommastelle geführt. ???
Ob und wann da irgendwie gerundet wird oder ob das nur beim Umspringen von 1 kWh Zählerstand erfolgt, ist jedoch nicht in den Unterlagen ergründbar :o
Wenn ich die beiden Batterien mit einbeziehe dann passt aber dein Berechnung so :)
PS:
Obwohl ich einen anderen Produktionszähler mit Modbus / 3 Kommastellen zusätzlich dort habe, verändere die Ermittlung aber da nicht mehr. Das Micro-BHKW wird nach jetzigem Stand so in 8-10 Wochen in den dauerhaften Ruhestand bzw. für noch XY Monate in dauerhafte Betriebsbereitschaft geschickt.
Gruß und Danke für's klären
300P
Eine Frage in die Runde ...
Es gibt das Attr consumerLegend mit verschiedenen Argumenten, unter anderem text_top und text_bottom.
Diese beiden Argumente blenden lediglich die Consumer Icons in dem Consumer-Paneel aus.
Ich würde diese beiden Argumente gern einkassieren. Gibt es aus eurer Sicht einen Grund, die Ausblendung der die Consumer Icons in dem Consumer-Paneel haben zu müssen?
Wenn es jemand nutzt, ist das auch kein Problem. Ansonsten nehme ich es mal weg bei Gelegenheit.
VG
Ich benutze sie nicht, also werde ich nichts vermissen.
ich nutze es auch nicht
Zitat von: DS_Starter am 10 Februar 2025, 00:33:37Gibt es aus eurer Sicht einen Grund, die Ausblendung der die Consumer Icons in dem Consumer-Paneel haben zu müssen?
Nein - Danke ;)
Hallo DS_Starter,
habe ich bisher nicht genutzt. Was hätte man damit steuern können?
Gruß
Bison
Zitathabe ich bisher nicht genutzt. Was hätte man damit steuern können?
Diese beiden Argumente blenden lediglich die Consumer Icons in dem Consumer-Paneel aus.
Ich denke die wird (fast?) niemand benutzen. Deswegen würde ich diese Argumente gerne entfernen. Ein bisschen Altlasten entsorgen.
LG
Vor dem Hintergrund, dass meine Verbrauchs- und SOC-Prognose nicht selten (aber nicht immer) ziemlich neben der Realität liegt, habe ich mir Gedanken über die Gründe gemacht.
Als einen Grund habe ich identifiziert, dass es einige Verbraucher gibt, die nur bei PV-Überschuss eingeschaltet werden. Kommt viel solare Leistung auf den PV-Modulen an, so werden die dann eingeschalteten Verbraucher bei der Verbrauchs- und SOC-Prognose berücksichtigt.
Kommt hingegen wetterbedingt wenig solare Leistung auf den PV-Modulen ab und es damit zu keinem oder wenig Überschuss (gegenüber einer kurzzeit-gemittelten Grundlast), dann werden die Verbraucher eben nicht eingeschaltet. Auf Basis zurückliegender Verbrauchswerte wird aber ggf. ein Verbrauch prognostiziert, der in den genannten Fällen dann neben der Verbrauchsprognose in Folge auch eine gute SOC-Prognose zunichte macht.
Eine Lösung des Problems könnte darin bestehen, dass man im Modul eine Möglichkeit schafft, einzelne Verbraucher (Überschuss-Verbraucher) aus der Prognose herauszunehmen. Wie seht Ihr das?
ZitatEine Lösung des Problems könnte darin bestehen, dass man im Modul eine Möglichkeit schafft, einzelne Verbraucher (Überschuss-Verbraucher) aus der Prognose herauszunehmen. Wie seht Ihr das?
Ja. Diese Möglichkeit ist bereits implementiert.
Dazu kann man den Schlüssel exconfc=1 in dem relevanten Verbraucher setzen. Der Verbraucher muss seine Verbrauchsdaten an das Modul übermitteln, d.h. entsprechende Readings anbieten damit die Werte gesammelt werden können.
Zitat von: DS_Starter am 11 Februar 2025, 08:26:43ZitatEine Lösung des Problems könnte darin bestehen, dass man im Modul eine Möglichkeit schafft, einzelne Verbraucher (Überschuss-Verbraucher) aus der Prognose herauszunehmen. Wie seht Ihr das?
Ja. Diese Möglichkeit ist bereits implementiert.
Dazu kann man den Schlüssel exconfc=1 in dem relevanten Verbraucher setzen. Der Verbraucher muss seine Verbrauchsdaten an das Modul übermitteln, d.h. entsprechende Readings anbieten damit die Werte gesammelt werden können.
Danke! Das hatte ich nicht auf dem Schirm!
Habe mir soeben neben dem Wiki auch mal die Online-Hilfe genauer angesehen. Nun verstehe ich den folgenden Satz in der Online-Hilfe
Zitat1 - der historische Energieverbrauch des Verbrauchers wird von der Verbrauchsprognose ausgeschlossen.
so, dass dieser Verbraucher überhaupt nicht bei der Prognose berücksichtigt wird. Das ist im Kurzzeitbereich (innerhalb eines Tages) aber wahrscheinlich nicht sinnvoll, da er ja die tatsächlich zur Verfügung stehende Leistung an diesem (!) Tag reduziert. Oder interpretiere ich die Aussage des obigen Satzes nur falsch? Darauf deutet jedenfalls die Formulierung "zukünftige Prognose" im Wiki hin, wenngleich Prognosen ja eigentlich immer in die Zukunft schauen, oder?
Edit: Nach meiner Vorstellung müsste man den charakteristischen Verbrauchsverlauf eines derartigen Verbrauchers (nur) an Tagen, an denen er eingeschaltet ist, vollumfänglich bei der aktuellen Tagesprognose berücksichtigen.
verstehe nicht ganz die Bedeutung von upSoC ...
upSoC
oberer Mindest-SoC, Der übliche Wert des optimalen SoC bewegt sich in Perioden mit hohem PV-Überschuss tendenziell zwischen 'lowSoC' und 'upSoC',
in Perioden mit geringer PV-Ausbeute bzw. geringem PV Energieüberschuss bewegt sich der optimale SoC tendenziell
zwischen 'upSoC' und 'maxSoC'. Die Einstellung von upSoC=50 für ein ausgewogenes Verhalten kann als guter Startwert dienen.
... vlt. auch deshalb, weil meine Batterie mit 7.7 kW relativ klein ist bei 11 kWp und der SoC im Sommer meist zwischen lowSoC und maxSoc schwankt bzw. im Winter zwischen lowSoc und 50% maxSoc ...
Zitatverstehe nicht ganz die Bedeutung von upSoC
Es ist ein Steuerungswert um z.B. in Zeiten mit wenig Energieerzeugung einen Füllgrad in den Batterien für einen Stromausfall als Reserve behalten. Die Batterie entlädt nicht unter upSoC wenn die Wahrscheinlichkeit nicht gegeben ist, dass sie morgen/übermorgen wieder hinreichend geladen werden kann.
ZitatHabe mir soeben neben dem Wiki auch mal die Online-Hilfe genauer angesehen. Nun verstehe ich den folgenden Satz in der Online-Hilfe
Zitat
1 - der historische Energieverbrauch des Verbrauchers wird von der Verbrauchsprognose ausgeschlossen.
so, dass dieser Verbraucher überhaupt nicht bei der Prognose berücksichtigt wird.
Das verstehst du richtig.
ZitatEdit: Nach meiner Vorstellung müsste man den charakteristischen Verbrauchsverlauf eines derartigen Verbrauchers (nur) an Tagen, an denen er eingeschaltet ist, vollumfänglich bei der aktuellen Tagesprognose berücksichtigen.
Dann brauchst du ihn nicht mit exconfc=1 auszuschließen.
Er wird in der Prognose berücksichtigt wenn sein Verbrauch in der Vergangenheit aufgezeichnet wurde.
Eine Hilfe könnte das Attr affectConsForecastIdentWeekdays sein.
Zitat von: DS_Starter am 11 Februar 2025, 09:38:30ZitatEdit: Nach meiner Vorstellung müsste man den charakteristischen Verbrauchsverlauf eines derartigen Verbrauchers (nur) an Tagen, an denen er eingeschaltet ist, vollumfänglich bei der aktuellen Tagesprognose berücksichtigen.
Dann brauchst du ihn nicht mit exconfc=1 auszuschließen.
Er wird in der Prognose berücksichtigt wenn sein Verbrauch in der Vergangenheit aufgezeichnet wurde.
Eine Hilfe könnte das Attr affectConsForecastIdentWeekdays sein.
Nun bin ich verwirrt, da ich Dich so verstanden habe, dass a) exconfc=1 für sporadisch eingeschaltete Verbraucher sinnvoll sei, die sonst die Verbrauchsprognose verschlechtern (können) und b) der charakteristischen Verbrauchsverlauf eines sporadisch eingeschalteten Verbrauchers bei der Tagesprognose (sinnvoll) berücksichtigt wird. Nun widersprechen sich a) und b) aber doch, oder etwas nicht?
Um es plastischer zu machen hier ein Beispiel: Überschussladen eines Elektroauto (habe ich leider noch nicht) unter der Annahme, dass pro Woche in etwa die gleiche Energie vom Wagen ,,verbraucht" wird und daher diese Energiemenge am Wochenende wieder ,,aufgefüllt" werden muss, was aber nur per Überschussladen erfolgen soll. Der Verbraucher wird sporadisch geladen, da nicht immer Überschuss zur Verfügung steht. Wenn dieser vorhanden ist, so wird solange geladen, bis das Fahrzeugakku voll ist. Wie wären in diesem Fall die globalen Attribute affectConsForecastLastDays und affectConsForecastIdentWeekdays sowie das verbraucherspezifische Attribut exconfc einzustellen, sodass die Verbrauchs- und SOC-Prognose möglichst gut wird?
ZitatWie wären in diesem Fall die globalen Attribute affectConsForecastLastDays und affectConsForecastIdentWeekdays sowie das verbraucherspezifische Attribut exconfc einzustellen, sodass die Verbrauchs- und SOC-Prognose möglichst gut wird?
Dann würde man nur affectConsForecastIdentWeekdays setzen. Dann würde die gesamte Historie verwendet.
Speziell bei solchen Großverbrauchern wie E-Auto müsste der historische Verbrauch stets herausgerechnet werden und andererseits um die prognostizierten Einschaltzeiten (und dementsprechende Energien) wieder aufzuschlagen. Gerade wenn es sich um Überschußladen handelt wo diverse Randbedingungen eingehen. Das wäre ein ToDo zur Verbesserung.
Zitat von: DS_Starter am 11 Februar 2025, 10:28:56ZitatWie wären in diesem Fall die globalen Attribute affectConsForecastLastDays und affectConsForecastIdentWeekdays sowie das verbraucherspezifische Attribut exconfc einzustellen, sodass die Verbrauchs- und SOC-Prognose möglichst gut wird?
Dann würde man nur affectConsForecastIdentWeekdays setzen. Dann würde die gesamte Historie verwendet.
Speziell bei solchen Großverbrauchern wie E-Auto müsste der historische Verbrauch stets herausgerechnet werden und andererseits um die prognostizierten Einschaltzeiten (und dementsprechende Energien) wieder aufzuschlagen. Gerade wenn es sich um Überschußladen handelt wo diverse Randbedingungen eingehen. Das wäre ein ToDo zur Verbesserung.
Danke für die Info!
Verstehe aber immer noch nicht, warum Du den "historischen Verlauf" solcher Verbraucher herausrechnen willst. Natürlich darf man den nicht grundsätzlich einrechnen. Wenn es aber um eine Tagesprognose geht und der Verbraucher eingeschaltet ist bzw. wird, könnte man doch sehr gut auf den "historischen Verlauf" für die Tagesprognose zurückgreifen, da daraus ja der charakteristische Verlauf bei den letzten Verbrauchsvorgängen sichtbar wird. Man müsste jedoch einen solchen Verbraucher taggen können, damit nicht nach den Standverfahren historische Verläufe täglich oder wochtagsweise übertragen werden. Könnte mir vorstellen, dass sich hierfür das Attribut exconfc vielleicht auf 2 gesetzt dienen könnte ;-)
Hallo,
nachdem ich nun meine Inverter und Akku Angaben im Modul auf die tatsächliche Anlagenkonfiguration angeglichen habe und die Current readings auch der Realität entsprechen, beobachte ich die Prognosen. Um keine falschen Korrekturen des Moduls die aus den ganzen Experimenten mit der config herrühren habe ich alle Historischen Daten gelöscht. Also reset pvCorrection cached und reset pvHistory.
Das Wetter Modul DWD liefert auch plausible Rad1h und Neff Werte.
Warum aber sind die prognostizierten Erträge PVforecast so abweichend von dem PVreal ?
Gestern hatte ich -83% Abweichung !
OK, das Modul muss nun natürlich erstmal Wochenlag wieder Abweichungsfaktoren Sammeln. Aber ich finde es komisch das nun von Anfang an die Abeichungen so hoch sind das es natürlich serh große Faktoren in die Datenbank schreibt.
Habe ich doch noc irgendwas falsch konfiguriret, sodass es nun zur Sammlung falscher Daten kommt. Oder muss ich einfach Geduld haben und das pendelt sich dann mit der Zeit schon ein ?
Kann es sein das die Strhlungswerte zu stark nerücksichtigt werden? Gab es da nicht mal ein attr für den Faktor? Oder ist die Ki schuld? Der Status steht bei mir oft auf gelb! Oder taugen die DWD Werte nix ?
Vielleicht kann nochmal jemand über meine def gucken...
define SolarForcast SolarForecast
attr SolarForcast affectConsForecastIdentWeekdays 0
attr SolarForcast affectConsForecastInPlanning 0
attr SolarForcast affectConsForecastLastDays 31
attr SolarForcast consumer01 Geschirrspueler icon=scene_dishwasher@orange type=dishwasher mode=must notbefore=07 notafter=18 power=2300 swstate=state:on:off on=on off=off auto=automatic etotal=energy:kWh:5 pcurr=power:W:5
attr SolarForcast consumer02 Waschmaschine icon=scene_washing_machine@orange mintime=150 notbefore=08 notafter=13 type=washingmachine mode=must power=2300 swstate=state:on:off on=on off=off auto=automatic etotal=energy:kWh:5 pcurr=power:W:5
attr SolarForcast consumerAdviceIcon times
attr SolarForcast consumerLegend icon_bottom
attr SolarForcast consumerLink 1
attr SolarForcast ctrlDebug none
attr SolarForcast ctrlSpecialReadings dayAfterTomorrowPVforecast
attr SolarForcast disable 0
attr SolarForcast event-on-change-reading .*
attr SolarForcast flowGraphicControl size=500 animate=1 consumerdist=130 showconsumerdummy=0
attr SolarForcast graphicBeam1Color 968A17
attr SolarForcast graphicBeam1Content pvForecast
attr SolarForcast graphicBeam1FontColor FFFDFC
attr SolarForcast graphicBeam2Color DCFF6B
attr SolarForcast graphicBeam2Content pvReal
attr SolarForcast graphicBeamHeightLevel1 200
attr SolarForcast graphicEnergyUnit Wh
attr SolarForcast graphicHistoryHour 12
attr SolarForcast graphicSelect forecast
attr SolarForcast group Strom
attr SolarForcast room 7.3_Solar
attr SolarForcast setupBatteryDev01 Solarbank pin=solarbank_info_total_charging_power:W pout=solarbank_info_total_output_power:W intotal=statistics_1_total:kWh outtotal=ges_battery_out:kWh cap=1600 charge=solarbank_info_solarbank_list_1_battery_power asynchron=1
attr SolarForcast setupInverterDev01 OpenDTU pv=Sued_1-6_power:Wh etotal=Sued_1-6_yieldtotal:kWh capacity=1800 strings=Dach
attr SolarForcast setupInverterDev02 Solarbank pv=solarbank_info_total_photovoltaic_power:Wh etotal=statistics_1_total:kWh capacity=600 strings=Akku feed=bat asynchron=1
attr SolarForcast setupInverterStrings Dach,Akku
attr SolarForcast setupMeterDev Stromzaehler gcon=SML_Watt_Bezug:Wh contotal=SML_Verbrauch_Summe:kWh gfeedin=SML_Watt_Einspeisung:Wh feedtotal=SML_Einspeisung_Summe:kWh
attr SolarForcast setupRadiationAPI DWD
attr SolarForcast setupStringPeak Dach=1.92 Akku=0.76
attr SolarForcast setupWeatherDev1 DWD
attr SolarForcast verbose 1
# FUUID 62dd77c5-f33f-98db-0df4-0793f62c2f52a26f
# FVERSION 76_SolarForecast.pm:v1.45.5-s29643/2025-02-09
# LCACHEFILE last write time: 21:19:02 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 21:19:52
# MODEL DWD
# NAME SolarForcast
# NOTIFYDEV Stromzaehler,Geschirrspueler,Waschmaschine,Solarbank,OpenDTU
# NR 731
# NTFY_ORDER 50-SolarForcast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 3693
# HELPER:
# 01M15DONE 1
# 02M15DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV SolarForcast
# SPGROOM
# VERSION 1.45.5
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 2294
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:2000054
# telnet telnetPort_127.0.0.1_47386
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name SolarForcast
# OLDREADINGS:
# READINGS:
# 2025-02-10 21:19:20 Battery_ChargeRecommended_01 1
# 2025-02-10 21:19:20 Current_AutarkyRate 19 %
# 2025-02-10 21:19:20 Current_BatCharge_01 80 %
# 2025-02-10 21:19:20 Current_Consumption 792 W
# 2025-02-10 21:19:20 Current_GridConsumption 638 W
# 2025-02-10 21:19:20 Current_GridFeedIn 0 W
# 2025-02-10 21:19:20 Current_PV 0 W
# 2025-02-10 21:19:20 Current_PowerBatIn_01 0 W
# 2025-02-10 21:19:20 Current_PowerBatOut_01 154 W
# 2025-02-10 21:19:20 Current_SelfConsumption 0 W
# 2025-02-10 21:19:20 Current_SelfConsumptionRate 0 %
# 2025-02-10 21:19:20 Current_Surplus 0 W
# 2025-02-10 21:00:00 LastHourGridconsumptionReal 737 Wh
# 2025-02-10 21:00:00 LastHourPVforecast 0 Wh
# 2025-02-10 21:00:00 LastHourPVreal 0 Wh
# 2025-02-10 21:19:20 NextHours_Sum01_PVforecast 0 Wh
# 2025-02-10 21:19:20 NextHours_Sum02_PVforecast 0 Wh
# 2025-02-10 21:19:20 NextHours_Sum03_PVforecast 0 Wh
# 2025-02-10 21:19:20 NextHours_Sum04_ConsumptionForecast 1579 Wh
# 2025-02-10 21:19:20 NextHours_Sum04_PVforecast 0 Wh
# 2025-02-10 21:19:20 RestOfDayConsumptionForecast 1231 Wh
# 2025-02-10 21:19:20 RestOfDayPVforecast 0 Wh
# 2025-02-10 00:59:49 Today_Hour01_BatIn_01 0 Wh
# 2025-02-10 00:59:49 Today_Hour01_BatOut_01 154 Wh
# 2025-02-10 00:59:49 Today_Hour01_GridConsumption 67 Wh
# 2025-02-10 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2025-02-10 00:59:49 Today_Hour01_PVreal 0 Wh
# 2025-02-10 01:59:49 Today_Hour02_BatIn_01 0 Wh
# 2025-02-10 01:59:49 Today_Hour02_BatOut_01 159 Wh
# 2025-02-10 01:59:49 Today_Hour02_GridConsumption 87 Wh
# 2025-02-10 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2025-02-10 01:59:49 Today_Hour02_PVreal 0 Wh
# 2025-02-10 02:59:50 Today_Hour03_BatIn_01 0 Wh
# 2025-02-10 02:59:50 Today_Hour03_BatOut_01 154 Wh
# 2025-02-10 02:59:50 Today_Hour03_GridConsumption 101 Wh
# 2025-02-10 02:59:50 Today_Hour03_GridFeedIn 0 Wh
# 2025-02-10 02:59:50 Today_Hour03_PVreal 0 Wh
# 2025-02-10 03:59:50 Today_Hour04_BatIn_01 0 Wh
# 2025-02-10 03:59:50 Today_Hour04_BatOut_01 158 Wh
# 2025-02-10 03:59:50 Today_Hour04_GridConsumption 100 Wh
# 2025-02-10 03:59:50 Today_Hour04_GridFeedIn 0 Wh
# 2025-02-10 03:59:50 Today_Hour04_PVreal 0 Wh
# 2025-02-10 04:59:51 Today_Hour05_BatIn_01 0 Wh
# 2025-02-10 04:59:51 Today_Hour05_BatOut_01 112 Wh
# 2025-02-10 04:59:51 Today_Hour05_GridConsumption 144 Wh
# 2025-02-10 04:59:51 Today_Hour05_GridFeedIn 0 Wh
# 2025-02-10 04:59:51 Today_Hour05_PVreal 0 Wh
# 2025-02-10 05:59:49 Today_Hour06_BatIn_01 0 Wh
# 2025-02-10 05:59:49 Today_Hour06_BatOut_01 0 Wh
# 2025-02-10 05:59:49 Today_Hour06_GridConsumption 265 Wh
# 2025-02-10 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2025-02-10 05:59:49 Today_Hour06_PVreal 0 Wh
# 2025-02-10 06:59:49 Today_Hour07_BatIn_01 0 Wh
# 2025-02-10 06:59:49 Today_Hour07_BatOut_01 0 Wh
# 2025-02-10 06:59:49 Today_Hour07_GridConsumption 234 Wh
# 2025-02-10 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2025-02-10 06:59:49 Today_Hour07_PVreal 0 Wh
# 2025-02-10 07:59:49 Today_Hour08_BatIn_01 0 Wh
# 2025-02-10 07:59:49 Today_Hour08_BatOut_01 0 Wh
# 2025-02-10 07:59:49 Today_Hour08_GridConsumption 533 Wh
# 2025-02-10 07:59:49 Today_Hour08_GridFeedIn 0 Wh
# 2025-02-10 07:59:49 Today_Hour08_PVreal 0 Wh
# 2025-02-10 08:59:49 Today_Hour09_BatIn_01 0 Wh
# 2025-02-10 08:59:49 Today_Hour09_BatOut_01 0 Wh
# 2025-02-10 08:59:49 Today_Hour09_GridConsumption 183 Wh
# 2025-02-10 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2025-02-10 08:59:49 Today_Hour09_PVforecast 16 Wh
# 2025-02-10 08:59:49 Today_Hour09_PVreal 30 Wh
# 2025-02-10 09:59:50 Today_Hour10_BatIn_01 60 Wh
# 2025-02-10 09:59:50 Today_Hour10_BatOut_01 0 Wh
# 2025-02-10 09:59:50 Today_Hour10_GridConsumption 109 Wh
# 2025-02-10 09:59:50 Today_Hour10_GridFeedIn 0 Wh
# 2025-02-10 09:59:50 Today_Hour10_PVforecast 101 Wh
# 2025-02-10 09:59:50 Today_Hour10_PVreal 233 Wh
# 2025-02-10 10:59:49 Today_Hour11_BatIn_01 20 Wh
# 2025-02-10 10:59:49 Today_Hour11_BatOut_01 0 Wh
# 2025-02-10 10:59:49 Today_Hour11_GridConsumption 37 Wh
# 2025-02-10 10:59:49 Today_Hour11_GridFeedIn 19 Wh
# 2025-02-10 10:59:49 Today_Hour11_PVforecast 242 Wh
# 2025-02-10 10:59:49 Today_Hour11_PVreal 293 Wh
# 2025-02-10 11:59:54 Today_Hour12_BatIn_01 160 Wh
# 2025-02-10 11:59:54 Today_Hour12_BatOut_01 0 Wh
# 2025-02-10 11:59:54 Today_Hour12_GridConsumption 526 Wh
# 2025-02-10 11:59:54 Today_Hour12_GridFeedIn 0 Wh
# 2025-02-10 11:59:54 Today_Hour12_PVforecast 405 Wh
# 2025-02-10 11:59:54 Today_Hour12_PVreal 648 Wh
# 2025-02-10 12:59:55 Today_Hour13_BatIn_01 260 Wh
# 2025-02-10 12:59:55 Today_Hour13_BatOut_01 0 Wh
# 2025-02-10 12:59:55 Today_Hour13_GridConsumption 110 Wh
# 2025-02-10 12:59:55 Today_Hour13_GridFeedIn 27 Wh
# 2025-02-10 12:59:55 Today_Hour13_PVforecast 483 Wh
# 2025-02-10 12:59:55 Today_Hour13_PVreal 1030 Wh
# 2025-02-10 13:59:49 Today_Hour14_BatIn_01 260 Wh
# 2025-02-10 13:59:49 Today_Hour14_BatOut_01 0 Wh
# 2025-02-10 13:59:49 Today_Hour14_GridConsumption 70 Wh
# 2025-02-10 13:59:49 Today_Hour14_GridFeedIn 40 Wh
# 2025-02-10 13:59:49 Today_Hour14_PVforecast 518 Wh
# 2025-02-10 13:59:49 Today_Hour14_PVreal 1061 Wh
# 2025-02-10 14:59:50 Today_Hour15_BatIn_01 230 Wh
# 2025-02-10 14:59:50 Today_Hour15_BatOut_01 0 Wh
# 2025-02-10 14:59:50 Today_Hour15_GridConsumption 66 Wh
# 2025-02-10 14:59:50 Today_Hour15_GridFeedIn 23 Wh
# 2025-02-10 14:59:50 Today_Hour15_PVforecast 462 Wh
# 2025-02-10 14:59:50 Today_Hour15_PVreal 904 Wh
# 2025-02-10 15:59:57 Today_Hour16_BatIn_01 130 Wh
# 2025-02-10 15:59:57 Today_Hour16_BatOut_01 0 Wh
# 2025-02-10 15:59:57 Today_Hour16_GridConsumption 243 Wh
# 2025-02-10 15:59:57 Today_Hour16_GridFeedIn 0 Wh
# 2025-02-10 15:59:57 Today_Hour16_PVforecast 277 Wh
# 2025-02-10 15:59:57 Today_Hour16_PVreal 459 Wh
# 2025-02-10 16:59:50 Today_Hour17_BatIn_01 60 Wh
# 2025-02-10 16:59:50 Today_Hour17_BatOut_01 0 Wh
# 2025-02-10 16:59:50 Today_Hour17_GridConsumption 558 Wh
# 2025-02-10 16:59:50 Today_Hour17_GridFeedIn 0 Wh
# 2025-02-10 16:59:50 Today_Hour17_PVforecast 130 Wh
# 2025-02-10 16:59:50 Today_Hour17_PVreal 171 Wh
# 2025-02-10 17:59:49 Today_Hour18_BatIn_01 0 Wh
# 2025-02-10 17:59:49 Today_Hour18_BatOut_01 0 Wh
# 2025-02-10 17:59:49 Today_Hour18_GridConsumption 757 Wh
# 2025-02-10 17:59:49 Today_Hour18_GridFeedIn 0 Wh
# 2025-02-10 17:59:49 Today_Hour18_PVforecast 8 Wh
# 2025-02-10 17:59:49 Today_Hour18_PVreal 6 Wh
# 2025-02-10 18:59:49 Today_Hour19_BatIn_01 0 Wh
# 2025-02-10 18:59:49 Today_Hour19_BatOut_01 0 Wh
# 2025-02-10 18:59:49 Today_Hour19_GridConsumption 727 Wh
# 2025-02-10 18:59:49 Today_Hour19_GridFeedIn 0 Wh
# 2025-02-10 18:59:49 Today_Hour19_PVreal 0 Wh
# 2025-02-10 19:59:49 Today_Hour20_BatIn_01 0 Wh
# 2025-02-10 19:59:49 Today_Hour20_BatOut_01 0 Wh
# 2025-02-10 19:59:49 Today_Hour20_GridConsumption 797 Wh
# 2025-02-10 19:59:49 Today_Hour20_GridFeedIn 0 Wh
# 2025-02-10 19:59:49 Today_Hour20_PVreal 0 Wh
# 2025-02-10 20:59:49 Today_Hour21_BatIn_01 0 Wh
# 2025-02-10 20:59:49 Today_Hour21_BatOut_01 0 Wh
# 2025-02-10 20:59:49 Today_Hour21_GridConsumption 737 Wh
# 2025-02-10 20:59:49 Today_Hour21_GridFeedIn 0 Wh
# 2025-02-10 20:59:49 Today_Hour21_PVreal 0 Wh
# 2025-02-10 21:19:20 Today_Hour22_BatIn_01 0 Wh
# 2025-02-10 21:19:20 Today_Hour22_BatOut_01 45 Wh
# 2025-02-10 21:19:20 Today_Hour22_GridConsumption 178 Wh
# 2025-02-10 21:19:20 Today_Hour22_GridFeedIn 0 Wh
# 2025-02-10 21:19:20 Today_Hour22_PVreal 0 Wh
# 2025-02-10 21:19:20 Today_MaxPVforecast 518 Wh
# 2025-02-10 21:19:20 Today_MaxPVforecastTime 2025-02-10 13:00:00
# 2025-02-10 21:19:20 Today_PVdeviation -83.01 %
# 2025-02-10 21:19:20 Today_PVforecast 2642 Wh
# 2025-02-10 21:19:20 Today_PVreal 4835 Wh
# 2025-02-10 21:19:20 Today_SunRise 07:51
# 2025-02-10 21:19:20 Today_SunSet 17:24
# 2025-02-10 21:19:20 Tomorrow_ConsumptionForecast 12348 Wh
# 2025-02-10 21:19:20 Tomorrow_PVforecast 1827 Wh
# 2025-02-10 21:19:20 Tomorrow_SunRise 07:49
# 2025-02-10 21:19:20 Tomorrow_SunSet 17:26
# 2025-02-10 21:19:20 consumer01 name='Geschirrspueler' state='off' mode='must' planningstate='suspended' info='kein max Überschuss für den aktuellen Tag gefunden'
# 2025-02-10 21:19:20 consumer01_currentPower 0 W
# 2025-02-10 21:19:20 consumer01_planned_start 10.02.2025 16:45:07
# 2025-02-10 21:19:20 consumer01_planned_stop 10.02.2025 19:45:07
# 2025-02-10 21:19:20 consumer02 name='Waschmaschine' state='off' mode='must' planningstate='suspended' info='kein max Überschuss für den aktuellen Tag gefunden'
# 2025-02-10 21:19:20 consumer02_currentPower 0 W
# 2025-02-10 21:19:20 consumer02_planned_start 10.02.2025 13:00:07
# 2025-02-10 21:19:20 consumer02_planned_stop 10.02.2025 15:30:07
# 2025-02-10 21:18:43 nextCycletime 21:19:52
# 2022-10-20 12:19:26 nextPolltime 12:20:36
# 2025-02-10 09:00:04 pvCorrectionFactor_09 1.88 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 95, Days in range: 1)
# 2025-02-10 10:00:04 pvCorrectionFactor_10 2.31 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 95, Days in range: 1)
# 2025-02-10 11:00:04 pvCorrectionFactor_11 1.21 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 90, Days in range: 1)
# 2025-02-10 14:00:00 pvCorrectionFactor_14 2.05 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 85, Days in range: 1)
# 2025-02-10 15:00:02 pvCorrectionFactor_15 1.96 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 80, Days in range: 1)
# 2025-02-10 16:00:04 pvCorrectionFactor_16 1.24 (automatic - old factor: 1.00, AI result used, Sun Alt range: 15, Cloud range: 75, Days in range: 1)
# 2025-02-10 17:00:04 pvCorrectionFactor_17 1.35 (automatic - old factor: 1.00, AI result used, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
# 2025-02-10 18:00:04 pvCorrectionFactor_18 0.75 (automatic - old factor: 1.00, Sun Alt range: 0, Cloud range: 75, Days in range: 1)
# 2025-02-10 21:19:20 pvCorrectionFactor_Auto on_complex_ai
# 2024-07-01 18:40:45 setupStringAzimuth Dach=7 Akku=7
# 2024-07-01 18:40:45 setupStringDeclination Dach=20 Akku=10
# 2025-02-10 21:19:20 special_dayAfterTomorrowPVforecast 1592 Wh
# 2025-02-10 21:19:21 state updated
#
setstate SolarForcast updated
setstate SolarForcast 2025-02-10 11:20:45 .associatedWith Stromzaehler Geschirrspueler Waschmaschine Solarbank OpenDTU DWD
setstate SolarForcast 2025-02-10 21:19:20 .lastupdateForecastValues 1739218760
setstate SolarForcast 2025-02-10 21:19:20 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate SolarForcast 2025-02-10 01:00:04 .signaldone_00 done
setstate SolarForcast 2025-02-10 01:00:04 .signaldone_01 done
setstate SolarForcast 2025-02-10 02:00:04 .signaldone_02 done
setstate SolarForcast 2025-02-10 03:00:04 .signaldone_03 done
setstate SolarForcast 2025-02-10 04:00:04 .signaldone_04 done
setstate SolarForcast 2025-02-10 05:00:04 .signaldone_05 done
setstate SolarForcast 2025-02-10 06:00:04 .signaldone_06 done
setstate SolarForcast 2025-02-10 07:00:04 .signaldone_07 done
setstate SolarForcast 2025-02-10 08:00:04 .signaldone_08 done
setstate SolarForcast 2025-02-10 09:00:04 .signaldone_09 done
setstate SolarForcast 2025-02-10 10:00:04 .signaldone_10 done
setstate SolarForcast 2025-02-10 11:00:04 .signaldone_11 done
setstate SolarForcast 2025-02-10 13:20:57 .signaldone_12 done
setstate SolarForcast 2025-02-10 13:20:57 .signaldone_13 done
setstate SolarForcast 2025-02-10 14:00:00 .signaldone_14 done
setstate SolarForcast 2025-02-10 15:00:02 .signaldone_15 done
setstate SolarForcast 2025-02-10 16:00:04 .signaldone_16 done
setstate SolarForcast 2025-02-10 17:00:04 .signaldone_17 done
setstate SolarForcast 2025-02-10 18:00:04 .signaldone_18 done
setstate SolarForcast 2025-02-10 19:00:04 .signaldone_19 done
setstate SolarForcast 2025-02-10 20:00:04 .signaldone_20 done
setstate SolarForcast 2025-02-10 21:00:01 .signaldone_21 done
setstate SolarForcast 2025-02-10 00:00:04 .signaldone_24 done
setstate SolarForcast 2025-02-10 21:19:20 Battery_ChargeRecommended_01 1
setstate SolarForcast 2025-02-10 21:19:20 Current_AutarkyRate 19 %
setstate SolarForcast 2025-02-10 21:19:20 Current_BatCharge_01 80 %
setstate SolarForcast 2025-02-10 21:19:20 Current_Consumption 792 W
setstate SolarForcast 2025-02-10 21:19:20 Current_GridConsumption 638 W
setstate SolarForcast 2025-02-10 21:19:20 Current_GridFeedIn 0 W
setstate SolarForcast 2025-02-10 21:19:20 Current_PV 0 W
setstate SolarForcast 2025-02-10 21:19:20 Current_PowerBatIn_01 0 W
setstate SolarForcast 2025-02-10 21:19:20 Current_PowerBatOut_01 154 W
setstate SolarForcast 2025-02-10 21:19:20 Current_SelfConsumption 0 W
setstate SolarForcast 2025-02-10 21:19:20 Current_SelfConsumptionRate 0 %
setstate SolarForcast 2025-02-10 21:19:20 Current_Surplus 0 W
setstate SolarForcast 2025-02-10 21:00:00 LastHourGridconsumptionReal 737 Wh
setstate SolarForcast 2025-02-10 21:00:00 LastHourPVforecast 0 Wh
setstate SolarForcast 2025-02-10 21:00:00 LastHourPVreal 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 NextHours_Sum01_PVforecast 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 NextHours_Sum02_PVforecast 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 NextHours_Sum03_PVforecast 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 NextHours_Sum04_ConsumptionForecast 1579 Wh
setstate SolarForcast 2025-02-10 21:19:20 NextHours_Sum04_PVforecast 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 RestOfDayConsumptionForecast 1231 Wh
setstate SolarForcast 2025-02-10 21:19:20 RestOfDayPVforecast 0 Wh
setstate SolarForcast 2025-02-10 00:59:49 Today_Hour01_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 00:59:49 Today_Hour01_BatOut_01 154 Wh
setstate SolarForcast 2025-02-10 00:59:49 Today_Hour01_GridConsumption 67 Wh
setstate SolarForcast 2025-02-10 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 00:59:49 Today_Hour01_PVreal 0 Wh
setstate SolarForcast 2025-02-10 01:59:49 Today_Hour02_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 01:59:49 Today_Hour02_BatOut_01 159 Wh
setstate SolarForcast 2025-02-10 01:59:49 Today_Hour02_GridConsumption 87 Wh
setstate SolarForcast 2025-02-10 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 01:59:49 Today_Hour02_PVreal 0 Wh
setstate SolarForcast 2025-02-10 02:59:50 Today_Hour03_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 02:59:50 Today_Hour03_BatOut_01 154 Wh
setstate SolarForcast 2025-02-10 02:59:50 Today_Hour03_GridConsumption 101 Wh
setstate SolarForcast 2025-02-10 02:59:50 Today_Hour03_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 02:59:50 Today_Hour03_PVreal 0 Wh
setstate SolarForcast 2025-02-10 03:59:50 Today_Hour04_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 03:59:50 Today_Hour04_BatOut_01 158 Wh
setstate SolarForcast 2025-02-10 03:59:50 Today_Hour04_GridConsumption 100 Wh
setstate SolarForcast 2025-02-10 03:59:50 Today_Hour04_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 03:59:50 Today_Hour04_PVreal 0 Wh
setstate SolarForcast 2025-02-10 04:59:51 Today_Hour05_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 04:59:51 Today_Hour05_BatOut_01 112 Wh
setstate SolarForcast 2025-02-10 04:59:51 Today_Hour05_GridConsumption 144 Wh
setstate SolarForcast 2025-02-10 04:59:51 Today_Hour05_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 04:59:51 Today_Hour05_PVreal 0 Wh
setstate SolarForcast 2025-02-10 05:59:49 Today_Hour06_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 05:59:49 Today_Hour06_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 05:59:49 Today_Hour06_GridConsumption 265 Wh
setstate SolarForcast 2025-02-10 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 05:59:49 Today_Hour06_PVreal 0 Wh
setstate SolarForcast 2025-02-10 06:59:49 Today_Hour07_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 06:59:49 Today_Hour07_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 06:59:49 Today_Hour07_GridConsumption 234 Wh
setstate SolarForcast 2025-02-10 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 06:59:49 Today_Hour07_PVreal 0 Wh
setstate SolarForcast 2025-02-10 07:59:49 Today_Hour08_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 07:59:49 Today_Hour08_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 07:59:49 Today_Hour08_GridConsumption 533 Wh
setstate SolarForcast 2025-02-10 07:59:49 Today_Hour08_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 07:59:49 Today_Hour08_PVreal 0 Wh
setstate SolarForcast 2025-02-10 08:59:49 Today_Hour09_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 08:59:49 Today_Hour09_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 08:59:49 Today_Hour09_GridConsumption 183 Wh
setstate SolarForcast 2025-02-10 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 08:59:49 Today_Hour09_PVforecast 16 Wh
setstate SolarForcast 2025-02-10 08:59:49 Today_Hour09_PVreal 30 Wh
setstate SolarForcast 2025-02-10 09:59:50 Today_Hour10_BatIn_01 60 Wh
setstate SolarForcast 2025-02-10 09:59:50 Today_Hour10_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 09:59:50 Today_Hour10_GridConsumption 109 Wh
setstate SolarForcast 2025-02-10 09:59:50 Today_Hour10_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 09:59:50 Today_Hour10_PVforecast 101 Wh
setstate SolarForcast 2025-02-10 09:59:50 Today_Hour10_PVreal 233 Wh
setstate SolarForcast 2025-02-10 10:59:49 Today_Hour11_BatIn_01 20 Wh
setstate SolarForcast 2025-02-10 10:59:49 Today_Hour11_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 10:59:49 Today_Hour11_GridConsumption 37 Wh
setstate SolarForcast 2025-02-10 10:59:49 Today_Hour11_GridFeedIn 19 Wh
setstate SolarForcast 2025-02-10 10:59:49 Today_Hour11_PVforecast 242 Wh
setstate SolarForcast 2025-02-10 10:59:49 Today_Hour11_PVreal 293 Wh
setstate SolarForcast 2025-02-10 11:59:54 Today_Hour12_BatIn_01 160 Wh
setstate SolarForcast 2025-02-10 11:59:54 Today_Hour12_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 11:59:54 Today_Hour12_GridConsumption 526 Wh
setstate SolarForcast 2025-02-10 11:59:54 Today_Hour12_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 11:59:54 Today_Hour12_PVforecast 405 Wh
setstate SolarForcast 2025-02-10 11:59:54 Today_Hour12_PVreal 648 Wh
setstate SolarForcast 2025-02-10 12:59:55 Today_Hour13_BatIn_01 260 Wh
setstate SolarForcast 2025-02-10 12:59:55 Today_Hour13_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 12:59:55 Today_Hour13_GridConsumption 110 Wh
setstate SolarForcast 2025-02-10 12:59:55 Today_Hour13_GridFeedIn 27 Wh
setstate SolarForcast 2025-02-10 12:59:55 Today_Hour13_PVforecast 483 Wh
setstate SolarForcast 2025-02-10 12:59:55 Today_Hour13_PVreal 1030 Wh
setstate SolarForcast 2025-02-10 13:59:49 Today_Hour14_BatIn_01 260 Wh
setstate SolarForcast 2025-02-10 13:59:49 Today_Hour14_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 13:59:49 Today_Hour14_GridConsumption 70 Wh
setstate SolarForcast 2025-02-10 13:59:49 Today_Hour14_GridFeedIn 40 Wh
setstate SolarForcast 2025-02-10 13:59:49 Today_Hour14_PVforecast 518 Wh
setstate SolarForcast 2025-02-10 13:59:49 Today_Hour14_PVreal 1061 Wh
setstate SolarForcast 2025-02-10 14:59:50 Today_Hour15_BatIn_01 230 Wh
setstate SolarForcast 2025-02-10 14:59:50 Today_Hour15_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 14:59:50 Today_Hour15_GridConsumption 66 Wh
setstate SolarForcast 2025-02-10 14:59:50 Today_Hour15_GridFeedIn 23 Wh
setstate SolarForcast 2025-02-10 14:59:50 Today_Hour15_PVforecast 462 Wh
setstate SolarForcast 2025-02-10 14:59:50 Today_Hour15_PVreal 904 Wh
setstate SolarForcast 2025-02-10 15:59:57 Today_Hour16_BatIn_01 130 Wh
setstate SolarForcast 2025-02-10 15:59:57 Today_Hour16_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 15:59:57 Today_Hour16_GridConsumption 243 Wh
setstate SolarForcast 2025-02-10 15:59:57 Today_Hour16_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 15:59:57 Today_Hour16_PVforecast 277 Wh
setstate SolarForcast 2025-02-10 15:59:57 Today_Hour16_PVreal 459 Wh
setstate SolarForcast 2025-02-10 16:59:50 Today_Hour17_BatIn_01 60 Wh
setstate SolarForcast 2025-02-10 16:59:50 Today_Hour17_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 16:59:50 Today_Hour17_GridConsumption 558 Wh
setstate SolarForcast 2025-02-10 16:59:50 Today_Hour17_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 16:59:50 Today_Hour17_PVforecast 130 Wh
setstate SolarForcast 2025-02-10 16:59:50 Today_Hour17_PVreal 171 Wh
setstate SolarForcast 2025-02-10 17:59:49 Today_Hour18_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 17:59:49 Today_Hour18_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 17:59:49 Today_Hour18_GridConsumption 757 Wh
setstate SolarForcast 2025-02-10 17:59:49 Today_Hour18_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 17:59:49 Today_Hour18_PVforecast 8 Wh
setstate SolarForcast 2025-02-10 17:59:49 Today_Hour18_PVreal 6 Wh
setstate SolarForcast 2025-02-10 18:59:49 Today_Hour19_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 18:59:49 Today_Hour19_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 18:59:49 Today_Hour19_GridConsumption 727 Wh
setstate SolarForcast 2025-02-10 18:59:49 Today_Hour19_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 18:59:49 Today_Hour19_PVreal 0 Wh
setstate SolarForcast 2025-02-10 19:59:49 Today_Hour20_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 19:59:49 Today_Hour20_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 19:59:49 Today_Hour20_GridConsumption 797 Wh
setstate SolarForcast 2025-02-10 19:59:49 Today_Hour20_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 19:59:49 Today_Hour20_PVreal 0 Wh
setstate SolarForcast 2025-02-10 20:59:49 Today_Hour21_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 20:59:49 Today_Hour21_BatOut_01 0 Wh
setstate SolarForcast 2025-02-10 20:59:49 Today_Hour21_GridConsumption 737 Wh
setstate SolarForcast 2025-02-10 20:59:49 Today_Hour21_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 20:59:49 Today_Hour21_PVreal 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_Hour22_BatIn_01 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_Hour22_BatOut_01 45 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_Hour22_GridConsumption 178 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_Hour22_GridFeedIn 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_Hour22_PVreal 0 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_MaxPVforecast 518 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_MaxPVforecastTime 2025-02-10 13:00:00
setstate SolarForcast 2025-02-10 21:19:20 Today_PVdeviation -83.01 %
setstate SolarForcast 2025-02-10 21:19:20 Today_PVforecast 2642 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_PVreal 4835 Wh
setstate SolarForcast 2025-02-10 21:19:20 Today_SunRise 07:51
setstate SolarForcast 2025-02-10 21:19:20 Today_SunSet 17:24
setstate SolarForcast 2025-02-10 21:19:20 Tomorrow_ConsumptionForecast 12348 Wh
setstate SolarForcast 2025-02-10 21:19:20 Tomorrow_PVforecast 1827 Wh
setstate SolarForcast 2025-02-10 21:19:20 Tomorrow_SunRise 07:49
setstate SolarForcast 2025-02-10 21:19:20 Tomorrow_SunSet 17:26
setstate SolarForcast 2025-02-10 21:19:20 consumer01 name='Geschirrspueler' state='off' mode='must' planningstate='suspended' info='kein max Überschuss für den aktuellen Tag gefunden'
setstate SolarForcast 2025-02-10 21:19:20 consumer01_currentPower 0 W
setstate SolarForcast 2025-02-10 21:19:20 consumer01_planned_start 10.02.2025 16:45:07
setstate SolarForcast 2025-02-10 21:19:20 consumer01_planned_stop 10.02.2025 19:45:07
setstate SolarForcast 2025-02-10 21:19:20 consumer02 name='Waschmaschine' state='off' mode='must' planningstate='suspended' info='kein max Überschuss für den aktuellen Tag gefunden'
setstate SolarForcast 2025-02-10 21:19:20 consumer02_currentPower 0 W
setstate SolarForcast 2025-02-10 21:19:20 consumer02_planned_start 10.02.2025 13:00:07
setstate SolarForcast 2025-02-10 21:19:20 consumer02_planned_stop 10.02.2025 15:30:07
setstate SolarForcast 2025-02-10 21:18:43 nextCycletime 21:19:52
setstate SolarForcast 2022-10-20 12:19:26 nextPolltime 12:20:36
setstate SolarForcast 2025-02-10 09:00:04 pvCorrectionFactor_09 1.88 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 95, Days in range: 1)
setstate SolarForcast 2025-02-10 10:00:04 pvCorrectionFactor_10 2.31 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 95, Days in range: 1)
setstate SolarForcast 2025-02-10 11:00:04 pvCorrectionFactor_11 1.21 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 90, Days in range: 1)
setstate SolarForcast 2025-02-10 14:00:00 pvCorrectionFactor_14 2.05 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 85, Days in range: 1)
setstate SolarForcast 2025-02-10 15:00:02 pvCorrectionFactor_15 1.96 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 80, Days in range: 1)
setstate SolarForcast 2025-02-10 16:00:04 pvCorrectionFactor_16 1.24 (automatic - old factor: 1.00, AI result used, Sun Alt range: 15, Cloud range: 75, Days in range: 1)
setstate SolarForcast 2025-02-10 17:00:04 pvCorrectionFactor_17 1.35 (automatic - old factor: 1.00, AI result used, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
setstate SolarForcast 2025-02-10 18:00:04 pvCorrectionFactor_18 0.75 (automatic - old factor: 1.00, Sun Alt range: 0, Cloud range: 75, Days in range: 1)
setstate SolarForcast 2025-02-10 21:19:20 pvCorrectionFactor_Auto on_complex_ai
setstate SolarForcast 2024-07-01 18:40:45 setupStringAzimuth Dach=7 Akku=7
setstate SolarForcast 2024-07-01 18:40:45 setupStringDeclination Dach=20 Akku=10
setstate SolarForcast 2025-02-10 21:19:20 special_dayAfterTomorrowPVforecast 1592 Wh
setstate SolarForcast 2025-02-10 21:19:21 state updated
Hallo Skusi,
ich denke du hast alles richtig eingerichtet.
Allgemein ist die Solarprognose gerade jetzt im Winter häufig ungenau. Es kommt oft keine Direkstrahlung sondern fast nur diffuse Strahlung auf die Zellen. Die von den Wetterdiensten prognostizierten Strahlungswerte sowie Bewölkungen sind je nach Wettermodell auch recht unterschiedlich. Ich habe verschiedene Quellen parallel in verschiedenen Devices laufen und die sind zur Zeit häufig nicht übereinstimmend in ihren Vorhersagen.
Davon unabhängig sind für eine erste Betrachtung diese Readings recht hilfreich:
# 2025-02-10 09:00:04 pvCorrectionFactor_09 1.88 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 95, Days in range: 1)
# 2025-02-10 10:00:04 pvCorrectionFactor_10 2.31 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 95, Days in range: 1)
# 2025-02-10 11:00:04 pvCorrectionFactor_11 1.21 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 90, Days in range: 1)
# 2025-02-10 14:00:00 pvCorrectionFactor_14 2.05 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 85, Days in range: 1)
# 2025-02-10 15:00:02 pvCorrectionFactor_15 1.96 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 80, Days in range: 1)
# 2025-02-10 16:00:04 pvCorrectionFactor_16 1.24 (automatic - old factor: 1.00, AI result used, Sun Alt range: 15, Cloud range: 75, Days in range: 1)
# 2025-02-10 17:00:04 pvCorrectionFactor_17 1.35 (automatic - old factor: 1.00, AI result used, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
# 2025-02-10 18:00:04 pvCorrectionFactor_18 0.75 (automatic - old factor: 1.00, Sun Alt range: 0, Cloud range: 75, Days in range: 1)
Hier ist abzulesen, dass für die jeweilige Stunde des Tages die Gegebenheiten für Sonnenstand, Bewölkung (und der hier nicht ausgeschriebenen Strahlung) nur an diesem Tag das erste mal auftrat und aufgezeichnet wurde. Das Modul zeichnet die Ergebnisse für jede einzelne Stunde abhängig von Sonnenstand, Bewölkung etc. auf.
Sollten sich die Verhältnisse in der Zukunft unter gleichen Bedingungen wiederholen, wird der ermittelte Faktor angewendet und wiederum mit dem Ergebnis verglichen/neu berechnet und so die Ergebnisse besser.
Dabei wird vorausgesetzt, dass die Wetterdienste die Verhältnisse wieder so vorhersagen was aber auch nicht feststeht, sondern mit Sicherheit mit Abweichungen von der Realität behaftet ist.
Wir hatten vor ein paar Monaten die DWD Daten mit dem implementierten Berechnungsmodell von pah ohne jegliche Korrekturfaktoren eine Weile beobachtet. Die Bewölkung hatte stets einen entscheidenden Einfluß auf die realen Ergebnisse. Bei Idealwetter mit klarem Himmel waren die Ergebnisse (wie vorhersehbar) sehr gut.
Also aktuell kein Anlass an den eigenen Einstellungen zu zweifeln.
ZitatDer Status steht bei mir oft auf gelb!
Dieser Status visualisiert die in der Vergangenheit unter den aktuellen Bedingungen für diese Stunde erreichte Trefferqualität um ein gewisses Gefühl für die Verlässlichkeit der Prognose zu haben.
ZitatWenn es aber um eine Tagesprognose geht und der Verbraucher eingeschaltet ist bzw. wird, könnte man doch sehr gut auf den "historischen Verlauf" für die Tagesprognose zurückgreifen, da daraus ja der charakteristische Verlauf bei den letzten Verbrauchsvorgängen sichtbar wird.
Ja genau. Das wird mit affectConsForecastIdentWeekdays so gemacht. Aber man müßte ihn aus dem historischen Tag stundenweise herausrechnen falls er gelaufen ist, da die Prognose, wenn es sich um Überschußladung handelt, ganz anders sein kann. Diese Prognose wäre wiedrum zu addieren.
Aber vllt. ist das auch alles etwas oversized und affectConsForecastIdentWeekdays reicht völlig aus. Habe auch kein E-Auto und kann die realen Auswirkungen nicht wirklich nachvollziehen.
Zitat von: DS_Starter am 11 Februar 2025, 11:28:37ZitatWenn es aber um eine Tagesprognose geht und der Verbraucher eingeschaltet ist bzw. wird, könnte man doch sehr gut auf den "historischen Verlauf" für die Tagesprognose zurückgreifen, da daraus ja der charakteristische Verlauf bei den letzten Verbrauchsvorgängen sichtbar wird.
Ja genau. Das wird mit affectConsForecastIdentWeekdays so gemacht. Aber man müßte ihn aus dem historischen Tag stundenweise herausrechnen falls er gelaufen ist, da die Prognose, wenn es sich um Überschußladung handelt, ganz anders sein kann. Diese Prognose wäre wiedrum zu addieren.
Aber vllt. ist das auch alles etwas oversized und affectConsForecastIdentWeekdays reicht völlig aus. Habe auch kein E-Auto und kann die realen Auswirkungen nicht wirklich nachvollziehen.
Das Beispiel war offenbar nicht gut, da es bei keinem von uns beiden zutrifft. Habe aber noch ein anderes Beispiel, das die Problematik vielleicht besser charakterisiert. Persönlich habe ich nämlich auch keine Wärmepumpe und nutze daher meine überschüssige PV-Leistung in der Übergangszeit um einen Elektroheizkörper mit Thermostat in einem Hobbyraum und einen IR-Strahler mit konstanter Leistung im Bad. In beiden Fällen sieht das Lastprofil bei den jeweiligen Einsätzen ziemlich gleich aus, aber es gibt keine Regelmäßigkeit hinsichtlich des Einsatzes. Und genau hier versagt die Verbrauchsprognose leider.
ZitatIn beiden Fällen sieht das Lastprofil bei den jeweiligen Einsätzen ziemlich gleich aus, aber es gibt keine Regelmäßigkeit hinsichtlich des Einsatzes. Und genau hier versagt die Verbrauchsprognose leider.
Da gebe ich dir völlig recht. Unregeläßige Einsätze lassen sich aktuell in der Verbrauchsprognose nicht gut vorhersehen. Deswegen schrieb ich weiter oben bereits dass es ein ToDo zur Verbesserung wäre .
Bei Großverbrauchern fällt das Manko halt ziemlich ins Gewicht.
Guten Morgen Heiko,
kann es evtl. sein das es irgendwo einen Bug "dauerhafte Bevorzugung zum Be-laden der Batterie 2" gibt.
Ich frage deshalb, da ich Folgendes bei meiner Vorbereitung / Kontrolle mit SF zum "Netzdienliches Be-Laden" beobachtet habe:
ABER - Hinweis :
Ich schalte / steuere die Batterie-Beladung beider Batterien z.Z. noch nicht mit FHEM - logge bzw. schaue aktuell nur was wohl von SF berechnet und vorgeben wird
2 Batterien:
- Batterie 01
Wechselt seit dem 22.01.2025 immer wieder (nachvollziehbar) den Status "Battery_ChargeRecommended_01" von 0 auf 1 und zurück u.s.w. ;D
DGLog -> 1994 Einträge 92 Einträge mit 0 1902 Einträge mit 1
- Batterie 02
Wechselt seit dem 22.01.2025 noch nicht ein einziges mal den Status "Battery_ChargeRecommended_02" von 1 auf 0 u.s.w :o
1982 Einträge ALLE Einträge im DBLog mit dem Wert 1 Keiner mit 0
(Auch wenn Batterie01 auf 0 wechselt - es erfolgt dann kein Wechsel von 1 auf 0 =>> trotz genügend späterer PV-Leistung")
Oder gibt es einen anderen Parameter / Grund den ich nicht sehe/finde/übersehe.
attr Forecast affectBatteryPreferredCharge 30
attr Forecast affectConsForecastLastDays 31
...
...
...
attr Forecast setupBatteryDev01 SBS25 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap:Wh show=2
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap:Wh show=2
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=70
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=70
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=70
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast setupRadiationAPI DWD
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=0.0001 HausSE2=0.0001
attr Forecast setupWeatherDev1 DWD
attr Forecast stateFormat Current_PVBerechnung des SF-cap-Wertes in den beiden SBS25
attr SBS25 userReadings bat_residual_cap {ReadingsNum($name,"bat_rated_capacity",0)*ReadingsNum($name,"bat_capacity",0)*10}\
- hier berechneter Wert = 9114
attr SBS25_2 userReadings bat_residual_cap {ReadingsNum($name,"bat_rated_capacity",0)*ReadingsNum($name,"bat_capacity",0)*10}\
- dort berechneter aktueller Wert = 8624
Gruß
300P
Nachsatz:
hab vergessen zu erwähnen das 2 String (HausSE1 und HausSE2) noch nicht auf dem Dach angeschlossen sind und deshalb so sind : HausSE1=0.0001 HausSE2=0.0001
Hallo zusammen,
ich habe das Modul relativ neu am Start - wirklich eine tolle Sache, super!!
Heute habe ich ein Update gemacht, nun wird der Akku-SOC als 0 % in der Grafik angezeigt.
Im Reading Current_BatCharge_01 ist der Wert aber korrekt.
Muss ich etwas neu einrichten oder ist das ein Bug?
Danke Euch und einen schönen Abend
Dirk
Zitat von: Dirk070 am 12 Februar 2025, 18:00:55Heute habe ich ein Update gemacht, nun wird der Akku-SOC als 0 % in der Grafik angezeigt.
Im Reading Current_BatCharge_01 ist der Wert aber korrekt.
Muss ich etwas neu einrichten oder ist das ein Bug?
Hallo Dirk,
zeig bitte mal dein "setupBatteryDev01" komplett.
Es könnte die Einstellung cap=xyxyxyxy sein.
Gruß
300P
Hallo,
ja, ich war gerade dabei meinen Post zu ergänzen ;)
CAP war vorher optional, nachdem ich den Wert eingetragen habe, erscheint auch der SOC (wieder).
Dafür wäre der CAP aber doch nicht notwendig, wenn ich CHARGE angegeben habe, oder?
e3dc_s10Pro pin=Battery_Power:W pout=-pin cap=13110 charge=Battery_SOC
Danke fürs Antworten.
Die cap-Angabe war optional - jetzt geht nicht alles ohne den cap ;D
Das hat wohl schon so einige getroffen ....
Danke Dir!!
Den Wert kriege ich leider nicht für mein E3/DC über die RSCP2MQTT Lösung von PVTom. Daher musste es dann ein direkter Wert sein.
Hallo 300P,
Zitatkann es evtl. sein das es irgendwo einen Bug "dauerhafte Bevorzugung zum Be-laden der Batterie 2" gibt.
Ich frage deshalb, da ich Folgendes bei meiner Vorbereitung / Kontrolle mit SF zum "Netzdienliches Be-Laden" beobachtet habe:
ABER - Hinweis :
Ich schalte / steuere die Batterie-Beladung beider Batterien z.Z. noch nicht mit FHEM - logge bzw. schaue aktuell nur was wohl von SF berechnet und vorgeben wird
Nein, es gibt keine Bevorzugung. Aber es gibt eine Gewichtung aller relevanten Kenngrößen bei der Berechnung in Abhängigkeit des cap-Anteils der Batterie zur gesamten installerten Batterie-Kapazität um eine gewisse Anteilsverteilung hinzubekommen.
So richtig arbeiten wird diese Logik wohl erst wenn die Sonne uns wieder Freude macht. ;)
Morgen früh ist die Version 1.45.6 im Update.
Enthalten sind Codes zur weiteren Vorbereitung die Verbrauchsprognose demnächst von einem deutlich erweiterterbaren Wertevorrat ableiten zu können.
In dem Zusammenhang wird bei einer späteren Umstellung das Attribut affectConsForecastLastDays wahrscheinlich obsolet da der Wertevorrat deutlich erweitert wird.
In dem Zusammenhang versuche ich ebenfalls das zuletzt mit Parallix diskutierte Thema mit zu implementieren, d.h. die geplanten Schaltzeiten der Verbraucher in den nächsten Stunden mit den Auswertungen der historischen Betriebsstunden zu verknüpfen.
Mal sehen ob/wie es mir gelingt.
Das Update morgen enthält keine funktionalen Änderungen, aber wichtige Vorbereitungen.
Führt das Update bitte zeitnah aus.
LG,
Heiko
Zitat von: 300P am 12 Februar 2025, 18:09:26Zitat von: Dirk070 am 12 Februar 2025, 18:00:55Heute habe ich ein Update gemacht, nun wird der Akku-SOC als 0 % in der Grafik angezeigt.
Im Reading Current_BatCharge_01 ist der Wert aber korrekt.
Muss ich etwas neu einrichten oder ist das ein Bug?
Hallo Dirk,
zeig bitte mal dein "setupBatteryDev01" komplett.
Es könnte die Einstellung cap=xyxyxyxy sein.
Gruß
300P
Moin!
Ich hatte das selbe Verhalten. Es hat bei mir geholfen von
cap=7.680:kWh auf
cap=7680 umzustellen. Danke für den Tipp!
Das Modul habe ich gestern zum ersten mal eingerichtet und bin echt geflasht! Jahrelang baut man sich seinen eigenen Mist und dann bekommt man so eine schöne Ansicht generiert nach Einstellung von ein paar Parametern. Mega cool!
Wird hier auch irgendwie noch Schneefall / Schnee auf den Modulen berücksichtigt?
Zitat von: FHEMAN am 13 Februar 2025, 08:03:25..........
Moin!
Ich hatte das selbe Verhalten. Es hat bei mir geholfen von cap=7.680:kWh auf cap=7680 umzustellen. Danke für den Tipp!
Das Modul habe ich gestern zum ersten mal eingerichtet und bin echt geflasht! Jahrelang baut man sich seinen eigenen Mist und dann bekommt man so eine schöne Ansicht generiert nach Einstellung von ein paar Parametern. Mega cool!
Wird hier auch irgendwie noch Schneefall / Schnee auf den Modulen berücksichtigt?
Ja - deine Werte der realen PV-Erträge werden an dem Tag reduziert !?!
;D ;D ;D
Guten Morgen,
ZitatWird hier auch irgendwie noch Schneefall / Schnee auf den Modulen berücksichtigt?
Wie 300P schon schrieb, werden deine realen Werte dadurch natürlich reduziert. ;)
Aber ich vermute du möchtest gern wissen ob dieser Zustand in der
PV-Prognose berücksichtigt wird?
Das hatten wir schon mal weit vorn diskutiert. Wenn die aktuelle Witterung (Wetterdienst) Schneefall vorhersagt, geht es natürlich in die Prognose ein. Aber das Modul kann nicht einschätzen ob die Module von Schnee bedeckt sind.
So kann zum Beispiel der schönste Sonnenschein vorliegen, aber die Module sind von einer dicken Schneeschicht bedeckt die in der Nacht gefallen ist.
Dann wird das prognostizierte und reale Ergebnis weit auseinanderliegen. Das Modul unterstützt eine externe Einflussnahme über die Setter pvCorrectionFactor_XX und pvCorrectionFactor_Auto.
So kannst du dir z.B. einen "Schneesensor" in FHEM bauen und falls der anschlägt, über geeignete Maßnahme (notify, DOIF, ...) für jede relevante Stunde eine individuelle Abschwächung vornehemen. Dadurch kannst du in diesen Fällen die Prognose und reale Erzeugung näher zusammenbringen.
Nur so als Anregung.
LG,
Heiko
Hallo zusammen,
ich nutze das Modul jetzt schon einige Zeit, hatte aber bisher keine Verbraucher angelegt. Damit habe ich jetzt angefangen. Vielleicht nicht die beste Jahreszeit, aber so startet die Waschmaschine bei Fehlern auch nicht gleich drei Mal am Tag ;-)
Für ein Thema habe ich noch keine richtig gute Lösung: Ich habe einen Akku, den ich einmal pro Woche laden möchte. Natürlich gerne bei Überschuss, spätestens Ende der Woche aber auch ohne. Soweit ich die Konfigurationsmöglichkeiten verstanden habe, sind die eher auf eine tägliche Ansteuerung der Verbraucher ausgelegt. Oder habe ich etwas übersehen. Ich könnte natürlich über Notifys mit den Parametern auto und mode arbeiten, bräuchte aber mindestens noch einen (Wochen-) Timer, den ich nach vorhandenem Überschuss aber auch wieder irgendwie deaktivieren müsste. Das scheint mir ziemlich unübersichtlich zu werden. Hatte schon jemand eine gute Idee für so einen Anwendungsfall?
Vielen Dank für Tipps
Thomas
Zitat von: tomcat.x am 13 Februar 2025, 16:04:15Hatte schon jemand eine gute Idee für so einen Anwendungsfall?
Exakt so einen Fall habe ich nicht. Aber ich habe zum Laden - um einen gewissen Wert sicherzustellen - abhängig vom Ladezustand userReadings canCharge und mustCharge im Device erstellt. Die kann man im Device mit verwenden (oder was eigenes draus bauen).
Wenn ich mustCharge erreiche - also während canCharge nicht genügend Überschuss zusammenkommt - wird zwangsgeladen. Ist keines aktiv wird gar nicht geladen.
Durch Verwendung von z.B. userReadings bleiben die Werte im Device selber und solarforeCast kann sich derer bedienen.
Gruß,
Tobi
@tomcat.x
Darf man mal Fragen warum..
ZitatIch habe einen Akku, den ich einmal pro Woche laden möchte
..du das machen möchest?
Nabend,
ich habe mich heute auch mal an den SolarForecast gewagt.
Hat super funktioniert mit der geführten Einrichtung.
Eine Sache habe ich aber noch.
Ich habe ein S10E von E3DC und lese die erforderlichen Daten per RSCP2MQTT aus.
Jetzt habe ich mit den Werten für Netzbezug, Einspeisung, Bezug aus Batterie und Einspeichern in Batterie ein "Problemchen".
Die Daten werden im 15 Minuten-Takt zur Verfügung gestellt. Immer ca. 1-1,5 Minuten nach der vollen Viertelstunde.
Beim Stundenwechsel zieht er mir die letzte Viertelstunde der vorhergehende Stunde in die aktuelle Stunde. (Hört sich doof an, ich weiß;-)).
Im Endeffekt habe ich dann in der Balkengrafik quasi immer den Verbrauch von x:15 bis x+1:15.
Wie haben das andere E3DC Nutzer gelöst? Es ist im Endeffekt nur Kosmetik.
Und dann hätte ich noch eine Frage.
Was bedeutet die 0 unter meiner Wärmepumpe?
Schönen Abend noch!
Die Frage kann ich dir beantworten:
ZitatWas bedeutet die 0 unter meiner Wärmepumpe?
Das ist die Restlaufzeit des aktuellen Zyklus in Minuten falls der Consumer geplant wurde und gestartet ist.
Zitat von: mannil am 13 Februar 2025, 21:10:13Nabend,
ich habe mich heute auch mal an den SolarForecast gewagt.
Hat super funktioniert mit der geführten Einrichtung.
Eine Sache habe ich aber noch.
Ich habe ein S10E von E3DC und lese die erforderlichen Daten per RSCP2MQTT aus.
Jetzt habe ich mit den Werten für Netzbezug, Einspeisung, Bezug aus Batterie und Einspeichern in Batterie ein "Problemchen".
Die Daten werden im 15 Minuten-Takt zur Verfügung gestellt. Immer ca. 1-1,5 Minuten nach der vollen Viertelstunde.
Beim Stundenwechsel zieht er mir die letzte Viertelstunde der vorhergehende Stunde in die aktuelle Stunde. (Hört sich doof an, ich weiß;-)).
Im Endeffekt habe ich dann in der Balkengrafik quasi immer den Verbrauch von x:15 bis x+1:15.
Wie haben das andere E3DC Nutzer gelöst? Es ist im Endeffekt nur Kosmetik.
Und dann hätte ich noch eine Frage.
Was bedeutet die 0 unter meiner Wärmepumpe?
Schönen Abend noch!
Moin mannil,
wir haben auch eine E3DC-Anlage. Ich hole die werte mit MODBUS alle 20 Sekunden ab und summiere einfach auf.
Das ist ausreichend genau und hat sich für mich bewährt.
Hier die Definition des devices
define S10 ModbusAttr 1 20 192.168.67.62:502 TCP
attr S10 DbLogInclude Leistung,battsoc,battwatt,gridwatt,homewatt,Entladung,Ladung,Netzbezug,Einspeisung,sun2watt2,s1_p,s2_p
attr S10 devStateIcon opened:rc_WEB@32CD32 disconnected:rc_WEB@red
attr S10 event-min-interval .*:180
attr S10 event-on-change-reading .*
attr S10 event-on-update-reading battwatt.*,Entladung.*,Ladung.*,Netzbezug.*,Leistung.*,homewatt.*,sun2watt2.*,s1_p.*,s2_p.*
attr S10 group E3DC
attr S10 icon measure_photovoltaic_inst@yellow
attr S10 obj-h40052-len 16
attr S10 obj-h40052-poll 1
attr S10 obj-h40052-reading seriennr
attr S10 obj-h40052-unpack n
attr S10 obj-h40066-len 2
attr S10 obj-h40066-poll 1
attr S10 obj-h40066-reading sunwatt
attr S10 obj-h40066-unpack N
attr S10 obj-h40068-len 2
attr S10 obj-h40068-poll 1
attr S10 obj-h40068-reading battwatt0
attr S10 obj-h40068-unpack N
attr S10 obj-h40070-len 2
attr S10 obj-h40070-poll 1
attr S10 obj-h40070-reading homewatt0
attr S10 obj-h40070-unpack N
attr S10 obj-h40072-len 2
attr S10 obj-h40072-max 65537
attr S10 obj-h40072-min 0
attr S10 obj-h40072-poll 1
attr S10 obj-h40072-reading gridwatt0
attr S10 obj-h40072-unpack N
attr S10 obj-h40074-len 2
attr S10 obj-h40074-poll 1
attr S10 obj-h40074-reading zusatzwatt
attr S10 obj-h40074-unpack N
attr S10 obj-h40081-len 1
attr S10 obj-h40081-poll 1
attr S10 obj-h40081-reading ae
attr S10 obj-h40081-unpack n
attr S10 obj-h40082-len 1
attr S10 obj-h40082-poll 1
attr S10 obj-h40082-reading battsoc
attr S10 obj-h40082-unpack n
attr S10 obj-h40084-len 1
attr S10 obj-h40084-reading ems
attr S10 obj-h40084-unpack n
attr S10 obj-h40101-len 1
attr S10 obj-h40101-poll 1
attr S10 obj-h40101-reading s1_p
attr S10 obj-h40101-unpack n
attr S10 obj-h40102-len 1
attr S10 obj-h40102-poll 1
attr S10 obj-h40102-reading s2_p
attr S10 obj-h40102-unpack n
attr S10 room Solaranlage
attr S10 timestamp-on-change-reading statSunwattDayMax,statSunwattDayMaxLast,statSunwattHourMax,statSunwattHourMaxLast,statSunwattMonthMax,statSunwattYearMax
attr S10 userReadings gridwatt { if (ReadingsVal("S10", "gridwatt0", "0") <= 32768 ) {(ReadingsVal("S10", "gridwatt0", "0"))} else {(ReadingsVal("S10", "gridwatt0", "0")) - 65536 };; }, \
battwatt { if (ReadingsVal("S10", "battwatt0", "0") <= 32768 ) {(ReadingsVal("S10", "battwatt0", "0"))} else {(ReadingsVal("S10", "battwatt0", "0")) - 65536 };; }, \
homewatt { if (ReadingsVal("S10", "homewatt0", "0") <= 4294901759 ) {(ReadingsVal("S10", "homewatt0", "0"))} else {(ReadingsVal("S10", "homewatt0", "0")) - 4294967295 + 65536 };; }, \
notstrom { (ReadingsVal("S10", "ems", "0")) ;; }, \
sun2wat { if (ReadingsVal("S10", "zusatzwatt", "0") <= 4294901759 ) {(ReadingsVal("S10", "zusatzwatt", "0")) - 65536 } else {(ReadingsVal("S10", "zusatzwatt", "0")) - 4294967296 + 65536 };; }, \
sun2wat2 { if (ReadingsVal("S10", "sun2wat", "0") > 40000 ) {(ReadingsVal("S10", "sun2wat", "0")) - 65536 } else {(ReadingsVal("S10", "sun2wat", "0")) };; }, \
sun2watt { if (ReadingsVal("S10", "sun2wat2", "0") < -40000 ) {(ReadingsVal("S10", "sun2wat2", "0")) + 65536 } else {(ReadingsVal("S10", "sun2wat2", "0")) };; }, \
sun2watt2 { (ReadingsVal("S10", "sun2watt", "0")) *-1 ;; }, \
Leistung { (ReadingsVal("S10", "sun2watt2", "0")) + (ReadingsVal("S10", "sunwatt", "0")) ;; }, \
autarkie { ((ReadingsVal("S10", "ae", "0")) & 0xFF00) >> 8;; }, \
eigenverbrauch { (ReadingsVal("S10", "ae", "0")) & 0xFF;; }, \
Entladung:.* {if (ReadingsVal("S10", "battwatt", "0")<=0) {my $Wert=abs(ReadingsVal("S10", "battwatt", "0"));; return $Wert} else{return 0}}, \
Ladung:.* {if (ReadingsVal("S10", "battwatt", "0")>=0) {my $Wert=abs(ReadingsVal("S10", "battwatt", "0"));; return $Wert} else{return 0}}, \
Battsoc_KWh:.* {use Math::Round qw/round/;; Math::Round::nearest(0.01,ReadingsVal("S10", "battsoc", "0")*29.16/100)}, \
Netzbezug:.* {if (ReadingsVal("S10", "gridwatt", "0")>=0) {my $Wert=abs(ReadingsVal("S10", "gridwatt", "0"));; return $Wert} else{return 0}}, \
Einspeisung:.* {if (ReadingsVal("S10", "gridwatt", "0")<=0) {my $Wert=abs(ReadingsVal("S10", "gridwatt", "0"));; return $Wert} else{return 0}}, \
Sparsam:.* {if (ReadingsVal("S10", "homewatt", "0")<700) {return 1} else{return 0}}
# DEF 1 20 192.168.67.62:502 TCP
# DeviceName 192.168.67.62:502
# EXPECT idle
# FD 25
# FUUID 612fdb98-f33f-79f8-2c69-879d76551b3e937b
# IODev S10
# Interval 20
# LASTOPEN 1739440102.46783
# MODBUSID 1
# MODE master
# MODULEVERSION Modbus 4.5.6 - 7.11.2023
# NAME S10
# NOTIFYDEV global
# NR 522
# NTFY_ORDER 50-S10
# PARTIAL
# PROTOCOL TCP
# STATE opened
# TCPConn 1
# TYPE ModbusAttr
# devioLoglevel 3
# devioNoSTATE 1
# eventCount 6026
# nextOpenDelay 60
# DICACHE:
# 3:
# UNPACK
# EXPRS:
# EXTRAS:
# FNAMES:
# Helper:
# DBLOG:
# Einspeisung:
# logdb:
# TIME 1739480324.72469
# VALUE 0
# Entladung:
# logdb:
# TIME 1739480324.72469
# VALUE 0
# Ladung:
# logdb:
# TIME 1739480324.72469
# VALUE 0
# Leistung:
# logdb:
# TIME 1739480344.84775
# VALUE 0
# Netzbezug:
# logdb:
# TIME 1739480344.9374
# VALUE 568
# battsoc:
# logdb:
# TIME 1739480305.25335
# VALUE 0
# battwatt:
# logdb:
# TIME 1739480324.72469
# VALUE 0
# gridwatt:
# logdb:
# TIME 1739480344.9374
# VALUE 568
# homewatt:
# logdb:
# TIME 1739480324.82962
# VALUE 568
# s1_p:
# logdb:
# TIME 1739480205.40592
# VALUE 0
# s2_p:
# logdb:
# TIME 1739480205.51689
# VALUE 0
# sun2watt2:
# logdb:
# TIME 1739480344.84775
# VALUE 0
# PICACHE:
# h40052:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40066:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40068:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40070:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40072:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40074:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40081:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40082:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40101:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# h40102:
# bswapRegs
# decode
# encode
# expr
# format
# ignoreExpr
# map
# mapDefault
# revRegs
# rmapDefault
# QUEUE:
# READ:
# BUFFER
# READINGS:
# 2025-02-13 21:59:04 Autarkie 0
# 2025-02-13 21:59:04 Battsoc_KWh 0
# 2022-04-19 11:24:01 Bildpfad /fhem/www/images/Solaranlage_dunkel_neu_ohne_Text.png
# 2025-02-13 21:59:04 Eigennutzung 0
# 2025-02-13 21:59:04 Einspeisung 0
# 2025-02-13 21:58:44 Einspeisung_Fortlaufend 0
# 2025-02-13 21:59:04 Entladung 0
# 2025-02-13 21:58:44 Entladung_Fortlaufend 0
# 2025-02-13 21:59:04 Ertrag_Fortlaufend_Extern 1.71
# 2025-02-13 21:59:04 Ertrag_Fortlaufend_Test 6.7
# 2025-02-13 21:59:04 Ertrag_Fortlaufend_s1_p 0
# 2025-02-13 21:59:04 Ertrag_Fortlaufend_s2_p 5.6
# 2025-02-13 21:58:44 Hausverbrauch_Fortlaufend 78602.47
# 2025-02-13 21:59:04 Ladung 0
# 2025-02-13 21:59:05 Leistung 0
# 2025-02-13 21:59:04 Netzbezug 568
# 2025-02-13 21:59:04 Netzbezug_Fortlaufend 79299.38
# 2025-02-13 21:59:04 Sparsam 1
# 2025-02-13 21:59:05 ae 99
# 2025-02-13 21:59:05 autarkie 0
# 2025-02-13 21:59:05 battsoc 0
# 2025-02-13 21:59:05 battwatt 0
# 2025-02-13 21:59:04 battwatt0 0
# 2025-02-13 21:59:05 eigenverbrauch 99
# 2022-12-12 23:29:16 ems 0
# 2025-02-13 21:59:05 gridwatt 568
# 2025-02-13 21:59:04 gridwatt0 568
# 2025-02-13 21:59:05 homewatt 568
# 2025-02-13 21:59:04 homewatt0 568
# 2025-02-13 21:59:05 notstrom 0
# 2025-02-13 21:59:05 s1_p 0
# 2025-02-13 21:59:05 s2_p 0
# 2025-02-13 21:59:04 seriennr 12383
# 2025-02-13 21:59:04 statEinspeisungDay Min: 0 Avg: 0 Max: 0
# 2025-02-12 23:59:55 statEinspeisungDayLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statEinspeisungDayMax 0
# 2025-02-12 23:59:55 statEinspeisungDayMaxLast 0
# 2025-02-13 21:59:04 statEinspeisungHour Min: 0 Avg: 0 Max: 0
# 2025-02-13 20:59:55 statEinspeisungHourLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statEinspeisungHourMax 0
# 2025-02-13 20:59:55 statEinspeisungHourMaxLast 0
# 2025-02-13 21:59:04 statEinspeisungMonth Min: 0 Avg: 4 Max: 4012
# 2025-01-31 23:59:55 statEinspeisungMonthLast Min: 0 Avg: 1 Max: 2398
# 2025-02-13 21:59:04 statEinspeisungMonthMax 4012
# 2025-01-31 23:59:55 statEinspeisungMonthMaxLast 2398
# 2025-02-13 21:59:04 statEinspeisungYear Min: 0 Avg: 2 Max: 4012
# 2024-12-31 23:59:55 statEinspeisungYearLast Min: 0 Avg: 616 Max: 18705
# 2025-02-13 21:59:04 statEinspeisungYearMax 4012
# 2024-12-31 23:59:55 statEinspeisungYearMaxLast 18705
# 2025-02-13 21:59:04 statEntladungDay Min: 0 Avg: 0 Max: 0
# 2025-02-12 23:59:55 statEntladungDayLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statEntladungDayMax 0
# 2025-02-12 23:59:55 statEntladungDayMaxLast 0
# 2025-02-13 21:59:04 statEntladungHour Min: 0 Avg: 0 Max: 0
# 2025-02-13 20:59:55 statEntladungHourLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statEntladungHourMax 0
# 2025-02-13 20:59:55 statEntladungHourMaxLast 0
# 2025-02-13 21:59:04 statEntladungMonth Min: 0 Avg: 334 Max: 11115
# 2025-01-31 23:59:55 statEntladungMonthLast Min: 0 Avg: 107 Max: 10185
# 2025-02-13 21:59:04 statEntladungMonthMax 11115
# 2025-01-31 23:59:55 statEntladungMonthMaxLast 10185
# 2025-02-13 21:59:04 statEntladungYear Min: 0 Avg: 174 Max: 11115
# 2024-12-31 23:59:55 statEntladungYearLast Min: 0 Avg: 409 Max: 11583
# 2025-02-13 21:59:04 statEntladungYearMax 11115
# 2024-12-31 23:59:55 statEntladungYearMaxLast 11583
# 2025-02-13 21:59:04 statHomewattDay Min: 355 Avg: 3727 Max: 16052
# 2025-02-12 23:59:55 statHomewattDayLast Min: 486 Avg: 749 Max: 2970
# 2025-02-13 21:59:04 statHomewattDayMax 16052
# 2025-02-12 23:59:55 statHomewattDayMaxLast 2970
# 2025-02-13 21:59:04 statHomewattHour Min: 408 Avg: 5401 Max: 7657
# 2025-02-13 20:59:55 statHomewattHourLast Min: 367 Avg: 587 Max: 6764
# 2025-02-13 21:59:04 statHomewattHourMax 7657
# 2025-02-13 20:59:55 statHomewattHourMaxLast 6764
# 2025-02-13 21:59:04 statHomewattMonth Min: 0 Avg: 3069 Max: 18475
# 2025-01-31 23:59:55 statHomewattMonthLast Min: 0 Avg: 2857 Max: 16933
# 2025-02-13 21:59:04 statHomewattMonthMax 18475
# 2025-01-31 23:59:55 statHomewattMonthMaxLast 16933
# 2025-02-13 21:59:04 statHomewattYear Min: 0 Avg: 2920 Max: 18475
# 2024-12-31 23:59:55 statHomewattYearLast Min: 0 Avg: 1858 Max: 21626
# 2025-02-13 21:59:04 statHomewattYearMax 18475
# 2024-12-31 23:59:55 statHomewattYearMaxLast 21626
# 2025-02-13 21:59:04 statLadungDay Min: 0 Avg: 0 Max: 0
# 2025-02-12 23:59:55 statLadungDayLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statLadungDayMax 0
# 2025-02-12 23:59:55 statLadungDayMaxLast 0
# 2025-02-13 21:59:04 statLadungHour Min: 0 Avg: 0 Max: 0
# 2025-02-13 20:59:55 statLadungHourLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statLadungHourMax 0
# 2025-02-13 20:59:55 statLadungHourMaxLast 0
# 2025-02-13 21:59:04 statLadungMonth Min: 0 Avg: 344 Max: 8919
# 2025-01-31 23:59:55 statLadungMonthLast Min: 0 Avg: 118 Max: 8958
# 2025-02-13 21:59:04 statLadungMonthMax 8919
# 2025-01-31 23:59:55 statLadungMonthMaxLast 8958
# 2025-02-13 21:59:04 statLadungYear Min: 0 Avg: 184 Max: 8958
# 2024-12-31 23:59:55 statLadungYearLast Min: 0 Avg: 420 Max: 11469
# 2025-02-13 21:59:04 statLadungYearMax 8958
# 2024-12-31 23:59:55 statLadungYearMaxLast 11469
# 2025-02-13 21:59:04 statLeistungDay Min: 0 Avg: 1 Max: 36
# 2025-02-12 23:59:55 statLeistungDayLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statLeistungDayMax 36
# 2025-02-12 23:59:55 statLeistungDayMaxLast 0
# 2025-02-13 21:59:04 statLeistungHour Min: 0 Avg: 0 Max: 0
# 2025-02-13 20:59:55 statLeistungHourLast Min: 0 Avg: 0 Max: 0
# 2025-02-13 21:59:04 statLeistungHourMax 0
# 2025-02-13 20:59:55 statLeistungHourMaxLast 0
# 2025-02-13 21:59:04 statLeistungMonth Min: 0 Avg: 886 Max: 7865
# 2025-01-31 23:59:55 statLeistungMonthLast Min: 0 Avg: 402 Max: 8944
# 2025-02-13 21:59:04 statLeistungMonthMax 7865
# 2025-01-31 23:59:55 statLeistungMonthMaxLast 8944
# 2025-02-13 21:59:04 statLeistungYear Min: 0 Avg: 544 Max: 8944
# 2024-12-31 23:59:55 statLeistungYearLast Min: 0 Avg: 1835 Max: 20589 (since: 2024-07-10_13:02:47 )
# 2025-02-13 21:59:04 statLeistungYearMax 8944
# 2024-12-31 23:59:55 statLeistungYearMaxLast 20589
# 2024-07-10 13:02:28 statSunwattDay Min: 0 Avg: 2207 Max: 11295
# 2024-07-09 23:59:55 statSunwattDayLast Min: 0 Avg: 3047 Max: 8224
# 2024-07-10 13:01:27 statSunwattDayMax 11295
# 2024-07-09 23:59:55 statSunwattDayMaxLast 8224
# 2024-07-10 13:02:28 statSunwattHour Min: 6065 Avg: 8095 Max: 11272
# 2024-07-10 12:59:55 statSunwattHourLast Min: 3594 Avg: 5493 Max: 11295
# 2024-07-10 12:59:55 statSunwattHourMax 11272
# 2024-07-10 12:59:55 statSunwattHourMaxLast 11295
# 2024-07-10 13:02:28 statSunwattMonth Min: 0 Avg: 2214 Max: 13170
# 2024-06-30 23:59:55 statSunwattMonthLast Min: 0 Avg: 2398 Max: 13048
# 2024-07-10 13:00:28 statSunwattMonthMax 13170
# 2024-06-30 23:59:55 statSunwattMonthMaxLast 13048
# 2024-07-10 13:02:28 statSunwattYear Min: 0 Avg: 1454 Max: 13170
# 2023-12-31 23:59:55 statSunwattYearLast Min: 0 Avg: 1286 Max: 12632
# 2024-07-10 13:00:28 statSunwattYearMax 13170
# 2023-12-31 23:59:55 statSunwattYearMaxLast 12632
# 2025-02-13 10:48:31 state opened
# 2025-02-13 21:59:05 sun2wat -65536
# 2025-02-13 21:59:05 sun2wat2 -65536
# 2025-02-13 21:59:05 sun2watt 0
# 2025-02-13 21:59:05 sun2watt2 0
# 2025-02-13 21:59:04 sunwatt 0
# 2025-02-13 21:59:05 zusatzwatt 0
# REMEMBER:
# lid 1
# lname S10
# lrecv 1739480345.44747
# lsend 1739480345.44281
# UPDATECACHE:
# h40052:
# adr 40052
# len 16
# objCombi h40052
# reading seriennr
# span 16
# type h
# h40066:
# adr 40066
# len 2
# objCombi h40066
# reading sunwatt
# span 2
# type h
# h40068:
# adr 40068
# len 2
# objCombi h40068
# reading battwatt0
# span 2
# type h
# h40070:
# adr 40070
# len 2
# objCombi h40070
# reading homewatt0
# span 2
# type h
# h40072:
# adr 40072
# len 2
# objCombi h40072
# reading gridwatt0
# span 2
# type h
# h40074:
# adr 40074
# len 2
# objCombi h40074
# reading zusatzwatt
# span 2
# type h
# h40081:
# adr 40081
# len 1
# objCombi h40081
# reading ae
# span 1
# type h
# h40082:
# adr 40082
# len 1
# objCombi h40082
# reading battsoc
# span 1
# type h
# h40101:
# adr 40101
# len 1
# objCombi h40101
# reading s1_p
# span 1
# type h
# h40102:
# adr 40102
# len 1
# objCombi h40102
# reading s2_p
# span 1
# type h
# defptr:
# S10 1
# gotReadings:
# s2_p 0
# helper:
# _98_statistics StatDevice_S10
# lastRead:
# h40052 1739480344.48043
# h40066 1739480344.58921
# h40068 1739480344.69903
# h40070 1739480344.80699
# h40072 1739480344.9127
# h40074 1739480345.0226
# h40081 1739480345.1285
# h40082 1739480345.2355
# h40101 1739480345.34035
# h40102 1739480345.44815
Die Addition mache ich folgendermaßen. Hier ein Beispiel für den Solarertrag.
Das geht sicher viel elganter aber es funktioniert und ich habe die Werte für die zwei direkt anbeschlossenen Strings und einen weiteren Wechselrichter.
define Solaranlage_Solarertrag_Fortlaufend_Doif DOIF (["S10:Leistung"])\
( \
{\
use Math::Round qw/round/;;\
my $Leistung = ReadingsNum("S10","Leistung","0")/180;;\
my $Leistung_s1_p = ReadingsNum("S10","s1_p","0")/180;;\
my $Leistung_s2_p = ReadingsNum("S10","s2_p","0")/180;;\
my $Leistung_Extern = ReadingsNum("S10","sun2watt2","0")/180;;\
\
my $Ertrag_Fortlaufend = ReadingsNum("S10","Ertrag_Fortlaufend_Test","0");;\
my $Ertrag_Fortlaufend_s1_p = ReadingsNum("S10","Ertrag_Fortlaufend_s1_p","0");;\
my $Ertrag_Fortlaufend_s2_p = ReadingsNum("S10","Ertrag_Fortlaufend_s2_p","0");;\
my $Ertrag_Fortlaufend_Extern = ReadingsNum("S10","Ertrag_Fortlaufend_Extern","0");;\
\
$Ertrag_Fortlaufend = $Ertrag_Fortlaufend + $Leistung;;\
$Ertrag_Fortlaufend_s1_p = $Ertrag_Fortlaufend_s1_p + $Leistung_s1_p;;\
$Ertrag_Fortlaufend_s2_p = $Ertrag_Fortlaufend_s2_p + $Leistung_s2_p;;\
$Ertrag_Fortlaufend_Extern = $Ertrag_Fortlaufend_Extern + $Leistung_Extern;;\
\
$Ertrag_Fortlaufend = Math::Round::nearest(0.01, $Ertrag_Fortlaufend);;\
$Ertrag_Fortlaufend_s1_p = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_s1_p);;\
$Ertrag_Fortlaufend_s2_p = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_s2_p);;\
$Ertrag_Fortlaufend_Extern = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_Extern);;\
\
fhem ("setReading S10 Ertrag_Fortlaufend_Test $Ertrag_Fortlaufend");;\
fhem ("setReading S10 Ertrag_Fortlaufend_s1_p $Ertrag_Fortlaufend_s1_p");;\
fhem ("setReading S10 Ertrag_Fortlaufend_s2_p $Ertrag_Fortlaufend_s2_p");;\
fhem ("setReading S10 Ertrag_Fortlaufend_Extern $Ertrag_Fortlaufend_Extern");;\
}\
)\
\
DOELSEIF ([00:00])\
(\
setReading S10 Ertrag_Fortlaufend_Test 0;;\
setReading S10 Ertrag_Fortlaufend_s1_p 0;;\
setReading S10 Ertrag_Fortlaufend_s2_p 0;;\
setReading S10 Ertrag_Fortlaufend_Extern 0\
)
attr Solaranlage_Solarertrag_Fortlaufend_Doif cmdpause 5
attr Solaranlage_Solarertrag_Fortlaufend_Doif do always
attr Solaranlage_Solarertrag_Fortlaufend_Doif room Solaranlage
attr Solaranlage_Solarertrag_Fortlaufend_Doif verbose 1
# DEF (["S10:Leistung"])
# (
# {
# use Math::Round qw/round/;
# my $Leistung = ReadingsNum("S10","Leistung","0")/180;
# my $Leistung_s1_p = ReadingsNum("S10","s1_p","0")/180;
# my $Leistung_s2_p = ReadingsNum("S10","s2_p","0")/180;
# my $Leistung_Extern = ReadingsNum("S10","sun2watt2","0")/180;
#
# my $Ertrag_Fortlaufend = ReadingsNum("S10","Ertrag_Fortlaufend_Test","0");
# my $Ertrag_Fortlaufend_s1_p = ReadingsNum("S10","Ertrag_Fortlaufend_s1_p","0");
# my $Ertrag_Fortlaufend_s2_p = ReadingsNum("S10","Ertrag_Fortlaufend_s2_p","0");
# my $Ertrag_Fortlaufend_Extern = ReadingsNum("S10","Ertrag_Fortlaufend_Extern","0");
#
# $Ertrag_Fortlaufend = $Ertrag_Fortlaufend + $Leistung;
# $Ertrag_Fortlaufend_s1_p = $Ertrag_Fortlaufend_s1_p + $Leistung_s1_p;
# $Ertrag_Fortlaufend_s2_p = $Ertrag_Fortlaufend_s2_p + $Leistung_s2_p;
# $Ertrag_Fortlaufend_Extern = $Ertrag_Fortlaufend_Extern + $Leistung_Extern;
#
# $Ertrag_Fortlaufend = Math::Round::nearest(0.01, $Ertrag_Fortlaufend);
# $Ertrag_Fortlaufend_s1_p = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_s1_p);
# $Ertrag_Fortlaufend_s2_p = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_s2_p);
# $Ertrag_Fortlaufend_Extern = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_Extern);
#
# fhem ("setReading S10 Ertrag_Fortlaufend_Test $Ertrag_Fortlaufend");
# fhem ("setReading S10 Ertrag_Fortlaufend_s1_p $Ertrag_Fortlaufend_s1_p");
# fhem ("setReading S10 Ertrag_Fortlaufend_s2_p $Ertrag_Fortlaufend_s2_p");
# fhem ("setReading S10 Ertrag_Fortlaufend_Extern $Ertrag_Fortlaufend_Extern");
# }
# )
#
#DOELSEIF ([00:00])
# (
# setReading S10 Ertrag_Fortlaufend_Test 0;
# setReading S10 Ertrag_Fortlaufend_s1_p 0;
# setReading S10 Ertrag_Fortlaufend_s2_p 0;
# setReading S10 Ertrag_Fortlaufend_Extern 0
# )
# FUUID 6331b829-f33f-a551-4c86-8035c752bcf33a83
# MODEL FHEM
# NAME Solaranlage_Solarertrag_Fortlaufend_Doif
# NOTIFYDEV global,.*(S10).*
# NR 595
# NTFY_ORDER 50-Solaranlage_Solarertrag_Fortlaufend_Doif
# STATE cmd_1
# TYPE DOIF
# VERSION 29460 2024-12-29 20:25:48
# eventCount 691
# READINGS:
# 2025-02-13 22:02:04 Device S10
# 2025-02-13 22:02:04 cmd 1
# 2025-02-13 22:02:04 cmd_event S10
# 2025-02-13 22:02:04 cmd_nr 1
# 2025-02-12 13:23:03 mode enabled
# 2025-02-13 22:02:04 state cmd_1
# 2025-02-13 10:48:22 timer_01_c02 14.02.2025 00:00:00
# Regex:
# accu:
# bar:
# barAvg:
# collect:
# cond:
# :
# 0:
# "S10:Leistung" S10:Leistung
# attr:
# cmdState:
# cmdpause:
# 5
# wait:
# waitdel:
# condition:
# 0 ::EventDoIf('S10',$hash,'Leistung',0)
# 1 ::DOIF_time_once($hash,0,$wday)
# days:
# do:
# 0:
# 0 { use Math::Round qw/round/; my $Leistung = ReadingsNum("S10","Leistung","0")/180; my $Leistung_s1_p = ReadingsNum("S10","s1_p","0")/180; my $Leistung_s2_p = ReadingsNum("S10","s2_p","0")/180; my $Leistung_Extern = ReadingsNum("S10","sun2watt2","0")/180; my $Ertrag_Fortlaufend = ReadingsNum("S10","Ertrag_Fortlaufend_Test","0"); my $Ertrag_Fortlaufend_s1_p = ReadingsNum("S10","Ertrag_Fortlaufend_s1_p","0"); my $Ertrag_Fortlaufend_s2_p = ReadingsNum("S10","Ertrag_Fortlaufend_s2_p","0"); my $Ertrag_Fortlaufend_Extern = ReadingsNum("S10","Ertrag_Fortlaufend_Extern","0"); $Ertrag_Fortlaufend = $Ertrag_Fortlaufend + $Leistung; $Ertrag_Fortlaufend_s1_p = $Ertrag_Fortlaufend_s1_p + $Leistung_s1_p; $Ertrag_Fortlaufend_s2_p = $Ertrag_Fortlaufend_s2_p + $Leistung_s2_p; $Ertrag_Fortlaufend_Extern = $Ertrag_Fortlaufend_Extern + $Leistung_Extern; $Ertrag_Fortlaufend = Math::Round::nearest(0.01, $Ertrag_Fortlaufend); $Ertrag_Fortlaufend_s1_p = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_s1_p); $Ertrag_Fortlaufend_s2_p = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_s2_p); $Ertrag_Fortlaufend_Extern = Math::Round::nearest(0.01, $Ertrag_Fortlaufend_Extern); fhem ("setReading S10 Ertrag_Fortlaufend_Test $Ertrag_Fortlaufend"); fhem ("setReading S10 Ertrag_Fortlaufend_s1_p $Ertrag_Fortlaufend_s1_p"); fhem ("setReading S10 Ertrag_Fortlaufend_s2_p $Ertrag_Fortlaufend_s2_p"); fhem ("setReading S10 Ertrag_Fortlaufend_Extern $Ertrag_Fortlaufend_Extern"); }
# 1:
# 0 setReading S10 Ertrag_Fortlaufend_Test 0; setReading S10 Ertrag_Fortlaufend_s1_p 0; setReading S10 Ertrag_Fortlaufend_s2_p 0; setReading S10 Ertrag_Fortlaufend_Extern 0
# 2:
# helper:
# NOTIFYDEV global,.*(S10).*
# event Leistung: 0
# globalinit 1
# last_timer 1
# sleeptimer -1
# timerdev S10
# timerevent Leistung: 0
# triggerDev S10
# timerevents:
# sun2wat: -65536
# sun2wat2: -65536
# sun2watt: 0
# sun2watt2: 0
# Leistung: 0
# Ertrag_Fortlaufend_Test: 6.7
# timereventsState:
# sun2wat: -65536
# sun2wat2: -65536
# sun2watt: 0
# sun2watt2: 0
# Leistung: 0
# Ertrag_Fortlaufend_Test: 6.7
# triggerEvents:
# sun2wat: -65536
# sun2wat2: -65536
# sun2watt: 0
# sun2watt2: 0
# Leistung: 0
# Ertrag_Fortlaufend_Test: 6.7
# triggerEventsState:
# sun2wat: -65536
# sun2wat2: -65536
# sun2watt: 0
# sun2watt2: 0
# Leistung: 0
# Ertrag_Fortlaufend_Test: 6.7
# internals:
# intervalfunc:
# localtime:
# 0 1739487600
# perlblock:
# readings:
# realtime:
# 0 00:00:00
# time:
# 0 00:00:00
# timeCond:
# 0 1
# timer:
# 0 0
# timers:
# 1 0
# trigger:
# triggertime:
# 1739487600:
# localtime 1739487600
# hash:
# uiState:
# uiTable:
Grüße
Jens
Danke für den Code.
Ein ganz schöner Brocken den ich erstmal verstehen muss.
Ich hab mich jetzt erstmal mit der integral Ermittlung begnügt. Mal gucken wie genau die ist.
Andere Frage:
Durch mein ganzes Ausprobieren habe ich wohl alles ziemlich durcheinander gebracht.
Meine PV Erzeugung wird in der Balkengraphik nicht mehr angezeigt und mein kompletter Tagesverbrauch wird auf eine Stunde vorhergesagt.
Kann ich irgendwie alle Hintergrunddaten löschen und quasi von null anfangen ohne meine Grundeinrichtung zu zerstören?
Ich hab schon alles Resets durchgeführt. Die alten Werte kommen aber zurück.
Danke!
VG,
Heiko
Edit: Muss ich vielleicht einfach nur warten und geduldiger sein? 8)
Hallo Heiko,
naja man könnte jetzt analysieren wo man was richten muß um die Daten zu bereinigen.
Die einfache Methode wäre ein "set .. reset pvHistory" und ein "set .. reset consumption".
Aber wenn man am Anfang steht kannst du auch so mit einer Neuanlage vorgehen:
- 1. du sicherst die Konfiguration mit "set ... plantConfiguration save"
- 2. Es entsteht dadurch ein File ../fhem/FHEM/FhemUtils/PVCfg_SolarForecast_<name> (das wird auch täglich automatisch angelegt)
- 3. Wichtig ... du benennst dieses File um in z.B. PVCfg_SolarForecast_<name>.bak
- 4. du löscht dein SF-Device
- 5. du legst dein SF-Device mit dem gleichen Namen! wieder neu an. Den Abfragedialog gehst du nicht durch sondern machst ...
- 6. kopieren des File PVCfg_SolarForecast_<name>.bak auf PVCfg_SolarForecast_<name>
- 7. mit "set ... plantConfiguration restore" holst du dir die gesicherte Konfig wieder ins Device
(siehe auch den Teil im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Backup_und_Wiederherstellung_der_Moduldaten))
Allerdings wird warten auch funktionieren. ;)
Bzw. kann man die meisten Daten auch selektiv löschen, muß sie nur vorher etwas analysieren.
Grüße,
Heiko
Hallo Heiko,
danke für die Anleitung.
Ich setze vorab auf warten.
Ich möchte sowieso noch ein paar consumer einfügen und an der grafischen Ausgabe etwas feintunen.
Da mach ich bestimmt noch das eine oder andere bei kaputt 8)
Schönes Wochenende!
VG,
Heiko
Hallo zusammen,
gibt es eine "Standard-Vorgehensweise" für den folgenden Fall:
Ich habe eine Wallbox und der Verbrauch würde in den Consumption laufen.
Das würde nach meinem Verständnis die Voraussage des Verbrauchs eher stören.
Für mich ist im Wesentlichen interessant, ob ich meinen normalen Verbrauch decken kann.
Wenn nicht, dann würde ich mit einem dynamischen Tarif meinen Speicher 1-2 Mal am Tag laden wollen.
Den Wagen lade ich im Sommer über den Überschuss und sonst zu den günstigen Stunden aus dem Netz.
Wie würde sich der Verbauch der Wallbox am besten aus der Prognbose der Consumption nehmen lassen?
Oder gibt es eine andere/bessere Lösung?
Danke Euch vorab und schöne Grüße
Dirk
Hallo Dirk,
wenn die Wallbox als Verbraucher im SF registriert ist und die Verbrauchswerte der Wallbox erfasst, dann kannst du den Schlüssel exconfc im Consumer-Attr die Verbrauchswerte (weitgehend) von der Prognose ausschließen lassen.
Zu der Consumer Steuerung muss ich noch sehr viel im Wiki beschreiben, aber wer ab und zu reinschaut sieht dass es sich immer weiter aufbaut.
LG
Zitat von: kask am 13 Februar 2025, 21:09:33@tomcat.x
Darf man mal Fragen warum..
..du das machen möchest?
Ja, sorry, da hätte ich gerade hier im SolarForecast-Thema "Akku" wohl etwas ausführlicher erklären sollen. Es geht nicht um einen Akku im Zusammenhang mit der Solar-Anlage. Den würde man ja eigentlich immer (mit Ausnahmen) laden wollen, weil er auch täglich (nachts) entladen wird.
Mir geht es um akkubetriebene Haushaltsgeräte ohne intelligente Ladesteuerung und ohne Übermittlung des Akkustands. Ich habe da schlechte Erfahrungen damit gemacht, die ständig am Strom zu haben und auf 100% zu quälen. Beispielsweise lade ich auch die Tablets mit dem Floorplan nicht ständig, sondern nur bei Bedarf. Die brauchen aber in der Regel zumindest einmal am Tag eine Ladung, das würde noch funktionieren. Als Beispiel für den Anwendungsfall, wegen dem ich gefragt habe, könne man einen Akkusauger nehmen. Der wird alle paar Tage mal benutzt und einmal die Woche möchte ich den laden. Momentan nutze ich dafür einen Wochen-Timer ohne Berücksichtigung der Solar-Produktion. In Summe (mit anderen Geräten) geht es zwar nur um ein paar Wh, aber es wäre trotzdem schön, das bei Überschuss zu machen, anstatt den zu verschenken.
ZitatMir geht es um akkubetriebene Haushaltsgeräte ohne intelligente Ladesteuerung und ohne Übermittlung des Akkustands. Ich habe da schlechte Erfahrungen damit gemacht, die ständig am Strom zu haben und auf 100% zu quälen.
Dem kann ich zustimmen und habe deshalb die relevanten Geräte im SF registriert und lasse sie derart steuern, dass der Akku zwischen den von mir gewählten min/max SoC-Grenzen ständig pendelt.
Die Consumer Konfig sieht zum Beispiel so aus:
deCONZ_HUEDevice1:Tablet+Flur
type=charger power=0 icon=tablet pcurr=power:W etotal=consumption:Wh auto=automatic
on=on off=off mintime=1430
interruptable=samsunggalaxy.fully:batterylevel:[4-9][0-9]|[0-9]{3}:50
Die dazu gehörige Ladecharakteristik zeigt das SVG im Anhang.
Durch die Angabe power=0 wird ein evtl. nicht vorhandener PV-Überschuß ignoriert. Kann man anpassen, aber bei den paar Watt war mir dieser Fakt nicht so wichtig da meine Hausanlage ohnehin über Bat gepuffert ist.
Edit: Ohne Übermittlung des Akkustandes könnte die Consumersteuerung so aussehen:
tplink.plug1
icon=batterie type=charger power=10 mode=must notbefore=07 mintime=300
on=on off=off
auto=automatic
Hier wird der PV Überschuß berücksichtigt und eine Soll-Ladezeit (mintime) pro Tag veranschlagt, die den Erfahrungswerten entsprechend ausreicht um das Gerät bei Bedarf einsatzbereit zu haben. Das 3. SVG zeigt einen Tagesverlauf.
LG
Hallo zusammen,
zur Zeit ist die V 1.46.0 in Vorbereitung.
Unter Anderem ist im plantConfiguration Check die Prüfung des pvHistory Key "con" eingebaut.
Ein Ergebnis dieser Prüfung seht ihr im Anhang. Im Logfile gibt es dazu den korrespondierenden Eintrag
2025.02.15 11:05:45.307 1: SolCast - WARNING - The stored Energy consumption of day/hour 11/01 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast reset consumption 11 01'.
Durch diese Änderung werden evtl. nervende Dauereinträge im Logfile entfernt und der User wird gezielt auf das Problem aufmerksam gemacht und kann sich in Ruhe der Lösung widmen.
Weiterhin wird die Verbrauchsprognose über den Median von bis zu 180 historischen Tagen (bei Bedarf auch mehr) berechnet werden können. Der default wird wahrscheinlich bei 60 Tagen liegen um den langsamen Wechsel zwischen Winter und Sommerhalbjahr, der sich auch im Energieverbrauch auswirken wird, in der Verbrauchsprognose abbilden zu können.
Ich bin mit den Weiterentwicklungen diesbezüglich noch nicht durch und halte euch auf dem Laufenden.
LG,
Heiko
Zitat von: DS_Starter am 14 Februar 2025, 12:13:24Hallo Dirk,
wenn die Wallbox als Verbraucher im SF registriert ist und die Verbrauchswerte der Wallbox erfasst, dann kannst du den Schlüssel exconfc im Consumer-Attr die Verbrauchswerte (weitgehend) von der Prognose ausschließen lassen.
Zu der Consumer Steuerung muss ich noch sehr viel im Wiki beschreiben, aber wer ab und zu reinschaut sieht dass es sich immer weiter aufbaut.
LG
Prima, Danke Dir, im Wiki ist das Attribut erwähnt, ich hatte es nicht richtig interpretiert.
Eine optische Frage habe ich noch - hat also keine Prio, ist halt nur Optik.
Für die Balkengrafik lässt die Einheit mit dem Attribut graphicEnergyUnit definieren.
Gibt es das auch für die Energieflußgrafik?
Gesucht hatte ich in der flowGraphicControl, aber es gibt keinen passenden Schlüssel?
Danke vorab und schöne Grüße
Dirk
Hallo Dirk,
ZitatFür die Balkengrafik lässt die Einheit mit dem Attribut graphicEnergyUnit definieren.
Gibt es das auch für die Energieflußgrafik?
Nein, dort wird derzeit alles in W/Wh ausgegeben. Es ist ein wenig schwierig für alle beteiligten Geräte identisch nach kW/kWh zu wechseln. Verbraucher haben teilweise nur unter 100 W Verbrauch. Dort stehen dann z.B. 49 (W). Bei einem generellen Wechsel nach kW würden dort 0.049 stehen, wohingegen ein Wechselrichter statt 9200 (W) 9.2 (kW) anzeigen würde.
Was ich damit sagen will ... es wird nicht für alle Fälle den idealen Weg der Darstellung geben. Die einzelnen Komponenten mit unterschiedlichen Einheiten darzustellen, halte ich auch für keine gute Lösung weil es zur Verwirrung beiträgt.
Hast du einen speziellen UseCase der bei dir diese Frage aufwirft oder war sie allgemeiner Natur?
Grüße,
Heiko
Der UseCase ergibt sich bei mir aus entsprechend großen Verbrauchern.
Einer Wärmepumpe (2-3 kW) und einer Wallbox (22 kW). Dann werden die Zahlenwerte in der Grafik recht groß. Mein Hauskraftwerk (E3/DC) wechselt je nach Größe des Verbrauchs zwischen W und kW.
Das ist aber alles nice-to-have, das Modul ist schon super so!
Lässt sich eigentlich der prognostizierte Verbrauch analog der PV-Prognose als Balkendiagramm darstellen? Über graphicBeam3Content? Gibt es dazu vielleicht ein Beispiel?
Hintergrund: die Prognose für den Verbrauch passt noch nicht (Modul läuft aber auch erst seit 2 Tagen) und mit der Graik liesse sich besser kontrollieren.
ZitatDer UseCase ergibt sich bei mir aus entsprechend großen Verbrauchern.
Einer Wärmepumpe (2-3 kW) und einer Wallbox (22 kW). Dann werden die Zahlenwerte in der Grafik recht groß. Mein Hauskraftwerk (E3/DC) wechselt je nach Größe des Verbrauchs zwischen W und kW.
Ok, verstehe ich. Ich denke mal darüber nach ...
ZitatLässt sich eigentlich der prognostizierte Verbrauch analog der PV-Prognose als Balkendiagramm darstellen? Über graphicBeam3Content? Gibt es dazu vielleicht ein Beispiel?
Ja. Verwende ich bei mir. Wird einfach z.Bsp. so definiert in der zweiten Ebene:
attr ... graphicBeam3Content consumptionForecast
attr ... graphicBeam4Color FF1F78
attr ... graphicBeam4Content consumption
attr ... graphicShowDiff bottom
Damit wird in der zweiten Ebene sowohl die Verbrauchsprognose als auch der reale Verbrauch dargestellt und gleichzeitig noch die Differenz zwischen beiden Werten. Das gilt dann auch für die Ebene 1 wenn es nicht stört.
Perfekt, habe ich so übernommen. Vielen Dank für die schnelle Unterstützung!!!
Aktuell sind meine Verbrauchswerte GridConsumption für die Stunden alle auf Null.
Wie kann ich am Besten ,,debuggen"?
Die Werte aus dem Device scheinen beim manuellen Abgleich zu stimmen...
Siehe auch Wiki ;)
.....Zur Laufzeit bekommt man mit dem Attribut :
ctrlDebug=collectData
einen Einblick in die Verbrauchsermittlung bei jedem Zyklus und kann so die Eingangswerte und das daraus resultierende Ergebnis im FHEM Log nachverfolgen....
...
2024.11.28 11:38:20.080 1: SolCast DEBUG> EnergyConsumption input -> PV: 96, PP: 0, GridIn: 0, GridCon: 582, BatIn: 5, BatOut: 0
2024.11.28 11:38:20.081 1: SolCast DEBUG> EnergyConsumption result -> 673 Wh
...
Gruß
300P
Danke für den Hinweis.
Und ja, ich muss mir das umfangreiche Wiki nochmal im Detail ansehen, sorry.
Es ist zwar ein wenig anderer Kontext, aber lies mal hier:
https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Hinweise_zur_Fehlersuche
ctrlDebug=collectData
ist hier der erste Schritt um zu sehen was "rein" kommt.
Dann wäre das der relevante Input, richtig?
DEBUG> collect Meter data - device: e3dc_s10Pro =>
2025.02.16 21:34:41 1: PV_Forecast DEBUG> gcon: 370 W, gfeedin: 0 W, contotal: 14210 Wh, feedtotal: 80 Wh
2025.02.16 21:34:41 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.16 21:34:41 1: PV_Forecast DEBUG> pin=0 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 8
2025.02.16 21:34:41 1: PV_Forecast DEBUG> EnergyConsumption input -> PV: 0, PP: 0, GridIn: 0, GridCon: 0, BatIn: 0, BatOut: 0
2025.02.16 21:34:41 1: PV_Forecast DEBUG> EnergyConsumption result -> 0 Wh
Am Ende des Zyklus (wie von dir dargestellt) steht das Gesuchte:
Logauszug.....:
...
...
...
2025.02.16 22:04:33 1: Forecast DEBUG> collect Producer 01 data - device: MB_USRW610_004 =>
2025.02.16 22:04:33 1: Forecast DEBUG> pcurr: 759 W, etotal: 12013101 Wh
2025.02.16 22:04:33 1: Forecast DEBUG> collect Meter data - device: SMA_Energymeter =>
2025.02.16 22:04:33 1: Forecast DEBUG> gcon: 9.7 W, gfeedin: 0 W, contotal: 780427.2 Wh, feedtotal: 2971166.1 Wh
...
...
Bei Dir steht leider kein fortlaufender Zählerstand als Eintrag - dann wird auch nicht gerechnet / gezählt - prüfe mal das Device / Reading dazu genauestens
EDIT:
Lass einmal es ohne Einschränkung der Device mit laufen ( ->> ctrlDebug collectData)
Gruß
300P
In der nächsten Version habe ich die DEBUG-Ausgabe noch etwas erweitert:
...
2025.02.16 22:57:02.589 1: SolCast DEBUG> collect Inverter 01 data - device: MySTP_5000, delivery: default =>
2025.02.16 22:57:02.591 1: SolCast DEBUG> pv: 0 W, etotal: 63517742 Wh
2025.02.16 22:57:02.593 1: SolCast DEBUG> summary data of all Inverters - pv: 0 W, this hour Generation: 0 Wh
2025.02.16 22:57:02.602 1: SolCast DEBUG> collect Producer 03 data - device: WindWheel =>
2025.02.16 22:57:02.604 1: SolCast DEBUG> pcurr: 0 W, etotal: 350 Wh
2025.02.16 22:57:02.605 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2025.02.16 22:57:02.607 1: SolCast DEBUG> gcon: 42.5 W, gfeedin: 0 W, contotal: 925082.7 Wh, feedtotal: 2639799.2 Wh
2025.02.16 22:57:02.609 1: SolCast DEBUG> write to pvHistory - day: 16, hod: 23, GridConsumption (gcons): 23 Wh
...
In der letzten Zeile sieht man welchen gcons-Wert das Modul berechnet und weggeschrieben hat.
LG
Zitat von: 300P am 16 Februar 2025, 22:13:16Bei Dir steht leider kein fortlaufender Zählerstand als Eintrag - dann wird auch nicht gerechnet / gezählt - prüfe mal das Device / Reading dazu genauestens
EDIT:
Lass einmal es ohne Einschränkung der Device mit laufen ( ->> ctrlDebug collectData)
Gruß
300P
Danke fürs Helfen. Die Readings kontrolliere ich nochmal und melde mich. Der Debug lief ohne Einschränkung, ich wollte nur hier nicht zu viele unnötige Infos posten.
Was wäre denn noch relevant, dann liefere ich die Infos noch nach?
Zitat von: DS_Starter am 16 Februar 2025, 23:00:50In der nächsten Version habe ich die DEBUG-Ausgabe noch etwas erweitert:
...
In der letzten Zeile sieht man welchen gcons-Wert das Modul berechnet und weggeschrieben hat.
LG
Super, soll ich lieber auf die Version warten?
Guten Morgen,
wenn du magst, kannst du die V 1.46.0 aus meinem contrib ziehen und FHEM danach restarten!
Sie muß zwar noch etwas getestet werden, aber zeigt bisher keine Fehler.
ZitatWas wäre denn noch relevant, dann liefere ich die Infos noch nach?
Du könntest uns für einen besseren Überblick diese Zeile der Debug-Ausgabe:
2025.02.16 22:57:02.607 1: SolCast DEBUG> gcon: 42.5 W, gfeedin: 0 W, contotal: 925082.7 Wh, feedtotal: 2639799.2 Whüber einen längeren Zeitraum, vllt. 2 Stunden, aus dem Log herauskopieren und zusammenstellen. Es muß jetzt nicht jede Zeile im Abstand von 2 Minuten sein, aber im Abstand von ca. 10 Minuten über einen Zeitraum von 2 Stunden oder etwas mehr wenn das geht wäre für uns hilfreich.
Hier mal meine Definition im Forecast und die Verbrauchsreadings aus dem Hauskraftwerk.
Der fortlaufende Zähler wird pro Tag genullt, das ist aber ja laut Doku kein Problem?!?
Definition PV Forecast
consumer01 e3dc_s10Pro:Wallbox type=noSchedule power=22000 icon=wallbox pcurr=Wallbox_TotalPower:W etotal=Wallbox_TotalEnergy:Wh noshow=2 exconfc=1
disable 0
event-on-change-reading *
graphicBeam3Content consumptionForecast
graphicBeam4Color FF1F78
graphicBeam4Content consumption
graphicEnergyUnit kWh
graphicHistoryHour 11
graphicShowDiff bottom
graphicShowNight 1
setupBatteryDev01 e3dc_s10Pro pin=Battery_Power:W pout=-pin cap=13110 charge=Battery_SOC
setupInverterDev01 e3dc_s10Pro pv=Solar_Power:W etotal=PVI_Energy_Total:Wh capacity=12000 strings=NW,SO limit=70
setupInverterStrings NW,SO
setupMeterDev e3dc_s10Pro gcon=Grid_Power_Out:W contotal=Grid_Today_EnergyOut:kWh gfeedin=Grid_Power_In:W feedtotal=Grid_Today_EnergyIn:kWh
setupRadiationAPI OpenMeteoDWD-API
setupStringPeak NW=5.4 SO=3.24
setupWeatherDev1 OpenMeteoDWD-API
Readings aus dem Hauskraftwerk (NAME e3dc_s10Pro)
Grid_Power_Out 14 2025-02-17 09:18:24
Grid_Power_In 4 2025-02-17 09:18:24
Grid_Today_EnergyIn 0.03 2025-02-17 09:00:04
Grid_Today_EnergyOut 11.84 2025-02-17 09:15:14
Und hier noch die Zeilen aus dem Debug, gegen Ende habe ich gekürzt und die letzte Zeile genommen, bevor ich abgeschaltet habe (zu erkennen an den Punkten vor der letzten Zeile):
2025.02.16 21:03:11 1: PV_Forecast DEBUG> gcon: 2252 W, gfeedin: 0 W, contotal: 12950 Wh, feedtotal: 80 Wh
2025.02.16 21:04:21 1: PV_Forecast DEBUG> gcon: 2240 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:05:31 1: PV_Forecast DEBUG> gcon: 2243 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:06:41 1: PV_Forecast DEBUG> gcon: 2246 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:07:51 1: PV_Forecast DEBUG> gcon: 2080 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:09:01 1: PV_Forecast DEBUG> gcon: 2096 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:10:11 1: PV_Forecast DEBUG> gcon: 2085 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:11:21 1: PV_Forecast DEBUG> gcon: 2081 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:12:31 1: PV_Forecast DEBUG> gcon: 2078 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:13:41 1: PV_Forecast DEBUG> gcon: 2080 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
2025.02.16 21:14:51 1: PV_Forecast DEBUG> gcon: 2082 W, gfeedin: 0 W, contotal: 13510 Wh, feedtotal: 80 Wh
.....
2025.02.16 21:38:11 1: PV_Forecast DEBUG> gcon: 371 W, gfeedin: 0 W, contotal: 14210 Wh, feedtotal: 80 Wh
Ich glaube das ist nur ein Anzeigeproblem.
1. zeige uns bitte noch ein komplettes List vom SF-Device
2. stelle das Attr graphicEnergyUnit auf Wh
Der Netzbezug liegt bei 1,5 - 2 kWh pro Stunde. Das könnte in der Grafik wegen der Größenverhältnisse untergehen.
Hallo - habe am Wochenende ein update gemacht - danach hing mein fhem in einer Endlosschleife.
Wenn ich das SolarForecast-Modul deaktiviere läuft fhem wieder. In der Log finde ich diesen Eintrag:
Forecast - all registered consumers collected
Can't use an undefined value as an ARRAY reference at ./FHEM/76_SolarForecast.pm line 12190.
Was könnte das sein?
ZitatWas könnte das sein?
Das ist ein Programmfehler wegen eines (bei dir) nicht vorhandenen Elements.
Den Fehler muß ich beseitigen.
LG,
Heiko
Ich habe das Modul in meinem Contrib upgedatet und den Fehler (hoffentlich) beseitigt.
Du/ihr könnt die Datei in euer FHEM-Verzeichnis herunterladen und FHEM neu starten.
Danach bitte testen ob wieder i.O.
LG
Zitat von: DS_Starter am 17 Februar 2025, 09:54:15Ich glaube das ist nur ein Anzeigeproblem.
1. zeige uns bitte noch ein komplettes List vom SF-Device
2. stelle das Attr graphicEnergyUnit auf Wh
Der Netzbezug liegt bei 1,5 - 2 kWh pro Stunde. Das könnte in der Grafik wegen der Größenverhältnisse untergehen.
Hier das List:
define PV_Forecast SolarForecast
attr PV_Forecast consumer01 e3dc_s10Pro:Wallbox type=noSchedule power=22000 icon=wallbox pcurr=Wallbox_TotalPower:W etotal=Wallbox_TotalEnergy:Wh noshow=2 exconfc=1
attr PV_Forecast disable 0
attr PV_Forecast event-on-change-reading .*
attr PV_Forecast graphicBeam3Content consumptionForecast
attr PV_Forecast graphicBeam4Color FF1F78
attr PV_Forecast graphicBeam4Content consumption
attr PV_Forecast graphicEnergyUnit kWh
attr PV_Forecast graphicHistoryHour 11
attr PV_Forecast graphicShowDiff bottom
attr PV_Forecast graphicShowNight 1
attr PV_Forecast room PV
attr PV_Forecast setupBatteryDev01 e3dc_s10Pro pin=Battery_Power:W pout=-pin cap=13110 charge=Battery_SOC
attr PV_Forecast setupInverterDev01 e3dc_s10Pro pv=Solar_Power:W etotal=PVI_Energy_Total:Wh capacity=12000 strings=NW,SO limit=70
attr PV_Forecast setupInverterStrings NW,SO
attr PV_Forecast setupMeterDev e3dc_s10Pro gcon=Grid_Power_Out:W contotal=Grid_Today_EnergyOut:kWh gfeedin=Grid_Power_In:W feedtotal=Grid_Today_EnergyIn:kWh
attr PV_Forecast setupRadiationAPI OpenMeteoDWD-API
attr PV_Forecast setupStringPeak NW=5.4 SO=3.24
attr PV_Forecast setupWeatherDev1 OpenMeteoDWD-API
attr PV_Forecast verbose 2
# FUUID 67ab5414-f33f-ae8f-4a76-de2d24ddb828f4ea
# FVERSION 76_SolarForecast.pm:v1.45.6-s29652/2025-02-12
# LCACHEFILE last write time: 10:48:07 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 10:55:05
# MODEL OpenMeteoDWDAPI
# NAME PV_Forecast
# NOTIFYDEV e3dc_s10Pro,e3dc_s10Pro:Wallbox
# NR 337
# NTFY_ORDER 50-PV_Forecast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL OpenMeteoDWDAPI
# eventCount 11774
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV PV_Forecast
# SPGROOM
# VERSION 1.45.6
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 14059
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:27243
# telnet telnetForBlockingFn_1739459812.62355_127.0.0.1_44344
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name PV_Forecast
# tsnext 1739792277.53391
# OLDREADINGS:
# READINGS:
# 2025-02-17 10:53:55 Battery_ChargeRecommended_01 1
# 2025-02-17 10:53:55 Current_AutarkyRate 100 %
# 2025-02-17 10:53:55 Current_BatCharge_01 32 %
# 2025-02-17 10:53:55 Current_Consumption 1798 W
# 2025-02-17 10:53:55 Current_GridConsumption 0 W
# 2025-02-17 10:53:55 Current_GridFeedIn 5 W
# 2025-02-17 10:53:55 Current_PV 2841 W
# 2025-02-17 10:53:55 Current_PowerBatIn_01 1038 W
# 2025-02-17 10:53:55 Current_PowerBatOut_01 0 W
# 2025-02-17 10:53:55 Current_SelfConsumption 1798 W
# 2025-02-17 10:53:55 Current_SelfConsumptionRate 63 %
# 2025-02-17 10:53:55 Current_Surplus 1043 W
# 2025-02-17 10:00:00 LastHourGridconsumptionReal 0 Wh
# 2025-02-17 10:00:00 LastHourPVforecast 1964 Wh
# 2025-02-17 10:00:00 LastHourPVreal 2025 Wh
# 2025-02-17 10:53:55 NextHours_Sum01_PVforecast 2604 Wh
# 2025-02-17 10:53:55 NextHours_Sum02_PVforecast 5324 Wh
# 2025-02-17 10:53:55 NextHours_Sum03_PVforecast 8104 Wh
# 2025-02-17 10:53:55 NextHours_Sum04_ConsumptionForecast 9573 Wh
# 2025-02-17 10:53:55 NextHours_Sum04_PVforecast 10634 Wh
# 2025-02-17 10:53:55 RestOfDayConsumptionForecast 16610 Wh
# 2025-02-17 10:53:55 RestOfDayPVforecast 14041 Wh
# 2025-02-17 00:59:49 Today_Hour01_BatIn_01 0 Wh
# 2025-02-17 00:59:49 Today_Hour01_BatOut_01 0 Wh
# 2025-02-17 00:59:49 Today_Hour01_GridConsumption 0 Wh
# 2025-02-17 00:02:52 Today_Hour01_GridFeedIn 0 Wh
# 2025-02-17 00:59:49 Today_Hour01_PVreal 0 Wh
# 2025-02-17 01:59:49 Today_Hour02_BatIn_01 0 Wh
# 2025-02-17 01:59:49 Today_Hour02_BatOut_01 0 Wh
# 2025-02-17 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2025-02-17 01:59:49 Today_Hour02_PVreal 0 Wh
# 2025-02-17 02:59:49 Today_Hour03_BatIn_01 0 Wh
# 2025-02-17 02:59:49 Today_Hour03_BatOut_01 0 Wh
# 2025-02-17 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2025-02-17 02:59:49 Today_Hour03_PVreal 0 Wh
# 2025-02-17 03:59:49 Today_Hour04_BatIn_01 0 Wh
# 2025-02-17 03:59:49 Today_Hour04_BatOut_01 0 Wh
# 2025-02-17 03:59:49 Today_Hour04_GridConsumption 0 Wh
# 2025-02-17 03:59:49 Today_Hour04_PVreal 0 Wh
# 2025-02-17 04:59:49 Today_Hour05_BatIn_01 0 Wh
# 2025-02-17 04:59:49 Today_Hour05_BatOut_01 0 Wh
# 2025-02-17 04:59:49 Today_Hour05_GridConsumption 0 Wh
# 2025-02-17 04:59:49 Today_Hour05_PVreal 0 Wh
# 2025-02-17 05:59:53 Today_Hour06_BatIn_01 0 Wh
# 2025-02-17 05:59:53 Today_Hour06_BatOut_01 0 Wh
# 2025-02-17 05:59:53 Today_Hour06_GridConsumption 0 Wh
# 2025-02-17 05:59:53 Today_Hour06_PVreal 0 Wh
# 2025-02-17 06:59:49 Today_Hour07_BatIn_01 0 Wh
# 2025-02-17 06:59:49 Today_Hour07_BatOut_01 0 Wh
# 2025-02-17 06:59:49 Today_Hour07_GridConsumption 0 Wh
# 2025-02-17 06:59:49 Today_Hour07_PVreal 0 Wh
# 2025-02-17 07:59:49 Today_Hour08_BatIn_01 0 Wh
# 2025-02-17 07:59:49 Today_Hour08_BatOut_01 0 Wh
# 2025-02-17 07:59:49 Today_Hour08_GridConsumption 0 Wh
# 2025-02-17 07:59:49 Today_Hour08_PVforecast 14 Wh
# 2025-02-17 07:59:49 Today_Hour08_PVreal 7 Wh
# 2025-02-17 08:59:50 Today_Hour09_BatIn_01 0 Wh
# 2025-02-17 08:59:50 Today_Hour09_BatOut_01 0 Wh
# 2025-02-17 08:59:50 Today_Hour09_GridConsumption 0 Wh
# 2025-02-17 08:59:50 Today_Hour09_GridFeedIn 20 Wh
# 2025-02-17 08:59:50 Today_Hour09_PVforecast 682 Wh
# 2025-02-17 08:59:50 Today_Hour09_PVreal 846 Wh
# 2025-02-17 09:59:51 Today_Hour10_BatIn_01 0 Wh
# 2025-02-17 09:59:51 Today_Hour10_BatOut_01 0 Wh
# 2025-02-17 09:59:51 Today_Hour10_GridConsumption 0 Wh
# 2025-02-17 09:59:51 Today_Hour10_GridFeedIn 10 Wh
# 2025-02-17 09:59:51 Today_Hour10_PVforecast 1964 Wh
# 2025-02-17 09:59:51 Today_Hour10_PVreal 2025 Wh
# 2025-02-17 10:53:55 Today_Hour11_BatIn_01 0 Wh
# 2025-02-17 10:53:55 Today_Hour11_BatOut_01 0 Wh
# 2025-02-17 10:53:55 Today_Hour11_GridConsumption 0 Wh
# 2025-02-17 10:53:55 Today_Hour11_GridFeedIn 10 Wh
# 2025-02-17 10:53:55 Today_Hour11_PVforecast 2305 Wh
# 2025-02-17 10:53:55 Today_Hour11_PVreal 2393 Wh
# 2025-02-17 10:53:55 Today_Hour12_PVforecast 2638 Wh
# 2025-02-17 10:53:55 Today_Hour13_PVforecast 2729 Wh
# 2025-02-17 10:53:55 Today_Hour14_PVforecast 2785 Wh
# 2025-02-17 10:53:55 Today_Hour15_PVforecast 2502 Wh
# 2025-02-17 10:53:55 Today_Hour16_PVforecast 1906 Wh
# 2025-02-17 10:53:55 Today_Hour17_PVforecast 1060 Wh
# 2025-02-17 10:53:55 Today_Hour18_PVforecast 191 Wh
# 2025-02-17 10:53:55 Today_MaxPVforecast 2785 Wh
# 2025-02-17 10:53:55 Today_MaxPVforecastTime 2025-02-17 13:00:00
# 2025-02-17 10:53:55 Today_PVforecast 18776 Wh
# 2025-02-17 10:53:55 Today_PVreal 5271 Wh
# 2025-02-17 10:53:55 Today_SunRise 07:42
# 2025-02-17 10:53:55 Today_SunSet 17:52
# 2025-02-17 10:53:55 Tomorrow_ConsumptionForecast -77958 Wh
# 2025-02-17 10:53:55 Tomorrow_PVforecast 18970 Wh
# 2025-02-17 10:53:55 Tomorrow_SunRise 07:40
# 2025-02-17 10:53:55 Tomorrow_SunSet 17:53
# 2025-02-17 10:53:55 consumer01 name='Wallbox' state='unknown' mode='can' planningstate='noSchedule'
# 2025-02-17 10:53:55 consumer01_currentPower 0 W
# 2025-02-17 10:53:55 nextCycletime 10:55:05
# 2025-02-17 10:52:46 nextRadiationAPICall nach 17.02.2025 11:07:46
# 2025-02-17 08:00:03 pvCorrectionFactor_08 0.50 (automatic - old factor: 1.00, Sun Alt range: 0, Cloud range: 15, Days in range: 1)
# 2025-02-17 09:00:04 pvCorrectionFactor_09 1.24 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 00, Days in range: 1)
# 2025-02-17 10:00:04 pvCorrectionFactor_10 1.10 (automatic - old factor: 1.18, Sun Alt range: 15, Cloud range: 00, Days in range: 2)
# 2025-02-17 10:53:55 pvCorrectionFactor_Auto on_complex
# 2025-02-12 16:38:30 setupStringAzimuth NW=144 SO=-36
# 2025-02-12 16:39:32 setupStringDeclination NW=30 SO=30
# 2025-02-17 10:53:56 state updated
# hmccu:
#
setstate PV_Forecast updated
setstate PV_Forecast 2025-02-16 20:50:06 .associatedWith e3dc_s10Pro e3dc_s10Pro:Wallbox
setstate PV_Forecast 2025-02-17 10:53:55 .lastupdateForecastValues 1739786035
setstate PV_Forecast 2025-02-17 10:53:55 .pvCorrectionFactor_Auto_Soll on_complex
setstate PV_Forecast 2025-02-17 01:00:02 .signaldone_01 done
setstate PV_Forecast 2025-02-17 02:00:04 .signaldone_02 done
setstate PV_Forecast 2025-02-17 03:00:04 .signaldone_03 done
setstate PV_Forecast 2025-02-17 04:00:04 .signaldone_04 done
setstate PV_Forecast 2025-02-17 05:00:04 .signaldone_05 done
setstate PV_Forecast 2025-02-17 06:00:04 .signaldone_06 done
setstate PV_Forecast 2025-02-17 07:00:04 .signaldone_07 done
setstate PV_Forecast 2025-02-17 08:00:03 .signaldone_08 done
setstate PV_Forecast 2025-02-17 09:00:04 .signaldone_09 done
setstate PV_Forecast 2025-02-17 10:00:04 .signaldone_10 done
setstate PV_Forecast 2025-02-17 00:00:04 .signaldone_24 done
setstate PV_Forecast 2025-02-17 10:53:55 Battery_ChargeRecommended_01 1
setstate PV_Forecast 2025-02-17 10:53:55 Current_AutarkyRate 100 %
setstate PV_Forecast 2025-02-17 10:53:55 Current_BatCharge_01 32 %
setstate PV_Forecast 2025-02-17 10:53:55 Current_Consumption 1798 W
setstate PV_Forecast 2025-02-17 10:53:55 Current_GridConsumption 0 W
setstate PV_Forecast 2025-02-17 10:53:55 Current_GridFeedIn 5 W
setstate PV_Forecast 2025-02-17 10:53:55 Current_PV 2841 W
setstate PV_Forecast 2025-02-17 10:53:55 Current_PowerBatIn_01 1038 W
setstate PV_Forecast 2025-02-17 10:53:55 Current_PowerBatOut_01 0 W
setstate PV_Forecast 2025-02-17 10:53:55 Current_SelfConsumption 1798 W
setstate PV_Forecast 2025-02-17 10:53:55 Current_SelfConsumptionRate 63 %
setstate PV_Forecast 2025-02-17 10:53:55 Current_Surplus 1043 W
setstate PV_Forecast 2025-02-17 10:00:00 LastHourGridconsumptionReal 0 Wh
setstate PV_Forecast 2025-02-17 10:00:00 LastHourPVforecast 1964 Wh
setstate PV_Forecast 2025-02-17 10:00:00 LastHourPVreal 2025 Wh
setstate PV_Forecast 2025-02-17 10:53:55 NextHours_Sum01_PVforecast 2604 Wh
setstate PV_Forecast 2025-02-17 10:53:55 NextHours_Sum02_PVforecast 5324 Wh
setstate PV_Forecast 2025-02-17 10:53:55 NextHours_Sum03_PVforecast 8104 Wh
setstate PV_Forecast 2025-02-17 10:53:55 NextHours_Sum04_ConsumptionForecast 9573 Wh
setstate PV_Forecast 2025-02-17 10:53:55 NextHours_Sum04_PVforecast 10634 Wh
setstate PV_Forecast 2025-02-17 10:53:55 RestOfDayConsumptionForecast 16610 Wh
setstate PV_Forecast 2025-02-17 10:53:55 RestOfDayPVforecast 14041 Wh
setstate PV_Forecast 2025-02-17 00:59:49 Today_Hour01_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 00:59:49 Today_Hour01_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 00:59:49 Today_Hour01_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 00:02:52 Today_Hour01_GridFeedIn 0 Wh
setstate PV_Forecast 2025-02-17 00:59:49 Today_Hour01_PVreal 0 Wh
setstate PV_Forecast 2025-02-17 01:59:49 Today_Hour02_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 01:59:49 Today_Hour02_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 01:59:49 Today_Hour02_PVreal 0 Wh
setstate PV_Forecast 2025-02-17 02:59:49 Today_Hour03_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 02:59:49 Today_Hour03_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 02:59:49 Today_Hour03_PVreal 0 Wh
setstate PV_Forecast 2025-02-17 03:59:49 Today_Hour04_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 03:59:49 Today_Hour04_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 03:59:49 Today_Hour04_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 03:59:49 Today_Hour04_PVreal 0 Wh
setstate PV_Forecast 2025-02-17 04:59:49 Today_Hour05_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 04:59:49 Today_Hour05_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 04:59:49 Today_Hour05_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 04:59:49 Today_Hour05_PVreal 0 Wh
setstate PV_Forecast 2025-02-17 05:59:53 Today_Hour06_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 05:59:53 Today_Hour06_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 05:59:53 Today_Hour06_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 05:59:53 Today_Hour06_PVreal 0 Wh
setstate PV_Forecast 2025-02-17 06:59:49 Today_Hour07_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 06:59:49 Today_Hour07_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 06:59:49 Today_Hour07_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 06:59:49 Today_Hour07_PVreal 0 Wh
setstate PV_Forecast 2025-02-17 07:59:49 Today_Hour08_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 07:59:49 Today_Hour08_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 07:59:49 Today_Hour08_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 07:59:49 Today_Hour08_PVforecast 14 Wh
setstate PV_Forecast 2025-02-17 07:59:49 Today_Hour08_PVreal 7 Wh
setstate PV_Forecast 2025-02-17 08:59:50 Today_Hour09_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 08:59:50 Today_Hour09_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 08:59:50 Today_Hour09_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 08:59:50 Today_Hour09_GridFeedIn 20 Wh
setstate PV_Forecast 2025-02-17 08:59:50 Today_Hour09_PVforecast 682 Wh
setstate PV_Forecast 2025-02-17 08:59:50 Today_Hour09_PVreal 846 Wh
setstate PV_Forecast 2025-02-17 09:59:51 Today_Hour10_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 09:59:51 Today_Hour10_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 09:59:51 Today_Hour10_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 09:59:51 Today_Hour10_GridFeedIn 10 Wh
setstate PV_Forecast 2025-02-17 09:59:51 Today_Hour10_PVforecast 1964 Wh
setstate PV_Forecast 2025-02-17 09:59:51 Today_Hour10_PVreal 2025 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour11_BatIn_01 0 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour11_BatOut_01 0 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour11_GridConsumption 0 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour11_GridFeedIn 10 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour11_PVforecast 2305 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour11_PVreal 2393 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour12_PVforecast 2638 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour13_PVforecast 2729 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour14_PVforecast 2785 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour15_PVforecast 2502 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour16_PVforecast 1906 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour17_PVforecast 1060 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_Hour18_PVforecast 191 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_MaxPVforecast 2785 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_MaxPVforecastTime 2025-02-17 13:00:00
setstate PV_Forecast 2025-02-17 10:53:55 Today_PVforecast 18776 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_PVreal 5271 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Today_SunRise 07:42
setstate PV_Forecast 2025-02-17 10:53:55 Today_SunSet 17:52
setstate PV_Forecast 2025-02-17 10:53:55 Tomorrow_ConsumptionForecast -77958 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Tomorrow_PVforecast 18970 Wh
setstate PV_Forecast 2025-02-17 10:53:55 Tomorrow_SunRise 07:40
setstate PV_Forecast 2025-02-17 10:53:55 Tomorrow_SunSet 17:53
setstate PV_Forecast 2025-02-17 10:53:55 consumer01 name='Wallbox' state='unknown' mode='can' planningstate='noSchedule'
setstate PV_Forecast 2025-02-17 10:53:55 consumer01_currentPower 0 W
setstate PV_Forecast 2025-02-17 10:53:55 nextCycletime 10:55:05
setstate PV_Forecast 2025-02-17 10:52:46 nextRadiationAPICall nach 17.02.2025 11:07:46
setstate PV_Forecast 2025-02-17 08:00:03 pvCorrectionFactor_08 0.50 (automatic - old factor: 1.00, Sun Alt range: 0, Cloud range: 15, Days in range: 1)
setstate PV_Forecast 2025-02-17 09:00:04 pvCorrectionFactor_09 1.24 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 00, Days in range: 1)
setstate PV_Forecast 2025-02-17 10:00:04 pvCorrectionFactor_10 1.10 (automatic - old factor: 1.18, Sun Alt range: 15, Cloud range: 00, Days in range: 2)
setstate PV_Forecast 2025-02-17 10:53:55 pvCorrectionFactor_Auto on_complex
setstate PV_Forecast 2025-02-12 16:38:30 setupStringAzimuth NW=144 SO=-36
setstate PV_Forecast 2025-02-12 16:39:32 setupStringDeclination NW=30 SO=30
setstate PV_Forecast 2025-02-17 10:53:56 state updated
Hier mal der Header-Bereich mit dem Minus-Wert in der Prognose für morgen:
Screenshot Header.png
Hier noch 2 Screenshots, einmal mit der Darstellung in kWh und einmal in Wh (siehe Dateiname).
Bis 6:00 Uhr gab es demnach keinen Verbrauch und auch die Werte um 7 oder 8 sind deutlich zu gering.
kWH:
Screenshot_kWh.png
Wh:
Screenshot_Wh.png
ZitatBis 6:00 Uhr gab es demnach keinen Verbrauch und auch die Werte um 7 oder 8 sind deutlich zu gering.
Nicht Verbrauch, es geht um den Netzbezug, oder?
Kann es sein, dass die Einheit der Readings
contotal=Grid_Today_EnergyOut:kWh bzw feedtotal=Grid_Today_EnergyIn:kWh
nicht kWh sondern Wh sein müsste?
Ansonsten führe bitte ein "get ... pvCircular 99" aus und poste die Ausgabe.
Sie sieht etwa so aus:
99 => tdayDvtn: -, ydayDvtn: 26.22
todayConsumption: 7962, feedintotal: 2639818.8, initdayfeedin: 2639800.2
gridcontotal: 925395.7, initdaygcon: 925108.4
initdaybatintot01: 4205688.9725021, initdaybatintot02: -, initdaybatintot03: -
Interessant ist hier initdaygcon.
Der Netzbezug ist um die Uhrzeit und zu dieser Jahreszeit auch unser Verbrauch ;)
Der Akku ist bei 10% gesperrt (als Notstromreserve).
Die Werte sind im Device (Hauskraftwerk) kWh, das stimmt schon.
Hier die Ausgabe aus dem GET:
99 => tdayDvtn: -, ydayDvtn: -7.45
todayConsumption: 7071, feedintotal: 40, initdayfeedin: 0
gridcontotal: 11840, initdaygcon: 17140
initdaybatintot01: 0, initdaybatintot02: -, initdaybatintot03: -
initdaybatouttot01: 0, initdaybatouttot02: -, initdaybatouttot03: -
batintot01: 0, batintot02: -, batintot03: -
batouttot01: 0, batouttot02: -, batouttot03: -
lastTsMaxSocRchd01: 1739375885, lastTsMaxSocRchd02: -, lastTsMaxSocRchd03: -
nextTsMaxSocChge01: 1741103885, nextTsMaxSocChge02: -, nextTsMaxSocChge03: -
days2care01: -, days2care02: -, days2care03: -
runTimeTrainAI: -, aitrainLastFinishTs: -, aiRulesNumber: -
attrInvChangedTs: 1739282920
Die 17,1 kWh initdaygcon Netzbezug (Summe gestern) stimmen mit den Daten aus dem Hauskraftwerk überein.
Zitat von: DS_Starter am 17 Februar 2025, 10:54:40Ich habe das Modul in meinem Contrib upgedatet und den Fehler (hoffentlich) beseitigt.
Du/ihr könnt die Datei in euer FHEM-Verzeichnis herunterladen und FHEM neu starten.
Danach bitte testen ob wieder i.O.
LG
Ich hatte das gleiche Problem - ist damit gelöst, danke!
Zitat von: DS_Starter am 17 Februar 2025, 10:54:40Ich habe das Modul in meinem Contrib upgedatet und den Fehler (hoffentlich) beseitigt.
Du/ihr könnt die Datei in euer FHEM-Verzeichnis herunterladen und FHEM neu starten.
Danach bitte testen ob wieder i.O.
LG
Hab die neue Version runter geladen und läuft jetzt! Super! Danke! :)
@Dirk,
die Dinge werden klarer denke ich.
Es wird am Tagesanfang initdaygcon: 17140, d.h. der Stand 17140 Wh gemeldet.
Aktuell (MIttag) wurden aber nur gridcontotal: 11840, d.h. Stand 11840 Wh gemeldet.
Das bedeutet weniger als am Tagesanfang.
Für das Modul wären 0 am Tagesanfang kein Problem, aber das sieht mir nicht danach aus. Eher vermute ich dass der Zähler "irgendwann" wieder tiefer (bei 0?) beginnend hochzählt.
Da wirst du vermutlich nicht um ein "vernünftiges" Userreading herum kommen.
LG,
Heiko
OK, Danke für den Hinweis, dann logge ich doch mal das Reading und schaue, wie ich das hinbekomme.
Hallo zusamnmen,
ab morgen früh ist die Version 1.46.0 im Update enthalten.
Was ist neu bzw. geändert:
- Im Benachrichtigungssystem wird der letzte und nächste Pull des Infofiles per Mouse-Over ausgedruckt wenn es keine Nachrichten gibt
- die Kalkulation der Verbrauchsvorhersage ist auf ein neues Verfahren umngestellt, welches uns erlaubt deutlich mehr als die derzeitigen 31
Tage einzubeziehen. Es werden aktuell bis zu 180 Tage Verbrauchswerte auf Stundenbasis gespeichert und können einbezogen werden.
In diesem Zusammenhang hat sich die Bedeutung des Attr affectConsForecastLastDays und affectConsForecastIdentWeekdays etwas geändert und wurde
an das neue Verfahren angepasst.
- der Key "exconfc" in der Consumersteuerung hat eine weitere Option "2":
exconfc Kennzeichen zur Verwendung des historischen Energieverbrauchs des Verbrauchers (optional).
0 - die gespeicherten Energieverbrauchsanteile bleiben als Bestandteil der allgemeinen Verbrauchsprognose erhalten (default)
1 - die allgemeine Verbrauchsprognose wird um die gespeicherten Energieverbrauchsanteile reduziert.
2 - wie bei '1', jedoch gehen die Planungsdaten des Verbrauchers bei der Prognose der kommenden Stunden wieder mit ein.
- Im PlantConfig check ist der Memory check der pvHistoryfür den consumption Wert eingefügt. Evtl. permanente Logeinträge entfallen damit.
- der Befehl "set reset consumption" ist in "set reset consumptionHistory" umbenannt
- Einige Debug-Informationen sind verbessert
- Bug Fixing, z.B. der gemeldete Fehler: https://forum.fhem.de/index.php?msg=1334123
Bezüglich der Verbrauchsprognose sollten sich Verbesserungen einstellen wenn Consumer mit höherer Leistung den Schlüssel exconfc=2 enthalten und
die Planung sowie Schaltung durch das Modul vorgenommen wird. Insbesondere wenn man nur gleiche Wochentage (affectConsForecastIdentWeekdays=1)
verrbeitet. Dann werden sich eingefahrene Verhaltensweisen und Rituale (am Tag X wird die Waschmaschine laufen gelassen, am Tyg Y immer gebügelt,
am Sonntag immer dem Hobby nachgegangen usw. ...) gut abbilden lassen.
Als weiteren Schritt habe ich Vorgesehen demnächst eine KI-Integration für die Verbrauchsprognose aufzubauen um unregelmäßige, aber von
bestimmten Umgebungsfaktoren abhängige Verbrauchsverhalten besser abbilden zu können.
Edit: Es sind keine Anpassung seitens des Anwenders nötig.
LG,
Heiko
Zitat von: DS_Starter am 17 Februar 2025, 14:51:00Für das Modul wären 0 am Tagesanfang kein Problem, aber das sieht mir nicht danach aus. Eher vermute ich dass der Zähler "irgendwann" wieder tiefer (bei 0?) beginnend hochzählt.
Da wirst du vermutlich nicht um ein "vernünftiges" Userreading herum kommen.
LG,
Heiko
Hallo Heiko,
eine Frage, was zählt als Tagesanfang, also bis wann nach 00:00:00 wird ein Zurücksetzen auf Null akzeptiert?
Ich baue gerade eine entsprechende Logik und da wäre der Zeitrahmen interessant.
Danke Dir.
Schöne Grüße
Dirk
Du must ,,nur" verhindern das der gestrige Zählerstandswert nach 00:00 Uhr als Reading im SF-Modul irgendwie ,,registriert" wird 😉
Gruß
300P
Ich würde auch ein Userreading mit monotonic bevorzugen.
Und wenn du Tageswerte oder sowas benötigst, dann eventuel diese mit statistic zusätzlich erstellen.
Dann bist du frei von irgendwelchen Timing Problemen von irgendeiner Hardware und irgendwelchen ominösen Systemzeiten.
Guten Abend,
Seit weit über einem Jahr bin ich aktiver Nutzer vom Modul SolarForecast und sehr begeistert über die ständige Weiterentwicklung :)
Nach den heutigen Update auf die Version 1.45.6 startet mein FHEM leider ständig neu.
Ich habe daher erstmal das Modul SolarForecast deaktiviert (nach etwas suche im Log), damit FHEM wieder starten konnte.
Hier der Auszug aus dem Log:
2025.02.17 18:52:26 1: UPD ./CHANGED
2025.02.17 18:52:26 1: UPD FHEM/00_TCM.pm
2025.02.17 18:52:26 1: UPD FHEM/10_EnOcean.pm
2025.02.17 18:52:26 1: UPD FHEM/76_SolarForecast.pm
2025.02.17 18:52:27 1: UPD FHEM/98_SVG.pm
2025.02.17 18:52:27 1: UPD FHEM/HttpUtils.pm
2025.02.17 18:52:27 1: UPD FHEM/lib/AttrTemplate/mqtt2.template
2025.02.17 18:52:27 1: saving fhem.cfg
2025.02.17 18:52:27 1: saving ./log/fhem.save
2025.02.17 18:52:27 1:
2025.02.17 18:52:27 1: New entries in the CHANGED file:
2025.02.17 18:52:27 1: - change: 76_SolarForecast: version 1.45.6
2025.02.17 18:52:27 1:
2025.02.17 18:52:28 1:
2025.02.17 18:52:28 1: update finished, "shutdown restart" is needed to activate the changes.
2025.02.17 18:52:35 0: Server shutdown
2025.02.17 18:52:36 1: Including fhem.cfg
.......
2025.02.17 18:52:48 3: Forecast - cached data "pvHistory" restored
2025.02.17 18:52:48 3: Forecast - cached data "pvCircular" restored
2025.02.17 18:52:48 3: Forecast - cached data "consumerMaster" restored
2025.02.17 18:52:48 3: Forecast - cached data "radiationApiData" restored
2025.02.17 18:52:48 3: Forecast - cached data "statusApiData" restored
2025.02.17 18:52:48 3: Forecast - cached data "aiTrainedData" restored
2025.02.17 18:52:48 3: Forecast - cached data "aiRawData" restored
.......
2025.02.17 18:53:01 0: Featurelevel: 6.3
2025.02.17 18:53:01 0: Server started with 515 defined entities
.......
Can't use an undefined value as an ARRAY reference at ./FHEM/76_SolarForecast.pm line 12190.
2025.02.17 18:53:12 1: Including fhem.cfg
Läuft es bei euch nach den Update fehlerfrei ?
Gruß Martin
Zitat von: Dirk070 am 17 Februar 2025, 17:08:48Zitat von: DS_Starter am 17 Februar 2025, 14:51:00Für das Modul wären 0 am Tagesanfang kein Problem, aber das sieht mir nicht danach aus. Eher vermute ich dass der Zähler "irgendwann" wieder tiefer (bei 0?) beginnend hochzählt.
Da wirst du vermutlich nicht um ein "vernünftiges" Userreading herum kommen.
LG,
Heiko
Hallo Heiko,
eine Frage, was zählt als Tagesanfang, also bis wann nach 00:00:00 wird ein Zurücksetzen auf Null akzeptiert?
Ich baue gerade eine entsprechende Logik und da wäre der Zeitrahmen interessant.
Danke Dir.
Schöne Grüße
Dirk
Du hast auch ein E3DC, richtig?
Die Erzeugungs-, Einspesiungs, Batterieladungs- und Batterientladungswerte kommen ja nur 1/4 stündlich.
Bei mir war das immer so ca. 1-2 Minuten nach der vollen Stunde.
Vielleicht liegt das bei Dir da dran.
Ich habe mich dann mit meiner eigenen Rechnung beholfen.
Leider weiche ich da etwas von der E3DC Berechnung ab.
fromgrid integral {ReadingsVal("$name","gridpower","")>0?ReadingsVal("$name","gridpower","")/3600:0},
togrid integral {ReadingsVal("$name","gridpower","")<0?ReadingsVal("$name","gridpower","")/-3600:0},
batin integral {ReadingsVal("$name","batterypower","")>0?ReadingsVal("$name","batterypower","")/3600:0},
batout integral {ReadingsVal("$name","batterypower","")<0?ReadingsVal("$name","batterypower","")/-3600:0},
fromroof integral {ReadingsVal("$name","solarpower",0)/3600}
Meine Erzeugungsleistung laut Eigenberechnung liegt bei 19,61kWh. Laut E3DC-Portal bei 20,85kWh.
Aber bis ich eine bessere Lösung habe, bleibt das so.
Gruß,
Heiko
Hallo Martin,
ZitatLäuft es bei euch nach den Update fehlerfrei ?
zwei User hatten ein Problem gemeldet, siehe #1984 / #1985.
In meinem contrib liegt eine gefixte Version die auch morgen früh im Update sein wird.
Du kannst die V aus meinem contrib sofort downloaden und FHEM neu starten.
Das löst das Problem.
@
Zitat von: DS_Starter am 17 Februar 2025, 20:07:25......
In meinem contrib liegt eine gefixte Version die auch morgen früh im Update sein wird.
......
Kleine -sehr unwichtige- Anmerkung am Rande für die ToDo-Liste auf d(ein)er Bereinigungsliste.
Ich hab es bislang noch nicht so gesehen / wahrgenommen ?!
Es erfolgt evtl. eine doppelte Prüfung / Anzeige der "Informationen zur Anlagenprüfung" der Ergebnisse der Perlmodule.
Anzeige bei "Common Settings"
checked Perl modules:
AI::DecisionTree
Anzeige bei "Perl Modules"
checked installed Perl Modules:
AI::DecisionTree
Gruß
300P
Guten Morgen,
danke für den Hinweis 300P. :)
Ich bereinige das.
LG,
Heiko
Zitat von: kask am 17 Februar 2025, 19:23:30Ich würde auch ein Userreading mit monotonic bevorzugen.
Und wenn du Tageswerte oder sowas benötigst, dann eventuel diese mit statistic zusätzlich erstellen.
Dann bist du frei von irgendwelchen Timing Problemen von irgendeiner Hardware und irgendwelchen ominösen Systemzeiten.
Zitat von: mannil am 17 Februar 2025, 20:04:02Du hast auch ein E3DC, richtig?
Die Erzeugungs-, Einspesiungs, Batterieladungs- und Batterientladungswerte kommen ja nur 1/4 stündlich.
Bei mir war das immer so ca. 1-2 Minuten nach der vollen Stunde.
Vielleicht liegt das bei Dir da dran.
Ich habe mich dann mit meiner eigenen Rechnung beholfen.
Leider weiche ich da etwas von der E3DC Berechnung ab.
fromgrid integral {ReadingsVal("$name","gridpower","")>0?ReadingsVal("$name","gridpower","")/3600:0},
togrid integral {ReadingsVal("$name","gridpower","")<0?ReadingsVal("$name","gridpower","")/-3600:0},
batin integral {ReadingsVal("$name","batterypower","")>0?ReadingsVal("$name","batterypower","")/3600:0},
batout integral {ReadingsVal("$name","batterypower","")<0?ReadingsVal("$name","batterypower","")/-3600:0},
fromroof integral {ReadingsVal("$name","solarpower",0)/3600}
Meine Erzeugungsleistung laut Eigenberechnung liegt bei 19,61kWh. Laut E3DC-Portal bei 20,85kWh.
Aber bis ich eine bessere Lösung habe, bleibt das so.
Gruß,
Heiko
Danke Euch beiden für die Hinweise. :)
Ja, ich habe ein E3/DC und habe ab Mitternacht mal mitgeloggt.
Die Werte werden verzögert initialisiert, stimmt.
Ich teste jetzt mal einen einfachen Ansatz und setze um 00:00 per setreading auf Null.
Ich logge dann mal 10 Minuten lang minütlich mit um zu prüfen, ob der Wert wieder zurück springt.
ich nehme mal an, dieser "Fehler" verschwindet mit der Zeit ...
Hallo Heiko,
ich habe mal wieder eine neue Idee. Vielleicht ist sie aber auch unnötig.
Wäre es evtl. für die Ertragsprognose hilfreich, die Momentanleistungen der einzelnen Strings zu kennen?
Zum Hintergrund:
Meine Solarpanelflächen (= Strings) sind untypisch ausgerichtet:
strings.png
Mein Wechselrichter liefert Spannung und Strom der einzelnen Strings. Daraus könnte immerhin die Scheinleistung ermittelt werden und so evtl. die Prognose verbessert werden?
Weiter verbessern ließe sich die Prognose evtl. mit der genauen Angabe der Dachneigung.
Meine Paneele liegen auf dem Dach, das eine Neigung von 38 Grad hat. Ich muss hier aber näherungsweise 40 Grad angeben.
Ich habe aktuell, da die Sonne jeden Tag etwas höher steigt, den Eindruck, dass 2 Grad einen recht deutlichen Unterschied in der potentiellen maximalen Leistung machen?
Kannst ja die Gedanken mal ein bisschen gären lassen.
Vielen Dank und viele Grüße,
Peter
Zitat von: grappa24 am 18 Februar 2025, 12:05:45ich nehme mal an, dieser "Fehler" verschwindet mit der Zeit ...
@grappa24
Das kommt darauf an wie lange dort du deine Daten speichern läßt und warten möchtest. ;)
Eine Vorgabe für die Historie ist bis zu 180 Tage da möglich.
- persönliche individuelle Einrichtung möglich - 8)
Default / Standart ist augenblicklich, soweit ich es kenne, 60 Tage.
Schau mal hier https://forum.fhem.de/index.php?topic=137058.msg1333936#msg1333936 (https://forum.fhem.de/index.php?topic=137058.msg1333936#msg1333936)
Gruß
300P
Nachsatz:
Bei Wochentagen weiß ich nicht so richtig wie es sich dann wirklich verhält....
Die dann anfallenden 180 Wochen wäre schon etwas sehr lange und sind bei 180 Speicherwerten auch nicht alle da :o
affectConsForecastLastDays
Es wird die angegebene Anzahl historischer Tageswerte bei der Berechnung der Verbrauchsprognose einbezogen.
So wird z.B. mit dem Attributwert "1" nur der vorangegangene Tag berücksichtigt, mit dem Wert "14" die vergangenen 14 Tage.
Die tatsächlich berücksichtigten Tage können geringer als angegeben sein wenn noch nicht genügend Werte im internen Speicher vorhanden sind.
(default: 60)
Hinweis: Bei einem zusätzlich gesetzten Attribut affectConsForecastIdentWeekdays wird die angegebene Anzahl vergangener gleicher Wochentage (Mo .. So) berücksichtigt.
In diesem Fall werden bei einem gesetzten Wert von "8" die gleichen Wochentage der vergangenen 8 Wochen berücksichtigt.
@grappa24 und @300P
Zitatich nehme mal an, dieser "Fehler" verschwindet mit der Zeit ...
Ja und Nein.
Ja, die Daten in der pvHistory bleiben max. 31 Tage enthalten. Sie würde verschwinden wenn nicht neue Datensätze mit negativer Consumption geschrieben werden. Ständig neue Datensätze mit neg. Verbrauch deuten auf ein Problem im Setup bzw. den Quellen hin.
Deswegen würde ich die vorhandenen neg. Werte löschen und beobachten ob neue entstehen.
Wie das geht steht im Log, z.B.:
Zitat2025.02.18 14:11:32.335 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 04/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumptionHistory 04 15'.
2025.02.18 14:11:32.338 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 18/13 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumptionHistory 18 13'.
2025.02.18 14:11:32.341 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 31/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumptionHistory 31 15'.
Die Stundenwerte der Wochentage stehen in der pvCircular und sie werden bis zu 210 Tage (bis 180 auswertbar) in die Vergangenheit reichen. Im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Die_Verbrauchsprognose) habe ich etwas zu den neuen Zusammenhängen geschrieben.
Ob sich in der pvCircular ebenfalls negative Verbrauchswerte finden, kann mit "get ... pvCircular" geprüft werden. Wichtig hier der Schlüssel con_all. Sauber sieht er etwa so aus:
con_all => Mo @ 634 708 483
Mi @ 648 665
Fr @ 567 522
Do @ 528 727
Sa @ 682 616
So @ 1059 578
Di @ 570 665 575
Sollten dort auch negative Werte zu finden sein, sagt Bescheid. In der aktuellen Version werden keine negativen con-Werte in diesen Schüssel eingetragen.
Hallo Peter,
ZitatWäre es evtl. für die Ertragsprognose hilfreich, die Momentanleistungen der einzelnen Strings zu kennen?
Naja, das wäre maximal für die aktuelle Stunde hilfreich um daraus über ein Integral auf die Stundenleistung zu schließen.
Für die Prognose der kommenden Stunden kann man den Wert nicht verwenden. Diese Prognosen bzw. der Tageswerte liefern die API's der gewählten Wetterdienste.
ZitatWeiter verbessern ließe sich die Prognose evtl. mit der genauen Angabe der Dachneigung.
Meine Paneele liegen auf dem Dach, das eine Neigung von 38 Grad hat. Ich muss hier aber näherungsweise 40 Grad angeben.
Ich habe aktuell, da die Sonne jeden Tag etwas höher steigt, den Eindruck, dass 2 Grad einen recht deutlichen Unterschied in der potentiellen maximalen Leistung machen?
Die Angabe des Neigungswinkels (set .. setupStringDeclination) kann ich freigeben.
Durch die Weiterentwicklungen der letzten Monate können wir jetzt den Winkel zw. 0 und 90 Grad in 1-Grad Schritten frei angeben.
Ich baue das kurzfristig ein.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 18 Februar 2025, 14:49:51Naja, das wäre maximal für die aktuelle Stunde hilfreich um daraus über ein Integral auf die Stundenleistung zu schließen.
Für die Prognose der kommenden Stunden kann man den Wert nicht verwenden. Diese Prognosen bzw. der Tageswerte liefern die API's der gewählten Wetterdienste.
wenn man die Werte direkt betrachtet, hast Du Recht. Ich dachte, es gibt evtl. eine Möglichkeit, die string-spezifischen Werte in die KI zum Lernen einfließen zu lassen?
ZitatDie Angabe des Neigungswinkels (set .. setupStringDeclination) kann ich freigeben.
Durch die Weiterentwicklungen der letzten Monate können wir jetzt den Winkel zw. 0 und 90 Grad in 1-Grad Schritten frei angeben.
Ich baue das kurzfristig ein.
Das ist super! Danke dafür schonmal vorab.
Viele Grüße,
Peter
Zitat von: DS_Starter am 18 Februar 2025, 14:26:21Deswegen würde ich die vorhandenen neg. Werte löschen und beobachten ob neue entstehen.
Wie das geht steht im Log, z.B.:
Zitat2025.02.18 14:11:32.335 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 04/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumption 04 15'.
2025.02.18 14:11:32.338 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 18/13 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumption 18 13'.
2025.02.18 14:11:32.341 1: SolCast6 - WARNING - The stored Energy consumption of day/hour 31/15 is negative. This appears to be an error. The incorrect value can be deleted with 'set SolCast6 reset consumption 31 15'.
Die "reset consumption dd hh" Befehle funktionieren bei mir nicht :( Die aufgelisteten Werte sind in der Tat alle negativ
ZitatDie "reset consumption dd hh" Befehle funktionieren bei mir nicht :(
Was heißt das? Wie was funktioniert nicht? Gibt es einen Fehler oder beschreibe mal bitte was du machst.
Ich nehme die Befehle aus dem Log, z.B. "set solErtrag reset consumption 01 07" und gebe sie in der FHEM Befehlszeile ein.
-> keine Rückmeldung und im Logfile bleibt der Fehler bestehen.
Ein "get soErtrag pvHistory 01" listet dann den negativen con-Wert immer noch auf, hier -87
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9308650.02759221, etotali02: -, etotali03: -
pvrl01: 0, pvrl02: -, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 1, con: -87, gcons: 1, conprice: 0.32
Was mir auffält: Im setter für SF gibts den reset-Befehl für "consumption dd hh" nicht?
Ach .... ich werd alt :(
In der aktuellen Version heißt es ja auch:
reset consumptionHistory dd hh
Sorry
(Kommt auf die Korrekturliste. In der Hilfe steht es richtig, nur die Logausgabe habe ich vergessen nachzuziehen. :o )
Jetzt wird das Löschen klappen, ist aber nur die halbe Wahrheit.
Nun ist noch wichtig zu ergründen woher diese Werte kommen sofern sie immer wieder eingetragen werden.
Es kann "mal" passieren, zum Beispiel bei einer temporär falschen Einrichtung, sollte aber nicht permanent auftreten.
Guten Morgen,
so, das Nullen hat funktioniert, jetzt ist der initdaygcon: 0
99 => tdayDvtn: -, ydayDvtn: -8.83
todayConsumption: 8540, feedintotal: 0, initdayfeedin: 0
gridcontotal: 8540, initdaygcon: 0
initdaybatintot01: 0, initdaybatintot02: -, initdaybatintot03: -
initdaybatouttot01: 0, initdaybatouttot02: -, initdaybatouttot03: -
batintot01: 0, batintot02: -, batintot03: -
batouttot01: 0, batouttot02: -, batouttot03: -
lastTsMaxSocRchd01: 1739375885, lastTsMaxSocRchd02: -, lastTsMaxSocRchd03: -
nextTsMaxSocChge01: 1741103885, nextTsMaxSocChge02: -, nextTsMaxSocChge03: -
days2care01: -, days2care02: -, days2care03: -
runTimeTrainAI: -, aitrainLastFinishTs: -, aiRulesNumber: -
attrInvChangedTs: 1739282920
Die Balken in der Verbrauchsgraphik zeigen von 00:00-06:00 noch immer Null.
Ich habe jetzt noch einen RESET CONSUMPTION abgesetzt, hätte aber gedacht, dass nach Mitternacht mit dem korrekten Startwert nun die Verbrauchswerte ab diesem Zeitpunkt schon korrekt wären.
Irgenwie sprechen wir scheinbar nicht von dem gleichem......? ?
So müsste es eigentlich aussehen bei einem aktuellen Tagesverbrauch von 5047 Wh und 17.1 Wh Einspeisung bei Stunde 99
99 => tdayDvtn: 4.35, ydayDvtn: -104.16
todayConsumption: 5047, feedintotal: 2978953.8, initdayfeedin: 2978936.9
gridcontotal: 780894.4, initdaygcon: 780869.5
initdaybatintot01: 9578888, initdaybatintot02: 6686075, initdaybatintot03: -
initdaybatouttot01: 6868960, initdaybatouttot02: 4713902, initdaybatouttot03: -
batintot01: 9579845, batintot02: 6686580, batintot03: -
batouttot01: 6870720, batouttot02: 4718635, batouttot03: -
lastTsMaxSocRchd01: 1739903302, lastTsMaxSocRchd02: 1739895601, lastTsMaxSocRchd03: -
nextTsMaxSocChge01: 1741631302, nextTsMaxSocChge02: 1741623601, nextTsMaxSocChge03: -
days2care01: 19, days2care02: 19, days2care03: -
runTimeTrainAI: 0.9987, aitrainLastFinishTs: 1739927704, aiRulesNumber: 3426
attrInvChangedTs: 1736179151
Zitat von: DS_Starter am 18 Februar 2025, 17:32:21Jetzt wird das Löschen klappen, ist aber nur die halbe Wahrheit.
Nun ist noch wichtig zu ergründen woher diese Werte kommen sofern sie immer wieder eingetragen werden.
Es kann "mal" passieren, zum Beispiel bei einer temporär falschen Einrichtung, sollte aber nicht permanent auftreten.
Das Löschen hat geklappt, ich hab aber heute schon wieder einen negativen con-Wert:
08 => pvfc: 90, pvrl: 108, pvrlvd: 1, rad1h: 40
etotali01: 9520629.48165973, etotali02: -, etotali03: -
pvrl01: 108, pvrl02: -, pvrl03: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 1, con: -205, gcons: 0, conprice: 0.32
gfeedin: 0, feedprice: 0.08
DoN: 0, sunaz: 107, sunalt: 0
batintotal01: 1885728.06901552, batintotal02: -, batintotal03: -
batouttotal01: 1752262.67133209, batouttotal02: -, batouttotal03: -
batsoc01: 5, batsoc02: -, batsoc03: -
batin01: 293, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 101, wcc: 32, rr1c: 0.00, pvcorrf: 1.50/0.35 temp: -3.70,
minutescsm01: 60
minutescsm02: 60
minutescsm03: 0
minutescsm04: 0
minutescsm05: 60
minutescsm06: 0
csmt08: 429463.918, csme08: 40.7260000000242, minutescsm08: 60
csmt09: 151744.493, csme09: 16.8789999999863, minutescsm09: 12Helft mir mal, wie wird der con-Wert berechnet, meine Definitionen sehen so aus (meter, inverter, battery):
SymGen24 gcon=User_Power_Import:W contotal=User_Energy_Import:Wh gfeedin=User_Power_Feedin feedtotal=User_Energy_Feedin:Wh conprice=0.32:€ feedprice=0.08:€
SymGen24 pv=PowerFlow_Site_P_PV:W etotal=User_Produced_PV:kWh capacity=10000 strings=suedwest,nordost
BatteryDummy pin=-pout pout=total_pac:W intotal=intotal:kWh outtotal=outtotal:kWh charge=chargestatus cap=cap:Wh show=1
ZitatHelft mir mal, wie wird der con-Wert berechnet, meine Definitionen sehen so aus (meter, inverter, battery):
Deine Definitionen sehen erstmal gut aus. Allerdings kann man hier nicht sehen welche Werte sich hinter den Readings verbergen und was da geliefert wird.
Die Berechnung und Zusammenhänge bzgl. con habe ich hier im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?) beschrieben.
LG
Ich habe gestern auf die v1.46.0 aktualisiert.
Nach der Aktualisierung ist mir direkt eine unplausible Verbrauchsvorhersage aufgefallen (viele Stunden waren "0"). Anlagencheck hat einen fehlerhaften Wert ergeben: "The stored Energy consumption of day/hour 01/17 is negative."
Das habe ich entsprechend zurückgesetzt, trotzdem werden weiterhin die "0" angezeigt und der prognostizierte Verbrauch für die nächsten 4 Stunden zeigt aktuell beispielsweise knapp -2.2 kW.
Abgesehen vom Update habe ich nichts geändert, die Anlagenkonfiguration ist unverändert, die Momentanwerte sind alle plausibel.
Wird sich das wieder einpendeln bzw. woher könnte der Fehler kommen?
ZitatNach der Aktualisierung ist mir direkt eine unplausible Verbrauchsvorhersage aufgefallen (viele Stunden waren "0").
Das ist erstmal nicht so dramatisch.
Wenn du ein "get ... pvCircular" ausführst, findest du in jeder Stunde die con-Werte für jeden Wochentag etwa so:
con_all => So @ 1438 8972
Do @ 509 751
Mo @ 1618 631 1587
Fr @ 2867 1152
Mi @ 673 10984
Di @ 1089 5886 1876
Sa @ 1287 903
Diese Daten werden seit einiger Zeit (seit einigen Updates) in die pvCircular geschrieben. Wenn du die Updates mitgemacht hast, finden sich diese Daten dort.
Solltest du erst jetzt mal wieder upgedated haben, sind evtl. noch keine oder sehr wenige Daten vorhanden und müssen erst geschrieben werden. Das baut sich auf, spätestens nach 7 Tagen steht in jedem Stundenwert und jedem Wochentag ein Wert. Schau mal wie es bei dir in diesem Speicher aussieht.
Hallo,
ich bin ja total begeistert vom dem Modul und arbeite mich sol ganz langsam vor.
Meine 3 Inverter werden auch so wie gewünscht abgebildet. Wie es scheint, so steht es ja auch in der Doku zum Modul, kann ich aktuell "nur" 3 Inverter integrieren.
Gibt es einen Trick, noch einen "4.", direkt Batterie ladenenden zu integrieren?
Hallo mkern1975,
freut mich. :)
Letztendlich muß ich die Anzahl der möglichen Inverter im Code erhöhen.
Aber vorab kann du folgendes tun.
In Zeile 389 steht:
MAXINVERTER => 3, # maximale Anzahl der möglichen Inverter
Stelle diesen Wert einfach auf "4" und starte FHEM neu.
Danach solltest du 4 Inverter einbauen können.
Beim nächsten Update des Moduls wäre dieser Wert wieder auf dem Standard. Deswegen muß ich den Standard dann noch anpassen.
LG,
Heiko
Zitat von: DS_Starter am 19 Februar 2025, 10:23:11Wenn du ein "get ... pvCircular" ausführst, findest du in jeder Stunde die con-Werte für jeden Wochentag etwa so:
Ja die Werte sind da, ich sehe nur nicht woher die "0"-Prognosen kommen. Wie gesagt ist es erst mit dem Update auf die 1.46.0 aufgetreten. (Davor hatte ich auch alle paar Tage mal einzelne Stunden, wo "0" prognostiziert war, aber nicht so gehäuft wie derzeit.)
Heute wird beispielsweise für 16:00-17:00 "0" angezeigt, das müssten die Daten sein, oder?
17 => pvapifc: 1258, pvaifc: -, pvfc: 1258, aihit: 0, pvrl: 880
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
confc: -3058, gcon: 5, gfeedin: 562, wcc: 0, rr1c: 0.00
temp: 0.50, wid: 0, wtxt: -
pprl01: -, pprl02: -, pprl03: -
pvcorrf: 0.00=0.88 0.05=1.27 0.100=0.93 0.15=0.89 0.20=1.11 0.30=0.86 0.40=0.99 0.70=1.00 0.75=0.71 0.85=1.50
0.90=0.69 0.95=1.09 5.00=0.98 5.05=0.83 5.10=1.08 5.100=0.86 5.15=1.50 5.20=0.97 5.25=1.50 5.30=1.00
5.40=1.38 5.45=0.87 5.50=1.01 5.55=1.00 5.60=1.30 5.65=0.89 5.70=0.74 5.75=0.94 5.80=1.03 5.85=0.57
5.90=0.94 5.95=1.01 10.10=1.08 10.100=0.86 10.15=1.50 10.20=0.99 10.25=1.50 10.30=0.95 10.35=0.96 10.40=1.38
10.45=1.03 10.50=1.43 10.55=1.12 10.60=1.30 10.65=0.92 10.70=2.54 10.75=0.96 10.80=0.97 10.85=1.25 10.90=0.77
10.95=0.98 15.10=1.08 15.100=1.05 15.15=1.19 15.20=0.97 15.25=1.50 15.30=1.00 15.35=0.88 15.40=1.04 15.45=0.83
15.50=0.98 15.55=1.07 15.60=0.87 15.65=0.98 15.70=1.17 15.75=1.44 15.80=0.71 15.85=1.25 15.90=0.98 15.95=0.62
20.00=1.03 20.100=1.01 20.10=0.96 20.15=1.50 20.20=0.97 20.25=1.50 20.30=1.00 20.40=1.38 20.45=0.87 20.50=1.01
20.55=0.95 20.60=1.30 20.65=1.15 20.70=1.50 20.75=1.18 20.80=1.12 20.85=0.75 20.90=0.98 20.95=1.13 25.00=0.90
25.100=1.11 25.10=1.08 25.15=1.50 25.20=0.97 25.25=1.50 25.30=1.00 25.40=1.38 25.45=0.87 25.50=1.01 25.55=1.00
25.60=1.30 25.65=1.04 25.70=1.50 25.75=0.94 25.80=1.13 25.85=1.00 25.90=0.98 25.95=0.63 30.00=0.98 30.100=0.97
30.10=1.08 30.15=1.50 30.20=1.03 30.25=1.50 30.30=1.00 30.40=0.97 30.45=0.87 30.50=1.05 30.55=1.05 30.60=1.30
30.65=1.00 30.70=1.07 30.75=0.94 30.80=1.12 30.85=1.25 30.90=0.98 30.95=0.63 35.00=1.03 35.05=0.94 35.100=0.84
35.10=1.08 35.15=1.50 35.20=0.97 35.25=1.10 35.30=1.00 35.35=1.01 35.40=0.88 35.45=0.87 35.50=1.10 35.55=1.07
35.60=1.30 35.65=1.05 35.70=0.86 35.75=1.44 35.80=1.16 35.85=0.92 35.90=0.85 35.95=1.11 40.00=1.00 40.05=1.01
40.100=1.11 40.10=1.05 40.15=1.06 40.20=1.05 40.25=1.50 40.30=1.02 40.35=1.01 40.40=1.02 40.45=1.01 40.50=1.00
40.55=1.18 40.60=0.90 40.65=0.83 40.70=0.78 40.75=1.16 40.80=0.87 40.85=1.09 40.90=1.37 40.95=1.20 45.10=1.08
45.15=1.50 45.20=0.97 45.25=1.50 45.30=1.00 45.40=1.38 45.45=0.87 45.50=1.01 45.55=1.00 45.60=1.30 45.65=1.15
45.70=1.50 45.75=0.94 45.80=1.12 45.85=1.25 45.90=0.98 45.95=0.63
simple=1.00
quality: 0.00=0.86 0.05=0.65 0.100=0.93 0.15=0.88 0.20=0.82 0.30=0.84 0.40=0.98 0.70=1.00 0.75=0.00 0.85=0.33
0.90=0.53 0.95=0.84 5.00=0.98 5.05=0.79 5.10=0.86 5.100=0.83 5.15=0.43 5.20=0.94 5.25=0.10 5.30=0.99
5.40=0.91 5.45=0.85 5.50=0.98 5.55=0.73 5.60=0.91 5.65=0.88 5.70=0.65 5.75=0.70 5.80=0.97 5.85=0.25
5.90=0.94 5.95=0.99 10.100=0.84 10.10=0.86 10.15=0.43 10.20=0.99 10.25=0.10 10.30=0.95 10.35=0.90 10.40=0.91
10.45=0.97 10.50=0.66 10.55=0.80 10.60=0.91 10.65=0.91 10.70=0.39 10.75=0.95 10.80=0.97 10.85=0.80 10.90=0.71
10.95=0.98 15.100=0.95 15.10=0.86 15.15=0.85 15.20=0.94 15.25=0.10 15.30=0.99 15.35=0.69 15.40=0.96 15.45=0.80
15.50=0.98 15.55=0.93 15.60=0.85 15.65=0.98 15.70=0.85 15.75=0.60 15.80=0.58 15.85=0.80 15.90=0.98 15.95=0.39
20.00=0.97 20.10=0.96 20.100=0.99 20.15=0.43 20.20=0.94 20.25=0.10 20.30=0.99 20.40=0.91 20.45=0.85 20.50=0.98
20.55=0.88 20.60=0.91 20.65=0.87 20.70=0.00 20.75=0.85 20.80=0.92 20.85=0.35 20.90=0.99 20.95=0.89 25.00=0.89
25.10=0.86 25.100=0.90 25.15=0.43 25.20=0.98 25.25=0.10 25.30=0.99 25.40=0.91 25.45=0.85 25.50=0.98 25.55=0.73
25.60=0.91 25.65=0.96 25.70=0.00 25.75=0.70 25.80=0.88 25.85=1.00 25.90=0.99 25.95=0.42 30.00=0.97 30.10=0.86
30.100=0.97 30.15=0.43 30.20=0.97 30.25=0.10 30.30=0.99 30.40=0.97 30.45=0.85 30.50=0.95 30.55=0.91 30.60=0.91
30.65=1.00 30.70=0.44 30.75=0.70 30.80=0.92 30.85=0.80 30.90=0.99 30.95=0.42 35.00=0.97 35.05=0.94 35.10=0.86
35.100=0.81 35.15=0.43 35.20=0.94 35.25=0.57 35.30=0.99 35.35=0.98 35.40=0.38 35.45=0.85 35.50=0.91 35.55=0.94
35.60=0.91 35.65=0.95 35.70=0.83 35.75=0.63 35.80=0.86 35.85=0.91 35.90=0.83 35.95=0.90 40.00=1.00 40.05=0.99
40.10=0.98 40.100=0.90 40.15=0.42 40.20=0.95 40.25=0.10 40.30=0.98 40.35=0.99 40.40=0.98 40.45=0.99 40.50=1.00
40.55=0.74 40.60=0.89 40.65=0.79 40.70=0.73 40.75=0.86 40.80=0.85 40.85=0.92 40.90=0.73 40.95=0.83 45.10=0.86
45.15=0.43 45.20=0.94 45.25=0.10 45.30=0.99 45.40=0.91 45.45=0.85 45.50=0.98 45.55=0.73 45.60=0.91 45.65=0.87
45.70=0.00 45.75=0.70 45.80=0.92 45.85=0.80 45.90=0.99 45.95=0.42
simple=1.00
pvrlsum: simple=1118901
pvfcsum: simple=1116209
dnumsum: simple=316
con_all => Thu @ 262 697
Wed @ 1574 310
Mon @ 438 1367
Sun @ 329 261
Sat @ 1103 345
Tue @ 1488
Fri @ 292 830
pvrl_0 => 00 @ 48 139
05 @ 80
15 @ 80 180
20 @ 90
30 @ 239
40 @ 180
70 @ 140
75 @ 10
85 @ 30
90 @ 30
95 @ 150
100 @ 61 69 10 100 80 70 50
pvrl_10 => 20 @ 1660
30 @ 1190
35 @ 1730
40 @ 740
45 @ 1100
50 @ 1010
55 @ 1160
60 @ 1000
65 @ 565
70 @ 1120
75 @ 1227
80 @ 402
85 @ 235
90 @ 380
95 @ 315
100 @ 390
pvrl_15 => 15 @ 2550
30 @ 720
35 @ 1870
40 @ 1913
45 @ 1400
50 @ 1507
55 @ 2450
60 @ 1885
65 @ 848
70 @ 1873
75 @ 1485
80 @ 508
85 @ 235
90 @ 1350
95 @ 192
100 @ 1627
pvrl_20 => 00 @ 4367
10 @ 3950
30 @ 720
40 @ 740
45 @ 775
50 @ 430
55 @ 2360
60 @ 1000
65 @ 530
75 @ 1985
80 @ 323
85 @ 683
90 @ 670
95 @ 418
100 @ 1682
pvrl_25 => 00 @ 4268
20 @ 4100
30 @ 720
40 @ 740
45 @ 775
50 @ 430
60 @ 1000
65 @ 812
75 @ 550
80 @ 1340
85 @ 1503
90 @ 670
95 @ 147
100 @ 870
pvrl_30 => 00 @ 5985
20 @ 6430
30 @ 720
40 @ 3907
45 @ 775
50 @ 3210
55 @ 6330
60 @ 1000
65 @ 1597
70 @ 5600
75 @ 550
80 @ 323
85 @ 235
90 @ 670
95 @ 147
100 @ 4466
pvrl_35 => 00 @ 7873
05 @ 6323
25 @ 7820
30 @ 720
35 @ 6800
40 @ 3150
45 @ 775
50 @ 4125
55 @ 7187
60 @ 1000
65 @ 1261
70 @ 6220
75 @ 2465
80 @ 1982
85 @ 3406
90 @ 3123
95 @ 3737
100 @ 3021
pvrl_40 => 00 @ 7937
05 @ 8148
10 @ 7250
15 @ 6770
20 @ 7680
30 @ 6782
35 @ 8117
40 @ 5930
45 @ 3850
50 @ 5037
55 @ 7770
60 @ 4697
65 @ 1184
70 @ 5280
75 @ 3395
80 @ 2808
85 @ 3712
90 @ 5775
95 @ 4580
100 @ 5200
pvrl_45 => 30 @ 720
40 @ 740
45 @ 775
50 @ 430
60 @ 1000
65 @ 530
75 @ 550
80 @ 323
85 @ 235
90 @ 670
95 @ 147
pvrl_5 => 00 @ 390 450
05 @ 260
30 @ 720
40 @ 740
45 @ 775
50 @ 430
60 @ 1000
65 @ 530 920
70 @ 549
75 @ 550
80 @ 323 220 410
85 @ 235 470
90 @ 670 790
95 @ 147 470
100 @ 230 800 300 370 529 150 120
pvfc_0 => 00 @ 44 170
05 @ 52
15 @ 92 199
20 @ 74
30 @ 278
40 @ 184
70 @ 140
75 @ 24
85 @ 10
90 @ 44
95 @ 126
100 @ 48 53 57 99 101 94 74
pvfc_10 => 20 @ 1677
30 @ 1251
35 @ 1906
40 @ 673
45 @ 1071
50 @ 662
55 @ 928
60 @ 910
65 @ 617
70 @ 442
75 @ 1283
80 @ 416
85 @ 188
90 @ 492
95 @ 322
100 @ 452
pvfc_15 => 15 @ 2941
30 @ 716
35 @ 2447
40 @ 1837
45 @ 1684
50 @ 1542
55 @ 2290
60 @ 2174
65 @ 866
70 @ 1597
75 @ 886
80 @ 720
85 @ 188
90 @ 1383
95 @ 310
100 @ 1547
pvfc_20 => 00 @ 4246
10 @ 4096
30 @ 716
40 @ 673
45 @ 891
50 @ 421
55 @ 2633
60 @ 910
65 @ 463
75 @ 1684
80 @ 296
85 @ 1130
90 @ 677
95 @ 370
100 @ 1663
pvfc_25 => 00 @ 4750
20 @ 4169
30 @ 716
40 @ 673
45 @ 891
50 @ 421
60 @ 910
65 @ 779
75 @ 715
80 @ 1181
85 @ 1499
90 @ 677
95 @ 232
100 @ 785
pvfc_30 => 00 @ 6137
20 @ 6213
30 @ 716
40 @ 4032
45 @ 891
50 @ 3044
55 @ 5770
60 @ 910
65 @ 1593
70 @ 8757
75 @ 715
80 @ 296
85 @ 188
90 @ 677
95 @ 232
100 @ 4588
pvfc_35 => 00 @ 7622
05 @ 6703
25 @ 11151
30 @ 716
35 @ 6688
40 @ 5094
45 @ 891
50 @ 3760
55 @ 6741
60 @ 910
65 @ 1196
70 @ 7259
75 @ 1558
80 @ 1711
85 @ 3704
90 @ 3658
95 @ 3359
100 @ 3592
pvfc_40 => 00 @ 7914
05 @ 8058
10 @ 7141
15 @ 10701
20 @ 7331
30 @ 6619
35 @ 8061
40 @ 5796
45 @ 3806
50 @ 5020
55 @ 5740
60 @ 5203
65 @ 1427
70 @ 6728
75 @ 2917
80 @ 3235
85 @ 3402
90 @ 4225
95 @ 3822
100 @ 4690
pvfc_45 => 30 @ 716
40 @ 673
45 @ 891
50 @ 421
60 @ 910
65 @ 463
75 @ 715
80 @ 296
85 @ 188
90 @ 677
95 @ 232
pvfc_5 => 00 @ 448 411
05 @ 314
30 @ 716
40 @ 673
45 @ 891
50 @ 421
60 @ 910
65 @ 463 1162
70 @ 741
75 @ 715
80 @ 296 314 559
85 @ 188 1042
90 @ 677 870
95 @ 232 375
100 @ 350 275 457 382 467 211 208Die Updates mache ich eigentlich immer mit sobald eine strukturelle Änderung drin ist. Kleinere Bugfix-Releases lasse ich meist aus, wenn ich den Bug bei mir nicht beobachtet habe.
Ja, das sind die Werte und passen auch.
Du hast offensichtlich keine deutsche locale "de_..." installiert wegen den engl.Wochentagen:
con_all => Thu @ 262 697
Wed @ 1574 310
Mon @ 438 1367
Sun @ 329 261
Sat @ 1103 345
Tue @ 1488
Fri @ 292 830
Das sollte keine Problem sein weil ich die locale im Modul auslese. Scheinbar gibt es da aber etwas was ich nicht bedacht habe.
Ich stelle nachher mal eine Testversion in mein contrib damit wir das herausbekommen was bei dir nicht so läuft wie vorhergesehen.
Kannst du mal noch ein "get .. valDecTree aiRawData" ausführen und einfach mal die letzten 20-30 Zeilen posten? Mich interessiert was im Schlüssel "nod" steht.
Edit: Und stelle zum Test das Attr affectConsForecastIdentWeekdays=0 falls es auf 1 steht.
Zitat von: DS_Starter am 19 Februar 2025, 11:49:20annst du mal noch ein "get .. valDecTree aiRawData" ausführen und einfach mal die letzten 20-30 Zeilen posten? Mich interessiert was im Schlüssel "nod" steht.
2025021701 => hod: 01, nod: Mon, sunaz: 9, sunalt: 0, rad1h: -, wcc: 20, rr1c: 0.00, pvrl: -, con: 224, temp: -5
2025021702 => hod: 02, nod: Mon, sunaz: 32, sunalt: 0, rad1h: -, wcc: 20, rr1c: 0.00, pvrl: -, con: 221, temp: -5
2025021703 => hod: 03, nod: Mon, sunaz: 51, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 237, temp: -5
2025021704 => hod: 04, nod: Mon, sunaz: 66, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 219, temp: -5
2025021705 => hod: 05, nod: Mon, sunaz: 79, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 220, temp: -5
2025021706 => hod: 06, nod: Mon, sunaz: 91, sunalt: 0, rad1h: -, wcc: 05, rr1c: 0.00, pvrl: -, con: 280, temp: -5
2025021707 => hod: 07, nod: Mon, sunaz: 102, sunalt: 0, rad1h: -, wcc: 10, rr1c: 0.00, pvrl: -, con: 325, temp: -5
2025021708 => hod: 08, nod: Mon, sunaz: 113, sunalt: 5, rad1h: 300, wcc: 25, rr1c: 0.00, pvrl: 950, con: 273, temp: -5
2025021709 => hod: 09, nod: Mon, sunaz: 125, sunalt: 15, rad1h: 960, wcc: 70, rr1c: 0.00, pvrl: 3570, con: 659, temp: -5
2025021710 => hod: 10, nod: Mon, sunaz: 138, sunalt: 20, rad1h: 2040, wcc: 75, rr1c: 0.00, pvrl: 6070, con: 2112, temp: -5
2025021711 => hod: 11, nod: Mon, sunaz: 153, sunalt: 25, rad1h: 3400, wcc: 65, rr1c: 0.00, pvrl: 7900, con: 2168, temp: -5
2025021712 => hod: 12, nod: Mon, sunaz: 169, sunalt: 30, rad1h: 3520, wcc: 65, rr1c: 0.00, pvrl: 8960, con: 1973, temp: 0
2025021713 => hod: 13, nod: Mon, sunaz: 186, sunalt: 30, rad1h: 4040, wcc: 30, rr1c: 0.00, pvrl: 9130, con: 2088, temp: 0
2025021714 => hod: 14, nod: Mon, sunaz: 203, sunalt: 25, rad1h: 3540, wcc: 15, rr1c: 0.00, pvrl: 8100, con: 2170, temp: 0
2025021715 => hod: 15, nod: Mon, sunaz: 218, sunalt: 20, rad1h: 2220, wcc: 45, rr1c: 0.00, pvrl: 4870, con: 2116, temp: 0
2025021716 => hod: 16, nod: Mon, sunaz: 232, sunalt: 15, rad1h: 1200, wcc: 65, rr1c: 0.00, pvrl: 2080, con: 2154, temp: 0
2025021717 => hod: 17, nod: Mon, sunaz: 244, sunalt: 5, rad1h: 420, wcc: 65, rr1c: 0.00, pvrl: 920, con: 1367, temp: 0
2025021718 => hod: 18, nod: Mon, sunaz: 255, sunalt: 0, rad1h: -, wcc: 65, rr1c: 0.00, pvrl: 30, con: 274, temp: 0
2025021719 => hod: 19, nod: Mon, sunaz: 266, sunalt: 0, rad1h: -, wcc: 60, rr1c: 0.00, pvrl: -, con: 681, temp: 0
2025021720 => hod: 20, nod: Mon, sunaz: 278, sunalt: 0, rad1h: -, wcc: 80, rr1c: 0.00, pvrl: -, con: 275, temp: 0
2025021721 => hod: 21, nod: Mon, sunaz: 290, sunalt: 0, rad1h: -, wcc: 65, rr1c: 0.00, pvrl: -, con: 338, temp: -5
2025021722 => hod: 22, nod: Mon, sunaz: 305, sunalt: 0, rad1h: -, wcc: 90, rr1c: 0.00, pvrl: -, con: 312, temp: -5
2025021723 => hod: 23, nod: Mon, sunaz: 323, sunalt: 0, rad1h: -, wcc: 90, rr1c: 0.00, pvrl: -, con: 247, temp: -5
2025021724 => hod: 24, nod: Mon, sunaz: 345, sunalt: 0, rad1h: -, wcc: 100, rr1c: 0.00, pvrl: -, con: 240, temp: -5
2025021801 => hod: 01, nod: Tue, sunaz: 9, sunalt: 0, rad1h: -, wcc: 75, rr1c: 0.00, pvrl: -, con: 232, temp: -5
2025021802 => hod: 02, nod: Tue, sunaz: 32, sunalt: 0, rad1h: -, wcc: 75, rr1c: 0.00, pvrl: -, con: 216, temp: -5
2025021803 => hod: 03, nod: Tue, sunaz: 51, sunalt: 0, rad1h: -, wcc: 90, rr1c: 0.00, pvrl: -, con: 225, temp: -5
2025021804 => hod: 04, nod: Tue, sunaz: 66, sunalt: 0, rad1h: -, wcc: 100, rr1c: 0.00, pvrl: -, con: 230, temp: -5
2025021805 => hod: 05, nod: Tue, sunaz: 79, sunalt: 0, rad1h: -, wcc: 95, rr1c: 0.00, pvrl: -, con: 212, temp: -5
2025021806 => hod: 06, nod: Tue, sunaz: 91, sunalt: 0, rad1h: -, wcc: 85, rr1c: 0.00, pvrl: -, con: 257, temp: -5
2025021807 => hod: 07, nod: Tue, sunaz: 102, sunalt: 0, rad1h: -, wcc: 70, rr1c: 0.00, pvrl: -, con: 375, temp: -5
2025021824 => hod: 24, nod: Tue, sunaz: 345, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 228, temp: -5
2025021901 => hod: 01, nod: Wed, sunaz: 9, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 234, temp: -5
2025021902 => hod: 02, nod: Wed, sunaz: 32, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 210, temp: -5
2025021903 => hod: 03, nod: Wed, sunaz: 51, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 303, temp: -10
2025021904 => hod: 04, nod: Wed, sunaz: 66, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 231, temp: -10
2025021905 => hod: 05, nod: Wed, sunaz: 79, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 221, temp: -10
2025021906 => hod: 06, nod: Wed, sunaz: 90, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 278, temp: -10
2025021907 => hod: 07, nod: Wed, sunaz: 102, sunalt: 0, rad1h: -, wcc: 00, rr1c: 0.00, pvrl: -, con: 388, temp: -10
2025021908 => hod: 08, nod: Wed, sunaz: 113, sunalt: 5, rad1h: 440, wcc: 00, rr1c: 0.00, pvrl: 1140, con: 561, temp: -10
2025021909 => hod: 09, nod: Wed, sunaz: 125, sunalt: 15, rad1h: 1680, wcc: 00, rr1c: 0.00, pvrl: 3900, con: 2033, temp: -10
2025021910 => hod: 10, nod: Wed, sunaz: 138, sunalt: 20, rad1h: 2840, wcc: 00, rr1c: 0.00, pvrl: 6800, con: 4228, temp: -5
2025021911 => hod: 11, nod: Wed, sunaz: 153, sunalt: 25, rad1h: 3740, wcc: 00, rr1c: 0.00, pvrl: 8680, con: 3564, temp: -5
2025021912 => hod: 12, nod: Wed, sunaz: 169, sunalt: 30, rad1h: 4220, wcc: 00, rr1c: 0.00, pvrl: 9580, con: 2023, temp: 0Schaut gut aus, die Zuweisung basiert auf Basis der englischen Wochentage.
Zitat von: DS_Starter am 19 Februar 2025, 11:49:20Und stelle zum Test das Attr affectConsForecastIdentWeekdays=0 falls es auf 1 steht.
Ja stand auf 1, ich habe auf 0 umgestellt, aber die Grafik hat sich auch nach mehreren automatischen Zyklen nicht sichtbar verändert, zumindest der exemlarische "0"er bei heute 16:00 ist unverändert.
Ja, das passt alles.
Ich habe dir eine Testversion ins contrib gestellt.
Mit ctrlDebug=consumption_long siehst du so eine Ausgabe:
2025.02.19 12:34:46.706 1: SolCast6 DEBUG> ################### Start Consumption forecast ###################
2025.02.19 12:34:46.709 1: SolCast6 DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.02.19 12:34:46.712 1: SolCast6 DEBUG> process Today dayname: Mi, Tomorrow dayname: Do
2025.02.19 12:34:46.722 1: SolCast6 DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
...
Poste bitte was bei dir kommt.
Habe es runtergeladen und mittels "reload" neu geladen, aber nicht neu gestartet. Lt. Log-File wurden die Routinen neu geladen, es müsste also passen.
Hier die letzte Ausgabe, alles konnte ich nicht posten, möglicherweise verletzt es irgendeine maximale Längenbeschränkung...
2025.02.19 12:53:46 1: mySolarForecast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.19 12:53:46 1: mySolarForecast DEBUG> estimated cons Tomorrow: 8567 Wh, Individual hourly values considered: 1440, exclude: 11857 Wh (avg of 7 entities)
2025.02.19 12:53:46 1: mySolarForecast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour00' hod '13' confc: 2454, confcEx: 2454
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '13' confc: 2454
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour01' hod '14' confc: 2339, confcEx: 2339
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '14' confc: 2339
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour02' hod '15' confc: -8677, confcEx: -8677
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '15' confc: -8677
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour03' hod '16' confc: 1159, confcEx: 1159
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '16' confc: 1159
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour04' hod '17' confc: -3562, confcEx: -3562
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '17' confc: -3562
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour05' hod '18' confc: 358, confcEx: 358
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '18' confc: 358
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour06' hod '19' confc: 326, confcEx: 326
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '19' confc: 326
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour07' hod '20' confc: 330, confcEx: 330
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '20' confc: 330
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour08' hod '21' confc: 387, confcEx: 387
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '21' confc: 387
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour09' hod '22' confc: 312, confcEx: 312
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '22' confc: 312
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour10' hod '23' confc: 247, confcEx: 247
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '23' confc: 247
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour11' hod '24' confc: 240, confcEx: 240
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store circular/history hod '24' confc: 240
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour12' hod '01' confc: -3767, confcEx: -3767
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour13' hod '02' confc: 240, confcEx: 240
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour14' hod '03' confc: 236, confcEx: 236
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour15' hod '04' confc: 230, confcEx: 230
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour16' hod '05' confc: 229, confcEx: 229
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour17' hod '06' confc: 240, confcEx: 240
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour18' hod '07' confc: 325, confcEx: 325
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour19' hod '08' confc: -5186, confcEx: -5186
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour20' hod '09' confc: -13530, confcEx: -13530
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour21' hod '10' confc: -6221, confcEx: -6221
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour22' hod '11' confc: -11810, confcEx: -11810
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour23' hod '12' confc: 2811, confcEx: 2811
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour24' hod '13' confc: 2454, confcEx: 2454
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour25' hod '14' confc: 2339, confcEx: 2339
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour26' hod '15' confc: -8677, confcEx: -8677
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour27' hod '16' confc: 1159, confcEx: 1159
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour28' hod '17' confc: -3562, confcEx: -3562
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour29' hod '18' confc: 358, confcEx: 358
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour30' hod '19' confc: 326, confcEx: 326
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour31' hod '20' confc: 330, confcEx: 330
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour32' hod '21' confc: 387, confcEx: 387
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour33' hod '22' confc: 312, confcEx: 312
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour34' hod '23' confc: 247, confcEx: 247
2025.02.19 12:53:46 1: mySolarForecast DEBUG> store 'NextHour35' hod '24' confc: 240, confcEx: 240
2025.02.19 12:53:46 1: mySolarForecast DEBUG> consumption calculated - day: 19, hod: 13, con: 2394 Wh
2025.02.19 12:53:46 1: mySolarForecast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 16668 Wh
2025.02.19 12:53:47 1: PERL WARNING: Use of uninitialized value $aVal in pattern match (m//) at ./FHEM/76_SolarForecast.pm line 5900.
Der Start ist weiter oben, die ersten Zeilen sind wichtig:
################### Start Consumption forecast ###################
....
Zitat von: DS_Starter am 19 Februar 2025, 13:07:31Der Start ist weiter oben, die ersten Zeilen sind wichtig:
################### Start Consumption forecast ###################
....
Sorry, so genau habe ich nicht geschaut. Für mich hat alles irgendwie gleich ausgeschaut.
Hier nun ein kompletter Block von einem "Start Consumption forecast" bis zum nächsten:
2025.02.19 12:51:46 1: mySolarForecast DEBUG> ################### Start Consumption forecast ###################
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Basics - installed locale: en_GB.UTF-8, used scheme: EN
2025.02.19 12:51:46 1: mySolarForecast DEBUG> process Today dayname: Wed, Tomorrow dayname: Thu
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Consumer '04' hist cons registered by 'exconfc' for excl. - day: 01, csme: 8000.00
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Consumer '04' hist cons registered by 'exconfc' for excl. - day: 04, csme: 6000.00
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Consumer '04' hist cons registered by 'exconfc' for excl. - day: 11, csme: 11000.00
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Consumer '04' hist cons registered by 'exconfc' for excl. - day: 12, csme: 1000.00
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Consumer '04' hist cons registered by 'exconfc' for excl. - day: 18, csme: 10000.00
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Consumer '04' hist cons registered by 'exconfc' for excl. - day: 20, csme: 5000.00
2025.02.19 12:51:46 1: mySolarForecast DEBUG> Consumer '04' hist cons registered by 'exconfc' for excl. - day: 29, csme: 42000.00
2025.02.19 12:51:46 1: mySolarForecast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 4000 Wh for Hour 01, Considered value numbers: 1
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 01: -3767 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 02: 240 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 03: 236 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 04: 230 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 05: 229 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 06: 240 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 07: 325 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 5500 Wh for Hour 08, Considered value numbers: 2
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 08: -5186 Wh, Considered value numbers: 14
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 14000 Wh for Hour 09, Considered value numbers: 1
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 09: -13530 Wh, Considered value numbers: 14
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 8333 Wh for Hour 10, Considered value numbers: 3
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 10: -6221 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 14000 Wh for Hour 11, Considered value numbers: 1
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 11: -11810 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 12: 2811 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 13: 2454 Wh, Considered value numbers: 14
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 14: 2339 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 11000 Wh for Hour 15, Considered value numbers: 1
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 15: -8677 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 16: 1159 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 4000 Wh for Hour 17, Considered value numbers: 1
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 17: -3562 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 18: 358 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 19: 326 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 20: 330 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 21: 387 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 22: 312 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 23: 247 Wh, Considered value numbers: 13
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 24: 240 Wh, Considered value numbers: 15
2025.02.19 12:51:46 1: mySolarForecast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons Tomorrow: 8567 Wh, Individual hourly values considered: 1440, exclude: 11857 Wh (avg of 7 entities)
2025.02.19 12:51:46 1: mySolarForecast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour00' hod '13' confc: 2454, confcEx: 2454
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '13' confc: 2454
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour01' hod '14' confc: 2339, confcEx: 2339
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '14' confc: 2339
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour02' hod '15' confc: -8677, confcEx: -8677
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '15' confc: -8677
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour03' hod '16' confc: 1159, confcEx: 1159
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '16' confc: 1159
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour04' hod '17' confc: -3562, confcEx: -3562
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '17' confc: -3562
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour05' hod '18' confc: 358, confcEx: 358
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '18' confc: 358
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour06' hod '19' confc: 326, confcEx: 326
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '19' confc: 326
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour07' hod '20' confc: 330, confcEx: 330
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '20' confc: 330
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour08' hod '21' confc: 387, confcEx: 387
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '21' confc: 387
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour09' hod '22' confc: 312, confcEx: 312
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '22' confc: 312
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour10' hod '23' confc: 247, confcEx: 247
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '23' confc: 247
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour11' hod '24' confc: 240, confcEx: 240
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store circular/history hod '24' confc: 240
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour12' hod '01' confc: -3767, confcEx: -3767
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour13' hod '02' confc: 240, confcEx: 240
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour14' hod '03' confc: 236, confcEx: 236
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour15' hod '04' confc: 230, confcEx: 230
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour16' hod '05' confc: 229, confcEx: 229
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour17' hod '06' confc: 240, confcEx: 240
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour18' hod '07' confc: 325, confcEx: 325
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour19' hod '08' confc: -5186, confcEx: -5186
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour20' hod '09' confc: -13530, confcEx: -13530
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour21' hod '10' confc: -6221, confcEx: -6221
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour22' hod '11' confc: -11810, confcEx: -11810
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour23' hod '12' confc: 2811, confcEx: 2811
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour24' hod '13' confc: 2454, confcEx: 2454
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour25' hod '14' confc: 2339, confcEx: 2339
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour26' hod '15' confc: -8677, confcEx: -8677
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour27' hod '16' confc: 1159, confcEx: 1159
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour28' hod '17' confc: -3562, confcEx: -3562
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour29' hod '18' confc: 358, confcEx: 358
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour30' hod '19' confc: 326, confcEx: 326
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour31' hod '20' confc: 330, confcEx: 330
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour32' hod '21' confc: 387, confcEx: 387
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour33' hod '22' confc: 312, confcEx: 312
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour34' hod '23' confc: 247, confcEx: 247
2025.02.19 12:51:46 1: mySolarForecast DEBUG> store 'NextHour35' hod '24' confc: 240, confcEx: 240
2025.02.19 12:51:46 1: mySolarForecast DEBUG> consumption calculated - day: 19, hod: 13, con: 2286 Wh
2025.02.19 12:51:46 1: mySolarForecast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 16560 Wh
Ich ahne was das Problem ist. Die hohen Excludes (E-Auto?) wobei es keine Einplanungen für die nächsten Stunden gibt wo ein entspechender Aufschlag stattfinden würde.
Falls es Einplanungen gibt, hilft die Umstellung auf exconfc=2 oder exconfc=0 des Consumers 4.
Durch:
store 'NextHour04' hod '17' confc: -3562, confcEx: -3562
ist der Forecast der Stunde 17 negativ und wird in der Grafik als 0 dargestellt. (Negativen Verbrauch gibt es im Kontext nicht).
Evtl. muß ich im Code nochmal nachbessern um ein abrutschen in das Negative zu vermeiden. Das ist aber wirklich nicht so einfach wenn Großverbraucher unregelmäßig in Betrieb sind.
affectConsForecastIdentWeekdays=1 halte ich generell für sinnvoll wenn das eigene Verbrauchsverhalten stark von den Wochentagen geprägt ist, sonst eher affectConsForecastIdentWeekdays=0.
Zitat von: DS_Starter am 19 Februar 2025, 13:45:50Ich ahne was das Problem ist. Die hohen Excludes (E-Auto?) wobei es keine Einplanungen für die nächsten Stunden gibt wo ein entspechender Aufschlag stattfinden würde.
Ich habe nur einen Verbraucher mit "exclude", nämlich die WW-Bereitung über die Wärmepumpe. Die "zieht" aber nicht mehr als 2-2,5 kW.
Kann es sein, dass es (seit dem Update) Probleme gibt, wenn Verbraucher dem gleichen FHEM-Gerät zugewiesen sind?
Die Wärmepumpe ist ein einziges Gerät, je nach Betriebsart wird der Verbrauch dann der Heizung, Kühlung oder WW zugewiesen. Es kann aber natürlich immer nur ein Betrieb auf einmal laufen, sodass pro Stunde in Summe nicht mehr als die oben genannten 2-2,5 kW zusammenkommen können.
Nachtrag: Die WW-Bereitung ist 2 Verbrauchern zugewiesen, 1x mit "must" und 1x mit "can" mit unterschiedlichen Startbedingungen. Kann es sein, dass der Verbrauch dadurch irgendwie "doppelt" registriert wird?
Die Verbraucher werden anhand ihrer Nummer, hier "4" was ich gesehen habe, verwaltet. Wenn es einen weiteren Consumer, z.B. "2" gibt, der im Prinzip das gleiche Device abbildet, wird SF diese beiden Consumer wie separate Consumer betrachten. SF "sieht" keinen Zusammenhang zwischen beiden.
Folgendes habe ich am Beispiel Hour 17 erkannt:
2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 4000 Wh for Hour 17, Considered value numbers: 1
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 17: -3562 Wh, Considered value numbers: 13
Historisch wurde ein aufgezeichneter Wert von 4000Wh für die Stunde 17 exkludiert und da es keine Einplanung für eben diese Stunde gibt der als Aufschlag in die Prognose eingehen würde geht der Zielwert in das Negative.
Entweder müsste man das exclude verhindern mit exconfc=0 oder aber eine Planung (aber keine Schaltung) ausführen lassen.
Mit "get ... valConsumerMaster 4" sieht man die geplanten Stundenleistungsbestandteile, als Beispiel:
ehodpieces => 11=10.00 12=10.00 13=10.00 14=10.00 15=10.00 ....
die als Aufschlag in den Stundenzielwert eingehen würden, aber nur sofern eine Einplanung des Consumers stattfindet. Diese "Dummyplanung" kann man durch eine geschickte consumer-Konfiguration erreichen.
An sich ist die WW-Integration oder ein E-Auto genau das Szenario welches ich mit einer KI abarbeiten möchte.
Edit: Aber ich werde im Code noch etwas anpassen um dieses Problem zu entschärfen.
Ich glaube ich habe einen Ansatz zur Verbesserung. Zeig mir mal bitte die Ausgabe von
"get ... valConsumerMaster 4"
Ich hatte Deinen Hinweis "Interessant ist hier initdaygcon." so interpretiert, dass dieser Wert zum Tagesstart Null sein kann oder eben ein ständig wachsender Zähler ist.
Bei mir wurde erst gegen 00:05 der Zähler resettet (auf Null). Ich habe es nun realisieren können, dass der Zähler um 00:00 auf Null gesetzt wird.
Daher mein Screenshot. Meintest Du andere/weitere Werte?
Zitat von: DS_Starter am 17 Februar 2025, 11:15:04ZitatBis 6:00 Uhr gab es demnach keinen Verbrauch und auch die Werte um 7 oder 8 sind deutlich zu gering.
Nicht Verbrauch, es geht um den Netzbezug, oder?
Kann es sein, dass die Einheit der Readings
contotal=Grid_Today_EnergyOut:kWh bzw feedtotal=Grid_Today_EnergyIn:kWh
nicht kWh sondern Wh sein müsste?
Ansonsten führe bitte ein "get ... pvCircular 99" aus und poste die Ausgabe.
Sie sieht etwa so aus:
99 => tdayDvtn: -, ydayDvtn: 26.22
todayConsumption: 7962, feedintotal: 2639818.8, initdayfeedin: 2639800.2
gridcontotal: 925395.7, initdaygcon: 925108.4
initdaybatintot01: 4205688.9725021, initdaybatintot02: -, initdaybatintot03: -
Interessant ist hier initdaygcon.
Zitat von: 300P am 19 Februar 2025, 08:26:14Irgenwie sprechen wir scheinbar nicht von dem gleichem......? ?
So müsste es eigentlich aussehen bei einem aktuellen Tagesverbrauch von 5047 Wh und 17.1 Wh Einspeisung bei Stunde 99
99 => tdayDvtn: 4.35, ydayDvtn: -104.16
todayConsumption: 5047, feedintotal: 2978953.8, initdayfeedin: 2978936.9
gridcontotal: 780894.4, initdaygcon: 780869.5
initdaybatintot01: 9578888, initdaybatintot02: 6686075, initdaybatintot03: -
initdaybatouttot01: 6868960, initdaybatouttot02: 4713902, initdaybatouttot03: -
batintot01: 9579845, batintot02: 6686580, batintot03: -
batouttot01: 6870720, batouttot02: 4718635, batouttot03: -
lastTsMaxSocRchd01: 1739903302, lastTsMaxSocRchd02: 1739895601, lastTsMaxSocRchd03: -
nextTsMaxSocChge01: 1741631302, nextTsMaxSocChge02: 1741623601, nextTsMaxSocChge03: -
days2care01: 19, days2care02: 19, days2care03: -
runTimeTrainAI: 0.9987, aitrainLastFinishTs: 1739927704, aiRulesNumber: 3426
attrInvChangedTs: 1736179151
@TheTrumpeter, ich habe dir die Testversion im contrib upgedatet. Bitte teste das Ergebnis in deinem Umfeld.
LG
Hallo, habe mal eine Frage, gibt es in consumer-mintime eine möglichkeit den Wert eines Readings zu übernehmen.
Habe es mit device:reading und {ReadingsVal("device","reading",0)} versucht aber scheinbar wird der Wert nicht übernommen.
Fehler: The key "mintime" must be an integer or a string starting with "SunPath."
Ich würde gerne eine Flexible mintime die in einen externen doif errechnet wird angeben.
ZitatHallo, habe mal eine Frage, gibt es in consumer-mintime eine möglichkeit den Wert eines Readings zu übernehmen.
Habe es mit device:reading und {ReadingsVal("device","reading",0)} versucht aber scheinbar wird der Wert nicht übernommen.
Fehler: The key "mintime" must be an integer or a string starting with "SunPath."
Ich würde gerne eine Flexible mintime die in einen externen doif errechnet wird angeben.
Momentan nicht, kann ich aber einbauen.
ZitatMomentan nicht, kann ich aber einbauen.
Danke, währe eine super Sache um zb. die Laufzeit einer Poolumpe nach Wassertemperatur flexibel einzuschalten.
Zitat von: DS_Starter am 19 Februar 2025, 15:11:34Ich glaube ich habe einen Ansatz zur Verbesserung. Zeig mir mal bitte die Ausgabe von
"get ... valConsumerMaster 4"
Sorry, war gestern dann nicht mehr hier...
04 => alias => Warmwasser optional
asynchron => 1
auto => 0
autoreading => solarforecast_dhw_auto
avgenergy => 2867.89
currpowerpercent => 76.1
cycleDayNum => 0
cycleStarttime => 1739956686
cycleTime => 35.7666666666667
dspignorecond =>
dswitch => Mythz
dswoffcond =>
dswoncond => Mythz
ehodpieces => 10=3000.00
energythreshold =>
epiecAVG => 1=0.00
epiecAVG_hours => 1
epiecHist => 9
epiecHist_1 => 1=0.00
epiecHist_10 => 1=0.00
epiecHist_10_hours => 0
epiecHist_1_hours => 0
epiecHist_2 => 1=0.00 2=0.00
epiecHist_2_hours => 1
epiecHist_3 => 1=0.00
epiecHist_3_hours => 0
epiecHist_4 => 1=0.00
epiecHist_4_hours => 0
epiecHist_5 => 1=0.00 2=0.00
epiecHist_5_hours => 1
epiecHist_6 => 1=0.00
epiecHist_6_hours => 0
epiecHist_7 => 1=0.00
epiecHist_7_hours => 0
epiecHist_8 => 1=0.00 2=0.00
epiecHist_8_hours => 1
epiecHist_9 => 1=0.00 2=0.00
epiecHist_9_hours => 1
epiecHour => -1
epiecStartEtotal => 5020000
epiecStartTime => 1739954050
epieces => 1=3000.00
exconfc => 1
hysteresis => 0
icon => sani_water_hot
interruptable => 0
isConsumptionRecommended => 1
isIntimeframe => 1
lastAutoOnTs => 1739953992
lastMinutesOn => 15.6166666666667
lastOnTime => 1739958838
locktime => 0:0
logoffon => off
mintime => 60
minutesOn => 0
mode => can
name => Mythz
noshow => 0
notafter => {main::min('17:00', sprintf('%02d:%02d', (split ':', main::sunset_abs('HORIZON=0',-120*60))[0], (split ':', main::sunset_abs('HORIZON=0',-120*60))[1]))}
notbefore => {main::max('08:05', sprintf('%02d:%02d', (split ':', main::sunrise_abs('HORIZON=0',120*60))[0], (split ':', main::sunrise_abs('HORIZON=0',120*60))[1]))}
offcom =>
offreg => 0
oncom => pOpMode manual
onoff => off
onreg => 1
physoffon => off
planSupplement =>
plandelete => regular
planstate => replanned: 2025-02-20 09:45:09 - 2025-02-20 10:45:09
planswitchoff => 1740044709
planswitchon => 1740041109
power => 3000
powerthreshold => 1
remainTime => 0
retotal => sElectrDHWTotal
rigncond =>
rpcurr => cur_power_dhw
rswoffcond =>
rswoncond => dhw_temp
rswstate => HeatingDHW
runtimeAvgDay => 47.27
spignorecondregex =>
startTime => 1739956686
state => off
surpmeth => SmartMeterRestAPI:pvoffset_mean_5min
swoffcondregex =>
swoncondregex => 4[0-3][.]*\d*|[0-3]\d[.]*\d*
type => heater
uetotal => kWh
upcurr => kWZitat von: DS_Starter am 19 Februar 2025, 15:44:31@TheTrumpeter, ich habe dir die Testversion im contrib upgedatet. Bitte teste das Ergebnis in deinem Umfeld.
Kann ich erst morgen Vormittag einspielen, werd's dann aber gleich rückmelden.
Zitat von: DS_Starter am 19 Februar 2025, 16:57:47ZitatHallo, habe mal eine Frage, gibt es in consumer-mintime eine möglichkeit den Wert eines Readings zu übernehmen.
Habe es mit device:reading und {ReadingsVal("device","reading",0)} versucht aber scheinbar wird der Wert nicht übernommen.
Fehler: The key "mintime" must be an integer or a string starting with "SunPath."
Ich würde gerne eine Flexible mintime die in einen externen doif errechnet wird angeben.
Momentan nicht, kann ich aber einbauen.
Wär's nicht generell einfacher die komplexe Consumer-Konfiguration in mehrere Attribute auszulagern wie es z.B. beim ModbusTCP-Modul üblich ist? Da werden die Eigenschaften für einen Wert über mehrere Attribute mit gleichem Prefix konfiguriert.
Hier wäre es sinngemäss "Consumer[xx]alias", "Consumer[xx]mintime", "Consumer[xx]bla". Manche Dinge sind mandatory, andere optional. So könnte man sehr einfach bedarfsgerechte Änderungen von Außen vornehmen.
Im konkreten Fall könnte der User das mittels "attr SolarForecast Consumer[xx]mintime 90" machen, ohne das gesamte komplexe "Consumer[xx]"-Attribut verändern zu müssen. Dann müsstest Du auch nicht für solche und ähnliche Wünsche das Modul immer wieder ändern und flexibler/komplexer machen.
ZitatWär's nicht generell einfacher die komplexe Consumer-Konfiguration in mehrere Attribute auszulagern wie es z.B. beim ModbusTCP-Modul üblich ist? Da werden die Eigenschaften für einen Wert über mehrere Attribute mit gleichem Prefix konfiguriert.
Nein. Wir können aktuell 16 Consumer mit jeweils 24 Schlüsseln einbinden. Das wären 384 Attribute.
Wir hatte früher eine Unmenge Attribute und ich habe deswegen diese Aggregationen vorgenommen und versuche Schritt für Schritt die Anzahl der Attr weiter zu senken wo es sinnvoll ist.
Das ist also kein Weg und es besteht dazu auch keine Notwendigkeit.
ZitatHier wäre es sinngemäss "Consumer[xx]alias", "Consumer[xx]mintime", "Consumer[xx]bla". Manche Dinge sind mandatory, andere optional. So könnte man sehr einfach bedarfsgerechte Änderungen von Außen vornehmen.
Im konkreten Fall könnte der User das mittels "attr SolarForecast Consumer[xx]mintime 90" machen, ohne das gesamte komplexe "Consumer[xx]"-Attribut verändern zu müssen. Dann müsstest Du auch nicht für solche und ähnliche Wünsche das Modul immer wieder ändern und flexibler/komplexer machen.
Was die Attribute können, muß auch im Code verarbeitet werden. Eine Anpassung ist für mich auf jeden Fall nötig. Es lässt sich mit der aktuellen Architektur sehr gut (auch für mich) lösen.
Für den Nutzer ist es auch sehr einfach ein Attribut zu ändern. In der Struktur kann man die Schlüssel auch jeweils in eine separate Zeile oder, in thematische Blöcke zusammengefasst, in mehrere Zeilen schrieben und hat so einen schnellen Überblick. Also z.B. so:
deCONZ_HUEDevice1:Tablet+Flur icon=tablet type=charger
power=0 pcurr=power:W etotal=consumption:Wh
auto=automatic
on=on off=off
mintime=1430
interruptable=samsunggalaxy.fully:batterylevel:[4-9][0-9]|[0-9]{3}:50
Es ist ein Handgriff für den User hier etwas zu ändern. Dem Modul ist es egal, dass es ein paar Werte mehr prüfen und verarbeiten muß beim speichern.
@TheTrumpeter, wie sieht denn heute deine Verbrauchsvorhersage aus falls du das heutige Update schon gemacht hast?
Zitat von: DS_Starter am 20 Februar 2025, 10:37:42@TheTrumpeter, wie sieht denn heute deine Verbrauchsvorhersage aus falls du das heutige Update schon gemacht hast?
Hab's jetzt gemacht.
(Vom Conrib kann ich unterwegs nix einspielen, aber ein normales Update geht grundsätzlich. Tu's nur nicht gerne, weil wenn's zu Problemen kommt ist es von daheim aus grundsätzlich einfacher zu lösen.)
Prognose schaut gut aus, keine "0"en und die Vorhersage ist grundsätzlich plausibel. Vor dem Update waren einzelne Stunden auf 0, der Rest auch plausibel.
Hallo guten Tag,
ich habe eine Frage: seit einem FHEM-Update am 18.02.25 wird der Ladezustand meiner Batterie im Solarforecast-Modul (Graphik -"Spinne") nicht mehr angezeigt - nur noch "0".
Im Reading "Current_BatCharge_01" steht aktuell der richtige SOC-Wert drin.
Hat sich etwas grundlegend geändert ? Wo könnte der Fehler stecken?
VLG Hardy
Der bekannte Fehler in der Konfiguration :
Ergänze die Einrichtung um den ,,cap"=xyxyx (Text genau lesen)
Dann klappt es wieder ;)
Gruß aus der Sonne
300P
Dankeschön - das hat sofort geholfen; ich hatte bei cap=2000 die Einheit Wh direkt dahinter (cap=2000Wh)
bis letzten Montag hat das nicht geschadet
Ihr seid SPITZE Jungs !!! :)
Hallo zusammen,
die PV und Verbrauchswerte sind nach einem Tag nun plausibel - ohne weitere Änderungen.
Eine Frage noch zur Definition des Akkus.
intotal Reading welches die totale Batterieladung als fortlaufenden Zähler liefert (optional)
outtotal Reading welches die totale Batterieentladung als fortlaufenden Zähler liefert (optional)
Bei den Verbrauchswerten war explizit erwähnt, dass ein Zurücksetzen auf Null zum Tagesstart verarbeitet wird (mit Eintrag im Log).
Hier bei den beiden Attributen ist dies nicht erwähnt. Gibt es diese Funktion hier tatsächlich nicht oder ist diese lediglich nicht dokumentiert?
Danke Euch und schöne Grüße
Dirk
Hallo Dirk,
bei den Batterien habe ich es auch eingebaut, dass ein Zurücksetzen auf 0 behandelt wird.
Aktuell wird es nicht im Log protokolliert. Das würde ich noch einbauen und im kommenden Release auch in der Doku vermerken.
LG,
Heiko
Hallo Heiko,
das ist ja perfekt, Danke.
Meine Verbrauchswerte werden ja jetzt korrekt angezeigt und es gab auch eine plausible Prognose für den morgigen Tag. Gestern habe ich ein Update per FHEM gemacht und danach und auch heute erscheint ein hoher negativer Wert in der Verbrauchsprognose. Muss ich nach dem Update einen Reset machen?
Schöne Grüße Dirk
Hallo Dirk,
im Normalfall muß man nach einem Update nichts machen.
Bei dir könnte es wegen der anfänglichen Schwierigkeiten nötig sein.
Kannst du bitte die Ausgabe von "get ... pvCircular" posten?
Das dürfte etwas länger sein. Wenn es den Rahmen sprengen sollte, bitte den Inhalt von 'con_all' jeder Stunde herauskopieren und posten.
Aktuell sind dies die Werte, die ausgegeben werden:
Verbrauch aktuell: 695 W nächste 4h: 3818 Wh Rest heute: 4402 Wh morgen: -86762 Wh
Ich habe den con_all im Excel gefiltert, sonst wäre es tatsächlich reichlich lang geworden.
01 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Mo @ 0
Do @ 0 1000
Fr @ 0 210
Sa @ 0 1080
Mi @ 1040
Di @ 0
So @ 0
02 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Sa @ 0 330
Mo @ 0
Do @ 0 990
Fr @ 0 340
So @ 0
Mi @ 930
Di @ 0
03 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => So @ 0
Sa @ 0 599
Di @ 0
Fr @ 0 870
Mi @ 970
Do @ 0 900
Mo @ 0
04 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Sa @ 0 491
Mo @ 0
Do @ 0 750
Fr @ 0 350
So @ 0
Mi @ 960
Di @ 0
05 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Do @ 0 790
Mo @ 0
Fr @ 0 750
Sa @ 0 1040
Di @ 0
Mi @ 930
So @ 0
06 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Sa @ 0 350
Do @ 0 840
Mo @ 0
Fr @ 0 750
So @ 0
Di @ 0
Mi @ 1040
07 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => So @ 0
Mi @ 1630
Di @ 0
Sa @ 0 650
Mo @ 0
Do @ 0 870
Fr @ 0 860
08 => pvapifc: 50, pvaifc: -, pvfc: 50, aihit: 0, pvrl: 0
con_all => So @ 2
Mi @ 1500
Di @ 10
Sa @ 0 350
Mo @ 6
Do @ 0 1150
Fr @ 0 640
pvrl_0 => 15 @ 7
35 @ 11
70 @ 2
100 @ 20
pvfc_0 => 15 @ 14
35 @ 16
70 @ 5
100 @ 14
09 => pvapifc: 473, pvaifc: -, pvfc: 473, aihit: 0, pvrl: 270
con_all => So @ 339
Mi @ 1795
Di @ 813
Sa @ 48 1208
Fr @ 10 955
Mo @ 817
Do @ 0 1336
pvrl_10 => 90 @ 270
100 @ 116 161
pvrl_5 => 00 @ 846 832
85 @ 347
95 @ 11
100 @ 49 763
pvfc_10 => 90 @ 468
100 @ 221 200
pvfc_5 => 00 @ 682 864
85 @ 619
95 @ 279
100 @ 346 127
10 => pvapifc: 1744, pvaifc: -, pvfc: 1744, aihit: 0, pvrl: 1288
con_all => Sa @ 369 1280
Fr @ 258 579
Do @ 44 1304
Mo @ 1980
So @ 1927
Di @ 2005
Mi @ 1805
pvrl_15 => 00 @ 1943 2025 2021
80 @ 259 371
100 @ 45 1595 601 439 1288
pvfc_15 => 00 @ 1652 1964 1792
80 @ 937 262
100 @ 455 136 591 1245 1259
11 => pvapifc: 2541, pvaifc: -, pvfc: 2541, aihit: 0, pvrl: 1651
con_all => Sa @ 781 1636
Fr @ 683 1029
Mo @ 2657
Do @ 203 1967
So @ 2167
Mi @ 2189
Di @ 2697
pvrl_20 => 00 @ 2667
05 @ 2184
65 @ 691
85 @ 2203
95 @ 203 786 2712
100 @ 1964 1019 1651
pvfc_20 => 00 @ 2305
05 @ 2213
65 @ 1493
85 @ 2011
95 @ 1604 238 1223
100 @ 1366 2595 1540
12 => pvapifc: 2778, pvaifc: -, pvfc: 2778, aihit: 0, pvrl: 1442
con_all => Sa @ 1304 1442
So @ 2762
Do @ 403 2751
Mo @ 2853
Di @ 2771
Fr @ 611 1538
Mi @ 2301
pvrl_25 => 00 @ 2877 2820
75 @ 619 1322
90 @ 1569
95 @ 408
100 @ 2796 2326 2776 1442
pvfc_25 => 00 @ 2649 2908
75 @ 1463 1031
90 @ 2274
95 @ 1075
100 @ 2396 2755 1943 2632
13 => pvapifc: 1790, pvaifc: -, pvfc: 1790, aihit: 0, pvrl: 1411
con_all => So @ 2608
Di @ 2584
Mi @ 1994
Sa @ 1359 1402
Do @ 499 1944
Mo @ 2729
Fr @ 654 1849
pvrl_25 => 00 @ 2784
40 @ 1359
100 @ 500 655 2652
pvrl_30 => 00 @ 2591
55 @ 1856
100 @ 2000 1954 1411
pvfc_25 => 00 @ 2741
40 @ 2460
100 @ 1110 570 1707
pvfc_30 => 00 @ 2782
55 @ 2437
100 @ 2459 1586 1790
14 => pvapifc: 1167, pvaifc: -, pvfc: 1167, aihit: 0, pvrl: 648
con_all => Mi @ 2369
Di @ 11892
So @ 2162
Fr @ 436 1671
Mo @ 2436
Do @ 242 1642
Sa @ 1516
pvrl_25 => 00 @ 2444 2538
80 @ 1528
100 @ 244 439 2186 2393
pvrl_30 => 45 @ 1693
100 @ 1646
pvfc_25 => 00 @ 2794 2458
80 @ 2340
100 @ 1095 286 1310 942
pvfc_30 => 45 @ 2638
100 @ 1988
15 => pvapifc: 1025, pvaifc: -, pvfc: 1025, aihit: 0, pvrl: 1631
con_all => Sa @ 1140
Fr @ 309 1604
Do @ 96 1497
Mo @ 2047
So @ 2028
Di @ 13281
Mi @ 2263
pvrl_20 => 100 @ 98 309
pvrl_25 => 00 @ 2067 2136
30 @ 2054
95 @ 1510
100 @ 1155 2263 1631
pvfc_20 => 100 @ 689 101
pvfc_25 => 00 @ 2521 2085
30 @ 2453
95 @ 1527
100 @ 1301 1797 2429
16 => pvapifc: 1035, pvaifc: -, pvfc: 1035, aihit: 0, pvrl: 1323
con_all => So @ 1446
Mi @ 1181
Di @ 1566
Sa @ 798
Fr @ 136 1320
Mo @ 1506
Do @ 110 466
pvrl_15 => 100 @ 110 137 800
pvrl_20 => 00 @ 1516 1565
30 @ 1469
100 @ 1188 461 1323
pvfc_15 => 100 @ 543 110 306
pvfc_20 => 00 @ 1917 1536
30 @ 1866
100 @ 1574 475 1170
17 => pvapifc: 262, pvaifc: -, pvfc: 262, aihit: 0, pvrl: 780
con_all => Di @ 700
Mi @ 1007
So @ 739
Fr @ 45 774
Do @ 52 251
Mo @ 288
Sa @ 359
pvrl_10 => 00 @ 760
05 @ 743
50 @ 714
70 @ 780
90 @ 1019
100 @ 22 52 45 362 261
pvfc_10 => 00 @ 1076
05 @ 1043
50 @ 1000
70 @ 979
90 @ 828
100 @ 275 172 48 106 59
18 => pvapifc: 101, pvaifc: -, pvfc: 101, aihit: 0, pvrl: 176
con_all => Sa @ 9795
So @ 205
Do @ 3 14
Mo @ 175
Fr @ 2 176
Di @ 392
Mi @ 7 273
pvrl_0 => 100 @ 7 4 2 45
pvrl_5 => 00 @ 205
20 @ 215
75 @ 176
100 @ 392 273 14
pvfc_0 => 100 @ 50 8 11 27
pvfc_5 => 00 @ 198
20 @ 178
75 @ 251
100 @ 181 299 61
19 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Fr @ 0 0
Mo @ 0
Do @ 19390 10
Sa @ 2060
Mi @ 0 0
Di @ 0
So @ 2
20 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Di @ 0
Fr @ 0 380
Mi @ 0 0
Do @ 1550 0
Sa @ 1180
So @ 0
21 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Mi @ -1 0
Fr @ 0 1520
Di @ 480
Mo @ 0
Do @ 1890 0
Sa @ 1320
So @ 0
22 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => So @ 0
Mi @ -1 0
Di @ 1290
Sa @ 1060
Do @ 1370 10
Fr @ 0 1020
23 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Mi @ 0 550
Di @ 1140
So @ 0
Mo @ 0
Do @ 1130 0
Fr @ 0 1210
Sa @ 1090
24 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => Mo @ 0
Do @ 1050 0
Fr @ 0 480
Sa @ 970
Mi @ 0 1020
Di @ 1040
So @ 0
99 => tdayDvtn: -, ydayDvtn: 34.42
Das sieht im Prinzip gut aus. Es gibt ein paar wenige negative Einträge wie z.B.
22 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
con_all => So @ 0
Mi @ -1 0
Ist aber kein Problem. Mit zunehmender Werteanzahl richtet der Median das. Wohin es geht sieht man hier z.B.:
11 => pvapifc: 2541, pvaifc: -, pvfc: 2541, aihit: 0, pvrl: 1651
con_all => Sa @ 781 1636
Fr @ 683 1029
Mo @ 2657
Do @ 203 1967
So @ 2167
Mi @ 2189
An dieser Stelle erstmal o.K. soweit.
Wichtig ist dann noch was sich im Schlüssel "con" in der pvHistory findet. Ein "get ...pvHistory" zeigt z.B.
03 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: -
etotali01: 63378810, etotali02: 3048200, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: 0, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 797, con: 634, gcons: 24, conprice: 0.2958
gfeedin: 0, feedprice: 0.1269
DoN: -, sunaz: 2, sunalt: -55
batintotal01: 4096349.85321095, batintotal02: -, batintotal03: -
batouttotal01: 3960172.19016563, batouttotal02: -, batouttotal03: -
batsoc01: 33, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 610, batout02: -, batout03: -
weatherid: -, wcc: 0, rr1c: 0, pvcorrf: 1.00/-
csmt01: 1383.3, csme01: 18.28, minutescsm01: 18
minutescsm02: 0
csmt03: 3535.17, csme03: 0, minutescsm03: 0
csmt04: 1745075.9, csme04: 113.09999999986, minutescsm04: 60
csmt05: 922.45, csme05: 0, minutescsm05: 0
csmt06: 1564.23, csme06: 5.95000000000005, minutescsm06: 37
csmt07: 0, csme07: 0, minutescsm07: 0
csmt08: 42200, csme08: 0, minutescsm08: 0
csmt09: 152235.1, csme09: 34.8000000000175, minutescsm09: 42
minutescsm10: 0
Der Schlüssel "con" zeigt den Verbrauch (Wh) am ausgewählten Tag und der jeweiligen Stunde. Hier könnten sich negative Werte verstecken die sich auswirken.
Du könntest bei Bedarf ein "set ... reset consumptionHistory" anwenden bei Bedarf. Man kann auch warten. Diese Werte bleiben maximal 31 Tage erhalten.
Hallo Heiko,
hab ein relativ wohl seltenes Phänomen.
Ab und an habe ich bei meinen 2 Batterien eine nicht ganz schlüssige Darstellung der Energieflüsse.
Die Gesamtsumme aller Berechnungen ist stimmig!
Dadurch das die eine Batterie ,,läd" und die andere ,,entläd" wird der Energiefluss mit einer ,,Lücke" dargestellt.
Ich weiß zwar das man eigentlich keine 2 SBS25 in einem Netz haben sollte, aber es ist nun mal so das es so ist
Anbei ein paar Screenshots die das Darstellungsproblem zeigen.
In einem Screenshot ganz unten sind die beiden SBS25 mit den aktuellen Leistungswerten (551 W / -786 W = 236 W) sichbar.
Gibt da evtl. eine Möglichkeit irgendwelche durch Einrichtungsparameter diese Darstellung zu vermeiden?
Gruß aus der Ferne / Urlaub
300P
Vielen Dank für die Hilfe, Heiko.
Einen negativen con-Wert finde ich hier nicht:
12 => 17 => pvfc: 275, pvrl: 22, pvrlvd: 1, rad1h: 270
confc: -, con: -, gcons: -, conprice: -
18 => pvfc: 50, pvrl: 7, pvrlvd: 1, rad1h: 40
confc: -, con: -, gcons: -, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
99 => pvfc: 325, pvrl: 29, pvrlvd: -, rad1h: -
confc: -, con: -, gcons: -, conprice: -
13 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
08 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: -, conprice: -
09 => pvfc: 85, pvrl: 0, pvrlvd: 1, rad1h: 80
confc: -, con: -, gcons: -, conprice: -
10 => pvfc: 455, pvrl: 45, pvrlvd: 1, rad1h: 390
confc: -, con: -, gcons: -, conprice: -
11 => pvfc: 1604, pvrl: 203, pvrlvd: 1, rad1h: 1480
confc: -, con: -, gcons: -, conprice: -
12 => pvfc: 1075, pvrl: 408, pvrlvd: 1, rad1h: 920
confc: -, con: -, gcons: -, conprice: -
13 => pvfc: 1110, pvrl: 500, pvrlvd: 1, rad1h: 940
confc: -, con: -, gcons: -, conprice: -
14 => pvfc: 1095, pvrl: 244, pvrlvd: 1, rad1h: 920
confc: -, con: -, gcons: -, conprice: -
15 => pvfc: 689, pvrl: 98, pvrlvd: 1, rad1h: 570
confc: -, con: -, gcons: -, conprice: -
16 => pvfc: 543, pvrl: 110, pvrlvd: 1, rad1h: 460
confc: -, con: -, gcons: -, conprice: -
17 => pvfc: 172, pvrl: 52, pvrlvd: 1, rad1h: 260
confc: 22, con: -, gcons: -, conprice: -
18 => pvfc: 8, pvrl: 4, pvrlvd: 1, rad1h: 40
confc: 7, con: -, gcons: -, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 19390, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1550, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -1, con: -, gcons: 1890, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -1, con: -, gcons: 1370, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1130, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1050, conprice: -
99 => pvfc: 6836, pvrl: 1664, pvrlvd: -, rad1h: -
confc: 27, con: -, gcons: 26380, conprice: -
14 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
08 => pvfc: 1, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
09 => pvfc: 279, pvrl: 11, pvrlvd: 1, rad1h: 250
confc: -, con: -, gcons: 0, conprice: -
10 => pvfc: 937, pvrl: 259, pvrlvd: 1, rad1h: 860
confc: 44, con: -, gcons: 0, conprice: -
11 => pvfc: 1493, pvrl: 691, pvrlvd: 1, rad1h: 1380
confc: 203, con: -, gcons: 0, conprice: -
12 => pvfc: 1463, pvrl: 619, pvrlvd: 1, rad1h: 1320
confc: 403, con: -, gcons: 0, conprice: -
13 => pvfc: 570, pvrl: 655, pvrlvd: 1, rad1h: 1100
confc: 499, con: -, gcons: 0, conprice: -
14 => pvfc: 286, pvrl: 439, pvrlvd: 1, rad1h: 1100
confc: 242, con: -, gcons: 0, conprice: -
15 => pvfc: 101, pvrl: 309, pvrlvd: 1, rad1h: 610
confc: 96, con: -, gcons: 0, conprice: -
16 => pvfc: 110, pvrl: 137, pvrlvd: 1, rad1h: 460
confc: 110, con: -, gcons: 0, conprice: -
17 => pvfc: 48, pvrl: 45, pvrlvd: 1, rad1h: 240
confc: 37, con: -, gcons: 0, conprice: -
18 => pvfc: 11, pvrl: 2, pvrlvd: 1, rad1h: 40
confc: 5, con: -, gcons: 0, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 19390, con: -, gcons: 0, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1550, con: -, gcons: 0, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 944, con: -, gcons: 0, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 684, con: -, gcons: 0, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1130, con: -, gcons: 0, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1050, con: -, gcons: 0, conprice: -
99 => pvfc: 5299, pvrl: 3167, pvrlvd: -, rad1h: -
confc: 26387, con: -, gcons: 0, conprice: -
15 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
08 => pvfc: 1, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
09 => pvfc: 346, pvrl: 49, pvrlvd: 1, rad1h: 310
confc: 10, con: -, gcons: 0, conprice: -
10 => pvfc: 262, pvrl: 371, pvrlvd: 1, rad1h: 840
confc: 258, con: -, gcons: 0, conprice: -
11 => pvfc: 238, pvrl: 786, pvrlvd: 1, rad1h: 1740
confc: 683, con: -, gcons: 0, conprice: -
12 => pvfc: 1031, pvrl: 1322, pvrlvd: 1, rad1h: 2400
confc: 611, con: -, gcons: 0, conprice: -
13 => pvfc: 2460, pvrl: 1359, pvrlvd: 1, rad1h: 2380
confc: 654, con: -, gcons: 0, conprice: -
14 => pvfc: 2340, pvrl: 1528, pvrlvd: 1, rad1h: 2130
confc: 436, con: -, gcons: 0, conprice: -
15 => pvfc: 1301, pvrl: 1155, pvrlvd: 1, rad1h: 1090
confc: 309, con: -, gcons: 0, conprice: -
16 => pvfc: 306, pvrl: 800, pvrlvd: 1, rad1h: 670
confc: 136, con: -, gcons: 0, conprice: -
17 => pvfc: 106, pvrl: 362, pvrlvd: 1, rad1h: 340
confc: 45, con: -, gcons: 0, conprice: -
18 => pvfc: 27, pvrl: 45, pvrlvd: 1, rad1h: 60
confc: 2, con: -, gcons: 9750, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 2090, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1180, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1320, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1060, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1090, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 970, conprice: -
99 => pvfc: 8418, pvrl: 7777, pvrlvd: -, rad1h: -
confc: 3144, con: -, gcons: 17460, conprice: -
16 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
08 => pvfc: 5, pvrl: 2, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
09 => pvfc: 619, pvrl: 347, pvrlvd: 1, rad1h: 620
confc: -, con: -, gcons: 0, conprice: -
10 => pvfc: 1652, pvrl: 1943, pvrlvd: 1, rad1h: 1690
confc: -, con: -, gcons: 0, conprice: -
11 => pvfc: 2213, pvrl: 2184, pvrlvd: 1, rad1h: 2240
confc: -, con: -, gcons: 0, conprice: -
12 => pvfc: 2396, pvrl: 2796, pvrlvd: 1, rad1h: 2300
confc: -, con: -, gcons: 0, conprice: -
13 => pvfc: 1707, pvrl: 2652, pvrlvd: 1, rad1h: 2320
confc: -, con: -, gcons: 0, conprice: -
14 => pvfc: 1310, pvrl: 2186, pvrlvd: 1, rad1h: 2490
confc: -, con: -, gcons: 0, conprice: -
15 => pvfc: 2453, pvrl: 2054, pvrlvd: 1, rad1h: 2270
confc: -, con: -, gcons: 0, conprice: -
16 => pvfc: 1866, pvrl: 1469, pvrlvd: 1, rad1h: 1660
confc: -, con: -, gcons: 0, conprice: -
17 => pvfc: 1043, pvrl: 743, pvrlvd: 1, rad1h: 860
confc: -, con: -, gcons: 0, conprice: -
18 => pvfc: 178, pvrl: 215, pvrlvd: 1, rad1h: 140
confc: -, con: -, gcons: 0, conprice: -
19 => pvfc: 0, pvrl: 2, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1320, con: -, gcons: 0, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1060, con: -, gcons: 0, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1090, con: -, gcons: 0, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 970, con: -, gcons: 0, conprice: -
99 => pvfc: 15442, pvrl: 16593, pvrlvd: -, rad1h: -
confc: 4440, con: -, gcons: 0, conprice: -
17 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
08 => pvfc: 14, pvrl: 7, pvrlvd: 1, rad1h: 10
confc: 2, con: -, gcons: 0, conprice: -
09 => pvfc: 682, pvrl: 846, pvrlvd: 1, rad1h: 680
confc: 339, con: -, gcons: 0, conprice: -
10 => pvfc: 1964, pvrl: 2025, pvrlvd: 1, rad1h: 1690
confc: 1927, con: -, gcons: 0, conprice: -
11 => pvfc: 2305, pvrl: 2667, pvrlvd: 1, rad1h: 2370
confc: 2167, con: -, gcons: 0, conprice: -
12 => pvfc: 2649, pvrl: 2877, pvrlvd: 1, rad1h: 2720
confc: 2762, con: -, gcons: 0, conprice: -
13 => pvfc: 2741, pvrl: 2784, pvrlvd: 1, rad1h: 2800
confc: 2608, con: -, gcons: 0, conprice: -
14 => pvfc: 2794, pvrl: 2444, pvrlvd: 1, rad1h: 2740
confc: 2162, con: -, gcons: 0, conprice: -
15 => pvfc: 2521, pvrl: 2067, pvrlvd: 1, rad1h: 2370
confc: 2028, con: -, gcons: 0, conprice: -
16 => pvfc: 1917, pvrl: 1516, pvrlvd: 1, rad1h: 1710
confc: 1446, con: -, gcons: 0, conprice: -
17 => pvfc: 1076, pvrl: 760, pvrlvd: 1, rad1h: 880
confc: 739, con: -, gcons: 0, conprice: -
18 => pvfc: 198, pvrl: 205, pvrlvd: 1, rad1h: 150
confc: 205, con: -, gcons: 0, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 2, con: -, gcons: 0, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1320, con: -, gcons: 0, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1060, con: -, gcons: 0, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1090, con: -, gcons: 0, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 970, con: -, gcons: 0, conprice: -
99 => pvfc: 18861, pvrl: 18198, pvrlvd: -, rad1h: -
confc: 20827, con: -, gcons: 0, conprice: -
18 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 0, conprice: -
08 => pvfc: 16, pvrl: 11, pvrlvd: 1, rad1h: 10
confc: 4, con: -, gcons: 0, conprice: -
09 => pvfc: 864, pvrl: 832, pvrlvd: 1, rad1h: 690
confc: 578, con: -, gcons: 0, conprice: -
10 => pvfc: 1792, pvrl: 2021, pvrlvd: 1, rad1h: 1630
confc: 1954, con: -, gcons: 0, conprice: -
11 => pvfc: 1223, pvrl: 2712, pvrlvd: 1, rad1h: 2280
confc: 2412, con: -, gcons: 0, conprice: -
12 => pvfc: 2908, pvrl: 2820, pvrlvd: 1, rad1h: 2740
confc: 2808, con: -, gcons: 0, conprice: -
13 => pvfc: 2782, pvrl: 2591, pvrlvd: 1, rad1h: 2830
confc: 2668, con: -, gcons: 0, conprice: -
14 => pvfc: 2458, pvrl: 2538, pvrlvd: 1, rad1h: 2750
confc: 2299, con: -, gcons: 9390, conprice: -
15 => pvfc: 2085, pvrl: 2136, pvrlvd: 1, rad1h: 2380
confc: 2038, con: -, gcons: 11150, conprice: -
16 => pvfc: 1536, pvrl: 1565, pvrlvd: 1, rad1h: 1720
confc: 1476, con: -, gcons: 20, conprice: -
17 => pvfc: 1000, pvrl: 714, pvrlvd: 1, rad1h: 830
confc: 514, con: -, gcons: 0, conprice: -
18 => pvfc: 181, pvrl: 392, pvrlvd: 1, rad1h: 140
confc: 190, con: -, gcons: 10, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 2, con: -, gcons: 10, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -10, con: -, gcons: 10, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1320, con: -, gcons: 480, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 525, con: -, gcons: 1290, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1090, con: -, gcons: 1140, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 970, con: -, gcons: 1040, conprice: -
99 => pvfc: 16845, pvrl: 18332, pvrlvd: -, rad1h: -
confc: 20838, con: -, gcons: 24540, conprice: -
19 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1040, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 930, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 970, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 960, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 930, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1040, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: -, gcons: 1630, conprice: -
08 => pvfc: 14, pvrl: 20, pvrlvd: 1, rad1h: 20
confc: 6, con: 1500, gcons: 1480, conprice: -
09 => pvfc: 127, pvrl: 763, pvrlvd: 1, rad1h: 450
confc: 813, con: 1795, gcons: 1070, conprice: -
10 => pvfc: 136, pvrl: 1595, pvrlvd: 1, rad1h: 1270
confc: 1980, con: 1805, gcons: 210, conprice: -
11 => pvfc: 2011, pvrl: 2203, pvrlvd: 1, rad1h: 1910
confc: 2657, con: 2189, gcons: 10, conprice: -
12 => pvfc: 2755, pvrl: 2326, pvrlvd: 1, rad1h: 2200
confc: 2771, con: 2301, gcons: 0, conprice: -
13 => pvfc: 2459, pvrl: 2000, pvrlvd: 1, rad1h: 2270
confc: 2608, con: 1994, gcons: 0, conprice: -
14 => pvfc: 942, pvrl: 2393, pvrlvd: 1, rad1h: 2090
confc: 2162, con: 2369, gcons: 10, conprice: -
15 => pvfc: 1797, pvrl: 2263, pvrlvd: 1, rad1h: 1760
confc: 2047, con: 2263, gcons: 0, conprice: -
16 => pvfc: 1574, pvrl: 1188, pvrlvd: 1, rad1h: 1350
confc: 1506, con: 1181, gcons: 10, conprice: -
17 => pvfc: 828, pvrl: 1019, pvrlvd: 1, rad1h: 690
confc: 700, con: 1007, gcons: 0, conprice: -
18 => pvfc: 299, pvrl: 273, pvrlvd: 1, rad1h: 140
confc: 205, con: 273, gcons: 10, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 2, con: 0, gcons: 10, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -10, con: 0, gcons: 10, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 900, con: 0, gcons: 0, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1060, con: 0, gcons: 10, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1115, con: 550, gcons: 550, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1005, con: 1020, gcons: 1020, conprice: -
99 => pvfc: 12942, pvrl: 16043, pvrlvd: -, rad1h: -
confc: 21527, con: 20247, gcons: 11900, conprice: -
20 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 1000, gcons: 1000, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 990, gcons: 990, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 900, gcons: 900, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 750, gcons: 750, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 790, gcons: 790, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 840, gcons: 840, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 870, gcons: 870, conprice: -
08 => pvfc: 16, pvrl: 0, pvrlvd: 1, rad1h: 20
confc: 1500, con: 1150, gcons: 1150, conprice: -
09 => pvfc: 221, pvrl: 116, pvrlvd: 1, rad1h: 190
confc: 1795, con: 1336, gcons: 1220, conprice: -
10 => pvfc: 591, pvrl: 601, pvrlvd: 1, rad1h: 580
confc: 1805, con: 1304, gcons: 740, conprice: -
11 => pvfc: 1366, pvrl: 1964, pvrlvd: 1, rad1h: 1160
confc: 2189, con: 1967, gcons: 10, conprice: -
12 => pvfc: 1943, pvrl: 2776, pvrlvd: 1, rad1h: 1760
confc: 2301, con: 2751, gcons: 0, conprice: -
13 => pvfc: 1586, pvrl: 1954, pvrlvd: 1, rad1h: 1720
confc: 1994, con: 1944, gcons: 10, conprice: -
14 => pvfc: 1988, pvrl: 1646, pvrlvd: 1, rad1h: 1740
confc: 2369, con: 1642, gcons: 0, conprice: -
15 => pvfc: 1527, pvrl: 1510, pvrlvd: 1, rad1h: 1310
confc: 2263, con: 1497, gcons: 0, conprice: -
16 => pvfc: 475, pvrl: 461, pvrlvd: 1, rad1h: 530
confc: 1181, con: 466, gcons: 10, conprice: -
17 => pvfc: 59, pvrl: 261, pvrlvd: 1, rad1h: 140
confc: 1007, con: 251, gcons: 0, conprice: -
18 => pvfc: 61, pvrl: 14, pvrlvd: 1, rad1h: 40
confc: 273, con: 14, gcons: 10, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 10, gcons: 10, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 0, gcons: 0, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 0, gcons: 0, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: -, con: 10, gcons: 10, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 550, con: 0, gcons: 0, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1020, con: 0, gcons: 0, conprice: -
99 => pvfc: 9833, pvrl: 11303, pvrlvd: -, rad1h: -
confc: 20247, con: 20482, gcons: 9310, conprice: -
21 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 1000, con: 210, gcons: 210, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 990, con: 340, gcons: 340, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 900, con: 870, gcons: 870, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 750, con: 350, gcons: 350, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 790, con: 750, gcons: 750, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 840, con: 750, gcons: 750, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 870, con: 860, gcons: 860, conprice: -
08 => pvfc: 16, pvrl: 0, pvrlvd: 1, rad1h: 20
confc: 1325, con: 640, gcons: 640, conprice: -
09 => pvfc: 200, pvrl: 161, pvrlvd: 1, rad1h: 330
confc: 1566, con: 955, gcons: 800, conprice: -
10 => pvfc: 1245, pvrl: 439, pvrlvd: 1, rad1h: 830
confc: 1554, con: 579, gcons: 150, conprice: -
11 => pvfc: 2595, pvrl: 1019, pvrlvd: 1, rad1h: 1660
confc: 2067, con: 1029, gcons: 60, conprice: -
12 => pvfc: 2274, pvrl: 1569, pvrlvd: 1, rad1h: 2160
confc: 2526, con: 1538, gcons: 0, conprice: -
13 => pvfc: 2437, pvrl: 1856, pvrlvd: 1, rad1h: 2280
confc: 1969, con: 1849, gcons: 10, conprice: -
14 => pvfc: 2638, pvrl: 1693, pvrlvd: 1, rad1h: 2490
confc: 1902, con: 1671, gcons: 0, conprice: -
15 => pvfc: 2429, pvrl: 1631, pvrlvd: 1, rad1h: 1970
confc: 1762, con: 1604, gcons: 10, conprice: -
16 => pvfc: 1170, pvrl: 1323, pvrlvd: 1, rad1h: 1250
confc: 990, con: 1320, gcons: 0, conprice: -
17 => pvfc: 979, pvrl: 780, pvrlvd: 1, rad1h: 800
confc: 324, con: 774, gcons: 20, conprice: -
18 => pvfc: 251, pvrl: 176, pvrlvd: 1, rad1h: 200
confc: 175, con: 176, gcons: 20, conprice: -
19 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 0, gcons: 10, conprice: -
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 380, gcons: 390, conprice: -
21 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 1520, gcons: 1520, conprice: -
22 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 5, con: 1020, gcons: 1020, conprice: -
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 1210, gcons: 1210, conprice: -
24 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 480, gcons: 480, conprice: -
99 => pvfc: 16234, pvrl: 10647, pvrlvd: -, rad1h: -
confc: 22305, con: 20875, gcons: 10470, conprice: -
22 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 1080, gcons: 1080, conprice: -
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 330, gcons: 330, conprice: -
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 599, gcons: 599, conprice: -
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 491, gcons: 491, conprice: -
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 1040, gcons: 1040, conprice: -
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 350, gcons: 350, conprice: -
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
confc: 0, con: 650, gcons: 650, conprice: -
08 => pvfc: 27, pvrl: 0, pvrlvd: 1, rad1h: 20
confc: 6, con: 350, gcons: 350, conprice: -
09 => pvfc: 468, pvrl: 270, pvrlvd: 1, rad1h: 410
confc: 813, con: 1208, gcons: 940, conprice: -
10 => pvfc: 1259, pvrl: 1288, pvrlvd: 1, rad1h: 1160
confc: 1304, con: 1280, gcons: 10, conprice: -
11 => pvfc: 1540, pvrl: 1651, pvrlvd: 1, rad1h: 2020
confc: 1967, con: 1636, gcons: 10, conprice: -
12 => pvfc: 2632, pvrl: 1442, pvrlvd: 1, rad1h: 2090
confc: 2301, con: 1442, gcons: 10, conprice: -
13 => pvfc: 1790, pvrl: 1411, pvrlvd: 1, rad1h: 1570
confc: 1944, con: 1402, gcons: 0, conprice: -
14 => pvfc: 1167, pvrl: 1141, pvrlvd: 1, rad1h: 1180
confc: 1671, con: 1116, gcons: 0, conprice: -
15 => pvfc: 1455, pvrl: 681, pvrlvd: 1, rad1h: 1380
confc: 1604, con: 674, gcons: 10, conprice: -
16 => pvfc: 1015, pvrl: -, pvrlvd: -, rad1h: 860
confc: 1181, con: -, gcons: -, conprice: -
17 => pvfc: 354, pvrl: -, pvrlvd: -, rad1h: 300
confc: 359, con: -, gcons: -, conprice: -
18 => pvfc: 116, pvrl: -, pvrlvd: -, rad1h: 60
confc: 176, con: -, gcons: -, conprice: -
19 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
confc: 0, con: -, gcons: -, conprice: -
20 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
confc: 0, con: -, gcons: -, conprice: -
21 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
confc: 0, con: -, gcons: -, conprice: -
22 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
confc: 10, con: -, gcons: -, conprice: -
23 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
confc: 275, con: -, gcons: -, conprice: -
24 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
confc: 240, con: -, gcons: -, conprice: -
99 => pvfc: 11823, pvrl: 7884, pvrlvd: -, rad1h: -
confc: 13851, con: 13648, gcons: 5870, conprice: -
ZitatGibt da evtl. eine Möglichkeit irgendwelche durch Einrichtungsparameter diese Darstellung zu vermeiden?
Das muss ich mir erstmal in Ruhe durchdenken. Ist nicht so trivial.
Edit: Gute Erholung! 8)
Einen negativen con-Wert finde ich hier nicht:
Sehr gut.
Stelle dir das Attr affectConsForecastIdentWeekdays=1 und affectConsForecastLastDays=8.
Dann würde ich mich zurücklehnen und die Entwicklung in Ruhe eine Weile beobachten. :)
@all,
morgen früh ist die V 1.46.3 im Update enthalten. Weitere Infos dazu habt ihr in Kürze im Postkasten des Mitteilungssystems.
LG
Zitat von: DS_Starter am 22 Februar 2025, 14:46:38Einen negativen con-Wert finde ich hier nicht:
Sehr gut.
Stelle dir das Attr affectConsForecastIdentWeekdays=1 und affectConsForecastLastDays=8.
Dann würde ich mich zurücklehnen und die Entwicklung in Ruhe eine Weile beobachten. :)
Da wollte ich mich gerade zurücklehnen, aber der Effekt nach dem Setzen der beiden Attribute war schon da ;)
Verbrauch aktuell: 491 W nächste 4h: 8677 Wh Rest heute: 11108 Wh morgen: 16387 WhDanke Dir!!
Übrig bleibt nun noch der Akku. In der Grafik wird der SOC etc. korrekt angezeigt.
Die Readings (Stunden und Summen) bleiben Null, damit auch die SpecialReadings.
Wie kann ich diesen Fehler noch eingrenzen/analysieren? Danke vorab.
99 => tdayDvtn: 26.01, ydayDvtn: 34.42
todayConsumption: 15584, feedintotal: 80, initdayfeedin: 0
gridcontotal: 6940, initdaygcon: 0
initdaybatintot01: 0, initdaybatintot02: -, initdaybatintot03: -
initdaybatouttot01: 0, initdaybatouttot02: -, initdaybatouttot03: -
batintot01: 0, batintot02: -, batintot03: -
batouttot01: 0, batouttot02: -, batouttot03: -
lastTsMaxSocRchd01: 1739375885, lastTsMaxSocRchd02: -, lastTsMaxSocRchd03: -
nextTsMaxSocChge01: 1741103885, nextTsMaxSocChge02: -, nextTsMaxSocChge03: -
days2care01: -, days2care02: -, days2care03: -
runTimeTrainAI: -, aitrainLastFinishTs: -, aiRulesNumber: -
attrInvChangedTs: 1739282920
01 => balias => S10
basynchron => 1
bcharge => 18
bchargewh => 2359.8
binstcap => 13110
bname => e3dc_s10Pro
bpowerin => 0
bpowerout => 0
bshowingraph => 2
Um das zu analysieren, schaltest du
ctrlDebug = collectData
ein.
Dann findest du im Log etwa diese Ausschriften:
....
2025.02.22 20:27:12.773 1: SolCast DEBUG> collect Battery data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2025.02.22 20:27:12.774 1: SolCast DEBUG> pin=0 W, pout=661 W, totalin: 4275553.12124698 Wh, totalout: 4138361.27315344 Wh, soc: 87
....
Die Werte in totalin und totalout müssen sich nach oben bewegen, sobald Energie in die Batterie geladen oder aus der Bat gezogen wird.
Zumindest innerhalb 60 Minuten sollten Werteänderungen feststellbar sein.
@300P,
ich denke ich konnte den/deinen Issue aus #2048 lösen.
In meinem contrib liegt die V 1.46.4 zum Test.
Alle anderen interessierten User sind natürlich auch eingeladen diese Version zu testen.
LG,
Heiko
Guten Morgen Heiko,
hab das ,,Special-Update" eingespielt 1 x Restart durchgeführt.
Da ist aktuell ein kleiner Rechenfehler von der virtuellen Erzeugungsbox zum Hausverbrauch.
Dort muss die Einspeisung noch abgezogen werden.
(Siehe Screenshot)
Sobald morgen (am frühen Morgen oder so) die von mir geschilderte Lade-/Entladesituation ansteht melde ich mich ob es sauber dargestellt wird.
Gruß und nochmals Danke für diese schnelle spezielle Anpassung 👍
300P
moin,
ich hab jetzt mal angefangen, mich mit der Verbrauchsprognose zu befassen ...
Während die PV Prognose (obere Grafik) wirklich sehr gut ist habe ich bei der Verbrauchsprognose (untere Grafik) jeweils um die Mittagszeit viel zu geringe Prognose ggü dem realen Verbrauch.
Wo kann ich denn da ggf mal ansetzen mit der "Fehlersuche" ?
Zitat von: DS_Starter am 22 Februar 2025, 20:32:05Um das zu analysieren, schaltest du
ctrlDebug = collectData
ein.
Dann findest du im Log etwa diese Ausschriften:
....
2025.02.22 20:27:12.773 1: SolCast DEBUG> collect Battery data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2025.02.22 20:27:12.774 1: SolCast DEBUG> pin=0 W, pout=661 W, totalin: 4275553.12124698 Wh, totalout: 4138361.27315344 Wh, soc: 87
....
Die Werte in totalin und totalout müssen sich nach oben bewegen, sobald Energie in die Batterie geladen oder aus der Bat gezogen wird.
Zumindest innerhalb 60 Minuten sollten Werteänderungen feststellbar sein.
Hallo Heiko,
Danke für die Unterstützung bei der Suche.
Definiert ist wie folgt:
e3dc_s10Pro pin=Battery_Power:W pout=-pin intotal:Battery_EnergyCharge:kWh outtotal:Battery_EnergyDischarge:kWh cap=13110 charge=Battery_SOC show=2 asynchron=1Werte aus dem liefernden Device (E3/DC):
Battery_EnergyCharge 5.97 2025-02-23 17:17:38
Battery_EnergyDischarge 1.97 2025-02-23 17:17:38
Battery_SOC 51 2025-02-23 17:09:28
30 Minuten habe ich mitgeloggt, bei den negativen PIN-Werten hätte ich einen POUT erwartet:
2025.02.23 15:33:27 1: PV_Forecast DEBUG> collect sunrise/sunset times - device: OpenMeteoDWD-API =>
2025.02.23 15:33:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:33:28 1: PV_Forecast DEBUG> pin=1140 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:33:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:33:38 1: PV_Forecast DEBUG> pin=1155 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:33:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:33:48 1: PV_Forecast DEBUG> pin=1149 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:33:57 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:33:57 1: PV_Forecast DEBUG> pin=1140 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:34:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:34:08 1: PV_Forecast DEBUG> pin=1203 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:34:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:34:18 1: PV_Forecast DEBUG> pin=1092 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:34:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:34:28 1: PV_Forecast DEBUG> pin=906 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:34:32 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:34:32 1: PV_Forecast DEBUG> pin=858 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:34:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:34:38 1: PV_Forecast DEBUG> pin=858 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:34:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:34:48 1: PV_Forecast DEBUG> pin=444 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:34:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:34:58 1: PV_Forecast DEBUG> pin=0 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:35:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:35:08 1: PV_Forecast DEBUG> pin=0 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:35:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:35:18 1: PV_Forecast DEBUG> pin=0 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:35:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:35:28 1: PV_Forecast DEBUG> pin=84 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:35:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:35:38 1: PV_Forecast DEBUG> pin=111 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:35:41 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:35:41 1: PV_Forecast DEBUG> pin=114 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:35:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:35:48 1: PV_Forecast DEBUG> pin=114 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:35:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:35:58 1: PV_Forecast DEBUG> pin=396 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:36:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:36:08 1: PV_Forecast DEBUG> pin=681 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:36:17 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:36:17 1: PV_Forecast DEBUG> pin=1053 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:36:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:36:28 1: PV_Forecast DEBUG> pin=1158 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:36:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:36:38 1: PV_Forecast DEBUG> pin=1134 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:36:47 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:36:47 1: PV_Forecast DEBUG> pin=1167 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:36:51 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:36:51 1: PV_Forecast DEBUG> pin=1167 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:36:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:36:58 1: PV_Forecast DEBUG> pin=1167 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:37:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:37:08 1: PV_Forecast DEBUG> pin=1161 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:37:17 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:37:17 1: PV_Forecast DEBUG> pin=1152 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:37:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:37:28 1: PV_Forecast DEBUG> pin=1167 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:37:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:37:38 1: PV_Forecast DEBUG> pin=1257 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:37:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:37:48 1: PV_Forecast DEBUG> pin=1257 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:37:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:37:58 1: PV_Forecast DEBUG> pin=1152 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2025.02.23 15:38:03 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:38:03 1: PV_Forecast DEBUG> pin=1152 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:38:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:38:08 1: PV_Forecast DEBUG> pin=1152 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:38:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:38:18 1: PV_Forecast DEBUG> pin=1134 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:38:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:38:28 1: PV_Forecast DEBUG> pin=1062 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:38:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:38:38 1: PV_Forecast DEBUG> pin=1152 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:38:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:38:48 1: PV_Forecast DEBUG> pin=1146 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:38:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:38:58 1: PV_Forecast DEBUG> pin=1146 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:39:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:39:08 1: PV_Forecast DEBUG> pin=1125 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:39:12 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:39:12 1: PV_Forecast DEBUG> pin=1113 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:39:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:39:18 1: PV_Forecast DEBUG> pin=1113 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:39:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:39:28 1: PV_Forecast DEBUG> pin=1119 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:39:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:39:38 1: PV_Forecast DEBUG> pin=1209 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:39:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:39:48 1: PV_Forecast DEBUG> pin=1119 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:39:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:39:58 1: PV_Forecast DEBUG> pin=1140 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:40:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:40:08 1: PV_Forecast DEBUG> pin=1140 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:40:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:40:18 1: PV_Forecast DEBUG> pin=1164 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:40:23 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:40:23 1: PV_Forecast DEBUG> pin=1137 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:40:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:40:28 1: PV_Forecast DEBUG> pin=1137 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:40:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:40:38 1: PV_Forecast DEBUG> pin=1215 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:40:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:40:48 1: PV_Forecast DEBUG> pin=1215 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:40:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:40:58 1: PV_Forecast DEBUG> pin=1215 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:41:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:41:08 1: PV_Forecast DEBUG> pin=1215 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:41:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:41:18 1: PV_Forecast DEBUG> pin=1179 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:41:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:41:28 1: PV_Forecast DEBUG> pin=1173 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:41:32 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:41:32 1: PV_Forecast DEBUG> pin=1218 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:41:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:41:38 1: PV_Forecast DEBUG> pin=1218 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:41:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:41:48 1: PV_Forecast DEBUG> pin=1194 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:41:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:41:58 1: PV_Forecast DEBUG> pin=1179 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:42:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:42:08 1: PV_Forecast DEBUG> pin=1167 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:42:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:42:18 1: PV_Forecast DEBUG> pin=1164 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:42:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:42:28 1: PV_Forecast DEBUG> pin=1173 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:42:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:42:38 1: PV_Forecast DEBUG> pin=1158 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:42:42 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:42:42 1: PV_Forecast DEBUG> pin=1173 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:42:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:42:48 1: PV_Forecast DEBUG> pin=1173 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:42:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:42:58 1: PV_Forecast DEBUG> pin=1179 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:43:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:43:08 1: PV_Forecast DEBUG> pin=1200 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:43:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:43:18 1: PV_Forecast DEBUG> pin=1206 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:43:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:43:28 1: PV_Forecast DEBUG> pin=1194 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 44
2025.02.23 15:43:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:43:38 1: PV_Forecast DEBUG> pin=1170 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:43:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:43:48 1: PV_Forecast DEBUG> pin=1185 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:43:53 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:43:53 1: PV_Forecast DEBUG> pin=1167 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:43:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:43:58 1: PV_Forecast DEBUG> pin=1167 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:44:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:44:08 1: PV_Forecast DEBUG> pin=1164 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:44:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:44:18 1: PV_Forecast DEBUG> pin=1164 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:44:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:44:28 1: PV_Forecast DEBUG> pin=1176 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:44:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:44:38 1: PV_Forecast DEBUG> pin=1125 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:44:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:44:48 1: PV_Forecast DEBUG> pin=1164 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:44:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:44:58 1: PV_Forecast DEBUG> pin=1149 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:45:02 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:45:02 1: PV_Forecast DEBUG> pin=1149 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:45:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:45:08 1: PV_Forecast DEBUG> pin=1149 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:45:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:45:18 1: PV_Forecast DEBUG> pin=1158 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:45:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:45:28 1: PV_Forecast DEBUG> pin=1152 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:45:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:45:38 1: PV_Forecast DEBUG> pin=1014 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:45:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:45:48 1: PV_Forecast DEBUG> pin=882 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:45:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:45:58 1: PV_Forecast DEBUG> pin=912 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:46:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:46:08 1: PV_Forecast DEBUG> pin=1041 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:46:12 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:46:12 1: PV_Forecast DEBUG> pin=945 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:46:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:46:18 1: PV_Forecast DEBUG> pin=945 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:46:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:46:28 1: PV_Forecast DEBUG> pin=903 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:46:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:46:38 1: PV_Forecast DEBUG> pin=903 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:46:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:46:48 1: PV_Forecast DEBUG> pin=816 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:46:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:46:58 1: PV_Forecast DEBUG> pin=828 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:47:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:47:08 1: PV_Forecast DEBUG> pin=-768 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:47:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:47:18 1: PV_Forecast DEBUG> pin=657 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:47:23 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:47:23 1: PV_Forecast DEBUG> pin=-591 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:47:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:47:28 1: PV_Forecast DEBUG> pin=-591 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:47:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:47:38 1: PV_Forecast DEBUG> pin=-537 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:47:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:47:48 1: PV_Forecast DEBUG> pin=-447 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:47:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:47:58 1: PV_Forecast DEBUG> pin=-654 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:48:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:48:08 1: PV_Forecast DEBUG> pin=375 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:48:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:48:18 1: PV_Forecast DEBUG> pin=381 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:48:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:48:28 1: PV_Forecast DEBUG> pin=273 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:48:32 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:48:32 1: PV_Forecast DEBUG> pin=-495 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:48:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:48:38 1: PV_Forecast DEBUG> pin=-495 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:48:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:48:48 1: PV_Forecast DEBUG> pin=-459 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:48:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:48:58 1: PV_Forecast DEBUG> pin=-198 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:49:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:49:08 1: PV_Forecast DEBUG> pin=-285 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:49:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:49:18 1: PV_Forecast DEBUG> pin=810 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:49:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:49:28 1: PV_Forecast DEBUG> pin=810 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:49:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:49:38 1: PV_Forecast DEBUG> pin=570 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:49:43 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:49:43 1: PV_Forecast DEBUG> pin=279 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:49:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:49:48 1: PV_Forecast DEBUG> pin=279 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:49:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:49:58 1: PV_Forecast DEBUG> pin=222 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:50:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:50:08 1: PV_Forecast DEBUG> pin=285 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:50:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:50:18 1: PV_Forecast DEBUG> pin=540 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:50:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:50:28 1: PV_Forecast DEBUG> pin=714 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:50:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:50:38 1: PV_Forecast DEBUG> pin=789 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:50:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:50:48 1: PV_Forecast DEBUG> pin=789 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:50:53 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:50:53 1: PV_Forecast DEBUG> pin=777 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:50:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:50:58 1: PV_Forecast DEBUG> pin=777 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:51:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:51:08 1: PV_Forecast DEBUG> pin=768 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:51:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:51:18 1: PV_Forecast DEBUG> pin=747 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:51:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:51:28 1: PV_Forecast DEBUG> pin=759 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:51:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:51:38 1: PV_Forecast DEBUG> pin=762 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:51:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:51:48 1: PV_Forecast DEBUG> pin=735 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:51:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:51:58 1: PV_Forecast DEBUG> pin=684 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:52:02 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:52:02 1: PV_Forecast DEBUG> pin=672 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:52:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:52:08 1: PV_Forecast DEBUG> pin=672 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:52:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:52:18 1: PV_Forecast DEBUG> pin=603 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:52:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:52:28 1: PV_Forecast DEBUG> pin=567 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:52:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:52:38 1: PV_Forecast DEBUG> pin=567 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:52:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:52:48 1: PV_Forecast DEBUG> pin=621 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:52:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:52:58 1: PV_Forecast DEBUG> pin=567 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:53:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:53:08 1: PV_Forecast DEBUG> pin=615 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:53:12 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:53:12 1: PV_Forecast DEBUG> pin=624 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:53:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:53:18 1: PV_Forecast DEBUG> pin=624 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:53:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:53:28 1: PV_Forecast DEBUG> pin=630 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:53:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:53:38 1: PV_Forecast DEBUG> pin=588 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:53:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:53:48 1: PV_Forecast DEBUG> pin=540 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:53:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:53:58 1: PV_Forecast DEBUG> pin=657 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:54:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:54:08 1: PV_Forecast DEBUG> pin=699 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 45
2025.02.23 15:54:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:54:18 1: PV_Forecast DEBUG> pin=684 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:54:23 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:54:23 1: PV_Forecast DEBUG> pin=645 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:54:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:54:28 1: PV_Forecast DEBUG> pin=645 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:54:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:54:38 1: PV_Forecast DEBUG> pin=588 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:54:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:54:48 1: PV_Forecast DEBUG> pin=609 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:54:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:54:58 1: PV_Forecast DEBUG> pin=615 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:55:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:55:08 1: PV_Forecast DEBUG> pin=615 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:55:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:55:18 1: PV_Forecast DEBUG> pin=624 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:55:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:55:28 1: PV_Forecast DEBUG> pin=603 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:55:32 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:55:32 1: PV_Forecast DEBUG> pin=621 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:55:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:55:38 1: PV_Forecast DEBUG> pin=621 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:55:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:55:48 1: PV_Forecast DEBUG> pin=651 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:55:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:55:58 1: PV_Forecast DEBUG> pin=672 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:56:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:56:08 1: PV_Forecast DEBUG> pin=645 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:56:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:56:18 1: PV_Forecast DEBUG> pin=669 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:56:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:56:28 1: PV_Forecast DEBUG> pin=642 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:56:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:56:38 1: PV_Forecast DEBUG> pin=621 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:56:42 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:56:42 1: PV_Forecast DEBUG> pin=624 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:56:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:56:48 1: PV_Forecast DEBUG> pin=624 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:56:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:56:58 1: PV_Forecast DEBUG> pin=669 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:57:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:57:08 1: PV_Forecast DEBUG> pin=663 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:57:18 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:57:18 1: PV_Forecast DEBUG> pin=672 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:57:28 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:57:28 1: PV_Forecast DEBUG> pin=672 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:57:38 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:57:38 1: PV_Forecast DEBUG> pin=669 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:57:48 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:57:48 1: PV_Forecast DEBUG> pin=642 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:57:53 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:57:53 1: PV_Forecast DEBUG> pin=642 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:57:58 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:57:58 1: PV_Forecast DEBUG> pin=642 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
2025.02.23 15:58:08 1: PV_Forecast DEBUG> collect Battery data: device=e3dc_s10Pro =>
2025.02.23 15:58:08 1: PV_Forecast DEBUG> pin=600 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 46
ZitatWo kann ich denn da ggf mal ansetzen mit der "Fehlersuche" ?
Lies dir mal das Kapitel im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Die_Verbrauchsprognose) durch und vergleiche die Empfehlungen mit deinen Einstellungen. Möglicherweise erreichst du damit bereits eine deutliche Verbesserung.
LG
Hallo Dirk,
Zitat30 Minuten habe ich mitgeloggt, bei den negativen PIN-Werten hätte ich einen POUT erwartet:
Ja das stimmt. Das ist allerdings nur eine ungünstige Debug Ausgabe. Das ändere ich im nächsten Release.
Aber dein Hauptproblem ist, dass intotal bzw. outtotal nichts bringen. Und das liegt an einer falschen Syntax im Attribut:
Falsch:
intotal:Battery_EnergyCharge:kWh outtotal:Battery_EnergyDischarge:kWh
Richtig:
intotal=Battery_EnergyCharge:kWh outtotal=Battery_EnergyDischarge:kWh
Nach einer Änderung kommen die Werte sicherlich wie erwartet.
Die Debug Ausgabe ist nun etwas erweitert um die Special Cases besser darzustellen:
2025.02.23 18:05:35.161 1: SolCast6 DEBUG> collect Battery Readings data: device=BatteryDummy2 =>
2025.02.23 18:05:35.162 1: SolCast6 DEBUG> pin=-200 W, pout=0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 15
2025.02.23 18:05:35.164 1: SolCast6 DEBUG> Battery Power data after resolving the special case 'pou eq -pin' =>
2025.02.23 18:05:35.165 1: SolCast6 DEBUG> pin=0 W, pout=200 W
Findet sich im kommenden Release wieder.
Zitat von: DS_Starter am 23 Februar 2025, 17:45:37Hallo Dirk,
Zitat30 Minuten habe ich mitgeloggt, bei den negativen PIN-Werten hätte ich einen POUT erwartet:
Ja das stimmt. Das ist allerdings nur eine ungünstige Debug Ausgabe. Das ändere ich im nächsten Release.
Aber dein Hauptproblem ist, dass intotal bzw. outtotal nichts bringen. Und das liegt an einer falschen Syntax im Attribut:
Falsch:
intotal:Battery_EnergyCharge:kWh outtotal:Battery_EnergyDischarge:kWh
Richtig:
intotal=Battery_EnergyCharge:kWh outtotal=Battery_EnergyDischarge:kWh
Nach einer Änderung kommen die Werte sicherlich wie erwartet.
Es darf nicht wahr sein :-[
Zig-Mal kontrolliert und jedesmal übersehen. Vielen Dank!!!!!!
ZitatZig-Mal kontrolliert und jdesmal übersehen.
Das passiert ... mir auch. Gerade auch wenn ich Support leiste, sehr leicht überliest man etwas.
Hallo zusammen,
ich sehe hier auf manchen Screenshots zwischen den Symbolen für das Wetter und der ersten Balkengrafik Batteriesymbole.
Im Wiki habe ich dazu nichts gefunden. Ich vermute, es stellt jeweils den Batteriezustand dar?
Was muss ich dafür konfigurieren?
Danke für einen kleinen Tipp!
Viele Grüße,
Peter
EDIT: Hab's gefunden. Am setupBatteryDev. Gibt es die Option ,,show"...
Hallo Peter,
und ich habe soeben dazu einen Wiki-Beitrag (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Visualisierung_der_Batterie_in_der_Balkengrafik) erstellt. ;)
LG,
Heiko
Zitat von: DS_Starter am 23 Februar 2025, 11:24:28@300P,
ich denke ich konnte den/deinen Issue aus #2048 lösen.
In meinem contrib liegt die V 1.46.4 zum Test.
Alle anderen interessierten User sind natürlich auch eingeladen diese Version zu testen.
LG,
Heiko
Guten Morgen Heiko,
grad hab ich es ein nochmals wie angekündigt paar Minuten beobachtet.
Soweit alles okay - nur wenn eingespeist wird - dann wird dieser Einspeisewwert nicht vom Wert der von der virtuellen Box zum Haus geht abgezogen.
Gruß
300P
Ich habe nochmal was geändert.
Zieh bitte nochmal aus meinem contrib.
LG
Hab es neu gezogen - Ergebnis dann später
Danke
300P
Die virtuelle Box zeigt jetzt ,,nur noch" den Hausverbrauch + Einspeisung - nicht die Summe der Erzeugung an (=>Screenshot)
Ist wirklich nicht so simpel.
Zieh nochmal bitte.
Glaube ich.
Ziehe es gleich - dauert nur etwas....
Zitat von: DS_Starter am 23 Februar 2025, 17:27:33ZitatWo kann ich denn da ggf mal ansetzen mit der "Fehlersuche" ?
Lies dir mal das Kapitel im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Die_Verbrauchsprognose) durch und vergleiche die Empfehlungen mit deinen Einstellungen. Möglicherweise erreichst du damit bereits eine deutliche Verbesserung.
Ich hab eine Wallbox als consumer eingerichtet und mit "exconfc=1" von der Verbrauchsprognose ausgeschlossen.
Frage: Wird dann auch der
Verbrauch dieses consumers herausgerechnet?
Zitat von: DS_Starter am 24 Februar 2025, 15:02:59Ist wirklich nicht so simpel.
Zieh nochmal bitte.
Hallo Heiko,
es gibt anbei 3 Screenshots:
(Nur bei A besteht Handlungsbedarf)
A:
14:22 Uhr = 15:22 Uhr in Deutschland)
Wenn PV erzeugt wird und davon ins Netz eingespeist sowie die Batterie geladen wird.
Erzeugung 1182 W (virtuelle Box i.o)
Netzeinsp. 2 W
Netzbezug 0 W
Batterie 772 W (laden beide)
Virtuelle Box nach Haus 1182 W (müsste 410 W sein - falsch - wird Batterie-Ladung nicht abgezogen)
div. Restverbrauch / Consumer (ist i.O)
B:
16:02 Uhr = 17:02 Deutschland
Wenn PV erzeugt wird, von der Batterie (summiert) entladen wird und ins Netz eingespeist wird.
Erzeugung 148 W (i.o.)
virtuelle-Box 148 W (i.o.)
Netzeinspeisung 1 W
Netzbezug 0 W
Batterie 271 W (entladen i.o.)
Hausverbrauch 418 W (i.o.)
div. Restverbrauch / Consumer (ist i.O)
C:
16:03 Uhr = 17:03 Uhr Deutschland
Wenn PV erzeugt wird, aus der Batterie geladen/entladen (netto entladen) wird und vom Netz bezogen wird.
Erzeugung 142 W (i.o.)
virtuelle-Box 142 W (i.o.)
Netzeinspeisung 0 W (i.o.)
Netzbezug 4 W (i.O)
Batterie 295 W (entladen i.o.)
Hausverbrauch 441 W (i.o.)
div. Restverbrauch / Consumer (ist i.O)
PS:
Screenshotupload sobald VPN wieder steht - Handy will heute nicht so wie ich will
Gruß
300P
Ich habe eine weitere Änderung eingebaut.
Ein mühsames Unterfangen ...
@grappa24,
ZitatFrage: Wird dann auch der Verbrauch dieses consumers herausgerechnet?
Nein, sofern du den aktuellen Verbrauch meinst der z.B. in der Flowgrafik dargestellt wird.
Zitat von: DS_Starter am 24 Februar 2025, 19:01:55@grappa24,
ZitatFrage: Wird dann auch der Verbrauch dieses consumers herausgerechnet?
Nein, sofern du den aktuellen Verbrauch meinst der z.B. in der Flowgrafik dargestellt wird.
na, das erklärt aber dann meine ggü der Vorhersage stark erhöhten Verbräuche zu bestimmten Stunden ;)
Im Wiki habe ich einen Abschnitt "Umsetzungsbeispiel Batterie Ladesteuerung mit Victron GX Venus über den Grid Setpoint (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Umsetzungsbeispiel_Batterie_Ladesteuerung_mit_Victron_GX_Venus_%C3%BCber_den_Grid_Setpoint)" eingefügt wen es interessiert.
Zitat von: DS_Starter am 24 Februar 2025, 18:58:40Ich habe eine weitere Änderung eingebaut.
Ein mühsames Unterfangen ...
So für heute die letzte Runde:
Ohne PV-Erzeugung sieht alles soweit okay aus.
Ab und an kommt ein "Glitsch" - vermutlich durch diverse Rundungen, aber er ist trotzdem irgendwie "logisch dargestellt.
Morgen beobachte ich dann noch bei laufender PV-Erzeugung.
Anbei wieder Screenshots:
Der "Glitsch" ist in dem Screenshot Nr. 2 5 und 6 sichtbar (sorry war versehentlich vorher anders)
Ein "Glitsch" ... :)
Zitatvermutlich durch diverse Rundungen
Wahrscheinlich gibt es kurze Spike Werte im 0.x Bereich. Bei mir habe ich sowas noch nicht festgestellt.
Guten Morgen Heiko,
leider ist bei der Erzeugung nun wohl etwas mehr durcheinander 😩.
Egal ob mit oder ohne den zusätzlichen Producer stimmt die Summe der Erzeugung nicht (hab Brennstoffzelle nach dem ersten Bild extra abgeschaltet).
Siehe Screnshots
Gruß
300P
Lädt oder Entlädt die Batterie in Richtung virt. Knoten? Die Flußrichtung kann man hier nicht sehen.
Bei mir sieht es nämlich richtig gut aus.
Edit: Verwendest du auch die aktuelle Datei aus meinem contrib?
EDit2: Ach ich glaube ich weiß was du meinst -> beim Abluß der Energie in die Bat. Habe nochmal eine Änderung eingebaut -> bitte neu ziehen.
Antwort Edit:
Ja, Batterien 🔋 laden dabei beide vom virtuellen Knoten.
Anwort Edit1:
Ja, es war die letzte Version von Gestern.
Antwort Edit2:
Ziehe mir das neue Update jetzt - war erst am Strand 🏖� zum Langschläfer-Frühstücken 8)
Das sieht nach einem Volltreffer 🎯 aus.
Siehe Screenshots mit 3 verschieden Szenarien
Laden / Verbrauch Haus
Laden / Verbrauch Haus / Einspeisung
Laden / Verbrauch Haus / Bezug
Ich warte noch bis heute Abend ab und schaue, ob bei alleinigem Hausverbrauch aus den Batterien mit EVU-Bezug/Einspeisung auch alles weiter sauber ist.
Dankeschön 🙏
Gruß
300P
Hallo,
ich komme im Moment mit der grafischen Darstellung der Batterie nicht klar.
Screenshot 2025-02-25 131802.png
pin und pout sind beides positive Werte in Watt und wie folgt im Attr konfiguriert.
attr SolarForecast setupBatteryDev01 hame_energy pin=Solar_1_input_power:W pout=Output_power_1:W charge=Battery_percentage cap=2240hame_energy Output_power_1_battout 240
hame_energy Solar_1_input_power 122
Warum wird das in der Grafik nicht auch so dargestellt? Ich würde erwarten, dass der Input wie der Output dargestellt wird...
VG
Hallo Reinschki,
da es sich auch um mehrere Batterien handeln ,,kann" wird der summierte Ab-/Zufluss zur Batterie dargestellt.
Ergebnis = Laden = wird vom virtuellen Knoten oben zur Batterie angezeigt
Ergebnis = Entladen = wird von der Batterie zum Haus dargestellt
Gruß
300P
Hm, und wofür gibt es dann den symbolischen Abfluss von der Batterie zum Haus?
Entladen der Batterie
ZitatHm, und wofür gibt es dann den symbolischen Abfluss von der Batterie zum Haus?
Das ist kein "Abfluss", sondern nur eine Verbindung, die zum Beispiel auch aktiv wird wenn die Batterie aus dem Haus bzw. aus dem öffentlichen Netz (über das Haus) geladen wird.
Hinweis: Die Flußrichtung der Energie wird durch die Aktivierung der Laufketten mit Attr flowGraphicControl -> animate=1 (default) angezeigt.
Zitat von: 300P am 25 Februar 2025, 12:35:36Das sieht nach einem Volltreffer 🎯 aus.
Siehe Screenshots mit 3 verschieden Szenarien
Laden / Verbrauch Haus
Laden / Verbrauch Haus / Einspeisung
Laden / Verbrauch Haus / Bezug
Ich warte noch bis heute Abend ab und schaue, ob bei alleinigem Hausverbrauch aus den Batterien mit EVU-Bezug/Einspeisung auch alles weiter sauber ist.
Dankeschön 🙏
Gruß
300P
@DS_Starter:
=>>Nochmalige Rückmeldung zu der letzten Contrib-Version von heute
Es sieht wirklich "alles gut" bei mir mit dieser letzten Version aus.
Gruß + Danke
300P
Bei mir auch alles "grün".
Die Version werde ich dann auch einchecken.
LG
Zur Info, im Februar wurde das ,,Solarspitzengesetz" verabschiedet. Im Merkblatt (https://www.solarwirtschaft.de/unsere-themen/photovoltaik/standpunkte/faq-solarspitzengesetz/#f13) der Bundesverband Solarwirtschaft e. V. sind die wesentlichen FAQ dazu beantwortet.
Für Bestandsanlagen ändert sich soweit ich sehen kann nichts. Für Neuanlagen ist die Einspeiseleistung auf 60% zu begrenzen sofern kein Smartmeter + Steuerung durch den VNB eingebaut wird.
An dieser Stelle wird evtl. das Feature (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Ber%C3%BCcksichtigung_einer_Wirkleistungsbegrenzung) des Moduls in Verbindung mit Solarspeichern interesssant um Selbstnutzung und Einspeisung zu optimieren. Kommerzielle Anbieter wie Enpal (https://www.enpal.de/strom/solarspitzengesetz) bieten Energiemanager (Enpal.one) an um eine Optimierung umzusetzen, wobei ich nichts dazu gefunden habe ob diese Geräte auch in der Lage sind eine PV Erzeugungsprognose in ihre Steuerung zu integrieren.
Unter Umständen kann man sich auch als Betrieber von Bestandsanlagen eine höhere Einspeisvergütung von 0,6 ct/kWh wenn man sich freiwillig für eine 60 %ige Begrenzung entscheidet. Wenn wir es schaffen mit Hilfe des Moduls und der Speichersteuerung ohnehin nicht mehr als 60% Leistung an das Netz zu bringen, könnte man getrost die 0,6 ct in Anspruch nehmen und sich dadurch einen kleiden Bonus gönnen.
Stimmt so nicht ... man muß wohl erklären zu Zeiten negativer Strompreise auf eine Vergütung verzichten und diese Zeiten im Rahmen des neuen § 51a EEG am Ende des Vergütungszeitraums nachholen.
klingt ja interessant!
Ich mach das schon seit Inebtriebnahme freiwillig mit E3DC-Control. Eine integrierte Lösung in FHEM würde ich aber auch mal probieren.
Wobei ich mit 9,75kWp auf Ost-West auch ohne Regelung nicht über die 60% komme. Jedenfalls habe ich das noch nicht gesehen.
Mal sehen wann hier das iMSys kommt. Das ist ja wohl Voraussetzung um die 0,6ct/kWh zusätzlich zu bekommen.
ZitatMal sehen wann hier das iMSys kommt. Das ist ja wohl Voraussetzung um die 0,6ct/kWh zusätzlich zu bekommen.
In den oben verlinkten FAQ finde ich dazu:
ZitatIn § 100 Abs. 47 EEG wird eine Anreizmöglichkeit eingeführt, um Bestandsanlagen in der Einspeisevergütung zu einem freiwilligen systemdienlichen Betrieb zu motivieren. Anlagenbetreiber von Bestandsanlagen können ihren Vergütungssatz um 0,6 ct/kWh erhöhen, sofern sie ggü. dem Netzbetreiber erklären, dass sie zu Zeiten negativer Strompreise auf eine Vergütung verzichten und diese Zeiten im Rahmen des neuen § 51a EEG am Ende des Vergütungszeitraums nachholen.
Wenn ich das richtig interpretiere bedarf es dazu nur einer Erklärung seitens des Betreibers, also uns.
Im Modul müsste ich dazu "nur" noch eine Prognose einbauen wann der Preis negativ wird. Dann könnte diese Info in die Bat-Steuerung einfließen.
Habe mich damit aber noch nicht wirklich beschäftigt, weiß nicht ob es eine solche Quelle (abfragbar) gibt.
Es reicht demnach aber auch nicht die 60% Regelung freiwillig einzuhalten wie ich oben geschrieben hatte.
iMSys ist Pflicht.
§100 Abs. 47 EEG
47) Für Anlagen, deren anzulegender Wert sich nach der für sie maßgeblichen Fassung des Erneuerbare-Energien-Gesetzes in Zeiträumen, in denen der Spotmarktpreis negativ ist, nicht verringert,
sind die §§ 51 und § 51a anzuwenden, wenn der Anlagenbetreiber in Textform gegenüber dem Netzbetreiber erklärt, dass diese anwendbar sein sollen.
Die Erklärung nach Satz 1 kann nur mit Wirkung frühestens zum Ablauf des Kalenderjahres, in dem die Anlage mit einem intelligenten Messsystem ausgestattet wird, abgegeben werden.
Nach Wirksamwerden der Erklärung nach Satz 1 erhöht sich der anzulegende Wert für die Anlage um 0,6 Cent pro Kilowattstunde.
Heißt für mich, dass man das erst im für das Folgejahr nach iMSys Installation beantragen kann. Wer jetzt noch keins hat also erst ab 2026
Edit:
Achtung, persönliche Laienmeinung bzw. -interpretation:
Die 60% scheinen aber hart nur für Neuanlagen zu gelten und haben mit der zusätzlichen Vergütung nach §100 Abs. 47 EEG nichts zu tun. Gem. §51 EEG gibt es keine Vergütung sobald der Börsenpreis negativ wird. Diese Stunden muss man dann "wegpuffern". Die sozusagen entgangenen Stunden verlängern dann nach §51a EEG den garantierten Vergütungszeitraum.
Das musste ich herauskopieren und zweimal lesen. ;)
Für mich ist der erste Satz der Bezug zu der Erklärung die man abgeben kann:
ZitatFür Anlagen, deren anzulegender Wert sich nach der für sie maßgeblichen Fassung des Erneuerbare-Energien-Gesetzes in Zeiträumen, in denen der Spotmarktpreis negativ ist, nicht verringert,
sind die §§ 51 und § 51a anzuwenden, wenn der Anlagenbetreiber in Textform gegenüber dem Netzbetreiber erklärt, dass diese anwendbar sein sollen.
Muß man sich §§ 51 und § 51a anschauen was da steht.
Wird wieder spannend das Ganze ... ;-)
Edit:
ZitatDie 60% scheinen aber hart nur für Neuanlagen zu gelten und haben mit der zusätzlichen Vergütung nach §100 Abs. 47 EEG nichts zu tun. Gem. §51 EEG gibt es keine Vergütung sobald der Börsenpreis negativ wird. Diese Stunden muss man dann "wegpuffern". Die sozusagen entgangenen Stunden verlängern dann nach §51a EEG den garantierten Vergütungszeitraum.
Ja, sehe ich auch so. Habe ich oben in meinem Post dazu korrigiert.
Der zweite Satz schränkt aber den ersten Satz wieder ein.
Ich bin zwar eher im Handels- und Steuerrecht zu Hause, aber die Gesetze sind ja gleich gestrickt.
In §51 steht drin, dass die Vegütung auf 0 absinkt wenn der Börsenpreis negativ wird. Eingeschränkt wird das ganze wieder um das iMSys. Wenn das nicht installiert ist, gilt voriges wieder nicht. Für Anlagen unter 2kWp gilt das alles nicht. Und die Datenübermittlung wird präzisiert (Anlagenbetreiber muss mitteilen welche Menge er in Zeiten des negativen Strompreises eingespeist hat). Tut er das nicht, wird die Vergütung für jeden Tag mit negativen Preisen pauschal um 5% gekürzt.
In §51a steht nur wie der zusätzliche Vergütungszeitraum berechnet wird.
Wie gesagt, Laieninterpratation. Aber mal wieder typisch deutsch.....
Ja typisch ... :(
Ich glaube auch nicht, dass wir das Thema jetzt tiefgreifend und allumfassend erörtern können. War jetzt auch nicht der Anspruch.
Aber für uns als Hausautomatisierer ist die Erkenntnis nicht ganz unwesentlich, dass es zumindest für Neuanlagen, bzw. unter den erwähnten Punkten auch für Bestandsanlagen, hilfreich sein kann/wird unsere Speicher/Verbrauchs- und Einspeiseoptimierung weiter voranzutreiben und so auch einen finanziellen Effekt aus unserem Hobby zu ziehen.
Moin,
Für Tibber Kunden habe ich ein Device mit Zeitfenstern für niedrige Preise und hohe Preise. Da könnte ich auch noch die Preise < Null als Trigger und Zeitfenster rein bringen.
Bisher war ein Preis unter 0ct sehr selten, aber das wird sich dann sicher auch noch ändern, mal sehen was der Markt da so regelt.
Im Moment liegen im Winter die Preise meistens über meinem EVU Fixpreis ;-)
VG Christian
Hallo zusammen,
eine Frage stellt sich mir noch.
Ich vergleiche gerne Prognose vs. Realität.
Für PV habe ich die Werte auch für den aktuellen Tag.
Heute:Today_PVreal
Heute Forecast:Today_PVforecastAber beim Verbrauch finde ich kein Reading für die Summe des prognostizierten Verbrauchs des aktuellen Tages.
Heute:special_todayConsumption
Heute Forecast:??????
Morgen:Tomorrow_ConsumptionForecastGibt es die Info oder könnte man diese ergänzen?
Danke vorab und schöne Grüße
Dirk
Ein zweites Thema habe ich doch noch.
Ich habe eine Wallbox als consumer01 mit exconfc=1 definiert.
Gestern wurde geladen und heute erscheint ein massiv erhöhter prognostizierter Verbrauch in dieser Stunde.
Bedeutet doch, dass doch der Verbrauch des cosumer01 mit einfliesst, trotz exconfc=1
Oder?
ZitatBedeutet doch, dass doch der Verbrauch des cosumer01 mit einfliesst, trotz exconfc=1
Oder?
Nein, allerdings sind die Dinge ein wenig komplexer. Sehr hilfreich ist diesem Fall das Attr affectConsForecastIdentWeekdays = 1.
Lies dir auch mal den Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_die_Verbrauchsprognose_erstellt?) im Wiki dazu durch. Dort habe ich den Sachverhalt versucht zu verdeutlichen.
Hallo Christian,
ZitatFür Tibber Kunden habe ich ein Device mit Zeitfenstern für niedrige Preise und hohe Preise. Da könnte ich auch noch die Preise < Null als Trigger und Zeitfenster rein bringen.
Das wäre vllt. ein guter Ansatz. Wenn du das machst würde ich mir Gedanken machen wie ich diesen Input auf die hier schon bekannte Weise integriere.
ZitatAber beim Verbrauch finde ich kein Reading für die Summe des prognostizierten Verbrauchs des aktuellen Tages.
Gibt es die Info oder könnte man diese ergänzen?
Es gibt zur Zeit diese Prognose-Readings:
todayConsumptionForecast Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
todayConForecastTillSunset Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
Ein special-Reading für die Summe der todayConsumptionForecast kann ich einbauen wenn gewünscht.
Zitat von: DS_Starter am 27 Februar 2025, 20:26:15ZitatBedeutet doch, dass doch der Verbrauch des cosumer01 mit einfliesst, trotz exconfc=1
Oder?
Nein, allerdings sind die Dinge ein wenig komplexer. Sehr hilfreich ist diesem Fall das Attr affectConsForecastIdentWeekdays = 1.
Lies dir auch mal den Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_die_Verbrauchsprognose_erstellt?) im Wiki dazu durch. Dort habe ich den Sachverhalt versucht zu verdeutlichen.
Danke Dir, das Attribut war schon so definiert.
Zitat von: DS_Starter am 27 Februar 2025, 20:49:18Es gibt zur Zeit diese Prognose-Readings:
todayConsumptionForecast Verbrauchsprognose pro Stunde des aktuellen Tages (01-24)
todayConForecastTillSunset Verbrauchsprognose von aktueller Stunde bis Stunde vor Sonnenuntergang
Ein special-Reading für die Summe der todayConsumptionForecast kann ich einbauen wenn gewünscht.
Ich würde es mir natürlich wünschen, aber das hat selbstverständlich keine Prio - ist ein typisches Nice-to-have.
Danke und viele Grüße
Dirk
Hallo zusammen,
gibt es eine Möglichkeit bei der Batterie einen minimalen SoC, idealerweise als Reading, anzugeben?
Bei mir startet die SoC Vorhersage morgens immer bei 0,0 %, was ich aber nie erreichen kann. Unter 7 % kann ich
den Akku nicht entladen und im Moment steht er bei minimal 50 % (Reserve für Stromausfall).
Ziel wäre den Akku in der Nacht davor so weit zu entladen, dass die 100 % nicht oder nur gerade so erreicht werden.
Klar, ein Nice-to-have, aber vielleicht macht das ja nicht so viel Mühe.
Gruß
Steffen
@all,
morgen gibt es ein Update. Ihr könnt euch dann ein Reading "special_todayConsumptionForecastDay" erstellen lassen.
@Steffen,
Zitatgibt es eine Möglichkeit bei der Batterie einen minimalen SoC, idealerweise als Reading, anzugeben?
Das gibt es schon, aber nicht als Reading. Sieh dir mal das Attr ctrlBatSocManagementXX -> Schlüssel "lowSoc" an und dazu den Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Aktivierung_des_Batterie_SOC-Managements) im Wiki.
LG,
Heiko
Zitat von: DS_Starter am 28 Februar 2025, 14:08:04@all,
morgen gibt es ein Update. Ihr könnt euch dann ein Reading "special_todayConsumptionForecastDay" erstellen lassen.
LG,
Heiko
Toll, vielen Dank!!!
Weiter vorn kamen einige Fragen zu speziellen Consumersteuerungen. Eine davon habe ich jetzt im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Fallstudie:_Trockner_darf_pausiert_werden,_wenn_nicht_genug_PV-%C3%9Cberschu%C3%9F_vorhanden_ist,_soll_aber_nach_sp%C3%A4testens_X_Stunden_fertig_sein) beantwortet.
Edit: Noch eine weitere Fragestellung beantwortet (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Fallstudie:_Umw%C3%A4lzpumpe_Pool_soll_X_Stunden_am_Tag_laufen._Ist_kein_PV-%C3%9Cberschu%C3%9F_vorhanden,_m%C3%BCssen_die_X_Stunden/Tag_trotzdem_erreicht_werden).
Guten Abend Heiko,
bei der Grafikanzeige gibt es wegen der evtl. vielen Nachkommastellen bei den Berechnungen der Differenzen bei den Batterien manchmal sehr breite Balken.
Kannst du diese breiten Balken eventuell durch ein sinniges Runden auf max. 1 oder max 2 Stellen vermeiden ?
(Siehe Screenshot)
Gruß
300P
Na klar, schaue ich mir morgen mal an.
LG
Moin,
beschäftige mich grade erstmalig mit dem Modul. Sieht toll aus, kann bestimmt viel - ich noch nicht. ;D
Der KI-Status ist bei mir aber - wie im Screen von 300P auch zu sehen - immer gelb. Hinweis: "KI-Unterstützung arbeitet einwandfrei, liefert jedoch keinen Wert für die aktuelle Stunde. Letztes KI-Training 02.03.2025 02:16.
Ist das normal? Oder hat das Modul noch zu wenige Werte, weil noch nicht lange genug am Start? Oder muss ich noch etwas einstellen?
Gruß Jens
Hallo liebe Gemeinde, ich habe mein SolarForecast jetzt mal in mein ftui2 intgeriert und leider nur einen Teilerforlg erzielt.
Mir wäre das Layout und die Darstellung des data-type="forecast" am liebsten. Packe ich dann aber die Kommandos genau wie in der WIKI page angegeben auf meine Seite bekomme ich eine Darstellung GIGANTISCH gross (ca. 10 mal so gross wie mein gesamtes tablet").
<li data-row="4" data-col="3" data-sizex="30" data-sizey="21">
<div class="cell" style="font-size:80%;">
<div data-type="forecast" data-device="PVForecast" data-get="state" data-html="both"</div>
</div>
</li>
Setze ich dann allerdings data-type="smaportalspg" ein, so ist alles vollkommen normal. Allerdings ist diese Darstellung nicht die welche ich gerne hätte.....
<li data-row="4" data-col="3" data-sizex="30" data-sizey="21">
<div class="cell" style="font-size:80%;">
<div data-type="smaportalspg" data-device="PVForecast" data-get="state" data-html="both"</div>
</div>
</li>
Hat das jemand anders auch schon mal gehabt?
Ich muss leider gleich noch eine Frage an den Entwickler durchschiessen.
Meine Raspi Installation war jetzt ca. 7 Jahre alt und diverse APT Module waren so buggy, dass ich praktisch keine Pakete mehr nachinstallieren konnte. DaHer: Alles neu macht der März und ich habe ein komplett neues Raspi aufgesetzt. Puh, jetzt bin ich echt am kämpfen, alle losen Enden wieder zusammn zu bekommen. Eines ist Solar Forecast. Ich habe das fehm.cfg rübergeholt und die meiste devices sind auch da. Auch SolarForcast, ABER WIEDER KOMPLETT unkonfiguriert !!
Was muss ich mit rüberholen, um den alten Zustand zu bekommen?? (habe das FhemUtils schon auch rübergeholt, aber das hat nix geholfen)
@BlackHawk133,
ZitatWas muss ich mit rüberholen, um den alten Zustand zu bekommen?? (habe das FhemUtils schon auch rübergeholt, aber das hat nix geholfen)
Die Wiederherstellung ist recht einfach. Es sind aber ein paar Schritte zu beachten die ich im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Backup_und_Wiederherstellung_der_Moduldaten) beschrieben habe.
Hallo Jens,
ZitatDer KI-Status ist bei mir aber - wie im Screen von 300P auch zu sehen - immer gelb. Hinweis: "KI-Unterstützung arbeitet einwandfrei, liefert jedoch keinen Wert für die aktuelle Stunde. Letztes KI-Training 02.03.2025 02:16.
Ist das normal? Oder hat das Modul noch zu wenige Werte, weil noch nicht lange genug am Start? Oder muss ich noch etwas einstellen?
Ja, das ist normal wenn noch nicht genug Traingsdaten vorhanden sind. Man kann sich einen kleinen Eindruck der vorhandenen Daten mit "get ... valDecTree ..." verschaffen.
Ich werden nachher noch eine Version zum Testen bereitstellen bei der ich die KI mit einem Ensemble-Algorithmus angereichert habe. Es werden mehrere Entscheidungsbäume auf unterschiedliche Stichproben der Trainingsdaten trainiert und die Vorhersagen gemittelt (Bootstrap Aggregating = Bagging). Das verbessert die Genauigkeit und Robustheit der Vorhersagen, benötigt aber Speicher und CPU-Ressourcen. Ich habe erstmal mit einem Ensemble von 10 Stichproben begonnen und dann schauen wir mal wie sich das darstellt.
An den Trainingsdaten liegt das n.m.M evtl. nicht allein - ich habe ja fast ein Jahr an KI-Daten im Speicher
In meinem contrib liegt die V 1.47.0 zum Testen.
@300P, die Dezimalstellen bei der Diff-Darstellung habe ich überarbeitet.
Die Menge Trainingsdaten sind schon entscheidend für die Trefferquote. Aber natürlich nicht allein. In der neuen V werden mehrere Entscheidungsbäume auf unterschiedliche Stichproben der Trainingsdaten trainiert und die Vorhersagen gemittelt (Bootstrap Aggregating = Bagging). Das verbessert die Genauigkeit und Robustheit der Vorhersagen der KI, benötigt aber Speicher und CPU-Ressourcen. Ich habe erstmal mit einem Ensemble von 10 Stichproben begonnen und dann schauen wir mal wie sich das darstellt.
Vielleicht bietet sich zukünftig ein Attribut an, damit der User das Ensemble auf die Leistungsfähigkeit seiner Hardware abstimmen kann.
Jedenfalls bekomme ich nun bei mir deutlich mehr Treffer (get ... forecastQualities):
Start: 2025-03-03 07:00:00, Quality: 0.57, Factor: 1.18, AI usage: 0, PV expect: 548 Wh, Sun Alt: -3, Cloud: 0
Start: 2025-03-03 08:00:00, Quality: 0.79, Factor: 1.26, AI usage: 1, PV expect: 1540 Wh, Sun Alt: 6, Cloud: 0
Start: 2025-03-03 09:00:00, Quality: 0.79, Factor: 1.26, AI usage: 1, PV expect: 2158 Wh, Sun Alt: 13, Cloud: 0
Start: 2025-03-03 10:00:00, Quality: 0.91, Factor: 1.10, AI usage: 1, PV expect: 4260 Wh, Sun Alt: 18, Cloud: 0
Start: 2025-03-03 11:00:00, Quality: 0.82, Factor: 1.22, AI usage: 1, PV expect: 5300 Wh, Sun Alt: 21, Cloud: 0
Start: 2025-03-03 12:00:00, Quality: -, Factor: 1.09, AI usage: 0, PV expect: 6767 Wh, Sun Alt: 22, Cloud: 0
Start: 2025-03-03 13:00:00, Quality: 0.85, Factor: 1.18, AI usage: 1, PV expect: 5375 Wh, Sun Alt: 21, Cloud: 0
Start: 2025-03-03 14:00:00, Quality: 0.87, Factor: 0.89, AI usage: 0, PV expect: 4512 Wh, Sun Alt: 17, Cloud: 15
Start: 2025-03-03 15:00:00, Quality: 0.82, Factor: 1.21, AI usage: 1, PV expect: 2288 Wh, Sun Alt: 12, Cloud: 0
Start: 2025-03-03 16:00:00, Quality: 0.74, Factor: 1.35, AI usage: 0, PV expect: 2556 Wh, Sun Alt: 4, Cloud: 0
Start: 2025-03-03 17:00:00, Quality: -, Factor: 0.93, AI usage: 0, PV expect: 295 Wh, Sun Alt: -4, Cloud: 18
AI usage: 1 bedeutet Treffer duch die KI
Bei mir ist es sehr selten das ich mal ein "grün" sehe - liege aber auch nicht den ganzen Tag vor dem Bildschirm ;D
Woran es bei mir liegt das die Quote meist niedrig liegt --- habe ich noch überhaupt keinen Ansatz und auch keinen blassen Schimmer.
Vielleicht liegt es einfach an der Übergangszeit mit all den Unwägbarkeiten in dieser Zeit
Bei knallender Sonne + ohne Wolken ( wie heute) liege ich bei mir sehr oft bei Factor >1.4 daneben.
Ich habe aber auch 3 Wechselrichter, 6 Strings :-[ und das in 3 Richtungen O:-)
Start: 2025-03-03 07:00:00, Quality: -, Factor: 1.00, AI usage: 1, PV expect: 13 Wh, Sun Alt: -6, Cloud: 23
Start: 2025-03-03 08:00:00, Quality: 0.86, Factor: 0.94, AI usage: 1, PV expect: 161 Wh, Sun Alt: 3, Cloud: 22
Start: 2025-03-03 09:00:00, Quality: 0.87, Factor: 0.94, AI usage: 1, PV expect: 447 Wh, Sun Alt: 11, Cloud: 23
Start: 2025-03-03 10:00:00, Quality: -, Factor: 1.40, AI usage: 0, PV expect: 1581 Wh, Sun Alt: 16, Cloud: 23
Start: 2025-03-03 11:00:00, Quality: -, Factor: 1.47, AI usage: 0, PV expect: 2420 Wh, Sun Alt: 20, Cloud: 24
Start: 2025-03-03 12:00:00, Quality: -, Factor: 1.75, AI usage: 1, PV expect: 2352 Wh, Sun Alt: 22, Cloud: 23
Start: 2025-03-03 13:00:00, Quality: -, Factor: 1.63, AI usage: 0, PV expect: 3672 Wh, Sun Alt: 22, Cloud: 21
Start: 2025-03-03 14:00:00, Quality: -, Factor: 1.40, AI usage: 0, PV expect: 3004 Wh, Sun Alt: 18, Cloud: 20
Start: 2025-03-03 15:00:00, Quality: -, Factor: 1.75, AI usage: 0, PV expect: 2252 Wh, Sun Alt: 14, Cloud: 21
Start: 2025-03-03 16:00:00, Quality: -, Factor: 1.75, AI usage: 0, PV expect: 542 Wh, Sun Alt: 7, Cloud: 22
Es gibt zwei Ebenen ... die Vorhersage durch die gewählte API und die Unterstützung durch die KI (wenn eingeschaltet)
Die API Vorhersage und deren Bewertung/Korrektur ist abhängig ob und wie oft identische Wetterlagen registriert wurden. Ein Indiz dafür sind die Readings:
setstate openMeteo 2025-03-02 08:00:05 pvCorrectionFactor_08 1.75 (automatic - old factor: 1.00, AI result used, Sun Alt range: 5, Cloud range: 85, Days in range: 1)
setstate openMeteo 2025-03-02 09:00:04 pvCorrectionFactor_09 1.17 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 45, Days in range: 1)
setstate openMeteo 2025-03-02 10:00:05 pvCorrectionFactor_10 0.96 (automatic - old factor: 0.91, Sun Alt range: 20, Cloud range: 40, Days in range: 2)
setstate openMeteo 2025-03-02 11:00:04 pvCorrectionFactor_11 1.28 (automatic - old factor: 1.00, AI result used, Sun Alt range: 25, Cloud range: 50, Days in range: 1)
setstate openMeteo 2025-03-02 12:00:03 pvCorrectionFactor_12 1.07 (automatic - old factor: 1.10, AI result used, Sun Alt range: 30, Cloud range: 60, Days in range: 2)
setstate openMeteo 2025-03-02 13:00:04 pvCorrectionFactor_13 1.09 (automatic - old factor: 1.00, AI result used, Sun Alt range: 30, Cloud range: 25, Days in range: 1)
setstate openMeteo 2025-03-02 14:00:04 pvCorrectionFactor_14 0.89 (automatic - old factor: 1.00, AI result used, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate openMeteo 2025-03-02 15:00:04 pvCorrectionFactor_15 0.99 (automatic - old factor: 1.00, AI result used, Sun Alt range: 25, Cloud range: 20, Days in range: 1)
setstate openMeteo 2025-03-02 16:00:04 pvCorrectionFactor_16 1.06 (automatic - old factor: 1.07, Sun Alt range: 20, Cloud range: 10, Days in range: 2)
setstate openMeteo 2025-03-02 17:00:04 pvCorrectionFactor_17 1.23 (automatic - old factor: 1.00, AI result used, Sun Alt range: 10, Cloud range: 20, Days in range: 1)
setstate openMeteo 2025-03-02 18:00:04 pvCorrectionFactor_18 0.93 (automatic - old factor: 0.85, AI result used, Sun Alt range: 5, Cloud range: 25, Days in range: 2)
Ist der Wert von "Days in range" sehr klein, wurde die Wetterlage selten bzw. noch nicht (bei 1) registriert. Der Hinweis "old factor: 1.00" besagt, dass noch keine Bewertung vorlag und deswegen kein Korrekturfaktor angewendet wurde.
Überlagert wirde die Prognose durch die KI wenn "AI result used" angegeben ist. Dann wurde nicht das API-Ergebnis, sondern das KI-Ergebnis verwendet.
Ein "get ... valDecTree aiRuleStrings" (hier in der neuen Version) zeigt die Anzahl der Regeln und Knoten. Ein wesentliches Merkmal welches von der Anzahl der Trainingsdaten abhängig ist. In der neuen Version werden wie gesagt ein Ensemble von 10 Trees verwendet:
Trained AI Object contains an Ensemble of 10 trees (only the first Tree is printed out)
Tree: 1 / Number of Rules: 3266 / Number of Nodes: 4378 / Depth: 5
Tree: 2 / Number of Rules: 3269 / Number of Nodes: 4385 / Depth: 5
Tree: 3 / Number of Rules: 3272 / Number of Nodes: 4375 / Depth: 5
Tree: 4 / Number of Rules: 3268 / Number of Nodes: 4377 / Depth: 5
Tree: 5 / Number of Rules: 3280 / Number of Nodes: 4402 / Depth: 5
Tree: 6 / Number of Rules: 3270 / Number of Nodes: 4400 / Depth: 5
Tree: 7 / Number of Rules: 3276 / Number of Nodes: 4391 / Depth: 5
Tree: 8 / Number of Rules: 3261 / Number of Nodes: 4368 / Depth: 5
Tree: 9 / Number of Rules: 3274 / Number of Nodes: 4381 / Depth: 5
Tree: 10 / Number of Rules: 3265 / Number of Nodes: 4376 / Depth: 5
Zitat von: DS_Starter am 02 März 2025, 20:18:19In meinem contrib liegt die V 1.47.0 zum Testen.
@300P, die Dezimalstellen bei der Diff-Darstellung habe ich überarbeitet.
Hallo Heiko,
schon mal Danke dafür ;D
Zwischenstand:
Aktuell ist ein Differenz-Wert bei den Batteriewerten "Battery_NextHour14_SoCforecast_02 bzw. ..02" für Morgen 14 Uhr mit "+2.90000000000001" nach dem Download und Restart nach einigen Minuten in der Grafik berechnet worden. Das betrifft wie bislang von mir dargestellt nur die Grafik - "richtige" Readings sind alle mit jeweils 1 Kommastelle vorhanden.
Gruß
300P
?
Hier meine Werte:
setstate Forecast 2025-03-02 09:00:05 pvCorrectionFactor_09 1.75 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 55, Days in range: 1)
setstate Forecast 2025-03-02 10:00:03 pvCorrectionFactor_10 1.75 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 50, Days in range: 1)
setstate Forecast 2025-03-02 11:00:03 pvCorrectionFactor_11 1.40 (automatic - old factor: 0.80, Sun Alt range: 25, Cloud range: 45, Days in range: 2)
setstate Forecast 2025-03-02 12:00:04 pvCorrectionFactor_12 1.47 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 40, Days in range: 2)
setstate Forecast 2025-03-02 13:00:00 pvCorrectionFactor_13 1.75 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 35, Days in range: 1)
setstate Forecast 2025-03-02 14:00:07 pvCorrectionFactor_14 1.63 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 35, Days in range: 1)
setstate Forecast 2025-03-02 15:00:03 pvCorrectionFactor_15 1.40 (automatic - old factor: 1.67, AI result used, Sun Alt range: 25, Cloud range: 30, Days in range: 2)
setstate Forecast 2025-03-02 16:00:05 pvCorrectionFactor_16 1.75 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 30, Days in range: 1)
setstate Forecast 2025-03-02 17:00:05 pvCorrectionFactor_17 1.75 (automatic - old factor: 1.00, AI result used, Sun Alt range: 15, Cloud range: 30, Days in range: 1)
setstate Forecast 2025-03-02 21:07:26 pvCorrectionFactor_Auto on_complex_ai
se
Aber hier hakt es wohl - evtl. durch download und Neustart ?
Hab letzte Woche zuletzt dort nachgesehen und dort auch Daten gehabt
AI trained object is missed or not an ARRAY
EDIT
hier noch der Screenshot mit den Kommastellen:
ZitatAber hier hakt es wohl - evtl. durch download und Neustart ?
Einfach mal "set ... aiDecTree addInstances" und danach "set ... aiDecTree train". Das greift der nächsten automatischen Erstellung vor.
Bei dir gibt es halt viele "Days in range: 1". That's live. ;)
Die Nachkommastellen sind mir ein Rätsel. Hast du graphicEnergyUnit = kWh eingestellt?
Ergebnis:
Trained AI Object contains an Ensemble of 10 trees (only the first Tree is printed out)
Tree: 1 / Number of Rules: 2870 / Number of Nodes: 3852 / Depth: 5
Tree: 2 / Number of Rules: 2854 / Number of Nodes: 3854 / Depth: 5
Tree: 3 / Number of Rules: 2857 / Number of Nodes: 3850 / Depth: 5
Tree: 4 / Number of Rules: 2864 / Number of Nodes: 3846 / Depth: 5
Tree: 5 / Number of Rules: 2858 / Number of Nodes: 3834 / Depth: 5
Tree: 6 / Number of Rules: 2846 / Number of Nodes: 3833 / Depth: 5
Tree: 7 / Number of Rules: 2863 / Number of Nodes: 3851 / Depth: 5
Tree: 8 / Number of Rules: 2856 / Number of Nodes: 3847 / Depth: 5
Tree: 9 / Number of Rules: 2845 / Number of Nodes: 3829 / Depth: 5
Tree: 10 / Number of Rules: 2862 / Number of Nodes: 3826 / Depth: 5
Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen
letztes KI-Training: 02.03.2025 21:26:56 / Laufzeit in Sekunden: 7.9520
Fast vergessen:
Unit ist Standart bzw. nicht gesetzt = Wh
Welche Werte werden in den beiden Beams dargestellt, beides batsocforecast?
ja - ist so
attr Forecast flowGraphicControl animate=1 consumerdist=130 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
attr Forecast graphicBeam1Color 3C14FF
attr Forecast graphicBeam1Content pvReal
attr Forecast graphicBeam2Color 19FF29
attr Forecast graphicBeam2Content pvForecast
attr Forecast graphicBeam3Color D60924
attr Forecast graphicBeam3Content batsocforecast_01
attr Forecast graphicBeam3FontColor FFFF0D
attr Forecast graphicBeam4Color FFFF1F
attr Forecast graphicBeam4Content batsocforecast_02
attr Forecast graphicBeam4FontColor 000000
attr Forecast graphicHeaderDetail all
Zieh bitte nochmal aus dem contrib.
Fürs erste jetzt mal ohne "breite" Balken.
Melde morgen den Status erneut nach mehreren Stunden Laufzeit.
Gruß
300P
Das ist schonmal gut.
Bitte zieh nochmal aus dem contrib und dann schauen wir morgen nochmal wenn es jetzt passt.
..
Moin DS_Starter,
ich habe die gestern die Version aus Deinem contrib gezogen. Alles bestens.
Nach dem update heute früh startete fhem nicht mehr. Es wurde nur das Modul 76_SolarForecast.pm upgedatet.
Ich habe wieder die Version aus Deinem contrib eingespielt. Wieder alles gut.
Grüße
Jens
Moin Jens,
dann sind die Erweiterungen in der KI nicht rückwärtskompatibel.
Hatte ich selbst noch garnicht probiert. Rückwärts gehen wir normal nicht. ;)
Probiere ich aber nachher mal bei mir aus. Vllt ist es nur eine Kleinigkeit.
Du kannst das Modul vorübergehend vom Update ausnehmen -> global -> exclude_from_update.
LG,
Heiko
Kurze Rückinfo.
Ich kann bestätigen, dass eine rückwärts Kompatibilität nicht gegeben ist.
Ist aber ok. Wir gehen nur vorwärts. :)
LG
Heute sieht man übrigens gut wie die netzdienliche Steuerung bzgl. Batteriemanagement arbeitet.
Zur Zeit wird eingespeist statt die Battrie zu laden. Die Batterie schwankt immer etwas zwischen kleiner Entladung, kleiner Ladung und Standby. Über den Setpoint wird gesteuert dass aktuell der Überschuß eingespeist wird. Die Ladefreigabe geht ab 12:00 los. Die meisten Anlagen werden dann einspeisen weil deren Batterien schon voll sein werden. Meine ist immer noch nur zu 70% geladen.
Heute ist es bei mir nicht, aber Gestern war es nach längerer Zeit so.
Seit Jahresanfang bislang mehrfach vorgekommen
->> aber immer nur Batterie01 ;D noch nicht bei Batterie02
Gestern mal als Screenshot zur Info O:-)
Nachtrag:
Batterieladestatus hinzugefügt
Zitat von: DS_Starter am 02 März 2025, 21:58:10Das ist schonmal gut.
Bitte zieh nochmal aus dem contrib und dann schauen wir morgen nochmal wenn es jetzt passt.
Guten Abend Heiko,
über den Tag war leider ab und an da wieder mal ein ,,dicker" Balken zu sehen.
Gruß
300P
@300P, das ist echt eine schwere Geburt.
Ich habe dir wieder ein Update in mein contrib geladen.
Bitte unbedingt fhem restarten. Es sind bereits weitere Entwicklungen enthalten.
LG
Na d ann schauen wir mal :o
Melde mich dann wieder morgen ob es sauber ist oder nicht. 😉
Hallo Heiko!
ich habe mich in den letzten Tagen ein wenig mit der Prognose des Batterie-SoC beschäftigt. Eine Ladesteuerung (Freigabe) kann ich bei mir leider nicht umsetzen.
Dabei ist mir die Frage aufgekommen, ob ich irgendwo angeben kann, mit welcher maximalen Leistung die Batterie(n) geladen und/oder entladen werden können.
Hintergrund: Meine Enphase-Speicher können leider nur mit insgesamt 2580 W ge- oder entladen werden.
Entsteht mehr PV-Überschuss, muss er verbraucht oder eingespeist werden.
Ich weiß nicht, ob das viele Nutzer des Moduls betrifft.
Und noch eine zweite Frage: Hast Du eine Erklärung dafür, was im Screenshot anbei zu sehen ist?
Für 12 Uhr wird der SoC auf 5% (mein MinSoC) prognostiziert, obwohl zuvor PV-Überschuss prognostiziert ist.
(oberes Diagramm ist Erzeugung, unteres Verbrauch)
Vielen Dank und viele Grüße,
Peter
Hallo Peter,
n.m.M. ist das erste ein Problem das alle haben, die eine Steuerung vorhaben die nur mittels genauer Angabe der Einspeise-/Bezugsleistung steuern wollen bzw. können. Das ist aber Anlagenspezifisch, wie du schon angemerkt hast.
Die meisten werden es mit einer Routine lösen, die sich genau nach diesem Wert orientiert und entsprechend gegensteuert.
Das grundsätzliche Einspeisen oder Laden (0/1) mit dem Maximalwert der Batterie kann man aber damit lösen das man die Maximalwerte der Werte für das Be-Laden / Entladen (0/1) zur Batterie hin durch eine eigen Routine der Batterie vorgibt.
Wenn die Batterie VOLL oder LEER ist wird sich das BMS schon automatisiert bei deiner Batterie einschalten und die Aktivität begrenzen O:-)
Zu der zweiten Frage:
Das kommt auch auf viele an Faktoren an. Du hast hier einen Zustand für 12:00 der angezeigt wird. Dieser wird aber evtl. durch deinen Verbrauch in den vorherigen Stunden verursacht. (man kann so nicht alles sehen was vorher sein wird)
Wenn das aber unbegründet so sein sollte =>@Heiko wird sich sicher dazu äußern.
Gruß
300P
Hallo,
zunächst einmal vielen Dank für dieses tolle Modul. Ich find's klasse! :D
Seit dem letzten Update wird mir die Batterieladung in der Grafik allerdings immer mit 0% angezeigt.
Die Readings zeigen einen anderen Wert.
Was und wo muss man etwas anpassen?
Vielen Dank für eine kurze Rückmeldung.
Bis denn
SouzA
Moin,
@SouzA,
freut mich, vielen Dank. :)
im setupBatteryDevXX das cap richtig! (Hilfetext genau lesen) angeben. Dann klappts auch wieder mit der Darstellung.
@Peter,
ZitatDabei ist mir die Frage aufgekommen, ob ich irgendwo angeben kann, mit welcher maximalen Leistung die Batterie(n) geladen und/oder entladen werden können.
wie 300P geschrieben hat, ist jede Batterieanlage spezifisch. Bei meiner Victron kann ich das auch nicht "direkt" steuern , sondern nur über den Umweg Grid Setpoint, d.h. über die Angabe dass X zwangseingespeist wird und der Rest verbraucht bzw. in der Bat gespeichert. Durch eine dynamische Berechnung kann der Grid Setpoint geschickt so gesetzt werden, dass die gewünschte Steuerung umgesetzt wird. Habe ich im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Umsetzungsbeispiel_Batterie_Ladesteuerung_mit_Victron_GX_Venus_%C3%BCber_den_Grid_Setpoint) beschrieben.
Bzgl. der SoC-Prognose kann man sich ctrlDebug=batteryManagement setzen. Dann bekommt man eijne Ausgabe welche die Berechnungsschritte der Prognose zeigt. Daran sollte man erkennen weshalb dieser Wert prognostiziert wird. Sieht etwa so aus:
...
2025.03.04 08:45:28.024 1: SolCast DEBUG> Bat 01 relLoad 04 08 -> 0 (currsoc: 70 %, SoCfc: 67.7 %, soc: 19233 Wh, pvfc: 412, confc: 592, Surp Day: 29833 Wh, Curr PV: 1693 W, Curr Consumption: 512 W, Limit: 7080 W)
2025.03.04 08:45:28.024 1: SolCast DEBUG> Bat 01 relLoad 04 09 -> 0 (SoCfc: 65.6 %, soc: 18632 Wh, pvfc: 2777, confc: 541, Surp Day: 27597 Wh)
2025.03.04 08:45:28.024 1: SolCast DEBUG> Bat 01 relLoad 04 10 -> 0 (SoCfc: 62.7 %, soc: 17813 Wh, pvfc: 5115, confc: 737, Surp Day: 23219 Wh)
2025.03.04 08:45:28.025 1: SolCast DEBUG> Bat 01 relLoad 04 11 -> 0 (SoCfc: 56.8 %, soc: 16127 Wh, pvfc: 5747, confc: 1517, Surp Day: 18989 Wh)
2025.03.04 08:45:28.025 1: SolCast DEBUG> Bat 01 relLoad 04 12 -> 1 (SoCfc: 70.4 %, soc: 19992 Wh, pvfc: 5527, confc: 1232, Surp Day: 14694 Wh)
2025.03.04 08:45:28.025 1: SolCast DEBUG> Bat 01 relLoad 04 13 -> 1 (SoCfc: 86.2 %, soc: 24484 Wh, pvfc: 6063, confc: 1072, Surp Day: 9703 Wh)
2025.03.04 08:45:28.026 1: SolCast DEBUG> Bat 01 relLoad 04 14 -> 0 (SoCfc: 82.5 %, soc: 23443 Wh, pvfc: 5115, confc: 937, Surp Day: 5525 Wh)
2025.03.04 08:45:28.026 1: SolCast DEBUG> Bat 01 relLoad 04 15 -> 1 (SoCfc: 92.9 %, soc: 26401 Wh, pvfc: 3933, confc: 646, Surp Day: 2238 Wh)
2025.03.04 08:45:28.026 1: SolCast DEBUG> Bat 01 relLoad 04 16 -> 1 (SoCfc: 99.1 %, soc: 28174 Wh, pvfc: 2666, confc: 696, Surp Day: 268 Wh)
2025.03.04 08:45:28.027 1: SolCast DEBUG> Bat 01 relLoad 04 17 -> 1 (SoCfc: 99.1 %, soc: 28160 Wh, pvfc: 577, confc: 592, Surp Day: 0 Wh)
2025.03.04 08:45:28.027 1: SolCast DEBUG> Bat 01 relLoad 04 18 -> 1 (SoCfc: 96.7 %, soc: 27474 Wh, pvfc: 0, confc: 762, Surp Day: 0 Wh)
2025.03.04 08:45:28.027 1: SolCast DEBUG> Bat 01 relLoad 04 19 -> 1 (SoCfc: 93.3 %, soc: 26504 Wh, pvfc: 0, confc: 1078, Surp Day: 0 Wh)
2025.03.04 08:45:28.028 1: SolCast DEBUG> Bat 01 relLoad 04 20 -> 1 (SoCfc: 91.1 %, soc: 25882 Wh, pvfc: 0, confc: 691, Surp Day: 0 Wh)
2025.03.04 08:45:28.028 1: SolCast DEBUG> Bat 01 relLoad 04 21 -> 1 (SoCfc: 88.9 %, soc: 25251 Wh, pvfc: 0, confc: 701, Surp Day: 0 Wh)
2025.03.04 08:45:28.028 1: SolCast DEBUG> Bat 01 relLoad 04 22 -> 1 (SoCfc: 86.8 %, soc: 24655 Wh, pvfc: 0, confc: 662, Surp Day: 0 Wh)
2025.03.04 08:45:28.028 1: SolCast DEBUG> Bat 01 relLoad 04 23 -> 1 (SoCfc: 84.9 %, soc: 24123 Wh, pvfc: 0, confc: 591, Surp Day: 0 Wh)
2025.03.04 08:45:28.029 1: SolCast DEBUG> Bat 01 relLoad 05 00 -> 1 (SoCfc: 83.1 %, soc: 23610 Wh, pvfc: 0, confc: 570, Surp Day: 0 Wh)
2025.03.04 08:45:28.029 1: SolCast DEBUG> Bat 01 relLoad 05 01 -> 1 (SoCfc: 81.6 %, soc: 23177 Wh, pvfc: 0, confc: 481, Surp Day: 0 Wh)
2025.03.04 08:45:28.029 1: SolCast DEBUG> Bat 01 relLoad 05 02 -> 1 (SoCfc: 80.0 %, soc: 22729 Wh, pvfc: 0, confc: 498, Surp Day: 0 Wh)
2025.03.04 08:45:28.030 1: SolCast DEBUG> Bat 01 relLoad 05 03 -> 1 (SoCfc: 78.4 %, soc: 22289 Wh, pvfc: 0, confc: 489, Surp Day: 0 Wh)
2025.03.04 08:45:28.030 1: SolCast DEBUG> Bat 01 relLoad 05 04 -> 1 (SoCfc: 76.9 %, soc: 21860 Wh, pvfc: 0, confc: 477, Surp Day: 0 Wh)
2025.03.04 08:45:28.030 1: SolCast DEBUG> Bat 01 relLoad 05 05 -> 1 (SoCfc: 75.4 %, soc: 21426 Wh, pvfc: 0, confc: 482, Surp Day: 0 Wh)
2025.03.04 08:45:28.031 1: SolCast DEBUG> Bat 01 relLoad 05 06 -> 1 (SoCfc: 75.4 %, soc: 21416 Wh, pvfc: 0, confc: 11, Surp Day: 0 Wh)
2025.03.04 08:45:28.031 1: SolCast DEBUG> Bat 01 relLoad 05 07 -> 0 (SoCfc: 73.2 %, soc: 20802 Wh, pvfc: 1143, confc: 553, Surp Day: 26667
...
Die Ausgaben mit "relLoad" sind die relevanten (es gibt auch andere). SoCfc ist der SoC Forecast (%) in dem Schritt. Die Daten dahinter sind die Werte die die Prognose beeinflussen, pvfc - PV Forecast, confc - Verbrauchsvorhersage, Surp Day - vorr. PV Überschuß für den Resttag
LG,
Heiko
Zitat von: DS_Starter am 04 März 2025, 08:53:55Moin,
@SouzA,
freut mich, vielen Dank. :)
im setupBatteryDevXX das cap richtig! (Hilfetext genau lesen) angeben. Dann klappts auch wieder mit der Darstellung.
Ja, das war's. Vielen Dank für den Support!
Ich hätte da jetzt nicht mehr gesucht, weil es ja schon lief (>1 Jahr)...
Thx & bis denn
SouzA
Hallo Heiko und 300P,
ich danke Euch für die schnellen Antworten.
Das Beispiel im Wiki habe ich mir angesehen, aber nicht komplett durchdrungen. Vielleicht deshalb, weil ich meine Batterieladung ohnehin nicht (so richtig gar nicht, auch nicht indirekt) steuern kann.
Ich hatte nur gehofft, die modulinterne SoC-Prognose mit der Angabe der max. Ent-/Ladeleistung unterstützen zu können.
Zitat von: DS_Starter am 04 März 2025, 08:53:55Die Ausgaben mit "relLoad" sind die relevanten (es gibt auch andere). SoCfc ist der SoC Forecast (%) in dem Schritt. Die Daten dahinter sind die Werte die die Prognose beeinflussen, pvfc - PV Forecast, confc - Verbrauchsvorhersage, Surp Day - vorr. PV Überschuß für den Resttag
Das sieht bei mir so aus:
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 09 -> 0 (currsoc: 15 %, SoCfc: 5.0 %, soc: 350 Wh, pvfc: 2622, confc: 792, Surp Day: 15528 Wh, Curr PV: 2291 W, Curr Consumption: 2709 W, Limit: 10000 W)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 10 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 3473, confc: 1055, Surp Day: 13110 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 11 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 3908, confc: 1284, Surp Day: 10486 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 12 -> 1 (SoCfc: 47.7 %, soc: 3339 Wh, pvfc: 4849, confc: 1528, Surp Day: 7165 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 13 -> 1 (SoCfc: 87.7 %, soc: 6142 Wh, pvfc: 4543, confc: 1429, Surp Day: 4051 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 14 -> 0 (SoCfc: 70.9 %, soc: 4964 Wh, pvfc: 3002, confc: 1060, Surp Day: 2109 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4111, confc: 1073, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 16 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 1389, confc: 700, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 17 -> 1 (SoCfc: 94.3 %, soc: 6601 Wh, pvfc: 257, confc: 700, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 18 -> 1 (SoCfc: 84.4 %, soc: 5908 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 19 -> 1 (SoCfc: 76.4 %, soc: 5348 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 20 -> 1 (SoCfc: 68.0 %, soc: 4763 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 21 -> 1 (SoCfc: 60.5 %, soc: 4232 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 22 -> 1 (SoCfc: 53.5 %, soc: 3742 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 23 -> 1 (SoCfc: 46.7 %, soc: 3270 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 00 -> 1 (SoCfc: 40.6 %, soc: 2839 Wh, pvfc: 0, confc: 479, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 01 -> 1 (SoCfc: 34.0 %, soc: 2382 Wh, pvfc: 0, confc: 508, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 02 -> 1 (SoCfc: 26.8 %, soc: 1875 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 03 -> 1 (SoCfc: 20.4 %, soc: 1428 Wh, pvfc: 0, confc: 497, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 04 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 466, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 05 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 463, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 06 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 13, confc: 648, Surp Day: 27777 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 07 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 386, confc: 649, Surp Day: 27391 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 08 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 1198, confc: 938, Surp Day: 26193 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 09 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 2830, confc: 792, Surp Day: 23363 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 10 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 4316, confc: 1055, Surp Day: 19047 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 11 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 1889, confc: 1284, Surp Day: 17158 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 12 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 4260, confc: 1528, Surp Day: 12898 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 13 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 4220, confc: 1429, Surp Day: 8678 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 14 -> 1 (SoCfc: 40.0 %, soc: 2803 Wh, pvfc: 3786, confc: 1060, Surp Day: 4892 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 15 -> 1 (SoCfc: 61.3 %, soc: 4291 Wh, pvfc: 2726, confc: 1073, Surp Day: 2166 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 16 -> 1 (SoCfc: 76.0 %, soc: 5319 Wh, pvfc: 1842, confc: 700, Surp Day: 324 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 17 -> 1 (SoCfc: 71.2 %, soc: 4981 Wh, pvfc: 324, confc: 700, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 18 -> 1 (SoCfc: 61.3 %, soc: 4288 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 19 -> 1 (SoCfc: 53.3 %, soc: 3728 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 20 -> 1 (SoCfc: 44.9 %, soc: 3143 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 21 -> 1 (SoCfc: 37.3 %, soc: 2612 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 22 -> 1 (SoCfc: 30.3 %, soc: 2122 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 05 23 -> 1 (SoCfc: 23.6 %, soc: 1650 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
Lese ich das alles richtig?
Für die 10-Uhr-Stunde wird da 3473Wh Erzeugung und 1055Wh Verbrauch prognostiziert, oder?
Demnach müssten doch ca. 2400 Wh in die Batterie geladen werden, trotzdem ist der SoCfc um 11 gleich dem um 10 Uhr.
Abgesehen davon sollte doch der SoCfc für die 10-Uhr-Stunde über dem currsoc der 9-Uhr-Stunde liegen.
Und von 11-12 Uhr "springt" der SoCfc dann hoch auf 47,7%, also um über 3000Wh. Und genau das ist bei meinem Speicher nicht realistisch möglich, da die max. Ent-/Ladeleistung nur 2580W beträgt.
In der 9-Uhr-Zeile steht ganz hinten "Limit: 10000 W". Das ist wohl die Nennleistung des Wechselrichters. Bei mir kann die Batterie leider deutlich weniger.
Ich hoffe, ich hab jetzt nicht zu viel "wirres Zeug" geschrieben. Vielleicht erklärt das, woher mein Gedanke kommt, die Ladeleistung noch anzugeben.
Bitte versteht das nicht als Angriff. Ich möchte hauptsächlich verstehen und ggf. Anregungen zur Optimierung geben.
Danke und Grüße,
Peter
Na dann zeig uns mal dein Batterie-Device.
Vielleicht erkennt man daran was. 😉
Gruß
300P
Hallo Peter,
ZitatLese ich das alles richtig?
Für die 10-Uhr-Stunde wird da 3473Wh Erzeugung und 1055Wh Verbrauch prognostiziert, oder?
Demnach müssten doch ca. 2400 Wh in die Batterie geladen werden, trotzdem ist der SoCfc um 11 gleich dem um 10 Uhr.
Die Sichtweise wäre völlig richtig wenn es für diese Zeit eine Ladefreigabe gäbe. Die ist aber nicht gegeben. Das sieht man an "relLoad XX XX -> 0" (relLoad = release Load).
D.h. das Modul geht davon aus, dass deswegen keine Aufladung erfolgt, also Standby oder Entladung.
Allerdings muß ich die Stelle nochmal prüfen unter dem Gesichtspunkt, dass in der Stunde ein effektiver Überschuß vorhanden ist und demnach die Bat im Standby verbleiben sollte und effektiv kein Entladen erfährt.
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 09 -> 0 (currsoc: 15 %, SoCfc: 5.0 %, soc: 350 Wh, pvfc: 2622, confc: 792, Surp Day: 15528 Wh, Curr PV: 2291 W, Curr Consumption: 2709 W, Limit: 10000 W)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 10 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 3473, confc: 1055, Surp Day: 13110 Wh)
2025.03.04 09:44:21 1: SolarForecast DEBUG> Bat 01 relLoad 04 11 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 3908, confc: 1284, Surp Day: 10486 Wh)
ZitatAbgesehen davon sollte doch der SoCfc für die 10-Uhr-Stunde über dem currsoc der 9-Uhr-Stunde liegen.
Wie oben. Weil keine Aufladung freigegeben ist, bleibt der SoCfc der Stunde 10 bei der Prognose von Stunde 09.
ZitatIn der 9-Uhr-Zeile steht ganz hinten "Limit: 10000 W". Das ist wohl die Nennleistung des Wechselrichters. Bei mir kann die Batterie leider deutlich weniger.
Das ist kein Problem. Diese Angabe ist für die Berechnung der Lade-Freigabe unter Berücksichtigung eines Limits (70% Regel, 60% Regel, VNB-Limit ...) relevant.
LG
@300P ... wie sehen deine Balkenbreiten aus?
Bislang alles ,,tippi toppi" 👍
Zitat von: 300P am 04 März 2025, 11:19:48Na dann zeig uns mal dein Batterie-Device.
Vielleicht erkennt man daran was. 😉
Gruß
300P
Das sieht so aus:
attr SolarForecast setupBatteryDev01 Enphase pin=StorageFeedIn:W intotal=StorageWhCharged:Wh pout=StorageConsumption:W outtotal=StorageWhDischarged:Wh charge=StorageFullPercent cap=7000 intotal=StorageWhCharged:Wh outtotal=StorageWhDischarged:Wh show=1 asynchron=1
attr Solarforecast ctrlBatSocManagement01 lowSoc=5 upSoC=50
Grüße,
Peter
Hallo Peter,
da ist etwas doppelt darin eingerichtet, kann sein das es daran liegt: (zu viele Parameter :o )
attr SolarForecast setupBatteryDev01 Enphase pin=StorageFeedIn:W intotal=StorageWhCharged:Wh pout=StorageConsumption:W outtotal=StorageWhDischarged:Wh charge=StorageFullPercent cap=7000 intotal=StorageWhCharged:Wh outtotal=StorageWhDischarged:Wh show=1 asynchron=1
attr Solarforecast ctrlBatSocManagement01 lowSoc=5 upSoC=50
Und Dein lowSoc ist evtl. auch etwas zu klein gewählt - geht auf die Batterielebensdauer ;)
Bitte mal wie folgt anpassen:
attr SolarForecast setupBatteryDev01 Enphase pin=StorageFeedIn:W pout=StorageConsumption:W intotal=StorageWhCharged:Wh outtotal=StorageWhDischarged:Wh charge=StorageFullPercent cap=7000 show=1 asynchron=1
attr Solarforecast ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=95 careCycle=20
@Peter,
ich habe auch etwas gemacht:
ZitatAllerdings muß ich die Stelle nochmal prüfen unter dem Gesichtspunkt, dass in der Stunde ein effektiver Überschuß vorhanden ist und demnach die Bat im Standby verbleiben sollte und effektiv kein Entladen erfährt.
Das habe ich gemacht und ein Updaqte in mein contrib geladen.
Zieh dir bitte die Version, starte FHEM neu und erstelle nochmal das Debuglog. Sollte besser aussehen bzgl. Standby vs. Entladen.
@300P, kannst du auch gerne testen.
LG
Hallo 300P,
danke für die Kontrolle und Deine Anmerkungen.
Zitat von: 300P am 04 März 2025, 12:53:13da ist etwas doppelt darin eingerichtet, kann sein das es daran liegt: (zu viele Parameter :o )
-> korrigiert. Vielen Dank!
Zitat von: 300P am 04 März 2025, 12:53:13Und Dein lowSoc ist evtl. auch etwas zu klein gewählt - geht auf die Batterielebensdauer ;)
--> Darauf habe ich leider keinen Einfluss. Das steuert das Enphase Gateway selbst.
Ich habe ihn nur gesetzt, damit die Anzeige in fhem realistischer ist. Tatsächlich wird der SoC sogar häufig bis 3% runter gefahren.
Zitat von: DS_Starter am 04 März 2025, 12:55:42Zieh dir bitte die Version, starte FHEM neu und erstelle nochmal das Debuglog. Sollte besser aussehen bzgl. Standby vs. Entladen.
-> Auch Dir vielen Dank für den immer wieder schnellen Service! Ich habe die Datei gezogen und neu gestartet. Ich werde es nachher mal genauer ansehen.
Danke und Grüße,
Peter
Edit: Hier der aktuelle Log-Auszug. Sieht aus, als wäre die Ladefreigabe jetzt immer an?
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 13 -> 1 (currsoc: 99 %, SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4543, confc: 1429, Surp Day: 3574 Wh, Curr PV: 3794 W, Curr Consumption: 3378 W, Limit: 10000 W)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 14 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3571, confc: 1060, Surp Day: 1063 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 2538, confc: 1073, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 16 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 1252, confc: 700, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 17 -> 1 (SoCfc: 93.4 %, soc: 6540 Wh, pvfc: 286, confc: 700, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 18 -> 1 (SoCfc: 81.2 %, soc: 5684 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 19 -> 1 (SoCfc: 71.3 %, soc: 4993 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 20 -> 1 (SoCfc: 61.0 %, soc: 4271 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 21 -> 1 (SoCfc: 51.6 %, soc: 3615 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 22 -> 1 (SoCfc: 43.0 %, soc: 3009 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 04 23 -> 1 (SoCfc: 34.7 %, soc: 2426 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 00 -> 1 (SoCfc: 27.1 %, soc: 1894 Wh, pvfc: 0, confc: 479, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 01 -> 1 (SoCfc: 19.0 %, soc: 1330 Wh, pvfc: 0, confc: 508, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 02 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 03 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 497, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 04 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 466, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 05 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 463, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 06 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 648, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 07 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 356, confc: 649, Surp Day: 27093 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 08 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 1212, confc: 938, Surp Day: 25881 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 09 -> 1 (SoCfc: 40.5 %, soc: 2835 Wh, pvfc: 2798, confc: 815, Surp Day: 23083 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 10 -> 1 (SoCfc: 83.7 %, soc: 5857 Wh, pvfc: 4359, confc: 1001, Surp Day: 18724 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 11 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4810, confc: 819, Surp Day: 13914 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 12 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 1826, confc: 1481, Surp Day: 12088 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 13 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4342, confc: 1429, Surp Day: 7746 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 14 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3880, confc: 1060, Surp Day: 3866 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 2817, confc: 1073, Surp Day: 1049 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 16 -> 1 (SoCfc: 100.0 %, soc: 6998 Wh, pvfc: 698, confc: 700, Surp Day: 351 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 17 -> 1 (SoCfc: 94.4 %, soc: 6610 Wh, pvfc: 351, confc: 700, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 18 -> 1 (SoCfc: 82.2 %, soc: 5754 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 19 -> 1 (SoCfc: 72.3 %, soc: 5063 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 20 -> 1 (SoCfc: 62.0 %, soc: 4341 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 21 -> 1 (SoCfc: 52.6 %, soc: 3685 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 22 -> 1 (SoCfc: 44.0 %, soc: 3079 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 13:25:17 1: SolarForecast DEBUG> Bat 01 relLoad 05 23 -> 1 (SoCfc: 35.7 %, soc: 2496 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
ZitatSieht aus, als wäre die Ladefreigabe jetzt immer an?
Das täuscht weil wir jetzt schon über den Zenit bzw. Max-Value sind.
Aber damit es um diese Zeit für den kommenden Tag transparenter aussieht habe ich noch etwas angepasst.
Liegt im contrib.
Übrigens zeigt der KI Umbau Wirkung. Es gibt deutlich mehr KI Treffer bei mir.
Ein Mouse-Over über den KI-Status zeigt nun auch die benötigte Zeit für eine KI-Anfrage durch das Modul.
Im "get .. valDecTree aiRuleStrings" sieht man die Zeit jetzt auch.
Hallo Heiko,
ich habe die neue Version gezogen. Jetzt ist die Ladeempfehlung nicht immer an:
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 13 -> 1 (currsoc: 100 %, SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4543, confc: 1429, Surp Day: 2450 Wh, Curr PV: 4478 W, Curr Consumption: 3665 W, Limit: 10000 W)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 14 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3604, confc: 1060, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3804, confc: 1073, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 16 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 1252, confc: 700, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 17 -> 1 (SoCfc: 93.4 %, soc: 6540 Wh, pvfc: 286, confc: 700, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 18 -> 1 (SoCfc: 81.2 %, soc: 5684 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 19 -> 1 (SoCfc: 71.3 %, soc: 4993 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 20 -> 1 (SoCfc: 61.0 %, soc: 4271 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 21 -> 1 (SoCfc: 51.6 %, soc: 3615 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 22 -> 1 (SoCfc: 43.0 %, soc: 3009 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 04 23 -> 1 (SoCfc: 34.7 %, soc: 2426 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 00 -> 1 (SoCfc: 27.1 %, soc: 1894 Wh, pvfc: 0, confc: 479, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 01 -> 1 (SoCfc: 19.0 %, soc: 1330 Wh, pvfc: 0, confc: 508, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 02 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 03 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 497, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 04 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 466, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 05 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 463, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 06 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 648, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 07 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 356, confc: 649, Surp Day: 29301 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 08 -> 0 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 1212, confc: 938, Surp Day: 28089 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 09 -> 0 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 2798, confc: 815, Surp Day: 25291 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 10 -> 0 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 4395, confc: 1001, Surp Day: 20896 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 11 -> 0 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 4916, confc: 819, Surp Day: 15980 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 12 -> 0 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 3892, confc: 1481, Surp Day: 12088 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 13 -> 0 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 4342, confc: 1429, Surp Day: 7746 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 14 -> 1 (SoCfc: 51.3 %, soc: 3588 Wh, pvfc: 3880, confc: 1060, Surp Day: 3866 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 15 -> 1 (SoCfc: 73.7 %, soc: 5158 Wh, pvfc: 2817, confc: 1073, Surp Day: 1049 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 16 -> 1 (SoCfc: 73.7 %, soc: 5156 Wh, pvfc: 698, confc: 700, Surp Day: 351 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 17 -> 1 (SoCfc: 68.1 %, soc: 4768 Wh, pvfc: 351, confc: 700, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 18 -> 1 (SoCfc: 55.9 %, soc: 3912 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 19 -> 1 (SoCfc: 46.0 %, soc: 3221 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 20 -> 1 (SoCfc: 35.7 %, soc: 2499 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 21 -> 1 (SoCfc: 26.3 %, soc: 1843 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 22 -> 1 (SoCfc: 17.7 %, soc: 1237 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 13:57:37 1: SolarForecast DEBUG> Bat 01 relLoad 05 23 -> 1 (SoCfc: 15.0 %, soc: 1050 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
Aber die Ladeempfehlung ist nach Sonnenuntergang - also mit pvfc=0 - noch an. (Das ist doch die 0 oder 1 rechts von dem Pfeil?)
Ist das ratsam? Oder kann das das an meiner Konfiguration liegen?
Was ich noch nicht ganz verstehe, sind die Zusammenhänge zwischen soc, pvfx und confc. Das sind scheinbar nicht einfach nur Summen und Differenzen? Steckt da noch mehr dahinter?
Viele Grüße,
Peter
ZitatAber die Ladeempfehlung ist nach Sonnenuntergang - also mit pvfc=0 - noch an. (Das ist doch die 0 oder 1 rechts von dem Pfeil?)
Ist das ratsam? Oder kann das das an meiner Konfiguration liegen?
Das ist eine Empfehlung / Freigabe die sich an einer optimalen Netzdienlichkeit orientiert. Vllt. nochmal den Abschnitt im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Ber%C3%BCcksichtigung_einer_Wirkleistungsbegrenzung) lesen.
Auch wenn kein PV Überschuß vorhanden ist, kann man die Bat laden wenn man das möchte oder vllt. sogar muß (wegen Unterschreitung des Low-SoC).
Das Batteriesystem wird es aber von sich aus nicht tun auch wenn man es freigibt.
ZitatWas ich noch nicht ganz verstehe, sind die Zusammenhänge zwischen soc, pvfx und confc. Das sind scheinbar nicht einfach nur Summen und Differenzen? Steckt da noch mehr dahinter?
Stimmt, da steckt mehr drin. Da es um Prognosen geht, gehen die voraussichtlichen Erzeugungen, Verbräuche, voraussichtlichen Auswirkungen der SoC-Steuerung und ein virtuellse Aufteilungsverhältnis bei mehreren Batteriesystemen mit ihrem gesamten zu erwartenden Wechselwirkungen in die Betrachtung ein.
Wer es sich antun will, kann sich im Code die Sub _batChargeRecmd anschauen. Dort wird das gemacht wovon wir gerade reden.
Hallo Heiko,
heute ist von mir kein "breiter Balken" mehr gesichtet worden.
Das sollte es dann ja wohl endlich gewesen sein. -> 🤗
Gruß
300P
Ich hatte gestern 03.03. eine Menge Einträge im Log, 1 Stunde lang von 00:00-01:00.
PV_Forecast - WARNING - The BatOut Energy of Battery 'e3dc_s10Pro' is lower than the value saved before. This situation is unexpected and the Energy generated of current hour of this Battery is set to '0'.
Wenn ich mich richtig erinnere, wurde diese Meldung ergänzt, um ein Zurückstellen auf Null wie auch beim Verbrauch/Produktion im Log für den Akku zu protokollieren.
Die Meldungen kommen aber auch bei Verbose=2.
Oder hat es mit dem Update von FHEM zu tun und damit dem Update des Moduls?
Schöne Grüße
Dirk
ZitatWenn ich mich richtig erinnere, wurde diese Meldung ergänzt, um ein Zurückstellen auf Null wie auch beim Verbrauch/Produktion im Log für den Akku zu protokollieren.
Die Meldungen kommen aber auch bei Verbose=2.
Ja, richtig. Seit V 1.46.3.
Ich stelle den verbose gern auf 3.
Hallo Heiko,
die Anpassungen zur Batterieprognose sehen für mich gut aus. Danke nochmal für die Hilfe und die Erklärungen!
Allerdings habe ich jetzt einige Zahlenwerte mit dem Suffix ,,.0" in den Balkengrafiken. Siehe Screenshot anbei. Diese kommen mir neu vor - und eigentlich unnötig bei der Einheit Wh. Hat das evtl. etwas mit Deinen Änderungen für 300P zu tun?
Ich kann aber auch nochmal das Modul aus dem Update holen und vergleich, wenn ich soll?
Viele Grüße,
Peter
ZitatHat das evtl. etwas mit Deinen Änderungen für 300P zu tun?
Ja, das ist die Begrenzung der Nachkommsstellen. Irgendeinen Tod muß man wohl sterben.
@Peter, 300P,
ich konnte auch das Problem lösen denke ich.
Könnt ihr nochmal bitte aus dem contrib ziehen und testen?
LG
Hallo Heiko,
Sorry. Ich muss doch nochmal zur Prognose des SoC zurück:
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 04 18 -> 1 (currsoc: 79 %, SoCfc: 66.8 %, soc: 4674 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh, Curr PV: 0 W, Curr Consumption: 689 W, Limit: 10000 W)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 04 19 -> 1 (SoCfc: 56.9 %, soc: 3983 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 04 20 -> 1 (SoCfc: 46.6 %, soc: 3261 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 04 21 -> 1 (SoCfc: 37.2 %, soc: 2605 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 04 22 -> 1 (SoCfc: 28.6 %, soc: 1999 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 04 23 -> 1 (SoCfc: 20.2 %, soc: 1416 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 00 -> 1 (SoCfc: 12.6 %, soc: 884 Wh, pvfc: 0, confc: 479, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 01 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 508, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 02 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 03 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 497, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 04 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 466, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 05 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 463, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 06 -> 1 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 0, confc: 648, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 07 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 356, confc: 649, Surp Day: 26490 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 08 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 1186, confc: 938, Surp Day: 25304 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 09 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 2670, confc: 815, Surp Day: 22634 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 10 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 4287, confc: 1001, Surp Day: 18347 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 11 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 1848, confc: 819, Surp Day: 16499 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 12 -> 0 (SoCfc: 5.0 %, soc: 350 Wh, pvfc: 3919, confc: 1481, Surp Day: 12580 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 13 -> 1 (SoCfc: 34.9 %, soc: 2445 Wh, pvfc: 4602, confc: 2274, Surp Day: 7978 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 14 -> 1 (SoCfc: 71.0 %, soc: 4968 Wh, pvfc: 4045, confc: 1242, Surp Day: 3933 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 15 -> 1 (SoCfc: 97.6 %, soc: 6834 Wh, pvfc: 2966, confc: 893, Surp Day: 967 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 16 -> 0 (SoCfc: 97.6 %, soc: 6834 Wh, pvfc: 727, confc: 661, Surp Day: 240 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 17 -> 1 (SoCfc: 89.0 %, soc: 6230 Wh, pvfc: 240, confc: 784, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 18 -> 1 (SoCfc: 76.8 %, soc: 5374 Wh, pvfc: 0, confc: 770, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 19 -> 1 (SoCfc: 66.9 %, soc: 4683 Wh, pvfc: 0, confc: 622, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 20 -> 1 (SoCfc: 56.6 %, soc: 3961 Wh, pvfc: 0, confc: 650, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 21 -> 1 (SoCfc: 47.2 %, soc: 3305 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 22 -> 1 (SoCfc: 38.6 %, soc: 2699 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 18:40:26 1: SolarForecast DEBUG> Bat 01 relLoad 05 23 -> 1 (SoCfc: 30.2 %, soc: 2116 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
Da geht der SoC morgen erst ab 13 Uhr nach oben, obwohl vorher schon PV-Überschuss da ist?
Gruß,
Peter
Ja weil von 07 - 12 zunächst keine Ladeempfehlung relLoad ... -> 0 vorhanden ist.
Zitat von: DS_Starter am 04 März 2025, 19:10:07Ja weil von 07 - 12 zunächst keine Ladeempfehlung relLoad ... -> 0 vorhanden ist.
Und warum? Ich will ja keine Ladeempfehlung haben, weil ich sie mangels Steuermöglichkeiten nicht befolgen kann.
Ich hatte gehofft, lediglich eine Prognose des SoC zu erhalten, ohne etwas zu steuern.
Kann ich das irgendwie so konfigurieren?
Gruß,
Peter
ZitatIch hatte gehofft, lediglich eine Prognose des SoC zu erhalten, ohne etwas zu steuern.
Kann ich das irgendwie so konfigurieren?
Ja, das Batteriemanagement nicht einschalten, d.h. ctrlBatSocManagementXX löschen bzw. nicht setzen.
Zitat von: DS_Starter am 04 März 2025, 19:02:18@Peter, 300P,
ich konnte auch das Problem lösen denke ich.
Könnt ihr nochmal bitte aus dem contrib ziehen und testen?
LG
OK von meiner Seite
Gruß
300P
Zitat von: DS_Starter am 04 März 2025, 19:40:49Ja, das Batteriemanagement nicht einschalten, d.h. ctrlBatSocManagementXX löschen bzw. nicht setzen.
Ach, so einfach... :-[
Das hatte ich gesetzt, weil meine Batterie einen MinSoC von 5 haben sollte. Dann werde ich mit dieser kleinen Unschärfe leben können.
Sorry, das Modul aus deinem contrib kann ich gerade nicht testen. Die Screenshots von 300P sehen für mich aber gut aus.
Nochmal danke! Und sorry wegen der Verwirrung, die ich gestiftet habe!
Viele Grüße,
Peter
Kein Problem ;)
Ich habe dass attr ctrlBatSocManagementXX jetzt gelöscht und fhem neu gestartet.
Sollte sich dadurch schon etwas an der Prognose geändert haben oder muss ich noch etwas zurücksetzen? Oder soll ich einfach mal auf morgen warten?
Viele Grüße,
Peter
Edit: Hier noch die Debug-Ausgabe mit der V aus dem contrib:
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat XX Charge Rcmd - Inverter 'Enphase' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 10000 W
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 7000 Wh, Percentage of total capacity: 100.0 %
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 04 21 -> 1 (currsoc: 51 %, SoCfc: 41.6 %, soc: 2914 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh, Curr PV: 0 W, Curr Consumption: 825 W, Limit: 10000 W)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 04 22 -> 1 (SoCfc: 33.0 %, soc: 2308 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 04 23 -> 1 (SoCfc: 24.6 %, soc: 1725 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 00 -> 1 (SoCfc: 17.0 %, soc: 1193 Wh, pvfc: 0, confc: 479, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 01 -> 1 (SoCfc: 9.0 %, soc: 629 Wh, pvfc: 0, confc: 508, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 02 -> 1 (SoCfc: 0.0 %, soc: 3 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 03 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 497, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 04 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 466, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 05 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 463, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 06 -> 0 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 14, confc: 648, Surp Day: 26319 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 07 -> 0 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 356, confc: 649, Surp Day: 25963 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 08 -> 0 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 1132, confc: 938, Surp Day: 24831 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 09 -> 0 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 2670, confc: 815, Surp Day: 22161 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 10 -> 0 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 4287, confc: 1001, Surp Day: 17874 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 11 -> 0 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 1808, confc: 819, Surp Day: 16066 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 12 -> 0 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 3866, confc: 1481, Surp Day: 12200 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 13 -> 1 (SoCfc: 28.7 %, soc: 2008 Wh, pvfc: 4505, confc: 2274, Surp Day: 7695 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 14 -> 1 (SoCfc: 63.5 %, soc: 4445 Wh, pvfc: 3950, confc: 1242, Surp Day: 3745 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 15 -> 1 (SoCfc: 87.9 %, soc: 6150 Wh, pvfc: 2787, confc: 893, Surp Day: 958 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 16 -> 1 (SoCfc: 88.3 %, soc: 6183 Wh, pvfc: 698, confc: 661, Surp Day: 260 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 17 -> 1 (SoCfc: 80.0 %, soc: 5601 Wh, pvfc: 260, confc: 784, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 18 -> 1 (SoCfc: 67.8 %, soc: 4747 Wh, pvfc: 0, confc: 769, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 19 -> 1 (SoCfc: 57.8 %, soc: 4045 Wh, pvfc: 0, confc: 632, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 20 -> 1 (SoCfc: 47.3 %, soc: 3313 Wh, pvfc: 0, confc: 659, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 21 -> 1 (SoCfc: 38.0 %, soc: 2657 Wh, pvfc: 0, confc: 590, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 22 -> 1 (SoCfc: 29.3 %, soc: 2051 Wh, pvfc: 0, confc: 545, Surp Day: 0 Wh)
2025.03.04 21:20:24 1: SolarForecast DEBUG> Bat 01 relLoad 05 23 -> 1 (SoCfc: 21.0 %, soc: 1468 Wh, pvfc: 0, confc: 525, Surp Day: 0 Wh)
Und zur Kontrolle das List des SolarForecast:
define SolarForecast SolarForecast
attr SolarForecast DbLogExclude .*
attr SolarForecast DbLogInclude Current_AutarkyRate:60,AllPVforecastsToEvent,LastHourPVforecast,LastHourPVreal
attr SolarForecast affectConsForecastIdentWeekdays 1
attr SolarForecast affectConsForecastInPlanning 0
attr SolarForecast consumer01 KlimaanlagePwr switchdev=Klimaanlage_Sw type=noSchedule power=750 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=Ventilator_fett auto=Automatik interruptable=1
attr SolarForecast consumer02 MQTT2_Luftentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=light_ceiling auto=Automatik
attr SolarForecast consumer03 MQTT2_Spelunkenentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=Ventilator_fett auto=Automatik
attr SolarForecast consumer04 MQTT2_ShellyGeschirrspueler type=noSchedule power=1500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=scene_dishwasher auto=Automatik
attr SolarForecast consumer05 Trockner_Pwr switchdev=Trockner type=noSchedule power=450 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=scene_clothes_dryer auto=Automatik
attr SolarForecast consumer06 Waschmaschine_Pwr switchdev=Waschmaschine type=noSchedule power=1800 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=scene_washing_machine auto=Automatik
attr SolarForecast consumer07 Stromverbrauch_Buero type=noSchedule power=500 pcurr=pcurr:W etotal=etotal:Wh icon=scene_office auto=Automatik
attr SolarForecast consumer08 Stromverbrauch_WoZi type=noSchedule power=500 pcurr=pcurr:W etotal=etotal:Wh icon=scene_livingroom auto=Automatik
attr SolarForecast consumer09 MQTT2_KlimaODU type=noSchedule power=1500 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=frost auto=Automatik
attr SolarForecast consumer10 MQTT2_ShellyPlugKuechenKuehlschrank type=noSchedule power=100 pcurr=switch_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_big auto=Automatik
attr SolarForecast consumer11 MQTT2_PlugKaffeemaschine type=noSchedule power=2500 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=scene_cockle_stove auto=Automatik
attr SolarForecast consumer12 MQTT2_ShellyPlugKellerKuehlschrank type=noSchedule power=150 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_small auto=Automatik
attr SolarForecast consumer13 ShellyplugSchuppen type=noSchedule power=100 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=building_carport_socket auto=Automatik
attr SolarForecast consumer14 HM_56DBA8_Sw_01 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian
attr SolarForecast consumer15 WallboxLeistungssumme type=other power=11000 pcurr=power:W etotal=total:Wh on=on off=off auto=Automatik mintime=60 icon=wallbox exconfc=1
attr SolarForecast consumer16 HM_35FA43_Sw_07 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian
attr SolarForecast consumerLegend icon_bottom
attr SolarForecast ctrlDebug batteryManagement
attr SolarForecast ctrlGenPVdeviation continuously
attr SolarForecast ctrlInterval 5
attr SolarForecast ctrlLanguage DE
attr SolarForecast ctrlSpecialReadings todayBatInSum,todayBatOutSum,todayConsumption,todayGridConsumption,todayGridFeedIn
attr SolarForecast event-aggregator Current_AutarkyRate:150:linear:mean
attr SolarForecast event-min-interval .*:300
attr SolarForecast event-on-change-reading .*
attr SolarForecast flowGraphicControl animate=1 consumerdist=110 showconsumerremaintime=0 h2consumerdist=50
attr SolarForecast graphicBeam1Content pvReal
attr SolarForecast graphicBeam2Content pvForecast
attr SolarForecast graphicBeam3Content consumptionForecast
attr SolarForecast graphicBeam4Content consumption
attr SolarForecast graphicBeamHeightLevel1 250
attr SolarForecast graphicBeamHeightLevel2 250
attr SolarForecast graphicHeaderDetail all
attr SolarForecast graphicHeaderOwnspec #Aktuell:\
Überschuss:Current_Surplus\
Einspeisung:Current_GridFeedIn\
Netzbezug:Current_GridConsumption\
Autarkie-Rate:Current_AutarkyRate\
#Heute:\
Erzeugt:Today_PVreal\
Bezogen:special_todayGridConsumption\
Eingespeist:special_todayGridFeedIn\
Verbraucht:special_todayConsumption\
#Batterie:\
Status:Akkustatus@Enphase\
SoC ;(%):StorageFullPercent@Enphase\
Heute ;geladen:special_todayBatInSum\
Heute ;entladen:special_todayBatOutSum
attr SolarForecast graphicHistoryHour 4
attr SolarForecast graphicHourStyle :00
attr SolarForecast graphicSelect both
attr SolarForecast graphicShowDiff bottom
attr SolarForecast graphicShowNight 1
attr SolarForecast room Garten->PV-Anlage
attr SolarForecast setupBatteryDev01 Enphase pin=StorageFeedIn:W pout=StorageConsumption:W intotal=StorageWhCharged:Wh outtotal=StorageWhDischarged:Wh charge=StorageFullPercent cap=7000 show=1 asynchron=1
attr SolarForecast setupInverterDev01 Enphase pv=wNowProduction:W etotal=whTodayProduction:Wh capacity=10000 asynchron=1
attr SolarForecast setupInverterStrings Osten,Westen
attr SolarForecast setupMeterDev MQTT2_SmartMeterReader gcon=Bezug:W contotal=ENERGY_Total:kWh gfeedin=Einspeisung:W feedtotal=ENERGY_Supply:kWh asynchron=1
attr SolarForecast setupRadiationAPI dwd
attr SolarForecast setupStringPeak Osten=4 Westen=6.4
attr SolarForecast setupWeatherDev1 dwd
attr SolarForecast userReadings Current_Surplus_Num {my $val = ReadingsVal("SolarForecast", "Current_Surplus", "0 W");; return substr($val, 0, index($val, " "));;}
# FUUID 651cfe6b-f33f-e199-c4fb-916e33f2d14b5241
# FVERSION 76_SolarForecast.pm:v1.47.0-s29721/2025-03-04
# LCACHEFILE last write time: 21:18:39 File: ./FHEM/FhemUtils/PVCsm_SolarForecast_SolarForecast
# MODE Automatic / Event-controlled - next planned Cycletime: 21:22:19
# MODEL DWD
# NAME SolarForecast
# NOTIFYDEV MQTT2_SmartMeterReader,KlimaanlagePwr,Klimaanlage_Sw,MQTT2_Luftentfeuchter,MQTT2_Spelunkenentfeuchter,MQTT2_ShellyGeschirrspueler,Trockner_Pwr,Trockner,Waschmaschine_Pwr,Waschmaschine,Stromverbrauch_Buero,Stromverbrauch_WoZi,MQTT2_KlimaODU,MQTT2_ShellyPlugKuechenKuehlschrank,MQTT2_PlugKaffeemaschine,MQTT2_ShellyPlugKellerKuehlschrank,ShellyplugSchuppen,HM_56DBA8_Sw_01,WallboxLeistungssumme,HM_35FA43_Sw_07,Enphase
# NR 776
# NTFY_ORDER 50-SolarForecast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 82
# HELPER:
# 14M15DONE 1
# 15M15DONE 1
# 16M15DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV SolarForecast
# SPGROOM
# VERSION 1.47.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# Helper:
# DBLOG:
# Current_AutarkyRate:
# logdb:
# TIME 1741119679.22417
# VALUE 96.777618128916
# LastHourPVforecast:
# logdb:
# TIME 1741119519.76399
# VALUE 0
# LastHourPVreal:
# logdb:
# TIME 1741119519.76399
# VALUE 0
# OLDREADINGS:
# READINGS:
# 2025-03-04 21:22:14 Battery_ChargeRecommended_01 1
# 2025-03-04 21:22:14 Current_AutarkyRate 92 %
# 2025-03-04 21:22:14 Current_BatCharge_01 51 %
# 2025-03-04 21:22:14 Current_Consumption 865 W
# 2025-03-04 21:22:14 Current_GridConsumption 67 W
# 2025-03-04 21:22:14 Current_GridFeedIn 0 W
# 2025-03-04 21:22:14 Current_PV 0 W
# 2025-03-04 21:22:14 Current_PowerBatIn_01 0 W
# 2025-03-04 21:22:14 Current_PowerBatOut_01 798 W
# 2025-03-04 21:22:14 Current_SelfConsumption 0 W
# 2025-03-04 21:22:14 Current_SelfConsumptionRate 0 %
# 2025-03-04 21:22:14 Current_Surplus 0 W
# 2025-03-04 21:22:15 Current_Surplus_Num 0
# 2025-03-04 21:00:00 LastHourGridconsumptionReal 45 Wh
# 2025-03-04 21:00:00 LastHourPVforecast 0 Wh
# 2025-03-04 21:00:00 LastHourPVreal 0 Wh
# 2025-03-04 21:22:14 NextHours_Sum01_PVforecast 0 Wh
# 2025-03-04 21:22:14 NextHours_Sum02_PVforecast 0 Wh
# 2025-03-04 21:22:14 NextHours_Sum03_PVforecast 0 Wh
# 2025-03-04 21:22:14 NextHours_Sum04_ConsumptionForecast 2107 Wh
# 2025-03-04 21:22:14 NextHours_Sum04_PVforecast 0 Wh
# 2025-03-04 21:22:14 RestOfDayConsumptionForecast 1433 Wh
# 2025-03-04 21:22:14 RestOfDayPVforecast 0 Wh
# 2025-03-04 00:59:59 Today_Hour01_BatIn_01 0 Wh
# 2025-03-04 00:59:59 Today_Hour01_BatOut_01 421 Wh
# 2025-03-04 00:59:59 Today_Hour01_GridConsumption 61 Wh
# 2025-03-04 00:59:59 Today_Hour01_GridFeedIn 0 Wh
# 2025-03-04 00:59:59 Today_Hour01_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
# 2025-03-04 01:59:54 Today_Hour02_BatIn_01 0 Wh
# 2025-03-04 01:59:54 Today_Hour02_BatOut_01 461 Wh
# 2025-03-04 01:59:54 Today_Hour02_GridConsumption 45 Wh
# 2025-03-04 01:59:54 Today_Hour02_GridFeedIn 0 Wh
# 2025-03-04 01:59:54 Today_Hour02_PVreal 0 Wh
# 2025-03-04 02:59:58 Today_Hour03_BatIn_01 0 Wh
# 2025-03-04 02:59:58 Today_Hour03_BatOut_01 517 Wh
# 2025-03-04 02:59:58 Today_Hour03_GridConsumption 47 Wh
# 2025-03-04 02:59:58 Today_Hour03_GridFeedIn 1 Wh
# 2025-03-04 02:59:58 Today_Hour03_PVreal 0 Wh
# 2025-03-04 03:59:57 Today_Hour04_BatIn_01 0 Wh
# 2025-03-04 03:59:57 Today_Hour04_BatOut_01 544 Wh
# 2025-03-04 03:59:57 Today_Hour04_GridConsumption 50 Wh
# 2025-03-04 03:59:57 Today_Hour04_GridFeedIn 1 Wh
# 2025-03-04 03:59:57 Today_Hour04_PVreal 0 Wh
# 2025-03-04 04:59:58 Today_Hour05_BatIn_01 0 Wh
# 2025-03-04 04:59:58 Today_Hour05_BatOut_01 340 Wh
# 2025-03-04 04:59:58 Today_Hour05_GridConsumption 144 Wh
# 2025-03-04 04:59:58 Today_Hour05_GridFeedIn 0 Wh
# 2025-03-04 04:59:58 Today_Hour05_PVreal 0 Wh
# 2025-03-04 05:59:58 Today_Hour06_BatIn_01 0 Wh
# 2025-03-04 05:59:58 Today_Hour06_BatOut_01 0 Wh
# 2025-03-04 05:59:58 Today_Hour06_GridConsumption 437 Wh
# 2025-03-04 05:59:58 Today_Hour06_GridFeedIn 0 Wh
# 2025-03-04 05:59:58 Today_Hour06_PVreal 0 Wh
# 2025-03-04 06:59:58 Today_Hour07_BatIn_01 0 Wh
# 2025-03-04 06:59:58 Today_Hour07_BatOut_01 0 Wh
# 2025-03-04 06:59:58 Today_Hour07_GridConsumption 550 Wh
# 2025-03-04 06:59:58 Today_Hour07_GridFeedIn 0 Wh
# 2025-03-04 06:59:58 Today_Hour07_PVforecast 12 Wh
# 2025-03-04 06:59:58 Today_Hour07_PVreal 0 Wh
# 2025-03-04 07:59:58 Today_Hour08_BatIn_01 60 Wh
# 2025-03-04 07:59:58 Today_Hour08_BatOut_01 0 Wh
# 2025-03-04 07:59:58 Today_Hour08_GridConsumption 235 Wh
# 2025-03-04 07:59:58 Today_Hour08_GridFeedIn 0 Wh
# 2025-03-04 07:59:58 Today_Hour08_PVforecast 143 Wh
# 2025-03-04 07:59:58 Today_Hour08_PVreal 479 Wh
# 2025-03-04 08:59:58 Today_Hour09_BatIn_01 471 Wh
# 2025-03-04 08:59:58 Today_Hour09_BatOut_01 85 Wh
# 2025-03-04 08:59:58 Today_Hour09_GridConsumption 50 Wh
# 2025-03-04 08:59:58 Today_Hour09_GridFeedIn 20 Wh
# 2025-03-04 08:59:58 Today_Hour09_PVforecast 646 Wh
# 2025-03-04 08:59:58 Today_Hour09_PVreal 1299 Wh
# 2025-03-04 09:59:59 Today_Hour10_BatIn_01 827 Wh
# 2025-03-04 09:59:59 Today_Hour10_BatOut_01 220 Wh
# 2025-03-04 09:59:59 Today_Hour10_GridConsumption 44 Wh
# 2025-03-04 09:59:59 Today_Hour10_GridFeedIn 19 Wh
# 2025-03-04 09:59:59 Today_Hour10_PVforecast 2716 Wh
# 2025-03-04 09:59:59 Today_Hour10_PVreal 2070 Wh
# 2025-03-04 10:59:59 Today_Hour11_BatIn_01 2207 Wh
# 2025-03-04 10:59:59 Today_Hour11_BatOut_01 0 Wh
# 2025-03-04 10:59:59 Today_Hour11_GridConsumption 35 Wh
# 2025-03-04 10:59:59 Today_Hour11_GridFeedIn 96 Wh
# 2025-03-04 10:59:59 Today_Hour11_PVforecast 2533 Wh
# 2025-03-04 10:59:59 Today_Hour11_PVreal 3166 Wh
# 2025-03-04 11:59:55 Today_Hour12_BatIn_01 2019 Wh
# 2025-03-04 11:59:55 Today_Hour12_BatOut_01 0 Wh
# 2025-03-04 11:59:55 Today_Hour12_GridConsumption 25 Wh
# 2025-03-04 11:59:55 Today_Hour12_GridFeedIn 386 Wh
# 2025-03-04 11:59:55 Today_Hour12_PVforecast 4066 Wh
# 2025-03-04 11:59:55 Today_Hour12_PVreal 4012 Wh
# 2025-03-04 12:59:55 Today_Hour13_BatIn_01 1579 Wh
# 2025-03-04 12:59:55 Today_Hour13_BatOut_01 0 Wh
# 2025-03-04 12:59:55 Today_Hour13_GridConsumption 36 Wh
# 2025-03-04 12:59:55 Today_Hour13_GridFeedIn 722 Wh
# 2025-03-04 12:59:55 Today_Hour13_PVforecast 5818 Wh
# 2025-03-04 12:59:55 Today_Hour13_PVreal 4452 Wh
# 2025-03-04 13:59:57 Today_Hour14_BatIn_01 284 Wh
# 2025-03-04 13:59:57 Today_Hour14_BatOut_01 6 Wh
# 2025-03-04 13:59:57 Today_Hour14_GridConsumption 27 Wh
# 2025-03-04 13:59:57 Today_Hour14_GridFeedIn 616 Wh
# 2025-03-04 13:59:57 Today_Hour14_PVforecast 4543 Wh
# 2025-03-04 13:59:57 Today_Hour14_PVreal 4394 Wh
# 2025-03-04 14:59:58 Today_Hour15_BatIn_01 208 Wh
# 2025-03-04 14:59:58 Today_Hour15_BatOut_01 274 Wh
# 2025-03-04 14:59:58 Today_Hour15_GridConsumption 63 Wh
# 2025-03-04 14:59:58 Today_Hour15_GridFeedIn 499 Wh
# 2025-03-04 14:59:58 Today_Hour15_PVforecast 3604 Wh
# 2025-03-04 14:59:58 Today_Hour15_PVreal 3630 Wh
# 2025-03-04 15:59:59 Today_Hour16_BatIn_01 406 Wh
# 2025-03-04 15:59:59 Today_Hour16_BatOut_01 274 Wh
# 2025-03-04 15:59:59 Today_Hour16_GridConsumption 28 Wh
# 2025-03-04 15:59:59 Today_Hour16_GridFeedIn 608 Wh
# 2025-03-04 15:59:59 Today_Hour16_PVforecast 3852 Wh
# 2025-03-04 15:59:59 Today_Hour16_PVreal 2005 Wh
# 2025-03-04 16:59:58 Today_Hour17_BatIn_01 28 Wh
# 2025-03-04 16:59:58 Today_Hour17_BatOut_01 9 Wh
# 2025-03-04 16:59:58 Today_Hour17_GridConsumption 16 Wh
# 2025-03-04 16:59:58 Today_Hour17_GridFeedIn 430 Wh
# 2025-03-04 16:59:58 Today_Hour17_PVforecast 1345 Wh
# 2025-03-04 16:59:58 Today_Hour17_PVreal 1115 Wh
# 2025-03-04 17:59:59 Today_Hour18_BatIn_01 3 Wh
# 2025-03-04 17:59:59 Today_Hour18_BatOut_01 1036 Wh
# 2025-03-04 17:59:59 Today_Hour18_GridConsumption 75 Wh
# 2025-03-04 17:59:59 Today_Hour18_GridFeedIn 3 Wh
# 2025-03-04 17:59:59 Today_Hour18_PVforecast 286 Wh
# 2025-03-04 17:59:59 Today_Hour18_PVreal 212 Wh
# 2025-03-04 18:59:59 Today_Hour19_BatIn_01 0 Wh
# 2025-03-04 18:59:59 Today_Hour19_BatOut_01 732 Wh
# 2025-03-04 18:59:59 Today_Hour19_GridConsumption 39 Wh
# 2025-03-04 18:59:59 Today_Hour19_GridFeedIn 0 Wh
# 2025-03-04 18:59:59 Today_Hour19_PVreal 0 Wh
# 2025-03-04 19:59:56 Today_Hour20_BatIn_01 0 Wh
# 2025-03-04 19:59:56 Today_Hour20_BatOut_01 689 Wh
# 2025-03-04 19:59:56 Today_Hour20_GridConsumption 43 Wh
# 2025-03-04 19:59:56 Today_Hour20_GridFeedIn 0 Wh
# 2025-03-04 19:59:56 Today_Hour20_PVreal 0 Wh
# 2025-03-04 20:59:58 Today_Hour21_BatIn_01 0 Wh
# 2025-03-04 20:59:58 Today_Hour21_BatOut_01 808 Wh
# 2025-03-04 20:59:58 Today_Hour21_GridConsumption 45 Wh
# 2025-03-04 20:59:58 Today_Hour21_GridFeedIn 1 Wh
# 2025-03-04 20:59:58 Today_Hour21_PVreal 0 Wh
# 2025-03-04 21:22:14 Today_Hour22_BatIn_01 0 Wh
# 2025-03-04 21:22:14 Today_Hour22_BatOut_01 324 Wh
# 2025-03-04 21:22:14 Today_Hour22_GridConsumption 17 Wh
# 2025-03-04 21:22:14 Today_Hour22_GridFeedIn 0 Wh
# 2025-03-04 21:22:14 Today_Hour22_PVreal 0 Wh
# 2025-03-04 21:22:14 Today_MaxPVforecast 5818 Wh
# 2025-03-04 21:22:14 Today_MaxPVforecastTime 2025-03-04 12:00:00
# 2025-03-04 21:22:14 Today_PVdeviation 9.23 %
# 2025-03-04 21:22:14 Today_PVforecast 29564 Wh
# 2025-03-04 21:22:14 Today_PVreal 26834 Wh
# 2025-03-04 21:22:14 Today_SunRise 06:54
# 2025-03-04 21:22:14 Today_SunSet 17:54
# 2025-03-04 21:22:14 Tomorrow_ConsumptionForecast -147120 Wh
# 2025-03-04 21:22:14 Tomorrow_PVforecast 26333 Wh
# 2025-03-04 21:22:14 Tomorrow_SunRise 06:52
# 2025-03-04 21:22:14 Tomorrow_SunSet 17:56
# 2025-03-04 21:22:14 consumer01 name='Klimaanlage' state='unknown' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer01_currentPower 0 W
# 2025-03-04 21:22:14 consumer02 name='Tageslichtlampe' state='off' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-03-04 21:22:14 consumer02_currentPower 0 W
# 2025-03-04 21:22:14 consumer03 name='Spelunkenentfeuchter' state='off' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer03_currentPower 0 W
# 2025-03-04 21:22:14 consumer04 name='Geschirrspüler' state='on' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer04_currentPower 0 W
# 2025-03-04 21:22:14 consumer05 name='Wäschetrockner' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-03-04 21:22:14 consumer05_currentPower 0.02 W
# 2025-03-04 21:22:14 consumer06 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-03-04 21:22:14 consumer06_currentPower 0.18 W
# 2025-03-04 21:22:14 consumer07 name='Büro' state='unknown' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer07_currentPower 179.2 W
# 2025-03-04 21:22:14 consumer08 name='Wohnzimmer' state='unknown' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer08_currentPower 155.7 W
# 2025-03-04 21:22:14 consumer09 name='Klimaaußengerät' state='off' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer09_currentPower 0 W
# 2025-03-04 21:22:14 consumer10 name='Küchen-Kühlschrank' state='on' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer10_currentPower 0 W
# 2025-03-04 21:22:14 consumer11 name='Kaffeemaschine, Toaster, Thermomix' state='on' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer11_currentPower 4.1 W
# 2025-03-04 21:22:14 consumer12 name='Kellerkühlschrank' state='on' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer12_currentPower 117.9 W
# 2025-03-04 21:22:14 consumer13 name='PlugSchuppen' state='off' mode='can' planningstate='noSchedule'
# 2025-03-04 21:22:14 consumer13_currentPower 0 W
# 2025-03-04 21:22:14 consumer14 name='Teichbelüfter' state='off' mode='can' planningstate='planned'
# 2025-03-04 21:22:14 consumer14_planned_start 05.03.2025 07:00:00
# 2025-03-04 21:22:14 consumer14_planned_stop 05.03.2025 08:00:00
# 2025-03-04 21:22:14 consumer15 name='WallboxLeistungssumme' state='on' mode='can' planningstate='suspended' info='max Überschußprognose zu gering'
# 2025-03-04 21:22:14 consumer15_currentPower 3.179 W
# 2025-03-04 21:22:14 consumer16 name='Skimmer' state='off' mode='can' planningstate='planned'
# 2025-03-04 21:22:14 consumer16_planned_start 05.03.2025 07:00:00
# 2025-03-04 21:22:14 consumer16_planned_stop 05.03.2025 08:00:00
# 2025-03-04 21:22:14 nextCycletime 21:22:19
# 2025-03-04 08:00:01 pvCorrectionFactor_08 1.65 (automatic - old factor: 0.90, Sun Alt range: 5, Cloud range: 70, Days in range: 2)
# 2025-03-04 09:00:01 pvCorrectionFactor_09 1.76 (automatic - old factor: 1.33, Sun Alt range: 15, Cloud range: 70, Days in range: 2)
# 2025-03-04 10:00:06 pvCorrectionFactor_10 0.95 (automatic - old factor: 1.30, Sun Alt range: 20, Cloud range: 65, Days in range: 2)
# 2025-03-04 11:00:07 pvCorrectionFactor_11 1.01 (automatic - old factor: 1.09, AI result used, Sun Alt range: 25, Cloud range: 60, Days in range: 2)
# 2025-03-04 12:00:01 pvCorrectionFactor_12 0.93 (automatic - old factor: 0.94, Sun Alt range: 30, Cloud range: 55, Days in range: 2)
# 2025-03-04 13:00:00 pvCorrectionFactor_13 0.92 (automatic - old factor: 1.20, Sun Alt range: 30, Cloud range: 50, Days in range: 2)
# 2025-03-04 14:00:06 pvCorrectionFactor_14 1.06 (automatic - old factor: 1.20, Sun Alt range: 30, Cloud range: 50, Days in range: 2)
# 2025-03-04 15:00:02 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 45, Days in range: 1)
# 2025-03-04 16:00:04 pvCorrectionFactor_16 1.02 (automatic - old factor: 1.48, Sun Alt range: 20, Cloud range: 40, Days in range: 2)
# 2025-03-04 17:00:05 pvCorrectionFactor_17 0.83 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 40, Days in range: 1)
# 2025-03-04 18:00:05 pvCorrectionFactor_18 0.74 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 40, Days in range: 1)
# 2025-03-04 21:22:14 pvCorrectionFactor_Auto on_complex_ai
# 2024-08-24 17:13:20 setupStringAzimuth Osten=-127 Westen=53
# 2025-02-19 10:56:15 setupStringDeclination Osten=38 Westen=38
# 2025-03-04 21:22:14 special_todayBatInSum 8092.0 Wh
# 2025-03-04 21:22:14 special_todayBatOutSum 6740.0 Wh
# 2025-03-04 21:22:14 special_todayConsumption 24281 Wh
# 2025-03-04 21:22:14 special_todayGridConsumption 2112 Wh
# 2025-03-04 21:22:14 special_todayGridFeedIn 3402.5 Wh
# 2025-03-04 21:22:15 state updated
# hmccu:
#
setstate SolarForecast updated
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_ctrlDebug
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicHistoryHour 4
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicShowNight 1
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicShowWeather
setstate SolarForecast 2025-03-04 21:18:38 .associatedWith MQTT2_SmartMeterReader KlimaanlagePwr Klimaanlage_Sw MQTT2_Luftentfeuchter MQTT2_Spelunkenentfeuchter MQTT2_ShellyGeschirrspueler Trockner_Pwr Trockner Waschmaschine_Pwr Waschmaschine Stromverbrauch_Buero Stromverbrauch_WoZi MQTT2_KlimaODU MQTT2_ShellyPlugKuechenKuehlschrank MQTT2_PlugKaffeemaschine MQTT2_ShellyPlugKellerKuehlschrank ShellyplugSchuppen HM_56DBA8_Sw_01 WallboxLeistungssumme HM_35FA43_Sw_07 Enphase dwd
setstate SolarForecast 2025-03-04 21:22:14 .lastupdateForecastValues 1741119734
setstate SolarForecast 2025-03-04 21:22:14 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate SolarForecast 2025-03-04 01:00:04 .signaldone_01 done
setstate SolarForecast 2025-03-04 02:00:02 .signaldone_02 done
setstate SolarForecast 2025-03-04 03:00:01 .signaldone_03 done
setstate SolarForecast 2025-03-04 04:00:03 .signaldone_04 done
setstate SolarForecast 2025-03-04 05:00:03 .signaldone_05 done
setstate SolarForecast 2025-03-04 06:00:03 .signaldone_06 done
setstate SolarForecast 2025-03-04 07:00:04 .signaldone_07 done
setstate SolarForecast 2025-03-04 08:00:01 .signaldone_08 done
setstate SolarForecast 2025-03-04 09:00:01 .signaldone_09 done
setstate SolarForecast 2025-03-04 10:00:06 .signaldone_10 done
setstate SolarForecast 2025-03-04 11:00:07 .signaldone_11 done
setstate SolarForecast 2025-03-04 12:00:01 .signaldone_12 done
setstate SolarForecast 2025-03-04 13:00:00 .signaldone_13 done
setstate SolarForecast 2025-03-04 14:00:06 .signaldone_14 done
setstate SolarForecast 2025-03-04 15:00:02 .signaldone_15 done
setstate SolarForecast 2025-03-04 16:00:04 .signaldone_16 done
setstate SolarForecast 2025-03-04 17:00:05 .signaldone_17 done
setstate SolarForecast 2025-03-04 18:00:05 .signaldone_18 done
setstate SolarForecast 2025-03-04 19:00:05 .signaldone_19 done
setstate SolarForecast 2025-03-04 20:00:00 .signaldone_20 done
setstate SolarForecast 2025-03-04 21:00:03 .signaldone_21 done
setstate SolarForecast 2025-03-04 00:00:05 .signaldone_24 done
setstate SolarForecast 2025-03-04 21:22:14 Battery_ChargeRecommended_01 1
setstate SolarForecast 2025-03-04 21:22:14 Current_AutarkyRate 92 %
setstate SolarForecast 2025-03-04 21:22:14 Current_BatCharge_01 51 %
setstate SolarForecast 2025-03-04 21:22:14 Current_Consumption 865 W
setstate SolarForecast 2025-03-04 21:22:14 Current_GridConsumption 67 W
setstate SolarForecast 2025-03-04 21:22:14 Current_GridFeedIn 0 W
setstate SolarForecast 2025-03-04 21:22:14 Current_PV 0 W
setstate SolarForecast 2025-03-04 21:22:14 Current_PowerBatIn_01 0 W
setstate SolarForecast 2025-03-04 21:22:14 Current_PowerBatOut_01 798 W
setstate SolarForecast 2025-03-04 21:22:14 Current_SelfConsumption 0 W
setstate SolarForecast 2025-03-04 21:22:14 Current_SelfConsumptionRate 0 %
setstate SolarForecast 2025-03-04 21:22:14 Current_Surplus 0 W
setstate SolarForecast 2025-03-04 21:22:15 Current_Surplus_Num 0
setstate SolarForecast 2025-03-04 21:00:00 LastHourGridconsumptionReal 45 Wh
setstate SolarForecast 2025-03-04 21:00:00 LastHourPVforecast 0 Wh
setstate SolarForecast 2025-03-04 21:00:00 LastHourPVreal 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 NextHours_Sum01_PVforecast 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 NextHours_Sum02_PVforecast 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 NextHours_Sum03_PVforecast 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 NextHours_Sum04_ConsumptionForecast 2107 Wh
setstate SolarForecast 2025-03-04 21:22:14 NextHours_Sum04_PVforecast 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 RestOfDayConsumptionForecast 1433 Wh
setstate SolarForecast 2025-03-04 21:22:14 RestOfDayPVforecast 0 Wh
setstate SolarForecast 2025-03-04 00:59:59 Today_Hour01_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 00:59:59 Today_Hour01_BatOut_01 421 Wh
setstate SolarForecast 2025-03-04 00:59:59 Today_Hour01_GridConsumption 61 Wh
setstate SolarForecast 2025-03-04 00:59:59 Today_Hour01_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 00:59:59 Today_Hour01_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
setstate SolarForecast 2025-03-04 01:59:54 Today_Hour02_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 01:59:54 Today_Hour02_BatOut_01 461 Wh
setstate SolarForecast 2025-03-04 01:59:54 Today_Hour02_GridConsumption 45 Wh
setstate SolarForecast 2025-03-04 01:59:54 Today_Hour02_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 01:59:54 Today_Hour02_PVreal 0 Wh
setstate SolarForecast 2025-03-04 02:59:58 Today_Hour03_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 02:59:58 Today_Hour03_BatOut_01 517 Wh
setstate SolarForecast 2025-03-04 02:59:58 Today_Hour03_GridConsumption 47 Wh
setstate SolarForecast 2025-03-04 02:59:58 Today_Hour03_GridFeedIn 1 Wh
setstate SolarForecast 2025-03-04 02:59:58 Today_Hour03_PVreal 0 Wh
setstate SolarForecast 2025-03-04 03:59:57 Today_Hour04_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 03:59:57 Today_Hour04_BatOut_01 544 Wh
setstate SolarForecast 2025-03-04 03:59:57 Today_Hour04_GridConsumption 50 Wh
setstate SolarForecast 2025-03-04 03:59:57 Today_Hour04_GridFeedIn 1 Wh
setstate SolarForecast 2025-03-04 03:59:57 Today_Hour04_PVreal 0 Wh
setstate SolarForecast 2025-03-04 04:59:58 Today_Hour05_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 04:59:58 Today_Hour05_BatOut_01 340 Wh
setstate SolarForecast 2025-03-04 04:59:58 Today_Hour05_GridConsumption 144 Wh
setstate SolarForecast 2025-03-04 04:59:58 Today_Hour05_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 04:59:58 Today_Hour05_PVreal 0 Wh
setstate SolarForecast 2025-03-04 05:59:58 Today_Hour06_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 05:59:58 Today_Hour06_BatOut_01 0 Wh
setstate SolarForecast 2025-03-04 05:59:58 Today_Hour06_GridConsumption 437 Wh
setstate SolarForecast 2025-03-04 05:59:58 Today_Hour06_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 05:59:58 Today_Hour06_PVreal 0 Wh
setstate SolarForecast 2025-03-04 06:59:58 Today_Hour07_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 06:59:58 Today_Hour07_BatOut_01 0 Wh
setstate SolarForecast 2025-03-04 06:59:58 Today_Hour07_GridConsumption 550 Wh
setstate SolarForecast 2025-03-04 06:59:58 Today_Hour07_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 06:59:58 Today_Hour07_PVforecast 12 Wh
setstate SolarForecast 2025-03-04 06:59:58 Today_Hour07_PVreal 0 Wh
setstate SolarForecast 2025-03-04 07:59:58 Today_Hour08_BatIn_01 60 Wh
setstate SolarForecast 2025-03-04 07:59:58 Today_Hour08_BatOut_01 0 Wh
setstate SolarForecast 2025-03-04 07:59:58 Today_Hour08_GridConsumption 235 Wh
setstate SolarForecast 2025-03-04 07:59:58 Today_Hour08_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 07:59:58 Today_Hour08_PVforecast 143 Wh
setstate SolarForecast 2025-03-04 07:59:58 Today_Hour08_PVreal 479 Wh
setstate SolarForecast 2025-03-04 08:59:58 Today_Hour09_BatIn_01 471 Wh
setstate SolarForecast 2025-03-04 08:59:58 Today_Hour09_BatOut_01 85 Wh
setstate SolarForecast 2025-03-04 08:59:58 Today_Hour09_GridConsumption 50 Wh
setstate SolarForecast 2025-03-04 08:59:58 Today_Hour09_GridFeedIn 20 Wh
setstate SolarForecast 2025-03-04 08:59:58 Today_Hour09_PVforecast 646 Wh
setstate SolarForecast 2025-03-04 08:59:58 Today_Hour09_PVreal 1299 Wh
setstate SolarForecast 2025-03-04 09:59:59 Today_Hour10_BatIn_01 827 Wh
setstate SolarForecast 2025-03-04 09:59:59 Today_Hour10_BatOut_01 220 Wh
setstate SolarForecast 2025-03-04 09:59:59 Today_Hour10_GridConsumption 44 Wh
setstate SolarForecast 2025-03-04 09:59:59 Today_Hour10_GridFeedIn 19 Wh
setstate SolarForecast 2025-03-04 09:59:59 Today_Hour10_PVforecast 2716 Wh
setstate SolarForecast 2025-03-04 09:59:59 Today_Hour10_PVreal 2070 Wh
setstate SolarForecast 2025-03-04 10:59:59 Today_Hour11_BatIn_01 2207 Wh
setstate SolarForecast 2025-03-04 10:59:59 Today_Hour11_BatOut_01 0 Wh
setstate SolarForecast 2025-03-04 10:59:59 Today_Hour11_GridConsumption 35 Wh
setstate SolarForecast 2025-03-04 10:59:59 Today_Hour11_GridFeedIn 96 Wh
setstate SolarForecast 2025-03-04 10:59:59 Today_Hour11_PVforecast 2533 Wh
setstate SolarForecast 2025-03-04 10:59:59 Today_Hour11_PVreal 3166 Wh
setstate SolarForecast 2025-03-04 11:59:55 Today_Hour12_BatIn_01 2019 Wh
setstate SolarForecast 2025-03-04 11:59:55 Today_Hour12_BatOut_01 0 Wh
setstate SolarForecast 2025-03-04 11:59:55 Today_Hour12_GridConsumption 25 Wh
setstate SolarForecast 2025-03-04 11:59:55 Today_Hour12_GridFeedIn 386 Wh
setstate SolarForecast 2025-03-04 11:59:55 Today_Hour12_PVforecast 4066 Wh
setstate SolarForecast 2025-03-04 11:59:55 Today_Hour12_PVreal 4012 Wh
setstate SolarForecast 2025-03-04 12:59:55 Today_Hour13_BatIn_01 1579 Wh
setstate SolarForecast 2025-03-04 12:59:55 Today_Hour13_BatOut_01 0 Wh
setstate SolarForecast 2025-03-04 12:59:55 Today_Hour13_GridConsumption 36 Wh
setstate SolarForecast 2025-03-04 12:59:55 Today_Hour13_GridFeedIn 722 Wh
setstate SolarForecast 2025-03-04 12:59:55 Today_Hour13_PVforecast 5818 Wh
setstate SolarForecast 2025-03-04 12:59:55 Today_Hour13_PVreal 4452 Wh
setstate SolarForecast 2025-03-04 13:59:57 Today_Hour14_BatIn_01 284 Wh
setstate SolarForecast 2025-03-04 13:59:57 Today_Hour14_BatOut_01 6 Wh
setstate SolarForecast 2025-03-04 13:59:57 Today_Hour14_GridConsumption 27 Wh
setstate SolarForecast 2025-03-04 13:59:57 Today_Hour14_GridFeedIn 616 Wh
setstate SolarForecast 2025-03-04 13:59:57 Today_Hour14_PVforecast 4543 Wh
setstate SolarForecast 2025-03-04 13:59:57 Today_Hour14_PVreal 4394 Wh
setstate SolarForecast 2025-03-04 14:59:58 Today_Hour15_BatIn_01 208 Wh
setstate SolarForecast 2025-03-04 14:59:58 Today_Hour15_BatOut_01 274 Wh
setstate SolarForecast 2025-03-04 14:59:58 Today_Hour15_GridConsumption 63 Wh
setstate SolarForecast 2025-03-04 14:59:58 Today_Hour15_GridFeedIn 499 Wh
setstate SolarForecast 2025-03-04 14:59:58 Today_Hour15_PVforecast 3604 Wh
setstate SolarForecast 2025-03-04 14:59:58 Today_Hour15_PVreal 3630 Wh
setstate SolarForecast 2025-03-04 15:59:59 Today_Hour16_BatIn_01 406 Wh
setstate SolarForecast 2025-03-04 15:59:59 Today_Hour16_BatOut_01 274 Wh
setstate SolarForecast 2025-03-04 15:59:59 Today_Hour16_GridConsumption 28 Wh
setstate SolarForecast 2025-03-04 15:59:59 Today_Hour16_GridFeedIn 608 Wh
setstate SolarForecast 2025-03-04 15:59:59 Today_Hour16_PVforecast 3852 Wh
setstate SolarForecast 2025-03-04 15:59:59 Today_Hour16_PVreal 2005 Wh
setstate SolarForecast 2025-03-04 16:59:58 Today_Hour17_BatIn_01 28 Wh
setstate SolarForecast 2025-03-04 16:59:58 Today_Hour17_BatOut_01 9 Wh
setstate SolarForecast 2025-03-04 16:59:58 Today_Hour17_GridConsumption 16 Wh
setstate SolarForecast 2025-03-04 16:59:58 Today_Hour17_GridFeedIn 430 Wh
setstate SolarForecast 2025-03-04 16:59:58 Today_Hour17_PVforecast 1345 Wh
setstate SolarForecast 2025-03-04 16:59:58 Today_Hour17_PVreal 1115 Wh
setstate SolarForecast 2025-03-04 17:59:59 Today_Hour18_BatIn_01 3 Wh
setstate SolarForecast 2025-03-04 17:59:59 Today_Hour18_BatOut_01 1036 Wh
setstate SolarForecast 2025-03-04 17:59:59 Today_Hour18_GridConsumption 75 Wh
setstate SolarForecast 2025-03-04 17:59:59 Today_Hour18_GridFeedIn 3 Wh
setstate SolarForecast 2025-03-04 17:59:59 Today_Hour18_PVforecast 286 Wh
setstate SolarForecast 2025-03-04 17:59:59 Today_Hour18_PVreal 212 Wh
setstate SolarForecast 2025-03-04 18:59:59 Today_Hour19_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 18:59:59 Today_Hour19_BatOut_01 732 Wh
setstate SolarForecast 2025-03-04 18:59:59 Today_Hour19_GridConsumption 39 Wh
setstate SolarForecast 2025-03-04 18:59:59 Today_Hour19_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 18:59:59 Today_Hour19_PVreal 0 Wh
setstate SolarForecast 2025-03-04 19:59:56 Today_Hour20_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 19:59:56 Today_Hour20_BatOut_01 689 Wh
setstate SolarForecast 2025-03-04 19:59:56 Today_Hour20_GridConsumption 43 Wh
setstate SolarForecast 2025-03-04 19:59:56 Today_Hour20_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 19:59:56 Today_Hour20_PVreal 0 Wh
setstate SolarForecast 2025-03-04 20:59:58 Today_Hour21_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 20:59:58 Today_Hour21_BatOut_01 808 Wh
setstate SolarForecast 2025-03-04 20:59:58 Today_Hour21_GridConsumption 45 Wh
setstate SolarForecast 2025-03-04 20:59:58 Today_Hour21_GridFeedIn 1 Wh
setstate SolarForecast 2025-03-04 20:59:58 Today_Hour21_PVreal 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_Hour22_BatIn_01 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_Hour22_BatOut_01 324 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_Hour22_GridConsumption 17 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_Hour22_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_Hour22_PVreal 0 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_MaxPVforecast 5818 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_MaxPVforecastTime 2025-03-04 12:00:00
setstate SolarForecast 2025-03-04 21:22:14 Today_PVdeviation 9.23 %
setstate SolarForecast 2025-03-04 21:22:14 Today_PVforecast 29564 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_PVreal 26834 Wh
setstate SolarForecast 2025-03-04 21:22:14 Today_SunRise 06:54
setstate SolarForecast 2025-03-04 21:22:14 Today_SunSet 17:54
setstate SolarForecast 2025-03-04 21:22:14 Tomorrow_ConsumptionForecast -147120 Wh
setstate SolarForecast 2025-03-04 21:22:14 Tomorrow_PVforecast 26333 Wh
setstate SolarForecast 2025-03-04 21:22:14 Tomorrow_SunRise 06:52
setstate SolarForecast 2025-03-04 21:22:14 Tomorrow_SunSet 17:56
setstate SolarForecast 2025-03-04 21:22:14 consumer01 name='Klimaanlage' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer01_currentPower 0 W
setstate SolarForecast 2025-03-04 21:22:14 consumer02 name='Tageslichtlampe' state='off' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate SolarForecast 2025-03-04 21:22:14 consumer02_currentPower 0 W
setstate SolarForecast 2025-03-04 21:22:14 consumer03 name='Spelunkenentfeuchter' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer03_currentPower 0 W
setstate SolarForecast 2025-03-04 21:22:14 consumer04 name='Geschirrspüler' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer04_currentPower 0 W
setstate SolarForecast 2025-03-04 21:22:14 consumer05 name='Wäschetrockner' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate SolarForecast 2025-03-04 21:22:14 consumer05_currentPower 0.02 W
setstate SolarForecast 2025-03-04 21:22:14 consumer06 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate SolarForecast 2025-03-04 21:22:14 consumer06_currentPower 0.18 W
setstate SolarForecast 2025-03-04 21:22:14 consumer07 name='Büro' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer07_currentPower 179.2 W
setstate SolarForecast 2025-03-04 21:22:14 consumer08 name='Wohnzimmer' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer08_currentPower 155.7 W
setstate SolarForecast 2025-03-04 21:22:14 consumer09 name='Klimaaußengerät' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer09_currentPower 0 W
setstate SolarForecast 2025-03-04 21:22:14 consumer10 name='Küchen-Kühlschrank' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer10_currentPower 0 W
setstate SolarForecast 2025-03-04 21:22:14 consumer11 name='Kaffeemaschine, Toaster, Thermomix' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer11_currentPower 4.1 W
setstate SolarForecast 2025-03-04 21:22:14 consumer12 name='Kellerkühlschrank' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer12_currentPower 117.9 W
setstate SolarForecast 2025-03-04 21:22:14 consumer13 name='PlugSchuppen' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-04 21:22:14 consumer13_currentPower 0 W
setstate SolarForecast 2025-03-04 21:22:14 consumer14 name='Teichbelüfter' state='off' mode='can' planningstate='planned'
setstate SolarForecast 2025-03-04 21:22:14 consumer14_planned_start 05.03.2025 07:00:00
setstate SolarForecast 2025-03-04 21:22:14 consumer14_planned_stop 05.03.2025 08:00:00
setstate SolarForecast 2025-03-04 21:22:14 consumer15 name='WallboxLeistungssumme' state='on' mode='can' planningstate='suspended' info='max Überschußprognose zu gering'
setstate SolarForecast 2025-03-04 21:22:14 consumer15_currentPower 3.179 W
setstate SolarForecast 2025-03-04 21:22:14 consumer16 name='Skimmer' state='off' mode='can' planningstate='planned'
setstate SolarForecast 2025-03-04 21:22:14 consumer16_planned_start 05.03.2025 07:00:00
setstate SolarForecast 2025-03-04 21:22:14 consumer16_planned_stop 05.03.2025 08:00:00
setstate SolarForecast 2025-03-04 21:22:14 nextCycletime 21:22:19
setstate SolarForecast 2025-03-04 08:00:01 pvCorrectionFactor_08 1.65 (automatic - old factor: 0.90, Sun Alt range: 5, Cloud range: 70, Days in range: 2)
setstate SolarForecast 2025-03-04 09:00:01 pvCorrectionFactor_09 1.76 (automatic - old factor: 1.33, Sun Alt range: 15, Cloud range: 70, Days in range: 2)
setstate SolarForecast 2025-03-04 10:00:06 pvCorrectionFactor_10 0.95 (automatic - old factor: 1.30, Sun Alt range: 20, Cloud range: 65, Days in range: 2)
setstate SolarForecast 2025-03-04 11:00:07 pvCorrectionFactor_11 1.01 (automatic - old factor: 1.09, AI result used, Sun Alt range: 25, Cloud range: 60, Days in range: 2)
setstate SolarForecast 2025-03-04 12:00:01 pvCorrectionFactor_12 0.93 (automatic - old factor: 0.94, Sun Alt range: 30, Cloud range: 55, Days in range: 2)
setstate SolarForecast 2025-03-04 13:00:00 pvCorrectionFactor_13 0.92 (automatic - old factor: 1.20, Sun Alt range: 30, Cloud range: 50, Days in range: 2)
setstate SolarForecast 2025-03-04 14:00:06 pvCorrectionFactor_14 1.06 (automatic - old factor: 1.20, Sun Alt range: 30, Cloud range: 50, Days in range: 2)
setstate SolarForecast 2025-03-04 15:00:02 pvCorrectionFactor_15 1.01 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 45, Days in range: 1)
setstate SolarForecast 2025-03-04 16:00:04 pvCorrectionFactor_16 1.02 (automatic - old factor: 1.48, Sun Alt range: 20, Cloud range: 40, Days in range: 2)
setstate SolarForecast 2025-03-04 17:00:05 pvCorrectionFactor_17 0.83 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 40, Days in range: 1)
setstate SolarForecast 2025-03-04 18:00:05 pvCorrectionFactor_18 0.74 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 40, Days in range: 1)
setstate SolarForecast 2025-03-04 21:22:14 pvCorrectionFactor_Auto on_complex_ai
setstate SolarForecast 2024-08-24 17:13:20 setupStringAzimuth Osten=-127 Westen=53
setstate SolarForecast 2025-02-19 10:56:15 setupStringDeclination Osten=38 Westen=38
setstate SolarForecast 2025-03-04 21:22:14 special_todayBatInSum 8092.0 Wh
setstate SolarForecast 2025-03-04 21:22:14 special_todayBatOutSum 6740.0 Wh
setstate SolarForecast 2025-03-04 21:22:14 special_todayConsumption 24281 Wh
setstate SolarForecast 2025-03-04 21:22:14 special_todayGridConsumption 2112 Wh
setstate SolarForecast 2025-03-04 21:22:14 special_todayGridFeedIn 3402.5 Wh
setstate SolarForecast 2025-03-04 21:22:15 state updated
Trotzdem habe ich morgen vor 13 Uhr den SoCfc=0.
Findet Ihr noch einen Fehler in meiner Konfiguration?
Viele Grüße,
Peter
PS: Die Geschichte mit den Kommastellen sieht für mich gut aus!
Ich habe nochmal im Code geschaut. Mit dem Multibatterie Management (und dem obligatorischen cap) ist das "einfache" Ausschalten nicht mehr so simpel.
Ich habe schon eine Idee es wieder einfach zu gestalten, aber erst Morgen. Heute ist es für diese Operation etwas zu spät geworden.
Melde mich morgen dazu nochmal.
Wenn Du da schon für mich ran gehst: Besteht evtl. auch die Möglichkeit, eine maximale Ladeleistung sowie min- und max-SoC an den einzelnen Batterien zu definieren und diese in der Prognose zu berücksichtigen?
Der SoC meiner Batterie schwankt (gesteuert durch Logik, die ich nicht beeinflussen kann) zwischen 3% und 100%. Die Ladeleistung liegt maximal bei 2580Watt.
Und wie immer: das ist weder eilig noch wichtig. Es soll ja in erster Linie Spaß machen, auch Dir als Entwickler.
Vielen Dank und viele Grüße,
Peter
ZitatWenn Du da schon für mich ran gehst: Besteht evtl. auch die Möglichkeit, eine maximale Ladeleistung sowie min- und max-SoC an den einzelnen Batterien zu definieren und diese in der Prognose zu berücksichtigen?
Da muß ich mal schauen. min- und max-SoC der einzelnen Batterien kannst du eigentlich schon im Attr ctrlBatSocManagementXX festlegen, ist aber fest und nicht dynamisch änderbar.
Möglicherweise lege ich das auf ein späteres Release. Den aktuellen Entwicklungsstand will ich erstmal finalisieren und für alle einchecken.
Hallo Heiko,
Zitat von: DS_Starter am 04 März 2025, 22:24:35Da muß ich mal schauen. min- und max-SoC der einzelnen Batterien kannst du eigentlich schon im Attr ctrlBatSocManagementXX festlegen, ist aber fest und nicht dynamisch änderbar.
Dann warte ich dann erstmal Deine finalisierte Version ab, bevor ich das attr ctrlBatSocManagement01 wieder anlege.
Dynamische Änderung brauche ich (und ich kann da nur für mich sprechen)
nicht. Ich könnte auch mit der SoC-Range 0-100 leben. Die SoC-Range 3-100, die mein Enphase-Gateway steuert, ist ja nicht so weit davon weg.
Wichtiger wäre mir, dass die Prognose des SoC realistischer für meine Rahmenbedingungen ist.
Klar lässt sich das nicht 1:1 nachbilden, ohne die genaue Logik zu kennen. Aber es soll ja auch "nur" eine Prognose sein. Das kann und muss auch nicht 100% stimmen.
Wenn Du was zu testen hast, stehe ich gerne bereit.
Viele Grüße,
Peter
Guten Morgen,
in meinem contrib liegt ein Update. Jetzt klappt das Abschalten des Bat Lademanagements wieder so wie kommuniziert durch Löschen/nicht Setzen des Attr ctrlBatSocManagementXX.
Die Unterschiede sieht man in den angehängten Screens.
Im linken Screen ist ctrlBatSocManagementXX eingeschaltet und lt. Prognose wird die Bat erst 15:00 zu 100% geladen sein.
Im rechten Screen ist ctrlBatSocManagementXX nicht eingeschaltet und die Bat wird sofort mit dem PV Überschuß geladen, sodass sie bereits 11:00 volll sein wird. Der Überschuß wird ab dem Erzeugnisspeak ins Netz eingespeist was nicht netzdienlich ist, zumal eine Abregelung der PV Anlage die Folge sein kann.
@Peter, jetzt sollten deine Bat Prognose den Verlauf anzeigen wie du es dir wünscht. Deine anderen Punkte schaue ich mir später an.
Zitat von: DS_Starter am 05 März 2025, 08:25:57in meinem contrib liegt ein Update
Wow! Das ging ja schnell. Ich ziehe das gleich mal.
Hallo Heiko,
das sieht für meine Umgebung schon sehr gut aus:
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 08 -> 1 (currsoc: 11 %, SoCfc: 8.1 %, soc: 566 Wh, pvfc: 500, confc: 684, Surp Day: 16496 Wh, Curr PV: 1696 W, Curr Consumption: 667 W, Limit: 10000 W)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 09 -> 1 (SoCfc: 21.8 %, soc: 1525 Wh, pvfc: 1892, confc: 826, Surp Day: 15430 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 10 -> 1 (SoCfc: 44.2 %, soc: 3095 Wh, pvfc: 2451, confc: 707, Surp Day: 13686 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 11 -> 1 (SoCfc: 74.5 %, soc: 5213 Wh, pvfc: 3026, confc: 673, Surp Day: 11333 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 12 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3387, confc: 652, Surp Day: 8598 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 13 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4456, confc: 870, Surp Day: 5012 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 14 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3645, confc: 1504, Surp Day: 2871 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3369, confc: 1422, Surp Day: 924 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 16 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 2253, confc: 711, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 17 -> 1 (SoCfc: 84.2 %, soc: 5897 Wh, pvfc: 211, confc: 1204, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 18 -> 1 (SoCfc: 73.6 %, soc: 5151 Wh, pvfc: 0, confc: 671, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 19 -> 1 (SoCfc: 63.1 %, soc: 4417 Wh, pvfc: 0, confc: 661, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 20 -> 1 (SoCfc: 52.4 %, soc: 3666 Wh, pvfc: 0, confc: 676, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 21 -> 1 (SoCfc: 43.4 %, soc: 3040 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 22 -> 1 (SoCfc: 35.4 %, soc: 2479 Wh, pvfc: 0, confc: 505, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 23 -> 1 (SoCfc: 26.5 %, soc: 1853 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 00 -> 1 (SoCfc: 17.6 %, soc: 1234 Wh, pvfc: 0, confc: 557, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 01 -> 1 (SoCfc: 9.9 %, soc: 695 Wh, pvfc: 0, confc: 485, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 02 -> 1 (SoCfc: 2.4 %, soc: 168 Wh, pvfc: 0, confc: 474, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 03 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 503, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 04 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 448, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 05 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 481, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 06 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 14, confc: 575, Surp Day: 14517 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 07 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 356, confc: 686, Surp Day: 14847 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 08 -> 1 (SoCfc: 0.5 %, soc: 32 Wh, pvfc: 720, confc: 684, Surp Day: 14811 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 09 -> 1 (SoCfc: 14.1 %, soc: 990 Wh, pvfc: 1891, confc: 826, Surp Day: 13746 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 10 -> 1 (SoCfc: 59.9 %, soc: 4196 Wh, pvfc: 4269, confc: 707, Surp Day: 10184 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 11 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 5657, confc: 673, Surp Day: 5200 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 12 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 5144, confc: 652, Surp Day: 708 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 13 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 2106, confc: 870, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 14 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3021, confc: 1504, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4673, confc: 1422, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 16 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 1484, confc: 711, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 17 -> 1 (SoCfc: 86.5 %, soc: 6056 Wh, pvfc: 354, confc: 1204, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 18 -> 1 (SoCfc: 75.9 %, soc: 5310 Wh, pvfc: 0, confc: 671, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 19 -> 1 (SoCfc: 65.4 %, soc: 4576 Wh, pvfc: 0, confc: 661, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 20 -> 1 (SoCfc: 54.6 %, soc: 3825 Wh, pvfc: 0, confc: 676, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 21 -> 1 (SoCfc: 45.7 %, soc: 3199 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 22 -> 1 (SoCfc: 37.7 %, soc: 2638 Wh, pvfc: 0, confc: 505, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 23 -> 1 (SoCfc: 28.7 %, soc: 2012 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
Die kleinen Punkte für Deine zukünftige Entwicklung sind hier nochmal gut zu sehen:
1) Der SoC wird nie auf 0% runter gehen, wie hier zwischen 06 02 und 06 08 zu sehen. Bei mir geht es bis minimal 3% runter.
2) Mein Speicher wird nie mit mehr als 2580W ge- oder entladen. In der Prognose würde diese Einschränkung bei 06 09 bis 06 11 greifen.
Wie gesagt: Für mich passen die aktuellen Änderungen gut. Danke dafür!
Viele Grüße,
Peter
Prima.
Zitat1) Der SoC wird nie auf 0% runter gehen, wie hier zwischen 06 02 und 06 08 zu sehen. Bei mir geht es bis minimal 3% runter.
Die SoC Begrenzungen sind Bestandteil der SoC Steuerung (ctrlBatSocManagementXX). Wenn man das Attr aus den genannten Gründen nicht setzt, greifen diese Einstellungen auch nicht. Damit muss man dann leben denke ich.
Das Verfahren muß einer gewissen Stringenz folgen.
Zitat2) Mein Speicher wird nie mit mehr als 2580W ge- oder entladen. In der Prognose würde diese Einschränkung bei 06 09 bis 06 11 greifen.
Das ist eine Eigenschaft des Speichers, den ich in einem Schlüssel im Attr setupBatteryDevXX abbilden könnte und dadurch in die Berechnung einfließen lassen kann.
Schaue ich mir mal in einer späteren Weiterentwicklung mit an.
LG,
Heiko
Hallo zusammen,
wahrscheinlich am Freitag wird die Version 1.47.0 im Update ausgeliefert.
Es ist ein Major Release. Diese Version ist nicht rückwärts kompatibel, d.h. Sicherungen und Backupfiles von Versionen < 1.47.0 sind mit dieser Version nicht kompatibel.
Was ist alles entalten?
- die KI ist erweitert um einen einstellbaren Essemble Algorithmus (Random Forests mit Essemble Algorithmus)
- ein neues Attribut aiControl ersetzt die bisherigen Attr ctrlAIdataStorageDuration und ctrlAIshiftTrainStart mit entspr. Schlüsseln
- im Attribut aiControl gibt es den Schlüssel aiTreesPV mit dem die Größe des Ensembles (s.o.) eingestellt werden kann
- das Training der KI erfolgt immer in einem Nebenprozess um keinerlei Blockierungen im System zu verursachen
- im Batteriemanagement sind einige Verbesserungen bzgl. der SoC Prognose eingeflossen und die Abhängigkeit vom Attr ctrlBatSocManagementXX wiederhergestellt
- die Setter "set ... aiDecTree addInstances" und "train" sind entfallen und wurden durch einen kombinierten Setter "set ... addInstAndTrain" ersetzt
- die Diff-Balkenanzeige ist bzgl. der Nachkommastellen überarbeitet
- kleinere Bugfixes
Alle Änderungen an Attributen werden automatisch vorgenommen. Ihr braucht nichts tun außer das Log nach dem Update kontrollieren und "save config" drücken um die Attributänderungen zu speichern.
Im Log kommt der Hinweis:
The attribute ctrlAIshiftTrainStart / ctrlAIdataStorageDuration is replaced by 'aiControl'. Please press 'save config' when restart is finished.
Solltet ihr nach dem Update von KI Fehlermeldungen erhalten, etwa "The trained object is not AI::DecisionTree", wartet ihr einfach bis zum nächsten automatischen KI Training oder führt "set ... aiDecTree addInstAndTrain" manuell aus.
Dann noch der Hinweis, dass ihr eure KI im Attribut aiControl, Schlüssel aiTreesPV bzgl. der Anzahl der trainierten Bäume einstellen könnt.
Standard ist 10. Bisher wurde nur ein Tree trainiert. Je mehr Trees ihr einstellt, desto robuster wird tendenziell die KI-Prognose und hat auch deutlich mehr Treffer.
Aber wo Licht ist, gibt es auch Schatten. Je mehr Trees ihr rechnet, desto mehr Rssourcen CPU, RAM werden benötigt. Die CPU eigentlich nur beim Training. Das läuft jetzt generell in einem Nebenprozess ab. Ihr braucht keine Bedenken wegen irgendwelcher Blockierungen in FHEM zu haben.
Aber der RAM-Verbrauch steigt mit steigender Tree Anzahl an. Je nach eurer Hardware könnt ihr ein bisschen probieren um das Optimum zu finden.
Als Beispiel habe ich 4600 Rohdatensätze und lasse 10 Trees (den Standard) rechnen. Damit erhalte ich für ca. 80% der Stundenwerte einen Treffer von der KI. Der RAM liegt bei 710 MB, Allerdings habe ich 5 SF-Instanzen parallel laufen, davon 3 mit KI Unterstützung.
Die Version liegt schon vorab im contrib. FHEM auf jeden Fall nach dem Download restarten.
LG,
Heiko
Nur mal so nebenbei, gestern und heute hatte ich auf einer meiner Instanzen Abweichungen von nur 0,8% bzw. -0,3%. Die Instanz verwendet die SolCast API.
Aber das ist schon sehr außergewöhnlich und nur der sehr stabilen Wetterlage geschuldet.
Es freut aber trotzdem. ;D
Das ist wirklich ein sehr gutes Ergebnis bei dir ;D
Schade - bei mir in den letzten Tagen teils >= -100 % daneben :o
Also immer mehr geerntet als der Forecast (DWD) "sagte" 8)
Trotzdem wunderbar wenn die Batterie bis zum Rand voll wird O:-)
Bei mir 2,9 % und -1,5 %, das sind doch Hammer Zahlen!
Ich benutze 2 DWD Stationen.
Gruß,
Stefan
Zitat von: stefanru am 05 März 2025, 20:34:49Ich benutze 2 DWD Stationen.
Darüber denke ich momentan auch nach.... ::)
War bislang in den letzten Jahren sonst besser
Naja, das ist wie geschrieben schon sehr außergwöhlich. Normal liegen die Abweichungen bei +-2 - 30% je nach Witterungslage. Bei ganz schlechten Bedingungen auch mehr.
Ja, aber wenn den ganzen Tag Sonne diese Woche vorausgesagt wird ist da schon etwas verwunderlich wenn mein Forecast mehrere Tage "voll daneben" liegt.
(sorry - liegt evtl. aber auch an meinem Standort bzw. den Zahlen die DWD dafür vorgibt)
So starke Abweichungen über längere Zeit bei solchen Wetter ist schon außergewöhnlich m.M. nach. Liste mal bitte deine pvCorrectionFactor_XX Readings.
setstate Forecast 2025-03-05 09:00:05 pvCorrectionFactor_09 1.75 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 10:00:04 pvCorrectionFactor_10 1.75 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 10, Days in range: 1)
setstate Forecast 2025-03-05 11:00:01 pvCorrectionFactor_11 1.75 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 12:00:05 pvCorrectionFactor_12 1.75 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 13:00:02 pvCorrectionFactor_13 1.75 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 14:00:00 pvCorrectionFactor_14 1.65 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 15:00:05 pvCorrectionFactor_15 1.75 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 16:00:03 pvCorrectionFactor_16 1.75 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 17:00:05 pvCorrectionFactor_17 1.75 (automatic - old factor: 1.00, AI result used, Sun Alt range: 15, Cloud range: 15, Days in range: 1)
setstate Forecast 2025-03-05 20:47:04 pvCorrectionFactor_Auto on_complex_ai
Ja, alle "Vorfälle" traten bei dir das erste mal auf (Days in range: 1). Das Modul hat keinerlei Vergleichswerte.
Zeige uns doch bitte mal von "get ... pvCircular 13" die Teile pvrl_30, pvfc_30 und pvcorrf.
pvcorrf ist etwas umfangreicher, etwa so:
pvcorrf: 15.00=1.57 15.05=1.50 15.100=1.04 15.20=0.97 15.35=1.50 15.45=1.30 15.55=1.33 15.70=0.81 15.75=0.61 15.85=1.21
15.90=1.57 15.95=0.73 20.100=0.86 20.15=0.25 20.20=1.47 20.50=1.24 20.55=1.16 20.60=1.50 20.65=0.56 20.70=1.29
20.75=0.69 20.80=0.70 20.85=0.39 20.90=0.95 20.95=0.60 25.00=1.12 25.05=1.50 25.100=0.40 25.20=1.25 25.25=0.87
25.30=0.94 25.35=1.50 25.45=1.42 25.50=1.27 25.55=1.36 25.65=1.14 25.70=0.66 25.75=1.47 25.80=1.21 25.85=0.56
25.90=0.66 30.00=0.97 30.10=0.95 30.100=0.91 30.25=1.11 30.30=1.13 30.35=1.23 30.45=1.30 30.55=0.92 30.60=1.39
30.65=1.35 30.70=1.31 30.75=1.12 30.80=1.14 30.95=1.54 35.00=0.96 35.65=1.12 35.95=0.41
hier:
13 => pvapifc: 3052, pvaifc: 2352, pvfc: 2352, aihit: 1, pvrl: 3942
batin01: 61, batin02: 2, batin03: -
batout01: 22, batout02: 27, batout03: -
confc: 664, gcon: 21, gfeedin: 2738, wcc: 25, rr1c: 0.00
temp: 12.00, wid: 0, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: 695, pprl02: -, pprl03: -
pvcorrf: 15.100=0.38 15.30=0.86 15.35=0.66 15.45=0.66 15.60=0.88 15.75=0.50 15.80=0.54 15.85=0.39 15.90=0.48 15.95=0.40
20.100=1.01 20.30=1.22 20.40=1.20 20.45=1.19 20.50=1.29 20.55=1.71 20.70=0.48 20.80=0.90 20.85=0.75 20.90=0.78
20.95=0.60 25.30=1.75 25.35=1.75 25.40=0.83 25.45=0.88 25.50=1.10 25.55=1.03 25.60=1.75 25.70=1.24 25.75=1.24
25.80=0.66 25.85=0.45 25.90=0.57 25.95=0.52 30.25=1.75 30.30=1.60 30.35=1.75 30.40=1.75 30.55=0.99 30.60=1.29
30.65=1.10 30.70=1.25 30.80=1.11 30.85=0.94 30.90=0.79 30.95=0.55 35.100=1.16 35.15=1.75 35.45=0.78 35.65=0.88
35.75=1.48 35.80=1.28 35.85=1.07 40.00=0.97 40.05=0.97 40.100=1.02 40.35=0.98 40.50=0.79 40.55=0.89 40.70=1.07
40.85=1.06 45.00=0.97 45.10=0.97 45.100=0.97 45.15=0.96 45.20=0.97 45.30=0.97 45.35=0.79 45.40=0.97 45.45=0.97
45.70=0.98 45.85=1.02 45.95=0.70 50.00=0.96 50.05=0.97 50.100=1.00 50.25=0.95 50.40=0.96 50.45=0.91 50.55=1.02
50.70=1.50 50.80=0.83 50.85=0.81 50.90=1.28 50.95=0.86 55.00=0.93 55.10=0.94 55.100=1.03 55.20=1.04 55.45=0.97
55.50=1.00 55.65=1.01 55.80=0.92 55.85=1.25 55.90=1.00 55.95=0.99 60.00=1.08 60.05=0.93 60.100=1.05 60.15=0.95
60.30=0.95 60.40=0.98 60.55=1.01 60.60=0.76 60.65=0.95 60.75=0.96 60.85=1.25 60.90=0.80 60.95=0.98
simple=0.94
pvrl_35 => 15 @ 3942
45 @ 2409
65 @ 2077
75 @ 5743
80 @ 3582
85 @ 2298
100 @ 1529
pvfc_35 => 15 @ 2178
45 @ 4200
65 @ 2786
75 @ 2934
80 @ 2303
85 @ 2142
100 @ 1318
Sorry, habe mich vertan -> pvrl_35, pvfc_35 wäre richtig.
oben korrigiert
Hallo Heiko,
kurzes Problem:
nach einem Update auf 76_SolarForecast.pm:v1.1.1-s29707/2025-02-28 flutet es mir das LogFile mit "Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12291."
Entsprechende Code Zeile ist
debugLog ($paref, 'saveData2Cache|consumption_long', "store '$k' hod '$nhhr' confc: $usage{$nhhr}{con}, confcEx: $usage{$nhhr}{conex}");
List
Internals:
FUUID 64e49843-f33f-bc77-7094-15af996111265637
FVERSION 76_SolarForecast.pm:v1.1.1-s29707/2025-02-28
LCACHEFILE last write time: 21:06:20 whole Operating Memory
MODE Automatic / Event-controlled - next planned Cycletime: 21:08:40
MODEL DWD
NAME mySolarForeCast
NOTIFYDEV myLGESS,SW_AU_Poolpumpe_2,STKD_UG_Luftentfeuchter_2,HT_WP_EnergyMeter,STKD_EG_Flur_Tablet_2,STKD_EG_Kueche_Kuehlschrank,STKD_EG_Kueche_Spuelmaschine,STKD_UG_FridgeBeverage,n_IT_Keller_Energy,STKD_EG_Buero_IT,PM_UG_Trockner,PM_UG_Waschmaschine,STKD_UG_Lufttrockner,di_LGESS_Battery
NR 409
NTFY_ORDER 50-mySolarForeCast
STATE updated
TYPE SolarForecast
WEATHERMODEL DWD
eventCount 136
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV mySolarForeCast
SPGROOM
VERSION 1.46.5
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 46
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:4011
telnet telnetPort_127.0.0.1_50462
terminated 1
timeout 30
abortArg:
arg:
block 1
name mySolarForeCast
tsnext 1741209468.9755
Helper:
DBLOG:
RestOfDayConsumptionForecast:
myDbLog:
TIME 1741204212.62794
VALUE 0
RestOfDayPVforecast:
myDbLog:
TIME 1741204212.62794
VALUE 0
Today_MaxPVforecast:
myDbLog:
TIME 1741204212.62794
VALUE 3931
Today_MaxPVforecastTime:
myDbLog:
TIME 1741204212.62794
VALUE 2025-03-05 12:00:00
Today_PVdeviation:
myDbLog:
TIME 1741204212.62794
VALUE 3.49
Today_PVforecast:
myDbLog:
TIME 1741204212.62794
VALUE 24530
Today_PVreal:
myDbLog:
TIME 1741204212.62794
VALUE 23674
Tomorrow_ConsumptionForecast:
myDbLog:
TIME 1741204816.08377
VALUE 2097
Tomorrow_PVforecast:
myDbLog:
TIME 1741204816.08377
VALUE 22897
Tomorrow_SunRise:
myDbLog:
TIME 1741204212.62794
VALUE 06:48
Tomorrow_SunSet:
myDbLog:
TIME 1741204212.62794
VALUE 18:05
special_BatPowerIn_Sum:
myDbLog:
TIME 1741204212.62794
VALUE 0
special_BatPowerOut_Sum:
myDbLog:
TIME 1741205300.10796
VALUE 712
special_SunHours_Remain:
myDbLog:
TIME 1741204212.62794
VALUE 0.00
special_SunMinutes_Remain:
myDbLog:
TIME 1741204212.62794
VALUE 0
special_allStringsFullfilled:
myDbLog:
TIME 1741204212.62794
VALUE 1
special_conForecastTillNextSunrise:
myDbLog:
TIME 1741204212.62794
VALUE -
special_dayAfterTomorrowPVforecast:
myDbLog:
TIME 1741204816.08377
VALUE 24321
special_daysUntilBatteryCare_01:
myDbLog:
TIME 1741204212.62794
VALUE -
special_runTimeCentralTask:
myDbLog:
TIME 1741204232.31076
VALUE 0.0660
special_runTimeLastAPIAnswer:
myDbLog:
TIME 1741204212.62794
VALUE -
special_runTimeLastAPIProc:
myDbLog:
TIME 1741204212.62794
VALUE -
special_runTimeTrainAI:
myDbLog:
TIME 1741204212.62794
VALUE 0.5046
special_todayBatIn_01:
myDbLog:
TIME 1741204212.62794
VALUE 9180.0
special_todayBatOut_01:
myDbLog:
TIME 1741204816.08377
VALUE 7486.0
special_todayConForecastTillSunset:
myDbLog:
TIME 1741204212.62794
VALUE 0
special_todayConsumptionForecast_01:
myDbLog:
TIME 1741204212.62794
VALUE 1050
special_todayConsumptionForecast_02:
myDbLog:
TIME 1741204212.62794
VALUE 981
special_todayConsumptionForecast_03:
myDbLog:
TIME 1741204212.62794
VALUE 1049
special_todayConsumptionForecast_04:
myDbLog:
TIME 1741204212.62794
VALUE 953
special_todayConsumptionForecast_05:
myDbLog:
TIME 1741204212.62794
VALUE 784
special_todayConsumptionForecast_06:
myDbLog:
TIME 1741204212.62794
VALUE 732
special_todayConsumptionForecast_07:
myDbLog:
TIME 1741204212.62794
VALUE 1856
special_todayConsumptionForecast_08:
myDbLog:
TIME 1741204212.62794
VALUE 1559
special_todayConsumptionForecast_09:
myDbLog:
TIME 1741204212.62794
VALUE 238
special_todayConsumptionForecast_10:
myDbLog:
TIME 1741204212.62794
VALUE 2007
special_todayConsumptionForecast_11:
myDbLog:
TIME 1741204212.62794
VALUE 2475
special_todayConsumptionForecast_12:
myDbLog:
TIME 1741204212.62794
VALUE 2242
special_todayConsumptionForecast_13:
myDbLog:
TIME 1741204212.62794
VALUE 1340
special_todayConsumptionForecast_14:
myDbLog:
TIME 1741204212.62794
VALUE 1148
special_todayConsumptionForecast_15:
myDbLog:
TIME 1741204212.62794
VALUE 552
special_todayConsumptionForecast_16:
myDbLog:
TIME 1741204212.62794
VALUE 401
special_todayConsumptionForecast_17:
myDbLog:
TIME 1741204212.62794
VALUE 738
special_todayConsumptionForecast_18:
myDbLog:
TIME 1741204212.62794
VALUE 886
special_todayConsumptionForecast_19:
myDbLog:
TIME 1741204212.62794
VALUE 400
special_todayConsumptionForecast_20:
myDbLog:
TIME 1741204212.62794
VALUE 201
special_todayConsumptionForecast_21:
myDbLog:
TIME 1741204212.62794
VALUE -
special_todayConsumptionForecast_22:
myDbLog:
TIME 1741204212.62794
VALUE -
special_todayConsumptionForecast_23:
myDbLog:
TIME 1741204212.62794
VALUE -
special_todayConsumptionForecast_24:
myDbLog:
TIME 1741204212.62794
VALUE -
special_todayGridConsumption:
myDbLog:
TIME 1741204212.62794
VALUE 12010
special_todayGridFeedIn:
myDbLog:
TIME 1741204212.62794
VALUE 2286.0
OLDREADINGS:
READINGS:
2025-03-05 21:08:20 Current_AutarkyRate 100 %
2025-03-05 21:08:20 Current_BatCharge_01 7.9 %
2025-03-05 21:08:20 Current_Consumption 712 W
2025-03-05 21:08:20 Current_GridConsumption 0 W
2025-03-05 21:08:20 Current_GridFeedIn 0 W
2025-03-05 21:08:20 Current_PV 0 W
2025-03-05 21:08:20 Current_PowerBatIn_01 0 W
2025-03-05 21:08:20 Current_PowerBatOut_01 712 W
2025-03-05 21:08:20 Current_SelfConsumption 0 W
2025-03-05 21:08:20 Current_SelfConsumptionRate 0 %
2025-03-05 21:08:20 Current_Surplus 0 W
2025-03-05 21:00:00 LastHourGridconsumptionReal 13 Wh
2025-03-05 21:00:00 LastHourPVforecast 0 Wh
2025-03-05 21:00:00 LastHourPVreal 0 Wh
2025-03-05 21:08:20 NextHours_Sum01_PVforecast 0 Wh
2025-03-05 21:08:20 NextHours_Sum02_PVforecast 0 Wh
2025-03-05 21:08:20 NextHours_Sum03_PVforecast 0 Wh
2025-03-05 21:08:20 NextHours_Sum04_ConsumptionForecast 0 Wh
2025-03-05 21:08:20 NextHours_Sum04_PVforecast 0 Wh
2025-03-05 21:08:20 RestOfDayConsumptionForecast 0 Wh
2025-03-05 21:08:20 RestOfDayPVforecast 0 Wh
2025-03-05 00:59:49 Today_Hour01_BatIn_01 0 Wh
2025-03-05 00:59:49 Today_Hour01_BatOut_01 0 Wh
2025-03-05 00:59:49 Today_Hour01_GridConsumption 336 Wh
2025-03-05 00:59:49 Today_Hour01_GridFeedIn 0 Wh
2025-03-05 00:59:49 Today_Hour01_PVreal 0 Wh
2025-03-05 01:59:50 Today_Hour02_BatIn_01 0 Wh
2025-03-05 01:59:50 Today_Hour02_BatOut_01 0 Wh
2025-03-05 01:59:50 Today_Hour02_GridConsumption 288 Wh
2025-03-05 01:59:50 Today_Hour02_GridFeedIn 0 Wh
2025-03-05 01:59:50 Today_Hour02_PVreal 0 Wh
2025-03-05 02:59:51 Today_Hour03_BatIn_01 0 Wh
2025-03-05 02:59:51 Today_Hour03_BatOut_01 0 Wh
2025-03-05 02:59:51 Today_Hour03_GridConsumption 4026 Wh
2025-03-05 02:59:51 Today_Hour03_GridFeedIn 0 Wh
2025-03-05 02:59:51 Today_Hour03_PVreal 0 Wh
2025-03-05 03:59:54 Today_Hour04_BatIn_01 0 Wh
2025-03-05 03:59:54 Today_Hour04_BatOut_01 0 Wh
2025-03-05 03:59:54 Today_Hour04_GridConsumption 1910 Wh
2025-03-05 03:59:54 Today_Hour04_GridFeedIn 0 Wh
2025-03-05 03:59:54 Today_Hour04_PVreal 0 Wh
2025-03-05 04:59:56 Today_Hour05_BatIn_01 0 Wh
2025-03-05 04:59:56 Today_Hour05_BatOut_01 0 Wh
2025-03-05 04:59:56 Today_Hour05_GridConsumption 294 Wh
2025-03-05 04:59:56 Today_Hour05_GridFeedIn 0 Wh
2025-03-05 04:59:56 Today_Hour05_PVreal 0 Wh
2025-03-05 05:59:59 Today_Hour06_BatIn_01 0 Wh
2025-03-05 05:59:59 Today_Hour06_BatOut_01 0 Wh
2025-03-05 05:59:59 Today_Hour06_GridConsumption 290 Wh
2025-03-05 05:59:59 Today_Hour06_GridFeedIn 0 Wh
2025-03-05 05:59:59 Today_Hour06_PVreal 0 Wh
2025-03-05 06:59:49 Today_Hour07_BatIn_01 0 Wh
2025-03-05 06:59:49 Today_Hour07_BatOut_01 0 Wh
2025-03-05 06:59:49 Today_Hour07_GridConsumption 1144 Wh
2025-03-05 06:59:49 Today_Hour07_GridFeedIn 0 Wh
2025-03-05 06:59:49 Today_Hour07_PVforecast 4 Wh
2025-03-05 06:59:49 Today_Hour07_PVreal 0 Wh
2025-03-05 07:59:49 Today_Hour08_BatIn_01 232 Wh
2025-03-05 07:59:49 Today_Hour08_BatOut_01 0 Wh
2025-03-05 07:59:49 Today_Hour08_GridConsumption 2984 Wh
2025-03-05 07:59:49 Today_Hour08_GridFeedIn 6 Wh
2025-03-05 07:59:49 Today_Hour08_PVforecast 46 Wh
2025-03-05 07:59:49 Today_Hour08_PVreal 570 Wh
2025-03-05 08:59:49 Today_Hour09_BatIn_01 1846 Wh
2025-03-05 08:59:49 Today_Hour09_BatOut_01 68 Wh
2025-03-05 08:59:49 Today_Hour09_GridConsumption 48 Wh
2025-03-05 08:59:49 Today_Hour09_GridFeedIn 55 Wh
2025-03-05 08:59:49 Today_Hour09_PVforecast 1917 Wh
2025-03-05 08:59:49 Today_Hour09_PVreal 2625 Wh
2025-03-05 09:59:49 Today_Hour10_BatIn_01 0 Wh
2025-03-05 09:59:49 Today_Hour10_BatOut_01 0 Wh
2025-03-05 09:59:49 Today_Hour10_GridConsumption 220 Wh
2025-03-05 09:59:49 Today_Hour10_GridFeedIn 8 Wh
2025-03-05 09:59:49 Today_Hour10_PVforecast 2826 Wh
2025-03-05 09:59:49 Today_Hour10_PVreal 2675 Wh
2025-03-05 10:59:52 Today_Hour11_BatIn_01 90 Wh
2025-03-05 10:59:52 Today_Hour11_BatOut_01 0 Wh
2025-03-05 10:59:52 Today_Hour11_GridConsumption 236 Wh
2025-03-05 10:59:52 Today_Hour11_GridFeedIn 9 Wh
2025-03-05 10:59:52 Today_Hour11_PVforecast 2488 Wh
2025-03-05 10:59:52 Today_Hour11_PVreal 3834 Wh
2025-03-05 11:59:55 Today_Hour12_BatIn_01 1194 Wh
2025-03-05 11:59:55 Today_Hour12_BatOut_01 0 Wh
2025-03-05 11:59:55 Today_Hour12_GridConsumption 37 Wh
2025-03-05 11:59:55 Today_Hour12_GridFeedIn 25 Wh
2025-03-05 11:59:55 Today_Hour12_PVforecast 3858 Wh
2025-03-05 11:59:55 Today_Hour12_PVreal 2891 Wh
2025-03-05 12:59:57 Today_Hour13_BatIn_01 3001 Wh
2025-03-05 12:59:57 Today_Hour13_BatOut_01 0 Wh
2025-03-05 12:59:57 Today_Hour13_GridConsumption 53 Wh
2025-03-05 12:59:57 Today_Hour13_GridFeedIn 39 Wh
2025-03-05 12:59:57 Today_Hour13_PVforecast 3931 Wh
2025-03-05 12:59:57 Today_Hour13_PVreal 3597 Wh
2025-03-05 13:59:49 Today_Hour14_BatIn_01 1276 Wh
2025-03-05 13:59:49 Today_Hour14_BatOut_01 90 Wh
2025-03-05 13:59:49 Today_Hour14_GridConsumption 10 Wh
2025-03-05 13:59:49 Today_Hour14_GridFeedIn 783 Wh
2025-03-05 13:59:49 Today_Hour14_PVforecast 2861 Wh
2025-03-05 13:59:49 Today_Hour14_PVreal 3028 Wh
2025-03-05 14:59:49 Today_Hour15_BatIn_01 782 Wh
2025-03-05 14:59:49 Today_Hour15_BatOut_01 11 Wh
2025-03-05 14:59:49 Today_Hour15_GridConsumption 0 Wh
2025-03-05 14:59:49 Today_Hour15_GridFeedIn 834 Wh
2025-03-05 14:59:49 Today_Hour15_PVforecast 2920 Wh
2025-03-05 14:59:49 Today_Hour15_PVreal 2217 Wh
2025-03-05 15:59:49 Today_Hour16_BatIn_01 114 Wh
2025-03-05 15:59:49 Today_Hour16_BatOut_01 310 Wh
2025-03-05 15:59:49 Today_Hour16_GridConsumption 4 Wh
2025-03-05 15:59:49 Today_Hour16_GridFeedIn 469 Wh
2025-03-05 15:59:49 Today_Hour16_PVforecast 2260 Wh
2025-03-05 15:59:49 Today_Hour16_PVreal 1241 Wh
2025-03-05 16:59:49 Today_Hour17_BatIn_01 30 Wh
2025-03-05 16:59:49 Today_Hour17_BatOut_01 521 Wh
2025-03-05 16:59:49 Today_Hour17_GridConsumption 45 Wh
2025-03-05 16:59:49 Today_Hour17_GridFeedIn 39 Wh
2025-03-05 16:59:49 Today_Hour17_PVforecast 1271 Wh
2025-03-05 16:59:49 Today_Hour17_PVreal 634 Wh
2025-03-05 17:59:55 Today_Hour18_BatIn_01 4 Wh
2025-03-05 17:59:55 Today_Hour18_BatOut_01 1487 Wh
2025-03-05 17:59:55 Today_Hour18_GridConsumption 28 Wh
2025-03-05 17:59:55 Today_Hour18_GridFeedIn 19 Wh
2025-03-05 17:59:55 Today_Hour18_PVforecast 148 Wh
2025-03-05 17:59:55 Today_Hour18_PVreal 362 Wh
2025-03-05 18:59:49 Today_Hour19_BatIn_01 0 Wh
2025-03-05 18:59:49 Today_Hour19_BatOut_01 476 Wh
2025-03-05 18:59:49 Today_Hour19_GridConsumption 29 Wh
2025-03-05 18:59:49 Today_Hour19_GridFeedIn 0 Wh
2025-03-05 18:59:49 Today_Hour19_PVreal 0 Wh
2025-03-05 19:59:51 Today_Hour20_BatIn_01 0 Wh
2025-03-05 19:59:51 Today_Hour20_BatOut_01 1815 Wh
2025-03-05 19:59:51 Today_Hour20_GridConsumption 15 Wh
2025-03-05 19:59:51 Today_Hour20_GridFeedIn 0 Wh
2025-03-05 19:59:51 Today_Hour20_PVreal 0 Wh
2025-03-05 20:59:56 Today_Hour21_BatIn_01 0 Wh
2025-03-05 20:59:56 Today_Hour21_BatOut_01 2084 Wh
2025-03-05 20:59:56 Today_Hour21_GridConsumption 13 Wh
2025-03-05 20:59:56 Today_Hour21_GridFeedIn 0 Wh
2025-03-05 20:59:56 Today_Hour21_PVreal 0 Wh
2025-03-05 21:08:20 Today_Hour22_BatIn_01 0 Wh
2025-03-05 21:08:20 Today_Hour22_BatOut_01 531 Wh
2025-03-05 21:08:20 Today_Hour22_GridConsumption 3 Wh
2025-03-05 21:08:20 Today_Hour22_GridFeedIn 0 Wh
2025-03-05 21:08:20 Today_Hour22_PVreal 0 Wh
2025-03-05 21:08:20 Today_MaxPVforecast 3931 Wh
2025-03-05 21:08:20 Today_MaxPVforecastTime 2025-03-05 12:00:00
2025-03-05 21:08:20 Today_PVdeviation 3.49 %
2025-03-05 21:08:20 Today_PVforecast 24530 Wh
2025-03-05 21:08:20 Today_PVreal 23674 Wh
2025-03-05 21:08:20 Today_SunRise 06:51
2025-03-05 21:08:20 Today_SunSet 18:04
2025-03-05 21:08:20 Tomorrow_ConsumptionForecast 2097 Wh
2025-03-05 21:08:20 Tomorrow_PVforecast 22897 Wh
2025-03-05 21:08:20 Tomorrow_SunRise 06:48
2025-03-05 21:08:20 Tomorrow_SunSet 18:05
2025-03-05 21:08:20 consumer01 name='SW_AU_Poolpumpe_2' state='off' mode='must' planningstate='suspended' info='kein max Überschuss für den aktuellen Tag gefunden'
2025-03-05 21:08:20 consumer01_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer01_currentPower 0 W
2025-03-05 21:08:20 consumer01_planned_start 05.03.2025 17:45:13
2025-03-05 21:08:20 consumer01_planned_stop 06.03.2025 03:45:13
2025-03-05 21:08:20 consumer02 name='STKD_UG_Luftentfeuchter_2' state='off' mode='can' planningstate='finished'
2025-03-05 21:08:20 consumer02_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer02_currentPower 0 W
2025-03-05 21:08:20 consumer02_planned_start 05.03.2025 08:36:22
2025-03-05 21:08:20 consumer02_planned_stop 05.03.2025 18:04:16
2025-03-05 21:08:20 consumer03 name='HT_WP_EnergyMeter' state='off' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-03-05 21:08:20 consumer03_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer03_currentPower 30.3 W
2025-03-05 21:08:20 consumer04 name='STKD_EG_Flur_Tablet_2' state='off' mode='must' planningstate='started' info='swoncond nicht erfüllt'
2025-03-05 21:08:20 consumer04_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer04_planned_start 10.06.2024 07:28:59
2025-03-05 21:08:20 consumer04_planned_stop 10.06.2024 21:21:00
2025-03-05 21:08:20 consumer05 name='STKD_EG_Kueche_Kuehlschrank' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-03-05 21:08:20 consumer05_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer05_currentPower 80.3 W
2025-03-05 21:08:20 consumer06 name='STKD_EG_Kueche_Spuelmaschine' state='off' mode='can' planningstate='noSchedule'
2025-03-05 21:08:20 consumer06_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer06_currentPower 1.3 W
2025-03-05 21:08:20 consumer07 name='STKD_UG_FridgeBeverage' state='off' mode='must' planningstate='started'
2025-03-05 21:08:20 consumer07_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer07_currentPower 0 W
2025-03-05 21:08:20 consumer07_planned_start 12.06.2024 12:49:31
2025-03-05 21:08:20 consumer07_planned_stop 12.06.2024 21:23:00
2025-03-05 21:08:20 consumer08 name='n_IT_Keller_Energy' state='on' mode='can' planningstate='noSchedule'
2025-03-05 21:08:20 consumer08_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer08_currentPower 42.2 W
2025-03-05 21:08:20 consumer09 name='STKD_EG_Buero_IT' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-03-05 21:08:20 consumer09_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer09_currentPower 170 W
2025-03-05 21:08:20 consumer10 name='PM_UG_Trockner' state='off' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-03-05 21:08:20 consumer10_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer10_currentPower 0 W
2025-03-05 21:08:20 consumer11 name='PM_UG_Waschmaschine' state='off' mode='can' planningstate='noSchedule'
2025-03-05 21:08:20 consumer11_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer11_currentPower 0 W
2025-03-05 21:08:20 consumer12 name='STKD_UG_Lufttrockner' state='off' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-03-05 21:08:20 consumer12_ConsumptionRecommended 0
2025-03-05 21:08:20 consumer12_currentPower 0 W
2023-09-07 20:53:45 currentWeatherDev myDWD_Nbg_FH
2023-08-23 12:43:42 moduleDirection PV1=-37 PV2=143
2023-08-22 13:34:38 moduleTiltAngle PV1=55 PV2=55
2025-03-05 21:08:20 nextCycletime 21:08:40
2025-03-05 08:00:01 pvCorrectionFactor_08 1.67 (automatic - old factor: 1.17, AI result used, Sun Alt range: 5, Cloud range: 15, Days in range: 3)
2025-03-05 09:00:04 pvCorrectionFactor_09 1.59 (automatic - old factor: 1.50, Sun Alt range: 15, Cloud range: 10, Days in range: 2)
2025-03-05 10:00:04 pvCorrectionFactor_10 1.05 (automatic - old factor: 1.14, Sun Alt range: 25, Cloud range: 10, Days in range: 3)
2025-03-05 11:00:04 pvCorrectionFactor_11 1.03 (automatic - old factor: 0.99, AI result used, Sun Alt range: 30, Cloud range: 10, Days in range: 2)
2025-03-05 12:00:04 pvCorrectionFactor_12 0.88 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 00, Days in range: 1)
2025-03-05 13:00:04 pvCorrectionFactor_13 1.02 (automatic - old factor: 1.12, Sun Alt range: 35, Cloud range: 05, Days in range: 1)
2025-03-05 14:00:00 pvCorrectionFactor_14 1.03 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 10, Days in range: 1)
2025-03-05 15:00:02 pvCorrectionFactor_15 0.88 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 10, Days in range: 1)
2025-03-05 16:00:04 pvCorrectionFactor_16 0.78 (automatic - old factor: 1.00, AI result used, Sun Alt range: 20, Cloud range: 10, Days in range: 1)
2025-03-05 17:00:04 pvCorrectionFactor_17 0.75 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 10, Days in range: 1)
2025-03-05 18:00:06 pvCorrectionFactor_18 1.50 (automatic - old factor: 1.00, AI result used, Sun Alt range: 5, Cloud range: 05, Days in range: 1)
2025-03-05 21:08:20 pvCorrectionFactor_Auto on_complex_ai
2024-08-15 14:07:31 setupStringAzimuth PV1=-37 PV2=143
2024-08-15 14:07:31 setupStringDeclination PV1=55 PV2=55
2025-03-05 21:08:20 special_BatPowerIn_Sum 0 W
2025-03-05 21:08:20 special_BatPowerOut_Sum 712 W
2025-03-05 21:08:20 special_SunHours_Remain 0.00
2025-03-05 21:08:20 special_SunMinutes_Remain 0
2025-03-05 21:08:20 special_allStringsFullfilled 1
2025-03-05 21:08:20 special_conForecastTillNextSunrise -
2025-03-05 21:08:20 special_dayAfterTomorrowPVforecast 24321 Wh
2025-03-05 21:08:20 special_daysUntilBatteryCare_01 -
2025-03-05 21:08:20 special_runTimeCentralTask 0.0524 s
2025-03-05 21:08:20 special_runTimeLastAPIAnswer -
2025-03-05 21:08:20 special_runTimeLastAPIProc -
2025-03-05 21:08:20 special_runTimeTrainAI 0.5046 s
2025-03-05 21:08:20 special_todayBatIn_01 9180.0 Wh
2025-03-05 21:08:20 special_todayBatOut_01 7486.0 Wh
2025-03-05 21:08:20 special_todayConForecastTillSunset 0 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_01 1050 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_02 981 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_03 1049 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_04 953 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_05 784 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_06 732 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_07 1856 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_08 1559 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_09 238 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_10 2007 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_11 2475 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_12 2242 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_13 1340 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_14 1148 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_15 552 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_16 401 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_17 738 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_18 886 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_19 400 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_20 201 Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_21 - Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_22 - Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_23 - Wh
2025-03-05 21:08:20 special_todayConsumptionForecast_24 - Wh
2025-03-05 21:08:20 special_todayGridConsumption 12013 Wh
2025-03-05 21:08:20 special_todayGridFeedIn 2286.0 Wh
2025-03-05 21:08:21 state updated
hmccu:
Attributes:
DbLogExclude [A-L].*,Next.*,Today_H.*,Today_S.*,[a-r].*,state
affectBatteryPreferredCharge 20
consumer01 SW_AU_Poolpumpe_2 type=other power=200 mode=must icon=sani_pump mintime=600 on=on off=off notbefore=7 notafter=21 locktime=300:1800 interruptable=1 pcurr=pCurr:W auto=pvAuto noshow=noshow
consumer02 STKD_UG_Luftentfeuchter_2 type=other power=220 mode=can icon=humidity mintime=SunPath:100:0 on=on off=off locktime=600:300 interruptable=1 pcurr=pCurr:W auto=pvAuto noshow=noshow
consumer03 HT_WP_EnergyMeter power=3000 type=noSchedule icon=sani_heating_heatpump pcurr=power_sum:W:100 etotal=energy_total:Wh swstate=wp_Active:1:0 noshow=noshow
consumer04 STKD_EG_Flur_Tablet_2 type=other power=20 mode=must icon=measure_battery_100 mintime=sunpath on=on swstate=state:on:off auto=pvAuto swoncond=di_Tablet_Charge:canCharge:1 noshow=noshow
consumer05 STKD_EG_Kueche_Kuehlschrank power=250 type=noSchedule icon=gefrierschrank pcurr=power:W:20 etotal=energy_total:Wh swstate=Consumer_Active:1:0 noshow=noshow
consumer06 STKD_EG_Kueche_Spuelmaschine power=2200 type=noSchedule icon=scene_dishwasher pcurr=power:W:8 etotal=energy_total:Wh swstate=Consumer_Active:1:0 noshow=noshow
consumer07 STKD_UG_FridgeBeverage power=150 type=noSchedule mode=must mintime=sunpath on=on icon=kuehlschrank_small pcurr=power:W:20 etotal=energy_total:Wh swstate=state:on:off auto=pvAuto noshow=noshow swoncond=di_Getraenke_KS_Switch:CanCool:1 locktime=300:300 interruptable=1
consumer08 n_IT_Keller_Energy power=130 type=noSchedule icon=it_nas pcurr=power:W:20 etotal=energy_total:Wh swstate=Consumer_Active:1:0 noshow=noshow
consumer09 STKD_EG_Buero_IT power=500 type=noSchedule icon=it_pc pcurr=power:W:20 etotal=energy_total:Wh swstate=Consumer_Active:1:0 noshow=noshow
consumer10 PM_UG_Trockner power=1000 type=noSchedule icon=scene_clothes_dryer pcurr=power:W:5 etotal=energy_total:Wh swstate=Consumer_Active:1:0 noshow=noshow
consumer11 PM_UG_Waschmaschine power=2200 type=noSchedule icon=scene_washing_machine pcurr=power:W:5 etotal=energy_total:Wh swstate=Consumer_Active:1:0 noshow=noshow
consumer12 STKD_UG_Lufttrockner power=500 type=noSchedule icon=Ventilator_wind pcurr=power:W:20 etotal=energy_total:Wh swstate=Consumer_Active:1:0 noshow=noshow
ctrlConsRecommendReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16
ctrlGenPVdeviation continuously
ctrlInterval 20
ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,conForecastTillNextSunrise,dayAfterTomorrowPVforecast,daysUntilBatteryCare_01,runTimeCentralTask,runTimeLastAPIAnswer,runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatOut_01,todayConForecastTillSunset,todayConsumptionForecast,todayGridConsumption,todayGridFeedIn
event-min-interval .*:3600
event-on-change-reading .*runTime.*:0.3,.*special_.*:50,.*
flowGraphicControl size=400 animate=1 consumerdist=100 showconsumer=1 showconsumerremaintime=0
graphicBeam1Content pvReal
graphicBeam2Content pvForecast
graphicBeam3Content consumption
graphicBeam4Content consumptionForecast
graphicHeaderOwnspec PV-Überschuss:Current_Surplus Autarkie:Current_AutarkyRate Eigenverbrauch:Current_SelfConsumption Eigenverbrauchsrate:Current_SelfConsumptionRate Überschuss:Current_Surplus
graphicHistoryHour 8
graphicShowDiff bottom
graphicShowNight 1
group solar_overview
room Solar
setupBatteryDev01 di_LGESS_Battery pin=pin:W pout=pout:W intotal=intotal:Wh outtotal=outtotal:Wh charge=charge
setupInverterDev01 myLGESS pv=/essinfo/home/statistics/pcs_pv_total_power:W etotal=totalPVGenSum:Wh capacity=10000
setupInverterStrings PV1,PV2
setupMeterDev myLGESS gcon=gridBuy:W contotal=totalGridBuy:Wh gfeedin=gridSell:W feedtotal=totalGridSell:Wh conprice=conprice:€ feedprice=price_sell_kwh:€
setupRadiationAPI myDWD_Nbg_FH
setupStringPeak PV1=4.32 PV2=2.16
setupWeatherDev1 myDWD_Nbg_FH
sortby 1
userReadings html:nextCycletime.* { FHEM::SolarForecast::pageAsHtml ('mySolarForeCast', '-', 'flow_noHead_noCons') }
Fällt dir auf Anhieb was zur Ursache ein?
Edit: Grad gesehen, bei den gleichen debugLog aufrufen in Zeilen 12252 und 12297 kommt die selbe Warning.
BTW: Bei FHEM Neustart bekomme ich zudem immer
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13503.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13503.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13236.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13236.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13656.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13656.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13657.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13657.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13985.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13985.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14060.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14060.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13904.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13904.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14584.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14584.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14585.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14585.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14586.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14586.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14587.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14587.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14588.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14588.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14626.
2025.03.05 20:50:12 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 14626.
Bin aber noch nicht dahintergestiegen, woran das liegen kann . Eventuell hast du eine Idee. Danke!
Hallo tobi,
das ist aber nicht die V aus dem contrib.
Die Zeile in dieser Version ist nur " # Legende unten" und die Zeile 13236 ist leer.
Nee, sorry. offizielles Update.
Aber ich kann die Version aus dem Contrib gern mal einspielen und rückmelden.
Kann es sein das da das KI-Training fehlte und deshalb "nichts" gefunden wurde,
->> Ich hab in den letzten Tagen ja immer wieder machmal tagsüber mehrfach vom contrib eine Download gemacht und getestet ?
@300P,
ist tatsächlich so dass es die ersten Werte sind die in dieser Konstellation aufgezeichnet wurden.
Trotzdem wundert mich die starke Abweichung.
Wir haben ja schon lange die Berechnungsroutine von pah im Einsatz und meine Vergleichsinstanz ohne jegliche Korrektur hat heute eine Abweichung auch von nur -1,5%.
Ich habe noch keine wirkliche Idee dazu. Sind deine Strings richtig eingerichtet bzgl. Ausrichtung und Neigung?
ja, die sind seit dem 30.1.02024 schon so eingerichtet:
setstate Forecast 2024-10-30 19:42:19 setupStringAzimuth GarageSE=-55 GarageNW=125 HausNW=125 HausSW=35 HausSE1=-55 HausSE2=-55
setstate Forecast 2024-10-30 19:37:38 setupStringDeclination GarageSE=40 GarageNW=40 HausNW=50 HausSW=50 HausSE1=50 HausSE2=50
ZitatKann es sein das da das KI-Training fehlte und deshalb "nichts" gefunden wurde,
->> Ich hab in den letzten Tagen ja immer wieder machmal tagsüber mehrfach vom contrib eine Download gemacht und getestet ?
Nein, es gibt Werte zumindest nach deinem pvHistory Auszug:
13 => pvapifc: 3052, pvaifc: 2352, pvfc: 2352, aihit: 1, pvrl: 3942
Ich glaube die Problematik bei dir ist die starke Gliederung der Strings und Einzelbestandteile. Die Kalkulation der API / KI ohne irgendwelche Vergleichswerte ist dadurch sehr ungenau.
Vllt. hilft es mehr Trees (mit der neuen Version) zu trainieren wenn du genügend RAM hast. Probier mal aiTreesPV=30 z.B.
15 Trees = Laufzeit in Sekunden: 14.54421
30 Trees = Laufzeit in Sekunden: 28.44452
Priobere mal was daraus wird :)
Trained AI Object contains an Ensemble of 30 trees (only the first Tree is printed out)
Tree: 1 -> Number of Rules: 2876 / Number of Nodes: 3847 / Depth: 5
Tree: 2 -> Number of Rules: 2887 / Number of Nodes: 3879 / Depth: 5
Tree: 3 -> Number of Rules: 2871 / Number of Nodes: 3869 / Depth: 5
Tree: 4 -> Number of Rules: 2878 / Number of Nodes: 3870 / Depth: 5
Tree: 5 -> Number of Rules: 2879 / Number of Nodes: 3876 / Depth: 5
Tree: 6 -> Number of Rules: 2880 / Number of Nodes: 3881 / Depth: 5
Tree: 7 -> Number of Rules: 2868 / Number of Nodes: 3861 / Depth: 5
Tree: 8 -> Number of Rules: 2881 / Number of Nodes: 3866 / Depth: 5
Tree: 9 -> Number of Rules: 2880 / Number of Nodes: 3872 / Depth: 5
Tree: 10 -> Number of Rules: 2884 / Number of Nodes: 3880 / Depth: 5
Tree: 11 -> Number of Rules: 2876 / Number of Nodes: 3857 / Depth: 5
Tree: 12 -> Number of Rules: 2880 / Number of Nodes: 3868 / Depth: 5
Tree: 13 -> Number of Rules: 2882 / Number of Nodes: 3858 / Depth: 5
Tree: 14 -> Number of Rules: 2878 / Number of Nodes: 3880 / Depth: 5
Tree: 15 -> Number of Rules: 2874 / Number of Nodes: 3876 / Depth: 5
Tree: 16 -> Number of Rules: 2890 / Number of Nodes: 3888 / Depth: 5
Tree: 17 -> Number of Rules: 2872 / Number of Nodes: 3847 / Depth: 5
Tree: 18 -> Number of Rules: 2872 / Number of Nodes: 3855 / Depth: 5
Tree: 19 -> Number of Rules: 2880 / Number of Nodes: 3867 / Depth: 5
Tree: 20 -> Number of Rules: 2865 / Number of Nodes: 3843 / Depth: 5
Tree: 21 -> Number of Rules: 2876 / Number of Nodes: 3889 / Depth: 5
Tree: 22 -> Number of Rules: 2888 / Number of Nodes: 3871 / Depth: 5
Tree: 23 -> Number of Rules: 2885 / Number of Nodes: 3876 / Depth: 5
Tree: 24 -> Number of Rules: 2876 / Number of Nodes: 3860 / Depth: 5
Tree: 25 -> Number of Rules: 2882 / Number of Nodes: 3874 / Depth: 5
Tree: 26 -> Number of Rules: 2871 / Number of Nodes: 3855 / Depth: 5
Tree: 27 -> Number of Rules: 2890 / Number of Nodes: 3896 / Depth: 5
Tree: 28 -> Number of Rules: 2886 / Number of Nodes: 3864 / Depth: 5
Tree: 29 -> Number of Rules: 2884 / Number of Nodes: 3867 / Depth: 5
Tree: 30 -> Number of Rules: 2881 / Number of Nodes: 3876 / Depth: 5
Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen
letztes KI-Training: 05.03.2025 21:42:00 / Laufzeit in Sekunden: 28.44452
letzte KI-Ergebnis Generierungsdauer: 0.42 ms
Zitat von: tobi01001 am 05 März 2025, 21:26:07Nee, sorry. offizielles Update.
Aber ich kann die Version aus dem Contrib gern mal einspielen und rückmelden.
V: 76_SolarForecast.pm:v1.47.0-s29725/2025-03-05
Leide keine Besserung - kommen in unterschiedlicher Häufigkeit - 12357 am meisten:
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12357.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12363.
und jene hinsichtlich $FW_ME und $FW_subdir kommen auch während fhem start (und nur dann).
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12357.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12363.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13549.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13549.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13569.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13569.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13302.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 13302.
...
Kann das damit zu tun haben, dass ich mit einem
userReadings
html:nextCycletime.* { FHEM::SolarForecast::pageAsHtml ('mySolarForeCast', '-', 'flow_noHead_noCons') }mir für TabletUI die Übersicht erzeuge?
Also das
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12357.
2025.03.05 21:34:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12363.
sind nur Logausgaben. Und die Variablen $FW_ME und $FW_subdir sind zu dem Zeitpunkt X noch nicht initialisiert. Das sind FHEMWEB Variablen, d.h. das FHEMWEB Device ist noch nicht aktiv.
Es ist durchaus möglich dass es mit der Generierung für TabletUI zusammenhängt. Vllt. kannst du es mal temporär aussetzen nur um zu verfifizieren ob die Spur richtig ist.
Ja, mein Problem sind nicht die Debugmeldunghen als solche, sondern dass sie eben das Log-File fluten.
Die FhemWeb geschichten kommen nur beim start von Fhem. Das schau ich mir mal an.
Hier habe ich mal die Consumption_Long Debug-Option aktiviert. Dann passiert folgendes:
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> ################### Start Consumption forecast ###################
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> process Today dayname: Mi, Tomorrow dayname: Do
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
...
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> estimated cons of Hour 01: Wh, Considered value numbers:
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> estimated cons of Hour 02: Wh, Considered value numbers:
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12318.
...
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> store 'NextHour00' hod '23' confc: , confcEx:
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12363.
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> store circular/history hod '23' confc:
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12357.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12357.
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> store 'NextHour01' hod '24' confc: , confcEx:
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12363.
2025.03.05 22:21:41 1: mySolarForeCast DEBUG> store circular/history hod '24' confc:
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12357.
Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/76_SolarForecast.pm line 12357.
....
Warum der Forecast leer ist, weiß ich nicht. Vor dem Update war er das nicht und ist es auch nur für Verbrauch.
Unabhängig davon, sollte das "Fehlen" des Forecasts nicht das Log füllen, da das ja zumindest bei mir vielfach mit jedem Durchlauf passiert. Offenbar bin ich aber der einzige mit diesem Verhalten. Daher vermute ich das Problem eher zwischen Bildschirm und Stuhllehne - zumindest aber auf meiner Seite der Konfiguration.
ZitatOffenbar bin ich aber der einzige mit diesem Verhalten. Daher vermute ich das Problem eher zwischen Bildschirm und Stuhllehne - zumindest aber auf meiner Seite der Konfiguration.
Das hängt sicherlich mit einer speziellen Situation bei dir zusammen. Trotzdem muss das Problem beseitigt werden.
Schau ich mir an.
Naja, wahrscheinlich ist irgendwo was verloren gegangen.
Kann ich das z.B. mit set ... reset consumptionHistory neu initialisieren?
ZitatKann ich das z.B. mit set ... reset consumptionHistory neu initialisieren?
Kann man, ist aber hier jetzt nicht nötig. Solche Situationen können immer mal auftreten und müssen gehärtet werden.
Habe ein Update in mein Contrib geladen. Das sollte das Problem mit den Logausgaben beseitigen.
Probiers mal.
Zitat von: DS_Starter am 05 März 2025, 22:52:34Habe ein Update in mein Contrib geladen. Das sollte das Problem mit den Logausgaben beseitigen.
Probiers mal.
Schaut sehr gut aus:
2025.03.05 23:16:24 1: mySolarForeCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.03.05 23:16:24 1: mySolarForeCast DEBUG> store 'NextHour21' hod '21' confc: 2097, confcEx: 2097
2025.03.05 23:16:24 1: mySolarForeCast DEBUG> store 'NextHour22' hod '22' confc: 1027, confcEx: 1027
2025.03.05 23:16:24 1: mySolarForeCast DEBUG> store 'NextHour23' hod '23' confc: 686, confcEx: 686
2025.03.05 23:16:24 1: mySolarForeCast DEBUG> consumption calculated - day: 05, hod: 24, con: 386 Wh
2025.03.05 23:16:24 1: mySolarForeCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 33790 Wh
Es kommen nur noch die eigentlichen Logeinträge (hab ich jetzt wieder deaktiviert). Aber wo hast du denn die confc und confcEx hergezaubert? Die waren vorher nicht da....
Danke vielmals für die super schnelle Korrektur.
ZitatAber wo hast du denn die confc und confcEx hergezaubert? Die waren vorher nicht da....
Diese die du als Ausgabe siehst waren schon vorher da.
Aber es gibt in den Stunden < hod=21 keine Daten und diese fehlenden Daten verursachen die WARNINGS im Log.
Vermutlich ist der Spuk nach einem Tag, wenn alle hod durchlaufen wurden, wieder vorbei. Ist aber nebensächlich, die Logausgaben sind jetzt "gehärtet". ;)
Hallo Heiko,
ich habe noch zwei kleine Verbesserungsvorschläge für den Tooltip an der Batterieprognose. Siehe Screenshot anbei.
1) Sofern nur ein Batterie-Device konfiguriert ist, ist die erste Zeile aus meiner Sicht unnötig.
2) Sofern kein attr ctrlBatSocManagementXX definiert ist, ist auch die zweite Zeile aus meiner Sicht unnötig.
Wenn Du das auch so siehst und die beiden Zeilen sich leicht ausfiltern lassen, wäre die Oberfläche ein wenig schlanker.
Viele Grüße,
Peter
Guten Morgen !
Die Sonne scheint heute super bei uns ☀️- oder bei euch etwa nicht nicht ☀️
Meine heutige Frage wegen der schlechten Forecast-Werte bei mir:
DWD-Modul:
Ich habe seit Gestern das letzte Update von Heiko aus dem Contrib bei mir am rennen.
Kann es sein das meine DWD-Station seit bereits einigen Tagen Rad1h "verschweigt" und ich inzwischen deshalb heute gar keine Solarforcast mehr berechnet bekomme ?
Im Modul habe ich (vor dem Update auf die letzte Contrib-Version 1.17.7) die Version 1.17.5 vom Oktober genutzt.
Hier meine Properties vom DWD - geändert zuletzt im Sommer letzten Jahres:
attr DWD forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, RR1c, TTT, Tx, Tn, Tg, DD, FX1, RR6c, R600, RRhc, Rh00, ww, wwd, Neff
Leider - leider gestern extra dabei alle Readings gelöscht.
Da waren definitiv zu 100% aber Rad1h drin als Reading - aber welches Datum habe mir jedoch nicht gemerkt.
Heute wird nun gar nichts mehr im Forecast angezeigt.
Deshalb evtl. die immer größer werdenden Forecast-Abweichungen in den letzten Tagen bei mir (und heute gar nichts mehr)?
Sreenshot:
Allgemeine Ansicht. (kein Forecast - meine FCU rennt wie am Schnürchen deshalb)
AllPVforecastsToEvent Berechnungseintrag in Datenbank = 0
Ruß
300P
Hallo 300P,
jaaaa, wunderbar, die Sonne heute.
Ich benutze auch den DWD für die Solarprognose und bekomme aktuell noch Daten für meine forecastStation N2813.
Wann wurden denn die einzelnen Readings an Deinem DWD-device zuletzt aktualisiert?
Bei mir ist alles aktuell außer R101, siehe screen anbei. Wobei ich nicht weiß, wofür das genau verwendet wird.
Viele Grüße,
Peter
Zitat von: 300P am 06 März 2025, 09:35:25Kann es sein das meine DWD-Station seit bereits einigen Tagen Rad1h "verschweigt"
Zu Deiner Station kann ich nichts sagen, aber bei mir war das (vor vielen Monaten) auch so, dass die ausgewählte Station die Werte auf einmal nicht mehr geliefert hat. Da musste ich dann die API wechseln bzw. habe das zumindest gemacht, da andere Stationen zu weit weg schienen. Vom Gefühl her habe ich aber nie wieder die guten Vorhersagewerte erreicht. Sieht man am letzten Wochenende, da war 100% Sonne vorhergesagt und so war es auch. Da hat die Vorhersage vom Modul gut gepasst. Irgendwann probiere ich mal den Mix mit 2 DWD-Stationen zum Vergleich. Aktuell gibt es aber andere Baustellen.
Zitat von: peterboeckmann am 06 März 2025, 10:20:06Hallo 300P,
jaaaa, wunderbar, die Sonne heute.
Ich benutze auch den DWD für die Solarprognose und bekomme aktuell noch Daten für meine forecastStation N2813.
Wann wurden denn die einzelnen Readings an Deinem DWD-device zuletzt aktualisiert?
Bei mir ist alles aktuell außer R101, siehe screen anbei. Wobei ich nicht weiß, wofür das genau verwendet wird.
Viele Grüße,
Peter
Ich meine gesehen zu haben 3.2.2025 (bevor ich ??? :-[ gelöscht habe.....)
Erst einmal Wechsel ich auf deine Station - mal sehen ob dann bei mir was da an Daten kommt. O:-)
....und schwupps, mit Rad1h von dort habe ich wieder eine Vorschau (von einem anderen Ort)
Nachsatz:
Eindeutig die Ursache mit Rad1h
Naja - dann muss ich mir wohl eine neue DWD-Station in der Nähe suchen....
Gruß
300P
Hi,
@Peter,
Zitat1) Sofern nur ein Batterie-Device konfiguriert ist, ist die erste Zeile aus meiner Sicht unnötig.
Da gebe ich dir prinzipiell recht. Zum Einen müsste ich nur wegen der Anzeige noch mehr if/else Strukturen einbauen und zum Anderen ist es ein kleiner und sichtbarer Gegencheck ob man dort wirklich das richtige Device angegeben hat. Manche User haben zwar mehrere Batterien, legen aber (aus welchen Gründen auch immer) nur eine im SF an. Deswegen lasse ich es so.
Zitat2) Sofern kein attr ctrlBatSocManagementXX definiert ist, ist auch die zweite Zeile aus meiner Sicht unnötig.
Das stimmt auch und das lege ich mal in mein Backlog.
ZitatBei mir ist alles aktuell außer R101, siehe screen anbei. Wobei ich nicht weiß, wofür das genau verwendet wird.
Das R101 verwenden wir schon lange nicht mehr und wurde durch das RR1c (Gesamtniederschlag während der letzten Stunde) ersetzt.
Im DWD Wetterdevice verwenden wir: TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet
bzw. noch Rad1h wenn auch als Strahlungsdevice genutzt.
Auch heute wieder herrlichster Sonnenschein. Meine Bat hat erst vor einer halben Stunde mit der Aufladung begonnen (Netzdienlichkeit). Über Mittag waren viele Verbraucher (Küche) an. Lt. Prognose wird sie aber 14:00 trotzdem voll sein.
Die KI Treffer (mit 10 Trees) liegen auch wieder bei über 70% der PV Prognosen der nächsten Stunden. (Der Screen zeigt eine Instanz mit KI aber ohne Batteriemanagement - bevor ihr euch wundert wieso die Bat bereits um 11:00 voll sein soll)
Momentan gibt es tatsächlich nicht viel auszusetzen.
Hallo Heiko,
Zitat von: DS_Starter am 06 März 2025, 13:01:39Im DWD Wetterdevice verwenden wir: TTT,Neff,RR1c,ww,SunUp,SunRise,SunSet
bzw. noch Rad1h wenn auch als Strahlungsdevice genutzt.
Das habe ich in meinem dwd-Device jetzt angepasst.
Magst du es im Wiki auch noch aktualisieren?
Viele Grüße,
Peter
ZitatMagst du es im Wiki auch noch aktualisieren?
Hatte mich gerade gewundert ... den Abschnitt hat ein User beigesteuert und sein Konfigurationsbeispiel dargestellt.
Ich werde einen extra Abschnitt für die Wetter/Strahlungs-API's bzw. noch die ganze Thematik der Autokorrektur / KI einfügen. Dort finden sich solche Angaben auch wieder.
...ich wars.....vor längerer Zeit :-[ :-X
Zitat von: DS_Starter am 06 März 2025, 13:29:10ZitatHatte mich gerade gewundert ... den Abschnitt hat ein User beigesteuert und sein Konfigurationsbeispiel dargestellt.
Ich werde einen extra Abschnitt für die Wetter/Strahlungs-API's bzw. noch die ganze Thematik der Autokorrektur / KI einfügen. Dort finden sich solche Angaben auch wieder.
Zur Info beim Thema DWD - plötzlich fehlerhafte Werte bei dem Forecast - am Ende gab es sogar gar nichts mehr an Forecast
==>> Verursacht durch fehlenden Rad1h-Wert im DWD-Device (Globalstrahlung)
Heute ist es wieder etwas besser bei mir mit dem Forecast-Werten, aber erst nachdem ich am Nachmittag eine Station in meiner Nähe gefunden habe.
Puh - meine erste gefundenen Station war aber schon ganz schön weit weg.
Bislang Entfernung nur ca. 2-3 km. ;D
Jetzt sind es 25 km :o
Mal sehen wie die Trefferquote wird, wenn nicht müssen halt mehrere DWD-Stationen herhalten.
Habe aber später noch eine Station etwas "näher" gefunden - aber auch ca. 18 km weit weg.
PS:
Das ist ganz schön mühselig mit der Stationsnummer suchen
- DWDTest-Device damit füttern und dann schauen ob überhaupt der Rad1h Wert kommt...
- einige Stationen senden einfach auch nur den Wert 0 dauerhaft
- also aufpassen was man auswählt / nimmt.
Gruß
300P
Zitat...ich wars.....vor längerer Zeit :-[ :-X
Ertappt ... :D
Dann kannst du deinen Text ja mal anpassen wenn du alles wieder so hast wie gewünscht.
So, heute kann ich noch etwas zum Besten geben und eine Sektflasche öffnen.
Über den ganzen Tag gerechnet hat meine Vergleichsinstanz (DWD mit PV-Berechnungsroutine nach pah + trackFlex Methode = unser Standard) die sagenhafte Abweichung von 0 %.
Naja, nicht ganz. Es sind doch noch 4 Wh Differenz vorhanden. ;)
setstate SolDwd4 2025-03-06 18:44:40 Today_PVforecast 42450 Wh
setstate SolDwd4 2025-03-06 18:44:40 Today_PVreal 42446 Wh
Zitat von: DS_Starter am 06 März 2025, 18:55:02So, heute kann ich noch etwas zum Besten geben und eine Sektflasche öffnen.
Über den ganzen Tag gerechnet hat meine Vergleichsinstanz (DWD mit PV-Berechnungsroutine nach pah + trackFlex Methode = unser Standard) die sagenhafte Abweichung von 0 %.
Naja, nicht ganz. Es sind doch noch 4 Wh Differenz vorhanden. ;)
setstate SolDwd4 2025-03-06 18:44:40 Today_PVforecast 42450 Wh
setstate SolDwd4 2025-03-06 18:44:40 Today_PVreal 42446 Wh
Wow, das ist beeindruckend!
Bei mir waren es gestern -35,5%.
Ob das an den Prognosedaten des dwd-devices liegt? Oder mag da noch etwas entscheidendes in der Konfiguration anders sein?
Ich habe meine zwei Strings mit fast Ost-West-Ausrichtung im Verdacht.
Internals:
FUUID 651cfe6b-f33f-e199-c4fb-916e33f2d14b5241
FVERSION 76_SolarForecast.pm:v1.47.0-s29728/2025-03-06
LCACHEFILE last write time: 08:15:05 File: ./FHEM/FhemUtils/PVCsm_SolarForecast_SolarForecast
MODE Automatic / Event-controlled - next planned Cycletime: 08:20:28
MODEL DWD
NAME SolarForecast
NOTIFYDEV MQTT2_SmartMeterReader,KlimaanlagePwr,Klimaanlage_Sw,MQTT2_Luftentfeuchter,MQTT2_Spelunkenentfeuchter,MQTT2_ShellyGeschirrspueler,Trockner_Pwr,Trockner,Waschmaschine_Pwr,Waschmaschine,Stromverbrauch_Buero,Stromverbrauch_WoZi,MQTT2_KlimaODU,MQTT2_ShellyPlugKuechenKuehlschrank,MQTT2_PlugKaffeemaschine,MQTT2_ShellyPlugKellerKuehlschrank,ShellyplugSchuppen,HM_56DBA8_Sw_01,WallboxLeistungssumme,HM_35FA43_Sw_07,Enphase
NR 776
NTFY_ORDER 50-SolarForecast
STATE running
TYPE SolarForecast
WEATHERMODEL DWD
eventCount 569
HELPER:
14M15DONE 1
15M15DONE 1
16M15DONE 1
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV SolarForecast
SPGROOM
VERSION 1.47.0
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 38
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:10482
telnet telnetForBlockingFn_1741330791.59075_127.0.0.1_47700
terminated 1
timeout 30
abortArg:
arg:
block 1
name SolarForecast
tsnext 1741336475.47783
Helper:
DBLOG:
Current_AutarkyRate:
logdb:
TIME 1741331934.36306
VALUE 93.59318909913
LastHourPVforecast:
logdb:
TIME 1741332023.2537
VALUE 723
LastHourPVreal:
logdb:
TIME 1741332023.2537
VALUE 655
OLDREADINGS:
READINGS:
2025-03-07 08:20:27 Battery_ChargeRecommended_01 1
2025-03-07 08:20:27 Current_AutarkyRate 97 %
2025-03-07 08:20:27 Current_BatCharge_01 10 %
2025-03-07 08:20:27 Current_Consumption 676 W
2025-03-07 08:20:27 Current_GridConsumption 17 W
2025-03-07 08:20:27 Current_GridFeedIn 0 W
2025-03-07 08:20:27 Current_PV 1314 W
2025-03-07 08:20:27 Current_PowerBatIn_01 655 W
2025-03-07 08:20:27 Current_PowerBatOut_01 0 W
2025-03-07 08:20:27 Current_SelfConsumption 659 W
2025-03-07 08:20:27 Current_SelfConsumptionRate 50 %
2025-03-07 08:20:27 Current_Surplus 638 W
2025-03-07 08:20:27 Current_Surplus_Num 638
2025-03-07 08:00:00 LastHourGridconsumptionReal 123 Wh
2025-03-07 08:00:00 LastHourPVforecast 723 Wh
2025-03-07 08:00:00 LastHourPVreal 655 Wh
2025-03-07 08:20:27 NextHours_Sum01_PVforecast 1671 Wh
2025-03-07 08:20:27 NextHours_Sum02_PVforecast 4570 Wh
2025-03-07 08:20:27 NextHours_Sum03_PVforecast 7932 Wh
2025-03-07 08:20:27 NextHours_Sum04_ConsumptionForecast 3599 Wh
2025-03-07 08:20:27 NextHours_Sum04_PVforecast 10853 Wh
2025-03-07 08:20:27 RestOfDayConsumptionForecast 12187 Wh
2025-03-07 08:20:27 RestOfDayPVforecast 24355 Wh
2025-03-07 00:59:57 Today_Hour01_BatIn_01 0 Wh
2025-03-07 00:59:57 Today_Hour01_BatOut_01 505 Wh
2025-03-07 00:59:57 Today_Hour01_GridConsumption 41 Wh
2025-03-07 00:59:57 Today_Hour01_GridFeedIn 0 Wh
2025-03-07 00:59:57 Today_Hour01_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
2025-03-07 01:59:57 Today_Hour02_BatIn_01 0 Wh
2025-03-07 01:59:57 Today_Hour02_BatOut_01 472 Wh
2025-03-07 01:59:57 Today_Hour02_GridConsumption 47 Wh
2025-03-07 01:59:57 Today_Hour02_GridFeedIn 0 Wh
2025-03-07 01:59:57 Today_Hour02_PVreal 0 Wh
2025-03-07 02:59:57 Today_Hour03_BatIn_01 0 Wh
2025-03-07 02:59:57 Today_Hour03_BatOut_01 622 Wh
2025-03-07 02:59:57 Today_Hour03_GridConsumption 45 Wh
2025-03-07 02:59:57 Today_Hour03_GridFeedIn 1 Wh
2025-03-07 02:59:57 Today_Hour03_PVreal 0 Wh
2025-03-07 03:59:59 Today_Hour04_BatIn_01 0 Wh
2025-03-07 03:59:59 Today_Hour04_BatOut_01 472 Wh
2025-03-07 03:59:59 Today_Hour04_GridConsumption 50 Wh
2025-03-07 03:59:59 Today_Hour04_GridFeedIn 0 Wh
2025-03-07 03:59:59 Today_Hour04_PVreal 0 Wh
2025-03-07 04:59:58 Today_Hour05_BatIn_01 0 Wh
2025-03-07 04:59:58 Today_Hour05_BatOut_01 342 Wh
2025-03-07 04:59:58 Today_Hour05_GridConsumption 177 Wh
2025-03-07 04:59:58 Today_Hour05_GridFeedIn 0 Wh
2025-03-07 04:59:58 Today_Hour05_PVreal 0 Wh
2025-03-07 05:59:58 Today_Hour06_BatIn_01 0 Wh
2025-03-07 05:59:58 Today_Hour06_BatOut_01 4 Wh
2025-03-07 05:59:58 Today_Hour06_GridConsumption 453 Wh
2025-03-07 05:59:58 Today_Hour06_GridFeedIn 0 Wh
2025-03-07 05:59:58 Today_Hour06_PVreal 0 Wh
2025-03-07 06:59:59 Today_Hour07_BatIn_01 0 Wh
2025-03-07 06:59:59 Today_Hour07_BatOut_01 2 Wh
2025-03-07 06:59:59 Today_Hour07_GridConsumption 481 Wh
2025-03-07 06:59:59 Today_Hour07_GridFeedIn 0 Wh
2025-03-07 06:59:59 Today_Hour07_PVforecast 53 Wh
2025-03-07 06:59:59 Today_Hour07_PVreal 12 Wh
2025-03-07 07:59:54 Today_Hour08_BatIn_01 157 Wh
2025-03-07 07:59:54 Today_Hour08_BatOut_01 2 Wh
2025-03-07 07:59:54 Today_Hour08_GridConsumption 123 Wh
2025-03-07 07:59:54 Today_Hour08_GridFeedIn 3 Wh
2025-03-07 07:59:54 Today_Hour08_PVforecast 723 Wh
2025-03-07 07:59:54 Today_Hour08_PVreal 655 Wh
2025-03-07 08:20:27 Today_Hour09_BatIn_01 233 Wh
2025-03-07 08:20:27 Today_Hour09_BatOut_01 0 Wh
2025-03-07 08:20:27 Today_Hour09_GridConsumption 13 Wh
2025-03-07 08:20:27 Today_Hour09_GridFeedIn 1 Wh
2025-03-07 08:20:27 Today_Hour09_PVforecast 1222 Wh
2025-03-07 08:20:27 Today_Hour09_PVreal 433 Wh
2025-03-07 08:20:27 Today_Hour10_PVforecast 2506 Wh
2025-03-07 08:20:27 Today_Hour11_PVforecast 3630 Wh
2025-03-07 08:20:27 Today_Hour12_PVforecast 2864 Wh
2025-03-07 08:20:27 Today_Hour13_PVforecast 3027 Wh
2025-03-07 08:20:27 Today_Hour14_PVforecast 3012 Wh
2025-03-07 08:20:27 Today_Hour15_PVforecast 2693 Wh
2025-03-07 08:20:27 Today_Hour16_PVforecast 3512 Wh
2025-03-07 08:20:27 Today_Hour17_PVforecast 2106 Wh
2025-03-07 08:20:27 Today_Hour18_PVforecast 211 Wh
2025-03-07 08:20:27 Today_MaxPVforecast 3630 Wh
2025-03-07 08:20:27 Today_MaxPVforecastTime 2025-03-07 10:00:00
2025-03-07 08:20:27 Today_PVdeviation 9.88 %
2025-03-07 08:20:27 Today_PVforecast 25559 Wh
2025-03-07 08:20:27 Today_PVreal 1100 Wh
2025-03-07 08:20:27 Today_SunRise 06:47
2025-03-07 08:20:27 Today_SunSet 18:00
2025-03-07 08:20:27 Tomorrow_ConsumptionForecast 15961 Wh
2025-03-07 08:20:27 Tomorrow_PVforecast 29971 Wh
2025-03-07 08:20:27 Tomorrow_SunRise 06:45
2025-03-07 08:20:27 Tomorrow_SunSet 18:02
2025-03-07 08:20:27 consumer01 name='Klimaanlage' state='unknown' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer01_currentPower 0 W
2025-03-07 08:20:27 consumer02 name='Tageslichtlampe' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-03-07 08:20:27 consumer02_currentPower 34 W
2025-03-07 08:20:27 consumer03 name='Spelunkenentfeuchter' state='off' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer03_currentPower 0 W
2025-03-07 08:20:27 consumer04 name='Geschirrspüler' state='on' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer04_currentPower 0 W
2025-03-07 08:20:27 consumer05 name='Wäschetrockner' state='on' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer05_currentPower 0.04 W
2025-03-07 08:20:27 consumer06 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer06_currentPower 0.2 W
2025-03-07 08:20:27 consumer07 name='Büro' state='unknown' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer07_currentPower 93.6 W
2025-03-07 08:20:27 consumer08 name='Wohnzimmer' state='unknown' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer08_currentPower 249.5 W
2025-03-07 08:20:27 consumer09 name='Klimaaußengerät' state='off' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer09_currentPower 0 W
2025-03-07 08:20:27 consumer10 name='Küchen-Kühlschrank' state='on' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer10_currentPower 0 W
2025-03-07 08:20:27 consumer11 name='Kaffeemaschine, Toaster, Thermomix' state='on' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer11_currentPower 4.1 W
2025-03-07 08:20:27 consumer12 name='Kellerkühlschrank' state='on' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer12_currentPower 117.9 W
2025-03-07 08:20:27 consumer13 name='PlugSchuppen' state='off' mode='can' planningstate='noSchedule'
2025-03-07 08:20:27 consumer13_currentPower 0 W
2025-03-07 08:20:27 consumer14 name='Teichbelüfter' state='off' mode='can' planningstate='planned'
2025-03-07 08:20:27 consumer14_planned_start 07.03.2025 09:00:00
2025-03-07 08:20:27 consumer14_planned_stop 07.03.2025 10:00:00
2025-03-07 08:20:27 consumer15 name='WallboxLeistungssumme' state='on' mode='can' planningstate='suspended' info='max Überschußprognose zu gering'
2025-03-07 08:20:27 consumer15_currentPower 2.843 W
2025-03-07 08:20:27 consumer16 name='Skimmer' state='off' mode='can' planningstate='planned'
2025-03-07 08:20:27 consumer16_planned_start 07.03.2025 09:00:00
2025-03-07 08:20:27 consumer16_planned_stop 07.03.2025 10:00:00
2025-03-07 08:20:23 nextCycletime 08:20:28
2025-03-07 07:00:02 pvCorrectionFactor_07 1.13 (automatic - old factor: 1.44, AI result used, Sun Alt range: 0, Cloud range: 10, Days in range: 2)
2025-03-07 08:00:12 pvCorrectionFactor_08 1.65 (automatic - old factor: 1.75, AI result used, Sun Alt range: 5, Cloud range: 10, Days in range: 2)
2025-03-07 08:20:27 pvCorrectionFactor_Auto on_complex_ai
2024-08-24 17:13:20 setupStringAzimuth Osten=-127 Westen=53
2025-02-19 10:56:15 setupStringDeclination Osten=38 Westen=38
2025-03-07 08:20:27 special_todayBatInSum 390.0 Wh
2025-03-07 08:20:27 special_todayBatOutSum 2421.0 Wh
2025-03-07 08:20:27 special_todayConsumption 4539 Wh
2025-03-07 08:20:27 special_todayGridConsumption 1430 Wh
2025-03-07 08:20:27 special_todayGridFeedIn 5.9 Wh
2025-03-07 08:20:27 state running
Attributes:
DbLogExclude .*
DbLogInclude Current_AutarkyRate:60,AllPVforecastsToEvent,LastHourPVforecast,LastHourPVreal
affectConsForecastIdentWeekdays 1
affectConsForecastInPlanning 0
consumer01 KlimaanlagePwr switchdev=Klimaanlage_Sw type=noSchedule power=750 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=Ventilator_fett auto=Automatik interruptable=1
consumer02 MQTT2_Luftentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=light_ceiling auto=Automatik
consumer03 MQTT2_Spelunkenentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=Ventilator_fett auto=Automatik
consumer04 MQTT2_ShellyGeschirrspueler type=noSchedule power=1500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=scene_dishwasher auto=Automatik
consumer05 Trockner_Pwr switchdev=Trockner type=noSchedule power=450 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=scene_clothes_dryer auto=Automatik
consumer06 Waschmaschine_Pwr switchdev=Waschmaschine type=noSchedule power=1800 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=scene_washing_machine auto=Automatik
consumer07 Stromverbrauch_Buero type=noSchedule power=500 pcurr=pcurr:W etotal=etotal:Wh icon=scene_office auto=Automatik
consumer08 Stromverbrauch_WoZi type=noSchedule power=500 pcurr=pcurr:W etotal=etotal:Wh icon=scene_livingroom auto=Automatik
consumer09 MQTT2_KlimaODU type=noSchedule power=1500 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=frost auto=Automatik
consumer10 MQTT2_ShellyPlugKuechenKuehlschrank type=noSchedule power=100 pcurr=switch_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_big auto=Automatik
consumer11 MQTT2_PlugKaffeemaschine type=noSchedule power=2500 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=scene_cockle_stove auto=Automatik
consumer12 MQTT2_ShellyPlugKellerKuehlschrank type=noSchedule power=150 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_small auto=Automatik
consumer13 ShellyplugSchuppen type=noSchedule power=100 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=building_carport_socket auto=Automatik
consumer14 HM_56DBA8_Sw_01 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian
consumer15 WallboxLeistungssumme type=other power=11000 pcurr=power:W etotal=total:Wh on=on off=off auto=Automatik mintime=60 icon=wallbox exconfc=1
consumer16 HM_35FA43_Sw_07 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian
consumerLegend icon_bottom
ctrlDebug none
ctrlGenPVdeviation continuously
ctrlInterval 5
ctrlLanguage DE
ctrlSpecialReadings todayBatInSum,todayBatOutSum,todayConsumption,todayGridConsumption,todayGridFeedIn
event-aggregator Current_AutarkyRate:150:linear:mean
event-min-interval .*:300
event-on-change-reading .*
flowGraphicControl animate=1 consumerdist=110 showconsumerremaintime=0 h2consumerdist=50
graphicBeam1Content pvReal
graphicBeam2Content pvForecast
graphicBeam3Content consumptionForecast
graphicBeam4Content consumption
graphicBeamHeightLevel1 250
graphicBeamHeightLevel2 250
graphicHeaderDetail all
graphicHeaderOwnspec #Aktuell:
Überschuss:Current_Surplus
Einspeisung:Current_GridFeedIn
Netzbezug:Current_GridConsumption
Autarkie-Rate:Current_AutarkyRate
#Heute:
Erzeugt:Today_PVreal
Bezogen:special_todayGridConsumption
Eingespeist:special_todayGridFeedIn
Verbraucht:special_todayConsumption
#Batterie:
Status:Akkustatus@Enphase
SoC (%):StorageFullPercent@Enphase
Heute geladen:special_todayBatInSum
Heute entladen:special_todayBatOutSum
graphicHistoryHour 4
graphicHourStyle :00
graphicSelect both
graphicShowDiff bottom
graphicShowNight 1
room Garten->PV-Anlage
setupBatteryDev01 Enphase pin=StorageFeedIn:W pout=StorageConsumption:W intotal=StorageWhCharged:Wh outtotal=StorageWhDischarged:Wh charge=StorageFullPercent cap=7000 show=1 asynchron=1
setupInverterDev01 Enphase pv=wNowProduction:W etotal=whTodayProduction:Wh capacity=10000 asynchron=1
setupInverterStrings Osten,Westen
setupMeterDev MQTT2_SmartMeterReader gcon=Bezug:W contotal=ENERGY_Total:kWh gfeedin=Einspeisung:W feedtotal=ENERGY_Supply:kWh asynchron=1
setupRadiationAPI dwd
setupStringPeak Osten=4 Westen=6.4
setupWeatherDev1 dwd
Morgen Peter,
ja das ist beeindruckend, aber wirklich nicht der Normalzustand. Deswegen nicht davon irritieren lassen.
Ich persönlich bin der Ansicht, dass alles was <= 10 % absolut Top ist.
Abweichungen können verschiedenste Ursachen haben, die Vorhersage der Strahlung, die Wetterbedingungen ;eine einzelne Wolke bei sonst absolut klaren Himmel deren Schatten genau auf deine Anlage fällt macht die Prognose kaputt; die Anzahl der aufgezeichneten Werte die für die Korrektur und KI als Ausgangslage dienen, ein evtl. Schattenwurf und und und.
Und auch der Faktor Zeit, d.h. Geduld, um Daten zu sammeln spielt eine sehr große Rolle, besonders bei solchen Anlagen mit aufgeteilten Strings. Hier werden die geliefert Raw-Daten nicht so ideal sein.
Um dahinter zu kommen, muß man sich jede einzelne Stunde anschauen was die (Wetter) Prognose war und die Realität. Das kann man auch alles in der pvCircular/pvHistory nachvollziehhen. Vllt. schreibe ich mal einen Artikel dazu ins Wiki (Zeit haben ...). Und auch die Grafik zeigt die Stunden mit der höchsten Abweichung. Diese Stunden könnte man sich am Anfang mal genauer anschauen.
Wichtig ist natürlich zunächst dass die Richtung und Neigung sowie Leistungen deiner Strings richtig sind, also grundsätzlich die techn. Daten deiner Anlage. Aber die sehen soweit ok aus was ich sehen kann.
Also am Ball bleiben und sich weiter damit beschäftigen, macht ja auch Spaß. :)
Nur nicht verzweifeln wenn es mal nicht so (schnell) klappt wie erwartet oder es krasse Abweichungen gibt. Auch bei mir sind bei instabilen Wetterlagen durchaus mal deutliche Abweichungen vorhanden, auch zwischen den einzelnen Wettermodellen welche durch die API's geliefert werden. Jeder prophezeit dann oft etwas anderes. Wir tanzen halt auf einer sehr komplexen Veranstaltung und haben auch noch den völlig irren Anspruch eine stundengenaue PV-Prognose zu erstellen. ;)
LG,
Heiko
Nur mal als Gegenbeispiel.
Heute sagt die OpenMeteoDWD für die Stunden 07-10 eine 100% ige Bewölkung voraus, aber nur diese API.
Es ist stahlender wolkenloser Himmel ... tja Prognose kaputt für die ersten Stunden ... und natürlich erstmal falsche Werte für diese Wetterlage aufgezeichnet was sich durch die internen Algos (KI, Medianberechnung) wieder richten muß.
Hallo Heiko!
Heute mittag um 12 habe ich einen deutlichen Ausreißer nach unten in der Prognose.
Mit welchen Mitteln kann ich mir die für die Prognose dieser Stunde genutzten Daten (und evtl Berechnungen) ansehen?
Viele Grüße,
Peter
ZitatHeute mittag um 12 habe ich einen deutlichen Ausreißer nach unten in der Prognose.
Bei mir übrigens auch. ;)
Um tiefer in die Daten reinzugehen, ctrlDebug mit einem passenden Parameter nutzen.
Hier bringt vermutlich radiationProcess, apiProcess und aiData etwas, evtl. mit pvCorrectionRead.
Das ist wirklich ein weites und zeitraubendes Feld.
Da finde ich meinen Ausreißer noch markanter. Ich schau mal in die von dir genannten Debug-Kategorien...
Jetzt ist die Prognose mit dem Wechsel der Stunde aktualisiert worden.
Sieht schon viel besser aus.
Vermutlich hat dwd neue Daten geliefert.
Viele Grüße,
Peter
Bei mir auch. (vergleiche mit meinem Bild zuvor) :) Ist aber SolCast. Strahlungsdaten sind SolCast, Wetterdaten vom DWD.
Zitat von: DS_Starter am 07 März 2025, 09:25:30Ich persönlich bin der Ansicht, dass alles was <= 10 % absolut Top ist.
hatte gestern 2.8 % :D
Hier stand Käse ;D
Weiter machen!
Nachdem bekannterweise der DWD bei meiner Heimatstation ohne Grund den Rad1h nicht mehr übermittelte sah der Forecast bei mir zuletzt ja sehr chaotisch aus.
Heute sah es bei mir endlich auch wieder besser aus.
Das eine SF (für den Nachbarn) mit DWD (neue 2 Stationen etwas weiter weg) mit Rad1h
=>> statt -59,7 % gestern === nun heute 9,8 % (das sieht schon wieder gut aus) :) ;D 8)
Bei meinem eigenen SF bin ich wieder zurück auf OpenMeteoDWD-API (+ die alte DWD-Stationen für Wetter)
==>> statt -167,8 % gestern === nun heute 17,8 % (das wird sich hoffentlich noch besser einpendeln) ::) :)) O:-)
Na das wird schon. ;)
Kleiner Hinweis...
die Strahlungswerte von DWD (Device) und OpenMeteo_DWD sind nicht kompatibel. Es könnte also etwas dauern bis der Median-Algo das zurechtrappelt. Da du aber schon mal bei OpenMeteo warst, könnte es andererseits weniger Zeit benötigen. Theoretisch wäre ein "set <name> reset pvCorrection cached" möglich, aber das löscht alle bisher gelernten PV Forecast/real Daten, würde ich eher nicht tun. Die KI-Daten sind davon aber nicht! betroffen.
Ich melde mich nochmal mit dem Tagesergebnis von heute: -18,2%
Insgesamt nicht sooo schlecht, aber
screen.png
die drei Stunden mit größerer Abweichung sind mir erstmal unerklärlich.
Die reale Erzeugung hat um kurz nach 12 eine kleine Kerbe. Trotzdem ist das konstant gute Wetter hier deutlich zu erkennen:
screen2.png
Leider hatte ich die Debug-Ausgaben wieder ausgeschaltet. Hier die Ausgaben von ca. 10 Uhr heute:
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Osten< => 2025-03-07 12:00:00, 1771.4 Wh, Afactor: 1.07 (trackFlex)
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Westen< => 2025-03-07 12:00:00, 4609.1 Wh, Afactor: 1.74 (trackFlex)
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Osten< => 2025-03-07 13:00:00, 0.0 Wh, Afactor: 0.00 (trackFlex)
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Westen< => 2025-03-07 13:00:00, 4554.7 Wh, Afactor: 1.83 (trackFlex)
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Osten< => 2025-03-07 14:00:00, 0.0 Wh, Afactor: 0.00 (trackFlex)
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Westen< => 2025-03-07 14:00:00, 4232.5 Wh, Afactor: 1.86 (trackFlex)
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Osten< => 2025-03-07 15:00:00, 0.0 Wh, Afactor: 0.00 (trackFlex)
2025.03.07 09:58:17 1: SolarForecast DEBUG> DWD API - PV estimate String >Westen< => 2025-03-07 15:00:00, 3074.8 Wh, Afactor: 1.84 (trackFlex)
[...]
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 12 string Westen ->
Estimated PV generation (calc) => 3900.8 Wh
Estimated PV generation (raw) => 3900.8 Wh
Module Temp (calculated) => 31.85 °C
PV correction factor => 1.00
PV correction quality => -
String Peak => 6200 W
Win(+)/Loss(-) String Peak Power by Temp => -0.20 kWp
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 12 summary:
Cloudcover => 17
Forecasted temperature => 11.10 °C
PV Correction mode => on_complex_ai
PV generation forecast => 5726 Wh
Starttime => 2025-03-07 11:00:00
Total Rain last hour => 0.00 kg/m2
2025.03.07 09:58:17 1: SolarForecast DEBUG> Start AI result check for hod: 12
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 1: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 2: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 3: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 4: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 5: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 6: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 7: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 9: 2031
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI accurate result found: pvaifc: 2031 (hod: 12, sunaz: 165, sunalt: 30, Rad1h: 1380, wcc: 17, rr1c: 0.00, temp: 10)
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI Hit - accurate result used -> aiRulesNum: 14484, variance: 35, hod: 12, Rad1h: 1380, pvfc: 2031 Wh
2025.03.07 09:58:17 1: SolarForecast DEBUG> read parameters - fd: 0, hod: 13, Sun Altitude Bin: 30, Cloud range: 20, corrf: 1.00, quality: -
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 13 string Osten ->
Estimated PV generation (calc) => 1771.4 Wh
Estimated PV generation (raw) => 1771.4 Wh
Module Temp (calculated) => 32.65 °C
PV correction factor => 1.00
PV correction quality => -
String Peak => 3860 W
Win(+)/Loss(-) String Peak Power by Temp => -0.14 kWp
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 13 string Westen ->
Estimated PV generation (calc) => 4609.1 Wh
Estimated PV generation (raw) => 4609.1 Wh
Module Temp (calculated) => 32.65 °C
PV correction factor => 1.00
PV correction quality => -
String Peak => 6180 W
Win(+)/Loss(-) String Peak Power by Temp => -0.22 kWp
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 13 summary:
Cloudcover => 19
Forecasted temperature => 12.40 °C
PV Correction mode => on_complex_ai
PV generation forecast => 6380 Wh
Starttime => 2025-03-07 12:00:00
Total Rain last hour => 0.00 kg/m2
2025.03.07 09:58:17 1: SolarForecast DEBUG> Start AI result check for hod: 13
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 1: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 2: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 4: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 5: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 6: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 7: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 9: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 10: 3011
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI accurate result found: pvaifc: 3011 (hod: 13, sunaz: 182, sunalt: 30, Rad1h: 1490, wcc: 19, rr1c: 0.00, temp: 15)
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI Hit - accurate result used -> aiRulesNum: 14484, variance: 47, hod: 13, Rad1h: 1490, pvfc: 3011 Wh
2025.03.07 09:58:17 1: SolarForecast DEBUG> read parameters - fd: 0, hod: 14, Sun Altitude Bin: 30, Cloud range: 20, corrf: 1.00, quality: -
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 14 string Osten ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0.0 Wh
Module Temp (calculated) => 33.05 °C
PV correction factor => 1.00
PV correction quality => -
String Peak => 3860 W
Win(+)/Loss(-) String Peak Power by Temp => -0.14 kWp
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 14 string Westen ->
Estimated PV generation (calc) => 4554.7 Wh
Estimated PV generation (raw) => 4554.7 Wh
Module Temp (calculated) => 33.05 °C
PV correction factor => 1.00
PV correction quality => -
String Peak => 6170 W
Win(+)/Loss(-) String Peak Power by Temp => -0.23 kWp
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 14 summary:
Cloudcover => 21
Forecasted temperature => 13.30 °C
PV Correction mode => on_complex_ai
PV generation forecast => 4555 Wh
Starttime => 2025-03-07 13:00:00
Total Rain last hour => 0.00 kg/m2
2025.03.07 09:58:17 1: SolarForecast DEBUG> Start AI result check for hod: 14
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 1: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 3: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 4: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 6: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 7: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 8: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 9: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 10: 3387
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI accurate result found: pvaifc: 3387 (hod: 14, sunaz: 199, sunalt: 30, Rad1h: 1400, wcc: 21, rr1c: 0.00, temp: 15)
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI Hit - accurate result used -> aiRulesNum: 14484, variance: 74, hod: 14, Rad1h: 1400, pvfc: 3387 Wh
2025.03.07 09:58:17 1: SolarForecast DEBUG> read parameters - fd: 0, hod: 15, Sun Altitude Bin: 25, Cloud range: 25, corrf: 1.00, quality: -
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 15 string Osten ->
Estimated PV generation (calc) => 0.0 Wh
Estimated PV generation (raw) => 0.0 Wh
Module Temp (calculated) => 33.55 °C
PV correction factor => 1.00
PV correction quality => -
String Peak => 3850 W
Win(+)/Loss(-) String Peak Power by Temp => -0.15 kWp
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 15 string Westen ->
Estimated PV generation (calc) => 4232.5 Wh
Estimated PV generation (raw) => 4232.5 Wh
Module Temp (calculated) => 33.55 °C
PV correction factor => 1.00
PV correction quality => -
String Peak => 6150 W
Win(+)/Loss(-) String Peak Power by Temp => -0.25 kWp
2025.03.07 09:58:17 1: SolarForecast DEBUG> PV API estimate for today Hour 15 summary:
Cloudcover => 23
Forecasted temperature => 14.30 °C
PV Correction mode => on_complex_ai
PV generation forecast => 4232 Wh
Starttime => 2025-03-07 14:00:00
Total Rain last hour => 0.00 kg/m2
2025.03.07 09:58:17 1: SolarForecast DEBUG> Start AI result check for hod: 15
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 3: 2978
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 4: 3021
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 5: 3021
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 7: 3021
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 8: 3021
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 9: 3021
2025.03.07 09:58:17 1: SolarForecast DEBUG> got AI result from Tree number 10: 3021
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI accurate result found: pvaifc: 3015 (hod: 15, sunaz: 215, sunalt: 25, Rad1h: 1280, wcc: 23, rr1c: 0.00, temp: 15)
2025.03.07 09:58:17 1: SolarForecast DEBUG> AI Hit - accurate result used -> aiRulesNum: 14484, variance: 71, hod: 15, Rad1h: 1280, pvfc: 3015 Wh
Das sind echt ne Menge Daten. Da steig ich heute nicht mehr durch. Aber ich hab's hier schonmal für die Ewigkeit dokumentiert. Reindenken werde ich mich die nächsten Tage vielleicht mal.
Viele Grüße,
Peter
Ich warte einfach ab - nächste Woche soll ja auch noch einmal eine derbe Kältewelle kommen - mal sehen ob das so wird oder die Sonne scheint. ;D
Wahrscheinlich gilt die alte Bauernregel:
Wenn der Hahn kräht auf dem Mist,
dann ändert sich das Wetter - oder es bleibt wie es ist.
😉😇🤣
Ich habe soben die V 1.47.1 für das Update morgen früh nachgeschoben.
In der V ist Peters Vorschlag 2) aus #2213 umgesetzt.
@Peter, ich habe mir deine Debug Daten angeschaut und ich glaube eine Idee zu haben woher die beiden Einbrüche kommen _könnten_.
Es liegt möglicherweise an fehlenden Diffusionsanteilen wenn es einen wolkenlosen Himmel in Verbindung mit einem Sonnenstand gibt, bei dem der geometrische Flächenfaktor bezogen auf dein Ost/West-Ausrichtungen 0 ergibt.
Ich habe dir eine Version 1.47.2 ins contrib geladen. Kannst sie mal ziehen, restarten und morgen mal ausprobieren. Es wird ja wieder ein toller Sonnentag.
Zitat von: DS_Starter am 06 März 2025, 18:55:02So, heute kann ich noch etwas zum Besten geben und eine Sektflasche öffnen.
Über den ganzen Tag gerechnet hat meine Vergleichsinstanz (DWD mit PV-Berechnungsroutine nach pah + trackFlex Methode = unser Standard) die sagenhafte Abweichung von 0 %.
Naja, nicht ganz. Es sind doch noch 4 Wh Differenz vorhanden. ;)
setstate SolDwd4 2025-03-06 18:44:40 Today_PVforecast 42450 Wh
setstate SolDwd4 2025-03-06 18:44:40 Today_PVreal 42446 Wh
Ich liege bei diesem stabilen Wetter ebenso stabil < 10%. Meist irgendwas um die -3,5% bis -6,5%.
Entsprechende DWD Station ist Luftlinie < 5 km weg...
Wünsche ein sonniges und ertragreiches Wochenende.
Hallo Heiko,
Zitat von: DS_Starter am 07 März 2025, 22:37:24Ich habe dir eine Version 1.47.2 ins contrib geladen. Kannst sie mal ziehen, restarten und morgen mal ausprobieren. Es wird ja wieder ein toller Sonnentag.
Danke für Deine Bemühungen!
Ich habe mal einen Screenshot vor dem Update gemacht und einen danach.
Das scheint schon eine deutliche Verbesserung gebracht zu haben. 8)
Ich werde es mal weiter beobachten.
Viele Grüße,
Peter
Zitat von: DS_Starter am 07 März 2025, 20:52:35Ich habe soben die V 1.47.1 für das Update morgen früh nachgeschoben.
In der V ist Peters Vorschlag 2) aus #2213 umgesetzt.
Danke dafür! Gefällt mir sehr gut!
Moin Peter,
ZitatDas scheint schon eine deutliche Verbesserung gebracht zu haben. 8)
Freut mich, schauen wir mal. Falls du ai eingeschaltet hast, mach das erstmal aus.
Sonst wird die Prognose mit den KI Werten u.U. überlagert und man sieht nicht die echte Auswirkung der Anpassungen der V 1.47.2.
Moin Heiko!
Wann schläfst du eigentlich?
Zitat von: DS_Starter am 08 März 2025, 08:59:15Falls du ai eingeschaltet hast, mach das erstmal aus.
Ich habe von on_complex_ai auf on_complex umgeschaltet.
Und es sieht tatsächlich gleich noch mehr nach der Kurve aus, die ich erwarten würde.
Vielen Dank für den Tipp!
Viele Grüße,
Peter
ZitatWann schläfst du eigentlich?
Naja, dieses SF-Projekt ist mittlerweile schon eine Passion geworden und ich stecke sehr sehr viel Zeit hier hinein. Und wenn ich Ideen im Kopf habe treibt es mich aus aus dem Bett. ;)
Hallo Heiko,
tendenziell waren die Prognosen heute zu gering, aber relativ parallel zur realen Erzeugung. Siehe auch Screenshot anbei.
Sollte ich für morgen die AI wieder aktivieren?
Viele Grüße,
Peter
Ja, aber das sieht gut aus.
Es werden dementsprechende Korrekturfaktoren gerechnet die bei nächsten identischen "Event" zur Anwendung kommen.
Das erkennst du an den Readings:
setstate SolDwd 2025-03-08 07:00:03 pvCorrectionFactor_07 0.84 (automatic - old factor: 0.85, Sun Alt range: 0, Cloud range: 25, Days in range: 2)
setstate SolDwd 2025-03-08 08:00:04 pvCorrectionFactor_08 1.27 (automatic - old factor: 1.22, Sun Alt range: 5, Cloud range: 30, Days in range: 3)
setstate SolDwd 2025-03-08 09:00:04 pvCorrectionFactor_09 1.34 (automatic - old factor: 1.45, Sun Alt range: 15, Cloud range: 25, Days in range: 3)
setstate SolDwd 2025-03-08 10:00:04 pvCorrectionFactor_10 1.07 (automatic - old factor: 1.03, Sun Alt range: 25, Cloud range: 25, Days in range: 2)
setstate SolDwd 2025-03-08 11:00:04 pvCorrectionFactor_11 0.99 (automatic - old factor: 1.35, Sun Alt range: 30, Cloud range: 25, Days in range: 2)
setstate SolDwd 2025-03-08 12:00:04 pvCorrectionFactor_12 0.77 (automatic - old factor: 1.10, Sun Alt range: 35, Cloud range: 30, Days in range: 2)
setstate SolDwd 2025-03-08 13:00:02 pvCorrectionFactor_13 0.81 (automatic - old factor: 1.47, Sun Alt range: 35, Cloud range: 20, Days in range: 1)
setstate SolDwd 2025-03-08 14:00:04 pvCorrectionFactor_14 0.77 (automatic - old factor: 1.50, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate SolDwd 2025-03-08 15:00:04 pvCorrectionFactor_15 0.82 (automatic - old factor: 0.82, Sun Alt range: 30, Cloud range: 20, Days in range: 2)
setstate SolDwd 2025-03-08 16:00:04 pvCorrectionFactor_16 0.94 (automatic - old factor: 0.73, Sun Alt range: 20, Cloud range: 20, Days in range: 4)
setstate SolDwd 2025-03-08 17:00:04 pvCorrectionFactor_17 0.93 (automatic - old factor: 1.17, Sun Alt range: 15, Cloud range: 20, Days in range: 2)
setstate SolDwd 2025-03-08 18:00:04 pvCorrectionFactor_18 0.62 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 15, Days in range: 1)
z.B. 0.99 automatic - old factor: 1.35 -> neu gerechneter Faktor 0.99 (für das nächste Mal) gegenüber dem aktuell genutzten Faktor 1.35.
ZitatSollte ich für morgen die AI wieder aktivieren?
Wie du magst. Vllt. lässt du es nochmal ausgeschaltet und wir schauen morgen nochmal ob es sich wieder so gut darstellt wie heute. Dann würde ich die kleine Änderung im Code beibehalten.
Hallo Heiko,
hier meine Readings aus diesem Bereich für heute:
setstate SolarForecast 2025-03-08 09:00:04 pvCorrectionFactor_09 1.27 (automatic - old factor: 1.03, AI result used, Sun Alt range: 15, Cloud range: 15, Days in range: 2)
setstate SolarForecast 2025-03-08 10:00:00 pvCorrectionFactor_10 0.78 (automatic - old factor: 0.97, Sun Alt range: 20, Cloud range: 20, Days in range: 2)
setstate SolarForecast 2025-03-08 11:00:00 pvCorrectionFactor_11 0.85 (automatic - old factor: 0.83, Sun Alt range: 25, Cloud range: 15, Days in range: 3)
setstate SolarForecast 2025-03-08 12:00:05 pvCorrectionFactor_12 0.84 (automatic - old factor: 0.72, Sun Alt range: 30, Cloud range: 15, Days in range: 2)
setstate SolarForecast 2025-03-08 13:00:01 pvCorrectionFactor_13 0.83 (automatic - old factor: 0.72, Sun Alt range: 30, Cloud range: 15, Days in range: 2)
setstate SolarForecast 2025-03-08 14:00:00 pvCorrectionFactor_14 0.84 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 15, Days in range: 1)
setstate SolarForecast 2025-03-08 15:00:01 pvCorrectionFactor_15 0.92 (automatic - old factor: 1.04, Sun Alt range: 25, Cloud range: 15, Days in range: 2)
setstate SolarForecast 2025-03-08 16:00:01 pvCorrectionFactor_16 0.97 (automatic - old factor: 1.20, Sun Alt range: 20, Cloud range: 15, Days in range: 2)
setstate SolarForecast 2025-03-08 17:00:05 pvCorrectionFactor_17 0.92 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 15, Days in range: 1)
setstate SolarForecast 2025-03-08 18:00:03 pvCorrectionFactor_18 0.68 (automatic - old factor: 0.60, Sun Alt range: 5, Cloud range: 10, Days in range: 2)
Ich lasse die KI noch weiterhin aus und berichte morgen wieder.
Viele Grüße,
Peter
Kannst du auch nochmal eine Debugausgabe posten bei Gelegenheit?
Ich möchte nur nochmal vergleichen wie sich meine kleine Anpassung bei zwei Ost/West Strings darstellt. Ich habe nur Südlage.
Zitat von: DS_Starter am 08 März 2025, 19:03:58Kannst du auch nochmal eine Debugausgabe posten bei Gelegenheit?
Ich möchte nur nochmal vergleichen wie sich meine kleine Anpassung bei zwei Ost/West Strings darstellt. Ich habe nur Südlage.
Mach ich morgen vormittag.
Hallo Heiko,
Zitat von: DS_Starter am 08 März 2025, 19:03:58Kannst du auch nochmal eine Debugausgabe posten bei Gelegenheit?
anbei die Debug-Ausgaben in einer Datei, weil es im Code-Block zu viel würde.
Außerdem ein Screenshot der heutigen Prognose. Die Wetter-Zeile zeigt zwar leichte Bewölkung (zwischen 38 und 50), bei WetterOnline ist davon nichts zu sehen.
Viele Grüße,
Peter
Moin Peter,
vielen Dank für die Daten.
ZitatDie Wetter-Zeile zeigt zwar leichte Bewölkung (zwischen 38 und 50), bei WetterOnline ist davon nichts zu sehen.
Solche Unterschiede gibt es. Auch DWD_OpenData (API) und die ICON Modelle des DWD (OpenMeteoDWD) liefern u.U. andere Prognosedaten für die gleiche Umgebung.
Auch werden z.B. eine WetterID "0" (=wolkenloser Himmel) geliefert und Neff (die Bewölkung) hat einen Wert von ungleich "0", was ja eigentlich nicht zusammenpasst. Hier versuche ich aktuell ein Schema zu finden wie DWD an dieser Stelle agiert.
Wenn du tiefer einsteigen möchtest, ist diese Seite des DWD (https://www.dwd.de/DE/leistungen/opendata/hilfe.html) ein guter Startpunkt um zu weiteren Dokumenten zu verzweigen.
LG,
Heiko
Hallo Heiko,
den tieferen Einstieg lasse ich lieber weg.
Solange die Strahlungsprognose des DWD brauchbar ist, bin ich zufrieden.
Deswegen habe ich mich auch noch nicht mit Alternativen dazu befasst.
Ich stehe aber gerne für Tests und Debugausgaben zur Verfügung.
Viele Grüße,
Peter
Für heute 12:00 Uhr habe ich in der Grafik eine Vorhersage, die 14% über der Kapazität (Sumne der Inverter capacity) liegt und das bei Cloud: 70.
Die Stunde ist generell der Ausreißer heute. Muss ich mich auf die Suche nach einem Konfiguratiosfehler machen?
Wie sieht denn dein(e) Attr setupInverterDevXX aus?
Ich habe auch eine Frage.
Bei mir sind die Vorhersagewerte immer viel zu hoch.
Sie werden für den nächsten Tag angepasst, was am Ende der Grafik sieht.
Am nächstem morgen sind sie dann wieder viel zu hoch und werden erst nach dem Stundenwechsel, für die jeweils nächste Stunde, korrigiert.
Anbei ein Bild zu Verdeutlichung.
Mit freundlichen Grüßen
Edit:
Internals:
FUUID 67247ac1-f33f-d66d-4e77-94b6b4acd8c6944b
FVERSION 76_SolarForecast.pm:v1.47.1-s29734/2025-03-07
LCACHEFILE last write time: 11:15:41 whole Operating Memory
MODE Automatic / Event-controlled - next planned Cycletime: 11:29:33
MODEL DWD
NAME PV_forecast
NOTIFYDEV ShellyPro_3EM,Hyper2000,SE3500H
NR 1538
NTFY_ORDER 50-PV_forecast
STATE updated
TYPE SolarForecast
WEATHERMODEL DWD
eventCount 5694
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
SPGDETAIL
SPGDEV PV_forecast
SPGROOM
VERSION 1.47.1
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 3878
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:214617
telnet telnetPort_127.0.0.1_54314
terminated 1
timeout 30
abortArg:
arg:
block 1
name PV_forecast
tsnext 1741518317.05364
OLDREADINGS:
READINGS:
2025-03-09 11:29:03 Battery_ChargeRecommended_01 1
2025-03-09 11:29:03 Current_AutarkyRate 100 %
2025-03-09 11:29:03 Current_BatCharge_01 99 %
2025-03-09 11:29:03 Current_Consumption 434 W
2025-03-09 11:29:03 Current_GridConsumption 0 W
2025-03-09 11:29:03 Current_GridFeedIn 1012 W
2025-03-09 11:29:03 Current_PV 1870 W
2025-03-09 11:29:03 Current_PowerBatIn_01 424 W
2025-02-02 07:46:16 Current_PowerBatIn_02 75 W
2025-03-09 11:29:03 Current_PowerBatOut_01 0 W
2025-02-02 07:46:16 Current_PowerBatOut_02 0 W
2025-03-09 11:29:03 Current_SelfConsumption 434 W
2025-03-09 11:29:03 Current_SelfConsumptionRate 23 %
2025-03-09 11:29:03 Current_Surplus 1436 W
2025-03-09 11:00:00 LastHourGridconsumptionReal 584 Wh
2025-03-09 11:00:00 LastHourPVforecast 2752 Wh
2025-03-09 11:00:00 LastHourPVreal 1000 Wh
2025-03-09 11:29:03 NextHours_Sum01_PVforecast 3622 Wh
2025-03-09 11:29:03 NextHours_Sum02_PVforecast 7174 Wh
2025-03-09 11:29:03 NextHours_Sum03_PVforecast 10396 Wh
2025-03-09 11:29:03 NextHours_Sum04_ConsumptionForecast 2590 Wh
2025-03-09 11:29:03 NextHours_Sum04_PVforecast 12458 Wh
2025-03-09 11:29:03 RestOfDayConsumptionForecast 4175 Wh
2025-03-09 11:29:03 RestOfDayPVforecast 14497 Wh
2025-03-09 00:59:49 Today_Hour01_BatIn_01 0 Wh
2025-03-09 00:59:49 Today_Hour01_BatOut_01 0 Wh
2025-03-09 00:59:49 Today_Hour01_GridConsumption 182 Wh
2025-03-09 00:59:49 Today_Hour01_GridFeedIn 0 Wh
2025-03-09 00:59:49 Today_Hour01_PVreal 10 Wh
2025-03-09 01:59:49 Today_Hour02_BatIn_01 0 Wh
2025-03-09 01:59:49 Today_Hour02_BatOut_01 0 Wh
2025-03-09 01:59:49 Today_Hour02_GridConsumption 186 Wh
2025-03-09 01:59:49 Today_Hour02_GridFeedIn 0 Wh
2025-03-09 01:59:49 Today_Hour02_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
2025-03-09 02:59:50 Today_Hour03_BatIn_01 0 Wh
2025-03-09 02:59:50 Today_Hour03_BatOut_01 0 Wh
2025-03-09 02:59:50 Today_Hour03_GridConsumption 191 Wh
2025-03-09 02:59:50 Today_Hour03_GridFeedIn 0 Wh
2025-03-09 02:59:50 Today_Hour03_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
2025-03-09 03:59:49 Today_Hour04_BatIn_01 0 Wh
2025-03-09 03:59:49 Today_Hour04_BatOut_01 0 Wh
2025-03-09 03:59:49 Today_Hour04_GridConsumption 191 Wh
2025-03-09 03:59:49 Today_Hour04_GridFeedIn 0 Wh
2025-03-09 03:59:49 Today_Hour04_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
2025-03-09 04:59:49 Today_Hour05_BatIn_01 0 Wh
2025-03-09 04:59:49 Today_Hour05_BatOut_01 0 Wh
2025-03-09 04:59:49 Today_Hour05_GridConsumption 185 Wh
2025-03-09 04:59:49 Today_Hour05_GridFeedIn 0 Wh
2025-03-09 04:59:49 Today_Hour05_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
2025-03-09 05:59:49 Today_Hour06_BatIn_01 0 Wh
2025-03-09 05:59:49 Today_Hour06_BatOut_01 0 Wh
2025-03-09 05:59:49 Today_Hour06_GridConsumption 190 Wh
2025-03-09 05:59:49 Today_Hour06_GridFeedIn 0 Wh
2025-03-09 05:59:49 Today_Hour06_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
2025-03-09 06:59:49 Today_Hour07_BatIn_01 0 Wh
2025-03-09 06:59:49 Today_Hour07_BatOut_01 0 Wh
2025-03-09 06:59:49 Today_Hour07_GridConsumption 243 Wh
2025-03-09 06:59:49 Today_Hour07_GridFeedIn 0 Wh
2025-03-09 06:59:49 Today_Hour07_PVforecast 6 Wh
2025-03-09 06:59:49 Today_Hour07_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
2025-03-09 07:59:49 Today_Hour08_BatIn_01 0 Wh
2025-03-09 07:59:49 Today_Hour08_BatOut_01 0 Wh
2025-03-09 07:59:49 Today_Hour08_GridConsumption 147 Wh
2025-03-09 07:59:49 Today_Hour08_GridFeedIn 93 Wh
2025-03-09 07:59:49 Today_Hour08_PVforecast 184 Wh
2025-03-09 07:59:49 Today_Hour08_PVreal 420 Wh
2025-03-09 08:59:59 Today_Hour09_BatIn_01 0 Wh
2025-03-09 08:59:59 Today_Hour09_BatOut_01 0 Wh
2025-03-09 08:59:59 Today_Hour09_GridConsumption 472 Wh
2025-03-09 08:59:59 Today_Hour09_GridFeedIn 496 Wh
2025-03-09 08:59:59 Today_Hour09_PVforecast 720 Wh
2025-03-09 08:59:59 Today_Hour09_PVreal 820 Wh
2025-03-09 09:59:49 Today_Hour10_BatIn_01 0 Wh
2025-03-09 09:59:49 Today_Hour10_BatOut_01 0 Wh
2025-03-09 09:59:49 Today_Hour10_GridConsumption 616 Wh
2025-03-09 09:59:49 Today_Hour10_GridFeedIn 667 Wh
2025-03-09 09:59:49 Today_Hour10_PVforecast 1959 Wh
2025-03-09 09:59:49 Today_Hour10_PVreal 870 Wh
2025-03-09 10:59:49 Today_Hour11_BatIn_01 0 Wh
2025-03-09 10:59:49 Today_Hour11_BatOut_01 0 Wh
2025-03-09 10:59:49 Today_Hour11_GridConsumption 584 Wh
2025-03-09 10:59:49 Today_Hour11_GridFeedIn 902 Wh
2025-03-09 10:59:49 Today_Hour11_PVforecast 2752 Wh
2025-03-09 10:59:49 Today_Hour11_PVreal 1000 Wh
2025-03-09 11:29:03 Today_Hour12_BatIn_01 0 Wh
2025-03-09 11:29:03 Today_Hour12_BatOut_01 0 Wh
2025-03-09 11:29:03 Today_Hour12_GridConsumption 122 Wh
2025-03-09 11:29:03 Today_Hour12_GridFeedIn 581 Wh
2025-03-09 11:29:03 Today_Hour12_PVforecast 3570 Wh
2025-03-09 11:29:03 Today_Hour12_PVreal 680 Wh
2025-03-09 11:29:03 Today_Hour13_PVforecast 3674 Wh
2025-03-09 11:29:03 Today_Hour14_PVforecast 3431 Wh
2025-03-09 11:29:03 Today_Hour15_PVforecast 3013 Wh
2025-03-09 11:29:03 Today_Hour16_PVforecast 1110 Wh
2025-03-09 11:29:03 Today_Hour17_PVforecast 1203 Wh
2025-03-09 11:29:03 Today_Hour18_PVforecast 275 Wh
2025-03-09 11:29:03 Today_Hour19_PVforecast 6 Wh
2025-03-09 11:29:03 Today_MaxPVforecast 3674 Wh
2025-03-09 11:29:03 Today_MaxPVforecastTime 2025-03-09 12:00:00
2025-03-09 11:29:03 Today_PVdeviation 48.41 %
2025-03-09 11:29:03 Today_PVforecast 21903 Wh
2025-03-09 11:29:03 Today_PVreal 3800 Wh
2025-03-09 11:29:03 Today_SunRise 06:51
2025-03-09 11:29:03 Today_SunSet 18:13
2025-03-09 11:29:03 Tomorrow_ConsumptionForecast 5036 Wh
2025-03-09 11:29:03 Tomorrow_PVforecast 18293 Wh
2025-03-09 11:29:03 Tomorrow_SunRise 06:48
2025-03-09 11:29:03 Tomorrow_SunSet 18:14
2024-11-01 08:16:36 currentInverterDev SE3500H pv=AC_current_W:W etotal=gesamtPV:kWh capacity=3600
2024-11-01 07:59:28 currentRadiationAPI PV_forecast_weather
2024-11-01 07:57:43 inverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
2024-11-01 08:20:00 moduleAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
2024-11-01 08:22:24 moduleDeclination Vordach=40 Fahrradschuppen=25 Dach=45 Garten=15 Wintergarten=15
2024-11-01 08:20:38 modulePeakString Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.94
2025-03-09 11:29:03 nextCycletime 11:29:33
2025-03-09 08:00:03 pvCorrectionFactor_08 1.75 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 75, Days in range: 1)
2025-03-09 09:00:03 pvCorrectionFactor_09 0.82 (automatic - old factor: 1.00, AI result used, Sun Alt range: 15, Cloud range: 50, Days in range: 1)
2025-03-09 10:00:03 pvCorrectionFactor_10 0.44 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 40, Days in range: 1)
2025-03-09 11:00:03 pvCorrectionFactor_11 0.36 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 35, Days in range: 1)
2025-03-09 11:29:03 pvCorrectionFactor_Auto on_complex_ai
2025-02-01 21:37:19 setupStringAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
2025-02-01 21:37:20 setupStringDeclination Vordach=40 Fahrradschuppen=25 Dach=45 Garten=10 Wintergarten=15
2025-03-09 11:29:03 special_runTimeTrainAI 0.34828 s
2025-03-09 11:29:03 special_todayBatInSum 0.0 Wh
2025-03-09 11:29:03 special_todayBatOutSum 0.0 Wh
2025-03-09 11:29:03 special_todayConsumption 4367 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_01 184 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_02 188 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_03 187 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_04 186 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_05 188 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_06 190 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_07 229 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_08 308 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_09 491 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_10 466 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_11 782 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_12 1017 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_13 782 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_14 660 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_15 385 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_16 510 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_17 304 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_18 190 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_19 67 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_20 16 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_21 139 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_22 240 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_23 192 Wh
2025-03-09 11:29:03 special_todayConsumptionForecast_24 182 Wh
2025-03-09 11:29:04 state updated
Attributes:
DbLogExclude .*
affectConsForecastIdentWeekdays 1
affectConsForecastLastDays 31
aiControl aiTrainStart=6 aiStorageDuration=1825 aiTreesPV=5
ctrlGenPVdeviation continuously
ctrlInterval 30
ctrlLanguage DE
ctrlSpecialReadings runTimeTrainAI,todayBatInSum,todayBatOutSum,todayConsumption,todayConsumptionForecast
event-on-change-reading .*
graphicEnergyUnit Wh
graphicHeaderOwnspec #Batterie
in heute:special_todayBatIn
out heute:special_todayBatOut
graphicHistoryHour 23
graphicHourCount 24
graphicLayoutType double
graphicShowDiff bottom
graphicShowNight 0
room PV-Solar
setupBatteryDev01 Hyper2000 pin=properties_report_properties_outputPackPower:W pout=properties_report_properties_packInputPower:W cap=2000 charge=properties_report_properties_electricLevel show=1
setupInverterDev01 SE3500H pv=AC_current_W:W etotal=AC_Lifetime_Energy_production_kWh:kWh capacity=3600
setupInverterDev02 Hyper2000 pv=properties_report_properties_solarInputPower:W etotal=properties_report_packData_1_totalVol:Wh capacity=1200
setupInverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
setupMeterDev ShellyPro_3EM gcon=Active_Power_S:W contotal=Purchased_Energy_S:W gfeedin=-gcon feedtotal=Returned_Energy_S:W
setupRadiationAPI PV_forecast_weather
setupStringPeak Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.93
setupWeatherDev1 PV_forecast_weather
ZitatBei mir sind die Vorhersagewerte immer viel zu hoch.
Für einen ersten Eindruck bräuchten wir mal ein List von deinem SF-Device.
Zitat von: DS_Starter am 09 März 2025, 10:52:29Wie sieht denn dein(e) Attr setupInverterDevXX aus?
Kann jetzt gerade nicht mehr schauen, habe nur noch Internet, kein VPN.
Ist da etwas relevant außer "capacity"? Es sind 2 und die 14% bezogen sich auf die Summe der beiden Werte.
Zitat von: DS_Starter am 09 März 2025, 11:23:32Für einen ersten Eindruck bräuchten wir mal ein List von deinem SF-Device.
Ist oben mit angehängt
ZitatIst da etwas relevant außer "capacity"? Es sind 2 und die 14% bezogen sich auf die Summe der beiden Werte.
Nein. Achte darauf dass hier max. Leistung in Watt anzugeben ist.
Ansonsten ctrlDebug=radiationProcess anschalten, dann sieht man mehr.
@Shadow3561,
du hast 5 Strings und 2 Inverter ohne den Invertern die ihnen zugehörigen Strings zugeordnet zu haben:
setupInverterDev01 SE3500H pv=AC_current_W:W etotal=AC_Lifetime_Energy_production_kWh:kWh capacity=3600
setupInverterDev02 Hyper2000 pv=properties_report_properties_solarInputPower:W etotal=properties_report_packData_1_totalVol:Wh capacity=1200
setupInverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
setupStringPeak Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.93
Dadurch verwenden beide Inverter alle Strings. Das ist wahrscheinlich so nicht korrekt. Überprüfe das mal.
Danke,
Ich habe es geändert und werde weiter beobachten.
Ich wünsche dir und Alen mitlesenden einen schönen, sonnigen Sonntag
Heut hab ich auch einen Ausreisser ...
mit OpenMeteoDWDEnsemble-API und SF 1.47.1
Vermutlich ist capacity im setupInverterDevXX nicht (richtig?) gesetzt in Verbindung mit einem irrealen Korrekturfaktor der sich mal eingeschlichen hat.
Ein "get ... forecastQualities" gibt einen Überblick über die Faktoren + Erwartungen.
Start: 2025-03-09 13:00:00, Quality: -, Factor: 1.00, AI usage: 1, PV expect: 5115 Wh, Sun Alt: 33, Cloud: 0
Start: 2025-03-09 14:00:00, Quality: 0.93, Factor: 0.94, AI usage: 1, PV expect: 4720 Wh, Sun Alt: 28, Cloud: 0
Start: 2025-03-09 15:00:00, Quality: 0.97, Factor: 0.97, AI usage: 1, PV expect: 4660 Wh, Sun Alt: 22, Cloud: 0
Start: 2025-03-09 16:00:00, Quality: 0.96, Factor: 0.96, AI usage: 1, PV expect: 3054 Wh, Sun Alt: 14, Cloud: 0
Start: 2025-03-09 17:00:00, Quality: -, Factor: 1.00, AI usage: 0, PV expect: 487 Wh, Sun Alt: 5, Cloud: 17
Start: 2025-03-10 06:00:00, Quality: 0.29, Factor: 2.34, AI usage: 1, PV expect: 2 Wh, Sun Alt: -10, Cloud: 100
Start: 2025-03-10 07:00:00, Quality: 0.83, Factor: 0.86, AI usage: 1, PV expect: 370 Wh, Sun Alt: -1, Cloud: 100
Start: 2025-03-10 08:00:00, Quality: 0.38, Factor: 0.62, AI usage: 1, PV expect: 1100 Wh, Sun Alt: 7, Cloud: 100
Start: 2025-03-10 09:00:00, Quality: 1.00, Factor: 1.00, AI usage: 1, PV expect: 4930 Wh, Sun Alt: 15, Cloud: 95
Start: 2025-03-10 10:00:00, Quality: 0.91, Factor: 1.10, AI usage: 1, PV expect: 4308 Wh, Sun Alt: 20, Cloud: 0
Start: 2025-03-10 11:00:00, Quality: -, Factor: 0.94, AI usage: 1, PV expect: 6371 Wh, Sun Alt: 23, Cloud: 35
Start: 2025-03-10 12:00:00, Quality: -, Factor: 0.95, AI usage: 1, PV expect: 5280 Wh, Sun Alt: 25, Cloud: 69
Start: 2025-03-10 13:00:00, Quality: -, Factor: 1.00, AI usage: 1, PV expect: 4460 Wh, Sun Alt: 23, Cloud: 34
Start: 2025-03-10 14:00:00, Quality: 0.77, Factor: 1.30, AI usage: 1, PV expect: 4717 Wh, Sun Alt: 19, Cloud: 56
Start: 2025-03-10 15:00:00, Quality: -, Factor: 1.00, AI usage: 1, PV expect: 2810 Wh, Sun Alt: 14, Cloud: 83
Start: 2025-03-10 16:00:00, Quality: 0.33, Factor: 0.60, AI usage: 1, PV expect: 1175 Wh, Sun Alt: 6, Cloud: 100
Start: 2025-03-10 17:00:00, Quality: 0.86, Factor: 1.16, AI usage: 1, PV expect: 333 Wh, Sun Alt: -2, Cloud: 100
Hallo,
mir ist gerade aufgefallen das es zur verwirrung führen kann das der Batterieladezustand über dem Balken angeortnet ist.
Wäre es nicht stimmiger wenn die Anzeige unter den Balken wäre?
Wie man auf dem einen Scrennshot sieht wird man verleitet die Zeit falsch zuzuweisen.
Oben ist die Vorhersage des Ertrages und unten die Vorhersage des Verbrauches.
Wenn ich das Batteriesymbol auf das untere Balkendiagram lege stiftet das Verwirrung.
Screenshot 2025-03-09 150722.png
Screenshot 2025-03-09 150818.png
Hallo kask,
ich gebe zu dass die visuelle Zuordnung in den gezeigten Fällen nicht so eindeutig ist.
Zwangsweise nach unten setzen würde ich die Bat-Leiste nicht wollen, evtl. einen zusätzlichen Parameter im Schlüssel show, also z.B. show=1[:below] oder so.
Alternativ tendiere ich dazu zwischen den Ebenen einen Trenner, eine Linie oder Freiplatz etc., einzufügen um die Ebenen besser visuell voneinander zu trennen. Es könnte nämlich sein, dass wir noch eine optionale dritte Ebene einfügen um noch mehr Werte visualisieren zu können. Wir haben ja bereits jetzt 9 Content-Möglichkeiten zur Auswahl. Weiterhin könnte es sein, dass auch die Wetterleiste wahlweise in anderen Ebenen dargestellt werden kann.
Kurzum, eine bessere visuelle Trennung der Ebenen sehe ich als wünschenswert an.
Vllt. hast du dazu auch eine Idee.
LG,
Heiko
Hallo Heiko,
Heute das gleiche Bild wie gestern. Die Vorhersage war für jede Stunde zu hoch - insgesamt 21 Prozent. Siehe Screenshot anbei.
Auch für morgen scheint die Prognose zu hoch. Da sollen ca. 10 Prozent mehr erzeugt werden als heute (33kWh ggü. 30 kWh heute), obwohl Nebel und Wolken vorhergesagt sind.
Soll ich dir noch irgendwelche Detail-Daten schicken?
Ich würde dann wieder die KI mit aktivieren?
Edit: mit aktivierter KI geht die Prognose für morgen prompt runter auf 27,7 kWh.
Viele Grüße,
Peter
Hallo Peter,
eigentlich nur nochmal die Readings pvCorrectionFactor_XX.
Hattest du heute eine leichte Bewölkung wie dargestellt oder wolkenlosen Himmel?
Die Prognose für morgen wird sich mit ziemlicher Sicherheit noch ändern.
Übrigens ... verwendest du das DWD Modell MOSMIX_S oder noch MOSMIX_L?
Zitat von: DS_Starter am 09 März 2025, 18:38:14eigentlich nur nochmal die Readings pvCorrectionFactor_XX.
setstate SolarForecast 2025-03-09 07:00:00 pvCorrectionFactor_07 0.82 (automatic - old factor: 0.89, Sun Alt range: 0, Cloud range: 40, Days in range: 2)
setstate SolarForecast 2025-03-09 08:00:00 pvCorrectionFactor_08 1.09 (automatic - old factor: 1.72, Sun Alt range: 5, Cloud range: 40, Days in range: 2)
setstate SolarForecast 2025-03-09 09:00:01 pvCorrectionFactor_09 1.17 (automatic - old factor: 1.27, Sun Alt range: 15, Cloud range: 45, Days in range: 2)
setstate SolarForecast 2025-03-09 10:00:01 pvCorrectionFactor_10 0.76 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 50, Days in range: 1)
setstate SolarForecast 2025-03-09 11:00:01 pvCorrectionFactor_11 0.86 (automatic - old factor: 1.02, Sun Alt range: 25, Cloud range: 50, Days in range: 2)
setstate SolarForecast 2025-03-09 12:00:04 pvCorrectionFactor_12 0.85 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 45, Days in range: 2)
setstate SolarForecast 2025-03-09 13:00:05 pvCorrectionFactor_13 0.74 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 45, Days in range: 1)
setstate SolarForecast 2025-03-09 14:00:03 pvCorrectionFactor_14 0.94 (automatic - old factor: 1.07, Sun Alt range: 30, Cloud range: 40, Days in range: 2)
setstate SolarForecast 2025-03-09 15:00:06 pvCorrectionFactor_15 0.83 (automatic - old factor: 1.12, Sun Alt range: 25, Cloud range: 35, Days in range: 3)
setstate SolarForecast 2025-03-09 16:00:03 pvCorrectionFactor_16 0.96 (automatic - old factor: 1.20, Sun Alt range: 20, Cloud range: 35, Days in range: 2)
setstate SolarForecast 2025-03-09 17:00:14 pvCorrectionFactor_17 0.90 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 30, Days in range: 1)
setstate SolarForecast 2025-03-09 18:00:03 pvCorrectionFactor_18 0.77 (automatic - old factor: 0.53, Sun Alt range: 5, Cloud range: 25, Days in range: 2)
Zitat von: DS_Starter am 09 März 2025, 18:38:14Hattest du heute eine leichte Bewölkung wie dargestellt oder wolkenlosen Himmel?
Weitgehend wolkenlos. Ein bisschen diesig, wie die letzten Tage auch.
Zitat von: DS_Starter am 09 März 2025, 18:38:14Übrigens ... verwendest du das DWD Modell MOSMIX_S oder noch MOSMIX_L?
Seit ein paar Wochen nutze ich MOSMIX_S. Kann die Umstellung die KI verwirrt haben?
Viele Grüße,
Peter
Zitat von: DS_Starter am 09 März 2025, 18:19:12Es könnte nämlich sein, dass wir noch eine optionale dritte Ebene einfügen um noch mehr Werte visualisieren zu können. Wir haben ja bereits jetzt 9 Content-Möglichkeiten zur Auswahl.
Dafür :D
ZitatSeit ein paar Wochen nutze ich MOSMIX_S. Kann die Umstellung die KI verwirrt haben?
Nein, alles gut. Wollte ich nur wissen.
An den Readings sieht man gut wie die Faktoren nach unten korrigiert werden. Bin zufrieden.
Problem ist die durch DWD gelieferte Bewölkung (bei uns der Parameter wcc). Das signifikante Wetter (weatherid) war wahrscheinlich 0 (=wolkenlos).
Man sieht das in der "get ... pvHistory" für heute z.B. Stunde 11 bei mir:
11 => pvfc: 5317, pvrl: 5240, pvrlvd: 1, rad1h: 1340
etotali01: 67166360, etotali02: -, etotali03: -, etotali04: -
pvrl01: 5240, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 813, con: 686, gcons: 10, conprice: 0.2958
gfeedin: 3456, feedprice: 0.1269
DoN: 1, sunaz: 147, sunalt: 30
batintotal01: 4403026.00448398, batintotal02: -, batintotal03: -
batouttotal01: 4274629.66720625, batouttotal02: -, batouttotal03: -
batsoc01: 63, batsoc02: -, batsoc03: -
batin01: 1242, batin02: -, batin03: -
batout01: 74, batout02: -, batout03: -
weatherid: 0, wcc: 28, rr1c: 0.00, pvcorrf: 1.00/0.80 temp: 5.40,
Wolkenloser Himmel (weatherid: 0), aber Cloudy 28 (wcc: 28). Ich habe es mit dem OpenMeteo ICON DWD verglichen, der bringt zur gleichen Stunde "weatherid: 0, wcc: 0" -> also so wie es realistisch richtig wäre.
Also ich weiß nicht was DWD OpenData da macht, aber wenn das signifikante Wetter "wolkenlos" ist, kann die Bewölkung nicht gleichzeitig 28 sein. Das kann ein Thema sein, weil dann nicht die für die reale Bewölkung gelernten Korrekturfaktoren verwendet werden. Das fällt einem halt nur bei wolkenloser Witterung auf, sonst nicht.
Ich werde das noch etwas beobachten, mal schauen ob das nur eine vorübergehende Erscheinung beim DWD ist.
Die Version 1.47.2 sieht gut für mich aus und werde sie einchecken.
Die KI kannst du gerne wieder aktivieren.
LG
ZitatDafür :D
:) Wunderte mich schon ein bisschen dass bisher noch niemand danach gefragt hat. ;)
Zitat von: DS_Starter am 09 März 2025, 19:24:32ZitatDafür :D
:) Wunderte mich schon ein bisschen dass bisher noch niemand danach gefragt hat. ;)
Ich find, was man hat, soll man auch zeigen können ;)
Ich habe die dritte Ebene bereits auf meiner Backlog-Liste stehen, geistert schon lange in meinem Kopf rum.
Aber der Hinweis von kask ist durchaus berechtigt. Damit man eine bessere visuelle Trennung zwischen den Ebenen hat müssen ich/wir etwas dazu überlegen.
Zitat von: DS_Starter am 09 März 2025, 11:41:43Nein. Achte darauf dass hier max. Leistung in Watt anzugeben ist.
Ja, ist so. Ich habe auch die Werte direkt per cut-and-paste in den Taschenrechner übernommen und damit die 14% ausgerechnet. Andernfalls dürfte die Abweichung auch um einen höheren Faktor abweichen.
Zitat von: DS_Starter am 09 März 2025, 11:41:43Ansonsten ctrlDebug=radiationProcess anschalten, dann sieht man mehr.
Das mache ich und schaue mir die Meldungen an.
Übrigens hat sich die Spitze so ne stunde vorher wohl zeitlich noch etwas verschoben und sich dadurch dann über 11 und 12 verteilt. Da hat man dann nur noch hohe Werte gesehen, aber nichts, was erst mal unplausibel erscheint. Erreicht wurden die Werte dann natürlich bei weitem nicht.
ZitatZwangsweise nach unten setzen würde ich die Bat-Leiste nicht wollen, evtl. einen zusätzlichen Parameter im Schlüssel show, also z.B. show=1[:below] oder so.
Alternativ tendiere ich dazu zwischen den Ebenen einen Trenner, eine Linie oder Freiplatz etc., einzufügen um die Ebenen besser visuell voneinander zu trennen. Es könnte nämlich sein, dass wir noch eine optionale dritte Ebene einfügen um noch mehr Werte visualisieren zu können. Wir haben ja bereits jetzt 9 Content-Möglichkeiten zur Auswahl. Weiterhin könnte es sein, dass auch die Wetterleiste wahlweise in anderen Ebenen dargestellt werden kann.
Kurzum, eine bessere visuelle Trennung der Ebenen sehe ich als wünschenswert an.
Das würde ich auch so sehen. Tendenziell wäre ich eher für eine Trennlinie als für einen "Freiplatz".
Auch das mit dem auswählen ob es oben oder unten eingeblendet sein soll, wäre eine gute Option.
Hiermit sollte die Aufteilung deutlich werden.
(Oben/Unten-Einbelendung mache ich noch)
LG
Hallo Heiko + @All,
Thema Ladesteuerung Batterien:
Bei Batterie01 (setupBatteryDev01) wird die netzdienliche Ladessteuerung (Battery_ChargeRecommended_01) - soweit ich beurteilen kann - durchgängig zu den richtigen Zeiten geschaltet. Heute z.B. wurde ab 07:00 Uhr bis um 13:00 Uhr immer wieder mal (13 x) der Wert von "Battery_ChargeRecommended_01" zwischen 0 und 1 hin und her gewechselt.
Bei Batterie02 (setupBatteryDev02) passiert leider (bei mir) kein Werte-Wechsel bei Battery_ChargeRecommended_02 - obwohl mehrfach bei mir in den letzen Tagen mehr ins Netz eingespeist wurde, als in die 2 Batterien zusammen an dem Tag eingespeichert werden könnte.
(Ist bislang weiterhin noch nicht ein einziges Mal von 1 auf 0 umgeschaltet)
Kurzum
Netzdienlich bei Batterie01 =>> läuft
Netzdienlich bei zusätzlich Batterie02 =>> ? ? Oder wird dies nur über Batterie01 "mitgesteuert"
Einen Grund für das Verhaltung sehe ich derzeitig nicht.
@Alle:
Gibt es jemanden der mit 2 / 3 Batterien Erfahrung hat oder es nutzt ?
Gruß
300?
Zitat von: DS_Starter am 09 März 2025, 11:41:43Ansonsten ctrlDebug=radiationProcess anschalten, dann sieht man mehr.
Da ist heute natürlich nichts Verdächtiges zu sehen. Wenn da ein Wert zu hoch ist, fällt das nicht auf. Gestern konnte man halt eindeutig sehen, dass der eine Wert nicht plausibel ist. Von dieser Stunde wäre das Debug-Log interessant gewesen. Ich warte mal, ob so was wieder auftritt und schaue dann direkt nach.
Was mir im Log aber aufgefallen ist: "Module Temp (calculated) => 22.55 °C" für "Hour 10" bei "Forecasted temperature => 7.80 °C" ist der höchste Wert heute. Das kam mir komisch vor, auf Temperaturen hatte ich bisher aber noch nicht geschaut. Nachdem ich das jetzt gemacht habe, würde ich sagen, dass dieser Wert sogar noch der plausibelste ist. Für den Rest des Tages war die Modultemperatur mit maximal 16-17 Grad vorhergesagt, obwohl selbst die "Forecasted temperature" bis auf 15 Grad stieg und die Sonneneinstrahlung natürlich im Laufe des Tages auch intensiver wurde (wie auch vorhergesagt). Die Modultemperatur lag dann eher zwischen 25 und 30 Grad. Der berechnete Zuschlag von 4-5% auf die "String Peak" führte dann auf jeden Fall zu Vorhersagefehlern. Wie wird denn die Module "Temp (calculated)" vorhergesagt?
ZitatWie wird denn die Module "Temp (calculated)" vorhergesagt?
Das ist eine Annahme, die aus diesem Zusammenhang abgeleitet wird:
# Die Nominalleistung der Module wird bei 25 Grad
# Umgebungstemperatur und bei 1.000 Watt Sonneneinstrahlung
# gemessen.
# Steigt die Temperatur um 1 Grad Celsius sinkt die Modulleistung
# typisch um 0,4 Prozent. Solartellen können im Sommer 70°C heiß
# werden.
#
# Das würde für eine 10 kWp Photovoltaikanlage folgenden
# Leistungsverlust bedeuten:
#
# Leistungsverlust = -0,4%/K * 45K * 10 kWp = 1,8 kWp
#
# https://www.enerix.de/photovoltaiklexikon/temperaturkoeffizient/
Natürlich nur grob denn wir wissen nicht den Temp. Koeffizienten der verbauten Zellen und wir wissen auch nicht die reale Temp. der Zellen, schon garnicht als Prognose. Im Modul wird ein Zuschlag/Abschlag abhängig von der der Umgebungstemp. und der Strahlungsintensität (d.h. Bewölkung vorgenommen).
Allerdings hat der daraus resultierende Wert nur eine begrenzende Funktion, d.h. der Peak kann etwas höher oder niedriger liegen.
@300P,
wichtige Frage, hast du das Attr ctrlBatSocManagement02 für die 2. Batterie gesetzt?
Wenn ja, kann nur ein ctrlDebug=batteryManagement mehr Aufschluß geben.
attr Forecast ctrlBatSocManagement01 lowSoc=10 upSoC=30 maxSoC=95 careCycle=20
attr Forecast ctrlBatSocManagement02 lowSoc=10 upSoC=30 maxSoC=95 careCycle=20
Hier das aktuelle Log vom Batteriemanagement
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step2 - basics -> Energy expected for charging: 13172.8666666667 Wh, need until maxsoc: 0 Wh
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 10.03.2025 16:54:00)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step3 - basics -> cantarget: -46 %, newtarget: -46 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step2 - basics -> Energy expected for charging: 12600.1333333333 Wh, need until maxsoc: 0 Wh
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 10.03.2025 16:54:00)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step3 - basics -> cantarget: -46 %, newtarget: -46 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB25' cap: 2500 W, Power limit: 70 % -> Pmax eff: 1750 W
2025.03.10 16:26:49 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB30' cap: 3000 W, Power limit: 70 % -> Pmax eff: 2100 W
2025.03.10 16:26:49 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB40' cap: 4000 W, Power limit: 70 % -> Pmax eff: 2800 W
2025.03.10 16:26:49 1: Forecast DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 6650 W
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 9016 Wh, Percentage of total capacity: 51.1 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 16 -> 1 (currsoc: 100 %, SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 824, confc: 300, Surp Day: 310 Wh, Curr PV: 3041 W, Curr Consumption: 2598 W, Limit: 6650 W)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 17 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 974, confc: 303, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 18 -> 1 (SoCfc: 96.4 %, soc: 8695 Wh, pvfc: 29, confc: 318, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 19 -> 1 (SoCfc: 92.6 %, soc: 8345 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 20 -> 1 (SoCfc: 88.4 %, soc: 7974 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 21 -> 1 (SoCfc: 84.3 %, soc: 7603 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 22 -> 1 (SoCfc: 80.5 %, soc: 7254 Wh, pvfc: 0, confc: 314, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 10 23 -> 1 (SoCfc: 77.2 %, soc: 6962 Wh, pvfc: 0, confc: 263, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 00 -> 1 (SoCfc: 74.2 %, soc: 6693 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 01 -> 1 (SoCfc: 71.3 %, soc: 6427 Wh, pvfc: 0, confc: 239, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 02 -> 1 (SoCfc: 68.3 %, soc: 6158 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 03 -> 1 (SoCfc: 65.4 %, soc: 5894 Wh, pvfc: 0, confc: 238, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 04 -> 1 (SoCfc: 62.4 %, soc: 5627 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 05 -> 1 (SoCfc: 59.4 %, soc: 5360 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 06 -> 1 (SoCfc: 56.5 %, soc: 5092 Wh, pvfc: 0, confc: 241, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 07 -> 1 (SoCfc: 67.1 %, soc: 6046 Wh, pvfc: 1299, confc: 239, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 08 -> 1 (SoCfc: 75.0 %, soc: 6761 Wh, pvfc: 1111, confc: 317, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 09 -> 1 (SoCfc: 85.9 %, soc: 7741 Wh, pvfc: 1371, confc: 282, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 10 -> 1 (SoCfc: 95.6 %, soc: 8618 Wh, pvfc: 1222, confc: 248, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 11 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2238, confc: 258, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2109, confc: 401, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2105, confc: 470, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1158, confc: 365, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 417, confc: 347, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 16 -> 1 (SoCfc: 97.5 %, soc: 8788 Wh, pvfc: 95, confc: 300, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 17 -> 1 (SoCfc: 94.3 %, soc: 8501 Wh, pvfc: 45, confc: 303, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 18 -> 1 (SoCfc: 90.4 %, soc: 8151 Wh, pvfc: 3, confc: 318, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 19 -> 1 (SoCfc: 86.5 %, soc: 7801 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 20 -> 1 (SoCfc: 82.4 %, soc: 7430 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 21 -> 1 (SoCfc: 78.3 %, soc: 7059 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 22 -> 1 (SoCfc: 74.4 %, soc: 6710 Wh, pvfc: 0, confc: 314, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 01 relLoad 11 23 -> 1 (SoCfc: 71.2 %, soc: 6418 Wh, pvfc: 0, confc: 263, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 Charge Rcmd - Installed Battery capacity: 8624 Wh, Percentage of total capacity: 48.9 %
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 16 -> 1 (currsoc: 100 %, SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 788, confc: 286, Surp Day: 0 Wh, Curr PV: 3041 W, Curr Consumption: 2598 W, Limit: 6650 W)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 17 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 931, confc: 290, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 18 -> 1 (SoCfc: 96.4 %, soc: 8316 Wh, pvfc: 28, confc: 305, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 19 -> 1 (SoCfc: 92.6 %, soc: 7982 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 20 -> 1 (SoCfc: 88.5 %, soc: 7628 Wh, pvfc: 0, confc: 319, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 21 -> 1 (SoCfc: 84.3 %, soc: 7272 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 22 -> 1 (SoCfc: 80.5 %, soc: 6939 Wh, pvfc: 0, confc: 300, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 10 23 -> 1 (SoCfc: 77.2 %, soc: 6659 Wh, pvfc: 0, confc: 252, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 00 -> 1 (SoCfc: 74.2 %, soc: 6401 Wh, pvfc: 0, confc: 232, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 01 -> 1 (SoCfc: 71.3 %, soc: 6148 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 02 -> 1 (SoCfc: 68.3 %, soc: 5891 Wh, pvfc: 0, confc: 231, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 03 -> 1 (SoCfc: 65.4 %, soc: 5638 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 04 -> 1 (SoCfc: 62.4 %, soc: 5382 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 05 -> 1 (SoCfc: 59.4 %, soc: 5126 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 06 -> 1 (SoCfc: 56.5 %, soc: 4870 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 07 -> 1 (SoCfc: 67.0 %, soc: 5782 Wh, pvfc: 1242, confc: 229, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 08 -> 1 (SoCfc: 75.0 %, soc: 6466 Wh, pvfc: 1063, confc: 303, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 09 -> 1 (SoCfc: 85.9 %, soc: 7404 Wh, pvfc: 1312, confc: 270, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 10 -> 1 (SoCfc: 95.6 %, soc: 8242 Wh, pvfc: 1169, confc: 238, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 11 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2141, confc: 246, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2018, confc: 384, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2014, confc: 450, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1107, confc: 350, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 398, confc: 331, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 16 -> 1 (SoCfc: 97.5 %, soc: 8407 Wh, pvfc: 91, confc: 286, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 17 -> 1 (SoCfc: 94.3 %, soc: 8133 Wh, pvfc: 43, confc: 290, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 18 -> 1 (SoCfc: 90.4 %, soc: 7796 Wh, pvfc: 2, confc: 305, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 19 -> 1 (SoCfc: 86.5 %, soc: 7462 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 20 -> 1 (SoCfc: 82.4 %, soc: 7108 Wh, pvfc: 0, confc: 319, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 21 -> 1 (SoCfc: 78.3 %, soc: 6752 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 22 -> 1 (SoCfc: 74.4 %, soc: 6419 Wh, pvfc: 0, confc: 300, Surp Day: 0 Wh)
2025.03.10 16:26:49 1: Forecast DEBUG> Bat 02 relLoad 11 23 -> 1 (SoCfc: 71.2 %, soc: 6139 Wh, pvfc: 0, confc: 252, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step2 - basics -> Energy expected for charging: 13172.8666666667 Wh, need until maxsoc: 0 Wh
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 10.03.2025 16:54:00)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step3 - basics -> cantarget: -46 %, newtarget: -46 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step2 - basics -> Energy expected for charging: 12600.1333333333 Wh, need until maxsoc: 0 Wh
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 10.03.2025 16:54:00)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step3 - basics -> cantarget: -46 %, newtarget: -46 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB25' cap: 2500 W, Power limit: 70 % -> Pmax eff: 1750 W
2025.03.10 16:26:52 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB30' cap: 3000 W, Power limit: 70 % -> Pmax eff: 2100 W
2025.03.10 16:26:52 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB40' cap: 4000 W, Power limit: 70 % -> Pmax eff: 2800 W
2025.03.10 16:26:52 1: Forecast DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 6650 W
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 9016 Wh, Percentage of total capacity: 51.1 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 16 -> 1 (currsoc: 100 %, SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 824, confc: 300, Surp Day: 310 Wh, Curr PV: 3039 W, Curr Consumption: 2599 W, Limit: 6650 W)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 17 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 974, confc: 303, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 18 -> 1 (SoCfc: 96.4 %, soc: 8695 Wh, pvfc: 29, confc: 318, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 19 -> 1 (SoCfc: 92.6 %, soc: 8345 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 20 -> 1 (SoCfc: 88.4 %, soc: 7974 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 21 -> 1 (SoCfc: 84.3 %, soc: 7603 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 22 -> 1 (SoCfc: 80.5 %, soc: 7254 Wh, pvfc: 0, confc: 314, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 10 23 -> 1 (SoCfc: 77.2 %, soc: 6962 Wh, pvfc: 0, confc: 263, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 00 -> 1 (SoCfc: 74.2 %, soc: 6693 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 01 -> 1 (SoCfc: 71.3 %, soc: 6427 Wh, pvfc: 0, confc: 239, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 02 -> 1 (SoCfc: 68.3 %, soc: 6158 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 03 -> 1 (SoCfc: 65.4 %, soc: 5894 Wh, pvfc: 0, confc: 238, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 04 -> 1 (SoCfc: 62.4 %, soc: 5627 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 05 -> 1 (SoCfc: 59.4 %, soc: 5360 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 06 -> 1 (SoCfc: 56.5 %, soc: 5092 Wh, pvfc: 0, confc: 241, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 07 -> 1 (SoCfc: 67.1 %, soc: 6046 Wh, pvfc: 1299, confc: 239, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 08 -> 1 (SoCfc: 75.0 %, soc: 6761 Wh, pvfc: 1111, confc: 317, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 09 -> 1 (SoCfc: 85.9 %, soc: 7741 Wh, pvfc: 1371, confc: 282, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 10 -> 1 (SoCfc: 95.6 %, soc: 8618 Wh, pvfc: 1222, confc: 248, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 11 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2238, confc: 258, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2109, confc: 401, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2105, confc: 470, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1158, confc: 365, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 417, confc: 347, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 16 -> 1 (SoCfc: 97.5 %, soc: 8788 Wh, pvfc: 95, confc: 300, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 17 -> 1 (SoCfc: 94.3 %, soc: 8501 Wh, pvfc: 45, confc: 303, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 18 -> 1 (SoCfc: 90.4 %, soc: 8151 Wh, pvfc: 3, confc: 318, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 19 -> 1 (SoCfc: 86.5 %, soc: 7801 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 20 -> 1 (SoCfc: 82.4 %, soc: 7430 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 21 -> 1 (SoCfc: 78.3 %, soc: 7059 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 22 -> 1 (SoCfc: 74.4 %, soc: 6710 Wh, pvfc: 0, confc: 314, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 01 relLoad 11 23 -> 1 (SoCfc: 71.2 %, soc: 6418 Wh, pvfc: 0, confc: 263, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 Charge Rcmd - Installed Battery capacity: 8624 Wh, Percentage of total capacity: 48.9 %
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 16 -> 1 (currsoc: 100 %, SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 788, confc: 286, Surp Day: 0 Wh, Curr PV: 3039 W, Curr Consumption: 2599 W, Limit: 6650 W)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 17 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 931, confc: 290, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 18 -> 1 (SoCfc: 96.4 %, soc: 8316 Wh, pvfc: 28, confc: 305, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 19 -> 1 (SoCfc: 92.6 %, soc: 7982 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 20 -> 1 (SoCfc: 88.5 %, soc: 7628 Wh, pvfc: 0, confc: 319, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 21 -> 1 (SoCfc: 84.3 %, soc: 7272 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 22 -> 1 (SoCfc: 80.5 %, soc: 6939 Wh, pvfc: 0, confc: 300, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 10 23 -> 1 (SoCfc: 77.2 %, soc: 6659 Wh, pvfc: 0, confc: 252, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 00 -> 1 (SoCfc: 74.2 %, soc: 6401 Wh, pvfc: 0, confc: 232, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 01 -> 1 (SoCfc: 71.3 %, soc: 6148 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 02 -> 1 (SoCfc: 68.3 %, soc: 5891 Wh, pvfc: 0, confc: 231, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 03 -> 1 (SoCfc: 65.4 %, soc: 5638 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 04 -> 1 (SoCfc: 62.4 %, soc: 5382 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 05 -> 1 (SoCfc: 59.4 %, soc: 5126 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 06 -> 1 (SoCfc: 56.5 %, soc: 4870 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 07 -> 1 (SoCfc: 67.0 %, soc: 5782 Wh, pvfc: 1242, confc: 229, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 08 -> 1 (SoCfc: 75.0 %, soc: 6466 Wh, pvfc: 1063, confc: 303, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 09 -> 1 (SoCfc: 85.9 %, soc: 7404 Wh, pvfc: 1312, confc: 270, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 10 -> 1 (SoCfc: 95.6 %, soc: 8242 Wh, pvfc: 1169, confc: 238, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 11 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2141, confc: 246, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2018, confc: 384, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2014, confc: 450, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1107, confc: 350, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 398, confc: 331, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 16 -> 1 (SoCfc: 97.5 %, soc: 8407 Wh, pvfc: 91, confc: 286, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 17 -> 1 (SoCfc: 94.3 %, soc: 8133 Wh, pvfc: 43, confc: 290, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 18 -> 1 (SoCfc: 90.4 %, soc: 7796 Wh, pvfc: 2, confc: 305, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 19 -> 1 (SoCfc: 86.5 %, soc: 7462 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 20 -> 1 (SoCfc: 82.4 %, soc: 7108 Wh, pvfc: 0, confc: 319, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 21 -> 1 (SoCfc: 78.3 %, soc: 6752 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 22 -> 1 (SoCfc: 74.4 %, soc: 6419 Wh, pvfc: 0, confc: 300, Surp Day: 0 Wh)
2025.03.10 16:26:52 1: Forecast DEBUG> Bat 02 relLoad 11 23 -> 1 (SoCfc: 71.2 %, soc: 6139 Wh, pvfc: 0, confc: 252, Surp Day: 0 Wh)
PS:
Schalte morgen früh mal nach dem Frühstück das Loggen wieder ein
Kann aber (SSD am RPI) auch einfach mal dauerloggen ?.......
Ich kann da jetzt nichts abwegiges erkennen.
Interessant wäre nur der Moment wo eine Bat nicht geladen werden soll und die andere noch eine Freigabe hat. Morgen ist da vllt. nicht so ein guter Tag dafür.
Aber vllt. liegt auch ein kleines Mißverständnis vor. Es erfolgt immer dann eine Ladefreigabe wenn:
- wenn benötigte Ladeenergie >= Restüberschuß des Tages zzgl. Sicherheitsaufschlag
ODER
- der PV-Erezugungszenit überschritten ist (Today_MaxPVforecastTime)
ODER
- wenn akt. PV Leistung >= WR-Leistungsbegrenzung
ODER
- wenn BatSoc-Managementnicht _nicht_ aktiviert ist
Wenn eine dieser Kriterien wahr ist, bleibt Battery_ChargeRecommended_XX = 1.
D.h. auch, wenn durch das Management der Bat1 die Einhaltung der Kriterien bereits erwirkt wird, bleibt die Bat2 im Modus Battery_ChargeRecommended_XX =1.
Zitat von: DS_Starter am 10 März 2025, 16:59:59Ich kann da jetzt nichts abwegiges erkennen.
Interessant wäre nur der Moment wo eine Bat nicht geladen werden soll und die andere noch eine Freigabe hat. Morgen ist da vllt. nicht so ein guter Tag dafür.
Stimmt - morgen soll es bei mir nur ca. 24 kWh geben statt ca. 37 kWh heute :o
(Tagesverbrauch ist so um die 15 kWh)
Ich habe den Sachverhalt im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Aktivierung_und_Arbeitsweise) nochmal festgehalten.
Zitat von: DS_Starter am 10 März 2025, 16:16:02Allerdings hat der daraus resultierende Wert nur eine begrenzende Funktion, d.h. der Peak kann etwas höher oder niedriger liegen.
Wobei das bei mir heute schon so 7% Unterschied in der Vorhersage verursacht haben dürfte. Berechnet war die Modultemperatur mit 15 Grad (also Zuschlag) und war dann über 32 (also Abschlag).
Und noch eine Frage zum Verständnis: Die voraussichtliche Modultemperatur wird aus Außentemperatur und Strahlungsintensität berechnet. Aus der voraussichtlichen Modultemperatur ergibt sich dann anhand eines durchschnittlichen Temp.-Koeffizienten der Zuschlag oder Abschlag. Müsste dann bei 2 Strings mit gleicher "Forecasted temperature" nicht auch "Win(+)/Loss(-) String Peak Power
by Temp" gleich sein?
ZitatMüsste dann bei 2 Strings mit gleicher "Forecasted temperature" nicht auch "Win(+)/Loss(-) String Peak Power by Temp" gleich sein?
Nur wenn die nominalen String-Peak identisch sind, also z.B. 2 Strings mit je 2kW Peak.
Das Ganze ist ein wenig Glaskugel schauen. Ich habe noch keine Angaben gefunden mit denen man eine Prognose der Zelltemperaturen sehr realistisch prognostizieren kann. Aktuelle Temperaturmessungen nutzen für eine Prognose nichts.
Ich könnte diesen Temperaturaufschlag / Abschlag auch herausnehmen. Allerdings hat die Zelltemperatur mit Sicherheit einen Leistungseinfluß.
Ob ich mit meiner Einschätzung richtig liege? Schwer zu sagen. Man kann sich die Mühe machen und die Prognosen für den Tag mal notieren und über geeignete Maßnahmen jede Stunde die realen Temp messen. Daraus dann eine Differenzbetrachtung anfertigen mit der man den Formelansatz verbessern kann.
Wenn ich mir meine Vergleichsinstanz mit der pah-Formel ohne jegliche Korrektur (auch keine via Tempkoeffizent) anschaue, erkenne ich bei sonnigen Wetter immer! um die Mittagszeit eine Abflachung der realen Erzeugung gegenüber der Prognose. Das könnte eine Folge der Aufheizung der Zellen sein (habe reine Südlage).
Bei den korrigierten Instanzen ist die Diskrepanz nicht so ausgeprägt. Sicherlich hat die Temp.Korrektur hier auch einen Einfluß.
Wie gesagt, besser weiß ich es nicht. Wenn jemand eine bessere Formel/Möglichkeit sieht, nehme ich einen Vorschlag gerne entgegen.
Hallo zusammen,
seit einigen Tagen ist meine Verbrauchsprognose leider leer.
Im Datenspeicher pvHistory sind die confc Werte der letzten Tage leer (siehe Bild confc_10.PNG) in den Daten von letztem Monat sind noch Werte vorhanden (siehe Bild confc_11.PNG).
Zur Erklärung: beim Update auf Version 1.45.6 (siehe mein Post #1992) hatte ich eine Endlosschleife und musste kurz das Modul deaktiveren. Nach der Behebung und Aktivierung waren dann die Verbrauchsprognosewerte nicht mehr vorhanden (ein Recover hatte ich danach nicht manuell gestartet).
Ich halte dieses Modul aktuell und habe das aktuellste Update von heute durchgeführt.
Vielleicht hat jemand eine Idee für eine weitere, tiefere Analyse ?
Gruß Martin
Ist das Attr affectConsForecastIdentWeekdays gesetzt, wenn ja wie?
Und zeigt mal bitte diesen Ausschnitt aus "get ... pvCircular 11":
con_all => Di @ 785 666 1391 1440 1509
Sa @ 697 851 535 739 1801
So @ 615 534 708 705 623
Mi @ 796 515 949 739 1055
Fr @ 1103 369 829 572 667
Mo @ 1888 954 1038 1961 2305 1099
Do @ 418 1379 1272 490 669
Es kommt auf das "con_all" an.
Danke für die schnelle Rückmeldung.
affectConsForecastIdentWeekdays 1
affectConsForecastLastDays 8
pvCircular 11 (con_all ist nicht vorhanden):
11 => pvapifc: 1741, pvaifc: -, pvfc: 1741, aihit: 0, pvrl: 2800
batin01: 2287, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
confc: -, gcon: 0, gfeedin: 0, wcc: 100, rr1c: 0.00
temp: 6.90, wid: 3, wtxt: Bewölkung zunehmend
pprl01: -, pprl02: -, pprl03: -
pvcorrf: -
quality: -
pvrlsum: -
pvfcsum: -
dnumsum: -
Gruß Martin
Hallo Martin,
zeig mal bitte noch die komplette Ausgabe von "get ... pvHistory 10".
hier die pvHistory 10 von heute:
10 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 250, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 0, sunaz: 360, sunalt: -43
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1466428, batouttotal02: -, batouttotal03: -
batsoc01: 45.6, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 255, batout02: -, batout03: -
weatherid: 101, wcc: 35, rr1c: 0.00, pvcorrf: 1.00/- temp: 3.40,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 229, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 0, sunaz: 20, sunalt: -42
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1466683, batouttotal02: -, batouttotal03: -
batsoc01: 40.9, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 229, batout02: -, batout03: -
weatherid: 101, wcc: 33, rr1c: 0.00, pvcorrf: 1.00/- temp: 2.40,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.001, csme02: 0.001, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 221, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 0, sunaz: 38, sunalt: -37
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1466912, batouttotal02: -, batouttotal03: -
batsoc01: 36.4, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 227, batout02: -, batout03: -
weatherid: 101, wcc: 30, rr1c: 0.00, pvcorrf: 1.00/- temp: 1.60,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.001, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 201, gcons: 0, conprice: 0.289
gfeedin: 19900, feedprice: 0.082
DoN: 0, sunaz: 54, sunalt: -30
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1467139, batouttotal02: -, batouttotal03: -
batsoc01: 32.1, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 201, batout02: -, batout03: -
weatherid: 100, wcc: 30, rr1c: 0.00, pvcorrf: 1.00/- temp: 1.30,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.001, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 205, gcons: 300, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 0, sunaz: 68, sunalt: -22
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1467346, batouttotal02: -, batouttotal03: -
batsoc01: 31.8, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 5, batout02: -, batout03: -
weatherid: 100, wcc: 38, rr1c: 0.00, pvcorrf: 1.00/- temp: 0.50,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.001, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
06 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 700, gcons: 800, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 0, sunaz: 81, sunalt: -13
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 31.6, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 101, wcc: 39, rr1c: 0.00, pvcorrf: 1.00/- temp: 0.20,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.002, csme02: 0.001, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
07 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 800, gcons: 900, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 0, sunaz: 92, sunalt: -3
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 31.5, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 102, wcc: 58, rr1c: 0.00, pvcorrf: 1.00/- temp: -1.60,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.002, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
08 => pvfc: 100, pvrl: 100, pvrlvd: 1, rad1h: 90
etotali01: 9405200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 100, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 200, gcons: 100, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 104, sunalt: 7
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 31.3, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 2, wcc: 62, rr1c: 0.00, pvcorrf: 1.00/- temp: -1.30,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.002, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
09 => pvfc: 600, pvrl: 300, pvrlvd: 1, rad1h: 310
etotali01: 9405300, etotali02: -, etotali03: -, etotali04: -
pvrl01: 300, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 181, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 116, sunalt: 15
batintotal01: 1688771, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 33.5, batsoc02: -, batsoc03: -
batin01: 119, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 2, wcc: 63, rr1c: 0.00, pvcorrf: 1.00/- temp: 0.10,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.002, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
10 => pvfc: 1909, pvrl: 1100, pvrlvd: 1, rad1h: 650
etotali01: 9405600, etotali02: -, etotali03: -, etotali04: -
pvrl01: 1100, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 384, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 130, sunalt: 23
batintotal01: 1688890, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 46, batsoc02: -, batsoc03: -
batin01: 736, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 2, wcc: 56, rr1c: 0.00, pvcorrf: 1.00/- temp: 3.10,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.003, csme02: 0.001, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
11 => pvfc: 3125, pvrl: 2800, pvrlvd: 1, rad1h: 950
etotali01: 9406700, etotali02: -, etotali03: -, etotali04: -
pvrl01: 2800, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 513, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 145, sunalt: 30
batintotal01: 1689626, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 77.6, batsoc02: -, batsoc03: -
batin01: 2287, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 1, wcc: 55, rr1c: 0.00, pvcorrf: 1.00/- temp: 6.50,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.003, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
12 => pvfc: 4098, pvrl: 4200, pvrlvd: 1, rad1h: 1160
etotali01: 9409500, etotali02: -, etotali03: -, etotali04: -
pvrl01: 4200, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 3099, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 162, sunalt: 34
batintotal01: 1691972, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 100, batsoc02: -, batsoc03: -
batin01: 1101, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 1, wcc: 52, rr1c: 0.00, pvcorrf: 1.00/- temp: 9.60,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.003, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
13 => pvfc: 5075, pvrl: 4900, pvrlvd: 1, rad1h: 1380
etotali01: 9413700, etotali02: -, etotali03: -, etotali04: -
pvrl01: 4900, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 4800, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 180, sunalt: 35
batintotal01: 1693073, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 100, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 1, wcc: 27, rr1c: 0.00, pvcorrf: 1.00/- temp: 11.80,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.004, csme02: 0.001, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
14 => pvfc: 4882, pvrl: 4900, pvrlvd: 1, rad1h: 1310
etotali01: 9418600, etotali02: -, etotali03: -, etotali04: -
pvrl01: 4900, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 4868, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 198, sunalt: 34
batintotal01: 1693073, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 100, batsoc02: -, batsoc03: -
batin01: 32, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 1, wcc: 37, rr1c: 0.00, pvcorrf: 1.00/- temp: 13.60,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 0.004, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
15 => pvfc: 4134, pvrl: 3700, pvrlvd: 1, rad1h: 1130
etotali01: 9423500, etotali02: -, etotali03: -, etotali04: -
pvrl01: 3700, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 4291, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 215, sunalt: 30
batintotal01: 1693105, batintotal02: -, batintotal03: -
batouttotal01: 1467351, batouttotal02: -, batouttotal03: -
batsoc01: 89.3, batsoc02: -, batsoc03: -
batin01: 59, batin02: -, batin03: -
batout01: 750, batout02: -, batout03: -
weatherid: 1, wcc: 46, rr1c: 0.00, pvcorrf: 1.00/- temp: 14.60,
csmt01: 0, csme01: 2960, minutescsm01: 52
csmt02: 0.871, csme02: 0.867, minutescsm02: 47
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
16 => pvfc: 3079, pvrl: 2900, pvrlvd: 1, rad1h: 890
etotali01: 9427200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 2900, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 2191, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 230, sunalt: 23
batintotal01: 1693186, batintotal02: -, batintotal03: -
batouttotal01: 1468101, batouttotal02: -, batouttotal03: -
batsoc01: 100, batsoc02: -, batsoc03: -
batin01: 711, batin02: -, batin03: -
batout01: 2, batout02: -, batout03: -
weatherid: 1, wcc: 54, rr1c: 0.00, pvcorrf: 1.00/- temp: 15.20,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 2.053, csme02: 1.182, minutescsm02: 53
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
17 => pvfc: 1611, pvrl: 1600, pvrlvd: 1, rad1h: 500
etotali01: 9430100, etotali02: -, etotali03: -, etotali04: -
pvrl01: 1600, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 4614, gcons: 600, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 243, sunalt: 16
batintotal01: 1693897, batintotal02: -, batintotal03: -
batouttotal01: 1468103, batouttotal02: -, batouttotal03: -
batsoc01: 63.8, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 2471, batout02: -, batout03: -
weatherid: 3, wcc: 59, rr1c: 0.00, pvcorrf: 1.00/- temp: 15.00,
csmt01: 2322, csme01: 2322, minutescsm01: 49
csmt02: 3.102, csme02: 1.049, minutescsm02: 32
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
18 => pvfc: 488, pvrl: 200, pvrlvd: 1, rad1h: 170
etotali01: 9431700, etotali02: -, etotali03: -, etotali04: -
pvrl01: 200, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 1661, gcons: 100, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 1, sunaz: 256, sunalt: 7
batintotal01: 1693897, batintotal02: -, batintotal03: -
batouttotal01: 1470574, batouttotal02: -, batouttotal03: -
batsoc01: 43.3, batsoc02: -, batsoc03: -
batin01: 10, batin02: -, batin03: -
batout01: 1371, batout02: -, batout03: -
weatherid: 3, wcc: 63, rr1c: 0.00, pvcorrf: 1.00/- temp: 14.30,
csmt01: 0, csme01: 1265, minutescsm01: 16
csmt02: 4.039, csme02: 0.937, minutescsm02: 58
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
19 => pvfc: 24, pvrl: 0, pvrlvd: 1, rad1h: 10
etotali01: 9431900, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 4259, gcons: 18530, conprice: 0.289
gfeedin: 14520, feedprice: 0.082
DoN: 1, sunaz: 267, sunalt: -3
batintotal01: 1693907, batintotal02: -, batintotal03: -
batouttotal01: 1471949, batouttotal02: -, batouttotal03: -
batsoc01: 38, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 249, batout02: -, batout03: -
weatherid: 3, wcc: 76, rr1c: 0.00, pvcorrf: 1.00/- temp: 13.60,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 4.04, csme02: 0.00100000000000033, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
20 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 9431900, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 75, gcons: 0, conprice: 0.289
gfeedin: 0, feedprice: 0.082
DoN: 0, sunaz: 279, sunalt: -12
batintotal01: 1693907, batintotal02: -, batintotal03: -
batouttotal01: 1472198, batouttotal02: -, batouttotal03: -
batsoc01: 36.4, batsoc02: -, batsoc03: -
batin01: 0, batin02: -, batin03: -
batout01: 92, batout02: -, batout03: -
weatherid: 103, wcc: 79, rr1c: 0.00, pvcorrf: 1.00/- temp: 11.40,
csmt01: 0, csme01: 0, minutescsm01: 0
csmt02: 4.04, csme02: 0, minutescsm02: 0
csmt03: 291914.575, csme03: 0, minutescsm03: 0
csmt04: 270301.851, csme04: 0, minutescsm04: 0
21 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
etotali01: -, etotali02: -, etotali03: -, etotali04: -
pvrl01: -, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: -, gcons: -, conprice: -
gfeedin: -, feedprice: -
DoN: 0, sunaz: 292, sunalt: -21
batintotal01: -, batintotal02: -, batintotal03: -
batouttotal01: -, batouttotal02: -, batouttotal03: -
batsoc01: -, batsoc02: -, batsoc03: -
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
weatherid: 103, wcc: 79, rr1c: 0.00, pvcorrf: 1.00/- temp: 9.70,
22 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
etotali01: -, etotali02: -, etotali03: -, etotali04: -
pvrl01: -, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: -, gcons: -, conprice: -
gfeedin: -, feedprice: -
DoN: 0, sunaz: 305, sunalt: -30
batintotal01: -, batintotal02: -, batintotal03: -
batouttotal01: -, batouttotal02: -, batouttotal03: -
batsoc01: -, batsoc02: -, batsoc03: -
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
weatherid: 103, wcc: 82, rr1c: 0.00, pvcorrf: 1.00/- temp: 7.80,
23 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
etotali01: -, etotali02: -, etotali03: -, etotali04: -
pvrl01: -, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: -, gcons: -, conprice: -
gfeedin: -, feedprice: -
DoN: 0, sunaz: 321, sunalt: -36
batintotal01: -, batintotal02: -, batintotal03: -
batouttotal01: -, batouttotal02: -, batouttotal03: -
batsoc01: -, batsoc02: -, batsoc03: -
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
weatherid: 103, wcc: 85, rr1c: 0.00, pvcorrf: 1.00/- temp: 6.10,
24 => pvfc: 0, pvrl: -, pvrlvd: -, rad1h: 0
etotali01: -, etotali02: -, etotali03: -, etotali04: -
pvrl01: -, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: -, gcons: -, conprice: -
gfeedin: -, feedprice: -
DoN: 0, sunaz: 340, sunalt: -41
batintotal01: -, batintotal02: -, batintotal03: -
batouttotal01: -, batouttotal02: -, batouttotal03: -
batsoc01: -, batsoc02: -, batsoc03: -
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
weatherid: 103, wcc: 85, rr1c: 0.00, pvcorrf: 1.00/- temp: 5.10,
99 => pvfc: 29125, pvrl: 26700, pvrlvd: -, rad1h: -
pvrl01: 26700, pvrl02: -, pvrl03: -, pvrl04: -
pprl01: -, pprl02: -, pprl03: -
confc: -, con: 33742, gcons: 21330, conprice: -
gfeedin: 34420, feedprice: -
DoN: -, sunaz: -, sunalt: -
batin01: 5055, batin02: -, batin03: -
batout01: 5852, batout02: -, batout03: -
batmaxsoc01: 100, batmaxsoc02: -, batmaxsoc03: -
batsetsoc01: 25, batsetsoc02: -, batsetsoc03: -
dayname: Mo,
cyclescsm01: 2, csme01: 6547.00, hourscsme01: 1.95, avgcycmntscsm01: 58.50
cyclescsm02: 2, csme02: 4.04, hourscsme02: 3.17, avgcycmntscsm02: 95.00
cyclescsm03: 0, csme03: 0.00
cyclescsm04: 0, csme04: 0.00
Gruß Martin
Sieht alles gut aus (d.h. die pvHistory).
Wie ist denn das Reading pvCorrectionFactor_Auto gesetzt?
Das Reading pvCorrectionFactor_Auto steht auf on_complex_ai.
Meine Readings für die Verbrauchs-Prognose sind alle leer:
special_conForecastTillNextSunrise - 2025-03-10 18:48:33
special_todayConForecastTillSunset 0 Wh 2025-03-10 18:48:33
special_todayConsumptionForecastDay - Wh 2025-03-10 18:48:33
special_todayConsumptionForecast_01 - Wh 2025-03-10 18:48:33
Gruß Martin
ZitatMeine Readings für die Verbrauchs-Prognose sind alle leer:
Ja, das liegt daran dass in der pvCircular die con_all leer ist.
Momentan habe ich noch keine Idee warum.
Du kannst mal ctrlDebug=saveData2Cache einschalten. Zu Beginn einer neuen Stunde sollte es einen Logeintrag geben:
... add consumption into Array (con_all) in Circular - day: ....
Du kannst auch nochmal die komplette pvCircular posten. Ist halt sehr umfangreich.
Hallo Heiko,
zum Stundenwechsel erscheint
kein Eintrag in Log
Zitat... add consumption into Array (con_all) in Circular - day: ....
2025.03.10 19:59:49 1: Forecast DEBUG> setPVhistory -> store Day: 10, Hour: 20, Key: minutescsm04, Value: 0
2025.03.10 19:59:49 1: Forecast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.03.10 19:59:49 1: Forecast DEBUG> setPVhistory -> stored simple - Day: 10, Hour: 20, Key: con, Value: 534
2025.03.10 19:59:49 1: Forecast DEBUG> setPVhistory -> stored compute - Day: 10, Hour: 99, Key: con, Value: 34201
2025.03.10 19:59:49 1: Forecast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 34201 Wh
2025.03.10 20:00:00 3: MQTT2_DEVICE set MQTT2_DVES_xxxxxx on
2025.03.10 20:00:04 1: Forecast DEBUG> setPVhistory -> stored simple - Day: 10, Hour: 21, Key: weatherid, Value: 103
2025.03.10 20:00:04 1: Forecast DEBUG> setPVhistory -> stored simple - Day: 10, Hour: 21, Key: wcc, Value: 79
2025.03.10 20:00:04 1: Forecast DEBUG> setPVhistory -> stored simple - Day: 10, Hour: 21, Key: rr1c, Value: 0.00
Anbei die komplette pvCircular.
Gruß Martin
Also die pvCircular ist so gut wie komplett leer. PV Korrekturen werden auch nicht gespeichert.
Hier ist grundsätzlich etwas im Argen.
Poste bitte ein List deines Devices.
Hallo Heiko,
anbei das List vom Forecast Modul.
Seltsam ist nur, dass die Konfiguration die gleiche von vor dem damaligen Update ist.
Gruß Martin
ZitatSeltsam ist nur, dass die Konfiguration die gleiche von vor dem damaligen Update ist.
Was ist daran seltsam?
Das Listing sieht ok aus, aber es fehlen Steuerreadings die vorhanden sein müssten nach einem Tag, z.B.
setstate SolCast 2025-03-10 20:50:09 .pvCorrectionFactor_Auto_Soll on_complex
setstate SolCast 2025-03-10 01:00:04 .signaldone_01 done
setstate SolCast 2025-03-10 02:00:04 .signaldone_02 done
setstate SolCast 2025-03-10 03:00:04 .signaldone_03 done
setstate SolCast 2025-03-10 04:00:04 .signaldone_04 done
setstate SolCast 2025-03-10 05:00:04 .signaldone_05 done
setstate SolCast 2025-03-10 06:00:01 .signaldone_06 done
setstate SolCast 2025-03-10 07:00:05 .signaldone_07 done
setstate SolCast 2025-03-10 08:00:05 .signaldone_08 done
setstate SolCast 2025-03-10 09:00:04 .signaldone_09 done
setstate SolCast 2025-03-10 10:00:04 .signaldone_10 done
setstate SolCast 2025-03-10 11:00:04 .signaldone_11 done
setstate SolCast 2025-03-10 12:00:04 .signaldone_12 done
setstate SolCast 2025-03-10 13:00:04 .signaldone_13 done
setstate SolCast 2025-03-10 14:00:04 .signaldone_14 done
setstate SolCast 2025-03-10 15:00:04 .signaldone_15 done
setstate SolCast 2025-03-10 16:00:04 .signaldone_16 done
setstate SolCast 2025-03-10 18:46:28 .signaldone_17 done
setstate SolCast 2025-03-10 18:46:28 .signaldone_18 done
setstate SolCast 2025-03-10 19:00:04 .signaldone_19 done
setstate SolCast 2025-03-10 20:00:04 .signaldone_20 done
setstate SolCast 2025-03-10 00:00:05 .signaldone_24 done
Aktuell habe ich keine Idee was da los ist.
Möglicherweise hast du das List nicht mit "Copy for forum.fhem.de" erstellt?
Hallo Heiko,
ZitatMöglicherweise hast du das List nicht mit "Copy for forum.fhem.de" erstellt?
Ja das stimmt, anbei das komplette List, hatte es vorher nur mit
list Forecast erzeugt.
Aber auch im kompletten List fehlen die
.signaldone_x Steuerreadings.
Wir können gerne morgen Abend weitermachen, ich danke dir sehr für deine Unterstützung.
Ich möchte dir nicht deinen Abend blockieren ;-)
Gruß Martin
ZitatAber auch im kompletten List fehlen die .signaldone_x Steuerreadings.
Ja richtig.
Außerdem sieht man schon hier:
setstate Forecast 2025-03-10 20:58:33 Tomorrow_ConsumptionForecast Warte auf weitere Tage mit einer Verbrauchszahl Wh
Stelle mal "set ... pvCorrectionFactor_Auto off"
Ich denke ich sehe das Problem.
Böse Falle ... du hattest dein Device nicht mit "set .. operatingMemory recover-<Datei>" recovert?
Setze das Attr setupInverterDev01 einfach nochmal, so wie es ist.
Guten Morgen Heiko,
Zitatdu hattest dein Device nicht mit "set .. operatingMemory recover-<Datei>" recovert?
Ja genau, mein Fehler.
Vielen Dank für deinen Support, ich werde heute den Ringspeicher sich wieder füllen lassen.
Gruß Martin
Guten Morgen Martin,
ZitatJa genau, mein Fehler.
Halb und halb.
Dadurch war eine Postion in pvCircular nicht gesetzt, deren Fehlen das Füllen verhindert hat.
Mit dem nächsten Update ist diese Gefahr nicht mehr vorhanden. Die entsprechende Stelle habe ich umgebaut.
Es wird aktuell reichen wenn du das Attr setupInverterDev01 einfach nochmal so setzt, so wie es ist.
Grüße,
Heiko
Zitat von: DS_Starter am 10 März 2025, 18:14:34Nur wenn die nominalen String-Peak identisch sind, also z.B. 2 Strings mit je 2kW Peak.
Ah, jetzt. Bei den geprüften Werten sah das für mich wie ein Faktor bzw. prozentualer Zuschlag aus. Aber klar, Einheit "kWp" bedeutet fester Wert, der wird addiert.
Danke.
Guten Morgen,
=>>Thema Netzdienliche Batterieladung mit 2 Batterien:
Das sieht gar nicht mal so eng aus wie Gestern gedacht.
- ChargeRecomended_01 ist seit 07:00 Uhr mehrfach von 1 auf 0 und zurück gewechselt.
- ChargeRecomended_02 ist weiterhin auf 1.
Gruß
300P
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step2 - basics -> Energy expected for charging: 13004.7111111111 Wh, need until maxsoc: 5319 Wh
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 11.03.2025 16:55:00)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step3 - basics -> cantarget: -44 %, newtarget: -44 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step2 - basics -> Energy expected for charging: 12439.2888888889 Wh, need until maxsoc: 4484 Wh
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 11.03.2025 16:55:00)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step3 - basics -> cantarget: -44 %, newtarget: -44 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB25' cap: 2500 W, Power limit: 70 % -> Pmax eff: 1750 W
2025.03.11 08:29:10 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB30' cap: 3000 W, Power limit: 70 % -> Pmax eff: 2100 W
2025.03.11 08:29:10 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB40' cap: 4000 W, Power limit: 70 % -> Pmax eff: 2800 W
2025.03.11 08:29:10 1: Forecast DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 6650 W
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 9016 Wh, Percentage of total capacity: 51.1 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 08 -> 0 (currsoc: 36 %, SoCfc: 36.0 %, soc: 3246 Wh, pvfc: 729, confc: 317, Surp Day: 8804 Wh, Curr PV: 715 W, Curr Consumption: 544 W, Limit: 6650 W)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 09 -> 1 (SoCfc: 41.6 %, soc: 3754 Wh, pvfc: 846, confc: 282, Surp Day: 3935 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 10 -> 1 (SoCfc: 52.8 %, soc: 4759 Wh, pvfc: 1365, confc: 248, Surp Day: 894 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 11 -> 1 (SoCfc: 83.5 %, soc: 7532 Wh, pvfc: 3339, confc: 258, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2595, confc: 401, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1694, confc: 470, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1167, confc: 365, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 650, confc: 347, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 16 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 417, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 17 -> 1 (SoCfc: 96.9 %, soc: 8738 Wh, pvfc: 54, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 18 -> 1 (SoCfc: 93.1 %, soc: 8390 Wh, pvfc: 5, confc: 318, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 19 -> 1 (SoCfc: 89.2 %, soc: 8040 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 20 -> 1 (SoCfc: 85.1 %, soc: 7672 Wh, pvfc: 0, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 21 -> 1 (SoCfc: 81.0 %, soc: 7301 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 22 -> 1 (SoCfc: 77.1 %, soc: 6951 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 11 23 -> 1 (SoCfc: 73.8 %, soc: 6657 Wh, pvfc: 0, confc: 265, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 00 -> 1 (SoCfc: 70.9 %, soc: 6388 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 01 -> 1 (SoCfc: 67.9 %, soc: 6124 Wh, pvfc: 0, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 02 -> 1 (SoCfc: 64.9 %, soc: 5855 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 03 -> 1 (SoCfc: 62.0 %, soc: 5591 Wh, pvfc: 0, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 04 -> 1 (SoCfc: 59.1 %, soc: 5324 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 05 -> 1 (SoCfc: 56.1 %, soc: 5057 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 06 -> 1 (SoCfc: 53.1 %, soc: 4789 Wh, pvfc: 0, confc: 241, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 07 -> 1 (SoCfc: 51.4 %, soc: 4638 Wh, pvfc: 103, confc: 239, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 08 -> 1 (SoCfc: 64.7 %, soc: 5831 Wh, pvfc: 1643, confc: 317, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 09 -> 1 (SoCfc: 79.5 %, soc: 7169 Wh, pvfc: 1769, confc: 282, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 10 -> 1 (SoCfc: 81.4 %, soc: 7342 Wh, pvfc: 440, confc: 248, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 11 -> 1 (SoCfc: 95.9 %, soc: 8644 Wh, pvfc: 1705, confc: 258, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 12 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2156, confc: 401, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 13 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 687, confc: 470, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 14 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1748, confc: 365, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 15 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 727, confc: 347, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 16 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 843, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 17 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1060, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 18 -> 1 (SoCfc: 97.6 %, soc: 8800 Wh, pvfc: 124, confc: 318, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 19 -> 1 (SoCfc: 93.7 %, soc: 8450 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 20 -> 1 (SoCfc: 89.6 %, soc: 8082 Wh, pvfc: 0, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 21 -> 1 (SoCfc: 85.5 %, soc: 7711 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 22 -> 1 (SoCfc: 81.6 %, soc: 7361 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 01 relLoad 12 23 -> 1 (SoCfc: 78.4 %, soc: 7067 Wh, pvfc: 0, confc: 265, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 Charge Rcmd - Installed Battery capacity: 8624 Wh, Percentage of total capacity: 48.9 %
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 08 -> 1 (currsoc: 43 %, SoCfc: 47.1 %, soc: 4064 Wh, pvfc: 698, confc: 303, Surp Day: 0 Wh, Curr PV: 715 W, Curr Consumption: 544 W, Limit: 6650 W)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 09 -> 1 (SoCfc: 52.8 %, soc: 4550 Wh, pvfc: 810, confc: 270, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 10 -> 1 (SoCfc: 63.9 %, soc: 5511 Wh, pvfc: 1306, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 11 -> 1 (SoCfc: 94.7 %, soc: 8164 Wh, pvfc: 3194, confc: 246, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2482, confc: 384, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1621, confc: 450, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1117, confc: 350, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 622, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 16 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 399, confc: 287, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 17 -> 1 (SoCfc: 96.9 %, soc: 8360 Wh, pvfc: 52, confc: 290, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 18 -> 1 (SoCfc: 93.1 %, soc: 8028 Wh, pvfc: 5, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 19 -> 1 (SoCfc: 89.2 %, soc: 7694 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 20 -> 1 (SoCfc: 85.1 %, soc: 7342 Wh, pvfc: 0, confc: 317, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 21 -> 1 (SoCfc: 81.0 %, soc: 6986 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 22 -> 1 (SoCfc: 77.1 %, soc: 6652 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 11 23 -> 1 (SoCfc: 73.9 %, soc: 6371 Wh, pvfc: 0, confc: 253, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 00 -> 1 (SoCfc: 70.9 %, soc: 6113 Wh, pvfc: 0, confc: 232, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 01 -> 1 (SoCfc: 67.9 %, soc: 5860 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 02 -> 1 (SoCfc: 65.0 %, soc: 5603 Wh, pvfc: 0, confc: 231, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 03 -> 1 (SoCfc: 62.0 %, soc: 5350 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 04 -> 1 (SoCfc: 59.1 %, soc: 5096 Wh, pvfc: 0, confc: 229, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 05 -> 1 (SoCfc: 56.1 %, soc: 4840 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 06 -> 1 (SoCfc: 53.1 %, soc: 4583 Wh, pvfc: 0, confc: 231, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 07 -> 1 (SoCfc: 51.5 %, soc: 4439 Wh, pvfc: 99, confc: 229, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 08 -> 1 (SoCfc: 64.7 %, soc: 5580 Wh, pvfc: 1571, confc: 303, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 09 -> 1 (SoCfc: 79.6 %, soc: 6861 Wh, pvfc: 1693, confc: 270, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 10 -> 1 (SoCfc: 81.5 %, soc: 7026 Wh, pvfc: 421, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 11 -> 1 (SoCfc: 95.9 %, soc: 8272 Wh, pvfc: 1630, confc: 246, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 12 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2062, confc: 384, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 13 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 658, confc: 450, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 14 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1672, confc: 350, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 15 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 695, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 16 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 807, confc: 287, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 17 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1013, confc: 290, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 18 -> 1 (SoCfc: 97.6 %, soc: 8417 Wh, pvfc: 118, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 19 -> 1 (SoCfc: 93.7 %, soc: 8083 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 20 -> 1 (SoCfc: 89.6 %, soc: 7731 Wh, pvfc: 0, confc: 317, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 21 -> 1 (SoCfc: 85.5 %, soc: 7375 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 22 -> 1 (SoCfc: 81.6 %, soc: 7041 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:10 1: Forecast DEBUG> Bat 02 relLoad 12 23 -> 1 (SoCfc: 78.4 %, soc: 6760 Wh, pvfc: 0, confc: 253, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step2 - basics -> Energy expected for charging: 13004.7111111111 Wh, need until maxsoc: 5319 Wh
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 11.03.2025 16:55:00)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step3 - basics -> cantarget: -44 %, newtarget: -44 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step2 - basics -> Energy expected for charging: 12439.2888888889 Wh, need until maxsoc: 4484 Wh
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step2 - calc care SoC -> docare: 0, care SoC: 5 %, use preliminary Target: 5 % (care SoC calculation & activation postponed to after 11.03.2025 16:55:00)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step3 - basics -> cantarget: -44 %, newtarget: -44 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step3 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step4 - basics -> docare: 0, lowSoc: 10 %, upSoc: 30 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step4 - observe low/up limits -> Target: 10 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB25' cap: 2500 W, Power limit: 70 % -> Pmax eff: 1750 W
2025.03.11 08:29:12 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB30' cap: 3000 W, Power limit: 70 % -> Pmax eff: 2100 W
2025.03.11 08:29:12 1: Forecast DEBUG> Bat XX Charge Rcmd - Inverter 'SB40' cap: 4000 W, Power limit: 70 % -> Pmax eff: 2800 W
2025.03.11 08:29:12 1: Forecast DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 6650 W
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 9016 Wh, Percentage of total capacity: 51.1 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 08 -> 0 (currsoc: 36 %, SoCfc: 36.0 %, soc: 3246 Wh, pvfc: 729, confc: 317, Surp Day: 8792 Wh, Curr PV: 714 W, Curr Consumption: 561 W, Limit: 6650 W)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 09 -> 1 (SoCfc: 41.6 %, soc: 3754 Wh, pvfc: 846, confc: 282, Surp Day: 3929 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 10 -> 1 (SoCfc: 52.8 %, soc: 4759 Wh, pvfc: 1365, confc: 248, Surp Day: 891 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 11 -> 1 (SoCfc: 83.5 %, soc: 7532 Wh, pvfc: 3339, confc: 258, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2595, confc: 401, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1694, confc: 470, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1167, confc: 365, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 650, confc: 347, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 16 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 417, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 17 -> 1 (SoCfc: 96.9 %, soc: 8738 Wh, pvfc: 54, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 18 -> 1 (SoCfc: 93.1 %, soc: 8390 Wh, pvfc: 5, confc: 318, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 19 -> 1 (SoCfc: 89.2 %, soc: 8040 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 20 -> 1 (SoCfc: 85.1 %, soc: 7672 Wh, pvfc: 0, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 21 -> 1 (SoCfc: 81.0 %, soc: 7301 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 22 -> 1 (SoCfc: 77.1 %, soc: 6951 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 11 23 -> 1 (SoCfc: 73.8 %, soc: 6657 Wh, pvfc: 0, confc: 265, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 00 -> 1 (SoCfc: 70.9 %, soc: 6388 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 01 -> 1 (SoCfc: 67.9 %, soc: 6124 Wh, pvfc: 0, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 02 -> 1 (SoCfc: 64.9 %, soc: 5855 Wh, pvfc: 0, confc: 242, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 03 -> 1 (SoCfc: 62.0 %, soc: 5591 Wh, pvfc: 0, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 04 -> 1 (SoCfc: 59.1 %, soc: 5324 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 05 -> 1 (SoCfc: 56.1 %, soc: 5057 Wh, pvfc: 0, confc: 240, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 06 -> 1 (SoCfc: 53.1 %, soc: 4789 Wh, pvfc: 0, confc: 241, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 07 -> 1 (SoCfc: 51.4 %, soc: 4638 Wh, pvfc: 103, confc: 239, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 08 -> 1 (SoCfc: 64.7 %, soc: 5831 Wh, pvfc: 1643, confc: 317, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 09 -> 1 (SoCfc: 79.5 %, soc: 7169 Wh, pvfc: 1769, confc: 282, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 10 -> 1 (SoCfc: 81.4 %, soc: 7342 Wh, pvfc: 440, confc: 248, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 11 -> 1 (SoCfc: 95.9 %, soc: 8644 Wh, pvfc: 1705, confc: 258, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 12 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 2156, confc: 401, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 13 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 687, confc: 470, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 14 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1748, confc: 365, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 15 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 727, confc: 347, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 16 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 843, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 17 -> 1 (SoCfc: 100.0 %, soc: 9016 Wh, pvfc: 1060, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 18 -> 1 (SoCfc: 97.6 %, soc: 8800 Wh, pvfc: 124, confc: 318, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 19 -> 1 (SoCfc: 93.7 %, soc: 8450 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 20 -> 1 (SoCfc: 89.6 %, soc: 8082 Wh, pvfc: 0, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 21 -> 1 (SoCfc: 85.5 %, soc: 7711 Wh, pvfc: 0, confc: 334, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 22 -> 1 (SoCfc: 81.6 %, soc: 7361 Wh, pvfc: 0, confc: 315, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 01 relLoad 12 23 -> 1 (SoCfc: 78.4 %, soc: 7067 Wh, pvfc: 0, confc: 265, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 Charge Rcmd - Installed Battery capacity: 8624 Wh, Percentage of total capacity: 48.9 %
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 08 -> 1 (currsoc: 43 %, SoCfc: 47.1 %, soc: 4064 Wh, pvfc: 698, confc: 303, Surp Day: 0 Wh, Curr PV: 714 W, Curr Consumption: 561 W, Limit: 6650 W)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 09 -> 1 (SoCfc: 52.8 %, soc: 4550 Wh, pvfc: 810, confc: 270, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 10 -> 1 (SoCfc: 63.9 %, soc: 5511 Wh, pvfc: 1306, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 11 -> 1 (SoCfc: 94.7 %, soc: 8164 Wh, pvfc: 3194, confc: 246, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 12 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2482, confc: 384, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 13 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1621, confc: 450, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 14 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1117, confc: 350, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 15 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 622, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 16 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 399, confc: 287, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 17 -> 1 (SoCfc: 96.9 %, soc: 8360 Wh, pvfc: 52, confc: 290, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 18 -> 1 (SoCfc: 93.1 %, soc: 8028 Wh, pvfc: 5, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 19 -> 1 (SoCfc: 89.2 %, soc: 7694 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 20 -> 1 (SoCfc: 85.1 %, soc: 7342 Wh, pvfc: 0, confc: 317, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 21 -> 1 (SoCfc: 81.0 %, soc: 6986 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 22 -> 1 (SoCfc: 77.1 %, soc: 6652 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 11 23 -> 1 (SoCfc: 73.9 %, soc: 6371 Wh, pvfc: 0, confc: 253, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 00 -> 1 (SoCfc: 70.9 %, soc: 6113 Wh, pvfc: 0, confc: 232, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 01 -> 1 (SoCfc: 67.9 %, soc: 5860 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 02 -> 1 (SoCfc: 65.0 %, soc: 5603 Wh, pvfc: 0, confc: 231, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 03 -> 1 (SoCfc: 62.0 %, soc: 5350 Wh, pvfc: 0, confc: 228, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 04 -> 1 (SoCfc: 59.1 %, soc: 5096 Wh, pvfc: 0, confc: 229, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 05 -> 1 (SoCfc: 56.1 %, soc: 4840 Wh, pvfc: 0, confc: 230, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 06 -> 1 (SoCfc: 53.1 %, soc: 4583 Wh, pvfc: 0, confc: 231, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 07 -> 1 (SoCfc: 51.5 %, soc: 4439 Wh, pvfc: 99, confc: 229, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 08 -> 1 (SoCfc: 64.7 %, soc: 5580 Wh, pvfc: 1571, confc: 303, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 09 -> 1 (SoCfc: 79.6 %, soc: 6861 Wh, pvfc: 1693, confc: 270, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 10 -> 1 (SoCfc: 81.5 %, soc: 7026 Wh, pvfc: 421, confc: 238, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 11 -> 1 (SoCfc: 95.9 %, soc: 8272 Wh, pvfc: 1630, confc: 246, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 12 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 2062, confc: 384, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 13 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 658, confc: 450, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 14 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1672, confc: 350, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 15 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 695, confc: 331, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 16 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 807, confc: 287, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 17 -> 1 (SoCfc: 100.0 %, soc: 8624 Wh, pvfc: 1013, confc: 290, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 18 -> 1 (SoCfc: 97.6 %, soc: 8417 Wh, pvfc: 118, confc: 304, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 19 -> 1 (SoCfc: 93.7 %, soc: 8083 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 20 -> 1 (SoCfc: 89.6 %, soc: 7731 Wh, pvfc: 0, confc: 317, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 21 -> 1 (SoCfc: 85.5 %, soc: 7375 Wh, pvfc: 0, confc: 320, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 22 -> 1 (SoCfc: 81.6 %, soc: 7041 Wh, pvfc: 0, confc: 301, Surp Day: 0 Wh)
2025.03.11 08:29:12 1: Forecast DEBUG> Bat 02 relLoad 12 23 -> 1 (SoCfc: 78.4 %, soc: 6760 Wh, pvfc: 0, confc: 253, Surp Day: 0 Wh)Nachsatz _ Tagesergebnis
Zwischen 07:00 und heutiger MaxPVForecastTime (12:00 Uhr) wird mehrfach ChargeRecomended_01 umgeschaltet.
ChargeRecomended_02 weiterhin keine Wechsel festgestellt.
Beide Batterien waren seit ca. 15:20 Uhr "voll" - weiterhin etwas Einspeisung.
@all,
morgen früf ist die V 1.47.3 im Update enthalten.
Der Batterie Key "show" kann nun erweitert werden um die Bat-Anzeige über oder unter den Balken anzeigen zu lassen.
Die Angabe erfolgt in dieser Weise:
show=1:top
show=1:bottom
show=2:top
show=2:bottom
Ansonsten sind kleinere Fixes enthalten die sich aus dem letzten Problemfall ergaben.
LG,
Heiko
Zitat von: 300P am 11 März 2025, 08:51:42Guten Morgen,
=>>Thema Netzdienliche Batterieladung mit 2 Batterien:
< snip >
Nachsatz _ Tagesergebnis
Zwischen 07:00 und heutiger MaxPVForecastTime (12:00 Uhr) wird mehrfach ChargeRecomended_01 umgeschaltet.
ChargeRecomended_02 weiterhin keine Wechsel festgestellt.
Beide Batterien waren seit ca. 15:20 Uhr "voll" - weiterhin etwas Einspeisung.
Moin, in Deinem Diagramm hast Du Tibberohnevertrag eingetragen,
wo kannst Du die Preise abfragen? Ich dachte das geht nur für Kunden.
VG Christian
Zitat von: 300P am 10 März 2025, 15:49:18@Alle:
Gibt es jemanden der mit 2 / 3 Batterien Erfahrung hat oder es nutzt ?
Hallo 300?
wodrüber steuerst Du denn die 2 Speicher? Bei Kostal geht nur ein Speicher, da sich ansonsten die Regelung hochschaukelt.
Man kann jedoch mehrere gleiche Speicher bei BYD koppeln, die dann vom WR als ein Speicher behandelt werden.
VG Christian
Zitat von: ch.eick am 12 März 2025, 14:12:14Moin, in Deinem Diagramm hast Du Tibberohnevertrag eingetragen,
wo kannst Du die Preise abfragen? Ich dachte das geht nur für Kunden.
VG Christian
Da gibt es eine spezielle Seite ;D
Dort kann man mit etwas Verspätung (morgens so ca. ab 07:00 Uhr) die Preise für den aktuellen Tag abfragen.
Für Statistik reicht das allemal. 8)
Bei Awattar geht sowas ähnliches auch. :)
Mache dazu einen neuen Thread auf wenn gewünscht.... O:-)
Gruß
300P
EDIT:
Hier der Link dazu : HTTPMOD -Tibber ohne Vertrag - Preisabfrage (https://forum.fhem.de/index.php?topic=141062.msg1336579#msg1336579)
Zitat von: ch.eick am 12 März 2025, 14:23:42Hallo 300?
wodrüber steuerst Du denn die 2 Speicher? Bei Kostal geht nur ein Speicher, da sich ansonsten die Regelung hochschaukelt.
Man kann jedoch mehrere gleiche Speicher bei BYD koppeln, die dann vom WR als ein Speicher behandelt werden.
Ich habe 2 Stück SMA-Wechselrichter (SBS25) mit jeweils einer LG10H Batterie.
Die sind komplett unabhängig voneinander ansprechbar. O:-)
Gruß
300P
Frage zu "graphicHeaderOwnspecValForm"
{
'Today_PVforecast' =>'(sprintf "%.1f", ($VALUE / 1000))." kWh"',
}
Ich hab da Schwierigkeiten mit der Einheit " kWh"
Egal, was ich an dieser Stelle notiere, es wird angezeigt, ausser kWh, dann ist die Formatierung "wirkungslos"; das "h" scheint irgendwie zu stören?
Zitat von: grappa24 am 13 März 2025, 10:17:13Frage zu "graphicHeaderOwnspecValForm"
{
'Today_PVforecast' =>'(sprintf "%.1f", ($VALUE / 1000))." kWh"',
}
Ich hab da Schwierigkeiten mit der Einheit " kWh"
Egal, was ich an dieser Stelle notiere, es wird angezeigt, ausser kWh, dann ist die Formatierung "wirkungslos"; das "h" scheint irgendwie zu stören?
Warum nicht?
(sprintf("%.1f kWh", $VALUE / 1000))
Zitat von: tobi01001 am 13 März 2025, 10:47:46Warum nicht?
(sprintf("%.1f kWh", $VALUE / 1000))
Wenn, dann so laut Doku:
'Today_PVforecast' => '(sprintf "%.1f", ($VALUE / 1000))." kWh"',aber da tritt der gleiche Effekt ein, ohne "h" gehts, mit "h" nicht. Das kleine "h" scheint eine besondere Funktion auszulösen / zu haben aber nur am Ende des Strings mit der Einheit.
Hallo zusammen,
ZitatFrage zu "graphicHeaderOwnspecValForm"
Code Auswählen
{
'Today_PVforecast' =>'(sprintf "%.1f", ($VALUE / 1000))." kWh"',
}
Ich hab da Schwierigkeiten mit der Einheit " kWh"
Wenn der anzuzeigende Wert die Einheit Wh oder kWh hat, wird die Anzeige automatisch entsprechend des Settings des Attr graphicEnergyUnit berechnet und ausgeschrieben. Dadurch vereinfacht sich das Handling falls man viele solcher Werte anzeigen will und die Anzeigeinheit umstellt.
In deinem Fall kannst du es so lösen:
{
'Today_PVforecast' => "(sprintf '%.1f kWh', ($VALUE / 1000))",
}
Das vor der kWh bewirkt, dass 'kWh' nicht als solche erkannt/gewertet wird und die automatische Umsetzung unterbleibt.
Ich werde es noch im Wiki festhalten.
LG
super, vielen Dank!
Da wir gerade beim "Schönmachen" sind, eine weitere Frage zum "graphicHeaderOwnspec":
Das "Eingabefeld Limit setzen:" ist ein Reading aus meiner BYD_Battery
Limit setzen:BatConfigReserve@BYD_Battery und ist mir leider etwas zu "lang" bzw. macht die zweite Spalte unnötig breit. Gibts da eine Möglichkeit, das Feld kürzer auszugeben?
Der Vollständigkeit halber hier die gesamte Defintion des Bereichs:#Batterie
Management:userFn_BatterySoCManagement
Limit setzen:BatConfigReserve@BYD_Battery
SoC evcc tablet:batteryPercent@SAMSUNG_SM_X210
:
SoC aktuell:BatteryChargeFormatted@BYD_Battery
PV heute:Today_PVforecast
:
:
Limit aktuell:BatConfigReserveFormatted@BYD_Battery
Verbrauch heute:special_todayConsumption
:
:
Limit optimal:Battery_OptimumTargetSoC_01@solErtrag
PV morgen:Tomorrow_PVforecast
:
:
Ladeanforderung:Battery_ChargeRequest_01@solErtrag
Verbrauch morgen:Tomorrow_ConsumptionForecast
:
:
Laden empfohlen:Battery_ChargeRecommended_01@solErtrag
Guten Morgen,
ZitatGibts da eine Möglichkeit, das Feld kürzer auszugeben?
Ja. Das musst du allerdings im Quellendevice machen und das Feld kürzen.
Das geht mit widgetOverride, z.B.:
attr BYD_Battery BatConfigReserve:textFieldNL-long,,5
LG,
Heiko
Hallo zusammen,
ein kleiner Ausblick ... OpenMeteo bietet ab sofort eine Satelliten gestützte Variante der Strahlungsprognose an.
ZitatMit Hilfe von Satellitensensoren kann die direkte und diffuse Sonneneinstrahlung für jeden Ort geschätzt werden. Obwohl zusätzliche Daten aus Wettermodellen wie Aerosoldicke, Ozongehalt, Luftfeuchtigkeit, Temperatur und Luftdruck erforderlich sind, um die Berechnungen zu verbessern, sind die resultierenden Sonnenstrahlungsdaten im Allgemeinen von guter Qualität.
Die Arbeit mit Satellitendaten ist mit einer Reihe von Herausforderungen verbunden, wie z. B. der Verarbeitung und Speicherung großer Datenmengen mit hoher zeitlicher und räumlicher Auflösung. Open-Meteo ist jedoch auf die Verarbeitung großer Mengen von gerasterten Daten spezialisiert und bietet eine schnelle API, so dass Satellitenstrahlungsdaten perfekt geeignet sind.
In einem ersten Schritt wurden vier verschiedene Satellitendatensätze integriert. Drei davon verwenden EUMETSAT-Daten von den MSG- und IODC-Satelliten, um Südamerika, Europa, Afrika und Teile von Indien abzudecken. Der vierte verwendet Daten des JMA Himawari-Satelliten, um Asien, Australien und Neuseeland abzudecken. Die Daten der GOES-Satelliten der NASA für Nord- und Südamerika sind noch nicht integriert worden.
Übersetzt mit DeepL.com (kostenlose Version)
Die Spezialität ist die Kombinierbarkeit mit DWD ICON Modellen.
Ihr könnt es euch hier (https://open-meteo.com/en/docs/satellite-radiation-api) schon mal anschauen.
Die Integration dieser API habe ich in meinem BackLog vorgesehen.
LG
@all,
morgen früh ist die V 1.48.0 im Update.
Die Balkengrafik Ebene 3 kann aktiviert werden indem die Attr graphicBeam5Content bzw. graphicBeam6Content gesetzt werden.
Die obsoleten Attr ctrlAIdataStorageDuration, ctrlAIshiftTrainStart sind jetzt entfernt.
LG,
Heiko
Moin,
ACHTUNG wer updaten will. Die 01_FHEMWEB.pm im heutigen Update ist defekt. Hinweis und Lösung wer evtl. schon betroffen ist siehe https://forum.fhem.de/index.php?msg=1336834.
UPDATE: Rudi hat das Problem bereits gefixt.
LG
Moin Heiko,
ich bekomme in den letzten Tagen immer mal wieder (insbesondere kurz nach Neustarts) folgende Fehlermeldungen:
screen.png
Hast Du eine spontane Idee dazu? Ich hatte meinen GraphicHeaderOwnSpec in Verdacht:
#Aktuell:
Überschuss:Current_Surplus
Einspeisung:Current_GridFeedIn
Netzbezug:Current_GridConsumption
Autarkie-Rate:Current_AutarkyRate
#Heute:
Erzeugt:Today_PVreal
Bezogen:special_todayGridConsumption
Eingespeist:special_todayGridFeedIn
Verbraucht:special_todayConsumption
#Batterie:
Status:Akkustatus@Enphase
SoC (%):StorageFullPercent@Enphase
Heute geladen:special_todayBatInSum
Heute entladen:special_todayBatOutSum
Habe es am Anfang schon mit Ü und mit Ü versucht. Beides bringt das gleiche Ergebnis.
Danke für jeden Ansatz!
Viel Grüße,
Peter
Nachtrag: Hier nochmal ein komplettes list:
define SolarForecast SolarForecast
attr SolarForecast DbLogExclude .*
attr SolarForecast DbLogInclude Current_AutarkyRate:60,AllPVforecastsToEvent,LastHourPVforecast,LastHourPVreal
attr SolarForecast affectConsForecastIdentWeekdays 1
attr SolarForecast affectConsForecastInPlanning 0
attr SolarForecast consumer01 KlimaanlagePwr switchdev=Klimaanlage_Sw type=noSchedule power=750 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=Ventilator_fett auto=Automatik interruptable=1
attr SolarForecast consumer02 MQTT2_Luftentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=light_ceiling auto=Automatik
attr SolarForecast consumer03 MQTT2_Spelunkenentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=Ventilator_fett auto=Automatik
attr SolarForecast consumer04 MQTT2_ShellyGeschirrspueler type=noSchedule power=1500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=scene_dishwasher auto=Automatik
attr SolarForecast consumer05 Trockner_Pwr switchdev=Trockner type=noSchedule power=450 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=scene_clothes_dryer auto=Automatik
attr SolarForecast consumer06 Waschmaschine_Pwr switchdev=Waschmaschine type=noSchedule power=1800 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=scene_washing_machine auto=Automatik
attr SolarForecast consumer07 Stromverbrauch_Buero type=noSchedule power=500 pcurr=pcurr:W etotal=etotal:Wh icon=scene_office auto=Automatik
attr SolarForecast consumer08 Stromverbrauch_WoZi type=noSchedule power=500 pcurr=pcurr:W etotal=etotal:Wh icon=scene_livingroom auto=Automatik
attr SolarForecast consumer09 MQTT2_KlimaODU type=noSchedule power=1500 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=frost auto=Automatik
attr SolarForecast consumer10 MQTT2_ShellyPlugKuechenKuehlschrank type=noSchedule power=100 pcurr=switch_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_big auto=Automatik
attr SolarForecast consumer11 MQTT2_PlugKaffeemaschine type=noSchedule power=2500 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=scene_cockle_stove auto=Automatik
attr SolarForecast consumer12 MQTT2_ShellyPlugKellerKuehlschrank type=noSchedule power=150 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_small auto=Automatik
attr SolarForecast consumer13 ShellyplugSchuppen type=noSchedule power=100 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=building_carport_socket auto=Automatik
attr SolarForecast consumer14 HM_56DBA8_Sw_01 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian
attr SolarForecast consumer15 WallboxLeistungssumme type=other power=11000 pcurr=power:W etotal=total:Wh on=on off=off auto=Automatik mintime=60 icon=wallbox exconfc=1
attr SolarForecast consumer16 HM_35FA43_Sw_07 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian
attr SolarForecast consumerLegend icon_bottom
attr SolarForecast ctrlDebug none
attr SolarForecast ctrlGenPVdeviation continuously
attr SolarForecast ctrlInterval 5
attr SolarForecast ctrlLanguage DE
attr SolarForecast ctrlSpecialReadings todayBatInSum,todayBatOutSum,todayConsumption,todayGridConsumption,todayGridFeedIn
attr SolarForecast event-aggregator Current_AutarkyRate:150:linear:mean
attr SolarForecast event-min-interval .*:300
attr SolarForecast event-on-change-reading .*
attr SolarForecast flowGraphicControl animate=1 consumerdist=110 showconsumerremaintime=0 h2consumerdist=50 strokewidth=10
attr SolarForecast graphicBeam1Content pvReal
attr SolarForecast graphicBeam2Content pvForecast
attr SolarForecast graphicBeam3Content consumptionForecast
attr SolarForecast graphicBeam4Content consumption
attr SolarForecast graphicBeamHeightLevel1 250
attr SolarForecast graphicBeamHeightLevel2 250
attr SolarForecast graphicHeaderDetail all
attr SolarForecast graphicHeaderOwnspec #Aktuell:\
Ü;berschuss:Current_Surplus\
Einspeisung:Current_GridFeedIn\
Netzbezug:Current_GridConsumption\
Autarkie-Rate:Current_AutarkyRate\
#Heute:\
Erzeugt:Today_PVreal\
Bezogen:special_todayGridConsumption\
Eingespeist:special_todayGridFeedIn\
Verbraucht:special_todayConsumption\
#Batterie:\
Status:Akkustatus@Enphase\
SoC ;(%):StorageFullPercent@Enphase\
Heute ;geladen:special_todayBatInSum\
Heute ;entladen:special_todayBatOutSum
attr SolarForecast graphicHistoryHour 4
attr SolarForecast graphicHourStyle :00
attr SolarForecast graphicSelect both
attr SolarForecast graphicShowDiff bottom
attr SolarForecast graphicShowNight 1
attr SolarForecast room Garten->PV-Anlage
attr SolarForecast setupBatteryDev01 Enphase pin=StorageFeedIn:W pout=StorageConsumption:W intotal=StorageWhCharged:Wh outtotal=StorageWhDischarged:Wh charge=StorageFullPercent cap=7000 show=1:bottom asynchron=1
attr SolarForecast setupInverterDev01 Enphase pv=wNowProduction:W etotal=whTodayProduction:Wh capacity=10000 asynchron=1
attr SolarForecast setupInverterStrings Osten,Westen
attr SolarForecast setupMeterDev MQTT2_SmartMeterReader gcon=Bezug:W contotal=ENERGY_Total:kWh gfeedin=Einspeisung:W feedtotal=ENERGY_Supply:kWh asynchron=1
attr SolarForecast setupRadiationAPI dwd
attr SolarForecast setupStringPeak Osten=4 Westen=6.4
attr SolarForecast setupWeatherDev1 dwd
attr SolarForecast userReadings Current_Surplus_Num {my $val = ReadingsVal("SolarForecast", "Current_Surplus", "0 W");; return substr($val, 0, index($val, " "));;}
# FUUID 651cfe6b-f33f-e199-c4fb-916e33f2d14b5241
# FVERSION 76_SolarForecast.pm:v1.48.0-s29752/2025-03-14
# LCACHEFILE last write time: 09:02:45 File: ./FHEM/FhemUtils/AIraw_SolarForecast_SolarForecast
# MODE Automatic / Event-controlled - next planned Cycletime: 09:14:39
# MODEL DWD
# NAME SolarForecast
# NOTIFYDEV MQTT2_SmartMeterReader,KlimaanlagePwr,Klimaanlage_Sw,MQTT2_Luftentfeuchter,MQTT2_Spelunkenentfeuchter,MQTT2_ShellyGeschirrspueler,Trockner_Pwr,Trockner,Waschmaschine_Pwr,Waschmaschine,Stromverbrauch_Buero,Stromverbrauch_WoZi,MQTT2_KlimaODU,MQTT2_ShellyPlugKuechenKuehlschrank,MQTT2_PlugKaffeemaschine,MQTT2_ShellyPlugKellerKuehlschrank,ShellyplugSchuppen,HM_56DBA8_Sw_01,WallboxLeistungssumme,HM_35FA43_Sw_07,Enphase
# NR 776
# NTFY_ORDER 50-SolarForecast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 305
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV SolarForecast
# SPGROOM
# VERSION 1.48.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 68
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:2032
# telnet telnetForBlockingFn_1742025762.17026_127.0.0.1_60824
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name SolarForecast
# tsnext 1742035688.92072
# Helper:
# DBLOG:
# Current_AutarkyRate:
# logdb:
# TIME 1742026353.46793
# VALUE 94.3535034392045
# LastHourPVforecast:
# logdb:
# TIME 1742026367.08779
# VALUE 1243
# LastHourPVreal:
# logdb:
# TIME 1742026367.08779
# VALUE 486
# OLDREADINGS:
# READINGS:
# 2025-03-15 09:14:34 Battery_ChargeRecommended_01 1
# 2025-03-15 09:14:34 Current_AutarkyRate 94 %
# 2025-03-15 09:14:34 Current_BatCharge_01 18 %
# 2025-03-15 09:14:34 Current_Consumption 773 W
# 2025-03-15 09:14:34 Current_GridConsumption 49 W
# 2025-03-15 09:14:34 Current_GridFeedIn 0 W
# 2025-03-15 09:14:34 Current_PV 2686 W
# 2025-03-15 09:14:34 Current_PowerBatIn_01 1962 W
# 2025-03-15 09:14:34 Current_PowerBatOut_01 0 W
# 2025-03-15 09:14:34 Current_SelfConsumption 724 W
# 2025-03-15 09:14:34 Current_SelfConsumptionRate 27 %
# 2025-03-15 09:14:34 Current_Surplus 1913 W
# 2025-03-15 09:14:35 Current_Surplus_Num 1913
# 2025-03-15 09:00:00 LastHourGridconsumptionReal 12 Wh
# 2025-03-15 09:00:00 LastHourPVforecast 1243 Wh
# 2025-03-15 09:00:00 LastHourPVreal 486 Wh
# 2025-03-15 09:14:34 NextHours_Sum01_PVforecast 2442 Wh
# 2025-03-15 09:14:34 NextHours_Sum02_PVforecast 5734 Wh
# 2025-03-15 09:14:34 NextHours_Sum03_PVforecast 9557 Wh
# 2025-03-15 09:14:34 NextHours_Sum04_ConsumptionForecast 1938 Wh
# 2025-03-15 09:14:34 NextHours_Sum04_PVforecast 13508 Wh
# 2025-03-15 09:14:34 RestOfDayConsumptionForecast 9611 Wh
# 2025-03-15 09:14:34 RestOfDayPVforecast 19709 Wh
# 2025-03-15 00:59:56 Today_Hour01_BatIn_01 0 Wh
# 2025-03-15 00:59:56 Today_Hour01_BatOut_01 838 Wh
# 2025-03-15 00:59:56 Today_Hour01_GridConsumption 39 Wh
# 2025-03-15 00:59:56 Today_Hour01_GridFeedIn 0 Wh
# 2025-03-15 00:59:56 Today_Hour01_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
# 2025-03-15 01:59:35 Today_Hour02_BatIn_01 0 Wh
# 2025-03-15 01:59:35 Today_Hour02_BatOut_01 471 Wh
# 2025-03-15 01:59:35 Today_Hour02_GridConsumption 47 Wh
# 2025-03-15 01:59:35 Today_Hour02_GridFeedIn 0 Wh
# 2025-03-15 01:59:35 Today_Hour02_PVreal 0 Wh
# 2025-03-15 02:59:27 Today_Hour03_BatIn_01 0 Wh
# 2025-03-15 02:59:27 Today_Hour03_BatOut_01 0 Wh
# 2025-03-15 02:59:27 Today_Hour03_GridConsumption 0 Wh
# 2025-03-15 02:59:27 Today_Hour03_GridFeedIn 0 Wh
# 2025-03-15 02:59:27 Today_Hour03_PVreal 0 Wh
# 2025-03-15 03:59:55 Today_Hour04_BatIn_01 0 Wh
# 2025-03-15 03:59:55 Today_Hour04_BatOut_01 0 Wh
# 2025-03-15 03:59:55 Today_Hour04_GridConsumption 251 Wh
# 2025-03-15 03:59:55 Today_Hour04_GridFeedIn 0 Wh
# 2025-03-15 03:59:55 Today_Hour04_PVreal 0 Wh
# 2025-03-15 04:59:55 Today_Hour05_BatIn_01 0 Wh
# 2025-03-15 04:59:55 Today_Hour05_BatOut_01 0 Wh
# 2025-03-15 04:59:55 Today_Hour05_GridConsumption 463 Wh
# 2025-03-15 04:59:55 Today_Hour05_GridFeedIn 0 Wh
# 2025-03-15 04:59:55 Today_Hour05_PVreal 0 Wh
# 2025-03-15 05:59:59 Today_Hour06_BatIn_01 0 Wh
# 2025-03-15 05:59:59 Today_Hour06_BatOut_01 0 Wh
# 2025-03-15 05:59:59 Today_Hour06_GridConsumption 443 Wh
# 2025-03-15 05:59:59 Today_Hour06_GridFeedIn 0 Wh
# 2025-03-15 05:59:59 Today_Hour06_PVreal 0 Wh
# 2025-03-15 06:59:58 Today_Hour07_BatIn_01 0 Wh
# 2025-03-15 06:59:58 Today_Hour07_BatOut_01 0 Wh
# 2025-03-15 06:59:58 Today_Hour07_GridConsumption 496 Wh
# 2025-03-15 06:59:58 Today_Hour07_GridFeedIn 0 Wh
# 2025-03-15 06:59:58 Today_Hour07_PVforecast 38 Wh
# 2025-03-15 06:59:58 Today_Hour07_PVreal 0 Wh
# 2025-03-15 07:59:58 Today_Hour08_BatIn_01 87 Wh
# 2025-03-15 07:59:58 Today_Hour08_BatOut_01 853 Wh
# 2025-03-15 07:59:58 Today_Hour08_GridConsumption 207 Wh
# 2025-03-15 07:59:58 Today_Hour08_GridFeedIn 6 Wh
# 2025-03-15 07:59:58 Today_Hour08_PVforecast 729 Wh
# 2025-03-15 07:59:58 Today_Hour08_PVreal 588 Wh
# 2025-03-15 08:19:14 Today_Hour09_BatIn_01 221 Wh
# 2025-03-15 08:19:14 Today_Hour09_BatOut_01 0 Wh
# 2025-03-15 08:19:14 Today_Hour09_GridConsumption 12 Wh
# 2025-03-15 08:19:14 Today_Hour09_GridFeedIn 6 Wh
# 2025-03-15 08:19:14 Today_Hour09_PVforecast 1243 Wh
# 2025-03-15 08:19:14 Today_Hour09_PVreal 486 Wh
# 2025-03-15 09:14:34 Today_Hour10_BatIn_01 656 Wh
# 2025-03-15 09:14:34 Today_Hour10_BatOut_01 0 Wh
# 2025-03-15 09:14:34 Today_Hour10_GridConsumption 38 Wh
# 2025-03-15 09:14:34 Today_Hour10_GridFeedIn 16 Wh
# 2025-03-15 09:14:34 Today_Hour10_PVforecast 2209 Wh
# 2025-03-15 09:14:34 Today_Hour10_PVreal 1400 Wh
# 2025-03-15 09:14:34 Today_Hour11_PVforecast 3141 Wh
# 2025-03-15 09:14:34 Today_Hour12_PVforecast 3745 Wh
# 2025-03-15 09:14:34 Today_Hour13_PVforecast 4058 Wh
# 2025-03-15 09:14:34 Today_Hour14_PVforecast 3630 Wh
# 2025-03-15 09:14:34 Today_Hour15_PVforecast 1426 Wh
# 2025-03-15 09:14:34 Today_Hour16_PVforecast 513 Wh
# 2025-03-15 09:14:34 Today_Hour17_PVforecast 1324 Wh
# 2025-03-15 09:14:34 Today_Hour18_PVforecast 188 Wh
# 2025-03-15 09:14:34 Today_Hour19_PVforecast 28 Wh
# 2025-03-15 09:14:34 Today_MaxPVforecast 4058 Wh
# 2025-03-15 09:14:34 Today_MaxPVforecastTime 2025-03-15 12:00:00
# 2025-03-15 09:14:34 Today_PVdeviation 3.47 %
# 2025-03-15 09:14:34 Today_PVforecast 22272 Wh
# 2025-03-15 09:14:34 Today_PVreal 2474 Wh
# 2025-03-15 09:14:34 Today_SunRise 06:28
# 2025-03-15 09:14:34 Today_SunSet 18:15
# 2025-03-15 09:14:34 Tomorrow_ConsumptionForecast 15200 Wh
# 2025-03-15 09:14:34 Tomorrow_PVforecast 15744 Wh
# 2025-03-15 09:14:34 Tomorrow_SunRise 06:25
# 2025-03-15 09:14:34 Tomorrow_SunSet 18:17
# 2025-03-15 09:14:34 consumer01 name='Klimaanlage' state='unknown' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer01_currentPower 0 W
# 2025-03-15 09:14:34 consumer02 name='Tageslichtlampe' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-03-15 09:14:34 consumer02_currentPower 34 W
# 2025-03-15 09:14:34 consumer03 name='Spelunkenentfeuchter' state='off' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer03_currentPower 0 W
# 2025-03-15 09:14:34 consumer04 name='Geschirrspüler' state='on' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer04_currentPower 0 W
# 2025-03-15 09:14:34 consumer05 name='Wäschetrockner' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-03-15 09:14:34 consumer05_currentPower 0.02 W
# 2025-03-15 09:14:34 consumer06 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-03-15 09:14:34 consumer06_currentPower 0.17 W
# 2025-03-15 09:14:34 consumer07 name='Büro' state='unknown' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer07_currentPower 99 W
# 2025-03-15 09:14:34 consumer08 name='Wohnzimmer' state='unknown' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer08_currentPower 295.3 W
# 2025-03-15 09:14:34 consumer09 name='Klimaaußengerät' state='off' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer09_currentPower 0 W
# 2025-03-15 09:14:34 consumer10 name='Küchen-Kühlschrank' state='on' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer10_currentPower 0 W
# 2025-03-15 09:14:34 consumer11 name='Kaffeemaschine, Toaster, Thermomix' state='on' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer11_currentPower 4.2 W
# 2025-03-15 09:14:34 consumer12 name='Kellerkühlschrank' state='on' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer12_currentPower 0.3 W
# 2025-03-15 09:14:34 consumer13 name='PlugSchuppen' state='off' mode='can' planningstate='noSchedule'
# 2025-03-15 09:14:34 consumer13_currentPower 0 W
# 2025-03-15 09:14:34 consumer14 name='Teichbelüfter' state='off' mode='can' planningstate='planned'
# 2025-03-15 09:14:34 consumer14_planned_start 15.03.2025 08:49:42
# 2025-03-15 09:14:34 consumer14_planned_stop 15.03.2025 09:49:42
# 2025-03-15 09:14:34 consumer15 name='WallboxLeistungssumme' state='on' mode='can' planningstate='suspended' info='max Überschußprognose zu gering'
# 2025-03-15 09:14:34 consumer15_currentPower 2.893 W
# 2025-03-15 09:14:34 consumer16 name='Skimmer' state='off' mode='can' planningstate='planned'
# 2025-03-15 09:14:34 consumer16_planned_start 15.03.2025 08:49:42
# 2025-03-15 09:14:34 consumer16_planned_stop 15.03.2025 09:49:42
# 2025-03-15 09:14:34 nextCycletime 09:14:39
# 2025-03-15 08:00:03 pvCorrectionFactor_08 1.39 (automatic - old factor: 1.00, AI result used, Sun Alt range: 10, Cloud range: 75, Days in range: 1)
# 2025-03-15 09:02:45 pvCorrectionFactor_09 0.78 (automatic - old factor: 1.27, Sun Alt range: 15, Cloud range: 75, Days in range: 2)
# 2025-03-15 09:14:34 pvCorrectionFactor_Auto on_complex_ai
# 2024-08-24 17:13:20 setupStringAzimuth Osten=-127 Westen=53
# 2025-02-19 10:56:15 setupStringDeclination Osten=38 Westen=38
# 2025-03-15 09:14:34 special_todayBatInSum 964.0 Wh
# 2025-03-15 09:14:34 special_todayBatOutSum 2162.0 Wh
# 2025-03-15 09:14:34 special_todayConsumption 5743 Wh
# 2025-03-15 09:14:34 special_todayGridConsumption 1996 Wh
# 2025-03-15 09:14:34 special_todayGridFeedIn 28.0 Wh
# 2025-03-15 09:14:35 state updated
# hmccu:
#
setstate SolarForecast updated
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_ctrlDebug
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicHistoryHour 4
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicShowNight 1
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicShowWeather
setstate SolarForecast 2025-03-15 09:02:44 .associatedWith MQTT2_SmartMeterReader KlimaanlagePwr Klimaanlage_Sw MQTT2_Luftentfeuchter MQTT2_Spelunkenentfeuchter MQTT2_ShellyGeschirrspueler Trockner_Pwr Trockner Waschmaschine_Pwr Waschmaschine Stromverbrauch_Buero Stromverbrauch_WoZi MQTT2_KlimaODU MQTT2_ShellyPlugKuechenKuehlschrank MQTT2_PlugKaffeemaschine MQTT2_ShellyPlugKellerKuehlschrank ShellyplugSchuppen HM_56DBA8_Sw_01 WallboxLeistungssumme HM_35FA43_Sw_07 Enphase dwd
setstate SolarForecast 2025-03-15 09:14:34 .lastupdateForecastValues 1742026474
setstate SolarForecast 2025-03-15 09:14:34 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate SolarForecast 2025-03-15 01:00:03 .signaldone_01 done
setstate SolarForecast 2025-03-15 02:00:26 .signaldone_02 done
setstate SolarForecast 2025-03-15 03:00:17 .signaldone_03 done
setstate SolarForecast 2025-03-15 04:00:00 .signaldone_04 done
setstate SolarForecast 2025-03-15 05:00:00 .signaldone_05 done
setstate SolarForecast 2025-03-15 06:00:03 .signaldone_06 done
setstate SolarForecast 2025-03-15 07:00:03 .signaldone_07 done
setstate SolarForecast 2025-03-15 08:00:03 .signaldone_08 done
setstate SolarForecast 2025-03-15 09:02:45 .signaldone_09 done
setstate SolarForecast 2025-03-15 00:00:01 .signaldone_24 done
setstate SolarForecast 2025-03-15 09:14:34 Battery_ChargeRecommended_01 1
setstate SolarForecast 2025-03-15 09:14:34 Current_AutarkyRate 94 %
setstate SolarForecast 2025-03-15 09:14:34 Current_BatCharge_01 18 %
setstate SolarForecast 2025-03-15 09:14:34 Current_Consumption 773 W
setstate SolarForecast 2025-03-15 09:14:34 Current_GridConsumption 49 W
setstate SolarForecast 2025-03-15 09:14:34 Current_GridFeedIn 0 W
setstate SolarForecast 2025-03-15 09:14:34 Current_PV 2686 W
setstate SolarForecast 2025-03-15 09:14:34 Current_PowerBatIn_01 1962 W
setstate SolarForecast 2025-03-15 09:14:34 Current_PowerBatOut_01 0 W
setstate SolarForecast 2025-03-15 09:14:34 Current_SelfConsumption 724 W
setstate SolarForecast 2025-03-15 09:14:34 Current_SelfConsumptionRate 27 %
setstate SolarForecast 2025-03-15 09:14:34 Current_Surplus 1913 W
setstate SolarForecast 2025-03-15 09:14:35 Current_Surplus_Num 1913
setstate SolarForecast 2025-03-15 09:00:00 LastHourGridconsumptionReal 12 Wh
setstate SolarForecast 2025-03-15 09:00:00 LastHourPVforecast 1243 Wh
setstate SolarForecast 2025-03-15 09:00:00 LastHourPVreal 486 Wh
setstate SolarForecast 2025-03-15 09:14:34 NextHours_Sum01_PVforecast 2442 Wh
setstate SolarForecast 2025-03-15 09:14:34 NextHours_Sum02_PVforecast 5734 Wh
setstate SolarForecast 2025-03-15 09:14:34 NextHours_Sum03_PVforecast 9557 Wh
setstate SolarForecast 2025-03-15 09:14:34 NextHours_Sum04_ConsumptionForecast 1938 Wh
setstate SolarForecast 2025-03-15 09:14:34 NextHours_Sum04_PVforecast 13508 Wh
setstate SolarForecast 2025-03-15 09:14:34 RestOfDayConsumptionForecast 9611 Wh
setstate SolarForecast 2025-03-15 09:14:34 RestOfDayPVforecast 19709 Wh
setstate SolarForecast 2025-03-15 00:59:56 Today_Hour01_BatIn_01 0 Wh
setstate SolarForecast 2025-03-15 00:59:56 Today_Hour01_BatOut_01 838 Wh
setstate SolarForecast 2025-03-15 00:59:56 Today_Hour01_GridConsumption 39 Wh
setstate SolarForecast 2025-03-15 00:59:56 Today_Hour01_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-15 00:59:56 Today_Hour01_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
setstate SolarForecast 2025-03-15 01:59:35 Today_Hour02_BatIn_01 0 Wh
setstate SolarForecast 2025-03-15 01:59:35 Today_Hour02_BatOut_01 471 Wh
setstate SolarForecast 2025-03-15 01:59:35 Today_Hour02_GridConsumption 47 Wh
setstate SolarForecast 2025-03-15 01:59:35 Today_Hour02_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-15 01:59:35 Today_Hour02_PVreal 0 Wh
setstate SolarForecast 2025-03-15 02:59:27 Today_Hour03_BatIn_01 0 Wh
setstate SolarForecast 2025-03-15 02:59:27 Today_Hour03_BatOut_01 0 Wh
setstate SolarForecast 2025-03-15 02:59:27 Today_Hour03_GridConsumption 0 Wh
setstate SolarForecast 2025-03-15 02:59:27 Today_Hour03_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-15 02:59:27 Today_Hour03_PVreal 0 Wh
setstate SolarForecast 2025-03-15 03:59:55 Today_Hour04_BatIn_01 0 Wh
setstate SolarForecast 2025-03-15 03:59:55 Today_Hour04_BatOut_01 0 Wh
setstate SolarForecast 2025-03-15 03:59:55 Today_Hour04_GridConsumption 251 Wh
setstate SolarForecast 2025-03-15 03:59:55 Today_Hour04_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-15 03:59:55 Today_Hour04_PVreal 0 Wh
setstate SolarForecast 2025-03-15 04:59:55 Today_Hour05_BatIn_01 0 Wh
setstate SolarForecast 2025-03-15 04:59:55 Today_Hour05_BatOut_01 0 Wh
setstate SolarForecast 2025-03-15 04:59:55 Today_Hour05_GridConsumption 463 Wh
setstate SolarForecast 2025-03-15 04:59:55 Today_Hour05_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-15 04:59:55 Today_Hour05_PVreal 0 Wh
setstate SolarForecast 2025-03-15 05:59:59 Today_Hour06_BatIn_01 0 Wh
setstate SolarForecast 2025-03-15 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate SolarForecast 2025-03-15 05:59:59 Today_Hour06_GridConsumption 443 Wh
setstate SolarForecast 2025-03-15 05:59:59 Today_Hour06_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-15 05:59:59 Today_Hour06_PVreal 0 Wh
setstate SolarForecast 2025-03-15 06:59:58 Today_Hour07_BatIn_01 0 Wh
setstate SolarForecast 2025-03-15 06:59:58 Today_Hour07_BatOut_01 0 Wh
setstate SolarForecast 2025-03-15 06:59:58 Today_Hour07_GridConsumption 496 Wh
setstate SolarForecast 2025-03-15 06:59:58 Today_Hour07_GridFeedIn 0 Wh
setstate SolarForecast 2025-03-15 06:59:58 Today_Hour07_PVforecast 38 Wh
setstate SolarForecast 2025-03-15 06:59:58 Today_Hour07_PVreal 0 Wh
setstate SolarForecast 2025-03-15 07:59:58 Today_Hour08_BatIn_01 87 Wh
setstate SolarForecast 2025-03-15 07:59:58 Today_Hour08_BatOut_01 853 Wh
setstate SolarForecast 2025-03-15 07:59:58 Today_Hour08_GridConsumption 207 Wh
setstate SolarForecast 2025-03-15 07:59:58 Today_Hour08_GridFeedIn 6 Wh
setstate SolarForecast 2025-03-15 07:59:58 Today_Hour08_PVforecast 729 Wh
setstate SolarForecast 2025-03-15 07:59:58 Today_Hour08_PVreal 588 Wh
setstate SolarForecast 2025-03-15 08:19:14 Today_Hour09_BatIn_01 221 Wh
setstate SolarForecast 2025-03-15 08:19:14 Today_Hour09_BatOut_01 0 Wh
setstate SolarForecast 2025-03-15 08:19:14 Today_Hour09_GridConsumption 12 Wh
setstate SolarForecast 2025-03-15 08:19:14 Today_Hour09_GridFeedIn 6 Wh
setstate SolarForecast 2025-03-15 08:19:14 Today_Hour09_PVforecast 1243 Wh
setstate SolarForecast 2025-03-15 08:19:14 Today_Hour09_PVreal 486 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour10_BatIn_01 656 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour10_BatOut_01 0 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour10_GridConsumption 38 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour10_GridFeedIn 16 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour10_PVforecast 2209 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour10_PVreal 1400 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour11_PVforecast 3141 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour12_PVforecast 3745 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour13_PVforecast 4058 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour14_PVforecast 3630 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour15_PVforecast 1426 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour16_PVforecast 513 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour17_PVforecast 1324 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour18_PVforecast 188 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_Hour19_PVforecast 28 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_MaxPVforecast 4058 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_MaxPVforecastTime 2025-03-15 12:00:00
setstate SolarForecast 2025-03-15 09:14:34 Today_PVdeviation 3.47 %
setstate SolarForecast 2025-03-15 09:14:34 Today_PVforecast 22272 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_PVreal 2474 Wh
setstate SolarForecast 2025-03-15 09:14:34 Today_SunRise 06:28
setstate SolarForecast 2025-03-15 09:14:34 Today_SunSet 18:15
setstate SolarForecast 2025-03-15 09:14:34 Tomorrow_ConsumptionForecast 15200 Wh
setstate SolarForecast 2025-03-15 09:14:34 Tomorrow_PVforecast 15744 Wh
setstate SolarForecast 2025-03-15 09:14:34 Tomorrow_SunRise 06:25
setstate SolarForecast 2025-03-15 09:14:34 Tomorrow_SunSet 18:17
setstate SolarForecast 2025-03-15 09:14:34 consumer01 name='Klimaanlage' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer01_currentPower 0 W
setstate SolarForecast 2025-03-15 09:14:34 consumer02 name='Tageslichtlampe' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate SolarForecast 2025-03-15 09:14:34 consumer02_currentPower 34 W
setstate SolarForecast 2025-03-15 09:14:34 consumer03 name='Spelunkenentfeuchter' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer03_currentPower 0 W
setstate SolarForecast 2025-03-15 09:14:34 consumer04 name='Geschirrspüler' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer04_currentPower 0 W
setstate SolarForecast 2025-03-15 09:14:34 consumer05 name='Wäschetrockner' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate SolarForecast 2025-03-15 09:14:34 consumer05_currentPower 0.02 W
setstate SolarForecast 2025-03-15 09:14:34 consumer06 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate SolarForecast 2025-03-15 09:14:34 consumer06_currentPower 0.17 W
setstate SolarForecast 2025-03-15 09:14:34 consumer07 name='Büro' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer07_currentPower 99 W
setstate SolarForecast 2025-03-15 09:14:34 consumer08 name='Wohnzimmer' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer08_currentPower 295.3 W
setstate SolarForecast 2025-03-15 09:14:34 consumer09 name='Klimaaußengerät' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer09_currentPower 0 W
setstate SolarForecast 2025-03-15 09:14:34 consumer10 name='Küchen-Kühlschrank' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer10_currentPower 0 W
setstate SolarForecast 2025-03-15 09:14:34 consumer11 name='Kaffeemaschine, Toaster, Thermomix' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer11_currentPower 4.2 W
setstate SolarForecast 2025-03-15 09:14:34 consumer12 name='Kellerkühlschrank' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer12_currentPower 0.3 W
setstate SolarForecast 2025-03-15 09:14:34 consumer13 name='PlugSchuppen' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-03-15 09:14:34 consumer13_currentPower 0 W
setstate SolarForecast 2025-03-15 09:14:34 consumer14 name='Teichbelüfter' state='off' mode='can' planningstate='planned'
setstate SolarForecast 2025-03-15 09:14:34 consumer14_planned_start 15.03.2025 08:49:42
setstate SolarForecast 2025-03-15 09:14:34 consumer14_planned_stop 15.03.2025 09:49:42
setstate SolarForecast 2025-03-15 09:14:34 consumer15 name='WallboxLeistungssumme' state='on' mode='can' planningstate='suspended' info='max Überschußprognose zu gering'
setstate SolarForecast 2025-03-15 09:14:34 consumer15_currentPower 2.893 W
setstate SolarForecast 2025-03-15 09:14:34 consumer16 name='Skimmer' state='off' mode='can' planningstate='planned'
setstate SolarForecast 2025-03-15 09:14:34 consumer16_planned_start 15.03.2025 08:49:42
setstate SolarForecast 2025-03-15 09:14:34 consumer16_planned_stop 15.03.2025 09:49:42
setstate SolarForecast 2025-03-15 09:14:34 nextCycletime 09:14:39
setstate SolarForecast 2025-03-15 08:00:03 pvCorrectionFactor_08 1.39 (automatic - old factor: 1.00, AI result used, Sun Alt range: 10, Cloud range: 75, Days in range: 1)
setstate SolarForecast 2025-03-15 09:02:45 pvCorrectionFactor_09 0.78 (automatic - old factor: 1.27, Sun Alt range: 15, Cloud range: 75, Days in range: 2)
setstate SolarForecast 2025-03-15 09:14:34 pvCorrectionFactor_Auto on_complex_ai
setstate SolarForecast 2024-08-24 17:13:20 setupStringAzimuth Osten=-127 Westen=53
setstate SolarForecast 2025-02-19 10:56:15 setupStringDeclination Osten=38 Westen=38
setstate SolarForecast 2025-03-15 09:14:34 special_todayBatInSum 964.0 Wh
setstate SolarForecast 2025-03-15 09:14:34 special_todayBatOutSum 2162.0 Wh
setstate SolarForecast 2025-03-15 09:14:34 special_todayConsumption 5743 Wh
setstate SolarForecast 2025-03-15 09:14:34 special_todayGridConsumption 1996 Wh
setstate SolarForecast 2025-03-15 09:14:34 special_todayGridFeedIn 28.0 Wh
setstate SolarForecast 2025-03-15 09:14:35 state updated
Moin Peter,
spontan nicht. Habe ich bei mir noch nicht gesehen.
In meiner GraphicHeaderOwnSpec gibt es auch Umlaute, die ich ganz normal als Ü oder ü schreibe.
Es ist aber auf jeden Fall eine Fehlermitteilung aus JavaScript (fhemweb.js) und nur in der Detailansicht wenn ich richtig liege.
Vllt. kannst du mit Browsertools etwas mehr Infos herausbekommen. JavaScript ist jetzt auch nicht gerade meine Domäne.
Wie ist denn im global Device das Attr encoding gesetzt, falls es gesetzt ist?
Hallo Heiko,
die Meldungen kommen sowohl auf der Detailseite wie auch im Raum.
Attr global encoding ist nicht gesetzt.
Ich werde das mal weiter beobachten. Solange es nur beim Neustart auftritt, ist es zu ertragen.
Viele Grüße,
Peter
Zitat von: DS_Starter am 14 März 2025, 23:22:01morgen früh ist die V 1.48.0 im Update.
Die Balkengrafik Ebene 3 kann aktiviert werden indem die Attr graphicBeam5Content bzw. graphicBeam6Content gesetzt werden.
Super, auch die Trenner gefallen mir gut :D
Habs einfach mal probiert....
Sogar die Batteriesymbol funktionieren in der Ebene 3 ;D
SBS25_2 pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap:Wh show=3:top icon=@yellow:@green:@red:@blue asynchron=1
PS:
Hilfetext zum Attribut irgendwann mal auf 3 Ebenen erweitern ;)
show Steuerung der Anzeige der Batterie in der Balkengrafik (optional)
0 - keine Anzeige des Gerätes (default)
<1...3>[:top|bottom] - Anzeige des Gerätes in der Balkengrafik Ebene 1,2 oder 3 (über|unter) den Balken
PPS:
Vielen Dank auch noch für den heutigen 01_FHEMWEB.pm Update-Bug-Hinweis.
Hatte morgens ein Update gestartet und bin direkt danach dann bis vorhin extern unterwegs gewesen. Vorhin dann gesehen das kein Web-Aufruf möglich war....wollte schon ein Backup einspielen. "Schwein gehabt" dank dir. :-[
Gruß
300P
Zitat von: peterboeckmann am 15 März 2025, 09:13:57......
ich bekomme in den letzten Tagen immer mal wieder (insbesondere kurz nach Neustarts) folgende Fehlermeldungen:
......
Habe es am Anfang schon mit Ü und mit Ü versucht. Beides bringt das gleiche Ergebnis.
Danke für jeden Ansatz!
Viel Grüße,
Peter
Auch schon mit Ü versucht ?
Bei mir geht Ü oder auch einfach Ü oder auch Ü
Aber bitte nur 1 Semikolon am Ende setzen => ;D
Im deinem "List" sind aktuell augenscheinlich 2 Semikolon drin.
attr SolarForecast graphicHeaderOwnspec #Aktuell:\
Ü;berschuss:Current_Surplus\
Einspeisung:Current_GridFeedIn\
Netzbezug:Current_GridConsumption\
Autarkie-Rate:Current_AutarkyRate\
#Heute:\
........Wichtige Deutsche HTML-Umlaute merken mit EselsbrückeUm sich die HTML-Umlaute Ä, ä, Ö, ö, Ü und ü besser merken zu können, kann man sich eine kleine Eselsbrücke schaffen. Alle Sonderzeichen fangen schon mal mit einem & an. Check! Als nächstes kommt der Buchstabe, den man schreiben möchte. Dabei einfach die Punkte wegdenken und die Groß- und Kleinschreibung beachten. In diesem Beispiel nehmen wir ein ä. Jetzt folgt nur noch die Abkürzung für Umlaute uml. Das ; am Ende nicht vergessen – fertig!
Ergebnis =>
äUnd hier die wichtigsten HTML-Umlaute für den deutschsprachigen Raum (https://www.designerinaction.de/tipps-tricks/web-development/html-umlaute-sonderzeichen/#html-umlaute-utf8)
Gruß
300P
ZitatPS:
Hilfetext zum Attribut irgendwann mal auf 3 Ebenen erweitern ;)
Ah ja ... danke für den Hinweis. Kommt im nächsten Release mit.
Einen Guten Morgen (mit viel 🌞),
wenn du evtl. auch noch an diesen Punkt (Erweiterung für die Ebene 3) irgendwann mal denkst:
graphicBeamHeightLevelX <value>
Multiplikator zur Festlegung der maximalen Balkenhöhe der jeweiligen Ebene.
In Verbindung mit dem Attribut graphicHourCount lassen sich damit auch recht kleine Grafikausgaben erzeugen.
(default: 200)
Schönen sonnigen Sonntag noch 8) ;) an Alle.
Gruß
300P
Mir fehlt seit einem Update vor kurzem der aktuelle SOC des Akkus - bis zum Update wurde er angezeigt.
Was hat sich geändert? Es war ja schon immer problematisch für die Prognose zu erkennen wieviel Energie in die Batterie geladen wurde ( Huawei mit HV - Akku )
Hat sich das gelöst?
Hat jemand ein Huawei best practise?
ZitatMir fehlt seit einem Update vor kurzem der aktuelle SOC des Akkus - bis zum Update wurde er angezeigt.
Du musst vermutlich im Attr setupBatteryDevXX nur den Schlüssel
cap (Hilfe beachten!) setzen. Der ist seit dem Multibatterie Feature Pflicht.
Zitatwenn du evtl. auch noch an diesen Punkt (Erweiterung für die Ebene 3) irgendwann mal denkst:
Kommt auch mit dem nächsten Release.
ZitatWichtige Deutsche HTML-Umlaute merken mit Eselsbrücke
Um sich die HTML-Umlaute Ä, ä, Ö, ö, Ü und ü besser merken zu können, kann man sich eine kleine Eselsbrücke schaffen. Alle Sonderzeichen fangen schon mal mit einem & an. Check! Als nächstes kommt der Buchstabe, den man schreiben möchte. Dabei einfach die Punkte wegdenken und die Groß- und Kleinschreibung beachten. In diesem Beispiel nehmen wir ein ä. Jetzt folgt nur noch die Abkürzung für Umlaute uml. Das ; am Ende nicht vergessen – fertig!
Ergebnis => Ü
Ähm (Ähm),
aus ä würd Ü?
Da hast du wohl eine Telfonat zwischen den 2 Sätzen bekommen! ;)
Zitat von: kask am 17 März 2025, 07:08:29Ähm (Ähm),
aus ä würd Ü?
Da hast du wohl eine Telfonat zwischen den 2 Sätzen bekommen! ;)
Oha - falscher Fehler 🙈 - ist korrigiert 😉
Danke für den Hinweis 👍
Ich hab da noch unterschiedliche Anzeigen Web und FTUI:
Im Web fehlt die SOC Menge in der Grafik unter den Balken (flow) wärend sie im FTUI Widget richtig angezeigt wird.
Das Reading Current_BatCharge_01 98.9 % ist auch richtig da.
setupBatteryDev01 PV_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W intotal=Summe_Ladung:kWh outtotal=Summe_Entladung:kWh cap=10260 charge=BatteryChargePercentIst da was falsch ?
Edit: Fehler ist weg, hat nur lange gedauert bis der SOC Wert richtig übernommen wurde (warum auch immer...)
LG WDS
Wär's möglich die Vorhersagedaten auf das Maximum der Inverterleistung zu limitieren?
Durch nicht passende Wettervorhersagen passiert's offenbar schonmal, dass die KI zu hohe Korrekturfaktoren lernt, die dann zu erhöhten Prognosen führen.
Beispiel von heute 13 Uhr:
Prognose sagte 15315 Wh vorher, obwohl mein WR auf 15 kW limitiert ist.
attr mySolarForecast setupInverterDev01 myHuawei pv=Active_Power:W etotal=Accumulated_energy_yield:kWh capacity=15000 asynchron=1
13 => pvfc: 15315, pvrl: 11070, pvrlvd: 1, rad1h: 4260
etotali01: 34949710, etotali02: -, etotali03: -, etotali04: -
pvrl01: 11070, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 2265, con: 2225, gcons: 0, conprice: 0.268824
gfeedin: 8845, feedprice: 0.075
DoN: 1, sunaz: 189, sunalt: 40
batintotal01: -, batintotal02: -, batintotal03: -
batouttotal01: -, batouttotal02: -, batouttotal03: -
batsoc01: -, batsoc02: -, batsoc03: -
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
weatherid: 3, wcc: 83, rr1c: 0.00, pvcorrf: 1.53/0.65 temp: 4.70,
csmt01: 71327, csme01: 0, minutescsm01: 0
csmt02: 103314, csme02: 0, minutescsm02: 0
csmt03: 15024000, csme03: 0, minutescsm03: 56
csmt04: 5056000, csme04: 0, minutescsm04: 0
csmt05: 0, csme05: 0, minutescsm05: 0
csmt06: 4838377610.00997, csme06: 19.0000104904175, minutescsm06: 0
csmt07: 3047744.12035754, csme07: 0, minutescsm07: 0
csmt08: 270640, csme08: 20, minutescsm08: 60
minutescsm09: 0
csmt10: 5056000, csme10: 0, minutescsm10: 0
csmt11: 207343, csme11: 0, minutescsm11: 0
csmt12: 284429, csme12: 0, minutescsm12: 0
Zitat von: TheTrumpeter am 17 März 2025, 14:27:17Wär's möglich die Vorhersagedaten auf das Maximum der Inverterleistung zu limitieren?
Durch nicht passende Wettervorhersagen passiert's offenbar schonmal, dass die KI zu hohe Korrekturfaktoren lernt, die dann zu erhöhten Prognosen führen.
Beispiel von heute 13 Uhr:
Prognose sagte 15315 Wh vorher, obwohl mein WR auf 15 kW limitiert ist.
< snip >
Moin
Bei der DbLog Leistungsprognose berücksichtige ich einmal die letzten 30 Tage und zusätzlich auch den Vortag, da es im Winter wegen Schnee mal schnell zu einem totalen Einbruch kommen kann, den die KI regional bedingt nicht so schnell lernen kann.
SELECT hour -1 AS hour,
if(yield_min > yield_max*0.04, yield_max, yield_min) AS yield_max
FROM (
SELECT hour,
-- Ist der letzte Tag 90% kleiner als der Durchschnitt der letzten Tage,
-- dann liegt Schnee auf den Modulen
cast(max(if(yield > 0,yield,0)) AS DECIMAL(6)) AS yield_max
FROM dwdfull
WHERE TIMESTAMP > DATE_ADD(@date,INTERVAL -30 DAY)
GROUP BY hour ) x1
INNER JOIN
-- Wie waren die letzten Tag? Extrem kleine Werte bedeuten abgedeckte Module,
-- was die Ki_Prognose nicht so schnell lernen kann.
(SELECT hour,
cast(min(if(yield > 0,yield,0)) AS DECIMAL(6)) AS yield_min
FROM dwdfull
WHERE TIMESTAMP > DATE_ADD(@date,INTERVAL -1 DAY)
AND TIMESTAMP < @date
GROUP BY hour
) X2 USING(hour)
VG Christian
Guten Abend,
ZitatWär's möglich die Vorhersagedaten auf das Maximum der Inverterleistung zu limitieren?
Durch nicht passende Wettervorhersagen passiert's offenbar schonmal, dass die KI zu hohe Korrekturfaktoren lernt, die dann zu erhöhten Prognosen führen.
Beispiel von heute 13 Uhr:
Prognose sagte 15315 Wh vorher, obwohl mein WR auf 15 kW limitiert ist.
Ich war der Meinung diese Begrenzung bereits eingebaut zu haben. Das stimmt zwar für die normale Prognose, allerdings arbeitet die KI daran (ungewollt) vorbei. Das werde ich entsprechend ändern.
War bei mir noch nicht aufgefallen.
LG,
Heiko
@Christian,
ZitatMoin, ich meine im Modul wird noch keine KI verwendet.
Echt? ::)
@all,
momentan arbeite ich daran die Kompatibilität zwischen den Strahlungswerten, die durch DWD (Device) und OpenMeteo geliefert werden, herzustellen. Das ist wertvoll um einerseits eine nahtlose Umschaltung der Strahlungsquellen DWD <-> OpenMeteo zu ermöglichen und andererseits die geplante Satellitenunterstützung für OpenMeteo als auch für DWD anbieten zu können. Die Logik ist bereits implemenietiert und funktioniert wie gewünscht.
Pferdefuß ....
Problematisch ist die Lerndaten für die KI durch die Homogenisierung invalidiert werden, d.h. wenn OPenMeteo mit "on_complex_ai" verwendet wird, würde die Prognose nach der Homogenisierung weniger Ertrag prognostizieren.
Natürlich könnte man mit einem "reset aiData" die alten Raw-Daten löschen und neu sammeln. Das funktioniert.
Allerdings bietet OpenMeteo an historische Daten abzurufen. Damit ist es möglich die rad1h Werte innerhalb der vorhandenen aiRawData mit dem angepassten Format zu refreshen. Dadurch würden wir die wertvollen Daten nicht verlieren.
Die Implementierung dieser Möglichkeit dauert noch, weswegen das nächste Release noch etwas auf sich warten lassen wird.
ZitatHast Du die KI als Perl Bibliothek gefunden? Ich würde das Python bei mir gerne raus bekommen.
Ja, die gibt es schon recht lange (1 Jahr +) im Modul. Ich verwende AI::DecisionTree. Es gibt aber weitere KI Bibliotheken die möglicherweise noch besser geeignet sind. Bin aber noch nicht dazu gekommen weitere KI zu testen und mit DecisionTree zu vergleichen.
Zitat von: DS_Starter am 16 März 2025, 10:27:42ZitatMir fehlt seit einem Update vor kurzem der aktuelle SOC des Akkus - bis zum Update wurde er angezeigt.
Du musst vermutlich im Attr setupBatteryDevXX nur den Schlüssel cap (Hilfe beachten!) setzen. Der ist seit dem Multibatterie Feature Pflicht.
Danke Heiko - das hat geholfen...
Zitat von: DS_Starter am 17 März 2025, 21:35:55das nächste Release
Ich habe das letzte Major-Update noch nicht gemacht, weil ich in der Ankündigung/Diskussion darüber zwischen den Zeilen rausgelesen habe, dass es den Ressourcenverbrauch deutlich erhöhen könnte (?), hat sich das bestätigt bzw. stimmt das?
Mein FHEM läuft noch immer auf einem RasPi 3B, RAM ist aufgrund diverser anderer Module schon recht gut gefüllt.
Zitat von: TheTrumpeter am 18 März 2025, 07:14:52Ich habe das letzte Major-Update noch nicht gemacht, weil ich in der Ankündigung/Diskussion darüber zwischen den Zeilen rausgelesen habe, dass es den Ressourcenverbrauch deutlich erhöhen könnte (?), hat sich das bestätigt bzw. stimmt das?
Mein FHEM läuft noch immer auf einem RasPi 3B, RAM ist aufgrund diverser anderer Module schon recht gut gefüllt.
meins läuft (auch) auf einem Raspi 3B+, bisher keinerlei Probleme mit dem neuen Release
Zitat von: 300P am 10 März 2025, 15:49:18@Alle:
Gibt es jemanden der mit 2 / 3 Batterien Erfahrung hat oder es nutzt ?
Hallo allerseits,
ich habe für meine 3-Batterie-Anlage mal eine Auswertung gestrickt um das Thema 'netzdienliches Laden' zu visualisieren. Dabei bin ich zu dem gleichen Schluss gekommen wie 300P (im wesentlichen). Der erste Schreenshot (001-*) zeigt die Ladefreigaben (gestrichelte Linien) der Batterien in Bezug auf den variablen Strompreis (durchgehende Linie). Auffällig ist das nur bei BAT1 eine Änderung stattfindet die Ladefreigaben der beiden anderen bleiben immer auf '1'. Die Ladefreigabe zu BAT1 scheint weder zeit- noch preisgebunden. Im 2. Screenshot (002-*) ist zusätzlich die reale (Auf- und Ent-) Ladung der Akkus zu sehen (gepunktete Linie) - dabei sind hier die Farben der Linien pro device identisch. Auch hier ist kein Einfluss der realen Ladung auf die Ladefreigaben zu erkennen. Im dritten Screenshot habe ich anstatt des Preises noch mal den realen PV-Überschuss (Surplus) als Vergleichskriterum genommen - auch da konnte ich keinen Einfluss erkennen
Gruß Gerd
001-2025-03-17 21_58_36-Greenshot.jpg
002-2025-03-17 21_54_55-Greenshot.jpg
003-2025-03-17 22_03_12-Greenshot.jpg
Zitat von: grappa24 am 18 März 2025, 08:04:58Zitat von: TheTrumpeter am 18 März 2025, 07:14:52Ich habe das letzte Major-Update noch nicht gemacht, weil ich in der Ankündigung/Diskussion darüber zwischen den Zeilen rausgelesen habe, dass es den Ressourcenverbrauch deutlich erhöhen könnte (?), hat sich das bestätigt bzw. stimmt das?
Mein FHEM läuft noch immer auf einem RasPi 3B, RAM ist aufgrund diverser anderer Module schon recht gut gefüllt.
meins läuft (auch) auf einem Raspi 3B+, bisher keinerlei Probleme mit dem neuen Release
OK, dann werde ich mich morgen mal drübertrauen...
Hallo zusammen,
Zitatweil ich in der Ankündigung/Diskussion darüber zwischen den Zeilen rausgelesen habe, dass es den Ressourcenverbrauch deutlich erhöhen könnte (?), hat sich das bestätigt bzw. stimmt das?
Im Prinzip ja, sofern man die KI Unterstützung nutzt.
Allerdings kann man im User auf den RAM Verbrauch Einfluß nehmen, indem im Attr aiControl der Schlüssel aiTreesPV reduziert wird. Mit dem Wert 1 wird der bisherige Zustand wieder aktiviert. Die Online Hilfe gibt Aufscluß über den Zusammenhang.
@Max_Meyer,
ZitatDie Ladefreigabe zu BAT1 scheint weder zeit- noch preisgebunden.
Das ist richtig. Das Ziel dessen ist hier im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Ber%C3%BCcksichtigung_einer_Wirkleistungsbegrenzung) beschrieben.
Um eine Aussage/Einschätzung bzgl. dieser Steuerung vornehmen zu können, müsstest du mal ctrlDebug=batteryManagement einschalten und die Logausgabe posten. Dann sieht man am besten den Ablauf der Logik-Entscheidungen.
LG,
Heiko
Zitat von: DS_Starter am 17 März 2025, 21:10:09Ich war der Meinung diese Begrenzung bereits eingebaut zu haben. Das stimmt zwar für die normale Prognose, allerdings arbeitet die KI daran (ungewollt) vorbei. Das werde ich entsprechend ändern.
War bei mir noch nicht aufgefallen.
Das passt doch dann auch zu meinem Problem:
Zitat von: tomcat.x am 09 März 2025, 10:47:26Für heute 12:00 Uhr habe ich in der Grafik eine Vorhersage, die 14% über der Kapazität (Sumne der Inverter capacity) liegt und das bei Cloud: 70.
Die Stunde ist generell der Ausreißer heute. Muss ich mich auf die Suche nach einem Konfiguratiosfehler machen?
Ist aber bis jetzt nicht wieder aufgetreten, also kann ich nicht mit Sicherheit sagen, dass es an der KI-Vorhersage lag.
Hallo Heiko,
bei mir passt die Verbrauchsvohersage für morgen so gar nicht:
screen.png
Ich hab mal attr ctrlDebug consumption,consumption_long gesetzt:
2025.03.18 12:51:00 1: SolarForecast DEBUG> ################### Start Consumption forecast ###################
2025.03.18 12:51:00 1: SolarForecast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.03.18 12:51:00 1: SolarForecast DEBUG> process Today dayname: Di, Tomorrow dayname: Mi
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 01 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 02 - 2.93 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 03 - 2.98 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 04 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 05 - 2.90 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 06 - 2.90 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 07 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 08 - 2.91 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 09 - 2.93 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 10 - 2.94 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 11 - 2.96 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 12 - 2.97 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 13 - 785.99 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 14 - 2784.75 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 15 - 2587.83 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 16 - 370.24 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 17 - 3.09 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 18 - 2.94 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 19 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 20 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 21 - 2.98 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 22 - 2.99 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 23 - 2.93 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 24 - 2.93 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 05, csme: 7162.47
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 01 - 2.80 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 02 - 2.80 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 03 - 2.76 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 04 - 2.79 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 05 - 2.75 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 06 - 2.75 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 07 - 2.79 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 08 - 2.79 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 09 - 2.75 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 10 - 2.76 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 11 - 2.81 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 12 - 2.76 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 13 - 2.82 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 14 - 2.76 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 15 - 2.78 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 16 - 2.82 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 17 - 2.77 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 18 - 2.75 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 19 - 2.79 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 20 - 3.11 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 21 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 22 - 2.97 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 23 - 2.99 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 24 - 2.90 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 12, csme: 70.39
2025.03.18 12:51:00 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 19, csme: 638889.14
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 01 - 2.98 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 02 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 03 - 2.93 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 04 - 2.94 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 05 - 2.98 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 06 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 07 - 2.92 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 08 - 2.91 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 09 - 3.03 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 10 - 2.84 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 11 - 2.91 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 12 - 2.15 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 13 - 3.50 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 14 - 2.74 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 15 - 2.79 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 16 - 2.74 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 17 - 2.74 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 18 - 2.73 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 19 - 2.78 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 20 - 2.73 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 21 - 2.74 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 22 - 2.74 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 23 - 2.75 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 24 - 2.75 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 26, csme: 15294.87
2025.03.18 12:51:00 1: SolarForecast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 01, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 01: 479 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 02, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 02: 508 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 03, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 03: 570 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 04, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 04: 497 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 05, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 05: 466 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 06, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 06: 463 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 07, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 07: 648 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 08, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 08: 671 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 09, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 09: 938 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 10, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 10: 814 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 11, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 11: 1372 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 12, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 12: 1628 Wh, Considered value numbers: 7
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 264 Wh for Hour 13, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 13: 1746 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 930 Wh for Hour 14, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 14: 1202 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 864 Wh for Hour 15, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 15: 1163 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 125 Wh for Hour 16, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 16: 1419 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 17, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 17: 853 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 18, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 18: 741 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 19, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 19: 723 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 20, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 20: 641 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 21, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 21: 657 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 22, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 22: 589 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 23, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 23: 529 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 24, Considered value numbers: 3
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons of Hour 24: 525 Wh, Considered value numbers: 6
2025.03.18 12:51:00 1: SolarForecast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons Tomorrow: -147788 Wh, Individual hourly values considered: 144, exclude: 165354 Wh (avg of 4 entities)
2025.03.18 12:51:00 1: SolarForecast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour00' hod '13' confc: 1746, confcEx: 1746
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '13' confc: 1746
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour01' hod '14' confc: 1202, confcEx: 1202
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '14' confc: 1202
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour02' hod '15' confc: 1163, confcEx: 1163
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '15' confc: 1163
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour03' hod '16' confc: 1419, confcEx: 1419
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '16' confc: 1419
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour04' hod '17' confc: 853, confcEx: 853
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '17' confc: 853
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour05' hod '18' confc: 741, confcEx: 741
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '18' confc: 741
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour06' hod '19' confc: 723, confcEx: 723
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '19' confc: 723
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour07' hod '20' confc: 641, confcEx: 641
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '20' confc: 641
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour08' hod '21' confc: 657, confcEx: 657
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '21' confc: 657
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour09' hod '22' confc: 589, confcEx: 589
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '22' confc: 589
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour10' hod '23' confc: 529, confcEx: 529
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '23' confc: 529
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour11' hod '24' confc: 525, confcEx: 525
2025.03.18 12:51:00 1: SolarForecast DEBUG> store circular/history hod '24' confc: 525
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour12' hod '01' confc: 479, confcEx: 479
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour13' hod '02' confc: 508, confcEx: 508
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour14' hod '03' confc: 570, confcEx: 570
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour15' hod '04' confc: 497, confcEx: 497
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour16' hod '05' confc: 466, confcEx: 466
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour17' hod '06' confc: 463, confcEx: 463
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour18' hod '07' confc: 648, confcEx: 648
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour19' hod '08' confc: 671, confcEx: 671
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour20' hod '09' confc: 938, confcEx: 938
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour21' hod '10' confc: 814, confcEx: 814
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour22' hod '11' confc: 1372, confcEx: 1372
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour23' hod '12' confc: 1628, confcEx: 1628
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour24' hod '13' confc: 1746, confcEx: 1746
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour25' hod '14' confc: 1202, confcEx: 1202
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour26' hod '15' confc: 1163, confcEx: 1163
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour27' hod '16' confc: 1419, confcEx: 1419
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour28' hod '17' confc: 853, confcEx: 853
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour29' hod '18' confc: 741, confcEx: 741
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour30' hod '19' confc: 723, confcEx: 723
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour31' hod '20' confc: 641, confcEx: 641
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour32' hod '21' confc: 657, confcEx: 657
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour33' hod '22' confc: 589, confcEx: 589
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour34' hod '23' confc: 529, confcEx: 529
2025.03.18 12:51:00 1: SolarForecast DEBUG> store 'NextHour35' hod '24' confc: 525, confcEx: 525
2025.03.18 12:51:00 1: SolarForecast DEBUG> consumption calculated - day: 18, hod: 13, con: 4049 Wh
2025.03.18 12:51:00 1: SolarForecast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 14628 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> ################### Start Consumption forecast ###################
2025.03.18 12:51:06 1: SolarForecast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.03.18 12:51:06 1: SolarForecast DEBUG> process Today dayname: Di, Tomorrow dayname: Mi
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 01 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 02 - 2.93 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 03 - 2.98 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 04 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 05 - 2.90 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 06 - 2.90 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 07 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 08 - 2.91 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 09 - 2.93 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 10 - 2.94 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 11 - 2.96 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 12 - 2.97 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 13 - 785.99 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 14 - 2784.75 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 15 - 2587.83 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 16 - 370.24 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 17 - 3.09 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 18 - 2.94 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 19 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 20 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 21 - 2.98 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 22 - 2.99 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 23 - 2.93 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 04, hod: 24 - 2.93 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 05, csme: 7162.47
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 01 - 2.80 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 02 - 2.80 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 03 - 2.76 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 04 - 2.79 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 05 - 2.75 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 06 - 2.75 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 07 - 2.79 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 08 - 2.79 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 09 - 2.75 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 10 - 2.76 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 11 - 2.81 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 12 - 2.76 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 13 - 2.82 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 14 - 2.76 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 15 - 2.78 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 16 - 2.82 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 17 - 2.77 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 18 - 2.75 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 19 - 2.79 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 20 - 3.11 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 21 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 22 - 2.97 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 23 - 2.99 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 11, hod: 24 - 2.90 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 12, csme: 70.39
2025.03.18 12:51:06 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 19, csme: 638889.14
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 01 - 2.98 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 02 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 03 - 2.93 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 04 - 2.94 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 05 - 2.98 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 06 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 07 - 2.92 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 08 - 2.91 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 09 - 3.03 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 10 - 2.84 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 11 - 2.91 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 12 - 2.15 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 13 - 3.50 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 14 - 2.74 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 15 - 2.79 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 16 - 2.74 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 17 - 2.74 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 18 - 2.73 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 19 - 2.78 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 20 - 2.73 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 21 - 2.74 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 22 - 2.74 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 23 - 2.75 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumer '15' register for exclude day 25, hod: 24 - 2.75 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 26, csme: 15294.87
2025.03.18 12:51:06 1: SolarForecast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 01, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 01: 479 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 02, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 02: 508 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 03, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 03: 570 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 04, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 04: 497 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 05, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 05: 466 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 06, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 06: 463 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 07, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 07: 648 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 08, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 08: 671 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 09, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 09: 938 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 10, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 10: 814 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 11, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 11: 1372 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 12, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 12: 1628 Wh, Considered value numbers: 7
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 264 Wh for Hour 13, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 13: 1746 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 930 Wh for Hour 14, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 14: 1202 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 864 Wh for Hour 15, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 15: 1163 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 125 Wh for Hour 16, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 16: 1419 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 17, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 17: 853 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 18, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 18: 741 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 19, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 19: 723 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 20, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 20: 641 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 21, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 21: 657 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 22, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 22: 589 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 23, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 23: 529 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> excl. hist 3 Wh for Hour 24, Considered value numbers: 3
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons of Hour 24: 525 Wh, Considered value numbers: 6
2025.03.18 12:51:06 1: SolarForecast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.03.18 12:51:06 1: SolarForecast DEBUG> estimated cons Tomorrow: -147788 Wh, Individual hourly values considered: 144, exclude: 165354 Wh (avg of 4 entities)
2025.03.18 12:51:06 1: SolarForecast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour00' hod '13' confc: 1746, confcEx: 1746
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '13' confc: 1746
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour01' hod '14' confc: 1202, confcEx: 1202
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '14' confc: 1202
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour02' hod '15' confc: 1163, confcEx: 1163
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '15' confc: 1163
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour03' hod '16' confc: 1419, confcEx: 1419
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '16' confc: 1419
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour04' hod '17' confc: 853, confcEx: 853
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '17' confc: 853
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour05' hod '18' confc: 741, confcEx: 741
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '18' confc: 741
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour06' hod '19' confc: 723, confcEx: 723
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '19' confc: 723
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour07' hod '20' confc: 641, confcEx: 641
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '20' confc: 641
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour08' hod '21' confc: 657, confcEx: 657
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '21' confc: 657
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour09' hod '22' confc: 589, confcEx: 589
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '22' confc: 589
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour10' hod '23' confc: 529, confcEx: 529
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '23' confc: 529
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour11' hod '24' confc: 525, confcEx: 525
2025.03.18 12:51:06 1: SolarForecast DEBUG> store circular/history hod '24' confc: 525
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour12' hod '01' confc: 479, confcEx: 479
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour13' hod '02' confc: 508, confcEx: 508
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour14' hod '03' confc: 570, confcEx: 570
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour15' hod '04' confc: 497, confcEx: 497
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour16' hod '05' confc: 466, confcEx: 466
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour17' hod '06' confc: 463, confcEx: 463
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour18' hod '07' confc: 648, confcEx: 648
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour19' hod '08' confc: 671, confcEx: 671
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour20' hod '09' confc: 938, confcEx: 938
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour21' hod '10' confc: 814, confcEx: 814
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour22' hod '11' confc: 1372, confcEx: 1372
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour23' hod '12' confc: 1628, confcEx: 1628
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour24' hod '13' confc: 1746, confcEx: 1746
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour25' hod '14' confc: 1202, confcEx: 1202
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour26' hod '15' confc: 1163, confcEx: 1163
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour27' hod '16' confc: 1419, confcEx: 1419
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour28' hod '17' confc: 853, confcEx: 853
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour29' hod '18' confc: 741, confcEx: 741
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour30' hod '19' confc: 723, confcEx: 723
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour31' hod '20' confc: 641, confcEx: 641
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour32' hod '21' confc: 657, confcEx: 657
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour33' hod '22' confc: 589, confcEx: 589
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour34' hod '23' confc: 529, confcEx: 529
2025.03.18 12:51:06 1: SolarForecast DEBUG> store 'NextHour35' hod '24' confc: 525, confcEx: 525
2025.03.18 12:51:06 1: SolarForecast DEBUG> consumption calculated - day: 18, hod: 13, con: 4049 Wh
2025.03.18 12:51:06 1: SolarForecast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 14628 Wh
Offenbar wird der Verbrauch der Wallbox abgezogen, wobei ich mit der noch nie 147 kWh am Tag geladen habe. Das Auto fasst nur 65 kWh.
Hast Du eine Idee, wo der Fehler stecken könnte?
Viele Grüße,
Peter
Hallo Peter,
ich sehe zumindest einen sehr hohen Verbrauchswert von 638 kWh der in deiner History aufgezeichnet wurde:
2025.03.18 12:51:00 1: SolarForecast DEBUG> Consumer '15' hist cons registered by 'exconfc' for excl. - day: 19, csme: 638889.14
Dieser Wert hat einen sehr hohen Einfluß auf den Durchschnitt der exkludiert wird und du müsstest für dich klären woher dieser hohe Wert kam. Vielleicht ein früherer Fehler? Es betrifft den Tag 19, also den 19.02. der morgen automatisch aus der History gelöscht wird.
2025.03.18 12:51:00 1: SolarForecast DEBUG> estimated cons Tomorrow: -147788 Wh, Individual hourly values considered: 144, exclude: 165354 Wh (avg of 4 entities)
Ob / wie ein Wert exkludiert wird hängt vom Schlüssel exconfc des Verbrauchers ab.
Allgemein lässt sich festhalten, dass Verbräuche sehr schlecht prognostiziert werden können wenn
Verbraucher unregelmäßig verwendet werden, nicht durch SolarForcast geplant und geschaltet werden und eine hohe Leistung beziehen. Dann fehlt häufig die Grundlage um mit der Näherungsrechnung richtig zu liegen.
Zitat von: DS_Starter am 18 März 2025, 09:22:25Das ist richtig. Das Ziel dessen ist hier im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#PV-Prognose_und_Verbrauch_optimierte_Beladungssteuerung_unter_Ber%C3%BCcksichtigung_einer_Wirkleistungsbegrenzung) beschrieben.
Um eine Aussage/Einschätzung bzgl. dieser Steuerung vornehmen zu können, müsstest du mal ctrlDebug=batteryManagement einschalten und die Logausgabe posten. Dann sieht man am besten den Ablauf der Logik-Entscheidungen.
Hallo Heiko,
Vielen Dank für deine prompte Antwort!
anbei das Log-file mit den ctrlDebug - Daten, hab den Tag heute geloggt, hoffe das passt so?
Das Wiki habe ich (nochmal) gelesen und eigentlich so verstanden dass eine verzögerte Batterieladung erfolgen sollte (solange die Prognose eine (Voll-) Ladung der Bat ermöglicht).
Vielleicht ist es aber auch meine Einstellung die bewirkt das nur die BAT1 gemanagend wird. Ich würde bloß gern verstehen warum BAT2 und BAT3 immer Ladefreigabe haben
Gruß Gerd
Das Steuerungsverhalten resultiert aus den Verhältnissen der Batteriekapazitäten zueinander und den daraus resultierenden Aufteilungen der beteiligten Kennzahlen.
Bat 01 relLoad 18 11 -> 0 (currsoc: 73.982 %, SoCfc: 74.0 %, soc: 6880 Wh, pvfc: 4883, confc: 767, Surp Day: 346652 Wh, Curr PV: 9814 W, Curr Consumption: 5110 W, Limit: 15190 W)
Bat 02 relLoad 18 11 -> 1 (currsoc: 91 %, SoCfc: 100.0 %, soc: 7500 Wh, pvfc: 3938, confc: 618, Surp Day: 0 Wh, Curr PV: 9814 W, Curr Consumption: 5110 W, Limit: 15190 W)
Bat 03 relLoad 18 11 -> 1 (currsoc: 68 %, SoCfc: 100.0 %, soc: 5500 Wh, pvfc: 2888, confc: 454, Surp Day: 0 Wh, Curr PV: 9814 W, Curr Consumption: 5110 W, Limit: 15190 W)
Die Kennzahl Surp Day ist bei den Bat2/3 = 0, was automatisch eine Ladefreigabe der Bat bedeutet. Allerdings ist mir Surp Day = 0 noch schleierhaft. Möglicherweise muß ich das Debug noch erweitern um dahinter zu kommen.
Hallo Heiko,
Zitat von: DS_Starter am 18 März 2025, 18:09:46ich sehe zumindest einen sehr hohen Verbrauchswert von 638 kWh der in deiner History aufgezeichnet wurde:
mit dem heutigen Tag scheint das tatsächlich erledigt zu sein. Die Verbrauchsprognose ist für den Tag und die einzelnen Stunden realistisch:
screen.png
Ich habe auch nicht herausgefunden, woher dieser viel zu hohe Verbrauch kam.
Viele Grüße,
Peter
ich habe gestern die aktuelle Version eingespielt, seither funktioniert die Anzeige des SOC meiner Batterie nicht mehr, stattdessen wird 0% angezeigt.
Nach dem Update habe ich gemerkt, dass ich erst das Attribut setupBattery... anlegen muss.
Was mach ich falsch? Solcast Device:
define solcast SolarForecast
attr solcast DbLogExclude .*
attr solcast DbLogInclude Current_.*
attr solcast comment "wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr solcast consumer01 Stromverbrauch_Zaehler2 type=heater power=2100 icon=sani_floor_heating pcurr=P_act_tot-get:kW etotal=total-get:kWh
attr solcast consumer02 Shelly_Waschmaschine type=washingmachine power=3000 mintime=60 pcurr=power:W etotal=energykwh:kWh icon=scene_washing_machine
attr solcast consumer03 Shelly_Trockner type=dryer power=3000 mintime=60 pcurr=power:W etotal=energykwh:kWh icon=scene_laundry_room
attr solcast consumer04 HTTPMOD_Wallbox type=charger power=0 pcurr=devices_01_power_w:W etotal=devices_01_total_energy:kWh icon=car_in
attr solcast consumerLegend icon_bottom
attr solcast ctrlNextDayForecastReadings 12,13
attr solcast event-on-change-reading .*
attr solcast flowGraphicControl size=600 animate=1
attr solcast graphicBeam1Color 38DE4D
attr solcast graphicBeam1Content pvForecast
attr solcast graphicBeam1FontColor 000000
attr solcast graphicBeam2Color FF8E2B
attr solcast graphicBeam2Content pvReal
attr solcast graphicBeam2FontColor 000000
attr solcast graphicHourCount 30
attr solcast graphicLayoutType double
attr solcast graphicWeatherColor FFC933
attr solcast room Technik_PV
attr solcast setupBatteryDev01 BatterieWR pin=BatteryPowerBMS2:kW pout=-pin intotal=BatteryChargeTotal:kWh outtotal=BatteryDischargeTotal:kWh cap=10:kWh charge=BatteryCapacity
attr solcast setupInverterDev01 Stromverbrauch_Zaehler11 pv=P_act-get:kW etotal=total-get:kWh
attr solcast setupInverterStrings Hausdach,Hausdach2,GartenhausSued,GartenhausNord
attr solcast setupMeterDev Stromverbrauch_Zaehler1_EHZ gcon=aktuellerverbrauch-get:kW contotal=total-get:kWh gfeedin=-gcon feedtotal=ueberschuss-total-get:kWh conprice=0.3:€ feedprice =0.08:€
attr solcast setupRadiationAPI DWD_Forecast
attr solcast setupStringPeak Hausdach=4.86 Hausdach2=2.49 GartenhausSued=0.6 GartenhausNord=0.6
attr solcast setupWeatherDev1 DWD_Forecast
# FUUID 62487147-f33f-ae17-74c6-e655d31e5ac447b7
# FVERSION 76_SolarForecast.pm:v1.48.0-s29752/2025-03-14
# LCACHEFILE last write time: 07:51:12 File: ./FHEM/FhemUtils/PVCfg_SolarForecast_solcast
# MODE Automatic / Event-controlled - next planned Cycletime: 07:56:10
# MODEL DWD
# NAME solcast
# NOTIFYDEV Stromverbrauch_Zaehler1_EHZ,Stromverbrauch_Zaehler2,Shelly_Waschmaschine,Shelly_Trockner,HTTPMOD_Wallbox,BatterieWR,Stromverbrauch_Zaehler11
# NR 393
# NTFY_ORDER 50-solcast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 1460
# HELPER:
# 01M15DONE 1
# 01M45DONE 1
# 02M15DONE 1
# 02M45DONE 1
# 03M15DONE 1
# 03M45DONE 1
# 04M15DONE 1
# 04M45DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV solcast
# SPGROOM
# VERSION 1.48.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 237
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:1397083
# telnet telnetPort_127.0.0.1_43844
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name solcast
# tsnext 1742370872.46547
# Helper:
# DBLOG:
# Current_AutarkyRate:
# logdb:
# TIME 1742367230.04523
# VALUE 100
# Current_BatCharge_01:
# logdb:
# TIME 1742367230.04523
# VALUE 21
# Current_Consumption:
# logdb:
# TIME 1742367300.0476
# VALUE 402
# Current_GridConsumption:
# logdb:
# TIME 1742367230.04523
# VALUE 0
# Current_GridFeedIn:
# logdb:
# TIME 1742367300.0476
# VALUE 12
# Current_PV:
# logdb:
# TIME 1742367300.0476
# VALUE 1644
# Current_PowerBatIn_01:
# logdb:
# TIME 1742367300.0476
# VALUE 1230
# Current_SelfConsumption:
# logdb:
# TIME 1742367300.0476
# VALUE 402
# Current_SelfConsumptionRate:
# logdb:
# TIME 1742367300.0476
# VALUE 24
# Current_Surplus:
# logdb:
# TIME 1742367300.0476
# VALUE 1242
# OLDREADINGS:
# READINGS:
# 2025-03-19 07:55:00 Current_AutarkyRate 100 %
# 2025-03-18 19:57:24 Current_BatCharge 71 %
# 2025-03-19 07:55:00 Current_BatCharge_01 21 %
# 2025-03-19 07:55:00 Current_Consumption 402 W
# 2025-03-19 07:55:00 Current_GridConsumption 0 W
# 2025-03-19 07:55:00 Current_GridFeedIn 12 W
# 2025-03-19 07:55:00 Current_PV 1644 W
# 2025-03-18 19:57:24 Current_PowerBatIn 0 W
# 2025-03-19 07:55:00 Current_PowerBatIn_01 1230 W
# 2025-03-18 19:57:24 Current_PowerBatOut 314 W
# 2025-03-19 07:55:00 Current_PowerBatOut_01 0 W
# 2025-03-19 07:55:00 Current_SelfConsumption 402 W
# 2025-03-19 07:55:00 Current_SelfConsumptionRate 24 %
# 2025-03-19 07:55:00 Current_Surplus 1242 W
# 2025-03-19 07:00:00 LastHourGridconsumptionReal 500 Wh
# 2025-03-19 07:00:00 LastHourPVforecast 96 Wh
# 2025-03-19 07:00:00 LastHourPVreal 0 Wh
# 2025-03-19 07:55:00 NextHours_Sum01_PVforecast 2175 Wh
# 2025-03-19 07:55:00 NextHours_Sum02_PVforecast 5056 Wh
# 2025-03-19 07:55:00 NextHours_Sum03_PVforecast 9927 Wh
# 2025-03-19 07:55:00 NextHours_Sum04_ConsumptionForecast 2865 Wh
# 2025-03-19 07:55:00 NextHours_Sum04_PVforecast 11857 Wh
# 2025-03-19 07:55:00 RestOfDayConsumptionForecast 11053 Wh
# 2025-03-19 07:55:00 RestOfDayPVforecast 31946 Wh
# 2025-03-19 00:59:49 Today_Hour01_GridConsumption 0 Wh
# 2025-03-19 00:59:49 Today_Hour01_GridFeedIn 0 Wh
# 2025-03-19 00:59:49 Today_Hour01_PVreal 0 Wh
# 2025-03-19 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2025-03-19 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2025-03-19 01:59:49 Today_Hour02_PVreal 0 Wh
# 2025-03-19 02:59:49 Today_Hour03_GridConsumption 500 Wh
# 2025-03-19 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2025-03-19 02:59:49 Today_Hour03_PVreal 0 Wh
# 2025-03-19 03:59:49 Today_Hour04_GridConsumption 500 Wh
# 2025-03-19 03:59:49 Today_Hour04_GridFeedIn 0 Wh
# 2025-03-19 03:59:49 Today_Hour04_PVreal 0 Wh
# 2025-03-19 04:59:49 Today_Hour05_GridConsumption 0 Wh
# 2025-03-19 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2025-03-19 04:59:49 Today_Hour05_PVreal 0 Wh
# 2025-03-19 05:59:49 Today_Hour06_GridConsumption 500 Wh
# 2025-03-19 05:59:49 Today_Hour06_GridFeedIn 0 Wh
# 2025-03-19 05:59:49 Today_Hour06_PVreal 0 Wh
# 2025-03-19 06:59:49 Today_Hour07_GridConsumption 500 Wh
# 2025-03-19 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2025-03-19 06:59:49 Today_Hour07_PVforecast 96 Wh
# 2025-03-19 06:59:49 Today_Hour07_PVreal 0 Wh
# 2025-03-19 07:55:00 Today_Hour08_BatIn_01 100 Wh
# 2025-03-19 07:55:00 Today_Hour08_BatOut_01 0 Wh
# 2025-03-19 07:55:00 Today_Hour08_GridConsumption 0 Wh
# 2025-03-19 07:55:00 Today_Hour08_GridFeedIn 0 Wh
# 2025-03-19 07:55:00 Today_Hour08_PVforecast 876 Wh
# 2025-03-19 07:55:00 Today_Hour08_PVreal 270 Wh
# 2025-03-19 07:55:00 Today_Hour09_PVforecast 2268 Wh
# 2025-03-19 07:55:00 Today_Hour10_PVforecast 2925 Wh
# 2025-03-19 07:55:00 Today_Hour11_PVforecast 5010 Wh
# 2025-03-19 07:55:00 Today_Hour12_PVforecast 1710 Wh
# 2025-03-19 07:55:00 Today_Hour13_PVforecast 3965 Wh
# 2025-03-19 07:55:00 Today_Hour14_PVforecast 5844 Wh
# 2025-03-19 07:55:00 Today_Hour15_PVforecast 4294 Wh
# 2025-03-19 07:55:00 Today_Hour16_PVforecast 3224 Wh
# 2025-03-19 07:55:00 Today_Hour17_PVforecast 2019 Wh
# 2025-03-19 07:55:00 Today_Hour18_PVforecast 616 Wh
# 2025-03-19 07:55:00 Today_Hour19_PVforecast 13 Wh
# 2025-03-19 07:55:00 Today_MaxPVforecast 5844 Wh
# 2025-03-19 07:55:00 Today_MaxPVforecastTime 2025-03-19 13:00:00
# 2025-03-19 07:55:00 Today_PVforecast 32860 Wh
# 2025-03-19 07:55:00 Today_PVreal 270 Wh
# 2025-03-19 07:55:00 Today_SunRise 06:20
# 2025-03-19 07:55:00 Today_SunSet 18:25
# 2025-03-19 07:55:00 Tomorrow_ConsumptionForecast 17750 Wh
# 2025-03-19 07:55:00 Tomorrow_Hour12_PVforecast 5943 Wh
# 2025-03-19 07:55:00 Tomorrow_Hour13_PVforecast 6550 Wh
# 2025-03-19 07:55:00 Tomorrow_PVforecast 38247 Wh
# 2025-03-19 07:55:00 Tomorrow_SunRise 06:18
# 2025-03-19 07:55:00 Tomorrow_SunSet 18:27
# 2025-03-19 07:55:00 consumer01 name='Stromverbrauch_Zaehler2' state='unknown' mode='can' planningstate='planned'
# 2025-03-19 07:55:00 consumer01_currentPower 11 W
# 2025-03-19 07:55:00 consumer01_planned_start 19.03.2025 08:00:00
# 2025-03-19 07:55:00 consumer01_planned_stop 19.03.2025 12:00:00
# 2025-03-19 07:55:00 consumer02 name='Shelly_Waschmaschine' state='on' mode='can' planningstate='planned'
# 2025-03-19 07:55:00 consumer02_currentPower 0 W
# 2025-03-19 07:55:00 consumer02_planned_start 19.03.2025 07:45:41
# 2025-03-19 07:55:00 consumer02_planned_stop 19.03.2025 08:45:41
# 2025-03-19 07:55:00 consumer03 name='Shelly_Trockner' state='on' mode='can' planningstate='planned'
# 2025-03-19 07:55:00 consumer03_currentPower 0 W
# 2025-03-19 07:55:00 consumer03_planned_start 19.03.2025 07:45:41
# 2025-03-19 07:55:00 consumer03_planned_stop 19.03.2025 08:45:41
# 2025-03-19 07:55:00 consumer04 name='HTTPMOD_Wallbox' state='unknown' mode='can' planningstate='planned'
# 2025-03-19 07:55:00 consumer04_currentPower 1 W
# 2025-03-19 07:55:00 consumer04_planned_start 19.03.2025 07:45:41
# 2025-03-19 07:55:00 consumer04_planned_stop 19.03.2025 09:45:41
# 2023-09-16 07:21:23 currentBatteryDev BatterieWR pin=BatteryPowerBMS2:kW pout=-pin intotal=BatteryChargeTotal:kWh outtotal=BatteryDischargeTotal:kWh charge=BatteryCapacity
# 2022-04-03 18:59:44 currentInverterDev Stromverbrauch_Zaehler11 pv=P_act-get:kW etotal=total-get:kWh
# 2024-03-17 09:24:04 currentMeterDev Stromverbrauch_Zaehler1_EHZ gcon=aktuellerverbrauch-get:kW contotal=total-get:kWh gfeedin=-gcon feedtotal=ueberschuss-total-get:kWh conprice=0.3:€ feedprice =0.08:€
# 2023-11-21 21:30:01 currentRadiationAPI DWD_Forecast
# 2023-07-20 21:35:59 inverterStrings Hausdach,Hausdach2,GartenhausSued,GartenhausNord
# 2023-07-20 21:36:24 modulePeakString Hausdach=4.86 Hausdach2=2.49 GartenhausSued=0.6 GartenhausNord=0.6
# 2025-03-19 07:55:00 nextCycletime 07:56:10
# 2023-03-30 17:11:04 nextPolltime 17:12:14
# 2025-03-19 07:55:00 pvCorrectionFactor_Auto on_complex_ai
# 2024-08-21 08:39:30 setupStringAzimuth Hausdach=S Hausdach2=S GartenhausSued=S GartenhausNord=N
# 2024-08-21 08:39:30 setupStringDeclination Hausdach=20 Hausdach2=20 GartenhausSued=10 GartenhausNord=10
# 2025-03-19 07:55:01 state updated
#
setstate solcast updated
setstate solcast 2025-03-19 07:51:11 .associatedWith Stromverbrauch_Zaehler1_EHZ Stromverbrauch_Zaehler2 Shelly_Waschmaschine Shelly_Trockner HTTPMOD_Wallbox BatterieWR Stromverbrauch_Zaehler11 DWD_Forecast
setstate solcast 2025-03-19 07:55:00 .lastupdateForecastValues 1742367300
setstate solcast 2025-03-19 07:55:00 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate solcast 2025-03-19 01:00:05 .signaldone_01 done
setstate solcast 2025-03-19 02:00:04 .signaldone_02 done
setstate solcast 2025-03-19 03:00:04 .signaldone_03 done
setstate solcast 2025-03-19 04:00:04 .signaldone_04 done
setstate solcast 2025-03-19 05:00:00 .signaldone_05 done
setstate solcast 2025-03-19 06:00:05 .signaldone_06 done
setstate solcast 2025-03-19 07:00:05 .signaldone_07 done
setstate solcast 2025-03-19 00:00:04 .signaldone_24 done
setstate solcast 2025-03-19 07:55:00 Current_AutarkyRate 100 %
setstate solcast 2025-03-18 19:57:24 Current_BatCharge 71 %
setstate solcast 2025-03-19 07:55:00 Current_BatCharge_01 21 %
setstate solcast 2025-03-19 07:55:00 Current_Consumption 402 W
setstate solcast 2025-03-19 07:55:00 Current_GridConsumption 0 W
setstate solcast 2025-03-19 07:55:00 Current_GridFeedIn 12 W
setstate solcast 2025-03-19 07:55:00 Current_PV 1644 W
setstate solcast 2025-03-18 19:57:24 Current_PowerBatIn 0 W
setstate solcast 2025-03-19 07:55:00 Current_PowerBatIn_01 1230 W
setstate solcast 2025-03-18 19:57:24 Current_PowerBatOut 314 W
setstate solcast 2025-03-19 07:55:00 Current_PowerBatOut_01 0 W
setstate solcast 2025-03-19 07:55:00 Current_SelfConsumption 402 W
setstate solcast 2025-03-19 07:55:00 Current_SelfConsumptionRate 24 %
setstate solcast 2025-03-19 07:55:00 Current_Surplus 1242 W
setstate solcast 2025-03-19 07:00:00 LastHourGridconsumptionReal 500 Wh
setstate solcast 2025-03-19 07:00:00 LastHourPVforecast 96 Wh
setstate solcast 2025-03-19 07:00:00 LastHourPVreal 0 Wh
setstate solcast 2025-03-19 07:55:00 NextHours_Sum01_PVforecast 2175 Wh
setstate solcast 2025-03-19 07:55:00 NextHours_Sum02_PVforecast 5056 Wh
setstate solcast 2025-03-19 07:55:00 NextHours_Sum03_PVforecast 9927 Wh
setstate solcast 2025-03-19 07:55:00 NextHours_Sum04_ConsumptionForecast 2865 Wh
setstate solcast 2025-03-19 07:55:00 NextHours_Sum04_PVforecast 11857 Wh
setstate solcast 2025-03-19 07:55:00 RestOfDayConsumptionForecast 11053 Wh
setstate solcast 2025-03-19 07:55:00 RestOfDayPVforecast 31946 Wh
setstate solcast 2025-03-19 00:59:49 Today_Hour01_GridConsumption 0 Wh
setstate solcast 2025-03-19 00:59:49 Today_Hour01_GridFeedIn 0 Wh
setstate solcast 2025-03-19 00:59:49 Today_Hour01_PVreal 0 Wh
setstate solcast 2025-03-19 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate solcast 2025-03-19 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate solcast 2025-03-19 01:59:49 Today_Hour02_PVreal 0 Wh
setstate solcast 2025-03-19 02:59:49 Today_Hour03_GridConsumption 500 Wh
setstate solcast 2025-03-19 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate solcast 2025-03-19 02:59:49 Today_Hour03_PVreal 0 Wh
setstate solcast 2025-03-19 03:59:49 Today_Hour04_GridConsumption 500 Wh
setstate solcast 2025-03-19 03:59:49 Today_Hour04_GridFeedIn 0 Wh
setstate solcast 2025-03-19 03:59:49 Today_Hour04_PVreal 0 Wh
setstate solcast 2025-03-19 04:59:49 Today_Hour05_GridConsumption 0 Wh
setstate solcast 2025-03-19 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate solcast 2025-03-19 04:59:49 Today_Hour05_PVreal 0 Wh
setstate solcast 2025-03-19 05:59:49 Today_Hour06_GridConsumption 500 Wh
setstate solcast 2025-03-19 05:59:49 Today_Hour06_GridFeedIn 0 Wh
setstate solcast 2025-03-19 05:59:49 Today_Hour06_PVreal 0 Wh
setstate solcast 2025-03-19 06:59:49 Today_Hour07_GridConsumption 500 Wh
setstate solcast 2025-03-19 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate solcast 2025-03-19 06:59:49 Today_Hour07_PVforecast 96 Wh
setstate solcast 2025-03-19 06:59:49 Today_Hour07_PVreal 0 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour08_BatIn_01 100 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour08_BatOut_01 0 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour08_GridConsumption 0 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour08_GridFeedIn 0 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour08_PVforecast 876 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour08_PVreal 270 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour09_PVforecast 2268 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour10_PVforecast 2925 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour11_PVforecast 5010 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour12_PVforecast 1710 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour13_PVforecast 3965 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour14_PVforecast 5844 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour15_PVforecast 4294 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour16_PVforecast 3224 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour17_PVforecast 2019 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour18_PVforecast 616 Wh
setstate solcast 2025-03-19 07:55:00 Today_Hour19_PVforecast 13 Wh
setstate solcast 2025-03-19 07:55:00 Today_MaxPVforecast 5844 Wh
setstate solcast 2025-03-19 07:55:00 Today_MaxPVforecastTime 2025-03-19 13:00:00
setstate solcast 2025-03-19 07:55:00 Today_PVforecast 32860 Wh
setstate solcast 2025-03-19 07:55:00 Today_PVreal 270 Wh
setstate solcast 2025-03-19 07:55:00 Today_SunRise 06:20
setstate solcast 2025-03-19 07:55:00 Today_SunSet 18:25
setstate solcast 2025-03-19 07:55:00 Tomorrow_ConsumptionForecast 17750 Wh
setstate solcast 2025-03-19 07:55:00 Tomorrow_Hour12_PVforecast 5943 Wh
setstate solcast 2025-03-19 07:55:00 Tomorrow_Hour13_PVforecast 6550 Wh
setstate solcast 2025-03-19 07:55:00 Tomorrow_PVforecast 38247 Wh
setstate solcast 2025-03-19 07:55:00 Tomorrow_SunRise 06:18
setstate solcast 2025-03-19 07:55:00 Tomorrow_SunSet 18:27
setstate solcast 2025-03-19 07:55:00 consumer01 name='Stromverbrauch_Zaehler2' state='unknown' mode='can' planningstate='planned'
setstate solcast 2025-03-19 07:55:00 consumer01_currentPower 11 W
setstate solcast 2025-03-19 07:55:00 consumer01_planned_start 19.03.2025 08:00:00
setstate solcast 2025-03-19 07:55:00 consumer01_planned_stop 19.03.2025 12:00:00
setstate solcast 2025-03-19 07:55:00 consumer02 name='Shelly_Waschmaschine' state='on' mode='can' planningstate='planned'
setstate solcast 2025-03-19 07:55:00 consumer02_currentPower 0 W
setstate solcast 2025-03-19 07:55:00 consumer02_planned_start 19.03.2025 07:45:41
setstate solcast 2025-03-19 07:55:00 consumer02_planned_stop 19.03.2025 08:45:41
setstate solcast 2025-03-19 07:55:00 consumer03 name='Shelly_Trockner' state='on' mode='can' planningstate='planned'
setstate solcast 2025-03-19 07:55:00 consumer03_currentPower 0 W
setstate solcast 2025-03-19 07:55:00 consumer03_planned_start 19.03.2025 07:45:41
setstate solcast 2025-03-19 07:55:00 consumer03_planned_stop 19.03.2025 08:45:41
setstate solcast 2025-03-19 07:55:00 consumer04 name='HTTPMOD_Wallbox' state='unknown' mode='can' planningstate='planned'
setstate solcast 2025-03-19 07:55:00 consumer04_currentPower 1 W
setstate solcast 2025-03-19 07:55:00 consumer04_planned_start 19.03.2025 07:45:41
setstate solcast 2025-03-19 07:55:00 consumer04_planned_stop 19.03.2025 09:45:41
setstate solcast 2023-09-16 07:21:23 currentBatteryDev BatterieWR pin=BatteryPowerBMS2:kW pout=-pin intotal=BatteryChargeTotal:kWh outtotal=BatteryDischargeTotal:kWh charge=BatteryCapacity
setstate solcast 2022-04-03 18:59:44 currentInverterDev Stromverbrauch_Zaehler11 pv=P_act-get:kW etotal=total-get:kWh
setstate solcast 2024-03-17 09:24:04 currentMeterDev Stromverbrauch_Zaehler1_EHZ gcon=aktuellerverbrauch-get:kW contotal=total-get:kWh gfeedin=-gcon feedtotal=ueberschuss-total-get:kWh conprice=0.3:€ feedprice =0.08:€
setstate solcast 2023-11-21 21:30:01 currentRadiationAPI DWD_Forecast
setstate solcast 2023-07-20 21:35:59 inverterStrings Hausdach,Hausdach2,GartenhausSued,GartenhausNord
setstate solcast 2023-07-20 21:36:24 modulePeakString Hausdach=4.86 Hausdach2=2.49 GartenhausSued=0.6 GartenhausNord=0.6
setstate solcast 2025-03-19 07:55:00 nextCycletime 07:56:10
setstate solcast 2023-03-30 17:11:04 nextPolltime 17:12:14
setstate solcast 2025-03-19 07:55:00 pvCorrectionFactor_Auto on_complex_ai
setstate solcast 2024-08-21 08:39:30 setupStringAzimuth Hausdach=S Hausdach2=S GartenhausSued=S GartenhausNord=N
setstate solcast 2024-08-21 08:39:30 setupStringDeclination Hausdach=20 Hausdach2=20 GartenhausSued=10 GartenhausNord=10
setstate solcast 2025-03-19 07:55:01 state updated
Batterie (ich habe ein paar vermutlich unwichtige Zeilen entfernt, sonst ist der Beitrag zu lang zum abschicken):
define BatterieWR ModbusAttr 1 60 172.16.1.41:4196
attr BatterieWR DbLogExclude .*
attr BatterieWR DbLogInclude (ActivePower|DCPower|BatteryPowerBMS|stat.*|ErzeugungLastMonth|InverterTemperature|BatteryCapacity|InverterGenerationTotal|BatteryVoltageBMS.*)
attr BatterieWR comment 33149 BatteryPower kann nicht gelesen werden, also wird es aus Spannung, Strom und Richtung berechnet.\
Es wird öfter umständlich das Vorzeichen berechnet, da es nicht bei allen Parametern mitgeliefert wird\
verbose ist auf 2, da momentan der Logstick ebenfalls als Master am Bus hängt, und das mag FHEM zu Recht nicht
attr BatterieWR dev-i-defPoll 1
attr BatterieWR dev-i-defShowGet 1
attr BatterieWR dev-timing-commDelay 0.4
attr BatterieWR enableControlSet 1
attr BatterieWR group Wechselrichter
attr BatterieWR obj-i33029-len 2
attr BatterieWR obj-i33029-poll 1
attr BatterieWR obj-i33029-reading InverterGenerationTotalIn
attr BatterieWR obj-i33029-unpack N
attr BatterieWR obj-i33035-expr $val*0.1
attr BatterieWR obj-i33035-format %.1f
attr BatterieWR obj-i33035-len 1
attr BatterieWR obj-i33035-poll 1
attr BatterieWR obj-i33035-reading InverterGenerationToday
attr BatterieWR obj-i33057-expr $val/1000
attr BatterieWR obj-i33057-len 2
attr BatterieWR obj-i33057-poll 1
attr BatterieWR obj-i33057-reading DCPower
attr BatterieWR obj-i33057-unpack N
attr BatterieWR obj-i33079-expr $val*0.001
attr BatterieWR obj-i33079-len 2
attr BatterieWR obj-i33079-reading ActivePower
attr BatterieWR obj-i33079-unpack l>
attr BatterieWR obj-i33093-expr $val*0.1
attr BatterieWR obj-i33093-len 1
attr BatterieWR obj-i33093-reading InverterTemperature
attr BatterieWR obj-i33095-len 1
attr BatterieWR obj-i33095-map 0:Waiting,1:OpenRun,2:Softrun,3:Generating,4100:OffGrid,8210:BMS Com Fail,8213:BMS Alarm
attr BatterieWR obj-i33095-poll 1
attr BatterieWR obj-i33095-reading Status
attr BatterieWR obj-i33133-expr $val*0.1
attr BatterieWR obj-i33133-len 1
attr BatterieWR obj-i33133-reading BatteryVoltage
attr BatterieWR obj-i33134-expr $val*0.1
attr BatterieWR obj-i33134-len 1
attr BatterieWR obj-i33134-reading BatteryCurrent
attr BatterieWR obj-i33135-len 1
attr BatterieWR obj-i33135-poll 1
attr BatterieWR obj-i33135-reading BatteryCurrentDirection
attr BatterieWR obj-i33135-showGet 1
attr BatterieWR obj-i33139-len 1
attr BatterieWR obj-i33139-poll 1
attr BatterieWR obj-i33139-reading BatteryCapacity
attr BatterieWR obj-i33141-expr $val*0.01
attr BatterieWR obj-i33141-len 1
attr BatterieWR obj-i33141-poll 1
attr BatterieWR obj-i33141-reading BatteryVoltageBMS
attr BatterieWR obj-i33141-unpack n
attr BatterieWR obj-i33142-expr $val*0.1
attr BatterieWR obj-i33142-len 1
attr BatterieWR obj-i33142-poll 1
attr BatterieWR obj-i33142-reading BatteryCurrentBMS
attr BatterieWR obj-i33142-unpack s>
attr BatterieWR obj-i33161-len 2
attr BatterieWR obj-i33161-poll 1
attr BatterieWR obj-i33161-reading BatteryChargeTotalIn
attr BatterieWR obj-i33161-unpack N
attr BatterieWR obj-i33163-expr $val*0.1
attr BatterieWR obj-i33163-len 1
attr BatterieWR obj-i33163-poll 1
attr BatterieWR obj-i33163-reading BatteryChargeToday
attr BatterieWR obj-i33165-len 2
attr BatterieWR obj-i33165-poll 1
attr BatterieWR obj-i33165-reading BatteryDischargeTotalIn
attr BatterieWR obj-i33165-unpack N
attr BatterieWR obj-i33167-expr $val*0.1
attr BatterieWR obj-i33167-len 1
attr BatterieWR obj-i33167-poll 1
attr BatterieWR obj-i33167-reading BatteryDischargeToday
attr BatterieWR obj-i33251-expr $val*0.1
attr BatterieWR obj-i33251-len 1
attr BatterieWR obj-i33251-reading MeterVoltageA
attr BatterieWR obj-i33252-expr $val*0.01
attr BatterieWR obj-i33252-len 1
attr BatterieWR obj-i33252-reading MeterCurrentAin
attr BatterieWR obj-i33253-expr $val*0.1
attr BatterieWR obj-i33253-len 1
attr BatterieWR obj-i33253-reading MeterVoltageB
attr BatterieWR obj-i33254-expr $val*0.01
attr BatterieWR obj-i33254-len 1
attr BatterieWR obj-i33254-reading MeterCurrentBin
attr BatterieWR obj-i33255-expr $val*0.1
attr BatterieWR obj-i33255-len 1
attr BatterieWR obj-i33255-reading MeterVoltageC
attr BatterieWR obj-i33256-expr $val*0.01
attr BatterieWR obj-i33256-len 1
attr BatterieWR obj-i33256-reading MeterCurrentCin
attr BatterieWR obj-i33257-expr $val*0.001
attr BatterieWR obj-i33257-len 2
attr BatterieWR obj-i33257-reading MeterActivePowerA
attr BatterieWR obj-i33257-unpack l>
attr BatterieWR obj-i33259-expr $val*0.001
attr BatterieWR obj-i33259-len 2
attr BatterieWR obj-i33259-reading MeterActivePowerB
attr BatterieWR obj-i33259-unpack l>
attr BatterieWR obj-i33261-expr $val*0.001
attr BatterieWR obj-i33261-len 2
attr BatterieWR obj-i33261-reading MeterActivePowerC
attr BatterieWR obj-i33261-unpack l>
attr BatterieWR room Technik_PV
attr BatterieWR skipGarbage 1
attr BatterieWR stateFormat DCPower kW Erzeugung InverterGenerationToday kWh heute BatteryCapacity% Batterie BatteryPower BatteryPowerBMS kW Batterieleistung Status
attr BatterieWR userReadings ForecastAktMonth:statInverterGenerationTotal.* {calcmonthusageSplit($name,"statInverterGenerationTotal",5)},\
BatteryPower:BatteryCurrentDirection.* {sprintf("%.3f",ReadingsNum($name,"BatteryVoltage",0)*ReadingsNum($name,"BatteryCurrent",0)*(ReadingsNum($name,"BatteryCurrentDirection",0)<=0?1:-1)/1000)},\
BatteryPowerBMS:BatteryCurrentBMS.* {sprintf("%.3f",ReadingsNum($name,"BatteryVoltageBMS",0)*ReadingsNum($name,"BatteryCurrentBMS",0)*(ReadingsNum($name,"BatteryCurrentDirection",0)<=0?1:-1)/1000)},\
BatteryPowerBMS2:BatteryPowerBMS.* {ReadingsNum($name,"BatteryPowerBMS",0)>=0?ReadingsNum($name,"BatteryPowerBMS",0):sprintf("%.3f",(ReadingsNum($name,"BatteryPowerBMS",0)*(1-0.1259))+0.06)},\
\
InverterGenerationTotal:InverterGenerationToday.* {\
my $var=ReadingsNum("BatterieWR","InverterGenerationTotalHelp",0)+ReadingsNum("BatterieWR","InverterGenerationToday",0);;;;\
return ( $var>=ReadingsNum("BatterieWR","InverterGenerationTotal",0)?$var:ReadingsNum("BatterieWR","InverterGenerationTotal",0))\
},\
BatteryChargeTotal:BatteryChargeToday.* {my $vara=ReadingsNum($name,"BatteryChargeTotalHelp",0)+ReadingsNum($name,"BatteryChargeToday",0);;;; $vara>=ReadingsNum($name,"BatteryChargeTotal",0)?$vara:ReadingsNum($name,"BatteryChargeTotal",0)},\
BatteryDischargeTotal:BatteryDischargeToday.* {my $varb=ReadingsNum($name,"BatteryDischargeTotalHelp",0)+ReadingsNum($name,"BatteryDischargeToday",0);;;; $varb>=ReadingsNum($name,"BatteryDischargeTotal",0)?$varb:ReadingsNum($name,"BatteryDischargeTotal",0)},\
MeterCurrentA:MeterActivePowerA.* {sprintf("%.3f",(ReadingsNum($name,"MeterActivePowerA",0)*1000)/ReadingsNum($name,"MeterVoltageA",0))},\
MeterCurrentB:MeterActivePowerB.* {sprintf("%.3f",(ReadingsNum($name,"MeterActivePowerB",0)*1000)/ReadingsNum($name,"MeterVoltageB",0))},\
MeterCurrentC:MeterActivePowerC.* {sprintf("%.3f",(ReadingsNum($name,"MeterActivePowerC",0)*1000)/ReadingsNum($name,"MeterVoltageC",0))},\
BatteryCapacitykwh:BatteryCapacity.* {sprintf("%.1f",(ReadingsNum($name,"BatteryCapacity",0)*13.2)/100)},\
BatteryCapacitymissing:BatteryCapacitykwh.* {sprintf("%.1f",13.2-ReadingsNum($name,"BatteryCapacitykwh",0))},\
BatteryChargetime:BatteryCapacitykwh.* {\
my $var=ReadingsNum($name,"BatteryPowerBMS",0);;\
if ($var>0) {\
$var=sprintf("%.1f",(ReadingsNum($name,"BatteryCapacitymissing",0))/$var);;\
}else{\
$var=0;; \
}\
return $var;;\
},\
\
MeterVoltageB\
\
attr BatterieWR verbose 2
# DEF 1 60 172.16.1.41:4196
# DeviceName 172.16.1.41:4196
# EXPECT response
# FD 4
# FUUID 6287ae83-f33f-ae17-6df4-762760f54d114cca
# IODev BatterieWR
# Interval 60
# LASTOPEN 1742324319.81887
# MODBUSID 1
# MODE master
# MODULEVERSION Modbus 4.5.6 - 7.11.2023
# NAME BatterieWR
# NOTIFYDEV global
# NR 394
# NTFY_ORDER 50-BatterieWR
# PARTIAL
# PROTOCOL RTU
# STATE 1.262 kW Erzeugung 0.3 kWh heute 21% Batterie 1.441 1.270 kW Batterieleistung Generating
# TCPConn 1
# TYPE ModbusAttr
# devioLoglevel 3
# devioNoSTATE 1
# eventCount 17811
# nextOpenDelay 60
# nextQueueRun 1742367355.03148
# nextTimeout 1742367356.02969
# FRAME:
# Helper:
# READ:
# BUFFER
# READINGS:
# 2025-03-19 07:55:46 ActivePower -0.09
# 2025-03-19 07:55:49 BatteryCapacity 21
# 2025-03-19 07:55:49 BatteryCapacitykwh 2.8
# 2025-03-19 07:55:49 BatteryCapacitymissing 10.4
# 2025-03-19 07:55:51 BatteryChargeToday 0.3
# 2025-03-19 07:55:51 BatteryChargeTotal 6135.3
# 2025-03-19 01:15:00 BatteryChargeTotalHelp 6135
# 2025-03-19 07:55:51 BatteryChargeTotalIn 6135
# 2025-03-19 07:55:49 BatteryChargetime 8.5
# 2025-03-19 07:55:48 BatteryCurrent 28.7
# 2025-03-19 07:55:50 BatteryCurrentBMS 25.7
# 2025-03-19 07:55:49 BatteryCurrentDirection 0
# 2025-03-19 07:55:52 BatteryDischargeToday 3.9
# 2025-03-19 07:55:52 BatteryDischargeTotal 7040.9
# 2025-03-19 01:15:00 BatteryDischargeTotalHelp 7037
# 2025-03-19 07:55:52 BatteryDischargeTotalIn 7040
# 2025-03-19 07:55:49 BatteryPower 1.441
# 2025-03-19 07:55:50 BatteryPowerBMS 1.270
# 2025-03-19 07:55:50 BatteryPowerBMS2 1.270
# 2025-03-19 07:55:48 BatteryVoltage 50.2
# 2025-03-19 07:55:50 BatteryVoltageBMS 49.43
# 2025-03-19 07:55:46 DCPower 1.262
# 2025-03-19 07:55:53 ForecastAktMonth 488
# 2025-03-18 19:58:39 IODev ModbusLine
# 2025-03-19 07:55:45 InverterGenerationToday 0.3
# 2025-03-19 07:55:45 InverterGenerationTotal 13894.3
# 2025-03-19 01:15:00 InverterGenerationTotalHelp 13894
# 2025-03-19 07:55:45 InverterGenerationTotalIn 13895
# 2025-03-19 07:55:47 InverterTemperature 33.2
# 2025-03-19 07:54:57 MeterActivePowerA -0.158
# 2025-03-19 07:54:58 MeterActivePowerB -0.155
# 2025-03-19 07:54:58 MeterActivePowerC 0.355
# 2025-03-19 07:54:57 MeterCurrentA -0.656
# 2025-03-19 07:55:53 MeterCurrentAin 0.88
# 2025-03-19 07:54:58 MeterCurrentB -0.641
# 2025-03-19 07:54:54 MeterCurrentBin 3.09
# 2025-03-19 07:54:58 MeterCurrentC 1.467
# 2025-03-19 07:54:57 MeterCurrentCin 1.48
# 2025-03-19 07:55:53 MeterVoltageA 240.7
# 2025-03-19 07:54:54 MeterVoltageB 241.7
# 2025-03-19 07:53:56 MeterVoltageC 242
# 2025-03-19 07:55:47 Status Generating
# 2025-03-19 07:55:53 statBatteryChargeTotal Hour: 0.1 Day: 0.1 Month: 151.1 Year: 469.4
# 2025-03-19 06:59:55 statBatteryChargeTotalLast Hour: 0.0 Day: 9.1 Month: 170.5 Year: 2689.0
# 2025-03-19 07:55:53 statBatteryDischargeTotal Hour: 0.2 Day: 4.7 Month: 156.9 Year: 554.8
# 2025-03-19 06:59:55 statBatteryDischargeTotalLast Hour: 0.2 Day: 7.0 Month: 197.7 Year: 2824.6
# 2025-03-19 07:55:53 statInverterGenerationTotal Hour: 0.2 Day: 0.2 Month: 303.5 Year: 704.0
# 2025-03-19 06:59:55 statInverterGenerationTotalLast Hour: 0.0 Day: 26.9 Month: 239.4 Year: 4637.0
# 2025-03-18 19:58:40 state opened
# REMEMBER:
# lid 1
# lname BatterieWR
# lrecv 1742367353.62857
# lsend 1742367354.03134
Moin Andy,
Ändere mal den Wert cap=10:kWh in cap=10000 ohne Einheit.
Das sollte helfen,
Gruß,
Peter
das hat geholfen, vielen Dank
Moin zusammen,
ZitatDie Kennzahl Surp Day ist bei den Bat2/3 = 0, was automatisch eine Ladefreigabe der Bat bedeutet. Allerdings ist mir Surp Day = 0 noch schleierhaft. Möglicherweise muß ich das Debug noch erweitern um dahinter zu kommen.
Ich habe einen Bug gefunden ... war wieder mit Kopfschmerz verbunden. ;)
Hier ein Debug Auszug wie es sich ab dem nächsten Release darstellen wird. Beachtet die Angabe von SurpDay bei beiden Batterien:
...
2025.03.19 09:21:14.128 1: SolCast6 DEBUG> Bat 01 relLoad 19 09 -> 1 (SoCfc: 83.5 %, soc: 4173 Wh, pvfc: 2094, rodpvfc: 11087, confcss: 1120, SurpDay: 9967 Wh, CurrSoc: 50.47 %, CurrPV: 3716 W, CurrCons: 940 W, Limit: 3500 W)
2025.03.19 09:21:14.130 1: SolCast6 DEBUG> Bat 01 relLoad 19 10 -> 0 (SoCfc: 83.5 %, soc: 4173 Wh, pvfc: 2168, rodpvfc: 3376, confcss: 295, SurpDay: 3081 Wh)
2025.03.19 09:21:14.133 1: SolCast6 DEBUG> Bat 01 relLoad 19 11 -> 1 (SoCfc: 100.0 %, soc: 5000 Wh, pvfc: 1949, rodpvfc: 2610, confcss: 0, SurpDay: 0 Wh)
...
2025.03.19 09:21:14.210 1: SolCast6 DEBUG> Bat 02 relLoad 19 09 -> 1 (SoCfc: 83.5 %, soc: 4173 Wh, pvfc: 2094, rodpvfc: 11087, confcss: 1120, SurpDay: 9967 Wh, CurrSoc: 50.47 %, CurrPV: 3716 W, CurrCons: 940 W, Limit: 3500 W)
2025.03.19 09:21:14.212 1: SolCast6 DEBUG> Bat 02 relLoad 19 10 -> 0 (SoCfc: 83.5 %, soc: 4173 Wh, pvfc: 2168, rodpvfc: 3376, confcss: 295, SurpDay: 3081 Wh)
2025.03.19 09:21:14.214 1: SolCast6 DEBUG> Bat 02 relLoad 19 11 -> 1 (SoCfc: 100.0 %, soc: 5000 Wh, pvfc: 1949, rodpvfc: 2610, confcss: 0, SurpDay: 0 Wh)
...
Beide (gleichen) Batterien bekommen "19 10 -> 0" als Vorgabe. Es ist eine Testinstallation bei der ich mit Dummies arbeite (habe nur eine reale Batterie).
LG,
Heiko
Hallo Heiko,
find ich gut das du einen Ansatz dazu gefunden hast.
Ich werde es dann morgen testen / beobachten, soweit heute bei mir der Strom wieder hergestellt werden wird.
Heute wird mein Producer01 (Brennstoffzelle) in den Ruhestand verabschiedet und parallel eine Wärmepumpe als neuer Großverbraucher installiert.
Solange schalte ich alles elektronisches ,,Gedöns" - wie meine immer Frau sagt - sicherheitshalber aus. 👨�💻💡🔌🔋🪫⚡️
Gruß und Danke für's finden des Bug's
300P
ZitatIch werde es dann morgen testen / beobachten, soweit heute bei mir der Strom wieder hergestellt werden wird.
Soll ich die neue Version schon ins contrib stellen?
In der Version gibt es noch eine Baustelle bzgl. OpenMeteo + KI. Wenn du diese Kombi bei dir nicht nutzt, könntest du testen.
Ich habe die Vorabversion von V 1.49.0 in mein contrib geladen. Hier sind schon einige Dinge weiterentwickelt.
Speziell die Batteriesteuerung mit mehreren Batterien ist gefixt.
Wichtig: Die Version bitte nicht testen falls ihr eine Kombi aus OpenMeteo + KI nutzt. Die KI würde in dieser Version tendenziell zu niedrige Ergebnisse prognostizieren. Ist noch eine Baustelle in dieser V.
Zitat von: DS_Starter am 19 März 2025, 12:30:24Wichtig: Die Version bitte nicht testen falls ihr eine Kombi aus OpenMeteo + KI nutzt. Die KI würde in dieser Version tendenziell zu niedrige Ergebnisse prognostizieren. Ist noch eine Baustelle in dieser V.
Hallo Heiko,
Super das du die Ursache gefunden hast - leider kann ich den derzeitigen Stand nicht testen da ich die Kombination OpenMeteo und KI verwende
Gruß Gerd
Hallo zusammen,
Punkte die in dem Major Release 1.49.0 enthalten sind:
- eine neue API-Option OpenMeteoDWD_D2-API (setupRadiationAPI) die nur das Modell ICON D2 für Mitteleuropa nutzt mit einer zeitlichen Auflösung von 15 Minuten. Diese Option soll perspektivisch die Satelliten-Unterstützung bekommen und alle Wetterdaten in der 15 minütigen Auflösung abgerufen werden (intern auf 1 h aggregiert)
- Attribut graphicBeamHeightLevel3 ist hinzugefügt
- der Setter "set ... reset aiData" löscht nicht nur die internen Strukturen, sondern auch das File auf OS-Ebene
- neues Attribut plantControl
- das Attribut affectBatteryPreferredCharge ist obsolet und als Schlüssel batteryPreferredCharge im Attr plantControl verfügbar
- das Attribut affectConsForecastInPlanning ist obsolet und als Schlüssel consForecastInPlanning im Attr plantControl verfügbar
- das Attribut ctrlShowLink ist obsolet und als Schlüssel showLink im Attr plantControl verfügbar
- Bugfix: die KI-Prognose ist begrenzt auf die Summe der installierten Inverter-Kapazitäten bzw. deren Limits
- Bugfix: die Ladeempfehlung bei mehreren installierten Batterien
- die Kompatibilität zwischen den für die KI gespeicherten Strahlungsdaten von DWD und OpenMeteo ist hergestellt.
Zukünftig wird auch bei Open-Meteo (wie bei DWD OpenData) die Globalstrahlung und nicht die GTI (Tilted Global Irridiance) im
KI-Rawdatensatz gespeichert. Die beiden Daten sind nicht kompatibel und müssen ggf. nach dem Update umgesetzt werden (s.u.)
Die Umstellung der Attribute erfolgt wie immer automatisch, ihr braucht an dieser Stelle nichts zu tun.
wichtiger Hinweis für Nutzer von Open-Meteo:
Wie oben geschrieben, werden für die KI ab dieser Version die GHI statt GTI Daten gespeichert. Die bisherigen Datensätze in aiRawData beinhalten die GTI Daten. Deswegen solltet ihr nach dem Update einmalig den neuen Befehl
set ... aiDecTree rawDataGHIreplace
ausführen. Der Befehl läuft etwas länger und überschreibt die GTI mit den von OpenMeteo gelieferten GHI-Daten. Wenn der Befehl ordnungsgemäß durch ist, wird im Log mit verbose 3 die Anzahl der Replacements ausgegeben:
2025.03.20 09:34:04.675 3: openMeteo - aiRawData -> number of datasets replaced rad1h: 3460
Danach das AI Learning durchführen oder einfach bis zum nächsten Autolerearning warten:
set ... aiDecTree addInstAndTrain
Danach hat die KI die GHI Daten im Bauch.
Es können zunächst immer noch durch KI-gelieferte Abweichungen gegenüber dem vorherigen Status zu beobachten sein (bedingt durch Differenzen in den gelieferten GHI-Daten), die sich mit fortschreitender Lern- und Trainingszeit wieder ausnivellieren.
Mit dieser Anpassung können wir zukünftig problemlos zwischen Open-Meteo und DWD OpenData switchen bzw. vllt. sogar die interne KI Unterstützung für API's die keine Strahlungsdaten liefern (SolCast, Victron-KI) implementieren da wir jederzeit die histrorischen Strahlungsdaten abrufen können.
LG,
Heiko
ich hab das update auf 1.49.0 durchgeführt, mein Open-Meteo auf GHI umgestellt und das KI-Training angestoßen.
Läuft alles soweit und "der PV-Vorhersagewert für die aktuelle Stunde wird von der KI Unterstützung geliefert" :D
Sehr gut Heiko, danke!
Zitat von: DS_Starter am 20 März 2025, 09:42:33- eine neue API-Option OpenMeteoDWD_D2-API (setupRadiationAPI) die nur das Modell ICON D2 für Mitteleuropa nutzt mit einer zeitlichen Auflösung von 15 Minuten. Diese Option soll perspektivisch die Satelliten-Unterstützung bekommen und alle Wetterdaten in der 15 minütigen Auflösung abgerufen werden (intern auf 1 h aggregiert)
Ich nutze aktuell OpenMeteoWorldAPI, die Daten sind bei Umstellung auf DWD vmtl. verloren, oder?
ZitatIch nutze aktuell OpenMeteoWorldAPI, die Daten sind bei Umstellung auf DWD vmtl. verloren, oder?
Nein, Daten gehen bei einem Wechsel zwischen den OpenMeteo Modellen nicht verloren.
Zwischen bestimmten Modellen, zb. DWD OpenData und OpenMeteo, gab es bisher Inkompatibilitäten. Die sind zukünftig aber beseitigt durch diese beschriebene Maßnahme, sodass man danach zwischen DWD OpenData und OpenMeteo wechseln kann.
Hallo zusammen,
ich habe mir Gedanken um die weitere Reduzierung der vielen Attribute gemacht und habe einige Attr identifiert, die man gut in neuen Attributen als Schlüssel clustern kann. Ihr kennt das Verfahren ja schon.
Es werden nur Attr thematisch zusammengefasst, die wenig Eingaben (wie 0,1 etc.) erfordern.
Es wären zwei neue Attr plantControl und consumerControl.
plantControl - aufnehmen alte Attr affectBatteryPreferredCharge -> in Key batteryPreferredCharge
affectConsForecastIdentWeekdays -> in Key consForecastIdentWeekdays
affectConsForecastInPlanning -> in Key consForecastInPlanning
affectConsForecastLastDays -> in Key consForecastLastDays
ctrlBackupFilesKeep -> in Key backupFilesKeep
ctrlGenPVdeviation -> in Key genPVdeviation
ctrlInterval -> in Key interval
ctrlShowLink -> in Key showLink
- neuen Schlüssel feedinPowerLimit
consumerControl - aufnehmen alte Attr consumerAdviceIcon -> in Key consumerAdviceIcon
consumerLink -> in Key consumerLink
consumerLegend -> in Key consumerLegend
Weiterhin das Attr affectSolCastPercentile löschen, ist wahrscheinlich unbenutzt?
Und es wird einen neuen Schlüssel in feedinPowerLimit in plantControl geben. Hier würde man ein Limit für die Einspeiseleistung der Anlage angeben können. Dieser Wert geht als Schwellenwert für die Bat-Ladefreigabe mit ein. D.h. ist die Bat-Ladung ausgeschaltet (weil z.B. später noch genug produziert wird), aber die Anlage aktuell soviel produziert dass der Schwellenwert überschritten wird (und demzufolge eine Abregelung erfolgen würde) wird die Bat-Ladung temporär freigegeben um diese Energie aufzunehmen, das Limit einzuhalten und eine Abregelung zu vermeiden.
Habt ihr Anmerkungen/Meinungen zu der Attributgestaltung?
Einen sonnigen Resttag,
Heiko
Guten Morgen Heiko,
Leider hat mein Heizungsbauer den RPI bei dem Heizungsumbau "geflutet". :'( :-X 😭
Parallel bin ich wg. Upgrade einer Batterie von LGH10HRESU auf eine LG16HPRIME etwas beschäftigt.
Zuerst muss ich mir dafür noch einen neuen RPI besorgen und hoffen das die SSD dann auch noch direkt wieder bootet.
Ich falle daher erst einmal für die Test mit den 2 Batterien b.a.w. aus. Melde mich wenn alles wieder läuft.....
Gruß
300P
Moin,
ach du Sch...e. :o
Da hast du ja deinen Spaß... was nicht alles bei solchen Aktionen passiert, unglaublich.
Viel Erfolg!
LG,
Heiko
Zitat von: DS_Starter am 20 März 2025, 09:42:33- Bugfix: die Ladeempfehlung bei mehreren installierten Batterien
Hallo Heiko,
habe gestern die Version 1.49 aus dem contrib geladen - und vor allem die Ladefreigabe mit mehreren Batterien getestet - aus meiner Sicht sieht es jetzt gut aus - die Ladefreigabe für die Batterien erfolgt verzögert und so wie ich das sehe auch 'individuell' auf die einzelne Batterie angepasst. Anbei meine Auswertungen - zur besseren Übersichtlichkeit Stück für Stück erweitert, zuerst die 001 mit nur einer Batterie (Ladezustand, Ladefreigabe) die 002 mit 2 Batterien und die 003 mit allen drei. Dazu muss ich sagen - sowohl gestern als auch heute waren hier zwei durchgehend sonnige Tage - also eine sehr übersichtliche Wetterlage.
Bei weiteren Fragen bzw. wenn noch zusätzlich Daten benötigt werden gerne melden.
@300P --> drück dir die Daumen das alles wieder ins Lot kommt
Gruß Gerd
Hallo zusammen,
kann die KI eigentlich die Verschattung einzelner Strings, die ja üblicherweise in unterschiedlichen Himmelsrichtungen und/oder Winkeln und montiert sind, erlernen?
Gemäß aiRawData erhält die KI diese Parameter als Trainingsgrundlage:
2025032215 => hod: 15, nod: Sa, sunaz: 217, sunalt: 35, rad1h: 7610, wcc: 89, wid: 3, rr1c: 0.00, pvrl: 3142, con: 884, temp: 16
Ich vermute, dass die Verschattung eines Strings (z.B. im Winter Vormittags im Schatten, im Sommer Vormittags in der Sonne) nur indirekt anhand der Summe der PV-Leistung erlernt werden kann. Diese Gesamt-PV-Leistung hängt aber noch von vielen anderen Dingen ab, daher dürfte das sehr ungenau sein.
Wäre es sinnvoll, aiRawData zu erweiterten, so dass die vorhandenen Datenfelder (Vorhersage, Leistung etc.) für jeden String separat gespeichert werden? Dann hätte die KI die Chance, eine Verschattung eines Strings viel direkter zu erlernen, als über die Summe aller Strings und das Ergebnis sollte genauer sein... Oder nicht?
VG,
Alex
Hallo,
habe ich dem Modul irgendwo die maximale Lade/Entladeleistung des Akkus mitgeteilt?
Falls ja, ich finde es nicht wieder. Falls nein: sollte man das einbauen?
Die Prognose des Akkustandes springt bei ausreichend Sonne innerhalb von einer Stunde von 10% auf 100%. Das macht der Akku in der Realität nicht mit. Außerdem wäre das nicht gewünscht, denn es soll ja die Mittagesspitze abgefedert werden und die dauert bei mir eher 3 bis 4 Stunden.
Kann man sich irgendwo anzeigen lassen, in welchem Zeitraum die Akkuladung eingeplant ist? Oder nur indirekt aus Battery_NextHourXY_SoCforecast?
VG Jens
Guten Abend,
@Alex
Zitatkann die KI eigentlich die Verschattung einzelner Strings, die ja üblicherweise in unterschiedlichen Himmelsrichtungen und/oder Winkeln und montiert sind, erlernen?
Ich vermute, dass die Verschattung eines Strings (z.B. im Winter Vormittags im Schatten, im Sommer Vormittags in der Sonne) nur indirekt anhand der Summe der PV-Leistung erlernt werden kann. Diese Gesamt-PV-Leistung hängt aber noch von vielen anderen Dingen ab, daher dürfte das sehr ungenau sein.
Es wird immer die Energie der Gesamtanlage auf Basis der Stunde gespeichert. In dieser Gesamtenergie hat jeder einzelne String auf Grund seiner Ausrichtung, evtl. Verschattung und weiteren Eigenschaften seinen individuellen Anteil. Wir erfassen aber die Gesamternergie, nicht die Energie der einzelnen Strings. Somit kann auch keine Separation in den aiRawData erfolgen.
Aber in jedem einzelnen Datensatz ist neben der Strahlung und anderen Werten auch der Sonne Azimut und Altitude gespeichert was u.A. ein Kennzeichen der Jahreszeit ist, die Sonne steht zu einer bestimmten Stunde (Azimut) in einer bestimmten Höhe (Altitude).
Wenn du jeden String einzeln betrachten möchtest, kannst du für jeden String ein eigenes SF-Device mit allen entsprechenden Angaben erstellen und die Vorhersagen bzw. anderen Werte aus den Readings über eigene Strukturen (z.B. Dummy) zusammenfassen. Deine Anlage muß natürlich die Möglichkeit bieten alle benötigten Werte separat erfassen/liefern zu können.
LG,
Heiko
@Jens,
Zitathabe ich dem Modul irgendwo die maximale Lade/Entladeleistung des Akkus mitgeteilt?
Falls nein: sollte man das einbauen?
Nein, hast du nicht. Das Thema habe ich aber bereits auf dem Schirm weil wir schon irgendwo weiter vorn festgestellt haben, dass es Sinn macht die max. mögliche Lade/Entladeleistung des Batteeriedevice angeben bzw. berücksichtigen zu können.
Den aktuelle Stand werde ich erstmal einchecken und diese Möglichkeit im nächsten Release mit vorsehen.
ZitatKann man sich irgendwo anzeigen lassen, in welchem Zeitraum die Akkuladung eingeplant ist? Oder nur indirekt aus Battery_NextHourXY_SoCforecast?
Nur damit keine Mißverständnisse aufkommen, SF
plant keinerlei Batterieladungen wie man es evtl. von den Consumern her kennt. Es wird lediglich eine Empfehlung über das Reading Battery_ChargeRecommended_XX=0 gegeben, wenn man vorerst auf die Ladung verzichten sollte um durch eine spätere Ladungsfreigabe die Einspeisung zu reduzieren. Ebenfalls wird über die SOC-Steuerung (Reading Battery_OptimumTargetSoC_XX) eine Empfehlung für den optimalen SOC dem User an die Hand gegeben. Er kann dieser Empfehlung folgen oder nicht.
Die (vorläufige) Empfehlung zur Batterie Ladung/Nichtladung der kommenden Stunden erkennt man in der Balkengrafik wenn man sich die Batterie einblendet.
ZitatKann man sich irgendwo anzeigen lassen, in welchem Zeitraum die Akkuladung eingeplant ist? Oder nur indirekt aus Battery_NextHourXY_SoCforecast?
Wie gesagt gibt es keine Einplanung seitens des Moduls. Es gibt jedoch eine Schätzung wie sich der SoC entwickeln wird wenn die Empfehlung zur Ladung und der SOC-Steuerung umgesetzt wird. Das Modul berücksichtigt dabei auch die zu erwartenden PV Erzeugung bzw. Hausverbräuche. Das alles zusammen führt zu einem wahrscheinlichen SoC-Stand für jede Stunde in der Zukunft den man in der Grafik bzw. den Readings Battery_NextHourXX_SoCforecast findet.
Wie oben geschrieben, sieht man die (vorläufige) Empfehlung zur Batterie Ladung/Nichtladung der kommenden Stunden in der Balkengrafik wenn man sich die Batterie einblendet.
LG,
Heiko
Zitat von: DS_Starter am 22 März 2025, 08:45:50Moin,
ach du Sch...e. :o
Da hast du ja deinen Spaß... was nicht alles bei solchen Aktionen passiert, unglaublich.
Viel Erfolg!
LG,
Heiko
So - geschafft ;D
Ein RPI-Systems ist wieder aufgesetzt mittels einer SD-Card.
Leider sind beide SSD's (Backup-SSD leider auch => :'( ) wegen dem Heizungswasser nicht mehr zu gebrauchen.....
.....UND natürlich als erstes FHEM mit Solarforcast in "Miniversion" neu aufgesetzt.(aber nur mit Inverter/Batterien/Energiezähler)
Jetzt reicht mir dann auch - die anderen "netten Spielereien" kommen nach, wenn ich mal wieder Lust dazu habe.
Gott sei Dank hab ich auch noch verstreut Daten auf verschiedenen Festplatten von diversen Entwicklungen - nur halt kein komplettes Backup
Gruß
300P
Na Hauptsache wieder "online"!
Mir selbst geht es ganz schlecht und ich fühle mich krank wenn die Haustechnik nicht funktioniert. FHEM ist über die Jahre ein sehr sehr wichtiger Bestandteil geworden, auch wenn die lebenswichtigen Funktionen auch ohne funktionieren, aber es fehlt dann etwas, man fühlt sich "nackt". ;)
Morgen früh ist die Version 1.49.0 im Update enthalten.
Zitat von: DS_Starter am 21 März 2025, 15:52:20Habt ihr Anmerkungen/Meinungen zu der Attributgestaltung?
Guten Morgen Heiko,
hab zu den Attributen mal nachgedacht wo ich die meisten Verständnisprobleme bei der Einrichtung meiner Anlage hatte und aus meiner Sicht sinnvolle Cluster beschrieben. Die Schlüssel der Attribute könnten ja so bleiben nur eben komprimiert auf wenigere Attribute.
ctrlBatSocManagementxx integrieren in setupBatteryDevxx
setupStringPeak und setupInverterStrings könnten in setupInverterDevxx
und bei einigen könnte man die Anzahl ja regulieren so das defaultmäßig z.B. nur der setupInverter01 (Batterie/Consumer/Producer...) vorhanden ist wird mehr benötigt können über ein sep. Atribut (z.B. MaxInverter/MaxDevice) die benötigte Anzahl vom Nutzer 'hinzugefügt' werden - natürlich mit definierten Maximum. Wenn die Anzahl von setupBatteryDevxx,Consumerxx, setupInverterDevxx, setupOtherProducerXX über ein separates Attribut gesteuert werden könnte würde das aus meiner Sicht dazu führen, dass die meisten Anlagen mit sehr wenigen Attributen bzw. nur einem wie setupInverterDevxx oder setupBatteryDevxx .. auskommt aber auch komplexe Anlagen (4 und mehr Inverter, mehrere Batterien ..) gemanaged werden könnten.
Dann hätte ich noch eine dritte Idee das Attribut Consumerxx aufteilen: in Consumer zum manipulieren und Consumer zum beobachten die letzteren könnten sehr viel einfacher angelegt werden - würden eigentlich nur die beiden Readings Power und Energy benötigen und wären anzahlseitig nicht begrenzt - Die meisten 'beobachteten' Verbraucher können bzw. sollten nicht gesteuert werden z.B. Herd, Wasserkocher, Netzwerk, Kühlschrank ... sind aber für den Hauptteil (Ausnahme WP und E-Auto) des hausinternen Leistungsverbrauchs verantwortlich (der Kühlschrank [AAA+] braucht übers Jahr mehr Energie als die Waschmaschine [AAA] und von dem Netzwerkgetöns will ich gar nicht erst reden) - diese Geräte sind aus meiner Sicht datenseitig notwendig aber müssen nicht alle Schlüssel haben - könnten also einfacher beschrieben werden
Ich möchte das wirklich nur als Anregung verstanden haben - und bin mir nicht im klaren ob und wieviel Aufwand das bedeuten würde. Die derzeitigen Attribute sind gut erklärt und die 'Wechselwirkungen' zwischen diesen findet der interessierte Nutzer leicht heraus - vom supertollen und schnellen Support ganz abgesehen.
Gruß Gerd
Hallo Gerd,
ich freue mich über deinen Ideen und Hinweise. Es ist gut auch mal eine andere Perspektve einzunehmen.
ZitatctrlBatSocManagementxx integrieren in setupBatteryDevxx
Das ist eine gute Idee und rein technisch wäre das auch gut möglich umzusetzen. Aktuell scheue ich noch etwas davor zurück, weil die Erläuterungen zu den einzelnen Schlüsseln beider Attribute sehr raumgreifend sind und ich bei einer Zusammenlegung befürchte, dass die User die Übersicht verlieren könnten.
ZitatsetupStringPeak und setupInverterStrings könnten in setupInverterDevxx
Im Prinzip ja, erscheint mir allerdings programmtechnisch aktuell etwas aufwendig.
Allerdings, und das wäre wahrscheinlich gut machbar, könnte setupStringPeak in setupInverterStrings aufgehen. Kommt auf die Shortliste....
Die anderen Hinweise lasse ich mir nach und nach auch noch durch den Kopf gehen.
LG,
Heiko
Hallo Heiko,
bevor hier das "plantControl" eingeführt wurde, funktionierte die Einplanung wenn der AKKU-Zustand 60% Ladung erreicht hatte. Nach der Änderung scheinen die 60% ignoriert zu werden. Gibt es hier einen besonderen Trick, oder gibt es nach der Änderung zusätzliche Parameter, die erforderlich sind, dass diese explizit angeführt werden müssen?
Das ist das neue Attribut, welches doch die Einplanung ab 60% freigibt, wenn ich es richtig verstanden habe:
attr Forecast plantControl batteryPreferredCharge=60
Guten Morgen,
@heramol, das ist mein Fehler. Ich habe intern eine Umsetzung übersehen.
Den Fix checke ich ein. Du kannst die gefixten V ab sofort aus meinem contrib laden und verwenden.
Grüße,
Heiko
Hallo,
kann es sein das die Consumersteuerung nicht mehr richtig tut?
Habe heute auf die neueste Version von SF eingespielt. Ich meine aber das Problem war gestern schon vorhanden.
Seit dem wird mir mein Consumer immer wieder (bei aktiver Automatik) eingeschaltet und ich kann nicht erkennen warum
define 01_SolarForecast SolarForecast
attr 01_SolarForecast DbLogExclude .*
attr 01_SolarForecast DbLogInclude Today_PVdeviation,AllPVforecastsToEvent,LastHourPVforecast,LastHourPVreal
attr 01_SolarForecast affectConsForecastIdentWeekdays 1
attr 01_SolarForecast alias SolarForecast
attr 01_SolarForecast comment update per "wget -qO fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr 01_SolarForecast consumer01 z_wav_stecker_luftentfeuchter type=charger power=600 switchdev=struc_entfeuchter mode=can icon=Ventilator_fett mintime=SunPath:60:-90 on=on off=off swstate=state:on:off pcurr=power:W etotal=energy_sum:kWh auto=automatic locktime=600:2700 spignorecond=01_SolarForecast:nulleinspeisung:1 asynchron=1 interruptable=1
attr 01_SolarForecast consumerAdviceIcon light_light_dim_100@gold
attr 01_SolarForecast consumerLegend text_top
attr 01_SolarForecast consumerLink 1
attr 01_SolarForecast ctrlConsRecommendReadings 01
attr 01_SolarForecast ctrlGenPVdeviation continuously
attr 01_SolarForecast ctrlInterval 30
attr 01_SolarForecast ctrlLanguage DE
attr 01_SolarForecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,conForecastTillNextSunrise,currentRunMtsConsumer_01,dayAfterTomorrowPVforecast,runTimeAvgDayConsumer_01,todayBatInSum,todayBatIn_01,todayBatIn_02,todayBatOutSum,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumption,todayConsumptionForecast,todayConsumptionForecastDay,todayGridConsumption,todayGridFeedIn
attr 01_SolarForecast ctrlUserExitFn {\
if ((ReadingsNum("MQTT2_jk_bms_ble_multi","176ah_state_of_charge",0) > 80 && ReadingsNum("MQTT2_shelly1pm_solar2","relay_0_power",0) < 700 && ReadingsNum("z_wav_stecker_luftentfeuchter","automatic",0) == 1) ||\
(ReadingsNum("MQTT2_jk_bms_ble_multi","280ah_state_of_charge",0) > 80 && ReadingsNum("MQTT2_shelly1pm_solar2","relay_0_power",0) < 1300 && ReadingsNum("z_wav_stecker_luftentfeuchter","automatic",0) == 1 && ReadingsNum("$name","nulleinspeisung",0) == 1)) {\
fhem "setreading $name nulleinspeisung 1";;\
}\
else {\
fhem "setreading $name nulleinspeisung 0";;\
}\
}
attr 01_SolarForecast event-on-change-reading .*
attr 01_SolarForecast flowGraphicControl size=600 animate=1 showconsumer=1 showconsumerdummy=0 showconsumerpower=1 showconsumerremaintime=1
attr 01_SolarForecast graphicHeaderOwnspec #\
Strompreis ;aWATTar ;ct:arbeitspreis@aWATTar\
:\
:\
:\
#\
Heute ;PV:Today_PVreal\
Heute ;Forecast ;PV:Today_PVforecast\
:\
:\
#\
Heute ;Con:special_todayConsumption\
Heute ;Forecast ;Con:special_todayConsumptionForecastDay\
Morgen ;Con:Tomorrow_ConsumptionForecast\
:\
:\
#\
Consumer ;Neuplanung:consumerNewPlanning:::\
Consumer ;Sofortstart:consumerImmediatePlanning:::\
attr 01_SolarForecast graphicHistoryHour 4
attr 01_SolarForecast graphicLayoutType double
attr 01_SolarForecast graphicSelect both
attr 01_SolarForecast graphicShowDiff top
attr 01_SolarForecast graphicWeatherColor 000000
attr 01_SolarForecast group 00 Energiebilanz
attr 01_SolarForecast plantControl batteryPreferredCharge=80
attr 01_SolarForecast room Energie
attr 01_SolarForecast setupBatteryDev01 MQTT2_jk_bms_ble_multi pin=176ah_charging_power:W pout=176ah_discharging_power:W charge=176ah_state_of_charge show=1 cap=8448 asynchron=1 icon=measure_battery_50@grey:measure_battery_100@green:measure_battery_100@red
attr 01_SolarForecast setupBatteryDev02 MQTT2_jk_bms_ble_multi pin=280ah_charging_power:W pout=280ah_discharging_power:W charge=280ah_state_of_charge show=1 cap=13440 asynchron=1 icon=measure_battery_50@grey:measure_battery_100@green:measure_battery_100@red
attr 01_SolarForecast setupInverterDev01 MQTT2_EPEver2MQTT pv=EP_1_LiveData_BATT_W:W etotal=EP_1_StatsData_GEN_TOT:kWh strings=gross capacity=3500 asynchron=1
attr 01_SolarForecast setupInverterDev02 MQTT2_EPEver2MQTT pv=EP_2_LiveData_BATT_W:W etotal=EP_2_StatsData_GEN_TOT:kWh strings=klein capacity=2500 asynchron=1
attr 01_SolarForecast setupInverterStrings gross,klein
attr 01_SolarForecast setupMeterDev MQTT2_tzaehler gcon=sml_Leistung:W contotal=Bezug_total:kWh gfeedin=-gcon feedtotal=Einspeisung_total:kWh asynchron=1 conprice=Strom_Kosten:aWATTar_Arbeitspreis:ct feedprice=0.0:€
attr 01_SolarForecast setupRadiationAPI OpenMeteoDWDEnsemble-API
attr 01_SolarForecast setupStringPeak gross=3.5 klein=2.5
attr 01_SolarForecast setupWeatherDev1 OpenMeteoDWDEnsemble-API
attr 01_SolarForecast sortby 2
attr 01_SolarForecast stateFormat Current_PV
# FUUID 62f00e06-f33f-638b-d558-edce0156a0cf493f
# FVERSION 76_SolarForecast.pm:v1.49.1-s29788/2025-03-25
# LCACHEFILE last write time: 15:30:05 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 15:42:21
# MODEL OpenMeteoDWDEnsembleAPI
# NAME 01_SolarForecast
# NOTIFYDEV MQTT2_tzaehler,z_wav_stecker_luftentfeuchter,struc_entfeuchter,MQTT2_jk_bms_ble_multi,MQTT2_EPEver2MQTT
# NR 436
# NTFY_ORDER 50-01_SolarForecast
# STATE 218 W
# TYPE SolarForecast
# WEATHERMODEL OpenMeteoDWDEnsembleAPI
# eventCount 6120
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV 01_SolarForecast
# SPGROOM
# VERSION 1.49.1
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 62
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:1577036
# telnet telnetPort_127.0.0.1_42896
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name 01_SolarForecast
# tsnext 1743005584.94968
# Helper:
# DBLOG:
# LastHourPVforecast:
# logdb:
# TIME 1742997602.51505
# VALUE 1220
# logdb2:
# TIME 1742997602.51687
# VALUE 1220
# LastHourPVreal:
# logdb:
# TIME 1742997602.51505
# VALUE 500
# logdb2:
# TIME 1742997602.51687
# VALUE 500
# Today_PVdeviation:
# logdb:
# TIME 1743000123.92751
# VALUE 15.80
# logdb2:
# TIME 1743000123.92798
# VALUE 15.80
# OLDREADINGS:
# READINGS:
# 2025-03-26 15:42:13 Battery_ChargeRecommended_01 1
# 2025-03-26 15:42:13 Battery_ChargeRecommended_02 1
# 2025-03-26 15:42:13 Current_AutarkyRate 95 %
# 2025-03-26 15:42:13 Current_BatCharge_01 18 %
# 2025-03-26 15:42:13 Current_BatCharge_02 32 %
# 2025-03-26 15:42:13 Current_Consumption 1131 W
# 2025-03-26 15:42:13 Current_GridConsumption 57 W
# 2025-03-26 15:42:13 Current_GridFeedIn 0 W
# 2025-03-26 15:42:13 Current_PV 218 W
# 2025-03-26 15:42:13 Current_PowerBatIn_01 0 W
# 2025-03-26 15:42:13 Current_PowerBatIn_02 0 W
# 2025-03-26 15:42:13 Current_PowerBatOut_01 539 W
# 2025-03-26 15:42:13 Current_PowerBatOut_02 317 W
# 2025-03-26 15:42:13 Current_SelfConsumption 218 W
# 2025-03-26 15:42:13 Current_SelfConsumptionRate 100 %
# 2025-03-26 15:42:13 Current_Surplus 0 W
# 2025-03-26 15:00:00 LastHourGridconsumptionReal 442 Wh
# 2025-03-26 15:00:00 LastHourPVforecast 1220 Wh
# 2025-03-26 15:00:00 LastHourPVreal 500 Wh
# 2025-03-26 15:42:13 NextHours_Sum01_PVforecast 569 Wh
# 2025-03-26 15:42:13 NextHours_Sum02_PVforecast 804 Wh
# 2025-03-26 15:42:13 NextHours_Sum03_PVforecast 857 Wh
# 2025-03-26 15:42:13 NextHours_Sum04_ConsumptionForecast 1856 Wh
# 2025-03-26 15:42:13 NextHours_Sum04_PVforecast 867 Wh
# 2025-03-26 15:42:13 RestOfDayConsumptionForecast 3466 Wh
# 2025-03-26 15:42:13 RestOfDayPVforecast 867 Wh
# 2025-03-26 00:59:59 Today_Hour01_BatIn_01 0 Wh
# 2025-03-26 00:59:59 Today_Hour01_BatIn_02 0 Wh
# 2025-03-26 00:59:59 Today_Hour01_BatOut_01 0 Wh
# 2025-03-26 00:59:59 Today_Hour01_BatOut_02 0 Wh
# 2025-03-26 00:59:59 Today_Hour01_GridConsumption 79 Wh
# 2025-03-26 00:59:59 Today_Hour01_GridFeedIn 18 Wh
# 2025-03-26 00:59:59 Today_Hour01_PVreal 0 Wh
# 2025-03-26 01:59:58 Today_Hour02_BatIn_01 0 Wh
# 2025-03-26 01:59:58 Today_Hour02_BatIn_02 0 Wh
# 2025-03-26 01:59:58 Today_Hour02_BatOut_01 0 Wh
# 2025-03-26 01:59:58 Today_Hour02_BatOut_02 0 Wh
# 2025-03-26 01:59:58 Today_Hour02_GridConsumption 71 Wh
# 2025-03-26 01:59:58 Today_Hour02_GridFeedIn 16 Wh
# 2025-03-26 01:59:58 Today_Hour02_PVreal 0 Wh
# 2025-03-26 02:59:59 Today_Hour03_BatIn_01 0 Wh
# 2025-03-26 02:59:59 Today_Hour03_BatIn_02 0 Wh
# 2025-03-26 02:59:59 Today_Hour03_BatOut_01 0 Wh
# 2025-03-26 02:59:59 Today_Hour03_BatOut_02 0 Wh
# 2025-03-26 02:59:59 Today_Hour03_GridConsumption 65 Wh
# 2025-03-26 02:59:59 Today_Hour03_GridFeedIn 14 Wh
# 2025-03-26 02:59:59 Today_Hour03_PVreal 0 Wh
# 2025-03-26 03:59:58 Today_Hour04_BatIn_01 0 Wh
# 2025-03-26 03:59:58 Today_Hour04_BatIn_02 0 Wh
# 2025-03-26 03:59:58 Today_Hour04_BatOut_01 0 Wh
# 2025-03-26 03:59:58 Today_Hour04_BatOut_02 0 Wh
# 2025-03-26 03:59:58 Today_Hour04_GridConsumption 31 Wh
# 2025-03-26 03:59:58 Today_Hour04_GridFeedIn 3 Wh
# 2025-03-26 03:59:58 Today_Hour04_PVreal 0 Wh
# 2025-03-26 04:59:58 Today_Hour05_BatIn_01 0 Wh
# 2025-03-26 04:59:58 Today_Hour05_BatIn_02 0 Wh
# 2025-03-26 04:59:58 Today_Hour05_BatOut_01 0 Wh
# 2025-03-26 04:59:58 Today_Hour05_BatOut_02 0 Wh
# 2025-03-26 04:59:58 Today_Hour05_GridConsumption 31 Wh
# 2025-03-26 04:59:58 Today_Hour05_GridFeedIn 2 Wh
# 2025-03-26 04:59:58 Today_Hour05_PVreal 0 Wh
# 2025-03-26 05:59:59 Today_Hour06_BatIn_01 0 Wh
# 2025-03-26 05:59:59 Today_Hour06_BatIn_02 0 Wh
# 2025-03-26 05:59:59 Today_Hour06_BatOut_01 0 Wh
# 2025-03-26 05:59:59 Today_Hour06_BatOut_02 0 Wh
# 2025-03-26 05:59:59 Today_Hour06_GridConsumption 97 Wh
# 2025-03-26 05:59:59 Today_Hour06_GridFeedIn 24 Wh
# 2025-03-26 05:59:59 Today_Hour06_PVreal 0 Wh
# 2025-03-26 06:59:58 Today_Hour07_BatIn_01 0 Wh
# 2025-03-26 06:59:58 Today_Hour07_BatIn_02 0 Wh
# 2025-03-26 06:59:58 Today_Hour07_BatOut_01 0 Wh
# 2025-03-26 06:59:58 Today_Hour07_BatOut_02 0 Wh
# 2025-03-26 06:59:58 Today_Hour07_GridConsumption 450 Wh
# 2025-03-26 06:59:58 Today_Hour07_GridFeedIn 79 Wh
# 2025-03-26 06:59:58 Today_Hour07_PVforecast 32 Wh
# 2025-03-26 06:59:58 Today_Hour07_PVreal 40 Wh
# 2025-03-26 07:59:58 Today_Hour08_BatIn_01 0 Wh
# 2025-03-26 07:59:58 Today_Hour08_BatIn_02 0 Wh
# 2025-03-26 07:59:58 Today_Hour08_BatOut_01 0 Wh
# 2025-03-26 07:59:58 Today_Hour08_BatOut_02 0 Wh
# 2025-03-26 07:59:58 Today_Hour08_GridConsumption 431 Wh
# 2025-03-26 07:59:58 Today_Hour08_GridFeedIn 142 Wh
# 2025-03-26 07:59:58 Today_Hour08_PVforecast 195 Wh
# 2025-03-26 07:59:58 Today_Hour08_PVreal 160 Wh
# 2025-03-26 08:59:59 Today_Hour09_BatIn_01 0 Wh
# 2025-03-26 08:59:59 Today_Hour09_BatIn_02 0 Wh
# 2025-03-26 08:59:59 Today_Hour09_BatOut_01 0 Wh
# 2025-03-26 08:59:59 Today_Hour09_BatOut_02 0 Wh
# 2025-03-26 08:59:59 Today_Hour09_GridConsumption 343 Wh
# 2025-03-26 08:59:59 Today_Hour09_GridFeedIn 116 Wh
# 2025-03-26 08:59:59 Today_Hour09_PVforecast 264 Wh
# 2025-03-26 08:59:59 Today_Hour09_PVreal 290 Wh
# 2025-03-26 09:59:58 Today_Hour10_BatIn_01 0 Wh
# 2025-03-26 09:59:58 Today_Hour10_BatIn_02 0 Wh
# 2025-03-26 09:59:58 Today_Hour10_BatOut_01 0 Wh
# 2025-03-26 09:59:58 Today_Hour10_BatOut_02 0 Wh
# 2025-03-26 09:59:58 Today_Hour10_GridConsumption 256 Wh
# 2025-03-26 09:59:58 Today_Hour10_GridFeedIn 98 Wh
# 2025-03-26 09:59:58 Today_Hour10_PVforecast 180 Wh
# 2025-03-26 09:59:58 Today_Hour10_PVreal 270 Wh
# 2025-03-26 10:59:57 Today_Hour11_BatIn_01 0 Wh
# 2025-03-26 10:59:57 Today_Hour11_BatIn_02 0 Wh
# 2025-03-26 10:59:57 Today_Hour11_BatOut_01 0 Wh
# 2025-03-26 10:59:57 Today_Hour11_BatOut_02 0 Wh
# 2025-03-26 10:59:57 Today_Hour11_GridConsumption 160 Wh
# 2025-03-26 10:59:57 Today_Hour11_GridFeedIn 45 Wh
# 2025-03-26 10:59:57 Today_Hour11_PVforecast 351 Wh
# 2025-03-26 10:59:57 Today_Hour11_PVreal 160 Wh
# 2025-03-26 11:59:58 Today_Hour12_BatIn_01 0 Wh
# 2025-03-26 11:59:58 Today_Hour12_BatIn_02 0 Wh
# 2025-03-26 11:59:58 Today_Hour12_BatOut_01 0 Wh
# 2025-03-26 11:59:58 Today_Hour12_BatOut_02 0 Wh
# 2025-03-26 11:59:58 Today_Hour12_GridConsumption 186 Wh
# 2025-03-26 11:59:58 Today_Hour12_GridFeedIn 82 Wh
# 2025-03-26 11:59:58 Today_Hour12_PVforecast 497 Wh
# 2025-03-26 11:59:58 Today_Hour12_PVreal 410 Wh
# 2025-03-26 12:59:59 Today_Hour13_BatIn_01 0 Wh
# 2025-03-26 12:59:59 Today_Hour13_BatIn_02 0 Wh
# 2025-03-26 12:59:59 Today_Hour13_BatOut_01 0 Wh
# 2025-03-26 12:59:59 Today_Hour13_BatOut_02 0 Wh
# 2025-03-26 12:59:59 Today_Hour13_GridConsumption 181 Wh
# 2025-03-26 12:59:59 Today_Hour13_GridFeedIn 74 Wh
# 2025-03-26 12:59:59 Today_Hour13_PVforecast 598 Wh
# 2025-03-26 12:59:59 Today_Hour13_PVreal 870 Wh
# 2025-03-26 13:59:57 Today_Hour14_BatIn_01 0 Wh
# 2025-03-26 13:59:57 Today_Hour14_BatIn_02 0 Wh
# 2025-03-26 13:59:57 Today_Hour14_BatOut_01 0 Wh
# 2025-03-26 13:59:57 Today_Hour14_BatOut_02 0 Wh
# 2025-03-26 13:59:57 Today_Hour14_GridConsumption 162 Wh
# 2025-03-26 13:59:57 Today_Hour14_GridFeedIn 55 Wh
# 2025-03-26 13:59:57 Today_Hour14_PVforecast 1034 Wh
# 2025-03-26 13:59:57 Today_Hour14_PVreal 890 Wh
# 2025-03-26 14:59:59 Today_Hour15_BatIn_01 0 Wh
# 2025-03-26 14:59:59 Today_Hour15_BatIn_02 0 Wh
# 2025-03-26 14:59:59 Today_Hour15_BatOut_01 0 Wh
# 2025-03-26 14:59:59 Today_Hour15_BatOut_02 0 Wh
# 2025-03-26 14:59:59 Today_Hour15_GridConsumption 442 Wh
# 2025-03-26 14:59:59 Today_Hour15_GridFeedIn 146 Wh
# 2025-03-26 14:59:59 Today_Hour15_PVforecast 1220 Wh
# 2025-03-26 14:59:59 Today_Hour15_PVreal 500 Wh
# 2025-03-26 15:42:13 Today_Hour16_BatIn_01 0 Wh
# 2025-03-26 15:42:13 Today_Hour16_BatIn_02 0 Wh
# 2025-03-26 15:42:13 Today_Hour16_BatOut_01 0 Wh
# 2025-03-26 15:42:13 Today_Hour16_BatOut_02 0 Wh
# 2025-03-26 15:42:13 Today_Hour16_GridConsumption 283 Wh
# 2025-03-26 15:42:13 Today_Hour16_GridFeedIn 101 Wh
# 2025-03-26 15:42:13 Today_Hour16_PVforecast 496 Wh
# 2025-03-26 15:42:13 Today_Hour16_PVreal 390 Wh
# 2025-03-26 15:42:13 Today_Hour17_PVforecast 598 Wh
# 2025-03-26 15:42:13 Today_Hour18_PVforecast 92 Wh
# 2025-03-26 15:42:13 Today_Hour19_PVforecast 37 Wh
# 2025-03-26 15:42:13 Today_MaxPVforecast 1220 Wh
# 2025-03-26 15:42:13 Today_MaxPVforecastTime 2025-03-26 14:00:00
# 2025-03-26 15:42:13 Today_PVdeviation 15.80 %
# 2025-03-26 15:42:13 Today_PVforecast 5594 Wh
# 2025-03-26 15:42:13 Today_PVreal 3980 Wh
# 2025-03-26 15:42:13 Today_SunRise 05:55
# 2025-03-26 15:42:13 Today_SunSet 18:27
# 2025-03-26 15:42:13 Tomorrow_ConsumptionForecast 11913 Wh
# 2025-03-26 15:42:13 Tomorrow_PVforecast 30894 Wh
# 2025-03-26 15:42:13 Tomorrow_SunRise 05:52
# 2025-03-26 15:42:13 Tomorrow_SunSet 18:28
# 2025-03-26 15:42:13 consumer01 name='z_wav_stecker_luftentfeuchter' state='off' mode='can' planningstate='continued' info='von extern umgeschaltet'
# 2025-03-26 15:42:13 consumer01_ConsumptionRecommended 0
# 2025-03-26 15:42:13 consumer01_currentPower 0 W
# 2025-03-26 15:42:13 consumer01_planned_start 26.03.2025 07:37:52
# 2025-03-26 15:42:13 consumer01_planned_stop 26.03.2025 16:56:58
# 2025-03-26 15:41:52 nextCycletime 15:42:21
# 2025-03-26 15:34:05 nextRadiationAPICall nach 26.03.2025 15:49:05
# 2025-03-26 15:42:13 nulleinspeisung 0
# 2025-03-26 07:00:01 pvCorrectionFactor_07 2.25 (automatic - old factor: 1.50, Sun Alt range: 5, Cloud range: 100, Days in range: 2)
# 2025-03-26 08:00:01 pvCorrectionFactor_08 1.26 (automatic - old factor: 1.37, Sun Alt range: 15, Cloud range: 100, Days in range: 2)
# 2025-03-26 09:00:02 pvCorrectionFactor_09 1.12 (automatic - old factor: 1.12, Sun Alt range: 25, Cloud range: 100, Days in range: 2)
# 2025-03-26 10:00:02 pvCorrectionFactor_10 0.74 (automatic - old factor: 0.59, Sun Alt range: 30, Cloud range: 100, Days in range: 3)
# 2025-03-26 11:00:00 pvCorrectionFactor_11 0.86 (automatic - old factor: 0.97, Sun Alt range: 35, Cloud range: 100, Days in range: 2)
# 2025-03-26 12:00:00 pvCorrectionFactor_12 1.04 (automatic - old factor: 1.11, Sun Alt range: 40, Cloud range: 100, Days in range: 2)
# 2025-03-26 13:00:02 pvCorrectionFactor_13 1.10 (automatic - old factor: 0.96, Sun Alt range: 40, Cloud range: 100, Days in range: 2)
# 2025-03-26 14:00:01 pvCorrectionFactor_14 1.09 (automatic - old factor: 1.34, Sun Alt range: 40, Cloud range: 100, Days in range: 2)
# 2025-03-26 15:00:02 pvCorrectionFactor_15 0.94 (automatic - old factor: 1.55, Sun Alt range: 35, Cloud range: 100, Days in range: 2)
# 2025-03-26 15:42:13 pvCorrectionFactor_Auto on_complex_ai
# 2024-06-18 12:14:24 setupStringAzimuth gross=S klein=S
# 2024-06-18 12:14:24 setupStringDeclination gross=35 klein=15
# 2025-03-26 15:42:13 special_BatPowerIn_Sum 0 W
# 2025-03-26 15:42:13 special_BatPowerOut_Sum 856 W
# 2025-03-26 15:42:13 special_conForecastTillNextSunrise 4281 Wh
# 2025-03-26 15:42:13 special_currentRunMtsConsumer_01 13 min
# 2025-03-26 15:42:13 special_dayAfterTomorrowPVforecast 29038 Wh
# 2025-03-26 15:42:13 special_runTimeAvgDayConsumer_01 238.55 min
# 2025-03-26 15:42:13 special_todayBatInSum 0.0 Wh
# 2025-03-26 15:42:13 special_todayBatIn_01 0.0 Wh
# 2025-03-26 15:42:13 special_todayBatIn_02 0.0 Wh
# 2025-03-26 15:42:13 special_todayBatOutSum 0.0 Wh
# 2025-03-26 15:42:13 special_todayBatOut_01 0.0 Wh
# 2025-03-26 15:42:13 special_todayBatOut_02 0.0 Wh
# 2025-03-26 15:42:13 special_todayConForecastTillSunset 1092 Wh
# 2025-03-26 15:42:13 special_todayConsumption 6232 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecastDay 14367 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_01 34 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_02 33 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_03 52 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_04 32 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_05 32 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_06 114 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_07 334 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_08 523 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_09 1040 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_10 1020 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_11 1580 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_12 1780 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_13 1766 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_14 1289 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_15 920 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_16 490 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_17 538 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_18 267 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_19 287 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_20 873 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_21 485 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_22 334 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_23 272 Wh
# 2025-03-26 15:42:13 special_todayConsumptionForecast_24 272 Wh
# 2025-03-26 15:42:13 special_todayGridConsumption 3268 Wh
# 2025-03-26 15:42:13 special_todayGridFeedIn 1015.0 Wh
# 2025-03-26 15:42:14 state updated
#
setstate 01_SolarForecast 218 W
setstate 01_SolarForecast 2023-12-03 17:49:33 .01_SolarForecast_consumerImmediatePlanning
setstate 01_SolarForecast 2023-12-03 17:49:33 .01_SolarForecast_consumerNewPlanning
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_ctrlDebu
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_graphicHistoryHour 4
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_graphicShowNight
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_graphicShowWeather
setstate 01_SolarForecast 2025-03-26 13:35:03 .associatedWith MQTT2_tzaehler z_wav_stecker_luftentfeuchter struc_entfeuchter MQTT2_jk_bms_ble_multi MQTT2_EPEver2MQTT
setstate 01_SolarForecast 2025-03-26 15:42:13 .lastupdateForecastValues 1743000133
setstate 01_SolarForecast 2025-03-26 15:42:13 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate 01_SolarForecast 2025-03-26 01:00:02 .signaldone_01 done
setstate 01_SolarForecast 2025-03-26 02:00:01 .signaldone_02 done
setstate 01_SolarForecast 2025-03-26 03:00:01 .signaldone_03 done
setstate 01_SolarForecast 2025-03-26 04:00:01 .signaldone_04 done
setstate 01_SolarForecast 2025-03-26 05:00:00 .signaldone_05 done
setstate 01_SolarForecast 2025-03-26 06:00:02 .signaldone_06 done
setstate 01_SolarForecast 2025-03-26 07:00:01 .signaldone_07 done
setstate 01_SolarForecast 2025-03-26 08:00:01 .signaldone_08 done
setstate 01_SolarForecast 2025-03-26 09:00:02 .signaldone_09 done
setstate 01_SolarForecast 2025-03-26 10:00:02 .signaldone_10 done
setstate 01_SolarForecast 2025-03-26 11:00:00 .signaldone_11 done
setstate 01_SolarForecast 2025-03-26 12:00:00 .signaldone_12 done
setstate 01_SolarForecast 2025-03-26 13:00:02 .signaldone_13 done
setstate 01_SolarForecast 2025-03-26 14:00:01 .signaldone_14 done
setstate 01_SolarForecast 2025-03-26 15:00:02 .signaldone_15 done
setstate 01_SolarForecast 2025-03-26 00:00:00 .signaldone_24 done
setstate 01_SolarForecast 2025-03-26 15:42:13 Battery_ChargeRecommended_01 1
setstate 01_SolarForecast 2025-03-26 15:42:13 Battery_ChargeRecommended_02 1
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_AutarkyRate 95 %
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_BatCharge_01 18 %
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_BatCharge_02 32 %
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_Consumption 1131 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_GridConsumption 57 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_GridFeedIn 0 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_PV 218 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_PowerBatIn_01 0 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_PowerBatIn_02 0 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_PowerBatOut_01 539 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_PowerBatOut_02 317 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_SelfConsumption 218 W
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_SelfConsumptionRate 100 %
setstate 01_SolarForecast 2025-03-26 15:42:13 Current_Surplus 0 W
setstate 01_SolarForecast 2025-03-26 15:00:00 LastHourGridconsumptionReal 442 Wh
setstate 01_SolarForecast 2025-03-26 15:00:00 LastHourPVforecast 1220 Wh
setstate 01_SolarForecast 2025-03-26 15:00:00 LastHourPVreal 500 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 NextHours_Sum01_PVforecast 569 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 NextHours_Sum02_PVforecast 804 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 NextHours_Sum03_PVforecast 857 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 NextHours_Sum04_ConsumptionForecast 1856 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 NextHours_Sum04_PVforecast 867 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 RestOfDayConsumptionForecast 3466 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 RestOfDayPVforecast 867 Wh
setstate 01_SolarForecast 2025-03-26 00:59:59 Today_Hour01_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 00:59:59 Today_Hour01_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 00:59:59 Today_Hour01_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 00:59:59 Today_Hour01_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 00:59:59 Today_Hour01_GridConsumption 79 Wh
setstate 01_SolarForecast 2025-03-26 00:59:59 Today_Hour01_GridFeedIn 18 Wh
setstate 01_SolarForecast 2025-03-26 00:59:59 Today_Hour01_PVreal 0 Wh
setstate 01_SolarForecast 2025-03-26 01:59:58 Today_Hour02_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 01:59:58 Today_Hour02_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 01:59:58 Today_Hour02_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 01:59:58 Today_Hour02_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 01:59:58 Today_Hour02_GridConsumption 71 Wh
setstate 01_SolarForecast 2025-03-26 01:59:58 Today_Hour02_GridFeedIn 16 Wh
setstate 01_SolarForecast 2025-03-26 01:59:58 Today_Hour02_PVreal 0 Wh
setstate 01_SolarForecast 2025-03-26 02:59:59 Today_Hour03_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 02:59:59 Today_Hour03_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 02:59:59 Today_Hour03_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 02:59:59 Today_Hour03_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 02:59:59 Today_Hour03_GridConsumption 65 Wh
setstate 01_SolarForecast 2025-03-26 02:59:59 Today_Hour03_GridFeedIn 14 Wh
setstate 01_SolarForecast 2025-03-26 02:59:59 Today_Hour03_PVreal 0 Wh
setstate 01_SolarForecast 2025-03-26 03:59:58 Today_Hour04_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 03:59:58 Today_Hour04_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 03:59:58 Today_Hour04_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 03:59:58 Today_Hour04_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 03:59:58 Today_Hour04_GridConsumption 31 Wh
setstate 01_SolarForecast 2025-03-26 03:59:58 Today_Hour04_GridFeedIn 3 Wh
setstate 01_SolarForecast 2025-03-26 03:59:58 Today_Hour04_PVreal 0 Wh
setstate 01_SolarForecast 2025-03-26 04:59:58 Today_Hour05_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 04:59:58 Today_Hour05_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 04:59:58 Today_Hour05_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 04:59:58 Today_Hour05_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 04:59:58 Today_Hour05_GridConsumption 31 Wh
setstate 01_SolarForecast 2025-03-26 04:59:58 Today_Hour05_GridFeedIn 2 Wh
setstate 01_SolarForecast 2025-03-26 04:59:58 Today_Hour05_PVreal 0 Wh
setstate 01_SolarForecast 2025-03-26 05:59:59 Today_Hour06_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 05:59:59 Today_Hour06_GridConsumption 97 Wh
setstate 01_SolarForecast 2025-03-26 05:59:59 Today_Hour06_GridFeedIn 24 Wh
setstate 01_SolarForecast 2025-03-26 05:59:59 Today_Hour06_PVreal 0 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_GridConsumption 450 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_GridFeedIn 79 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_PVforecast 32 Wh
setstate 01_SolarForecast 2025-03-26 06:59:58 Today_Hour07_PVreal 40 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_GridConsumption 431 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_GridFeedIn 142 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_PVforecast 195 Wh
setstate 01_SolarForecast 2025-03-26 07:59:58 Today_Hour08_PVreal 160 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_GridConsumption 343 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_GridFeedIn 116 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_PVforecast 264 Wh
setstate 01_SolarForecast 2025-03-26 08:59:59 Today_Hour09_PVreal 290 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_GridConsumption 256 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_GridFeedIn 98 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_PVforecast 180 Wh
setstate 01_SolarForecast 2025-03-26 09:59:58 Today_Hour10_PVreal 270 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_GridConsumption 160 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_GridFeedIn 45 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_PVforecast 351 Wh
setstate 01_SolarForecast 2025-03-26 10:59:57 Today_Hour11_PVreal 160 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_GridConsumption 186 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_GridFeedIn 82 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_PVforecast 497 Wh
setstate 01_SolarForecast 2025-03-26 11:59:58 Today_Hour12_PVreal 410 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_GridConsumption 181 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_GridFeedIn 74 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_PVforecast 598 Wh
setstate 01_SolarForecast 2025-03-26 12:59:59 Today_Hour13_PVreal 870 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_GridConsumption 162 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_GridFeedIn 55 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_PVforecast 1034 Wh
setstate 01_SolarForecast 2025-03-26 13:59:57 Today_Hour14_PVreal 890 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_GridConsumption 442 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_GridFeedIn 146 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_PVforecast 1220 Wh
setstate 01_SolarForecast 2025-03-26 14:59:59 Today_Hour15_PVreal 500 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_GridConsumption 283 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_GridFeedIn 101 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_PVforecast 496 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour16_PVreal 390 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour17_PVforecast 598 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour18_PVforecast 92 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_Hour19_PVforecast 37 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_MaxPVforecast 1220 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_MaxPVforecastTime 2025-03-26 14:00:00
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_PVdeviation 15.80 %
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_PVforecast 5594 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_PVreal 3980 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_SunRise 05:55
setstate 01_SolarForecast 2025-03-26 15:42:13 Today_SunSet 18:27
setstate 01_SolarForecast 2025-03-26 15:42:13 Tomorrow_ConsumptionForecast 11913 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Tomorrow_PVforecast 30894 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 Tomorrow_SunRise 05:52
setstate 01_SolarForecast 2025-03-26 15:42:13 Tomorrow_SunSet 18:28
setstate 01_SolarForecast 2025-03-26 15:42:13 consumer01 name='z_wav_stecker_luftentfeuchter' state='off' mode='can' planningstate='continued' info='von extern umgeschaltet'
setstate 01_SolarForecast 2025-03-26 15:42:13 consumer01_ConsumptionRecommended 0
setstate 01_SolarForecast 2025-03-26 15:42:13 consumer01_currentPower 0 W
setstate 01_SolarForecast 2025-03-26 15:42:13 consumer01_planned_start 26.03.2025 07:37:52
setstate 01_SolarForecast 2025-03-26 15:42:13 consumer01_planned_stop 26.03.2025 16:56:58
setstate 01_SolarForecast 2025-03-26 15:41:52 nextCycletime 15:42:21
setstate 01_SolarForecast 2025-03-26 15:34:05 nextRadiationAPICall nach 26.03.2025 15:49:05
setstate 01_SolarForecast 2025-03-26 15:42:13 nulleinspeisung 0
setstate 01_SolarForecast 2025-03-26 07:00:01 pvCorrectionFactor_07 2.25 (automatic - old factor: 1.50, Sun Alt range: 5, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 08:00:01 pvCorrectionFactor_08 1.26 (automatic - old factor: 1.37, Sun Alt range: 15, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 09:00:02 pvCorrectionFactor_09 1.12 (automatic - old factor: 1.12, Sun Alt range: 25, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 10:00:02 pvCorrectionFactor_10 0.74 (automatic - old factor: 0.59, Sun Alt range: 30, Cloud range: 100, Days in range: 3)
setstate 01_SolarForecast 2025-03-26 11:00:00 pvCorrectionFactor_11 0.86 (automatic - old factor: 0.97, Sun Alt range: 35, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 12:00:00 pvCorrectionFactor_12 1.04 (automatic - old factor: 1.11, Sun Alt range: 40, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 13:00:02 pvCorrectionFactor_13 1.10 (automatic - old factor: 0.96, Sun Alt range: 40, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 14:00:01 pvCorrectionFactor_14 1.09 (automatic - old factor: 1.34, Sun Alt range: 40, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 15:00:02 pvCorrectionFactor_15 0.94 (automatic - old factor: 1.55, Sun Alt range: 35, Cloud range: 100, Days in range: 2)
setstate 01_SolarForecast 2025-03-26 15:42:13 pvCorrectionFactor_Auto on_complex_ai
setstate 01_SolarForecast 2024-06-18 12:14:24 setupStringAzimuth gross=S klein=S
setstate 01_SolarForecast 2024-06-18 12:14:24 setupStringDeclination gross=35 klein=15
setstate 01_SolarForecast 2025-03-26 15:42:13 special_BatPowerIn_Sum 0 W
setstate 01_SolarForecast 2025-03-26 15:42:13 special_BatPowerOut_Sum 856 W
setstate 01_SolarForecast 2025-03-26 15:42:13 special_conForecastTillNextSunrise 4281 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_currentRunMtsConsumer_01 13 min
setstate 01_SolarForecast 2025-03-26 15:42:13 special_dayAfterTomorrowPVforecast 29038 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_runTimeAvgDayConsumer_01 238.55 min
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayBatInSum 0.0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayBatIn_01 0.0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayBatIn_02 0.0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayBatOutSum 0.0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayBatOut_01 0.0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayBatOut_02 0.0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConForecastTillSunset 1092 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumption 6232 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecastDay 14367 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_01 34 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_02 33 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_03 52 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_04 32 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_05 32 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_06 114 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_07 334 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_08 523 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_09 1040 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_10 1020 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_11 1580 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_12 1780 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_13 1766 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_14 1289 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_15 920 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_16 490 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_17 538 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_18 267 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_19 287 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_20 873 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_21 485 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_22 334 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_23 272 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayConsumptionForecast_24 272 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayGridConsumption 3268 Wh
setstate 01_SolarForecast 2025-03-26 15:42:13 special_todayGridFeedIn 1015.0 Wh
setstate 01_SolarForecast 2025-03-26 15:42:14 state updated
Aus meiner sicht sollte das so nicht sein.
Ich habe jetzt (aus Verzweifelung) die Automatik deaktiviert.
Viele Grüße
Heiko
Hallo Heiko,
die Consumersteuerung hat keinerlei Update bekommen, tut also wie bisher.
Die Frage ist weshalb dein Consumer einschaltet?
Prinzipiell darf er immer wenn er eingeplant ist zwischen Sonnenauf- und Untergang und PV-Überschuß vorhanden ist oder die PV-Überschuß-Ignore-Bedingung (nulleinspeisung = 1) wahr ist:
attr 01_SolarForecast consumer01 z_wav_stecker_luftentfeuchter ... mintime=SunPath:60:-90 on=on ... spignorecond=01_SolarForecast:nulleinspeisung:1 ... interruptable=1
Das heißt im Prinzip, wenn PV Überschuß vorhanden ist wird er einschalten bzw. wenn kein PV-Überschuß vorhanden ist UND das Reading nulleinspeisung = 1 ist, wird er ebenfalls einschalten. Das Reading setzt du in einer eigenen Funktion und es lässt sich von extern nicht beurteilen ob die logisch richtig arbeitet.
Du kannst ctrlDebug=consumerSwitchingXX einschalten um herauszubekommen warum ein Consumer ein bzw. ausschaltet.
LG,
Heiko
Ja genau so sollte es sein. ABER die nulleinspeisung war heute niemals "1".
Weiterhin war die Batterie heute nicht über 80%.
attr 01_SolarForecast plantControl batteryPreferredCharge=80
Letzten Sommer hat es genau so getan.
Mir fällt dazu nichts mehr ein.
Werde weiter suchen und beobachten.
Heiko
Ja, wie gesagt ctrlDebug=consumerSwitchingXX setzen. Sonst ist eine Analyse von ferne wirklich schwierig.
Ein "get ... valCurrent" muß auch den Schlüssel zeigen:
batteryPreferredCharge => 80
Edit:
Und zeige mal bitte die Ausgabe von:
Zitatget ... valBattery
Zitat von: DS_Starter am 26 März 2025, 20:55:30Ein "get ... valCurrent" muß auch den Schlüssel zeigen:
batteryPreferredCharge => 80
Das wird richtig angezeigt. Sollte also tun.
Ich werde Debug aktivieren und beobachten. Im Moment ist die Batterie leer. Wird aber morgen wieder.
Danke für die Unterstützung
Ich habe einen Verdacht ... was ist mit get ... valBattery ?
01 => balias => MQTT2_jk_bms_ble_multi
basynchron => 1
bcharge => 16
bchargewh => 1351.68
bicon => measure_battery_50@grey:measure_battery_100@green:measure_battery_100@red
binstcap => 8448
bname => MQTT2_jk_bms_ble_multi
bposingraph => top
bpowerin => 0
bpowerout => 0
bshowingraph => 1
02 => balias => MQTT2_jk_bms_ble_multi
basynchron => 1
bcharge => 1
bchargewh => 134.4
bicon => measure_battery_50@grey:measure_battery_100@green:measure_battery_100@red
binstcap => 13440
bname => MQTT2_jk_bms_ble_multi
bposingraph => top
bpowerin => 0
bpowerout => 0
bshowingraph => 1
Ich glaube einen Fehler im Multibatterie Management bezüglich Auswertung für Consumerschaltung gefunden zu haben. Es wird noch die Batterie 01 ausgewertet und nicht der resultierende SoC aller installierten Batterien.
Wenn deine Bat 01 auf +80% kommt, werden deine Consumer freigeschaltet obwohl der resultierende SoC eventuell noch nicht >= 80 ist.
Das fixe ich gerade.
Okay. Hört sich gut an.
Aber auch Batterie 1 war heute nicht auf 80%. max war 40%
Bin dann für heute weg.
In meinem contrib liegt eine V mit dem Fix.
Bitte lade sie + FHEM restart. Dann sehen wir weiter.
LG
Wurde die Limitierung auf die WR-Max-Leistung in der Prognose schon umgesetzt?
Heute um 12:00 sollen wieder über 16kWh vom Dach kommen, obwohl mein WR auf 15kW limitiert ist.
(Nutze noch die 1.48.0...)
Hier pvCircular von der Stunde:
13 => pvapifc: 16586, pvaifc: -, pvfc: 16586, aihit: 0, pvrl: 9640
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
confc: 1375, gcon: 0, gfeedin: 8611, wcc: 95, rr1c: 0.00
temp: 14.00, wid: 2, wtxt: -
pprl01: -, pprl02: -, pprl03: -
pvcorrf: 5.100=0.76 5.15=0.96 5.20=1.16 5.25=1.19 5.30=0.96 5.35=0.96 5.40=0.96 5.45=1.15 5.50=0.92 5.55=0.66
5.60=1.00 5.65=1.15 5.70=1.17 5.75=0.63 5.80=1.27 5.85=1.53 5.90=1.48 5.95=1.27 10.100=0.76 10.15=0.96
10.20=1.16 10.25=1.19 10.30=0.96 10.35=0.96 10.40=0.96 10.45=1.15 10.50=0.92 10.55=0.66 10.60=1.00 10.65=1.15
10.70=1.17 10.75=0.63 10.80=1.27 10.85=1.53 10.90=1.48 10.95=1.27 15.100=0.76 15.15=0.96 15.20=1.16 15.25=1.19
15.30=0.96 15.35=0.96 15.40=0.96 15.45=1.15 15.50=0.92 15.55=0.66 15.60=1.00 15.65=1.15 15.70=1.17 15.75=0.63
15.80=1.27 15.85=1.53 15.90=1.48 15.95=1.27 20.00=1.05 20.05=0.99 20.10=0.79 20.100=0.60 20.15=0.96 20.20=1.16
20.25=1.07 20.30=1.07 20.35=0.96 20.40=1.06 20.45=1.15 20.50=0.92 20.55=0.78 20.60=1.00 20.65=0.41 20.70=1.06
20.75=0.72 20.80=1.06 20.85=1.03 20.90=0.73 20.95=0.91 25.00=1.00 25.05=1.05 25.100=0.85 25.10=1.01 25.15=0.96
25.20=1.06 25.25=0.99 25.30=0.96 25.35=0.96 25.40=0.96 25.45=1.15 25.50=0.92 25.55=0.66 25.60=1.00 25.65=1.15
25.70=1.17 25.75=1.79 25.80=1.49 25.85=1.00 25.90=0.73 25.95=0.63 30.00=0.99 30.10=1.06 30.100=0.79 30.15=0.96
30.20=1.16 30.25=1.19 30.30=1.00 30.35=0.96 30.40=1.14 30.45=1.15 30.50=0.92 30.55=0.78 30.60=1.07 30.65=1.15
30.70=0.92 30.75=0.75 30.80=1.27 30.85=1.53 30.90=1.48 30.95=1.04 35.00=0.95 35.05=0.97 35.100=0.92 35.10=0.95
35.15=0.96 35.20=1.10 35.25=1.19 35.30=0.83 35.35=1.10 35.40=1.04 35.45=0.96 35.50=0.90 35.55=0.95 35.60=0.88
35.65=1.14 35.70=1.25 35.75=0.74 35.80=1.43 35.85=1.07 35.90=1.33 35.95=1.22 40.00=1.00 40.100=1.55 40.15=0.96
40.20=1.09 40.25=1.08 40.30=0.96 40.35=1.00 40.40=1.07 40.45=1.15 40.50=0.98 40.55=0.72 40.60=1.00 40.65=1.02
40.70=1.08 40.75=0.90 40.80=0.93 40.85=0.81 40.90=1.48 40.95=0.81 45.00=1.01 45.100=1.09 45.15=0.96 45.20=1.16
45.25=1.07 45.30=0.96 45.35=0.94 45.40=0.96 45.45=1.06 45.50=0.94 45.55=0.66 45.60=0.84 45.65=1.34 45.70=1.21
45.75=0.63 45.80=1.27 45.85=1.40 45.90=1.22 45.95=1.44 50.00=0.98 50.100=1.01 50.20=0.96 50.30=0.99 50.45=1.01
50.60=0.99 50.75=0.98 50.95=0.97 55.00=1.00 55.05=1.04 55.10=0.98 55.100=1.10 55.35=1.21 55.45=1.00 55.60=1.01
55.65=1.08 55.70=1.14 55.85=0.96 55.95=1.02 60.00=1.00 60.05=1.00 60.100=1.01 60.20=0.97 60.35=0.93 60.40=1.06
60.45=1.03 60.50=1.06 60.55=1.03 60.60=1.04 60.65=1.16 60.70=0.87 60.75=0.96 60.85=1.00 60.90=0.93 60.95=0.89
65.00=0.96 65.100=1.02 65.10=1.06 65.20=1.04 65.35=0.99 65.40=1.14 65.55=1.01 65.60=1.02 65.70=0.99 65.75=0.96
65.80=0.90 65.85=0.99 65.95=1.07
simple=1.00
quality: 5.100=0.63 5.15=0.95 5.20=0.67 5.25=0.95 5.30=0.91 5.35=0.96 5.40=0.91 5.45=0.99 5.50=0.80 5.55=0.49
5.60=1.00 5.65=0.77 5.70=0.86 5.75=0.42 5.80=0.69 5.85=0.65 5.90=0.68 5.95=0.79 10.100=0.63 10.15=0.95
10.20=0.67 10.25=0.95 10.30=0.91 10.35=0.96 10.40=0.91 10.45=0.99 10.50=0.80 10.55=0.49 10.60=1.00 10.65=0.77
10.70=0.86 10.75=0.42 10.80=0.69 10.85=0.65 10.90=0.68 10.95=0.79 15.100=0.63 15.15=0.95 15.20=0.67 15.25=0.95
15.30=0.91 15.35=0.96 15.40=0.91 15.45=0.99 15.50=0.80 15.55=0.49 15.60=1.00 15.65=0.77 15.70=0.86 15.75=0.42
15.80=0.69 15.85=0.65 15.90=0.68 15.95=0.79 20.00=0.95 20.05=0.99 20.100=0.33 20.10=0.30 20.15=0.95 20.20=0.67
20.25=0.96 20.30=0.84 20.35=0.96 20.40=0.94 20.45=0.99 20.50=0.80 20.55=0.72 20.60=1.00 20.65=0.00 20.70=0.94
20.75=0.62 20.80=0.94 20.85=0.83 20.90=0.63 20.95=0.90 25.00=1.00 25.05=0.95 25.10=0.99 25.100=0.82 25.15=0.95
25.20=0.97 25.25=0.75 25.30=0.91 25.35=0.96 25.40=0.91 25.45=0.99 25.50=0.80 25.55=0.49 25.60=1.00 25.65=0.77
25.70=0.86 25.75=0.56 25.80=0.67 25.85=1.00 25.90=0.63 25.95=0.40 30.00=0.99 30.100=0.73 30.10=0.89 30.15=0.95
30.20=0.67 30.25=0.95 30.30=1.00 30.35=0.96 30.40=0.76 30.45=0.99 30.50=0.80 30.55=0.71 30.60=0.93 30.65=0.77
30.70=0.91 30.75=0.67 30.80=0.69 30.85=0.65 30.90=0.68 30.95=0.96 35.00=0.95 35.05=0.97 35.10=0.95 35.100=0.91
35.15=0.95 35.20=0.96 35.25=0.95 35.30=0.79 35.35=0.91 35.40=0.96 35.45=0.71 35.50=0.89 35.55=0.95 35.60=0.86
35.65=0.89 35.70=0.80 35.75=0.64 35.80=0.70 35.85=0.94 35.90=0.75 35.95=0.82 40.00=1.00 40.100=0.64 40.15=0.95
40.20=0.97 40.25=0.97 40.30=0.91 40.35=1.00 40.40=0.93 40.45=0.99 40.50=0.98 40.55=0.61 40.60=1.00 40.65=0.89
40.70=0.93 40.75=0.88 40.80=0.92 40.85=0.77 40.90=0.68 40.95=0.76 45.00=0.99 45.100=0.92 45.15=0.95 45.20=0.67
45.25=0.95 45.30=0.91 45.35=0.94 45.40=0.91 45.45=0.98 45.50=0.93 45.55=0.49 45.60=0.81 45.65=0.75 45.70=0.83
45.75=0.42 45.80=0.69 45.85=0.71 45.90=0.82 45.95=0.70 50.00=0.98 50.100=0.99 50.20=0.90 50.30=0.99 50.45=0.99
50.60=0.99 50.75=0.97 50.95=0.95 55.00=1.00 55.05=0.93 55.100=0.91 55.10=0.97 55.35=0.71 55.45=1.00 55.60=0.99
55.65=0.93 55.70=0.88 55.85=0.92 55.95=0.98 60.00=1.00 60.05=1.00 60.100=0.99 60.20=0.94 60.35=0.84 60.40=0.94
60.45=0.98 60.50=0.89 60.55=0.94 60.60=0.92 60.65=0.86 60.70=0.66 60.75=0.96 60.85=1.00 60.90=0.93 60.95=0.88
65.00=0.96 65.10=0.94 65.100=0.98 65.20=0.93 65.35=0.99 65.40=0.88 65.55=0.99 65.60=0.95 65.70=0.99 65.75=0.91
65.80=0.74 65.85=0.99 65.95=0.94
simple=1.00
pvrlsum: simple=2952430
pvfcsum: simple=2963044
dnumsum: simple=405
con_all => Mon @ 2265 2088 2361 2518 278 2225 2245
Thu @ 2319 2149 2623 1375 1234 1331 1264
Fri @ 2708 2714 2241 2447 486
Sat @ 3124 2400 2847 2640 1141 2712 935
Wed @ 2852 2321 2553 2855 1013 543 1982 1034
Tue @ 3085 2195 2268 1895 2211 223
Sun @ 2509 2941 2260 3421 260 789
pvrl_10 => 35 @ 8850
50 @ 6420
55 @ 4307
60 @ 8060
70 @ 6610
75 @ 2360
80 @ 5470
85 @ 2935
90 @ 3698
95 @ 5135
pvrl_15 => 35 @ 8850
50 @ 6420
55 @ 4307
60 @ 8060
70 @ 6610
75 @ 2360
80 @ 5470
85 @ 2935
90 @ 3698
95 @ 5135
pvrl_20 => 00 @ 5253
05 @ 4900
10 @ 2850
25 @ 5490
30 @ 6180
35 @ 8850
40 @ 5500
50 @ 6420
55 @ 4345
60 @ 8060
65 @ 1590
70 @ 5010
75 @ 2130
80 @ 4203
85 @ 2597
90 @ 3667 2900
95 @ 2560
100 @ 1637 820 769 839
pvrl_25 => 00 @ 5317 7599 7470 7890 8129
05 @ 6770
10 @ 6650 7900
20 @ 7270
25 @ 5820
35 @ 8850
50 @ 6420
55 @ 4307
60 @ 8060
70 @ 6610
75 @ 2360 6670 7430
80 @ 5470 6799
85 @ 2935 6219 6759 6410
90 @ 3698 6699
95 @ 5135 1519 2529
100 @ 3518 879 3590 2809
pvrl_30 => 00 @ 9400 9480 9300 9010
10 @ 8530
30 @ 9130
35 @ 8850
40 @ 9750
50 @ 6420
55 @ 4552
60 @ 8228
70 @ 6610 7660
75 @ 4380 5119
80 @ 5470
85 @ 2935
90 @ 3698
95 @ 4660
100 @ 3423 1940 1439 3100 5770 5970 2170 1230
pvrl_35 => 00 @ 10100 10010 10070 10020 9740
05 @ 10000
10 @ 9720
20 @ 9990
30 @ 8430
35 @ 9235
40 @ 9570 9350
45 @ 7640
50 @ 8297
55 @ 5894
60 @ 7210 6710
65 @ 8740
70 @ 6477
75 @ 3457
80 @ 6495
85 @ 3680
90 @ 4113
95 @ 4623
100 @ 3180 2520 2620 5110
pvrl_40 => 00 @ 11003 11930 11800
20 @ 11460
25 @ 11330
35 @ 8850 10990
40 @ 9980
50 @ 8393
55 @ 4735
60 @ 8800
65 @ 9180
70 @ 8040
75 @ 5692
80 @ 6005
85 @ 2935 11070
90 @ 3698
95 @ 5135 6180
100 @ 4634 8720 8990 2730 10890
pvrl_45 => 00 @ 10487
25 @ 11430
35 @ 10320 9640
45 @ 8430
50 @ 9280
55 @ 4307
60 @ 7305
65 @ 9735
70 @ 8845
75 @ 2360
80 @ 5470
85 @ 5393
90 @ 4053 8830
95 @ 6130
100 @ 2783 4940
pvrl_5 => 35 @ 8850
50 @ 6420
55 @ 4307
60 @ 8060
70 @ 6610
75 @ 2360
80 @ 5470
85 @ 2935
90 @ 3698
95 @ 5135
pvrl_50 => 00 @ 11328
20 @ 11770
30 @ 11303
45 @ 11840
60 @ 11193
75 @ 10510
95 @ 7370
100 @ 8654
pvrl_55 => 00 @ 12978
05 @ 12560
10 @ 11670
35 @ 10810
45 @ 11810
60 @ 11000
65 @ 12580
70 @ 11255
85 @ 7420
95 @ 10487
100 @ 8271
pvrl_60 => 00 @ 13300
05 @ 13213
20 @ 12070
35 @ 10370
40 @ 13285
45 @ 12877
50 @ 10740
55 @ 11020
60 @ 13590
65 @ 12005
70 @ 7320
75 @ 10930
85 @ 8700
90 @ 9690
95 @ 9180
100 @ 7401
pvrl_65 => 00 @ 12300
10 @ 13640
20 @ 13540
35 @ 12180
40 @ 12945
55 @ 12433
60 @ 13430
70 @ 11362
75 @ 10050
80 @ 8180
85 @ 10882
95 @ 9176
100 @ 9161
pvfc_10 => 35 @ 8481
50 @ 7675
55 @ 6516
60 @ 8045
70 @ 5660
75 @ 3720
80 @ 3766
85 @ 1914
90 @ 2503
95 @ 4042
pvfc_15 => 35 @ 8481
50 @ 7675
55 @ 6516
60 @ 8045
70 @ 5660
75 @ 3720
80 @ 3766
85 @ 1914
90 @ 2503
95 @ 4042
pvfc_20 => 00 @ 5008
05 @ 4944
10 @ 4840
25 @ 5698
30 @ 5184
35 @ 8481
40 @ 5187
50 @ 7675
55 @ 5542
60 @ 8045
65 @ 3881
70 @ 4728
75 @ 2939
80 @ 3968
85 @ 3028
90 @ 3265 5710
95 @ 2826
100 @ 1711 2438 729 1070
pvfc_25 => 00 @ 6667 5976 7619 8624 8167
05 @ 6421
10 @ 6240 8156
20 @ 7491
25 @ 7278
35 @ 8481
50 @ 7675
55 @ 6516
60 @ 8045
70 @ 5660
75 @ 3720 3680 6504
80 @ 3766 4486
85 @ 1914 9015 6330 6260
90 @ 2503 11707
95 @ 4042 4282 3366
100 @ 3670 1373 3786 5411
pvfc_30 => 00 @ 9868 9057 8986 10053
10 @ 7624
30 @ 9118
35 @ 8481
40 @ 7401
50 @ 7675
55 @ 5864
60 @ 7691
70 @ 5660 9872
75 @ 4126 8541
80 @ 3766
85 @ 1914
90 @ 2503
95 @ 4467
100 @ 3825 2953 1735 5211 4797 3724 2176 2078
pvfc_35 => 00 @ 10154 10122 10563 10862 10589
05 @ 10282
10 @ 10194
20 @ 9551
30 @ 10180
35 @ 8360
40 @ 10376 7787
45 @ 9855
50 @ 9182
55 @ 6178
60 @ 7328 8548
65 @ 7817
70 @ 5169
75 @ 4701
80 @ 4548
85 @ 3454
90 @ 3097
95 @ 3784
100 @ 3138 2727 3185 8476
pvfc_40 => 00 @ 10590 12457 11850
20 @ 11111
25 @ 11651
35 @ 8481 11434
40 @ 9325
50 @ 8528
55 @ 6593
60 @ 8812
65 @ 10177
70 @ 7457
75 @ 6350
80 @ 6472
85 @ 1914 15315
90 @ 2503
95 @ 4042 10000
100 @ 4186 11870 5617 4343 11921
pvfc_45 => 00 @ 10430
25 @ 12052
35 @ 10363 10842
45 @ 8632
50 @ 9905
55 @ 6516
60 @ 8695
65 @ 7263
70 @ 7329
75 @ 3720
80 @ 3766
85 @ 3855
90 @ 3333 7225
95 @ 4262
100 @ 1869 5203
pvfc_5 => 35 @ 8481
50 @ 7675
55 @ 6516
60 @ 8045
70 @ 5660
75 @ 3720
80 @ 3766
85 @ 1914
90 @ 2503
95 @ 4042
pvfc_50 => 00 @ 11553
20 @ 12992
30 @ 11435
45 @ 11740
60 @ 11349
75 @ 10864
95 @ 7771
100 @ 8588
pvfc_55 => 00 @ 12942
05 @ 11622
10 @ 12078
35 @ 7668
45 @ 11834
60 @ 10912
65 @ 11681
70 @ 9892
85 @ 8046
95 @ 10269
100 @ 7490
pvfc_60 => 00 @ 13284
05 @ 13213
20 @ 12774
35 @ 12022
40 @ 12496
45 @ 12558
50 @ 9574
55 @ 10384
60 @ 12436
65 @ 10352
70 @ 9828
75 @ 11382
85 @ 8688
90 @ 10372
95 @ 10266
100 @ 7351
pvfc_65 => 00 @ 12766
10 @ 12884
20 @ 12656
35 @ 12260
40 @ 11395
55 @ 12326
60 @ 12734
70 @ 11457
75 @ 10914
80 @ 10308
85 @ 10971
95 @ 8607
100 @ 9002
Das ist in der 1.49 umgesetzt:
https://forum.fhem.de/index.php?msg=1337341 (https://forum.fhem.de/index.php?msg=1337341)
Hallo zusammen, lieber Heiko,
erst einmal ein ganz grosses Danke für dein Modul. Es stellt bei mir überwiegend die Energieverteilung dar und "erläutert" wo ich gerade am meisten verbrauche, bzw produziere (nur ein kleines BKW).
Eine Idee für das Häuschenstyling hätte ich. Könnte man das Häuschen anhand der Autarky Prozentwerte farblich darstellen? Je autarker ("grüner") der Verbrauch ist mit der Farbe grün oder einer frei wählbaren Farbe und dann über HSV zu den nicht so autarken ("roten/dunkelorangen") Momente während des Sonnenlichtsammeln.
Lieben Gruß
Ingo
ZitatKönnte man das Häuschen anhand der Autarky Prozentwerte farblich darstellen?
Idee gefällt mir, malschauen.
Zitat... und dann über HSV zu den nicht so autarken ("roten/dunkelorangen") Momente während des Sonnenlichtsammeln.
Kannst du das nochmal verständlich schreiben? ;)
Hi zusammen,
gestern nach dem Update auf die neueste Version habe ich mal Verbose auf 3 eingestellt (vorger auf 0).
Da ist mir aufgefallen das alle 3 sec. folgende Warnung im Log auftaucht:
Sonnenhuegel - WARNING - 'Sungrow_SH8rt' - the total energy drawn from grid was reset and is registered with >0<.
Was kann/muss ich tun damit diese Meldung unterbleibt?
Meine Definition des Moduls habe ich mal angehängt.
define Sonnenhuegel SolarForecast
attr Sonnenhuegel affectConsForecastIdentWeekdays 0
attr Sonnenhuegel affectConsForecastLastDays 8
attr Sonnenhuegel alias Sonnenhuegel
attr Sonnenhuegel consumer01 Power_Meter_Warmwasser_Sw type=heater power=1946 mode=can on=on off=off swstate=state:on:off swoncond=Temp_Warmw:state:off swoffcond=Temp_Warmw:state:on icon=sani_heating@white\
attr Sonnenhuegel consumer02 MQTT2_Hzg_Eisenbahn Device=FB_Hzg_Eisenbahn type=heater power=2200 mode=can on="on" off="off" icon=sani_heating@white
attr Sonnenhuegel consumer03 FB_Hzg_Buero_Sw Device=FB+Heizung+Büro type=heater power=1230 mode=can on="on" off="off" icon=sani_heating@white
attr Sonnenhuegel consumer04 Wallbox_regeln Device=Wallbox type=charger power=5200 mode=can on="on" off="off" swstate=state:on:off icon=wallbox@yellow
attr Sonnenhuegel ctrlGenPVdeviation continuously
attr Sonnenhuegel ctrlSpecialReadings todayConsumptionForecastDay
attr Sonnenhuegel event-on-change-reading .*
attr Sonnenhuegel flowGraphicControl h2consumerdist=200
attr Sonnenhuegel graphicBeam1Color 2BFF1C
attr Sonnenhuegel graphicBeam2Color DCFF7D
attr Sonnenhuegel graphicBeam5Color FF3D44
attr Sonnenhuegel graphicBeam5Content consumptionForecast
attr Sonnenhuegel graphicBeam6Color 2BFF1C
attr Sonnenhuegel graphicBeam6Content consumption
attr Sonnenhuegel graphicEnergyUnit Wh
attr Sonnenhuegel graphicHeaderDetail all
attr Sonnenhuegel graphicHeaderShow 1
attr Sonnenhuegel graphicHistoryHour 4
attr Sonnenhuegel graphicHourStyle :00
attr Sonnenhuegel graphicSelect both
attr Sonnenhuegel graphicShowDiff bottom
attr Sonnenhuegel graphicShowNight 0
attr Sonnenhuegel plantControl batteryPreferredCharge=90
attr Sonnenhuegel room PV-Anlage
attr Sonnenhuegel setupBatteryDev01 Sungrow_SH8rt pout=Battery_power_discharge:W pin=Battery_power_charge:W intotal:Total_battery_charge_energy_from_PV:KWh outtotal:Total_battery_discharge_Energy:KWh cap=10200 charge=Battery_level show=1:top asynchron=1\
attr Sonnenhuegel setupInverterDev01 Sungrow_SH8rt pv=Total_DC_Power:W etotal=Total_PV_Generation:kWh feed=bat capacity=10500 asynchron=1
attr Sonnenhuegel setupInverterStrings Süddach
attr Sonnenhuegel setupMeterDev Sungrow_SH8rt gcon=-gfeedin contotal=Daily_Import_Energy:kWh gfeedin=Export_power:W feedtotal=Daily_Export_Energy:kWh asynchron=1
attr Sonnenhuegel setupRadiationAPI OpenMeteoDWD_D2-API
attr Sonnenhuegel setupStringPeak Süddach=8.5
attr Sonnenhuegel setupWeatherDev1 OpenMeteoDWD_D2-API
attr Sonnenhuegel verbose 1
# FUUID 67b34507-f33f-b751-a5a9-c65bef1601ddaec2
# FVERSION 76_SolarForecast.pm:v1.49.1-s29788/2025-03-25
# LCACHEFILE last write time: 18:06:59 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 18:18:25
# MODEL OpenMeteoDWDD2API
# NAME Sonnenhuegel
# NOTIFYDEV Sungrow_SH8rt,Power_Meter_Warmwasser_Sw,MQTT2_Hzg_Eisenbahn,FB_Hzg_Buero_Sw,Wallbox_regeln
# NR 342
# NTFY_ORDER 50-Sonnenhuegel
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL OpenMeteoDWDD2API
# eventCount 71839
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# SPGDETAIL
# SPGDEV Sonnenhuegel
# SPGROOM
# VERSION 1.49.1
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 17849
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:548347
# telnet telnetForBlockingFn_1742984382.93201_127.0.0.1_36180
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name Sonnenhuegel
# tsnext 1743103322.47742
# OLDREADINGS:
# READINGS:
# 2025-03-27 18:17:57 Battery_ChargeRecommended_01 1
# 2025-03-27 18:17:57 Current_AutarkyRate 97 %
# 2025-03-27 18:17:57 Current_BatCharge_01 97.8 %
# 2025-03-27 18:17:57 Current_Consumption 334 W
# 2025-03-27 18:17:57 Current_GridConsumption 11 W
# 2025-03-27 18:17:57 Current_GridFeedIn 0 W
# 2025-03-27 18:17:57 Current_PV 0 W
# 2025-03-27 18:17:57 Current_PowerBatIn_01 0 W
# 2025-03-27 18:17:57 Current_PowerBatOut_01 323 W
# 2025-03-27 18:17:57 Current_SelfConsumption 0 W
# 2025-03-27 18:17:57 Current_SelfConsumptionRate 0 %
# 2025-03-27 18:17:57 Current_Surplus 0 W
# 2025-03-27 18:00:00 LastHourGridconsumptionReal 0 Wh
# 2025-03-27 18:00:00 LastHourPVforecast 998 Wh
# 2025-03-27 18:00:00 LastHourPVreal 800 Wh
# 2025-03-27 18:17:57 NextHours_Sum01_PVforecast 116 Wh
# 2025-03-27 18:17:57 NextHours_Sum02_PVforecast 116 Wh
# 2025-03-27 18:17:57 NextHours_Sum03_PVforecast 116 Wh
# 2025-03-27 18:17:57 NextHours_Sum04_ConsumptionForecast 0 Wh
# 2025-03-27 18:17:57 NextHours_Sum04_PVforecast 116 Wh
# 2025-03-27 18:17:57 RestOfDayConsumptionForecast 0 Wh
# 2025-03-27 18:17:57 RestOfDayPVforecast 116 Wh
# 2025-03-27 00:59:58 Today_Hour01_BatIn_01 0 Wh
# 2025-03-27 00:59:58 Today_Hour01_BatOut_01 0 Wh
# 2025-03-27 00:59:58 Today_Hour01_PVreal 0 Wh
# 2025-03-27 02:00:00 Today_Hour02_BatIn_01 0 Wh
# 2025-03-27 02:00:00 Today_Hour02_BatOut_01 0 Wh
# 2025-03-27 02:00:00 Today_Hour02_PVreal 0 Wh
# 2025-03-27 02:59:59 Today_Hour03_BatIn_01 0 Wh
# 2025-03-27 02:59:59 Today_Hour03_BatOut_01 0 Wh
# 2025-03-27 02:59:59 Today_Hour03_PVreal 0 Wh
# 2025-03-27 03:59:57 Today_Hour04_BatIn_01 0 Wh
# 2025-03-27 03:59:57 Today_Hour04_BatOut_01 0 Wh
# 2025-03-27 03:59:57 Today_Hour04_PVreal 0 Wh
# 2025-03-27 04:59:59 Today_Hour05_BatIn_01 0 Wh
# 2025-03-27 04:59:59 Today_Hour05_BatOut_01 0 Wh
# 2025-03-27 04:59:59 Today_Hour05_PVreal 0 Wh
# 2025-03-27 05:59:52 Today_Hour06_BatIn_01 0 Wh
# 2025-03-27 05:59:52 Today_Hour06_BatOut_01 0 Wh
# 2025-03-27 05:59:52 Today_Hour06_PVreal 0 Wh
# 2025-03-27 06:59:57 Today_Hour07_BatIn_01 0 Wh
# 2025-03-27 06:59:57 Today_Hour07_BatOut_01 0 Wh
# 2025-03-27 06:59:57 Today_Hour07_PVforecast 180 Wh
# 2025-03-27 06:59:57 Today_Hour07_PVreal 0 Wh
# 2025-03-27 07:59:59 Today_Hour08_BatIn_01 0 Wh
# 2025-03-27 07:59:59 Today_Hour08_BatOut_01 0 Wh
# 2025-03-27 07:59:59 Today_Hour08_PVforecast 600 Wh
# 2025-03-27 07:59:59 Today_Hour08_PVreal 200 Wh
# 2025-03-27 08:59:57 Today_Hour09_BatIn_01 0 Wh
# 2025-03-27 08:59:57 Today_Hour09_BatOut_01 0 Wh
# 2025-03-27 08:59:57 Today_Hour09_PVforecast 2100 Wh
# 2025-03-27 08:59:57 Today_Hour09_PVreal 1200 Wh
# 2025-03-27 09:59:57 Today_Hour10_BatIn_01 0 Wh
# 2025-03-27 09:59:57 Today_Hour10_BatOut_01 0 Wh
# 2025-03-27 09:59:57 Today_Hour10_PVforecast 5220 Wh
# 2025-03-27 09:59:57 Today_Hour10_PVreal 2600 Wh
# 2025-03-27 10:59:58 Today_Hour11_BatIn_01 0 Wh
# 2025-03-27 10:59:58 Today_Hour11_BatOut_01 0 Wh
# 2025-03-27 10:59:58 Today_Hour11_GridFeedIn 100 Wh
# 2025-03-27 10:59:58 Today_Hour11_PVforecast 3600 Wh
# 2025-03-27 10:59:58 Today_Hour11_PVreal 7400 Wh
# 2025-03-27 11:59:58 Today_Hour12_BatIn_01 0 Wh
# 2025-03-27 11:59:58 Today_Hour12_BatOut_01 0 Wh
# 2025-03-27 11:59:58 Today_Hour12_GridFeedIn 200 Wh
# 2025-03-27 11:59:58 Today_Hour12_PVforecast 7100 Wh
# 2025-03-27 11:59:58 Today_Hour12_PVreal 7700 Wh
# 2025-03-27 12:59:58 Today_Hour13_BatIn_01 0 Wh
# 2025-03-27 12:59:58 Today_Hour13_BatOut_01 0 Wh
# 2025-03-27 12:59:58 Today_Hour13_GridFeedIn 100 Wh
# 2025-03-27 12:59:58 Today_Hour13_PVforecast 7200 Wh
# 2025-03-27 12:59:58 Today_Hour13_PVreal 7800 Wh
# 2025-03-27 13:59:57 Today_Hour14_BatIn_01 0 Wh
# 2025-03-27 13:59:57 Today_Hour14_BatOut_01 0 Wh
# 2025-03-27 13:59:57 Today_Hour14_GridFeedIn 1100 Wh
# 2025-03-27 13:59:57 Today_Hour14_PVforecast 4336 Wh
# 2025-03-27 13:59:57 Today_Hour14_PVreal 7300 Wh
# 2025-03-27 15:00:00 Today_Hour15_BatIn_01 0 Wh
# 2025-03-27 15:00:00 Today_Hour15_BatOut_01 0 Wh
# 2025-03-27 15:00:00 Today_Hour15_GridFeedIn 1500 Wh
# 2025-03-27 15:00:00 Today_Hour15_PVforecast 7050 Wh
# 2025-03-27 15:00:00 Today_Hour15_PVreal 6400 Wh
# 2025-03-27 15:59:57 Today_Hour16_BatIn_01 0 Wh
# 2025-03-27 15:59:57 Today_Hour16_BatOut_01 0 Wh
# 2025-03-27 15:59:57 Today_Hour16_GridFeedIn 2100 Wh
# 2025-03-27 15:59:57 Today_Hour16_PVforecast 4986 Wh
# 2025-03-27 15:59:57 Today_Hour16_PVreal 5000 Wh
# 2025-03-27 16:59:58 Today_Hour17_BatIn_01 0 Wh
# 2025-03-27 16:59:58 Today_Hour17_BatOut_01 0 Wh
# 2025-03-27 16:59:58 Today_Hour17_GridFeedIn 2800 Wh
# 2025-03-27 16:59:58 Today_Hour17_PVforecast 2700 Wh
# 2025-03-27 16:59:58 Today_Hour17_PVreal 3000 Wh
# 2025-03-27 17:59:57 Today_Hour18_BatIn_01 0 Wh
# 2025-03-27 17:59:57 Today_Hour18_BatOut_01 0 Wh
# 2025-03-27 17:59:57 Today_Hour18_GridFeedIn 500 Wh
# 2025-03-27 17:59:57 Today_Hour18_PVforecast 998 Wh
# 2025-03-27 17:59:57 Today_Hour18_PVreal 800 Wh
# 2025-03-27 18:17:57 Today_Hour19_BatIn_01 0 Wh
# 2025-03-27 18:17:57 Today_Hour19_BatOut_01 0 Wh
# 2025-03-27 18:17:57 Today_Hour19_GridFeedIn 0 Wh
# 2025-03-27 18:17:57 Today_Hour19_PVforecast 167 Wh
# 2025-03-27 18:17:57 Today_Hour19_PVreal 0 Wh
# 2025-03-27 18:17:57 Today_MaxPVforecast 7200 Wh
# 2025-03-27 18:17:57 Today_MaxPVforecastTime 2025-03-27 12:00:00
# 2025-03-27 18:17:57 Today_PVdeviation -7.11 %
# 2025-03-27 18:17:57 Today_PVforecast 46237 Wh
# 2025-03-27 18:17:57 Today_PVreal 49400 Wh
# 2025-03-27 18:17:57 Today_SunRise 06:10
# 2025-03-27 18:17:57 Today_SunSet 18:47
# 2025-03-27 18:17:57 Tomorrow_ConsumptionForecast 22400 Wh
# 2025-03-27 18:17:57 Tomorrow_PVforecast 58846 Wh
# 2025-03-27 18:17:57 Tomorrow_SunRise 06:08
# 2025-03-27 18:17:57 Tomorrow_SunSet 18:49
# 2025-03-27 18:17:57 consumer01 name='Warmwasser anheizen' state='off' mode='can' planningstate='finished'
# 2025-03-27 18:17:57 consumer01_planned_start 27.03.2025 11:37:43
# 2025-03-27 18:17:57 consumer01_planned_stop 27.03.2025 15:37:46
# 2025-03-27 18:17:57 consumer02 name='FB_Hzg_Eisenbahn' state='off' mode='can' planningstate='finished'
# 2025-03-27 18:17:57 consumer02_planned_start 27.03.2025 11:38:01
# 2025-03-27 18:17:57 consumer02_planned_stop 27.03.2025 15:38:04
# 2025-03-27 18:17:57 consumer03 name='FB Heizung Büro' state='off' mode='can' planningstate='finished'
# 2025-03-27 18:17:57 consumer03_planned_start 27.03.2025 11:37:40
# 2025-03-27 18:17:57 consumer03_planned_stop 27.03.2025 15:37:43
# 2025-03-27 18:17:57 consumer04 name='Wallbox' state='off' mode='can' planningstate='priority' info='von extern umgeschaltet'
# 2025-03-27 18:17:57 consumer04_planned_start 27.03.2025 09:00:00
# 2025-03-27 18:17:57 consumer04_planned_stop 27.03.2025 11:00:00
# 2025-03-27 18:17:15 nextCycletime 18:18:25
# 2025-03-27 18:17:25 nextRadiationAPICall nach 27.03.2025 18:32:25
# 2025-03-27 08:00:03 pvCorrectionFactor_08 0.55 (automatic - old factor: 0.92, AI result used, Sun Alt range: 10, Cloud range: 60, Days in range: 2)
# 2025-03-27 09:00:00 pvCorrectionFactor_09 0.53 (automatic - old factor: 1.00, AI result used, Sun Alt range: 20, Cloud range: 80, Days in range: 1)
# 2025-03-27 10:00:00 pvCorrectionFactor_10 0.66 (automatic - old factor: 1.00, AI result used, Sun Alt range: 30, Cloud range: 70, Days in range: 1)
# 2025-03-27 11:00:01 pvCorrectionFactor_11 1.25 (automatic - old factor: 1.00, AI result used, Sun Alt range: 35, Cloud range: 45, Days in range: 1)
# 2025-03-27 12:00:02 pvCorrectionFactor_12 1.09 (automatic - old factor: 1.00, AI result used, Sun Alt range: 40, Cloud range: 40, Days in range: 1)
# 2025-03-27 13:00:02 pvCorrectionFactor_13 0.97 (automatic - old factor: 0.98, AI result used, Sun Alt range: 40, Cloud range: 00, Days in range: 5)
# 2025-03-27 14:00:00 pvCorrectionFactor_14 1.03 (automatic - old factor: 0.59, Sun Alt range: 40, Cloud range: 00, Days in range: 2)
# 2025-03-27 15:00:03 pvCorrectionFactor_15 1.00 (automatic - old factor: 0.99, AI result used, Sun Alt range: 35, Cloud range: 00, Days in range: 2)
# 2025-03-27 16:00:01 pvCorrectionFactor_16 1.00 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 00, Days in range: 1)
# 2025-03-27 17:00:01 pvCorrectionFactor_17 0.97 (automatic - old factor: 0.96, AI result used, Sun Alt range: 20, Cloud range: 00, Days in range: 4)
# 2025-03-27 18:00:00 pvCorrectionFactor_18 0.70 (automatic - old factor: 0.73, Sun Alt range: 10, Cloud range: 00, Days in range: 5)
# 2025-03-27 18:17:57 pvCorrectionFactor_Auto on_complex_ai
# 2025-03-26 10:15:09 setupStringAzimuth Süddach=0
# 2025-03-26 10:15:52 setupStringDeclination Süddach=33
# 2025-03-27 18:17:57 special_todayConsumptionForecastDay 22900 Wh
# 2025-03-27 18:17:58 state updated
#
setstate Sonnenhuegel updated
setstate Sonnenhuegel 2025-03-26 11:19:43 .associatedWith Sungrow_SH8rt Power_Meter_Warmwasser_Sw MQTT2_Hzg_Eisenbahn FB_Hzg_Buero_Sw Wallbox_regeln
setstate Sonnenhuegel 2025-03-27 18:17:57 .lastupdateForecastValues 1743095877
setstate Sonnenhuegel 2025-03-27 18:17:57 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate Sonnenhuegel 2025-03-27 01:00:01 .signaldone_01 done
setstate Sonnenhuegel 2025-03-27 02:00:03 .signaldone_02 done
setstate Sonnenhuegel 2025-03-27 03:00:02 .signaldone_03 done
setstate Sonnenhuegel 2025-03-27 04:00:00 .signaldone_04 done
setstate Sonnenhuegel 2025-03-27 05:00:02 .signaldone_05 done
setstate Sonnenhuegel 2025-03-27 06:00:01 .signaldone_06 done
setstate Sonnenhuegel 2025-03-27 07:00:01 .signaldone_07 done
setstate Sonnenhuegel 2025-03-27 08:00:03 .signaldone_08 done
setstate Sonnenhuegel 2025-03-27 09:00:00 .signaldone_09 done
setstate Sonnenhuegel 2025-03-27 10:00:00 .signaldone_10 done
setstate Sonnenhuegel 2025-03-27 11:00:01 .signaldone_11 done
setstate Sonnenhuegel 2025-03-27 12:00:02 .signaldone_12 done
setstate Sonnenhuegel 2025-03-27 13:00:02 .signaldone_13 done
setstate Sonnenhuegel 2025-03-27 14:00:00 .signaldone_14 done
setstate Sonnenhuegel 2025-03-27 15:00:03 .signaldone_15 done
setstate Sonnenhuegel 2025-03-27 16:00:01 .signaldone_16 done
setstate Sonnenhuegel 2025-03-27 17:00:01 .signaldone_17 done
setstate Sonnenhuegel 2025-03-27 18:00:00 .signaldone_18 done
setstate Sonnenhuegel 2025-03-27 00:00:01 .signaldone_24 done
setstate Sonnenhuegel 2025-03-27 18:17:57 Battery_ChargeRecommended_01 1
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_AutarkyRate 97 %
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_BatCharge_01 97.8 %
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_Consumption 334 W
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_GridConsumption 11 W
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_GridFeedIn 0 W
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_PV 0 W
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_PowerBatIn_01 0 W
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_PowerBatOut_01 323 W
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_SelfConsumption 0 W
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_SelfConsumptionRate 0 %
setstate Sonnenhuegel 2025-03-27 18:17:57 Current_Surplus 0 W
setstate Sonnenhuegel 2025-03-27 18:00:00 LastHourGridconsumptionReal 0 Wh
setstate Sonnenhuegel 2025-03-27 18:00:00 LastHourPVforecast 998 Wh
setstate Sonnenhuegel 2025-03-27 18:00:00 LastHourPVreal 800 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 NextHours_Sum01_PVforecast 116 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 NextHours_Sum02_PVforecast 116 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 NextHours_Sum03_PVforecast 116 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 NextHours_Sum04_ConsumptionForecast 0 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 NextHours_Sum04_PVforecast 116 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 RestOfDayConsumptionForecast 0 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 RestOfDayPVforecast 116 Wh
setstate Sonnenhuegel 2025-03-27 00:59:58 Today_Hour01_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 00:59:58 Today_Hour01_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 00:59:58 Today_Hour01_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 02:00:00 Today_Hour02_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 02:00:00 Today_Hour02_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 02:00:00 Today_Hour02_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 02:59:59 Today_Hour03_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 02:59:59 Today_Hour03_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 02:59:59 Today_Hour03_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 03:59:57 Today_Hour04_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 03:59:57 Today_Hour04_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 03:59:57 Today_Hour04_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 04:59:59 Today_Hour05_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 04:59:59 Today_Hour05_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 04:59:59 Today_Hour05_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 05:59:52 Today_Hour06_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 05:59:52 Today_Hour06_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 05:59:52 Today_Hour06_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 06:59:57 Today_Hour07_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 06:59:57 Today_Hour07_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 06:59:57 Today_Hour07_PVforecast 180 Wh
setstate Sonnenhuegel 2025-03-27 06:59:57 Today_Hour07_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 07:59:59 Today_Hour08_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 07:59:59 Today_Hour08_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 07:59:59 Today_Hour08_PVforecast 600 Wh
setstate Sonnenhuegel 2025-03-27 07:59:59 Today_Hour08_PVreal 200 Wh
setstate Sonnenhuegel 2025-03-27 08:59:57 Today_Hour09_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 08:59:57 Today_Hour09_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 08:59:57 Today_Hour09_PVforecast 2100 Wh
setstate Sonnenhuegel 2025-03-27 08:59:57 Today_Hour09_PVreal 1200 Wh
setstate Sonnenhuegel 2025-03-27 09:59:57 Today_Hour10_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 09:59:57 Today_Hour10_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 09:59:57 Today_Hour10_PVforecast 5220 Wh
setstate Sonnenhuegel 2025-03-27 09:59:57 Today_Hour10_PVreal 2600 Wh
setstate Sonnenhuegel 2025-03-27 10:59:58 Today_Hour11_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 10:59:58 Today_Hour11_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 10:59:58 Today_Hour11_GridFeedIn 100 Wh
setstate Sonnenhuegel 2025-03-27 10:59:58 Today_Hour11_PVforecast 3600 Wh
setstate Sonnenhuegel 2025-03-27 10:59:58 Today_Hour11_PVreal 7400 Wh
setstate Sonnenhuegel 2025-03-27 11:59:58 Today_Hour12_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 11:59:58 Today_Hour12_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 11:59:58 Today_Hour12_GridFeedIn 200 Wh
setstate Sonnenhuegel 2025-03-27 11:59:58 Today_Hour12_PVforecast 7100 Wh
setstate Sonnenhuegel 2025-03-27 11:59:58 Today_Hour12_PVreal 7700 Wh
setstate Sonnenhuegel 2025-03-27 12:59:58 Today_Hour13_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 12:59:58 Today_Hour13_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 12:59:58 Today_Hour13_GridFeedIn 100 Wh
setstate Sonnenhuegel 2025-03-27 12:59:58 Today_Hour13_PVforecast 7200 Wh
setstate Sonnenhuegel 2025-03-27 12:59:58 Today_Hour13_PVreal 7800 Wh
setstate Sonnenhuegel 2025-03-27 13:59:57 Today_Hour14_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 13:59:57 Today_Hour14_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 13:59:57 Today_Hour14_GridFeedIn 1100 Wh
setstate Sonnenhuegel 2025-03-27 13:59:57 Today_Hour14_PVforecast 4336 Wh
setstate Sonnenhuegel 2025-03-27 13:59:57 Today_Hour14_PVreal 7300 Wh
setstate Sonnenhuegel 2025-03-27 15:00:00 Today_Hour15_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 15:00:00 Today_Hour15_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 15:00:00 Today_Hour15_GridFeedIn 1500 Wh
setstate Sonnenhuegel 2025-03-27 15:00:00 Today_Hour15_PVforecast 7050 Wh
setstate Sonnenhuegel 2025-03-27 15:00:00 Today_Hour15_PVreal 6400 Wh
setstate Sonnenhuegel 2025-03-27 15:59:57 Today_Hour16_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 15:59:57 Today_Hour16_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 15:59:57 Today_Hour16_GridFeedIn 2100 Wh
setstate Sonnenhuegel 2025-03-27 15:59:57 Today_Hour16_PVforecast 4986 Wh
setstate Sonnenhuegel 2025-03-27 15:59:57 Today_Hour16_PVreal 5000 Wh
setstate Sonnenhuegel 2025-03-27 16:59:58 Today_Hour17_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 16:59:58 Today_Hour17_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 16:59:58 Today_Hour17_GridFeedIn 2800 Wh
setstate Sonnenhuegel 2025-03-27 16:59:58 Today_Hour17_PVforecast 2700 Wh
setstate Sonnenhuegel 2025-03-27 16:59:58 Today_Hour17_PVreal 3000 Wh
setstate Sonnenhuegel 2025-03-27 17:59:57 Today_Hour18_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 17:59:57 Today_Hour18_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 17:59:57 Today_Hour18_GridFeedIn 500 Wh
setstate Sonnenhuegel 2025-03-27 17:59:57 Today_Hour18_PVforecast 998 Wh
setstate Sonnenhuegel 2025-03-27 17:59:57 Today_Hour18_PVreal 800 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_Hour19_BatIn_01 0 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_Hour19_BatOut_01 0 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_Hour19_GridFeedIn 0 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_Hour19_PVforecast 167 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_Hour19_PVreal 0 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_MaxPVforecast 7200 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_MaxPVforecastTime 2025-03-27 12:00:00
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_PVdeviation -7.11 %
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_PVforecast 46237 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_PVreal 49400 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_SunRise 06:10
setstate Sonnenhuegel 2025-03-27 18:17:57 Today_SunSet 18:47
setstate Sonnenhuegel 2025-03-27 18:17:57 Tomorrow_ConsumptionForecast 22400 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Tomorrow_PVforecast 58846 Wh
setstate Sonnenhuegel 2025-03-27 18:17:57 Tomorrow_SunRise 06:08
setstate Sonnenhuegel 2025-03-27 18:17:57 Tomorrow_SunSet 18:49
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer01 name='Warmwasser anheizen' state='off' mode='can' planningstate='finished'
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer01_planned_start 27.03.2025 11:37:43
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer01_planned_stop 27.03.2025 15:37:46
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer02 name='FB_Hzg_Eisenbahn' state='off' mode='can' planningstate='finished'
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer02_planned_start 27.03.2025 11:38:01
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer02_planned_stop 27.03.2025 15:38:04
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer03 name='FB Heizung Büro' state='off' mode='can' planningstate='finished'
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer03_planned_start 27.03.2025 11:37:40
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer03_planned_stop 27.03.2025 15:37:43
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer04 name='Wallbox' state='off' mode='can' planningstate='priority' info='von extern umgeschaltet'
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer04_planned_start 27.03.2025 09:00:00
setstate Sonnenhuegel 2025-03-27 18:17:57 consumer04_planned_stop 27.03.2025 11:00:00
setstate Sonnenhuegel 2025-03-27 18:17:15 nextCycletime 18:18:25
setstate Sonnenhuegel 2025-03-27 18:17:25 nextRadiationAPICall nach 27.03.2025 18:32:25
setstate Sonnenhuegel 2025-03-27 08:00:03 pvCorrectionFactor_08 0.55 (automatic - old factor: 0.92, AI result used, Sun Alt range: 10, Cloud range: 60, Days in range: 2)
setstate Sonnenhuegel 2025-03-27 09:00:00 pvCorrectionFactor_09 0.53 (automatic - old factor: 1.00, AI result used, Sun Alt range: 20, Cloud range: 80, Days in range: 1)
setstate Sonnenhuegel 2025-03-27 10:00:00 pvCorrectionFactor_10 0.66 (automatic - old factor: 1.00, AI result used, Sun Alt range: 30, Cloud range: 70, Days in range: 1)
setstate Sonnenhuegel 2025-03-27 11:00:01 pvCorrectionFactor_11 1.25 (automatic - old factor: 1.00, AI result used, Sun Alt range: 35, Cloud range: 45, Days in range: 1)
setstate Sonnenhuegel 2025-03-27 12:00:02 pvCorrectionFactor_12 1.09 (automatic - old factor: 1.00, AI result used, Sun Alt range: 40, Cloud range: 40, Days in range: 1)
setstate Sonnenhuegel 2025-03-27 13:00:02 pvCorrectionFactor_13 0.97 (automatic - old factor: 0.98, AI result used, Sun Alt range: 40, Cloud range: 00, Days in range: 5)
setstate Sonnenhuegel 2025-03-27 14:00:00 pvCorrectionFactor_14 1.03 (automatic - old factor: 0.59, Sun Alt range: 40, Cloud range: 00, Days in range: 2)
setstate Sonnenhuegel 2025-03-27 15:00:03 pvCorrectionFactor_15 1.00 (automatic - old factor: 0.99, AI result used, Sun Alt range: 35, Cloud range: 00, Days in range: 2)
setstate Sonnenhuegel 2025-03-27 16:00:01 pvCorrectionFactor_16 1.00 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 00, Days in range: 1)
setstate Sonnenhuegel 2025-03-27 17:00:01 pvCorrectionFactor_17 0.97 (automatic - old factor: 0.96, AI result used, Sun Alt range: 20, Cloud range: 00, Days in range: 4)
setstate Sonnenhuegel 2025-03-27 18:00:00 pvCorrectionFactor_18 0.70 (automatic - old factor: 0.73, Sun Alt range: 10, Cloud range: 00, Days in range: 5)
setstate Sonnenhuegel 2025-03-27 18:17:57 pvCorrectionFactor_Auto on_complex_ai
setstate Sonnenhuegel 2025-03-26 10:15:09 setupStringAzimuth Süddach=0
setstate Sonnenhuegel 2025-03-26 10:15:52 setupStringDeclination Süddach=33
setstate Sonnenhuegel 2025-03-27 18:17:57 special_todayConsumptionForecastDay 22900 Wh
setstate Sonnenhuegel 2025-03-27 18:17:58 state updated
Danke für dieses tolle Modul und eventuelle Hilfe.
Erhardt
Hallo Erhardt,
bei der Meldung geht es darum, dass das Reading im Schlüssel contotal (total energy drawn from grid), d.h. bei dir also Daily_Import_Energy, bei Auslesen keinen Wert bzw. den Wert "0" liefert.
attr Sonnenhuegel setupMeterDev Sungrow_SH8rt gcon=-gfeedin contotal=Daily_Import_Energy:kWh gfeedin=Export_power:W feedtotal=Daily_Export_Energy:kWh asynchron=1
Weil das Device Sungrow_SH8rt als asynchron definiert ist, liest das SF-Modul bei jedem Event von Sungrow_SH8rt die Readings aus, deswegen kommt die Meldung so häufig.
Stimmt der Readingname und hat dieses Reading einen Wert?
LG,
Heiko
Hallo Heiko,
ZitatStimmt der Readingname und hat dieses Reading einen Wert?
Natürlich nicht, :-[ der Wert bzw. das Reading war nicht mehr da!
Reading wieder hinzugefügt und... Warnung taucht nicht mehr auf. Frag mich nicht wo das Reading geblieben ist... sehr seltsam das.
Danke Erhardt
Na da musst du mal schauen ob dieses Reading auch seinen Zweck erfüllt.
Aber Problem identifiziert ... ist schonmal gut. :)
Ich habe eine neue Version eingecheckt.
Neben dem Bugfix bzgl. BatPrioCharge kann man mit flowGraphicControl -> homenodedyncol = 1 eine dynamische Einfärbung des Home-Knotens aktivieren. Die Färbung richtet sich nach der aktuellen Autarkierate.
Die zur Zeit dynamische Einfärbung der Laufketten Home-Knoten -> Consumer werde ich auch noch schaltbar gestalten. Wenn man alle Register zieht, könnte die Flußgrafik farblich etwas überladen sein. Deswegen soll der Anwender es selbst bestimmen können.
LG,
Heiko
Guten Morgen
Zitat... und dann über HSV zu den nicht so autarken ("roten/dunkelorangen") Momente während des Sonnenlichtsammeln.
Kannst du das nochmal verständlich schreiben? ;)
ich habe so an HUE HSV (https://de.wikipedia.org/wiki/HSV-Farbraum) gedacht. 100 Prozent Autark ist grün/hellgrün und je nach Prozentsatz wird es gegen 0 ziemlich Rot. ggf je nach Attribut zu einer anderen Farbe. Aber ein Farbverlauf von grün nach rot wäre sehr nice (Farbwerte von 105 zu 15). So hat man auf den ersten Blick ein CO2freundliches Gefühl ;-)
P.S: Habe gerade gesehen, das es schon eingepföegt wurde. Daher ein grosses Dankeschön!
Lieben Gruß
Ingo
Hallo Heiko,
nach den letzten Änderungen schaue ich mir gerade die Vorhersage wieder genauer an. Gestern hatte ich in der App auf dem Handy für heute mehr Sonnenstunden vorhergesagt als gestern, die Vorhersage der Erzeugung war aber deutlich schlechter. Da wollte ich mal anhand der Wettersymbole die einzelnen Stunden in der Grafik mit der App verglichen. Dabei ist mir was anderes aufgefallen. Beim Mouse-over werden "Höhe" und "Azimut" angezeigt. Für Stunde 12 bekam ich gestern für den aktuellen Tag Höhe = 43 und für heute 32. Wenn ich heute schaue, ist es für Stunde 12 dann auf einmal 43 und für morgen nur 22. Das ist hoffentlich nur ein Anzeigefehler. Oder interpretiere ich "Höhe" hier falsch.
Viele Grüße
Thomas
Hallo Thomas,
danke für den Hinweis. Das ist definitiv kein Anzeigeproblem sondern ein Fehler der sich an irgendeiner Stelle aus der Ermittlung aus Astro ergibt. Das muss ich mir anschauen, auf den ersten Blick konnte ich nichts finden. Da muss ich intensiver forschen.
Muß ich aber definitiv beseitigen.
In den Aufzeichnungen der aiRawData steht sunalt richtig drin, sodass die Lernergebnisse der KI nicht negativ beeinflusst sind, aber hätte sicherlich Auswirkungen auf eine KI-Prognose für den Folgetag.
Ich melde ich.
Grüße,
Heiko
Ich konnte das Problem identifizieren und lösen.
In meinem contrib liegt die gefixte V 1.49.4. Du/ihr könnt sie gern downloaden, restarten und testen.
Die KI-Vorhersage für den kommenden Tag wird korrigiert.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 28 März 2025, 11:54:41Du/ihr könnt sie gern downloaden, restarten und testen.
bei mir hat es geholfen.
Auch generell muss ich mal ein Lob loswerden, was die Prognose betrifft. Gestern war das Prognose-Ergebnis bei 0,7%. Spitze!
Danke und Grüße,
Peter
Bei der Vorhersage für morgen sieht man wegen des Wetters nicht so viel. Aber die Werte für "Höhe" sind jetzt plausibel. Und mir ist noch eingefallen, dass schon mal jemand geschrieben hatte, dass die Vorhersage für den nächsten Tag selbst spät abends immer niedriger ist als am nächsten Tag morgens dann.
ZitatUnd mir ist noch eingefallen, dass schon mal jemand geschrieben hatte, dass die Vorhersage für den nächsten Tag selbst spät abends immer niedriger ist als am nächsten Tag morgens dann.
Ja, das kann sein. Die Prognose ist halt dynamisch und ändert sich alle Nasen lang. Da fällt so ein Problem nicht so schnell auf. Deswegen nochmal danke für den Hinweis, hast du gut gemerkt. :)
Hallo zusammen,
ich habe die V 1.49.4 eingechceckt. Sie ist morgen früh im Update mit folgendem Inhalt:
- bugfix Ermittlung Sun Altitude für den kommenden Tag
- in der Flowgrafik zeigt ein Mouse-Over über dem Hausknoten die aktuelle Autarkierate
- im Attr flowGraphicControl gibt es den neuen Key 'strokeconsumerdyncol' um die Linien Haus->Consumer dynamisch einfärben zu können (war bis jetzt der default und muß nun wenn gewünscht mit strokeconsumerdyncol=1 aktiviert werden!) Es passt damit zum Verhalten von 'homenodedyncol'.
LG,
Heiko
Nabend zusammen,
ich habe noch weiter gearbeitet und die V 1.49.5 im contrib und kurzfristig im Update enthalten.
Was ist umgsetzt:
- die Attribute affectSolCastPercentile, ctrlSolCastAPIoptimizeReq sind obsolete und der Standard wird verwendet
- das Attr affectConsForecastIdentWeekdays wird ersetzt durch plantControl->consForecastIdentWeekdays
- das Attr affectConsForecastLastDays wird ersetzt durch plantControl->consForecastLastDays
- das Attr ctrlGenPVdeviation wird ersetzt durch plantControl->genPVdeviation
- das Attr ctrlInterval wird ersetzt durch plantControl->cycleInterval
- im Attr setupBattery gibt es die Schlüssel pinmax und poutmax. Hier kann man die maximale Lade/Entladeleistung der Batterie angeben. Dieser Wert wird im Batteriemanagement genutzt um den zukünftigen SoC besser schätzen zu können. Diese fehlende Möglichkeit wurde schon öfter angemerkt und ist jetzt eingebaut.
Nach Download des Moduls aus dem contrib bitte FHEM restarten. Die Attribute werden dabei automatisch umgesetzt.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 29 März 2025, 23:21:43im Attr setupBattery gibt es die Schlüssel pinmax und poutmax. Hier kann man die maximale Lade/Entladeleistung der Batterie angeben. Dieser Wert wird im Batteriemanagement genutzt um den zukünftigen SoC besser schätzen zu können. Diese fehlende Möglichkeit wurde schon öfter angemerkt und ist jetzt eingebaut.
Ich habe das Modul geladen und werde insbesondere dieses neue Feature testen. Leider wird heute ein Regentag, daher gibt es Testergebnisse frühestens morgen.
Vielen Dank und viele Grüße,
Peter
Morgen Peter,
ja, hier ist es ähnlich. Wobei ich das Feature bei mir real nicht testen kann weil die Batterie maximal 14400 W leistet. Das erreiche ich bei mir nie integriert auf 14,4 kWh für eine Stunde Dauerleistung.
Deswegen liegt die V vorerst im contrib und wir warten mal ab. :)
Schönen Sonntag,
Heiko
Hallo Heiko,
wie versprochen, habe ich heute mal die SoC-Prognose getestet.
Ohne pinmax und poutmax funktioniert es aus meiner Sicht wie bisher. Mit den beiden Werten auf 250 bzw (realistisch) 2500 funktioniert es auch so, wie ich es mir vorstellen würde.
Die attr wurden automatisiert umgestellt, wie immer.
Auch sonst ist mir an dieser Vorab-Version nichts negativ aufgefallen.
Tolle Arbeit! Kann aus meiner Sicht so eingecheckt werden.
Gruß,
Peter
Hallo Heiko,
ja das gleiche bei mir - hab die Version V 1.49.5 auch mal gestern zum Test geladen und min/max gesetzt.
Es sieht ebenfalls alles okay bei mir aus.
Gruß
300P
Hallo ihr zwei,
vielen Dank für die positive Rückmeldung.
Heute Abend will ich noch zwei Attribute in die plantControl einbringen:
ctrlGenPVdeviation -> in Key genPVdeviation
ctrlInterval -> in Key cycleInterval
Dann vereinigt plantControl alle übergreifenden Einstellungen soweit ich sehen kann.
Den Stand würde ich einchecken, vllt. schon heute Abend.
Mal schauen, ich gebe Bescheid.
LG,
Heiko
Hallo zusammen,
die Attribute ctrlGenPVdeviation und ctrlInterval sind auch noch umgesetzt und die Version 1.49.5 ist eingecheckt.
Liegt auch im contrib.
LG,
Heiko
Hallo Zusammen,
gibt es noch eine weitere Möglichkeit herauszufinden warum das KI Learning bei SolCast-API mit OpenMeteoDWD-API nicht funktioniert?
Common Settings
- AI support for the PV forecast is not used.
- erfüllt
pvCorrectionFactor_08
0.76 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 60, Days in range: 1) 2025-03-31 08:00:04
pvCorrectionFactor_09
0.48 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 95, Days in range: 1) 2025-03-31 09:00:04
pvCorrectionFactor_10
0.95 (automatic - old factor: 0.35, Sun Alt range: 20, Cloud range: 90, Days in range: 2) 2025-03-31 10:00:04
pvCorrectionFactor_11
0.84 (automatic - old factor: 0.65, Sun Alt range: 30, Cloud range: 95, Days in range: 2) 2025-03-31 11:00:04
pvCorrectionFactor_12
0.89 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 90, Days in range: 1) 2025-03-31 12:00:04
pvCorrectionFactor_13
0.70 (automatic - old factor: 1.00, Sun Alt range: 40, Cloud range: 75, Days in range: 1) 2025-03-31 13:00:01
pvCorrectionFactor_14
0.70 (automatic - old factor: 1.00, Sun Alt range: 40, Cloud range: 70, Days in range: 1) 2025-03-31 14:00:04
pvCorrectionFactor_15
0.90 (automatic - old factor: 1.00, Sun Alt range: 40, Cloud range: 65, Days in range: 1) 2025-03-31 15:00:04
pvCorrectionFactor_16
0.86 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 60, Days in range: 1) 2025-03-31 16:00:04
pvCorrectionFactor_17
0.67 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 65, Days in range: 1) 2025-03-31 17:00:04
pvCorrectionFactor_18
0.70 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 55, Days in range: 1) 2025-03-31 18:00:04
pvCorrectionFactor_19
0.61 (automatic - old factor: 1.00, Sun Alt range: 15, Cloud range: 75, Days in range: 1) 2025-03-31 19:00:04
pvCorrectionFactor_20
0.71 (automatic - old factor: 1.00, Sun Alt range: 5, Cloud range: 40, Days in range: 1) 2025-03-31 20:00:04
pvCorrectionFactor_Auto
on_complex
Gruß Michael
Hallo Michael,
du musst die KI aktivieren mit:
set <name> pvCorrectionFactor_Auto on_complex_ai
Im Anlagencheck gibt es dazu den entsprechenden Hinweis:
Set pvCorrectionFactor_Auto to '_ai' for switch on AI support.
LG,
Heiko
Hallo Heiko,
heute zerstört mir die KI mal wieder die Prognose. Siehe den direkten Vergleich hier:
on_complex.png
Anbei ein paar Debug-Ausgaben. Kannst Du daran eine Ursache erkennen und ggf. eine Aktion zur Korrektur empfehlen?
Danke und Grüße,
Peter
Moin Peter,
da ist nichts zerstört. Das sind die Ergebnisse, welche der KI Algo aus den bisherigen Lern-Erfahrungen für die durch die API gelieferten Wetter/Strahlungsdaten ermittelt. Es kommt darauf an wieviele Lerndatensätze die KI schon hat, die sie für die Prognosedaten anwenden kann.
Wenn man den Eindruck hat, die KI hat noch nicht genügend Lerndatensätze, kann man durchaus erstmal ohne KI arbeiten. Daran ist nichts verwerfliches.
Die Frage ist natürlich auch, welche der beiden Prognosen tatsächlich am Ende des heutigen Tages der Realität am Nächsten kommt. ;)
Kannst ja zwei Screenshoots machen und heute Abend mit dem Ergebnis vergleichen.
LG,
Heiko
Zitat von: DS_Starter am 31 März 2025, 22:44:25Hallo Michael,
du musst die KI aktivieren mit:
set <name> pvCorrectionFactor_Auto on_complex_ai
Im Anlagencheck gibt es dazu den entsprechenden Hinweis:
Set pvCorrectionFactor_Auto to '_ai' for switch on AI support.
LG,
Heiko
Hallo Heiko,
da muss ich nachfragen. Michael (ahlermi) hatte nach der SolCast-API gefragt.
Ich habe das SolCast-API auch aktiv und für das Model SolCastAPI
meldet der Check "Unfortunately, AI support is not possible with the selected radiation API MODEL.."
Was ist jetzt richtig?
Spielt das ausgewählte WEATHERMODEL da auch einer Rolle?
Danke und Gruß,
Guido.
Zitat von: DS_Starter am 31 März 2025, 22:44:25Hallo Michael,
du musst die KI aktivieren mit:
set <name> pvCorrectionFactor_Auto on_complex_ai
Danke Heiko!, on_complex_ai gibt es gar nicht zur Auswahl, ich setze es per Befehl
Zitatda muss ich nachfragen. Michael (ahlermi) hatte nach der SolCast-API gefragt.
Ich habe das SolCast-API auch aktiv und für das Model SolCastAPI
meldet der Check "Unfortunately, AI support is not possible with the selected radiation API MODEL.."
Was ist jetzt richtig?
Ach sorry, das habe ich überlesen.
Bei der SolCast-API kann KI nicht verwendet werden, weil diese API keine Strahlungsdaten liefert.
Die gewählte Wetter-API spielt da nicht hinein. Ich hatte nur "OpenMeteoDWD" gelesen. :-[
Also definitiv bei SolCast-API -> kein KI Support möglich.
@ahlermi, damit ist deine letzte Frage auch geklärt denke ich.
LG,
Heiko
Hallo,
ich wollte gerade jetzt dann auch mal mit der KI testen. Dabei musste ich feststellen das mir die _ai
Sachen nicht angezeigt/angeboten werden im set-Befehl.
Daraufhin haben ich, seit langem, die "Zahnräder" betätigt und musste anliegende Auswertung zur Kenntnis nehmen. Ich hatte die _ai schon mal vor länger Zeit am laufen.
Auf meinem Linux-System brachte eine "apt-get install libai-decisiontree-perl"
root@urmel:/opt/fhem# apt-get install libai-decisiontree-perl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libai-decisiontree-perl is already the newest version (0.11-2+b1).
0 upgraded, 0 newly installed, 0 to remove and 40 not upgraded.
root@urmel:/opt/fhem#
Also sollte eigentlich alles gut sein oder ? Warum tut es dann nicht ?
Als Wetter-API habe ich OpenMeteoDWDEnsemble-API
VG
Heiko
Hallo Heiko,
die Wetter-API ist nicht ausschlaggbend, sondern die setupRadiationAPI, d.h. der Strahlungslieferant.
Manche API's (SolCast, Victron) liefern keine Strahlungswerte. Deshalb kann dort keine KI aktiviert werden.
Das steht auch in dem Anlagencheck. Leider zeigt dein Screenshot nicht die relevanten oberen Zeilen.
LG,
Heiko
setupRadiationAPI steht auch auf OpenMeteoDWDEnsemble-API
Leider
Vllt. solltest du es mit CPAN versuchen:
cpan install AI::DecisionTree
Möglicherweise erkennt dein Perl, warum auch immer, das installierte Perl-Modul nicht.
Das wars. Komische Sache
Danke für die Hilfe.
Heiko
Hallo Heiko,
Du hattest absolut Recht!
Zitat von: DS_Starter am 01 April 2025, 09:29:13da ist nichts zerstört. Das sind die Ergebnisse, welche der KI Algo aus den bisherigen Lern-Erfahrungen für die durch die API gelieferten Wetter/Strahlungsdaten ermittelt.
Ich habe die real erzeugten Werte mal beiden Screenshots gegenüber gestellt:
Diagramm.png
Tabelle.png
In beiden Methoden war die Gesamtabweichung über den Tag unter 10 Prozent, mit KI sogar nur knapp 3 Prozent (!!!).
Ich war zu skeptisch gegenüber der Prognose.
Viele Grüße,
Peter
Moin Peter,
:-) , das hast du schön aufbereitet.
Jetzt sind wir im April. Es werden uns tendenziell unbeständige Wetterverhältnissse erwarten welche die Anlage/Prognose vor Herausforderungen stellen wird. Jeder Lauftag der Anlage/des Moduls sammelt Werte aus den Wetterverhältnissen, Strahlungswerten, Prognosen und realen Erzeugungen. Jeder dieser Datensätze ist wertvoll für die Ableitungen der nächsten Prognosen. Jede dieser Daten (außer die direkt gemessenen Erzeugungen/Verbräuche) ist _immer_ mit Fehlern behaftet. So kann zum Beispiel die durch die API gelieferte Bewölkung oder Strahlung von den realen Werten vor Ort abweichen.
Durch statistische Ansätze (Median) in Verbindung mit KI Unterstützung versuchen wir die Fehler mit fortschreitender Datensammlung mehr und mehr zu eliminieren. So ist die Funktionsweise des Gesamtsystems designed. Fehlschläge und Ausreißer wird es immer geben, aber in der Grundtendenz sollte unser Ergebnis immer besser werden. So die Theorie. ;)
LG,
Heiko
Super Modul muss ich sagen!
Gibt es eine Option das Consumer Dummy einzufärben? Einen Consumer kann ich ja eine feste Farbe zuordnen. Dem Consumer Dummy aber nicht. Oder ich finde da nichts.
Gruß, Andy
Hallo Andy,
stimmt ... diese Möglichkeit fehlt zur Zeit. Da ich momentan dabei bin die Attribut-Struktur zu straffen und zu überarbeiten, würde ich in dem Zuge gleich diese Möglichkeit mit implementieren.
LG,
Heiko
Hallo Heiko,
da Du scheinbar gerade an ein paar Verschönerungen arbeitest (oder dazu gedrängt wirst) ;-)
Links neben dem Home-Knoten steht der Gesamtverbrauch. Der ist aber nicht in der Mitte (so wie der Balken und das Licht-Icon nebst Wert auf der rechten Seite) sondern tiefer. Bei mir sieht es dann sogar so aus, als ob der an der Laufkette zum ersten Verbraucher ist.
Viele Grüße
Thomas
Hi Thomas,
ja, ist bei mir auch so. Das richte ich mit.
LG
Hallo @all,
soeben habe ich die V 1.49.6 in mein contrib geladen.
Umgesetzt ist:
- der Text des Home-Knotens ist ausgerichtet
- es gibt ein neues Attribut consumerControl. Zunächst nur mit dem Schlüssel dummyIcon um das Icon und die Farbe des Consumer Dummy anpassen zu können.
- ein inaktiver Consumer wird "grau" (wie die Laufkette in diesem Fall) dargestellt
consumerControl <Schlüssel=Wert> <Schlüssel=Wert> ...
Durch die Angabe der nachfolgend aufgeführten 'Schlüssel=Wert' Paare können verschiedene übergreifende Eigenschaften der Verbraucherdarstellung eingestellt werden.
Die Eingabe kann mehrzeilig erfolgen.
dummyIcon Icon und ggf. dessen Farbe zur Darstellung des Dummy-Verbrauchers in der Flußgrafik (optional)
Syntax: [<Icon>][@<Farbe>]
Soll nur die Farbe des Standard Dummy-Icon geändert werden, kann lediglich '@<Farbe>' angegeben werden.
Die Farbe kann als Hex-Wert (z.B. #cc3300) oder Bezeichnung (z.B. red, blue) angegeben werden.
Beispiel:
attr <name> consumerControl dummyIcon=light_light_dim_100@#cc3300
In dieses Attribut werden noch weitere Schlüssel folgen und die Anzahl der Attribute im Modul reduzieren.
Ihr könnt die V gerne ausprobieren.
LG,
Heiko
Hallo,
- Ich habe PV Module mit 20kWp auf dem Dach aber aus Gründen nur einen 15kVA Wechselrichter. Bisher hatte ich setupStringPeak auf 20, das führt allerdings zu Prognosen >15kW.
Wenn ich jetzt setupStringPeak auf 15 setze, würde sich das ja vermutlich anteilig auch auf die Berechnung der Werte <15 auswirken, richtig?
Was die Anlage aber tatsächlich macht, ist bei 15kW abzuregeln. D.h. mein "Berg" in der Verlaufskurve ist bei 15 abgeschnitten und nicht einfach nur flacher.
Lässt sich das am Device mit entsprechender Konfiguration abbilden? Vielleicht mit limit=75 am setupInverterDev und setupStringPeak auf 20?
- Nach einigen Monaten Beobachtung ist bei mir immer noch SolCastAPI mit pvCorrectionFactor_Auto=off bei wechselhaftem Wetter am nähesten dran.
Bei den anderen sind mMn die Ungenauigkeiten in der Wetterprognose die Schwierigkeit den Entscheidungsbaum bzw. die Korrekturfaktoren passend zu berechnen, da die Eingangsdaten falsch sind und alle Bemühungen in den Berechnungsalgorithmen vereiteln.
zB Ist: bewölkt, Prognose: Sonne --> falsche Datengrundlage für Berechnung.
Was ich daher gerne hätte, ist eine alleinige Berücksichtigung des Sonnenstandes, der sich bei mir in den ersten Morgenstunden wegen eines östlichen Berges je nachdem mehr, weniger oder gar nicht auf den PV Ertrag auswirkt.
In pvCorrectionFactor_Auto=on_complex wird aber (auch) das Wetter berücksichtigt, ich würde mir eine Methode wünschen, die nur den Sonnenstand mit einbezieht.
Wäre das sinnvoll und möglich?
LG
Zitat von: fichtennadel am 03 April 2025, 14:34:57Ich habe PV Module mit 20kWp auf dem Dach aber aus Gründen nur einen 15kVA Wechselrichter. Bisher hatte ich setupStringPeak auf 20, das führt allerdings zu Prognosen >15kW.
Wenn ich jetzt setupStringPeak auf 15 setze, würde sich das ja vermutlich anteilig auch auf die Berechnung der Werte <15 auswirken, richtig?
Was die Anlage aber tatsächlich macht, ist bei 15kW abzuregeln. D.h. mein "Berg" in der Verlaufskurve ist bei 15 abgeschnitten und nicht einfach nur flacher.
Lässt sich das am Device mit entsprechender Konfiguration abbilden? Vielleicht mit limit=75 am setupInverterDev und setupStringPeak auf 20?
Ich habe ein ähnliches Setup, aber bei mir funktioniert das einwandfrei (abgesehen vom mittlerweile behobenen Bug, dass die AI-Korrektur nicht mehr limitiert wurde).
Folgender Schlüssel im Inverter-Device ist nötig:
capacity=15000
ZitatWas ich daher gerne hätte, ist eine alleinige Berücksichtigung des Sonnenstandes, der sich bei mir in den ersten Morgenstunden wegen eines östlichen Berges je nachdem mehr, weniger oder gar nicht auf den PV Ertrag auswirkt.
In pvCorrectionFactor_Auto=on_complex wird aber (auch) das Wetter berücksichtigt, ich würde mir eine Methode wünschen, die nur den Sonnenstand mit einbezieht.
Wäre das sinnvoll und möglich?
Du kannst pvCorrectionFactor_Auto=simple setzen um die Bewölkung etc. nicht zu bewerten. Der Sonnenstad wird implizit durch SolCast API in den gelieferten Prognosen berücksichtigt.
Zusätzlich könntest für bestimmte Stunden eine manuelle Reduktion vornehmen mit pvCorrectionFactor_XX.
LG,
Heiko
Zitat von: TheTrumpeter am 03 April 2025, 14:50:14Folgender Schlüssel im Inverter-Device ist nötig:
capacity=15000
Hm, danke, ich sehe gerade, das hatte ich sogar schon gesetzt.
Aber trotzdem ist zB heute Today_Hour13_PVforecast=16526Wh, bei pvCorrectionFactor_Auto=on_complex.
Woran kann das liegen ?
define PV_Forecast_OpenMeteo SolarForecast
attr PV_Forecast_OpenMeteo alias PV Forecast OpenMeteo
attr PV_Forecast_OpenMeteo consumer01 waermepumpe icon=sani_heating_heatpump_buffer type=noSchedule mode=can power=1700 pcurr=Leistungsaufnahme
attr PV_Forecast_OpenMeteo consumer02 Wallbox_goe icon=electric_car_icon type=noSchedule mode=can power=11000 pcurr=power_curr exconfc=1
attr PV_Forecast_OpenMeteo ctrlLanguage DE
attr PV_Forecast_OpenMeteo ctrlSolCastAPImaxReq 10
attr PV_Forecast_OpenMeteo event-on-change-reading .*
attr PV_Forecast_OpenMeteo flowGraphicControl animate=1
attr PV_Forecast_OpenMeteo graphicHistoryHour 8
attr PV_Forecast_OpenMeteo group Forecast
attr PV_Forecast_OpenMeteo room PV Forecast
attr PV_Forecast_OpenMeteo setupInverterDev01 wechselrichter pv=movingAveragePV:W etotal=ZaehlerPVProduktion:Wh capacity=15000
attr PV_Forecast_OpenMeteo setupInverterStrings String1
attr PV_Forecast_OpenMeteo setupMeterDev wechselrichter gcon=movingAverageBezug:W contotal=ArchiveData_EnergyReal_WAC_Plus_Absolute:Wh gfeedin=-gcon feedtotal=ArchiveData_EnergyReal_WAC_Minus_Absolute:Wh
attr PV_Forecast_OpenMeteo setupRadiationAPI OpenMeteoDWD-API
attr PV_Forecast_OpenMeteo setupStringPeak String1=20
attr PV_Forecast_OpenMeteo setupWeatherDev1 OpenMeteoDWD-API
# FUUID 6727e791-f33f-9021-7834-141c9173b46fa1cd
# FVERSION 76_SolarForecast.pm:v1.49.5-s29814/2025-03-31
# LCACHEFILE last write time: 15:08:44 File: ./FHEM/FhemUtils/PVCfg_SolarForecast_PV_Forecast_OpenMeteo
# MODE Automatic / Event-controlled - next planned Cycletime: 15:15:20
# MODEL OpenMeteoDWDAPI
# NAME PV_Forecast_OpenMeteo
# NOTIFYDEV wechselrichter,waermepumpe,Wallbox_goe
# NR 343
# NTFY_ORDER 50-PV_Forecast_OpenMeteo
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL OpenMeteoDWDAPI
# eventCount 3790
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV PV_Forecast_OpenMeteo
# SPGROOM
# VERSION 1.49.5
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 1884
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:15195
# telnet telnetForBlockingFn_1743576186.98371_127.0.0.1_46796
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name PV_Forecast_OpenMeteo
# tsnext 1743692332.21057
# OLDREADINGS:
# READINGS:
# 2025-04-03 15:14:11 Current_AutarkyRate 100 %
# 2025-04-03 15:14:11 Current_Consumption 10669 W
# 2025-04-03 15:14:11 Current_GridConsumption 0 W
# 2025-04-03 15:14:11 Current_GridFeedIn 395 W
# 2025-04-03 15:14:11 Current_PV 11064 W
# 2025-04-03 15:14:11 Current_SelfConsumption 10669 W
# 2025-04-03 15:14:11 Current_SelfConsumptionRate 96 %
# 2025-04-03 15:14:11 Current_Surplus 395 W
# 2025-04-03 15:00:00 LastHourGridconsumptionReal 29 Wh
# 2025-04-03 15:00:00 LastHourPVforecast 14225 Wh
# 2025-04-03 15:00:00 LastHourPVreal 12246 Wh
# 2025-04-03 15:14:11 NextHours_Sum01_PVforecast 10331 Wh
# 2025-04-03 15:14:11 NextHours_Sum02_PVforecast 17356 Wh
# 2025-04-03 15:14:11 NextHours_Sum03_PVforecast 20822 Wh
# 2025-04-03 15:14:11 NextHours_Sum04_ConsumptionForecast 3515 Wh
# 2025-04-03 15:14:11 NextHours_Sum04_PVforecast 21701 Wh
# 2025-04-03 15:14:11 RestOfDayConsumptionForecast 6234 Wh
# 2025-04-03 15:14:11 RestOfDayPVforecast 21757 Wh
# 2025-04-03 00:59:53 Today_Hour01_GridConsumption 201 Wh
# 2025-04-03 00:59:53 Today_Hour01_GridFeedIn 0 Wh
# 2025-04-03 00:59:53 Today_Hour01_PVreal 0 Wh
# 2025-04-03 01:59:50 Today_Hour02_GridConsumption 182 Wh
# 2025-04-03 01:59:50 Today_Hour02_GridFeedIn 0 Wh
# 2025-04-03 01:59:50 Today_Hour02_PVreal 0 Wh
# 2025-04-03 02:59:50 Today_Hour03_GridConsumption 167 Wh
# 2025-04-03 02:59:50 Today_Hour03_GridFeedIn 0 Wh
# 2025-04-03 02:59:50 Today_Hour03_PVreal 0 Wh
# 2025-04-03 03:59:50 Today_Hour04_GridConsumption 165 Wh
# 2025-04-03 03:59:50 Today_Hour04_GridFeedIn 0 Wh
# 2025-04-03 03:59:50 Today_Hour04_PVreal 0 Wh
# 2025-04-03 04:59:50 Today_Hour05_GridConsumption 215 Wh
# 2025-04-03 04:59:50 Today_Hour05_GridFeedIn 0 Wh
# 2025-04-03 04:59:50 Today_Hour05_PVreal 0 Wh
# 2025-04-03 05:59:50 Today_Hour06_GridConsumption 189 Wh
# 2025-04-03 05:59:50 Today_Hour06_GridFeedIn 0 Wh
# 2025-04-03 05:59:50 Today_Hour06_PVreal 0 Wh
# 2025-04-03 06:59:50 Today_Hour07_GridConsumption 219 Wh
# 2025-04-03 06:59:50 Today_Hour07_GridFeedIn 0 Wh
# 2025-04-03 06:59:50 Today_Hour07_PVforecast 57 Wh
# 2025-04-03 06:59:50 Today_Hour07_PVreal 38 Wh
# 2025-04-03 07:59:54 Today_Hour08_GridConsumption 172 Wh
# 2025-04-03 07:59:54 Today_Hour08_GridFeedIn 306 Wh
# 2025-04-03 07:59:54 Today_Hour08_PVforecast 956 Wh
# 2025-04-03 07:59:54 Today_Hour08_PVreal 625 Wh
# 2025-04-03 08:59:50 Today_Hour09_GridConsumption 40 Wh
# 2025-04-03 08:59:50 Today_Hour09_GridFeedIn 1783 Wh
# 2025-04-03 08:59:50 Today_Hour09_PVforecast 5150 Wh
# 2025-04-03 08:59:50 Today_Hour09_PVreal 4079 Wh
# 2025-04-03 09:59:50 Today_Hour10_GridConsumption 0 Wh
# 2025-04-03 09:59:50 Today_Hour10_GridFeedIn 6696 Wh
# 2025-04-03 09:59:50 Today_Hour10_PVforecast 10173 Wh
# 2025-04-03 09:59:50 Today_Hour10_PVreal 7445 Wh
# 2025-04-03 10:59:51 Today_Hour11_GridConsumption 0 Wh
# 2025-04-03 10:59:51 Today_Hour11_GridFeedIn 9581 Wh
# 2025-04-03 10:59:51 Today_Hour11_PVforecast 12361 Wh
# 2025-04-03 10:59:51 Today_Hour11_PVreal 10562 Wh
# 2025-04-03 11:59:51 Today_Hour12_GridConsumption 0 Wh
# 2025-04-03 11:59:51 Today_Hour12_GridFeedIn 11337 Wh
# 2025-04-03 11:59:51 Today_Hour12_PVforecast 15742 Wh
# 2025-04-03 11:59:51 Today_Hour12_PVreal 12353 Wh
# 2025-04-03 12:59:54 Today_Hour13_GridConsumption 0 Wh
# 2025-04-03 12:59:54 Today_Hour13_GridFeedIn 12084 Wh
# 2025-04-03 12:59:54 Today_Hour13_PVforecast 16526 Wh
# 2025-04-03 12:59:54 Today_Hour13_PVreal 13287 Wh
# 2025-04-03 13:59:50 Today_Hour14_GridConsumption 0 Wh
# 2025-04-03 13:59:50 Today_Hour14_GridFeedIn 12586 Wh
# 2025-04-03 13:59:50 Today_Hour14_PVforecast 15984 Wh
# 2025-04-03 13:59:50 Today_Hour14_PVreal 13301 Wh
# 2025-04-03 14:59:50 Today_Hour15_GridConsumption 29 Wh
# 2025-04-03 14:59:50 Today_Hour15_GridFeedIn 7938 Wh
# 2025-04-03 14:59:50 Today_Hour15_PVforecast 14225 Wh
# 2025-04-03 14:59:50 Today_Hour15_PVreal 12246 Wh
# 2025-04-03 15:14:11 Today_Hour16_GridConsumption 1 Wh
# 2025-04-03 15:14:11 Today_Hour16_GridFeedIn 100 Wh
# 2025-04-03 15:14:11 Today_Hour16_PVforecast 11124 Wh
# 2025-04-03 15:14:11 Today_Hour16_PVreal 1824 Wh
# 2025-04-03 15:14:11 Today_Hour17_PVforecast 7954 Wh
# 2025-04-03 15:14:11 Today_Hour18_PVforecast 4238 Wh
# 2025-04-03 15:14:11 Today_Hour19_PVforecast 1148 Wh
# 2025-04-03 15:14:11 Today_Hour20_PVforecast 74 Wh
# 2025-04-03 15:14:11 Today_MaxPVforecast 16526 Wh
# 2025-04-03 15:14:11 Today_MaxPVforecastTime 2025-04-03 12:00:00
# 2025-04-03 15:14:11 Today_PVforecast 115712 Wh
# 2025-04-03 15:14:11 Today_PVreal 75760 Wh
# 2025-04-03 15:14:11 Today_SunRise 06:30
# 2025-04-03 15:14:11 Today_SunSet 19:27
# 2025-04-03 15:14:11 Tomorrow_ConsumptionForecast 17550 Wh
# 2025-04-03 15:14:11 Tomorrow_PVforecast 105239 Wh
# 2025-04-03 15:14:11 Tomorrow_SunRise 06:28
# 2025-04-03 15:14:11 Tomorrow_SunSet 19:28
# 2025-04-03 15:14:11 consumer01 name='Wärmepumpe' state='unknown' mode='can' planningstate='noSchedule'
# 2025-04-03 15:14:11 consumer01_currentPower 400 W
# 2025-04-03 15:14:11 consumer02 name='Wallbox' state='unknown' mode='can' planningstate='noSchedule'
# 2025-04-03 15:14:11 consumer02_currentPower 0 W
# 2025-04-03 15:14:11 nextCycletime 15:15:20
# 2025-04-03 15:10:44 nextRadiationAPICall nach 03.04.2025 15:25:44
# 2025-04-03 07:00:06 pvCorrectionFactor_07 0.36 (automatic - old factor: 0.38, Sun Alt range: 0, Cloud range: 00, Days in range: 5)
# 2025-04-03 08:00:06 pvCorrectionFactor_08 0.42 (automatic - old factor: 0.34, Sun Alt range: 10, Cloud range: 00, Days in range: 7)
# 2025-04-03 09:00:06 pvCorrectionFactor_09 0.77 (automatic - old factor: 0.75, Sun Alt range: 20, Cloud range: 00, Days in range: 6)
# 2025-04-03 10:00:05 pvCorrectionFactor_10 0.95 (automatic - old factor: 0.95, Sun Alt range: 30, Cloud range: 00, Days in range: 4)
# 2025-04-03 11:00:06 pvCorrectionFactor_11 0.83 (automatic - old factor: 0.90, Sun Alt range: 35, Cloud range: 00, Days in range: 3)
# 2025-04-03 12:00:05 pvCorrectionFactor_12 0.78 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
# 2025-04-03 13:00:05 pvCorrectionFactor_13 0.80 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
# 2025-04-03 14:00:05 pvCorrectionFactor_14 0.83 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
# 2025-04-03 15:00:07 pvCorrectionFactor_15 0.86 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
# 2025-04-03 15:14:11 pvCorrectionFactor_Auto on_complex
# 2024-11-03 22:17:10 setupStringAzimuth String1=SE
# 2024-11-04 11:11:27 setupStringDeclination String1=10
# 2025-04-03 15:14:13 state updated
#
setstate PV_Forecast_OpenMeteo updated
setstate PV_Forecast_OpenMeteo 2025-04-02 08:42:02 .associatedWith wechselrichter waermepumpe Wallbox_goe
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 .lastupdateForecastValues 1743686050
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 .pvCorrectionFactor_Auto_Soll on_complex
setstate PV_Forecast_OpenMeteo 2025-04-03 01:00:05 .signaldone_01 done
setstate PV_Forecast_OpenMeteo 2025-04-03 02:00:05 .signaldone_02 done
setstate PV_Forecast_OpenMeteo 2025-04-03 03:00:03 .signaldone_03 done
setstate PV_Forecast_OpenMeteo 2025-04-03 04:00:05 .signaldone_04 done
setstate PV_Forecast_OpenMeteo 2025-04-03 05:00:05 .signaldone_05 done
setstate PV_Forecast_OpenMeteo 2025-04-03 06:00:05 .signaldone_06 done
setstate PV_Forecast_OpenMeteo 2025-04-03 07:00:06 .signaldone_07 done
setstate PV_Forecast_OpenMeteo 2025-04-03 08:00:06 .signaldone_08 done
setstate PV_Forecast_OpenMeteo 2025-04-03 09:00:06 .signaldone_09 done
setstate PV_Forecast_OpenMeteo 2025-04-03 10:00:05 .signaldone_10 done
setstate PV_Forecast_OpenMeteo 2025-04-03 11:00:06 .signaldone_11 done
setstate PV_Forecast_OpenMeteo 2025-04-03 12:00:05 .signaldone_12 done
setstate PV_Forecast_OpenMeteo 2025-04-03 13:00:05 .signaldone_13 done
setstate PV_Forecast_OpenMeteo 2025-04-03 14:00:05 .signaldone_14 done
setstate PV_Forecast_OpenMeteo 2025-04-03 15:00:07 .signaldone_15 done
setstate PV_Forecast_OpenMeteo 2025-04-03 00:00:06 .signaldone_24 done
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_AutarkyRate 100 %
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_Consumption 10669 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_GridConsumption 0 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_GridFeedIn 395 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_PV 11064 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_SelfConsumption 10669 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_SelfConsumptionRate 96 %
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Current_Surplus 395 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:00:00 LastHourGridconsumptionReal 29 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:00:00 LastHourPVforecast 14225 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:00:00 LastHourPVreal 12246 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 NextHours_Sum01_PVforecast 10331 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 NextHours_Sum02_PVforecast 17356 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 NextHours_Sum03_PVforecast 20822 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 NextHours_Sum04_ConsumptionForecast 3515 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 NextHours_Sum04_PVforecast 21701 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 RestOfDayConsumptionForecast 6234 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 RestOfDayPVforecast 21757 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 00:59:53 Today_Hour01_GridConsumption 201 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 00:59:53 Today_Hour01_GridFeedIn 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 00:59:53 Today_Hour01_PVreal 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 01:59:50 Today_Hour02_GridConsumption 182 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 01:59:50 Today_Hour02_GridFeedIn 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 01:59:50 Today_Hour02_PVreal 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 02:59:50 Today_Hour03_GridConsumption 167 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 02:59:50 Today_Hour03_GridFeedIn 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 02:59:50 Today_Hour03_PVreal 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 03:59:50 Today_Hour04_GridConsumption 165 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 03:59:50 Today_Hour04_GridFeedIn 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 03:59:50 Today_Hour04_PVreal 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 04:59:50 Today_Hour05_GridConsumption 215 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 04:59:50 Today_Hour05_GridFeedIn 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 04:59:50 Today_Hour05_PVreal 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 05:59:50 Today_Hour06_GridConsumption 189 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 05:59:50 Today_Hour06_GridFeedIn 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 05:59:50 Today_Hour06_PVreal 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 06:59:50 Today_Hour07_GridConsumption 219 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 06:59:50 Today_Hour07_GridFeedIn 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 06:59:50 Today_Hour07_PVforecast 57 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 06:59:50 Today_Hour07_PVreal 38 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 07:59:54 Today_Hour08_GridConsumption 172 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 07:59:54 Today_Hour08_GridFeedIn 306 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 07:59:54 Today_Hour08_PVforecast 956 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 07:59:54 Today_Hour08_PVreal 625 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 08:59:50 Today_Hour09_GridConsumption 40 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 08:59:50 Today_Hour09_GridFeedIn 1783 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 08:59:50 Today_Hour09_PVforecast 5150 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 08:59:50 Today_Hour09_PVreal 4079 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 09:59:50 Today_Hour10_GridConsumption 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 09:59:50 Today_Hour10_GridFeedIn 6696 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 09:59:50 Today_Hour10_PVforecast 10173 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 09:59:50 Today_Hour10_PVreal 7445 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 10:59:51 Today_Hour11_GridConsumption 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 10:59:51 Today_Hour11_GridFeedIn 9581 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 10:59:51 Today_Hour11_PVforecast 12361 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 10:59:51 Today_Hour11_PVreal 10562 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 11:59:51 Today_Hour12_GridConsumption 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 11:59:51 Today_Hour12_GridFeedIn 11337 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 11:59:51 Today_Hour12_PVforecast 15742 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 11:59:51 Today_Hour12_PVreal 12353 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 12:59:54 Today_Hour13_GridConsumption 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 12:59:54 Today_Hour13_GridFeedIn 12084 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 12:59:54 Today_Hour13_PVforecast 16526 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 12:59:54 Today_Hour13_PVreal 13287 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 13:59:50 Today_Hour14_GridConsumption 0 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 13:59:50 Today_Hour14_GridFeedIn 12586 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 13:59:50 Today_Hour14_PVforecast 15984 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 13:59:50 Today_Hour14_PVreal 13301 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 14:59:50 Today_Hour15_GridConsumption 29 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 14:59:50 Today_Hour15_GridFeedIn 7938 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 14:59:50 Today_Hour15_PVforecast 14225 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 14:59:50 Today_Hour15_PVreal 12246 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour16_GridConsumption 1 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour16_GridFeedIn 100 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour16_PVforecast 11124 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour16_PVreal 1824 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour17_PVforecast 7954 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour18_PVforecast 4238 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour19_PVforecast 1148 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_Hour20_PVforecast 74 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_MaxPVforecast 16526 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_MaxPVforecastTime 2025-04-03 12:00:00
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_PVforecast 115712 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_PVreal 75760 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_SunRise 06:30
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Today_SunSet 19:27
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Tomorrow_ConsumptionForecast 17550 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Tomorrow_PVforecast 105239 Wh
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Tomorrow_SunRise 06:28
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 Tomorrow_SunSet 19:28
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 consumer01 name='Wärmepumpe' state='unknown' mode='can' planningstate='noSchedule'
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 consumer01_currentPower 400 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 consumer02 name='Wallbox' state='unknown' mode='can' planningstate='noSchedule'
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 consumer02_currentPower 0 W
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 nextCycletime 15:15:20
setstate PV_Forecast_OpenMeteo 2025-04-03 15:10:44 nextRadiationAPICall nach 03.04.2025 15:25:44
setstate PV_Forecast_OpenMeteo 2025-04-03 07:00:06 pvCorrectionFactor_07 0.36 (automatic - old factor: 0.38, Sun Alt range: 0, Cloud range: 00, Days in range: 5)
setstate PV_Forecast_OpenMeteo 2025-04-03 08:00:06 pvCorrectionFactor_08 0.42 (automatic - old factor: 0.34, Sun Alt range: 10, Cloud range: 00, Days in range: 7)
setstate PV_Forecast_OpenMeteo 2025-04-03 09:00:06 pvCorrectionFactor_09 0.77 (automatic - old factor: 0.75, Sun Alt range: 20, Cloud range: 00, Days in range: 6)
setstate PV_Forecast_OpenMeteo 2025-04-03 10:00:05 pvCorrectionFactor_10 0.95 (automatic - old factor: 0.95, Sun Alt range: 30, Cloud range: 00, Days in range: 4)
setstate PV_Forecast_OpenMeteo 2025-04-03 11:00:06 pvCorrectionFactor_11 0.83 (automatic - old factor: 0.90, Sun Alt range: 35, Cloud range: 00, Days in range: 3)
setstate PV_Forecast_OpenMeteo 2025-04-03 12:00:05 pvCorrectionFactor_12 0.78 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
setstate PV_Forecast_OpenMeteo 2025-04-03 13:00:05 pvCorrectionFactor_13 0.80 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
setstate PV_Forecast_OpenMeteo 2025-04-03 14:00:05 pvCorrectionFactor_14 0.83 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
setstate PV_Forecast_OpenMeteo 2025-04-03 15:00:07 pvCorrectionFactor_15 0.86 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:11 pvCorrectionFactor_Auto on_complex
setstate PV_Forecast_OpenMeteo 2024-11-03 22:17:10 setupStringAzimuth String1=SE
setstate PV_Forecast_OpenMeteo 2024-11-04 11:11:27 setupStringDeclination String1=10
setstate PV_Forecast_OpenMeteo 2025-04-03 15:14:13 state updated
Zitat von: DS_Starter am 03 April 2025, 15:01:23Du kannst pvCorrectionFactor_Auto=simple setzen um die Bewölkung etc. nicht zu bewerten. Der Sonnenstad wird implizit durch SolCast API in den gelieferten Prognosen berücksichtigt.
Zusätzlich könntest für bestimmte Stunden eine manuelle Reduktion vornehmen mit pvCorrectionFactor_XX.
Beides berücksichtigt aber nicht den Jahresverlauf, oder versteh ich was falsch?
In der Stunde 8 bin ich zB im Februar noch im Schatten, da habe ich nur 20% des vorhergesagten Ertrags.
Im März ist um 8 die Sonne aber schon übern Hügel, da kommen dann 100%.
Ich wüsste jetzt nicht, wie ich das mit dem pvCorrectionFactor_XX abbilden kann, und die SolCast API weiß auch nichts von meiner Sonnenstand/Jahresverlauf abhängigen Verschattung.
ZitatAber trotzdem ist zB heute Today_Hour13_PVforecast=16526Wh, bei pvCorrectionFactor_Auto=on_complex.
Woran kann das liegen ?
Ordne dem Inverter bitte den String zu "strings=String1", auch wenn du nur einen hast. Technisch wird der String dann mit der Inverter-Cap beschnitten.
ZitatBeides berücksichtigt aber nicht den Jahresverlauf, oder versteh ich was falsch?
Naja da steckt schon ein wenig mehr drin. Aus der Hilfe:
pvCorrectionFactor_XX <Zahl>
Voreinstellung des Korrekturfaktors für die Stunde XX des Tages.
(default: 1.0)
In Abhängigkeit vom Setting pvCorrectionFactor_Auto ('off' bzw. 'on_.*') erfolgt eine statische oder dynamische Voreinstellung:
...
on_.* Der eingestellte Korrekturfaktor wird durch die Autokorrektur bzw. KI überschrieben
sofern ein berechneter Korrekturwert im System verfügbar ist.
Im Reading pvCorrectionFactor_XX wird der Status durch den Zusatz 'manual flex' signalisiert.
Da steckt eine Dynamik drin. Sobald ein berechneter Korrekturfakror vorhanden ist, wird dieser verwendet.
Aber du hast Recht, dass es keinen Jahreszeit abhängigen Korrekturfaktor "simple" gibt.
Nur als Hinweis, du verwendest nicht die SolCast API, sondern die OpenMeteoDWD-API!
Zitat von: DS_Starter am 03 April 2025, 15:55:45ZitatAber trotzdem ist zB heute Today_Hour13_PVforecast=16526Wh, bei pvCorrectionFactor_Auto=on_complex.
Woran kann das liegen ?
Ordne dem Inverter bitte den String zu "strings=String1", auch wenn du nur einen hast. Technisch wird der String dann mit der Inverter-Cap beschnitten.
Danke, das war's, jetzt ist die Vorhersage bei 15k gekappt.
Zitat von: DS_Starter am 03 April 2025, 15:55:45Aber du hast Recht, dass es keinen Jahreszeit abhängigen Korrekturfaktor "simple" gibt.
Und den würd ich mir halt jetzt wünschen ;D - aber alles gut, schon klar, man kann nicht jede Sonderlocke umsetzen.
Zitat von: DS_Starter am 03 April 2025, 15:55:45Nur als Hinweis, du verwendest nicht die SolCast API, sondern die OpenMeteoDWD-API!
Danke, ich weiß, das ist aber ein anderes Device, ich hab' ja drei zum Vergleichen ;)
Zitat von: DS_Starter am 02 April 2025, 23:29:45soeben habe ich die V 1.49.6 in mein contrib geladen.
Leider ist nach der Installation der 1.49.6 und einem Restart mein SolarForecast Device verschwunden und lässt sich auch nicht mit "set <device> restore ... " wiederherstellen.
Bin zurück auf die 1.49.5
Das ist mir unverständlich.
Gibt es im Log irgendwelche dienlichen Meldungen beim Start? Meistens steht etwas weshalb das Modul nicht geladen werden konnte.
Die Anpassungen in der V 1.49.6 sind nicht so gravierend dass sie einen Fehler verursachen sollten.
Ich glaube ich weiß was es ist ....
Zitat von: DS_Starter am 03 April 2025, 22:50:52Gibt es im Log irgendwelche dienlichen Meldungen beim Start? Meistens steht etwas weshalb das Modul nicht geladen werden konnte.
sorry, ja, folgende Log-Einträge:
2025.04.03 16:57:13 1: reload: Error:Modul 76_SolarForecast deactivated:
Bareword "CICONCOLDEF" not allowed while "strict subs" in use at ./FHEM/76_SolarForecast.pm line 17024, <$fh> line 5561.
BEGIN not safe after errors--compilation aborted at ./FHEM/76_SolarForecast.pm line 19485, <$fh> line 5561.
2025.04.03 16:57:13 0: Bareword "CICONCOLDEF" not allowed while "strict subs" in use at ./FHEM/76_SolarForecast.pm line 17024, <$fh> line 5561.
BEGIN not safe after errors--compilation aborted at ./FHEM/76_SolarForecast.pm line 19485, <$fh> line 5561.
Erledigt ... im contrib liegt ein Update der Version. Zu blöd, da war eine alte Konstante noch verblieben.
Kannst du wieder laden.
So würden wir uns das jeden Tag wünschen ... :)
hab mal etwas mit consumerControl gespielt ;)
dummyIcon=status_comfort@#ff8c00
Habe ich bei mir gleich übernommen. :)
ich bekomme einfach das Reading "Current_BatCharge_01" nicht über null.
Stündlich wir gezählt, aber SolarForecast zeigt immer 0% an.
Hab Ihr eine Idee wo ich schauen könnte?
Danke und Grüße
mi.ke
define SolarForecast SolarForecast
attr SolarForecast ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=99 careCycle=25
attr SolarForecast ctrlSpecialReadings SunHours_Remain,SunMinutes_Remain,todayBatInSum
attr SolarForecast event-on-change-reading .*
attr SolarForecast flowGraphicControl shiftx=-5 size=200 consumerdist=130 animate=1 homenodedyncol=1 strokeconsumerdyncol=1 showconsumer=0 strokecolstd=yellow
attr SolarForecast graphicBeam1Color 1D820D
attr SolarForecast graphicBeam1Content pvForecast
attr SolarForecast graphicBeam1FontColor 0DF7FF
attr SolarForecast graphicBeamWidth 20
attr SolarForecast graphicHeaderDetail all,co,pv,own,status
attr SolarForecast graphicHeaderOwnspec #Info\
Autarkierate:Current_AutarkyRate\
-\
-\
-\
#Batterie\
Input:Current_PowerBatIn_01\
Ladung:Current_BatCharge_01\
-\
-\
\
#Sonnenstunden\
verbleiben:special_SunHours_Remain\
-\
-\
-\
\
attr SolarForecast graphicHourCount 13
attr SolarForecast graphicWeatherColor B6C908
attr SolarForecast graphicWeatherColorNight CCCCCC
attr SolarForecast room System->Solar,Testkram
attr SolarForecast setupBatteryDev01 Solarbatterie_SF cap=cap:Wh pin=pin:W pout=pout:W intotal=intotal:Wh outtotal=outtotal:W charge:charge show=1
attr SolarForecast setupInverterDev01 WechselrichterSued_SF pv=pv:W etotal=etotal:Wh capacity=800 asynchron=0 icon=solar_icon@yellow:solar_icon
attr SolarForecast setupInverterStrings Balkon,Kellerdach
attr SolarForecast setupMeterDev Stromzaehler_SF gcon=gcon:W contotal=contotal:kWh gfeedin=gfeedin:Wh feedtotal=feedtotal:Wh
attr SolarForecast setupRadiationAPI DWD_OpenData
attr SolarForecast setupStringPeak Balkon=0.420 Kellerdach=0.420
attr SolarForecast setupWeatherDev1 DWD_OpenData
attr SolarForecast timestamp-on-change-reading .*
attr SolarForecast verbose 2
# FUUID 67ea8c84-f33f-b65a-4640-f708b0ba3292b546
# FVERSION 76_SolarForecast.pm:v1.49.5-s29814/2025-03-31
# LCACHEFILE last write time: 15:41:12 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 15:52:46
# MODEL DWD
# NAME SolarForecast
# NOTIFYDEV Stromzaehler_SF,Solarbatterie_SF,WechselrichterSued_SF
# NR 418
# NTFY_ORDER 50-SolarForecast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 257
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# SPGDETAIL
# SPGDEV SolarForecast
# SPGROOM
# VERSION 1.49.5
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 905
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:30312
# telnet telnetForBlockingFn_1743767199.35439_127.0.0.1_44616
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name SolarForecast
# tsnext 1743781919.65561
# OLDREADINGS:
# READINGS:
# 2025-04-04 13:47:51 Battery_ChargeRecommended_01 1
# 2025-04-03 18:52:57 Battery_ChargeRequest_01 1
# 2025-04-03 18:52:57 Battery_OptimumTargetSoC_01 10 %
# 2025-04-04 12:26:17 Current_AutarkyRate 100 %
# 2025-04-04 13:59:31 Current_BatCharge_01 0 %
# 2025-04-04 15:50:26 Current_Consumption 337 W
# 2025-04-04 12:26:17 Current_GridConsumption 0 W
# 2025-04-03 18:52:57 Current_GridFeedIn 0 W
# 2025-04-04 13:47:51 Current_PV 800 W
# 2025-04-04 15:50:26 Current_PowerBatIn_01 463 W
# 2025-04-03 18:52:57 Current_PowerBatOut_01 0 W
# 2025-04-04 15:50:26 Current_SelfConsumption 337 W
# 2025-04-04 15:46:56 Current_SelfConsumptionRate 42 %
# 2025-04-04 15:50:26 Current_Surplus 463 W
# 2025-04-04 15:00:00 LastHourGridconsumptionReal 265 Wh
# 2025-04-04 14:00:00 LastHourPVforecast 732 Wh
# 2025-04-03 18:00:00 LastHourPVreal 0 Wh
# 2025-04-04 15:51:36 NextHours_Sum01_PVforecast 554 Wh
# 2025-04-04 15:51:36 NextHours_Sum02_PVforecast 912 Wh
# 2025-04-04 15:51:36 NextHours_Sum03_PVforecast 1100 Wh
# 2025-04-04 15:51:36 NextHours_Sum04_ConsumptionForecast 1493 Wh
# 2025-04-04 15:51:36 NextHours_Sum04_PVforecast 1151 Wh
# 2025-04-04 13:59:31 RestOfDayConsumptionForecast 16633937 Wh
# 2025-04-04 15:51:36 RestOfDayPVforecast 1155 Wh
# 2025-04-04 00:00:04 Today_Hour01_BatIn_01 0 Wh
# 2025-04-04 00:00:04 Today_Hour01_BatOut_01 0 Wh
# 2025-04-04 00:59:49 Today_Hour01_GridConsumption 380 Wh
# 2025-04-04 00:00:04 Today_Hour01_PVreal 0 Wh
# 2025-04-04 01:00:04 Today_Hour02_BatIn_01 0 Wh
# 2025-04-04 01:00:04 Today_Hour02_BatOut_01 0 Wh
# 2025-04-04 01:59:26 Today_Hour02_GridConsumption 336 Wh
# 2025-04-04 01:00:04 Today_Hour02_PVreal 0 Wh
# 2025-04-04 02:00:04 Today_Hour03_BatIn_01 0 Wh
# 2025-04-04 02:00:04 Today_Hour03_BatOut_01 0 Wh
# 2025-04-04 02:59:49 Today_Hour03_GridConsumption 308 Wh
# 2025-04-04 02:00:04 Today_Hour03_PVreal 0 Wh
# 2025-04-04 03:00:04 Today_Hour04_BatIn_01 0 Wh
# 2025-04-04 03:00:04 Today_Hour04_BatOut_01 0 Wh
# 2025-04-04 03:10:36 Today_Hour04_GridConsumption 38 Wh
# 2025-04-04 03:00:04 Today_Hour04_PVreal 0 Wh
# 2025-04-04 04:00:04 Today_Hour05_BatIn_01 0 Wh
# 2025-04-04 04:00:04 Today_Hour05_BatOut_01 0 Wh
# 2025-04-04 04:00:04 Today_Hour05_GridConsumption 0 Wh
# 2025-04-04 04:00:04 Today_Hour05_PVreal 0 Wh
# 2025-04-04 05:00:04 Today_Hour06_BatIn_01 0 Wh
# 2025-04-04 05:00:04 Today_Hour06_BatOut_01 0 Wh
# 2025-04-04 05:00:04 Today_Hour06_GridConsumption 0 Wh
# 2025-04-04 05:00:04 Today_Hour06_PVreal 0 Wh
# 2025-04-04 06:00:04 Today_Hour07_BatIn_01 0 Wh
# 2025-04-04 06:00:04 Today_Hour07_BatOut_01 0 Wh
# 2025-04-04 06:00:04 Today_Hour07_GridConsumption 0 Wh
# 2025-04-04 06:00:04 Today_Hour07_PVreal 0 Wh
# 2025-04-04 07:00:04 Today_Hour08_BatIn_01 0 Wh
# 2025-04-04 07:00:04 Today_Hour08_BatOut_01 0 Wh
# 2025-04-04 07:00:04 Today_Hour08_GridConsumption 0 Wh
# 2025-04-04 00:00:26 Today_Hour08_PVforecast 22 Wh
# 2025-04-04 07:00:04 Today_Hour08_PVreal 0 Wh
# 2025-04-04 08:00:04 Today_Hour09_BatIn_01 0 Wh
# 2025-04-04 08:00:04 Today_Hour09_BatOut_01 0 Wh
# 2025-04-04 08:59:40 Today_Hour09_GridConsumption 1907 Wh
# 2025-04-04 07:00:26 Today_Hour09_PVforecast 85 Wh
# 2025-04-04 08:00:04 Today_Hour09_PVreal 0 Wh
# 2025-04-04 09:00:04 Today_Hour10_BatIn_01 0 Wh
# 2025-04-04 09:00:04 Today_Hour10_BatOut_01 0 Wh
# 2025-04-04 09:59:16 Today_Hour10_GridConsumption 371 Wh
# 2025-04-04 07:00:26 Today_Hour10_PVforecast 169 Wh
# 2025-04-04 09:00:04 Today_Hour10_PVreal 0 Wh
# 2025-04-04 10:00:04 Today_Hour11_BatIn_01 0 Wh
# 2025-04-04 10:00:04 Today_Hour11_BatOut_01 0 Wh
# 2025-04-04 10:59:49 Today_Hour11_GridConsumption 265 Wh
# 2025-04-04 07:00:26 Today_Hour11_PVforecast 370 Wh
# 2025-04-04 10:00:04 Today_Hour11_PVreal 0 Wh
# 2025-04-04 11:54:47 Today_Hour12_BatIn_01 729 Wh
# 2025-04-04 11:00:04 Today_Hour12_BatOut_01 0 Wh
# 2025-04-04 11:59:27 Today_Hour12_GridConsumption 387 Wh
# 2025-04-04 07:00:26 Today_Hour12_PVforecast 527 Wh
# 2025-04-04 11:00:04 Today_Hour12_PVreal 0 Wh
# 2025-04-04 12:59:49 Today_Hour13_BatIn_01 11953 Wh
# 2025-04-04 12:00:04 Today_Hour13_BatOut_01 0 Wh
# 2025-04-04 12:59:49 Today_Hour13_GridConsumption 266 Wh
# 2025-04-04 07:00:26 Today_Hour13_PVforecast 654 Wh
# 2025-04-04 12:00:04 Today_Hour13_PVreal 0 Wh
# 2025-04-04 13:59:31 Today_Hour14_BatIn_01 5540 Wh
# 2025-04-04 13:00:04 Today_Hour14_BatOut_01 0 Wh
# 2025-04-04 13:59:31 Today_Hour14_GridConsumption 391 Wh
# 2025-04-04 13:00:08 Today_Hour14_PVforecast 732 Wh
# 2025-04-04 13:00:04 Today_Hour14_PVreal 0 Wh
# 2025-04-04 14:02:47 Today_Hour15_BatIn_01 0 Wh (WARNING invalid BatIn Energy occured - see Logfile)
# 2025-04-04 14:00:04 Today_Hour15_BatOut_01 0 Wh
# 2025-04-04 14:59:06 Today_Hour15_GridConsumption 265 Wh
# 2025-04-04 13:00:08 Today_Hour15_PVforecast 732 Wh
# 2025-04-04 14:00:04 Today_Hour15_PVreal 0 Wh
# 2025-04-04 15:48:06 Today_Hour16_BatIn_01 5 Wh
# 2025-04-04 15:00:04 Today_Hour16_BatOut_01 0 Wh
# 2025-04-04 15:51:36 Today_Hour16_GridConsumption 364 Wh
# 2025-04-04 13:00:08 Today_Hour16_PVforecast 674 Wh
# 2025-04-04 15:00:04 Today_Hour16_PVreal 0 Wh
# 2025-04-04 13:00:08 Today_Hour17_PVforecast 536 Wh
# 2025-04-04 13:00:08 Today_Hour18_PVforecast 331 Wh
# 2025-04-04 07:00:26 Today_Hour19_PVforecast 166 Wh
# 2025-04-04 07:00:26 Today_Hour20_PVforecast 33 Wh
# 2025-04-04 13:01:18 Today_MaxPVforecast 732 Wh
# 2025-04-04 00:00:26 Today_MaxPVforecastTime 2025-04-04 13:00:00
# 2025-04-04 13:00:08 Today_PVforecast 5031 Wh
# 2025-04-04 00:00:04 Today_PVreal 0 Wh
# 2025-04-04 00:00:04 Today_SunRise 06:55
# 2025-04-04 00:00:04 Today_SunSet 20:01
# 2025-04-04 12:00:37 Tomorrow_ConsumptionForecast 33265551 Wh
# 2025-04-04 15:00:16 Tomorrow_PVforecast 4173 Wh
# 2025-04-04 00:00:04 Tomorrow_SunRise 06:53
# 2025-04-04 00:00:04 Tomorrow_SunSet 20:02
# 2025-04-04 15:51:36 nextCycletime 15:52:46
# 2025-04-03 18:52:57 pvCorrectionFactor_Auto on_complex_ai
# 2025-04-03 13:49:28 setupStringAzimuth Balkon=-4 Kellerdach=83
# 2025-04-01 21:45:38 setupStringDeclination Balkon=90 Kellerdach=35
# 2025-04-04 15:51:36 special_SunHours_Remain 4.16
# 2025-04-04 15:51:36 special_SunMinutes_Remain 249
# 2025-04-04 15:50:26 special_todayBatInSum -135586.5 Wh
# 2025-04-04 15:51:37 state updated
#
setstate SolarForecast updated
setstate SolarForecast 2025-04-04 12:13:29 .SolarForecast_ctrlDebu
setstate SolarForecast 2025-04-04 12:13:29 .SolarForecast_graphicHistoryHour
setstate SolarForecast 2025-04-04 12:13:29 .SolarForecast_graphicShowNight
setstate SolarForecast 2025-04-04 12:13:29 .SolarForecast_graphicShowWeather
setstate SolarForecast 2025-04-04 14:02:48 .associatedWith Stromzaehler_SF Solarbatterie_SF WechselrichterSued_SF DWD_OpenData
setstate SolarForecast 2025-04-04 15:51:36 .lastupdateForecastValues 1743774696
setstate SolarForecast 2025-04-04 15:51:36 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate SolarForecast 2025-04-04 01:00:04 .signaldone_01 done
setstate SolarForecast 2025-04-04 02:00:04 .signaldone_02 done
setstate SolarForecast 2025-04-04 03:00:04 .signaldone_03 done
setstate SolarForecast 2025-04-04 04:00:04 .signaldone_04 done
setstate SolarForecast 2025-04-04 05:00:04 .signaldone_05 done
setstate SolarForecast 2025-04-04 06:00:04 .signaldone_06 done
setstate SolarForecast 2025-04-04 07:00:04 .signaldone_07 done
setstate SolarForecast 2025-04-04 08:00:04 .signaldone_08 done
setstate SolarForecast 2025-04-04 09:00:04 .signaldone_09 done
setstate SolarForecast 2025-04-04 10:00:04 .signaldone_10 done
setstate SolarForecast 2025-04-04 11:00:04 .signaldone_11 done
setstate SolarForecast 2025-04-04 12:00:04 .signaldone_12 done
setstate SolarForecast 2025-04-04 13:00:04 .signaldone_13 done
setstate SolarForecast 2025-04-04 14:00:04 .signaldone_14 done
setstate SolarForecast 2025-04-04 15:00:04 .signaldone_15 done
setstate SolarForecast 2025-04-04 00:00:04 .signaldone_24 done
setstate SolarForecast 2025-04-04 13:47:51 Battery_ChargeRecommended_01 1
setstate SolarForecast 2025-04-03 18:52:57 Battery_ChargeRequest_01 1
setstate SolarForecast 2025-04-03 18:52:57 Battery_OptimumTargetSoC_01 10 %
setstate SolarForecast 2025-04-04 12:26:17 Current_AutarkyRate 100 %
setstate SolarForecast 2025-04-04 13:59:31 Current_BatCharge_01 0 %
setstate SolarForecast 2025-04-04 15:50:26 Current_Consumption 337 W
setstate SolarForecast 2025-04-04 12:26:17 Current_GridConsumption 0 W
setstate SolarForecast 2025-04-03 18:52:57 Current_GridFeedIn 0 W
setstate SolarForecast 2025-04-04 13:47:51 Current_PV 800 W
setstate SolarForecast 2025-04-04 15:50:26 Current_PowerBatIn_01 463 W
setstate SolarForecast 2025-04-03 18:52:57 Current_PowerBatOut_01 0 W
setstate SolarForecast 2025-04-04 15:50:26 Current_SelfConsumption 337 W
setstate SolarForecast 2025-04-04 15:46:56 Current_SelfConsumptionRate 42 %
setstate SolarForecast 2025-04-04 15:50:26 Current_Surplus 463 W
setstate SolarForecast 2025-04-04 15:00:00 LastHourGridconsumptionReal 265 Wh
setstate SolarForecast 2025-04-04 14:00:00 LastHourPVforecast 732 Wh
setstate SolarForecast 2025-04-03 18:00:00 LastHourPVreal 0 Wh
setstate SolarForecast 2025-04-04 15:51:36 NextHours_Sum01_PVforecast 554 Wh
setstate SolarForecast 2025-04-04 15:51:36 NextHours_Sum02_PVforecast 912 Wh
setstate SolarForecast 2025-04-04 15:51:36 NextHours_Sum03_PVforecast 1100 Wh
setstate SolarForecast 2025-04-04 15:51:36 NextHours_Sum04_ConsumptionForecast 1493 Wh
setstate SolarForecast 2025-04-04 15:51:36 NextHours_Sum04_PVforecast 1151 Wh
setstate SolarForecast 2025-04-04 13:59:31 RestOfDayConsumptionForecast 16633937 Wh
setstate SolarForecast 2025-04-04 15:51:36 RestOfDayPVforecast 1155 Wh
setstate SolarForecast 2025-04-04 00:00:04 Today_Hour01_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 00:00:04 Today_Hour01_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 00:59:49 Today_Hour01_GridConsumption 380 Wh
setstate SolarForecast 2025-04-04 00:00:04 Today_Hour01_PVreal 0 Wh
setstate SolarForecast 2025-04-04 01:00:04 Today_Hour02_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 01:00:04 Today_Hour02_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 01:59:26 Today_Hour02_GridConsumption 336 Wh
setstate SolarForecast 2025-04-04 01:00:04 Today_Hour02_PVreal 0 Wh
setstate SolarForecast 2025-04-04 02:00:04 Today_Hour03_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 02:00:04 Today_Hour03_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 02:59:49 Today_Hour03_GridConsumption 308 Wh
setstate SolarForecast 2025-04-04 02:00:04 Today_Hour03_PVreal 0 Wh
setstate SolarForecast 2025-04-04 03:00:04 Today_Hour04_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 03:00:04 Today_Hour04_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 03:10:36 Today_Hour04_GridConsumption 38 Wh
setstate SolarForecast 2025-04-04 03:00:04 Today_Hour04_PVreal 0 Wh
setstate SolarForecast 2025-04-04 04:00:04 Today_Hour05_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 04:00:04 Today_Hour05_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 04:00:04 Today_Hour05_GridConsumption 0 Wh
setstate SolarForecast 2025-04-04 04:00:04 Today_Hour05_PVreal 0 Wh
setstate SolarForecast 2025-04-04 05:00:04 Today_Hour06_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 05:00:04 Today_Hour06_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 05:00:04 Today_Hour06_GridConsumption 0 Wh
setstate SolarForecast 2025-04-04 05:00:04 Today_Hour06_PVreal 0 Wh
setstate SolarForecast 2025-04-04 06:00:04 Today_Hour07_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 06:00:04 Today_Hour07_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 06:00:04 Today_Hour07_GridConsumption 0 Wh
setstate SolarForecast 2025-04-04 06:00:04 Today_Hour07_PVreal 0 Wh
setstate SolarForecast 2025-04-04 07:00:04 Today_Hour08_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 07:00:04 Today_Hour08_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 07:00:04 Today_Hour08_GridConsumption 0 Wh
setstate SolarForecast 2025-04-04 00:00:26 Today_Hour08_PVforecast 22 Wh
setstate SolarForecast 2025-04-04 07:00:04 Today_Hour08_PVreal 0 Wh
setstate SolarForecast 2025-04-04 08:00:04 Today_Hour09_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 08:00:04 Today_Hour09_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 08:59:40 Today_Hour09_GridConsumption 1907 Wh
setstate SolarForecast 2025-04-04 07:00:26 Today_Hour09_PVforecast 85 Wh
setstate SolarForecast 2025-04-04 08:00:04 Today_Hour09_PVreal 0 Wh
setstate SolarForecast 2025-04-04 09:00:04 Today_Hour10_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 09:00:04 Today_Hour10_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 09:59:16 Today_Hour10_GridConsumption 371 Wh
setstate SolarForecast 2025-04-04 07:00:26 Today_Hour10_PVforecast 169 Wh
setstate SolarForecast 2025-04-04 09:00:04 Today_Hour10_PVreal 0 Wh
setstate SolarForecast 2025-04-04 10:00:04 Today_Hour11_BatIn_01 0 Wh
setstate SolarForecast 2025-04-04 10:00:04 Today_Hour11_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 10:59:49 Today_Hour11_GridConsumption 265 Wh
setstate SolarForecast 2025-04-04 07:00:26 Today_Hour11_PVforecast 370 Wh
setstate SolarForecast 2025-04-04 10:00:04 Today_Hour11_PVreal 0 Wh
setstate SolarForecast 2025-04-04 11:54:47 Today_Hour12_BatIn_01 729 Wh
setstate SolarForecast 2025-04-04 11:00:04 Today_Hour12_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 11:59:27 Today_Hour12_GridConsumption 387 Wh
setstate SolarForecast 2025-04-04 07:00:26 Today_Hour12_PVforecast 527 Wh
setstate SolarForecast 2025-04-04 11:00:04 Today_Hour12_PVreal 0 Wh
setstate SolarForecast 2025-04-04 12:59:49 Today_Hour13_BatIn_01 11953 Wh
setstate SolarForecast 2025-04-04 12:00:04 Today_Hour13_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 12:59:49 Today_Hour13_GridConsumption 266 Wh
setstate SolarForecast 2025-04-04 07:00:26 Today_Hour13_PVforecast 654 Wh
setstate SolarForecast 2025-04-04 12:00:04 Today_Hour13_PVreal 0 Wh
setstate SolarForecast 2025-04-04 13:59:31 Today_Hour14_BatIn_01 5540 Wh
setstate SolarForecast 2025-04-04 13:00:04 Today_Hour14_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 13:59:31 Today_Hour14_GridConsumption 391 Wh
setstate SolarForecast 2025-04-04 13:00:08 Today_Hour14_PVforecast 732 Wh
setstate SolarForecast 2025-04-04 13:00:04 Today_Hour14_PVreal 0 Wh
setstate SolarForecast 2025-04-04 14:02:47 Today_Hour15_BatIn_01 0 Wh (WARNING invalid BatIn Energy occured - see Logfile)
setstate SolarForecast 2025-04-04 14:00:04 Today_Hour15_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 14:59:06 Today_Hour15_GridConsumption 265 Wh
setstate SolarForecast 2025-04-04 13:00:08 Today_Hour15_PVforecast 732 Wh
setstate SolarForecast 2025-04-04 14:00:04 Today_Hour15_PVreal 0 Wh
setstate SolarForecast 2025-04-04 15:48:06 Today_Hour16_BatIn_01 5 Wh
setstate SolarForecast 2025-04-04 15:00:04 Today_Hour16_BatOut_01 0 Wh
setstate SolarForecast 2025-04-04 15:51:36 Today_Hour16_GridConsumption 364 Wh
setstate SolarForecast 2025-04-04 13:00:08 Today_Hour16_PVforecast 674 Wh
setstate SolarForecast 2025-04-04 15:00:04 Today_Hour16_PVreal 0 Wh
setstate SolarForecast 2025-04-04 13:00:08 Today_Hour17_PVforecast 536 Wh
setstate SolarForecast 2025-04-04 13:00:08 Today_Hour18_PVforecast 331 Wh
setstate SolarForecast 2025-04-04 07:00:26 Today_Hour19_PVforecast 166 Wh
setstate SolarForecast 2025-04-04 07:00:26 Today_Hour20_PVforecast 33 Wh
setstate SolarForecast 2025-04-04 13:01:18 Today_MaxPVforecast 732 Wh
setstate SolarForecast 2025-04-04 00:00:26 Today_MaxPVforecastTime 2025-04-04 13:00:00
setstate SolarForecast 2025-04-04 13:00:08 Today_PVforecast 5031 Wh
setstate SolarForecast 2025-04-04 00:00:04 Today_PVreal 0 Wh
setstate SolarForecast 2025-04-04 00:00:04 Today_SunRise 06:55
setstate SolarForecast 2025-04-04 00:00:04 Today_SunSet 20:01
setstate SolarForecast 2025-04-04 12:00:37 Tomorrow_ConsumptionForecast 33265551 Wh
setstate SolarForecast 2025-04-04 15:00:16 Tomorrow_PVforecast 4173 Wh
setstate SolarForecast 2025-04-04 00:00:04 Tomorrow_SunRise 06:53
setstate SolarForecast 2025-04-04 00:00:04 Tomorrow_SunSet 20:02
setstate SolarForecast 2025-04-04 15:51:36 nextCycletime 15:52:46
setstate SolarForecast 2025-04-03 18:52:57 pvCorrectionFactor_Auto on_complex_ai
setstate SolarForecast 2025-04-03 13:49:28 setupStringAzimuth Balkon=-4 Kellerdach=83
setstate SolarForecast 2025-04-01 21:45:38 setupStringDeclination Balkon=90 Kellerdach=35
setstate SolarForecast 2025-04-04 15:51:36 special_SunHours_Remain 4.16
setstate SolarForecast 2025-04-04 15:51:36 special_SunMinutes_Remain 249
setstate SolarForecast 2025-04-04 15:50:26 special_todayBatInSum -135586.5 Wh
setstate SolarForecast 2025-04-04 15:51:37 state updated
define Solarbatterie_SF dummy
attr Solarbatterie_SF comment pin Reading welches die aktuelle Batterieladung liefert\
pout Reading welches die aktuelle Batterieentladung liefert\
intotal Reading welches die totale Batterieladung liefert (fortlaufender Zähler)\
outtotal Reading welches die totale Batterieentladung liefert (fortlaufender Zähler)\
charge Reading welches den aktuellen Ladezustand (in Prozent) liefert\
Einheit die jeweilige Einheit (W,Wh,kW,kWh)
attr Solarbatterie_SF event-on-change-reading .*
attr Solarbatterie_SF stateFormat charge %
attr Solarbatterie_SF timestamp-on-change-reading .*
attr Solarbatterie_SF userReadings PowerOut:pout.* integral {ReadingsVal($name,"pout",0) / 60},\
PowerOut_Wh {sprintf("%.1f",ReadingsVal($name,"PowerOut",0) / 60) }
# FUUID 67ec4695-f33f-b65a-57e3-a05bd1ebcbf4cb33
# NAME Solarbatterie_SF
# NR 421
# STATE 5.8 %
# TYPE dummy
# eventCount 284
# READINGS:
# 2025-04-01 18:48:27 PoverOut 0
# 2025-04-01 18:50:30 PowerOut 0
# 2025-04-01 18:49:42 PowerOut_Wh 0.0
# 2025-04-04 13:03:02 cap 1000
# 2025-04-04 15:52:03 charge 5.8
# 2025-04-04 15:53:03 intotal 57.6
# 2025-04-02 13:48:53 outtotal 0
# 2025-04-04 15:53:03 pin 462.6
# 2025-04-02 13:48:53 pout 0
#
setstate Solarbatterie_SF 5.8 %
setstate Solarbatterie_SF 2025-04-01 18:48:27 PoverOut 0
setstate Solarbatterie_SF 2025-04-01 18:50:30 PowerOut 0
setstate Solarbatterie_SF 2025-04-01 18:49:42 PowerOut_Wh 0.0
setstate Solarbatterie_SF 2025-04-04 13:03:02 cap 1000
setstate Solarbatterie_SF 2025-04-04 15:52:03 charge 5.8
setstate Solarbatterie_SF 2025-04-04 15:53:03 intotal 57.6
setstate Solarbatterie_SF 2025-04-02 13:48:53 outtotal 0
setstate Solarbatterie_SF 2025-04-04 15:53:03 pin 462.6
setstate Solarbatterie_SF 2025-04-02 13:48:53 pout 0
Da ist ein Syntaxfehler:
charge:charge -> charge=charge
LG,
Heiko
Hallo Heiko,
Wald....Bäume....
Ich hab den Fehler tatsächlich in zwei Instanzen und sehe ihn seit drei Tage nicht.
Vielen lieben Dank
LG mi.ke
Hallo @all,
soeben habe ich das Major Release 1.50.0 eingecheckt und ist morgen früh im Regelupdate enthalten.
Die V ist ebenfalls in meinem contrib sofort verfügbar.
Enthalten sind die Changes von V 1.49.1 - 1.49.5 sowie die folgenden weiteren Changes (inkl 1.49.6 Vorabversion):
- der Text des Home-Knotens ist ausgerichtet
- es gibt ein neues Attribut consumerControl mit dem Schlüssel dummyIcon um das Icon und die Farbe des Consumer Dummy anpassen zu können.
- ein inaktiver Consumer wird "grau" (wie die Laufkette in diesem Fall) dargestellt
- Verbesserung der Batterie Ladungsfreigabe wenn die aktuell festgestellte Netzeinspeisung über plantControl->feedinPowerLimit liegt
- Ersatz Attribut consumerAdviceIcon durch consumerControl->adviceIcon
- Ersatz Attribut consumerLegend durch consumerControl->showLegend
- Ersatz Attribut consumerLink durch consumerControl->detailLink
Es wäre wichtig das Update zeitnah durchzuführen, damit die automatische Umsetzung der Attribute vorgenommen wird bevor ich in einem nächsten Major Release die alten Attribute komplett entferne.
Wer die V aus dem contrib benutzt, bitte wie gewöhnlich nach dem Download FHEM restarten.
LG,
Heiko
Hallo,
ich habe das Modul bei meinen Eltern in Betrieb gonommen und die Werte für die PV Anlage sieht soweit gut aus.
Was ich aber nicht wirklich hinbekomme ist den Hichi Zähler einzubinden für den Energiefluss.
Hat jemand schon einen solchen eingebunden?
Gruß
Carsten
Hast du den den Hitchi schon in Fhem?
Ich habe ein bitShake mi Tasmota und ihn so eingebunden:
attr SolarForecast setupMeterDev Smartmeter_2E1F50 gcon=APOX_Power:W contotal=APOX_E_in:kWh gfeedin=-gcon feedtotal=APOX_E_out:kWh
Gruß schwatter
Hallo Heiko, hallo grappa24,
Zitat von: DS_Starter am 04 April 2025, 10:11:59Habe ich bei mir gleich übernommen. :)
ich auch. ^^
@Heiko: Gibt es eigentlich einen Wert für den "Verbrauch" des dummy, anhand dessen die Linie eingefärbt wird?
Schönen Sonntag noch!
VIele Grüße,
Peter
Zitat von: schwatter am 06 April 2025, 14:43:53Hast du den den Hitchi schon in Fhem?
Ich habe ein bitShake mi Tasmota und ihn so eingebunden:
attr SolarForecast setupMeterDev Smartmeter_2E1F50 gcon=APOX_Power:W contotal=APOX_E_in:kWh gfeedin=-gcon feedtotal=APOX_E_out:kWh
Gruß schwatter
Super.
Das gfeedin=-gcon war was ich falsch hatte.
gruß
Carsten
Hallo habe gerade auf Version 50 aktualiersiet major release: jetzt erhalte ich im LOG alle 30sec:
Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
conForecastTillNextSunrise' has no Parameter or default value set. Set the attribute again or inform Maintainer.
Was kann ich machen?
Kontrollieren des Settings des attr ist die erste Möglichkeit 😉
Hallo liebe Entwickler,
erst mal danke für die Arbeit.
Ich habe einen kleinen Änderungsvorschlag/-wunsch:
Wäre es für euch möglich unter dem Attribut "ctrlSpecialReadings" noch "tomorrowConsumptionForecast" (stundenweise Vorhersage analog zu todayConsumptionForecast) hinzuzufügen?
Vor allem, wenn die Unterscheidung nach Wochentagen aktiv ist, unterscheiden sich die stündlichen Verbrauchsprognosen teilweise von denen des aktuellen Tages. Aktuell bleibt nur die Möglichkeit den Tageswert aus dem Reading Tomorrow_ConsumptionForecast zu verwenden. Bei einzelnen Stunden in denen regelmäßig das E-Auto geladen wird, ist das leider etwas zu ungenau für weitergehende Berechnungen.
Sebastian
@Peter,
Zitat@Heiko: Gibt es eigentlich einen Wert für den "Verbrauch" des dummy, anhand dessen die Linie eingefärbt wird?
Bin mir nicht ganz sicher was genau du meinst. Es gibt kein Reading für diesen Wert. Dieser Wert wird dynamisch aus dem Gesamtverbrauch minus der vom Modul ermittelten Verbräuche der registrierten Verbraucher berechnet.
@Sebastian
ZitatWäre es für euch möglich unter dem Attribut "ctrlSpecialReadings" noch "tomorrowConsumptionForecast" (stundenweise Vorhersage analog zu todayConsumptionForecast) hinzuzufügen?
Das gibt es bereits mit dem Attr ctrlNextDayForecastReadings. Historisch bedingt ist es leider z.Zt. nicht Bestandteil von ctrlSpecialReadings. Das wäre noch eine Aufgabe für mich zur Vereinheitlichung. Aber die Funktionalistät ist damit gegeben.
LG,
Heiko
Zitat von: DS_Starter am 06 April 2025, 23:08:42@Sebastian
ZitatWäre es für euch möglich unter dem Attribut "ctrlSpecialReadings" noch "tomorrowConsumptionForecast" (stundenweise Vorhersage analog zu todayConsumptionForecast) hinzuzufügen?
Das gibt es bereits mit dem Attr ctrlNextDayForecastReadings. Historisch bedingt ist es leider z.Zt. nicht Bestandteil von ctrlSpecialReadings. Das wäre noch eine Aufgabe für mich zur Vereinheitlichung. Aber die Funktionalistät ist damit gegeben.
LG,
Heiko
Das Attr ctrlNextDayForecastReadings habe ich gesetzt. Es erstellt aber nur die Readings Tomorrow_HourXX_PVforecast. Ich meinte die Vorhersage der stündlichen Verbrauchswerte, die ja als Readings special_todayConsumptionForecast_XX für den aktuellen Tag ausgegeben werden, auch noch für den Folgetag. In der Balkengrafik zeigt es ja die stündliche Vorhersage für den Folgetag an. Daher müssten die Werte ja schon irgendwo vorhanden sein.
War nur als Anregung und weiterer Punkt auf der ToDo-Liste gedacht.
LG
Sebastian
Hallo Sebastian,
ZitatIch meinte die Vorhersage der stündlichen Verbrauchswerte
Ach ja sorry, da habe ich zu schnell drübergelesen. Das muss ich mir anschauen.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 06 April 2025, 23:08:42@Peter,
Zitat@Heiko: Gibt es eigentlich einen Wert für den "Verbrauch" des dummy, anhand dessen die Linie eingefärbt wird?
Bin mir nicht ganz sicher was genau du meinst. Es gibt kein Reading für diesen Wert. Dieser Wert wird dynamisch aus dem Gesamtverbrauch minus der vom Modul ermittelten Verbräuche der registrierten Verbraucher berechnet.
ja, ich hab mich unklar ausgedrückt.
Ich beziehe mich auf die Nennleistung der registrierten Verbraucher (attr consumerXX -> Key "power"). Kann ich für den Dummy auch eine Dummy-"Nennleistung" angeben, ab der die Linie rot eingefärbt wird?
Viele Grüße,
Peter
Wurde was geändert seitens Openmeteo? Habe ich was verpennt?
Bekomme seit einiger Zeit ab ca. 20-21Uhr folgende log-Einträge.
ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
@Peter,
ZitatKann ich für den Dummy auch eine Dummy-"Nennleistung" angeben, ab der die Linie rot eingefärbt wird?
Das ist zur Zeit nicht einstellbar, für alle Verbraucher nicht. Vllt. kann ich da etwas machen, mal schauen.
@kask,
ZitatWurde was geändert seitens Openmeteo? Habe ich was verpennt?
Nein, weder noch. Ich vermute das hängt mit einer etwas unglücklichen Zeit des Sonnenuntergangs zusammen. OpenMeteo Ensemble hat ein hohes Call Equivalent und verbraucht viele Credits. Die Grenze sind 8000 Credits pro Tag. Im Kopf oben rechts siehst du die verbrauchten und noch verfügbaren Credits, zB. (3160/4840).
Ich schau mal ob ich es besser hinbekomme.
LG,
Heiko
Ok, ich beobachte das mal weiter.
So jetzt ging es wieder los.
2025.04.07 20:54:50 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 20:56:49 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 20:58:48 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 20:59:49 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:00:04 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:00:47 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:02:46 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:04:45 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:06:44 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:08:43 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:10:42 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:12:41 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:14:40 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:16:39 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:18:38 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:20:37 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:22:36 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:24:35 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:26:34 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:28:33 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:30:32 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
2025.04.07 21:32:31 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum OMETMAXREQ daily API requests is reached or already exceeded. Process is exited.
Wobei die anderen Openmeteo API's den Fehler nicht ausgeben. Ich kann da heute auch nicht sehen wieviele Anfragen es in wirklichkeit waren da ich FHEM neu gestartet habe.
Danke, ich glaube die Stelle schon gefunden zu haben die etwas ärgert.
Ich habe die V 1.50.1 in mein contrib geladen. Außer dieser Problemlösung enthält die V noch eine Erweiterung.
Der Setter pvCorrectionFactor_Auto hat nun die auswählbare Option "on_complex_api_ai".
on_complex_ai verwendet ja die API-Ergebnisse wobei bei einem AI Hit die KI Ergebnisse verwendet werden. Es ist allerdings nicht unbedingt gesagt, dass KI immer der bessere Wert ist.
Diese neue Option verwendet sowohl den API und KI-Wert und bildet aus beiden Treffern den Durchschnitt als effektive Vorhersage.
LG,
Heiko
Zitat von: TheTrumpeter am 27 März 2025, 09:29:44Wurde die Limitierung auf die WR-Max-Leistung in der Prognose schon umgesetzt?
Heute um 12:00 sollen wieder über 16kWh vom Dach kommen, obwohl mein WR auf 15kW limitiert ist.
(Nutze noch die 1.48.0...)
Zitat von: tomcat.x am 27 März 2025, 09:58:51Das ist in der 1.49 umgesetzt:
https://forum.fhem.de/index.php?msg=1337341 (https://forum.fhem.de/index.php?msg=1337341)
Ich will ja nicht lästig sein, aber mit der 1.50 wird wieder mehr als 15 kWh prognostiziert, heute in der 12. Stunde sollen über 16 kWh vom Dach kommen:
12 => pvapifc: 16147, pvaifc: -, pvfc: 16147, aihit: 0, pvrl: 4230
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
confc: 2023, gcon: 314, gfeedin: 2327, wcc: 99, rr1c: 0.00
temp: 8.50, wid: 3, wtxt: -
pprl01: -, pprl02: -, pprl03: -
pvcorrf: 5.100=0.91 5.15=0.97 5.20=1.11 5.30=1.07 5.35=1.06 5.40=0.98 5.45=1.08 5.50=0.40 5.55=1.16 5.60=0.85
5.65=1.09 5.70=1.18 5.75=1.10 5.80=0.83 5.85=1.28 5.90=1.32 5.95=1.59 10.100=0.91 10.15=0.97 10.20=1.11
10.30=1.07 10.35=1.06 10.40=0.98 10.45=1.08 10.50=0.40 10.55=1.16 10.60=0.85 10.65=1.09 10.70=1.18 10.75=1.10
10.80=0.83 10.85=1.28 10.90=1.32 10.95=1.59 15.100=0.91 15.15=0.97 15.20=1.11 15.30=1.07 15.35=1.06 15.40=0.98
15.45=1.08 15.50=0.40 15.55=1.16 15.60=0.85 15.65=1.09 15.70=1.18 15.75=1.10 15.80=0.83 15.85=1.28 15.90=1.32
15.95=1.59 20.00=1.07 20.100=0.75 20.10=1.14 20.15=1.17 20.20=1.11 20.30=0.74 20.35=1.17 20.40=0.98 20.45=0.72
20.50=0.65 20.55=1.15 20.60=0.85 20.65=0.95 20.70=0.90 20.75=0.96 20.80=0.91 20.85=1.04 20.90=1.07 20.95=1.00
25.00=0.96 25.05=0.94 25.10=1.12 25.100=1.00 25.15=0.96 25.20=1.11 25.30=1.07 25.35=1.06 25.40=1.25 25.45=1.03
25.50=0.40 25.55=1.16 25.60=1.07 25.65=1.08 25.70=1.18 25.75=1.10 25.80=0.83 25.85=1.28 25.90=1.14 25.95=0.75
30.00=1.03 30.100=0.86 30.10=0.96 30.15=1.13 30.20=1.11 30.25=1.09 30.30=1.07 30.35=1.06 30.40=0.98 30.45=1.08
30.50=0.77 30.55=1.16 30.60=0.85 30.65=1.04 30.70=1.18 30.75=1.14 30.80=1.16 30.85=1.02 30.90=1.03 30.95=1.33
35.00=0.97 35.10=0.92 35.100=0.83 35.15=1.02 35.20=1.06 35.25=0.91 35.30=1.07 35.35=1.02 35.40=0.98 35.45=1.05
35.50=0.40 35.55=1.16 35.60=1.10 35.65=1.04 35.70=1.15 35.75=1.10 35.80=1.20 35.85=1.06 35.90=1.20 35.95=1.31
40.00=0.99 40.100=0.74 40.15=1.00 40.20=1.06 40.25=0.99 40.30=1.07 40.35=1.06 40.40=1.05 40.45=1.08 40.50=0.78
40.55=1.16 40.60=0.93 40.65=0.97 40.70=1.18 40.75=1.09 40.80=0.87 40.85=0.66 40.90=0.73 40.95=1.59 45.00=0.94
45.05=1.02 45.10=0.99 45.100=1.31 45.15=1.04 45.20=0.96 45.25=1.02 45.30=1.04 45.35=1.07 45.40=0.94 45.45=1.08
45.50=0.40 45.55=1.12 45.60=0.85 45.65=0.89 45.70=1.48 45.75=0.68 45.80=0.93 45.85=1.48 45.90=1.32 45.95=1.14
50.00=1.00 50.05=1.01 50.100=1.03 50.10=1.02 50.35=1.05 50.45=1.02 50.50=1.09 50.75=0.94 50.80=0.99 50.85=1.16
50.95=1.03 55.00=1.03 55.05=1.02 55.100=1.00 55.15=0.84 55.35=1.08 55.40=0.97 55.45=0.99 55.50=1.00 55.55=1.04
55.65=1.02 55.70=1.07 55.75=1.06 55.85=1.18 55.95=0.81 60.00=1.00 60.05=1.03 60.100=1.07 60.15=1.02 60.20=1.00
60.25=1.01 60.30=0.86 60.35=1.03 60.45=1.08 60.55=0.94 60.60=1.02 60.65=1.01 60.75=1.34 60.80=1.21 60.85=1.15
60.90=1.01 60.95=1.18
simple=1.01
quality: 5.100=0.93 5.15=0.92 5.20=0.98 5.30=0.99 5.35=0.89 5.40=0.97 5.45=0.96 5.50=0.00 5.55=0.87 5.60=0.83
5.65=0.92 5.70=0.77 5.75=0.91 5.80=0.97 5.85=0.78 5.90=0.76 5.95=0.63 10.100=0.93 10.15=0.92 10.20=0.98
10.30=0.99 10.35=0.89 10.40=0.97 10.45=0.96 10.50=0.00 10.55=0.87 10.60=0.83 10.65=0.92 10.70=0.77 10.75=0.91
10.80=0.97 10.85=0.78 10.90=0.76 10.95=0.63 15.100=0.93 15.15=0.92 15.20=0.98 15.30=0.99 15.35=0.89 15.40=0.97
15.45=0.96 15.50=0.00 15.55=0.87 15.60=0.83 15.65=0.92 15.70=0.77 15.75=0.91 15.80=0.97 15.85=0.78 15.90=0.76
15.95=0.63 20.00=0.93 20.10=0.78 20.100=0.67 20.15=0.72 20.20=0.98 20.30=0.64 20.35=0.85 20.40=0.97 20.45=0.00
20.50=0.46 20.55=0.87 20.60=0.83 20.65=0.95 20.70=0.39 20.75=0.95 20.80=0.90 20.85=0.97 20.90=0.93 20.95=1.00
25.00=0.96 25.05=0.94 25.100=1.00 25.10=0.90 25.15=0.94 25.20=0.98 25.30=0.99 25.35=0.89 25.40=0.80 25.45=0.98
25.50=0.00 25.55=0.87 25.60=0.94 25.65=0.92 25.70=0.77 25.75=0.91 25.80=0.97 25.85=0.78 25.90=0.88 25.95=0.66
30.00=0.97 30.10=0.96 30.100=0.84 30.15=0.88 30.20=0.98 30.25=0.85 30.30=0.99 30.35=0.89 30.40=0.97 30.45=0.96
30.50=0.70 30.55=0.87 30.60=0.83 30.65=0.96 30.70=0.77 30.75=0.87 30.80=0.86 30.85=0.98 30.90=0.97 30.95=0.75
35.00=0.96 35.100=0.80 35.10=0.91 35.15=0.98 35.20=0.99 35.25=0.90 35.30=0.99 35.35=0.98 35.40=0.97 35.45=0.98
35.50=0.00 35.55=0.87 35.60=0.91 35.65=0.96 35.70=0.89 35.75=0.91 35.80=0.83 35.85=0.95 35.90=0.83 35.95=0.76
40.00=0.99 40.100=0.65 40.15=1.00 40.20=0.99 40.25=0.99 40.30=0.99 40.35=0.89 40.40=0.95 40.45=0.96 40.50=0.72
40.55=0.87 40.60=0.92 40.65=0.97 40.70=0.77 40.75=0.91 40.80=0.86 40.85=0.47 40.90=0.62 40.95=0.63 45.00=0.93
45.05=0.95 45.100=0.76 45.10=0.99 45.15=0.97 45.20=0.95 45.25=0.98 45.30=0.98 45.35=0.93 45.40=0.93 45.45=0.96
45.50=0.00 45.55=0.89 45.60=0.83 45.65=0.88 45.70=0.68 45.75=0.53 45.80=0.92 45.85=0.68 45.90=0.76 45.95=0.88
50.00=1.00 50.05=0.99 50.10=0.96 50.100=0.97 50.35=0.91 50.45=0.96 50.50=0.84 50.75=0.87 50.80=0.98 50.85=0.76
50.95=0.94 55.00=0.97 55.05=0.97 55.100=1.00 55.15=0.81 55.35=0.85 55.40=0.92 55.45=0.99 55.50=1.00 55.55=0.92
55.65=0.97 55.70=0.87 55.75=0.88 55.85=0.85 55.95=0.76 60.00=1.00 60.05=0.94 60.100=0.94 60.15=0.97 60.20=1.00
60.25=0.98 60.30=0.83 60.35=0.94 60.45=0.93 60.55=0.94 60.60=0.98 60.65=0.98 60.75=0.74 60.80=0.71 60.85=0.87
60.90=0.99 60.95=0.84
simple=0.99
pvrlsum: simple=2983162
pvfcsum: simple=2966470
dnumsum: simple=416
con_all => Sun @ 3374 3245 2361 3335 895 2723 1204 1854
Wed @ 2811 2226 2023 2377 672 1223 2673 757 1583
Sat @ 3417 3004 3479 3068 1588 2408 980 1637
Fri @ 2966 3352 2222 2678 556 2416 1975
Mon @ 2641 1973 2385 2470 170 1268 1622 457 561
Tue @ 2526 2258 2255 2270 2353 663 2252
Thu @ 2954 2171 2415 2510 564 1909 544 194 679
pvrl_10 => 35 @ 8790
50 @ 3640
55 @ 6505
60 @ 5955
65 @ 8965
75 @ 4783
80 @ 6250
85 @ 3795
90 @ 3258
95 @ 3243
pvrl_15 => 35 @ 8790
50 @ 3640
55 @ 6505
60 @ 5955
65 @ 8965
75 @ 4783
80 @ 6250
85 @ 3795
90 @ 3258
95 @ 3243
pvrl_20 => 00 @ 6047
10 @ 6040
15 @ 6850
30 @ 3620
35 @ 8020
45 @ 1810
50 @ 4393
55 @ 6287
60 @ 5955
65 @ 5915
70 @ 2810
75 @ 4508
80 @ 3238 3269
85 @ 4107
90 @ 3056
95 @ 2605
100 @ 1422 719 850 1120 850
pvrl_25 => 00 @ 4690 7540 8040 7909 7790
05 @ 7960
10 @ 7220
15 @ 5950
35 @ 8790
40 @ 7309
45 @ 6970
50 @ 3640
55 @ 6505
60 @ 6657 7170
65 @ 8180
75 @ 4783
80 @ 6250
85 @ 3795
90 @ 3258 7750 1210 6139
95 @ 4098 4390 7550
100 @ 1606 5860 5779 2230 3989 8800
pvrl_30 => 00 @ 7745 9580 9710 9520
10 @ 9610 9100
15 @ 8915
25 @ 9360
35 @ 8790
50 @ 5942
55 @ 6505
60 @ 5955
65 @ 8965 8960
75 @ 6138
80 @ 7120
85 @ 4974 7470
90 @ 3245
95 @ 4195
100 @ 2255 1569 1320 4229 3730 3200 1500 1940
pvrl_35 => 00 @ 10970 10260 10200 10300 10320
10 @ 10070
15 @ 10140
20 @ 10120
25 @ 9740
35 @ 9490
45 @ 10400
50 @ 3640
55 @ 6505
60 @ 5690 8990
65 @ 9143
70 @ 8790
75 @ 4783
80 @ 7540
85 @ 4082
90 @ 3642
95 @ 3732
100 @ 3611 2820 9680 7060
pvrl_40 => 00 @ 10560 11660 12400 11910
15 @ 10740
20 @ 11560
25 @ 11860
35 @ 8790
40 @ 11067
50 @ 6688
55 @ 6505
60 @ 8156
65 @ 8060
75 @ 4612
80 @ 7328
85 @ 3795 5590 4500
90 @ 3258 8160
95 @ 3243
100 @ 2818 7860 2500 8430 4360 1810
pvrl_45 => 00 @ 10692 12110 11690
05 @ 12170
10 @ 10700
15 @ 10180
20 @ 11480
25 @ 10810
30 @ 11940
35 @ 10220
40 @ 10130
50 @ 3640
55 @ 9515
60 @ 5955
65 @ 6998 7840
70 @ 8850
75 @ 4783 5700
80 @ 8100
85 @ 6955 11020 10440
90 @ 3258
95 @ 4698
100 @ 7389 6640 3990 1180 9720
pvrl_5 => 35 @ 8790
50 @ 3640
55 @ 6505
60 @ 5955
65 @ 8965
75 @ 4783
80 @ 6250
85 @ 3795
90 @ 3258
95 @ 3243
pvrl_50 => 00 @ 10957
05 @ 11790
10 @ 11430
35 @ 13540
45 @ 12520
50 @ 11220
75 @ 6600
80 @ 7300
85 @ 12890
95 @ 7730
100 @ 7743
pvrl_55 => 00 @ 13335
05 @ 12350
15 @ 9695
35 @ 12530
40 @ 11020
45 @ 11282
50 @ 10588
55 @ 13290
65 @ 8960
70 @ 12250
75 @ 12190
85 @ 11345
95 @ 4930
100 @ 7043
pvrl_60 => 00 @ 12808
05 @ 12620
15 @ 13160
20 @ 12050
25 @ 12800
30 @ 10015
35 @ 12990
45 @ 11955
55 @ 10880
60 @ 11400
65 @ 11600
75 @ 12060
80 @ 11240
85 @ 9800
90 @ 8980
95 @ 8435
100 @ 9375
pvfc_10 => 35 @ 7848
50 @ 9144
55 @ 5630
60 @ 6997
65 @ 8221
75 @ 4337
80 @ 6425
85 @ 2960
90 @ 2465
95 @ 2043
pvfc_15 => 35 @ 7848
50 @ 9144
55 @ 5630
60 @ 6997
65 @ 8221
75 @ 4337
80 @ 6425
85 @ 2960
90 @ 2465
95 @ 2043
pvfc_20 => 00 @ 5647
10 @ 4702
15 @ 4953
30 @ 4922
35 @ 6857
45 @ 5190
50 @ 6752
55 @ 5483
60 @ 6997
65 @ 6210
70 @ 4517
75 @ 4718
80 @ 4121 3048
85 @ 3967
90 @ 2850
95 @ 2615
100 @ 1665 2089 738 1127 824
pvfc_25 => 00 @ 6856 5266 8199 8573 8075
05 @ 8472
10 @ 6474
15 @ 6295
35 @ 7848
40 @ 5835
45 @ 7139
50 @ 9144
55 @ 5630
60 @ 6460 6505
65 @ 7556
75 @ 4337
80 @ 6425
85 @ 2960
90 @ 2465 9802 3112 5116
95 @ 4064 5866 6287
100 @ 1973 3809 4358 5366 7046 6460
pvfc_30 => 00 @ 7450 10317 9443 9088
10 @ 8618 10846
15 @ 7886
25 @ 7920
35 @ 7848
50 @ 7697
55 @ 5630
60 @ 6997
65 @ 8221 8997
75 @ 5362
80 @ 6128
85 @ 5005 7203
90 @ 3163
95 @ 3156
100 @ 2590 2159 1225 4926 3078 3612 2177 2262
pvfc_35 => 00 @ 9864 11371 10252 10664 10794
10 @ 10998
15 @ 9985
20 @ 10067
25 @ 10736
35 @ 9287
45 @ 10232
50 @ 9144
55 @ 5630
60 @ 6772 6579
65 @ 8783
70 @ 7809
75 @ 4337
80 @ 6280
85 @ 3868
90 @ 3034
95 @ 2841
100 @ 3435 3270 9514 9402
pvfc_40 => 00 @ 10033 12806 11754 11967
15 @ 10773
20 @ 11452
25 @ 11971
35 @ 7848
40 @ 10552
50 @ 8576
55 @ 5630
60 @ 8794
65 @ 8286
75 @ 4218
80 @ 8386
85 @ 2960 8558 6869
90 @ 2465 13240
95 @ 2043
100 @ 2374 6152 3528 6765 12861 1816
pvfc_45 => 00 @ 10591 12912 12476
05 @ 11609
10 @ 10848
15 @ 9826
20 @ 11997
25 @ 10590
30 @ 11705
35 @ 9550
40 @ 10828
50 @ 9144
55 @ 8463
60 @ 6997
65 @ 7990 8693
70 @ 5987
75 @ 4337 11106
80 @ 8751
85 @ 6169 7072 11674
90 @ 2465
95 @ 4118
100 @ 7308 4933 5065 2206 8525
pvfc_5 => 35 @ 7848
50 @ 9144
55 @ 5630
60 @ 6997
65 @ 8221
75 @ 4337
80 @ 6425
85 @ 2960
90 @ 2465
95 @ 2043
pvfc_50 => 00 @ 10954
05 @ 11650
10 @ 10944
35 @ 12266
45 @ 11996
50 @ 9436
75 @ 7474
80 @ 7472
85 @ 9786
95 @ 7280
100 @ 7538
pvfc_55 => 00 @ 12958
05 @ 12022
15 @ 11548
35 @ 10664
40 @ 11860
45 @ 11434
50 @ 10612
55 @ 12162
65 @ 8682
70 @ 10658
75 @ 10756
85 @ 9596
95 @ 6117
100 @ 7065
pvfc_60 => 00 @ 12787
05 @ 11906
15 @ 12788
20 @ 12036
25 @ 12538
30 @ 11696
35 @ 12260
45 @ 11092
55 @ 11562
60 @ 11179
65 @ 11396
75 @ 8979
80 @ 7994
85 @ 8548
90 @ 8888
95 @ 7127
100 @ 8771Limitierung ist gesetzt:
attr mySolarForecast setupInverterDev01 myHuawei pv=Active_Power:W etotal=Accumulated_energy_yield:kWh capacity=15000 asynchron=1
In dem setupInverterDev01 gibt es die Zuordnung "strings=..." nicht. Dann "weiß" das Modul nicht welchen String es beschneiden soll.
Ich schau mal heute Abend ob ich etwas machen kann wenn nichts gesetzt ist. Ist eine programmtechnische Angelegenheit.
Edit: Setze bei dir bitte den Key "strings=...".
LG
Zitat von: DS_Starter am 09 April 2025, 11:13:34Edit: Setze bei dir bitte den Key "strings=...".
Habe ich jetzt mal gesetzt. Leider ist die Stunde schon um, d.h. ich seh' jetzt nicht mehr ob's was gebracht hätte.
Bisher war es nicht definiert, weil lt. CommandRef optional.
Ja, wie gesagt ich schau mal heute Abend wie ich es programmtechnisch hinbekomme wenn strings fehlt. Optional ist völlig richtig. Wenn es keiner Limitierung bedarf, arbeitet es aktuell so wie gewünscht auch ohne strings.
@all,
bei mir sind alle DWD_OpenData mit dem Datenstand: 2025-04-08 23:00:00 stehen geblieben. Die Updates der Devices laufen.
Es werden offensichtlich keine aktuelen Daten von DWD_OpenData geliefert.
Ist das bei euch auch so?
LG
Zitat von: DS_Starter am 09 April 2025, 12:46:31Es werden offensichtlich keine aktuelen Daten von DWD_OpenData geliefert.
Ist das bei euch auch so?
Nein, meine Station liefert Daten, zuletzt um 2025-04-09 13:53:38.
Tobi
Zitat von: DS_Starter am 09 April 2025, 12:46:31@all,
bei mir sind alle DWD_OpenData mit dem Datenstand: 2025-04-08 23:00:00 stehen geblieben. Die Updates der Devices laufen.
Es werden offensichtlich keine aktuelen Daten von DWD_OpenData geliefert.
Ist das bei euch auch so?
LG
Nein, hier auch alles i.O.
Viele Grüße!
Peter
Vielen Dank für die Infos, jetzt läufts bei mir auch wieder. Man muss nur drüber reden. :)
@all,
ich habe soeben die V 1.50.2 in mein contrib geladen.
- die Kapazität des Wechselrichters begrenzt die Leistung der Strings auch wenn keine explizite Zuordnung durch "strings=..." vorhanden ist. Es betrifft dann alle Strings, da ohne Zuordnung alle definierten Strings dem WR automatisch zugeordnet werden.
- das Attr ctrlSpecialReadings enthält die Option "tomorrowConsumptionForecast" um die stündliche Verbrauchsvorhersage für den kommenden Tag als Reading darzustellen
LG,
Heiko
Hallo,
habe ich irgendeinen Beitrag übersehen? Ich habe gerade 1.50.0 aktiv und kann zur Autokorrektur nur noch die Werte ohne AI auswählen (z.B. on_complex).
Ich habe nach dem Update von DWD auf OpenMeteo-D2 umgestellt, kann daher nicht sagen, ob das AI vorher oder nachher verschwunden ist.
Die Hilfetexte nennen weiterhin AI als Option. Wio habe ich das verloren bzw wo ist es verloren gegangen.
Gruß
Christian
@DS_Starter
Hallo Heiko,
...ich hätte da mal einen Wunsch.... O:-)
Wenn ich eine Version aus deinem Contrib lade / nutze / betreibe lasse ich die Updates aus gutem Grund immer ein paar Tage sein.
Manchmal gibt es da ja Umstellungen die nicht rückwärtskompatibel sind.
Wenn dann diese Updates zeitlich verzögert für alle bereitgestellt wurden, kann man nicht sehen welche Version grad heruntergeladen werden soll bzw. auch nicht welcher Versionstand grad bei mir in Nutzung ist.
Anhand der Dateigröße geht es zwar auf Umwegen, aber besser wäre wenn die Version die aktuell beim normalen Update geladen werden könnte und die Version die z.Z. bei mir aktiv in Nutzung ist beim "Zahnrad-Check" angezeigt werden würde.
Gruß
300P
Mit der Version 1.50.1 habe ich den Fehler immer noch:
2025.04.08 21:09:23 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.08 21:11:22 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.08 21:13:21 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.08 21:15:20 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
@kask, da miss ich nochmal genauer schauen. Wieviel Strings hast du insgesamt?
@300p, die aktuelle Version wird doch immer im ensprechenden Internal angezeigt. Ich kann sie auch noch im check vermerken.
Im Standard update schreibe ich die neue Version jetzt immer in den Update Text.
Reicht dir das so?
Lg
Das reicht so!
💪🙌👍
fünf Strings.
Zitat@kask, da miss ich nochmal genauer schauen. Wieviel Strings hast du insgesamt?
@cbl,
Zitathabe ich irgendeinen Beitrag übersehen? Ich habe gerade 1.50.0 aktiv und kann zur Autokorrektur nur noch die Werte ohne AI auswählen (z.B. on_complex).
Führe bitte den Anlagencheck aus und poste bitte die Ausgabe.
LG
@kask, was steht denn in deinem Reading nextRadiationAPICall?
Ich habe die V1.50.2 in meinem contrib aktualisiert.
- der Plantcheck entält in der Kopfzeile die aktuell eingesetzte Modulversion
@kask, wegen deiner Problematik habe ich etwas angepasst.
Um weiterzukommen stelle bitte ctrlDebug=apiCall ein. Wichtig sind dann diese Ausgaben:
Zitat2025.04.09 22:00:29.806 1: openMeteo1 DEBUG> Open-Meteo API Call - remaining API Requests: 4420, Request equivalents p. call: 20, new call interval: 900
....
2025.04.09 22:00:29.985 1: openMeteo1 DEBUG> Open-Meteo API Call - remaining API Requests: 4400, Request equivalents p. call: 20, new call interval: 900
....
Hier sieht man den Verlauf der API Requests und das daraus berechnete Call Intervall. Das letztere scheint bei dir zu kurz zu sein und deswegen die Credits zu schnell aufgebraucht zu sein.
LG,
Heiko
Hab ich eingestellt..jetzt ist es ja zu spät mit dem nextRadiationAPICall.
ich beobachte es heute abend mal.
Zitat von: DS_Starter am 09 April 2025, 22:10:26Ich habe die V1.50.2 in meinem contrib aktualisiert.
- der Plantcheck entält in der Kopfzeile die aktuell eingesetzte Modulversion
LG,
Heiko
Hallo Heiko,
das "Kommt" nicht so richtig - leider nur ein "-"-Zeichen. ;)
Informationen zur Anlagenkonfigurationsprüfung - Module Version: -, Model: OpenMeteoDWDAPI
Gruß nach einem langen Tag beim WP-Einbau / Inbetriebnahme / Stillegung der Brennstoffzelle....
300P
Das kann ich bestätigen.
Hmm - und warum klappt das bei mir problemlos?
Wie sieht denn euer Internal FVERSION aus?
bei mir klappts auch ...
FVERSION 76_SolarForecast.pm:v1.50.2-s29837/2025-04-09
So!
Dann ist bei dir/euch das Modul Meta.pm nicht geladen. Warum auch immer. Vllt. gibt es das bei euch nicht?
Passe die Auswertung an damit das auch dann klappt.
LG
Moin,
bevor ich etwas im Modul anpasse, schaut doch bitte bei euch ob es das Modul Meta.pm im Verz. ../FHEM nicht gibt. Das ist im FHEM Standard enthalten und müsste vorhanden sein.
LG
Hallo Heiko,
Zitat von: DS_Starter am 11 April 2025, 07:35:34schaut doch bitte bei euch ob es das Modul Meta.pm (https://meta.pm/) im Verz. ../FHEM nicht gibt.
Bei mir sieht es auch so aus:
screen.png
Und die Meta.pm ist da. Ich hab sie hier mal mit angehängt.
Das Internal FVERSION hat den Wert 1.50.2.
Viele Grüße,
Peter
Hallo Heiko,
ich habe nochmal drei Fragen zum Design. Siehe dazu bitte auch den Screenshot anbei.
1) Besteht die Möglichkeit, die Balkenhöhen der beiden Reihen aneinander anzupassen? Bei mir sind aktuell 3500 Wh Erzeugung (erste Reihe) wesentlich kleiner als 700 Wh Verbrauch (zweite Reihe). Ich habe schon mit den attr graphicBeamHeightLevelX gespielt, aber das ändert nichts.
2) Seit kurzem (vermutlich v.1.50) sind die Balkengrafiken unten (bei 0) nicht mehr an der gleichen Stelle. Zumindest im Chrome auf Windows 11. Im Chrome auf iOS sieht es noch korrekt aus. Ich glaube, dass die fettgedruckten negativen Werte dafür verantwortlich sind. Gab es dort eine Änderung?
3) Gibt es eine Konfigurationsmöglichkeit dafür, die Flow-Grafik über der Balkengrafik anzuzeigen?
Viele Grüße,
Peter
Guten Morgen,
Meta.pm ist bei mir vorhanden.
FHEM ist vor 2 Wochen komplett neu aufgesetzt worden (Bei mir war alles vom Heizungsbauer überflutet worden und alle Geräte k.o)
Version FHEM ist aktuell (V6.4)
Wie sieht denn dein Internal FVERSION aus?
Hallo Peter,
Zitat1) Besteht die Möglichkeit, die Balkenhöhen der beiden Reihen aneinander anzupassen? Bei mir sind aktuell 3500 Wh Erzeugung (erste Reihe) wesentlich kleiner als 700 Wh Verbrauch (zweite Reihe). Ich habe schon mit den attr graphicBeamHeightLevelX gespielt, aber das ändert nichts.
Nicht direkt. Der Platz wird automatisch ausgenutzt. Die Verhältnisse hängen auch von den Zusatzelementen ab (Wetter, Batterien). Du könntest z.B. die Anzeige det Bat in die zweite Ebene legen.
Edit: anbei ein Beispiel mit graphicBeamHeightLevel1=400 und graphicBeamHeightLevel2=200
Zitat2) Seit kurzem (vermutlich v.1.50) sind die Balkengrafiken unten (bei 0) nicht mehr an der gleichen Stelle. Zumindest im Chrome auf Windows 11. Im Chrome auf iOS sieht es noch korrekt aus. Ich glaube, dass die fettgedruckten negativen Werte dafür verantwortlich sind. Gab es dort eine Änderung?
Nein, an den Grafikelementen wurde nichts geändert. (Ich habe auch nicht verstanden was du genau meinst)
Zitat3) Gibt es eine Konfigurationsmöglichkeit dafür, die Flow-Grafik über der Balkengrafik anzuzeigen?
Zur Zeit nicht, das müsste ich einbauen falls es nicht zu große Umbauten erfordert.
LG,
Heiko
Zitat von: DS_Starter am 11 April 2025, 08:39:01Wie sieht denn dein Internal FVERSION aus?
1.50.2
Ok, danke. Ich weiß jetzt nicht warum Meta.pm in den Fällen so anders arbeitet wie bei mir.
Ich werde die Auswertung etwas ändern damit es in allen Fällen passt.
LG
Ich habe soeben die V 1.50.2 im contrib upgedatet. Damit sollte nun die Versionsanzeige im Check für alle User passen.
LG
Hallo Heiko,
danke für Deine Antworten.
Zitat von: DS_Starter am 11 April 2025, 09:01:33Nicht direkt. Der Platz wird automatisch ausgenutzt. Die Verhältnisse hängen auch von den Zusatzelementen ab (Wetter, Batterien). Du könntest z.B. die Anzeige det Bat in die zweite Ebene legen.
Edit: anbei ein Beispiel mit graphicBeamHeightLevel1=400 und graphicBeamHeightLevel2=200
Hierbei geht es mir darum, dass ein Balken für 1000 Wh in der ersten Zeile der Balkengrafik genauso hoch ist wie 1000Wh in der zweiten Zeile. Das werde ich mit statischer Konfiguration von Attributen sicher nicht realisieren können.
Vielleicht lässt sich das ja programmtechnisch umsetzen? (wenn die entsprechenden graphicBeamHeightLevelX nicht gesetzt sind)
Zitat von: DS_Starter am 11 April 2025, 09:01:33Nein, an den Grafikelementen wurde nichts geändert. (Ich habe auch nicht verstanden was du genau meinst)
Ich hänge hier nochmal einen Screenshot an und markiere die Stellen, die ich meine:
screen.png
Viele Grüße,
Peter
ZitatHierbei geht es mir darum, dass ein Balken für 1000 Wh in der ersten Zeile der Balkengrafik genauso hoch ist wie 1000Wh in der zweiten Zeile. Das werde ich mit statischer Konfiguration von Attributen sicher nicht realisieren können.
Verstehe. Das ließe sich mit entsprechenden Aufwand sicherlich machen, aber diese Abhängigkeit ist nicht gewünscht. Warum? Die Balken in einer Ebene sind in ihrer Höhe von dem Bereich abhängig in dem sie sich in dieser Ebene bewegen. D.h. wenn in der Ebene eine Min. / Max. Range von 30 / 100 vorhanden ist, wird man sehr gut die einzelnen Abstufungen der Zwischenwerte sehen. Ist in der zweiten Ebene dieser Min. / Max. Bereich z.B. zwischen 200 / 6000 vorhanden, wird man auch dort die Zwischenwerte gut sehen können. ABER setzt man die Ebenen in eine Abhängigkeit, wird man in der Ebene mit den 30 / 100 - Bereichswerten kaum Differenzen in den Balken sehen. Das wäre nicht gut.
ZitatIch hänge hier nochmal einen Screenshot an und markiere die Stellen, die ich meine
Ah ok. Der minimale Versatz tritt dann auf wenn man eine Diff-Anzeige einschaltet UND die Diff negativ ist. Ich sehe es im Mozilla auch, aber sehr gering, kaum wahrnehmbar. Kann ich momentan nichts dazu sagen, vllt. finde ich etwas.
LG,
Heiko
Zitat von: DS_Starter am 11 April 2025, 11:33:14ABER setzt man die Ebenen in eine Abhängigkeit, wird man in der Ebene mit den 30 / 100 - Bereichswerten kaum Differenzen in den Balken sehen. Das wäre nicht gut.
Das sehe ich ein. Wenn der Aufwand vertretbar wäre, könnte man das evtl. über die attr graphicBeamHeightLevelX konfigurierbar machen?
Viele Grüße,
Peter
Hallo ich habe folgendes Problem:
Ich habe ein SolarForecast Device bei dem ich auch das setupBatteryDev01 Attribut gesetzt habe.
Nun ist es so, dass im Reading 2025-04-11 12:22:47 Current_BatCharge_01 99 % angezeigt wird, die Grafik jedoch konstant bei 0% steht. Hat jemand eine Idee wo mein Fehler liegt?
setupBatteryDev01 solix2mqtt pin=scenInfo_solarbank_info_total_charging_power:W pout=scenInfo_solarbank_info_total_battery_power:W pinmax=1000 poutmax=800 cap=1600:Wh charge=scenInfo_solarbank_info_solarbank_list_1_battery_power show=1
Internals:
FUUID 67f8d4ce-f33f-3b45-7a60-052d0ec26a8a4874
FVERSION 76_SolarForecast.pm:v1.50.0-s29825/2025-04-05
LCACHEFILE last write time: 12:16:16 whole Operating Memory
MODE Automatic / Event-controlled - next planned Cycletime: 12:23:57
MODEL OpenMeteoDWDAPI
NAME solarForecast
NOTIFYDEV solix2mqtt
NR 461
NTFY_ORDER 50-solarForecat
STATE updated
TYPE SolarForecast
WEATHERMODEL OpenMeteoDWDAPI
eventCount 45
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV solarForecast
SPGROOM Energiezähler
VERSION 1.50.0
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 27
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:4729
telnet telnetPort_127.0.0.1_59318
terminated 1
timeout 30
abortArg:
arg:
block 1
name solarForecat
tsnext 1744370197.34916
OLDREADINGS:
READINGS:
2025-04-11 12:22:47 Current_AutarkyRate 100 %
2025-04-11 12:22:47 Current_BatCharge_01 99 %
2025-04-11 12:22:47 Current_Consumption 267 W
2025-04-11 12:22:47 Current_GridConsumption 0 W
2025-04-11 12:22:47 Current_GridFeedIn 412 W
2025-04-11 12:22:47 Current_PV 832 W
2025-04-11 12:22:47 Current_PowerBatIn_01 153 W
2025-04-11 12:22:47 Current_PowerBatOut_01 0 W
2025-04-11 12:22:47 Current_SelfConsumption 267 W
2025-04-11 12:22:47 Current_SelfConsumptionRate 32 %
2025-04-11 12:22:47 Current_Surplus 565 W
2025-04-11 12:00:00 LastHourGridconsumptionReal 10 Wh
2025-04-11 12:00:00 LastHourPVforecast 1343 Wh
2025-04-11 12:00:00 LastHourPVreal 1170 Wh
2025-04-11 12:22:47 NextHours_Sum01_PVforecast 1666 Wh
2025-04-11 12:22:47 NextHours_Sum02_PVforecast 3426 Wh
2025-04-11 12:22:47 NextHours_Sum03_PVforecast 5101 Wh
2025-04-11 12:22:47 NextHours_Sum04_ConsumptionForecast 0 Wh
2025-04-11 12:22:47 NextHours_Sum04_PVforecast 6554 Wh
2025-04-11 12:22:47 RestOfDayConsumptionForecast 0 Wh
2025-04-11 12:22:47 RestOfDayPVforecast 9021 Wh
2025-04-11 10:59:49 Today_Hour11_GridConsumption 0 Wh
2025-04-11 10:59:49 Today_Hour11_GridFeedIn 92 Wh
2025-04-11 10:59:49 Today_Hour11_PVforecast 994 Wh
2025-04-11 10:59:49 Today_Hour11_PVreal 180 Wh
2025-04-11 11:59:58 Today_Hour12_BatIn_01 0 Wh
2025-04-11 11:59:58 Today_Hour12_BatOut_01 0 Wh
2025-04-11 11:59:58 Today_Hour12_GridConsumption 10 Wh
2025-04-11 11:59:58 Today_Hour12_GridFeedIn 4 Wh
2025-04-11 11:59:58 Today_Hour12_PVforecast 1343 Wh
2025-04-11 11:59:58 Today_Hour12_PVreal 1170 Wh
2025-04-11 12:22:47 Today_Hour13_BatIn_01 0 Wh
2025-04-11 12:22:47 Today_Hour13_BatOut_01 0 Wh
2025-04-11 12:22:47 Today_Hour13_GridConsumption 0 Wh
2025-04-11 12:22:47 Today_Hour13_GridFeedIn 25 Wh
2025-04-11 12:22:47 Today_Hour13_PVforecast 1611 Wh
2025-04-11 12:22:47 Today_Hour13_PVreal 330 Wh
2025-04-11 12:22:47 Today_Hour14_PVforecast 1757 Wh
2025-04-11 12:22:47 Today_Hour15_PVforecast 1763 Wh
2025-04-11 12:22:47 Today_Hour16_PVforecast 1533 Wh
2025-04-11 12:22:47 Today_Hour17_PVforecast 1326 Wh
2025-04-11 12:22:47 Today_Hour18_PVforecast 963 Wh
2025-04-11 12:22:47 Today_Hour19_PVforecast 557 Wh
2025-04-11 12:22:47 Today_Hour20_PVforecast 126 Wh
2025-04-11 12:22:47 Today_Hour21_PVforecast 3 Wh
2025-04-11 12:22:47 Today_MaxPVforecast 1763 Wh
2025-04-11 12:22:47 Today_MaxPVforecastTime 2025-04-11 14:00:00
2025-04-11 12:22:47 Today_PVforecast 11976 Wh
2025-04-11 12:22:47 Today_PVreal 1680 Wh
2025-04-11 12:22:47 Today_SunRise 06:32
2025-04-11 12:22:47 Today_SunSet 20:01
2025-04-11 12:22:47 Tomorrow_ConsumptionForecast 88 Wh
2025-04-11 12:22:47 Tomorrow_PVforecast 13209 Wh
2025-04-11 12:22:47 Tomorrow_SunRise 06:30
2025-04-11 12:22:47 Tomorrow_SunSet 20:03
2025-04-11 12:22:47 nextCycletime 12:23:57
2025-04-11 12:20:27 nextRadiationAPICall nach 11.04.2025 12:35:27
2025-04-11 12:22:47 pvCorrectionFactor_Auto standby (remains in standby for 1.29 hours)
2025-04-11 10:46:37 setupStringAzimuth gartenhaus=SW
2025-04-11 10:46:54 setupStringDeclination gartenhaus=20
2025-04-11 12:22:48 state updated
Attributes:
ctrlLanguage DE
event-on-change-reading .*
flowGraphicControl size=300 animate=1 consumerdist=100 showconsumer=1 showconsumerdummy=0 shiftx=-20 strokewidth=15 strokecolstd=#99cc00
room Energiezähler
setupBatteryDev01 solix2mqtt pin=scenInfo_solarbank_info_total_charging_power:W pout=scenInfo_solarbank_info_total_battery_power:W pinmax=1000 poutmax=800 cap=1600:Wh charge=scenInfo_solarbank_info_solarbank_list_1_battery_power show=1
setupInverterDev01 solix2mqtt pv=scenInfo_solarbank_info_solarbank_list_1_photovoltaic_power:W etotal=scenInfo_statistics_2_total:kWh capacity=800 feed=bat
setupInverterStrings gartenhaus
setupMeterDev solix2mqtt gcon=scenInfo_grid_info_grid_to_home_power:W contotal=T0:Wh gfeedin=scenInfo_grid_info_photovoltaic_to_grid_power:W feedtotal=photovoltaic_to_grid_energy:Wh conprice=0.30:EUR feedprice=0:EUR
setupRadiationAPI OpenMeteoDWD-API
setupStringPeak gartenhaus=2
setupWeatherDev1 OpenMeteoDWD-API
Screenshot 2025-04-11 122111.png
@nuccleon,
da ist ein Syntaxfehler:
cap=1600:Wh -> cap=1600
@Peter,
ZitatWenn der Aufwand vertretbar wäre, könnte man das evtl. über die attr graphicBeamHeightLevelX konfigurierbar machen?
Schwer zu sagen, muß ich mir erst anschauen.
Ich möchte aber zunächst meine Attributkonsolidierungen durchziehen. Evtl. später nochmal erinnern.
LG,
Heiko
Danke Heiko!
Zitat von: TheTrumpeter am 09 April 2025, 12:10:40Zitat von: DS_Starter am 09 April 2025, 11:13:34Edit: Setze bei dir bitte den Key "strings=...".
Habe ich jetzt mal gesetzt. Leider ist die Stunde schon um, d.h. ich seh' jetzt nicht mehr ob's was gebracht hätte.
Bisher war es nicht definiert, weil lt. CommandRef optional.
Funktioniert trotzdem nicht...
attr mySolarForecast setupInverterDev01 myHuawei pv=Active_Power:W etotal=Accumulated_energy_yield:kWh capacity=15000 asynchron=1 strings=PV1,PV3
attr mySolarForecast setupInverterStrings PV1,PV3
attr mySolarForecast setupStringPeak PV1=8.46 PV3=8.46
Hier pvCircular von der 16. Stunde heute, es hätten fast 17 kWh produziert werden sollen:
16 => pvapifc: 16780, pvaifc: -, pvfc: 16780, aihit: 0, pvrl: 5650
batin01: -, batin02: -, batin03: -
batout01: -, batout02: -, batout03: -
confc: 803, gcon: 0, gfeedin: 5347, wcc: 69, rr1c: 0.00
temp: 19.10, wid: 2, wtxt: -
pprl01: -, pprl02: -, pprl03: -
pvcorrf: 5.00=0.92 5.05=1.03 5.100=0.85 5.15=0.85 5.20=0.90 5.25=0.94 5.30=1.00 5.35=0.95 5.40=1.01 5.45=0.89
5.50=0.86 5.55=0.97 5.60=0.71 5.65=0.71 5.70=1.69 5.75=0.81 5.80=0.88 5.85=1.25 5.90=0.96 5.95=1.30
10.00=1.00 10.100=1.03 10.10=0.92 10.15=0.94 10.20=0.91 10.25=0.95 10.30=1.31 10.35=0.99 10.40=1.01 10.45=0.89
10.50=0.96 10.55=1.15 10.60=0.71 10.65=0.76 10.70=2.69 10.75=0.81 10.80=0.92 10.85=1.00 10.90=0.89 10.95=1.16
15.00=0.94 15.100=0.78 15.15=0.95 15.20=0.91 15.25=0.94 15.30=1.31 15.35=0.94 15.40=1.01 15.45=0.89 15.50=0.86
15.55=1.09 15.60=0.71 15.65=0.88 15.70=2.69 15.75=1.06 15.80=0.95 15.85=1.37 15.90=1.06 15.95=0.82 20.00=0.93
20.10=1.03 20.100=0.76 20.15=0.95 20.20=0.97 20.25=0.94 20.30=1.31 20.35=0.94 20.40=1.01 20.45=0.94 20.50=0.95
20.55=0.97 20.60=0.72 20.65=0.95 20.70=1.35 20.75=0.72 20.80=0.87 20.85=1.37 20.90=1.33 20.95=1.22 25.00=0.97
25.05=0.95 25.100=1.03 25.15=0.96 25.20=1.05 25.25=0.94 25.30=1.10 25.35=1.00 25.40=1.02 25.45=0.98 25.50=1.00
25.55=1.15 25.60=0.85 25.65=1.13 25.70=1.24 25.75=0.74 25.80=0.96 25.85=1.37 25.90=1.06 25.95=1.16 30.00=1.04
30.05=0.98 30.10=0.99 30.100=1.00 30.15=0.95 30.20=0.91 30.25=0.94 30.30=1.31 30.35=0.94 30.40=1.01 30.45=0.89
30.50=1.02 30.55=1.09 30.60=0.71 30.65=0.76 30.70=1.69 30.75=0.83 30.80=0.95 30.85=1.37 30.90=1.16 30.95=1.66
35.00=0.95 35.100=0.96 35.10=0.89 35.15=0.95 35.20=1.09 35.25=0.94 35.30=1.31 35.35=1.19 35.40=1.01 35.45=1.10
35.50=0.86 35.55=1.09 35.60=0.72 35.65=0.76 35.70=2.19 35.75=0.83 35.80=0.95 35.85=1.46 35.90=1.06 35.95=0.66
40.00=1.04 40.05=0.98 40.10=0.97 40.100=1.01 40.15=0.95 40.20=1.06 40.25=0.94 40.30=1.01 40.35=1.01 40.40=1.01
40.45=1.03 40.50=0.86 40.55=0.91 40.60=1.19 40.65=1.18 40.70=1.44 40.75=0.83 40.80=0.95 40.85=1.37 40.90=1.06
40.95=0.82 45.00=1.02 45.05=1.06 45.100=0.96 45.10=1.03 45.15=1.04 45.20=0.91 45.25=0.94 45.30=1.31 45.35=1.02
45.40=1.01 45.45=0.89 45.50=0.86 45.55=1.09 45.60=1.06 45.65=1.15 45.70=2.19 45.75=0.83 45.80=0.98 45.85=0.87
45.90=1.06 45.95=1.16 50.00=0.97 50.05=1.03 50.10=1.19 50.100=1.03 50.15=1.04 50.25=0.99 50.30=0.93 50.40=0.72
50.45=0.93 50.50=0.99 50.55=1.16 50.60=1.06 50.65=1.01 50.70=1.14 50.75=1.01 50.80=1.15 50.85=1.04 50.90=1.21
50.95=1.08
simple=0.98
quality: 5.00=0.91 5.05=0.97 5.100=0.83 5.15=0.83 5.20=0.87 5.25=0.85 5.30=1.00 5.35=0.97 5.40=0.93 5.45=0.96
5.50=0.83 5.55=0.97 5.60=0.60 5.65=0.60 5.70=0.86 5.75=0.76 5.80=0.86 5.85=0.80 5.90=0.95 5.95=0.77
10.00=1.00 10.100=0.97 10.10=0.79 10.15=0.93 10.20=0.95 10.25=0.94 10.30=0.88 10.35=0.99 10.40=0.93 10.45=0.96
10.50=0.96 10.55=0.87 10.60=0.60 10.65=0.68 10.70=0.37 10.75=0.76 10.80=0.91 10.85=1.00 10.90=0.87 10.95=0.82
15.00=0.94 15.100=0.71 15.15=0.88 15.20=0.95 15.25=0.85 15.30=0.88 15.35=0.86 15.40=0.93 15.45=0.96 15.50=0.83
15.55=0.93 15.60=0.60 15.65=0.86 15.70=0.37 15.75=0.94 15.80=0.95 15.85=0.73 15.90=0.94 15.95=0.79 20.00=0.93
20.10=0.94 20.100=0.68 20.15=0.88 20.20=0.97 20.25=0.85 20.30=0.88 20.35=0.86 20.40=0.93 20.45=0.93 20.50=0.95
20.55=0.97 20.60=0.62 20.65=0.95 20.70=0.74 20.75=0.62 20.80=0.85 20.85=0.73 20.90=0.75 20.95=0.82 25.00=0.97
25.05=0.94 25.100=0.97 25.15=0.96 25.20=0.83 25.25=0.85 25.30=0.91 25.35=1.00 25.40=0.98 25.45=0.98 25.50=1.00
25.55=0.87 25.60=0.83 25.65=0.88 25.70=0.81 25.75=0.65 25.80=0.95 25.85=0.73 25.90=0.94 25.95=0.87 30.00=0.96
30.05=0.98 30.10=0.99 30.100=1.00 30.15=0.88 30.20=0.95 30.25=0.85 30.30=0.88 30.35=0.86 30.40=0.93 30.45=0.96
30.50=0.98 30.55=0.93 30.60=0.60 30.65=0.68 30.70=0.62 30.75=0.71 30.80=0.95 30.85=0.73 30.90=0.86 30.95=0.60
35.00=0.94 35.100=0.96 35.10=0.72 35.15=0.88 35.20=0.92 35.25=0.85 35.30=0.88 35.35=0.70 35.40=0.93 35.45=0.91
35.50=0.83 35.55=0.93 35.60=0.60 35.65=0.68 35.70=0.55 35.75=0.71 35.80=0.95 35.85=0.69 35.90=0.94 35.95=0.49
40.00=0.96 40.05=0.95 40.10=0.97 40.100=0.99 40.15=0.88 40.20=0.94 40.25=0.85 40.30=0.99 40.35=0.92 40.40=0.93
40.45=0.97 40.50=0.83 40.55=0.90 40.60=0.84 40.65=0.84 40.70=0.00 40.75=0.71 40.80=0.95 40.85=0.73 40.90=0.94
40.95=0.77 45.00=0.98 45.05=0.95 45.100=0.96 45.10=0.97 45.15=0.89 45.20=0.95 45.25=0.85 45.30=0.88 45.35=0.91
45.40=0.93 45.45=0.96 45.50=0.83 45.55=0.93 45.60=0.95 45.65=0.87 45.70=0.41 45.75=0.71 45.80=0.98 45.85=0.82
45.90=0.94 45.95=1.00 50.00=0.97 50.05=0.97 50.10=0.84 50.100=0.97 50.15=0.93 50.25=0.99 50.30=0.83 50.40=0.60
50.45=0.83 50.50=0.99 50.55=0.75 50.60=0.94 50.65=0.99 50.70=0.87 50.75=0.98 50.80=0.87 50.85=0.96 50.90=0.83
50.95=0.92
simple=0.98
pvrlsum: simple=1785642
pvfcsum: simple=1825107
dnumsum: simple=416
con_all => Sat @ 845 609 1166 232 280 995 702 592
Fri @ 303 2379 1036 803 226 404 1087 307
Sun @ 483 1159 326 343 187 481 2788 590
Wed @ 2855 2030 2490 425 595 522 604 572 331 347
Mon @ 273 2154 863 357 236 650 298 572 309
Tue @ 1010 288 173 1040 1373 216
Thu @ 2115 2282 1094 335 646 291 740 817 669 348
pvrl_10 => 00 @ 1170 1910 2269 2310
10 @ 1080
15 @ 1080
25 @ 1085
30 @ 3050
35 @ 1690
45 @ 2080
50 @ 2875 1920
55 @ 3460 3000
60 @ 1587
65 @ 1365
70 @ 1975
75 @ 1230
80 @ 1310
85 @ 1347
90 @ 1575 1059
95 @ 1167 449
100 @ 798 140 250 119 570 1700 310 409 1160 1320
pvrl_15 => 00 @ 3450 3500 3510 3880
30 @ 3050
45 @ 2080
50 @ 2875
55 @ 3460
60 @ 1587
65 @ 1365 2080
70 @ 1975
75 @ 1640 2410
80 @ 1513
85 @ 1320
90 @ 1575
95 @ 1167 1900 1810 2420
100 @ 1070 1320 510 330 1330 3370 970
pvrl_20 => 00 @ 1470 4300 4300 4190 4480 4390 4160
10 @ 4320
20 @ 4240
30 @ 3050
45 @ 2683
50 @ 3210
55 @ 3247
60 @ 1560
65 @ 1520 2510
70 @ 2431
75 @ 2477 2870
80 @ 1678
85 @ 1320
90 @ 1912
95 @ 2119 4600
100 @ 2164 590 990 1120 4210 1290 3740
pvrl_25 => 00 @ 5780 5640
05 @ 5690
15 @ 5690
20 @ 5590
30 @ 5170
35 @ 5550
40 @ 5240
45 @ 4527
50 @ 3528
55 @ 4317
60 @ 3358 2130 3200
65 @ 3136
70 @ 2094
75 @ 2345
80 @ 1513 4620
85 @ 1320
90 @ 1575
95 @ 1652
100 @ 2294 780 1750 1160 1840 1840 620
pvrl_30 => 00 @ 7110
05 @ 6300
10 @ 6015
30 @ 3050
45 @ 2080
50 @ 4130
55 @ 3460
60 @ 1587
65 @ 1365
70 @ 3838
75 @ 1640
80 @ 1513
85 @ 1320
90 @ 2250
95 @ 1167
100 @ 1758
pvrl_35 => 00 @ 7640 9000 8810
10 @ 6220
20 @ 7955
30 @ 3050
35 @ 7290
45 @ 4735
50 @ 2875
55 @ 3460
60 @ 2564
65 @ 1365
70 @ 3787
75 @ 1640
80 @ 1513
85 @ 3610
90 @ 1575
95 @ 2948 7010 3060 2910
100 @ 3418 1990 3030 4940
pvrl_40 => 00 @ 8468
05 @ 7950
10 @ 8700 8990
20 @ 9180
30 @ 5565
35 @ 8100
45 @ 7270
50 @ 2875
55 @ 4905
60 @ 3390
65 @ 4030
70 @ 2253 5650
75 @ 1640
80 @ 1513
85 @ 1320
90 @ 1575
95 @ 3528 5380
100 @ 5609
pvrl_45 => 00 @ 9596
05 @ 9165
10 @ 10123
15 @ 10170
30 @ 3050
35 @ 10010
45 @ 2080
50 @ 2875
55 @ 3460
60 @ 3292
65 @ 3937
70 @ 3447
75 @ 1640
80 @ 5182
85 @ 2737
90 @ 1575
95 @ 2052
100 @ 5791
pvrl_5 => 00 @ 539
05 @ 530
15 @ 580
20 @ 770
30 @ 1680
35 @ 450
45 @ 2080
50 @ 2875
55 @ 1825
60 @ 1587
65 @ 920
70 @ 1155
75 @ 772
80 @ 1198
85 @ 997
90 @ 772
95 @ 790
100 @ 225
pvrl_50 => 00 @ 9592
05 @ 10595
10 @ 10290
15 @ 10880
25 @ 9980
30 @ 7300
40 @ 6185
45 @ 7800
50 @ 9740
55 @ 10070
60 @ 8695
65 @ 9102
70 @ 10350
75 @ 10310
80 @ 10353
85 @ 7925
90 @ 8550
95 @ 8072
100 @ 6775
pvfc_10 => 00 @ 1406 2052 2134 2278
10 @ 1306
15 @ 1159
25 @ 1148
30 @ 2688
35 @ 1705
45 @ 2165
50 @ 3354 1649
55 @ 3228 2378
60 @ 2220
65 @ 1797
70 @ 734
75 @ 1524
80 @ 1427
85 @ 1349
90 @ 1484 1484
95 @ 701 1212
100 @ 972 382 284 251 406 1032 547 181 1682 1511
pvfc_15 => 00 @ 3946 3290 3506 4158
30 @ 2688
45 @ 2165
50 @ 3354
55 @ 3228
60 @ 2220
65 @ 1797 2133
70 @ 734
75 @ 2118 1693
80 @ 1591
85 @ 964
90 @ 1484
95 @ 701 3340 1826 2677
100 @ 3900 561 457 1719 1274 1378 1638
pvfc_20 => 00 @ 4482 1555 4358 4621 4783 5007 4852
10 @ 4060
20 @ 4108
30 @ 2688
45 @ 2863
50 @ 3362
55 @ 3343
60 @ 2158
65 @ 2132 2102
70 @ 1795
75 @ 2577 4821
80 @ 1922
85 @ 964
90 @ 1435
95 @ 1872 3623
100 @ 2206 1152 964 884 4458 1699 3181
pvfc_25 => 00 @ 5950 5824
05 @ 6016
15 @ 5893
20 @ 4642
30 @ 4721
35 @ 5548
40 @ 5153
45 @ 4632
50 @ 3534
55 @ 3770
60 @ 3196 4954 3743
65 @ 2772
70 @ 1695
75 @ 3172
80 @ 1591 4816
85 @ 964
90 @ 1484
95 @ 1430
100 @ 2357 871 4524 1703 2377 1551 373
pvfc_30 => 00 @ 6831
05 @ 6448
10 @ 6104
30 @ 2688
45 @ 2165
50 @ 4036
55 @ 3228
60 @ 2220
65 @ 1797
70 @ 5308
75 @ 2118
80 @ 1591
85 @ 964
90 @ 1935
95 @ 701
100 @ 1760
pvfc_35 => 00 @ 8130 9535 9298
10 @ 7948
20 @ 7281
30 @ 2688
35 @ 5109
45 @ 4290
50 @ 3354
55 @ 3228
60 @ 3581
65 @ 1797
70 @ 5489
75 @ 2118
80 @ 1591
85 @ 2477
90 @ 1484
95 @ 2572 10143 5571 3474
100 @ 3352 5275 3301 3379
pvfc_40 => 00 @ 8155
05 @ 8320
10 @ 8472 9702
20 @ 8634
30 @ 5532
35 @ 7491
45 @ 7030
50 @ 3354
55 @ 5417
60 @ 2842
65 @ 3401
70 @ 5489 16780
75 @ 2118
80 @ 1591
85 @ 964
90 @ 1484
95 @ 3512 7404
100 @ 5575
pvfc_45 => 00 @ 9437
05 @ 8664
10 @ 9867
15 @ 9083
30 @ 2688
35 @ 9080
45 @ 2165
50 @ 3354
55 @ 3228
60 @ 3121
65 @ 3410
70 @ 5489
75 @ 2118
80 @ 5262
85 @ 3225
90 @ 1484
95 @ 2055
100 @ 6007
pvfc_5 => 00 @ 588
05 @ 513
15 @ 680
20 @ 870
30 @ 1680
35 @ 464
45 @ 2165
50 @ 3354
55 @ 1878
60 @ 2220
65 @ 1291
70 @ 997
75 @ 957
80 @ 1362
85 @ 799
90 @ 807
95 @ 606
100 @ 264
pvfc_50 => 00 @ 9857
05 @ 10272
10 @ 8680
15 @ 10114
25 @ 10096
30 @ 8524
40 @ 8649
45 @ 9128
50 @ 9860
55 @ 7602
60 @ 8203
65 @ 8978
70 @ 9056
75 @ 10070
80 @ 9032
85 @ 7588
90 @ 7063
95 @ 7461
100 @ 6577
ZitatFunktioniert trotzdem nicht...
Dann will ich es im Debug sehen -> ctrlDebug=radiationProcess
Man würde es schon für die Prognose für morgen sehen falls genug Sonne prognostiziert, der ggf. testweise die cap des Inverter heruntersetzen.
LG
Supi ->>> Versionsanzeige im Check
Vielen Dank !!! ;D 8)
@TheTrumpeter,
ich habe mir deinen Fall nochmal vorgenommen und bin der Meinung, dass die Problematik in der Zuordnung von zwei Strings auf einen Inverter liegt.
Das muß mir genauer anschauen wie das zu lösen ist.
LG,
Heiko
Hallo Heiko,
ich hab immer wieder ganz fürchterliche Freezes, und weiß nicht, woher sie kommen. Zunächst hatte ich ein HTTPMOD-Device (pi-hole) in Verdacht, aber nachdem ich das gestoppt hatte, wurde es nicht besser, also falsche Fährte.
Ich weiß mir im Moment keinen Rat mehr, deshalb greife ich nach jedem Strohhalm. Kannst du dir den folgenden Log-anschauen?
2025.04.11 18:28:12.835 1: [Freezemon] myFreezemon: possible freeze starting at 18:27:53, delay is 19.834 possibly caused by: no bad guy found :-(
2025.04.11 18:28:35.061 1: [Freezemon] myFreezemon: possible freeze starting at 18:28:15, delay is 20.06 possibly caused by: tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-MQTT2_CLIENT_keepalive(rhasspyMQTT2) tmr-HMLAN_KeepAliveCheck(HM_CFG_LAN_Adapter) tmr-FHEM::SolarForecast::releaseCentralTask(mySolarForecast)
2025.04.11 18:29:01.079 1: [Freezemon] myFreezemon: possible freeze starting at 18:28:36, delay is 25.077 possibly caused by: tmr-HttpUtils_TimeoutErr(N/A) tmr-PRESENCE_StartLocalScan(Pihole_ping) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW2) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW1) tmr-CODE(0x560712d6ab30)(__ANON__) tmr-CODE(0x56070e2126c8)(__ANON__) tmr-CODE(0x560712fde228)(__ANON__) tmr-at_Exec(FritzBoxTraffic)
2025.04.11 18:29:01.338 2: rhasspyMQTT2: No PINGRESP for last PINGREQ (at 2025-04-11 18:28:14), disconnecting
2025.04.11 18:29:01.341 1: 192.168.1.100:1883 disconnected, waiting to reappear (rhasspyMQTT2)
2025.04.11 18:29:26.532 1: [Freezemon] myFreezemon: possible freeze starting at 18:29:02, delay is 24.53 possibly caused by: tmr-Unifi_DoUpdate(myUniFi) tmr-HMLAN_KeepAlive(HM_CFG_LAN_Adapter) tmr-SIP_watch_listen(N/A) tmr-SYSMON_Update(S740.Sysmon) tmr-SYSSTAT_GetUpdate(TrafficUnifiWan) tmr-CODE(0x5606f4d81138)(SIGNALduino_KeepAlive) tmr-FW_closeInactiveClients(N/A) tmr-MQTT::Timer(MyBroker) tmr-SamsungAV_Init(SamsungTV) tmr-FileLog_addLog(FileLog_JK_BMS) tmr-CODE(0x5606f4d81138)(SIGNALduino_KeepAlive) tmr-SIGNALduinoAdv_KeepAlive(mySignalESP32) tmr-MQTT2_CLIENT_keepalive(rhasspyMQTT2) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW2) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW1)
2025.04.11 18:29:48.561 1: [Freezemon] myFreezemon: possible freeze starting at 18:29:27, delay is 21.559 possibly caused by: tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-HMLAN_KeepAliveCheck(HM_CFG_LAN_Adapter) tmr-FHEM::SolarForecast::releaseCentralTask(mySolarForecast) tmr-HMUARTLGW_CheckCmdResp(myHmUARTLGW2) tmr-HttpUtils_TimeoutErr(N/A) tmr-HttpUtils_TimeoutErr(N/A) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW2) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW1) tmr-HMLAN_KeepAlive(HM_CFG_LAN_Adapter) tmr-CODE(0x560712fb9ad0)(__ANON__) tmr-CODE(0x560713413e38)(__ANON__) tmr-CODE(0x5606f3dbec30)(dnsQuery)
2025.04.11 18:30:10.298 1: 192.168.1.100:1883 reappeared (rhasspyMQTT2)
2025.04.11 18:30:10.318 1: [Freezemon] myFreezemon: possible freeze starting at 18:29:49, delay is 21.317 possibly caused by: tmr-HMLAN_KeepAliveCheck(HM_CFG_LAN_Adapter) tmr-HttpUtils_TimeoutErr(N/A) tmr-at_Exec(FritzBoxTraffic) tmr-BlockingKill(N/A) tmr-at_Exec(myTemperature) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW2) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW1) tmr-CODE(0x560712f77ef8)(__ANON__) tmr-CODE(0x560713413a18)(__ANON__) tmr-CODE(0x5607130f28e0)(__ANON__)
2025.04.11 18:30:32.045 1: [Freezemon] myFreezemon: possible freeze starting at 18:30:11, delay is 21.043 possibly caused by: tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-FHEM::SolarForecast::releaseCentralTask(mySolarForecast) tmr-HttpUtils_TimeoutErr(N/A) tmr-HMLAN_KeepAlive(HM_CFG_LAN_Adapter) tmr-HttpUtils_TimeoutErr(N/A) tmr-BlockingKill(N/A) tmr-DOIF_TimerTrigger(HeizungWZ) tmr-DOIF_TimerTrigger(Heizung_alive) tmr-DOIF_TimerTrigger(BewegungsmelderFlurEG) tmr-DOIF_TimerTrigger(Ueberwachung) tmr-DOIF_TimerTrigger(BewegungsmelderGarage) tmr-HourCounter_Run(N/A) tmr-HourCounter_Run(N/A) tmr-HourCounter_Run(N/A) tmr-HourCounter_Run(N/A) tmr-SIP_watch_listen(N/A) tmr-SYSMON_Update(S740.Sysmon) tmr-SYSSTAT_GetUpdate(TrafficUnifiWan) tmr-CODE(0x5606f4d81138)(SIGNALduino_KeepAlive) tmr-FW_closeInactiveClients(N/A) tmr-MQTT::Timer(MyBroker) tmr-SamsungAV_Init(SamsungTV) tmr-FileLog_addLog(FileLog_JK_BMS) tmr-CODE(0x5606f4d81138)(SIGNALduino_KeepAlive) tmr-SIGNALduinoAdv_KeepAlive(mySignalESP32) tmr-CUL_HM_ActCheck(N/A) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW2) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW1) tmr-DWD_OpenData::Timer(DWD.Wetter.Leverkusen) tmr-FHEM::AMADDevice::checkDeviceState(Pixel4a) tmr-CODE(0x5607134afc48)(__ANON__) tmr-CODE(0x560713daf4c0)(__ANON__) tmr-CODE(0x5606fcd93c78)(GSI_ApiRequest)
2025.04.11 18:30:55.104 1: [Freezemon] myFreezemon: possible freeze starting at 18:30:34, delay is 21.102 possibly caused by: tmr-CODE(0x5606f8d58a70)(HandleSendQueue) tmr-FHEM::SolarForecast::releaseCentralTask(mySolarForecast)
2025.04.11 18:31:16.986 1: [Freezemon] myFreezemon: possible freeze starting at 18:30:56, delay is 20.984 possibly caused by: tmr-CODE(0x560713366af8)(__ANON__) tmr-CODE(0x56071347e190)(__ANON__) tmr-CODE(0x56070c1454f8)(__ANON__) tmr-CODE(0x5606f8d58a70)(HandleSendQueue) tmr-at_Exec(FritzBoxTraffic) tmr-HMLAN_KeepAlive(HM_CFG_LAN_Adapter) tmr-HttpUtils_TimeoutErr(N/A) tmr-HttpUtils_TimeoutErr(N/A) tmr-MQTT2_CLIENT_keepalive(rhasspyMQTT2) tmr-FileLog_addLog(FileLog_HeishaMon_main) tmr-HttpUtils_TimeoutErr(N/A) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW2) tmr-HMUARTLGW_CheckCredits(myHmUARTLGW1) tmr-HttpUtils_TimeoutErr(N/A)
2025Es sind sehr viele Devices vorhanden, u.a. auch dein Modul SolarForecast.
Viele Grüße Gisbert
Hallo Gisbert,
mit diesen Ausgaben wirst du vermutlich nicht viel weiterkommen. Soweit ich sehen kann, sind die meisten Ausgaben der vermutlichen Verursacher ziemlich unverdächtig.
Die vorkommenden Routinen von SF sind im eigenen Code und greifen nicht auf externe Devices zu was ein Problem sein kann wenn die Devices (Schalter) nicht antworten. Aber singleUpdateState und releaseCentralTask sind unverdächtig.
Ich tippe auf ein Device welches nicht non-blocking programmiert ist und auf ein physisches Device zugreifen will welches aber nicht antwortet bis zum Timeout. Das Delay ist immer rund 20s wenn man dem trauen kann.
SF hat eine eigene Zeitmessung. Die kannst du mit Attr ctrlSpecialReadings -> runTimeCentralTask aktivieren und siehst dann im Reading "special_runTimeCentralTask" den Zeitverbrauch für einen kompletten Cycle.
Die Zeit liegt bei mir bei ca. 30 - 60 ms. Wenn ein Verbraucher geschaltet werden soll, aber nicht antwortet, könnten Verzögerungen auftreten, aber nicht in den besagten Routinen.
Ich tippe auf PRESENCE mit dem Pihole_ping. Ich glaube erst PRESENCE2 ist non-blocking (ohne Garantie).
Wenn du mit Freezemon nicht weiterkommst, würde ich Freezemon löschen! und mal Apptime (https://wiki.fhem.de/wiki/Apptime) nutzen. Alternativ auch Devices gezielt disablen die auf externe Devices oder in das Inet greifen. Auch nicht vergessen einen DNS Server im global Device zu setzen! Der sollte auch funktionieren!
LG,
Heiko
Man könnte ja bei Verdacht auch mal das device disablen.
Da es aber auch viele HttpUtils aufgelistet sind und SF auch HttpUtils nutzt sehe ich so erst einmal dort das Problem.
Sicher das es kein HttpUtils Problem ist?
DNS ok? Serverdevice ethernet connection bescheiden oder gar via wifi angebunden?
Ich gehe davon aus das der server ansonsten nicht hängt?
@TheTrumpeter, @all
ich habe die V 1.50.3 in mein contrib geladen.
Die Problematik der fehlenden Leistungsbegrenzung bei der Zuordnung von mehr als einem String auf einen Inverter sollte gelöst sein.
Bitte teste den Erfolg bei deiner Installation.
Weitere User sind natürlich auch eingeladen die V zu nutzen.
LG,
Heiko
Zitat von: kask am 11 April 2025, 22:43:14Man könnte ja bei Verdacht auch mal das device disablen.
Da es aber auch viele HttpUtils aufgelistet sind und SF auch HttpUtils nutzt sehe ich so erst einmal dort das Problem.
Sicher das es kein HttpUtils Problem ist?
DNS ok? Serverdevice ethernet connection bescheiden oder gar via wifi angebunden?
Ich gehe davon aus das der server ansonsten nicht hängt?
Sorry für den offtopic-Beitrag.
Ich hab jetzt alle Device, die mit pi-hole und SYSMON zu tun haben rausgeschmissen und Fhem neu gestartet. Das läuft ohne jetzt ohne Probleme. Damit ist klar, dass SolarForecast nicht der Verursacher ist, und ich bei pi-hole und SYSMON etc. weitersuchen muss.
ZitatSicher das es kein HttpUtils Problem ist?
Dazu reichen meine Möglichkeiten nicht, um diese Frage zu beantworten.
DNS ist ok, die LAN-Anbindung ist unverdächtig, und der Server hat nicht viel zu tun.
Ich versuche das Problem weiter einzukreisen.
Viele Grüße Gisbert
ZitatDa es aber auch viele HttpUtils aufgelistet sind und SF auch HttpUtils nutzt sehe ich so erst einmal dort das Problem.
Sicher das es kein HttpUtils Problem ist?
SF betreffend bin ich sicher. In dem Fall müssten andere Subs als Verursacher aufgelistet sein. Darüber hinaus nutzt SF nur das nicht blockierende HttpUtils_BlockingGet.
Die DNS Auflösung muß aber problemlos funktionieren. Die DNS Auflösung ist m.M. generell in FHEM blockierend, es sei denn man hat dnsServer im global Device gesetzt.
Für andere Module kann ich das natürlich nicht beurteilen.
Hallo Heiko,
ich hab folgendes in global definiert:
dnsServer 1.1.1.1
Das funktioniert schon seit längerer Zeit (> 1 Jahr) so, vermutlich dürfte das nicht das Problem sein. Internetausfälle hab ich auch keine.
Viele Grüße Gisbert
Naja, du fragst einen DNS Server im Inet ab. Ist der nicht zu erreichen, wird dein FHEM auch u.U. blockieren.
Ich habe einen lokalen DNS im eigenen Netz zugewiesen. Dieser holt externe Adressen auch von CloudFlare.
Also ich würde dir raten ebenfalls einen lokalen DNS anzugeben. Pi-Hole bietet sowas auch an.
Edit: Ich habe dir mal meine lokale DNS Architektur angehängt.
Ähm pi-hole ist der "DNS-Server". Sonst funktioniert doch pi-hole nicht, das is doch die eigentliche Kernfunktion.
Vermutlich meinst du einen Resolver. Das kann aber meiner Meinung nach pi-hole nicht.
Und Pi-hole zu haben und dann einen anderen DNS server anzugeben ist auch "banane".
ZitatUnd Pi-hole zu haben und dann einen anderen DNS server anzugeben ist auch "banane".
Nein, das hat seinen Grund. So gut Pi-Hole auch ist, aber hat keine Master-Slave Funktion. Zumindest kenne ich keine. Deswegen gibt es bei mir mehre DNS-Server, wobei ich nur den Master pflegen muß. Deswegen ist es so wie es dargestellt ist.
Resolver ... jepp.
Master-Slave (High Availability) ist schön für die Konfiguration da hast du vollkommen recht und mir ist da auch nichts bekannt bei pi-hole. Als DNS-Server aber so nicht wirklich nötig da man ja bestenfalls mehrere DNS-Server angibt um bei Ausfall eines und auch zum aufteilen beider (oder noch mehr) parallel nutzt.
Auch der pi-hole sollte mehr wie ein dns-server kontaktieren können.
Wenn dieser nicht geht dann funktioniert der oder die andere/n halt.
Und ein pi-hole macht schon Sinn da pi-hole nicht immer den Namen auflösen läst. Da wird auch gecached ausgegeben. Dann wird es auch schneller.
Zudem kommt das man ja eigentlich auch nicht möchte das ein Nameserver alle Anfragen bekommt. Der muss ja nicht alles wissen.
So jetzt genug off-topic.
Ich hatte Vorgestern leider das debugging irgend wie falsch gesetzt.
Das debugging sagte nach dem der Fehler immer kam das wohl keine requests mehr gemacht werden. Sondern stur einfach die Meldung ausgegeben wird.
2025.04.11 23:45:03 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:47:02 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:49:01 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:51:00 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:52:59 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:54:58 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
Ich habe 5 Strings noch einmal zur Info.
Das nächste was mich stützig macht das Pro request 20 calls abgezählt werden. Warum ist das so?
Und wieso sind um 9:30 Morgens 3500 calls bereits geschehen bei einem Interval von ca. 16 minuten?
025.04.12 00:00:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - the daily API requests -> limited to: 8000, done: 0
..
2025.04.12 00:00:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7980, Request equivalents p. call: 20, new call interval: 1081
..
..
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7900, Request equivalents p. call: 20, new call interval: 1092
..
..
..
2025.04.12 08:59:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4500, Request equivalents p. call: 20, new call interval: 1198
2025.04.12 09:16:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - the daily API requests -> limited to: 8000, done: 3500
..
2025.04.12 09:16:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4480, Request equivalents p. call: 20, new call interval: 1181
..
2025.04.12 09:16:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4460, Request equivalents p. call: 20, new call interval: 1186
..
2025.04.12 09:16:17 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4440, Request equivalents p. call: 20, new call interval: 1192
..
2025.04.12 09:16:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4420, Request equivalents p. call: 20, new call interval: 1197
..
2025.04.12 09:16:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4400, Request equivalents p. call: 20, new call interval: 1202
Edit.:
Ich habe mal alle Zeilen extrahiert. Bis jetzt gerade ist das alles im gleichen Intervall und nichts auffälliges.
Ich hänge mal die ersten 2,5h des Tages an um das hier nicht zu sprengen.
2025.04.12 00:00:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7980, Request equivalents p. call: 20, new call interval: 1081
2025.04.12 00:00:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7960, Request equivalents p. call: 20, new call interval: 1084
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7940, Request equivalents p. call: 20, new call interval: 1087
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7920, Request equivalents p. call: 20, new call interval: 1089
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7900, Request equivalents p. call: 20, new call interval: 1092
2025.04.12 00:16:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7880, Request equivalents p. call: 20, new call interval: 1082
2025.04.12 00:16:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7860, Request equivalents p. call: 20, new call interval: 1085
2025.04.12 00:16:49 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7840, Request equivalents p. call: 20, new call interval: 1088
2025.04.12 00:16:49 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7820, Request equivalents p. call: 20, new call interval: 1090
2025.04.12 00:16:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7800, Request equivalents p. call: 20, new call interval: 1093
2025.04.12 00:32:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7780, Request equivalents p. call: 20, new call interval: 1084
2025.04.12 00:32:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7760, Request equivalents p. call: 20, new call interval: 1087
2025.04.12 00:32:41 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7740, Request equivalents p. call: 20, new call interval: 1089
2025.04.12 00:32:41 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7720, Request equivalents p. call: 20, new call interval: 1092
2025.04.12 00:32:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7700, Request equivalents p. call: 20, new call interval: 1095
2025.04.12 00:48:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7680, Request equivalents p. call: 20, new call interval: 1086
2025.04.12 00:48:33 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7660, Request equivalents p. call: 20, new call interval: 1088
2025.04.12 00:48:33 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7640, Request equivalents p. call: 20, new call interval: 1091
2025.04.12 00:48:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7620, Request equivalents p. call: 20, new call interval: 1094
2025.04.12 00:48:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7600, Request equivalents p. call: 20, new call interval: 1097
2025.04.12 01:04:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7580, Request equivalents p. call: 20, new call interval: 1087
2025.04.12 01:04:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7560, Request equivalents p. call: 20, new call interval: 1090
2025.04.12 01:04:25 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7540, Request equivalents p. call: 20, new call interval: 1093
2025.04.12 01:04:25 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7520, Request equivalents p. call: 20, new call interval: 1096
2025.04.12 01:04:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7500, Request equivalents p. call: 20, new call interval: 1099
2025.04.12 01:20:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7480, Request equivalents p. call: 20, new call interval: 1089
2025.04.12 01:20:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7460, Request equivalents p. call: 20, new call interval: 1092
2025.04.12 01:20:17 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7440, Request equivalents p. call: 20, new call interval: 1095
2025.04.12 01:20:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7420, Request equivalents p. call: 20, new call interval: 1098
2025.04.12 01:20:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7400, Request equivalents p. call: 20, new call interval: 1101
2025.04.12 01:36:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7380, Request equivalents p. call: 20, new call interval: 1091
2025.04.12 01:36:09 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7360, Request equivalents p. call: 20, new call interval: 1094
2025.04.12 01:36:10 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7340, Request equivalents p. call: 20, new call interval: 1097
2025.04.12 01:36:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7320, Request equivalents p. call: 20, new call interval: 1100
2025.04.12 01:36:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7300, Request equivalents p. call: 20, new call interval: 1103
2025.04.12 01:51:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7280, Request equivalents p. call: 20, new call interval: 1093
2025.04.12 01:52:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7260, Request equivalents p. call: 20, new call interval: 1096
2025.04.12 01:52:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7240, Request equivalents p. call: 20, new call interval: 1099
2025.04.12 01:52:01 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7220, Request equivalents p. call: 20, new call interval: 1102
2025.04.12 01:52:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7200, Request equivalents p. call: 20, new call interval: 1105
2025.04.12 02:07:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7180, Request equivalents p. call: 20, new call interval: 1095
2025.04.12 02:07:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7160, Request equivalents p. call: 20, new call interval: 1098
2025.04.12 02:07:53 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7140, Request equivalents p. call: 20, new call interval: 1101
2025.04.12 02:07:53 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7120, Request equivalents p. call: 20, new call interval: 1104
2025.04.12 02:07:53 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7100, Request equivalents p. call: 20, new call interval: 1107
2025.04.12 02:23:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7080, Request equivalents p. call: 20, new call interval: 1097
2025.04.12 02:23:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7060, Request equivalents p. call: 20, new call interval: 1100
2025.04.12 02:23:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7040, Request equivalents p. call: 20, new call interval: 1103
2025.04.12 02:23:45 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7020, Request equivalents p. call: 20, new call interval: 1106
2025.04.12 02:23:45 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7000, Request equivalents p. call: 20, new call interval: 1109
Morgen kask,
ZitatDas nächste was mich stützig macht das Pro request 20 calls abgezählt werden. Warum ist das so?
OpenMeteoEnsemble hat durch seine Funktionalität ein Requestäquivalent (nicht Calls) von 20 pro Request. Also ein Request an OpenMeteoEnsemble verbraucht 20 Requests des Tageslimit. Das sind bei 5 Strings 100 Credits pro Call. Das kann man auf der Open Meteo API Seite vergleichen.
ZitatUnd wieso sind um 9:30 Morgens 3500 calls bereits geschehen bei einem Interval von ca. 16 minuten?
Request Equivalents nicht Calls. Siehe oben.
Aber ich denke die Bestimmung des Call Intervalls passt nicht 100%ig. Um 02:23:45 hast du nach 7000 Restequivalente. Bei 100 Verbrauch pro Call sind das 70 Calls. Das berechnete Intervall sind ca. 18 Minuten -> Sie würden demnach noch 70 x 18 / 60 = 21 Stunden (ca.) reichen. Das wäre rein rechnerisch bis kurz vor Mitternacht.
Beobachte es mal weiter.
Calls, Requestäquivalent... Die Hauptsache ist das du weißt was ich meine. Was auch immer ein "Requestäquivalent" sein soll.
Selbst openai kennt den quatsch nicht.
ZitatDer Begriff ,,Requestäquivalent" ist kein standardisierter Begriff in der Informatik oder allgemeinen Fachsprache – es klingt so, als könnte er aus einem bestimmten Kontext stammen, z. B. Webentwicklung, Netzwerke, APIs oder vielleicht aus dem Bereich der Lasttests bzw. Systemauslastung.
Hier sind ein paar mögliche Interpretationen – je nach Zusammenhang:
blah, blah..blah
Ok, wie dem auch sei.
Wieso macht man Nachts den gleichen Interval? Da würde es doch rein technisch reichen wenn kurz vor Sonnenaufgang angefangen wird.
Es ist doch unerheblich wie die Vorhersage die 4h vorher variieren kann, ändert ja nichts an dem was gesagt wird wenn es wirklich los geht.
Oder habe ich da einen Denkfehler?
Ich beobachte weiter!
Wieso haben die anderen Openmeteo api's den Fehler nicht. Die Anzahl ist doch die selbe an Anfragen!
ZitatWieso macht man Nachts den gleichen Interval? Da würde es doch rein technisch reichen wenn kurz vor Sonnenaufgang angefangen wird.
Es ist doch unerheblich wie die Vorhersage die 4h vorher variieren kann, ändert ja nichts an dem was gesagt wird wenn es wirklich los geht.
Oder habe ich da einen Denkfehler?
Weil nicht nur Strahlungsdaten, sondern auch Wetterdaten geholt werden und wir froh sind eine Quelle zu haben die häufig aktualisiert.
Man kann natürlich Nachts weniger häufig aktualisieren. Soll ich deswegen noch mehr Logik einbauen die das auch noch berücksichtigt obwohl wir genügend Requests zur Verfügung haben? Lassen wir doch mal die Kirche im Dorf. Ich brauche hier vermutlich nur einen Sicherheitsaufschlag in das berechnete Intervall einzubauen. Das schaue ich mir nachher mal an.
ZitatWieso haben die anderen Openmeteo api's den Fehler nicht. Die Anzahl ist doch die selbe an Anfragen!
Sorry, ich habe es versucht zu erläutern. Mehr Nerven habe ich jetzt nicht dazu. Wenn du dich intensiver einlesen willst, schau dir die API von OpenMeteo an.
LG
Hallo kask,
ich habe in der Intervallfindung einen Puffer in das Coding eingebaut um die Intervallberechnung für OpenMeteo resilienter zu gestalten.
Die V 1.50.3 in meinem contrib ist upgedated. Lade sie dir bitte in dein System und poste dann wieder die Debug Ausgaben wie gehabt. Das "new call interval" sollte sich nun etwas erhöhen und rein rechnerisch bis nach Mitternacht ausreichen.
LG,
Heiko
@all,
hier habe ich für einen besseren Überblick die Weiterentwicklungen der Versionen 1.50.1 - 1.50.3 zusammengefasst:
- Der Setter pvCorrectionFactor_Auto hat nun die auswählbare Option "on_complex_api_ai". "on_complex_ai"
verwendet die API-Ergebnisse wobei bei einem KI Hit die KI Ergebnisse verwendet werden.
Es ist allerdings nicht unbedingt gesagt, dass KI immer der bessere Wert ist. Diese neue Option verwendet
sowohl den API und KI-Wert und bildet aus beiden Treffern den Durchschnitt als effektive Vorhersage.
- die Kapazität des Wechselrichters begrenzt die Leistung der Strings auch wenn keine explizite Zuordnung durch "strings=..." vorhanden ist.
Es betrifft dann alle Strings, da ohne Zuordnung alle definierten Strings dem WR automatisch zugeordnet werden.
- das Attr ctrlSpecialReadings enthält die Option "tomorrowConsumptionForecast" um die stündliche Verbrauchsvorhersage für den kommenden Tag
als Reading darzustellen
- im Anlagencheck wird die aktuell verwendete Modulversion im Header ausgegeben
- Behebung der fehlenden Begrenzung für Strings, wenn mehr als ein String einem Wechselrichter zugewiesen ist
- verbesserte Call Intervallberechnung im MODEL OpenMeteoDWDEnsembleAPI
- verbesserte String Prüfung im Anlagencheck
- kleinere Änderungen im Code und CommandRef
Wer noch nicht mindestens auf V1.50.0 ist, sollte am WE auf die V1.50.3 updaten die ich soeben eingecheckt habe.
Kommende Woche wird das Major Release 1.51.0 erscheinen in dem alle inzwischen obsolet gewordenen Attribute entfernt werden. Deshalb wäre es vorteilhaft vorher die automatische Umstellung vorgenommen zu haben.
LG,
Heiko
Mein Kontingent ist aufgebraucht!
2025.04.13 20:53:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 0, Call equivalent: 20, new call interval: 900
Ich brauche mehr Zeit zwischen den Intervalen. 18 Minuten wie schon von Dir gesagt. Ich habe aber zwischen 15 und 17.
86400s am Tag / (20 blahblubs * 5 Strings) = 864s Intervall = alle 14,4 Minuten sind es aber ausgerechnet. Was ist das Problem?
Und wenn es aufgebracht wird wird ein neuer Interval von 15minuten gesetzt.
Aber alle 119s kommt der Fehler im Log.
2025.04.13 21:08:49 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.13 21:10:48 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.13 21:12:47 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.13 21:14:46 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
Das passt doch alles nicht. Wo ist mein Denkfehler?
Ok. Die 119 ist mein ctrlInterval der jetzt leider cycleInterval heißt wie ich sehen musste. Schade das der ctrlInterval für dich als obsolet angesehen wird.
Ich benutzen den aktiv. Aber OK.
Ich sehe den Fehler auch noch nicht. Das 15 Minuten Intervall ist der Standard, darunter ist es nicht sinnvoll und wird auf 15 Min verlängert.
Mich irritiert, dass bereits 21:XX das Limit erreicht ist. Das passt rechnerisch nicht. Gibt es vielleicht irgendwann einen Sprung in dem Ablauf jedes Calls? Das müsste man im Debug über einen ganzen Tag sehen falls es den gibt.
ZitatctrlInterval der jetzt leider cycleInterval heißt wie ich sehen musste. Schade das der ctrlInterval für dich als obsolet angesehen wird.
Ich benutzen den aktiv. Aber OK.
Ich benutze ihn auch aktiv. Den Parameter gibt es doch nach wie vor in plantControl. Wo ist das Problem?
LG,
Heiko
Ich sehe keinen Sprung. das ist ja auch das was mich irritiert.
Das problem ist das ich es nicht einfach so als attr setzen kann in Zukunft. Denke ich jetzt einfach mal so ;)
2025.04.13 00:00:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7980, Call equivalent: 20, new call interval: 1126
2025.04.13 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7960, Call equivalent: 20, new call interval: 1129
2025.04.13 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7940, Call equivalent: 20, new call interval: 1132
2025.04.13 00:00:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7920, Call equivalent: 20, new call interval: 1135
2025.04.13 00:00:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7900, Call equivalent: 20, new call interval: 1138
2025.04.13 00:15:21 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7880, Call equivalent: 20, new call interval: 1129
2025.04.13 00:15:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7860, Call equivalent: 20, new call interval: 1132
2025.04.13 00:15:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7840, Call equivalent: 20, new call interval: 1135
2025.04.13 00:15:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7820, Call equivalent: 20, new call interval: 1138
2025.04.13 00:15:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7800, Call equivalent: 20, new call interval: 1140
2025.04.13 00:31:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7780, Call equivalent: 20, new call interval: 1131
2025.04.13 00:31:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7760, Call equivalent: 20, new call interval: 1134
2025.04.13 00:31:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7740, Call equivalent: 20, new call interval: 1137
2025.04.13 00:31:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7720, Call equivalent: 20, new call interval: 1140
2025.04.13 00:31:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7700, Call equivalent: 20, new call interval: 1143
2025.04.13 00:47:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7680, Call equivalent: 20, new call interval: 1134
2025.04.13 00:47:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7660, Call equivalent: 20, new call interval: 1136
2025.04.13 00:47:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7640, Call equivalent: 20, new call interval: 1139
2025.04.13 00:47:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7620, Call equivalent: 20, new call interval: 1142
2025.04.13 00:47:09 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7600, Call equivalent: 20, new call interval: 1145
2025.04.13 01:02:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7580, Call equivalent: 20, new call interval: 1136
2025.04.13 01:02:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7560, Call equivalent: 20, new call interval: 1139
2025.04.13 01:03:01 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7540, Call equivalent: 20, new call interval: 1142
2025.04.13 01:03:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7520, Call equivalent: 20, new call interval: 1145
2025.04.13 01:03:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7500, Call equivalent: 20, new call interval: 1148
2025.04.13 01:18:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7480, Call equivalent: 20, new call interval: 1138
2025.04.13 01:18:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7460, Call equivalent: 20, new call interval: 1141
2025.04.13 01:18:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7440, Call equivalent: 20, new call interval: 1144
2025.04.13 01:18:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7420, Call equivalent: 20, new call interval: 1148
2025.04.13 01:18:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7400, Call equivalent: 20, new call interval: 1151
2025.04.13 01:34:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7380, Call equivalent: 20, new call interval: 1141
2025.04.13 01:34:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7360, Call equivalent: 20, new call interval: 1144
2025.04.13 01:34:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7340, Call equivalent: 20, new call interval: 1147
2025.04.13 01:34:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7320, Call equivalent: 20, new call interval: 1150
2025.04.13 01:34:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7300, Call equivalent: 20, new call interval: 1153
2025.04.13 01:50:33 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7280, Call equivalent: 20, new call interval: 1144
2025.04.13 01:50:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7260, Call equivalent: 20, new call interval: 1147
2025.04.13 01:50:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7240, Call equivalent: 20, new call interval: 1150
2025.04.13 01:50:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7220, Call equivalent: 20, new call interval: 1153
2025.04.13 01:50:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7200, Call equivalent: 20, new call interval: 1156
2025.04.13 02:06:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7180, Call equivalent: 20, new call interval: 1146
2025.04.13 02:06:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7160, Call equivalent: 20, new call interval: 1149
2025.04.13 02:06:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7140, Call equivalent: 20, new call interval: 1153
2025.04.13 02:06:28 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7120, Call equivalent: 20, new call interval: 1156
2025.04.13 02:06:28 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7100, Call equivalent: 20, new call interval: 1159
2025.04.13 02:22:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7080, Call equivalent: 20, new call interval: 1149
2025.04.13 02:22:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7060, Call equivalent: 20, new call interval: 1152
2025.04.13 02:22:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7040, Call equivalent: 20, new call interval: 1155
2025.04.13 02:22:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7020, Call equivalent: 20, new call interval: 1159
2025.04.13 02:22:20 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 7000, Call equivalent: 20, new call interval: 1162
2025.04.13 02:38:10 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6980, Call equivalent: 20, new call interval: 1152
2025.04.13 02:38:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6960, Call equivalent: 20, new call interval: 1155
2025.04.13 02:38:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6940, Call equivalent: 20, new call interval: 1158
2025.04.13 02:38:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6920, Call equivalent: 20, new call interval: 1162
2025.04.13 02:38:13 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6900, Call equivalent: 20, new call interval: 1165
2025.04.13 02:54:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6880, Call equivalent: 20, new call interval: 1155
2025.04.13 02:54:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6860, Call equivalent: 20, new call interval: 1158
2025.04.13 02:54:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6840, Call equivalent: 20, new call interval: 1161
2025.04.13 02:54:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6820, Call equivalent: 20, new call interval: 1165
2025.04.13 02:54:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6800, Call equivalent: 20, new call interval: 1168
2025.04.13 03:09:54 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6780, Call equivalent: 20, new call interval: 1158
2025.04.13 03:09:54 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6760, Call equivalent: 20, new call interval: 1161
2025.04.13 03:09:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6740, Call equivalent: 20, new call interval: 1164
2025.04.13 03:09:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6720, Call equivalent: 20, new call interval: 1168
2025.04.13 03:09:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6700, Call equivalent: 20, new call interval: 1171
2025.04.13 03:25:46 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6680, Call equivalent: 20, new call interval: 1161
2025.04.13 03:25:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6660, Call equivalent: 20, new call interval: 1164
2025.04.13 03:25:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6640, Call equivalent: 20, new call interval: 1168
2025.04.13 03:25:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6620, Call equivalent: 20, new call interval: 1171
2025.04.13 03:25:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6600, Call equivalent: 20, new call interval: 1175
2025.04.13 03:41:37 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6580, Call equivalent: 20, new call interval: 1164
2025.04.13 03:41:38 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6560, Call equivalent: 20, new call interval: 1167
2025.04.13 03:41:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6540, Call equivalent: 20, new call interval: 1171
2025.04.13 03:41:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6520, Call equivalent: 20, new call interval: 1175
2025.04.13 03:41:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6500, Call equivalent: 20, new call interval: 1178
2025.04.13 03:57:30 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6480, Call equivalent: 20, new call interval: 1167
2025.04.13 03:57:30 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6460, Call equivalent: 20, new call interval: 1171
2025.04.13 03:57:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6440, Call equivalent: 20, new call interval: 1174
2025.04.13 03:57:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6420, Call equivalent: 20, new call interval: 1178
2025.04.13 03:57:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6400, Call equivalent: 20, new call interval: 1182
2025.04.13 04:13:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6380, Call equivalent: 20, new call interval: 1171
2025.04.13 04:13:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6360, Call equivalent: 20, new call interval: 1174
2025.04.13 04:13:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6340, Call equivalent: 20, new call interval: 1178
2025.04.13 04:13:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6320, Call equivalent: 20, new call interval: 1182
2025.04.13 04:13:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6300, Call equivalent: 20, new call interval: 1185
2025.04.13 04:29:13 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6280, Call equivalent: 20, new call interval: 1174
2025.04.13 04:29:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6260, Call equivalent: 20, new call interval: 1178
2025.04.13 04:29:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6240, Call equivalent: 20, new call interval: 1181
2025.04.13 04:29:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6220, Call equivalent: 20, new call interval: 1185
2025.04.13 04:29:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6200, Call equivalent: 20, new call interval: 1189
2025.04.13 04:45:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6180, Call equivalent: 20, new call interval: 1178
2025.04.13 04:45:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6160, Call equivalent: 20, new call interval: 1181
2025.04.13 04:45:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6140, Call equivalent: 20, new call interval: 1185
2025.04.13 04:45:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6120, Call equivalent: 20, new call interval: 1189
2025.04.13 04:45:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6100, Call equivalent: 20, new call interval: 1193
2025.04.13 05:00:57 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6080, Call equivalent: 20, new call interval: 1181
2025.04.13 05:00:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6060, Call equivalent: 20, new call interval: 1185
2025.04.13 05:00:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6040, Call equivalent: 20, new call interval: 1189
2025.04.13 05:00:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6020, Call equivalent: 20, new call interval: 1193
2025.04.13 05:00:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 6000, Call equivalent: 20, new call interval: 1197
2025.04.13 05:16:49 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5980, Call equivalent: 20, new call interval: 1185
2025.04.13 05:16:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5960, Call equivalent: 20, new call interval: 1189
2025.04.13 05:16:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5940, Call equivalent: 20, new call interval: 1193
2025.04.13 05:16:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5920, Call equivalent: 20, new call interval: 1197
2025.04.13 05:16:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5900, Call equivalent: 20, new call interval: 1201
2025.04.13 05:32:41 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5880, Call equivalent: 20, new call interval: 1189
2025.04.13 05:32:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5860, Call equivalent: 20, new call interval: 1193
2025.04.13 05:32:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5840, Call equivalent: 20, new call interval: 1197
2025.04.13 05:32:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5820, Call equivalent: 20, new call interval: 1201
2025.04.13 05:32:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5800, Call equivalent: 20, new call interval: 1205
2025.04.13 05:48:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5780, Call equivalent: 20, new call interval: 1193
2025.04.13 05:48:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5760, Call equivalent: 20, new call interval: 1197
2025.04.13 05:48:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5740, Call equivalent: 20, new call interval: 1201
2025.04.13 05:48:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5720, Call equivalent: 20, new call interval: 1206
2025.04.13 05:48:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5700, Call equivalent: 20, new call interval: 1210
2025.04.13 06:04:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5680, Call equivalent: 20, new call interval: 1197
2025.04.13 06:04:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5660, Call equivalent: 20, new call interval: 1202
2025.04.13 06:04:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5640, Call equivalent: 20, new call interval: 1206
2025.04.13 06:04:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5620, Call equivalent: 20, new call interval: 1210
2025.04.13 06:04:28 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5600, Call equivalent: 20, new call interval: 1214
2025.04.13 06:20:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5580, Call equivalent: 20, new call interval: 1202
2025.04.13 06:20:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5560, Call equivalent: 20, new call interval: 1206
2025.04.13 06:20:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5540, Call equivalent: 20, new call interval: 1210
2025.04.13 06:20:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5520, Call equivalent: 20, new call interval: 1215
2025.04.13 06:20:20 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5500, Call equivalent: 20, new call interval: 1219
2025.04.13 06:36:09 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5480, Call equivalent: 20, new call interval: 1206
2025.04.13 06:36:10 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5460, Call equivalent: 20, new call interval: 1211
2025.04.13 06:36:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5440, Call equivalent: 20, new call interval: 1215
2025.04.13 06:36:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5420, Call equivalent: 20, new call interval: 1220
2025.04.13 06:36:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5400, Call equivalent: 20, new call interval: 1224
2025.04.13 06:52:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5380, Call equivalent: 20, new call interval: 1211
2025.04.13 06:52:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5360, Call equivalent: 20, new call interval: 1216
2025.04.13 06:52:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5340, Call equivalent: 20, new call interval: 1220
2025.04.13 06:52:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5320, Call equivalent: 20, new call interval: 1225
2025.04.13 06:52:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5300, Call equivalent: 20, new call interval: 1229
2025.04.13 07:07:54 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5280, Call equivalent: 20, new call interval: 1216
2025.04.13 07:07:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5260, Call equivalent: 20, new call interval: 1221
2025.04.13 07:07:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5240, Call equivalent: 20, new call interval: 1225
2025.04.13 07:07:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5220, Call equivalent: 20, new call interval: 1230
2025.04.13 07:07:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5200, Call equivalent: 20, new call interval: 1235
2025.04.13 07:23:46 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5180, Call equivalent: 20, new call interval: 1221
2025.04.13 07:23:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5160, Call equivalent: 20, new call interval: 1226
2025.04.13 07:23:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5140, Call equivalent: 20, new call interval: 1231
2025.04.13 07:23:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5120, Call equivalent: 20, new call interval: 1235
2025.04.13 07:23:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5100, Call equivalent: 20, new call interval: 1240
2025.04.13 07:39:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5080, Call equivalent: 20, new call interval: 1226
2025.04.13 07:39:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5060, Call equivalent: 20, new call interval: 1231
2025.04.13 07:39:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5040, Call equivalent: 20, new call interval: 1236
2025.04.13 07:39:41 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5020, Call equivalent: 20, new call interval: 1241
2025.04.13 07:39:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 5000, Call equivalent: 20, new call interval: 1246
2025.04.13 07:55:30 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4980, Call equivalent: 20, new call interval: 1232
2025.04.13 07:55:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4960, Call equivalent: 20, new call interval: 1237
2025.04.13 07:55:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4940, Call equivalent: 20, new call interval: 1242
2025.04.13 07:55:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4920, Call equivalent: 20, new call interval: 1247
2025.04.13 07:55:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4900, Call equivalent: 20, new call interval: 1252
2025.04.13 08:11:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4880, Call equivalent: 20, new call interval: 1238
2025.04.13 08:11:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4860, Call equivalent: 20, new call interval: 1243
2025.04.13 08:11:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4840, Call equivalent: 20, new call interval: 1248
2025.04.13 08:11:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4820, Call equivalent: 20, new call interval: 1253
2025.04.13 08:11:25 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4800, Call equivalent: 20, new call interval: 1258
2025.04.13 08:27:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4780, Call equivalent: 20, new call interval: 1244
2025.04.13 08:27:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4760, Call equivalent: 20, new call interval: 1249
2025.04.13 08:27:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4740, Call equivalent: 20, new call interval: 1254
2025.04.13 08:27:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4720, Call equivalent: 20, new call interval: 1259
2025.04.13 08:27:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4700, Call equivalent: 20, new call interval: 1265
2025.04.13 08:43:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4680, Call equivalent: 20, new call interval: 1250
2025.04.13 08:43:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4660, Call equivalent: 20, new call interval: 1255
2025.04.13 08:43:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4640, Call equivalent: 20, new call interval: 1261
2025.04.13 08:43:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4620, Call equivalent: 20, new call interval: 1266
2025.04.13 08:43:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4600, Call equivalent: 20, new call interval: 1272
2025.04.13 08:58:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4580, Call equivalent: 20, new call interval: 1256
2025.04.13 08:58:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4560, Call equivalent: 20, new call interval: 1262
2025.04.13 08:58:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4540, Call equivalent: 20, new call interval: 1267
2025.04.13 08:58:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4520, Call equivalent: 20, new call interval: 1273
2025.04.13 08:59:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4500, Call equivalent: 20, new call interval: 1279
2025.04.13 09:14:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4480, Call equivalent: 20, new call interval: 1263
2025.04.13 09:14:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4460, Call equivalent: 20, new call interval: 1269
2025.04.13 09:14:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4440, Call equivalent: 20, new call interval: 1275
2025.04.13 09:14:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4420, Call equivalent: 20, new call interval: 1280
2025.04.13 09:14:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4400, Call equivalent: 20, new call interval: 1286
2025.04.13 09:30:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4380, Call equivalent: 20, new call interval: 1270
2025.04.13 09:30:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4360, Call equivalent: 20, new call interval: 1276
2025.04.13 09:30:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4340, Call equivalent: 20, new call interval: 1282
2025.04.13 09:30:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4320, Call equivalent: 20, new call interval: 1288
2025.04.13 09:30:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4300, Call equivalent: 20, new call interval: 1294
2025.04.13 09:46:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4280, Call equivalent: 20, new call interval: 1278
2025.04.13 09:46:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4260, Call equivalent: 20, new call interval: 1284
2025.04.13 09:46:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4240, Call equivalent: 20, new call interval: 1290
2025.04.13 09:46:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4220, Call equivalent: 20, new call interval: 1296
2025.04.13 09:46:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4200, Call equivalent: 20, new call interval: 1302
2025.04.13 10:02:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4180, Call equivalent: 20, new call interval: 1286
2025.04.13 10:02:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4160, Call equivalent: 20, new call interval: 1292
2025.04.13 10:02:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4140, Call equivalent: 20, new call interval: 1298
2025.04.13 10:02:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4120, Call equivalent: 20, new call interval: 1304
2025.04.13 10:02:28 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4100, Call equivalent: 20, new call interval: 1311
2025.04.13 10:18:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4080, Call equivalent: 20, new call interval: 1294
2025.04.13 10:18:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4060, Call equivalent: 20, new call interval: 1300
2025.04.13 10:18:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4040, Call equivalent: 20, new call interval: 1306
2025.04.13 10:18:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4020, Call equivalent: 20, new call interval: 1313
2025.04.13 10:18:20 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 4000, Call equivalent: 20, new call interval: 1320
2025.04.13 10:34:09 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3980, Call equivalent: 20, new call interval: 1302
2025.04.13 10:34:10 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3960, Call equivalent: 20, new call interval: 1309
2025.04.13 10:34:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3940, Call equivalent: 20, new call interval: 1315
2025.04.13 10:34:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3920, Call equivalent: 20, new call interval: 1322
2025.04.13 10:34:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3900, Call equivalent: 20, new call interval: 1329
2025.04.13 10:50:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3880, Call equivalent: 20, new call interval: 1311
2025.04.13 10:50:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3860, Call equivalent: 20, new call interval: 1318
2025.04.13 10:50:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3840, Call equivalent: 20, new call interval: 1325
2025.04.13 10:50:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3820, Call equivalent: 20, new call interval: 1332
2025.04.13 10:50:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3800, Call equivalent: 20, new call interval: 1339
2025.04.13 11:05:54 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3780, Call equivalent: 20, new call interval: 1321
2025.04.13 11:05:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3760, Call equivalent: 20, new call interval: 1328
2025.04.13 11:05:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3740, Call equivalent: 20, new call interval: 1335
2025.04.13 11:05:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3720, Call equivalent: 20, new call interval: 1342
2025.04.13 11:05:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3700, Call equivalent: 20, new call interval: 1349
2025.04.13 11:21:45 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3680, Call equivalent: 20, new call interval: 1331
2025.04.13 11:21:46 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3660, Call equivalent: 20, new call interval: 1338
2025.04.13 11:21:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3640, Call equivalent: 20, new call interval: 1345
2025.04.13 11:21:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3620, Call equivalent: 20, new call interval: 1353
2025.04.13 11:21:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3600, Call equivalent: 20, new call interval: 1360
2025.04.13 11:37:38 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3580, Call equivalent: 20, new call interval: 1341
2025.04.13 11:37:38 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3560, Call equivalent: 20, new call interval: 1349
2025.04.13 11:37:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3540, Call equivalent: 20, new call interval: 1357
2025.04.13 11:37:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3520, Call equivalent: 20, new call interval: 1364
2025.04.13 11:37:41 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3500, Call equivalent: 20, new call interval: 1372
2025.04.13 11:53:30 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3480, Call equivalent: 20, new call interval: 1353
2025.04.13 11:53:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3460, Call equivalent: 20, new call interval: 1360
2025.04.13 11:53:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3440, Call equivalent: 20, new call interval: 1368
2025.04.13 11:53:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3420, Call equivalent: 20, new call interval: 1376
2025.04.13 11:53:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3400, Call equivalent: 20, new call interval: 1384
2025.04.13 12:09:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3380, Call equivalent: 20, new call interval: 1364
2025.04.13 12:09:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3360, Call equivalent: 20, new call interval: 1373
2025.04.13 12:09:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3340, Call equivalent: 20, new call interval: 1381
2025.04.13 12:09:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3320, Call equivalent: 20, new call interval: 1389
2025.04.13 12:09:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3300, Call equivalent: 20, new call interval: 1397
2025.04.13 12:25:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3280, Call equivalent: 20, new call interval: 1377
2025.04.13 12:25:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3260, Call equivalent: 20, new call interval: 1385
2025.04.13 12:25:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3240, Call equivalent: 20, new call interval: 1394
2025.04.13 12:25:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3220, Call equivalent: 20, new call interval: 1403
2025.04.13 12:25:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3200, Call equivalent: 20, new call interval: 1411
2025.04.13 12:41:05 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3180, Call equivalent: 20, new call interval: 1390
2025.04.13 12:41:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3160, Call equivalent: 20, new call interval: 1399
2025.04.13 12:41:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3140, Call equivalent: 20, new call interval: 1408
2025.04.13 12:41:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3120, Call equivalent: 20, new call interval: 1417
2025.04.13 12:41:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3100, Call equivalent: 20, new call interval: 1426
2025.04.13 12:56:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3080, Call equivalent: 20, new call interval: 1405
2025.04.13 12:56:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3060, Call equivalent: 20, new call interval: 1414
2025.04.13 12:56:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3040, Call equivalent: 20, new call interval: 1423
2025.04.13 12:56:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3020, Call equivalent: 20, new call interval: 1432
2025.04.13 12:57:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 3000, Call equivalent: 20, new call interval: 1442
2025.04.13 13:12:49 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2980, Call equivalent: 20, new call interval: 1420
2025.04.13 13:12:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2960, Call equivalent: 20, new call interval: 1429
2025.04.13 13:12:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2940, Call equivalent: 20, new call interval: 1439
2025.04.13 13:12:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2920, Call equivalent: 20, new call interval: 1449
2025.04.13 13:12:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2900, Call equivalent: 20, new call interval: 1459
2025.04.13 13:28:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2880, Call equivalent: 20, new call interval: 1436
2025.04.13 13:28:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2860, Call equivalent: 20, new call interval: 1446
2025.04.13 13:28:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2840, Call equivalent: 20, new call interval: 1456
2025.04.13 13:28:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2820, Call equivalent: 20, new call interval: 1467
2025.04.13 13:28:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2800, Call equivalent: 20, new call interval: 1477
2025.04.13 13:44:33 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2780, Call equivalent: 20, new call interval: 1453
2025.04.13 13:44:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2760, Call equivalent: 20, new call interval: 1464
2025.04.13 13:44:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2740, Call equivalent: 20, new call interval: 1475
2025.04.13 13:44:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2720, Call equivalent: 20, new call interval: 1485
2025.04.13 13:44:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2700, Call equivalent: 20, new call interval: 1496
2025.04.13 13:59:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2680, Call equivalent: 20, new call interval: 1474
2025.04.13 13:59:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2660, Call equivalent: 20, new call interval: 1485
2025.04.13 13:59:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2640, Call equivalent: 20, new call interval: 1496
2025.04.13 13:59:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2620, Call equivalent: 20, new call interval: 1507
2025.04.13 13:59:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2600, Call equivalent: 20, new call interval: 1519
2025.04.13 14:16:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2580, Call equivalent: 20, new call interval: 1492
2025.04.13 14:16:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2560, Call equivalent: 20, new call interval: 1504
2025.04.13 14:16:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2540, Call equivalent: 20, new call interval: 1516
2025.04.13 14:16:20 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2520, Call equivalent: 20, new call interval: 1528
2025.04.13 14:16:20 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2500, Call equivalent: 20, new call interval: 1540
2025.04.13 14:32:10 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2480, Call equivalent: 20, new call interval: 1514
2025.04.13 14:32:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2460, Call equivalent: 20, new call interval: 1526
2025.04.13 14:32:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2440, Call equivalent: 20, new call interval: 1539
2025.04.13 14:32:13 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2420, Call equivalent: 20, new call interval: 1552
2025.04.13 14:32:13 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2400, Call equivalent: 20, new call interval: 1564
2025.04.13 14:48:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2380, Call equivalent: 20, new call interval: 1538
2025.04.13 14:48:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2360, Call equivalent: 20, new call interval: 1551
2025.04.13 14:48:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2340, Call equivalent: 20, new call interval: 1564
2025.04.13 14:48:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2320, Call equivalent: 20, new call interval: 1577
2025.04.13 14:48:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2300, Call equivalent: 20, new call interval: 1591
2025.04.13 15:03:54 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2280, Call equivalent: 20, new call interval: 1563
2025.04.13 15:03:54 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2260, Call equivalent: 20, new call interval: 1577
2025.04.13 15:03:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2240, Call equivalent: 20, new call interval: 1591
2025.04.13 15:03:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2220, Call equivalent: 20, new call interval: 1606
2025.04.13 15:03:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2200, Call equivalent: 20, new call interval: 1620
2025.04.13 15:19:45 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2180, Call equivalent: 20, new call interval: 1592
2025.04.13 15:19:46 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2160, Call equivalent: 20, new call interval: 1606
2025.04.13 15:19:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2140, Call equivalent: 20, new call interval: 1621
2025.04.13 15:19:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2120, Call equivalent: 20, new call interval: 1636
2025.04.13 15:19:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2100, Call equivalent: 20, new call interval: 1652
2025.04.13 15:35:38 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2080, Call equivalent: 20, new call interval: 1622
2025.04.13 15:35:38 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2060, Call equivalent: 20, new call interval: 1638
2025.04.13 15:35:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2040, Call equivalent: 20, new call interval: 1654
2025.04.13 15:35:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2020, Call equivalent: 20, new call interval: 1670
2025.04.13 15:35:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 2000, Call equivalent: 20, new call interval: 1687
2025.04.13 15:51:30 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1980, Call equivalent: 20, new call interval: 1656
2025.04.13 15:51:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1960, Call equivalent: 20, new call interval: 1673
2025.04.13 15:51:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1940, Call equivalent: 20, new call interval: 1690
2025.04.13 15:51:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1920, Call equivalent: 20, new call interval: 1708
2025.04.13 15:51:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1900, Call equivalent: 20, new call interval: 1726
2025.04.13 16:07:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1880, Call equivalent: 20, new call interval: 1694
2025.04.13 16:07:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1860, Call equivalent: 20, new call interval: 1712
2025.04.13 16:07:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1840, Call equivalent: 20, new call interval: 1730
2025.04.13 16:07:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1820, Call equivalent: 20, new call interval: 1749
2025.04.13 16:07:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1800, Call equivalent: 20, new call interval: 1769
2025.04.13 16:23:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1780, Call equivalent: 20, new call interval: 1735
2025.04.13 16:23:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1760, Call equivalent: 20, new call interval: 1755
2025.04.13 16:23:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1740, Call equivalent: 20, new call interval: 1775
2025.04.13 16:23:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1720, Call equivalent: 20, new call interval: 1796
2025.04.13 16:23:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1700, Call equivalent: 20, new call interval: 1817
2025.04.13 16:39:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1680, Call equivalent: 20, new call interval: 1782
2025.04.13 16:39:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1660, Call equivalent: 20, new call interval: 1803
2025.04.13 16:39:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1640, Call equivalent: 20, new call interval: 1825
2025.04.13 16:39:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1620, Call equivalent: 20, new call interval: 1848
2025.04.13 16:39:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1600, Call equivalent: 20, new call interval: 1871
2025.04.13 16:54:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1580, Call equivalent: 20, new call interval: 1834
2025.04.13 16:54:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1560, Call equivalent: 20, new call interval: 1858
2025.04.13 16:54:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1540, Call equivalent: 20, new call interval: 1882
2025.04.13 16:54:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1520, Call equivalent: 20, new call interval: 1907
2025.04.13 16:55:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1500, Call equivalent: 20, new call interval: 1932
2025.04.13 17:10:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1480, Call equivalent: 20, new call interval: 1894
2025.04.13 17:10:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1460, Call equivalent: 20, new call interval: 1920
2025.04.13 17:10:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1440, Call equivalent: 20, new call interval: 1946
2025.04.13 17:10:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1420, Call equivalent: 20, new call interval: 1974
2025.04.13 17:10:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1400, Call equivalent: 20, new call interval: 2002
2025.04.13 17:26:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1380, Call equivalent: 20, new call interval: 1962
2025.04.13 17:26:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1360, Call equivalent: 20, new call interval: 1991
2025.04.13 17:26:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1340, Call equivalent: 20, new call interval: 2021
2025.04.13 17:26:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1320, Call equivalent: 20, new call interval: 2051
2025.04.13 17:26:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1300, Call equivalent: 20, new call interval: 2083
2025.04.13 17:42:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1280, Call equivalent: 20, new call interval: 2041
2025.04.13 17:42:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1260, Call equivalent: 20, new call interval: 2073
2025.04.13 17:42:35 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1240, Call equivalent: 20, new call interval: 2107
2025.04.13 17:42:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1220, Call equivalent: 20, new call interval: 2141
2025.04.13 17:42:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1200, Call equivalent: 20, new call interval: 2177
2025.04.13 17:58:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1180, Call equivalent: 20, new call interval: 2133
2025.04.13 17:58:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1160, Call equivalent: 20, new call interval: 2170
2025.04.13 17:58:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1140, Call equivalent: 20, new call interval: 2208
2025.04.13 17:58:28 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1120, Call equivalent: 20, new call interval: 2248
2025.04.13 17:58:28 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1100, Call equivalent: 20, new call interval: 2288
2025.04.13 18:14:17 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1080, Call equivalent: 20, new call interval: 2243
2025.04.13 18:14:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1060, Call equivalent: 20, new call interval: 2285
2025.04.13 18:14:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1040, Call equivalent: 20, new call interval: 2329
2025.04.13 18:14:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1020, Call equivalent: 20, new call interval: 2375
2025.04.13 18:14:20 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1000, Call equivalent: 20, new call interval: 2422
2025.04.13 18:30:09 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 980, Call equivalent: 20, new call interval: 2375
2025.04.13 18:30:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 960, Call equivalent: 20, new call interval: 2424
2025.04.13 18:30:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 940, Call equivalent: 20, new call interval: 2475
2025.04.13 18:30:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 920, Call equivalent: 20, new call interval: 2529
2025.04.13 18:30:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 900, Call equivalent: 20, new call interval: 2585
2025.04.13 18:46:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 880, Call equivalent: 20, new call interval: 2536
2025.04.13 18:46:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 860, Call equivalent: 20, new call interval: 2595
2025.04.13 18:46:03 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 840, Call equivalent: 20, new call interval: 2657
2025.04.13 18:46:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 820, Call equivalent: 20, new call interval: 2721
2025.04.13 18:46:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 800, Call equivalent: 20, new call interval: 2790
2025.04.13 19:01:53 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 780, Call equivalent: 20, new call interval: 2739
2025.04.13 19:01:54 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 760, Call equivalent: 20, new call interval: 2811
2025.04.13 19:01:55 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 740, Call equivalent: 20, new call interval: 2887
2025.04.13 19:01:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 720, Call equivalent: 20, new call interval: 2967
2025.04.13 19:01:56 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 700, Call equivalent: 20, new call interval: 3052
2025.04.13 19:17:45 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 680, Call equivalent: 20, new call interval: 3002
2025.04.13 19:17:46 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 660, Call equivalent: 20, new call interval: 3093
2025.04.13 19:17:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 640, Call equivalent: 20, new call interval: 3190
2025.04.13 19:17:47 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 620, Call equivalent: 20, new call interval: 3292
2025.04.13 19:17:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 600, Call equivalent: 20, new call interval: 3402
2025.04.13 19:33:38 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 580, Call equivalent: 20, new call interval: 3356
2025.04.13 19:33:38 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 560, Call equivalent: 20, new call interval: 3475
2025.04.13 19:33:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 540, Call equivalent: 20, new call interval: 3604
2025.04.13 19:33:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 520, Call equivalent: 20, new call interval: 3742
2025.04.13 19:33:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 500, Call equivalent: 20, new call interval: 3892
2025.04.13 19:49:30 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 480, Call equivalent: 20, new call interval: 3856
2025.04.13 19:49:30 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 460, Call equivalent: 20, new call interval: 4024
2025.04.13 19:49:31 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 440, Call equivalent: 20, new call interval: 4207
2025.04.13 19:49:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 420, Call equivalent: 20, new call interval: 4407
2025.04.13 19:49:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 400, Call equivalent: 20, new call interval: 4627
2025.04.13 20:05:21 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 380, Call equivalent: 20, new call interval: 4621
2025.04.13 20:05:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 360, Call equivalent: 20, new call interval: 4877
2025.04.13 20:05:22 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 340, Call equivalent: 20, new call interval: 5164
2025.04.13 20:05:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 320, Call equivalent: 20, new call interval: 5487
2025.04.13 20:05:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 300, Call equivalent: 20, new call interval: 5852
2025.04.13 20:21:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 280, Call equivalent: 20, new call interval: 5931
2025.04.13 20:21:14 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 260, Call equivalent: 20, new call interval: 6387
2025.04.13 20:21:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 240, Call equivalent: 20, new call interval: 6919
2025.04.13 20:21:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 220, Call equivalent: 20, new call interval: 7548
2025.04.13 20:21:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 200, Call equivalent: 20, new call interval: 8302
2025.04.13 20:37:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 180, Call equivalent: 20, new call interval: 8697
2025.04.13 20:37:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 160, Call equivalent: 20, new call interval: 9784
2025.04.13 20:37:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 140, Call equivalent: 20, new call interval: 11181
2025.04.13 20:37:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 120, Call equivalent: 20, new call interval: 13044
2025.04.13 20:37:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 100, Call equivalent: 20, new call interval: 15652
2025.04.13 20:52:57 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 80, Call equivalent: 20, new call interval: 18379
2025.04.13 20:52:58 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 60, Call equivalent: 20, new call interval: 24503
2025.04.13 20:52:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 40, Call equivalent: 20, new call interval: 36752
2025.04.13 20:52:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 20, Call equivalent: 20, new call interval: 73505
2025.04.13 20:53:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 0, Call equivalent: 20, new call interval: 900
Einzige was mich irritiert ist das der Interval im Log am Ende immer großer wird. aber die Zeit sich nicht groß ändert vom Interval.
OK, der Interval passt was im Log ausgegeben wird, nicht ganz aber da würde ein Aufruf nicht klappen.
Aber der wird nicht übernommen. Das ist die krux.
Ich sehe den Fehler jetzt, z.B.:
Zitat...
2025.04.13 19:49:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 400, Call equivalent: 20, new call interval: 4627
2025.04.13 20:05:21 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 380, Call equivalent: 20, new call interval: 4621
...
19:49 wurde ein neues Interval von 4627s errechnet, ca. 77 Min. Aber es wird nicht verwendet/eingehalten denn 20:05 wirde schon der nächste Call gestartet.
Heute finde ich den Fehler nicht mehr im Code, aber jetzt weiß ich wonach ich suchen muß.
ZitatDas problem ist das ich es nicht einfach so als attr setzen kann in Zukunft.
Wieso das denn? plantControl aufrufen, Wert ändern, speichern -> fertig. Übersehe ich etwas?
Z.B. bei mir, ich baue diese Attribute zum besseren Überblick/Änderbarkeit immmer mehrzeilig auf:
plantControl cycleInterval=180
feedinPowerLimit=4900
consForecastIdentWeekdays=1
consForecastLastDays=8
genPVdeviation=daily
Ich habe das Problem doch schneller gefunden als gedacht. Ich habe dir die V 1.50.4 ins contrib geladen.
Teste sie bitte bei dir.
@all,
in der V im contrib gibt es auch den Schlüssel flowGraphicControl->strokeCmrRedColLimit.
Damit kann man die Leistungsaufnahme der Consumer in der Flußgrafik bestimmen, ab der die Verbindungslinien Haus -> Consumer rot eingefärbt werden sollen.
LG
Ich teste!
Z.B. bei mir, ich baue diese Attribute zum besseren Überblick/Änderbarkeit immmer mehrzeilig auf:
Und was ist wenn ich "attr forecastdevice plantControl cycleInterval=180" ausführe?
Mit "attr forecastdevice ctrlInterval 180" kann ich es mal eben so setzen ohne andere sachen mit zu schreiben bzw. zuvor mühselig rumcoden um nicht alles kaput zu schreiben.
Es gibt Leute die automatisieren sachen und fingern da nicht immer händisch dran rum. So Leute soll es echt geben.
ZitatUnd was ist wenn ich "attr forecastdevice plantControl cycleInterval=180" ausführe?
Wie oft machst du das und änderst das cycleInterval?
Wenn es einen konkreten Bedarf gibt, kann ich für spezielle Verwendungen einen Setter implementieren der Änderungen umsetzt ohne eine Strukturänderung (das rote Fragezeichen) zu verursachen. Das at-Modul oder notify-Modul bietet zum Beispiel solche Möglichkeiten (active/inactive). Da bin ich durchaus offen. Es gibt auch schon den Setter operationMode der sich an den Optionen von at/notify anlehnt.
Alles hat Vor- und Nachteile, das ist mir bewußt. Nur haben wir damit zukünftig weniger Attribute, die thematisch geclustert und dadurch funktional im Zusammenhang erkennbar sind.
Zitat von: DS_Starter am 11 April 2025, 20:58:43@TheTrumpeter,
ich habe mir deinen Fall nochmal vorgenommen und bin der Meinung, dass die Problematik in der Zuordnung von zwei Strings auf einen Inverter liegt.
Das muß mir genauer anschauen wie das zu lösen ist.
Zitat von: DS_Starter am 11 April 2025, 22:46:10@TheTrumpeter, @all
ich habe die V 1.50.3 in mein contrib geladen.
Die Problematik der fehlenden Leistungsbegrenzung bei der Zuordnung von mehr als einem String auf einen Inverter sollte gelöst sein.
Bitte teste den Erfolg bei deiner Installation.
Sorry, ich war am Wochenende kaum online & wie ich sehe ist die Version schon veröffentlicht. Werd's gleich laden und beobachten.
Abgesehen davon, eigentlich könnte ich die 2 Strings zu einem zusammenfassen.
Ich habe damals bei der Konfiguration einfach versucht die Anlage so genau wie möglich abzubilden. Sie besteht aus 2 Strings, die aber direkt nebeneinander liegen. Einzig im tiefsten Winter hat der eine String ein paar Minuten am Vormittag leichte Beschattung, aber solange es keine String-individuellen Lernfunktionen gibt, ist das irrelevant.
Auf die Lernwerte sollte das keinen Einfluss haben, weil die zum Inverter gehören und sich der nicht ändert (abgesehen von der Konfiguration der String-Zuordnung, aber die zugeordnete Leistung bleibt gleich).
ZitatAbgesehen davon, eigentlich könnte ich die 2 Strings zu einem zusammenfassen.
Ja schon, allerdings ist es gut durch deinen Fall darauf aufmerksam geworden zu sein. Es wird ja durchaus öfter vorkommen dass ein WR mehrere Strings bedient. Insofern sehe ich bei dir keinen Anpassungsbedarf.
LG
ZitatWie oft machst du das und änderst das cycleInterval?
Bei jedem Neustart und sonst alle 72 Stunden. Falls du dich erinnerst syncronisiere ich meine SF Devices. So das jedes Device all 119s aktualisiert und alle Module 17s. Zueinander verzögert. Die ganze Devices hatten mein FHEM stark verzögert teilweise. Wieweit das jetzt überhaupt noch benötigt wird weiß ich nicht. Es hat zudem den Vorteil das mein Dummy Sammel-SF device alle 17s aktualisiert wird. Würde deshalb ungerne drauf verzichten wollen.
ZitatWürde deshalb ungerne drauf verzichten wollen.
Na dann überlege ich mir eine Set-Möglichkeit.
Für solche dynamischen Änderungen sind Attribute ganz allgemein keine gute Wahl. Sie sind eher für statische Einstellungen. Allein schon deswegen weil jedesmal ein "save" notwendig ist um die Änderungen zu persistieren.
Wie gesagt: "bei jedem Neustart". Somit ist ein save nicht nötig in meinem Fall.
Aber die Änderung von dir scheint zu funktionieren.
Ich habe jetzt noch 1400calls frei. Normalerweise wäre ich jetzt kurz vor knapp.
2025.04.14 20:31:36 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1500, Call equivalent: 20, new call interval: 1066
2025.04.14 20:49:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - the daily API requests -> limited to: 8000, done: 6500
..
2025.04.14 20:49:27 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining Requests: 1400, Call equivalent: 20, new call interval: 1065
Nabend zusammen,
mal was ganz "profanes":
Neue WP (Buderus) die Tage eingebaut....
...mit 1 X Heizstab (2.1 kW) für die Erhitzung des Warmwasserpuffers für Überschuss der sonst ins Netz gehen oder evtl. abgeregelt werden würde.
Der kann einfach in die Steckdose 230V und bis zu 80 Grad die 290 Liter im WW-Puffer "überhitzen".
Diesen hab ich "mal eben" eingebunden wie folgt:
attr Forecast consumer06 tuya_local_bfac44fb487476efd1vhdu \
type=heater \
power=2100 \
mode=can \
icon=sani_buffer_electric_heater_side@orange \
mintime=300\
on=on \
off=off \
pcurr=cur_power:W:5 \
etotal=etotal:kWh\
notbefore=08:00 \
notafter=19:00\
surpmeth=10 \
locktime=60:60 \
interruptable=1
Ist das so sinnvoll oder gibt es das "besser"?
Zusatzfrage weil ich es grad nicht finde:
pcurr=cur_power:W:5 - die 5 als Parameter heißt doch Schnitt der 5 letzten Werte oder nicht?
(erlaubt sind da - glaub ich - Werte von 2...20)
Gruß
300P
Zitatpcurr=cur_power:W:5 - die 5 als Parameter heißt doch Schnitt der 5 letzten Werte oder nicht?
Nein, das ist ein Schwellenwert ab dem der Verbraucher als aktiv gewertet wird. Also z.B. 10. Alles was unter 10 Watt gemessen wird, gilt als "Standby" und als nicht aktivem Verbraucher.
Ansonsten sollte es so passen. Ich würde aber einfach mintime=SunPath nutzen, also von Sonnenaufgang bis Untergang.
Bei interruptable könntest du noch ein Device:Reading:Regex deines Wassertemperaturmessers hinterlegen um ab 80°C den Heizer nicht mehr einzuschalten.
LG
Zitat von: DS_Starter am 14 April 2025, 21:38:35Zitatpcurr=cur_power:W:5 - die 5 als Parameter heißt doch Schnitt der 5 letzten Werte oder nicht?
Nein, das ist ein Schwellenwert ab dem der Verbraucher als aktiv gewertet wird. Also z.B. 10. Alles was unter 10 Watt gemessen wird, gilt als "Standby" und als nicht aktivem Verbraucher.
Ansonsten sollte es so passen. Ich würde aber einfach mintime=SunPath nutzen, also von Sonnenaufgang bis Untergang.
Bei interruptable könntest du noch ein Device:Reading:Regex deines Wassertemperaturmessers hinterlegen um ab 80°C den Heizer nicht mehr einzuschalten.
LG
okay Danke für die Anmerkungen. ;D
Der Heizstab hat einen Thermoschalter eingebaut der durch Einstellung bis auf 80 Grad eingestellt werden kann, daher ist kein weitere Wassertemperaturmessung extra notwendig.
@kask, @all,
die V 1.50.4 in meinem contrib ist aktualisiert.
Es gibt nun den Setter cycleInterval um das Datensammelinterval dynamisch ändern zu können. Der Befehl aktualisiert und persistiert auch den entsprechenden Schlüssel in plantControl. Dadurch ist Konsistenz gegeben.
Kannst du gerne mal testen.
Grüße,
Heiko
Hallo zusammen,
ich habe gestern den SOC Forecast bei mir aktiviert aber die Anzeige sieht bei mir so aus. An was könnte das Liegen?SOCForecast.jpg
Gruß
Moin scank,
hast du das Attr graphicEnergyUnit auf kWh stehen? Wenn ja, stelle es mal auf Wh um
LG,
Heiko
Hallo Heiko,
das war es. Danke für deine schnelle Hilfe.
Gruß
@scank, @all,
durch deine Anfrage ist mir bewusst geworden, dass die Werte-Darstellung des SOC im Balkendiagramm nicht von der Einstellung Wh/kWh abhhängen darf da es sich dabei ja um % handelt. Das trifft prinzipiell auch auf den Content energycosts, feedincome zu.
Ich habe diese relevaten Contents jetzt von der Einstellung des Attr graphicEnergyUnit entkoppelt.
Das Update der V 1.50.4 befindet sich in meinem contrib.
Ihr könnt es gerne laden und bei euch ausprobieren.
LG,
Heiko
Ich muss noch einmal nachfragen.
Nach wie vor bekomme ich an einigen Tagen eine stündliche Vorhersage die viel höher ist als die Kapazität des WR.
Habe ich noch irgendetwas falsch konfiguriert?
Ich hänge mal ein Bild Ann und ein list vom device.
Mit freundlichen Grüßen
Internals:
FUUID 67247ac1-f33f-d66d-4e77-94b6b4acd8c6944b
FVERSION 76_SolarForecast.pm:v1.50.0-s29825/2025-04-05
LCACHEFILE last write time: 17:32:54 File: ./FHEM/FhemUtils/PVCfg_SolarForecast_PV_forecast
MODE Automatic / Event-controlled - next planned Cycletime: 17:36:24
MODEL DWD
NAME PV_forecast
NOTIFYDEV ShellyPro_3EM,Hyper2000,SE3500H
NR 1538
NTFY_ORDER 50-PV_forecast
STATE running
TYPE SolarForecast
WEATHERMODEL DWD
eventCount 221458
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
SPGDETAIL
SPGDEV PV_forecast
SPGROOM
VERSION 1.50.0
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 38103
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:2177993
telnet telnetPort_127.0.0.1_58680
terminated 1
timeout 30
abortArg:
arg:
block 1
name PV_forecast
tsnext 1744821908.98247
OLDREADINGS:
READINGS:
2025-04-16 17:36:00 Battery_ChargeRecommended_01 1
2025-04-16 17:36:00 Battery_NextHour00_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour01_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour02_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour03_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour04_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour05_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour06_SoCforecast_01 96.6 %
2025-04-16 17:36:00 Battery_NextHour07_SoCforecast_01 86.1 %
2025-04-16 17:36:00 Battery_NextHour08_SoCforecast_01 75.7 %
2025-04-16 17:36:00 Battery_NextHour09_SoCforecast_01 64.8 %
2025-04-16 17:36:00 Battery_NextHour10_SoCforecast_01 54.1 %
2025-04-16 17:36:00 Battery_NextHour11_SoCforecast_01 43.0 %
2025-04-16 17:36:00 Battery_NextHour12_SoCforecast_01 26.4 %
2025-04-16 17:36:00 Battery_NextHour13_SoCforecast_01 12.6 %
2025-04-16 17:36:00 Battery_NextHour14_SoCforecast_01 4.8 %
2025-04-16 17:36:00 Battery_NextHour15_SoCforecast_01 0.0 %
2025-04-16 17:36:00 Battery_NextHour16_SoCforecast_01 0.0 %
2025-04-16 17:36:00 Battery_NextHour17_SoCforecast_01 13.7 %
2025-04-16 17:36:00 Battery_NextHour18_SoCforecast_01 45.1 %
2025-04-16 17:36:00 Battery_NextHour19_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour20_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour21_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour22_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Battery_NextHour23_SoCforecast_01 100.0 %
2025-04-16 17:36:00 Current_AutarkyRate 100 %
2025-04-16 17:36:00 Current_BatCharge_01 99 %
2025-04-16 17:36:00 Current_Consumption 374 W
2025-04-16 17:36:00 Current_GridConsumption 0 W
2025-04-16 17:36:00 Current_GridFeedIn 52 W
2025-04-16 17:36:00 Current_PV 426 W
2025-04-16 17:36:00 Current_PowerBatIn_01 0 W
2025-04-16 17:36:00 Current_PowerBatOut_01 0 W
2025-04-16 17:36:00 Current_SelfConsumption 374 W
2025-04-16 17:36:00 Current_SelfConsumptionRate 88 %
2025-04-16 17:36:00 Current_Surplus 52 W
2025-04-16 17:00:00 LastHourGridconsumptionReal 1221 Wh
2025-04-16 17:00:00 LastHourPVforecast 1320 Wh
2025-04-16 17:00:00 LastHourPVreal 1060 Wh
2025-04-16 17:36:00 NextHours_Sum01_PVforecast 778 Wh
2025-04-16 17:36:00 NextHours_Sum02_PVforecast 1125 Wh
2025-04-16 17:36:00 NextHours_Sum03_PVforecast 1237 Wh
2025-04-16 17:36:00 NextHours_Sum04_ConsumptionForecast 672 Wh
2025-04-16 17:36:00 NextHours_Sum04_PVforecast 1246 Wh
2025-04-16 17:36:00 RestOfDayConsumptionForecast 731 Wh
2025-04-16 17:36:00 RestOfDayPVforecast 1246 Wh
2025-04-16 00:59:57 Today_Hour01_BatIn_01 0 Wh
2025-04-16 00:59:57 Today_Hour01_BatOut_01 0 Wh
2025-04-16 00:59:57 Today_Hour01_GridConsumption 141 Wh
2025-04-16 00:59:57 Today_Hour01_GridFeedIn 140 Wh
2025-04-16 00:59:57 Today_Hour01_PVreal 0 Wh
2025-04-16 01:59:58 Today_Hour02_BatIn_01 0 Wh
2025-04-16 01:59:58 Today_Hour02_BatOut_01 0 Wh
2025-04-16 01:59:58 Today_Hour02_GridConsumption 177 Wh
2025-04-16 01:59:58 Today_Hour02_GridFeedIn 178 Wh
2025-04-16 01:59:58 Today_Hour02_PVreal 0 Wh
2025-04-16 02:59:58 Today_Hour03_BatIn_01 0 Wh
2025-04-16 02:59:58 Today_Hour03_BatOut_01 0 Wh
2025-04-16 02:59:58 Today_Hour03_GridConsumption 159 Wh
2025-04-16 02:59:58 Today_Hour03_GridFeedIn 161 Wh
2025-04-16 02:59:58 Today_Hour03_PVreal 0 Wh
2025-04-16 03:59:58 Today_Hour04_BatIn_01 0 Wh
2025-04-16 03:59:58 Today_Hour04_BatOut_01 0 Wh
2025-04-16 03:59:58 Today_Hour04_GridConsumption 132 Wh
2025-04-16 03:59:58 Today_Hour04_GridFeedIn 120 Wh
2025-04-16 03:59:58 Today_Hour04_PVreal 0 Wh
2025-04-16 04:59:58 Today_Hour05_BatIn_01 0 Wh
2025-04-16 04:59:58 Today_Hour05_BatOut_01 0 Wh
2025-04-16 04:59:58 Today_Hour05_GridConsumption 170 Wh
2025-04-16 04:59:58 Today_Hour05_GridFeedIn 0 Wh
2025-04-16 04:59:58 Today_Hour05_PVreal 0 Wh
2025-04-16 05:59:57 Today_Hour06_BatIn_01 0 Wh
2025-04-16 05:59:57 Today_Hour06_BatOut_01 0 Wh
2025-04-16 05:59:57 Today_Hour06_GridConsumption 288 Wh
2025-04-16 05:59:57 Today_Hour06_GridFeedIn 0 Wh
2025-04-16 05:59:57 Today_Hour06_PVreal 0 Wh
2025-04-16 06:59:57 Today_Hour07_BatIn_01 0 Wh
2025-04-16 06:59:57 Today_Hour07_BatOut_01 0 Wh
2025-04-16 06:59:57 Today_Hour07_GridConsumption 223 Wh
2025-04-16 06:59:57 Today_Hour07_GridFeedIn 2 Wh
2025-04-16 06:59:57 Today_Hour07_PVforecast 11 Wh
2025-04-16 06:59:57 Today_Hour07_PVreal 0 Wh
2025-04-16 07:59:57 Today_Hour08_BatIn_01 0 Wh
2025-04-16 07:59:57 Today_Hour08_BatOut_01 0 Wh
2025-04-16 07:59:57 Today_Hour08_GridConsumption 174 Wh
2025-04-16 07:59:57 Today_Hour08_GridFeedIn 190 Wh
2025-04-16 07:59:57 Today_Hour08_PVforecast 190 Wh
2025-04-16 07:59:57 Today_Hour08_PVreal 250 Wh
2025-04-16 08:59:59 Today_Hour09_BatIn_01 0 Wh
2025-04-16 08:59:59 Today_Hour09_BatOut_01 0 Wh
2025-04-16 08:59:59 Today_Hour09_GridConsumption 503 Wh
2025-04-16 08:59:59 Today_Hour09_GridFeedIn 558 Wh
2025-04-16 08:59:59 Today_Hour09_PVforecast 522 Wh
2025-04-16 08:59:59 Today_Hour09_PVreal 620 Wh
2025-04-16 09:59:57 Today_Hour10_BatIn_01 0 Wh
2025-04-16 09:59:57 Today_Hour10_BatOut_01 0 Wh
2025-04-16 09:59:57 Today_Hour10_GridConsumption 704 Wh
2025-04-16 09:59:57 Today_Hour10_GridFeedIn 1012 Wh
2025-04-16 09:59:57 Today_Hour10_PVforecast 581 Wh
2025-04-16 09:59:57 Today_Hour10_PVreal 1080 Wh
2025-04-16 10:59:57 Today_Hour11_BatIn_01 0 Wh
2025-04-16 10:59:57 Today_Hour11_BatOut_01 0 Wh
2025-04-16 10:59:57 Today_Hour11_GridConsumption 157 Wh
2025-04-16 10:59:57 Today_Hour11_GridFeedIn 1342 Wh
2025-04-16 10:59:57 Today_Hour11_PVforecast 1479 Wh
2025-04-16 10:59:57 Today_Hour11_PVreal 1450 Wh
2025-04-16 11:59:56 Today_Hour12_BatIn_01 0 Wh
2025-04-16 11:59:56 Today_Hour12_BatOut_01 0 Wh
2025-04-16 11:59:56 Today_Hour12_GridConsumption 58 Wh
2025-04-16 11:59:56 Today_Hour12_GridFeedIn 1937 Wh
2025-04-16 11:59:56 Today_Hour12_PVforecast 2956 Wh
2025-04-16 11:59:56 Today_Hour12_PVreal 1600 Wh
2025-04-16 12:59:59 Today_Hour13_BatIn_01 0 Wh
2025-04-16 12:59:59 Today_Hour13_BatOut_01 0 Wh
2025-04-16 12:59:59 Today_Hour13_GridConsumption 60 Wh
2025-04-16 12:59:59 Today_Hour13_GridFeedIn 2562 Wh
2025-04-16 12:59:59 Today_Hour13_PVforecast 3887 Wh
2025-04-16 12:59:59 Today_Hour13_PVreal 2090 Wh
2025-04-16 13:59:59 Today_Hour14_BatIn_01 0 Wh
2025-04-16 13:59:59 Today_Hour14_BatOut_01 0 Wh
2025-04-16 13:59:59 Today_Hour14_GridConsumption 109 Wh
2025-04-16 13:59:59 Today_Hour14_GridFeedIn 2382 Wh
2025-04-16 13:59:59 Today_Hour14_PVforecast 4482 Wh
2025-04-16 13:59:59 Today_Hour14_PVreal 1980 Wh
2025-04-16 14:59:58 Today_Hour15_BatIn_01 0 Wh
2025-04-16 14:59:58 Today_Hour15_BatOut_01 0 Wh
2025-04-16 14:59:58 Today_Hour15_GridConsumption 114 Wh
2025-04-16 14:59:58 Today_Hour15_GridFeedIn 2523 Wh
2025-04-16 14:59:58 Today_Hour15_PVforecast 1880 Wh
2025-04-16 14:59:58 Today_Hour15_PVreal 2140 Wh
2025-04-16 15:59:56 Today_Hour16_BatIn_01 0 Wh
2025-04-16 15:59:56 Today_Hour16_BatOut_01 0 Wh
2025-04-16 15:59:56 Today_Hour16_GridConsumption 132 Wh
2025-04-16 15:59:56 Today_Hour16_GridFeedIn 1439 Wh
2025-04-16 15:59:56 Today_Hour16_PVforecast 3031 Wh
2025-04-16 15:59:56 Today_Hour16_PVreal 1320 Wh
2025-04-16 16:59:59 Today_Hour17_BatIn_01 0 Wh
2025-04-16 16:59:59 Today_Hour17_BatOut_01 0 Wh
2025-04-16 16:59:59 Today_Hour17_GridConsumption 1221 Wh
2025-04-16 16:59:59 Today_Hour17_GridFeedIn 976 Wh
2025-04-16 16:59:59 Today_Hour17_PVforecast 1320 Wh
2025-04-16 16:59:59 Today_Hour17_PVreal 1060 Wh
2025-04-16 17:36:00 Today_Hour18_BatIn_01 0 Wh
2025-04-16 17:36:00 Today_Hour18_BatOut_01 0 Wh
2025-04-16 17:36:00 Today_Hour18_GridConsumption 360 Wh
2025-04-16 17:36:00 Today_Hour18_GridFeedIn 235 Wh
2025-04-16 17:36:00 Today_Hour18_PVforecast 1222 Wh
2025-04-16 17:36:00 Today_Hour18_PVreal 270 Wh
2025-04-16 17:36:00 Today_Hour19_PVforecast 502 Wh
2025-04-16 17:36:00 Today_Hour20_PVforecast 252 Wh
2025-04-16 17:36:00 Today_Hour21_PVforecast 24 Wh
2025-04-16 17:36:00 Today_MaxPVforecast 4482 Wh
2025-04-16 17:36:00 Today_MaxPVforecastTime 2025-04-16 13:00:00
2025-04-16 17:36:00 Today_PVdeviation 34.23 %
2025-04-16 17:36:00 Today_PVforecast 22339 Wh
2025-04-16 17:36:00 Today_PVreal 13860 Wh
2025-04-16 17:36:00 Today_SunRise 06:19
2025-04-16 17:36:00 Today_SunSet 20:23
2025-04-16 17:36:00 Tomorrow_ConsumptionForecast 5788 Wh
2025-04-16 17:36:00 Tomorrow_Hour06_PVforecast 0 Wh
2025-04-16 17:36:00 Tomorrow_Hour07_PVforecast 0 Wh
2025-04-16 17:36:00 Tomorrow_Hour08_PVforecast 69 Wh
2025-04-16 17:36:00 Tomorrow_Hour09_PVforecast 234 Wh
2025-04-16 17:36:00 Tomorrow_Hour10_PVforecast 436 Wh
2025-04-16 17:36:00 Tomorrow_Hour11_PVforecast 636 Wh
2025-04-16 17:36:00 Tomorrow_Hour12_PVforecast 966 Wh
2025-04-16 17:36:00 Tomorrow_Hour13_PVforecast 1412 Wh
2025-04-16 17:36:00 Tomorrow_Hour14_PVforecast 1289 Wh
2025-04-16 17:36:00 Tomorrow_Hour15_PVforecast 1212 Wh
2025-04-16 17:36:00 Tomorrow_Hour16_PVforecast 1059 Wh
2025-04-16 17:36:00 Tomorrow_Hour17_PVforecast 826 Wh
2025-04-16 17:36:00 Tomorrow_Hour18_PVforecast 594 Wh
2025-04-16 17:36:00 Tomorrow_Hour19_PVforecast 361 Wh
2025-04-16 17:36:00 Tomorrow_Hour20_PVforecast 148 Wh
2025-04-16 17:36:00 Tomorrow_Hour21_PVforecast 24 Wh
2025-04-16 17:36:00 Tomorrow_PVforecast 9266 Wh
2025-04-16 17:36:00 Tomorrow_SunRise 06:16
2025-04-16 17:36:00 Tomorrow_SunSet 20:25
2024-11-01 08:16:36 currentInverterDev SE3500H pv=AC_current_W:W etotal=gesamtPV:kWh capacity=3600
2024-11-01 07:59:28 currentRadiationAPI PV_forecast_weather
2024-11-01 07:57:43 inverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
2024-11-01 08:20:00 moduleAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
2024-11-01 08:22:24 moduleDeclination Vordach=40 Fahrradschuppen=25 Dach=45 Garten=15 Wintergarten=15
2024-11-01 08:20:38 modulePeakString Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.94
2025-04-16 17:35:54 nextCycletime 17:36:24
2025-04-16 08:00:01 pvCorrectionFactor_08 0.57 (automatic - old factor: 0.68, AI result used, Sun Alt range: 10, Cloud range: 85, Days in range: 3)
2025-04-16 09:00:02 pvCorrectionFactor_09 0.92 (automatic - old factor: 0.86, AI result used, Sun Alt range: 20, Cloud range: 70, Days in range: 2)
2025-04-16 10:00:00 pvCorrectionFactor_10 0.80 (automatic - old factor: 0.39, Sun Alt range: 25, Cloud range: 70, Days in range: 2)
2025-04-16 11:00:01 pvCorrectionFactor_11 0.82 (automatic - old factor: 0.68, AI result used, Sun Alt range: 35, Cloud range: 60, Days in range: 3)
2025-04-16 12:00:00 pvCorrectionFactor_12 0.54 (automatic - old factor: 1.00, Sun Alt range: 40, Cloud range: 60, Days in range: 1)
2025-04-16 13:00:03 pvCorrectionFactor_13 0.54 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 75, Days in range: 1)
2025-04-16 14:00:02 pvCorrectionFactor_14 0.44 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 65, Days in range: 1)
2025-04-16 15:00:02 pvCorrectionFactor_15 0.58 (automatic - old factor: 1.00, AI result used, Sun Alt range: 45, Cloud range: 60, Days in range: 1)
2025-04-16 16:00:00 pvCorrectionFactor_16 0.44 (automatic - old factor: 1.00, Sun Alt range: 40, Cloud range: 65, Days in range: 1)
2025-04-16 17:00:03 pvCorrectionFactor_17 0.50 (automatic - old factor: 1.00, AI result used, Sun Alt range: 35, Cloud range: 60, Days in range: 1)
2025-04-16 17:36:00 pvCorrectionFactor_Auto standby (remains in standby for 1.93 hours)
2025-02-01 21:37:19 setupStringAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
2025-04-06 14:17:36 setupStringDeclination Vordach=50 Fahrradschuppen=20 Dach=45 Garten=8 Wintergarten=15
2025-04-16 17:36:00 special_BatPowerIn_Sum 0 W
2025-04-16 17:36:00 special_BatPowerOut_Sum 0 W
2025-04-16 17:36:00 special_runTimeTrainAI 2.76301 s
2025-04-16 17:36:00 special_todayBatInSum 0.0 Wh
2025-04-16 17:36:00 special_todayBatOutSum 0.0 Wh
2025-04-16 17:36:00 special_todayConsumption 3600 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_01 181 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_02 182 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_03 187 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_04 186 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_05 191 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_06 292 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_07 241 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_08 202 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_09 400 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_10 478 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_11 482 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_12 296 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_13 191 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_14 48 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_15 25 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_16 108 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_17 386 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_18 511 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_19 268 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_20 202 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_21 7 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_22 0 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_23 0 Wh
2025-04-16 17:36:00 special_todayConsumptionForecast_24 59 Wh
2025-04-16 17:36:00 special_todayGridConsumption 4883 Wh
2025-04-16 17:36:00 special_todayGridFeedIn 15757.6 Wh
2025-04-16 17:36:00 state running
Attributes:
DbLogExclude .*
aiControl aiTrainStart=5 aiStorageDuration=1825 aiTreesPV=30
ctrlLanguage DE
ctrlNextDayForecastReadings 06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21
ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,runTimeTrainAI,todayBatInSum,todayBatOutSum,todayConsumption,todayConsumptionForecast,todayGridConsumption,todayGridFeedIn
event-on-change-reading .*
graphicEnergyUnit Wh
graphicHeaderDetail all
graphicHeaderOwnspec Ladeleistung:Current_PowerBatIn_01
Entladeleistung:Current_PowerBatOut_01
graphicHistoryHour 23
graphicHourCount 24
graphicLayoutType double
graphicShowDiff bottom
graphicShowNight 0
plantControl consForecastIdentWeekdays=1 consForecastLastDays=31 cycleInterval=30 genPVdeviation=continuously
room PV-Solar
setupBatteryDev01 Hyper2000 pin=properties_report_properties_outputPackPower:W pout=properties_report_properties_packInputPower:W pinmax=1200 poutmax=1200 cap=1920 charge=properties_report_properties_electricLevel show=1
setupInverterDev01 SE3500H pv=gesamtPV:W etotal=AC_Lifetime_Energy_production_kWh:kWh capacity=3600 asynchron=1 strings=Vordach,Fahrradschuppen,Garten,Dach,Wintergarten
setupInverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
setupMeterDev ShellyPro_3EM gcon=Active_Power_S:W contotal=Purchased_Energy_S:W gfeedin=-gcon feedtotal=Returned_Energy_S:W
setupRadiationAPI PV_forecast_weather
setupStringPeak Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.93
setupWeatherDev1 PV_forecast_weather
Habe jetzt noch einmal ein update gefahren und danach alle historischen Daten gelöscht und werde weiter beobachten.
Du brauchst die V 1.50.4 aus meinem contrib. In der V ist dieses Thema erledigt.
Du kannst aber auch auf die V 1.51.0 warten die ich heute oder die nächsten Tage einchecke.
LG,
Heiko
Die Version V1.51.0 ist eingecheckt.
Es sind wie kommuniziert die Weiterentwicklungen V1.50.1 - 3 enthalten sowie:
- der Balkencontent batsocforecast_, energycosts, feedincome ist von der Wh -> kWh Konvertierung entkoppelt
- OpenMeteoDWDEnsemble: die Berechnung des Intervalls ist korrigiert
- ein neuer Setter cycleInterval zur dynamischen Anpassung der Datensammlung
- eine User spezifische Möglichkeit den Schwellenwert für die rot-Färbung der Haus->Consumer Linien festzulegen (flowGraphicControl->strokeCmrRedColLimit)
Die folgenden Attribute sind gelöscht (wenn obsolet) oder sind als Schlüssel in den Sammel-Attributen consumerControl bzw. plantControl aufgegangen:
- affectBatteryPreferredCharge, affectConsForecastInPlanning, ctrlShowLink, ctrlBackupFilesKeep
- affectConsForecastIdentWeekdays, affectConsForecastLastDays, ctrlInterval, ctrlGenPVdeviation
- affectSolCastPercentile, ctrlSolCastAPIoptimizeReq, consumerAdviceIcon, consumerLink, consumerLegend
Noch ein Wort zu den Attributen.
Ziel ist es, die Anzahl der Attribute im Zaum zu halten und wo es möglich und sinnvoll erscheint, thematisch in Sammelattributen zu clustern.
Es können später auch noch weitere Zusammenfassungen entstehen.
Solltet ihr jedoch aus irgendwelchen Gründen bestimmte Attribute weiterhin als separate Attribute benötigen, kann ich diese Attribute auch wieder aus den Sammelattributen herauslösen und als ctrl-Attr bereitstellen oder alternativ einen dynamischen Setter (wie cycleInterval) implementieren.
Solche Setter sind für dynamische Änderungen besser geeignet weil z.B. kein manueller "save" nötig ist.
Wie gesagt ist das Ziel so wenig Attribute wie möglich und soviel Attribute wie nötig im Modul zu haben.
Es soll aber keiner auf entsprechenden Komfort verzichten müssen.
Ich hoffe das klärt nochmal den Grund für diese Bemühungen.
PAH hatte seinerzeit ein schönes grafisches Interface auf JavaScript-Basis zur Einstellung aller Attribute angeregt. Das würde mir ebenfalls sehr gut gefallen. Allerdings sind meine JS-Fähigkeiten sehr beschränkt.
Wer diesbezüglich in der Lage ist und gern unterstützen möchte, ist herzlich willkommen.
LG,
Heiko
Hey zusammen,
das Modul ist echt spitze! Allerdings habe ich ein Verständnis Problem.
Meine Hardware im Modul:
PV Module: 2 x 500W
WR: APSystems 800
Speicher: Growatt NOAH 2000
Anschluss:
PV Module an NOAH 2000, NOAH 2000 an WR.
Der NOAH hat zwei eigene MTTP Tracker, die Max 1800W zulassen. Er gibt dann die Energie, wenn man möchte weiter an den WR. Maximal 800 gibt er weiter und man kann einstellen ob er durchgehend x Watt abgeben soll oder Batterie First.
Mich irritiert die Anleitung insofern als das bei setupInverterDev in der Hilfe steht:
Legt ein beliebiges Wechselrichter-Gerät bzw. Solar-Ladegerät und dessen Readings zur Lieferung der aktuellen PV Erzeugungswerte fest.
Ein Solar-Ladegerät wandelt die von den Solarzellen gelieferte Energie nicht in Wechselstrom um, sondern lädt damit direkt eine vorhandene Batterie
Nun ist es aber so ja nicht ganz in dieser Konstellation. Ich habe folgende attr dafür:
setupInverterDev01 - noah_mqtt pv=solar_w:W etotal=generation_total_kwh:kWh capacity=800 feed=bat
setupBatteryDev01 - noah_mqtt pin=charge_w:W pout=discharge_w:W cap=2048 charge=soc
Nun habe ich bei den Werten die vom NOAH kommen ca. 3W Differenz zwischen dem was die PV Module an Energie aufnehmen und was der NOAH als charging anzeigt. Diese drei W, werden in der Grafik über das Haus geschliffen und landen dann in dem Unknown Verbraucher (die Lampe).
Nun ist die Frage:
- Muss ich den wirklichen WR (APSystems) auch noch angeben oder führt das dann nicht zur Verfälschung? Der WR zeigt mir auch alles an von Modulen, Gesamt Tag und Gesamt Lebenslang. Oder muss ich irgendwo angeben das die Geräte hintereinander hängen und die Konstellation eben ein wenig anders ist?
Wenn ich den WR als setupInverterDev02 angebe, wird dieser als zusätzliches Gerät mit Panelen angezeigt. Dadurch würde ich die Leistung, die der Akku abgibt, nochmal angezeigt bekommen, das ist nicht richtig. Was habe ich hier übersehen?
Hi,
das ist eine interessante Konstellation. Wahrscheinlich muß man hier etwas kreativ im Setup sein.
Das setupInverterDev01
setupInverterDev01 - noah_mqtt pv=solar_w:W etotal=generation_total_kwh:kWh capacity=800 feed=bat
sieht erstmal soweit gut aus. Von dem Verständis her sagt der Zusatz feed=bat aus, dass es sich hierbei um ein Gerät handelt, welches die Batterie direkt lädt und Überschuß ggf. an das Hausnetz liefert.
Bei dir wäre das quasi der NOAH 2000, der allerdings max. 1800W liefern kann. Die müsstest du bei capacity einstellen weil sonst deine Solarzellen, die max. 1000Wp bringen können, in der Prognose bei 800 Wh abgeschnitten würden bei capacity=800.
Da der WR APSystems bei einige/alle? der benötigten Readings für PV/etotal etc. liefert, würdest du diese Readings bei setupInverterDev01/setupBatteryDev01 angeben. Das hast du wahrscheinlich auch getan.
Den APSystems als setupInverterDev02 als weiteren WR anzugeben, würde tatsächlich das Ergebnis verfälschen. Es sei denn, man definiert den WR mit
capacity=0. Sowas habe ich noch nie probiert. Alternativ wäre es vllt. auch noch eine Entwicklungsaufgabe für mich, bei den setupInverterDevXX den Schlüssel "strings=none" zu ermöglichen. Das würde dann bedeuten, ein WR ist vorhanden, wird aber nicht durch PV-Module gespeist sondern aus einer vorhandenen Batterie.
Die 3W von denen du schreibst, scheinen mir die Verlustleistung innerhalb der Geräte NOAH/APSystems zu sein. Diese Verlustleistung (gibt es bei mir auch, je nach Auslastung in unterschiedlicher Höhe) wird genau wie du schreibst als nicht zuordenbare Energie in dem Dummy dargestellt. Irgendwo muß die ja hin. ;)
Edit: ".. WR mit capacity=0.." ist wahrscheinlich Blödsinn, aber die zu entwickelnde Variante mit "strings=none" erscheint mir eher schlüssig. Mit der dann in dem WR02 eingestellten capacity=800 wäre auch klar, dass nicht mehr als 800W aus der Gleichstromquelle(=Batterie) an das Hausnetz geliefert werden könnten.
LG,
Heiko
Danke für deine schnelle Antwort.
Die Konstellation ist aktuell, das was man so macht um die 800W für ein Balkonkraftwerk in DE einzuhalten.
PV Module max Peak mit Bifazial 1300 W -> Eingang Noah bis 1800 W -> Ausgang Noah 800 W -> WR 800 W -> Hausnetz. Man kann auch vier Module (bis zu 2600Wp) anstelle von zweien nutzen. Habe aber keinen Platz dafür.
Ich finde es gut das es diese Grafik gibt aber sie wäre immer noch falsch mit der Anpassung.
Richtig wäre ja: Sonne -> Akku -> WR -> Haus
Und die Verlustleistung sollte dann auch nicht durch das Haus gehen sondern vorher sichtbar sein. Ich habe auch alle Daten, die das aufzeigen. Anbei mal die Readings, direkt vom NOAH:
charge_w (Batterie Aufladung) / solar_w (PV Module)
READINGS:
2025-04-17 14:56:54 BAT0_soc 53
2025-04-17 14:56:54 BAT0_temp 16
2025-04-17 09:41:13 IODev mqtt2_server
2025-04-17 14:58:24 battery_num 1
2025-04-17 14:58:24 charge_w 86
2025-04-17 14:58:24 discharge_w 0
2025-04-17 09:41:38 firmware 10.09.05.4013
2025-04-17 14:58:24 generation_today_kwh 0.6
2025-04-17 14:58:24 generation_total_kwh 0.9
2025-04-17 09:41:38 manufacturer Growatt
2025-04-17 09:41:38 model NOAH 2000
2025-04-17 09:41:38 modul_version 0.0.29
2025-04-17 09:41:38 name Garage Speicher
2025-04-17 14:58:24 output_w 0
2025-04-17 14:56:54 parameters_charging_limit 100
2025-04-17 14:56:54 parameters_discharge_limit 10
2025-04-17 14:56:54 parameters_output_power_w 800
2025-04-17 14:58:24 soc 54
2025-04-17 14:58:24 solar_w 89
2025-04-17 14:58:24 status online
2025-04-17 14:58:24 work_mode battery_first
Also wir reden hier bei der Grafik nur über Schönheit. Damit kann ich notfalls leben.
Aber was das anlegen aktueller Balkonkraftwerke mit Speicher angeht, ist das etwas unschön.
Wenn ich irgendetwas testen kann, bitte gerne melden. Ich bin schon froh nichts überlesen zu haben. Die Doku zu diesem Modul ist nicht gerade kurz. (was aber bei dem Modul auch gut so ist)
EDIT: Hab nachdem ich gepostet hab nochmal rumgespielt und das auch angepasst:
setupBatteryDev01 - noah_mqtt pin=charge_w:W pout=discharge_w:W pinmax=1800 poutmax=800 cap=2048 charge=soc
setupInverterDev01 - noah_mqtt pv=solar_w:W etotal=generation_total_kwh:kWh capacity=800 feed=bat
Ach ja - Ich nehme die meisten Werte aus dem Speicher/Noah. Aber ich kann auch die aus dem WR nehmen. Aber nicht die, die zb die Modulwerte zeigen, denn da kommt an, was man im Speicher einstellt. Demnach ist auch das Gesamterzeugnis z.B. nicht das, was ggf. im Akku ist.
Gruß,
Kai
Hallo Kai,
ZitatIch finde es gut das es diese Grafik gibt aber sie wäre immer noch falsch mit der Anpassung.
Richtig wäre ja: Sonne -> Akku -> WR -> Haus
Ja, genau. Meiner Meinungs würde es dann genau so aussehen mit der Möglichkeit "strings=none". Ist natürlich nur Theorie bis man es umgesetzt hat.
Aber im Anhang mal eine Skizze wie der Fluß aussehen würde m.M. nach. Statt der Sonne über dem WR-Knoten würde man ein Icon für den WR02 definieren.
ZitatUnd die Verlustleistung sollte dann auch nicht durch das Haus gehen sondern vorher sichtbar sein.
Das behalte ich mal im Hinterkopf. Es gibt aber sehr umfangreiche Installationen mit mehreren WR, Batterien und auch sonstigen Erzeugern die überall Verlustleistung erzeugen. Bei allen diesen Einrichtungen müssten entsprechende Readings vorhanden sein, ausgewertet und irgendwie auch dargestellt werden. Ein ziemlich heftiges Unterfangen ...
Also was denkst du? Wollen wir die Variante mit "strings=none" mal angehen und schauen ob sich damit eine solche Anlage gut abbilden lässt?
Grüße,
Heiko
Hallo Heiko,
in einem konkreten Fall mit der Consumer-Steuerung bin ich langsam am Verzweifeln... Entweder bin ich zu doof oder das Modul kapituliert bei 6 zu steuernden Verbrauchern. Jedenfalls konnte ich das Schaltverhalten bisher nicht sinnvoll nachvollziehen.
Ausgangssituation:
PV Anlage mit Akku und PV Überschuss sinnvoll mit zwei Heizstäben (3 kW und 2 kW) verbrauchen. Die Heizstäbe sind pro Phase einzeln via Shelly schaltbar. Der größere, 3 kW Heizstab darf nur bei viel Überschuss in Betrieb gehen. Somit kann sehr fein durch den kleinen 2 kW Heizstab auf Überschuss reagiert werden. Die Heizstäbe sollen erst in Aktion treten, wenn der Akku auf 100% geladen worden ist. Ebenfalls dürfen sich die Heizstäbe nicht aus der Batterie bedienen und diese entladen. Die erste Bedingung konnte ich erfolgreich etablieren - Akku zu 100% voll, Verbrauchersteuerung startet. Wenn zu wenig PV Ertrag von den Modulen kommt, bedienen sich die Verbraucher schön von der Batterie und entladen diese fröhlich. Habe schon mit "interruptable" und "swoffcond" experimentiert, alles ohne Erfolg, die Heizstäbe entladen weiter fleißig die Batterie.
Was mache ich falsch, wo stehe ich auf dem Schlauch?
Viele Grüße!
Peter
PS: Im Anhang noch ein Bild vom "Schlechtfall" und anbei die Definitionen der Verbraucher.
attr PV_Vorhersage consumer01 ShellyPlus1PM_1 type=heater power=975 mode=can icon=sani_buffer_electric_heater_top on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:<100 mintime=SunPath locktime=60:60 surpmeth=SH10rt_1:01_Total_DC_Power:>5000\
attr PV_Vorhersage consumer02 ShellyPlus1PM_2 type=heater power=997 mode=can icon=sani_buffer_electric_heater_top on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:<100 mintime=SunPath locktime=60:60 surpmeth=SH10rt_1:01_Total_DC_Power:>5000\
attr PV_Vorhersage consumer03 ShellyPlus1PM_3 type=heater power=998 mode=can icon=sani_buffer_electric_heater_top on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:<100 mintime=SunPath locktime=60:60 surpmeth=SH10rt_1:01_Total_DC_Power:>5000\
attr PV_Vorhersage consumer04 ShellyPlusPlugS_1 type=noSchedule power=5 icon=sani_pump pcurr=power:W etotal=relay_0_energy_Wh noshow=2
attr PV_Vorhersage consumer05 ShellyPlus1PM_4 type=heater power=645 mode=can icon=sani_buffer_electric_heater_side on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:<100 mintime=SunPath locktime=60:60 surpmeth=10
attr PV_Vorhersage consumer06 ShellyPlus1PM_5 type=heater power=664 mode=can icon=sani_buffer_electric_heater_side on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:<100 mintime=SunPath locktime=60:60 surpmeth=10
attr PV_Vorhersage consumer07 ShellyPlus1PM_6 type=heater power=670 mode=can icon=sani_buffer_electric_heater_side on=on off=off notbefore=08:00 notafter=20:00 auto=automatic pcurr=power:W etotal=relay_0_energy_Wh:Wh interruptable=1 swoncond=BYD_Akku:SOC:100 swoffcond=BYD_Akku:SOC:<100 mintime=SunPath locktime=60:60 surpmeth=10
Gern!
Aber auch hier gibt es natürlich wieder Verlustleistung und Toleranzen.
Wenn ich im Akku z.B. sage er soll 800W raus lassen, heißt es nicht das diese auch nach dem WR herauskommen. Die Werte habe ich in FHEM alle.
Den APSystems WR frage ich lokal via HTTPMOD ab und den NOAH frage ich via noha_mqtt ab (eigentlich für HA aber geht auch für FHEM).
Bleibe ich mal bei den 800W und teste es habe ich laut NOAH:
PV Modul aktuell: 71W
NOAH Entladung: 772W
(wären zusammen eigentlich 843W, aber gut.. lassen wir mal so dahingestellt)
NOAH Ausgabe: 792W
APSystems WR:
Eingang/Ausgang WR: 738 W
Ich denke hier kommen dann aber noch Toleranzen der Systeme und Stabilität der Leistung hinzu. Wäre aber schon nett zu sehen.
PS: Dann freu dich schonmal wenn ich bald meine 10K Anlage auf dem Dache habe und nicht nur dieses Spielzeug. Dann hab ich bestimmt noch mehr. Wobei ich mir bei SMA zumindest vernünftige Werte erhoffe und nicht solche Abweichungen wegen Toleranz und Verlust. Die 3W+/- sind ja okay. Aber das was Noah meint auszugeben und was der WR dann am Ende meint, sind Welten und nicht alles Verlust.
ZitatDann freu dich schonmal wenn ich bald meine 10K Anlage auf dem Dache habe und nicht nur dieses Spielzeug. Dann hab ich bestimmt noch mehr.
Na dann hast du auch viel Spaß um alle Geräte möglichst synchron auszulesen bzw. die FHEM Devices anzuhalten zur gleichen Zeit aktuelle Werte zu liefern damit das Modul sie konsistent zusammenführen kann :) ... klappt nur bedingt gut. Bei mir klappt am Besten Die Werte per MQTT liefern zu lassen. SMA frage ich mit SMAInverter ab.
Mir würde es tatsächlich nicht um ms gehen. Man muss bedenken, bei meinem Spielzeug sind das auch noch unterschiedliche Hersteller. Da ist mir klar das es nicht perfekt sein wird. Aber immer noch besser als das was die Hersteller auf den Markt werfen und deren Einstellmöglichkeiten. Die Frage der Genauigkeit der Daten sei auch mal dahingestellt. Könnte jetzt noch sagen, ich habe einen Shelly hinter dem WR, der zeigt nochmal leicht was anderes an. Aber das Thema lassen wir lieber.
Am Ende geht es mir nur darum es vernünftig steuern zu können. Und wenn das 20 Sekunden dauert, wäre das am Ende in der Grafik ggf. nicht mega schön aber an sich würde es seinen Dienst tun.
@seayak,
swoffcond=BYD_Akku:SOC:<100
ist für diesen Fall nicht zu gebrauchen, weil
1.) swoffcond den gesamten geplanten Schaltzyklus des Heizers beendet, aber du wilst ja nur unterbrechen
2.) <100 als Regex falsch ist. Um Werte kleiner 100 zu identifizieren könnte man schreiben: swoffcond=BYD_Akku:SOC:[0-9]{1,2}
Es würde sich tatsächlich interruptable anbieten, aber in der Form Device:Reading:Regex[:Hysterese]. Also könnte der Term so aussehen:
interruptable=<Bat-Device>:<SoC-Reading>:[0-9]{1,2}Dann würde der Heizer unterbrochen, wenn kein PV-Überschuß vorhanden ist oder der SOC der Batterie kleiner/gleich 99% beträgt.
Damit sollte deine Steuerung theoretisch ;) funktionieren.
LG,
Heiko
Hallo Heiko,
vielen Dank, ein Teilerfolg wurde soeben mit der Regex Definition bei "interruptable" erreicht.
Mit 99% wird unterbrochen, aber sobald danach wieder 100% Bat SOC erreicht werden, werden wieder alle 6 Heizstäbe eingeschaltet, obwohl viel zu wenig PV vom Dach kommt und die Batterie wird wieder entladen.
Womit arbeitet denn die Steuerung? Current_Surplus? Das ist jetzt z.B. positiv und wird jetzt aber zum Beispiel zum Aufladen der Batterie und der Hausverbraucher genutzt. Eine Steuerung, nur basierend auf wirklichem Überschuss, der sonst ins Netz gehen würde, sehe ich als sinnvoller an.
Aktuell "schwingt und toggelt" dann das Szenario, wenn es zur abfallenden PV Leistung am Nachmittag kommt.
Viele Grüße!
Peter
Hallo Peter,
ja stimmt, das ist eine ODER Verknüpfung. D.h. kein Interrupt wenn PV-Überschuß oder Bat zu 100% voll.
Dein Hinweis bringt micht auf die Idee. Du könntest auch das Reading Current_GridFeedIn auswerten, also:
interruptable=<SF-Device>:Current_GridFeedIn:0
Dann wird der Heizer unterbrochen wenn kein PV Überschuß ODER keine Netzeinspeisung vorliegt. Anderherum schaltet der Heizer ein, wenn Netzeinspeisung vorliegt, was ja automatisch einen PV Überschuß bedeuten würde sonst gäbe es keine Einspeisung.
Das Toggeln kann man mit mit der Angabe einer Hysterese bzw. dem locktime-Key verhindern.
Muß jetzt erstmal los ... aber ich denke du weißt wie der Lösungsweg aussehen könnte.
LG,
Heiko
Ich habe tatsächlich noch was.
Das Balkendiagramm zeigt für morgen 800W für mehrere Stunden an. Aber das ist nicht korrekt.
Es geht von:
setupInverterDev01 - noah_mqtt pv=solar_w:W etotal=generation_total_kwh:kWh capacity=800 feed=batcapacity aus.
Nun kann ich aber solange der Akku nicht voll ist, durchaus bis zu 1800W in den Akku jagen. Sobald dieser voll wäre, kann ich nur noch 800W nutzen. Ich kann aber auch Akku laden und gleichzeitig einspeisen.
Die 1800 bekomme ich natürlich wegen der Limitierung meiner Module nicht. Aber das wäre max Akku.
Wenn ich capacity nun auf 1800 stelle, wäre es aber auch wieder falsch. Meine Module schaffen ja maximal 1300. Wenn ich es nun auf 1300 stelle wäre das natürlich niemals erreichbar, denn ich lebe ja nicht im Labor. Also stelle ich es mal auf 1100. Das ist real erreichbar.
Das Modul an sich weiß, wann der Akku voll ist bzw. nicht mehr lädt. Sollte ja in der Theorie möglich sein, das ggf. noch irgendwie anzupassen. Sollte das noch nicht gehen, wäre meine Vorhersage bei dieser Anlage, mit gutem Wetter quasi immer falsch und somit unnütz.
Ich hoffe man hat verstanden was ich meine. Es fällt mir etwas schwer das zu erklären.
Guten Morgen!
du must deine Batterie evtl. genauer einstellen.
Schau Dir mal meine Batterie an:
SBS37 pin=-pout:kW pout=total_pac:kW pinmax=3680 poutmax=3680 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@white asynchron=0
SBS25_2 pin=-pout:kW pout=total_pac:kW pinmax=2500 poutmax=2500 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@blue asynchron=0
Meine WR könnten auch maximal 9500 Watt in die BWR schicken
Meine Batterien (2) können aber nur:
SBS25 2500 Watt max rein oder raus
SBS37 3680 Watt max rein oder raus
(Alle WR sind mit ihren Nennwerten eingerichtet)
Gruß + bin jetzt weg zum Fischessen..... ;D
300P
Moin,
ZitatNun kann ich aber solange der Akku nicht voll ist, durchaus bis zu 1800W in den Akku jagen.
Ja, deshalb schrieb ich ja weiter vorn dass capacity=1800 hier richtig wäre damit kein Beschneiden bei 800 Wh vorgenommen wird.
ZitatWenn ich capacity nun auf 1800 stelle, wäre es aber auch wieder falsch. Meine Module schaffen ja maximal 1300.
Die max. Leistung der Module stellst du ja im Attr setupStringPeak ein. Damit ist für das Modul alles klar. Mehr musst du nicht tun, der Rest passiert intern.
@300P, guten Appetit! :)
LG,
Heiko
Moin,
Habe heute die neueste Version eingespielt.
Leider erschliesst sich mir die
graphicBeam3Content
batsocforecast_01nicht so ganz.
ctrlNextHoursSoCForecastReadings
00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23Wenn der SocForecast über der ersten Balkengrafik ist, stimmt alles
Es endet immer mit der aktuellen Stunde. Anbei ein Bild.
Schönes Osterwochenende allen Mitlesenden
Hallo Shadow3561,
das liegt einfach daran dass die beiden Ebenen zeitlich nicht synchronisiert sind.
Die Ebene 1 zeigt keine Nachtstunden, die Ebene 2 zeigt sie an.
Die Synchronisation kann man mit Attr graphicShowNight=01 herstellen.
LG
Danke,
darauf muss man erst mal kommen.
Schönes langes WE
@87insane,
ich habe nochmal nachgedacht. Eigentlich hast du eine variable, vom Ladezustand abhängige WR-Kapazität.
Bei den Batterien habe ich diese Variable cap-Möglichkeit bereits ein gebaut. Bei deinem WR bräuchtest su das auch um die capa dynamisch (über ein Reading) gemäß des Bat-Ladezustandes einzustellen.
Siehst du das auch so?
LG
Zitat von: 300P am 18 April 2025, 11:17:51Guten Morgen!
du must deine Batterie evtl. genauer einstellen.
Schau Dir mal meine Batterie an:
SBS37 pin=-pout:kW pout=total_pac:kW pinmax=3680 poutmax=3680 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@white asynchron=0
SBS25_2 pin=-pout:kW pout=total_pac:kW pinmax=2500 poutmax=2500 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@blue asynchron=0
Meine WR könnten auch maximal 9500 Watt in die BWR schicken
Meine Batterien (2) können aber nur:
SBS25 2500 Watt max rein oder raus
SBS37 3680 Watt max rein oder raus
(Alle WR sind mit ihren Nennwerten eingerichtet)
Gruß + bin jetzt weg zum Fischessen..... ;D
300P
Das verstehe ich nicht ganz. Denn in meinen Augen ist das schon genauso eingestellt wie es sein muss. Du hast eigentlich auch nur eine Sache anders. Das wäre Laden - Entladen in pin. Aber das ist bei mir nicht richtig.
Der Speicher kann 1800W aufnehmen. Die Module würden im Labor 1300W liefern können. Der Speicher kann laden und entladen gleichzeitig. Maximaler Ausgang ist 800W Richtung WR. Ggf. verstehe ich das auch nicht, wie du das genau meinst.
Zitat@87insane,
ich habe nochmal nachgedacht. Eigentlich hast du eine variable, vom Ladezustand abhängige WR-Kapazität.
Bei den Batterien habe ich diese Variable cap-Möglichkeit bereits ein gebaut. Bei deinem WR bräuchtest su das auch um die capa dynamisch (über ein Reading) gemäß des Bat-Ladezustandes einzustellen.
Siehst du das auch so?
Und das verstehe ich leider garnicht.
Ich habe den Shelly Pro3em noch nicht im Stromkasten. Daher habe ich in die Richtung keine genaue Steuerung. Mein Grundrauschen sind ca. 400W. Das stelle ich also so im Speicher ein. Nun schiebt er 400W rauß und lädt zusätzlich was an Überschuss kommt.
Die Maximal 800W, die ich rauß geben kann, stehen ja in poutmax der Battery. Also dachte ich, wären eigentlich alle Werte da.
Laut Beschreibung passt capacity nur nicht zu dem was bei mir eigentlich passiert. Die Beschreibung verweist bei diesem Wert auf Ausgangsleistung.
Ggf. sollte ich auch erstmal ein wenig Wochenende machen. Ich danke aber erst nochmal für das Modul. Das ist ein sehr mächtiges Teil und es macht Spaß hier ein wenig zu fachsimpeln.
@87insane,
wir denken vermutlich auf verschiedenen Ebenen und Zusammenhängen, ist nicht so einfach.
Deswegen nur nochmal kurz zur Erläuterung.
Die Angabe capacity im Attr setupInverterDev01 hat in erster Linie die Aufgabe die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die Peak-Leistungen der PV-Module höher als die angeschlossene WR-Leistung bzw. kommt es vor, dass die KI / korrigierte API-Prognose über der max. WR-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene capacity gekappt.
D.h. der Schlüssel müsste bei dir m.M. nach capacity=1800 lauten. Nehmen wir an die Batterie ist nicht voll und es ist volle Sonne prognostiziert. Dann würden deine Module die volle Leistung von 1300W leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, da kleiner capacity=1800.
Und nehmen wir an, es ist volle Sonne und der Backofen ist an. Dann würde der WR nach meinem Verständnis max. 800W an das Hausnetz liefern und die restlich erzeugte PV-Leistung von 500W (1300W - 800W) in die Batterie schieben. -> keine Begrenzung wäre nötig
Anders ist es aber wenn volle Sonne scheint, die Batterie aber schon voll ist!
Dann würde der WR 800W an das Hausnetz liefern, aber die theoretisch verbleibenden 500W PV nicht mehr als Batterieladung nutzen könen, d.h. die PV-Anlage würde abregeln.
In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Leistung auf 800Wh begrenzt werden weil der WR ja seine eigentlichen 1800W nicht mehr ausspielen kann.
Das meinte ich mit dynamischer Anpassung der WR-capacity. Es beeinflusst in erster Linie die PV-Prognose für ein stimmiges Bild.
Deine Einstellung in der Batterie
setupBatteryDev01 - pinmax=1800 poutmax=800
haben insbesondere auf die SoC-Prognose Einfluß.
Ich hoffe ich habe keinen Denkfehler, aber so müßte sich deine Anlage m.M. nach verhalten nach allem was ich gelesen habe.
schöne Ostern!
LG
Sorry aber ich habe immer noch das Problem mit:
2025.04.18 17:15:50.259 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
conForecastTillNextSunrise' has no Parameter or default value set. Set the attribute again or inform Maintainer.
Der Parameter ist in attr gesetzt:
ctrlSpecialReadings includes
BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,
conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,
currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,
daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,
runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,
runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,
runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,
todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,
todayRemainingAPIcalls,todayRemainingAPIrequests,conForecastTillNextSunrise
Was kann ich tun damit der FEhler nicht mehr erscheint.
Das Forecast Modul scheint sonst einwandfrei zu funktionieren.
Nimm conForecastTillNextSunrise nochmal raus, speichere das Attr. Dann nimm conForecastTillNextSunrise wieder hinein und speichern. Vllt. Ist der Fehler dann weg.
Zitat von: Hackstall am 18 April 2025, 17:19:42Sorry aber ich habe immer noch das Problem mit:
.........
...........
BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,
conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,
currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,
daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,
runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,
runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,
runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,
todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,
todayRemainingAPIcalls,todayRemainingAPIrequests,conForecastTillNextSunrise
Du hast /hattest es leider wohl 2 x darin eingetragen / enthalten.(rot/blau)
Evtl. mal manuell editiert / eingetragen gewesen ?!? :o
Zitat von: DS_Starter am 18 April 2025, 14:34:04@87insane,
wir denken vermutlich auf verschiedenen Ebenen und Zusammenhängen, ist nicht so einfach.
Deswegen nur nochmal kurz zur Erläuterung.
Die Angabe capacity im Attr setupInverterDev01 hat in erster Linie die Aufgabe die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die Peak-Leistungen der PV-Module höher als die angeschlossene WR-Leistung bzw. kommt es vor, dass die KI / korrigierte API-Prognose über der max. WR-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene capacity gekappt.
D.h. der Schlüssel müsste bei dir m.M. nach capacity=1800 lauten. Nehmen wir an die Batterie ist nicht voll und es ist volle Sonne prognostiziert. Dann würden deine Module die volle Leistung von 1300W leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, da kleiner capacity=1800.
Und nehmen wir an, es ist volle Sonne und der Backofen ist an. Dann würde der WR nach meinem Verständnis max. 800W an das Hausnetz liefern und die restlich erzeugte PV-Leistung von 500W (1300W - 800W) in die Batterie schieben. -> keine Begrenzung wäre nötig
Anders ist es aber wenn volle Sonne scheint, die Batterie aber schon voll ist!
Dann würde der WR 800W an das Hausnetz liefern, aber die theoretisch verbleibenden 500W PV nicht mehr als Batterieladung nutzen könen, d.h. die PV-Anlage würde abregeln.
In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Leistung auf 800Wh begrenzt werden weil der WR ja seine eigentlichen 1800W nicht mehr ausspielen kann.
Das meinte ich mit dynamischer Anpassung der WR-capacity. Es beeinflusst in erster Linie die PV-Prognose für ein stimmiges Bild.
Deine Einstellung in der Batterie
setupBatteryDev01 - pinmax=1800 poutmax=800
haben insbesondere auf die SoC-Prognose Einfluß.
Ich hoffe ich habe keinen Denkfehler, aber so müßte sich deine Anlage m.M. nach verhalten nach allem was ich gelesen habe.
schöne Ostern!
LG
Danke und gut erklärt.
Hab schon direkt die nächste Geschichte. Ich werde (wenn es noch nicht gehen sollte) via doif/mswitch....
aufgrund der Prognosen, eine Art intelligente Akku Ladung bauen. Das wollte ich anhand der Prognosen machen.
Aufgaben für mich:
Steuerung des Akku via mqtt einrichten. Bisher lese ich nur aus.
Regeln anlegen, wann geladen werden muss/soll und wann ich wie viel ins Haus jagen möchte.
Hintergrund ist zum einen, kein ultra leeres Akku, wobei der Akku das schon selber übernimmt. (Kann man einstellen)
Hinzu möchte ich natürlich nicht, wie du erklärt hast, bei bestem Wetter den Vorteil der 1800W verlieren. Also möchte ich den Akku quasi schon leerer haben, um dementsprechend laden zu können und gleichzeitig ans Haus weitergeben.
Im Akku kann man folgendes einstellen:
Minimale Ladung in %
Maximale Ladung in %
Abgabe ans Haus in W (Max 800W)
Modus: Batterie First (dann geht alles in die Batterie bis sie voll ist und danach alles ins Haus), Verbraucher First in W
Der erste Modus ist in meinen Augen nicht zu ende gedacht. Daher würde ich zwischen den Modis switchen.
In der original App, kann man dafür Zeiten eingeben. Diese Steuern dann die Modis. Das ist aber auch nur so halb gedacht.
Ich werde mich nochmal genauer in die Doku einlesen und ein wenig warten, aufgrund der Anpassung deinerseits bez. des Attributes.
Danke für die super Erklärungen und vor allem die Freundlichkeit. Das ist hier im Forum gern mal so ne Sache ;)
Gruß,
Kai
Hallo Heiko,
ich habe hier eine sehr verwirrende Aufteilung in der Höhe der drei Balkengrafiken. Siehe Screenshot anbei.
Ich habe keine Höhen festgelegt, also sollte der Standard verwendet werden. Müssten da nicht alle drei Balkengrafiken die gleiche Höhe haben?
Hier noch ein List meines SF-Devices:
define SolarForecast SolarForecast
attr SolarForecast DbLogExclude .*
attr SolarForecast DbLogInclude Current_AutarkyRate:60,AllPVforecastsToEvent,LastHourPVforecast,LastHourPVreal
attr SolarForecast consumer01 KlimaanlagePwr switchdev=Klimaanlage_Sw type=noSchedule power=750 pcurr=power:W etotal=energy:Wh on=on off=off mintime=60 icon=Ventilator_fett auto=Automatik interruptable=1
attr SolarForecast consumer02 MQTT2_Luftentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=light_ceiling auto=Automatik
attr SolarForecast consumer03 MQTT2_Spelunkenentfeuchter type=noSchedule power=500 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=Ventilator_fett auto=Automatik
attr SolarForecast consumer04 MQTT2_ShellyGeschirrspueler type=noSchedule power=1700 pcurr=switch_apower:W etotal=switch_aenergy_total:Wh on=on off=off icon=scene_dishwasher auto=Automatik
attr SolarForecast consumer05 Trockner_Pwr switchdev=Trockner type=noSchedule power=2700 pcurr=power:W:3 etotal=energy:Wh on=on off=off mintime=60 icon=scene_clothes_dryer auto=Automatik
attr SolarForecast consumer06 Waschmaschine_Pwr switchdev=Waschmaschine type=noSchedule power=2100 pcurr=power:W:3 etotal=energy:Wh on=on off=off mintime=60 icon=scene_washing_machine auto=Automatik
attr SolarForecast consumer07 Stromverbrauch_Buero type=noSchedule power=300 pcurr=pcurr:W etotal=etotal:Wh icon=scene_office auto=Automatik
attr SolarForecast consumer08 Stromverbrauch_WoZi type=noSchedule power=500 pcurr=pcurr:W etotal=etotal:Wh icon=scene_livingroom auto=Automatik
attr SolarForecast consumer09 MQTT2_KlimaODU type=noSchedule power=1500 pcurr=params_switch_0_apower:W:10 etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=frost auto=Automatik
attr SolarForecast consumer10 MQTT2_ShellyPlugKuechenKuehlschrank type=noSchedule power=65 pcurr=switch_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_big auto=Automatik
attr SolarForecast consumer11 MQTT2_PlugKaffeemaschine type=noSchedule power=2500 pcurr=params_switch_0_apower:W:6 etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=scene_cockle_stove auto=Automatik
attr SolarForecast consumer12 MQTT2_ShellyPlugKellerKuehlschrank type=noSchedule power=150 pcurr=params_switch_0_apower:W:5 etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=kuehlschrank_small auto=Automatik
attr SolarForecast consumer13 ShellyplugSchuppen type=noSchedule power=100 pcurr=params_switch_0_apower:W etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=building_carport_socket auto=Automatik
attr SolarForecast consumer14 HM_56DBA8_Sw_01 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian
attr SolarForecast consumer15 WallboxLeistungssumme type=other power=11000 pcurr=power:W:5 etotal=total:Wh on=on off=off auto=Automatik mintime=60 icon=wallbox exconfc=1
attr SolarForecast consumer16 HM_35FA43_Sw_07 type=other power=30 on=on off=off auto=Automatik noshow=3 mintime=60 icon=debian mode=can mintime=SunPath:60:-60
attr SolarForecast consumerControl dummyIcon=status_comfort@#ff8c00 showLegend=icon_bottom
attr SolarForecast ctrlDebug none
attr SolarForecast ctrlLanguage DE
attr SolarForecast ctrlSpecialReadings todayBatInSum,todayBatOutSum,todayConsumption,todayGridConsumption,todayGridFeedIn
attr SolarForecast event-aggregator Current_AutarkyRate:150:linear:mean
attr SolarForecast event-min-interval .*:300
attr SolarForecast event-on-change-reading .*
attr SolarForecast flowGraphicControl animate=1 consumerdist=110 showconsumerremaintime=0 h2consumerdist=50 strokewidth=10 homenodedyncol=1 strokeconsumerdyncol=1
attr SolarForecast graphicBeam1Content pvReal
attr SolarForecast graphicBeam2Content pvForecast
attr SolarForecast graphicBeam3Content consumptionForecast
attr SolarForecast graphicBeam4Content consumption
attr SolarForecast graphicBeam5Content feedincome
attr SolarForecast graphicBeam6Content energycosts
attr SolarForecast graphicHeaderDetail all
attr SolarForecast graphicHeaderOwnspec #Aktuell:\
Ü;berschuss:Current_Surplus\
Einspeisung:Current_GridFeedIn\
Netzbezug:Current_GridConsumption\
Autarkie-Rate:Current_AutarkyRate\
#Heute:\
Erzeugt:Today_PVreal\
Bezogen:special_todayGridConsumption\
Eingespeist:special_todayGridFeedIn\
Verbraucht:special_todayConsumption\
#Batterie:\
Status:Akkustatus@Enphase\
SoC ;(%):StorageFullPercent@Enphase\
Heute ;geladen:special_todayBatInSum\
Heute ;entladen:special_todayBatOutSum
attr SolarForecast graphicHistoryHour 4
attr SolarForecast graphicHourStyle :00
attr SolarForecast graphicSelect both
attr SolarForecast graphicShowDiff bottom
attr SolarForecast graphicShowNight 1
attr SolarForecast plantControl consForecastInPlanning=1 batteryPreferredCharge=5 consForecastIdentWeekdays=1 cycleInterval=5 genPVdeviation=continuously
attr SolarForecast room Garten->PV-Anlage
attr SolarForecast setupBatteryDev01 Enphase pin=StorageFeedIn:W pout=StorageConsumption:W pinmax=2500 poutmax=2500 intotal=StorageWhCharged:Wh outtotal=StorageWhDischarged:Wh charge=StorageFullPercent cap=7000 show=1:bottom asynchron=1
attr SolarForecast setupInverterDev01 Enphase pv=wNowProduction:W etotal=whTodayProduction:Wh capacity=10000 asynchron=1 strings=Osten,Westen
attr SolarForecast setupInverterStrings Osten,Westen
attr SolarForecast setupMeterDev MQTT2_SmartMeterReader gcon=Bezug:W contotal=ENERGY_Total:kWh gfeedin=Einspeisung:W feedtotal=ENERGY_Supply:kWh asynchron=1 conprice=28.51:ct feedprice=8.04:ct
attr SolarForecast setupRadiationAPI dwd
attr SolarForecast setupStringPeak Osten=4 Westen=6.4
attr SolarForecast setupWeatherDev1 dwd
attr SolarForecast userReadings Current_Surplus_Num {my $val = ReadingsVal("SolarForecast", "Current_Surplus", "0 W");; return substr($val, 0, index($val, " "));;}
# FUUID 651cfe6b-f33f-e199-c4fb-916e33f2d14b5241
# FVERSION 76_SolarForecast.pm:v1.51.0-s29866/2025-04-16
# LCACHEFILE last write time: 11:15:03 File: ./FHEM/FhemUtils/PVCsm_SolarForecast_SolarForecast
# MODE Automatic / Event-controlled - next planned Cycletime: 11:20:38
# MODEL DWD
# NAME SolarForecast
# NOTIFYDEV MQTT2_SmartMeterReader,KlimaanlagePwr,Klimaanlage_Sw,MQTT2_Luftentfeuchter,MQTT2_Spelunkenentfeuchter,MQTT2_ShellyGeschirrspueler,Trockner_Pwr,Trockner,Waschmaschine_Pwr,Waschmaschine,Stromverbrauch_Buero,Stromverbrauch_WoZi,MQTT2_KlimaODU,MQTT2_ShellyPlugKuechenKuehlschrank,MQTT2_PlugKaffeemaschine,MQTT2_ShellyPlugKellerKuehlschrank,ShellyplugSchuppen,HM_56DBA8_Sw_01,WallboxLeistungssumme,HM_35FA43_Sw_07,Enphase
# NR 776
# NTFY_ORDER 50-SolarForecast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL DWD
# eventCount 41294
# HELPER:
# 14M15DONE 1
# 15M15DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV SolarForecast
# SPGROOM
# VERSION 1.51.0
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 18706
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:14833
# telnet telnetForBlockingFn_1744959215.45784_127.0.0.1_60144
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name SolarForecast
# tsnext 1745057943.84112
# Helper:
# DBLOG:
# AllPVforecastsToEvent:
# logdb:
# TIME 1745013900.43492
# VALUE 0
# Current_AutarkyRate:
# logdb:
# TIME 1745054341.34739
# VALUE 92.5959075875403
# LastHourPVforecast:
# logdb:
# TIME 1745054416.44143
# VALUE 743
# LastHourPVreal:
# logdb:
# TIME 1745054416.44143
# VALUE 1895
# OLDREADINGS:
# READINGS:
# 2025-04-19 11:20:33 Battery_ChargeRecommended_01 1
# 2025-04-19 11:20:33 Current_AutarkyRate 94 %
# 2025-04-19 11:20:33 Current_BatCharge_01 30 %
# 2025-04-19 11:20:33 Current_Consumption 717 W
# 2025-04-19 11:20:33 Current_GridConsumption 43 W
# 2025-04-19 11:20:33 Current_GridFeedIn 0 W
# 2025-04-19 11:20:33 Current_PV 1096 W
# 2025-04-19 11:20:33 Current_PowerBatIn_01 422 W
# 2025-04-19 11:20:33 Current_PowerBatOut_01 0 W
# 2025-04-19 11:20:33 Current_SelfConsumption 674 W
# 2025-04-19 11:20:33 Current_SelfConsumptionRate 61 %
# 2025-04-19 11:20:33 Current_Surplus 379 W
# 2025-04-19 11:20:34 Current_Surplus_Num 379
# 2025-04-19 11:00:00 LastHourGridconsumptionReal 48 Wh
# 2025-04-19 11:00:00 LastHourPVforecast 743 Wh
# 2025-04-19 11:00:00 LastHourPVreal 1895 Wh
# 2025-04-19 11:20:33 NextHours_Sum01_PVforecast 2171 Wh
# 2025-04-19 11:20:33 NextHours_Sum02_PVforecast 3389 Wh
# 2025-04-19 11:20:33 NextHours_Sum03_PVforecast 4844 Wh
# 2025-04-19 11:20:33 NextHours_Sum04_ConsumptionForecast 4380 Wh
# 2025-04-19 11:20:33 NextHours_Sum04_PVforecast 6446 Wh
# 2025-04-19 11:20:33 RestOfDayConsumptionForecast 10024 Wh
# 2025-04-19 11:20:33 RestOfDayPVforecast 10789 Wh
# 2025-04-19 00:59:58 Today_Hour01_BatIn_01 0 Wh
# 2025-04-19 00:59:58 Today_Hour01_BatOut_01 0 Wh
# 2025-04-19 00:59:58 Today_Hour01_GridConsumption 555 Wh
# 2025-04-19 00:59:58 Today_Hour01_GridFeedIn 0 Wh
# 2025-04-19 00:59:58 Today_Hour01_PVreal 0 Wh
# 2025-04-19 01:59:59 Today_Hour02_BatIn_01 0 Wh
# 2025-04-19 01:59:59 Today_Hour02_BatOut_01 0 Wh
# 2025-04-19 01:59:59 Today_Hour02_GridConsumption 548 Wh
# 2025-04-19 01:59:59 Today_Hour02_GridFeedIn 0 Wh
# 2025-04-19 01:59:59 Today_Hour02_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
# 2025-04-19 02:59:59 Today_Hour03_BatIn_01 0 Wh
# 2025-04-19 02:59:59 Today_Hour03_BatOut_01 0 Wh
# 2025-04-19 02:59:59 Today_Hour03_GridConsumption 499 Wh
# 2025-04-19 02:59:59 Today_Hour03_GridFeedIn 0 Wh
# 2025-04-19 02:59:59 Today_Hour03_PVreal 0 Wh
# 2025-04-19 03:59:59 Today_Hour04_BatIn_01 0 Wh
# 2025-04-19 03:59:59 Today_Hour04_BatOut_01 0 Wh
# 2025-04-19 03:59:59 Today_Hour04_GridConsumption 551 Wh
# 2025-04-19 03:59:59 Today_Hour04_GridFeedIn 0 Wh
# 2025-04-19 03:59:59 Today_Hour04_PVreal 0 Wh
# 2025-04-19 04:59:58 Today_Hour05_BatIn_01 0 Wh
# 2025-04-19 04:59:58 Today_Hour05_BatOut_01 0 Wh
# 2025-04-19 04:59:58 Today_Hour05_GridConsumption 523 Wh
# 2025-04-19 04:59:58 Today_Hour05_GridFeedIn 0 Wh
# 2025-04-19 04:59:58 Today_Hour05_PVreal 0 Wh
# 2025-04-19 05:59:58 Today_Hour06_BatIn_01 0 Wh
# 2025-04-19 05:59:58 Today_Hour06_BatOut_01 0 Wh
# 2025-04-19 05:59:58 Today_Hour06_GridConsumption 593 Wh
# 2025-04-19 05:59:58 Today_Hour06_GridFeedIn 0 Wh
# 2025-04-19 05:59:58 Today_Hour06_PVreal 0 Wh
# 2025-04-19 06:59:58 Today_Hour07_BatIn_01 0 Wh
# 2025-04-19 06:59:58 Today_Hour07_BatOut_01 0 Wh
# 2025-04-19 06:59:58 Today_Hour07_GridConsumption 635 Wh
# 2025-04-19 06:59:58 Today_Hour07_GridFeedIn 0 Wh
# 2025-04-19 06:59:58 Today_Hour07_PVforecast 15 Wh
# 2025-04-19 06:59:58 Today_Hour07_PVreal 15 Wh
# 2025-04-19 07:59:58 Today_Hour08_BatIn_01 33 Wh
# 2025-04-19 07:59:58 Today_Hour08_BatOut_01 0 Wh
# 2025-04-19 07:59:58 Today_Hour08_GridConsumption 449 Wh
# 2025-04-19 07:59:58 Today_Hour08_GridFeedIn 0 Wh
# 2025-04-19 07:59:58 Today_Hour08_PVforecast 83 Wh
# 2025-04-19 07:59:58 Today_Hour08_PVreal 143 Wh
# 2025-04-19 08:59:58 Today_Hour09_BatIn_01 9 Wh
# 2025-04-19 08:59:58 Today_Hour09_BatOut_01 0 Wh
# 2025-04-19 08:59:58 Today_Hour09_GridConsumption 124 Wh
# 2025-04-19 08:59:58 Today_Hour09_GridFeedIn 0 Wh
# 2025-04-19 08:59:58 Today_Hour09_PVforecast 333 Wh
# 2025-04-19 08:59:58 Today_Hour09_PVreal 509 Wh
# 2025-04-19 09:59:57 Today_Hour10_BatIn_01 436 Wh
# 2025-04-19 09:59:57 Today_Hour10_BatOut_01 0 Wh
# 2025-04-19 09:59:57 Today_Hour10_GridConsumption 42 Wh
# 2025-04-19 09:59:57 Today_Hour10_GridFeedIn 2 Wh
# 2025-04-19 09:59:57 Today_Hour10_PVforecast 299 Wh
# 2025-04-19 09:59:57 Today_Hour10_PVreal 1139 Wh
# 2025-04-19 10:59:58 Today_Hour11_BatIn_01 1076 Wh
# 2025-04-19 10:59:58 Today_Hour11_BatOut_01 9 Wh
# 2025-04-19 10:59:58 Today_Hour11_GridConsumption 48 Wh
# 2025-04-19 10:59:58 Today_Hour11_GridFeedIn 13 Wh
# 2025-04-19 10:59:58 Today_Hour11_PVforecast 743 Wh
# 2025-04-19 10:59:58 Today_Hour11_PVreal 1895 Wh
# 2025-04-19 11:20:33 Today_Hour12_BatIn_01 395 Wh
# 2025-04-19 11:20:33 Today_Hour12_BatOut_01 0 Wh
# 2025-04-19 11:20:33 Today_Hour12_GridConsumption 14 Wh
# 2025-04-19 11:20:33 Today_Hour12_GridFeedIn 1 Wh
# 2025-04-19 11:20:33 Today_Hour12_PVforecast 2847 Wh
# 2025-04-19 11:20:33 Today_Hour12_PVreal 490 Wh
# 2025-04-19 11:20:33 Today_Hour13_PVforecast 916 Wh
# 2025-04-19 11:20:33 Today_Hour14_PVforecast 1780 Wh
# 2025-04-19 11:20:33 Today_Hour15_PVforecast 850 Wh
# 2025-04-19 11:20:33 Today_Hour16_PVforecast 2999 Wh
# 2025-04-19 11:20:33 Today_Hour17_PVforecast 1257 Wh
# 2025-04-19 11:20:33 Today_Hour18_PVforecast 567 Wh
# 2025-04-19 11:20:33 Today_Hour19_PVforecast 402 Wh
# 2025-04-19 11:20:33 Today_Hour20_PVforecast 141 Wh
# 2025-04-19 11:20:33 Today_Hour21_PVforecast 27 Wh
# 2025-04-19 11:20:33 Today_MaxPVforecast 2999 Wh
# 2025-04-19 11:20:33 Today_MaxPVforecastTime 2025-04-19 15:00:00
# 2025-04-19 11:20:33 Today_PVdeviation -69.68 %
# 2025-04-19 11:20:33 Today_PVforecast 13259 Wh
# 2025-04-19 11:20:33 Today_PVreal 4191 Wh
# 2025-04-19 11:20:33 Today_SunRise 06:03
# 2025-04-19 11:20:33 Today_SunSet 20:21
# 2025-04-19 11:20:33 Tomorrow_ConsumptionForecast 17588 Wh
# 2025-04-19 11:20:33 Tomorrow_PVforecast 49622 Wh
# 2025-04-19 11:20:33 Tomorrow_SunRise 06:00
# 2025-04-19 11:20:33 Tomorrow_SunSet 20:23
# 2025-04-19 11:20:33 consumer01 name='Klimaanlage' state='off' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer01_currentPower 0 W
# 2025-04-19 11:20:33 consumer02 name='Tageslichtlampe' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-04-19 11:20:33 consumer02_currentPower 33.9 W
# 2025-04-19 11:20:33 consumer03 name='Spelunkenentfeuchter' state='off' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer03_currentPower 0 W
# 2025-04-19 11:20:33 consumer04 name='Geschirrspüler' state='on' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer04_currentPower 23.1 W
# 2025-04-19 11:20:33 consumer05 name='Wäschetrockner' state='on' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer05_currentPower 0.03 W
# 2025-04-19 11:20:33 consumer06 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer06_currentPower 0.21 W
# 2025-04-19 11:20:33 consumer07 name='Büro' state='unknown' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer07_currentPower 96.9 W
# 2025-04-19 11:20:33 consumer08 name='Wohnzimmer' state='unknown' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer08_currentPower 223.6 W
# 2025-04-19 11:20:33 consumer09 name='Klimaaußengerät' state='on' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer09_currentPower 9.6 W
# 2025-04-19 11:20:33 consumer10 name='Küchen-Kühlschrank' state='on' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer10_currentPower 56.8 W
# 2025-04-19 11:20:33 consumer11 name='Kaffeemaschine, Toaster, Thermomix' state='on' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer11_currentPower 4.3 W
# 2025-04-19 11:20:33 consumer12 name='Kellerkühlschrank' state='on' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer12_currentPower 0 W
# 2025-04-19 11:20:33 consumer13 name='PlugSchuppen' state='off' mode='can' planningstate='noSchedule'
# 2025-04-19 11:20:33 consumer13_currentPower 0 W
# 2025-04-19 11:20:33 consumer14 name='Teichbelüfter' state='off' mode='can' planningstate='planned'
# 2025-04-19 11:20:33 consumer14_planned_start 19.04.2025 11:15:02
# 2025-04-19 11:20:33 consumer14_planned_stop 19.04.2025 12:15:02
# 2025-04-19 11:20:33 consumer15 name='WallboxLeistungssumme' state='on' mode='can' planningstate='suspended' info='max Überschußprognose zu gering'
# 2025-04-19 11:20:33 consumer15_currentPower 3.112 W
# 2025-04-19 11:20:33 consumer16 name='Skimmer' state='off' mode='can' planningstate='started'
# 2025-04-19 11:20:33 consumer16_planned_start 19.04.2025 09:23:14
# 2025-04-19 11:20:33 consumer16_planned_stop 19.04.2025 19:21:02
# 2025-04-19 11:20:33 nextCycletime 11:20:38
# 2025-04-19 07:00:02 pvCorrectionFactor_07 0.84 (automatic - old factor: 0.76, AI result used, Sun Alt range: 5, Cloud range: 100, Days in range: 3)
# 2025-04-19 08:00:03 pvCorrectionFactor_08 1.03 (automatic - old factor: 0.78, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 3)
# 2025-04-19 09:00:01 pvCorrectionFactor_09 1.03 (automatic - old factor: 0.59, AI result used, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
# 2025-04-19 10:00:03 pvCorrectionFactor_10 1.01 (automatic - old factor: 0.34, Sun Alt range: 30, Cloud range: 100, Days in range: 2)
# 2025-04-19 11:00:03 pvCorrectionFactor_11 1.08 (automatic - old factor: 0.51, AI result used, Sun Alt range: 35, Cloud range: 100, Days in range: 2)
# 2025-04-19 11:20:33 pvCorrectionFactor_Auto on_complex_ai
# 2024-08-24 17:13:20 setupStringAzimuth Osten=-127 Westen=53
# 2025-02-19 10:56:15 setupStringDeclination Osten=38 Westen=38
# 2025-04-19 11:20:33 special_todayBatInSum 1949.0 Wh
# 2025-04-19 11:20:33 special_todayBatOutSum 9.0 Wh
# 2025-04-19 11:20:33 special_todayConsumption 6810 Wh
# 2025-04-19 11:20:33 special_todayGridConsumption 4582 Wh
# 2025-04-19 11:20:33 special_todayGridFeedIn 16.1 Wh
# 2025-04-19 11:20:34 state updated
#
setstate SolarForecast updated
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_ctrlDebug
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicHistoryHour 4
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicShowNight 1
setstate SolarForecast 2025-01-16 10:01:19 .SolarForecast_graphicShowWeather
setstate SolarForecast 2025-04-18 08:53:36 .associatedWith MQTT2_SmartMeterReader KlimaanlagePwr Klimaanlage_Sw MQTT2_Luftentfeuchter MQTT2_Spelunkenentfeuchter MQTT2_ShellyGeschirrspueler Trockner_Pwr Trockner Waschmaschine_Pwr Waschmaschine Stromverbrauch_Buero Stromverbrauch_WoZi MQTT2_KlimaODU MQTT2_ShellyPlugKuechenKuehlschrank MQTT2_PlugKaffeemaschine MQTT2_ShellyPlugKellerKuehlschrank ShellyplugSchuppen HM_56DBA8_Sw_01 WallboxLeistungssumme HM_35FA43_Sw_07 Enphase dwd
setstate SolarForecast 2025-04-19 11:20:33 .lastupdateForecastValues 1745054433
setstate SolarForecast 2025-04-19 11:20:33 .pvCorrectionFactor_Auto_Soll on_complex_ai
setstate SolarForecast 2025-04-19 01:00:03 .signaldone_01 done
setstate SolarForecast 2025-04-19 02:00:06 .signaldone_02 done
setstate SolarForecast 2025-04-19 03:00:06 .signaldone_03 done
setstate SolarForecast 2025-04-19 04:00:04 .signaldone_04 done
setstate SolarForecast 2025-04-19 05:00:00 .signaldone_05 done
setstate SolarForecast 2025-04-19 06:00:01 .signaldone_06 done
setstate SolarForecast 2025-04-19 07:00:02 .signaldone_07 done
setstate SolarForecast 2025-04-19 08:00:03 .signaldone_08 done
setstate SolarForecast 2025-04-19 09:00:01 .signaldone_09 done
setstate SolarForecast 2025-04-19 10:00:03 .signaldone_10 done
setstate SolarForecast 2025-04-19 11:00:03 .signaldone_11 done
setstate SolarForecast 2025-04-19 00:00:08 .signaldone_24 done
setstate SolarForecast 2025-04-19 11:20:33 Battery_ChargeRecommended_01 1
setstate SolarForecast 2025-04-19 11:20:33 Current_AutarkyRate 94 %
setstate SolarForecast 2025-04-19 11:20:33 Current_BatCharge_01 30 %
setstate SolarForecast 2025-04-19 11:20:33 Current_Consumption 717 W
setstate SolarForecast 2025-04-19 11:20:33 Current_GridConsumption 43 W
setstate SolarForecast 2025-04-19 11:20:33 Current_GridFeedIn 0 W
setstate SolarForecast 2025-04-19 11:20:33 Current_PV 1096 W
setstate SolarForecast 2025-04-19 11:20:33 Current_PowerBatIn_01 422 W
setstate SolarForecast 2025-04-19 11:20:33 Current_PowerBatOut_01 0 W
setstate SolarForecast 2025-04-19 11:20:33 Current_SelfConsumption 674 W
setstate SolarForecast 2025-04-19 11:20:33 Current_SelfConsumptionRate 61 %
setstate SolarForecast 2025-04-19 11:20:33 Current_Surplus 379 W
setstate SolarForecast 2025-04-19 11:20:34 Current_Surplus_Num 379
setstate SolarForecast 2025-04-19 11:00:00 LastHourGridconsumptionReal 48 Wh
setstate SolarForecast 2025-04-19 11:00:00 LastHourPVforecast 743 Wh
setstate SolarForecast 2025-04-19 11:00:00 LastHourPVreal 1895 Wh
setstate SolarForecast 2025-04-19 11:20:33 NextHours_Sum01_PVforecast 2171 Wh
setstate SolarForecast 2025-04-19 11:20:33 NextHours_Sum02_PVforecast 3389 Wh
setstate SolarForecast 2025-04-19 11:20:33 NextHours_Sum03_PVforecast 4844 Wh
setstate SolarForecast 2025-04-19 11:20:33 NextHours_Sum04_ConsumptionForecast 4380 Wh
setstate SolarForecast 2025-04-19 11:20:33 NextHours_Sum04_PVforecast 6446 Wh
setstate SolarForecast 2025-04-19 11:20:33 RestOfDayConsumptionForecast 10024 Wh
setstate SolarForecast 2025-04-19 11:20:33 RestOfDayPVforecast 10789 Wh
setstate SolarForecast 2025-04-19 00:59:58 Today_Hour01_BatIn_01 0 Wh
setstate SolarForecast 2025-04-19 00:59:58 Today_Hour01_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 00:59:58 Today_Hour01_GridConsumption 555 Wh
setstate SolarForecast 2025-04-19 00:59:58 Today_Hour01_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 00:59:58 Today_Hour01_PVreal 0 Wh
setstate SolarForecast 2025-04-19 01:59:59 Today_Hour02_BatIn_01 0 Wh
setstate SolarForecast 2025-04-19 01:59:59 Today_Hour02_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 01:59:59 Today_Hour02_GridConsumption 548 Wh
setstate SolarForecast 2025-04-19 01:59:59 Today_Hour02_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 01:59:59 Today_Hour02_PVreal 0 Wh (WARNING invalid real PV occured - see Logfile)
setstate SolarForecast 2025-04-19 02:59:59 Today_Hour03_BatIn_01 0 Wh
setstate SolarForecast 2025-04-19 02:59:59 Today_Hour03_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 02:59:59 Today_Hour03_GridConsumption 499 Wh
setstate SolarForecast 2025-04-19 02:59:59 Today_Hour03_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 02:59:59 Today_Hour03_PVreal 0 Wh
setstate SolarForecast 2025-04-19 03:59:59 Today_Hour04_BatIn_01 0 Wh
setstate SolarForecast 2025-04-19 03:59:59 Today_Hour04_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 03:59:59 Today_Hour04_GridConsumption 551 Wh
setstate SolarForecast 2025-04-19 03:59:59 Today_Hour04_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 03:59:59 Today_Hour04_PVreal 0 Wh
setstate SolarForecast 2025-04-19 04:59:58 Today_Hour05_BatIn_01 0 Wh
setstate SolarForecast 2025-04-19 04:59:58 Today_Hour05_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 04:59:58 Today_Hour05_GridConsumption 523 Wh
setstate SolarForecast 2025-04-19 04:59:58 Today_Hour05_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 04:59:58 Today_Hour05_PVreal 0 Wh
setstate SolarForecast 2025-04-19 05:59:58 Today_Hour06_BatIn_01 0 Wh
setstate SolarForecast 2025-04-19 05:59:58 Today_Hour06_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 05:59:58 Today_Hour06_GridConsumption 593 Wh
setstate SolarForecast 2025-04-19 05:59:58 Today_Hour06_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 05:59:58 Today_Hour06_PVreal 0 Wh
setstate SolarForecast 2025-04-19 06:59:58 Today_Hour07_BatIn_01 0 Wh
setstate SolarForecast 2025-04-19 06:59:58 Today_Hour07_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 06:59:58 Today_Hour07_GridConsumption 635 Wh
setstate SolarForecast 2025-04-19 06:59:58 Today_Hour07_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 06:59:58 Today_Hour07_PVforecast 15 Wh
setstate SolarForecast 2025-04-19 06:59:58 Today_Hour07_PVreal 15 Wh
setstate SolarForecast 2025-04-19 07:59:58 Today_Hour08_BatIn_01 33 Wh
setstate SolarForecast 2025-04-19 07:59:58 Today_Hour08_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 07:59:58 Today_Hour08_GridConsumption 449 Wh
setstate SolarForecast 2025-04-19 07:59:58 Today_Hour08_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 07:59:58 Today_Hour08_PVforecast 83 Wh
setstate SolarForecast 2025-04-19 07:59:58 Today_Hour08_PVreal 143 Wh
setstate SolarForecast 2025-04-19 08:59:58 Today_Hour09_BatIn_01 9 Wh
setstate SolarForecast 2025-04-19 08:59:58 Today_Hour09_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 08:59:58 Today_Hour09_GridConsumption 124 Wh
setstate SolarForecast 2025-04-19 08:59:58 Today_Hour09_GridFeedIn 0 Wh
setstate SolarForecast 2025-04-19 08:59:58 Today_Hour09_PVforecast 333 Wh
setstate SolarForecast 2025-04-19 08:59:58 Today_Hour09_PVreal 509 Wh
setstate SolarForecast 2025-04-19 09:59:57 Today_Hour10_BatIn_01 436 Wh
setstate SolarForecast 2025-04-19 09:59:57 Today_Hour10_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 09:59:57 Today_Hour10_GridConsumption 42 Wh
setstate SolarForecast 2025-04-19 09:59:57 Today_Hour10_GridFeedIn 2 Wh
setstate SolarForecast 2025-04-19 09:59:57 Today_Hour10_PVforecast 299 Wh
setstate SolarForecast 2025-04-19 09:59:57 Today_Hour10_PVreal 1139 Wh
setstate SolarForecast 2025-04-19 10:59:58 Today_Hour11_BatIn_01 1076 Wh
setstate SolarForecast 2025-04-19 10:59:58 Today_Hour11_BatOut_01 9 Wh
setstate SolarForecast 2025-04-19 10:59:58 Today_Hour11_GridConsumption 48 Wh
setstate SolarForecast 2025-04-19 10:59:58 Today_Hour11_GridFeedIn 13 Wh
setstate SolarForecast 2025-04-19 10:59:58 Today_Hour11_PVforecast 743 Wh
setstate SolarForecast 2025-04-19 10:59:58 Today_Hour11_PVreal 1895 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour12_BatIn_01 395 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour12_BatOut_01 0 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour12_GridConsumption 14 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour12_GridFeedIn 1 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour12_PVforecast 2847 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour12_PVreal 490 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour13_PVforecast 916 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour14_PVforecast 1780 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour15_PVforecast 850 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour16_PVforecast 2999 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour17_PVforecast 1257 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour18_PVforecast 567 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour19_PVforecast 402 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour20_PVforecast 141 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_Hour21_PVforecast 27 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_MaxPVforecast 2999 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_MaxPVforecastTime 2025-04-19 15:00:00
setstate SolarForecast 2025-04-19 11:20:33 Today_PVdeviation -69.68 %
setstate SolarForecast 2025-04-19 11:20:33 Today_PVforecast 13259 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_PVreal 4191 Wh
setstate SolarForecast 2025-04-19 11:20:33 Today_SunRise 06:03
setstate SolarForecast 2025-04-19 11:20:33 Today_SunSet 20:21
setstate SolarForecast 2025-04-19 11:20:33 Tomorrow_ConsumptionForecast 17588 Wh
setstate SolarForecast 2025-04-19 11:20:33 Tomorrow_PVforecast 49622 Wh
setstate SolarForecast 2025-04-19 11:20:33 Tomorrow_SunRise 06:00
setstate SolarForecast 2025-04-19 11:20:33 Tomorrow_SunSet 20:23
setstate SolarForecast 2025-04-19 11:20:33 consumer01 name='Klimaanlage' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer01_currentPower 0 W
setstate SolarForecast 2025-04-19 11:20:33 consumer02 name='Tageslichtlampe' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate SolarForecast 2025-04-19 11:20:33 consumer02_currentPower 33.9 W
setstate SolarForecast 2025-04-19 11:20:33 consumer03 name='Spelunkenentfeuchter' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer03_currentPower 0 W
setstate SolarForecast 2025-04-19 11:20:33 consumer04 name='Geschirrspüler' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer04_currentPower 23.1 W
setstate SolarForecast 2025-04-19 11:20:33 consumer05 name='Wäschetrockner' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer05_currentPower 0.03 W
setstate SolarForecast 2025-04-19 11:20:33 consumer06 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer06_currentPower 0.21 W
setstate SolarForecast 2025-04-19 11:20:33 consumer07 name='Büro' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer07_currentPower 96.9 W
setstate SolarForecast 2025-04-19 11:20:33 consumer08 name='Wohnzimmer' state='unknown' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer08_currentPower 223.6 W
setstate SolarForecast 2025-04-19 11:20:33 consumer09 name='Klimaaußengerät' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer09_currentPower 9.6 W
setstate SolarForecast 2025-04-19 11:20:33 consumer10 name='Küchen-Kühlschrank' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer10_currentPower 56.8 W
setstate SolarForecast 2025-04-19 11:20:33 consumer11 name='Kaffeemaschine, Toaster, Thermomix' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer11_currentPower 4.3 W
setstate SolarForecast 2025-04-19 11:20:33 consumer12 name='Kellerkühlschrank' state='on' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer12_currentPower 0 W
setstate SolarForecast 2025-04-19 11:20:33 consumer13 name='PlugSchuppen' state='off' mode='can' planningstate='noSchedule'
setstate SolarForecast 2025-04-19 11:20:33 consumer13_currentPower 0 W
setstate SolarForecast 2025-04-19 11:20:33 consumer14 name='Teichbelüfter' state='off' mode='can' planningstate='planned'
setstate SolarForecast 2025-04-19 11:20:33 consumer14_planned_start 19.04.2025 11:15:02
setstate SolarForecast 2025-04-19 11:20:33 consumer14_planned_stop 19.04.2025 12:15:02
setstate SolarForecast 2025-04-19 11:20:33 consumer15 name='WallboxLeistungssumme' state='on' mode='can' planningstate='suspended' info='max Überschußprognose zu gering'
setstate SolarForecast 2025-04-19 11:20:33 consumer15_currentPower 3.112 W
setstate SolarForecast 2025-04-19 11:20:33 consumer16 name='Skimmer' state='off' mode='can' planningstate='started'
setstate SolarForecast 2025-04-19 11:20:33 consumer16_planned_start 19.04.2025 09:23:14
setstate SolarForecast 2025-04-19 11:20:33 consumer16_planned_stop 19.04.2025 19:21:02
setstate SolarForecast 2025-04-19 11:20:33 nextCycletime 11:20:38
setstate SolarForecast 2025-04-19 07:00:02 pvCorrectionFactor_07 0.84 (automatic - old factor: 0.76, AI result used, Sun Alt range: 5, Cloud range: 100, Days in range: 3)
setstate SolarForecast 2025-04-19 08:00:03 pvCorrectionFactor_08 1.03 (automatic - old factor: 0.78, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 3)
setstate SolarForecast 2025-04-19 09:00:01 pvCorrectionFactor_09 1.03 (automatic - old factor: 0.59, AI result used, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
setstate SolarForecast 2025-04-19 10:00:03 pvCorrectionFactor_10 1.01 (automatic - old factor: 0.34, Sun Alt range: 30, Cloud range: 100, Days in range: 2)
setstate SolarForecast 2025-04-19 11:00:03 pvCorrectionFactor_11 1.08 (automatic - old factor: 0.51, AI result used, Sun Alt range: 35, Cloud range: 100, Days in range: 2)
setstate SolarForecast 2025-04-19 11:20:33 pvCorrectionFactor_Auto on_complex_ai
setstate SolarForecast 2024-08-24 17:13:20 setupStringAzimuth Osten=-127 Westen=53
setstate SolarForecast 2025-02-19 10:56:15 setupStringDeclination Osten=38 Westen=38
setstate SolarForecast 2025-04-19 11:20:33 special_todayBatInSum 1949.0 Wh
setstate SolarForecast 2025-04-19 11:20:33 special_todayBatOutSum 9.0 Wh
setstate SolarForecast 2025-04-19 11:20:33 special_todayConsumption 6810 Wh
setstate SolarForecast 2025-04-19 11:20:33 special_todayGridConsumption 4582 Wh
setstate SolarForecast 2025-04-19 11:20:33 special_todayGridFeedIn 16.1 Wh
setstate SolarForecast 2025-04-19 11:20:34 state updated
Viele Grüße und frohe Ostertage!
Peter
@Kai,
bezüglich Batterie Optimierung hat das Modul bereits Logik an Bord welche genau deine Anforderung abdeckt. Möglichereise kannst du es nutzen. Ich habe es im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Aktivierung_des_Batterie_SOC-Managements) beschrieben.
LG,
Heiko
Hallo Peter,
ZitatIch habe keine Höhen festgelegt, also sollte der Standard verwendet werden. Müssten da nicht alle drei Balkengrafiken die gleiche Höhe haben?
Nein. Die Höhe der Ebenen wird dynamisch berechnet um abhängig von der vorkommenden Balkenhöhe (Min/Max) eine optimale Platzverwendung zu haben und nicht zuviel Freiplatz. Mit den Attr graphicBeamHeightLevelX legt man
Multiplikatoren fest, die Einfluß auf die Dynamik dieser Berechnungen haben.
Anbei ein Beispiel. Meine Ebene 3 stellt kaum Werte dar. Durch die Dynamik wird der Freiplatz minimiert.
Um Level3 zu vergrößern, ist im 2. Screenshot graphicBeamHeightLevel3=1500 eingestellt.
LG,
Heiko
Hallo zusammen,
um uns die Arbeit mit der Consumersteuerung zu erleichtern, kann in den Schlüsseln interruptable, swoncond, swoffcond und spignorecond neben den Regex-Bedingungen auch {Perl-Code} verwendet werden. Das sicherlich für viele User eine Erleichterung:
interruptable definiert die möglichen Unterbrechungsoptionen für den Verbraucher nachdem er gestartet ....
Device:Reading:{Perl-Code} - Verbraucher wird temporär unterbrochen, wenn der Perl-Code 'wahr' zurückgibt oder unzureichender
PV Überschuß (wenn power ungleich 0) vorliegt und wird wieder eingeschaltet, wenn der Perl-Code 'falsch' zurückgibt und PV Überschuß
(wenn power ungleich 0) vorliegt. Der Wert von Device:Reading wird dem Code mit der Variable $VALUE übergeben.
Der Code ist in {..} einzuschließen und darf keine Leerzeichen enthalten.
Beispiel -> swoffcond:EcoFlow:data_data_socSum:{$VALUE==100?1:0}
Weiterhin werden zusätzlich zu den Werten auch die Schlüsselnamen der Sammelattribute bei der Eingabe geprüft um Verschreiber abzufangen.
Die V1.51.1 liegt bei mir im contrib. Wie immer Restart nach dem Download ausführen.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 19 April 2025, 13:46:15Mit den Attr graphicBeamHeightLevelX legt man Multiplikatoren fest
Danke für die Erklärung. Jetzt hab ich das endlich kapiert.
Viele Grüße,
Peter
Hallo Heiko,
die Balkengrafik scheint sich verändert zu haben, FVERSION
76_SolarForecast.pm:v1.51.0-s29866/2025-04-16
Vorher war die Dimension einheitlich bei kWh, jetzt sind die Prognosen in Wh und die tatsächlichen Werte in kWh.
Viele Grüße Gisbert
Hallo Gisbert,
auf dem Bild sieht doch alles ok für mich aus. Kann bei mir auch kein Problem feststellen.
Mit Mouse-Over über dem Balken sieht man die Einheit.
LG,
Heiko
Hallo Heiko
ich meine die Werte, die durch das Attribut graphicShowDiff ein- bzw. ausgeblendet werden können.
Aus der Erinnerung heraus hatten diese Werte auch die Einheit kWh und nicht Wh wie jetzt. Ich finde die Einheit kWh, wie früher, besser kompatibel zu den Werten in der Balkengrafik.
Viele Grüße Gisbert
Ach jetzt weiß ich was du meinst.
Naja, das kommt daher, weil wir inzwischen auch Batterie SoC in % und Preise in € (feedin) darstellen können und dafür eine kWh Umrechnung in Diff nicht passt.
Ich schau nochmal ob ich da noch eine Bedingung zur Unterscheidung einbauen kann.
LG,
Heiko
Hallo Gisbert, @all,
ich habe dein Thema bzgl. graphicShowDiff Wh<->kWh gelöst. Es werden diesbezüglich nur Energiewerte in der Balkengrafik berücksichtigt.
Weiterhin habe ich eine Anregung von kask (Danke dafür!) umgesetzt und einen Setter 'attrKeyVal' integriert. Damit können in den Sammelattributen beliebige (valide) <Schlüssel=Wert> Paare gesetzt oder geändert werden.
attrKeyVal <Attribut> [<Gerät>] <Schlüssel=Wert>
Es können ein oder mehrere Schlüssel=Wert Paare in den Sammelattributen (aiControl, consumerXX, plantControl, setup.*, etc.) neu gesetzt oder verändert werden.
Ist ein Gerät obligatorisch, wie in den setup.*-Attributen verlangt, kann es ebenfalls gesetzt oder geändert werden. Es erfolgt eine automatische Speicherung der Änderung.
Beispiel:
set <name> attrKeyVal setupBatteryDev01 asynchron=1
set <name> attrKeyVal setupBatteryDev02 BatteryDummy2 asynchron=1
set <name> attrKeyVal plantControl cycleInterval=77
set <name> attrKeyVal plantControl batteryPreferredCharge=0 consForecastInPlanning=1 cycleInterval=77
Dadurch ist es manuell oder programmtechnisch möglich, Werte selektiv in diesen Attributen zu ändern. Das erschließt perspektivisch auch die Möglichkeit, die aktuellen Setter setupStringAzimuth, setupStringDeclination in Attribute zu überführen, da sie bei Nachführanlagen ebenfalls als dynamische Attribute gesetzt werden können. Es ist ein weiterer Schritt zu konsistenten Look&Feel.
Das Update der V 1.51.1 liegt in meinem contrib. Nach Download Restart durchführen nicht vergessen.
LG,
Heiko
Die V 1.51.1 ist eingecheckt und morgen früh im Update enthalten.
Grüße,
Heiko
Hallo zusammen,
das Attribut 'graphicSelect' ist erweitert und mit dem Getter 'get ... html ...' harmonisiert. Somit hat get ... html die gleichen Optionen wie graphicSelect und umgekehrt.
Die Erweiterung von 'graphicSelect' betrifft die von peterboeckmann gwünschte Möglichkeit, Balken- und Fußgrafik in ihrer Reihenfolge vertauschen zu können. Dazu gibt es in dem Attribut bzw. dem Getter 'html' folgende zusätzlichen Optionen:
swap wie 'both', mit vertauschter Balken- und Energieflußgrafik Reihenfolge
swap_noHead wie 'both_noHead', mit vertauschter Balken- und Energieflußgrafik Reihenfolge
swap_noCons wie 'both_noCons', mit vertauschter Balken- und Energieflußgrafik Reihenfolge
swap_noHead_noCons wie 'both_noHead_noCons', mit vertauschter Balken- und Energieflußgrafik Reihenfolge
Im Zuge dieser Weiterentwicklung ist das Attr graphicHeaderShow sowie consumerControl->showLegend=none obsolet geworden. Beides wird durch die möglichen Optionen von graphicSelect abgedeckt.
Die Version 1.51.2 liegt in meinem Contrib. Restart nach Download wie gewohnt nicht vergessen.
LG,
Heiko
Und die V 1.51.2 ist auch eingecheckt und morgen früh im Update enthalten.
LG
Hallo Heiko,
Vielen Dank dafür:
Zitat von: DS_Starter am 21 April 2025, 14:34:39Die Erweiterung von 'graphicSelect' betrifft die von peterboeckmann gwünschte Möglichkeit, Balken- und Fußgrafik in ihrer Reihenfolge vertauschen zu können.
Ich habe die V soeben gezogen, sieht auf den ersten Blick sehr gut aus.
Edit: Immer wieder toll zu sehen, wie Dein Modul wächst.
Viele Grüße,
Peter
Danke Peter :)
Stück für Stück ...
Lg,
Heiko
swap_noCons ist so ganz meins ;)
Hallo zusammen,
in meinem contrib liegt die V 1.51.3.
Die Setter setupStringAzimuth und setupStringDeclination werden in die Attribute setupStringAzimuth bzw. setupStringDeclination umgesetzt. Die Setter sind danach nicht mehr vorhanden.
Der Vorgang erfolgt automatisch.
WICHTIG: Nach dem Download der Version direkt FHEM restarten. Nachdem FHEM wieder gestartet ist, die umgesetzte Struktur (Attribute) mit "save" speichern. Damit ist die Umsetzung abgeschlossen.
Weiterhin habe ich eine kleine Änderung im Balloon-Popup der Batterie in der Balkengrafik vorgenommen. Der Hinweis "keine Ladeempfehlung" ist ersetzt durch "laden wenn über Einspeiselimit". Dieser Hinweis trifft diesen Status deutlich besser, denn die Batterie kann/soll durchaus geladen werden, wenn eine Einspeisung über dem gesetzten Limit der Anlage (Attr plantControl->feedinPowerLimit) erfolgt. Genau dieser Mechanismus soll eine eventuelle Abregelung der Anlage verhindern.
LG,
Heiko
Moin,
seit heute wird bei mir die Verbrauchsgrafik nicht mehr richtig angezeigt.
Hat sich irgendwas verändert?
graphicBeamHeightLevel3 hat leider keine Auswirkung.
V 1.51.2
Mit freundlichen Grüßen
Bei mir sieht weiterhin alles gut aus:
Hab bis heute Mittag V1.51.2 genutzt - aktuell bin ich auf V1.51.3
Alle "graphicBeamHeightLevel1/2/3" stehen bei mir auf dem Wert "300"
Gruß
300P
Setze doch graphicBeamHeightLevel3 auf einen deutlich höheren Wert, z.B. 1500.
Bei mir wird der Level dann deutlich übergewichtet.
Done
Nach setzen des Attribut graphicShowNight 1habe ich den Fehler gefunden. Es war ein Aussreisser gestern Abend, sieh Bild.
Nach löschen mit set PV_forecast reset consumptionHistory 22 23ist alles wieder wie es sein soll.
Danke für den Hinweis, dass es wohl an meinem FHEM/Device liegen muss.
Mit freundlichen Grüßen
Oh ja, das erklärt natürlich die Problematik.
Hallo Heiko,
ich habe heute Morgen ein Update gemacht. Diese Meldungen sind mir im Log aufgefallen:
2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
VG und Danke für Deinen Einsatz hier,
Guido.
Morgen Guido,
da wird das SF Device vor dem FHEMWEB Device beim Start erzeugt. Das ist nicht weiter tragisch, aber vllt. bekomme ich die Warnung weg in solchen Fällen. Muß ich mal schauen.
LG,
Heiko
Wurde in einem der letzten Releases eigentlich die Berechnung des "realen Verbrauchs" für die Balkengrafik angepasst?
Seit ein paar Releases ändert sich der angezeigte tatsächliche Verbrauch der laufenden Stunde sehr häufig, insbesondere wird der auch immer wieder weniger.
Früher war das meiner Meinung nach exakt die Summe aus "Bezug" plus "Erzeugung minus Einspeisung", nun habe ich das Gefühl, dass der Momentanverbrauch auch irgendwie mit berücksichtigt wird und daraus eine Hochrechnung versucht wird?
Die Verbrauchsberechnung und deren Darstellung ist nicht geändert.
Allerdings ist die Ermittlung des realen Verbrauchs ein wenig komplexer als von dir geschrieben.
Dazu gibt es ein Kapitel im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?).
LG,
Heiko
Zitat von: DS_Starter am 24 April 2025, 11:43:57Allerdings ist die Ermittlung des realen Verbrauchs ein wenig komplexer als von dir geschrieben.
Im Falle von Batterien oder sonstigen Erzeugern ja, in meinem einfachen Fall "PV-Anlage ohne Speicher" ist es exakt was ich geschrieben habe, nämlich die Summe aus "Bezug" plus "Erzeugung minus Einspeisung"
Zitat aus dem Wiki:
ZitatVerbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
Im Wiki steht auch, dass die Werte mit jedem Zyklus "Attribut plantControl->cycleInterval" gesammelt und der Verbrauch ermittelt wird. So wie ich das sehe, ändern sich die Werte aber bei jedem Event, das zu einer Neuberechnung in SolarForecast führt.
Werden dann auch alle für die Berechnung nötigen Werte "frisch abgeholt" oder ggf. teilweise Werte des letzten regulären Zyklusses verwendet?
Ich beobachte, dass der IST-Verbrauch in der Balkengrafik größere Sprünge macht, die mit den aktuellen Werten nicht erklärbar sind.
PV-Erzeugung hat eine Auflösung von 10 Wh, Netzbezug und -einspeisung haben eine Auflösung von 1 Wh, d.h. die Sprünge könnten höchstens durch diese unterschiedliche Auflösung in ebendiesem Bereich stattfinden.
Allerdings habe ich zusätzliche Event-Schwellen bei PV-Erzeugung in Höhe von 1 kWh bzw. bei den Smartmeter-Zählerständen in Höhe von 0.1 kWh gesetzt. Wenn also diese Schwellen verwendet werden und nicht die "Live-Werte", könnte es zu größeren Schwankungen kommen.
ZitatIm Wiki steht auch, dass die Werte mit jedem Zyklus "Attribut plantControl->cycleInterval" gesammelt und der Verbrauch ermittelt wird. So wie ich das sehe, ändern sich die Werte aber bei jedem Event, das zu einer Neuberechnung in SolarForecast führt.
Ja, das ist natürlich richtig und habe ich gleich ergänzt.
ZitatWerden dann auch alle für die Berechnung nötigen Werte "frisch abgeholt" oder ggf. teilweise Werte des letzten regulären Zyklusses verwendet?
Alle Werte werden neu gelesen. Die Zyklen gemäß Zeitplan unterscheiden sich inhaltlich nicht von den Eventzyklen.
Um nähere Informationen zu bekommen, sollte dir ctrlDebug=collectData helfen. Nach den ganze Wetterdaten kommen die gelieferten Werte der Geräte, z.B.:
2025.04.24 17:07:12.176 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2025.04.24 17:07:12.176 1: SolCast DEBUG> gcon: 11.4 W, gfeedin: 0 W, contotal: 1001574.9 Wh, feedtotal: 3476679.9 Wh
2025.04.24 17:07:12.177 1: SolCast DEBUG> write to pvHistory - day: 24, hod: 18, GridConsumption (gcons): 3 Wh
2025.04.24 17:07:12.177 1: SolCast DEBUG> collect Battery Readings data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2025.04.24 17:07:12.178 1: SolCast DEBUG> pin: 0 W, pout: 334 W, totalin: 4840059.83604193 Wh, totalout: 4722562.66920408 Wh, soc: 87
2025.04.24 17:07:12.192 1: SolCast DEBUG> EnergyConsumption input -> PV: 20, PP: 0, GridIn: 0, GridCon: 3, BatIn: 0, BatOut: 43
2025.04.24 17:07:12.192 1: SolCast DEBUG> EnergyConsumption result -> 66 Wh
Möglicherweise verletzen manche Geräte die Forderung nach einem sich ortlaufend erhöhenden Zähler. Das Debug sollte dann auch entsprechende Mitteilungen zeigen.
LG,
Heiko
Hallo!
Ich bin derzeit dabei meinen RAM-Bedarf in FHEM zu untersuchen. Von 180MB (maximal) vor einem Jahr bin ich mittlerweile bei 360MB direkt nach einem Neustart. Dies auch kontinuierlich ansteigend.
Bei mir benötigte SolarForecast ca. 110MB. Zumindest war der RAM-Bedarf ca. 110MB weniger nach einem neustart, als ich SF entfernt hatte.
Jetzt habe ich SF wieder neu eingerichtet. Jetzt liege ich bei ca. 280MB RAM. SF Benötigt nur noch 10-20MB. Ist aber auch noch wieder im Lernprozess. Habe nur das Device selbst danach wiederhergestellt. So wichtig sind die bisher gesammelten Daten da für mich nicht. Ich benötige es eigentlich nur um ein paar Verbraucher zu schalten, wenn genug Strom da ist.
Ist es richtig, das mit der Zeit der Bedarf immer weiter wächst?
Ich beobachte in regelmäßigen Abständen, das der Bedarf Sprunghaft um 5-8MB einmal am Tag steigt. (Nur bei aktiviertem SF) So habe ich derzeit immer nur ein paar Tage Laufzeit von FHEM bis ich zu viel RAM verbrauche.
Ist der RAM-Verbrauch "normal" und ich sollte mein System lieber weiter aufrüsten? Oder liegt es nur an meiner Installation?
Gruß
Bismosa
Tendenziell wird durch Datensammlung und vor allem durch KI Prozesse der Speicherbedarf wachsen. Allerdings hat alles seine Grenzen bzw. kann man darauf Einfluß nehmen.
Insbesondere kannst du zwei Dinge einstellen:
- das Attr aiControl->aiStorageDuration auf einen ganz niedrigen Wert setzen. Dadurch werden nur ganz wenige KI-Rawdaten gehalten. Einmal in der Nacht erfolgt die Löschung, Kontrolle mit get ... valDecTree aiRawData.
- das Attr aiControl->aiTreesPV auf 1 setzen. Das reduziert stark den Umfang der Random Trees, Kontrolle mit get ... valDecTree aiRuleStrings.
Damit dürftest du die stärksten Ressourcenfresser reduziert haben wenn du diese Funktionen nicht benutzt.
Die restlichen Speicher wie pvHistory und pvCircular werden regelmäßig überschrieben und sollten nicht so stark beitragen.
Zitatch beobachte in regelmäßigen Abständen, das der Bedarf Sprunghaft um 5-8MB einmal am Tag steigt.
Das kommt durch die KI RandomTree Berechnung.
ZitatSo habe ich derzeit immer nur ein paar Tage Laufzeit von FHEM bis ich zu viel RAM verbrauche.
Bei nur einem SF-Device kommt mir ein wenig merkwürdig vor. Auf meinem P-system laufen 6! SF-Devices parallel. Jedes davon sammelt in vollem Umfang Daten.
Man sieht im Screenshot wie der RAM eine Zeit lang steigt, sich aber dann einpendelt.
Allerdings läuft auf dem Server so ziemlich alles was es bei mir gibt (1213 Entitäten).
Vielleicht liegt es auch an deiner Perl-Version. Hatten wir ja schon öfter. Bei mir Perl 5.36
Grüße,
Heiko
Hallo!
Danke für die schnelle und sehr ausführliche Antwort!
:o 800MB RAM? Ok...da brauche ich noch ein bisschen. Dann liege ich mit meinen 360MB (und mein System ist nicht gerade klein...über 1000 devices) ja noch gut im Rennen.
Ich habe das Attribut aiControl nun gesetzt und werde das mal weiter beobachten. Perl habe ich ebenfalls 5.36
Und über eine Hardwareerweiterung sollte ich dann auch dringend mal nachdenken :)
Gruß
Bismosa
Man gönnt sich ja sonst nichts ;)
Die SF-Instanzen haben jeweils ca. 5000 bis 8000 KI-Rawdatensätze und jeweils 10 RandowmTrees mit jeweils ca. 7000 Knoten und 10 x 5200 Regeln. Das wird alles im Ram gehalten. Dadurch leifert die KI ein Abfragergebnis innerhalb von 0.06 ms. Das ist wichtig für die Gesamtperformance, denn diese Zeit würde FHEM direkt ausbremsen. Deswegen achte ich darauf. Trotz der Komplexität brauchen meine SF-Devices pro Zyklus nur etwa 40 ms. Das variiert natürlich etwas je nachdem ob physische Devices geschaltet werden müssen usw.
LG,
Heiko
@all,
ich habe noch einige Attribute identifiziert, die m.M. nach selten bis sehr selten genutzt bzw. nach ihrer Festlegung geändert werden.
Diese Attribute würde ich unter einem Attr "graphicControl" zusammenfassen:
graphicBeamWidth
graphicHourCount
graphicEnergyUnit
graphicHeaderDetail
graphicHourStyle
graphicLayoutType
graphicSpaceSize
Natürlich kann man diese Schlüssel dann wieder über den Setter attrKeyVal selektiv ändern.
Gibt es andere Meinungen/Ergänzungen dazu?
Zitat von: bismosa am 24 April 2025, 18:01:48bei 360MB direkt nach einem Neustart. Dies auch kontinuierlich ansteigend.
Was verwendest Du denn sonst noch?
Ich habe vor einiger Zeit festgestellt, dass fhempy (verwende ich für tuyalocal) bei mir zu permanent steigendem RAM-Verbrauch führt. Warum das so ist, konnte ich noch nicht ergründen. Ich helfe mir nun damit, dass ich fhempy mittels watchdog neu starte, wenn die RAM-Auslastung über eine bestimmte Schwelle geht.
Ich plane schon lange mein System von einem RasPi 3B (1 GB RAM) auf einen 4B mit 4 GB RAM umzuziehen und bei der Gelegenheit auch gleich die ganzen aufgesteckten HATs umzubauen sowie die weitere Verkabelung auf abnehmbare Schraubterminals zu ändern, aber irgendwie fehlt mir die Motivation dafür... never change a running system.
Zitat von: TheTrumpeter am 25 April 2025, 07:06:13Ich plane schon lange mein System von einem RasPi 3B (1 GB RAM) auf einen 4B mit 4 GB RAM umzuziehen und bei der Gelegenheit auch gleich die ganzen aufgesteckten HATs umzubauen sowie die weitere Verkabelung auf abnehmbare Schraubterminals zu ändern, aber irgendwie fehlt mir die Motivation dafür... never change a running system.
Bau dir eine WP ein und lass den HZB dann doch mal alles im Raum "fluten" :o - dann MUSST du es tun......hab Erfahrung damit :'(
;D
Gruß
300P
Zitat von: DS_Starter am 24 April 2025, 23:13:33@all,
ich habe noch einige Attribute identifiziert, die m.M. nach selten bis sehr selten genutzt bzw. nach ihrer Festlegung geändert werden.
Diese Attribute würde ich unter einem Attr "graphicControl" zusammenfassen:
.......
Natürlich kann man diese Schlüssel dann wieder über den Setter attrKeyVal selektiv ändern.
Gibt es andere Meinungen/Ergänzungen dazu?
Keine Einwände meinerseits
Zitat von: 300P am 25 April 2025, 09:16:49Bau dir eine WP ein und lass den HZB dann doch mal alles im Raum "fluten" :o - dann MUSST du es tun......hab Erfahrung damit :'(
WP heißt Wärmepumpe und HZB Heizungsbauer?
Wärmepumpe habe ich schon, der FHEM-RasPi bzw. generell die ganzen Zusatzgeräte hängen ca. 2,3 Meter über dem Fussboden im Keller. Bis das ganze Geschoss auf 2,3 m geflutet ist, sind erstmal gut 200 m³ Wasser erforderlich. Da ist der RasPi dann meine letzte Sorge.
Meiner war wegen einer vorhandenen Brennstoffzellenheizung mit einem USB-Viessmannadapter aus Platzgründen an der Wand unterhalb der Verteilung in einer geschlossenen Kunstoffkiste - genau da ging aber der Wasserstrahl rein (RPI incl. SSD und Backup SSD haben schwimmen gelernt) weil einer der Handwerker wohl da reingeschaut hatte und den Deckel daneben gelegt hatte......
Meine Datenbank ist glücklicherweise in einem anderen Keller untergebracht - der RPI jetzt aber ebenfalls.
Moin,
seit dem Update vom contrib auf V 1.51.3 habe ich folgende Meldung im log
V_forecast - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_PV_forecast: No such file or directoryReicht es hier einfach eine leere Datei zu erstellen oder aus das Device dies tun?
Mit freundlichen Grüßen
Moin zusammen,
ein Bombenprojekt, das ich seit längerem verfolge und nutze :) . Herzlichen Dank, DS_Starter!
In Version 1.51.3 treten nach update und shutdown restart folgende Warnings auf (nur zur Info, sind ja unproblematisch):
2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
Macht alle weiter so! Ich bleibe dabei ;)
Beste Grüße
softwear
Moin zusammen,
die Meldung Error deleting file kommt daher dass du vermutlich keine Consumer registriert hast. Das werde ich in eine Warning umwandeln mit anderem verbose Level. Muss ich mal schauen.
Die andere Warnung mit dem FW Variablen ist im nächsten Release auch gelöst, wahrscheinlich. ;)
Schönen sonnigen Tag!
Heiko
Zitat von: TheTrumpeter am 25 April 2025, 07:06:13Zitat von: bismosa am 24 April 2025, 18:01:48bei 360MB direkt nach einem Neustart. Dies auch kontinuierlich ansteigend.
Was verwendest Du denn sonst noch?
Ist hier ja etwas Off-Topic. Dennoch möchte ich kurz antworten.
Fhempy habe ich auch laufen. Allerdings noch nicht weiter untersucht. Jetzt bin ich wieder bei 250MB nach Neustart. Ist jetzt auf 270MB gestiegen über Nacht und hält sich dort aber seit ein paar Stunden konstant. Das sieht jetzt wieder um einiges besser aus.
Ich habe als Speicherintensive Module bisher:
1x SB_SERVER und 6x SB_PLAYER (ca. 20MB) Ist aber wieder aktiv, da ich es nutze
FHEM_Installer (ca. 30MB)
Und nachdem ich SF nun wieder neu eingerichtet habe und
aiControl aiStorageDuration=100 aiTreesPV=1gesetzt habe sehr viel mehr Speicher wieder frei. Wobei ich dies erst noch ein paar Tage beobachten muss.
Ich habe in meinen 1200 Devices bestimmt noch viele andere Kandidaten.
Ein Versuch der Ermittlung, welches Modul wie viel Speicher benötigt ist übrigens hier: https://forum.fhem.de/index.php?msg=1339366 (https://forum.fhem.de/index.php?msg=1339366)
So bin ich auch darauf gekommen, das SF sehr viel Speicher benötigt. (Aber es halt auch braucht für die Berechnungen)
Ich bin insgesamt schon länger dabei mein ganzen System umzustellen. Vom Raspberry bin ich jetzt aus unterschiedlichen Gründen weg. Jetzt habe ich (noch einen sehr alten) mini PC mit Proxmox und einer Linux VM (das schöne ist, das man sich auch mal eben weitere zum testen erstellen kann). IO habe ich alles umgestellt von GPIO auf Firmata. Da sollte dann auch irgendwann ein Hardwarewechsel keine großen Schwierigkeiten mehr machen.
Damit es hier nicht zu OT wird, können wir auch gerne an anderer Stelle das fortführen. Dann bitte einen Hinweis wo ;)
Gruß
Bismosa
Hallo Heiko,
Ein weiterer Wunsch!
Kannst du als graphicBeamXcontent noch ein "batsoc_X" einpflegen?
Sowie "consumption" & "consumptionforecast"!
Hallo kask,
Ja, mach ich mit.
Lg
Moin,
eine Stunde in der Nacht kamen die Meldungen dann waren sie wieder weg.
2025.04.26 02:07:43 1: PERL WARNING: Use of uninitialized value in sprintf at ./FHEM/76_SolarForecast.pm line 4982.
2025.04.26 02:07:43 1: stacktrace:
2025.04.26 02:07:43 1: main::__ANON__ called by ./FHEM/76_SolarForecast.pm (4982)
2025.04.26 02:07:43 1: FHEM::SolarForecast::___15Minutes2HourAggregator called by ./FHEM/76_SolarForecast.pm (4798)
2025.04.26 02:07:43 1: FHEM::SolarForecast::__openMeteoDWD_ApiResponse called by FHEM/HttpUtils.pm (756)
2025.04.26 02:07:43 1: main::__ANON__ called by fhem.pl (786)
gruß
falk
2025.04.25 00:02:46 1: ForecastOpenMeteo - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastOpenMeteo: No such file or directory
2025.04.25 00:02:46 1: ForecastVictronVRM - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastVictronVRM: No such file or directory
2025.04.25 00:02:47 1: ForecastSolarAPI - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastSolarAPI: No such file or directory
2025.04.25 00:02:47 1: ForecastOpenMeteoEnsemble - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastOpenMeteoEnsemble: No such file or directory
2025.04.25 00:02:47 1: ForecastOpenMeteoWorld - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastOpenMeteoWorld: No such file or directory
2025.04.25 00:02:47 1: ForecastDWD - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastDWD: No such file or directory
2025.04.25 00:02:47 1: Forecast - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_Forecast: No such file or directory
...
2025.04.26 00:02:40 1: ForecastOpenMeteo - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastOpenMeteo: No such file or directory
2025.04.26 00:02:40 1: ForecastVictronVRM - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastVictronVRM: No such file or directory
2025.04.26 00:02:41 1: Forecast - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_Forecast: No such file or directory
2025.04.26 00:02:41 1: ForecastDWD - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastDWD: No such file or directory
2025.04.26 00:02:41 1: ForecastSolarAPI - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastSolarAPI: No such file or directory
2025.04.26 00:02:41 1: ForecastOpenMeteoEnsemble - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastOpenMeteoEnsemble: No such file or directory
2025.04.26 00:02:41 1: ForecastOpenMeteoWorld - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_ForecastOpenMeteoWorld: No such file or directory
Habe ich seit 2 Tagen um kurz nach Mitternacht.
ZitatHabe ich seit 2 Tagen um kurz nach Mitternacht.
Ja, das kommt wenn man keine Consumer (mehr) definiert hat. Wenn das Consumer-File schon gelöscht ist, kommt diese Meldung. Ich lasse mir da etwas einfallen.
Grüße,
Heiko
Ich hatte aber nie Comsumer in der FHEM Instance.
Ja. Allerdings wenn du welche gehabt hättest und diese alle löscht (weil du keine mehr haben willst), wäre das entsprechende File im Verzeichnis stehengeblieben bis vor Version xx. Deswegen wird dieses File grundsätzlich versucht zu löschen wenn es keine Consumer gibt. Was wiederum zu der besagten Meldung führt wenn es dieses File nicht gibt bzw. nie gegeben hat.
Ich baue vorher eine Prüfung ein. Dann sollte es diese Meldung nicht mehr geben.
Hallo Falk,
Zitateine Stunde in der Nacht kamen die Meldungen dann waren sie wieder weg.
Es wurden einige Werte von der API nicht geliefert. Ich würde an der Stelle zunächst nichts unternehmen.
Wir beobachten es weiter. Sollte es öfter vorkommen, melde dich bitte wieder.
LG,
Heiko
Hallo kask,
ZitatKannst du als graphicBeamXcontent noch ein "batsoc_X" einpflegen?
Sowie "consumption" & "consumptionforecast"!
Eine Frage dazu. Das aktuell vorhandene batsocforecast_XX zeigt ja bereits die Soc-Prognose und den erreichten SOC der Batterien. Wie meinst du deinen Request genau?
Guten Morgen zusammen,
ich habe soeben die V 1.51.4 eingecheckt. Sie ist auch bereits in meinem contrib zur Nutzung vorhanden.
In dieser Version ist:
- die Warnung bzgl. $FW_ME, $FW_subdir in line 14434 gefixt
- die Meldung 'ERROR deleting file', wenn keine Consumer vorhanden sind, gefixt
- Vorbereitungen für ein neues Attr graphicControl eingebaut (noch nicht aktiv)
- einige weitere kleinere Fixes
schönen Sonntag!
Hallo Heiko,
ich habe heute mal danach gesucht warum meine Steuerung der Speicher nicht mehr so funktioniert wie gewünscht.
Die Ursache ist das SolarForcast einen wahnsinnigen verbrauch für die nächsten Stunden und auch den Folgetag voraussagt uns meine Programm dann sagt oh, bei dem zukünftigen verbrauch muss der Speicher gleich fürs mit allem vollgeballert werden was geht.
setstate SolarForecast 2025-04-27 00:59:55 statistic_todayConsumptionForecast_01 654 Wh
setstate SolarForecast 2025-04-27 01:59:55 statistic_todayConsumptionForecast_02 731 Wh
setstate SolarForecast 2025-04-27 02:59:55 statistic_todayConsumptionForecast_03 697 Wh
setstate SolarForecast 2025-04-27 03:59:55 statistic_todayConsumptionForecast_04 639 Wh
setstate SolarForecast 2025-04-27 04:59:49 statistic_todayConsumptionForecast_05 669 Wh
setstate SolarForecast 2025-04-27 05:59:55 statistic_todayConsumptionForecast_06 773 Wh
setstate SolarForecast 2025-04-27 06:59:55 statistic_todayConsumptionForecast_07 743 Wh
setstate SolarForecast 2025-04-27 07:59:55 statistic_todayConsumptionForecast_08 1113 Wh
setstate SolarForecast 2025-04-27 08:59:55 statistic_todayConsumptionForecast_09 3063 Wh
setstate SolarForecast 2025-04-27 09:59:56 statistic_todayConsumptionForecast_10 6775 Wh
setstate SolarForecast 2025-04-27 10:59:55 statistic_todayConsumptionForecast_11 11804 Wh
setstate SolarForecast 2025-04-27 11:59:55 statistic_todayConsumptionForecast_12 12671 Wh
setstate SolarForecast 2025-04-27 12:59:55 statistic_todayConsumptionForecast_13 13930 Wh
setstate SolarForecast 2025-04-27 14:00:00 statistic_todayConsumptionForecast_14 16766 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_15 16044 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_16 15676 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_17 11985 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_18 6197 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_19 3706 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_20 763 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_21 461 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_22 414 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_23 695 Wh
setstate SolarForecast 2025-04-27 14:01:25 statistic_todayConsumptionForecast_24 613 Wh
Kommen diese Werte daher das ich zwei Autos PV-Optimiert lade?
Das kommt aber nicht jeden Tag vor, vermutlich denkt die Software das könnte ja heute sein, woher soll die das auch wissen...
Ich habe jetzt erstmal die Prognose des Verbrauchs in meiner Berechnung deaktiviert.
Im Anhang noch die Historien mit verdammt vielen Daten :o
Gruß
Max
HI Max,
ZitatKommen diese werte daher das ich zwei Autos PV-Optimiert lade?
Das kommt abe rnicht jeden Tag vor, vermutlich denkt die Software das könnte ja heute sein, woher soll die das auch wissen...
Ja, richtig. Ich habe vor, auch noch eine KI auf die Verbrauchsprognose anzusetzen. Bin aber noch nicht soweit.
ZitatIch habe jetzt erstmal die Prognose des Verbrauchs in meiner Berechnung deaktiviert.
Du kannst solche Verbraucher mit exconfc=1 im Verbraucher-Attribut von der Verbrauchsprognose ausschließen.
Edit: Die Attr plantControl->consForecastIdentWeekdays=1 bzw. plantControl->consForecastLastDays können hier auch hilfreich sein.
Grüße,
Heiko
Zitat von: DS_Starter am 27 April 2025, 14:12:38HI Max,
ZitatKommen diese werte daher das ich zwei Autos PV-Optimiert lade?
Das kommt abe rnicht jeden Tag vor, vermutlich denkt die Software das könnte ja heute sein, woher soll die das auch wissen...
Ja, richtig. Ich habe vor, auch noch eine KI auf die Verbrauchsprognose anzusetzen. Bin aber noch nicht soweit.
ZitatIch habe jetzt erstmal die Prognose des Verbrauchs in meiner Berechnung deaktiviert.
Du kannst solche Verbraucher mit exconfc=1 im Verbraucher-Attribut von der Verbrauchsprognose ausschließen.
Edit: Die Attr plantControl->consForecastIdentWeekdays=1 bzw. plantControl->consForecastLastDays können hier auch hilfreich sein.
Grüße,
Heiko
Alles klar, das werde ich mir mal ansehen. Danke für den Tip.
Gruß
Max
Hallo Max,
mir ist zu dem Car Thema noch etwas eingefallen.
Kann man eigentlich die Werte der Autobatterie, also Soc, Ladeleistung etc., im Modul als Batterie registrieren?
Wenn ja, könnte man das Auto (die Batterie) als Bat ohne SoC-Management eintragen. Dann würde die in diese Batterie geladene Energie nicht als Verbrauch gewertet. Es ist für das Modul ja "nur" gespeicherte Energie.
Den Schlüssel poutmax würde man 0 setzen, da Das Auto nicht in das Haus zurück lädt (zumindest mein Kenntnisstand) -> poutmax=0.
Dann würde es ebenfalls keine dementsprechend große Verbrauchsprognose geben. Kann man mal probieren.
Unschön ist dann halt, dass das Auto nicht als Verbraucher erscheint, was man vllt. sehen möchte.
Gibt so einige Möglichkeiten.
LG
@DS_Starter
ZitatEine Frage dazu. Das aktuell vorhandene batsocforecast_XX zeigt ja bereits die Soc-Prognose und den erreichten SOC der Batterien. Wie meinst du deinen Request genau?
Sowie "consumption" & "consumptionforecast" halt ;D
"batsoc_XX" & "batsocforecast_XX" :o
Der Consumption ist ja auch kein Forecast sondern ein realer angestandener Wert in der Vergangenheit.
Ich würde halt den SOC gerne sehen wollen der anstand in der Vergangenheit.
Ich hatte mir schon sowas gedacht nach ein bisschen nachdenken. Deswegen musste ich die Datenhaltung in der pvHistory erweitern. Man sieht ab V 1.51.3 dort nun auch welche SoC-Prognose es für welche Stunde gegeben hat und den real erreichten SoC, z.B.:
16 => pvfc: 5147, pvrl: 5280, pvrlvd: 1, rad1h: -
etotali01: 65022541, etotali02: 3623020, etotali03: -, etotali04: -
pvrl01: 3820, pvrl02: 1460, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 561, con: 787, gcons: 20, conprice: 0.2958
gfeedin: 1700, feedprice: 0.1269
DoN: 1, sunaz: 230, sunalt: 43
batintotal01: 4866469.18724458, batintotal02: -, batintotal03: -
batouttotal01: 4747058.20336639, batouttotal02: -, batouttotal03: -
batprogsoc01: 100.0, batprogsoc02: -, batprogsoc03: -
batsoc01: 97, batsoc02: -, batsoc03: -
batin01: 2904, batin02: -, batin03: -
...
Damit kann ich jetzt arbeiten. In der bishereigen Balkendarstellung ist für die Zukunft der Prognose-SoC und für die Gegenwart und Vergangenheit der reale erreichte SoC abgebildet. Das hat den Vorteil, dass man nur eine Balkenreihe braucht bzw. für 2 Batterien ein Level "verbraucht". Deswegen will ich diese Option auch verfügbar lassen. Zusätzlich wird es die Möglichkeit geben, in einer Balkenreihe die SoC-Prognose für eine Batterie abzubilden und in der zweiten Reihen dann den real erreichten SoC. D.h. man sieht wie bei Consumption oder PV-Prognose / PV real zwischen beiden Balkenreihen die erreichte Übereinstimmung zwischen SoC Prognose und real.
Das sollte dem Wunsch entsprechen denke ich.
LG
Hallo Heiko,
Ja ich bekomme von beiden Fahrzeugen die SOC Werte.
Ab März laden wir nur mit PV Überschuss bis etwa Ende Oktober.
Du meinst die Beiden Wallboxen/Autos als Batterie definieren?
Ganz verkehrt ist es ja nicht die als Verbraucher zu sehen aber die müssen ja nicht immer laden.
Aber das in dein SolarForecast einzubauen halte ich für zu viel.
Gruß
Max
ZitatDu meinst die Beiden Wallboxen/Autos als Batterie definieren?
Ja, es sind ja Speicher aus der Perspektive. Aber war nur so eine Idee weil in die Speicher geladene Energie automatisch keinen Verbrauch aus Sicht des Moduls darstellt.
Wenn du mit dem exclude klar kommst, passt das ja auch. Ich würde halt consForecastIdentWeekdays=1 und consForecastLastDays=4 stellen. Dann kann das Modul die genauen Verbräche aus der pvHistory verwenden und sieht genau wann das Auto geladen wurde. Nach 4 Wochen geht es in die pvCircular. Dort sind die einzelnen Verbraucher nicht mehr separat verfügbar.
Und noch ein Gedanke zur Auto als Batterie. In den aiRawData kann/werde ich noch die SoC-Werte der registrierten Batterien speichern. Wenn dann eine KI dafür implementiert ist, kann sie die SoC-Werte sehen und in Beziehung mit den aufgetretenen Verbräuchen setzen. Ich denke das würde dann ein recht gutes Ergebnis liefern.
Zitat von: MadMax am 27 April 2025, 19:49:40Hallo Heiko,
Ja ich bekomme von beiden Fahrzeugen die SOC Werte.
Ab März laden wir nur mit PV Überschuss bis etwa Ende Oktober.
......
Aber das in dein SolarForecast einzubauen halte ich für zu viel.
Gruß
Max
Wie wäre es die Auto-Batterie als ConsumerXY als"heater" zu definieren.
Dann müsste es n.m.M. schon gehen. O:-)
evtl. Zusatzdefinition : Voraussetzung "SOC <= XY %" evtl. einbauen falls die Autos nicht von allein sich "abnabeln"
Ein Heater verbraucht doch auch nur - gibt nix zurück :o
Gruß
300P
ZitatDann müsste es n.m.M. schon gehen. O:-)
evtl. Zusatzdefinition : Voraussetzung "SOC <= XY %" evtl. einbauen falls die Autos nicht von allein sich "abnabeln"
Ein Heater verbraucht doch auch nur - gibt nix zurück :o
Ja, sollte passen. Wichtig ist eben, dass der registrierte (vergangene) Verbrauch nicht automatisch in die Prognose hineininterpretiert wird, was bei so großen Verbrauchern natürlich unweigerlich zu Übertreibungen führt.
Ist nicht so einfach mit den E-Autos. ;)
Ich hab da mal eine Idee:
Mein ConsumerXY "Heater" für WW-Erhöhung (Temperaturfühler - max 80 Grad) funktioniert tagsüber mit dem PV-Überschuss schon sehr gut.
FBDECT_fbahahttp_E8_DF_70_07_42_0B
type=heater
power=2200
mode=can
icon=sani_buffer_electric_heater_side@orange
mintime=SunPath
on=on
off=off
asynchron=0
notbefore=08:00
notafter=19:00
locktime=300:300
pcurr=power:W
etotal=energy:Wh
surpmeth=10
interruptable=1Da habe ich nun eine "Zusatzanforderung für den sehr frühen Morgen......
Wegen anstehender "Duschorgien" am Morgen wird im Sommer sicherlich öfters mal ein WP-Lauf in den frühen Morgenstunden allein fürs WW anstehen.
Den könnte man vermeiden wenn die Batterie evtl. (noch) genügend voll wäre und an dem Tag so oder so viel zu viel PV-Ertrag anstehen würde.
Wie kann bzw. könnte ich das einem ConsumerXY beibringen ?
Starte Prüfung um 02 / 03 / 04 / 05:00 Uhr
Stoppe Prüfung auf jeden Fall immer spätestens um 08:00 Uhr mit "off"
Aber nur dann, wenn Batterie(n) voller als XY % ist/sind
und der PV-Gesamtertrag im Laufe des heutigen Tages mehr als 100 % Batterieladung "beträgt"
und dann auch nur für XYZ Minuten
schalte dann "an" - und nach XYZ Minuten bitte "off"
Dank im Voraus für Anregungen
Gruß
300P
Bezieht sich das:
ZitatStarte Prüfung um 02 / 03 / 04 / 05:00 Uhr
Stoppe Prüfung auf jeden Fall immer spätestens um 08:00 Uhr mit "off"
auf die WP? Denn der Heater geht ja wegen notbefore=08:00 ohnehin nicht vor 8:00 los.
Du könntest den Heater ohne deine Definition zu verändern mit der "Spezialanforderung" übersteuern.
Dazu kannst du eine sub im Attr ctrlUserExitFn nutzen.
Mal ins unreine:
{
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
if (int $hour >= 7 && int $hour < 10) {
my $soctotal = CurrentVal ($name, 'batsoctotal', 0); # SoC über alle Bat als Durchschnitt
my $pvtot = ReadingsNum ($name, 'Today_PVforecast', 0); # PV Prognose total heute in Wh
my $caps = CurrentVal ($name, 'batcapsum', 0); # Summe installierte Bat Wh
my $need = $caps - ($soctotal/100 * $caps); # benötigte Ladeenergie Bat bis 100% Ladung
if ($soctotal >= XX && int $hour >= 8 && int $hour < 9 && $pvtot >= $need) { # SoC Vorgabe erfüllt und ab 08:00 bis max. 9:00
# send "on"-Kommando an Heater Device if(ne "on");
}
else {
# send "off"-Kommando an Heater Device if(ne "off");
}
}
}
Es werden teilweise Funktionen des Moduls verwendet (CurrentVal, timestringsFromOffset).
Könnte so funktionieren. Syntax-Fehler inklusive. ;)
Edit: besser als ReadingsNum ($name, 'Today_PVforecast', 0) wäre m.M. nach ReadingsNum ($name, 'RestOfDayPVforecast', 0) um die noch verfügbare PV-Prognose des Tages zu erhalten.
LG
Viele Dank - teste es heute Nacht :) ;D O:-)
Zitat von: 300P am 27 April 2025, 20:41:05Wie kann bzw. könnte ich das einem ConsumerXY beibringen ?
Hallo 300P,
wie wäre das den Verbraucher von 'can' auf 'must' umzuschalten? geht ja als reading
Gruß Gerd
Zitat von: DS_Starter am 27 April 2025, 19:31:50Zusätzlich wird es die Möglichkeit geben, in einer Balkenreihe die SoC-Prognose für eine Batterie abzubilden und in der zweiten Reihen dann den real erreichten SoC. D.h. man sieht wie bei Consumption oder PV-Prognose / PV real zwischen beiden Balkenreihen die erreichte Übereinstimmung zwischen SoC Prognose und real.
Hallo Heiko,
ist den Post so zu verstehen so dass es möglich wäre auch den Ist- und Sollwert aller Batterien (siehe screen) im graphicBeam...content auswählbar zu machen? Das würde mir, mit mehr als einer Bat sehr entgegenkommen.
Gruß Gerd
Hallo Gerd,
Sollwert ... weiß ich nicht so recht ob der Begriff richtig ist, sondern es ist die SoC-Prognose die das Modul für eine/jede Batterie ausrechnet.
Man könnte dann z.B. in Level 2 im primären Balken die SoC-Pronose für Bat1 anzeigen lassen und im sekundären Balken den erreichten realen Soc-Wert der Bat1.
In Level 3 könnte man das identisch für die Bat2 einrichten.
Ich denke jetzt sind die Möglichkeiten besser ausgedrückt. Passt das für dich, oder meinst du noch etwas anderes?
LG
Zitat von: Max_Meyer am 27 April 2025, 22:07:12Zitat von: 300P am 27 April 2025, 20:41:05Wie kann bzw. könnte ich das einem ConsumerXY beibringen ?
Hallo 300P,
wie wäre das den Verbraucher von 'can' auf 'must' umzuschalten? geht ja als reading
Gruß Gerd
Ja könnte u.U. auch irgendwie gehen - aber da wird "nix" an Zusatzbedingung beachtet und bei leerer Batterie wird trotzdem Energie (vom EVU) verbraucht.....und ich hätte den Consumer 2 X (1 x Tagsüber / 1 x Nachts) ;)
Zitat von: DS_Starter am 27 April 2025, 22:38:44t ... weiß ich nicht so recht ob der Begriff richtig ist, sondern es ist die SoC-Prognose die das Modul für eine/jede Batterie ausrechnet.
Man könnte dann z.B. in Level 2 im primären Balken die SoC-Pronose für Bat1 anzeigen lassen und im sekundären Balken den erreichten realen Soc-Wert der Bat1.
In Level 3 könnte man das identisch für die Bat2 einrichten.
Ich denke jetzt sind die Möglichkeiten besser ausgedrückt. Passt das für dich, oder meinst du noch etwas anderes?
Guten Morgen Heiko,
ja du hast recht das war sehr unglücklich formuliert - was ich meine ist die Frage ob es, jenseits der batsocforecast_xx (SOC-Prognose) und batsocconsumtion_xx (real eingetretener Wert), noch einen Parameter mit 'gewichteten' Durchschnittswert über alle Batterien für jeden der beiden o.g. Zustände geben kann (analog der Darstellung in der Grafik (screen von 22:09) - wo ja die Batterie auch nur einmal mit einem Wert zu sehen ist - gleichgültig wie viele Bat-devices definiert sind. Der andere screen (22:18) sollte meine derzeitige Abbildung und das Problem mit der 3 Bat. im Lev.3 dokumentieren. Die beiden anderen Level nutze ich für PV-Forecast vs. PV-real und Verbrauch-Forecast - vs.realer Verbrauch
Gruß Gerd
Zitat von: 300P am 27 April 2025, 22:05:38Viele Dank - teste es heute Nacht :) ;D O:-)
War heute Nacht nichts mit Probelauf.
-> Die Warmwasserzurkulation hatte die WW-Temperatur so reduziert das so kurz nach 3 Uhr einen WP-Start verursacht wurde.
Werde mal die Zirkulation nachts ausschalten - ohne das meine bessere Hälfte was davon erfährt..... ;) O:-)
Zitat von: 300P am 27 April 2025, 22:48:25könnte u.U. auch irgendwie gehen - aber da wird "nix" an Zusatzbedingung beachtet und bei leerer Batterie wird trotzdem Energie (vom EVU) verbraucht.....und ich hätte den Consumer 2 X (1 x Tagsüber / 1 x Nachts) ;)
Guten Morgen 300P,
das reading welches 'can' und 'must' umschaltet, könnte ja mit den notwendigen Randbedingungen hergeleitet werden.
In meiner Anlage habe ich das Problem mit den 'Duschorgien' hardwareseitig gelöst - habe einen E-DLH parallel geschaltet und nehme den immer dann mit dazu wenn im Puffer die Temperatur unter die 'Duschwohlfühltemperatur' sinkt - so wird das Wasser aus dem Puffer nur minimal erwärmt - hat in den letzten 12 Monaten keine 20 kWh gebraucht - ist aber immer warmes Dusch-Wasser da.
Gruß Gerd
Hallo Gerd,
Zitatwas ich meine ist die Frage ob es, jenseits der batsocforecast_xx (SOC-Prognose) und batsocconsumtion_xx (real eingetretener Wert), noch einen Parameter mit 'gewichteten' Durchschnittswert über alle Batterien für jeden der beiden o.g. Zustände geben kann (analog der Darstellung in der Grafik (screen von 22:09) - wo ja die Batterie auch nur einmal mit einem Wert zu sehen ist - gleichgültig wie viele Bat-devices definiert sind.
Jetzt weiß ich was du meinst. Das muss ich mir erst durchdenken.
Ich werde erstmal das Attr graphicControl fertig einführen und mich dann mit den zusätzlichen Contentmöglichkeiten befassen. Mal schauen was ich alles ermöglichen kann.
Lg,
Heiko
Hallo Heiko, bei mir wurde letzte Woche meine PV-Anlage installiert und in Betrieb genommen. Durch das FHEM-Wiki bin ich auf dieses Hammer-Modul aufmerksam geworden und bin seit dem an der Konfiguration und Erforschung was hier alles möglich ist dran. Das ist ja wirklich was ganz Großes was du hier erschaffen hast und da wollte ich einfach mal DANKE sagen.
Ich bin gespannt was man hier alles zaubern kann. ;D
Hallo,
1. bei mir scheint etwas mit den Wetterdaten nicht zu stimmen. Gestern wurde durchgehend Sonne angezeigt. Heute wieder bis zu 100% bewölkt obwohl tatsächlich durchgehend Sonne, siehe Anhang
2. meine Verbrauchprognose ist viel zu hoch, sollten so was um 25kWh sein - wo ist der Fehler
welche Daten soll ich noch schicken für die Fehlersuche
Hallo Wolle02,
ich freue mich über dein Dankeschön :) ... nehme es gern auch für diejenigen Nutzer entgegen, die mich über eine bereits lange Zeit mit Ideen und auch Code-Zuarbeiten unterstützt haben.
Wünsche dir viel Spaß und auch einen persönlichen Mehrwert mit dem Modul!
LG,
Heiko
@Medel:
Das sieht nach fehlerhaften Daten aus.
Hast du schon im Log nach zutreffenden Fehlermitteilungen geschaut ?
Hallo Medel,
bei dem Wetter kommt es darauf an welchen Dienst du nutzt. Möglicherweise ist für deinen Standort ein anderer Dienst bzw. eine andere Wetterstation besser geeignet.
Bzgl. Verbrauchsprognose könnte eine fehlerhafte Angabe Wh/kWh eines Verbrauchers eine Ursache sein.
Debug einschalten mit ctrlDebug=consumption. An den Ausgaben erkennt man wahrscheinlich schon eine Spur zum Übeltäter.
@300P,
ich habe den Ansatz in #2646 noch etwas geändert, sonst würde dieser Code auch nach 9:00 in deine Consumersteuerung dauerhaft reinsteuern.
EDIT
@Heiko:
hat sich grade überschnitten - schaue es mir an ;)
Hallo zusammen,
ich stelle hier den vorerst letzten Stand (mit vielen Erläuterung) für mein WW-Heater als "ctrlUserExitFn" zur weiteren Nutzung zur Verfügung.
{
################################
# Wenn es später als 04:00 Uhr ist (>=4)
# und
# früher als 08:00 Uhr ist (<8) (also bis "7:59")
# und
# der SoC-Wert (über alle Batterien) >30 (%) ist
# und
# die restliche PV-Prognose von heute höher als die benötigte Ladeenergie aller Batterien ist (in Wh)
# schaltet sich der Heater-ConsumerXX ein
#
# andernfalls
#
# wenn es später als 02:00 Uhr ist (>=4)
# und
# früher als 08:00 Uhr ist (<8)
# und
# wenn
# der SoC-Wert über alle Batterien <40 (%) ist ->>> oder <<<- die restliche PV-Prognose von heute niedriger als die benötigte Ladeenergie aller Batterien ist (in Wh)
# schaltet sich der Heater-ConsumerXX aus
################################
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
# hier anpassen !!!
my $timestart = 2; # ab welcher Uhrzeit soll es sein
my $timeend = 8; # bis wieviel Uhr soll es sein
# hier anpassen !!!
if (int $hour >= $timestart && int $hour < $timeend ) {
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
# hier anpassen !!!
my $minsocbat = 30; # nur bis mindesten XY SoC aller Batterien
my $heater = (split " ", AttrVal ($name, 'consumer06', ''))[0]; # ConsumerXX (Heater) zur Ermittlung des Namens immer !!!! hier angeben
# hier anpassen !!!
my $soctotal = CurrentVal ($name, 'batsoctotal', 0); # SoC über alle Bat als Durchschnitt
my $pvtot = ReadingsNum ($name, 'RestOfDayPVforecast', 0); # Restliche PV Prognose total heute in Wh
# war my $pvtot = ReadingsNum ($name, 'Today_PVforecast', 0); # PV Prognose total heute in Wh
my $caps = CurrentVal ($name, 'batcapsum', 0); # Summe installierte Bat Wh
my $need = $caps - ($soctotal/100 * $caps); # benötigte Ladeenergie Bat bis 100% Ladung
Log3 ($name, 5, qq{$name - userFn -> WWHeater Reading ist = $heater - aktuelle Stunde = $hour aus $dt erzeugt });
Log3 ($name, 5, qq{$name - userFn -> WWHeater StartZeit ist von $timestart Uhr bis $timeend Uhr und mindestens ein SoC von $minsocbat % muss in den vorhandenen Batterien gegeben sein });
Log3 ($name, 5, qq{$name - userFn -> Der PV-Tages-Restertrag betraegt $pvtot Wh >>>???mehr???<<< als die fehlende Ladeenergie in den® Batterie(n) von $need Wh});
if ($soctotal >= $minsocbat && $pvtot > $need) {
# Wenn die % SoC-Vorgabe erfüllt und der PV-Tages-Rest-Ertrag > 100% Batteriekapazitaet
if (ReadingsVal($heater,"state","") ne "on") {
# send "on"-Kommando an Heater Device if(ne "on");
fhem ("set $heater on");
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --on--});
}
}
else {
if (($soctotal < $minsocbat) || ($pvtot <= $need)) {
# ab xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
# und
# (die SoC-Vorgabe unterschritten !!!!! oder derTages-Rest-Ertrag < 100% Batteriekapazitaet)
# danach sollte der Heater-ConsumerXY wieder nach "seinen" Regeln steuern...
if (ReadingsVal($heater,"state","") ne "off") {
# send "off"-Kommando an Heater Device if(ne "off");
fhem ("set $heater off");
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --off--});
}
}
}
}
}
Heute Nacht wird es wohl bei mir damit klappen, denn meine Test tagsüber haben geklappt.(PS: hat geklappt)
Gruß
300P
EDIT 29.04.2025 - Anmerkung von Heiko eingebaut
positives Ergebnis in der Folgenacht:
2025.04.29 02:00:04 2: Forecast - userFn -> Forecast Consumer FBDECT_fbahahttp_E8_DF_70_07_42_0B in Forecast set to --on--
2025.04.29 02:00:13 2: Forecast - userFn -> Forecast Consumer FBDECT_fbahahttp_E8_DF_70_07_42_0B in Forecast set to --on--
2025.04.29 02:00:28 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
2025.04.29 05:47:28 2: Forecast - userFn -> Forecast Consumer FBDECT_fbahahttp_E8_DF_70_07_42_0B in Forecast set to --off--
2025.04.29 05:47:44 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
Zitatbei dem Wetter kommt es darauf an welchen Dienst du nutzt. Möglicherweise ist für deinen Standort ein anderer Dienst bzw. eine andere Wetterstation besser geeignet.
OpenMeteo
ZitatBzgl. Verbrauchsprognose könnte eine fehlerhafte Angabe Wh/kWh eines Verbrauchers eine Ursache sein.
Debug einschalten mit ctrlDebug=consumption. An den Ausgaben erkennt man wahrscheinlich schon eine Spur zum Übeltäter.
Siehe Anhang
Habe keinen Verbraucher eingetragen, ist das vielleicht der Fehler
Hier mal die aktuellen Daten von Heute:
99 => pvfc: 157813, pvrl: 94775, pvrlvd: -, rad1h: -
pvrl01: 44671, pvrl02: 37766, pvrl03: 2807, pvrl04: 9531
pprl01: -, pprl02: -, pprl03: -
confc: 439795, con: 19034, gcons: 220, conprice: -
gfeedin: 78940, feedprice: -
DoN: -, sunaz: -, sunalt: -
batin01: 0, batin02: 0, batin03: -
batout01: 0, batout02: 0, batout03: -
batmaxsoc01: 50.00, batmaxsoc02: 100.0, batmaxsoc03: -
batsetsoc01: -, batsetsoc02: -, batsetsoc03: -
dayname: Mo,
Wechelrichter Daten:
P: 319 W, Pheute: 44.570 kWh, Ptotal: 87827.975 kWh
P: 8155 W, Pheute: 37.898 kWh, Ptotal: 30617.216 kWh
P: 309 W, Pheute: 2.757 kWh, Ptotal: 1938.546 kWh
P: 92 W, Pheute: 9.582 kWh, Ptotal: 25.016 kWh
Zählerdaten
P: -6846 W, Verbrauch_heute: 0.220 kWh, Einspeisung_heute: 78.380 kWh
ZitatHabe keinen Verbraucher eingetragen, ist das vielleicht der Fehler
Nein, definitv nicht.
Offensichtlich wird zumindest aktuell der Verbrauch richtig erfasst ->
confc: 439795, con: 19034, gcons: 220, conprice: -
gfeedin: 78940, feedprice: -
DoN: -, sunaz: -, sunalt: -
19,034 kWh deckt sich mit deiner Angabe. Der Forecast von 439,795 kWh kommt aus den hohen Werten:
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 08: 11539 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 09: 17442 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 10: 21098 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 11: 25303 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 12: 27685 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 13: 43426 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 14: 64984 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 15: 63856 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 16: 70521 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 17: 53323 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 18: 15390 Wh, Considered value numbers: 60
2025.04.28 18:00:04 1: solarforcast DEBUG> estimated cons of Hour 19: 14040 Wh, Considered value numbers: 60
....
Die hohen Werte stehen vermutlich im Schlüssel pvCircular->con_all der Stunden 08-19. Ein
"get ... pvCircular" zeigt dir die Werte. Hier ein Beispiel für die Stunde 10
10 => pvapifc: 2536, pvaifc: -, pvfc: 2536, aihit: 0, pvrl: 2861
batin01: 0, batin02: 0, batin03: -
batout01: 0, batout02: 0, batout03: -
confc: 449, gcon: 0, gfeedin: 3303, wcc: 0, rr1c: 0.00
temp: 12.00, wid: 0, wtxt: Bewölkungsentwicklung nicht beobachtet
pprl01: 0, pprl02: -, pprl03: -
pvcorrf: 10.00=1.88 10.05=1.50 10.100=0.69 10.15=2.00 10.20=1.50 10.25=1.76 10.40=1.50 10.45=2.00 10.50=1.50 10.55=2.00
10.60=0.59 10.65=1.14 10.70=1.50 10.75=1.03 10.80=1.60 10.85=1.00 10.90=1.78 10.95=1.39 15.00=1.30 15.100=0.86
15.25=1.86 15.30=1.19 15.35=2.72 15.40=1.50 15.45=1.31 15.50=0.68 15.55=0.98 15.60=0.80 15.65=0.81 15.70=1.91
15.75=1.16 15.80=1.14 15.85=2.49 15.90=0.85 15.95=1.03 20.00=1.17 20.100=0.99 20.15=0.87 20.40=1.75 20.45=1.90
20.65=1.63 20.70=2.25 20.85=0.97 20.90=1.75 20.95=1.05 25.00=1.21 25.100=0.36 25.35=1.10 25.40=1.33 25.50=1.22
25.55=1.26 25.60=0.58 25.75=1.10 25.85=0.53 25.90=1.63 25.95=0.80 30.00=1.04 30.100=0.40 30.30=1.12 30.45=0.89
30.50=0.26 30.55=1.20 30.60=1.28 30.65=0.88 30.75=0.77 30.80=0.58 30.85=0.47 35.00=0.88
simple=1.27
quality: 10.00=0.53 10.05=0.30 10.100=0.55 10.15=0.39 10.20=0.16 10.25=0.57 10.40=0.29 10.45=0.29 10.50=0.50 10.55=0.45
10.60=0.00 10.65=0.79 10.70=0.43 10.75=0.97 10.80=0.63 10.85=0.99 10.90=0.51 10.95=0.56 15.00=0.77 15.100=0.84
15.25=0.54 15.30=0.73 15.35=0.35 15.40=0.44 15.45=0.62 15.50=0.00 15.55=0.98 15.60=0.52 15.65=0.77 15.70=0.52
15.75=0.86 15.80=0.88 15.85=0.40 15.90=0.58 15.95=0.97 20.00=0.86 20.100=0.99 20.15=0.85 20.40=0.34 20.45=0.53
20.65=0.58 20.70=0.24 20.85=0.97 20.90=0.46 20.95=0.95 25.00=0.82 25.100=0.00 25.35=0.91 25.40=0.75 25.50=0.82
25.55=0.79 25.60=0.27 25.75=0.91 25.85=0.12 25.90=0.62 25.95=0.76 30.00=0.96 30.100=0.00 30.30=0.89 30.45=0.87
30.50=0.00 30.55=0.83 30.60=0.78 30.65=0.86 30.75=0.70 30.80=0.28 30.85=0.00 35.00=0.86
simple=0.79
pvrlsum: simple=278354
pvfcsum: simple=218695
dnumsum: simple=211
con_all => Sa @ 2113 469 2252 722 1720 1600 284 274
So @ 2137 732 717 4870 3447 3447 1558 757 162 96 2285
Fr @ 608 1137 1307 551 6 1483 783
Do @ 208 983 3155 1083 1127 693 81 435 446 627
Mi @ 280 561 3304 825 486 381 350 348 326 161
Di @ 2784 865 865 3209 827 182 301 427 563 9 645 6
Mo @ 2596 161 498 2798 1174 449 2 359 161
.....
Zeige uns mal bitte diesen Auszug von dir.
Dann sehe ich dass
batin01: 0, batin02: 0,
batout01: 0, batout02: 0
Zwei Batterien hast du, aber bei keiner etwas rein oder raus. Ist das richtig?
Hier die pvCircular
Ja, man sieht hier in der Stunde 08 zum Beispiel der resultierende Wert über alle Wochentage durchaus bei den im Debug angegebenen 11539 Wh liegt.
08 => ...
con_all => Sa @ 11439 18904 14029 12239 6174 12590 7904 15467 2209
Di @ 0 5695 20210 21725 14992 17117 16942 10843 13244
Do @ 6000 14976 9093 13328 17219 6502 18679 3009 11146
Mi @ 1 14873 10007 13645 14130 19165 9861 20532 19677
Fr @ 0 13151 6026 19051 14205 7668 8928 17078 11154
So @ 6674 7886 12137 8168 8283 7802 9006 29915 2014
Mo @ 7803 7309 11639 13365 11050 15886 8846 9154 2865
Ich gehe davon aus, dass die Werte richtig sind. Hast du ein E-Auto was geladen wird?
Wenn ja, kannst du mit der Einstellung:
plantControl->consForecastIdentWeekdays=1
plantControl->consForecastLastDays=4 (oder evtl. noch kleiner)
versuchen gegenzusteuern.
Zum Beispiel liegst du an einem Montag zwischen 2865 Wh - 15886 Wh für die Stunde 08:
Mo @ 7803 7309 11639 13365 11050 15886 8846 9154 2865
Passt das soweit? Oder gab es in der Vergangenheit eine Fehlkonfiguration in deren Folge so hohe Werte aufgezeichnet wurden?
E-Auto habe ich nicht. Aber es war ein Kommafehler in einer Erzeugung, ich glaube ich habe ihn am Sa geändert. Momentan habe ich noch einen Fehler in der Batterie 1 bei der Beladung festgestellt. Weiß aber noch nicht wie ich den richtigen Wert bekomme. Geht da auch PIN=-POUT
ZitatGeht da auch PIN=-POUT
Ja, so wie es in der Hilfe zu setupBatteryDevXX beschrieben steht:
Sonderfälle: Sollte das Reading für pin und pout identisch, aber vorzeichenbehaftet sein, können die Schlüssel pin und pout wie folgt definiert werden:
pin=-pout (ein negativer Wert von pout wird als pin verwendet)
pout=-pin (ein negativer Wert von pin wird als pout verwendet)
LG
@300P,
nur als Tipp, sowas:
fhem ("set ".$heater." off");
kannst du ganz einfach so schreiben:
fhem ("set $heater off");
Sieht doch viel übersichtlicher aus.
Und diese Ausdrücke:
my $timestart = "4"; # ab welcher Uhrzeit soll es sein
my $timeend = "8"; # bis wieviel Uhr soll es sein
my $minsocbat = "30"; # nur bis mindesten XY SoC aller Batterien
besser so:
my $timestart = 4; # ab welcher Uhrzeit soll es sein
my $timeend = 8; # bis wieviel Uhr soll es sein
my $minsocbat = 30; # nur bis mindesten XY SoC aller Batterien
Weil die Ziffern bei uns als Integer verarbeitet werden und nicht als String ("4" ist der String 4).
z.B. if (5 > $timestart) versus if ("5" ne $timestart) mit $timestart = "4"
LG,
Heiko
@all
die V 1.51.5 ist eingecheckt.
In der Version gibt es ein neues Attr graphicControl und es werden die folgenden Attribute automatisch umgesetzt:
graphicBeamWidth -> graphicControl->beamWidth
graphicHourCount -> graphicControl->hourCount
graphicEnergyUnit -> graphicControl->energyUnit
graphicSpaceSize -> graphicControl->spaceSize
graphicHeaderDetail -> graphicControl->headerDetail
graphicHourStyle -> graphicControl->hourStyle
graphicLayoutType -> graphicControl->layoutType
Nach dem Restart vom FHEM ist die neue Konfiguration nur zu sichern. Damit ist die Umsetzung abgeschlossen.
Grüße,
Heiko
Zitat von: DS_Starter am 28 April 2025, 20:37:01@300P,
nur als Tipp......
LG,
Heiko
DANKE !!
Umgesetzt / geändert im Beitrag
Hey @Heiko,
ich lese hier fleißig mit und finde die ganzen Anpassung echt gut. Wollte aber nochmal kurz auf die "strings=none" Geschichte in setupInverterDev01 aufmerksam machen. Leider kann ich nicht einschätzen wie viel Aufwand das ist.
PS: Ich habe nun mit dem Modul immer mal ein wenig rum gespielt und einiges getestet. Mich wunder die relativ große Abweichung der Prognose. Gestern z.B. 15.8%. Hierzu muss ich sagen, ich habe fast perfekte Süd Ausrichtung (5% Abweichung). Allerdings je nach Jahreszeit/Sonnenstand ab Uhrzeit x (Beispiel 17:30 Uhr) eine Verschattung. Das würde zumindest die abendliche Abweichung erklären.
Über den Tag, bei keiner Verschattung werden aber auch mal 100W zu viel geschätzt oder 300W zu wenig usw. Mir ist klar, dass es nicht 100% genau sein kann aber mir kommen die Differenzen viel vor. Ist dem so oder reden wir hier vom normalem Toleranzbereich? (KI ist bei mir auch aktiv)
Dann noch eine kurze Best Pratice Frage: Wenn ich meine große 10kWp Anlage bekomme. Besser ein zweites SF def anlegen oder alles in das eine rein?
Danke und Gruß,
Kai
Hallo Kai,
ZitatWollte aber nochmal kurz auf die "strings=none" Geschichte in setupInverterDev01 aufmerksam machen.
Das habe ich noch auf dem Schirm. Da hier etwas mehr Auswirkungen zu erwarten sind, habe ich es etwas nach hinten gelegt. Aber gerne daran erinnern, bei mir läuft hier einiges durch ...
ZitatMir ist klar, dass es nicht 100% genau sein kann aber mir kommen die Differenzen viel vor. Ist dem so oder reden wir hier vom normalem Toleranzbereich? (KI ist bei mir auch aktiv)
Also grundsätzlich wird sich bei so stabilen Wetter, einer entsprechenden Lauf- und Lernzeit und der hoffentlich gute Übereinstimmung der durch den Wetterdienst vorhergesagte und tatsächlich vorhandene Strahlung/Bewölkung eine Abweichung < 10%, typisch bei mir so zwischen 0,5 und 5% einpegeln.
Bezüglich KI besteht die Herausforderung, dass die KI immer nur durch Auswertung der vergangenen "Erfahrungen" auf die Prognose schließt. Da kommt es stark darauf an wieviel Daten, Entscheidungsmöglichkeiten (Lerngrad) vorhanden sind. Vergleichbar mit der Entwicklung vom Kleinkind über Schulkind zum Experten. ;)
Bei meinen Devices hat die KI schon einige Daten gesammelt und kommt damit schon recht gut zurecht. Eine ungefähre Vorstellung des Lerngrades kann man sich mit "get ... valDecTree aiRuleStrings" anschauen. Je höher die verfügbaren Regeln und Knoten sind, desto granularer kann die Entscheidungsfindung der KI ausfallen:
Trained AI Object contains an Ensemble of 10 trees (only the first Tree is printed out)
Tree: 1 -> Number of Rules: 5294 / Number of Nodes: 7132 / Depth: 6
Tree: 2 -> Number of Rules: 5300 / Number of Nodes: 7122 / Depth: 5
Tree: 3 -> Number of Rules: 5290 / Number of Nodes: 7142 / Depth: 6
Tree: 4 -> Number of Rules: 5293 / Number of Nodes: 7121 / Depth: 5
Tree: 5 -> Number of Rules: 5300 / Number of Nodes: 7134 / Depth: 5
Tree: 6 -> Number of Rules: 5290 / Number of Nodes: 7110 / Depth: 6
Tree: 7 -> Number of Rules: 5281 / Number of Nodes: 7136 / Depth: 5
Tree: 8 -> Number of Rules: 5293 / Number of Nodes: 7143 / Depth: 6
Tree: 9 -> Number of Rules: 5297 / Number of Nodes: 7136 / Depth: 6
Tree: 10 -> Number of Rules: 5284 / Number of Nodes: 7126 / Depth: 6
Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen
letztes KI-Training: 28.04.2025 17:15:25 / Laufzeit in Sekunden: 3.13943
letzte KI-Ergebnis Generierungsdauer: 0.06 ms
Allgemein sind diese Anpassungs- und Korrekturprozesse recht komplex und erfordern auch Zeit. Und es gibt immer wieder Rückschläge weil z.B. die Wetterprognose mit den realen Bedingungen nicht übereinstimmt und somit die gespeicherten Werte verfälscht, deren Auswirkungen wiederum im Modul durch statistische Methoden (Medianberechnung) versucht wird zu verringern.
ZitatDann noch eine kurze Best Pratice Frage: Wenn ich meine große 10kWp Anlage bekomme. Besser ein zweites SF def anlegen oder alles in das eine rein?
Also wenn deine zwei Anlagen in der Anwendung gut zusammenpassen, also beide Anlagen speisen das Hausnetz und laden auch die gleichen Batterien, speisen die gleichen Verbraucher usw., kannst du sie in ein Device integrieren. Ansonsten dann besser zwei Devices vorsehen.
LG,
Heiko
Danke für die schnelle Antwort. Da hat meine KI noch einiges zu lernen.
Tree: 1 -> Number of Rules: 92 / Number of Nodes: 101 / Depth: 2
Tree: 2 -> Number of Rules: 92 / Number of Nodes: 100 / Depth: 2
Tree: 3 -> Number of Rules: 90 / Number of Nodes: 101 / Depth: 2
Tree: 4 -> Number of Rules: 92 / Number of Nodes: 101 / Depth: 2
Tree: 5 -> Number of Rules: 95 / Number of Nodes: 104 / Depth: 2
Tree: 6 -> Number of Rules: 91 / Number of Nodes: 98 / Depth: 2
Tree: 7 -> Number of Rules: 94 / Number of Nodes: 106 / Depth: 2
Tree: 8 -> Number of Rules: 94 / Number of Nodes: 104 / Depth: 2
Tree: 9 -> Number of Rules: 93 / Number of Nodes: 105 / Depth: 2
Tree: 10 -> Number of Rules: 91 / Number of Nodes: 99 / Depth: 2
Was die Best Practice angeht:
Das Eine ist ein BKW, Einphasig mit kleiner BAT.
Das Andere ist eine 10kWp Anlage, 3 Phasig mit größerer BAT und Notstrom/Ersatzstrom.
Hatte das Modul aber so verstanden, das ich bei den verschiedenen Attr fast überall wo es wichtig ist, auch sagen kann was ist z.B. der richtige String an welcher Batterie usw. Ich bin mir nicht sicher ob ich das besser trenne oder nicht. Nicht alle deiner Ansätze, machen die Anlagen so.
- Unterschiedliche Akkus,
- Einphasig/Dreiphasig,
- Ja - es wird das gleiche Netz bespeist,
- Die Verbraucher sind zumindest auf der einen Phase, natürlich die gleichen. Wird aber ja eh im Stromzähler zusammen gezählt.
Ich glaub ich mach einfach zwei def´s.
Gruß,
Kai
ZitatHatte das Modul aber so verstanden, das ich bei den verschiedenen Attr fast überall wo es wichtig ist, auch sagen kann was ist z.B. der richtige String an welcher Batterie usw. Ich bin mir nicht sicher ob ich das besser trenne oder nicht.
Ja, so ist es auch. Ich vermute, dass sich 90% aller Fälle in einem Device abbilden lassen. Einphasig/Dreiphasig ist egal solage die registrirten Zähler alles richtig liefern.
Du kannst sogar alles in einem Device abbilden und zusätzlich noch ein weiteres Device nur mit deiner neuen Anlage erstellen. Dann kannst du vergleichen.
Zu beachten ist eben auch nochmal die KI. Wenn du jetzt eine Anlage zubaust und damit mehr Leistung im gleichen Device hast, wird die KI anfangs immer zu wenig prognostizieren, weil sie ja davon ausgeht ... aha, es ist soviel Strahlung, Bewölkung, Temperatur usw. pronostiziert -> dann wird es nach meiner Erfahrung X Wh geben. Sie lernt dann zwar auch das wieder, aber der Faktor Zeit spielt eine Rolle.
Die API (z.B. OpenMeteo) reagiert auf diese Anlagenänderung sofort.
Zitat von: 87insane am 29 April 2025, 11:49:15Was die Best Practice angeht:
Das Eine ist ein BKW, Einphasig mit kleiner BAT.
Das Andere ist eine 10kWp Anlage, 3 Phasig mit größerer BAT und Notstrom/Ersatzstrom.
- Unterschiedliche Akkus,
- Einphasig/Dreiphasig,
- Ja - es wird das gleiche Netz bespeist,
- Die Verbraucher sind zumindest auf der einen Phase, natürlich die gleichen. Wird aber ja eh im Stromzähler zusammen gezählt.
Ich glaub ich mach einfach zwei def´s.
Gruß,
Kai
Hallo Kai,
wenn dein aktuelles BKW sauber eingerichtet ist - sag / zeig mal wie es konfiguriert ist.
Wichtig wäre dabei auch noch zu wissen, ob dein BKW sein Leistung komplett "durch" die Batterie in dein Hausnetz weiterreicht oder ob die Batterie als separates Device zu sehen ist das keinen Einfluss auf die Leistungswerte der BKW-WR hat.
EDIT : fällt mir grad noch ein ->> das ist ja schon bekannt O:-)
Gruß
300P
Wir hatten es vorhin bezüglich KI und Trefferquote.
Meine KI mit OpenMeteo erreichte heute 1,4 % und gestern 3,6 % Tagesabweichung.
Da ich eine Victron-Anlage habe, kann ich auch die von Victron bereitgestellte KI-basierte PV-Prognose nutzen. Sie basiert auf dem SolCast-Dienst, den wir im Modul ebenfalls nutzen können. Leider haben neuere Accounts nur noch 10 freie Calls pro Tag.
Jedenfalls hatte meine Victron-Instanz gestern eine Tagesabweichung von 0! Prozent, also 100% Übereinstimmung von Prognose und Realität. Das hatte ich bisher noch nie! Heute hat diese Instanz auch wieder -5,2 % Tagesabweichung.
Ich persönlich bin mit diesen Ergebnissen hoch zufrieden. Bei instabilen Wetterlagen und Bewölkungen sind solche Übereinstimmungen nicht so leicht zu erreichen und fallen üblicherweise durchaus höher aus. Auch damit muß man leben auch wenn wir an stetigen Verbesserungen arbeiten.
Bei mir ist die Prognose / Trefferquote auch relativ treffsicher im gleichen Bereich immer etwas unterhalb der Vorhersage. Das kommt durch Erweiterung eines neuen PV-String im März und dauert halt seine Zeit.
Beim Verbrauch gibts logischerweise z.Z. keine guten Treffer
Der Grund
->> Eine Umstellung von Gas/Brennstoffzelle auf Elektr.-WP muss sich erst in den Verbrauchswerten langsam einfinden....
Anbei meine Werte:
Gruß
300P
Interessant ... wir fast den geichen Haus(grund)verbrauch. :)
Hab dein System für solche Zwecke "gehacked" 8) O:-)
Zitat von: DS_Starter am 29 April 2025, 21:19:59Interessant ... wir fast den geichen Haus(grund)verbrauch. :)
Meinst du die 473 W? Die hab ich auch ;-)
Screenshot 2025-04-29 212353.png
Aber mal was anderes:
Ich habe eine Prognose für Verbrauch.
Ich habe eine Prognose für Produktion.
Ich habe eine Prognose für den SoC der Batterie.
Kann man auch eine (stündliche) Prognose des Netzbezugs haben? Damit könnte ich mir in Verbindung mit Tibber die Kosten vorhersagen und im zweiten Schritt (mache ich bereits über einige andere Berechnungen) Verbraucher nach PV, SoC und Strompreis steuern.
Bei der Batterie habe ich da zudem folgende Herausforderung:
Über den WR kann ich das Entladen der Batterie unterbinden.
Das benutze ich gestaffelt um Kapazität für gewisse Strompreise aufzuheben. (Dadurch wird in teuren Phasen die Energie aus der Batterie bezogen und nicht vom Netz).
Allerdings führte das bei dem aktuellen Wetter dazu, dass nachts die Batterie gesperrt wurde und morgens dann noch mehr als nötig in der Batterie war, unnötig vom Netz bezogen wurde und dann auch noch ins Netz gespeist wurde...
Das würde ich gerne optimieren. Im Moment nutze ich die komplette SoC Vorhersage in Kombination mit Produktionsvorhersage und Verbrauchsvorhersage.
Ist morgige Produktion > Verbrauch und ist der vorhergesagte SoC niemals 0%, wird die Batterie unabhängig Strompreis etc. freigeschalten. Andernfalls greift die Staffelung / Zuordnung SoC / Strompreis.
Eventuell hat da jemand bereits was ähnliches umgesetzt oder eine Idee das weiter zu optimieren?
Und letztendlich bleibt da noch die Wärmepumpe als theoretischer Großverbraucher. Der Verbrauch der WP hängt dabei maßgeblich von Außentemperatur (wegen Heizung) und Warmwasserverbrauch ab. Gibt es (eventuell in einer fernen Zukunft) die Möglichkeit ein Verbrauchsvorhersage über die KI mit der Wettervorhersage in Verbindung zu bringen?
Das sind so die Dinge die sich aktuell angesammelt haben...
Danke für das Super Modul und noch einen schönen Abend,
Tobi
Hallo Tobi,
heute Abend bin ich nicht mehr in der Lage tiefere Überlegungen anzustellen.
Aber ich habe mir deinen Post-Link für eine spätere Bearbeitung abgespeichert.
LG,
Heiko
Auch ich bin begeistert ob der Trefferquote. Die Abweichung betrug jetzt den dritten (!!) Tag in Folge < 1% :)
OpenMeteo API, Dachanlage mit zwei Strings ( Süd, Nord ) in Kombination mit einem BKW mit Mikroinverter.
Ein fettes DANKE für das Modul und die stetige Weiterentwicklung!
Hallo zusammen,
in meinem contrib liegt die V 1.51.6.
Die verfügbaren Balkencontents bzgl. Batteriewerten sind etwas umgebaut (um die neuen Optionen zu ermöglichen) und erweitert.
- der bisherige Content batsocforecast_XX ist in batsocCombi_XX umbenannt
- neuer Content batsocForecast_XX
- neuer Content batsocReal_XX
- neuer Content batsocForecastSum
- neuer Content batsocRealSum
Nun können die Batteriewerte wie folgt in den Balken dargestellt werden:
batsocCombi_XX der prognostizierte (ab kommender Stunde) und bis zur aktuellen Zeit real erreichte SOC (%) der Batterie XX
batsocForecast_XX der prognostizierte SOC (%) der Batterie XX
batsocReal_XX der real erreichte SOC (%) der Batterie XX
batsocForecastSum der prognostizierte SOC (%) als Summe über alle Batterien
batsocRealSum der real erreichte SOC (%) als Summe über alle Batterien
Die Umsetzung von batsocforecast_XX ist in batsocCombi_XX (falls gesetzt) erfolgt automatisch beim Restart. "Save" nicht vergessen.
@Gerd (Max__Meyer),
dein Request ist jetzt auch mit drin.
LG,
Heiko
Zitat von: DS_Starter am 30 April 2025, 14:49:16Hallo zusammen,
in meinem contrib liegt die V 1.51.6.
@Gerd (Max__Meyer),
dein Request ist jetzt auch mit drin.
LG,
Heiko
Hallo Heiko,
Danke! - für mich ist das optimal- hab's gleich probiert und seh jetzt 3x den Prognose-Ist-Vergleich
Gruß Gerd
PS: du musst aber auch mal Pause machen!
Hallo Heiko,
ich habe das in der Wiki erläuterte Diagram zur Darstellung der PV-Erzeugung umgesetzt und bin ganz begeistert, das Ganze jetzt auf diesem Wege verfolgen zu können. Allerdings finde ich persönlich die Darstellung besser mit "steps" anstatt "lines". (Siehe unterer Screenshot der deiner Umsetzung im Modul ähnelt.) Einziges Manko, es fehlt der AllPVforecastsToEvent-Eintrag=0 in der Stunde vor dem Sonnenaufgang. Dadurch fängt die Sonnenaufgangs-Stufe bereits beim Sonnenuntergang an. (siehe "initiale PV Vorhersage" im Bild.)
Meine Bitte: Könnt man zur vollen Stunden vor dem Sonnenaufgang noch ein AllPVforecastsToEvent=0 Eintrag setzen? (Oder eventuell für jede Stunde?)
Noch eine Frage zur AI beim DWD. Wie kommt es, dass nur die Sonnenhöhe und nicht auch die Sonnenrichtung Einfluss hat? Geometrisch gesehen ist z. B. bei mir die Verschattung und der Bestrahlungswinkel der Module von beiden abhängig? Die Uhrzeit ist da ja weniger relevant. Oder verstehe ich da etwas falsch?
Gruß
tupol
Guten Morgen,
@tupol, ich schau mir das mal an. Bin mir aktuell unsicher, ob das relativ einfach zu realisieren ist. Kann ich noch nicht sagen.
ZitatNoch eine Frage zur AI beim DWD. Wie kommt es, dass nur die Sonnenhöhe und nicht auch die Sonnenrichtung Einfluss hat? Geometrisch gesehen ist z. B. bei mir die Verschattung und der Bestrahlungswinkel der Module von beiden abhängig? Die Uhrzeit ist da ja weniger relevant. Oder verstehe ich da etwas falsch?
Die Sonnenrichtung wird auch berücksichtigt. Die Uhrzeit ist im Prinzip ein Stellvertreterwert für die Sonnenrichtung. Tatsächlich wird die KI aber neben der Uhrzeit auch mit dem Sonnenazimuth (sunaz) gefüttert. Zu beachten ist, dass wir immer mit Stundenslots arbeiten, alles im Modul (außer aktuelle "Current" Werte) wird auf Stundenbasis gerechnet.
In den Entscheidungssätzen wird das Azimuth aber kaum aufgeführt. Warum das so ist, kann ich nicht beantworten, nur mutmaßen.
So könnte ich mir vorstellen, dass die Trefferanzahl bei Benutzung der Uhrzeit höher ist. Kleines Beispiel zur Erläuterung. Hier sind ein paar Datensätze gleicher Uhrzeit:
2025033012 => hod: 12, nod: So, sunaz: 146, sunalt: 38, rad1h: -, wcc: 100, wid: 3, rr1c: 0.30, pvrl: 540, con: 584, temp: 7
2025033112 => hod: 12, nod: Mo, sunaz: 146, sunalt: 38, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 689, con: 574, temp: 7
2025040112 => hod: 12, nod: Di, sunaz: 146, sunalt: 38, rad1h: -, wcc: 64, wid: 2, rr1c: 0.00, pvrl: 4583, con: 1353, temp: 9
2025040212 => hod: 12, nod: Mi, sunaz: 145, sunalt: 39, rad1h: -, wcc: 20, wid: 1, rr1c: 0.00, pvrl: 4312, con: 982, temp: 11
2025040312 => hod: 12, nod: Do, sunaz: 145, sunalt: 39, rad1h: -, wcc: 0, wid: 0, rr1c: 0.00, pvrl: 5832, con: 1128, temp: 12
2025040412 => hod: 12, nod: Fr, sunaz: 145, sunalt: 40, rad1h: -, wcc: 0, wid: 0, rr1c: 0.00, pvrl: 5715, con: 918, temp: 16
2025040512 => hod: 12, nod: Sa, sunaz: 145, sunalt: 40, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 5015, con: 1123, temp: 11
2025040612 => hod: 12, nod: So, sunaz: 145, sunalt: 40, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 3007, con: 508, temp: 4
2025040712 => hod: 12, nod: Mo, sunaz: 145, sunalt: 41, rad1h: -, wcc: 56, wid: 2, rr1c: 0.00, pvrl: 4632, con: 641, temp: 9
2025040812 => hod: 12, nod: Di, sunaz: 145, sunalt: 41, rad1h: -, wcc: 27, wid: 1, rr1c: 0.00, pvrl: 3782, con: 417, temp: 11
2025040912 => hod: 12, nod: Mi, sunaz: 145, sunalt: 42, rad1h: -, wcc: 67, wid: 2, rr1c: 0.00, pvrl: 3729, con: 743, temp: 12
2025041012 => hod: 12, nod: Do, sunaz: 145, sunalt: 42, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 1449, con: 1198, temp: 9
Bei diesen 12 Datensätzen ist die Uhrzeit 12 mal gleich, das Azimuth aber nur 9 mal (145), die anderen Datensätze haben 1 Grad Änderung. Vermutlich hat das Auswirkung bei der Wichtung der Parameter, hod 12 wird vllt. als "höherwertiger" bei der Entscheidungsfindung als sunaz bei einem Grad Unterschied angesehen.
Wenn ich mal Zeit finde, will ich auch nochmal eine weitere KI, z.B. unter Verwendung von PDL::LinearAlgebra oder AI::NeuralNet::BackProp, implementieren und schauen wie sich die Ergebnisse damit gestalten.
LG,
Heiko
@tupol, @all,
in meinem contrib liegt die V 1.51.7.
Die Events 'AllPVforecastsToEvent'-Events starten nun in täglich mit einem 0-Event um den definierten Aufsetzpunkt für die SVG-Plots zu haben.
Darüber hinaus gibt es mit plantControl->genPVforecastsToEvent die Möglichkeit die Events für den Plot-Type 'steps' zu optimieren. Die generelle Aktivierung von 0-Werten zu Beginn jeder Stunde würde zu einer unschönen Darstellung bei SVG 'lines' führen (siehe 3. Screenshot).
genPVforecastsToEvent
Das Modul erzeugt täglich 'AllPVforecastsToEvent'-Events zur Visualisierung der PV Prognose.
Nähere Erläuterungen dazu sind im Wiki beschrieben
Die Eventerzeugung kann für bestimmte Nutzungen optimiert werden.
adapt4Steps - die Events werden für den SVG Plot-Type 'steps' optimiert
Die Auswirkung von genPVforecastsToEvent=adapt4Steps sieht man im 1. Screenshot.
LG,
Heiko
Zitat von: DS_Starter am 29 April 2025, 11:26:27Vergleichbar mit der Entwicklung vom Kleinkind über Schulkind zum Experten.
Hm, ich hoffe mal, das meinst du als Witz. Menschen lernen durch Regelbildung - ein neuronales Netz bildet keine Regeln.
LG
pah
Hallo pah,
damit wollte ich lediglich zum Ausdruck bringen, dass je mehr (Lern)datensätze der KI zur Vefügungung stehen die Anzahl der Knoten (und auch der Tiefe) steigt und damit eine granularere Ergebnisbildung ermöglicht wird.
Falls ich falsch liege oder es unrichtig ausgedrückt haben sollte ... bitte mich/uns gerne aufklären und es wissenschaftlich korrekt beschreiben. Ich lerne die Zusammenhänge um KI im Allgemeinen und deren Anwendung in unserem Kontext immer mehr und versuche weitere Verbesserungen zu erschließen.
LG,
Heiko
Es geht ja hier nicht um Wissenschaft, insofern können wir den Ball flach halten.
Aber noch einmal: Die KI-Modelle, die Du verwendest, kennen keine Regeln. Sie haben nichts verstanden und werden auch nie etwas "verstehen". Sie können lediglich Muster erkennen. Und wenn sie kein Muster erkennen, erfinden sie komplett neue Realitäten.
Ein guter und einfach formulierter Artikel dazu ist hier zu finden: https://de.wikipedia.org/wiki/Halluzination_(K%C3%BCnstliche_Intelligenz)
Für Deine Vorhersage ist das weitgehend irrelevant - im Zweifelsfall ist einfach die Vorhersage falsch. Wenn man allerdings, und sei es nur in einer Rand-Diskussion, den Eindruck erweckt, solche Systeme könnten lernen und denken, entsteht die gewaltige Gefahr des Missbrauchs.
LG
pah
Hallo Tobi,
ich habe nun ein wenig über deine Fragen in #2682 nachgedacht.
ZitatKann man auch eine (stündliche) Prognose des Netzbezugs haben?
...
Gibt es (eventuell in einer fernen Zukunft) die Möglichkeit ein Verbrauchsvorhersage über die KI mit der Wettervorhersage in Verbindung zu bringen?
Beide Dinge sind m.M. nach eng miteinander verbunden.
Bereits längere Zeit habe ich vor die Verbrauchsvorhersage mit einem KI-Algo unterstützen zu lassen. Die Jahreszeiten bzw. Temperaturen und weitere Umwelteinflüsse können dabei der KI zur Verfügung gestellt werden.
Der erwartete Netzbezug ist unter anderem vom Ladezustand der Batterien (wenn vorhanden) und der Tageszeit (Lastgang) abhängig. Auch das kann eine KI m.M. nach gut verknüpfen.
In der V 1.51.7 habe ich KI-Rohdatensammlung erweitert.
Beide Fragen würde ich jetzt mal mit "Ja" beantworten und habe sie bei mir in die Planung aufgenommen.
LG,
Heiko
@all,
die V 1.51.7 ist eingecheckt.
LG
Guten Tag Zusammen,
hier ein Tipp für die Nutzer der "ctrlSpecialReadings" bei den Consumern.
Mit FHEM bin ich die Tage vom RPI auf einen QNAP-Container umgezogen.
Parallel hab ich dabei 2 ConsumerXX (03/07) abgekoppelt und die zugehörigen attr gelöscht weil es sinnlos ist so geringe Verbraucher zu beobachten oder gar zu steuern.
Gestern bzw. heute habe ich dann zufällig dabei bemerkt das die "ctrlSpecialReadings" für die gesamten ConsumerXX nicht mehr bereitgestellt werden (einige Werte werden bei mir oben im Kopfbereich angezeigt),
Hier der Tipp :
Wer also einen ConsumerXX per attr "delete" entfernt muss darauf achten das er ihn auch bei den "ctrlSpecialReadings" nicht mehr angeklickt hat - falls er diese Werte als Reading vorher gesehen hat.
==>> Ansonsten werden alle ConsumerXX-Reading bei den "ctrlSpecialReadings" nicht mehr angezeigt.
Gruß
300P
##################
Hat sich mit V1.51.8 erledigt (s.u.) 8)
####################
Problem erkannt und ist mit V 1.51.8 behoben.
Die V habe ich soeben in mein contrib geladen.
LG
Hallo Heiko,
mein Consumer '_WP_Heizstab_WW' schaltet sich bei mir schön ein und aus:
2025.05.02 18:00:02 2: Forecast - Consumer '_Brunnen' was external switched off
2025.05.02 18:00:32 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.02 18:00:33 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.02 18:20:23 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.02 18:20:23 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.02 18:20:53 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
2025.05.02 18:20:53 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.02 18:20:53 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
Aber warum wird um 18:20:53 ein externes schalten dabei erkannt
- da wird eigentlich doch "nur" durch SF geschaltet
- irgendwie beachtet er auch nicht die 'locktime' von 300:300
(->>V1.51.8 )
EDIT : war auch schon vorher - hab mal im Log gesucht
Hier der Consumer '_WP_Heizstab_WW':
FBDECT_fbahahttp_E8_DF_70_07_42_0B
type=heater
power=2170
mode=can
icon=sani_buffer_electric_heater_side@orange
mintime=SunPath
on=on
off=off
asynchron=0
notbefore=08:00
notafter=19:00
locktime=300:300
pcurr=power:W
etotal=energy:Wh
surpmeth=10
interruptable=1
Zitat von: DS_Starter am 16 April 2025, 21:39:57Die Version V1.51.0 ist eingecheckt.
Es sind wie kommuniziert die Weiterentwicklungen V1.50.1 - 3 enthalten sowie:
- der Balkencontent batsocforecast_, energycosts, feedincome ist von der Wh -> kWh Konvertierung entkoppelt
- OpenMeteoDWDEnsemble: die Berechnung des Intervalls ist korrigiert
- ein neuer Setter cycleInterval zur dynamischen Anpassung der Datensammlung
- eine User spezifische Möglichkeit den Schwellenwert für die rot-Färbung der Haus->Consumer Linien festzulegen (flowGraphicControl->strokeCmrRedColLimit)
Die folgenden Attribute sind gelöscht (wenn obsolet) oder sind als Schlüssel in den Sammel-Attributen consumerControl bzw. plantControl aufgegangen:
- affectBatteryPreferredCharge, affectConsForecastInPlanning, ctrlShowLink, ctrlBackupFilesKeep
- affectConsForecastIdentWeekdays, affectConsForecastLastDays, ctrlInterval, ctrlGenPVdeviation
- affectSolCastPercentile, ctrlSolCastAPIoptimizeReq, consumerAdviceIcon, consumerLink, consumerLegend
Noch ein Wort zu den Attributen.
Ziel ist es, die Anzahl der Attribute im Zaum zu halten und wo es möglich und sinnvoll erscheint, thematisch in Sammelattributen zu clustern.
Es können später auch noch weitere Zusammenfassungen entstehen.
Solltet ihr jedoch aus irgendwelchen Gründen bestimmte Attribute weiterhin als separate Attribute benötigen, kann ich diese Attribute auch wieder aus den Sammelattributen herauslösen und als ctrl-Attr bereitstellen oder alternativ einen dynamischen Setter (wie cycleInterval) implementieren.
Solche Setter sind für dynamische Änderungen besser geeignet weil z.B. kein manueller "save" nötig ist.
Wie gesagt ist das Ziel so wenig Attribute wie möglich und soviel Attribute wie nötig im Modul zu haben.
Es soll aber keiner auf entsprechenden Komfort verzichten müssen.
Ich hoffe das klärt nochmal den Grund für diese Bemühungen.
PAH hatte seinerzeit ein schönes grafisches Interface auf JavaScript-Basis zur Einstellung aller Attribute angeregt. Das würde mir ebenfalls sehr gut gefallen. Allerdings sind meine JS-Fähigkeiten sehr beschränkt.
Wer diesbezüglich in der Lage ist und gern unterstützen möchte, ist herzlich willkommen.
LG,
Heiko
Hallo Heiko, ich habe heute nach (viel zu) langer Zeit ein Update laufen lassen und folgende Hinweise im Log gefunden, die ich in formativ teilen möchte:
2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14712.
2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14712.
2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14732.
2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14732.
Desweiteren zeigt mir FHEM folgende Hinweise:
Das mit den Perlwarnings ist bekannt und soweit okay
Schau mal hier im Beitrag #2605 und ..ff
Die Hinweise kommen weil evtl. Attribute inzwischen umbenannt worden sind.
Gruß
300P
@300P,
ZitatAber warum wird um 18:20:53 ein externes schalten dabei erkannt
- da wird eigentlich doch "nur" durch SF geschaltet
- irgendwie beachtet er auch nicht die 'locktime' von 300:300
Die Ursache der externen Schaltung bzw. der locktime kann man so nicht erkennen -> ctrlDebug=consumerSwitchingXX sollte hier helfen.
Wahrscheinlich gibt es noch eine Schaltung durch einen anderen Einfluß als SF.
@Dracolein,
mit den aktuellsten Versionen (ab 1.51.4) sollten die $FWxx Warnungen gefixt sein.
Ansonsten hat sich viel getan, wie 300P schon geschrieben hat.
LG,
Heiko
@300P,
zur Erläuterung ...
die Meldung
Consumer 'XXX' was external switched off/on
kommt immer dann, wenn der aktuelle Schaltzustand des Consumers nicht mit dem zuletzt aufgezeichneten (durch SF verurachten) Schaltzustand des Consumers im SF übereinstimmt.
Ausgewertet wird das Reading/regex des Schlüssels "swstate". Möglicherweise wird der Consumer nicht real geschaltet, aber der Inhalt des Readings ändert sich was nicht sein sollte.
Hallo Heiko,
Danke für die Hinweise und Ja das mit dem "external" kenn ich von 2 anderen Consumer - Brunnen und Lampe -
A:
Mein Brunnen macht es wenn er über seine "im Fritz-Gerät hinterlegte normale" Zeitschaltung ein/aus geschaltet wird.
B:
Die Lampe macht es immer wenn sie über die "im Fritz-Gerät hinterlegte normale" Zeitschaltung1 Stunde vor dem Sonnenuntergang ON geschaltet wird und um 22:15 OFF geschaltet wird.
Beide werden aber nicht über SF gesteuert / nur Anzeige =>> noSchedule.
Der Heater benutzt die vormals vor meinem RPI installierte Fritz546. Da hab ich nur wenn nötig den RPI aus der Ferne "hart" ab und an neu gestartet.
Da ist nichts an ON/OFF Schaltungen im Gerät hinterlegt, sonst hätte der RPI dann immer wieder einen Neustart gehabt und wäre bei der Anmeldung hängen geblieben. Soeben etwa nochmals im Gerät kontrolliert - da ist keine Schaltung im Protokoll aufgezeichnet worden.
Ich logge es mal in SF.....und berichte...
Gruß
300P
Guten Morgen,
heute gibt es nicht genug PV-Ertrag - also hab ich das "Loggen" erst einmal unterbrochen.
Gruß + schönes WE (mit hoffentlich mehr Sonne die Tage)
300P
Hallo,
ich bekomme für meine Anlage einen etwas seltsamen Forecast beim Übergang vom Ostdach auf das Westdach.
Insbesondere der Forecast für 14:00 ist massiv zu hoch.
Das hier sollten die relevanten Teile der Config sein:
setupStringAzimuth:NW=120 SO=-60
setupStringDeclination:NW=45 SO=45
setupInverterDev01:Sungrow pv=Total_DC_Power:W etotal=kWh:kWh capacity=5800 strings=NW
setupInverterDev02:Fronius pv=Total_DC_Power:W capacity=5400 etotal=kWh:kWh strings=SO
Anbei ein Tagesgraph eines durchweg sonnigen Tages, der den Effekt verdeutlicht. Ich muss dazu sagen, dass es speziell auf der SO Seite am Nachmittag Verschattungen gibt und alle Panels mit Optimierern laufen. Müsste ich das anders konfigurieren?
Allerdings habe ich schon Forecasts von 10KW für den 14:00 Timeslot gesehen - realistisch schaffen beide Anlagenteile aufgrund der Ausrichtung aber maximal so jeweils 4200W Peakleistung und der gemeinsame Peak geht kaum über 6KW hinaus.
Gruß,
Jörg
Hallo Jörg,
Ich denke es ist alles richtig konfiguriert. Wie sieht denn das Attr setupStringPeak aus?
Auf dem Screenshot kann ich leider nichts erkennen, außer dass es zwei schöne gegenseitig versetzte Kurven mit jweils einem Maximum gibt. Den 14:00 Punkt sehe ich nicht.
Grundsätzlich begrenze ich die max. Leistung auf die Summe der Inverter-Leistung bzw. der String-Leistung. Aber wegen deines Ost/West Versatzes hinkt das etwas, da wie du ja schon geschrieben hast, in deinem Fall eine Begrenzung der max. Leistung vorher eingreifen müßte.
Sollte es durch die Korrekturfaktoren oder die KI (macht sie schonmal gern) zu Übertreibungen nach oben kommen, greift die max. Begrenzung zu spät ein.
Habe schon etwas darüber nachgedacht, sehe aber aktuell keine Möglichkeit seitens des Moduls die Max-Begrenzung so flexibel zu gestalten, dass dein Case abgebildet wird.
Was ich in Planung habe, ist ein eigenes neuronales Netz zu implementieren (zunächst für Hausverbrauch und Netzbezug). Sollte sich das als sehr günstig erweisen, würde ich es vermutlich auch auf die PV-Erzeugung erweitern um noch bessere KI-Prognosen zu erreichen. Aber das muß die Zukunft zeigen ... uns geht nichts verloren, die Rohdaten werden ja fleißig gesammelt.
Grüße,
Heiko
@300P,
mir fällt gerade etwas ein.
Kann es sein, dass es bei deinem Problem genau um den Heizstab geht, den wir über die ctrlUserExitFn quasi an der Consumersteuerung vorbei "extern" schalten?
Das würde die Meldung "Consumer 'XXX' was external switched off/on" erklären.
Die Frage bzgl. locktime kann nur durch das Debug beantworten.
@DS_Starter:
Ja - genau der ist es.
In der Nacht schaltet der "ctrlUserExitFn" sauber als externer um, das macht er ohne Murren und genau richtig:
attr Forecast ctrlUserExitFn {\
\
my $dt = timestringsFromOffset (time, 0);;\
my $hour = $dt->{hour};; # aktuelle Stunde in 24h format (00-23)\
my $timestart = "1";; # ab welcher Uhrzeit soll es sein\
my $timeend = "8";; # bis wieviel Uhr soll es sein\
\
if (int $hour >= $timestart && int $hour < $timeend ) {\
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr\
\
my $minsocbat = "30";; # nur bis mindesten XY SoC aller Batterien\
my $heater = (split " ", AttrVal ($name, 'consumer06', ''))[0];; # Heater-Name von ConsumerXX\
my $soctotal = CurrentVal ($name, 'batsoctotal', 0);; # SoC über alle Bat als Durchschnitt\
my $pvtot = ReadingsNum ($name, 'RestOfDayPVforecast', 0);; # Restliche PV Prognose total heute in Wh\
# war my $pvtot = ReadingsNum ($name, 'Today_PVforecast', 0);; # PV Prognose total heute in Wh\
my $caps = CurrentVal ($name, 'batcapsum', 0);; # Summe installierte Bat Wh\
my $need = $caps - ($soctotal/100 * $caps);; # benötigte Ladeenergie Bat bis 100% Ladung\
\
\
Log3 ($name, 5, qq{$name - userFn -> WWHeater Reading ist = $heater - aktuelle Stunde = $hour aus $dt erzeugt });;\
Log3 ($name, 5, qq{$name - userFn -> StartZeit von = $timestart bis EndeZeit = $timeend und mindestens ein SoC von $minsocbat % muss in den vorhandenen Batterien gegeben sein });;\
Log3 ($name, 5, qq{$name - userFn -> Der PV-Tages-Restertrag betraegt $pvtot Wh ???mehr??? als die offene und noch zu ladende Batteriekapazitaet von $need Wh});;\
\
if ($soctotal >= ($minsocbat - 2) && $pvtot > $need) { \
# Zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr und % SoC-Vorgabe erfüllt und der PV-Tages-Rest-Ertrag > 100% Batteriekapazitaet\
# send "on"-Kommando an Heater Device if(ne "on");;\
if (ReadingsVal($heater,"state","") ne "on") {\
fhem ("set ".$heater." on");;\
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --on--});;\
}\
}\
else {\
if (($soctotal < $minsocbat) || ($pvtot <= $need)) { \
# Wenn die (SoC-Vorgabe unterschritten !!!!! oder !!!! derTages-Rest-Ertrag < 100% Batteriekapazitaet)\
# danach sollte der Heater-ConsumerXY wieder nach "seinen" Regeln steuern...\
# send "off"-Kommando an Heater Device if(ne "off");;\
if (ReadingsVal($heater,"state","") ne "off") {\
fhem ("set ".$heater." off");;\
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --off--});;\
} \
}\
}\
}\
}
Hier der zugehörige "consumer06" (tagsüber -> SF-Consumerschaltung)
attr Forecast consumer06 FBDECT_fbahahttp_E8_DF_70_07_42_0B \
type=heater \
power=2170 \
mode=can \
icon=sani_buffer_electric_heater_side@orange \
mintime=SunPath \
on=on \
off=off \
asynchron=0\
notbefore=08:00 \
notafter=19:00 \
locktime=300:300 \
pcurr=power:W \
etotal=energy:Wh\
surpmeth=10 \
interruptable=1\
Gruß
300P
Ich glaube hier ist noch ein logischer Fehler drin:
if (int $hour >= $timestart && int $hour < $timeend ) {
# diverse Logik zur Schaltung -> i.O.
}
else {
# Ausschaltung nach Bedingung -> nicht i.O. da else-Zweig IMMER außerhalb der if-Zeitgrenzen ausgeführt wird
}
Der else-Zweig ist so m.M. nach falsch.
Du müsstest den gesamten Code zur Schaltung nur innerhalb des if-Zweiges einbetten, also:
attr Forecast ctrlUserExitFn {
...
if (int $hour >= $timestart && int $hour < $timeend ) {
# hier die gesamte Logik zur Schaltung einbetten, die gesamte Logik soll nur innerhalb von $timestart und $timeend laufen
}
}
Hallo Heiko,
laut meiner nochmaligen Editorprüfung war / ist die {}-Setzung so i.o. und das "else" ist innerhalb der Zeitprüfung.
Nur die Einrückung spiegelt das leider nicht so ganz astrein genau so wieder O:-)
=> Die drittletzte Klammer ist da etwas zu weit links geraten.
Gruß
300P
Hast recht. Also warten auf das Debug. Hier regnet es heute auch...
Grad hat sich der Heater eingeschaltet.... :o
logge jetzt mal - muss sich ja wieder ausschalten. ;D
Du könntest in deiner Rotine das Log3 noch so ergänzen, dass man sieht wenn der Vorgang in dieser Routine ausgeführt wird, also 'UserExitFn' ergänzen o.ä.
Hier das log (ungeprüft)
2025.05.03 14:54:28 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.03 14:54:28 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.03 14:55:58 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2864.8
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2631 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 210 seconds
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:55:58 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:56:00 1: PERL WARNING: Missing argument in sprintf at (eval 1365583) line 1.
2025.05.03 14:56:13 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2867.8
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2639 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 195 seconds
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:56:13 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:56:28 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2831.6
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2649 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 180 seconds
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:56:28 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:56:43 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2758.7
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2621 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 165 seconds
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:56:43 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:56:58 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2664.9
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2605 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 150 seconds
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:56:58 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:57:13 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2575.3
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2621 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 135 seconds
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:57:13 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:57:28 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2307.5
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2643 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 120 seconds
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:57:28 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:57:43 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 2045.4
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2642 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 105 seconds
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:57:43 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:57:58 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 1766.4
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2674 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 90 seconds
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:57:58 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:58:13 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 1461.6
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2627 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 75 seconds
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:58:13 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:58:28 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 1179.4
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2670 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 60 seconds
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:58:28 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:58:43 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 921.3
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2672 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 45 seconds
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:58:43 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:58:49 1: FCU: Can't open /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0: No such file or directory
2025.05.03 14:58:58 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 671.1
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2650 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 30 seconds
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:58:58 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:59:13 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 432.1
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2689 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 15 seconds
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:59:28 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 208.3
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2653 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - isInLocktime: 1
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:59:43 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - current planning state: interrupting
2025.05.03 14:59:43 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
2025.05.03 14:59:49 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 294 seconds
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
2025.05.03 14:59:58 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 285 seconds
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:58 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
2025.05.03 15:00:01 1: sub TibberDatenOhneVertrag: setze Uhrzeit 15 bei 15 Preis 0.2119
2025.05.03 15:00:04 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 619 W, nompower: 2170, surplus: 1530 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 279 seconds
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 15:00:04 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
2025.05.03 15:00:13 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 619 W, nompower: 2170, surplus: 1530 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 270 seconds
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 15:00:13 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
2025.05.03 15:00:28 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 553 W, nompower: 2170, surplus: 1651 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 255 seconds
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 15:00:28 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
2025.05.03 15:00:43 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 408 W, nompower: 2170, surplus: 1831 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 240 seconds
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
jump to the top
Zitat von: DS_Starter am 03 Mai 2025, 15:02:03Du könntest in deiner Rotine das Log3 noch so ergänzen, dass man sieht wenn der Vorgang in dieser Routine ausgeführt wird, also 'UserExitFn' ergänzen o.ä.
Ist schon drin:
fhem ("set $heater on");;\
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --on--});;\
......
......
fhem ("set $heater off");;\
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --off--});;\
Also was ich zunächst sehe ist, dass locktime korrekt berücksichtigt, aber falsch geloggt wird:
...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 15 seconds
...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
Letzter Start war entgegen dem Log um 14:54:28, sieht man ganz am Anfang des Log. Bei 300 Sek locktime wäre 15:59:28 das Ende, was auch richtig gewertet wird. Aktuell ist es 14:59:13 und es wird 15 Sekunden Restlocktime ausgegeben -> das passt.
Die Logausgabe "last cycle start time: 2025-05-03 14:55:28" stimmt nicht, schaue ich mir an.
Etwas später:
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"
2025.05.03 14:59:43 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
Ist völlig i.O., die locktime ist um und kein Überschuß mehr. Bei der Endzeit gibt es ein paar Sekunden Unterschied, schaue ich mir auch an. Kann es sein, dass die Änderungszeit der Statusreadings etwas von der Zeit im SF abweicht? Kann ich mir momentan nicht erklären, sieht aber so aus.
Das wars schon im Prinzip. Danach sieht man wieder wie die remainLockTime heruntergezählt wird:
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 240 seconds
Ist auch ok.
Hallo 87insane,
in meinem contrib liegt die V 1.51.9 zum testen des Inverter im BKW.
Man kann nun strings=none im IntverterDev angeben. Dadurch werden die Eigenschaften des Inverters verändert.
Das setup-Attribut wäre etwa so anzugeben:
<Inverter-Device>
pv=energie_aus_bat:W etotal=etotal_inv:kWh
capacity=1000
strings=none
icon=inverter@darkorange:inverter@grey
Im Icon bietet sich an die Sonne zu ersetzen, da der Inverter aus der Bat gespeist wird.
Die Flußgrafik ist erst halb fertig. Hier fehlt noch die Verknüpfung von Bat -> Inverter wie im Anhang dargestellt.
Es kommt erstmal auf die Logik an.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 03 Mai 2025, 10:18:43Ich denke es ist alles richtig konfiguriert. Wie sieht denn das Attr setupStringPeak aus?
Habe ich entsprechend der technischen Spezifikation der Strings definiert:
setupStringPeak:NW=5.84 SO=5.34Wie gesagt erreichen diese durch ihre Ausrichtung etc. eigentlich nie das technische Peak. Ich bin davon ausgegangen, dass dies mit Hilfe der Orientierung und Neigung berücksichtigt wird. Besonders beim SO-Dach gibt es allerdings Verluste durch die Optimierer und falsche Wechselrichterwahl (das hat der Solateur so richtig verbockt, hab ich jetzt zumindest halbwegs korrigiert). Da sind 4500 Peak wahrscheinlich das Maxiumum. Beim NW macht der Wechselrichter dann auch bei 5000 Schluss.
ZitatAuf dem Screenshot kann ich leider nichts erkennen, außer dass es zwei schöne gegenseitig versetzte Kurven mit jweils einem Maximum gibt. Den 14:00 Punkt sehe ich nicht.
Ja, die SVGs sind da leider u.U. schwer zu lesen/konfigurieren.
Der Schnittpunkt der beiden Kurven ist ziemlich genau gegen 14:00 bei einem Wert von ca. 3000 Watt, das jeweilige Maximum bei etwa 4000 Watt.
Der Algorithmus scheint aber zu glauben, dass im Mittelbereich der Überlappung beide Strings fast auf volle Leistung gehen - was bei 180 Grad entgegengesetzten Dächern aber doch generell unrealistisch sein sollte.
Gerade bemerkt das die KI Status "rot" hatte, weil Storage voll war - vielleicht hat das zusätzliche Probleme verursacht - zumindest wird er Probleme gehabt haben zu lernen.
Jörg
Hallo Jörg,
Strings sehen auch gut aus.
ZitatIch bin davon ausgegangen, dass dies mit Hilfe der Orientierung und Neigung berücksichtigt wird.
Ja natürlich sind die Ergebnisse der gewählten API (KI ohnehin) unter Berücksichtigung der Ausrichtung der Module und weiterer Parameter.
Nur das absolut rechnerische Maximum wird durch mich begrenzt, und das sind die Summen der Inverterleistungen bzw. max. möglichen Stringleistungen.
Das sind aber nur ein Hilfsmittel. Wenn die Ergebnisse der API, der evtl. Korrekturfaktoren und/oder KI ein Ergebnis nahe der Realität bringen, was ja unser Ziel ist, wird die künstliche Begrenzung nicht eingreifen müssen.
ZitatDer Algorithmus scheint aber zu glauben, dass im Mittelbereich der Überlappung beide Strings fast auf volle Leistung gehen
Kommt auf die gewählte API an. Beim DWD-Device rechnen wir im Modul jeden einzelnen String nach der Methode von pah und bilden die Summe. Bei anderen API's liefert die API für jeden einzelnen String die Prognosewerte, die sich dann summieren. Also den EINEN Algo gibt es so nicht. Die KI (wenn aktiviert) übersteuert ggf. je nach gewählter Option.
Du kannst uns ja mal die Readings pvCorrectionFactor_XX zeigen. Das ist i.A. recht aufschlußreich.
Grüße,
Heiko
Zitat von: DS_Starter am 03 Mai 2025, 15:42:54Also was ich zunächst sehe ist, dass locktime korrekt berücksichtigt, aber falsch geloggt wird:
...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 15 seconds
...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
Letzter Start war entgegen dem Log um 14:54:28, sieht man ganz am Anfang des Log. Bei 300 Sek locktime wäre 15:59:28 das Ende, was auch richtig gewertet wird. Aktuell ist es 14:59:13 und es wird 15 Sekunden Restlocktime ausgegeben -> das passt.
Die Logausgabe "last cycle start time: 2025-05-03 14:55:28" stimmt nicht, schaue ich mir an.
Etwas später:
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"
2025.05.03 14:59:43 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
Ist völlig i.O., die locktime ist um und kein Überschuß mehr. Bei der Endzeit gibt es ein paar Sekunden Unterschied, schaue ich mir auch an. Kann es sein, dass die Änderungszeit der Statusreadings etwas von der Zeit im SF abweicht? Kann ich mir momentan nicht erklären, sieht aber so aus.
Das wars schon im Prinzip. Danach sieht man wieder wie die remainLockTime heruntergezählt wird:
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 240 seconds
Ist auch ok.
Schau einmal hier - ist doch eigentlich okay mit der End-Last-Cycle-Zeit:
2025.05.03 14:59:28 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 208.3
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2653 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - isInLocktime: 1
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - last cycle end time: still running
2025.05.03 14:59:43 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - current planning state: interrupting
2025.05.03 14:59:43 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
2025.05.03 14:59:49 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 294 seconds
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28
Meinem Fehler mit dem "external switch" bleib und bin ich weiter auf der Spur - sobald ich was sehe melde ich mich wieder.
Danke für die Unterstützung und deine Zeit ;)
Gruß
300P
Zitat von: Adimarantis am 03 Mai 2025, 09:40:53Hallo,
ich bekomme für meine Anlage einen etwas seltsamen Forecast beim Übergang vom Ostdach auf das Westdach.
Insbesondere der Forecast für 14:00 ist massiv zu hoch.
Das hier sollten die relevanten Teile der Config sein:
setupStringAzimuth:NW=120 SO=-60
setupStringDeclination:NW=45 SO=45
setupInverterDev01:Sungrow pv=Total_DC_Power:W etotal=kWh:kWh capacity=5800 strings=NW
setupInverterDev02:Fronius pv=Total_DC_Power:W capacity=5400 etotal=kWh:kWh strings=SO
Anbei ein Tagesgraph eines durchweg sonnigen Tages, der den Effekt verdeutlicht. Ich muss dazu sagen, dass es speziell auf der SO Seite am Nachmittag Verschattungen gibt und alle Panels mit Optimierern laufen. Müsste ich das anders konfigurieren?
Allerdings habe ich schon Forecasts von 10KW für den 14:00 Timeslot gesehen - realistisch schaffen beide Anlagenteile aufgrund der Ausrichtung aber maximal so jeweils 4200W Peakleistung und der gemeinsame Peak geht kaum über 6KW hinaus.
Gruß,
Jörg
Hallo Jörg,
eine ähnliche Konfiguration gibt es bei mir - evtl. sogar noch komplexer. O:-)
attr Forecast setupBatteryDev01 SBS37 pin=-pout:kW pout=total_pac:kW pinmax=3680 poutmax=3680 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap:Wh show=3:top icon=@yellow:@green:@red:@white asynchron=0
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW pinmax=2500 poutmax=2500 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap:Wh show=3:top icon=@yellow:@green:@red:@blue asynchron=0
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=100 asynchron=0
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=100 asynchron=0
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=100 asynchron=0
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupRadiationAPI OpenMeteoDWD-API
attr Forecast setupStringAzimuth GarageSE=-55 GarageNW=135 HausNW=135 HausSW=35 HausSE1=-55 HausSE2=-55
attr Forecast setupStringDeclination GarageSE=38 GarageNW=38 HausNW=48 HausSW=48 HausSE1=48 HausSE2=48
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.100 HausSE2=2.100
attr Forecast setupWeatherDev1 OpenMeteoDWD-APIDa werden die Leistungen der einzelnen String sogar schon vorab durch den WR schon gekappt. 8)
Aber - die Gesamtleistung meiner PV hat augenscheinlich den Vorteil, dass sie durch die verteilten 3 Stringrichtungen schön langsam hoch und wieder runter geht.(rote Linie 1 SVG)
Man könnte sagen :"Das war so von Anfang an so gewollt" O:-)
Insgesamt lag die Prognose am Anfang 20-40 % daneben - mit der Zeit bin ich jetzt real so um die +/-10 % gegenüber den Berechnungen.
Gruß
300P
@DS_Starter
Heute gab es Erfolg bei der Suche mit meinem Heater "external switch"-Bug:
z.B.
ohne log :'(
2025.05.04 13:49:17 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
2025.05.04 13:49:32 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
mit special-log ;)
2025.05.04 14:43:29 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
2025.05.04 14:43:44 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
==>> siehe txt-Datei
Gruß
300P
@300P,
ich habe einen Ansatz.
Der Heater ist ja ein MQTT-Device. Im Log sieht man, dass dieses Device asynchron arbeitet (hätte mir auch ohne Log klar sein müssen :-[ ). Im Consumer Attribut ist aber synchron (asynchron=0) spezifiziert.
Das führt im Prinzip dazu, dass nach einem on/off Kommando das Ergebnis nicht registriert wird, weil der Event des Consumers ignoriert wird. Erst beim nächsten regulären Zyklus.
Schalte in dem Attr asynchron=1 bitte ein und im ctrlDebug zusätzlich notifyHandling ein damit man die Eventverarbeitung sieht bzw. was da abläuft oder nicht. Dann schauen wir nochmal.
LG,
Heiko
MQTT-Gerät ?
sorry -editiert
defmod FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT fbahahttp:E8_DF_70_07_42_0B switch,powerMeter,switch
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B DbLogExclude .*
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B DbLogInclude power,energy
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B alias _WP_Heizstab_WW
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B event-min-interval power:300,energy:300
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B event-on-change-reading power,energy
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B event-on-update-reading power,energy
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B model Powerline546E
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B room FBDECT
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B userReadings solarforecast_auto
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B verbose 2
Zitat von: DS_Starter am 04 Mai 2025, 19:23:55@300P,
Schalte in dem Attr asynchron=1 bitte ein und im ctrlDebug zusätzlich notifyHandling ein damit man die Eventverarbeitung sieht bzw. was da abläuft oder nicht. Dann schauen wir nochmal.
Hallo Heiko,
das ist jetzt eingeschaltet (auf 1 geändert) - Morgen schauen wir mal was passiert.
Danke 8)
Gruß
300P
HTTP wollte ich schreiben ... man sollte nicht soviel parallel machen ;)
Aber um was es mir geht, ist hier zu sehen:
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on"
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - current planning state: continuing
2025.05.04 14:03:36 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - cycleDayNum: 3
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-04 13:49:47
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-04 13:56:21
Die SF Routine wartet nicht auf das Schaltergebnis des Devices weil es non-blocking arbeitet, also asynchron.
Edit: Ich bin mir jetzt nicht mehr so sicher ob ich auf dem richtigen Weg bin. Ist, glaube ich, nicht mein Tag heute. >:( Aber sei es drum, ein Versuch ist es wert.
Schauen wir morgen nochmal drauf.
Kann man irgendwo angeben dass der Akku bitte bis z.b. 14:00 Uhr gefüllt sein soll?
Bisher ist es bei mir so, dass der Akku erst zum Abend gefüllt ist.
Wenn ich aber Nachmittags mit dem Auto nach Hause komme, dann wäre es schön, wenn der Hausakku bereits voll wäre, sodass der dann noch vorhandene Überschuss dann ins Auto wandern kann.
Gruß Jens
Hallo Jens,
bisher gibt es dieses Feature nicht, müsste ich einbauen bzw. mich damit beschäftigen eine solche Logik zu erstellen.
LG,
Heiko
Zitat von: Bitschubser am 05 Mai 2025, 17:23:54Kann man irgendwo angeben dass der Akku bitte bis z.b. 14:00 Uhr gefüllt sein soll?
Klar. Wenn es uns gelingt, die Wettersteuerung in FHEM zu integrieren. Dann kann man wählen, wann wieviel Sonne scheint.
LG
pah
Zitat von: DS_Starter am 04 Mai 2025, 19:53:11.....
Ich bin mir jetzt nicht mehr so sicher ob ich auf dem richtigen Weg bin. Ist, glaube ich, nicht mein Tag heute. >:( Aber sei es drum, ein Versuch ist es wert.
Schauen wir morgen nochmal drauf.
Hallo Heiko,
neuer Versuch (wenn du das mit dem Wetter im Griff hast ;) )
=>> ctrlDebug bzw. zusätzlich notifyHandling
Anbei die Log-Datei (gezippt wegen der Größe - aber mit mehrfachen on/off des "Heater").
Gruß
300P
Zitat von: Bitschubser am 05 Mai 2025, 17:23:54Kann man irgendwo angeben dass der Akku bitte bis z.b. 14:00 Uhr gefüllt sein soll?
Bisher ist es bei mir so, dass der Akku erst zum Abend gefüllt ist.
Wenn ich aber Nachmittags mit dem Auto nach Hause komme, dann wäre es schön, wenn der Hausakku bereits voll wäre, sodass der dann noch vorhandene Überschuss dann ins Auto wandern kann.
Gruß Jens
Hallo Jens,
versuche es evtl. mal diesen ctrlUserExitFn und bau dir diesen aus
.
->> Bereich "-Batterieladungaktiv- on/off" muss du natürlich eigenständig erledigen.
Diese Details für deine Batterie kennst nur du und musst es selber ergänzen.
->> Ob die Ladebedingungen richtig passen ?? - selbst Hand anlegen und prüfen / anpassen.
{
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
my $timestart = 9; # ab welcher Uhrzeit soll es sein
my $timeend = 14; # bis wieviel Uhr soll es sein
if (int $hour >= $timestart && int $hour < $timeend ) {
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
my $minsocbat = 100; # laden nur bis mindesten XYZ SoC aller Batterien
my $soctotal = CurrentVal ($name, 'batsoctotal', 0); # SoC über alle Bat als Durchschnitt
my $pvtot = ReadingsNum ($name, 'RestOfDayPVforecast', 0); # Restliche PV Prognose total heute in Wh
my $caps = CurrentVal ($name, 'batcapsum', 0); # Summe installierte Bat Wh
my $need = $caps - ($soctotal/100 * $caps); # benötigte Ladeenergie Bat bis 100% Ladung
Log3 ($name, 5, qq{$name - userFn -> StartZeit von = $timestart bis EndeZeit = $timeend und mindestens ein SoC von $minsocbat % sollte bis dahin in den vorhandenen Batterien geladen worden sein, soweit es technisch möglich ist.});
Log3 ($name, 5, qq{$name - userFn -> Der PV-Tages-Restertrag betraegt $pvtot Wh ???mehr??? als die offene und noch zu ladende Batteriekapazitaet von $need Wh});
if ($soctotal < ($minsocbat) && $pvtot > $need) {
# Zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr und % SoC-Vorgabe erfüllt und der PV-Tages-Rest-Ertrag > 100% Batteriekapazitaet
# send "on"-Kommando an Batterie-Device if(ne "on");
if (-Batterieladungaktiv- ne "on") {
fhem ("set -Batterieladung- on");
Log3 ($name, 2, qq{$name - userFn -> $name BatteryLoad in $name set to --on--});
}
}
else {
if (($soctotal >= $minsocbat) || ($pvtot <= $need)) {
# Wenn die (SoC-Vorgabe unterschritten !!!!! oder !!!! derTages-Rest-Ertrag < 100% Batteriekapazitaet)
# danach sollte die Batterieladung enden....
# send "off"-Kommando an Batterie-Device if(ne "off");
if (-Batterieladung- ne "off") {
fhem ("set -Batterieladung- off");
Log3 ($name, 2, qq{$name - userFn -> $name BatteryLoad in $name set to --off--});
}
}
}
}
}Gruß
300P
@300P,
die Idee von gestern bzgl. asynchron war eine Sinnestäuschung von mir, die Reaktionen auf on/off Kommandos aus dem Consumer Schaltmodul erfolgen sofort:
2025.05.05 10:59:33 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"
2025.05.05 10:59:33 1: Forecast DEBUG> consumer "06" - current planning state: interrupting
2025.05.05 10:59:33 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
...
2025.05.05 11:06:18 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on"
2025.05.05 11:06:18 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.05 11:06:18 1: Forecast DEBUG> consumer "06" - current planning state: continuing
2025.05.05 11:06:18 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
...
2025.05.05 11:30:30 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"
2025.05.05 11:30:30 1: Forecast DEBUG> consumer "06" - current planning state: interrupting
2025.05.05 11:30:30 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
Bezüglich der externen Kommandos habe ich herausgefunden, dass sie lediglich in der Zeit von 10:00 bis 10:59 auftauchen, das Log startet 08:09 und endet 11:36.
2025.05.05 10:21:17 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
2025.05.05 10:21:32 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
2025.05.05 10:44:07 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
2025.05.05 10:44:22 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
2025.05.05 10:49:10 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
2025.05.05 10:49:25 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
2025.05.05 10:59:48 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
2025.05.05 10:59:51 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
Das kann Zufall sein, wäre aber ein Anhaltspunkt. Auf jeden Fall sendet Consumer Schaltmodul keine Kommandos die es verursachen könnten.
Ich tippe auf ein Problem mit der Switch State Erkennung wenn es tatsächlich keine echten externen Schaltungen gibt. Zur Zeit verwendest du den Standard.
Setze dir mal swstate explizit:
swstate=state:.*on.*:.*off.*
Dann schauen wir nochmal.
Das notifyHandling Debug kannst du ausschalten, war ein Holzweg.
Grüße,
Heiko
Hallo Heiko,
Danke für die Analyse und die Fehlersuche.
Ich bin mir zu 100% sicher das da keiner ,,externe" manuelle Schaltungen vorgenommen hat.
Ich habe die Anpassung
swstate=state:.*on.*:.*off.* vorgenommen.
Morgen geht's dann weiter.
Gruß + schönen Restabend
300P
Guten Morgen Allerseits!
@Heiko:
Hier noch eine SVG passend zu der Zeit des gestrigen "Geister"-Umschalten.
(z.Z. kommt alles was an Werten irgendwie zur WP gehört in die SQL-Datenbank) O:-)
Gruß
300P
Also das sieht mir so aus, dass der Heater tatsächlich schaltet wenn die Statusänderung in der DB landet. Ist das ein intelligentes Teil welches selbstständig schalten kann aufgrund irgendwelcher Eingangswerte?
Kann mir aktuell keinen Reim darauf machen.
@ 300P
Bitte poste mal den genauen Typ Deines Heizstabes, damit man sich mit den technischen Daten befassen kann.
Danke und Gruß!
Peter
Hallo Heiko,
=> Nein - das ist ein Fritz 546E. Der schaltet nur wenn man:
A: manuell am Taster drückt (==>>ist nicht passiert)
B: wenn man eine automatische Schaltung z.B. von HH:MM bis HH:MM einstellt (==>>ist nicht eingestellt)
C: oder für stand eine Leistungschwelle von xyxyx W eingibt (==>>ist nicht eingestellt)
D: per Fritzbox schaltet (==>>ist nicht passiert)
E: per Handyapp schaltet (==>>ist nicht passiert)
F: per FHEM mittels einem "fbahahttp"-Device schaltet ? ? ?
Eine Idee habe ich nach langem Kopfzerbrechen aber noch gehabt:
Der Heater wird mit einem relativ langsam Zyklus abgefragt. Der "INTERVAL = 300 s" ist so vom "fbahahttp"-Fritzbox-Device im Standart vorgegeben. Leider kann man dies nicht im "Heater"-Device einzeln anpassen.
Könnte sein das diese Abfragelänge da einwirken könnte wenn das als Änderung vom Heater"-Device einen Event auslöst.
Ich habe diesen Interval heute morgen mal auf 60 s (Minimalinterval bei Fritzbox-Device) verkürzt und wollte am Nachmittag mal sehen ob sich heute dann was verändert hat. Zusätzlich logge ich neben aktueller "power" und dem Zählerstand "energy" ab heute auch den Status "state" (On/Off) jetzt auch mal dort mit.
Gruß
300P
Zitat von: seayak am 06 Mai 2025, 13:11:17@ 300P
Bitte poste mal den genauen Typ Deines Heizstabes, damit man sich mit den technischen Daten befassen kann.
Danke und Gruß!
Peter
TÜRK+HILLINGER
EHK 230V 2000W =>>> TH 1105340 Temperaturgeführt bis zu 80 Grad
EDIT : 2000 Watt
Zwischeninfo zu meinem "Problem":
Heute Nachmittag gab es nach der Umstellung auf 60s (2 Beiträge vorher) keine "Geisterschaltung" des Heaters mehr. O:-)
Nur Schaltungen von Solarforecast wegen Wolken / Sonne / Wolken.....
Schau'n wir mal was morgen so passiert - weil es bislang meist morgens passierte :o
Schönen Restabend
300P
Zitat von: 300P am 06 Mai 2025, 13:21:05Hallo Heiko,
=> Nein - das ist ein Fritz 546E. Der schaltet nur wenn man:
A: manuell am Taster drückt (==>>ist nicht passiert)
B: wenn man eine automatische Schaltung z.B. von HH:MM bis HH:MM einstellt (==>>ist nicht eingestellt)
C: oder für stand eine Leistungschwelle von xyxyx W eingibt (==>>ist nicht eingestellt)
D: per Fritzbox schaltet (==>>ist nicht passiert)
E: per Handyapp schaltet (==>>ist nicht passiert)
F: per FHEM mittels einem "fbahahttp"-Device schaltet ? ? ?
Eine Idee habe ich nach langem Kopfzerbrechen aber noch gehabt:
Der Heater wird mit einem relativ langsam Zyklus abgefragt. Der "INTERVAL = 300 s" ist so vom "fbahahttp"-Fritzbox-Device im Standart vorgegeben. Leider kann man dies nicht im "Heater"-Device einzeln anpassen.
Könnte sein das diese Abfragelänge da einwirken könnte wenn das als Änderung vom Heater"-Device einen Event auslöst.
Ich habe diesen Interval heute morgen mal auf 60 s (Minimalinterval bei Fritzbox-Device) verkürzt und wollte am Nachmittag mal sehen ob sich heute dann was verändert hat. Zusätzlich logge ich neben aktueller "power" und dem Zählerstand "energy" ab heute auch den Status "state" (On/Off) jetzt auch mal dort mit.
Hallo 330P,
vielleicht als Idee:
richte doch mal einen Dummy als neuen Consumer mit identischen Werten ein und schau ob das Schaltverhalten gleich ist - damit ließe sich ein 'Fremdenfluss' ausschließen' und einfach rausfinden ob der Fehler in der Logik liegt.
und
ggfls. wäre es besser die 2KW nicht direkt über den Zwischenstecker zu schalten - wenn ich bei mir den Heizstab Heizstab (3x1,5kW) anschaue wird der ziemlich häufig geschaltet. Ob der Fritz so robust ist?
Gruß Gerd
Zitat von: Max_Meyer am 06 Mai 2025, 20:54:18....
richte doch mal einen Dummy als neuen Consumer mit identischen Werten ein und schau ob das Schaltverhalten gleich ist - damit ließe sich ein 'Fremdenfluss' ausschließen' und einfach rausfinden ob der Fehler in der Logik liegt.
....
Hallo Gerd,
ja - habe ich schon auf einen parallel betriebenen TEST-KOPIE-RPI gemacht und solange die anderen Maschine ausgestellt - gleiche Ergebnisse zwischen 10:00 Uhr und 12:00 Uhr (heute Morgen gemacht) erhalten.
Zitat von: Max_Meyer am 06 Mai 2025, 20:54:18ggfls. wäre es besser die 2KW nicht direkt über den Zwischenstecker zu schalten - wenn ich bei mir den Heizstab Heizstab (3x1,5kW) anschaue wird der ziemlich häufig geschaltet. Ob der Fritz so robust ist?
Gruß Gerd
Da hatte ich vor der Auswahl des 546E mal hingeschaut.
Zum einen hab ich u.a. für die Waschmaschine schon einen seit fast 8 Jahren Jahren im Einsatz (mehr als 2 kWh) der mehr als 4 mal am Tag von FHEM geschaltet wird.
Zum anderen wird er in den technischen Daten mit Anschlusswerten von max. 2.300 Watt und max. 10A beschrieben.
==>> Beides wird beim Anschluss von diesem WW_Heater mit Steckeranschluss nicht überschritten.
Um das "zu häufige" kurzfristige Schalten zu vermeiden nutze ich eine "Reaktionsverzögerung ->> im Consumer "lockTime"
Dies werde ich aber sicherlich auch noch länger (900:900) (15 Minuten) stellen.
Aktuell bin ich erst bei der Einstellung "lockTime=300:300" von 5 Minuten (Sperrzeit jeweils nach EIN/AUS-Schaltung)
Gruß
300P
Edit:
Grad eben ist mir aber bei 100.sten Kontrolle vom "customer06" und dem "ctrlUserExitFn" noch was aufgefallen - mal morgen bis 12:00 Uhr sehen ob es das war. ??? ::) :-X
Wenns das war :'( :'( :'(
Zitat von: 300P am 06 Mai 2025, 22:31:33Um das "zu häufige" kurzfristige Schalten zu vermeiden nutze ich eine "Reaktionsverzögerung ->> im Consumer "lockTime"
Dies werde ich aber sicherlich auch noch länger (900:900) (15 Minuten) stellen.
Aktuell bin ich erst bei der Einstellung "lockTime=300:300" von 5 Minuten (Sperrzeit jeweils nach EIN/AUS-Schaltung)
Hallo 300P,
Ja, das Nachlaufen wollte ich vermeiden beim Heizstab - der sollte bei mir - aufgrund seiner Leistung - ausschließlich mit PV laufen - bei einer Laufzeit über die PV-Deckung hinaus holt er sich die Energie ja entweder aus der Batterie oder dem Netz und das muss nicht sein dachte ich.
Gruß Gerd
Hallo zusammen,
in meinem contrib liegt eine Vorabversion des Major Release 1.52.0 zum Test wer mag.
Was ist alles enthalten:
- das Setup der Wechselrichter (setupInverterDevXX) kann nun verschiedene Architekturen spezifizieren um eine bessere Unterstützung für
Balkonkraftwerke oder andere Anlagen mit reinen Batterie-Wechselrichtern zu ermöglichen
- Es kann der Typ Batterie-Wechselrichter zur reinen DC->AC / AC->DC definiert werden, die Flußgrafik gibt diese IN / OUT Flüsse auch wieder
- die Attribute setupInverterDevXX enthalten dafür neue Schlüssel dc2ac, ac2dc
- die obsolet gewordenen Attribute sind entfernt: graphicLayoutType, graphicHourStyle, graphicHeaderDetail, graphicSpaceSize, graphicBeamWidth,
graphicHourCount, graphicEnergyUnit, graphicHeaderShow
- Im Wiki habe ich begleitend dazu einen Abschnitt zum Setup der Wechselrichter (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Einrichtung_der_Wechselrichter_mit_setupInverterDevXX) erstellt
Nach einem Download FHEM restarten!!
Mit diesen Möglichkeiten sollten sich noch mehr Anlagen besser integrieren lassen. Das betrifft auch meine eigene
Victron Anlage. Die MultiPlus II sind AC-DC/DC-AC Wechselrichter zwischen Batterie und Hausnetz ohne eigene Solarzellen.
Die sind an einem SMA-WR (DC-AC) bzw. Victron SmartLoader (DC-DC) angeschlossen.
Grüße,
Heiko
Ich habe eine Frage zur Batteriekapazitätsanzeige:
Die Readings
Current_BatCharge_01 60 %
Current_BatCharge_02 50 %
sind vorhanden, aber in der Graphik wird keine Batteriekapazität angezeigt.
Korrektur von cap war notwenig. Die Einheit musste ich entfernen, weil es kein Reading zur Batteriekap gibt.
cap=48:kWh ändern nach cap=48 dann wird auch der Prozentwert der Batterien angezeigt.
attr AB_WS_SS setupBatteryDev01 Deye_12k pin=Akku_Leistung_BMS1__kW:kW pout=-pin intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh cap=24:kWh charge=Akku_SOC__KAP show=2:bottom icon=measure_battery_50@#262626:@yellow:measure_battery_100@red
attr AB_WS_SS setupBatteryDev02 Deye_15k pin=Akku_Leistung_BMS1__kW:kW pout=-pin intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh cap=48:kWh charge=Akku_SOC__KAP show=2:bottom icon=measure_battery_50@#262626:@yellow:measure_battery_100@red
Wie kann ich die Kapazität der beiden Batterieinheiten zur Anzeige bringen?
Ein weiterer Punkt sind die großen Werte der Leistungsanzeigen. Bei der Übernahme der Werte aus den Invertern werden 3 Stellen ergänzt. Wie bekomme ich die zur vielen Stellen wieder weg?
Wenn mehrere Batterieinheiten vorhanden sind, wird hier nur der Mittelwert der Batterien-Kapazität angezeigt.
Bei den Invertern wird jeder Inverter separat angezeigt. Bei den beiden Batterien wird nur eine einzige Batterie angezeigt. Da wäre es nicht schlecht auch jede Batterie separat anzuzeigen.
@all,
ich habe die Vorabversion 1.52.0 in meinem contrib upgedated.
@Chris,
ZitatWenn mehrere Batterieinheiten vorhanden sind, wird hier nur der Mittelwert der Batterien-Kapazität angezeigt.
Bei den Invertern wird jeder Inverter separat angezeigt. Bei den beiden Batterien wird nur eine einzige Batterie angezeigt. Da wäre es nicht schlecht auch jede Batterie separat anzuzeigen.
Das ist bereits geplant, aber andere Dinge haben aktuell eine höhre Prio bei mir.
Kommt Zeit ... ;)
LG,
Heiko
Zitat von: 300P am 06 Mai 2025, 22:31:33Grad eben ist mir aber bei 100.sten Kontrolle vom "customer06" und dem "ctrlUserExitFn" noch was aufgefallen - mal morgen bis 12:00 Uhr sehen ob es das war. ??? ::) :-X
Wenns das war :'( :'( :'(
Nun ja - es nicht das was mir da gestern noch aufgefallen war. O:-)
Eins kann ich jetzt wie folgt festhalten:
- SF schaltet (richtig - wegen surplus zu klein) aus:
Logbuch :
2025.05.07 14:12:31 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.07 14:12:31 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
DBLog Eintrag:
2025-05-07 14:12:31 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT state: off state off NULL
- Kurz (Sekunden) danach später schaltet der FBDECT_fbahahttp_E8_DF_70_07_42_0B (eigenständig ?!?) wieder ein:
Logbuch:
2025.05.07 14:12:33 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
DBLog Eintrag:
2025-05-07 14:12:33 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT state: on state on NULL
- Zum nächsten SF Intervall (ca. 15 Sekunden) später schaltet der FBDECT_fbahahttp_E8_DF_70_07_42_0B (eigenständig ?!?) wieder aus:
Logbuch:
2025.05.07 14:12:49 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
DBLog Eintrag:
2025-05-07 14:12:49 FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT state: off state off NULL
Ob dies mit meiner Konstellation Fritz546E und EHK-Heater zusammenhängt wird ist mir weiterhin nicht ersichtlich.
Aber wenn es passiert dann passt es in meinen SF-Intervall von 15 Sekunden.
Als letztes werde ich mir mal den FBDECT_fbahahttp_E8_DF_70_07_42_0B mit verbose 5 ansehen.
Wenn da auch nichts mehr auffällig wird - dann ist es eben ein
FHEM-"Glitsch" :o
Kriegsentscheident ist dies aber nicht - aber das "warum wurmt mich".
Gruß
300P
Nimm doch temporär zum Test deinen Code aus der ctrlUserExitFn raus. Nicht dass sich dort noch ein Fehler verbirgt der das Schaltverhalten verursacht.
Kannst den Code gern nochmal komplett posten.
@ 300P
Ich nutze in zwei FHEM Installationen unter anderem Shelly Relais zum Schalten. Bei einem auch zum Schalten von jeweils individuell aller 3 Phasen von 2 Heizstäben. Läuft jetzt super mit PV Überschussverbrauch mittels SF Steuerung, nach meinen Optimierungen und der Hilfe hier aus dem Thread.
Falls es Dir möglich ist und WLAN Coverage an Deinem "Heizstab-Tatort" vorhanden ist, setze doch einfach mal z.B. die Shelly Steckdose, die 16A schalten kann, zum Testen für Deinen Heizstab ein.
Nur so eine Idee...
Gruß Peter
Ja - gute Idee mit einem Wechsel des Schalters.
Hab heute aus China 2 neue Schalter 20A erhalten - wechsele die Tage mal aus....das Zuheizen funktioniert ja ansonsten super mit SF ->> Dank nochmals an Heiko !!!! :)
Muss mich jetzt aber erst mal zum versprochenen Jahres Firmware-Update einer Victron mit Batterie und deren BMS ebenfalls notwendigen Update beim Schwager einfinden. ;)
Zitat von: DS_Starter am 07 Mai 2025, 15:50:19Nimm doch temporär zum Test deinen Code aus der ctrlUserExitFn raus. Nicht dass sich dort noch ein Fehler verbirgt der das Schaltverhalten verursacht.
Kannst den Code gern nochmal komplett posten.
Bitteschön: O:-)
{
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
my $timestart = 1; # ab welcher Uhrzeit soll es sein
my $timeend = 8; # bis wieviel Uhr soll es sein
if (int $hour >= $timestart && int $hour < $timeend ) {
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
my $minsocbat = 30; # nur bis mindesten XY SoC aller Batterien
my $heater = (split " ", AttrVal ($name, 'consumer06', ''))[0]; # Heater-Name von ConsumerXX
my $soctotal = CurrentVal ($name, 'batsoctotal', 0); # SoC über alle Bat als Durchschnitt
my $pvtot = ReadingsNum ($name, 'RestOfDayPVforecast', 0); # Restliche PV Prognose total heute in Wh
# war my $pvtot = ReadingsNum ($name, 'Today_PVforecast', 0); # PV Prognose total heute in Wh
my $caps = CurrentVal ($name, 'batcapsum', 0); # Summe installierte Bat Wh
my $need = $caps - ($soctotal/100 * $caps); # benötigte Ladeenergie Bat bis 100% Ladung
Log3 ($name, 5, qq{$name - userFn -> WWHeater Reading ist = $heater - aktuelle Stunde = $hour aus $dt erzeugt });
Log3 ($name, 5, qq{$name - userFn -> StartZeit von = $timestart bis EndeZeit = $timeend und mindestens ein SoC von $minsocbat % muss in den vorhandenen Batterien gegeben sein });
Log3 ($name, 5, qq{$name - userFn -> Der PV-Tages-Restertrag betraegt $pvtot Wh ???mehr??? als die offene und noch zu ladende Batteriekapazitaet von $need Wh});
if ($soctotal >= ($minsocbat - 2) && $pvtot > $need) {
# Zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr und % SoC-Vorgabe erfüllt und der PV-Tages-Rest-Ertrag > 100% Batteriekapazitaet
# send "on"-Kommando an Heater Device if(ne "on");
if (ReadingsVal($heater,"state","") ne "on") {
fhem ("set $heater on");
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --on--});
}
}
else {
if (($soctotal < $minsocbat) || ($pvtot <= $need)) {
# Wenn die (SoC-Vorgabe unterschritten !!!!! oder !!!! derTages-Rest-Ertrag < 100% Batteriekapazitaet)
# danach sollte der Heater-ConsumerXY wieder nach "seinen" Regeln steuern...
# send "off"-Kommando an Heater Device if(ne "off");
if (ReadingsVal($heater,"state","") ne "off") {
fhem ("set $heater off");
Log3 ($name, 2, qq{$name - userFn -> $name Consumer $heater in $name set to --off--});
}
}
}
}
}
Kann ich die Darstellung umgestalten um die Energieerfassungen richtig zusammenzufassen.
Die Batterien sind bei mir nicht direkt im Netz, sondern hängen direkt an den Deye Invertern.
Anbei eine grobe Übersicht der Energieverteilung mit den Energiezählern.
Hallo Chris,
Umgestalten im Sinne die Icons frei zu arrangieren, ist nicht möglich.
Es ist ein Prinzip-Flußbild.
Aber wie der Zufall es will, bin ich gerade dabei (die V 1.52.0 liegt im contrib zum Test) die Architekturmöglichkeiten aufzuwerten. Momentan kann man mit dieser V auch Batterie-Wechselrichter ohne angeschlossene Solarzellen integrieren, wie auf dem Screen zu sehen. Die Laufketten bewegen sich entsprechend der Wandlungsrichtung. Die Verbindung Batterie-Netz ist dann ausgegraut.
Wenn ich es richtig interpretiere, ist dein Wechselrichter ein Batteriewechselrichter mit angeschlossenen Solarzellen, der nach Bedarf ins Netz einspeist oder alternativ die Batterie lädt bzw. die Batterie-Energie in das Hausnetz DC->AC wandelt?
@300P,
du hast ja Log Ausgaben in deinem Code. D.h. man müsste entsprechende Einträge finde sofern du mind. verbose 2 im Device eingestellt hast. Ist das so? Da du nichts davon geschrieben hast, gibt es wohl keine Logeinträge und demzufolge auch keine Schaltvorgänge über diesen Code? ... Was kann bestätigen würde, dass dein "Problem" nicht von deinem Code herrührt.
@DS_Starter
Ich verwende 2x Deye Hybridinverter der Modelreihe SUN-(6-20)K-SG01HP3-EU und ist eine komplexe Einheit die an FHEM per RS485 angeschlossen ist.
Anschlüsse eines Hybridinverters: 3x PV-Strings, 1x Grid-Anschluss, 1x Last-Anschluss, 1x Batterie-Anschluss.
Die Geräte sind notstromfähig. Zusätzlich ist ein ABB-Transfairschalter für die Notstromumschaltung vorgelagert.
Gesamt PV-Leistung 22kWp, Gesamt Deye-Batteriespeicher 72kWh, Notstromgenerator 6,5kW hängt an PV-Anlage 1, 2kW Wingenerator hängt an PV-Anlage 2.
Das gesamte würde ich gern unter das SolarForecast Modul einbinden. Das wird aber nicht sehr einfach.
Der Hybridinverter fehlt im Prinzip noch bei den Wechselrichtertypen.
Ich würde versuche, diesen Typ mit in die 1.52.0 einzubauen.
Übersetzt in die SF-Möglichkeiten wäre es:
- 3x PV-Strings: haben wir mit dem Schlüssel strings im Inverterattribut
- Last-Anschluss, also der Anschluß an das Hausnetz?: haben wir mit dem Schlüssel pv im Inverterattribut
- Batterie-Anschluss: muß ich bei einem solchen WR noch integrieren
Frage Grid-Anschluss, ist das Anschluß der NUR ins öffentliche Netz einspeist oder wie ist das zum Verhältnis zum Lastanschluß zu verstehen?
EDIT: Ich glaube kann es mir selbst beantworten. Am Grid ist der Zugang vom Hauszähler, am Lastanschluß alle Verbraucher. Die Energie wird durchgeschleift und im Notstrombetrieb unterbrochen + Batteriespeisung, richtig?
Notstromgenerator + Wingenerator können wir mit den Producerattributen.
Zitat von: DS_Starter am 07 Mai 2025, 19:38:20@300P,
du hast ja Log Ausgaben in deinem Code. D.h. man müsste entsprechende Einträge finde sofern du mind. verbose 2 im Device eingestellt hast. Ist das so? Da du nichts davon geschrieben hast, gibt es wohl keine Logeinträge und demzufolge auch keine Schaltvorgänge über diesen Code? ... Was kann bestätigen würde, dass dein "Problem" nicht von deinem Code herrührt.
Frisch zurück vom BMS- und 2 anstehenden Victron Firmware-Update nebst notwendiger erneuter Konfiguration des MPII.... O:-)
Ja - in der Nacht von 01:00 Uhr bis 08:00 Uhr kommen die angesprochenen Logeinträge (SF hat verbose 2) natürlich immer rein wenn on/off geschaltet wird.
Aber tagsüber kommt kein einziger Eintrag -
niemals nicht in den letzten Tagen :-[ .
Das war auch der Grund das ich davon ausging => es kommt evtl. irgendwie vom Schalten des SF-Consumer06.🤔
Gruß
300P
ZitatDas war auch der Grund das ich davon ausging => es kommt evtl. irgendwie vom Schalten des SF-Consumer06.
Das hätte man im Debug gesehen. Außerdem würden bei Schaltvorgängen mit dem Consumer-Modul kein "switched by extern" erscheinen da diese Vorgäge getrackt werden.
Das stimmt wiederum genauso!
Zitat von: DS_Starter am 07 Mai 2025, 20:02:43- Last-Anschluss, also der Anschluß an das Hausnetz?: haben wir mit dem Schlüssel pv im Inverterattribut
- Batterie-Anschluss: muß ich bei einem solchen WR noch integrieren
Hallo Heiko,
dann müsste aber ein zusätzliche Batteriesymbol auftauchen - um Anlagen mit mehreren Batterien abzubilden von denen nur eine an einem Hybridwechselrichter hängt. Oder?
Gruß Gerd
Hallo Gerd,
Zitatdann müsste aber ein zusätzliche Batteriesymbol auftauchen - um Anlagen mit mehreren Batterien abzubilden von denen nur eine an einem Hybridwechselrichter hängt. Oder?
Naja, ich verwende im Flußbild keine separaten Batterien, sondern einen "Batterieknoten", also eine Sammelstelle für alle vorhandenen Batterien, vergleichbar mit dem vorhandenen Inverterknoten. Von diesem "Knoten" aus würden sich dann Verbindungen zu den relevanten Hybridwechselrichtern ergeben.
Dadurch können die Flüsse von und zu Hybrid <-> Batterie dargestellt werden.
Es ist also etwas abstrakter als die physikalische Realität, zeichnet aber dennoch die realen Flüsse nach.
Zitat von: DS_Starter am 07 Mai 2025, 22:17:12Dadurch können die Flüsse von und zu Hybrid <-> Batterie dargestellt werden.
Es ist also etwas abstrakter als die physikalische Realität, zeichnet aber dennoch die realen Flüsse nach.
Hallo Heiko,
aus meiner Sicht passt das heute schon ziemlich gut - hab dazu mal 2 Screen reingehangen - einen von heute Nachmittag - die das (Über-)Laden abbildet und eine von heute Abend wo Entladen zu sehen ist.
Gruß Gerd
Du hast aber eine recht komplexe Anlage. Reicht dir überhaupt die verfügbare Anzahl Wechselrichter? ;)
Weitere hinzuzufügen wäre kein Problem.
Die V 1.52.0 wird dir dann vermutlich noch mehr Möglichkeiten geben wenn sie mal fertig ist.
LG,
Heiko
Zitat von: DS_Starter am 07 Mai 2025, 22:39:35Du hast aber eine recht komplexe Anlage. Reicht dir überhaupt die verfügbare Anzahl Wechselrichter?
Hallo Heiko,
zuerst einmal nochmal Danke! für das Modul! Es hilft sehr!
die Wechselrichter (12) und auch die Verbraucher (75) habe ich zu Clustern (4+2/16) zusammengelegt - das deckt den Energiefluss eigentlich ganz gut ab. Mittlerweile stimmen auch die Prognosen besser - vermutlich durch die Abstrahierung bedingt hat das ein wenig gedauert. Ich befürchte, dass ich diese, inzwischen gewonnene, Genauigkeit wieder einbüße wenn ich die WR weiter vereinzelne. Was gut wäre, wenn ich auch die beiden letzten (kleinsten) Cluster, die zur Zeit als Producer abgebildet sind, als Inverter einbinden könnte. Aber das ist nicht besonders wichtig - funktioniert auch so.
Im Zusammenhang mit den Daten zur Genauigkeit der Prognose verwendet werden hätte ich noch eine Frage: 'würde es Sinn machen der AI auch noch andere Istdaten, die Einfluss auf Erzeugung und Verbrauch haben z.B. gemessene Temperaturen, Wind, Abwesenheiten etc. zugänglich zu machen?'
Gruß Gerd
Das ist ja nochmal komplexer als es schon so aussieht. Respekt!
ZitatIm Zusammenhang mit den Daten zur Genauigkeit der Prognose verwendet werden hätte ich noch eine Frage: 'würde es Sinn machen der AI auch noch andere Istdaten, die Einfluss auf Erzeugung und Verbrauch haben z.B. gemessene Temperaturen, Wind, Abwesenheiten etc. zugänglich zu machen?'
Die Temperatur bekommt die KI schon, allerdings die vom Wetterdienst gelieferte Temperatur. Wenn man es genau nimmt, müßte es die Solarzellentemperatur sein denn sie bestimmt die Verluste bzw. ggf. Erhöhung der Peakleistung. Aber wer kann das schon liefern. Außerdem müsste man dann auch eine Prognose dieser Temperatur haben, noch unwahrscheinlicher sie zu bekommen.
Bei Wind und Abesenheiten wüsste ich nicht wie diese Paramter Einfluß auf den Solarertrag haben könnten.
Mir schwebt eher der Ersatz der aktuell verwendeten KI Bibliothek durch ein eigenes und anpassbares neuronales Netzwerk vor um diesbezüglich Fortschritte zu machen. Das will ich zunächst für den Hausverbrauch aufsetzen und wenn das erfolgreich ist, auch auf andere Prognosen adaptieren.
Mal sehen wie ich voran komme.
Achso ... heißt das du könntest 6 statt 4 mögliche Inverter gebrauchen?
Grüße,
Heiko
Zitat von: DS_Starter am 07 Mai 2025, 23:27:21Achso ... heißt das du könntest 6 statt 4 mögliche Inverter gebrauchen?
Guten Morgen Heiko,
ja das wäre schön - aber nicht unbedingt notwendig
Zitat von: DS_Starter am 07 Mai 2025, 23:27:21Bei Wind und Abesenheiten wüsste ich nicht wie diese Paramter Einfluß auf den Solarertrag haben könnten.
Auf die PV-Prognose nicht aber auf den Verbrauch - Urlaub (Sommer und Winter) und schlechtes Wetter (Wind Regen im Winter) führen zu geänderten Verbräuchen.
Zitat von: DS_Starter am 07 Mai 2025, 23:27:21Die Temperatur bekommt die KI schon, allerdings die vom Wetterdienst gelieferte Temperatur
die vom Wetterdienst kommenden Daten hatte ich als Prognose angesehen - das trifft ja vor Ort nicht unbedingt genau zu - außerdem hat das auch Einfluss auf den Verbrauch.
Der Kommentar soll nur meine der Frage zugrundeliegenden Gedanken erklären - ich glaube auch, eine signifikante Prognoseverbesserung ist damit nicht zu erreichen. Es war nur eine Idee.
Zitat von: DS_Starter am 07 Mai 2025, 23:27:21Das ist ja nochmal komplexer
Ist ist über die letzten anderthalb Jahrzehnte gewachsen und fühlt sich nicht so komplex an - die abgebildete Granularität ist aber sicher Hobby ;D - so lässt sich schön die Energieeinsparung auf ca. 1/6 des ursprünglichen Bedarfs nachverfolgen - Hobby eben
Gruß Gerd
Zitat von: DS_Starter am 07 Mai 2025, 20:02:43- 3x PV-Strings: haben wir mit dem Schlüssel strings im Inverterattribut
- Last-Anschluss, also der Anschluß an das Hausnetz?: haben wir mit dem Schlüssel pv im Inverterattribut
- Batterie-Anschluss: muß ich bei einem solchen WR noch integrieren
Ich hoffe mit meinem Blockschaltbild es die Verteilung besser zu verstehen.
PVA1 hält die USV-Versorgung ohne Strom-Unterbrechung aufrecht, wenn das EVU-Netz(Grid) wegfällt. FÜr die USV-Versorgung aller Lasten im Haus hat der Hybridinverter 2 Trinax PV-Strings, eine Batterieeinheit und einen Windgenerator zur Verfügung.
PVA2 hält die USV-Versorgung für den Aussenbereich, die Wärmepumpe und die Haustechnikspannungsversorgung in allen Bereichen aufrecht, wenn das EVU-Netz(Grid) wegfällt. FÜr die USV- und SV-Versorgung aller Lasten im gesamten Objekt hat der Hybridinverter 3 Trinax PV-Strings, eine Batterieeinheit und einen Notstomgenerator zur Verfügung.
Die Anlage ist grundsätzlich so ausgelegt, das nichts in EVU-Netz eingespeist wird.
Alle im Blockschaltbild angeführten Anlagenteile werden mit Drehstrom-Energiezähler erfasst, bis auf die Geschirspüler, Waschmaschinen und Trockner. Diese Geräte werden mit einem 1-Phasen Energiezähler erfasst.
Im Aussenbereich (AB-UV) wird zudem der Poolbereich erfasst, und ja nach vorhandener Solar- und PV-Energie der Poolbereich freigegeben.
Ich denke das es so mit dem Blockschaltbild besser verständlich ist.
Ergänzend noch die Deye Energieerfassung. Je nach dem aktuellen Zustand gibt es die Inverter Leistung bzw. Akku Leistung mit positivem und negativen Werten.
Hier fehlt noch die Energierfassung für den Notstromgenarator bzw. Windgenerator mit den Leistungswerten.
Zur Temperaturerfassung:Ich erfasse die Lokale Lufttemperatur in meiner Wetterstation, und habe mir zusetzlich ein kleine Solarzelle inklusive 1-Wire Temperatursensor gebaut.
Der maximale Spannungsausgang der Solarzelle sind 4,7VDC (Messbereich 0-5VDC). Die Solarzelle ist waagerecht auf der Dachspitze montiert und daraus ermittle ich die Einstrahlungsenergie W/m² und es gibt keine Schatten auf der Solarzelle. Derzeit noch ohne Temperaturkompensation aber mit Temperaturerfassung.
Natürlich passt das nicht ganz zu den montierten PV-Modulen, denn diese sind unterschiedlich in der Lage und Ausrichtung.
setupStringAzimuth SüdOstdach=-28 SüdWestdach1=39 SüdWestdach2=39 SüdWestwand=52
setupStringDeclination SüdOstdach=48 SüdWestdach1=15 SüdWestdach2=15 SüdWestwand=90
setupStringPeak SüdOstdach=4.35 SüdWestdach1=6.6 SüdWestdach2=6.6 SüdWestwand=4.35Nur so informativ zu Überlegungen.
Ein Danke noch für dieses sehr komplexe Thema und die Modulentwicklung. :)
Vielen Dank allerseits für den informativen und wertvollen Input. Ich will versuchen in der V 1.52.0 auch Hybridwechselrichter noch mit zu integrieren. Momentan haben wir ab dieser V folgende Typen zur Verfügung:
PV-Wechselrichter Der Standard Wechselrichter. Er wandelt die Energie der angeschlossenen Solarzellen in Wechselstrom um.
Dieses Gerät liefert die Energie in das Hausnetz. Alternativ kann mit feed=grid die Funktion des
Wechselrichters in exklusive Einspeisung in das öffentliche Netz geändert werden.
Solar-Ladegerät Ein Solar-Ladegerät wandelt die Energie der angeschlossenen Solarzellen nicht in Wechselstrom um, sondern
arbeitet als DC-DC Wandler und lädt direkt eine Batterie bzw. versorgt einen Batteriewechselrichter.
Die Funktion als Solar-Ladegerät wird mit feed=bat aktiviert (z.B. ein Victron SmartSolar MPPT).
Batterie-Wechselrichter Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer
Batterie und dem Hausnetz.
Die Funktion als Batterie-Wechselrichter wird mit strings=none aktiviert.
@Chris, da du eine Nulleinspeisung hast, gibt es im Sommer sicherlich häufiger die Situation, dass die Anlage abregelt wenn die Batterien voll sind und nicht genügend Verbrauch vorhanden ist. Wie gehst du damit um oder kommt es nicht so häufig vor?
Zitat von: DS_Starter am 08 Mai 2025, 19:37:36@Chris, da du eine Nulleinspeisung hast, gibt es im Sommer sicherlich häufiger die Situation, dass die Anlage abregelt wenn die Batterien voll sind und nicht genügend Verbrauch vorhanden ist. Wie gehst du damit um oder kommt es nicht so häufig vor?
Die Hybridinverter sind so eingestellt das es keine Netzeinspeisung gibt.
Diese Geräte sind sehr flexibel wie man mit der Überschußenergie umgeht. Ich bin noch in der Ferigstellungsphase da ich noch ein Dach für die PV-Module sanieren muss, darum bin ich noch nicht in die Verlegenheit gekommen. Jedenfalls können diese Hybridinverter einen Inselbetrieb genauso wie einen vollen Gridbetrieb, oder nur einen Grid Ergänzungsbetrieb ohne manuelle Eingriffe realisieren. Ist nur eine Einstellungssache an den Hybridinvertern.
Da mein Nachbar ebenfalls eine PV-Anlage errichten möchte, hatten wir schon überlegt die Energie gegenseitig auszutauschen und einen Pseudo-Inselbetrieb zu realisieren. Grundsätzlich kann mit geringem Aufwand ein Erdkabel verlegt werden um die beiden Objekte zu verbinden, und das EVU bekommt seine Zähler zurück.
Man bekommt ohnehin nichts für die Energie, und mit den neuen idiotischen Ideen wollen die EVUs die privaten PV-Anlagenbesitzer nun damit nötigen die Hauseigenen PV-Anlagen und Batterien je nach Netzlast ein- und ausschalten, und dabei die Besitzer zusätzlich zwingen den Strom zu kaufen auch wenn man selbst genügend Energie zur Eigenversorgung zur Verfügung hat. Da dann kan man sich vorstellen was geschieht wenn man auch ein E-Fahrzeug hat, und damit in die Arbeit fahren will, aber das EVU alles weggeschaltet hat und man selbst nicht eingreifen kann.
Ja, das wird noch spannend ...
Ich habe ein Problem mit dem Attribut graphicHeaderOwnspec
Normalerweise sollte <br> einen Zeilenumbruch an dieser Position veranlassen wo es gesetzt ist, nur es geschieht nicht sondern verschieb alles.
Ich muss alles mit den : anpassen damit die Darstellung passt.
#
AutarkyRate:Current_AutarkyRate
Überschuß:Current_Surplus
aktueller Netzbezug:Current_GridConsumption
:
:
#Inverter 1
Status:Betriebsstatus@Deye_12k
:
:
:
#Batterieeinheit 1
Energieladung heute:Akku_Energie_Ladung_Heute__kWh@Deye_12k
Energieentladung heute:Akku_Energie_Entladung_Heute__kWh@Deye_12k
:
:
#Inverter 2
Status:Betriebsstatus@Deye_15k
:
:
:
#Batterieeinheit 2
Energieladung heute:Akku_Energie_Ladung_Heute__kWh@Deye_15k
Energieentladung heute:Akku_Energie_Entladung_Heute__kWh@Deye_15k
:
:
#Settings
Autokorrektur:pvCorrectionFactor_Auto : : :
Consumer<br>Neuplanung:consumerNewPlanning : : :
Consumer<br>Sofortstart:consumerImmediatePlanning : : :
Wetter:graphicShowWeather : : :
History:graphicHistoryHour : : :
ShowNight:graphicShowNight : : :
Debug:ctrlDebug : : :
Mit definierten Zeilenumbrüchen sollte es eignetlich genaus aussehen.
#
AutarkyRate:Current_AutarkyRate
Überschuß:Current_Surplus
aktueller Netzbezug:Current_GridConsumption
<br>
#Inverter 1
Status:Betriebsstatus@Deye_12k
<br>
#Batterieeinheit 1
Energieladung heute:Akku_Energie_Ladung_Heute__kWh@Deye_12k
Energieentladung heute:Akku_Energie_Entladung_Heute__kWh@Deye_12k
<br>
#Inverter 2
Status:Betriebsstatus@Deye_15k
<br>
#Batterieeinheit 2
Energieladung heute:Akku_Energie_Ladung_Heute__kWh@Deye_15k
Energieentladung heute:Akku_Energie_Entladung_Heute__kWh@Deye_15k
<br>
#Settings
Autokorrektur:pvCorrectionFactor_Auto : : :
Consumer<br>Neuplanung:consumerNewPlanning : : :
Consumer<br>Sofortstart:consumerImmediatePlanning : : :
Wetter:graphicShowWeather : : :
History:graphicHistoryHour : : :
ShowNight:graphicShowNight : : :
Debug:ctrlDebug : : :
Hab ich da jetzt einen Denkfehler?
ZitatNormalerweise sollte <br> einen Zeilenumbruch an dieser Position veranlassen wo es gesetzt ist, nur es geschieht nicht sondern verschieb alles.
Dieser Bereich hat eine Tabellenstruktur mit einer definierten Syntax --->
ZitatEin leeres Feld in einer Zeile wird durch ":" erzeugt.
Deswegen habe ich die zu verwende Syntax im Attribut/Wiki beschrieben.
Der Zeilenumbruch bezieht sich auf die Verwendung in den Labeln:
ZitatLeerzeichen im Label sind durch " " einzufügen, ein Zeilenumbruch durch "<br>".
Vielleicht wird es für den Leser nicht genügend deutlich, dass sich der Zeilenumbruch auch auf "im Label" bezieht? Wenn es so ist, muß ich es noch deutlicher hervorheben.
LG,
Heiko
Das war dann ein Missverständnis meinerseite.
Ich muss sagen das ist schon ein ganz mächtiges Modul.
Hier stecken bestimmt mehrere tausend Stunden Arbeit drin innerhalb der letzten 5 Jahre Aufbau des Moduls. Habe die Zeit nicht gezählt.
Dafür kann man nur Dankbar sein. Und der Erfolg gibt dir recht:
WhatsApp Bild 2025-05-10 um 09.39.10_9ab0998d.jpg
(screenshot von gestern)
Kleiner Hinweis zum Wiki bzw. dem DbRep-Device zum Löschen der AllPVForeCast Readings des Folgetages:
Ich würde dem DbRep noch ein
attr Rep.Del.AllPVforecastsToEvent device TYPE=SolarForecast
spendieren. Für Leute die auch andere Prognosen in der Db haben (wie ich zum Beispiel Tibber-Preise), ist das sicherlich hilfreich. ;)
LG und Danke!
Zitat von: tobi01001 am 10 Mai 2025, 09:45:40Dafür kann man nur Dankbar sein. Und der Erfolg gibt dir recht:
WhatsApp Bild 2025-05-10 um 09.39.10_9ab0998d.jpg
(screenshot von gestern)
Zu den Abweichungen hätte ich jetzt auch eine Frage. Bei mir sind die aktuell immer so um die 20 - 30%. Ok, dachte ich mir, das muss sich erstmal eingrooven, weil die KI ja erstmal trainiert werden muss. Wie lange dauert die Trainingszeit denn so bis man mit präziseren Werten rechnen kann?
Des weiteren ist mir in dem Zusammenhang noch was anderes aufgefallen. Aus dem Screenshot kann man sehen, dass morgens erst mal mein Speicher geladen wird. So lange bis der auf 100% steht passen die Werte der realen PV Erzeugung nicht. Obwohl hier aktuell die Sonne vom strahlend blauen Himmel scheint und ich heute schon 8,8 kWh erzeugt habe wird die reale PV Erzeugung für 8h mit 492 Wh und für 9h mit 904 Wh angezeigt, obwohl die Progrnose (und die scheint ja hier zu stimmen) deutlich mehr anzeigt und ich auch deutlich mehr erzeugt habe. Erst ab 10h, als der Speicher voll war, stimmt scheint auch der Wert der realen PV Erzeugung wieder zu stimmen.
Welche Attributswerte müsste ich euch den zeigen, um zu prüfen, ob ich hier irgend eine Fehleinstellung vorgenommen habe?
Na dann zeigt deine bessere Hälfte 👰�♂️🤵, zeig dein Haus 🏡 und zeig dein Boot 🛥� ....😉🤣😂
Besser wäre natürlich es wenn wir dazu einige Attribute wie z.B. (siehe Screenshot) kennen würden 🤔❓
Zitat von: 300P am 10 Mai 2025, 13:48:41Besser wäre natürlich es wenn wir dazu einige Attribute wie z.B. (siehe Screenshot) kennen würden 🤔❓
Deshalb hab ich ja gefragt welche es denn sein dürfen. ::)
Hier sind die gewünschten Setup Attribute:
setupBatteryDev01 PV_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W cap=10240 intotal=Summe_Ladung:Wh outtotal=Summe_Entladung:Wh charge=BatteryChargePercent show=2
setupInverterDev01 Fronius_Symo_Gen24 pv=PowerFlow_Site_P_PV:W etotal=PowerFlow_Site_E_Total:Wh capacity=6000 strings=Dach_Ost,Dach_West
setupInverterDev02 BKW_600 pv=power:W etotal=energy_total:Wh capacity=600 strings=BKW_Ost
setupInverterDev03 BKW_800 pv=power:W etotal=energy_total:Wh capacity=800 strings=BKW_West
setupInverterStrings Dach_Ost,Dach_West,BKW_Ost,BKW_West
setupMeterDev Hausstromzaehler gcon=power:W contotal=overall_consumption:Wh gfeedin=-gcon:W feedtotal=overall_feed:Wh
setupRadiationAPI OpenMeteoDWDEnsemble-API
setupStringAzimuth Dach_Ost=E Dach_West=W BKW_Ost=E BKW_West=W
setupStringDeclination Dach_Ost=40 Dach_West=40 BKW_Ost=15 BKW_West=90
setupStringPeak Dach_Ost=3.22 Dach_West=3.22 BKW_Ost=0.72 BKW_West=0.92
setupWeatherDev1 OpenMeteoDWDEnsemble-API
ups... sorry hatte ich beim warten an der Waschanlage auf dem Handy überlesen.... O:-)
Geb für die Batterie schon mal die Werte für die max. Ladung / Einladung (deiner Batterie) mit an und lass die Batterie etwas "bunter" werden.
dadurch könnte das Verhalten der Batterie evtl. schon besser werden.:
Und lass die Batterie etwas "bunter" werden mit dem icon-Eintrag ;)
setupBatteryDev01 PV_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W pinmax=25000000 poutmax=25000000 cap=10240 intotal=Summe_Ladung:Wh outtotal=Summe_Entladung:Wh charge=BatteryChargePercent show=2 icon=@yellow:@green:@red:@white
Zitat von: Max_Meyer am 07 Mai 2025, 23:13:11'würde es Sinn machen der AI auch noch andere Istdaten, die Einfluss auf Erzeugung und Verbrauch haben z.B. gemessene Temperaturen, Wind, Abwesenheiten etc. zugänglich zu machen?'
Leute, erstens sind wir in Deutschland und sprechen von KI, nicht AI. Ich habe gerade eine Konferenz mit rund 1.000 Teilnehmern und 13.000 Messebesuchern hinter mir - der Begriff "KI" ist wirklich fest verankert.
Zweitens muss man berücksichtigen, _welches_ Modell dahinter steckt. Soweit ich das sehe, ist das ein Random Forest Regressor. Und da kann als wesentlicher Nachteil ein Overfitting auftreten. Die Gefahr des Overfitting steigt an, wenn mehr Parameter eingeführt werden - dann hilft eigentlich nur noch eine Reduktion der Dimensionalität. Mit anderen Worten: Nichts Genaues weiß man nicht, aber die Wahrscheinlichkeit ist hoch, dass die Prognosen dann wesentlich schlechter werden.
LG
pah
Ich habe eine Frage zum graphicHeaderOwnspec.
Ich berechne für einen Dummy einen Wert den ich als Reading state ausgebe.
Nun wird aber anstatte des state Wertes ein Feld Format:textField-long generiert.
#CO2 Einsparung
aktuelles Jahr:state@CO2JD
letztes Jahr:state@CO2JLD
Lässt sich das irgendwie abändern?
Zitat von: Wolle02 am 10 Mai 2025, 15:10:11.....
Hier sind die gewünschten Setup Attribute:
.......
@Wolle02:
A:
Könnte es sein das du am Anfang evtl. Einheiten bei den WR/BWR/EM/String etc. nach dem Start anpassen musstest ?
(z. B. wurden dadurch evtl. auch zu hohe Werte als reale Daten modulintern abgespeichert)
Abhilfe :
- Reset für den entsprechenden Bereich (WIKI)
oder
- Es steht dir frei weiter zu warten bis sie nicht mehr so stark in / auf die Prognoseberechnung einwirken.
oder
- Verkürze vorerst als Versuch in plantcontrol die consForecastLastDays auf 20 oder sogar noch weniger Tage.
B:
Hast du evtl. schon einmal auf die "Überprüfung" mit der Maus geklickt (Zahnräder) ?
Da gibts manchmal auch erste Ansätze für evtl. Datenfehler
C:
Ansonsten schau dir auch evtl. manuell die Daten an - siehe WIKI mit langen Erklärungen dazu
D:
Es gibt weitere Hinweise im WIKI für die möglichen Fehlerquellen und der Fehlersuche.
Gruß
300P
Zitat von: Burny4600 am 10 Mai 2025, 20:11:02Ich habe eine Frage zum graphicHeaderOwnspec.
Ich berechne für einen Dummy einen Wert den ich als Reading state ausgebe.
Nun wird aber anstatte des state Wertes ein Feld Format:textField-long generiert.
#CO2 Einsparung
aktuelles Jahr:state@CO2JD
letztes Jahr:state@CO2JLD
Lässt sich das irgendwie abändern?
Sonderfall bei diesem Reading:
Das wird m.M.n. wegen dem Namen "state" und dem modulübergreifenden Zugriff darauf so sein.
Nimm einen anderen Namen als "state" in dem Modul für dein Userreading (unter Userreading "doppeln") dann wird es klappen.
Gruß
300P
Zitat von: Wolle02 am 10 Mai 2025, 15:10:11.....
Hier sind die gewünschten Setup Attribute:
.......
@Wolle02:
Ist mir eben noch eingefallen.
Dein Fronius WR ist ein Hybrid-WR ?!?
Könnte sein das es dort so eingestellt ist das zuerst die "überschüssige" PV-Erzeugung vorrangig direkt in die Batterie geht ;)
Ich bin dann "überfragt" da ich kein solches System betreibe bzw. davon keine Ahnung habe. :-[ :-X O:-)
Gruß
300P
@Chris & 300P,
Zitatch berechne für einen Dummy einen Wert den ich als Reading state ausgebe.
Nun wird aber anstatte des state Wertes ein Feld Format:textField-long generiert.
Das Problem wird in V 1.52.0 behoben sein.
Da kommenden Release werden auch die zugeordneten Solar-Strings mit einem Mouse-Over sichtbar sein. Dazu gibt es eine neue Reihe Solarzellen über den Producern/Invertern. In der V. 1.52.0 wird es auch Batteriewechselrichter ohne Zellen für das Setup geben.
Die Solarzellen können wie üblich ein/ausgeblendet sowie das Icon und Färbung angepasst werden. Vermutlich werden ich die Reihe zuschaltbar mit default=off gestalten.
@tobi01001,
danke für den Hinweis. Habe ich im Wiki eingefügt.
LG,
Heiko
@Wolle02,
ZitatObwohl hier aktuell die Sonne vom strahlend blauen Himmel scheint und ich heute schon 8,8 kWh erzeugt habe wird die reale PV Erzeugung für 8h mit 492 Wh und für 9h mit 904 Wh angezeigt, obwohl die Progrnose (und die scheint ja hier zu stimmen) deutlich mehr anzeigt und ich auch deutlich mehr erzeugt habe. Erst ab 10h, als der Speicher voll war, stimmt scheint auch der Wert der realen PV Erzeugung wieder zu stimmen.
300P hatte es schon erwähnt. Das scheint ein Setup-Problem zu sein.
Kontrolliere bitte die Readings im Schlüssel etotal der setupInverterDevXX Attribute. Es ist zu vermuten, und ich glaube das Thema gab es schonmal, dass der WR solange er die Batterie lädt das genannte Reading nicht hochzählt/updated. Vllt. ist es nicht das richtige Reading oder man muß bei diesem Typ ein Userreading erstellen. Am Besten mal im Fronius Thread nachfragen. Ich glaube es gibt eine User die diesen WR mit SF zusammen benutzen.
LG,
Heiko
Hallo Heiko und 300P,
danke für eure Erklärungen. Dann muss ich mal im Fronius Thread fragen welches Reading User dort für die reale PV-Erzeugung nutzen.
Danke und Gruß
Wolle
Zitat von: Prof. Dr. Peter Henning am 10 Mai 2025, 17:57:02der Begriff "KI" ist wirklich fest verankert
@pah
Tippfehler im alltäglichen denglisch :)
Zitat von: Prof. Dr. Peter Henning am 10 Mai 2025, 17:57:02Wahrscheinlichkeit ist hoch, dass die Prognosen dann wesentlich schlechter werden
Das war meine Frage - danke für die Antwort
Gruß Gerd
Zitat von: 300P am 10 Mai 2025, 20:47:57Sonderfall bei diesem Reading:
Zitat von: DS_Starter am 10 Mai 2025, 22:28:08@Chris
Das Problem wird in V 1.52.0 behoben sein.
Alles klar. Danke. Ich habe es entsprechend bei mir angepasst.
Zitat von: 300P am 10 Mai 2025, 16:39:51hatte ich beim warten an der Waschanlage auf dem Handy überlesen
Jetzt bin ich aber beeindruckt: Eine Autowaschanlage eingebunden in SolarForeCast. 8)
LG
pah
Ich muss noch einmal etwas fragen,
Wie lange dauert es in etwa bis die Prognosen einigermaßen mit der Realität übereinstimmen?
Gestern war es mal seit 3 Wochen recht genau, sonst habe ich immer zwischen 30-50%.
Bei mir wird als Prognose ein Wert bei der Produktion angezeigt, der leider in der Realität, auf Grund der verschiedenen Ausrichtungen, nicht erreicht werden kann.
Muss ich etwas anders im Device einstellen?
Mit freundlichen Grüßen und schönen Sonntag
Das kommt auf die gewählte API sowie die Wiederholrate der schon aufgezeichneten ähnlichen Wetterlagen an.
KI sollte man auch erst nutzen wenn es eine länge Lern-Historie gibt. Wir gehen jetzt in das Frühjar / Sommer hinein. Hat die KI im Winter angefangen zu lernen, dann wird es kaum Werte geben auf die man sich jetzt stützen kann. In diesem Fall erstmal ohne KI arbeiten, es geht auch ohne ... man sollte es kaum glauben. ;)
Zwischen 30 und 50% ist allerdings sehr hoch, vor allem wenn es dauerhaft auftritt. Gerade bei dem aktuellen Wetter. Hier kann es durchaus auch noch ein Setup-Problem geben. Siehe den Case von Wolle02.
Zeige uns mal bitte ein List deines Devices, führe auch mal den Anlagencheck aus und beachte was dort eventuell angemerkt wird.
LG,
Heiko
ZitatHat die KI im Winter angefangen zu lernen, dann wird es kaum Werte geben auf die man sich jetzt stützen kann.
Es sind noch nicht so viele Datensätze gespeichert, allerdings schon genügend wo den ganzen Tag Sonnenschein war (auch in der Wettervorhersage).
Hier Wird z.B. um 12Uhr Sonne vorhergesagt und PV 4400W, es werden aber nur 3800W erzeugt,
Am nächsten Tag gleiche Vorhersage von Wetter und PV und wieder werden nur 3800W erzeugt.
Den Tag darauf dann das selbe. Sollte nicht nach 3 Tagen mit fast identischen Werten die Prognose angepasst werden?
ZitatZeige uns mal bitte ein List deines Devices, führe auch mal den Anlagencheck aus und beachte was dort eventuell angemerkt wird.
Internals:
FUUID 67247ac1-f33f-d66d-4e77-94b6b4acd8c6944b
FVERSION 76_SolarForecast.pm:v1.51.8-s29916/2025-05-02
LCACHEFILE last write time: 13:51:22 whole Operating Memory
MODE Automatic / Event-controlled - next planned Cycletime: 13:53:33
MODEL DWD
NAME PV_forecast
NOTIFYDEV SE3500H,Hyper2000
NR 1538
NTFY_ORDER 50-PV_forecast
STATE running
TYPE SolarForecast
WEATHERMODEL DWD
eventCount 9174
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV PV_forecast
SPGROOM
VERSION 1.51.8
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 547
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:4156033
telnet telnetPort_127.0.0.1_43390
terminated 1
timeout 30
abortArg:
arg:
block 1
name PV_forecast
tsnext 1746967948.22172
OLDREADINGS:
READINGS:
2025-05-11 13:53:27 Battery_ChargeRecommended_01 1
2025-05-11 13:53:27 Battery_NextHour00_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour01_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour02_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour03_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour04_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour05_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour06_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour07_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour08_SoCforecast_01 87.3 %
2025-05-11 13:53:27 Battery_NextHour09_SoCforecast_01 76.4 %
2025-05-11 13:53:27 Battery_NextHour10_SoCforecast_01 65.8 %
2025-05-11 13:53:27 Battery_NextHour11_SoCforecast_01 55.1 %
2025-05-11 13:53:27 Battery_NextHour12_SoCforecast_01 44.3 %
2025-05-11 13:53:27 Battery_NextHour13_SoCforecast_01 33.3 %
2025-05-11 13:53:27 Battery_NextHour14_SoCforecast_01 22.3 %
2025-05-11 13:53:27 Battery_NextHour15_SoCforecast_01 11.4 %
2025-05-11 13:53:27 Battery_NextHour16_SoCforecast_01 3.0 %
2025-05-11 13:53:27 Battery_NextHour17_SoCforecast_01 0.0 %
2025-05-11 13:53:27 Battery_NextHour18_SoCforecast_01 29.7 %
2025-05-11 13:53:27 Battery_NextHour19_SoCforecast_01 85.9 %
2025-05-11 13:53:27 Battery_NextHour20_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour21_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour22_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Battery_NextHour23_SoCforecast_01 100.0 %
2025-05-11 13:53:27 Current_AutarkyRate 100 %
2025-05-11 13:53:27 Current_BatCharge_01 96 %
2025-05-11 13:53:27 Current_Consumption 458 W
2025-05-11 13:53:27 Current_GridConsumption 0 W
2025-05-11 13:53:27 Current_GridFeedIn 2073 W
2025-05-11 13:53:27 Current_PV 3074 W
2025-05-11 13:53:27 Current_PowerBatIn_01 543 W
2025-05-11 13:53:27 Current_PowerBatOut_01 0 W
2025-05-11 13:53:27 Current_SelfConsumption 458 W
2025-05-11 13:53:27 Current_SelfConsumptionRate 15 %
2025-05-11 13:53:27 Current_Surplus 2616 W
2025-05-11 13:00:00 LastHourGridconsumptionReal 152 Wh
2025-05-11 13:00:00 LastHourPVforecast 4400 Wh
2025-05-11 13:00:00 LastHourPVreal 2847 Wh
2025-05-11 13:53:27 NextHours_Sum01_PVforecast 4400 Wh
2025-05-11 13:53:27 NextHours_Sum02_PVforecast 8800 Wh
2025-05-11 13:53:27 NextHours_Sum03_PVforecast 11195 Wh
2025-05-11 13:53:27 NextHours_Sum04_ConsumptionForecast 2160 Wh
2025-05-11 13:53:27 NextHours_Sum04_PVforecast 12806 Wh
2025-05-11 13:53:27 RestOfDayConsumptionForecast 3017 Wh
2025-05-11 13:53:27 RestOfDayPVforecast 14505 Wh
2025-05-11 00:59:58 Today_Hour01_BatIn_01 0 Wh
2025-05-11 00:59:58 Today_Hour01_BatOut_01 163 Wh
2025-05-11 00:59:58 Today_Hour01_GridConsumption 2 Wh
2025-05-11 00:59:58 Today_Hour01_GridFeedIn 1 Wh
2025-05-11 00:59:58 Today_Hour01_PVreal 0 Wh
2025-05-11 01:59:59 Today_Hour02_BatIn_01 0 Wh
2025-05-11 01:59:59 Today_Hour02_BatOut_01 250 Wh
2025-05-11 01:59:59 Today_Hour02_GridConsumption 4 Wh
2025-05-11 01:59:59 Today_Hour02_GridFeedIn 0 Wh
2025-05-11 01:59:59 Today_Hour02_PVreal 0 Wh
2025-05-11 02:59:59 Today_Hour03_BatIn_01 0 Wh
2025-05-11 02:59:59 Today_Hour03_BatOut_01 227 Wh
2025-05-11 02:59:59 Today_Hour03_GridConsumption 3 Wh
2025-05-11 02:59:59 Today_Hour03_GridFeedIn 0 Wh
2025-05-11 02:59:59 Today_Hour03_PVreal 0 Wh
2025-05-11 03:59:58 Today_Hour04_BatIn_01 0 Wh
2025-05-11 03:59:58 Today_Hour04_BatOut_01 56 Wh
2025-05-11 03:59:58 Today_Hour04_GridConsumption 173 Wh
2025-05-11 03:59:58 Today_Hour04_GridFeedIn 0 Wh
2025-05-11 03:59:58 Today_Hour04_PVreal 0 Wh
2025-05-11 04:59:57 Today_Hour05_BatIn_01 0 Wh
2025-05-11 04:59:57 Today_Hour05_BatOut_01 0 Wh
2025-05-11 04:59:57 Today_Hour05_GridConsumption 197 Wh
2025-05-11 04:59:57 Today_Hour05_GridFeedIn 0 Wh
2025-05-11 04:59:57 Today_Hour05_PVreal 0 Wh
2025-05-11 05:59:57 Today_Hour06_BatIn_01 0 Wh
2025-05-11 05:59:57 Today_Hour06_BatOut_01 0 Wh
2025-05-11 05:59:57 Today_Hour06_GridConsumption 177 Wh
2025-05-11 05:59:57 Today_Hour06_GridFeedIn 0 Wh
2025-05-11 05:59:57 Today_Hour06_PVforecast 24 Wh
2025-05-11 05:59:57 Today_Hour06_PVreal 0 Wh
2025-05-11 06:59:58 Today_Hour07_BatIn_01 17 Wh
2025-05-11 06:59:58 Today_Hour07_BatOut_01 0 Wh
2025-05-11 06:59:58 Today_Hour07_GridConsumption 183 Wh
2025-05-11 06:59:58 Today_Hour07_GridFeedIn 0 Wh
2025-05-11 06:59:58 Today_Hour07_PVforecast 231 Wh
2025-05-11 06:59:58 Today_Hour07_PVreal 126 Wh
2025-05-11 07:59:59 Today_Hour08_BatIn_01 199 Wh
2025-05-11 07:59:59 Today_Hour08_BatOut_01 0 Wh
2025-05-11 07:59:59 Today_Hour08_GridConsumption 11 Wh
2025-05-11 07:59:59 Today_Hour08_GridFeedIn 41 Wh
2025-05-11 07:59:59 Today_Hour08_PVforecast 1075 Wh
2025-05-11 07:59:59 Today_Hour08_PVreal 452 Wh
2025-05-11 08:59:59 Today_Hour09_BatIn_01 391 Wh
2025-05-11 08:59:59 Today_Hour09_BatOut_01 263 Wh
2025-05-11 08:59:59 Today_Hour09_GridConsumption 488 Wh
2025-05-11 08:59:59 Today_Hour09_GridFeedIn 146 Wh
2025-05-11 08:59:59 Today_Hour09_PVforecast 1152 Wh
2025-05-11 08:59:59 Today_Hour09_PVreal 1084 Wh
2025-05-11 09:59:59 Today_Hour10_BatIn_01 1103 Wh
2025-05-11 09:59:59 Today_Hour10_BatOut_01 0 Wh
2025-05-11 09:59:59 Today_Hour10_GridConsumption 0 Wh
2025-05-11 09:59:59 Today_Hour10_GridFeedIn 387 Wh
2025-05-11 09:59:59 Today_Hour10_PVforecast 2789 Wh
2025-05-11 09:59:59 Today_Hour10_PVreal 1798 Wh
2025-05-11 10:59:57 Today_Hour11_BatIn_01 533 Wh
2025-05-11 10:59:57 Today_Hour11_BatOut_01 112 Wh
2025-05-11 10:59:57 Today_Hour11_GridConsumption 29 Wh
2025-05-11 10:59:57 Today_Hour11_GridFeedIn 633 Wh
2025-05-11 10:59:57 Today_Hour11_PVforecast 2036 Wh
2025-05-11 10:59:57 Today_Hour11_PVreal 2157 Wh
2025-05-11 11:59:59 Today_Hour12_BatIn_01 339 Wh
2025-05-11 11:59:59 Today_Hour12_BatOut_01 11 Wh
2025-05-11 11:59:59 Today_Hour12_GridConsumption 33 Wh
2025-05-11 11:59:59 Today_Hour12_GridFeedIn 1357 Wh
2025-05-11 11:59:59 Today_Hour12_PVforecast 4400 Wh
2025-05-11 11:59:59 Today_Hour12_PVreal 2399 Wh
2025-05-11 12:59:59 Today_Hour13_BatIn_01 15 Wh
2025-05-11 12:59:59 Today_Hour13_BatOut_01 83 Wh
2025-05-11 12:59:59 Today_Hour13_GridConsumption 152 Wh
2025-05-11 12:59:59 Today_Hour13_GridFeedIn 1026 Wh
2025-05-11 12:59:59 Today_Hour13_PVforecast 4400 Wh
2025-05-11 12:59:59 Today_Hour13_PVreal 2847 Wh
2025-05-11 13:53:27 Today_Hour14_BatIn_01 231 Wh
2025-05-11 13:53:27 Today_Hour14_BatOut_01 172 Wh
2025-05-11 13:53:27 Today_Hour14_GridConsumption 54 Wh
2025-05-11 13:53:27 Today_Hour14_GridFeedIn 1282 Wh
2025-05-11 13:53:27 Today_Hour14_PVforecast 4400 Wh
2025-05-11 13:53:27 Today_Hour14_PVreal 2771 Wh
2025-05-11 13:53:27 Today_Hour15_PVforecast 4400 Wh
2025-05-11 13:53:27 Today_Hour16_PVforecast 4400 Wh
2025-05-11 13:53:27 Today_Hour17_PVforecast 2173 Wh
2025-05-11 13:53:27 Today_Hour18_PVforecast 1548 Wh
2025-05-11 13:53:27 Today_Hour19_PVforecast 1142 Wh
2025-05-11 13:53:27 Today_Hour20_PVforecast 312 Wh
2025-05-11 13:53:27 Today_Hour21_PVforecast 79 Wh
2025-05-11 13:53:27 Today_Hour22_PVforecast 11 Wh
2025-05-11 13:53:27 Today_MaxPVforecast 4400 Wh
2025-05-11 13:53:27 Today_MaxPVforecastTime 2025-05-11 11:00:00
2025-05-11 13:53:27 Today_PVdeviation 32.06 %
2025-05-11 13:53:27 Today_PVforecast 34572 Wh
2025-05-11 13:53:27 Today_PVreal 13634 Wh
2025-05-11 13:53:27 Today_SunRise 05:26
2025-05-11 13:53:27 Today_SunSet 21:09
2025-05-11 13:53:27 Tomorrow_ConsumptionForecast 6043 Wh
2025-05-11 13:53:27 Tomorrow_Hour06_PVforecast 43 Wh
2025-05-11 13:53:27 Tomorrow_Hour07_PVforecast 77 Wh
2025-05-11 13:53:27 Tomorrow_Hour08_PVforecast 917 Wh
2025-05-11 13:53:27 Tomorrow_Hour09_PVforecast 2014 Wh
2025-05-11 13:53:27 Tomorrow_Hour10_PVforecast 2018 Wh
2025-05-11 13:53:27 Tomorrow_Hour11_PVforecast 4148 Wh
2025-05-11 13:53:27 Tomorrow_Hour12_PVforecast 4290 Wh
2025-05-11 13:53:27 Tomorrow_Hour13_PVforecast 4298 Wh
2025-05-11 13:53:27 Tomorrow_Hour14_PVforecast 1766 Wh
2025-05-11 13:53:27 Tomorrow_Hour15_PVforecast 4400 Wh
2025-05-11 13:53:27 Tomorrow_Hour16_PVforecast 4307 Wh
2025-05-11 13:53:27 Tomorrow_Hour17_PVforecast 2361 Wh
2025-05-11 13:53:27 Tomorrow_Hour18_PVforecast 1723 Wh
2025-05-11 13:53:27 Tomorrow_Hour19_PVforecast 1344 Wh
2025-05-11 13:53:27 Tomorrow_Hour20_PVforecast 304 Wh
2025-05-11 13:53:27 Tomorrow_Hour21_PVforecast 109 Wh
2025-05-11 13:53:27 Tomorrow_Hour22_PVforecast 11 Wh
2025-05-11 13:53:27 Tomorrow_PVforecast 34130 Wh
2025-05-11 13:53:27 Tomorrow_SunRise 05:25
2025-05-11 13:53:27 Tomorrow_SunSet 21:10
2024-11-01 08:16:36 currentInverterDev SE3500H pv=AC_current_W:W etotal=gesamtPV:kWh capacity=3600
2024-11-01 07:59:28 currentRadiationAPI PV_forecast_weather
2024-11-01 07:57:43 inverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
2024-11-01 08:20:00 moduleAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
2024-11-01 08:22:24 moduleDeclination Vordach=40 Fahrradschuppen=25 Dach=45 Garten=15 Wintergarten=15
2024-11-01 08:20:38 modulePeakString Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.94
2025-05-11 13:52:23 nextCycletime 13:53:33
2025-05-11 07:00:00 pvCorrectionFactor_07 0.55 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 55, Days in range: 1)
2025-05-11 08:00:02 pvCorrectionFactor_08 0.69 (automatic - old factor: 0.99, AI result used, Sun Alt range: 15, Cloud range: 35, Days in range: 2)
2025-05-11 09:00:02 pvCorrectionFactor_09 0.89 (automatic - old factor: 0.76, AI result used, Sun Alt range: 25, Cloud range: 00, Days in range: 3)
2025-05-11 10:00:02 pvCorrectionFactor_10 0.64 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 40, Days in range: 1)
2025-05-11 11:00:00 pvCorrectionFactor_11 0.68 (automatic - old factor: 0.49, Sun Alt range: 40, Cloud range: 25, Days in range: 2)
2025-05-11 12:00:02 pvCorrectionFactor_12 0.55 (automatic - old factor: 1.00, Sun Alt range: 50, Cloud range: 40, Days in range: 1)
2025-05-11 13:00:02 pvCorrectionFactor_13 0.65 (automatic - old factor: 1.00, Sun Alt range: 55, Cloud range: 00, Days in range: 1)
2025-05-11 13:53:27 pvCorrectionFactor_Auto on_complex_api_ai
2025-05-11 13:53:27 special_BatPowerIn_Sum 543 W
2025-05-11 13:53:27 special_BatPowerOut_Sum 0 W
2025-05-11 13:53:27 special_runTimeTrainAI 0.78956 s
2025-05-11 13:53:27 special_todayBatInSum 2830.8 Wh
2025-05-11 13:53:27 special_todayBatOutSum 1341.7 Wh
2025-05-11 13:53:27 special_todayConsumption 8776 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_01 188 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_02 186 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_03 188 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_04 190 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_05 186 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_06 188 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_07 234 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_08 285 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_09 575 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_10 595 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_11 688 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_12 650 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_13 598 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_14 537 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_15 702 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_16 546 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_17 435 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_18 471 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_19 171 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_20 33 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_21 4 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_22 230 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_23 190 Wh
2025-05-11 13:53:27 special_todayConsumptionForecast_24 182 Wh
2025-05-11 13:53:27 special_todayGridConsumption 1506 Wh
2025-05-11 13:53:27 special_todayGridFeedIn 4873.0 Wh
2025-05-11 13:53:27 state running
Attributes:
DbLogExclude .*
aiControl aiTrainStart=5 aiStorageDuration=1825 aiTreesPV=30
ctrlLanguage DE
ctrlNextDayForecastReadings 06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22
ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,runTimeTrainAI,todayBatInSum,todayBatOutSum,todayConsumption,todayConsumptionForecast,todayGridConsumption,todayGridFeedIn
event-on-change-reading .*
graphicBeam3Content batsocForecast_01
graphicBeam4Content batsocReal_01
graphicBeam5Content gridconsumption
graphicBeam6Content consumptionForecast
graphicControl hourCount=24 energyUnit=Wh headerDetail=all layoutType=double
graphicHeaderOwnspec Ladeleistung:Current_PowerBatIn_01
Entladeleistung:Current_PowerBatOut_01
Akku_In:special_todayBatInSum
Akku_Out:special_todayBatOutSum
graphicHistoryHour 12
graphicSelect both
graphicShowDiff bottom
graphicShowNight 01
plantControl consForecastIdentWeekdays=1 consForecastLastDays=31 cycleInterval=70 genPVdeviation=continuously
room PV-Solar
setupBatteryDev01 Hyper2000 pin=outputPackPower:W pout=packInputPower:W intotal=energy_total_batteryOutput:Wh outtotal=energy_total_batteryInput:Wh pinmax=1200 poutmax=1200 cap=1920 charge=electricLevel show=2:bottom asynchron=1
setupInverterDev01 SE3500H pv=AC_current_W:W etotal=AC_Lifetime_Energy_production_kWh:kWh capacity=3500 asynchron=1 strings=Vordach,Fahrradschuppen,Garten,Wintergarten
setupInverterDev02 Hyper2000 pv=solarInputPower:W etotal=energy_total_solar:Wh capacity=900 asynchron=1 strings=Dach feed=bat
setupInverterStrings Vordach,Fahrradschuppen,Dach,Garten,Wintergarten
setupMeterDev SE3500H gcon=Momentanleistung_Bezug:W contotal=total_Energy_Imported_kWh:kWh gfeedin=Momentanleistung_Einspeisung feedtotal=total_Energy_Exported_kWh:kWh asynchron=1
setupRadiationAPI PV_forecast_weather
setupStringAzimuth Vordach=-90 Fahrradschuppen=0 Dach=0 Garten=-90 Wintergarten=90
setupStringDeclination Vordach=50 Fahrradschuppen=20 Dach=45 Garten=8 Wintergarten=15
setupStringPeak Vordach=0.6 Fahrradschuppen=0.66 Dach=0.88 Garten=1.2 Wintergarten=1.93
setupWeatherDev1 PV_forecast_weatherHier noch ein aiRuleStrings
Trained AI Object contains an Ensemble of 30 trees (only the first Tree is printed out)
Tree: 1 -> Number of Rules: 258 / Number of Nodes: 330 / Depth: 3
Tree: 2 -> Number of Rules: 257 / Number of Nodes: 327 / Depth: 3
Tree: 3 -> Number of Rules: 257 / Number of Nodes: 326 / Depth: 2
Tree: 4 -> Number of Rules: 257 / Number of Nodes: 326 / Depth: 2
Tree: 5 -> Number of Rules: 257 / Number of Nodes: 327 / Depth: 3
Tree: 6 -> Number of Rules: 258 / Number of Nodes: 331 / Depth: 3
Tree: 7 -> Number of Rules: 258 / Number of Nodes: 329 / Depth: 3
Tree: 8 -> Number of Rules: 257 / Number of Nodes: 333 / Depth: 3
Tree: 9 -> Number of Rules: 256 / Number of Nodes: 327 / Depth: 2
Tree: 10 -> Number of Rules: 258 / Number of Nodes: 327 / Depth: 3
Tree: 11 -> Number of Rules: 258 / Number of Nodes: 335 / Depth: 3
Tree: 12 -> Number of Rules: 258 / Number of Nodes: 327 / Depth: 3
Tree: 13 -> Number of Rules: 256 / Number of Nodes: 329 / Depth: 2
Tree: 14 -> Number of Rules: 258 / Number of Nodes: 331 / Depth: 2
Tree: 15 -> Number of Rules: 256 / Number of Nodes: 328 / Depth: 3
Tree: 16 -> Number of Rules: 258 / Number of Nodes: 330 / Depth: 2
Tree: 17 -> Number of Rules: 257 / Number of Nodes: 325 / Depth: 3
Tree: 18 -> Number of Rules: 258 / Number of Nodes: 333 / Depth: 2
Tree: 19 -> Number of Rules: 257 / Number of Nodes: 330 / Depth: 3
Tree: 20 -> Number of Rules: 258 / Number of Nodes: 337 / Depth: 3
Tree: 21 -> Number of Rules: 257 / Number of Nodes: 330 / Depth: 3
Tree: 22 -> Number of Rules: 257 / Number of Nodes: 334 / Depth: 2
Tree: 23 -> Number of Rules: 257 / Number of Nodes: 326 / Depth: 2
Tree: 24 -> Number of Rules: 257 / Number of Nodes: 327 / Depth: 3
Tree: 25 -> Number of Rules: 257 / Number of Nodes: 331 / Depth: 2
Tree: 26 -> Number of Rules: 258 / Number of Nodes: 327 / Depth: 2
Tree: 27 -> Number of Rules: 257 / Number of Nodes: 328 / Depth: 2
Tree: 28 -> Number of Rules: 257 / Number of Nodes: 329 / Depth: 2
Tree: 29 -> Number of Rules: 258 / Number of Nodes: 328 / Depth: 3
Tree: 30 -> Number of Rules: 257 / Number of Nodes: 330 / Depth: 2
Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen
letztes KI-Training: 11.05.2025 05:15:01 / Laufzeit in Sekunden: 0.78956
letzte KI-Ergebnis Generierungsdauer: 0.14 ms
Tree: 1
if rad1h='1330' -> '1705'
if rad1h='330' -> '324'
if rad1h='1060' and sunalt='18' -> '961'
if rad1h='1060' and sunalt='38' -> '1276'
if rad1h='70' -> '32'
if rad1h='800' -> '942'
if rad1h='510' and sunalt='10' -> '254'
if rad1h='510' and sunalt='13' -> '311'
if rad1h='510' and sunalt='17' -> '733'
if rad1h='510' and sunalt='11' -> '272'
if rad1h='510' and sunalt='21' -> '350'
if rad1h='1180' and sunalt='44' -> '972'
if rad1h='1180' and sunalt='47' -> '707'
if rad1h='1180' and sunalt='45' -> '992'
if rad1h='1020' -> '1904'
if rad1h='780' and sunalt='36' -> '444'
if rad1h='780' and sunalt='30' -> '850'
if rad1h='1070' -> '1594'
if rad1h='540' -> '1069'
if rad1h='1000' -> '1876'
if rad1h='1590' -> '1810'
if rad1h='430' -> '217'
if rad1h='720' -> '895'
if rad1h='1080' -> '1096'
if rad1h='500' and sunalt='23' -> '645'
if rad1h='500' and sunalt='13' -> '410'
if rad1h='500' and sunalt='37' -> '704'
if rad1h='280' and rr1c='0.10' -> '220'
if rad1h='280' and rr1c='0.00' -> '215'
if rad1h='2700' -> '2861'
if rad1h='2770' and sunalt='51' -> '3002'
if rad1h='2770' and sunalt='53' -> '2855'
if rad1h='2210' -> '2268'
if rad1h='1160' -> '1410'
if rad1h='2250' -> '2329'
if rad1h='840' -> '1288'
if rad1h='20' -> '33'
if rad1h='2690' -> '2860'
if rad1h='1460' and sunalt='53' -> '1951'
if rad1h='1460' and sunalt='39' -> '2108'
if rad1h='1460' and sunalt='48' -> '2108'
if rad1h='150' and wcc='50' -> '80'
if rad1h='150' and wcc='00' -> '82'
if rad1h='790' -> '2090'
if rad1h='2370' -> '3086'
if rad1h='1120' -> '1475'
if rad1h='10' -> '10'
if rad1h='660' -> '1083'
if rad1h='620' -> '786'
if rad1h='1760' -> '2717'
if rad1h='1320' and sunalt='47' -> '1714'
if rad1h='1320' and sunalt='32' -> '1143'
if rad1h='1320' and sunalt='45' -> '2193'
if rad1h='1250' and sunalt='42' -> '1601'
if rad1h='1250' and sunalt='40' -> '1935'
if rad1h='1370' -> '2178'
if rad1h='1300' and sunalt='48' -> '1968'
if rad1h='1300' and sunalt='42' -> '1985'
if rad1h='90' and sunalt='4' -> '45'
if rad1h='90' and sunalt='5' -> '37'
if rad1h='90' and sunalt='8' -> '172'
if rad1h='870' and sunalt='26' -> '1267'
if rad1h='870' and sunalt='21' -> '863'
if rad1h='870' and sunalt='47' -> '1461'
if rad1h='440' and sunalt='18' -> '526'
if rad1h='440' and sunalt='16' -> '480'
if rad1h='440' and sunalt='10' -> '120'
if rad1h='1720' and sunalt='41' -> '2154'
if rad1h='1720' and sunalt='53' -> '2517'
if rad1h='1030' and sunalt='40' -> '1170'
if rad1h='1030' and sunalt='45' -> '1021'
if rad1h='1030' and sunalt='33' -> '1873'
if rad1h='980' -> '2246'
if rad1h='300' and sunalt='16' -> '528'
if rad1h='300' and sunalt='15' -> '186'
if rad1h='300' and sunalt='36' -> '496'
if rad1h='1360' and sunalt='40' -> '555'
if rad1h='1360' and sunalt='48' -> '2501'
if rad1h='1360' and sunalt='47' -> '504'
if rad1h='690' and rr1c='0.00' -> '1899'
if rad1h='690' and rr1c='0.30' -> '1529'
if rad1h='410' -> '700'
if rad1h='180' -> '521'
if rad1h='830' and sunalt='32' -> '1069'
if rad1h='830' and sunalt='37' -> '1193'
if rad1h='1240' and sunalt='38' -> '1391'
if rad1h='1240' and sunalt='32' -> '1638'
if rad1h='1240' and sunalt='51' -> '2832'
if rad1h='1700' and sunalt='35' -> '1181'
if rad1h='1700' and sunalt='46' -> '1965'
if rad1h='960' and sunalt='22' -> '1053'
if rad1h='960' and sunalt='49' -> '1251'
if rad1h='960' and sunalt='28' -> '1583'
if rad1h='960' and sunalt='19' -> '969'
if rad1h='920' and sunalt='34' -> '1762'
if rad1h='920' and sunalt='38' -> '610'
if rad1h='920' and sunalt='24' -> '1039'
if rad1h='920' and sunalt='29' -> '887'
if rad1h='570' and sunalt='28' -> '320'
if rad1h='570' and sunalt='36' -> '1376'
if rad1h='570' and sunalt='26' -> '1526'
if rad1h='120' and sunalt='5' -> '67'
if rad1h='120' and sunalt='12' -> '259'
if rad1h='120' and sunalt='6' -> '91'
if rad1h='160' and sunalt='13' -> '68'
if rad1h='160' and sunalt='8' -> '148'
if rad1h='160' and sunalt='9' -> '35'
if rad1h='60' and sunalt='2' -> '21'
if rad1h='60' and sunalt='3' -> '11'
if rad1h='1840' -> '2049'
if rad1h='340' -> '547'
if rad1h='1810' -> '2912'
if rad1h='400' -> '551'
if rad1h='190' -> '160'
if rad1h='1850' -> '2090'
if rad1h='750' and sunalt='24' -> '1056'
if rad1h='750' and sunalt='29' -> '785'
if rad1h='680' -> '1458'
if rad1h='530' -> '900'
if rad1h='990' -> '1570'
if rad1h='1130' -> '1809'
if rad1h='2180' -> '2256'
if rad1h='310' and rr1c='0.70' -> '482'
if rad1h='310' and rr1c='0.00' -> '181'
if rad1h='270' and sunalt='18' -> '299'
if rad1h='270' and sunalt='8' -> '208'
if rad1h='270' and sunalt='15' -> '415'
if rad1h='40' -> '10'
if rad1h='1040' and wcc='70' -> '1670'
if rad1h='1040' and wcc='90' -> '656'
if rad1h='1010' and sunalt='46' -> '1847'
if rad1h='1010' and sunalt='30' -> '852'
if rad1h='1230' and sunalt='47' -> '2011'
if rad1h='1230' and sunalt='42' -> '2375'
if rad1h='140' and rr1c='0.20' -> '32'
if rad1h='140' and rr1c='0.00' -> '44'
if rad1h='2820' -> '2868'
if rad1h='360' and sunalt='12' -> '280'
if rad1h='360' and sunalt='15' -> '522'
if rad1h='360' and sunalt='29' -> '512'
if rad1h='320' -> '736'
if rad1h='1500' and sunalt='46' -> '2530'
if rad1h='1500' and sunalt='31' -> '1747'
if rad1h='2980' -> '3136'
if rad1h='230' and sunalt='12' -> '174'
if rad1h='230' and sunalt='9' -> '121'
if rad1h='390' -> '234'
if rad1h='110' and sunalt='8' -> '23'
if rad1h='110' and sunalt='11' -> '115'
if rad1h='110' and sunalt='4' and wid='2' -> '43'
if rad1h='110' and sunalt='4' and wid='3' -> '55'
if rad1h='110' and sunalt='7' -> '113'
if rad1h='600' -> '427'
if rad1h='1520' and sunalt='30' -> '1799'
if rad1h='1520' and sunalt='47' -> '2777'
if rad1h='480' -> '441'
if rad1h='2310' and sunalt='46' -> '2804'
if rad1h='2310' and sunalt='48' -> '2447'
if rad1h='2340' -> '2890'
if rad1h='1450' -> '1785'
if rad1h='640' and sunalt='16' -> '379'
if rad1h='640' and sunalt='37' -> '1396'
if rad1h='30' -> '50'
if rad1h='1490' and sunalt='45' -> '1712'
if rad1h='1490' and sunalt='52' -> '1514'
if rad1h='1490' and sunalt='33' -> '1755'
if rad1h='1490' and sunalt='51' -> '2395'
if rad1h='730' and sunalt='46' -> '1827'
if rad1h='730' and sunalt='26' -> '1165'
if rad1h='730' and sunalt='23' -> '1046'
if rad1h='730' and sunalt='20' -> '760'
if rad1h='2660' -> '3200'
if rad1h='420' and rr1c='0.60' -> '315'
if rad1h='420' and rr1c='0.00' -> '862'
if rad1h='460' and sunalt='23' -> '520'
if rad1h='460' and sunalt='13' -> '425'
if rad1h='460' and sunalt='24' -> '641'
if rad1h='550' -> '843'
if rad1h='1110' -> '1011'
if rad1h='1140' and sunalt='35' -> '1891'
if rad1h='1140' and sunalt='50' -> '1541'
if rad1h='610' -> '1104'
if rad1h='100' and wid='0' -> '57'
if rad1h='100' and wid='45' -> '114'
if rad1h='100' and wid='3' -> '80'
if rad1h='100' and wid='61' -> '395'
if rad1h='100' and wid='2' -> '34'
if rad1h='490' -> '723'
if rad1h='1150' and sunalt='47' -> '1824'
if rad1h='1150' and sunalt='31' -> '1739'
if rad1h='1150' and sunalt='48' -> '1545'
if rad1h='1150' and sunalt='46' -> '769'
if rad1h='2270' -> '924'
if rad1h='2710' and wcc='00' -> '3001'
if rad1h='2710' and wcc='30' -> '3050'
if rad1h='2350' -> '2358'
if rad1h='380' and rr1c='0.00' -> '339'
if rad1h='380' and rr1c='0.60' -> '115'
if rad1h='1440' -> '888'
if rad1h='900' -> '1452'
if rad1h='1190' and sunalt='50' -> '2966'
if rad1h='1190' and sunalt='36' -> '2088'
if rad1h='1740' and sunalt='51' -> '2684'
if rad1h='1740' and sunalt='52' -> '2418'
if rad1h='1600' and sunalt='52' -> '824'
if rad1h='1600' and sunalt='48' -> '2595'
if rad1h='2150' -> '2889'
if rad1h='1200' -> '1397'
if rad1h='740' and sunalt='23' -> '947'
if rad1h='740' and sunalt='34' -> '1407'
if rad1h='200' and rr1c='1.30' -> '198'
if rad1h='200' and rr1c='0.00' -> '60'
if rad1h='2190' and sunalt='49' -> '3071'
if rad1h='2190' and sunalt='44' -> '2680'
if rad1h='580' -> '1158'
if rad1h='630' -> '1150'
if rad1h='1880' -> '2110'
if rad1h='1350' -> '883'
if rad1h='1220' -> '771'
if rad1h='890' and rr1c='0.10' -> '1141'
if rad1h='890' and rr1c='0.00' -> '931'
if rad1h='710' -> '779'
if rad1h='50' and wcc='90' -> '23'
if rad1h='50' and wcc='00' -> '11'
if rad1h='50' and wcc='25' -> '21'
if rad1h='50' and wcc='80' -> '10'
if rad1h='50' and wcc='75' -> '70'
if rad1h='2450' and sunalt='49' -> '3054'
if rad1h='2450' and sunalt='51' -> '3234'
if rad1h='860' and sunalt='31' -> '1105'
if rad1h='860' and sunalt='19' -> '790'
if rad1h='1900' -> '724'
if rad1h='1970' and sunalt='36' -> '2078'
if rad1h='1970' and sunalt='43' -> '2749'
if rad1h='1660' -> '2414'
if rad1h='670' -> '358'
if rad1h='1260' and sunalt='33' -> '1852'
if rad1h='1260' and sunalt='43' -> '1886'
if rad1h='350' and rr1c='0.00' -> '841'
if rad1h='350' and rr1c='0.10' -> '209'
if rad1h='880' -> '1456'
if rad1h='2050' and sunalt='48' -> '2559'
if rad1h='2050' and sunalt='42' -> '2104'
if rad1h='930' -> '1734'
if rad1h='2040' and sunalt='38' -> '2089'
if rad1h='2040' and sunalt='42' -> '2469'
if rad1h='170' -> '321'
if rad1h='700' -> '909'
if rad1h='1820' -> '2231'
if rad1h='450' and sunalt='12' -> '330'
if rad1h='450' and sunalt='24' -> '639'
if rad1h='970' and sunalt='41' -> '2023'
if rad1h='970' and sunalt='37' -> '1568'
if rad1h='80' and sunalt='5' -> '68'
if rad1h='80' and sunalt='2' -> '21'
if rad1h='80' and sunalt='19' -> '348'
if rad1h='80' and sunalt='4' -> '46'
if rad1h='1280' -> '1727'
Mit freundlichen Grüßen
ZitatDen Tag darauf dann das selbe. Sollte nicht nach 3 Tagen mit fast identischen Werten die Prognose angepasst werden?
Ja, richtig.
Genaueres sieht man an den Readings:
Zitat2025-05-11 07:00:00 pvCorrectionFactor_07 0.55 (automatic - old factor: 1.00, Sun Alt range: 10, Cloud range: 55, Days in range: 1)
2025-05-11 08:00:02 pvCorrectionFactor_08 0.69 (automatic - old factor: 0.99, AI result used, Sun Alt range: 15, Cloud range: 35, Days in range: 2)
2025-05-11 09:00:02 pvCorrectionFactor_09 0.89 (automatic - old factor: 0.76, AI result used, Sun Alt range: 25, Cloud range: 00, Days in range: 3)
2025-05-11 10:00:02 pvCorrectionFactor_10 0.64 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 40, Days in range: 1)
2025-05-11 11:00:00 pvCorrectionFactor_11 0.68 (automatic - old factor: 0.49, Sun Alt range: 40, Cloud range: 25, Days in range: 2)
2025-05-11 12:00:02 pvCorrectionFactor_12 0.55 (automatic - old factor: 1.00, Sun Alt range: 50, Cloud range: 40, Days in range: 1)
2025-05-11 13:00:02 pvCorrectionFactor_13 0.65 (automatic - old factor: 1.00, Sun Alt range: 55, Cloud range: 00, Days in range: 1)
Days in range = 1 bedeutet, dass bisher nur ein Tag mit gleichen Sonnenstand und Bewölkung zur gleichen Stunde aufgezeichnet wurde und zur Kalkulation für die Zukunft verwendet werden kann. Das betrifft das herkömmliche im Modul verankerte Verfahren.
Der Unterschied zwischen pvCorrectionFactor_XX und "automatic - old factor" zeigt wie hoch die aktuelle Dynamik der Anpassung für die Stunde X ist, d.h. bei "pvCorrectionFactor_09 0.89 (automatic - old factor: 0.76)" die Anpassung schon recht klein.
Aber du hast KI eingeschaltet, d.h. deren Werte bilden mit den API Werten einen Durchschnitt der verwendet wird (pvCorrectionFactor_Auto = on_complex_api_ai). Sieht man an "AI result used".
Nun halte ich den Lernzustand deiner KI für unzureichend, du hast nur ca. 350 Entscheidungsknoten bei einer Tiefe von max. 3 soweit ich das sehe. Ich halte das für zu wenig, d.h. die Anzahl der Rohdatensätze (get ... valDecTree aiRawData) ist noch zu gering.
Zum Vergleich bei einer meiner Instanzen gibt es über 7000 Entscheidungsknoten bei einer Tiefe von max. 6:
Trained AI Object contains an Ensemble of 9 trees (only the first Tree is printed out)
Tree: 1 -> Number of Rules: 5253 / Number of Nodes: 7074 / Depth: 6
Tree: 2 -> Number of Rules: 5264 / Number of Nodes: 7054 / Depth: 5
Tree: 3 -> Number of Rules: 5259 / Number of Nodes: 7068 / Depth: 5
Tree: 4 -> Number of Rules: 5256 / Number of Nodes: 7064 / Depth: 6
Tree: 5 -> Number of Rules: 5268 / Number of Nodes: 7042 / Depth: 5
Tree: 6 -> Number of Rules: 5259 / Number of Nodes: 7057 / Depth: 5
Tree: 7 -> Number of Rules: 5264 / Number of Nodes: 7047 / Depth: 5
Tree: 8 -> Number of Rules: 5247 / Number of Nodes: 7036 / Depth: 5
Tree: 9 -> Number of Rules: 5261 / Number of Nodes: 7072 / Depth: 6
Ich würde dir raten, zunächst auf die KI zu verzichten und pvCorrectionFactor_Auto = on_complex einzusetzen, also nur mit der API zu arbeiten.
Weiterhin könntest du die noch ein zweites SF-Device anlegen und dort mit der openMeteo API (oder SolCast) arbeiten. Dann hast du einen Vergleich und kannst entscheiden welche Variante für dich besser geegnet ist. Du hast viele Einzelstrings die sich zu einem Gesamtbild fügen müssen. Auch darin kann eine Herausforderung liegen, wobei Burny4600 uns kürzlich seine sehr komplexe Anlage mit durchaus guten Ergebnissen präsentiert hatte.
OpenMeteo ist auch sehr einfach einzurichten.
LG,
Heiko
ZitatIch würde dir raten, zunächst auf die KI zu verzichten und pvCorrectionFactor_Auto = on_complex einzusetzen, also nur mit der API zu arbeiten.
Werden dann trotzdem Daten für die KI gesammelt und ich kann dann irgendwann wieder auf on_compex_api_ai schalten?
ZitatWerden dann trotzdem Daten für die KI gesammelt und ich kann dann irgendwann wieder auf on_compex_api_ai schalten?
Ja, auf jeden Fall.
Auch Korrekturfaktoren werden permanent weiter berechnet auch wenn man pvCorrectionFactor_Auto = off eingestellt hat. Man kann jederzeit zwischen den Modi wechseln.
Du kannst den Fortschritt der Rohdaten und des Trainings mit "get ... valDecTree ..." verfolgen.
Hallo zusammen,
ich habe soeben das Major Release 1.52.0 eingecheckt.
Was ist alles enthalten:
- das Setup der Wechselrichter (setupInverterDevXX) kann nun verschiedene Architekturen spezifizieren um eine bessere Unterstützung für
Balkonkrafwerke oder andere Anlagen mit reinen Batterie-Wechselrichtern zu ermöglichen
- Es kann der Typ Batterie-Wechselrichter zur reinen DC->AC / AC->DC definiert werden, die Flußgrafik gibt diese IN / OUT Flüsse auch wieder
- die Attribute setupInverterDevXX enthalten dafür neue Schlüssel dc2ac, ac2dc
- die obsolet gewordenen Attribute sind entfernt: graphicLayoutType, graphicHourStyle, graphicHeaderDetail, graphicSpaceSize, graphicBeamWidth,
graphicHourCount, graphicEnergyUnit, graphicHeaderShow
- Im Attr flowGraphicControl ist ein neuer Schlüssel "showGenerators" vorhanden um eine Reihe mit
PV-Zellen anzuzeigen sofern der WR Zellen zugeordnet hat.
Ein Mouse-Over zeigt die zugeordneten Strings.
Das Icon und dessen Farbe kann man noch nicht ändern. Mir fehlt momentan noch die Idee in welches Attribut ich es
einbauen kann. Ein zusätzliches Attr wollte ich dafür ungern erstellen. Mal sehen ob mir noch eine Idee kommt.
- Im Wiki habe ich begleitend zu der Erweiterungen von setupInverterDevXX einen Abschnitt zum Setup der Wechselrichter erstellt
https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Einrichtung_der_Wechselrichter_mit_setupInverterDevXX
- Attribut graphicHeaderOwnspec: Fehler bei Anzeige des Readings "state" eines Devices gefixt
Nach dem Download Restart nicht vergessen!
LG,
Heiko
Zitat von: Prof. Dr. Peter Henning am 11 Mai 2025, 12:15:12Zitat von: 300P am 10 Mai 2025, 16:39:51hatte ich beim warten an der Waschanlage auf dem Handy überlesen
Jetzt bin ich aber beeindruckt: Eine Autowaschanlage eingebunden in SolarForeCast. 8)
LG
pah
Tja - an der Kasse nicht gefragt wieviel noch vor mir waren, sonst wär ich wieder gefahren.......denn es waren 3 Autos x 8-15 Minuten je nach Waschprogramm. Das gibt meist dann ca. 35-45 Minuten Wartezeit. :o
Und dann ist das Handy der beste Freund...... O:-)
Gruß
300P
Ich habe eine Frage zur der Ermittlung der Abweichung.
Wo kann ich diese Einstellungen definieren um ein Ergebniss der Abweichungen zu erhalten?
Im Standard, wie bei dir eingestellt, wird das Ergebnis nach Sonnenuntergang ermittelt.
Ansonsten einstellbar über Attr plantControl->genPVdeviation.
LG,
Heiko
Moin,
weil wir es gestern über die Verwendung von KI diskutiert hatten hier noch ein Beispiel von meienr OpenMeteo Ensemble Instanz.
Gesammelt wurden bisher 6334 Rohdatensätze.
Damit erreicht die KI ca. 5400 Entscheidungsknoten mit einer Tiefe von 5-6.
Trained AI Object contains an Ensemble of 10 trees (only the first Tree is printed out)
Tree: 1 -> Number of Rules: 4009 / Number of Nodes: 5462 / Depth: 5
Tree: 2 -> Number of Rules: 4015 / Number of Nodes: 5481 / Depth: 5
Tree: 3 -> Number of Rules: 4006 / Number of Nodes: 5484 / Depth: 5
Tree: 4 -> Number of Rules: 4008 / Number of Nodes: 5455 / Depth: 6
Tree: 5 -> Number of Rules: 4005 / Number of Nodes: 5464 / Depth: 5
Tree: 6 -> Number of Rules: 4016 / Number of Nodes: 5469 / Depth: 5
Tree: 7 -> Number of Rules: 3992 / Number of Nodes: 5462 / Depth: 5
Tree: 8 -> Number of Rules: 4010 / Number of Nodes: 5476 / Depth: 5
Tree: 9 -> Number of Rules: 3997 / Number of Nodes: 5473 / Depth: 5
Tree: 10 -> Number of Rules: 4003 / Number of Nodes: 5472 / Depth: 5
Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen
letztes KI-Training: 12.05.2025 03:15:26 / Laufzeit in Sekunden: 2.25812
letzte KI-Ergebnis Generierungsdauer: 0.03 ms
Wenn man sich die aiRuleStrings anschaut, sieht den Einfluß der Tiefe (hier 3 und 4):
if rad1h='1430' and hod='17' and rr1c='0.20' -> '2430'
if rad1h='1430' and hod='17' and rr1c='0.00' -> '3300'
if rad1h='1430' and hod='10' and temp='10' and wcc='00' -> '3734'
if rad1h='1430' and hod='10' and temp='10' and wcc='50' -> '2316'
Bei der Tiefe 4 werden mehr Vergleichsparameter einbezogen im Vergleich zu der Tiefe 3.
Bei der gewählten Autokorrekturmethode werden die KI Ergebnisse anstatt der API Werte verwendet sofern Treffer geliefert werden:
2025-05-12 06:00:04 pvCorrectionFactor_06 0.75 (automatic - old factor: 0.57, AI result used, Sun Alt range: 0, Cloud range: 00, Days in range: 5)
2025-05-12 07:00:05 pvCorrectionFactor_07 0.73 (automatic - old factor: 0.73, AI result used, Sun Alt range: 10, Cloud range: 00, Days in range: 3)
2025-05-12 08:00:05 pvCorrectionFactor_08 0.89 (automatic - old factor: 0.99, AI result used, Sun Alt range: 20, Cloud range: 00, Days in range: 2)
2025-05-12 09:00:05 pvCorrectionFactor_09 0.98 (automatic - old factor: 0.99, AI result used, Sun Alt range: 25, Cloud range: 00, Days in range: 11)
2025-05-12 10:00:05 pvCorrectionFactor_10 0.94 (automatic - old factor: 0.95, AI result used, Sun Alt range: 35, Cloud range: 00, Days in range: 7)
Das Ergebnis liegt sehr nahe an der Realität (siehe Anhang).
LG,
Heiko
Ich muss leider nochmal fragen. Es geht um die Consumer. Aus irgend einem Grund wurde nur ein Consumer angezeigt. Nun habe ich alle Verbraucher gelöscht und wollte einem nach dem anderen wieder anlegen.
Nun wird kein einziger Verbraucher angezeigt.
Woran liegt mein Fehler?
Es gibt im Prinzip 2 Stellen an denen man die Sichtbarkeit steuert:
- im consumer Attribut, Schlüssel noshow für die Sichtbarkeit einzelner consumer
- das Attr graphicSelect für die generelle Sichtbarkeit
Und für die Flußgrafik:
- flowGraphicControl showconsumer=1
Grüße,
Heiko
Das lag an keinem der beiden Attribute. Das muss ganz anderes gelegen sein.
Nachdem ich FHEM neu gestartet hatte, wurden alle Verbraucher angezeigt.
Irgendetwas blockierte die Anzeige der Verbraucher. Alles andere wurde angezeigt.
Jetzt können wieder ohne Probleme die Verbraucher hinzugefügt werden.
Was mir noch aufgefallen ist, ist der Zeitraum 12 und 13Uhr wo alles bei den Batterien auf 0 ist.
Dann zeig mal bitte ein List deines SF Devices.
list AB_WS_SS
Internals:
CFGFN /media/hdd/fhem/myprogram/energiemanagement_rasp02.pm
FUUID 681a12bc-f33f-f4d2-bfda-4b4a7e77d485e542
FVERSION 76_SolarForecast.pm:v1.51.8-s29916/2025-05-02
LCACHEFILE last write time: 14:33:22 File: ./FHEM/FhemUtils/PVCsm_SolarForecast_AB_WS_SS
MODE Automatic / Event-controlled - next planned Cycletime: 14:38:55
MODEL OpenMeteoDWDEnsembleAPI
NAME AB_WS_SS
NOTIFYDEV HTZ_SDM630M_01,Daikin_WP,OG1_SDM120M_02D,Deye_12k,Deye_15k
NR 1918
NTFY_ORDER 50-AB_WS_SS
STATE updated
TYPE SolarForecast
WEATHERMODEL OpenMeteoDWDEnsembleAPI
eventCount 269
HELPER:
02M15DONE 1
03M15DONE 1
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV AB_WS_SS
SPGROOM
VERSION 1.51.8
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 24
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:1501
telnet telnetForBlockingFn_1747052685.61174_127.0.0.1_35304
terminated 1
timeout 30
abortArg:
arg:
block 1
name AB_WS_SS
tsnext 1747063338.45292
OLDREADINGS:
READINGS:
2025-05-12 14:38:06 Battery_ChargeRecommended_01 1
2025-05-12 14:38:06 Battery_ChargeRecommended_02 1
2025-05-12 14:38:06 Battery_ChargeRequest_01 0
2025-05-12 14:38:06 Battery_ChargeRequest_02 0
2025-05-12 14:38:06 Battery_NextHour00_SoCforecast_01 77.2 %
2025-05-12 14:38:06 Battery_NextHour00_SoCforecast_02 62.2 %
2025-05-12 14:38:06 Battery_NextHour01_SoCforecast_01 85.3 %
2025-05-12 14:38:06 Battery_NextHour01_SoCforecast_02 70.3 %
2025-05-12 14:38:06 Battery_NextHour02_SoCforecast_01 92.9 %
2025-05-12 14:38:06 Battery_NextHour02_SoCforecast_02 77.9 %
2025-05-12 14:38:06 Battery_NextHour03_SoCforecast_01 98.8 %
2025-05-12 14:38:06 Battery_NextHour03_SoCforecast_02 83.8 %
2025-05-12 14:38:06 Battery_NextHour04_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour04_SoCforecast_02 88.7 %
2025-05-12 14:38:06 Battery_NextHour05_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour05_SoCforecast_02 90.4 %
2025-05-12 14:38:06 Battery_NextHour06_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour06_SoCforecast_02 90.6 %
2025-05-12 14:38:06 Battery_NextHour07_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour07_SoCforecast_02 90.6 %
2025-05-12 14:38:06 Battery_NextHour08_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour08_SoCforecast_02 90.6 %
2025-05-12 14:38:06 Battery_NextHour09_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour09_SoCforecast_02 90.6 %
2025-05-12 14:38:06 Battery_NextHour10_SoCforecast_01 96.4 %
2025-05-12 14:38:06 Battery_NextHour10_SoCforecast_02 87.0 %
2025-05-12 14:38:06 Battery_NextHour11_SoCforecast_01 90.6 %
2025-05-12 14:38:06 Battery_NextHour11_SoCforecast_02 81.2 %
2025-05-12 14:38:06 Battery_NextHour12_SoCforecast_01 84.8 %
2025-05-12 14:38:06 Battery_NextHour12_SoCforecast_02 75.3 %
2025-05-12 14:38:06 Battery_NextHour13_SoCforecast_01 78.8 %
2025-05-12 14:38:06 Battery_NextHour13_SoCforecast_02 69.4 %
2025-05-12 14:38:06 Battery_NextHour14_SoCforecast_01 75.4 %
2025-05-12 14:38:06 Battery_NextHour14_SoCforecast_02 66.0 %
2025-05-12 14:38:06 Battery_NextHour15_SoCforecast_01 70.8 %
2025-05-12 14:38:06 Battery_NextHour15_SoCforecast_02 61.4 %
2025-05-12 14:38:06 Battery_NextHour16_SoCforecast_01 68.3 %
2025-05-12 14:38:06 Battery_NextHour16_SoCforecast_02 58.9 %
2025-05-12 14:38:06 Battery_NextHour17_SoCforecast_01 69.2 %
2025-05-12 14:38:06 Battery_NextHour17_SoCforecast_02 59.8 %
2025-05-12 14:38:06 Battery_NextHour18_SoCforecast_01 75.4 %
2025-05-12 14:38:06 Battery_NextHour18_SoCforecast_02 66.0 %
2025-05-12 14:38:06 Battery_NextHour19_SoCforecast_01 82.8 %
2025-05-12 14:38:06 Battery_NextHour19_SoCforecast_02 73.4 %
2025-05-12 14:38:06 Battery_NextHour20_SoCforecast_01 91.0 %
2025-05-12 14:38:06 Battery_NextHour20_SoCforecast_02 81.5 %
2025-05-12 14:38:06 Battery_NextHour21_SoCforecast_01 99.1 %
2025-05-12 14:38:06 Battery_NextHour21_SoCforecast_02 89.7 %
2025-05-12 14:38:06 Battery_NextHour22_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour22_SoCforecast_02 97.9 %
2025-05-12 14:38:06 Battery_NextHour23_SoCforecast_01 100.0 %
2025-05-12 14:38:06 Battery_NextHour23_SoCforecast_02 100.0 %
2025-05-12 14:38:06 Battery_OptimumTargetSoC_01 10 %
2025-05-12 14:38:06 Battery_OptimumTargetSoC_02 10 %
2025-05-12 14:38:06 Current_AutarkyRate 100 %
2025-05-12 14:38:06 Current_BatCharge_01 69 %
2025-05-12 14:38:06 Current_BatCharge_02 54 %
2025-05-12 14:38:06 Current_Consumption 3425 W
2025-05-12 14:38:06 Current_GridConsumption 0 W
2025-05-12 14:38:06 Current_GridFeedIn 115 W
2025-05-12 14:38:06 Current_PV 2890 W
2025-05-12 14:38:06 Current_PowerBatIn_01 0 W
2025-05-12 14:38:06 Current_PowerBatIn_02 0 W
2025-05-12 14:38:06 Current_PowerBatOut_01 330 W
2025-05-12 14:38:06 Current_PowerBatOut_02 320 W
2025-05-12 14:38:06 Current_SelfConsumption 2775 W
2025-05-12 14:38:06 Current_SelfConsumptionRate 96 %
2025-05-12 14:38:06 Current_Surplus 0 W
2025-05-12 14:00:00 LastHourGridconsumptionReal 0 Wh
2025-05-12 14:00:00 LastHourPVforecast 4360 Wh
2025-05-12 14:00:00 LastHourPVreal 0 Wh
2025-05-12 14:38:06 NextHours_Sum01_PVforecast 4360 Wh
2025-05-12 14:38:06 NextHours_Sum02_PVforecast 8497 Wh
2025-05-12 14:38:06 NextHours_Sum03_PVforecast 11941 Wh
2025-05-12 14:38:06 NextHours_Sum04_ConsumptionForecast 0 Wh
2025-05-12 14:38:06 NextHours_Sum04_PVforecast 14751 Wh
2025-05-12 14:38:06 RestOfDayConsumptionForecast 0 Wh
2025-05-12 14:38:06 RestOfDayPVforecast 16675 Wh
2025-05-12 00:59:54 Today_Hour01_BatIn_01 0 Wh
2025-05-12 00:59:54 Today_Hour01_BatIn_02 0 Wh
2025-05-12 00:59:54 Today_Hour01_BatOut_01 0 Wh
2025-05-12 00:59:54 Today_Hour01_BatOut_02 0 Wh
2025-05-12 00:59:54 Today_Hour01_GridConsumption 1537 Wh
2025-05-12 00:59:54 Today_Hour01_GridFeedIn 0 Wh
2025-05-12 00:59:54 Today_Hour01_PVreal 0 Wh
2025-05-12 01:59:53 Today_Hour02_BatIn_01 0 Wh
2025-05-12 01:59:53 Today_Hour02_BatIn_02 0 Wh
2025-05-12 01:59:53 Today_Hour02_BatOut_01 0 Wh
2025-05-12 01:59:53 Today_Hour02_BatOut_02 0 Wh
2025-05-12 01:59:53 Today_Hour02_GridConsumption 2512 Wh
2025-05-12 01:59:53 Today_Hour02_GridFeedIn 0 Wh
2025-05-12 01:59:53 Today_Hour02_PVreal 0 Wh
2025-05-12 02:59:54 Today_Hour03_BatIn_01 0 Wh
2025-05-12 02:59:54 Today_Hour03_BatIn_02 0 Wh
2025-05-12 02:59:54 Today_Hour03_BatOut_01 0 Wh
2025-05-12 02:59:54 Today_Hour03_BatOut_02 0 Wh
2025-05-12 02:59:54 Today_Hour03_GridConsumption 2531 Wh
2025-05-12 02:59:54 Today_Hour03_GridFeedIn 0 Wh
2025-05-12 02:59:54 Today_Hour03_PVreal 0 Wh
2025-05-12 03:59:55 Today_Hour04_BatIn_01 0 Wh
2025-05-12 03:59:55 Today_Hour04_BatIn_02 0 Wh
2025-05-12 03:59:55 Today_Hour04_BatOut_01 0 Wh
2025-05-12 03:59:55 Today_Hour04_BatOut_02 0 Wh
2025-05-12 03:59:55 Today_Hour04_GridConsumption 2563 Wh
2025-05-12 03:59:55 Today_Hour04_GridFeedIn 0 Wh
2025-05-12 03:59:55 Today_Hour04_PVreal 0 Wh
2025-05-12 04:59:56 Today_Hour05_BatIn_01 0 Wh
2025-05-12 04:59:56 Today_Hour05_BatIn_02 0 Wh
2025-05-12 04:59:56 Today_Hour05_BatOut_01 0 Wh
2025-05-12 04:59:56 Today_Hour05_BatOut_02 0 Wh
2025-05-12 04:59:56 Today_Hour05_GridConsumption 1475 Wh
2025-05-12 04:59:56 Today_Hour05_GridFeedIn 0 Wh
2025-05-12 04:59:56 Today_Hour05_PVreal 0 Wh
2025-05-12 05:59:57 Today_Hour06_BatIn_01 0 Wh
2025-05-12 05:59:57 Today_Hour06_BatIn_02 0 Wh
2025-05-12 05:59:57 Today_Hour06_BatOut_01 0 Wh
2025-05-12 05:59:57 Today_Hour06_BatOut_02 0 Wh
2025-05-12 05:59:57 Today_Hour06_GridConsumption 2131 Wh
2025-05-12 05:59:57 Today_Hour06_GridFeedIn 0 Wh
2025-05-12 05:59:57 Today_Hour06_PVforecast 152 Wh
2025-05-12 05:59:57 Today_Hour06_PVreal 0 Wh
2025-05-12 06:59:58 Today_Hour07_BatIn_01 0 Wh
2025-05-12 06:59:58 Today_Hour07_BatIn_02 0 Wh
2025-05-12 06:59:58 Today_Hour07_BatOut_01 0 Wh
2025-05-12 06:59:58 Today_Hour07_BatOut_02 0 Wh
2025-05-12 06:59:58 Today_Hour07_GridConsumption 1914 Wh
2025-05-12 06:59:58 Today_Hour07_GridFeedIn 0 Wh
2025-05-12 06:59:58 Today_Hour07_PVforecast 871 Wh
2025-05-12 06:59:58 Today_Hour07_PVreal 0 Wh
2025-05-12 07:59:58 Today_Hour08_BatIn_01 0 Wh
2025-05-12 07:59:58 Today_Hour08_BatIn_02 0 Wh
2025-05-12 07:59:58 Today_Hour08_BatOut_01 0 Wh
2025-05-12 07:59:58 Today_Hour08_BatOut_02 0 Wh
2025-05-12 07:59:58 Today_Hour08_GridConsumption 1593 Wh
2025-05-12 07:59:58 Today_Hour08_GridFeedIn 0 Wh
2025-05-12 07:59:58 Today_Hour08_PVforecast 2247 Wh
2025-05-12 07:59:58 Today_Hour08_PVreal 0 Wh
2025-05-12 08:59:52 Today_Hour09_BatIn_01 0 Wh
2025-05-12 08:59:52 Today_Hour09_BatIn_02 0 Wh
2025-05-12 08:59:52 Today_Hour09_BatOut_01 0 Wh
2025-05-12 08:59:52 Today_Hour09_BatOut_02 0 Wh
2025-05-12 08:59:52 Today_Hour09_GridConsumption 487 Wh
2025-05-12 08:59:52 Today_Hour09_GridFeedIn 0 Wh
2025-05-12 08:59:52 Today_Hour09_PVforecast 4127 Wh
2025-05-12 08:59:52 Today_Hour09_PVreal 0 Wh
2025-05-12 09:59:58 Today_Hour10_BatIn_01 0 Wh
2025-05-12 09:59:58 Today_Hour10_BatIn_02 0 Wh
2025-05-12 09:59:58 Today_Hour10_BatOut_01 0 Wh
2025-05-12 09:59:58 Today_Hour10_BatOut_02 0 Wh
2025-05-12 09:59:58 Today_Hour10_GridConsumption 525 Wh
2025-05-12 09:59:58 Today_Hour10_GridFeedIn 82 Wh
2025-05-12 09:59:58 Today_Hour10_PVforecast 4360 Wh
2025-05-12 09:59:58 Today_Hour10_PVreal 0 Wh
2025-05-12 10:59:58 Today_Hour11_BatIn_01 0 Wh
2025-05-12 10:59:58 Today_Hour11_BatIn_02 0 Wh
2025-05-12 10:59:58 Today_Hour11_BatOut_01 0 Wh
2025-05-12 10:59:58 Today_Hour11_BatOut_02 0 Wh
2025-05-12 10:59:58 Today_Hour11_GridConsumption 6 Wh
2025-05-12 10:59:58 Today_Hour11_GridFeedIn 187 Wh
2025-05-12 10:59:58 Today_Hour11_PVforecast 4360 Wh
2025-05-12 10:59:58 Today_Hour11_PVreal 0 Wh
2025-05-12 11:58:21 Today_Hour12_BatIn_01 0 Wh
2025-05-12 11:58:21 Today_Hour12_BatIn_02 0 Wh
2025-05-12 11:58:21 Today_Hour12_BatOut_01 0 Wh
2025-05-12 11:58:21 Today_Hour12_BatOut_02 0 Wh
2025-05-12 11:58:21 Today_Hour12_GridConsumption 0 Wh
2025-05-12 11:58:21 Today_Hour12_GridFeedIn 206 Wh
2025-05-12 11:58:21 Today_Hour12_PVforecast 4360 Wh
2025-05-12 11:58:21 Today_Hour12_PVreal 0 Wh
2025-05-12 11:58:21 Today_Hour13_PVforecast 4360 Wh
2025-05-12 11:58:21 Today_Hour14_PVforecast 4360 Wh
2025-05-12 14:38:06 Today_Hour15_BatIn_01 0 Wh
2025-05-12 14:38:06 Today_Hour15_BatIn_02 0 Wh
2025-05-12 14:38:06 Today_Hour15_BatOut_01 0 Wh
2025-05-12 14:38:06 Today_Hour15_BatOut_02 0 Wh
2025-05-12 14:38:06 Today_Hour15_GridConsumption 20 Wh
2025-05-12 14:38:06 Today_Hour15_GridFeedIn 369 Wh
2025-05-12 14:38:06 Today_Hour15_PVforecast 4360 Wh
2025-05-12 14:38:06 Today_Hour15_PVreal 0 Wh
2025-05-12 14:38:06 Today_Hour16_PVforecast 4360 Wh
2025-05-12 14:38:06 Today_Hour17_PVforecast 4017 Wh
2025-05-12 14:38:06 Today_Hour18_PVforecast 3136 Wh
2025-05-12 14:38:06 Today_Hour19_PVforecast 2635 Wh
2025-05-12 14:38:06 Today_Hour20_PVforecast 931 Wh
2025-05-12 14:38:06 Today_Hour21_PVforecast 70 Wh
2025-05-12 14:38:06 Today_MaxPVforecast 4360 Wh
2025-05-12 14:38:06 Today_MaxPVforecastTime 2025-05-12 09:00:00
2025-05-12 14:38:06 Today_PVforecast 48706 Wh
2025-05-12 14:38:06 Today_PVreal 0 Wh
2025-05-12 14:38:06 Today_SunRise 05:29
2025-05-12 14:38:06 Today_SunSet 20:32
2025-05-12 14:38:06 Tomorrow_ConsumptionForecast Warte auf weitere Tage mit einer Verbrauchszahl Wh
2025-05-12 14:38:06 Tomorrow_Hour01_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_Hour02_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_Hour03_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_Hour04_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_Hour05_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_Hour06_PVforecast 153 Wh
2025-05-12 14:38:06 Tomorrow_Hour07_PVforecast 831 Wh
2025-05-12 14:38:06 Tomorrow_Hour08_PVforecast 2051 Wh
2025-05-12 14:38:06 Tomorrow_Hour09_PVforecast 3820 Wh
2025-05-12 14:38:06 Tomorrow_Hour10_PVforecast 4360 Wh
2025-05-12 14:38:06 Tomorrow_Hour11_PVforecast 4360 Wh
2025-05-12 14:38:06 Tomorrow_Hour12_PVforecast 4360 Wh
2025-05-12 14:38:06 Tomorrow_Hour13_PVforecast 4360 Wh
2025-05-12 14:38:06 Tomorrow_Hour14_PVforecast 4360 Wh
2025-05-12 14:38:06 Tomorrow_Hour15_PVforecast 4360 Wh
2025-05-12 14:38:06 Tomorrow_Hour16_PVforecast 4360 Wh
2025-05-12 14:38:06 Tomorrow_Hour17_PVforecast 4022 Wh
2025-05-12 14:38:06 Tomorrow_Hour18_PVforecast 3139 Wh
2025-05-12 14:38:06 Tomorrow_Hour19_PVforecast 2685 Wh
2025-05-12 14:38:06 Tomorrow_Hour20_PVforecast 970 Wh
2025-05-12 14:38:06 Tomorrow_Hour21_PVforecast 82 Wh
2025-05-12 14:38:06 Tomorrow_Hour22_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_Hour23_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_Hour24_PVforecast 0 Wh
2025-05-12 14:38:06 Tomorrow_PVforecast 48273 Wh
2025-05-12 14:38:06 Tomorrow_SunRise 05:28
2025-05-12 14:38:06 Tomorrow_SunSet 20:33
2025-05-12 14:38:06 consumer01 name='Wärmepumpe' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-12 14:38:06 consumer01_currentPower 0 W
2025-05-12 14:38:06 consumer02 name='Geschirrspüler' state='unknown' mode='can' planningstate='planned'
2025-05-12 14:38:06 consumer02_planned_start 12.05.2025 16:00:00
2025-05-12 14:38:06 consumer02_planned_stop 12.05.2025 19:00:00
2025-05-12 14:38:06 consumer03 name='Geschirrspüler' state='unknown' mode='can' planningstate='planned'
2025-05-12 14:38:06 consumer03_planned_start 12.05.2025 16:00:00
2025-05-12 14:38:06 consumer03_planned_stop 12.05.2025 19:00:00
2025-05-12 14:37:46 nextCycletime 14:38:55
2025-05-12 14:25:18 nextRadiationAPICall nach 12.05.2025 14:40:18
2025-05-12 14:38:06 pvCorrectionFactor_Auto on_complex_ai
2025-05-12 14:38:07 state updated
Attributes:
aiControl aiTrainStart=2 aiStorageDuration=1825 aiTreesPV=10
alias AB Wetterstation - Solar Vorhersage
comment :
#
CO bis Sonnenuntergang:special_todayConForecastTillSunset
PV Übermorgen:special_dayAfterTomorrowPVforecast
consumer01 Daikin_WP:Wärmepumpe type=noSchedule power=8000 swstate=state:on:off asynchron=1 etotal=kWh_heating_day:kWh pcurr:HTZ_SDM630M_01:Active_Power_Total__W:W icon=sani_heating_heatpump
consumer02 OG1_SDM120M_02D:Geschirrspüler type=dishwasher mode=can power=0 pcurr:Active_Power__W:W on=on off=off notafter=20 swstate=state:on:off asynchron=1 icon=scene_dishwasher
consumer03 OG1_SDM120M_02D:Geschirrspüler type=dishwasher mode=can power=0 pcurr:Active_Power__W:W on=on off=off notafter=20 swstate=state:on:off asynchron=1 icon=scene_dishwasher
ctrlBatSocManagement01 lowSoc=10 upSoC=50 maxSoC=99 careCycle=25
ctrlBatSocManagement02 lowSoc=10 upSoC=50 maxSoC=99 careCycle=25
ctrlLanguage DE
ctrlNextDayForecastReadings 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24
ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
event-min-interval .*:1800
event-on-change-reading .*
flowGraphicControl animate=1 consumerdist=80 h2consumerdist=50 shiftx=0 shifty=0 showconsumer=1 showconsumerdummy=1 showconsumerpower=1 showconsumerremaintime=0 size=400 strokewidth=12
graphicBeam1Color 3C14FF
graphicBeam1Content pvReal
graphicBeam2Color 19FF29
graphicBeam2Content pvForecast
graphicBeam3Color D60924
graphicBeam3Content batsocCombi_02
graphicBeam3FontColor FFFF0D
graphicBeam4Color FFFF1F
graphicBeam4Content batsocCombi_01
graphicBeam4FontColor 000000
graphicBeamHeightLevel1 200
graphicBeamHeightLevel2 200
graphicControl beamWidth=40 energyUnit=kWh headerDetail=all hourCount=24 hourStyle=:00 layoutType=double spaceSize=24
graphicHeaderOwnspec #
AutarkyRate:Current_AutarkyRate
Überschuß:Current_Surplus
aktueller Netzbezug:Current_GridConsumption
:
#
:
:
:
:
#CO2 Einsparung
aktuelles Jahr:co2@CO2JD
letztes Jahr:co2@CO2JLD
:
:
#
:
:
:
:
#Inverter 1
Status:Betriebsstatus@Deye_12k
Leistung ∑:Inverter_Leistung_Gesamt__kW@Deye_12k
String 1:PV1_Leistung__W@Deye_12k
String 2:PV2_Leistung__W@Deye_12k
#Batterieeinheit 1
Energieladung heute:Akku_Energie_Ladung_Heute__kWh@Deye_12k
Energieentladung heute:Akku_Energie_Entladung_Heute__kWh@Deye_12k
:
:
#
:
:
:
:
#Inverter 2
Status:Betriebsstatus@Deye_15k
Leistung ∑:Inverter_Leistung_Gesamt__kW@Deye_15k
String 1:PV1_Leistung__W@Deye_15k
String 2:PV2_Leistung__W@Deye_15k
#Batterieeinheit 2
Energieladung heute:Akku_Energie_Ladung_Heute__kWh@Deye_15k
Energieentladung heute:Akku_Energie_Entladung_Heute__kWh@Deye_15k
:
:
#
:
:
:
:
#Settings
Autokorrektur:pvCorrectionFactor_Auto : : :
Consumer<br>Neuplanung:consumerNewPlanning : : :
Consumer<br>Sofortstart:consumerImmediatePlanning : : :
Wetter:graphicShowWeather : : :
History:graphicHistoryHour : : :
ShowNight:graphicShowNight : : :
Debug:ctrlDebug : : :
graphicHeaderOwnspecValForm {
'Akku_Energie_Ladung_Heute__kWh' => "(sprintf '%.1f kWh', ($VALUE))",
'Akku_Energie_Entladung_Heute__kWh' => "(sprintf '%.1f kWh', ($VALUE))",
'Inverter_Leistung_Gesamt__kW' => "(sprintf '%.1f kW', ($VALUE))",
'co2' => "(sprintf '%.1f Tonnen', ($VALUE))",
'PV1_Leistung__W' => "(sprintf '%.f W', ($VALUE))",
'PV2_Leistung__W' => "(sprintf '%.f W', ($VALUE))",
'Deye_12k.Betriebsstatus' => "($VALUE eq '1002' ? 'Online' : 'Offline')",
'Deye_15k.Betriebsstatus' => "($VALUE eq '1002' ? 'Online' : 'Offline')"
}
graphicHistoryHour 4
graphicSelect both
graphicShowDiff no
graphicShowNight 1
graphicShowWeather 1
graphicWeatherColor F0EC07
graphicWeatherColorNight CFD5FF
group Forecast
plantControl backupFilesKeep=3
batteryPreferredCharge=20
consForecastIdentWeekdays=1
consForecastLastDays=60
cycleInterval=70
feedinPowerLimit=0
genPVdeviation=continuously
showLink=1
room PV-Anlagen
setupBatteryDev01 Deye_12k pin=Akku_Leistung_BMS1__kW:kW pout=-pin intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh cap=24000 charge=Akku_SOC__KAP show=2:bottom icon=@grey:@#0CFB0C:@yellow:@red
setupBatteryDev02 Deye_15k pin=Akku_Leistung_BMS1__kW:kW pout=-pin intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh cap=24000 charge=Akku_SOC__KAP show=2:bottom icon=@grey:@#0CFB0C:@yellow:@red
setupInverterDev01 Deye_12k pv=PV1_Leistung__W:W etotal=PV1_Energie_Heute__kWh:kWh capacity=1960 strings=SüdOstdach asynchron=1 limit=100 icon=inverter@red:solar
setupInverterDev02 Deye_12k pv=PV2_Leistung__W:W etotal=PV2_Energie_Heute__kWh:kWh capacity=0.0 strings=SüdWestwand asynchron=1 limit=100 icon=inverter@red:solar
setupInverterDev03 Deye_15k pv=PV1_Leistung__W:W etotal=PV1_Energie_Heute__kWh:kWh capacity=2400 strings=SüdWestdach1 asynchron=1 limit=100 icon=inverter@red:solar
setupInverterDev04 Deye_15k pv=PV2_Leistung__W:W etotal=PV2_Energie_Heute__kWh:kWh capacity=0.0 strings=SüdWestdach2 asynchron=1 limit=100 icon=inverter@red:solar
setupInverterStrings SüdOstdach,SüdWestdach1,SüdWestdach2,SüdWestwand
setupMeterDev HTZ_SDM630M_01 gcon=Active_Power_Total__W:W contotal=Active_Energy_Imp_Total__kWh:kWh gfeedin=-gcon feedtotal=Active_Energy_Exp_Total__kWh:kWh conprice=0.0144:€ feedprice=0.0054:€
setupRadiationAPI OpenMeteoDWDEnsemble-API
setupStringAzimuth SüdOstdach=-28 SüdWestdach1=39 SüdWestdach2=39 SüdWestwand=52
setupStringDeclination SüdOstdach=48 SüdWestdach1=15 SüdWestdach2=15 SüdWestwand=90
setupStringPeak SüdOstdach=4.35 SüdWestdach1=6.6 SüdWestdach2=6.6 SüdWestwand=4.35
setupWeatherDev1 OpenMeteoDWDEnsemble-API
setupWeatherDev2 DWD
verbose 2
Stimmt, nichts verdächtiges zu entdecken.
Vielelicht der Browsercache gewesen?
Edit:
ZitatWas mir noch aufgefallen ist, ist der Zeitraum 12 und 13Uhr wo alles bei den Batterien auf 0 ist.
Dann wurden für die Zeit keine Daten der Bats gespeichert. Vllt. ein Hänger deines FHEM?
Laut Systemlast zu diesem Zeitpunkt war auch nichts auffälliges.
Es kann nur von FHEM selbst ein Fehler gewesen sein, denn den FireFox Browser hatte ich weiterhin am Laufen, und nachdem das System neu gestartet wurde war in der gleichen Browseransicht wieder alles da.
Was jedenfalls beim Errichten eines Verbrauchers (consumer) nicht geschah, war das die Readings consumerxx, consumerxx_currentPower, consumerxx_planned_start und consumerxx_planned_stop der hinzugefügten Geräte nicht ersichtlich waren. Für den einen schon länger vorhandenen Verbraucher waren diese Readings vorhanden. Diese Readings wurden durch löschen des Verbrauchers auch entfernt, nur bei einer neuerlichen Anlage erschienen diese Readings vorerst nicht. Nach dem Pi Neustart waren dann alle angelegten Verbraucher vorhanden.
Vielleicht waren es auch die vielen Test die ich mit diesem Modul gemacht hatte für FHEM zu viel.
Oder das war dann der FHEM-GEIST der hier zugeschlagen hatte.
ZitatWas jedenfalls beim Errichten eines Verbrauchers (consumer) nicht geschah, war das die Readings consumerxx, consumerxx_currentPower, consumerxx_planned_start und consumerxx_planned_stop der hinzugefügten Geräte nicht ersichtlich waren. Für den einen schon länger vorhandenen Verbraucher waren diese Readings vorhanden.
Das ist richtig so. Die kommen erst mit der Einplanung des Consumers und Folgeaktivitäten. Aternativ mit "set ... consumerImmediatePlanning / consumerNewPlanning ".
Nachdem in den letzten Tagen die Prognose bei mir recht konstant daneben lag (überschätzt) und ich heute mal durch's Dachfenster auf die Panele geschaut habe, ging mir durch den Kopf, ob der geringere Ertrag nicht durchaus auch prognostizierbar wäre: Denn nach mehreren Wochen ohne relevanten Niederschlag in Berlin liegt eine recht dicke Dreck/Staubschicht auf den Modulen, die den Ertrag entsprechend reduziert.
Der vom Modul prognostizierte Ertrag passt zu meinem Erwartungswert aus dem letzten Jahr - da hatte es nur vorher mal zur Reinigung geregnet.
Spielt Niederschlag (der Vergangenheit) bislang eine Rolle in der Prognose?
Gruß
Christian
Hallo Zusammen,
ich bin auch schon lange stiller Nutzer dieses Tools. Für meine Anlage funktioniert das ganze auch sehr zuverlässig.
Ich wollte nun aber mal überlegen, wie ich die Solaranlage mit einigen Panels auf der Garage noch erweitern kann.
Dazu habe ich mir 4 SF angelegt und in mit 1kW Peak in alle 4 Himmelsrichtungen Eingerichtet.
Reale Daten habe ich zu den Werten natürlich nicht, somit Funktioniert die Autokorrektur nicht.
Die Ergebnisse, welche ich erhalte, sind absolut unplausibel.
defmod SolarForecast_1kW_Sued SolarForecast
attr SolarForecast_1kW_Sued graphicHistoryHour 10
attr SolarForecast_1kW_Sued graphicSelect forecast
attr SolarForecast_1kW_Sued setupInverterDev01 Solar_1kWp pv=Solar_Leistung_Sued:W etotal=Energie_Sued:kWh capacity=1000
attr SolarForecast_1kW_Sued setupInverterStrings Sued
attr SolarForecast_1kW_Sued setupMeterDev Leistung_test gcon=Netzbezug:W contotal=Energie_Netzbezug:kWh gfeedin=Einspeisung_abs:W feedtotal=Energie_Einspeisung_abs:kWh
attr SolarForecast_1kW_Sued setupRadiationAPI DWD_Forecast
attr SolarForecast_1kW_Sued setupStringAzimuth Sued=0
attr SolarForecast_1kW_Sued setupStringDeclination Sued=45
attr SolarForecast_1kW_Sued setupStringPeak Sued=1
attr SolarForecast_1kW_Sued setupWeatherDev1 DWD_Forecast
für Nord habe ich nur eine andere StringDeclination gewählt.
defmod SolarForecast_1kW_Nord SolarForecast
attr SolarForecast_1kW_Nord graphicHistoryHour 10
attr SolarForecast_1kW_Nord graphicSelect forecast
attr SolarForecast_1kW_Nord setupInverterDev01 Solar_1kWp pv=Solar_Leistung_Nord:W etotal=Energie_Nord:kWh capacity=1000
attr SolarForecast_1kW_Nord setupInverterStrings Nord
attr SolarForecast_1kW_Nord setupMeterDev Leistung_test gcon=Netzbezug:W contotal=Energie_Netzbezug:kWh gfeedin=Einspeisung_abs:W feedtotal=Energie_Einspeisung_abs:kWh
attr SolarForecast_1kW_Nord setupRadiationAPI DWD_Forecast
attr SolarForecast_1kW_Nord setupStringAzimuth Nord=N
attr SolarForecast_1kW_Nord setupStringDeclination Nord=45
attr SolarForecast_1kW_Nord setupStringPeak Nord=1
attr SolarForecast_1kW_Nord setupWeatherDev1 DWD_Forecast
Wieso ist der Forecast für Nord höher als für Süd? Habe ich eine Fehler eingebaut? Gibt es Erfahrungen mit Anlagen, die nach Norden ausgerichtet sind?
Vielen Dank und Grüße
Kai
Hallo Christian,
sagen wir mal so, nicht der Niederschlag direkt, nur dessen Wirkung. D.h. unter sonst gleichen Bedingungen waren deine sauberen Platten leistungsstärker und das Ergebnis wurde gemerkt. Die Prognose unterstellt weiterhin diese Leistung und prognostiziert entsprechend.
Ist vllt. ein bisschen sehr theoretisch, aber eine naheliegende Schlußfolgerung.
Alte PV-Weisheit:
String-Nordausrichtung gibt im Sommer immer weniger Ertrag gegenüber der gleichen Anlage mit einer String-Südausrichtung. ;)
Im Winter kann es für die beiden Strings im Ertrag "gleichartiger" sein / werden. :o
Gruß
300P
Zitat von: Univega06 am 12 Mai 2025, 21:18:55Wieso ist der Forecast für Nord höher als für Süd? Habe ich eine Fehler eingebaut? Gibt es Erfahrungen mit Anlagen, die nach Norden ausgerichtet sind?
Neben meiner Weisheiten O:-)
- Warum / bzw. gibt es einen besonderen Grund warum :
1 x setupStringAzimuth ==>>> Sued=0 (statt beide mit dem Eintrag "S" und "N" ? )
1 x setupStringAzimuth ==>>> Nord=N (oder statt beide mit dem Eintrag "-180" unten "0" oben ?)
Das wäre das einzige was mir an Unterschieden dabei auffällt - die DWD-Daten sind ja gleich gewählt.
Gruß
300P
Zitat von: 300P am 12 Mai 2025, 21:25:00Alte PV-Weisheit:
String-Nordausrichtung gibt im Sommer immer weniger Ertrag gegenüber der gleichen Anlage mit einer String-Südausrichtung. ;)
Im Winter kann es für die beiden Strings im Ertrag "gleichartiger" sein / werden. :o
Gruß
300P
:o Soweit war ich auch schon, daher je die Feststellung das etwas nicht passt ;)
Zitat von: 300P am 12 Mai 2025, 21:39:59Zitat von: Univega06 am 12 Mai 2025, 21:18:55Wieso ist der Forecast für Nord höher als für Süd? Habe ich eine Fehler eingebaut? Gibt es Erfahrungen mit Anlagen, die nach Norden ausgerichtet sind?
Neben meiner Weisheiten O:-)
- Warum / bzw. gibt es einen besonderen Grund warum :
1 x setupStringAzimuth ==>>> Sued=0 (statt beide mit dem Eintrag "S" und "N" ? )
1 x setupStringAzimuth ==>>> Nord=N (oder statt beide mit dem Eintrag "-180" unten "0" oben ?)
Das wäre das einzige was mir an Unterschieden dabei auffällt - die DWD-Daten sind ja gleich gewählt.
Gruß
300P
Das kommt nur vom Probieren, ob einen Unterschied macht --> Macht es aber nicht
Danke und Grüße
Kai
Hallo Kai,
ich sehe bei dir keinen Fehler und habe deswegen bei mir zwei Instanzen nachgestellt.
Nordlage:
2025-05-12 22:23:31 Tomorrow_PVforecast 38161 Wh
2025-05-12 22:23:31 Tomorrow_SunRise 05:24
2025-05-12 22:23:31 Tomorrow_SunSet 20:52
2025-05-12 22:23:31 nextCycletime 22:24:06
2025-05-12 22:23:32 state updated
Attributes:
alias DWD Nordlage
ctrlDebug none
event-on-change-reading .*
graphicBeam1Color FF3636
graphicHeaderOwnspec Autokorrektur:pvCorrectionFactor_Auto
Debug:ctrlDebug
graphicHistoryHour 5
graphicShowNight 0
plantControl consForecastInPlanning=0
backupFilesKeep=3
cycleInterval=35
genPVdeviation=daily
room Energie->SolarVergleich
setupInverterDev01 STP_5000 pv=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100
setupInverterStrings Süddach
setupMeterDev SMA_Energymeter gcon=bezW:W contotal=bezWZ:kWh gfeedin=einW:W feedtotal=einWZ:kWh conprice=0.2958:€ feedprice=0.1269:€
setupRadiationAPI DWD.Solar.N5872
setupStringAzimuth Süddach=N
setupStringDeclination Süddach=45
setupStringPeak Süddach=5.0
setupWeatherDev1 DWD.Solar.N5872
verbose 2
Südlage:
2025-05-12 22:26:44 Tomorrow_PVforecast 43323 Wh
2025-05-12 22:26:44 Tomorrow_SunRise 05:24
2025-05-12 22:26:44 Tomorrow_SunSet 20:52
2025-05-12 22:26:44 nextCycletime 22:27:19
2025-05-12 22:26:45 state updated
Attributes:
alias DWD Südlage
ctrlDebug none
event-on-change-reading .*
graphicBeam1Color FF3636
graphicHeaderOwnspec Autokorrektur:pvCorrectionFactor_Auto
Debug:ctrlDebug
graphicHistoryHour 5
graphicShowNight 0
plantControl consForecastInPlanning=0
backupFilesKeep=3
cycleInterval=35
genPVdeviation=daily
room Energie->SolarVergleich
setupInverterDev01 STP_5000 pv=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1
setupInverterStrings Süddach
setupMeterDev SMA_Energymeter gcon=bezW:W contotal=bezWZ:kWh gfeedin=einW:W feedtotal=einWZ:kWh conprice=0.2958:€ feedprice=0.1269:€
setupRadiationAPI DWD.Solar.N5872
setupStringAzimuth Süddach=S
setupStringDeclination Süddach=45
setupStringPeak Süddach=5.0
setupWeatherDev1 DWD.Solar.N5872
verbose 2
Die beiden Instanzen sind bis auf die Ausrichtung identisch. Die Vorhersage für morgen (Tomorrow_PVforecast) erwartungsgemäß für Südlage höher (43323 Wh) als für Nordlage (38161 Wh). Alles ohne Korrekturfaktoren.
Die Grafiken zeigen auch entsprechende Ergebnisse.
Ich kann dir jetzt keine Erklärung für dein Ergebnis geben. Ich gehe davon aus, dass du die aktuellste Version benutzt?
EDIT: Du darfst für diesen Vergleich die Autokorrektur nicht setzen oder musst sie auf "off" schalten.
Grüße,
Heiko
@all,
die V 1.52.0 ist eingecheckt und wird morgen im Update enthalten sein.
Hallo Heiko,
das habe ich gerade ausprobiert:
Zitat von: DS_Starter am 11 Mai 2025, 20:31:09- Im Attr flowGraphicControl ist ein neuer Schlüssel "showGenerators" vorhanden um eine Reihe mit
PV-Zellen anzuzeigen sofern der WR Zellen zugeordnet hat.
Ein Mouse-Over zeigt die zugeordneten Strings.
Ich habe zwei Strings an meinem Wechselrichter.
Der Wechelrichter liefert mir für jeden der Strings Spannung und Strom. So berechne ich mir in UserReadings die (Schein-)Leistung.
Könntest Du die Konfiguration noch so erweitern, dass ich pro String eine [Device:]Reading-Kombination für die Leistung angeben kann?
Damit könnten dann die beiden zugeordneten Strings graphisch dargestellt werden.
Ich habe mal versucht, das in einem Fake-Screenshot anbei darzustellen.
Vielen Dank (für das Modul an sich und jedes Nachdenken über meine Ideen)!
Viele Grüße,
Peter
Edit: Hier mal eine Idee zur Umsetzung bei gleichzeitiger Zusammenfassung der attr setupStringXXX:
Bisher:
attr SolarForecast setupStringAzimuth Osten=-127 Westen=53
attr SolarForecast setupStringDeclination Osten=38 Westen=38
attr SolarForecast setupStringPeak Osten=4 Westen=6.4
Vorschlag:
attr SolarForecast setupStrings
Azimuth_Osten=-127 Azimuth_Westen=53
Declination_Osten=38 Declination_Westen=38
Peak_Osten=4 Peak_Westen=6.4
Power_Osten=SolarMax:LeistungString1 Power_Westen=SolarMax:LeistungString2 // Neu definierte Leistungsangaben
Ob das so technisch machbar und für Nutzer zu verstehen wäre?
Zitat von: peterboeckmann am 13 Mai 2025, 08:19:57Der Wechelrichter liefert mir für jeden der Strings Spannung und Strom. So berechne ich mir in UserReadings die (Schein-)Leistung.
Ich schließe mich dem an... Ich kann die Leistung der einzelnen Strings direkt ablesen.
Am Tablet zeige ich das u.a. z.B. wie im Screenshot.
Screenshot 2025-05-13 103107.png
Was mir aber noch aufgefallen ist:
Die Batterie speist jetzt immer in den Wechselrichter und von da zum "Haus". Formal und technisch ist das richtig, aber die untere Linie zum Haus wird nicht mehr verwendet und wenn man den neuen Schlüssel showGenerators nicht gesetzt hat, wird nicht mehr zwischen solar und Batterieleistung unterschieden. D.h. ich sehe nur noch die Summe?
Vielleicht habe ich auch was falsch eingestellt.
Zum Vergleich:
mit Schlüssel:
Screenshot 2025-05-13 103255.png
ohne Schlüssel:
Screenshot 2025-05-13 103449.png
"Früher" ging der Energiefluss von der Batterie zum Haus.
Danke und LG,
Tobias
Hallo zusammen,
@Peter,
dein Vorschlag ist gut und ich habe acuh schon über eine Zusamenfassung der String-Attribute nachgedacht. Allerdings ist es nicht so einfach, vor allem unter dem Aspekt unbekannte Anzahl Strings, deren Bezeichnungen und der Fehleranfälligkeit der Eingaben.
Deswegen gibt es auch grafisch im Flow nur die zusammengesetzte "Solarzelle". Es besteht die Herausforderung eine tendenziell unbekannte Anzahl zugeordneter Strings grafisch optimal über den bis zu X Invertern zu positionieren.
Deshalb vorerst nur so, auch wenn ich um die Schwäche dieser Ansicht weiß.
Aber über ein neue Struktur der Stringsattribute mache ich mir als erstes Gedanken. Das ist eine Grundlage für weitere Ausbauten.
@Tobias,
ZitatDie Batterie speist jetzt immer in den Wechselrichter und von da zum "Haus". Formal und technisch ist das richtig, aber die untere Linie zum Haus wird nicht mehr verwendet und wenn man den neuen Schlüssel showGenerators nicht gesetzt hat, wird nicht mehr zwischen solar und Batterieleistung unterschieden. D.h. ich sehe nur noch die Summe?
Vielleicht habe ich auch was falsch eingestellt.
Es ist alles richtig eingestellt. Wenn man nur einen WR hat, wird in der Flow der Knoten gespart, an dessen Stelle tritt der eine WR der dann auch die Summe aus PV und Batterie zusammenfügt. Das war mal ein Wunsch der User Platz zu sparen wenn es nur einen WR gibt und der Knoten quasi keine logische Funktion hat.
Vielleicht wäre es sinnvoll den Knoten immer anzuzeigen, das würde mir das Leben auch leichter machen. Da nehme ich eure Meinungen gern entgegen.
Ggf. wäre im simpelsten Fall mit nur einem WR und nichts weiter die Knotenebene etwas zuviel aber damit kann man sicherlich auch leben?
Zitat"Früher" ging der Energiefluss von der Batterie zum Haus.
Das sollte jetzt nicht mehr so sein, außer in dem Fall wenn die Batterie aus dem Hausnetz direkt geladen wird und man keinen reinen Batteriewechselrichter, der diese Funktion übernimmt, per Attribut implementiert hat.
LG,
Heiko
Zitat von: DS_Starter am 13 Mai 2025, 11:17:49dein Vorschlag ist gut und ich habe acuh schon über eine Zusamenfassung der String-Attribute nachgedacht. Allerdings ist es nicht so einfach, vor allem unter dem Aspekt unbekannte Anzahl Strings, deren Bezeichnungen und der Fehleranfälligkeit der Eingaben.
Deswegen gibt es auch grafisch im Flow nur die zusammengesetzte "Solarzelle". Es besteht die Herausforderung eine tendenziell unbekannte Anzahl zugeordneter Strings grafisch optimal über den bis zu X Invertern zu positionieren.
Deshalb vorerst nur so, auch wenn ich um die Schwäche dieser Ansicht weiß.
Aber über ein neue Struktur der Stringsattribute mache ich mir als erstes Gedanken. Das ist eine Grundlage für weitere Ausbauten.
Das würde/wird dann z.B. bei mir ganz schön anstrengend werden die vernünftig darzustellen:
3 WR / 2 x 2 Strings / 1 x 3 String ;)
Gott sei Dank ist die Brennstoffzelle inzwischen bei mir schon mal weggefallen O:-)
Gruß
300P
Genau deswegen ;)
Zitat von: 300P am 13 Mai 2025, 11:37:41Das würde/wird dann z.B. bei mir ganz schön anstrengend werden die vernünftig darzustellen:
3 WR / 2 x 2 Strings / 1 x 3 String
Das sehe ich ein. Zumal dann, wenn man die einzelnen Leistungen nicht abbilden kann oder möchte.
@Heiko:
Vielleicht ist die Konfiguration der Strings weniger fehleranfällig, wenn sie amalog zu den Verbrauchern erfolgt?
attr setupString01...
attr setupString02...
etc.
ZitatVielleicht ist die Konfiguration der Strings weniger fehleranfällig, wenn sie amalog zu den Verbrauchern erfolgt?
Ja, allerdings habe ich die max. Anzahl Consumer vorgegeben und ich weiß was mich max. erwartet. Bei den Strings ist der User frei.
Eine Unbekannte für mich. Ich könnte sie beschneiden, möchte ich aber nicht. (Aber vllt. nicht zu umgehen, mal sehen)
Dann steht die Frage im Raum wieviel man max. braucht, 10 Strings vllt.? Keine Ahnung was es so allgemein gibt.
Zitat von: DS_Starter am 13 Mai 2025, 11:17:49Das sollte jetzt nicht mehr so sein, außer in dem Fall wenn die Batterie aus dem Hausnetz direkt geladen wird und man keinen reinen Batteriewechselrichter, der diese Funktion übernimmt, per Attribut implementiert hat.
Ja, genau. Mein "Problem":
- die untere Flusslinie zwischen Batterie und Haus wird nicht mehr verwndet aber dennoch angezeigt.
- ohne showGenerators sehe ich nur eine Sonne als WR und da nur die Summe der Leistung aus Batterie und Solar. Was der WR halt gerade an Leistung ausgibt. Aber die reine solarpower wird nur mit showGenerators angezeigt.
Das fand ich vorher übersichtlicher und schöner (beides etwas subjektiv). Da war ich mir nicht sicher ob das so gewollt ist... Aber Falls ja, baue ich mir meinen Weg drumrum...
[EDIT]: Man müsste/könnte die Batterie(n) dann auch oben wie die Strings als Eingangsgröße für den WR hinsetzen. Sind ja aus Sicht WR dann auch Erzeuger (und "Verbraucher" in die andere Richtung).
Hallo Heiko,
Zitat von: DS_Starter am 13 Mai 2025, 11:48:23Dann steht die Frage im Raum wieviel man max. braucht, 10 Strings vllt.? Keine Ahnung was es so allgemein gibt.
aus Symmetriegründen wurde ich 16 vorschlagen, wie bei den Verbrauchern.
Also, falls du dich für die Begrenzung entscheidest.
Viele Grüße,
Peter
@Tobias,
schau mal im Anhang. So sähe es "normalerweise" aus wenn ich nicht künstlich den Knoten sparen würde. Mit und ohne Batterie-Wechselrichter.
Das wäre m.M. nach besser und für mich auch einfacher in Zukunft. Braucht halt etwas mehr Platz. Die Stringebene kann man ausblende, dadurch ändert sich nichts am grundlegenden Aufbau.
Ich habe noch ein Paar Fragen zur Visualisierung.
Im Anhang habe ich eine Übersicht zusammengestellt, wie die Energieflüsse bei mir sind. Ich weis es ist betreffend Hybridinverter noch nichts fertig, aber vieleicht habe ich einen Denkfehler bei der Visualisierung der Stromflüsse. ÜberscihtIst.png ist die aktuelle Ansicht der Konfiguartion.
Bei den Verbrauchern habe ich jedenfalls einen Konfigurationsfehler, und komme nicht darauf woran es liegt.
Es wird kein Stromfluss, kein Status und kein Verbrauch angezeigt.
ZB: Wärmepumpe der mittels Dummy eingebunden wird.
list HZG_WPD
Internals:
CFGFN /media/hdd/fhem/myprogram/energiemanagement_rasp02.pm
FUUID 6822145f-f33f-f4d2-a327-12d2bcbaa47ad659
NAME HZG_WPD
NR 1922
STATE
<b>
<br>
<span style='color:#00FFFF'>Verbrauch aktueller<span style='color:transparent'>..............<span style='color:#00FFFF'>26.2 W
<br>
<span style='color:#C90076'>Verbrauch Energie heute<span style='color:transparent'>......<span style='color:#C90076'>-2940.611 kWh
<br>
</b></span>
TYPE dummy
eventCount 1083
READINGS:
2025-05-13 12:01:03 Active_Energy_Day__kWh -2940.611
2025-05-13 12:01:03 Active_Power__W 26.2
2025-05-13 12:01:03 state EIN
Attributes:
alias AP Garage Ost - Heizung - Wärmepumpe
cmdIcon EIN:remotecontrol/black_btn_GREEN AUS:remotecontrol/black_btn_RED
devStateIcon EIN:sani_heating_heatpump@0CFB0C AUS:sani_heating_heatpump@gray
devStateStyle style="text-align:left;;font-weight:bold;;"
icon sani_heating_heatpump
room Energiemanagement,Heizung
stateFormat {
my $ap=ReadingsNum($name,'Active_Power__W',0);
my $aed=ReadingsNum($name,'Active_Energy_Day__kWh',0);
"
<b>
<br>
<span style='color:#00FFFF'>Verbrauch aktueller<span style='color:transparent'>..............<span style='color:#00FFFF'>$ap W
<br>
<span style='color:#C90076'>Verbrauch Energie heute<span style='color:transparent'>......<span style='color:#C90076'>$aed kWh
<br>
</b></span>
"
}
webCmd ::EIN:AUS
Forecast Definition Wärmepumpe consumer01
HZG_WPD:Wärmepumpe type=noSchedule icon=sani_heating_heatpump
power=0 pcurr:Active_Power__W:W etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=0
asynchron=1
Forecast Reading consumer02
.........
consumer01 name='Wärmepumpe' state='on' mode='can' planningstate='noSchedule' 2025-05-13 12:02:11
consumer01_currentPower 0 W 2025-05-13 12:02:11
......
Aus irgendeinen Grund ändert sich der aktuelle Zustand nicht. Auch die Werte der Readings Active_Power__W und Active_Energy_Day__kWh aus dem Dummy werden nicht übernommen. etotal=Active_Energy_Day__kWh:kWh fehlt zur Gänze.
@Chris,
die Inverterdefinition ist nicht richtig. Du hast sicherlich feed=bat gesetzt, was einen Batteriewechselrichter kennzeichnet. Außerdem müsstest du die jeweils 2 Strings den 2 WR zuweisen (nicht 4 PV-WR). Zukünftig wird es ein feed=hybrid geben um Hybridwechselrichter zu implementieren.
Für eine Übergangszeit könntest du zusätzliche reine Batteriewechselrichter versuchen einzubauen um die Flüsse von/zu den Batterien nachzubilden. Die Batterien werden generell als Batteriepack dargestellt, nicht einzeln an den WR.
Bzgl. Consumer liegt das Problem wahrscheinlich in zwei Fehlern:
- Active_Energy_Day__kWh -2940.611 hat einen negativen Verbrauchswert -> soll positiv sein (negativer Verbrauch wäre für mich "Erzeugung")
- Syntaxfehler pcurr:Active_Power__W:W -> pcurr=Active_Power__W:W
Grüße,
Heiko
Dummer Sysntax-Fehler.
Das mit dem feed=bat stimmt. Ich wollte nur sehen ob sich da schon etwas geändert hat.
Die Syntax für zwei Strings pro Wechselrichter habe ich noch nicht verstanden wie diese aussehen sollte.
Deye_12k strings=SüdOstDach,SüdWestWand icon=inverter@red:solar capacity=1960
pv=PV1_Leistung__W,PV2_Leistung__W:W etotal=PV1_Energie_Heute__kWh,PV2_Energie_Heute__kWh:kWh
asynchron=1
limit=100
Beim Parameter string ist es klar strings=SüdOstDach,SüdWestWand aber wie gehe ich mit den Leistungswerten der einzelnen Strings um.
Der Parameter capacity ist auch klar das ich hier beide Strings summmieren muss. Das ergibt aber ein Problem wenn die Strings unterschiedliche Leistungen bzw. Ausrichtung haben.
Oder es sind Verschattungen gegeben, wie es bei mir bei SüdWestDach1 und SüdWestDach2 mit untergehender Sonne geschieht.
Bei Active_Energy_Day__kWh -2940.611 hatte ich den falschen Wert herangezogen, aber es kann sein das die Eastronzähler 0.0 oder -0.0 anzeigen wenn zB. die Waschmaschine nicht läuft.
Da muss ich mir beim Dummy noch etwas einfallen lassen.
ZitatBeim Parameter string ist es klar strings=SüdOstDach,SüdWestWand aber wie gehe ich mit den Leistungswerten der einzelnen Strings um.
Der Parameter capacity ist auch klar das ich hier beide Strings summmieren muss. Das ergibt aber ein Problem wenn die Strings unterschiedliche Leistungen bzw. Ausrichtung haben.
Oder es sind Verschattungen gegeben, wie es bei mir bei SüdWestDach1 und SüdWestDach2 mit untergehender Sonne geschieht.
Die Strings werden einzeln gerechnet bzw. über die API abgefragt um die Lage/Ausrichtung/Stringleistung spezifisch für den String zu berücksichtigen. Die ermittelten Leistungsprognosen wird dann ggf. mit gelernten Korrekturfaktoren und/oder KI-Prognosen bewertet. Daraus ergibt sich eine Summe die <= dem capacity Wert sein muß sonst wird sie gekappt. capacity hat in diesem Kontext lediglich die Funktion einer worst case Begrenzung nach oben, alles andere obliegt den beschriebenen Mechanismen.
Zitat von: Burny4600 am 13 Mai 2025, 13:37:57Die Syntax für zwei Strings pro Wechselrichter habe ich noch nicht verstanden wie diese aussehen sollte.
Deye_12k strings=SüdOstDach,SüdWestWand icon=inverter@red:solar capacity=1960
pv=PV1_Leistung__W,PV2_Leistung__W:W etotal=PV1_Energie_Heute__kWh,PV2_Energie_Heute__kWh:kWh
asynchron=1
limit=100
Beim Parameter string ist es klar strings=SüdOstDach,SüdWestWand aber wie gehe ich mit den Leistungswerten der einzelnen Strings um.
Der Parameter capacity ist auch klar das ich hier beide Strings summmieren muss. Das ergibt aber ein Problem wenn die Strings unterschiedliche Leistungen bzw. Ausrichtung haben.
Oder es sind Verschattungen gegeben, wie es bei mir bei SüdWestDach1 und SüdWestDach2 mit untergehender Sonne geschieht.
Hier zur Erklärung mein SB40 (mit 3 Strings - aufgeteilt wegen der verschiedenen sich ergebenden Verschattung.
Vielleicht wird es dadurch klarer:
max. Leistung WR = 4000 W
String HausSE1 = 2.100 kWp
String HausSE2 = 2.100 kWp
String HausSW = 2.230 kWp
==========================
Summe aller Strings = 6.430 kWp
==> unter dem erlaubten Summenwert aller angeschlossenen Strings des WR soweit ich es kenne
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=100 asynchron=0
attr Forecast setupStringAzimuth GarageSE=-55 GarageNW=135 HausNW=135 HausSW=35 HausSE1=-55 HausSE2=-55
attr Forecast setupStringDeclination GarageSE=38 GarageNW=38 HausNW=48 HausSW=48 HausSE1=48 HausSE2=48
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.100 HausSE2=2.100
aGruß
300P
Das ergibt dann am Wechselrichter diese meßbaren 2 wirklichen Strings:
(siehe Screenshot1)
Aber beim SB40 auf der Phase 3 dann (max 4 kw):
(siehe Screenshot2)
Und die fasst in einem Unterprogram die 3 Strings zusammen woraus sich dann ein total_pac und etotal für die 3 Strings ergibt.
In SF werden die Einzelanteile der angeschlossenen und berechneten Strings in eine resultierende Gesamtsumme für die Prognose zusammengefasst.
total_pac und etotal ist ja der gemessene/gelieferte Output des WR und aus Sicht des Moduls unabhängig davon welche Strings angeschlossen sind.
EDIT: @Chris, gerade gesehen: "pv=PV1_Leistung__W,PV2_Leistung__W:W etotal=PV1_Energie_Heute__kWh,PV2_Energie_Heute__kWh:kWh" ist falsch. Nur "pv=total_pac:W etotal=etotal:kWh". d.h. die aktuelle Leistung des WR -> Hausnetz und seine gesamte kumulierte erzeugte Energie.
Irgendwie stehe ich jetzt daneben.
Grundsätzlich ergeben sich die Leistung bei meinem Hybridinverter so.
DC-PV + DC-Batterie entspricht ungefähr AC-Last + AC UPS
setupInverterDevXX
pv=total_pac:W entspricht der Summe PV1-Leistung + PV2-Leistung = PV_Leistung__W
etotal=etotal:kWh entspricht (Summe Last-Leistung + Summe UPS-Leistung) pro Stunde = SV_USV_Energie__kWh
Ist etotal ein umuliert Wert für Stunden oder Tag? Wenn ja, dann muss ich den berechnen, da der Inverter keine kWh für Last und UPS ausgibt.
Ist ein aufsteigender Zähler
Also muss ich diesen Wert erst ermitteln.
Der Inverter hat zwei Strings
Deye_12k_StringD strings=SüdOstDach,SüdWestWand icon=inverter@red:solar capacity=8700
pv=PV_Leistung__W:W etotal=SV_USV_Energie__kWh:kWh
asynchron=0
limit=100
Ich hoffe ich habs kappiert. Morgen gehts weiter.
Hallo Heiko,
in v1.52.0 scheint sich ein Fehler eingeschlichen zu haben.
Im Screenshot anbei bewegt sich der Balken vom Speicher zum Wechselrichter. Aktuell werden dort 2500 W aus der Batterie geliefert.
Vor der v1.52.0 war da der Fluss doch zum Haus, oder?
Siehe auch die Erzeugung aktuell im Screenshot oben im graphicHeader.
Viele Grüße,
Peter
Hallo Peter,
nein, ist kein Fehler. Hatte Tobias schon "bemängelt". Lies mal #2824 ff.
Bei euch fehlt der Inverterknoten weil ihr nur einen WR habt.
Ich überlege schon ob ich diese Darstellung nur dann anwende wenn es keine Batterie gibt, also quasi nur bei der absoluten Minimalvariante.
Bei größeren Anlagen wird das System deutlicher (SC2).
Ja - wer die historische Entwicklung des Modules nicht im Kopf hat der stutzt da etwas bei Darstellung von ,,kleinen" Anlagen... ;)
Zitat von: DS_Starter am 13 Mai 2025, 15:08:48..........
"pv=total_pac:W etotal=etotal:kWh". d.h. die aktuelle Leistung des WR -> Hausnetz und seine gesamte kumulierte erzeugte Energie.
Das steht als Erläuterung beim Inverter aber anders.
pv Ein Reading, welches die [b]aktuelle PV-Leistung[/b] als positiven Wert liefert.
etotal Das Reading, welches die [b]gesamte erzeugte PV-Energie[/b] liefert (ein stetig aufsteigender Zähler).Ich gebs heute auf.
Was genau ist unverständlich? vllt. muß ich es besser schreiben.
Der Stand ist immer noch ohne Hybrid. Nicht vergessen.
Vllt so eindeutiger:
pv Ein Reading welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz geliefert wird, bereitstellt. Es muß ein positiver Wert sein.
etotal Das Reading, welches die gesamte erzeugte PV-Energie liefert (ein stetig aufsteigender Zähler). -> hier sehe ich keinen Unterschied zu "gesamte kumulierte erzeugte Energie". Erzeugt die Definition Fragen im Kopf und gibt Raum für Spekulation?
@all,
der Knoten in der Flußgrafik wird nun nur bei der absoluten Minimalvariante mit nur einem WR und keiner installierten Batterie ausgeblendet.
Bei allen anderen komplexeren Installation wird er eingeblendet. Dadurch werden die beschriebenen Irritationen vermieden und nebenbei ist es auch für mich leichter weitere Entwicklungen in die Flußgrafik einzubauen (z.B. Hybridwechselrichter).
Die V 1.52.1 liegt im contrib, vllt. kommt noch etwas hinzu.
LG,
Heiko
Zitat von: DS_Starter am 13 Mai 2025, 11:48:23Dann steht die Frage im Raum wieviel man max. braucht, 10 Strings vllt.? Keine Ahnung was es so allgemein gibt.
Hallo Heiko,
Strings ist das eine - bei Consumer-WR gibt es nach meinem Wissenstand zwischen 1 und 6 Anschlussmöglichkeiten(Strings).
Aber selten mehr als 2 MPP. MPP sind nach meinem Verständnis das Maßgebende Faktum. Denn der MPP 'sucht' den optimalen Betriebspunkt für die zugeordneten Strings.
Zitat von: DS_Starter am 13 Mai 2025, 15:08:48In SF werden die Einzelanteile der angeschlossenen und berechneten Strings in eine resultierende Gesamtsumme für die Prognose zusammengefasst.
total_pac und etotal ist ja der gemessene/gelieferte Output des WR und aus Sicht des Moduls unabhängig davon welche Strings angeschlossen sind.
Da stellt sich mir die Frage ob die Angabe der Strings überhaupt notwendig ist? - ohne würde die Einrichtung einer neuen Anlage vereinfachen? - außer für die Optik.
für die Optik wäre es allerdings schön die Strings einzeln zu sehen (beigefügte Foto-Montage)
Dann hätte ich mal eine Frage zur Autarkie (Current_AutarkyRate) es sieht so aus als würde hier der Augenblickswert herangezogen und manchmal fehlt irgendetwas um die Current_AutarkyRate wieder zurück zu setzten. Habe mal für einen sonnigen Tag den Netzbezug und die Current_AutarkyRate gegenüber gestellt (screen 2) ist das erklärbar?
Gruß Gerd
Toll, jetzt hat es mich nach dem Update auch bei zwei im Freundeskreis betreuten Hybrid-Anlagen erwischt, Stromfluss von der Batterie, zur Sonne, dann zurück zum Haus. Die meisten User werden so eine Minimalkonfiguration haben. Wie soll ich das jetzt wieder den Nutzern (einer ist stolze 81 Jahre alt und total fit) wieder erklären...
Gruß aus Leipzig!
Peter
Hallo Peter,
erstens ist das nicht falsch ... die Energie von der Bat läuft über den (Hybrid)Wechselrichter in das Hausnetz.
Außerdem siehe 2 Posts höher gibt es schon einen Nachtrag.
Leute - haltet doch bitte den Ball flach wenn's mal nicht sofort wieder so ist wie man es erwartet.
Das ist ganz und gar freiwillig was DS_Starter an Zeit da in das großartige Projekt einbringt.
Außerdem hat er doch bislang immer einen Weg gefunden all unsere Anliegen und Wünsche dann doch wieder - soweit möglich -einzubringen.
Bei großen Firmen heißt es dann einfach das die Umsetzung eine Vorgabe zur zukünftigen Weiterentwicklung ist, unabwendbar für die zukünftige Nutzung so ausgeführt wurde und deshalb auch so ausgerollt werden muss.....blablabla...und man wartet monatelang auf die dann versprochene Optimierung des Systems.... O:-)
Hi Heiko,
ja, mag sein, Post hatte ich auch gelesen. Aber in der Grafik liefert jetzt auch der Mond PV Energie ganz oben in der Grafik.
Hallo Gerd,
ZitatDa stellt sich mir die Frage ob die Angabe der Strings überhaupt notwendig ist? - ohne würde die Einrichtung einer neuen Anlage vereinfachen? - außer für die Optik.
Außer Ungenauigkeiten der API/KI-Prognose gibt es nicht selten den Fall dass die installierte WR-Leistung kleiner ist als die verbaute Stringleistung. Auch in diesen Fällen ist die max. Leistung zu begrenzen. Dazu nutze ich die zugeordneten Strings.
https://www.solario24.com/de/ratgeber/wechselrichter-kleiner-als-modulleistung-es-kann-die-bessere-wahl-sein?srsltid=AfmBOoqsiK6YFOTFQkg0nM0SYb2qcXy1uau28AFZVzTI9x_HE6TFH5eQ
Zitatfür die Optik wäre es allerdings schön die Strings einzeln zu sehen (beigefügte Foto-Montage)
Ja, ich weiß. Wie schon geschrieben ist es nicht ganz so trivial umzusetzen. Vllt. hat kask eine gute Idee, er hatte mir in der Vergangenheit schon gute Zuarbeiten für die Grafik geliefert. :)
ZitatDann hätte ich mal eine Frage zur Autarkie (Current_AutarkyRate) es sieht so aus als würde hier der Augenblickswert herangezogen und manchmal fehlt irgendetwas um die Current_AutarkyRate wieder zurück zu setzten. Habe mal für einen sonnigen Tag den Netzbezug und die Current_AutarkyRate gegenüber gestellt (screen 2) ist das erklärbar?
Die Autarkierate im Readings ist der aktuelle Wert, deswegen Current_ ;).
Die Autarkierate berechnet sich aus verschiedenen Werten der PV Erzeugung, Batterie-In/Out, Netzbezug usw.
Nun liefern die Geräte in FHEM nicht synchron ihre Werte, zu unterschiedlich arbeiten die verwendeten Gerätemodule. So kann es sein dass der Verbrauch kurz negativ wird oder ähnliche Dinge. Das hat dann Einfluß auch auf ein solches Reading.
ZitatAber in der Grafik liefert jetzt auch der Mond PV Energie ganz oben in der Grafik.
Schau mal, mit der V 1.52.1 ist das nicht der Fall. (Anhang)
Zitat von: DS_Starter am 13 Mai 2025, 12:04:25@Tobias,
schau mal im Anhang. So sähe es "normalerweise" aus wenn ich nicht künstlich den Knoten sparen würde. Mit und ohne Batterie-Wechselrichter.
Das wäre m.M. nach besser und für mich auch einfacher in Zukunft. Braucht halt etwas mehr Platz. Die Stringebene kann man ausblende, dadurch ändert sich nichts am grundlegenden Aufbau.
Ja, soweit verstanden. Das spart Platz in der Ansicht und ist bei einer Konfiguration mit nur einem WR und nur einer Batterie durchaus gut - war es vorher auch schon.
Bindet man den Knoten ein braucht man etwas merh Platz, hat aber eine realistischere Darstellung.
Das Problem bei der aktuellen Variante:
Der Energiefluss Batterie - Haus ist obsolete, da die Batterie immer entweder den Knoten selbst oder einen Wechselrichter speist und somit der untere Ernegiefluss einfach grau daher kommt.
Werden die PV strings nicht angezeigt, zeigt der Knoten die Summe aus PV und Batterie (wie es beim Laden ausschaut habe ich jetzt nicht probiert...), aber nicht separat die eigentliche Leistung aus den Modulen (siehe Screenshot) 7330 W powert der Wechselrichter ins Haus, 3633 W davon zieht er von der Batterie. Die Solarleistung muss ich mir selbst ausrechnen ;)
Screenshot 2025-05-13 103449.png
Aber wem erkläre ich das... ;D
Jedenfalls habe ich jetz die Variante inkl. PV-Strings gewählt, was für mich gut ausschaut, auch wenn ich auf den ersten flüchtigen Blick nicht sehe, ob die Batterie gerade geladen oder entladen wird.
Aber dennoch die Frage: Wofür ist in der aktuellen Variante der Energieflusspfeil zwischen Batterie und Haus gedacht (siehe Screenshot)? Der wird doch in diesere Konfiguration nie bedient?
Screenshot 2025-05-13 210302.png
LG, Tobi
@Peter: Was heißt denn erwischt. Erwischen wird das jeden, der das Update einspielt. Aber es erwischt einen ja nicht kalt und obendrauf gibt es noch 1:1 Entwickersupport mit Reaktionszeiten von der jede Service-Abteiluing nur träumen kann. ;D Das Feature bzw. Verhalten war ja angekündigt - vielleicht nicht im letzten Detail. Aber über oranges Briefumschlagsymbol und verlinktem Post wesentlich detaillierter als irgendwo sonst. Find das insgesamt Wahnsinn, wieviel Aufwand Heiko nicht nur ins Modul, sondern die Doku und zudem die Fragen der Anwender steckt.
Hallo Heiko,
danke für den schnellen Fix.
Gruß,
Heiko
Hallo Tobi,
ZitatAber dennoch die Frage: Wofür ist in der aktuellen Variante der Energieflusspfeil zwischen Batterie und Haus gedacht (siehe Screenshot)? Der wird doch in diesere Konfiguration nie bedient?
Ich sehe deine Anhänge noch nicht, aber ich weiß was du meinst.
Zur Zeit braucht es diese Verbindung nur noch, wenn die Batterie aus dem öffentlichen Grid (über das Hausnetz) zwangsbeladen wird. Z.B. im Winter ohne PV und die Bat sinkt unter den Min-SOC. Vermutlich werde ich es auch noch hinbekommen auch diesen Fluß über den Inverterknoten laufen zu lassen, er wird ja an V 1.52.1 immer verfügbar sein wenn eine Batterie installiert ist.
Dann ist diese Verbindung obsolet. Wir können uns dann ja überlegen ob die graue Verbindung wegen der Symmetrie für das Auge dennoch drin bleiben soll/kann. ;)
Zitat von: DS_Starter am 13 Mai 2025, 21:15:24Die Autarkierate im Readings ist der aktuelle Wert, deswegen Current_ ;).
Die Autarkierate berechnet sich aus verschiedenen Werten der PV Erzeugung, Batterie-In/Out, Netzbezug usw.
Nun liefern die Geräte in FHEM nicht synchron ihre Werte, zu unterschiedlich arbeiten die verwendeten Gerätemodule. So kann es sein dass der Verbrauch kurz negativ wird oder ähnliche Dinge. Das hat dann Einfluß auch auf ein solches Reading.
@Heiko,
vielen Dank für die schnelle Antwort - ja das erklärt die Kurve
Gruß Gerd
@all,
die V 1.52.1 mit der Änderung bzgl. Flußgrafik habe ich soeben eingecheckt.
Ist dann morgen früh im Update enthalten.
Grüße,
Heiko
Zitat von: DS_Starter am 13 Mai 2025, 21:36:25Hallo Tobi,
ZitatAber dennoch die Frage: Wofür ist in der aktuellen Variante der Energieflusspfeil zwischen Batterie und Haus gedacht (siehe Screenshot)? Der wird doch in diesere Konfiguration nie bedient?
Ich sehe deine Anhänge noch nicht, aber ich weiß was du meinst.
Zur Zeit braucht es diese Verbindung nur noch, wenn die Batterie aus dem öffentlichen Grid (über das Hausnetz) zwangsbeladen wird. Z.B. im Winter ohne PV und die Bat sinkt unter den Min-SOC. Vermutlich werde ich es auch noch hinbekommen auch diesen Fluß über den Inverterknoten laufen zu lassen, er wird ja an V 1.52.1 immer verfügbar sein wenn eine Batterie installiert ist.
Dann ist diese Verbindung obsolet. Wir können uns dann ja überlegen ob die graue Verbindung wegen der Symmetrie für das Auge dennoch drin bleiben soll/kann. ;)
Ja genau das/die meine ich. Aber die wird ja ohnehin auch über den Inverter geladen. Von daher wäre der
Fluss über den WR nur konsequent. Aus
Symmetriegründen ästetischen Gründen würde ich die Batterie probeweise auf Ebene Inverter heben. Dann könnte man eventuell in einer Summenbatterie Installationen mit mehreren Batterien an mehreren WR's abbilden.
Aber im Moment stört mich die graue Linie weniger wegen Ästetik oder Symmetrie, sondern schlicht weil ich gewohnt bin darüber direkt den Bezug von der Batterie abzulesen. Wenn sie ganz weg ist, und die verbleibende eventuell noch horizontal ausgerichtet, habe (zumindest ich) wieder eine Darstellung in der ich das schnell ablesen kann und wo nichts nach oben fließt. Dem Strom ist das egal, meinem Auge und meinem Verstand nicht ganz ;D
Ja, alles hat so seine Vor- und Nachteile.
Die Änderungen kommen vor allem durch das Hinzufügen von möglichen Batterie-Wechselrichtern und zukünftig noch Hybridwechselrichtern, die dann mindestens 3 Anschlüsse haben werden.
Vielleicht fällt mir bzgl. der visuellen Kenntlichmachung von Ladung / Entladung noch etwas besseres ein. Zur Zeit ist die Batterie als SVG-Objekt gestaltet. Das könnte ich in ein FHEM Icon (wie Inverter etc.) umwandeln. Dann könnte der User Entladen/Laden zum Beispiel durch unterschiedliche Färbungen/Symbole selbst festlegen, bzw. kann ich die Einstellungen übernehmen, die man im setupBatteryDevXX (icon) angeben kann.
Zitat von: 300P am 12 Mai 2025, 21:25:00String-Nordausrichtung gibt im Sommer immer weniger Ertrag gegenüber der gleichen Anlage mit einer String-Südausrichtung.
Das erklär doch bitte mal einem PV-Anlagenbetreiber auf der Südhalbkugel.
LG
pah
Guten Morgen,
ich habe gestern wahrgenommen, wie groß doch das Interesse ist, die Verbindungslinie zwischen dem Haus und der Batterie zu erhalten. Hätte ich nicht gedacht. ;) Dabei ging es nicht so sehr um den Energiefluß an sich, sondern den schnellen Erkennungsfaktor ob die Bat geladen oder entladen wird.
Das hat mich bewogen nochmal Hand anzulegen und habe einen Kompromiß erzielt.
Mit der V 1.52.2 in meinem contrib wird wenn kein Batterie- oder (zukünftig) Hybridwechselrichter definiert ist, beim Ladevorgang die Linie Knoten -> Batterie genutzt (wie aktuell) und beim Entladevorgang wieder die Linie Batterie -> Haus aktiviert.
Ist hingegen ein Batterie- oder (zukünftig) Hybridwechselrichter definiert, wird der Fluß Laden - Knoten -> Batterie bzw. Entladen - Batterie -> Knoten über diesen Wechselrichter geführt was der Realität entspricht und mich in der Weiterentwicklung auch nicht behindert.
Im Anhang seht ihr die Beispiele zur Verdeutlichung.
Ich hoffe dass die Gestaltung jetzt allgemeine Zustimmung findet. :)
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 14 Mai 2025, 08:27:38Guten Morgen,
ich habe gestern wahrgenommen, wie groß doch das Interesse ist, die Verbindungslinie zwischen dem Haus und der Batterie zu erhalten. Hätte ich nicht gedacht. ;) Dabei ging es nicht so sehr um den Energiefluß an sich, sondern den schnellen Erkennungsfaktor ob die Bat geladen oder entladen wird.
Das hat mich bewogen nochmal Hand anzulegen und habe einen Kompromiß erzielt.
Mit der V 1.52.2 in meinem contrib wird wenn kein Batterie- oder (zukünftig) Hybridwechselrichter definiert ist, beim Ladevorgang die Linie Knoten -> Batterie genutzt (wie aktuell) und beim Entladevorgang wieder die Linie Batterie -> Haus aktiviert.
Ist hingegen ein Batterie- oder (zukünftig) Hybridwechselrichter definiert, wird der Fluß Laden - Knoten -> Batterie bzw. Entladen - Batterie -> Knoten über diesen Wechselrichter geführt was der Realität entspricht und mich in der Weiterentwicklung auch nicht behindert.
Im Anhang seht ihr die Beispiele zur Verdeutlichung.
Ich hoffe dass die Gestaltung jetzt allgemeine Zustimmung findet. :)
LG,
Heiko
Du bist großartig!Ich hab die v aus dem contrib gezogen und freue mich auf heute Abend, wenn der Strom aus der Batterie zum Haus fließt. ;)
Vielen Dank und viele Grüße,
Peter
Hallo Heiko,
ich bin gerade über ein neues Problem gestolpert, das ich selbst verursacht habe.
Ich bin letzte Woche mit fhem auf einen Raspi5 mit Debian Bookworm umgezogen. Danach passten die Vorhersagen nicht mehr so ganz. Heute sehe ich, dass das Perl Modul AI::DecisionTree fehlt.
Nach der Installation mit cpan meldet der Anlagencheck immer noch das gleiche Problem.
Bei meiner Recherche bin ich sehr schnell auf diesen Foreneintrag gestoßen: https://forum.fhem.de/index.php?msg=1340950 (https://forum.fhem.de/index.php?msg=1340950)
Magst du die Erkenntnis im Anlagencheck ergänzen?
Unter Bookworm muss die Installation nicht mit cpan erfolgen, sondern mit:
sudo apt-get install libai-decisiontree-perl
Danke!
Viele Grüße,
Peter
Hallo Peter,
die alternative Installationsmethode kann ich gerne ergänzen.
Mich wundert es etwas, weil cpan bzw. cpanm nach meiner Auffassung genau die richtigen Tools sind um im Perl Umfeld Zusatzmodule zu installieren.
Kann da allerdings auch nicht mit Erfahrung argumentieren, bei mir hat cpan / cpanm bisher immer zum Erfolg geführt.
Vielleicht können Nutzer, die da tiefer drin stecken, noch etwas dazu beitragen.
Bzgl. Grafik (danke :) ), wir warten den Tag und Abend mal ab und wenn alles zur Zufriedenheit läuft, checke ich die V 1.52.2 heute Abend in.
Grüße,
Heiko
Zitat von: Prof. Dr. Peter Henning am 14 Mai 2025, 03:21:45Zitat von: 300P am 12 Mai 2025, 21:25:00String-Nordausrichtung gibt im Sommer immer weniger Ertrag gegenüber der gleichen Anlage mit einer String-Südausrichtung.
Das erklär doch bitte mal einem PV-Anlagenbetreiber auf der Südhalbkugel.
LG
pah
Guten Morgen pah,
sorry - aber das war mir beim tippen schon so bewußt.
Als ich es dann geschrieben hatte, wollte ich es aber nicht weiter ausholend und ausführlich aufzeigen.
Denn wer von den hier beitragenden Usern (mit SF-Modul) ist auf der Südhalbkugel und verfolgt diese Faden im Einzelnen detailiert.... O:-)
Sichtlich sehr sehr wenige (Anlage) :o
Gruß
300P
Guten Morgen,
ich hab die aktuelle Entwicklung nicht mehr verfolgt und gleich eine "dumme" Frage:
Zitat- Im Attr flowGraphicControl ist ein neuer Schlüssel "showGenerators" vorhanden um eine Reihe mit
PV-Zellen anzuzeigen sofern der WR Zellen zugeordnet hat.
Warum werden die PV-Zellen oberhalb der Sonne dargestellt und nicht zwischen Sonne und Haus? ... sorry
ZitatWarum werden die PV-Zellen oberhalb der Sonne dargestellt und nicht zwischen Sonne und Haus? ... sorry
Die Sonne ist ja nur das Standard-Icon stellvertretend für einen Standard PV-Wechselrichter. Ändere das Icon wenn du es wünscht und schon sieht es andres aus.
@all,
im contrib V 1.52.2 nochmal upgedated (Summezahl Haus).
Zitat von: DS_Starter am 14 Mai 2025, 08:27:38über diesen Wechselrichter geführt was der Realität entspricht
Na ja. Der solare Energiestrom geht in den Wechselrichter, und auch der Batteriestrom kommt aus dem und geht in den WR. Insofern stimmt das in Deinem Diagramm noch nicht. Ich habe mal einen kurzen Screencast meines Diagramms angehängt. Darin sieht man sehr schön, wie sich die Farbe der Animationen verändert - in diesem Falle nur, weil bei schwankendem Verbrauch eben ab und zu minimal aus dem Grid hinzugeladen wird. Als sehr informativ empfindet meine Chefin auch, dass sich die Richtung der Pfeile (ins Grid/aus dem Grid, in die Batterie/aus der Batterie) ebenfalls umkehrt.
LG
pah
Zitat von: 300P am 14 Mai 2025, 09:20:25ist auf der Südhalbkugel
Nicht nur das. Sondern bau mal am Nordpol einen String mit Nordausrichtung auf. Sphärische Polarkoordinaten haben so ihre Tücken...
LG
pah
Moin pah,
ZitatNa ja. Der solare Energiestrom geht in den Wechselrichter, und auch der Batteriestrom kommt aus dem und geht in den WR.
Ja, absolut. Der Fall Hybridwechselrichter, der sowohl Hausnetz und Batterie versorgt/entlädt, kommt bei uns noch.
Das ist einer der nächsten Schritte.
EDIT: Bezüglich Pfeile finde sie auch hilfreich zusätzlich zu der animierten Laufrichtung. Muß ich mal schauen wie man das an eine Linie im SVG einbaut. Tipp nehme ich gerne entgegen.
LG,
Heiko
Die Pfeile sind ganz einfach:
<!-- Pfeil Gesamtleistung -->
<div style="position:absolute;left:115px;top:555px;">
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 150" width="400px"
height="150px">
<path id="pgrid1" transform=""
style="fill:url(#r_h_r);stroke:#bbbbbb;stroke-width:1"
d="M 5,12 h 165 v -10 l 15 15 l -15 15 v -10 h -165 Z"/>
</svg>
</div>
Wie man sieht, ist der Code nicht optimiert - sondern einfach eine Box 400x150 Pixel. Die Füllung ist ein Pattern
<pattern id="r_h_r" patternUnits="userSpaceOnUse" width="15" height="15">
<line x1="0" y1="0" x2="0" y2="15" class="arrow-red" stroke-width="15"/>
<animatetransform attributeName="patternTransform" type="translate" by="15 0"
dur="1s" repeatCount="indefinite"/>
</pattern>
Und die Richtungsumgḱehr:
Du rufst einfach eine JavaScript-Funktion, welche die Füllung (g_h_r = grün horizontal rechts etc.) wechselt und die Richtung (scale(-1 1) oder scale (1 1) ) umkehrt. Dann muss man noch berücksichtigen, dass sich dabei natürlich auch die Position des Pfeils ändert - also nochmal eine horizontale Verschiebung (translate (x y) )einbauen.
Die Funktion ist insofern trivial, als sie den Parameterwert "power" auch als Rückgabewert liefert - aber zwischendrin wechselt sie eben auch die Pfeile.
/* FHEM - zaehler - grid*/
function total_power(power) {
var a = document.getElementById('pgrid1');
var b = document.getElementById('pgrid2');
var s1, s2, t1, t2;
if (power < -0.02) {
s1 = "url(#g_h_r)";
s2 = "url(#g_v_u)";
t1 = "translate(195,0) scale(-1,1)";
t2 = "translate(0,630) scale(1,-1)";
} else {
if (power > 0.02) {
s1 = "url(#r_h_r)";
s2 = "url(#r_v_u)";
t1 = "";
t2 = "";
} else {
s1 = "url(#b_t)";
s2 = "url(#b_s)";
t1 = "";
t2 = "";
}
}
a.style.fill = s1;
a.setAttribute("transform", t1);
b.style.fill = s2;
b.setAttribute("transform", t2);
return power;
}
LG
pah
Zitat von: peterboeckmann am 14 Mai 2025, 08:54:53.........
Unter Bookworm muss die Installation nicht mit cpan erfolgen, sondern mit:
sudo apt-get install libai-decisiontree-perl
Ja das stimmt. Das war ein Post von mir. Ich hatte auf einem Pi4 Bookworm 32Bit inklusive FHEM neu aufgesetzt. Ebenso SolarForecast im Anschluss. Die Installation von CPAN läuft durch, nur FHEM erkennt die CPAN Installation nicht. Bei der Ursachenforschung betreffend des Ai-decisiontree Fehlers von FHEM bin ich im WEB über die Perl-Instalations Routine
sudo apt-get install libai-decisiontree-perl gestolpert.
Nach der Installation erkannt SolarForecast die Ai-decisiontree Funktion.
Ich hoffe ich habe es betreffend setupInverterDevxx jetzt kappiert, auch wenn es für Hybridwechselrichter noch nicht vorhanden ist.
ZitatNur "pv=total_pac:W etotal=etotal:kWh". d.h. die aktuelle Leistung des WR -> Hausnetz ...................
Dieser Wert kann bei mir positiv oder negativ für die Import-Export SV-Hauslast sein. Die USV-Hauslast liefert nur postive Werte.
Zitatpv Ein Reading welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz geliefert wird, bereitstellt. Es muß ein positiver Wert sein.
Somit kann das Ergebnis nur so sein:
Die Summe der Leistungen der PV-Strings + die Generatorleistung W
String1_Leistung__W + String2_Leistung__W + Generator_Leistung_Gesamt__W
Zitat..........und seine gesamte kumulierte erzeugte Energie.
Zitatetotal Das Reading, welches die gesamte erzeugte PV-Energie liefert (ein stetig aufsteigender Zähler). -> hier sehe ich keinen Unterschied zu "gesamte kumulierte erzeugte Energie". Erzeugt die Definition Fragen im Kopf und gibt Raum für Spekulation?
Also die Summe der Energie der PV-Strings + die Generatorenergie in kWh
String_Energie_Gesamt__kWh + Generator_Energie_Gesamt__kWh
Beim Wert Generator_Energie_Gesamt__kWh habe ich nur das Problem, dass der Hybridinverter dieses Reading nicht erzeugt, aber dazu habe ich noch keine Idee wie ich diesen Wert über ein Jahr hinweg generiere, ausser ich verpasse dem Generator einen eigenen Energiezähler. Ich muss für die Statistik-Ermittlung noch herausfinden wie ich ein kumulierten Wert über 52 Wochen unter FHEM berechne.
@Chris,
ZitatSomit kann das Ergebnis nur so sein:
Die Summe der Leistungen der PV-Strings + die Generatorleistung W
String1_Leistung__W + String2_Leistung__W + Generator_Leistung_Gesamt__W
Nicht ganz. Die Generatorleistung ist doch kein PV, richtig?
Den Generator müsstest du als setupOtherProducerXX definieren.
Dann verbleibt:
pv=String1_Leistung__W + String2_Leistung__W
Das gleiche gilt bei etotal. Den Generatorteil in dem setupOtherProducerXX Gerät angeben.
ZitatBeim Wert Generator_Energie_Gesamt__kWh habe ich nur das Problem, dass der Hybridinverter dieses Reading nicht erzeugt, aber dazu habe ich noch keine Idee wie ich diesen Wert über ein Jahr hinweg generiere, ausser ich verpasse dem Generator einen eigenen Energiezähler. Ich muss für die Statistik-Ermittlung noch herausfinden wie ich ein kumulierten Wert über 52 Wochen unter FHEM berechne.
Ich persönliche logge alle Energiewerte in MariaDB und werte nach Bedarf und Herzenslust per DbRep flexibel aus.
ZitatDie Generatorleistung ist doch kein PV, richtig?
Das stimmt, aber der Generator ist wie die Strings am Hybriydinverter als Energielieferant angeschlossen, und dient der Versorgung für die SV- und USV-Last.
Wohlgemerkt wenn es einen Hybridinverter gibt.
ZitatMariaDB
Das kenne ich noch nicht, und muss mich darüber erkundigen.
Aber ich denke ich habe die Lösung für die Ermittlung der gesamt kWh des Generators gefunden.
ZitatDas stimmt, aber der Generator ist wie die Strings am Hybriydinverter als Energielieferant angeschlossen, und dient der Versorgung für die SV- und USV-Last.
Wohlgemerkt wenn es einen Hybridinverter gibt.
Denke aber bitte daran ... wenn der Generator aus Sicht des Moduls als PV-Erzeugung gewertet wird (weil es als PV eingeht), dann verhagelt es dir die Prognose, da die ermittelte/aufgezeichnete PV-Energie nicht mit der real nur von den PV-Zellen generierte Energie übereinstimmt. Natürlich nur wenn der Generator arbeitet.
Auch wenn der Genarator physisch am WR angeschlossen ist, müssen wir die logische Struktur etwas anders gestalten.
ZitatAuch wenn der Genarator physisch am WR angeschlossen ist, müssen wir die logische Struktur etwas anders gestalten.
Ja, dass stimmt. Erst einmal einen Schritt nach dem anderen.
Interessant sind noch drei weitere Datenpunkte (zwei von denen zeige ich bei mir im Diagramm an)
1.Die am heutigen Tag in die Batterie eingespeicherte und
2.die daraus bezogene Energiemenge.
Wenn man beide Werte über die Zeit aufintegriert, bekommt man einen guten Überblick über den Speicherverlust (und bevor jemand glaubt, schlauer zu sein: Die vom BYD-Speicher selbst gemeldeten Energiemengen sind notorisch ungenau). Diesen Speicherverlust über die Zeit zu betrachten, scheint ein guter Indikator für den Zustand des Speichers zu sein.
3.Der Eigenverbrauch des Wechselrichters. Der schluckt bei heftiger Aktivität (Solarer Zustrom oder Entladen des Speichers) so um die 40W bei mir.
LG
pah
Und wenn ich schon am Fantasieren bin: Ich hatte vor Monaten schon mal vorgeschlagen, die Visualisierung von der Vorhersage zu trennen.
Das ist bei mir ja im FTUI2 und FTUI3 schon realisiert. Es gibt aber noch etwas, das ohne FTUI man verwenden könnte: Den guten alten FLOORPLAN. Vor vielen Jahren habe ich das mal, mit einem statischen Bild, für die Heizungsanlage gemacht (ist schon 2016 in den SmartHome Hacks publiziert).
Das könnte man etwas aufbohren, die Pfeile konfigurierbar machen (von wo nach wo?) und animieren. Dann könnte auch jeder seine Verbraucher und Erzeuger dort positionieren, wo er möchte.
LG
pah
Frage und kleine Bitte:
- Kann man das Icon für den "Knoten" auch selbst bestimmen?
- Bitte falls möglich das Icon für den Inverter etwas nach rechts rücken / mittig setzen
D a n k e
ZitatKann man das Icon für den "Knoten" auch selbst bestimmen?
Baue ich in das Attr flowGraphicControl ein.
ZitatBitte falls möglich das Icon für den Inverter etwas nach rechts rücken / mittig setzen
Ja, die ganze Inverterzeile muß ein kleines bisschen nach rechts. Vllt. heute Abend.
LG
@grappa24: Die Zellen sollen angeblich 5,291 kW DC liefern, der WR genausoviel als Wechselstrom, und ebensoviel geht weiter ?
Das kann ich nicht ganz glauben.
LG
pah
Der / die zugehörigen String-DC-Werte werden momentan von SF weder erfasst bzw. zugeordnet.
Aktuell zeigen die "PV-Zellen" (die Strings die dem WR zugeordnet wurden) daher (m.M.n.) nur den AC-Wert den der WR (in Summe) damit am Ende ins Hausnetz abgibt. O:-)
Das ist erst seit ein paar Tagen als Grafikanzeige dazugekommen und es wird daher auch (noch) nicht zwischen DC/AC unterschieden. ;)
Gruß
300P
Ich habe ein Problem mit der Definition des Standbywertes.
consumer01
HZG_WPD:Wärmepumpe type=noSchedule icon=sani_heating_heatpump
power=0 pcurr=Active_Power__W:W:30 etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=0
asynchron=1Ein nominaler Wert ist nicht notwendig.
Der Standbywert entspricht 26W. Trotzdem wird das Gerät aktiv angezeigt.
Ändere ich auf power=2540 wird die Geräteicone dunkel, und die grüne Verbindungslinie dunkler. Soll das so sein?
Versuche es mal so:
attr Forecast consumer08 SMA_Elgris_EM2 \
type=noSchedule \
power=0 \
icon=sani_heating_heatpump@orange \
pcurr=Bezug_Wirkleistung:W\
etotal=Bezug_Wirkleistung_Zaehler:kWh\
noshow=0
Das ergibt: (Screenshot)
PS:
Natürlich mit deinen Parameterangaben 😉
Gruß
300P
Die Inverterreihe habe ich schonmal etwas verschoben, liegt im contrib.
ZitatDer Standbywert entspricht 26W. Trotzdem wird das Gerät aktiv angezeigt.
Das schaue ich mir an.
ZitatDer Standbywert entspricht 26W. Trotzdem wird das Gerät aktiv angezeigt.
Habe den logischen Fehler gefunden und beseitigt -> Update im contrib.
@all,
habe die V 1.52.2 mit den kleinen Fixes eingecheckt.
Zusätzlich ist noch die Möglichkeit im Attr flowGraphicControl eingebaut, das Knoten-Icon und ggf. dessen Farbe anpassen zu können:
inverterNodeIcon Icon für den Inverterknoten (das Icon unter der Wechselrichterzeile) und ggf. dessen Farbe bei Aktivität.
Die Farbe kann als Hex-Wert (z.B. #cc3300) oder Bezeichnung (z.B. red, blue) angegeben werden.
Syntax: <Icon>[@<Farbe>]
LG,
Heiko
so hatte ich es mir für meine "einfache" Konfig. vorgesellt ...
Dein Hausverbrauch ist X-stellig ist mir aufgefallen.
Ich habe gleich noch die Normierung dafür eingebaut, liegt im contrib wenn du noch ausprobieren willst.
LG
Hallo,
wie kann ich zwei Speicher darstellen?
Habe einmal Fronius mit BYd-Speicher und dann noch eine Balkonanlage von SolMate mit eigenem Speicher und würde gerne Füllgrad und Be- oder Entladen in der Flussgrafik sehen.
setupBatteryDev01
PV_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W intotal=Summe_Ladung:kWh outtotal=Summe_Entladung:kWh cap=7680 charge=BatteryChargePercent show=1 icon=measure_battery_50@#262626:@yellow:measure_battery_100@red
setupBatteryDev02
solmate pin=battery_flow:W pout=-pin intotal=energy:Wh cap=672:kWh charge=battery_proc pinmax=525 poutmax=600 show=1:bottom icon=measure_battery_50@#262626:@yellow:measure_battery_100@red
setupInverterDev01
Fronius_Symo pv=PowerFlow_Site_P_PV:W etotal=PowerFlow_Inverters_1_E_Total:kWh feed=bat capacity=6000 strings=Dach icon=inverter@red:solar
setupInverterDev02
solmate pv=power:W etotal=energy:kWh capacity=600 feed=bat strings=Balkon icon=inverter@red:solar
setupInverterStrings Dach,Balkon
setupMeterDev Fronius_Symo gcon=Bezug:W contotal=Meter_0_EnergyReal_WAC_Plus_Absolute:Wh gfeedin=Einspeisung feedtotal=Meter_0_EnergyReal_WAC_Minus_Absolute:Wh conprice=powerCost:€ feedprice=0.0803:€
setupRadiationAPI OpenMeteoDWD_D2-API
setupStringAzimuth Dach=-3 Balkon=-3
setupStringDeclination Dach=50 Balkon=90
setupStringPeak Dach=5.28 Balkon=0.525
Momentan sieht es bei mir wie angehängt aus.
Aktuell können in der Flußgrafik keine Einzelbatterien dargestellt werden, nur als Cluster wie bei dir zu sehen.
Einzelanzeige ist über/unter den Balkendiagrammen möglich.
LG,
Heiko
Ich hätte einen Wunsch.
Ich habe für jeden größeren Bereich, Aussenbereich, EG, OG1 und OG2 eigene Zähler zur Energieerfassung.
Zusätzlich gibt es in diesen Bereichen nachgelagerte Geräte die ebenfalls mit einem eigenen Energiezähler bestückt sind.
ZB. Geschirrspüler, Waschmaschine, Trockner usw.
In der aktuellen Form ist das für die Auswertungen nicht vorgesehen, und lösen dadurch falsche Berechnungen aus.
Derzeit habe ich mir so beholfen.
Ich entnehme dem Energiezähler, zB. EG die Leistungs- und Energiewerte.
Von diesen Werten ziehe ich die Energiewerte der Geräte ZB. Geschirrspüler, Waschmaschine, Trockner usw. ab, dass nur mehr die Restenergie für das EG übrig bleibt. Sind sozusagen Dummys für die Stockwerke. Es müsste eigentlich möglich sein die Geräte einem Stockwerk zuzuweisen, wie man es auch bei der Batterie mit dem Inverter macht.
Wie gesagt ist nur ein Wunsch bzw. Idee.
ZitatIch habe für jeden größeren Bereich, Aussenbereich, EG, OG1 und OG2 eigene Zähler zur Energieerfassung.
Zusätzlich gibt es in diesen Bereichen nachgelagerte Geräte die ebenfalls mit einem eigenen Energiezähler bestückt sind.
ZB. Geschirrspüler, Waschmaschine, Trockner usw.
In der aktuellen Form ist das für die Auswertungen nicht vorgesehen, und lösen dadurch falsche Berechnungen aus.
Ich könnte mir vorstellen weitere Energiezähler zu implementieren mit der Option, dass man als User die Verbraucher den Energiezählern zuordnen kann. Dann entstünde eine Fächer-Struktur wie in dem Fake-Bild im Anhang. Vorab muß noch vorgesehen werden, die möglichen Zähler als Grid- oder Zwischenzähler spezifizieren zu können und den Consumern eine Zuordnung zu Zählern zu erlauben usw.
Möglich ist vieles ... der Appetit kommt bekanntlich beim Essen. ;)
In der letzten Zeit sind einige Vorschläge und Wünsche geäußert worden. Deswegen hier mal ein Abriss was bei mir als nächste Schritte auf dem Plan stehen:
- Wechselrichter: Implementierung von Hybridwechselrichtern bzw. die Ersetzung des vorhandenen Parameters "pv" mit z.B. "pvIn" (DC-In Leistung Module) und erweiterte Nutzung von "dc2ac / dc2dc", d.h. der Output des Standard/Hybrid-WR Richtung Hausnetz bzw. Batterie.
- Batteriemangement: mögliche Einflußnahme des Users auf den Ladezyklus der Batterien in der Form, dass das System bis zum vorgegebenen Zeitpunkt versucht soviel wie möglich Energie in die Batterie(n) zu laden. Zur Zeit wird ein ausgewogenes Laden über den gesamten Tag unter Berücksichtigung von gegebenen Einspeiselimits prozessiert. Das bezieht sich natürlich nur auf Reading Battery_ChargeRecommended_XX, es ist euch ja bekannt dass SF nicht direkt das Batteriesystem steuert.
- Batterieanzeige: Einzelbatterien in der Flußgrafik. Sie würden dann wahrscheinlich rechts der aktuellen "Sammelbatterie" platziert und das aktuelle Batteriesymbol wird zu einem "Batterie-Knoten". Mal sehen.
- Implementierung eines neuronalen Netzes zur KI-gestützten Hausverbrauchsprognose um diesbezüglich die Qualität und Möglichkeiten zu verbessern.
- Wiki weiter ausbauen
- Sonne, Garten und Urlaub :)
Die aufgeführten Punkte stellen keine feste Reihenfolge dar, insbesondere nicht der letzte Anstrich. ;)
LG,
Heiko
Wie gesagt nur eine Idee von mir.
So wie du es schon angesprochen hast, wäre eine Fächerung genau das.
Eine Auffächerung wäre für viele Bereiche zum Überblick eine feine Sache. Das wird bei Vielen wahrscheinlich nicht notwendig sein und für dich eine Menge Arbeit.
Zitat- Batterieanzeige: Einzelbatterien in der Flußgrafik. Sie würden dann wahrscheinlich rechts der aktuellen "Sammelbatterie" platziert und das aktuelle Batteriesymbol wird zu einem "Batterie-Knoten". Mal sehen.
Das wird wahrscheinlich nicht ganz passen bei den Hybridwechselrichtern. Da passt dann der Leistungsfluss unter umständen nicht.
Bei meinen Hybridwechselrichtern haben die Batterien keine Verbindung mit dem Hausnetz. Diese Batterien gehen per DC in den Hybridwechselrichter im Prinzip wie die PV-Strings. Der Generator geht per AC in den Hybridwechselrichter.
Per AC ist dann die beiden Lasten drauf. Einmal AC Hauslast (bzw. Import & Export Grid) und einmal AC USV.
Sonne, Garten und Urlaub :) sind jedenfalls wichtiger.Änderungen und Anpassungen sind Schlechtwetterangelegenheiten.
Und bis ich dein Baby durchgetestet habe, wird ohnehin noch viel Zeit vergehen, und habe jetzt schon einige Ideen beim Durchtesten bei mir abgeändert.
Jetzt muss ich ohnehin die fehlenden 17kWp noch fertig stellen, sowie die Hilfsanlagen Windgenerator und Notstromgenerator.
Hallo Heiko,
ich habe mal bisschen mit aiTreesPV gespielt und sehr schnell für mich überraschende Ergebnisse bekommen. Die Anzahl der gefundenen Regeln ist in nur 2 Tagen signifikant gestiegen.
Gruß Gerd
Ich suche bei der Balkengraphik die Möglichkeit den Abstand der Icons zum Oberen- bzw. Unterem-Rand zu vergrößern.
Lässt sich das einstellen?
Nicht das ich es wüsste ;)
Moin,
ZitatIch suche bei der Balkengraphik die Möglichkeit den Abstand der Icons zum Oberen- bzw. Unterem-Rand zu vergrößern.
Lässt sich das einstellen?
Aktuell nicht wie 300P schon schrieb. Im Prinzip sollte es aber via graphicControl einbaubar sein.
Der Freiplatz zwischen der obersten Iconzeile und dem oberen Rand und der untersten Text/Iconzeile und dem unteren Rand, richtig?
@Gerd,
ja, damit kann man experimentieren. Wahrscheinlich wirst du je nach Wahl einen entsprechenden RAM-Verbrauch feststellen. Deswegen kann man das entsprechend seines Systems anpassen um eine Ausgewogenheit zwischen der vorhandenen Hardware und tendenziell besseren Ergebnissen herstellen zu können.
ZitatDer Freiplatz zwischen der obersten Iconzeile und dem oberen Rand und der untersten Text/Iconzeile und dem unteren Rand, richtig?
Ja genau.
Soll der obere und untere Freiplatz getrennt voneinander einstellbar sein oder reicht ein Parameter um symmetrisch beide Freiräume einzustellen?
Morgen zusammen,
habe die V 1.52.3 in mein contrib geladen. Im graphicControl gibt es zwei Keys um die Abständen oben/unten in den Balkengrafik Ebenen einstellen zu können:
beamPaddingBottom Legt den Platz in px im Balkendiagramm fest, der zwischen der letzten Text- oder Iconreihe der jeweiligen Balkengrafik Ebene
und dem unteren Rand dieser Ebene eingefügt wird.
Der Wert gilt einheitlich für alle Balkengrafik Ebenen.
Wert: Ganzzahl, default: 0
beamPaddingTop Legt den Platz in px im Balkendiagramm fest, der zwischen dem oberen Rand der jeweiligen Balkengrafik Ebene und der ersten
Text- oder Iconreihe dieser Ebene eingefügt wird.
Der Wert gilt einheitlich für alle Balkengrafik Ebenen.
Wert: Ganzzahl, default: 0
Weiterhin stellt der Setter attrKeyVal eine Liste der verfügbaren zusammengesetzten Attribute zur Verfügung. Nach Auswahl des Attributs kann man den/die Schlüssel setzen.
LG,
Heiko
ZitatbeamPaddingBottom, beamPaddingTop
Das ging wieder einmal sehr schnell. Das passt. Danke.
Prima, habe die Version soeben eingecheckt, ist morgen früh im Regelupdate.
LG
Ich bin mir nicht sicher, ob ich hier richtig bin. Das Modul ließ sich problemlos definieren und meldet:
ZitatHerzlich Willkommen!
Die nächsten Abfragen führen sie durch die Grundinstallation.
Sind alle Eingaben vorgenommen, prüfen sie bitte die Konfiguration abschließend mit "set SolarVorhersage plantConfiguration check" oder mit Druck auf das angebotene Icon.
Korrigieren sie bitte eventuelle Fehler und beachten sie mögliche Hinweise.
(Die Anzeigesprache kann mit dem Attribut "ctrlLanguage" umgestellt werden.)
Bitte geben sie alle von Ihnen verwendeten Stringnamen mit "attr SolarVorhersage setupInverterStrings" an
Jetzt steht im Wiki:
ZitatNach der Definition wird der User durch einen Dialog geführt, der einige unerlässliche Einstellungen abfragt und in den entsprechenden Attributen und Readings persistiert.
Wo finde ich denn diesen Dialog bzw. wie starte ich den? Unter "set SolarVorhersage plantConfiguration check" erscheinen natürlich Fehler, weil die Konfiguration noch nicht abgeschlossen ist.
Besten Dank
Das ist der Einstieg in den Dialog.
Als erste Anweisung steht ja da:
Bitte geben sie alle von Ihnen verwendeten Stringnamen mit "attr SolarVorhersage setupInverterStrings" an
Wenn du das machst, kommst du zum nächsten Schritt usw.
Die Formulierung im Wiki ist wohl etwas mißverständlich?
LG,
Heiko
Moin Zusammen !
Hier für diejenigen unter euch, die mehrere SMA Batteriewechselrichter nutzen und netzdienlich laden wollen. (Andere BWR natürlich mit Anpassung der Modus-Befehle)
Ich nutze im "ctrlUserExitFn" seit ein paar Tagen (u.a.) diesen Code und es läuft soweit gut damit.
Für 1 BWR ist der Code etwas tiefer auch dabei
{
# BEGIN ######## Netzdienliches Laden ################
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
my $timestart = 9; # ab welcher Uhrzeit soll es sein ===>> Wert evtl. anpassen
my $timeend = 15; # bis wieviel Uhr soll es sein ===>> Wert evtl. anpassen
if (int $hour >= $timestart && int $hour < $timeend ) {
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
my $curpowerbatin01 = ReadingsNum ($name, 'Current_PowerBatIn_01', 0);
my $curpowerbatin02 = ReadingsNum ($name, 'Current_PowerBatIn_02', 0);
my $curpowerbatout01 = ReadingsNum ($name, 'Current_PowerBatOut_01', 0);
my $curpowerbatout02 = ReadingsNum ($name, 'Current_PowerBatOut_02', 0);
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); # SoC Bat01 aktuell
my $curbatcharge02 = CurrentVal ($name, 'Current_BatCharge_02', 0); # SoC Bat02 aktuell
my $currentsurplus = (ReadingsNum ($name, 'Current_Surplus', 0) - 50); # etwas abziehen zwecks weniger als Puffer
my $batchargerequest01 = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0); # Batterie01 muss geladen werden ?
my $batchargerequest02 = ReadingsNum ($name, 'Battery_ChargeRequest_02', 0); # Batterie02 muss geladen werden ?
my $gridfriendlychargebat01 = ReadingsNum ($name, 'Battery_ChargeRecommended_01', 0); # Batterie01 recommended ?
my $gridfriendlychargebat02 = ReadingsNum ($name, 'Battery_ChargeRecommended_02', 0); # Batterie02 recommended ?
my $curbatchargemin01= 30; # erst ab Mindes-BAT01-SOC XY netzdienlich ===>> Wert evtl. anpassen 0..30
my $curbatchargemin02= 30; # erst ab Mindes-BAT02-SOC XY netzdienlich ===>> Wert evtl. anpassen 0..30
my $bwr01 = "MB_SBS25"; # Name des 1ten BWR-Modbus-Device ===>> Wert evtl. anpassen
my $bwr02 = "MB_SBS25_2"; # Name des 2ten BWR-Modbus-Device ===>> Wert evtl. anpassen
if (int $gridfriendlychargebat01 eq 0 || $gridfriendlychargebat02 eq 0) {
# Nur wenn die Batterieladung01 oder 02 SF-Systemseitig nicht empfohlen wird dann
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended Battery01 $gridfriendlychargebat01 - Battery02 $gridfriendlychargebat02 });
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); # SoC Bat01 aktuell
my $curbatcharge02 = CurrentVal ($name, 'Current_BatCharge_02', 0); # SoC Bat02 aktuell
if (int $gridfriendlychargebat01 eq 0 && $batchargerequest01 eq 0 && $curbatcharge01 > $curbatchargemin01) {
# wenn bei Bat01 = 0 -beides- und SOC groß genug ->>dann unterbinden Laden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended only Battery01 Reading = $gridfriendlychargebat01 });
fhem("set $bwr01 Set_Leistung_W $currentsurplus"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
else {
if (int $gridfriendlychargebat01 eq 1 || $batchargerequest01 eq 1 || (($curbatcharge01 - 3) <= $curbatchargemin01)) {
# wenn bei Bat01 = beides oder nur eins auf 1 steht ---dann bitte jetzt Steuerung aus / kein Laden unterbinden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended =>> Battery01 Reading = $gridfriendlychargebat01 and BatChargerequest =>> Battery01 Reading = $batchargerequest01 });
fhem("set $bwr01 Set_Leistung_W 0"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => not activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
}
if (int $gridfriendlychargebat02 eq 0 && $batchargerequest02 eq 0 && $curbatcharge02 > $curbatchargemin02) {
# wenn bei Bat02 = 0 -beides- und SOC groß genug --->>dann unterbinden Laden Bat02
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended only Battery02 Reading = $gridfriendlychargebat02 });
fhem("set $bwr02 Set_Leistung_W $currentsurplus"); # Watt Netzleistung am Übergabemesspunkt (WR2)
fhem("set $bwr02 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR2)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr02 => not activ - BatIn02 $curpowerbatin02 BatOut02 $curpowerbatout02 });
}
else {
if (int $gridfriendlychargebat02 eq 1 || int $batchargerequest02 eq 1 || (($curbatcharge02 - 3) <= $curbatchargemin02)) {
# wenn bei Bat02 = beides oder nur eins auf 1 steht ---dann bitte jetzt Steuerung aus / kein Laden unterbinden Bat02
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended =>> Battery02 Reading = $gridfriendlychargebat02 and BatChargerequest =>> Battery02 Reading = $batchargerequest02 });
fhem("set $bwr02 Set_Leistung_W 0"); # Watt Netzleistung am Übergabemesspunkt (WR2)
fhem("set $bwr02 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR2)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr02 => not activ - BatIn02 $curpowerbatin02 BatOut02 $curpowerbatout02 });
}
}
}
}
# ENDE ######## Netzdienliches Laden ################
}
Hier nur für 1 BWR:
{
# BEGIN ######## Netzdienliches Laden ################
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
my $timestart = 9; # ab welcher Uhrzeit soll es sein ===>> Wert evtl. anpassen
my $timeend = 15; # bis wieviel Uhr soll es sein ===>> Wert evtl. anpassen
if (int $hour >= $timestart && int $hour < $timeend ) {
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
my $curpowerbatin01 = ReadingsNum ($name, 'Current_PowerBatIn_01', 0);
my $curpowerbatout01 = ReadingsNum ($name, 'Current_PowerBatOut_01', 0);
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); # SoC Bat01 aktuell
my $currentsurplus = (ReadingsNum ($name, 'Current_Surplus', 0) - 50); # etwas abziehen zwecks weniger als Puffer
my $batchargerequest01 = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0); # Batterie01 muss geladen werden ?
my $gridfriendlychargebat01 = ReadingsNum ($name, 'Battery_ChargeRecommended_01', 0); # Batterie01 recommended ?
my $curbatchargemin01= 30; # erst ab Mindes-BAT01-SOC XY netzdienlich ===>> Wert evtl. anpassen 0..30
my $bwr01 = "MB_SBS25"; # Name des 1ten BWR-Modbus-Device ===>> Wert evtl. anpassen
if (int $gridfriendlychargebat01 eq 0) {
# Nur wenn die Batterieladung01 SF-Systemseitig nicht empfohlen wird dann
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended Battery01 $gridfriendlychargebat01 });
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); # SoC Bat01 aktuell
if (int $gridfriendlychargebat01 eq 0 && $batchargerequest01 eq 0 && $curbatcharge01 > $curbatchargemin01) {
# wenn bei Bat01 = 0 -beides- und SOC groß genug ->>dann unterbinden Laden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended only Battery01 Reading = $gridfriendlychargebat01 });
fhem("set $bwr01 Set_Leistung_W $currentsurplus"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
else {
if (int $gridfriendlychargebat01 eq 1 || $batchargerequest01 eq 1 || (($curbatcharge01 - 3) <= $curbatchargemin01)) {
# wenn bei Bat01 = beides oder nur eins auf 1 steht ---dann bitte jetzt Steuerung aus / kein Laden unterbinden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended =>> Battery01 Reading = $gridfriendlychargebat01 and BatChargerequest =>> Battery01 Reading = $batchargerequest01 });
fhem("set $bwr01 Set_Leistung_W 0"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => not activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
}
}
}
# ENDE ######## Netzdienliches Laden ################
}
ACHTUNG:
Voraussetzung ist das die Modbus-Device bereits existieren und sauber dazu passend eingerichtet sind !
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
Zitat von: DS_Starter am 18 Mai 2025, 14:05:59Die Formulierung im Wiki ist wohl etwas mißverständlich?
LG,
Heiko
Besten Dank! Ich hatte irgendwie einen geführten Dialog erwartet (ähnlich eines Installationsdialogs). Jetzt habe ich es aber vermutlich verstanden.
Nabend zusammen,
in meinem contrib liegt die V 1.52.4.
In Vorbereitung der Hybridinverterintegration ist bei den Invertern im setupInverterDevXX der bisherige Schlüssel "pv" in "pvOut" umbenannt und es gibt einen neuen Schlüssel "pvIn" für die DC Eingangsleistung aus den Solarzellen. pvIn wird nun auch in der Flußgrafik unterhalb der Solarzelle angezeigt.
Solange pvIn nicht gesetzt ist, wird dort 0 angezeigt.
pvIn Ein Reading, welches die aktuelle DC PV-Eingangsleistung in W liefert (Summe aller angeschlossenen Strings).
Es wird ein positiver numerischer Wert erwartet.
pvOut Ein Reading, welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz oder öffentliche Netz
geliefert wird, bereitstellt. Es wird ein positiver numerischer Wert erwartet.
Die Umstellung von pv -> pvOut erfolgt automatisch. Bitte Restart nicht vergessen!
pvIn ist dann noch manuell zu setzen, ist jedoch kein Problem wenn der Schlüssel später eingefügt wird. Bis dahin wird lediglich "0" angezeigt, sonst hat es keine Nachteile.
Weiterhin_
- die Online-Hilfe zu setupInverterDevXX ist für eine bessere Übersicht Inverterspezifisch organisiert
- die Flußgrafik habe ich noch etwas ausgerichtet wie von Peter angemerkt (#2913)
- fix des Problems "devision by zero" (#2926)
- das Attr ctrlSpecialReadings hat eine neue Auswahl "BatWeightedTotalSOC" zur Anzeige des resultierenden SOC aller Batterien
LG,
Heiko
Hallo Heiko,
ich bin endlich dazu gekommen nochmal etwas zu forschen....
Wo kommt beim "get ..... nextHours" der Wert "sunaz" her. Dieser verändert sich über den Tag nur um +/-70, sollte doch aber volle 360 ° haben?!
Zitat von: DS_Starter am 12 Mai 2025, 22:33:17Hallo Kai,
ich sehe bei dir keinen Fehler und habe deswegen bei mir zwei Instanzen nachgestellt.
..........
Danke und Grüße
Kai
sunaz wird durch eine Subroutine es Astro-Moduls geliefert und läuft auch bis 360 Grad.
Hier der Ausschnitt der Rawdata von heute:
2025051801 => hod: 01, nod: So, sunaz: 350, sunalt: -19, rad1h: -, wcc: 100, wid: 61, rr1c: 0.00, pvrl: -, con: 734, gcons: 25, temp: 7
2025051802 => hod: 02, nod: So, sunaz: 5, sunalt: -19, rad1h: -, wcc: 100, wid: 3, rr1c: 0.50, pvrl: -, con: 627, gcons: 23, temp: 9
2025051803 => hod: 03, nod: So, sunaz: 20, sunalt: -17, rad1h: -, wcc: 100, wid: 61, rr1c: 0.30, pvrl: -, con: 594, gcons: 22, temp: 9
2025051804 => hod: 04, nod: So, sunaz: 34, sunalt: -12, rad1h: -, wcc: 100, wid: 61, rr1c: 0.30, pvrl: -, con: 567, gcons: 25, temp: 9
2025051805 => hod: 05, nod: So, sunaz: 47, sunalt: -6, rad1h: -, wcc: 100, wid: 61, rr1c: 0.30, pvrl: -, con: 636, gcons: 24, temp: 9
2025051806 => hod: 06, nod: So, sunaz: 59, sunalt: 1, rad1h: -, wcc: 89, wid: 80, rr1c: 0.00, pvrl: 15, con: 638, gcons: 23, temp: 9
2025051807 => hod: 07, nod: So, sunaz: 70, sunalt: 10, rad1h: -, wcc: 100, wid: 61, rr1c: 0.00, pvrl: 189, con: 523, gcons: 23, temp: 9
2025051808 => hod: 08, nod: So, sunaz: 82, sunalt: 19, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 835, con: 1288, gcons: 28, temp: 10
2025051809 => hod: 09, nod: So, sunaz: 93, sunalt: 28, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 2649, con: 1603, gcons: 35, temp: 11
2025051810 => hod: 10, nod: So, sunaz: 106, sunalt: 37, rad1h: -, wcc: 74, wid: 2, rr1c: 0.00, pvrl: 4350, con: 976, gcons: 20, temp: 12
2025051811 => hod: 11, nod: So, sunaz: 121, sunalt: 46, rad1h: -, wcc: 80, wid: 2, rr1c: 0.00, pvrl: 3453, con: 913, gcons: 24, temp: 13
2025051812 => hod: 12, nod: So, sunaz: 140, sunalt: 53, rad1h: -, wcc: 60, wid: 3, rr1c: 0.00, pvrl: 2037, con: 888, gcons: 15, temp: 15
2025051813 => hod: 13, nod: So, sunaz: 163, sunalt: 58, rad1h: -, wcc: 52, wid: 2, rr1c: 0.00, pvrl: 3474, con: 1156, gcons: 43, temp: 15
2025051814 => hod: 14, nod: So, sunaz: 190, sunalt: 58, rad1h: -, wcc: 96, wid: 3, rr1c: 0.20, pvrl: 2350, con: 844, gcons: 32, temp: 15
2025051815 => hod: 15, nod: So, sunaz: 214, sunalt: 55, rad1h: -, wcc: 20, wid: 80, rr1c: 0.00, pvrl: 4184, con: 1015, gcons: 10, temp: 15
2025051816 => hod: 16, nod: So, sunaz: 235, sunalt: 48, rad1h: -, wcc: 51, wid: 2, rr1c: 0.00, pvrl: 2127, con: 612, gcons: 3, temp: 16
2025051817 => hod: 17, nod: So, sunaz: 250, sunalt: 40, rad1h: -, wcc: 92, wid: 3, rr1c: 0.00, pvrl: 3355, con: 1920, gcons: 58, temp: 16
2025051818 => hod: 18, nod: So, sunaz: 264, sunalt: 30, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 1168, con: 1550, gcons: 57, temp: 16
2025051819 => hod: 19, nod: So, sunaz: 276, sunalt: 21, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 956, con: 633, gcons: 26, temp: 15
2025051820 => hod: 20, nod: So, sunaz: 287, sunalt: 12, rad1h: -, wcc: 34, wid: 2, rr1c: 0.00, pvrl: 418, con: 676, gcons: 23, temp: 14
2025051821 => hod: 21, nod: So, sunaz: 298, sunalt: 4, rad1h: -, wcc: 44, wid: 2, rr1c: 0.00, pvrl: 96, con: 601, gcons: 24, temp: 13
2025051822 => hod: 22, nod: So, sunaz: 310, sunalt: -4, rad1h: -, wcc: 98, wid: 3, rr1c: 0.00, pvrl: -, con: 714, gcons: 23, temp: 13
Und von NextHours:
NextHour00 => starttime: 2025-05-18 23:00:00, day: 18, hourofday: 24, today: 1
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 22, confcEx: 22, weatherid: 103, wcc: 98, rr1c: 0.00, temp=12.20
rad1h: 0, sunaz: 336, sunalt: -16, DoN: 0
rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
NextHour01 => starttime: 2025-05-19 00:00:00, day: 19, hourofday: 01, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 22, confcEx: 22, weatherid: 103, wcc: 100, rr1c: 0.00, temp=11.80
rad1h: 0, sunaz: 350, sunalt: -18, DoN: 0
rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
NextHour02 => starttime: 2025-05-19 01:00:00, day: 19, hourofday: 02, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 22, confcEx: 22, weatherid: 103, wcc: 100, rr1c: 0.00, temp=11.10
rad1h: 0, sunaz: 5, sunalt: -19, DoN: 0
rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
NextHour03 => starttime: 2025-05-19 02:00:00, day: 19, hourofday: 03, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 22, confcEx: 22, weatherid: 103, wcc: 100, rr1c: 0.00, temp=10.50
rad1h: 0, sunaz: 20, sunalt: -17, DoN: 0
rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
NextHour04 => starttime: 2025-05-19 03:00:00, day: 19, hourofday: 04, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 21, confcEx: 21, weatherid: 102, wcc: 75, rr1c: 0.00, temp=10.10
rad1h: 0, sunaz: 34, sunalt: -12, DoN: 0
rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
Okay, die werte sehen wie gesagt bei mir anders aus.
Das Astro-Modul ist im SF integriert?
Nachtrag: Habe den Fehler gefunden. Im global war nicht die korrekte Position angegeben. Jetzt passen die Werte!
Danke und Grüße
Kai
Ist ein Sunny Tripower Smart Energy laut deines Verständnisses ein Hybridinverter?
Moin,
Ja der Sunny Tripower Smart Energy ist ein Hybridwechselrichter. Die Funktion ist momentan etwas umständlich in SF zu integrieren, aber diesen Typ WR steht oben auf dem Zettel der Weiterentwicklung.
Frage ... bekommt man bei diesem Invertertyp separate Werte heraus, welche Leistung aus PV in das Hausnetz gespeist wird und welche Leistung aus der Batterie? Oder gibt es nur einen Mix aus PV und Bat als Leistungsangabe Richtung Hausnetz?
Lg,
Heiko
Hier mal die Umsetzung von 1.52.4 mit PvIn/PvOut.
(Einzige) Abweichung vom Standard ist das Icon für den Wechselrichter anstatt der Sonne (icon=inverter@#ff8c00:inverter@grey)
PvIn/PvOut mittels 98_fronius.pm aus folgenden Readings: https://forum.fhem.de/index.php?msg=1341825
So hab ich es mir gedacht. 🙂 Man sieht auch den Wandlungsverlust. Hätte ich sogar mit mehr gerechnet, aber kommt sicher auf die Qualität des WR an.
Hallo zusammen,
der Wandlungsverlust/ Eigenverbrauch ist bei meinem Wechselrichter etwas deutlicher zu sehen:
screen.png
@grappa24: Wie heißt das Icon, das Du für den Wechselrichter verwendest? Das gefällt mir besser als meins.
@Heiko: Du hattest kürzlich die Panel-Symbole ganz oben schonmal weiter nach rechts geschoben. Ich habe den Eindruck, dass diese zusammen mit der Linie darunter und dem Wechselrichter-Symbol noch etwas nach rechts könnten. Die Line über dem WR ist weiter links als die Linie unter dem WR, oder?
Viele Grüße,
Peter
Die Linie ja. Bei den Icons gibt es welche die sind in sich etwas unsymmetrisch. Da ändert sich das Bild ein wenig wenn der User andere Icons definiert.
Zitat von: peterboeckmann am 19 Mai 2025, 12:05:54@grappa24: Wie heißt das Icon, das Du für den Wechselrichter verwendest? Das gefällt mir besser als meins.
icon=inverter@#ff8c00:inverter@grey
Zitat von: DS_Starter am 19 Mai 2025, 09:34:11Frage ... bekommt man bei diesem Invertertyp separate Werte heraus, welche Leistung aus PV in das Hausnetz gespeist wird und welche Leistung aus der Batterie? Oder gibt es nur einen Mix aus PV und Bat als Leistungsangabe Richtung Hausnetz?
Zunächst großen Respekt für deine Anstrengungen. Ich habe noch nie ein derart umfangreiches Modul mit einer so guten Dokumentation gesehen.
Der Wechselrichter liefert alle benannten Daten, aber man bekommt derzeit nur einen Bruchteil in FHEM. In FHEM steht nur ein Mix aus PV und Bat als Leistungsangabe Richtung Hausnetz zur Verfügung.
ZitatReadings
SpotP: spotpower - Current power in watt delivered by the inverter
AvP01: average power 1 minute: average power in watt of the last minute
AvP05: average power 5 minutes: average power in watt of the five minutes
AvP15: average power 15 minutes: average power in watt of the fifteen minutes
SpotPDC1: current d.c. voltage delivered by string 1
SpotPDC2: current d.c. voltage delivered by string 2
TotalTodayP: generated power in Wh of the current day
AlltimeTotalP: all time generated power in Wh
Alarm1..3: alrm trigger 1..3. Set by parameter alarmN-value
Das sieht dann so aus:
ZitatAlarm1 0 2025-05-19 14:21:04
Alarm2 0 2025-05-19 14:21:04
Alarm3 0 2025-05-19 14:21:04
AlltimeTotalP 602784 2025-05-19 14:21:04
AvP01 1440 2025-05-19 14:21:04
AvP05 1356 2025-05-19 14:21:04
AvP15 1616 2025-05-19 14:21:04
SpotP 1413 2025-05-19 14:21:04
SpotPDC1 735 2025-05-19 14:21:04
SpotPDC2 766 2025-05-19 14:21:04
TodayTotalP 17194 2025-05-19 14:21:04
modulstate normal 2025-05-19 14:21:04
Die Werte können aber über den Homemanager und den Akku ausgelesen werden. Leider ist das Homemanager-Modul instabil und stürzt bei jedem Neustart ab.
Hallo,
vielen Dank dafür, 300P
Zitat von: 300P am 18 Mai 2025, 15:35:46Moin Zusammen !
Hier für diejenigen unter euch, die mehrere SMA Batteriewechselrichter nutzen und netzdienlich laden wollen. (Andere BWR natürlich mit Anpassung der Modus-Befehle)
Ich nutze im "ctrlUserExitFn" seit ein paar Tagen (u.a.) diesen Code und es läuft soweit gut damit.
Für 1 BWR ist der Code etwas tiefer auch dabei
Leider bekomme ich beim Einfügen des Codes in "ctrlUserExitFN" immer folgenden Fehler
Global symbol "$timestart" requires explicit package name (did you forget to declare "my $timestart"?) at (eval 118524) line 5.
Global symbol "$timeend" requires explicit package name (did you forget to declare "my $timeend"?) at (eval 118524) line 6.
Global symbol "$timestart" requires explicit package name (did you forget to declare "my $timestart"?) at (eval 118524) line 8.
Global symbol "$timeend" requires explicit package name (did you forget to declare "my $timeend"?) at (eval 118524) line 8.Kann man einfach statt
$timestart = 9; # ab welcher Uhrzeit soll es sein ===>> Wert evtl. anpassen
$timeend = 15; # bis wieviel Uhr soll es sein ===>> Wert evtl. anpassenfolgendes schreiben?
my $timestart = 9; # ab welcher Uhrzeit soll es sein ===>> Wert evtl. anpassen
my $timeend = 15; # bis wieviel Uhr soll es sein ===>> Wert evtl. anpassenDanke
oelidoc
1. Gibt es eine Möglichkeit dass die Werte in der Grafik automatisch geändert werden ohne jedes mal die Seite neu zu laden?
2. Kann man den Prozent Wert der Batterieladung auslesen (Bei mehreren Batterien)? Ist in den Readings nicht enthalten.
zu 1.
Bei mir aktuallisiert sic die Ansicht automatisch
2. Current_BatCharge_0X heisst das Reading
@Persuasiv,
vielen Dank :) Gebe mir Mühe...
ZitatDer Wechselrichter liefert alle benannten Daten, aber man bekommt derzeit nur einen Bruchteil in FHEM. In FHEM steht nur ein Mix aus PV und Bat als Leistungsangabe Richtung Hausnetz zur Verfügung.
Das habe ich befürchtet und ist sicherlich auch unterschiedlich je nachdem welches FHEM Modul den WR ausliest.
Hoffentlich gibt es zumindest die Angabe für etotal, also die durch PV erzeugte Energie, damit der reale Ertrag mit der Prognose verglichen werden kann für die darauf aufbauenden Berechnungen.
EDIT: AlltimeTotalP könnte dafür passen.
@oelidoc,
my $timestart = 9;
my $timeend = 15;
ist so richtig. Das "my" hat 300P sicher nur vergessen bzw. hatte die Variablen vorher mit my definiert.
LG,
Heiko
Zitatzu 1. Bei mir aktuallisiert sich die Ansicht automatisch
Geht bei mir nicht (neuste Version). Wie findet man den Fehler
Zitatzu 2. Current_BatCharge_0X heisst das Reading
Wird bei mir nicht angezeigt. Muss man da ein User Reading erzeugen und selbst aus den einzelnen Werten errechnen?
ZitatGeht bei mir nicht (neuste Version). Wie findet man den Fehler
Das ist nicht so sehr ein Modulproblem. Hier ein paar Hinweise:
- die autom. Aktualisierung geht nur in der Raumansicht, nicht in der Detailansicht.
- im benutzten FHEMWEB Device muß das Attr longpoll gesetzt sein (allg. FHEM Einstellung)
- das Reading state im SF-Device muß Events generieren, d.h. man darf es nicht unterbinden indem man state von
der Eventgenerierung ausschliesst indem man zum Beispiel event-on-change-reading setzt ohne state zu berücksichtigen
Das ist eigentlich schon alles was man beachten muß.
ZitatWird bei mir nicht angezeigt. Muss man da ein User Reading erzeugen und selbst aus den einzelnen Werten errechnen?
Nein, nicht nötig.
Zeig mal bitte dein Attribut setupBatteryDevXX.
ZitatZeig mal bitte dein Attribut setupBatteryDevXX.
attr solarforcast setupBatteryDev01 SENEC pin=-pout:W pout=AKKU-Entnahme:W cap=10000 charge=AKKU-Beladung
attr solarforcast setupBatteryDev02 Mqtt_cerbo pin=Batterie_Power_value:W pout=-pin cap=16600 charge=Batterie_value
Zitatdie autom. Aktualisierung geht nur in der Raumansicht, nicht in der Detailansicht.
Das war mein Fehler
Hallo,
ich bin gerade dabei, eine Batteriesteuerung mit SF einzurichten. Dabei ist mir aufgefallen, dass heute bei blauem Himmel die ganze Zeit Battery_ChargeRecommended_01 = 1 ist, obwohl der BYD HVS schon lange voll ist. Das liegt wahrscheinlich an dem BYDBox Modul, das die Daten für das SF Batterie Device liefert: der SOC steht dort auf (echten) 98%, was bei allen anderen Devices von SMA (WR, EM) als 100% angezeigt wird. Gehe ich recht in der Annahme, dass der Battery_ChargeRecommended_01 nur bei 100% auf 0 geht? Und wie kann ich bei der Batteriesteuerung dafür sorgen, dass 98% SOC der BYDBox als voller Akku gewertet werden?
Vielen Dank im voraus
oelidoc
Hallo zusammen,
Ich habe heute auf der Arbeit ein
update all
gemacht und von 1.51... auf 1.52.3 aktualisiert, danach ist leider FHEM nicht mehr gestartet, divison bei zero in Zeile 13987, ich bin mit dem Modul echt gut zufrieden habe aber leider schon mindestens 2 mal durch ein Update mein System geschrottet, das ist nicht gut für den WAF-Faktor.
Gibt es vielleicht ein paar Möglichkeiten das Fehler in der Art abgefangen werden das nur das Modul nicht arbeitet, aber das System noch startet?
Hier meine Korrektur, damit läuft FHEM wieder.
Ich bekomme jetzt aber There may be '3' incorrect value(s) in the 'con' key of the pvHistory Storage. ohne das im Log was auftaucht was ich resetten kann.
Viele Grüße und Danke für die viele Arbeit an dem Modul!
Michael
@Medel,
hier ist ein Fehler
attr solarforcast setupBatteryDev01 SENEC pin=-pout:W pout=AKKU-Entnahme:W cap=10000 charge=AKKU-Beladung
Richtig wäre nur pin=-pout ohne die Einheit.
Hallo Michael,
das tut mit wirklich leid, aber ein "divison bei zero" toleriert Perl nicht.
Bei aller Akribie kann es Zustände geben die bei 1000 Usern kein Problem darstellen, beim 1001sten gibt es eine Konstallation die einen Divisor "0" verursachen.
Wenn ich eine solche Stelle feststelle oder gemeldet bekomme, kann ich es fixen. Wie in diesem Fall.
Aber kleine Kritik ... ein Update eines produktiven Systems sollte man nicht remote machen. Fehler passieren trotz allen Tests durchaus, davor ist niemand gefeit.
Ich entschärfe diese Stelle.
ZitatIch bekomme jetzt aber There may be '3' incorrect value(s) in the 'con' key of the pvHistory Storage. ohne das im Log was auftaucht was ich resetten kann.
Mindests verbose 1 im Device gesetzt und dann Anlagencheck ausgeführt? Dann erscheinen die Logeinträge mit dem reset-Hinweis.
LG,
Heiko
Zitatattr solarforcast setupBatteryDev01 SENEC pin=-pout pout=AKKU-Entnahme:W cap=10000 charge=AKKU-Beladung
attr solarforcast setupBatteryDev02 Mqtt_cerbo pin=Batterie_Power_value:W pout=-pin cap=16600 charge=Batterie_value
hab es geändert. Keine Änderung. Kann den Wert nirgends finden.
Vielleicht habe ich es auch falsch geschrieben. In der Grafik ist der Wert richtig nur finde ich kein Reading das ich abfragen kann.
ZitatCurrent_BatCharge_01 49.49 %
Current_BatCharge_02 100.0 %
nur diese werden angezeigt es gibt kein Current_BatCharge_0X
In dem Beispiel wird in der Grafik jetzt 81% angezeigt, dies wollte ich abfragen.
Zitat von: DS_Starter am 19 Mai 2025, 18:19:15@oelidoc,
my $timestart = 9;
my $timeend = 15;
ist so richtig. Das "my" hat 300P sicher nur vergessen bzw. hatte die Variablen vorher mit my definiert.
LG,
Heiko
Sorry - bei mir wird das (wie vermutet) schon vorher in einem anderen Bereich / Code-Fragment initialisiert.
Ändere es in meinem Post "richtig" ab.
Gruß
300P
Zitatnur diese werden angezeigt es gibt kein Current_BatCharge_0X
Das sind sie doch. X ist nur ein Platzhalter, also Current_BatCharge_01, Current_BatCharge_02, ....
Was du meinst ist der gewichtete Durchschnitts-SoC aller Batterien wie in der Flußgrafik zu sehen.
Das Reading gibt es derzeit nicht, kann es aber zum Beispiel in ctrlSpecialReadings auswählbar zur Verfügung stellen.
Zitat von: oelidoc am 19 Mai 2025, 19:38:32Hallo,
ich bin gerade dabei, eine Batteriesteuerung mit SF einzurichten. Dabei ist mir aufgefallen, dass heute bei blauem Himmel die ganze Zeit Battery_ChargeRecommended_01 = 1 ist, obwohl der BYD HVS schon lange voll ist. Das liegt wahrscheinlich an dem BYDBox Modul, das die Daten für das SF Batterie Device liefert: der SOC steht dort auf (echten) 98%, was bei allen anderen Devices von SMA (WR, EM) als 100% angezeigt wird. Gehe ich recht in der Annahme, dass der Battery_ChargeRecommended_01 nur bei 100% auf 0 geht? Und wie kann ich bei der Batteriesteuerung dafür sorgen, dass 98% SOC der BYDBox als voller Akku gewertet werden?
Vielen Dank im voraus
oelidoc
Nein es muss nicht 100% SOC erreicht werden um auf Battery_ChargeRecommended_01 = 0 zu kommen.
Die Logik ist anders:
Lese doch evtl. das WIKI =>> netzdienlich <<== (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Unterst%C3%BCtzung_eines_netzdienlichen_Verhaltens)nochmals durch.
Wenn du es erst heute mittag eingerichtet hast - warte bis morgen - dann sollte es schon passen. ;)
(Vorausgesetzt das alles richtig eingerichtet ist)
Zitat von: 300P am 19 Mai 2025, 20:35:18Sorry - bei mir wird das (wie vermutet) schon vorher in einem anderen Bereich / Code-Fragment initialisiert.
Ändere es in meinem Post "richtig" ab.
Gruß
300P
Kein Problem, hast mir ja sehr geholfen!
Vielen Dank
oelidoc
Zitat von: 300P am 19 Mai 2025, 20:50:33Nein es muss nicht 100% SOC erreicht werden um auf Battery_ChargeRecommended_01 = 0 zu kommen.
Die Logik ist anders:
Lese doch evtl. das WIKI =>> netzdienlich <<== (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Unterst%C3%BCtzung_eines_netzdienlichen_Verhaltens)nochmals durch.
Wenn du es erst heute mittag eingerichtet hast - warte bis morgen - dann sollte es schon passen. ;)
(Vorausgesetzt das alles richtig eingerichtet ist)
Ja, mach ich - morgen ist auch noch ein Tag - melde mich, wenn´s nicht klappt
Gruß
oelidoc
Zitat von: Medel am 19 Mai 2025, 20:32:18Zitatattr solarforcast setupBatteryDev01 SENEC pin=-pout pout=AKKU-Entnahme:W cap=10000 charge=AKKU-Beladung
attr solarforcast setupBatteryDev02 Mqtt_cerbo pin=Batterie_Power_value:W pout=-pin cap=16600 charge=Batterie_value
hab es geändert. Keine Änderung. Kann den Wert nirgends finden.
Vielleicht habe ich es auch falsch geschrieben. In der Grafik ist der Wert richtig nur finde ich kein Reading das ich abfragen kann.
ZitatCurrent_BatCharge_01 49.49 %
Current_BatCharge_02 100.0 %
nur diese werden angezeigt es gibt kein Current_BatCharge_0X
In dem Beispiel wird in der Grafik jetzt 81% angezeigt, dies wollte ich abfragen.
Ich habs per UserReading realisiert:
(wird wohl keiner 999 Batterien haben O:-) )
attr Forecast userReadings Current_BatCharge999 {((ReadingsNum("SBS37","chargestatus",0) * 10 * ReadingsNum("SBS37","bat_rated_capacity",0)) + (ReadingsNum("SBS25_2","chargestatus",0) * 10 * ReadingsNum("SBS25_2","bat_rated_capacity",0))) / ( (ReadingsNum("SBS37","bat_rated_capacity",0) * 1000) + (ReadingsNum("SBS25_2","bat_rated_capacity",0)*1000))*100},
@oelidoc
ZitatUnd wie kann ich bei der Batteriesteuerung dafür sorgen, dass 98% SOC der BYDBox als voller Akku gewertet werden?
Im Attr ctrlBatSocManagementXX hast du den Schlüssel maxSoC zur Verfügung. Es ist primär für einen anderen Zweck vorgesehen, aber maxSoC=98 würde der Batteriesteuerung mitteilen, dass 98% erreicht werden sollen um "volle" Ladung zu erreichen.
Hallo Heiko,
Zitat von: DS_Starter am 19 Mai 2025, 20:59:00@oelidoc
Im Attr ctrlBatSocManagementXX hast du den Schlüssel maxSoC zur Verfügung. Es ist primär für einen anderen Zweck vorgesehen, aber maxSoC=98 würde der Batteriesteuerung mitteilen, dass 98% erreicht werden sollen um "volle" Ladung zu erreichen.
Hab ich mal so übernommen - werde morgen vormittag beobachten...
LG & vielen Dank
oelidoc
@Peter, @ahlermi, @all
ich habe die V 1.52.4 im contrib upgedated.
Enthalten ist:
- die Flußgrafik habe ich noch etwas ausgerichtet wie von Peter angemerkt (#2913)
- fix des Problems "devision by zero" (#2926)
@oelidoc,
wichtig ist noch zu beachten, dass Battery_ChargeRecommended_01=1 quasi die Standardeinstellung ist (auch Nachts). Heißt nichts anderes als dass die Batterie aufgeladen werden kann/sollte/könnte. Der Wert "0" bedeutet im Prinzip, dass man die Bat nicht bzw. nur bei Überschreitung des gesetzten Einspeiselimits laden sollte um Netzdienlichkeit in Verbindung mit der Vermeidung einer evtl. Drosselung der Anlage zu erreichen.
Ich will das jetzt nicht zerreissen.
Generel kann man schon den Dividend auf 0 abfragen vor der Kalkulation. Ist ja nicht nur in Perl so. Sehr viele Sprachen mögen es nicht durch 0 zu teilen.
Bestenfalls kommt eine Exception und der Teil wird übergangen. Worst case ist das es alles lahm legt.
Divisionen mit dynamischen Variabelen sind immer mit Vorsicht zu geniessen. Meine Devise "versuchen immer zu multiplizieren, wenn möglich".
36/1000 = 36*0.001
Aber das ist im Modul schon recht konsequent abgefangen. Was du hier aber sicher falsch gemacht hast vermutlich folgendes.
Ich vermute es handelt sich um folgende sub:
sub __calcFcQuality
Und das..
$pvrl = sprintf "%.0f", $pvrl;
$pvfc = sprintf "%.0f", $pvfc;
.. ist doch sinnfrei und vergünstigt das Verhalten ja eigentlich noch.
Du springst bei explizieter "0" raus. Das ist ja schon einmal lobenswert.
Aber danach schneidest du die Nachkommastellen konsequent weg und aus einem 0.99999 wird eine 0.
Zumal verstehe ich auch nicht warum die Nachkommastellen nicht mit einbezogen werden bei der kalkulation.
Zitatsub __calcFcQuality
Nein, es geht um eine Stelle in __calcNewFactor_migrated.
ZitatAber danach schneidest du die Nachkommastellen konsequent weg und aus einem 0.99999 wird eine 0.
Nicht wirklich, aus 0.99999 wird mit sprintf "%.0f" eine 1.
Aber die Stelle
$pvrl = sprintf "%.0f", $pvrl;
$pvfc = sprintf "%.0f", $pvfc;
kann ich rausnehmen, hast recht.
Allerdings ändert es nichts, weil wie gesagt andere Stelle.
Die habe ich aber entsprechend behandelt.
Edit: Habe die kleine Anpassung auch noch in die V 1.52.4 eingebaut und in das contrib geladen.
grad erst gesehen mmmhmmmm ;D :o :-X :))
Irgendwie sind bei den Updates heute meine "rules" "nodes" und "depht" geschrumpft.....
Könnte die Einrichtung der DC-Strings gewesen sein.
=> Macht aber nix - Ertrag ist z.Z. ja hoch - Batterien werden so oder zur Zeit immer voll.
ZitatIrgendwie sind bei den Updates heute meine "rules" "nodes" und "depht" geschrumpft.....
Könnte die Einrichtung der DC-Strings gewesen sein.
Eher nicht, geht dort nicht ein.
Wichtig ist, dass die Rohdaten nicht abhanden gekommen sind, schau dir "get ... valDecTree aiRawData" an ob das ok aussieht.
Number of datasets: 1367
sieht okay aus für mich
Trainiere einfach mal neu mit "set ... aiDecTree addInstAndTrain".
Bleibt so wie vorhin, nur kleine Unterschiede +/-1.
- lass ich so "liegen" -> ist zu spät jetzt.... ;)
Ja, dann passt es auch so. Wichtig sind immer die Rohdaten, die sollten nicht verloren gehen. Alles andere wird immer wieder neu aufgebaut. Die Rohdaten werden in einer der SF-Dateien gesichert. Steht im Wiki unter Backup/Restore.
Hast du die evtl. bei deinem "Hochwasser" nicht auf den neuen Raspi restored?
Ja - den RPI habe ich restored und bin dann mit den FHEM / Daten komplett auf einen QNAP-Container umgezogen.
(Der RPI bekommt das FHEM-Backup täglich draufgeschoben - QNAP macht so oder Snapshot - sicher ist sicher ) O:-)
Aber ich war am Wochenende schon wieder bei > 3000 "rules" ->> aiTreesPV bis auf 50 für einige Tage gesetzt - aktuell aber wieder auf 30 begrenzt. ;D
Naja die Zeit wird es wieder heilen..... 8)
PS:
Kleiner Hinweis für SMA-WR-Besitzer wegen der Solareingangsleistung und deren Darstellung in SF:
Es gibt aktuell evtl. einen kleinen Bug im zugehörigen SMAInverter-Modul wenn man das Reading "strings_pdc" dazu als Reading nutzt.
MadMax wird es wohl richten - er ist informiert.
Gruß
300P
Hallo zusammen,
in der V 1.52.4 in meinem contrib gibt es eine Erweiterung:
- das Attr ctrlSpecialReadings hat eine neue Auswahl "BatWeightedTotalSOC" zur Anzeige des resultierenden SOC aller Batterien
BatWeightedTotalSOC der resultierende (gewichtete) SOC über alle installierten Batterien
Bei Aktivierung wird das Reading special_BatWeightedTotalSOC erstellt.
Grüße,
Heiko
Hallo,
irgendwie bekomme ich das mit dem "netzdienlichem Verhalten" der Batterieladung nicht hin oder ich hab`s immer noch nicht verstanden :))
Ich habe keine Einspeisebegrenzung, die Batterie ist schon morgens voll, SF prognostiziert für 15 Uhr eine fast leere Batterie und Battery_ChargeRecommended_01 ist die ganze Zeit = 1. Irgendwas muss falsch eingestellt sein, ich finde es aber nicht. Ich kann mit meinem ModbusAttr Device für den STP8SE die Ladung unterbrechen, diese Funktionalität ist also m.E. gegeben.
Wo soll ich / wo wollt ihr gucken?
Hier mein SF Device:
define Sonnenschein SolarForecast
attr Sonnenschein comment update per "wget -qO /opt/fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr Sonnenschein consumer01 MQTT2_DVES_159462 type=heater power=1400 icon=sani_heating_automatic mode=can pcurr=ENERGY_Power:W swstate=state:.*on.*:.*off.* auto=1 etotal=ENERGY_Total:kWh mintime=SunPath:60:-65 interruptable=Thermostat_Kueche_Climate:measured-temp:(2[3-9]|[3-5][0-9])\.[0-9]:0.2 on=on off=off asynchron=1 exconfc=1
attr Sonnenschein consumer02 Teichpumpe type=other on=on off=off auto=1 power=30 mode=can mintime=360 notbefore=12 interruptable=1 icon=springbrunnen_icon locktime=5:1800 asynchron=1
attr Sonnenschein consumer03 MQTT2_DVES_693B50 type=dishwasher power=2400 on=on off=off pcurr=ENERGY_Power:W:5 etotal=ENERGY_Total:kWh icon=scene_dishwasher auto=1
attr Sonnenschein consumer04 MQTT2_DVES_1857F8 type=washingmachine power=2300 on=on off=off pcurr=ENERGY_Power:W etotal=ENERGY_Total:kWh icon=scene_washing_machine auto=1
attr Sonnenschein consumer05 MQTT2_DVES_17BC26 type=dryer power=900 on=on off=off pcurr=ENERGY_Power:W etotal=ENERGY_Total:kWh icon=scene_laundry_room auto=1
attr Sonnenschein consumer06 MQTT2_shellyplus1pm type=noSchedule power=1200 on=on off=off icon=coffee-machine pcurr=apower:W etotal=aenergy_total auto=1
attr Sonnenschein consumer07 MQTT2_zigbee_Plug_4 type=heater power=2000 icon=sani_heating_heatpump mode=can pcurr=power:W swstate=state:.*on.*:.*off.* auto=1 mintime=SunPath:60:-60 interruptable=1 on=on off=off asynchron=1 exconfc=1
attr Sonnenschein consumer08 MQTT2_DVES_44CEB0 type=heater power=1440 icon=sani_heating_automatic mode=can pcurr=ENERGY_Power:W swstate=state:.*on.*:.*off.* auto=1 etotal=ENERGY_Total:kWh mintime=SunPath:60:-65 interruptable=Thermostat_Arbeitszimmer_Climate:measured-temp:(2[3-9]|[3-5][0-9])\.[0-9]:0.2 on=on off=off asynchron=1 exconfc=1
attr Sonnenschein consumerControl detailLink=1
attr Sonnenschein ctrlBatSocManagement01 careCycle=20\
lowSoc=5\
maxSoC=98\
upSoC=50\
attr Sonnenschein ctrlDebug none
attr Sonnenschein ctrlLanguage DE
attr Sonnenschein ctrlUserExitFn {\
# BEGIN ######## Netzdienliches Laden ################\
my $dt = timestringsFromOffset (time, 0);;\
my $hour = $dt->{hour};; # aktuelle Stunde in 24h format (00-23)\
my $timestart = 8;; # ab welcher Uhrzeit soll es sein ===>> Wert evtl. anpassen\
my $timeend = 15;; # bis wieviel Uhr soll es sein ===>> Wert evtl. anpassen\
\
if (int $hour >= $timestart && int $hour < $timeend ) {\
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr\
\
\
my $curpowerbatin01 = ReadingsNum ($name, 'Current_PowerBatIn_01', 0);;\
my $curpowerbatout01 = ReadingsNum ($name, 'Current_PowerBatOut_01', 0);;\
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0);; # SoC Bat01 aktuell\
my $currentsurplus = (ReadingsNum ($name, 'Current_Surplus', 0) - 50);; # etwas abziehen zwecks weniger als Puffer\
my $batchargerequest01 = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0);; # Batterie01 muss geladen werden ?\
my $gridfriendlychargebat01 = ReadingsNum ($name, 'Battery_ChargeRecommended_01', 0);; # Batterie01 recommended ?\
my $curbatchargemin01= 30;; # erst ab Mindes-BAT01-SOC XY netzdienlich ===>> Wert evtl. anpassen 0..30\
my $bwr01 = "STP8SE";; # Name des 1ten BWR-Modbus-Device ===>> Wert evtl. anpassen\
\
\
if (int $gridfriendlychargebat01 eq 0) {\
# Nur wenn die Batterieladung01 SF-Systemseitig nicht empfohlen wird dann\
\
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended Battery01 $gridfriendlychargebat01 });;\
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0);; # SoC Bat01 aktuell\
\
if (int $gridfriendlychargebat01 eq 0 && $batchargerequest01 eq 0 && $curbatcharge01 > $curbatchargemin01) {\
# wenn bei Bat01 = 0 -beides- und SOC groß genug ->>dann unterbinden Laden Bat01\
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended only Battery01 Reading = $gridfriendlychargebat01 });;\
fhem("set $bwr01 Set_Leistung $currentsurplus");; # Watt Netzleistung am Übergabemesspunkt (WR1)\
fhem("set $bwr01 Set_Aktiv 802");; # 802 - Steuerung aktiv (WR1)\
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });;\
}\
else {\
if (int $gridfriendlychargebat01 eq 1 || $batchargerequest01 eq 1 || (($curbatcharge01 - 3) <= $curbatchargemin01)) {\
# wenn bei Bat01 = beides oder nur eins auf 1 steht ---dann bitte jetzt Steuerung aus / kein Laden unterbinden Bat01\
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended =>> Battery01 Reading = $gridfriendlychargebat01 and BatChargerequest =>> Battery01 Reading = $batchargerequest01 });;\
fhem("set $bwr01 Set_Leistung 0");; # Watt Netzleistung am Übergabemesspunkt (WR1)\
fhem("set $bwr01 Set_Aktiv 803");; # 803 - Steuerung nicht aktiv (WR1)\
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => not activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });;\
}\
}\
}\
}\
# ENDE ######## Netzdienliches Laden ################\
\
}
attr Sonnenschein disable 0
attr Sonnenschein event-on-change-reading .*
attr Sonnenschein flowGraphicControl animate=1 showconsumerdummy=0 showconsumerpower=1 showconsumerremaintime=0 homenodedyncol=1 strokeconsumerdyncol=0 inverterNodeIcon=inverter
attr Sonnenschein graphicBeam3Content consumptionForecast
attr Sonnenschein graphicBeam4Content consumption
attr Sonnenschein graphicBeamHeightLevel1 200
attr Sonnenschein graphicBeamHeightLevel2 100
attr Sonnenschein graphicControl energyUnit=Wh
attr Sonnenschein graphicShowNight 0
attr Sonnenschein plantControl showLink=1 genPVdeviation=daily
attr Sonnenschein room Photovoltaik
attr Sonnenschein setupBatteryDev01 BYDBox7.7 pout=BatteryPower:W pin=-pout intotal=Battery_1_ChargeE:W outtotal=Battery_1_DischargeE:W charge=SOC cap=7700 asynchron=1 show=1
attr Sonnenschein setupInverterDev01 SunnyTripower8.0SE asynchron=1 pv=state:W etotal=SPOT_EPVTOTAL:Wh capacity=8000
attr Sonnenschein setupInverterStrings StringA,StringB
attr Sonnenschein setupMeterDev SunnyHomeManager2.0 gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:Wh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:Wh feedprice=0.082:€ conprice=0.3564:€ asynchron=1
attr Sonnenschein setupRadiationAPI OpenMeteoDWD_D2-API
attr Sonnenschein setupStringAzimuth StringA=-36 StringB=54
attr Sonnenschein setupStringDeclination StringA=45 StringB=45
attr Sonnenschein setupStringPeak StringA=6 StringB=2.8
attr Sonnenschein setupWeatherDev1 OpenMeteoDWD_D2-API
attr Sonnenschein verbose 0
# FUUID 64577c31-f33f-74ea-4814-4087424dfb073f20
# FVERSION 76_SolarForecast.pm:v1.52.3-s29969/2025-05-17
# LCACHEFILE last write time: 12:19:57 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 12:21:52
# MODEL OpenMeteoDWDD2API
# NAME Sonnenschein
# NOTIFYDEV SunnyHomeManager2.0,MQTT2_DVES_159462,Teichpumpe,MQTT2_DVES_693B50,MQTT2_DVES_1857F8,MQTT2_DVES_17BC26,MQTT2_shellyplus1pm,MQTT2_zigbee_Plug_4,MQTT2_DVES_44CEB0,BYDBox7.7,SunnyTripower8.0SE
# NR 620
# NTFY_ORDER 50-Sonnenschein
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL OpenMeteoDWDD2API
# eventCount 848
# HELPER:
# 01M15DONE 1
# 03M15DONE 1
# 04M15DONE 1
# 05M15DONE 1
# 07M15DONE 1
# 08M15DONE 1
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV Sonnenschein
# SPGROOM
# VERSION 1.52.3
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 18
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:315092
# telnet telnetPort_127.0.0.1_43176
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name Sonnenschein
# tsnext 1747741994.12378
# OLDREADINGS:
# READINGS:
# 2025-05-20 12:21:26 Battery_ChargeRecommended_01 1
# 2025-05-20 12:21:26 Battery_ChargeRequest_01 0
# 2025-05-20 12:21:26 Battery_OptimumTargetSoC_01 5 %
# 2025-05-20 12:21:26 Current_AutarkyRate 99 %
# 2025-05-20 12:21:26 Current_BatCharge_01 91 %
# 2025-05-20 12:21:26 Current_Consumption 465 W
# 2025-05-20 12:21:26 Current_GridConsumption 6 W
# 2025-05-20 12:21:26 Current_GridFeedIn 0 W
# 2025-05-20 12:21:26 Current_PV 1987 W
# 2025-05-20 12:21:26 Current_PowerBatIn_01 1527.03 W
# 2025-05-20 12:21:26 Current_PowerBatOut_01 0 W
# 2025-05-20 12:21:26 Current_SelfConsumption 459 W
# 2025-05-20 12:21:26 Current_SelfConsumptionRate 23 %
# 2025-05-20 12:21:26 Current_Surplus 1522 W
# 2025-05-20 12:00:00 LastHourGridconsumptionReal 0 Wh
# 2025-05-20 12:00:00 LastHourPVforecast 6340 Wh
# 2025-05-20 12:00:00 LastHourPVreal 5145 Wh
# 2025-05-20 12:21:26 NextHours_Sum01_PVforecast 4299 Wh
# 2025-05-20 12:21:26 NextHours_Sum02_PVforecast 7925 Wh
# 2025-05-20 12:21:26 NextHours_Sum03_PVforecast 11249 Wh
# 2025-05-20 12:21:26 NextHours_Sum04_ConsumptionForecast 19013 Wh
# 2025-05-20 12:21:26 NextHours_Sum04_PVforecast 13788 Wh
# 2025-05-20 12:21:26 RestOfDayConsumptionForecast 26792 Wh
# 2025-05-20 12:21:26 RestOfDayPVforecast 19556 Wh
# 2025-05-20 00:59:59 Today_Hour01_BatIn_01 0 Wh
# 2025-05-20 00:59:59 Today_Hour01_BatOut_01 312 Wh
# 2025-05-20 00:59:59 Today_Hour01_GridConsumption 0 Wh
# 2025-05-20 00:59:59 Today_Hour01_GridFeedIn 0 Wh
# 2025-05-20 00:59:59 Today_Hour01_PVreal 0 Wh
# 2025-05-20 01:59:49 Today_Hour02_BatIn_01 0 Wh
# 2025-05-20 01:59:49 Today_Hour02_BatOut_01 317 Wh
# 2025-05-20 01:59:49 Today_Hour02_GridConsumption 0 Wh
# 2025-05-20 01:59:49 Today_Hour02_GridFeedIn 0 Wh
# 2025-05-20 01:59:49 Today_Hour02_PVreal 0 Wh
# 2025-05-20 02:59:49 Today_Hour03_BatIn_01 0 Wh
# 2025-05-20 02:59:49 Today_Hour03_BatOut_01 336 Wh
# 2025-05-20 02:59:49 Today_Hour03_GridConsumption 0 Wh
# 2025-05-20 02:59:49 Today_Hour03_GridFeedIn 0 Wh
# 2025-05-20 02:59:49 Today_Hour03_PVreal 0 Wh
# 2025-05-20 03:59:49 Today_Hour04_BatIn_01 0 Wh
# 2025-05-20 03:59:49 Today_Hour04_BatOut_01 331 Wh
# 2025-05-20 03:59:49 Today_Hour04_GridConsumption 0 Wh
# 2025-05-20 03:59:49 Today_Hour04_GridFeedIn 0 Wh
# 2025-05-20 03:59:49 Today_Hour04_PVreal 0 Wh
# 2025-05-20 04:59:49 Today_Hour05_BatIn_01 0 Wh
# 2025-05-20 04:59:49 Today_Hour05_BatOut_01 324 Wh
# 2025-05-20 04:59:49 Today_Hour05_GridConsumption 0 Wh
# 2025-05-20 04:59:49 Today_Hour05_GridFeedIn 0 Wh
# 2025-05-20 04:59:49 Today_Hour05_PVreal 0 Wh
# 2025-05-20 05:59:58 Today_Hour06_BatIn_01 0 Wh
# 2025-05-20 05:59:58 Today_Hour06_BatOut_01 285 Wh
# 2025-05-20 05:59:58 Today_Hour06_GridConsumption 0 Wh
# 2025-05-20 05:59:58 Today_Hour06_GridFeedIn 0 Wh
# 2025-05-20 05:59:58 Today_Hour06_PVforecast 15 Wh
# 2025-05-20 05:59:58 Today_Hour06_PVreal 27 Wh
# 2025-05-20 06:59:49 Today_Hour07_BatIn_01 59 Wh
# 2025-05-20 06:59:49 Today_Hour07_BatOut_01 36 Wh
# 2025-05-20 06:59:49 Today_Hour07_GridConsumption 0 Wh
# 2025-05-20 06:59:49 Today_Hour07_GridFeedIn 0 Wh
# 2025-05-20 06:59:49 Today_Hour07_PVforecast 376 Wh
# 2025-05-20 06:59:49 Today_Hour07_PVreal 360 Wh
# 2025-05-20 07:59:49 Today_Hour08_BatIn_01 1373 Wh
# 2025-05-20 07:59:49 Today_Hour08_BatOut_01 0 Wh
# 2025-05-20 07:59:49 Today_Hour08_GridConsumption 0 Wh
# 2025-05-20 07:59:49 Today_Hour08_GridFeedIn 0 Wh
# 2025-05-20 07:59:49 Today_Hour08_PVforecast 1680 Wh
# 2025-05-20 07:59:49 Today_Hour08_PVreal 1790 Wh
# 2025-05-20 08:59:49 Today_Hour09_BatIn_01 2370 Wh
# 2025-05-20 08:59:49 Today_Hour09_BatOut_01 0 Wh
# 2025-05-20 08:59:49 Today_Hour09_GridConsumption 0 Wh
# 2025-05-20 08:59:49 Today_Hour09_GridFeedIn 0 Wh
# 2025-05-20 08:59:49 Today_Hour09_PVforecast 3062 Wh
# 2025-05-20 08:59:49 Today_Hour09_PVreal 3329 Wh
# 2025-05-20 09:59:49 Today_Hour10_BatIn_01 561 Wh
# 2025-05-20 09:59:49 Today_Hour10_BatOut_01 182 Wh
# 2025-05-20 09:59:49 Today_Hour10_GridConsumption 0 Wh
# 2025-05-20 09:59:49 Today_Hour10_GridFeedIn 3 Wh
# 2025-05-20 09:59:49 Today_Hour10_PVforecast 3421 Wh
# 2025-05-20 09:59:49 Today_Hour10_PVreal 4042 Wh
# 2025-05-20 10:59:49 Today_Hour11_BatIn_01 447 Wh
# 2025-05-20 10:59:49 Today_Hour11_BatOut_01 10 Wh
# 2025-05-20 10:59:49 Today_Hour11_GridConsumption 0 Wh
# 2025-05-20 10:59:49 Today_Hour11_GridFeedIn 4 Wh
# 2025-05-20 10:59:49 Today_Hour11_PVforecast 5775 Wh
# 2025-05-20 10:59:49 Today_Hour11_PVreal 4801 Wh
# 2025-05-20 11:59:49 Today_Hour12_BatIn_01 0 Wh
# 2025-05-20 11:59:49 Today_Hour12_BatOut_01 0 Wh
# 2025-05-20 11:59:49 Today_Hour12_GridConsumption 0 Wh
# 2025-05-20 11:59:49 Today_Hour12_GridFeedIn 5 Wh
# 2025-05-20 11:59:49 Today_Hour12_PVforecast 6340 Wh
# 2025-05-20 11:59:49 Today_Hour12_PVreal 5145 Wh
# 2025-05-20 12:21:26 Today_Hour13_BatIn_01 547 Wh
# 2025-05-20 12:21:26 Today_Hour13_BatOut_01 0 Wh
# 2025-05-20 12:21:26 Today_Hour13_GridConsumption 0 Wh
# 2025-05-20 12:21:26 Today_Hour13_GridFeedIn 1 Wh
# 2025-05-20 12:21:26 Today_Hour13_PVforecast 4760 Wh
# 2025-05-20 12:21:26 Today_Hour13_PVreal 1517 Wh
# 2025-05-20 12:21:26 Today_Hour14_PVforecast 3504 Wh
# 2025-05-20 12:21:26 Today_Hour15_PVforecast 3838 Wh
# 2025-05-20 12:21:26 Today_Hour16_PVforecast 2436 Wh
# 2025-05-20 12:21:26 Today_Hour17_PVforecast 2717 Wh
# 2025-05-20 12:21:26 Today_Hour18_PVforecast 1294 Wh
# 2025-05-20 12:21:26 Today_Hour19_PVforecast 1240 Wh
# 2025-05-20 12:21:26 Today_Hour20_PVforecast 1019 Wh
# 2025-05-20 12:21:26 Today_Hour21_PVforecast 480 Wh
# 2025-05-20 12:21:26 Today_Hour22_PVforecast 14 Wh
# 2025-05-20 12:21:26 Today_MaxPVforecast 6340 Wh
# 2025-05-20 12:21:26 Today_MaxPVforecastTime 2025-05-20 11:00:00
# 2025-05-20 12:21:26 Today_PVforecast 41971 Wh
# 2025-05-20 12:21:26 Today_PVreal 21011 Wh
# 2025-05-20 12:21:26 Today_SunRise 05:34
# 2025-05-20 12:21:26 Today_SunSet 21:24
# 2025-05-20 12:21:26 Tomorrow_ConsumptionForecast 44628 Wh
# 2025-05-20 12:21:26 Tomorrow_PVforecast 52114 Wh
# 2025-05-20 12:21:26 Tomorrow_SunRise 05:32
# 2025-05-20 12:21:26 Tomorrow_SunSet 21:25
# 2025-05-20 12:21:26 consumer01 name='Cecotec Radiator' state='off' mode='can' planningstate='planned'
# 2025-05-20 12:21:26 consumer01_currentPower 0 W
# 2025-05-20 12:21:26 consumer01_planned_start 20.05.2025 12:15:05
# 2025-05-20 12:21:26 consumer01_planned_stop 20.05.2025 20:18:59
# 2025-05-20 12:21:26 consumer02 name='Teichpumpe' state='on' mode='can' planningstate='started' remainLockTime='522'
# 2025-05-20 12:21:26 consumer02_planned_start 20.05.2025 12:00:08
# 2025-05-20 12:21:26 consumer02_planned_stop 20.05.2025 18:00:08
# 2025-05-20 12:21:26 consumer03 name='Spülmaschine' state='on' mode='can' planningstate='planned'
# 2025-05-20 12:21:26 consumer03_currentPower 1 W
# 2025-05-20 12:21:26 consumer03_planned_start 20.05.2025 12:15:05
# 2025-05-20 12:21:26 consumer03_planned_stop 20.05.2025 15:15:05
# 2025-05-20 12:21:26 consumer04 name='Waschmaschine' state='on' mode='can' planningstate='planned'
# 2025-05-20 12:21:26 consumer04_currentPower 0 W
# 2025-05-20 12:21:26 consumer04_planned_start 20.05.2025 12:15:05
# 2025-05-20 12:21:26 consumer04_planned_stop 20.05.2025 14:15:05
# 2025-05-20 12:21:26 consumer05 name='Trockner' state='on' mode='can' planningstate='planned'
# 2025-05-20 12:21:26 consumer05_currentPower 0 W
# 2025-05-20 12:21:26 consumer05_planned_start 20.05.2025 12:15:05
# 2025-05-20 12:21:26 consumer05_planned_stop 20.05.2025 13:45:05
# 2025-05-20 12:21:26 consumer06 name='Kaffeemaschine' state='off' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
# 2025-05-20 12:21:26 consumer06_currentPower 0 W
# 2025-05-20 12:21:26 consumer07 name='Trotec Lüfter' state='off' mode='can' planningstate='planned'
# 2025-05-20 12:21:26 consumer07_currentPower 0 W
# 2025-05-20 12:21:26 consumer07_planned_start 20.05.2025 12:15:05
# 2025-05-20 12:21:26 consumer07_planned_stop 20.05.2025 20:23:59
# 2025-05-20 12:21:26 consumer08 name='Trotec Radiator' state='off' mode='can' planningstate='planned'
# 2025-05-20 12:21:26 consumer08_currentPower 0 W
# 2025-05-20 12:21:26 consumer08_planned_start 20.05.2025 12:15:05
# 2025-05-20 12:21:26 consumer08_planned_stop 20.05.2025 20:18:59
# 2025-05-20 12:20:42 nextCycletime 12:21:52
# 2025-05-20 12:09:04 nextRadiationAPICall nach 20.05.2025 12:24:04
# 2025-05-20 06:00:04 pvCorrectionFactor_06 1.29 (automatic - old factor: 0.54, AI result used, Sun Alt range: 0, Cloud range: 100, Days in range: 2)
# 2025-05-20 07:00:03 pvCorrectionFactor_07 0.67 (automatic - old factor: 0.72, AI result used, Sun Alt range: 5, Cloud range: 100, Days in range: 6)
# 2025-05-20 08:00:04 pvCorrectionFactor_08 0.76 (automatic - old factor: 0.74, AI result used, Sun Alt range: 15, Cloud range: 100, Days in range: 5)
# 2025-05-20 09:00:05 pvCorrectionFactor_09 1.07 (automatic - old factor: 0.84, AI result used, Sun Alt range: 25, Cloud range: 90, Days in range: 2)
# 2025-05-20 10:00:04 pvCorrectionFactor_10 0.97 (automatic - old factor: 0.77, Sun Alt range: 35, Cloud range: 80, Days in range: 2)
# 2025-05-19 11:00:05 pvCorrectionFactor_11 0.89 (automatic - old factor: 0.96, Sun Alt range: 45, Cloud range: 00, Days in range: 2)
# 2025-05-19 12:00:05 pvCorrectionFactor_12 0.89 (automatic - old factor: 0.90, AI result used, Sun Alt range: 50, Cloud range: 00, Days in range: 7)
# 2025-05-19 13:00:05 pvCorrectionFactor_13 0.91 (automatic - old factor: 0.92, AI result used, Sun Alt range: 55, Cloud range: 00, Days in range: 8)
# 2025-05-19 14:00:05 pvCorrectionFactor_14 0.99 (automatic - old factor: 0.92, Sun Alt range: 60, Cloud range: 00, Days in range: 3)
# 2025-05-19 15:00:04 pvCorrectionFactor_15 0.91 (automatic - old factor: 0.92, Sun Alt range: 55, Cloud range: 00, Days in range: 8)
# 2025-05-19 16:00:04 pvCorrectionFactor_16 0.88 (automatic - old factor: 0.85, AI result used, Sun Alt range: 50, Cloud range: 00, Days in range: 4)
# 2025-05-19 17:00:05 pvCorrectionFactor_17 0.88 (automatic - old factor: 1.11, AI result used, Sun Alt range: 45, Cloud range: 00, Days in range: 2)
# 2025-05-19 18:00:05 pvCorrectionFactor_18 0.86 (automatic - old factor: 0.88, AI result used, Sun Alt range: 35, Cloud range: 00, Days in range: 4)
# 2025-05-19 19:00:04 pvCorrectionFactor_19 0.92 (automatic - old factor: 0.93, AI result used, Sun Alt range: 25, Cloud range: 00, Days in range: 5)
# 2025-05-19 20:00:02 pvCorrectionFactor_20 0.92 (automatic - old factor: 0.82, AI result used, Sun Alt range: 15, Cloud range: 30, Days in range: 2)
# 2025-05-19 21:00:05 pvCorrectionFactor_21 0.59 (automatic - old factor: 0.60, AI result used, Sun Alt range: 5, Cloud range: 00, Days in range: 10)
# 2025-05-20 12:21:26 pvCorrectionFactor_Auto standby (remains in standby for 0.20 hours)
# 2025-05-20 12:21:28 state updated
# hmccu:
#
setstate Sonnenschein updated
setstate Sonnenschein 2025-05-20 11:06:54 .associatedWith SunnyHomeManager2.0 MQTT2_DVES_159462 Teichpumpe MQTT2_DVES_693B50 MQTT2_DVES_1857F8 MQTT2_DVES_17BC26 MQTT2_shellyplus1pm MQTT2_zigbee_Plug_4 MQTT2_DVES_44CEB0 BYDBox7.7 SunnyTripower8.0SE
setstate Sonnenschein 2025-05-20 12:21:26 .lastupdateForecastValues 1747736486
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_01_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_01_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_02_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_02_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_03_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_03_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_04_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_04_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_05_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_05_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_06_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_06_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_07_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_07_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_08_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_08_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_09_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_09_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_10_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_10_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_11_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_11_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_12_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_12_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_13_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_13_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_14_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_14_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_15_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_15_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_16_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_16_cloudcover done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_17_apipercentil done
setstate Sonnenschein 2025-04-18 17:51:29 .pvCorrectionFactor_17_cloudcover done
setstate Sonnenschein 2025-04-18 18:00:05 .pvCorrectionFactor_18_apipercentil done
setstate Sonnenschein 2025-04-18 18:00:05 .pvCorrectionFactor_18_cloudcover done
setstate Sonnenschein 2025-05-20 10:32:07 .pvCorrectionFactor_Auto_Soll on_complex_api_ai
setstate Sonnenschein 2025-05-20 01:00:04 .signaldone_01 done
setstate Sonnenschein 2025-05-20 02:00:04 .signaldone_02 done
setstate Sonnenschein 2025-05-20 03:00:05 .signaldone_03 done
setstate Sonnenschein 2025-05-20 04:00:04 .signaldone_04 done
setstate Sonnenschein 2025-05-20 05:00:04 .signaldone_05 done
setstate Sonnenschein 2025-05-20 06:00:04 .signaldone_06 done
setstate Sonnenschein 2025-05-20 07:00:03 .signaldone_07 done
setstate Sonnenschein 2025-05-20 08:00:04 .signaldone_08 done
setstate Sonnenschein 2025-05-20 09:00:05 .signaldone_09 done
setstate Sonnenschein 2025-05-20 10:00:04 .signaldone_10 done
setstate Sonnenschein 2025-05-20 00:04:10 .signaldone_24 done
setstate Sonnenschein 2025-05-20 12:21:26 Battery_ChargeRecommended_01 1
setstate Sonnenschein 2025-05-20 12:21:26 Battery_ChargeRequest_01 0
setstate Sonnenschein 2025-05-20 12:21:26 Battery_OptimumTargetSoC_01 5 %
setstate Sonnenschein 2025-05-20 12:21:26 Current_AutarkyRate 99 %
setstate Sonnenschein 2025-05-20 12:21:26 Current_BatCharge_01 91 %
setstate Sonnenschein 2025-05-20 12:21:26 Current_Consumption 465 W
setstate Sonnenschein 2025-05-20 12:21:26 Current_GridConsumption 6 W
setstate Sonnenschein 2025-05-20 12:21:26 Current_GridFeedIn 0 W
setstate Sonnenschein 2025-05-20 12:21:26 Current_PV 1987 W
setstate Sonnenschein 2025-05-20 12:21:26 Current_PowerBatIn_01 1527.03 W
setstate Sonnenschein 2025-05-20 12:21:26 Current_PowerBatOut_01 0 W
setstate Sonnenschein 2025-05-20 12:21:26 Current_SelfConsumption 459 W
setstate Sonnenschein 2025-05-20 12:21:26 Current_SelfConsumptionRate 23 %
setstate Sonnenschein 2025-05-20 12:21:26 Current_Surplus 1522 W
setstate Sonnenschein 2025-05-20 12:00:00 LastHourGridconsumptionReal 0 Wh
setstate Sonnenschein 2025-05-20 12:00:00 LastHourPVforecast 6340 Wh
setstate Sonnenschein 2025-05-20 12:00:00 LastHourPVreal 5145 Wh
setstate Sonnenschein 2025-05-20 12:21:26 NextHours_Sum01_PVforecast 4299 Wh
setstate Sonnenschein 2025-05-20 12:21:26 NextHours_Sum02_PVforecast 7925 Wh
setstate Sonnenschein 2025-05-20 12:21:26 NextHours_Sum03_PVforecast 11249 Wh
setstate Sonnenschein 2025-05-20 12:21:26 NextHours_Sum04_ConsumptionForecast 19013 Wh
setstate Sonnenschein 2025-05-20 12:21:26 NextHours_Sum04_PVforecast 13788 Wh
setstate Sonnenschein 2025-05-20 12:21:26 RestOfDayConsumptionForecast 26792 Wh
setstate Sonnenschein 2025-05-20 12:21:26 RestOfDayPVforecast 19556 Wh
setstate Sonnenschein 2025-05-20 00:59:59 Today_Hour01_BatIn_01 0 Wh
setstate Sonnenschein 2025-05-20 00:59:59 Today_Hour01_BatOut_01 312 Wh
setstate Sonnenschein 2025-05-20 00:59:59 Today_Hour01_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 00:59:59 Today_Hour01_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 00:59:59 Today_Hour01_PVreal 0 Wh
setstate Sonnenschein 2025-05-20 01:59:49 Today_Hour02_BatIn_01 0 Wh
setstate Sonnenschein 2025-05-20 01:59:49 Today_Hour02_BatOut_01 317 Wh
setstate Sonnenschein 2025-05-20 01:59:49 Today_Hour02_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 01:59:49 Today_Hour02_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 01:59:49 Today_Hour02_PVreal 0 Wh
setstate Sonnenschein 2025-05-20 02:59:49 Today_Hour03_BatIn_01 0 Wh
setstate Sonnenschein 2025-05-20 02:59:49 Today_Hour03_BatOut_01 336 Wh
setstate Sonnenschein 2025-05-20 02:59:49 Today_Hour03_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 02:59:49 Today_Hour03_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 02:59:49 Today_Hour03_PVreal 0 Wh
setstate Sonnenschein 2025-05-20 03:59:49 Today_Hour04_BatIn_01 0 Wh
setstate Sonnenschein 2025-05-20 03:59:49 Today_Hour04_BatOut_01 331 Wh
setstate Sonnenschein 2025-05-20 03:59:49 Today_Hour04_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 03:59:49 Today_Hour04_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 03:59:49 Today_Hour04_PVreal 0 Wh
setstate Sonnenschein 2025-05-20 04:59:49 Today_Hour05_BatIn_01 0 Wh
setstate Sonnenschein 2025-05-20 04:59:49 Today_Hour05_BatOut_01 324 Wh
setstate Sonnenschein 2025-05-20 04:59:49 Today_Hour05_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 04:59:49 Today_Hour05_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 04:59:49 Today_Hour05_PVreal 0 Wh
setstate Sonnenschein 2025-05-20 05:59:58 Today_Hour06_BatIn_01 0 Wh
setstate Sonnenschein 2025-05-20 05:59:58 Today_Hour06_BatOut_01 285 Wh
setstate Sonnenschein 2025-05-20 05:59:58 Today_Hour06_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 05:59:58 Today_Hour06_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 05:59:58 Today_Hour06_PVforecast 15 Wh
setstate Sonnenschein 2025-05-20 05:59:58 Today_Hour06_PVreal 27 Wh
setstate Sonnenschein 2025-05-20 06:59:49 Today_Hour07_BatIn_01 59 Wh
setstate Sonnenschein 2025-05-20 06:59:49 Today_Hour07_BatOut_01 36 Wh
setstate Sonnenschein 2025-05-20 06:59:49 Today_Hour07_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 06:59:49 Today_Hour07_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 06:59:49 Today_Hour07_PVforecast 376 Wh
setstate Sonnenschein 2025-05-20 06:59:49 Today_Hour07_PVreal 360 Wh
setstate Sonnenschein 2025-05-20 07:59:49 Today_Hour08_BatIn_01 1373 Wh
setstate Sonnenschein 2025-05-20 07:59:49 Today_Hour08_BatOut_01 0 Wh
setstate Sonnenschein 2025-05-20 07:59:49 Today_Hour08_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 07:59:49 Today_Hour08_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 07:59:49 Today_Hour08_PVforecast 1680 Wh
setstate Sonnenschein 2025-05-20 07:59:49 Today_Hour08_PVreal 1790 Wh
setstate Sonnenschein 2025-05-20 08:59:49 Today_Hour09_BatIn_01 2370 Wh
setstate Sonnenschein 2025-05-20 08:59:49 Today_Hour09_BatOut_01 0 Wh
setstate Sonnenschein 2025-05-20 08:59:49 Today_Hour09_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 08:59:49 Today_Hour09_GridFeedIn 0 Wh
setstate Sonnenschein 2025-05-20 08:59:49 Today_Hour09_PVforecast 3062 Wh
setstate Sonnenschein 2025-05-20 08:59:49 Today_Hour09_PVreal 3329 Wh
setstate Sonnenschein 2025-05-20 09:59:49 Today_Hour10_BatIn_01 561 Wh
setstate Sonnenschein 2025-05-20 09:59:49 Today_Hour10_BatOut_01 182 Wh
setstate Sonnenschein 2025-05-20 09:59:49 Today_Hour10_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 09:59:49 Today_Hour10_GridFeedIn 3 Wh
setstate Sonnenschein 2025-05-20 09:59:49 Today_Hour10_PVforecast 3421 Wh
setstate Sonnenschein 2025-05-20 09:59:49 Today_Hour10_PVreal 4042 Wh
setstate Sonnenschein 2025-05-20 10:59:49 Today_Hour11_BatIn_01 447 Wh
setstate Sonnenschein 2025-05-20 10:59:49 Today_Hour11_BatOut_01 10 Wh
setstate Sonnenschein 2025-05-20 10:59:49 Today_Hour11_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 10:59:49 Today_Hour11_GridFeedIn 4 Wh
setstate Sonnenschein 2025-05-20 10:59:49 Today_Hour11_PVforecast 5775 Wh
setstate Sonnenschein 2025-05-20 10:59:49 Today_Hour11_PVreal 4801 Wh
setstate Sonnenschein 2025-05-20 11:59:49 Today_Hour12_BatIn_01 0 Wh
setstate Sonnenschein 2025-05-20 11:59:49 Today_Hour12_BatOut_01 0 Wh
setstate Sonnenschein 2025-05-20 11:59:49 Today_Hour12_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 11:59:49 Today_Hour12_GridFeedIn 5 Wh
setstate Sonnenschein 2025-05-20 11:59:49 Today_Hour12_PVforecast 6340 Wh
setstate Sonnenschein 2025-05-20 11:59:49 Today_Hour12_PVreal 5145 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour13_BatIn_01 547 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour13_BatOut_01 0 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour13_GridConsumption 0 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour13_GridFeedIn 1 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour13_PVforecast 4760 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour13_PVreal 1517 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour14_PVforecast 3504 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour15_PVforecast 3838 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour16_PVforecast 2436 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour17_PVforecast 2717 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour18_PVforecast 1294 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour19_PVforecast 1240 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour20_PVforecast 1019 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour21_PVforecast 480 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_Hour22_PVforecast 14 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_MaxPVforecast 6340 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_MaxPVforecastTime 2025-05-20 11:00:00
setstate Sonnenschein 2025-05-20 12:21:26 Today_PVforecast 41971 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_PVreal 21011 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Today_SunRise 05:34
setstate Sonnenschein 2025-05-20 12:21:26 Today_SunSet 21:24
setstate Sonnenschein 2025-05-20 12:21:26 Tomorrow_ConsumptionForecast 44628 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Tomorrow_PVforecast 52114 Wh
setstate Sonnenschein 2025-05-20 12:21:26 Tomorrow_SunRise 05:32
setstate Sonnenschein 2025-05-20 12:21:26 Tomorrow_SunSet 21:25
setstate Sonnenschein 2025-05-20 12:21:26 consumer01 name='Cecotec Radiator' state='off' mode='can' planningstate='planned'
setstate Sonnenschein 2025-05-20 12:21:26 consumer01_currentPower 0 W
setstate Sonnenschein 2025-05-20 12:21:26 consumer01_planned_start 20.05.2025 12:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer01_planned_stop 20.05.2025 20:18:59
setstate Sonnenschein 2025-05-20 12:21:26 consumer02 name='Teichpumpe' state='on' mode='can' planningstate='started' remainLockTime='522'
setstate Sonnenschein 2025-05-20 12:21:26 consumer02_planned_start 20.05.2025 12:00:08
setstate Sonnenschein 2025-05-20 12:21:26 consumer02_planned_stop 20.05.2025 18:00:08
setstate Sonnenschein 2025-05-20 12:21:26 consumer03 name='Spülmaschine' state='on' mode='can' planningstate='planned'
setstate Sonnenschein 2025-05-20 12:21:26 consumer03_currentPower 1 W
setstate Sonnenschein 2025-05-20 12:21:26 consumer03_planned_start 20.05.2025 12:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer03_planned_stop 20.05.2025 15:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer04 name='Waschmaschine' state='on' mode='can' planningstate='planned'
setstate Sonnenschein 2025-05-20 12:21:26 consumer04_currentPower 0 W
setstate Sonnenschein 2025-05-20 12:21:26 consumer04_planned_start 20.05.2025 12:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer04_planned_stop 20.05.2025 14:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer05 name='Trockner' state='on' mode='can' planningstate='planned'
setstate Sonnenschein 2025-05-20 12:21:26 consumer05_currentPower 0 W
setstate Sonnenschein 2025-05-20 12:21:26 consumer05_planned_start 20.05.2025 12:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer05_planned_stop 20.05.2025 13:45:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer06 name='Kaffeemaschine' state='off' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
setstate Sonnenschein 2025-05-20 12:21:26 consumer06_currentPower 0 W
setstate Sonnenschein 2025-05-20 12:21:26 consumer07 name='Trotec Lüfter' state='off' mode='can' planningstate='planned'
setstate Sonnenschein 2025-05-20 12:21:26 consumer07_currentPower 0 W
setstate Sonnenschein 2025-05-20 12:21:26 consumer07_planned_start 20.05.2025 12:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer07_planned_stop 20.05.2025 20:23:59
setstate Sonnenschein 2025-05-20 12:21:26 consumer08 name='Trotec Radiator' state='off' mode='can' planningstate='planned'
setstate Sonnenschein 2025-05-20 12:21:26 consumer08_currentPower 0 W
setstate Sonnenschein 2025-05-20 12:21:26 consumer08_planned_start 20.05.2025 12:15:05
setstate Sonnenschein 2025-05-20 12:21:26 consumer08_planned_stop 20.05.2025 20:18:59
setstate Sonnenschein 2025-05-20 12:20:42 nextCycletime 12:21:52
setstate Sonnenschein 2025-05-20 12:09:04 nextRadiationAPICall nach 20.05.2025 12:24:04
setstate Sonnenschein 2025-05-20 06:00:04 pvCorrectionFactor_06 1.29 (automatic - old factor: 0.54, AI result used, Sun Alt range: 0, Cloud range: 100, Days in range: 2)
setstate Sonnenschein 2025-05-20 07:00:03 pvCorrectionFactor_07 0.67 (automatic - old factor: 0.72, AI result used, Sun Alt range: 5, Cloud range: 100, Days in range: 6)
setstate Sonnenschein 2025-05-20 08:00:04 pvCorrectionFactor_08 0.76 (automatic - old factor: 0.74, AI result used, Sun Alt range: 15, Cloud range: 100, Days in range: 5)
setstate Sonnenschein 2025-05-20 09:00:05 pvCorrectionFactor_09 1.07 (automatic - old factor: 0.84, AI result used, Sun Alt range: 25, Cloud range: 90, Days in range: 2)
setstate Sonnenschein 2025-05-20 10:00:04 pvCorrectionFactor_10 0.97 (automatic - old factor: 0.77, Sun Alt range: 35, Cloud range: 80, Days in range: 2)
setstate Sonnenschein 2025-05-19 11:00:05 pvCorrectionFactor_11 0.89 (automatic - old factor: 0.96, Sun Alt range: 45, Cloud range: 00, Days in range: 2)
setstate Sonnenschein 2025-05-19 12:00:05 pvCorrectionFactor_12 0.89 (automatic - old factor: 0.90, AI result used, Sun Alt range: 50, Cloud range: 00, Days in range: 7)
setstate Sonnenschein 2025-05-19 13:00:05 pvCorrectionFactor_13 0.91 (automatic - old factor: 0.92, AI result used, Sun Alt range: 55, Cloud range: 00, Days in range: 8)
setstate Sonnenschein 2025-05-19 14:00:05 pvCorrectionFactor_14 0.99 (automatic - old factor: 0.92, Sun Alt range: 60, Cloud range: 00, Days in range: 3)
setstate Sonnenschein 2025-05-19 15:00:04 pvCorrectionFactor_15 0.91 (automatic - old factor: 0.92, Sun Alt range: 55, Cloud range: 00, Days in range: 8)
setstate Sonnenschein 2025-05-19 16:00:04 pvCorrectionFactor_16 0.88 (automatic - old factor: 0.85, AI result used, Sun Alt range: 50, Cloud range: 00, Days in range: 4)
setstate Sonnenschein 2025-05-19 17:00:05 pvCorrectionFactor_17 0.88 (automatic - old factor: 1.11, AI result used, Sun Alt range: 45, Cloud range: 00, Days in range: 2)
setstate Sonnenschein 2025-05-19 18:00:05 pvCorrectionFactor_18 0.86 (automatic - old factor: 0.88, AI result used, Sun Alt range: 35, Cloud range: 00, Days in range: 4)
setstate Sonnenschein 2025-05-19 19:00:04 pvCorrectionFactor_19 0.92 (automatic - old factor: 0.93, AI result used, Sun Alt range: 25, Cloud range: 00, Days in range: 5)
setstate Sonnenschein 2025-05-19 20:00:02 pvCorrectionFactor_20 0.92 (automatic - old factor: 0.82, AI result used, Sun Alt range: 15, Cloud range: 30, Days in range: 2)
setstate Sonnenschein 2025-05-19 21:00:05 pvCorrectionFactor_21 0.59 (automatic - old factor: 0.60, AI result used, Sun Alt range: 5, Cloud range: 00, Days in range: 10)
setstate Sonnenschein 2025-05-20 12:21:26 pvCorrectionFactor_Auto standby (remains in standby for 0.20 hours)
setstate Sonnenschein 2025-05-20 12:21:28 state updated
Vielen Dank im voraus
oelidoc
Das Modul geht von hohen Verbräuchen heute aus:
NextHours_Sum04_ConsumptionForecast 19013 Wh
RestOfDayConsumptionForecast 26792 Wh
RestOfDayPVforecast 19556 Wh
Der Verbrauch ist so hoch bzw. höher als der erwartete PV-Ertrag. Unter dieser Erwartung ist Battery_ChargeRecommended_01 = 1 aus Sicht des Moduls ok.
Die Frage ist also wieso der erwartete Verbrauch so hoch ist. Gibt es z.B. ein E-Auto was geladen wurde und dessen Abnahmeleistung in die Verbrauchsprognose einfließt?
Hallo Heiko,
nein, kein E-Auto, nur unregelmäßig zwei Elektroheizkörper (Consumer01 und 08). Aber die haben das Attr exconfc=1.
Soll ich die Verbrauchshistorie einfach mal löschen? Ist denn alles andere richtig konfiguriert?
Danke
oelidoc
Nein, nicht löschen.
Setze dir noch zusätzlich plantControl->consForecastIdentWeekdays und plantControl->consForecastLastDays=4. DAmit erfolgt eine präzisiere Einschränkung der zu berücksichtigenden Verbrauchszeiträume.
LG
Zitat von: DS_Starter am 20 Mai 2025, 14:16:31Nein, nicht löschen.
Setze dir noch zusätzlich plantControl->consForecastIdentWeekdays und plantControl->consForecastLastDays=4. DAmit erfolgt eine präzisiere Einschränkung der zu berücksichtigenden Verbrauchszeiträume.
Okay, hab ich. Werde die nächsten Tage mal beobachten...
Ich habe noch eine Frage zu dem CtrlUserExitFN von 300P:
fhem("set $bwr01 Set_Leistung $currentsurplus"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR1)Warum wird bei der Leistung "$currentsurplus" verwendet und was heißt "Watt Netzleistung am Übergabemesspunkt"?
Vielen Dank
oelidoc
@Burny4600
Hat sich das bei Dir erledigt?
Zitat von: Burny4600 am 14 Mai 2025, 19:18:53Der Standbywert entspricht 26W. Trotzdem wird das Gerät aktiv angezeigt.
ZitatHat sich das bei Dir erledigt?
Ja das hat sich erledigt. Es war bei mir ein Syntaxfehler.
Zitat von: oelidoc am 20 Mai 2025, 15:51:47Ich habe noch eine Frage zu dem CtrlUserExitFN von 300P:
fhem("set $bwr01 Set_Leistung $currentsurplus"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR1)Warum wird bei der Leistung "$currentsurplus" verwendet und was heißt "Watt Netzleistung am Übergabemesspunkt"?
Vielen Dank
oelidoc
Moin oelidoc,
dieser Wert "$currentsurplus" wird wie folgt ermittelt (in diesem Code):
my $currentsurplus = (ReadingsNum ($name, 'Current_Surplus', 0) - 50);
Also ein Reading-Wert der in SF geführt wird ->> aufgrund deiner Einrichtung in SF (Quelle = dein Energymeter).
Der Wert "$currentsurplus" ist der aktuelle Einspeisewert am Netzübergabepunkt an deiner Anlage.
Oder auch der aktuelle Readingwert von deinem Energymeter-Device an deinem Netzübergabepunkt.
Oder auch (evtl.) gleichzeitig der Wert der zum "Abrufzeitpunkt" aktuell in der Grafik als Einspeisung angezeigt wird.
Da dieser Wert nicht in "Echtzeit" ermittelt wird, sondern in gewissen Zeitabständen, habe ich mir gedacht dort etwas abzuziehen um möglichst keinen Verbrauch zu erzeugen.
Grund:
-> WEIL wir ja mit diesem Code im "CtrlUserExitFN" die Steuerung der Batterie komplett selber zu diesem Zeitpunkt übernommen haben und die Batterie nur stur das macht - was wir ihr sagen - bis das wir es anders sagen...... ;D
Ich weiß aber aktuell noch nicht genau ob dieser "Abzieh"-Wert ausreichend ist bei "nur" einer Batterie - bei mir gleicht sich dieser Wert bei 2 Batterien einigermaßen so ab, dass es im Mittel mit Verbrauch / Einspeisung so bei mir passt. O:-)
Gruß
300P
EDIT:
anbei Grafik vom 19.5.25
obere Ansicht:
EVU-Bezug/Netzeinspeisung / WR-Leistungen
Morgens bis ca. 8:00 Uhr lief die WP auf EVU-Strom
- der Tag vorher war nicht so ertragsreich ->> Batterien nachts leer.
Tagsüber wenig EVU-Bezug trotz 3 x Waschen / 2 x Spülmaschine / 2 x Trockner / 2 Stunden Elektrogrill / 1 h Airfryer plus Grundverbrauch......
WR-Ertrag - je Phase=1 WR - Daten selberklärend nach "Sonnenscheinertrag"
Untere Ansicht
Batterien-SOC im Tagesverlauf / Temperatur außen / GrydfriendlyBatteryXX (SF-Wert) (...02 sieht man nicht - wird genau von ....01 überdeckt)
Hallo 300P,
vielen Dank für deine Erläuterungen, die ich soweit glaube verstanden zu haben.
Einzig: der Modbus Befehl set $bwr01 Set_Leistung $currentsurplus führt der zur Einspeisung des Überschusses oder zum Laden mit dem Überschuss?
Wahrscheinlich wird für mich alles nachvollziehbarer, wenn bei mir endlich mal mit Heiko´s Hilfe $gridfriendlychargebat01 eq 0 wird und ich das Verhalten der Anlage live beobachten kann...
Bis dahin
oelidoc
Hallo Heiko,
Zitat von: DS_Starter am 19 Mai 2025, 21:10:25@Peter, @ahlermi, @all
ich habe die V 1.52.4 im contrib upgedated.
Enthalten ist:
- die Flußgrafik habe ich noch etwas ausgerichtet wie von Peter angemerkt (#2913)
- fix des Problems "devision by zero" (#2926)
Danke, das sieht schon viel besser aus.
Jetzt sind die Zahlen nur noch ein bisschen "schief". Das fällt gerade bei den Nullen gut auf. Siehe Screenshot. Evtl. müssten dann auch die Symbole für Panels und Knoten noch mit rutschen?
Ich weiß, ich bin kleinlich. Alles nicht so wichtig, wie die Funktion an sich.
Mir ist heute aufgefallen, dass der SoC in der Flußgrafik mit zwei Nachkommastellen angezeigt wird. Ist das Absicht? Prozente mit zwei Nachkommastellen?
Viele Grüße,
Peter
ZitatMir ist heute aufgefallen, dass der SoC in der Flußgrafik mit zwei Nachkommastellen angezeigt wird. Ist das Absicht? Prozente mit zwei Nachkommastellen?
Nein, in der Version die ich einchecke werden alle Werte >= 10 ohne Nachkommastellen, < 10 mit 2 Nachkommastellen dargestellt. Das ist in der gesamten Flußgrafik so. Die Batteriewerte fügen sich dann in das Gesamtsystem ein.
ZitatJetzt sind die Zahlen nur noch ein bisschen "schief". Das fällt gerade bei den Nullen gut auf.
Naja ... ;)
LG,
Heiko
Zitat von: oelidoc am 20 Mai 2025, 22:05:40Hallo 300P,
vielen Dank für deine Erläuterungen, die ich soweit glaube verstanden zu haben.
Einzig: der Modbus Befehl
set $bwr01 Set_Leistung $currentsurplus führt der zur Einspeisung des Überschusses oder zum Laden mit dem Überschuss?
Wahrscheinlich wird für mich alles nachvollziehbarer, wenn bei mir endlich mal mit Heiko´s Hilfe $gridfriendlychargebat01 eq 0 wird und ich das Verhalten der Anlage live beobachten kann...
Bis dahin
oelidoc
Damit stellt du ein...
- auf welchen Wert sich der BWR am Netzübergabeort einpendeln soll.
Beispiel:
Aktuell werden 1234 Watt eingespeist - normal würde die Batterie bei "1" jetzt den Überschuss "laden" wenn wir nicht steuertechnisch eingreifen
Wenn wir also eingreifen wollen (netzdienlich =>> SF Battery_ChargeRecommended01 bei "0").... ;D
Dann wollen wir das die Batterie bei diesem Punkt von 1234 Watt nicht mehr als 0 Watt in die Batterie "läd" / ""einspeist". :o
Also verschieben wir den "Zielwert" des BWR von 0 auf 1234 Watt damit dieser BWR diese Batterie nicht lädt. O:-)
Und wir sagen dem BWR das wir jetzt der Herr der Batteriesteuerung sind und ihm auch alles vorgegeben haben.... ::)
Dieser Wert wird dann in deinem Intervall von SF (jetzt bitte nicht deshalb 1 Sekunde Intervall einstellen -> Systemlast !!!!) immer wieder aktuell gesetzt bis das SF Battery_ChargeRecommended01 "1" vorgibt.
Dann wird dort ( nachfolgendes "else") wieder 0 Watt eintragen und dem BWR gesagt das unser "manuelles eingreifen" beendet wird.
Gruß + schönen Abend an Alle
300P
EDIT:
Dein SF Intervall sollte auf so zwischen 15 - 30 Sekunden eingestellt sein.
Wenn der Wechselrichter zu lange nichts von "Dir" hört stellt er sich automatisch wieder auf "Eigensteuerung" um
@ 300P
Super erklärt - vielen Dank - und schönen Abend
oelidoc
Hallo zusammen
die V 1.52.4 habe ich soben eingecheckt. Hier nochmal zusammengefasst die Weiterentwicklungen:
In Vorbereitung der Hybridinverterintegration ist bei den Invertern im setupInverterDevXX der bisherige Schlüssel "pv" in "pvOut" umbenannt und es gibt einen neuen Schlüssel "pvIn" für die DC Eingangsleistung aus den Solarzellen. pvIn wird nun auch in der Flußgrafik unterhalb der Solarzelle angezeigt.
Solange pvIn nicht gesetzt ist, wird dort 0 angezeigt.
pvIn Ein Reading, welches die aktuelle DC PV-Eingangsleistung in W liefert (Summe aller angeschlossenen Strings).
Es wird ein positiver numerischer Wert erwartet.
pvOut Ein Reading, welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz oder öffentliche Netz
geliefert wird, bereitstellt. Es wird ein positiver numerischer Wert erwartet.
Die Umstellung von pv -> pvOut erfolgt automatisch. Bitte Restart nicht vergessen!
pvIn ist dann noch manuell zu setzen, ist jedoch kein Problem wenn der Schlüssel später eingefügt wird. Bis dahin wird lediglich "0" angezeigt, sonst hat es keine Nachteile.
Weiterhin:
- die Online-Hilfe zu setupInverterDevXX ist für eine bessere Übersicht Inverterspezifisch organisiert
- die Flußgrafik habe ich noch etwas ausgerichtet wie von Peter angemerkt (#2913)
- fix des Problems "devision by zero" (#2926)
- das Attr ctrlSpecialReadings hat eine neue Auswahl "BatWeightedTotalSOC" zur Anzeige des resultierenden SOC aller Batterien
LG,
Heiko
Warum findet sich die Leistung der Solarzellen (Generators) denn unterhalb der Solarzellen und nicht neben den Solarzellen wie bei allen anderen Symbolen (Haus, Inverter, ...)?
Das sieht irgendwie komisch aus. Kann man es daneben (oder ev. darüber?) darstellen?
Moin,
ZitatWarum findet sich die Leistung der Solarzellen (Generators) denn unterhalb der Solarzellen und nicht neben den Solarzellen wie bei allen anderen Symbolen (Haus, Inverter, ...)?
Die Werte werden auch bei den Invertern darunter dargestellt und nicht daneben. Beim Haus steht der Wert nur deswegen daneben weil ich darunter den Platz für die weiteren Verzweigungen brauche.
Den Wert neben den Generatoren darzustellen ist extrem ungünstig, weil der benötigte Platz je nach Leistung der Generatoren flexibel berechnet werden muß wenn mehrere Inverter mit Generatoren vorhanden sind. Zumal ich vllt. später noch ermögliche, mehrere Strings an einen Inverter darzustellen. Auch dann ist der Wert darunter darzustellen einfach optimal um den Platz gut auszunutzen.
ZitatKann man es daneben (oder ev. darüber?) darstellen?
Daneben aus den beschriebenen Gründen nicht. Darüber wäre es möglich. Da alle anderen Werte in der Grafik (bis auf Ausnahmen aus bestimmten Gründen) ebenfalls unter den Symbolen dargestellt werden, halte ich die gegenwärtige Darstellung für stringent.
Bin allerdings offen, falls eine Mehrheit der User die Darstellung des Wertes über den Generatoren für besser empfindet.
LG,
Heiko
Zitat von: DS_Starter am 21 Mai 2025, 09:55:30Die Werte werden auch bei den Invertern darunter dargestellt und nicht daneben.
Das stimmt so nicht. Bei mir wird es daneben dargestellt. Habe nix diesbezüglich (um-)konfiguriert.
Zitat von: DS_Starter am 21 Mai 2025, 09:55:30Darüber wäre es möglich. Da alle anderen Werte in der Grafik (bis auf Ausnahmen aus bestimmten Gründen) ebenfalls unter den Symbolen dargestellt werden, halte ich die gegenwärtige Darstellung für stringent.
Ganz unten in der Darstellung sind die Verbraucher, da wird der Verbrauch "ganz unten am Ende der Darstellung" hingeschrieben, von wo aus keinerlei weitere Linien weggehen.
Man könnte es also auch als "stringent" erachten bei den Symbolen "ganz oben" die Werte darüberzuschreiben, sodass die davon unten weggehenden Linien nicht durch den Text unterbrochen werden.
Aber egal, werde deswegen nicht groß herumstreiten. Habe die Darstellung nun ausprobiert und überlege sie ohnehin wieder zu deaktivieren (showGenerators=0), weil sich bei meinem einfachen System kaum ein Mehrwert dadurch ergibt.
ZitatDas stimmt so nicht.
Vermutlich liegt eine kleines Mißverständnis vor. Bei der absoluten Minimalkonfiguration wird der Inverterknoten durch den Inverter ersetzt. Der Wert steht daneben, ist aber nur durch die Ersetzung des Knotens durch den Inverter bedingt.
Und wie du schon sagst, sind die Werte der Consumer auch unterhalb der Symbole, nur beim Haus nicht, denn hier können im vollen Ausbau 16 Abgänge zu den Consumern vorhanden sein.
Für die Darstellungsentscheidungen sind für mich immer die komplexeren Anlagen führend, denn dann steigt der Schwierigkeitsgrad.
Vergleiche mal die Varianten im Anhang. Hier sieht man es ganz gut.
LG,
Heiko
Zitat von: DS_Starter am 21 Mai 2025, 11:33:21Vergleiche mal die Varianten im Anhang. Hier sieht man es ganz gut.
Genau, meins sieht ungefähr so aus wie der Screenshot mit hellem Hintergrund, nur habe ich noch einige Consumer unterhalb des Hauses dargestellt.
Wenn ich mir die übrigen beiden Bilder so anschaue, würde es dem 1. Screenshot (113220.png) durchaus guttun, wenn die Generator-Leistungen über den Symbolen dargestellt wären. Beim 2. Screenshot würde es keinen positiven Effekt haben, aber es wäre auch nicht nachteilig.
Egal, wie gesagt ist das eine Kleinigkeit mit der ich leben kann.
Meine Meinung:
Bei den WRn, den OtherProducern und den Strings/Panel kommt die Leistung "raus" >= drunter sollte daher bleiben.
Bei den Consumern steht (neben der aufgenommen Leistung) evtl. eine 2.te Zeile mit Werten => drunter daher sollte bleiben.
Beim Hausverteiler, den/der Batterie/n und dem Inverterknoten (auch bei Minimalkonfig's) steht's wegen "Summierung/Verteilung" daneben => ist funktionell notwendig und geht es wohl m.M.n. auch nicht anders.
Bei den Linienflüssen ist m.M.n. auch alles z.Z. soweit okay.
Gruß
300P
neue Idee für den Inverterknoten ;) ( flowGraphicControl ... inverterNodeIcon=measure_power_meter@#ff8c00 )
Jetzt war ich schon verwundert dass es ein Icon gibt welches man nicht ersetzen kann ;)
Du meinst das Icon für den Inverterknoten, das Icon für den Hausknoten kann man tatsächlich nicht ändern ... tztz.
Moin,
ich habe auch die aktuelle Version installiert (aus fhem Update), und mir ist heute aufgefallen, daß die angezeigten Werte nicht mehr stimmig sind: Einspeisung 3732, Eigenverbrauch vom WR -3732, kein Zukauf, Verbrauch -3860 ...
Zumindest Anfang der Woche sahen sie noch anders aus, meine ich
Aktuelle laufen PC und Spüma sowie ein paar andere kleinere Verbraucher
Internals:
FUUID 62f1192d-f33f-378b-0c69-cc57687c40949580
FVERSION 76_SolarForecast.pm:v1.52.4-s29984/2025-05-20
MODE Automatic / Event-controlled - next planned Cycletime: 12:31:08
MODEL OpenMeteoDWDAPI
NAME SolarForecast
NOTIFYDEV MyObis,ShellyPlugS_HWR_Waschmaschine,ShellyPlug_HWR_Trockner,ShellyPlugS_Kueche_SpueMa,ShellyPlugS_Kueche_Kuehlschrank,Shellyplus1pm_Gartenhaus_Gefrierschrank,ShellyPlugS_Buero_PC,ShellyPlusPlugS_Buero_fhem,ShellyPlusPlugS_Buero_NAS,ShellyPlugS_Wohnzimmer_TV,ShellyPlusPlugS_Buero_FritzBox,PV
NR 1423
NTFY_ORDER 50-SolarForecast
STATE updated
TYPE SolarForecast
WEATHERMODEL OpenMeteoDWDAPI
eventCount 4
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV SolarForecast
SPGROOM
VERSION 1.52.4
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
OLDREADINGS:
READINGS:
2025-05-22 12:29:58 Current_AutarkyRate 0 %
2025-05-22 12:29:58 Current_Consumption -3061 W
2025-05-22 12:29:58 Current_GridConsumption 0 W
2025-05-22 12:29:58 Current_GridFeedIn 3061 W
2025-05-22 12:29:58 Current_PV 0 W
2025-05-22 12:29:58 Current_SelfConsumption 0 W
2025-05-22 12:29:58 Current_SelfConsumptionRate 0 %
2025-05-22 12:29:58 Current_Surplus 3061 W
2025-05-22 10:53:15 Error malformed JSON string received
2025-05-22 10:53:15 Errorcode 9000
2025-05-22 12:00:00 LastHourGridconsumptionReal 128 Wh
2025-05-22 12:00:00 LastHourPVforecast 3461 Wh
2025-05-22 12:00:00 LastHourPVreal 2241 Wh
2025-05-22 12:29:58 NextHours_Sum01_PVforecast 4435 Wh
2025-05-22 12:29:58 NextHours_Sum02_PVforecast 9390 Wh
2025-05-22 12:29:58 NextHours_Sum03_PVforecast 13692 Wh
2025-05-22 12:29:58 NextHours_Sum04_ConsumptionForecast 2238 Wh
2025-05-22 12:29:58 NextHours_Sum04_PVforecast 16868 Wh
2025-05-22 12:29:58 RestOfDayConsumptionForecast 6184 Wh
2025-05-22 12:29:58 RestOfDayPVforecast 21914 Wh
2025-05-22 00:59:49 Today_Hour01_GridConsumption 339 Wh
2025-05-22 00:59:49 Today_Hour01_GridFeedIn 0 Wh
2025-05-22 00:59:49 Today_Hour01_PVreal 0 Wh
2025-05-22 01:59:49 Today_Hour02_GridConsumption 345 Wh
2025-05-22 01:59:49 Today_Hour02_GridFeedIn 0 Wh
2025-05-22 01:59:49 Today_Hour02_PVreal 0 Wh
2025-05-22 02:59:49 Today_Hour03_GridConsumption 339 Wh
2025-05-22 02:59:49 Today_Hour03_GridFeedIn 0 Wh
2025-05-22 02:59:49 Today_Hour03_PVreal 0 Wh
2025-05-22 03:59:52 Today_Hour04_GridConsumption 341 Wh
2025-05-22 03:59:52 Today_Hour04_GridFeedIn 0 Wh
2025-05-22 03:59:52 Today_Hour04_PVreal 0 Wh
2025-05-22 04:59:49 Today_Hour05_GridConsumption 322 Wh
2025-05-22 04:59:49 Today_Hour05_GridFeedIn 0 Wh
2025-05-22 04:59:49 Today_Hour05_PVreal 0 Wh
2025-05-22 05:59:49 Today_Hour06_GridConsumption 371 Wh
2025-05-22 05:59:49 Today_Hour06_GridFeedIn 0 Wh
2025-05-22 05:59:49 Today_Hour06_PVforecast 20 Wh
2025-05-22 05:59:49 Today_Hour06_PVreal 4 Wh
2025-05-22 06:59:49 Today_Hour07_GridConsumption 269 Wh
2025-05-22 06:59:49 Today_Hour07_GridFeedIn 7 Wh
2025-05-22 06:59:49 Today_Hour07_PVforecast 240 Wh
2025-05-22 06:59:49 Today_Hour07_PVreal 218 Wh
2025-05-22 07:59:49 Today_Hour08_GridConsumption 24 Wh
2025-05-22 07:59:49 Today_Hour08_GridFeedIn 120 Wh
2025-05-22 07:59:49 Today_Hour08_PVforecast 2044 Wh
2025-05-22 07:59:49 Today_Hour08_PVreal 529 Wh
2025-05-22 08:59:49 Today_Hour09_GridConsumption 0 Wh
2025-05-22 08:59:49 Today_Hour09_GridFeedIn 2578 Wh
2025-05-22 08:59:49 Today_Hour09_PVforecast 771 Wh
2025-05-22 08:59:49 Today_Hour09_PVreal 2956 Wh
2025-05-22 09:59:49 Today_Hour10_GridConsumption 0 Wh
2025-05-22 09:59:49 Today_Hour10_GridFeedIn 4169 Wh
2025-05-22 09:59:49 Today_Hour10_PVforecast 2271 Wh
2025-05-22 09:59:49 Today_Hour10_PVreal 4497 Wh
2025-05-22 10:59:49 Today_Hour11_GridConsumption 0 Wh
2025-05-22 10:59:49 Today_Hour11_GridFeedIn 4666 Wh
2025-05-22 10:59:49 Today_Hour11_PVforecast 3671 Wh
2025-05-22 10:59:49 Today_Hour11_PVreal 5010 Wh
2025-05-22 11:59:49 Today_Hour12_GridConsumption 128 Wh
2025-05-22 11:59:49 Today_Hour12_GridFeedIn 1363 Wh
2025-05-22 11:59:49 Today_Hour12_PVforecast 3461 Wh
2025-05-22 11:59:49 Today_Hour12_PVreal 2241 Wh
2025-05-22 12:29:58 Today_Hour13_GridConsumption 7 Wh
2025-05-22 12:29:58 Today_Hour13_GridFeedIn 725 Wh
2025-05-22 12:29:58 Today_Hour13_PVforecast 3095 Wh
2025-05-22 12:29:58 Today_Hour13_PVreal 1007 Wh
2025-05-22 12:29:58 Today_Hour14_PVforecast 5775 Wh
2025-05-22 12:29:58 Today_Hour15_PVforecast 4136 Wh
2025-05-22 12:29:58 Today_Hour16_PVforecast 4467 Wh
2025-05-22 12:29:58 Today_Hour17_PVforecast 1885 Wh
2025-05-22 12:29:58 Today_Hour18_PVforecast 3026 Wh
2025-05-22 12:29:58 Today_Hour19_PVforecast 456 Wh
2025-05-22 12:29:58 Today_Hour20_PVforecast 374 Wh
2025-05-22 12:29:58 Today_Hour21_PVforecast 222 Wh
2025-05-22 12:29:58 Today_Hour22_PVforecast 26 Wh
2025-05-22 12:29:58 Today_MaxPVforecast 5775 Wh
2025-05-22 12:29:58 Today_MaxPVforecastTime 2025-05-22 13:00:00
2025-05-22 12:29:58 Today_PVforecast 35940 Wh
2025-05-22 12:29:58 Today_PVreal 16462 Wh
2025-05-22 12:29:58 Today_SunRise 05:22
2025-05-22 12:29:58 Today_SunSet 21:25
2025-05-22 12:29:58 Tomorrow_ConsumptionForecast 11344 Wh
2025-05-22 12:29:58 Tomorrow_PVforecast 26192 Wh
2025-05-22 12:29:58 Tomorrow_SunRise 05:21
2025-05-22 12:29:58 Tomorrow_SunSet 21:26
2025-05-22 12:29:58 consumer01 name='ShellyPlugS_HWR_Waschmaschine' state='on' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer01_ConsumptionRecommended 1
2025-05-22 12:29:58 consumer01_currentPower 0 W
2025-05-22 12:29:58 consumer02 name='ShellyPlug_HWR_Trockner' state='on' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer02_currentPower 0 W
2025-05-22 12:29:58 consumer03 name='ShellyPlugS_Kueche_SpueMa' state='on' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer03_ConsumptionRecommended 1
2025-05-22 12:29:58 consumer03_currentPower 28.01 W
2025-05-22 12:29:58 consumer04 name='ShellyPlugS_Kueche_Kuehlschrank' state='on' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer04_ConsumptionRecommended 1
2025-05-22 12:29:58 consumer04_currentPower 0 W
2025-05-22 12:29:58 consumer05 name='Gefrierschrank Gartenhaus mit Temp' state='on' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer05_currentPower 31.6 W
2025-05-22 12:29:58 consumer06 name='ShellyPlugS_Buero_PC' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-22 12:29:58 consumer06_currentPower 47.84 W
2025-05-22 12:29:58 consumer07 name='ShellyPlusPlugS_Buero_fhem' state='unknown' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer07_currentPower 5.7 W
2025-05-22 12:29:58 consumer08 name='ShellyPlusPlugS_Buero_NAS' state='on' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer08_currentPower 0 W
2025-05-22 12:29:58 consumer09 name='ShellyPlugS_Wohnzimmer_TV' state='off' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer09_currentPower 0 W
2025-05-22 12:29:58 consumer10 name='ShellyPlusPlugS_Buero_FritzBox' state='on' mode='can' planningstate='noSchedule'
2025-05-22 12:29:58 consumer10_currentPower 0 W
2025-05-22 12:29:58 nextCycletime 12:31:08
2022-10-18 14:57:17 nextPolltime 14:58:27
2025-05-22 12:25:25 nextRadiationAPICall nach 22.05.2025 12:40:25
2025-05-22 06:00:05 pvCorrectionFactor_06 0.42 (automatic - old factor: 0.57, Sun Alt range: 0, Cloud range: 90, Days in range: 2)
2025-05-22 07:00:04 pvCorrectionFactor_07 0.83 (automatic - old factor: 1.01, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 4)
2025-05-22 08:00:04 pvCorrectionFactor_08 0.61 (automatic - old factor: 1.00, AI result used, Sun Alt range: 15, Cloud range: 95, Days in range: 2)
2025-05-22 09:00:00 pvCorrectionFactor_09 0.96 (automatic - old factor: 0.89, AI result used, Sun Alt range: 25, Cloud range: 95, Days in range: 2)
2025-05-22 10:00:05 pvCorrectionFactor_10 0.92 (automatic - old factor: 0.89, AI result used, Sun Alt range: 35, Cloud range: 55, Days in range: 2)
2025-05-22 11:00:04 pvCorrectionFactor_11 1.30 (automatic - old factor: 0.92, Sun Alt range: 45, Cloud range: 100, Days in range: 3)
2025-05-22 12:00:04 pvCorrectionFactor_12 0.90 (automatic - old factor: 1.12, AI result used, Sun Alt range: 50, Cloud range: 45, Days in range: 2)
2025-05-22 12:29:58 pvCorrectionFactor_Auto on_complex_ai
2025-05-22 12:29:58 special_runTimeTrainAI 10.07296 s
2025-05-22 12:29:59 state updated
Attributes:
DbLogExclude .*
alias SolarForecast
cmdIcon consumer03_ConsumptionRecommended cmdIcon 0:15px-red 1:15px-green consumer04_ConsumptionRecommended cmdIcon 0:15px-red 1:15px-green
comment ShellyPlugS_Gartenhaus_Weatherman
Current_PV = 0 W -> wird vermutlich nicht stimmen.
Leider sieht man das /die Inverter-Attribute nicht.
Hallöchen.
Erstmal muss ich ein Ganz Dickes Lob aussprechen - ein Super Modul habt Ihr da auf die Beine gestellt. Endlich kann man (oder ich als dummy) mit FHEM die Beladung eines Stromspeicher an die PV-Prognose binden, bzw. an dieser ausrichten.
Leider macht mir das 76_SolarForecast.pm seit dem letzten Update Probleme.
Ich habe am 15.05 letztmalig mein FHEM via update all und shutdown restart auf den aktuellen Stand gebracht. Nach dem Update lief alles.
Gestern, nach Rückkehr von einer Dienstreise, habe ich wieder mit update all und shutdown restart ein Update angestoßen, und hatte danach keine Verbindung mehr zum FHEMWEB.
Siehe dieser Thread (https://forum.fhem.de/index.php?topic=141711.0)
Ich habe heute jede Datei einzeln ge-updatet, und nach jeder Datei einen restart gemacht - und beim 76_SolarForecast.pm hatte ich nach dem restart wieder keine Verbindung zum FHEMWEB.
Jetzt bin ich aber mit meinem Latein am Ende, und benötige Schützenhilfe zur Ursachenforschung & Behebung.
VG
Hallo roadghost,
dann bräuchte ich mal bitte ein Auszug aus dem Log beim Start von FHEM.
An irgendeiner Stelle beim Laden von SF passiert vermutlich ein Fehler den ich behandeln muß.
Grüße,
Heiko
Zitat von: DS_Starter am 22 Mai 2025, 14:20:56dann bräuchte ich mal bitte ein Auszug aus dem Log beim Start von FHEM.
Grüße,
Heiko
Ich gehe mal davon aus, einen Start vonnfhem mit dem "Bauchschmerzen Update" vom Modul?
Das bastel ich heute Abend gern zusammen, jetzt wo ich weiß, wie ich es danach wieder an laufen kriegen kann 😉
VG
Ja, genau. Ich dachte du hast einen fehlerhaften Start noch in der Historie des Log.
Ansonsten gerne bis heute Abend.
Hallo Heiko,
ich habe eine Frage zum Parameter pcurr bei den Verbrauchern. Genauer gesagt zum Zusatz <Schwellenwert>. Was genau bedeutet hier "als aktiv gewertet"? Nur dass ein niedrigerer Verbrauch nicht zur Vorhersage verwendet wird? Oder sollte der Energiefluss in der Grafik dann auch nicht animiert sein?
Ich habe bei 2 Verbrauchern "pcurr=power:W:2" definiert, beim einen wird der Fluss im Standby mit 0.92 W animiert, beim anderen mit 0.22 W nicht. Der Unterschied hat dann vermutlich nichts mit dem Schwellenwert zu tun. Man sieht natürlich am Icon, dass beide Geräte aus bzw. im Standby sind.
Viele Grüße
Thomas
Zitat von: DS_Starter am 22 Mai 2025, 14:20:56Hallo roadghost,
dann bräuchte ich mal bitte ein Auszug aus dem Log beim Start von FHEM.
An irgendeiner Stelle beim Laden von SF passiert vermutlich ein Fehler den ich behandeln muß.
Grüße,
Heiko
Zur Info:
Bei mir dauert es seit ein paar Tagen bei einem shutdown / restart ebenfalls bis zu 5 Minuten ehe sich FHEM wieder meldet. :o
Hatte schon gedacht es läge an meinem Debian-QNAP-Container.....
025.05.21 18:13:52 2: myDbLog - Last database write cycle done
2025.05.21 18:13:53 0: Server shutdown
2025.05.21 18:13:53 2: myDbLog - stopping SubProcess PID >30720< ...
2025.05.21 18:13:53 2: myDbLog - SubProcess PID >30720< stopped
2025.05.21 18:15:27 1: Including fhem.cfg
2025.05.21 18:15:28 2: myDbLog - Subprocess >3036< initialized ... ready for non-blocking operation
2025.05.21 18:15:28 2: eventTypes: loaded 4841 lines from ./log/eventTypes.txt
2025.05.21 18:15:29 1: MB_CFG_SBS25: loading config from cfg file
2025.05.21 18:15:32 1: Zisterne: loading config from cfg file
2025.05.21 18:15:44 1: Including ./log/fhem.save
2025.05.21 18:15:45 0: Featurelevel: 6.4
2025.05.21 18:15:45 0: Server started with 402 defined entities (fhem.pl:29809/2025-03-30 perl:5.036000 os:linux user:fhem pid:3035)
2025.05.21 18:25:45 2: AttrTemplates: got 265 entries
Hallo Thomas,
das bezieht sich auf die Flußgrafik. Der Energiefluß sollte unterhalb der Schwelle grau, also nicht aktiv sein.
Von dem problematischen Consumer mal das Consumerattribut und ein "get ... valConsumerMaster" posten.
ZitatBei mir dauert es seit ein paar Tagen bei einem shutdown / restart ebenfalls bis zu 5 Minuten ehe sich FHEM wieder meldet. :o
Hatte schon gedacht es läge an meinem Debian-QNAP-Container.....
Wird schon so sein. ;) Du hast ja keinen Fehler. Wo dein Server die Zeit verbraucht sieht man hier nicht, müßtest wahrscheinlich mindestens auf verbose 3 gehen.
Zitat von: DS_Starter am 22 Mai 2025, 15:21:54Von dem problematischen Consumer mal das Consumerattribut und ein "get ... valConsumerMaster" posten.
Momentan läuft die Spülmaschine allerdings. Den Schwellenwert hatte ich jetzt mal auf 5 erhöht, da aktuell der Verbrauch bei 3.2 liegt. Falls das in dem Zustand nichts bringt, mache ich es später nochmal.
attr WD_SolarForecast consumer01 S_Spuelmaschine:Spuelmaschine \
icon=scene_dishwasher \
type=dishwasher \
mintime=220 \
switchdev=SMS6ECW00E \
mode=SMS6ECW00E:v_SFmode \
auto=v_SFauto \
pcurr=power:W:5 \
interruptable=0 \
power=50 \
on=startProgram \
off=stopProgram \
swstate=state:Program.*:Idle|Offline|Delayed.* \
notafter=18 \
etotal=energy:Wh:501 => alias => Spuelmaschine
asynchron => 0
auto => 0
autoreading => v_SFauto
avgenergy => 168.95
currpowerpercent => 6.42
cycleDayNum => 1
cycleStarttime => 1747911058
cycleTime => 157.516666666667
dspignorecond =>
dswitch => SMS6ECW00E
dswoffcond =>
dswoncond =>
ehodpieces => 16=76.67 17=17.04 18=17.04 19=76.67
energythreshold => 5
epiecAVG => 1=378.40 2=208.20 3=0.00 4=0.00
epiecAVG_hours => 4
epiecHist => 1
epiecHist_1 => 1=409.00 2=166.00 3=2.00
epiecHist_10 => 1=383.00 2=209.00 3=3.00 4=2.00
epiecHist_10_hours => 4
epiecHist_1_hours => 3
epiecHist_2 => 1=438.00 2=226.00 3=4.00 4=1.00
epiecHist_2_hours => 4
epiecHist_3 => 1=432.00 2=183.00 3=4.00 4=1.00
epiecHist_3_hours => 4
epiecHist_4 => 1=405.00 2=169.00 3=3.00 4=2.00
epiecHist_4_hours => 4
epiecHist_5 => 1=387.00 2=385.00 3=3.00 4=3.00 5=1.00
epiecHist_5_hours => 5
epiecHist_6 => 1=438.00 2=222.00 3=3.00 4=2.00
epiecHist_6_hours => 4
epiecHist_7 => 1=406.00 2=179.00 3=3.00 4=1.00
epiecHist_7_hours => 4
epiecHist_8 => 1=0.00
epiecHist_8_hours => 0
epiecHist_9 => 1=422.00 2=168.00 3=3.00 4=2.00
epiecHist_9_hours => 4
epiecHour => 3
epiecStartEtotal => 808514
epiecStartTime => 1747911128
epieces => 1=76.03 2=16.89 3=16.89 4=76.03
exconfc => 0
hysteresis => 0
icon => scene_dishwasher
interruptable => 0
isConsumptionRecommended => 1
isIntimeframe => 1
lastAutoOffTs => 1744464349
lastAutoOnTs => 1747566054
lastMinutesOn => 0
lastOnTime => 1747920555
locktime => 0:0
logoffon => off
mintime => 220
minutesOn => 28.4833333333333
mode => SMS6ECW00E:v_SFmode
name => S_Spuelmaschine
noshow => 0
notafter => 18
notbefore =>
offcom => stopProgram
offreg => Idle|Offline|Delayed.*
oncom => startProgram
onoff => off
onreg => Program.*
physoffon => on
planSupplement =>
plandelete => regular
planstate => planned: 2025-05-22 15:15:39 - 2025-05-22 18:55:39
planswitchoff => 1747932939
planswitchon => 1747919739
power => 50
powerthreshold => 5
remainTime => 0
retotal => energy
rigncond =>
rpcurr => power
rswoffcond =>
rswoncond =>
rswstate => state
runtimeAvgDay => 183.80
spignorecondition =>
startTime => 1747918800
state => on
surpmeth => default
swoffcondition =>
swoncondition =>
type => dishwasher
uetotal => Wh
upcurr => W
Einen Nachtrag habe ich noch: Ich dachte bisher, dass der Zustand des Icons (Farbe) von swstate gesteuert wird. Jetzt sehe ich, mit der Erhöhung des Schwellenwerts wird das Icon grau, der Energiefluss aber nicht.
ZitatIch dachte bisher, dass der Zustand des Icons (Farbe) von swstate gesteuert wird.
Es gibt Fallunterschiede. Bei Verbrauchern ohne Energiemessung ist es so wie du sagst.
Bei Verbrauchern mit Energiemessung gehe ich tiefer rein und berücksichtige einen evtl. Schwellenwert.
Der Schwellenwert wird jedenfalls richtig erkannt:
powerthreshold => 5Ist der Energiefluß animiert oder nur nicht grau?
Zitat von: DS_Starter am 22 Mai 2025, 15:56:56Ist der Energiefluß animiert oder nur nicht grau?
Der ist grün und animiert.
Wo liegt den der Schwellenwert ohne explizite Angabe? Erklärt der Default-Wert den Unterschied bei meinen beiden Geräten (einmal 0.92 und einmal 0.22).
Ohne Angabe wird der Verbrauch > 1% des power-Wertes als aktiv gewertet.
Aber ich sehe gerade, dass ich bei dem Laufketten Style evtl. noch eine Nachbesserung machen muß bzgl. der besagten Fallunterscheidung.
Bei mir wird nach dem Update keine Solarleistung mehr angezeigt. Die Attribute wurden nicht geändert. Ich kann sie auch nicht per Hand ändern. Es kommt immer eine Fehlermeldung beim Übernehmen.
Hier meine Attribute:
setupInverterDev01 SmaSTL8000TL pv=PACTot:W etotal=ETotal:kwh capacity=8000 strings=suedost
setupInverterDev02 SmaSTP10.0 pv=SPOT_PACTOT:W etotal=SPOT_ETOTAL:wh capacity=10000 strings=nordwest
setupInverterDev03 Sonoff_POW_Solar pv=ENERGY_Power:W etotal=ENERGY_Total:kwh capacity=600 strings=balkon
setupInverterDev04 openDTU pv=power:W etotal=yieldtotal:kwh capacity=1600 strings=gurken
wenn ich aus pv pvOut mache kommt die Meldung:
The key 'etotal=ETotal:kwh' is not specified correctly. Please refer to the command reference.
wenn ich aus pv pvout mache kommt einmal die Meldung:
The key 'etotal=ETotal:kwh' is not specified correctly. Please refer to the command reference.
beim 2. click auf attr:
The key 'pvout' is not a valid key in attribute 'setupInverterDev01'
hat sich da irgend etwas mit der Groß- und Kleinschreibung geändert?. Bisher hatte ich überall, vor dem "=" Kleinschreibung
Mit allem in Großschreibung geht es auch nicht
Geb mal die SF-Version an die dir angezeigt wird
Entweder hier (SC1) oder hier (SC2) mal nachsehen/posten
ZitatBei mir wird nach dem Update keine Solarleistung mehr angezeigt. Die Attribute wurden nicht geändert. Ich kann sie auch nicht per Hand ändern. Es kommt immer eine Fehlermeldung beim Übernehmen.
Hier meine Attribute:
Probiere nicht einen Neustart unter FHEM sondern auf der Konsole
sudo systemctl stop fhem.service und anschließend wieder
sudo systemctl start fhem.service
Bei mir hat es jedenfalls dannach funktioniert.
@Medel,
bei dir gibt es ein paar Syntaxfehler die entsprechende Fehlermeldungen hervorbringen:
etotal=ETotal:kwh -> etotal=ETotal:kWh
pvout -> pvOut
Zitathat sich da irgend etwas mit der Groß- und Kleinschreibung geändert?
Nein, aber ich prüfe immer konsequenter damit sich so wenig wie möglich Setup-Fehler einschleichen.
ZitatMit allem in Großschreibung geht es auch nicht
Nein, es ist genau beschrieben wie etwas anzugeben ist.
Läuft bei mir wieder.
Zitatbei die gibt es ein paar Syntaxfehler die entsprechende Fehlermeldungen hervorbringen:
Wäre es möglich die Vorgaben in der Beschreibung so anzupassen wie die Groß- und Kleinschreibung der Parameter sein soll. Oder vielleicht intern die übergebenen Parameter Namen in Klein oder Großbuchstaben zu wandeln dass die Schreibung egal ist.
Soll man denn mit dem aktuellen Modul einen Hybridwechselrichter als "PV-Wechselrichter" einrichten oder wie macht man das? Ich konnte meinem Wechselrichter inzwischen deutlich mehr Daten entlocken. Besten Dank!
ZitatWäre es möglich die Vorgaben in der Beschreibung so anzupassen wie die Groß- und Kleinschreibung der Parameter sein soll.
Ist doch gegeben, Auszug aus Comref setupInverterDevXX:
Einheit die jeweilige Einheit (W,kW,Wh,kWh)
pvIn Ein Reading, welches die aktuelle DC PV-Eingangsleistung in W liefert (Summe aller angeschlossenen Strings).
Es wird ein positiver numerischer Wert erwartet.
pvOut Ein Reading, welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz oder öffentliche Netz
geliefert wird, bereitstellt. Es wird ein positiver numerischer Wert erwartet.
Auch wenn ich alles intensiv prüfe, kann mir natürlich mal etwas entgehen. In diesem Fall einfach einen kurzen Hinweis geben, dann passe ich es umgehend an.
ZitatIst doch gegeben, Auszug aus Comref setupInverterDevXX:
Ist bei mir ein scheinbar ein css Fehler da wird alles in Großschreibung konvertiert. Muss mal schauen ob ich den finde. Wenn ich den Text kopiere stimmt es.
Zitat von: DS_Starter am 22 Mai 2025, 14:58:55Ja, genau. Ich dachte du hast einen fehlerhaften Start noch in der Historie des Log.
Ansonsten gerne bis heute Abend.
Hallo,
hier kommt mein Log-Auszug:
2025.05.21 22:30:00.314 1: Downloading https://fhem.de/fhemupdate/controls_fhem.txt
2025.05.21 22:30:00.314 1: fhem
2025.05.21 22:30:00.393 1: RMDIR: ./restoreDir/update/2025-05-09
2025.05.21 22:30:00.469 1: UPD ./CHANGED
2025.05.21 22:30:00.487 1: UPD FHEM/01_FHEMWEB.pm
2025.05.21 22:30:00.502 1: UPD FHEM/36_Shelly.pm
2025.05.21 22:30:00.521 1: UPD FHEM/76_SolarForecast.pm
2025.05.21 22:30:00.557 1: UPD FHEM/96_allowed.pm
2025.05.21 22:30:00.569 1: UPD FHEM/98_weekprofile.pm
2025.05.21 22:30:00.592 1: UPD www/images/fhemSVG/hue_room_guest.svg
2025.05.21 22:30:00.614 1: saving fhem.cfg
2025.05.21 22:30:00.615 1: saving ./log/fhem.save
2025.05.21 22:30:00.616 1:
2025.05.21 22:30:00.616 1: New entries in the CHANGED file:
2025.05.21 22:30:00.616 1: - feature: 76_SolarForecast: Version 1.52.4
2025.05.21 22:30:00.616 1: - feature: 98_weekprofile: attribute extraClientModules
2025.05.21 22:30:00.617 1: to support further modules with attribute weekprofile
2025.05.21 22:30:00.617 1: - feature: 76_SolarForecast: graphicControl keys beamPaddingBottom/Top
2025.05.21 22:30:00.617 1: - fix/new: 36_Shelly: log fw-check, model of Shelly3EM, PLUGS_UI implemented
2025.05.21 22:30:00.617 1: - fix/new: 36_Shelly: log fw-check, model of Shelly3EM, PLUGS_UI implemented
2025.05.21 22:30:00.618 1:
2025.05.21 22:30:00.624 1:
2025.05.21 22:30:00.625 1: Downloading https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt
2025.05.21 22:30:00.625 1: fhemabfall
2025.05.21 22:30:00.675 1: nothing to do...
2025.05.21 22:30:00.676 1:
2025.05.21 22:30:00.676 1:
2025.05.21 22:30:00.676 1: Downloading https://git.cooltux.net/FHEM/mod-NUKI/raw/branch/devel/controls_NukiSmart.txt
2025.05.21 22:30:00.677 1: NukiSmart
2025.05.21 22:30:00.890 1: nothing to do...
2025.05.21 22:30:00.890 1:
2025.05.21 22:30:00.891 1:
2025.05.21 22:30:00.891 1: Downloading https://raw.githubusercontent.com/LuRhe/fhem-46_GoECharger/main/controls_46_GoECharger.txt
2025.05.21 22:30:00.891 1: 46_GoECharger
2025.05.21 22:30:01.322 1: nothing to do...
2025.05.21 22:30:01.322 1: Calling /usr/bin/perl ./contrib/commandref_modular.pl, this may take a while
2025.05.21 22:30:01.747 1:
2025.05.21 22:30:01.747 1: update finished, "shutdown restart" is needed to activate the changes.
2025.05.21 22:30:01.747 1:
2025.05.21 22:30:01.748 1: Please consider using the global attribute sendStatistics
2025.05.21 22:30:27.560 3: MQTT2_DEVICE set Stehlampe off
2025.05.21 22:30:28.259 3: MQTT2_DEVICE set TV off
2025.05.21 22:30:36.678 3: [Shelly_firmwarecheck] Klingel: current=20230913-112003/v1.14.0-gcb84623 update=none beta=20231107-162940/v1.14.1-rc1-g0617c15
2025.05.21 22:30:38.481 3: [Shelly_firmwarecheck] Gartenlampen: current=20230913-112003/v1.14.0-gcb84623 update=none beta=20231107-162940/v1.14.1-rc1-g0617c15
2025.05.21 22:30:54.833 3: [Shelly_firmwarecheck] Terrassendach: current=20230913-112003/v1.14.0-gcb84623 update=none beta=20231107-162940/v1.14.1-rc1-g0617c15
2025.05.21 22:31:10.027 1: Server shutdown delayed due to alexa for max 10 sec
2025.05.21 22:31:12.114 3: alexa: read: end of file reached while sysread
2025.05.21 22:31:12.114 3: alexa: stopped
2025.05.21 22:31:13.042 0: Server shutdown
2025.05.21 22:31:14 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 14.
2025.05.21 22:31:14.690 1: Including fhem.cfg
2025.05.21 22:31:14.695 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_goe_PV.pm line 14, <$fh> line 9.
2025.05.21 22:31:14.695 1: PERL WARNING: Subroutine GoEC_setPvSP redefined at ./FHEM/99_goe_PV.pm line 19, <$fh> line 9.
2025.05.21 22:31:14.810 3: WEB: port 8083 opened
2025.05.21 22:31:14.812 3: WEBphone: port 8084 opened
2025.05.21 22:31:14.813 3: WEBtablet: port 8085 opened
2025.05.21 22:31:14.944 2: eventTypes: loaded 10817 lines from ./log/eventTypes.txt
2025.05.21 22:31:15.307 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2025.05.21 22:31:15.308 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2025.05.21 22:31:15.308 3: MOBILEUI: new ext defined infix:mobile/: dir:./www/mobile/:
2025.05.21 22:31:15.308 3: Registering HTTPSRV MOBILEUI for URL /mobile and assigned link mobile/ ...
2025.05.21 22:31:15.329 1: HMLAN_Parse: HMUSB new condition disconnected
2025.05.21 22:31:15.731 3: Opening Rademacher device /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00PU21-if00-port0
2025.05.21 22:31:15.746 3: Setting Rademacher serial parameters to 115200,8,N,1
2025.05.21 22:31:15.748 3: Rademacher device opened
2025.05.21 22:31:15.786 2: Registering GEOFANCY geofancy for URL /geo...
2025.05.21 22:31:15.985 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2025.05.21 22:31:15.985 3: AMADBridge: port 8090 opened
2025.05.21 22:31:15.986 3: AMADCommBridge (AMADBridge) - Socket opened.
2025.05.21 22:31:16.012 3: AMADDevice (Wandtablet) - I/O device is AMADBridge
2025.05.21 22:31:16.012 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:31:16.012 3: AMADDevice (Wandtablet) - defined with AMAD_ID: 1511977959382 on port 8090
2025.05.21 22:31:16.012 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:31:16.283 3: Opening myJeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2025.05.21 22:31:16.284 3: Setting myJeeLink serial parameters to 57600,8,N,1
2025.05.21 22:31:17.286 3: myJeeLink device opened
2025.05.21 22:31:17.364 3: Garage_PV_R: Defined with URL and interval 30 featurelevel 6.4
2025.05.21 22:31:17.391 3: telnetPort: port 7072 opened
2025.05.21 22:31:17.430 3: Garage_PV_L: Defined with URL and interval 30 featurelevel 6.4
2025.05.21 22:31:17.528 3: Aussentemp: I/O device is myJeeLink
2025.05.21 22:31:17.625 3: HUEDevice1: I/O device is ..
2025.05.21 22:31:17.626 3: HUEGroup0: I/O device is ..
2025.05.21 22:31:17.627 3: HUEGroup1: I/O device is ..
2025.05.21 22:31:17.628 3: HUEGroup2: I/O device is ..
2025.05.21 22:31:17.629 3: HUESensor1: I/O device is ..
2025.05.21 22:31:17.708 3: GoECharger (myGoE) - defined GoECharger Device with Host 192.168.188.138 and Interval 60
2025.05.21 22:31:17.709 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:31:17.710 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:31:17.711 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:31:17.711 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:31:17.712 3: deletereading myGoE .* : Deleted reading Http_state for device myGoE
2025.05.21 22:31:21.488 3: PV_Prognose - cached data "pvHistory" restored
2025.05.21 22:31:21.492 3: PV_Prognose - cached data "pvCircular" restored
2025.05.21 22:31:21.492 3: PV_Prognose - cached data "radiationApiData" restored
2025.05.21 22:31:21.493 3: PV_Prognose - cached data "statusApiData" restored
2025.05.21 22:31:21.493 3: PV_Prognose - cached data "weatherApiData" restored
2025.05.21 22:31:21.525 3: PV_Prognose - cached data "aiTrainedData" restored
2025.05.21 22:31:21.535 3: PV_Prognose - cached data "aiRawData" restored
2025.05.21 22:31:21.590 1: Including ./log/fhem.save
2025.05.21 22:31:21.984 3: No I/O device found for CUL_HOERMANN_09AFF60A20
2025.05.21 22:31:21.987 3: No I/O device found for HMS100TF_0000
2025.05.21 22:31:21.988 3: No I/O device found for IT_1527x0eed3
2025.05.21 22:31:22.000 3: Opening HMUSB device 127.0.0.1:1234
2025.05.21 22:31:22.002 1: HMLAN_Parse: HMUSB new condition init
2025.05.21 22:31:22.005 3: HMUSB device opened
2025.05.21 22:31:23.337 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx
2025.05.21 22:31:23.346 3: alexa: starting
2025.05.21 22:31:23.370 3: alexa: using logfile: ./log/alexa-2025-05-21.log
2025.05.21 22:31:29.507 1: usb create starting
2025.05.21 22:31:29.582 3: Probing CUL device /dev/ttyS0
2025.05.21 22:31:29.582 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 613.
2025.05.21 22:31:29.583 1: CUL: Can't open /dev/ttyS0: Input/output error
2025.05.21 22:31:29.583 3: Probing CUL device /dev/ttyS1
2025.05.21 22:31:29.583 1: CUL: Can't open /dev/ttyS1: Input/output error
2025.05.21 22:31:29.583 3: Probing CUL device /dev/ttyS10
2025.05.21 22:31:29.584 1: CUL: Can't open /dev/ttyS10: Input/output error
2025.05.21 22:31:29.584 3: Probing CUL device /dev/ttyS11
2025.05.21 22:31:29.584 1: CUL: Can't open /dev/ttyS11: Input/output error
2025.05.21 22:31:29.584 3: Probing CUL device /dev/ttyS12
2025.05.21 22:31:29.585 1: CUL: Can't open /dev/ttyS12: Input/output error
2025.05.21 22:31:29.585 3: Probing CUL device /dev/ttyS13
2025.05.21 22:31:29.585 1: CUL: Can't open /dev/ttyS13: Input/output error
2025.05.21 22:31:29.585 3: Probing CUL device /dev/ttyS14
2025.05.21 22:31:29.586 1: CUL: Can't open /dev/ttyS14: Input/output error
2025.05.21 22:31:29.586 3: Probing CUL device /dev/ttyS15
2025.05.21 22:31:29.586 1: CUL: Can't open /dev/ttyS15: Input/output error
2025.05.21 22:31:29.586 3: Probing CUL device /dev/ttyS16
2025.05.21 22:31:29.587 1: CUL: Can't open /dev/ttyS16: Input/output error
2025.05.21 22:31:29.587 3: Probing CUL device /dev/ttyS17
2025.05.21 22:31:29.587 1: CUL: Can't open /dev/ttyS17: Input/output error
2025.05.21 22:31:29.587 3: Probing CUL device /dev/ttyS18
2025.05.21 22:31:29.588 1: CUL: Can't open /dev/ttyS18: Input/output error
2025.05.21 22:31:29.588 3: Probing CUL device /dev/ttyS19
2025.05.21 22:31:29.588 1: CUL: Can't open /dev/ttyS19: Input/output error
2025.05.21 22:31:29.588 3: Probing CUL device /dev/ttyS2
2025.05.21 22:31:29.588 1: CUL: Can't open /dev/ttyS2: Input/output error
2025.05.21 22:31:29.589 3: Probing CUL device /dev/ttyS20
2025.05.21 22:31:29.589 1: CUL: Can't open /dev/ttyS20: Input/output error
2025.05.21 22:31:29.589 3: Probing CUL device /dev/ttyS21
2025.05.21 22:31:29.589 1: CUL: Can't open /dev/ttyS21: Input/output error
2025.05.21 22:31:29.590 3: Probing CUL device /dev/ttyS22
2025.05.21 22:31:29.590 1: CUL: Can't open /dev/ttyS22: Input/output error
2025.05.21 22:31:29.590 3: Probing CUL device /dev/ttyS23
2025.05.21 22:31:29.590 1: CUL: Can't open /dev/ttyS23: Input/output error
2025.05.21 22:31:29.591 3: Probing CUL device /dev/ttyS24
2025.05.21 22:31:29.591 1: CUL: Can't open /dev/ttyS24: Input/output error
2025.05.21 22:31:29.591 3: Probing CUL device /dev/ttyS25
2025.05.21 22:31:29.591 1: CUL: Can't open /dev/ttyS25: Input/output error
2025.05.21 22:31:29.592 3: Probing CUL device /dev/ttyS26
2025.05.21 22:31:29.592 1: CUL: Can't open /dev/ttyS26: Input/output error
2025.05.21 22:31:29.592 3: Probing CUL device /dev/ttyS27
2025.05.21 22:31:29.592 1: CUL: Can't open /dev/ttyS27: Input/output error
2025.05.21 22:31:29.593 3: Probing CUL device /dev/ttyS28
2025.05.21 22:31:29.593 1: CUL: Can't open /dev/ttyS28: Input/output error
2025.05.21 22:31:29.593 3: Probing CUL device /dev/ttyS29
2025.05.21 22:31:29.593 1: CUL: Can't open /dev/ttyS29: Input/output error
2025.05.21 22:31:29.594 3: Probing CUL device /dev/ttyS3
2025.05.21 22:31:29.594 1: CUL: Can't open /dev/ttyS3: Input/output error
2025.05.21 22:31:29.594 3: Probing CUL device /dev/ttyS30
2025.05.21 22:31:29.594 1: CUL: Can't open /dev/ttyS30: Input/output error
2025.05.21 22:31:29.595 3: Probing CUL device /dev/ttyS31
2025.05.21 22:31:29.595 1: CUL: Can't open /dev/ttyS31: Input/output error
2025.05.21 22:31:29.595 3: Probing CUL device /dev/ttyS4
2025.05.21 22:31:29.595 1: CUL: Can't open /dev/ttyS4: Input/output error
2025.05.21 22:31:29.596 3: Probing CUL device /dev/ttyS5
2025.05.21 22:31:29.596 1: CUL: Can't open /dev/ttyS5: Input/output error
2025.05.21 22:31:29.596 3: Probing CUL device /dev/ttyS6
2025.05.21 22:31:29.596 1: CUL: Can't open /dev/ttyS6: Input/output error
2025.05.21 22:31:29.596 3: Probing CUL device /dev/ttyS7
2025.05.21 22:31:29.597 1: CUL: Can't open /dev/ttyS7: Input/output error
2025.05.21 22:31:29.597 3: Probing CUL device /dev/ttyS8
2025.05.21 22:31:29.597 1: CUL: Can't open /dev/ttyS8: Input/output error
2025.05.21 22:31:29.597 3: Probing CUL device /dev/ttyS9
2025.05.21 22:31:29.598 1: CUL: Can't open /dev/ttyS9: Input/output error
2025.05.21 22:31:29.606 1: usb create end
2025.05.21 22:31:29.637 0: Featurelevel: 6.4
2025.05.21 22:31:29.637 0: Server started with 343 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:1627228)
2025.05.21 22:31:29.643 3: myBroker: port 2000 opened
2025.05.21 22:31:29.963 3: telnetForBlockingFn_1747859489.9632: port 43145 opened
2025.05.21 22:31:30.087 1: HMLAN_Parse: HMUSB new condition ok
Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE strings$/ at ./FHEM/76_SolarForecast.pm line 6960.
2025.05.21 22:31:30 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 14.
2025.05.21 22:31:30.682 1: Including fhem.cfg
2025.05.21 22:31:30.686 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_goe_PV.pm line 14, <$fh> line 9.
2025.05.21 22:31:30.687 1: PERL WARNING: Subroutine GoEC_setPvSP redefined at ./FHEM/99_goe_PV.pm line 19, <$fh> line 9.
2025.05.21 22:31:30.795 3: WEB: port 8083 opened
2025.05.21 22:31:30.797 3: WEBphone: port 8084 opened
2025.05.21 22:31:30.798 3: WEBtablet: port 8085 opened
2025.05.21 22:31:30.926 2: eventTypes: loaded 10817 lines from ./log/eventTypes.txt
2025.05.21 22:31:31.279 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2025.05.21 22:31:31.279 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2025.05.21 22:31:31.280 3: MOBILEUI: new ext defined infix:mobile/: dir:./www/mobile/:
2025.05.21 22:31:31.280 3: Registering HTTPSRV MOBILEUI for URL /mobile and assigned link mobile/ ...
2025.05.21 22:31:31.299 1: HMLAN_Parse: HMUSB new condition disconnected
2025.05.21 22:31:31.691 3: Opening Rademacher device /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00PU21-if00-port0
2025.05.21 22:31:31.704 3: Setting Rademacher serial parameters to 115200,8,N,1
2025.05.21 22:31:31.706 3: Rademacher device opened
2025.05.21 22:31:31.743 2: Registering GEOFANCY geofancy for URL /geo...
2025.05.21 22:31:31.938 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2025.05.21 22:31:31.939 3: AMADBridge: port 8090 opened
2025.05.21 22:31:31.939 3: AMADCommBridge (AMADBridge) - Socket opened.
2025.05.21 22:31:31.965 3: AMADDevice (Wandtablet) - I/O device is AMADBridge
2025.05.21 22:31:31.965 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:31:31.965 3: AMADDevice (Wandtablet) - defined with AMAD_ID: 1511977959382 on port 8090
2025.05.21 22:31:31.965 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:31:32.235 3: Opening myJeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2025.05.21 22:31:32.236 3: Setting myJeeLink serial parameters to 57600,8,N,1
2025.05.21 22:31:33.238 3: myJeeLink device opened
2025.05.21 22:31:33.315 3: Garage_PV_R: Defined with URL and interval 30 featurelevel 6.4
2025.05.21 22:31:33.342 3: telnetPort: port 7072 opened
2025.05.21 22:31:33.380 3: Garage_PV_L: Defined with URL and interval 30 featurelevel 6.4
2025.05.21 22:31:33.476 3: Aussentemp: I/O device is myJeeLink
2025.05.21 22:31:33.573 3: HUEDevice1: I/O device is ..
2025.05.21 22:31:33.574 3: HUEGroup0: I/O device is ..
2025.05.21 22:31:33.575 3: HUEGroup1: I/O device is ..
2025.05.21 22:31:33.576 3: HUEGroup2: I/O device is ..
2025.05.21 22:31:33.577 3: HUESensor1: I/O device is ..
2025.05.21 22:31:33.654 3: GoECharger (myGoE) - defined GoECharger Device with Host 192.168.188.138 and Interval 60
2025.05.21 22:31:33.656 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:31:33.656 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:31:33.657 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:31:33.658 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:31:33.658 3: deletereading myGoE .* : Deleted reading Http_state for device myGoE
2025.05.21 22:31:37.370 3: PV_Prognose - cached data "pvHistory" restored
2025.05.21 22:31:37.373 3: PV_Prognose - cached data "pvCircular" restored
2025.05.21 22:31:37.374 3: PV_Prognose - cached data "radiationApiData" restored
2025.05.21 22:31:37.374 3: PV_Prognose - cached data "statusApiData" restored
2025.05.21 22:31:37.375 3: PV_Prognose - cached data "weatherApiData" restored
2025.05.21 22:31:37.407 3: PV_Prognose - cached data "aiTrainedData" restored
2025.05.21 22:31:37.417 3: PV_Prognose - cached data "aiRawData" restored
2025.05.21 22:31:37.470 1: Including ./log/fhem.save
2025.05.21 22:31:37.863 3: No I/O device found for HMS100TF_0000
2025.05.21 22:31:37.865 3: No I/O device found for IT_1527x0eed3
2025.05.21 22:31:37.867 3: No I/O device found for CUL_HOERMANN_09AFF60A20
2025.05.21 22:31:37.878 3: Opening HMUSB device 127.0.0.1:1234
2025.05.21 22:31:37.880 1: HMLAN_Parse: HMUSB new condition init
2025.05.21 22:31:37.882 3: HMUSB device opened
2025.05.21 22:31:38.939 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx
2025.05.21 22:31:38.947 3: alexa: starting
2025.05.21 22:31:38.967 3: alexa: using logfile: ./log/alexa-2025-05-21.log
2025.05.21 22:31:45.123 1: usb create starting
2025.05.21 22:31:45.196 3: Probing CUL device /dev/ttyS0
2025.05.21 22:31:45.197 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 613.
2025.05.21 22:31:45.197 1: CUL: Can't open /dev/ttyS0: Input/output error
2025.05.21 22:31:45.198 3: Probing CUL device /dev/ttyS1
2025.05.21 22:31:45.198 1: CUL: Can't open /dev/ttyS1: Input/output error
2025.05.21 22:31:45.198 3: Probing CUL device /dev/ttyS10
2025.05.21 22:31:45.198 1: CUL: Can't open /dev/ttyS10: Input/output error
2025.05.21 22:31:45.199 3: Probing CUL device /dev/ttyS11
2025.05.21 22:31:45.199 1: CUL: Can't open /dev/ttyS11: Input/output error
2025.05.21 22:31:45.199 3: Probing CUL device /dev/ttyS12
2025.05.21 22:31:45.199 1: CUL: Can't open /dev/ttyS12: Input/output error
2025.05.21 22:31:45.200 3: Probing CUL device /dev/ttyS13
2025.05.21 22:31:45.200 1: CUL: Can't open /dev/ttyS13: Input/output error
2025.05.21 22:31:45.200 3: Probing CUL device /dev/ttyS14
2025.05.21 22:31:45.200 1: CUL: Can't open /dev/ttyS14: Input/output error
2025.05.21 22:31:45.201 3: Probing CUL device /dev/ttyS15
2025.05.21 22:31:45.201 1: CUL: Can't open /dev/ttyS15: Input/output error
2025.05.21 22:31:45.201 3: Probing CUL device /dev/ttyS16
2025.05.21 22:31:45.201 1: CUL: Can't open /dev/ttyS16: Input/output error
2025.05.21 22:31:45.202 3: Probing CUL device /dev/ttyS17
2025.05.21 22:31:45.202 1: CUL: Can't open /dev/ttyS17: Input/output error
2025.05.21 22:31:45.202 3: Probing CUL device /dev/ttyS18
2025.05.21 22:31:45.202 1: CUL: Can't open /dev/ttyS18: Input/output error
2025.05.21 22:31:45.203 3: Probing CUL device /dev/ttyS19
2025.05.21 22:31:45.203 1: CUL: Can't open /dev/ttyS19: Input/output error
2025.05.21 22:31:45.203 3: Probing CUL device /dev/ttyS2
2025.05.21 22:31:45.203 1: CUL: Can't open /dev/ttyS2: Input/output error
2025.05.21 22:31:45.204 3: Probing CUL device /dev/ttyS20
2025.05.21 22:31:45.204 1: CUL: Can't open /dev/ttyS20: Input/output error
2025.05.21 22:31:45.204 3: Probing CUL device /dev/ttyS21
2025.05.21 22:31:45.204 1: CUL: Can't open /dev/ttyS21: Input/output error
2025.05.21 22:31:45.204 3: Probing CUL device /dev/ttyS22
2025.05.21 22:31:45.205 1: CUL: Can't open /dev/ttyS22: Input/output error
2025.05.21 22:31:45.205 3: Probing CUL device /dev/ttyS23
2025.05.21 22:31:45.205 1: CUL: Can't open /dev/ttyS23: Input/output error
2025.05.21 22:31:45.205 3: Probing CUL device /dev/ttyS24
2025.05.21 22:31:45.206 1: CUL: Can't open /dev/ttyS24: Input/output error
2025.05.21 22:31:45.206 3: Probing CUL device /dev/ttyS25
2025.05.21 22:31:45.206 1: CUL: Can't open /dev/ttyS25: Input/output error
2025.05.21 22:31:45.206 3: Probing CUL device /dev/ttyS26
2025.05.21 22:31:45.207 1: CUL: Can't open /dev/ttyS26: Input/output error
2025.05.21 22:31:45.207 3: Probing CUL device /dev/ttyS27
2025.05.21 22:31:45.207 1: CUL: Can't open /dev/ttyS27: Input/output error
2025.05.21 22:31:45.207 3: Probing CUL device /dev/ttyS28
2025.05.21 22:31:45.208 1: CUL: Can't open /dev/ttyS28: Input/output error
2025.05.21 22:31:45.208 3: Probing CUL device /dev/ttyS29
2025.05.21 22:31:45.208 1: CUL: Can't open /dev/ttyS29: Input/output error
2025.05.21 22:31:45.208 3: Probing CUL device /dev/ttyS3
2025.05.21 22:31:45.209 1: CUL: Can't open /dev/ttyS3: Input/output error
2025.05.21 22:31:45.209 3: Probing CUL device /dev/ttyS30
2025.05.21 22:31:45.209 1: CUL: Can't open /dev/ttyS30: Input/output error
2025.05.21 22:31:45.209 3: Probing CUL device /dev/ttyS31
2025.05.21 22:31:45.210 1: CUL: Can't open /dev/ttyS31: Input/output error
2025.05.21 22:31:45.210 3: Probing CUL device /dev/ttyS4
2025.05.21 22:31:45.210 1: CUL: Can't open /dev/ttyS4: Input/output error
2025.05.21 22:31:45.210 3: Probing CUL device /dev/ttyS5
2025.05.21 22:31:45.210 1: CUL: Can't open /dev/ttyS5: Input/output error
2025.05.21 22:31:45.211 3: Probing CUL device /dev/ttyS6
2025.05.21 22:31:45.211 1: CUL: Can't open /dev/ttyS6: Input/output error
2025.05.21 22:31:45.211 3: Probing CUL device /dev/ttyS7
2025.05.21 22:31:45.211 1: CUL: Can't open /dev/ttyS7: Input/output error
2025.05.21 22:31:45.212 3: Probing CUL device /dev/ttyS8
2025.05.21 22:31:45.212 1: CUL: Can't open /dev/ttyS8: Input/output error
2025.05.21 22:31:45.212 3: Probing CUL device /dev/ttyS9
2025.05.21 22:31:45.212 1: CUL: Can't open /dev/ttyS9: Input/output error
2025.05.21 22:31:45.220 1: usb create end
2025.05.21 22:31:45.248 0: Featurelevel: 6.4
2025.05.21 22:31:45.248 0: Server started with 343 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:1627245)
2025.05.21 22:31:45.254 3: myBroker: port 2000 opened
2025.05.21 22:31:45.574 3: telnetForBlockingFn_1747859505.57361: port 43745 opened
2025.05.21 22:31:45.772 1: HMLAN_Parse: HMUSB new condition ok
2025.05.21 22:31:45.813 2: autocreate: define DUOFERN_000000 DUOFERN 000000
2025.05.21 22:31:45.818 1: RMDIR: ./restoreDir/save/2025-05-02
Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE strings$/ at ./FHEM/76_SolarForecast.pm line 6960.
2025.05.21 22:31:46 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 14.
2025.05.21 22:31:46.510 1: Including fhem.cfg
2025.05.21 22:31:46.515 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_goe_PV.pm line 14, <$fh> line 9.
2025.05.21 22:31:46.515 1: PERL WARNING: Subroutine GoEC_setPvSP redefined at ./FHEM/99_goe_PV.pm line 19, <$fh> line 9.
2025.05.21 22:31:46.626 3: WEB: port 8083 opened
2025.05.21 22:31:46.628 3: WEBphone: port 8084 opened
2025.05.21 22:31:46.628 3: WEBtablet: port 8085 opened
2025.05.21 22:31:46.758 2: eventTypes: loaded 10817 lines from ./log/eventTypes.txt
2025.05.21 22:31:47.120 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2025.05.21 22:31:47.120 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2025.05.21 22:31:47.121 3: MOBILEUI: new ext defined infix:mobile/: dir:./www/mobile/:
2025.05.21 22:31:47.121 3: Registering HTTPSRV MOBILEUI for URL /mobile and assigned link mobile/ ...
2025.05.21 22:31:47.141 1: HMLAN_Parse: HMUSB new condition disconnected
2025.05.21 22:31:47.535 3: Opening Rademacher device /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00PU21-if00-port0
2025.05.21 22:31:47.548 3: Setting Rademacher serial parameters to 115200,8,N,1
2025.05.21 22:31:47.550 3: Rademacher device opened
2025.05.21 22:31:47.587 2: Registering GEOFANCY geofancy for URL /geo...
2025.05.21 22:31:47.786 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2025.05.21 22:31:47.786 3: AMADBridge: port 8090 opened
2025.05.21 22:31:47.787 3: AMADCommBridge (AMADBridge) - Socket opened.
2025.05.21 22:31:47.812 3: AMADDevice (Wandtablet) - I/O device is AMADBridge
2025.05.21 22:31:47.812 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:31:47.812 3: AMADDevice (Wandtablet) - defined with AMAD_ID: 1511977959382 on port 8090
2025.05.21 22:31:47.813 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:31:48.084 3: Opening myJeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2025.05.21 22:31:48.085 3: Setting myJeeLink serial parameters to 57600,8,N,1
2025.05.21 22:31:49.087 3: myJeeLink device opened
2025.05.21 22:31:49.164 3: Garage_PV_R: Defined with URL .. and interval 30 featurelevel 6.4
2025.05.21 22:31:49.191 3: telnetPort: port 7072 opened
2025.05.21 22:31:49.229 3: Garage_PV_L: Defined with URL .. and interval 30 featurelevel 6.4
2025.05.21 22:31:49.327 3: Aussentemp: I/O device is myJeeLink
2025.05.21 22:31:49.424 3: HUEDevice1: I/O device is ..
2025.05.21 22:31:49.425 3: HUEGroup0: I/O device is ..
2025.05.21 22:31:49.426 3: HUEGroup1: I/O device is ..
2025.05.21 22:31:49.428 3: HUEGroup2: I/O device is ..
2025.05.21 22:31:49.429 3: HUESensor1: I/O device is ..
2025.05.21 22:31:49.507 3: GoECharger (myGoE) - defined GoECharger Device with Host 192.168.188.138 and Interval 60
2025.05.21 22:31:49.508 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:31:49.508 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:31:49.510 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:31:49.510 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:31:49.510 3: deletereading myGoE .* : Deleted reading Http_state for device myGoE
2025.05.21 22:31:53.255 3: PV_Prognose - cached data "pvHistory" restored
2025.05.21 22:31:53.259 3: PV_Prognose - cached data "pvCircular" restored
2025.05.21 22:31:53.260 3: PV_Prognose - cached data "radiationApiData" restored
2025.05.21 22:31:53.260 3: PV_Prognose - cached data "statusApiData" restored
2025.05.21 22:31:53.260 3: PV_Prognose - cached data "weatherApiData" restored
2025.05.21 22:31:53.293 3: PV_Prognose - cached data "aiTrainedData" restored
2025.05.21 22:31:53.303 3: PV_Prognose - cached data "aiRawData" restored
2025.05.21 22:31:53.359 1: Including ./log/fhem.save
2025.05.21 22:31:53.751 3: No I/O device found for IT_1527x0eed3
2025.05.21 22:31:53.753 3: No I/O device found for CUL_HOERMANN_09AFF60A20
2025.05.21 22:31:53.755 3: No I/O device found for HMS100TF_0000
2025.05.21 22:31:53.766 3: Opening HMUSB device 127.0.0.1:1234
2025.05.21 22:31:53.768 1: HMLAN_Parse: HMUSB new condition init
2025.05.21 22:31:53.770 3: HMUSB device opened
2025.05.21 22:31:54.809 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx
2025.05.21 22:31:54.817 3: alexa: starting
2025.05.21 22:31:54.837 3: alexa: using logfile: ./log/alexa-2025-05-21.log
2025.05.21 22:32:00.963 1: usb create starting
2025.05.21 22:32:01.048 3: Probing CUL device /dev/ttyS0
2025.05.21 22:32:01.049 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 613.
2025.05.21 22:32:01.049 1: CUL: Can't open /dev/ttyS0: Input/output error
2025.05.21 22:32:01.050 3: Probing CUL device /dev/ttyS1
2025.05.21 22:32:01.050 1: CUL: Can't open /dev/ttyS1: Input/output error
2025.05.21 22:32:01.050 3: Probing CUL device /dev/ttyS10
2025.05.21 22:32:01.051 1: CUL: Can't open /dev/ttyS10: Input/output error
2025.05.21 22:32:01.051 3: Probing CUL device /dev/ttyS11
2025.05.21 22:32:01.051 1: CUL: Can't open /dev/ttyS11: Input/output error
2025.05.21 22:32:01.051 3: Probing CUL device /dev/ttyS12
2025.05.21 22:32:01.052 1: CUL: Can't open /dev/ttyS12: Input/output error
2025.05.21 22:32:01.052 3: Probing CUL device /dev/ttyS13
2025.05.21 22:32:01.052 1: CUL: Can't open /dev/ttyS13: Input/output error
2025.05.21 22:32:01.053 3: Probing CUL device /dev/ttyS14
2025.05.21 22:32:01.053 1: CUL: Can't open /dev/ttyS14: Input/output error
2025.05.21 22:32:01.053 3: Probing CUL device /dev/ttyS15
2025.05.21 22:32:01.053 1: CUL: Can't open /dev/ttyS15: Input/output error
2025.05.21 22:32:01.054 3: Probing CUL device /dev/ttyS16
2025.05.21 22:32:01.054 1: CUL: Can't open /dev/ttyS16: Input/output error
2025.05.21 22:32:01.054 3: Probing CUL device /dev/ttyS17
2025.05.21 22:32:01.055 1: CUL: Can't open /dev/ttyS17: Input/output error
2025.05.21 22:32:01.055 3: Probing CUL device /dev/ttyS18
2025.05.21 22:32:01.055 1: CUL: Can't open /dev/ttyS18: Input/output error
2025.05.21 22:32:01.056 3: Probing CUL device /dev/ttyS19
2025.05.21 22:32:01.056 1: CUL: Can't open /dev/ttyS19: Input/output error
2025.05.21 22:32:01.056 3: Probing CUL device /dev/ttyS2
2025.05.21 22:32:01.056 1: CUL: Can't open /dev/ttyS2: Input/output error
2025.05.21 22:32:01.057 3: Probing CUL device /dev/ttyS20
2025.05.21 22:32:01.057 1: CUL: Can't open /dev/ttyS20: Input/output error
2025.05.21 22:32:01.057 3: Probing CUL device /dev/ttyS21
2025.05.21 22:32:01.057 1: CUL: Can't open /dev/ttyS21: Input/output error
2025.05.21 22:32:01.058 3: Probing CUL device /dev/ttyS22
2025.05.21 22:32:01.058 1: CUL: Can't open /dev/ttyS22: Input/output error
2025.05.21 22:32:01.058 3: Probing CUL device /dev/ttyS23
2025.05.21 22:32:01.059 1: CUL: Can't open /dev/ttyS23: Input/output error
2025.05.21 22:32:01.059 3: Probing CUL device /dev/ttyS24
2025.05.21 22:32:01.059 1: CUL: Can't open /dev/ttyS24: Input/output error
2025.05.21 22:32:01.060 3: Probing CUL device /dev/ttyS25
2025.05.21 22:32:01.060 1: CUL: Can't open /dev/ttyS25: Input/output error
2025.05.21 22:32:01.060 3: Probing CUL device /dev/ttyS26
2025.05.21 22:32:01.060 1: CUL: Can't open /dev/ttyS26: Input/output error
2025.05.21 22:32:01.061 3: Probing CUL device /dev/ttyS27
2025.05.21 22:32:01.061 1: CUL: Can't open /dev/ttyS27: Input/output error
2025.05.21 22:32:01.061 3: Probing CUL device /dev/ttyS28
2025.05.21 22:32:01.061 1: CUL: Can't open /dev/ttyS28: Input/output error
2025.05.21 22:32:01.062 3: Probing CUL device /dev/ttyS29
2025.05.21 22:32:01.062 1: CUL: Can't open /dev/ttyS29: Input/output error
2025.05.21 22:32:01.062 3: Probing CUL device /dev/ttyS3
2025.05.21 22:32:01.063 1: CUL: Can't open /dev/ttyS3: Input/output error
2025.05.21 22:32:01.063 3: Probing CUL device /dev/ttyS30
2025.05.21 22:32:01.063 1: CUL: Can't open /dev/ttyS30: Input/output error
2025.05.21 22:32:01.064 3: Probing CUL device /dev/ttyS31
2025.05.21 22:32:01.064 1: CUL: Can't open /dev/ttyS31: Input/output error
2025.05.21 22:32:01.064 3: Probing CUL device /dev/ttyS4
2025.05.21 22:32:01.064 1: CUL: Can't open /dev/ttyS4: Input/output error
2025.05.21 22:32:01.065 3: Probing CUL device /dev/ttyS5
2025.05.21 22:32:01.065 1: CUL: Can't open /dev/ttyS5: Input/output error
2025.05.21 22:32:01.065 3: Probing CUL device /dev/ttyS6
2025.05.21 22:32:01.065 1: CUL: Can't open /dev/ttyS6: Input/output error
2025.05.21 22:32:01.066 3: Probing CUL device /dev/ttyS7
2025.05.21 22:32:01.066 1: CUL: Can't open /dev/ttyS7: Input/output error
2025.05.21 22:32:01.066 3: Probing CUL device /dev/ttyS8
2025.05.21 22:32:01.066 1: CUL: Can't open /dev/ttyS8: Input/output error
2025.05.21 22:32:01.067 3: Probing CUL device /dev/ttyS9
2025.05.21 22:32:01.067 1: CUL: Can't open /dev/ttyS9: Input/output error
2025.05.21 22:32:01.076 1: usb create end
2025.05.21 22:32:01.104 0: Featurelevel: 6.4
2025.05.21 22:32:01.104 0: Server started with 344 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:1627262)
2025.05.21 22:32:01.110 3: myBroker: port 2000 opened
2025.05.21 22:32:01.427 3: telnetForBlockingFn_1747859521.42716: port 45333 opened
2025.05.21 22:32:01.577 1: HMLAN_Parse: HMUSB new condition ok
Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE strings$/ at ./FHEM/76_SolarForecast.pm line 6960.
2025.05.21 22:32:02 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 14.
2025.05.21 22:32:02.177 1: Including fhem.cfg
2025.05.21 22:32:02.181 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_goe_PV.pm line 14, <$fh> line 9.
2025.05.21 22:32:02.182 1: PERL WARNING: Subroutine GoEC_setPvSP redefined at ./FHEM/99_goe_PV.pm line 19, <$fh> line 9.
2025.05.21 22:32:02.290 3: WEB: port 8083 opened
2025.05.21 22:32:02.291 3: WEBphone: port 8084 opened
2025.05.21 22:32:02.292 3: WEBtablet: port 8085 opened
2025.05.21 22:32:02.422 2: eventTypes: loaded 10817 lines from ./log/eventTypes.txt
2025.05.21 22:32:02.787 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2025.05.21 22:32:02.787 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2025.05.21 22:32:02.788 3: MOBILEUI: new ext defined infix:mobile/: dir:./www/mobile/:
2025.05.21 22:32:02.788 3: Registering HTTPSRV MOBILEUI for URL /mobile and assigned link mobile/ ...
2025.05.21 22:32:02.808 1: HMLAN_Parse: HMUSB new condition disconnected
2025.05.21 22:32:03.198 3: Opening Rademacher device /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00PU21-if00-port0
2025.05.21 22:32:03.211 3: Setting Rademacher serial parameters to 115200,8,N,1
2025.05.21 22:32:03.213 3: Rademacher device opened
2025.05.21 22:32:03.250 2: Registering GEOFANCY geofancy for URL /geo...
2025.05.21 22:32:03.446 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2025.05.21 22:32:03.447 3: AMADBridge: port 8090 opened
2025.05.21 22:32:03.447 3: AMADCommBridge (AMADBridge) - Socket opened.
2025.05.21 22:32:03.472 3: AMADDevice (Wandtablet) - I/O device is AMADBridge
2025.05.21 22:32:03.472 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:32:03.472 3: AMADDevice (Wandtablet) - defined with AMAD_ID: 1511977959382 on port 8090
2025.05.21 22:32:03.473 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.05.21 22:32:03.740 3: Opening myJeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2025.05.21 22:32:03.741 3: Setting myJeeLink serial parameters to 57600,8,N,1
2025.05.21 22:32:04.743 3: myJeeLink device opened
2025.05.21 22:32:04.821 3: Garage_PV_R: Defined with URL .. and interval 30 featurelevel 6.4
2025.05.21 22:32:04.848 3: telnetPort: port 7072 opened
2025.05.21 22:32:04.886 3: Garage_PV_L: Defined with URL .. and interval 30 featurelevel 6.4
2025.05.21 22:32:04.982 3: Aussentemp: I/O device is myJeeLink
2025.05.21 22:32:05.078 3: HUEDevice1: I/O device is ..
2025.05.21 22:32:05.079 3: HUEGroup0: I/O device is ..
2025.05.21 22:32:05.080 3: HUEGroup1: I/O device is ..
2025.05.21 22:32:05.081 3: HUEGroup2: I/O device is ..
2025.05.21 22:32:05.082 3: HUESensor1: I/O device is ..
2025.05.21 22:32:05.158 3: GoECharger (myGoE) - defined GoECharger Device with Host 192.168.188.138 and Interval 60
2025.05.21 22:32:05.160 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:32:05.160 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:32:05.161 3: GoECharger (myGoE) - set interval to 60
2025.05.21 22:32:05.162 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.05.21 22:32:05.162 3: deletereading myGoE .* : Deleted reading Http_state for device myGoE
2025.05.21 22:32:08.866 3: PV_Prognose - cached data "pvHistory" restored
2025.05.21 22:32:08.870 3: PV_Prognose - cached data "pvCircular" restored
2025.05.21 22:32:08.871 3: PV_Prognose - cached data "radiationApiData" restored
2025.05.21 22:32:08.871 3: PV_Prognose - cached data "statusApiData" restored
2025.05.21 22:32:08.871 3: PV_Prognose - cached data "weatherApiData" restored
2025.05.21 22:32:08.903 3: PV_Prognose - cached data "aiTrainedData" restored
2025.05.21 22:32:08.914 3: PV_Prognose - cached data "aiRawData" restored
2025.05.21 22:32:08.969 1: Including ./log/fhem.save
2025.05.21 22:32:09.359 3: No I/O device found for HMS100TF_0000
2025.05.21 22:32:09.361 3: No I/O device found for IT_1527x0eed3
2025.05.21 22:32:09.363 3: No I/O device found for CUL_HOERMANN_09AFF60A20
2025.05.21 22:32:09.375 3: Opening HMUSB device 127.0.0.1:1234
2025.05.21 22:32:09.378 1: HMLAN_Parse: HMUSB new condition init
2025.05.21 22:32:09.380 3: HMUSB device opened
2025.05.21 22:32:10.427 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx
2025.05.21 22:32:10.435 3: alexa: starting
2025.05.21 22:32:10.455 3: alexa: using logfile: ./log/alexa-2025-05-21.log
2025.05.21 22:32:16.611 1: usb create starting
2025.05.21 22:32:16.684 3: Probing CUL device /dev/ttyS0
2025.05.21 22:32:16.685 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 613.
2025.05.21 22:32:16.685 1: CUL: Can't open /dev/ttyS0: Input/output error
2025.05.21 22:32:16.686 3: Probing CUL device /dev/ttyS1
2025.05.21 22:32:16.686 1: CUL: Can't open /dev/ttyS1: Input/output error
2025.05.21 22:32:16.686 3: Probing CUL device /dev/ttyS10
2025.05.21 22:32:16.686 1: CUL: Can't open /dev/ttyS10: Input/output error
2025.05.21 22:32:16.686 3: Probing CUL device /dev/ttyS11
2025.05.21 22:32:16.687 1: CUL: Can't open /dev/ttyS11: Input/output error
2025.05.21 22:32:16.687 3: Probing CUL device /dev/ttyS12
2025.05.21 22:32:16.687 1: CUL: Can't open /dev/ttyS12: Input/output error
2025.05.21 22:32:16.687 3: Probing CUL device /dev/ttyS13
2025.05.21 22:32:16.688 1: CUL: Can't open /dev/ttyS13: Input/output error
2025.05.21 22:32:16.688 3: Probing CUL device /dev/ttyS14
2025.05.21 22:32:16.688 1: CUL: Can't open /dev/ttyS14: Input/output error
2025.05.21 22:32:16.688 3: Probing CUL device /dev/ttyS15
2025.05.21 22:32:16.689 1: CUL: Can't open /dev/ttyS15: Input/output error
2025.05.21 22:32:16.689 3: Probing CUL device /dev/ttyS16
2025.05.21 22:32:16.689 1: CUL: Can't open /dev/ttyS16: Input/output error
2025.05.21 22:32:16.689 3: Probing CUL device /dev/ttyS17
2025.05.21 22:32:16.690 1: CUL: Can't open /dev/ttyS17: Input/output error
2025.05.21 22:32:16.690 3: Probing CUL device /dev/ttyS18
2025.05.21 22:32:16.690 1: CUL: Can't open /dev/ttyS18: Input/output error
2025.05.21 22:32:16.690 3: Probing CUL device /dev/ttyS19
2025.05.21 22:32:16.691 1: CUL: Can't open /dev/ttyS19: Input/output error
2025.05.21 22:32:16.691 3: Probing CUL device /dev/ttyS2
2025.05.21 22:32:16.691 1: CUL: Can't open /dev/ttyS2: Input/output error
2025.05.21 22:32:16.691 3: Probing CUL device /dev/ttyS20
2025.05.21 22:32:16.692 1: CUL: Can't open /dev/ttyS20: Input/output error
2025.05.21 22:32:16.692 3: Probing CUL device /dev/ttyS21
2025.05.21 22:32:16.692 1: CUL: Can't open /dev/ttyS21: Input/output error
2025.05.21 22:32:16.692 3: Probing CUL device /dev/ttyS22
2025.05.21 22:32:16.692 1: CUL: Can't open /dev/ttyS22: Input/output error
2025.05.21 22:32:16.693 3: Probing CUL device /dev/ttyS23
2025.05.21 22:32:16.693 1: CUL: Can't open /dev/ttyS23: Input/output error
2025.05.21 22:32:16.693 3: Probing CUL device /dev/ttyS24
2025.05.21 22:32:16.693 1: CUL: Can't open /dev/ttyS24: Input/output error
2025.05.21 22:32:16.694 3: Probing CUL device /dev/ttyS25
2025.05.21 22:32:16.694 1: CUL: Can't open /dev/ttyS25: Input/output error
2025.05.21 22:32:16.694 3: Probing CUL device /dev/ttyS26
2025.05.21 22:32:16.694 1: CUL: Can't open /dev/ttyS26: Input/output error
2025.05.21 22:32:16.695 3: Probing CUL device /dev/ttyS27
2025.05.21 22:32:16.695 1: CUL: Can't open /dev/ttyS27: Input/output error
2025.05.21 22:32:16.695 3: Probing CUL device /dev/ttyS28
2025.05.21 22:32:16.695 1: CUL: Can't open /dev/ttyS28: Input/output error
2025.05.21 22:32:16.696 3: Probing CUL device /dev/ttyS29
2025.05.21 22:32:16.696 1: CUL: Can't open /dev/ttyS29: Input/output error
2025.05.21 22:32:16.696 3: Probing CUL device /dev/ttyS3
2025.05.21 22:32:16.696 1: CUL: Can't open /dev/ttyS3: Input/output error
2025.05.21 22:32:16.697 3: Probing CUL device /dev/ttyS30
2025.05.21 22:32:16.697 1: CUL: Can't open /dev/ttyS30: Input/output error
2025.05.21 22:32:16.697 3: Probing CUL device /dev/ttyS31
2025.05.21 22:32:16.697 1: CUL: Can't open /dev/ttyS31: Input/output error
2025.05.21 22:32:16.698 3: Probing CUL device /dev/ttyS4
2025.05.21 22:32:16.698 1: CUL: Can't open /dev/ttyS4: Input/output error
2025.05.21 22:32:16.698 3: Probing CUL device /dev/ttyS5
2025.05.21 22:32:16.698 1: CUL: Can't open /dev/ttyS5: Input/output error
2025.05.21 22:32:16.698 3: Probing CUL device /dev/ttyS6
2025.05.21 22:32:16.699 1: CUL: Can't open /dev/ttyS6: Input/output error
2025.05.21 22:32:16.699 3: Probing CUL device /dev/ttyS7
2025.05.21 22:32:16.699 1: CUL: Can't open /dev/ttyS7: Input/output error
2025.05.21 22:32:16.699 3: Probing CUL device /dev/ttyS8
2025.05.21 22:32:16.700 1: CUL: Can't open /dev/ttyS8: Input/output error
2025.05.21 22:32:16.700 3: Probing CUL device /dev/ttyS9
2025.05.21 22:32:16.700 1: CUL: Can't open /dev/ttyS9: Input/output error
2025.05.21 22:32:16.708 1: usb create end
2025.05.21 22:32:16.735 0: Featurelevel: 6.4
2025.05.21 22:32:16.735 0: Server started with 344 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:1627284)
2025.05.21 22:32:16.741 3: myBroker: port 2000 opened
2025.05.21 22:32:17.058 3: telnetForBlockingFn_1747859537.0576: port 37073 opened
2025.05.21 22:32:17.258 1: HMLAN_Parse: HMUSB new condition ok
Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE strings$/ at ./FHEM/76_SolarForecast.pm line 6960.
ZitatSoll man denn mit dem aktuellen Modul einen Hybridwechselrichter als "PV-Wechselrichter" einrichten oder wie macht man das?
Ich würde so vorgehen, einen Standard PV-Wechselrichter und zusätzlich einen Batteriewechselrichter im Modul zu definieren. Das referenzierte Device ist dann identisch und die entsprechenden Schlüssel setzt du so dass die logische Funktion abgebildet wird, also pvIn / pvOut. pvOut müsste hier behelfsweise die Summe enthalten, die der WR in das Hausnetz + Batterie lädt. Bei dem Batteriewechselrichter die Schlüssel ac2dc / dc2ac für Richtung Hausnetz->Bat bzw. Bat->Hausnetz verwenden. Der "Teilfluß" WR -> Batterie (direkt) würde dann über den Inverterknoten -> Batteriewechselrichter -> Batterie laufen.
Mal sehen wann ich dazu komme Hybrid-WR zu implementieren ...
@roadghost,
hier der Fehler:
Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE strings$/ at ./FHEM/76_SolarForecast.pm line 6960.Merkwürdig nur, dass es ihn bei mir nicht gibt. Egal, schaue ich mir an.
@roadghost,
zeige mir mal bitte dein(e) Attribut(e) setupInverterDevXX.
Zitat von: DS_Starter am 22 Mai 2025, 20:03:26@roadghost,
zeige mir mal bitte dein(e) Attribut(e) setupInverterDevXX.
et voila:
setupInverterDev01
SH10rt_1_LAN pv=01_Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000 limit=70 [strings=South1,South2][icon=day[solar_icon]Night[solar_icon]]]
setupInverterDev02
Garage_PV_R pv=current_power-1:W etotal=total_yield-1:kWh capacity=580 limit=85 [strings=Garage_R][icon=day[solar_icon]Night[solar_icon]]]
setupInverterDev03
Garage_PV_L pv=current_power-1:W etotal=total_yield-1:kWh capacity=580 limit=85 [strings=Garage_L][icon=day[solar_icon]Night[solar_icon]]]
Ja da sind die Übeltäter:
Zitat[strings=Garage_R][icon=day[solar_icon]Night[solar_icon]]]
Die eckigen Klammern gehören da nicht hin und verursachen den Fehler.
Zur Erläuterung ... es hat sich in FHEM (vllt. generell) eingebürgert, dass optionale Parameter durch [...] gekennzeichnet werden. Dabei sind die Klammern nicht Teil der Syntax und werden bei der Eingabe weggelassen.
Für das erste Attr wäre es dann so anzugeben:
setupInverterDev01
SH10rt_1_LAN pv=01_Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000 limit=70 strings=South1,South2 icon=solar_icon:solar_icon
In dem Beispiel in der Online-Hife sieht man das.
Zitat von: DS_Starter am 22 Mai 2025, 20:22:55Ja da sind die Übeltäter:
Vielen Dank - habs angepasst, update angestupst, alles wieder gut.
Hallo zusammen,
die V 1.52.5 ist eingecheckt.
Was ist enthalten:
- die Sammelattribute werden auf das verbotene Vorhandensein von [...] in Schlüsseln geprüft und ggf. abgelehnt.
- bugfix in der Flußgrafik: Darstellung der Laufketten bei Unterschreiten von Schwellenwerten (Consumer)
- erweiterte Prüfung des Schlüssels cap im Attr setupBatteryDevXX. Eine Angabe einer Ganzzahl in
Verbindung mit ":Wh" oder ":kWh" führt zu einem Fehler. Eine Angabe von z.B. "1234Name:Wh" wäre erlaubt.
Es ist zwar in FHEM erlaubt, dass Readings aus reinen Ziffern bestehen, jedoch in der Praxis sehr
unwahrscheinlich. Da schon häufiger der Fehler "cap=1234:Wh" zu erhöhten Supportaufwand führte, habe ich mich jetzt
zu diesem Schritt entschlossen.
- in den Attr ctrlBatSocManagementXX gibt es einen neuen Schlüssel lcSlot. Damit kann man ein Zeitfenster
festlegen in dem die Batterie-Ladesteuerung arbeiten soll. Nun ist es möglich, zum Beispiel bis 10:00 die
Batterieladung mit der maximal möglichen Energie so voll wie möglich laden zu lassen und danach die
Ladelogik zu aktivieren.
Das Feature kann für jede vorhandene Batterie separat verwendet werden. So könnte man zum Beispiel eine
Batterie bis 12:00 so voll wie möglich und die anderen Batterien "netzdienlich" laden lassen.
lcSlot Es wird ein tägliches Zeitfenster festgelegt, in dem die Ladesteuerung des Moduls für diese
Batterie aktiv sein soll. Außerhalb des Zeitfensters wird die Batterieladung mit voller
Leistung freigegeben. Das SoC-Management der Batterie ist davon nicht betroffen.
Wert: <hh:mm>-<hh:mm>, default: ganztägig
LG,
Heiko
Zitat von: DS_Starter am 22 Mai 2025, 22:40:55- bugfix in der Flußgrafik: Darstellung der Laufketten bei Unterschreiten von Schwellenwerten (Consumer)
Funktioniert. Danke!
@Persuasiv,
hat die Anlage des Hybrid-WR so wie vorgeschlagen funktioniert?
Wenn ja, würde ich den Workaround in das Wiki übernehmen solange ich noch keinen Hybrid-WR nativ implementiert habe.
LG,
Heiko
Im contrib liegt ein Update der 1.52.5.
In der Batterieeinblendung (Mouse-Over) sieht man nun auch, ob das Lademanagement entsprechend der Einstellung "lcSlot" aktiviert ist oder nicht.
Hallo Zusammen,
vor ein paar Tagen hatte ich darauf hingewiesen das im "76_SMAInverter.pm"-Modul ein Bug bei den dortigen DC-Summenwerten der Strings besteht.
Inzwischen hab ich auch erkannt das dieser "alte" Summenwert eigentlich nur für die Hybrid-WR gedacht / gegolten hat.
Aber MadMax hat heute die normale Summe der DC-String für die normalen WR ebenfalls im Modul als weiteren Reading-Wert bereit gestellt.
Also:
Für alle die einen SMA-Wechselrichter betreiben und das Modul 76_SMAInverter als Datenquelle im SF-Modul nutzen gibt eine neue Version von MadMax mit dem Reading string_sum_pdc
(z.Z. manueller Download - die Tage sicherlich per normalem FHEM-update) 8)
Dieser Wert kann für die grafische Darstellung der aktuellen Summe aller Strings/Panels beim SMA-WR genutzt werden.
Beispiel:
SB40 limit=100 asynchron=0 etotal=etotal:kWh capacity=4000 pvIn=string_sum_pdc:kW pvOut=total_pac:kW strings=HausSE1,HausSE2,HausSWGruß
300P
Werde ich auch übernehmen, bei mir werkelt noch ein SMA aus alter Zeit.
Zitat von: DS_Starter am 22 Mai 2025, 22:40:55lcSlot Es wird ein tägliches Zeitfenster festgelegt, in dem die Ladesteuerung des Moduls für diese
Batterie aktiv sein soll. Außerhalb des Zeitfensters wird die Batterieladung mit voller
Leistung freigegeben. Das SoC-Management der Batterie ist davon nicht betroffen.
Wert: <hh:mm>-<hh:mm>, default: ganztägig
Hallo Heiko,
dazu hätte ich eine Frage: "wäre es nicht besser das durch ein 'true'-'false' (als Reading) ggfls optional gefolgt von einem Zeitfenster (z.B.: true:10:53) zu steuern?" dann wäre einfach auch eine Reihenfolge in der Batterieladung (wenn mehr als eine Bat. vorhanden ist) realisierbar? Wenn z.B. Bat1 voll dann Bat2 auf true oder einen Tag die dann die andere um eine gleichmäßige Belastung zu schaffen.
Ist nur eine Idee - ich arbeite derzeit mit solchen Prios.
Gruß Gerd
Kurze Frage (gerade aus dem Urlaub zurück, FHEM Update war notwendig), kommen diese Fehlermeldungen im Log:
2025.05.23 18:37:00 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14803.
2025.05.23 18:37:00 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14803.
2025.05.23 18:37:00 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14823.
2025.05.23 18:37:00 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14823.
2025.05.23 18:37:00 3: The string 'NW' is not a valid string name defined in attribute 'setupInverterStrings'.
2025.05.23 18:37:00 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/76_SolarForecast.pm line 9952.
2025.05.23 18:37:00 1: PERL WARNING: Use of uninitialized value $pvounit in pattern match (m//) at ./FHEM/76_SolarForecast.pm line 9953.
Hat sich die Definition des InverterStrings geändert? Danke Euch vorab.
Ja - momentan hat sich viel getan 😉 einige Parameter umbenannt und auch was hinzugekommen bei den diversen Versionen
Schau dir die neue Syntax an und passe entsprechend an - wahrscheinlich hast du mit Zeitverzug durch den Urlaub einige automatische Umstellungen ,,verpasst" 🤷
Hallo Gerd,
Zitat"wäre es nicht besser das durch ein 'true'-'false' (als Reading) ggfls optional gefolgt von einem Zeitfenster (z.B.: true:10:53) zu steuern?" dann wäre einfach auch eine Reihenfolge in der Batterieladung (wenn mehr als eine Bat. vorhanden ist) realisierbar?
Ob das besser wäre kommt ein bisschen darauf an welche Ziele man verfolgt. Ein bisschen weiter vorn war ein Nutzer der täglich bis zu einer bestimmten Zeit soviel in die Bat laden wollte wie es geht, danach sollte die Ladekontrolle greifen.
Momentan, wenn lcSlot nicht gesetzt ist, entspricht es im Prinzip deinem "false" sofern man darunter versteht dass das Lademanagement aktiv ist und eine Empfehlung per Reading steuert
mit welcher Leistung geladen werden sollte. Das ist der default.
Nun kann man mit lcSlot die Steuerung nur auf einen täglichen Slot eingrenzen, in dem die Batterie der Steuerung vom Modul unterliegt, aber sonst mit der vollen möglichen Leistung geladen wird.
Wir haben momentan keinen Modus der das Laden quasi logisch "unterbindet", sondern mit 0 nur einschränkt (Laden bei Überschreitung eines Einspeiselimits) bzw. 1 Laden mit voller Leistung was möglich ist. Die Zeit außerhalb des Slots würde einem "true" entsprechen. Das bedeutet "true" -> immer Laden mit max. möglicher Leistung, "false" -> Laden unter Modulsteuerung.
Um ein von dir skizziertes Szenario mit z.B. 3 Batterien umzusetzen, könnte man so vorgehen:
1. die Bat 1 soll mit voller Leistung geladen werden, die anderen nur bei weiterem Überschuß
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
Was passiert: die Bat1 unterliegt keiner Steuerung (nur von 23:00 bis 23:10 als Dummyzeit), das Reading Battery_ChargeRecommended_01 wird "1" gesetzt, d.h. die Bat01 soll mit voller Leistung geladen werden. Die anderen Batterien unterliegen der Steuerung -> Battery_ChargeRecommended_02 / 03 sind "0".
Ist das Ladeziel erreicht setzt man um die 2. Bat vollzuladen:
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=23:00-23:10
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=00:00-23:59
Die Bat01 / Bat03 unterliegen der Steuerung, d.h. Battery_ChargeRecommended_01 / 03 sind "0". Bat02 soll mit voller Leistung geladen werden -> Battery_ChargeRecommended_02 ist "1".
Ist auch die Bat02, würde man den Kelch an die Bat03 weiterreichen:
set ... attrKeyVal ctrlBatSocManagement01 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement02 lcSlot=00:00-23:59
set ... attrKeyVal ctrlBatSocManagement03 lcSlot=23:00-23:10
Der Vorteil des Setzens via attrKeyVal hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrund gecheckt wird und ggf. ein Fehler zurückgegeben wird den der User im Script auswerten kann und damit die Fehlermöglichkeiten minimiert werden.
Um deine Idee aufzugreifen, wäre ein weiterer Schlüssel "lcBool=<Device>:<Reading>" denkbar, welches ein logisches true / false liefern kann, um die Ladung unter Modulkontrolle (1) bzw. ohne Modulkontrolle, d.h. mit voller Leistung (0) zu realisieren.
Die Verwendung von lcSlot und lcBool kann ich durch Prüfung gegeneinander ausschließen, d.h. der User kann nur eine der Varianten gleichzeitig setzen.
Das "lc" steht in diesen Schlüssel für "load control".
LG,
Heiko
Zitat von: DS_Starter am 23 Mai 2025, 22:21:04Der Vorteil des Setzens via attrKeyVal hat den Vorteil, dass die Zeitfenster-Syntax (Anfangszeit kleiner Endezeit usw.) im Hintergrung gecheckt wird und ggf. ein Fehler zurückgegeben wird den der User im Script auswerten kann und damit die Fehlermöglichkeiten minimiert werden.
Um deine Idee aufzugreifen, wäre ein weiterer Schlüssel "lcBool=<Device>:<Reading>" denkbar, welches ein logisches true / false liefern kann, um die Ladung unter Modulkontrolle (1) bzw. ohne Modulkontrolle, d.h. mit voller Leistung (0) zu realisieren.
Die Verwendung von lcSlot und lcBool kann ich durch Prüfung gegeneinander ausschließen, d.h. der User kann nur eine der Varianten gleichzeitig setzen.
Das "lc" steht in diesen Schlüssel für "load control".
Guten Abend Heiko,
Zuerst einmal: Danke für deine schnelle und ausführliche Antwort!
Einen zusätzlichen Schlüssel braucht es m.M.n. dann nicht - die Idee mit 'set ... attrKeyVal' ist so OK und kann ja auch flexibel in jede Logik eingepasst werden
Gruß Gerd
Für Peter habe ich noch die Nullen zueinander ausgerichtet. ;)
Hallo zusammen,
Ich habe gestern ein Update auf die Version 1.52.4 von Version 1.52.3 gemacht.
Ich habe auch Version 1.52.5 probiert. Das gleiche.
Im Anschluss habe ich jetzt keinen BatteriesoC mehr und keinen Batterieforecast (siehe Anhang).
Interessanterweise wird die aktuelle Stunde angezeigt.
Hab alle Quellen‑Devices geprüft und keinen Fehler gefunden. Mehrfach fhem neu gestartet.
Jetzt bin ich am Ende mit meinen Ideen.
Weiterhin habe ich jetzt schon seit längerem, stört mich jedoch nicht, einen merkwürdigen Wert bei Con-Forecast. Der aktuelle Tag stimmt dann wieder. Das war in der Vergangenheit auch mal anders. Ich kann den Zeitpunkt aber nicht mehr bestimmen, an dem sich das Verhalten geändert hat.
Vielleicht habt ihr noch Ideen.
define 01_SolarForecast SolarForecast
attr 01_SolarForecast DbLogExclude .*
attr 01_SolarForecast DbLogInclude Today_PVdeviation,AllPVforecastsToEvent,LastHourPVforecast,LastHourPVreal
attr 01_SolarForecast alias SolarForecast
attr 01_SolarForecast comment update per "wget -qO fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
attr 01_SolarForecast consumer01 z_wav_stecker_luftentfeuchter type=charger power=600 switchdev=struc_entfeuchter mode=can icon=Ventilator_fett mintime=SunPath:60:-90 on=on off=off swstate=state:on:off pcurr=power:W etotal=energy_sum:kWh auto=automatic exconfc=1 locktime=600:2700 spignorecond=01_SolarForecast:nulleinspeisung:1 asynchron=1 interruptable=1
attr 01_SolarForecast consumer02 shelly_plug_s_wz_klima icon=sani_heating_heatpump type=noSchedule mode=can power=0 pcurr=power:W:10 exconfc=0 etotal=energy_total:kWh
attr 01_SolarForecast consumer03 MQTT2_zigbee_z_plug_keller_luftentfeuchter_alt icon=Ventilator_fett type=noSchedule mode=can power=0 pcurr=power:W exconfc=1 etotal=energy:kWh
attr 01_SolarForecast consumer04 MQTT2_zigbee_z_plug_oben_kuehlschrank icon=kuehlschrank_small type=noSchedule mode=can power=0 pcurr=power:W:10 exconfc=0 etotal=energy:kWh
attr 01_SolarForecast consumer05 z_wav_stecker_kuehschrank_keller icon=kuehlschrank_small type=noSchedule mode=can power=0 pcurr=power:W:10 exconfc=0 etotal=energy:kWh
attr 01_SolarForecast consumer06 MQTT2_zigbee_z_plug_spuelmaschine icon=scene_dishwasher type=noSchedule mode=can power=0 pcurr=power:W:10 exconfc=0 etotal=energy:kWh
attr 01_SolarForecast consumer07 MQTT2_plug_s_waschmaschine icon=scene_washing_machine type=noSchedule mode=can power=0 pcurr=relay_0_power:W:10 exconfc=0 etotal=relay_0_energy_total:Wh
attr 01_SolarForecast consumer08 MQTT2_zigbee_z_plug_keller_trockner icon=scene_clothes_dryer type=noSchedule mode=can power=0 pcurr=power:W:10 exconfc=0 etotal=energy:kWh
attr 01_SolarForecast consumer09 MQTT2_shelly1pm_heizung icon=sani_boiler_temp type=noSchedule mode=can power=0 pcurr=relay_0_power:W:10 exconfc=1 etotal=relay_0_energy_total:Wh
attr 01_SolarForecast consumer10 z_wav_stecker_backofen icon=scene_baking_oven type=noSchedule mode=can power=0 pcurr=power:W:10 exconfc=0 etotal=energy:kWh
attr 01_SolarForecast consumer11 MQTT_zigbee_z_strommess_keller icon=it_network type=noSchedule mode=can power=0 pcurr=z_strommess_keller_power_b:W exconfc=1 etotal=z_strommess_keller_energy_produced_b:kWh
attr 01_SolarForecast consumerControl adviceIcon=light_light_dim_100@gold detailLink=1 showLegend=text_bottom dummyIcon=status_comfort@#ff8c00
attr 01_SolarForecast ctrlConsRecommendReadings 01
attr 01_SolarForecast ctrlLanguage DE
attr 01_SolarForecast ctrlNextHoursSoCForecastReadings 00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23
attr 01_SolarForecast ctrlSpecialReadings BatPowerIn_Sum,BatPowerOut_Sum,conForecastTillNextSunrise,currentRunMtsConsumer_01,dayAfterTomorrowPVforecast,runTimeAvgDayConsumer_01,todayBatInSum,todayBatIn_01,todayBatIn_02,todayBatOutSum,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,todayConsumption,todayConsumptionForecast,todayConsumptionForecastDay,todayGridConsumption,todayGridFeedIn
attr 01_SolarForecast ctrlUserExitFn {\
if ((ReadingsNum("MQTT2_jk_bms_ble_multi","AVG_state_of_charge",0) > 80 && ReadingsNum("MQTT2_shelly1pm_solar2","relay_0_power",0) < 700 && ReadingsNum("z_wav_stecker_luftentfeuchter","automatic",0) == 1) ||\
(ReadingsNum("MQTT2_jk_bms_ble_multi","AVG_state_of_charge",0) > 80 && ReadingsNum("MQTT2_shelly1pm_solar2","relay_0_power",0) < 1300 && ReadingsNum("z_wav_stecker_luftentfeuchter","automatic",0) == 1 && ReadingsNum("$name","nulleinspeisung",0) == 1)) {\
fhem "setreading $name nulleinspeisung 1";;\
}\
else {\
fhem "setreading $name nulleinspeisung 0";;\
}\
}
attr 01_SolarForecast event-on-change-reading .*
attr 01_SolarForecast flowGraphicControl size=600 animate=1 showconsumer=1 showconsumerdummy=1 strokeconsumerdyncol=1 showconsumerpower=1 showconsumerremaintime=1 homenodedyncol=1
attr 01_SolarForecast graphicBeam5Content batsocCombi_02
attr 01_SolarForecast graphicBeam6Color 69FF87
attr 01_SolarForecast graphicBeam6Content batsocCombi_01
attr 01_SolarForecast graphicControl layoutType=double
attr 01_SolarForecast graphicHeaderOwnspec #\
Strompreis ;aWATTar ;ct:arbeitspreis@aWATTar\
:\
:\
:\
#\
Heute ;PV:Today_PVreal\
Heute ;Forecast ;PV:Today_PVforecast\
:\
:\
#\
Heute ;Con:special_todayConsumption\
Heute ;Forecast ;Con:special_todayConsumptionForecastDay\
Morgen ;Con:Tomorrow_ConsumptionForecast\
:\
:\
#\
Consumer ;Neuplanung:consumerNewPlanning:::\
Consumer ;Sofortstart:consumerImmediatePlanning:::\
attr 01_SolarForecast graphicHistoryHour 4
attr 01_SolarForecast graphicSelect swap
attr 01_SolarForecast graphicShowDiff top
attr 01_SolarForecast graphicWeatherColor 000000
attr 01_SolarForecast group 00 Energiebilanz
attr 01_SolarForecast plantControl batteryPreferredCharge=80 consForecastIdentWeekdays=1 cycleInterval=70 genPVdeviation=continuously
attr 01_SolarForecast room Energie
attr 01_SolarForecast setupBatteryDev01 MQTT2_jk_bms_ble_multi pin=176ah_charging_power:W pout=176ah_discharging_power:W charge=176ah_state_of_charge show=1 cap=8448:Wh asynchron=1 icon=measure_battery_100@grey:measure_battery_50@green:measure_battery_50@red:measure_battery_0@red
attr 01_SolarForecast setupBatteryDev02 MQTT2_jk_bms_ble_multi pin=280ah_charging_power:W pout=280ah_discharging_power:W charge=280ah_state_of_charge show=1 cap=13440:Wh asynchron=1 icon=measure_battery_100@grey:measure_battery_50@green:measure_battery_50@red:measure_battery_0@red
attr 01_SolarForecast setupInverterDev01 MQTT2_EPEver2MQTT pvOut=EP_1_LiveData_BATT_W:W capacity=3500 etotal=EP_1_StatsData_GEN_TOT:kWh strings=gross asynchron=1
attr 01_SolarForecast setupInverterDev02 MQTT2_EPEver2MQTT capacity=2500 pvOut=EP_2_LiveData_BATT_W:W etotal=EP_2_StatsData_GEN_TOT:kWh asynchron=1 strings=klein
attr 01_SolarForecast setupInverterStrings gross,klein
attr 01_SolarForecast setupMeterDev MQTT2_tzaehler gcon=sml_Leistung:W contotal=Bezug_total:kWh gfeedin=-gcon feedtotal=Einspeisung_total:kWh asynchron=1 conprice=0.35:€ feedprice=0:€
attr 01_SolarForecast setupRadiationAPI OpenMeteoDWDEnsemble-API
attr 01_SolarForecast setupStringAzimuth gross=S klein=S
attr 01_SolarForecast setupStringDeclination gross=35 klein=15
attr 01_SolarForecast setupStringPeak gross=3.5 klein=2.5
attr 01_SolarForecast setupWeatherDev1 OpenMeteoDWDEnsemble-API
attr 01_SolarForecast sortby 2
attr 01_SolarForecast stateFormat Current_PV
attr 01_SolarForecast verbose 0
# FUUID 62f00e06-f33f-638b-d558-edce0156a0cf493f
# FVERSION 76_SolarForecast.pm:v1.52.5-s29993/2025-05-23
# LCACHEFILE last write time: 08:00:03 File: ./FHEM/FhemUtils/AIraw_SolarForecast_01_SolarForecast
# MODE Automatic / Event-controlled - next planned Cycletime: 08:10:28
# MODEL OpenMeteoDWDEnsembleAPI
# NAME 01_SolarForecast
# NOTIFYDEV MQTT2_tzaehler,z_wav_stecker_luftentfeuchter,struc_entfeuchter,shelly_plug_s_wz_klima,MQTT2_zigbee_z_plug_keller_luftentfeuchter_alt,MQTT2_zigbee_z_plug_oben_kuehlschrank,z_wav_stecker_kuehschrank_keller,MQTT2_zigbee_z_plug_spuelmaschine,MQTT2_plug_s_waschmaschine,MQTT2_zigbee_z_plug_keller_trockner,MQTT2_shelly1pm_heizung,z_wav_stecker_backofen,MQTT_zigbee_z_strommess_keller,MQTT2_jk_bms_ble_multi,MQTT2_EPEver2MQTT
# NR 436
# NTFY_ORDER 50-01_SolarForecast
# STATE 1728 W
# TYPE SolarForecast
# WEATHERMODEL OpenMeteoDWDEnsembleAPI
# eventCount 585
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV 01_SolarForecast
# SPGROOM
# VERSION 1.52.5
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 47
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:1286284
# telnet telnetPort_127.0.0.1_49650
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name 01_SolarForecast
# tsnext 1748077927.33121
# Helper:
# DBLOG:
# LastHourPVforecast:
# logdb:
# TIME 1748066403.78796
# VALUE 1344
# logdb2:
# TIME 1748066403.79023
# VALUE 1344
# LastHourPVreal:
# logdb:
# TIME 1748066403.78796
# VALUE 1170
# logdb2:
# TIME 1748066403.79023
# VALUE 1170
# Today_PVdeviation:
# logdb:
# TIME 1748066974.4693
# VALUE 12.49
# logdb2:
# TIME 1748066974.47033
# VALUE 12.49
# OLDREADINGS:
# READINGS:
# 2025-05-23 06:05:27 Battery_ChargeRecommended_01 1
# 2025-05-23 06:05:27 Battery_ChargeRecommended_02 1
# 2025-05-23 06:05:27 Battery_NextHour00_SoCforecast_01 70.2 %
# 2025-05-23 06:05:27 Battery_NextHour00_SoCforecast_02 73.2 %
# 2025-05-23 06:05:27 Battery_NextHour01_SoCforecast_01 73.7 %
# 2025-05-23 06:05:27 Battery_NextHour01_SoCforecast_02 76.7 %
# 2025-05-23 06:05:27 Battery_NextHour02_SoCforecast_01 79.5 %
# 2025-05-23 06:05:27 Battery_NextHour02_SoCforecast_02 82.4 %
# 2025-05-23 06:05:27 Battery_NextHour03_SoCforecast_01 89.6 %
# 2025-05-23 06:05:27 Battery_NextHour03_SoCforecast_02 92.5 %
# 2025-05-23 06:05:27 Battery_NextHour04_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour04_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour05_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour05_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour06_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour06_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour07_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour07_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour08_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour08_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour09_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour09_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour10_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour10_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour11_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour11_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour12_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour12_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour13_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour13_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour14_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour14_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour15_SoCforecast_01 99.8 %
# 2025-05-23 06:05:27 Battery_NextHour15_SoCforecast_02 99.7 %
# 2025-05-23 06:05:27 Battery_NextHour16_SoCforecast_01 99.6 %
# 2025-05-23 06:05:27 Battery_NextHour16_SoCforecast_02 99.6 %
# 2025-05-23 06:05:27 Battery_NextHour17_SoCforecast_01 99.5 %
# 2025-05-23 06:05:27 Battery_NextHour17_SoCforecast_02 99.4 %
# 2025-05-23 06:05:27 Battery_NextHour18_SoCforecast_01 99.3 %
# 2025-05-23 06:05:27 Battery_NextHour18_SoCforecast_02 99.3 %
# 2025-05-23 06:05:27 Battery_NextHour19_SoCforecast_01 99.2 %
# 2025-05-23 06:05:27 Battery_NextHour19_SoCforecast_02 99.2 %
# 2025-05-23 06:05:27 Battery_NextHour20_SoCforecast_01 99.1 %
# 2025-05-23 06:05:27 Battery_NextHour20_SoCforecast_02 99.0 %
# 2025-05-23 06:05:27 Battery_NextHour21_SoCforecast_01 98.9 %
# 2025-05-23 06:05:27 Battery_NextHour21_SoCforecast_02 98.9 %
# 2025-05-23 06:05:27 Battery_NextHour22_SoCforecast_01 98.8 %
# 2025-05-23 06:05:27 Battery_NextHour22_SoCforecast_02 98.8 %
# 2025-05-23 06:05:27 Battery_NextHour23_SoCforecast_01 98.7 %
# 2025-05-23 06:05:27 Battery_NextHour23_SoCforecast_02 98.6 %
# 2025-05-24 08:09:52 Current_AutarkyRate 96 %
# 2025-05-24 08:09:52 Current_BatCharge_01 76 %
# 2025-05-24 08:09:52 Current_BatCharge_02 82 %
# 2025-05-24 08:09:52 Current_Consumption 301 W
# 2025-05-24 08:09:52 Current_GridConsumption 13 W
# 2025-05-24 08:09:52 Current_GridFeedIn 0 W
# 2025-05-24 08:09:52 Current_PV 1728 W
# 2025-05-24 08:09:52 Current_PowerBatIn_01 510 W
# 2025-05-24 08:09:52 Current_PowerBatIn_02 930 W
# 2025-05-24 08:09:52 Current_PowerBatOut_01 0 W
# 2025-05-24 08:09:52 Current_PowerBatOut_02 0 W
# 2025-05-24 08:09:52 Current_SelfConsumption 288 W
# 2025-05-24 08:09:52 Current_SelfConsumptionRate 17 %
# 2025-05-24 08:09:52 Current_Surplus 1427 W
# 2025-05-24 08:00:00 LastHourGridconsumptionReal 87 Wh
# 2025-05-24 08:00:00 LastHourPVforecast 1344 Wh
# 2025-05-24 08:00:00 LastHourPVreal 1170 Wh
# 2025-05-24 08:09:52 NextHours_Sum01_PVforecast 2677 Wh
# 2025-05-24 08:09:52 NextHours_Sum02_PVforecast 6944 Wh
# 2025-05-24 08:09:52 NextHours_Sum03_PVforecast 11155 Wh
# 2025-05-24 08:09:52 NextHours_Sum04_ConsumptionForecast 5912 Wh
# 2025-05-24 08:09:52 NextHours_Sum04_PVforecast 13846 Wh
# 2025-05-24 08:09:52 RestOfDayConsumptionForecast 13505 Wh
# 2025-05-24 08:09:52 RestOfDayPVforecast 34746 Wh
# 2025-05-24 01:00:00 Today_Hour01_BatIn_01 0 Wh
# 2025-05-24 01:00:00 Today_Hour01_BatIn_02 0 Wh
# 2025-05-24 01:00:00 Today_Hour01_BatOut_01 0 Wh
# 2025-05-24 01:00:00 Today_Hour01_BatOut_02 0 Wh
# 2025-05-24 01:00:00 Today_Hour01_GridConsumption 28 Wh
# 2025-05-24 01:00:00 Today_Hour01_GridFeedIn 1 Wh
# 2025-05-24 01:00:00 Today_Hour01_PVreal 0 Wh
# 2025-05-24 01:59:59 Today_Hour02_BatIn_01 0 Wh
# 2025-05-24 01:59:59 Today_Hour02_BatIn_02 0 Wh
# 2025-05-24 01:59:59 Today_Hour02_BatOut_01 0 Wh
# 2025-05-24 01:59:59 Today_Hour02_BatOut_02 0 Wh
# 2025-05-24 01:59:59 Today_Hour02_GridConsumption 26 Wh
# 2025-05-24 01:59:59 Today_Hour02_GridFeedIn 0 Wh
# 2025-05-24 01:59:59 Today_Hour02_PVreal 0 Wh
# 2025-05-24 02:59:58 Today_Hour03_BatIn_01 0 Wh
# 2025-05-24 02:59:58 Today_Hour03_BatIn_02 0 Wh
# 2025-05-24 02:59:58 Today_Hour03_BatOut_01 0 Wh
# 2025-05-24 02:59:58 Today_Hour03_BatOut_02 0 Wh
# 2025-05-24 02:59:58 Today_Hour03_GridConsumption 26 Wh
# 2025-05-24 02:59:58 Today_Hour03_GridFeedIn 0 Wh
# 2025-05-24 02:59:58 Today_Hour03_PVreal 0 Wh
# 2025-05-24 03:59:59 Today_Hour04_BatIn_01 0 Wh
# 2025-05-24 03:59:59 Today_Hour04_BatIn_02 0 Wh
# 2025-05-24 03:59:59 Today_Hour04_BatOut_01 0 Wh
# 2025-05-24 03:59:59 Today_Hour04_BatOut_02 0 Wh
# 2025-05-24 03:59:59 Today_Hour04_GridConsumption 28 Wh
# 2025-05-24 03:59:59 Today_Hour04_GridFeedIn 0 Wh
# 2025-05-24 03:59:59 Today_Hour04_PVreal 0 Wh
# 2025-05-24 04:59:59 Today_Hour05_BatIn_01 0 Wh
# 2025-05-24 04:59:59 Today_Hour05_BatIn_02 0 Wh
# 2025-05-24 04:59:59 Today_Hour05_BatOut_01 0 Wh
# 2025-05-24 04:59:59 Today_Hour05_BatOut_02 0 Wh
# 2025-05-24 04:59:59 Today_Hour05_GridConsumption 26 Wh
# 2025-05-24 04:59:59 Today_Hour05_GridFeedIn 0 Wh
# 2025-05-24 04:59:59 Today_Hour05_PVreal 0 Wh
# 2025-05-24 05:59:59 Today_Hour06_BatIn_01 0 Wh
# 2025-05-24 05:59:59 Today_Hour06_BatIn_02 0 Wh
# 2025-05-24 05:59:59 Today_Hour06_BatOut_01 0 Wh
# 2025-05-24 05:59:59 Today_Hour06_BatOut_02 0 Wh
# 2025-05-24 05:59:59 Today_Hour06_GridConsumption 26 Wh
# 2025-05-24 05:59:59 Today_Hour06_GridFeedIn 0 Wh
# 2025-05-24 05:59:59 Today_Hour06_PVforecast 48 Wh
# 2025-05-24 05:59:59 Today_Hour06_PVreal 30 Wh
# 2025-05-24 06:59:57 Today_Hour07_BatIn_01 0 Wh
# 2025-05-24 06:59:57 Today_Hour07_BatIn_02 0 Wh
# 2025-05-24 06:59:57 Today_Hour07_BatOut_01 0 Wh
# 2025-05-24 06:59:57 Today_Hour07_BatOut_02 0 Wh
# 2025-05-24 06:59:57 Today_Hour07_GridConsumption 80 Wh
# 2025-05-24 06:59:57 Today_Hour07_GridFeedIn 8 Wh
# 2025-05-24 06:59:57 Today_Hour07_PVforecast 326 Wh
# 2025-05-24 06:59:57 Today_Hour07_PVreal 390 Wh
# 2025-05-24 07:59:59 Today_Hour08_BatIn_01 0 Wh
# 2025-05-24 07:59:59 Today_Hour08_BatIn_02 0 Wh
# 2025-05-24 07:59:59 Today_Hour08_BatOut_01 0 Wh
# 2025-05-24 07:59:59 Today_Hour08_BatOut_02 0 Wh
# 2025-05-24 07:59:59 Today_Hour08_GridConsumption 87 Wh
# 2025-05-24 07:59:59 Today_Hour08_GridFeedIn 18 Wh
# 2025-05-24 07:59:59 Today_Hour08_PVforecast 1344 Wh
# 2025-05-24 07:59:59 Today_Hour08_PVreal 1170 Wh
# 2025-05-24 08:09:52 Today_Hour09_BatIn_01 0 Wh
# 2025-05-24 08:09:52 Today_Hour09_BatIn_02 0 Wh
# 2025-05-24 08:09:52 Today_Hour09_BatOut_01 0 Wh
# 2025-05-24 08:09:52 Today_Hour09_BatOut_02 0 Wh
# 2025-05-24 08:09:52 Today_Hour09_GridConsumption 16 Wh
# 2025-05-24 08:09:52 Today_Hour09_GridFeedIn 1 Wh
# 2025-05-24 08:09:52 Today_Hour09_PVforecast 2373 Wh
# 2025-05-24 08:09:52 Today_Hour09_PVreal 280 Wh
# 2025-05-24 08:09:52 Today_Hour10_PVforecast 4199 Wh
# 2025-05-24 08:09:52 Today_Hour11_PVforecast 4606 Wh
# 2025-05-24 08:09:52 Today_Hour12_PVforecast 2239 Wh
# 2025-05-24 08:09:52 Today_Hour13_PVforecast 4952 Wh
# 2025-05-24 08:09:52 Today_Hour14_PVforecast 5112 Wh
# 2025-05-24 08:09:52 Today_Hour15_PVforecast 3194 Wh
# 2025-05-24 08:09:52 Today_Hour16_PVforecast 3174 Wh
# 2025-05-24 08:09:52 Today_Hour17_PVforecast 1716 Wh
# 2025-05-24 08:09:52 Today_Hour18_PVforecast 1828 Wh
# 2025-05-24 08:09:52 Today_Hour19_PVforecast 1183 Wh
# 2025-05-24 08:09:52 Today_Hour20_PVforecast 388 Wh
# 2025-05-24 08:09:52 Today_Hour21_PVforecast 178 Wh
# 2025-05-24 08:09:52 Today_MaxPVforecast 5112 Wh
# 2025-05-24 08:09:52 Today_MaxPVforecastTime 2025-05-24 13:00:00
# 2025-05-24 08:09:52 Today_PVdeviation 12.49 %
# 2025-05-24 08:09:52 Today_PVforecast 36860 Wh
# 2025-05-24 08:09:52 Today_PVreal 1870 Wh
# 2025-05-24 08:09:52 Today_SunRise 05:04
# 2025-05-24 08:09:52 Today_SunSet 21:00
# 2025-05-24 08:09:52 Tomorrow_ConsumptionForecast -246960605687 Wh
# 2025-05-24 08:09:52 Tomorrow_PVforecast 1801 Wh
# 2025-05-24 08:09:52 Tomorrow_SunRise 05:03
# 2025-05-24 08:09:52 Tomorrow_SunSet 21:01
# 2025-05-24 08:09:52 consumer01 name='z_wav_stecker_luftentfeuchter' state='off' mode='can' planningstate='priority'
# 2025-05-24 08:09:52 consumer01_ConsumptionRecommended 1
# 2025-05-24 08:09:52 consumer01_currentPower 0 W
# 2025-05-24 08:09:52 consumer01_planned_start 24.05.2025 06:04:00
# 2025-05-24 08:09:52 consumer01_planned_stop 24.05.2025 19:30:00
# 2025-05-24 08:09:52 consumer02 name='shelly_plug_s_wz_klima' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer02_currentPower 5.58 W
# 2025-05-24 08:09:52 consumer03 name='MQTT2_zigbee_z_plug_keller_luftentfeuchter_alt' state='off' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer03_currentPower 0 W
# 2025-05-24 08:09:52 consumer04 name='MQTT2_zigbee_z_plug_oben_kuehlschrank' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer04_currentPower 0 W
# 2025-05-24 08:09:52 consumer05 name='z_wav_stecker_kuehschrank_keller' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer05_currentPower 4.4 W
# 2025-05-24 08:09:52 consumer06 name='MQTT2_zigbee_z_plug_spuelmaschine' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer06_currentPower 0 W
# 2025-05-24 08:09:52 consumer07 name='MQTT2_plug_s_waschmaschine' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer07_currentPower 0 W
# 2025-05-24 08:09:52 consumer08 name='MQTT2_zigbee_z_plug_keller_trockner' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer08_currentPower 0.1 W
# 2025-05-24 08:09:52 consumer09 name='MQTT2_shelly1pm_heizung' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer09_currentPower 9.46 W
# 2025-05-24 08:09:52 consumer10 name='z_wav_stecker_backofen' state='on' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer10_currentPower 2.5 W
# 2025-05-24 08:09:52 consumer11 name='MQTT_zigbee_z_strommess_keller' state='unknown' mode='can' planningstate='noSchedule'
# 2025-05-24 08:09:52 consumer11_currentPower 115.8 W
# 2025-05-24 08:09:18 nextCycletime 08:10:28
# 2025-05-24 08:01:43 nextRadiationAPICall nach 24.05.2025 08:16:43
# 2025-05-24 08:09:52 nulleinspeisung 0
# 2025-05-24 06:00:02 pvCorrectionFactor_06 0.40 (automatic - old factor: 0.33, Sun Alt range: 5, Cloud range: 00, Days in range: 2)
# 2025-05-24 07:00:00 pvCorrectionFactor_07 0.82 (automatic - old factor: 0.59, Sun Alt range: 10, Cloud range: 35, Days in range: 2)
# 2025-05-24 08:00:03 pvCorrectionFactor_08 0.92 (automatic - old factor: 0.99, Sun Alt range: 20, Cloud range: 55, Days in range: 2)
# 2025-05-24 08:09:52 pvCorrectionFactor_Auto on_complex
# 2025-05-24 08:09:52 special_BatPowerIn_Sum 1440 W
# 2025-05-24 08:09:52 special_BatPowerOut_Sum 0 W
# 2025-05-24 08:09:52 special_conForecastTillNextSunrise 14004 Wh
# 2025-05-24 08:09:52 special_currentRunMtsConsumer_01 0 min
# 2025-05-24 08:09:52 special_dayAfterTomorrowPVforecast 699 Wh
# 2025-05-24 08:09:52 special_runTimeAvgDayConsumer_01 491.65 min
# 2025-05-24 08:09:52 special_todayBatInSum 0.0 Wh
# 2025-05-24 08:09:52 special_todayBatIn_01 0.0 Wh
# 2025-05-24 08:09:52 special_todayBatIn_02 0.0 Wh
# 2025-05-24 08:09:52 special_todayBatOutSum 0.0 Wh
# 2025-05-24 08:09:52 special_todayBatOut_01 0.0 Wh
# 2025-05-24 08:09:52 special_todayBatOut_02 0.0 Wh
# 2025-05-24 08:09:52 special_todayConForecastTillSunset 12685 Wh
# 2025-05-24 08:09:52 special_todayConsumption 2165 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecastDay 14649 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_01 29 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_02 27 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_03 28 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_04 30 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_05 27 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_06 46 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_07 256 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_08 550 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_09 906 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_10 270 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_11 1951 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_12 2568 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_13 2208 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_14 1207 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_15 954 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_16 882 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_17 705 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_18 941 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_19 632 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_20 226 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_21 86 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_22 55 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_23 35 Wh
# 2025-05-24 08:09:52 special_todayConsumptionForecast_24 30 Wh
# 2025-05-24 08:09:52 special_todayGridConsumption 343 Wh
# 2025-05-24 08:09:52 special_todayGridFeedIn 29.0 Wh
# 2025-05-24 08:09:52 state running
#
setstate 01_SolarForecast 1728 W
setstate 01_SolarForecast 2023-12-03 17:49:33 .01_SolarForecast_consumerImmediatePlanning
setstate 01_SolarForecast 2023-12-03 17:49:33 .01_SolarForecast_consumerNewPlanning
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_ctrlDebu
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_graphicHistoryHour 4
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_graphicShowNight
setstate 01_SolarForecast 2025-02-01 07:50:46 .01_SolarForecast_graphicShowWeather
setstate 01_SolarForecast 2025-05-24 07:57:27 .associatedWith MQTT2_tzaehler z_wav_stecker_luftentfeuchter struc_entfeuchter shelly_plug_s_wz_klima MQTT2_zigbee_z_plug_keller_luftentfeuchter_alt MQTT2_zigbee_z_plug_oben_kuehlschrank z_wav_stecker_kuehschrank_keller MQTT2_zigbee_z_plug_spuelmaschine MQTT2_plug_s_waschmaschine MQTT2_zigbee_z_plug_keller_trockner MQTT2_shelly1pm_heizung z_wav_stecker_backofen MQTT_zigbee_z_strommess_keller MQTT2_jk_bms_ble_multi MQTT2_EPEver2MQTT
setstate 01_SolarForecast 2025-05-24 08:09:52 .lastupdateForecastValues 1748066992
setstate 01_SolarForecast 2025-05-24 08:09:52 .pvCorrectionFactor_Auto_Soll on_complex
setstate 01_SolarForecast 2025-05-24 01:00:02 .signaldone_01 done
setstate 01_SolarForecast 2025-05-24 02:00:02 .signaldone_02 done
setstate 01_SolarForecast 2025-05-24 03:00:01 .signaldone_03 done
setstate 01_SolarForecast 2025-05-24 04:00:02 .signaldone_04 done
setstate 01_SolarForecast 2025-05-24 05:00:01 .signaldone_05 done
setstate 01_SolarForecast 2025-05-24 06:00:02 .signaldone_06 done
setstate 01_SolarForecast 2025-05-24 07:00:00 .signaldone_07 done
setstate 01_SolarForecast 2025-05-24 08:00:03 .signaldone_08 done
setstate 01_SolarForecast 2025-05-24 00:00:01 .signaldone_24 done
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_ChargeRecommended_01 1
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_ChargeRecommended_02 1
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour00_SoCforecast_01 70.2 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour00_SoCforecast_02 73.2 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour01_SoCforecast_01 73.7 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour01_SoCforecast_02 76.7 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour02_SoCforecast_01 79.5 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour02_SoCforecast_02 82.4 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour03_SoCforecast_01 89.6 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour03_SoCforecast_02 92.5 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour04_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour04_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour05_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour05_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour06_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour06_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour07_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour07_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour08_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour08_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour09_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour09_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour10_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour10_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour11_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour11_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour12_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour12_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour13_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour13_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour14_SoCforecast_01 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour14_SoCforecast_02 100.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour15_SoCforecast_01 99.8 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour15_SoCforecast_02 99.7 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour16_SoCforecast_01 99.6 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour16_SoCforecast_02 99.6 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour17_SoCforecast_01 99.5 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour17_SoCforecast_02 99.4 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour18_SoCforecast_01 99.3 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour18_SoCforecast_02 99.3 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour19_SoCforecast_01 99.2 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour19_SoCforecast_02 99.2 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour20_SoCforecast_01 99.1 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour20_SoCforecast_02 99.0 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour21_SoCforecast_01 98.9 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour21_SoCforecast_02 98.9 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour22_SoCforecast_01 98.8 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour22_SoCforecast_02 98.8 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour23_SoCforecast_01 98.7 %
setstate 01_SolarForecast 2025-05-23 06:05:27 Battery_NextHour23_SoCforecast_02 98.6 %
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_AutarkyRate 96 %
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_BatCharge_01 76 %
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_BatCharge_02 82 %
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_Consumption 301 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_GridConsumption 13 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_GridFeedIn 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_PV 1728 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_PowerBatIn_01 510 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_PowerBatIn_02 930 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_PowerBatOut_01 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_PowerBatOut_02 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_SelfConsumption 288 W
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_SelfConsumptionRate 17 %
setstate 01_SolarForecast 2025-05-24 08:09:52 Current_Surplus 1427 W
setstate 01_SolarForecast 2025-05-24 08:00:00 LastHourGridconsumptionReal 87 Wh
setstate 01_SolarForecast 2025-05-24 08:00:00 LastHourPVforecast 1344 Wh
setstate 01_SolarForecast 2025-05-24 08:00:00 LastHourPVreal 1170 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 NextHours_Sum01_PVforecast 2677 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 NextHours_Sum02_PVforecast 6944 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 NextHours_Sum03_PVforecast 11155 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 NextHours_Sum04_ConsumptionForecast 5912 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 NextHours_Sum04_PVforecast 13846 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 RestOfDayConsumptionForecast 13505 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 RestOfDayPVforecast 34746 Wh
setstate 01_SolarForecast 2025-05-24 01:00:00 Today_Hour01_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 01:00:00 Today_Hour01_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 01:00:00 Today_Hour01_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 01:00:00 Today_Hour01_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 01:00:00 Today_Hour01_GridConsumption 28 Wh
setstate 01_SolarForecast 2025-05-24 01:00:00 Today_Hour01_GridFeedIn 1 Wh
setstate 01_SolarForecast 2025-05-24 01:00:00 Today_Hour01_PVreal 0 Wh
setstate 01_SolarForecast 2025-05-24 01:59:59 Today_Hour02_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 01:59:59 Today_Hour02_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 01:59:59 Today_Hour02_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 01:59:59 Today_Hour02_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 01:59:59 Today_Hour02_GridConsumption 26 Wh
setstate 01_SolarForecast 2025-05-24 01:59:59 Today_Hour02_GridFeedIn 0 Wh
setstate 01_SolarForecast 2025-05-24 01:59:59 Today_Hour02_PVreal 0 Wh
setstate 01_SolarForecast 2025-05-24 02:59:58 Today_Hour03_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 02:59:58 Today_Hour03_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 02:59:58 Today_Hour03_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 02:59:58 Today_Hour03_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 02:59:58 Today_Hour03_GridConsumption 26 Wh
setstate 01_SolarForecast 2025-05-24 02:59:58 Today_Hour03_GridFeedIn 0 Wh
setstate 01_SolarForecast 2025-05-24 02:59:58 Today_Hour03_PVreal 0 Wh
setstate 01_SolarForecast 2025-05-24 03:59:59 Today_Hour04_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 03:59:59 Today_Hour04_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 03:59:59 Today_Hour04_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 03:59:59 Today_Hour04_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 03:59:59 Today_Hour04_GridConsumption 28 Wh
setstate 01_SolarForecast 2025-05-24 03:59:59 Today_Hour04_GridFeedIn 0 Wh
setstate 01_SolarForecast 2025-05-24 03:59:59 Today_Hour04_PVreal 0 Wh
setstate 01_SolarForecast 2025-05-24 04:59:59 Today_Hour05_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 04:59:59 Today_Hour05_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 04:59:59 Today_Hour05_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 04:59:59 Today_Hour05_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 04:59:59 Today_Hour05_GridConsumption 26 Wh
setstate 01_SolarForecast 2025-05-24 04:59:59 Today_Hour05_GridFeedIn 0 Wh
setstate 01_SolarForecast 2025-05-24 04:59:59 Today_Hour05_PVreal 0 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_GridConsumption 26 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_GridFeedIn 0 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_PVforecast 48 Wh
setstate 01_SolarForecast 2025-05-24 05:59:59 Today_Hour06_PVreal 30 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_GridConsumption 80 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_GridFeedIn 8 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_PVforecast 326 Wh
setstate 01_SolarForecast 2025-05-24 06:59:57 Today_Hour07_PVreal 390 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_GridConsumption 87 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_GridFeedIn 18 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_PVforecast 1344 Wh
setstate 01_SolarForecast 2025-05-24 07:59:59 Today_Hour08_PVreal 1170 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_BatIn_01 0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_BatIn_02 0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_BatOut_01 0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_BatOut_02 0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_GridConsumption 16 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_GridFeedIn 1 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_PVforecast 2373 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour09_PVreal 280 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour10_PVforecast 4199 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour11_PVforecast 4606 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour12_PVforecast 2239 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour13_PVforecast 4952 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour14_PVforecast 5112 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour15_PVforecast 3194 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour16_PVforecast 3174 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour17_PVforecast 1716 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour18_PVforecast 1828 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour19_PVforecast 1183 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour20_PVforecast 388 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_Hour21_PVforecast 178 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_MaxPVforecast 5112 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_MaxPVforecastTime 2025-05-24 13:00:00
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_PVdeviation 12.49 %
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_PVforecast 36860 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_PVreal 1870 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_SunRise 05:04
setstate 01_SolarForecast 2025-05-24 08:09:52 Today_SunSet 21:00
setstate 01_SolarForecast 2025-05-24 08:09:52 Tomorrow_ConsumptionForecast -246960605687 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Tomorrow_PVforecast 1801 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 Tomorrow_SunRise 05:03
setstate 01_SolarForecast 2025-05-24 08:09:52 Tomorrow_SunSet 21:01
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer01 name='z_wav_stecker_luftentfeuchter' state='off' mode='can' planningstate='priority'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer01_ConsumptionRecommended 1
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer01_currentPower 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer01_planned_start 24.05.2025 06:04:00
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer01_planned_stop 24.05.2025 19:30:00
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer02 name='shelly_plug_s_wz_klima' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer02_currentPower 5.58 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer03 name='MQTT2_zigbee_z_plug_keller_luftentfeuchter_alt' state='off' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer03_currentPower 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer04 name='MQTT2_zigbee_z_plug_oben_kuehlschrank' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer04_currentPower 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer05 name='z_wav_stecker_kuehschrank_keller' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer05_currentPower 4.4 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer06 name='MQTT2_zigbee_z_plug_spuelmaschine' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer06_currentPower 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer07 name='MQTT2_plug_s_waschmaschine' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer07_currentPower 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer08 name='MQTT2_zigbee_z_plug_keller_trockner' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer08_currentPower 0.1 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer09 name='MQTT2_shelly1pm_heizung' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer09_currentPower 9.46 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer10 name='z_wav_stecker_backofen' state='on' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer10_currentPower 2.5 W
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer11 name='MQTT_zigbee_z_strommess_keller' state='unknown' mode='can' planningstate='noSchedule'
setstate 01_SolarForecast 2025-05-24 08:09:52 consumer11_currentPower 115.8 W
setstate 01_SolarForecast 2025-05-24 08:09:18 nextCycletime 08:10:28
setstate 01_SolarForecast 2025-05-24 08:01:43 nextRadiationAPICall nach 24.05.2025 08:16:43
setstate 01_SolarForecast 2025-05-24 08:09:52 nulleinspeisung 0
setstate 01_SolarForecast 2025-05-24 06:00:02 pvCorrectionFactor_06 0.40 (automatic - old factor: 0.33, Sun Alt range: 5, Cloud range: 00, Days in range: 2)
setstate 01_SolarForecast 2025-05-24 07:00:00 pvCorrectionFactor_07 0.82 (automatic - old factor: 0.59, Sun Alt range: 10, Cloud range: 35, Days in range: 2)
setstate 01_SolarForecast 2025-05-24 08:00:03 pvCorrectionFactor_08 0.92 (automatic - old factor: 0.99, Sun Alt range: 20, Cloud range: 55, Days in range: 2)
setstate 01_SolarForecast 2025-05-24 08:09:52 pvCorrectionFactor_Auto on_complex
setstate 01_SolarForecast 2025-05-24 08:09:52 special_BatPowerIn_Sum 1440 W
setstate 01_SolarForecast 2025-05-24 08:09:52 special_BatPowerOut_Sum 0 W
setstate 01_SolarForecast 2025-05-24 08:09:52 special_conForecastTillNextSunrise 14004 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_currentRunMtsConsumer_01 0 min
setstate 01_SolarForecast 2025-05-24 08:09:52 special_dayAfterTomorrowPVforecast 699 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_runTimeAvgDayConsumer_01 491.65 min
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayBatInSum 0.0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayBatIn_01 0.0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayBatIn_02 0.0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayBatOutSum 0.0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayBatOut_01 0.0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayBatOut_02 0.0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConForecastTillSunset 12685 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumption 2165 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecastDay 14649 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_01 29 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_02 27 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_03 28 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_04 30 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_05 27 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_06 46 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_07 256 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_08 550 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_09 906 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_10 270 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_11 1951 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_12 2568 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_13 2208 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_14 1207 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_15 954 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_16 882 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_17 705 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_18 941 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_19 632 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_20 226 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_21 86 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_22 55 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_23 35 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayConsumptionForecast_24 30 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayGridConsumption 343 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 special_todayGridFeedIn 29.0 Wh
setstate 01_SolarForecast 2025-05-24 08:09:52 state running
Viele Grüße
Heiko
Guten Morgen,
das Problem wird hier der Verbrauchswert sein.
Zur Kontrolle setze bitte ctrlDebug=batteryManagement und poste Ausgabe.
Edit: ich sehe gerade deine Readings sehen gut aus:
...
# 2025-05-23 06:05:27 Battery_NextHour00_SoCforecast_01 70.2 %
# 2025-05-23 06:05:27 Battery_NextHour00_SoCforecast_02 73.2 %
# 2025-05-23 06:05:27 Battery_NextHour01_SoCforecast_01 73.7 %
# 2025-05-23 06:05:27 Battery_NextHour01_SoCforecast_02 76.7 %
# 2025-05-23 06:05:27 Battery_NextHour02_SoCforecast_01 79.5 %
# 2025-05-23 06:05:27 Battery_NextHour02_SoCforecast_02 82.4 %
# 2025-05-23 06:05:27 Battery_NextHour03_SoCforecast_01 89.6 %
# 2025-05-23 06:05:27 Battery_NextHour03_SoCforecast_02 92.5 %
# 2025-05-23 06:05:27 Battery_NextHour04_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour04_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour05_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour05_SoCforecast_02 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour06_SoCforecast_01 100.0 %
# 2025-05-23 06:05:27 Battery_NextHour06_SoCforecast_02 100.0 %
...
Wirklich etwas merkwürdig.
Poste mal bitte eine Ausgabe von "get ... nextHours".
Bezüglich der Verbrauchsprognose ist vermutlich der Exclude eines Großverbrauchers die Ursache. Ein ctrlDebug=consumption_long sollte uns auf die Spur bringen.
LG,
Heiko
Danke für die schnelle Reaktion
Hier get .. next Hours
NextHour00 => starttime: 2025-05-24 09:00:00, day: 24, hourofday: 10, today: 1
pvapifc: 3716, pvaifc: -, pvfc: 3716, aihit: 0
confc: 270, confcEx: 270, weatherid: 2, wcc: 50, rr1c: 0.00, temp=9.80
rad1h: 2190, sunaz: 106, sunalt: 39, DoN: 1
rrange: 0.00, crange: 50, DaysInRange: 1, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour01 => starttime: 2025-05-24 10:00:00, day: 24, hourofday: 11, today: 1
pvapifc: 4649, pvaifc: -, pvfc: 4649, aihit: 0
confc: 1951, confcEx: 1951, weatherid: 1, wcc: 41, rr1c: 0.00, temp=11.40
rad1h: 2620, sunaz: 121, sunalt: 48, DoN: 1
rrange: 0.00, crange: 40, DaysInRange: 1, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour02 => starttime: 2025-05-24 11:00:00, day: 24, hourofday: 12, today: 1
pvapifc: 5235, pvaifc: -, pvfc: 5235, aihit: 0
confc: 2568, confcEx: 2568, weatherid: 1, wcc: 33, rr1c: 0.00, temp=12.80
rad1h: 2890, sunaz: 141, sunalt: 55, DoN: 1
rrange: 0.00, crange: 35, DaysInRange: 1, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour03 => starttime: 2025-05-24 12:00:00, day: 24, hourofday: 13, today: 1
pvapifc: 5155, pvaifc: -, pvfc: 5155, aihit: 0
confc: 2208, confcEx: 2208, weatherid: 1, wcc: 37, rr1c: 0.00, temp=13.90
rad1h: 3030, sunaz: 165, sunalt: 59, DoN: 1
rrange: 0.00, crange: 35, DaysInRange: 1, correff: 0.93/0.83
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour04 => starttime: 2025-05-24 13:00:00, day: 24, hourofday: 14, today: 1
pvapifc: 5664, pvaifc: -, pvfc: 5664, aihit: 0
confc: 1207, confcEx: 1207, weatherid: 1, wcc: 41, rr1c: 0.00, temp=14.80
rad1h: 3090, sunaz: 193, sunalt: 59, DoN: 1
rrange: 0.00, crange: 40, DaysInRange: 1, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour05 => starttime: 2025-05-24 14:00:00, day: 24, hourofday: 15, today: 1
pvapifc: 5478, pvaifc: -, pvfc: 5478, aihit: 0
confc: 954, confcEx: 954, weatherid: 1, wcc: 45, rr1c: 0.00, temp=15.50
rad1h: 3010, sunaz: 218, sunalt: 55, DoN: 1
rrange: 0.00, crange: 45, DaysInRange: 1, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour06 => starttime: 2025-05-24 15:00:00, day: 24, hourofday: 16, today: 1
pvapifc: 2637, pvaifc: -, pvfc: 2637, aihit: 0
confc: 882, confcEx: 882, weatherid: 1, wcc: 35, rr1c: 0.00, temp=16.00
rad1h: 2740, sunaz: 238, sunalt: 48, DoN: 1
rrange: 0.00, crange: 35, DaysInRange: 1, correff: 0.54/0.14
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour07 => starttime: 2025-05-24 16:00:00, day: 24, hourofday: 17, today: 1
pvapifc: 3938, pvaifc: -, pvfc: 3938, aihit: 0
confc: 705, confcEx: 705, weatherid: 1, wcc: 25, rr1c: 0.00, temp=16.40
rad1h: 2330, sunaz: 253, sunalt: 40, DoN: 1
rrange: 0.00, crange: 25, DaysInRange: 1, correff: 0.99/0.98
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour08 => starttime: 2025-05-24 17:00:00, day: 24, hourofday: 18, today: 1
pvapifc: 1825, pvaifc: -, pvfc: 1825, aihit: 0
confc: 941, confcEx: 941, weatherid: 0, wcc: 0, rr1c: 0.00, temp=16.30
rad1h: 1810, sunaz: 266, sunalt: 30, DoN: 1
rrange: 0.00, crange: 00, DaysInRange: 5, correff: 0.64/0.44
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour09 => starttime: 2025-05-24 18:00:00, day: 24, hourofday: 19, today: 1
pvapifc: 1183, pvaifc: -, pvfc: 1183, aihit: 0
confc: 632, confcEx: 632, weatherid: 0, wcc: 0, rr1c: 0.00, temp=15.60
rad1h: 1170, sunaz: 278, sunalt: 21, DoN: 1
rrange: 0.00, crange: 00, DaysInRange: 4, correff: 0.74/0.65
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour10 => starttime: 2025-05-24 19:00:00, day: 24, hourofday: 20, today: 1
pvapifc: 388, pvaifc: -, pvfc: 388, aihit: 0
confc: 226, confcEx: 226, weatherid: 0, wcc: 0, rr1c: 0.00, temp=14.40
rad1h: 500, sunaz: 289, sunalt: 12, DoN: 1
rrange: 0.00, crange: 00, DaysInRange: 7, correff: 0.68/0.53
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour11 => starttime: 2025-05-24 20:00:00, day: 24, hourofday: 21, today: 1
pvapifc: 178, pvaifc: -, pvfc: 178, aihit: 0
confc: 86, confcEx: 86, weatherid: 0, wcc: 0, rr1c: 0.00, temp=13.10
rad1h: 80, sunaz: 300, sunalt: 4, DoN: 1
rrange: 0.00, crange: 00, DaysInRange: 3, correff: 1.50/0.05
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour12 => starttime: 2025-05-24 21:00:00, day: 24, hourofday: 22, today: 1
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 55, confcEx: 55, weatherid: 0, wcc: 0, rr1c: 0.00, temp=11.80
rad1h: 0, sunaz: 312, sunalt: -4, DoN: 1
rrange: 0.00, crange: 00, DaysInRange: 3, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour13 => starttime: 2025-05-24 22:00:00, day: 24, hourofday: 23, today: 1
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 35, confcEx: 35, weatherid: 101, wcc: 20, rr1c: 0.00, temp=10.40
rad1h: 0, sunaz: 324, sunalt: -11, DoN: 0
rrange: 0.00, crange: 20, DaysInRange: 3, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour14 => starttime: 2025-05-24 23:00:00, day: 24, hourofday: 24, today: 1
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 30, confcEx: 30, weatherid: 101, wcc: 29, rr1c: 0.00, temp=9.40
rad1h: 0, sunaz: 338, sunalt: -15, DoN: 0
rrange: 0.00, crange: 30, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour15 => starttime: 2025-05-25 00:00:00, day: 25, hourofday: 01, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 28, confcEx: 28, weatherid: 102, wcc: 52, rr1c: 0.00, temp=8.90
rad1h: 0, sunaz: 352, sunalt: -18, DoN: 0
rrange: 0.00, crange: 50, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour16 => starttime: 2025-05-25 01:00:00, day: 25, hourofday: 02, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 26, confcEx: 26, weatherid: 102, wcc: 74, rr1c: 0.00, temp=8.80
rad1h: 0, sunaz: 7, sunalt: -18, DoN: 0
rrange: 0.00, crange: 75, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour17 => starttime: 2025-05-25 02:00:00, day: 25, hourofday: 03, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 28, confcEx: 28, weatherid: 103, wcc: 97, rr1c: 0.00, temp=8.60
rad1h: 0, sunaz: 21, sunalt: -15, DoN: 0
rrange: 0.00, crange: 95, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour18 => starttime: 2025-05-25 03:00:00, day: 25, hourofday: 04, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 29, confcEx: 29, weatherid: 103, wcc: 98, rr1c: 0.00, temp=8.40
rad1h: 0, sunaz: 35, sunalt: -11, DoN: 0
rrange: 0.00, crange: 100, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour19 => starttime: 2025-05-25 04:00:00, day: 25, hourofday: 05, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 26, confcEx: 26, weatherid: 103, wcc: 99, rr1c: 0.00, temp=8.10
rad1h: 0, sunaz: 48, sunalt: -5, DoN: 0
rrange: 0.00, crange: 100, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour20 => starttime: 2025-05-25 05:00:00, day: 25, hourofday: 06, today: 0
pvapifc: 256, pvaifc: -, pvfc: 256, aihit: 0
confc: 50, confcEx: 50, weatherid: 103, wcc: 100, rr1c: 0.00, temp=8.30
rad1h: 60, sunaz: 59, sunalt: 3, DoN: 0
rrange: 0.00, crange: 100, DaysInRange: 2, correff: 2.64/0.38
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour21 => starttime: 2025-05-25 06:00:00, day: 25, hourofday: 07, today: 0
pvapifc: 428, pvaifc: -, pvfc: 428, aihit: 0
confc: 262, confcEx: 262, weatherid: 3, wcc: 100, rr1c: 0.00, temp=9.30
rad1h: 230, sunaz: 71, sunalt: 12, DoN: 1
rrange: 0.00, crange: 100, DaysInRange: 3, correff: 1.26/0.35
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour22 => starttime: 2025-05-25 07:00:00, day: 25, hourofday: 08, today: 0
pvapifc: 491, pvaifc: -, pvfc: 491, aihit: 0
confc: 600, confcEx: 600, weatherid: 3, wcc: 100, rr1c: 0.00, temp=10.70
rad1h: 320, sunaz: 82, sunalt: 21, DoN: 1
rrange: 0.00, crange: 100, DaysInRange: 3, correff: 1.00/1.00
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour23 => starttime: 2025-05-25 08:00:00, day: 25, hourofday: 09, today: 0
pvapifc: 246, pvaifc: -, pvfc: 246, aihit: 0
confc: 1001, confcEx: 1001, weatherid: 3, wcc: 100, rr1c: 0.20, temp=11.50
rad1h: 260, sunaz: 93, sunalt: 30, DoN: 1
rrange: 0.20, crange: 100, DaysInRange: 3, correff: 0.60/0.32
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour24 => starttime: 2025-05-25 09:00:00, day: 25, hourofday: 10, today: 0
pvapifc: 112, pvaifc: -, pvfc: 112, aihit: 0
confc: 270, confcEx: 270, weatherid: 51, wcc: 100, rr1c: 0.20, temp=11.10
rad1h: 150, sunaz: 106, sunalt: 39, DoN: 1
rrange: 0.20, crange: 100, DaysInRange: 3, correff: 0.48/0.00
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour25 => starttime: 2025-05-25 10:00:00, day: 25, hourofday: 11, today: 0
pvapifc: 89, pvaifc: -, pvfc: 89, aihit: 0
confc: 1951, confcEx: 1951, weatherid: 51, wcc: 100, rr1c: 0.20, temp=10.10
rad1h: 100, sunaz: 121, sunalt: 48, DoN: 1
rrange: 0.20, crange: 100, DaysInRange: 2, correff: 0.54/0.16
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour26 => starttime: 2025-05-25 11:00:00, day: 25, hourofday: 12, today: 0
pvapifc: 98, pvaifc: -, pvfc: 98, aihit: 0
confc: 2568, confcEx: 2568, weatherid: 51, wcc: 100, rr1c: 0.40, temp=9.50
rad1h: 120, sunaz: 140, sunalt: 55, DoN: 1
rrange: 0.40, crange: 100, DaysInRange: 4, correff: 0.51/0.04
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour27 => starttime: 2025-05-25 12:00:00, day: 25, hourofday: 13, today: 0
pvapifc: 193, pvaifc: -, pvfc: 193, aihit: 0
confc: 2208, confcEx: 2208, weatherid: 51, wcc: 100, rr1c: 0.40, temp=9.60
rad1h: 140, sunaz: 165, sunalt: 59, DoN: 1
rrange: 0.40, crange: 100, DaysInRange: 3, correff: 0.87/0.86
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour28 => starttime: 2025-05-25 13:00:00, day: 25, hourofday: 14, today: 0
pvapifc: 119, pvaifc: -, pvfc: 119, aihit: 0
confc: 1207, confcEx: 1207, weatherid: 51, wcc: 100, rr1c: 0.40, temp=9.90
rad1h: 130, sunaz: 193, sunalt: 60, DoN: 1
rrange: 0.40, crange: 100, DaysInRange: 3, correff: 0.60/0.32
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour29 => starttime: 2025-05-25 14:00:00, day: 25, hourofday: 15, today: 0
pvapifc: 136, pvaifc: -, pvfc: 136, aihit: 0
confc: 954, confcEx: 954, weatherid: 51, wcc: 100, rr1c: 0.60, temp=10.30
rad1h: 110, sunaz: 218, sunalt: 56, DoN: 1
rrange: 0.60, crange: 100, DaysInRange: 4, correff: 0.77/0.70
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour30 => starttime: 2025-05-25 15:00:00, day: 25, hourofday: 16, today: 0
pvapifc: 147, pvaifc: -, pvfc: 147, aihit: 0
confc: 882, confcEx: 882, weatherid: 53, wcc: 100, rr1c: 0.60, temp=10.90
rad1h: 110, sunaz: 238, sunalt: 48, DoN: 1
rrange: 0.60, crange: 100, DaysInRange: 1, correff: 0.86/0.84
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour31 => starttime: 2025-05-25 16:00:00, day: 25, hourofday: 17, today: 0
pvapifc: 96, pvaifc: -, pvfc: 96, aihit: 0
confc: 705, confcEx: 705, weatherid: 53, wcc: 100, rr1c: 0.60, temp=11.50
rad1h: 120, sunaz: 253, sunalt: 40, DoN: 1
rrange: 0.60, crange: 100, DaysInRange: 3, correff: 0.51/0.04
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour32 => starttime: 2025-05-25 17:00:00, day: 25, hourofday: 18, today: 0
pvapifc: 125, pvaifc: -, pvfc: 125, aihit: 0
confc: 941, confcEx: 941, weatherid: 53, wcc: 100, rr1c: 0.10, temp=12.00
rad1h: 130, sunaz: 266, sunalt: 31, DoN: 1
rrange: 0.10, crange: 100, DaysInRange: 4, correff: 0.63/0.41
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour33 => starttime: 2025-05-25 18:00:00, day: 25, hourofday: 19, today: 0
pvapifc: 98, pvaifc: -, pvfc: 98, aihit: 0
confc: 632, confcEx: 632, weatherid: 51, wcc: 99, rr1c: 0.10, temp=12.40
rad1h: 120, sunaz: 278, sunalt: 21, DoN: 1
rrange: 0.10, crange: 100, DaysInRange: 5, correff: 0.54/0.14
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour34 => starttime: 2025-05-25 19:00:00, day: 25, hourofday: 20, today: 0
pvapifc: 105, pvaifc: -, pvfc: 105, aihit: 0
confc: 226, confcEx: 226, weatherid: 51, wcc: 97, rr1c: 0.10, temp=12.60
rad1h: 90, sunaz: 289, sunalt: 12, DoN: 1
rrange: 0.10, crange: 95, DaysInRange: 1, correff: 0.77/0.71
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour35 => starttime: 2025-05-25 20:00:00, day: 25, hourofday: 21, today: 0
pvapifc: 18, pvaifc: -, pvfc: 18, aihit: 0
confc: 86, confcEx: 86, weatherid: 51, wcc: 96, rr1c: 0.00, temp=12.60
rad1h: 30, sunaz: 300, sunalt: 4, DoN: 1
rrange: 0.00, crange: 95, DaysInRange: 1, correff: 0.34/0.00
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour36 => starttime: 2025-05-25 21:00:00, day: 25, hourofday: 22, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 55, confcEx: 55, weatherid: 3, wcc: 81, rr1c: 0.00, temp=12.10
rad1h: 0, sunaz: 312, sunalt: -4, DoN: 1
rrange: 0.00, crange: 80, DaysInRange: 1, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour37 => starttime: 2025-05-25 22:00:00, day: 25, hourofday: 23, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 35, confcEx: 35, weatherid: 102, wcc: 67, rr1c: 0.00, temp=11.30
rad1h: 0, sunaz: 324, sunalt: -10, DoN: 0
rrange: 0.00, crange: 65, DaysInRange: 2, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
NextHour38 => starttime: 2025-05-25 23:00:00, day: 25, hourofday: 24, today: 0
pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
confc: 30, confcEx: 30, weatherid: 102, wcc: 52, rr1c: 0.10, temp=10.70
rad1h: 0, sunaz: 338, sunalt: -15, DoN: 0
rrange: 0.10, crange: 50, DaysInRange: -, correff: 1.00/-
soc01: -, soc02: -, soc03: -, socprogwhsum: -
rcdchargebat01: -, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: -, lcintimebat02: -, lcintimebat03: -
Ja, in allen Datensätzen der kommenden Stunden ist soc01: -, d.h. dann kann nichts angezeigt werden.
Frage ist wieso. Das ctrlDebug=batteryManagement sollte etwas bringen.
Die Balkengrafik zeigt die prognostizierte und die tatsächliche Stromproduktion an. Kann man in die Vergangenheit scrollen?
So ich habe verbose 5 und attr 01_SolarForecast ctrlDebug batteryManagement,consumption_long
gesetzt.
Das steht jetzt im log.
ZitatDie Balkengrafik zeigt die prognostizierte und die tatsächliche Stromproduktion an. Kann man in die Vergangenheit scrollen?
Falls die Frage an mich gerichtet ist ... ja du kannst bedingt historische Stunden anzeigen -> Attr
graphicHistoryHour
@tatu123,
jetzt wird das Problem sichtbar:
2025.05.24 09:26:40 4: 01_SolarForecast DEBUG> current hour of day: 10
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> Bat XX Charge Rcmd - Inverter 'MQTT2_EPEver2MQTT' cap: 3500 W, Power limit: 100 % -> Pmax eff: 3500 W
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> Bat XX Charge Rcmd - Inverter 'MQTT2_EPEver2MQTT' cap: 2500 W, Power limit: 100 % -> Pmax eff: 2500 W
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 6000 W
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> WARNING - The requirements for dynamic battery charge recommendation are not met. Exit.
Ich sehe jetzt auch den Fehler -> die Angabe cap=13440:Wh in den setupBatteryDev02 Attr ist so falsch, nur cap=13440 ohne Einheit setzen, sonst wird ein angegebenes Reading vermutet. Für setupBatteryDev01 gilt es entsprechend.
In der Flussgrafik werden immer mal wieder falsche Werte angezeigt. 5 Minuten später passt es aber wieder. Woran liegt das? Wenn es falsch eingerichtet ist, dann müsste es doch immer falsch sein?!
ooohhh man. Ich bin so Blind. Tausendmal geprüft.
Wenn man die Onlinehilfe RICHTIG lesen könnte würde so was nicht passieren. :o 8)
Danke und sorry
Heiko
ZitatIn der Flussgrafik werden immer mal wieder falsche Werte angezeigt. 5 Minuten später passt es aber wieder. Woran liegt das? Wenn es falsch eingerichtet ist, dann müsste es doch immer falsch sein?!
Die vielen Devices in FHEM liefern ihre Werte nicht synchron. So kann der Interter hohe Enegrieerzeugung liefern und der Meter eine hohe Einspeisung -> alles passt. Ein paar Sekunden später liefert der Inverter nur die Hälfte Erzeugung, der Meter weiterhin eine hohe Einspeisung weil seine Aktualisierung noch nicht passiert ist -> passt nicht mehr!
Man kann versuchen mit asynchron und falls möglich die einzelnen FHEM Devices zu synchronisieren, aber prinzipiell müssen wir mit der Thematik leben. Das zeigt sich insbesondere bei dynamisch schwankenden Leistungen.
Bei meinem Pärchen SMAEM (Meter) und SMAInverter habe ich es so gelöst:
SMAEM auf interval 30 gestellt -> ein Notify triggert die Datenholung bei Inverter ->
SMA_Energymeter:Saldo_Wirkleistung:.* {
fhem "get STP_5000 data";
} -> der Inverter ist in SF auf asynchron=1 gestellt, d.h. wenn er neue Daten hat holt SF sie gleich ab. Im SMAInverter Device selbst ist mode auf "manual" eingestellt.
Dadurch habe ich eine Chain gebaut die zumindest für dieses Pärchen Synchronität herstellt.
LG,
Heiko
@tatu123,
wegen deiner Verbrauchsprognose...
der consumer01 hat einen hohen Verbrauch der großen Einfluß hat:
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 11 - 21474837070.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 12 - 21474837010.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 13 - 21474836990.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 14 - 42949673520.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 15 - 21474836940.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 16 - 42949673460.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 17 - 42949673600.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 18 - 21474836850.00 Wh
2025.05.24 09:26:40 1: 01_SolarForecast DEBUG> consumer '01' register for exclude day 10, hod: 19 - 42949673560.00 Wh
Du nutzt plantControl->consForecastIdentWeekdays=1 was gut ist. Ich würde zusätzlich plantControl->consForecastLastDays=4 setzen, was dann die letzten 4 Wochen des gleichen Wochentages berücksichtigen würde. Eventuell auch exconfc=2 testen. Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_die_Verbrauchsprognose_erstellt?)
Probiers mal damit. Die Prognose unter Einbeziehung von Verbrauchern hoher Leistung, die obendrein noch unregelmäßig laufen, ist schwierig. Ich bemühe mich dafür ein neuronales Netz zu entwickeln und bin auch schon ein ganzes Stück gekommen. Die Implementierung braucht Zeit, damit sieht es gerade nicht so gut aus. ;)
LG,
Heiko
Hab jetzt endlich eine Möglichkeit gefunden, pvIn/pvOut beim Fronius SymoGEN24 korrekt abzugreifen und komme auf Wandlungsverluste von 2-5 %
Sag ich doch.
LG
pah
Interessante Engergieflüsse ;D
Zitat von: Univega06 am 24 Mai 2025, 21:57:04Die Prognose unter Einbeziehung von Verbrauchern hoher Leistung, die obendrein noch unregelmäßig laufen, ist schwierig. Ich bemühe mich dafür ein neuronales Netz zu entwickeln und bin auch schon ein ganzes Stück gekommen.
Zu dem Problem habe ich mehrere Abschlussarbeiten anfertigen lassen. Ergebnis war immer mies - weil die wahrscheinlichste Prognose immer ist, dass das Teil nicht läuft.
LG
pah
@pah,
ZitatZu dem Problem habe ich mehrere Abschlussarbeiten anfertigen lassen.
Gibt es die Möglichkeit, solche Arbeiten online einzusehen?
Könnte evtl. Arbeit und Zeit sparen.
LG,
Heiko
Kann man die Energieflussgrafik verstecken bzw. deaktivieren, ohne die Definitionen (z. B. setupBatteryDev01) zu verändern?
ZitatKann man die Energieflussgrafik verstecken bzw. deaktivieren, ohne die Definitionen (z. B. setupBatteryDev01) zu verändern?
Ja, Attr graphicSelect. Siehe auch Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#5_-_Die_Energieflu%C3%9Fgrafik_(Flow_Graphic)).
@all,
die V 1.52.5 ist eingecheckt und morgen früh im Update enthalten. Der Überblick des Inhalts findet ihr in #3002.
LG,
Heiko
Hallo Heiko,
bei solchem Wetter (wie dem heutige Wetter) müllen mir meine consumer das Logfile bei verbose 2 mit on/off-Meldungen etwas zu.
2025.05.27 10:11:37 2: Forecast - Consumer '_Waschmaschine' switched on
2025.05.27 10:11:37 2: Forecast - Consumer '_WP_Heizstab_WW' switched on
2025.05.27 10:11:37 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on" (Automatic = 1)
2025.05.27 10:11:37 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on" (Automatic = 1)
2025.05.27 10:16:40 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 10:16:40 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 10:18:55 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 10:18:55 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 10:21:41 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 10:21:41 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 10:23:56 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 10:23:56 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.27 10:26:56 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 10:26:56 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 10:29:11 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 10:29:11 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 10:32:11 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 10:32:11 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 10:34:26 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 10:34:26 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.27 10:37:26 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 10:37:26 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 10:39:41 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 10:39:41 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 10:42:41 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 10:42:41 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 10:49:26 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 10:49:26 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 10:54:41 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 10:54:41 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 10:59:11 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 10:59:11 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.27 10:59:49 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 10:59:49 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 11:04:56 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 11:04:56 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 11:10:11 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 11:10:11 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 11:10:11 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 11:10:11 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 11:15:26 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 11:15:26 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 11:22:28 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 11:22:28 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.27 11:22:58 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 11:22:58 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 11:28:13 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 11:28:13 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 11:33:28 2: Forecast - Consumer '_Waschmaschine' switched off (interrupted)
2025.05.27 11:33:28 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: surplus shortage (Automatic = 1)
2025.05.27 11:38:15 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 11:38:16 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 11:38:46 2: Forecast - Consumer '_Waschmaschine' switched on (continued)
2025.05.27 11:38:46 2: Forecast - switching Consumer '_Waschmaschine' to 'on', command: "set FBDECT_fbahahttp_11657_0127183 on", cause: existing surplus
2025.05.27 11:44:17 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 11:44:17 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.27 12:11:37 2: Forecast - switching Consumer '_Waschmaschine' to 'off', command: "set FBDECT_fbahahttp_11657_0127183 off", cause: planned switch-off time reached/exceeded (Automatic = 1)
2025.05.27 12:11:38 2: Forecast - Consumer '_Waschmaschine' switched off
2025.05.27 12:53:11 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 12:53:12 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 13:06:21 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 13:06:21 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.27 13:14:37 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 13:14:37 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 13:39:09 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 13:39:09 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.27 13:58:26 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.27 13:58:26 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.27 14:03:41 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.27 14:03:41 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
FBDECT_fbahahttp_E8_DF_70_07_42_0B
type=heater
power=2170
mode=can
icon=sani_buffer_electric_heater_side@orange
mintime=SunPath
on=on
off=off
asynchron=1
notbefore=08:00
notafter=19:00
locktime=300:300
pcurr=power:W
etotal=energy:Wh
surpmeth=10
interruptable=1
swstate=state:.*on.*:.*off.*
Deshalb die Frage:
Könnte das Logging dieser gesendeten Befehle vom consumerXX nicht auf auf Level 3 gesetzt werden?
Wer denn da genauer was wissen will, um nachzuvollziehen ob oder ob nicht, kann den Level doch auf "verbose 3" setzen.
Es sind ja nun nicht so "wichtige" Alarme/Ereignisse - die allermeisten anderen Module "verschweigen" das Schalten von Geräten ja auch meist bei verbose 2.
verbose
Set the verbosity level. Possible values:
0 - server start/stop
1 - error messages or unknown packets
2 - major events/alarms.
3 - commands sent out will be logged.
4 - you'll see whats received by the different devices.
5 - debugging.
The value for the global device is a default for other devices without own verbose attribute set.
Gruß
300P
ZitatKönnte das Logging dieser gesendeten Befehle vom consumerXX nicht auf auf Level 3 gesetzt werden?
Sicher, kann ich machen.
EDIT: ist eingecheckt.
Hallo,
irgendwie habe ich seit längerer Zeit ein Problem bei der Verwendung der Wetterkorrekturen über ein eigenes FHEM DWD-Device.
Erst mal Danke für das Modul und die Menge Arbeit die da drin steckt.
Das Problem was ich festgestellt habe, ist wenn ich den Parameter setupWeatherDev1 auf mein lokales FHEM-DWD-Device einstelle sehen die Prognosen so aus als wenn das Wetter überhaupt nicht berücksichtigt wird. Schalte ich z.b. auf OpenMeteoDWD_D2-API sieht es gleich viel besser aus.
Ich habe das DWD-Device natürlich überprüft und hier scheint alles korrekt zu sein. Die notwendigen Readings TTT,Neff,RR1c,ww sind aktuell und plausibel.
Auch das Modul sagt alles auf grün und in Ordnung. Setzte ich aber ein "get SolarForecast weatherApiData" ab, bekomme ich keine Daten im Cache zurück. Bzw jetzt sehe ich die Daten nur von "OpenMeteo" aber keine von einer der lokalen Instanz auch wenn ich "get SolarForecast data" ausführe.
Das Modul ist natürlich auf dem aktuellen Stand 76_SolarForecast.pm:v1.52.5-s29997/2025-05-25.
Eigentlich kann ich auch auf die andere API gehen, ich wollte aber trotzdem mitteilen das hier irgendwie ein Bug zu seien scheint.
Das DWD-Device hat auch keine besonderen Einstellungen:
attr phy_DWD forecastDays 3
attr phy_DWD forecastProperties Neff,ww,wwd,SunD1,SunD3,FF,FX1,Tm,PEvap,RR1c,RR3c ,RRdc,SunD,RSunD,TTT,TX,TN,R101,SunUp,SunRise,SunSet,Rad1h
attr phy_DWD forecastRefresh 1
attr phy_DWD forecastResolution 1
attr phy_DWD forecastStation P######
Wenn ich noch irgendwelche Infos schicken soll, kann ich das gerne machen.
Grüße
Hier habe ich gerade beschrieben, wie man solche Vorhersagewerte in einen FHEM-Plot einbauen kann.
https://wiki.fhem.de/wiki/LogFromArray
https://forum.fhem.de/index.php?topic=141763.msg1342440#msg134244
als Thread dazu.
LG
pah
@Phill,
danke für den Hinweis.
Wenn man ein DWD device als Wetterlieferant gewählt hat, sollte ein "get SolarForecast weatherApiData" keine Daten liefern weil es in diesem Sinn keine API ist.
Bei mir sehe ich auch gerade, dass alte! Daten von OpenMeteo entalten sind, weil ich mal OpenMeteo als Wetterlieferant bei diesem Device ausgewählt hatte. Das ist ein Fehler und schaue ich mir an.
Für die Funtion hat es allerdings keine Relevanz. Man sieht mit einem ctrlDebug=collectData woher die Wetterdaten bezogen werden.
In dem Fall von einem DWD Device was i.O. ist:
2025.05.28 13:25:18.423 1: SolDwd DEBUG> collect Weather data step 1 - device: DWD.Solar.xxxxx =>
2025.05.28 13:25:18.423 1: SolDwd DEBUG> Weather 1: fc0_13, don: 1, wid: 61, RR1c: 0.40, TTT: 16.3, Neff: 93
2025.05.28 13:25:18.424 1: SolDwd DEBUG> Weather 1: fc0_14, don: 1, wid: 61, RR1c: 0.30, TTT: 16.6, Neff: 94
2025.05.28 13:25:18.424 1: SolDwd DEBUG> Weather 1: fc0_15, don: 1, wid: 81, RR1c: 0.30, TTT: 16.8, Neff: 92
2025.05.28 13:25:18.424 1: SolDwd DEBUG> Weather 1: fc0_16, don: 1, wid: 81, RR1c: 0.50, TTT: 16.9, Neff: 91
2025.05.28 13:25:18.424 1: SolDwd DEBUG> Weather 1: fc0_17, don: 1, wid: 81, RR1c: 0.40, TTT: 16.8, Neff: 90
2025.05.28 13:25:18.425 1: SolDwd DEBUG> Weather 1: fc0_18, don: 1, wid: 81, RR1c: 0.40, TTT: 16.3, Neff: 88
2025.05.28 13:25:18.425 1: SolDwd DEBUG> Weather 1: fc0_19, don: 1, wid: 81, RR1c: 0.40, TTT: 15.7, Neff: 88
2025.05.28 13:25:18.425 1: SolDwd DEBUG> Weather 1: fc0_20, don: 1, wid: 81, RR1c: 0.30, TTT: 15, Neff: 89
2025.05.28 13:25:18.425 1: SolDwd DEBUG> Weather 1: fc0_21, don: 1, wid: 80, RR1c: 0.20, TTT: 14.1, Neff: 88
2025.05.28 13:25:18.426 1: SolDwd DEBUG> Weather 1: fc0_22, don: 0, wid: 180, RR1c: 0.00, TTT: 13.3, Neff: 84
2025.05.28 13:25:18.426 1: SolDwd DEBUG> Weather 1: fc0_23, don: 0, wid: 103, RR1c: 0.00, TTT: 12.7, Neff: 81
2025.05.28 13:25:18.426 1: SolDwd DEBUG> Weather 1: fc1_0, don: 0, wid: 103, RR1c: 0.00, TTT: 12.2, Neff: 81
2025.05.28 13:25:18.427 1: SolDwd DEBUG> Weather 1: fc1_1, don: 0, wid: 103, RR1c: 0.00, TTT: 11.8, Neff: 80
2025.05.28 13:25:18.427 1: SolDwd DEBUG> Weather 1: fc1_2, don: 0, wid: 103, RR1c: 0.00, TTT: 11.4, Neff: 83
2025.05.28 13:25:18.427 1: SolDwd DEBUG> Weather 1: fc1_3, don: 0, wid: 103, RR1c: 0.00, TTT: 11, Neff: 84
2025.05.28 13:25:18.427 1: SolDwd DEBUG> Weather 1: fc1_4, don: 0, wid: 103, RR1c: 0.00, TTT: 10.9, Neff: 87
2025.05.28 13:25:18.428 1: SolDwd DEBUG> Weather 1: fc1_5, don: 0, wid: 103, RR1c: 0.00, TTT: 10.6, Neff: 81
2025.05.28 13:25:18.428 1: SolDwd DEBUG> Weather 1: fc1_6, don: 1, wid: 3, RR1c: 0.00, TTT: 10.7, Neff: 78
2025.05.28 13:25:18.428 1: SolDwd DEBUG> Weather 1: fc1_7, don: 1, wid: 3, RR1c: 0.00, TTT: 10.9, Neff: 69
2025.05.28 13:25:18.429 1: SolDwd DEBUG> Weather 1: fc1_8, don: 1, wid: 3, RR1c: 0.00, TTT: 11.7, Neff: 72
2025.05.28 13:25:18.429 1: SolDwd DEBUG> Weather 1: fc1_9, don: 1, wid: 2, RR1c: 0.00, TTT: 12.5, Neff: 73
2025.05.28 13:25:18.429 1: SolDwd DEBUG> Weather 1: fc1_10, don: 1, wid: 2, RR1c: 0.00, TTT: 13.4, Neff: 72
2025.05.28 13:25:18.429 1: SolDwd DEBUG> Weather 1: fc1_11, don: 1, wid: 2, RR1c: 0.00, TTT: 14.2, Neff: 72
2025.05.28 13:25:18.430 1: SolDwd DEBUG> Weather 1: fc1_12, don: 1, wid: 2, RR1c: 0.00, TTT: 14.9, Neff: 73
2025.05.28 13:25:18.430 1: SolDwd DEBUG> Weather 1: fc1_13, don: 1, wid: 2, RR1c: 0.00, TTT: 15.7, Neff: 74
2025.05.28 13:25:18.430 1: SolDwd DEBUG> Weather 1: fc1_14, don: 1, wid: 2, RR1c: 0.00, TTT: 16.5, Neff: 77
2025.05.28 13:25:18.430 1: SolDwd DEBUG> Weather 1: fc1_15, don: 1, wid: 2, RR1c: 0.00, TTT: 16.9, Neff: 79
2025.05.28 13:25:18.431 1: SolDwd DEBUG> Weather 1: fc1_16, don: 1, wid: 2, RR1c: 0.00, TTT: 17.2, Neff: 78
2025.05.28 13:25:18.431 1: SolDwd DEBUG> Weather 1: fc1_17, don: 1, wid: 2, RR1c: 0.00, TTT: 17.3, Neff: 83
2025.05.28 13:25:18.431 1: SolDwd DEBUG> Weather 1: fc1_18, don: 1, wid: 3, RR1c: 0.00, TTT: 17.2, Neff: 87
2025.05.28 13:25:18.432 1: SolDwd DEBUG> Weather 1: fc1_19, don: 1, wid: 3, RR1c: 0.00, TTT: 16.8, Neff: 87
2025.05.28 13:25:18.432 1: SolDwd DEBUG> Weather 1: fc1_20, don: 1, wid: 3, RR1c: 0.00, TTT: 16.1, Neff: 89
2025.05.28 13:25:18.432 1: SolDwd DEBUG> Weather 1: fc1_21, don: 1, wid: 3, RR1c: 0.00, TTT: 15.6, Neff: 89
2025.05.28 13:25:18.433 1: SolDwd DEBUG> Weather 1: fc1_22, don: 0, wid: 103, RR1c: 0.00, TTT: 15.2, Neff: 93
2025.05.28 13:25:18.433 1: SolDwd DEBUG> merge Weather data =>
2025.05.28 13:25:18.433 1: SolDwd DEBUG> Weather merged: fc0_13, don: 1, wid: 61, RR1c: 0.40, TTT: 16.30, Neff: 93
2025.05.28 13:25:18.433 1: SolDwd DEBUG> Weather merged: fc0_14, don: 1, wid: 61, RR1c: 0.30, TTT: 16.60, Neff: 94
2025.05.28 13:25:18.434 1: SolDwd DEBUG> Weather merged: fc0_15, don: 1, wid: 81, RR1c: 0.30, TTT: 16.80, Neff: 92
2025.05.28 13:25:18.434 1: SolDwd DEBUG> Weather merged: fc0_16, don: 1, wid: 81, RR1c: 0.50, TTT: 16.90, Neff: 91
2025.05.28 13:25:18.434 1: SolDwd DEBUG> Weather merged: fc0_17, don: 1, wid: 81, RR1c: 0.40, TTT: 16.80, Neff: 90
2025.05.28 13:25:18.434 1: SolDwd DEBUG> Weather merged: fc0_18, don: 1, wid: 81, RR1c: 0.40, TTT: 16.30, Neff: 88
2025.05.28 13:25:18.435 1: SolDwd DEBUG> Weather merged: fc0_19, don: 1, wid: 81, RR1c: 0.40, TTT: 15.70, Neff: 88
2025.05.28 13:25:18.435 1: SolDwd DEBUG> Weather merged: fc0_20, don: 1, wid: 81, RR1c: 0.30, TTT: 15.00, Neff: 89
2025.05.28 13:25:18.435 1: SolDwd DEBUG> Weather merged: fc0_21, don: 1, wid: 80, RR1c: 0.20, TTT: 14.10, Neff: 88
2025.05.28 13:25:18.436 1: SolDwd DEBUG> Weather merged: fc0_22, don: 0, wid: 180, RR1c: 0.00, TTT: 13.30, Neff: 84
2025.05.28 13:25:18.436 1: SolDwd DEBUG> Weather merged: fc0_23, don: 0, wid: 103, RR1c: 0.00, TTT: 12.70, Neff: 81
2025.05.28 13:25:18.436 1: SolDwd DEBUG> Weather merged: fc1_0, don: 0, wid: 103, RR1c: 0.00, TTT: 12.20, Neff: 81
2025.05.28 13:25:18.436 1: SolDwd DEBUG> Weather merged: fc1_1, don: 0, wid: 103, RR1c: 0.00, TTT: 11.80, Neff: 80
2025.05.28 13:25:18.437 1: SolDwd DEBUG> Weather merged: fc1_10, don: 1, wid: 2, RR1c: 0.00, TTT: 13.40, Neff: 72
2025.05.28 13:25:18.437 1: SolDwd DEBUG> Weather merged: fc1_11, don: 1, wid: 2, RR1c: 0.00, TTT: 14.20, Neff: 72
2025.05.28 13:25:18.437 1: SolDwd DEBUG> Weather merged: fc1_12, don: 1, wid: 2, RR1c: 0.00, TTT: 14.90, Neff: 73
2025.05.28 13:25:18.437 1: SolDwd DEBUG> Weather merged: fc1_13, don: 1, wid: 2, RR1c: 0.00, TTT: 15.70, Neff: 74
2025.05.28 13:25:18.438 1: SolDwd DEBUG> Weather merged: fc1_14, don: 1, wid: 2, RR1c: 0.00, TTT: 16.50, Neff: 77
2025.05.28 13:25:18.438 1: SolDwd DEBUG> Weather merged: fc1_15, don: 1, wid: 2, RR1c: 0.00, TTT: 16.90, Neff: 79
2025.05.28 13:25:18.439 1: SolDwd DEBUG> Weather merged: fc1_16, don: 1, wid: 2, RR1c: 0.00, TTT: 17.20, Neff: 78
2025.05.28 13:25:18.439 1: SolDwd DEBUG> Weather merged: fc1_17, don: 1, wid: 2, RR1c: 0.00, TTT: 17.30, Neff: 83
2025.05.28 13:25:18.439 1: SolDwd DEBUG> Weather merged: fc1_18, don: 1, wid: 3, RR1c: 0.00, TTT: 17.20, Neff: 87
2025.05.28 13:25:18.440 1: SolDwd DEBUG> Weather merged: fc1_19, don: 1, wid: 3, RR1c: 0.00, TTT: 16.80, Neff: 87
2025.05.28 13:25:18.440 1: SolDwd DEBUG> Weather merged: fc1_2, don: 0, wid: 103, RR1c: 0.00, TTT: 11.40, Neff: 83
2025.05.28 13:25:18.440 1: SolDwd DEBUG> Weather merged: fc1_20, don: 1, wid: 3, RR1c: 0.00, TTT: 16.10, Neff: 89
2025.05.28 13:25:18.441 1: SolDwd DEBUG> Weather merged: fc1_21, don: 1, wid: 3, RR1c: 0.00, TTT: 15.60, Neff: 89
2025.05.28 13:25:18.441 1: SolDwd DEBUG> Weather merged: fc1_22, don: 0, wid: 103, RR1c: 0.00, TTT: 15.20, Neff: 93
2025.05.28 13:25:18.442 1: SolDwd DEBUG> Weather merged: fc1_3, don: 0, wid: 103, RR1c: 0.00, TTT: 11.00, Neff: 84
2025.05.28 13:25:18.442 1: SolDwd DEBUG> Weather merged: fc1_4, don: 0, wid: 103, RR1c: 0.00, TTT: 10.90, Neff: 87
2025.05.28 13:25:18.442 1: SolDwd DEBUG> Weather merged: fc1_5, don: 0, wid: 103, RR1c: 0.00, TTT: 10.60, Neff: 81
2025.05.28 13:25:18.443 1: SolDwd DEBUG> Weather merged: fc1_6, don: 1, wid: 3, RR1c: 0.00, TTT: 10.70, Neff: 78
2025.05.28 13:25:18.443 1: SolDwd DEBUG> Weather merged: fc1_7, don: 1, wid: 3, RR1c: 0.00, TTT: 10.90, Neff: 69
2025.05.28 13:25:18.443 1: SolDwd DEBUG> Weather merged: fc1_8, don: 1, wid: 3, RR1c: 0.00, TTT: 11.70, Neff: 72
2025.05.28 13:25:18.444 1: SolDwd DEBUG> Weather merged: fc1_9, don: 1, wid: 2, RR1c: 0.00, TTT: 12.50, Neff: 73
Da kannst du auch die Werte mit dem DWD Device vergleichen.
Vllt. fülle ich aber auch die weatherApiData mit den Werten damit eine Einheitlichkeit vorhanden ist und nicht zur Verwirrung führt.
LG,
Heiko
Hi, und danke für die Antwort.
Dein Hinweis mit dem Debug hat geholfen zu erkennen das es wohl nicht an den Wetterdaten liegt, sondern an den Radiation-Werten und somit an der Einstellung des Attributs setupRadiationAPI. DWD sendet hier Strahlungswerte die viel Höher sind als die von OpenMeteo. Es scheint das die von OpenMeteo Wetterabhängig sind und von DWD Wetterunabhängig oder zumindest viel weniger Wetterabhängig sind.
Es war etwas kniffelig herauszufinden, da wenn man setupWeatherDev1 ändert sofort die neuen Wetterdaten benutzt werden, im Gegensatz ändert man setupRadiationAPI die Daten der vorherigen API noch eine Zeit lang weiter verwendet werden.
Um es eindeutig zu belegen, habe ich dann ein neues Gerät angelegt.
Dass die Rad1h Daten so unterschiedlich sind ist natürlich merkwürdig ist vielleicht auch Stationsabhängig. Bei DWD hatte ich bei der Solarvorhersage immer einen ziemlich akkuraten Sinus, das hatte mich schon die ganze Zeit gewundert. Dann werde ich wohl bei OpenMeteo bleiben.
Grüße und Danke!
Hallo Heiko, ich habe aktuell die Version 1.52.5 laufen. Seit dem Update auf 1.52.4 habe ich festgestellt, dass plötzlich die Prognosewerte für meinen Speicher nicht mehr stimmen. Es wird so angezeigt, als wenn der Speicher über Nacht nicht entladen werden würde. Natürlich wird aber Nachts auch Strom verbraucht, so dass der Speicher morgens dann bei ca. 40% steht.
Wo könnte ich denn hier ansetzen?
Moin,
sorry, das Thema hatte ich etwas aus den Augen verloren ...
Zitat von: DS_Starter am 22 Mai 2025, 13:27:47Current_PV = 0 W -> wird vermutlich nicht stimmen.
Leider sieht man das /die Inverter-Attribute nicht.
Habe ich irgendwann mal übersehen, daß der Wechselrichter bzw. die Einrichtung sich geändert hat?
Hier ist der WR:
Internals:
DEF crypt:51540655 192.168.1.21
FUUID 5c573c8b-f33f-e6da-959a-d15c910a847eb23a
FVERSION 76_SMAInverter.pm:v2.29.6-s29924/2025-05-04
HOST 192.168.1.21
INTERVAL 60
INVCLASS 8001
INVFWMAIN 2
INVTYPE 9100
LASTUPDATE 28.05.2025 / 17:06:08
NAME PV
NR 98
PASS crypt:51540655
STATE 530
TYPE SMAInverter
eventCount 8932
HELPER:
AVERAGEBUF 530,826,1078,1214,1387,1422,1619,1993,1416,1443,1461,1578,1706,1766,2260,1881,2379
DEFAULT_TARGET_SERIAL 4294967295
DEFAULT_TARGET_SUSYID 65535
FAULTEDCYCLES 0
INTERVAL 60
MAXBYTES 300
MYSERIALNUMBER 123321123
MYSUSYID 233
PACKAGE main
PKT_ID 32769
VERSION 2.29.6
firtRunDay 0
READINGS:
2025-05-28 17:06:08 INV_CLASS Solar-Wechselrichter
2025-05-28 16:35:08 INV_FIRMWARE 2.85.3 R
2025-05-28 17:06:08 INV_GRIDRELAY geschlossen
2025-05-28 17:06:08 INV_GeneralOperatingStatus MPP
2025-05-28 17:06:08 INV_NAME SN: 304906370
2025-05-28 17:06:08 INV_PACMAX1 7000
2025-05-28 17:06:08 INV_PACMAX2 7000
2025-05-28 17:06:08 INV_PACMAX3 7000
2025-05-28 17:06:08 INV_STATUS Ok
2025-05-04 20:53:18 INV_TEMP 48.7
2025-05-28 17:06:08 INV_TYPE STP 7000TL-20
2025-05-28 17:06:08 SPOT_ETODAY 14273
2025-05-28 17:06:08 SPOT_ETODAY_KWh 14.273
2025-05-28 17:06:08 SPOT_ETOTAL 91153941
2025-05-28 17:06:08 SPOT_ETOTAL_KWh 91153.941
2025-05-28 17:06:08 SPOT_FEEDTM 49828.34
2025-05-28 17:06:08 SPOT_FREQ 50.02
2025-05-28 17:06:08 SPOT_IAC1 0.75
2025-05-28 17:06:08 SPOT_IAC2 0.75
2025-05-28 17:06:08 SPOT_IAC3 0.75
2025-05-28 17:06:08 SPOT_IDC1 0.546
2025-05-28 17:06:08 SPOT_IDC2 0.572
2025-05-28 17:06:08 SPOT_OPERTM 50743.4
2025-05-28 17:06:08 SPOT_PAC1 177
2025-05-28 17:06:08 SPOT_PAC2 175
2025-05-28 17:06:08 SPOT_PAC3 178
2025-05-28 17:06:08 SPOT_PACTOT 530
2025-05-28 17:06:08 SPOT_PDC1 228
2025-05-28 17:06:08 SPOT_PDC2 241
2025-05-28 17:06:08 SPOT_UAC1 238.88
2024-02-11 14:22:02 SPOT_UAC1_2 9.870
2025-05-28 17:06:08 SPOT_UAC2 237
2024-02-11 14:22:02 SPOT_UAC2_3 9.940
2025-05-28 17:06:08 SPOT_UAC3 238.18
2024-02-11 14:22:02 SPOT_UAC3_1 9.880
2025-05-28 17:06:08 SPOT_UDC1 418.81
2025-05-28 17:06:08 SPOT_UDC2 423.06
2025-05-28 17:06:08 SUSyID 181 - SN: 304906370
2025-05-28 17:06:08 Serialnumber 304906370
2025-05-28 17:06:08 avg_power_lastminutes_05 1076
2025-05-28 17:06:08 avg_power_lastminutes_10 1308
2025-05-28 17:06:08 avg_power_lastminutes_15 1473
2025-05-28 17:06:08 modulstate normal
2025-05-28 17:06:08 opertime_start 28.05.2025 04:29:51
2025-05-28 17:06:08 opertime_stop 28.05.2025 22:19:21
2025-05-28 17:06:08 state 530
Attributes:
SBFSpotComp 0
detail-level 2
event-on-change-reading .*
event-on-update-reading .*
mode automatic
room PV
target-serial 304906370
target-susyid 181
userReadings SPOT_ETODAY_KWh { my $temp1 = ReadingsVal($name,"SPOT_ETODAY",0)/1000; return $temp1;},
SPOT_ETOTAL_KWh { my $temp1 = ReadingsVal($name,"SPOT_ETOTAL",0)/1000; return $temp1;}Und nochmal das SV-Device:
Internals:
FUUID 62f1192d-f33f-378b-0c69-cc57687c40949580
FVERSION 76_SolarForecast.pm:v1.52.5-s29997/2025-05-25
LCACHEFILE last write time: 17:00:04 File: ./FHEM/FhemUtils/AIraw_SolarForecast_SolarForecast
MODE Automatic / Event-controlled - next planned Cycletime: 17:09:34
MODEL OpenMeteoDWDAPI
NAME SolarForecast
NOTIFYDEV MyObis,ShellyPlugS_HWR_Waschmaschine,ShellyPlug_HWR_Trockner,ShellyPlugS_Kueche_SpueMa,ShellyPlugS_Kueche_Kuehlschrank,Shellyplus1pm_Gartenhaus_Gefrierschrank,ShellyPlugS_Buero_PC,ShellyPlusPlugS_Buero_fhem,ShellyPlusPlugS_Buero_NAS,ShellyPlugS_Wohnzimmer_TV,ShellyPlusPlugS_Buero_FritzBox,PV
NR 1422
NTFY_ORDER 50-SolarForecast
STATE updated
TYPE SolarForecast
WEATHERMODEL OpenMeteoDWDAPI
eventCount 3006
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV SolarForecast
SPGROOM
VERSION 1.52.5
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 11359
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:3838722
telnet telnetForBlockingFn_1748357921.0281_127.0.0.1_53688
terminated 1
timeout 30
abortArg:
arg:
block 1
name SolarForecast
tsnext 1748445387.15631
OLDREADINGS:
READINGS:
2025-05-28 17:08:24 Current_AutarkyRate 0 %
2025-05-28 17:08:24 Current_Consumption 269 W
2025-05-28 17:08:24 Current_GridConsumption 269 W
2025-05-28 17:08:24 Current_GridFeedIn 0 W
2025-05-28 17:08:24 Current_PV 0 W
2025-05-28 17:08:24 Current_SelfConsumption 0 W
2025-05-28 17:08:24 Current_SelfConsumptionRate 0 %
2025-05-28 17:08:24 Current_Surplus 0 W
2025-05-28 17:00:00 LastHourGridconsumptionReal 1258 Wh
2025-05-28 17:00:00 LastHourPVforecast 650 Wh
2025-05-28 17:00:00 LastHourPVreal 1515 Wh
2025-05-28 17:08:24 NextHours_Sum01_PVforecast 1048 Wh
2025-05-28 17:08:24 NextHours_Sum02_PVforecast 1730 Wh
2025-05-28 17:08:24 NextHours_Sum03_PVforecast 1985 Wh
2025-05-28 17:08:24 NextHours_Sum04_ConsumptionForecast 2307 Wh
2025-05-28 17:08:24 NextHours_Sum04_PVforecast 2110 Wh
2025-05-28 17:08:24 RestOfDayConsumptionForecast 3570 Wh
2025-05-28 17:08:24 RestOfDayPVforecast 2113 Wh
2025-05-28 00:59:49 Today_Hour01_GridConsumption 361 Wh
2025-05-28 00:59:49 Today_Hour01_GridFeedIn 0 Wh
2025-05-28 00:59:49 Today_Hour01_PVreal 0 Wh
2025-05-28 01:59:49 Today_Hour02_GridConsumption 369 Wh
2025-05-28 01:59:49 Today_Hour02_GridFeedIn 0 Wh
2025-05-28 01:59:49 Today_Hour02_PVreal 0 Wh
2025-05-28 02:59:49 Today_Hour03_GridConsumption 372 Wh
2025-05-28 02:59:49 Today_Hour03_GridFeedIn 0 Wh
2025-05-28 02:59:49 Today_Hour03_PVreal 0 Wh
2025-05-28 03:59:49 Today_Hour04_GridConsumption 347 Wh
2025-05-28 03:59:49 Today_Hour04_GridFeedIn 0 Wh
2025-05-28 03:59:49 Today_Hour04_PVreal 0 Wh
2025-05-28 04:59:52 Today_Hour05_GridConsumption 349 Wh
2025-05-28 04:59:52 Today_Hour05_GridFeedIn 0 Wh
2025-05-28 04:59:52 Today_Hour05_PVreal 0 Wh
2025-05-28 05:59:49 Today_Hour06_GridConsumption 414 Wh
2025-05-28 05:59:49 Today_Hour06_GridFeedIn 0 Wh
2025-05-28 05:59:49 Today_Hour06_PVforecast 19 Wh
2025-05-28 05:59:49 Today_Hour06_PVreal 0 Wh
2025-05-28 06:59:49 Today_Hour07_GridConsumption 532 Wh
2025-05-28 06:59:49 Today_Hour07_GridFeedIn 0 Wh
2025-05-28 06:59:49 Today_Hour07_PVforecast 79 Wh
2025-05-28 06:59:49 Today_Hour07_PVreal 67 Wh
2025-05-28 07:59:49 Today_Hour08_GridConsumption 170 Wh
2025-05-28 07:59:49 Today_Hour08_GridFeedIn 51 Wh
2025-05-28 07:59:49 Today_Hour08_PVforecast 292 Wh
2025-05-28 07:59:49 Today_Hour08_PVreal 392 Wh
2025-05-28 08:59:49 Today_Hour09_GridConsumption 28 Wh
2025-05-28 08:59:49 Today_Hour09_GridFeedIn 252 Wh
2025-05-28 08:59:49 Today_Hour09_PVforecast 915 Wh
2025-05-28 08:59:49 Today_Hour09_PVreal 723 Wh
2025-05-28 09:59:52 Today_Hour10_GridConsumption 449 Wh
2025-05-28 09:59:52 Today_Hour10_GridFeedIn 609 Wh
2025-05-28 09:59:52 Today_Hour10_PVforecast 708 Wh
2025-05-28 09:59:52 Today_Hour10_PVreal 1415 Wh
2025-05-28 10:59:50 Today_Hour11_GridConsumption 0 Wh
2025-05-28 10:59:50 Today_Hour11_GridFeedIn 1697 Wh
2025-05-28 10:59:50 Today_Hour11_PVforecast 3423 Wh
2025-05-28 10:59:50 Today_Hour11_PVreal 2137 Wh
2025-05-28 11:59:49 Today_Hour12_GridConsumption 0 Wh
2025-05-28 11:59:49 Today_Hour12_GridFeedIn 2291 Wh
2025-05-28 11:59:49 Today_Hour12_PVforecast 714 Wh
2025-05-28 11:59:49 Today_Hour12_PVreal 2807 Wh
2025-05-28 12:59:49 Today_Hour13_GridConsumption 13 Wh
2025-05-28 12:59:49 Today_Hour13_GridFeedIn 696 Wh
2025-05-28 12:59:49 Today_Hour13_PVforecast 1316 Wh
2025-05-28 12:59:49 Today_Hour13_PVreal 1092 Wh
2025-05-28 13:59:49 Today_Hour14_GridConsumption 259 Wh
2025-05-28 13:59:49 Today_Hour14_GridFeedIn 420 Wh
2025-05-28 13:59:49 Today_Hour14_PVforecast 1952 Wh
2025-05-28 13:59:49 Today_Hour14_PVreal 807 Wh
2025-05-28 14:59:49 Today_Hour15_GridConsumption 174 Wh
2025-05-28 14:59:49 Today_Hour15_GridFeedIn 570 Wh
2025-05-28 14:59:49 Today_Hour15_PVforecast 1803 Wh
2025-05-28 14:59:49 Today_Hour15_PVreal 831 Wh
2025-05-28 15:59:49 Today_Hour16_GridConsumption 488 Wh
2025-05-28 15:59:49 Today_Hour16_GridFeedIn 1754 Wh
2025-05-28 15:59:49 Today_Hour16_PVforecast 3988 Wh
2025-05-28 15:59:49 Today_Hour16_PVreal 2335 Wh
2025-05-28 16:59:49 Today_Hour17_GridConsumption 1258 Wh
2025-05-28 16:59:49 Today_Hour17_GridFeedIn 534 Wh
2025-05-28 16:59:49 Today_Hour17_PVforecast 650 Wh
2025-05-28 16:59:49 Today_Hour17_PVreal 1515 Wh
2025-05-28 17:08:24 Today_Hour18_GridConsumption 7 Wh
2025-05-28 17:08:24 Today_Hour18_GridFeedIn 65 Wh
2025-05-28 17:08:24 Today_Hour18_PVforecast 1101 Wh
2025-05-28 17:08:24 Today_Hour18_PVreal 165 Wh
2025-05-28 17:08:24 Today_Hour19_PVforecast 754 Wh
2025-05-28 17:08:24 Today_Hour20_PVforecast 274 Wh
2025-05-28 17:08:24 Today_Hour21_PVforecast 146 Wh
2025-05-28 17:08:24 Today_Hour22_PVforecast 4 Wh
2025-05-28 17:08:24 Today_MaxPVforecast 3988 Wh
2025-05-28 17:08:24 Today_MaxPVforecastTime 2025-05-28 15:00:00
2025-05-28 17:08:24 Today_PVforecast 18138 Wh
2025-05-28 17:08:24 Today_PVreal 14286 Wh
2025-05-28 17:08:24 Today_SunRise 05:15
2025-05-28 17:08:24 Today_SunSet 21:33
2025-05-28 17:08:24 Tomorrow_ConsumptionForecast 11336 Wh
2025-05-28 17:08:24 Tomorrow_PVforecast 23604 Wh
2025-05-28 17:08:24 Tomorrow_SunRise 05:14
2025-05-28 17:08:24 Tomorrow_SunSet 21:34
2025-05-28 17:08:24 consumer01 name='ShellyPlugS_HWR_Waschmaschine' state='on' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer01_ConsumptionRecommended 0
2025-05-28 17:08:24 consumer01_currentPower 0 W
2025-05-28 17:08:24 consumer02 name='ShellyPlug_HWR_Trockner' state='on' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer02_currentPower 2.61 W
2025-05-28 17:08:24 consumer03 name='ShellyPlugS_Kueche_SpueMa' state='on' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer03_ConsumptionRecommended 0
2025-05-28 17:08:24 consumer03_currentPower 39.69 W
2025-05-28 17:08:24 consumer04 name='ShellyPlugS_Kueche_Kuehlschrank' state='on' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer04_ConsumptionRecommended 0
2025-05-28 17:08:24 consumer04_currentPower 0 W
2025-05-28 17:08:24 consumer05 name='Gefrierschrank Gartenhaus mit Temp' state='on' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer05_currentPower 1 W
2025-05-28 17:08:24 consumer06 name='ShellyPlugS_Buero_PC' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-28 17:08:24 consumer06_currentPower 75.76 W
2025-05-28 17:08:24 consumer07 name='ShellyPlusPlugS_Buero_fhem' state='unknown' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer07_currentPower 5.7 W
2025-05-28 17:08:24 consumer08 name='ShellyPlusPlugS_Buero_NAS' state='on' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer08_currentPower 0 W
2025-05-28 17:08:24 consumer09 name='ShellyPlugS_Wohnzimmer_TV' state='off' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer09_currentPower 0 W
2025-05-28 17:08:24 consumer10 name='ShellyPlusPlugS_Buero_FritzBox' state='on' mode='can' planningstate='noSchedule'
2025-05-28 17:08:24 consumer10_currentPower 0 W
2025-05-28 17:08:24 nextCycletime 17:09:34
2022-10-18 14:57:17 nextPolltime 14:58:27
2025-05-28 16:57:54 nextRadiationAPICall nach 28.05.2025 17:12:54
2025-05-28 07:00:04 pvCorrectionFactor_07 0.98 (automatic - old factor: 0.85, AI result used, Sun Alt range: 10, Cloud range: 100, Days in range: 7)
2025-05-28 08:00:05 pvCorrectionFactor_08 1.64 (automatic - old factor: 1.27, Sun Alt range: 20, Cloud range: 100, Days in range: 3)
2025-05-28 09:00:04 pvCorrectionFactor_09 1.08 (automatic - old factor: 1.73, AI result used, Sun Alt range: 25, Cloud range: 100, Days in range: 5)
2025-05-28 10:00:04 pvCorrectionFactor_10 1.12 (automatic - old factor: 1.12, AI result used, Sun Alt range: 35, Cloud range: 100, Days in range: 5)
2025-05-28 11:00:04 pvCorrectionFactor_11 1.13 (automatic - old factor: 1.13, AI result used, Sun Alt range: 45, Cloud range: 100, Days in range: 6)
2025-05-28 12:00:04 pvCorrectionFactor_12 1.12 (automatic - old factor: 0.80, Sun Alt range: 50, Cloud range: 100, Days in range: 5)
2025-05-28 13:00:05 pvCorrectionFactor_13 0.95 (automatic - old factor: 1.02, Sun Alt range: 60, Cloud range: 100, Days in range: 2)
2025-05-28 14:00:05 pvCorrectionFactor_14 0.94 (automatic - old factor: 0.90, AI result used, Sun Alt range: 60, Cloud range: 100, Days in range: 5)
2025-05-28 15:00:03 pvCorrectionFactor_15 0.98 (automatic - old factor: 0.99, AI result used, Sun Alt range: 55, Cloud range: 100, Days in range: 10)
2025-05-28 16:00:04 pvCorrectionFactor_16 0.97 (automatic - old factor: 0.81, AI result used, Sun Alt range: 50, Cloud range: 100, Days in range: 7)
2025-05-28 17:00:04 pvCorrectionFactor_17 1.22 (automatic - old factor: 0.83, AI result used, Sun Alt range: 45, Cloud range: 100, Days in range: 3)
2025-05-28 17:08:24 pvCorrectionFactor_Auto on_complex_ai
2025-05-28 17:08:24 special_runTimeTrainAI 10.14762 s
2025-05-28 17:08:25 state updated
Attributes:
DbLogExclude .*
alias SolarForecast
cmdIcon consumer03_ConsumptionRecommended cmdIcon 0:15px-red 1:15px-green consumer04_ConsumptionRecommended cmdIcon 0:15px-red 1:15px-green
comment ShellyPlugS_Gartenhaus_Weatherman
funktioniert:
consumer03_planned_hour {my @consumer03_planned = split( " ", ReadingsVal("SolarForecast","consumer03_planned_start",""));return $consumer03_planned[1];}
gibt im Moment Fehler:
consumer03_planned_hour {my @consumer03_planned = split( " ", ReadingsVal("SolarForecast","consumer03_planned_start","")); my @pieces = split(/:/,$consumer03_planned[1]); return $pieces[0].":".$pieces[1]},
consumer03_planned_date {my @consumer03_planned = split( " ", ReadingsVal("SolarForecast","consumer03_planned_start","")); my @pieces = split(/:/,$consumer03_planned[0]); return $pieces[1]}
consumer01 ShellyPlugS_HWR_Waschmaschine type=noSchedule power=2200 icon=scene_washing_machine pcurr=power:W
consumer02 ShellyPlug_HWR_Trockner type=noSchedule icon=scene_clothes_dryer pcurr=power:W power=3000
consumer03 ShellyPlugS_Kueche_SpueMa type=noSchedule power=2200 icon=scene_dishwasher pcurr=power:W
consumer04 ShellyPlugS_Kueche_Kuehlschrank type=noSchedule power=90 icon=kuehlschrank_small pcurr=power:W
consumer05 Shellyplus1pm_Gartenhaus_Gefrierschrank type=noSchedule power=90 icon=gefrierschrank_icon pcurr=power:W
consumer06 ShellyPlugS_Buero_PC type=noSchedule power=100 switchdev=ShellyPlugS_Buero_PC icon=it_pc pcurr=power:W
consumer07 ShellyPlusPlugS_Buero_fhem type=noSchedule power=100 switchdev=ShellyPlusPlugS_Buero_fhem icon=system_fhem pcurr=power:W
consumer08 ShellyPlusPlugS_Buero_NAS type=noSchedule power=150 icon=it_nas pcurr=power:W
consumer09 ShellyPlugS_Wohnzimmer_TV type=noSchedule power=150 icon=it_television pcurr=power:W
consumer10 ShellyPlusPlugS_Buero_FritzBox type=noSchedule power=20 icon=it_router pcurr=power:W
consumerControl adviceIcon=radio_checked@green detailLink=1 showLegend=text_bottom
ctrlConsRecommendReadings 01,03,04
ctrlSpecialReadings runTimeTrainAI
event-on-change-reading .*
graphicBeam1Color 35E01B
graphicBeam1Content pvReal
graphicBeam2Color FF8F1F
graphicBeam2Content pvForecast
graphicControl hourCount=24 hourStyle=:00 layoutType=double
graphicHeaderOwnspec #
AutarkyRate:Current_AutarkyRate
Überschuß:Current_Surplus
aktueller Netzbezug:Current_GridConsumption
aktuelle Einspeisung:Current_GridFeedIn
graphicHistoryHour 0
graphicSelect both
group Energie
room EG->HWR,OG->Buero
setupInverterDev01 PV pv=SPOT_PACTOT:W etotal=SPOT_ETOTAL:W capacity=7500
setupInverterStrings Sued
setupMeterDev MyObis gcon=power:W gfeedin=-gcon contotal=total_consumption:W feedtotal=total_feed:W
setupRadiationAPI OpenMeteoDWD-API
setupStringAzimuth Sued=SE
setupStringDeclination Sued=45
setupStringPeak Sued=7.5
setupWeatherDev1 OpenMeteoDWD-APIGruß, Christoph
@caldir65,
setupInverterDev01 PV pv=SPOT_PACTOT:W etotal=SPOT_ETOTAL:W capacity=7500
muß heißen
setupInverterDev01 PV pvOut=SPOT_PACTOT:W etotal=SPOT_ETOTAL:W capacity=7500
Die Umsetzung erfolgte automatisch. Möglicherweise hast du die Strukturänderung nicht gespeichert.
LG,
Heiko
@Wolle02,
poste bitte deine setup* - Attribute.
Grüße,
Heiko
Hallo Heiko,
danke, leider funktioniert das so nicht - beim setzen des attr kommt eine Fehlermeldung "The key 'etotal=SPOT_ETOTAL:W' is not specified correctly. Please refer to the command reference."
Zitat von: DS_Starter am 28 Mai 2025, 18:13:25setupInverterDev01 PV pv=SPOT_PACTOT:W etotal=SPOT_ETOTAL:W capacity=7500
muß heißen
setupInverterDev01 PV pvOut=SPOT_PACTOT:W etotal=SPOT_ETOTAL:W capacity=7500
Zitat von: Phill am 28 Mai 2025, 15:14:54Dass die Rad1h Daten so unterschiedlich sind ist natürlich merkwürdig
Hallo Phill,
die Koordinaten des Standorts sind aber richtig gepflegt? Ich frage aus Erfahrung ;-) Ich hatte da ganz am Anfang was eingetragen und nie wieder die Korrektheit geprüft. SolarForcast hatte dann ja auch Koordinaten vorgefunden und nichts bemängelt. Auf die DWD Station hätte so was keinen Einfluss, weil man die direkt auswählt.
Mal davon abgesehen, haben mir heute Morgen DWD und Open Meteo für den Nachmittag total unterschiedliches Wetter vorausgesagt ...
Viele Grüße
Thomas
@caldir65,
da steckt noch ein Fehler drin:
setupInverterDev01 PV pvOut=SPOT_PACTOT:W etotal=SPOT_ETOTAL:Wh capacity=7500
etotal ist eine Energie -> Wh | kWh
LG
Zitat von: DS_Starter am 28 Mai 2025, 18:14:54@Wolle02,
poste bitte deine setup* - Attribute.
Grüße,
Heiko
Ja natürlich. Hier:
setupBatteryDev01 PV_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W cap=10240 intotal=Summe_Ladung:Wh outtotal=Summe_Entladung:Wh charge=BatteryChargePercent show=2
setupInverterDev01 BKW_800 capacity=800 etotal=energy_total:Wh pvOut=power:W strings=BKW_West
setupInverterDev02 Fronius_Symo_Gen24 etotal=User_Produced_PV:kWh pvOut=PowerFlow_Site_P_PV:W capacity=6000 strings=Dach_Ost,Dach_West
setupInverterDev03 BKW_600 capacity=600 etotal=energy_total:Wh pvOut=power:W strings=BKW_Ost
setupInverterStrings Dach_Ost,Dach_West,BKW_Ost,BKW_West
setupMeterDev Hausstromzaehler gcon=power:W contotal=overall_consumption:Wh gfeedin=-gcon:W feedtotal=overall_feed:Wh
setupRadiationAPI OpenMeteoDWDEnsemble-API
setupStringAzimuth Dach_Ost=E Dach_West=W BKW_Ost=E BKW_West=W
setupStringDeclination Dach_Ost=40 Dach_West=40 BKW_Ost=15 BKW_West=90
setupStringPeak Dach_Ost=3.22 Dach_West=3.22 BKW_Ost=0.72 BKW_West=0.92
setupWeatherDev1 OpenMeteoDWDEnsemble-API
Das passt alles.
Dann müssen wir in das Debug schauen -> ctrlDebug=batteryManagement
Die Ausgabe bitte posten. Sieht etwas so aus:
2025.05.28 23:20:59.288 1: SolCast DEBUG> Bat XX Charge Rcmd - Inverter 'STP_5000' cap: 5000 W, Power limit: 100 % -> Pmax eff: 5000 W
2025.05.28 23:20:59.288 1: SolCast DEBUG> Bat XX Charge Rcmd - Inverter 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common' cap: 2080 W, Power limit: 100 % -> Pmax eff: 2080 W
2025.05.28 23:20:59.288 1: SolCast DEBUG> Bat XX Charge Rcmd - Inverter 'MQTT2_cerboGX_c0619ab34e08_vebus' cap: 7200 W, Power limit: 100 % -> Pmax eff: 7200 W
2025.05.28 23:20:59.289 1: SolCast DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 14280 W
2025.05.28 23:20:59.289 1: SolCast DEBUG> Bat 01 Charge Rcmd - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.05.28 23:20:59.289 1: SolCast DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 28416 Wh, Percentage of total capacity: 100.0 %
2025.05.28 23:20:59.290 1: SolCast DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.05.28 23:20:59.290 1: SolCast DEBUG> Bat 01 relLoad 28 23 -> 1 (CurrSoc: 89 %, SoCfc: 24559 Wh, whneed: 3126, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, CurrPV: 0 W, CurrCons: 739 W, Limit: 14280 W, inTime: 1)
2025.05.28 23:20:59.290 1: SolCast DEBUG> Bat 01 relLoad 29 00 -> 1 (SoCfc: 84.3 % / 23968 Wh, whneed: 3857, pvfc: 0, tompvfc: 41690, tomconfc: 16050, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.291 1: SolCast DEBUG> Bat 01 relLoad 29 01 -> 1 (SoCfc: 82.5 % / 23441 Wh, whneed: 4448, pvfc: 0, tompvfc: 41690, tomconfc: 16050, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.291 1: SolCast DEBUG> Bat 01 relLoad 29 02 -> 1 (SoCfc: 80.6 % / 22914 Wh, whneed: 4975, pvfc: 0, tompvfc: 41690, tomconfc: 16050, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.292 1: SolCast DEBUG> Bat 01 relLoad 29 03 -> 1 (SoCfc: 78.8 % / 22401 Wh, whneed: 5502, pvfc: 0, tompvfc: 41690, tomconfc: 16050, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.292 1: SolCast DEBUG> Bat 01 relLoad 29 04 -> 1 (SoCfc: 76.9 % / 21865 Wh, whneed: 6015, pvfc: 0, tompvfc: 41690, tomconfc: 16050, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.293 1: SolCast DEBUG> Bat 01 relLoad 29 05 -> 0 (SoCfc: 75.2 % / 21358 Wh, whneed: 6551, pvfc: 84, tompvfc: 41606, tomconfc: 15510, SurpDay: 26096 Wh, inTime: 1)
2025.05.28 23:20:59.293 1: SolCast DEBUG> Bat 01 relLoad 29 06 -> 0 (SoCfc: 74.2 % / 21094 Wh, whneed: 7058, pvfc: 238, tompvfc: 41368, tomconfc: 15034, SurpDay: 26334 Wh, inTime: 1)
2025.05.28 23:20:59.294 1: SolCast DEBUG> Bat 01 relLoad 29 07 -> 0 (SoCfc: 74.0 % / 21024 Wh, whneed: 7322, pvfc: 824, tompvfc: 40544, tomconfc: 14147, SurpDay: 26397 Wh, inTime: 1)
2025.05.28 23:20:59.294 1: SolCast DEBUG> Bat 01 relLoad 29 08 -> 0 (SoCfc: 74.0 % / 21024 Wh, whneed: 7392, pvfc: 2851, tompvfc: 37693, tomconfc: 13488, SurpDay: 24205 Wh, inTime: 1)
2025.05.28 23:20:59.294 1: SolCast DEBUG> Bat 01 relLoad 29 09 -> 0 (SoCfc: 74.0 % / 21024 Wh, whneed: 7392, pvfc: 3767, tompvfc: 33926, tomconfc: 12686, SurpDay: 21240 Wh, inTime: 1)
2025.05.28 23:20:59.295 1: SolCast DEBUG> Bat 01 relLoad 29 10 -> 0 (SoCfc: 74.0 % / 21024 Wh, whneed: 7392, pvfc: 4000, tompvfc: 29926, tomconfc: 11984, SurpDay: 17942 Wh, inTime: 1)
2025.05.28 23:20:59.295 1: SolCast DEBUG> Bat 01 relLoad 29 11 -> 0 (SoCfc: 74.0 % / 21024 Wh, whneed: 7392, pvfc: 4247, tompvfc: 25679, tomconfc: 10751, SurpDay: 14928 Wh, inTime: 1)
2025.05.28 23:20:59.295 1: SolCast DEBUG> Bat 01 relLoad 29 12 -> 0 (SoCfc: 74.0 % / 21024 Wh, whneed: 7392, pvfc: 4145, tompvfc: 21534, tomconfc: 9929, SurpDay: 11605 Wh, inTime: 1)
2025.05.28 23:20:59.296 1: SolCast DEBUG> Bat 01 relLoad 29 13 -> 1 (SoCfc: 85.5 % / 24285 Wh, whneed: 7392, pvfc: 4687, tompvfc: 16847, tomconfc: 8865, SurpDay: 7982 Wh, inTime: 1)
2025.05.28 23:20:59.296 1: SolCast DEBUG> Bat 01 relLoad 29 14 -> 1 (SoCfc: 98.6 % / 28017 Wh, whneed: 4131, pvfc: 4903, tompvfc: 11944, tomconfc: 8109, SurpDay: 3835 Wh, inTime: 1)
2025.05.28 23:20:59.297 1: SolCast DEBUG> Bat 01 relLoad 29 15 -> 1 (SoCfc: 100.0 % / 28416 Wh, whneed: 399, pvfc: 4417, tompvfc: 7527, tomconfc: 7309, SurpDay: 218 Wh, inTime: 1)
2025.05.28 23:20:59.297 1: SolCast DEBUG> Bat 01 relLoad 29 16 -> 1 (SoCfc: 100.0 % / 28416 Wh, whneed: 0, pvfc: 3098, tompvfc: 4429, tomconfc: 6651, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.297 1: SolCast DEBUG> Bat 01 relLoad 29 17 -> 1 (SoCfc: 100.0 % / 28416 Wh, whneed: 0, pvfc: 2151, tompvfc: 2278, tomconfc: 6081, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.298 1: SolCast DEBUG> Bat 01 relLoad 29 18 -> 1 (SoCfc: 100.0 % / 28416 Wh, whneed: 0, pvfc: 1780, tompvfc: 498, tomconfc: 5439, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.298 1: SolCast DEBUG> Bat 01 relLoad 29 19 -> 1 (SoCfc: 99.0 % / 28137 Wh, whneed: 0, pvfc: 413, tompvfc: 85, tomconfc: 4775, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.298 1: SolCast DEBUG> Bat 01 relLoad 29 20 -> 1 (SoCfc: 96.8 % / 27505 Wh, whneed: 279, pvfc: 85, tompvfc: 0, tomconfc: 4121, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.299 1: SolCast DEBUG> Bat 01 relLoad 29 21 -> 1 (SoCfc: 94.2 % / 26775 Wh, whneed: 911, pvfc: 0, tompvfc: 0, tomconfc: 4121, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.299 1: SolCast DEBUG> Bat 01 relLoad 29 22 -> 1 (SoCfc: 91.5 % / 26003 Wh, whneed: 1641, pvfc: 0, tompvfc: 0, tomconfc: 4121, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:20:59.299 1: SolCast DEBUG> Bat 01 relLoad 29 23 -> 1 (SoCfc: 88.9 % / 25272 Wh, whneed: 2413, pvfc: 0, tompvfc: 0, tomconfc: 4121, SurpDay: 0 Wh, inTime: 1)
Et voilà:
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Inverter 'BKW_800' cap: 800 W, Power limit: 100 % -> Pmax eff: 800 W
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Inverter 'Fronius_Symo_Gen24' cap: 6000 W, Power limit: 100 % -> Pmax eff: 6000 W
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Inverter 'BKW_600' cap: 600 W, Power limit: 100 % -> Pmax eff: 600 W
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 7400 W
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 Charge Rcmd - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 10240 Wh, Percentage of total capacity: 100.0 %
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 28 23 -> 1 (CurrSoc: 67.1 %, SoCfc: 6849 Wh, whneed: 3369, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, CurrPV: 1 W, CurrCons: 388 W, Limit: 7400 W, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 00 -> 1 (SoCfc: 66.8 % / 6840 Wh, whneed: 3391, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 01 -> 1 (SoCfc: 66.7 % / 6831 Wh, whneed: 3400, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 02 -> 1 (SoCfc: 66.5 % / 6810 Wh, whneed: 3409, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 03 -> 1 (SoCfc: 66.4 % / 6801 Wh, whneed: 3430, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 04 -> 1 (SoCfc: 66.3 % / 6792 Wh, whneed: 3439, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 05 -> 1 (SoCfc: 66.3 % / 6791 Wh, whneed: 3448, pvfc: 41, tompvfc: 40448, tomconfc: 14474, SurpDay: 25974 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 06 -> 1 (SoCfc: 67.2 % / 6881 Wh, whneed: 3449, pvfc: 502, tompvfc: 39946, tomconfc: 14072, SurpDay: 25874 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 07 -> 1 (SoCfc: 70.6 % / 7228 Wh, whneed: 3359, pvfc: 1035, tompvfc: 38911, tomconfc: 13423, SurpDay: 25488 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 08 -> 1 (SoCfc: 83.8 % / 8576 Wh, whneed: 3012, pvfc: 2696, tompvfc: 36215, tomconfc: 12225, SurpDay: 23990 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 09 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 1664, pvfc: 3609, tompvfc: 32606, tomconfc: 11181, SurpDay: 21425 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 10 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 3626, tompvfc: 28980, tomconfc: 9920, SurpDay: 19060 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 11 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 3170, tompvfc: 25810, tomconfc: 8594, SurpDay: 17216 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 12 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 6621, tompvfc: 19189, tomconfc: 7341, SurpDay: 11848 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 13 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 4999, tompvfc: 14190, tomconfc: 6196, SurpDay: 7994 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 14 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 3804, tompvfc: 10386, tomconfc: 5103, SurpDay: 5283 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 15 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 6497, tompvfc: 3889, tomconfc: 4063, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 16 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 2332, tompvfc: 1557, tomconfc: 3095, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 17 -> 1 (SoCfc: 99.1 % / 10152 Wh, whneed: 0, pvfc: 864, tompvfc: 693, tomconfc: 2152, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 18 -> 1 (SoCfc: 94.0 % / 9625 Wh, whneed: 88, pvfc: 316, tompvfc: 377, tomconfc: 1362, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 19 -> 1 (SoCfc: 91.2 % / 9341 Wh, whneed: 615, pvfc: 317, tompvfc: 60, tomconfc: 789, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 20 -> 1 (SoCfc: 88.1 % / 9018 Wh, whneed: 899, pvfc: 60, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 21 -> 1 (SoCfc: 87.9 % / 9000 Wh, whneed: 1222, pvfc: 0, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 22 -> 1 (SoCfc: 87.8 % / 8990 Wh, whneed: 1240, pvfc: 0, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 23 -> 1 (SoCfc: 87.6 % / 8968 Wh, whneed: 1250, pvfc: 0, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Inverter 'BKW_800' cap: 800 W, Power limit: 100 % -> Pmax eff: 800 W
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Inverter 'Fronius_Symo_Gen24' cap: 6000 W, Power limit: 100 % -> Pmax eff: 6000 W
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Inverter 'BKW_600' cap: 600 W, Power limit: 100 % -> Pmax eff: 600 W
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat XX Charge Rcmd - Summary Power limit of all Inverter (except feed 'grid'): 7400 W
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 Charge Rcmd - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 Charge Rcmd - Installed Battery capacity: 10240 Wh, Percentage of total capacity: 100.0 %
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 Charge Rcmd - The PV generation, consumption and surplus listed below are based on the battery's share of the total capacity!
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 28 23 -> 1 (CurrSoc: 67.1 %, SoCfc: 6849 Wh, whneed: 3369, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, CurrPV: 1 W, CurrCons: 441 W, Limit: 7400 W, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 00 -> 1 (SoCfc: 66.8 % / 6840 Wh, whneed: 3391, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 01 -> 1 (SoCfc: 66.7 % / 6831 Wh, whneed: 3400, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 02 -> 1 (SoCfc: 66.5 % / 6810 Wh, whneed: 3409, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 03 -> 1 (SoCfc: 66.4 % / 6801 Wh, whneed: 3430, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 04 -> 1 (SoCfc: 66.3 % / 6792 Wh, whneed: 3439, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 05 -> 1 (SoCfc: 66.3 % / 6791 Wh, whneed: 3448, pvfc: 41, tompvfc: 40448, tomconfc: 14474, SurpDay: 25974 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 06 -> 1 (SoCfc: 67.2 % / 6881 Wh, whneed: 3449, pvfc: 502, tompvfc: 39946, tomconfc: 14072, SurpDay: 25874 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 07 -> 1 (SoCfc: 70.6 % / 7228 Wh, whneed: 3359, pvfc: 1035, tompvfc: 38911, tomconfc: 13423, SurpDay: 25488 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 08 -> 1 (SoCfc: 83.8 % / 8576 Wh, whneed: 3012, pvfc: 2696, tompvfc: 36215, tomconfc: 12225, SurpDay: 23990 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 09 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 1664, pvfc: 3609, tompvfc: 32606, tomconfc: 11181, SurpDay: 21425 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 10 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 3626, tompvfc: 28980, tomconfc: 9920, SurpDay: 19060 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 11 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 3170, tompvfc: 25810, tomconfc: 8594, SurpDay: 17216 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 12 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 6621, tompvfc: 19189, tomconfc: 7341, SurpDay: 11848 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 13 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 4999, tompvfc: 14190, tomconfc: 6196, SurpDay: 7994 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 14 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 3804, tompvfc: 10386, tomconfc: 5103, SurpDay: 5283 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 15 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 6497, tompvfc: 3889, tomconfc: 4063, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 16 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 0, pvfc: 2332, tompvfc: 1557, tomconfc: 3095, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 17 -> 1 (SoCfc: 99.1 % / 10152 Wh, whneed: 0, pvfc: 864, tompvfc: 693, tomconfc: 2152, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 18 -> 1 (SoCfc: 94.0 % / 9625 Wh, whneed: 88, pvfc: 316, tompvfc: 377, tomconfc: 1362, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 19 -> 1 (SoCfc: 91.2 % / 9341 Wh, whneed: 615, pvfc: 317, tompvfc: 60, tomconfc: 789, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 20 -> 1 (SoCfc: 88.1 % / 9018 Wh, whneed: 899, pvfc: 60, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 21 -> 1 (SoCfc: 87.9 % / 9000 Wh, whneed: 1222, pvfc: 0, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 22 -> 1 (SoCfc: 87.8 % / 8990 Wh, whneed: 1240, pvfc: 0, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:43 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 23 -> 1 (SoCfc: 87.6 % / 8968 Wh, whneed: 1250, pvfc: 0, tompvfc: 0, tomconfc: 438, SurpDay: 0 Wh, inTime: 1)
Sieht alles ok aus. Du siehst den prognostizierten Verlauf (SoCfc in %) in Anbhängigkeit der Erzeugung (pvfc) und des erwarteteten Verbrauchs (tomconfc Differenz von Stunde zu Stunde).
Morgen früh
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 08 -> 1 (SoCfc: 83.8 % / 8576 Wh, whneed: 3012, pvfc: 2696, tompvfc: 36215, tomconfc: 12225, SurpDay: 23990 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 09 -> 1 (SoCfc: 100.0 % / 10240 Wh, whneed: 1664, pvfc: 3609, tompvfc: 32606, tomconfc: 11181, SurpDay: 21425 Wh, inTime: 1)
soll der Soc bei 83,8% Anfang 08 Uhr stehen, Ende 09 Uhr dann bei 100% da 3609 Wh Erzeugung und nur ein Ladebedarf von 1664 Wh erwartet wird. Der Verbrauch liegt in der Stunde bei ca. 1000Wh. Das passt alles soweit.
LG,
Heiko
Ok, aber es stimmt ja leider nicht. Der Verbrauch ist ja tatsächlich höher so dass der SoC morgens immer niedriger als prognostiziert ist. Das komische ist ja, dass die Prognose bislang immer einigermaßen gepasst hat (gefühlt bis zum Update auf 1.52.4) und es plötzlich nicht mehr tut. Um das scheinbar falsch gelernte zurückzusetzen kann/soll ich einen 'restet consumptionHistory' machen? Oder gibt es da eine andere Herangehensweise?
Guten Morgen
@Wolle02,
wenn ich es richtig interpretieren sind deine Verbrauchsvorhersagen zu niedrig. Deswegen wird zu wenig Batteriebezug kalkuliert was dann diese Auswirkung bzgl. Batterie SoC hat.
Bei genaueren Hinsehen sieht man es auch z.B. hier:
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 00 -> 1 (SoCfc: 66.8 % / 6840 Wh, whneed: 3391, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 01 -> 1 (SoCfc: 66.7 % / 6831 Wh, whneed: 3400, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 02 -> 1 (SoCfc: 66.5 % / 6810 Wh, whneed: 3409, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
2025.05.28 23:34:13 1: PV_Vorhersage DEBUG> Bat 01 relLoad 29 03 -> 1 (SoCfc: 66.4 % / 6801 Wh, whneed: 3430, pvfc: 0, tompvfc: 40489, tomconfc: 14516, SurpDay: 0 Wh, inTime: 1)
Wenn man whneed zwischen den Stunden vergleicht, kommt man auf geringe Steigerungen 3391 -> 3400 = 8Wh, 3400 -> 3409 = 9Wh.
Hier wäre m.M. nach anzusetzen.
Ein gesetzes ctrlDebug=consumption_long zeigt dir die Liste der Erwartungen:
2025.05.29 08:04:23.251 1: SolCast DEBUG> ################### Start Consumption forecast ###################
2025.05.29 08:04:23.251 1: SolCast DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.05.29 08:04:23.251 1: SolCast DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.05.29 08:04:23.252 1: SolCast DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.05.29 08:04:23.253 1: SolCast DEBUG> estimated cons of Hour 01: 536 Wh, Considered value numbers: 8
2025.05.29 08:04:23.253 1: SolCast DEBUG> estimated cons of Hour 02: 480 Wh, Considered value numbers: 8
2025.05.29 08:04:23.253 1: SolCast DEBUG> estimated cons of Hour 03: 458 Wh, Considered value numbers: 8
2025.05.29 08:04:23.253 1: SolCast DEBUG> estimated cons of Hour 04: 479 Wh, Considered value numbers: 8
2025.05.29 08:04:23.254 1: SolCast DEBUG> estimated cons of Hour 05: 500 Wh, Considered value numbers: 8
2025.05.29 08:04:23.254 1: SolCast DEBUG> estimated cons of Hour 06: 510 Wh, Considered value numbers: 8
2025.05.29 08:04:23.254 1: SolCast DEBUG> estimated cons of Hour 07: 554 Wh, Considered value numbers: 8
2025.05.29 08:04:23.254 1: SolCast DEBUG> estimated cons of Hour 08: 742 Wh, Considered value numbers: 8
2025.05.29 08:04:23.255 1: SolCast DEBUG> estimated cons of Hour 09: 676 Wh, Considered value numbers: 8
2025.05.29 08:04:23.255 1: SolCast DEBUG> estimated cons of Hour 10: 736 Wh, Considered value numbers: 8
2025.05.29 08:04:23.255 1: SolCast DEBUG> estimated cons of Hour 11: 700 Wh, Considered value numbers: 8
2025.05.29 08:04:23.256 1: SolCast DEBUG> estimated cons of Hour 12: 1163 Wh, Considered value numbers: 8
2025.05.29 08:04:23.256 1: SolCast DEBUG> estimated cons of Hour 13: 1030 Wh, Considered value numbers: 8
2025.05.29 08:04:23.256 1: SolCast DEBUG> estimated cons of Hour 14: 825 Wh, Considered value numbers: 8
2025.05.29 08:04:23.256 1: SolCast DEBUG> estimated cons of Hour 15: 899 Wh, Considered value numbers: 8
2025.05.29 08:04:23.256 1: SolCast DEBUG> estimated cons of Hour 16: 716 Wh, Considered value numbers: 8
2025.05.29 08:04:23.257 1: SolCast DEBUG> estimated cons of Hour 17: 600 Wh, Considered value numbers: 8
2025.05.29 08:04:23.257 1: SolCast DEBUG> estimated cons of Hour 18: 586 Wh, Considered value numbers: 8
2025.05.29 08:04:23.257 1: SolCast DEBUG> estimated cons of Hour 19: 594 Wh, Considered value numbers: 8
2025.05.29 08:04:23.257 1: SolCast DEBUG> estimated cons of Hour 20: 620 Wh, Considered value numbers: 8
2025.05.29 08:04:23.258 1: SolCast DEBUG> estimated cons of Hour 21: 632 Wh, Considered value numbers: 8
2025.05.29 08:04:23.258 1: SolCast DEBUG> estimated cons of Hour 22: 676 Wh, Considered value numbers: 8
2025.05.29 08:04:23.258 1: SolCast DEBUG> estimated cons of Hour 23: 678 Wh, Considered value numbers: 8
2025.05.29 08:04:23.258 1: SolCast DEBUG> estimated cons of Hour 24: 660 Wh, Considered value numbers: 8
2025.05.29 08:04:23.259 1: SolCast DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.05.29 08:04:23.259 1: SolCast DEBUG> estimated cons Tomorrow: 15442 Wh, Individual hourly values considered: 192, exclude: 0 Wh (avg of 0 entities)
2025.05.29 08:04:23.259 1: SolCast DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.05.29 08:04:23.260 1: SolCast DEBUG> store 'NextHour00' hod '09' confc: 676, confcEx: 676
2025.05.29 08:04:23.260 1: SolCast DEBUG> store circular/history hod '09' confc: 676
2025.05.29 08:04:23.260 1: SolCast DEBUG> store 'NextHour01' hod '10' confc: 736, confcEx: 736
2025.05.29 08:04:23.260 1: SolCast DEBUG> store circular/history hod '10' confc: 736
2025.05.29 08:04:23.261 1: SolCast DEBUG> store 'NextHour02' hod '11' confc: 700, confcEx: 700
2025.05.29 08:04:23.261 1: SolCast DEBUG> store circular/history hod '11' confc: 700
2025.05.29 08:04:23.261 1: SolCast DEBUG> store 'NextHour03' hod '12' confc: 1163, confcEx: 1163
2025.05.29 08:04:23.262 1: SolCast DEBUG> store circular/history hod '12' confc: 1163
2025.05.29 08:04:23.262 1: SolCast DEBUG> store 'NextHour04' hod '13' confc: 1030, confcEx: 1030
2025.05.29 08:04:23.262 1: SolCast DEBUG> store circular/history hod '13' confc: 1030
2025.05.29 08:04:23.262 1: SolCast DEBUG> store 'NextHour05' hod '14' confc: 825, confcEx: 825
2025.05.29 08:04:23.263 1: SolCast DEBUG> store circular/history hod '14' confc: 825
2025.05.29 08:04:23.263 1: SolCast DEBUG> store 'NextHour06' hod '15' confc: 899, confcEx: 899
2025.05.29 08:04:23.263 1: SolCast DEBUG> store circular/history hod '15' confc: 899
2025.05.29 08:04:23.264 1: SolCast DEBUG> store 'NextHour07' hod '16' confc: 716, confcEx: 716
2025.05.29 08:04:23.264 1: SolCast DEBUG> store circular/history hod '16' confc: 716
2025.05.29 08:04:23.264 1: SolCast DEBUG> store 'NextHour08' hod '17' confc: 600, confcEx: 600
2025.05.29 08:04:23.265 1: SolCast DEBUG> store circular/history hod '17' confc: 600
2025.05.29 08:04:23.265 1: SolCast DEBUG> store 'NextHour09' hod '18' confc: 586, confcEx: 586
2025.05.29 08:04:23.265 1: SolCast DEBUG> store circular/history hod '18' confc: 586
2025.05.29 08:04:23.266 1: SolCast DEBUG> store 'NextHour10' hod '19' confc: 594, confcEx: 594
2025.05.29 08:04:23.266 1: SolCast DEBUG> store circular/history hod '19' confc: 594
2025.05.29 08:04:23.266 1: SolCast DEBUG> store 'NextHour11' hod '20' confc: 620, confcEx: 620
2025.05.29 08:04:23.266 1: SolCast DEBUG> store circular/history hod '20' confc: 620
2025.05.29 08:04:23.267 1: SolCast DEBUG> store 'NextHour12' hod '21' confc: 632, confcEx: 632
2025.05.29 08:04:23.267 1: SolCast DEBUG> store circular/history hod '21' confc: 632
2025.05.29 08:04:23.267 1: SolCast DEBUG> store 'NextHour13' hod '22' confc: 676, confcEx: 676
2025.05.29 08:04:23.267 1: SolCast DEBUG> store circular/history hod '22' confc: 676
2025.05.29 08:04:23.268 1: SolCast DEBUG> store 'NextHour14' hod '23' confc: 678, confcEx: 678
2025.05.29 08:04:23.268 1: SolCast DEBUG> store circular/history hod '23' confc: 678
2025.05.29 08:04:23.268 1: SolCast DEBUG> store 'NextHour15' hod '24' confc: 660, confcEx: 660
2025.05.29 08:04:23.269 1: SolCast DEBUG> store circular/history hod '24' confc: 660
2025.05.29 08:04:23.269 1: SolCast DEBUG> store 'NextHour16' hod '01' confc: 536, confcEx: 536
2025.05.29 08:04:23.269 1: SolCast DEBUG> store 'NextHour17' hod '02' confc: 480, confcEx: 480
2025.05.29 08:04:23.269 1: SolCast DEBUG> store 'NextHour18' hod '03' confc: 458, confcEx: 458
2025.05.29 08:04:23.270 1: SolCast DEBUG> store 'NextHour19' hod '04' confc: 479, confcEx: 479
2025.05.29 08:04:23.270 1: SolCast DEBUG> store 'NextHour20' hod '05' confc: 500, confcEx: 500
2025.05.29 08:04:23.270 1: SolCast DEBUG> store 'NextHour21' hod '06' confc: 510, confcEx: 510
2025.05.29 08:04:23.271 1: SolCast DEBUG> store 'NextHour22' hod '07' confc: 554, confcEx: 554
2025.05.29 08:04:23.271 1: SolCast DEBUG> store 'NextHour23' hod '08' confc: 742, confcEx: 742
2025.05.29 08:04:23.271 1: SolCast DEBUG> store 'NextHour24' hod '09' confc: 676, confcEx: 676
2025.05.29 08:04:23.271 1: SolCast DEBUG> store 'NextHour25' hod '10' confc: 736, confcEx: 736
2025.05.29 08:04:23.272 1: SolCast DEBUG> store 'NextHour26' hod '11' confc: 700, confcEx: 700
2025.05.29 08:04:23.272 1: SolCast DEBUG> store 'NextHour27' hod '12' confc: 1163, confcEx: 1163
2025.05.29 08:04:23.272 1: SolCast DEBUG> store 'NextHour28' hod '13' confc: 1030, confcEx: 1030
2025.05.29 08:04:23.272 1: SolCast DEBUG> store 'NextHour29' hod '14' confc: 825, confcEx: 825
2025.05.29 08:04:23.273 1: SolCast DEBUG> store 'NextHour30' hod '15' confc: 899, confcEx: 899
2025.05.29 08:04:23.273 1: SolCast DEBUG> store 'NextHour31' hod '16' confc: 716, confcEx: 716
2025.05.29 08:04:23.273 1: SolCast DEBUG> store 'NextHour32' hod '17' confc: 600, confcEx: 600
2025.05.29 08:04:23.273 1: SolCast DEBUG> store 'NextHour33' hod '18' confc: 586, confcEx: 586
2025.05.29 08:04:23.274 1: SolCast DEBUG> store 'NextHour34' hod '19' confc: 594, confcEx: 594
2025.05.29 08:04:23.274 1: SolCast DEBUG> store 'NextHour35' hod '20' confc: 620, confcEx: 620
2025.05.29 08:04:23.274 1: SolCast DEBUG> store 'NextHour36' hod '21' confc: 632, confcEx: 632
2025.05.29 08:04:23.275 1: SolCast DEBUG> store 'NextHour37' hod '22' confc: 676, confcEx: 676
2025.05.29 08:04:23.275 1: SolCast DEBUG> store 'NextHour38' hod '23' confc: 678, confcEx: 678
2025.05.29 08:04:23.275 1: SolCast DEBUG> store 'NextHour39' hod '24' confc: 660, confcEx: 660
2025.05.29 08:04:23.276 1: SolCast DEBUG> consumption calculated - day: 29, hod: 09, con: 25 Wh
2025.05.29 08:04:23.276 1: SolCast DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 1640 Wh
Vllt. sehen wir hier was Sache ist.
LG,
Heiko
Hier ist das DebugLog:
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> ################### Start Consumption forecast ###################
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> Basics - installed locale: de_DE.UTF-8, used scheme: DE
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> process Today dayname: Do, Tomorrow dayname: Fr
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> ################### Consumption forecast for the next Hours (new median) ###################
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 01: 8 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 02: 8 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 03: 18 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 04: 8 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 05: 8 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 06: 40 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 07: 401 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 08: 630 Wh, Considered value numbers: 34
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 09: 1198 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 10: 1044 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 11: 1261 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 12: 1326 Wh, Considered value numbers: 32
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 13: 1253 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 14: 1145 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 15: 1093 Wh, Considered value numbers: 31
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 16: 1040 Wh, Considered value numbers: 32
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 17: 968 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 18: 943 Wh, Considered value numbers: 32
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 19: 790 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 20: 573 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 21: 351 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 22: 16 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 23: 9 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons of Hour 24: 20 Wh, Considered value numbers: 33
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> ################### Consumption forecast for the next day (new median) ###################
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> estimated cons Tomorrow: 14496 Wh, Individual hourly values considered: 1440, exclude: 0 Wh (avg of 0 entities)
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> ################### Store Consumption forecast values (new median) ###################
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour00' hod '09' confc: 1198, confcEx: 1198
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '09' confc: 1198
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour01' hod '10' confc: 1044, confcEx: 1044
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '10' confc: 1044
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour02' hod '11' confc: 1261, confcEx: 1261
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '11' confc: 1261
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour03' hod '12' confc: 1326, confcEx: 1326
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '12' confc: 1326
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour04' hod '13' confc: 1253, confcEx: 1253
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '13' confc: 1253
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour05' hod '14' confc: 1145, confcEx: 1145
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '14' confc: 1145
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour06' hod '15' confc: 1093, confcEx: 1093
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '15' confc: 1093
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour07' hod '16' confc: 1040, confcEx: 1040
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '16' confc: 1040
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour08' hod '17' confc: 968, confcEx: 968
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '17' confc: 968
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour09' hod '18' confc: 943, confcEx: 943
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '18' confc: 943
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour10' hod '19' confc: 790, confcEx: 790
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '19' confc: 790
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour11' hod '20' confc: 573, confcEx: 573
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '20' confc: 573
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour12' hod '21' confc: 351, confcEx: 351
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '21' confc: 351
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour13' hod '22' confc: 16, confcEx: 16
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '22' confc: 16
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour14' hod '23' confc: 9, confcEx: 9
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '23' confc: 9
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour15' hod '24' confc: 20, confcEx: 20
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store circular/history hod '24' confc: 20
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour16' hod '01' confc: 8, confcEx: 8
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour17' hod '02' confc: 8, confcEx: 8
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour18' hod '03' confc: 18, confcEx: 18
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour19' hod '04' confc: 8, confcEx: 8
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour20' hod '05' confc: 8, confcEx: 8
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour21' hod '06' confc: 40, confcEx: 40
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour22' hod '07' confc: 401, confcEx: 401
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour23' hod '08' confc: 630, confcEx: 630
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour24' hod '09' confc: 1198, confcEx: 1198
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour25' hod '10' confc: 1044, confcEx: 1044
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour26' hod '11' confc: 1261, confcEx: 1261
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour27' hod '12' confc: 1326, confcEx: 1326
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour28' hod '13' confc: 1253, confcEx: 1253
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour29' hod '14' confc: 1145, confcEx: 1145
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour30' hod '15' confc: 1093, confcEx: 1093
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour31' hod '16' confc: 1040, confcEx: 1040
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour32' hod '17' confc: 968, confcEx: 968
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour33' hod '18' confc: 943, confcEx: 943
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour34' hod '19' confc: 790, confcEx: 790
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour35' hod '20' confc: 573, confcEx: 573
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour36' hod '21' confc: 351, confcEx: 351
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour37' hod '22' confc: 16, confcEx: 16
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour38' hod '23' confc: 9, confcEx: 9
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> store 'NextHour39' hod '24' confc: 20, confcEx: 20
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> consumption calculated - day: 29, hod: 09, con: 881 Wh
2025.05.29 08:44:57 1: PV_Vorhersage DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 1648 Wh
So wie ich das sehe sind in den Nachtstunden die "cons" immer viel zu wenig. Meine Dauerverbraucher verursachen bei mir eine permanente Grundlast von ca. 350 W
ZitatSo wie ich das sehe sind in den Nachtstunden die "cons" immer viel zu wenig.
Ja genau, das ist der Grund für die Auswirkung.
Wie ist denn deine Einstellung plantControl->consForecastIdentWeekdays und plantControl->consForecastLastDays?
Zitat von: DS_Starter am 29 Mai 2025, 09:21:29Wie ist denn deine Einstellung plantControl->consForecastIdentWeekdays und plantControl->consForecastLastDays?
Ah, ich glaube jetzt kommt Licht ins Dunkel. Beide Werte habe ich nicht gesetzt; stehen also auf Defaultwerten.
bei consForecastIdentWeekdays ist das 0
bei consForecastLastDays ist das 60
Wenn natürlich 60 Tage in die Prognose mit einfließen kann das wahrscheinlich nicht stimmen, weil ich so lange die Anlage ja noch gar nicht in Betrieb habe.
Ich verstehe nur nicht, warum es dann vorher gepasst hatte.
ZitatIch verstehe nur nicht, warum es dann vorher gepasst hatte.
Das kann ich dir auch nicht beantworten. Dazu hätten wir einen Vergleich des Debugs benötigt.
Aber wenn du die Parameter entsprechend des Bedarfs anpasst (mit dem Debug die Verbrauchsprognose gegenprüfen) sollte es passen.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 28 Mai 2025, 21:14:15da steckt noch ein Fehler drin:
setupInverterDev01 PV pvOut=SPOT_PACTOT:W etotal=SPOT_ETOTAL:Wh capacity=7500
Danke, jetzt passt es wieder.
LG Christoph
Bei der Sichtung der technischen Unterlagen von BAT-Herstellen, stößt man immer wieder einmal darauf, dass die Ladeleistung gegen Ende eines Ladevorgangs nicht zu gering sein sollte. Diese Empfehlung ist dadurch begründet, dass die einzelnen Zellen einer BAT nicht zu lange eine zu hohe Spannung haben sollten. Immerhin wird die Ladung BAT-seitig ja erst unterbrochen, wenn die Ladeschlussspannung erreicht ist. Nun frage ich mich, ob es in SF irgendwo eine Stelle gibt, bei der diese minimale Ladeleistung berücksichtigt wird. Insbesondere in Richtung Herbst/Winter/Frühjahr guckend, wäre eine derartige Berücksichtigung, z.B. im Kontext der Berechnung der von SF ausgesprochenen Ladeempfehlung, sinnvoll. Ist obiges ggf. schon in SF drin und wurde von mir nur übersehen?
Hey zusammen,
da ich das Update gesehen habe, wollte ich mich auch mal wieder melden.
Ich gehe davon aus, dass ist für die von mir mal erwähnte Konstellation mit Modulen -> Akku -> Wechselrichter -> Hausnetz?
Leider habe ich mir auch nach mehrmaligem lesen immer noch keinen Reim darauf machen können.
Ich habe folgende Geräte/Readings in FHEM:
Akku: noah_mqtt (Alles DC)
Readings:
BAT0_soc = Ladezustand Batterie in %
charge_w = wie viel wird die Batterie gerade geladen in W
discharge_w = entladen in W
generation_today_kwh
output_w = was geht von der Batterie zum WR in W
solar_w = was liefern die Module aktuell in W
WR: httpmod_ab_garage_wechselrichter (Alles DC)
Readings:
gesamt_W = was kommt von der Batterie zum WR bzw geht ins Haus in W
Modul1/2_W = was liefert die Batterie auf String 1/2 zum WR
gesamt_heute_kWh = was wurde heute in kWh über den WR ans Haus gegeben.
gesamt_kWh = gesamt über den WR gelaufen in kWh
Ich habe keine Messsteckdose oder so in diesem System. Daher kenne ich den wirklichen AC Wert nicht. Testweise habe ich einen Shelly dazwischen gehangen aber der zieht natürlich den Eigenverbrauch auch mit ab. Die Werte dessen, lasse ich jetzt mal weg.
Ich kann jedenfalls kein Gerät anlegen mit den neuen Werten, da diese in unterschiedlichen Geräten sitzen. Jetzt müsste ich diese innerhalb von FHEM übertragen in das andere oder einen Dummy erstellen. Das halte ich aber für OP.
Aktuell für BatteryDev01: noah_mqtt pin=charge_w:W pout=discharge_w:W pinmax=1800 poutmax=800 cap=2048 charge=soc
Aktuell für InverterDev01: noah_mqtt pvOut=solar_w:W capacity=1800 feed=bat etotal=generation_total_kwh:kWh
Einer der Versuche für InverterDev01: httpmod_ab_garage_wechselrichter pvOut=gesamt_W:W capacity=800 etotal=gesamt_kWh:kWh
Ich habe ein wenig rum gespielt aber nichts hinbekommen was so ist, wie die Realität.
Mit dem gezeigtem Versuch bekomme ich zwar auch die Ladung/Entladung angezeigt aber nicht die Werte, die wirklich an den Modulen anliegen. Mehrere Geräte anlegen geht auch nicht, dann ist die Grafik falsch. Ich sehe den Wald vor lauter Bäumen nicht. Kann mir jemand einen Tipp geben?
Gruß,
Kai
Zitat von: 87insane am 30 Mai 2025, 12:32:37...
Ich habe ein wenig rum gespielt aber nichts hinbekommen was so ist, wie die Realität.
Mit dem gezeigtem Versuch bekomme ich zwar auch die Ladung/Entladung angezeigt aber nicht die Werte, die wirklich an den Modulen anliegen. Mehrere Geräte anlegen geht auch nicht, dann ist die Grafik falsch. Ich sehe den Wald vor lauter Bäumen nicht. Kann mir jemand einen Tipp geben?
...
Wenn Du mehrere Geräte an einem reinen Aktor betreibst (also ohne Messfunktion) betreibst, dann kann FHEM natürlich nicht wissen, welche Leistung die einzelnen Geräte zur Arbeit brauchen. Es bleibt also eine Unsicherheit, die Du ggf. dadurch reduzieren könntest, indem Du die minimale Last, die am Aktor hängt, mit diesem in Verbindung bringt. Dann weiß FHEM vom Ein- bis zum Ausschalten, dass diese Leistung mindestens vom Gerät bezogen wird.
PS: Du schreibst, dass Module am Aktor hängen. Du meinst aber doch nicht PV-Module, oder?
Irgendwie spielen bei mir jetzt die Werte für Prognose und Realität verrückt. Nachdem sich die Batterieprognose für die Entladung in der Nacht leider weiter nicht mehr einpendelt, sondern immer keine Entladung anzeigt, sehen jetzt auch die realen PV-Werte komisch aus. Zur Erläuterung siehe das Bild unten.
Seit heute Mittag ist bei uns strahlender Sonnenschein. Ich habe um 13.30 Uhr das Auto an die Wallbox gehängt. In der Stunde 13 blieb daraufhin der Wert für die reale PV-Erzeugung "hängen" und wurde in der Stunde 14 dann "draufgerechnet". Stunde 15 war dann normal und in Stunde 16 und 17 dann das gleiche Spiel.
So toll und komplex das Modul auch ist fällt es mir etwas schwer einen richtigen Ansatzpunkt für das Debugging zu finden. Bislang hat beim Autoladen alles richtig gezählt; in der Summe stimmt es zwar so ungefähr aber so soll das doch bestimmt nicht sein.
Internals:
FUUID 680c772c-f33f-bf2d-3af4-85ab080ffea54d30
FVERSION 76_SolarForecast.pm:v1.52.5-s29997/2025-05-25
LCACHEFILE last write time: 17:31:26 File: ./FHEM/FhemUtils/PVCsm_SolarForecast_PV_Vorhersage
MODE Automatic / Event-controlled - next planned Cycletime: 17:40:35
MODEL OpenMeteoDWDEnsembleAPI
NAME PV_Vorhersage
NOTIFYDEV Hausstromzaehler,Shelly_Waschmaschine,openWB_Ladepunkt,Shelly_Keller_Luftentfeuchter,Shelly_Fernseher,Shelly_Trockner,Shelly_IT,Shelly_Backofen,Shelly_Microwelle,Shelly_Spuelmaschine,PV_Batterie,BKW_800,Fronius_Symo_Gen24,BKW_600
NR 595
NTFY_ORDER 50-PV_Vorhersage
STATE updated
TYPE SolarForecast
WEATHERMODEL OpenMeteoDWDEnsembleAPI
eventCount 5961
HELPER:
FW WEB
PACKAGE FHEM::SolarForecast
S10DONE 1
SPGDETAIL
SPGDEV PV_Vorhersage
SPGROOM System->System
VERSION 1.52.5
VERSION_API unused
VERSION_CTZ 1.0.0
VERSION_ErrCodes 1.3.9
VERSION_SMUtils 1.28.3
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 16803
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:181067
telnet telnetForBlockingFn_1748536697.28551_127.0.0.1_52810
terminated 1
timeout 30
abortArg:
arg:
block 1
name PV_Vorhersage
tsnext 1748624386.70922
Helper:
DBLOG:
Current_AutarkyRate:
logdb:
TIME 1748615928.15819
VALUE 100
OLDREADINGS:
READINGS:
2025-04-30 12:00:12 Battery_ChargeRecommended_01 1
2025-05-30 17:40:06 Consumption_total 494346.422217193
2025-05-30 16:38:47 Current_AutarkyRate 100 %
2025-05-30 17:37:05 Current_BatCharge_01 98.0 %
2025-05-30 17:40:06 Current_Consumption 2906 W
2025-05-30 17:36:05 Current_GridConsumption 0 W
2025-05-30 17:40:06 Current_GridFeedIn 197 W
2025-05-30 17:39:36 Current_PV 3108 W
2025-05-30 17:37:05 Current_PowerBatIn_01 5 W
2025-05-30 11:12:57 Current_PowerBatOut_01 0 W
2025-05-30 17:40:06 Current_SelfConsumption 2906 W
2025-05-30 17:40:06 Current_SelfConsumptionRate 94 %
2025-05-30 17:40:06 Current_Surplus 202 W
2025-05-30 17:00:00 LastHourGridconsumptionReal 23 Wh
2025-05-30 17:00:00 LastHourPVforecast 4522 Wh
2025-05-30 17:00:00 LastHourPVreal 1712 Wh
2025-05-30 17:40:06 NextHours_Sum01_PVforecast 3035 Wh
2025-05-30 17:40:06 NextHours_Sum02_PVforecast 5147 Wh
2025-05-30 17:40:06 NextHours_Sum03_PVforecast 6149 Wh
2025-05-30 17:40:06 NextHours_Sum04_ConsumptionForecast 2001 Wh
2025-05-30 17:40:06 NextHours_Sum04_PVforecast 6342 Wh
2025-05-30 17:40:06 RestOfDayConsumptionForecast 2029 Wh
2025-05-30 17:40:06 RestOfDayPVforecast 6343 Wh
2025-05-30 00:00:05 Today_Hour01_BatIn_01 0 Wh
2025-05-30 00:00:05 Today_Hour01_BatOut_01 0 Wh
2025-05-30 00:45:28 Today_Hour01_GridConsumption 3 Wh
2025-05-30 00:00:13 Today_Hour01_GridFeedIn 0 Wh
2025-05-30 00:00:05 Today_Hour01_PVreal 0 Wh
2025-05-30 01:00:01 Today_Hour02_BatIn_01 0 Wh
2025-05-30 01:00:01 Today_Hour02_BatOut_01 0 Wh
2025-05-30 01:57:10 Today_Hour02_GridConsumption 5 Wh
2025-05-30 01:00:01 Today_Hour02_GridFeedIn 0 Wh
2025-05-30 01:00:01 Today_Hour02_PVreal 0 Wh
2025-05-30 02:00:06 Today_Hour03_BatIn_01 0 Wh
2025-05-30 02:00:06 Today_Hour03_BatOut_01 0 Wh
2025-05-30 02:49:45 Today_Hour03_GridConsumption 3 Wh
2025-05-30 02:51:45 Today_Hour03_GridFeedIn 1 Wh
2025-05-30 02:00:06 Today_Hour03_PVreal 0 Wh
2025-05-30 03:00:05 Today_Hour04_BatIn_01 0 Wh
2025-05-30 03:00:05 Today_Hour04_BatOut_01 0 Wh
2025-05-30 03:59:49 Today_Hour04_GridConsumption 5 Wh
2025-05-30 03:00:05 Today_Hour04_GridFeedIn 0 Wh
2025-05-30 03:00:05 Today_Hour04_PVreal 0 Wh
2025-05-30 04:00:06 Today_Hour05_BatIn_01 0 Wh
2025-05-30 04:00:06 Today_Hour05_BatOut_01 0 Wh
2025-05-30 04:59:25 Today_Hour05_GridConsumption 4 Wh
2025-05-30 04:56:24 Today_Hour05_GridFeedIn 1 Wh
2025-05-30 04:00:06 Today_Hour05_PVreal 0 Wh
2025-05-30 05:00:07 Today_Hour06_BatIn_01 0 Wh
2025-05-30 05:00:07 Today_Hour06_BatOut_01 0 Wh
2025-05-30 05:56:59 Today_Hour06_GridConsumption 7 Wh
2025-05-30 05:48:51 Today_Hour06_GridFeedIn 3 Wh
2025-05-30 00:00:44 Today_Hour06_PVforecast 74 Wh
2025-05-30 05:59:30 Today_Hour06_PVreal 20 Wh
2025-05-30 06:00:01 Today_Hour07_BatIn_01 0 Wh
2025-05-30 06:00:01 Today_Hour07_BatOut_01 0 Wh
2025-05-30 06:45:54 Today_Hour07_GridConsumption 5 Wh
2025-05-30 06:33:16 Today_Hour07_GridFeedIn 2 Wh
2025-05-30 00:00:44 Today_Hour07_PVforecast 560 Wh
2025-05-30 06:59:35 Today_Hour07_PVreal 245 Wh
2025-05-30 07:00:06 Today_Hour08_BatIn_01 0 Wh
2025-05-30 07:00:06 Today_Hour08_BatOut_01 0 Wh
2025-05-30 07:58:15 Today_Hour08_GridConsumption 6 Wh
2025-05-30 07:58:15 Today_Hour08_GridFeedIn 1 Wh
2025-05-30 00:00:44 Today_Hour08_PVforecast 1796 Wh
2025-05-30 07:59:49 Today_Hour08_PVreal 1169 Wh
2025-05-30 08:31:04 Today_Hour09_BatIn_01 1 Wh
2025-05-30 08:00:11 Today_Hour09_BatOut_01 0 Wh
2025-05-30 08:56:56 Today_Hour09_GridConsumption 8 Wh
2025-05-30 08:55:54 Today_Hour09_GridFeedIn 4 Wh
2025-05-30 00:00:05 Today_Hour09_PVforecast 2866 Wh
2025-05-30 08:59:51 Today_Hour09_PVreal 3269 Wh
2025-05-30 09:35:55 Today_Hour10_BatIn_01 1 Wh
2025-05-30 09:00:03 Today_Hour10_BatOut_01 0 Wh
2025-05-30 09:57:26 Today_Hour10_GridConsumption 22 Wh
2025-05-30 09:59:51 Today_Hour10_GridFeedIn 222 Wh
2025-05-30 08:37:08 Today_Hour10_PVforecast 3717 Wh
2025-05-30 09:59:51 Today_Hour10_PVreal 3906 Wh
2025-05-30 10:00:07 Today_Hour11_BatIn_01 0 Wh
2025-05-30 10:00:07 Today_Hour11_BatOut_01 0 Wh
2025-05-30 10:19:27 Today_Hour11_GridConsumption 12 Wh
2025-05-30 10:59:49 Today_Hour11_GridFeedIn 1480 Wh
2025-05-30 08:37:08 Today_Hour11_PVforecast 4506 Wh
2025-05-30 10:59:45 Today_Hour11_PVreal 3961 Wh
2025-05-30 11:00:08 Today_Hour12_BatIn_01 0 Wh
2025-05-30 11:00:08 Today_Hour12_BatOut_01 0 Wh
2025-05-30 11:00:08 Today_Hour12_GridConsumption 0 Wh
2025-05-30 11:59:49 Today_Hour12_GridFeedIn 3240 Wh
2025-05-30 08:37:08 Today_Hour12_PVforecast 4802 Wh
2025-05-30 11:59:20 Today_Hour12_PVreal 4684 Wh
2025-05-30 12:00:06 Today_Hour13_BatIn_01 0 Wh
2025-05-30 12:00:06 Today_Hour13_BatOut_01 0 Wh
2025-05-30 12:00:06 Today_Hour13_GridConsumption 0 Wh
2025-05-30 12:59:50 Today_Hour13_GridFeedIn 3970 Wh
2025-05-30 08:37:08 Today_Hour13_PVforecast 4738 Wh
2025-05-30 12:59:34 Today_Hour13_PVreal 5199 Wh
2025-05-30 13:00:05 Today_Hour14_BatIn_01 0 Wh
2025-05-30 13:00:05 Today_Hour14_BatOut_01 0 Wh
2025-05-30 13:00:05 Today_Hour14_GridConsumption 0 Wh
2025-05-30 13:59:41 Today_Hour14_GridFeedIn 2217 Wh
2025-05-30 08:37:08 Today_Hour14_PVforecast 5534 Wh
2025-05-30 13:59:41 Today_Hour14_PVreal 2974 Wh
2025-05-30 14:00:09 Today_Hour15_BatIn_01 0 Wh
2025-05-30 14:00:09 Today_Hour15_BatOut_01 0 Wh
2025-05-30 14:31:47 Today_Hour15_GridConsumption 1 Wh
2025-05-30 14:59:33 Today_Hour15_GridFeedIn 152 Wh
2025-05-30 14:25:09 Today_Hour15_PVforecast 4971 Wh
2025-05-30 14:59:49 Today_Hour15_PVreal 6900 Wh
2025-05-30 15:00:04 Today_Hour16_BatIn_01 0 Wh
2025-05-30 15:00:04 Today_Hour16_BatOut_01 0 Wh
2025-05-30 15:17:22 Today_Hour16_GridConsumption 7 Wh
2025-05-30 15:58:58 Today_Hour16_GridFeedIn 76 Wh
2025-05-30 00:00:44 Today_Hour16_PVforecast 5104 Wh
2025-05-30 15:59:50 Today_Hour16_PVreal 4478 Wh
2025-05-30 16:00:03 Today_Hour17_BatIn_01 0 Wh
2025-05-30 16:00:03 Today_Hour17_BatOut_01 0 Wh
2025-05-30 16:53:30 Today_Hour17_GridConsumption 23 Wh
2025-05-30 16:59:47 Today_Hour17_GridFeedIn 123 Wh
2025-05-30 14:25:09 Today_Hour17_PVforecast 4522 Wh
2025-05-30 16:59:47 Today_Hour17_PVreal 1712 Wh
2025-05-30 17:00:16 Today_Hour18_BatIn_01 0 Wh
2025-05-30 17:00:16 Today_Hour18_BatOut_01 0 Wh
2025-05-30 17:00:16 Today_Hour18_GridConsumption 0 Wh
2025-05-30 17:40:06 Today_Hour18_GridFeedIn 83 Wh
2025-05-30 14:25:09 Today_Hour18_PVforecast 3855 Wh
2025-05-30 17:40:06 Today_Hour18_PVreal 5016 Wh
2025-05-30 14:25:09 Today_Hour19_PVforecast 2655 Wh
2025-05-30 14:25:09 Today_Hour20_PVforecast 1861 Wh
2025-05-30 14:25:09 Today_Hour21_PVforecast 604 Wh
2025-05-30 00:00:44 Today_Hour22_PVforecast 3 Wh
2025-05-30 08:37:38 Today_MaxPVforecast 5534 Wh
2025-05-30 00:01:13 Today_MaxPVforecastTime 2025-05-30 13:00:00
2025-05-30 17:40:06 Today_PVdeviation 4.91 %
2025-05-30 14:25:09 Today_PVforecast 52168 Wh
2025-05-30 17:40:06 Today_PVreal 43533 Wh
2025-05-30 00:00:05 Today_SunRise 05:26
2025-05-30 00:00:05 Today_SunSet 21:15
2025-05-30 17:00:25 Tomorrow_ConsumptionForecast 15579 Wh
2025-05-30 17:00:25 Tomorrow_PVforecast 33961 Wh
2025-05-30 00:00:05 Tomorrow_SunRise 05:25
2025-05-30 00:00:05 Tomorrow_SunSet 21:16
2025-05-30 15:54:25 consumer01 name='Waschmaschine' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 11:19:43 consumer01_currentPower 0 W
2025-05-30 13:30:17 consumer02 name='Wallbox' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 17:40:06 consumer02_currentPower 1808.48 W
2025-05-30 17:39:05 consumer03 name='Luftentfeuchter' state='on' mode='can' planningstate='started' info='swoncond nicht erfüllt'
2025-05-30 17:40:06 consumer03_currentPower 435.7 W
2025-05-30 17:31:26 consumer03_planned_start 30.05.2025 17:31:24
2025-05-30 17:31:26 consumer03_planned_stop 30.05.2025 20:15:00
2025-05-30 12:41:45 consumer04 name='Fernseher' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 17:39:05 consumer04_currentPower 123 W
2025-05-30 08:49:23 consumer05 name='Trockner' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 08:52:24 consumer05_currentPower 0 W
2025-05-30 12:41:45 consumer06 name='IT' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 17:40:06 consumer06_currentPower 113.4 W
2025-05-30 12:41:45 consumer07 name='Backofen' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 17:39:05 consumer07_currentPower 0.6 W
2025-05-30 15:23:56 consumer08 name='Microwelle' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 17:39:36 consumer08_currentPower 0.6 W
2025-05-30 13:21:35 consumer09 name='Spülmaschine' state='on' mode='can' planningstate='noSchedule' info='von extern umgeschaltet'
2025-05-30 17:38:05 consumer09_currentPower 0 W
2025-05-30 17:40:06 nextCycletime 17:40:35
2025-05-30 17:30:19 nextRadiationAPICall nach 30.05.2025 17:45:53
2025-05-30 06:00:01 pvCorrectionFactor_06 0.36 (automatic - old factor: 0.43, Sun Alt range: 0, Cloud range: 00, Days in range: 9)
2025-05-30 07:00:06 pvCorrectionFactor_07 0.55 (automatic - old factor: 0.64, Sun Alt range: 10, Cloud range: 00, Days in range: 2)
2025-05-30 08:00:11 pvCorrectionFactor_08 0.65 (automatic - old factor: 1.00, Sun Alt range: 20, Cloud range: 00, Days in range: 1)
2025-05-30 09:00:03 pvCorrectionFactor_09 1.14 (automatic - old factor: 1.00, Sun Alt range: 30, Cloud range: 35, Days in range: 1)
2025-05-30 10:00:07 pvCorrectionFactor_10 1.05 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 30, Days in range: 1)
2025-05-30 11:00:08 pvCorrectionFactor_11 0.88 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 20, Days in range: 1)
2025-05-30 12:00:06 pvCorrectionFactor_12 0.96 (automatic - old factor: 0.94, Sun Alt range: 55, Cloud range: 00, Days in range: 6)
2025-05-30 13:00:05 pvCorrectionFactor_13 0.95 (automatic - old factor: 0.87, Sun Alt range: 60, Cloud range: 00, Days in range: 8)
2025-05-30 14:00:09 pvCorrectionFactor_14 0.54 (automatic - old factor: 1.00, Sun Alt range: 65, Cloud range: 00, Days in range: 1)
2025-05-30 15:00:04 pvCorrectionFactor_15 0.93 (automatic - old factor: 0.90, Sun Alt range: 60, Cloud range: 00, Days in range: 4)
2025-05-30 16:00:03 pvCorrectionFactor_16 0.88 (automatic - old factor: 1.00, Sun Alt range: 55, Cloud range: 00, Days in range: 1)
2025-05-30 17:00:16 pvCorrectionFactor_17 0.38 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 00, Days in range: 1)
2025-05-22 19:34:48 pvCorrectionFactor_Auto on_complex
2025-05-30 17:40:17 state updated
Attributes:
DbLogExclude .*
DbLogInclude Current_AutarkyRate
consumer01 Shelly_Waschmaschine:Waschmaschine type=noSchedule power=2000 icon=scene_washing_machine pcurr=power:W etotal=energy_total:Wh
consumer02 openWB_Ladepunkt:Wallbox type=noSchedule power=3000 icon=wallbox swstate=charge_state:true:false pcurr=cp_power:W etotal=cp_imported_overall:Wh
consumer03 Shelly_Keller_Luftentfeuchter:Luftentfeuchter type=other power=540 pcurr=power:W etotal=energy_total:Wh icon=Ventilator_wind on=on off=off swstate=state:on:off mintime=SunPath:120:-60 interruptable=1 locktime=1800 swoncond=TH_Sensor_innen_Keller:humidity:{ReadingsNum("TH_Sensor_innen_Keller","humidity",0)>=65} swoffcond=TH_Sensor_innen_Keller:humidity:{ReadingsNum("TH_Sensor_innen_Keller","humidity",0)<=56}
consumer04 Shelly_Fernseher:Fernseher type=noSchedule power=120 icon=it_television pcurr=power:W etotal=energy_total:Wh
consumer05 Shelly_Trockner:Trockner type=noSchedule power=0 icon=scene_laundry_room_fem pcurr=power:W etotal=energy_total:Wh
consumer06 Shelly_IT:IT type=noSchedule power=0 icon=it_nas pcurr=power:W etotal=energy_total:Wh
consumer07 Shelly_Backofen:Backofen type=noSchedule power=0 icon=scene_baking_oven pcurr=power:W:3 etotal=energy_total:Wh:3
consumer08 Shelly_Microwelle:Microwelle type=noSchedule power=0 icon=scene_microwave_oven pcurr=power:W:1 etotal=energy_total:Wh:1
consumer09 Shelly_Spuelmaschine:Spülmaschine type=noSchedule power=0 icon=scene_dishwasher pcurr=power:W:1 etotal=energy_total:Wh:1
ctrlDebug none
event-on-change-reading .*
flowGraphicControl homenodedyncol=1
graphicBeam3Content batsocCombi_01
graphicHeaderOwnspec #
PV_Erzeugung_heute:pv_daily_exported@openWB_Ladepunkt
Autarkierate:Current_AutarkyRate
graphicHeaderOwnspecValForm { 'pv_daily_exported' => "(sprintf '%.1f kWh', ($VALUE / 1000))",
}
graphicHistoryHour 5
group Fronius
plantControl cycleInterval=30 consForecastLastDays=30 showLink=1 genPVdeviation=continuously
room Haustechnik->Energie
setupBatteryDev01 PV_Batterie pin=BatteryChargeWatt:W pout=BatteryDischargeWatt:W cap=10240 intotal=Summe_Ladung:Wh outtotal=Summe_Entladung:Wh charge=BatteryChargePercent show=2
setupInverterDev01 BKW_800 capacity=800 etotal=energy_total:Wh pvOut=power:W strings=BKW_West
setupInverterDev02 Fronius_Symo_Gen24 etotal=User_Produced_PV:kWh pvOut=PowerFlow_Site_P_PV:W capacity=6000 strings=Dach_Ost,Dach_West
setupInverterDev03 BKW_600 capacity=600 etotal=energy_total:Wh pvOut=power:W strings=BKW_Ost
setupInverterStrings Dach_Ost,Dach_West,BKW_Ost,BKW_West
setupMeterDev Hausstromzaehler gcon=power:W contotal=overall_consumption:Wh gfeedin=-gcon:W feedtotal=overall_feed:Wh
setupRadiationAPI OpenMeteoDWDEnsemble-API
setupStringAzimuth Dach_Ost=E Dach_West=W BKW_Ost=E BKW_West=W
setupStringDeclination Dach_Ost=40 Dach_West=40 BKW_Ost=15 BKW_West=90
setupStringPeak Dach_Ost=3.22 Dach_West=3.22 BKW_Ost=0.72 BKW_West=0.92
setupWeatherDev1 OpenMeteoDWDEnsemble-API
timestamp-on-change-reading .*
userReadings Consumption_total:Current_Consumption.* integral {ReadingsNum("$name","Current_Consumption","0")/3600}
Hallo Heiko,
ich habe mir während der Regentage nochmal die initial PV-Forecast-Einträge im DB-Log näher angesehen. ich glaube, da gibt es eine Verschiebung um 24 h. Heißt, die Werte für den aktuellen Tag werden für den nächsten Tag eingetragen. Kannst Du da nochmal nachschauen.
Noch eine Bitte. Ich hatte fälschlicher Weise angegeben, dass ich die Werte mit "steps" anzeige. Tatsächlich sind es jedoch "fsteps" denn die Linie muss schon am vorherigen Werte nach oben oder unten gehen. Sonst wird die letzte Stunde immer nur als senkrechter Strich angezeigt und der Querbalken behält den Wert der vorherigen Stunde. Man bräuchte allerdings bei "fsteps" tatsächlich einen "0"-Eintrag in der Stunde vor dem Sonnenaufgang, sonst zieht sich der erste Initial-Forecast Querbalken von der 0 Stunden bis zum Sonnenaufgang.
Ich hoffe, ich konnte es nachvollziehbar erklären.
Gruß
tupol
Zitat von: Wolle02 am 30 Mai 2025, 18:00:52...
Seit heute Mittag ist bei uns strahlender Sonnenschein. Ich habe um 13.30 Uhr das Auto an die Wallbox gehängt. In der Stunde 13 blieb daraufhin der Wert für die reale PV-Erzeugung "hängen" und wurde in der Stunde 14 dann "draufgerechnet". Stunde 15 war dann normal und in Stunde 16 und 17 dann das gleiche Spiel.
So toll und komplex das Modul auch ist fällt es mir etwas schwer einen richtigen Ansatzpunkt für das Debugging zu finden. Bislang hat beim Autoladen alles richtig gezählt; in der Summe stimmt es zwar so ungefähr aber so soll das doch bestimmt nicht sein.
Habe hier immer mal wieder ein sehr ähnliches Problem. Bei mir liegt's eindeutig daran, dass mein Goodwe immer mal wieder keine Verbindung via Modbus-UDP zulässt und SF daher von einer PV-Leistung = 0 ausgehen muss. Da SF aber nicht auf Leistungen, sondern Energiemengen arbeitet, tauchen die - sofern der Wechselrichter nicht ausgeschaltet ist - in der Grafik noch auf, aber natürlich erst dann, wenn wieder ein Kontakt zu ihm hergestellt werden kann.
Hallo Parallix,
ZitatBei der Sichtung der technischen Unterlagen von BAT-Herstellen, stößt man immer wieder einmal darauf, dass die Ladeleistung gegen Ende eines Ladevorgangs nicht zu gering sein sollte. ...
Nun frage ich mich, ob es in SF irgendwo eine Stelle gibt, bei der diese minimale Ladeleistung berücksichtigt wird. Insbesondere in Richtung Herbst/Winter/Frühjahr guckend, wäre eine derartige Berücksichtigung, z.B. im Kontext der Berechnung der von SF ausgesprochenen Ladeempfehlung, sinnvoll. Ist obiges ggf. schon in SF drin und wurde von mir nur übersehen?
Die Ladeempfehlung im Modul ist auf ein möglichst gutes Gleichgewicht von Einspeisung und Batterieladung ausgerichtet um möglichst keine Erzeugungsbegrenzung bei Berücksichtigung eines evtl. Enspeiselimits zu erfahren und dennoch möglichst viel Ladung, bestenfalls 100%) in die Batterie zu bekommen. Im Normalfall bei relativ geringer Erzeugungsprognose wird das entsprechende Reading immer 1 sein.
D.h. auch, wenn die Batterie fast oder ganz voll ist, wird dieses Reading 1 sein = Ladeempfehlung.
Wie genau der User seine Batterien steuert, mit wieviel Leistung geladen wird etc., ist dem User überlassen. Das Modul greift nicht direkt in die Batterie oder deren Logik ein.
Zitat von: DS_Starter am 30 Mai 2025, 19:46:42...
Im Normalfall bei relativ geringer Erzeugungsprognose wird das entsprechende Reading immer 1 sein.
D.h. auch, wenn die Batterie fast oder ganz voll ist, wird dieses Reading 1 sein = Ladeempfehlung.
Wie genau der User seine Batterien steuert, mit wieviel Leistung geladen wird etc., ist dem User überlassen. Das Modul greift nicht direkt in die Batterie oder deren Logik ein.
Es ist ja auch gut, dass man eine feinere Steuerung außerhalb machen kann und auch sollte! Da es aber bei faktisch allen BAT-Systemen o.g. Mindestleistung bzw. ein ausbauabhängigen Mindeststrom (Termination Current) gibt, hatte ich vorgeschlagen, auf der (groben) Ebene der SF-Ladeempfehlung o.g. Mindestleistung zu berücksichtigen, um damit letztlich alle marktverfügbaren BAT-Systeme zu schützen. Hierzu müsste die Ladeempfehlung ja "nur" dann nicht gegeben werden, wenn der BAT-SOC eine konfigurierbare Grenze über- und die Ladeleistung eine konfigurierbare Grenze unterschreitet. Dies nur zu Erläuterung, warum dieses Feature eine absolut sinnvolle Erweiterung der bisherigen Funktionalität von SF wäre.
Edit: Da es im Grunde bei allen BAT-Systemen darum geht, das Ausreißen einer Zelle (nach oben) zeitlich nicht dadurch zu verlängern, dass man das System mit einer sehr geringen Leistung weiter läd, müsste man sich in SF wohl doch etwas mehr ansehen, als nur den SOC, nämlich die Zellspannungen. Damit wäre man aber weit außerhalb von SF. Insofern stimme ich Dir bei nochmaliger Betrachtung des Problems zu, möchte aber anregen, dass im SF-Wiki auf vorgenannten, BAT-schädigenden Sachverhalt hingewiesen wird. Wäre das eine gute Lösung?
@Parallix,
vllt. habe die Thematik noch nicht verstanden. Bei meinen Pylontech/Victron habe ich auch noch nichts davon gelesen, möglicherweise steckt es in dem BMS drin und für mich nicht transparent.
Wenn ich dich richtig verstanden habe, sollte das entsprechende Reading "0" werden, wenn
- ein bestimmter oberer SoC erreicht ist UND
- der gemessene Ladestrom bzw. Ladeleistung in die Batterie eine bestimmte Grenze unterschreitet.
Ist das rechtig zusammengefasst?
Ich wäre davon ausgegangen, dass die BMS die Einhaltung solcher Grenzwerte beachten und entsprechend steuernd eingreifen.
Zitat von: DS_Starter am 30 Mai 2025, 20:23:13@Parallix,
vllt. habe die Thematik noch nicht verstanden. Bei meinen Pylontech/Victron habe ich auch noch nichts davon gelesen, möglicherweise steckt es in dem BMS drin und für mich nicht transparent.
Wenn ich dich richtig verstanden habe, sollte das entsprechende Reading "0" werden, wenn
- ein bestimmter oberer SoC erreicht ist ODER
- der gemessene Ladestrom bzw. Ladeleistung in die Batterie eine bestimmte Grenze unterschreitet.
Ist das rechtig zusammengefasst?
Ich wäre davon ausgegangen, dass die BMS die Einhaltung solcher Grenzwerte beachten und entsprechend steuernd eingreifen.
In Deiner Zusammenfassung hätte statt "oder" ein "und" stehen müssen. Ansonsten ist alles richtig zusammengefasst. Habe meinen Beitrag oben noch etwas hinzugefügt, was sich Du wahrscheinlich beim Schreiben nicht gesehen hast. Sorry für das späte Edit.
PS: Meinerseits gehe ich nicht davon aus, dass das BMS das gewünschte leisten kann. Grund: Es müsste wissen, ob, wie lange und wieviel PV-Leistung noch kommt. Das wiederum kann eigentlich nur SF.
Ok, verstanden. Würde ich vorsehen.
Solche Sachverhalte im Wiki zu ergänzen ist eine gute Lösung. Da ich mich mit genau dieser Thematik noch nicht befasst habe kannst du mir gern per PN einen Text schreiben den ich dann im Wiki passend einfüge.
LG
@Kai,
du könntest dir im noah_mqtt per userReadings den Wert aus dem httpmod_ab_garage_wechselrichter in ein Reading im noah_mqtt abbilden. Wenn noah_mqtt seine Daten aktualisiert, trigerst du mit einem passenden Reading das/die userReadings. Die Readingwerte holst du mit
ReadingsNum ('httpmod_ab_garage_wechselrichter', 'gesamt_W', 0)
So kannst du dir alle benötigten Werte zusammenstellen und ggf. auch noch manipulieren bei Bedarf. Dann brauchst du auch keinen Dummy.
LG,
Heiko
@Wolle02,
in deinem Setup fehlt noch plantControl->consForecastIdentWeekdays=1 in Verbindung mit plantControl->consForecastLastDays=4. Im Wiki (http://192.168.2.71:32771/index.php/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_die_Verbrauchsprognose_erstellt?) habe ich den Zusammenhang erläutert.
Die Verbrauchsprognose mit solchen leistungsstarken Verbrauchern die unregelmäßig verwendet werden und auch nicht durch SF geplant werden, ist sehr schwierig. Hatte ich schonmal erwähnt.
Möglicherweise hilft dir beim consumer02 openWB_Ladepunkt:Wallbox zusätzlich exconfc=1 zu setzen.
LG,
Heiko
@tupol,
es werden kurz nach Mitternacht die in NextHours enthaltenen Werte für pvfc entsprechend der starttime als Events abgebildet. D.h je nachdem wieviele Daten in NextHours enthalten sind, werden die Daten des laufenden Tages und die Daten des folgenden Tages in Events geliefert. Du kannst mit geeigneten Mitteln diese beiden Werte vergleichen.
Die Sache bzgl. fsteps schaue ich mir an.
LG,
Heiko
@Wolle02,
in meinem contrib liegt die V 1.52.7.
Das exclude/include bzgl. Verbrauchern mit exconfc in Abhängigkeit der gesetzten Parameter plantControl->consForecastIdentWeekdays / plantControl->consForecastLastDays ist verbessert.
Lade dir bitte die V in dein System und restarte FHEM.
Danach kannst du experimentieren ob deine Verbrauchvorhersage mit oder ohne die Parameter plantControl->consForecastIdentWeekdays=1 / plantControl->consForecastLastDays=4 bessere Ergebnisse bringt.
Andere User können die V in diesem Kontext natürlich auch gern mal testen.
LG,
Heiko
Hallo,
irgendwie bekomme ich das mit dem netzdienlichen Laden per ctrlUserExitFN nicht hin.
z.Zt. ist Battery_ChargeRecommended_01 = 0, aber die Batterie wird munter weiter geladen. Bei SF verbose 3 erscheint im Log dauernd
2025.05.31 09:58:24 3: Sonnenschein - userFn -> Batteryload STP8SE => not activ - BatIn01 3297.66 BatOut01 0Stelle ich die Batterieladung im Modbus Device händisch ab, so wird Sie von SF wieder eingeschaltet. Irgendwas falsch im ctrlUserExitFN ?
{
# BEGIN ######## Netzdienliches Laden ################
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
my $timestart = 8; # ab welcher Uhrzeit soll es sein ===>> Wert evtl. anpassen
my $timeend = 16; # bis wieviel Uhr soll es sein ===>> Wert evtl. anpassen
if (int $hour >= $timestart && int $hour < $timeend ) {
# Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
my $curpowerbatin01 = ReadingsNum ($name, 'Current_PowerBatIn_01', 0);
my $curpowerbatout01 = ReadingsNum ($name, 'Current_PowerBatOut_01', 0);
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); # SoC Bat01 aktuell
my $currentsurplus = (ReadingsNum ($name, 'Current_Surplus', 0) - 50); # etwas abziehen zwecks weniger als Puffer
my $batchargerequest01 = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0); # Batterie01 muss geladen werden ?
my $gridfriendlychargebat01 = ReadingsNum ($name, 'Battery_ChargeRecommended_01', 0); # Batterie01 recommended ?
my $curbatchargemin01= 30; # erst ab Mindes-BAT01-SOC XY netzdienlich ===>> Wert evtl. anpassen 0..30
my $bwr01 = "STP8SE"; # Name des 1ten BWR-Modbus-Device ===>> Wert evtl. anpassen
if (int $gridfriendlychargebat01 eq 0) {
# Nur wenn die Batterieladung01 SF-Systemseitig nicht empfohlen wird dann
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended Battery01 $gridfriendlychargebat01 });
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); # SoC Bat01 aktuell
if (int $gridfriendlychargebat01 eq 0 && $batchargerequest01 eq 0 && $curbatcharge01 > $curbatchargemin01) {
# wenn bei Bat01 = 0 -beides- und SOC groß genug ->>dann unterbinden Laden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended only Battery01 Reading = $gridfriendlychargebat01 });
fhem("set $bwr01 $currentsurplus"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
else {
if (int $gridfriendlychargebat01 eq 1 || $batchargerequest01 eq 1 || (($curbatcharge01 - 3) <= $curbatchargemin01)) {
# wenn bei Bat01 = beides oder nur eins auf 1 steht ---dann bitte jetzt Steuerung aus / kein Laden unterbinden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended =>> Battery01 Reading = $gridfriendlychargebat01 and BatChargerequest =>> Battery01 Reading = $batchargerequest01 });
fhem("set $bwr01 Set_Leistung 0"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> Batteryload $bwr01 => not activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
}
}
}
# ENDE ######## Netzdienliches Laden ################
}Wo soll ich suchen?
Vielen Dank
oelidoc
Zitat von: Parallix am 30 Mai 2025, 17:14:40Zitat von: 87insane am 30 Mai 2025, 12:32:37...
Ich habe ein wenig rum gespielt aber nichts hinbekommen was so ist, wie die Realität.
Mit dem gezeigtem Versuch bekomme ich zwar auch die Ladung/Entladung angezeigt aber nicht die Werte, die wirklich an den Modulen anliegen. Mehrere Geräte anlegen geht auch nicht, dann ist die Grafik falsch. Ich sehe den Wald vor lauter Bäumen nicht. Kann mir jemand einen Tipp geben?
...
Die Module hängen an dem Speicher. Und der Speicher am Wechselrichter. Das ist aktuell häufig so, da man so die 800W ein wenig austricksen kann.
Der Akku hat einen Eingang bis zu 1800W. Ich kann also die volle Power der Module nutzen um zu laden und Energie ins Haus zu speisen.
Wenn Du mehrere Geräte an einem reinen Aktor betreibst (also ohne Messfunktion) betreibst, dann kann FHEM natürlich nicht wissen, welche Leistung die einzelnen Geräte zur Arbeit brauchen. Es bleibt also eine Unsicherheit, die Du ggf. dadurch reduzieren könntest, indem Du die minimale Last, die am Aktor hängt, mit diesem in Verbindung bringt. Dann weiß FHEM vom Ein- bis zum Ausschalten, dass diese Leistung mindestens vom Gerät bezogen wird.
PS: Du schreibst, dass Module am Aktor hängen. Du meinst aber doch nicht PV-Module, oder?
Hallo oelidoc,
bei deiner Funktion habe ich einige syntaktische und auch logische Fehler gesehen. Bei den logischen Fehlern bin ich mir nicht ganz sicher, weil ich deine Batterieanlage nicht kenne und nicht weiß welche Befehle welche Auswirkung haben.
Aber ich habe deine Funktion mal so umgeschrieben wie ich denke dass es richtig sein müßte:
{
# BEGIN ######## Netzdienliches Laden ################
my $dt = timestringsFromOffset (time, 0);
my $hour = $dt->{hour}; # aktuelle Stunde in 24h format (00-23)
my $timestart = 8; # ab welcher Uhrzeit soll es sein ===>> Wert evtl. anpassen
my $timeend = 16; # bis wieviel Uhr soll es sein ===>> Wert evtl. anpassen
if (int $hour >= $timestart && int $hour < $timeend ) { # Nur zwischen xy:00 bis max. xy:59 (!!!! $timeend -1 Stunde !!!!) Uhr
my $curpowerbatin01 = ReadingsNum ($name, 'Current_PowerBatIn_01', 0);
my $curpowerbatout01 = ReadingsNum ($name, 'Current_PowerBatOut_01', 0);
my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); # SoC Bat01 aktuell
my $currentsurplus = (ReadingsNum ($name, 'Current_Surplus', 0) - 50); # etwas abziehen zwecks weniger als Puffer
my $batchargerequest01 = ReadingsNum ($name, 'Battery_ChargeRequest_01', 0); # Batterie01 muss geladen werden ?
my $chargerecommended01 = ReadingsNum ($name, 'Battery_ChargeRecommended_01', 0); # Batterie01 recommended ?
my $curbatchargemin01= 30; # erst ab Mindes-BAT01-SOC XY netzdienlich ===>> Wert evtl. anpassen 0..30
my $bwr01 = "STP8SE"; # Name des 1ten BWR-Modbus-Device ===>> Wert evtl. anpassen
if (!$chargerecommended01) { # Nur wenn die Batterieladung01 SF-Systemseitig nicht empfohlen wird dann
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended Battery01 $chargerecommended01 });
if (!$batchargerequest01 && $curbatcharge01 > $curbatchargemin01) {
# wenn bei Bat01 = 0 -beides- und SOC groß genug ->>dann unterbinden Laden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended only Battery01 Reading = $chargerecommended01 });
fhem("set $bwr01 $currentsurplus"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 802"); # 802 - Steuerung aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> BatteryControl $bwr01 => activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
elsif ($batchargerequest01 || $curbatcharge01 - 3 <= $curbatchargemin01) {
# wenn bei Bat01 = beides oder nur eins auf 1 steht ---dann bitte jetzt Steuerung aus / kein Laden unterbinden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended =>> Battery01 Reading = $chargerecommended01 and BatChargerequest =>> Battery01 Reading = $batchargerequest01 });
fhem("set $bwr01 Set_Leistung 0"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> BatteryControl $bwr01 => not activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
}
elsif ($chargerecommended01 || $batchargerequest01 || $curbatcharge01 - 3 <= $curbatchargemin01) {
# wenn bei Bat01 = beides oder nur eins auf 1 steht ---dann bitte jetzt Steuerung aus / kein Laden unterbinden Bat01
Log3 ($name, 5, qq{$name - userFn -> Gridfriendlyloadrecommended =>> Battery01 Reading = $chargerecommended01 and BatChargerequest =>> Battery01 Reading = $batchargerequest01 });
fhem("set $bwr01 Set_Leistung 0"); # Watt Netzleistung am Übergabemesspunkt (WR1)
fhem("set $bwr01 Set_Aktiv 803"); # 803 - Steuerung nicht aktiv (WR1)
Log3 ($name, 3, qq{$name - userFn -> BatteryControl $bwr01 => not activ - BatIn01 $curpowerbatin01 BatOut01 $curpowerbatout01 });
}
}
# ENDE ######## Netzdienliches Laden ################
}
Hier noch ein paar Erläuterungen in knapper Form:
- int $chargerecommended01 eq 0: numerischer Vergleich mit "eq" falsch , also entweder $chargerecommended01 == 0 oder viel einfacher
!$chargerecommended01 -> logisch "false"
- das 2. my $curbatcharge01 = CurrentVal ($name, 'Current_BatCharge_01', 0); wird nicht gebraucht da schon vorher gelesen
- if (int $chargerecommended01 eq 0 && $batchargerequest01 eq 0 && $curbatcharge01 > $curbatchargemin01) { ->
- das int $chargerecommended01 eq 0 braucht man nicht da Eintritt in Funktion schon vorher mit !$chargerecommended01 definiert
- $batchargerequest01 eq 0 als !$batchargerequest01 schreiben
- int $chargerecommended01 eq 1 -> gleiches Thema wie schon geschrieben, inumerischer Vergleich mit "eq" falsch,
deswegen $chargerecommended01 == 1 oder einfach $chargerecommended01 -> logisch "true"
- $batchargerequest01 eq 1 -> wie schon geschrieben -> $batchargerequest01 == 1 oder besser/einfacher nur $batchargerequest01
LG,
Heiko
@87insane,
du hast nur zitiert aber nichts geschrieben. ;)
Zitat von: tupol am 30 Mai 2025, 19:04:21ich habe mir während der Regentage nochmal die initial PV-Forecast-Einträge im DB-Log näher angesehen. ich glaube, da gibt es eine Verschiebung um 24 h. Heißt, die Werte für den aktuellen Tag werden für den nächsten Tag eingetragen. Kannst Du da nochmal nachschauen.
Wenn ich die heutige Prognose anschaue, würde ich diese Vermutung bestätigen.
Es fiel mir schon auf, dass sich die aktuelle Vorhersage manchmal nicht so Recht mit der Initialen Tagesvorhersage deckt. Ich konnte mir nur keinen Reim darauf machen.
Gruß Heiko
P.S. Danke für das coole Modul!
Screenshot_20250531-183848_1.png
Hallo Heiko,
Zitat von: DS_Starter am 31 Mai 2025, 16:51:25bei deiner Funktion habe ich einige syntaktische und auch logische Fehler gesehen. Bei den logischen Fehlern bin ich mir nicht ganz sicher, weil ich deine Batterieanlage nicht kenne und nicht weiß welche Befehle welche Auswirkung haben.
Aber ich habe deine Funktion mal so umgeschrieben wie ich denke dass es richtig sein müßte:
Vielen Dank für deine Korrekturen! Werde ich morgen so anwenden.
Wie ich woanders schon schrieb hab ich den Code ja von 300P, der einen anderen Wechselrichter hat. Beim SunnyTripower8SE reicht es meiner Erfahrung nach Modbus SetLeistung auf 0 zusetzen und dann die Steuerung mit SetAktiv 802 ein- und mit 803 auszuschalten. Werde ich so versuchen.
Nochmals vielen Dank und schönes Wochenende
oelidoc
ZitatEs fiel mir schon auf, dass sich die aktuelle Vorhersage manchmal nicht so Recht mit der Initialen Tagesvorhersage deckt
Naja, das Wetter ist dynamisch und die Vorhersagen ändern sich ständig. ;)
Ich hatte es schonmal kontrolliert und konnte keinen Fehler feststellen. Aber man kann es so kontrolieren:
- kurz vor Mitternacht (oder so spät wie möglich) mit "get ... nextHours" die Werte für die kommenden Stunden ausgeben und z.B. in einem notepad++ speichern
- die Werte pvfc für jeden Stunde (starttime) sollten sich morgen für den morgigen Tag in der Datenbank mit Reading AllPVforecastsToEvent wiederfinden
Ich habe die Werte soeben auch gezogen und werden sie morgen mal vergleichen.
LG,
Heiko
Zitat von: oelidoc am 31 Mai 2025, 19:17:26Beim SunnyTripower8SE reicht es meiner Erfahrung nach Modbus SetLeistung auf 0 zusetzen und dann die Steuerung mit SetAktiv 802 ein- und mit 803 auszuschalten
Hallo oelidoc,
nach meinem Wissensstand muss das Schreiben zyklisch (20min) erfolgen - sonst stellt er sich wieder auf 803
Gruß Gerd
Hallo allerseits,
ich hätte mal eine Frage/Anmerkung zum Thema 'netztdienlicher Verbrauch'
1.) Hat sich jemand schon mal mit der API zur 'Stromampel' beschäftigt?
https://api.energy-charts.info/signal?country=de&postal_code=<PLZ>
Die liefert, in 15-min-Scheiben, die Zusammensetzung des Strommix im Grid auch verdichtet auf Signalen --> siehe beigefügter Screen. Die Infos sind vom Frauenhofer und anmeldefrei verfügbar.
2.) ist es möglich bzw. macht es Sinn diese Infos in SF mit zu integrieren?
Gruß Gerd
Hallo Gerd,
damit habe ich mich noch nicht beschäftigt.
Nach ein paar Minuten darüber nachdenken fällt mir keine sinnvolle Verwendung dafür in unserem Kontext ein.
Aber kann auch sein zu so später Stunde keine Aufnahmefähigkeit mehr zu haben.
Hast du etwas im Hinterkopf?
Grüße,
Heiko
Guten Morgen Heiko,
Zitat von: DS_Starter am 31 Mai 2025, 23:28:10Hast du etwas im Hinterkopf?
Ich hatte gedacht, das Signal als zusätzliche Einschränkung beim Batterieladen, bzw. bei 'power-consumtion' von Großverbrauchern (Warmwasser, WA,GSP,WP etc.) immer dann einzusetzen, wenn die individuelle Vorhersage in SF ein ausreichendes Energieangebot signalisiert.
Ja normalerweise reicht auch der Preis aus
https://api.energy-charts.info/price?bzn=DE-LU
Aber ich kann mir gut vorstellen das in einigen Situationen nicht 1:1 gilt: 'billiger Strompreise = viel EE im Netz'
Wie gesagt im Moment sind das nur Gedankenspiele, die ich kurz teilen wollte. In meinem Fall habe ich eine einigermaßen funktionierende Logik. Da bin ich dabei zu konsolidieren und auf einen einheitlichen Stand bringen so kommt die eine oder andere Idee
Gruß Gerd
Zitat von: Max_Meyer am 31 Mai 2025, 22:39:48Zitat von: oelidoc am 31 Mai 2025, 19:17:26Beim SunnyTripower8SE reicht es meiner Erfahrung nach Modbus SetLeistung auf 0 zusetzen und dann die Steuerung mit SetAktiv 802 ein- und mit 803 auszuschalten
Hallo oelidoc,
nach meinem Wissensstand muss das Schreiben zyklisch (20min) erfolgen - sonst stellt er sich wieder auf 803
Gruß Gerd
Das kommt auf die individuellen Parameter im BWR an.
Bei mir z.B. word erst nach 30 Minuten wieder automatisch ,,ausgeschaltet" falls kein neues setzen des Registers per Modbus erfolgt.
Guten Morgen,
wie gestern in #3079 geschrieben, habe ich mir am sehr späten Abend die Vorhersagewerte von nextHours rauskopiert um sie heute mit der Daten für die initiale Vorhersage in der DB zu vergleichen.
NextHour09 => starttime: 2025-06-01 08:00:00, day: 01, hourofday: 09, today: 0
pvapifc: 1183, pvaifc: -, pvfc: 1183, aihit: 0
confc: 590, confcEx: 590, weatherid: 3, wcc: 86, rr1c: 0.00, temp=19.30
rad1h: -, sunaz: 91, sunalt: 30, DoN: 1
rrange: 0.00, crange: 85, DaysInRange: 1, correff: 1.08/0.92
soc01: 78.0, soc02: -, soc03: -, socprogwhsum: 22166
rcdchargebat01: 1, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
NextHour10 => starttime: 2025-06-01 09:00:00, day: 01, hourofday: 10, today: 0
pvapifc: 1649, pvaifc: -, pvfc: 1649, aihit: 0
confc: 610, confcEx: 610, weatherid: 3, wcc: 100, rr1c: 0.30, temp=19.30
rad1h: -, sunaz: 103, sunalt: 39, DoN: 1
rrange: 0.30, crange: 100, DaysInRange: 5, correff: 0.98/0.98
soc01: 81.3, soc02: -, soc03: -, socprogwhsum: 23101
rcdchargebat01: 1, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
NextHour11 => starttime: 2025-06-01 10:00:00, day: 01, hourofday: 11, today: 0
pvapifc: 2266, pvaifc: -, pvfc: 2266, aihit: 0
confc: 1052, confcEx: 1052, weatherid: 61, wcc: 100, rr1c: 0.10, temp=19.00
rad1h: -, sunaz: 118, sunalt: 48, DoN: 1
rrange: 0.10, crange: 100, DaysInRange: 1, correff: 1.10/0.91
soc01: 85.1, soc02: -, soc03: -, socprogwhsum: 24194
rcdchargebat01: 1, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
NextHour12 => starttime: 2025-06-01 11:00:00, day: 01, hourofday: 12, today: 0
pvapifc: 2202, pvaifc: -, pvfc: 2202, aihit: 0
confc: 658, confcEx: 658, weatherid: 80, wcc: 100, rr1c: 0.00, temp=20.10
rad1h: -, sunaz: 137, sunalt: 55, DoN: 1
rrange: 0.00, crange: 100, DaysInRange: 5, correff: 0.99/0.99
soc01: 85.1, soc02: -, soc03: -, socprogwhsum: 24194
rcdchargebat01: 0, rcdchargebat02: -, rcdchargebat03: -
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
Hier auszugsweise für die Stunden 09 - 12. Die Werte für pvfc sollten sich in der DB wiederfinden, also 08:00 -> 1183, 09:00 -> 1649, 10:00 -> 2266, 11:00 -> 2202.
In der DB sind die Werte auch so enthalten:
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 11:00:01 SolCast SOLARFORECAST AllPVforecastsToEvent 2202 Wh
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 11:00:00 SolCast SOLARFORECAST AllPVforecastsToEvent 0 Wh
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 10:00:01 SolCast SOLARFORECAST AllPVforecastsToEvent 2266 Wh
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 10:00:00 SolCast SOLARFORECAST AllPVforecastsToEvent 0 Wh
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 09:00:01 SolCast SOLARFORECAST AllPVforecastsToEvent 1649 Wh
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 09:00:00 SolCast SOLARFORECAST AllPVforecastsToEvent 0 Wh
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 08:00:01 SolCast SOLARFORECAST AllPVforecastsToEvent 1183 Wh
Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 2025-06-01 08:00:00 SolCast SOLARFORECAST AllPVforecastsToEvent 0 Wh
Die existierende 0 zwischen den Werten ist dem gesetzen Parameter plantControl->genPVforecastsToEvent=adapt4Steps geschuldet.
Das passt also so wie ich das sehe.
LG,
Heiko
Guten Abend,
nachdem ich jetzt ein Jahr lang aus der Steckdose mein Auto geladen habe und die seit dem letzten Sommer auch mit SolarForecast gesteuert habe, habe ich nun seit letzter Woche eine goE-Wallbox und habe sie Dank der Vorarbeit von pah sehr schnell in FHEM einbinden können. Nun suche ich den besten Weg, sie auch in den SolarForecast-Kosmos zu integrieren. (Ich weiß, was pah davon hält. ;) )
Aktuell versorge ich die goE mit einem at Device alle paar Minuten mit den Werten von Grid-Einspeisung, PV-Produktion und Batteriezufluss. Bislang sind es die echten Werte, ich könnte hier aber auch beliebige andere (z.B. von SolarForecast empfohlene) Werte dem goE unterjubeln. Dessen PV-Überschuss-Ladesteuerung entscheidet dann selbst, ob es gerade genug ist, um den Ladevorgang zu starten/ fortzusetzen oder nicht und mit welcher Leistung geladen wird.
Bislang kann SolarForecast den Consumern nur sagen, DASS sie aktiv werden können, aber nicht WIEVIEL Leistung ihnen zusteht, oder übersehe ich etwas?
Viele Grüße
Christian
Nabend Christian,
ZitatBislang kann SolarForecast den Consumern nur sagen, DASS sie aktiv werden können, aber nicht WIEVIEL Leistung ihnen zusteht, oder übersehe ich etwas?
Per default ist es so wie du schreibst. Allerdings kann man die Logik über das Attribut ctrlUserExitFn für etwas speziellere Anwendungen erweitern. Dabei kommt es natürlich stark darauf an welche Logik man umsetzen möchte. Aber es gibt viele Möglichkeiten.
LG,
Heiko
<OT>
Für Proxmox Nutzer könnte eventuell dieser Beitrag (https://forum.fhem.de/index.php?topic=141804.0) von Interesse sein.
</OT>
In meinem contrib liegt die V 1.52.8.
Ich habe noch eine optimierende Anpassung bzgl. der Verbrauchsprognose bei Verwendung von plantControl->consForecastIdentWeekdays und plantControl->consForecastLastDays eingebaut.
LG,
Heiko
Gibt es unterschiedliche contrib Ablagen?
Unter https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter?desc=1&order=date&rev=29968 ist nur mehr die
1.5 MB � 29968 2 Wochen DS_Starter 76_SolarForecast: contrib Version 1.52.3ersichtlich.
Hab den richtigen Link gefunden.
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter?desc=1&order=date
Zitat von: DS_Starter am 01 Juni 2025, 22:37:35Nabend Christian,
ZitatBislang kann SolarForecast den Consumern nur sagen, DASS sie aktiv werden können, aber nicht WIEVIEL Leistung ihnen zusteht, oder übersehe ich etwas?
Per default ist es so wie du schreibst. Allerdings kann man die Logik über das Attribut ctrlUserExitFn für etwas speziellere Anwendungen erweitern. Dabei kommt es natürlich stark darauf an welche Logik man umsetzen möchte. Aber es gibt viele Möglichkeiten.
Ich schaue mir mal die Beispiele im Wiki zu ctrlUserExitFn an. Die hatte ich noch nicht gesehen. Das geht in eine passende Richtung. Ein erster Schritt könnte sein, das AT-Device durch eine Funktion hier zu ersetzen, die dann in jedem Zyklus neue Werte an die Box liefert. In einem zweiten Schritt könnte ich das verbessern und die übermittelten Werte anders ermitteln. Die Frage, die sich dann vermutlich stellen wird (aber erstmal abwarten, bis ich da bin), ist die Berücksichtigung in den Empfehlungen für weitere Consumer durch SF.
Gruß
Christian
Ich habe das Modul neu eingerichtet.
Den Funktionsumfang finde ich super - allerdings stimmen bei mir Forecast und Erzeugung noch nicht gut.
Bei der Ursachensuche bin ich auf folgende Frage gestoßen:
Innerhalb des Moduls Solarforecast werden unterschiedliche Definitionen von Azimut benutzt:
-Beim Setup von Solarforecast ist die Orientierung der Strings anzugeben mit folgenden Werten:
setupStringAzimuth Azimuth values are integers in the range -180 to 180.
=> Beispielsweise "Süden" hat den Wert 0
- Bei "Mouse Over" dem Wettersymbol in der Anzeige von Solarforecast oder auch im Modul Astro wird im Süden ein Azimut von 180 angezeigt.
=> stimmt die Vorgabe, dass bei setupStringAzimuth die Orientierung mit [-180:180] anzugeben ist?
Zitatstimmt die Vorgabe, dass bei setupStringAzimuth die Orientierung mit [-180:180] anzugeben ist?
Ja, im Solarbereich gibt es andere Konventionen als in Astronomie und Navigation. Die verwendeten API's wie z.B. OpenMeteo erwarten die Angaben in der Solar-Konvention. Andere Erwartungen muss ich intern umrechnen.
LG,
Heiko
@all,
ich habe den Request von Parallix aus #3067 umgesetzt, im contrib liegt die V 1.52.9.
Dazu gibt es einen neuen Key in ctrlBatSocManagementXX -> [loadAbort=<SoC>:<PowerIn>]
loadAbort Bedingung für einen generellen Ladeabbruch. Die Bedingung ist erfüllt, wenn der angegebene
SoC (%) erreicht bzw. überschritten ist UND die angegebene Ladeleistung (W)
unterschritten wurde -> Reading Battery_ChargeAbort_XX = 1.
Fällt der aktuelle SoC wieder unter den angegebenen SoC, wird Battery_ChargeAbort_XX = 0
Zur Signalisierung der Abbruch-Condition habe ich das Reading Battery_ChargeAbort_XX eingeführt, welches man in den Steuerungsroutinen für die Batterie auswerten kann.
@Parallix, vllt. kannst du es mal testen ob die Logik deinen Request abbildet.
Grüße,
Heiko
@all,
ich habe die Bitte von tupol aus #3062 umgesetzt und eine Optimierung für fsteps (Attr plantControl) eingebaut:
genPVforecastsToEvent Das Modul erzeugt täglich 'AllPVforecastsToEvent'-Events zur Visualisierung der PV Prognose.
Nähere Erläuterungen dazu sind im Wiki beschrieben.
Hinweis: Bei Nutzung des Attributes ist ebenfalls das Attribut event-on-update-reading=AllPVforecastsToEvent zu setzen.
Die Eventerzeugung kann für bestimmte Nutzungen optimiert werden:
adapt4Steps - die Events werden für den SVG Plot-Type 'steps' optimiert
adapt4fSteps - die Events werden für den SVG Plot-Type 'fsteps' optimiert
Die V 1.52.10 liegt in meinem contrib zum Test.
LG,
Heiko
Hallo Heiko,
ich hätte wieder mal eine Frage - habe einige SF - Werte (stichpunktartig) auf Plausibilität geprüft. Das betrifft folgende Readings:
Netzbezug_total --> NB-Übergabepunkt ins Grid (1.8.1)
Netzlieferung_Total --> NB-Übergabepunkt ins Grid (2.8.1)
PV_today --> SF
Consumtion_Today --> SF
BatIn_today --> Energy-Sum aller Batterien pro Tag (BAT-Readings)
BatIn_today --> Energy-Sum aller Batterien pro Tag (BAT-Readings)
Die Annahme war (ist):
(Netzbezug_total+PV_today+BatOut_today)-(Netzlieferung_Total+Netzlieferung_Total) = Consumtion_Today
Das ist in keiner meiner SF - Installationen aufgegangen --> siehe Screenshots --> der von mir ausgerechnete 'reale' Tagesverbrauch zu diesem Zeitpunkt betrug ungefähr 24 kWh
Dabei ist mir bewusst das unter Consumer_xx niemals alle Verbraucher im Haus gelistet sind und das sich eine geringe Unschärfe aus der Messgenauigkeit bzw. Abfrageinterfall ergeben kann.
Frage1: ist meine Annahme richtig?
Frage2: lässt sich ein Reading 'Unknown Consumtion Yesterday' erzeugen indem man vom Soll (Formel oben) das Ist (Consumer_xx) abzieht? - so ließe sich leicht ermitteln ob noch ein maßgeblicher Anteil an Leistungsverbrauch im Haus nicht erfasst ist.
Gruß Gerd
Hallo Gerd,
ZitatFrage1: ist meine Annahme richtig?
Nicht ganz. In deiner Rechnung fehlt das BatIn_today.
Die Formel lautet:
PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0oder anders ausgedrückt:
Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + BatterieentladungDer Verbrauch des Hauses ist die einzige Größe die nicht direkt gemessen wird. Deswegen ergiebt sich der Verbrauch aus der letzteren Formel. Siehe auch Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?).
Dadurch erübrigt sich auch ein 'Unknown Consumtion Yesterday', weil es eine 'Unknown Consumtion' nicht geben kann.
LG,
Heiko
Zitat von: DS_Starter am 03 Juni 2025, 18:37:17Dadurch erübrigt sich auch ein 'Unknown Consumtion Yesterday', weil es eine 'Unknown Consumtion' nicht geben kann.
Hallo Heiko,
Ja bei der Formel war ich wohl abgelenkt :) - in den Screens ist es richtig.
Aber mit dem unbekannten Verbrauch meine ich die Differenz mit dem errechneten Verbrauch und dem was die Consumer 1-16 über den Tag verbrauchen - da muss es eine Differenz geben.
Zitat von: DS_Starter am 03 Juni 2025, 18:37:17PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung - Verbrauch = 0
dann ist es mir nach wie vor unplausibel warum ich bei den einzelnen SF-Installationen eben nicht auf '0' komme - ist in den Screens zu sehen
Gruß Gerd
Zitatdann ist es mir nach wie vor unplausibel warum ich bei den einzelnen SF-Installationen eben nicht auf '0' komme - ist in den Screens zu sehen
So 100%ig wird das nicht funktionieren, weil wir auf Stundenbasis arbeiten, aber die Geräte in FHEM leider nicht alle zur vollen Stunde (oder ein paar Sekunden davor/danach) ihre aktuellen Werte liefern. Als User müssen wir versuchen eine solche Synchronität herzustellen so gut es geht.
Einfaches Beispiel ... du hast eine leistungsstarke Anlage. Bei 15kW Peak und vollem Sonnenschein würde die PV 15kWh in der Stunde erzeugen. Fehlt nur 1 Minute vor der vollen Stunde der aktuelle Meßwert, wäre das schon eine Differenz von 250Wh Erzeugung die bei der Verbrauchsberechnung für diese Stunde fehlt. Die anderen Geräte (z.B. Batterien) bringen ihre Differenzen auch ein. Ich denke du siehst worauf ich hinaus will.
Deswegen wäre eine absolute Synchronität der beteiligten Geräte essentiell für eine hohe Genauigkeit. Das werden wir aber nur in den seltensten Fällen 100%ig in FHEM hinbekommen.
Zitat von: DS_Starter am 03 Juni 2025, 19:02:35Einfaches Beispiel ... du hast eine leistungsstarke Anlage. Bei 15kW Peak und vollem Sonnenschein würde die PV 15kWh in der Stunde erzeugen. Fehlt nur 1 Minute vor der vollen Stunde der aktuelle Meßwert, wäre das schon eine Differenz von 250Wh Erzeugung die bei der Verbrauchsberechnung für diese Stunde fehlt. Die anderen Geräte (z.B. Batterien) bringen ihre Differenzen auch ein. Ich denke du siehst worauf ich hinaus will.
Hallo Heiko,
ich denke wir reden/schreiben aneinander vorbei - der obige Sachverhalt ist klar - der Hinweis mit den Stundenscheiben macht meine Werte auch plausibel.
Aber mit meinem Redingsvorschlag dachte ich an etwas anderes - der 'Hausverbrauch' ist nach obiger Formel bekannt. Zusätzlich haben die Consumer_01 - _16 zusammengerechnet einen 'Consumerenergieverbrauch'. Dieser bildet einen Teil des 'Hausenergieverbrauchs' ab.
Die Idee war, das in Verhältnis zu setzten - oder einfach nur die Differenz pro Tag auszuweisen als 'unbekannten Hausenergieverbrauch' - so ähnlich wie du es mit der Leistung im Hausknoten für die Momentanwerte machst.
Gruß Gerd
Hallo Gerd,
ja, da habe ich dich tatsächlich mißverstanden. Jetzt weiß ich was du meinst.
Das ginge eigentlich nur immer für den vergangenen Tag. Denn solange der aktuelle Tag noch nicht um ist, kann ich diese Differenz nicht bestimmen.
Kannst du mir den Use Case dafür ein bisschen näher bringen damit ich eine Idee habe was man damit erreichen kann? Vllt. fällt mir dann noch etwas besseres ein wenn ich das Ansinnen besser einordnen kann.
EDIT: Nach einigem Nachdenken könnte ich ein ctrlSpecialReadings für den aktuellen Tag mitlaufen lassen, welches sich dynamisch ändert. Es gibt bereits ein Reading special_todayConsumption. Das passt in diesen Kontext. Damit hätte man einen ständigen Vergleich von Gesamtverbrauch zum Verbrauch der den Consumern nicht zugeordnet werden kann. Sollte machbar sein. Alternativ wäre auch ein Reading denkbar welches den Energiebetrag ausgiebt der allen registrierten Verbauchern zugeordnet werden kann. Das ist nun Ansichtssache was besser ist und vllt. von dem Use Case abhängig.
LG,
Heiko
Zitat von: DS_Starter am 03 Juni 2025, 21:16:55Nach einigem Nachdenken könnte ich ein ctrlSpecialReadings für den aktuellen Tag mitlaufen lassen, welches sich dynamisch ändert. Es gibt bereits ein Reading special_todayConsumption. Das passt in diesen Kontext. Damit hätte man einen ständigen Vergleich von Gesamtverbrauch zum Verbrauch der den Consumern nicht zugeordnet werden kann. Sollte machbar sein. Alternativ wäre auch ein Reading denkbar welches den Energiebetrag ausgiebt der allen registrierten Verbauchern zugeordnet werden kann. Das ist nun Ansichtssache was besser ist und vllt. von dem Use Case abhängig.
Guten Morgen Heiko,
Danke! Das hatte ich so gemeint :) - Um Prio einzuordnen hab ich noch mal versucht die usecases zu beschreiben
momentan sehe ich zwei usecases für dieses Reading
1.) mehr statistisch - ich habe die Info dazu genutzt um herauszufinden wieviel von meinem Verbrauch noch keinem konkreten Verbraucherzugeordnet werden kann d.h. je kleiner der Wert ist desto mehr diskrete Verbraucher befinden sich innerhalb der Statistik desto genauer ist zu sehen wann, wo, welche Energie verwendet wird.
2.) wenn du Richtung 2.te KI-Instanz für Consumer gehst wäre diese Differenz m.M.n. notwendig um für diesen Energie-Anteil eine Vorhersage u kreieren
Daher wäre ich dafür nur den Rest (nicht zugeordneten Verbrauch) auszugeben
Gruß Gerd
Morgen Gerd,
ich habe soeben die V 1.52.11 in mein contrib geladen.
Das Attr ctrlSpecialReadings hat jetzt auch diese Option:
todayNotOwnerConsumption der Energieverbrauch am aktuellen Tag, der den registrierten Verbrauchern nicht zugeordnet werden konnte
Kannst mal probieren.
LG,
Heiko
Hallo Heiko,
Weiterentwicklung weckt Wünsche. ;-)
Zitat von: DS_Starter am 04 Juni 2025, 08:22:13Morgen Gerd,
ich habe soeben die V 1.52.11 in mein contrib geladen.
Das Attr ctrlSpecialReadings hat jetzt auch diese Option:
todayNotOwnerConsumption der Energieverbrauch am aktuellen Tag, der den registrierten Verbrauchern nicht zugeordnet werden konnte
Kannst mal probieren.
LG,
Heiko
Wenn das umsetzbar ist, kannst Du doch bestimmt auch die Tagessummen der einzelnen Verbraucher ermitteln, oder?
Dabei würde mich nicht so sehr ein separates Readings interessieren, als viel mehr die Anzeige an den Verbrauchern in der Flußgrafik.
Und dann vielleicht an allen anderen Elementen nach und nach auch die jeweilige Tages-Arbeit zusätzlich zu den jeweiligen Momentanleistungen?
Meinst du, das wäre aufwendig?
:)
ZitatWenn das umsetzbar ist, kannst Du doch bestimmt auch die Tagessummen der einzelnen Verbraucher ermitteln, oder?
Ja, die habe ich.
ZitatDabei würde mich nicht so sehr ein separates Readings interessieren, als viel mehr die Anzeige an den Verbrauchern in der Flußgrafik.
Und dann vielleicht an allen anderen Elementen nach und nach auch die jeweilige Tages-Arbeit zusätzlich zu den jeweiligen Momentanleistungen?
Meinst du, das wäre aufwendig?
Das geht, kostet zwar Zeit, ist aber nicht so dramatisch. Zumindest bei den Consumern lässt sich dieser Wert unterhalb der Verbraucher in der Grafik darstellen, ein/ausblendbar wie ihr das kennt.
Bei den anderen Elementen ist es nicht so gut machbar, allein schon wegen der Übersichtlichkeit und dem Platz in der Grafik, der auch noch dynamisch verwaltet wird.
Ich könnte mir vorstellen, so wie es pah in seiner Grafik gemacht hat, in einer Ecke zum Beispiel die Summe für PV-Erzeugung (mit Symbol) und eine Summe des Hausverbrauchs (mit Symbol). Die Summe für Batterie-In/Out könnten mit an den Batterieknoten passen und die Summen Grid-In/Out an das Gridsymbol.
Nur mal als erster Gedankengang.
LG,
Heiko
Zitat von: DS_Starter am 04 Juni 2025, 11:08:27Nur mal als erster Gedankengang.
Das klingt doch schon mal sehr gut.
Am wichtigsten wäre mir persönlich das auch bei den Verbrauchern, dem "Rest"-Verbrauch und dem Gesamtverbrauch am Haus.
Optimal wäre es dann, auch die jeweilige Einheit (W, Wh) mit anzuzeigen.
Viele Grüße,
Peter
ZitatOptimal wäre es dann, auch die jeweilige Einheit (W, Wh) mit anzuzeigen.
Das müsste ich dann sowieso vorsehen. Wenn der Umfang zunimmt, reicht es nicht (schon vom Platz her) immer nur W / Wh anzuzeigen wie momentan.
Die Zahlen werden dann u.U. einfach zu lang. Aber auch die Einheiten (kWh) brauchen Platz der verloren geht.
Naja, das muß im Kopf entwickelt werden, braucht Zeit.
Jetzt lege ich ohnehin erstmal eine kleine Pause ein, da habt ihr auch Ruhe. ;)
Zitat von: DS_Starter am 04 Juni 2025, 14:01:08Jetzt lege ich ohnehin erstmal eine kleine Pause ein, da habt ihr auch Ruhe. ;)
Pausen sind wichtig. Gute Erholung!
Zitat von: DS_Starter am 04 Juni 2025, 08:22:13todayNotOwnerConsumption der Energieverbrauch am aktuellen Tag, der den registrierten Verbrauchern nicht zugeordnet werden konnte
Kannst mal probieren
Hallo Heiko,
vielen Dank!
das sieht super aus!
Gruß Gerd
@all,
die Version 1.52.11 ist eingecheckt. Hier die summarische Zusammenstellung, was in den Versionen 1.52.7 - 1.52.11 alles enthalten ist:
- das exclude/include bzgl. Verbrauchern mit exconfc in Abhängigkeit der gesetzten Parameter
plantControl->consForecastIdentWeekdays / plantControl->consForecastLastDays ist verbessert.
- optimierende Anpassung bzgl. der Verbrauchsprognose bei Verwendung von
plantControl->consForecastIdentWeekdays und plantControl->consForecastLastDays
- neuer Key in ctrlBatSocManagementXX -> [loadAbort=<SoC>:<PowerIn>] zur Definition einer generellen Ladeabbruch-Bedingung
- Optimierung AllPVforecastsToEvent-Events für SVG Plot-Type 'fsteps' -> plantControl->genPVforecastsToEvent:adapt4fSteps
- ctrlSpecialReadings : neue Option todayNotOwnerConsumption - der Energieverbrauch am aktuellen Tag, der den registrierten
Verbrauchern nicht zugeordnet werden konnte
LG,
Heiko
Moin!
Seit gestern füllt sich meine Log-Datei. Mit Meldungen wie diese:
2025.06.04 16:57:57 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2796.
2025.06.04 16:57:57 1: stacktrace:
2025.06.04 16:57:57 1: main::__ANON__ called by ./FHEM/01_FHEMWEB.pm (2796)
2025.06.04 16:57:57 1: main::FW_makeImage called by ./FHEM/76_SolarForecast.pm (14641)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_graphicHeader called by ./FHEM/76_SolarForecast.pm (14198)
2025.06.04 16:57:57 1: FHEM::SolarForecast::entryGraphic called by ./FHEM/76_SolarForecast.pm (14073)
2025.06.04 16:57:57 1: FHEM::SolarForecast::FwFn called by ./FHEM/01_FHEMWEB.pm (3471)
2025.06.04 16:57:57 1: main::FW_devState called by ./FHEM/01_FHEMWEB.pm (3258)
2025.06.04 16:57:57 1: main::FW_Notify called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (3900)
2025.06.04 16:57:57 1: main::DoTrigger called by fhem.pl (5017)
2025.06.04 16:57:57 1: main::readingsEndUpdate called by fhem.pl (5200)
2025.06.04 16:57:57 1: main::readingsSingleUpdate called by ./FHEM/76_SolarForecast.pm (20997)
2025.06.04 16:57:57 1: FHEM::SolarForecast::singleUpdateState called by ./FHEM/76_SolarForecast.pm (8150)
2025.06.04 16:57:57 1: FHEM::SolarForecast::writeCacheToFile called by ./FHEM/76_SolarForecast.pm (12506)
2025.06.04 16:57:57 1: FHEM::SolarForecast::___switchConsumerOn called by ./FHEM/76_SolarForecast.pm (12384)
2025.06.04 16:57:57 1: FHEM::SolarForecast::__switchConsumer called by ./FHEM/76_SolarForecast.pm (11437)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_manageConsumerData called by ./FHEM/76_SolarForecast.pm (8534)
2025.06.04 16:57:57 1: FHEM::SolarForecast::centralTask called by ./FHEM/76_SolarForecast.pm (8255)
2025.06.04 16:57:57 1: FHEM::SolarForecast::runTask called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (855)
2025.06.04 16:57:57 1: PERL WARNING: Use of uninitialized value $name in substitution (s///) at ./FHEM/01_FHEMWEB.pm line 3033.
2025.06.04 16:57:57 1: stacktrace:
2025.06.04 16:57:57 1: main::__ANON__ called by ./FHEM/01_FHEMWEB.pm (3033)
2025.06.04 16:57:57 1: main::FW_iconPath called by ./FHEM/01_FHEMWEB.pm (2800)
2025.06.04 16:57:57 1: main::FW_makeImage called by ./FHEM/76_SolarForecast.pm (14641)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_graphicHeader called by ./FHEM/76_SolarForecast.pm (14198)
2025.06.04 16:57:57 1: FHEM::SolarForecast::entryGraphic called by ./FHEM/76_SolarForecast.pm (14073)
2025.06.04 16:57:57 1: FHEM::SolarForecast::FwFn called by ./FHEM/01_FHEMWEB.pm (3471)
2025.06.04 16:57:57 1: main::FW_devState called by ./FHEM/01_FHEMWEB.pm (3258)
2025.06.04 16:57:57 1: main::FW_Notify called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (3900)
2025.06.04 16:57:57 1: main::DoTrigger called by fhem.pl (5017)
2025.06.04 16:57:57 1: main::readingsEndUpdate called by fhem.pl (5200)
2025.06.04 16:57:57 1: main::readingsSingleUpdate called by ./FHEM/76_SolarForecast.pm (20997)
2025.06.04 16:57:57 1: FHEM::SolarForecast::singleUpdateState called by ./FHEM/76_SolarForecast.pm (8150)
2025.06.04 16:57:57 1: FHEM::SolarForecast::writeCacheToFile called by ./FHEM/76_SolarForecast.pm (12506)
2025.06.04 16:57:57 1: FHEM::SolarForecast::___switchConsumerOn called by ./FHEM/76_SolarForecast.pm (12384)
2025.06.04 16:57:57 1: FHEM::SolarForecast::__switchConsumer called by ./FHEM/76_SolarForecast.pm (11437)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_manageConsumerData called by ./FHEM/76_SolarForecast.pm (8534)
2025.06.04 16:57:57 1: FHEM::SolarForecast::centralTask called by ./FHEM/76_SolarForecast.pm (8255)
2025.06.04 16:57:57 1: FHEM::SolarForecast::runTask called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (855)
2025.06.04 16:57:57 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/01_FHEMWEB.pm line 3036.
2025.06.04 16:57:57 1: stacktrace:
2025.06.04 16:57:57 1: main::__ANON__ called by ./FHEM/01_FHEMWEB.pm (3036)
2025.06.04 16:57:57 1: main::FW_iconPath called by ./FHEM/01_FHEMWEB.pm (2800)
2025.06.04 16:57:57 1: main::FW_makeImage called by ./FHEM/76_SolarForecast.pm (14641)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_graphicHeader called by ./FHEM/76_SolarForecast.pm (14198)
2025.06.04 16:57:57 1: FHEM::SolarForecast::entryGraphic called by ./FHEM/76_SolarForecast.pm (14073)
2025.06.04 16:57:57 1: FHEM::SolarForecast::FwFn called by ./FHEM/01_FHEMWEB.pm (3471)
2025.06.04 16:57:57 1: main::FW_devState called by ./FHEM/01_FHEMWEB.pm (3258)
2025.06.04 16:57:57 1: main::FW_Notify called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (3900)
2025.06.04 16:57:57 1: main::DoTrigger called by fhem.pl (5017)
2025.06.04 16:57:57 1: main::readingsEndUpdate called by fhem.pl (5200)
2025.06.04 16:57:57 1: main::readingsSingleUpdate called by ./FHEM/76_SolarForecast.pm (20997)
2025.06.04 16:57:57 1: FHEM::SolarForecast::singleUpdateState called by ./FHEM/76_SolarForecast.pm (8150)
2025.06.04 16:57:57 1: FHEM::SolarForecast::writeCacheToFile called by ./FHEM/76_SolarForecast.pm (12506)
2025.06.04 16:57:57 1: FHEM::SolarForecast::___switchConsumerOn called by ./FHEM/76_SolarForecast.pm (12384)
2025.06.04 16:57:57 1: FHEM::SolarForecast::__switchConsumer called by ./FHEM/76_SolarForecast.pm (11437)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_manageConsumerData called by ./FHEM/76_SolarForecast.pm (8534)
2025.06.04 16:57:57 1: FHEM::SolarForecast::centralTask called by ./FHEM/76_SolarForecast.pm (8255)
2025.06.04 16:57:57 1: FHEM::SolarForecast::runTask called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (855)
...
2025.06.04 16:57:57 1: PERL WARNING: Use of uninitialized value $img in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14642.
2025.06.04 16:57:57 1: stacktrace:
2025.06.04 16:57:57 1: main::__ANON__ called by ./FHEM/76_SolarForecast.pm (14642)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_graphicHeader called by ./FHEM/76_SolarForecast.pm (14198)
2025.06.04 16:57:57 1: FHEM::SolarForecast::entryGraphic called by ./FHEM/76_SolarForecast.pm (14073)
2025.06.04 16:57:57 1: FHEM::SolarForecast::FwFn called by ./FHEM/01_FHEMWEB.pm (3471)
2025.06.04 16:57:57 1: main::FW_devState called by ./FHEM/01_FHEMWEB.pm (3258)
2025.06.04 16:57:57 1: main::FW_Notify called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (3900)
2025.06.04 16:57:57 1: main::DoTrigger called by fhem.pl (5017)
2025.06.04 16:57:57 1: main::readingsEndUpdate called by fhem.pl (5200)
2025.06.04 16:57:57 1: main::readingsSingleUpdate called by ./FHEM/76_SolarForecast.pm (20997)
2025.06.04 16:57:57 1: FHEM::SolarForecast::singleUpdateState called by ./FHEM/76_SolarForecast.pm (8150)
2025.06.04 16:57:57 1: FHEM::SolarForecast::writeCacheToFile called by ./FHEM/76_SolarForecast.pm (12506)
2025.06.04 16:57:57 1: FHEM::SolarForecast::___switchConsumerOn called by ./FHEM/76_SolarForecast.pm (12384)
2025.06.04 16:57:57 1: FHEM::SolarForecast::__switchConsumer called by ./FHEM/76_SolarForecast.pm (11437)
2025.06.04 16:57:57 1: FHEM::SolarForecast::_manageConsumerData called by ./FHEM/76_SolarForecast.pm (8534)
2025.06.04 16:57:57 1: FHEM::SolarForecast::centralTask called by ./FHEM/76_SolarForecast.pm (8255)
2025.06.04 16:57:57 1: FHEM::SolarForecast::runTask called by fhem.pl (3983)
2025.06.04 16:57:57 1: main::CallFn called by ./FHEM/98_freezemon.pm (1235)
2025.06.04 16:57:57 1: main::freezemon_callFn called by ./FHEM/98_freezemon.pm (1348)
2025.06.04 16:57:57 1: main::__ANON__ called by fhem.pl (855)
2025.06.04 16:57:57 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2796.
2025.06.04 16:57:57 1: stacktrace:
Geändert hatte ich zu dem Zeitpunkt nichts. Habe gestern Abend dann aber mal ein Update von FHEM gemacht. Die Fehler kommen weiterhin.
Liegt es an dem Modul? Oder läuft hier eher etwas anderes Amok? Die Meldungen kommen derzeit jede Minute...
Gruß
Bismosa
Moin,
das ist meine Schuld. Ich hatte eine fehlerfafte Mitteilung an das Mitteilungssystem gesendet.
Du dürftest auch kein Mail-Icon in der grafischen Oberfläche sehen.
Ich habe soeben die Mitteilung neu versendet und dürfte sich in den nächsten 2 Stunden geben. Wenn du es eilig hast, kannst du auch restarten. Dann wird die korrigierte Mitteilung kurzfristig geholt.
LG,
Heiko
Hallo!
Danke für die sehr schnelle Behebung des Problems! Hat sich jetzt gerade beruhigt und es wird auch eine Mitteilung angezeigt.
Gruß
Bismosa
Zitat von: DS_Starter am 30 Mai 2025, 23:23:34@Wolle02,
in meinem contrib liegt die V 1.52.7.
Das exclude/include bzgl. Verbrauchern mit exconfc in Abhängigkeit der gesetzten Parameter plantControl->consForecastIdentWeekdays / plantControl->consForecastLastDays ist verbessert.
Lade dir bitte die V in dein System und restarte FHEM.
Danach kannst du experimentieren ob deine Verbrauchvorhersage mit oder ohne die Parameter plantControl->consForecastIdentWeekdays=1 / plantControl->consForecastLastDays=4 bessere Ergebnisse bringt.
Andere User können die V in diesem Kontext natürlich auch gern mal testen.
LG,
Heiko
Hallo Heiko, ich wollte dir noch eine Rückmeldung zur Version 1.52.7 bzw. 8 geben, die ich aktuell bei mir aufgrund deiner Bemühungen laufen habe (Vielen Dank an der Stelle). Die Rückmeldung hat sich etwas verzögert, weil ich noch einen Fehler in meiner Config gefunden habe.
Im Wesentlichen hat sich die Darstellung bei mir bislang nicht großartig geändert. Ich hatte einen Fehler in der BatConfig (Wh und kWh) was dazu führte, dass bei BatOut immer 0 W eingetragen war. Das hat sich zwar zwischenzeitlich geändert, aber scheinbar ist das Reading BatOut nicht für die Verbrauchsberechnung verantwortlich, so dass sich an der Batterie SoC Prognose für die Nachtzeit nicht wirklich was ändert.
Aus der pvHistory sehe ich, dass sich die Verbrausprognose (confc) Nachts immer so um einen Wert zwischen 30 - 100 Watt bewegt, während der reale Verbrauch (con) sich immer dauerhaft zwischen 350 - 500 Watt bewegt; sollte sich das lernende System hier nicht anpassen?
Deine Vorschläge bezüglich plantControl->consForecastIdentWeekdays=1 / plantControl->consForecastLastDays=4 habe ich umgesetzt.
Muss ich der ganzen Sache einfach noch mehr Zeit geben oder könnten sich im System irgendwelche falschen Wert "festgesetzt" haben, so dass ein Reset der pvHistory und ein kompletter Neustart des Lernprozesses besser wäre?
05 => 01 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 370300.200000142, etotali02: 1242341.80334037, etotali03: 3261930.04500005, etotali04: -
pvrl01: 0, pvrl02: 0, pvrl03: 0, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 83, con: 483, gcons: 23, conprice: -
gfeedin: 0, feedprice: -
DoN: 0, sunaz: 348, sunalt: -18
batintotal01: 256380.4, batintotal02: -, batintotal03: -
batouttotal01: 237585.8, batouttotal02: -, batouttotal03: -
batprogsoc01: 18.3, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 1874
batsoc01: 19.2, batsoc02: -, batsoc03: -, socwhsum: 1966
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 0, batin02: -, batin03: -
batout01: 460, batout02: -, batout03: -
weatherid: 151, wcc: 99, rr1c: 0.30, pvcorrf: 1.00/- temp: 14.90,
csmt01: 27784.058, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13871.918, csme04: 15.7240000000002, minutescsm04: 17
csmt05: 21663.434, csme05: 1.27200000000084, minutescsm05: 60
csmt06: 47917.312, csme06: 114.691999999995, minutescsm06: 60
csmt07: 4150.885, minutescsm07: 0
csmt08: 536.004, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
02 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 370300.200000142, etotali02: 1242342.35889872, etotali03: 3261930.04500005, etotali04: -
pvrl01: 0, pvrl02: 0, pvrl03: 0, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 105, con: 351, gcons: 4, conprice: -
gfeedin: 0, feedprice: -
DoN: 0, sunaz: 2, sunalt: -18
batintotal01: 256380.5, batintotal02: -, batintotal03: -
batouttotal01: 238045.9, batouttotal02: -, batouttotal03: -
batprogsoc01: 14.3, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 1460
batsoc01: 15.4, batsoc02: -, batsoc03: -, socwhsum: 1577
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 0, batin02: -, batin03: -
batout01: 347, batout02: -, batout03: -
weatherid: 151, wcc: 99, rr1c: 0.30, pvcorrf: 1.00/- temp: 14.90,
csmt01: 27784.058, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13871.918, csme04: 0, minutescsm04: 0
csmt05: 21664.917, csme05: 1.48300000000017, minutescsm05: 60
csmt06: 48030.967, csme06: 113.654999999999, minutescsm06: 60
csmt07: 4151.459, minutescsm07: 0
csmt08: 536.679, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
03 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 370300.200000142, etotali02: 1242342.77264751, etotali03: 3261930.04500005, etotali04: -
pvrl01: 0, pvrl02: 0, pvrl03: 0, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 84, con: 411, gcons: 4, conprice: -
gfeedin: 1, feedprice: -
DoN: 0, sunaz: 16, sunalt: -17
batintotal01: 256380.5, batintotal02: -, batintotal03: -
batouttotal01: 238393.8, batouttotal02: -, batouttotal03: -
batprogsoc01: 10.4, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 1064
batsoc01: 11.3, batsoc02: -, batsoc03: -, socwhsum: 1157
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 0, batin02: -, batin03: -
batout01: 408, batout02: -, batout03: -
weatherid: 103, wcc: 98, rr1c: 0.00, pvcorrf: 1.00/- temp: 14.20,
csmt01: 27784.058, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13871.918, csme04: 0, minutescsm04: 0
csmt05: 21666.4, csme05: 1.48300000000017, minutescsm05: 60
csmt06: 48146.433, csme06: 115.466, minutescsm06: 60
csmt07: 4152.06, minutescsm07: 0
csmt08: 537.376, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
04 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 370300.300000142, etotali02: 1242343.256308, etotali03: 3261930.04500005, etotali04: -
pvrl01: 0, pvrl02: 0, pvrl03: 0, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 95, con: 351, gcons: 4, conprice: -
gfeedin: 0, feedprice: -
DoN: 0, sunaz: 30, sunalt: -13
batintotal01: 256380.5, batintotal02: -, batintotal03: -
batouttotal01: 238802.5, batouttotal02: -, batouttotal03: -
batprogsoc01: 7.9, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 805
batsoc01: 8.9, batsoc02: -, batsoc03: -, socwhsum: 911
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 0, batin02: -, batin03: -
batout01: 347, batout02: -, batout03: -
weatherid: 103, wcc: 80, rr1c: 0.00, pvcorrf: 1.00/- temp: 13.60,
csmt01: 27785.122, csme01: 1.06399999999849, minutescsm01: 15
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13872.128, csme04: 0.210000000000946, minutescsm04: 0
csmt05: 21667.883, csme05: 1.48300000000017, minutescsm05: 60
csmt06: 48260.235, csme06: 113.802000000003, minutescsm06: 60
csmt07: 4152.661, minutescsm07: 0
csmt08: 538.074, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
05 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 370300.300000142, etotali02: 1242343.72419747, etotali03: 3261930.04500005, etotali04: -
pvrl01: 0, pvrl02: 0, pvrl03: 0, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 90, con: 398, gcons: 6, conprice: -
gfeedin: 3, feedprice: -
DoN: 0, sunaz: 43, sunalt: -7
batintotal01: 256380.5, batintotal02: -, batintotal03: -
batouttotal01: 239150.2, batouttotal02: -, batouttotal03: -
batprogsoc01: 6.8, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 699
batsoc01: 7.8, batsoc02: -, batsoc03: -, socwhsum: 799
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 0, batin02: -, batin03: -
batout01: 395, batout02: -, batout03: -
weatherid: 102, wcc: 75, rr1c: 0.00, pvcorrf: 1.00/- temp: 12.80,
csmt01: 27785.122, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13872.128, csme04: 0, minutescsm04: 0
csmt05: 21669.366, csme05: 1.48300000000017, minutescsm05: 60
csmt06: 48374.234, csme06: 113.998999999996, minutescsm06: 60
csmt07: 4153.252, minutescsm07: 0
csmt08: 538.764, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
06 => pvfc: 50, pvrl: 40, pvrlvd: 1, rad1h: 50
etotali01: 370300.400000142, etotali02: 1242344.36697567, etotali03: 3261930.04500005, etotali04: -
pvrl01: 0, pvrl02: 39, pvrl03: 1, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 31, con: 420, gcons: 111, conprice: -
gfeedin: 1, feedprice: -
DoN: 0, sunaz: 55, sunalt: 1
batintotal01: 256381.3, batintotal02: -, batintotal03: -
batouttotal01: 239545.6, batouttotal02: -, batouttotal03: -
batprogsoc01: 7.2, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 734
batsoc01: 7.0, batsoc02: -, batsoc03: -, socwhsum: 717
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 0, batin02: -, batin03: -
batout01: 270, batout02: -, batout03: -
weatherid: 102, wcc: 69, rr1c: 0.00, pvcorrf: 0.42/0.00 temp: 12.40,
csmt01: 27785.122, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13872.128, csme04: 0, minutescsm04: 0
csmt05: 21670.85, csme05: 1.48399999999674, minutescsm05: 60
csmt06: 48486.675, csme06: 112.441000000006, minutescsm06: 60
csmt07: 4153.846, minutescsm07: 0
csmt08: 539.462, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
07 => pvfc: 410, pvrl: 513, pvrlvd: 1, rad1h: 250
etotali01: 370300.400000142, etotali02: 1242384.28681575, etotali03: 3261931.57400005, etotali04: -
pvrl01: 6, pvrl02: 465, pvrl03: 42, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 313, con: 525, gcons: 100, conprice: -
gfeedin: 0, feedprice: -
DoN: 1, sunaz: 66, sunalt: 9
batintotal01: 256381.3, batintotal02: -, batintotal03: -
batouttotal01: 239815.9, batouttotal02: -, batouttotal03: -
batprogsoc01: 10.0, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 1019
batsoc01: 9.1, batsoc02: -, batsoc03: -, socwhsum: 932
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 88, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
weatherid: 2, wcc: 78, rr1c: 0.00, pvcorrf: 0.66/0.49 temp: 12.80,
csmt01: 27785.122, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13872.337, csme04: 0.208999999998923, minutescsm04: 0
csmt05: 21672.333, csme05: 1.48300000000017, minutescsm05: 60
csmt06: 48598.948, csme06: 112.272999999994, minutescsm06: 60
csmt07: 4154.451, minutescsm07: 0
csmt08: 540.159, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
08 => pvfc: 1342, pvrl: 669, pvrlvd: 1, rad1h: 620
etotali01: 370307.300000141, etotali02: 1242850.24389666, etotali03: 3261974.49800005, etotali04: -
pvrl01: 16, pvrl02: 591, pvrl03: 62, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 209, con: 486, gcons: 5, conprice: -
gfeedin: 1, feedprice: -
DoN: 1, sunaz: 76, sunalt: 18
batintotal01: 256470, batintotal02: -, batintotal03: -
batouttotal01: 239816.1, batouttotal02: -, batouttotal03: -
batprogsoc01: 21.1, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 2157
batsoc01: 11.1, batsoc02: -, batsoc03: -, socwhsum: 1137
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 207, batin02: -, batin03: -
batout01: 20, batout02: -, batout03: -
weatherid: 3, wcc: 88, rr1c: 0.00, pvcorrf: 0.96/0.95 temp: 13.60,
csmt01: 27785.122, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27735.664, csme03: 0, minutescsm03: 0
csmt04: 13872.337, csme04: 0, minutescsm04: 0
csmt05: 21673.392, csme05: 1.05900000000111, minutescsm05: 42
csmt06: 48713.541, csme06: 114.593000000001, minutescsm06: 60
csmt07: 4155.035, minutescsm07: 0
csmt08: 540.845, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
09 => pvfc: 2164, pvrl: 1111, pvrlvd: 1, rad1h: 1060
etotali01: 370323.80000014, etotali02: 1243441.5859535, etotali03: 3262036.81400005, etotali04: -
pvrl01: 35, pvrl02: 972, pvrl03: 104, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 1292, con: 825, gcons: 5, conprice: -
gfeedin: 2, feedprice: -
DoN: 1, sunaz: 87, sunalt: 28
batintotal01: 256677, batintotal02: -, batintotal03: -
batouttotal01: 239836.9, batouttotal02: -, batouttotal03: -
batprogsoc01: 22.8, batprogsoc02: -, batprogsoc03: -, socprogwhsum: 2331
batsoc01: 15.1, batsoc02: -, batsoc03: -, socwhsum: 1546
lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
batin01: 268, batin02: -, batin03: -
batout01: 1, batout02: -, batout03: -
weatherid: 2, wcc: 52, rr1c: 0.00, pvcorrf: 1.00/- temp: 14.60,
csmt01: 27785.122, csme01: 0, minutescsm01: 0
csmt02: 1920946.04, csme02: 0, minutescsm02: 0
csmt03: 27814.261, csme03: 78.5969999999979, minutescsm03: 16
csmt04: 13872.337, csme04: 0, minutescsm04: 0
csmt05: 21673.392, csme05: 0, minutescsm05: 0
csmt06: 48828.8, csme06: 115.259000000005, minutescsm06: 60
csmt07: 4155.648, minutescsm07: 0
csmt08: 541.554, minutescsm08: 0
csmt09: 15583.828, minutescsm09: 0
Hallo Wolle02,
ZitatAus der pvHistory sehe ich, dass sich die Verbrausprognose (confc) Nachts immer so um einen Wert zwischen 30 - 100 Watt bewegt, während der reale Verbrauch (con) sich immer dauerhaft zwischen 350 - 500 Watt bewegt; sollte sich das lernende System hier nicht anpassen?
Deine Vorschläge bezüglich plantControl->consForecastIdentWeekdays=1 / plantControl->consForecastLastDays=4 habe ich umgesetzt.
Ja, das passiert auch. Aber das ist ein langsamer Prozess. Lernen ist aktuell der falsche Ausdruck, es gibt noch keine KI beim Verbrauch im Spiel. Aber es werden die historischen Werte über statistische Methoden (Median bei größerem Blick in die Vergangenheit) ausgewertet.
Löschen würde ich nicht wegen dieser Thematik, die History erneuert sich mit jeden Tag. Nach spätestens 31 Tagen ist sie komplett mit aktualisierten Werten ersetzt.
Aber mit der aktuellen Version kannst du gern mal etwas spielen, z.B.:
plantControl->consForecastIdentWeekdays=1 / plantControl->consForecastLastDays=4 oder
plantControl->consForecastIdentWeekdays=1 / plantControl->consForecastLastDays=2 oder
plantControl->consForecastIdentWeekdays=1 / plantControl->consForecastLastDays=8 oder
plantControl->consForecastIdentWeekdays=0 / plantControl->consForecastLastDays=40 oder
plantControl->consForecastIdentWeekdays=0 / plantControl->consForecastLastDays=80 ....
Versuche so einen für dein System passenden Modus zu finden.
LG,
Heiko
Zitat von: DS_Starter am 03 Juni 2025, 00:25:44@all,
ich habe den Request von Parallix aus #3067 umgesetzt, im contrib liegt die V 1.52.9.
Dazu gibt es einen neuen Key in ctrlBatSocManagementXX -> [loadAbort=<SoC>:<PowerIn>]
loadAbort Bedingung für einen generellen Ladeabbruch. Die Bedingung ist erfüllt, wenn der angegebene
SoC (%) erreicht bzw. überschritten ist UND die angegebene Ladeleistung (W)
unterschritten wurde -> Reading Battery_ChargeAbort_XX = 1.
Fällt der aktuelle SoC wieder unter den angegebenen SoC, wird Battery_ChargeAbort_XX = 0
Zur Signalisierung der Abbruch-Condition habe ich das Reading Battery_ChargeAbort_XX eingeführt, welches man in den Steuerungsroutinen für die Batterie auswerten kann.
@Parallix, vllt. kannst du es mal testen ob die Logik deinen Request abbildet.
Grüße,
Heiko
Danke Dir Heiko! das neue Reading kann ich nun heranziehen, um aktiv zu werden, wenn die potenziell kritische Situation eintritt. Konkret prüfe ich dann (wenn Battery_ChargeAbort_XX == 1), ob es in der betreffenden BAT eine Zelle gibt, die sich anschickt, nach oben zu schießen. Ist dies der Fall, unterbreche ich die Ladung.
Hi Heiko,
ich habe ein Anzeige Problem seit dem letzten Update.
Für mein Tablet UI scheint der Header etwas breit geworden zu sein.
Ich war jetzt einige Zeit weg und habe eventuell etwas überlesen.
Im Anhang mal ein Screenshot was ich meine.
Ich denke bei Autokorrektur ist es länger geworden.
Danke und Gruß,
Stefan
Hi Stefan,
das kommt sicherlich durch "Start in xx h". Dieser Zusatz kommt nur bei Änderung des setupInverterDevXX. Ist aber nicht neu und verschwindet nach Ablauf der Wartezeit.
Ich mache gerade eine "kreative Pause". 😉
Grüße,
Heiko
Danke Heiko,
ja das setupInverterDevXX wurde durch das Update angefasst.
Die Meldung "Start in xx h" ist nun verschwunden und es passt alles wieder ;-)
Danke und viel Erholung in der kreativen Pause.
Zitat von: stefanru am 06 Juni 2025, 18:27:49Hi Heiko,
ich habe ein Anzeige Problem seit dem letzten Update.
Für mein Tablet UI scheint der Header etwas breit geworden zu sein.
Wie kann man den Akkufüllstand dort einblenden? Besten Dank!
Zitat von: Persuasiv am 06 Juni 2025, 21:20:04Wie kann man den Akkufüllstand dort einblenden? Besten Dank!
Das kannst du beim setupBatteryDevXX mit show festlegen
show Steuerung der Anzeige der Batterie in der Balkengrafik (optional)
0 - keine Anzeige des Gerätes (default)
1..3[:top|bottom] - Anzeige des Gerätes in der Ebene 1,2 oder 3 (über|unter) den Balken
Zitat von: grappa24 am 24 Mai 2025, 17:48:23Hab jetzt endlich eine Möglichkeit gefunden, pvIn/pvOut beim Fronius SymoGEN24 korrekt abzugreifen und komme auf Wandlungsverluste von 2-5 %
Hallo Grappa,
welche Werte vom SymoGen24 nimmst Du hier nun für pvIn/pvOut?
Danke für Deine Hilfe,
Bozan
Zitat von: Bozan am 07 Juni 2025, 20:31:16welche Werte vom SymoGen24 nimmst Du hier nun für pvIn/pvOut?
pvOut=Inverter_Common_PAC_Value - PowerFlow_Site_P_Akku
pvIn=Inverter_Common_IDC_Value * Inverter_Common_UDC_Value + Inverter_Common_IDC_2_Value * Inverter_Common_UDC_2_ValueAusgangsleistung als Summe aus der Wechselstromleistung PAC des Inverters plus das was aus der Batterie kommt (ist negativ, deshalb minus)
Eingangsleistung als I*U meiner beiden Strings
100% sicher bin ich mir zwar nicht, liefert aber sehr plausible Werte und flow-Grafik; konnte es noch nicht für alle Situationen testen.
Die letzten Tage habe ich mich mit Strategien zur optimalen Batteriebeladung beschäftigt und mir dabei u.a. auch das Beispiel ,,Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie" angesehen. Hierbei ist mir aufgefallen, dass diese und meine (sehr ähnliche) Lösung nicht optimal ist, da ein fixer ,,Verkürzungsfaktor Zeit bis Vollladung vor Sunset" verwendet wird.
Was man bräuchte wäre einige wenige gemäß Forecast berechnete Readings:
Eins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.
Zusätzlich bräuchte man noch ein Reading mit der Anzahl der verbleibenden Stunden ohne Ladeempfehlung (Battery_RemainingHoursWithoutChargeRecommendation_XX).
Insofern möchte ich vorschlagen, die o.g. (special)Readings noch in SF aufzunehmen.
Nachtrag 1: Aufgefallen ist mir auch, dass die bisherige SoC-Prognose in SF von einer Ladung mit maximal zur Verfügung stehenden Überschussleistung ausgeht. Im dem in Wiki beschriebenen Beispiel (,,Dynamische Ladestromsteuerung eines Victron ...") ist dies aber nicht der Fall. Abhilfe könnte eine vom User anpassbare Methode schaffen, die maximalen Ladeleistungen für die restlichen Stunden des Tages liefert.
Nachtrag 2: Dass upSoC und lowSoC Attribute sind, halte ich persönlich für ungünstig. Grund: upSoC ist - nach meinem Verständnis - optimal gesetzt, wenn die BAT nach einen (abendlichen) Dunkelzyklus mindestens noch lowSoc erreicht. Beide Werte müssten hierzu im Jahresverlauf programmgesteuert angepasst werden können, was vorliegend aber nicht geht. Daher schlage ich vor, beide in ein Reading zu überführen.
Hallo DS_Starter,
ich habe wohl aus versehen was an meinem Forecast Modul verstellt. Leider weiß ich nicht wo ich den Fehler suchen soll. Kannst du mir helfen wo ich in den Einstellungen nachschauen muß?
Mein Forecast sieht wie folgt aus:
Moin,
Ich bin zur Zeit unterwegs und kann erst kommende Woche wieder aktiv sein. Vllt. Kann die Community helfen. Das Bild alleine hilft nicht viel. Da sind mehr Infos nötig wie das verwendete Model, die verwendete Autokorrektur etc. Ich tippe ins Blaue, du hast KI eingeschaltet, aber evtl. Ungenügende Trainingsdaten. Aber kann auch etwas anderes sein. Zumindest vermute ich, du meinst mit der Frage die starken Sprünge in den Stundenvorhersagen.
Lg,
Heiko
Zitat von: Bison am 08 Juni 2025, 22:15:38ich habe wohl aus versehen was an meinem Forecast Modul verstellt. Leider weiß ich nicht wo ich den Fehler suchen soll. Kannst du mir helfen wo ich in den Einstellungen nachschauen muß?
Vlt. einfach auf die configdb umstellen, dann kann man problemlos ältere Versionen - sofern diese auch wirklich liefen - eines Devices wiederherstellen.
LG
pah
Hallo DS_Starter,
ja das mit der KI könnte sein. Ich habe glaube in den Reiter Autokorrektur auf on_complex_ai gesetzt. Heute sind die Lücken kleiner geworden. Also ich beobachte es jetzt mal.
Wücnche dir noch einen schönen #urlaub und danke für das tolle Tool.
Gruß Bison
@Heiko, ich habe die aktuelle Version auf meinem Testystem und die Batterieanzeige aktiviert.
Da ich an diversen Stellen in meinem System mit Batterie Icons von rot über gelb nach grün spiele und ich vor einger Zeit im Wiki einen uiTable Beitrag von Damian gelesen habe wo er IstWerte von 0 bis 100 in RGB Werte von FF0000 bis 00FF00 umrechnet wollte ich auch so etwas haben.
Anbei eine kleine abgespeckte Sub :
sub hsv{
my $cur= shift;
$cur = 100 if ($cur>100);
$cur = 0 if ($cur<0);
my $h = $cur * 0.003333;
my ($r,$g,$b) = Color::hsv2rgb ($h,1,1);
$r *= 255;
$g *= 255;
return sprintf("#%02X%02X00", $r+0.5, $g+0.5);
}
ich habe die in meinem SolarForecast drin und verwende stat "gray" bzw #cccccc hsv($soc) für die History und Forecast Batterie Icons einzufärben.
Der Screenshot ist halt nicht so toll da mein Speicher z.Z immer relativ voll ist
Hallo zusammen,
nun tritt das SF Modul bei mir wieder mehr in den Fokus. Nach einer längeren Abstinenz muss ich mich wieder langsam herantasten was eigentlich der letzte Stand war, an dem ich anknüpfen wollte. Ist schon eigenartig, so lange war die Zeit doch gar nicht. ;)
@Parallix,
was ich an zusätzlichen Readings liefern kann, stelle ich gern zur Verfügung, muß die Details mir erstmal anschauen.
ZitatNachtrag 1: Aufgefallen ist mir auch, dass die bisherige SoC-Prognose in SF von einer Ladung mit maximal zur Verfügung stehenden Überschussleistung ausgeht. Im dem in Wiki beschriebenen Beispiel (,,Dynamische Ladestromsteuerung eines Victron ...") ist dies aber nicht der Fall. Abhilfe könnte eine vom User anpassbare Methode schaffen, die maximalen Ladeleistungen für die restlichen Stunden des Tages liefert.
Der User kann mit dem Schlüssel pinmax die maximal mögliche Ladeleistung in Watt festlegen. mit welcher die Batterie geladen werden kann. Dieser Wert wird durch die SoC-Prognose auch beachtet.
Der User kann diesen Schlüssel dynamisch setzen mit:
set ... attrKeyVal setupBatteryDevXX pinmax=<Wert> D.h., das Script aus dem Wiki kann um einen solchen Befehl ergänzt werden um SF die Einstellung für den Lader mitzuteilen. (Zur Zeit der Erstellung des Wiki-Beitrages gab es attrKeyVal bzw. die aktuelle Bat-Prognose noch nicht).
ZitatNachtrag 2: Dass upSoC und lowSoC Attribute sind, halte ich persönlich für ungünstig. Grund: upSoC ist - nach meinem Verständnis - optimal gesetzt, wenn die BAT nach einen (abendlichen) Dunkelzyklus mindestens noch lowSoc erreicht. Beide Werte müssten hierzu im Jahresverlauf programmgesteuert angepasst werden können, was vorliegend aber nicht geht. Daher schlage ich vor, beide in ein Reading zu überführen.
Eine Überführung in ein Reading ist durch die Verfügbarkeit von attrKeyVal nicht (mehr) nötig.
Der User kann den/die Schlüssel mit:
set ... attrKeyVal ctrlBatSocManagementXX lowSoc=<Wert> upSoC=<Wert> dynamisch setzen.
Allerdings ist m.M. nach im Normalfall keine ständige Änderung nötig, da dieser Wert im Prinzip während der Zeiten mit sehr wenig Solarerzeugung einen Mindestvorrat an Energie für den Fall des Netzausfalls in der Batterie belässt. (siehe diesen Beitrag (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Nutzung_des_Batterie_SOC-Management) im Wiki).
@Wzut,
deinen Vorschlag kann ich gern in den Standard übernehmen, sodass der User im icon-Schlüssel eine solche Gestaltung wählen kann.
LG,
Heiko
Guten Morgen,
@grappa24,
mir ist beim Lesen der letzten Beiträge aufgefallen:
ZitatAusgangsleistung als Summe aus der Wechselstromleistung PAC des Inverters plus das was aus der Batterie kommt (ist negativ, deshalb minus)
Der Wert pvOut wird vom Modul als PV-Erzeugung gewertet. D.h., wenn dort Batterie-Anteile drin sind, wird deine reale Erzeugung gegenüber der Prognose falsch interpretiert und führt dann zu falschen Korrekturfaktoren etc.
Als Alternative (solange ich keinen Hybridwechselrichter als Typ integriert habe) bietet sich an zwei Inverterdevices im Modul anzulegen, einen PV-Wechselrichter und einen Batterie-Wechselrichter. Durch die Angabe der Readings gemäß der verwendeten Logik in der Attributschlüsseln wird es dann richtig abgebildet und auch richtig interpretiert.
LG,
Heiko
Ich versuche aktuell einen Hybridwechselrichter noch besser in das Modul einzubinden. Die Einrichtung des PV-Inverter hat geklappt, aber beim Einrichten des Batterieinverters sagt er: "An inverter with connected solar cells don't need the key 'ac2dc'. Please delete this key." bzw. "An inverter with connected solar cells don't need the key 'dc2ac'. Please delete this key."
Was mache ich falsch?
Zitat von: Wzut am 14 Juni 2025, 18:38:55ich habe die in meinem SolarForecast drin und verwende stat "gray" bzw #cccccc hsv($soc) für die History und Forecast Batterie Icons einzufärben.
Der Screenshot ist halt nicht so toll da mein Speicher z.Z immer relativ voll ist
Kannst Du die Definition von deinem setupBatteryDev01 (inkl. Icon) posten? Besten Dank!
@Persuasiv,
wenn du einen Batteriewechselrichter definieren willst, musst du strings=none setzen.
Commandref -> Batterie-Wechselrichter
Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer
Batterie und dem Hausnetz.
Die Funktion als Batterie-Wechselrichter wird mit strings=none aktiviert.
Das Feature von Wzut bin ich gerade dabei einzubauen. Ihr bekommt nachhher noch die Info wenn die V im Contrib ist zum Ausprobieren.
Zitat von: Persuasiv am 15 Juni 2025, 10:54:12Kannst Du die Definition von deinem setupBatteryDev01 (inkl. Icon) posten? Besten Dank!
Das bringt dich nicht weiter , da es in meinem setupBatteryDev01 keinen icon= Eintrag gibt.
Meine vorgeschlagene Einfärbung rot-grün betrift alle Icons links und rechts der aktuellen Stunde.
Ich versuche mich auch gerade am Batterie-Wechselrichter, bekomme aber keine Werte an den Flüssen dargestellt
setupInverterDev01 (PV-WR)
SymGen24 icon=inverter@#ff8c00:inverter@grey capacity=10000 strings=suedwest,nordost etotal=User_Produced_PV:kWh pvOut=Inverter_Cumulation_PAC_Value:WsetupInverterDev02 (Batterie-WR)
BatteryDummy strings=none ac2dc=total_pac:W dc2ac=-total_pac:W capacity=7680
wobei total_pac = PowerFlow_Site_P_Akku
In meinem contrib liegt die V 1.52.12
Die Anregung von Wzut ist in den Kontext des Moduls eingebaut und angepasst.
Im setupBatteryDevXX kann die Farbe des/der Icons zur Darstellung der Batterie in der Balkengrafik dynamisch abhängig vom SoC-Wert dargestellt werden. Die Farbangabe ist dann einfach nur "dyn".
Für das Batterie Icon gibt es ja die Möglichkeit, ein separates Icon bzw. eine Farbe getrennt für jede Ladungsphase zu definieren:
<empfohlen> - Icon wenn die Aufladung empfohlen, aber inaktiv ist (kein Aufladen / Entladen)
<aufladen> - Icon wird verwendet wenn die Batterie aktuell aufgeladen wird
<entladen> - Icon wird verwendet wenn die Batterie aktuell entladen wird
<unterlassen> - Icon wenn Aufladen nur bei Überschreitung des Einspeiselimits empfohlen
In dem Kontext der Batteriedarstellung bietet es sich an, nur die Farben der Symbole anzupassen wenn gewünscht, die Batterie-Icons aber zu belassen. Das war bis jetzt schon so und empfohlen.
Nun kann man für jede einzelne der Phasen die dynamische Farbanpassung auswählen. Will man zum Beispiel nur eine SoC-abhängige Farbanpassung für den Zustand <empfohlen> oder <unterlassen> haben, würde man definieren:
icon=@dyn:::@dyn
Möchte man in allen Phasen den Default überschreiben, würde man setzen:
icon=@dyn:@dyn:@dyn:@dyn
Der ":" trennt die Icons@Farben der einzelnen Batteriephasen voneinander.
Auch bei der dynamischen Farbgestaltung wird der Zustand <unterlassen> durch eine Verringerung der Deckkraft (siehe Screenhot) signalisiert. Dadurch ist dieser Modus auch bei Verwendung von 'dyn' gut erkennbar.
Nach Download der V wie üblich bitte restarten.
LG,
Heiko
@grappa24,
das
ac2dc=total_pac:W dc2ac=-total_pac
gibt es bei den Wechselrichtern nicht. Gibt es nur bei den Batteriedevices.
So müsste die Definition aussehen:
BatteryDummy strings=none ac2dc=<Reading für AC-DC>:W dc2ac=<Reading für DC-AC>:W capacity=7680
Hier mal meine für einen Batterie-WR zum Vergleich:
MQTT2_cerboGX_c0619ab34e08_vebus
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
asynchron=0
Ergebnis sieht aus wie im Screenshot.
Das mit dyn wäre auch eine Möglichkeit für graphicWeatherColor. Ist nur eine Spielerei die nicht wichtig ist.
Hallo Heiko,
das ist ja ein schönes Farbenspiel !!!!
Gruß
300P
Ein schöner Impuls von Wzut. :)
Man muß natürlich schauen, wieviel Farbe man in den Grafiken möchte und es vertragen wird ohne überladen zu wirken. Aber das kann ja jeder selbst entscheiden.
Also wenn es passt, dann würde ich die V heute einchecken und morgen ist sie im Update.
Ich finde es gut. Es ist optional, da kann sich niemand beschweren.
Ist eingecheckt.
ich konnte den Batterie-WR nun einrichten:
SymGen24 strings=none ac2dc=PowerFlow_Site_p_Akku:W dc2ac=PowerFlow_Site_P_Akku:W capacity=7680 asynchron=1
Was mich noch nicht verstehe:
Bei sehr kleinen "Flüssen" (so um die 1-2 W) zwischen Batterie und Inverter- bzw. Hausknoten werden diese nicht zwischen dem neuen Batterie-WR und der Batterie angezeigt sondern wie "früher" zwischen Batterie und Inverter- bzw. Hausknoten.
Dabei kann es sich um Selbstverbräuche der Geräte handeln. Wenn z.B. 1-2W in einen Batterie-WR hineinfließen, aber nicht hinaus, gibt es bei den umfangreichen Differenzbetrachtungen bzgl. der Flüsse einen Fehlbetrag. Dieser Betrag wird letztendlich zum Hausknoten geleitet und dann beim Verbraucher "nicht zuordenbarer Energie" grafisch abfließen.
Wir haben in jedem Gerät Verlustenergie, die in der Summenbetrachtung irgendwohin "fließen" muß.
Zitat von: 300P am 15 Juni 2025, 17:58:12Hallo Heiko,
das ist ja ein schönes Farbenspiel !!!!
Gruß
300P
Mag ja sein, dass das schön bunt erscheint - aber inhaltlich habe ich gewisse Zweifel. Um 5:00 früh soll der blaue Balken 10% und der grüne Balken 15% darstellen. Das sieht aber nicht anders aus, als um 6:00 früh mit 2x 10%. Und auch danach bis zur Mittagszeit wird durch den Ansatz, den zweiten Wert unbedingt vor dem grünen Hintergrund darstellen zu wollen, der Informationsgehalt der Balken negiert - das kann man also auch sein lassen.
Statt also dies durch irgendwelche Batteriesymbole (die letztlich keine zusätzliche Information darstellen) zu doppeln, wäre eine bessere Balkendarstellung zu empfehlen.
Auch aus anderer Sicht ist das ziemlich sinnfrei: Helles Rot vor hellem Grün ist ergonomisch einfach ein No-Go.
Sorry für die Kritik.
LG
pah
Da ich so ziemlich keine Zwischentöne in der Farbgebung erkenne (man könnte es evtl. auch farbenblind nennen) stelle ich es bei mir so ein das es (für mich) einfach erkennbar ist - egal ob dies manchem ,,in die Augen beißt" oder nicht 😉
Wir sind ein freies Land, jeder kann machen was er will.
Aber: Die gewöhnliche "Farbenblindheit" ist eine Rot-Grün-Unterscheidungsschwäche. Gerade deswegen sollte man nicht mit Rot auf Grün "schreiben". Das hat also nichts mit subjektivem "Beißen" zu tun.
Meine Hauptkritik richtete sich aber nicht auf die Farbwahl, sondern auf die Doppelung der Informationen in den Icons und den seltsamen Balken.
LG
pah
Zitat von: Bison am 10 Juni 2025, 08:10:31Hallo DS_Starter,
ja das mit der KI könnte sein. Ich habe glaube in den Reiter Autokorrektur auf on_complex_ai gesetzt. Heute sind die Lücken kleiner geworden. Also ich beobachte es jetzt mal.
Wücnche dir noch einen schönen #urlaub und danke für das tolle Tool.
Gruß Bison
Zitat von: Bison am 10 Juni 2025, 08:10:31Hallo DS_Starter,
ja das mit der KI könnte sein. Ich habe glaube in den Reiter Autokorrektur auf on_complex_ai gesetzt. Heute sind die Lücken kleiner geworden. Also ich beobachte es jetzt mal.
Wücnche dir noch einen schönen #urlaub und danke für das tolle Tool.
Gruß Bison
Zitat von: DS_Starter am 09 Juni 2025, 08:01:44Moin,
Ich bin zur Zeit unterwegs und kann erst kommende Woche wieder aktiv sein. Vllt. Kann die Community helfen. Das Bild alleine hilft nicht viel. Da sind mehr Infos nötig wie das verwendete Model, die verwendete Autokorrektur etc. Ich tippe ins Blaue, du hast KI eingeschaltet, aber evtl. Ungenügende Trainingsdaten. Aber kann auch etwas anderes sein. Zumindest vermute ich, du meinst mit der Frage die starken Sprünge in den Stundenvorhersagen.
Lg,
Heiko
Hallo DS_Starter,
ich habe immer noch große Sprünge in dem Forcast nach dem Umschalten auf KI. Das läuft nun schon seit 8 Tagen. Muß ich mich noch gedulden oder an die Fehlersuche gehen.
Ich habe folgendes eingestellt:
- Modul Version: 1.52.12, Model: OpenMeteoDWDAPI
- Autokorrektur on_complex_ai
Der Check zeigt keine Fehler.
Gruß Bison
8 Tage Lerndaten ist einfach deutlich zu wenig. Du kannst dir einen Überblick über die gespeichteren Rohdaten für den Lernvorgang anschauen mit:
get ... valDecTree aiRawData
Bei mir sind bereits
Number of datasets: 8994
gespeichert. Aus diesem Wertevorrat leitet die KI über den Lernvorgang Vorhersagen für zukünftige Wetter/Strahlungsdaten bei entsprechenden Sonnenständen, Niederschlagen etc, ab.
Man hat eine ungefähre Vorstellung vom Lernzustand mit:
get ... valDecTree aiRuleStrings
Die erreichte Anzahl an Rules, Nodes und der Tiefe Depth geben ganz grob einen Hinweis auf welchen Vorrat an Verknüpfungen/Entscheidungen die KI zurückgeifen kann.
Trained AI Object contains an Ensemble of 10 trees (only the first Tree is printed out)
Tree: 1 -> Number of Rules: 5892 / Number of Nodes: 7940 / Depth: 5
Tree: 2 -> Number of Rules: 5903 / Number of Nodes: 7952 / Depth: 6
Tree: 3 -> Number of Rules: 5909 / Number of Nodes: 7959 / Depth: 6
Tree: 4 -> Number of Rules: 5889 / Number of Nodes: 7904 / Depth: 6
Tree: 5 -> Number of Rules: 5888 / Number of Nodes: 7929 / Depth: 5
Tree: 6 -> Number of Rules: 5892 / Number of Nodes: 7901 / Depth: 6
Tree: 7 -> Number of Rules: 5894 / Number of Nodes: 7919 / Depth: 6
Tree: 8 -> Number of Rules: 5886 / Number of Nodes: 7893 / Depth: 6
Tree: 9 -> Number of Rules: 5889 / Number of Nodes: 7900 / Depth: 6
Tree: 10 -> Number of Rules: 5898 / Number of Nodes: 7915 / Depth: 6
Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen
letztes KI-Training: 16.06.2025 02:15:27 / Laufzeit in Sekunden: 3.75761
letzte KI-Ergebnis Generierungsdauer: 0.06 ms
Wie sind deine Daten im Vergleich dazu?
PS: Als Ausblick bin ich inzwischen der Ansicht mit einem eigenen entworfenen neuronalen Netzwerk bessere Ergebnisse erreichen zu können. Aber den Beweis nuß ich erstmal noch antreten und die Zeit dazu finden. ;)
Hallo DS_Starter,
hier mal meine Daten:
aiRawData
Number of datasets: 6765
2024040416 => hod: 16, nod: -, sunaz: 223, sunalt: 40, rad1h: 2160, wcc: 100, wid: -, rr1c: 0.30, pvrl: 95, con: -, gcons: -, temp: 15
2024040417 => hod: 17, nod: -, sunaz: 239, sunalt: 30, rad1h: 1850, wcc: 100, wid: -, rr1c: 0.40, pvrl: 76, con: -, gcons: -, temp: 15
2024040418 => hod: 18, nod: -, sunaz: 252, sunalt: 25, rad1h: 2350, wcc: 100, wid: -, rr1c: 0.00, pvrl: 109, con: -, gcons: -, temp: 15
2024040419 => hod: 19, nod: -, sunaz: 264, sunalt: 15, rad1h: 880, wcc: 70, wid: -, rr1c: 0.00, pvrl: 81, con: -, gcons: -, temp: 15
aiRuleStrings
Trained AI Object contains an Ensemble of 10 trees (only the first Tree is printed out)
Tree: 1 -> Number of Rules: 4280 / Number of Nodes: 5639 / Depth: 6
Tree: 2 -> Number of Rules: 4283 / Number of Nodes: 5640 / Depth: 5
Tree: 3 -> Number of Rules: 4289 / Number of Nodes: 5658 / Depth: 5
Tree: 4 -> Number of Rules: 4287 / Number of Nodes: 5640 / Depth: 6
Tree: 5 -> Number of Rules: 4289 / Number of Nodes: 5622 / Depth: 6
Tree: 6 -> Number of Rules: 4287 / Number of Nodes: 5644 / Depth: 6
Tree: 7 -> Number of Rules: 4281 / Number of Nodes: 5638 / Depth: 6
Tree: 8 -> Number of Rules: 4284 / Number of Nodes: 5630 / Depth: 6
Tree: 9 -> Number of Rules: 4296 / Number of Nodes: 5651 / Depth: 6
Tree: 10 -> Number of Rules: 4289 / Number of Nodes: 5640 / Depth: 6
Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen
letztes KI-Training: 17.06.2025 02:16:00 / Laufzeit in Sekunden: 10.07013
letzte KI-Ergebnis Generierungsdauer: 0.22 ms
Ich habe gestern mal die Autokorrektur auf on_complex_api_ai umgestellt. Damit sind die die Löcher nicht mehr so groß. Ich werde mir mal heute das Abweichungsergeniss anschauen. Vielleicht komme ich dann der Lösung näher.
Gruß Bison
Zitat von: Prof. Dr. Peter Henning am 16 Juni 2025, 20:07:54Wir sind ein freies Land, jeder kann machen was er will.
Aber: Die gewöhnliche "Farbenblindheit" ist eine Rot-Grün-Unterscheidungsschwäche. Gerade deswegen sollte man nicht mit Rot auf Grün "schreiben". Das hat also nichts mit subjektivem "Beißen" zu tun.
Meine Hauptkritik richtete sich aber nicht auf die Farbwahl, sondern auf die Doppelung der Informationen in den Icons und den seltsamen Balken.
LG
pah
Mein erster Eindruck zu den dyn-Icons war durchwegs positiv, nun erkenne ich aber, dass - aus meiner Sicht - wertvolle Infos nicht mehr dargestellt werden. Also stelle ich mir die Frage, was denn alles in einem Bild dargestellt werden sollte und komme zu folgendem Ergebnis:
- Ladezustand, möglichst fein aufgelöst
- Ladefreigabe
Wären o.g. Infos nicht perfekt mit einer klassischen, ggf. dyn. eingefärbten Balkengrafik mit einem auf [0:100] fixiertem Bereich darstellbar, bei der der prozentuale Ladezustand als Zahl über dem jeweiligen Balken steht und ein "LF" im unteren Teil des Balkens die (prognostizierte) Ladefreigabe visualisiert?
Zitat von: Parallix am 17 Juni 2025, 08:19:10Wären o.g. Infos nicht perfekt mit einer klassischen, ggf. dyn. eingefärbten Balkengrafik mit einem auf [0:100] fixiertem Bereich darstellbar, bei der der prozentuale Ladezustand als Zahl über dem jeweiligen Balken steht und ein "LF" im unteren Teil des Balkens die (prognostizierte) Ladefreigabe visualisiert?
Eines der Hauptprobleme in der unten angesprochenen Grafik war ja, dass bei _zwei_ Werten das Einschreiben der Zahlen in den oberen Balken diesen total zerstört hat (eben künstlich verlängert, damit die Zahl hineinpasst). Man müsste also bei zwei Werten die Zahl über den jeweils oberen Balken schreiben - das ist aber auch ungünstig, weil dann evtl. mal der eine und mal der andere durch die obere Zahl repräsentiert würde.
Nebeneinander gestapelte Balken sind auch nicht auf einen Blick ablesbar.
Nach einigem Überlegen würde ich sagen: Bei mehr als einem zu visualisierenden Wert für 2 Speicher: _gestapelte_ Balken, die höchstens zusammen 100% ergeben.
Bei einem oder mehreren Speicherwerten und einer "Ladefreigabe" würde ich die Ladefreigabe durch eine Farbtonänderung der Balken im "freien" Bereich angeben - etwa, indem man halbtransparent weiß darüber legt. Etwa so, wie im angehängten Bild, auf die Schnelle.
Zu überlegen wäre auch, Zahlen nur einzublenden, wenn man mit dem Mauszeiger über die Grafik fährt - so wie das bei den SVG-Plots von FHEM der Fall ist.
LG
pah
Zitat von: DS_Starter am 14 Juni 2025, 23:04:37...
Der User kann mit dem Schlüssel pinmax die maximal mögliche Ladeleistung in Watt festlegen. mit welcher die Batterie geladen werden kann. Dieser Wert wird durch die SoC-Prognose auch beachtet.
Der User kann diesen Schlüssel dynamisch setzen mit:
set ... attrKeyVal setupBatteryDevXX pinmax=<Wert>
Jede Änderung eines Attributs führt aber dazu, dass eine Konfigurationsänderung vorliegt. die auch entsprechend anzeigt wird und diesem Hinweis nur via "Save config" nachgegangen werden kann. Daher ist es unschön, dyn. Änderungen auf Basis von Attributen vorzunehmen und wünsch(t)e mir daher eine Überführung in ein Reading zur dyn. Konfiguration.
Zitat von: Prof. Dr. Peter Henning am 17 Juni 2025, 08:34:47...
Nach einigem Überlegen würde ich sagen: Bei mehr als einem zu visualisierenden Wert für 2 Speicher: _gestapelte_ Balken, die höchstens zusammen 100% ergeben.
Bei einem oder mehreren Speicherwerten und einer "Ladefreigabe" würde ich die Ladefreigabe durch eine Farbtonänderung der Balken im "freien" Bereich angeben.
...
Oder pro BAT eine (horizontale) Balkengrafik (analog zu den bisherigen BAT-Symbolen) mit einer über dem jeweiligen Balken stehenden Prozentzahl, gefolgt von einem Suffix. welches die Ladefreigabe visualisiert, also z.B. 50+ für SOC=50% und Ladefreigabe erteilt oder 50- für SOC=50% und Ladefreigabe nicht erteilt.
Moin,
@Bison,
die Datenmenge sieht doch gut aus. Da waren die 8 Tage Laufzeit irgendwie ein Mißverständnis.
@Parallix,
Zitatnun erkenne ich aber, dass - aus meiner Sicht - wertvolle Infos nicht mehr dargestellt werden
Welche denn genau? Denn außer einer dynamischen Einfärbung ist kein inhaltlicher Unterschied vorhanden. Die Zeiten ohne Ladeempfehlung werden durch einen verminderten Deckungsgrad signalisiert. (Screenshot)
Edit: Man kann auch für die Zeiten ohne Ladeempfehlung die dynamik ausschalten und den Standard benutzen:
icon=@dyn:::(Screenshot2)
Oder dafür eine dem User genehme alternative Farbe einsetzen.
ZitatWären o.g. Infos nicht perfekt mit einer klassischen, ggf. dyn. eingefärbten Balkengrafik mit einem auf [0:100] fixiertem Bereich darstellbar, bei der der prozentuale Ladezustand als Zahl über dem jeweiligen Balken steht und ein "LF" im unteren Teil des Balkens die (prognostizierte) Ladefreigabe visualisiert?
Das kannst du dir bereits jetzt in einer Ebene einblenden (Screenshot). Fehlt nur das "LF" als Fußtext.
ZitatJede Änderung eines Attributs führt aber dazu, dass eine Konfigurationsänderung vorliegt. die auch entsprechend anzeigt wird und diesem Hinweis nur via "Save config" nachgegangen werden kann.
Normalerweise ja, aber nicht wenn du diesen Setter benutzt da im Hintergrund alles für dich erledigt wird. Dafür gibt es ihn.
In dem Zusammenhang darf dann global->autosave nicht auf "0" gesetzt sein was per default auch nicht der Fall ist.
@pah,
ZitatNach einigem Überlegen würde ich sagen: Bei mehr als einem zu visualisierenden Wert für 2 Speicher: _gestapelte_ Balken, die höchstens zusammen 100% ergeben.
Kein schlechter Gedanke den ich gern mal mit verfolge. Alternativ/ergänzend möchte ich die aktuelle lineare Normalisierung der Balkenhöhen durch den Nutzer auswählbar auf eine logarithmische Normalisierung zur Verfügung stellen. Diese Methode betont kleinere Werte stärker und komprimiert größere Werte, was nützlich sein kann, wenn die Daten eine große Spannweite haben was bei uns durchaus vorkommt.
LG,
Heiko
Zitat von: DS_Starter am 17 Juni 2025, 08:53:10...
@pah,
ZitatNach einigem Überlegen würde ich sagen: Bei mehr als einem zu visualisierenden Wert für 2 Speicher: _gestapelte_ Balken, die höchstens zusammen 100% ergeben.
Kein schlechter Gedanke den ich gern mal mit verfolge. Alternativ/ergänzend möchte ich die aktuelle lineare Normalisierung der Balkenhöhen durch den Nutzer auswählbar auf eine logarithmische Normalisierung zur Verfügung stellen. Diese Methode betont kleinere Werte stärker und komprimiert größere Werte, was nützlich sein kann, wenn die Daten eine große Spannweite haben was bei uns durchaus vorkommt.
...
Wenn eben möglich bitte auch für jedes BAT-System eine eigene Grafik vorsehen. Auf diese Weise lassen sich Lade-/Entlade-Asymmetrien schneller erkennen, was ja auch ein Zweck derartiger Grafiken ist.
Und bedenkt bitte: Der Mensch kann höchstens 10 gleichzeitig angezeigte Farben sicher voneinander unterscheiden.
LG
pah
ZitatWenn eben möglich bitte auch für jedes BAT-System eine eigene Grafik vorsehen.
Dafür haben wir die Möglichkeit mehrere Ebenen aufzumachen und in jeder Ebene dann eben nur mit einem Balken die gewünschten Inforationen anzuzeigen. Die aktuell 3 Ebenen kann ich auch noch auf mehr erweitern je nach Bedarf der Anwender.
Zitat von: DS_Starter am 17 Juni 2025, 08:53:10Alternativ/ergänzend möchte ich als die aktuelle lineare Normalisierung der Balkenhöhen durch den Nutzer auswählbar auf eine logarithmische Normalisierung zur Verfügung stellen.
Ich erinnere mich noch gut an meine ersten Versuche die beiden Werte mit simplen HTML "schön" darzustellen. Bei deutlichen Unterschieden oder wenn die Werte groß genug sind war das alles kein Problem. Kopfschmerzen machten die Sonderfälle : Werte ohne deutliche Differenz oder Gleichheit oder sehr kleine Werte, Das führt alles zum "aufpumpen" der Balken um genügend Platz (Höhe) für die Zahlen zu schaffen. IMHO hatten wir zu Anfang auch mal eine Variante wo die Werte ausserhalb der Balken standen, also eine je eine Zeile über und unter den Balken.
Hi Wzut,
ja ich kann mich auch noch recht gut daran erinnern. Ich glaube ... schon so um die 6 oder 7 Jahre her. Mensch wie die Zeit rennt. :o
Alles hat seine Vor- und Nachteile. Außerhalb der Balken Werte anzeigen kollidiert leicht mit den zuschaltbaren Differenzanzeigen und war auch nicht so toll. Deswegen ist es so wie aktuell auch gut, natürlich mit Verbesserungspotential. Mal sehen was die Loga bringt und/oder der Vorschlag von pah.
Eine kleine Erinnerung für die User, die die Entwicklung noch icht so lange verfolgt haben...
Ich hatte mal einen Vorgänger von SF gebaut der das SMA-Portal als Datenquelle verwendete. Wzut hatte für dieses Modul (SMAPortal) die Balkengrafik gebaut und sehr viel Energie dort hineingesteckt.
Leider konnten wir SMAPortal wegen der Beschränkungen durch SMA nicht weiterführen und ich habe das Projekt sterben lassen.
Besonders der Verlust von Wzut's Arbeit hat mir sehr sehr weh getan und so reifte der Gedanke etwas eigenes auf die Beine zu stellen um die Grafik von Wzut nicht verloren zu geben. Und so ist SF eigentlich als Modul um die "Balkengrafik herum" entstanden.
Naja, so war der Anfang. Seitdem sind schon wieder 5 Jahre vergangen .... und jetzt stehen wir hier mit dieser integrativen Lösung zur Steuerung von Solaranlagen und Verbrauchern und, und ...
Danke mein lieber Wzut!! (Damit musst du jetzt leben) :D
LG,
Heiko
Wie aus der angefügten Grafik zu entnehmen, wird mir für heute und morgen ein schier unglaublicher Verbrauch (da es in meinem Haushalt bis dato keinerlei Großverbraucher gibt) prognostiziert. Das Problem tauchte aber auch heute erst auf, sodass ich davon ausgehe, dass es auf einem Bug basiert. Hat irgendwer ähnlich unplausible Werte nach den letzten Updates bekommen?
Nein, alles normal.
Bei Verbrauchprognose immer schauen wie plantControl->consForecastIdentWeekdays und consForecastLastDays gesetzt ist. Davon hängt ab aus welchem Datenspeicher (pvHistory oder pvCircular) die Prognose abgeleitet wird.
Aber der erste Anlaufpunkt für eine erste Analyse ist das Debugging über ctrlDebug->consumption bzw. consumption_long.
Meist sieht man da schon einen Hinweis auf die Ursache.
Zitat von: DS_Starter am 17 Juni 2025, 10:09:41Nein, alles normal.
Naja, normal ist dieser Verbrauch bei mir nicht ;-)
Zitat von: DS_Starter am 17 Juni 2025, 10:09:41Bei Verbrauchprognose immer schauen wie plantControl->consForecastIdentWeekdays und consForecastLastDays gesetzt ist. Davon hängt ab aus welchem Datenspeicher (pvHistory oder pvCircular) die Prognose abgeleitet wird.
Bei mir wie folgt:
consForecastIdentWeekdays=0 consForecastLastDays=1Zitat von: DS_Starter am 17 Juni 2025, 10:09:41Aber der erste Anlaufpunkt für eine erste Analyse ist das Debugging über ctrlDebug->consumption bzw. consumption_long.
Meist sieht man da schon einen Hinweis auf die Ursache.
Hier brauche ich etwas Hilfe, da mir das Format nicht ganz klar ist. Nehmen wir mal folgendes Beispiel soeben aus SF gezogener Debug-Daten:
01 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
batin01: 0, batin02: 0, batin03: -
batout01: 133, batout02: 135, batout03: -
confc: 90, gcon: 0, gfeedin: 200, wcc: 49, rr1c: 0.00
temp: 19.30, wid: 101, wtxt: -
pprl01: -, pprl02: -, pprl03: -
pvcorrf: -
quality: -
pvrlsum: -
pvfcsum: -
dnumsum: -
con_all => Di @ 119 92 68 105 85 95 87 77 1 83 100 87 49 87 65 30 68 97 68
Do @ 67 85 64 88 102 107 96 3 80 12 50 83 44 60 17 17 6 97
Fr @ 85 223 139 76 81 5 100 83 33 5 41 48 55 40 6 107
So @ 87 93 88 15 89 135 95 2 69 57 65 120 51 11 107 90 21
Sa @ 116 26 87 91 89 55 85 2 17 34 93 24 2 89 29 1 26 21 90
Mo @ 144 47 113 2 62 68 100 1 103 92 22 83 6 25 92 124 123 9 11
Mi @ 82 73 92 69 65 71 103 80 36 200 159 92 44 201 132 144 105 82 84198
gcons_a => Sa @ 0 0 0 0 0 0 0
Fr @ 0 0 0 0 0 0
So @ 0 0 0 0 0 0 0
Do @ 0 0 0 0 0 0
Di @ 0 0 0 0 0 0 0
Mi @ 0 0 0 0 0 84100
Mo @ 0 0 0 0 0 0 0
Hier fällt der große Wert 84198 bei con_all bzw. 84100 bei gcons_a am Mittwoch auf. Welche Energiemengen (Einheit?) sollen denn hier wann bezogen worden sein?
ZitatWelche Energiemengen (Einheit?) sollen denn hier wann bezogen worden sein?
Das sind Wh (der abgefragten Stunde). Werde ich in der Online-Hilfe ergänzen.
Bei der Einstellung
consForecastIdentWeekdays=0 consForecastLastDays=1
wird der nur der gestrige Tag aus der pvHistory verwendet. Hole dir mal bitte die get ... pvHstory 16.
Hallo!
Ich habe irgendwie Schwierigkeiten die Poolpumpensteuerung aus dem Wiki richtig zu verwenden.
Mein Ziel ist es, das die Poolpumpe mind. 3h am Tag läuft. Nach Möglichkeit schon vormittags. Sollte aber nicht genug Strom vorhanden sein, darf es bis 18Uhr das nachholen (zur Not halt auch aus dem Netz)
die 99_mySolarForecastUtils.pm ist angelegt und aus dem Beispiel 1:1 übernommen.
Im SF-Modul habe ich:
attr SF ctrlUserExitFn {\
::pumpControl ($name, '02', 180);;\
}
und
attr SF consumer02 Firmata_Aussensteckdose:Pool\
icon=sani_pump \
type=other \
power=500 \
mode=must \
mintime=480 \
notafter=10\
on=on off=off \
auto=automatic \
interruptable=Firmata_Aussensteckdose:SF_Int:1 \
swoffcond=Firmata_Aussensteckdose:SF_Abort:1
Die Pumpe schaltet meiner Meinung nach etwas willkürlich:
2025-06-15_08:07:27 Firmata_Aussensteckdose automatic: 0
2025-06-15_08:07:33 Firmata_Aussensteckdose automatic: 1
2025-06-15_08:07:39 Firmata_Aussensteckdose automatic: 1
2025-06-15_08:24:29 Firmata_Aussensteckdose automatic: 0
2025-06-15_08:24:35 Firmata_Aussensteckdose automatic: 1
2025-06-15_10:00:04 Firmata_Aussensteckdose on
2025-06-15_10:00:46 Firmata_Aussensteckdose off
2025-06-15_15:01:46 Firmata_Aussensteckdose on
2025-06-15_16:00:07 Firmata_Aussensteckdose off
2025-06-15_16:03:37 Firmata_Aussensteckdose on
2025-06-15_17:06:37 Firmata_Aussensteckdose off
2025-06-15_17:08:57 Firmata_Aussensteckdose on
2025-06-15_17:21:47 Firmata_Aussensteckdose off
2025-06-15_17:35:47 Firmata_Aussensteckdose on
2025-06-15_17:59:07 Firmata_Aussensteckdose off
2025-06-15_18:00:05 Firmata_Aussensteckdose off
2025-06-16_09:46:27 Firmata_Aussensteckdose on
2025-06-16_09:47:37 Firmata_Aussensteckdose off
2025-06-16_14:48:37 Firmata_Aussensteckdose on
2025-06-16_17:47:07 Firmata_Aussensteckdose off
Ist das ein erklärbares verhalten? PV-Strom war gestern den ganzen Tag reichlich vorhanden.
Am Sonntag war das verhalten sehr ähnlich. Da war aber nicht immer genug Strom da. Vor allem stört mich z.B. die Einschaltzeit für weniger als eine Minute um 10Uhr. Das war Sonntag genau so.
Danke für das Modul!
Gruß
Bismosa
Zitat von: DS_Starter am 17 Juni 2025, 10:50:46ZitatWelche Energiemengen (Einheit?) sollen denn hier wann bezogen worden sein?
Das sind Wh (am gesamten Tag). Werde ich in der Online-Hilfe ergänzen.
Pro Zeile sind's ja mehrere Werte, deren Anzahl sich aber von Zeile zu Zeile unterscheidet. wie sieht's mit der zeitlichen Zuordnung aus?
Zitat von: DS_Starter am 17 Juni 2025, 10:50:46Bei der Einstellung
consForecastIdentWeekdays=0 consForecastLastDays=1
wird der nur der gestrige Tag aus der pvHistory verwendet.
Hatte ich mir schon gedacht, obwohl eine Reduzierung der Ausgaben von get() auf Basis der Einstellungen das Debugging unterstützen würde.
Zitat von: DS_Starter am 17 Juni 2025, 10:50:46Hole dir mal bitte die get ... pvHstory 16.
Gerne! Da der Outpunt länglich ist, wohl besser als Datei.
Ich sehe zwei Ausreißerprognosen:
08 => pvfc: 2708, pvrl: 2400, pvrlvd: 1, rad1h: 800
etotali01: 28153200, etotali02: -, etotali03: -, etotali04: -
pvrl01: 2400, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 83786, con: 129, gcons: 0, conprice: 0.40
gfeedin: 2100, feedprice: 0.075
DoN: 1, sunaz: 74, sunalt: 17
batintotal01: 1123491, batintotal02: 1108899, batintotal03: -
batouttotal01: 1020901, batouttotal02: 1013755, batouttotal03: -
batprogsoc01: 3.0, batprogsoc02: 3.0, batprogsoc03: -, socprogwhsum: 306
batsoc01: 42, batsoc02: 40.2, batsoc03: -, socwhsum: 4192
lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
batin01: 91, batin02: 82, batin03: -
batout01: 0, batout02: 0, batout03: -
weatherid: 0, wcc: 0, rr1c: 0.00, pvcorrf: 0.82/0.79 temp: 14.60,
minutescsm01: 0
minutescsm02: 60
23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
etotali01: 28256800, etotali02: -, etotali03: -, etotali04: -
pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
etotalp01: -, etotalp02: -, etotalp03: -
pprl01: -, pprl02: -, pprl03: -
confc: 84113, con: 9, gcons: 0, conprice: 0.40
gfeedin: 400, feedprice: 0.075
DoN: 0, sunaz: 319, sunalt: -6
batintotal01: 1124942, batintotal02: 1110288, batintotal03: -
batouttotal01: 1020991, batouttotal02: 1013880, batouttotal03: -
batprogsoc01: 3.0, batprogsoc02: 3.0, batprogsoc03: -, socprogwhsum: 306
batsoc01: 80.7, batsoc02: 75.4, batsoc03: -, socwhsum: 7961
lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
batin01: 0, batin02: 0, batin03: -
batout01: 172, batout02: 182, batout03: -
weatherid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/- temp: 19.00,
minutescsm01: 0
minutescsm02: 60
Einen Grund dafür erkenne ich momentan noch nicht. Da müsste man sich noch die Logausgabe des Debug mit der Herleitung anschauen.
@Bismosa,
ZitatIst das ein erklärbares verhalten?
Es wird bei jedem Zyklus der Überschuß, also PV - Verbrauch, ermittelt und daraus die Schaltung (bei interruptable) abgeleitet.
Möglicherweise gab es zu diesen Zeiten keinen Überschuß weil ein anderes Gerät auch an war verbunden mit einer kurzfristigen Bewölkung z.B.
Du kannst solche kurzen Laufzeiten / Unterbrechnungen unterbinden, indem du den locktime Schlüssel verwendest. Das verhindert dass deine Pumpe über Gebühr schaltet.
Edit: Alternativ kannst du auch mit dem
surpmeth Schlüssel die PV-Überschuß Bewertung glätten.
LG,
Heiko
@Parallix,
ich habe deinen Wunsch bzgl. Zusatzreadings schonmal teilweise umgesetzt.
Im contrib befindet sich die V 1.52.13. ctrlSpecialReadings enthält jetzt die Option:
remainingHrsWoChargeRcmdBat_XX die verbleibende Anzahl Stunden ohne Ladeempfehlung für Batterie XX am aktuellen Tag
Ich musste den Key einkürzen. Das Reading einfach zu lang.
LG
Zitat von: DS_Starter am 17 Juni 2025, 11:30:27...
ich habe deinen Wunsch bzgl. Zusatzreadings schonmal teilweise umgesetzt.
Im contrib befindet sich die V 1.52.13. ctrlSpecialReadings enthält jetzt die Option:
remainingHrsWoChargeRcmdBat_XX die verbleibende Anzahl Stunden ohne Ladeempfehlung für Batterie XX am aktuellen Tag
Super! Danke! Werde ich direkt am nächsten Feiertag bei mir einbauen!
Zitat von: DS_Starter am 17 Juni 2025, 11:30:27Ich musste den Key einkürzen. Das Reading einfach zu lang.
...
Das ist nun wirklich kein Problem!
Zitat von: DS_Starter am 17 Juni 2025, 11:12:51Ich sehe zwei Ausreißerprognosen:
...
Einen Grund dafür erkenne ich momentan noch nicht. Da müsste man sich noch die Logausgabe des Debug mit der Herleitung anschauen.
Leider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein (Zählerwechsel einmal ausgeschlossen). Ausreißer nach unten sind also sofort identifizierbar und solche nach oben sollten auch einfach identifizierbar sein. Kommt es zu solchen Ausreißern, sollte SF diese proaktiv entfernen (und ggf. einem entsprechenden Log-Eintrag produzieren), da die Zuverlässigkeit der Software hierdurch enorm gesteigert werden kann. Das jedenfalls ist mein Vorschlag.
ZitatLeider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein (Zählerwechsel einmal ausgeschlossen). Ausreißer nach unten sind also sofort identifizierbar und solche nach oben sollten auch einfach identifizierbar sein.
Die Verletzung der Monotonie nach unten kann ich abfangen wie ich es bei den Invertern auch schon eingebaut habe. Das baue ich ein.
Nach oben sehe ich keine Möglichkeit. Wenn jemand ein Elektroauto (mit Netzanteil) lädt oder eine Baumaßnahme durchführt, hat das einen außergewöhnlich hohen Energie-Ausschlag nach oben im Verhältnis zum sonstigen Durchschnitt zur Folge. Wo soll ich eine Grenze einziehen, die einen Fehler sicher erkennt. Mir fällt diesbezüglich nichts ein was sich in der Praxis bewähren könnte.
Ich habe etwas weiter gespielt :)
Die Bat Icons measure_battery_X gibt es nur in fünf Stufen, bei Rollos und Licht hat FHEM Icons mit 11 Stufen. Daher habe ich mir mal 11 neue gemacht (0-100) Mit etwas css lässt sich der aktuelle SoC auf dem Bat Icon darstellen (Stichwort z-index). Dabei ist mir aufgefallen das $soc für alte und aktuelle Werte ein Integer Wert ist, bei der Prognose aber ein Float ( 100,0 war aber zu lang für die kleine Batterie , daher gewandelt )
Zitat von: DS_Starter am 17 Juni 2025, 11:24:42Es wird bei jedem Zyklus der Überschuß, also PV - Verbrauch, ermittelt und daraus die Schaltung (bei interruptable) abgeleitet.
Möglicherweise gab es zu diesen Zeiten keinen Überschuß weil ein anderes Gerät auch an war verbunden mit einer kurzfristigen Bewölkung z.B.
Du kannst solche kurzen Laufzeiten / Unterbrechnungen unterbinden, indem du den locktime Schlüssel verwendest. Das verhindert dass deine Pumpe über Gebühr schaltet.
LG,
Heiko
Hallo Heiko,
ich kann eigentlich ausschließen, das es zu diesen Zeiten keinen PV-Überschuss gab. Ich hatte immer mind. 1000-1500W eingespeist.
Wie es da bei der berechneten Prognose aussah weiß ich allerdings nicht.
Heute Morgen kann es tatsächlich sein, das es um 10Uhr noch nicht ausreichend war. Dennoch wurde die Pumpe wieder für ein paar Sekunden eingeschaltet.
Aktuell ist die Prognose bei 8000W und die tatsächliche Einspeisung noch etwas da drüber. Die Pumpe (mit 500W angegeben) läuft dennoch nicht.
Irgendwie verstehe ich hier wohl das Verhalten noch nicht.
locktime sollte hier doch dann nur die Laufzeit "verlängern" um ein zu kurzes Schalten zu unterbinden. Dann wäre die Pumpe heute Morgen etwas länger eingeschaltet geblieben.
Ich habe auch eine andere schaltbare Steckdose für eine Klimaanlage (derzeit aber ohne einen Verbraucher angeschlossen):
attr SF consumer04 MQTT2_zigbee_plug_Klimaanlage type=heater power=1000 \
mode=can \
notbefore=09:00 notafter=09:00\
interruptable=1\
locktime=180:180\
on=on off=off\
mintime=SunPath\
auto=automatic\
Diese lief von 9:02 bis 22:07 durchgehend. Die hätte abgeschaltet, wenn der Überschuss nicht ausreichend gewesen wäre. Da funktioniert das super.
Gruß
Bismosa
@bismosa,
wenn die Analyseanforderung zu komplex wird, dann kommt man über eine Debugausgabe nicht herum.
Dazu setzt du dir:
ctrlDebug->consumerSwitchingXX
XX = der Counsumer (deine Pumpe) deren Schaltverhalten du ergründen möchtest.
Wenn eine Schaltung passiert, die für dich nicht nachvollziehbar ist hole den entsprechenden Bereich aus dem Log und dann können wir gemeinsam versuchen die Ursache zu ergründen.
LG,
Heiko
@Wzut,
ZitatDie Bat Icons measure_battery_X gibt es nur in fünf Stufen, bei Rollos und Licht hat FHEM Icons mit 11 Stufen. Daher habe ich mir mal 11 neue gemacht (0-100)
Lässt du deine neuen Icons einchecken? Wenn ja, könnte/würde ich deine Lösung in SF einbauen. Das sieht schön "flüssig" aus. Brauche dann nur noch die Info wie du die Werte direkt auf die Batterie bringst. Das würde ich evtl. konfigurierbar gestalten. PC-Nutzer bekommen die Info per Mouse-Over. Auf einem Tablet ist so ein Aufdruck sicherlich häufig gewünscht.
ich werde die 11 mal im Icon Thread posten, mal schaun ob Wuppi sie nimmt. Zum spielen hänge ich sie aber schon mal an.
Desweiteren musst du den vorhanden HTML Tag style um zwei Klassen erweitern und dann dann das Bat Image mit $soc zusammenpacken, hier mal die beiden Abschnitte wie ich es gemacht habe :
$ret .= '<style>TD.solarfc {text-align: center; padding-left:5px; padding-right:5px; margin:0px;}';
$ret .=' .batcontainer {position: relative;}';
$ret .=' .batsoc { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%) rotate(-90deg); color:#000; z-index: 2; }';
$ret .='</style>';
$title .= defined $currsoc ? "\n".$htitles{socbacur}{$lang}.": ".$currsoc." %" : '';
my $image = defined $hfcg->{$i}{'rcdchargebat'.$bn} ? FW_makeImage ($bicon) : '';
$image = '<div class="batcontainer">'.$image if ($image);
$image .= '<div class="batsoc">'.int($soc).'</div></div>' if ($image);
$ret .= "<td title='$title' class='solarfc' width='$width' style='margin:1px; vertical-align:middle align:center; padding-bottom:1px;'>$image</td>";
Dumm ist dabei nur das man nicht weiss welche Hintergrundfarbe gerade aktuell beim User ist. Es wäre toll wenn das auf Modulebene feststellen könnte bevor FHEMWEB das Ding zusammenbaut. In meinem Beispiel z.B. kommt das color:#000 halt nicht so gut an bei einem relativ dunklen Hintergrund. Alternativ kann man natürlich unter dem SoC Wert eine Hintergrundfarbe direkt setzen, hat mir persönlich allerdings nicht so gut gefallen. Anyway, spiel einfach mal etwas damit.
ZitatDumm ist dabei nur das man nicht weiss welche Hintergrundfarbe gerade aktuell beim User ist.
Wir könnten doch die Schriftfarbe für den Batterieaufdruck konfigurierbar machen? Der User weiß ja welche Farbe an der Stelle am Besten passen würde.
Leider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein
[/quote]
Hallo zusammen
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
Ein bsp ist hier die grüne Reihe
Gruß Gerd
Zitat von: Parallix am 17 Juni 2025, 11:54:59Zitat von: DS_Starter am 17 Juni 2025, 11:12:51Ich sehe zwei Ausreißerprognosen:
...
Einen Grund dafür erkenne ich momentan noch nicht. Da müsste man sich noch die Logausgabe des Debug mit der Herleitung anschauen.
Leider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein
Hallo zusammen
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
Ein bsp ist hier die grüne Reihe
Gruß Gerd
Zitat von: Max_Meyer am 17 Juni 2025, 22:28:04...
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
...
Natürlich müssen Ausreißer nach oben hin anders behandelt werden. Unter Berücksichtigung der Hausanschluss-, Modul- und sonstiger max. Leistungen (P_max) sollten dies aber kein riesiges Problem sein. Werden innerhalb zweier Abfragen, die delta_t Sekunden auseinanderliegen SF zwei Energiewerte angeliefert, die in der Differenz delta_E auseinander liegen und ist delta_E / delta_t > P_max, dann darf der zweite Energiewert von SF nicht verwendet werden (Schwellwertfilterung).
Alternativ kann natürlich ein hoher Energiewert mit einem anschließenden Rücksprung auf eine (längere) Folge wieder kleinerer Enegiewerten identifiziert und eliminiert werden (Breitenfilterung).
Eine weitere Alternative wäre der Einsatz eines Modalfilters, Medianfilters oder getrimmten Mittelwertfilters u.s.w., alle natürlich jeweils gleitend eingerichtet.
Zitat von: DS_Starter am 17 Juni 2025, 21:40:50Wir könnten doch die Schriftfarbe für den Batterieaufdruck konfigurierbar machen?
Sicher, aber hat das Muodul nicht schon genug Attribute ? :o 8)
Alternativ kannst auch Farben,Font und z-Index innerhalb von .batsoc ganz weglassen und den SoC recht dicht an das Batterie Icon packen. Durch das wesentlich breitere Wettericon darüber, bzw die vierstelligen Werte in den Balken ist in der Spalte genügend Breite vorhanden (in meinem Beispiel bin ich mit top auf 60% und left auf 2%, richtig mittig ist es aber in der Spalte nicht. Habe auf die Schnelle aber nicht gefunden warum. da das TD ja schon align:center hat )
Zitat von: Parallix am 18 Juni 2025, 08:33:00Zitat von: Max_Meyer am 17 Juni 2025, 22:28:04...
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
...
Natürlich müssen Ausreißer nach oben hin anders behandelt werden. Unter Berücksichtigung der Hausanschluss-, Modul- und sonstiger max. Leistungen (P_max) sollten dies aber kein riesiges Problem sein. Werden innerhalb zweier Abfragen, die delta_t Sekunden auseinanderliegen SF zwei Energiewerte angeliefert, die in der Differenz delta_E auseinander liegen und ist delta_E / delta_t > P_max, dann darf der zweite Energiewert von SF nicht verwendet werden (Schwellwertfilterung).
Alternativ kann natürlich ein hoher Energiewert mit einem anschließenden Rücksprung auf eine (längere) Folge wieder kleinerer Enegiewerten identifiziert und eliminiert werden (Breitenfilterung).
Eine weitere Alternative wäre der Einsatz eines Modalfilters, Medianfilters oder getrimmten Mittelwertfilters u.s.w., alle natürlich jeweils gleitend eingerichtet.
Meine Meinung:
Vielleicht sollte man nicht alle auftretenden Probleme, die irgendwelche unzuverlässige Hardware bzw. irgend ein anderes FHEM-Modul bei der Erfassung macht, hier in SF "maßregeln" wollen.
Es wäre sicherlich besser das man für solche Fehler/Ungenauigkeiten bei der Ursache anpackt und nicht alles in diesem Modul zur Lösung an DS_Starter heranträgt.
Der hat sicherlich schon zeitlich genug allein mit diesem Modul und seine anderen Modulen zu tun / entwickeln / programmieren / regeln.
Hallo!
Soll ich mein "Problem" vielleicht lieber in einen neuen Thread verschieben?
Ich habe nun ein paar Debug-Zeilen zusammen. Ich selbst werde nicht so ganz schlau daraus. Um 08:00:04 wurde die Pumpe heute gestartet. Um 08:00:47 war dann aber Interrupt gesetzt und die Pumpe wurde wieder abgeschaltet.
2025.06.18 07:59:49 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 493
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 500 W
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - physical Switchstate before switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - logical Switchstate before switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 294 W, nompower: 500, surplus: 493 W, planstate: planned: 2025-06-18 08:00:00 - 2025-06-18 16:00:00, starttime: 18.06.2025 08:00:00
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 3
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - physical Switchstate after switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - logical Switchstate after switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - cycleDayNum: 0
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-17 20:07:57
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - last cycle end time: 2025-06-17 20:15:03
2025.06.18 08:00:04 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 495
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 500 W
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - physical Switchstate before switching: off
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - logical Switchstate before switching: off
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 291 W, nompower: 500, surplus: 495 W, planstate: planned: 2025-06-18 08:00:00 - 2025-06-18 16:00:00, starttime: 18.06.2025 08:00:00
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 3
2025.06.18 08:00:04 1: SF DEBUG> Consumer switch enable by battery state: 1
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose on"
2025.06.18 08:00:04 3: MQTT2_DEVICE set Firmata_Aussensteckdose on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - current planning state: starting
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - physical Switchstate after switching: on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - logical Switchstate after switching: on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-18 08:00:04
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - last cycle end time: still running
2025.06.18 08:00:09 1: SMAInverter - Inverter answer does not match our parameters.
2025.06.18 08:00:38 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2025.06.18 08:00:47 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 498
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 0 W
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - current planning state: started
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - physical Switchstate before switching: on
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - logical Switchstate before switching: on
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 291 W, nompower: 500, surplus: 498 W, planstate: switched on: 2025-06-18 08:00:04 - 2025-06-18 16:00:04, starttime: 18.06.2025 08:00:04
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 2
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose off"
2025.06.18 08:00:47 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.18 08:00:47 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - current planning state: interrupting
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - physical Switchstate after switching: off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - logical Switchstate after switching: off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-18 08:00:04
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - last cycle end time: -
Kann es sein, das hier ein Fehler im Wiki (oder in der Zwischenzeit eine Änderung) war?
if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe
}
Freigabe müsste doch (wenn ich das richtig verstanden habe) 0 sein?
Da aber keine Laufzeit hinzugekommen ist, warum sollte dann durch das Script SF_Int geändert worden sein?
Um 13:01:47 wurde dann die Pumpe eingeschaltet. Da war Interrupt auf "0".
Alle anderen Schaltzeiten waren dann heute wegen zu starker Bewölkung und nicht vorhandenem PV-Überschuss völlig in Ordnung.
Gruß
Bismosa
Ich muss mal kurz dazwischen grätschen, sorry.
Wir sanieren gerade unser Dach und mussten einen String runternehmen.
Ich habe jetzt das Attribut "pvCorrectionFactor_Auto" auf "noLearning" gesetzt. Wenn alles wieder montiert ist gehe ich zurück auf "on_complex....".
Ist dieser Weg der richtige oder verhagelt ich mir damit die gesammelten Daten für die KI?
Mit freundlichen Grüßen
Nabend zusammen,
@Shadow3561,
ZitatIst dieser Weg der richtige oder verhagelt ich mir damit die gesammelten Daten für die KI?
Das ist genau richtig, passt.
@bismosa,
bei dir bewegen wir uns wahrscheinlich in einem Grenzbereich wo Überschuß und nominale Leistungsaufnahme der Pumpe nah beisammen liegen.
Zitat... nompower: 500, surplus: 493 W,...
Ich würde dir raten den Überschuß im Consumer entweder über einen Median oder den Durchschnitt mehrerer Messungen zu verwenden:
surpmeth=median oder surpmeth=5 (z.B.)
Im nächsten Release kommt an dieser Stelle noch eine Debugausgabe hinzu.
Zu Testzwecken kannst du auch vorübergehend power=350 setzen um eine evtl. Änderung des Verhaltens zu provozieren.
@all,
ZitatEs wäre sicherlich besser das man für solche Fehler/Ungenauigkeiten bei der Ursache anpackt ...
Der Meinung von 300P schließe ich mich absolut an. Weniger aus "Eigennutz" sondern auf Grund der Überlegung, dass SF nur ein Konsument der Werte z.B. eines Zählerdevices ist. Vermutlich werden diese Werte auch an anderer Stelle verarbeitet, geloggt, in SVG's gezaubert und vllt. auch zu Berechnungen genutzt.
Selbst wenn SF die Probleme durch diverse Maßnahmen neutralisiert, bleibt das Grundproblem bestehen und verschlechtert insgesamt die Qualität der FHEM Installation.
Ich plädiere dafür, wenn wir/ihr solche Dinge bei Gerätemodulen bemerkt auf jeden Fall auch die Entwickler dieser Module anzusprechen um eine Verbesserung der Datenlieferung zu erreichen wenn möglich. Dann haben alle etwas davon. Ungeachtet dessen werden ich meinen Teil in SF auch leisten.
Zitat von: 300P am 18 Juni 2025, 12:46:31...
Meine Meinung:
Vielleicht sollte man nicht alle auftretenden Probleme, die irgendwelche unzuverlässige Hardware bzw. irgend ein anderes FHEM-Modul bei der Erfassung macht, hier in SF "maßregeln" wollen.
Es wäre sicherlich besser das man für solche Fehler/Ungenauigkeiten bei der Ursache anpackt und nicht alles in diesem Modul zur Lösung an DS_Starter heranträgt.
Der hat sicherlich schon zeitlich genug allein mit diesem Modul und seine anderen Modulen zu tun / entwickeln / programmieren / regeln.
In Teilen gebe ich 300P recht. Da es aber eine schier unglaubliche Anzahl an zuliefernden Modulen gibt, könnte eine Konzentration der Problemlösung (in SF) zielführender, schneller und damit vielleicht auch sinnvoller sein, als eine eine große Anzahl dezentraler Lösungen, oder?
Vielleicht könnte man dem SF-User aber auch eine Handvoll an sinnvollen Maßnahmen/Vorschläge an die Hand geben, mit denen er sich einfach selber um die Problemlösung kümmern kann. Ein solcher Vorschlag wäre vielleicht, die Modul-Instanzen, die SF Daten anliefern, um geeigneten UserReadings zu erweitern. Hierbei könnten die Methoden, die event-aggregator zur Verfügung stellt, zum Einsatz kommen. Schade ist nur, dass dort einige hilfreiche Filter noch fehlen, insb. solche, die sporadisch auftauchende Ausreißer unberücksichtigt lassen. Vlt. gibt es ja an anderer Stelle in FHEM eine Toolbox, in der die für unseren Anwendungszweck benötigten gleitenden Filter bereits existieren oder leicht erweitert werden können. Ist Euch so eine Toolbox bekannt?
PS: Meinerseits schreibe ich in diesen Thread hier meine Vorschläge rein, da er "Ideen zu Weiterentwicklung" heißt. Vielleicht gibt es hierbei auch mal die ein oder andere schlechte Idee, die dann natürlich nicht in SF aufgenommen werden sollte.
@Heiko ich habe die Icons unter https://forum.fhem.de/index.php?msg=1343459 gepostet,
Allerdings unter den Namen battery_0-100 statt einfach nur bat_0-100
Hallo!
Danke für den Versuch mir hier zu helfen!
Ich versuche ja erstmal nur das Schaltverhalten zu verstehen. Sorry, wenn ich damit nerve. Ich habe das wohl immer noch nicht kapiert ::)
Ich habe das Modul so verstanden, das es gerade (auch) dafür gemacht ist um Verbraucher gezielt zu steuern. Ich denke die Steuerung der Poolpumpe sollte ein häufiger Anwendungsfall sein. Dann stelle ich mich vermutlich nur dämlich an ;)
Bisher habe ich noch nichts verändert. da ich erstmal die jetzige Situation verstehen möchte.
Zitat von: DS_Starter am 18 Juni 2025, 22:00:13bei dir bewegen wir uns wahrscheinlich in einem Grenzbereich wo Überschuß und nominale Leistungsaufnahme der Pumpe nah beisammen liegen.
Das war gestern so. Angegeben habe ich die Pumpe mit 500W (da existiert keine Verbrauchsmessung). Das sind aber nur ca. 250-300W realer Verbrauch.
Heute war auch genug Überschuss vorhanden:
2025.06.19 10:00:04 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 1297
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 500 W
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - physical Switchstate before switching: off
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - logical Switchstate before switching: off
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 375 W, nompower: 500, surplus: 1297 W, planstate: planned: 2025-06-19 10:00:00 - 2025-06-19 18:00:00, starttime: 19.06.2025 10:00:00
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 3
2025.06.19 10:00:04 1: SF DEBUG> Consumer switch enable by battery state: 1
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose on"
2025.06.19 10:00:04 3: MQTT2_DEVICE set Firmata_Aussensteckdose on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - current planning state: starting
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - physical Switchstate after switching: on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - logical Switchstate after switching: on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-19 10:00:04
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - last cycle end time: still running
2025.06.19 10:00:37 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 1420
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 0 W
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - current planning state: started
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - physical Switchstate before switching: on
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - logical Switchstate before switching: on
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 2248 W, nompower: 500, surplus: 1420 W, planstate: switched on: 2025-06-19 10:00:04 - 2025-06-19 18:00:04, starttime: 19.06.2025 10:00:04
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 2
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose off"
2025.06.19 10:00:37 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.19 10:00:37 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - current planning state: interrupting
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - physical Switchstate after switching: off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - logical Switchstate after switching: off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-19 10:00:04
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - last cycle end time: -
Warum beginnt der Zyklus heute wieder um 10Uhr? Mit der Einstellung: notafter=10:00 könnte er doch auch früher starten, wenn genug Überschuss vorhanden ist?
Der Überschuss war auch beim abschalten groß genug. Auch jetzt habe ich aktuell 2kW Überschuss. Da könnte die Pumpe ruhig laufen.
Oder wird durch die Kombination von
mintime=480
notafter=10:00
Der gesamte Tag betrachtet? Da z.B. um 14Uhr der meiste Überschuss vorhanden ist, wird erst dann die Pumpe geschaltet? Die 480 Minuten würde er dann ja auch noch bis Sonnenuntergang erreichen.
Mein Ziel war es durch diese Einstellung zu erreichen, das die Pumpe um 10Uhr (wenn genug Überschuss vorhanden) beginnt. Aber nach 18Uhr dann nicht mehr läuft.
Gruß
Bismosa
@Wzut,
prima. Das schaue ich mir dann kurzfristig auch an.
@Bismosa,
kein Thema ;)
ZitatIch habe das Modul so verstanden, das es gerade (auch) dafür gemacht ist um Verbraucher gezielt zu steuern. Ich denke die Steuerung der Poolpumpe sollte ein häufiger Anwendungsfall sein.
Ja, genau richtig.
Ich denke ich weiß jetzt warum deine Pumpe ausschaltet. Du hast das Beispiel im Wiki angwendet
interruptable=Firmata_Aussensteckdose:SF_Int:1Das bedeutet, sobald der Regex "1" im Device:Reading Firmata_Aussensteckdose:SF_Int matcht, schaltet die Pumpe ab, egal ob noch Überschuß da ist oder nicht.
Und der Regex matched, da das Reading über dein Skript auf 1 gesetzt wurde:
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
Zur Lösung definierst du interruptable im Consumer einfach so:
interruptable=1
Dann reagiert das Modul bei der Steuerung nur auf das Vorhandensein eines Überschusses mit "on" bzw. "off".
(Das Beispiel im Wiki schaue ich mir nochmal an ob es da einen Fehler gibt. Es ist aber für einen speziellen Steuerungsfall aufgebaut).
ZitatWarum beginnt der Zyklus heute wieder um 10Uhr? Mit der Einstellung: notafter=10:00 könnte er doch auch früher starten, wenn genug Überschuss vorhanden ist?
Das Modul versucht die angegebene Soll-Laufzeit von 480 Minuten unter Berücksichtigung der PV-Prognose, der Verbrauchsprognose und der Laufprognose anderer Verbraucher möglichst optimal in den Tag hinzuplanen. Wenn man sich die Logik der Planung näher anschauen will -> ctrlDebug->consumerPlanning einschalten.
Mit der Einstellung notafter=10:00 greift man praktisch in den Planungsprozess ein und sagt dem Modul dass man ab 10:00 die Einplanung starten möchte auch wenn das Modul vllt. intern erst 10:30 die Einplanung setze würde.
LG,
Heiko
@all,
ich habe in der Zwischenzeit die (lineare) Skalierung der Balkengrafik überarbeitet und die Möglichkeit geschaffen, dass der User für jede vorhandene Ebene der Balkengrafik getrennt die Skalierung zwischen linear (default) und logarithmisch umschalten kann.
Ihr sehr die Darstellungsunterschiede in den Screenshots.
Die Umschaltung erfolgt über das Attr graphicControl->scaleMode:
scaleMode
Für jede Ebene der Balkengrafik kann der Skalierungsmodus linear oder logarithmisch festgelegt werden.
Die logarithmische Einstellung hebt kleine Werte stärker an und komprimiert größere Werte in der Darstellung.
Die Angabe für eine Ebene besteht aus der Ebenen-Nummer (1..X), einem ':' gefolgt von dem Modus 'lin' oder 'log'.
Die Strings für jede Ebene werden durch Komma getrennt (siehe Beispiel).
<Ebene>:lin - lineare Skalierung (default)
<Ebene>:log - logarithmische Skalierung
Beispiel: scaleMode=1:log,2:lin
Die V 1.52.14 liegt in meinem contrib.
LG,
Heiko
Hallo!
Vielen Dank für die ausführliche Antwort!
Das hat mich nun zumindest ein Stück weiter gebracht.
interruptable=Firmata_Aussensteckdose:SF_Int:1Zitat von: DS_Starter am 19 Juni 2025, 11:43:31Das bedeutet, sobald der Regex "1" im Device:Reading Firmata_Aussensteckdose:SF_Int matcht, schaltet die Pumpe ab, egal ob noch Überschuß da ist oder nicht.
So steht es auch in der Commandref:
ZitatVerbraucher wird temporär unterbrochen, wenn der Wert des angegebenen Device:Readings auf den Regex matched
interruptable=1ZitatVerbraucher wird temporär ausgeschaltet falls der PV Überschuß die benötigte Energie unterschreitet
Das sind demnach ja ganz unterschiedliche Funktionen.
Ich habe das nun gesetzt und die Pumpe lief sofort (wie eigentlich erwartet) los.
Dann habe ich das nur aus dem Beispiel im Wiki noch nicht verstanden:
if ($mrest >= ($mneed - $msum)) {
readingsSingleUpdate ($dhash, 'SF_Int', 1, 0); # Interrupt-Freigabe
}
else {
readingsSingleUpdate ($dhash, 'SF_Int', 0, 0); # keine Interrupt-Freigabe
}Ich hatte gedacht, das dies dafür da ist, "interruptable=0" zu setzen, das die Pumpe nicht mehr ausgehen darf (damit diese lange genug am Tag läuft...auch bei Schlechtwetter). Aber nach der Beschreibung in der Commandref geht das nicht.?
Ich lasse jetzt mal die Werte $mrest $mneed $msum protokollieren. Vielleicht werde ich dann noch etwas schlauer.
Gruß
Bismosa
ZitatDann habe ich das nur aus dem Beispiel im Wiki noch nicht verstanden:
Ja, das muß ich mir anschauen. Ich denke das passt nicht (mehr) und dort gehört ein anderer Befehl hinein.
Sage auf jeden Fall nochmal Bescheid wenn ich das reviewed habe.
Im battery_70 steckt ein Hochkomma zuviel, Wuppi wird es bestimmt noch tauschen
Ich habe die V im contrib upgedated -> die logarithmische Darstellung ist nachgebessert.
Ich habe das Fallbeispiel Pumpensteuerung (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Fallstudie:_Umw%C3%A4lzpumpe_Pool_soll_X_Stunden_am_Tag_laufen._Ist_kein_PV-%C3%9Cberschu%C3%9F_vorhanden,_m%C3%BCssen_die_X_Stunden/Tag_trotzdem_erreicht_werden) im Wiki überarbeitet.
Das sollte nun passen.
LG,
Heiko
@Parallix,
ich möchte nochmal nachfragen bzgl. dieser Anforderung:
ZitatEins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.
Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.
Habe ich das so richtig wiedergegeben?
LG,
Heiko
Zitat von: DS_Starter am 19 Juni 2025, 21:15:56ch möchte nochmal nachfragen bzgl. dieser Anforderung:
ZitatEins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.
Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.
Habe ich das so richtig wiedergegeben?
Hallo allerseits,
ich frage mich ob eine einseitige Fokussierung ausschließlich auf netzdienliche Batterieladung im letzten drittel des Tages so sinnvoll ist.
Da ist zum einen die 'Energie-Konkurrenz' zwischen Batterie(n) und 'Großverbrauchern z.B. WP, Heizstab, E-Car, WA, GSP, Poolheizung etc. besonders in der Übergangszeit(Herbst, Winter, Frühjahr) wo gerade genug Energie vom Dach zur Verfügung steht um den Bedarf weitestgehend zu decken. Und die Batterie ist ein 'gutmütiger' Consumer - d.h. die nimmt die PV-Energie ab wenigen Watt Überschuss und gewährleistet so eine max. Ausbeute während z.B. meine WP mind. 650 W braucht um anzulaufen und bei PV-Überschuss den Puffer wärmer zu machen als er lt. Heizkurve sein müsst - ein Heizstab braucht 1500W, E-Car alt ab 1500W neu (ISO 15118) 600W etc.
Auf der anderen Seite sollte jede Batterie (Theorie (Studie) durfte ich gerade lernen) nur möglichst kurz im Ladezustand 100% verharren. Ansonsten altert eine (LFP-) Batterie überdurchschnittlich schnell. Zumindest ist dies neben Umgebungstemperatur und (Ent-) Ladestrom ein sehr entscheidender Einfluss. Mit Ladezuständen um die 80% passiert das nicht (siehe Handy). BMS hält auch eine definierte Ladung vor um Überladung und Tiefenentladung zu vermeiden.
Die Frage aus meiner Sicht ist, auf was optimiert werden soll - max. Energieausbeute vs. max. Batteriegesundheit.
Vielleicht ist es sinnvoll die Bat (erstmal nur im Sommer) bis auf 80% laden? Verbraucher priorisieren? so dass sie hintereinander einschalten solange PV Überschuss vorhanden ist und dann auch wieder ausschalten wenn weg? Aber wie kann man das planen? Es ist sicher möglich für Verbraucher ein Profil zu ermitteln - beim Heizstab z.B. der braucht (bei mir 200l WW-Boiler) ca. 0,5 kWh pro 1K Temperaturerhöhung - die Krux ist wenn der Heizstab ausschaltet weil z.B. 75°C erreicht sind (lt. Sensor Heizstab) ist das im oberen Bereich des Boilers noch nicht der Fall - also geht das Ding mit bis zu 4500 W 'unkontrolliert' wieder an sobald die Konvektion gewirkt hat - schreib das nur um die kleinen Klippen zu skizzieren die da so umhergeistern - denn heute stört das nicht, jede Lücke wird von der Batterie genutzt - die saugt die Energie weg wenn verfügbar.
Ich möchte diesen Post bitte nur als Diskussionsanstoß verstanden wissen - bin mir nicht sicher was da richtig wäre - gerne antworten
Gruß Gerd
Hallo Gerd,
meine Anlage fahre ich zur Zeit so, dass sie nur ca 2/3 der möglichen Einspeiseleistung einspeisen soll (plantControl->feedinPowerLimit).
Dadurch wird die Batterie in den Zeiten ohne "Ladefreigabe" bzw. "nur Laden wenn Einspeiselimit überschritten" bereits mit wenig Leistung (der evtl. Überschußleistung) geladen und der SoC steigt so langsam an. Mit der Ladefreigabe, die sich nach dem SoC in Beziehung zum erwarteten Restüberschuß des Tages sowie Verbrauchsprognose richtet, wird die Batterie dann mit voller Überschußleistung voll geladen.
So werden die 100% zur Zeit erst recht spät am Tag erreicht und gehen nach kurzer Zeit wieder in den Entladungsmodus.
Im Herbst/Winter wird die "Ladefreigabe" früher oder ohnehin für den ganzen Tag erteilt. Dadurch ist die Batterie eher voll (wenn möglich), aber die Energieausbeute und Einspeisung ohnhin gering(er).
Die Verbraucher kann man priorisiert im Modul planen lassen, indem man über die Schlüssel notbefore in Verbindung mit mintime und den weiteren Möglichkeiten eine Abfolge aufbaut. Man kann auch eine automatische Chain aufbauen, indem über eine kleine Logik in ctrlUserExitFn der Status planningstate='finished' eines Consumers ausgewertet wird um danach den nächsten zu starten. Es gibt viele Möglichkeiten.
LG,
Heiko
Zitat von: DS_Starter am 19 Juni 2025, 21:15:56@Parallix,
ich möchte nochmal nachfragen bzgl. dieser Anforderung:
ZitatEins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.
Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.
Habe ich das so richtig wiedergegeben?
LG,
Heiko
Hallo Heiko!
Ja, Du hast mich richtig verstanden. Was die letztgenannte Minimalleistung angeht, so ist diese natürlich nicht auf eine Stunde bezogen, sondern sollte in der zu betrachtenden Stunde möglichst nicht unterschritten werden.
Hintergründe:- Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Gesundheit aus, was u.a. auch daran liegt, dass der Temperaturstress im Akku bei langsamer Energiezuführung nur gering ist.
- Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.
- Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.
- Ein geringer Ladestrom kann zu zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.
- Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.
Übrigens:
Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass SOC=100% üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellwert überschreitet, der – würde dieser Schwellwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen würde. Schädlich sind also insb. häufige Nachladevorgänge bei Werten um die 100%, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellwert überschreiten.
Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut, der nach einem SOC von 100% unterschritten werden muss, bevor überhaupt eine weitere Ladung erfolgen kann. Insb. in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit SOC=100% erreicht. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.
Nun hoffe ich, dass meine Erläuterungen nicht zu sehr Off-Topic waren, meinen Feature-Request aber hinreichend motiviert haben und auch einige von Gerd aufgeworfene Aspekte beleuchtet haben.
Zitat von: DS_Starter am 14 Juni 2025, 23:04:37Der User kann mit dem Schlüssel pinmax die maximal mögliche Ladeleistung in Watt festlegen. mit welcher die Batterie geladen werden kann. Dieser Wert wird durch die SoC-Prognose auch beachtet.
Der User kann diesen Schlüssel dynamisch setzen mit:
set ... attrKeyVal setupBatteryDevXX pinmax=<Wert>
Ich habe hier ein kleines Skript, das mir die Ladeleistung der Batterie dynamisch anpasst. Hierzu wird mittels set .... attrKeyVal den pinmax Wert dynamisch angepasst. Aktuell steht er z.B. auf 505 Watt.
PV_Batterie
cap=10240
charge=BatteryChargePercent
intotal=Summe_Ladung:Wh
outtotal=Summe_Entladung:Wh
pin=BatteryChargeWatt:W
pinmax=505
pout=BatteryDischargeWatt:W
show=2 Trotzdem wird die Batterie munter weiter mit der maximal möglichen Ladeleistung befüllt.
Wo hab ich hier den Fehler?
Zitat von: Wolle02 am 20 Juni 2025, 07:49:25...
Ich habe hier ein kleines Skript, das mir die Ladeleistung der Batterie dynamisch anpasst. Hierzu wird mittels set .... attrKeyVal den pinmax Wert dynamisch angepasst. Aktuell steht er z.B. auf 505 Watt.
...
Trotzdem wird die Batterie munter weiter mit der maximal möglichen Ladeleistung befüllt.
Wo hab ich hier den Fehler?
In SF ist pinmax "nur" ein Wert, der zur Kalkulation verwendet wird.
Setzt Du pinmax denn auch in Deinem WR?
Zitat von: DS_Starter am 19 Juni 2025, 23:59:14meine Anlage fahre ich zur Zeit so, dass sie nur ca 2/3 der möglichen Einspeiseleistung einspeisen soll (plantControl->feedinPowerLimit).
Dadurch wird die Batterie in den Zeiten ohne "Ladefreigabe" bzw. "nur Laden wenn Einspeiselimit überschritten" bereits mit wenig Leistung (der evtl. Überschußleistung) geladen und der SoC steigt so langsam an. Mit der Ladefreigabe, die sich nach dem SoC in Beziehung zum erwarteten Restüberschuß des Tages sowie Verbrauchsprognose richtet, wird die Batterie dann mit voller Überschußleistung voll geladen.
Hallo Heiko, Hallo Parallix
Danke für die schnelle Antwort - die Idee ist gut umsetzbar - werde ich mal versuchen das zu skalieren.
Bei mir ist es derzeit so, dass die Batterien hintereinander geladen werden aber eben bis angezeigte 100% - wenn die alle voll sind, reicht die gespeicherte Leistung in der Heizperiode um über die Nacht zu kommen (PV vorausgesetzt) - dabei verwendet die WP schon tagsüber mittels PV-Direktverbrauch das Haus als Puffer um nicht unnötig Energie zu wandeln.
Gruß Gerd
Moin zusammen,
@Parallix,
Motivation ist schon da. ;) Die Umsetzung braucht ein bisschen Vorbereitung.
ZitatWas die letztgenannte Minimalleistung angeht, so ist diese natürlich nicht auf eine Stunde bezogen, sondern sollte in der zu betrachtenden Stunde möglichst nicht unterschritten werden.
Mein Aussage war so zu verstehen, dass ich um einen Vergleich mit der Anzahl der PV-Überschußstunden rechnen zu können, die Minimalleistung auf eine Stunde normieren muß um ebenfalls Wh zu bekommen. Anders gesagt, wenn die Bat mit der Minimalleistung von 50W eine Stunde lang geladen wird, sind das 50Wh.
Wenn wir z.B. an einem Tag 10 Stunden ermitteln, in denen jeweils ein Überschüß >= 50Wh prognostiziert wird, hätten wir im Sinne der Anforderung einen Wert für Battery_ChargingHoursRemain_XX=10.
Das wäre m.M. nach die umzusetzende Logik zur Erstellung des Readings.
@Wolle02 / @all,
ganz allgemeine Aussage ... SF greift außer bei der Consumern nicht aktiv steuernd in die Wechselrichter oder Batteriesysteme ein.
Dazu braucht ihr stets eigene Skripte, die zum Beispiel über ctrlUserExitFn eingebunden werden können.
Die Angaben in den setup.*-Attributen dienen dazu, SF Informationen über die möglichen Leistungs- und weitere Parameter mitzuteilen. Wenn ihr also Leistungsparameter in den Invertern / Batterien (dynamisch) ändert, hinterlegt diese Anpassung auch immer über "set ... attrKeyVal" in SF damit diese Kennzahlen identisch gehalten werden.
LG,
Heiko
Zitat von: DS_Starter am 20 Juni 2025, 08:33:14Moin zusammen,
@Parallix,
Motivation ist schon da. ;) Die Umsetzung braucht ein bisschen Vorbereitung.
Bloß kein Stress! Aktuell mache ich es noch händisch und komme mit max. zwei bis drei Anpassungen der Ladeleistung aus.
Zitat von: DS_Starter am 20 Juni 2025, 08:33:14ZitatWas die letztgenannte Minimalleistung angeht, so ist diese natürlich nicht auf eine Stunde bezogen, sondern sollte in der zu betrachtenden Stunde möglichst nicht unterschritten werden.
Mein Aussage war so zu verstehen, dass ich um einen Vergleich mit der Anzahl der PV-Überschußstunden rechnen zu können, die Minimalleistung auf eine Stunde normieren muß um ebenfalls Wh zu bekommen. Anders gesagt, wenn die Bat mit der Minimalleistung von 50W eine Stunde lange geladen wird, sind das 50Wh.
Wenn wir z.B. an einem Tag 10 Stunden ermitteln, in denen jeweils ein Überschüß >= 50Wh prognostiziert wird, hätten wir im Sinne der Anforderung einen Wert für Battery_ChargingHoursRemain_XX=10.
Das wäre m.M. nach die umzusetzende Logik zur Erstellung des Readings.
Dann bekäme man den Wert "nur" mit einer 1h-Auflösung am PV-Produktionsende, oder?
Besser wäre es vermutlich, sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen anzusehen und daraus den zeitlichen Punkt abzuleiten, an dem die geforderte Mindestleistung unterschritten wird.
Am PV-Produktionsstart (morgens) ist übrigens keine Sonderberechnung erforderlich, da man dort ja noch weit von SOC=100% entfernt ist.
ZitatBesser wäre es meines Erachtens, wenn man sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen ansieht und daraus den zeitlichen Punkt ableitet, an dem die geforderte Mindestleistung unterschritten wird, oder?
Leistungsprognosen habe ich nicht zur Verfügung. Es gibt nur Prognosen der Energien, d.h. Verbräuche oder Erzeugungen, Einspeisungen etc. im 1h Raster.
Zitat von: DS_Starter am 20 Juni 2025, 09:02:02ganz allgemeine Aussage ... SF greift außer bei der Consumern nicht aktiv steuernd in die Wechselrichter oder Batteriesysteme ein.
Dazu braucht ihr stets eigene Skripte, die zum Beispiel über ctrlUserExitFn eingebunden werden können.
Die Angaben in den setup.*-Attributen dienen dazu, SF Informationen über die möglichen Leistungs- und weitere Parameter mitzuteilen. Wenn ihr also Leistungsparameter in den Invertern / Batterien (dynamisch) ändert, hinterlegt diese Anpassung auch immer über "set ... attrKeyVal" in SF damit diese Kennzahlen identisch gehalten werden.
Ok, danke. Irgendwie führt das bei mir immer wieder zu Missverständnissen. Dann fahre ich mal zweigleisig und regele die Batterie mit dem Skript und teile SF den Wert informatorisch mit.
Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?
LG Wolle
Zitat von: DS_Starter am 20 Juni 2025, 09:12:08ZitatBesser wäre es meines Erachtens, wenn man sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen ansieht und daraus den zeitlichen Punkt ableitet, an dem die geforderte Mindestleistung unterschritten wird, oder?
Leistungsprognosen habe ich nicht zur Verfügung. Es gibt nur Prognosen der Energien, d.h. Verbräuche oder Erzeugungen, Einspeisungen etc. im 1h Raster.
Dann würde man wohl die mittlere Leistung (Berechnung wie von Dir weiter oben angeben), zeitlich lokalisiert in der Mitte des 1h-Intervalls, heranziehen. Der Rest (linearer Ansatz) bliebe gleich.
Zitat von: Wolle02 am 20 Juni 2025, 09:28:00...
Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?
Die Steuerung, ggf. auch Regelung, soll außerhalb von SF erfolgen, kann - in Teilen - natürlich von SF angestoßen und/oder mit Daten versorgt werden. So jedenfalls hatte ich Heiko immer verstanden.. Darüber hinaus wird es ja auch künftig weitere, die Steuerung/Regelung steuernde Elemente geben, wie z.B. die Steuerbox.
@Parallix,
mit deinem Einverständnis würde ich deine Hinweise zur Batterie in #3204 gern in das Wiki übernehmen.
ZitatDann würde man wohl die mittlere Leistung zeitlich in der Mitte des 1h-Intervalls ansetzen.
Ich baue mal ein Reading mit den mir im Modul gegebenen Möglichkeiten und dann schauen wir mal ob das Ergebnis den erwarteten Nutzen bringt.
@Wolle
ZitatIst denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?
Momentan ist eine Regelung dieser Geräte nicht geplant. Dabei sind mehrere Aspekte zu berücksichtigen:
- die Varianten zur Steuerung bestimmter Eigenschaften in Invertern oder Batteriesystemen sind äußerst vielfältig und erfordern ein hohes
Maß an im Modul zu hinterlegende Informationen die verwaltet und geprüft werden müssen
- unabhängig von den technisch/organisatorischen Herausforderungen gibt es auch die Frage nach einer Verantwortlichkeit wenn durch bestimmte Steuerungen,
z.B. über Modbus, die Geräte in einen sagen wir mal "unerwünschten Zustand" versetzt werden.
Ich möchte ungern eine derartige Zentralisierung im Modul herbeiführen. Allerdings sind solche Steuerungsmöglichkeiten immer optional, sodaß der
User sie verwenden kann oder aber nicht wenn er eigene Logiken einsetzen möchte. Das ist ein Grundprinzip im Modul.
LG,
Heiko
Zitat von: DS_Starter am 20 Juni 2025, 09:49:50@Parallix,
mit deinem Einverständnis würde ich deine Hinweise zur Batterie in #3204 gern in das Wiki übernehmen.
Klar! Gerne!
Zitat von: DS_Starter am 20 Juni 2025, 09:49:50ZitatDann würde man wohl die mittlere Leistung zeitlich in der Mitte des 1h-Intervalls ansetzen.
Ich baue mal ein Reading mit den mir im Modul gegebenen Möglichkeiten und dann schauen wir mal ob das Ergebnis den erwarteten Nutzen bringt.
Prima! Danke!
@Parallix,
ich habe deinen Content in einen neuen Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#weitere_m%C3%B6gliche_Aspekte_der_SOC-_und_Batterieladesteuerung) ins Wiki eingebaut. Eventuell magst du noch weitere Aspekte ergänzen.
In dem Zusammenhang ist mir aufgefallen, dass es evtl. günstig wäre den Schlüssel ctrlBatSocManagementXX->loadAbort um einen Fallback-Wert zu ergänzen.
Also statt:
loadAbort=<SoC>:<PowerIn>
ein
loadAbort=<SoC1>:<PowerIn>:<SoC2>
Abgeschaltet würde man bei erreichen SoC1 und <= PowerIn. Battery_ChargeAbort_XX = 0 würde wieder gesetzt, wenn der SoC unter SoC2 fällt statt wie aktuell auch SoC1.
Rückwärtskompatibel wäre die Variante, denn es könnte SoC2=SoC1 angegeben werden.
LG,
Heiko
@Parallix,
nochmal eine Frage zu dem Thema ...
ZitatEins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.
Eigentlich müsste es meiner Meinung nach keine minimal geforderte Ladeleistung sein, sondern ein Ladeleistungsrichtwert den man angeben kann oder vllt. sogar eine maximal erlaubte (gesetzte) Ladeleistung.
Denn genau dann würde die ermittelte Anzahl Stunden mit "Überschuß > Ladeleistungsrichtwert" realistisch sein.
Würde ich die Stunden durch Vergleich "Überschuß > minimal geforderte Ladeleistung" ermitteln, würden sie nicht mehr zutreffen wenn die Ladeleistung höher als minimal gefordert wäre und den Prognose-Überschuß übersteigen würde.
Ich hoffe ich habe mich verständlich ausgedrückt. Es ist im Prinzip eine Definitionsfrage. Sie ist aber wichtig, da ich die vergleichende Ladeleistung als Parameter beschreiben muß was das eigentlich ist/sein soll.
Zitat von: DS_Starter am 20 Juni 2025, 17:19:17@Parallix,
ich habe deinen Content in einen neuen Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#weitere_m%C3%B6gliche_Aspekte_der_SOC-_und_Batterieladesteuerung) ins Wiki eingebaut. Eventuell magst du noch weitere Aspekte ergänzen.
Das mache ich natürlich gerne, sollte mir noch ein entsprechender Aspekt einfallen.
Zitat von: DS_Starter am 20 Juni 2025, 17:19:17In dem Zusammenhang ist mir aufgefallen, dass es evtl. günstig wäre den Schlüssel ctrlBatSocManagementXX->loadAbort um einen Fallback-Wert zu ergänzen.
Also statt:
loadAbort=<SoC>:<PowerIn>
ein
loadAbort=<SoC1>:<PowerIn>:<SoC2>
Abgeschaltet würde man bei erreichen SoC1 und <= PowerIn. Battery_ChargeAbort_XX = 0 würde wieder gesetzt, wenn der SoC unter SoC2 fällt statt wie aktuell auch SoC1.
Rückwärtskompatibel wäre die Variante, denn es könnte SoC2=SoC1 angegeben werden.
Ohne <PowerIn> würde damit das von mir beschrieben Verfahren, welches z.B. BYD inzwischen einsetzt auch mit früheren FW-Versionen (die man vlt. nicht aktualisieren will) verfügbar machen.
Was die Abbruchbedingung angeht, ist es natürlich so, dass es nur sinnvoll ist, bei einer Ladeleistung < PowerIn das Laden zu beenden, wenn der SOC knapp unter 100% ist. Anders ausgedrückt: Wird ein <SoC1> deutlich kleiner als 100 angegeben, dann darf <PowerIn> durchaus auch 0 sein!
Ist damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden? Vielleicht habe ich Sie auch nur nicht richtig verstanden. Gucke sie mir morgen in aller Frische aber nochmal an.
ZitatWas die Abbruchbedingung angeht, ist es natürlich so, dass es nur sinnvoll ist, bei einer Ladeleistung < PowerIn das Laden zu beenden, wenn der SOC knapp unter 100% ist. Anders ausgedrückt: Wird ein <SoC1> deutlich kleiner als 100 angegeben, dann darf <PowerIn> durchaus auch 0 sein!
Diese Möglichkeit hat der User, d.h. er kann die Bedingungen nach seinen Maßstäben definieren
ZitatIst damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden?
Eigentlich nicht. Ja, lies dir morgen meine Gedanken dazu nochmal durch. Wesentlich ist nicht so sehr der Wert an sich, sondern die verbale Definition. Es sei denn, du setzt gerade in Gedanken
PowerIn mit der "minimal geforderten Ladeleistung" gleich. Aber auch dann könnte die reale Ladeleistung höher sein und würde ggf. den Überschuß übersteigen und somit die berechneten Stunden invalidieren.
Zitat von: DS_Starter am 20 Juni 2025, 21:46:03ZitatIst damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden?
Eigentlich nicht. Ja, lies dir morgen meine Gedanken dazu nochmal durch. Wesentlich ist nicht so sehr der Wert an sich, sondern die verbale Definition. Es sei denn, du setzt gerade in Gedanken PowerIn mit der "minimal geforderten Ladeleistung" gleich. Aber auch dann könnte die reale Ladeleistung höher sein und würde ggf. den Überschuß übersteigen und somit die berechneten Stunden invalidieren.
Wenn ich das richtig sehe, dann weicht Dein Anwendungsfall von meinem ab und wir haben deshalb einen unterschiedlichen Blick auf die Dinge. Daher möchte ich meinen nochmal ausführlich darstellen:
Wenn ein Akku über den Tag möglichst gleichmäßig unter ausschließlicher Nutzung von PV-Energie von einem CurrentSOC auf einen EndSOC gebracht werden soll, dann muss zunächst die Energiemenge E_L ermittelt werden, die per Ladung in ihn gebracht werden muss. Hierzu wird die Energie E_A benötigt, die maximal im Akku gespeichert werden kann. Nun kann E_L ausgerechnet werden:
E_L = E_A * (EndSOC – CurrentSOC)
Unter der Annahme, dass die Ladeleistung während der gesamten Ladezeit nie unter die Ladeschlussleistung P_End fallen darf, stehen nicht alle Stunden mit Solarertrag zur Verfügung, sondern nur die, die eine Ladung mit o.g. Ladeschlussleistung garantieren. Also muss ich die Zeit T_L kennen, die mir für die Ladung mit mindestens P_End (von Dir <PowerIn> genannt) zur Verfügung steht. Wenn ich T_L kenne, kann ich am Wechselrichter die Ladeleistung P_L so limitieren, dass ich den Akku erst am Ende des Tages auf den Zielwert EndSOC gebracht habe:
P_L = E_L / T_L
Zur Illustration habe ich unten die Ladekurve meiner Akkus an einem recht normalen PV-Tag angefügt.
PS[1]: Da während eines Tages unvorhergesehen sowohl solare Ertrag, der Hausverbrauch und damit die zur Ladung zur Verfügung stehende Ladeleistung variieren kann, sollte in regelmäßigen Abständen die o.g. Berechnung und das Setzen von P_L neu durchgeführt werden.
PS[2]: Je nach Situation kann P_L natürlich über den Tag auch aus anderen (als den o.g.) Gründen verändert werden. Bei einer schlechten PV-Prognosequalität (Unsicherheit) bietet sich z.B. eine höhere Ladung bereits zu Beginn eines Sonnentages an, um an Ende des Tages den Akku auch gesichert auf den Sollwert zu bringen.
Zitat von: Parallix am 21 Juni 2025, 08:26:21Zitat von: DS_Starter am 20 Juni 2025, 21:46:03ZitatIst damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden?
Eigentlich nicht. Ja, lies dir morgen meine Gedanken dazu nochmal durch. Wesentlich ist nicht so sehr der Wert an sich, sondern die verbale Definition. Es sei denn, du setzt gerade in Gedanken PowerIn mit der "minimal geforderten Ladeleistung" gleich. Aber auch dann könnte die reale Ladeleistung höher sein und würde ggf. den Überschuß übersteigen und somit die berechneten Stunden invalidieren.
Wenn ich das richtig sehe, dann weicht Dein Anwendungsfall von meinem ab und wir haben deshalb einen unterschiedlichen Blick auf die Dinge. Daher möchte ich meinen nochmal ausführlich darstellen:
Wenn ein Akku über den Tag möglichst gleichmäßig unter ausschließlicher Nutzung von PV-Energie von einem CurrentSOC auf einen EndSOC gebracht werden soll, dann muss zunächst die Energiemenge E_L ermittelt werden, die per Ladung in ihn gebracht werden muss. Hierzu wird die Energie E_A benötigt, die maximal im Akku gespeichert werden kann. Nun kann E_L ausgerechnet werden:
E_L = E_A * (EndSOC – CurrentSOC)
Unter der Annahme, dass die Ladeleistung während der gesamten Ladezeit nie unter die Ladeschlussleistung P_End fallen darf, stehen nicht alle Stunden mit Solarertrag zur Verfügung, sondern nur die, die eine Ladung mit o.g. Ladeschlussleistung garantieren. Also muss ich die Zeit T_L kennen, die mir für die Ladung mit mindestens P_End (von Dir <PowerIn> genannt) zur Verfügung steht. Wenn ich T_L kenne, kann ich am Wechselrichter die Ladeleistung P_L so limitieren, dass ich den Akku erst am Ende des Tages auf den Zielwert EndSOC gebracht habe:
P_L = E_L / T_L
PS[1]: Da während eines Tages unvorhergesehen sowohl solare Ertrag, der Hausverbrauch und damit die zur Ladung zur Verfügung stehende Ladeleistung variieren kann, sollte in regelmäßigen Abständen die o.g. Berechnung und das Setzen von P_L neu durchgeführt werden.
PS[2]: Je nach Situation kann P_L natürlich über den Tag auch aus anderen (als den o.g.) Gründen verändert werden. Bei einer schlechten PV-Prognosequalität (Unsicherheit) bietet sich z.B. eine höhere Ladung bereits zu Beginn eines Sonnentages an, um an Ende des Tages den Akku auch gesichert auf den Sollwert zu bringen.
Moin,
Ich hatte auch mal versucht die Ladeleistung etwas gleichmäßiger zu regeln um in der Mittagszeit einen schönen grafischen Block zu bekommen, jedoch spielt zusätzlich noch die Ladekurve des Speichers mit rein. Ein möglichst linearer Anstieg des SOC ergibt bei mir eine Art von Keil bei der Ladeleistung. Letztendlich habe ich dann versucht die Ladeleistung so beim WR vorzugeben, das es sich auf die Zeit möglichst Netzdienlich verteilt. Zum Ende wird zwar eine hohe Wünschleistung vorgegeben, jedoch der Speicher entscheidet sich für weniger und es wird ein Keil.
VG Christian
Zitat von: ch.eick am 21 Juni 2025, 10:53:20...
Moin,
Ich hatte auch mal versucht die Ladeleistung etwas gleichmäßiger zu regeln um in der Mittagszeit einen schönen grafischen Block zu bekommen, jedoch spielt zusätzlich noch die Ladekurve des Speichers mit rein. Ein möglichst linearer Anstieg des SOC ergibt bei mir eine Art von Keil bei der Ladeleistung. Letztendlich habe ich dann versucht die Ladeleistung so beim WR vorzugeben, das es sich auf die Zeit möglichst Netzdienlich verteilt. Zum Ende wird zwar eine hohe Wünschleistung vorgegeben, jedoch der Speicher entscheidet sich für weniger und es wird ein Keil.
...
Sinnvollerweise verändern die BYDs (und sicher auch andere) die max. Ladeleistung in Abhängigkeit vom akt. SOC und der Temperatur. Das ist auch gut, um den Akku nicht zu viel Stress auszusetzen.
ZitatUnter der Annahme, dass die Ladeleistung während der gesamten Ladezeit nie unter die Ladeschlussleistung P_End fallen darf, stehen nicht alle Stunden mit Solarertrag zur Verfügung, sondern nur die, die eine Ladung mit o.g. Ladeschlussleistung garantieren. Also muss ich die Zeit T_L kennen, die mir für die Ladung mit mindestens P_End (von Dir <PowerIn> genannt) zur Verfügung steht. Wenn ich T_L kenne, kann ich am Wechselrichter die Ladeleistung P_L so limitieren, dass ich den Akku erst am Ende des Tages auf den Zielwert EndSOC gebracht habe
Das <PowerIn> ist der Wert, den wir als eine Komponente der Ladeabbruchbedingung in ctrlBatSocManagementXX->loadAbort verwenden. Deswegen war meine Frage, ob die dort angegebene Leistung identisch zu der gerade diskutierten Ladeschlussleistung ist, da ich ansonsten einen weiteren Parameter in ctrlBatSocManagementXX einführen und auch entsprechend beschreiben muß was der User darunter zu verstehen hat.
Der erste Schritt um weiterzukommen wäre jetzt erstmal ein "Ja" oder "Nein". ;)
Zitat von: Parallix am 21 Juni 2025, 11:01:53Zitat von: ch.eick am 21 Juni 2025, 10:53:20...
Moin,
Ich hatte auch mal versucht die Ladeleistung etwas gleichmäßiger zu regeln um in der Mittagszeit einen schönen grafischen Block zu bekommen, jedoch spielt zusätzlich noch die Ladekurve des Speichers mit rein. Ein möglichst linearer Anstieg des SOC ergibt bei mir eine Art von Keil bei der Ladeleistung. Letztendlich habe ich dann versucht die Ladeleistung so beim WR vorzugeben, das es sich auf die Zeit möglichst Netzdienlich verteilt. Zum Ende wird zwar eine hohe Wünschleistung vorgegeben, jedoch der Speicher entscheidet sich für weniger und es wird ein Keil.
...
Sinnvollerweise verändern die BYDs (und sicher auch andere) die max. Ladeleistung in Abhängigkeit vom akt. SOC und der Temperatur. Das ist auch gut, um den Akku nicht zu viel Stress auszusetzen.
Danke für die Rückmeldung, das war mir auch so bewußt, ich wollte es nur nochmal erwähnen, damit nicht zuviel Zeit darein investiert wird.
Gerne hätte ich halt ein weiteres Gerät mit gleichmäßigem, kalkulierbarem Bezug zum Peak Shaving gehabt:-)
Zitat von: DS_Starter am 21 Juni 2025, 11:41:51...
Das <PowerIn> ist der Wert, den wir als eine Komponente der Ladeabbruchbedingung in ctrlBatSocManagementXX->loadAbort verwenden. Deswegen war meine Frage, ob die dort angegebene Leistung identisch zu der gerade diskutierten Ladeschlussleistung ist, da ich ansonsten einen weiteren Parameter in ctrlBatSocManagementXX einführen und auch entsprechend beschreiben muß was der User darunter zu verstehen hat.
Der erste Schritt um weiterzukommen wäre jetzt erstmal ein "Ja" oder "Nein". ;)
Ja, PowerIn sollte die oben diskutierte minimal geforderte Ladeschlussleistung sein und daher vielleicht besser MinTermPwr heißen.
Zitat von: ch.eick am 21 Juni 2025, 12:05:29...
Danke für die Rückmeldung, das war mir auch so bewußt, ich wollte es nur nochmal erwähnen, damit nicht zuviel Zeit darein investiert wird.
Gerne hätte ich halt ein weiteres Gerät mit gleichmäßigem, kalkulierbarem Bezug zum Peak Shaving gehabt:-)
Hier geht es ja nicht um regelungstechnisch nicht trivial zu betrachtende klassische Peaks, die zeitlich nur sehr kurz anstehen, sondern um längere Zeiträume mit erhöhten Erzeugungs- oder Verbrauchsleistungen. Auf Basis von SF können beide prognostiziert und damit auch kalkulatorisch berücksichtigt werden. Sofern überhaupt genügend Akku-Kapazität zur Verfügung steht (wird immer so dargestellt, ist im privaten Bereich aber häufig nicht der Fall), können die Erzeugungsanteile, die gekappt werden sollen, in den den Speicher verbracht werden.
Offensichtlich bräuchte man für Deinen Anwendungsfall neben dem von mir vorgeschlagenen Wert für die minimale geforderten Ladeschlussleistung, über deren Verwendung die maximalen Ladezeiten bestimmt werden kann, noch weitere Werte zur Betrachtung von zum kappenden Erträgen: Ein Wert, mit dem die maximale tolerierbare Einspeiseleistung angegeben wird, ein Wert für die Dauer der prognostizierten Einspeisekappung und ein Wert für die Energie, die durch die Kappung dann anderweitig zu "entsorgen" ist.
@Parallix, @all,
in meinem contrib liegt die V 1.52.16. und ist jetzt auch eingecheckt.
Ergänzt ist nun die Option remainingSurplsHrsMinPwrBat_XXim Attribut ctrlSpecialReadings:
remainingSurplsHrsMinPwrBat_XX
die verbleibende Anzahl Stunden am aktuellen Tag, in denen der PV-Überschuß (Wh) höher ist als das
kalkulierte Stundenintegral einer minimalen Ladeleistung der Batterie XX.
Die Angabe <MinPwr> erfolgt im Attribut ctrlBatSocManagementXX->loadAbort.
Es wird natürlich geprüft, ob Attribut ctrlBatSocManagementXX->loadAbort gesetzt ist, da <MinPwr> für diese Auswertung benötigt wird.
Der Wert remainingSurplsHrsMinPwrBat_XX wird natürlich dynamisch mit jedem SF-Zyklus neu berechnet, sodaß Änderungen in diversen Vorhersagen und Verhältnissen im Stromnetz eingehen.
Diese Version enthält kumulativ einige Erweiterungen seit der letzten offiziellen Version.
Deswegen hier die hinzugekommenen Features im Überblick:
- Attr ctrlSpecialReadings enthält die neuen Optionen remainingHrsWoChargeRcmdBat_XX und remainingSurplsHrsMinPwrBat_XX
- die Balkengrafik ist hinsichlich ihrer linearen Skalierung überarbeitet
- jede Ebene der Balkengrafik kann getrennt auf eine logarithmische Skalierung umgestellt werden (Attr graphicControl->scaleMode)
- das Attr ctrlBatSocManagementXX->loadAbort ist um eine Freigabebedingung erweitert
EDIT: Anpassung der Beschreibung von remainingSurplsHrsMinPwrBat_XX
EDIT2: Ich habe den Namen des Special Readings geändert damit er besser auf den eigentlichen Inhalt der
Berechnung passt. Dass man das Reading zur Ladesteuerung der Bat verwendet steht auf einem anderen
Blatt.
LG,
Heiko
Zitat von: DS_Starter am 19 Juni 2025, 19:04:30Ich habe das Fallbeispiel Pumpensteuerung (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Fallstudie:_Umw%C3%A4lzpumpe_Pool_soll_X_Stunden_am_Tag_laufen._Ist_kein_PV-%C3%9Cberschu%C3%9F_vorhanden,_m%C3%BCssen_die_X_Stunden/Tag_trotzdem_erreicht_werden) im Wiki überarbeitet.
Das sollte nun passen.
Hallo Heiko!
Vielen Dank! Nun passt es perfekt. Es schaltet nun genauso wie erwartet. :)
Kleiner Schönheitsfehler im wiki:
if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1"); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0"); # keine Interrupt-Freigabe
}
mit "consumer$c" wird auch die Nummer des Verbrauchers vom Script benutzt.
Danke für das Modul und den Support!
Gruß
Bismosa
ZitatKleiner Schönheitsfehler im wiki...
Danke, habe es gleich angepasst. War mir doch wieder durchgerutscht. ;)
Die V 1.52.16 ist eingecheckt.
Zitat von: DS_Starter am 21 Juni 2025, 21:55:48Die V 1.52.16 ist eingecheckt.
Hallo Heiko!
Nachdem ich korrekterweise zuvor aufgefordert wurde, meine bisherigen Settings von <ctrlBatSocManagementXX> zu erweitern, habe ich soeben <remainingSurplsHrsMinPwrBat_XX> via <ctrlSpecialReadings> aktivieren können.
Nun erhalte ich für meine beiden BATs <special_remainingSurplsHrsMinPwrBat_XX> und damit einen Wert, auf dessen Basis ich die Ladeleistungen der BATs konfigurieren kann. Der angezeigte Wert ist stimming! Super! Danke!
Einige Dinge sind mir aufgefallen:
- <special_remainingSurplsHrsMinPwrBat_XX> sollte noch in einen Gleitkommawert überführt werden, da ja von der aktuellen Zeit ausgehend die noch verbleibenden Ladestunden bestimmt werden (sollten).
- Trotz via <loadAbort> eingestelltem Threshold (bei mir 5%) wird in SF am Tagesende nach Erreichen von SOC=100% für einige Folgestunden (bei einem weiterhin prognostiziertem SOC von 100%) noch eine Ladeempfehlung gegeben.
- Der Bezeichner special_remainingSurplsHrsMinPwrBat_XX ist doch recht sperrig und schlecht lesbar/interpretierbar und könnte durch special_remSunHrsWithMinChgPwrBat_XX ersetzt werden. Sofern denkbar, könnte man auch das Prefix "special_" durch ein "s_" erseten
Moin,
freut mich, dass es klappt.
Zitat<special_remainingSurplsHrsMinPwrBat_XX> sollte noch in einen Gleitkommawert überführt werden, da ja von der aktuellen Zeit ausgehend die noch verbleibenden Ladestunden bestimmt werden (sollten).
Kann ich machen. Das bezieht sich im Prinzip immer auf die aktuelle (angebrochene) Stunde die dann zu dem Gleitkommawert führt.
ZitatTrotz via <loadAbort> eingestelltem Threshold (bei mir 5%) wird in SF am Tagesende nach Erreichen von SOC=100% für einige Folgestunden (bei einem weiterhin prognostiziertem SOC von 100%) noch eine Ladeempfehlung gegeben.
Du meinst sicherlich, dass "Battery_ChargeRecommended_XX=1" gesetzt ist. Ja, das ist richtig so, da dieses Reading eine "Ladefreigabe" im Sinne der Netzdienlichkeit signalisiert und auch Nachts 1 sein wird wenn keine PV anliegt. Konsequenterweise sollte ich es umbenennen in z.B. "Battery_ChargeFullRelease_XX=1" im Sinne einer vollen Ladefreigabe gegenüber der beschränkten Ladefreigabe bei Überschreiten eines Einspeiselimits. Eine solche Umbenennung zieht wieder einigen Aufwand beim Nutzer nach sich, weswegen ich bislang davon Abstand genommen habe. Kommt aber vllt. noch wenn gewünscht.
ZitatDer Bezeichner special_remainingSurplsHrsMinPwrBat_XX ist doch recht sperrig und schlecht lesbar/interpretierbar und könnte durch special_remSunHrsWithMinChgPwrBat_XX ersetzt werden
Hier war mir der Bezug zu den Stunden mit PV-Überschuß (SurplsHrs) sehr wichtig, da dieser Wert die Berechnungsgrundlage in Beziehung von <MinPwr> ist weswegen die Bezeichnung so die Inhalt richtig wiedergibt (auch wenn es vllt. am Anfang etwas mühselig ist ;) ). Weiterhin passt die Bezeichnung im Kontext gut zur auch etwas kryptischen Bezeichnung remainingHrsWoChargeRcmdBat_XX.
LG,
Heiko
Zitat von: DS_Starter am 22 Juni 2025, 10:31:35Moin,
freut mich, dass es klappt.
Zitat<special_remainingSurplsHrsMinPwrBat_XX> sollte noch in einen Gleitkommawert überführt werden, da ja von der aktuellen Zeit ausgehend die noch verbleibenden Ladestunden bestimmt werden (sollten).
Kann ich machen. Das bezieht sich im Prinzip immer auf die aktuelle (angebrochene) Stunde die dann zu dem Gleitkommawert führt.
Das wäre super, da man andernfalls die daraus bestimmten Ladeleistungen am Ende eines PV-Tages auf Basis zu ungenauer Zahlen bestimmen müsste.
Zitat von: DS_Starter am 22 Juni 2025, 10:31:35ZitatTrotz via <loadAbort> eingestelltem Threshold (bei mir 5%) wird in SF am Tagesende nach Erreichen von SOC=100% für einige Folgestunden (bei einem weiterhin prognostiziertem SOC von 100%) noch eine Ladeempfehlung gegeben.
Du meinst sicherlich, dass "Battery_ChargeRecommended_XX=1" gesetzt ist. Ja, das ist richtig so, da dieses Reading eine "Ladefreigabe" im Sinne der Netzdienlichkeit signalisiert und auch Nachts 1 sein wird wenn keine PV anliegt. Konsequenterweise sollte ich es umbenennen in z.B. "Battery_ChargeFullRelease_XX=1" im Sinne einer vollen Ladefreigabe gegenüber der beschränkten Ladefreigabe bei Überschreiten eines Einspeiselimits. Eine solche Umbenennung zieht wieder einigen Aufwand beim Nutzer nach sich, weswegen ich bislang davon Abstand genommen habe. Kommt aber vllt. noch wenn gewünscht.
Die Benennung ist in der Tat ungünstig und ich war - wenn ich mich recht erinnere - schon früher einmal darüber gestolpert. Was ich aber überhaupt nicht nachvollziehen kann ist, warum eine Speicherladung nach Sonnenuntergang netzdienlich sein soll. Würde in SF eine Netzbeteiberprognose für (alle) regenerative Energien herangezogen, in der auch die Windkraftanlagen berücksichtigt würden, dann könnte der o.g. Fall auftreten. Im vorliegenden Fall aber wohl doch nicht, oder?
Einfach mal einen anderen Blickwinkel einnehmen. Eine "Ladefreigabe" ist immer vorhanden, es sei denn sie wird durch bestimmte netzdienliche und andere Faktoren "untersagt" bzw. in eine "beschränkte Ladeempfehlung bei Überschreitung des Einspeiselimits" gewandelt. Das ist die Aussage des Readings "Battery_ChargeRecommended_XX=1", mehr nicht.
Zitat von: DS_Starter am 22 Juni 2025, 10:56:36Einfach mal einen anderen Blickwinkel einnehmen. Eine "Ladefreigabe" ist immer vorhanden, es sei denn sie wird durch bestimmte netzdienliche und andere Faktoren "untersagt" bzw. in eine "beschränkte Ladeempfehlung bei Überschreitung des Einspeiselimits" gewandelt. Das ist die Aussage des Readings "Battery_ChargeRecommended_XX=1", mehr nicht.
Wenn ich den anderen Blickwinkel einnehme, dann sehe ich etwas, was (mir) absolut nicht verständlich ist: Netzdienlich soll eine Akkuladung zu einer Zeit sein, in denen keine PV-Leistung zur Verfügung steht? In diesem Fall muss dann aus dem Netz geladen werden, was in den Abendstunden (mit erhöhten Netzlasten durch ein nicht netzdienliches Laden von (Elektroauto-)Batterien, Kochen, Waschen, u.s.w.) keineswegs netzdienlich ist. Also sollte zu diesen Zeiten das Laden "untersagt" (nicht empfohlen) werden! Ausnahme: Es handelt sich um eine Sicherungsladung, mit der a) eine geforderte Mindestenergie für Backupzwecke eingelagert wird oder b) der Akku vor einer Tiefentladung geschützt wird. Beide letztgenannten sind aber außerhalb von SF zu betrachten.
PS: Hilf mir bitte mit dem Blickwinkel, wenn ich irgendetwas total falsch sehe oder verstehe!
Die Übersetzung von "Battery_ChargeRecommended" ist wohl "Batterie_LadungEmpfohlen"
Was gibt es an dem zu deuten
"Trump" sagte ja auch das er in 24 Stunden Frieden stiften wird - er sagte ja "nur" nicht von wann an.....
sorry ;) O:-)
ZitatNetzdienlich soll eine Akkuladung zu einer Zeit sein, in denen keine PV-Leistung zur Verfügung steht?
Löse dich von der Vorstellung, das Reading ist ausschließlich für ein netzdienliches Verhalten da. Es dient auch dazu ein optimales Verhältnis zwischen Einspeisung und Batterie-Endaufladung zu erreichen, also Gewinnmaximierung zum Schutz unserer eigenen Investition um ein Herabregeln der Anlage zu vermeiden. In Verbindung mit plantControl->feedinPowerLimit wird ein netzdienliches Verhalten
unterstützt. Vergleiche dazu auch den Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Unterst%C3%BCtzung_eines_netzdienlichen_Verhaltens) im Wiki.
Wie schon geschrieben ist das Reading Battery_ChargeRecommended_XX eher eine "Freigabe". (Vermutlich werde ich das Reading doch noch in Battery_ChargeFullRelease_XX umbenennen. Den Schmerz muß ich dann nur einmal ertragen.) D.h. natürlich ist die Ladung in der Nacht auch freigegeben wenn man mag. Aber kein ESS was ich kenne lädt ohne PV-Überschuß die Batterie ... außer - und jetzt kommt der nächste Punkt -
ZitatAusnahme: Es handelt sich um eine Sicherungsladung, mit der a) eine geforderte Mindestenergie für Backupzwecke eingelagert wird oder b) der Akku vor einer Tiefentladung geschützt wird.
Dazu gibt es im Modul das Reading
Battery_ChargeRequest_XX. Das wird gesetzt wenn eine Emergency Ladung der Bat erfolgen sollte.
Zusammengfasst ist Battery_ChargeRecommended_XX=1 eine "du kannst laden" Freigabe, wogegen Battery_ChargeRequest_XX=1 eine "du mußt es nun wirklich tun!"-Ansage ist. Dazu gehört im Prinzip noch Battery_ChargeAbort_XX welches besagt, jetzt die "Ladung tatsächlich abbrechen" weil die von dir definierte Bedingung eingetreten ist.
Ich hoffe das ist jetzt noch etwas klarer geworden.
LG,
Heiko
Zitat von: DS_Starter am 22 Juni 2025, 13:42:51...
Ich hoffe das ist jetzt noch etwas klarer geworden.
Ja! Ganz lieben Dank! Stand wirklich auf dem Schlauch! Künftig wird das anderen wohl auch nicht mehr passieren, wenn Du das Reading - wie in Deinen Überlegungen oben beschrieben - umbenennen wirst.
Eine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?
PS[1]: Damit ich beim gelegentlich notwendigen Anfahren des unteren SOCs niemals in einem Zustand der Energielosigkeit bin, hatte ich mich daher seinerzeit für eine aus zwei BATs bestehenden Konfiguration entschieden.
PS[2]: Eine "Emergency Ladung" wird eigentlich stets vom BAT-System ausgelöst.
ZitatEine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?
Ja, das ist noch ein interessanter Aspekt... allerdings könnte es sein, dass man dann heute in die Abregelung geht statt morgen, aber sei es mal dahingestellt.
Man könnte folgendermaßen vorgehen...
Es gibt das Reading special_conForecastTillNextSunrise. Vermutlich bräuchte man dazu eher ein special_conForecastSunSetTillNextSunrise (also den Verbrauch zwischen kommenden Sonnenuntergang und Sonnenaufgang was sicherlich auch machbar wäre).
Jetzt muß man nur in ctrlUserExitFn eine kleine Routine schreiben, die den vorhandenen SoC über alle Batterien (BatteryVal ($name, <Batterienummer 01, 02, ..., 'bchargewh', 0) in Wh) als Summe ermittelt.
Ist diese Summe in Wh >= special_conForecastTillNextSunrise (unter Berücksichtigung eines Sicherheitszuschlages und minimal zu verbleibenden SOC), dann könnte man einen Ladestop-Befehl an die Batterie(n) im Skript absetzen. Fällt der Soc wieder unter X, gibst du das Laden wieder frei. Das könnte man auch mittels dynamischen Setzen von ctrlBatSocManagementXX->loadAbort batteriespezifisch automatisieren.
ZitatPS[2]: Eine "Emergency Ladung" wird eigentlich stets vom BAT-System ausgelöst.
Ja, ich weiß. Möglicherweise möchte man bereits etwas vorher druckbetanken. Meine Pylons haben einen absoluten Minimal-SoC lt. Datenblatt von 5%. Die will ich nicht riskieren und will auf mindestens 10% bleiben. D.h. zw. 5-9% würde mir das Reading das Emergency Laden signalisieren. (ctrlBatSocManagementXX->lowSoc)
Zitat von: DS_Starter am 22 Juni 2025, 15:04:13ZitatEine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?
Ja, das ist noch ein interessanter Aspekt... allerdings könnte es sein, dass man dann heute in die Abregelung geht statt morgen, aber sei es mal dahingestellt.
Hallo zusammen,
das hatte ich auch schon mal geschrieben, bei mir nenne ich das MaxSOC Limitierung.
- Morgens ermittle ich den SOC beim Übergang vom Speicherbetrieb zur PV Übernahme durch die Module.
- Den SOC am Abend, wenn der Speicher vollständig übernimmt, verwende ich in der Berechnung des geplanten SOCs ebenfalls.
- Sollte der Speicher bei der MaxSOC Limitierung am Nachmittag z.B. wegen des E-Auto ladens verwendet werden, wird die Limitierung ausgesetzt.
- Wenn bei uns dann nachmittags geplant wurde den Wirlpool am Abend zu nutzen, dann setze ich die MaxSOC Limitierung manuell auf 100%.
Es ist also wichtig, wenn man dynamisch limitieren möchte, dass man auch manuell umplanen kann, denn das kann die Steuerung nicht erahnen :-)
Mein Code wäre in diesem DOIF zufinden. (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick/Photovoltaik/Wechselrichter/RAW_WR_1_Speicher_1_ExternControl.txt) Block 7_SOC_Calculation reagiert auf den Übergang morgens und im 8_Reset werden die Merker gesichert.
VG Christian
Zitat von: DS_Starter am 22 Juni 2025, 15:04:13...
Man könnte folgendermaßen vorgehen...
Es gibt das Reading special_conForecastTillNextSunrise. Vermutlich bräuchte man dazu eher ein special_conForecastSunSetTillNextSunrise (also den Verbrauch zwischen kommenden Sonnenuntergang und Sonnenaufgang was sicherlich auch machbar wäre).
...
Aufgrund der bereits diskutierten Ladeschlussbedingung und einer stets existierenden Grundlast, wäre es wohl eher ein special_consFcastFromChgTermTillNextChg, oder?
Zitat von: DS_Starter am 22 Juni 2025, 15:04:13ZitatEine Sache beschäftigt mich noch: Um ein Herabregeln der Anlage zu vermeiden, müsste man eigentlich abends die Ladung dann aussetzen, wenn - gemäß Forecast - die BAT so voll ist, dass man über die Nacht kommt und morgens einen minimalen SOC (mit einer auf Basis von Unsicherheiten zu bestimmenden Reserve) nicht unterschreitet. Neben dem oberen SOC sollte, damit das BAT-System gelegentlich auch mal die untere Grenze sieht (wichtig für dessen SOC-Kalibration), auch der BAT-Zustand "leer" hin und wieder mal erreicht werden. Wie würdest Du das auf Basis der aktuell verfügbaren SF-Readings angehen?
Ja, das ist noch ein interessanter Aspekt... allerdings könnte es sein, dass man dann heute in die Abregelung geht statt morgen, aber sei es mal dahingestellt.
Ich unterliege ja noch der 70% Regelung und versuche diese so gut es geht zu vermeiden. Durch Ost/West und etwas Süd hält sich das Abregeln sehr in Grenzen, da ich einige Geräte in die Zeit schieben kann.
- WP mit WW ab 12 Uhr für 30-45 Minuten
- Wirlpool ab 12:30 Uhr für ca 2-3 Stunden
- Speicherladen nach dem Mittagshoch aus der Leistungsprognose. Da kommt dann die Ladezeitberechnung mit dem Delta SOC zum Tragen, was besagten Keil zur Folge hat.
Darüber hinaus habe ich eine openWB, die von hause aus ein Mittagshoch als Regelpunkt beachten kann. Diesen regelpunkt berechne ich ebenfalls dynamisch und verschiebe ihn, um das E-Auto auch mal über mehrere Tage als Speicher in der Mittagszeit zu verwenden. Das ganze ist jedoch noch eher experimentell zu betrachten. Die mögliche Ladeleistung wird zusätzlich durch die anderen Starkverbraucher dynamisch reduziert, um das Ladefenster möglichst in die Länge zu ziehen. Natürlich kann man das vereinfacht auch mit einer starren Ladeleistung machen, die müsste man dann aber auch noch über ein Zeitfenster begrenzen. Ich mag es halt gerne dynamisch und automatisch ;-)
Ich berechne jetzt den Readingswert für special_remainingSurplsHrsMinPwrBat_XX auf 2 Stellen nach dem Komma. Ist eingecheckt und auch in meinem contrib verfügbar.
Zitat von: DS_Starter am 22 Juni 2025, 15:48:10Ich berechne jetzt den Readingswert für special_remainingSurplsHrsMinPwrBat_XX auf 2 Stellen nach dem Komma. Ist eingecheckt und auch in meinem contrib verfügbar.
Suppi!
ZitatAufgrund der bereits diskutierten Ladeschlussbedingung und einer stets existierenden Grundlast, wäre es wohl eher ein special_consFcastFromChgTermTillNextChg, oder?
Naja, dieses in den Raum geworfene Reading special_conForecastSunSetTillNextSunrise ist inhaltlich der prognostizierte Verbrauch zwischen kommenden Sonnenuntergang und kommenden Sonnenaufgang, also der Nachtverbrauch. Das ist zunächst einmal völlig losgelöst von der Verwendung in der Bat-Ladesteuerung -> deswegen passt der Name schon.
Zitat von: ch.eick am 22 Juni 2025, 15:37:14...
Natürlich kann man das vereinfacht auch mit einer starren Ladeleistung machen, die müsste man dann aber auch noch über ein Zeitfenster begrenzen. Ich mag es halt gerne dynamisch und automatisch ;-)
Möglichst viel dynamisch hinzubekommen, dürfte auch in erheblichem Maße den Komfort und damit auch die Akzeptanz durch weniger technisch interessierte Menschen erhöhen. Alles zusammen macht SF zu einem immer leistungsfähigeren Modul, was schon unglaublich nahe an einem EMS ist. Toll!
Zitat von: DS_Starter am 22 Juni 2025, 15:53:01ZitatAufgrund der bereits diskutierten Ladeschlussbedingung und einer stets existierenden Grundlast, wäre es wohl eher ein special_consFcastFromChgTermTillNextChg, oder?
Naja, dieses in den Raum geworfene Reading special_conForecastSunSetTillNextSunrise ist inhaltlich der prognostizierte Verbrauch zwischen kommenden Sonnenuntergang und kommenden Sonnenaufgang, also der Nachtverbrauch. Das ist zunächst einmal völlig losgelöst von der Verwendung in der Bat-Ladesteuerung -> deswegen passt der Name schon.
Von welchem Sunrise bzw. Sunset sprechen wir eigentlich, wenn wir mal von den im Modul SUNRISE_EL genannten Definitionen (real, civil, nautic oder astronmic) ausgehen? Im SF-Wiki habe ich hierzu zumindest nichts gefunden. Eine saubere Definition ist jedoch wichtig, denn selbst bei der Annahme "real" bin ich sicher nicht der einzige, bei dem der Verbrauch (im Akku) konservierter Energie schon einige Zeit vor dem Sonnenuntergang beginnt und am kommenden Tag erst einige Zeit nach dem Sonnenaufgang endet!
ZitatVon welchem Sunrise bzw. Sunset sprechen wir eigentlich
Sofern die lokalen Koordinaten gesetzt sind (wird geprüft und sollte dadurch immer gwährleistet sein) wird der Standard aus https://metacpan.org/release/JFORGET/DateTime-Event-Sunrise-0.0505/view/lib/DateTime/Event/Sunrise.pm (HORIZON=-0.833) verwendet.
Ansonsten gibt es ein Fall-Back auf die durch die gewählte Wetter-API gelieferten Werte.
Zitat von: DS_Starter am 22 Juni 2025, 17:30:46...
Sofern die lokalen Koordinaten gesetzt sind (wird geprüft und sollte dadurch immer gwährleistet sein) wird der Standard aus https://metacpan.org/release/JFORGET/DateTime-Event-Sunrise-0.0505/view/lib/DateTime/Event/Sunrise.pm (HORIZON=-0.833) verwendet.
Ansonsten gibt es ein Fall-Back auf die durch die gewählte Wetter-API gelieferten Werte.
Und zur Bestimmung der Zeiten wird SUNRISE_EL genutzt? Fände ich - auch unter dem Gesichtspunkt der Softwarekonsolidierung - gut!
Den Fallback auf die von der Wetter-API gelieferten Werte finde ich hingegen unschön, da die Wahl (Fallback) bei nicht gesetzten lokalen Koordinaten nicht auffällt und es für den Fall, dass die Wetter-API mal nicht genutzt werden kann (Ausfall Internet, Störung des Dienstleistungsanbieters) kein Fallback mehr gibt.
Vorschlag: Gesetzte Station-Koordinaten bei in SF fordern und Fallback auf Wetter-API rausnehmen.
ZitatUnd zur Bestimmung der Zeiten wird SUNRISE_EL genutzt? Fände ich - auch unter dem Gesichtspunkt der Softwarekonsolidierung - gut!
Ja, so ist es.
ZitatDen Fallback auf die von der Wetter-API gelieferten Werte finde ich hingegen unschön, da die Wahl (Fallback) bei nicht gesetzten lokalen Koordinaten nicht auffällt und es für den Fall, dass die Wetter-API mal nicht genutzt werden kann (Ausfall Internet, Störung des Dienstleistungsanbieters) kein Fallback mehr gibt.
Vorschlag: Gesetzte Station-Koordinaten bei in SF fordern und Fallback auf Wetter-API rausnehmen.
Wird gefordert und geprüft. Fall-Back bleibt sicherheitshalber zum Schutz vor diversen Nebenwirkungen drin, auch auf die
unwahrscheinliche Gefahr hin, dass es ein paar Minuten Unterschied geben könnte. Der Nutzer kann ja theoretisch diese Daten im global Device irgenwann löschen wobei sie zum Zeitpunkt der SF-EInrichtung vorhanden waren.
Dafür gibt es den Config-Check. Da kann der User solche Dinge auch nochmal manuell prüfen.
Diesen Check sollte man ab und zu mal durchlaufen lassen. Soviel Mitwirkung darf ich schon erwarten.
Zitat von: DS_Starter am 22 Juni 2025, 15:48:10Ich berechne jetzt den Readingswert für special_remainingSurplsHrsMinPwrBat_XX auf 2 Stellen nach dem Komma. Ist eingecheckt und auch in meinem contrib verfügbar.
Aktuell (8:11) erhalte ich für <special_remainingSurplsHrsMinPwrBat_XX> einen höheren Wert (13.82) als für <special_SunHours_Remain> (13.62), was meiner Ansicht nach nicht stimmen kann, da <SunSet> in SF mit 21:49 angegeben wird und da sicher keinen nennenswerten solaren Ertrag, wohl aber einen höheren Verbrauch habe. Oder erfolgt die Berechnung von <special_remainingSurplsHrsMinPwrBat_XX> ausschließlich auf Basis des 1h-Mittelwerts und nicht, wie seinerzeit von mir vorgeschlagen, auf Basis eines linearen Ansatzes, mit Stützpunkten, die jeweils in der Mitte eines 1h-Intervalls liegen?
Mal was ganz anderes: Künftig wird es wohl immer mehr Anlagen geben, die dynamisch abgeregelt werden können. In der Konsequenz bedeutet das, dass die Leistung, die lokal nicht genutzt wird und daher in das öffentliche Netz eingespeist werden kann (vereinfachend meist PV-Überschuss genannt), nur noch prognostiziert, aber nicht mehr gemessen werden kann.
Insofern wird es zunehmend extrem wichtig sein, sehr gute Prognosedaten zu haben. Hierfür wird es mittelfristig erforderlich sein, das Zeitfenster und die Stärke einer vorgesehenen Abregelung im Vorfeld zu kennen, um diese vorausschauend in SF berücksichtigen zu können. Gibt es hierfür öffentlich zugängige Datenbanken und APIs, die von uns genutzt werden können?
Zitat von: Parallix am 23 Juni 2025, 09:40:31Gibt es hierfür öffentlich zugängige Datenbanken und APIs, die von uns genutzt werden können?
Hallo Parallix
schau mal hier - ist vom Frauenhofer - da gibt es viel - vielleicht passt dir was davon
https://www.energy-charts.info/index.html?l=de&c=DE
Das meiste ist über API verfügbar - ich hab bisschen mit der Stromampel rumgespielt
Gruß Gerd
Zitat von: Parallix am 23 Juni 2025, 09:40:31Mal was ganz anderes: Künftig wird es wohl immer mehr Anlagen geben, die dynamisch abgeregelt werden können. In der Konsequenz bedeutet das, dass die Leistung, die lokal nicht genutzt wird und daher in das öffentliche Netz eingespeist werden kann (vereinfachend meist PV-Überschuss genannt), nur noch prognostiziert, aber nicht mehr gemessen werden kann.
Insofern wird es zunehmend extrem wichtig sein, sehr gute Prognosedaten zu haben. Hierfür wird es mittelfristig erforderlich sein, das Zeitfenster und die Stärke einer vorgesehenen Abregelung im Vorfeld zu kennen, um diese vorausschauend in SF berücksichtigen zu können. Gibt es hierfür öffentlich zugängige Datenbanken und APIs, die von uns genutzt werden können?
Ich denke, gerade im Sommer, wo es die Abregelung geben wird, sind doch unsere Prognosen bereits ziemlich gut, da habe selbst ich mit meinem vereinfachten Ansatz sehr gute Ergebnisse. Daraus bekomme ich ein ziemlich gutes Zeitfenster für das Mittagshoch.
Ich würde nun nicht die Prognose auf biegen und brechen noch besser machen, sondern eher die Zeiten mit der Abregelung hinzuziehen. Wenn man dort einen Block in der Mitte nimmt, wird sicherlich der Solarhügel getroffen werden :-)
Am Beispiel von gestern lag mein Mittagshoch von 12-16 Uhr, was bei Tibber ebenfalls die Stunden mit den niedrigsten Preisen waren. Ich habe da jetzt zwar noch nicht die negativen Preise an der Börse dargestellt, jedoch sollten die mit dem Tibber auf und ab ja deckungsgleich sein.
Über Tibber habe ich mir dann auch noch die höchsten Preise als Zeitfenster berechnet, was entsprechend die beste Zeit für das Einspeisen aus dem Speicher wäre. Leider wird ja diese Unterstützung des Netzes nicht finanziel gefördert, weshalb wohl niemand seinen Speicher dafür hergeben wird.
My5cent
Christian
Zitat von: ch.eick am 23 Juni 2025, 15:36:27Am Beispiel von gestern lag mein Mittagshoch von 12-16 Uhr, was bei Tibber ebenfalls die Stunden mit den niedrigsten Preisen waren. Ich habe da jetzt zwar noch nicht die negativen Preise an der Börse dargestellt, jedoch sollten die mit dem Tibber auf und ab ja deckungsgleich sein.
Hallo Christian,
Ich glaube im Prinzip hast du Recht - zumindest kurzfristig - der Nachteil der Lösung über den Preis ist, das wir nur eine Preiszone haben, daher ist der Preis von der Nordsee bis zum Bodensee identisch - obwohl die regionale Energiesituation unterschiedlich ist - sollten unsere ÜNB wirklich mal mit der Digitalisierung voran kommen könnte es regionale Signale geben d.h. - Smartmeter vorausgesetzt - Anlagen werden regional abgeregelt - aus meinem, bisher sehr oberflächlichen Verständnis setzt da die Stromampel - post vorher - an. Dort habe ich den Netz-Mix bezogen auf meine PLZ. Sollte sich das bestätigen ist das Signal auf die Dauer genauer als der Preis - aus meiner Sicht zumindest.
Heute arbeite ich aber auch mit dem Preis
Gruß Gerd
Zitat von: Max_Meyer am 23 Juni 2025, 16:04:53Zitat von: ch.eick am 23 Juni 2025, 15:36:27Am Beispiel von gestern lag mein Mittagshoch von 12-16 Uhr, was bei Tibber ebenfalls die Stunden mit den niedrigsten Preisen waren. Ich habe da jetzt zwar noch nicht die negativen Preise an der Börse dargestellt, jedoch sollten die mit dem Tibber auf und ab ja deckungsgleich sein.
Hallo Christian,
Ich glaube im Prinzip hast du Recht - zumindest kurzfristig - der Nachteil der Lösung über den Preis ist, das wir nur eine Preiszone haben, daher ist der Preis von der Nordsee bis zum Bodensee identisch - obwohl die regionale Energiesituation unterschiedlich ist - sollten unsere ÜNB wirklich mal mit der Digitalisierung voran kommen könnte es regionale Signale geben d.h. - Smartmeter vorausgesetzt - Anlagen werden regional abgeregelt - aus meinem, bisher sehr oberflächlichen Verständnis setzt da die Stromampel - post vorher - an. Dort habe ich den Netz-Mix bezogen auf meine PLZ. Sollte sich das bestätigen ist das Signal auf die Dauer genauer als der Preis - aus meiner Sicht zumindest.
Heute arbeite ich aber auch mit dem Preis
Gruß Gerd
Ich arbeite mit dem was jetzt und kostenlos verfügbar ist, der Rest wird sicherlich irgendwann kommen :-) :-)
Um meinen Ansatz generischer zu gestallten müsste ich mal auf den Börsenpreis als Quelle umstellen.
Kurze Zwischenfrage,
hat bereits jemand die Abfrage der EPEX Spot Preise direkt von der Quelle, also ohne Drittanbieter Web Seiten dazwischen für FHEM umgesetzt?
Ich hatte im Wiki ja mal https://wiki.fhem.de/wiki/Stromb%C3%B6rse begonnen, jedoch hat bisher niemand etwas ergänzt :-(
Zitat von: ch.eick am 23 Juni 2025, 16:33:59hat bereits jemand die Abfrage der EPEX Spot Preise direkt von der Quelle, also ohne Drittanbieter Web Seiten dazwischen für FHEM umgesetzt?
Ich hatte im Wiki ja mal https://wiki.fhem.de/wiki/Stromb%C3%B6rse (https://wiki.fhem.de/wiki/Stromb%C3%B6rse) begonnen, jedoch hat bish
Hallo Christian,
rudimentär - ich hab das folgende HTTPMOD gemacht - aber bisher nicht weiter verwendet oder geprüft
defmod netprice_1 HTTPMOD https://api.energy-charts.info/price?bzn=DE-LU 3600
attr netprice_1 userattr
attr netprice_1 disable 0
attr netprice_1 extractAllJSON 1
attr netprice_1 group price
attr netprice_1 room XX_Kategorie->HTTPMOD
attr netprice_1 showBody 0
attr netprice_1 userReadings 000_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_0",0) ) ) ."/". ReadingsNum($name,"price_0",0)."". ReadingsVal($name,"unit","0") },\
001_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_1",0) ) ) ."/". ReadingsNum($name,"price_1",0)."". ReadingsVal($name,"unit","0") },\
002_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_2",0) ) ) ."/". ReadingsNum($name,"price_2",0)."". ReadingsVal($name,"unit","0") },\
003_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_3",0) ) ) ."/". ReadingsNum($name,"price_3",0)."". ReadingsVal($name,"unit","0") },\
004_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_4",0) ) ) ."/". ReadingsNum($name,"price_4",0)."". ReadingsVal($name,"unit","0") },\
005_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_5",0) ) ) ."/". ReadingsNum($name,"price_5",0)."". ReadingsVal($name,"unit","0") },\
006_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_6",0) ) ) ."/". ReadingsNum($name,"price_6",0)."". ReadingsVal($name,"unit","0") },\
007_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_7",0) ) ) ."/". ReadingsNum($name,"price_7",0)."". ReadingsVal($name,"unit","0") },\
008_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_8",0) ) ) ."/". ReadingsNum($name,"price_8",0)."". ReadingsVal($name,"unit","0") },\
009_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_9",0) ) ) ."/". ReadingsNum($name,"price_9",0)."". ReadingsVal($name,"unit","0") },\
010_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_10",0) ) ) ."/". ReadingsNum($name,"price_10",0)."". ReadingsVal($name,"unit","0") },\
011_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_11",0) ) ) ."/". ReadingsNum($name,"price_11",0)."". ReadingsVal($name,"unit","0") },\
012_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_12",0) ) ) ."/". ReadingsNum($name,"price_12",0)."". ReadingsVal($name,"unit","0") },\
013_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_13",0) ) ) ."/". ReadingsNum($name,"price_13",0)."". ReadingsVal($name,"unit","0") },\
014_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_14",0) ) ) ."/". ReadingsNum($name,"price_14",0)."". ReadingsVal($name,"unit","0") },\
015_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_15",0) ) ) ."/". ReadingsNum($name,"price_15",0)."". ReadingsVal($name,"unit","0") },\
016_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_16",0) ) ) ."/". ReadingsNum($name,"price_16",0)."". ReadingsVal($name,"unit","0") },\
017_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_17",0) ) ) ."/". ReadingsNum($name,"price_17",0)."". ReadingsVal($name,"unit","0") },\
018_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_18",0) ) ) ."/". ReadingsNum($name,"price_18",0)."". ReadingsVal($name,"unit","0") },\
019_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_19",0) ) ) ."/". ReadingsNum($name,"price_19",0)."". ReadingsVal($name,"unit","0") },\
020_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_20",0) ) ) ."/". ReadingsNum($name,"price_20",0)."". ReadingsVal($name,"unit","0") },\
021_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_21",0) ) ) ."/". ReadingsNum($name,"price_21",0)."". ReadingsVal($name,"unit","0") },\
022_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_22",0) ) ) ."/". ReadingsNum($name,"price_22",0)."". ReadingsVal($name,"unit","0") },\
023_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_23",0) ) ) ."/". ReadingsNum($name,"price_23",0)."". ReadingsVal($name,"unit","0") }\
Gruß Gerd
PS.: ggfls ist das off Topic und wir sollten woanders weiter diskutieren?
ZitatAktuell (8:11) erhalte ich für <special_remainingSurplsHrsMinPwrBat_XX> einen höheren Wert (13.82) als für <special_SunHours_Remain> (13.62), was meiner Ansicht nach nicht stimmen kann, da <SunSet> in SF mit 21:49 angegeben wird und da sicher keinen nennenswerten solaren Ertrag, wohl aber einen höheren Verbrauch habe.
Ich habe eine Weile gesucht um die Ursache zu finden. In der Stunde des Sonnenuntergangs hatte ich vergessen nur anteilig zu rechnen.
Die Version 1.52.18 ist eingecheckt. In dieser Version gibt es auch ein weiteres Special Reading:
conForecastComingNight Verbrauchsprognose vom kommenden Sonnenuntergang bis zum kommenden Sonnenaufgang. Ist der Sonnenuntergang
bereits vergangen, ist es die Verbrauchsprognose ab aktueller Zeit (Nacht) bis zum kommenden Sonnenaufgang.
LG,
Heiko
Zitat von: DS_Starter am 23 Juni 2025, 22:39:16ZitatAktuell (8:11) erhalte ich für <special_remainingSurplsHrsMinPwrBat_XX> einen höheren Wert (13.82) als für <special_SunHours_Remain> (13.62), was meiner Ansicht nach nicht stimmen kann, da <SunSet> in SF mit 21:49 angegeben wird und da sicher keinen nennenswerten solaren Ertrag, wohl aber einen höheren Verbrauch habe.
Ich habe eine Weile gesucht um die Ursache zu finden. In der Stunde des Sonnenuntergangs hatte ich vergessen nur anteilig zu rechnen.
Danke für Dein Feedback und das Update! Super!
Zitat von: DS_Starter am 23 Juni 2025, 22:39:16Die Version 1.52.18 ist eingecheckt. In dieser Version gibt es auch ein weiteres Special Reading:
conForecastComingNight
Verbrauchsprognose vom kommenden Sonnenuntergang bis zum kommenden Sonnenaufgang. Ist der Sonnenuntergang
bereits vergangen, ist es die Verbrauchsprognose ab aktueller Zeit (Nacht) bis zum kommenden Sonnenaufgang.
Ganz große Klasse!
@ch.eick: Bin ganz bei Dir: Richtig konfiguriert liefert SF in aller Regel eine wirklich gute Prognose. In meinem vorherigen Beitrag wollte ich auch auch nicht in Richtung Verbesserung der Prognosesoftware SF gehen, sondern in Richtung der erforderlichen Datenquellen für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht. Meines Erachtens haben das noch viele Leute überhaupt nicht auf dem Schirm.
PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.
Zitat von: Parallix am 24 Juni 2025, 09:20:20PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.
Das mag für deinen und evtl. andere WR ja so sein - bei mir wird immer so oder so geladen wenn es (seitens des BWR/BMS wird übersteuert) für die "Gesundheit" der Batterie auch notwendig ist. ;D ;) O:-)
Zitat... für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht.
Die Abregelung der Anlage ist ein generelles Problem im Hinblick auf die Auswertung von Prognose und realer Erzeugung bzw. davon abgeleitete Korrekturfaktoren, KI-Trainings, Überschußprognosen und was alles sonst noch davon abhängig ist.
Für das Modul ist im Fall einer Abregelung die realer Erzeugung einfach nicht vorhanden und führt zu einem entsprechenden Gap zwischen Prognose und Ertrag und in der Folge zu tendenziell falschen Korrekturen. In gewisser Weise ist durch den verwendeten Median eine Resilienz im Modul eingebaut, dennoch ist es auf Dauer ein Problem für die Prognose.
Eine Variante wäre die Datensätze vom Learning auszuschließen sofern eine Abregelung der Anlage erfolgt, was wiederum thematisiert, dass:
1. SF in geeigneter Weise über eine aktive Abregelung der Anlage informiert werden muß
2. wenn die Anlage zu häufig/zu regelmäßig abgeregelt wird, eine durchgängige und zügig arbeitende Anpassung
der Korrekturen vermutlich nicht mehr realisiert wird
Nach meiner aktuellen Einschätzung werde ich vermutlich über den Einbau von Punkt 1) nicht drumherum kommen falls uns nicht etwas besseres einfällt.
LG,
Heiko
Zitat von: 300P am 24 Juni 2025, 10:37:36Zitat von: Parallix am 24 Juni 2025, 09:20:20PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.
Das mag für deinen und evtl. andere WR ja so sein - bei mir wird immer so oder so geladen wenn es (seitens des BWR/BMS wird übersteuert) für die "Gesundheit" der Batterie auch notwendig ist. ;D ;) O:-)
Der Gesundheit wegen hatte ich deshalb auf diese Angelegenheit hingewiesen. Persönlich bin ich froh, dass ich die maximale Ladeleistung auch im Fall "Notladung" limitieren kann und nicht der Strategie des Herstellers ausgeliefert bin.
Zitat von: DS_Starter am 24 Juni 2025, 11:46:31...
Eine Variante wäre die Datensätze vom Learning auszuschließen sofern eine Abregelung der Anlage erfolgt ...
Auch wenn man klassisch (also ohne KI) herangeht muss das Vorliegen des Sonderfalls "Abregelung" bekannt sein. Wenn dann für die Zeit der Abregelung eine gute Schätzung für die solar einbringbare Energie vorliegt, kann man diese regelungstechnisch als Ersatzwerte für die zu einem Zeitpunkt nicht messbaren aber möglichen Ertragswerte ansetzen. Alles nicht trivial, aber sicher auch kein Mega-Showstopper.
ZitatWenn dann für die Zeit der Abregelung eine gute Schätzung für die solar einbringbare Energie vorliegt, kann man diese regelungstechnisch als Ersatzwerte für die zu einem Zeitpunkt nicht messbaren aber möglichen Ertragswerte ansetzen.
Das wäre im Prinzip identisch den Ertragswert = Prognosewert zu setzen, falls der Abregelungsstatus vorliegt. Kann man machen. SF muß in jedem Fall über den Abregelungsstatus informiert werden. Tritt dieser Status auch nur zu einem gewissen Teil einer Stunde (z.b. 20 Minuten) ein, wäre der Datensatz dieser Stunde als komprimitiert und als entspechend zu behandeln vorzusehen.
Zitat von: Parallix am 24 Juni 2025, 13:01:06Zitat von: 300P am 24 Juni 2025, 10:37:36Zitat von: Parallix am 24 Juni 2025, 09:20:20PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.
Das mag für deinen und evtl. andere WR ja so sein - bei mir wird immer so oder so geladen wenn es (seitens des BWR/BMS wird übersteuert) für die "Gesundheit" der Batterie auch notwendig ist. ;D ;) O:-)
Der Gesundheit wegen hatte ich deshalb auf diese Angelegenheit hingewiesen. Persönlich bin ich froh, dass ich die maximale Ladeleistung auch im Fall "Notladung" limitieren kann und nicht der Strategie des Herstellers ausgeliefert bin.
Bei mir ist die Notladung bisher nur im Winter bei längerer PV Flaute mal aufgetreten. Das ist mit MinSOC 20% und meinem SmartLaden, bis wieder 100% erreicht ist, schon einige Jahre nicht mehr aufgetreten. Ich denke im Winter wird ja wohl niemand auf die Idee kommen PV abzuregeln.
Zitat von: Parallix am 24 Juni 2025, 09:20:20@ch.eick: Bin ganz bei Dir: Richtig konfiguriert liefert SF in aller Regel eine wirklich gute Prognose. In meinem vorherigen Beitrag wollte ich auch auch nicht in Richtung Verbesserung der Prognosesoftware SF gehen, sondern in Richtung der erforderlichen Datenquellen für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht. Meines Erachtens haben das noch viele Leute überhaupt nicht auf dem Schirm.
Wie Heiko schon geschrieben hat würde das automatische Lernen der KI gestört werden.
Bei meiner Prognose Variante werde ich mal die Abregelung mit in die Datensammlung aus der MySQL einbauen und die Datensätze dann verwerfen.
ZitatPS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.
Die 0W sind doch am SmartMeter, da wird der Haushalt und der Speicher doch trotzdem versorgt.
Zitat von: ch.eick am 24 Juni 2025, 14:15:27Zitat von: Parallix am 24 Juni 2025, 09:20:20@ch.eick: Bin ganz bei Dir: Richtig konfiguriert liefert SF in aller Regel eine wirklich gute Prognose. In meinem vorherigen Beitrag wollte ich auch auch nicht in Richtung Verbesserung der Prognosesoftware SF gehen, sondern in Richtung der erforderlichen Datenquellen für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht. Meines Erachtens haben das noch viele Leute überhaupt nicht auf dem Schirm.
Wie Heiko schon geschrieben hat würde das automatische Lernen der KI gestört werden.
Bei meiner Prognose Variante werde ich mal die Abregelung mit in die Datensammlung aus der MySQL einbauen und die Datensätze dann verwerfen.
Zu einer Störung dürfte es bei einer gut trainierten KI nur dann kommen, wenn nicht erkennbar ist, warum sich Dinge anders verhalten. Daher ist es ganz wichtig, dass die KI weiß, wenn der Fall "Abregelung" vorliegt und wie stark die Abregelung dann ausfällt.
Zitat von: ch.eick am 24 Juni 2025, 14:15:27ZitatPS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.
Die 0W sind doch am SmartMeter, da wird der Haushalt und der Speicher doch trotzdem versorgt.
Es ging um die Ladeleistung vom WR in Richtung des DC-gekoppelten Speichers!
Zitat von: Parallix am 24 Juni 2025, 16:07:17Daher ist es ganz wichtig, dass die KI weiß, wenn der Fall "Abregelung" vorliegt und wie stark die Abregelung dann ausfällt.
Leute, bitte bedenkt: Eine KI - jedenfalls die Typen, die Ihr verwendet - weiß GAR NICHTS. So etwas wie feste und unumstößliche Regeln könnt Ihr dem System nicht beibringen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 24 Juni 2025, 16:19:12...
Leute, bitte bedenkt: Eine KI - jedenfalls die Typen, die Ihr verwendet - weiß GAR NICHTS. So etwas wie feste und unumstößliche Regeln könnt Ihr dem System nicht beibringen.
Warum sollte es nicht mittels "Reinforcement Learning" und einem geeigneten Belohnungsschema zu machen sein?
Zitat von: DS_Starter am 23 Juni 2025, 22:39:16Verbrauchsprognose vom kommenden Sonnenuntergang bis zum kommenden Sonnenaufgang. Ist der Sonnenuntergang
bereits vergangen, ist es die Verbrauchsprognose ab aktueller Zeit (Nacht) bis zum kommenden Sonnenaufgang.
Hallo Heiko,
zuerst einmal DANKE für die vielen Ideen die du in dieses tolle Modul einfließen lässt!
Trotzdem, jedes neue Feature erzeugt neue Wünsche ;) - in meinem Falle geht es um prognosegeführte Steuerung der WP - sozusagen der der größte Energiefresser (ca. 3500 kWh/a) unter den Verbrauchern und 'unglücklicher Weise ist sie gerade im Winter am gefräßigsten - man will ja nicht frieren :) so gehen über 60% des externen Bezugs :'( auf die Heizung zurück.
Die WP ist auch dahingehend ein Sonderfall-Verbraucher weil diese sehr saisonal (bei mir nur in der Heizperiode) im Einsatz ist - aber so wie ich das verstanden habe, werden alle Verbraucher gemittelt erfasst - so dass sich der Verbrauch über das Jahr und alle consumer verschleift so das die WP nicht wirklich auftaucht.
Generisch gesehen ist die WP(+Puffer) in gewisser Weise wie eine Batterie - es wird Energie eingespeichert wenn sie günstig ist und entnommen solange was drin ist.
Die Frage ist ob sich sowas (leicht - mit überschaubaren Aufwand) in einem Batterie-ähnlichen Device abbilden lassen würde?
Mir sind dabei 2 Szenarien im Sinn:
- die WP mit der Überschussleistung füttern um den Puffer wärmer zu machen als er müsste solange Sonne scheint (ungeregelt mach ich das seit Jahren WP als Prio1) lässt sich verbessen mit Prognosewerten
- die WP mit einem errechneten Konstantwert (gesamtenergiebetrag pro tag geteilt durch 24) theoretisch 24h mit geringer Leistung durchlaufen zu lassen dadurch steigt der COP (theoretisch 10-20%) bei ungenügenden Sonnenschein. Voraussetzung wäre eine 'Energieprognose'
next topic:
Zitat von: DS_Starter am 24 Juni 2025, 13:34:32Das wäre im Prinzip identisch den Ertragswert = Prognosewert zu setzen, falls der Abregelungsstatus vorliegt. Kann man machen. SF muß in jedem Fall über den Abregelungsstatus informiert werden. Tritt dieser Status auch nur zu einem gewissen Teil einer Stunde (z.b. 20 Minuten) ein, wäre der Datensatz dieser Stunde als komprimitiert und als entspechend zu behandeln vorzusehen
warum nutzt du nicht den Parameter 'Limit' aus dem setupInverterDevXX? Die Gültigkeit Regel 'Ertragswert = Prognosewert' wäre auch (relativ) simpel. Der Wert (von limit) könnte bei Bedarf dynamisch von user gesetzt werden.
next topic:
ich habe mir mal stichpunktartig die Daten Today_Hourxx_PVforecast in Bezug auf die summierten Readings dazu angeschaut und leichte Diskrepanzen festgestellt --> siehe screens
Abweichung ist nicht groß nur verwunderlich - ist das plausibel oder hab ich falsch gerechnet?
last topic:
nur zur Info - ich habe mal mit aiTreesPV 'herumgespielt' und die auf 10, 30, 40 gesetzt - auf unterschiedlichen RPI-Devices - hab CPU und RAM mitgeloggt und die Abweichung verglichen - Ergebnis: in keinem Falle wurde mehr als 35% RAM verwendet (für alle Anwendungen) und die war sinnigerweise bei der 10er im Schnitt am besten (gleiche Daten)
Gruß Gerd
Hallo Gerd,
viele Fragen auf einmal ... ;)
ZitatWärmepumpe:
die WP mit der Überschussleistung füttern um den Puffer wärmer zu machen als er müsste solange Sonne scheint (ungeregelt mach ich das seit Jahren WP als Prio1) lässt sich verbessen mit Prognosewerten
Vermutlich habe ich es noch nicht wirklich verstanden worum es dabei eigentlich geht. Wenn es nur darum geht einen vorhandenen PV-Überschuß in der WP zu "verbrauchen" kann man doch einen Consumer entsprechen konfigurieren. Vllt. kannst du das Anliegen noch etwas anders formulieren.
Zitatwarum nutzt du nicht den Parameter 'Limit' aus dem setupInverterDevXX? Die Gültigkeit Regel 'Ertragswert = Prognosewert' wäre auch (relativ) simpel.
Du meinst damit sicherlich, dass man "limit" als Signal für die Abregelung der Anlage verwenden könnte? D.h. wird die Anlage abgeregelt, setzt man z.B. limit=0. Im Prinzip ginge das, hätte aber zur Folge dass der User u.U. in allen vorhandenen WR setzen müßte. Anlagen regeln aber nicht unbedingt auf 0, sondern evtl. nur soweit herunter bis ein bestimmter Einspeisewert unterschritten ist. Gibt bestimmt viele Varianten. In jedem Fall ist der Ertrag dann künstlich vermindert und der Datensatz in der Stunde bildet nicht die eigentlich realen Verhältnisse ab. Mir schwebt da schon etwas vor. ;)
Zitatich habe mir mal stichpunktartig die Daten Today_Hourxx_PVforecast in Bezug auf die summierten Readings dazu angeschaut und leichte Diskrepanzen festgestellt --> siehe screens
Abweichung ist nicht groß nur verwunderlich - ist das plausibel oder hab ich falsch gerechnet?
Wahrscheinlich ein Mißverständnis. Die Today_HourXX_PVforecast beeinhalten die PV Prognose für die Stunde des Tages. Die NextHours_SumXX_PVforecast die Summe der PV Prognose für die nächsten XX Stunden, wobei die verstrichenen Minuten berücksichtigt werden, also z.B. von jetzt 19:23 bis 20:23 bei NextHours_Sum01_PVforecast. Natürlich ist es wiederum nur eine Näherung, denn die PV-Verteilung innerhalb einer Stunde ist (insbesondere zu dieser Tageszeit) nicht linear. Aber für bestimmte Anwendungen war dies mal ein User-Wunsch den ich gern umgesetzt habe.
LG,
Heiko
Im Wiki habe ich die Steuerungsreadings des Moduls für die Batteriesteuerung in einem Abschnitt (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Erl%C3%A4uterung_der_Batterie-Steuerungsreadings) zusammengefasst erläutert.
Zitat von: DS_Starter am 24 Juni 2025, 19:27:39...
Anlagen regeln aber nicht unbedingt auf 0, sondern evtl. nur soweit herunter bis ein bestimmter Einspeisewert unterschritten ist
...
Da letzteres zumindest die vom VNB ggf. zu bedienende Forderung ist, ist dies die Abregelung, die in aller Regel gemeint ist. Die die dann noch maximal zulässige Einspeiseleistung (Toleranzen mal ausgenommen) bestimmt sich dann stets auf einen Prozentwert der Modulleistung. Im Relais-Fall wären das 0%, 30%, 60% und 100% und im EEBUS-Fall alle Werte in [0%,100%]. Hieraus lässt sich entnehmen, dass die Nutzung von EEBUS zur Steuerung gegenüber dem Relais-basisertem Verfahren u.a. Einspeisevorteile hat bzw. haben kann. Denn bei einer fiktiven beispielhaften Forderung einer Abregelung auf nur 90% müsste ein nicht EEBUS verwendendes System bereits auf 60% abregeln.
Zitat von: DS_Starter am 24 Juni 2025, 19:27:39vermutlich habe ich es noch nicht wirklich verstanden worum es dabei eigentlich geht. Wenn es nur darum geht einen vorhandenen PV-Überschuß in der WP zu "verbrauchen" kann man doch einen Consumer entsprechen konfigurieren. Vllt. kannst du das Anliegen noch etwas anders formulieren.
Hallo Heiko,
du hast recht - ich habe das ziemlich oberflächlich beschrieben - was ich meine ist das eine WP mit Puffer im Prinzip die gleichen Steuersignale braucht wie eine Batterie die konstant geladen werden soll. Um zu verdeutlichen was ich gern erreichen will habe ich ein typisches Schaltspiel eines Heiztages rangehangen und skizziert was ich gern erreichen möchte. Die Idee kam mir bei der Diskussion zu den zusätzlichen Bat-Readings. Falls meine Gedanken abwegig sind und/oder eine Implementation viel Aufwand verursacht ist es auch kein Problem meine bestehende Logik mit vorhanden Signalen aus SF verfeinern - aber eben ohne KI-Unterstützung
Zitat von: DS_Starter am 24 Juni 2025, 19:27:39Du meinst damit sicherlich, dass man "limit" als Signal für die Abregelung der Anlage verwenden könnte? D.h. wird die Anlage abgeregelt, setzt man z.B. limit=0. Im Prinzip ginge das, hätte aber zur Folge dass der User u.U. in allen vorhandenen WR setzen müßte. Anlagen regeln aber nicht unbedingt auf 0, sondern evtl. nur soweit herunter bis ein bestimmter Einspeisewert unterschritten ist. Gibt bestimmt viele Varianten. In jedem Fall ist der Ertrag dann künstlich vermindert und der Datensatz in der Stunde bildet nicht die eigentlich realen Verhältnisse ab. Mir schwebt da schon etwas vor. ;)
ja das hatte ich gedacht - es ist wie Parallix schreibt - gilt aber für die komplette Anlage - ich bin gespannt was dir einfällt
Gruß Gerd
@all,
ich habe die Arbeit von Wzut mit den neuen Batteriesymbolen implementiert und den Ladezustand an das Icon gebracht. Im Anhang seht ihr das Ergebnis.
Ich persönlich finde die Darstellung mit diesen Icons moderner. Danke Wzut!
Wenn es gewünscht ist, kann ich die SoC-Beschriftung optional gestalten.
Version 1.52.19 liegt in meinem contrib.
@Gerd,
deine WP-Geschichte schaue ich mir morgen nochmal an. Heute bekomme ich keinen gescheiten Gedanken mehr hin. ;)
LG,
Heiko
Zitat von: DS_Starter am 24 Juni 2025, 22:31:37ich habe die Arbeit von Wzut mit den neuen Batteriesymbolen implementiert und den Ladezustand an das Icon gebracht. Im Anhang seht ihr das Ergebnis.
Wie immer, Danke für die Arbeit. Mal aus ergonomischer Sicht betrachtet.
Wettersymbole nicht ausreichend voneinander unterscheidbar. Unterschiedliche Farbgebung Wolken/Sonne könnte das verbessern - da müsste mal jemand eine Fleißarbeit machen.
Batterieymbole und Beschriftung OK, etwas weniger Helligkeitskontrast beim Icon würde die Erkennbarkeit der Zahlen verbessern. Warum nicht die Schrift kleiner machen und horizontal anordnen?
Balkendiagramm: Wie schon gesagt, ist das wegen der abwechselnden Anordnung (mal oben, mal unten) ebenfalls schwer zu erfassen.
LG
pah
Zitat von: Parallix am 24 Juni 2025, 16:36:32Warum sollte es nicht mittels "Reinforcement Learning" und einem geeigneten Belohnungsschema zu machen sein?
Weil Statistik immer Statistik bleibt. Neuronale Netze kennen keine festen Regeln.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 25 Juni 2025, 01:56:03Wettersymbole nicht ausreichend voneinander unterscheidbar.
Warum nicht die Schrift kleiner machen und horizontal anordnen?
a. ja die Wetter Icons, wir hatten damals nach der SMA Umstellung und den Wechsel zu DWD nicht genug passende Wetter Icons in FHEM. Also war die erste Überlegung welche der vielen möglichen Codes von DWD wir überhaupt verwenden wollen und welche Symbole uns daher noch fehlen. Da ich nun leider ein lausiger Maler bin und eher der Typ gnadenloser Kopierer, habe ich vorhande Wettersymole verändert. Zum Teil durch löschen von Elementen oder kopieren von Teilen von einem Icon zum anderen.
b. ja mir persönlich gefällt es auch besser die Schrift im Innernraum des Icons zu haben, aber wie bereits geschrieben ist dann wieder das Problem der optimalen Farbe für den möglichen Rot-Grün und Style möglichen Hintergrund. Aber Heiko schrieb ja auch das die Art der Darstellung hauptsächlich ein Ersatz der fehlenden Hoover Funktion beim Tablet/Handy sein soll.
Moin,
ZitatWarum nicht die Schrift kleiner machen und horizontal anordnen?
Ich habe das auch mal umgesetzt (siehe Screenshots) und die V ins contrib geladen.
Wenn ich die Beschriftung optional gestalte (ein Schlüssel im setupBatteryDevXX) ist eine Auswahl ohne/links daneben/unterhalb der Batterie kein Problem. Dann kann der User selbst bestimmen was er gern hätte. Diese Option wäre übrigens ganz hilfreich, da man ja auch Differenzwerte zwischen den Balkenwerten in der Grafik andrucken kann, was in diesem Fall eine Darstellung des SOC neben den Batterien als bessere Variante erscheinen lässt.
ZitatBalkendiagramm: Wie schon gesagt, ist das wegen der abwechselnden Anordnung (mal oben, mal unten) ebenfalls schwer zu erfassen.
Deine Anmerkung von weiter vorn habe ich noch auf dem Plan. graphicControl->scaleMode kann zur Zeit lin, log. Hinzu kommen könnte noch ein "staple". Vllt. hat jemand (Wzut?) schonmal Zeit und Lust sich diese Variante mal anzuschauen?
LG,
Heiko
Zitat von: DS_Starter am 25 Juni 2025, 09:12:48Vllt. hat jemand (Wzut?) schonmal Zeit und Lust sich diese Variante mal anzuschauen?
Kein Problem , sag mir was ich konkret tun soll. Im Moment versteh ich es nämlich nicht, auch was Peter mit "mal oben mal unten" meint. IMHO steht die Zahl immer oben am Ende das Balkens und der kleinere steht immer vor dem größeren.
Peter hatte die Idee, die beiden Balken quasi als "Stapel aufeinandergestellt" darzustellen, also z.B. im unteren Bereich immer den primären Balken, darüber immer den sekundären Balken mit ihren jeweiligen Werten und Farben. Dabei müsste man sich vermutlich noch um eine Normierung Gedanken machen damit die Höhe beider Anteile zusammen nicht grösser wird wenn man den größten Einzelwert = 100% annimmt.
Nur mal so ins unreine gesprochen ... bei der Umsetzung kommen dann vermutlich die Gedanken ....
Zitat von: Max_Meyer am 24 Juni 2025, 22:05:54Zitat von: DS_Starter am 24 Juni 2025, 19:27:39vermutlich habe ich es noch nicht wirklich verstanden worum es dabei eigentlich geht. Wenn es nur darum geht einen vorhandenen PV-Überschuß in der WP zu "verbrauchen" kann man doch einen Consumer entsprechen konfigurieren. Vllt. kannst du das Anliegen noch etwas anders formulieren.
Hallo Heiko,
du hast recht - ich habe das ziemlich oberflächlich beschrieben - was ich meine ist das eine WP mit Puffer im Prinzip die gleichen Steuersignale braucht wie eine Batterie die konstant geladen werden soll. Um zu verdeutlichen was ich gern erreichen will habe ich ein typisches Schaltspiel eines Heiztages rangehangen und skizziert was ich gern erreichen möchte. Die Idee kam mir bei der Diskussion zu den zusätzlichen Bat-Readings. Falls meine Gedanken abwegig sind und/oder eine Implementation viel Aufwand verursacht ist es auch kein Problem meine bestehende Logik mit vorhanden Signalen aus SF verfeinern - aber eben ohne KI-Unterstützung
Hallo Gerd,
bei Deiner WP kannst Du sicherlich noch einiges vorab optimieren, bevor Du extern eingreifst. Ich habe 13 Zyklen gezählt, wohingegen ich auf ca.6 Zyklen komme, auch wenn es sehr kalt ist und inklusive WW Bereitung.
1. Sperrzeiten z.B. für WW nutzen
2. Wenn Dein Wohnobjekt wirklich gut isoliert ist und somit die Verlustwäre gering, kannst Du es machen wie ich.
2.1 Tagesanhebung am Tag von 10:00-16:00 Uhr für die Heizung.
2.2 Nachtabsenkung von 16:00-10:00 Uhr
2.3 Die Heizung wird so gegen 18 Uhr abgeschaltet und verwendet somit von 16-18 Uhr noch den Puffer.
2.3.1 An nicht so kalten Tagen schalte ich die Heizung nachts komplett bis 10 Uhr ab
2.3.2 Ist es bitterlich kalt wird die Heizung bereits früher wieder aktiviert und bedient sich aus dem Speicher
Durch die Nachtabsenkung reicht der Speicher oft einige Zeit und wird nur moderat in der Nacht nachgeheizt.
Ab 10 Uhr gehts dann erst richtig los und die WP läuft über Stunden durch, was weniger Taktzyklen bedeutet.
Der PV-Modus wird nur verwendet, wenn die Prognose für den nächsten Tag schlecht ist und es heute PV-Überschuss gibt.
Dadurch wird die Heizung nochmals am Tag intensiever und das WW auf z.B. 60°C angehoben. Wichtig ist jedoch, dass dann
die WP am nächsten Tag mit weniger PV ebenfalls weniger läuft. Bei mir fällt dann zB das WW am nächsten Tag komplett weg.
Das würde bereits die PV Verwendung optimieren, ist jedoch sehr stark vom Energiebedarf Deines Hauses und dem WW Bedarf abhängig.
Mehr gerne als PN.
Ein ständiges aktivieren des PV-Modus geht zu lasten der WP (Kompressor), oder man erzeugt Wärme, die man gar nicht wirklich benötigt.
VG Christian
Zitat von: ch.eick am 25 Juni 2025, 13:13:48Der PV-Modus wird nur verwendet, wenn die Prognose für den nächsten Tag schlecht ist und es heute PV-Überschuss gibt.
Dadurch wird die Heizung nochmals am Tag intensiever und das WW auf z.B. 60°C angehoben. Wichtig ist jedoch, dass dann
die WP am nächsten Tag mit weniger PV ebenfalls weniger läuft. Bei mir fällt dann zB das WW am nächsten Tag komplett weg.
Das würde bereits die PV Verwendung optimieren, ist jedoch sehr stark vom Energiebedarf Deines Hauses und dem WW Bedarf abhängig.
Mehr gerne als PN.
Ein ständiges aktivieren des PV-Modus geht zu lasten der WP (Kompressor), oder man erzeugt Wärme, die man gar nicht wirklich benötigt.
Hallo Christian,
prinzipiell habe ich die Einstellungen bei mir sehr ähnlich - die Anlage ist (geringfügig) anders - z.B. mache ich das WW nicht mit der WP und die Dämmung ist nach WSVO 95... - Über Details können wir gerne auch anderswo fachsimpeln :) - ist hier out topic denke ich.
Aber ich wollte mit meiner Initiative auf etwas anderes abzielen - es geht mir primär gar nicht um eine Verringerung der Einschaltspiele der WP, sondern eine Erhöhung der Effizienz. Also wie ich das Maximum an Heizenergie aus der eingesetzten elektrischen Energie produzieren kann (erst einmal ohne PV einzukalkulieren). Im Prinzip gilt ja: je geringer die eingesetzte elektrische Energie ist, desto größer der COB - also die aus der EE erzielbare thermische Leistung - in den Grenzen die die WP erlaubt. (gibt für jede WP Effizienz-Kennlinien oder Tabellen oder Auslegetools) andersherum ausgedrückt wenn ich lange mit gleichmäßiger el. Energie fahre (die man berechnen muss) dann sollte ich nach 8,10,....x h genug Heizenergie produziert haben um über den Tag zu kommen. Theoretisch!!soll das effizienter sein als das bisherige Schaltspiel der WP - je nach Rechnung um 10-20%. Du hat sicher Recht das man Teile davon auch in den Parametern der WP hinterlegen könnte (Heiz- , Mischerkennlinie. Puffertemperatur etc.) das geht nur nur schlecht dynamisch - heute gebe ich nur das PV-Angebot (wattgenau bis zur Obergrenze) an die WP weiter und bin damit gut gefahren so hab ich dafür zuerst in diese Richtung gedacht.
Vielleicht hab ich mich auch verrannt aber generisch gesehen ist die WP wie ein Inverter und der Puffer die dazugehörige Batterie. die notwendige Heizenergie für den z.B. Tag ließe sich ermitteln und durch die Lauf-h und den erwarteten COP teilen und die WP damit füttern. Es wird nicht unnötig thermische Energie erzeugt da der Puffer einen Verlust von 1K/d hat - (nachgemessen) und der Mischer nur die notwendige Wärme entnimmt.
So zumindest die Idee
Gruß Gerd
Guten Abend Gemeinde,
ich habe eine kurze Zwischenfrage.
Warum wird bei der Klimaanlage (ganz rechts) kein Stromfluss dargestellt?
Eingerichtet ist der consumer wie alle andere auch.
VG,
Heiko
Bildschirmfoto vom 2025-06-25 21-20-46.png
Edit: Konnte mir selbst helfen. Das Device (Shelly EM) war auf "off". Nach Umschalten auf "on" kommt die Grafik.
Bekomme ich den Schalter "Ein/Aus" Schalter da irgendwie weg? Bei der Wärmepump (Shelly Pro3EM) erscheint der garnicht. Die setsates habe ich im Pana device schon gelöscht.
Bildschirmfoto vom 2025-06-25 21-30-18.png
Nabend zusammen,
@Heiko:
ZitatBekomme ich den Schalter "Ein/Aus" Schalter da irgendwie weg?
Ja, mit einem Trick (der eigentlich normalerweise einen Fehler darstellt):
In dem Consumer setzt du weder "on" noch "off" und setzt swstate auf einen on:off-Regex der weder für ein noch aus gültig ist d.h. weder ein noch aus-Zustand erkannt wird, z.B.:
SolCastDummy6 icon=sani_buffer_electric_heater_side type=noSchedule power=1000 swstate=state:bla:bluff
LG,
Heiko
Danke, funktioniert :)
Die Version 1.53.0 ist eingecheckt und ab 29.06. im Update.
In dieser Version ist folgendes umgesetzt:
- die Beschriftung an den Batterien kann wahlweise mit dem Attr setupBatteryDevXX->label angewendet werden
label Wird die Batterie in der Balkengrafik mit dem Schlüssel 'show' angezeigt, kann das Symbol mit dem
aktuellen SOC-Wert (%) beschriftet werden.
none - keine Beschriftung (default)
below - Beschriftung unterhalb des Batteriesymbols
beside - Beschriftung neben dem Batteriesymbol
- es gibt das neue Reading Battery_ChargeUnrestricted_XX als Ersatz für das Reading Battery_ChargeRecommended_XX.
Beide Reading werden vorerst beide parallel bereitgestellt damit jeder genügend Zeit hat seine
eigenen Skripte und Steuerungen auf das neu Reading umzustellen (mich eingeschlossen ;) ).
Ich werde mit genügend Vorlauf ankündigen bevor das alte Reading Battery_ChargeRecommended_XX entfernt wird.
- Das Attribut graphicShowDiff wurde durch graphicControl->showDiff ersetzt
- Weil die globalen Attribute latitude, longitude und altitude so wichtig sind, prüft SF ständig deren
Vorhandensein und teilt dem User einen fehlerhaften Zustand sofort über das Messagesystem mit.
Man wird also unmittelbar darauf aufmerksam gemacht. Man muß natürlich auch mal die Post öffnen und lesen. ;)
Im Anhang seht ihr wie sich das Ganze darstellt.
- Es gibt jetzt auch die Möglichkeit, die Consumer-Schaltersymbole im Paneel auszublenden. Dazu gibt es im consumer-Attribut
eine Werte-Erweiterung des Key noshow -> 9 - das Schaltelement des Verbrauchers wird in der Verbraucherlegende ausgeblendet.
Die Werte sind jetzt auch kombinierbar, z.B. noshow=39.
- Hinzugekommen ist die Möglichkeit, auf eine Abregelung der PV-Anlage zu reagieren. Dazu gibt es die
Eingabemöglichkeit einer Device:Reading Kombination (z.B. ein Readingwert des Victron SolarChargers)
via dem neuen plantControl->reductionState. Die Grafik ist um einen Ampel-Anzeigewert
ergänzt (Screenshot).
- Integration Prüfung plantControl->reductionState und plantControl->feedinPowerLimit im configCheck
- weitere kleinere Changes und Fixes
Ich hoffe damit wieder ein Puzzlesteinchen für mehr Zuverlässigkeit gesetzt zu haben.
Nach Download wie üblich restarten.
LG,
Heiko
Hallo Gerd,
wie versprochen habe ich mir deine Sache nochmal durch den Kopf gehen lassen. Ich muß gestehen, da ich keine WP habe, sind für mich manche Dinge nur wage nachvollziehbar. Aber ungeachtet dessen bin ich mir sehr sicher, dass wenn wir eine spezifische Unterstützung für WP einbauen wollen, es nur über einen spezifischen Consumer WP gemacht werden kann der dann mehr Parameter und spezifische Logik eingebaut hat ... so ähnlich wie ich es für das Batteriesystem gemacht habe. D.h. auch dafür würden dann spezifische Steuerungs- und Signalreadings bereitgestellt werden.
Die Schwierigkeit für mich besteht darin, dass ich eben keine WP habe um meine entwickelten Logiken im eigenen Haus zu überprüpfen, im Gegensatz zum Batteriesystem.
Ich gebe aber zu, dass es ein reizvolles und vor allem sicher auch ein Thema mit viel Optimierungspotential wäre. Momentan muß ich da leider passen fürchte ich. :-\
LG,
Heiko
Zitat von: Max_Meyer am 25 Juni 2025, 17:09:23Aber ich wollte mit meiner Initiative auf etwas anderes abzielen - es geht mir primär gar nicht um eine Verringerung der Einschaltspiele der WP, sondern eine Erhöhung der Effizienz. Also wie ich das Maximum an Heizenergie aus der eingesetzten elektrischen Energie produzieren kann (erst einmal ohne PV einzukalkulieren). Im Prinzip gilt ja: je geringer die eingesetzte elektrische Energie ist, desto größer der COB - also die aus der EE erzielbare thermische Leistung - in den Grenzen die die WP erlaubt. (gibt für jede WP Effizienz-Kennlinien oder Tabellen oder Auslegetools) andersherum ausgedrückt wenn ich lange mit gleichmäßiger el. Energie fahre (die man berechnen muss) dann sollte ich nach 8,10,....x h genug Heizenergie produziert haben um über den Tag zu kommen. Theoretisch!!soll das effizienter sein als das bisherige Schaltspiel der WP - je nach Rechnung um 10-20%. Du hat sicher Recht das man Teile davon auch in den Parametern der WP hinterlegen könnte (Heiz- , Mischerkennlinie. Puffertemperatur etc.) das geht nur nur schlecht dynamisch - heute gebe ich nur das PV-Angebot (wattgenau bis zur Obergrenze) an die WP weiter und bin damit gut gefahren so hab ich dafür zuerst in diese Richtung gedacht.
Ich habe meine Wärmepumpe so eingestellt, dass die Tagestemperatur etwas höher als meine eigentliche Wunschtemperatur ist & die Nachttemperatur dafür etwas niedriger. Zusätzlich ist die Zeit für den Tagbetrieb auf 0930-1500 Uhr eingestellt.
In Kombination mit einer großen Speichermasse & einem sehr gut thermisch isolierten Gebäude läuft die Wärmepumpe damit - von einzelnen Ausnahmen abgesehen - in der finsteren Jahreszeit nur noch tagsüber. Da meine Wärmepumpe nicht modulieren kann, hole ich damit in erster Näherung bereits das Maximum an möglichem Eigenstromverbrauch heraus. Zusätzlich sind die Lufttemperaturen tagsüber tendenziell höher, sodass sich das auch positiv auf den COP auswirken müsste.
Während der Übergangszeit mit geringem Heizbedarf kann es mal passieren, dass während einer wolkigen Phase geheizt wird, obwohl später ev. noch ein Sonnenfenster käme. Diese Unschärfe habe ich bisher nicht abgebildet.
Warmwasserbereitung über die Wärmepumpe habe ich über SF durch Betriebsartenumschaltung realisiert.
Zitat von: Prof. Dr. Peter Henning am 25 Juni 2025, 01:56:03Wettersymbole nicht ausreichend voneinander unterscheidbar. Unterschiedliche Farbgebung Wolken/Sonne könnte das verbessern
@Heiko, dazu hatte ich gestern noch eine Idee : Man könnte doch die Wettericons in drei Gruppen einteilen ->
a. Icons mit guter Ertragsprognose -> Sonnig / wenig Wolken , etc.
b. Icons für schlechtere Prognosen -> Regen , viele Wolken , etc.
c. die ganzen Nacht Icons , bzw. alles was nicht a. oder b. ist.
Bei der Ausgabe wird die Gruppe a. mit 100% Hellogikeit dargestellt. Gruppe b. um ein paar Prozent reduziert und Gruppe c. nochmal etwas dunkler. Das ist zwar dann immer noch keine unterschiedliche Farbgebung, aber eine Lösung die mit den heutigen Bordmitteln relativ leicht machbar wäre.
Moin Wzut,
das wäre zwar möglich, aber ich glaube das ist nicht das was unsere User als Fortschritt sehen würden, mich eingeschlossen ;).
Vllt. macht es Sinn, dass wir bei OpenAutomation schauen, ob es einen kompletten Satz gut passender SVG-Wettericons gibt und die in FHEM laden? Die sind doch frei verwendbar und könnten uns so mit relativ wenig Aufwand einen schönen Satz zusammenstellen, oder?
Nur mal als Idee ...
LG,
Heiko
ZitatBekomme ich den Schalter "Ein/Aus" Schalter da irgendwie weg?
Es gibt jetzt auch die reguläre Möglichkeit, die Schaltersymbole auszublenden.
Dazu gibt es im consumer-Attribut eine Werte-Erweiterung des Key noshow -> 9 - das Schaltelement des Verbrauchers wird in der Verbraucherlegende ausgeblendet. Die Werte sind jetzt auch kombinierbar, z.B. noshow=39.
Liegt im contrib.
Zitat von: DS_Starter am 25 Juni 2025, 22:32:22Die Schwierigkeit für mich besteht darin, dass ich eben keine WP habe um meine entwickelten Logiken im eigenen Haus zu überprüpfen, im Gegensatz zum Batteriesystem.
Ich gebe aber zu, dass es ein reizvolles und vor allem sicher auch ein Thema mit viel Optimierungspotential wäre. Momentan muß ich da leider passen fürchte ich
Hallo Heiko,
das ist OK - kein Problem - es ist so schon aller Ehren wert was du hier ablieferst!
Und du hast Recht da muss man sich langsam annähern - schließlich soll es doch warm bleiben im Winter :). Ich wollte diese Optimierung eigentlich diese Heizsaison angehen falls sich die Prios nicht verschieben ;) - erstmal mit Bordmitteln in der WP (wie ch.eick geschrieben) und zusätzlich über aus der Vergangenheit abgeleitete Vorgaben - kann die WP ziemlich umfangreich fremd steuern - bei Bedarf - falls das erfolgreich wird, können wir ja noch mal reden - bei Interesse.
Aber eines würde ich gern noch noch mal diskutieren - das ist der saisonale Einfluss der WP - wenn ich mir den Elektroenergiebedarf im Haushalt übers das Jahr ansehe dann liegt der Verbrauch bei ca. 12.000 kWh davon ca. 3000 kWh sind die WP --> während (fast) alle anderen Verbraucher kontinuierlich, über das ganze Jahr verteilt, konsumieren - ist die WP (im wesentlichen) nur reichlich 3 Monate aktiv - verbraucht in der Zeit aber 25% der Jahresenergiemenge - hab mal so einen BSP-Tag im Winter mit reingehangen - trotz E-Car-laden dominiert der WP-Bedarf. So wie ich das verstehe verfälscht das dann die Prognose für die anderen Verbraucher?
Meine Frage wäre also ist es möglich/sinnvoll consumer als saisonal zu kennzeichnen - oder merkt das KI sowieso?
Gruß Gerd
Zitat von: TheTrumpeter am 26 Juni 2025, 07:44:21Ich habe meine Wärmepumpe so eingestellt, dass die Tagestemperatur etwas höher als meine eigentliche Wunschtemperatur ist & die Nachttemperatur dafür etwas niedriger. Zusätzlich ist die Zeit für den Tagbetrieb auf 0930-1500 Uhr eingestellt.
In Kombination mit einer großen Speichermasse & einem sehr gut thermisch isolierten Gebäude läuft die Wärmepumpe damit - von einzelnen Ausnahmen abgesehen - in der finsteren Jahreszeit nur noch tagsüber. Da meine Wärmepumpe nicht modulieren kann, hole ich damit in erster Näherung bereits das Maximum an möglichem Eigenstromverbrauch heraus. Zusätzlich sind die Lufttemperaturen tagsüber tendenziell höher, sodass sich das auch positiv auf den COP auswirken müsste.
Während der Übergangszeit mit geringem Heizbedarf kann es mal passieren, dass während einer wolkigen Phase geheizt wird, obwohl später ev. noch ein Sonnenfenster käme. Diese Unschärfe habe ich bisher nicht abgebildet.
Hallo
Auch wenn bei mir die Situation leicht anders ist - ich hab eine WP mit Erdsonde und so immer (fast) konstante Zulauftemperaturen, die Dämmung ist WSVO 95, WW macht nicht die WP.. habe ich das ähnlich - über Zeitprogramme in der WP eingestellt. An Tagen ohne Sonne wird so nur die Wärme erzeugt die ich benötige (denke ich zumindest :) ) Zusätzlich nutze ich den Puffer (mit Offset) wenn es einen Solarüberschuss gibt. Der Plan jetzt ist das Verhalten der WP so zu strecken das ein ähnliches Schaltspiel herauskommt wie du es beschreibst nur eben angepasst auf die höhere Heizleistung pro m²
Gruß Gerd
Hallo Gerd,
ZitatAber eines würde ich gern noch noch mal diskutieren - das ist der saisonale Einfluss der WP ... verbraucht in der Zeit aber 25% der Jahresenergiemenge - hab mal so einen BSP-Tag im Winter mit reingehangen - trotz E-Car-laden dominiert der WP-Bedarf. So wie ich das verstehe verfälscht das dann die Prognose für die anderen Verbraucher? Meine Frage wäre also ist es möglich/sinnvoll consumer als saisonal zu kennzeichnen - oder merkt das KI sowieso?
Ja, das ist etwas problematisch. Zur Zeit gibt es für die Verbrauchsprognose keine KI-Unterstützung. Das will ich erst noch implementieren. Du siehst auch mit "get ... valDecTree aiRawData" dass es in den Daten noch keine separierten Felder von Verbrauchern enthalten sind.
Momentan würde ich dir raten einzustellen:
- plantControl->consForecastIdentWeekdays=1
- plantControl->consForecastLastDays=4 (oder kleiner)
- im WP-consumer: exconfc=1 (siehe auch im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_die_Verbrauchsprognose_erstellt?))
Dadurch werden nur die zeitnah in der pvHistory gespeicherten Daten genutzt und das Modul kann die Anteile der WP einkalkulieren bzw. würden sie jetzt im Sommer nicht zum Tragen kommen.
Wir werden sehen was meine KI-Implementierung leisten kann (wenn ich dazu komme...).
LG,
Heiko
Zitat von: DS_Starter am 26 Juni 2025, 21:28:06Momentan würde ich dir raten einzustellen:
- plantControl->consForecastIdentWeekdays=1
- plantControl->consForecastLastDays=4 (oder kleiner)
- im WP-consumer: exconfc=1
Hallo Heiko
Danke für die schnelle Antwort - ja das ist ein guter Hinweis - die Einstellungen könnten ja auch mit attrKeyVal dynamisiert werden - so dass in der Heizsaison andere Einstellungen gelten als außerhalb. Zumindest bei mir ist das notwendig - da sich die WP aus unterschiedlichen Stromkreisen bedient (Steuerung und Last) hab ich die Readings (wie bei allen Consumern) auf MQTT-Devices zusammengeführt und SF als einen Consumer übergeben. Die Steuerung (Pumpen, Ventile, controlboard ... --> ca. 300 kWh/a) ist ja auch außerhalb der Heizsaison aktiv (z.B. Kühlung)
Gruß Gerd
Moin,
@Wzut, ich habe über deinen Vorschlag nochmal nachgedacht. Im Modul haben wir den Bewölkungsgrad von 0..100. Wenn wir hier mit pahcolor ansetzen und eine dynamische Farbkurve für den Tag von z.B. von Grau über Orange bis Sonnen-Gelb implementieren und für die Nacht z.B. von Grau bis hellerem Blau (also Blautöne für die Nacht), dann gäbe es im Gesamtbild wahrscheinlich für den Betrachter eine recht gute visuelle Beziehung zwischen Tag/Nacht und Bewölkung. Stelle ich mir zumindest so vor.
Das Setup im Modul wäre dann auch gut machbar. Die Attr graphicWeatherColor und graphicWeatherColorNight könnte ich in graphicControl als einen Schlüssel überführen, in dem man dann feste Farben für Tag/Nacht oder eben die dynamischen Farben wie beschrieben festlegen kann.
Kleiner Wermutstropfen ... die jetzt verfügbare Farbauswahl über den colorpicker geht dann nicht mehr weil man den Farbwert dann eingeben muß.
Was denkst du?
LG,
Heiko
Das müsste man mal live sehen :) Keine Ahnung wie "bunt" das wird.
(BTW : wo "versteckt" sich der Bewölkungsgrad ? )
Das mit dem Colorpicker würde mich persönlich nicht stören, wenn ein Hex Farbwert benötigt wird gibt es genug andere Colorpicker um sich den passenden Wert zu besorgen.
ZitatBTW : wo "versteckt" sich der Bewölkungsgrad ?
Du kannst dir den Bewölkungsgrad "wcc" jederzeit aus der pvHistory (Daten vor aktueller Zeit) und nextHours (ab aktueller Zeit) holen.
Beispiele findest du in den angegebenen Subroutinen:
$hfcg->{0}{wcc} = HistoryVal ($hash, $hfcg->{0}{day_str}, $hfcg->{0}{time_str}, 'wcc', '-'); # sub _beamGraphicFirstHour
$hfcg->{$i}{wcc} = NexthoursVal ($name, 'NextHour'.$nh, 'wcc', '-'); # _beamGraphicRemainingHours
Ja hast Recht, wie das in der Realität wirkt, können wir tatsächlich erst am Beispiel beurteilen.
Hallo zusammen,
ich habe leider ein Problem mit dem Solarcast-Modul und finde den Fehler nicht...
Es gibt Zeiten, da wird die Übergabeleistung ans Haus negativ, dies wird mir natürlich direkt im Log mit einem Fehler quittiert:
2025.06.25 05:59:53 3: SolarForecast - WARNING - The calculated Energy consumption of the house is negative. This appears to be an error and is not saved. Check Readings _PVreal, _GridFeedIn, _GridConsumption, _BatIn_XX, _BatOut_XX of hour >06<
Mein Modul ist wie folgt aufgebaut:
define SolarForecast SolarForecast
attr SolarForecast ctrlLanguage DE
attr SolarForecast event-on-change-reading .*
attr SolarForecast room KG->PV-Anlage,Wetter
attr SolarForecast setupBatteryDev01 NR_Batterie pin=PIn:W pout=POut:W cap=30000 intotal=PIn_Gesamt:kWh outtotal=POut_Gesamt:kWh charge=SOC asynchron=1 show=1:top icon=measure_battery_50@#262626:@yellow:measure_battery_100@red
attr SolarForecast setupInverterDev01 NR_Fronius pvOut=PVOut:W etotal=PVOutTotal:kWh capacity=10000 icon=inverter@red:solar strings=Dach1,Dach2 asynchron=1
attr SolarForecast setupInverterDev02 NR_Victron_gesamt pvOut=PVOut:W etotal=PVOutTotal:kWh capacity=15000 icon=inverter@blue:solar strings=Mauer1, Mauer2, Mauer3, Mauer4, Mauer5, Mauer6, Carport1, Carport2, Carport3, Carport4, Carport5, Carport6 asynchron=1
attr SolarForecast setupInverterStrings Dach1,Dach2,Mauer1,Mauer2,Mauer3,Mauer4,Mauer5,Mauer6,Carport1,Carport2,Carport3,Carport4,Carport5,Carport6
attr SolarForecast setupMeterDev NR_Smartmeter gcon=GridLoadPos:W contotal=GridLoadTotal_bought gfeedin=GridLoadNeg:W feedtotal=GridLoadTotal_sold conprice=35.90:ct/kWh feedprice=0.083:ct/kWh asynchron=1
attr SolarForecast setupRadiationAPI OpenMeteoDWD_D2-API
attr SolarForecast setupStringAzimuth Dach1=48 Dach2=48 Mauer1=48 Mauer2=48 Mauer3=48 Mauer4=48 Mauer5=48 Mauer6=48 Carport1=-40 Carport2=-40 Carport3=-40 Carport4=-40 Carport5=-40 Carport6=-40
attr SolarForecast setupStringDeclination Dach1=40 Dach2=40 Mauer1=90 Mauer2=90 Mauer3=90 Mauer4=90 Mauer5=90 Mauer6=90 Carport1=0 Carport2=0 Carport3=0 Carport4=0 Carport5=0 Carport6=0
attr SolarForecast setupStringPeak Dach1=3.735 Dach2=3.735 Mauer1=1.245 Mauer2=1.245 Mauer3=1.245 Mauer4=1.245 Mauer5=1.245 Mauer6=1.660 Carport1=1.245 Carport2=1.660 Carport3=1.660 Carport4=1.660 Carport5=1.660 Carport6=1.660
attr SolarForecast setupWeatherDev1 OpenMeteoDWD_D2-API
# FUUID 6855a29f-f33f-1b3f-f383-35aed6f06580e796
# FVERSION 76_SolarForecast.pm:v1.52.18-s30065/2025-06-23
# LCACHEFILE last write time: 13:23:19 whole Operating Memory
# MODE Automatic / Event-controlled - next planned Cycletime: 13:26:40
# MODEL OpenMeteoDWDD2API
# NAME SolarForecast
# NOTIFYDEV NR_Smartmeter,NR_Batterie,NR_Fronius,NR_Victron_gesamt
# NR 869
# NTFY_ORDER 50-SolarForecast
# STATE updated
# TYPE SolarForecast
# WEATHERMODEL OpenMeteoDWDD2API
# eventCount 36520
# HELPER:
# FW WEB
# PACKAGE FHEM::SolarForecast
# S10DONE 1
# SPGDETAIL
# SPGDEV SolarForecast
# SPGROOM
# VERSION 1.52.18
# VERSION_API unused
# VERSION_CTZ 1.0.0
# VERSION_ErrCodes 1.3.9
# VERSION_SMUtils 1.28.3
# GMFRUNNING:
# abortFn FHEM::SolarForecast::_abortGetMessageFile
# bc_pid 5917
# finishFn FHEM::SolarForecast::_processMessageFile
# fn FHEM::SolarForecast::_retrieveMessageFile
# loglevel 3
# pid DEAD:2070847
# telnet telnetPort_127.0.0.1_37134
# terminated 1
# timeout 30
# abortArg:
# arg:
# block 1
# name SolarForecast
# tsnext 1751027697.94142
# OLDREADINGS:
# READINGS:
# 2025-06-27 13:25:55 Battery_ChargeRecommended_01 1
# 2025-06-27 13:25:55 Current_AutarkyRate 100 %
# 2025-06-27 13:25:55 Current_BatCharge_01 95 %
# 2025-06-27 13:25:55 Current_Consumption 277 W
# 2025-06-27 13:25:55 Current_GridConsumption 0 W
# 2025-06-27 13:25:55 Current_GridFeedIn 1275 W
# 2025-06-27 13:25:55 Current_PV 1520 W
# 2025-06-27 13:25:55 Current_PowerBatIn_01 0 W
# 2025-06-27 13:25:55 Current_PowerBatOut_01 32 W
# 2025-06-27 13:25:55 Current_SelfConsumption 245 W
# 2025-06-27 13:25:55 Current_SelfConsumptionRate 16 %
# 2025-06-27 13:25:55 Current_Surplus 1243 W
# 2025-06-27 13:00:00 LastHourGridconsumptionReal 0 Wh
# 2025-06-27 13:00:00 LastHourPVforecast 3238 Wh
# 2025-06-27 13:00:00 LastHourPVreal 3400 Wh
# 2025-06-27 13:25:55 NextHours_Sum01_PVforecast 2589 Wh
# 2025-06-27 13:25:55 NextHours_Sum02_PVforecast 4571 Wh
# 2025-06-27 13:25:55 NextHours_Sum03_PVforecast 6173 Wh
# 2025-06-27 13:25:55 NextHours_Sum04_ConsumptionForecast 22785 Wh
# 2025-06-27 13:25:55 NextHours_Sum04_PVforecast 9676 Wh
# 2025-06-27 13:25:55 RestOfDayConsumptionForecast 30844 Wh
# 2025-06-27 13:25:55 RestOfDayPVforecast 19330 Wh
# 2025-06-27 00:59:58 Today_Hour01_BatIn_01 200 Wh
# 2025-06-27 00:59:58 Today_Hour01_BatOut_01 0 Wh
# 2025-06-27 00:59:58 Today_Hour01_GridConsumption 0 Wh
# 2025-06-27 00:59:58 Today_Hour01_GridFeedIn 0 Wh
# 2025-06-27 00:59:58 Today_Hour01_PVreal 0 Wh
# 2025-06-27 01:59:58 Today_Hour02_BatIn_01 100 Wh
# 2025-06-27 01:59:58 Today_Hour02_BatOut_01 0 Wh
# 2025-06-27 01:59:58 Today_Hour02_GridConsumption 0 Wh
# 2025-06-27 01:59:58 Today_Hour02_GridFeedIn 0 Wh
# 2025-06-27 01:59:58 Today_Hour02_PVreal 0 Wh
# 2025-06-27 02:59:57 Today_Hour03_BatIn_01 300 Wh
# 2025-06-27 02:59:57 Today_Hour03_BatOut_01 0 Wh
# 2025-06-27 02:59:57 Today_Hour03_GridConsumption 0 Wh
# 2025-06-27 02:59:57 Today_Hour03_GridFeedIn 0 Wh
# 2025-06-27 02:59:57 Today_Hour03_PVreal 0 Wh
# 2025-06-27 03:59:58 Today_Hour04_BatIn_01 200 Wh
# 2025-06-27 03:59:58 Today_Hour04_BatOut_01 0 Wh
# 2025-06-27 03:59:58 Today_Hour04_GridConsumption 0 Wh
# 2025-06-27 03:59:58 Today_Hour04_GridFeedIn 0 Wh
# 2025-06-27 03:59:58 Today_Hour04_PVreal 0 Wh
# 2025-06-27 04:59:56 Today_Hour05_BatIn_01 200 Wh
# 2025-06-27 04:59:56 Today_Hour05_BatOut_01 0 Wh
# 2025-06-27 04:59:56 Today_Hour05_GridConsumption 0 Wh
# 2025-06-27 04:59:56 Today_Hour05_GridFeedIn 0 Wh
# 2025-06-27 04:59:56 Today_Hour05_PVreal 0 Wh
# 2025-06-27 05:59:59 Today_Hour06_BatIn_01 800 Wh
# 2025-06-27 05:59:59 Today_Hour06_BatOut_01 0 Wh
# 2025-06-27 05:59:59 Today_Hour06_GridConsumption 0 Wh
# 2025-06-27 05:59:59 Today_Hour06_GridFeedIn 0 Wh
# 2025-06-27 05:59:59 Today_Hour06_PVforecast 30 Wh
# 2025-06-27 05:59:59 Today_Hour06_PVreal 50 Wh
# 2025-06-27 06:59:57 Today_Hour07_BatIn_01 0 Wh
# 2025-06-27 06:59:57 Today_Hour07_BatOut_01 200 Wh
# 2025-06-27 06:59:57 Today_Hour07_GridConsumption 0 Wh
# 2025-06-27 06:59:57 Today_Hour07_GridFeedIn 0 Wh
# 2025-06-27 06:59:57 Today_Hour07_PVforecast 552 Wh
# 2025-06-27 06:59:57 Today_Hour07_PVreal 750 Wh
# 2025-06-27 07:59:59 Today_Hour08_BatIn_01 0 Wh
# 2025-06-27 07:59:59 Today_Hour08_BatOut_01 500 Wh
# 2025-06-27 07:59:59 Today_Hour08_GridConsumption 0 Wh
# 2025-06-27 07:59:59 Today_Hour08_GridFeedIn 0 Wh
# 2025-06-27 07:59:59 Today_Hour08_PVforecast 1660 Wh
# 2025-06-27 07:59:59 Today_Hour08_PVreal 1700 Wh
# 2025-06-27 08:59:57 Today_Hour09_BatIn_01 0 Wh
# 2025-06-27 08:59:57 Today_Hour09_BatOut_01 500 Wh
# 2025-06-27 08:59:57 Today_Hour09_GridConsumption 0 Wh
# 2025-06-27 08:59:57 Today_Hour09_GridFeedIn 0 Wh
# 2025-06-27 08:59:57 Today_Hour09_PVforecast 540 Wh
# 2025-06-27 08:59:57 Today_Hour09_PVreal 1689 Wh
# 2025-06-27 09:59:59 Today_Hour10_BatIn_01 0 Wh
# 2025-06-27 09:59:59 Today_Hour10_BatOut_01 700 Wh
# 2025-06-27 09:59:59 Today_Hour10_GridConsumption 0 Wh
# 2025-06-27 09:59:59 Today_Hour10_GridFeedIn 0 Wh
# 2025-06-27 09:59:59 Today_Hour10_PVforecast 1090 Wh
# 2025-06-27 09:59:59 Today_Hour10_PVreal 1710 Wh
# 2025-06-27 10:59:59 Today_Hour11_BatIn_01 100 Wh
# 2025-06-27 10:59:59 Today_Hour11_BatOut_01 900 Wh
# 2025-06-27 10:59:59 Today_Hour11_GridConsumption 0 Wh
# 2025-06-27 10:59:59 Today_Hour11_GridFeedIn 3 Wh
# 2025-06-27 10:59:59 Today_Hour11_PVforecast 1373 Wh
# 2025-06-27 10:59:59 Today_Hour11_PVreal 5129 Wh
# 2025-06-27 11:59:58 Today_Hour12_BatIn_01 200 Wh
# 2025-06-27 11:59:58 Today_Hour12_BatOut_01 200 Wh
# 2025-06-27 11:59:58 Today_Hour12_GridConsumption 0 Wh
# 2025-06-27 11:59:58 Today_Hour12_GridFeedIn 8 Wh
# 2025-06-27 11:59:58 Today_Hour12_PVforecast 3117 Wh
# 2025-06-27 11:59:58 Today_Hour12_PVreal 9240 Wh
# 2025-06-27 12:59:56 Today_Hour13_BatIn_01 0 Wh
# 2025-06-27 12:59:56 Today_Hour13_BatOut_01 0 Wh
# 2025-06-27 12:59:56 Today_Hour13_GridConsumption 0 Wh
# 2025-06-27 12:59:56 Today_Hour13_GridFeedIn 3 Wh
# 2025-06-27 12:59:56 Today_Hour13_PVforecast 3238 Wh
# 2025-06-27 12:59:56 Today_Hour13_PVreal 3400 Wh
# 2025-06-27 13:25:55 Today_Hour14_BatIn_01 0 Wh
# 2025-06-27 13:25:55 Today_Hour14_BatOut_01 0 Wh
# 2025-06-27 13:25:55 Today_Hour14_GridConsumption 0 Wh
# 2025-06-27 13:25:55 Today_Hour14_GridFeedIn 1 Wh
# 2025-06-27 13:25:55 Today_Hour14_PVforecast 2301 Wh
# 2025-06-27 13:25:55 Today_Hour14_PVreal 1169 Wh
# 2025-06-27 13:25:55 Today_Hour15_PVforecast 2966 Wh
# 2025-06-27 13:25:55 Today_Hour16_PVforecast 695 Wh
# 2025-06-27 13:25:55 Today_Hour17_PVforecast 2788 Wh
# 2025-06-27 13:25:55 Today_Hour18_PVforecast 4438 Wh
# 2025-06-27 13:25:55 Today_Hour19_PVforecast 4886 Wh
# 2025-06-27 13:25:55 Today_Hour20_PVforecast 1530 Wh
# 2025-06-27 13:25:55 Today_Hour21_PVforecast 620 Wh
# 2025-06-27 13:25:55 Today_Hour22_PVforecast 104 Wh
# 2025-06-27 13:25:55 Today_MaxPVforecast 4886 Wh
# 2025-06-27 13:25:55 Today_MaxPVforecastTime 2025-06-27 18:00:00
# 2025-06-27 13:25:55 Today_PVforecast 31928 Wh
# 2025-06-27 13:25:55 Today_PVreal 24837 Wh
# 2025-06-27 13:25:55 Today_SunRise 05:13
# 2025-06-27 13:25:55 Today_SunSet 21:46
# 2025-06-27 13:25:55 Tomorrow_ConsumptionForecast 67823 Wh
# 2025-06-27 13:25:55 Tomorrow_PVforecast 56035 Wh
# 2025-06-27 13:25:55 Tomorrow_SunRise 05:13
# 2025-06-27 13:25:55 Tomorrow_SunSet 21:46
# 2025-06-27 13:25:30 nextCycletime 13:26:40
# 2025-06-27 13:19:43 nextRadiationAPICall nach 27.06.2025 13:34:43
# 2025-06-27 06:00:04 pvCorrectionFactor_06 1.15 (automatic - old factor: 0.45, Sun Alt range: 0, Cloud range: 100, Days in range: 2)
# 2025-06-27 07:00:00 pvCorrectionFactor_07 1.25 (automatic - old factor: 1.10, Sun Alt range: 10, Cloud range: 100, Days in range: 2)
# 2025-06-27 08:00:02 pvCorrectionFactor_08 1.32 (automatic - old factor: 1.57, AI result used, Sun Alt range: 20, Cloud range: 100, Days in range: 2)
# 2025-06-27 09:00:03 pvCorrectionFactor_09 1.75 (automatic - old factor: 1.00, Sun Alt range: 25, Cloud range: 100, Days in range: 1)
# 2025-06-27 10:00:04 pvCorrectionFactor_10 1.57 (automatic - old factor: 1.00, Sun Alt range: 35, Cloud range: 100, Days in range: 1)
# 2025-06-27 11:00:01 pvCorrectionFactor_11 1.75 (automatic - old factor: 1.00, Sun Alt range: 45, Cloud range: 100, Days in range: 1)
# 2025-06-27 12:00:01 pvCorrectionFactor_12 1.75 (automatic - old factor: 1.00, Sun Alt range: 55, Cloud range: 95, Days in range: 1)
# 2025-06-27 13:00:00 pvCorrectionFactor_13 1.05 (automatic - old factor: 1.00, Sun Alt range: 60, Cloud range: 95, Days in range: 1)
# 2025-06-27 13:25:55 pvCorrectionFactor_Auto on_complex_ai
# 2025-06-27 13:25:56 state updated
Gemäß Anleitung sind alle übergebenen Werte numerisch und positiv.
Ein Hinweis zu meiner Installation:
Ich betreibe ein Kombinations-System aus Victron und Fronius. Dazu gehören 4 Laderegler und 4 Wechselrichter. Somit müsste ich theoretisch 8 Attribute vergeben. Ich habe das nun auf 2 beschränkt: Victron gesamt (4 Laderegler, 3 Wechselrichter) und Fronius (1 Wechselrichter).
Kann mir jemand sagen, wo der Fehler zu suchen ist?
Vielen Dank für die Unterstützung und euch ein schönes Wochenende!
Marvin
Hallo Marvin,
ich habe bei mir bei allen datenliefernden Quellen (Inverter, Batt, Meter), wenn technisch verantwortbar, die minimal mögliche Intervallzeiten gesetzt. Im SolarForecast Modul habe ich das Attribut "plantControl", dort dann das "cycleInterval" auf 10 Sekunden gesetzt und schon sah alles besser aus.
Viele Grüße!
Peter
Hallo Peter,
danke für die Rückmeldung. Habe ich ebenfalls umgesetzt und werde es mal testen.
VG Marvin
Nach meinem Verständnis sollte der Zyklus für das Sammeln (von den datenliefernden FHEM-Modulen) möglichst < oder = vom dem SF-Zyklus Aktualisierungszyklus liegen.
Von Vorteil ist auch das dieses "aktuelle Daten-Sammeln" von einem Wert (EM-Meter am Netzübergabepunkt) angestoßen und dadurch dann erst alle aktuell bekannten Reading-Daten (die maßgeblich SF-relevant sind) dann "abgeholt" werden.
Aber egal wie - leichte Überschneidungen lassen sich auch bei mir nicht ganz ausschließen....
(Mein SF-Invtervall beträgt 15 s ==>>> die meisten anderen Module liefern im gleichen Intervall vom 15 s)
So bin ich bislang von diesen Meldungen "verschont" geblieben.
Zitat von: Max_Meyer am 26 Juni 2025, 20:56:16Jahresenergiemenge - hab mal so einen BSP-Tag im Winter mit reingehangen - trotz E-Car-laden dominiert der WP-Bedarf.
Hallo Gerd,
Könntest Du mir bitte mal die Definition für die Jahresenergiemenge aus Grafana als Export per PN schicken, das gefällt mir.
VG Christian
Hallo zusammen,
ich bitte um einen Denkanstoß. Ich möchte meinen Batteriespeicher bei Bedarf zum optimales Strompreis aus dem Netz nachladen. (EVU_Tibber_connect)
Mein erster Gedanke ist den SOC-Forcast im Zeitraum, in welchen Strompreise von Tibber zur Verfügung stehen, mit einem Skript auszuwerten. Unterschreitet der SOC einen Minimalwert (ctrlBatSocManagement01:lowSOC) , wird die fehlende Energie berechnet und daraus eine Ladezeit in h ermittelt.
Erstmal scheint es so zu sein, dass der SOC-FC zwar als Grafik angezeigt wird, aber nicht als Reading bereitgestellt wird. Bedeutet für mich ich muss diese nochmals aus den FC-Readings (PV, Verbrauch..) berechnen.
Übersehe ich da eine Funktionalität in diesem Modul? Hat jemand eine ähnliche Funktion bereits implementiert?
Gruß Manuel
Hallo Manuel,
es gibt das Attr ctrlNextHoursSoCForecastReadings. Hier kannst du dir den SOC-Forecast für die nächsten X Stunden als Reading ausgeben lassen. Der FC ist für jede der kommenden Stunden separat aufgeführt. Je nach deinem Bedarf bildest du dir eine Summe über die kommenden X Stunden.
LG,
Heiko
Zitat von: Petrosilius Zwackelmann am 28 Juni 2025, 12:28:33Hallo zusammen,
ich bitte um einen Denkanstoß. Ich möchte meinen Batteriespeicher bei Bedarf zum optimales Strompreis aus dem Netz nachladen. (EVU_Tibber_connect)
Hallo Manuel,
im EVU_Tibber_connect habe ich auch bereits Trigger readings für max/min Preise und auch die Uhrzeiten für Start und Stop drin.
Das EVU_Tibber gibt Dir noch zusätzlich etwas aufbereitete Info.
Beim Speicher Device habe ich dann im DOIF sowas drin
RAW_WR_1_Speicher_1_ExternControl (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick/Photovoltaik/Wechselrichter/RAW_WR_1_Speicher_1_ExternControl.txt)
################################################################################################################
## 18 SpeicherStromboerse
##
18_SpeicherStromboerse
{if( !([$SELF:state] eq "off") ## DOIF enabled
and
((
[$SELF:SpeicherStromboerse] eq "Tibber" ## Soll Tibber verwendet werden?
and [EVU_Tibber_connect:fc0_trigger] ## Wurde der Trigger geändert
)
or [$SELF:ui_command_1] eq "SpeicherStromboerse" ## Hier wird das uiTable select ausgewertet
)
) {
if ([?EVU_Tibber_connect:fc0_trigger] eq "on") {
set_Reading("SpeicherDcPowerAbs",[?$SELF:SpeicherStromboerseDcPowerAbs]);
fhem("setreading $SELF SpeicherTriggerLaden An");
} else {
fhem("setreading $SELF SpeicherTriggerLaden Aus");
fhem("setreading $SELF SpeicherDcPowerAbs 0");
}
set_Reading("ui_command_1","---"); ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten
## kann das Kommando nicht sofort wiederholt werden
}
}
Die WP, WB und der Wirlpool reagieren entsprechend auch. Beim Wirlpool nutze ich den Trigger, um im Winter bei niedrigem Nachtpreis zusätzlich zu heizen, da der PV-Überschuss am Tag nicht reichen würde.
Die anderen Devices sind auch im contrib abgelegt, um es als Muster zu verwenden. Beschreibungen sind im FHEM Wiki vom Kostal Plenticore zufinden.
VG Christian
Hallo zusammen,
ich habe ein Update der V 1.53.0 in mein contrib geladen.
Hinzugekommen ist die Möglichkeit auf eine Abregelung der PV-Anlage zu reagieren. Dazu gibt die Eingabemöglichkeit einer Device:Reading Kombination (bei mir z.B. ein Readingwert des Victron SolarChargers) via plantControl->reductionState.
In der grafischen Oberfläche ist eine Statusanzeige für den aktuellen Abregelungsstatus eingebaut. Hat man das benannte Attribut nicht gesetzt, wird man mit einem Mouse-Over auf dieses Setting aufmerksam gemacht. (Screenshot) Ansonsten die Ampel in grün wenn keine Abregelung, sonst gelb. Kein "rot", denn die Abregelung ist kein Fehler, nur Info.
Kurze Abregelungen, die sich kaum auf das Ergebnis ausgewirkt haben, sind kein Problem. Das Modul vergleicht ständig die Prognose und reale Erzeugung der betrachteten Stunde und validiert den Datensatz wenn am Ende der Stunde der Unterschied hinreichend gering ist (aktueller Ansatz sind <10%). Ansonsten wird der Datensatz der Stunde mit einem invalid-Kennzeichen von der Korrekturfaktorenanpassung sowie KI-Training ausgeschlossen um Verfälschungen über diesen Weg vorzubeugen.
LG,
Heiko
Zitat von: DS_Starter am 28 Juni 2025, 18:20:23Hallo zusammen,
ich habe ein Update der V 1.53.0 in mein contrib geladen.
Hinzugekommen ist die Möglichkeit auf eine Abregelung der PV-Anlage zu reagieren.
...
Damit sind wir für den Teil, für den SF konzipiert ist, schon super vorbereitet! Danke Heiko!
Wenn es jetzt einen geeigneten Prozess innerhalb von FHEM oder ein erschwingliches Gateway "EEBUS nach irgendetwas, mit dem FHEM gut umgehen kann" gäbe, dann sollten wir alle keine Sorge bei Ankündigung einer Steuerbox mehr bekommen.
Andere Sache: Warum steht bei "Abweichung heute" eigentlich immer (wenn ich darauf schaue ein Minuszeichen? Und was überhaupt wird bei "Abweichung gestern" angegeben? Die Abweichung der PV-Prognose vom tatsächlichen Wert? die Abweichung der Verbrauchs-Prognose von vom tatsächlichen Wert? Oder die Bilanzierung von beidem? Im Wiki kann ich leider nichts dazu finden. Ideal wäre es eigentlich, alle drei Werte zu haben.
ZitatWarum steht bei "Abweichung heute" eigentlich immer (wenn ich darauf schaue ein Minuszeichen?
Im Standard wird die Tagesabweichung nach Sonnenuntergang berechnet. Bis dahin steht dort ein '-'. Ein Mouse-Over zeigt dir das aber. Du kannst mit plantControl->genPVdeviation die Berechnung umschalten.
ZitatUnd was überhaupt wird bei "Abweichung gestern" angegeben?
Mitternacht wird der für heute berechnete Betrag nach "gestern" verschoben. Wie ein Schieberegister. Für heute gibt es dann wieder den aktuellen Wert wie oben geschrieben.
Und es ist das Verhältnis von PV Prognose zu realer Erzeugung. Aber auch das zeigt ein Mouse-Over.
LG,
Heiko
Zitat von: DS_Starter am 28 Juni 2025, 21:10:06...
Mouse-Over
...
Jetzt sehe ich es auch :)
Vielleicht wäre es hilfreich den Standard bei "Abweichung heute" von "nach Sonnenuntergang" in "bis jetzt" zu ändern. Dann würde nach Sonnenuntergang immer noch der gleiche Wert angezeigt, tagsüber sieht man aber auch etwas sinnvolles.
Die plantControl Paramter werden in der 53'er version jetzt auch im configCheck mit geprüft inkl. Verweis auf den passenden Wiki Beitrag.
Die V 53 werde ich heute Abend einchecken. Sind bereits ein Menge Features aufgelaufen.
ZitatVielleicht wäre es hilfreich den Standard bei "Abweichung heute" von "nach Sonnenuntergang" in "bis jetzt" zu ändern. Dann würde nach Sonnenuntergang immer noch der gleiche Wert angezeigt, tagsüber sieht man aber auch etwas sinnvolles.
Ob diese gleitende Abweichung (plantControl->genPVdeviation=continuously) so sinnvoll ist, weiß ich nicht mal. Ich persönlich halte sie nicht für sehr hilfreich, aber da kann jeder seine eigene Meinung haben. Deswegen kann man es ja so einstellen wie man es mag. Also plantControl->genPVdeviation=continuously setzen und fertig. ;)
V1.53.0 ist eingecheckt und morgen früh im Update.
Moin zusammen,
Danke für die Arbeit, hat sich bezüglich Autarkie was getan? Kann ich dem Modul beibringen das ich nicht einspeisen kann?
Gruß Michael
Hallo Michael,
ja, es gibt im Prinzip 2 Stellen:
- plantControl->feedinPowerLimit: bedeutet wieviel eingespeist werden kann -> bei dir "0".
Diese Info ist für ein Batteriemanagement wichtig, da versucht wird die
Bat als Puffer zu nutzen soweit das geht um eine Abregelung zu verhindern.
Geht natürlich nur wenn du Bat hast. Im Wiki gibt es etwas dazu.
- plantControl->reductionState: Hier suchst du dir ein passendes Reading deiner Anlage, welches SF
signalisiert falls eine Abregelung eingetreten ist. Das ist für den
"Lernprozess" wichtig um falsche Rückschlüsse zu verhindern.
LG,
Heiko
Info bzgl. 1.53.0: PERL WARNING: Use of uninitialized value $color in string eq at ./FHEM/76_SolarForecast.pm line 18709
Test V1.53.0
setupBatteryDev01 show=3 funktioniert nicht. Es wird kein Batteriesymbol unterhalb der Balkengrafik angezeigt.
show=0-2 funktioniert.
attr AB_WS_SS setupBatteryDev01
Deye_12k icon=@dyn:@#0CFB0C:@yellow:@red show=2:bottom cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
show=3
Mit dem alten Attribut funktioniert die Anzeige unterhalb.
Ein weiterer Eintrag ist mir im LOG aufgefallen, der immer bei einem Neustart von FHEM kommt.
2025.06.30 16:55:27 1: reload: Error:Modul 99_mySolarForecastUtils deactivated:
Wo kann ich diese Eintrag beeinflussen?
@Chris,
ZitatsetupBatteryDev01 show=3 funktioniert nicht. Es wird kein Batteriesymbol unterhalb der Balkengrafik angezeigt.
Ohne die Ergänzung top oder bottom wird der Standard umgesetzt und der ist 'top'. Ist aber nichts Neues.
D.h. nur show=3 zeigt Bat über den Balken und funktioniert auch in Ebene 3 (Screenshot).
ZitatEin weiterer Eintrag ist mir im LOG aufgefallen, der immer bei einem Neustart von FHEM kommt.
...
Error:Modul 99_mySolarForecastUtils deactivated
Du hast einen Perl-Syntax Fehler in der 99_mySolarForecastUtils. Im Log sollte vor diesem Eintrag der eigentliche Fehler ausgeschrieben werden.
LG,
Heiko
@grappa24,
die Warnung habe ich beseitigt und eingecheckt. Ist morgen früh im Update.
Anscheinend macht mir die Hitze schon zu schaffen.
Zum einem hatte ich einen Denkfehler,und habe mich aus dem Thread https://forum.fhem.de/index.php?topic=137058.msg1343782#msg1343782 betreffen label irritieren lassen und zum anderen einen Syntax-Fehler.
Deye_12k icon=@dyn:@#0CFB0C:@yellow:@red show=2:bottom cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
show=3
Das kann ohnehin nicht funktionieren.
Trotzdem schaffe ich es nicht eine Ebene 3 einzurichten. show=3:bottom
Anscheinend blockiere ich mir irgendwie die Ebene 3.
Nutz die Flussgraphik die Ebene 3?
Die Ebene 3 wird aktiviert, wenn du das Attr graphicBeam5Content und/oder graphicBeam6Content setzt. Ich habe es gleich im Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Aktivierung_der_Balkengrafik_Ebene_3) ergänzt.
ZitatNutz die Flussgraphik die Ebene 3?
Nein, die Flußgrafik ist eine eigenständige Applikation.
Könntest du betreffend 99_mySolarForecastUtils.pm noch eine Änderung im Wiki vornehmen?
Basis für die Datei 99_mySolarForecastUtils.pm
###############################################################################
#
# Save this file as 99_mySolarForecastUtils.pm, and create your own functions
# in the new file. They are then available in every Perl expression.
#
###############################################################################
package main;
use strict;
use warnings;
sub
mySolarForecastUtils_Initialize($$)
{
my ($hash) = @_;
}
###############################################################################
#
# Datei Start
#
###############################################################################
Eigene Perl Code Funktionen eintragen
###############################################################################
#
# Datei Ende
#
###############################################################################
1;
Mein Fehler lag in der Definition mySolarForecastUtils am Anfang der Datei.
Habe es ergänzt.
Das steht eigentlich doch schon im allgemeinen WIKI für alle myUtils wie man es richig macht: ;)
https://wiki.fhem.de/wiki/99_myUtils_anlegen
Irgendwas ist generell kaputt gegangen mit dem Update auf v1.53.0, siehe Screenshots, negative Zahlen hatte ich noch nie, machen auch keinen Sinn.
Siehe die richtigen Werte aus meiner Grafik.
Geändert habe ich auch:
plantControl feedinPowerLimit=0 reductionState=d_check_wechselrichter_100:state:{$VALUE eq "on"}
ZitatIrgendwas ist generell kaputt gegangen mit dem Update auf v1.53.0
Kaputt ist sicherlich nichts. Welche Version hattest du vorher? Hast du die Updates der Weiterentwicklungen immer mitgemacht?
Zitat von: seayak am 27 Juni 2025, 14:04:26minimal mögliche Intervallzeiten gesetzt
Typischer Anfängerfehler - damit legt man sein System ziemlich lahm.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 Juli 2025, 01:56:00Zitat von: seayak am 27 Juni 2025, 14:04:26minimal mögliche Intervallzeiten gesetzt
Typischer Anfängerfehler - damit legt man sein System ziemlich lahm.
LG
pah
Hallo pah,
im Deinem Zitat von mir fehlt leider noch der nicht von Dir mit kopierte Zusatz "wenn technisch verantwortbar". Das beinhaltet auch den sorgsamen Umgang mit den Intervallzeiten. Auch die Beachtung von 300P gegebenen Hinweise wird ein technisch versierter User beachten.
Viele Grüße!
Peter
Zitat von: seayak am 01 Juli 2025, 12:18:01Das beinhaltet auch den sorgsamen Umgang mit den Intervallzeiten. Auch die Beachtung von 300P gegebenen Hinweise wird ein technisch versierter User beachten.
Das sehe ich deutlich anders, weil damit immer noch nicht das Problem der zeitversetzten Messwerte gelöst wird. Statt eines reichlich absurden Sampling-Intervalls von 10 Sekunden für diese Daten wäre der richtige Weg eine Interpolation zu einem bestimmten Zeitpunkt.
LG
pah
Eine Frage noch zur Balkendarstellung der Batterie-Einheiten.
Jede Deye-Batterie hängt an einem Deye-Hybridinverter. Die beiden Hybridinverter und zugehörigen Batterien haben miteinander nichts zu tun.
Beide Batterien sind im Soll, aber die Batterie 2 zeigt eine gravierende Abweichung an.
setupBatteryDev01
Deye_12k icon=@dyn:@#0CFB0C:@yellow:@red show=2:bottom label=beside cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
setupBatteryDev02
Deye_15k icon=@dyn:@#0CFB0C:@yellow:@red show=3:bottom label=beside cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
Irgendwo muss ich da noch einen Fehler haben.
.....gegenüber des 2ten Wertes ist die Abweichung so groß :o .
Ausschlaggebend ist der Eintrag des 2.te Wertes in "graphicBeamXContent" - wenn keiner da ist ist die Abweichung halt so groß wie der Wert selbst ist.
Zeig mal den Bereich mit den Attributen
Nachsatz zu meinem Post wegen evtl. Datenüberschneidungen:
Hab zur Vermeidung von Verwirrung in meinem Post extra nicht dabei angegeben, dass ich innerhalb von SF beim attr plantControl den Wert cycleInterval=0 gesetzt habe.
Der "automatische" zyklische Interval bei SF ist somit ausgestellt.
Die SF-Daten werden bei mir erst ganz am Ende in einem eigens dafür angelegtem Sammel-Notify für alle relevanten Daten (Dummy- / Verbrauchs- / Bezugs- / Leistungs- / Zustandsdaten / etc. / usw.) aktualisiert.
Der "triggeredByEvent" ist dort auf die Veränderung des Saldos der Bezugleistung im Smartmeter am Hausanschluss eingestellt. Das Smartmeter-Device hat eine Min-Interval von 30 oder aber der Saldo der Bezugsleistung ändert sich vorher.
Eine 100 % Lösung ist dies sicherlich auch nicht - aber die bekannten Probleme mit den negativen Werten im Log kenne ich bislang nur aus den Post anderer User... :o
Zitat von: 300P am 02 Juli 2025, 15:26:17Der "triggeredByEvent" ist dort auf die Veränderung des Saldos der Bezugleistung im Smartmeter am Hausanschluss eingestellt. Das Smartmeter-Device hat eine Min-Interval von 30 oder aber der Saldo der Bezugsleistung ändert sich vorher.
Das als "Führungsgröße" zu verwenden erscheint auf den ersten Blick schlüssig. Wie gehst Du dann mit den weiteren Geräten (Wechselrichter, Batterie) um?
Wenn sich der "PowerOffset" im SmartMeter ändert, kann eine Ursache eine Änderung der WR-Leistung sein, d.h. man müsste dessen Leistung sofort abholen. Machst Du das so und passen die Werte dann wirklich zusammen, d.h. steile Gradienten durch Wolken werden sauber abgebildet?
Zitat von: TheTrumpeter am 02 Juli 2025, 15:51:15Wie gehst Du dann mit den weiteren Geräten (Wechselrichter, Batterie) um?
Wenn sich der "PowerOffset" im SmartMeter ändert, kann eine Ursache eine Änderung der WR-Leistung sein, d.h. man müsste dessen Leistung sofort abholen. Machst Du das so und passen die Werte dann wirklich zusammen, d.h. steile Gradienten durch Wolken werden sauber abgebildet?
Alle Device werden - wie schon geschrieben - dann mit den aktuellen Werten abgeholt
==>>> Sie stehen ebenfalls auf manuellem Intervall bzw. reagieren auf diesen per Notify / triggeredByEvent.(siehe Screenshot)
Mir reicht dies so bislang - hab noch nie nachverfolgt ob und wie genau dies ist wenn z.B. Wolken kommen und gehen oder Verbräuche hoch/runter gehen
=>>> da sollen sich meine BWR doch Gedanken drum machen - mir ist's egal ::)
PS:
Nach 30 Tagen sind das alles so oder so nur noch Stundenwerte.
und irgendwann dann nur noch Tageswert die ich mir ansehen will ;D ....
Zitat von: 300P am 02 Juli 2025, 15:16:26.....gegenüber des 2ten Wertes ist die Abweichung so groß :o .
Ausschlaggebend ist der Eintrag des 2.te Wertes in "graphicBeamXContent" - wenn keiner da ist ist die Abweichung halt so groß wie der Wert selbst ist.
Zeig mal den Bereich mit den Attributen
Da ist kein Eintrag - also Rätselraten oder ;)
Nimm mal die Werte der attr ...Beam5.. in ...Beam6... und lösch die in ..Beam5..
Könnte - Müsste aber nicht sein das es sich verändert. ???
EDIT - Nachsatz:
Falls das nicht wirkt - du hast doch nur 1 Wert je Beam - Also schalt die Berechnung in GrafikControl aus:
showDiff Zusätzliche numerische Anzeige der Differenz '<primärer Balkeninhalt> - <sekundärer Balkeninhalt>'.
no - keine Differenzanzeige (default)
top - Anzeige über den Balken
bottom - Anzeige unter den Balken
Zitat von: 300P am 02 Juli 2025, 20:07:44Nimm mal die Werte der attr ...Beam5.. in ...Beam6... und lösch die in ..Beam5..
Unter ...Beam6... definiert sieht es anders aus.
Irgendwie dürfte aber die Abweichung trotzdem nicht stimmen. Mir kommen diese Werte zu gring vor.
Zitat von: Burny4600 am 02 Juli 2025, 20:13:05Irgendwie dürfte aber die Abweichung trotzdem nicht stimmen. Mir kommen diese Werte zu gring vor.
Das sind sicherlich irgendwelche Rundungsdifferenzen (1 Wert je Beam s.o. beim Edit)
@DS_Starter:
Dies ist noch aus der Zeit als es "nur" eine Anzeige mit 2 Werten gab
showDiff Zusätzliche numerische Anzeige der Differenz '<primärer Balkeninhalt> - <sekundärer Balkeninhalt>'.
no - keine Differenzanzeige (default)
top - Anzeige über den Balken
bottom - Anzeige unter den Balken
Aus dem obigen ergibt sich evtl. zukünftig der Wunsch einiger User das es pro Beam gesteuert werden könnte ?!?
Kannst du ja mal auf die berühmte ToDo-List nehmen ;)
.
ZitatAus dem obigen ergibt sich evtl. zukünftig der Wunsch einiger User das es pro Beam gesteuert werden könnte ?!?
Kannst du ja mal auf die berühmte ToDo-List nehmen ;)
Kann ich machen, wenn es den Wunsch geben sollte. ;)
Als wir zu Beginn nur einen Ebene hatten, war das egal. Nun sind es ja inzwischen 3, und wer weiß ob es dabei bleibt.
Moin zusammen,
ich hatte da mal einen Grundsätzlichen Gedanken zur Abregelung oder auch Limitierung bei negativen Börsenpreise.
Wir alle haben ja bereits echte Erträge, mit der die KI gelernt hat.
Was wird denn mit denen, die neu anfangen und direkt der Limitierung unterliegen, da wird die PV-Anlage ja nie ihre volle Leistungsmöglichkeit erbringen. IM SF sollen ja die entsprechenden Stunden markiert werden, wenn sich das jedoch häuft wird es nurnoch die historischen maximalen Werte geben, die ein Neuling nicht bekommen kann.
Ich denke, da sind wir dann wieder zurück bei unserer alten Berechnungsformel mit Ausrichtung, Neigung, Sonnenstand und Winkelkorrektur, oder halt den Onlinediensten, die das machen :-( Ein Testlauf für die jeweilige Anlage bis 11kW könnte dann nur ein E-Auto laden zum Mittagshoch bieten, bei dem man einen maximalen Eigenverbrauch erzeugt.
In meinem Fall, da ich ja mit DbLog arbeite könnte ich für die entsprechenden Datensätze eine Datenrefferenz erzeugen, die als Maximum angenommen werden kann, bevor die Daten in die KI geladen werden.
Wie seht Ihr das, liege ich da gedanklich falsch?
VG Christian
Moin,
ZitatIch denke, da sind wir dann wieder zurück bei unserer alten Berechnungsformel mit Ausrichtung, Neigung, Sonnenstand und Winkelkorrektur, oder halt den Onlinediensten, die das machen
Dieser Ansatz ist bis heute die Grundlage des Moduls und wurde nie aufgegeben. Die ganze KI Geschichte ist nur eine On-Top Variante. Gerade Beginner haben keine Trainingsdaten zur Verfügungung. Die Daten bauen sich erst langsam mit der Zeit auf, bevor man davon partizipieren kann.
Das trifft dann natürlich auch auf die Fälle mit Abregelung zu. Die Trainingsdaten werden weniger und decken nur einen Teil der auftetenden Bedingungen ab, sind jedoch nur unterstützend für die PV Prognose auf Grundlage der verwendeten API's.
Also insofern kein Handlungsbedarf im Modul.
LG,
Heiko
In meinem contrib liegt die V 1.53.2.
showDiff kann man nun für jede Ebene separat setzen:
showDiff Zusätzliche numerische Anzeige der Differenz '<primärer Balkeninhalt> - <sekundärer Balkeninhalt>'.
Die Angabe für jede Ebene besteht aus der Ebenen-Nummer (1..X), einem ':' gefolgt von der Position 'top' oder 'bottom'.
<Ebene>:top - Anzeige über den Balken
<Ebene>:bottom - Anzeige unter den Balken
LG,
Heiko
passt :)
Ich habe im FHEM Log immer Einträge, wenn Consumer "extern" ein- und ausgeschalten werden. Ich habe keine Option gefunden (außer das Verbose-Level), um die Meldung zu deaktivieren. Habt ihr noch eine Idee?
Zitat von: ranon am 04 Juli 2025, 14:22:13ein- und ausgeschalten werden
Es heißt ausgeschaltet. Bitte https://wiki.fhem.de/wiki/Fehlerteufel beachten
LG
pah
Zitat von: ranon am 04 Juli 2025, 14:22:13Ich habe im FHEM Log immer Einträge, wenn Consumer "extern" ein- und ausgeschalten werden. Ich habe keine Option gefunden (außer das Verbose-Level), um die Meldung zu deaktivieren. Habt ihr noch eine Idee?
Das hatte ich auch mal, damals noch bei verbose 2 - Lösung siehe https://forum.fhem.de/index.php?msg=1342407 ff.
Hinweis:
verbose
Set the verbosity level. Possible values:
0 - server start/stop
1 - error messages or unknown packets
2 - major events/alarms.
3 - commands sent out will be logged.
4 - you'll see whats received by the different devices.
5 - debugging.
The value for the global device is a default for other devices without own verbose attribute set.
=>> verbose "2" ist (u.a.) deshalb m.M.n. auch "normalerweise" in global einzutragen um derartige Meldungen zu vermeiden ;)
Neue V ist eingecheckt und morgen im Update.
LG
Wenn man die Meldungen "... was external switched ..." nicht im Log sehen möchte einfach verbose 2 im Device einstellen. Alle relevanten Fehler oder Warnungen kommen vom Modul mit verbose 2 oder kleiner.
Ich habe alle SF auf 2 stehen im produktiven Betrieb wenn alles zu meiner Zufriedenheit läuft.
Guten Morgen,
@Wzut,
hattest du schon Gelegenheit weiter an der Thematik Icons bzw. Balken "Stapelanzeige" zu arbeiten?
Ich frage nur wegen der Planung der nächsten Schritte im Modul, d.h. ob ich es sich lohnt noch zu warten bevor ich etwas größeres wie z.B. Implementierung eines neuronalen Netzes anfasse?
LG,
Heiko
Guten Morgen,
@DS_Starter, an der Stelle einfach mal Danke für dieses super Modul !
Ich nutze das Modul in den Sonnenmonaten primär dafür meinen E3DC-Speicher und meine Consumer (Heizstäbe, Klimaanlage etc...) so zu steuern und zu schalten um eine Netzeinspeisung möglichst zu vermeiden. Funktioniert auch wunderbar, was super wäre wenn es irgendwann mal möglich ist noch mehr als 16 Consumer zu steuern. Im Voraus schon Mal vielen Dank !
Gruß,
Rolf
Hallo Rolf,
mehr Consumer sind "eigentlich" kein Problem. Es wird dann nur immer etwas enger mit der Darstellung in der Flowgrafik. Aber wenn man vllt. nicht unbedingt alle darstellt (kann man ausblenden) oder sogar mit allen in der Übersicht klarkommt, sollte es machbar sein.
Wieviele Consumer wären denn dein Bedarf? (nicht übertreiben ;) )
LG,
Heiko
Zitat von: DS_Starter am 05 Juli 2025, 12:00:35Hallo Rolf,
mehr Consumer sind "eigentlich" kein Problem. Es wird dann nur immer etwas enger mit der Darstellung in der Flowgrafik. Aber wenn man vllt. nicht unbedingt alle darstellt (kann man ausblenden) oder sogar mit allen in der Übersicht klarkommt, sollte es machbar sein.
Wieviele Consumer wären denn dein Bedarf? (nicht übertreiben ;) )
LG,
Heiko
Hallo Heiko,
Danke für die schnelle Rückmeldung, so 3 bis 4 Consumer mehr würde mir helfen. Die Visualisierung selber spielt dabei eigentlich für mich keine Rolle, für mich ist interessant die Consumer von deinem Modul schalten zu lassen, weil ich es nur mit deinem Modul schaffe den Verbrauch dieser Consumer bei der Verbrauchsprognose auch gleich wieder von deinem Modul rausrechnen lassen kann. Wie gesagt, sind primär Consumer die ich nur ansteuere bei PV-Überschuss und um Netzeinspeisung zu vermeiden). Spätestens im Herbst nutze dich dann nämlich wieder die Verbrauchsprognose deines Moduls um das Laden meines E3DC-Speichers zu steuern, also ob geladen werden muss, oder auch nicht und da ich einen dynamischen Stromtarif habe auch noch zum Ermitteln des idealen Zeitpunkts.
Danke vorab !
Gruß,
Rolf
Ich werde versuchen die möglichen Consumer auf 20 hochzuziehen. Ist eine schöne runde Zahl ;), schauen wir mal wie gut sie sich einfügen lassen.
Zitat von: DS_Starter am 05 Juli 2025, 13:12:25.... Consumer auf 20 hochzuziehen. Ist eine schöne runde Zahl ;), .....
Hallo Heiko.
Ich denke, wenn eine weitere Auffächerung einmal möglich ist wie wir schon einmal angesprochen hatten, dann dürfte es mit der Übersicht kein Problem geben.
20 Consumer müssten eigentlich für den privaten Bereich mit größeren Anlagen ausreichen sein.
@all,
morgen früh wird es ein wichtiges Update für Nutzer von DWD_OpenData geben.
Die letzte Zeit mit fast durchweg optimalen Sonnenschein habe ich beobachtet und mich gefragt, wieso die Prognose bei Verwendung von DWD_OPenData (Device) immer schlechter gegenüber von OpenMeteo DWD ICON wurde. Es wurden tendienziell überhöhte Werte gegenüber der real erzeugten Energie prognostiziert, sodass die Korrekturfaktoren immer weiter nach unten korrigierten.
Ich habe einen Implementierungsfehler identifiziert, der sich in längeren Phasen mit Bewölkungen <= 10 besonders bemerkbar macht.
Da diese Codekorrektur sehr wichtig für diesen Userkreis ist, habe ich diese Version als Minor Version 1.54.0 und nicht als einfachen Bugfix eingecheckt. Die Version ist auch sofort in meinem contrib zum Download verfügbar.
LG,
Heiko
ZitatIch denke, wenn eine weitere Auffächerung einmal möglich ist wie wir schon einmal angesprochen hatten, dann dürfte es mit der Übersicht kein Problem geben.
Ja, keine Frage. Das ist dann grafisch/programmtechnisch nochmal eine höhere Herausforderung.
Seitens der Priorität würde ich aktuell eher Wert auf eine inhaltliche Weiterentwicklung/Verbesserung der KI Unterstützung im Bereich der Verbrauchsprognose u. ggf. PV-Prognose legen.
20 Consumer könnten wir wahrscheinlich mit der aktuellen Grafikstruktur noch unterbringen. Ich probiere das mal.
LG,
Heiko
Hallo Ihr Sonnenanbeter.
Ich hab ne Frage, und zwar habe ich seit Sonntag ein Problem mit meinem alexa FHEM, und nach posting im alexa Unterforum !könnte! das SolarForecast mit eine Ursache sein.
Situation:
Nachts, so gegen 00:09 Uhr, stirbt mein alexa FHEm, und meldet: "alexafhem stopped; failed to connect to fhem: error: socket hang up".
Im alexa log ist nichts auffälliges, aber im FHEM log:
2025.07.05 00:09:54.783 3: PV_Prognose - old backup file './FHEM/FhemUtils/PVH_SolarForecast_PV_Prognose_2025_07_02_00_09_03' deleted
2025.07.05 00:09:54.783 3: PV_Prognose - old backup file './FHEM/FhemUtils/PVC_SolarForecast_PV_Prognose_2025_07_02_00_09_03' deleted
2025.07.05 00:09:55.225 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.
Laut @passibe ist in dem log eine Zeile nach diesem Eintrag etwas zu finden, was möglicherweise hier auf dieses Modul hinweist.
Achtung, eintrag hier gekürzt, zu viele Zeichen, Forum-Software macht das nicht mit:
2025.07.05 00:09:55.263 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:67:111:110:116:101:110:116:45:84:121:112:101:58:32:97:112:112:108:105:99:97:116:105:111:110:47:111:99:116:101:116:45:115:116:114:101:97:109:59:32:99:104:97:114:115:101:116:61:85:84:70:45:56:13:10:13:10:91:34:80:86:95:80,off:0
Kann ich weitere Daten bereitstellen, um das genauer zu analysieren ? Oder ist das SolarForecast hier unschuldig ?
Viele Grüße
Zitat von: DS_Starter am 05 Juli 2025, 13:12:25Ich werde versuchen die möglichen Consumer auf 20 hochzuziehen. Ist eine schöne runde Zahl ;), schauen wir mal wie gut sie sich einfügen lassen.
Hallo Heiko,
super, freut mich - vielen Dank vorab !
Gruß,
Rolf
@roadghost,
ZitatNachts, so gegen 00:09 Uhr, stirbt mein alexa FHEm, und meldet: "alexafhem stopped; failed to connect to fhem: error: socket hang up".
Ein Zusammenhang mit dem SF-Modul ist sehr unwahrscheinlich, weil:
- im SF-Modul TcpServerUtils.pm nicht verwendet wird
- die Funktion TcpServer_WriteBlocking (das ist die Sub in der sich die Fehlerzeile 563 befindet) im Modul nicht verwendet/aufgerufen wird
- ich mir keinen Zusammenhang zwischen dem Löschen von 2 Dateien auf BS Ebene und einem TCP-Aufruf denken kann
- meine Logausgaben grundsätzlich anders aufgebaut sind als:
2025.07.05 00:09:55.263 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:67:111:110:116:101:110:116:45:84:121:112:101:58:32:97:112:112:108:105:99:97:116:105:111:110:47:111:99:116:101:116:45:115:116:114:101:97:109:59:32:99:104:97:114:115:101:116:61:85:84:70:45:56:13:10:13:10:91:34:80:86:95:80,off:0
Du kannst allerdings probehalber die Erstellung und Bereinigung der Backup-Files im SF-Device einfach mal als Negativtest ausschalten indem du im Attr plantControl explizit backupFilesKeep=0 setzt.
LG,
Heiko
Hallo Heiko,
ich habe ein Problem mit dem Consumer 07. Dieser Consumer verursacht eine ständige Wiederholung unter Event monitor.
2025-07-05 15:40:18.116 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
Wenn ich die Definition ändern möchte, wird diese Änderung nicht übernommen.
Die SolarForcast Version ist V1.53.3. Mit der V1.53.0 ist mir das noch nicht aufgefallen.
Es kommt auch ständig immer wieder Connention lost.
Auch im Log sind ständige Einträge vorhanden.
2025.07.05 15:19:54.519 3: [Freezemon] myFreezemon: possible freeze starting at 15:19:52, delay is 2.518 tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::centralTask(N/A)
2025.07.05 15:19:57.236 3: [Freezemon] myFreezemon: possible freeze starting at 15:19:55, delay is 2.235 possibly caused by: tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3699788)(GetUpdate) tmr-STELLMOTOR_GetUpdate(AB_FR_HZG_R2H)
2025.07.05 15:20:03.327 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:02, delay is 1.326 possibly caused by: tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3658698)(ProcessRequestQueue)
2025.07.05 15:20:46.259 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:45, delay is 1.258 possibly caused by: tmr-FHEM::SolarForecast::centralTask(N/A) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-SYSMON_Update(sysmon) tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-PID20_Calc(N/A) tmr-PID20_Calc(N/A) tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS) tmr-CODE(0x3658698)(ProcessRequestQueue)
2025.07.05 15:20:48.961 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:47, delay is 1.96 possibly caused by: (GetUpdate) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3699788)(GetUpdate) tmr-FHEM::SolarForecast::centralTask(N/A) tmr-CODE(0x36bc650)(ResponseTimeout)
2025.07.05 15:20:50.911 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:49, delay is 1.91 possibly caused by: tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3658698)(ProcessRequestQueue)
Ein Löschen des Consumer 07 mit Neustart löst das Problem zwar, aber wenn ich den Consumer 07 neu definiere wird der alte Eintrag wieder übernommen.
Wie kann ich die alte Definition entfernen?
Eines habe ich noch herausgefunden.
Der Consumer 07 lässt sich ändern, wenn ich den Eintrag für Consumer 07 unter ctrlUserExitFn entferne. Dann bleibt auch die Definition von Consumer 07 nach einem Neustart von FHEM vorhanden.
Mache ich den Eintrag unter ctrlUserExitFn
{
::pumpPoControl ($name, '07', 180);
}wird unter Consumer 07 die alte Konfiguration eingetragen.
Warum ist das nur bei Consumer 07?
ZitatWarum ist das nur bei Consumer 07?
Keine Ahnung ;)
Wie sieht die sub pumpPoControl denn genau aus? Poste mal bitte den kompletten Code.
@Chris,
ich sehe gerade, du hast den Alias falsch angegeben. Er darf keine Leerzeichen enthalten.
Lt Commandref:
ZitatIm optionalen Alias sind Leerzeichen durch '+' zu ersetzen (z.B. 'Ein+toller+Alias').
Also
... AB_POOLD:Aussenbereich+Pool auto=automatic
Ich habe den Alias in der üblichen Form mit definiert. Wurde jetzt auf AB_POOLD:Aussenbereich+Pool geändert.
Consumer 07
AB_POOLD:Aussenbereich+Pool
icon=scene_pool
type=other
asynchron=1
power=0 pcurr=Active_Power__W:W:2 etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=automatic mode=must
interruptable=1 swoffcond=AB_POOLD:SF_Abort:1
mintime=240 notbefore=03:00 notafter=21:00
Eintrag in der 99_mySolarForecastUtils.pm
############################################################################
# Pumpensteuerung AB-Pool
############################################################################
sub pumpPoControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)
$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};
readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung
if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);
my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;
for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}
if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}
if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1"); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0"); # keine Interrupt-Freigabe
}
}
return;
}
Jedenfalls liegt es nicht an dem Pseudo Leerzeichen.
Sowie ich wieder das Attribut ctrlUserExitFn ergänze
{
::pumpPoControl ($name, '07', 180);
}
steht sofort wieder der alte Eintrag im Consumer 07
Alte Consumer 07 Definition
AB_POOLD:Aussenbereich Pool
asynchron=1
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
icon=scene_pool
interruptable=0
mintime=240
mode=must
notafter=21:00
notbefore=03:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swoffcond=AB_POOLD:SF_Abort:1
swstate=state:EIN:AUS
type=other
Eigenartig.
Das ist in der Tat eigenartig. Poste mal bitte wie der "alte" Eintrag aussieht, auf den der consumer gesetzt wird.
Das ist der alte Eintrag.
AB_POOLD:Aussenbereich Pool
asynchron=1
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
icon=scene_pool
interruptable=0
mintime=240
mode=must
notafter=21:00
notbefore=03:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swoffcond=AB_POOLD:SF_Abort:1
swstate=state:EIN:AUS
type=other
Also ist es tatsächlich nur die Änderung von interruptable=0/1.
Hast du global autosave=1 gesetzt oder nicht gesetzt, jedenfalls nicht explizit 0?
Was passiert, wenn du:
set ... attrKeyVal consumer07 interruptable=1 bzw.
set ... attrKeyVal consumer07 interruptable=0
manuell ausführst?
Zitat von: DS_Starter am 05 Juli 2025, 17:15:26@roadghost,
ZitatNachts, so gegen 00:09 Uhr, stirbt mein alexa FHEm, und meldet: "alexafhem stopped; failed to connect to fhem: error: socket hang up".
Ein Zusammenhang mit dem SF-Modul ist sehr unwahrscheinlich, weil:
- im SF-Modul TcpServerUtils.pm nicht verwendet wird
- die Funktion TcpServer_WriteBlocking (das ist die Sub in der sich die Fehlerzeile 563 befindet) im Modul nicht verwendet/aufgerufen wird
- ich mir keinen Zusammenhang zwischen dem Löschen von 2 Dateien auf BS Ebene und einem TCP-Aufruf denken kann
- meine Logausgaben grundsätzlich anders aufgebaut sind als:
2025.07.05 00:09:55.263 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:67:111:110:116:101:110:116:45:84:121:112:101:58:32:97:112:112:108:105:99:97:116:105:111:110:47:111:99:116:101:116:45:115:116:114:101:97:109:59:32:99:104:97:114:115:101:116:61:85:84:70:45:56:13:10:13:10:91:34:80:86:95:80,off:0
Du kannst allerdings probehalber die Erstellung und Bereinigung der Backup-Files im SF-Device einfach mal als Negativtest ausschalten indem du im Attr plantControl explizit backupFilesKeep=0 setzt.
LG,
Heiko
Hi,
da Du Millionenmal mehr Ahnung von der Materie hast, als ich, möchte ich Dir da nicht widersprechen, aaber:
Wenn ich die 76_SolarForecast aus dem restoreDir vom 02.07.25 wiederherstelle, taucht der Fehler nicht mehr im FHEM log auf.
Möglicherweise besteht dort nur ein gewisser Zusammenhang, oder soetwas wie ein Querverweis ??
global autosave=0 ist definiert.
Sobald ich set AB_WS_SS attrKeyVal consumer07 interruptable=1 eingebe, kommt zwar keine Fehlermeldung, aber die Consumer 07 Definition wird auf die alte Definition zurückgesetzt.
Wenn global autosave=0 definiert ist, wird das automatische Sichern verhindert.
Will man attrKeyVal nutzen, sollte autosave=1 gesetzt bzw. garnicht gesetzt sein. autosave=1 ist der FHEM Standard. Ich schreibe es in die Commandref noch rein.
Ich habe autosave=1 jetzt definiert, aber es hat sich nichts am Consumer 07 geändert.
Ergänzend für die dyn Definition bei den Batterien. Die Batterie 2 übernimmt nicht die dyn Defintion.
ZitatWenn ich die 76_SolarForecast aus dem restoreDir vom 02.07.25 wiederherstelle, taucht der Fehler nicht mehr im FHEM log auf.
Möglicherweise besteht dort nur ein gewisser Zusammenhang, oder soetwas wie ein Querverweis ??
Schwarze Kunst...
Welche Version stellst du denn aus dem restoreDir vom 02.07.25 wieder her?
ZitatErgänzend für die dyn Definition bei den Batterien. Die Batterie 2 übernimmt nicht die dyn Defintion.
Und "get ... valBattery" sieht wie aus? Interessiert eigentlich nur der key bicon.
get AB_WS_SS valBattery
01 => balias => OG2 Heizraum - PV-Anlage 1
basynchron => 1
bcharge => 65
bchargewh => 15600
bicon => @dyn:@#0CFB0C:@yellow:@red
binstcap => 24000
blabel => beside
bloadAbortCond => 0
bname => Deye_12k
bpinmax => 9223372036854775807
bposingraph => bottom
bpoutmax => 9223372036854775807
bpowerin => 820
bpowerout => 0
bshowingraph => 2
02 => balias => AB Ost Nebengebäude - PV-Anlage 2
basynchron => 1
bcharge => 98
bchargewh => 23520
bicon => @dyn:@#0CFB0C:@yellow:@red
binstcap => 24000
blabel => beside
bloadAbortCond => 1
bname => Deye_15k
bpinmax => 9223372036854775807
bposingraph => bottom
bpoutmax => 9223372036854775807
bpowerin => 650
bpowerout => 0
bshowingraph => 3
Du hast "dyn" nur für den Status "empfohlen" aktiviert. Wenn nicht "empfohlen" wird, wird kein dyn verwendet. Du kannst es prüfen indem du alle Status mit "dyn" besetzt:
icon=@dyn:@dyn:@dyn:@dyn
Zitat von: DS_Starter am 05 Juli 2025, 19:59:56ZitatWenn ich die 76_SolarForecast aus dem restoreDir vom 02.07.25 wiederherstelle, taucht der Fehler nicht mehr im FHEM log auf.
Möglicherweise besteht dort nur ein gewisser Zusammenhang, oder soetwas wie ein Querverweis ??
Schwarze Kunst...
Welche Version stellst du denn aus dem restoreDir vom 02.07.25 wieder her?
Ich stelle wieder her: 76_SolarForecast.pm:v1.52.2-s29962/2025-05-14
ZitatIch stelle wieder her: 76_SolarForecast.pm:v1.52.2-s29962/2025-05-14
Seitdem ist natürlich viel passiert, wobei wir mit Alexa nichts zu tun haben. Zumindest wüsste ich nicht wie es zustande kommen sollte.
Das einzige was in diesem Kontext vllt. relevant sein könnte ist ein Icon, was als Mouse-Over in der Grafik dazu gekommen ist (Screenshot). Wobei mir dennoch die Phantasie fehlt was das mit Alexa zu tun haben könnte.
Was machst du denn mit Alexa in Bezug zum SF-Modul/Device?
Zitat von: DS_Starter am 05 Juli 2025, 20:30:30ZitatIch stelle wieder her: 76_SolarForecast.pm:v1.52.2-s29962/2025-05-14
Seitdem ist natürlich viel passiert, wobei wir mit Alexa nichts zu tun haben. Zumindest wüsste ich nicht wie es zustande kommen sollte.
Das einzige was in diesem Kontext vllt. relevant sein könnte ist ein Icon, was als Mouse-Over in der Grafik dazu gekommen ist (Screenshot). Wobei mir dennoch die Phantasie fehlt was das mit Alexa zu tun haben könnte.
Was machst du denn mit Alexa in Bezug zum SF-Modul/Device?
Das ist einfach zu beantworten: Nichts
Den Stein ins Rollen brachte am Dienstag die GöGa, weil Sie den TV nicht per Sprachbefehl einschalten konnte.
Ich begann zu suchen, und stelle fest, dass alexaFHEM nicht lief, und immer nach Mitternacht mit der genannten Fehlermeldung die Verbindung zum SSH-Dienst verliert.
Zitat von: Burny4600 am 05 Juli 2025, 14:31:46Hallo Heiko.
Ich denke, wenn eine weitere Auffächerung einmal möglich ist wie wir schon einmal angesprochen hatten, dann dürfte es mit der Übersicht kein Problem geben.
20 Consumer müssten eigentlich für den privaten Bereich mit größeren Anlagen ausreichen sein.
Hallo Heiko,
Nur ein kleiner Dekanstoß zu den 20 (und mehr?) Consumern (ca.75 Stromsensoren aktiv :) )
Ich nutze die Consumer einerseits zum visualisieren zum andern werden sie auch über SF gesteuert - für den ersten Typus müsste es meiner Ansicht nach nicht so viele Attribute geben - falls dir das hilft - das würde vielleicht auch Platz in der Grafik schaffen die wären ja nur als Schaltzustand mit aktueller Leistung darzustellen (ggfls. fix als fortlaufende NR) oder?
Gruß Gerd
@roadghost,
um weiterzukommen, schalte wie schon geschrieben die Backups aus: plantControl->backupFilesKeep=0
Und beobachte heute Nacht/morgen früh ob sich eine Änderung ergibt. Es sollten keine Backups der Konfiguration erstellt werden und demzufolge auch keine Löschungen/Bereinigungen.
Dann sieht man weiter ...
Zitat von: DS_Starter am 05 Juli 2025, 21:03:01@roadghost,
um weiterzukommen, schalte wie schon geschrieben die Backups aus: plantControl->backupFilesKeep=0
Und beobachte heute Nacht/morgen früh ob sich eine Änderung ergibt. Es sollten keine Backups der Konfiguration erstellt werden und demzufolge auch keine Löschungen/Bereinigungen.
Dann sieht man weiter ...
Das habe ich vorhin getestet - ledier negativ. Der Fehler tritt immer so gegen 00:xx Uhr auf, oder wenn ich fhem neu starte, somit kann ich das gut testen.
Spiele ich die aktuelle 76_SolarForecast ein, und mache einen Neustart, ist alexa FHEM nicht gestartet & nicht verbunden. Spiele ich die alte Verion wieder ein, ist alles OK.
ZitatDas habe ich vorhin getestet - ledier negativ. Der Fehler tritt immer so gegen 00:xx Uhr auf, oder wenn ich fhem neu starte, somit kann ich das gut testen.
Dann stelle Alexa doch mal auf ein höheres verbose damit man im Log etwas sieht. Ggf. auch SF-Device auf z.B. verbose 4 und dann poste mal den Log vom Start. Irgendeinen Anhaltspunkt braucht man. Zur Zeit gibt es keinen.
Ich habe SF und alexa auf verb 5 gesetzt, und einen shutdown restart gemacht:
2025.07.05 21:34:31.960 3: alexa: read: end of file reached while sysread
2025.07.05 21:34:31.961 3: alexa: stopped
2025.07.05 21:34:32.967 0: Server shutdown
2025.07.05 21:34:34 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 14.
2025.07.05 21:34:34 2: Perfmon: ready to watch out for delays greater than one second
2025.07.05 21:34:34.606 1: Including fhem.cfg
2025.07.05 21:34:34.610 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_goe_PV.pm line 14, <$fh> line 10.
2025.07.05 21:34:34.611 1: PERL WARNING: Subroutine GoEC_setPvSP redefined at ./FHEM/99_goe_PV.pm line 19, <$fh> line 10.
2025.07.05 21:34:34.715 3: WEB: port 8083 opened
2025.07.05 21:34:34.716 3: WEBphone: port 8084 opened
2025.07.05 21:34:34.717 3: WEBtablet: port 8085 opened
2025.07.05 21:34:34.844 2: eventTypes: loaded 11006 lines from ./log/eventTypes.txt
2025.07.05 21:34:35.184 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2025.07.05 21:34:35.184 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2025.07.05 21:34:35.185 3: MOBILEUI: new ext defined infix:mobile/: dir:./www/mobile/:
2025.07.05 21:34:35.185 3: Registering HTTPSRV MOBILEUI for URL /mobile and assigned link mobile/ ...
2025.07.05 21:34:35.203 1: HMLAN_Parse: HMUSB new condition disconnected
2025.07.05 21:34:35.580 3: Opening Rademacher device /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00PU21-if00-port0
2025.07.05 21:34:35.593 3: Setting Rademacher serial parameters to 115200,8,N,1
2025.07.05 21:34:35.597 3: Rademacher device opened
2025.07.05 21:34:35.633 2: Registering GEOFANCY geofancy for URL /geo...
2025.07.05 21:34:35.818 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2025.07.05 21:34:35.819 3: AMADBridge: port 8090 opened
2025.07.05 21:34:35.819 3: AMADCommBridge (AMADBridge) - Socket opened.
2025.07.05 21:34:35.843 3: AMADDevice (Wandtablet) - I/O device is AMADBridge
2025.07.05 21:34:35.844 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.07.05 21:34:35.844 3: AMADDevice (Wandtablet) - defined with AMAD_ID: 1511977959382 on port 8090
2025.07.05 21:34:35.844 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.07.05 21:34:36.102 3: Opening myJeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2025.07.05 21:34:36.104 3: Setting myJeeLink serial parameters to 57600,8,N,1
2025.07.05 21:34:37.107 3: myJeeLink device opened
2025.07.05 21:34:37.179 3: Garage_PV_R: Defined with URL ### and interval 30 featurelevel 6.4
2025.07.05 21:34:37.204 3: telnetPort: port 7072 opened
2025.07.05 21:34:37.241 3: Garage_PV_L: Defined with URL ### and interval 30 featurelevel 6.4
2025.07.05 21:34:37.335 3: Aussentemp: I/O device is myJeeLink
2025.07.05 21:34:37.408 3: GoECharger (myGoE) - defined GoECharger Device with Host 192.168.188.138 and Interval 60
2025.07.05 21:34:37.409 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.07.05 21:34:37.410 3: GoECharger (myGoE) - set interval to 60
2025.07.05 21:34:37.411 3: GoECharger (myGoE) - set interval to 60
2025.07.05 21:34:37.411 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.07.05 21:34:37.412 3: deletereading myGoE .* : Deleted reading Http_state for device myGoE
2025.07.05 21:34:40.943 3: PV_Prognose - cached data "pvHistory" restored
2025.07.05 21:34:40.946 3: PV_Prognose - cached data "pvCircular" restored
2025.07.05 21:34:40.948 3: PV_Prognose - cached data "radiationApiData" restored
2025.07.05 21:34:40.948 3: PV_Prognose - cached data "statusApiData" restored
2025.07.05 21:34:40.948 3: PV_Prognose - cached data "weatherApiData" restored
2025.07.05 21:34:40.980 3: PV_Prognose - cached data "aiTrainedData" restored
2025.07.05 21:34:40.990 3: PV_Prognose - cached data "aiRawData" restored
2025.07.05 21:34:41.055 1: Including ./log/fhem.save
2025.07.05 21:34:41.439 3: No I/O device found for IT_1527x0eed3
2025.07.05 21:34:41.441 3: No I/O device found for HMS100TF_0000
2025.07.05 21:34:41.443 3: No I/O device found for CUL_HOERMANN_09AFF60A20
2025.07.05 21:34:41.452 3: Opening HMUSB device 127.0.0.1:1234
2025.07.05 21:34:41.455 1: HMLAN_Parse: HMUSB new condition init
2025.07.05 21:34:41.457 3: HMUSB device opened
2025.07.05 21:34:42.643 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a ####################
2025.07.05 21:34:42.643 5: alexa: using /usr/local/bin/alexa-fhem
2025.07.05 21:34:42.650 3: alexa: starting
2025.07.05 21:34:42.672 3: alexa: using logfile: ./log/alexa-2025-07-05.log
2025.07.05 21:34:42.677 1: usb create starting
2025.07.05 21:34:42.747 3: Probing CUL device /dev/ttyS0
2025.07.05 21:34:42.748 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 613.
2025.07.05 21:34:42.748 1: CUL: Can't open /dev/ttyS0: Input/output error
2025.07.05 21:34:42.748 3: Probing CUL device /dev/ttyS1
2025.07.05 21:34:42.749 1: CUL: Can't open /dev/ttyS1: Input/output error
2025.07.05 21:34:42.749 3: Probing CUL device /dev/ttyS10
2025.07.05 21:34:42.749 1: CUL: Can't open /dev/ttyS10: Input/output error
2025.07.05 21:34:42.749 3: Probing CUL device /dev/ttyS11
2025.07.05 21:34:42.750 1: CUL: Can't open /dev/ttyS11: Input/output error
2025.07.05 21:34:42.750 3: Probing CUL device /dev/ttyS12
2025.07.05 21:34:42.750 1: CUL: Can't open /dev/ttyS12: Input/output error
2025.07.05 21:34:42.750 3: Probing CUL device /dev/ttyS13
2025.07.05 21:34:42.751 1: CUL: Can't open /dev/ttyS13: Input/output error
2025.07.05 21:34:42.751 3: Probing CUL device /dev/ttyS14
2025.07.05 21:34:42.751 1: CUL: Can't open /dev/ttyS14: Input/output error
2025.07.05 21:34:42.751 3: Probing CUL device /dev/ttyS15
2025.07.05 21:34:42.752 1: CUL: Can't open /dev/ttyS15: Input/output error
2025.07.05 21:34:42.752 3: Probing CUL device /dev/ttyS16
2025.07.05 21:34:42.752 1: CUL: Can't open /dev/ttyS16: Input/output error
2025.07.05 21:34:42.752 3: Probing CUL device /dev/ttyS17
2025.07.05 21:34:42.753 1: CUL: Can't open /dev/ttyS17: Input/output error
2025.07.05 21:34:42.753 3: Probing CUL device /dev/ttyS18
2025.07.05 21:34:42.753 1: CUL: Can't open /dev/ttyS18: Input/output error
2025.07.05 21:34:42.753 3: Probing CUL device /dev/ttyS19
2025.07.05 21:34:42.754 1: CUL: Can't open /dev/ttyS19: Input/output error
2025.07.05 21:34:42.754 3: Probing CUL device /dev/ttyS2
2025.07.05 21:34:42.754 1: CUL: Can't open /dev/ttyS2: Input/output error
2025.07.05 21:34:42.754 3: Probing CUL device /dev/ttyS20
2025.07.05 21:34:42.755 1: CUL: Can't open /dev/ttyS20: Input/output error
2025.07.05 21:34:42.755 3: Probing CUL device /dev/ttyS21
2025.07.05 21:34:42.755 1: CUL: Can't open /dev/ttyS21: Input/output error
2025.07.05 21:34:42.755 3: Probing CUL device /dev/ttyS22
2025.07.05 21:34:42.756 1: CUL: Can't open /dev/ttyS22: Input/output error
2025.07.05 21:34:42.756 3: Probing CUL device /dev/ttyS23
2025.07.05 21:34:42.756 1: CUL: Can't open /dev/ttyS23: Input/output error
2025.07.05 21:34:42.756 3: Probing CUL device /dev/ttyS24
2025.07.05 21:34:42.756 1: CUL: Can't open /dev/ttyS24: Input/output error
2025.07.05 21:34:42.757 3: Probing CUL device /dev/ttyS25
2025.07.05 21:34:42.757 1: CUL: Can't open /dev/ttyS25: Input/output error
2025.07.05 21:34:42.757 3: Probing CUL device /dev/ttyS26
2025.07.05 21:34:42.758 1: CUL: Can't open /dev/ttyS26: Input/output error
2025.07.05 21:34:42.758 3: Probing CUL device /dev/ttyS27
2025.07.05 21:34:42.758 1: CUL: Can't open /dev/ttyS27: Input/output error
2025.07.05 21:34:42.758 3: Probing CUL device /dev/ttyS28
2025.07.05 21:34:42.759 1: CUL: Can't open /dev/ttyS28: Input/output error
2025.07.05 21:34:42.759 3: Probing CUL device /dev/ttyS29
2025.07.05 21:34:42.759 1: CUL: Can't open /dev/ttyS29: Input/output error
2025.07.05 21:34:42.759 3: Probing CUL device /dev/ttyS3
2025.07.05 21:34:42.759 1: CUL: Can't open /dev/ttyS3: Input/output error
2025.07.05 21:34:42.760 3: Probing CUL device /dev/ttyS30
2025.07.05 21:34:42.760 1: CUL: Can't open /dev/ttyS30: Input/output error
2025.07.05 21:34:42.760 3: Probing CUL device /dev/ttyS31
2025.07.05 21:34:42.760 1: CUL: Can't open /dev/ttyS31: Input/output error
2025.07.05 21:34:42.761 3: Probing CUL device /dev/ttyS4
2025.07.05 21:34:42.761 1: CUL: Can't open /dev/ttyS4: Input/output error
2025.07.05 21:34:42.761 3: Probing CUL device /dev/ttyS5
2025.07.05 21:34:42.761 1: CUL: Can't open /dev/ttyS5: Input/output error
2025.07.05 21:34:42.762 3: Probing CUL device /dev/ttyS6
2025.07.05 21:34:42.762 1: CUL: Can't open /dev/ttyS6: Input/output error
2025.07.05 21:34:42.762 3: Probing CUL device /dev/ttyS7
2025.07.05 21:34:42.762 1: CUL: Can't open /dev/ttyS7: Input/output error
2025.07.05 21:34:42.763 3: Probing CUL device /dev/ttyS8
2025.07.05 21:34:42.763 1: CUL: Can't open /dev/ttyS8: Input/output error
2025.07.05 21:34:42.763 3: Probing CUL device /dev/ttyS9
2025.07.05 21:34:42.763 1: CUL: Can't open /dev/ttyS9: Input/output error
2025.07.05 21:34:42.771 1: usb create end
2025.07.05 21:34:42.806 0: Featurelevel: 6.4
2025.07.05 21:34:42.806 0: Server started with 337 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:3252)
2025.07.05 21:34:42.814 3: myBroker: port 2000 opened
2025.07.05 21:34:42.999 1: Perfmon: possible freeze starting at 21:34:35, delay is 7.999
2025.07.05 21:34:43.170 3: telnetForBlockingFn_1751744083.16966: port 42643 opened
2025.07.05 21:34:43.317 1: HMLAN_Parse: HMUSB new condition ok
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] using config from ./alexa-fhem.cfg
2025.07.05 21:34:43.367 5: alexa: read: *** CONFIG: parsed completely
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] os.homedir()=/opt/fhem
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] this is alexa-fhem 0.5.65
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] connecting to FHEM ...
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] [FHEM] defaults to: will not send proactive events
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] [FHEM] trying longpoll to listen for fhem events
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1751744082942
2025.07.05 21:34:43.375 3: The keys entered must not contain square brackets [...]
2025.07.05 21:34:43.376 3: The keys entered must not contain square brackets [...]
2025.07.05 21:34:43.376 3: The keys entered must not contain square brackets [...]
2025.07.05 21:34:43.382 3: PV_Prognose - all registered consumers collected
2025.07.05 21:34:43.388 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/76_SolarForecast.pm line 10090.
2025.07.05 21:34:43.388 1: PERL WARNING: Use of uninitialized value $pvounit in pattern match (m//) at ./FHEM/76_SolarForecast.pm line 10091.
2025.07.05 21:34:43.388 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4709.
2025.07.05 21:34:43.553 2: AttrTemplates: got 265 entries
2025.07.05 21:34:43.613 3: GoECharger (myGoE) - RequestERROR: http://192.168.188.138/status: empty answer received
2025.07.05 21:34:43.828 1: PERL WARNING: Use of uninitialized value $maxamp in concatenation (.) or string at ./FHEM/46_GoECharger.pm line 666.
2025.07.05 21:34:44.203 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.
2025.07.05 21:34:44.279 1: txt:72:len:354137,off:0 (hier musste ich kürzen, Zahlenfolge zu lang)
2025.07.05 21:34:44.299 1: stacktrace:
2025.07.05 21:34:44.299 1: main::TcpServer_WriteBlocking called by ./FHEM/01_FHEMWEB.pm (704)
2025.07.05 21:34:44.299 1: main::FW_initInform called by ./FHEM/01_FHEMWEB.pm (962)
2025.07.05 21:34:44.299 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (613)
2025.07.05 21:34:44.299 1: main::FW_Read called by fhem.pl (3988)
2025.07.05 21:34:44.300 1: main::CallFn called by fhem.pl (789)
2025.07.05 21:34:44.322 5: alexa: read: [5.7.2025, 21:34:44] [FHEM] longpoll error: Error: socket hang up, retry in: 5000msec
2025.07.05 21:34:44.322 5: alexa: read: *** FHEM: connection failed: Error: socket hang up
2025.07.05 21:34:44.328 1: PERL WARNING: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 841.
2025.07.05 21:34:44.330 1: PERL WARNING: Use of uninitialized value $calcphases in multiplication (*) at ./FHEM/46_GoECharger.pm line 951.
2025.07.05 21:34:44.338 5: alexa: read: [5.7.2025, 21:34:44] Got SIGTERM, shutting down alexa-fhem...
2025.07.05 21:34:44.338 5: alexa: read: [5.7.2025, 21:34:44] Reading alexaFHEM.ProxyConnection set to stopping;; alexa-fhem terminating
2025.07.05 21:34:44.342 3: alexa: read: end of file reached while sysread
2025.07.05 21:34:44.343 3: alexa: stopped
Könne das Thema eine Rolle spielen ?
https://forum.fhem.de/index.php?topic=61520.0
Was ich momentan sehe ist:
The keys entered must not contain square brackets [...]
Das hat fehlerhafte Definitionen in deinen Consumern. Poste bitte die Attribute consumerXX.
Das wird schärfer geprüft um Folgefehler zu vermeiden.
2025.07.05 21:34:43.388 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/76_SolarForecast.pm line 10090.
2025.07.05 21:34:43.388 1: PERL WARNING: Use of uninitialized value $pvounit in pattern match (m//) at ./FHEM/76_SolarForecast.pm line 10091.
Und wahrscheinlich noch Fehler in dem/den setupInverterDevXX. Poste die bitte auch noch.
Dann kommt
2025.07.05 21:34:43.613 3: GoECharger (myGoE) - RequestERROR: http://192.168.188.138/status: empty answer received
2025.07.05 21:34:43.828 1: PERL WARNING: Use of uninitialized value $maxamp in concatenation (.) or string at ./FHEM/46_GoECharger.pm line 666.
2025.07.05 21:34:44.203 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.
Der Wide character Fehler direkt nach der Warning im 46_GoECharger der vorher einen RequestERROR geworfen hat. Da scheint auch etwas nicht iO zu sein, entzieht sich aber meiner Kenntnis.
Hast du im global evtl. encoding=unicode eingestellt?
Das ist vermutlich die Ursache:
2025.07.05 21:34:44.322 5: alexa: read: [5.7.2025, 21:34:44] [FHEM] longpoll error: Error: socket hang up, retry in: 5000msec
Ein longpoll Fehler im FHEMWEB der wohl wiederum nur ein Folgefehler des "Wide character in syswrite at FHEM/TcpServerUtils.pm line 563" zu sein scheint.
Soweit das was ich sehen kann. Lass uns zunächst die Attribute von SF ansehen.
Edit:
ZitatKönne das Thema eine Rolle spielen ?
https://forum.fhem.de/index.php?topic=61520.0
Ja genau, gleiches Thema. Deswegen meine Vermutung bzgl. des Smiley-Icon.
Das wäre aber ein FHEMWEB-Thema, welches sich auch bei mir zeigen müsste, was nicht der Fall ist.
@roadghost,
ich habe prophylaktisch etwas bzgl. der erwähnten Icons geändert und dir die Version zum Test in mein contrib geladen. Lade sie die bitte herunter und restarte mit dieser Version.
Die Attribute müssen trotzdem noch berichtigt werden.
@Burny4600,
wir haben gestern dein Thema etwas aus den Augen verloren bzw. nicht weiterverfolgt.
Gibt es deinerseits weitere Erkenntnisse?
LG,
Heiko
ZitatPoste bitte die Attribute consumerXX.
Ich habe keine consumer definiert.
ZitatUnd wahrscheinlich noch Fehler in dem/den setupInverterDevXX. Poste die bitte auch noch.
setupInverterDev01
SH10rt_1_LAN pv=01_Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000 limit=70 [strings=South1,South2][icon=day[solar_icon]Night[solar_icon]]]
setupInverterDev02
Garage_PV_R pv=current_power-1:W etotal=total_yield-1:kWh capacity=580 limit=85 [strings=Garage_R][icon=day[solar_icon]Night[solar_icon]]]
setupInverterDev03
Garage_PV_L pv=current_power-1:W etotal=total_yield-1:kWh capacity=580 limit=85 [strings=Garage_L][icon=day[solar_icon]Night[solar_icon]]]ZitatHast du im global evtl. encoding=unicode eingestellt?
Habe ich geprüft, ist nicht eingestellt. Kein attr mit encoding.
Hi,
ja die setupInverterDevXX haben Fehler. Die eckigen Klammern schreibt man nicht, sondern sind eine Kennzeichnung für optionale Einstellungen und "icon" ist ganz falsch:
setupInverterDev01
SH10rt_1_LAN pv=01_Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000 limit=70 [strings=South1,South2][icon=day[solar_icon]Night[solar_icon]]]
Dein setupInverterDev01 würdest du richtig so definieren:
setupInverterDev01
SH10rt_1_LAN pv=01_Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000 limit=70 strings=South1,South2 icon=solar_icon:solar_icon
Für die anderen setupInverterDevXX gilt es gleichermaßen:
setupInverterDev02
Garage_PV_R pv=current_power-1:W etotal=total_yield-1:kWh capacity=580 limit=85 strings=Garage_R icon=solar_icon:solar_icon
setupInverterDev03
Garage_PV_L pv=current_power-1:W etotal=total_yield-1:kWh capacity=580 limit=85 strings=Garage_L icon=solar_icon:solar_icon
Wenn du die Attr korrigiert und gespeichert hast, kannst du gleich auf die aktuelle 1.54.0 updaten. Sie enthält dieselbe Ergänzung die ich dir gestern Abend noch bereitgestellt hatte. Nach dem Restart schauen wir nochmal auf das Log vom Start.
[quote]setupInverterDev01
SH10rt_1_LAN pv=01_Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000 limit=70 strings=South1,South2 icon=solar_icon:solar_icon
[/quote]
Das funktioniert leider nicht, ich muss pvIn und pvOut definieren, sonst erhalte ich die Meldung, dass die attribute fehlen
Für die anderen gleichermaßen.
Ja richtig, sorry. Das sind einige von den Änderungen die dazu gekommen sind.
Es können nun verschiedene Wechselricher Typen eingerichtet werden. Normale WR so:
setupInverterDev01
SH10rt_1_LAN pvOut=01_Total_DC_Power:W etotal=Total_PV_Generation:kWh capacity=8000 limit=70 strings=South1,South2 icon=solar_icon:solar_icon
pvIn ist optional und muß nicht gesetzt werden.
Hier einer meiner WR Definitionen zum Vergleich:
setupInverterDev01
STP_5000 strings=Süddach etotal=etotal:kWh pvIn=string_1_pdc:kW pvOut=total_pac:kW capacity=5000
Ich habe die SetupInvertder Dev 1 bis 3 angepasst, aktuelle Version installiert.
Bei einem Neustart erhalte ich noch identische Fehlermeldung im FEHM log, und alexa FHEM startet nicht von selber. Endet im socket hangup.
Das attribut plantControl backupFilesKeep=0 habe ich wieder gelöscht, um zu sehen, was heute Nacht passiert.
Wie ich jetzt den eigentlichen Fehler ausmerzen kann ? Kein Plan - so tief sind meine Kenntnisse bei weitem nicht.
Ich nehme die besagten Icons raus und stelle dir gleich ein Version in meinem contrib zum Test bereit.
Es jetzt eine reine Vermutung, aber etwas anderes was in irgendeiner Weise mit "Wide character" zu tun haben könnte, fällt mir beim Besten Willen nicht ein.
Die V 1.54.1 liegt in meinem contrib (Link siehe Fußtext). Suche dort die 76_SolarForecast.pm und lade sie mit dem Downloadbottom in dein Verzeichnis ../FHEM wo alle anderen Moduldateien auch liegen.
Dann restarten.
Ich habe mich die ganze Zeit gefragt wo die Verbindung zwischen SF und alexa ist. Nun ist mir der Start eines dauerhaften longpoll ins Auge gefallen:
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1751744082942
alexa wird über alle (globale) Änderungs-Events ungefiltert benachrichtigt. Dadurch kommen auch die Informationen von SF über den longpoll zu alexa. Wide Character sind da natürlich vorher zu encoden, sonst geht das schief.
Zitat von: DS_Starter am 06 Juli 2025, 09:59:28... wir haben gestern dein Thema etwas aus den Augen verloren....
Hallo Heiko, Ich bin mit diesem Problem nicht weiter gekommen.
Eine Eigenart habe ich aber noch gefunden.
Ich habe zusätzlich einen Consumer 08 mit den gleichen Daten angelegt wie den Consumer 07.
Diesesmal wurde die Änderung des Consumer 07 übernommen, aber dafür hat der Consumer 08 seine Defintion nicht behalten, sondern den alten Inhalt von Consumer 07 übernommen.
Irgendwie dürfte das Problem am Attribut ctrlUserExitFn liegen.
Das ist sehr dubios.
:o , ich versuche es mal bei mir mit Dummies nachzustellen.
Hallo Heiko,
mit der neuesten Version von heute Früh habe ich in den Balkengrafiken sehr unterschiedlich breite Balken. Vermutlich liegt die Ursache in der Anzeige der Differenz mit einer Nachkommastelle. Siehe auch den Screenshot anbei.
Magst du da bei Gelegenheit mal bitte nachschauen?
Vielen Dank und viele Grüße,
Peter
Zitat von: DS_Starter am 06 Juli 2025, 13:45:09Die V 1.54.1 liegt in meinem contrib (Link siehe Fußtext). Suche dort die 76_SolarForecast.pm und lade sie mit dem Downloadbottom in dein Verzeichnis ../FHEM wo alle anderen Moduldateien auch liegen.
Dann restarten.
Habe ich soeben geladen, Dateiberechtigungen gesetzt, Dateibesitzer auf fhem dialout angepasst, dann shutdown restart.
Hier das FHEM log:
2025.07.06 15:37:26.864 3: alexa: read: end of file reached while sysread
2025.07.06 15:37:26.865 3: alexa: stopped
2025.07.06 15:37:27.870 0: Server shutdown
2025.07.06 15:37:29 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 14.
2025.07.06 15:37:29 2: Perfmon: ready to watch out for delays greater than one second
2025.07.06 15:37:29.601 1: Including fhem.cfg
2025.07.06 15:37:29.605 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_goe_PV.pm line 14, <$fh> line 10.
2025.07.06 15:37:29.605 1: PERL WARNING: Subroutine GoEC_setPvSP redefined at ./FHEM/99_goe_PV.pm line 19, <$fh> line 10.
2025.07.06 15:37:29.710 3: WEB: port 8083 opened
2025.07.06 15:37:29.711 3: WEBphone: port 8084 opened
2025.07.06 15:37:29.712 3: WEBtablet: port 8085 opened
2025.07.06 15:37:29.839 2: eventTypes: loaded 11027 lines from ./log/eventTypes.txt
2025.07.06 15:37:30.178 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2025.07.06 15:37:30.178 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2025.07.06 15:37:30.179 3: MOBILEUI: new ext defined infix:mobile/: dir:./www/mobile/:
2025.07.06 15:37:30.179 3: Registering HTTPSRV MOBILEUI for URL /mobile and assigned link mobile/ ...
2025.07.06 15:37:30.197 1: HMLAN_Parse: HMUSB new condition disconnected
2025.07.06 15:37:30.573 3: Opening Rademacher device /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00PU21-if00-port0
2025.07.06 15:37:30.587 3: Setting Rademacher serial parameters to 115200,8,N,1
2025.07.06 15:37:30.590 3: Rademacher device opened
2025.07.06 15:37:30.628 2: Registering GEOFANCY geofancy for URL /geo...
2025.07.06 15:37:30.814 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2025.07.06 15:37:30.814 3: AMADBridge: port 8090 opened
2025.07.06 15:37:30.815 3: AMADCommBridge (AMADBridge) - Socket opened.
2025.07.06 15:37:30.839 3: AMADDevice (Wandtablet) - I/O device is AMADBridge
2025.07.06 15:37:30.839 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.07.06 15:37:30.839 3: AMADDevice (Wandtablet) - defined with AMAD_ID: 1511977959382 on port 8090
2025.07.06 15:37:30.840 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.07.06 15:37:31.098 3: Opening myJeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2025.07.06 15:37:31.100 3: Setting myJeeLink serial parameters to 57600,8,N,1
2025.07.06 15:37:32.104 3: myJeeLink device opened
2025.07.06 15:37:32.176 3: Garage_PV_R: Defined with URL ## and interval 30 featurelevel 6.4
2025.07.06 15:37:32.202 3: telnetPort: port 7072 opened
2025.07.06 15:37:32.238 3: Garage_PV_L: Defined with URL ## and interval 30 featurelevel 6.4
2025.07.06 15:37:32.331 3: Aussentemp: I/O device is myJeeLink
2025.07.06 15:37:32.404 3: GoECharger (myGoE) - defined GoECharger Device with Host 192.168.188.138 and Interval 60
2025.07.06 15:37:32.405 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.07.06 15:37:32.405 3: GoECharger (myGoE) - set interval to 60
2025.07.06 15:37:32.407 3: GoECharger (myGoE) - set interval to 60
2025.07.06 15:37:32.407 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.07.06 15:37:32.407 3: deletereading myGoE .* : Deleted reading Http_state for device myGoE
2025.07.06 15:37:35.966 3: PV_Prognose - cached data "pvHistory" restored
2025.07.06 15:37:35.969 3: PV_Prognose - cached data "pvCircular" restored
2025.07.06 15:37:35.970 3: PV_Prognose - cached data "radiationApiData" restored
2025.07.06 15:37:35.970 3: PV_Prognose - cached data "statusApiData" restored
2025.07.06 15:37:35.970 3: PV_Prognose - cached data "weatherApiData" restored
2025.07.06 15:37:36.003 3: PV_Prognose - cached data "aiTrainedData" restored
2025.07.06 15:37:36.013 3: PV_Prognose - cached data "aiRawData" restored
2025.07.06 15:37:36.078 1: Including ./log/fhem.save
2025.07.06 15:37:36.465 3: No I/O device found for HMS100TF_0000
2025.07.06 15:37:36.467 3: No I/O device found for IT_1527x0eed3
2025.07.06 15:37:36.469 3: No I/O device found for CUL_HOERMANN_09AFF60A20
2025.07.06 15:37:36.479 3: Opening HMUSB device 127.0.0.1:1234
2025.07.06 15:37:36.481 1: HMLAN_Parse: HMUSB new condition init
2025.07.06 15:37:36.483 3: HMUSB device opened
2025.07.06 15:37:37.756 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a ##
2025.07.06 15:37:37.756 5: alexa: using /usr/local/bin/alexa-fhem
2025.07.06 15:37:37.762 3: alexa: starting
2025.07.06 15:37:37.785 3: alexa: using logfile: ./log/alexa-2025-07-06.log
2025.07.06 15:37:37.790 1: usb create starting
2025.07.06 15:37:37.856 3: Probing CUL device /dev/ttyS0
2025.07.06 15:37:37.856 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 613.
2025.07.06 15:37:37.856 1: CUL: Can't open /dev/ttyS0: Input/output error
2025.07.06 15:37:37.857 3: Probing CUL device /dev/ttyS1
2025.07.06 15:37:37.857 1: CUL: Can't open /dev/ttyS1: Input/output error
2025.07.06 15:37:37.857 3: Probing CUL device /dev/ttyS10
2025.07.06 15:37:37.858 1: CUL: Can't open /dev/ttyS10: Input/output error
2025.07.06 15:37:37.858 3: Probing CUL device /dev/ttyS11
2025.07.06 15:37:37.858 1: CUL: Can't open /dev/ttyS11: Input/output error
2025.07.06 15:37:37.858 3: Probing CUL device /dev/ttyS12
2025.07.06 15:37:37.859 1: CUL: Can't open /dev/ttyS12: Input/output error
2025.07.06 15:37:37.859 3: Probing CUL device /dev/ttyS13
2025.07.06 15:37:37.859 1: CUL: Can't open /dev/ttyS13: Input/output error
2025.07.06 15:37:37.859 3: Probing CUL device /dev/ttyS14
2025.07.06 15:37:37.860 1: CUL: Can't open /dev/ttyS14: Input/output error
2025.07.06 15:37:37.860 3: Probing CUL device /dev/ttyS15
2025.07.06 15:37:37.860 1: CUL: Can't open /dev/ttyS15: Input/output error
2025.07.06 15:37:37.860 3: Probing CUL device /dev/ttyS16
2025.07.06 15:37:37.861 1: CUL: Can't open /dev/ttyS16: Input/output error
2025.07.06 15:37:37.861 3: Probing CUL device /dev/ttyS17
2025.07.06 15:37:37.861 1: CUL: Can't open /dev/ttyS17: Input/output error
2025.07.06 15:37:37.861 3: Probing CUL device /dev/ttyS18
2025.07.06 15:37:37.862 1: CUL: Can't open /dev/ttyS18: Input/output error
2025.07.06 15:37:37.862 3: Probing CUL device /dev/ttyS19
2025.07.06 15:37:37.862 1: CUL: Can't open /dev/ttyS19: Input/output error
2025.07.06 15:37:37.862 3: Probing CUL device /dev/ttyS2
2025.07.06 15:37:37.863 1: CUL: Can't open /dev/ttyS2: Input/output error
2025.07.06 15:37:37.863 3: Probing CUL device /dev/ttyS20
2025.07.06 15:37:37.863 1: CUL: Can't open /dev/ttyS20: Input/output error
2025.07.06 15:37:37.863 3: Probing CUL device /dev/ttyS21
2025.07.06 15:37:37.864 1: CUL: Can't open /dev/ttyS21: Input/output error
2025.07.06 15:37:37.864 3: Probing CUL device /dev/ttyS22
2025.07.06 15:37:37.864 1: CUL: Can't open /dev/ttyS22: Input/output error
2025.07.06 15:37:37.864 3: Probing CUL device /dev/ttyS23
2025.07.06 15:37:37.864 1: CUL: Can't open /dev/ttyS23: Input/output error
2025.07.06 15:37:37.865 3: Probing CUL device /dev/ttyS24
2025.07.06 15:37:37.865 1: CUL: Can't open /dev/ttyS24: Input/output error
2025.07.06 15:37:37.865 3: Probing CUL device /dev/ttyS25
2025.07.06 15:37:37.865 1: CUL: Can't open /dev/ttyS25: Input/output error
2025.07.06 15:37:37.866 3: Probing CUL device /dev/ttyS26
2025.07.06 15:37:37.866 1: CUL: Can't open /dev/ttyS26: Input/output error
2025.07.06 15:37:37.866 3: Probing CUL device /dev/ttyS27
2025.07.06 15:37:37.866 1: CUL: Can't open /dev/ttyS27: Input/output error
2025.07.06 15:37:37.867 3: Probing CUL device /dev/ttyS28
2025.07.06 15:37:37.867 1: CUL: Can't open /dev/ttyS28: Input/output error
2025.07.06 15:37:37.867 3: Probing CUL device /dev/ttyS29
2025.07.06 15:37:37.867 1: CUL: Can't open /dev/ttyS29: Input/output error
2025.07.06 15:37:37.868 3: Probing CUL device /dev/ttyS3
2025.07.06 15:37:37.868 1: CUL: Can't open /dev/ttyS3: Input/output error
2025.07.06 15:37:37.868 3: Probing CUL device /dev/ttyS30
2025.07.06 15:37:37.868 1: CUL: Can't open /dev/ttyS30: Input/output error
2025.07.06 15:37:37.869 3: Probing CUL device /dev/ttyS31
2025.07.06 15:37:37.869 1: CUL: Can't open /dev/ttyS31: Input/output error
2025.07.06 15:37:37.869 3: Probing CUL device /dev/ttyS4
2025.07.06 15:37:37.869 1: CUL: Can't open /dev/ttyS4: Input/output error
2025.07.06 15:37:37.870 3: Probing CUL device /dev/ttyS5
2025.07.06 15:37:37.870 1: CUL: Can't open /dev/ttyS5: Input/output error
2025.07.06 15:37:37.870 3: Probing CUL device /dev/ttyS6
2025.07.06 15:37:37.870 1: CUL: Can't open /dev/ttyS6: Input/output error
2025.07.06 15:37:37.871 3: Probing CUL device /dev/ttyS7
2025.07.06 15:37:37.871 1: CUL: Can't open /dev/ttyS7: Input/output error
2025.07.06 15:37:37.871 3: Probing CUL device /dev/ttyS8
2025.07.06 15:37:37.871 1: CUL: Can't open /dev/ttyS8: Input/output error
2025.07.06 15:37:37.872 3: Probing CUL device /dev/ttyS9
2025.07.06 15:37:37.872 1: CUL: Can't open /dev/ttyS9: Input/output error
2025.07.06 15:37:37.880 1: usb create end
2025.07.06 15:37:37.915 0: Featurelevel: 6.4
2025.07.06 15:37:37.916 0: Server started with 337 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:4009)
2025.07.06 15:37:37.923 3: myBroker: port 2000 opened
2025.07.06 15:37:38.110 1: Perfmon: possible freeze starting at 15:37:30, delay is 8.11
2025.07.06 15:37:38.279 3: telnetForBlockingFn_1751809058.27884: port 40987 opened
2025.07.06 15:37:38.472 1: HMLAN_Parse: HMUSB new condition ok
2025.07.06 15:37:38.477 5: alexa: read: [6.7.2025, 15:37:37] using config from ./alexa-fhem.cfg
2025.07.06 15:37:38.477 5: alexa: read: *** CONFIG: parsed completely
2025.07.06 15:37:38.477 5: alexa: read: [6.7.2025, 15:37:37] os.homedir()=/opt/fhem
2025.07.06 15:37:38.477 5: alexa: read: [6.7.2025, 15:37:37] this is alexa-fhem 0.5.65
2025.07.06 15:37:38.477 5: alexa: read: [6.7.2025, 15:37:37] connecting to FHEM ...
2025.07.06 15:37:38.477 5: alexa: read: [6.7.2025, 15:37:37] [FHEM] defaults to: will not send proactive events
2025.07.06 15:37:38.477 5: alexa: read: [6.7.2025, 15:37:38] [FHEM] trying longpoll to listen for fhem events
2025.07.06 15:37:38.477 5: alexa: read: [6.7.2025, 15:37:38] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1751809058051
2025.07.06 15:37:38.489 3: PV_Prognose - all registered consumers collected
2025.07.06 15:37:38.714 2: AttrTemplates: got 265 entries
2025.07.06 15:37:38.759 1: PERL WARNING: Use of uninitialized value $maxamp in concatenation (.) or string at ./FHEM/46_GoECharger.pm line 666.
2025.07.06 15:37:38.798 3: GoECharger (myGoE) - RequestERROR: http://192.168.188.138/status: empty answer received
2025.07.06 15:37:39.351 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.
2025.07.06 15:37:39.434 1: txt:######################## gekürzt
2025.07.06 15:37:39.455 1: stacktrace:
2025.07.06 15:37:39.455 1: main::TcpServer_WriteBlocking called by ./FHEM/01_FHEMWEB.pm (704)
2025.07.06 15:37:39.455 1: main::FW_initInform called by ./FHEM/01_FHEMWEB.pm (962)
2025.07.06 15:37:39.455 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (613)
2025.07.06 15:37:39.455 1: main::FW_Read called by fhem.pl (3988)
2025.07.06 15:37:39.455 1: main::CallFn called by fhem.pl (789)
2025.07.06 15:37:39.469 1: PERL WARNING: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 841.
2025.07.06 15:37:39.469 1: PERL WARNING: Use of uninitialized value $calcphases in multiplication (*) at ./FHEM/46_GoECharger.pm line 951.
2025.07.06 15:37:39.483 5: alexa: read: [6.7.2025, 15:37:39] [FHEM] longpoll error: Error: socket hang up, retry in: 5000msec
2025.07.06 15:37:39.483 5: alexa: read: *** FHEM: connection failed: Error: socket hang up
2025.07.06 15:37:39.534 5: alexa: read: [6.7.2025, 15:37:39] Got SIGTERM, shutting down alexa-fhem...
2025.07.06 15:37:39.534 5: alexa: read: [6.7.2025, 15:37:39] Reading alexaFHEM.ProxyConnection set to stopping;; alexa-fhem terminating
2025.07.06 15:37:39.535 3: alexa: read: end of file reached while sysread
2025.07.06 15:37:39.535 3: alexa: stopped
Zitat von: DS_Starter am 06 Juli 2025, 14:33:13Ich habe mich die ganze Zeit gefragt wo die Verbindung zwischen SF und alexa ist. Nun ist mir der Start eines dauerhaften longpoll ins Auge gefallen:
2025.07.05 21:34:43.367 5: alexa: read: [5.7.2025, 21:34:42] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1751744082942
alexa wird über alle (globale) Änderungs-Events ungefiltert benachrichtigt. Dadurch kommen auch die Informationen von SF über den longpoll zu alexa. Wide Character sind da natürlich vorher zu encoden, sonst geht das schief.
Muss ich hier etwas anpassen ?
Nein, da kannst du nichts machen. Man muß auf Wide Character (z.B. Smileys) verzichten oder intern UTF-8 kodieren.
Tja, die Smileys sind jetzt raus und trotzdem scheint noch ein Problem bei dir zu bestehen.
Da fällt mir gerade nichts mehr dazu ein, Browser Cache mal geleert?
ZitatVermutlich liegt die Ursache in der Anzeige der Differenz mit einer Nachkommastelle.
Ja, die macht die Zahl breiter.
Zitat von: DS_Starter am 06 Juli 2025, 15:51:18Browser Cache mal geleert?
Habe ich geleert, auch mit FF, Edge und Chrome probiert.
Die Eckigen Klammern in meinen DEV waren sicherlich falsch, aber dass alexaFHEM nach einem Neusart von FHEM nicht startet, hatte ich bisher nie. Im Unterforum von alexaFHEM ist man auch, na ja, etwas ratlos. Normalerweise soll der alexaFHEM dienst auch eigenständig neu starten, wenn die SSH Verbindung verloren ging, oder der Dienst die Verbindung zum FHEMCONNECTOR verloren hat.
Auch dies funktioniert mit dem aktuellen Update nicht mehr.
Wenn ich Daten / INfo´s bereitstellen kann, die Helfen, bitte bescheid geben was benötigt wird.
Ich weiß nicht wen man sonst noch fragen könnte, da ja, soweit ich das verstehe, SF und FHEMWEB involviert sind. Du betreust ja SF, und wer ist verantwortlich für FHEMWEB ? Eventuell sehen 12 Augen mehr .... ??
FHEMWEB betreut Rudolph König. Hat mit FHEMWEB aber nichts zu tun, sonst hätte jeder von uns doch recht vielen SF Usern das Problem. Nein, das ist ein alexa Thema bzgl. des gestarteten longpoll.
Die Wide Character waren eine heiße Spur, aber die sind ja raus und nur diese sind seit der V 1.52.2 hineingekommen.
Echt schwierig.
Du kannst noch versuchen den Eventmonitor beim Start mitlaufen zu lassen und zu schauen ob zu Events (egal von welchem Device) findest die Wide Character (also wie Smileys oder auch nicht druckbare, kryptische Zeichen) enthalten.
@all,
hat sonst noch jemand von euch SF + alexa laufen?
Zitat von: DS_Starter am 06 Juli 2025, 16:12:34Du kannst noch versuchen den Eventmonitor beim Start mitlaufen zu lassen und zu schauen ob zu Events (egal von welchem Device) findest die Wide Character (also wie Smileys oder auch nicht druckbare, kryptische Zeichen) enthalten.
Eventmonitoreinträge:
2025-07-06 16:20:08.933 DUOFERN DUO_Bad dawnAutomatic: off
2025-07-06 16:20:08.942 ModbusAttr SH10rt_1_LAN 05_Einspeisung: 12 W
2025-07-06 16:20:15.031 LaCrosse Aussentemp battery: okFHEM log
2025.07.06 16:20:08.203 0: Server started with 336 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:5044)
2025.07.06 16:20:08.210 3: myBroker: port 2000 opened
2025.07.06 16:20:08.399 1: Perfmon: possible freeze starting at 16:20:00, delay is 8.399
2025.07.06 16:20:08.566 3: telnetForBlockingFn_1751811608.56598: port 37117 opened
2025.07.06 16:20:08.771 1: HMLAN_Parse: HMUSB new condition ok
2025.07.06 16:20:08.922 3: GoECharger (myGoE) - RequestERROR: http://192.168.188.138/status: empty answer received
2025.07.06 16:20:09.024 2: AttrTemplates: got 265 entries
2025.07.06 16:20:09.437 1: PERL WARNING: Use of uninitialized value $maxamp in concatenation (.) or string at ./FHEM/46_GoECharger.pm line 666.
2025.07.06 16:20:09.610 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.
2025.07.06 16:20:09.692 1: ######## gekürzt #######
2025.07.06 16:20:09.720 1: stacktrace:
2025.07.06 16:20:09.723 1: main::TcpServer_WriteBlocking called by ./FHEM/01_FHEMWEB.pm (704)
2025.07.06 16:20:09.723 1: main::FW_initInform called by ./FHEM/01_FHEMWEB.pm (962)
2025.07.06 16:20:09.723 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (613)
2025.07.06 16:20:09.723 1: main::FW_Read called by fhem.pl (3988)
2025.07.06 16:20:09.723 1: main::CallFn called by fhem.pl (789)
2025.07.06 16:20:09.760 1: PERL WARNING: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 841.
2025.07.06 16:20:09.763 1: PERL WARNING: Use of uninitialized value $calcphases in multiplication (*) at ./FHEM/46_GoECharger.pm line 951.
2025.07.06 16:20:20.807 3: ABFALL myAbfall - CALENDAR:Abfall triggered, updating ABFALL myAbfall ...
Leider keinen Eintrag im Eventlog zum Zeitpunkt des Fehlers im FHEM log gefunden.
Wir können höchstens so vorgehen, dass ich dir die Versionen ab 1.53.2 etappenweise ins contrib stelle und du sie testest. Irgendwann von einer V zur nächsten kommt das Problem und evtl. fällt mir dann noch etwas ein.
Du hattest die 1.53.2 als letzte V, richtig?
Möchstest du diesen Aufwand mit mir betreiben?
Zitat von: DS_Starter am 06 Juli 2025, 16:12:34@all,
hat sonst noch jemand von euch SF + alexa laufen?
Läuft bei mir auch beides.
Soll ich was bestimmtes testen?
Viele Grüße,
Peter
Zitat von: DS_Starter am 06 Juli 2025, 16:31:51Wir können höchstens so vorgehen, dass ich dir die Versionen ab 1.53.2 etappenweise ins contrib stelle und du sie testest. Irgendwann von einer V zur nächsten kommt das Problem und evtl. fällt mir dann noch etwas ein.
Du hattest die 1.53.2 als letzte V, richtig?
Möchstest du diesen Aufwand mit mir betreiben?
Klar - können wir gern so machen.
Letzte definitiv Funktionierende: Am bzw. ab dem 22.05.25 (letztes Backup von FHEM was ich habe)
Ich habe am 02.07.25 ein update gemacht, und das hat den Fehler "einschleichen lassen" - also die Versionen zwischen dem 22.05 und dem 01.07 sind die Kandidaten. Wie viele sind das ?
@Peter, du bist jetzt unsere Hoffnung :)
Naja zunächst mal scheint alexa mit SF in der aktuellen Version zusammen bei dir zu laufen und keinen Stress zu haben?
Schau dir mal das Start-Log von roadghost, insbesondere "Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.".
Hast du solche Einträge?
@roadghost, Im contrib liegt jetzt die V 1.52.11 zum Test
Zitat von: DS_Starter am 06 Juli 2025, 16:41:34@roadghost, Im contrib liegt jetzt die V 1.52.11 zum Test
Diese Version funktioniert.
FHEM log:
2025.07.06 17:00:06.757 1: Server shutdown delayed due to alexa for max 10 sec
2025.07.06 17:00:08.781 0: Server shutdown
2025.07.06 17:00:10 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 14.
2025.07.06 17:00:10 2: Perfmon: ready to watch out for delays greater than one second
2025.07.06 17:00:10.349 1: Including fhem.cfg
2025.07.06 17:00:10.353 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_goe_PV.pm line 14, <$fh> line 10.
2025.07.06 17:00:10.353 1: PERL WARNING: Subroutine GoEC_setPvSP redefined at ./FHEM/99_goe_PV.pm line 19, <$fh> line 10.
2025.07.06 17:00:10.458 3: WEB: port 8083 opened
2025.07.06 17:00:10.460 3: WEBphone: port 8084 opened
2025.07.06 17:00:10.460 3: WEBtablet: port 8085 opened
2025.07.06 17:00:10.587 2: eventTypes: loaded 10837 lines from ./log/eventTypes.txt
2025.07.06 17:00:10.922 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2025.07.06 17:00:10.922 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2025.07.06 17:00:10.924 3: MOBILEUI: new ext defined infix:mobile/: dir:./www/mobile/:
2025.07.06 17:00:10.924 3: Registering HTTPSRV MOBILEUI for URL /mobile and assigned link mobile/ ...
2025.07.06 17:00:10.943 1: HMLAN_Parse: HMUSB new condition disconnected
2025.07.06 17:00:11.321 3: Opening Rademacher device /dev/serial/by-id/usb-Rademacher_DuoFern_USB-Stick_WR00PU21-if00-port0
2025.07.06 17:00:11.335 3: Setting Rademacher serial parameters to 115200,8,N,1
2025.07.06 17:00:11.338 3: Rademacher device opened
2025.07.06 17:00:11.374 2: Registering GEOFANCY geofancy for URL /geo...
2025.07.06 17:00:11.560 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2025.07.06 17:00:11.560 3: AMADBridge: port 8090 opened
2025.07.06 17:00:11.561 3: AMADCommBridge (AMADBridge) - Socket opened.
2025.07.06 17:00:11.584 3: AMADDevice (Wandtablet) - I/O device is AMADBridge
2025.07.06 17:00:11.585 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.07.06 17:00:11.585 3: AMADDevice (Wandtablet) - defined with AMAD_ID: 1511977959382 on port 8090
2025.07.06 17:00:11.585 3: AMADDevice (Wandtablet) - set remoteServer to Automagic
2025.07.06 17:00:11.847 3: Opening myJeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2025.07.06 17:00:11.849 3: Setting myJeeLink serial parameters to 57600,8,N,1
2025.07.06 17:00:12.851 3: myJeeLink device opened
2025.07.06 17:00:12.923 3: Garage_PV_R: Defined with URL # and interval 30 featurelevel 6.4
2025.07.06 17:00:12.949 3: telnetPort: port 7072 opened
2025.07.06 17:00:12.986 3: Garage_PV_L: Defined with URL # and interval 30 featurelevel 6.4
2025.07.06 17:00:13.077 3: Aussentemp: I/O device is myJeeLink
2025.07.06 17:00:13.151 3: GoECharger (myGoE) - defined GoECharger Device with Host 192.168.188.138 and Interval 60
2025.07.06 17:00:13.152 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.07.06 17:00:13.152 3: GoECharger (myGoE) - set interval to 60
2025.07.06 17:00:13.154 3: GoECharger (myGoE) - set interval to 60
2025.07.06 17:00:13.154 3: GoECharger (myGoE) - set kW_measured_corr_value to 1.00
2025.07.06 17:00:13.154 3: deletereading myGoE .* : Deleted reading Http_state for device myGoE
2025.07.06 17:00:16.712 3: PV_Prognose - cached data "pvHistory" restored
2025.07.06 17:00:16.715 3: PV_Prognose - cached data "pvCircular" restored
2025.07.06 17:00:16.716 3: PV_Prognose - cached data "radiationApiData" restored
2025.07.06 17:00:16.716 3: PV_Prognose - cached data "statusApiData" restored
2025.07.06 17:00:16.717 3: PV_Prognose - cached data "weatherApiData" restored
2025.07.06 17:00:16.749 3: PV_Prognose - cached data "aiTrainedData" restored
2025.07.06 17:00:16.759 3: PV_Prognose - cached data "aiRawData" restored
2025.07.06 17:00:16.824 1: Including ./log/fhem.save
2025.07.06 17:00:17.213 3: No I/O device found for CUL_HOERMANN_09AFF60A20
2025.07.06 17:00:17.215 3: No I/O device found for IT_1527x0eed3
2025.07.06 17:00:17.217 3: No I/O device found for HMS100TF_0000
2025.07.06 17:00:17.227 3: Opening HMUSB device 127.0.0.1:1234
2025.07.06 17:00:17.229 1: HMLAN_Parse: HMUSB new condition init
2025.07.06 17:00:17.231 3: HMUSB device opened
2025.07.06 17:00:18.549 1: usb create starting
2025.07.06 17:00:18.622 3: Probing CUL device /dev/ttyS0
2025.07.06 17:00:18.623 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 613.
2025.07.06 17:00:18.623 1: CUL: Can't open /dev/ttyS0: Input/output error
2025.07.06 17:00:18.623 3: Probing CUL device /dev/ttyS1
2025.07.06 17:00:18.624 1: CUL: Can't open /dev/ttyS1: Input/output error
2025.07.06 17:00:18.624 3: Probing CUL device /dev/ttyS10
2025.07.06 17:00:18.624 1: CUL: Can't open /dev/ttyS10: Input/output error
2025.07.06 17:00:18.624 3: Probing CUL device /dev/ttyS11
2025.07.06 17:00:18.625 1: CUL: Can't open /dev/ttyS11: Input/output error
2025.07.06 17:00:18.625 3: Probing CUL device /dev/ttyS12
2025.07.06 17:00:18.625 1: CUL: Can't open /dev/ttyS12: Input/output error
2025.07.06 17:00:18.625 3: Probing CUL device /dev/ttyS13
2025.07.06 17:00:18.626 1: CUL: Can't open /dev/ttyS13: Input/output error
2025.07.06 17:00:18.626 3: Probing CUL device /dev/ttyS14
2025.07.06 17:00:18.626 1: CUL: Can't open /dev/ttyS14: Input/output error
2025.07.06 17:00:18.626 3: Probing CUL device /dev/ttyS15
2025.07.06 17:00:18.627 1: CUL: Can't open /dev/ttyS15: Input/output error
2025.07.06 17:00:18.627 3: Probing CUL device /dev/ttyS16
2025.07.06 17:00:18.627 1: CUL: Can't open /dev/ttyS16: Input/output error
2025.07.06 17:00:18.627 3: Probing CUL device /dev/ttyS17
2025.07.06 17:00:18.628 1: CUL: Can't open /dev/ttyS17: Input/output error
2025.07.06 17:00:18.628 3: Probing CUL device /dev/ttyS18
2025.07.06 17:00:18.628 1: CUL: Can't open /dev/ttyS18: Input/output error
2025.07.06 17:00:18.628 3: Probing CUL device /dev/ttyS19
2025.07.06 17:00:18.629 1: CUL: Can't open /dev/ttyS19: Input/output error
2025.07.06 17:00:18.629 3: Probing CUL device /dev/ttyS2
2025.07.06 17:00:18.629 1: CUL: Can't open /dev/ttyS2: Input/output error
2025.07.06 17:00:18.629 3: Probing CUL device /dev/ttyS20
2025.07.06 17:00:18.630 1: CUL: Can't open /dev/ttyS20: Input/output error
2025.07.06 17:00:18.630 3: Probing CUL device /dev/ttyS21
2025.07.06 17:00:18.630 1: CUL: Can't open /dev/ttyS21: Input/output error
2025.07.06 17:00:18.630 3: Probing CUL device /dev/ttyS22
2025.07.06 17:00:18.631 1: CUL: Can't open /dev/ttyS22: Input/output error
2025.07.06 17:00:18.631 3: Probing CUL device /dev/ttyS23
2025.07.06 17:00:18.631 1: CUL: Can't open /dev/ttyS23: Input/output error
2025.07.06 17:00:18.631 3: Probing CUL device /dev/ttyS24
2025.07.06 17:00:18.632 1: CUL: Can't open /dev/ttyS24: Input/output error
2025.07.06 17:00:18.632 3: Probing CUL device /dev/ttyS25
2025.07.06 17:00:18.632 1: CUL: Can't open /dev/ttyS25: Input/output error
2025.07.06 17:00:18.632 3: Probing CUL device /dev/ttyS26
2025.07.06 17:00:18.633 1: CUL: Can't open /dev/ttyS26: Input/output error
2025.07.06 17:00:18.633 3: Probing CUL device /dev/ttyS27
2025.07.06 17:00:18.633 1: CUL: Can't open /dev/ttyS27: Input/output error
2025.07.06 17:00:18.633 3: Probing CUL device /dev/ttyS28
2025.07.06 17:00:18.634 1: CUL: Can't open /dev/ttyS28: Input/output error
2025.07.06 17:00:18.634 3: Probing CUL device /dev/ttyS29
2025.07.06 17:00:18.634 1: CUL: Can't open /dev/ttyS29: Input/output error
2025.07.06 17:00:18.634 3: Probing CUL device /dev/ttyS3
2025.07.06 17:00:18.635 1: CUL: Can't open /dev/ttyS3: Input/output error
2025.07.06 17:00:18.635 3: Probing CUL device /dev/ttyS30
2025.07.06 17:00:18.635 1: CUL: Can't open /dev/ttyS30: Input/output error
2025.07.06 17:00:18.635 3: Probing CUL device /dev/ttyS31
2025.07.06 17:00:18.636 1: CUL: Can't open /dev/ttyS31: Input/output error
2025.07.06 17:00:18.636 3: Probing CUL device /dev/ttyS4
2025.07.06 17:00:18.636 1: CUL: Can't open /dev/ttyS4: Input/output error
2025.07.06 17:00:18.636 3: Probing CUL device /dev/ttyS5
2025.07.06 17:00:18.637 1: CUL: Can't open /dev/ttyS5: Input/output error
2025.07.06 17:00:18.637 3: Probing CUL device /dev/ttyS6
2025.07.06 17:00:18.637 1: CUL: Can't open /dev/ttyS6: Input/output error
2025.07.06 17:00:18.637 3: Probing CUL device /dev/ttyS7
2025.07.06 17:00:18.638 1: CUL: Can't open /dev/ttyS7: Input/output error
2025.07.06 17:00:18.638 3: Probing CUL device /dev/ttyS8
2025.07.06 17:00:18.638 1: CUL: Can't open /dev/ttyS8: Input/output error
2025.07.06 17:00:18.638 3: Probing CUL device /dev/ttyS9
2025.07.06 17:00:18.638 1: CUL: Can't open /dev/ttyS9: Input/output error
2025.07.06 17:00:18.647 1: usb create end
2025.07.06 17:00:18.682 0: Featurelevel: 6.4
2025.07.06 17:00:18.683 0: Server started with 336 defined entities (fhem.pl:29809/2025-03-30 perl:5.034000 os:linux user:fhem pid:6230)
2025.07.06 17:00:18.690 3: myBroker: port 2000 opened
2025.07.06 17:00:18.890 1: Perfmon: possible freeze starting at 17:00:11, delay is 7.89
2025.07.06 17:00:19.042 3: telnetForBlockingFn_1751814019.04215: port 37341 opened
2025.07.06 17:00:19.238 1: HMLAN_Parse: HMUSB new condition ok
2025.07.06 17:00:19.503 3: GoECharger (myGoE) - RequestERROR: http://192.168.188.138/status: empty answer received
2025.07.06 17:00:19.506 3: GoECharger (myGoE) - RequestERROR: http://192.168.188.138/status: empty answer received
2025.07.06 17:00:19.602 2: AttrTemplates: got 265 entries
2025.07.06 17:00:19.614 1: PERL WARNING: Use of uninitialized value $maxamp in concatenation (.) or string at ./FHEM/46_GoECharger.pm line 666.
2025.07.06 17:00:20.506 1: PERL WARNING: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 841.
2025.07.06 17:00:20.511 1: PERL WARNING: Use of uninitialized value $calcphases in multiplication (*) at ./FHEM/46_GoECharger.pm line 951.
Jetzt die V 1.52.18
Jetzt die V 1.53.0
Zitat von: DS_Starter am 06 Juli 2025, 17:13:54Jetzt die V 1.53.0
Diese Version tut nimmer
Bringt die wide character Fehlermeldung im FHEM log
In dieser Version sind die neuen Batterie Icons hinzugekommen.
Hast du eine Batterie intergriert und zeigst du die Batterie Icons in der Balkengrafik an?
Zitat von: DS_Starter am 06 Juli 2025, 17:24:15In dieser Version sind die neuen Batterie Icons hinzugekommen.
Hast du eine Batterie intergriert und zeigst du die Batterie Icons in der Balkengrafik an?
Ich habe eine Batterie, Ja.
Meine Ansicht ist diese:
Schalte die Anzeige der Batterie mal aus (setupBatteryDevXX -> show=0).
Speichern. Wenn die Batterie nicht mehr anzeigt wird restarten und dann ...
Zitat von: DS_Starter am 06 Juli 2025, 17:29:33Schalte die Anzeige der Batterie mal aus (setupBatteryDevXX -> show=0).
Speichern. Wenn die Batterie nicht mehr anzeigt wird restarten und dann ...
Batterie-Icons sind mit show=0 ausgeschaltet, sind nicht mehr sichtbar in der Balkengrafik, jedoch gleiche Situation mit identischer Fehlermeldung im FHEM log
Das ist "schade".
@Peter, bei dir läuft alexa mit SF und kein Problem?
@roadghost, zeige mir bitte mal deine gesamte Grafik mit Kopf usw.
Zitat von: DS_Starter am 06 Juli 2025, 17:39:12@roadghost, zeige mir bitte mal deine gesamte Grafik mit Kopf usw.
Gerne
Mal bitte auf eutsch umstellen ctrlLanguage=DE und testen.
Wenn das nicht hilft den Header ausschalten graphicSelect=both_noHead und testen.
Ich tippe immernoch auf ein Grafikelement.
Wow :o
Lass die Einstellung so, zeige dir die Batterien wieder an + speichern. Mache dann ein normales Update auf die eingecheckte Version und berichte bitte.
Batterie wieder angezeigt
Update auf Version 76_SolarForecast.pm:v1.54.0-s30101/2025-07-05 erledigt
shutdown restart
Alles gut, keine Fehler mehr im FHEM log und alexa startet normal durch
Vielen Dank !!
P.S. Lass Dir den Kaffee schmecken ;-)
puh :)
Trotzdem muss ich noch schauen wieso das Problem in Englisch vorhanden ist.
Ggf. musst du nochmal testen. ;)
@Peter, kannst du das Verhalten mit alexa bestätigen wenn SF auf EN eingestellt ist?
Danke euch und LG,
Heiko
Zitat von: DS_Starter am 06 Juli 2025, 18:07:01Ggf. musst du nochmal testen. ;)
Kein ding - ich helfe gern - bis zum 13.07 kannste mich noch einbinden, danach erst wieder ab dem 04.08
Zitat von: DS_Starter am 06 Juli 2025, 16:37:56Hast du solche Einträge?
Im Log von heute nicht.
Wie könnte ich das provozieren?
Verbose bei SF und alexa auf 5 und dann fhem neu starten?
Viele Grüße,
Peter
Es reicht eigentlich im SF ctrlLanguage=EN und neu starten + dann schauen ob es diese Meldungen wie bei roadghost gibt bzw. alexa problemlos läuft.
@ roadghost, dein OpenMeteo steht auf Fehler. Was steht da im Mouse-Over Popup?
Zitat von: DS_Starter am 06 Juli 2025, 18:07:01@Peter, kannst du das Verhalten mit alexa bestätigen wenn SF auf EN eingestellt ist?
Leider nein, aber ich bekomme jetzt dauerhaft Popup-Fehlermeldungen wie vor längerer Zeit schonmal kurz nach dem Neustart:
fhem?room=Garten%2D%3EPV%2DAnlage line 1:
Uncaught SyntaxError: Expected ',' or ']' after array element in JSON at position 610986 (line 1 column 610987)
Ich stelle mal wieder zurück.
Edit: Nach dem Zurückstellen durch deleteattr alles wieder normal.
Im Log habe ich weiterhin keine Einträge von FHEM/TcpServerUtils.pm.
Viele Grüße,
Peter
Aber alexa läuft wenn ich dich richtig verstehe? Und im Log kam auch nicht der "Wide Character" Fehler?
Zitat von: DS_Starter am 06 Juli 2025, 18:22:01Aber alexa läuft wenn ich dich richtig verstehe? Und im Log kam auch nicht der "Wide Character" Fehler?
Ja genau. Alexa läuft und keine solche Fehlermeldung im fhem-Log und auch keine solche Meldung im alexa-Log.
Wie sollte ich Verbose einstellen? Ist das egal?
Viele Grüße,
Peter
Zitat von: DS_Starter am 06 Juli 2025, 16:12:34@all,
hat sonst noch jemand von euch SF + alexa laufen?
Beides läuft ohne Probleme bei mir.
VG
Ja das ist egal. roadghost hat das Problem, dass bei Einstellung EN alexa nicht läuft bzw. die Verbindung mit "Wide Character" Fehler abbricht ... völlig untypisch.
@tatu123, vielen Dank für die Rückinfo.
Mich freut das, macht das Verhalten bei roadghost eigentlich für mich noch undurchsichtiger...
@roadghost, vllt kannst du dich mit Peter bzw. tatu123 dazu nochmal austauschen, ggf. in einen eigenen Thread.
@Heiko
Noch eine Ergänzung zum eigenartigem Verhalten von Consumer 07.
Wie schon erwähnt habe ich einen Consumer 08 mit den gleichen Defintion wie Consumer 07 angelegt.
Consumer 07
AB_POOLD:Aussenbereich+Pool
icon=scene_pool
type=other
asynchron=1
power=0 pcurr=Active_Power__W:W:2 etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=automatic mode=must
interruptable=1 swoffcond=AB_POOLD:SF_Abort:1
mintime=240 notbefore=03:00 notafter=21:00
ctrlUserExitFn
{
::pumpPoControl ($name, '07', 180);
}
Consumer 08
AB_POOLD:Aussenbereich+Pool
icon=scene_pool
type=other
asynchron=1
power=0 pcurr=Active_Power__W:W:2 etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=automatic mode=must
interruptable=1 swoffcond=AB_POOLD:SF_Abort:1
mintime=240 notbefore=03:00 notafter=21:00
ctrlUserExitFn
{
::pumpPoControl ($name, '08', 180);
}
Sobald ich nun bei Consumer 07 und Consumer 08 die ctrlUserExitFn festgelegt habe, passierte das gleiche mit Consumer 08 wie vorher bei Consumer 07.
Consumer 08 änderte seinen Inhalt auf den, den vorher Consumer 07 hatte.
Consumer 08 nach der Definition von ctrlUserExitFn
AB_POOLD:Aussenbereich Pool
asynchron=1
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
icon=scene_pool
interruptable=0
mintime=240
mode=must
notafter=21:00
notbefore=03:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swoffcond=AB_POOLD:SF_Abort:1
swstate=state:EIN:AUS
type=other
Und jetzt kommts!
Lösche ich den Consumer 08 und die zugehörige ctrlUserExitFn Definition, behält der Consumer 07 endlich seinen Inhalt trotz vorhandener ctrlUserExitFn Definition.
Getestet mit Modul Version: 1.54.1
Hallo zusammen,
Zitat von: DS_Starter am 06 Juli 2025, 18:35:06Ja das ist egal. roadghost hat das Problem, dass bei Einstellung EN alexa nicht läuft bzw. die Verbindung mit "Wide Character" Fehler abbricht ... völlig untypisch.
@tatu123, vielen Dank für die Rückinfo.
Mich freut das, macht das Verhalten bei roadghost eigentlich für mich noch undurchsichtiger...
@roadghost, vllt kannst du dich mit Peter bzw. tatu123 dazu nochmal austauschen, ggf. in einen eigenen Thread.
Leider kann ich das Verhalten bei @roadghost bestätigen.
Ich habe auch SF + AlexaFhem am Laufen. Bei Umstellung von 'ctrlLanguage' auf EN finde ich ebenfalls folgende Meldung im Logfile:
2025.07.06 18:55:18 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.
2025.07.06 18:55:18 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:65:99:99:101:115:115:45:67:111:110:116:114:111:108:45:65:108:108:111:119:45:77:101:116:104:111:100:115:58:32:71:69:84:44:32:80:79:83:84:44:32:79:80:84:73:79:78:83:13:10:65:99:99:101:115:115:45:67:111:110:116:114:111:108:45:65:108:108:111:119:45:72:101:97:100:101:114:115:58:32:79:....
viele, viele Zeilen
.....
32:60:47:115:118:103:62:60:47:97:62:60:47:100:105:118:62:34:93:10,len:499225,off:0
2025.07.06 18:55:18 1: stacktrace:
2025.07.06 18:55:18 1: main::TcpServer_WriteBlocking called by ./FHEM/01_FHEMWEB.pm (704)
2025.07.06 18:55:18 1: main::FW_initInform called by ./FHEM/01_FHEMWEB.pm (962)
2025.07.06 18:55:18 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (613)
2025.07.06 18:55:18 1: main::FW_Read called by fhem.pl (3988)
2025.07.06 18:55:18 1: main::CallFn called by fhem.pl (789)und alexaFHEM ist tot.
Nach Entfernen des Attributs 'ctrlLanguage' und Neustart von FHEM ist alles wieder gut. Keine Fehlermeldung im Log und alexaFhem läuft nach reboot.
Zitat von: DS_Starter am 06 Juli 2025, 18:13:18@ roadghost, dein OpenMeteo steht auf Fehler. Was steht da im Mouse-Over Popup?
API Abfrage fehlgeschlagen,Start SSL xxxx:443 timed out
Das kann schonmal passieren, sollte aber die Ausnahme sein. OpenMeteo läuft bei mir sehr zuverlassig.
Zitat von: Wolle02 am 06 Juli 2025, 19:17:26Hallo zusammen,
Zitat von: DS_Starter am 06 Juli 2025, 18:35:06Ja das ist egal. roadghost hat das Problem, dass bei Einstellung EN alexa nicht läuft bzw. die Verbindung mit "Wide Character" Fehler abbricht ... völlig untypisch.
@tatu123, vielen Dank für die Rückinfo.
Mich freut das, macht das Verhalten bei roadghost eigentlich für mich noch undurchsichtiger...
@roadghost, vllt kannst du dich mit Peter bzw. tatu123 dazu nochmal austauschen, ggf. in einen eigenen Thread.
Leider kann ich das Verhalten bei @roadghost bestätigen.
Ich habe auch SF + AlexaFhem am Laufen. Bei Umstellung von 'ctrlLanguage' auf EN finde ich ebenfalls folgende Meldung im Logfile:
2025.07.06 18:55:18 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.
2025.07.06 18:55:18 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:65:99:99:101:115:115:45:67:111:110:116:114:111:108:45:65:108:108:111:119:45:77:101:116:104:111:100:115:58:32:71:69:84:44:32:80:79:83:84:44:32:79:80:84:73:79:78:83:13:10:65:99:99:101:115:115:45:67:111:110:116:114:111:108:45:65:108:108:111:119:45:72:101:97:100:101:114:115:58:32:79:....
viele, viele Zeilen
.....
32:60:47:115:118:103:62:60:47:97:62:60:47:100:105:118:62:34:93:10,len:499225,off:0
2025.07.06 18:55:18 1: stacktrace:
2025.07.06 18:55:18 1: main::TcpServer_WriteBlocking called by ./FHEM/01_FHEMWEB.pm (704)
2025.07.06 18:55:18 1: main::FW_initInform called by ./FHEM/01_FHEMWEB.pm (962)
2025.07.06 18:55:18 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (613)
2025.07.06 18:55:18 1: main::FW_Read called by fhem.pl (3988)
2025.07.06 18:55:18 1: main::CallFn called by fhem.pl (789)
und alexaFHEM ist tot.
Nach Entfernen des Attributs 'ctrlLanguage' und Neustart von FHEM ist alles wieder gut. Keine Fehlermeldung im Log und alexaFhem läuft nach reboot.
Hallo Leidensgenosse ;-)
Zitat von: DS_Starter am 06 Juli 2025, 16:12:34@all,
hat sonst noch jemand von euch SF + alexa laufen?
Hallo Ihr Zwei,
bei mir läuft die Kombi SF + (FHEM-)Alexa fehlerfrei
Gruß Gerd
Edit 21:00
hätte erst zu ende lesen sollen - nach Umstellen auf 'EN' und 'restart' startet auch mein alexa nicht mehr
Kann das Verhalten also auch bestätigen
Gruß Gerd
@Burny4600,
ich habe das Thema bei mir mit einem Dummy nachgestellt.
Es funktioniert einwandfrei ... aber erst nachdem ich eine doppelt defierte sub pumpControl in 99_myUtils gelöscht hatte. ;)
Ich habe tatsächlich nicht daran gedacht diese sub bereits definiert zu haben und ganz seltsame Effekte festgestellt und an meinem Code gezweifelt, bis ich darauf kam.
Vielleicht ist es bei dir ähnlich.
Also diese userExitFn funktioniert:
{
pumpControl ($name, '01', 600);
pumpControl ($name, '02', 300);
}
Und dazu die Consumer attr:
consumer01
SolCastPumpDummy:Zirkulationspumpe
auto=automatic
etotal=energy_Wh:Wh
icon=sani_pump
interruptable=0
mintime=780
mode=must
notafter=09
off=off
on=on
pcurr=actpow:W
power=50
swoffcond=SolCastPumpDummy:SF_Abort:1
type=other
consumer02
SolCastPumpDummy:Zirkulationspumpe
auto=automatic
etotal=energy_Wh:Wh
icon=sani_pump
interruptable=1
mintime=780
mode=must
notafter=09
off=off
on=on
pcurr=actpow:W
power=50
swoffcond=SolCastPumpDummy:SF_Abort:1
type=other
Im C1 wurde ordnungsgemäß interruptable=0 gesetzt.
Zitat von: roadghost am 06 Juli 2025, 20:20:19Hallo Leidensgenosse ;-)
Och, was heißt hier Leidensgenosse? Bei mir tut ja alles ;) Ich hab es nur ausprobiert, weil ich die gleiche Kombination fahre und Heiko gefragt hatte.
Ich weiß zwar nicht warum der Fehler auftritt, aber wer als deutschsprachiger Fhem bewusst auf Englisch fährt, der ist dann halt selbst schuld. :P
Gruß
Wolle
Danke euch allen für die Mitarbeit. Jedenfalls verdichtet sich die Symptomatik wenn EN verwendet wird.
Jetzt muß ich "nur" noch herausbekommen wieso es so ist, denn gerade EN ist ja eigentlich einfacher als DE strukturiert.
LG,
Heiko
Hallo Burny4600,
ich habe die ctrlUserExitFn noch etwas robuster gestaltet und gehärtet.
V 1.54.1 liegt abgedatet im contrib.
LG,
Heiko
Hallo alexa-User,
ich denke das EN-Problem behoben zu haben.
Im contrib liegt die gefixte Version und ich bitte euch um einen Test.
LG,
Heiko
@Heiko
Das heist, das auch die Schreibweise der ctrlUserExitFn anders ist.
{
::pumpPoControl ($name, '07', 180);
}
:: ist zu entfernen?
Zitat:: ist zu entfernen?
Nein, bleibt alles so erhalten.
@Chris,
ich habe im Setter attrKeyVal noch ein Thema entdeckt, welches eine unterschiedliche Behandlung bewirken _könnte_ je nachdem ob der Befehl aus der FHEMWEB GUI herus oder als Kommando aus einem Skript heraus ausgelöst wird.
Die Funktion habe ich angepasst und wieder in meinem contrib upgedated.
Grüße,
Heiko
Hallo Heiko,
bei mir funktioniert mit der Version 76_SolarForecast.pm:v1.54.1-s30109/2025-07-06 mit CtlLanguage auf EN auch alexa ganz normal.
Kein Fehler im FHEM log.
Woran lag es ?
Danke für deine Rückmeldung! :)
ZitatWoran lag es ?
Ich mußte diesen englischen Text:
no reduction status available\nPlease set the key 'reductionState' with 'attr <NAME> plantControl'
in das UTF-8 Format bringen. Dieser Text erscheint als Mouse-Over über dem Abregelungs-ICON in bestimmten Situationen.
Warum dieser Text? ... Ich weiß es nicht. Daran ist nichts verwerfliches oder besonderes. Lediglich der Zeilenumbruch (\n). Das soll ein Wide Character sein?
Aber es ist so, diesen Text nach UTF-8 encoded und läuft.
Wahrscheinlich müßte man zentral im alexa-Modul eine UTF-8 Konvertierung bei der longpoll Funktion vornehmen. Es kann ja an anderer Stelle vllt. wieder passieren und die Suche ist echt schwierig. Aber das ist nicht meine Baustelle. ;)
LG,
Heiko
@Heiko
ZitatDie Funktion habe ich angepasst und wieder in meinem contrib upgedated.
Ich habe dein Modul nochmals aktualisiert.
Betreffend UTF-8 Konvertierung und Alexa habe ich einen Hinweis unter der Sprachsteuerung gemacht.
Mich hat es zwar noch nicht betroffen, da Alexa bei mir auf einem anderen FHEM System mit einem Pi5 läuft, aber dieses System ist die FHEM-Zentraleinheit für die anderen 9 FHEM-Systeme.
Hi Chris,
den Text in deinem Post müsstest du mal korrigieren. alexa _verursacht_ das Problem nicht, sondern ist von der Problemtik betroffen, könnte aber wahrscheinlich an dieser zentralen Stelle (longpoll) zur Fehlervermeidung beitragen. Dadurch käme es nicht zum Wide Character Fehler falls ein Modul im FHEM Universum an einer Stelle die UTF-8 Konvertierung nicht oder ungenügend vorgenommen hat.
LG,
Heiko
Ich hoffe ich habe die Alexa Änderung jetzt richtig übernommen.
Ja, aber die Postüberschrift ist noch irreführend ;)
Edit:
Und
ZitatEs gibt ein Problem mit der UTF-8 Konvertierung ...
stimmt so auch nicht. Sondern ...
ZitatFalls ein Modul eine nötige UTF-8 Konvertierung nicht oder ungenügend vorgenommen hat, kann alexa davon betroffen sein und es kommt zum Wide Character Fehler. ...
Habe es gerade selbst bemerkt und geändert.
Siehe meinen Edit oben nochmal.
Ich hoffe ich habe es jetzt richtig vertsanden.
Eine Frage noch zum Attribut ConsumerXX.
Ist das beabsichtig das die Consumer Konfiguration nach zB. set AB_WS_SS attrKeyVal consumer07 interruptable=1 sich alphabetisch sortiert?
ZB vorhandene Definition
AB_POOLD:Aussenbereich+Pool
icon=scene_pool
type=other
asynchron=1
power=0 pcurr=Active_Power__W:W:2 etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=automatic mode=must
interruptable=1 swoffcond=AB_POOLD:SF_Abort:1
mintime=240 notbefore=03:00 notafter=21:00
Ausführen von "set AB_WS_SS attrKeyVal consumer07 interruptable=1"
Ändert sich in
AB_POOLD:Aussenbereich+Pool
asynchron=1
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
icon=scene_pool
interruptable=1
mintime=240
mode=must
notafter=21:00
notbefore=03:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swoffcond=AB_POOLD:SF_Abort:1
swstate=state:EIN:AUS
type=other
Der Inhalt selbst hat sich nicht geändert.
ZitatIst das beabsichtig das die Consumer Konfiguration nach zB. set AB_WS_SS attrKeyVal consumer07 interruptable=1 sich alphabetisch sortiert?
Jein. Es ist ein Nebenprodukt der Funktionalität. Ich hatte die Wahl zwischen "immer zufällig durcheinander" oder "alphabetisch und damit immer geordnet" und habe mich für das Letztere entschieden. :)
LG,
Heiko
Zitat von: DS_Starter am 07 Juli 2025, 11:51:58Warum dieser Text?
Hallo Heiko,
es dürften die einfachen Anführungszeichen um reductionState gewesen sein. Im Notepad++ sieht man den Unterschied sofort. Es sind sogar 2 verschiedene, öffnend und schließend. Wenn mein Hex-Editor nicht lügt und beim Kopieren nichts schiefgegangen ist, waren es statt ASCII 27 dort 91 und 92, nur im englischen Text.
Viele Grüße
Thomas
Ah, guter Hinweis. :) Jetzt wo du es sagst sehe ich es auch (nutze Notepad++).
Damit habe mich mir jetzt eine Frage verdient oder? Und wenn ich sage, dass es noch (16?) weitere Zeilen damit gibt, vielleicht eine 2. ;D
Na sicher :)
Hallo Heiko,
hier meine Frage. Ich habe einige solcher Einträge im Log:
The calculated Energy consumption of the house is negative. This appears to be an error and is not saved. Check Readings _PVreal, _GridFeedIn, _GridConsumption, _BatIn_XX, _BatOut_XX of hour >24<
Da wollte ich jetzt mal versuchen, ob ich die weg bekomme. Vermutlich nur unterschiedliche Intervalle bei der Datenlieferung.
Meine eigentliche Frage bezieht sich aber auf die BatIn und BatOut Werte. Die sind bei mir immer 0. Woraus bzw wie werden die denn berechnet?
Viele Grüße
Thomas
ZitatMeine eigentliche Frage bezieht sich aber auf die BatIn und BatOut Werte. Die sind bei mir immer 0. Woraus bzw wie werden die denn berechnet?
Diese Werte werden pro Stunde berechnet und liest die Angaben aus den Schlüsselreadings (Batterie) intotal und outtotal. Es sind also Differenzen da intotal und outtotal stetig hochzählen sollten.
Hier nochmal zum Wide Character Fehler:
ZitatKann das Zeichen '...' den Wide-Character-Fehler verursachen?
Ein normaler ASCII-Ziffern-8 (Codepunkt U+0038) löst keinen Wide-Character-Fehler aus, denn er liegt im Bereich 0–255 und passt in ein einzelnes Byte.
Der gezeigte Ausdruck nutzt jedoch typografische Anführungszeichen:
* Die Zeichen ' und ' sind nicht das einfache ASCII-Apostroph (0x27), sondern Unicode-Codepunkte U+2018 (LEFT SINGLE QUOTATION MARK) und U+2019 (RIGHT SINGLE QUOTATION MARK).
* Diese Codepunkte liegen weit über 255 und werden in UTF-8 als Mehr-Byte-Sequenz kodiert.
Solche Zeichen in einem als Unicode-String markierten Perl-Scalar, der ohne UTF-8-Ausgabe-Layer (binmode) ausgegeben wird, führen genau zum ,,Wide character in print"-Fehler.
Jetzt haben wir es. Im Modul habe ich natürlich alle Vorkommen eliminiert.
Zitat von: DS_Starter am 07 Juli 2025, 16:15:16Es sind also Differenzen da intotal und outtotal stetig hochzählen sollten.
Ah, ok. Die habe ich nicht. Nur pin und pout. Also intotal und outtotal habe ich nicht nur nicht definiert, sondern die werden so auch nicht fertig geliefert. Aber ich schaue noch mal, Wäre schon interessant.
Das wäre für die Energiesummenbildung relevant. Sonst fehlen diese Anteile. Wenn outtotal fehlt, kann dein Hausverbrauch negativ werden da:
Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung
bzw. Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?). Da steht es drin wie gerechnet wird.
Zitat von: DS_Starter am 07 Juli 2025, 16:18:55sondern Unicode-Codepunkte U+2018 (LEFT SINGLE QUOTATION MARK) und U+2019 (RIGHT SINGLE QUOTATION MARK
Ja, wenn man das in den Hex-Editor richtig einfügt (als Unicode), dann sieht man das auch so und nicht 91 und 92 wie oben geschrieben. Ich glaube, meine 2. Frage muss ich mir dann noch aufheben. :-[
Ach komm, heute ist mein spendabler Tag ;)
Na gut, auch wenn ich eher intotal und outtotal definieren müsste, die Batterie liefert die nämlich laut MQTT Explorer doch.
Also es geht um die Verbrauchersteuerung. Zum einen hatte ich da mal in der Liste der Verbraucher auf die Uhr geklickt. Das "Klick für sofortige Einplanung" hatte ich aber wohl falsch verstanden. Ich dachte "sofortige Einplanung" startet die Berechnung noch mal neu, mit den aktuellen Werten. Die Spülmaschine ist aber direkt angegangen. Gibt es dann einen Unterschied zum einfachen Einschalten über den Schieberegler? Gemacht hatte ich das, weil ich vorher den Automatikmodus erst eingeschaltet hatte. Bei dem ist mir aufgefallen, dass alle Verbraucher laut Log eingeplant werde, auch solche mit "Automatik aus". Macht das Sinn? Nehmen die anderen Geräten dann nicht den Slot weg obwohl sie gar nicht gestartet werden könnten?
Zitat von: DS_Starter am 07 Juli 2025, 16:31:04Das wäre für die Energiesummenbildung relevant. Sonst fehlen diese Anteile. Wenn outtotal fehlt, kann dein Hausverbrauch negativ werden da
Ok, sind definiert. Die Batterie liefert die Werte aber auf Tagesbasis. Passt das zu "Sollte des Reading die Vorgabe eines stetig aufsteigenden Zählers verletzen ..." oder bekomme ich dann jede Nacht einen Eintrag im Log?
Ja es gibt Unterschiede zwischen den Methoden:
- consumerImmediatePlanning (Soforteinplanung): Es wird das sofortige Einschalten des Verbrauchers zur aktuellen Zeit eingeplant. Eventuell im consumerXX Attribut gesetzte Schlüssel notbefore, notafter bzw. mode werden nicht beachtet -> D.h. der Verbraucher wird ab der aktuelen Zeit eingeplant und auch eingeschaltet sofern die Elemente PV-Überschuß und andere Festlegunge im Consumer erfüllt sind.
Diese Methode wird auch beim Click auf das Uhrensymbol angewendet.
- consumerNewPlanning: Es wird die vorhandene Planung des angegebenen Verbrauchers gelöscht. Die Neuplanung wird unter Berücksichtigung der im consumerXX Attribut gesetzten Parameter sofort vorgenommen. -> hier wird die Einplanungszeit wieder optimiert gesucht. Die
Einplanung wird sofort vorgenommen, aber der Start des Zeitfensters kann z.B. erst in 3 Stunden sein.
ZitatGibt es dann einen Unterschied zum einfachen Einschalten über den Schieberegler?
Ja, der Schieberegeler ist keine Einplanung und unterliegt auch nicht der Modulsteuerung. Er ist im Prinzip identisch zu einem manuellen Schalten des Gerätes. Im Status des Consumers wird dann auch "von extern umgeschaltet erscheinen".
ZitatBei dem ist mir aufgefallen, dass alle Verbraucher laut Log eingeplant werde, auch solche mit "Automatik aus". Macht das Sinn?
Ja, macht Sinn. Die Automatik kann man für weiterführende Steuerungsaufgaben nutzen, z.B. eine Chain aufbauen. Man lässt alle Consumer planen, setzt aber alle außer den ersten auf Automatik=off. Ist der erste Consumer fertig, wird der nächste mit Automatik=on freigeschaltet und arbeitet seine Einplanung ab usw.
ZitatNehmen die anderen Geräten dann nicht den Slot weg obwohl sie gar nicht gestartet werden könnten?
In gewisser Weise schon. Deswegen sollte man dauerhaft auch nur die Consumer planen lassen die man auch steuern lassen will. Macht ja sonst wenig Sinn. Alle anderen kann man mit type=noSchedule definieren zur Anzeige und manuellen Schalten.
ZitatDie Batterie liefert die Werte aber auf Tagesbasis. Passt das zu "Sollte des Reading die Vorgabe eines stetig aufsteigenden Zählers verletzen ..." oder bekomme ich dann jede Nacht einen Eintrag im Log?
Das kommt ein bisschen auf das Zeitregime an. SF registriert den Anfangszustand zu Beginn jeder Stunde. Wenn die Bat vorher zur Stunde 0 auf 0 setzt kommt keine Meldung, sonst vllt. eine mit verbose 3.
Ich würde SF mit verbose 2 laufen lassen sobald alles zur Zufriedenheit eingerichtet ist.
Zitat von: DS_Starter am 07 Juli 2025, 17:11:46Deswegen sollte man dauerhaft auch nur die Consumer planen lassen die man auch steuern lassen will.
Schon klar. Aber es werden ja explizit Gerätetypen wie Waschmaschine, Trockner und Spülmaschine angeboten. Und die laufen (zumindest bei uns) nicht täglich. Und bei einem BKW reicht der Überschuss dann nicht immer gleich für alle Geräte. Würde mich eh mal interessieren, wie viele Nutzer hier was richtiges auf dem Dach haben oder so wie ich um "jede Wattstunde" kämpfen müssen.
Zitat von: DS_Starter am 07 Juli 2025, 17:17:32Das kommt ein bisschen auf das Zeitregime an.
Ok, mit Kenntnis der Logik kann man den Zeitpunkt der Nullung ja manuell vorziehen, damit keine Meldung kommt.
Zitat von: DS_Starter am 07 Juli 2025, 17:17:32Ich würde SF mit verbose 2 laufen lassen sobald alles zur Zufriedenheit eingerichtet ist.
Bei den vielen Optionen, die SolarForecast bietet, komme ich da nie hin ;-) Außerdem schraube ich ja ständig an der Hardware. Da liegt schon wieder ein Wechselrichter mit ein paar kleinen Panels im Keller.
ZitatSchon klar. Aber es werden ja explizit Gerätetypen wie Waschmaschine, Trockner und Spülmaschine angeboten. Und die laufen (zumindest bei uns) nicht täglich.
Im default wird nur auf Grundlage der PV Prognose geplant. Da kann es zu Überschneidungen der einzelnen Consumer in der Planung kommen. Das ist aber kein Problem, denn ist zb. die Spülmaschine losgelaufen, wartet der nächste (schon eingeplante Consumer) bis Überschuß vorhanden ist. Wenn nicht wird er automatisch "replanned" sofern der Status noch "planned" ist. Da gibt es eine interne Logik.
Es gibt plantControl->consForecastInPlanning. Damit kannst du die Einplanungslogik auch beeinflussen.
ZitatBei den vielen Optionen, die SolarForecast bietet, komme ich da nie hin ;-)
Mach dir nichts draus, ich werde auch nie fertig. ;)
Hallo Heiko,
seit dem letztem crontrib Update taucht ca. alle 5 Sek links oben Connection lost, trying a reconnect every 5 seconds.
Vorher war das Problem, dass irgendwie nur SolarForecast um ca. 15:50 nicht mehr die aktuelle Uhrzeit übernommen hatte und eine Meldung lieferte, dass DWD nicht mehr aktuell ist.
Nach einem Systemneustart ist zwar der DWD Hinweis nicht mehr vorhanden, dafür aber die ständige Connection lost Meldung.
Das ist aber nur der Fall, wenn ich die Forcast Seite aufrufe.
Zudem finde ich im LOG diese Einträge:
tmr-FHEM::SolarForecast::singleUpdateState(N/A)
tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS)
tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS)
tmr-FHEM::SolarForecast::centralTask(N/A)
Auch das Reading state aktualisiert sich alle 7 Sek.
Zudem hat sich seit dem Neustart die Systemlast um einiges erhöht.
Durch was kommt das.
Die Meldung kommt wenn FHEMWEB longpoll die Verbindung verliert. Ab und zu kommt das bei mir auch, aber soll natürlich kein Dauerzustand sein. Das Modul hat sehr viele Readings. Wenn diese bei jeden Update einen Event werfen und es dazu vllt. noch sehr häufig mit kurzen Zyklen passiert, kann es eine Ursache sein. -> event-on-change-reading=.* nutzen
Ich frage bei solchen Dingen gerne mal die KI und es kommen durchaus erstaunlich gute Antworten:
Ursachen & LösungenDiese Meldung ist ein typisches Zeichen dafür, dass die Longpoll-Verbindung zwischen Browser und FHEM-Server unterbrochen wurde. Das passiert nicht selten – aber es gibt ein paar typische Gründe und einfache Gegenmaßnahmen:
🔍 Häufige Ursachen
Instabile Netzwerkverbindung ➝ WLAN-Schwankungen, PowerLAN-Brücken oder Proxy-Server können die Verbindung stören.
Browser-Timeouts oder Tabs im Hintergrund ➝ Manche Browser (v. a. mobil) kappen Longpolls, wenn der Tab nicht aktiv ist.
FHEM läuft hinter einem Apache-Proxy ➝ Wenn du FHEM über Apache weiterleitest, kann die Proxy-Konfiguration Longpolls abbrechen.
Longpoll-Modus nicht optimal eingestellt ➝ FHEM kann longpoll über websocket oder polling betreiben – je nach Setup funktioniert das eine besser als das andere.Lösungen & TippsMaßnahme Beschreibung
attr WEB longpoll websocket Aktiviert WebSocket-Modus – oft stabiler als klassisches Longpoll
attr WEB longpoll 1 Falls WebSocket nicht funktioniert, klassisches Longpoll aktivierenApache-Proxy prüfen Stelle sicher, dass ProxyPass und ProxyPassReverse korrekt gesetzt sind
Netzwerk stabilisieren WLAN-Verstärker, direkte LAN-Verbindung oder Router-Check
Browser wechseln/testen Chrome, Firefox, Edge – manche sind robuster bei Longpolls
Ich benutze FHEMWEB F18 sowohl mit longpoll=websocket als auch longpoll=1. Beide Varianten zumindest nach meiner Beobachtung gleich stabil-> ausprobieren.
Achso:
Zitattmr-FHEM::SolarForecast::singleUpdateState(N/A)
tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS)
tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS)
tmr-FHEM::SolarForecast::centralTask(N/A)
Diese Meldungen sind nicht von mir. Hast du Apptime oder eine anderes Performance-Tool ständig im Hintergrund mitlaufen? -> nicht machen und abschalten. Das bringt oftmals mehr Ärger als Nutzen. Diese Tools nur einsetzen um einen konkreten Verdacht zu untersuchen und nach beendeter Untersuchung wieder abschalten aber nicht ständig mitlaufen lassen.
@Chris,
wenn alle 7 Sek. dein state updated, hast du entweder cycleInterval so kurz eingestellt oder eines/mehrere Geräte (Consumer, Battery, Meter, Inverter) auf asynchron stehen. In diesem Fall reagiert SF auf Events dieser Geräte und startet einen neuen Zyklus.
LG,
Heiko
Zitat von: tomcat.x am 07 Juli 2025, 17:41:57Ok, mit Kenntnis der Logik kann man den Zeitpunkt der Nullung ja manuell vorziehen, damit keine Meldung kommt.
@tomcat.x
Wenn es nur darum geht die lästige Meldung zu eliminieren hilft vielleicht auch ein DoIf oder ein Notify?
Zitat von: Damian am 01 April 2019, 23:58:37define mydoif DOIF ([logTrigger:state]) (set ....)
hatte ich mal überlegt - hab aber derzeit keine Meldungen und so nix fertiges
Gruß Gerd
@Peter,
bzgl. deines Post in #3401 tendiere ich dazu die zusätzlichen Differenzanzeige generell ohne Nachkommastellen darzustellen wenn die Anzeige in Wh erfolgt (der default).
Bei der Anzeige in kWh würde ich bei einer Nachkommastelle bleiben. Damit sollte die Darstellung insgesamt harmonischer sein wenn Differenzen angezeigt werden.
@Peter, @all,
ich habe die Balkenbreitenthematik jetzt so gelöst, dass die zusätzliche Differenzanzeige von PVForecast und PVreal ohne Nachkommastellen erfolgt sofern Wh angezeigt werden. Andere Werte (z.B. Batterie SoC) betrifft das nicht. Erfolgt die Anzeige von PVForecast und PVreal in kWh, bleibt die Anzeige bei einer Nachkommstelle.
Damit sollte es in den meisten Fällen passen. Wem die Ästhetik immernoch nicht reicht, kann die Balkenbreite mit graphicControl->beamWidth=X auf einen festen Wert setzen um alle Balken mit einer einheitlichen Breite darzustellen. Das habe ich auf einem der Screenshots eingestellt.
LG,
Heiko
Die V in meinem contrib ist upgedated.
Moin,
jetzt weiß ich auch wie die typografischen Anführungszeichen ins Modul gekommen sind denn bewußt verwende ich sie nicht.
Für eine zügige Übersetzung verwende ich die Online Verson von DeepL. Enthält der zu übersetzende Text '...', liefert DeepL den englischen Text mit typografischen Anführungszeichen zurück. Böse Falle.
Nur als Hinweis falls ihr DeepL in eigenen Projekten verwendet.
LG,
Heiko
Moin Heiko.
Zitat von: DS_Starter am 07 Juli 2025, 21:07:10@Peter, @all,
ich habe die Balkenbreitenthematik jetzt so gelöst, dass die zusätzliche Differenzanzeige von PVForecast und PVreal ohne Nachkommastellen erfolgt sofern Wh angezeigt werden. Andere Werte (z.B. Batterie SoC) betrifft das nicht. Erfolgt die Anzeige von PVForecast und PVreal in kWh, bleibt die Anzeige bei einer Nachkommstelle.
Damit sollte es in den meisten Fällen passen. Wem die Ästhetik immernoch nicht reicht, kann die Balkenbreite mit graphicControl->beamWidth=X auf einen festen Wert setzen um alle Balken mit einer einheitlichen Breite darzustellen. Das habe ich auf einem der Screenshots eingestellt.
LG,
Heiko
Das gefällt mir so sehr gut.
Würdest du in Betracht ziehen, das gleiche such für die consumptionreal und consumptionforecast zu übernehmen?
Vielen Dank und viele Grüße,
Peter
ZitatWürdest du in Betracht ziehen, das gleiche such für die consumptionreal und consumptionforecast zu übernehmen?
Mache ich gerne.
LG,
Heiko
Zitat von: DS_Starter am 30 Juni 2025, 23:54:24ZitatIrgendwas ist generell kaputt gegangen mit dem Update auf v1.53.0
Kaputt ist sicherlich nichts. Welche Version hattest du vorher? Hast du die Updates der Weiterentwicklungen immer mitgemacht?
Ja, die Updates bin ich immer mitgegangen.
Danke, war ein unabhängiges Problem mit dem EVENT aus der Aufteilung von Positiven und Negativen Werten vom Smart Shunt.
ZitatWürdest du in Betracht ziehen, das gleiche such für die consumptionreal und consumptionforecast zu übernehmen?
Habe es umgesetzt (Screenshot). Update liegt im contrib.
Zitat von: DS_Starter am 08 Juli 2025, 09:18:01Habe es umgesetzt (Screenshot). Update liegt im contrib.
Vielen Dank. Gezogen und positiv getestet.
Viele Grüße,
Peter
@Heiko
ZitatHast du Apptime oder eine anderes Performance-Tool ständig im Hintergrund mitlaufen?
Weder Apptime noch andere Performance-Tools laufen bei mir.
Zitatwenn alle 7 Sek. dein state updated, hast du entweder cycleInterval....
event-on-change-reading=.*
wird standartmässig fast überall verwendetcycleInterval=70
ist seit Anfang so defeniertNetzwerkverbindungen alle Pis nutzen 1GB-LAN-Verbindung
Pis nutzen keine Proxyverbindung
attr WEB longpoll websocket
nun definiertEs dürfte an longpoll gelegen sein. Nun taucht
Connection lost, trying a reconnect every 5 seconds. nicht mehr ständig auf, und auch unter SYSMON ist die Systemlast wieder geringer.
FHEMWEB Einstellungenattr WEB JavaScripts codemirror/fhem_codemirror.js pgm2/clock.js pgm2/HMdeviceTools.js pgm2/HMinfoTools.js pgm2/hm.js
attr WEB stylesheetPrefix dark
SolarForcast Einstellungen plantControl cycleInterval=70
Verbraucher: consumer 01 bis 13 asynchron=1
Hochspannungsbatterien: setupBatteryDev 01 u. 02 asynchron=1
Hybridinvertern: setupInverterDev 01 u. 02 asynchron=1
Smartmeter: setupMeterDev asynchron=1
Gibt es noch etwas worauf ich achten muss?
Hallo Chris,
da (fast?) alle Geräte mit asynchron=1 betrieben werden, reagiert SF auf jedes Event der relevanten Readings dieser Geräte.
Du hast event-on-change-reading=.* fast überall verwendet wie du schreibst, was die Eventlast schon gut reduzieren dürfte.
Es wäre zu überlegen, ob wirklich alle Geräte mit asynchron=1 sinnvoll betrieben werden oder ob es nicht ausreicht z.B. nur den Meter als "führendes" Gerät mit asynchron=1 zu definieren. Das kannst du aber nur selbst einschätzen wie dein System arbeitet.
Ansonsten würde ich SF in einem separaten Room im FHEMWEB unterbringen, schon wegen der doch recht umfangreichen Grafik. Bei mir habe ich 5 ziemlich voll ausgebaute SF-Devices in einem Raum untergebracht. Das funktioniert auf meinem Server auch problemlos. Ich mache das aber nur um solche Worst Case Szenarien zu prüfen wie die SF-Systeme in solchen Umgebungen spielen oder ob es zu Problemen kommt.
LG,
Heiko
Zitat von: Burny4600 am 08 Juli 2025, 10:14:59Gibt es noch etwas worauf ich achten muss?
Hallo Chris,
Vielleicht ist die Ursache nicht im SF/FHEM zu finden, sondern im Heimnetz - jedenfalls war das bei mir die Ursache für ähnliche Phänomene.
Meine Anlage ist auch (mit der Zeit) gewachsen und hat viele Sensoren (mehrere 100) verstreut über unterschiedliche Hardware und Schnittstellen - z.T. räumlich weit auseinander - die ich zuerst über FHEM2FHEM, später hauptsächlich mit MQTT verbunden habe. Und manche dieser Gerätschaften sind auch selber ziemlich 'gesprächig', viele bringen Ihren eigenen 'Bus' mit. Dadurch ist der Broadcast im Heimnetz gewachsen was schlussendlich die oben erwähnten Probleme verursachte - Abhilfe hab ich zum einen durch Router-Einstellungen (QoS/Storm-Control-Rate) und zum anderen eine Überprüfung der Netzwerkkabel auf CAT6 gefunden, damit das alles im 1GB läuft. Seither bin ich symptomfrei in diese Richtung.
Ist nur so eine Idee - die oben angesprochenen Einstellungen hatte ich auch ohne (durchschlagenden) Erfolg probiert
Gruß Gerd
Hallo Heiko,
ich habe jetzt wenigstens mal beim Kühlschrank den Typ auf noSchdule geändert. Da macht die Planung definit keinen Sinn ;-)
Zitat von: DS_Starter am 07 Juli 2025, 17:11:46Alle anderen kann man mit type=noSchedule definieren zur Anzeige
Allerdings kann ich nicht wirklich einen Unterschied feststellen. In der Verbraucherliste über der Grafik kommt beim Mouseover über die Uhr immer noch "Plannungsstatus: planned" und im Log auch "SolarForecast - Consumer "Kühlschrank" planned: ...". Er wurde noch nie geschaltet, weil keine Kommandos dafür definiert sind. Hätte ich sonst noch was ändern müssen?
Viele Grüße
Thomas
Hallo Thomas,
ZitatAllerdings kann ich nicht wirklich einen Unterschied feststellen.
Falls du die Parameter gerade geändert hast... warten bis der neue Einplanungszyklus beginnt, i.A. morgen (in der Nacht).
Oder mit "set ... consumerNewPlanning <Verbrauchernummer>".
Ne, habe extra gewartet. War gestern schon und in der Zwischenzeit sogar ein Restart wegen SolarForcast Update.
Jetzt nach dem "set ... consumerNewPlanning <Verbrauchernummer>" steht im Log: "WD_SolarForecast - Consumer planning of "Kühlschrank" deleted"
Gerade probiert ... habe einen Consumer:
consumer16 SolCastDummy6 icon=sani_buffer_electric_heater_side type=noSchedule power=1000
definiert.
In seinem Reading steht:
consumer16 name='SolarForecast Consumer Dummy 6' state='off' mode='can' planningstate='noSchedule'
Und das Mouse-Over zeigt gemäß SCreenshot.
Zeig mal dein Attribut.
Wie gesagt, nach dem "set ... consumerNewPlanning <Verbrauchernummer>" jetzt alles ok. "Planungstatus: noSchedule" und bei "Ein:" und "Aus:" keine Zeiten mehr. Seltsam. Danke!
Passt. Eine reguläre Neuplanung findet nach dem Status "finished" statt bzw. nach einem internen Plan. Das kann sich auch bis in den neuen Tag hinein ziehen, je nach den bisherigen Ramendaten.
Übrigens ... ein Restart würde nichts nutzen. SF merkt sich bei einem regulären Shutdown/Restart alle aktuellen Einplanungsdaten und die Status jedes definierten Consumers. Wäre ja sonst fatal. Im Hintergrund findet ein entsprechendes Management statt.
@Gerd
An den Netzwerkkomponenten kann es bei mir nicht liegen. Das gesamte Netzwerk ist Cat7 Konform installiert.
Früher waren einige Pis per Powerlan mit dem Netzwerk verbunden, bis ich diese Bereiche ebenfalls mit Cat7 nachinstalliert hatte. Powerlan taugte bei mir jedenfalls auch nicht für die FHEM Anwendungen.
Ich gebe dir Recht, das es für FHEM ratsam ist auf die Netzwerkkomponenten acht zu geben. Da kann man leicht das falsche als Fehlerursache verdächtigen.
Bei mir ist das System in den letzten 10 Jahren auch erheblich gewachsen.
FHEM ist auf 10 Pis verteilt, die aber für sich grundsätzlich autark arbeiten. Gewisse Bereiche will ich eigenständig haben, wie die Heizung, Solarthermie, PV. Ich hole mir von diesen Bereichen nur notwendige Datenpunkte für eine Zentrale Übersicht.
Wieviele Sensoren, Aktoren und Schnittstellen vorhanden müsste ich mal wirklich zählen. Es sind im gesamten System sicherlich über 200 Stk.
Auch die Systeme wachsen immer noch, wie jetzt der PV-Bereich mit SolarForecast, und ich lerne immer noch dazu.
@Heiko
Ich habe Anpassungen betreffend asynchron=1 vorgenommen.
asynchron=1 ist nur mehr setupMeterDev definiert.
Alles andere passte und entsprach ohnehin deinen Vorschlägen. Mit den Entfernungen von asynchron=1 ist die Systemlast gleich um einiges verringert worden.
Trotzdem taucht jetzt wieder Connection lost, trying a reconnect every 5 seconds. auf.
Kann das mit der Verbrauchsplanung zusammenhängen?
EDIT:
Ich habe den Eventmonitor einige Zeit betrachtet, und mir ist da wieder der Consumer 07 aufgefallen.
eventMonitor
2025-07-08 17:21:17.238 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:17.261 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:17.279 Global global SAVE
2025-07-08 17:21:20.248 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:20.269 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:20.287 Global global SAVE
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS Current_PowerBatIn_02: 570 W
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS Current_Consumption: 188 W
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS Current_Surplus: 6 W
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS special_BatPowerIn_Sum: 570 W
2025-07-08 17:21:22.904 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:23.224 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:23.571 Global global SAVE
2025-07-08 17:21:24.108 SolarForecast AB_WS_SS Current_PV: 249 W
2025-07-08 17:21:24.108 SolarForecast AB_WS_SS Current_Consumption: 243 W
2025-07-08 17:21:25.536 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:25.557 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:25.575 Global global SAVE
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Current_BatCharge_02: 62 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour00_SoCforecast_02: 73.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour01_SoCforecast_02: 82.3 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour02_SoCforecast_02: 84.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour03_SoCforecast_02: 82.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour04_SoCforecast_02: 79.1 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour05_SoCforecast_02: 76.7 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour06_SoCforecast_02: 74.1 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour07_SoCforecast_02: 71.4 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour08_SoCforecast_02: 68.7 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour09_SoCforecast_02: 66.3 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour10_SoCforecast_02: 62.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour11_SoCforecast_02: 58.5 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour12_SoCforecast_02: 55.8 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour13_SoCforecast_02: 56.5 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour14_SoCforecast_02: 55.4 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour15_SoCforecast_02: 57.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour16_SoCforecast_02: 60.2 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour17_SoCforecast_02: 65.8 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour18_SoCforecast_02: 72.9 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour19_SoCforecast_02: 80.7 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour20_SoCforecast_02: 87.9 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour21_SoCforecast_02: 95.3 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour22_SoCforecast_02: 99.4 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS special_BatWeightedTotalSOC: 51.00 %
2025-07-08 17:21:27.554 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:27.576 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:27.593 Global global SAVE
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS nextCycletime: 17:22:37
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS consumer01_currentPower: 97.5 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS consumer11_currentPower: 232.5 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS Current_GridConsumption: 543 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS Current_Consumption: 232 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS Current_Surplus: 17 W
2025-07-08 17:21:33.255 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:33.578 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:33.899 Global global SAVE
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_PowerBatOut_01: 0 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS consumer12_currentPower: 271.7 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_Consumption: 222 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_Surplus: 27 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_AutarkyRate: 0 %
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS special_BatPowerOut_Sum: 0 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS special_SunHours_Remain: 3.72
Kann das an meiner pumpControl liegen?
############################################################################
# Pumpensteuerung
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)
$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};
readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung
if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);
my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;
for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}
if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}
if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1"); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0"); # keine Interrupt-Freigabe
}
}
return;
}
ZitatKann das mit der Verbrauchsplanung zusammenhängen?
Ja und Nein. Wichtig ist ob und wieviele Daten zwischen dem FHEM Server und dem Browser ausgetauscht werden müssen (Änderungen in der Grafik, Readingänderungen usw.) und ob es bei diesem Datenaustausch ein Abbruch der longpoll Verbindung gibt die als Folge diese Meldung hat.
Im Normalfall kommt die Meldung mal und verschwindet nach dem Neuaufbau (5 Sekunden) wieder. Sollte natürlich nicht ständig passieren.
Hat sich ein Browsertab mal abgehängt einfach Refresh drücken und dann sollte es auch weitergehen.
Wie gesagt, kann mal passieren keine Frage, aber natürlich kein penetranter Dauerzustand.
ZitatIch habe den Eventmonitor einige Zeit betrachtet, und mir ist da wieder der Consumer 07 aufgefallen.
Ich möchte es weiter fassen ... versuche die Events weiter zu reduzieren.
Die Minimalvariante wäre im SF Device zu setzen:
event-on-change-reading state
state muß auf jedenfall aktualisieren (Grafik Update).
Ich gehe stark davon aus du wirst eine Abhängigkeit zwischen dem Eventvolumen und deiner Browsermeldung feststellen.
notbefore Startzeitpunkt Verbraucher nicht vor angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
notafter Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
notafter müsste eigentlich Endzeitpunkt lauten. Ist ein wenig verwirrend.
Ich würde das Startzeitpunkt weglassen. Verbraucher nicht vor bzw. Verbraucher nicht nach ist ausreichend.
Eine Frage zur Planung der Consumer.
Die Definition für consumer 04 lautetEG_WI_TRD:EG-Wirtschaftsraum+Trockner
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
exconfc=2
icon=scene_clothes_dryer
interruptable=EG_WI_TRD:SF_Int:1
mintime=300
mode=must
notafter=16:30
notbefore=08:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swstate=state:EIN:AUS
type=dryer
Warum greift die Planung nicht?
consumer04
consumer04_planned_start 08.07.2025 15:00:02
consumer04_planned_stop 08.07.2025 20:00:02
consumer04_planned_stop müsste um 16:30 anhalten.
Zitat von: Burny4600 am 08 Juli 2025, 19:50:09notbefore Startzeitpunkt Verbraucher nicht vor angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
notafter Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
notafter müsste eigentlich Endzeitpunkt lauten. Ist ein wenig verwirrend.
Ich würde das Startzeitpunkt weglassen. Verbraucher nicht vor bzw. Verbraucher nicht nach ist ausreichend.
Das interpretierst du evtl. falsch:
notbefore =>>> starte die "Einplanung" nicht
vor dieser Zeit
notafter =>>> starte die "Einplanung" nicht
nach dieser Zeit
(bedeutet NICHT schalte mich an und aus innerhalb dieser Zeit ;) )
Zitat von: Burny4600 am 08 Juli 2025, 17:17:20An den Netzwerkkomponenten kann es bei mir nicht liegen. Das gesamte Netzwerk ist Cat7 Konform installiert.
Früher waren einige Pis per Powerlan mit dem Netzwerk verbunden, bis ich diese Bereiche ebenfalls mit Cat7 nachinstalliert hatte. Powerlan taugte bei mir jedenfalls auch nicht für die FHEM Anwendungen.
Ich gebe dir Recht, das es für FHEM ratsam ist auf die Netzwerkkomponenten acht zu geben. Da kann man leicht das falsche als Fehlerursache verdächtigen.
Bei mir ist das System in den letzten 10 Jahren auch erheblich gewachsen.
FHEM ist auf 10 Pis verteilt, die aber für sich grundsätzlich autark arbeiten. Gewisse Bereiche will ich eigenständig haben, wie die Heizung, Solarthermie, PV. Ich hole mir von diesen Bereichen nur notwendige Datenpunkte für eine Zentrale Übersicht.
Wieviele Sensoren, Aktoren und Schnittstellen vorhanden müsste ich mal wirklich zählen. Es sind im gesamten System sicherlich über 200 Stk.
Auch die Systeme wachsen immer noch, wie jetzt der PV-Bereich mit SolarForecast, und ich lerne immer noch dazu.
@Chris,
Meine Anlage hat aus gleichen Gründen eine ähnliche Größe :) (8 PI's) - für einzelne Komponenten reicht auch PowerLan - dort ist das Problem, dasjenige worum es sich hier dreht, die durch WR produzierte PV-Energie welche den Sinus beeinträchtigt (Oberwellen) auch aus diesen Gründen hat die Ausführung (bei dir CAT7) nicht unbedingt was mit der im Router ankommenden Bandbreite zu tun.
Ich würde dir wirklich raten
1.) im Router mal einen 'Kabeltest' zu machen um die ausgehandelte Geschwindigkeit zu sehen
2.) mit den beiden im oberen Post genannten Einstellungen (QoS/Storm-Control-Rate) den Brodcast zu dämpfen
es sei denn dein internes Netzwerk ist deutlich schneller als 2GB (z.B. mit LAG) dann solle es unkritisch sein
Ist ja kein Risiko dabei - die Einstellungen lassen sich jederzeit wieder auf Default setzen und der Aufwand ist überschaubar - aber so kann man ausschließen Geister zu jagen. Und ich hatte seither keine Abbrüche, und negative Verbräuche mehr.
Gruß Gerd
PS @Heiko: Ist das ist Out-Topic hier?
ZitatPS @Heiko: Ist das ist Out-Topic hier?
Alles gut, wir sind im Ausstausch und ich schweife auch gerne mal ab. Ansonsten könnt ihr euch damit in ein Technikforum zurückziehen wenn sich das Thema ausweiten wollte. ;)
@all,
ich habe die max. möglichen Consumer im Modul auf 20 erhöht.
Es lässt auch noch mit etwas guten Willen in der Flowgrafik unterbringen. In dem Screenshot habe ich dazu eingestellt:
consumerdist=90
size=600
h2consumerdist=190
showconsumerdummy=0
Das Update befindet sich im contrib.
LG,
Heiko
Hallo Heiko,
ich war die letzten Tage auf der Suche nach der Ursache für die fehlerhafte Darstellung von Umlauten und Sonderzeichen wie in °C u.a.
Rudi hatte sich der Sache angenommen und Module identifiziert, die zwischen dem 28.6. und 5.7. (Zeitpunkte meiner Fhem-Updates) geändert wurden, siehe dazu auch den verlinkten Beitrag:
https://forum.fhem.de/index.php?topic=142010.msg1344512#msg1344512 (https://forum.fhem.de/index.php?topic=142010.msg1344512#msg1344512)
Ab dem 5.7. sehe ich die falsche Darstellung der Umlaute und von Sonderzeichen.
Um es kurz zu machen, ein Update deines Moduls im Zeitraum 28.6. bis 5.7. scheint sich als Ursache herauszukristallisieren. Wenn ich dein Modul disable, wird alles richtig angezeigt, wenn ich das disable-Attribut lösche, werden die Umlaute etc. wieder sehr komisch dargestellt.
Da ich dein Modul und dein enormes Engagement sehr schätze und respektiere und ich sehr gerne dein Modul weiter nutzen möchte, wollte ich dich bitten in dieses Problem reinzuschauen.
Beschreibung und Darstellung des Fehlers sind hier dokumentiert:
https://forum.fhem.de/index.php?topic=142010.0 (https://forum.fhem.de/index.php?topic=142010.0)
Viele Grüße Gisbert
Hallo Gisbert,
lade die V aus meinem contrib. Wir hatten kürzlich erst einen Fehler behoben mit typografischen Anführungszeichen der sich bei alexa mit englischer Einstellung gezeigt hatte. Der fix ist noch nicht eingecheckt.
Vllt. hast du auch engl. eingestellt. Wenn das nicht hilft brauche ich ein konkretes Beispiel denn bei mir werden Umlaute korrekt dargestellt.
LG,
Heiko
Zitat von: 300P am 08 Juli 2025, 20:00:06Das interpretierst du evtl. falsch:
notbefore =>>> starte die "Einplanung" nicht vor dieser Zeit
notafter =>>> starte die "Einplanung" nicht nach dieser Zeit
Das habe ich richtig verstanden.
Zitat von: 300P am 08 Juli 2025, 20:00:06(bedeutet NICHT schalte mich an und aus innerhalb dieser Zeit ;) )
Für was definiere ich für den Consumer ein notbefore und ein notafter, wenn die Planung das ohnehin nicht berücksicht?
EG_KUE_GSD:EG-Küche+Geschirrspüler
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
exconfc=2
icon=scene_dishwasher
interruptable=EG_KUE_GSD:SF_Int:1
mintime=180
mode=must
notafter=19:00
notbefore=06:30
.....Im Zeitraum 06:30 bis 19:00 ist die Einplanung mit einer Mindestzeit von 180 min möglich.
Die Verbraucherplanung gibt aber vor, EIN um 17:00 und AUS um 20:00.
Anscheinend verstehe ich hier immer nich etwas falsch.
Guten Morgen,
ZitatFür was definiere ich für den Consumer ein notbefore und ein notafter, wenn die Planung das ohnehin nicht berücksicht?
Doch, die Planung berücksichtigt es ja. Wie 300P schon schrieb passiert mit dieser Angabe:
notbefore=06:30
notafter=19:00
Die
Einplanung des Starts des Consumerzyklus erfolgt nicht vor 06:30 und nicht nach 19:00. Das heißt der geplante Start des Consumers erfolgt optimiert irgendwo zwischen 06:30 und 19:00. Das ist aber der Start des Zyklus. D.h. im Extremfall startet der Consumer 19:00 und läuft dann die eingegebene mintime, hier mintime=180 Minuten.
ZitatDie Verbraucherplanung gibt aber vor, EIN um 17:00 und AUS um 20:00.
In deinem konkreten Fall wird der Start um 17:00 eingelant (im Zeitfenster 06:30 bis 19:00) und läuft dann 180 Minuten = 3h bis 20:00.
Alles richtig wie definiert.
Vielleicht sind hier die Begriffe missverständlich. (Nur) der "Start" wird in diese Zeitspanne gelegt. Wenn man "Einplanung" als den Slot versteht, in dem das Gerät laufen wird, ist es nicht richtig. Ich war da auch drüber gestolpert und hatte die Zeiten nachträglich angepasst.
Ja wahrscheinlich. In der ComRef habe ich aktuell stehen:
notbefore Startzeitpunkt Verbraucher nicht vor angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
notafter Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
Hier steht ausdrücklich
Startzeitpunkt drin. Vllt. muß ich das noch eindringlicher schreiben?
Schreibe evtl. einfach dazu:
notafter Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
Achtung:
Der sich ergebende Schaltzeitpunkt zum Beenden (off) kann in beiden Fällen jedoch weit über den gewählten Zeitpunkt "notafter" hinausgehen. Hierdurch wird lediglich der mögliche Startzeitpunkt eingeschränkt, jedoch in keinem Fall die eingeplante Laufzeit.
Zitat von: DS_Starter am 09 Juli 2025, 09:30:30Hier steht ausdrücklich Startzeitpunkt drin. Vllt. muß ich das noch eindringlicher schreiben?
Also das finde ich schon eindeutig. War das mal anders beschrieben? Weiß auch nicht, wo ich das mir der "Einplanung" in diesem Zeitraum her habe. Vermutlich die allgemeine Verwirrung ;-)
ZitatWar das mal anders beschrieben?
_Irgendwann_ vielleicht ... steht aber schon sehr lange so drin.
Zitat von: DS_Starter am 09 Juli 2025, 09:20:13Die Einplanung des Starts des Consumerzyklus erfolgt nicht vor 06:30 und nicht nach 19:00. Das heißt der geplante Start des Consumers erfolgt optimiert irgendwo zwischen 06:30 und 19:00. Das ist aber der Start des Zyklus. D.h. im Extremfall startet der Consumer 19:00 und läuft dann die eingegebene mintime, hier mintime=180 Minuten.
ZitatDie Verbraucherplanung gibt aber vor, EIN um 17:00 und AUS um 20:00.
In deinem konkreten Fall wird der Start um 17:00 eingelant (im Zeitfenster 06:30 bis 19:00) und läuft dann 180 Minuten = 3h bis 20:00.
Ok.
Jetzt habe ich es verstanden, dass durch die mintime die Planungszeit von 19:00 überschritten werdem kann.
Ich nahm an, dass ein Betrieb nur in diesem Zeitfenster erfolgt, auch wenn die mintime noch nicht erreicht wurde.
Da muss ich dann einige Zeiten bei den Consumern ändern.
Aber zurück zur ständigen Wiederholung von
Connection lost, trying a reconnect every 5 seconds..
Verursacht von consumer 07, wenn ein aktives Planungsfenster vorhanden ist.
Entferne ich unter dem Attribut ctrlUserExitFn die Zeile
::pumpControl ($name, '07', 180); ist sofort keine Wiederholung von
Connection lost.... ersichtlich.
Irgendwie habe ich in der 99_mySolarForecastUtils.pm
pumpControl anscheinend einen Fehler.
############################################################################
# Pumpensteuerung
############################################################################
sub pumpControl {
my $name = shift;
my $c = shift; # Nummer des Verbrauchers, z.B. 07
my $mneed = shift; # Soll-Pumpenzeit, z.B. 300 (Minuten)
$c = sprintf "%02d", $c; # falls führende 0 vergessen wird
my $pump = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', ''); # Devicename der Pumpe
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate); # akt. Status des Consumers
my $dhash = $defs{$pump};
readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0); # default keine Zyklusbeendigung
if ($simpCstat =~ /started|interrupt|continu/xs) { # Vorgang ist gestartet
my $t = time;
my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon', '');
my $stopts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
return if(!$startts || !$stopts);
my $mrest = sprintf '%.0f', (($stopts - $t) / 60); # Restlaufzeit (Minuten)
my $dt = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
my $day = $dt->{day};
my $hstart = int $dt->{hour} + 1; # lfd. Stunde bei Pumpen Start
my $msum = 0;
for my $hod (1..24) { # bisherige Laufzeit der Pumpe
next if($hod < $hstart);
$hod = sprintf "%02d", $hod;
$msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
}
if ($msum >= $mneed) {
readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0); # vorfristige Zyklusbeendigung
return;
}
if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1"); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0"); # keine Interrupt-Freigabe
}
}
return;
}
Fehler ist da nicht drin. Allerdings wird bei den Statements:
* fhem ("set $name attrKeyVal consumer$c interruptable=1");
* fhem ("set $name attrKeyVal consumer$c interruptable=0");
jedesmal ein Aktualisierungszyklus durchlaufen weil das Consumerattribut geändert wird. Das hat Auswirkung auf ein Eventaufkommen und Systemlast (wie weiter vorn diskutiert) je nachdem wie häufig der Zyklus passiert.
Hilfreich könnte folgende Ergänzung sein. Oben nach "my $plstate":
my $plstate = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', ''); # die nächste Zeile ergänzen ->
my $intbl = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);
Und dann innerhalb der if-Bedingung diese Statements verwenden:
if ($mrest >= ($mneed - $msum)) {
fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl); # Interrupt-Freigabe
}
else {
fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl); # keine Interrupt-Freigabe
}
Dadurch werden die Befehle nur einmalig ausgeführt wenn die jeweilige $intbl-Zusatzbedingung erfüllt ist und dürfte die Systemlast deutlich reduzieren.
Probier das mal aus.
Zitat von: DS_Starter am 09 Juli 2025, 00:23:59Hallo Gisbert,
lade die V aus meinem contrib. Wir hatten kürzlich erst einen Fehler behoben mit typografischen Anführungszeichen der sich bei alexa mit englischer Einstellung gezeigt hatte. Der fix ist noch nicht eingecheckt.
Vllt. hast du auch engl. eingestellt. Wenn das nicht hilft brauche ich ein konkretes Beispiel denn bei mir werden Umlaute korrekt dargestellt.
LG,
Heiko
Hallo Heiko,
das war es tatsächlich - mit der neuen Version aus deinen contrib sieht jetzt wieder alles gut aus. In Debian, auf dem mein Fhem läuft, habe ich US-englische Sprache eingestellt.
Du bist der beste, vielen, lieben Dank.
Gisbert
Freut mich dass dein Problem dadurch auch gelöst werden konnte. :)
Ich werde die Version aus dem contrib heute einchecken. Dann ist der Fix morgen früh offiziell verfügbar.
LG,
Heiko
@Heiko
Zitat von: DS_Starter am 09 Juli 2025, 10:40:01jedesmal ein Aktualisierungszyklus durchlaufen weil das Consumerattribut geändert wird. Das hat Auswirkung auf ein Eventaufkommen und Systemlast (wie weiter vorn diskutiert) je nachdem wie häufig der Zyklus passiert.
Das sieht jetzt anders aus. Und die Systemlast hat sich beim Pi4 auch reduziert.
Danke für den Tipp.
Ich ergänze es auch im Wiki.
@Burny4600
Noch ein Tipp zur "Event-Last-Analyse": Ich nutze dafür gerne die DOIFtools. Also nicht für einzelne Events, aber über die statistische Auswertung bekommt man einen Endruck, von wo die Last kommt. Und man kann bei Änderungen den Erfolg prüfen. Ich nutze zwar DOIF, die Tools sind aber unabhängig davon.
Hallo zusammen,
die V 1.54.1 ist eingecheckt. Hier nochmal die Inhalte im Überblick:
- die Anzahl der maximal möglichen Consumer ist auf 20 erhöht.
- die Verwendung von Dezimalstellen in der Balkengrafik ist abhängig von der Auswahl Wh, kWh für relevante Anzeigen (PVreal/Forecast, consumption/Forecast)
- attrKeyVal - Behebung unterschiedlicher Abarbeitungsprozesse bei Initiierung via GUI oder Skript
- BugFix "Wide character in syswrite" bzw. fehlerhafte Darstellung von Umlauten wenn EN als Systemsprache eingestellt
- interne Optimierungen
LG,
Heiko
PS:
Dieses FHEM Update wird bei mir heute Morgen als neu "gezogen" :
76_SolarForecast.pm:v1.54.0-s30101/2025-07-05 ;)
EDIT:
Hab wieder das Contrib "gezogen"
Im SVN sehe ich aber trotzdem die 1.54.1 vom 8.7.2025 in der Änderungshistorie ??
Jetzt nochmals per updatecheck kontrolliert - würde jetzt jetzt richtig geladen.
@Chris,
noch ein kleiner Hinweis zur Pumpensteuerung.
Du hast angegeben:
::pumpControl ($name, '07', 180)
D.h. die Pumpe soll 3h Laufzeit am Tag einhalten. Unser Script realisiert diese Zeit auch unter der Bedingung dass nicht genügend PV vorhanden ist, wobei die Phasen mit genügend PV bevorzugt verwendet werden.
Man kann sich mit "get ... pvHistory <Tag>" die Auswertung für den/die Consumer in der Stunde "99" anschauen und ggf. mit einem kleinen Programm abrufen und auswerten:
99 => pvapifcraw: -, pvfc: 17343, pvrl: 13768, pvrlvd: -, plantderated: -, rad1h: -
pvrl01: 13768, pvrl02: -, pvrl03: -, pvrl04: -
pprl01: -, pprl02: -, pprl03: -
confc: 7718, con: 10287, gcons: 506, conprice: -
gfeedin: 3923, feedprice: -
DoN: -, sunaz: -, sunalt: -
batin01: 0, batin02: -, batin03: -
batout01: 0, batout02: -, batout03: -
batmaxsoc01: 87, batmaxsoc02: -, batmaxsoc03: -
batsetsoc01: -, batsetsoc02: -, batsetsoc03: -
dayname: Mi,
cyclescsm01: 6, csme01: 0.00, hourscsme01: 9.95, avgcycmntscsm01: 99.50
cyclescsm02: 10, csme02: 0.00, hourscsme02: 5.00, avgcycmntscsm02: 30.00
Hier sind die hourscsme01, hourscsme02 von Interesse. Sie enthalten die kumulierten Laufstunden der Consumer an dem gewählten Tag. Die cyclescsmXX die Anzahl der EIN/AUS Zyklen und avgcycmntscsmXX die durchschnittliche Laufzeit (Minuten) pro Zyklus für den Tag. Hier im Beispiel sind es die Consumer 01, 02. Bei mir auf dem Testsystem sind es Dummies. Die Pumpensteuerung ist so im ctrlUserExitFn hinterlegt:
{
::pumpControl ($name, '01', 600);
::pumpControl ($name, '02', 300);
}
Der Consumer 01 soll also 10h und der Consumer 02 5h am Tag laufen. Am Consumer 01 hatte ich etwas herumgefummelt weswegen dort ein paar Minuten fehlen.
LG,
Heiko
@300P,
ich glaube du warst etwas zu früh dran. ;)
Ab 8:00 bist du auf der sicheren Seite denke ich.
LG,
Heiko
Zitat von: DS_Starter am 10 Juli 2025, 11:27:40Der Consumer 01 soll also 10h und der Consumer 02 5h am Tag laufen. Am Consumer 01 hatte ich etwas herumgefummelt weswegen dort ein paar Minuten fehlen.
Danke für die Hinweise.
Bei mir muss die Pumpe mindesten 3h am Tag laufen. Ist auch abhängig von der Aussen- und Wassertemperatur, aber in einen vorgegebenem Zeitfenster.
Derzeit bin ich noch bei den Basics von SolarForest und teste diverse Szenarien durch, um das System besser zu verstehen.
Es wird sich wahrscheinlich noch einges ändern, wenn die Hybridinverter eingebunden sind.
Zitat von: DS_Starter am 10 Juli 2025, 11:28:43@300P,
ich glaube du warst etwas zu früh dran. ;)
Ab 8:00 bist du auf der sicheren Seite denke ich.
LG,
Heiko
Der frühe Vogel 🐦 fängt den Wurm 🪱
(Diesmal wohl nicht 😇)
Bin sonst auch um 7 oder 1/2 8 Uhr mit Update-laden dabei - manchmal auch schon um 6 Uhr...............
Hab daran (erst ab 8:00 Uhr) deshalb wohl gar nicht mehr gedacht 🤔
Hallo Heiko,
mir ist da etwas aufgefallen.
Die graphicHistoryHour ist aktuell auf 12 eingestellt und in der 11. Stunde ist die 1. Spalte nicht in Ordnung.
* Das Wetter zeigt "?".
* Als Stunde wird "-1" anstelle von 23 angezeigt.
* Ich meine, dass der Differenzwert auch schon mal nicht gepasst hat.
Morgens um 8 ist alles OK.
Viele Grüße und Danke für Deinen unermüdlichen Einsatz hier,
Guido.
Moin Guido,
ja das Phänomen kenne ich. "Leider" kann man es nicht beliebig nachstellen, sondern muß die Ursache versuchen zu ergründen wenn es gerade mal auftritt. Meistens habe ich da gerade etwas anderes zu tun und wenn ich Zeit hätte kommt es nicht. Man hat nur eine Stunde dazu Zeit ;)
Das Wetter-Fragezeichen wird bewusst gesetzt, wenn es keine Wetterinformation gibt und "-1" ist auch eine Folge fehlender Daten (müsste ich nochmal nachschauen). Das heißt also für diese betreffende Stunde liegen keinerlei Daten vor. Warum in diesem Fall keine Daten vorliegen, konnte ich bisher nicht ergründen. Falls es mal auftritt, ist nach meinen Beobachtungen ausnahmslos die Stunde 23 vom Vortag. Es hat also irgendwas mit dem Tageswechsel zu tun, was aber im Normalfall keinerlei Probleme bereitet.
LG,
Heiko
Moin Heiko,
mich stört es nicht weiter und Auswirkungen hat es vermutlich auch nicht.
Also kein Grund da jetzt Zeit zu verbrennen.
VG,
Guido.
Lässt sich plantControl -> reductionState und plantControl -> feedinPowerLimit irgendwie deaktivieren, auch wenn zwar Batterien vorhanden sind und man es trotzdem nicht nutzt.
Hallo Chris,
du brauchst die Parameter einfach nicht setzen.
Lg
Hallo,
gibt es eine Möglichkeit im Flow den Alias der Consumer anzuzeigen. Nicht als Mouseover, sondern als Text über dem Icon o.ä.
Sehe ich den Wald vor lauter Bäumen nicht, oder gibts die Möglichkeit nicht?
Grüße,
Hugo
Hallo nochmal,
ich hätte noch zwei Fragen:
* Muss man das Attribut plantControl->reductionState zusätzlich zu plantControl->feedinPowerLimit angeben, oder ist das alternativ.
* Wenn man beides angeben muss, wozu dient dann die Information des reductionStates?
Hintergrund: Mein Fronius liefert das nicht von sich aus und daher könnte ich das nur "schätzen", wenn sich die Einspeiseleistung kurz vor der Grenze befindet.
Grüße,
Hugo
Hallo Hugo,
willkommen bei den PV-Propheten. ;)
Zitatgibt es eine Möglichkeit im Flow den Alias der Consumer anzuzeigen. Nicht als Mouseover, sondern als Text über dem Icon o.ä.
Zur Zeit gibt es diese Möglichkeit nicht, vor allem weil die Breite des Alias-Textes unvorhersehbar ist. Alternativ könnte ich die Nummer des Consumers als Andruckmöglichkeit vorsehen.
ZitatMuss man das Attribut plantControl->reductionState zusätzlich zu plantControl->feedinPowerLimit angeben, oder ist das alternativ.
Weder noch. Beide Attribute sind optional und steuern verschiedene Aufgaben wie sie in der Commandref beschrieben sind.
ZitatWenn man beides angeben muss, wozu dient dann die Information des reductionStates?
Muß man nicht, aber plantControl->reductionState teilt dem Modul mit dass die Anlage abgeregelt wurde/ist. Es gibt unterschiedliche Gründe dafür. Ein Grund könnte sein, dass das Einspeiselimit der Anlage erreicht ist UND die uberschüssige Energie nicht mehr durch die vorhandenen Batterien aufgenommen werden kann weil diese bereits voll geladen sind.
Also ist plantControl->reductionState für das Modul ein Informationsstatus und es ist davon auszugehen, dass PV-Prognose und reale Erzeugung nicht zusammenpassen werden und somit der Datensatz der betreffenden Stunde nicht für Trainings- un Korrekturzwecke geeignet ist.
LG,
Heiko
Hallo Heiko,
danke für die schnelle Antwort.
Ich muss mich noch an den modularen Aufbau gewöhnen, der solche "Hinweise" braucht. Mein selbst gestrickter, monolithischer Block "weiß" ja alles, ist aber ab dem Speicher der kommen wird nicht mehr sinnvoll wartbar/erweiterbar.
Danke für das tolle Modul.
ZitatZur Zeit gibt es diese Möglichkeit nicht, vor allem weil die Breite des Alias-Textes unvorhersehbar ist. Alternativ könnte ich die Nummer des Consumers als Andruckmöglichkeit vorsehen.
Mein Featurerequests wäre ein zusätzliches Attribut z.B. displayname einzuführen, das auf z.B. 15 Zeichen limitiert ist und über/unter dem Consumer angezeigt wird, wenn es definiert ist. Dann kann man einen sprechenden (langen) Namen vergeben und etwas kurzes, mit dem man den Consumer im Flow schnell identifizieren kann.
Grüße,
Hugo
Zitat von: hugomckinley am 14 Juli 2025, 12:39:05Mein Featurerequests wäre ein zusätzliches Attribut z.B. displayname einzuführen, das auf z.B. 15 Zeichen limitiert ist und über/unter dem Consumer angezeigt wird, wenn es definiert ist. Dann kann man einen sprechenden (langen) Namen vergeben und etwas kurzes, mit dem man den Consumer im Flow schnell identifizieren kann.
Hallo Hugo
Ich habe dieses ,Dilemma' mit MQTT- Device gelöst, d.h. SF sieht die,'Original-Device' gar nicht sondern nur MQTT, die sprechende Namen haben, dort hab ich nur die für SF notwendigen topic abonniert und wo notwendig kombiniert
Auf diese Weise sind inzwischen 11 WR und über 70 Consumer an SF angebunden. Ein HybridWR ist als Batterie und als WR mit an Bord. Logik z.B. Ladung Batterie, Prioritäten.... läuft auf den eigentlichen Device und wird von SF mit Signalen versorgt
Vielleicht kein Idealweg,aber mir hat es in einer über Jahre gewachsen Anlage, geholfen gewachsene Logik von neuem zu entkoppeln.
Gruß Gerd
Hallo Gerd,
ich kann mir das jetzt ohne Details nicht vorstellen, wie deine Steuerung funktioniert, aber mein "Problem" ist nur optischer Natur ;-)
Dazu würde ich auf keinen Fall MQTT als zusätzlichen Layer einziehen.
Mein Ziel ist es derzeit, dass ich jetzt die "wenigen" Geräte, die meine eigene Logik steuert, in SF zu überführen und dort zu schalten.
Dazu muss ich mir, soweit ich das bis jetzt verstanden habe, die passenden swoncond und swoffcond basteln um die entsprechenden Randbedingungen zu berücksichtigen.
Auch die locktime werde ich verwenden, da ich bisher alles mit DOIF und wait-timern gelöst habe.
Könntest du mir beispielhaft die notwendigen Definitionen eines deiner Geräte zukommen lassen, vielleicht kan ich ja was abkucken?
Danke!
Grüße,
Hugo
Da hätte ich auch noch gleich eine Frage dazu, wo ich keine Antwort gefunden habe:
Ist es möglich als PerlCode bei swoncond eine Funktion aus der 99_myUtils.pm zu verwenden.
Ein erster Versuch führt leider nur zu:
ERROR in interruptable or swoffcond Code execution: Undefined subroutine &FHEM::SolarForecast::CheckWPOff called at (eval 170417) line 1.Die Funktion lässt sich aber in der Befehlszeile von FHEM aufrufen und funktioniert.
Grüße,
Hugo
Hallo Hugo,
wenn du eine Funktion außerhalb des SolarForecast-Packages im "main" aufrufen willst, mußt du die Funktion mit zwei führenden Doppelpunkten schreiben, also z.B.:
{::CheckWPOff}
Funktionen in der 99_myUtils.pm liegen im "main" Package, welches man damit erreicht. Auch "main::CheckWPOff" wäre möglich.
LG,
Heiko
Sehe ich das richtig, dass man bei der surpmeth "median" oder "avg" nicht sagen kann, ob das der Median oder der Durchschnitt der letzten 5sec oder der letzten 5 Minuten ist, sobald man einen oder mehrere Consumer/Inverter mit asynchron=1 hat? In diesem Fall ist ja plantControl->cycleInterval eigentlich nicht mehr relevant bei vielen Events, da ja jeder eine Neuberechnung auslöst.
Sehe ich das richtig?
Hintergrund: Bisher prüfe ich, ob der Überschuss für eine gewisse Zeit (einige Minuten, kommt auf den Verbraucher an) über seiner Leistung + Zuschlag liegt. Das führt dazu, dass ein kurzes Aufreißen der Wolkendecke, nicht zu einem Einschalten führt. Ebenso in umgekehrter Richtung, dass eine Wolke die 2 Minuten die PV-Leistung senkt nicht zum Ausschalten des Verbrauchers führt.
Dieses Verhalten könnte ich mit dem Median oder dem Durchschnitt wahrscheinlich auch abbilden, aber nur wenn das der Wert in einem gewissen (einstellbaren) Zeitraum ist und nicht über eine gewisse Anzahl von Werten, da ich ja nicht sagen kann, ob das der Median/Durchschnitt von 30 Sekunden oder 5 Minuten ist.
Nebeneffekt ist, dass ich bei mir über die Wartezeiten die Verbraucher priorisieren kann. z.B. erhöht die Poolpumpe die Leistung nach 3 Minuten, die Wärmepumpe schaltet aber erst nach 6 Minuten ein, um ein Takten möglichst zu vermeiden. Das führt auch dazu, dass die WP nur dann aktiv wird, wenn der Überschuss für beide reicht. Wenn der Überschuss zwar für die Poolpumpe oder die Wärmepumpe reicht, aber nach dem Hochschalten der Poolpumpe sich die WP nicht mehr ausgeht, wird dieser Timer in den folgenden Minuten nach dem Hochschalten der Poolpumpe zurück gesetzt und die Wärmepumpe muss (weiter) warten, oder es geht sich gar nicht mehr aus.
d.h. über das unterschiedlich verzögerte Einschalten kann ich die Verbraucher priorisieren und die waittimer sorgen für ein stabiles und schwankungstolerantes Schaltverhalten.
So schaltet die WP als erstes aus, denn ohne kann die Pumpe wahrscheinlich weiter laufen. Damit die WP nicht zu oft taktet, aber erst nach z.B. 7 Minuten und die Pumpe nach 9 Minuten usw.
Das alles hat jetzt noch nichts mit einem Forecast zu tun, denn das ist nur das Folgen der Überschussleistung und da brauche ich keine Vorhersage, da dieses Verhalten von Sonneaufgang bis Sonnenuntergang gilt.
Die Verbesserung/Erweiterung, die ich mir durch SF erhoffe ist, dass ich mit der Vorhersage dann die Wärmepumpe fürs Haus, Batterieladung und E-Auto in Abhängigkeit der Prognose zum passenden Zeitpunkt "einzwicken" kann, damit es im Haus warm ist und das Auto voll (genug) wird usw.
In dieser Zeit können dann andere (niederpriorisierte) "Überschussverbraucher" ausgeschaltet, bzw. runter geregelt werden. z.B. muss das Auto geladen werden, auch wenn der Pool noch keine Badewanne ist ;-)
Dieses Verhalten sollte auch möglich sein, wenn diese hochpriorsierten Verbraucher (WP-Haus, e-Auto, Batterieladung) über die Prognose von SF gesteuert werden und die "Überschussvernichter" extern, wie bisher. Vom Gefühl her ist das besser zu kontrollieren, wenn alles über SF läuft.
Ausserdem wäre es leichter beherschbar, wenn das ganze Strommanagement an einer Stelle passiert und nicht vom Zusammenspiel von zwei Systemen, die nur indirekt üner den Überschuss kommunizieren, abhängt.
Ich weiß nicht, ob das hier die richtige Stelle ist, aber das sind so meine Überlegungen und mir will nicht einfallen, wie ich das mit SF abbilden kann, ohne etwas mit den waittimern von DOIF vergleichbarem.
Bitte um Korrektur, oder Hinweise, ob ich da auf dem Holzweg bin, oder ob ich nur nicht sehe, wie das funktionieren kann.
Grüße,
Hugo
ZitatSehe ich das richtig, dass man bei der surpmeth "median" oder "avg" nicht sagen kann, ob das der Median oder der Durchschnitt der letzten 5sec oder der letzten 5 Minuten ist, sobald man einen oder mehrere Consumer/Inverter mit asynchron=1 hat? In diesem Fall ist ja plantControl->cycleInterval eigentlich nicht mehr relevant bei vielen Events, da ja jeder eine Neuberechnung auslöst.
Sehe ich das richtig?
Ja, das siehst du richtig.
ZitatDieses Verhalten könnte ich mit dem Median oder dem Durchschnitt wahrscheinlich auch abbilden, aber nur wenn das der Wert in einem gewissen (einstellbaren) Zeitraum ist und nicht über eine gewisse Anzahl von Werten, da ich ja nicht sagen kann, ob das der Median/Durchschnitt von 30 Sekunden oder 5 Minuten ist.
Ja richtig. Die asynch-Einstellung ist in diesem Kontext nicht hilfreich.
Wenn man eine regelmäßige Bezugsgröße bzgl. der Zyklusabarbeitung braucht, sollte asynch nicht gesetzt werden.
Evtl. kann man mit "locktime" ergänzend auf das Schaltverhalten Einfluß nehmen.
LG,
Heiko
Zitat von: hugomckinley am 16 Juli 2025, 19:05:55Könntest du mir beispielhaft die notwendigen Definitionen eines deiner Geräte zukommen lassen, vielleicht kan ich ja was abkucken?
Hallo Hugo,
Das mach ich gerne - wird aber bisschen dauern da ich derzeit nur mit dem Handy unterwegs bin und so das kopieren von Code fehlerträchtig ist. Ich hoffe das passt?
Ich habe die Lösung gewählt weil die eigentlichen Device auf unterschiedlicher Hardware laufen so bleib ich flexibel.
Gruß Gerd
@Heiko
Ich habe eine Bitte betreffend der Batterieanzeige.
Derzeit sind meine zwei unabhängigen Batterieeinheiten in der Anzeige vermischt. Ich vermute das auch daraus der Stromfluss, egal in welche Richtung, immer grün angezeigt wird.
Derzeit habe ich noch keine Idee wie ich die Visualisierung entsprechend umstellen kann.
Wenn du einmal an den Hybridinvertern arbeitest, wäre eine Änderung der Batterieeinheiten hilfreich.
Zur Erinnerung:
Ich habe zwei unabhängige Hybridinverter.
Jeder Hybridinverter hat mehrere ihm zugeteilte Batterieinheiten die als gesamte Einheit zu betrachten sind (Batteriekaskade pro Hybridinverter).
Darum müssten eine Zuteilung bei den Hybridinverter erfolgen, wo jeder Hybridinverter seine eigene Batterie hat.
Wie gesagt, wenn du einmal mit den Hybridinvertern anfängst.
Kleine Codeschnipsel für diejenigen die immer wieder die Contrib-Versionen zum Testen laden (FHEM auf RPI)
A - >>Userattribut anlegen (hinzufügen)
attr Forecast userattr userFn_LoadContribcUpdate:1,0
B - >>ctrlUserExitFn anlegen (oder ergänzen)
{
# BEGIN ######## Load_Contrib_Update #######
#
# Wenn attr userFn_LoadContribcUpdate = 1 dann ...
# lade das aktuelle nur 1 x das Solarforecast Update ...
# aus dem Contrib von DS_Starter.
my $updatefromcontrib = AttrVal ($name, 'userFn_LoadContribcUpdate', "0");
if ($updatefromcontrib eq "1") {
# lade die aktuelle Dateiversion vom Contrib DS_Starter
Log3 ($name, 2, qq{$name - start download Update Solarforecast from Contrib ====>>> wird gestartet});
fhem ('"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"');
# setze aber sofort wieder zurück auf 0 (= nicht weiter laden >> 1 x reicht)
Log3 ($name, 2, qq{$name - end download Update Solarforecast from Contrib});
fhem (" attr $name userFn_LoadContribcUpdate 0");
Log3 ($name, 2, qq{$name - attr $name userFn_LoadContribcUpdate 0 ====>>> wurde ausgeführt});
}
#
#
# ENDE ######## Load_Contrib_Update #######
}
C - >>Anzeige im Bereich graphicHeaderOwnspec irgendwo einfügen:
ContribUpdate:userFn_LoadContribcUpdate
Im graphicHeaderOwnspec setzt man dann o.g. von 0 auf 1. Als Ergebnis wird einmalig die aktuelle Version aus dem Contrib von DS_Starter geladen.
Nicht vergessen !!!
Manuelles "shutdown & restart" aktiviert erst die frisch geladene Testversion !!!
@Burny4600, bin nicht sicher, ob es dir hilft:
Ich hab zwar nur einen Hybridinverter, habe aber für diesen im Modul zwei Inverter angelegt, wobei der eine den Fluß von/zur Batterie darstellt.
Hier seine Definition (mit strings=none und ac2dc bzw. dc2ac):
SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=PowerFlow_Site_P_DC_OUT:W dc2ac=PowerFlow_Site_P_DC_IN:W capacity=7680 asynchron=1
Hallo zusammen,
nur zur Info, morgen ist ein Update verfügbar welches aber nur mehr Debug Infos liefert -> https://forum.fhem.de/index.php?msg=1344951.
LG,
Heiko
Einige Fragen die sich mir gerade stellen:
Angenommen ich habe 3 Consumer mit 1500W, 600W und 300W mit interupptable=1.
Die PV Leistung geht zurück und es werden 1800W bezogen.
Welche Consumer, werden in welcher Reihenfolge abgeschaltet?
Gibt es da ein Timing? Oder eine Priorisierung?
Etwas OT, aber so ist mir das in den Kopf gekommen:
Meine Anforderung wäre, dass die Verbraucher in einer gewissen Reihenfolge abgeschaltet werden. (unabhängig von der Leistung)
Angedachte Lösung: Meine Überlegung wäre jetzt, dass ich interruptable vom jeweils vorherigen Verbraucher abhängig mache.
@Heiko: Wenn das alles fertig ist und so funktioniert wie gewollt, schreibe ich es als Beispiel ins Wiki
Grüße,
Hugo
Und noch eine:
Ist es bei surpmeth=median auch möglich eine Anzahl anzugeben? Wenn ja, wie?
Hallo Hugo,
ZitatWelche Consumer, werden in welcher Reihenfolge abgeschaltet?
Gibt es da ein Timing? Oder eine Priorisierung?
Ja, in gewisser Weise. Die Consumer werden bei jeden Zyklus sequentiell aufsteigend entsprechend ihrer Nummer 01, 02, 03 ... behandelt.
ZitatEtwas OT, aber so ist mir das in den Kopf gekommen:
Meine Anforderung wäre, dass die Verbraucher in einer gewissen Reihenfolge abgeschaltet werden. (unabhängig von der Leistung)
Angedachte Lösung: Meine Überlegung wäre jetzt, dass ich interruptable vom jeweils vorherigen Verbraucher abhängig mache.
Das ist quasi eine Chain die aufgebaut werden soll. Kann man machen. Dazu kann man z.B. das auto-Reading benutzen.
Ausgangszustand: - auto für alle Consumer "on"
-> sind alle Consumer eingeschaltet? -> Ausschalten "auto" für alle Consumer außer dem "Master"
-> ist der Master beendet ("finished") ? -> "auto" für den nächsten Consumer wieder "on" schalten
-> ist dieser Consumer "finished" ? -> "auto" für den nächsten Consumer wieder "on" schalten
-> usw. ....
-> wenn der letzte Consumer "finished" ist alle wieder auto "on"
Eine solche Logik kann man im ctrlUserExitFn einbauen.
ZitatIst es bei surpmeth=median auch möglich eine Anzahl anzugeben? Wenn ja, wie?
Nein. Macht auch keinen Sinn. Median verwendet den mittleren Wert eines nach Größe geordneten Arrays aller gespeicherten Werte. Bei z.B. 7 vorhandenen Werten ist es der Wert an der 4. Stelle (Mitte bei ungeraden Zahlen). Bei gerader Anzahl der Werte ist es der Durchschnitt der beiden mittleren Werte, also z.B. Durchschnitt Wert 5 und 6 bei 10 vorhandenen Werten.
LG,
Heiko
Zitat von: grappa24 am 18 Juli 2025, 16:26:49SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=PowerFlow_Site_P_DC_OUT:W dc2ac=PowerFlow_Site_P_DC_IN:W capacity=7680 asynchron=1
Ändert sich bei dir die Farbe des Energieflusses?
Bei mir ändert sich nur die Flussrichtung, aber der Beam bleibt immer grün.
@all,
morgen gibt es nochmal ein Update.
ctrDebug ist um collectData_long ergänzt. Ich habe collectData aufgeteilt und ein Teil in collectData_long delegiert um die Übersicht des Debug zu verbessern. In collectData sind die Energie- und Leistungswerte enthalten. collectData_long ergänzt Infos zu Wetter- und Astrodaten, welche nicht so oft im Debug benötigt werden.
(Liegt auch im contrib)
LG,
Heiko
Zitat von: roadghost am 06 Juli 2025, 16:00:24Ich weiß nicht wen man sonst noch fragen könnte, da ja, soweit ich das verstehe, SF und FHEMWEB involviert sind. Du betreust ja SF, und wer ist verantwortlich für FHEMWEB ? Eventuell sehen 12 Augen mehr .... ??
Falscher Thread.
pah
Zitat von: Burny4600 am 19 Juli 2025, 18:09:18Zitat von: grappa24 am 18 Juli 2025, 16:26:49SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=PowerFlow_Site_P_DC_OUT:W dc2ac=PowerFlow_Site_P_DC_IN:W capacity=7680 asynchron=1
Ändert sich bei dir die Farbe des Energieflusses?
Bei mir ändert sich nur die Flussrichtung, aber der Beam bleibt immer grün.
auch bei mir ändert sich nur die Flußrichtung, allerdings "färbe" ich den Beam ja orange
ZitatZitat von: grappa24 am 18 Juli 2025, 16:26:49auch bei mir ändert sich nur die Flußrichtung, allerdings "färbe" ich den Beam ja orange
Ich habe nun zwar zwei zusätzliche Inverter für die Batterieeinheiten, aber eine korrekte Berechnung des Energiebedarfs lässt sich so noch weniger darstellen.
Mit dieser Konfiguration werden alle Energieerzeuger addiert. Siehe Anhang.
Das stellt sich bei meinen Hybridinvertern etwas anders dar. Die Ladung der Batterien und die Generatoren dürfen aber nicht in den Verbrauch mit einbezogen werden. Da müsste ich in die SF-Berechnungen direkt eingreifen können um das zu korrigieren.
Bei meinen verwendeten Hybridinvertern gibt es Eingänge für die PV-Module, einen Ein- bzw. Ausgang für die Batterien (Nur DC), einen Eingang für den Generator (Nur AC) und einen Ein- bzw. Ausgang für die Last (nur AC inklusive Grid) und einen Ausgang für die USV Verbraucher (nur AC).
Um das visuell und rechnerisch darzustellen, müssten Anpassungen gemacht werden. Zudem müssten die beiden Batterien getrennt in der Visualisierung dargestellt werden, und auch deren Berechnungen sind zu trennen.
Dazu müsste es neue feeds geben, die sowohl bei der Batterie und auch bei dem Producer zu ergänzen sind. Klingt einfach, ist es aber nicht, weil die bisherige SF Konfiguration komplett im Modul umgekrempelt werden müsste.
Dies Szenario könnte eigentlich so für meine Hybridinverter aussehen.
setupInverterDev01
Deye_12k_SFD icon=inverter@#0CFB0C:solar
strings=SuedOstDach,SuedWestWand
capacity=8700
pvIn=PV_Leistung__W:W
pvOut=Last__W:W
etotal=PV_Energie__kWh:kWh
limit=100
asynchron=1
setupBatteryDev01
Deye_12k icon=@dyn:@dyn:@dyn:@dyn show=2:bottom label=beside cap=24000
feed=Inv1
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
setupGeneratorDev01
AB_WG2KWD pcurr=Active_Power__W:W etotal=Active_Energy_Day__kWh:kWh
feed=Inv1
icon=Ventilator_wind@darkorange
setupUSVDev01
Out=USV__W:W
...............
####################################################################
setupInverterDev02
Deye_15k_SFD icon=inverter@#0CFB0C:solar
strings=SuedOstDach,SuedWestWand
capacity=13200
pvIn=PV_Leistung__W:W
pvOut=Last__W:W
etotal=PV_Energie__kWh:kWh
limit=100
asynchron=1
setupBatteryDev02
Deye_12k icon=@dyn:@dyn:@dyn:@dyn show=2:bottom label=beside cap=48000
feed=Inv2
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
setupGeneratorDev02
AB_NS6KWD pcurr=Active_Power__W:W etotal=Active_Energy_Day__kWh:kWh
feed=Inv2
icon=sani_garden_pump@darkorange
setupUSVDev02
Out=USV__W:W
...............
@all,
in meinem contrib liegt die V 1.54.4.
Mit dem Consumer Key 'aliasshort' kann man eine Kurzbeschreibung der Consumer in der Flußgrafik einblenden.
Es stehen dafür 10 Zeichen (keine Leerzeichen) zur Verfügung.
Je nach Anzahl eurer Consumer müsst ihr evtl. mit flowGraphicControl die Grafik passend einrichten.
Das Beispiel in meinem Screenshot arbeitet mit:
size=480
animate=1
homenodedyncol=1
consumerdist=160
strokeconsumerdyncol=1
h2consumerdist=20
strokewidth=17
showGenerators=1
LG,
Heiko
@Chris,
ZitatIch habe nun zwar zwei zusätzliche Inverter für die Batterieeinheiten, aber eine korrekte Berechnung des Energiebedarfs lässt sich so noch weniger darstellen.
Mit dieser Konfiguration werden alle Energieerzeuger addiert. Siehe Anhang.
Dann stimmt aber noch etwas im Setup nicht. Die Flüsse der Batterieinverter werden vom Knoten subtrahiert sofern die Laufrichtung (d.h. In/Out) richtig verwendet wird.
Leider sehe ich das Setup der Batterieinverter nicht.
Meiner sieht z.B. so aus:
MQTT2_cerboGX_c0619ab34e08_vebus
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
asynchron=0
DC_IN und DC_OUT sind userReadings die je nach Vorzeichen der Quelle .../vebus/276/Dc/0/Power in der Quelle erzeugt werden.
D.h. erzeugen deine Inverter Strom, wird der entsprechende Batterie-In-Wert vom Verbrauch abgezogen (Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?)).
Man kann die einzelnen Bestandteile mit ctrlDebug=collectData (mit der aktuellen Version) ganz gut verfolgen:
...
2025.07.20 18:20:44.866 1: SolCast DEBUG> current Power values -> PV2Node: 1195 W, PV2Grid: 0, Other: 0 W, GridIn: 327 W, GridCon: 0 W, BatIn: 0 W, BatOut: 10 W
2025.07.20 18:20:44.867 1: SolCast DEBUG> current Consumption result -> 878 W
...
ZitatDie Ladung der Batterien und die Generatoren dürfen aber nicht in den Verbrauch mit einbezogen werden. Da müsste ich in die SF-Berechnungen direkt eingreifen können um das zu korrigieren.
Bezüglich der Generatoren bin ich anderer Meinung. Sofern sie Energie liefern, ist diese als Input in den Verbrauch mit einzubeziehen. Batterien siehe oben.
Ich sehe aktuell nichts was diesbezüglich korrigiert werden müßte.
ZitatZudem müssten die beiden Batterien getrennt in der Visualisierung dargestellt werden, und auch deren Berechnungen sind zu trennen.
Intern werden alle Batterien getrennt gerechnet. Nur in der Flußdarstellung sind alle Bat zusammengefasst.
Die Anteile der Batterien an In/Out werden über die oben erwähnten (virtuellen) Batterieinverter zusammengefügt.
ZitatBei meinen verwendeten Hybridinvertern gibt es Eingänge für die PV-Module, einen Ein- bzw. Ausgang für die Batterien (Nur DC), einen Eingang für den Generator (Nur AC) und einen Ein- bzw. Ausgang für die Last (nur AC inklusive Grid) und einen Ausgang für die USV Verbraucher (nur AC).
einen Ein- bzw. Ausgang für die Batterien (Nur DC) -> den wirst du sicherlich für die virtuellen Batterieinverter nutzen -> wenn ja, daraus userReadings erstellen die wie oben beschrieben In/Out jeweils als positiven Werte bereitstellen.
einen Eingang für den Generator (Nur AC) -> den verwendest du für deinen (virtuellen) OtherProducer
und einen Ein- bzw. Ausgang für die Last (nur AC inklusive Grid) und einen Ausgang für die USV Verbraucher (nur AC) -> die wirst du auch zusammenfassen müssen, beide gehen als Lieferung an den Inverterknoten ein.
LG,
Heiko
ZitatZitat
Ist es bei surpmeth=median auch möglich eine Anzahl anzugeben? Wenn ja, wie?
Nein. Macht auch keinen Sinn. Median verwendet den mittleren Wert eines nach Größe geordneten Arrays aller gespeicherten Werte. Bei z.B. 7 vorhandenen Werten ist es der Wert an der 4. Stelle (Mitte bei ungeraden Zahlen). Bei gerader Anzahl der Werte ist es der Durchschnitt der beiden mittleren Werte, also z.B. Durchschnitt Wert 5 und 6 bei 10 vorhandenen Werten.
Das würde schon Sinn machen meiner Meinung nach. In der Commandref steht, dass bis zu 20 Werte für den Median genutzt werden. Das würde bei einer Zykluszeit von 60sec bedeuten, dass bis zu 20 Minuten für die Bildung des Medians genutzt werden.
Wenn es beispielsweise folgende Werte sind: 1500, 1200, 1500, 1200, 1500, 1800, 2700, 3100, 3200, 3400, 4700, 4800, 5000
Bilde ich den Median über alle 13 Werte (13 Minuten) ist das 2700
Bilde ich aber den Median über die letzten 5 Werte (nur die letzten 5 Minuten) ist das schon 4700
Somit kann ich den Schwankungen des Ertrags wesentlich schneller folgen, aber trotzdem Ausreißer halbwegs ausbügeln.
Wenn der Median aber über 20 Minuten gebildet wird ist er sehr träge und noch dazu steht bis zu 20, was es noch dazu recht undefinierbar macht.
Habe ich da einen Denkfehler, oder wäre es schon sinnvoll, wenn man die Anzahl der Werte einschränken (festlegen) kann?
Zitatund noch dazu steht bis zu 20, was es noch dazu recht undefinierbar macht.
Das "bis zu" bedeutet, dass z.B. bei einem Restart das Array erst aufgebaut werden muß da es ja nicht vorhanden ist. Wenn es voll aufgebaut ist, sind es 20 Werte.
ZitatBilde ich aber den Median über die letzten 5 Werte (nur die letzten 5 Minuten) ist das schon 4700
Somit kann ich den Schwankungen des Ertrags wesentlich schneller folgen, aber trotzdem Ausreißer halbwegs ausbügeln.
So gesehen hast du Recht. Mir war der Glättungsgedanke wichtiger.
Ich mache mir ein paar Gedanken wie ich 'median' ergänzen könnte.
ZitatIch mache mir ein paar Gedanken wie ich 'median' ergänzen könnte.
Es wäre toll, wenn man auf diesen Wert dann auch zugreifen könnte. Pro Consumer wäre perfekt, das würde (fast) genau meinen Anwendungsfall abbilden.
Ich bügle Ausreißer in beide Richtungen (recht erfolgreich) mit den Waittimern von DOIF weg. z.B.: War der Überschuss in den letzten x Minuten immer über 1800W, dann schalte die Poolheizung ein.
Wenn der Zeitraum etwas länger ist, sollte das ein kurzer Zeitbereich beim Median aber genauso abbilden. Das ist dann glaube ich nur mehr herumprobieren mit den Werten, bis sich das ähnlich verhält.
ZitatEs wäre toll, wenn man auf diesen Wert dann auch zugreifen könnte. Pro Consumer wäre perfekt, das würde (fast) genau meinen Anwendungsfall abbilden.
Wie meinst du das? Weil über den Schlüssel surpmeth kannst du es doch spezifisch für jeden Consumer einstellen.
Den Wertevorrat kann man sich jetzt schon anschauen bzw. programmtechnisch auslesen. Es ist der Schlüssel surplusslidereg im "get ... valCurrent".
Per Programm kommt man mit "CurrentVal ('<Name>', 'surplusslidereg', <default>)" an die Werte (Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Schnittstelle_f%C3%BCr_Modulautoren_bzw._eigenen_Code)). In diesem Fall wird eine Array-Referenz geliefert welche dann zu dereferenzieren ist.
ZitatWie meinst du das? Weil über den Schlüssel surpmeth kannst du es doch spezifisch für jeden Consumer einstellen.
Ich meine den errechneten Wert pro Consumer, den man beim debugConsumerSwitch in der ersten Zeile sieht sieht:
2025.07.20 09:56:45 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "04" ###############
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - ConsumptionRecommended calc method: average:3, surplus: 2972.33333333333
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - additional consumption after switching on (if currently 'off'): 1600 W
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - current planning state: interrupted
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - physical Switchstate before switching: off
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - logical Switchstate before switching: off
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 4314 W, nompower: 1600, surplus: 3321 W, planstate: interrupted:, starttime: 20.07.2025 08:03:44
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - isInLocktime: 0
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - Check Context 'switch on' => swoncond: 1, on-command: heatpump on
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - isAddSwitchOnCond Info: The value "1422.581" resulted in 'true' after exec "{main::CheckWPOn}"
-> Check successful
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - device 'dum_valve' is used as switching device
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - Interrupt Info: The value "1422.581" resulted in 'false' after exec "{main::CheckWPInterruptable}"
-> the effect depends on the switch context
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - Interrupt Characteristic value: 3
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - send switch command now: "set dum_valve heatpump on"
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - Check Context 'switch off' => swoffcond: 0, off-command: heatpump off
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - is Consumption recommended: 1
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - Interrupt Info: The value "1422.581" resulted in 'false' after exec "{main::CheckWPInterruptable}"
-> the effect depends on the switch context
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - current planning state: continuing
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - physical Switchstate after switching: on
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - logical Switchstate after switching: on
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - cycleDayNum: 2
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - last cycle start time: 2025-07-20 09:56:45
2025.07.20 09:56:45 1: energy_mgmt DEBUG> consumer "04" - last cycle end time: still running
Ok, verstehe. Mal sehen was ich tun kann.
Eine weitere Frage ist gerade aufgetaucht:
Ich habe eine Pumpe die mehrere Leistungsstufen hat und die per Überschuss geschaltet wird. (ca.250W, ca. 1000W und noch zwei, wo ich die Leistung nicht weiß, die Leistungen varieren auch und müssen gemessen werden)
Diese beiden Stufen habe ich als zwei Consumer abgebildet, was schalttechnisch funktioniert, aber dazu führt, dass die Leistung doppelt gezählt wird, da es der selbe Leistungsmesser ist.
Das führt zu falschen Prognosewerten, da 2x 1kW ja deutlich mehr ist als 1kW und das über Stunden.
Meine Überlegung wäre folgende gewesen:
pcurr=Pool_Pin31_monotonic_count_PowerCurrent:W:{main::GetPCurr("pump_low",$VALUE)}
Dann habe ich aber gelesen, dass der dritte Parameter ein Threshold ist und kein Rückgabewert für die Leistung. Oder sollte das mit Perlcode doch so funktionieren?
Der Vollständigkeit halber hier, was ich vor hatte(noch ohne Einheit):
# Aufteilen der Leistung der Pumpe auf zwei Devices, damit die Leistung nicht doppelt gezählt wird
sub
GetPCurr($$){
my ($dev,$VALUE)=@_;
if($dev eq "pump_low"){
if($VALUE >500){ #fiktiver Verbrauch der niedrigen Stufe
return 250;
}
else{
return $VALUE;
}
}elsif($dev eq "pump_high"){
if($VALUE >500){
return ($VALUE - 250); #den fiktiven Verbrauch der niedrigen Stufe abziehen
}
else{
return 0; # Bei Verbrauch < 500W gibt es die Hohe STufe nicht und es wird der tatsächliche Wert bei der miedrigen Stufe zurückgegeben
}
}
}
Übersehe ich hier eine Möglichkeit, wie man das realisieren kann?
ZitatDann habe ich aber gelesen, dass der dritte Parameter ein Threshold ist und kein Rückgabewert für die Leistung. Oder sollte das mit Perlcode doch so funktionieren?
Der ist tatächlich nur ein threshold um z.B. einen Standby-Leistung von 0.5 W als "aus" definieren zu können.
Funktiniert also so nicht.
Da fällt mir adhoc auch keine Lösung ein, ist auch schon spät ;) Morgen vllt....
Kannst du mal den call zeigen oder sagen wie du deine sub aufrufst?
Da du ja immer nur ein Device bearbeitest könnte das andere Device ja noch den alten Wert haben.
Wäe es da nicht sinniger beide devices in der sub abzufrühstücken und wenn sich eines ändert das andere sich ändern muß?!
Wie gesagt, keine Ahnung wie du das verstrickt hast.
Aufruf durch das jeweilige Device:
pcurr=Pool_Pin31_monotonic_count_PowerCurrent:W:{main::GetPCurr("pump_low",$VALUE)}
Ich müsste eben, den Verbrauch korrigieren, was so aber nicht funktioniert, da es ja nur ein Thresholdwert ist und keine Leistung die zurückgegeben wird.
Bezüglich alter Wert, würde das höchstens im Umschaltmoment des Zählers passieren und da dann nur für einen Zyklus. Sollte vernachlässigbar sein.
Natürlich wäre es "korrekter" wenn man es in einem Device machen würde, aber das ist nicht möglich und sicher auch gefährlich, wenn ein Consumer in den Leistungsdaten des anderen herumschreiben würde.
Ich hoffe ich habe die Frage richtig verstanden.
Ich glaube ich habe einen Fehler bei der Berechnung des durchschnittlichen Überschusses gefunden:
Es werden die letzten drei Werte gemittelt. Der Durchschnitt steigt, obwohl die Einspeisung 0W ist.
025.07.21 12:48:00 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "07" ###############
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - ConsumptionRecommended calc method: average:3, surplus: 1173.66666666667
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate before switching: on
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate before switching: on
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - general switching parameters => auto mode: 1, Current household consumption: 4228 W, nompower: 1000, surplus: 0 W, planstate: switched on: 2025-07-21 07:31:53 - 2025-07-21 20:52:59, starttime: 21.07.2025 07:31:53
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - isInLocktime: 0
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch on' => swoncond: 1, on-command: pump_high on
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_High_On}"
-> Check successful
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - device 'dum_valve' is used as switching device
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Characteristic value: 3
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch off' => swoffcond: 0, off-command: pump_high off
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - is Consumption recommended: 1
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate after switching: on
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate after switching: on
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - cycleDayNum: 1
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - last cycle start time: 2025-07-21 07:31:53
2025.07.21 12:48:00 1: energy_mgmt DEBUG> consumer "07" - last cycle end time: still running
2025.07.21 12:49:00 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "07" ###############
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - ConsumptionRecommended calc method: average:3, surplus: 1545.66666666667
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate before switching: on
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate before switching: on
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - general switching parameters => auto mode: 1, Current household consumption: 4374 W, nompower: 1000, surplus: 0 W, planstate: switched on: 2025-07-21 07:31:53 - 2025-07-21 20:52:59, starttime: 21.07.2025 07:31:53
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - isInLocktime: 0
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch on' => swoncond: 1, on-command: pump_high on
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_High_On}"
-> Check successful
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - device 'dum_valve' is used as switching device
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Characteristic value: 3
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch off' => swoffcond: 0, off-command: pump_high off
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - is Consumption recommended: 1
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate after switching: on
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate after switching: on
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - cycleDayNum: 1
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - last cycle start time: 2025-07-21 07:31:53
2025.07.21 12:49:00 1: energy_mgmt DEBUG> consumer "07" - last cycle end time: still running
2025.07.21 12:50:00 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "07" ###############
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - ConsumptionRecommended calc method: average:3, surplus: 2167
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate before switching: on
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate before switching: on
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - general switching parameters => auto mode: 1, Current household consumption: 4443 W, nompower: 1000, surplus: 0 W, planstate: switched on: 2025-07-21 07:31:53 - 2025-07-21 20:52:59, starttime: 21.07.2025 07:31:53
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - isInLocktime: 0
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch on' => swoncond: 1, on-command: pump_high on
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_High_On}"
-> Check successful
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - device 'dum_valve' is used as switching device
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Characteristic value: 3
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch off' => swoffcond: 0, off-command: pump_high off
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - is Consumption recommended: 1
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate after switching: on
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate after switching: on
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - cycleDayNum: 1
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - last cycle start time: 2025-07-21 07:31:53
2025.07.21 12:50:00 1: energy_mgmt DEBUG> consumer "07" - last cycle end time: still running
2025.07.21 12:51:00 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "07" ###############
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - ConsumptionRecommended calc method: average:3, surplus: 2959
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate before switching: on
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate before switching: on
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - general switching parameters => auto mode: 1, Current household consumption: 4342 W, nompower: 1000, surplus: 0 W, planstate: switched on: 2025-07-21 07:31:53 - 2025-07-21 20:52:59, starttime: 21.07.2025 07:31:53
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - isInLocktime: 0
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch on' => swoncond: 1, on-command: pump_high on
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_High_On}"
-> Check successful
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - device 'dum_valve' is used as switching device
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Characteristic value: 3
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch off' => swoffcond: 0, off-command: pump_high off
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - is Consumption recommended: 1
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info:
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - current planning state: started
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate after switching: on
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate after switching: on
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - cycleDayNum: 1
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - last cycle start time: 2025-07-21 07:31:53
2025.07.21 12:51:00 1: energy_mgmt DEBUG> consumer "07" - last cycle end time: still running
Kann es sein, dass swoffcond nicht ausgewertet wird bzw. nicht wirksam wird, wenn interruptable=0 gesetzt ist?
Ich habe einen Consumer, der am Morgen eingeschaltet wird, sobald der Überschuss reicht, aber spätestens wenn es 8:00 ist. (wird über swoncond gelöst)
Er darf dann nicht unterbrochen werden, bis eine externe Bedingung zutrifft. (swoffcond, welche die umgewälzte Wassermenge berücksichtigt. Laufzeit der Pumpe geht leider nicht, da die Wassermenge nicht nur von dieser Pumpe abhängt. Somit kann ich mintime nicht verwenden.)
Consumer:
Pool_Strom_Pumpe:Poolpumpe
asynchron=0
auto=pump_low_auto
icon=scene_pool
interruptable=0
mintime=SunPath:0:180
mode=must
noshow=0
notafter=08:00
off="pump_low off"
on="pump_low on"
pcurr=Pool_Pin31_monotonic_count_PowerCurrent:W
power=200
surpmeth=3
switchdev=dum_valve
swoffcond=Pool_Strom_Heizung:Pool_Pin31_monotonic_count_PowerCurrent:{main::Check_Pump_Low_Off}
swoncond=Pool_Strom_Heizung:Pool_Pin31_monotonic_count_PowerCurrent:{main::Check_Pump_Low_On}
swstate=pump_low:on:off
type=other
Wie kann ich denn den Consumer trotzdem ausschalten?
So sah das Log dazu aus:
Nach dem Umschalten von interruptable auf =1 wurde sofort ausgeschaltet.
2025.07.21 15:46:07 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "05" ###############
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate before switching: on
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate before switching: off
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - general switching parameters => auto mode: 1, Current household consumption: 857 W, nompower: 200, surplus: 0 W, planstate: switched on: 2025-07-21 06:36:52 - 2025-07-21 23:52:58, starttime: 21.07.2025 06:36:52
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - isInLocktime: 0
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - device 'dum_valve' is used as switching device
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - Interrupt Characteristic value: 0
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - is Consumption recommended: 0
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate after switching: on
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate after switching: off
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - cycleDayNum: 3
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - last cycle start time: 2025-07-21 15:35:02
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - last cycle end time: 2025-07-21 15:40:07
2025.07.21 15:47:01 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "05" ###############
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate before switching: on
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate before switching: on
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - general switching parameters => auto mode: 1, Current household consumption: 850 W, nompower: 200, surplus: 0 W, planstate: switched on: 2025-07-21 06:36:52 - 2025-07-21 23:52:58, starttime: 21.07.2025 06:36:52
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - isInLocktime: 0
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - device 'dum_valve' is used as switching device
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - Interrupt Characteristic value: 1
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - is Consumption recommended: 0
2025.07.21 15:47:01 1: energy_mgmt DEBUG> consumer "05" - send switch command now: "set dum_valve pump_low off"
2025.07.21 15:47:02 1: energy_mgmt DEBUG> consumer "05" - current planning state: interrupting
2025.07.21 15:47:02 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate after switching: off
2025.07.21 15:47:02 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate after switching: off
2025.07.21 15:47:02 1: energy_mgmt DEBUG> consumer "05" - cycleDayNum: 3
2025.07.21 15:47:02 1: energy_mgmt DEBUG> consumer "05" - last cycle start time: 2025-07-21 15:35:02
2025.07.21 15:47:02 1: energy_mgmt DEBUG> consumer "05" - last cycle end time: 2025-07-21 15:40:07
Zitat von: hugomckinley am 21 Juli 2025, 16:01:09Kann es sein, dass swoffcond nicht ausgewertet wird bzw. nicht wirksam wird, wenn interruptable=0 gesetzt ist?
Meines Wissens nach geht swoffcond vor ! :)
Das würde aber auch deinem Ansinnen - nach dem Start IMMER auf den externen OFF-Befehl warten - entgegenstehen wenn du interruptable=1 einstellst.
Zitat von: hugomckinley am 21 Juli 2025, 16:01:09Laufzeit der Pumpe geht leider nicht, da die Wassermenge nicht nur von dieser Pumpe abhängt. Somit kann ich mintime nicht verwenden.)
Du hast aber "mintime" doch definiert, was den ganzen Tag von Morgens bis Abend heißt ?
Das ist sicherlich etwas lang => ;) - ich würde eine ermittelte max-Laufzeit eintragen.
mintime=SunPath:0:180Demnach aktuell : von Sonnenaufgang (+ 0 Minuten) bis zum Sonnenuntergang (+ 180 Minuten)
Vorschlag:
mintime=360 (das sind schon 6 Stunden lang) ;D
Zusätzlich vorerst dann einen Eintrag
notbefore=06:00 um die Einschaltzeit etwas einzugrenzen.
Dann hast du nach dem Einschalten von attr "crtlDebug" =>> consumerSwitching01 nachts evtl. auch weniger Daten beim SF-ctrldebug.
Damit solltest du evtl. dann morgen im Log erkennen können warum nicht geschaltet wird.
Einen Versuch wäre es Wert.
Zitat von: hugomckinley am 21 Juli 2025, 16:01:09So sah das Log dazu aus:
Nach dem Umschalten von interruptable auf =1 wurde sofort ausgeschaltet.
logisch =>> Surplus = 0
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
Zitatlogisch =>> Surplus = 0
Stimmt, war nicht die swoffcond
ZitatDas würde aber auch deinem Ansinnen - nach dem Start IMMER auf den externen OFF-Befehl warten - entgegenstehen wenn du interruptable=1 einstellst.
Das ist ja mein Problem, dass ich interruptable=0 setzen muss.
ZitatDu hast aber "mintime" doch definiert, was den ganzen Tag von Morgens bis Abend heißt ?
Das ist sicherlich etwas lang => ;) - ich würde eine ermittelte max-Laufzeit eintragen.
Ich meine, dass ich keine sinnvolle mintime in Minuten angeben kann.
Das Problem ist, dass sich keine maximale Laufzeit ermitteln lässt. Sie kann irgendwo zwischen 5 und 16 Stunden liegen. Derzeit bei meiner Steuerung: Start: über 250W Überschuss, Ende: spätestens 23:59 wenn die Menge nicht erreicht wurde, ansonsten früher. Kann auch mal 13:00 sein.
ZitatDamit solltest du evtl. dann morgen im Log erkennen können warum nicht geschaltet wird.
Ich sehe den Grund leider nicht:
Zuerst ist der logic state on und dann off, aber es wird nie geschaltet. Erst als ich interruptable auf =1 gesetzt habe wurde wegen surplus=0 geschaltet.
Es wird
last cycle end time: 2025-07-21 15:28:07 gesetzt, was ja heißen würde, dass die Einplanung beendet wurde, oder?
Man sieht aber nicht, dass das swoffcond zur Ausplanung geführt hätte.
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low offAber der physical Switchstate ändert sich nicht und es bleibt immer so.
2025.07.21 15:28:07 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "05" ###############
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate before switching: on
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate before switching: on
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - general switching parameters => auto mode: 1, Current household consumption: 860 W, nompower: 200, surplus: 0 W, planstate: switched on: 2025-07-21 06:36:52 - 2025-07-21 23:52:58, starttime: 21.07.2025 06:36:52
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - isInLocktime: 0
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - device 'dum_valve' is used as switching device
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - Interrupt Characteristic value: 0
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - is Consumption recommended: 0
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate after switching: on
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate after switching: on
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - cycleDayNum: 2
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - last cycle start time: 2025-07-21 15:23:07
2025.07.21 15:28:07 1: energy_mgmt DEBUG> consumer "05" - last cycle end time: still running
2025.07.21 15:29:08 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "05" ###############
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate before switching: on
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate before switching: off
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - general switching parameters => auto mode: 1, Current household consumption: 865 W, nompower: 200, surplus: 0 W, planstate: switched on: 2025-07-21 06:36:52 - 2025-07-21 23:52:58, starttime: 21.07.2025 06:36:52
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - isInLocktime: 0
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - device 'dum_valve' is used as switching device
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - Interrupt Characteristic value: 0
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - is Consumption recommended: 0
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate after switching: on
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate after switching: off
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - cycleDayNum: 2
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - last cycle start time: 2025-07-21 15:23:07
2025.07.21 15:29:08 1: energy_mgmt DEBUG> consumer "05" - last cycle end time: 2025-07-21 15:28:07
2025.07.21 15:29:29 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "05" ###############
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate before switching: on
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate before switching: off
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - general switching parameters => auto mode: 1, Current household consumption: 846 W, nompower: 200, surplus: 0 W, planstate: switched on: 2025-07-21 06:36:52 - 2025-07-21 23:52:58, starttime: 21.07.2025 06:36:52
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - isInLocktime: 0
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - isAddSwitchOnCond Info: The value "" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - device 'dum_valve' is used as switching device
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - Interrupt Characteristic value: 0
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - is Consumption recommended: 0
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - current planning state: started
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate after switching: on
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate after switching: off
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - cycleDayNum: 2
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - last cycle start time: 2025-07-21 15:23:07
2025.07.21 15:29:29 1: energy_mgmt DEBUG> consumer "05" - last cycle end time: 2025-07-21 15:28:07 Nachdem ich meine Check_Pump_Low_On so geändert habe, dass sie 0 liefert, schaut es im Log genauso aus wie bei Check_Pump_Low_Off.
Ich glaube, dass bei interruptable=0 die swoffcond auf 0 gesetzt wir und nicht ausgewertet wird. Sie liefert definitiv 1.
2025.07.21 19:17:12 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "05" ###############
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - current planning state: continued
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate before switching: on
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate before switching: off
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - general switching parameters => auto mode: 1, Current household consumption: 936 W, nompower: 250, surplus: 0 W, planstate: continued:, starttime: 21.07.2025 06:36:52
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - isInLocktime: 0
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch on' => swoncond: 0, on-command: pump_low on
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - device 'dum_valve' is used as switching device
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - Interrupt Characteristic value: 0
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - is Consumption recommended: 0
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - current planning state: continued
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate after switching: on
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate after switching: off
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - cycleDayNum: 7
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - last cycle start time: 2025-07-21 18:09:10
2025.07.21 19:17:12 1: energy_mgmt DEBUG> consumer "05" - last cycle end time: 2025-07-21 18:12:10
Es gibt doch auch eine artähnliche Lösung im WIKI: ;)
Schau mal dort - das müsste auf jeden Fall bei dir passen.
siehe WIKI: Fallstudie: Umwälzpumpe Pool soll X Stunden am Tag laufen. Ist kein PV-Überschuß vorhanden, müssen die X Stunden/Tag trotzdem erreicht werden (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Fallstudie:_Umw%C3%A4lzpumpe_Pool_soll_X_Stunden_am_Tag_laufen._Ist_kein_PV-%C3%9Cberschu%C3%9F_vorhanden,_m%C3%BCssen_die_X_Stunden/Tag_trotzdem_erreicht_werden)
Alternativ schaue dir auch mal die Option "spignorecond" an :
Bedingung um einen fehlenden PV Überschuß zu ignorieren (optional). Bei erfüllter Bedingung wird der Verbraucher entsprechend
der Planung eingeschaltet auch wenn zu dem Zeitpunkt kein PV Überschuß vorliegt.
ACHTUNG: Die Verwendung beider Schlüssel spignorecond und interruptable kann zu einem unerwünschten Verhalten führen!
Device - Device zur Lieferung der Bedingung
Reading - Reading welches die Bedingung enthält
Die Bedingung kann als regulärer Ausdruck oder als in {..} eingeschlossener Perl-Code formuliert sein:
Regex - regulärer Ausdruck der für eine 'wahre' Bedingung erfüllt sein muß
{Perl-Code} - der in {..} eingeschlossene Perl-Code muß 'wahr' liefern um die Bedingung zu erfüllen. Er darf keine Leerzeichen enthalten.
Der Wert von Device:Reading wird dem Code mit der Variable $VALUE übergeben.
Hallo zusammen,
ZitatKann es sein, dass swoffcond nicht ausgewertet wird bzw. nicht wirksam wird, wenn interruptable=0 gesetzt ist?
Nein. Wie 300P schon schrieb ist swoffcond priorisiert.
Es wird aber swoffcond "false" ermittelt:
2025.07.21 15:46:07 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
ZitatIch glaube ich habe einen Fehler bei der Berechnung des durchschnittlichen Überschusses gefunden:
Es werden die letzten drei Werte gemittelt. Der Durchschnitt steigt, obwohl die Einspeisung 0W ist.
Fehler nicht, aber eine ungünstige Implementierung meinerseits. Der Durchschnitt wird aktuell über die ältesten X Werte gebildet wenn X<20 gesetzt ist. Das ändere ich in Verwendung der neuesten/letzten Werte um.
LG,
Heiko
ZitatNein. Wie 300P schon schrieb ist swoffcond priorisiert.
Sehr gut. Es hat auch schon so funktioniert bilde ich mir ein. (aber bei einem anderen Consumer)
Aber ein
{Check_Pump_Low_Off}in der Befehlszeile von FHEM
ergibt
1.
Das ist ja das merkwürdige.
Ich bin verwirrt ...
Log(im gleichen Zustand):
2025.07.21 20:47:22 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "05" ###############
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - ConsumptionRecommended calc method: average:3, surplus: 0
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - current planning state: suspended
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate before switching: on
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate before switching: on
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - general switching parameters => auto mode: 1, Current household consumption: 969 W, nompower: 250, surplus: 0 W, planstate: suspended:, starttime: 21.07.2025 19:58:05
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - isInLocktime: 0
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch on' => swoncond: 0, on-command: pump_low on
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - device 'dum_valve' is used as switching device
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - Interrupt Characteristic value: 0
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - is Consumption recommended: 0
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - current planning state: suspended
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - physical Switchstate after switching: on
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - logical Switchstate after switching: on
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - cycleDayNum: 15
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - last cycle start time: 2025-07-21 20:43:22
2025.07.21 20:47:22 1: energy_mgmt DEBUG> consumer "05" - last cycle end time: still running ZitatDas ändere ich in Verwendung der neuesten/letzten Werte um.
Herzlichen Dank.
Naja, der Aufruf von {Check_Pump_Low_Off} ohne Argumente? ... was wäre zu erwarten?
Wie sieht diese Sub denn aus?
sub
Check_Pump_Low_Off{
if(((((ReadingsVal("pump_l1_hc","waterAmount",0) + ReadingsVal("pump_l2_hc","waterAmount",0)) > 90)
&& (ReadingsVal("dum_valve","bath_mode","0") == 1)
)
|| (((ReadingsVal("pump_l1_hc","waterAmount",0) + ReadingsVal("pump_l2_hc","waterAmount",0)) > 45)
&& ReadingsVal("dum_valve","bath_mode","1") == 0
)
)
&& ReadingsVal("dum_valve","heatpump","on") eq "off"
&& ReadingsVal("dum_valve","special_function","") eq "none"
&& ReadingsVal("dum_valve","valve_position","") eq "normal"
)
{return 1}
else
{return 0}
}
Es wird ja
swoffcond=<Device>:<Reading>:<Bedingung>
angegeben. Das Device/Reading muß den Vergleichswert liefern der mit der Bedingung verglichen wird.
Dabei kann Bedingung ein Regex oder, wie bei dir, eine Funktion sein.
D.h. du müsstest mal "Pool_Strom_Heizung" Reading "Pool_Pin31_monotonic_count_PowerCurrent" checken ob die Kombi den Vergleichswert "1" liefert.
Ich werde die Commandref noch etwas präziser formulieren.
Das wars!
Da steht gerade 0 (W) drinnen, was false ist.
Unter Tags steht dort aber irgendwas >0 drinnen, was dann natürlich true ist.
Somit vergleiche ich mit unterschiedlichen Werten.
Danke sehr!
Das habe ich zwar gelesen, aber nicht verstanden bzw. hinterfragt, weil es fälschlicherweise funktioniert hat, wenn die Heizung lief!
Ich habe das so interpretiert, dass Device:Reading nur den $VALUE liefert, um damit mit dem Perlcode zu rechnen.
Nachdem ich keinen Wert brauche, war das irgendein dummy-Wert. Jetzt nehme ich einen dummy-Wert der statisch 1 ist. :-)
Gerade korrigiert.
Wie immer im Leben -> Kaum macht man es richtig, funktionierts!
In meinem contrib liegt ein Update der V 1.54.4. Drin ist:
- Attr ConsumerXX hat neuen Key 'aliasshort'
- Deprecated Attribut graphicShowDiff entfernt
- Attr ConsumerXX Key surpmeth=median[_2..20] kann optional die neuesten 2..20 Elemente verwenden
- Attr ConsumerXX Key surpmeth=average[_2..20] anstatt nur 2..20 -> Harmonisierung zur Angabe
von surpmeth=median[_2..20] und es werden die neuesten X Elemente verwendet (Korrektur)
- Debug consumerSwitching: Info-Meldung des Vergleichsvorgangs wird ausgegeben
- Speichern des Ergebnisses der surpmeth-Berechnung im neuen Schlüssel surpmethResult im
Verbraucherstammsatz (get ... valConsumerMaster).
Den Wert kann man sich mit [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', 'surpmethResult', <default>)
in eigene Programme holen (Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Schnittstelle_f%C3%BCr_Modulautoren_bzw._eigenen_Code))
- Präzisierung der comRef:
swoncond Bedingung die zusätzlich erfüllt sein muß um den geplanten Zyklus zu starten und den Verbraucher einzuschalten (optional).
Device:Reading - die Device/Reading Kombination liefert den Prüfwert $VALUE ('undef' wird ignoriert)
Die Prüfung kann als regulärer Ausdruck oder als in {..} eingeschlossener Perl-Code formuliert sein:
Regex - regulärer Ausdruck zur Prüfung von $VALUE der im Erfolgsfall 'wahr' liefern muß
{Perl-Code} - der in {..} eingeschlossene Perl-Code darf keine Leerzeichen enthalten. Die Variable $VALUE kann vom Code ausgewertet werden.
Der return Wert muß im Erfolgsfall 'wahr' sein.
swoffcond vorrangige Bedingung um den Verbraucher auszuschalten (optional). Der geplante Zyklus wird gestoppt.
Device:Reading - die Device/Reading Kombination liefert den Prüfwert $VALUE ('undef' wird ignoriert)
Die Prüfung kann als regulärer Ausdruck oder als in {..} eingeschlossener Perl-Code formuliert sein:
Regex - regulärer Ausdruck zur Prüfung von $VALUE der im Erfolgsfall 'wahr' liefern muß
{Perl-Code} - der in {..} eingeschlossene Perl-Code darf keine Leerzeichen enthalten. Die Variable $VALUE kann vom Code ausgewertet werden.
Der return Wert muß im Erfolgsfall 'wahr' sein.
LG,
Heiko
PS:
Heute wird bei einigen wohl auch ein FTUI-Update manuell mit "get <SF-Devicename> ftuiFramefiles" notwendig O:-)
@Heiko
ZitatDann stimmt aber noch etwas im Setup nicht. Die Flüsse der Batterieinverter werden vom Knoten subtrahiert sofern die Laufrichtung (d.h. In/Out) richtig verwendet wird.
Leider sehe ich das Setup der Batterieinverter nicht.
Möglich das ich hier einen Fehler habe.
Meine Batterien sind am Hybridinverter angeschlossen.
Das setupBatteryDev01 lautetDeye_12k icon=@dyn:@dyn:@dyn:@dyn show=2:bottom label=beside cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1Muss ich zusätzlich ein setupInverterDev03 als einen Batterie-Wechselrichter anlegen?
Bei der Erfassung des
Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung.
Sind das die sich stetig erhöhendeen Wh, also die bisherige Summe an Wh der einzelnen Geräten?
ZitatMuss ich zusätzlich ein setupInverterDev03 als einen Batterie-Wechselrichter anlegen?
Ja genau. Nativ kann das Modul noch keinen Hybridinverter integrieren. Als Workarund erstellt man einen Standardwechselrichter und dazu einen (virtuellen) Batteriewechselrichter.
ZitatBei der Erfassung des Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung.
Sind das die sich stetig erhöhendeen Wh, also die bisherige Summe an Wh der einzelnen Geräten?
Wir rechnen auf Stundenbasis. Das Ergebnis Wh bedingt auch dass die Bestandteile in Wh vorliegen müssen. Allerdings wird nur der Stundenanteil jedes Gerätes verwendet und nicht die Summe Wh, aber das macht das Modul intern. Abgeleitet wird es aus den jeweiligen Werten Total Wh.
Zitat von: DS_Starter am 22 Juli 2025, 13:15:22Ja genau. Nativ kann das Modul noch keinen Hybridinverter integrieren. Als Workarund erstellt man einen Standardwechselrichter und dazu einen (virtuellen) Batteriewechselrichter.
Dazu muss ich mir noch etwas berechnen um ac2dc und dc2ac zu ermitteln.
Nur da müsste ich die Strings der Hybridinverter bei dieser Definition abziehen um es annähernd zu berechnen, denn um die Verluste zu ermitteln muss ich mir noch etwas einfallen lassen.
Zitat von: DS_Starter am 22 Juli 2025, 13:15:22Wir rechnen auf Stundenbasis. Das Ergebnis Wh bedingt auch dass die Bestandteile in Wh vorliegen müssen. Allerdings wird nur der Stundenanteil jedes Gerätes verwendet und nicht die Summe Wh, aber das macht das Modul intern. Abgeleitet wird es aus den jeweiligen Werten Total Wh.
Gut diese Wh Werte liegen sowohl pro h, pro Tag und als Total vor. Die Totalwerte haben alle gepasst.
@all,
die V 1.54.4 ist eingecheckt und morgen früh im Update enthalten. Details in #3586.
LG,
Heiko
@Heiko
Kann man die Farbe je nach Flussrichtung des Beams bei den Batterie-Wechselrichtern so einstellen, dass zB. Laden Rot wäre und Entladen Grün wäre.
ZitatKann man die Farbe je nach Flussrichtung des Beams bei den Batterie-Wechselrichtern so einstellen, dass zB. Laden Rot wäre und Entladen Grün wäre.
Momentan kann man das nicht.
Zur Zeit gibt es, von den Consumern mal abgesehen, diese drei Grundfarben:
strokecolina Farbe einer inaktiven Linie
Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: gray
strokecolsig Farbe einer aktiven Signallinie
Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: red
strokecolstd Farbe einer aktiven Standardlinie
Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: darkorange
Dabei ist die Signallinie in rot vorbehalten für einen Zusatnd der i.A. als "unschön" angesehen wird, z.B. den Netzbezug.
Für BatIn/Out trifft das so nicht zu. Es ist nur eine Zwischenspeicherung, die ich persönlich als neutral bewerten würde.
Wenn es den Wunsch nach einer farblichen Unterscheidung gibt, würde ich zwei neue Liniennamen in flowGraphicControl aufnehmen für diesen Zweck und die Farbgebung komplett dem User überlassen wenn er vom Standard abweichen möchte. Das wären dann Linien für BatIn/BatOut.
LG,
Heiko
Es muss nicht rot sein, nur einen Unterschied zwischen laden und entladen wäre übersichtlicher bei der Verfolgung des Stromflusses.
Nochmals zurück zu der Leistungsberechnung am Inverter-Knoten in der Graphik.
Verbrauch (W) = Inverter Last Leistung ∑ (W) + sonstige Erzeugung ∑ (W) - Inverter Batterieladung (W) + Inverter Batterieentladung (W)
Die Batterieladung bzw. Batterieentladung berechne ich aus der Akku Leistung, je nach dem ob sie positiv oder negativ ist.
Diese Berechnung kann ich leider bei mir so nicht anwenden.
Die Batterieladung und Batterieentladung dürfen bei mir nicht in die Berechnung des AC-Verbrauchs der Graphik einfließen, sondern werden nur intern im Hybridinverter angezeigt und kann nur als Anzeige in der Graphik verwendet werden.
Würde ich die Batterieladung und Batterieentladung aus dem Verbrauch herausrechnen, passt das mit der Übersicht nicht mehr.
Ich lasse es derzeit wie es ist.
Schön langsam wird es mit meiner Überschussregelung per SF :-)
Wenn ich die letzten Herausforderungen noch schaffe und über keinen Showstopper mehr stolpere, werde ich dann die "Simulation" auf einem Dummy noch ein paar Tage beobachten und dann in den Testbetrieb gehen können.
Aber hier brauche ich Expertenrat:
- Was ist der logical Switchstate und warum und wann unterscheidet er sich vom physical Switchstate?
- Gibt es außer den Vorgaben im Consumer für das Einplanen, einem Klick auf das Uhrensymbol und einem set consumerNewPlanning weitere Gründe warum ein Consumer neu geplant wird? (hier 19:45, aus irgendeinem Grund, den ich noch nicht weiß, wird hier neu geplant und anscheinend sofort gestartet)
- Was bedeutet: Interrupt Characteristic value: 3
- Gehe ich recht in der Annahme, dass ein swoffcond=1 stärker wiegt, als ein interruptable=0? Denn dann müsste hier ja ausgeschaltet werden.
- last cycle start time: 2025-07-23 10:25:14 und last cycle start time: 2025-07-23 10:25:14 sind die Ein- und Ausschaltzeiten des Consumers?
- cycleDayNum: 3 heißt drei mal Ein und drei mal Aus, oder Ein, Aus, Ein?
- Die größte Frage: Warum wird hier nicht ausgeschaltet?
2025.07.23 20:08:17 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "04" ###############
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - ConsumptionRecommended calc method: median:13, surplus: 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - method base: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - current planning state: planned
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - physical Switchstate before switching: on
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - logical Switchstate before switching: off
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 1108 W, nompower: 1800, surplus: 0 W, planstate: replanned: 2025-07-23 19:45:17 - 2025-07-23 20:50:59, starttime: 23.07.2025 19:45:17
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isInLocktime: 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Check Context 'switch on' => swoncond: 0, on-command: heatpump on
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isAddSwitchOnCond Info: The value "1" resulted in 'false' after exec "{main::CheckWPOn}"
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isAddSwitchOffCond Info: The reference value "1" resulted in 'true' after exec "{main::CheckWPOff}"
-> Check successful -> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - device 'dum_valve' is used as switching device
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Interrupt Info: The reference value "1" resulted in 'false' after exec "{main::CheckWPInterruptable}"
-> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Interrupt Characteristic value: 3
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Check Context 'switch off' => swoffcond: 1, off-command: heatpump off
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - is Consumption recommended: 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isAddSwitchOffCond Info: The reference value "1" resulted in 'true' after exec "{main::CheckWPOff}"
-> Check successful -> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Interrupt Info: The reference value "1" resulted in 'false' after exec "{main::CheckWPInterruptable}"
-> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - current planning state: planned
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - physical Switchstate after switching: on
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - logical Switchstate after switching: off
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - cycleDayNum: 3
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - last cycle start time: 2025-07-23 10:25:14
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - last cycle end time: 2025-07-23 14:44:14 Definition des Consumers:
Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800 asynchron=0
icon=sani_heating_heatpump
auto=sf_automatic
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=dum_valve:sf_true:{main::CheckWPInterruptable}
swoffcond=dum_valve:sf_true:{main::CheckWPOff}
Hier das Problem mit dem nicht Schalten in umgekehrter Richtung:
2025.07.24 09:00:18 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "07" ###############
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - ConsumptionRecommended calc method: median:19, surplus: 2067
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - method base: 1796 2005 2051 1729 1787 1162 1445 2070 2409 2001 2105 2067 1760 1034 3794 4150 4150 4338 4338 4338
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - additional consumption after switching on (if currently 'off'): 1000 W
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - current planning state: interrupted
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate before switching: off
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate before switching: off
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - general switching parameters => auto mode: 1, Current household consumption: 2210 W, nompower: 1000, surplus: 4338 W, planstate: interrupted:, starttime: 24.07.2025 08:10:18
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - isInLocktime: 0
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch on' => swoncond: 1, on-command: pump_high on
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOnCond Info: The value "1" resulted in 'true' after exec "{main::Check_Pump_High_On}"
-> Check successful
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOffCond Info: The reference value "1" resulted in 'false' after exec "{main::Check_Pump_High_Off}"
-> the effect depends on the switch context
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - device 'dum_valve' is used as switching device
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info: The reference value "1" resulted in 'true' after exec "{main::Check_Pump_High_Interruptable}"
-> Check successful -> the effect depends on the switch context
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Interrupt Characteristic value: 2
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch off' => swoffcond: 0, off-command: pump_high off
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - is Consumption recommended: 1
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOffCond Info: The reference value "1" resulted in 'false' after exec "{main::Check_Pump_High_Off}"
-> the effect depends on the switch context
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info: The reference value "1" resulted in 'true' after exec "{main::Check_Pump_High_Interruptable}"
-> Check successful -> the effect depends on the switch context
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - current planning state: interrupted
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - physical Switchstate after switching: off
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - logical Switchstate after switching: off
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - cycleDayNum: 1
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - last cycle start time: 2025-07-24 08:10:18
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - last cycle end time: 2025-07-24 08:25:18
Warum wird hier nicht geschaltet?
on="heatpump on"
off="heatpump off"
Reagiert dein Device auch wirklich auf:
(wirklich schon getestet ?)
set dum_valve "heatpump on"
set dum_valve "heatpump off"
Ja, das funktioniert alles. Ich kann in SF auch händisch ein- und ausschalten.
Normalerweise sieht man im Log auch das Auslösen des Schaltbefehls, aber das fehlt hier ja auch. Aber ich sehe keinen Grund warum.
Zum "sehen" setze / schalte mal in SF auf "verbose 3" um.
- Dann siehst du die Schaltvorgänge von den ConsumerXY,
- auch die manuellen Schaltungen (...external....)
sind "wieder" im Logbuch sichtbar. ;)
verbose
Set the verbosity level. Possible values:
0 - server start/stop
1 - error messages or unknown packets
2 - major events/alarms.
3 - commands sent out will be logged.
4 - you'll see whats received by the different devices.
5 - debugging.
The value for the global device is a default for other devices without own verbose attribute set.
PS:
Früher sah man das bei "verbose 2".
Aber dies ist/sind weder ein "alarm".....noch "major event". Ansonsten müsste/würde/sollte ja jeder einzelne Schaltvorgang eines Device bei der Einstellung "verbose 2" protokolliert werden. Ohjeh ...welche Datenflut kommt denn da ??? ::)
Seit einiger Zeit (Ende Mai 2025) wird daher nur bei verbose 3 das Schalten im Logbuch eingetragen. O:-)
ZitatWas ist der logical Switchstate und warum und wann unterscheidet er sich vom physical Switchstate?
Der logische Switchstate berücksichtigt ein Standby bzw. den Threshhold der bei pcurr angegeben wurde. Beispiel ein Schaltdose mit Meßfunktion. Angeschlossen ist ein TV. Die Dose ist "on", dh. der Verbraucher ist physich "on". Der Verbraucher (TV) ist aber im Standby und verbraucht nur 0,5W. DAmit ist der Verbrauch < Threshhold und der Verbraucher ist logisch "off".
ZitatGibt es außer den Vorgaben im Consumer für das Einplanen, einem Klick auf das Uhrensymbol und einem set consumerNewPlanning weitere Gründe warum ein Consumer neu geplant wird? (hier 19:45, aus irgendeinem Grund, den ich noch nicht weiß, wird hier neu geplant und anscheinend sofort gestartet)
Ja.
Sofern ein Consumer nicht im Planungszeitraum gestartet werden konnte (weil z.B. kein Überschuß oder andere Verhinderungsgründe), versucht das Modul ein Replanning in einem folgenden passenden Zeitraum:
planstate: replanned: 2025-07-23 19:45:17 - 2025-07-23 20:50:59, starttime: 23.07.2025 19:45:17
Ein Start erfolgt aber hier nicht, sondern nur die neue Einplanung.
ZitatWas bedeutet: Interrupt Characteristic value: 3
Das ist ein Interrupt Typ -> für interne Programmierung.
Interruptable 0/1 -> Typ 0/1, Code return "true" -> 2, Code return "false" -> 3
ZitatGehe ich recht in der Annahme, dass ein swoffcond=1 stärker wiegt, als ein interruptable=0? Denn dann müsste hier ja ausgeschaltet werden.
Das sind zwei unterschiedliche Sachverhalte. interruptable=0 besagt der Verbraucher ist nicht temporär unterbrechbar. swoffcond=1 besagt, wenn die Bedingung zutrifft, wird der gesamte aktive Lauf beendet. D.h. der Consumer ist dann "finished".
Zitatlast cycle start time: 2025-07-23 10:25:14 und last cycle start time: 2025-07-23 10:25:14 sind die Ein- und Ausschaltzeiten des Consumers?
Ja
ZitatcycleDayNum: 3 heißt drei mal Ein und drei mal Aus, oder Ein, Aus, Ein?
Das erstere.
ZitatDie größte Frage: Warum wird hier nicht ausgeschaltet?
Ich sehe zwei Gründe.
1. es liegt kein PV Überschuß vor
Current household consumption: 1108 W, nompower: 1800, surplus: 0 W ....
2. die swoncond: 0, d.h. die zusätzliche Bedingung für Start des Zyklus ist "false" geliefert von {main::CheckWPOn}. Gleichzeitig wird 'true' after exec "{main::CheckWPOff} geliefert, d.h. swoffcond=1 und somit wird Einschalten ebenfalls verhindert.
(Die Ausgabe "isAddSwitchOnCond Info: The value "1" resulted in 'false' after exec "{main::CheckWPOn}" muß ich nochmal ändern -> die 1 ist nicht der return von main::CheckWPOn), ist aber nur der Log)
ZitatHier das Problem mit dem nicht Schalten in umgekehrter Richtung:
Warum wird hier nicht geschaltet?
Bei interuptable ist ein Code angegeben, das bedeutet der Verbraucher wird unterbrochen wenn {} = "true" liefert. Und das macht er:
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info: The reference value "1" resulted in 'true' after exec "{main::Check_Pump_High_Interruptable}"
-> Check successful -> the effect depends on the switch context
Commandref:
Device:Reading:{Perl-Code} - Verbraucher wird temporär unterbrochen, wenn der Perl-Code 'wahr' zurückgibt oder unzureichender
PV Überschuß (wenn power ungleich 0) vorliegt und wird wieder eingeschaltet, wenn der Perl-Code 'falsch' zurückgibt und PV Überschuß
(wenn power ungleich 0) vorliegt.
Ich hoffe nichts vergessen zu haben...
LG,
Heiko
Version mit den Debug Info Changes ist eingecheckt.
@Heiko
Danke für deine Erklärungen.
Ich habe den Begriff interruptable falsch verstanden und die commandref daher nicht so interpretiert.
Ich dachte, dass interrupt
able=1 die Freigabe für das Schalten durch den Überschuss ist, dabei ist es ein zusätzliches Kriterium.
Einmal mit UND und einmal mit ODER. Wie bei swoncond und swoffcond.
Ich dachte:
* interuptable=1 -> Regelung durch Überschuss freigegeben
* interruptable=0 -> Überschussregelung aus -> immer ein, wenn geplant
aber es ist so:
* interruptable=1: Verbraucher aus, trotz Überschuss (surplus=0 ODER interruptable = 1)
* interruptable=0: Verbraucher ein, wenn Überschuss vorhanden (surplus >0 UND interruptable = 0)
Habe ich das richtig Verstanden, dass bei interruptable der Perlcode oder die Regex für sich true ergeben müssen?
Ist das dann nicht anders, wie bei swoncond und swoffond? Da muss doch der Vergleich Decvice:Reading mit dem Ergebnis des Perlcode true ergeben, oder?
ZitatEs wird ja
swoffcond=<Device>:<Reading>:<Bedingung>
angegeben. Das Device/Reading muß den Vergleichswert liefern der mit der Bedingung verglichen wird.
Dabei kann Bedingung ein Regex oder, wie bei dir, eine Funktion sein.
(Was bei mir egal ist, da mein sf_true Reading fix auf 1 steht. Aber evtl. verwende ich es ja mal anders.)
--> Sollte ich jetzt verstanden haben. Danke!
Ich glaube bei einer Frage haben wir aneinander vorbei geredet:
Gehe ich recht in der Annahme, dass ein swoffcond=1 stärker wiegt, als ein interruptable=0? Denn dann müsste hier ja ausgeschaltet werden.Hier ist
swoncond=false,
interruptable=false und
swoffcond=trueMeine Frage war, warum hier nicht
ausgeschaltet wird?
Wird hier der physische Schalter nicht ausgeschaltet, weil der logische Zustand schon aus ist?
(Kommt bei mir derzeit noch vor, da noch meine Regelung den Verbraucher steuert. Leistung ist schon 0, aber physical Switchstate ist noch "on")
ZitatIch dachte:
* interuptable=1 -> Regelung durch Überschuss freigegeben
* interruptable=0 -> Überschussregelung aus -> immer ein, wenn geplant
Das ist nicht ganz richtig. Richtig ist:
* interuptable=1 -> Ein gestarteter Verbraucher kann bei fehlendem Überschuß unterbrochen und später fortgesetzt werden
* interruptable=0 -> Ein einmal gestarteter Verbraucher darf nicht unterbrochen werden wenn später Überschuß fehlen sollte
Aber das Verhalten ist unterschiedlich ob man interuptable=1/0 setzt oder ob man interuptable=Device:Reading:{Perl-Code} verwendet -> ComRef
ZitatHabe ich das richtig Verstanden, dass bei interruptable der Perlcode oder die Regex für sich true ergeben müssen?
Ist angegeben: interuptable=Device:Reading:{Perl-Code} -> bei return "true" wird direkt unterbrochen, bei "false" forstgesetzt. $VALUE aus
Device:Reading kann im Code ausgewertet werden.
Bei swoncond und swoffond ist es genauso, nur das bei swoncond der Verbraucher überhaupt erst gestartet wird wenn "true" und bei
swoffond der Consumer auf "finished" gesetzt wird, d.h. er wird beendet und nicht nur unterbrochen.
ist angegeben: Device:Reading:Regex -> der Regex wird auf den Wert von Device:Reading angewendet -> bei "true" direkte Uterbrechung, bei "fals." Forstzung.
ZitatMeine Frage war, warum hier nicht ausgeschaltet wird?
Wird hier der physische Schalter nicht ausgeschaltet, weil der logische Zustand schon aus ist?
Die swoffcond ist "false" ->
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch off' => swoffcond: 0, off-command: pump_high off
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - is Consumption recommended: 1
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOffCond Info: The reference value "1" resulted in 'false' after exec "{main::Check_Pump_High_Off}"
-> the effect depends on the switch context
Da swoffcond nicht true ist, weiterhin PV da ist (is Consumption recommended: 1) wird nicht ausgeschaltet.
Meine Frage hat sich auf den Beitrag davor bezogen. Hier war die Frage, warum nicht eingeschaltet wurde.
Hier war die Frage warum nicht ausgeschaltet wurde.
https://forum.fhem.de/index.php?msg=1345175
Ah ok, Mißverständnis.
ZitatWird hier der physische Schalter nicht ausgeschaltet, weil der logische Zustand schon aus ist?
Ja, richtig.
Du kannst z.B. bei pcurr den :<Schwellenwert> ergänze und ihn recht hoch setzen, z.B 500 (W). Dann ist der Consumer erst dann aktiv gewertet wenn er > 500 W verbraucht.
Ich habe eine Frage zum Dummy-Verbraucher.
Woraus wird der Wert beim Dummy-Verbraucher ermittelt?
Eigentlich kann dieser Wert nur positiv sein, denn dieser Wert ergibt sich aus dem Wert des Hausknotens und der Verbraucher. Zumindest habe ich das so verstanden.
Laut SF Graphik ist dieser Wert ungefähr -6. Das kann sich aus Verzögerungen der Energieauswertung ergeben.
Aber der Wert -2327 beim Dummy-Verbraucher kann nicht stimmen.
Fällt ein Verbraucher mit hohem Verbrauch weg, ist der Dummy-Verbraucher zwar positiv, kann aber auch nicht stimmen.
Irgendwo muss ich einen Fehler verursacht haben.
Ja - solche Situationen habe ich manchmal auch.
Bei mir "schläft" der Messwert im zuständigen Mess-Device in solchen Fällen manchmal minutenlang ehe wieder ein aktualisierter Wert kommt, obwohl der Abfragezylus im Device extra klein (15 sec) eingestellt ist.
Andere Reading aus dem gleichen Gerät werden zwar immer wieder neu aktualisiert - aber der Wert vom aktuellem Verbrauch eben manchmal (noch) nicht.
Liegt also bei mir meist eindeutig an der eingesetzten Hardware die nicht "zeitnah" die "richtigen" Werte im entsprechenden Device zur Verfügung stellt.
Meine Waschmaschine und meine PV-WW-ZusatzHeater sind solche Kandidaten (==>> Fritz-Geräte)
Zitat von: 300P am 26 Juli 2025, 19:15:35Ja - solche Situationen habe ich manchmal auch.
Das stört mich jetzt nicht mehr, denn ich synchronisierte nun die Energiewerte mit dem Hauptzähler der alle 15 Sek. einen Event auslöst.
Das wäre für SF nicht schlecht den Trigger auf den Hauptzähler (Grid) zu definieren, um unrealistische Werte in der Grafikansicht einzudämmen.
Das mich stört ist der ermittelte Dummy-Wert beim Hausknoten der bei mir nicht stimmt. Ich finde den Fehler einfach nicht den ich irgendwo verursacht habe.
Am Ende wirst du merken das es ein ,,Zeitverzug sein wird der halt passiert". O:-)
Bei deinen Screenshots scheint hier die Ursache der Consumer zu sein, der einmal ON und danach ,,fast" AUS ist. ;)
Zitat von: 300P am 27 Juli 2025, 16:59:27Bei deinen Screenshots scheint hier die Ursache der Consumer zu sein, der einmal ON und danach ,,fast" AUS ist. ;)
Meinst du den Consumer 02 von links. Das passt vom Consumer. Der Geschirrspüler hat einmal die Heizung an und dann wieder aus. Wenn alle Verbraucher zusammengerechnet werden, kommst du auf 3356 kW. 3350 kW werden am Hauskonten angezeigt. Nur wenn du auf den Dummy-Verbraucher schaust siehst du einen Verbrauch von -2327 kW.
Beim anderen Screenshot wird am Dummy-Verbraucher zu viel angezeigt. Die Berechnung des Dummy-Verbrauchers weicht bei mir permanent zu viel ab. Und das sowohl viel zu viel ins Negative und zu viel ins Positive.
Wobei alle anderen Werte zusammenpassen.
Irgendwo ist bei mir ein Fehler vorhanden, der aber nach meinen Beobachtungen nichts mit einem Zeitverzug zu tun hat. Da müsste bei relativ konstantem Verbrauch sich der Dummy-Verbrauch anpassen. Das tut er aber nicht.
Der Zeitversatz müsste nach 20 Sek. behoben sein. Die Verbraucherwerte werden zwischen 10 und 15 Sek ermittelt und an SF übergeben.
Hallo Chris,
eine kurze Erläuterung zu dem Consumer Dummy.
Der Wert für diesen Dummy wird berechnet, indem von dem ermittelten Hausverbrauch (Wiki (https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Wie_wird_der_Verbrauch_des_Hauses_ermittelt_und_gespeichert?)) die gemessenen/gelieferten Anteile der registrierten Verbraucher abgezogen wird. Der verbleibende Rest ist der nicht zuordenbare Dummy-Verbrauch.
Du kannst ctrlDebug=collectData setzen. Am Ende des Log siehst du:
Zitat2025.07.27 18:15:08.453 1: SolCast DEBUG> current Power values -> PV2Node: 438 W, PV2Grid: 0, Other: 0 W, GridIn: 0 W, GridCon: 45 W, BatIn: 0 W, BatOut: 126 W
2025.07.27 18:15:08.453 1: SolCast DEBUG> current Consumption result -> 609 W
den Hausverbrauch.
Wenn ich mir deine Screenshots anschaue, fällt mir auch EG-KUE-GS auf der ein Großverbraucher ist. Du hast EG, OG1, OG2 integriert, die vermutlich keine echten Verbraucher sind, sondern nur Summenzähler oder Summendummies. Allerdings gehen sie als Verbraucher ein, wenn sie so definiert sind und werden gemäß der oben gezeigten Berechnung berücksichtigt was zwangsläufig zu Fehlern im Dummy in die eine oder andere Richtung führt.
Im einfachsten Fall blendest du dir den Consumer-Dummy nicht ein, denn es ist m.M. nach dadurch lediglich ein Schönheitsfehler wenn du EG, OG1, OG2 für dich richtig einordnen kannst.
LG,
Heiko
Schau dir die nachfolgenden Screenshots mal an.
Mein Device ,,Heater" reagiert einfach nicht zeitnah mit den richtigen Verbrauchswerten. :o
Daher ergibt sich die negative Summierung.....
Zitat von: DS_Starter am 27 Juli 2025, 18:33:14Wenn ich mir deine Screenshots anschaue, fällt mir auch EG-KUE-GS auf der ein Großverbraucher ist. Du hast EG, OG1, OG2 integriert, die vermutlich keine echten Verbraucher sind, sondern nur Summenzähler oder Summendummies. Allerdings gehen sie als Verbraucher ein, wenn sie so definiert sind und werden gemäß der oben gezeigten Berechnung berücksichtigt was zwangsläufig zu Fehlern im Dummy in die eine oder andere Richtung führt.
AB, EG, OG1, OG2 sind eigene Energiezähler. Auch die Verbraucher haben einen eigenen Energiezähler.
Die zugehörigen Verbraucher zu den Bereichen (AB, EG, OG1, OG2) werden aber in den Bereichen abgezogen, und somit stimmt die Summe der Verbraucher und Energiezähler der Bereiche annähernd, weil in der Anzeige auf und abgerundet wird. ~ +/-5W
Es stimmen auch alle Verbrauchs- und Produktions-Werte wie man auf meinen Shreenshots sehen kann. Nur der Dummy-Verbraucher hat ein Problem mit den ermittelten Werten.
consumer02EG_KUE_GSD:EG-Küche+Geschirrspüler
aliasshort=EG-KUE-GS
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
exconfc=2
icon=scene_dishwasher
interruptable=EG_KUE_GSD:SF_Int:1
mintime=180
mode=must
notafter=19:00
notbefore=06:30
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=2350
swstate=state:EIN:AUS
type=dishwasherconsumer11EG_SDM630M_01D:EG+gesamt
aliasshort=EG
etotal=Active_Energy__kWh:kWh
exconfc=2
icon=control_building_modern_s_eg
noshow=2
pcurr=Active_Power__W:W
power=0
type=otherZitat von: DS_Starter am 27 Juli 2025, 18:33:14Im einfachsten Fall blendest du dir den Consumer-Dummy nicht ein, denn es ist m.M. nach dadurch lediglich ein Schönheitsfehler wenn du EG, OG1, OG2 für dich richtig einordnen
Wenn das keinen Einfluss auf den SF mit den Vorhersagen hat kann ich diesen weglassen.
Zitat von: DS_Starter am 27 Juli 2025, 18:33:14Du kannst ctrlDebug=collectData setzen.
2025.07.28 10:44:08.422 1: AB_WS_SS DEBUG> collect Producer 01 data - device: AB_WG2KWD =>
2025.07.28 10:44:08.423 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:08.423 1: AB_WS_SS DEBUG> collect Producer 02 data - device: AB_NS6KWD =>
2025.07.28 10:44:08.424 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:08.424 1: AB_WS_SS DEBUG> collect Meter data - device: HTZ_SDM630M_01 =>
2025.07.28 10:44:08.424 1: AB_WS_SS DEBUG> gcon: 1083.8 W, gfeedin: 0 W, contotal: 22209830 Wh, feedtotal: 769902 Wh
2025.07.28 10:44:08.425 1: AB_WS_SS DEBUG> write to pvHistory - day: 28, hod: 11, GridConsumption (gcons): 601 Wh
2025.07.28 10:44:08.426 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_12k =>
2025.07.28 10:44:08.426 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2695.5 Wh, totalout: 2387.1 Wh, soc: 40
2025.07.28 10:44:08.427 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_15k =>
2025.07.28 10:44:08.427 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2499.1 Wh, totalout: 2313.5 Wh, soc: 20
2025.07.28 10:44:08.526 1: AB_WS_SS DEBUG> EnergyConsumption input -> PV: 600 Wh, PP: 0 Wh, GridIn: 0 Wh, GridCon: 601 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2025.07.28 10:44:08.526 1: AB_WS_SS DEBUG> EnergyConsumption result -> 1201 Wh
2025.07.28 10:44:08.530 1: AB_WS_SS DEBUG> current Power values -> PV2Node: 490 W, PV2Grid: 0, Other: 0 W, GridIn: 0 W, GridCon: 1083 W, BatIn: 0 W, BatOut: 0 W
2025.07.28 10:44:08.530 1: AB_WS_SS DEBUG> current Consumption result -> 1573 W
2025.07.28 10:44:10.543 1: AB_WS_SS DEBUG> collect Inverter 01 data - device: Deye_12k_SFD, source: pv, delivery: default =>
2025.07.28 10:44:10.543 1: AB_WS_SS DEBUG> pvOut: 0 W, pvIn: 180 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 2723300 Wh
2025.07.28 10:44:10.544 1: AB_WS_SS DEBUG> collect Inverter 02 data - device: Deye_15k_SFD, source: pv, delivery: default =>
2025.07.28 10:44:10.544 1: AB_WS_SS DEBUG> pvOut: 490 W, pvIn: 690 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 2718800 Wh
2025.07.28 10:44:10.545 1: AB_WS_SS DEBUG> collect Inverter 03 data - device: Deye_12k_SFD, source: bat, delivery: default =>
2025.07.28 10:44:10.545 1: AB_WS_SS DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> collect Inverter 04 data - device: Deye_15k_SFD, source: bat, delivery: default =>
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> summary data of all Inverters - pv: 490 W, this hour Generation: 600 Wh
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> State of Plant derating: 0, info: reductionState not set
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> currently saved 'pvrlvd' value: 1
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> current percentage pvrl/pvapifc deviation of hod 11: 960.0 % -> pvrlvd: 1
2025.07.28 10:44:10.790 1: AB_WS_SS DEBUG> collect Producer 01 data - device: AB_WG2KWD =>
2025.07.28 10:44:10.791 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.791 1: AB_WS_SS DEBUG> collect Producer 02 data - device: AB_NS6KWD =>
2025.07.28 10:44:10.792 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.792 1: AB_WS_SS DEBUG> collect Meter data - device: HTZ_SDM630M_01 =>
2025.07.28 10:44:10.792 1: AB_WS_SS DEBUG> gcon: 1024.7 W, gfeedin: 0 W, contotal: 22209830 Wh, feedtotal: 769902 Wh
2025.07.28 10:44:10.793 1: AB_WS_SS DEBUG> write to pvHistory - day: 28, hod: 11, GridConsumption (gcons): 601 Wh
2025.07.28 10:44:10.794 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_12k =>
2025.07.28 10:44:10.794 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2695.5 Wh, totalout: 2387.1 Wh, soc: 40
2025.07.28 10:44:10.795 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_15k =>
2025.07.28 10:44:10.795 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2499.1 Wh, totalout: 2313.5 Wh, soc: 20
2025.07.28 10:44:10.895 1: AB_WS_SS DEBUG> EnergyConsumption input -> PV: 600 Wh, PP: 0 Wh, GridIn: 0 Wh, GridCon: 601 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2025.07.28 10:44:10.895 1: AB_WS_SS DEBUG> EnergyConsumption result -> 1201 Wh
2025.07.28 10:44:10.898 1: AB_WS_SS DEBUG> current Power values -> PV2Node: 490 W, PV2Grid: 0, Other: 0 W, GridIn: 0 W, GridCon: 1024 W, BatIn: 0 W, BatOut: 0 W
2025.07.28 10:44:10.898 1: AB_WS_SS DEBUG> current Consumption result -> 1514 W
Zitat von: 300P am 27 Juli 2025, 21:10:46Schau dir die nachfolgenden Screenshots mal an.
Ich finde bei deinen Screenshots keinen Fehler. Da passt immer alles zusammen, auch wenn dein Heater manchmal nicht erfasst wurde.
Der einzige Unterschied deines Screenshots zu meinem ist die Einbindung der Batterie. Bei dir ist es der klassische Aufbau.
Bei mir ist die Batterie mit einem eigenen Inverter eingebunden. Die Energie des Batterieinverters wird beim PV-Inverter bei mir abgezogen oder dazugezählt, je nachdem, ob die Batterie geladen oder entladen wird. Damit passt die Summe am Inverter-Konten. Grüne Markierung.
Was mir aber jetzt aufgefallen ist, dürfte das genau das Problem für den Dummy-Verbraucher sein.
Das ist mir speziell an meinem ersten Shreenshot aufgefallen. Hier liefert der Hybrid-Inverter-1 81W und der Hybrid-Inverter-2 1019W und der Pseudo-Batterie-Inverter-2 des Hybrid-Iverter-2 2320W. Siehe grüne Markierungen die den Leistungswert am Inverter-Knoten 3240W ergibt.
Diese Werte stimmen mit denen meiner Hybrid-Inverter zusammen, was ich aber mit einer internen Berechnung im Vorfeld mache. Nur SF ist dafür nicht ausgelegt.
Es hängt wahrscheinlich auch damit zusammen.
Betrachtet man den Batterie-Inverter-2, wird hier der fast gleiche Wert angezeigt wie es beim Dummy-Verbraucher der Fall ist. Siehe rote Markierungen.
Was mir dazu noch aufgefallen ist, ist die Batterie die trotz Batterie-Inverter Konfiguration (ac2dc/dc2ac) zusätzlich die Einbindung am Inverter- und Haus-Knoten hat, die eigentlich nicht mehr benötigt werden.
Wenn sich diese Konfiguration nicht auf das SF auswirkt, kann ich den Dummy-Verbraucher weglassen und es passt soweit alles.
@Heiko
In meinem Post befindet sich die Datei energiemanagement.pm die meine SF Konfiguration beinhaltet.
Vielleicht fällt dir noch etwas auf.
Ich denke ich habe somit mein Dummy-Verbraucher Problem gefunden.