Neue Ladesteuerung mit PV Integration: EVCC ist Open Source!

[andig]

Hallo Zusammen,

nach 2 Monaten Arbeit möchte ich Euch heute meine EV Charge Controller Software zur PV-gesteuerten Ladung vorstellen. Unter dem Namen EVCC findet ihr sie auf Github unter https://github.com/andig/evcc:



EVCC funktioniert ähnlich wie OpenWB, unterstützt aber auch- da mein Anwendungsfall- Wallbe Boxen. Ein Raspberry Pi ist nicht notwendig- EVCC kann auf jedem PC, auch als Docker Container betrieben werden und muss nicht wie bei OpenWB in der Wallbox lokalisiert sein. Alle Daten können in InfluxDB erfasst und mit Grafana ausgewertet werden. Informationen über den Ladevorgang sind über Telegram oder Pushover verfügbar. Die Konfiguration erfolgt mit Hilfe einer strukturierten yaml Datei.

Wenn OpenWB Eure Anforderungen erfüllt gibt es keinen Grund zu wechseln. Wenn ihr neugierig seid, EVCC ausprobieren wollt oder helfen es weiter zu entwickeln freue ich mich hier oder auf GitHub über Feedback.

VG

[goebelmeier]

Oh, wie großartig! Damit ist soeben die Entscheidung gegen openWB mit go-eCharger und für evcc mit wallbe Eco 2.0s - 11kW gefallen. Mein e-Up kommt voraussichtlich im Juni. Die Daten meiner Zähler (1x Zweirichtungs-eHZ für Bezug und Lieferung, 1x Produktions-eHZ und alle Zählerdaten aus einem E3DC S10E) laufen bereits in MQTT rein, so dass ich mir vorstellen kann, dass das Ding ruckzuck lauffähig ist. Ich bin gespannt und volle Vorfreude.

[Colonia1948]

Ich hänge mich da mal kurz dran, da ich auch Interesse an einer PV-GESTEUERTEN Wallbox habe: Gibt's die Wallbe Eco auch mit längerem Kabel (min. 7m)? Danke.

[andig]

Oh, wie großartig! Damit ist soeben die Entscheidung gegen openWB mit go-eCharger und für evcc mit wallbe Eco 2.0s - 11kW gefallen.

Perfekt- ich freue mich auf weiteres Feedback und würde Dich gerne dabei begleiten und die Lösung weiter verfeinern. Ich nutze sie heute schon um mein PHEV damit PV-geführt zu laden.

Der guten Ordnung halber muss aber auch erwähnt werden, dass:
a) OpenWB seit längerem existiert und eine große Anwendergemeinde hat
b) OpenWB viele Features hat die evcc nicht hat und die ich auch nicht plane
c) Wallbe der Meinung ist dass die Garantie bei Nutzung der Schnittstelle entfällt

Unabhängig davon bin ich zu dem Schluss gekommen, dass die Wallbe als Eco S ggü. der OpenWB Hardware- auch preislich- für meinen Anwendungsfall die bessere Lösung ist. Das ist kein Argument gegen OpenWB per se. Meld Dich einfach wenn Du soweit bist, konkrete Issues bitte im Github aufmachen.

Ich hänge mich da mal kurz dran, da ich auch Interesse an einer PV-GESTEUERTEN Wallbox habe: Gibt's die Wallbe Eco auch mit längerem Kabel (min. 7m)? Danke.

Gibt es (10m), dann bist Du aber nicht mehr bei der günstigen Eco S. Einfach mal in den Shop schauen...

Hallo andig,

ein paar Fragen:
* Wenn man den PC nicht 24/7 laufen lassen möchte, kann man das Docker-file auch auf einen stromsparenden RPi werfen?
* Deine SW sollte ja 24/7 verfügbar sein, oder?
* Aufruf mit IP-Adresse?

VG U x I

[andig]

Hallo umali,

mir fehlt leider der "Zitieren" Button bei deinem Beitrag, deshalb Antworten inline:

Deine SW sollte ja 24/7 verfügbar sein, oder?

Ja. Natürlich kann man sie stoppen, ab da läuft die WB eben mit ihrer "normalen" Funktion ohne externe Steuerung weiter.

Aufruf mit IP-Adresse?

Und Port, ja. Standardmäßig ist Port 7070 eingestellt, Aufruf lokal wäre also http://ip:7070

Wenn man den PC nicht 24/7 laufen lassen möchte, kann man das Docker-file auch auf einen stromsparenden RPi werfen?

Kann man, ja. Es gibt verschiedene Möglichkeiten:

a) Mit Docker. Docker-CE wird seit dem Raspi3 unterstützt. Der Aufruf wäre genau wie beschrieben:

Code: Alles auswählen

docker run andig/evcc

Die Hürde bzgl. Docker auf dem Raspi ist die CPU Architektur. Im Moment stelle ich noch kein Image für ARM v6/v7 bereit, ist aber geplant. Damit bleiben die weiteren Optionen.

b) Nutzung von go zur Installation:

Code: Alles auswählen

sudo apt-get install golang
go install github.com/andig/evcc

Damit wird das Programm installiert.

c) Selbst bauen:

Code: Alles auswählen

git clone https://github.com/andig/evcc
cd evcc
go build ./... oder
go run github.com/andig/evcc

Um Euch/Dir das zu vereinfachen habe ich das Binary für den Raspi hier angehängt.

[andig]

Update: Binary wurde nicht hochgeladen, Fehlermeldung gabs auch keine. Ich hab's mit in Github abgelegt: https://github.com/andig/evcc/releases/tag/0.1

Hallo umali,
mir fehlt leider der "Zitieren" Button bei deinem Beitrag, deshalb Antworten inline:

Mir auch. Liegt vermutlich an der neuen Foren-SW. Scheint als ob da eine Verzögerung eingebaut ist (nervig).

Wenn man den PC nicht 24/7 laufen lassen möchte, kann man das Docker-file auch auf einen stromsparenden RPi werfen?

Kann man, ja. Es gibt verschiedene Möglichkeiten:

a) Mit Docker. Docker-CE wird seit dem Raspi3 unterstützt. Der Aufruf wäre genau wie beschrieben:

Code: Alles auswählen

docker run andig/evcc

Die Hürde bzgl. Docker auf dem Raspi ist die CPU Architektur. Im Moment stelle ich noch kein Image für ARM v6/v7 bereit, ist aber geplant. Damit bleiben die weiteren Optionen.

b) Nutzung von go zur Installation:

Code: Alles auswählen

sudo apt-get install golang
go install github.com/andig/evcc

Damit wird das Programm installiert.

c) Selbst bauen:

Code: Alles auswählen

git clone https://github.com/andig/evcc
cd evcc
go build ./... oder
go run github.com/andig/evcc

Um Euch/Dir das zu vereinfachen habe ich das Binary für den Raspi hier angehängt.

Alle klar - Danke!
Nativ ist dann vermutlich die bevorzugte Methode, korrekt?

Noch eine Anschlussfrage:
Wie verhält es sich mit der Speichernutzung? In openWB ist eine RAM-Disk vorgesehen. Ist so etwas bei EVCC implementiert oder muss man das vor der Install händisch erledigen und danach noch anpassen?

Außer den RPi (oder andere embedded devices) fallen mir jetzt nur Server oder NAS ein, die 24/7 laufen, wo EVCC installiert werden könnte. Allerdings halte ich den RPi als vollständig eigenständige Mini-HW für eine so wichtige Sache wie EV-Laden für geeigneter.

VG U x I

[andig]

andig hat geschrieben: ↑

Alle klar - Danke!
Nativ ist dann vermutlich die bevorzugte Methode, korrekt?

Ich würde es vom Anwendungsfall abhängig machen. Bei mir läuft EVCC auf dem NAS- da ist Docker das Mittel der Wahl. Auf einen Raspi im Außenbereich kann ich verzichten. Wenns auf dem Raspi laufen soll würde ich das nativ als systemd Service machen.

Noch eine Anschlussfrage:
Wie verhält es sich mit der Speichernutzung? In openWB ist eine RAM-Disk vorgesehen. Ist so etwas bei EVCC implementiert oder muss man das vor der Install händisch erledigen und danach noch anpassen?

Die Architektur ist anders:
OpenWB kommt als vollständige Disktribution. Bei OpenWB laufen Shellskripte die ihre Daten über die Ramdisk austauschen.
Bei EVCC läuft eine Applikation die alle Kommunikation intern abwickelt. Wenn externe Skripte eingebunden werden (was möglich ist, siehe https://github.com/andig/evcc/blob/mast ... .dist.yaml) wird der Output direkt geparst und weiter verwendet ohne notwendige Zwischenspeicherung. Wird bei EVCC das Logging abgeschaltet (oder das Logfile auf eine Ramdisk verlagert) so entstehen keine Schreibzugriffe auf die SD Karte.

Viele Grüße, Andreas

PS.: ein Effekt der anderen Architektur ist z.B. auch dass EVCC nicht mal einen Webserver für die Benutzeroberfläche braucht und insgesamt einfach minimale Systemanforderungen stellt. Deshalb lässt sich das auch als Applikation statt als fertiges Image ausliefern.

Ich switche mit den Details mal besser hierher:

Keinen integrierten, kann aber einen externen Zähler als Modbus Master ansteuern. Dafür hat sie aber eine Menge Ein- und Ausgänge die sich z.T. auch frei konfigurieren lassen. Wunsch: darüber die Phasenumschaltung realisieren. Externer Zähler ist für EVCC nicht wichtig- ein solcher Zähler kann dann auch direkt ausgelesen werden ohne mit der Wallbe gekoppelt sein zu müssen.

Bekommst Du die Zählerwerte per LAN (Register?), wenn der Zähler per RS485 direkt mit der Wallbe verbunden ist?
Wie ermittelst Du ohne Zähler die Ladeleistung? Oder werden da nur die Vorgabewerte abgebildet?

Ich nehme an, dass Du bevorzugt mit dem EVU-Smartmeter arbeitest, sonst wird das ja nichts Vernünfiges mit Nullausregelung am EVU-Übergabepunkt (steht auch so auf Github).

Der tatsächliche Istwert der Ladeleistung ist meist nur dann interessant, wenn das Auto nicht mehr dem Sollwert folgen kann (Ladeende o.ä.), also nicht so dramatisch. Allerdings fände ich die Zählung der Ladeenergiemenge schon wichtig.
Hast Du die nicht implementiert? Reine Ausregelung?

VG U x I