76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Habe es grad bei mir probiert, bekomme auch nur den default in das Reading. Schaue ich mir an, komisch ...

[DS_Starter]

Ja, das Problem sitzt vor dem Bildschirm 

Natürlich ist der Index falsch, so ist es richtig:

Code Auswählen Erweitern

{
  # Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
  ::batSocChargeMgmnt ($name,'BYD_Battery');

  # Anlegen des Readings "Ladestrategie" und füllen mit dem gesetzten Wert
  my $wert = NexthoursVal ($name, "NextHour00", "strategybat01", "loadRelease");
  storeReading ("Ladestrategie", $wert);
}

Ändere ich auch im Wiki.

[Hadl]

Ich habe eine Variante in opt/smartPower eingebaut, die funktionieren könnte um zur aktuellen Stunde eine Zeitgewichtung zu realisieren ohne dass je mehr sich die aktuelle Stunde dem Ende neigt der Überschuß gegen 0 geht und somit die Leistungsgrenze sprunghaft gegen unendlich (pinmax) läuft.

Ich habs bei mir eingespielt und werde heute mal schaun wie's läuft.
Beim drübersehen ist mir aber aufgefallen, das die Gewichtung bei "$total" meiner Ansicht nach noch fehlt. Hier wird die laufende Stunde voll mit in die Summe gerechnet.

Code Auswählen Erweitern

      my @remaining_hods = grep { int $_ >= int $hod } @sortedhods;
      my $total          = 0;                                               
      $total            += $hsurp->{$_}{surplswh} for @remaining_hods;                                           # Gesamtkapazität aller Stunden mit PV-Überschuß ermitteln
damit würde achievable weiterhin am Ende der Stunde zu optimistisch sein

Code Auswählen Erweitern

          if ($runwhneed > 0 && $total * $befficiency < $runwhneed) {                                            # Erreichbarkeit des Ziels (benötigte Ladeenergie total) prüfen
              $achievable = 0;                                                     
          }

Wäre es generell nicht vorteilhaft für eine gleichmäßige Ladeleistung wenn man die Ladeleistung nicht anhand der Werte der aktuellen Stunde berechnen würde ($spls), sondern anhand des Resttages?
Also die Schleife von der schwächsten zur stärksten Überschuss-Stunde immer wieder neu berechnen, und sobald man nurnoch Stunden hat die den mittleren Restbedarf decken können wird dieser Wert als neue Leistung genutzt. Auch auf die Gefahr hin das die aktuelle Stunde das vielleicht garnicht liefern kann, aber die Leistung ist ja eh ein max-Wert.

Stunde0 ist aktuelle Stunde, Stunde1 die nächste usw.

Also wenn ich im Akku noch 5 kWh brauche, und folgende Stunden mit Überschuss habe:

Code Auswählen Erweitern

Stunde0: 0.4 kWh, aber es ist schon 15 Minuten vor Stundenende (0.1kWh Rest-Erwartung)
Stunde1: 10  kWh
Stunde2: 5  kWh
Stunde3: 1  kWh
Stunde4: 0.5 kWhDann würde die Schleife folgendes machen startend bei einem Bedarf von 5 kWh

Code Auswählen Erweitern

Stunde0: 0.1 kWh => Rest 4,9 kWh in 4,25 Stunden => 1,15 kW Bedarf im Schnitt (limit 0,1kWh)
Stunde4: 0.5 kWh => Rest 4,4 kWh in 4,25 Stunden => 1,04 kW Bedarf im Schnitt (limit 0,5kWh)
Stunde3: 1  kWh => Rest 3,9 kWh in 3,25 Stunden => 1,20 kW Bedarf im Schnitt (limit 1  kWh)
Stunde2: 5  kWh => Rest 2,9 kWh in 2,25 Stunden => 1,29 kW Bedarf im Schnitt
Stunde1: 10  kWh => Rest 1,61kWh in 1,25 Stunden => 1,29 kW Bedarf im Schnitt
Aktuelle Stunde => Rest 0,32kWh in 0,25 Stunden => OTP 1,29kW => aktuell zu setzen auch wenn nicht zu erwartenDamit würde man für dem aktuellen Zeitpunkt eher den maximalen Wert anfordern den man voraussichtlich an diesem Tag noch zum laden braucht. Wenns besser läuft als gedacht würde er sogar im Laufe des Tages sinken.

Das ganze dann natürlich noch mit den Safety Margin und den achievable-Aufschlägen zu garnieren.

Wenn ich das richtig gesehen habe ist die Strategie eh schon sehr ähnlich, nur die aktuelle Stunde wird anders behandelt. Was hältst du davon?

Viele Grüße

Christian

[DS_Starter]

Hallo Christian,

Beim drübersehen ist mir aber aufgefallen, das die Gewichtung bei "$total" meiner Ansicht nach noch fehlt. Hier wird die laufende Stunde voll mit in die Summe gerechnet.
Code Auswählen
      my @remaining_hods = grep { int $_ >= int $hod } @sortedhods;
      my $total          = 0;                                             
      $total            += $hsurp->{$_}{surplswh} for @remaining_hods;                                          # Gesamtkapazität aller Stunden mit PV-Überschuß ermitteln
damit würde achievable weiterhin am Ende der Stunde zu optimistisch sein

Dabei hast du übersehen, dass in  @sortedhods bzw. $hsurp->{XX}{surplswh} bereits der zeitgewichtete PV-Überschuß der aktuellen Stunde enthalten ist. Das wird in einem Codeblock vorher gemacht.

Wäre es generell nicht vorteilhaft für eine gleichmäßige Ladeleistung wenn man die Ladeleistung nicht anhand der Werte der aktuellen Stunde berechnen würde ($spls), sondern anhand des Resttages?
Also die Schleife von der schwächsten zur stärksten Überschuss-Stunde immer wieder neu berechnen, und sobald man nurnoch Stunden hat die den mittleren Restbedarf decken können wird dieser Wert als neue Leistung genutzt.

So ist es und das ist bereits seit langem implementiert. Diese Aufgabe übernimmt die Iterations-Sub ___batFindMinPhWh.

Die Stunde 00 (aktuelle Stunde) erhält dann noch eine Nachbehandlung mit allen möglichen bisher eingebrachten Anforderungen und Wünschen.
Danke fürs mitdenken. 

LG,
Heiko

[DS_Starter]

Die Einstellung der aktuellen Testversion hat sich für optPower als zu aggressiv erwiesen. Aus dem Grund wurde optPower wieder auf den vorherigen Code zurückgesetzt. Dafür hat smartPower als agressivere Variante diesen Code übernommen. Die eingebaute Zeitgewichtung ist geblieben.
Dadurch ist optPower für User mit dem Ziel moderaterer Ladeleistungen gegenüber smartPower wieder besser geeignet.

Contrib ist upgedatet. 

[DS_Starter]

In der Consumer-Steuerung kann man nun auch den PV-Anteil mit dem Schlüssel pvshare von 0..100% festlegen.
Mit dem Schlüssel pvshare kann somit der gewünschte prozentuale PV-Anteil zur Deckung der Leistungsaufnahme festgelegt werden.

pvshare    
  Legt den PV-Anteil der Verbraucherleistung (Schlüssel 'power') fest, der als ausreichend für den Verbraucher gewertet wird. (optional)
  Die Einstellung 100% definiert einen benötigten PV-Überschuß von mindestens 'power'. Mit 0% benötigt der Verbraucher keinen PV-Überschuß.
  Wert: 0..100, default: 100 (%)

Dadurch kann man nun auch Verbraucher mit PV-Anteilen steuern deren Leistungsaufnahme größer als der maximal mögliche PV-Überschuß der Anlage ist.

Update liegt im contrib.

[DS_Starter]

Hallo zusammen,

die Version 1.59.6 im Contrib beinhaltet inzwischen einige Weiterentwicklungen und Anpassungen.
Hier eine Zusammenstellung für die bessere Übersicht:

- im Nutzer eigenen Grafikbereich (Graphic Header Own Specification):
            die Feldbreite von Textfeldern ist einstellbar (default: 10),
            Anzeige/Änderung von Schlüsselwerten zusammengesetzter Attribute,
            Bugfix bei Erstellung eines leeren Feldes mit ':'

- Commandref angepasst

- weitere Optimierungen der Batteriesteuerung optPower/smartPower wie z.B. eine zeitgewichtete Überschußbewertung der aktuellen Stunden

- neuer Schlüssel 'pvshare' in Consumerattributen zur Festlegung eines PV-Anteils an der Leistungsaufnahme

- interne Codeoptimierungen   

[DS_Starter]

Ich habe in unserem Haushalt die Autarkiequote seit dem 01.01. diesen Jahres berechnet und komme auf 89%.
Dieser Wert wird sich Richtung Jahresende wieder etwas negativer entwickeln, jedoch kann ich damit sicherlich sehr zufrieden sein. Die eingesetzte SOC/Batteriesteuerung hat daran vermutlich einen nicht unerheblichen Anteil. Mal schauen welcher Wert am Jahresende steht... 

[grappa24]

sehr gut, komme seit 01.01.25 "nur" auf 85% Autarkie (76% in 2024)

[DS_Starter]

Ein weiteres Feature für den User-Bereich der Grafik ist eingebaut. Die Feldbreite von Texteingabefeldern kann nun dort definiert werden. Die Syntax für diesen Bereich ist übersichtlich in einer Tabelle in der Hilfe zusammengestellt:

Code Auswählen Erweitern

.inputSize=<Ganzzahl>   legt die Breite von Texteingabefeldern fest (default: 10)
&nbsp;                  fügt ein Leerzeichen im Label ein
<br>                    fügt einen Zeilenumbruch im Label ein
#<Text>                 definiert einen Zeilentitel
#                       erzeugt einen leeren Zeilentitel
<Label>:<Wert>          Erstellt das anzuzeigende <Label>:<Wert> Paar.
                        <Wert> kann ein Attribut, Reading, oder Set-Kommando sein.
<Label>:<Wert>@<Device> der Wert eines anderen <Device> wird angezeigt
<Label>:<Attr>-><Key>   der Schlüsselwert eines kombinierten Attributes (z.B. flowGraphicControl) wird angezeigt
:                       erzeugt ein Leerfeld


Contrib ist upgedated.

[Hadl]

Ich hab die Version aus 30436 heute laufen lassen.
Die Unterschiede innerhalb einer Stunde haben nun einen etwas anderen Verlauf, aber die wechselnden Ladeleistungen bei ausreichend Überschuss sind trotzdem noch vorhanden. Vor allem zwischen 14 und 16 Uhr erkennt man das gut.
Du darfst diesen Dateianhang nicht ansehen.
Der Bereich des Sprungs hat sich nun auf ca. 10 Minuten verbreitert.

Code Auswählen Erweitern

2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ######################### Start Battery Management DebugLog #########################
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging raw: 33397 Wh
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging after application Share factor: 33397 Wh
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 35 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 33397 Wh, need until maxsoc: 3279 Wh
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 1, care SoC: 40 %, Remaining days until care SoC: 24, Target: 40 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> cantarget: -335 %, newtarget: -335 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 1, Target: 40 % (no change)
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 1, lowSoc: 40 %, upSoc: 60 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 40 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 40 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - General load termination condition: 0
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 87 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - charging target: 100 % / 7680 Wh
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.10.25 14:00:04 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.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - used safety margin: 50 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/14 - lr: 1, CurrSoc: 57.3 %, SoCfc: 7011 Wh, whneed: 3279, pvfc: 5388, rodpvfc: 4014, confcss: 879, SurpDay: 3135 Wh, CurrPV: 6007 W, CurrCons: 1399 W, Limit: 22000 W, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/15 - lr: 0, SoCfc: 91.3 % / 7011 Wh, whneed: 669, pvfc: 2334, rodpvfc: 1680, confcss: 281, SurpDay: 1399 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/16 - lr: 1, SoCfc: 100.0 % / 7680 Wh, whneed: 669, pvfc: 1499, rodpvfc: 181, confcss: 0, SurpDay: 181 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/17 - lr: 1, SoCfc: 96.8 % / 7437 Wh, whneed: 0, pvfc: 181, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/18 - lr: 1, SoCfc: 90.0 % / 6913 Wh, whneed: 243, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/19 - lr: 1, SoCfc: 84.2 % / 6470 Wh, whneed: 767, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/20 - lr: 1, SoCfc: 79.0 % / 6068 Wh, whneed: 1210, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/21 - lr: 1, SoCfc: 73.1 % / 5614 Wh, whneed: 1612, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/22 - lr: 1, SoCfc: 68.0 % / 5222 Wh, whneed: 2066, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeLR Bat 01 25/23 - lr: 1, SoCfc: 63.6 % / 4884 Wh, whneed: 2458, pvfc: 0, rodpvfc: 0, confcss: 0, SurpDay: 0 Wh, inTime: 1
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP - The limit for grid feed-in is 18800 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - weighted self-consumption: 0 %
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 3279 Wh -> target likely achievable? yes
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/14 - hod: 15 / 00, lr/lc: 1/1, SoC S/E: 4401 / 7680 Wh, Surplus: 4306 Wh, OTP: 1887 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/15 - hod: 16 / 01, lr/lc: 0/1, SoC S/E: 7680 / 7680 Wh, Surplus: 1736 Wh, OTP: 3000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/16 - hod: 17 / 02, lr/lc: 0/1, SoC S/E: 7680 / 7680 Wh, Surplus: 997 Wh, OTP: 3000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/17 - hod: 18 / 03, lr/lc: 0/1, SoC S/E: 7680 / 7437 Wh, Surplus: 0 Wh, OTP: 0 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/18 - hod: 19 / 04, lr/lc: 1/1, SoC S/E: 7437 / 6913 Wh, Surplus: 0 Wh, OTP: 3000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/19 - hod: 20 / 05, lr/lc: 1/1, SoC S/E: 6913 / 6470 Wh, Surplus: 0 Wh, OTP: 3000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/20 - hod: 21 / 06, lr/lc: 1/1, SoC S/E: 6470 / 6068 Wh, Surplus: 0 Wh, OTP: 3000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/21 - hod: 22 / 07, lr/lc: 1/1, SoC S/E: 6068 / 5614 Wh, Surplus: 0 Wh, OTP: 3000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/22 - hod: 23 / 08, lr/lc: 1/1, SoC S/E: 5614 / 5222 Wh, Surplus: 0 Wh, OTP: 3000 W
2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/23 - hod: 24 / 09, lr/lc: 1/1, SoC S/E: 5222 / 4884 Wh, Surplus: 0 Wh, OTP: 3000 WHier nochmal der Bereich von 14-15 Uhr in der Übersicht. Die OTP Ladeleistung variiert um über 30%

Code Auswählen Erweitern

2025.10.25 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/14 - hod: 15 / 00, lr/lc: 1/1, SoC S/E: 4401 / 7680 Wh, Surplus: 4306 Wh, OTP: 1887 W (remaining: 3279 Wh)
2025.10.25 14:51:47 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/14 - hod: 15 / 00, lr/lc: 1/1, SoC S/E: 5645 / 6270 Wh, Surplus: 718 Wh, OTP: 1122 W (remaining: 2035 Wh)
2025.10.25 15:00:05 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/15 - hod: 16 / 00, lr/lc: 1/1, SoC S/E: 5837 / 7347 Wh, Surplus: 1736 Wh, OTP: 1524 W (remaining: 1843 Wh)
So wirklich verstehe ich nicht, warum die Leistung von 1887 W auf 1122 W innerhalb der Stunde sinkt und dann auf 1524 W am Stundenwechsel wieder hochgeht, wenn doch konstant Überschuss vorhanden ist.

Wenn ich mir die Surplus Werte anschaue kann irgendwas nicht stimmen.
Um 14:00 habe ich bei der LR Strategie für den Rest des Tages ein SurpDay: 3135 Wh aber in OTP für diese Stunde alleine einen Surplus: 4306 Wh
Der Überschuss der aktuellen Stunde kann ja nicht größer sein, als der des Resttages.

Meine Berechnung für 14:00 würde erwarten: Bedarf 3279 Wh auf 3 Stunden aufgeteilt sind 1093 W
Stunde2: Bedarf 3279 Wh in 3 Stunden. Surplus: 997 Wh => 997W Laden + 20% Margin = 1196 W
Stunde1: Bedarf 2282 Wh in 2 Stunden. Surplus: 1736 => 1141W Laden  + 20% Margin = 1369 W
Stunde0: Bedarf 1141 Wh in 1 Stunden. Surplus: 4306 => 1141W Laden + 20% Margin =  1369 W

Ich würde also für 14:00 einen OTP von konstant 1369 W erwarten. evtl etwas fallend da der SOC ja durch den Margin um 20% schneller steigt als benötigt.

Wo ist mein Denkfehler, was führt zu den OTP Leistungen zwischen 1887W und 1122W innerhalb der Stunde wo alles nach Plan läuft.

VG Hadl

[300P]

Ich habe in unserem Haushalt die Autarkiequote seit dem 01.01. diesen Jahres berechnet und komme auf 89%.
Dieser Wert wird sich Richtung Jahresende wieder etwas negativer entwickeln, jedoch kann ich damit sicherlich sehr zufrieden sein. Die eingesetzte SOC/Batteriesteuerung hat daran vermutlich einen nicht unerheblichen Anteil. Mal schauen welcher Wert am Jahresende steht... 

2024 =>  Autarkie 94 % Eigenverbrauch 74 % (->>> ohne WP)
2025 =>  nur noch 86 % Eigenverbrauch 82 % (mit WP)

siehe Screenshot:
   

[DS_Starter]

@Hadl,

ich kann sicherlich nicht alle Fragen umfassend beantworten, dafür ist die Komplexität zu hoch.
Einiges kann ich erläutern.

Wenn ich mir die Surplus Werte anschaue kann irgendwas nicht stimmen.
Um 14:00 habe ich bei der LR Strategie für den Rest des Tages ein SurpDay: 3135 Wh aber in OTP für diese Stunde alleine einen Surplus: 4306 Wh
Der Überschuss der aktuellen Stunde kann ja nicht größer sein, als der des Resttages.

Bei dem Debug der LR Strategie ist das Surplus des Resttages die Angabe nach Prognosefortschreibung am Ende der relevanten Stunde ausgedruckt. Bei den anderen Strategien ist es der Überschuß zu Beginn der Stunde.
Ich sehe ein, dass es zu Verwirrungen führt. Deswegen wird das Debuglog zukünftig nur noch die Angaben für die gewählte Strategie ausgeben und nicht mehr alles. Das sieht dann so aus:

Code Auswählen Erweitern

2025.10.26 10:06:57.416 1: SolCast DEBUG> ChargeMgmt - Inverter 'STP_5000' cap: 5000 W, Power limit: 100 % -> Pmax eff: 5000 W
2025.10.26 10:06:57.417 1: SolCast DEBUG> ChargeMgmt - Inverter 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common' cap: 2080 W, Power limit: 100 % -> Pmax eff: 2080 W
2025.10.26 10:06:57.417 1: SolCast DEBUG> ChargeMgmt - Inverter 'MQTT2_cerboGX_c0619ab34e08_vebus' cap: 7200 W, Power limit: 100 % -> Pmax eff: 7200 W
2025.10.26 10:06:57.417 1: SolCast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 14280 W
2025.10.26 10:06:57.418 1: SolCast DEBUG> ChargeMgmt - The limit for grid feed-in is: 4800 W
2025.10.26 10:06:57.418 1: SolCast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2025.10.26 10:06:57.418 1: SolCast DEBUG> ChargeMgmt Bat 01 - General load termination condition: 0
2025.10.26 10:06:57.419 1: SolCast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.10.26 10:06:57.419 1: SolCast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 95 %
2025.10.26 10:06:57.419 1: SolCast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2025.10.26 10:06:57.420 1: SolCast DEBUG> ChargeMgmt Bat 01 - charging target: 100 % / 28416 Wh
2025.10.26 10:06:57.420 1: SolCast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.10.26 10:06:57.420 1: SolCast 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.10.26 10:06:57.426 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.10.26 10:06:57.426 1: SolCast DEBUG> ChargeOTP Bat 01 - charging target: 28416 Wh, remaining: 16765 Wh -> target likely achievable? no
2025.10.26 10:06:57.426 1: SolCast DEBUG> ChargeOTP Bat 01 26/10 - hod: 11/00, lr/lc: 1/1, SoC S/E: 11651/11915 Wh, Surp h/d: 278/0 Wh, OTP: 5040 W
2025.10.26 10:06:57.427 1: SolCast DEBUG> ChargeOTP Bat 01 26/11 - hod: 12/01, lr/lc: 1/1, SoC S/E: 11915/11289 Wh, Surp h/d: 0/0 Wh, OTP: 5040 W
2025.10.26 10:06:57.427 1: SolCast DEBUG> ChargeOTP Bat 01 26/12 - hod: 13/02, lr/lc: 1/1, SoC S/E: 11289/10984 Wh, Surp h/d: 0/0 Wh, OTP: 5040 W
2025.10.26 10:06:57.428 1: SolCast DEBUG> ChargeOTP Bat 01 26/13 - hod: 14/03, lr/lc: 1/1, SoC S/E: 10984/10720 Wh, Surp h/d: 0/0 Wh, OTP: 5040 W
2025.10.26 10:06:57.428 1: SolCast DEBUG> ChargeOTP Bat 01 26/14 - hod: 15/04, lr/lc: 1/1, SoC S/E: 10720/10208 Wh, Surp h/d: 0/0 Wh, OTP: 5040 W
2025.10.26 10:06:57.428 1: SolCast DEBUG> ChargeOTP Bat 01 26/15 - hod: 16/05, lr/lc: 1/1, SoC S/E: 10208/9576 Wh, Surp h/d: 0/0 Wh, OTP: 5040 W
....

Für das aktuelle Beispiel ist es zwar nicht zutreffend oder relevant, aber der Überschuss der aktuellen Stunde kann durchaus größer sein, als der des Resttages. Das trifft zum Beispiel zu wenn in den Folgestunden des Tages ein Mehrverbrauch gegenüber der PV-Erzeugung vorliegt, also ein negativer Überschuß.

14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/14 - hod: 15 / 00, lr/lc: 1/1, SoC S/E: 4401 / 7680 Wh, Surplus: 4306 Wh, OTP: 1887 W (remaining: 3279 Wh)
14:51:47 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 25/14 - hod: 15 / 00, lr/lc: 1/1, SoC S/E: 5645 / 6270 Wh, Surplus: 718 Wh, OTP: 1122 W (remaining: 2035 Wh)

So wirklich verstehe ich nicht, warum die Leistung von 1887 W auf 1122 W innerhalb der Stunde sinkt und dann auf 1524 W am Stundenwechsel wieder hochgeht, wenn doch konstant Überschuss vorhanden ist.

Der Überschuß ist ja nicht konstant. Er reduziert sich, wie hier auch zu sehen, durch die Zeitgewichtung von 4306 Wh zu Beginn der Stunde zu 718 Wh gegen Ende der Stunde.
Mit achievable=yes, wie bei dir der Fall, folgt die vorgeschlagene Ladeleistungsbegrenzung tendenziell dem Überschuß auch wenn noch diverse Nachbehandlungen erfolgen.
Ich konnte bei mir noch keine negativen Folgen der Zeitgewichtung in Bezug auf die resultierende Ladeleistung beobachten, werde dies aber weiter verfolgen. Sollten sich dadurch negative Effekte ergeben, fliegt die Zeitgewichtung wieder aus den Routinen.

Meine Berechnung für 14:00 würde erwarten: Bedarf 3279 Wh auf 3 Stunden aufgeteilt sind 1093 W
Stunde2: Bedarf 3279 Wh in 3 Stunden. Surplus: 997 Wh => 997W Laden + 20% Margin = 1196 W
Stunde1: Bedarf 2282 Wh in 2 Stunden. Surplus: 1736 => 1141W Laden  + 20% Margin = 1369 W
Stunde0: Bedarf 1141 Wh in 1 Stunden. Surplus: 4306 => 1141W Laden + 20% Margin =  1369 W

Das ist nur die halbe Wahrheit, denn smartPower benutzt eine Ratio gewichtete Margin aus (Rest)Tagesüberschuß und Ladebedarf, die du in #4248 ins Spiel gebracht hast und die ich in #4259 beschrieben habe.

ABER...dank deines Anschubses habe ich mir die Routine nochmal angeschaut und festgestellt, dass ich leider statt des (Rest)Tagesüberschusses die (Rest)Tages-PV-Erzeugung eingebracht habe.
Das habe ich korrigiert.

Das Modulupdate liegt im Contrib.

Allgemein möchte ich nochmal in Erinnerung rufen, dass es das Ziel ist am Ende des Tages das gewünschte Ladeziel oder, falls nicht machbar, eine möglichst maximale Ladung zu erreichen. Diese Ziele sollen mit einer möglichst geringen Ladeleistung erreicht werden. Idealerweise ist diese Ladeleistung über einen längeren Zeitraum relativ konstant, was tendenziell im Sommer mit Überschüssen weit oberhalb der Zielladeleistung erreicht werden wird. Aktuell wird dies weniger der Fall sein und die Ladeleistung entsprechend der formulierten Ziele volatil sein. Eine gleichmäßige Ladeleistung über den gesamten Tag ist wünschenswert, aber nicht das Ziel. Insbesondere nicht, wenn das gewünschte Ladeziel nicht oder nur unsicher erreicht werden kann.

Weiterhin gibt es User, die lieber eine niedrige Ladeleistung bevorzugen und dafür bereit sind eventuelle Verluste in Form von Einspeisung zu akzeptieren. Für diesen Kreis ist optPower gemacht.
Andere User möchten in schlechten Phasen doch eher das Maximum an Ladung herausholen und deswegen nicht zwanghaft an evtl. zu niedrigen Ladeleistungen festhalten. Für diesen Kreis ist die aggressivere smartPower Option gedacht.