76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[ch.eick]

...
Moin,
Ich hatte auch mal versucht die Ladeleistung etwas gleichmäßiger zu regeln um in der Mittagszeit einen schönen grafischen Block zu bekommen, jedoch spielt zusätzlich noch die Ladekurve des Speichers mit rein. Ein möglichst linearer Anstieg des SOC ergibt bei mir eine Art von Keil bei der Ladeleistung. Letztendlich habe ich dann versucht die Ladeleistung so beim WR vorzugeben, das es sich auf die Zeit möglichst Netzdienlich verteilt. Zum Ende wird zwar eine hohe Wünschleistung vorgegeben, jedoch der Speicher entscheidet sich für weniger und es wird ein Keil.
...

Sinnvollerweise verändern die BYDs (und sicher auch andere) die max. Ladeleistung in Abhängigkeit vom akt. SOC und der Temperatur. Das ist auch gut, um den Akku nicht zu viel Stress auszusetzen.

Danke für die Rückmeldung, das war mir auch so bewußt, ich wollte es nur nochmal erwähnen, damit nicht zuviel Zeit darein investiert wird.
Gerne hätte ich halt ein weiteres Gerät mit gleichmäßigem, kalkulierbarem Bezug zum Peak Shaving gehabt:-)

[Parallix]

...
Das <PowerIn> ist der Wert, den wir als eine Komponente der Ladeabbruchbedingung in ctrlBatSocManagementXX->loadAbort verwenden. Deswegen war meine Frage, ob die dort angegebene Leistung identisch zu der gerade diskutierten Ladeschlussleistung ist, da ich ansonsten einen weiteren Parameter in ctrlBatSocManagementXX einführen und auch entsprechend beschreiben muß was der User darunter zu verstehen hat.

Der erste Schritt um weiterzukommen wäre jetzt erstmal ein "Ja" oder "Nein". 

Ja, PowerIn sollte die oben diskutierte minimal geforderte Ladeschlussleistung sein und daher vielleicht besser MinTermPwr heißen.

[Parallix]

...
Danke für die Rückmeldung, das war mir auch so bewußt, ich wollte es nur nochmal erwähnen, damit nicht zuviel Zeit darein investiert wird.
Gerne hätte ich halt ein weiteres Gerät mit gleichmäßigem, kalkulierbarem Bezug zum Peak Shaving gehabt:-)

Hier geht es ja nicht um regelungstechnisch nicht trivial zu betrachtende klassische Peaks, die zeitlich nur sehr kurz anstehen, sondern um längere Zeiträume mit erhöhten Erzeugungs- oder Verbrauchsleistungen. Auf Basis von SF können beide prognostiziert und damit auch kalkulatorisch berücksichtigt werden. Sofern überhaupt genügend Akku-Kapazität zur Verfügung steht (wird immer so dargestellt, ist im privaten Bereich aber häufig nicht der Fall), können die Erzeugungsanteile, die gekappt werden sollen, in den den Speicher verbracht werden.

Offensichtlich bräuchte man für Deinen Anwendungsfall neben dem von mir vorgeschlagenen Wert für die minimale geforderten Ladeschlussleistung, über deren Verwendung die maximalen Ladezeiten bestimmt werden kann, noch weitere Werte zur Betrachtung von zum kappenden Erträgen: Ein Wert, mit dem die maximale tolerierbare Einspeiseleistung angegeben wird, ein Wert für die Dauer der prognostizierten Einspeisekappung und ein Wert für die Energie, die durch die Kappung dann anderweitig zu "entsorgen" ist.

[DS_Starter]

@Parallix, @all,

in meinem contrib liegt die V 1.52.16. und ist jetzt auch eingecheckt.
Ergänzt ist nun die Option remainingSurplsHrsMinPwrBat_XXim Attribut ctrlSpecialReadings:

remainingSurplsHrsMinPwrBat_XX   
        die verbleibende Anzahl Stunden am aktuellen Tag, in denen der PV-Überschuß (Wh) höher ist als das
        kalkulierte Stundenintegral einer minimalen Ladeleistung der Batterie XX.
        Die Angabe <MinPwr> erfolgt im Attribut ctrlBatSocManagementXX->loadAbort.

Es wird natürlich geprüft, ob Attribut ctrlBatSocManagementXX->loadAbort gesetzt ist, da <MinPwr> für diese Auswertung benötigt wird.
Der Wert remainingSurplsHrsMinPwrBat_XX wird natürlich dynamisch mit jedem SF-Zyklus neu berechnet, sodaß Änderungen in diversen Vorhersagen und Verhältnissen im Stromnetz eingehen.

Diese Version enthält kumulativ einige Erweiterungen seit der letzten offiziellen Version.
Deswegen hier die hinzugekommenen Features im Überblick:

- Attr ctrlSpecialReadings enthält die neuen Optionen remainingHrsWoChargeRcmdBat_XX und remainingSurplsHrsMinPwrBat_XX

- die Balkengrafik ist hinsichlich ihrer linearen Skalierung überarbeitet

- jede Ebene der Balkengrafik kann getrennt auf eine logarithmische Skalierung umgestellt werden (Attr graphicControl->scaleMode)
 
- das Attr ctrlBatSocManagementXX->loadAbort ist um eine Freigabebedingung erweitert

EDIT: Anpassung der Beschreibung von remainingSurplsHrsMinPwrBat_XX
EDIT2: Ich habe den Namen des Special Readings geändert damit er besser auf den eigentlichen Inhalt der
       Berechnung passt. Dass man das Reading zur Ladesteuerung der Bat verwendet steht auf einem anderen
       Blatt.


LG,
Heiko

[bismosa]

Ich habe das Fallbeispiel Pumpensteuerung im Wiki überarbeitet.

Das sollte nun passen.

Hallo Heiko!
Vielen Dank! Nun passt es perfekt. Es schaltet nun genauso wie erwartet. 
Kleiner Schönheitsfehler im wiki:

Code Auswählen Erweitern

      if ($mrest >= ($mneed - $msum)) {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=1");            # Interrupt-Freigabe
      }
      else {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=0");            # keine Interrupt-Freigabe
      }
mit "consumer$c" wird auch die Nummer des Verbrauchers vom Script benutzt.

Danke für das Modul und den Support!
Gruß
Bismosa

[DS_Starter]

Kleiner Schönheitsfehler im wiki...

Danke, habe es gleich angepasst. War mir doch wieder durchgerutscht. 

[DS_Starter]

Die V 1.52.16 ist eingecheckt.

[Parallix]

Die V 1.52.16 ist eingecheckt.

Hallo Heiko!

Nachdem ich korrekterweise zuvor aufgefordert wurde, meine bisherigen Settings von <ctrlBatSocManagementXX> zu erweitern, habe ich soeben <remainingSurplsHrsMinPwrBat_XX> via <ctrlSpecialReadings> aktivieren können.

Nun erhalte ich für meine beiden BATs <special_remainingSurplsHrsMinPwrBat_XX> und damit einen Wert, auf dessen Basis ich die Ladeleistungen der BATs konfigurieren kann. Der angezeigte Wert ist stimming! Super! Danke!

Einige Dinge sind mir aufgefallen:

• <special_remainingSurplsHrsMinPwrBat_XX> sollte noch in einen Gleitkommawert überführt werden, da ja von der aktuellen Zeit ausgehend die noch verbleibenden Ladestunden bestimmt werden (sollten).
• Trotz via <loadAbort> eingestelltem Threshold (bei mir 5%) wird in SF am Tagesende nach Erreichen von SOC=100% für einige Folgestunden (bei einem weiterhin prognostiziertem SOC von 100%) noch eine Ladeempfehlung gegeben.
• Der Bezeichner special_remainingSurplsHrsMinPwrBat_XX ist doch recht sperrig und schlecht lesbar/interpretierbar und könnte durch special_remSunHrsWithMinChgPwrBat_XX ersetzt werden. Sofern denkbar, könnte man auch das Prefix "special_" durch ein "s_" erseten

[DS_Starter]

Moin,

freut mich, dass es klappt.

<special_remainingSurplsHrsMinPwrBat_XX> sollte noch in einen Gleitkommawert überführt werden, da ja von der aktuellen Zeit ausgehend die noch verbleibenden Ladestunden bestimmt werden (sollten).

Kann ich machen. Das bezieht sich im Prinzip immer auf die aktuelle (angebrochene) Stunde die dann zu dem Gleitkommawert führt.

Trotz via <loadAbort> eingestelltem Threshold (bei mir 5%) wird in SF am Tagesende nach Erreichen von SOC=100% für einige Folgestunden (bei einem weiterhin prognostiziertem SOC von 100%) noch eine Ladeempfehlung gegeben.

Du meinst sicherlich, dass "Battery_ChargeRecommended_XX=1" gesetzt ist. Ja, das ist richtig so, da dieses Reading eine "Ladefreigabe" im Sinne der Netzdienlichkeit signalisiert und auch Nachts 1 sein wird wenn keine PV anliegt. Konsequenterweise sollte ich es umbenennen in z.B. "Battery_ChargeFullRelease_XX=1" im Sinne einer vollen Ladefreigabe gegenüber der beschränkten Ladefreigabe bei Überschreiten eines Einspeiselimits. Eine solche Umbenennung zieht wieder einigen Aufwand beim Nutzer nach sich, weswegen ich bislang davon Abstand genommen habe. Kommt aber vllt. noch wenn gewünscht.

Der Bezeichner special_remainingSurplsHrsMinPwrBat_XX ist doch recht sperrig und schlecht lesbar/interpretierbar und könnte durch special_remSunHrsWithMinChgPwrBat_XX ersetzt werden

Hier war mir der Bezug zu den Stunden mit PV-Überschuß (SurplsHrs) sehr wichtig, da dieser Wert die Berechnungsgrundlage in Beziehung von <MinPwr> ist weswegen die Bezeichnung so die Inhalt richtig wiedergibt (auch wenn es vllt. am Anfang etwas mühselig ist  ). Weiterhin passt die Bezeichnung im Kontext gut zur auch etwas kryptischen Bezeichnung remainingHrsWoChargeRcmdBat_XX. 

LG,
Heiko

[Parallix]

Moin,

freut mich, dass es klappt.

<special_remainingSurplsHrsMinPwrBat_XX> sollte noch in einen Gleitkommawert überführt werden, da ja von der aktuellen Zeit ausgehend die noch verbleibenden Ladestunden bestimmt werden (sollten).

Kann ich machen. Das bezieht sich im Prinzip immer auf die aktuelle (angebrochene) Stunde die dann zu dem Gleitkommawert führt.

Das wäre super, da man andernfalls die daraus bestimmten Ladeleistungen am Ende eines PV-Tages auf Basis zu ungenauer Zahlen bestimmen müsste.

[Parallix]

Trotz via <loadAbort> eingestelltem Threshold (bei mir 5%) wird in SF am Tagesende nach Erreichen von SOC=100% für einige Folgestunden (bei einem weiterhin prognostiziertem SOC von 100%) noch eine Ladeempfehlung gegeben.

Du meinst sicherlich, dass "Battery_ChargeRecommended_XX=1" gesetzt ist. Ja, das ist richtig so, da dieses Reading eine "Ladefreigabe" im Sinne der Netzdienlichkeit signalisiert und auch Nachts 1 sein wird wenn keine PV anliegt. Konsequenterweise sollte ich es umbenennen in z.B. "Battery_ChargeFullRelease_XX=1" im Sinne einer vollen Ladefreigabe gegenüber der beschränkten Ladefreigabe bei Überschreiten eines Einspeiselimits. Eine solche Umbenennung zieht wieder einigen Aufwand beim Nutzer nach sich, weswegen ich bislang davon Abstand genommen habe. Kommt aber vllt. noch wenn gewünscht.

Die Benennung ist in der Tat ungünstig und ich war - wenn ich mich recht erinnere - schon früher einmal darüber gestolpert. Was ich aber überhaupt nicht nachvollziehen kann ist, warum eine Speicherladung nach Sonnenuntergang netzdienlich sein soll. Würde in SF eine Netzbeteiberprognose für (alle) regenerative Energien herangezogen, in der auch die Windkraftanlagen berücksichtigt würden, dann könnte der o.g. Fall auftreten. Im vorliegenden Fall aber wohl doch nicht, oder?

[DS_Starter]

Einfach mal einen anderen Blickwinkel einnehmen. Eine "Ladefreigabe" ist immer vorhanden, es sei denn sie wird durch bestimmte netzdienliche und andere Faktoren "untersagt" bzw. in eine "beschränkte Ladeempfehlung bei Überschreitung des Einspeiselimits" gewandelt. Das ist die Aussage des Readings "Battery_ChargeRecommended_XX=1", mehr nicht.

[Parallix]

Einfach mal einen anderen Blickwinkel einnehmen. Eine "Ladefreigabe" ist immer vorhanden, es sei denn sie wird durch bestimmte netzdienliche und andere Faktoren "untersagt" bzw. in eine "beschränkte Ladeempfehlung bei Überschreitung des Einspeiselimits" gewandelt. Das ist die Aussage des Readings "Battery_ChargeRecommended_XX=1", mehr nicht.

Wenn ich den anderen Blickwinkel einnehme, dann sehe ich etwas, was (mir) absolut nicht verständlich ist: Netzdienlich soll eine Akkuladung zu einer Zeit sein, in denen keine PV-Leistung zur Verfügung steht? In diesem Fall muss dann aus dem Netz geladen werden, was in den Abendstunden (mit erhöhten Netzlasten durch ein nicht netzdienliches Laden von (Elektroauto-)Batterien, Kochen, Waschen, u.s.w.) keineswegs netzdienlich ist.  Also sollte zu diesen Zeiten das Laden "untersagt" (nicht empfohlen) werden! Ausnahme: Es handelt sich um eine Sicherungsladung, mit der a) eine geforderte Mindestenergie für Backupzwecke eingelagert wird oder b) der Akku vor einer Tiefentladung geschützt wird. Beide letztgenannten sind aber außerhalb von SF zu betrachten.

PS: Hilf mir bitte mit dem Blickwinkel, wenn ich irgendetwas total falsch sehe oder verstehe!

[300P]

Die Übersetzung von "Battery_ChargeRecommended" ist wohl "Batterie_LadungEmpfohlen"
Was gibt es an dem zu deuten
"Trump" sagte ja auch das er in 24 Stunden Frieden stiften wird - er sagte ja "nur" nicht von wann an.....
sorry     

[DS_Starter]

Netzdienlich soll eine Akkuladung zu einer Zeit sein, in denen keine PV-Leistung zur Verfügung steht?

Löse dich von der Vorstellung, das Reading ist ausschließlich für ein netzdienliches Verhalten da. Es dient auch dazu ein optimales Verhältnis zwischen Einspeisung und Batterie-Endaufladung zu erreichen, also Gewinnmaximierung zum Schutz unserer eigenen Investition um ein Herabregeln der Anlage zu vermeiden. In Verbindung mit plantControl->feedinPowerLimit wird ein netzdienliches Verhalten unterstützt. Vergleiche dazu auch den Abschnitt im Wiki.
Wie schon geschrieben ist das Reading Battery_ChargeRecommended_XX eher eine "Freigabe". (Vermutlich werde ich das Reading doch noch in Battery_ChargeFullRelease_XX umbenennen. Den Schmerz muß ich dann nur einmal ertragen.) D.h. natürlich ist die Ladung in der Nacht auch freigegeben wenn man mag. Aber kein ESS was ich kenne lädt ohne PV-Überschuß die Batterie ... außer - und jetzt kommt der nächste Punkt -

Ausnahme: Es handelt sich um eine Sicherungsladung, mit der a) eine geforderte Mindestenergie für Backupzwecke eingelagert wird oder b) der Akku vor einer Tiefentladung geschützt wird.

Dazu gibt es im Modul das Reading Battery_ChargeRequest_XX. Das wird gesetzt wenn eine Emergency Ladung der Bat erfolgen sollte.

Zusammengfasst ist Battery_ChargeRecommended_XX=1 eine "du kannst laden" Freigabe, wogegen Battery_ChargeRequest_XX=1 eine "du mußt es nun wirklich tun!"-Ansage ist. Dazu gehört im Prinzip noch Battery_ChargeAbort_XX welches besagt, jetzt die "Ladung tatsächlich abbrechen" weil die von dir definierte Bedingung eingetreten ist.

Ich hoffe das ist jetzt noch etwas klarer geworden.

LG,
Heiko