docolli: E3DC S10E Hauskraftwerk & Easy Connect Wallbox 11kW, FHEM, rscp2mqtt, MyStrom Wifi Switch, Nissan Leaf ZE1
Gleich vorneweg:
Wer ein E3/DC Hauskraftwerk (HKW) und die Easy Connect Wallbox zusammen mit evcc betreiben will, sollte unten in den Bereich "Wallbox" schauen. Dort habe ich beschrieben, wie es inzwischen möglich ist, dass das HKW weiterhin lesend die Werte der Wallbox bekommt, ohne störend in die evcc Steuerung reinzugrätschen. So bekommt man weiterhin die korrekten Werte des reinen Hausverbrauchs (sonst sind die Ladungen der Wallbox mit drin), hat die Statistiken für Haus und Auto getrennt im E3/DC Web-Portal und kann sogar die im HKW selbst verbaute Steuerung, bis zu welchem SOC der Hausbatterie diese die Wallboxladung unterstützt, nutzen.
Schon vor fast 10 Jahren habe ich mir einen Raspbery Pi besorgt und darauf Raspbian mit FHEM als Hausautomationssystem installiert. Zunächst hauptsächlich um
- Den insgesamten Stromverbrauch per ELV Energiezähler (mit Sensor für die Ferraris-Scheibe !) aufzuzeichnen
- Einzelne Verbraucher (z.B. Waschmaschine, Trocker) per Zwischenstecker (aktuell MyStrom Wifi Switch) aufzuzeichnen
- Meine Heizungstemperaturen per 1-wire Sensoren aufzuzeichnen
- Die Temperaturen von Solarthermie samt Pufferspeicher aufzuzeichnen
Das Logging erfolgte bis vor 3 Jahren von FHEM aus in Dateien auf der SD-Karte, was aber häufiger zu ärgerlichen Defekten der SD-Karte führte.
Der Raspi darf in einem eigenen Hutschienengehäuse werkeln, Als Stromversorgung habe ich eine kleine USB-USV mit Netzteil gefunden, somit ist bei einem eventuellen Umschalten auf Notstrom, der Raspi weiterhin versorgt.
Später kamen noch weitere 433 / 866Mhz Funkkomponenten hinzu, die alle per USB-CULs am Raspi hängen.
- Außen- und Innentemperaturen (dazu nutze ich die günstigen Technoline TX 29-IT bzw. TX 29 DHT-IT)
- Zisterne- und Heizölstand (Ultraschallsensor FT002)
- Regensensor (ADE WS1907)
- mit der PV kam ein neuer Stromzähler mit optischer Schnittstelle, also Umrüstung von (1.) auf Lesekopf mit Tasmota
- Detektion ob Brenner, Heizungs- bzw. Solarpumpen laufen (über selbst programmierte ESP32 mit Optokopplern)
- Ablesen der Wasseruhr über einen ESP32 mit Kamera (AI on the edge)
- Einbindung des E-Auto (Nissan) über Carwings
Inzwischen erfolgt das Logging auf eine externe MariaDB Instanz auf einem Synology NAS. Auf diesem läuft auch in einer VM ein Alpine Linux, welches Grafana zur Visualisierung der geloggten Daten hostet.
Später (1 Jahr nach PV-Anlage und E-Auto) kam dann in 04/2023 evcc mit auf den Raspi, FHEM wurde um einen MQTT-Broker erweitert und ganz neu (12/2023) ist mit rscp2mqtt ein Programm dazu gekommen, um mein E3/DC HKW komplett per RSCP auszulesen und steuern zu können. Über Modbus lässt das E3/DC leider nur sehr eingeschränkt zu.
Aktuell habe ich meinem FHEM mit FTUI3 eine schöne Oberfläche verpasst und auch ein Android-Tablett an eine Wand geschraubt, über das man mit dem Fullscreen Kiosk-Browser "Fully" auf FHEM (FTUI), evcc und Grafana zugreifen kann.
Die PV-Anlage mit Batteriespeicher kam 04/2022, nachdem ich in unserer Firma gesehen habe, wie gut das funktioniert und wie wenig Kabel dafür vom Dach kommen muss. Ich habe mich für ein E3/DC System entschieden, weil dieses (im Gegensatz zum alternativ angebotenen Senec-System) eine deutliche höhere Lade- und Entladeleistung (4,5kW) hatte und Notstrom- und Inselfähig ist, wobei ich nicht wirklich damit rechne, dass das mal für längere Zeit notwendig wird. Die hohe Ladeleistung hat an Tagen, in denen die Sonne nur kurz, dafür aber intensiv, scheint (wir haben öfters Nebel am Vormittag) Vorteile, da bekommt man den Speicher in 3h komplett voll. In unserer Firma haben wir Senec Speicher, die laden nur mit max. 2kW und brauchen so fast den ganzen Tag, um voll zu werden.
Ich habe 12,6kWp aufgeteilt auf 2 Dachhälften: 8,1kWp sind auf dem SO-Dach, 4,5kWp sind auf dem NW-Dach. Im Juli ist der Peak auf dem SO-Dach um ~12:00h, auf dem NW-Dach um 16:00h.
Was aber viel wichtiger ist (und darum sollte man, wenn möglich, auch nicht ideale Dachflächen mit PV-Panels belegen), ist die Tatsache, dass relativ gesehen bei trübem Wetter beide Dachflächen gleich viel Leistung erzeugen. Die gesamte PV-Leistung ist bei diesem Wetter also nur von der verlegten Fläche, aber nicht von der Ausrichtung abhängig.
Als E3/DC HKW (Wechselrichter und Hausbatterie) habe ich das S10E, zunächst mit 3 Batteriemodulen, bald darauf aber mit 4 Modulen komplett aufgerüstet mit 13,1kWh.
Eine Wallbox habe ich mir gleich mit der PV installieren lassen. Damit alles gut zusammenspielt, habe ich mich für die E3/DC Easy Connect entschieden. Seit die Einbindung sowohl in evcc als auch ins E3/DC System klappt ist diese für mich eigentlich ideal gewählt.
Zu evcc bin ich durch einen Tipp eines Freundes und anschließender Internet Recherche gekommen, weil mich gestört hat, dass ich nirgendwo festlegen konnte (weder im Auto, noch im E3/DC System) bis zu welchem SOC ich das Auto laden will. In der Regel möchte ich nur auf 80% laden, nur in speziellen Fällen soll auf 100% geladen werden.
evcc war rasch installiert und konfiguriert, mit Hilfe der Konfigurationsunterstützung hatte ich schnell das E3/DC-System (Stromzähler, Batterie und Wallbox) angebunden, auch das E-Auto wurde sofort korrekt abgefragt. Also erstmal volle Begeisterung. Leider verflüchtigte sich das rasch, da bei beim gewählten Limit von 80% SOC es zu einem "Out of sync" Error kam und die Wallbox weiter geladen hat. Durch Lesen der Diskussionen wurde mir klar, dass es grundsätzlich gehen kann, andere aber einen modbusproxy nutzen, um das HKW nicht mehr schreibend auf die Wallbox zugreifen zu lassen. Das habe ich so wie beschrieben eingerichtet, dann ging es auch eine Weile (zumindest hat dann evcc seine Funktion prima erfüllt), aber auf E3/DC Seite hatte ich massive Probleme.
Erst nach einiger Zeit fiel mir auf, dass das E3/DC System z.B. nicht mehr erkannt hat, dass eine Ladung beendet wurde, und es hat weiter mit der letzten Ladeleistung viele Stunden (und Tage) als E-Auto Ladung protokolliert. Auch der protokollierte Hausverbrauch war viel höher, da nun die Energie fürs Autoladen dem Haus zugeschlagen wurde. Über den Sommer 2023 hinweg habe ich das so erduldet, bzw. zeitweise in meiner Not die Wallbox im E3/DC System gelöscht gehabt. Glücklich war ich so aber nicht. Da der modbusproxy einen schreibgeschützen Zugriff auf die Wallbox bieten soll, habe ich mich dann im Herbst daran gemacht zu ergründen, weshalb das mit dem E3/DC System zusammen nicht klappt.
Über ein Python-Script habe ich die Modbus-Kommunikation Befehl für Befehl zwischen direkter Kommunikation HKW<->Wallbox und wenn der evcc modbusproxy dazwischen ist HKW<->evcc<->Wallbox verglichen. Dies sowohl wenn der Proxy Schreibbefehle durchlässt, als auch wenn sie blockiert sind. Dabei fiel auf, dass nach einiger Zeit, wenn der modbusproxy Schreibbefehle blockiert, das HKW in einer Sendeschleife für ein und desselben Befehl hängen bleibt. Damit ist die Kommunikation de facto unterbrochen. Grund war (und dank des tollen evcc Teams schnell behoben), dass der modbusproxy blockierte Schreibbefehle bis dahin mit einem Modbusfehler beantwortet hat, dies aber das HKW dazu bewegte, den Befehl endlos immer wieder zu senden.
Seit evcc Version 0.122.1 sendet der modbusproxy mit der Option readonly: true keinen Fehler mehr zurück (siehe PR), damit kommt das E3/DC HKW bestens zurecht. Seither ist evcc problemlos in ein E3/DC HKW und Wallbox System integrierbar.
evcc ist per MQTT an FHEM angebunden.
Ich habe die E3/DC Easy Connect und es war, wie oben beschrieben, leider etwas kniffelig evcc zusammen mit dem E3/DC System problemlos ans Laufen zu bekommen. Die einfachste Vorgehensweise (aber mit Nachteilen) ist, die Wallbox mit ihrer IP-Adresse direkt in evcc wie in der Doku beschrieben einzubinden und anschließend die Wallbox im HKW zu löschen.
Dann ist die Wallbox aus Sicht des HKW aber einfach ein weiterer Hausverbraucher, die aktuelle Leistung und der Stromverbrauch wird somit zur Hausleistung dazu gerechnet. Die schöne Trennung von tatsächlichem Hausverbrauch und E-Auto Ladung hat man in dieser Konfiguration nicht mehr. Auch andere Komfortfunktionen des E3/DC, die auf Werten der Wallbox beruhen, funktionieren nicht mehr.
Wichtig ist, dass man in der Weboberfläche der Wallbox unter Config/Others das Master Slave Enable deaktiviert! Ansonsten kann evcc die Wallbox nicht vollständig ansteuern und es gibt Probleme wie z.B. dass evcc die Ladung nicht unterbrechn kann oder dass die Ladeleistung zu gering ist.
chargers:
- name: my_charger
type: template
template: phoenix-ev-eth
# Modbus TCP
modbus: tcpip
id: 255
host: 192.0.2.2 # Hostname
port: 502 # Port Viel besser ist es die Wallbox aus Sicht des HKW über den evcc modbusproxy (im schreibgeschützen Modus) einzubinden. Dazu muss in der evcc.yaml zuerst der modbusproxy folgendermaßen aktiviert werden.
modbusproxy:
- port: 502 # Port modbusproxy
uri: 192.0.2.2:502 # IP und Port Wallbox
readonly: true # Schreibzugriffe blockierenNach einem Neustart von evcc ist der modbusproxy aktiv. Dieser lauscht unter der IP-Adresse des evcc Systems auf Port 502 und leitet Modbus Leseanfragen an die IP-Adresse der Wallbox auf Port 502 weiter. Schreibzugriffe werden "kommentarlos" verworfen.
Nun muss die Wallbox zunächst wie oben beschrieben auch aus dem HKW gelöscht, kann aber jetzt über die IP-Adresse der evcc Instanz wieder eingebunden werden. Wichtig ist beim Hinzufügen der Wallbox den korrekten Typ (hier "Easy Connect" auszuwählen), da bei einer fehlerhaften Wahl dennoch eine Wallbox im HKW angelegt wird. Diese kann aber nicht mehr gelöscht werden, da sie mangels korrekter Antwort der Wallbox (aus Sicht des HKW, jeder Typ nutzt wohl eigene Modbus Register/Coils) nicht mehr angezeigt wird. Die IP-Adresse ist aber dennoch intern als verwendet gespeichert und kann somit nicht mehr benutzt werden.
Im folgenden Feld muss die evcc IP-Adresse manuell eingetragen werden und dann auf "übernehmen" drücken. Nicht das Feld "suchen" auswählen, da damit das HKW wieder den IP Bereich im LAN scannt und die Wallbox unter ihrer eigentlichen IP-Adresse findet und somit wieder schreibenden Zugriff hat.
Es sollte nach einiger Zeit (etwas Geduld haben) die Wallbox erkannt und angezeigt werden. Ladestart und -ende, aber vor allem die nun von evcc gesteuerte Ladeleistung sollte das HKW korrekt anzeigen. Auch im E3/DC Web-Portal sollten die Ladungen korrekt angezeigt und protokolliert werden.
Nun kann z.B. die Ladepriorisierung im E3/DC HKW wie gewohnt genutzt werden, da das HKW die aktuellen Leistungswerte der Wallbox lesen kann. Es ist möglich über das Setzen der Option "Batterieentladung durch Wallbox - Bis SOC xx%" im HKW festzulegen, dass der Hausakku bis zu diesem Wert die Wallboxladung unterstützt und danach nur noch die Leistung liefert, welche das Haus benötigt. Dann wird ab dem gewählten SOC (des Hausakku) nur noch der aktuelle Hausbedarf vom HKW erzeugt, die Wallboxladung kommt aus dem Stromnetz. Eine Wallboxladung saugt nun nicht mehr in kurzer Zeit den kompletten Hausakku leer.
Hinweis: Wenn die evcc Instanz (und damit der modbusproxy) eine Zeit lang nicht aktiv ist, fängt das HKW automatisch an im LAN nach der Wallbox zu suchen und findet diese wieder über ihre direkte IP. Bei Problemen mit der Wallboxsteuerung in evcc bitte im HKW prüfen, ob die Wallbox noch über die evcc IP (und damit über den modbusproxy) verbunden ist. Auch prüfen, ob in der Weboberfläche der Wallbox unter Config/Others das Master Slave Enable immer noch deaktiviert ist. Das aktiviert das HKW manchmal leider wieder, wenn es kurz mal direkt auf die Wallbox zugreifen kann.
Hat man mehr als 1 Easy Connect Wallbox, so kann man die weiteren aktuell leider nicht ebenfalls über den evcc modbusproxy leiten, da das HKW eine Wallbox immer nur auf Port 502 anspricht, ein anderer Port kann nicht definiert werden. Da die Adressierung "IP:Port" eindeutig sein muss, muss aus Sicht des HKW jede Wallbox ihre eigene IP-Adresse haben, der modbusproxy bzw. evcc haben aber nur 1 IP-Adresse. Ein Weg, wie man evcc bzw. den modbusproxy auf einem System auch unter einer zweiten IP-Adresse zur Verfügung stellen kann, damit das klappen könnte, ist mir nicht bekannt.
Da das E3/DC HKW nicht mehr die Ladeleistung steuert, ist der Schlüsselschalter an der Wallbox, mit dem ich vor der evcc Einbindung zwischen PV-Überschußladen und Netzladen umstellen konnte, erstmal unnütz geworden. Per FHEM und Modbus frage ich jedoch inzwischen die Stellung ab und sende per REST-API an evcc eine Umschaltung zwischen "PV" und "Schnell".
Eine alternative Umsetzung direkt unter Linux findet sich hier: https://github.com/evcc-io/evcc/discussions/12859
Als E-Auto haben wir einen Nissan Leaf ZE1 mit 40kWh Akku und 6kW Ladeleistung am Typ 2 Stecker. Hier musste ich auch erst lernen, dass für dieses Auto eine 11kW Wallbox nicht ausreicht. Beim ersten Ladeversuch hat der 3x16A Leitungsschutzschalter ausgelöst. Der Leaf ZE1 lädt am Typ 2 Anschluss nur 1phasig, das sind bei 6kW eben 26A. Nach Rücksprache mit dem Elektriker wurde der Leitungsschutzschalter gegen einen 3x32A getauscht und die Leistung auf 20A begrenzt, dies verträgt die Zuleitung noch problemlos. Zusätzlich habe ich einen Temperatursensor am Zuleitungskabel angebracht, um dies zu überwachen.
evcc hat nach Eingabe der Zugangsdaten sofort und seither problemlos die Daten vom Nissan Server abgerufen. Das klappt einwandfrei!
Ich möchte auf evcc nicht mehr verzichten, da ich damit folgende Szenarien abdecken kann
- fein geregelte PV-Überschußladung, inzwischen auch mit Nutzung der Hausbatterie als Unterstützung
- Ladung auf einen Maximalwert, um den Akku zu schonen
- Ladung auf einen Mindestwert direkt beim Einstecken, ohne evcc Interaktion. Egal woher der Strom kommt
- Ladepläne nutze ich eher selten. Im Augenblick wird jedoch testweise beim Einstecken per Script ein Plan erzeugt -> 80% bis 6h morgens. So kann man Nachmittags mit PV Überschuss laden, steckt man dann irgendwann aus (das Auto sollte sowieso Abends in die Garage), hat man nur Sonnenstrom geladen. Reicht das aber nicht für den nächsten Tag, steckt man nach dem Fahren in die Garage wieder ein und am nächsten Morgen ist das Auto gut geladen. So kann man einfach durch die Handlung "über Nacht eingesteckt haben oder nicht" bestimmen wie stark das Auto und mit welchem Strom geladen wird.
# open evcc at http://evcc.local:7070
network:
schema: http
host: evcc.local # .local suffix announces the hostname on MDNS
port: 7070
log: info
levels:
cache: error
# database configuration for persisting charge sessions and settings
database:
type: sqlite
dsn: /var/lib/evcc/evcc.db
# unique installation id
plant: xxxxxx
interval: 10s # control cycle interval
sponsortoken: xxxxxx
meters:
- type: template
template: e3dc
usage: grid
host: 192.168.1.121
port: 502
name: grid1
- type: template
template: e3dc
usage: pv
host: 192.168.1.121
port: 502
name: pv1
- type: template
template: e3dc
usage: battery
host: 192.168.1.121
port: 502
name: battery1
capacity: 13.1 # in kWh
chargers:
- type: template
template: phoenix-ev-eth
modbus: tcpip
id: 255
host: 192.168.1.125
port: 502
name: wallbox1
vehicles:
- type: template
template: carwings
title: Nissan Leaf
user: xxxxxx
password: xxxxxx
capacity: 40
phases: 1
icon: car
cache: 15m
minCurrent: 6
maxCurrent: 25
name: ev1
loadpoints:
- title: xxxxxx
charger: wallbox1
vehicle: ev1
mode: pv
phases: 3
mincurrent: 6
maxcurrent: 20
soc:
poll:
mode: always
interval: 720m
site:
title: xxxxxx
meters:
grid: grid1
pv:
- pv1
battery:
- battery1
residualPower: 100
tariffs:
currency: EUR # (default EUR)
grid:
type: fixed
price: 0.3923 # [currency]/kWh
feedin:
type: fixed
price: 0.066891 # [currency]/kWh
modbusproxy:
- port: 502
uri: 192.168.1.125:502
readonly: true
# mqtt message broker
mqtt:
broker: localhost:1883
topic: evcc # root topic for publishing, set empty to disable publishing
clientid: 653555047
# push messages
messaging:
events:
connect: # vehicle connect event
title: Car connected
msg: "${vehicleName} Car connected, mode:${mode}"
guest:
title: Guest connected
msg: "${vehicleName} Guest connected, mode:${mode}"
services:
- type: script
cmdline: /home/pi/evcc/evcc_message.sh # ev. anpassen
timeout: 50sAktuell werkelt noch ein alte Ölheizung, Warmwasser wird mit Solarthermie unterstützt. Aber bereits alles durch 1-wire Sensoren in der Hausautomation überwacht.
Im Sommer/Herbst soll auf eine Wärmepumpe mit großem Pufferspeicher und zusätzlichen Heizstäben umgestellt werden. Solarthermie soll bleiben.