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.

Wer Fragen hat, kann gerne eine Diskussion hier bei Github aufmachen und mich über @docolli informieren. Ich versuche dann zu helfen.

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

1. Den insgesamten Stromverbrauch per ELV Energiezähler (mit Sensor für die Ferraris-Scheibe !) aufzuzeichnen
2. Einzelne Verbraucher (z.B. Waschmaschine, Trocker) per Zwischenstecker (aktuell MyStrom Wifi Switch) aufzuzeichnen
3. Meine Heizungstemperaturen per 1-wire Sensoren aufzuzeichnen
4. 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.

5. Außen- und Innentemperaturen (dazu nutze ich die günstigen Technoline TX 29-IT bzw. TX 29 DHT-IT)
6. Zisterne- und Heizölstand (Ultraschallsensor FT002)
7. Regensensor (ADE WS1907)
8. mit der PV kam ein neuer Stromzähler mit optischer Schnittstelle, also Umrüstung von (1.) auf Lesekopf mit Tasmota
9. Detektion ob Brenner, Heizungs- bzw. Solarpumpen laufen (über selbst programmierte ESP32 mit Optokopplern)
10. Ablesen der Wasseruhr über einen ESP32 mit Kamera (AI on the edge)
11. 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.

Wichtig: Alle DIP-Schalter in der Wallbox auf "Off", außer DIP 10:

Auch wichtig: Master/Slave muss ausgeschaltet sein:

Dazu auf die Weboberfläche der Wallbox gehen (Passwort, Google-Suche mit "Wallbe Passwort"), Haken entfernen und "submit". Wenn das HKW direkt schreibenden Zugriff auf die Wallbox hat, kann dies wieder vom HKW gesetzt werden, daher Zugriff nur über Modbus-Proxy. Siehe unten. Bei Problemen diese Option kontrollieren.

Wichtig ist auch zu prüfen, ob die Remote Charge Current Limitation auf einem Wert >=6 (A) steht! Sonst erkennt evcc beim Start nicht korrekt, dass die Wallbox eine Steuerung in 0,1A-Schritten kann und sendet die Ladeleistung um den Faktor 10 zu klein. Also den Wert 16 anstatt 160 für 16.0(A) Ladeleistung. Dann startet die Ladung nicht, egal welchen Modus man in evcc wählt.

Den Wert also auf 6 setzen und danach den Knopf submit drücken. Darauf achten, dass evcc nicht läuft und den Wert wieder mit einem zu kleinen Wert überschreibt! Erst setzen, prüfen und dann evcc starten.

So löscht man die Wallbox im HKW:

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 unterbrechen 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 blockieren

Nach 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 habe ich inzwischen auch eine Lösung gefunden! Siehe https://github.com/evcc-io/evcc/discussions/14800

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! Nachtrag: Ab und zu ändert Nissan die URL zur Abfrage. Aber das hat bislang das evcc Team und der Maintainer der Carwings-Go Implementierung immer rasch behoben. Auch die Änderung der Verschlüsselung in 07/2025 wurde fix behoben.

Als zweites E-Auto haben wir einen BMW iX2. Auch dieser ließ sich problemlos über evcc einbinden, man musste nur einmalig einen Token generieren. Seither ist auch dieser problemlos in evcc anzusteuern.

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
• Wiederholende Pläne sind auch super -> 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: info
  lp-1: info
  site: info
  
# database configuration for persisting charge sessions and settings
database:
  type: sqlite
  dsn: /var/lib/evcc/evcc.db

# unique installation id
plant: xxx

interval: 10s # control cycle interval

sponsortoken: xxx

site:
  title: xxx
  meters:
    grid: grid1
    pv:
    - pv1
    battery:
    - battery1
    aux:
#    -
    ext:
    - wp_meter
    - heating_meter
    - home_meter
  residualPower: 100

circuits:
  - name: garage
    title: Garage
    maxCurrent: 32

meters:
- name: grid1
  type: template
  template: e3dc-rscp
  usage: grid
  host: 192.168.1.121
  user: xxx
  password: xxx
  key: xxx
- name: pv1
  type: template
  template: e3dc-rscp
  usage: pv
  host: 192.168.1.121
  user: xxx
  password: xxx
  key: xxx
- name: battery1
  type: template
  template: e3dc-rscp
  usage: battery
  host: 192.168.1.121
  user: xxx
  password: xxx
  key: xxx
  capacity: 13.1 # in kWh
  dischargelimit: 500

- name: wp_meter
  type: custom
  power:
    source: mqtt
    topic: open3e/CurrentElectricalPowerConsumptionSystem
    timeout: 60s

- name: heating_meter
  type: template
  template: shelly-pro-3em
  host: 192.168.1.106

- name: home_meter
  type: custom
  power:
    source: mqtt
    topic: e3dc/home/power
    timeout: 60s

loadpoints:
- title: Garage Carmen
  circuit: garage
  charger: wallbox1
  vehicle: ev1
  mode: pv
  priority: 20
  soc:
    poll:
      mode: always
      interval: 720m

- title: Garage Olli
  circuit: garage
  charger: wallbox2
  vehicle: ev2
  mode: pv
  priority: 30
  soc:
    poll:
      mode: always
      interval: 720m
  

- title: AC•THOR Heizstab
  charger: myPV_ac-thor
  vehicle: heating1
  mode: off
  priority: 1
  enable:
    threshold: -200 # einschalten, wenn 1 min. lang mind. 200W Überschuss vorhanden ist
    delay: 1m
  disable:
    threshold: 200
    delay: 10s

- title: Wärmepumpe
  charger: wp_charger
  meter: wp_meter
  vehicle: heating2
  mode: now
  priority: 10


chargers:
- name: wallbox1
  type: template
  template: phoenix-ev-eth
  modbus: tcpip
  id: 255
  host: 192.168.1.40
  port: 502  

- name: wallbox2
  type: template
  template: phoenix-ev-eth
  modbus: tcpip
  id: 255
  host: 192.168.1.41
  port: 502


- name: myPV_ac-thor
  type: template
  template: ac-thor
  modbus: tcpip
  id: 1
  host: 192.168.1.145
  port: 502


- name: wp_charger
  type: switchsocket
  icon: heatpump
  enabled:
    source: script
    cmd: /bin/sh -c 'echo true'
  enable:
    source: script
    cmd: /bin/sh -c 'echo true' 
  features:
    - integrateddevice
    - heating
  power:
    source: http
    uri: http://localhost:7070/api/state
    jq: .result.ext[0].power
  standbypower: 10  

vehicles:
- name: ev1
  type: template
  template: carwings 
  title: Nissan Leaf  
  user: xxx  
  password: xxx
  capacity: 40  
  phases: 1  
  icon: car  
  cache: 15m  
  minCurrent: 6  
  maxCurrent: 25  

- name: ev2
  type: template
  template: bmw
  title: BMW iX2
  user: xxx
  password: xxx
  hcaptcha: xxx
  vin: xxx
  capacity: 65
  phases: 3
  icon: car
  cache: 15m
  minCurrent: 6
  maxCurrent: 32

- name: heating1
  type: custom
  title: Heizstab
  icon: heater

- name: heating2
  type: custom
  title: Wärmepumpe


tariffs:
  currency: EUR # (default EUR)
  grid:
    type: fixed
    price: 0.2963 # [currency]/kWh
  feedin:
    type: fixed
    price: 0.066891 # [currency]/kWh
  solar:
    - type: template
      template: forecast-solar
      lat: xxx
      lon: xxx
      dec: 25 # 0 = horizontal, 90 = vertikal
      kwp: 8.5
      az: -45 # Ausrichtung der PV-Module im Azimut in Grad. -180 = Norden, -90 = Osten, 0 = Süden, 90 = Westen, 180 = Norden
    - type: template
      template: forecast-solar
      lat: xxx
      lon: xxx
      dec: 25 # 0 = horizontal, 90 = vertikal
      kwp: 4
      az: 135 # Ausrichtung der PV-Module im Azimut in Grad. -180 = Norden, -90 = Osten, 0 = Süden, 90 = Westen, 180 = Norden


modbusproxy:
- port: 502
  uri: 192.168.1.40:502
  readonly: true
- port: 1502
  uri: 192.168.1.41:502
  readonly: true

mqtt:
  broker: 192.168.1.180: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: custom
      encoding: tsv
      send:
        source: script
        cmd: /home/evcc/evcc_message.sh # ev. anpassen
        timeout: 50s

Viessmann Vitocal-250A Wärmepumpe mit Pufferspeicher und MyPV AC Thor mit 9kW Heizstab. Anbindung WP über open3e und MQTT an evcc. Details kommen demnächst.

Visualisierung in FHEM mit 1-wire Sensoren.

Zusätzliche Daten von open3e:

Um Daten von der Wärmepumpe zu bekommen, habe ich folgende Hardware genutzt und mit dem CAN-Anschluß der Wärmepumpe verbunden:

• Raspberry Pi Zero 2 W, 4x 1 GHz, 512 MB RAM, WLAN, BT
• Raspberry Pi Zero Shield - RS485 CAN HAT, MCP2515

Zu Details, wie man open3e installiert und als Dienst ans Laufen bekommt, gehe ich hier nicht ein. open3e hat selbst eine gute Github Seite dazu.

Meine open3e Konfigurationsdatei (192.168.1.180 ist mein MQTT Broker Mosquitto):

--can
can0
--read
268,269,271,274,286,318,320,321,322,324,325,335,355,381,389,391,396,402,426,476,543,548,1193,1211,565,1391,580,881,1043,1416,1769,1770,1771,1772,1775,1776,1815,1816,1817,2333,2334,2346,2351,2369,2427,2487,2488,2496,2735,3016
--timestep
15
--mqtt
192.168.1.180:1883:open3e
--mqttformatstring
{didName}
--mqttclientid
Open3E
--config
devices.json

Einbindung in evcc:

site:
  title: xxx
  meters:
    grid: grid1
    pv:
    - pv1
    battery:
    - battery1
    aux:
#    -
    ext:
    - wp_meter
  residualPower: 100

meters:
- name: wp_meter
  type: custom
  power:
    source: mqtt
    topic: open3e/CurrentElectricalPowerConsumptionSystem
    timeout: 60s

loadpoints:
- title: Wärmepumpe
  # circuit: heating
  charger: wp_charger
  meter: wp_meter
  vehicle: heating2
  # integrateddevice: true # Fahrzeugauswahl deaktivieren
  mode: now
  priority: 10

chargers:
- name: wp_charger
  type: switchsocket
  icon: heatpump
  enabled:
    source: script
    cmd: /bin/sh -c 'echo true'
  enable:
    source: script
    cmd: /bin/sh -c 'echo true' 
  features:
    - integrateddevice
    - heating
  power:
    source: http
    uri: http://localhost:7070/api/state
    jq: .result.ext[0].power
  standbypower: 10  

vehicles:
- name: heating2
  type: custom
  title: Wärmepumpe

# mqtt message broker
mqtt:
  broker: 192.168.1.180:1883
  topic: evcc # root topic for publishing, set empty to disable publishing
  clientid: 653555047