Wer eine Daikin Altherma (oder ein baugleiches Rotex-/Hoval-Belaria-Modell) besitzt und sie in Home Assistant integrieren will, stößt schnell auf eine ernüchternde Erkenntnis: Es gibt nicht die eine Lösung, sondern mehrere Bausteine, die zusammen erst ein vollständiges Bild ergeben. In diesem ersten Teil der Serie kläre ich, welche Wege es gibt, wofür sie taugen – und wofür nicht – und steige dann in die Hardware-Seite ein: wie der ESP32 physisch an die Wärmepumpe angeschlossen wird. Das Herzstück der Auslese-Seite ist dabei das Open-Source-Projekt ESPAltherma von Entwickler raomin, auf dessen Dokumentation und Definitionsdateien diese Serie aufbaut.
Die Architektur: Drei Bausteine, drei Aufgaben
Bevor irgendein Kabel verlegt wird, lohnt sich der Überblick, weil er spätere Enttäuschungen erspart. Wer ESPAltherma installiert in der Hoffnung, damit auch die Heizkurve verstellen zu können, wird schnell merken: Das funktioniert nicht. ESPAltherma ist ein reines Auslese-Projekt. Für die eigentliche Steuerung braucht es andere Komponenten. In meinem eigenen Setup sieht die Aufteilung so aus:
1. ESPAltherma – Lesen, und zwar richtig detailliert
ESPAltherma klinkt sich seriell in die Kommunikation zwischen der Inneneinheit und den internen Steuerkomponenten der Altherma ein (Protokoll P1P2, dazu gleich mehr). Der große Vorteil: Es liefert Werte, die keine andere Integration hergibt – Verdampfungsdruck, Kondensationsdruck, Sauggastemperatur, Heißgastemperatur, Inverter-Frequenz des Kompressors, Ventilstellungen. Das sind die Werte, mit denen man tatsächlich verstehen kann, was die Wärmepumpe gerade tut, statt nur zu sehen, dass „geheizt wird“. Der Nachteil: ESPAltherma kann (mit einer kleinen Ausnahme, dazu in Teil 2) nicht in die Regelung eingreifen. Es ist ein Beobachter, kein Akteur.
2. Daikin Cloud/Onecta-Integration – Steuern von Heizung und Warmwasser-Regelbetrieb
Für die eigentliche Steuerung – Heizkurve, Betriebsmodus, Warmwasser-Zeitplan, Urlaubsmodus – kommt bei mir die offizielle Daikin-Cloud-Integration (Onecta) zum Einsatz. Sie spiegelt im Wesentlichen das, was auch die Daikin-App kann, eben nur eingebettet in Home Assistant und damit automatisierbar. Der Kompromiss: Diese Integration läuft über die Herstellercloud, ist also nicht lokal, aber dafür stabil und offiziell unterstützt.
3. SG-Ready-Kontakte – der Warmwasser-Boost
Für den PV-Überschuss-gesteuerten Warmwasser-Boost nutze ich die SG-Ready-Schnittstelle der Wärmepumpe – dazu hatte ich bereits einen eigenen Artikel veröffentlicht. Das ist bewusst getrennt von den beiden anderen Bausteinen: SG-Ready ist ein einfaches, robustes Kontakt-Signal (potentialfrei), das die Wärmepumpe selbst interpretiert – ideal für die eher grobe, aber zuverlässige „jetzt mehr Wärme reinstecken“-Logik bei PV-Überschuss.
Der vierte, mächtigere Weg – mit Verfallsdatum
Es gibt noch eine vierte Möglichkeit, die ich aktuell parallel nutze, aber bewusst nicht als Kern meines Setups gewählt habe: den Daikin Home Hub über Modbus. Der Home Hub ist ein separates Gateway-Modul, das Daikin für die Einbindung in Energiemanagementsysteme anbietet. Über die Modbus-Schnittstelle (technisch beheimatet in einem Baustein namens EKRHH) lassen sich nicht nur Werte auslesen, sondern auch fast alle Sollwerte direkt schreiben: Vorlauftemperatur-Sollwerte für Heizen und Kühlen, Warmwasser-Nachheiz-Sollwert, Leistungsgrenzen, Betriebsmodus, Smart-Grid-Zustand.
Klingt nach der eierlegenden Wollmilchsau – hat aber einen entscheidenden Haken: Der Home Hub kann nur einen Modus gleichzeitig sprechen. Aktuell läuft meiner im Modbus-Modus, aber die anstehende Pflicht zur EEBus-Anbindung für den Netzbetreiber (im Rahmen der §14a-Regelungen) zwingt mich, auf EEBus umzustellen – und dann ist mit Modbus Schluss. Wer das umgehen will: Es lassen sich offenbar auch zwei Home-Hub-Boxen parallel betreiben, eine im Modbus- und eine im EEBus-Modus. Ich werde selbst zunächst ohne diese Zusatzbox weitermachen, daher bleibt Modbus in dieser Serie ein Exkurs und kein Kernbaustein – aber wer noch nicht umstellen muss, findet in Teil 2 trotzdem die relevanten Details dazu.
Warum diese Aufteilung sinnvoll ist
Der Grund, warum ich nicht versuche, alles über einen einzigen Kanal zu lösen: Jede der drei Kernkomponenten hat eine Aufgabe, für die sie besonders gut geeignet ist. ESPAltherma für die Tiefe (Diagnose, Verständnis, Dashboard), die Cloud-Integration für die alltägliche, robuste Steuerung, SG-Ready für die einfache, hardwarenahe PV-Logik. Wer versucht, alles über Modbus zu machen, baut sich eine Abhängigkeit auf, die – wie mein eigenes Beispiel zeigt – durch regulatorische Änderungen jederzeit wegbrechen kann.
Was ist überhaupt das P1P2-Protokoll?
ESPAltherma liest nicht etwa Modbus oder ein anderes standardisiertes Protokoll aus, sondern klinkt sich in die interne, proprietäre serielle Kommunikation der Altherma ein – das sogenannte „I“-Protokoll (Daikin-intern, reverse-engineered von der Community), auf älteren Geräten auch das ältere „S“-Protokoll. Diese Kommunikation läuft normalerweise zwischen der Inneneinheit und optionalen Zubehörteilen wie dem digitalen Raumthermostat. Der Clou: Der ESP32 klinkt sich einfach als zusätzlicher, passiver Lauscher an diese Leitung – genau dafür gibt es auf der Platine einen dedizierten Steckverbinder.
Der X10A-Anschluss: Wo die Reise hingeht
Auf der Hauptplatine der Inneneinheit findet sich ein mit X10A beschrifteter Steckverbinder. Das ist der serielle Port, über den auch das optionale digitale Raumthermostat kommuniziert. Genau hier setzt ESPAltherma an.
Eine wichtige Ausnahme: Wer ein Bi-Zone-Modul verbaut hat (zwei getrennte Heizkreise), findet den X10A-Port dort bereits durch ein Kabel zum Bi-Zone-Modul belegt. In diesem Fall ist stattdessen der X12A-Port am Bi-Zone-Modul die richtige Adresse – die Pinbelegung ist identisch zu X10A.
Pinbelegung: Die 4-Pin-Variante (Standard-Altherma)
Bei den meisten Daikin-Altherma-Modellen ist der X10A-Anschluss 4-polig aufgebaut. Die Pinbelegung von links nach rechts (Blickrichtung auf den Stecker):
| Pin | Bezeichnung | Funktion |
|---|---|---|
| 1 | 5V | Versorgungsspannung – kann den ESP32 direkt mit Strom versorgen |
| 2 | TX | Sendeleitung der Wärmepumpe → geht an den RX-Pin des ESP32 |
| 3 | RX | Empfangsleitung der Wärmepumpe → geht an den TX-Pin des ESP32 |
| 4 | NC | Nicht belegt |
| 5 | GND | Masse – zwingend mit dem ESP32-GND verbinden |
Wichtig beim Verkabeln: TX der Wärmepumpe geht an RX des ESP32 und umgekehrt – ein klassisches Kreuzverkabelungs-Prinzip, wie man es von seriellen Schnittstellen kennt. Wer stattdessen TX-zu-TX und RX-zu-RX verbindet, bekommt gar keine Kommunikation zustande.
Zum Anschließen empfiehlt sich entweder ein passender 5-poliger JST-EH-2.5mm-Steckverbinder (steckt sauber und lösbar in den bestehenden Anschluss) oder vier einzelne Dupont-Kabel (Female-Male), die auf die Pins des vorhandenen Steckverbinders aufgesteckt werden, ohne diesen selbst zu verändern.
Passendes ESP32-Board: ESP32 NodeMCU Development Board mit WROOM-32 bei Amazon ansehen*
* Affiliate-Link: Wenn du über einen entsprechend gekennzeichneten Link etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich ändert sich der Preis dadurch nicht. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.
Pinbelegung: Die 8-Pin-Variante (Rotex-Modelle)
Baugleiche Rotex-Wärmepumpen haben teils einen anders aufgebauten, 8-poligen X10A-Steckverbinder. Auch hier liegt Pin 1 (von links betrachtet) auf +5V. Die Zuordnung der übrigen Pins unterscheidet sich vom 4-Pin-Standard – hier lohnt sich vorab ein Blick ins jeweilige Rotex-Servicehandbuch oder in die einschlägigen Community-Threads, da die Belegung je nach Modelljahr leicht variieren kann.
Ein in der Community häufig berichtetes Problem bei Rotex-Geräten: Die 5V-Versorgung des X10A-Ports ist teils zu schwach ausgelegt, um zusätzlich zur eigentlichen Thermostat-Kommunikation auch noch einen ESP32 mitzuversorgen. In diesem Fall empfiehlt sich ein separates USB-Netzteil für den ESP32 – die GND-Verbindung zur Wärmepumpe bleibt davon unberührt und ist weiterhin zwingend erforderlich (dazu gleich mehr).
Passendes externes Netzteil: 5-V-/2-A-USB-Netzteil bei Amazon ansehen*
Sicherheitshinweis: Bevor irgendetwas angefasst wird
Eine Wärmepumpe hängt am 230-Volt-Netz und führt zusätzlich Kältemittel unter Druck. Das Öffnen des Gehäuses zur Platine ist in der Regel unproblematisch, weil der X10A-Bereich niederspannungsseitig (5V-Logik) liegt – trotzdem gilt:
- Wärmepumpe vor dem Öffnen an der zugehörigen Sicherung abschalten
- Nach dem Abschalten kurz warten, bis interne Kondensatoren sich entladen haben, bevor an der Platine gearbeitet wird
- Arbeiten an der Kältemittelseite (Rohrleitungen, Ventile) sind hiervon nicht betroffen und auch nicht Gegenstand dieses Projekts – hier wird ausschließlich die Kommunikationsleitung angezapft
- Im Zweifel: Rücksprache mit dem installierenden Fachbetrieb halten, insbesondere wenn noch Gewährleistung auf dem Gerät liegt (das Öffnen des Gehäuses ist in der Regel unkritisch, das Verändern von Kältekreis-Komponenten dagegen nicht – ESPAltherma rührt an keiner dieser Komponenten)
Level-Shifter: Nötig oder nicht?
Ein technisches Detail, das in Foren regelmäßig diskutiert wird: Der X10A-Port arbeitet mit TTL-Pegeln auf 5V-Basis, der ESP32 dagegen ist ein 3,3V-Gerät und seine GPIOs sind – anders als beim klassischen 5V-toleranten Arduino – nicht durchgängig für 5V ausgelegt.
In der Theorie bedeutet das: Ein Level-Shifter (Pegelwandler) zwischen X10A-TX und ESP32-RX wäre die sichere Lösung, um die GPIOs vor Überspannung zu schützen. In der Praxis berichtet die überwiegende Mehrheit der ESPAltherma-Nutzer – mich eingeschlossen – von einem stabilen Betrieb auch ganz ohne Level-Shifter. Eine Erklärung dafür: Die tatsächlich anliegenden Pegel liegen oft niedriger als die nominalen 5V, und die kurze Signaldauer sowie der vergleichsweise hochohmige Innenwiderstand der Leitung sorgen dafür, dass die GPIOs in der Praxis nicht dauerhaft überlastet werden.
Wer auf Nummer sicher gehen will, kann einen einfachen bidirektionalen Logic-Level-Converter (für wenige Euro erhältlich) zwischen die TX/RX-Leitungen schalten. Das kostet etwas Lötaufwand und Platz, eliminiert aber jedes Risiko für die ESP32-Hardware. Ich selbst verzichte darauf, weise aber ausdrücklich darauf hin: Betrieb ohne Level-Shifter erfolgt auf eigenes Risiko.
Passender Pegelwandler: bidirektionaler 3,3-V-/5-V-Logic-Level-Converter bei Amazon ansehen*
Stromversorgung des ESP32
Zwei Optionen stehen zur Wahl:
- Versorgung über die 5V-Leitung des X10A-Ports. Bequem, weil kein zusätzliches Kabel nötig ist. Funktioniert bei den meisten Standard-Altherma-Geräten problemlos – auf meiner eigenen Anlage sorgt ein großzügig dimensionierter 7805-Spannungsregler mit Kühlkörper für stabile 5V, und der ESPAltherma-Verbrauch von rund 70mA fällt kaum ins Gewicht.
- Externes Netzteil (z.B. gewöhnliches USB-Ladegerät). Notwendig, wenn die interne 5V-Versorgung zu schwach ist (siehe Rotex-Hinweis oben) oder man den Stromkreis der Wärmepumpe grundsätzlich nicht zusätzlich belasten möchte.
Der wichtigste Punkt, unabhängig von der gewählten Stromversorgung: Die GND-Leitung zwischen ESP32 und X10A-Port muss immer verbunden sein – auch wenn der ESP32 über ein externes Netzteil versorgt wird. Ohne gemeinsame Masse funktioniert die serielle Kommunikation nicht zuverlässig, selbst wenn TX/RX korrekt verkabelt sind. Das ist laut übereinstimmenden Erfahrungsberichten aus der Community die mit Abstand häufigste Fehlerquelle bei „Timeout“- oder CRC-Fehlern – dazu mehr in Teil 2, wenn es um die Fehlersuche nach dem Flashen geht.
Praxistipp: Wackelkontakt vermeiden
Ein oft unterschätztes Detail: Dupont-Kabel sind bequem, aber notorisch anfällig für Wackelkontakte – gerade auf dem eng gebauten X10A-Steckverbinder. Ein einzelner minimaler Wackelkontakt auf der TX- oder RX-Leitung äußert sich dann nicht als „geht gar nicht“, sondern als sporadische CRC-Fehler, die sich nur schwer eingrenzen lassen. Eine bewährte Lösung aus der Community: einen gewöhnlichen 2,54mm-Buchsenleisten-Header auf den X10A-Steckverbinder aufstecken und die Dupont-Kabel dann auf die längeren, stabileren Pins dieses Headers stecken statt direkt auf den Original-Steckverbinder. Das reduziert mechanischen Stress auf die Original-Buchse spürbar.
Wo soll der ESP32 physisch sitzen?
Ich selbst setze einen gewöhnlichen ESP32 ohne jedes zusätzliche Gehäuse ein – die Platine hängt einfach frei an den Anschlusskabeln im Gehäuse der Wärmepumpe, ganz ohne Isolierung, Schrumpfschlauch oder Ähnliches, und läuft damit seit längerem stabil. Auch einen Level-Shifter zwischen X10A und ESP32 nutze ich nicht (siehe oben) – in der Praxis war beides schlicht nicht nötig.
Wer es dennoch etwas aufgeräumter mag oder zusätzlichen Kontaktschutz möchte, kann alternativ zum vom ESPAltherma-Projekt empfohlenen M5StickC/M5StickC Plus greifen. Das bringt ein eigenes Gehäuse und ein kleines Display mit (praktisch für Statusanzeigen/Logs direkt am Gerät), kostet aber auch spürbar mehr als eine einfache ESP32-Platine – notwendig ist es nach eigener Erfahrung nicht.
Home Assistant selbst läuft bei mir auf einem Raspberry Pi 4*, auf dem auch die ESPAltherma-Daten später als Entitäten und Automationen zusammenlaufen.
Ausblick auf Teil 2
Mit der Hardware-Seite ist die eine Hälfte der Arbeit erledigt. Im nächsten Teil geht es an die Software: Firmware mit VSCode und PlatformIO flashen, die passende Definitionsdatei für das eigene Wärmepumpenmodell auswählen, die gewünschten Werte freischalten – und die fertigen Daten dann als saubere Entitäten in Home Assistant zum Leben erwecken, inklusive der eigenen Template-Sensoren, die ich für Drücke, Temperaturen und Inverter-Frequenz im Einsatz habe. Weiter geht es hier mit ESPAltherma Teil 2: Firmware flashen und in Home Assistant einbinden.