Heidelberg-to-MQTT: eigene ESP32-Firmware von RDDZ für die Heidelberg Wallbox
Community-Lösungen für die Heidelberg Energy Control gibt es genug. Wir wollten trotzdem eine eigene: eine schlanke ESP32-Firmware, komplett von RDDZ entwickelt und im eigenen Betrieb getestet, die die Wallbox per Modbus RTU ausliest und per MQTT steuerbar macht – mit Web-Update, Konfigportal und Fernzugriff auf die Logs.
Eigenes Projekt, komplett ohne Community-Codebasis.
WARUM EIGENBAU
Schlank statt überladen
HeidelBridge und wbec funktionieren grundsätzlich – für eine Heidelberg Energy Control, die man nicht täglich im Blick hat, war beides aber zu funktionsreich und nicht zuverlässig genug. Deshalb hat RDDZ eine eigene Firmware entwickelt. Das Ziel: einschalten, einmal konfigurieren, dann läuft es.
Minimal by design
Nur was für Modbus-Lesen/Schreiben und MQTT wirklich nötig ist – kein Ballast.
OTA-Updates
Neue Firmware-Versionen per Browser einspielen, ohne den ESP32 am Einbauort ausbauen zu müssen.
Eigenes Konfigportal
WiFiManager scheiterte an einem Sonderzeichen im WLAN-Passwort – ein eigenes DNS/Webserver-Portal löst das zuverlässig.
Fernzugriff auf Logs
Eine /log-Route mit RAM-Puffer und NTP-Zeitstempeln zeigt den Status auch ganz ohne USB-Kabel.
Der Bug, der am längsten Kopfzerbrechen bereitet hat
Der ESP32-Hardware-Watchdog schlug während der blockierenden WLAN-Verbindung zu und schickte das Gerät in eine Neustart-Schleife. Nicht einmal der Konfigurations-Access-Point tauchte noch auf. Die Lösung: Wir bauten die Watchdog-Fütterung sauber in die Verbindungslogik ein, statt sie während langer Blockierzeiten zu vergessen.
AUFBAU
Warum der ESP32 direkt an der Heidelberg Energy Control sitzt
Die Heidelberg Energy Control selbst spricht kein WLAN, sondern nur Modbus RTU über eine feste RS-485-Leitung. Der ESP32 sitzt deshalb bewusst nah an der Wallbox und übernimmt dort die Übersetzung ins Heimnetz.
Modbus braucht kurze Leitungswege
RS-485 ist robust, aber am zuverlässigsten mit kurzen, direkten Kabelwegen zwischen Heidelberg Energy Control und Transceiver.
Nur der ESP32 braucht WLAN
Die Heidelberg Energy Control selbst hat gar kein WLAN eingebaut und kann sich auch nicht von sich aus mit dem Internet oder dem Heimnetz verbinden. Diese Aufgabe übernimmt komplett der ESP32: Er stellt die WLAN-Verbindung her und reicht die Werte weiter. An der Wallbox selbst ändern und bauen wir dabei nichts um – sie bleibt technisch genau so, wie sie ab Werk ausgeliefert wird.
Ein Gerät, ein Zweck
Auslesen, steuern, per MQTT bereitstellen – mehr macht die Firmware bewusst nicht.
WALLBOX KONFIGURIEREN
DIP-Schalter und Drehschalter richtig stellen
Die Heidelberg Energy Control hat selbst kein WLAN und keine Cloud-Anbindung – sie spricht ausschließlich über ihre interne RS-485-Schnittstelle. Damit sie brav auf die Modbus-Anfragen des ESP32 antwortet, stellen Sie vor der Erstinbetriebnahme ein paar kleine Schalter im Gerät passend.
Vorsicht: Schalten Sie die Heidelberg Energy Control vor dem Öffnen unbedingt spannungsfrei (Sicherung im Verteiler) – im Inneren liegt Netzspannung an. Im Zweifel übernimmt das der Elektriker.
Für genau diesen Aufbau – eine einzelne Wallbox, gesteuert von einem externen Modbus-Master (dem ESP32), ohne Heidelbergs eigenes Lastmanagement zwischen mehreren Wallboxen:
Schalterblock S4 (Bus-ID der Heidelberg Energy Control)
S4/1 OFF
S4/2 OFF
S4/3 OFF
S4/4 ON -> Bus-ID = 1
Schalterblock S5 (Betriebsart)
S5/1 ON -> Status-LED leuchtet dauerhaft
S5/2 OFF
S5/3 OFF
S5/4 OFF -> Wallbox arbeitet als "Follower"
(reagiert nur auf externe Modbus-Anfragen,
führt selbst kein Lastmanagement)
Schalterblock S6 (Busabschluss / Terminierung)
S6/1 OFF
S6/2 ON -> 120-Ohm-Abschlusswiderstand aktiv
S6/3 OFF
S6/4 OFF Die Heidelberg Energy Control bildet in diesem Aufbau ein Ende der RS-485-Leitung, deshalb bleibt ihr interner Busabschluss (S6/2) aktiv. Setzen Sie am anderen Ende – direkt am MAX485-Modul – zusätzlich einen 120-Ohm-Widerstand zwischen A und B. Baudrate und Datenformat (19200 Baud, 8 Datenbits, gerade Parität, 1 Stoppbit) sind fest vorgegeben; über Schalter stellen Sie die nicht ein.
Hinweis: Diese Einstellungen gelten für eine einzelne, extern per Modbus gesteuerte Wallbox. Sind mehrere Wallboxen über Heidelbergs eigenes lokales Lastmanagement verkettet, gelten andere Bus-IDs und Master/Follower-Rollen – maßgeblich ist dann die Betriebsanleitung von Heidelberg.
TECHNIK
Verkabelung und MQTT-Topics
Die Firmware verbindet ESP32 und Heidelberg Energy Control über ein MAX485-Modul und veröffentlicht alle Werte strukturiert per MQTT.
Pinbelegung und Modbus-Parameter:
Das vollständige Verkabelungsschema (ESP32 ↔ MAX485 ↔ Heidelberg Energy Control, inkl. DE/RE-Brückung) gibt es als eigene Grafik weiter unten im Beitrag. MQTT-Topics (Prefix heidelberg-to-mqtt/<chip-id>/):
RO -> GPIO18 DI -> GPIO19 DE+RE -> GPIO21 (gemeinsam) MAX485 VCC -> 3.3V Modbus: 19200 Baud, 8E1, Slave-ID 1
Alle Werte laufen unter einem gemeinsamen Prefix zusammen (die vollständige Liste aller Topics folgt weiter unten):
status/current Ladestrom (A) status/voltage Spannung (V) status/temperature Temperatur (°C) status/energy Energiezähler (kWh) wifi/rssi, wifi/ssid, wifi/uptime Diagnose control/current_limit Sollstrom setzen (A)
MQTT-REFERENZ
Alle MQTT-Topics im Überblick
Alle Topics laufen unter dem Prefix heidelberg-to-mqtt/<chip-id>/. Die meisten sind als retained markiert – ein neu verbundener Client bekommt den letzten bekannten Wert sofort, ohne auf die nächste Änderung warten zu müssen.
info/… – einmalig beim Boot veröffentlicht (retained):
info/layout_version Modbus-Register-Layout-Version info/hardware_variante Hardware-Variante der Wallbox info/software_revision Software-Revision der Wallbox info/hw_min_ampere Minimal mögliche Stromstärke (A) info/hw_max_ampere Maximal mögliche Stromstärke (A)
status/… – laufend aktualisiert (retained):
status/ladezustand Ladezustand (Rohwert Register 5) status/strom_l1 / _l2 / _l3 Ladestrom je Phase (A) status/spannung_l1 / _l2 / _l3 Spannung je Phase (V) status/leistung_va Scheinleistung (VA) status/energie_gesamt_wh Energiezähler gesamt (Wh) status/temperatur Platinentemperatur (°C) status/extern_gesperrt Externe Sperre aktiv (1 = gesperrt) status/modbus_fehler Zähler für Modbus-Fehler
wifi/… – Diagnosedaten des ESP32 selbst (retained):
wifi/ssid Verbundenes WLAN wifi/bssid MAC-Adresse des Access Points wifi/rssi_dbm Signalstärke (dBm) wifi/rssi_prozent Signalstärke (%) wifi/ip Aktuelle IP-Adresse wifi/uptime_s Laufzeit seit dem letzten Boot (s) wifi/freier_speicher_bytes Freier Heap-Speicher (Byte)
set/… – einzige Steuermöglichkeit, die Firmware abonniert dieses Topic:
set/strom Gewünschter Ladestrom in Ampere (0-max)
0 = Ladevorgang unterbrechen Quelle: README des GitHub-Repositories RDDZ-DE/heidelberg-to-mqtt.
VERSIONSVERLAUF
Von der ersten Version zum stabilen Betrieb
Fünf Versionen innerhalb weniger Tage – jede hat ein konkretes Problem aus dem echten Betrieb gelöst.
v1.0 – v1.1
Erste lauffähige Version, dann eigenes Konfigportal statt WiFiManager, Watchdog-Schutz und Mindeststrom-Absicherung.
v1.2 – v1.3
Konfiguration zur Laufzeit über den Browser, dazu NTP-Zeitstempel in den Logs für nachvollziehbare Fehlersuche.
v1.4
Eigenes WiFi-Diagnose-Topic mit Signalstärke, IP, Uptime und freiem Speicher – für Monitoring ganz ohne Zugriff vor Ort.
Woran lag der Blinkcode 6x weiß / 3x blau?
Der Fehlercode deutete zunächst auf einen Kommunikationsfehler hin, obwohl die Logs keine Modbus-Fehler zeigten. Der eigentliche Grund: eine Leader/Follower-Einstellung an der Heidelberg Energy Control selbst, die den Ladezustand bewusst auf „gesperrt“ hielt – kein Firmware-Bug, sondern ein Konfigurationsdetail der Wallbox.
EINSATZ
Vom Prototyp zum Dauerbetrieb
Software: beliebiges MQTT-System
Die Firmware liest die Heidelberg Energy Control per Modbus aus und veröffentlicht alle Werte über einen MQTT-Broker im Netzwerk, zum Beispiel Mosquitto. Mehr braucht es nicht. Jedes MQTT-fähige System kann die Werte abonnieren und Sollstrom-Vorgaben zurücksenden. Bei mir übernimmt das IP-Symcon für PV-Überschussladen. Genauso gut laufen Home Assistant, openHAB oder ein eigenes Skript – ganz ohne evcc als Vermittler.
Hardware: 3D-gedrucktes Gehäuse
Passend zur Firmware gibt es ein eigenes, selbst gedrucktes Gehäuse für ESP32 und MAX485-Modul: geschlossen, mit sauberer Kabeldurchführung für das Cat7-Anschlusskabel und Zugentlastung per Kabelbinder.
NACHBAUEN
Eigenes Setup in 7 Schritten
Der Quellcode liegt MIT-lizenziert auf GitHub. Wer selbst eine laufende Anbindung an die Heidelberg Energy Control will, findet dort alles Nötige.
Hardware besorgen
ESP32-WROOM-32D + MAX485-Modul, verkabelt nach RO/DI/DE+RE-Schema.
Firmware flashen
Mit PlatformIO bauen und per pio run -t upload aufspielen.
Access Point verbinden
Beim ersten Start erscheint „Heidelberg-to-MQTT-Setup-XXXXXXXX“.
WLAN & MQTT eintragen
Zugangsdaten und Broker-Adresse im Captive-Portal hinterlegen.
Werte prüfen
Ladezustand, Strom und Spannung der Heidelberg Energy Control erscheinen im MQTT-Broker.
Updates & Logs per Browser
/update für neue Firmware-Versionen, /log für den Live-Status.
In beliebiges MQTT-System einbinden
Voraussetzung ist ein MQTT-Broker im Netzwerk (z. B. Mosquitto) – darüber lässt sich die Firmware z. B. per eigenem Modul in IP-Symcon, Home Assistant oder jedem anderen MQTT-fähigen System einbinden.
FAZIT
Manchmal ist die kleinste Lösung die stabilste
Heidelberg-to-MQTT ist kein Feature-Monster, sondern bewusst minimal gehalten: Modbus lesen, MQTT senden, stabil laufen. Genau das macht den Unterschied im Alltag – gerade wenn der ESP32 direkt an der Wallbox verbaut ist und niemand ständig nach dem Rechten sehen will.
Heidelberg-to-MQTT ist eine Eigenentwicklung von RDDZ – vom Firmware-Code über die Modbus-Anbindung bis zur Gehäusekonstruktion. Der Quellcode ist MIT-lizenziert auf GitHub verfügbar – Pull Requests und Nachbauten sind ausdrücklich willkommen.
Hinweis: Die Firmware ersetzt keine geprüfte Herstellersoftware – wir haben sie für unseren eigenen Betrieb entwickelt. Wer eine Heidelberg Wallbox in Betrieb nimmt, sollte die Modbus-Parameter der eigenen Anlage vorher prüfen.
FAQ
Häufige Fragen zur NIS2-Registrierung
QUELLEN
Quellen und Links
- GitHub-Repository: RDDZ-DE/heidelberg-to-mqtt (README, Changelog, Releases)
- Heidelberg Wallbox Energy Control – Modbus-RTU-Dokumentation des Herstellers
- PlatformIO-Dokumentation (ESP32-Build-Toolchain)
Eigenes Smart-Home- oder IoT-Projekt geplant?
Ob ESP32-Firmware, Modbus/MQTT-Anbindung oder passendes 3D-gedrucktes Gehäuse dazu – sprechen Sie uns an.
