Hallo zusammen,
ich möchte heute mein Open-Source-Projekt vorstellen: Ein ESP32 BT50 Failover & Monitor für NIBE Wärmepumpen.
Das Problem: Meine NIBE-Wärmepumpe erhält die Raumtemperatur (BT50) per Modbus TCP. Zuvor hat Home Assistant (HA) diese Werte direkt an die Wärmepumpe geschrieben. Das Problem dabei: Bei jedem HA-Neustart oder Ausfall entstand eine Schreiblücke, woraufhin die Wärmepumpe sofort einen Fehler meldete und munter Alarme verschickte. Das führte im Alltag (gerade wenn man viel an HA bastelt) zu extremer Alarm-Müdigkeit.
Die Lösung: Ich habe einen ESP32 (WROOM-32) als “Middleman” dazwischengeschaltet. Er entkoppelt Home Assistant von der kritischen Steuerungsaufgabe.
Das kann das Projekt im Detail:
-
Direkte CCU-Anbindung: Der ESP32 holt sich die Raumtemperatur per JSON-RPC-API direkt von der Homematic CCU (ohne Umweg über Home Assistant).
-
Modbus Controller: Der ESP schreibt die Werte selbstständig und zuverlässig per Modbus TCP (Register 202, 5986, 5987) an die NIBE Wärmepumpe im 60-Sekunden-Takt.
(BT50 bekommt Raumtemperatur meines Büros) -
Intelligente Failover-State-Machine: Fällt die Temperaturquelle aus, hält der ESP32 den letzten Wert (Holdover-Modus), ohne dass die Wärmepumpe sofort in den Fehler läuft.
-
Abgestufte Telegram-Alarme: Der ESP32 alarmiert selbstständig via Telegram. Es gibt 4 Stufen (NORMAL, HOLDOVER, PREALERT nach 15 Min, CUTOFF nach 60 Min). Erst nach 60 Minuten Ausfall wird der externe Fühler hart deaktiviert, um Frostschutz etc. zu gewährleisten.
-
Telegram-Bot integriert: Man kann den ESP per Telegram steuern (
/status,/test, etc.) und erhält Systemmeldungen (z.B. nach einem Boot). -
Eigenes Web-Dashboard: Ein integrierter Webserver im ESP32 liefert Systemzustände aus (
GET /status, API, Eventlog). -
Home Assistant Anbindung: HA dient nur noch dem passiven Monitoring und liest die REST-API des ESPs aus, um den Zustand übersichtlich darzustellen.
-
LED-Indikator: Status ist direkt am Gerät ablesbar (z.B. Leuchten = OK, Blinken = Problem).
Das Projekt ist komplett in C++ / PlatformIO (Arduino-Framework) geschrieben, um Breaking-Changes durch ESPHome-Updates zu vermeiden und maximale Stabilität zu garantieren.
Falls jemand ein ähnliches Problem mit seiner Heizanlage oder Modbus-Geräten hat, die zickig auf HA-Neustarts reagieren: Vielleicht hilft euch das!
Wenn Interesse besteht veröffentliche das Ganze unter einer MIT Lizenz auf github.
Lasst mich wissen was ihr denkt!
Transparenz: Offene Punkte und Risikoeinschätzung (Security)
Um realistisch zu bleiben: Das Projekt läuft nicht in einer Hochsicherheitsumgebung, sondern in einem typischen Heimnetzwerk. Im Rahmen eines Audit-Reports (“Security Best Practices von Codex”) haben wir bereits viele Lücken geschlossen (z.B. Telegram-Verbindungen auf echtes TLS-Zertifikats-Pinning umgestellt, Payload-Limits aktiviert und API-Tokens für steuernde Endpunkte eingeführt).
Ein paar “offene Wunden” (Acceptable Risks) nehme ich im Heimnetz für den Komfort aber aktuell noch in Kauf:
-
Unverschlüsselte CCU-Anbindung (HIGH Risk im LAN): Die Kommunikation mit der Homematic CCU-API erfolgt über lokales, unverschlüsseltes HTTP. Die Login-Session wird im lokalen Netz im Klartext übertragen. Ein Angreifer im eigenen LAN könnte diese theoretisch mitlesen.
-
Klartext-Secrets im Code (HIGH Risk bei Backups): Zugangsdaten (WLAN, Token, CCU-Passwort) liegen als Klartext in der lokalen
secrets.h. Die Datei ist zwar von Git ausgeschlossen, bei ungesicherten Host-Backups könnten die Daten jedoch abfließen. -
HTTP Control-Plane (HIGH Risk im LAN): Auch wenn Mutating-Endpunkte (wie das manuelle Posten von Daten an den ESP) mit einem API-Token abgesichert sind, reist dieser Token unverschlüsselt über das lokale M-WLAN. Replay-Attacken aus dem eigenen LAN sind somit möglich.
-
Fehlendes Rate-Limiting (MEDIUM Risk): Die API hat derzeit keinen Schutz vor Flood-Angriffen (Token-Bucket etc.). Ein “durchgedrehtes” Gerät im Netz könnte den ESP32 durch Spam-Anfragen lahmlegen (DoS).
-
Offene Telemetrie (MEDIUM Risk): Endpunkte wie
/statusoder/eventserfordern keine Authentifizierung. Jeder im WLAN kann den Zustand der Wärmepumpe/Failovers auslesen. -
Ich bin kein Coder: dieses Projekt ist durch Vibecoding entstanden.
Architektur und Logik: Opus 4.6 / Sonnet 4.6
Implementer: Gemini 3.1 / Kimi K2.5
Test und fixes: Codex 5.3
Fazit: Für ein offenes Gäste-WLAN wäre dieses Setup ungeeignet. Da sich der ESP32, Home Assistant und die CCU aber isoliert im gesicherten Heimnetz/IoT-VLAN befinden, stufen Codex und Claude diese Risiken für meinen Anwendungsfall vorerst als akzeptabel ein.
Hier noch ein paar Screenshots
vom web dashboard:
Die Warnung (reg5986) habe ich bislang noch nicht weg bekommen, aber ist auch nur optisch und beeinträchtigt die Funktion nicht
und von der HA Integration über RESTful API
Die CCU hier hier leider noch als offline angezeigt… ist aber ein reines nice to have
Benachrichtigungen vom Telegram Bot:
um 11:34 war HA nach einem update wieder zurück
und so sieht es aus wenn die CCU mal für 10 Minuten weg war und die Wärmepumpe davon nichts mitbekommen hat:
