evcc-io
Lastmanagement
Fortführung von PR3453
Dokumentation: lastmanagement
Download unter Relases ab v0.118.0.
use cases
- Lastbegrenzung: bestimmte Leistung in einem Stromkreis nicht überschreiten
- zB alle Wallboxen zusammen max 11kW
- zB max Leistung am Netzpunkt <= 5kW
- Infrastrukturschutz: Strom begrenzen im Stromkreis zum Schutz der Sicherung oder Leitungen
- zB max Strom < 20A im Stromkreis (pro Phase)
Arbeitsweise
- Begrenzung erfolgt immer in einem Stromkreis
- Stromkreise können hierarchisch sein
- Stromkreis kann ein physisches Meter haben, muss aber nicht. In diesem Fall wird der Verbrauch aller LP im Kreis benutzt
- Bei Überschreiten der maximalen Leistung oder des maximalen Stroms werden die LP im jeweiligen Kreis im maximalen Strom begrenzt
- die Prüfung der maximalen Leistung und des maximalen Stroms erfolgt unabhängig und pro Stromkreis, es kann also beides, eines von beider oder keins geprüft werden.
Konfigurationserweiterung für Lastmanagement:
- Stromkreise (Circuits) definieren. Es kann (muss aber nicht) ein Hauptkreis angelegt werden, welcher den Zähler der PV verwenden kann. Weitere Stromkreise liegen darunter und können optional eigene Zähler für die Unterverteilung haben. Falls kein physischer Zähler für einen Stromkreis vorhanden ist, wird der Verbrauch aus der Summe aller zugeordneten LP und Unterkreise bestimmt.
- pro Stromkreis kann die maximale Leistung (in kW) oder der maximale Strom (in Ampere) angegeben werden
circuits:
- name: main
maxCurrent: 0
maxPower: 6
meter: grid1
parent:
- name: zaun
maxCurrent: 14
meter:
parent: main
- name: garage
maxCurrent: 12
meter:
parent: main
- Loadpoints einzelnen Stromkreisen zuordnen. Mehrere Loadpoints können einem Circuit zugeordnet werden.
loadpoints:
- title: GarageLinks
circuit: garage
Die Konfiguration der Circuits kann mit Hilfe des Konfigurationsassistenten im "advanced" Modus erfolgen.
evcc configure --advanced
Installation / Test
Beispielhaft Linux: siehe auch hier für die Schritte: Installation
Manueller Test
Nur das Binary um mal zu gucken obs was tut.
mkdir evcc-test && cd evcc-test
# download and extract
wget https://github.com/hoermto/evcc/releases/download/v0.104.2-lloadmanagement/evcc_v0.104.2-lloadmanagement-next_linux_amd64.tar.gz
tar -xzvf evcc_v0.104.2-lloadmanagement-next_linux_amd64.tar.gz
# create / modify configuration
vi evcc.yaml
<edit / copy file>
# manual start for testing, ctrl+c to stop
./evcc -c evcc.yaml
# start in background to remain running after shell exit
nohup ./evcc -c evcc.yaml&
Installation komplett
Bei bestehender Installation (https://docs.evcc.io/docs/installation/linux), bzw. Neuinstallation:
# download package (use recent version)
wget https://github.com/hoermto/evcc/releases/download/v0.104.2-lloadmanagement/evcc_0.104.2.lloadmanagement-next_amd64.deb
# Entfernen der Standardinstallation, falls vorhanden. Die /etc/evcc.yaml Konfigurationsdatei bleibt dabei erhalten. Es ist aber sinnvoll vorab eine Kopie zu erstellen.
cp /etc/evcc.yaml ~/evcc.yaml.backup
sudo apt-get remove evcc
# Installation
sudo dpkg -i ./evcc_0.104.2~lloadmanagement-next_amd64.deb
# weitere Schritte siehe Installationsanleitung.
Docker
Download: https://github.com/hoermto/evcc-lm/releases die docker-...zip Datei runterladen, und dann mittels docker load -i <zip datei> in das lokale Repository laden:
> docker load -i ./docker_evcc_amd64_0.124.1.tgz
Loaded image: evcc/evcc:testing
Weitere Schritte hier: https://docs.evcc.io/docs/installation/docker.
Für den Namen des images dann aber evcc/evcc:testing verwenden.
Vielen Dank für die Bereitstellung des Release 0.118.0 Feature/lastmanagement.
Wäre es eventuell möglich die Updateanzeige anzupassen, dass nur neue Releases vom Feature/lastmanagement angezeigt werden oder neue Releases vom Hauptzweig?
Would it be possible to join this with charge power regulation using power/current limits phase by phase? For example at this moment my PV generates 25A on each phase, BUT there also a 25A load on one of the phases (cooking/washing etc.) So evcc calculates this as 17,25kW produced, 5,7kW house consumption and 11,5kW available for EV charging.
In such case IF I was charging a car with 11kW I would be using 7,2kW from the sun and 3,7kW from the grid. This then would be billed separately as simultaneous power export (2phase @1.9kW each) and 3.7kW import on the "busy" third phase.
I would like to avoid using power from the grid, if possible in such cases.
Would it be possible to join this with charge power regulation using power/current limits phase by phase? For example at this moment my PV generates 25A on each phase, BUT there also a 25A load on one of the phases (cooking/washing etc.) So evcc calculates this as 17,25kW produced, 5,7kW house consumption and 11,5kW available for EV charging.
In such case IF I was charging a car with 11kW I would be using 7,2kW from the sun and 3,7kW from the grid. This then would be billed separately as simultaneous power export (2phase @1.9kW each) and 3.7kW import on the "busy" third phase.
I would like to avoid using power from the grid, if possible in such cases.
Limitation fur current is per phase, because fuses are installed per phase. We don't support phase accurate management, since evcc does not know the phase wiring for each load point.
Power limitation is per loadpoint total, and works parallel.
In your case, where are you from (e.g. how is the PV connected to the grid and how its metered)? In DE the grid meter always takes the aggregated power into consideration, so P1 consumption of 20A and P2 + P3 feeding to grid of 10A each would result in 0 power consumption. So you would need to set the current limit to 0 on the grid meter to prevent any grid consumption, with potentially disabled LP if one phase is utilized more than others.
Would it be possible to join this with charge power regulation using power/current limits phase by phase? For example at this moment my PV generates 25A on each phase, BUT there also a 25A load on one of the phases (cooking/washing etc.) So evcc calculates this as 17,25kW produced, 5,7kW house consumption and 11,5kW available for EV charging.
In such case IF I was charging a car with 11kW I would be using 7,2kW from the sun and 3,7kW from the grid. This then would be billed separately as simultaneous power export (2phase @1.9kW each) and 3.7kW import on the "busy" third phase.
I would like to avoid using power from the grid, if possible in such cases.
Nee, mein Ziel ist es nicht den aktuellen Zustand durch solche Massnahmen zu persistieren. Entweder es gibt einen Merge, oder nicht. Ohne Merge wird der Punkt kommen wo dieser Branch nicht weitergepflegt wird.
Bitte bitte merged das in den Main branch :) Ich brauche das unbedingt
@hoermto Frage: Dürfen die Werte maxCurrent / maxPower Resultate aus (shell)-scripts sein oder müssen es constants sein?
@hoermto Frage: Dürfen die Werte maxCurrent / maxPower Resultate aus (shell)-scripts sein oder müssen es constants sein?
aktuell stehen die Werte im Configfile und werden beim Start gelesen. Damit sind sie fix für die Laufzeit - also nicht dynamisch, falls das die Frage ist. Du kannst natürlich die Limite aus Sktipten errechnen, aber dann müsste evcc neu gestartet werden. Was ist der Usecase für dynamische Limits?
Usecase: Mein VNB verechnet mir zusätzlich zur Energie jeden Monat die in einem 15-minuten Intervall maximal bezogene Leistung zu Hochtarif-Zeiten. Der Hochtarif ist Mo-Fr 07-20 Uhr und Sa, 07-13 Uhr. Im Niedertarif (alle anderen Zeiten) ist die bezogene Spitzenleistung egal. Zumindest in der Schweiz ist die Lastgangmessung/-verrechnung für Bezüger ab 50MWh oder 100MWh pro Jahr sehr üblich, wahrscheinlich auch in Deutschland. Denn die Spitzenlast ist schlussendlich entscheidend dafür, wie gross das Stromnetz gebaut werden muss, d.h. es macht sogar Sinn, wenn man Bezüger, die kurzzeitig hohe Spitzen im Netz verursachen, finanziell bestraft.
Der Spitzenlast-Preis ist substanziell (CHF 13.90 pro Monat und kW), d.h. das Ziel ist, wenn irgendwie möglich die Spitzenlast durch e-mobility nicht zu erhöhen. Leider ist sie in meinem Fall jeden Monat auch stark unterschiedlich. Im Sommer drücken die PV-Anlagen die bezogene Spitzenlast in die 20kW Gegend, im Winter habe ich leider zum Teil 40kW Spitzenlast.
Aus dieser Situation ergeben sich zwei Ideen, warum ich das gerne dynamisch hätte:
- Das Limit soll eben nur im Hochtarif gelten, in der Nacht ist "freies Laden für freie Bürger".
- Wenn die Spitzenlast in einem Monat bereits durch nicht-e-mobility Verbraucher hoch wurde, dann kann ich auch für die e-mobility zu Hochtarif-Zeiten mehr Last freischalten.
Allerdings, wenn ichs mir jetzt so überlege, hätte ich eigentlich genau 2 rule-changes pro Tag. Das könnte man auch über neustarts von evcc lösen. Aber schön wärs natürlich dennoch, sofern es mit wenig Aufwand möglich wäre.
Usecase: Mein VNB verechnet mir zusätzlich zur Energie jeden Monat die in einem 15-minuten Intervall maximal bezogene Leistung zu Hochtarif-Zeiten. Der Hochtarif ist Mo-Fr 07-20 Uhr und Sa, 07-13 Uhr. Im Niedertarif (alle anderen Zeiten) ist die bezogene Spitzenleistung egal. Zumindest in der Schweiz ist die Lastgangmessung/-verrechnung für Bezüger ab 50MWh oder 100MWh pro Jahr sehr üblich, wahrscheinlich auch in Deutschland. Denn die Spitzenlast ist schlussendlich entscheidend dafür, wie gross das Stromnetz gebaut werden muss, d.h. es macht sogar Sinn, wenn man Bezüger, die kurzzeitig hohe Spitzen im Netz verursachen, finanziell bestraft.
Der Spitzenlast-Preis ist substanziell (CHF 13.90 pro Monat und kW), d.h. das Ziel ist, wenn irgendwie möglich die Spitzenlast durch e-mobility nicht zu erhöhen. Leider ist sie in meinem Fall jeden Monat auch stark unterschiedlich. Im Sommer drücken die PV-Anlagen die bezogene Spitzenlast in die 20kW Gegend, im Winter habe ich leider zum Teil 40kW Spitzenlast.
Aus dieser Situation ergeben sich zwei Ideen, warum ich das gerne dynamisch hätte:
1. Das Limit soll eben nur im Hochtarif gelten, in der Nacht ist "freies Laden für freie Bürger". 2. Wenn die Spitzenlast in einem Monat bereits durch nicht-e-mobility Verbraucher hoch wurde, dann kann ich auch für die e-mobility zu Hochtarif-Zeiten mehr Last freischalten.Allerdings, wenn ichs mir jetzt so überlege, hätte ich eigentlich genau 2 rule-changes pro Tag. Das könnte man auch über neustarts von evcc lösen. Aber schön wärs natürlich dennoch, sofern es mit wenig Aufwand möglich wäre.
Danke für die Info. Ich selbst plane das aktuell nicht einzubauen. Das geht in Richtung "Planner" - evcc macht momentan ne ganze Menge im alten "PV" Modus (jetzt: auto o.ä.). Da es keinen Merge gibt, will ich das auch nicht weiter aufblasen. Aber generell gibts einen absehbaren Zielkonflikt mit dem geplanten Laden und dem Lastmanagement (aus diesem Branch), weil der Planer afaik momentan davon ausgeht, dass immer ausreichend Strom zur Verfügung steht. Aber das Leistungslimit im Planer ist durchaus eine überlegenswerte Option.
Ich stecke nicht so tief in der Materie drin - was heißt das Merge tag '0.118.1' into feature/lastmanagement ???
Gibts irgend eine Timeline für diesen PR? Der ist ja irgendwie mittlerweile ein Jahr alt. Können wir mit einem merge rechnen, und wenn ja, wann? Ich brauche das Feature unbedingt und der verständliche Standpunkt von @hoermto das Ding irgendwann sterben zu lassen wenns keinen Merge gibt, ist keine schöne Aussicht. Dauernd rebasen macht sicher nur begrenzt Spass. @andig
Das heisst dass der code zusammengeführt wurde. Es gibt aber ein Problem beim Test, weswegen noch kein Release da ist.
Da es keinen Merge gibt, will ich das auch nicht weiter aufblasen.
@hoermto oder sonst jemanden: Weiss jemand, woran es liegt, dass das so lange schon rumliegt? Igendwie ist seitens der Maintainer absoulte Funkstille zu diesem Thema, in anderen sind sie aber recht aktiv. "Keine Zeit / Interesse / Priorität" wäre ja auch schonmal ne Ansage, da weiss man wodran man ist.
Genau das: Komplexes Feature, äusserst knappe Zeitressourcen. Irgendwann wird es klappen. Derzeit liegt der Fokus auf noch dringenderen und noch komplexeren Dingen wie z.B. der Konfig über die Web-UI.
Das Feature ist wirklich super und extrem wichtig, da man mit der WB eine Dauerlast in seiner Anlage hat und letztere dann auf 32A bzw. 44A begrenzen muss. Das kann dann im EFH dann schon einmal eng werden. Kann es aber sein, dass in dem Lastmanagement Release nicht alles andere drin ist? Z.B. läuft damit mit Elli leider nicht, so dass ich wieder zurück musste auf das offizielle Release.
Das Feature ist wirklich super und extrem wichtig, da man mit der WB eine Dauerlast in seiner Anlage hat und letztere dann auf 32A bzw. 44A begrenzen muss. Das kann dann im EFH dann schon einmal eng werden. Kann es aber sein, dass in dem Lastmanagement Release nicht alles andere drin ist? Z.B. läuft damit mit Elli leider nicht, so dass ich wieder zurück musste auf das offizielle Release.
Es ist das offizielle Release, und es gibt keine WB spezifischen Anpassungen. Was geht denn nicht? Die besten Ergebnisse werden mit WB mit eigenem Zähler erreicht, und solchen die nciht zu träge reagieren.
Das scheint das alte Elli Zertifikat Problem zu sein. Soweit ich mit erinnere wird zur Erstellung des regulären evcc Release eine angepasste go Version genutzt, um das Problem zu umgehen. Hier der Auszug aus dem Trace:
[eebus ] DEBUG 2023/07/13 22:40:34 trying to connect to c7bf45556a9527c8f16c48e9cd7bb6b5c4aa1e45 at 192.168.70.2
[eebus ] DEBUG 2023/07/13 22:40:34 initiating connection to c7bf45556a9527c8f16c48e9cd7bb6b5c4aa1e45 at 192.168.70.2:4712
[eebus ] DEBUG 2023/07/13 22:40:34 connection to c7bf45556a9527c8f16c48e9cd7bb6b5c4aa1e45 failed: tls: failed to parse certificate from server: x509: invalid basic constraints b
Die Pakete werden mit einem Standard Go 1.20 gebaut, das Dockerimage durch das Dockerfile aus dem Projekt.
@hoermto Um die Elli Wallboxen zu unterstützen, musst du (leider) Go patchen. Siehe https://github.com/evcc-io/evcc/blob/master/Makefile#L133-L144
0.118.8 available in releases @scat70 include asn patch
Thanks a lot, Elli works fine so far with this release!
kann mir mal jemand erklären, warum ich auf der RP 4 diesen Fehler bei der Installation bekomme? Danke
@andig @premultiply Besteht die Möglichkeit, dass die Funktion kurzfristig in das normale release übernommen wird? Wäre für uns sehr hilfreich
0.120.3 available in releases.
- with LM enabled charging now starts with minCurrent always, and increases after in order to prevent spikes on start and cover slower devices, to have time to be considered in consumption evaluation.
Vielen Dank für dieses Feature, funktioniert für mich wunderbar!
Szenario hier: der Hausanschluss ist mit 50A abgesichert, der Zweirichtungszähler verträgt aber nur 40A. Daher sind die Hauptsicherungen auch auf 40A ausgelegt. Neben der Wallbox (11 kW) gibt es noch einen elektrischen Durchlauferhitzer im Bad (18 kW) und eine Wärmepumpe. Im Winter haben wir es schon geschafft, dass die Hauptsicherung auf der ersten Phase geflogen ist, wenn gleichzeitig das Auto geladen und geduscht wurde.
Mein Testszenario: circuit ergänzt, loadpoint erweitert, maxPower mit 16 hinterlegt (ohne Einheit, das steht oben im Beispiel noch falsch), Schnellladen aktiviert und Dusche aufgedreht. Die Ladeleistung wurde wie gewünscht reduziert, um unter 16 kW Gesamtlast zu bleiben.
Vielen Dank für dieses Feature, funktioniert für mich wunderbar!
Szenario hier: der Hausanschluss ist mit 50A abgesichert, der Zweirichtungszähler verträgt aber nur 40A. Daher sind die Hauptsicherungen auch auf 40A ausgelegt. Neben der Wallbox (11 kW) gibt es noch einen elektrischen Durchlauferhitzer im Bad (18 kW) und eine Wärmepumpe. Im Winter haben wir es schon geschafft, dass die Hauptsicherung auf der ersten Phase geflogen ist, wenn gleichzeitig das Auto geladen und geduscht wurde.
Mein Testszenario: circuit ergänzt, loadpoint erweitert, maxPower mit 16 hinterlegt (ohne Einheit, das steht oben im Beispiel noch falsch), Schnellladen aktiviert und Dusche aufgedreht. Die Ladeleistung wurde wie gewünscht reduziert, um unter 16 kW Gesamtlast zu bleiben.
Danke für den Usecase. Fehler in der Beschreibung behoben.
0.120.3 available in releases.
- with LM enabled charging now starts with minCurrent always, and increases after in order to prevent spikes on start and cover slower devices, to have time to be considered in consumption evaluation.
Hi @hoermto, you don't have a docker image available anywhere, by any chance?
0.120.3 available in releases.
- with LM enabled charging now starts with minCurrent always, and increases after in order to prevent spikes on start and cover slower devices, to have time to be considered in consumption evaluation.
Hi @hoermto, you don't have a docker image available anywhere, by any chance?
in releases link you find this docker image: https://github.com/hoermto/evcc-lm/releases/download/0.120.3-loadmanagement/docker_evcc_amd64_0.120.3-loadmanagement.tgz