EVCC mit Heidelbridge Modbus timeouts

Allgemein
,
1

Hallo zusammen,

ich habe Probleme, meine Heidelberg EC Wallbox in meinem HA zum laufen zu bekommen.

Ich habe folgendes Setup:

Die Heidelberg EC ist per Modbus RTU mit einem ESP32 und entsprechendem rs485 Adapter verbunden, auf dem ESP läuft Heidelbridge. Der ESP übergibt die Daten dann per WLAN an HA mit EVCC.

Das ganze hat jetzt einige Monate gut geklappt, ich konnte aufgrund einer Rückrufaktion meines Autos einige Zeit nicht laden und nun wo es wieder ginge bekomme ich keine Verbindung mehr zustande.

Mein EVCC meldet mir immer timeouts, ich habe auch schon versucht es mittels modbus proxy zum laufen zu bekommen, aber nichts führt zum Erfolg. Auch die bei Modbus-Adapter angesprochenen Sensoren der Wallbox melden immer unavailable.

Ich bin wirklich am verzweifeln und weiß nicht, was ich noch versuchen kann. Die Heidelbridge ist im WLAN und auch per Browser erreichbar, die Verkabelung hab ich komplett überprüft, da passt alles.

Hier mein EVCC file:

interval: 15s

#mqtt:
#  broker: 192.168.178.62:1883
#  topic: evcc # root topic for publishing, set empty to disable
#  user: evccmqtt
#  password: fhruz463cdhe

site:
  title: Home
  meters:
    grid: my_grid
    pv: 
      - my_pv

chargers:
  - name: heidelberg_ec
    type: template
    template: daheimladen-mb
    host: 192.168.178.62 # IP address or hostname
    port: 502 # Port (optional) 

loadpoints:
  - title: carport
    charger: heidelberg_ec
    mode: off
    guardduration: 5m
    enable:
      # einschalten, wenn 1 Minute lang mindestens 2000 W Überschuss vorhanden ist
      delay: 1m
      threshold: -2000
    disable:
      # ausschalten, wenn 30 Minuten lang mehr als 2000 W aus dem Netz bezogen werden
      delay: 30m
      threshold: 2000

Und hier die Fehlermeldung im Log von EVCC:


Using config file: /config/evcc.yaml

starting evcc: ‘EVCC_DATABASE_DSN=/data/evcc.db evcc --config /config/evcc.yaml’

\[main  \] INFO 2025/08/08 11:23:08 evcc 0.207.1

\[main  \] INFO 2025/08/08 11:23:08 using config file: /config/evcc.yaml

\[db    \] INFO 2025/08/08 11:23:08 using sqlite database: /data/evcc.db

\[main  \] INFO 2025/08/08 11:23:08 UI listening at :7070

\[main  \] FATAL 2025/08/08 11:23:12 charger \[heidelberg_ec\] cannot create charger ‘heidelberg_ec’: cannot create charger type ‘template’: cannot create charger type ‘daheimladen-mb’: current limit: read tcp 192.168.178.62:54546->192.168.178.62:502: i/o timeout

loadpoint \[lp-1\] charger: not found: heidelberg_ec

\[main  \] FATAL 2025/08/08 11:23:12 will attempt restart in: 15m0s

**Das Log des Modbus Proxy sieht so aus:**

Preparing to run modbus-proxy

Upstream: 192.168.178.65:502

Listen: 502

Timeout: 10

Connection Time: 0.1

Loglevel: INFO

Generated Config

devices:

* modbus:

  url: 192.168.178.65:502 # device url (mandatory)

  timeout: 10 # communication timeout (s) (optional, default: 10)

  connection_time: 0.1 # delay after connection (s) (optional, default: 0)

  listen:

  bind: 0:502 # listening address (mandatory)

logging:

version: 1

formatters:

standard:    format: “%(asctime)s %(levelname)8s %(name)s: %(message)s”

handlers:

console:    class: logging.StreamHandler    formatter: standard

root:

handlers: \\\[‘console’\\\]  level: INFO

2025-08-08 10:40:40,284     INFO modbus-proxy: Starting…

2025-08-08 10:40:40,290     INFO modbus-proxy.ModBus(192.168.178.65:502): Ready to accept requests on 0:502

2025-08-08 10:45:33,825     INFO modbus-proxy.Client(192.168.178.62:54254): new client connection

2025-08-08 10:45:35,392     INFO modbus-proxy.ModBus(192.168.178.65:502): connecting to modbus…

2025-08-08 10:45:35,438     INFO modbus-proxy.ModBus(192.168.178.65:502): connected!

2025-08-08 10:45:35,439     INFO modbus-proxy.ModBus(192.168.178.65:502): delay after connect: 0.1

2025-08-08 10:47:54,456     INFO modbus-proxy.Client(192.168.178.62:54254): client closed connection

2025-08-08 10:47:54,456     INFO modbus-proxy.Client(192.168.178.62:54254): closing connection…

2025-08-08 10:47:54,457     INFO modbus-proxy.Client(192.168.178.62:54254): connection closed

2025-08-08 10:53:33,284     INFO modbus-proxy.Client(192.168.178.62:52880): new client connection

2025-08-08 10:53:33,284     INFO modbus-proxy.ModBus(192.168.178.65:502): connecting to modbus…

2025-08-08 10:53:33,347     INFO modbus-proxy.ModBus(192.168.178.65:502): connected!

2025-08-08 10:53:33,347     INFO modbus-proxy.ModBus(192.168.178.65:502): delay after connect: 0.1

2025-08-08 10:53:41,707     INFO modbus-proxy.Client(192.168.178.62:52880): client closed connection

2025-08-08 10:53:41,707     INFO modbus-proxy.Client(192.168.178.62:52880): closing connection…

2025-08-08 10:53:41,707     INFO modbus-proxy.Client(192.168.178.62:52880): connection closed

Ich bin für jeden Denkanstoß dankbar

:crayon:by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden)
s.a.: (Neues Update & Features - Hier in der Community 🫶)

2

Du meinst das rote Dreieck was ab und zu in EVCC auftaucht? Hatte ich auch einige Zeit. Mit der neusten Version (Heidelbridge UND evcc) ist es wesentlich seltener geworden.
Allerdings hängt sich meine Heidelbridge alle paar Wochen mal auf und da hilft leider nur ein Reset.

3

Nein, das Dreieck hatte ich früher auch gelegentlich aber jetzt ist es so dass gar keine Verbindung mehr zustande kommt und ich die Fehlermeldungen im Log habe

4

Schau mal per MQTT-Explorer in die internals ob es viele wifi-disconnects oder mqtt_disconnects gibt.
Evtl. ist an der Stelle das WLAN bei dir etwas schlapp. Manchmal machen schon 10cm von der Wand weg was aus.

5

Habe ich gerade gemacht, das WLAN scheint stabil, keine disconnects.

Das Problem scheint die Modbus-Verbindung zu sein.

image
image241×347 6.73 KB

6

Ich hab sporadisch mqtt_disconnects, aber modbus ist bei mir stabil.

Wie ist das denn bei dir verkabelt? Das kann zum Einen das Kabel zu Wallbox sein aber auch schon die Verkabelung ESp32 ←→ Modbus-Adapter. Dupont-Steckerchen? Die machen gern mal Probleme.

7

Das Kabel von der Wallbox ist ein Cat5e Kabel 7m lang, habe es aber auch schon testweise mit einem kurzen Cat7 Kabel versucht, ebenfalls ohne Erfolg.

ESP zum Modbus-Adapter habe ich tatsächlich mit Jumperkabeln, das ist ein guten Punkt. Aber es hat ja mehrere Monate funktioniert.

Dann werde ich mich mal dran machen und den Adapter mit dem ESP verlöten.

8

Ich habe auch noch so einen fliegenden Aufbau. Zur Wallbox bestimmt 10 Meter. Laut Handbuch kann die Verbindung 500m lang werden.
Wenn du schon lötest wäre vielleicht auch ein Stützkondensator über der Spannungsversorgung ganz gut.

Ich überlege auch, von WLAN auf Ethernet umzusteigen.

9

Ich hatte noch einen Waveshare-Modbus to Eth Adapter hier rumliegen, den habe ich gerade mal angeschlossen und den Modbus-Proxy auf den Adapter konfiguriert.

Nun bekomme ich die Wallboxdaten auf Sensoren, die ich direkt per yaml abfrage. Die Modbusverbindung funktioniert also.

Leider meldet mir EVCC weiter die Timeout-Fehler. Ich habe auch schon versucht, ohne den Modbus-Proxy direkt mit EVCC auf den Waveshare-Adapter zuzugreifen (die Abfrage in meiner modbus.yaml vorher deaktiviert), aber ohne Erfolg.

Von daher glaube ich eher nicht, dass es am Heidelbridge Adapter liegt und ich bin einigermaßen ratlos.

10

In Homeassistant kommen die Daten der Heidelbridge doch per MQTT an und werden Autodiscoverd (wasn deutsch :slight_smile:

Vielleicht ist einfach dein Modbusadapter etwas fritte, evtl. Überspannung oder einfach nicht die beste Qualität.Aber das kann auch nicht sein wenn es auch mit deinem anderen Adapter genau so schlecht geht.

Kann ja fast nur noch an der Verbindung evcc-modbus/heidelbridge liegen. Mach mal ein ping vom evcc-Rechner auf die Adapter-IP. Ist da irgendwas auffällig?

11

Habe ich auch gerade versucht, der ping klappt problemlos, 100 Versuche, kein Fehler, alle unter 1ms.

Was mir noch aufgefallen ist:

Im Protokoll des Modbus-Proxy läuft alles ohne Fehler wenn ich nur über die modbus.yaml die Sensoren abfrage, sobald ich dann EVCC startet kommen immer mal wieder Timeout Errors dazu.

image
image990×389 12.9 KB

12

Über die Heidelbridge kommen die Daten doch per daheimladen an und nicht per Modbus (man korrigiere mich wenn das Mumpitz ist!), so ist das bei mir jedenfalls in evcc konfiguriert:

chargers:
- type: template
  template: daheimladen-mb
  host: 10.10.10.201
  port: 502
  name: wallbox4

EInen Proxy brauchst du da glaub ich nicht.

Ich habe einen Proxy für meine Solarapparatur, aber das ist eine andere Geschichte.

Achso, als Modbus-Multiplexer verwende ich:

13

Ich habe die Sache mit der Heidelbridge jetzt aufgegeben.

Aktuell habe ich wieder den Waveshare-Adapter in Betrieb, damit kann ich über die modbus.yaml die Wallbox wie gehabt auslesen.

Mit evcc habe ich bei Konfiguration über die evcc.yaml weiter die timeouts bekommen. Allerdings gibt es ja jetzt den experimentellen UI-Konfigurationsassistenten. Mit dem funktioinert es komischerweise.

image
image475×1233 53.5 KB