76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Wenn ich das richtig sehe, dann wird Battery_OptimumTargetSoC_XX – eine nach meinem Empfinden sehr schlechte Bezeichnung für das Reading – schrittweise angehoben, damit der erforderliche obere SOC zur Batteriepflege auch erreicht werden kann.

Ja, jedoch nicht nur das. Es wird tatsächlich optimaler SoC berechnet, der auf die PV Erzeugung der nächsten zwei Tage reagiert. Das führt dazu, dass in dieser für PV armen Zeit dennoch im Normalfall genügend Speicherplatz verfügbar ist um den Wechsel von schlechten zu sehr guten Erzeugungslagen (die gibt es tatsächlich  ) zu managen. Das ist der große Vorteil gegenüber (kommerziellen) Lösungen die einen statischen SoC einstellen. Deswegen ist die Namensgebung auch absolut richtig und passend.

Nach meinem Erfahrungen und bei meiner Anlagenkonfiguration wird dieser Zustand bei einem nicht zu kurz eingestellten careCycle, der in meinem Fall bei 14 Tagen liegt, auch ohne Anhebung des Mindest-SOC hinreichend oft erreicht.

Bei mir nicht da ich eine sehr hohe Speicherkapazität gegenüber der installierten PV-Leistung habe was mir allerdings viele Vorteile bietet.

Des weiteren schlage ich vor, dass der Zähler special_daysUntilBatteryCare_XX bis zur turnusmäßigen Batteriewartung – sofern nicht bereits realisiert (steht aber nicht im Wiki) - auch negative Werte annehmen kann und damit die bisherige Überschreitung des Wartungstermins in Tagen leicht ermittelbar wird.

Ich sehe für eine solche Änderung keine Notwendigkeit und ich möchte auch mal ein Stück vorwärts kommen mit den noch anstehenden Dingen. Das aktuelle Verfahren hat sich bewährt und geht jetzt schätzungsweise in die 3. oder 4. Wintersaison.

Wenn dann noch ein Attribut, z.B.  careCycleTolerance, existiert, mit dem die tolerierte Überschreitung des Wartungstermins angegeben werden kann, könnten weitere sinnvolle Funktionen bzw. Readings in oder außerhalb von SF realisiert werden.

Was wäre das beispielsweise?

Abschließend möchte ich außerdem noch anregen, die binäre Readings, die sich auf ein Device beziehen und wie z.B.  Battery_ChargeAbort_01, Battery_ChargeRequest_01 und Battery_ChargeRequest_01 das Vorliegen einer Sondersituation signalisieren, in ein einziges Reading zu überführen

Worin besteht der Unterschied zwei Readings auszuwerten oder nur ein Reading bezüglich seines Wertes, der verschiedene Status repräsentiert?
Was ist denn der überragende Vorteil einer solchen Änderung gegenüber dem Nachteil alle Codes, sämtliche Onlinehilfen und Wikibeschreibungen ändern/anpassen müssen?
Kannst du das bitte darlegen? Ich bin bei vielen Dingen gern bereit mitzugehen, will aber verstehen wofür ich meine Freizeit/Lebenszeit verbrennen soll.

LG,
Heiko

[Parallix]

Wenn ich das richtig sehe, dann wird Battery_OptimumTargetSoC_XX – eine nach meinem Empfinden sehr schlechte Bezeichnung für das Reading – schrittweise angehoben, damit der erforderliche obere SOC zur Batteriepflege auch erreicht werden kann.

Ja, jedoch nicht nur das. Es wird tatsächlich optimaler SoC berechnet, der auf die PV Erzeugung der nächsten zwei Tage reagiert. Das führt dazu, dass in dieser für PV armen Zeit dennoch im Normalfall genügend Speicherplatz verfügbar ist um den Wechsel von schlechten zu sehr guten Erzeugungslagen (die gibt es tatsächlich  ) zu managen. Das ist der große Vorteil gegenüber (kommerziellen) Lösungen die einen statischen SoC einstellen. Deswegen ist die Namensgebung auch absolut richtig und passend.

Ja! SF kann sehr viel und in der Tat deutlich mehr als kommerzielle Lösungen und das im übrigen auch mit sehr wenig Datentransport nach außen! Den Readingnamen finde ich deshalb schlecht, da aus ihm überhaupt nicht hervorgeht, dass es sich um einen optimalen unteren SOC handelt. Hier wäre z.B. BatOptMinSoC_XX (ggf, auch weniger abgekürzt) greifbarer - man könnte auch "optimaler" sagen

[DS_Starter]

dass es sich um einen optimalen unteren SOC handelt.
BatOptMinSoC_XX

Ja, da könnte ich auch auch mitgehen. 

[Parallix]

Nach meinem Erfahrungen und bei meiner Anlagenkonfiguration wird dieser Zustand bei einem nicht zu kurz eingestellten careCycle, der in meinem Fall bei 14 Tagen liegt, auch ohne Anhebung des Mindest-SOC hinreichend oft erreicht.

Bei mir nicht da ich eine sehr hohe Speicherkapazität gegenüber der installierten PV-Leistung habe was mir allerdings viele Vorteile bietet.

Ja! Dass das bei Dir so ist, das glaube ich Dir! Meinerseits hatte ich ja auch geschrieben: "Um SF an möglichst viele [andere] Konfigurationen und Anwendungsfälle  anpassen zu können" ...

[Parallix]

Wenn dann noch ein Attribut, z.B.  careCycleTolerance, existiert, mit dem die tolerierte Überschreitung des Wartungstermins angegeben werden kann, könnten weitere sinnvolle Funktionen bzw. Readings in oder außerhalb von SF realisiert werden.

Was wäre das beispielsweise?

Außerhalb z.B. das zwangsweise Beladen des Speichers aus dem Netz, was innerhalb von SF durch ein Reading (oder Bit innerhalb eines Readings) z.B. empfohlen werden könnte.

[DS_Starter]

Außerhalb z.B. das zwangsweise Beladen des Speichers aus dem Netz, was innerhalb von SF durch ein Reading (oder Bit innerhalb eines Readings) z.B. empfohlen werden könnte.

Fragezeichen im Kopf ... das ist doch schon gegeben -> Das Reading Battery_ChargeRequest_XX signalisiert doch bereits das Ladeverlangen. Vllt. stehe ich einfach nur auf dem Schlauch...

[Parallix]

Abschließend möchte ich außerdem noch anregen, die binäre Readings, die sich auf ein Device beziehen und wie z.B.  Battery_ChargeAbort_01, Battery_ChargeRequest_01 und Battery_ChargeRequest_01 das Vorliegen einer Sondersituation signalisieren, in ein einziges Reading zu überführen

Worin besteht der Unterschied zwei Readings auszuwerten oder nur ein Reading bezüglich seines Wertes, der verschiedene Status repräsentiert?
Was ist denn der überragende Vorteil einer solchen Änderung gegenüber dem Nachteil alle Codes, sämtliche Onlinehilfen und Wikibeschreibungen ändern/anpassen müssen?
Kannst du das bitte darlegen? Ich bin bei vielen Dingen gern bereit mitzugehen, will aber verstehen wofür ich meine Freizeit/Lebenszeit verbrennen soll.

• Eine zu behandelnde Sondersituation lässt sich durch Abfrage eines Readings feststellen (Readingwert > 0), was auch bei einer künftige Erweiterung von Sondersituationen weiter so wäre. Die Anzahl an Readings würde reduziert. (Datensparsamkeit)
• Bei einer Konfiguration ggf, nicht relevante oder genutzte Readings würden nicht mehr angezeigt (Übersichtlichkeit)
• Spezifischere Angaben lassen sich ohne zusätzliche Readings machen, z.B. dringende Ladeempfehlung wg. SOC < lowSOC, Anregung zur Ladung aus dem Netz, um den Speicher in den "Wartungszustand" zu bringen. (Detailliertheit)

[DS_Starter]

Ja, diese allgemeinen Vorteile sind mir bewusst. Was ich eher meinte ist ein unmittelbarer Vorteil der den AUFWAND einer solchen Umstellung lohnt. Man muß sich bewusst sein, dass diese grundlegende Änderung von Readingsinhalten bzw. ihrer Datenpendants in den internen Strukturen (currentVal, Nexthours, Circular, History, ...), die Erstellung von Routinen zum Parsen von Readinginhalten sowie das Überprüfen/Nachziehen von Doku etc. inklusive der dazugehörigen Tests und Fehlerbereinigungen viele Stunden Freizeit bis zu einigen Tagen dieser wertvollen Zeit verschlingen können.

Deswegen hinterfrage ich den Nutzen von solchen Vorschlägen sehr genau. Das ist kein böser Wille, aber es geht um meine Zeit...

Wenn es mal weitere Funktionen geben sollte, die eine gewisse "Notwendigkeit" (ähnlich den zusammengesetzten Attributen) einer solchen Zusammenfassung erfordern, kann man darüber nachdenken.

Unmittelbar ließen sich thematisch gleiche Anforderungen in einem vorhandenen Reading darstellen, zum Beispiel eine Ladeanforderung im Reading Battery_ChargeRequest_XX -> 0 - keine, 1 - normale Anforderung (SoC < upSoC), 2 - dringende Anforderung/Notladung (SoC < lowSoC). Auch hier wären einige Codeänderungen nötig, weil eine einfache Prüfung true/false nicht mehr reicht, aber der Umfang wäre überschaubar. Aber wie gesagt "nice to have" ist einfach zu wenig.
Wenn jemand sagt es würde mir wirklich sehr helfen weil "..." wenn ich diese oder jene Funktionalität hätte, bin ich der letzte der sich querstellt.

[Parallix]

...
Aber wie gesagt "nice to have" ist einfach zu wenig.
Wenn jemand sagt es würde mir wirklich sehr helfen weil "..." wenn ich diese oder jene Funktionalität hätte, bin ich der letzte der sich querstellt.

Es sind alles nur Vorschläge und ich werde wahrscheinlich auch überleben, wenn keiner der Vorschläge realisiert werden würde  .

Wenn es um Herzensangelegenheiten geht, so würde ich mich über einen frei konfigurierbaren TargetSOC und eine Änderungs-/Abschaltmöglichkeit des schrittweisen Anhebens des unteren SOCs schon sehr freuen. Aktuell bin ich dabei, SF auch bei der Ladung (m)eines EV's stärker heranzuziehen. Hier habe ich aber arge Probleme, da die jetzige Bat-Steuerung noch in einem recht engen Korsett steckt.

[DS_Starter]

Wenn es um Herzensangelegenheiten geht, so würde ich mich über einen frei konfigurierbaren TargetSOC und eine Änderungs-/Abschaltmöglichkeit des schrittweisen Anhebens des unteren SOCs schon sehr freuen. Aktuell bin ich dabei, SF auch bei der Ladung (m)eines EV's stärker heranzuziehen. Hier habe ich aber arge Probleme, da die jetzige Bat-Steuerung noch in einem recht engen Korsett steckt.

Da lässt sich bestimmt etwas machen.  
Mit "schrittweisen Anhebens des unteren SOCs" meinst du sicherlich die 5% des Taget-SoCs, also des Readings Battery_OptimumTargetSoC_XX? Das muß ich mir anschauen wie es in die generelle Ablauflogik passen würde wenn es einen konfigurierbaren Schlüssel gäbe.
Bei "frei konfigurierbaren TargetSOC" bin ich mir unschlüssig was du meinst. Soll damit Battery_OptimumTargetSoC_XX manuell setzbar und nicht mehr logikgeführt sein?

[Parallix]

...
Da lässt sich bestimmt etwas machen.  
Mit "schrittweisen Anhebens des unteren SOCs" meinst du sicherlich die 5% des Taget-SoCs, also des Readings Battery_OptimumTargetSoC_XX? Das muß ich mir anschauen wie es in die generelle Ablauflogik passen würde wenn es einen konfigurierbaren Schlüssel gäbe.

Wenn die Anhebung von einem fixen Startwert aus erfolgt - so jedenfalls hatte ich Dich immer verstanden - und die Anhebung DeltaPerStep um die bislang festen 5 Prozentpunkte (woher kommen die eigentlich ?) konfigurierbar sein, dann könnte man, z.B. mit DeltaPerStep=0, den unteren Ziel-SOC festsetzen.

Bei "frei konfigurierbaren TargetSOC" bin ich mir unschlüssig was du meinst. Soll damit Battery_OptimumTargetSoC_XX manuell setzbar und nicht mehr logikgeführt sein?

Du hattest mir an früherer Stelle mal geschrieben, dass die Ladungsplanung für loadStrategy == optPower immer von 100 als (oberer) TargetSOC ausgeht. Insb. im Sommer würde ich diesen Wert aber absenken wollen. Darum geht es mir. Da bei mir (auf der Nordhalbkugel) der Sommer erst einmal vorbei ist, ist diese Feature eher eine niedrig zu priorisierende Angelegenheit.

Übrigens wird bei mir aktuell (bei SOC = 75) Battery_ChargeOptTargetPower_XX mit 250 W =  pinreduced angegeben; das ist eigentlich viel zu wenig. Wahrscheinlich ist es sinnvoll, künftig von zwei Steuerungsmöglichkeiten auszugehen: a) Fixes Setzen der Ladung mit  Battery_ChargeOptTargetPower_XX b) Fixes Setzen der maximalen Ladung mit Battery_ChargeOptTargetPower_XX. Also einmal eher in Richtung Regelung und einmal in Richtung Steuerung zu denken.

Edit: Bin gleich zum Sport und daher dann offline. Also bitte nicht wurden, wenn ich nicht direkt antworte.

[DS_Starter]

Wenn die Anhebung von einem fixen Startwert aus erfolgt - so jedenfalls hatte ich Dich immer verstanden - und die Anhebung DeltaPerStep um die bislang festen 5 Prozentpunkte (woher kommen die eigentlich ?) konfigurierbar sein, dann könnte man, z.B. mit DeltaPerStep=0, den unteren Ziel-SOC festsetzen.

Ja, die Anhebung basiert auf dem aktuellen Battery_OptimumTargetSoC_XX (initial aus dem Sommer kommend == lowSoC) und erfolgt in 5er Schritten 40,45,50, etc. Das 5er Raster ist eine empirische Festlegung von mir und berücksichtigt die verbleibenden Tage von careCycle.

Du hattest mir an früherer Stelle mal geschrieben, dass die Ladungsplanung für loadStrategy == optPower immer von 100 als (oberer) TargetSOC ausgeht. Insb. im Sommer würde ich diesen Wert aber absenken wollen. Darum geht es mir.

Ok, verstanden.

Übrigens wird bei mir aktuell (bei SOC = 75) Battery_ChargeOptTargetPower_XX mit 250 W =  pinreduced angegeben;

Es müsste mindestens pinreduced * safetyMargin sein. Also würde ich pinreduced und/oder safetyMargin anheben.

[Parallix]

Da bei mir aktuell (12.10.25) eine absolut diffuse Lichtsituation vorliegt und die Sonne bereits so hoch steht dass es bei meiner 25° Dachneigung praktisch keine wirksamen Abschattungen mehr gibt, erhalte ich derzeit (ca. 13:00 MESZ) von meinen Ost-, Süd- und Weststrängen praktisch die gleichen Erzeugungsleistungen. Insbesondere am frühen Morgen sieht das das aufgrund des tieferen Sonnenstandes anders aus. Dann nämlich führt eine Baumbestand auf der Westseite durchaus zu einer signifikanten Leistungsreduktion, der sich natürlich nur im Westseitenstrang bemerkbar macht und zu einer nicht nur marginalen Diskrepanz zwischen prognostiziertem und tatsächlichen Ertrag führt.

Um o.g. Auswirkungen möglichst gut korrigieren zu können, bedarf es Korrekturfaktoren, die für jeden einzelnen String respektive für jede einzelne Ausrichtung getrennt bestimmt werden. Hiermit möchte ich anregen, diese in einer zukünftigen Version von SF einzurichten.

Edit:
Heute (13.10.25) wird mir bei pinreduced=250, poutmax=7680, cap=7680 und aktuell (9:55 MESZ) bei SOC=15% und rund 3000 W solar erzeugte Leistung vorgeschlagen: Battery_ChargeOptTargetPower_XX = 250 W. Mir ist klar, dass mir wegen Battery_ChargeUnrestricted_XX == 1 angezeigt wird, dass ich eigentlich mit (bis zu) pinmax=3500 laden könnte. Das ist aber, insb. vor der Perspektive einer noch höheren solaren Erzeugung, unnötig viel.

Begrüßen würde ich, wenn  Battery_ChargeOptTargetPower_XX unter Berücksichtigung der safetyMargin auf einen Wert gesetzt würde, mit dem man bei Ladung bis zum Sonnentagesende den Speicher auf den Ziel-SOC (aktuell noch fest 100%) bekommen würde, jedoch nicht mehr als  pinmax.

Wer bei Battery_ChargeUnrestricted_XX == 1 mit pinmax laden will, der kann das ja unabhängig von Battery_ChargeOptTargetPower_XX machen. Wenn man so vorheht, dann würde das Reading "Battery_ChargeOptTargetPower_XX"  wenigstens seine ursprünglich angedachte Bedeutung behalten, nämlich einen Leistung anzugeben, mit der ein Speicher möglichst schonend geladen werden kann.

[DS_Starter]

Begrüßen würde ich, wenn  Battery_ChargeOptTargetPower_XX unter Berücksichtigung der safetyMargin auf einen Wert gesetzt würde, mit dem man bei Ladung bis zum Sonnentagesende den Speicher auf den Ziel-SOC (aktuell noch fest 100%) bekommen würde, jedoch nicht mehr als  pinmax.

Um die Ladeleistung gegenüber eienr zu eng gefassten Berechnung zu erhöhen gibt es die safetyMargin, was bei dir offensichtlich auf 0 gesetzt ist, sonst würde die Ladeleistung nicht bei pinreduced landen. Weiterhin kann man pinreduced anheben. Wenn weniger Überschuß als pinreduced vorliegt, wird ohnehin weniger geladen. Dadurch hat man eine höhere Resilienz.
Hast du dir denn im Wiki meine Erläuterungen zur Wahl der Ladestrategie mal durchgelesen?

Wenn man sich das Debuglog anschaut sieht man, dass die Ladeleistung sich immer an die Überschüsse anpasst. Aber der gesamte Überschuß reicht zur Zeit nicht aus um die Bat auf das Ziel zu laden, kann ich nicht ändern. Dann muß man sich woanders beschweren. So sieht es mit default Margin 20% und pinreduced 600W aus:

Code Auswählen Erweitern

2025.10.13 10:41:08.105 1: SolCast DEBUG> Bat 01 ChargeOTP - charging target: 28416 Wh, remaining: 15345 Wh -> target likely achievable? no
2025.10.13 10:41:08.106 1: SolCast DEBUG> Bat 01 ChargeOTP 13/10 - hod: 11 / 00, lr/lc: 1/1, SoC S/E: 13071 / 13745 Wh, Surplus: 2239 Wh, OTP: 3869 W
2025.10.13 10:41:08.106 1: SolCast DEBUG> Bat 01 ChargeOTP 13/11 - hod: 12 / 01, lr/lc: 1/1, SoC S/E: 13745 / 14952 Wh, Surplus: 1271 Wh, OTP: 1525 W
2025.10.13 10:41:08.106 1: SolCast DEBUG> Bat 01 ChargeOTP 13/12 - hod: 13 / 02, lr/lc: 1/1, SoC S/E: 14952 / 16351 Wh, Surplus: 1473 Wh, OTP: 1768 W
2025.10.13 10:41:08.107 1: SolCast DEBUG> Bat 01 ChargeOTP 13/13 - hod: 14 / 03, lr/lc: 1/1, SoC S/E: 16351 / 17537 Wh, Surplus: 1248 Wh, OTP: 1498 W
2025.10.13 10:41:08.107 1: SolCast DEBUG> Bat 01 ChargeOTP 13/14 - hod: 15 / 04, lr/lc: 1/1, SoC S/E: 17537 / 19506 Wh, Surplus: 2073 Wh, OTP: 2488 W
2025.10.13 10:41:08.108 1: SolCast DEBUG> Bat 01 ChargeOTP 13/15 - hod: 16 / 05, lr/lc: 1/1, SoC S/E: 19506 / 20655 Wh, Surplus: 1209 Wh, OTP: 1451 W
2025.10.13 10:41:08.108 1: SolCast DEBUG> Bat 01 ChargeOTP 13/16 - hod: 17 / 06, lr/lc: 1/1, SoC S/E: 20655 / 23155 Wh, Surplus: 2632 Wh, OTP: 3158 W
2025.10.13 10:41:08.108 1: SolCast DEBUG> Bat 01 ChargeOTP 13/17 - hod: 18 / 07, lr/lc: 1/1, SoC S/E: 23155 / 23747 Wh, Surplus: 623 Wh, OTP: 748 W
2025.10.13 10:41:08.109 1: SolCast DEBUG> Bat 01 ChargeOTP 13/18 - hod: 19 / 08, lr/lc: 1/1, SoC S/E: 23747 / 23119 Wh, Surplus: 0 Wh, OTP: 5040 W

Damit ist man auch nicht davor gefeit, dass mal etwas eingespeist wird ... steht alles im Wiki.

Eine Variante wäre eine automatische Umschaltung zur Strategie "loadRelease" wenn/solange das Ladeziel als unerreichbar errechnet wird -> "target likely achievable? no". Das kann der User tun, dazu brauche ich nur ein Reading/Signal dieser Berechnung bereitzustellen.

Wer bei Battery_ChargeUnrestricted_XX == 1 mit pinmax laden will, der kann das ja unabhängig von Battery_ChargeOptTargetPower_XX machen. Wenn man so vorheht, dann würde das Reading "Battery_ChargeOptTargetPower_XX"  wenigstens seine ursprünglich angedachte Bedeutung behalten, nämlich einen Leistung anzugeben, mit der ein Speicher möglichst schonend geladen werden kann.

Wo ist das Problem?

@all:
Im contrib liegt eine neue Version mit folgenden Umsetzungen:

- mit ctrlBatSocManagementXX->loadTarget kann ein Ladeziel (0..100%) für die Bat eingestellt werden
- bei mehreren Batterien wird deren Anteil vom aktuellen Ladungsdefizit im Verhältnis zum Gesamtdefizit bestimmt. Bisher wurde dafür
  die installierte Kapazität benutzt

Gerade die Auswirkungen des letzten Aspekts kann ich bei mir nur ungenügend testen/simulieren weil ich nur eine Batterie habe. Deswegen bin ich auf euer Feedback angewiesen wie sich das Ladeverhalten verändert.

LG,
Heiko