76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Hadl,

vielen Dank! 

Mittlerweile sehe ich aber auch immer mehr Stunden mit geringen Ertrag, und nur kurzen "Lichtblicken" am Tag. Die würde ich gerne in den Akku bekommen anstatt diese einzuspeisen und dann am Abend den Akku nicht voll zu haben.
In ein paar Wochen kommt sicher wieder die Zeit in der der Akku über Nacht ab und zu leer wird.
...
Deshalb würde ich mich über ein Signal "target likely achievable"=0 des aktuellen Tages sehr freuen. Ich würde auch dann mit hoher Leistung laden lassen und einspeisen damit vermeiden.

Ich kann das vollkommen nachvollziehen und habe diese Idee bei mir heute im Laufe des Tages bereits eingebaut und getestet. Den Trigger "target likely achievable"=0 zu nutzen und die Ladeleistung entsprechend hochzuheben ist m.M. nach in Verbindung mit optPower eine sehr gut funktionierende Variante die Volatilität in dieser Jahreszeit abzufangen und für die Batterie zu nutzen.

Schwierig ist eine Festlegung der Ladeleistung die irgendwo zwischen pinreduced und pinmax liegt, denn diese Optimierung macht ja die optPower-Logik bereits. Die Schwäche, unvorhergesehene "Lichtblicke" mit hohen Erträgen nicht nutzen zu können, liegt dann in der Natur der Sache.

Die Idee den achievable-Status zu nutzen ist in der aktuellen Contrib-Version enthalten wenn du es ausprobieren möchtest. Morgen ist wieder so ein verhangener Tag an dem es vielleicht "Lichtblicke" gibt. Dann lässt es sich gut beobachten.

Im Anhang ist eine schöne gleichmäßge Ladekurve zu sehen die kurz nach 16:00 das gewünschte Max von 100% erreicht.

LG,
Heiko

[grappa24]

wird der achievable-Status automatisch verarbeitet oder ist der selbst umzusetzen?

[DS_Starter]

Moin,

das wird automatisch gemacht.
Wenn es aus bestimmten Gründen gewünscht ist, kann ich auch ein Reading dafür erstellen. Allerdings ist der Wert pro Batterie zu errechnen. Je nach deren Anzahl würden dann 1-X Readings generiert.
Alternativ könnte ich auch einen Wert in valBattery erstellen, der aus Scripten heraus mit BatteryVal gelesen werden könnte.

[Hadl]

Hallo Heiko,
ich hab mir die aktuelle version aus dem Contrib geladen und lasse es heute mal damit laufen. Ich werde berichten.

Schwierig ist eine Festlegung der Ladeleistung die irgendwo zwischen pinreduced und pinmax liegt, denn diese Optimierung macht ja die optPower-Logik bereits. Die Schwäche, unvorhergesehene "Lichtblicke" mit hohen Erträgen nicht nutzen zu können, liegt dann in der Natur der Sache.

Ich hab mir das so vorgestellt:
Die optPower Logik versucht ja den Energiebedarf möglichst gleichmäßig auf die Stunden mit Energieüberschuss zu verteilen. Wenn viel Überschuss vorhanden ist, dann wird die Ladeleistung auch mit hoher Wahrscheinlichkeit erfüllt.
Sollte es aber knapp sein, müsste man mehr von den kurzen "Lichtblicken" profitieren, indem man den berechneten optPower Wert anhebt.

Man könnte auf den Quotienten zwischen erwarteten Überschuss und Ladebedarf des Rest-Tages schauen.
Ist dieser > 120% wird OptPower wie berechnet werwendet.
Ist dieser < 100% wird pinmax verwendet.
Ist dieser zwischen 100% und 120% wird linear zwischen OptPower und pinmax interpoliert und diese erhöhte Leistung als neues OptPower verwendet.

Nehmen wir an, OptPower berechnet für den aktuellen Zeitpunkt 1000W und pinmax ist 2000W:
Überschuss/Ladebedarf[%] -> OptPower
100% -> 2000W
105% -> 1750W
110% -> 1500W
115% -> 1250W
120% -> 1000W

Die 120% sollen nur ein Beispiel sein und sollten einstellbar sein.

[grappa24]

das wird automatisch gemacht.

mir reicht das 

[DS_Starter]

Hallo Hadl,

wir behalten das im Hinterkopf und schauen uns erstmal an wie die aktuelle Lösung jetzt mit den Situationen umgeht.

Man könnte auf den Quotienten zwischen erwarteten Überschuss und Ladebedarf des Rest-Tages schauen.
Ist dieser > 120% wird OptPower wie berechnet werwendet.
Ist dieser < 100% wird pinmax verwendet.
Ist dieser zwischen 100% und 120% wird linear zwischen OptPower und pinmax interpoliert und diese erhöhte Leistung als neues OptPower verwendet.

Im Prinzip wird der Fall "Ist dieser < 100% wird pinmax verwendet" jetzt bereits abgebildet. Der Status achievable=0 sagt aus, dass das Ladeziel wegen ungenügenden Überschuß rechnerisch nicht erreicht werden kann.

Dann wäre eine stufenweise Abschwächung von pinmax (bei 100%) bis optpower (bei >= 120%) noch umzusetzen. Im Prinzip gibt es das in abgewandelter Form jetzt auch schon. Über den Parameter ctrlBatSocManagementXX->safetyMargin kannst du einen prozentualen Sicherheitsaufschlag auf den berechneten optPower-Wert aufschlagen lassen. Wenn es sich als günstig erweist, könnte ich eine solche Abstufung aus safetyMargin ableiten. Schauen wir mal...

[Parallix]

Einige haben sich vielleicht gefragt, warum ich gerne in Battery_ChargeOptTargetPower_XX eine sinnvolle berechnete Ladeleistung und nicht (in einigen Situationen) einen festen Wert wie pinmax hätte. Der Grund liegt zum einen darin, dass auch bei volatilen Wetterlagen keine Leistungssprünge, von 0 auf pinmax haben möchte.

Es gibt aber noch einen weiteren Grund: Wenn man mal von einem "Force"-Modus absieht, startet meine in FHEM realisierte Ladesteuerung für mein EV die Ladung erst dann, wenn der zur Verfügung stehende "Überschuss" eine gewisse Grenze überschreitet. In Abhängigkeit vom aktuellen Ladezustand der Hausspeicher rechne ich in vorgenannten Grenze, also den geforderter Überschuss, die aktuellen Ladeleistungen der Hausspeicher mit deren aktuellem SOC gewichtet ein und verfolge damit das im SF-Wiki unter dem Stichwort "Priorisierung" beschrieben Ziel einer Verschiebung von Ladeprioritäten.

Beispiel: Bei einem Haus-SOC von 90% wird 90% der akt. Hausspeicher-Ladeleistung in den zur Verfügung stehenden Überschuss für die EV-Ladung eingerechnet, bei einem Haus-SOC von 0% halt gar nichts.

Edit: Meine EV-Ladesteuerung basiert auf der Annahme, dass das EV innnerhalb einer Woche (insb. tagsüber) einige Tage durchgehend zur Ladung zur Verfügung steht, also z.B. von Freitag 15:00 Uhr bis Montag 7:00 Uhr und in diesem Zeitfester eine Aufladung möglich ist, um mit dem EV wenigstens über die verbleibenden Zeit pro Woche zu kommen ohne die Hausspeicher so stark zu entladen, das mit diesen das Ziel einer 100% Autarkie nicht mehr erfüllt werden kann. Ist dies (im Beispiel) bis Sonntag 24:00 Uhr nicht möglich, so erfolgt eine (Teil-)Aufladung über das öffentliche Netz.

Übrigens: Unvorhergesehene Lichtblicke bei volatilen Wetterlagen führen selbst bei einer unbegrenztem max. Ladeleistung - zumindest bei mir - selten zu signifikanten Energieeinträgen.

[DS_Starter]

Einige haben sich vielleicht gefragt, warum ich gerne in Battery_ChargeOptTargetPower_XX eine sinnvolle berechnete Ladeleistung und nicht (in einigen Situationen) einen festen Wert wie pinmax hätte.

Diese sinnvoll berechnete Ladeleistung gibt es im Reading Battery_ChargeOptTargetPower_XX und ist ja das Ergebnis der optPower-Logik. Diese Logik stützt sich, wie kann es anders sein, auf die PV- und Verbrauchsprognose. Nur muß man dann damit leben, dass unvorhergesehene plötzliche Aufklarungen bei sonst bedeckten Himmel verbunden mit einer plötzlichen/starken PV-Erzeugung im Form von Einspeisung "verloren" geht. Dem kann man nur mit einem gewissen Sicherheitsaufschlag (safetyMargin) begegnen oder aber wie aktuell im contrib implementiert, die Aktivierung der berechneten optPower von einer generellen Erreichbarkeit abhängig zu gestalten. Dadurch ist die Wahrscheinlichkeit deutlich gesteigert, unvermittelte Sonnenenergie in die Batterie zu laden. 

[Parallix]

...
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.

EDIT: Alternativ dazu könnte ich die aktuelle Ladeleistung auf pinmax stellen, solange "target likely achievable?"== no ist. Das würde eine fallbezogene Mischung aus loadRelease und optPower ergeben. Sobald das Ladeziel überhaupt erreichbar scheint, greift dann eine optimale Ladestrombegrenzung.

Eine explizit gewählte Ladestrategie automatisch umzuschalten, dass fände ich sehr seltsam. Logischer wäre es vermutlich, eine weitere Ladestrategie "Automatik" einzuführen, die dann selber entscheidet, was zu tun ist.

Edit (zu Deinem Edit): Auch wenn das Ziel nicht erreichbar ist, sollte meines Erachtens die "optimale Ladestrombegrenzung" greifen, wenn ein User die Strategie "schonende Ladung" aka "optPower" gewählt hat.

@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.

Gerne teste ich die neuen Features, wobei ich ctrlBatSocManagementXX->loadTarget erst dann auf einen Wert < 100 setzen möchte, wenn es am Tag mal mehr als 0 Sonnenstunden (ein Prognosewert, der in der DWD-App Warnwetter abgegeben wird) prognostiziert werden

Edit: Im Wiki finde eine textuell inzwischen sehr anspruchsvolle Beschreibung der Ladestrategien. Was ich vermisse ist eine klassische algorithmische Darstellung, die ich gerne beisteuern würde. Da aktuell aber noch einiges nicht konsolidiert ist, werde ich dieses Projekt wahrscheinlich erst kommenden Monat in Angriff nehmen, sofern Interesse an einer entsprechenden Darstellung besteht und würde mich diesbezüglich über ein Feedback freuen.

[DS_Starter]

@all,

im contrib liegt ein weiteres Update.
Es sind nun folgenden Umsetzungen enthalten:

- bei mehreren Batterien wird deren Anteil vom aktuellen Ladungsdefizit im Verhältnis zum Gesamtdefizit bestimmt. Bisher wurde dafür
  die installierte Kapazität benutzt. Diese Aufteilung ist für die SoC- und Ladesteuerung benutzt/relevant.
 
- die generelle Erreichbarkeit des Ladeziels (achievable) wird für die Aktivierung der berechneten optPower verwendet  (*)

- mit ctrlBatSocManagementXX->stepSoC kann die Schrittweite zur optimalen SoC-Berechnung eingestellt oder das SoC-Management abgeschaltet werden

  stepSoC    
    Optionale Schrittweite zur optimalen SoC-Berechnung (Battery_OptimumTargetSoC_XX) in %.
    Mit der Angabe 'stepSoC=0' wird das SoC-Management deaktiviert und Battery_OptimumTargetSoC_XX
    auf den Wert 'lowSoC' gesetzt.
    Wert: 0..5, default: 5
   
- mit ctrlBatSocManagementXX->loadTarget kann ein Ladeziel (0..100%) für die Bat eingestellt werden

  loadTarget    
    Optionaler Ziel-SoC in % für die Berechnung der Ladefreigabe bzw. der optimalen Ladeleistung.
    Der Zielwert ist eine kalkulatorische Rechengröße. Der reale SoC kann je Situation in Grenzen
    über- oder unterschritten werden. Der höhere Wert aus Reading Battery_OptimumTargetSoC_XX
    und 'loadTarget' hat für die Berechnung Vorrang.
    Wert: 0..100, default: 100


(*) Ich denke darüber nach zusätzlich zu den vorhandenen Strategien loadRelease, optPower die Strategie smartPower zu
    ergänzen und in dieser Strategie die Anwendung von achievable zu verankern. Dann würde optPower ohne Beachtung der
    Erreichbarkeit des Ladeziels das Reading Battery_ChargeOptTargetPower_01 befüllen und smartPower wie optPower
    rechnen mit dem Zusatz der Beachtung der generellen Ziel-Erreichbarkeit.

Im Wiki finde eine textuell inzwischen sehr anspruchsvolle Beschreibung der Ladestrategien. Was ich vermisse ist eine klassische algorithmische Darstellung, die ich gerne beisteuern würde.

Liebend gerne.

[Parallix]

@all,

im contrib liegt ein weiteres Update.
...

Das sind sehr gute Nachrichten, da sich das Modul nun - generischer gestaltet - viele Anwendungsfälle unterstützt!  Toll finde ich die sich aus Deiner Fußnote ergebende Perspektive!