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

Im contrib liegt die V 1.60.4.

Für das Reading Battery_ChargeOptTargetPower_XX ist eine Glättungsfunktion eingebaut. Das bedeutet, dass nicht jede kleinste Änderung des Leistungslimits im Reading upgedated wird, sondern erst wenn ein Schwellenwert der Änderung überschritten wird. Diesen Wert habe ich (vorerst) auf 10W empirisch definiert. Dadurch werden Änderungen erst dann an die reale Batteriesteuerung übertragen, wenn diese Änderungsschwelle überschritten wird.

Außerdem habe ich die oben erwähnte Behandlung der Batterie-Effizienz ausgebaut und wieder konzentriert an exponierten Stellen eingesetzt.

Leider wird der Praxistest bei mir längere Zeit nichts bringen weil die nächsten Tage unterirdische PV vorhersagen. Vielleicht habt ihr eher die Möglichkeit dazu. Wäre super  :).

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

Zitat von: DS_Starter am 09 November 2025, 00:00:46Für das Reading Battery_ChargeOptTargetPower_XX ist eine Glättungsfunktion eingebaut
Herzlichen Dank für deine Mühe!

Zitat von: DS_Starter am 09 November 2025, 00:00:46Außerdem habe ich die oben erwähnte Behandlung der Batterie-Effizienz ausgebaut und wieder konzentriert an exponierten Stellen eingesetzt.
Danke, aber ich glaub so ganz passts auch jetzt noch nicht. "runwhneed" ist jetzt nur noch die Netto-Zielenergie im Akku die wir brauchen, aber nichtmehr die Brutto Energie zum Akkuladen.
Das "Achievable" und die Suche ___batFindMinPhWh rechnet jetzt nur mit der niedrigeren Netto Energie und Ladeleistung.
Im Anschluss wird die Leistung zur gefundenen Netto Leistung dann zwar in ___batAdjustEfficiencyAndLimits erhöht, aber einige Stunden am Tag können das evtl. garnicht leisten, oder wir sind über dem Limit. Damit haben wir am Ende des Tages warscheinlich zu wenig Energie geladen oder mussten Leistung nachträglich erhöhen.
Wir sollten aus der Netto Energie die der Akku benötigt zuerst die Brutto Energie (Netto / Efficiency) berechnen und mit dieser dann den Achievable und ___batFindMinPhWh berechnen.

Zitat von: DS_Starter am 09 November 2025, 00:00:46Leider wird der Praxistest bei mir längere Zeit nichts bringen weil die nächsten Tage unterirdische PV vorhersagen. Vielleicht habt ihr eher die Möglichkeit dazu. Wäre super  :).
Ja, selbst bei meiner Anlagengröße reichts gerade nicht um den Akku voll zu bekommen. Aber evtl. reichts wieder in den nächsten Tagen.
Gestern hatte ich das erste mal ein "hochzählen" von Battery_OptimumTargetSoC von 5% auf 10%.
Allerdings hab ich incl. heute den dritten Tag in folge meinen MaxSoc nicht erreicht. Ich hatte also schon drei Erhöhungen erwartet. Dann aber das komische: Gestern Abend geht er wieder auf 5% runter, obwohl heute auch mies ist.
Hier die beiden Log's zu den Veränderungen
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging raw: 6405 Wh
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging after application Share factor: 6405 Wh
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 10 %
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 6405 Wh, need until maxsoc: 5967 Wh
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 5 %, Remaining days until care SoC: 24, Target: 10 %
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: 17 %, newtarget: 10 %
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 0, Target: 10 % (new target > 5 % and Sunset has passed)
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 0, lowSoc: 5 %, upSoc: 20 %
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 10 %
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 10 %
2025.11.08 17:29:23 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)

2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging raw: 8571 Wh
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging after application Share factor: 8571 Wh
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 10 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 8571 Wh, need until maxsoc: 7212 Wh
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 5 %, Remaining days until care SoC: 24, Target: 10 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: -12 %, newtarget: -12 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 0, Target: 5 % (new target < current Target SoC 10)
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 0, lowSoc: 5 %, upSoc: 20 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 5 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 5 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - General load termination condition: 0
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier SoC: 40 % / 3072 Wh
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier Parameter: set:4444
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 87 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - charging target: 100 % / 7680 Wh
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 7212 Wh -> target likely achievable? no
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - current Ratio of surplus / energy requirement to achieve the load target: 0 %
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 08/23 - hod:24/00, lr/lc:1/1, SocS/E:468/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/00 - hod:01/01, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/01 - hod:02/02, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/02 - hod:03/03, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/03 - hod:04/04, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/04 - hod:05/05, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/05 - hod:06/06, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/06 - hod:07/07, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/07 - hod:08/08, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/08 - hod:09/09, lr/lc:1/1, SocS/E:384/768 Wh, SurpH/D:108/0 Wh, OTP:3000/476 W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/09 - hod:10/10, lr/lc:1/1, SocS/E:768/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/10 - hod:11/11, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/11 - hod:12/12, lr/lc:1/1, SocS/E:384/798 Wh, SurpH/D:476/0 Wh, OTP:3000/476 W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/12 - hod:13/13, lr/lc:1/1, SocS/E:798/1141 Wh, SurpH/D:394/0 Wh, OTP:3000/394 W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/13 - hod:14/14, lr/lc:1/1, SocS/E:1141/1093 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/14 - hod:15/15, lr/lc:1/1, SocS/E:1093/1071 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/15 - hod:16/16, lr/lc:1/1, SocS/E:1071/768 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/16 - hod:17/17, lr/lc:1/1, SocS/E:768/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/17 - hod:18/18, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W

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

DS_Starter

Im Parameter ctrlBatSocManagementXX->loadTarget kann man neben dem SoC-Ziel nun auch eine Zielzeit mitgeben, wobei auch eine (negative) Relativzeit zum Sonnenuntergang verwendet werden kann:

loadTarget
   
        Optionaler Ziel-SoC (%), Zielzeit zur Berechnung der Ladefreigabe und optimalen Ladeleistung.
   Der angegebene Ziel-SoC muß größer als der Wert von 'lowSoC' sein. Ein höherer Wert im Reading
   Battery_OptimumTargetSoC_XX gegenüber der Parametervorgabe hat Vorrang.
   Eine angegebene Zielzeit ist die volle Stunde (1..20) oder als negativer Wert (-20..-1) die
   letzte volle Stunde vor dem Sonnenuntergang abzüglich diesem Wert.
   Syntax: <Ziel-SoC>[:<Zielzeit>]
   Wertebereich Ziel-SoC: lowSoc..100, default: 100
   Wertebereich Zielzeit: -20..20 (ohne führende Null), default: undefiniert


Update liegt wieder im 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

DS_Starter

#4473
ZitatDanke, aber ich glaub so ganz passts auch jetzt noch nicht. "runwhneed" ist jetzt nur noch die Netto-Zielenergie im Akku die wir brauchen, aber nichtmehr die Brutto Energie zum Akkuladen.
Das "Achievable" und die Suche ___batFindMinPhWh rechnet jetzt nur mit der niedrigeren Netto Energie und Ladeleistung.
Im Anschluss wird die Leistung zur gefundenen Netto Leistung dann zwar in ___batAdjustEfficiencyAndLimits erhöht, aber einige Stunden am Tag können das evtl. garnicht leisten, oder wir sind über dem Limit. Damit haben wir am Ende des Tages warscheinlich zu wenig Energie geladen oder mussten Leistung nachträglich erhöhen.
Man wird sehen...
In jedem Zyklus wird der gesamte Tag durchlaufen, nicht nur eine Stunde. D.h. das Nettoergebnis aus ___batFindMinPhWh und nachgelagerten Subs wird sowohl für die Weiterschreibung (Prognose) für jede einzelne betrachtete Stunde als auch für die aktuelle Stunde am Ende immer auf den Bruttowert gebracht und mit den max/min Grenzen behandelt. Damit sollte das passen.
Aber der Praxistest wird es zeigen. Die Devise ist "So einfach wie möglich - so kompliziert wie nötig".

ZitatJa, selbst bei meiner Anlagengröße reichts gerade nicht um den Akku voll zu bekommen. Aber evtl. reichts wieder in den nächsten Tagen.
Gestern hatte ich das erste mal ein "hochzählen" von Battery_OptimumTargetSoC von 5% auf 10%.
Allerdings hab ich incl. heute den dritten Tag in folge meinen MaxSoc nicht erreicht. Ich hatte also schon drei Erhöhungen erwartet. Dann aber das komische: Gestern Abend geht er wieder auf 5% runter, obwohl heute auch mies ist.

Entweder war mal für heute mehr Überschuß als benötigt angezeigt oder (wahrscheinlich) ist morgen wieder genügend Überschuß in der Prognose. Deswegen wird Platz frei gemacht und die Energie in das Haus geliefert:

2025.11.08 23:33:36 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: -12 %, newtarget: -12 %

Hier kann die Bat mehr als voll geladen werden. Bei cantarget steht sonst irgendein höherer Wert wie bei mir:

2025.11.09 15:29:00.444 1: SolCast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: 69 %, newtarget: 15 %
-> SoC Opt wurde auf 15% gesetzt, wird morgen weiter auf 20% steigen wenn kein Wunder geschieht.  ;)
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

Zitat von: DS_Starter am 09 November 2025, 16:47:33am Ende immer auf den Bruttowert gebracht und mit den max/min Grenzen behandelt
Ja, genau da denke ich liegt das kleine Problem. So kann es passieren das man in einer Stunde mit 1000Wh Überschuss, auch mit 1000W laden will, dann wegen efficiency die Grenze auf 1150W gesetzt wird.
Die anderen Stunden laden auch weniger weil davon ausgegangen wird, das für diese Stunde 1000Wh mehr im Akku ist - aber der Akku hat am Ende der Stunde nur 870Wh mehr Ladung.
Am Ende gehen dann sogar die 1150Wh dafür in die Prognose ein, was aber nicht erreichbar ist.

Zitat von: DS_Starter am 09 November 2025, 16:47:33Entweder war mal für heute mehr Überschuß als benötigt angezeigt oder (wahrscheinlich) ist morgen wieder genügend Überschuß in der Prognose. Deswegen wird Platz frei gemacht und die Energie in das Haus geliefert:
Ich hab mal die Überschuss-Prognose zu dem Zeitpunkt 2025.11.08 23:33:36 mit als Edit in den #4471 mit reingenommen. Das ist weniger als eine kWh, daran sollte es nicht liegen. Auch im Nachgang wurde der Akku nur von 5% bis ca. 40% voll. Die Abweichung zwischen Prognose und Erzeugung sind 3%.
Man hätte also leicht den SOC etwas anheben können, dann würde der Akku nicht so viel am unteren Limit hängen.
Hab ich da vielleicht etwas noch nicht richtig konfiguriert?

Für morgen wieder keine Anhebung des SOC, und folgende Prognose:
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging raw: 12861 Wh
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging after application Share factor: 12861 Wh
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 10 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 12861 Wh, need until maxsoc: 7127 Wh
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 5 %, Remaining days until care SoC: 24, Target: 10 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: -67 %, newtarget: -67 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 0, Target: 5 % (no change)
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 0, lowSoc: 5 %, upSoc: 20 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 5 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 5 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - General load termination condition: 0
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier SoC: 40 % / 3072 Wh
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier Parameter: set:4444
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 87 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - charging target: 100 % / 7680 Wh
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 7127 Wh -> target likely achievable? no
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - current Ratio of surplus / energy requirement to achieve the load target: 0 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/20 - hod:21/00, lr/lc:1/1, SocS/E:553/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/21 - hod:22/01, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/22 - hod:23/02, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 09/23 - hod:24/03, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/00 - hod:01/04, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/01 - hod:02/05, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/02 - hod:03/06, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/03 - hod:04/07, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/0 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/04 - hod:05/08, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/196 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/05 - hod:06/09, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/440 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/06 - hod:07/10, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/664 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/07 - hod:08/11, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/997 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/08 - hod:09/12, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/1041 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/09 - hod:10/13, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/1159 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/10 - hod:11/14, lr/lc:1/1, SocS/E:384/384 Wh, SurpH/D:0/2014 Wh, OTP:3000/- W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/11 - hod:12/15, lr/lc:1/1, SocS/E:384/726 Wh, SurpH/D:393/1621 Wh, OTP:3000/2041 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/12 - hod:13/16, lr/lc:1/1, SocS/E:726/1661 Wh, SurpH/D:1075/546 Wh, OTP:3000/2041 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/13 - hod:14/17, lr/lc:1/1, SocS/E:1661/3437 Wh, SurpH/D:2041/0 Wh, OTP:3000/2041 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/14 - hod:15/18, lr/lc:1/1, SocS/E:3437/4263 Wh, SurpH/D:949/0 Wh, OTP:3000/949 W
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 10/15 - hod:16/19, lr/lc:1/1, SocS/E:4263/4518 Wh, SurpH/D:293/0 Wh, OTP:3000/293 W
4518Wh im Akku wären 59% SOC. Mal sehen, aktuell ist der Akku leer.

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

DS_Starter

#4475
ZitatJa, genau da denke ich liegt das kleine Problem. So kann es passieren das man in einer Stunde mit 1000Wh Überschuss, auch mit 1000W laden will, dann wegen efficiency die Grenze auf 1150W gesetzt wird.
Die anderen Stunden laden auch weniger weil davon ausgegangen wird, das für diese Stunde 1000Wh mehr im Akku ist - aber der Akku hat am Ende der Stunde nur 870Wh mehr Ladung.
Sehe ich nicht so. Es sollen 1000Wh in den Akku und wegen der Effizemz wird die Ladeleistung auf 1150W gesetzt.
Wenn davon ausgegangen wird, dass wirklich die 1150W eine Stunde lang auf die Bat einwirken (passiert nur bei wirklich genügend Überschuß und stabilen Bedingungen), werden 1000Wh in der Bat drin sein. Die Fortschreibung der Progose berücksichtigt das. D.h. in der nächsten Runde vermindert sich der Bedarf um 1000Wh und rechnet damit neu. Gleichzeitig wird die aktuelle Stunde immer um die Effizienz erhöht. Nur die aktuelle Stunde ist das was wirklich bei der Bat anliegt. Alles andere ist nur Prognose.

Aber wie gesagt die Realität wird zeigen ob die Ziele erreicht werden. Wichtig ist nur vor dem Test immer die aktuelste V aus dem contrib zu ziehen. Ich mache immer weiter und schreibe nicht jede kleine Änderung hier rein.

ZitatMan hätte also leicht den SOC etwas anheben können, dann würde der Akku nicht so viel am unteren Limit hängen.
Hab ich da vielleicht etwas noch nicht richtig konfiguriert?
Wie schon geschrieben, wird nicht nur heute sondern auch der nächste Tag berücksichtigt. In deinem Debug sieht man das in den Zeilen:

2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 12861 Wh, need until maxsoc: 7127 Wh
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 5 %, Remaining days until care SoC: 24, Target: 10 %
2025.11.09 20:17:48 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: -67 %, newtarget: -67 %

Du hast das Glück viel PV Leistung zu haben.

Was du konfiguriert hast, weiß ich nicht. Auch weiß ich nicht welche Ziele mit der SoC Steuerung verfolgt werden. Im Allgemeinen wird sich im Winter der SoC immer weiter erhöhen wenn wenig PV Energie reinkommt. Aber wenn die Sonne mal rauskommt, soll die Batterie entladen sein um Energie aufzunehmen und nicht einzuspeisen oder gar abzuregeln. Deswegen wird voraus geschaut. Das ist der Sinn dieser Steuerung.
Wenn du unbedingt immer einen absoluten Wert als Bodensatz für einen evtl. Stromausfall haben willst, setzt du dir im Winterhalbjahr z.B. lowSoC=50. Dieser SoC wird dann gehalten und nur bei Stromausfall verbraucht. Aber dann hast du nur 50% für aktive Strategien.
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

Hallo Heiko,
ja, ich teste gerne die aktuelle Contrib Version und schreib die Ergebnisse hier rein.
Nur ists im Moment recht schwer viel Überschuss zu finden, der die Lade-Regelung wirklich regeln lässt. Vielleicht kommen ja bald mal wieder ein paar sonnige Tage.

Ja, ich glaube wir haben zwei ziemlich unterschiedliche Verhältnisse von PV Leistung zu Akku Kapazität, deswegen teste ich auch gerne mal aus der Sichtweise des kleinen Akkus.

Was mir im Log auffällt ist "Energy expected for charging: 12861 Wh"
Das kann garnicht sein, das wäre ja quasi ein Null-Verbrauch.
Wenn ich die SurpH Werte von morgen aufsummiere komme ich auf 4750Wh, das ist schon viel realistischer.

Mein Ziel ist es vor allem den Akku zu nutzen um möglichst wenig Energie einkaufen zu müssen.
Als zweites Ziel will ich aber auch die Lebensdauer des Akkus erhöhen und falls möglich eine Notstromreserve zu haben.

Im Sommer schütze ich den Akku nun durch langsames Laden und kurze Zeiten in denen er nahe 100% ist.

Aktuell hängt mir der Akku aber für viele Stunden bei den unteren 5% rum, manche Zellen haben niedrige Spannungen und altern dadurch schnell. Diesen ~5% Punkt habe ich heute um ca. 15:00 Uhr erreicht und komme da auch bis morgen früh um 08:30 warscheinlich nicht raus. Das sind über 17 Stunden und die will ich vermeiden.

Manuell hab ich letzten Winter bei solchen Wetterlagen im Wechselrichter eine untere SOC Grenze von 10-20% gesetzt. Damit war sehr selten eine Zelle im bedenklichen Spannungsbereich.
Meine Hoffnung ist das ich das nun mit OptimumTargetSoC automatisieren kann. Aber nach nun drei Tagen mit weniger als 50% SOC Hub ist die untere Grenze fast immer bei 5% geblieben
Z.b. an einem Tag wie heute hätte der SOC statt zwischen 5% und 40% auch zwischen 10% und 45% sein können, wenn er gestern auf 10% OptimumTargetSoC geblieben wäre.

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

DS_Starter

Dann zieh mal das aktuelle contrib. Das Log wird jetzt etwas anders aussehen:

...
2025.11.09 22:48:40.080 1: SolCast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 0 Wh, need until maxsoc: 22449 Wh
2025.11.09 22:48:40.080 1: SolCast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 10 %, Remaining days until care SoC: 19, Target: 15 %
2025.11.09 22:48:40.080 1: SolCast DEBUG> SoC Step3 Bat 01 - basics -> max SOC so that predicted PV can be stored: 100 %, newtarget: 15 %
...

Der Fokus liegt bis jetzt bei anstehender Lademöglichkeit möglichst viel Raum zu bieten und die Entladung wird dann bis lowSoC gestattet.
Wenn 5% bei dir so kritisch sind, setze doch lowSoC etwas höher, vllt. 7%.
Aber du wirst sehen, dass sich die Verhältnisse bald ändern und der SoC sich stufenweise erhöht (übrigens auch einstellbar) und wird dann zwischen maxSoC und upSoC pendeln unter der Voraussetzung genügend "wenig" (tolles Wendung) PV zu erwarten.

Für heute reichts erstmal .... Gute Nacht!

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