Laden startet nicht, wenn HeidelBridge aktiv ist (Peugeot e-208 + Heidelberg Wallbox)

[ulicleuc-web]

📦 Umgebung

• Wallbox: Heidelberg Energy Control 11 kW
• Fahrzeug: Peugeot e-208
• Board: LILYGO T-CAN485 (ESP32 mit onboard RS485)
• Firmware: HeidelBridge 3.6.0 (auch mit 3.5.0 getestet)
• Betriebsmodus: Nur Monitoring über MQTT (keine bewusste Steuerung)

🎯 Ziel

HeidelBridge soll ausschließlich lesend über MQTT Daten bereitstellen, ohne das Ladeverhalten zu beeinflussen.

⚠️ Problem

Sobald HeidelBridge über RS485 mit der Wallbox verbunden ist:

• Fahrzeug wird erkannt
• Laden startet nicht
• Fahrzeugmeldung: „Ladevorgang beendet“ (obwohl nie geladen wurde)

Wenn HeidelBridge entfernt wird oder die Wallbox wieder ohne Modbus (ID 0) läuft, funktioniert das Laden sofort wieder.

🔍 Beobachtungen (MQTT)

enable_charging ON
standby_enabled OFF
charging_current_limit 16.00
is_vehicle_connected 1
is_vehicle_charging 0
vehicle_state connected
charging_power 0.00
energy_meter 10924.02
charging_voltage/phase1 245.00
charging_voltage/phase2 245.00
charging_voltage/phase3 244.00

internal/modbus_read_errors 0
internal/modbus_write_errors 0

### 🔁 Schritte zur Reproduktion

1. HeidelBridge (LILYGO T-CAN485) an RS485 anschließen
2. System starten
3. Peugeot e-208 anschließen
4. Fahrzeug verbindet sich, Laden startet nicht

### ✅ Erwartetes Verhalten

Ladevorgang sollte identisch zur Standalone-Wallbox starten.

### ❓ Fragen

* Schreibt HeidelBridge beim Start Register, die das Laden verhindern könnten?
* Gibt es einen empfohlenen **Read-Only / Passive Mode**?
* Sind Inkompatibilitäten mit dem Peugeot e-208 bekannt?

### 📎 Zusatzinfos

* Wallbox lädt seit ~4 Jahren zuverlässig ohne HeidelBridge.
* Es wurden keine MQTT-Steuerbefehle gesendet.
* Problem tritt mit Version 3.5.0 und 3.6.0 auf.

### 🙏 Vielen Dank

Tolles Projekt — die MQTT-Integration funktioniert hervorragend und liefert sehr wertvolle Daten!

[BorisBrock]

@ulicleuc-web Die Werte sehen eigentlich gut aus. Ich würde noch mal explizit per MQTT folgendes setzen:

• enable_charging -> 1
• charging_current_limit -> 16

Falls das nichts hilft, müsste man sich mal die Ausgaben der HeidelBridge anschauen. Das ist leider ein bisschen "fortgeschrittener":

• In platformio.ini das Log Level umstellen: LOGGING_LEVEL_ERROR -> LOGGING_LEVEL_TRACE
• Projekt kompilieren
• Projekt auf Board flashen
• Über den Seriellen Monitor die Ausgaben beim Ladevorgang beobachten

[ulicleuc-web]

Hallo Boris, danke für die schnelle Antwort. Ich habe als erstens die beiden Parameter gecheckt: enable_charging ON charging_current_limit 16.00 Sieht gut aus. Mit dem Trace wird es dann komplex, Was mir dabei z.B. aufgefallen ist: ... [DEBUG] Reading voltages: 243.000000 243.000000 243.000000 V [DEBUG] Heidelberg wallbox: Read standby enabled = 0 [TRACE] Publishing MQTT messages ... [DEBUG] Heidelberg wallbox: Read state: 4 [DEBUG] Heidelberg wallbox: Read standby enabled = 0 [TRACE] Publishing MQTT messages [DEBUG] Heidelberg wallbox: Read max. charging current: 0.000000 #### das gefällt mir nicht... [DEBUG] Heidelberg wallbox: Read standby enabled = 0 [TRACE] Publishing MQTT messages [DEBUG] Reading power meter value: 0.000000 W ... [DEBUG] Read Heidelberg failsafe current: 16.000000 [DEBUG] Heidelberg wallbox: Read standby enabled = 0 [TRACE] Publishing MQTT messages [DEBUG] Heidelberg wallbox: Read energy meter value: 10924797.000000 Wh [DEBUG] Heidelberg wallbox: Read standby enabled = 0 [TRACE] Publishing MQTT messages [DEBUG] Reading currents: 0.000000 0.000000 0.000000 A ... Auf welche Outputs muss ich sonst noch achten? Ich kann Dir die MQTTs und Traceausgaben schicken, wenn Du magst. Vielen Dank für Deine Unterstützung, sonnige Grüße, Uli

…

On Sun, Mar 1, 2026 at 6:06 AM Boris Brock ***@***.***> wrote: *BorisBrock* left a comment (BorisBrock/HeidelBridge#60) <#60 (comment)> @ulicleuc-web <https://github.com/ulicleuc-web> Die Werte sehen eigentlich gut aus. Ich würde noch mal explizit per MQTT folgendes setzen: - enable_charging -> 1 - charging_current_limit -> 16 Falls das nichts hilft, müsste man sich mal die Ausgaben der HeidelBridge anschauen. Das ist leider ein bisschen "fortgeschrittener": - In platformio.ini das Log Level umstellen: LOGGING_LEVEL_ERROR -> LOGGING_LEVEL_TRACE - Projekt kompilieren - Projekt auf Board flashen - Über den Seriellen Monitor die Ausgaben beim Ladevorgang beobachten — Reply to this email directly, view it on GitHub <#60 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B2FZBDAJ6DVCVTM3O3CPGAL4OPANJAVCNFSM6AAAAACWCYCDKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNZZGEYTKNBQGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[BorisBrock]

Hi Uli,
ich denke da hast du schon die relevante Zeile identifiziert. Dass der maximale Ladestrom auf 0 steht, bedeutet, dass die Wallbox den Ladevorgang verweigert. Siehe Register 261 im Manual:

The system can be locked by setting 0 in register 261. However, this is not
displayed to the user. It is noticed that the charging does not start or is
terminated.

Der Wert wird nach einem Neustart der Wallbox auch immer wieder auf 0 zurückgesetzt.

Jetzt wäre also die Frage, warum du den Wert nicht setzen kannst. Das MQTT-Topic "/control/charging_current_limit" sollte direkt ein Beschreiben des Registers auslösen. Das sollte mit folgender Log-Ausgabe quittiert werden:

Heidelberg wallbox: setting charging current limit to X A

Alternativ könnte auch eine der beiden folgenden Ausgaben kommen:

ERROR: Could not set maximum charging current

...wenn es einen Fehler beim Schreiben des Registers gab.

charging is disabled. current limit X A is not applied

...wenn die HeidelBridge gesperrt ist.

Eine dieser drei Ausgaben müsstest du also auf jeden Fall sehen, wenn du per MQTT ein Limit setzt.

[ulicleuc-web]

Hallo Boris,
in den MQTT Daten taucht folgendes auf:
einmalig, beim Start:
HeidelBridgeLi/charging_current_limit 16.00
danach nie wieder, auch nicht als: "control/charging_current_limit"
Ich hatte schon mal versucht, HeidelBridgeLi/charging_current_limit per
mosquitto_pub -t "HeidelBridgeLi/set/charging_current_limit" -m "16000" (bzw. auch mit -m 16),
zu setzen, ohne Erfolg, ohne Trace damals.
Der heutige Versuch mit:
mosquitto_pub -t "HeidelBridgeLi/control/charging_current_limit" -m "160" (lt manual 160 für 16A)
hat nun das gewünschte Ergebnis gebracht.

Vielen Dank für deinen schnellen und kompetenten Support.

Bleibt noch die Frage: Muss ich das jedes mal vor dem Laden machen?
Oder nach jedem Power Off der Wallbox?

Liebe Grüße, Uli

[BorisBrock]

Hi, wenn es einmal gesetzt ist, sollte der Wert erhalten bleiben.
Einzige Ausnahme: kompletter Power-Off der Wallbox. Aber das passiert ja eher selten.

[ulicleuc-web]

Hmm,
heute habe ich es hardwaremässig neu angebracht, danach eingeschaltet, und danach, ohne Auto, den mosquitto_pub abgesetzt.
Als dann nach einigen Stunden meine Frau laden wollte, ging erstmal nichts. Erst mit einem erneuten
mosquitto_pub -t "HeidelBridgeLi/control/charging_current_limit" -m "160"
hat der Peugeot angefangen zu laden. So kann ich das nicht meiner Frau überlassen, zumal ich öfter mal nicht da bin.
Kann man einen Automatismus hinzufügen, nach dem Motto:
if (is_vehicle_connected == 1) , dann setze charging_current_limit ?
Oder kennst du einen Weg, auf dieses Ereignis auf MQTT/mosquitto zu warten, und dann den mosquitto_pub abzusetzen?

[BorisBrock]

Ja, der WAF darf nicht vernachlässigt werden 😉

Die Heidelbridge sollte das Strom-Limit-Register eigentlich nicht einfach so beschreiben. Das passiert nur, wenn per MQTT oder über Modbus/TCP (evcc) eine Änderung angestoßen wird. D.h., wenn das System einmal läuft, und du dann das Limit auf 160 setzt, sollte das auch so bleiben. Dass es sich nach einiger Zeit zurücksetzt, wäre seltsam.

Du kannst den Wert ja mal per MQTT einstellen, und dann z.B. mit dem MQTT Explorer schauen, wass die HeidelBridge meldet. Da sollte dann der gesetzte Wert zu sehen sein. Wenn du dann ein paar Stunden wartest, sollte der Wert immernoch gemeldet werden. Oder verhält sich das bei Dir anders?

Der Automatismus, wie Du ihn vorschlägst, würde diverse andere Use Cases kaputt machen (z.B. Steuerung per MQTT, absichtliches Blockieren der wallbox etc.).

[ulicleuc-web]

Hi Boris,
der WAF ist inzwischen mein größtes Problem...
Der eingestellte Wert für das charging_current_limit verschwindet -warum auch immer- nach einigen Stunden, vielleicht auch Minuten. Ich habe einen stündlichen
mosquitto_pub -t "HeidelBridgeLi/control/charging_current_limit" -m "160"
per cron eingebaut, aber der scheint für den WAF nicht auszureichen. Habe den cron nun auf 2 Minuten Abstand gesetzt, damit der WAF dann hoffentlich befriedigt ist.
Gibt es keine persistente Möglichkeit?

[BorisBrockBbr]

Wie gesagt: der Wert ist eigentlich persistent. Ich habe es auch noch mal ausprobiert, und in MQTT Explorer beobachtet. Wenn er einmal auf 16 gesetzt wird, bleibt er auch dabei:

Verwendest du evcc?
Und kannst du im MQTT Explorer schauen, ob auch sonst niemand per MQTT den Wert überschreibt?

[ulicleuc-web]

Hi Boris,
danke für die schnelle Antwort.
evcc verwende ich nicht,
Die MQTT Werte die ich sowohl mit mosquitto als auch mit homeassistant auslese, sind OK , allerdings bekomme ich manchmal keine Werte für charging_current_limit. In diesem Fall setze ich den Wert auf 160, also 16A.
Grundsätzlich funktioniert mein cron/mosquitto_pub um den charging_current_limit zu setzen, Allerdimgs habe ich beim Laden einen unangenehmen Seiteneffekt beobachtet:
Es scheint, als ob das zyklische MQTT Senden die Wallbox beeinflusst und zu kurzen Abbrüchen im cron Rhythmus führt. Daher hab ich die Bedingung zur Ausführung des
mosquitto_pub -t "HeidelBridgeLi/control/charging_current_limit" -m 160
mit dem Erkennen des Autos verknüpft:
mosquitto_sub -C 1 -v -t "HeidelBridgeLi/is_vehicle_connected" |grep "is_vehicle_connected 1" || mosquitto_pub -t HeidelBridgeLi/control/charging_current_limit -m 160
Hoffe dass der WAF damit erfüllt ist ;-)

[ulicleuc-web]

Hallo Boris,
eigentlich dachte ich, dass alles Läuft, und hatte meiner Frau auch schon homeassistant installiett, damit sie das Laden selber steuern kann. Dann ist mir mein Homeassistant RaspberryPi abgestürzt, und der Regler für die current limit war nicht mehr zu nutzen, die Entität war nicht mehr zu nutzen. Um HA wieder zu überreden, den Regler wieder zu bauen, habe ich in HA die Heidelbridge gelöscht, und die Wallbox mit Heidelbridge ausgeschaltet und wieder eingeschaltet.
Der Regler ist nicht wiedergekommen, aber was mich nun verwundert ist der Zählerstand energy_meter von gestern 11004 wieder zurück auf 10932 gefallen ist. Das passt nicht zu "Energy since installation" "und auch nicht zu Energy since PowerOn" .
Hast Du eine Idee?

[BorisBrock]

Hi,
der Wert kommt direkt aus Register 18 der Wallbox. Laut Doku kann er nicht geändert/zurückgesetzt werden und ist Read-Only:

Electrical energy drawn by the vehicles since commissioning of the wallbox. The
register content is not lost when the wallbox is disconnected from the mains. A
reset is not possible.

Daher sollte es eigentlich nicht möglich sein, dass der Wert zurückspringt.
Allerdings habe ich diese Beobachtung auch schon an anderen Stellen gelesen. Du scheinst nicht der erste/einzige zu sein, bei dem das passiert...

Ob das wirklich ein Fehler in der Firmware der Wallbox ist? Wäre schon komisch.

[frankschmitz890]

Hallo Zusammen,
ich habe am 08.03. das Update auf die neueste Firmware durchgeführt.
Nach dem Update funkionierte alles weiter. Tage später stellte ulicleuc-web geschilderte Fehler ein. Ich habe dies nicht mehr mit dem Update in Verbindung gebracht und habe folgendes probiert:
Heidelbridge stromlos und RS485 Kabel getrennt: danach die Wallbox wieder in Betrieb genommen: gleicher Fehler.
Erst mit dem zurücksetzen aller DIP Schalter in der Wallbox war die Box wieder funktionsfähig.
Tatsächlich lade mich mit der Box seit 1,5 Jahren und mit der Heidelbridge seit 6 Monaten.
Ich bin aber nicht so tief in das Debugging eingestiegen, wie ulicleuc-web.

ESP32, externes RS485 Modul, BMW I3