Einleitung
Die Integration smarter Heizsysteme in eine Home-Automation-Lösung wie Home Assistant (HASS) ermöglicht nicht nur die zentrale Steuerung, sondern auch detaillierte Analysen und Automatisierungen. Dieser Beitrag zeigt, wie eine Dimplex-Wärmepumpe mit der NWPM Touch-Erweiterung über MQTT mit Home Assistant verbunden wird. Wir richten uns an fortgeschrittene Nutzer, die mit MQTT und YAML bereits vertraut sind.
📌 Update Juli 2026: Dieser Artikel wurde umfassend erweitert — neben zusätzlichen Sensoren ist jetzt auch die Steuerung der Wärmepumpe aus Home Assistant beschrieben (Betriebsmodus, Warmwassersoll, Heizkurve, Smart Grid / SG Ready) inklusive einer wichtigen Stolperfalle beim Schreiben über eine MQTT-Bridge. Siehe „Update Juli 2026″ und Schritt 5 weiter unten.

Die Anleitung basiert auf den von Dimplex zur verfügung gestellten Informationen:
https://dimplex.atlassian.net/wiki/spaces/DW/pages/3021930597/MQTT+Anbindung
Voraussetzungen
Für die Integration benötigen Sie:
- Einen Home Assistant Server, idealerweise auf einem Raspberry Pi, Proxmox oder vergleichbarer Hardware.
- Eine Dimplex-Wärmepumpe mit Touch-Display und einer NWPM Touch-Erweiterung.
- Einen MQTT-Broker, z. B. Mosquitto, entweder als Standalone-Server oder auf der NWPM-Baugruppe.
Optional: Ein Broker-to-Broker-Setup, um einen externen Broker mit dem integrierten MQTT-Server der NWPM zu verbinden.
Besonderheiten bei meiner Dimplex-MQTT-Anbindung
Die Dimplex NWPM Touch-Erweiterung bietet einen eingebauten MQTT-Server, der entweder direkt genutzt oder wie bei mir über ein Broker-to-Broker-Setup mit einem externen Broker verbunden werden kann. Die Konfigurationsdatei für das Broker-to-Broker-Setup sieht beispielsweise so aus:
# connection dimplex
connection dimplex
address 192.168.x.x:61894
remote_username mqtt
remote_password <password>
try_private true
bridge_insecure true
topic # out 0
topic # in 0
In unserem Setup nutzen wir einen Mosquitto-Broker auf Proxmox in einem LXC-Container und empfehlen, diesen für mehr Flexibilität zu verwenden.
Update Juli 2026: Inzwischen ist auch die Steuerung eingerichtet — siehe Schritt 5 weiter unten.
Schritt 1: MQTT in Home Assistant aktivieren
Stellen Sie sicher, dass der MQTT-Integration in Home Assistant aktiviert ist. Dies erfolgt über die configuration.yaml oder über die Benutzeroberfläche von Home Assistant.
Beispiel für die configuration.yaml:
mqtt:
broker: 192.168.x.x # IP-Adresse des MQTT-Brokers
username: mqtt
password: <password>
Starten Sie Home Assistant neu, um die Änderungen zu übernehmen.
Schritt 2: YAML-Konfiguration der Sensoren
Um die Daten der Wärmepumpe in Home Assistant anzuzeigen, fügen Sie die Sensoren in der configuration.yaml hinzu. Hier ist eine Übersicht wichtiger Sensoren:
sensor:
- name: "Wärmepumpe Außentemperatur (R1)"
unique_id: '1301a_temperature'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1301a'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Temperatur Ruecklauf (R2)"
unique_id: '1294a_temperature'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1294a']['value_batch']['1294a']['value'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Temperatur Vorlauf (R9)"
unique_id: '1300a_temperature'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1300-1301a']['value_batch']['1300a']['value'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Temperatur Warmwassersoll"
unique_id: '1042i_temperature'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1042i'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Temperatur Warmwassersoll Max"
unique_id: '1044i_temperature'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1044i'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Temperatur Warmwassersoll Min"
unique_id: '1045i_temperature'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1045i'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Temperatur Warmwasser (R3)"
unique_id: '1305a_temperature'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1305a']['value_batch']['1305a']['value'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Status (Telemetry)"
unique_id: '530u_status_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['530i'] }}"
qos: 1
- name: "Wärmepumpe Sperrmeldungen (Telemetry)"
unique_id: '533i_sperrmeldungen_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['533i'] }}"
qos: 1
- name: "Wärmepumpe Störmeldungen (Telemetry)"
unique_id: '531i_stoermeldungen_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['531i'] }}"
qos: 1
- name: "Wärmepumpe Sensorfehler (Telemetry)"
unique_id: '532i_sensorfehler_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['532i'] }}"
qos: 1
- name: "Wärmepumpe Status"
unique_id: '530i_status'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['530-533i']['value_batch']['530i']['value'] }}"
qos: 1
- name: "Wärmepumpe Verdichter 1"
unique_id: '1500d_status_telemetry'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1500d']['value_batch']['1500d']['value'] }}"
qos: 1
- name: "Wärmepumpe Verdichter 2"
unique_id: '1501i_status_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1501i'] }}"
qos: 1
- name: "Wärmepumpe Ventilator (M2)"
unique_id: '1502d_status_telemetry'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1502-1505d']['value_batch']['1502d']['value'] }}"
qos: 1
- name: "Wärmepumpe Primärpumpe (M11)"
unique_id: '1506d_status_telemetry'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1505-1507d']['value_batch']['1506d']['value'] }}"
qos: 1
- name: "Wärmepumpe Heizungspumpe (M13)"
unique_id: '1512d_status_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1512d'] }}"
qos: 1
- name: "Wärmepumpe Warmwasserpumpe (M18)"
unique_id: '1517d_status_telemetry'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1516-1517d']['value_batch']['1517d']['value'] }}"
qos: 1
- name: "Wärmepumpe Zusatzumwälzpumpe (M16)"
unique_id: '1516d_status_telemetry'
state_topic: "gateway/broadcast/changed_on/modbus"
value_template: "{{ value_json['1516-1517d']['value_batch']['1516d']['value'] }}"
qos: 1
- name: "Wärmepumpe Heizungspumpe (M15)"
unique_id: '1514d_status_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1514d'] }}"
qos: 1
- name: "Wärmepumpe Sammelstörmeldung (H5)"
unique_id: '1523d_status_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1523d'] }}"
qos: 1
- name: "Wärmepumpe Heizungspumpe (M20)"
unique_id: '1515d_status_telemetry'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1515d'] }}"
qos: 1
Weitere Sensoren, wie für Warmwassersolltemperaturen, Sperrmeldungen oder Pumpenstatus, können auf ähnliche Weise hinzugefügt werden. Ich habe noch nicht alle Werte zu 100% geprüft und je nach ausstattung der Wärmepumpe z.B. mit 2. Heizkreislauf, Solar oder Schwimbad anbindung gibt es auch noch mehr Werte die Interessant sein können. Dazu kann man die Adressen auf der Wiki Seite von Dimplex nachschlagen.
Hier ist eine detaillierte Erklärung der einzelnen Elemente anhand des Beispielsensors „Wärmepumpe Außentemperatur (R1)“:
YAML-Abschnitt:
sensor:
- name: "Wärmepumpe Außentemperatur (R1)"
unique_id: '1301a_temperature'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry['1301a'] }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
1. sensor
Die oberste Ebene definiert einen oder mehrere Sensoren. In diesem Fall wird eine Liste von Sensoren definiert, daher wird ein - verwendet, um den einzelnen Sensor zu beschreiben.
2. name
name: "Wärmepumpe Außentemperatur (R1)"
- Beschreibung: Der Anzeigename des Sensors, der in der Benutzeroberfläche von Home Assistant erscheint.
- Empfehlung: Wählen Sie einen klaren und eindeutigen Namen, um den Sensor einfach zu identifizieren.
3. unique_id
unique_id: '1301a_temperature'
- Beschreibung: Eine eindeutige ID für den Sensor. Sie ermöglicht es Home Assistant, den Sensor auch nach Änderungen in der Konfiguration wiederzuerkennen.
- Hinweis: Verwenden Sie eine konsistente Struktur, idealerweise basierend auf der Datenquelle. Hier wurde der Modbus-Registercode
1301averwendet, ergänzt durch_temperaturezur besseren Lesbarkeit.
4. state_topic
state_topic: "extern/broadcast/twin_reported_state"
- Beschreibung: Das MQTT-Topic, aus dem der Sensor seine Daten bezieht.
- Beispiel: In diesem Fall hört der Sensor auf Nachrichten im Topic
extern/broadcast/twin_reported_state. - Wichtig: Die Topics müssen exakt mit denen übereinstimmen, die die NWPM-Baugruppe sendet.
5. value_template
value_template: "{{ value_json.telemetry['1301a'] }}"
- Beschreibung: Ein Template, um die empfangenen Daten aus dem MQTT-Payload zu extrahieren.
- Details:
value_json: Nimmt an, dass die empfangene Nachricht ein JSON-Format hat.telemetry['1301a']: Greift auf das Feld1301ainnerhalb dertelemetry-Struktur zu. Dieses Feld enthält den Wert für die Außentemperatur.
- Empfehlung: Überprüfen Sie die MQTT-Nachrichtenstruktur mit Tools wie MQTT Explorer, um sicherzustellen, dass der Zugriff korrekt definiert ist.
6. unit_of_measurement
unit_of_measurement: "°C"
- Beschreibung: Gibt die Einheit an, in der der Wert dargestellt wird.
- Beispiel: In diesem Fall wird die Temperatur in Grad Celsius (
°C) angezeigt. - Wichtig: Home Assistant verwendet diese Einheit auch für Konvertierungen und Darstellungen in Diagrammen.
7. device_class
device_class: temperature
- Beschreibung: Definiert die Art des Sensors (z. B. Temperatur, Feuchtigkeit, Batterie).
- Beispiel: Der Wert
temperaturesignalisiert Home Assistant, dass der Sensor Temperaturdaten liefert. Dies beeinflusst, wie die Daten dargestellt werden (z. B. mit einem Thermometer-Symbol).
8. qos
qos: 1
- Beschreibung: Die Quality of Service (QoS)-Stufe für MQTT-Nachrichten.
0(Default): Keine Zustellungsgarantie.1: Mindestens einmalige Zustellung (empfohlen für wichtige Daten).2: Genau einmalige Zustellung (weniger häufig verwendet).
- Empfehlung: Für Sensoren, bei denen Datenintegrität wichtig ist, sollte mindestens QoS 1 verwendet werden.
Zusätzliche Hinweise zur Konfiguration
- Validierung: Nach der Einrichtung der YAML-Datei kann die Konfiguration in Home Assistant über Einstellungen → Einstellungen prüfen validiert werden.
- Fehlerbehebung: Falls der Sensor nicht funktioniert, überprüfen Sie:
- Ob MQTT-Nachrichten im definierten Topic empfangen werden (z. B. mit MQTT Explorer).
- Ob das
value_templatekorrekt auf die JSON-Daten zugreift. - Ob die Verbindung zum Broker korrekt eingerichtet ist.
Mit dieser detaillierten Erklärung können Sie ähnliche Sensoren für andere Werte der Wärmepumpe einrichten.
Schritt 3: Zusätzliche Status-Mappings
Um die rohen Statuswerte der Wärmepumpe besser lesbar zu machen, können Sie benutzerdefinierte Templates in YAML definieren. Ein Beispiel für das Mapping des Betriebsstatus:
- sensor:
- name: "Dimplex Status"
unique_id: "dimplex_status_mapped"
state: >
{% set mapping = {
0: "Aus",
1: "Aus",
2: "Heizen",
3: "Schwimmbad",
4: "Warmwasser",
5: "Kühlen",
10: "Abtauen",
11: "Durchflussüberwachung",
24: "Verzögerung Betriebsmodusumschaltung"
} %}
{{ mapping.get(states('sensor.warmepumpe_status_telemetry') | int, "Unbekannt") }}
- sensor:
- name: "Dimplex Sperrmeldungen"
unique_id: "dimplex_Sperrmeldungen_mapped"
state: >
{% set mapping = {
0: "keine Sperre",
2: "Volumenstrom",
5: "Funktionskontrolle",
6: "Einsatzgrenze HT",
7: "Systemkontrolle",
8: "Verzögerung Umschaltung Kühlen",
9: "Pumpenvorlauf",
10: "Mindeststandzeit",
11: "Netzbelastung",
12: "Schaltspielsperre",
13: "Warmwasser Nacherwärmung",
14: "Regenerativ",
15: "EVU-Sperre",
16: "Sanftanlasser",
17: "Durchfluss",
18: "Einsatzgrenze Wärmepumpe",
19: "Hochdruck",
20: "Niederdruck",
21: "Einsatzgrenze Wärmequelle",
23: "System Grenze",
24: "Last Primärkreis",
25: "Sperre Extern",
31: "Aufwärmen",
33: "EvD Initialisierung",
34: "2. Wärmeerzeuger freigegeben",
35: "Störung (siehe Kapitel Störmeldungen)"
} %}
{{ mapping.get(states('sensor.warmepumpe_sperrmeldungen_telemetry') | int, "Unbekannt") }}
- sensor:
- name: "Dimplex Störmeldung"
unique_id: "dimplex_stoermeldung_mapped"
state: >
{% set mapping = {
0: "kein Fehler",
1: "Fehler N17.1",
2: "Fehler N17.2",
3: "Fehler N17.3",
4: "Fehler N17.4",
6: "Elektronisches Ex.Ventil",
10: "WPIO",
12: "Inverter",
13: "WQIF",
15: "Sensorik (siehe Kapitel Sensorfehler)",
16: "Niederdruck Sole",
19: "!Primärkreis",
20: "!Abtauen",
21: "!Niederdruck Sole",
22: "!Warmwasser",
23: "!Last Verdichter",
24: "!Codierung",
25: "!Niederdruck",
26: "!Frostschutz",
28: "!Hochdruck",
29: "!Temperatur Differenz",
30: "!Heißgasthermostat",
31: "!Durchfluss"
} %}
{{ mapping.get(states('sensor.warmepumpe_stormeldungen_telemetry') | int, "Unbekannt") }}
- sensor:
- name: "Dimplex Sensorfehler"
unique_id: "dimplex_sensorfehler_mapped"
state: >
{% set mapping = {
0: "kein Fehler",
1: "Außenfühler (R1)",
2: "Rücklauffühler (R2)",
3: "Warmwasserfühler (R3)",
4: "Codierung (R7)",
5: "Vorlauffühler (R9)",
6: "2. Heizkreisfühler (R5)",
7: "3. Heizkreisfühler (R13)",
8: "Regenerativfühler (R13)",
9: "Raumfühler 1",
10: "Raumfühler 2",
11: "Fühler Wärmequellenaustritt (R6)",
12: "Fühler Wärmequelleneintritt (R24)*",
14: "Kollektorfühler (R23)",
15: "Niederdrucksensor (R25)",
16: "Hochdrucksensor (R26)",
17: "Raumfeuchte 1",
18: "Raumfeuchte 2",
19: "Fühler Frostschutz-Kälte",
20: "Heißgas",
21: "Rücklauffühler (R2.1)",
22: "Schwimmbadfühler (R20)",
23: "Vorlauffühler Kühlen Passiv (R11)",
24: "Rücklauffühler Kühlen Passiv (R4)",
26: "Fühler Solarspeicher (R22)",
28: "Anforderungsfühler Heizen (R2.2)",
29: "RTM Econ",
30: "Anforderungsfühler Kühlen (R39)"
} %}
{{ mapping.get(states('sensor.warmepumpe_sensorfehler_telemetry') | int, "Unbekannt") }}
Dieses Mapping wird im Frontend von Home Assistant als Klartext angezeigt und verbessert die Benutzerfreundlichkeit.
Schritt 4: Test der Integration
Nachdem die YAML-Konfiguration hinzugefügt wurde, starten Sie Home Assistant neu. Die Sensoren sollten nun in der Übersicht auftauchen. Überprüfen Sie, ob die Werte korrekt sind und sich aktualisieren.
Update Juli 2026: Neue Sensoren und Steuerung der Wärmepumpe
Seit dem ursprünglichen Artikel hat sich einiges getan: Die Wärmepumpe lässt sich jetzt auch aus Home Assistant heraus steuern — Betriebsmodus, Warmwassersolltemperatur, Heizkurve, Party-/Urlaubsmodus und sogar Smart Grid / SG Ready. Außerdem sind einige nützliche Sensoren dazugekommen. Der Weg dorthin hatte eine entscheidende Stolperfalle, die in der gerenderten Dimplex-Wiki-Seite leicht zu übersehen ist — dazu gleich mehr.
Neue Sensoren
Die NWPM sendet im Topic extern/broadcast/twin_reported_state deutlich mehr Register, als man zunächst vermutet (bei mir über 100). Ein paar lohnende Ergänzungen zur configuration.yaml (innerhalb des bestehenden mqtt: sensor: Blocks):
- name: "Wärmepumpe Warmwassersoll effektiv"
unique_id: '1594i_ww_soll_effektiv'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ (value_json.telemetry.get('1594i') | float(none)) / 10 if value_json.telemetry.get('1594i') is not none else none }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Rücklaufsoll"
unique_id: '1620i_ruecklaufsoll'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ (value_json.telemetry.get('1620i') | float(none)) / 10 if value_json.telemetry.get('1620i') is not none else none }}"
unit_of_measurement: "°C"
device_class: temperature
qos: 1
- name: "Wärmepumpe Heizkurvenendpunkt"
unique_id: '766i_heizkurvenendpunkt'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry.get('766i', none) }}"
unit_of_measurement: "°C"
qos: 1
- name: "Wärmepumpe Heizkurve Parallelverschiebung"
unique_id: '767i_parallelverschiebung'
state_topic: "extern/broadcast/twin_reported_state"
# Register 0-38, neutral = 19 -> Anzeige als -19..+19 (siehe Schritt 5)
value_template: "{{ (value_json.telemetry.get('767i') | int) - 19 if value_json.telemetry.get('767i') is not none else none }}"
qos: 1
- name: "Wärmepumpe Partystunden"
unique_id: '715i_partystunden'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry.get('715i', none) }}"
unit_of_measurement: "h"
qos: 1
- name: "Wärmepumpe Smart Grid Status"
unique_id: '2662i_smart_grid'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry.get('2662i', none) }}"
qos: 1
Hinweis zur Skalierung: a-Register kommen bereits skaliert an (z. B. "37.4"), die i-Varianten von Temperatur-Sollwerten dagegen unskaliert mit Faktor 10 (1594i = 515 bedeutet 51,5 °C) — daher das / 10 im Template. Einstellwerte wie 1042i (Warmwassersoll) kommen dagegen als ganze Grad.
Schritt 5: Die Wärmepumpe steuern (set_value)
Schreiben funktioniert laut Dimplex-Wiki über das Topic gateway/modbus/set_value/{register} mit einer JSON-Payload:
{"name": "1042u", "value": ["54"]}
Die Stolperfalle: MQTTv5-Properties und die Bridge
Genau so hatte ich es zuerst umgesetzt — und die Wärmepumpe hat alle Schreibbefehle stillschweigend ignoriert. Kein Fehler, keine Reaktion, nichts.
Der Grund: Die Operationen der NWPM verwenden MQTTv5-Properties (response-topic und correlation-data) für das Routing der Antwort. Eine Mosquitto-Bridge (wie im Broker-to-Broker-Setup oben) spricht mit der Gegenstelle aber standardmäßig MQTT 3.1.1 — die v5-Properties gehen dabei verloren, und die NWPM verwirft Requests ohne Antwort-Routing kommentarlos.
Die Lösung steht etwas versteckt im Wiki: Für pre-MQTTv5-Clients muss das Property-Fallback als JSON-Feld mit in die Payload:
{"name": "1042u", "value": ["54"], "mqtt_msg_properties": {"correlation_data": 1042, "response_topic": "extern/hass/set_value_reply/1042u"}}
Damit funktionieren die Schreibbefehle auch über die Bridge. Die Antwort der NWPM ({"status": 0} bei Erfolg) wird auf dem angegebenen response_topic veröffentlicht — nach dem Muster extern/<client>/set_value_reply/... — und läuft über die Bridge (topic # in) zurück zum eigenen Broker, wo man sie z. B. mit MQTT Explorer beobachten kann.
Betriebsmodus als Select-Entität
Register 714u steuert den Betriebsmodus (0 = Sommer, 1 = Auto, 2 = Urlaub, 3 = Party, 4 = 2. Wärmeerzeuger, 5 = Kühlen). In der configuration.yaml unterhalb von mqtt: (auf gleicher Ebene wie sensor:):
select:
- name: "Wärmepumpe Betriebsmodus"
unique_id: '714u_betriebsmodus_select'
command_topic: "gateway/modbus/set_value/714u"
command_template: >-
{% set m = {'Sommer': '0', 'Auto': '1', 'Urlaub': '2', 'Party': '3', '2. Wärmeerzeuger': '4', 'Kühlen': '5'} %}
{"name": "714u", "value": ["{{ m[value] }}"], "mqtt_msg_properties": {"correlation_data": 714, "response_topic": "extern/hass/set_value_reply/714u"}}
state_topic: "extern/broadcast/twin_reported_state"
value_template: >-
{% set names = ['Sommer', 'Auto', 'Urlaub', 'Party', '2. Wärmeerzeuger', 'Kühlen'] %}
{% set v = value_json.telemetry.get('714i') %}
{{ names[v | int] if v is not none and v | int < 6 else this.state }}
options:
- "Sommer"
- "Auto"
- "Urlaub"
- "Party"
- "2. Wärmeerzeuger"
- "Kühlen"
qos: 1
Der Clou: Als state_topic dient wieder die Telemetrie — die Entität zeigt also immer den tatsächlichen Zustand der Wärmepumpe an, auch wenn jemand den Modus direkt am Touch-Display ändert.
Smart Grid / SG Ready
Register 2662u erlaubt die SG-Ready-Steuerung per Software (0 = Hardware-Eingang, 10 = Normalbetrieb, 11 = verstärkter Betrieb, 12 = abgesenkter Betrieb, 13 = Maximalbetrieb inkl. Heizstäbe) — ideal für PV-Überschuss-Automationen:
- name: "Wärmepumpe Smart Grid Modus"
unique_id: '2662u_smart_grid_select'
command_topic: "gateway/modbus/set_value/2662u"
command_template: >-
{% set m = {'Hardware-Eingang': '0', 'Normal (gelb)': '10', 'Verstärkt (grün)': '11', 'Abgesenkt (rot)': '12', 'Max + Heizstäbe (dunkelgrün)': '13'} %}
{"name": "2662u", "value": ["{{ m[value] }}"], "mqtt_msg_properties": {"correlation_data": 2662, "response_topic": "extern/hass/set_value_reply/2662u"}}
state_topic: "extern/broadcast/twin_reported_state"
value_template: >-
{% set m = {'0': 'Hardware-Eingang', '10': 'Normal (gelb)', '11': 'Verstärkt (grün)', '12': 'Abgesenkt (rot)', '13': 'Max + Heizstäbe (dunkelgrün)'} %}
{% set v = value_json.telemetry.get('2662i') %}
{{ m.get(v, this.state) if v is not none else this.state }}
options:
- "Hardware-Eingang"
- "Normal (gelb)"
- "Verstärkt (grün)"
- "Abgesenkt (rot)"
- "Max + Heizstäbe (dunkelgrün)"
qos: 1
Achtung: Nach einem Stromausfall fällt das Register auf 0 (Hardware-Eingang) zurück.
Sollwerte als Number-Entitäten
Nach demselben Muster lassen sich Zahlenwerte schreiben — hier das Warmwassersoll (1042u); Partystunden (715u, 0–72), Urlaubstage (1108u, 0–150) und Heizkurvenendpunkt (766u, 20–70 °C) funktionieren analog:
number:
- name: "Wärmepumpe Warmwassersoll"
unique_id: '1042u_ww_soll_number'
command_topic: "gateway/modbus/set_value/1042u"
command_template: '{"name": "1042u", "value": ["{{ value | int }}"], "mqtt_msg_properties": {"correlation_data": 1042, "response_topic": "extern/hass/set_value_reply/1042u"}}'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ value_json.telemetry.get('1042i', none) }}"
min: 30
max: 60
step: 1
unit_of_measurement: "°C"
device_class: temperature
mode: box
qos: 1
Tipp: Setzen Sie min/max bewusst enger als die Registergrenzen der Wärmepumpe (das Register erlaubt bis 85 °C!) — so kann weder ein Tippfehler noch eine außer Kontrolle geratene Automation unsinnige Werte schreiben.
Eine Besonderheit ist die Parallelverschiebung der Heizkurve (767u): Das Register läuft von 0 bis 38 mit Neutralpunkt 19 — am Display entspricht das −19 bis +19. Intuitiver wird es, wenn man auch in Home Assistant auf der Skala −19 bis +19 arbeitet (0 = neutral) und im Template umrechnet: beim Schreiben Wert + 19, beim Lesen Register − 19:
- name: "Wärmepumpe Heizkurve Parallelverschiebung einstellen"
unique_id: '767u_parallelverschiebung_number'
command_topic: "gateway/modbus/set_value/767u"
# Register 0-38 mit Neutralpunkt 19 -> UI -19..+19 (Register = Wert + 19)
command_template: '{"name": "767u", "value": ["{{ value | int + 19 }}"], "mqtt_msg_properties": {"correlation_data": 767, "response_topic": "extern/hass/set_value_reply/767u"}}'
state_topic: "extern/broadcast/twin_reported_state"
value_template: "{{ (value_json.telemetry.get('767i') | int) - 19 if value_json.telemetry.get('767i') is not none else none }}"
min: -19
max: 19
step: 1
mode: box
qos: 1
Nach dem Einfügen genügt ein Reload der MQTT-Entitäten (Entwicklerwerkzeuge → YAML → „Manuell konfigurierte MQTT-Entitäten“) — ein kompletter Neustart ist nicht nötig.
Beispiel-Automation: Automatische Sommer-/Winterumschaltung
Als praktisches Beispiel eine Automation, die täglich die 5-Tage-Prognose auswertet (Tagesmittel aus Höchst- und Tiefstwert): Liegen alle fünf Tage unter 15 °C, schaltet sie auf Auto (Winterbetrieb), liegen alle darüber, auf Sommer. Dazwischen passiert nichts — das wirkt als natürliche Hysterese gegen ständiges Hin- und Herschalten. Manuell gesetzte Modi wie Urlaub oder Party werden nie überschrieben:
alias: "Wärmepumpe Saisonumschaltung (Sommer/Winter)"
description: "5-Tage-Prognose: alle Tagesmittel < 15°C → Auto (Winter); alle > 15°C → Sommer"
triggers:
- trigger: time
at: "12:00:00"
conditions:
- condition: template
value_template: "{{ states('select.warmepumpe_betriebsmodus') in ['Sommer', 'Auto'] }}"
actions:
- action: weather.get_forecasts
target:
entity_id: weather.forecast_home
data:
type: daily
response_variable: fc
- variables:
temps: >-
{% set ns = namespace(t=[]) %}
{% for d in fc['weather.forecast_home']['forecast'][:5] %}
{% set low = d.templow if d.templow is defined and d.templow is not none else d.temperature %}
{% set ns.t = ns.t + [((d.temperature + low) / 2) | round(1)] %}
{% endfor %}
{{ ns.t }}
- choose:
- conditions:
- condition: template
value_template: "{{ temps | length >= 5 and temps | max < 15 and states('select.warmepumpe_betriebsmodus') != 'Auto' }}"
sequence:
- action: select.select_option
target:
entity_id: select.warmepumpe_betriebsmodus
data:
option: "Auto"
- action: notify.notify
data:
message: "Wärmepumpe auf Winterbetrieb (Auto) umgestellt. 5-Tage-Prognose Tagesmittel: {{ temps | join('°C, ') }}°C — alle unter 15°C."
- conditions:
- condition: template
value_template: "{{ temps | length >= 5 and temps | min > 15 and states('select.warmepumpe_betriebsmodus') != 'Sommer' }}"
sequence:
- action: select.select_option
target:
entity_id: select.warmepumpe_betriebsmodus
data:
option: "Sommer"
- action: notify.notify
data:
message: "Wärmepumpe auf Sommerbetrieb umgestellt. 5-Tage-Prognose Tagesmittel: {{ temps | join('°C, ') }}°C — alle über 15°C."
mode: single
(weather.forecast_home ist die Standard-Wetterentität der Met.no-Integration; den Notify-Dienst an das eigene Setup anpassen.)
Sicherheitshinweise zum Schreiben
- Konservativ anfangen: Zum Testen zuerst einen Wert schreiben, der dem aktuellen entspricht, oder einen harmlosen wie die Partystunden — und die Bestätigung in der Telemetrie abwarten.
- Grenzen setzen:
min/maxin den Number-Entitäten eng wählen (siehe oben). - Zustand zurücklesen: Immer die Telemetrie als
state_topicverwenden stattoptimistic— dann sieht man sofort, ob ein Schreibbefehl wirklich angekommen ist. - Ein Schreibbefehl ohne
mqtt_msg_propertieswird über eine MQTT-3.1.1-Bridge kommentarlos verworfen — wenn also „nichts passiert“, zuerst hier suchen.
Besonderheiten und Tipps
- Broker-to-Broker-Setup: Wenn der direkte Zugriff auf den NWPM-MQTT-Server nicht möglich oder gewünscht ist, sorgt ein Broker-to-Broker-Setup für die Weiterleitung der Daten.
- Debugging: Nutzen Sie Tools wie MQTT Explorer, um die Nachrichtenströme zwischen Broker und Home Assistant zu überwachen.

Mit dieser Integration können Sie die Wärmepumpe effizient in Ihre Home Assistant Umgebung einbinden und Daten für Automatisierungen und Analysen nutzen. Viel Erfolg!
Falls noch etwas fehlt oder du weitere Details ergänzt haben möchtest, lass es mich wissen!


















