76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...

Wenn nur nach aufsteigendem Überschuss sortiert wird, dann kann es in der Tat bei zwei gleichen Überschüssen zu einem Problem kommen, wenn Du Dir zur Berechnung der Ladeempfehlung immer den ersten Eintrag schnappst. Wenn Du Dir aber den Eintrag mit größter (Rest-)Stundenzahl wählst, dann sollte vorgenanntes Problem nicht mehr existieren, richtig?

Ja, allerdings ist das ein unnötiger Performancefresser, weil ich immer! den Nachfolger mit dem Vorgänger vergleichen müßte.
...

Welchen Sortieralgorithmus nimmst Du denn?

[DS_Starter]

sort { $hsurp->{$a}{spswh} <=> $hsurp->{$b}{spswh} } keys %{$hsurp};   

[Parallix]

sort { $hsurp->{$a}{spswh} <=> $hsurp->{$b}{spswh} } keys %{$hsurp};   

Dann könntest Du doch die zweistellig dargestellte Stundenzahl, z.B. als Nachkommastelle, an das zu sortierende Element anhängen und könntest in einem Aufwasch diese beim Sortieren mitberücksichtigen.

[DS_Starter]

Probier ich aus. Muß man dann halt wieder auseinandersplitten.

[DS_Starter]

In meinem contrib liegt die V 1.58.2.
Die besprochene Problematik sollte gelöst sein. Die Sortierung habe ich auch erweitert.


Jetzt ist im Debug nicht mehr viel zu sehen, aber bei Surplus ist die Anzahl der noch folgenden Stunden mit diesem Überschuß angedruckt:

Code Auswählen Erweitern

2025.09.10 15:29:39.078 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 25723 Wh, Surplus: 481 Wh (0 hours), OptTargetPower: 481 W, safety: 20 %
2025.09.10 15:29:39.078 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.080 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 22, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.080 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 23, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.080 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 24, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
LG,
Heiko

[Parallix]

Ein Sache ist mir heute Abend noch (mit dem alten Code) aufgefallen: Obgleich bei mir ja loadAbort=99:686:95 ist und der nächste "care cycle" erst in einigen Tagen ansteht (Konfiguration siehe weiter oben), empfiehlt SF auch nach Erreichen eines SOC von 95 % eine nicht verschwindende Ladeleistung. Dies ist mir nur deshalb aufgefallen, weil ich zu Testzwecken derzeit keine Auswertung von Battery_ChargeAbort_XX vornehme. Sichtbar wird das ganze aber auch dadurch, dass die Ladekurve nicht asymptotisch gegen 95 % geht, sondern einen Knick hat und das natürlich leider nach Erreichen eines SOC von ungewollten 100%.

[DS_Starter]

Obgleich bei mir ja loadAbort=99:686:95 ist und der nächste "care cycle" erst in einigen Tagen ansteht (Konfiguration siehe weiter oben), empfiehlt SF auch nach Erreichen eines SOC von 95 % eine nicht verschwindende Ladeleistung.

Ja, es werden lediglich die Abbruchbedingungen geprüft und davon abhängig das Reading Battery_ChargeAbort_XX gesetzt. Was der User mit dieser Info macht, liegt in seiner Hand.
Aber abgesehen davon wäre bei loadAbort=99:686:95 der SoC 99% eine der Abbruchbdingungen und <95% wieder die Freigabe. Davon abhängig wäre Battery_ChargeAbort_XX=0|1.

[Hadl]

Man kann sich auch nur auf die Werte des einen oder des anderen Readings bei der Steuerung des Akkus stützen

Heute hatte ich damit nen Tag an dem das Akku laden basierend auf Battery_ChargeOptTargetPower_01 schief gegangen ist und ich tagsüber eingespeist habe und Abends schon zukaufen musste. Zugegeben war der Verbrauch Nachmittags ungewöhnlich hoch.

Wie man sieht wurde der Akku ab 14:30 leerer, aber die Battery_ChargeOptTargetPower_01 (lila Punkte) Leistung stieg nur leicht an.
Ab 16:00 Uhr als der Akku nur noch 60% (grüne Linie) hatte stand er auf 1000W
Von 18:00 -19:00 Uhr als der Akku nor noch ca. 20% hatte stand Battery_ChargeOptTargetPower_01 dann auf 79-105W. In der Zeit war der Hausverbrauch aber gering und ich habe den ganzen Rest (ca. 1,5kW) eingespeist. Spätestens hier hätte ich mit allem Überschuss den Akku laden müssen.

Auffällig ist, das immer als Battery_ChargeUnrestricted_01 == 0 war (nicht grau schraffiert), war die Battery_ChargeOptTargetPower_01 deutlich höher. Das macht doch mit deiner Erklärung erst recht keinen Sinn, sollten diese unabhängig voneinander sein.
Das dritte Bild zeigt das nochmal im Detail



Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

Moin,

Zugegeben war der Verbrauch Nachmittags ungewöhnlich hoch.

Das Risko besteht und auch dass Prognosen (PV oder Verbrauch) nicht so eintreffen wie vorhergesagt.

Ein genereller Aspekt ist, dass die Empfehlung in Battery_ChargeOptTargetPower_XX prognosebasiert ist. Wobei hier der Fokus auf minimaler Ladungsenergie liegt, wie es die ursprüngliche Anforderung von Parallix für diese Implementierung war. Möglicherweise gelingt es mir noch einen Bezug zu der real existierenden Situation mit einfließen zu lassen.

Die Bilder sind ja ganz nett, nützen aber nichts. Um wirklich Zusammenhänge zu erkennen braucht man einen Logauszug mit ctrlDebug=batteryManagement, am Besten gleich mit der V 1.58.2 aus dem contrib.

Vielleicht ist aber diese Art der Steuerung für dich bzw. deine Anlage auch nicht der richtige Weg und du wärst besser beraten, nur über die Battery_ChargeUnrestricted_XX in Verbindung mit plantControl->feedinPowerLimit (welches auf jeden Fall gesetzt sein sollte für alle Steuerungsvarianten) zu steuern. Ist plantControl->feedinPowerLimit bei dir gesetzt?

[Gisbert]

Hallo Heiko,

ich hätte eine kleine Bitte bei der Darstellung des Energy flow graphs im Attribut flowGraphicControl:

Code Auswählen Erweitern

shiftx    Horizontal shift of the energy flow graph.
Value: -80 ... 80, default: 0Da ich Fhem überwiegend auf dem Handy mit dem flex Style nutze, reichen diese Werte oft nicht aus, um ein schönes Ergebnis hinzubekommen. Mein Vorschlag wäre mindestens -100 ... 100 vorzugeben - oder ganz darauf zu verzichten, wie bei shifty.

Viele Grüße Gisbert

[DS_Starter]

@all,

ich habe in der V 1.58.2 im contrib noch einiges verbessert und neu hochgeladen.

@Gisbert,
schaue ich mir an.

LG,
Heiko

[DS_Starter]

@Gisbert,

ich habe die Beschränkung für shiftx herausgenommen und die V in meinem contrib upgedated.

LG,
Heiko

[Hadl]

Ein genereller Aspekt ist, dass die Empfehlung in Battery_ChargeOptTargetPower_XX prognosebasiert ist. Wobei hier der Fokus auf minimaler Ladungsenergie liegt, wie es die ursprüngliche Anforderung von Parallix für diese Implementierung war. Möglicherweise gelingt es mir noch einen Bezug zu der real existierenden Situation mit einfließen zu lassen.

Ja, hier will ich glaub ich die gleiche Strategie wie Parallix umsetzen. Aber vorranginger will ich natürlich den Akku nutzen um Netzbezug zu vermeiden.
Ich würde mir wünschen das der Battery_ChargeOptTargetPower immer wieder neu berechnet wird auf Basis des aktuellen Ladezustands und der aktuellen Prognose. So das wenn der Akku entgegen der Prognose nicht geladen wurde (hoher Verbrauch/geringe PV) die nachfolgenden Stunden eine höhere Leistung bekommen.
Dabei passt warscheinlich der prozentuale safety Zuschlag auf den Bedarf nicht, denn der wäre zum Ende bei geringer Restmenge ja auch sehr gering. Vielleicht sollte man den auf die Akku Kapazität beziehen.
Also z.B. bei 20% einen 10kW Akku so laden als müssten 12kW rein.

Die Bilder sind ja ganz nett, nützen aber nichts. Um wirklich Zusammenhänge zu erkennen braucht man einen Logauszug mit ctrlDebug=batteryManagement, am Besten gleich mit der V 1.58.2 aus dem contrib.

Ja, gerne. Ich bin aber auch ein Freund von Bildern. Damit finde ich kriegt man leichter den Überblick. Hier der debug log.

Code Auswählen Erweitern

2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step1 - basics -> Battery share factor of total capacity: 1
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step1 - basics -> Expected energy for charging raw: 62059 Wh
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step1 - basics -> Expected energy for charging after application Share factor: 62059 Wh
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step1 - compare with SoC history -> preliminary new Target: 35 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step2 - basics -> Energy expected for charging: 62059 Wh, need until maxsoc: 906 Wh
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step2 - calc care SoC -> docare: 0, care SoC: 35 %, use preliminary Target: 35 % (care SoC calculation & activation postponed to after 12.09.2025 18:01:00)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step3 - basics -> cantarget: -708 %, newtarget: -708 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step3 - charging probability -> docare: 0, Target: 35 % (new target < current Target SoC 40)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step4 - basics -> docare: 0, lowSoc: 40 %, upSoc: 60 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step4 - observe low/up limits -> Target: 40 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step5 - rounding the SoC to steps of 5 % -> Target: 40 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 SoC Step6 - force charging request: no (Battery is sufficiently charged)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeMgmt - General load termination condition: 0
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeMgmt - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeMgmt - Installed Battery capacity: 7680 Wh, Percentage of total capacity: 100.0 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeMgmt - The PV generation, consumption and surplus listed below are based on the battery's share of total installed capacity!
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR - used safety margin: 50 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/00 -> 0 (CurrSoc: 68.2 %, SoCfc: 4991 Wh, whneed: 2442, pvfc: 0, rodpvfc: 49405, confcss: 6632, SurpDay: 42773 Wh, CurrPV: 0 W, CurrCons: 298 W, Limit: 22000 W, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/01 -> 0 (SoCfc: 61.9 % / 4753 Wh, whneed: 2689, pvfc: 0, rodpvfc: 49405, confcss: 6418, SurpDay: 42987 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/02 -> 0 (SoCfc: 58.9 % / 4520 Wh, whneed: 2927, pvfc: 0, rodpvfc: 49405, confcss: 6208, SurpDay: 43197 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/03 -> 0 (SoCfc: 55.8 % / 4286 Wh, whneed: 3160, pvfc: 0, rodpvfc: 49405, confcss: 5997, SurpDay: 43408 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/04 -> 0 (SoCfc: 52.9 % / 4059 Wh, whneed: 3394, pvfc: 0, rodpvfc: 49405, confcss: 5793, SurpDay: 43612 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/05 -> 0 (SoCfc: 49.8 % / 3828 Wh, whneed: 3621, pvfc: 0, rodpvfc: 49405, confcss: 5585, SurpDay: 43820 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/06 -> 0 (SoCfc: 46.7 % / 3586 Wh, whneed: 3852, pvfc: 36, rodpvfc: 49369, confcss: 5331, SurpDay: 44038 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/07 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4094, pvfc: 586, rodpvfc: 48783, confcss: 4369, SurpDay: 44414 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/08 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 1896, rodpvfc: 46887, confcss: 3480, SurpDay: 43407 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/09 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 1256, rodpvfc: 45631, confcss: 3142, SurpDay: 42489 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/10 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 1601, rodpvfc: 44030, confcss: 2802, SurpDay: 41228 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/11 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 3638, rodpvfc: 40392, confcss: 2410, SurpDay: 37982 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/12 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 6757, rodpvfc: 33635, confcss: 1684, SurpDay: 31951 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/13 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 5097, rodpvfc: 28538, confcss: 971, SurpDay: 27567 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/14 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 8001, rodpvfc: 20537, confcss: 349, SurpDay: 20188 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/15 -> 0 (SoCfc: 41.2 % / 3168 Wh, whneed: 4512, pvfc: 7897, rodpvfc: 12640, confcss: 0, SurpDay: 12640 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/16 -> 1 (SoCfc: 64.7 % / 4968 Wh, whneed: 4512, pvfc: 5889, rodpvfc: 6751, confcss: 0, SurpDay: 6751 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/17 -> 1 (SoCfc: 88.1 % / 6768 Wh, whneed: 2712, pvfc: 4350, rodpvfc: 2401, confcss: 0, SurpDay: 2401 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/18 -> 1 (SoCfc: 100.0 % / 7680 Wh, whneed: 912, pvfc: 2249, rodpvfc: 152, confcss: 0, SurpDay: 152 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/19 -> 1 (SoCfc: 98.3 % / 7547 Wh, whneed: 0, pvfc: 152, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/20 -> 1 (SoCfc: 92.0 % / 7067 Wh, whneed: 133, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/21 -> 1 (SoCfc: 87.9 % / 6747 Wh, whneed: 613, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/22 -> 1 (SoCfc: 83.8 % / 6437 Wh, whneed: 933, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 12/23 -> 1 (SoCfc: 79.7 % / 6124 Wh, whneed: 1243, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/00 -> 0 (SoCfc: 76.5 % / 5877 Wh, whneed: 1556, pvfc: 0, roTomPV: 62059, roTomCON: 9376, SurpDay: 52683 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/01 -> 0 (SoCfc: 73.4 % / 5639 Wh, whneed: 1803, pvfc: 0, roTomPV: 62059, roTomCON: 9162, SurpDay: 52897 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/02 -> 0 (SoCfc: 70.4 % / 5406 Wh, whneed: 2041, pvfc: 0, roTomPV: 62059, roTomCON: 8952, SurpDay: 53107 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/03 -> 0 (SoCfc: 67.3 % / 5172 Wh, whneed: 2274, pvfc: 0, roTomPV: 62059, roTomCON: 8741, SurpDay: 53318 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/04 -> 0 (SoCfc: 64.4 % / 4945 Wh, whneed: 2508, pvfc: 0, roTomPV: 62059, roTomCON: 8537, SurpDay: 53522 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/05 -> 0 (SoCfc: 61.4 % / 4714 Wh, whneed: 2735, pvfc: 0, roTomPV: 62059, roTomCON: 8329, SurpDay: 53730 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/06 -> 0 (SoCfc: 57.9 % / 4445 Wh, whneed: 2966, pvfc: 12, roTomPV: 62047, roTomCON: 8075, SurpDay: 53972 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/07 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3235, pvfc: 610, roTomPV: 61437, roTomCON: 7113, SurpDay: 54324 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/08 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3626, pvfc: 1783, roTomPV: 59654, roTomCON: 6224, SurpDay: 53430 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/09 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3626, pvfc: 1639, roTomPV: 58015, roTomCON: 5886, SurpDay: 52129 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/10 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3626, pvfc: 4166, roTomPV: 53849, roTomCON: 5546, SurpDay: 48303 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/11 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3626, pvfc: 8333, roTomPV: 45516, roTomCON: 5154, SurpDay: 40362 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/12 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3626, pvfc: 11202, roTomPV: 34314, roTomCON: 4428, SurpDay: 29886 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/13 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3626, pvfc: 11563, roTomPV: 22751, roTomCON: 3715, SurpDay: 19036 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/14 -> 0 (SoCfc: 52.8 % / 4054 Wh, whneed: 3626, pvfc: 7574, roTomPV: 15177, roTomCON: 3093, SurpDay: 12084 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/15 -> 1 (SoCfc: 76.2 % / 5854 Wh, whneed: 3626, pvfc: 7636, roTomPV: 7541, roTomCON: 2689, SurpDay: 4852 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/16 -> 1 (SoCfc: 99.7 % / 7654 Wh, whneed: 1826, pvfc: 4177, roTomPV: 3364, roTomCON: 2215, SurpDay: 1149 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/17 -> 1 (SoCfc: 100.0 % / 7680 Wh, whneed: 26, pvfc: 2153, roTomPV: 1211, roTomCON: 1891, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/18 -> 1 (SoCfc: 100.0 % / 7680 Wh, whneed: 0, pvfc: 926, roTomPV: 285, roTomCON: 1553, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/19 -> 1 (SoCfc: 100.0 % / 7680 Wh, whneed: 0, pvfc: 285, roTomPV: 0, roTomCON: 1281, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/20 -> 1 (SoCfc: 93.8 % / 7200 Wh, whneed: 0, pvfc: 0, roTomPV: 0, roTomCON: 849, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/21 -> 1 (SoCfc: 89.6 % / 6880 Wh, whneed: 480, pvfc: 0, roTomPV: 0, roTomCON: 561, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/22 -> 1 (SoCfc: 85.5 % / 6570 Wh, whneed: 800, pvfc: 0, roTomPV: 0, roTomCON: 282, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 13/23 -> 1 (SoCfc: 81.5 % / 6257 Wh, whneed: 1110, pvfc: 0, roTomPV: 0, roTomCON: 0, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/00 -> 0 (SoCfc: 78.3 % / 6010 Wh, whneed: 1423, pvfc: 0, roTomPV: 47759, roTomCON: 9376, SurpDay: 38383 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/01 -> 0 (SoCfc: 75.2 % / 5772 Wh, whneed: 1670, pvfc: 0, roTomPV: 47759, roTomCON: 9162, SurpDay: 38597 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/02 -> 0 (SoCfc: 72.1 % / 5539 Wh, whneed: 1908, pvfc: 0, roTomPV: 47759, roTomCON: 8952, SurpDay: 38807 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/03 -> 0 (SoCfc: 69.1 % / 5305 Wh, whneed: 2141, pvfc: 0, roTomPV: 47759, roTomCON: 8741, SurpDay: 39018 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/04 -> 0 (SoCfc: 66.1 % / 5078 Wh, whneed: 2375, pvfc: 0, roTomPV: 47759, roTomCON: 8537, SurpDay: 39222 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/05 -> 0 (SoCfc: 63.1 % / 4847 Wh, whneed: 2602, pvfc: 0, roTomPV: 47759, roTomCON: 8329, SurpDay: 39430 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/06 -> 0 (SoCfc: 59.4 % / 4565 Wh, whneed: 2833, pvfc: 0, roTomPV: 47759, roTomCON: 8075, SurpDay: 39684 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/07 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3115, pvfc: 409, roTomPV: 47350, roTomCON: 7113, SurpDay: 40237 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/08 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 2305, roTomPV: 45045, roTomCON: 6224, SurpDay: 38821 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/09 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 4118, roTomPV: 40927, roTomCON: 5886, SurpDay: 35041 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/10 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 4021, roTomPV: 36906, roTomCON: 5546, SurpDay: 31360 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/11 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 3150, roTomPV: 33756, roTomCON: 5154, SurpDay: 28602 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/12 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 5766, roTomPV: 27990, roTomCON: 4428, SurpDay: 23562 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/13 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 3580, roTomPV: 24410, roTomCON: 3715, SurpDay: 20695 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/14 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 6882, roTomPV: 17528, roTomCON: 3093, SurpDay: 14435 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/15 -> 0 (SoCfc: 51.4 % / 3951 Wh, whneed: 3729, pvfc: 7251, roTomPV: 10277, roTomCON: 2689, SurpDay: 7588 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/16 -> 1 (SoCfc: 74.9 % / 5751 Wh, whneed: 3729, pvfc: 5505, roTomPV: 4772, roTomCON: 2215, SurpDay: 2557 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/17 -> 1 (SoCfc: 98.3 % / 7551 Wh, whneed: 1929, pvfc: 3634, roTomPV: 1138, roTomCON: 1891, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/18 -> 1 (SoCfc: 100.0 % / 7680 Wh, whneed: 129, pvfc: 1042, roTomPV: 96, roTomCON: 1553, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/19 -> 1 (SoCfc: 97.4 % / 7484 Wh, whneed: 0, pvfc: 96, roTomPV: 0, roTomCON: 1281, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/20 -> 1 (SoCfc: 91.2 % / 7004 Wh, whneed: 196, pvfc: 0, roTomPV: 0, roTomCON: 849, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/21 -> 1 (SoCfc: 87.0 % / 6684 Wh, whneed: 676, pvfc: 0, roTomPV: 0, roTomCON: 561, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/22 -> 1 (SoCfc: 83.0 % / 6374 Wh, whneed: 996, pvfc: 0, roTomPV: 0, roTomCON: 282, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeUR 14/23 -> 1 (SoCfc: 78.9 % / 6061 Wh, whneed: 1306, pvfc: 0, roTomPV: 0, roTomCON: 0, SurpDay: 0 Wh, inTime: 1)
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> ChargeOTP - The limit for grid feed-in is: 18800 W
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> ChargeOTP - NOTE: The hours printed below are the estimated number of hours on the current day with at least the respective PV surplus.
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 01, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 02, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 03, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 04, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 05, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 06, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 07, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 08, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 09, Start SoC: 3168 Wh, Surplus: 1007 Wh (9 hours), OptTargetPower: 602 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 10, Start SoC: 3168 Wh, Surplus: 918 Wh (10 hours), OptTargetPower: 541 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 11, Start SoC: 3709 Wh, Surplus: 1261 Wh (8 hours), OptTargetPower: 596 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 12, Start SoC: 4305 Wh, Surplus: 2000 Wh (6 hours), OptTargetPower: 675 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 13, Start SoC: 4980 Wh, Surplus: 2000 Wh (5 hours), OptTargetPower: 648 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 14, Start SoC: 5628 Wh, Surplus: 2000 Wh (4 hours), OptTargetPower: 616 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 15, Start SoC: 6244 Wh, Surplus: 2000 Wh (3 hours), OptTargetPower: 574 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 6818 Wh, Surplus: 2000 Wh (2 hours), OptTargetPower: 517 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 7335 Wh, Surplus: 2000 Wh (1 hours), OptTargetPower: 414 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: 7680 Wh, Surplus: 2000 Wh (1 hours), OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: 7680 Wh, Surplus: 1911 Wh (7 hours), OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 22, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 23, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %
2025.09.12 00:07:19 1: PV_SolarForecast DEBUG> Bat 01 ChargeOTP - hod: 24, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 500 W, safety: 20 %


Vielleicht ist aber diese Art der Steuerung für dich bzw. deine Anlage auch nicht der richtige Weg und du wärst besser beraten, nur über die Battery_ChargeUnrestricted_XX in Verbindung mit plantControl->feedinPowerLimit (welches auf jeden Fall gesetzt sein sollte für alle Steuerungsvarianten) zu steuern. Ist plantControl->feedinPowerLimit bei dir gesetzt?

Ja, das ist bei mir gesetzt und damit funktioniert es prinzibiell auch. Aber als Ergebniss wird immer irgendwann am Nachmittag bei noch hoher PV Leistung das Laden freigegeben und ich lade den Akku in Maximaler Geschwindigkeit. Den Akku will ich zwecks Lebensdauer, so wie Parallix, nicht so viel Stress aussetzen und lieber langsam laden.

Ich hab mir nun die Grobstrategie von OptTargetPower nochmals durchgelesen. Damit sollte doch die Ladeleistung gleichmäßig über alle verfügbaren Stunden mit genügend Überschuss verteilt werden.

Warum sehe ich dann so unterschiedliche Werte wie hier? OptTargetPower ist immer deutlich niedriger wenn ChargeUnrestricted gesetzt ist!?!

Das dritte Bild zeigt das nochmal im Detail

Wann wird denn OptTargetPower bestimmt? Nur einmal am Tag, oder bei jeder Berechnung wieder neu?

OptTargetPower sollte bei jeder Berechnung wieder neu bestimmt werden, so das nach aktuellen Akku Ladezustand und der Rest-Tagesprognose der Akku noch voll (inkl safety) werden kann. Falls nichtmehr möglich sollte auf pinmax gestellt werden. Damit wird er zwar am Ende des Tages immer auf pinmax stehen, da ja die safety Energie nicht reinpasst, aber da sollter er auch schon voll sein und somit eh keine Ladung mehr erfolgen.

[300P]

Ja, das ist bei mir gesetzt und damit funktioniert es prinzibiell auch. Aber als Ergebniss wird immer irgendwann am Nachmittag bei noch hoher PV Leistung das Laden freigegeben und ich lade den Akku in Maximaler Geschwindigkeit. Den Akku will ich zwecks Lebensdauer, so wie Parallix, nicht so viel Stress aussetzen und lieber langsam laden.

...deshalb habe ich die Max-Leistung für Ladung und Entladung im BWR zusätzlich unterhalb der Möglichkeiten de Batterie vorgegeben und bereits beim Kauf der BWR kleinere BWR gewählt als bei den Batterien möglich gewesen wären.. 
Die eine Batterie könnte 5 kW - die andere könnte Batterie 7 kW  Dauerleistung vertragen.
Das ist durch die Wahl der BWR bereits reduziert und zusätzlich im BWR dann auf max 2.5 kW Wirkleistung in beide Richtungen bei mir begrenzt.

[Parallix]

Hallo zusammen,

die von Heiko implementierte Empfehlung zur optimalen Ladung funktioniert (bei mir) sehr gut. Noch nicht ganz glücklich bin ich aber mit der noch nicht ganz optimalen Verteilung der Ladeenergie über den Tag, die im bisherigen Schema ja nahezu gleich erfolgt, was grundsätzlich ja auch gut ist.  Konkret sehe ich folgende wünschenswerte funktionale Anforderungen (werden noch erweitert), die noch nicht alle ganz optimal erfüllt werden:

• Die (Haus-)Speicher sollen schonend geladen werden.
• Das Standby-Management von Speichern soll unterstützt werden.
• Das Standby-Management von Wechselrichtern soll unterstützt werden.
• Unnötige Zyklen des (Haus-)Speichers sollen vermieden werden.
• Die Planung und Optimierung der Ladung von EV-Batterien soll im Gesamtkonzept enthalten sein.
• Der SOC=SOC_Max_CareCycle:=100% soll im Falle eines "care cycles" spätestmöglich angenommen werden.
• Täglich soll spätestmöglich ein SOC=SOC_Max_Daily in der Nähe eines SOC-Ziels erreicht werden.
• Die Annäherung an jeden Ziel-SOC < SOC_Max_Daily soll mit reduzierter Leistung erfolgen.
• Die Annäherung an den Ziel-SOC = SOC_Max_CareCycle soll mit reduzierter Leistung erfolgen, die kurz vor Erreichen von SOC_Max_CareCycle aber nicht kleiner als die Ladeschlussleistung sein darf.
• Die Ladung soll so erfolgen, dass der obere SOC_Max_Daily bzw. SOC_Max_CareCycle auch mit hoher Wahrscheinlichkeit erreicht wird.
• Der Ausfall eines Dienstes zur Bereitstellung solarer Strahlungsdaten soll kompensiert werden.

Motivation zu 1. Die (Haus-)Speicher soll schonend geladen werden:

Eine schonenden Ladung führt zu einem reduzierten Stress der im Speicher verbauten Zellen. Somit trägt sie dazu bei, den Speicher über einen möglichst langen Zeitraum ohne unnötige Kapazitätsverluste nutzen zu können.

Motivation zu 2. Das Standby-Management von Speichern soll unterstützt werden:

Die Entladung eines Speichers mit sehr geringer Entladeleistung ist o.B.d.A. ineffizient. Durch ein Standby-Management von Speichern kann die Effizienz einer Anlage ggf. gesteigert werden. Wenn mehrere unabhängige Speicher vorliegen, ist dies auch ohne Verlust der Versorgungssicherheit möglich und bewirkt überdies eine effizientere Nutzung der gespeicherten Energie.

Motivation zu 3. Das Standby-Management von Wechselrichtern soll unterstützt werden:

Der Betrieb eines Wechselrichters ist ineffizient, wenn dieser komplett oder überwiegend durch eine Leistungszuführung aus dem Netz erfolgt. Durch ein Standby-Management von Wechselrichters kann die Effizienz einer Anlage ggf. gesteigert werden.

Motivation zu 4. Unnötige Zyklen des (Haus-)Speichers sollen vermieden werden:

Jedem Zyklus eines Speichers führt zu einer Degeneration und reduziert somit die zu erwartende Lebensdauer. Insofern gilt es, unnötige Zyklen zu vermeiden. Sie entstehen immer dann vor, wenn über das Netz Energie in den (Haus-) Speicher verbracht wird und direkt im Anschluss daran wieder abfließt.

Bsp.: Am Abend oder in der Nacht wird ein (Haus-)Speicher durch eine Last, z.B. eine Wärmepumpe oder ein EV, so weit entladen wird, dass eine (Not-)Ladung aus dem Netz erforderlich wird. Da die Last eingeschaltet bleibt, wiederholt sich der Vorgang der lastbedingten Entladung und (Not-)Ladung des (Haus-)Speichers aus dem Netz mehrfach und die vielen Teilzyklen addieren sich zu einem vermeidbaren Gesamtzyklus.

Motivation zu 5. Die Planung und Optimierung der Ladung von EV-Batterien soll im Gesamtkonzept enthalten sein:

Auch bei EV-Batterien führt eine schonende Ladung zu den beim Haus-Speicher beschriebenen positiven Auswirkungen. Anders, als beim Hausspeicher ist die Leistung, mit der EV-Batterien geladen werden können, nicht nur nach oben, sondern (leider) auch nach unten hin begrenzt. Die untere Grenze ist zumeist durch einen minimal erforderlichen Ladestrom von 6 A vorgeben. Bei einer typischerweise vorliegenden Ladespannung von 230 V ergibt sich an einer 11 kW-Wallbox bei einphasiger (1P) Laden ein Ladeleistungsbereich von [1380, 3680] W und bei dreiphasigem (3P) Laden ein Ladeleistungsbereich von [4140, 11040] W.

Wenngleich häufig der Wunsch besteht, ein EV nur bei Überschuss zu laden, wird dies z.B. in folgenden Fällen nicht möglich sein:
a) Das EV steht in der Woche nur abends zur Ladung an der eigenen Wallbox.
b) Das EV soll aufgrund einer längeren Fahrt auf einen höheren, als den jahreszeitlich üblichen SOC gebracht werden.
c) Der Überschuss reicht jahreszeitlich oder durch das aktuelle Wetter nicht aus, um das EV auf einen gewünschten Ziel-SOC zu bringen.
d) Aufgrund einer starken Fluktuation der solaren Einstrahlung (z.B. bei Wolken auf einem ansonsten blauen Himmel) ist eine durchgängige Ladung auf Überschussbasis nicht möglich.

Während es nur in einigen der o.g. Fälle sinnvoll sein wird, dass EV unter Verwendung der im Hausspeicher gespeicherten Energie zu laden. liegt bei dem unter d) genannte Fall eine andere Situation vor. Wird nämlich die Ladung eines EV immer wieder abgebrochen, so führt dies zu Stresssituation der Ladehardware, z.B. im Form von einer hoch frequentierten Schaltens von Relais resp. Schützen. Um eine derartige Stresssituation zu vermeiden, wird man das EV also für eine gewisse Zeit aus dem Hausspeicher laden, wenn der Ladevorgang zuvor auf Basis eines solare Überschusses gestartet wurde und in näherer Zukunft auch wieder mit Überschuss zu rechnen ist.

Motivation zu 6. Der SOC=SOC_Max_CareCycle:=100% soll im Falle eines "care cycles" spätestmöglich angenommen werden:

Ein möglichst spätes Erreichen eines SOC von 100 % führt mit hoher Wahrscheinlichkeit dazu, dass einzelnen Zellen des Speichers, die sich bei Erreichen eines SOC von 100 % weit oberhalb Ihrer Nennspannung befinden, wieder auf eine unproblematische Spannung gebracht werden. Dies trägt sie dazu bei, den Speicher über einen möglichst langen Zeitraum ohne unnötige Kapazitätsverluste nutzen zu können.

Motivation zu 7. Täglich soll spätestmöglich ein SOC=SOC_Max_Daily in der Nähe eines SOC-Ziels erreicht werden:

Jedes unnötig lange Verweilen auf einem hohen SOC < 100 führt zu einem unnötigen Stress, der letztlich dessen Nutzungsdauer des Speichers reduziert. Durch das möglichst späte Erreichen des Ziel-SOC wird diesem unnötigen Stress entgegengewirkt. Darüber hinaus steht bis dahin mehr Überschussleistung zur Verfügung, die sinnvoll zur Aktivierung überschussbetriebener Geräte genutzt werden kann und die Wahrscheinlichkeit eines Netzbezugs aufgrund von Regelungslatenzen reduziert.

Motivation zu 8. Die Annäherung an jeden Ziel-SOC < SOC_Max_Daily soll mit reduzierter Leistung erfolgen:

Wird gegen Ende der Ladung eines Speichers die Ladeleistung nicht reduziert, so wird ein SOC < SOC_CareCycle_Max häufig zu hoch geschätzt. In der Folge ist im Speicher weniger Energie gespeichert, als der SOC annehmen lässt. Die Reduktion der Ladeleistung zum Ende einer Ladung kann dazu beitragen, die SOC-Schätzung besser vornehmen zu können.

Motivation zu 9. Die Annäherung an den Ziel-SOC = SOC_Max_CareCycle soll mit reduzierter Leistung erfolgen, die kurz vor Erreichen von SOC_Max_CareCycle aber nicht kleiner als die Ladeschlussleistung sein darf:

Die Motivation entspricht der vorherigen. Hinzu kommt, dass kurz vor Ladeschluss (beim Ladeschluss bei SOC=100 ist dies typischerweise ab einem SOC von 99% der Fall) die Ladeleistung nicht geringer als eine vom Hersteller vorgegebene Ladeschlussleistung sein darf, da andernfalls der Speicher unnötig lange einem erhöhten Stress ausgesetzt wird.

Motivation zu 10. Die Ladung soll so erfolgen, dass der obere SOC_Max_Daily bzw. SOC_Max_CareCycle auch mit hoher Wahrscheinlichkeit erreicht wird:

Abgesehen von dem SOC = 100 %, der eigentlich nur für die Kalibrierung dieses SOCs erforderlich ist, dient jeder sinnvoll eingestellte Ziel-SOC < 100 % dazu, den Speicher so einzusetzen, dass höchstens nur noch ein marginaler Netzbezug erfolgt.  Des Weiteren stellt er aber auch die Versorgungssicherheit mit elektrischer Leistung während eines Zeitraums sicher, wenn die Anlage not- oder gar ersatzstromfähig ist. Um beide Aspekte (geringer Netzbezug, hohe Versorgungssicherheit) zu berücksichtigen, gilt es die jeweiligen oberen SOCs täglich auch zu erreichen.

Motivation zu 11. Der Ausfall eines Dienstes zur Bereitstellung solarer Strahlungsdaten soll kompensiert werden:

Für den bestimmungsgemäßen Betrieb von SF werden externe Dienste genutzt, die Prognosen für solare Strahlungsdaten liefern. Ein Ausfall eines solchen Dienstes soll keine signifikanten Auswirkungen auf die Funktion von SF haben.

Meinerseits werde ich (durch weitere Edits)  heute und am Wochenende noch an dieser Stelle erläutern bzw. darlegen, wie o.g. Ziele, die sich teilweise gegensätzlich sind (Zielkonflikt), erreicht werden können, warum sie in SF behandelt werden sollten und bitte bis dahin noch um ein wenig Geduld.