Der Ausgangspunkt
Die Stiebel Eltron LWZ 504 ist eine Kompaktanlage — Wärmepumpe, Warmwasser, Lüftung in einem Gerät. Das ist komfortabel, bis man feststellt: Alle Einstellungen müssen direkt an der Anlage im Technikraum gemacht werden. Das optionale Raumgerät FES Komfort hatte ich nicht eingebaut. Jede Temperaturänderung, jede Programmumstellung — Keller.
Das Gerät hat aber einen USB-Anschluss. Stiebel Eltron gibt dazu nichts heraus, kein Protokoll, keine Dokumentation. Aber im FHEM-Forum hatte jemand die serielle Kommunikation reverse-engineered und ein Perl-Modul namens THZ gebaut. Das war die Grundlage.
Kein Programmierer — und trotzdem
Ich habe in diesem Projekt keine einzige Zeile Code selbst geschrieben. Das gesamte System — Backend, Frontend, Protokoll-Implementierung, MQTT-Integration, Datenbank — ist zusammen mit Claude Code entstanden. Ich habe das Ziel definiert, Entscheidungen getroffen, Zusammenhänge erklärt und Probleme beschrieben. Claude Code hat implementiert.
Das war kein einmaliger Sprint. Wir haben das System in mehreren Iterationen aufgebaut und ständig weiterentwickelt — von v1.0.0 bis heute v1.2.5. Jedes Release hat etwas Konkretes gebracht: stabilere serielle Kommunikation, neue Seiten, Energiezähler, MQTT-Bugfixes, Saison-Presets, UI-Verbesserungen. Das liest sich wie ein normaler Entwicklungszyklus — weil es einer ist.
Für mich ist das der praktische Beweis, was heute mit KI-gestützter Entwicklung möglich ist: Ein IT-Manager mit technischem Hintergrund, aber ohne Programmiererfahrung, baut ein vollständiges, produktiv laufendes System. Das verändert, wie ich über den Einsatz von KI in Unternehmen nachdenke — und was ich meinen Kunden empfehle.
Vom FHEM-Modul zur eigenen Implementierung
Ich habe das FHEM-ModulTHZ von GitHub heruntergeladen und Claude Code gebeten,
es zu analysieren. Das Perl-Modul ist über Jahre gewachsen — viele Gerätetypen, viele
Sonderfälle. Für meine Anlage mit Hardware-ID HW:98 (die gar nicht
in der FHEM-Liste stand) mussten die Byte-Offsets einzeln herausgearbeitet werden.
Das Protokoll selbst ist ein klassisches serielles Request-Response-Protokoll:
115200 Baud, ein Drei-Phasen-Handshake mit STX/DLE/ETX-Steuerzeichen,
Byte-Escaping für 0x10 und eine einfache Modulo-256-Prüfsumme.
Die Anlage kennt zwei Kommandoarten — GET für Lesewerte und SET für schreibbare
Parameter. ~130 Parameter lassen sich schreiben, von Solltemperaturen bis zum
Betriebsmodus.
Bei HW:98 ist sGlobal.compressor dauerhaft auf 1 gesetzt —
ein Hardware-Bug. Den Verdichterstatus lese ich deshalb ausschließlich aus
dem Display-Register sDisplay, das den tatsächlichen Zustand
der Anlage widerspiegelt.
Das Web-Interface
Das Backend läuft in Python 3.12 mit FastAPI und asyncio auf einem Raspberry Pi —
direkt per USB an der Anlage. Ein asyncio.Lock serialisiert alle
Zugriffe auf die serielle Schnittstelle, weil nur ein Prozess gleichzeitig
schreiben darf. Nach jedem SET-Befehl liest das Backend den Wert direkt zurück
und bestätigt den tatsächlichen Anlagenwert — nicht den gesendeten.
Das Frontend ist in Svelte 5 gebaut und bezieht Live-Daten per WebSocket. Es gibt vier thematische Seiten:
- Dashboard — Anlagenstatus, aktueller Betriebsmodus, Energieübersicht, Fehlerlog
- Heizkreis — Temperaturen, Heizkurve, Saison-Presets, Energiezähler
- Warmwasser — Solltemperaturen, Pasteurisierungsprogramm, Energiezähler
- Lüftung — Lüftungsstufen, Luftmengen in m³/h, Wochenprogramm
Alle Messwerte werden in SQLite mit konfigurierbarer Retention gespeichert und lassen sich als Zeitreihen in ECharts-Diagrammen darstellen — Vorlauf, Rücklauf, Außentemperatur, COP und Jahresarbeitszahl auf einen Blick.
MQTT und Home Assistant
Im zweiten Schritt kam MQTT dazu. Ich wollte selektiv entscheiden: Welche Werte soll Home Assistant nur lesen dürfen — und welche auch schreiben?
Das System unterscheidet deshalb zwischen zwei Modi, die sich pro Parameter einzeln aktivieren lassen:
- MQTT-Send — Wert wird bei jedem Poll an HA publiziert (retain, QoS 1)
- MQTT-Write — HA darf den Parameter über ein
/set-Topic schreiben
HA Auto-Discovery sorgt dafür, dass Sensoren, Binärsensoren, Zahlenfelder und Auswahlfelder (z.B. der Betriebsmodus) automatisch in Home Assistant auftauchen — ohne manuelle Entity-Konfiguration.
MQTT-Write aktivieren setzt MQTT-Send automatisch mit. Ohne Send würde Home Assistant nach einem Reconnect keinen aktuellen State mehr kennen und könnte den Parameter auf einen falschen Wert zurücksetzen.
PV-Optimierung: Sommer, Winter, Übergang
Mit der MQTT-Write-Anbindung wurde es interessant. Ich habe das Sommer- und Winterprogramm in Home Assistant so angepasst, dass die Anlage zu Zeiten mit hohem PV-Ertrag stärker heizt oder das Warmwasser auflädt — also Strom verbraucht, wenn er ohnehin produziert wird.
Das eigentliche Problem war die Übergangszeit: Im Frühjahr und Herbst taktet die Anlage häufig kurz — der Verdichter startet, hört aber schnell wieder auf, weil die Solltemperatur rasch erreicht ist. Das ist ineffizient und erhöht den Verschleiß.
Ich habe dafür eine Übergangsbewertung gebaut, die mehrere Werte kombiniert — Außentemperatur, Vorlauftemperatur, Verdampfertemperatur und tatsächliche Verdichterlaufzeit. Wenn die Bewertung ein bestimmtes Muster zeigt, schaltet Home Assistant automatisch ein Übergangsprogramm mit leicht angepassten Sollwerten. Das Ergebnis: längere, gleichmäßigere Verdichterlaufzeiten und ein deutlich besserer COP in den Übergangsmonaten.