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.

[KonstantinSchubert]

Der Wert des geladenen Stroms wird übrigens nicht bestimmt durch die Kosten, die man beim Beladen hatte, sondern durch den Nutzen, den er bringen kann.

Wenn ich den Strom super teuer fuer 100 Cent pro kWh aus dem Netz geladen habe, und jetzt kostet der Netzstrom plötzlich nur noch 10 cent pro kWh fuer die naechsten 3 Monate, dann ist der Wert des Stroms in der Batterie eben 10 cent und nicht 100 cent pro kWh.

[andig]

...und genau so ist es im experimentellen Optimizer umgesetzt ("end of horizon value").

[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.

[cschlipf]

Dir geht es da wohl bei Octopus um den Bonus. Das wird so aber nach "a" nicht funktionieren. Der Ladevorgang muss von Octopus abgeschlossen werden. Du musst also in Octopus den Zielladestand eingeben.

Das kannst Du aber mit Home Assistant hinbekommen zum Beispiel mit meinen Automationen: https://github.com/ha-puzzles/homeassistant-puzzlepieces/tree/main/use-cases/stromtarife/octopus-intelligent-go

Um nun noch mehr um den Bonus zu tricksen, musst Du das nur noch so erweitern, dass automatisch der ZielSoc aktualisiert wird - ist einfach zu machen, aber diesen Bonus-Cheat teile ich aus Fairness gegenüber Octopus nicht.

Die Leistung nach "b" kannst Du dabei auch einfach in EVCC via Home Assistant anpassen.

Generell ist das aber kein Scope für EVCC.

[JWartenberg]

@andig: Beispiel: Lademenge in der Batteriekonfiguration steht auf 4 KW, verbilligter Tarif gilt für die Zeit von 00:00 -05:00 (aktiviert über Netzladen / Preisgrenze). Damit wird im Winter meine 11 KW Batterie garantiert voll und das Haus während der Zeit des verbilligten Tarifs mit Strom versorgt.
Jetzt in der Übergangszeit bei geringem PV-Überschuss möchte in in der Nacht aber nur 2 KW zusätzlich in die Batterie laden weil mir das bis zum folgenden Tag reicht bis wieder genug Sonne da ist. Könnte man erreichen über Begrenzung auf 2 KW oder 1/2 Stunde Dauer und sicherlich auch noch anders.
@cschlipf : nein, der Tarif ist Octopus Go (ohne Intelligent). ~30,5 ct von 05:00-0:00 und ~24,5 ct von 0:00-05:00.

Mir geht es darum in der Übergangszeit, in der der PV-Strom mal knapp nicht reicht, nicht unnötig viel in der Nacht zu laden.

[andig]

...das wird sich alles ohne weitere Knöpfe über den Optimizer lösen lassen der dann selbst entscheiden wann Laden ökonomisch sinnvoll wäre. Beim aktuellen Fortschritt macht es keinen Sinn, dafür weitere manuelle Controls zu bauen, insbesondere keine die Du über API ohnehin schon selbst ansteuern könntest.

[JWartenberg]

OK, verstanden

[UDicke]

...das wird sich alles ohne weitere Knöpfe über den Optimizer lösen lassen der dann selbst entscheiden wann Laden ökonomisch sinnvoll wäre. Beim aktuellen Fortschritt macht es keinen Sinn, dafür weitere manuelle Controls zu bauen, insbesondere keine die Du über API ohnehin schon selbst ansteuern könntest.

Ich habe den installiert und bin sehr gespannt was der tut. Bis jetzt kann ich leider noch nicht erkennen wo und wie der agiert und wie ich das Verhalten ggf. beeinflussen kann.
Das kann ich heute Abend sehen...

z.Zt. begrenze ich die Ladeleistung der Hausbatterie über HA mit dem Ziel "langsam laden und trotzdem voll am Abend,"

[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.

[andig]

@benesolar dazu gibts einen Request: #23308.

[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!

[kobius77]

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 ...

[kobius77]

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ß

[kobius77]

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...

[jjfx141]

Ich würde gern ein Zeitfenster festlegen wollen, in dem die Batterie aus dem Netz geladen werden darf und eine Ziel-SoC, der nicht überschritten werden soll, aber gerne am Ende dieses Zeitfensters erreicht sein kann. Das wäre bei mir dann z.B. 22:00 Uhr bis 05:00 Uhr (Niedriglaststufe meines Netzbetreibers nach Abrechnungsmodul 3) und 70% (das reicht, bis auch bei Bewölkung PV übernimmt).

Da es mir für die Haltbarkeit der Technik nicht zielführend erscheint, wenn der Speicher stundenlang um den Zielwert schwankend zwischen laden und entladen wechselt, sollte das Laden in einem einzigen preisoptimierten Block erfolgen, ggf. mit einem zusätzlichen Spätladen analog der Fahrzeug Ladeplanung.

Ein Blockladen würde ich mir im Übrigen auch für die Wallbox wünschen. Für Garagenparker mag das nicht relevant sein, aber wenn im Winter die Fahrzeugbatterie jedesmal vorgeheizt werden muß, erscheinen zehn über die Nacht verteilte Ladephasen von 15 oder 30 Minuten nicht wünschenswert. Zumindest ist mir das der eine Cent Preisunterschied in der Nacht nicht Wert.

Eine prognosebasierte Lösung zum Netzladen brauche ich für meine Zwecke nicht. An Tagen, an denen die Heizung läuft, fehlen mir zwei bis drei kWh und die sollen halt möglichst preisgünstig - und damit in der Nacht - eingekauft werden.

[TRON4R]

Jetzt wo bei mir endlich das Smartmeter von Octopus aktiviert wurde, habe ich natürlich direkt die neue Möglichkeit genutzt, nachts von 0:00 bis 5:00 Uhr zum halben Strompreis den Hausakku aufladen zu können.

Es hat auch super funktioniert. Ein wirklich sehr schönes Feature von evcc, welches mir hilft, meinen Akku außerhalb der guten PV-Monate noch effektiver zu nutzen.

Folgende Dinge sind mir dabei allerdings aufgefallen. Einige habe ich hier schon gesehen und möchte ich hiermit unterstützen, andere noch nicht:

1. Mein Hausakku (Huawei LUNA2000) wurde nur bis 95% geladen, nicht bis 100%.
   Ist das so mit Absicht programmiert worden, z.B. um den Akku zu schonen?

2. Die aktuell sehr binäre Aktivierung des Ladevorgangs mit nur der Unterschreitung einer Preisgrenze als Kriterium ist für viele Fälle zu grob:

• so fängt der Akku um Punkt Mitternacht an zu laden und ist dann bereits um kurz vor 3 Uhr damit fertig. D.h. er steht dann 2h vollgeladen rum, bis um 5 Uhr der Strompreis wieder auf den teureren Standardtarif umschaltet. Da wäre ein späterer Ladestart besser.
• Wenn ich weiß, dass es am nächsten Tag halbwegs sonnig werden wird, will ich den Akku u.U. nur halbvoll laden, damit ich noch genug Platz für den PV-Strom am Tag habe.

Mir ist klar, dass das wohl durch den Optimizer gelöst werden soll. Aber das ist ja ein größeres Projekt, welches noch einige Zeit brauchen wird, und von daher wäre meine Frage, ob man zwischenzeitlich nicht einfach einen simplen %-Wähler wie bei den Wallbox-Loadpoints einbauen könnte, der dann einfach den Ziel-SoC festlegt, bei dessen Erreichen das Netzladen beendet wird

3. Am Ende des Netzladens ist bei meinem Huawei SUN2000 Wechselrichter dann immer AC-Laden ausgeschaltet, auch wenn es vorher aktiviert war. Ich habe irgendwo gelesen, dass es da wohl den YAML-Parameter forceload oder so gibt, der das dauerhaft aktiviert lässt. Aber AC-Laden will ich im Sommer z.B. wiederum nicht aktiv haben. Von daher wäre es schöner, wenn einfach der vor dem Netzladen bestehende Stand beibehalten werden könnte.

Es wäre toll, wenn da vielleicht noch zumindest die Ziel-SoC-Idee zeitnah umgesetzt werden könnte, sodass man das Netzladen diesen Winter bereits effektiv nutzen kann. Denn ich vermute mal, dass der Optimizer noch ein paar Monate brauchen wird, bis dieses recht komplexe Thema so umgesetzt werden könnte, dass damit eine weitgehend automatische Steuerung der Systeme möglich ist.

[iseeberg79]

Das yaml ist doch nichts anderes als ein Custom-Meter. Du kannst es in die evcc.yaml als battery, type custom und einer geschickten Auswahl selbst zusammenkopieren und ändern. Die Parameter bekommen die richtigen Werte und gut. Daraus könnte dann sogar ein PR gemacht werden. Kein kompilieren nötig, um ein Template eines WR anzupassen zum Ausprobieren.
(alles etwas off-topic hier, ich markiere das später...)

[VolkerK62]

dann ergänze ich das OT noch um den Hinweis, dass man auch etwas aufwändigere Templates ganz einfach testen kann
https://github.com/evcc-io/evcc/blob/master/CONTRIBUTING.md#device-templates

[LotharWoman]

Ok, ich habe mir mal einen LXC aufgesetzt und komme jetzt auch auf den Server. Mit der ganzen Dateistruktur in Linux muss man sich auch erst mal zurecht finden, so wie auch mit der ganzen Syntax. Ich glaube da muss ich noch nach etwas Hilfe bei euch Fragen um das überarbeitete Template zu testen.
Da hier dann doch zu OT, am Besten nach #24674 verschieben. Dort hatte ich schon mal angefangen das Fehlverhalten zu thematisieren. die nächsten Tage werd ich mich dann mal über die huawei-sun2000.yaml her machen und die entsprechenden Register zusammensuchen. Alles sehr neu für mich, aber schauen wir mal was bei rum kommt.

@VolkerK62 Nur mal zum Verständnis vornweg.
"evcc --template-type charger --template new-charger-template.yaml" wäre für den hier anstehenden Fall dann "evcc --template-type meter --template huawei-sun2000-test.yaml" ? Wo lege ich vor ausführen des Befehl das neue File ab, /etc oder /var/lib/evcc ? Und in der Konfiguration über GUI ist dann dieser neue Meter samt Batterie und Wechselrichter anzulegen und zu konfigurieren?

[VolkerK62]

@LotharWoman da evcc lokal gestartet wird, am besten im Home Laufwerk, dann brauchst du keine Pfade angeben. Richtig, du kannst dann in der UI-Konfig dieses Template auswählen und einrichten.

[TRON4R]

Ich weiß, dass das Thema "Netzladen" zu verbessern weiterhin etwas hinten an steht und der Optimizer viele Punkte umsetzen wird. Aber vielleicht gibt es ja trotzdem die Möglichkeit, die folgende Sache schnell einzubauen, die vom Aufwand nach meinem Eindruck eigentlich überschaubar sein sollte, weil die meisten Zutaten dafür schon vorhanden sind:

Und zwar lädt evcc bei der Nutzung der aktuellen Netzladen-Funktion den Hausakku nur soweit auf, wie es in der yaml mit dem Parameter maxsoc: bei den meter Definitionen bestimmt wird.
Hat man dort z.B.
maxsoc: 95
eingetragen, dann hört das Netzladen bei 95% SoC auf. D.h. darüber könnte man bereits jetzt die Netzladung insoweit steuern, dass wenn man weiß, dass der nächste Tag z.B. besonders sonnig wird, man den Akku nachts z.B. nur bis 60% auflädt, statt bis 95%. Oder umgekehrt.
Nur leider muss man dazu dann jedesmal die yaml editieren und evcc neu starten.

Könnte man nicht diesen Parameter (vielleicht auch noch zusammen mit minsoc) auch in der GUI im Bereich Netzladen noch einstellbar machen? Dann wäre das auch am Handy mit zwei Klicks am Abend nach einem kurzen Blick auf die Prognose für den nächsten Tag zu erledigen und man könnte sich zudem den Neustart sparen. Was meinst Du dazu, @naltatis ?

[Enrica-r]

Ich finde viele Vorschläge super. Auch bei uns in der Schweiz kommen ab 2026 dynamische Strompreise inkl dynamischer Netzpreise.
Was ich in der Disskussion vermisse, sind Sperrungen gewisser Geräte, wenn der Preis über einer Schwelle liegt. Gerade bei Heizungen/WP bräuchte es noch einen Parameter: wie lange darf die Heizung blockiert sein. Gerade bei der Heizung im Winter sollte Algorithmus die größte Dunkelflaute erkennen und die Batterie möglichst dann entleeren und erst wenn sie einen Schwellwert unterschreitet die Heizung sperren.

Mittelfristig wäre der Einsatz von KI sinnvoll. Sie könnte all die vielen Parameter wie Pv Prognose, Wetter/Temperaturen (Prognose Verbrauch Heizung), Warmwassererzeuger, Auto und Batteriespeicher mit den Tarifen optimieren.

[LotharWoman]

Ich hatte es an andere Stelle schon ml erwähnt, aber weil grad heute Nacht wieder von Relevanz und ich regelmäßig auf das Problem stoße, meiner Meinung nach bräuchte die Ladeplanung für den Bereich Hausbatterie dringend die Möglichkeit eine Startzeit zu setzen.
In folgendem Beispiel wird die Batterie gegen 23Uhr leer sein. Für Morgen ist wenig Solar zu erwarten. Es wäre also sinnvoll in den frühen Morgenstunden die Batterie schon etwas vorzuladen, über Tags dann Strom direkt vom Netz zu nutzen und den wenigen zu erwartenden PV-Ertrag zum kompletten befüllen der Hausbatterie zu verwenden.
Aktuell geht der Plan nur mittels zweiter Automatisierungssoftware umzusetzen, da evcc schon vor Mitternacht die Batterie aus dem Ruhezustand wecken würde. Das System würde also die ganze Nacht Strom verbrauchen und so mehr Strom verschwenden als die 2 Viertelstunden um Mitternacht einbringen.

Besteht da wirklich keine einfache Möglichkeit der evcc Software eine Startzeit für die Netzladung mitzugeben/zu implementieren, um schon am Vorabend den nächsten Tag planen zu können? Nur mal als Denkanstoß:

Für Systeme mit grossen Batterien oder wenn der Strom durch die komplette Nacht reicht, also 24/7 Systeme sicher nicht von Relevanz. Gleiches Problem besteht aber auch bei Batteriesperrzeiten, auch hier findet die Planung über den Preis immer sofort ab aktuellem Zeitpunkt Anwendung, aber auch hier kann es sinnvoll sein Sperren erst ab einem späteren Zeitpunkt starten zu können, z.Bsp. dann wenn Ertrag zu erwarten ist.

[KonstantinSchubert]

Warum morgens vorladen? Weil da die Preise besser sind? Was, wenn sie es mal nicht sind? Ich glaube, letztendlich lassen sich alle diese Anforderungen erschlagen, indem man eine echte Optimierung macht, welche dir Strompreise, die vorhergesagte PV-Produktion und den erwarteten Verbrauch berücksichtig. Dann hat man immer den optimalen Fahrplan und muss den Akku nicht babysitten. Es gibt ja in evcc schon eine experimentelle Optimierung von evcc und alternativ habe ich auch eine Optimierung auf akkuplan.eu gebaut.

…

On Fri 14. Nov 2025 at 22:33, LotharWoman ***@***.***> wrote: Ich hatte es an andere Stelle schon ml erwähnt, aber weil grad heute Nacht wieder von Relevanz und ich regelmäßig auf das Problem stoße, meiner Meinung nach bräuchte die Ladeplanung für den Bereich Hausbatterie dringend die Möglichkeit eine Startzeit zu setzen. In folgendem Beispiel wird die Batterie gegen 23Uhr leer sein. Für Morgen ist wenig Solar zu erwarten. Es wäre also sinnvoll in den frühen Morgenstunden die Batterie schon etwas vorzuladen, über Tags dann Strom direkt vom Netz zu nutzen und den wenigen zu erwartenden PV-Ertrag zum kompletten befüllen der Hausbatterie zu verwenden. Aktuell geht der Plan nur mittels zweiter Automatisierungssoftware umzusetzen, da evcc schon vor Mitternacht die Batterie aus dem Ruhezustand wecken würde. Das System würde also die ganze Nacht Strom verbrauchen und so mehr Strom verschwenden als die 2 Viertelstunden um Mitternacht einbringen. image.png (view on web) <https://github.com/user-attachments/assets/3ef4ee7f-0f14-42d4-9320-a10a5e369b31> Besteht da wirklich keine einfache Möglichkeit der evcc Software eine Startzeit für die Netzladung mitzugeben/zu implementieren, um schon am Vorabend den nächsten Tag planen zu können? Nur mal als Denkanstoß: image.png (view on web) <https://github.com/user-attachments/assets/622cb48b-d53f-4b16-b27f-14c370876e85> Für Systeme mit grossen Batterien oder wenn der Strom durch die komplette Nacht reicht, also 24/7 Systeme sicher nicht von Relevanz. Gleiches Problem besteht aber auch bei Batteriesperrzeiten, auch hier findet die Planung über den Preis immer sofort ab aktuellem Zeitpunkt Anwendung, aber auch hier kann es sinnvoll sein Sperren erst ab einem späteren Zeitpunkt starten zu können, z.Bsp. dann wenn Ertrag zu erwarten ist. — Reply to this email directly, view it on GitHub <#16364 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANB22C7V3QWXXFQNRRTWAL34ZDC5AVCNFSM6AAAAABO6XNGUOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJXGM2TOMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[thecem]

Es gibt Dynamische und TOU Tarife, beide lassen sich mit Modul 3 kombinieren, somit ist das was @LotharWoman hier schreibt, sehr relevant um die Batterie so spät wie möglich zu laden, um die „Standzeiten “ bei hoher Ladung zu verhindern.

Hier wird die Batterie je nach eingestellter max Charge Power umgehend geladen bis der Max SOC erreicht wird, danach steht sie bis der Zeitraum endet, weil der Bezug aus dem Netz erfolgt.

[machtandrebel]

Ich sehe das auch so und frage mich schon seit Längerem hier im Forum, warum es nicht auch eine Zeitfensterplanung für die Batterie gibt. Einige WR Hersteller bieten dass im HEM an. Nur meiner nicht ...

[jjfx141]

Ich war kurz davor, als Workaround den Preis in der Nacht für ein oder zwei Stunden auf nahe Null zu setzen, um das Netzladen auf dieses Zeitfenster zu begrenzen, werde aber jetzt den dynamischen Tarif ganz aufgeben. Wenn mein Netzbetreiber (bzw. dessen unfähiger Sub-Dienstleister) es irgendwann schafft, den Zählerwechsel vorzunehmen, sollte mein Preisprofil so aussehen:

Der Speicher lädt dann zwar fünf Stunden, aber zumindest am Stück. Ich habe zudem die Ladeleistung des Speichers auf gemütliche 600 W reduziert, so kommen die drei kWh zusammen, die ich maximal pro Nacht aus dem Netz laden will. Max SoC steht zur Sicherheit auf 85%. Bei Bedarf kann ich das Ladefenster ja immer noch auf ein oder zwei Stunden verkürzen, indem ich vom echten Preis um 0,1 Cent nach unten abweiche.

[MartinRinas]

Ich hab hier und da Fragen zum preisgesteuerten Netzladen gesehen, zuletzt hier https://www.photovoltaikforum.com/thread/238874-evcc-netzgesteuertes-akku-laden-funktioniert-nicht-sma-shm-2-0-sma-stp-10-sma-sb/?postID=4540437#post4540437

Dreht sich immer um ein recht ähnlich gelagerte Situation:
Dynamische Preise welche sicher teilweise nur geringfügig von Stunde zu Stunde ändern. Die aktuelle Regelung mit fixem Umschaltpunkt durch Über/Unterschreiten sorgt hier für eine nicht ideale Steuerung, im unglücklichsten Fall auch zu mehreren, kurzen, Ladeintervallen. Zudem werden m.w. die Wandlungsverluse nicht berücksichtig.
Angenommener Fall:

1. Preislimit 20ct/kWh, Preis sinkt unter 20ct zwischen 2 und 5, Akku wird geladen und für den gesamten Zeitraum gesperrt. Alles gut.
2. Preis steigt um 6 auf 20,1ct/kWh - Akku wird entsperrt und Strom entnommen.
   Wohingegen es wirtschaftlicher wäre den Speicher weiter zu sperren bis eine größere (ggf. konfigurierbare) Preisdifferenz erreicht wurde. z.b. Ladestart bei unterschreiten von 20ct/kWh, Ladestopp&ensperren erst bei überschreiten von 22ct/kWh.

Konkret also die Ein- und Ausschaltschwelle mit einem Offset versehen, eine Schalthysterese einbauen.

Falls das konzeptionell im Optimizer bereits adressiert ist wäre das natürlich auch gut und dann womöglich hinfällig.

https://www.photovoltaikforum.com/thread/238874-evcc-netzgesteuertes-akku-laden-funktioniert-nicht-sma-shm-2-0-sma-stp-10-sma-sb/?postID=4540437#post4540437

[KonstantinSchubert]

Ich denke, in einer Optimierung wird das verhindert, wenn man Ladeverluste und Entladeverluste berücksichtigt und wenn man dem Laden der Batterie virtuelle Verschleiß-Kosten zuschreibt. Ich mache das in meiner Optimierung so, wäre sicher cool wenn die Optimierung von evcc das auch könnte.

Dennoch bleibt dann noch das Problem, dass evtl. Ladevorgänge "zerstückelt" werden, wenn die Preisfunktion sehr un-monoton ist, also immer wieder steigt und abfällt. Da kann man dann eventuell auch noch "Startkosten" für einen Ladevorgang beschreiben - das ist dann aber sehr Hardware-abhängig.

[MartinRinas]

Bei den zerstückelten Ladevorgängen sehe ich erstmal mehr ein optisches als ein reeles Problem. Es finden ja keine mechanischen Schaltvorgänge statt welche dann beispielsweise zu einem schnelleren Verschleiß führen würden. Ist vielleicht nicht so hübsch in einer Statistik anzusehen, okay. Aber gibts darüber hinaus ein echtes Problem? Vielleicht gibts da eins, ich kanns nur gerade nicht erkennen.

[andi0b]

Wie wäre es für den Anfang einfach zwei Preisgrenzen einzuführen statt einer? Lade- und Entladegrenze.

Liegt der Preis unter der Ladegrenze, wird geladen.
Über der Entladegrenze wird entladen.
Dazwischen wird die Batterie gesperrt (direkter Netzbezug)

Zusätzlich wäre eine maximale Ladeschwelle (zb 70%) auch interessant, über der Ladeschwelle wird die Batterie gesperrt, bis der Preis unter die Entladegrenze fällt, oder die Batterie über der Ladeschwelle geladen ist (durch pv).

Dann könnte man manuell halbwegs vernünftig den nächsten Tag planen.

[KonstantinSchubert]

Bei den zerstückelten Ladevorgängen sehe ich erstmal mehr ein optisches als ein reeles Problem.

Das stimmt. Das ist eher bei den Autos ein Thema, wo man evtl. mit einer Batterie, die schon warm ist, besser laden kann.

Wie wäre es für den Anfang einfach zwei Preisgrenzen einzuführen statt einer? [...] Dann könnte man manuell halbwegs vernünftig den nächsten Tag planen.

Solange du jeden Abend auf die Preise schaust um den nächsten Tag zu planen ist das sicher eine gute Lösung. So Optimierungen wie der evopt von evcc oder wie akkuplan sind dann eher für Leute, die das nicht jeden Tag machen wollen.
Die Frage ist ein bisschen, in welche Richtung sich evcc perspektivisch entwickeln will.

[volsk]

My German is not so good, so I'm missing 60% of the discussion. I hope this is not a duplicate.

Feature Request: Smarter Home Battery Charge & Discharge Control Based on Energy Price

Introduce a three-threshold battery control model that cleanly separates Grid charging, PV charging only, and discharging decisions based on energy price. This avoids economically inefficient cycling and better supports dynamic, fixed, and complex tariff structures.

Problem Statement

Current battery control tends to switch directly between charge and discharge.
This can lead to:
• Battery discharge at prices that do not compensate round-trip losses
• Unnecessary cycling and wear
• No way to express “wait until it’s actually worth it”
• Poor alignment with fixed or seasonal tariffs

An explicit PV charge only state is required.

Proposed Solution: Dual Price Thresholds (X, Y)

Two configurable price thresholds:

Price range	Battery behavior
Price ≤ X	Charge from grid
X < Price < Y	PV-Only (or hold)
Price ≥ Y	Discharge allowed (normal / on-demand)

X would be set to 0 or Y depending on your choice.

Variant A — Dynamic Pricing (Efficiency-Aware)

Use case: Hourly / real-time pricing.

Users charging at low prices should not discharge again until price increases compensate for round-trip efficiency losses.

Let:
• X = charge price threshold
• a = round-trip efficiency (0 < a ≤ 1)

Y = X / a

Example
• X = €0.11 / kWh
• a = 0.8 (80%)

Y = 0.1375 €/kWh

Behavior:
• Charge ≤ €0.11
• Hold between €0.11–€0.1375
• Discharge only ≥ €0.1375

Variant B — Fixed Off-Peak / Peak Contract

Use case: Fixed tariff with predictable price windows.

Example:
• Off-peak charging: €0.11 / kWh
• Peak price: €0.23 / kWh

Configuration:
• X = €0.11
• Y = €0.23

Behavior:
• Charge during off-peak
• Hold during mid-price periods
• Discharge only during peak price

Variant C — Complex / Seasonal Tariffs

Use case: Multiple price classes with seasonal differences. My energy tariffs below for reference.

Example thresholds:
• Summer: X = €0.13, Y = €0.14
• Winter: X = €0.185, Y = €0.25

Only thresholds change; control logic remains identical.

Spring & Summer (1 April – 30 September)

Period	Days	Time	Price (€/kWh)
Standard	All	00:00 – 12:00	0.228702
Standard	All	16:00 – 00:00	0.228702
Off-peak	Mon–Fri	12:00 – 16:00	0.131176
Off-peak	Sat, Sun & public holidays	12:00 – 16:00	0.110848

Autumn & Winter (1 October – 31 March)

Period	Days	Time	Price (€/kWh)
Standard	All	06:00 – 12:00	0.253991
Standard	All	16:00 – 01:00	0.253991
Off-peak	All	12:00 – 16:00	0.200751
Off-peak	All	01:00 – 06:00	0.184053

⸻

Optional Configuration Extensions
• allowPvChargeInHold: true|false
• autoDischargeThreshold = X / efficiency
• Seasonal profiles for X/Y

[hnayeb]

Hi.

Ich möchte meinen Usecase auch gerne darstellen. Für mich wäre vorerst ein fixer Max-Netzlade-SOC für den Speicher auch sehr praktisch, der dann später vom Optimizer auf Basis der zu erwarteten Produktion des nächsten Tages dynamisch gesetzt werden könnte.

Ich nutze einen Stromtarif, der zwischen 00:00 und 05:00 Uhr 18,99Cent pro KwH kostet und an den restlichen Zeiten immer 32,7Cent. Also kein echter dynamischer Tarif, sondern sehr gut kalkulierbar. Ich würde meinen 20kWh Speicher daher gerne nachts aus dem Netz laden lassen, damit ich den günstigen Tarif aus der Nacht auch am Tag nutzen kann. Allerdings sollte in der Nacht auch nur soweit geladen werden, dass ich tagsüber auch noch "Platz" habe, um den PV Überschuss nutzen zu können und ihn nicht einspeisen muss.

Anfänglich würde es mir reichen, wenn ich einfach einen fixen SoC angebe für das Netzladen in der Nacht. Wenn das Wetter dann gut ist, dann kann ich den Überschuss noch retten. Falls nicht, hab ich genug aus dem Netz geladen für den restlichen Tag, etc. Später könnte der Optimizer dann diesen Wert für mich täglich setzen, abhängig davon, was an Produktion, Verbrauch, etc. prognostiziert wird.

Vielen Dank für das tolle Produkt! Ich bin so happy, dass ich mich für EVCC entschieden habe. Macht bitte weiter so!

Viele Grüße
Human

[hendriksoppa-droid]

Wenn ihr einen gut kalkulierbaren Strompreis bei echtem Börsenpreis braucht, da kann ich glaube ich helfen... habe auch eine Einbindung in evcc umgesetzt und bin bereit da mit euch weiterzudenken.
Habe eine Vorhersage gebaut, die echt brauchbar ist. Die Qualitätszahlen könnt ihr gerne einsehen. In der Regel würdet ihr damit die richtige Entscheidung treffen.
Mit den Werten könntet ihr entscheiden an welchem Tag ihr "ganz voll ladet" oder eben nur das "Nötigste".
Ihr hättet Preise für jede Stunde, sobald day ahead verfügbar ist, schaltet es automatisch auf den tatsächlichen 15min Preis um.

#29275

[FroeMa]

Für mich macht Netzladen nur Sinn, wenn es ähnlich wie einer Wallbox funktionieren würde. Ich nutze einen dynamischen Stromtarif und mir würde es zunächst mal reichen, wenn ich eine Zielladung angeben kann und evcc mir die günstigsten Zeitpunkte dafür berechnet. Also als Beispiel: Lade bis 7 Uhr günstigst auf 80%. Verbunden mit einer Solarprognose wäre dann ein weiterer Schritt.

[eikewink]

Ich würde mir Folgendes wünschen, und zwar, dass man die Möglichkeit hat, wenn man aus der Nacht kommt und meinetwegen eine Vorhersage hat für den nächsten Tag größer denn 100 kWh zum Beispiel oder 60 oder 80, je nachdem einstellbar, dass man die Batterie entlädt in das Netz, zum Beispiel bis 9 Uhr auf X Prozent, weil ich das Problem habe, dass mein Speicher jetzt größer ist. Ich über die Nacht komme und meistens der Speicher morgens noch 20% oder 30% Ladung hat und ich diese gerne ins Netz geben würde, wenn am nächsten Tag die Sonne dementsprechend stark scheint.

und dann ist mir egal wieviel ich bekomme, da ich ja dann eh "gleich nachlade"

cool wäre sowas mit ner astro Funktion ala 8:37 Uhr Sonnenaufgang + 45 min dann akku auf 5%

[eikewink]

ich habe smartmeter und smart gateway alles gerade eingebaut

[UDicke]

@eikewink hast Du einen dynamischen Preis für die Einspeisung oder wozu soll das gut sein?

[cschlipf]

Also wie ich das verstanden habe kannst Du aber selbst dann nicht einfach nach Deinem Gutdünken zu einer beliebigen Zeit einspeisen. Sondern nur netzdienlich, d.h. Dein Netzbetreiber entscheidet wann er sich aus Deinem Speicher bedienen kann. Nicht Du.

[ansgarherkert]

Hast du eine über 20 Jahre alte Altanlage ohne fixe Einspeisevergütung?

Dein Vorschlag wäre nur dann sinnvoll, wenn du zeitvariabel morgens eine Einspeisevergütung erhältst, die (zur Kompensation der Ladeverluste) mindestens 20% über der Vergütung direkt zum Zeitpunkt der Produktion ist. Bei einer Anlage mit fixer Einspeisvergütung ist das ja nie der Fall und du machst dann immer einen Verlust im Vergleich zur normalen Überschusseinspeisung.

[eikewink]

@eikewink hast Du einen dynamischen Preis für die Einspeisung oder wozu soll das gut sein?

das soll das ziel sein noch stecke im im festen tarif

[ansgarherkert]

Hallo @naltatis, @andig,

danke für die tollen Gesprächen auf dem evcc Treffen in Osnabrück. Darauf aufbauend hier mein Vorschlag zum Netzladen.

Ich finde die bisherige Implementierung schon gut. Die Idee des Optimizers verstehe ich. Allerdings sind verlässliche Prognosen für PV-Produktion und Verbrauch notwendig, um einen Optimizer richtig einsetzen zu können. Da sehe ich die größten Probleme. Ich habe daher überlegt, welche Daten realistisch vorhanden sind und was damit jeweils ideal möglich ist.

Ich glaube, dass Szenarios 2 und 3 die in der Praxis relevantesten sind und habe dafür einen Vorschlag.

Szenarien

1. Keine Informationen außer dem Stromtarif sind verfügbar bzw. nutzbar (aktueller Stand)
2. Zusätzlich ist die Ladeleistung der Hausbatterie bekannt (z.B. 10 kWh) - praktisch immer verfügbar
3. Zusätzlich sind unzuverlässige Prognosen von Verbrauch und/oder PV-Erzeugung verfügbar
4. Zusätzlich sind verlässliche Prognosen von Verbrauch und PV-Erzeugung verfügbar

Für Szenario (1) ist die aktuelle Implementierung optimal.

Für Szenario (2) ist eine einfache Optimierung möglich, die meist schon ein (fast) optimales Ergebnis liefert. Diese ist: lade nicht am Anfang einer Niedrigpreisphase sondern am Ende dieser Phase. Damit kann vorhandener PV-Überschuss optimal genutzt werden.

Dies ist bereits die optimale Implementierung bei zeitvariablen Tarifen. Selbst exakte Kenntnis von Verbrauch und PV-Produktion führt zu keiner Verbesserung (außer es ist besser den Ziel-SOC der Batterie täglich zu variieren). Bei dynamischen Tarifen ist dies ggf. noch nicht optimal aber auch dort ist das fast immer besser als die Implementierung in Szenario (1), da PV-Überschuss deutlich besser genutzt wird.

Für Szenario (3) ist schwer zu sagen, was optimal ist. Da insbesondere ein zu geringes Laden der Batterie bei späteren hohen Stromkosten die Ergebnisse zerstört, ist wahrscheinlich ein Vorgehen wie bei Szenario (2) die sichere und bessere Lösung als ein Optimierer auf Basis unzuverlässiger Daten.

Für Szenario (4) ist ein voller Optimierer optimal. Es kann nicht nur das Ladefenster optimiert werden sondern auch der SOC, bis zu dem jeweils geladen wird.

Einordnung
Ich denke, Szenarios (2) und (3) sind die mit Abstand wichtigsten Szenarios. Viele Nutzer werden keine oder nicht ganz verlässliche Prognosen von Verbrauch und/oder PV-Erzeugung haben. Insbesondere wenn man zeitvariable Tarife nutzt, ist daher der einfache Algorithmus deutlich besser als ein Optimizer mit unzuverlässigen Prognosen.

Ich denke daher, dass zusätzlich zu dem geplanten Optimizer als weitere Option auch die Möglichkeit, am Ende der Niedrigpreisphasen zu laden, in evcc vorgesehen werden sollte. Der Implementierungsaufwand ist gering, gerade im Vergleich mit dem Optimizer.

Beispiel bei mir
Ich habe einen zeitvariablen Tarif mit Niedrigpreisen von 2:00-6:00 und 12:00-16:00. Die Preisdifferenzen sind so groß, dass es sich immer lohnt in den Niedrigpreisphasen die Batterie zu laden und die Hochpreisphasen damit zu überbrücken.

Mein Verbrauch 16:00-24:00 schwankt täglich um 5 kWh oder mehr, abhängig davon, wieviel gekocht / gebacken / geduscht / gebadet / gewaschen / am PC gespielt / ... wird. Ich habe zusätzlich einen Mieter, den ich nicht "steuern" kann. Ich habe also keine verlässliche Verbrauchsprognose und will daher vor dem Ende der Niedrigpreisphase eine möglichst volle Batterie haben, um Strombezug in der Hochpreisphase zu minimieren. Ein dynamisches "Optimierung" des SOC vor einer Hochpreisphase wäre kontraproduktiv.

Die Produktion meiner PV-Anlage habe ich mit forecast-solar in evcc modelliert. Bei mir weicht die echte Produktion regelmäßig um +/-15% von der Prognose ab. Die Abweichungen innerhalb des Tages sind noch größer, wenn der Tag nicht 100% sonnig ist. Daher ist der tatsächlich verfügbare PV-Überschuss deutlich unterschiedlich von der Prognose und ich halte es daher für gefährlich, diese bei der Ladeplanung zu verwenden.

Anmerkung zur Implementierung des vorgeschlagenen Algorithmus zum Laden am Ende der Niedrigpreisphase
Es ist (leicht) zu berücksichtigen, dass die Ladeleistung bei hohem SOC auch bei Hausbatterien abfällt. Es sollte dafür ein (kleiner) Zeitpuffer vor dem Ende der Niedrigpreisphase vorgesehen werden (von evcc vorgegeben oder optional Eingabe vom Nutzer).

Der Algorithmus würde bei jedem Refresh von evcc prüfen, ob gerade eine Niedrigpreisphase ist, und ermitteln, wie lange das Laden der Batterie bis zum Ziel-SOC dauern wird. Wenn das errechnete Ladeende (plus Puffer) vor Ende der Niedrigpreisphase ist, dann wird noch gewartet. Wenn das Ladeende am Ende der Niedrigpreisphase liegt (oder danach), dann wird Netzladen gestartet. In der Zeit, in der das Laden noch nicht gestartet wurde, wird das Entladen der Batterie in der Niedrigpreisphase gesperrt.

Es wäre gut, wenn der Nutzer (optional) einen Ziel-SOC eingeben kann. Das ist bei großen Batterien und relativ geringem Verbrauch sinnvoll. (Für mich nicht relevant.)

Ich weiss nicht, wie ihr den Optimizer programmieren wollt. Ggf. kann dieser ja auch ohne Verbrauchs- und PV-Prognosen arbeiten und kommt zu vergleichbaren Ergebnissen. Aber so ein einfacher und klar nachvollziehbarer Algorithmus hätte wohl selbst dann einige Vorteile.

[thecem]

Gibt es. emhass oder wie gezeigt EOS.

[ansgarherkert]

Aber nicht direkt in evcc. Klar kann ich das selbst programmieren oder andere Systeme verwenden.

Ich dachte, es geht darum zum Netzladen etwas direkt in evcc anzubieten, was der breiten Masse der "normalen" Nutzer hilft und leicht und möglichst "narrensicher" zu bedienen ist.

Sonst müsste auch der Optimizer nicht in EVCC implementiert werden.

[eikewink]

....anderes Beispiel, dann nicht ins Netz aber in meine Heizstäbe. Ich würde den Akku zumindest gern leer haben am Morgen
Nach dem Motto knall sie runter auf 5% oder was weiß ich ....Energie kommt ja gleich

[cschlipf]

....anderes Beispiel, dann nicht ins Netz aber in meine Heizstäbe. Ich würde den Akku zumindest gern leer haben am Morgen Nach dem Motto knall sie runter auf 5% oder was weiß ich ....Energie kommt ja gleich

Jetzt wird es interessant für mich. Weil das ist ein Use Case den ich schon mit Home Assistant automatisieren wollte. Zwar nicht mit Heizstäben, aber mit einem Auto, aber beides sind ja technisch gesehen Loadpoints.

Konkret ist meine Idee morgens, wenn noch genug Rest im Speicher ist, diesen in das Auto zu laden bevor ich um 8:00 Uhr ins Büro fahre. Denn wie oft kommt es vor dass unter der Woche schöner Sonnenschein ist, aber zum Wochenende, dann wenn das Auto leer ist und geladen werden soll, wird die Prognose wieder schlecht. So könnte ich die Restkapazität unter der Woche im Auto nutzen, statt einzuspeisen.

Dazu müsste ja eigentlich morgens nur das Laden mit Battery Boost aktiviert werden.

[andig]

Optimizer…

[gennergy]

Ich finde es wird teilweise viel zu komplex gedacht und "die" optimale automatisierte Lösung über Vorcast ist eher unwahrscheinlich.
Es gibt eher ein anderes Problem oder unschönes Verhalten beim Netzladen.

Ausgangssituation:
Es ist Mai, der Sonnenertrag ist eher dürftig und die Aussentemperaturen sind ziemlich kalt.
Die Wärmepume springt morgens öfters noch an. Manchmal reicht die Energie im Hausakku nicht aus, bevor die Sonne nachlädt und es wird Strom aus dem Netz bezogen.
Ich habe einen Stromtarif mit einer günstigen Zeit von 0 - 5 Uhr. Wenn der Akku nicht genug Energie hat wird von 5 bis ca. 11 Uhr teurer Strom aus dem Netz bezogen.

Lösungsansatz:
Ich weiß zb., dass ich morgens um 5 Uhr 40% im Akku benötige, damit der Tag ohne Netzbezug starten kann.
Ich stelle also Netzladen mit günstigen Preis zwischen 0 - 5 Uhr ein. Soweit so gut.

Problem:
Ist der Speicher vom Vortag noch weit über den genannten 40% blockiert der Akku seine Entladung über die ganze Zeit von 0-5 Uhr, auch wenn nicht nachgeladen werden muss. Oder der Akku ist nach einer Stunde bereits auf seinen Soll SOC und die Entladung wir bis 5Uhr blockiert.
In diesem Zeitraum wird der komplette Hausverbrauch und die Wärmepumpe aus dem Netz bezogen. Es könnte aber vom Akku geliefert werden.

Umständlich:
Es muss jeden Abend kontrolliert werden, ob genug Energie im Speicher ist und Netzladen aktiviert bzw. deaktiviert werden.
(Auch umständlich: Der Soll SOC für den Speicher kann nur in der Konfiguration angepasst werden und benötigt einen Reboot von EVCC.)

[TRON4R]

Klar, in dem Szenario bin ich bei Dir. Aber Deine Beschreibung oben klang so, als ob es generell unerwünscht sei, den Speicher zu sperren, wenn der Strom günstig ist.

[hnayeb]

Das war die Beschreibung von Gennergy, die ich nun so interpretiert habe, wie es bei mir auch derzeit aussieht. Eventuell hat er/sie da auch was anderes gemeint, das möchte ich nicht ausschließen. Vielleicht gibt es dazu ja noch eine Klarstellung von @gennergy

[gennergy]

Am besten nochmal in einem Satz.
Ich möchte nicht, dass das Akku entleeren gesperrt wird, weil ein Netzladeplan für den Akku exisitiert aber kein tatsächliches Laden des Akkus statt findet.

[gennergy]

Every five minutes, the script calculates when the battery would be full if it switched to grid charging at that moment. If that projected completion time falls within five minutes of the cheap-rate window ending, it switches to grid charging. Otherwise it stays in zero-export mode.

I'm not a fan of external scripts. A few EVCC updates down the road, and the script might no longer work.

[volsk]

I'm not a fan of external scripts. A few EVCC updates down the road, and the script might no longer work.

I can't argue with that. But currently the functionality is lacking in EVCC itself.

The mentioned script zur Belehrung und Unterhaltung: battery.sh

[blappm]

Hallo zusammen

Habt ihr nun ein ein Lade/Entladefahrplan Skript gemacht, oder kann das bestehende Skript erst einfach laden?

Ich habe für das PEVO EMS (welches auch EVCC unter der Haube hat), ein solches Skript gemacht, welches ohne externen Aufruf/API auskommt. Aber ist halt nicht in Go programmiert sondern python ...

Produktionsprognose-, Verbrauchsprognose-Leistung , sowie Verkaufs- und Kaufpreise können als CSV-Liste
gefüttert werden, so dass man alles schön simulieren kann. Das ganze funktioniert auch mit Last-Peak-Shave
zusammen. Speicher laden vom Netz ist aber derzeit gesperrt, weil das bei uns in der Schweiz weder sinnvoll (man zahlt immer die Netzkosten dazu), noch wirklich erlaubt ist (man verliert eine Prämie namens Herkunftsnachweis).

usage: linopt-battery.py [-h] -c CAPACITY [-d DATE] [-S] [-M] [-O] [--current-soc CURRENT_SOC]
[--tarifs-yaml TARIFS_YAML] [--min-soc MIN_SOC] [--max-soc MAX_SOC] --max-charge
MAX_CHARGE [--min-charge-trigger MIN_CHARGE_TRIGGER] --max-discharge MAX_DISCHARGE
[--min-discharge-trigger MIN_DISCHARGE_TRIGGER] [--peak-shaving-kw PEAK_SHAVING_KW]
[--is-holiday | --no-is-holiday] [--efficiency EFFICIENCY] [--flex-kw FLEX_KW]
[--flex-hours FLEX_HOURS] [--flex-already-run FLEX_ALREADY_RUN]
[--flex-price-threshold FLEX_PRICE_THRESHOLD]
[--amortization-cost AMORTIZATION_COST] [--min-profit-margin MIN_PROFIT_MARGIN]
[--uuid UUID] [--battype {AC,DC}] [--pdeliveryhour PDELIVERYHOUR]
[--market-premium MARKET_PREMIUM] [--selfconsumption-only]
[--charge-incentive-mode {early,late,none}]
[--discharge-incentive-mode {early,late,none}] [--pv-forecast PV_FORECAST]
[--consumption CONSUMPTION] [--buy-forecast BUY_FORECAST]
[--sell-forecast SELL_FORECAST] [--json-output]

Als Output bekommt man dann einen Fahrplan, den man für Steuerungen verwenden kann.

Führe Optimierung mit cmd '['/usr/bin/python3.11', '/bin/linopt-battery.py', '--uuid', '850716b0-2d62-499e-a0b6-508fccd52861', '--capacity', '38', '--max-charge', '19', '--max-discharge', '19', '--min-soc', '10', '--max-soc', '100', '--tarifs-yaml', 'tarifs.yaml', '--flex-price-threshold', '0.15', '--amortization-cost', '0.035', '--min-charge-trigger', '0.1', '--min-discharge-trigger', '0.5', '--efficiency', '95', '--market-premium', '0.04']' aus für: 'Automatische Batteriesteuerung (Ladung/Entladung)' (850716b0-2d62-499e-a0b6-508fccd52861)...
Erfolg: INFO: Morgen-Datei existiert noch nicht (vor 19 Uhr). Temporäre Spiegelung aktiv.
INFO: Launching single 48h optimization with 4-block time-bands...
48h EMS-OPTIMIERUNGS-PLAN
Std | Kauf-P | Verk-P | PV | Verbr | FlexGer | Akku Lad | Akku Ent | NetzKauf | NetzVerk | Abreg | Akku-SOC | Prio-% | Cashflow

07:00 | 0.3387 | 0.1855 | 2.04 | 0.50 | - | - | 14.44kW | - | 15.26kW | - | 3.80kWh(10.0%) | 0 % | 2.17 CHF
08:00 | 0.3387 | 0.1698 | 4.33 | 0.87 | - | - | - | - | 3.46kW | - | 3.80kWh(10.0%) | 9 % | 0.00 CHF
09:00 | 0.3387 | 0.1331 | 7.88 | 1.74 | 6.15kW | - | - | - | 6.15kW | - | 3.80kWh(10.0%) | 29 % | 0.00 CHF
10:00 | 0.3387 | 0.1057 | 11.59 | 0.79 | 10.81kW | - | - | - | 10.81kW | - | 3.80kWh(10.0%) | 43 % | 0.00 CHF
11:00 | 0.3387 | 0.0789 | 13.20 | 0.65 | 12.56kW | - | - | - | 12.56kW | - | 3.80kWh(10.0%) | 58 % | 0.00 CHF
12:00 | 0.3387 | 0.0526 | 13.71 | 0.42 | - | 13.28kW | - | - | - | - | 17.08kWh(44.9%) | 72 % | -0.61 CHF
13:00 | 0.3387 | 0.0463 | 14.09 | 0.40 | - | 13.69kW | - | - | - | - | 30.77kWh(81.0%) | 75 % | -0.63 CHF
14:00 | 0.3387 | 0.0534 | 12.47 | 0.48 | 4.76kW | 7.22kW | - | - | 4.76kW | - | 37.99kWh(100.0%) | 71 % | -0.33 CHF
15:00 | 0.3387 | 0.0994 | 9.28 | 1.00 | 8.28kW | - | - | - | 8.28kW | - | 37.99kWh(100.0%) | 47 % | 0.00 CHF
16:00 | 0.3387 | 0.1259 | 7.83 | 0.54 | 7.29kW | - | - | - | 7.29kW | - | 37.99kWh(100.0%) | 32 % | 0.00 CHF
17:00 | 0.3387 | 0.1415 | 6.44 | 0.79 | 5.66kW | - | - | - | 5.66kW | - | 37.99kWh(100.0%) | 24 % | 0.00 CHF
18:00 | 0.3387 | 0.1626 | 3.55 | 0.73 | - | - | - | - | 2.81kW | - | 37.99kWh(100.0%) | 13 % | 0.00 CHF
19:00 | 0.3387 | 0.1857 | 1.05 | 0.72 | - | - | - | - | 0.33kW | - | 37.99kWh(100.0%) | 0 % | 0.00 CHF
20:00 | 0.3387 | 0.1864 | 0.04 | 1.03 | - | - | 19.00kW | - | 17.06kW | - | 18.99kWh(50.0%) | 0 % | 2.88 CHF
21:00 | 0.2772 | 0.1839 | 0.00 | 0.86 | - | - | 0.91kW | - | - | - | 18.08kWh(47.6%) | 1 % | 0.14 CHF
22:00 | 0.2772 | 0.1647 | 0.00 | 1.00 | - | - | 1.05kW | - | - | - | 17.03kWh(44.8%) | 12 % | 0.14 CHF
23:00 | 0.2772 | 0.1491 | 0.00 | 1.41 | - | - | 1.48kW | - | - | - | 15.55kWh(40.9%) | 20 % | 0.17 CHF
--- FOLGETAG -------------------------------------------------------------------------------------------------------------------
00:00 | 0.2772 | 0.1458 | 0.00 | 1.34 | - | - | 1.41kW | - | - | - | 14.14kWh(37.2%) | 22 % | 0.16 CHF
01:00 | 0.2772 | 0.1436 | 0.00 | 0.73 | - | - | 0.77kW | - | - | - | 13.37kWh(35.2%) | 23 % | 0.08 CHF
02:00 | 0.2772 | 0.1427 | 0.00 | 0.74 | - | - | 0.78kW | - | - | - | 12.59kWh(33.1%) | 23 % | 0.08 CHF
03:00 | 0.2772 | 0.1427 | 0.00 | 0.69 | - | - | 0.72kW | - | - | - | 11.87kWh(31.2%) | 23 % | 0.08 CHF
04:00 | 0.2772 | 0.1434 | 0.00 | 0.77 | - | - | 0.81kW | - | - | - | 11.06kWh(29.1%) | 23 % | 0.09 CHF
05:00 | 0.2772 | 0.1499 | 0.00 | 0.61 | - | - | 0.64kW | - | - | - | 10.42kWh(27.4%) | 20 % | 0.07 CHF
06:00 | 0.3387 | 0.1807 | 0.38 | 0.77 | - | - | - | - | - | - | 10.42kWh(27.4%) | 3 % | 0.00 CHF
07:00 | 0.3387 | 0.1855 | 1.98 | 0.99 | - | - | 6.21kW | - | 6.89kW | - | 4.21kWh(11.1%) | 0 % | 0.94 CHF
08:00 | 0.3387 | 0.1698 | 5.28 | 0.44 | - | - | - | - | 4.84kW | - | 4.21kWh(11.1%) | 9 % | 0.00 CHF
09:00 | 0.3387 | 0.1331 | 9.27 | 0.55 | 8.72kW | - | - | - | 8.72kW | - | 4.21kWh(11.1%) | 29 % | 0.00 CHF
10:00 | 0.3387 | 0.1057 | 12.55 | 0.60 | 11.95kW | - | - | - | 11.95kW | - | 4.21kWh(11.1%) | 43 % | 0.00 CHF
11:00 | 0.3387 | 0.0789 | 14.63 | 2.42 | 12.21kW | - | - | - | 12.21kW | - | 4.21kWh(11.1%) | 58 % | 0.00 CHF
12:00 | 0.3387 | 0.0526 | 16.24 | 0.63 | - | 15.61kW | - | - | - | - | 19.82kWh(52.2%) | 72 % | -0.72 CHF
13:00 | 0.3387 | 0.0463 | 17.03 | 2.38 | - | 14.65kW | - | - | - | - | 34.47kWh(90.7%) | 75 % | -0.68 CHF
14:00 | 0.3387 | 0.0534 | 14.49 | 2.63 | 7.92kW | 3.94kW | - | - | 7.92kW | - | 38.00kWh(100.0%) | 71 % | -0.18 CHF
15:00 | 0.3387 | 0.0994 | 11.19 | 1.45 | 9.75kW | - | - | - | 9.75kW | - | 38.00kWh(100.0%) | 47 % | 0.00 CHF
16:00 | 0.3387 | 0.1259 | 8.13 | 1.37 | 6.76kW | - | - | - | 6.76kW | - | 38.00kWh(100.0%) | 32 % | 0.00 CHF
17:00 | 0.3387 | 0.1415 | 4.53 | 1.07 | 3.46kW | - | - | - | 3.46kW | - | 38.00kWh(100.0%) | 24 % | 0.00 CHF
18:00 | 0.3387 | 0.1626 | 2.00 | 0.61 | - | - | - | - | 1.38kW | - | 38.00kWh(100.0%) | 13 % | 0.00 CHF
19:00 | 0.3387 | 0.1857 | 0.48 | 0.54 | - | - | 12.80kW | - | 12.10kW | - | 25.20kWh(66.3%) | 0 % | 1.93 CHF
20:00 | 0.3387 | 0.1864 | 0.01 | 1.09 | - | - | 19.00kW | - | 16.97kW | - | 6.20kWh(16.3%) | 0 % | 2.88 CHF
21:00 | 0.2772 | 0.1839 | 0.00 | 0.86 | - | - | 0.90kW | - | - | - | 5.30kWh(13.9%) | 1 % | 0.13 CHF
22:00 | 0.2772 | 0.1647 | 0.00 | 0.83 | - | - | 0.87kW | - | - | - | 4.43kWh(11.7%) | 12 % | 0.11 CHF
23:00 | 0.2772 | 0.1491 | 0.00 | 0.00 | - | - | - | - | - | - | 4.43kWh(11.7%) | 20 % | 0.00 CHF