discussion of logic regarding feed-in (export) tariff pre-charging and further development

[christian1980nrw]

Lets discuss the charging conditions in case of feeding in / exporting to the grid. @ckvsoft @alex90alex If the prices and the total charging costs at night are lower than the export payout in the afternoon, we should pre-charge the battery (maybe up to 100%).

Also if we are charging we should not forget the lost profit caused of the charging. It should be part of our calculations or am i wrong?

So that we don't talk past each other, we should carry out the example calculations in a shared spreadsheet first. https://docs.google.com/spreadsheets/d/1Xkx3vjyCw-b7HOuuWABOCdY-kFDthEFuIPjaHk99Tdo/edit?usp=sharing

Regards Christian

[ckvsoft]

Ja so genau weis ich das noch nicht, sonst hätte ich ja schon was angefangen. Keine Ahnung, nur bin ich so wie es jetzt ist nicht wirklich zu Frieden. Mein Akku ist jetzt schon auf 12% im idle mode. Doch die teuersten Stunden hab ich Heute noch vor mir. Erst wieder um 23 Uhr gehts halbwegs.

[christian1980nrw]

Dann besorg Dir doch im ersten Step mal einen API Key für das Solarwetter um vielleicht die Daten zumindest schonmal im Log aufzuzeichnen. Heute wäre also die Schwelle um zu 90% zu laden erreicht. Bringt Dir aber nur was wenn die Ladeverluste wirtschaftlich sind. Manchmal gehts halt einfach nicht, außer Du nutzt die Abwärme um Dein Haus zu mitzuheizen. Mein Multiplus ist in der Garage, also bleibt er bei flachen Preisspitzen aus (leider).

[ckvsoft]

Das hab ich eh, nur müsste ich ja da mehr Daten haben. Das sagt ja nichts aus.

[ckvsoft]

Ich hab mal auf die Victron 5000 Aktion zu geschlagen und nochmal 32 Akkus geordert. Die waren auch grad Günstig Also Abwärme hab ich ned wirklich viel ;-) Oder was meinst damit?

[christian1980nrw]

Naja, ich meine damit das die Ladeverluste bei der Kalkulation des Economic Check eventuell reduziert werden können falls die Multiplus und Akkus im Haus eingebaut sind. Die Abwärme wird ja dann genutzt. Dementsprechend öfter laufen die dann wirtschaftlich. Anders als z.B. bei mir wo sie in der Garage sind.

[christian1980nrw]

@ckvsoft Vielleicht löst das Dein Problem und Du kannst mehr Preise aktivieren. Ich hab mal was gebaut für dynamisches Ziel-SOC errechnet aus dem Solarwetter. https://github.com/christian1980nrw/Spotmarket-Switcher/commit/c131a084d60d633fc0c3cac7cb7944dcbd5aff6d

[alex90alex]

ich bin auch mal wieder dabei.. :-) Ich habe mir eben mal das aktuelle Skript geladen, bekomme aber folgende Fehlermeldung:

I: Bash Version: GNU bash, version 5.0.18(1)-release (arm-ve-linux-gnueabi) I: Spotmarket-Switcher - Version 2.4.3-DEV [|] Loading...Config validation passed. I: aWATTar today-data is up to date. I: Please be patient. A delay of 7 seconds will help avoid overloading the Solarweather-API. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 42 100 42 0 0 76 0 --:--:-- --:--:-- --:--:-- 76 date: invalid date '1970-01-01 ' date: invalid date '1970-01-01 ' controller.sh: line 541: ( - ) / 60: syntax error: operand expected (error token is ") / 60") root@raspberrypi4:/data/etc/Spotmarket-Switcher#

Könnt ihr hier weiterhelfen? Habe ich etwas übersehen? Beste Grüße Alex

[christian1980nrw]

Du hast das Solarwetter aktiviert und vermutlich keinen API Key eingetragen. Den musst Du Dir erstmal besorgen.

[alex90alex]

Perfekt das wars wohl. Werden im aktuellen Skript noch die Preise von morgen mit einbezogen? Den entsprechenden Punkt habe ich in der Config mit =1 aktiviert. Die Ausgabe anbei bezieht sich aber wohl nur auf die Preise von heute. (für eine verneinfachte Nachvollziehbarkeit der Berechnung habe ich aktuell den Verlust vom Victronsystem auf 10% gestellt.) Zu meinem System: Victron MP2 5000 und ca. 16 kWh Speicher. Falls Bedarf besteht, kann ich die kommenden 2-3 Wochen beim Testen vom Skript unterstützen. Programmieren kann ich leider nicht. ;-)

I: Current price is 0.305 EUR/kWh total price. I: Lowest price will be 0.2592 EUR/kWh total price. I: The average price will be 0.287946 EUR/kWh total price. I: Highest price will be 0.3059 EUR/kWh total price. I: Second lowest price will be 0.2598 EUR/kWh total price. I: Third lowest price will be 0.2615 EUR/kWh total price. I: Fourth lowest price will be 0.2636 EUR/kWh total price. I: Fifth lowest price will be 0.2681 EUR/kWh total price. I: Sixth lowest price will be 0.2682 EUR/kWh total price. I: Sunrise today will be 08:04 and sunset will be 16:27. Suntime will be 503 minutes. I: Solarenergy today will be 0.8 megajoule per sqaremeter with 97.2 percent clouds. I: Solarenergy tomorrow will be 3 megajoule per squaremeter with 92.1 percent clouds. At 0.8 megajoule there will be a target-SoC of 90 set. I: Victron scheduled charging is OFF. Battery SOC is at 17 %. Charging was not executed. I: Victron discharging (ESS) is OFF. Battery SOC is at 17 %. (total_cost=0.3355 €) D: skip Fritz DECT. not activated D: skip Shelly Api. not activated

[christian1980nrw]

Im DEV funktioniert der Tag morgen momentan nicht, da einiges umgebaut wird. Siehe Text oben. Also bitte deaktivieren. Ansonsten musst Du auf die alte Version aus dem Master zurückgreifen. 10% ist leider unrealistisch, außer Du nutzt die Abwärme im Haus zum heizen und reduzierst es aus dem Grund.

[alex90alex]

Okay alles klar. Ich stelle es wieder auf 20% und lasse das Skript mal übers Wochenende laufen. Das Log-file wird aktuell nicht mehr befüllt oder? Ich würde gerne nachvollziehen, was das Skript jede Stunde berechnet/bewertet. :-)

[christian1980nrw]

...das Log landet in /tmp

[alex90alex]

Aktuell scheint die Logik so für mein Gebäude/meine Hardware noch nicht zu passen. Mit den 3 günstigen Stunden heute Nacht wurde der Akku bereits so geladen, dass ich ohne Probleme das Haus über den ganzen Tag bis zum Abend/Nacht versorgen kann. Durch das gesetzte Entladelimit von 0 wird aber gezielt das Entladen verhindert und lediglich auf die Abendstunden (21-24) gelegt. Die teuerste Stunde wäre heute jedoch von 18-19 Uhr. Möglicherweise hilft es, wenn ich das Entladelimit auf bspw. 500W erhöhe.

[christian1980nrw]

Das hat mit Entladelimit nichts zu tun. Du musst die mittlere Spalte der Matrix anders konfigurieren wenn Du möchst das zu mehr Stunden entladen wird. Es wird nach Preisen sortiert entladen, je nachdem wie viele Du aktiviert hast. Daher ist Deine Aussage oben falsch.

[christian1980nrw]

@alex90alex @ckvsoft Ich habe im DEV gerade eine neue Version 2.4.4-DEV hochgeladen, bei der die Preise des Folgetages wieder funktionieren sollten. In der Config gibt es für die 48 Stunden nun eiine zweite Matrix die verwendet wird sobald diese am Nachmittag vorliegen. Im Code gibt es einige Verbesserungen, ob alles wie bisher funktioniert, müsste noch getestet werden.

[christian1980nrw]

...also ich hab schon was gefunden. Wenn die jeweiligen Preise erreicht werden, wird die jeweilige Aktion nicht ausgelöst, z.B. eingeschaltet oder geladen. Ich schaue heute Abend mal woran es liegt, kann nur eine Kleinigkeit sein.

[christian1980nrw]

So, die aktuelle DEV Version sollte nun etwas besser funktionieren. Die Ausgabe enthält nun auch Angaben zum dynamischen SOC-Ladeziel (abhängig vom Solarertrag) und den dynamischen Entladepreisen (abhängig vom Akkufüllstand).

[christian1980nrw]

...ich mache mal hier zu, da kein Feedback mehr kommt.

[ckvsoft]

Ja sorry, hatte keine Zeit zum testetn. Mir ist nur aufgefallen das bei mir die start logic nicht funktioniert hat. Gestern zb. hätte den ganzen Tag geladen werden dürfen.

[christian1980nrw]

@ckvsoft Du hast Recht, habe es heute mal ausprobiert und einen neuen Issue aufgemacht. Ich bin leider schon seit Wochen krank, daher läuft aktuell recht wenig an diesem Projekt.

EDIT: Es funktioniert doch, ich war zu schnell. Der Economic Check bricht den Ladevorgang korrekterweise ab. Wenn man ihn deaktiviert, wird auch zum start_price geladen. Issue wird also geschlossen. Was korrigiert werden müsste (ggf. baut man dafür besser einen zweiten Preis dafür in die config ein) ist, dass switching und nicht nur charging zum start_price funktioniert.

[ckvsoft]

Ja ich komm ja einstweilen auch zu nix. Ich würde es so sehen das für mich der Start Preis vorang hat und nicht der economic check. Bei Preisen der letzten Tagen hat der gar keinen Sinn. Zu den Preisen darf er den ganzen Tag vom Netz leben und den Akku voll halten

[christian1980nrw]

Ich nutze die Bruttopreise aus der Tibber App, da ist der Check schon realistischer, da die Steuern und Abgaben die Schwankungen erhöhen. Ich überlege die anderen APIs auch optional auf Bruttopreise umzustellen. Bei mir steht der Check außerdem auf highest_price. Leider sind die Preisschwankungen tagsüber oft zu klein, so das sich das Laden des Akkus aus dem Netz nur selten lohnt.

[christian1980nrw]

@ckvsoft Die aWATTar API habe ich jetzt mal auf Bruttopreise umgebaut. Entso-E bleibt erstmal auf ToDo. Tibber hat letzte Zeit ihre API erst sehr spät aktualisiert, deshalb gibts dann jetzt ein Fallback auf die aWATTar API, falls die Preise 13 Uhr nicht vorliegen. Siehe "2.4.6-DEV"

[ckvsoft]

Ich denke mal das unsere Ansichten wann geladen werden darf sehr weit auseinander liegen. Switching ist mir egal, wüsste nicht was ich damit schalten möchte.

Ich frage mich warum bei niedrigen preisen von 0,2 Cent ein laden keinen Sinn machen soll weil die economy Berechnung das anhand des höchsten preisen das sagt und auf der anderen Seite ein preis von 4 oder auch mehr cent dann ökonomisch ist nur weil der Höchstpreis weit darüber liegt? Ich bin der Meinung das ein von mir festgelegter Startpreis den Vorrang haben sollte und der economy check dann evtl. gegen diesen checken soll.

Ob das ganze Netto oder Brutto ist hat da nicht viel zu tun. Wenn Brutto genommen wird dann setzte ich meine Preisangaben in der Config ja auch als Brutto ein.

[christian1980nrw]

Ich denke mal das unsere Ansichten wann geladen werden darf sehr weit auseinander liegen. Switching ist mir egal, wüsste nicht was ich damit schalten möchte.

Bei mir läuft eine Warmwasserwärmepumpe meist nachts damit.

Ich frage mich warum bei niedrigen preisen von 0,2 Cent ein laden keinen Sinn machen soll weil die economy Berechnung das anhand des höchsten preisen das sagt und auf der anderen Seite ein preis von 4 oder auch mehr cent dann ökonomisch ist nur weil der Höchstpreis weit darüber liegt? Ich bin der Meinung das ein von mir festgelegter Startpreis den Vorrang haben sollte und der economy check dann evtl. gegen diesen checken soll.

Also wenn die Preisschwankungen tagsüber z.B. nur 20% sind und die Ladeverluste schon darüber liegen... dazu kommen noch die battery_lifecycle_costs, dann verbrauche ich den Strom doch lieber ganz normal.

Ob das ganze Netto oder Brutto ist hat da nicht viel zu tun. Wenn Brutto genommen wird dann setzte ich meine Preisangaben in der Config ja auch als Brutto ein.

Doch, bei Bruttokalkulation bzw. total costs fallen die battery_lifecycle_costs nicht so stark ins Gewicht und der economc check kommt ggf. eher zu einer positiven Bewertung. Bei uns sind seit diesem Jahr alleine die Steuern und Abgaben bei 20 Cent...

Gruß! Christian

[ckvsoft]

Ich denke mal das unsere Ansichten wann geladen werden darf sehr weit auseinander liegen. Switching ist mir egal, wüsste nicht was ich damit schalten möchte.

Bei mir läuft eine Warmwasserwärmepumpe meist nachts damit.

Im Sommer fällt das nicht ins Gewicht und im Winter läuft die Wärmepumpe so und so mehrmals am Tag/Nacht. a bringt ein Switch nix.

Ich frage mich warum bei niedrigen preisen von 0,2 Cent ein laden keinen Sinn machen soll weil die economy Berechnung das anhand des höchsten preisen das sagt und auf der anderen Seite ein preis von 4 oder auch mehr cent dann ökonomisch ist nur weil der Höchstpreis weit darüber liegt? Ich bin der Meinung das ein von mir festgelegter Startpreis den Vorrang haben sollte und der economy check dann evtl. gegen diesen checken soll.

Also wenn die Preisschwankungen tagsüber z.B. nur 20% sind und die Ladeverluste schon darüber liegen... dazu kommen noch die battery_lifecycle_costs, dann verbrauche ich den Strom doch lieber ganz normal.

Ja schon. Nur wenn der akku leer ist bringt mir das auch nix wenn ich dann zu teuren Stunden keinen Akku habe und erst den teuren Strom nutzen muss.

Ob das ganze Netto oder Brutto ist hat da nicht viel zu tun. Wenn Brutto genommen wird dann setzte ich meine Preisangaben in der Config ja auch als Brutto ein.

Doch, bei Bruttokalkulation bzw. total costs fallen die battery_lifecycle_costs nicht so stark ins Gewicht und der economc check kommt ggf. eher zu einer positiven Bewertung. Bei uns sind seit diesem Jahr alleine die Steuern und Abgaben bei 20 Cent... Bei aWATTar kann man das so und so nicht mit absoluten Werden berechnen. Das kommt ja immer am aktuellen Strompreis an weil ja hier abgaben in % vom aktuellen Preis dazu gerechnet werden.

Gruß! Christian

battery_lifecycle_costs sind für mich mal egal. Habe den economy check jetzt abgeschaltet. Verwnde nur noch startpreis und die matrix (noch die erste Version)

[christian1980nrw]

Ich denke mal das unsere Ansichten wann geladen werden darf sehr weit auseinander liegen. Switching ist mir egal, wüsste nicht was ich damit schalten möchte.

Bei mir läuft eine Warmwasserwärmepumpe meist nachts damit.

Im Sommer fällt das nicht ins Gewicht und im Winter läuft die Wärmepumpe so und so mehrmals am Tag/Nacht. a bringt ein Switch nix.

Wenn ich sie nachts zum günstigsten Preisen laufen lasse, verbraucht sie tagsüber nichts oder deutlich weniger.

Im Sommer kannst Du mit der Wetter-API beeinflussen über die Parameter abort_solar_yield_today=10.0 abort_solar_yield_tomorrow=15.0 abort_suntime=700 ...dann geht sie nur zu den üblichen Bereitstellungszeiten an, die bei mir zu den Zeiten programmiert sind wo am meisten Sonnenertrag zu erwarten ist.

Ich frage mich warum bei niedrigen preisen von 0,2 Cent ein laden keinen Sinn machen soll weil die economy Berechnung das anhand des höchsten preisen das sagt und auf der anderen Seite ein preis von 4 oder auch mehr cent dann ökonomisch ist nur weil der Höchstpreis weit darüber liegt? Ich bin der Meinung das ein von mir festgelegter Startpreis den Vorrang haben sollte und der economy check dann evtl. gegen diesen checken soll.

Also wenn die Preisschwankungen tagsüber z.B. nur 20% sind und die Ladeverluste schon darüber liegen... dazu kommen noch die battery_lifecycle_costs, dann verbrauche ich den Strom doch lieber ganz normal.

Ja schon. Nur wenn der akku leer ist bringt mir das auch nix wenn ich dann zu teuren Stunden keinen Akku habe und erst den teuren Strom nutzen muss.

Mir ist es egal wenn der Akku mal mehrere Tage nicht verwendet wird. Ist zwar schade, aber es lohnt sich oft einfach nicht.

Ob das ganze Netto oder Brutto ist hat da nicht viel zu tun. Wenn Brutto genommen wird dann setzte ich meine Preisangaben in der Config ja auch als Brutto ein.

Doch, bei Bruttokalkulation bzw. total costs fallen die battery_lifecycle_costs nicht so stark ins Gewicht und der economc check kommt ggf. eher zu einer positiven Bewertung. Bei uns sind seit diesem Jahr alleine die Steuern und Abgaben bei 20 Cent... Bei aWATTar kann man das so und so nicht mit absoluten Werden berechnen. Das kommt ja immer am aktuellen Strompreis an weil ja hier abgaben in % vom aktuellen Preis dazu gerechnet werden.

Also die neueste Version errechnet aus den aWATTar Nettopreisen nun fast identische Bruttopreise wie die Tibber App liefert (Tibber stellt Brutto und Nettopreise bereit), nur noch um ein paar Kommastellen genauer. Kontrolliert habe ich das mit den DE Preisen. Bei uns kommt Mehrwertsteuer auf den Börsenstrompreis und außerdem ohne Mehrwertsteuer noch Fixkosten über den Parameter energy_fee.

Gruß! Christian

Gruß! Christian

battery_lifecycle_costs sind für mich mal egal. Habe den economy check jetzt abgeschaltet. Verwnde nur noch startpreis und die matrix (noch die erste Version)

[christian1980nrw]

@ckvsoft Wenn Du noch eine ältere Version verwendest und parallel die Wetter-API nutzt, empfehle ich Dir zumindest diesen Patch einzuspielen. Das dynamische Ladeziel wurde falsch berechnet wenn der erwartete Solarertrag zu klein war, also außerhalb der Matrix lag. https://github.com/christian1980nrw/Spotmarket-Switcher/commit/585b8fee593b6d4da61d111c096f4342802d4cea