Ideensammlung: Netzladen nächster Schritt

[naltatis]

Inzwischen haben wir die Funktion "Netzladen für Hausbatterie" für viele Systeme integriert. Wir sind bewusst mit einem sehr einfachen und bereits bekannten Mechanismus gestartet (feste Preisschwelle). Damit können wir erst einmal Erfahrungen sammeln und schauen, ob die einzelnen Implementierungen auch alle funktionieren. Zudem lassen sich über diesen Mechanismus auch externe Automatisierungen via API relativ gut umsetzen.

Es gab schon einiges an Feedback (Github, Slack, Sticker-Feedback, ...) und Ideen, wie man die Funktion noch erweitern und besser nutzbar machen kann. Ich mache hier mal einen dedizierten Thread auf, in dem wir diese Ideen sammeln und bündeln können. Hier stichpunktartig die Ideen, die ich noch im Kopf habe.

• relatives Preislimit Tibber: Support smartcharging by relative price level #10848
• einmaliges Preislimit (eingestelltes Limit verfällt nach Zeit x) Netzladen: Nur einmalig ausführen #16361 Günstiges Netzladen Dynamische Stromtarife / Reset Filter nach Ausstecken #16673
• zeitbasiert (bspw. immer in den günstigsten 2 Stunden pro Nacht laden)
• Ladeziel/-plan für Hausbatterie (bspw. morgen 8 Uhr zu 80 %)
• Laden abhängig von Produktions- und Verbrauchsprognose (fester Algorithmus)
• Schnittstelle/Plugin für Optimierungsalgorithmus (bekommt historische Verbrauchsdaten und Prognosen, gibt Ladeplan zurück). Entweder als externe Schnittstelle oder als embedded Code (analog JavaScript- und Go-Plugins heute)

Disclaimer: Da uns wichtig ist, die Einstellungsmöglichkeiten nicht zu technisch und kompliziert werden zu lassen, werden wir nicht alle Ideen umsetzen können und wollen. Einige Szenarien werden mit externer Unterstützung (via API) abgebildet werden müssen.

[wiwimaster]

Ich hätte dazu noch eine Idee (vielleicht hast du sie auch implizit so gedacht), die eng mit dem Punkt #16367 zusammenhängt: mit den dynamischen Stromtarifen hast du eine weitere Bezugsquelle für Strom, die gleichermaßen wie die PV Erträge miteinbezogen und je nach Bedarf priorisiert werden müsste. Das bedeutet, dass du die einzelnen Punkte, die du genannt hast (und zu denen mir auch kein weiterer einfällt) teilweise kombinieren müsstest, um zum gewünschten Ergebnis zu kommen.
Also bspw.

Lade nachts zwischen 0-5 Uhr mit deinem günstigen Stromtarif den Akku auf 30% voll, aber nicht mehr, weil deine Produktionsprognose sagt, dass du ab 12 Uhr Sonne hast, die dir weitere 70% volllädt.

Macht das Sinn?

[Ak11rA]

Wir haben keine Prognose.

Würde aber Sinn machen, eine zu haben, oder? Zum Beispiel: https://swagger.forecast.solar. Heute zum Beispiel hat evcc unsere Hausbatterie vormittags vollgeladen, weil der Preis unter der eingestellten festen Schwelle lag, und jetzt scheint die Sonne und wir speisen den eben gekauften Strom wieder ein.

[naltatis]

Ja, zu dem Thema gibts auch bereits nen Proof of Concept: #9454

[EIBHomeControl]

Ich finde den Ansatz auch interessant. Ich habe diesen fast so aktuell mit Nodered umgesetzt. Wird laden die Batterie zwischen 0 und 7 Uhr auf einen einstellbaren SOC. Es wird autom. der günstiges Tarif bestimmt (Tibber). Die restliche Zeit läuft über forecast.solar automatisch.

[ruffieuxh]

Hallo zusammen,

Ich habe mir im Frühling eine eigene 35kWh Batterie gebaut mit einem GEN24 WR vorne dran. Anbieter ist Groupe-e in der Schweiz.

Ich war gerade daran, eine eigene Logik für die Nachtladung meiner Batterie zu entwickeln und testen, als ich vom Stromanbieter auf evcc aufmerksam gemacht wurde. Also, sofort installiert und getestet.
Die Funktion gefällt mir schon ganz gut aber wie @wiwimaster bereits erwähnt hat, müsste die Logik noch etwas schlauer werden und sowohl den jeweils aktuellen Ladestand der Batterie sowie auch die Wetterprognose des Folgetages berücksichtigen.

Ich bin kein prof. Programmierer, habe mir dazu aber bereits eine Idee in Java Script erstellt (bei Interesse verfügbar). Folgende Logik:

• Ich prüfe Anhand des Tarifs des Folgetages die Preise um die Mittagszeit (typ. 13-15Uhr). Wenn diese tief sind (in meinem Fall tiefer als der Nachttarif) gehe ich davon, dass der PV Ertrag gut sein wird und somit lade ich die Batterie nur zu 30% aus dem Netz. Andernfalls lade ich sie zu 50% aus dem Netz

• Je nach Ladestand der Batterie und dem Nachladebedarf von oben prüfe ich dann im Tarif die günstigsten Anzahl Perioden im Tarif, welche meinen Bedarf an Energie erfüllen.

-Wenn der Tarif extrem tief (zu definieren) ist, müsste man einen anderen Ziel SoC definieren können.

Ich hoffe, das ist einigermassen verständlich. :-)

[cschlipf]

Warum verwendest Du da nicht HomeAssistant? Da hast Du alles was Du dafür brauchst.

[mabasger]

Auch ich nutze das Feature. Tausend Dank dafür und es klappt 1A!

Als Quick Win sehe ich #16361 und würde den Request stark unterstützen wollen.

Es gibt imho einige nette Regeln, die auch ohne komplexe Prognosesysteme von EVCC abgebildet werden können:

1. Bestimmen, wie viel geladen werden soll: beim jetzigen Netzladen kann ich die Preisgrenze setzen. Ich würde aber auch gerne angeben, wie viel Strom ich in der Zeit laden möchte. z.B. ich will max 3kWh Strom kaufen. Das ist ne ziemlich plumpe und einfache Regel, kann dann später entfallen wenn EVCC mit KI Prognosen macht :-) Aber ich weis in etwa, wie viel Strom ich kaufen muss, um bis zur Sonne durchzuhalten.
2. Wert meines gespeicherten Stroms anzeigen: EVCC berechnet schon den Wert des geladenen Stroms für das Auto. Das sollte auch für den Hausakku gehen. Unter "Hausbatterie" könnte mir angezeigt werden, wie viel mein Strom im Akku durchschnittlich wert ist - inklusive der Ladeverluste. Das wäre wichtig für meine manuellen und auch für spätere EVCC-automatisierte Entscheidungen
3. Easy rule für hohe Einspeisevergütungen: wenn Tarif <= Vergütung, dann wird der Akku geladen
4. Wertvollen Batteriestrom sparen wenn Netzstrom billiger ist: wenn Tarif <= Wert des geladenen Stroms, dann wird die Batterie gesperrt, es gibt keine Entnahme des Stroms, weil er teurer ist, als der Netzstrom
5. halte in der Nacht Strom zurück für teure Zeiten: ich konfiguriere meinen erwarteten Verbrauch je Stunde (das könnte EVCC dann später mal selbst lernen) und wie viele Stunden nach Sonnenaufgang meine PV idR die Hausversorgung übernimmt (das kann dann später EVCC mit Prognose auch tun). EVCC berechnet, ob der Strom bis zur Übernahme durch die PV reicht. Ja? Alles in Butter. Nein? Dann reserviert EVCC für die teuerste Zeit den Strom der Batterie. Beispiel: 5-6 Uhr sind 37 Cent? Also lege ich mal 0,5 kWh für die Zeit zurück und sperre rechtzeitig die Batterie, so dass auf jeden Fall von 5-6 Uhr 0,5 kWh da sind.
6. Optimierung der Nachtfahrt / einfache Verbrauchsprognose: Szenario: ich habe am Abend ne Gans gemacht und fünf Kuchen. Akku also schon ziemlich down. EVCC hat dank (5) meine Batterie schon gesperrt, weil am Morgen der Strom aus dem Netz teuer ist. Der Haushalt fährt also komplett vom Netz. Jetzt hat EVCC also 0,5 kWh für 5-6 Uhr reserviert, weil es da ja 37 Cent kostet. Aber das war's dann auch. Für 4-5 Uhr ist nicht mehr genügend da, und der Strom kostet da 36 Cent. Aber... um 1-2 Uhr kostet er nur 22 Cent. Plus Ladeverluste von 10% also 24,2 Cent, das ist günstiger als 36 Cent, also werden 0,5 kWh geladen, um von 4-5 Uhr zu kommen.

Warum (6)? Warum keine volle Prognose? Weil es weniger komplex ist. Eine Prognose mit Eigenproduktion nach Wetter ist komplexer als ein Szenario, bei dem alle Variablen schon vorliegen. (6) ist also recht dumm, aber bringt uns über den regelmäßig hohen Morgenpreis.

[andig]

Die Punkte sind eigentlich alle recht "dumm" und könnten durch Prognose ersetzt werden.

[naltatis]

@andig lass uns hier doch erstmal Ideen sammeln - ohne Bewertung und Aufwandsschätzung.

[c1olli]

Ich würde gerne unabhängig von einem Tarif laden.
Menge, Ladeleistung und Zeit frei wählbar.
Z.B. für Tarife mit günstigem Nachtstrom.

[naltatis]

Magst du das etwas ausführen?

Meine Interpretation: Du hast einen Tarif mit zeitabhängigen Preisen (Tag/Nacht), möchtest aber manuell bestimmen, wann geladen wird, da es nur zwei Preisstufen gibt und der aktuelle Preislimit Mechanismus zu grob ist. Richtig?

[c1olli]

Es gibt ja Tarife mit Nacht- und Tagstrom, die sich nicht wie Tibber und co. an den Strommarkt halten und entsprechend lässt sich darauf nicht verweisen.
Also wäre es hier schön zu sagen "Mein Tarif hat von 22-06 Uhr die günstige Phase und da will ich 10 kWh mit max. 5000W laden."

[mr42hh]

Zeitabhängige Preise kann EVCC doch auch prima abbilden:
https://docs.evcc.io/en/docs/devices/tariffs#time-based-electricity-price

[benesolar]

Mein Vorschlag ist Netzentladen!
Daher abgesehen von den Preislimits alle Funktionen vom ersten Post.

Hintergrund ist die Verwendung bei Energiegemeinschaften um die Mitglieder auch Nachts mit Photovoltaikstrom zu versorgen.

[VolkerK62]

ich hab da nur gefährliches Halbwissen, aber da gibt es wohl aktuell noch gesetzliche/bürokratische/regulatorische Hürden

[benesolar]

Ich beziehe mich auf Österreich.

Bürgerenergiegemeinschaften dürfen Energie erzeugen, speichern, verbrauchen und verkaufen.

Ich bin Betreiber einer solchen und habe das auch laufen.
Momentan leider mit einem fixen Einspeisewert da Fronius nicht mehr Einstellmöglichkeiten bietet.

[andi0b]

In Kombination mit dynamisch bepreisten Einspeisetarifen wäre das besonders interessant (https://www.smartenergy.at/smartcontrol).

Sowohl eine Einspeisesperre bei negativen Marktpreisen. Als auch eine maximale Einspeisung aus dem Akku bei hohen Preisen. Oft sind die Preise morgens von 6-8 Uhr hoch, da sollte man den Akku am besten komplett ins Netz entladen.

[endurance1968]

Ich nutze das in Kombi mit Victron DESS. D.h. dynamische Preise und entsprechendes Lades des Haus-Akkus erledigt Victron schon für mich. Mir würde es deshalb schon reichen die maximale Ladeschwelle beim Netzladen beieinflussen zu können (aktuell sind das wohl 95% hart codiert oder?). Ich würde das bei mir etwas runter setzen, damit ich 1. noch mehr luft für PV am Tag habe und 2tens Victron dann schon nachlädt wenn es anhand der Preisdifferenz Sinn macht. Aktuell habe ich das Preislevel extrem niedrig angesetzt, so das EVCC maximal am Wochenende zum Zuge kommt (15C/kWh), da macht das auf 95% Laden dann auch (finanziell sinn, selbst wenn Autos später in der Woche damit geladen werden).
Evtl. kann man die Preisschwelle auf einem Prozentwert vom maxi oder minimum der Durschnittskosten berechnen lassen. Dann braucht man das nicht saisonal etc. manuell anpassen - dass macht es aber für die Nachvollziehbarkeit evtl. etwas kompliziert. Ich persöhnlich habe kein Problem das einmal im Monat manuell zu justieren.
Schön wäre es auch wenn man die Tibberpreis noch anpassen könnte damit es mit den restlichen Preisen passt. bei mir immer 2-3cent in EVCC zu niedrig. Oder kann man dem Preis schon einen offsett geben?

[CHB68]

Das geht doch in der Konfiguration unter Advanced Settings kann ich optional [maxsoc] einstellen. Dann lädt evcc nur bis zu der Grenze. In der Doku findest du das hier:

meters:
  - name: my_battery
    type: template
    template: victron-energy
    usage: battery
    host: 192.0.2.2 # IP-Adresse oder Hostname
    port: 502 # Port (optional)
    capacity: 50 # Akkukapazität in kWh (optional)
    minsoc: 25 # Ladung mit maximaler Geschwindigkeit bis zu dem angegeben Ladestand unabhängig PV-Erzeugung, wenn der Lademodus nicht auf 'Aus' steht (optional)
    maxsoc: # optional

[CHB68]

Eine Diskussion zum Victron DESS will ich hier nicht anfangen (gehört hier nicht her) aber ich habe das jetzt wieder deaktiviert und freue mich, wenn den Steuerung über evcc weiter ausgebaut wird.
Mir fehlt eigentlich nur noch eine allgemeine Entladesperre, die ich wie die Ladung über die dynamischen Strompreise festlegen kann. Bei Strompreisen unter einem individuellen Wert soll die Batterie nicht entladen werden. Ich spare dann die Ladung für die Preisspitzen.

[endurance1968]

Das geht doch in der Konfiguration unter Advanced Settings kann ich optional [maxsoc] einstellen. Dann lädt evcc nur bis zu der Grenze. In der Doku findest du das hier:

meters:
  - name: my_battery
    type: template
    template: victron-energy
    usage: battery
    host: 192.0.2.2 # IP-Adresse oder Hostname
    port: 502 # Port (optional)
    capacity: 50 # Akkukapazität in kWh (optional)
    minsoc: 25 # Ladung mit maximaler Geschwindigkeit bis zu dem angegeben Ladestand unabhängig PV-Erzeugung, wenn der Lademodus nicht auf 'Aus' steht (optional)
    maxsoc: # optional

OK werde ich ausprobieren. Unter https://docs.evcc.io/docs/reference/configuration/meters habe ich nichts dazu in der docu gesehen. Advanced settings wo? Suche in der Docu nach maxsoc hat nichts ergeben.

[CHB68]

https://docs.evcc.io/docs/devices/meters#energy

[endurance1968]

Ah OK, dachte in der reference wäre immer alles, aber da gibt es dann wohl für bekannte geräte noch immer erweiterungen die nicht in der Reference direkt stecken. War mit so nicht bewusst.
Schade das die Suche da nicht wirklich greift (aber das ist anderes Thema)

[XHalamaX]

Es wäre hilfreich, wenn ich innerhalb der nächsten 24-36 Stunden eine genaue Uhrzeit und eine Ladezeit in Minuten einplanen könnte. Oft entscheide ich abhängig von Faktoren wie Strompreisen, Wetter, Wochentag, Ladeverlusten und aktuellem Ladestand, ob ich noch ein paar kWh nachladen sollte. Momentan bin ich jedoch auf das Laden in ganzen Stunden beschränkt, was je nach Preisentwicklung suboptimal ist.

Hilfreich beider Planung wären:

• Preisanzeige,
• Steigerung des Ladezustands in Prozent oder kWh,
• ein PV-Forecast

Bei fast allen Vorschlägen muss man ohnehin täglich Anpassungen vornehmen, um "Fehlladungen" zu vermeiden. Ich könnte mir vorstellen, dass diese Ladephasen zukünftig automatisiert ermittelt werden, aber das könnte schnell sehr komplex werden. Persönlich finde ich die Ansätze von Andreas Schmitz (bekannt als "Der Akku Doktor") recht vielversprechend. Hier sind die Links zu seinem Projekt und einigen
GitHub: https://github.com/Akkudoktor-EOS/EOS
YouTube: https://www.youtube.com/watch?v=sHtv0JCxAYk / https://www.youtube.com/watch?v=ki6PziTq-8g

Ich bin mir nicht sicher, ob ihr das Projekt kennt...es befindet sich noch in einer frühen Entwicklungsphase, aber eine Schnittstelle zu einem späteren Zeitpunkt wäre vermutlich besser als sich eine "halbgare" Automatisierung selbst zu überlegen.

[XHalamaX]

Ich habe per Node-RED EOS und EVCC verbunden. Der Node-Red Flow ist noch nicht ideal und ich muss bei der Zeitumstellung sicherlich nochmal nachjustieren aber es geht soweit. Falls jemand Interesse hat einfach melden oder mitmachen. Das ist natürlich alles noch nicht ganz durchgetestet.

https://github.com/XHalamaX/EOS-EVCC-Node-Red-Integration
https://github.com/Akkudoktor-EOS/EOS

[bindaandi]

Ich würde auch eine Entladesperre für die Hausbatterie bei günstigen Netz-Strompreisen vorschlagen!. Ich hatte heute den Fall dass ich die Batterie mit günstigen Netzstrom geladen hatte um die teuren Abendpreise abzudecken. Allerdings hat mir der Trockner (bei noch günstigen Preisen) die Batterie schon wieder tagsüber leer gemacht!

[drahdiwaberl]

ein Gedanke mit dem ich in dem Zusammenhang schon öfter gespielt hab: wieviel ist denn der Strom der gerade im Akku ist eigentlich wert? was hat es gekostet ihn zu laden? das wär eigentlich die Metrik die man bräuchte um zu entscheiden ob man jetzt den Strom aus dem Akku zieht oder für später (Morgenspitze) aufbehält - aber auch ob man jetzt billig vom Netz lädt oder die Kapazität für den PV-Überschuss frei hält.

Geht natürlich ganz klar alles Richtung gesamtheitliches Energiemanagement, wo ich aber der Meinung bin dass evcc durchaus Potential für hätte.

[bindaandi]

wie ich weiter oben schon mal geschrieben habe bin ich der Meinung dass sich der Wert des Batterieinhaltes nicht aus dem wie er geladen wurde bestimmt sondern wie ich ihn verwende. Also ob es mir gelingt eine teure Netzstromphase zu überbrücken, oder ob er in einer relativ günstigen Phase entleert wird. Das läuft dann alles auf eine Verbrauchsprognose hin ...

[drahdiwaberl]

guter Punkt - widerspricht sich aber nicht denk ich. Am Beginn dieses Threads gings um die Wichtigkeit einer Entladesperre - wo ich absolut d'accord bin.

Die Herausforderung wird aber sein zu entscheiden wann diese aktiviert werden soll und auf der anderen Seite genauso wann (aus dem Netz) geladen werden soll. Also wann ist es günstig (!=billig).

Von mir im letzten Post auch nicht fertig gedacht bzw. formuliert: der Wert der Ladung im Akku muss (und sollte wohl) nicht nur von den monetären Kosten des Ladens abhängig sein. Das ist nur ein Faktor. Ein weiterer wäre natürlich der Zeitpunkt. Wenn ich um 5 Uhr früh noch 20% habe und weiss dass ich damit über die Morgenspitze komme(*) dann ist mir die Ladung natürlich massiv mehr wert als um 11 - wenn danach die 5 billigsten Stunden des Tages (und vielleicht auch noch PV) kommen. Da würd ich die (evtl. sogar "teure") Ladung vielleicht sogar gern loswerden um für PV Platz zu machen, der Wert könnt dann also sogar ins Minus gehn (analog dynamische Strompreise)

Diesen "Wert der Ladung" aus verschiedenen Faktoren zu jedem Zeitpunkt berechnen zu können - und wahrscheinlich wegen der Vergleichbarkeit idealerweise auf ct/kWh umzulegen - wär vielleicht ein Ansatz um das zu lösen. Bräuchte aber sicher noch viele Faktoren an die ich/wir noch gar nicht denken.

(*) und ja - wie weiss ich "wie weit" ich mit der Akkuladung komm. Sicher wär da eine Verbrauchsprognose gut, aber vorher ist es vielleicht auch noch eine Frage der Entladestrategie. Meine Strategie ist zB. vorrangig "Grundlastabdeckung" - und diese ist bekannt. Wenn also (Beispiel oben) um 5 Uhr früh noch die Wärmepumpe laufen muss bekommt die keine Leistung mehr aus dem Akku ("ist mir zu viel wert") - bei Wechselrichtern die die Entladeleistung nicht regeln können wär das also wohl Entladesperre.
(edit: und auch diese Strategie könnte/sollte ein Faktor für den aktuellen "Wert" der Ladung sein)

[Schelfengerch]

ich denke, dass mit dem Batterie-schonen ergibt sich von selbst... Will ich den Strom monatelang aufheben, weil ich ihn irgendwann mal teuer eingeladen habe? Der Speicher soll doch laufend arbeiten um auf kurze Sicht die Preisspitzen abzufangen!?!

Für mich wäre folgende Reihenfolge logisch:

1. Verbrauchsprognose erstellen (täglich nach Bekanntgabe der Strompreise für den nächsten Tag)
2. Erzeugungsprognose erstellen PV
3. Feststellung: muss absehbar aus dem Netz geladen werden?
4. wenn ja, wie sind die Preise in den nächsten Stunden? wenn nein, alles entspannt
5. Welcher Verbrauch ist in den nächsten Stunden prognostiziert
6. Wann sind die Preisspitzen?
7. Ist genügend Strom im Akku um die Spitzen abzufangen?
8. wenn nein, Ladeplanung zu möglichst günstigen Zeiten mit ggf. mehreren Beladungsfenstern

Wenn der Akku in den günstigen Zeiten lädt, wird er ja schonmal nicht entladen und der aktuelle Verbrauch läuft auch günstig aus dem Netz.
Lastmanagement sollte dann zuverlässig funktionieren, da ggf. auch die Ladevorgänge der Autos anspringen und somit Wallbox(en), PV-Speicher, Wärmepumpe und der Hausverbrauch zusammenkommen könnten - nicht dass mal die Hauptsicherung fliegt ;-)

[jove01]

   Wenn der Akku in den günstigen Zeiten lädt, wird er ja schonmal nicht entladen und der aktuelle Verbrauch läuft auch günstig aus dem Netz.

Wie steuert EVCC denn diese Sperre? Ich kann bei meinem Sungrow SH10RT keinen Parameter erkennen, der dafür verantwortlich ist. Oder ist das die interne Logik der WR "Wenn am Laden, dann ..." ?

[Schelfengerch]

Ab April 2025 kommen neben den variablen Strompreisen auch variable Netzentgelte für steuerbare Verbrauchseinrichtungen:

Zitat FAQs zum 14AEnWG Bundesnetzagentur:
Gemäß unserer Festlegung muss der Netzbetreiber ab April 2025 Verbraucherinnen und Verbrauchern ein zeitvariables Netzentgelt im Sinne von Modul 3 anbieten. Das Modul 3 kann nur in Kombination mit Modul 1 ausgewählt werden. Vorgesehen sind mehrere Zeitfenster mit drei Preisstufen der örtlich geltenden Netzentgelte (HT / NT / ST). Die Zeitfenster und Preisstufen werden kalenderjährlich festgelegt, gelten für das gesamte Netzgebiet und müssen in mindestens zwei Quartalen eines Jahres abgerechnet werden.

Folglich wären ab April zusätzlich zu den variablen Strompreisen auch die drei Preisstufen des jeweiligen örtlichen Versorgers eine weitere wichtige Preiskomponente, die bei der Beladung des Hausspeichers/eAutos mit berücksichtigt werden muss.

Weiter könnte der Strompreis direkt von der Leipziger Börse eex (also ohne "Umweg" über Anbieter A/B/C) gezogen werden. Da der Börsenpreis ja für alle gleich ist, würde dies die evcc-Konfiguration erleichtern und den Umstieg auf die ab April 2025 bei allen Versorgern verpflichtend anzubietenden variablen Tarifen begünstigen. evcc müsste nicht von jedem kleinen Gemeindewerk Preisinformationen integrieren... Kann man ggf. die Daten der europäischen Transparenzplattform nutzen newtransparency.entsoe.eu ?

[cschlipf]

Voraussetzung ist aber so weit ich weiß ein iMS. Den hat leider auch noch nicht jeder.

[westrandlader]

Guten Morgen,

nur als Idee. Im ersten Schritt habe ich mir ein Skript in iobroker gebastelt, welches genau das macht:

ich möchte nur die hohen Kosten in den morgen und Abendstunden überbrücken. In aller Regel pendeln sich die Preise morgens und abends ab 9h wieder auf ein Normalniveau ein. Das Skript macht nachmittags um 15h und morgens um 5h folgendes:

• Ist Akku SOC kleiner als 40%?
• wenn ja, ist die Preisdifferenz zwischen aktuell und 7.00 bzw. 18.00 Uhr größer als 20% ?(das ganz lohnt sich ja nur, wenn die Preise sehr hoch sind, Lade-/Entladeverluste etc.)
• Dann lade Akku auf 40%

Damit schaffe ich es in der Regel ganz gut über die teuren Stunden, aber vermeide dass der Akku zu voll geladen wird. Klar, auch nicht perfekt, aber pragmatischer Ansatz zur "Vermeidung von Peaks".

Variablen wären:

• Uhrzeit(en), wann geladen werden soll und mit welchen Uhrzeiten die Preise verglichen werden sollen
• Preisdifferenz, ab wann sich das lohnt (
• Unteres SOC Limit, wann geladen werden soll (bei mir unter 40%)
• Ziel SOC (wie viel brauche ich, um die teuren Stunden halbwegs zu überbrücken).

Gruß

[drahdiwaberl]

ich denke es wäre zu überlegen neben der festen Preisschwelle andere "Bewertungen" der Stundenpreise einzuführen - was dann mit aktuellem UI schon zu einer mehr "dynamischen" Planung führt.

Als Inspiration vielleicht zwei Varianten die eine HA-Integration für dynamische Strompreise nutzt - mit der ich bisher viele Automationen dieser Art in HA umsetze:

"Rank" - die Stunden nach Preis sortiert - ermöglicht also zb. "lade in den 6 billigsten Stunden"
https://github.com/mampfes/ha_epex_spot?tab=readme-ov-file#8-rank-sensor

"Quantile" - die Preise der 24 Stunden zwischen 0 und 1 gemappt - "lade in allen Stunden in denen der Preis weniger als 25% vom teuersten des Tages ist (Quantile < 0.25)"
https://github.com/mampfes/ha_epex_spot?tab=readme-ov-file#7-quantile-sensor

my2c

[mucki12]

Im Photovoltaikforum gibt es dutzende Beispiele von Usern, die das ebenfalls umgesetzt haben und aktiv nutzen. ZB auf Basis mit HA und PV System von Huawei unter Berücksichtigung des Tibber Preises, des zu erwartenden Verbrauchs und der zu erwartenden PV Erträge.

[bindaandi]

Eine Sache ist mir heute auch noch aufgefallen. Beim Netzladen der Hausbatterie wäre neben der Preisgrenze ggf. noch ein Zielladestand sinnvoll.

[jove01]

Wie hier schon mehrfach gewünscht, finde ich es auch sehr wichtig, beim Netzladen der Hausbatterie anschließend eine Entladesperre gegen den Hausverbrauch für x Stunden oder bis Preis y der Hausbatterie zu haben, damit nichts sofort in günstigen Zeiten wieder entladen wird. Sonst hätte man nichts außer Umwandlungsverlusten.

[cschlipf]

Nächtliches Entladen vor dem Morgen verhindern.

Was ich mir in HomeAssistant zusammengeklickt habe, was recht einfach ist: Nachts ab 0:00 Uhr die Entladung des Heimspeichers verhindern, wenn er unter Wert x fällt (bei mir 35%, was 15% unter der Entladegrenze von 20% sind). Morgens um 6:00 wird der Speicher wieder freigegeben, so dass er den morgendlichen Strompreispeak überbrücken kann.

Das ist auch relativ risikolos. Im schlimmsten Fall ist der Strom morgens doch nicht teuer oder die restliche Energie im Speicher wurde morgens nicht verbraucht bevor die Sonne wieder kommt. Aber Nachts scheint keine Sonne, daher kann ich gesichert sagen, dass der Speicher sich nur entleeren wird - muss also keine Prognose berücksichtigen. Und ich kaufe keinen Strom - also kein proakives Investment, da ich nur den Strom nehme, der eh schon im Speicher steckt.

Bei mir ist das recht starr mit festen Zeiten geregelt - ich komme da aber gut hin. Man könnte es aber noch besser machen in dem man den tatsächlichen Preis und auch die Zeiten des Sonnenaufganges am Morgen berücksichtigt.

OK, eigentlich ist meine Idee eher das Gegenteil von dem Netzladen, zu dem wir hier Ideen sammeln wollen.

[AlexJoda]

Eine Entladesperre ist entscheidend für sinnvolles Netzladen! Weiterhin sollten die Preisgrenzen nur ein bestimmten Zeitintervall gelten weil man das sonst ständig wieder deaktivieren muß. Ich hoffe das kommt irgendwann in EVCC ohne HA oder ähnliches nutzen zu müssen...EVCC hat absolut das Potential als alleinige Lösung für das Strommanagement zu dienen...

[rafdev18]

Ich möchte noch anregen das die Effizienz des Systems Inverter - Batterie - Inverter mit in die Ladeentscheidung einfliesst. Bei einem Verlust von 12-18% gibt es viele Tage an denen die Nutzung der Batterie aus Effizienzgründen keinen Sinn macht.

[Schelfengerch]

Da bin ich inhaltlich mit dabei. Aufgrund der AC/DC-Umwandlungsverluste müsste der von der PV erzeugte Strom (bei DC-gekoppelten Anlagen), an Tagen mit nennenswerten Erträgen und absehbaren Preisspitzen, primär in den Speicher laufen. Dies könnte ggf. durch das Nachführen des Mindestladestands des Akkus erreicht werden.

[longtom99]

Weil es gut hier rein passt und mir das heute aufgefallen ist.
Ich habe eine BWWP als Ladepunkt.
Ich möchte es generell über PV enable bei -500W starten.
ABER es soll dann EIN bleiben egal welcher Bezug bis zum eingestellten SoC/Temperatur.
Deshalb habe ich bei disable eine hohen Wert eingesetzt, das es anbleibt und nicht ein/aus taktet.

Das Problem ist das es beim günstigen Netzladen auch AN bleibt bis SoC erreicht ist, weil anscheinend der disable Paramter hier auch greift.

Ich hätte gerne eine Möglichkeit das günstige Netzladen UNABHÄNGIG vom disable Parameter zu betreiben.
Also NUR zu den ausgewählten Stunden ein und danach aus.
Eventuell als optionaler Paramter oder eigenen Auswahlpunkt zu Aus/PV/Mini+PV/Schnell?
Andere Möglichkeiten?

[premultiply]

Die momentane Abbildung von Heizsystemen auf normale Ladepunkte ist eher dem experimentellen Charakter geschuldet und wird sich sehr wahrscheinlich noch ändern.
Derzeit steht aber erstmal das komplexe Thema Konfig-UI im Vordergrund der Entwicklungsarbeit bevor neue Großbaustellen begonnen werden.

[cschlipf]

Automatischer Reset des Preislimits

Grundsätzlich bin ich dafür das Netzladen simpel zu halten. Wer mehr braucht kann HA nutzen.

Was ich mir aber wünschen würde wäre ein automatischer Reset des Preislimits. Was mir jetzt schon mehrfach passiert ist: Ich sehe am Abend, dass es nachts günstig ist und am Tag teuer - also setze ich den Preislimit. Akku lädt auf - alles toll.. wenige Tage ist es generell günstig. Und auf einmal lädt der Akku auf - weil ich vergessen habe das Preislimit nach dem letzte Laden zu löschen.

Es wäre super wenn man hier einen automatischen Reset machen könnte. Beispiel:

• Gültigkeitsdauer des Preislimits von x Stunden (z.B. 12 Std hardcodiert würde vermutlich meistens reichen)
• Reset nach Erreichen eines Zielladestandes (aktuell fehlt der noch)

[jove01]

Automatischer Reset des Preislimits

Grundsätzlich bin ich dafür das Netzladen simpel zu halten. Wer mehr braucht kann HA nutzen.

Was ich mir aber wünschen würde wäre ein automatischer Reset des Preislimits. Was mir jetzt schon mehrfach passiert ist: Ich sehe am Abend, dass es nachts günstig ist und am Tag teuer - also setze ich den Preislimit. Akku lädt auf - alles toll.. wenige Tage ist es generell günstig. Und auf einmal lädt der Akku auf - weil ich vergessen habe das Preislimit nach dem letzte Laden zu löschen.

Es wäre super wenn man hier einen automatischen Reset machen könnte. Beispiel:

* Gültigkeitsdauer des Preislimits von x Stunden (z.B. 12 Std hardcodiert würde vermutlich meistens reichen)

* Reset nach Erreichen eines Zielladestandes (aktuell fehlt der noch)

Das müsste aus HA so gehen (nicht im Einsatz, aber einmal getestet)
action: mqtt.publish data: topic: evcc/site/batteryGridChargeLimit/set payload: " {{ states('input_number.sungrow_preis_limit_netzladung') }} " alias: EVCC Netzladen aktivieren

[longtom99]

evcc plugin von HACS installieren und schon kann man viel automatisieren. :-)

[snookerap]

Kann jemand ein Beispiel einer Automatisierung in Home Assistant posten?
Könnte sicher vielen hier helfen... :-)

[cschlipf]

Hier findest Du ein paar: https://github.com/ha-puzzles/homeassistant-puzzlepieces

[longtom99]

zb hier (evcc Plugin mittels HACS), ich mache den Modus von PV auf AUS (damit ich die "Ladesesion" abgeschlossen habe) dann wieder auf PV und ich stelle den SoC/Temperatur auf 59%/Grad da nur 5er Schritte im Standard möglich sind.

[Pardasus]

Muss man das Repo Manuell über HACS runterladen? Ich finde es nicht. Bis jetzt Steuer ich evcc über HA/MQTT.

[cschlipf]

Muss man das Repo Manuell über HACS runterladen? Ich finde es nicht. Bis jetzt Steuer ich evcc über HA/MQTT.

Das Repo ist eine Sammlung von Dokumentation und Config Dateien. In erster Linie musst Du lesen.

[TobiasSt78]

Wie ist denn der Status der Umsetzung?

Ein gesteuertes "Batterie unter x EUR/kWh nicht entladen" analog zum Netzladen wäre echt traumhaft als erster nächster Schritt.

Die beschriebene Umsetzung über einen "Fake-Ladepunkt" sorgt leider auch dafür, dass der Akku trotz PV Überschuss nicht geladen wird wenn man nicht täglich die Schwellwerte anpasst.

Hat dafür jemand eine Lösung? Also entladen unter x EUR/kWh stoppen, Laden der Batterie weiter zulassen?

[VolkerK62]

Das kommt auf die Hardware an. Bei manchen Batterie-WR betrifft die Sperre nicht nur das Entladen, sondern dann auch das Laden.

[sthbto]

Ich habe inzwischen 2 Winter Erfahrung mit der automatisierten Steuerung der Batterie und dynamischen Strompreisen. Meine Erfahrung bzgl. sinnvoller Featurehübe:

Featurehub 1:

• Ich logge beim Laden der Batterie den jeweiligen Strompreis und zugehörigen SOC-Hub. Es können also mit der Zeit mehrere Preisbestandteile in der Batterie drin sein. Den PV SOC-Anteil speichere ich mit dem Preis meiner Einspeisevergütung.
• Ein Entladen der Batterie wird nur frei gegeben, wenn der Netzstrom x% teurer ist als der in der Batterie gespeicherte, um die Batterieverluste zu berücksichtigen, z.B. 30%.

Featurehub 2:

• Danach habe ich irgendwann eine PV Prognose eingebunden
• Außerdem ein Standardlastprofil meines Hausverbrauchs definiert
  Damit bin ich in der Lage die Batterie ergänzend zu Featurehub 1 nur dann freizuschalten, wenn ich den Strom nicht für eine spätere Hochpreisphase benötige

Featurehub 3:

• Ich habe das Lastprofil um die Wärmepumpe ergänzt und berechne auf historischen Werten, wann die WP das nächste mal anspringt. Meine Wärmepumpe ist keine die moduliert, sondern kann nur ein/aus

Featurehub 4:

• Ich sperre die Wärmepumpe in Hochpreisphasen und erhöhe die Betriebsweise in Niedrigpreisphasen
• Die Sperr-, Normal- und Erhöhungszeiten werden dabei im Lastprofil des Hauses für die Prognose berücksichtigt
• Das Zeiten für die WP setze ich aktuell noch komplett manuell. Die Ansteuerung erfolgt über die SG-Schnittstelle der WP (nicht evcc tauglich)

Einen sehr großen Effekt bei geringem Aufwand kann man dabei bereits mit Featurehub 1 erreichen. 2 ist z.T. recht einfach, z.B. die PV Prognose einzubinden. Das Standardlastprofil ist ein bisschen kniffeliger, da könnte man aber auch einfach über einige Wochen stundenweise den Durchschnittsverbrauch bilden. Damit holt man schon 70%+ des Möglichen, denke ich.
3 und 4 sind sicherlich spezieller und nicht so einfach übertragbar.
Wobei die benötigte Leistung einer modulierenden Wärmepumpe relativ einfach über die aktuelle Durchschnittsaußentemperatur abgebildet werden kann. Damit könnte das Lastprofil des Hauses+WP nach wie vor einigermaßen elegant berechnet werden.

Unter dem Strich bin ich mega zufrieden mit meinem Stand.
Meine Konfig:

• Homematic CCU3 mit Modbus TCP Plugin
• Fronius Symo Gen24. Da kann man die zulässige Lade- und Entladeleistung über Modbus TCP vorgeben. Funktioniert perfekt.
• PV Prognose über Solcast
• Tibber
• evcc fürs Laden der Autos (PV und Zielladen schnell)

Ich weiß leider nicht, wie einfach sich unterschiedliche Wechselrichter ansprechen lassen. Mit Fronius ist es jedenfalls sehr einfach :-)

[Wisley7]

Ich denke mit dem Algorithmus von der Preis-Soc Liste, und wie du den dann verarbeitest würde reichen.
Tibber Preise bekomme ich im IoBroker, und von dort aus steuere ich meinen alten fronius über modbus.
schon mal vielen dank

[ttjaden]

Kurze Info am Rande: Für Fronius Systeme gibt es ab Mai auch in Deutschland eine kostengünstige Lösung für optimierte Speicherbewirtschaftung: https://www.fronius.com/de-at/austria/solarenergie/eigenheim/produkte-und-loesungen/anlagen-ueberwachung/energiekosten-assistent

[Bernd2211]

Kurze Info am Rande: Für Fronius Systeme gibt es ab Mai auch in Deutschland eine kostengünstige Lösung für optimierte Speicherbewirtschaftung: https://www.fronius.com/de-at/austria/solarenergie/eigenheim/produkte-und-loesungen/anlagen-ueberwachung/energiekosten-assistent

Leider nur für Fronius Premium Kunden. Ich habe mir in der Kombi HA+evcc ein paar Regeln gebastelt, aber eigentlich wäre mir eine Lösung komplett in evcc lieber.

[sthbto]

Ich denke mit dem Algorithmus von der Preis-Soc Liste, und wie du den dann verarbeitest würde reichen. Tibber Preise bekomme ich im IoBroker, und von dort aus steuere ich meinen alten fronius über modbus. schon mal vielen dank

Hi @Wisley7 , hier das CCU Script.
Unter dem Bereiche "Systemvariablen" sind die notwendigen HM Variablen, die als Input benötigt werden. Außerdem die Variable, die am Ende ausgibt, ob der Akku gesperrt werden soll, weil kein SOC Anteil mit passendem Preis mehr gefunden wurde.
Schau mal drauf, ob du damit klar kommst ;-)

! Hier wird eine Liste erzeugt, welche den Batterie-SOC in mehrere
! Teile unterteilt. Es wird je nach Quelle der gepeicherten Energie (PV, Netz)
! der SOC Anteil inkl. des jeweiligen Preises angegeben.
! Wird Energie aus der Batterie entnommen, wird derjenige Block um die entnommene
! Energiemenge reduziert (wenn vorhanden), der entsprechend Vorgabe x% guenstiger
! als der aktuelle EPEX Preis ist. Gibt es mehrere Bloecke, welche dieses
! Kriterium erfuellen, wird derjenige genommen, der naeher dran ist.'

! Beispiel:
! [40%: 6.5 Cent; 15%: 18 Cent; 15%: 19 Cent; 15%: 22 Cent]
! Aktueller EPEX Preis: 30 Cent. Mindest Delta 50% >> Strom nehmen, der zu
! maximal 20 Cent gespeichert wurde. Es wird demnach der Strom entnommen, der
! zu 19 Cent gespeichert wurde.

! So sieht die Liste dann real aus: [Preis in Cent > SOC Anteil]: [6.40>20.40;16.84>23.40;17.32>45.10;17.44>1.80;27.20>0.50]
! ======= Systemvariablen ===============
var obj_energy_price_list = dom.GetObject("PV.Gen24.Bat_Energy_Price_Components"); ! Liste mit den SOC Anteilen inkl. Preis
! [40%: 6.5 Cent; 15%: 18 Cent; 15%: 19 Cent; 15%: 22 Cent]
var obj_pv_energyprice = dom.GetObject("PV.Gen24.Preis_PV_Strom"); ! Energiepreis, der fuer PV Strom angesetzt wird, z.B. 8.4 (in Cent)
var obj_min_price_delta = dom.GetObject("PV.Gen24.Min_Deltapreis_Speichern_zu_Entnahme"); ! Angestrebtes Preisdelta zw. Speichern und Entnahme in Prozent, z.B. 35
var obj_price_now = dom.GetObject("PV.EPEX.electricity_price_now"); ! aktueller EPEX Preis in Cent, z.B. 30.4 (in Cent)
var obj_Bat_SOC = dom.GetObject("PV.Gen24.Bat_SOC_IST"); ! Aktueller Batterie SOC
var obj_Bat_GridCharge = dom.GetObject("PV.Gen24.BatGridCharge"); ! Netzlademodus fuer die Batterie ist true oder false. WENN TRUE DANN (aktuellen EPEX Preis fuer SOC-Hub nehmen) SONST (PV-Preis fuer SOC-Hub nehmen)
var obj_Bat_EnergyPrice_DischargeLock = dom.GetObject("PV.Gen24.BatEnergyPrice_DischargeLock"); ! Entladesperre TRUE, wenn Energiepreise in Batterie zu teuer


! ======= Lokale Variablen ===============
string s_energy_price_list;
string s_energy_price_list_new;
string s_energy_price_list_new_element;
integer i_energy_price_list_length = 0;
string s_item;
integer i_index_energy_price_list;
integer i_index_price_found;
string s_energy_price_list_separator = ";";
string s_SOC_price_separator = ">";
real r_Sum_SOCs_energy_price_list = 0.0;
boolean b_price_found = false;
real r_SOC_delta;
real r_SOC_rest;
real r_EPEX_Price_now = obj_price_now.Value().ToString(2).ToFloat();
integer i_while_counter;
boolean b_Bat_EnergyPrice_DischargeLock;

s_energy_price_list = obj_energy_price_list.Value();
! s_energy_price_list = ("6.4>20.5;16.5>40.3");
! s_energy_price_list = ("6.4>20.5;16.5>20.3;23.51>5;24.11>3.00");
! s_energy_price_list = ("6.4>20.5;16.5>20.3;30.0>50.0");
! s_energy_price_list = ("16.5>20.3;30.0>70.0");

if (obj_energy_price_list && (obj_pv_energyprice && (obj_min_price_delta && (obj_price_now && (obj_Bat_SOC && obj_Bat_EnergyPrice_DischargeLock))))) {
  ! Pruefen, ob Batterie SOC > 0. Ist er null, ist es wahrscheinlich, dass
  ! die Verbindung zwischen Gen24 und CCU fehlt schlug. In diesem Fall wird
  ! der SOC in der SysVar auf 0.0 gesetzt. Daduch wuerde hier eine
  ! Entladung erkannt werden, welche nicht stattgefunden hat und bei wieder
  ! verfuegbarer Verbindung eine Ladung zum PV Preis.
  ! Da die Batterie immer eine Mindestenergiemenge von ~10% enhaelt, ist eine
  ! Pruefung auf 0.0 hier sinnvoll.
  if (obj_Bat_SOC.Value() > 0.0) {
    ! Berechnen, ob Batterie seit letzter Berechnung geladen wurde:
    ! Delta_SOC = Aktueller_SOC - Alle_SOC_Staende_der_Preisliste_addieren

    ! WENN (Delta_SOC > 0) >> Batterie wurde seit letzter Berechnung geladen
    !   DANN (1) SOC Hub muss der Liste hinzugefuegt werden. Dazu pruefen, ob es bereits diese Preis in der Liste gibt
    !     WENN (Aktueller EPEX_Preis bereits in Liste enthalten)
    !       DANN (1.1) SOC dieses Preises um Ladedelta (Delta_SOC) erhoehen
    !     SONST (1.2) (Aktuellen EPEX_Preis mit Delta_SOC der Liste hinzufuegen)
    ! SONST WENN (Delta_SOC < 0)
    !   DANN (2) Batterie wurde seit letzter Berechnung entladen

    ! ======= Summe der Eintraege der Preis-SOC Liste =======
    ! Berechnen, ob Batterie seit letzter Berechnung geladen wurde:
    ! Delta_SOC = Aktueller_SOC - Alle_SOC_Staende_der_Preisliste_addieren
    foreach(s_item, s_energy_price_list.Split(s_energy_price_list_separator)) {
      r_Sum_SOCs_energy_price_list = r_Sum_SOCs_energy_price_list + s_item.StrValueByIndex(s_SOC_price_separator, 1).ToFloat();
    }
    ! WriteLine("Batterie Ist-SOC: " # obj_Bat_SOC.Value()); ! DEBUG
    ! WriteLine("Gesamt SOC der Preis-SOC-Liste: " # r_Sum_SOCs_energy_price_list); ! DEBUG
    ! WriteLine("Aktueller EPEX Preis: " # r_EPEX_Price_now); ! DEBUG
    ! WriteLine("Alte Energie Preisliste: " # s_energy_price_list); ! DEBUG

    ! ==========================================================
    ! ======= Programmteil, wenn Batterie GELADEN wird =========
    ! ==========================================================
    ! WENN (Delta_SOC > 0) >> Batterie wurde seit letzter Berechnung geladen
    ! DANN SOC Hub muss der Liste hinzugefuegt werden. Dazu pruefen, ob es bereits diese Preis in der Liste gibt
    r_SOC_delta = obj_Bat_SOC.Value() - r_Sum_SOCs_energy_price_list;
    if (r_SOC_delta > 0.0) {
      ! (1)
      ! WriteLine("1. Es wurde geladen: " # r_SOC_delta # " %"); ! DEBUG
      b_price_found = false;
      i_index_energy_price_list = 0;
      if (!obj_Bat_GridCharge.Value()) {
        ! WENN (Batterie NICHT aus dem Netz geladen wird) DANN (EPEX_Preis = PV_Strompreis)
        r_EPEX_Price_now = obj_pv_energyprice.Value();
      }
      ! Suchen, ob aktueller EPEX Preis schon in Liste vorhanden ist
      foreach(s_item, s_energy_price_list.Split(s_energy_price_list_separator)) {
        if (s_item.StrValueByIndex(s_SOC_price_separator, 0).ToFloat() == r_EPEX_Price_now) {
          b_price_found = true;
          i_index_price_found = i_index_energy_price_list;
          ! WriteLine("Preis gefunden in Liste bei Index " # i_index_price_found); ! DEBUG
        }
        i_index_energy_price_list = i_index_energy_price_list + 1;
      }
      ! WENN (Aktueller EPEX_Preis bereits in Liste enthalten)
      ! DANN (1.1) SOC dieses Preises um Ladedelta (Delta_SOC) erhoehen
      s_energy_price_list_new = "";
      if (b_price_found) {
        ! (1.1)
        ! WriteLine("Preise gefunden"); ! DEBUG
        i_index_energy_price_list = 0;
        foreach(s_item, s_energy_price_list.Split(s_energy_price_list_separator)) {
          ! Liste durchlaufen bis zum Element mit dem gleichen Preis und dort den SOC erhoehen. Liste ansonten unveraendert lassen
          ! WENN aktuelles Listenelement das ist, das geaendert werden soll, dann aendern
          if (i_index_energy_price_list == i_index_price_found) {
            ! Das ist der Index, der angepasst werden muss
            s_energy_price_list_new_element = s_item.StrValueByIndex(s_SOC_price_separator, 0) # s_SOC_price_separator # (s_item.StrValueByIndex(s_SOC_price_separator, 1).ToFloat() + r_SOC_delta).ToString(2);
            if (i_index_energy_price_list < 1) {
              s_energy_price_list_new = s_energy_price_list_new_element;
            }
            else {
              s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # s_energy_price_list_new_element;
            }
          }
          else {
            ! SONST aktuelles Listenelement unveraendert uebernehmen
            if (i_index_energy_price_list < 1) {
              s_energy_price_list_new = s_item;
            }
            else {
              s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # s_item;
            }
          }
          i_index_energy_price_list = i_index_energy_price_list + 1;
          ! WriteLine("Neue Liste " # s_energy_price_list_new); ! DEBUG
        }
      }
      else {
        ! (1.2)
        ! WriteLine("Preise nicht gefunden"); ! DEBUG
        ! SONST Preis und SOC neu der Liste hinzufuegen
        s_energy_price_list_new_element = r_EPEX_Price_now.ToString(2) # s_SOC_price_separator # r_SOC_delta.ToString(2);
        if (s_energy_price_list != "") {
          ! Element an der richtigen Stelle der Liste einsortieren
          b_price_found = false;
          foreach(s_item, s_energy_price_list.Split(s_energy_price_list_separator)) {
            ! WENN der aktuell EPEX Preis kleiner ist als als das naechste Listenelement, muss es DAVOR eingefuegt werden
            ! WriteLine("Epex Preis < Element der Liste : " # r_EPEX_Price_now # " < " # s_item.StrValueByIndex(s_SOC_price_separator, 0).ToFloat() # " ?"); ! DEBUG
            if ((r_EPEX_Price_now < (s_item.StrValueByIndex(s_SOC_price_separator, 0).ToFloat())) && !b_price_found) {
              ! WriteLine("TRUE"); ! DEBUG
              if (s_energy_price_list_new == "") {
                ! WriteLine("Neue Liste leer"); ! DEBUG
                s_energy_price_list_new = s_energy_price_list_new_element # s_energy_price_list_separator # " " # s_item;
                b_price_found = true;
              }
              else {
                ! WriteLine("Neue Liste nicht leer"); ! DEBUG
                s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # " " # s_energy_price_list_new_element # s_energy_price_list_separator # s_item;
                b_price_found = true;
              }
            }
            else {
              ! SONST wird die Liste unveraendert aufgebaut
              if (s_energy_price_list_new == "") {
                ! WriteLine("Neue Liste leer"); ! DEBUG
                s_energy_price_list_new = s_item;
              }
              else {
                ! WriteLine("Neue Liste nicht leer"); ! DEBUG
                s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # s_item;
              }
            }
          }
          ! WENN b_price_found == false, DANN wurde das neue Listenelement nicht eingefuegt.
          ! Es ist groesser als alle Listenelemente und muss am Ende der Liste angefuegt werden
          if (!b_price_found) {
            s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # " " # s_energy_price_list_new_element;
          }
        }
        else {
          ! Die SOC Preis Liste ist leer. Neue Liste anlegen
          s_energy_price_list_new = s_energy_price_list_new_element;
        }
      }
      ! WriteLine("Alte Liste " # s_energy_price_list); ! DEBUG
      ! WriteLine("Neue Liste " # s_energy_price_list_new); ! DEBUG
      s_energy_price_list = s_energy_price_list_new;
    }
    else {
      ! SONST WENN (Delta_SOC < 0)
      if (r_SOC_delta < 0.0) {
        ! DANN (2) Batterie wurde seit letzter Berechnung entladen
        ! ===========================================================
        ! ======= Programmteil, wenn Batterie ENTLADEN wird =========
        ! ===========================================================
        ! WriteLine("2. Es wurde entladen: " # r_SOC_delta # " %"); ! DEBUG
        ! Der Delta_SOC muss von einem der SOCs aus der Liste abgezogen werden.
        ! (2.1)
        ! Dazu wird die Energie Preis Liste durchlaufen und fuer jedes Element
        ! geprueft, ob dieses geeignet ist. Geeignet ist jedes Element, dessen
        ! (Einkaufspreis + Min_Preisdelta_in_Prozent) <= AKtueller_EXPS_Preis
        ! Erfuellt ein Index das Kriterium, wird dieser gespeichert. Da die Liste
        ! bzgl. der Preise aufsteigend sortiert ist, wird automatisch das letzte
        ! preislich noch moegliche Element gefunden.
        ! (2.2)
        ! WENN (Passendes Element gefunden)
        !   DANN (Neue Liste erstellen und entsprechendes Listenelemnt editieren)
        ! WENN (Verfuegbarer_SOC_in_Liste >= ABS(Delta_SOC))
        !   DANN (Verfuegbarer_SOC_neu = Verfuegbarer_SOC_in_Liste - ABS(Delta_SOC))
        ! SONST (Listenelement ist verbraucht. Es bleibt ein r_SOC_delta uebrig, der im naechsten Schleifendurchlauf bearbeitet werden muss)
        ! (2.3)
        ! Wird kein passendes Element gefunden, muss von anderen Listenelementen der
        ! Delta_SOC abgezogen werden >>  i_index_price_found = -1

        ! WriteLine("Min. Preisdelta in Prozent: " # obj_min_price_delta.Value()); ! DEBUG
        i_while_counter = 0;
        while ((r_SOC_delta < 0.0) && (i_while_counter < 20)) {
          i_while_counter = i_while_counter + 1;
          ! WriteLine("While Schleifen Zähler: " # i_while_counter); ! DEBUG

          s_energy_price_list_new = "";
          i_index_energy_price_list = 0;
          i_index_price_found = -1; ! Wird kein passendes Element gefunden, muss von anderen Elementen der Delta_SOC abgezogen werden
          foreach(s_item, s_energy_price_list.Split(s_energy_price_list_separator)) {
            ! (2.1) Suchen des letzten passenden Elements in der Energie Preis Liste
            if ((s_item.StrValueByIndex(s_SOC_price_separator, 0).ToFloat() * (1.0 + (obj_min_price_delta.Value() / 100.0))) <= r_EPEX_Price_now) {
              i_index_price_found = i_index_energy_price_list;
              ! WriteLine("Preis gefunden in Liste bei Index " # i_index_price_found); ! DEBUG
              ! WriteLine("Preis + Mindelta <= EPEX Preis: " # (s_item.StrValueByIndex(s_SOC_price_separator, 0).ToFloat() * (1.0 + (obj_min_price_delta.Value() / 100.0))) # " <= " # r_EPEX_Price_now); ! DEBUG
            }
            i_index_energy_price_list = i_index_energy_price_list + 1;
          }
          ! WriteLine("Zu nutzender Index " # i_index_price_found); ! DEBUG


          if (i_index_price_found >= 0) {
            ! (2.2) Es wurde ein passender Index gefunden
            ! WriteLine("If für Preis gefunden."); ! DEBUG
            i_index_energy_price_list = 0;
            foreach(s_item, s_energy_price_list.Split(s_energy_price_list_separator)) {
              if (i_index_energy_price_list == i_index_price_found) {
                ! Das zu aendernde Element wurde gefunden
                ! WriteLine("ForEach Schleife: Element gefunden"); ! DEBUG
                r_SOC_rest = s_item.StrValueByIndex(s_SOC_price_separator, 1).ToFloat() + r_SOC_delta; ! Wenn Wert negativ, ist das Listenelemnt aufgebraucht
                ! WriteLine("Rest SOC: " # r_SOC_rest); ! DEBUG
                if (r_SOC_rest <= 0.0) {
                  ! Listenelemnt ist "verbraucht" und wird ignoriert.
                  ! Es verbleibt ein neuer Rest-SOC
                  r_SOC_delta = r_SOC_rest;
                  ! WriteLine("Listenelement verbraucht. Neuer Delta_SOC: " # r_SOC_delta); ! DEBUG
                }
                else {
                  ! Listenelement ist noch nicht verbraucht
                  s_energy_price_list_new_element = s_item.StrValueByIndex(s_SOC_price_separator, 0) # s_SOC_price_separator # r_SOC_rest.ToString(2);
                  ! WriteLine("Neues Preislistenelemnt: " # s_energy_price_list_new_element); ! DEBUG
                  if (s_energy_price_list_new == "") {
                    ! WriteLine("Liste leer"); ! DEBUG
                    s_energy_price_list_new = s_energy_price_list_new_element;
                  }
                  else {
                    ! WriteLine("Liste nicht leer"); ! DEBUG
                    s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # s_energy_price_list_new_element;
                  }
                  r_SOC_delta = 0.0;
                }
              }
              else {
                ! Noch nicht beim gefundenen Index angekommen. Liste einfach nur zusammenbauen
                if (s_energy_price_list_new == "") {
                  s_energy_price_list_new = s_item.Trim();
                }
                else {
                  s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # s_item;
                }
              }
              i_index_energy_price_list = i_index_energy_price_list + 1;
              ! WriteLine(s_energy_price_list_new); ! DEBUG
            }
          }

          else {
            ! (2.3) Es wurde kein passender Index gefunden (i_index_price_found = -1)
            ! WriteLine("Else für kein Preis gefunden.");
            ! Es werden beginnend von vorne in der Liste die SOCs abgezogen
            foreach(s_item, s_energy_price_list.Split(s_energy_price_list_separator)) {
              r_SOC_rest = s_item.StrValueByIndex(s_SOC_price_separator, 1).ToFloat() + r_SOC_delta; ! Wenn Wert negativ, ist das Listenelemnt aufgebraucht
              if (r_SOC_rest <= 0.0) {
                ! WriteLine("Listenelemnt ist verbraucht und wird ignoriert"); ! DEBUG
                ! Listenelemnt ist "verbraucht" und wird ignoriert.
                ! Es verbleibt ein neuer Rest-SOC
                r_SOC_delta = r_SOC_rest;
              }
              else {
                ! Listenelement ist noch nicht verbraucht
                ! WriteLine("Listenelement ist noch nicht verbraucht"); ! DEBUG
                s_energy_price_list_new_element = s_item.StrValueByIndex(s_SOC_price_separator, 0) # s_SOC_price_separator # r_SOC_rest.ToString(2);
                ! WriteLine("Neues Listenelemnt: " # s_energy_price_list_new_element); ! DEBUG
                if (s_energy_price_list_new == "") {
                  s_energy_price_list_new = s_energy_price_list_new_element;
                }
                else {
                  s_energy_price_list_new = s_energy_price_list_new # s_energy_price_list_separator # s_energy_price_list_new_element;
                }
                r_SOC_delta = 0.0;
              }
            }
          }
          s_energy_price_list = s_energy_price_list_new;
        }
      }
      else {
        ! WriteLine("Batterie wurde weder ge- noch entladen."); ! DEBUG
      }
    }
    ! WriteLine("Neue Liste " # s_energy_price_list); ! DEBUG

    ! ======= Preis schreiben =========
    obj_energy_price_list.State(s_energy_price_list);


    ! ======= Pruefen, ob Batterieentladung gesperrt werden sollte =========
    ! Wenn Preise in Battereie zu hoch, soll Variable zur Entladesperre gesetzt werden
    r_EPEX_Price_now = obj_price_now.Value().ToString(2).ToFloat();
    if ((s_energy_price_list.StrValueByIndex(s_energy_price_list_separator, 0).StrValueByIndex(s_SOC_price_separator, 0).ToFloat() * (1.0 + (obj_min_price_delta.Value() / 100.0))) <= r_EPEX_Price_now) {
      b_Bat_EnergyPrice_DischargeLock = false;
      ! WriteLine("Preis <= EPEX Preis: " # (s_energy_price_list.StrValueByIndex(s_energy_price_list_separator, 0).StrValueByIndex(s_SOC_price_separator, 0).ToFloat() * (1.0 + (obj_min_price_delta.Value() / 100.0))) # " <= " # r_EPEX_Price_now);
      ! WriteLine("DischargeLock: " # b_Bat_EnergyPrice_DischargeLock); ! DEBUG
    }
    else {
      b_Bat_EnergyPrice_DischargeLock = true;
      ! WriteLine("Preis <= EPEX Preis: " # (s_energy_price_list.StrValueByIndex(s_energy_price_list_separator, 0).StrValueByIndex(s_SOC_price_separator, 0).ToFloat() * (1.0 + (obj_min_price_delta.Value() / 100.0))) # " <= " # r_EPEX_Price_now);
      ! WriteLine("DischargeLock: " # b_Bat_EnergyPrice_DischargeLock); ! DEBUG
    }
    ! Variable schreiben, wenn sich der Wert geaendert hat
    if (obj_Bat_EnergyPrice_DischargeLock.Value() != b_Bat_EnergyPrice_DischargeLock) {
      obj_Bat_EnergyPrice_DischargeLock.State(b_Bat_EnergyPrice_DischargeLock);
      ! WriteLine("DischargeLock Var hat sich geaendert und wird geschrieben"); ! DEBUG
    }
  }
} ```

[Wisley7]

Oh cool, besten Dank. Das kann ich bei mir wunderbar umsetzen. Da steckt einiges an Arbeit drin.

[Steph6431]

Ich fände es super, wenn man definieren könnte welche Energiemenge über das Netz bezogen werden soll.
Dann könnte man auch über eigene Forecasts das voraussichtliche Delta (erwarteter Verbrauch - erwarteter PV-Ertrag) für den nächsten Tag abschätzen und eine sinnvolle Energiemenge nachts einkaufen. (Indem per API nachts die gewünschte Energiemenge gesetzt wird)
Somit könnte vermieden werden, dass tagsüber zu teuren Zeiten Strom aus dem Netz bezogen werden muss(wenn nachts nicht geladen wird) und auch eine Einspeisung (wenn der Speicher, so wie jetzt, komplett voll geladen wird).

[dieterxy]

Ich habe wie einige andere hier Homeassistent für die Homeautomation darauf evcc für das Energiemanagement. . Eine weitere steuernde Software werde ich nicht einsetzen, daher finde ich jeden Schritt von evcc in Richtung HEMS gut.

Gut fände ich, wenn ich die Kosten der geladenen Energie im Batteriespeicher in € / kWh hätte.
Das als Vorbeitung für eine automatische Entladesperre, sodass die Batterie nur entladen wird wenn die Kosten + einstellbare Verluste (in %) geringer sind als Netz oder PV.

[thoros1179]

Ich würde gerne das dynamische Netzladen rein über einen Zeitraum steuern können anstatt über eine Preisgrenze. Die Preisgrenze hat den Nachteil, dass ich sie jeden tag kontrollieren muss ob sie für die tagesaktuellen Preise überhaupt noch Sinn ergibt. Nun ist es aber ja so, dass der Strom i.d.R. nachts zwischen ungefähr 3 und 6 Uhr immer am günstigsten ist, egal wie der konkrete Preis an dem Tag ist. Ich würde gerne einfach immer zwischen 3 und 6 Uhr laden können, unabhängig vom Preis.

[ThinkEV]

Hier wird das Netzladen des Hausakkus und nicht des Autos diskutiert.
Bei meinem Auto mache ich auch so: Ladeplan 90% täglich auf 07:00 Uhr und gut. Vor Kurzem wurden wiederholdende Ladepläne implementiert. Das ist sehr genial.

[thoros1179]

Stimmt, hier geht es eher um den Hausakku. Da hatte ich es bisher direkt über den WR eingestellt, dass er zwischen 3 und 5 Uhr auflädt (bevor ich das Auto hatte und als es tasgüber immer dunkel war). Dafür würde in evcc dann der Ansatz mit den günstigsten x Stunden funktionieren, oder einfach auch ein (wiederholender) Ladeplan wie beim Auto mit mehr oder weniger identischer Logik. Das ist vielleicht aus Benutzersicht dann auch am einfachsten zu verstehen, wenn die beiden Prozesse auf die gleiche Art konfiguriert werden könnten.

[Coernel82]

Letztendlich ist die eleganteste Lösung die, den Energiebedarf für den nächsten Tag / die nächsten Stunden zu berechnen und dann auch genau so viel zu laden, dass die Batterie nicht über 100% geladen wird (=Netzeinspeisung). Ich habe das versucht abzubilden, und bin jetzt konkret genau am Test dieser Funktion, was nicht ganz trivial ist.
Hier ist die konkrete Funktion: https://github.com/Coernel82/smartCharge4evcc/blob/03d0167d8077b96726bf0e073d07c7aaff9fceee/backend/home.py#L173-L264

Letztendlich brauche ich Hilfe:

• wird die PV-Prognose korrekt berechnet?
• wird der Energieverbrauch des Hauses korrekt berechnet?
• wird der Ladestand des Akkus korrekt berechnet?
• wird die nötige Ladung korrekt berechnet?
• und letztendlich: wir der korrekte Preis berechnet?

Ich würde mich freuen, wenn ihr versucht die Logik zu überprüfen, issues und pull requests sind herzlich willkommen.

[tvand]

Hier wird das Netzladen des Hausakkus und nicht des Autos diskutiert. Bei meinem Auto mache ich auch so: Ladeplan 90% täglich auf 07:00 Uhr und gut. Vor Kurzem wurden wiederholdende Ladepläne implementiert. Das ist sehr genial.

Genau. Es ist praktisch alles schon da. Man muss die Hausbatterie nur genau so wie ein Auto behandeln, dann gibt es (wiederholte) Ladepläne, Mindest-SoC, preisoptimiertes Laden usw. Und es würde sich auch genau so bedienen lassen.

[Coernel82]

Hier wird das Netzladen des Hausakkus und nicht des Autos diskutiert. Bei meinem Auto mache ich auch so: Ladeplan 90% täglich auf 07:00 Uhr und gut. Vor Kurzem wurden wiederholdende Ladepläne implementiert. Das ist sehr genial.

Genau. Es ist praktisch alles schon da. Man muss die Hausbatterie nur genau so wie ein Auto behandeln, dann gibt es (wiederholte) Ladepläne, Mindest-SoC, preisoptimiertes Laden usw. Und es würde sich auch genau so bedienen lassen.

@tvand Für den Winter super. In der Übergangszeit verschwendest du damit Energie, weil du ggf. einspeisen wirst.

[Aeroid]

Ich hab diesen Winter mit meinem HomeAssistant und Victron Ekrano ganz gut folgendes Tibber-Laden umgesetzt:
Im tiefen Winter (bis letzte Woche) Nachts zeitgesteuert via Victron von 2:00 - 5:00 immer voll aus dem Netz laden.
und via HomeAssistant schalte ich die Akku-Entladung bei niedrigen Strompreisen ab.
Das brachte mich mit Wärmepumpe und Akku über den Tag und ich konnte recht zuverlässig tagesgünstigst Strom kaufen. Selten hab ich mal zu viel/zu früh gekauft.

Seit es wieder etwas mehr Sonne gibt, lade ich Nachts nur noch bis 50%, das reicht bis die Sonne kommt und zusätzlich lade ich ab 13:00 noch mal fix bis 70%.

Vermutlich werden ich das Netzladen aber in ein paar Wochen dann wieder nicht brauchen.

Würde mir also "Jahreszeiten" wünschen, die zwischen den drei Szenarien (Kein Netzladen Mär-Sep, "Min+PV" Feb+Okt, "Billigst voll Laden" Nov-Jan) umschalten.

(WP: 2kW / Akku: 2x15kWh / WR: 3xMultiPlus5000 / Max Laden: 7500W)

[steve0564]

Löse ich mit der NodeRed-Implementierung der Victron-Cerbo....

[Aeroid]

Ja, geht natürlich, aber ich verliere langsam den Überblick, wer für welche Regelung verantwortlich ist. Wenn es dann nach Monaten mal Issues gibt, bin ich ganz schön am Suchen (HA, shelly, Victron(s), RS485-MQTT,...). Das wird nicht besser wenn ich irgendwann 60 werde. evcc ist auf nem guten Weg, dass zumindest an einem Ort zu haben!

[Aeroid]

Es über Forecasting zu lösen, wäre natürlich eleganter. Das hieße aber neben dem PV-Forecast auch den Kosten/Bedarfs-Forecast in evcc zu machen. Dann wäre es gleitend und nicht in Szenarien gelöst.
Wird dann natürlich noch komplexer,
da dann zum Automatismus Goals festgelegt werden müssten (billigst?, CO2-arm?,... ).
Von der künftigen Netzeinspeisungsoption aus dem Akku ganz zu schweigen.

[CommoCruise]

Hallo zusammen,
Ich nutze seit gestern das Netzladen und wollte nachfragen wie der Stand der Weiterentwicklung ist.

Folgende Features wären aus meiner Sicht sinnvoll:

• PV Forecast abhängiges Netzladen:
  -> Netzladen = true, when PV Forecast < X kwh.
• Batterie Kapazität abhängiges Netzladen:
  -> Netzladen = true, when Batterie SOC < X% & Netzladen = true while Batterie SOC < X%
• Festlegen der maximalen Ladeleistung in KW für das Netzladen, um die Batterie schonend aufzuladen.

Alles natürlich kombiniert.
Die wären aus meiner Sicht die Anforderungen für zeitabhängiges( Octopus Go) Netzladen.

Danke und Gruß

[TRON4R]

Da das Forecast-basierte Netzladen der Batterie vermutlich etwas aufwendiger zu realisieren ist, wollte ich nur mal kurz die Idee einwerfen, zumindest den Vorschlag dieser Initiative "Dein Stromspeicher kann mehr" der HTW Berlin in evcc umzusetzen.

Die Idee ist, dass man - gerade bei dem aktuellen seit Wochen absolut wolkenlosen Wetter ein wichtiges Feature - die Hausbatterie erst zu einem späteren Zeitpunkt auflädt als automatisch mit den ersten Sonnenstrahlen und so z.B. durch erst mittägliches Laden des Speichers den massiven Stromproduktions-Peak bei Sonnenhöchststand netzdienlich abzumildern hilft UND gleichzeitig noch der Batteriealterung vorbeugt, weil der Hausakku weniger lange mit 100% rumsteht, da er erst später am Tag voll wird.

Dazu würde m.E. eine simple Zeitsteuerung wie z.B. "Hausbatterie immer nur in der Zeit von 11:00 Uhr bis 15:00 Uhr laden" völlig ausreichen. Vielleicht könnte man sogar Teile des bereits existierenden Ladeplanungs-Features für Wallboxen für den Hausspeicher frontend- und backendseitig übernehmen und so den Entwicklungsaufwand weiter minimieren?

Ich denke die Kombination aus Netzdienlichkeit und längerer Akkulebensdauer sind doch zwei gute Gründe und die Umsetzung könnte ein erster - wenig komplizierter - Einstieg in das Thema Hausbatterie-Ladeoptimierung sein.

[cschlipf]

Wäre toll. Ich würde es aber nicht mit Zeitsteuerung machen, sondern anhand der PV Vorhersage, die man jetzt ja in EVCC hat. Z.b. starte den Ladevorgang des 10kWh Speicher, sobald die Vorhersage noch 20 kWh (Puffer für Hausverbrauch und lokale Wetterschwankungen) verspricht.

[TRON4R]

Ja, das ginge natürlich auch. Und wurde ja auch weiter oben schon diskutiert. Ich wollte es aber so einfach wie möglich halten.
Und den Nutzer einfach eine Start- und eine Endzeit einstellen zu lassen und dann Akku außerhalb der Zeit dann nicht zu laden, kam mir jetzt einfacher vor, als irgendwelche Vorhersage-Algorithmen einzubinden und zu optimieren. Da liegt ja - wie so oft - das Problem im Detail und zieht einen Rattenschwanz an kleinen Problemchen nach sich. Ein simples "Lade nur zwischen 11:00 Uhr 15:00 Uhr" hingegen würde die Sache übersichtlich halten und könnte dann später immer noch ausgebaut werden.

[cschlipf]

Eigentlich müsste man da doch "nur" den Hausspeicher wie einen Loadpoint einbinden und könnte dann mit Ladeplänen arbeiten?

[TRON4R]

Interessante Idee. Ich bin mir aber nicht sicher, ob das Template z.B. für die Huawei LUNA 2000 das unterstützt...

[andig]

Note #20455 will add an external battery mode api.

[redzioch]

Is it possible to switch to English in this discussion?

[ekkea]

[switching to English as requested by redzioch, hope that works for everybody]

Lots of good ideas in the above discussion, specifically the availability of forecasts opens lots of opportunities it seems. The challenge with all these various smart charging strategies is that (in my experience) they can be implemented well for a particular case with quite limited effort. However, it will likely become difficult to make them work flawlessly for all use cases and/or in combination with each other. In my experience this will require to eliminate lots of side effects, consider numerous corner cases and to put work in overcoming unintended limitations.
I'd suggest to consider employing an optimization based on MILP (mixed integer linear programming), an algorithm well proven in power plant operational optimization and such. Assuming that the time horizon does not need to be more than a day or two, such a model should be limited to a few hundred variables for a standard case (one battery, one EV) and still solve in acceptable time on a Raspi or such. Anyway, there are cloud services available as well ...
The advantage of MILP over other optimization algorithms is that it can deal with discontinuities (e.g. switched loads) and still guarantees to find the global optimum as long as the model is built after the rules.
Another nice thing about this approach is that you can still add strategy rules (they become additional boundary conditions) and direct the solution (i.e. the charging schedule) into preferred directions by building the target function accordingly (e.g. optimize for cost or CO2 or a combination, prefer source A over source B regardless of cost, etc.).
I'll stop here. Happy to discuss more if there is any interest.

[andig]

@ekkea it seems your comment is more on the implementation than on the feature side. I have no deeper mathematical understanding if the optimisation we're trying to do is better solvable using MILP or SAT or similar (https://stackoverflow.com/questions/53565698/what-is-the-difference-between-sat-and-linear-programming). I would however suggest- if anybody is interested in looking into implementation any sort of optimisation- let's start a separate discussion for that purpose.

[ekkea]

@andig, you are spot on, what I did is a bit jumping to the solution. I guess my underlying statement is that from my perspective, the most satisfying solution would be one that

1. allows me to set the strategy rules / constraints I think make sense for my use case and
2. that yields the optimum within the remaining solution space.

And I agree, also under that assumption it's important to understand which strategy rules the user community would consider useful. My ask in that regard would be to be able to move the battery and EV charging times (from either my own PV system or from the grid) to periods of excessive renewable power on the grid.

Regarding the implementation, if you decide to consider an optimization algorithm as underlying approach, I'll be happy to take part in the discussion, here or in a different thread.

[andig]

Shall we move the "how could we do this technically" Discussion to Slack?

[ekkea]

I'm not familiar with Slack, but sure, let's go ahead, I'll figure out.