76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

@Parallix,

zu deiner Anregung in #3789:
...
Im ersten Ansatz würde ich meinen, du möchtest als Ergebnis die Anzahl der Stunden die benötigt werden, um die Bat bis Sonnenuntergang auf z.B. maxSoC zu laden.

Im Prinzip ja, aber die Batterie soll in diesem Anwendungsfall ab dem Berechnungszeitpunkt für das SF-SpecialReading bis zum Sonnenuntergang immer mit möglichst geringer Leistung auf ein Ziel-SOC geladen werden, da auf diese Weise der Stress für die Batterie minimiert werden kann. Hierzu ist praktisch die gleiche Rechnung durchzuführen, wie Du sie bereits mit ,,MinPwr" machst. Nun der Input ist in diesem Anwendungsfall ein anderer, da jetzt eine ,,MinPwr" entsprechende Größe zyklisch außerhalb von SF neu berechnet wird und über ein Reading SF zur Verfügung gestellt wird. SF berechnet und aktualisiert damit – analog zum anderen bereits implementierten Anwendungsfall ,,Termination Current" – die maximale Zeit, in der die angegebene Leistung zum Laden der Batterie zur Verfügung steht.  Extern kann dann die Suche nach der kleinsten Leistung (> TerminationPower), mit der am Tagesende der Ziel-SOC erreicht werden kann, erfolgen.

Edit 1: Für den Fall, dass die angegebene Leistung zu keiner Zeit zur Verfügung gestellt werden kann, kann eine 0 genau dieses auch korrekt signalisieren.

Edit 2: Alternativ zum Reading in SF, könnte SF auch eine Funktion zur Verfügung stellen, mit der - basieren auf dem o.g. Input - die o.g. Zeit bestimmt oder noch besser zyklisch aktualisiert ein Verteilung "Dauer über (1h-durchschnittliche) Mindestleistung" generiert werden kann. Das ist wahrscheinlich sogar der sinnvollere Weg, oder?

Bsp. für o.g. Verteilung:
>= 0,1 kW für 14 h, >=   1,4 kWh
>= 0,7 kW für 13 h, >=   0,1 kWh
>= 0,9 kW für 12 h, >= 10,8 kWh
>= 1,6 kW für 11 h, >= 17,6 kWh
      ...
>= 12,7 kW für  2h, >= 25,4 kWh
>= 14,8 kW für  1h, >= 14,8 kWh

[M94654]

Hallo zusammen,

ich habe den Request aus #3801 umgesetzt.

Vielen Dank!
Grüße
Michael

[DS_Starter]

@Parallix,

ich denke langsam eine ungefähre Ahnung zu haben wohin du willst.
Folgende Logik wäre mein Ansatz:

1. vom aktuellen Zeitpunkt bis Sonnenuntergang wird der PV Überschuß für jede einzelne Stunde ermittelt
2. die Überschüsse werden aufsteigend sortiert, dabei wird die Beziehung zur Tagestunde erhalten
3. der Ladebedarf (Wh) wird durch die Anzahl verbleibende Überschußstunden geteilt -> es ergiebt sich die
   notwendige (Mindest)-Startladeleistung
4. die Ladeleistung aus (3) wird über das Array aus (2) iteriert. Ist das Arrayelement (der Überschuß)
   größer als die Ladeleistung, wird die Ladeleistung als Ergebnis für diese Stunde festgehalten.
   Anderenfalls wird der Überschuß als Ladeleistung verwendet. Daraus ergiebt sich eine Endladung als
   Startwert für das nächste Arraylement -> eine neue Mindestladeleistung wird für die verbleibenden
   Stunden ermittelt und wieder mit dem Array-Element (Überschuß) in Beziehung gesetzt usw.....
5. Nachdem für jedes Array-Element die Ladeleistung ermittelt wurde, erfolgt die Rücksortierung in die
   aufsteigenden Tagesstunden, sodass für jede verbleibende Tagesstunde bis Sonnenuntergang eine
   "Zielladeleistung" verfügbar ist.
6. Wird die Zielladeleistung für jede Stunde erreicht, d.h. die prognostizierten PV-Überschüsse und
   weiteren Rahmenbedingen Realität, würde die Bat am Ende des Tages ihr Ziel-SoC erreicht haben

Bei mehreren Bat müsste noch eine Gewichtung eingebaut werden, da sonst konkurrierende Ladeleistungen entstehen würden.

Eine Bereitstellung als Reading wäre vermutlich nicht praktikabel, sondern eher als Hash mit allen Werten den man sich mit BatteryVal auslesen kann (und auch mit get ... valBattery anschauen).

Das wäre meine skizzierte Vorgehensweise dazu und hoffe natürlich meine Theorie so umsetzen zu können.
Passt der Ansatz zu deiner Vorstellung?

LG,
Heiko   
   

[Max_Meyer]

Bei mehreren Bat müsste noch eine Gewichtung eingebaut werden, da sonst konkurrierende Ladeleistungen entstehen würden.

Guten Morgen Heiko, Guten Morgen Parallix,

Ich hab das via User-Readings mit SF nach folgender Grundlogik umgesetzt:

Auszug aus dem Grobkonzept:
"das setzen des Parameters '40016_Wirkleistungsbegrenzung_in_Prozent' ist:
- Vorzeichen behaftet d.h:
            ein '-' (Minus) vor der Zahl bewirkt eine Reduzierung der Ladeleistung
            KEIN Vorzeichen vot der Zahl bewirkt eine Reduzierung der ENT- Ladeleistung
- ist ein prozentualer Faktor der (gewollten) Gesamtleistung (2500W)
- die Umrechnung in Prozent und zurück über Multiplikation damit keine Division durch Null auftritt
- W_40016 ist das Modbusregister zur Übergabe der Wirkleistungsbegrenzung in % (geht auch mit Leistung ist ein anderer MBR)

Formel Batterie laden:
1.) die zur 100%-Ladung notwendige Energie ermittelt: 2500*(100-Ladezusand Batterie in %) = missed_Energy_to_load
2.) Die Abbruchbedingung für das kontinuierliche Laden ist solange 'true' wie 'fast_load_start' größer ist als der PV-Forecast_Rest_of_the_day mit Fixwert (Reserve=5kWh) offset
3.) der eigentliche Parameter w_40016_load wird errechnet
3.1) der Normalfall (kontinuierliches Laden) wenn die Freigabebedingungen (Surplus & fast_load_start) OK sind wird missed_Energy_to_load  durch die verbleibenden Stunden mit Surplus geteilt (special_remainingSurplsHrsMinPwrBat_xx) und das Ergebnis als Anteil der Nennleistung (2500 W) negiert ausgegeben.
3.2) erste Eskalation wenn die Ladezeit nicht reicht - fast_load_start geht auf true der Batterieladestand ist unter 89% - w_40016_load  wird pauschal um  einen Faktor verkleinert
3.3) zweite Eskalation wenn die Ladezeit nicht reicht - fast_load_start geht auf true der Batterieladestand ist über 89% - w_40016_load  wird pauschal auf - 99% verkleinert
3.4 Abbruch wenn Surplus nicht mehr ausreicht --> w_40016_load  wird pauschal auf -100% gesetzt
Ob und wie (Ent-)Laden wird entscheidet die interne Inverterlogik über das verbundene Energymeter"

Das funktioniert soweit ganz gut - führt dazu das die Ladeleistung ansteigt bei 'ungeplanten' Entnahmen, muss für jede Bat separat gemacht werden - nur eine BAT kommuniziert direkt mit dem EM die anderen liefern beim Entladen auf Triggerpunkte bezogene Festwerte dazu. Laden siehe oben. Da muss ich man sich nicht um das letzte Watt kümmern - macht das EM

Ich schreib es bloß als Anregung - vielleicht kannst du einen Teil davon verwenden?
Gruß Gerd

[Parallix]

@Parallix,
...
Passt der Ansatz zu deiner Vorstellung?

Hallo Heiko,

ja, Deine Vorgehensbeschreibung entspricht (wahrscheinlich) weitgehend dem, was mir vorschwebt.

Die Mindeststartladeleistung ist z.B. für das Laden von EVs wichtig, die in aller Regel mindestens 6A pro genutzter Phasen (1 oder 3) und damit 1.370 W (1 x 230 V x 6 A) bzw. 4.140 W (3 x 230 V x 6 A) für eine Ladung brauchen.

Außerhalb des Anwendungsfalls ,,EV-Ladung" wird eigentlich keine Mindeststartladeleistung benötigt, da ja jederzeit mit der Ladung begonnen werden kann, wenngleich ein Verschieben des Starts hin zu Zeiten mit höheren Überschüssen und damit höheren erreichbaren Startladeleistungen natürlich die Netzdienlichkeit erhöhen kann. Anderseits führt ein ,,Softstart" der Ladung mit einer anfänglich geringen Ladeleistungen, einer möglichst gleichmäßige Ladung über den Tag (die bei PV netzdienlich über einen Zeitraum gegen Mittag sanft gesteigert, dann aber wieder reduziert werden sollte) und einem Erreichen des Ziel-SOC erst am Tagesende zu einem geringstmöglichen Stress für die Batterie und ist daher ja auch der Motor meines Anliegens.

Edit: Danke Gerd für Deinen Input! Muss ich mir nochmal genauer ansehen!

Edit 2: Das Laden mit möglichst geringer Leistung führt übrigens noch zu einem netten Nebeneffekt: Kurzzeitige Lastspitzen, müssen - aufgrund des größeren eigenen Überschusses - nicht über das Netz bedient werden und reduzieren so die aus dem Netz bezogene Leistung.

PS: Die nachfolgende Grafik dient zur Illustration, wie eine möglichst gleichmäßige Ladung über den Tag aussehen könnte.

[DS_Starter]

Moin Gerd, Parallix,

danke für das Teilen deiner Strategie Gerd.
Ich muß mir das Ganze anschauen und noch weiter zu Gemüte fürhren.
Die Umsetzung wird etwas Zeit brauchen und wir werden uns dem optimalen Ergebnis gemeinsam nähern müssen.
Den aktuellen contrib Stand werde ich erstmal einschecken damit die Weiterentwicklungen drin sind.

LG,
Heiko

[DS_Starter]

@all,

die Version 1.57.3 ist eingecheckt und liefert ab morgen früh folgenden Inhalt aus:

- Abfangen Crash wenn Victron API kein Array als Antwort sendet
- das global Attribut dnsServer wird in allen SF Models im Configcheck geprüft
- Erweiterung der Einstellung plantControl->genPVdeviation für einen möglichen Perspektivwechsel
- Neues Spezialreading ctrlSpecialReadings->dummyConsumption
- weitere kleinere Fixes und Codeanpassungen

LG,
Heiko

[Parallix]

...
Auszug aus dem Grobkonzept:
...

Mir ist die Intention Deiner Eskalationsstufen nicht klar. Wenn ich 3.2 richtig verstehe, dann reduzierst Du die Ladeleistung, wenn die Ladezeit nicht ausreicht. In vorliegenden Fall müsstest Du die Ladeleistung doch eher erhöhen denn erniedrigen, oder?

Aktuell (es ist ja noch Sommer reicht bei mir noch eine ganztägige Ladung mit einer Leistung, die unterhalb BatTerminationPower liegt. Das wird im Winter sicher anders aussehen. Nicht zuletzt deshalb möchte ich hier dazu beitragen, dass frühzeitig eine Datenbasis geschaffen wird, mit der auch dann eine optimale und batterieschonende Ladung und Entladung möglich wird, die auch zu einer guten SOC-Schätzung führt. Folglich muss regelmäßig auf SOC=100 auf und einen unteren SOC, der bei ca. 5% liegt, entladen wird. Letzteres geht insb. bei mehr als einem angebundenen Speicher auch ohne drohendem Autarkieverlust.

Im Sommer wird sicher die Strategie ,,Erreichung des Ziel-SOC so spät wie möglich" eine sinnvolle sein, da die Tage lang sind, nachts vergleichsweise wenig Energie aus dem Speicher entnommen wird und der Speicher daher morgens noch recht voll sein wird. Es ist also wenig tragisch, wenn Variationen in der Ladung oder Entladung auftreten.

Im tiefen Winter wird die Strategie eine andere sein, nämlich ,,Erreichung des Ziel-SOC so früh wie möglich". Dies weil die Tage kurz sind, nachts (vielleicht aus tagsüber) vergleichsweise viel an  Energie aus dem Speicher entnommen wird und der Speicher daher morgens nur noch über wenig an Energiereserve verfügt, die man aufgrund unvorhersehbarer Variationen der Produktion/Entnahme aber maximieren möchte.

Beachtet werden muss, dass sich die o.g. Strategien ausschließlich auf die (fest) installierten Speicher im Haus beziehen, nicht aber  auf die in einem EV. Gleichwohl ist es natürlich wichtig, dass auch diese Speicher in einer Ladungsplanung geeignet berücksichtigt werden. Der Planungshorizont für EV-Speicher variiert erheblich: Zwischen den Werktagen werden alle die, die mit einem EV zur Arbeit fahren, täglich eine Mindestenergie in das EV bringen wollen (ggf. via Energietransfer von Hausspeicher), um damit ein stets hinreichend geladenes EV für die Fahrt zur Arbeit zu haben. Am Wochenende darf dann, sofern keine Reisen geplant sind, die Ladung auch über mehrere Tage erfolgen. Ist absehbar, dass praktisch täglich ein nennenswerter Energiefluss vom Hausspeicher zum EV-Speicher und (ggf. zeitlich versetzt) vom EVU in den Hausspeicher erfolgt, so sollte (aus Effizienzgründen und zur Reduzierung unnötiger Ladezyklen des Hausspeichers) auf eine Ladung des EVs aus dem Hausspeicher verzichtet werden und das EV über das Netz des EVU geladen werden.

Die Ladeplanung sollte meiner Ansicht aber nicht hart von Jahreszeiten abhängig sein, sondern sich im Idealfall adaptiv an die jahreszeitlich unterschiedlichen Gegebenheiten adaptieren. Dies setzt voraus, dass der Vorhersagehorizont in jedem Fall einige Tage betragen muss.

[Wolle02]

Hallo zusammen, ich habe bei mir die kontinuierliche Ladung des Speichers ähnlich wie Gerd realisiert, allerdings mit einem MSwitch als Eventhandler und nicht mittels Userreadings. Von der Funktion sind wir allerdings ähnlich unterwegs, wobei ich noch zusätzlich eine Funktion integriert habe, die den Speicher auf max. Einspeiseleistung setzt sobald an der Strombörse negative Strompreise vorliegen, so dass so lange wie Speicherkapazität vorhanden ist keine Einspeisung ins Netz erfolgt.
Dies zum einen, da es in Zukunft keine Einspeisevergütung mehr gibt, wenn negative Strompreise vorliegen und zum anderen, um ein netzdienliches Verhalten zu unterstützen, da bei Vorliegen von zu viel erneuerbarer Energie im Netz (Voraussetzung der negativen Strompreise) nicht noch zusätzlich ins Netz eingespeist werden soll. Dies würde auch einer eventuellen (Zwangs-)Abregelung durch den Netzbetreiber vorbeugen.

An einem sonnigen Tag (gestern) sieht die Ladekurve bei mir dann so aus wie im angehängten Bild.

[Parallix]

... bei Vorliegen von zu viel erneuerbarer Energie im Netz (Voraussetzung der negativen Strompreise) nicht noch zusätzlich ins Netz eingespeist werden soll. Dies würde auch einer eventuellen (Zwangs-)Abregelung durch den Netzbetreiber vorbeugen.

Die Abregelung wird (nach aktuellem Stand) auf "day ahead"-Basis erfolgen. Insofern ist unklar, ob unsererseits überhaupt vorgebeugt werden kann. Gleichwohl ist ein netzdienliches Verhalten natürlich löblich! Die Frage ist nur, was wirklich netzdienlich ist. Ob die Politik es z.B.auf dem Schirm hat, dass es letztlich durch negative und ladesweit gültige Börsenstrompreise verursacht zu sprunghaften lokalen Bezugsspitzen bei gleichzeitiger verringerter Einspeisung kommen wird, ist mir unklar. Besser würde man vermutlich fahren, wenn die zur Verfügung stehende Leistung sinnvoll genutzt werden würde. Immerhin gab es hierzu ja auch mal einige Ideen, wie z.B hier nachzulesen ist.

[Max_Meyer]

Mir ist die Intention Deiner Eskalationsstufen nicht klar. Wenn ich 3.2 richtig verstehe, dann reduzierst Du die Ladeleistung, wenn die Ladezeit nicht ausreicht. In vorliegenden Fall müsstest Du die Ladeleistung doch eher erhöhen denn erniedrigen, oder?

Hallo Parallix,
prinzipiell richtig - ich gebe aber das Derating vor - das muss ich reduzieren - was dazu führt das mehr 'Ladeleistung 'erlaubt' wird. Den genauen Betrag macht der Inverter mit dem EM aus.

Im tiefen Winter wird die Strategie eine andere sein, nämlich ,,Erreichung des Ziel-SOC so früh wie möglich". Dies weil die Tage kurz sind, nachts (vielleicht aus tagsüber) vergleichsweise viel an  Energie aus dem Speicher entnommen wird und der Speicher daher morgens nur noch über wenig an Energiereserve verfügt, die man aufgrund unvorhersehbarer Variationen der Produktion/Entnahme aber maximieren möchte.

Der Test steht noch aus - bisher gehe ich davon aus, dass der vorgegeben Offset hier so wirkt dass der Akku eher lädt. Also mangels Prognose, prognostiziertes PV reduziert um den Offset reicht auch wenn zwischendurch Energie abgegeben wird.

Beachtet werden muss, dass sich die o.g. Strategien ausschließlich auf die (fest) installierten Speicher im Haus beziehen, nicht aber  auf die in einem EV.

meiner Ansicht nach ist das Bestimmende hier die Strategie der PV-Energieverwendung - bei mir habe ich die WP (+WW) vor dem EV priorisiert - das führt(e) dazu das im eigentlichen Winter  praktisch keine PV-Energie fürs EV zur Verfügung steht - das EV lädt dann (bei Bedarf) nachts.
In der Übergangszeit bis Ende Oktober und ab Mitte Februar - ich habe das ähnlich wie Batterieladen gemacht und gebe über User-Readings den aktuellen PV-Überschuss (ab 1700W) ans EV weiter - Umschaltung 1-3ph ist automatisch - ist in meinem Fall noch von Ladeparametern im EV abhängig - durch Kombi von PV und nachts laden wird SOC min garantiert. EV hab ich als Consumer eingerichtet und eine Zusatzlogik jenseits SF im Einsatz.

Die Abregelung wird (nach aktuellem Stand) auf "day ahead"-Basis erfolgen. Insofern ist unklar, ob unsererseits überhaupt vorgebeugt werden kann. Gleichwohl ist ein netzdienliches Verhalten natürlich löblich! Die Frage ist nur, was wirklich netzdienlich ist.

eine dynamische Abregelung kleiner PV Anlagen (<25kW) ist technisch nur mir SmartMeter möglich - deren Rollout ist bis 2032 geplant (derzeit ) - solange kein SM eingebaut ist gilt die 60% Kappung - da gibt es ja durchaus Möglichkeiten prognosebasiert die regelbaren Verbraucher in diese Zeit zu legen - der Messpunkt dafür ist der NÜP (am Zähler) - alles was vorher intern verbraucht wird zählt da nicht.
Gruß Gerd

[Parallix]

Hallo Gerd,

...
eine dynamische Abregelung kleiner PV Anlagen (<25kW) ist technisch nur mir SmartMeter möglich - deren Rollout ist bis 2032 geplant (derzeit ) - solange kein SM eingebaut ist gilt die 60% Kappung - da gibt es ja durchaus Möglichkeiten prognosebasiert die regelbaren Verbraucher in diese Zeit zu legen - der Messpunkt dafür ist der NÜP (am Zähler) - alles was vorher intern verbraucht wird zählt da nicht.

dass Du zu den 60%-igen gehörst, dass wusste ich nicht; steht ja auch nicht in Deiner Signatur. Im Grunde arbeitest Du ja auch nicht netzdienlich, sondern eher eigenverbrauchsoptimiert, oder?

Die dynamische Regelung verlangt übrigens deutlich mehr als nur ein iMSys. Gebraucht wird zusätzlich nämlich noch eine Steuerbox und eine Software, die seitens des Netzbetreibers an letztere die (Steuer-)Befehle sendet. Die Steuerbox weist ihrerseits dann z.B. via EEBUS Dein EMS an, diese Befehle auszuführen und wiederholt diese Anweisung beispielsweise im Falle eines temporären Ausfalls Deines EMS.

PS: Auch ich gehe davon aus, dass eine Wärmepumpe im "echten Winter" von einer PV-Anlage höchstens nur noch marginal profitiert. Habe bislang aber keine und werde damit wahrscheinlich auch noch einige Zeit warten.

[300P]

PS: Auch ich gehe davon aus, dass eine Wärmepumpe im "echten Winter" von einer PV-Anlage höchstens nur noch marginal profitiert. Habe bislang aber keine und werde damit wahrscheinlich auch noch einige Zeit warten.

Das ist zu 100 % nicht von der Hand zu weisen 

Trotz kleinerer Optimierungen    an meiner Anlage (Module / Strings bis zur technischen Grenze gemäß der WR-Datenblätter hinzugefügt) im Frühjahr werde ich keinesfalls meine Autarkie von weit über 90 % in Zukunft mit der WP noch aufrecht erhalten können.

Da nützt es auch nix wenn im Sommer viel Überschuss vorhanden ist - der kann ja nicht 1/2 Jahr in den Keller gestapelt werden.(so viel Batterie kann man gar nicht "haben"! )