76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

DS_Starter

Von mir auch ein Beispiel.
Mit meinen 0% Margin werde ich 100% Ldung heute wohl nicht ganz erreichen, und wenn dann nur ganz knapp.
(V 1.58.3 aus dem contrib)

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

klaus.schauer

#4066
Zitat von: Max_Meyer am 16 September 2025, 14:06:02
Zitat von: klaus.schauer am 16 September 2025, 11:18:49Übernimmt ein SMA Homemanager 2.0 die zentrale Steuerung der Energieströme zwischen den Wechselrichtern oder wird hierzu ein anderes Hilfsprogramm oder das SolarForecast-Modul selbst genutzt?
- Werden für den AC-Aus-/Eingang (SPOT_PACTOT) des Hybridwechselrichters beim Laden durch die anderen Wechselrichter zeitweise negative Werte ausgegeben?
- Falls ja, wie verhält sich dann die Saldierung des SolarForecast-Moduls, da ja für den AC-Pfad "pvOut" lt. Online-Hilfe expliziert nur positive Werte erlaubt sind?
- Werden teilweise zusätzliche Berechnungen durchgeführt, um die Rohdaten der Wechselrichter aus dem SMAInverter-Modul z. B. "SPOT_PACTOT" an die SolarForecast-Enerigepfade z. B. "pvOut" anzupassen?
Sorry- das hatte ich anders aufgefasst
Nicht schlimm. Jetzt habe ich jedenfalls die Bestätigung, dass ich die passenden Eingangsgrößen verwende.
ZitatNein ich fahre hier mit eigener Logik. Aus meiner Sicht liegt ein großer Vorteil von SF darin, dass herstellerneutral alle Geräte (Erzeuger + Consumer) normiert eingebundenen werden und in die Prognoseplanung mit einbezogen werden können. SF sozusagen als Plattform für das gesamte Hausenergiemanagement.
Bei entsprechender Schnittstellennutzung lässt sich der EM2 und SF sicher kombinieren,  ob das sinnvoll ist?
Ich setze da eher auf Standardlösungen für die Grundfunktionen, die auch noch laufen, wenn Fhem mal ausnahmsweise einen Schluckauf hätte.
Wie ich schon im ersten Beitrag beschrieben habe, soll der HomeManager 2.0 auch als EEBus-Energiemanagementsystem (EMS) nach § 14a EnWG für die Leistungsbegrenzung der Wärmepumpe und der Wallbox genutzt werden, sobald der Netzbetreiber bereit ist. Später soll dann auch die Einspeisebegrenzung nach § 9 EEG über EEBus bereitgestellt werden. Das wird  Fhem auf absehbare Zeit nicht oder vielleicht grundsätzlich nie leisten können.

So erhoffe ich mir von SolarForecast als Ergänzung eine Lösung für eine zusätzliche prognosebasierte Steuerung der Wärmepumpe in Zeiten mit Niedrig- und Hochlasttarifstufen für das Netzentgelt (§ 14a EnWG Modul 3).

Damit wäre ich wieder bei der Ausgangsfrage, wie ich SolarForecast für die Konstellation
- SMA STP10.0SE (SUNNY TRIPOWER 10.0 SE) mit angeschlossenem Solarspeicher
- SMA STP3.0-3AV-40 (Sunny Tripower 3.0)
- SMA Homemanager 2.0
konfigurieren muss. Die derzeitige Konfiguration
setupInverterDev01: wr4136601s strings=south capacity=10000 pvIn=SPOT_PDC_SUM:W pvOut=SPOT_PACTOT:W etotal=SPOT_EPVTOTAL:Wh asynchron=1
setupInverterDev02: wr4136602s strings=east capacity=3000 pvIn=SPOT_PDC_SUM:W pvOut=SPOT_PACTOT:W etotal=SPOT_ETOTAL:Wh asynchron=1
setupInverterDev03: wr4136601s strings=none capacity=10000 ac2dc=BAT_P_CHARGE:W dc2ac=BAT_P_DISCHARGE:W asynchron=1
setupBatteryDev01: wr4136601s pin=BAT_P_CHARGE:W pout=BAT_P_DISCHARGE:W pinmax=10000 poutmax:10000 intotal=BAT_LOADTOTAL:Wh outtotal=BAT_UNLOADTOTAL:W cap=19300 charge=ChargeStatus asynchron=1 show=1:bottom
setupMeterDev: wr4136601s gcon=Meter_Power_Grid_Consumation:W contotal=Meter_TOTAL_Grid_Consumation:Wh gfeedin=Meter_Power_Grid_FeedIn:W feedtotal=Meter_TOTAL_Grid_FeedIn:Wh asynchron=1
müsste augenscheinlich noch um eine zusätzliche Logik ergänzt werden. Dazu warte ich dann notfalls auf die angekündigten Beschreibungen im Wiki.

Es bleibt dennoch die Frage, ob es nicht sinnvoller wäre, einen Wechselrichtertyp "PV-Hybridinverter" in SolarForecast einzuführen oder das bestehende Profil zu ergänzen? Damit könnten die zusätzlichen Energiepfade für Solarspeicher "batIn" / "batOut" und die Energieeinspeisung durch andere Wechselrichter über "pvOut" dort unmittelbar saldiert werden. Der Bedarf dafür sollte herstellerübergreifend bestehen.



DS_Starter

#4067
Jetzt habe ich den Tag nochmal ausgewertet. Es gab bei mir heute tatsächlich auch noch eine Punktlandung. Wie geplant war die Batterie gegen 18:00 voll.

@klaus,
ZitatEs bleibt dennoch die Frage, ob es nicht sinnvoller wäre, einen Wechselrichtertyp "PV-Hybridinverter" in SolarForecast einzuführen oder das bestehende Profil zu ergänzen? Damit könnten die zusätzlichen Energiepfade für Solarspeicher "batIn" / "batOut" und die Energieeinspeisung durch andere Wechselrichter über "pvOut" dort unmittelbar saldiert werden. Der Bedarf dafür sollte herstellerübergreifend bestehen.
Das ist durchaus noch auf dem Plan, mache es aber abhängig vom Bedarf der User damit ich meine Zeit/Arbeit konzentrieren kann. Es ist noch einiges bei mir auf dem Plan und das Wiki möchte ja auch noch weiter ergänzt werden.

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

Max_Meyer

Zitat von: klaus.schauer am 16 September 2025, 18:57:03Ich setze da eher auf Standardlösungen für die Grundfunktionen, die auch noch laufen, wenn Fhem mal ausnahmsweise einen Schluckauf hätte.
Guten Morgen Klaus,
als Rückfallstrategie ist das bei mir durchaus auch so - da wirkt eben dann keine Optimierung ist z.B. der Akku schon 11:00 Uhr voll. Aber was ist 'Standardlösung' ?
SMA-HM2? - der HM2 wird verschwinden - ich war im Frühjahr bei einer SMA-Schulung mit Ausblick Produktentwicklung - der Sunny Boy Smart Energy hat das schon im WR integriert - Preisdruck. Und das Ausrollen der ÜNB-Smartmeter - die machen das stückweise überflüssig (redundante Daten) - ÜNB akzeptieren (derzeit) nur Ihre eigenen, genormten Geräte mit Rundsteuerempfänger.
Nichtsdestotrotz wird die dem HM2 hinter liegende Cloudlösung bleiben und sehr Nutzerfreundlich werden. - wenn du das als Standard siehst?

Zitat von: klaus.schauer am 16 September 2025, 18:57:03So erhoffe ich mir von SolarForecast als Ergänzung eine Lösung für eine zusätzliche prognosebasierte Steuerung der Wärmepumpe in Zeiten mit Niedrig- und Hochlasttarifstufen für das Netzentgelt
Derzeit unterstützt SF keine Prognose von einzelnen Verbrauchern

Zitat von: klaus.schauer am 16 September 2025, 18:57:03später soll dann auch die Einspeisebegrenzung nach § 9 EEG über EEBus bereitgestellt werden.
das gilt für elektrische Leistungen ab 4,2 kW

Ich glaube das es zumindest die nächsten Jahre - solange der Smartmeterrollout der ÜNB noch auf sich warten lässt keine 'Standardlösung' geben wird.
Zitat von: klaus.schauer am 16 September 2025, 18:57:03müsste augenscheinlich noch um eine zusätzliche Logik ergänzt werde

Hier verstehe ich deine Frage nicht - nach meinem Verständnis ist der SMA-STP energieflussrichtig in die PV-Anlage eingebunden
Gruß Gerd






FHEM: PI3...5 FB7590/7530/EnOcean/FS20 /Revolt/FHEM2FHEM/HTTPMOD-->Solmaxx-, Deye-, Bosswerk-Inverter/ModBusTCP -->SMA-Inverter, GoE-Charger, BröntjeWP/Solarforecast/DbLog/DbRep/PostgreSQLDB/Grafana/MQTT-->Shelly,FHEM,HMS/HCCON/Netatmo/KLF etc.

Parallix

Zitat von: Max_Meyer am 17 September 2025, 07:23:31...
Derzeit unterstützt SF keine Prognose von einzelnen Verbrauchern
...

Woher hast Du denn diese Info? Da die Verbrauchsdaten für jeden registrierten Verbraucher getrennt gespeichert werden (vgl. Wiki) liegt SF zumindest die Datenbasis für eine verbraucherspezifische Prognose vor.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

klaus.schauer

Zitat von: Max_Meyer am 17 September 2025, 07:23:31Ich glaube das es zumindest die nächsten Jahre - solange der Smartmeterrollout der ÜNB noch auf sich warten lässt keine 'Standardlösung' geben wird. ÜNB akzeptieren (derzeit) nur Ihre eigenen, genormten Geräte mit Rundsteuerempfänger.
Nun ja Westnetz z. B. empfiehlt schon seit Juli 2024 - auf dem Papier - die digitale Verbrauchersteuerung nach §14a EnWG mit EEBus-Schnittstellen, siehe https://www.westnetz.de/content/dam/revu-global/westnetz/documents/bauen/ihr-weg-zum-netzanschluss/niederspannung/tab-niederspannung-01092025.pdf und https://www.westnetz.de/content/dam/revu-global/westnetz/documents/bauen/ihr-weg-zum-netzanschluss/niederspannung/technische-mindestanforderung-steuerbarer-verbrauchseinrichtungen-20240701.pdf jeweils Kapitel 7. Es besteht also Grund zur Hoffnung.

Parallix

#4071
Zitat von: klaus.schauer am 17 September 2025, 09:55:48
Zitat von: Max_Meyer am 17 September 2025, 07:23:31Ich glaube das es zumindest die nächsten Jahre - solange der Smartmeterrollout der ÜNB noch auf sich warten lässt keine 'Standardlösung' geben wird. ÜNB akzeptieren (derzeit) nur Ihre eigenen, genormten Geräte mit Rundsteuerempfänger.
Nun ja Westnetz z. B. empfiehlt schon seit Juli 2024 - auf dem Papier - die digitale Verbrauchersteuerung nach §14a EnWG mit EEBus-Schnittstellen, siehe https://www.westnetz.de/content/dam/revu-global/westnetz/documents/bauen/ihr-weg-zum-netzanschluss/niederspannung/tab-niederspannung-01092025.pdf und https://www.westnetz.de/content/dam/revu-global/westnetz/documents/bauen/ihr-weg-zum-netzanschluss/niederspannung/technische-mindestanforderung-steuerbarer-verbrauchseinrichtungen-20240701.pdf jeweils Kapitel 7. Es besteht also Grund zur Hoffnung.

Gleiches geht übrigens aus diversen FNN-Veröffentlichungen hervor, wie z.B.  dieser hier.

PS: Für das iMSys-Rollout sind übrigens die Messstellenbetreiber zuständig.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

Max_Meyer

Zitat von: Parallix am 17 September 2025, 09:44:54Woher hast Du denn diese Info? Da die Verbrauchsdaten für jeden registrierten Verbraucher getrennt gespeichert werden (vgl. Wiki) liegt SF zumindest die Datenbasis für eine verbraucherspezifische Prognose vor.
Hallo Parallix, Hallo Klaus,
du hast Recht - die Datenbasis ist da  -die Prognose aber (noch) nicht - deswegen hatte ich 'derzeit' geschrieben.

Zitat von: Parallix am 17 September 2025, 10:14:37Gleiches geht übrigens aus diversen FNN-Veröffentlichungen hervor, wie z.B.  dieser hier.
Zitat von: klaus.schauer am 17 September 2025, 09:55:48Nun ja Westnetz z. B. empfiehlt schon seit Juli 2024 - auf dem Papier - die digitale Verbrauchersteuerung nach §14a EnWG mit EEBus-Schnittstellen, siehe https://www.westnetz.de/content/dam/revu-global/westnetz/documents/bauen/ihr-weg-zum-netzanschluss/niederspannung/tab-niederspannung-01092025.pdf und https://www.westnetz.de/content/dam/revu-global/westnetz/documents/bauen/ihr-weg-zum-netzanschluss/niederspannung/technische-mindestanforderung-steuerbarer-verbrauchseinrichtungen-20240701.pdf jeweils Kapitel 7. Es besteht also Grund zur Hoffnung.

Ich bin auch der Meinung das dies die Zukunft ist. Aber HM2 und andere 'private' Smartmeter sind nicht als Messeinrichtung vorgesehen - zumindest nach meinem Wissenstand
Sollten wir das weiter diskutieren wollen würde ich ein separates Topic bevorzugen - ist hier off-Topic m.M.n.

@Klaus
vielleicht könntest du etwas ausführlicher beschreiben wo dein Problem im Energiefluss des Hybrid-WR legt - ich würde das gern verstehen

Gruß Gerd

FHEM: PI3...5 FB7590/7530/EnOcean/FS20 /Revolt/FHEM2FHEM/HTTPMOD-->Solmaxx-, Deye-, Bosswerk-Inverter/ModBusTCP -->SMA-Inverter, GoE-Charger, BröntjeWP/Solarforecast/DbLog/DbRep/PostgreSQLDB/Grafana/MQTT-->Shelly,FHEM,HMS/HCCON/Netatmo/KLF etc.

Parallix

Zitat von: Max_Meyer am 17 September 2025, 10:36:03...
Aber HM2 und andere 'private' Smartmeter sind nicht als Messeinrichtung vorgesehen - zumindest nach meinem Wissenstand
Sollten wir das weiter diskutieren wollen würde ich ein separates Topic bevorzugen - ist hier off-Topic m.M.n.
...

Es gilt zu unterscheiden zwischen der Messeinrichtung des Messstellenbetreibers und des EMS-Systems des Anlagenbeteibers. Da SF sicher ein Teil eines solchen EMS-Systems ist, kann eine entsprechende Diskussion hier eigentlich nicht OT sein.

@Heiko: Siehst Du das anders?
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

#4074
Moin zusammen,

alles gut. Ich verfolge die Diskussionsbeiträge auch sehr interessiert, auch wenn ich eher in die Weiterentwicklung und Wikibearbeitung abtauche und momentan eher mit ein paar Urlaubsvorbereitungen beschäftigt bin.  ;)  Deswegen hält sich mein Engagement für FHEM/SF zur Zeit etwas in Grenzen.

Aber ich lese immer wieder mit und versuche auch die Konsequenzen einzuordnen, wo SF in dem Gesamtbild für uns sinnvolle Unterstützung liefern kann.
Wenn es dann wieder fachlich mehr um das Modul gehen wird seht ihr es ja und könnt mit dieser Diskussion dann etwas im Hintergrund bleiben um den Faden nicht zu sehr zu unterbrechen.

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

grappa24

Ich bin ja ganz begeistert von der Beladungssteuerung mittels Battery_ChargeOptTargetPower_XX.

Zum Verständnis: Das Reading "Battery_ChargeOptTargetPower_XX" ist der einzige steuernde Parameter (außer safetyMargin) ?

bzw. welche Rolle spielen dabei
- Battery_ChargeRecommended_01
- Battery_ChargeRequest_01
- Battery_ChargeUnrestricted_01

Ich weiß, steht alles im Wiki, ich bin halt nunmal jemand, der sich von der praktischen Seite annähert  ;)
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

DS_Starter

ZitatZum Verständnis: Das Reading "Battery_ChargeOptTargetPower_XX" ist der einzige steuernde Parameter (außer safetyMargin) ?
Für diese Strategie ("optimale Ladestromsteuerung") ja.

Zitatbzw. welche Rolle spielen dabei
- Battery_ChargeRecommended_01
- Battery_ChargeRequest_01
- Battery_ChargeUnrestricted_01

- Battery_ChargeRecommended_01 -> ist veraltet und wird demnächst gelöscht, steht in der Mailbox  ;)
- Battery_ChargeUnrestricted_01 -> ist das Steuerreading für die Strategie "Ladung nach Freigabe"
- Battery_ChargeRequest_01 -> ist ein Reading welches eine Notladung (vom Grid) signalisiert falls (im Winter) lowSoc unterschritten werden sollte


Bei mir hat es heute auch wieder sehr gut funktioniert ... ca. 16:00 war der Akku wie geplant voll.
Die V 1.58.3 (mit ein paar kleinen Nachbesserungen) läuft so wie ich es mir vorstelle und chekce sie sicherlich heute Abend noch ein.

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

Hadl

Ich hab gestern auch nochmal auf die Version aus dem Contrib aktualisiert und möchte meine Ergebnisse mit euch teilen.
Die Steuerung über Battery_ChargeOptTargetPower ist echt super, ich will auf jedem Fall dabei bleiben. Nach unten hin (SOC) nehme ich weiterhin Battery_OptimumTargetSoC_01 um bei Unterschreitung noch schneller zu laden, um erstmal etwas Reserve im Speicher zu haben (Full Backup, hoher Verbrauch,...)

Das sieht man heute früh auch recht gut, das er solange er unter 40% war erstmal schneller geladen hat.

Was mich aber noch stört ist das doch recht ausgeprägte "Sägezahn" Profil beim Laden.
Scheinbar reagiert da mein Akku auch etwas komisch drauf, denn jeden Tag musste er den SOC deutlich korrigieren.
Gestern hat er noch 74 Minuten mit ca. 510W geladen bis er von 99,2% auf 100% gesprungen ist. Heute dann das Gegenteil. Er hat bei 93% schon die Ladeleistung auf 0W runter und dann nur noch "leer" auf 100% hochgerampt.
Kurz vorher beim Stundenwechsel von 15:59 auf 16:00 war der letzte "Sägezahn" Sprung von OPT von 500W auf 922W
Hier mal ein paar ausgewählte Zeilen aus dem Log, indem man diesen Sägezahn sieht.
Zitat2025.09.17 15:50:15 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 521 W, sum need: 1042 Wh, number hrs: 2, OTP-average: 521 W
2025.09.17 15:51:25 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 516 W, sum need: 1032 Wh, number hrs: 2, OTP-average: 516 W
2025.09.17 15:52:36 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 507 W, sum need: 1014 Wh, number hrs: 2, OTP-average: 507 W
2025.09.17 15:53:46 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 502 W, sum need: 1004 Wh, number hrs: 2, OTP-average: 502 W
2025.09.17 15:54:56 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 500 W, sum need: 1000 Wh, number hrs: 2, OTP-average: 500 W
2025.09.17 15:56:06 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 500 W, sum need: 1000 Wh, number hrs: 2, OTP-average: 500 W
2025.09.17 15:57:16 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 500 W, sum need: 1000 Wh, number hrs: 2, OTP-average: 500 W
2025.09.17 15:58:26 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 500 W, sum need: 1000 Wh, number hrs: 2, OTP-average: 500 W
2025.09.17 15:59:36 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 500 W, sum need: 1000 Wh, number hrs: 2, OTP-average: 500 W
2025.09.17 15:59:50 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 500 W, sum need: 1000 Wh, number hrs: 2, OTP-average: 500 W
2025.09.17 16:00:04 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 922 W, sum need: 922 Wh, number hrs: 1, OTP-average: 922 W
2025.09.17 16:00:46 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 912 W, sum need: 912 Wh, number hrs: 1, OTP-average: 912 W
2025.09.17 16:01:56 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 894 W, sum need: 894 Wh, number hrs: 1, OTP-average: 894 W
2025.09.17 16:03:07 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 876 W, sum need: 876 Wh, number hrs: 1, OTP-average: 876 W
2025.09.17 16:04:17 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 802 W, sum need: 802 Wh, number hrs: 1, OTP-average: 802 W
2025.09.17 16:05:26 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 691 W, sum need: 691 Wh, number hrs: 1, OTP-average: 691 W

Um das zu vermeiden denke ich man muss "number hrs" nicht als Ganzzahl von 2 auf 1 Springen lassen, sondern sollte um 15:59 auch nur noch 1,017 Stunden haben

Im Anhang ist das ganze Log dazu

Viele Grüße

Hadl
FHEM: Rpi 5 + SSD / WR: Fronius Symo Gen24 10.0 Plus + BYD HVS 7.7, Fronius Symo Gen24 12.0 SC (60%) PV: (Ost=3.5 West=6.6 Nord=9.9 Ost=4.5) / Homematic BidCoS / Shelly / Viessmann