Battery Price Calculation - FeedIn-Preis berücksichtigen?

[TobiasB71]

Ich spiele mit der DEV Version rum und habe die Battery Price Calculation konfiguriert, derzeit ist das so, dass die Ladung der Batterie aus PV mit 0€ Kosten berechnet wird.

Würde es nicht Sinn machen, dafür den FeedIn-Preis quasi als virtuelle Kosten anzusetzen und entsprechend einzurechnen? Immerhin ist es ja (bei mir) so, dass ich alles, was ich einspeise, bezahlt kriege, und wenn es stattdessen in den Akku geht, entgeht mir dieses Geld. D.h. zum Zeitpunkt des Ladens per PV kostet mich das rein buchhalterisch 8 Cent/kWh und dementsprechend müsste dass doch so wie die Kosten beim Laden aus dem Grid sinnvollerweise beim Preis der Batterieladung mit eingerechnet werden, oder?

[Chesstimation]

Auch ich nutze die "Development"-Version seit Wochen und muss sagen sie läuft wunderbar. Bzgl. der "Battery Price Calculation" habe ich mich aber auch schon gewundert, dass "feed_in_price" für den geladenen PV-Strom nicht berücksichtigt wird. Zusätzlich müsste ja auch noch "battery.charge_efficiency" und "battery.discharge_efficiency" berücksichtigt werden, oder wird das schon gemacht?

[ohAnd]

Feedin Preis geht direkt an die Optimierer, da dort entschieden wird, ob es gerade Sinn macht über PV Batterie zu laden oder eben ins Grid zu schicken ... d.h. er wird genau dort für die o.g. Fragen bereits berücksichtigt und in die Entscheidung mit einbezogen

Der Battery Price soll, dem Namen nach, direkt die Kosten der aktuell enthaltenen Energiemenge (Historie) repräsentieren, um eben den Optimierern ein realistischeres Bild zu geben. (ohne diese wurde entweder nur der konfigurierte Fix-Preis oder eben 'kostenlos' angenommen)
Hier werden dann die verschiedenen Energiequellen über ihre jeweiligen Kosten gegenüber gestellt, um daraufhin zum Einen den Jetzt-Zustand (was sollte jetzt gerade umgesetzt werden z.B. PV zu Battery oder lade Battery vom Grid) und zum Anderen die Prognose zu zeigen, was wäre wenn die aktuellen Annahmen bzgl. Verbrauch, PV-Input, SOC-Verlauf, ... so zutreffen.

[TobiasB71]

Für mein Verständnis sind das 2 unterschiedliche Entscheidungen:

Bei der ersten geht es um die Frage "spare ich mehr Geld, wenn ich zum Zeitpunkt X überschüssige Solarenergie in die Batterie lade oder sie stattdessen einspeise", bei die zweite wäre "ist der Strom, der aktuell in der Batterie gespeichert ist, günstiger als wenn ich ihn aus dem Netz beziehen würde".

Bei der 1. Entscheidung würde der Optimierer nur den FeedIn-Preis brauchen, aber dieses Szenario ist doch technisch gar nicht möglich, es gibt doch gar keinen "avoid solar charging" Status?!

Die Frage wäre IMHO, wie genau arbeitet der Optimierer bei der 2. Entscheidung - schlägt er den getrennt übergebenen FeedIn-Preis dann auf den ggf. definierten Fix-Preis oben drauf oder benutzt er den FeedIn-Preis nur, wenn der Fix-Preis = 0 ist ... denn "kostenlos" war der Strom der im Akku steckt in keinem Fall.

[MatzeBu]

... es gibt doch gar keinen "avoid solar charging" Status?!
Das habe ich mich auch schon gefragt ob es den gibt. Es gibt Situationen wo der sinnvoll ist!

[Chesstimation]

@ohAnd Deine Antwort verstehe ich nicht. In welcher Situation kann es denn Sinn machen, mit überschüssigem PV-Strom NICHT den Akku zu laden, sondern einzuspeisen? Da müsste ja die Einspeisevergütung sehr hoch sein.

[ohAnd]

jep, falsch beschrieben... habe mich wohl von einem Wunsch leiten lassen ... ;-)

... die Optimierer (eos,evopt) können (meines Wissens) derzeit nur grid_charge, discharge (to home), avoid discharge - zumindest ist das derzeit in der response in eos_connect umgesetzt

---

Aber genau deswegen wäre dann eine Integration in den battery_price aus meiner Sicht quasi nutzlos, da der Optmierer eben nicht das Batterie Laden sperren könnte und damit der Überschuss eingespeist werden kann.

(ausser man überlagert den Optimierer mit einem wie auch immer gearteten onTop-Algo in EOS_connect und steuert per max charge-power, was zum jetzigen Zeitpunkt zu viel des Guten wäre - wenn hier einer gute Ideen hat gerne PR)

---

Was ich nicht im Detail weiss und nur erahnen kann (deswegen ist es ...connect und nicht all-inclusive-system ;-) ) das der feedin-Preis für die Optimierer eine Grösse ist, um ggfs. die Batterie früher auf 100% (bzw. max. SOC) zu bekommen, um dann den Mehrertrag bei der Einspeisung zu nutzen ... z.B. per GridCharge weil im Vorfeld die gridpreise unter einspeisung (inkl. effiecincy) liegen... gab ja einige Tage im letzten Jahr, wo sogar Geld gezahlt wurde fürs verbrauchen ... nahe dem Zeitpunkt war natürlcih feedin = 0 ... aber 12h später kann es ja schon anders aussehen, und das wäre eine Stärke des Systems über den forecast

---

conclusio:
für mich ist es derzeit noch nicht schlüssig, warum der Preis der Energie die die Batterie aktuell enthält, in irgendeiner Form mit dem FeedIn-Preis verrechnet werden kann/ soll - und wie mit den bestehenden Möglichkeiten der reale Mehrwert aussieht (also was ändert sich damit 'wahrscheinlich' in dem Optimierungsergebnis und damit in der zyklischen Ansteuerung des Inverters/ Batterie)

[Chesstimation]

Ich würde mir vorstellen, den Energiepreis der in der Batterie gespeicherten Energie etwa so zu verwenden:
Mein 1. konkretes Beispiel z.B. für die nächsten 24h: Tibber 15min Preise: Heute Nacht hier etwa 31.5ct/kwh. Mein Speichersystem hat nur ~77% Wirkungsgrad. Akku ist leer. Also wenn ich heute Nacht lade, kostet der Strom den ich morgen entnehmen würde 31.5ct/kWh/77% = 40.9ct/kWh. Morgen kostet der Strom max. so um die 40ct/kWh. Also würde ich eigentlich erwarten dass der Optimierer kein grid_charge macht, bzw. falls es morgen höhere Gridpreise gäben würde, solange avoid_discharge macht, solange der Strompreis unter 41ct/kWh ist.
2. Beispiel: Auch der feed_in_price müsste für das PV-Laden des Akkus natürlich berücksichtigt werden. Ich bekomme hier noch 14.7ct/kWh, dieser steigt aber bei Verwendung des Akkus auf 14.7/77% auf etwa 19.1ct/kWh. In solchen (seltenen) Situationen wo der Strom aus dem Netz nun unter 20ct/kWh kostet, sollte der Optimierer auch hier auf avoid_discharge gehen. Ich glaube dies ist aktuell nicht machbar, weil der PV-Strom im Akku generell als kostenlos gerechnet wird.
3. Und der Parameter battery.price_euro_per_wh_accu scheint aktuell gar nicht in die Optimierung mit einzugehen. Meine Vorstellung hier wäre das ich über diesen Parameter einstellen kann, dass z.B. der Akku nur dann entladen wird, wenn ich mindestens 5ct/kWh beim Entladen gegenüber dem Netzbezug spare.

[ohAnd]

beim schnellen drüber lesen

1. => so sollten die Optimierer bereits arbeiten - hat aber nichts mit feedin-Preis zu tun ... - EOS_connect übergibt diese Daten bereits -- ggfs. bitte beim jeweils verwendeten Optimierer recherchieren
2. muss mal durchdacht werden, wie es sich über viele Opt-Zyklen verhalten würde ... und über die verschiedenen EInflüsse load, pv, grid price legen ... klingt im ersten Moment schlüssig - aber irgendwie auch nicht ;-)
3. doch ... als fix price und das seit Start des Projekts --- aber eben "neuerdings" nur, wenn price_calculation_enabled = false ... da er ja durch die dyn. Berechnung ersetzt wird

[ohAnd]

released with 0.2.33 - thx to @Chesstimation