Entitäten

Entitäten der Smart-Funktionen

Das optionale Smart Energy & Comfort-Profil ergänzt elektrische und thermische Energiezähler für Gesamtlaufzeit, Tag und Monat, COP für dieselben Zeiträume, geschätzte Kosten, CO₂ und optionale PV-Nutzung sowie die Verdichterzyklus- und Betriebsanalyse. Es handelt sich um abgeleitete Werte, nicht um zusätzliche physische Zähler. Die erforderlichen Leistungsregister müssen verfügbar sein.

Der Health Monitor ergänzt acht Prüfungen auf Probleme und einen Berichtssensor. Heizkurven- und Wetterberater ergänzen schreibgeschützte Empfehlungen. Der Predictive Advisor ergänzt ein strikt schreibgeschütztes Empfehlungs-Framework (Status, Empfehlungen, Datenqualität). Der optionale Komfort-Zeitplan verändert den bestehenden Raum-Sollwert des Heizkreises; er erzeugt keine zweite Klima-Regelentität. Das automatische Warmwasserladen nutzt die bestehenden Boost-Bedienelemente und die bestehende Zustandsmaschine.

Jede Entität, die diese Pakete erzeugen können, steht mit ihrem exakten Namen unter Entitäten der optionalen Funktionen; die Unterteilung in Untergeräte beschreibt Gerätegruppen (Gerätehierarchie).

Mit aktivierter Gerätehierarchie separieren iDM Analytics, iDM Health Monitor, iDM Comfort und Diagnose diese Funktionen von den Regler-Entitäten. Wird eine optionale Funktion deaktiviert, werden ihre Entitätsregistrierungen entfernt; beim erneuten Aktivieren werden dieselben IDs wiederhergestellt. Bestehende Regler-IDs bleiben erhalten.

Die Integration erzeugt Entitäten dynamisch auf Grundlage deiner Wärmepumpen-Konfiguration (Heizkreise, Zonen, optionale Funktionen).

Entitäts-Plattformen

Die genauen Zahlen hängen vom erkannten Modell, den aktiven Heizkreisen, Zonen, Räumen und optionalen Funktionen ab. Das Hinzufügen von Heizkreisen, Zonen, Kaskade oder Web-Supplement-Daten kann zusätzliche Entitäten hinzufügen.

Entitäten werden in Home Assistant, wo möglich, nach Funktion gruppiert: Konfigurations-Entitäten zuerst, gefolgt von Schaltern, schreibbaren Werten, Live-Messwerten und Diagnose.

Entitätsnamen und Sprachen

Entitätsnamen stammen aus den Übersetzungsdateien der Integration und folgen der in Home Assistant eingestellten Sprache: Eine englische Installation zeigt englische Namen, eine deutsche zeigt die deutschen Namen, die die Integration schon immer verwendet hat. Heizkreise und Zonenräume teilen sich jeweils einen Namen pro Messwert und ergänzen den Heizkreisbuchstaben oder die Zonen-/Raumnummer, zum Beispiel Heizkreis A Vorlauftemperatur und Zone 1 Raum 2 Temperatur.

Das Ändern der Home-Assistant-Sprache ändert nur die angezeigten Namen. Entitäts-IDs und Unique-IDs bleiben exakt, wie sie sind, sodass Dashboards, Automationen und Langzeitstatistiken weiter funktionieren. Eine Entität, die nach einem Sprachwechsel erstellt wird, leitet ihre Entitäts-ID vom Namen in dieser Sprache ab — wie bei jeder Home-Assistant-Integration.

Sensoren

Laufzeit-Diagnose

Dieser Sensor bleibt auch dann verfügbar, wenn die Abfrage der Wärmepumpe fehlschlägt, was ihn beim Zusammenstellen von Informationen für einen Fehlerbericht nützlich macht. Die direkte Socket-Laufzeit wird über die Attribute modbus_connection_version und tmodbus_version identifiziert.

Systemtemperaturen & Drücke

Navigator 10 — Wärmesenke (Trennwärmetauscher)

Register 1072 ist ein wortgetauschtes FLOAT32 — die offizielle IDM-Doku nennt UCHAR, Feldmessungen haben aber den Float bewiesen (0.23.0-b8): Eine Anlage mit livem Durchfluss zeigt echte L/min-Werte. Ohne Trennwärmetauscher meldet der ganze Block „nicht vorhanden" (-1.0), und diese Entitäten bleiben nicht verfügbar; liefert das Web-Supplement eine eigene Durchflusszeile, füllt deren Wert den Durchfluss automatisch auf (siehe Bekannte Einschränkungen).

Verdichter & Pumpen

Energie & Leistung

PV / Energiemanagement

Der Batterie SOC akzeptiert 0–100; -1 bedeutet, dass kein Batteriewert vorliegt. Wer Adresse 86 wie die umgebenden FLOAT-Werte über zwei Register behandelt, erhält ein unplausibles Ergebnis. Wenn eine Batterie genutzt wird, verlangt der IDM-Support zusätzlich das Schreiben von Register 84 (battery_discharge); nur den SOC zuzuordnen reicht nicht (#493).

PV-Überschussbetrieb (abgeleitete Diagnose)

Die Navigator-Regler legen kein internes Statusregister „PV-Überschussladen aktiv“ offen — der gesamte PV-Block (74–88) besteht aus GLT-Messeingängen, die ein externer Energiemanager beschreibt. Die Integration stellt deshalb den abgeleiteten diagnostischen Binärsensor PV-Überschussbetrieb (calculated_pv_surplus_operation, Issue #353) bereit. Er ist on, wenn beide Hälften des Zustands zutreffen:

1. Dem Regler wird aktuell Überschuss signalisiert: pv_surplus (Register 74) ≥ 0,05 kW oder das SG-Ready-Signal smart_grid_status (Register 90) meldet Supergreen.
2. Die Wärmepumpe zieht tatsächlich elektrische Leistung: power_consumption_hp (Register 4122) ≥ 0,05 kW, mit Rückfall auf hp_operating_mode (Register 1090) ≠ Aus bei Anlagen ohne die Nav-10-Leistungsmessung.

Die Entität wird nur erzeugt, wenn an der erkannten Anlage mindestens eine Quelle pro Hälfte existiert; Schwellenwerte und die aktuell aktiven Quellen werden als Attribute offengelegt. Hinweis für Anlagen, bei denen der Überschuss hinter dem Abzweig der Wärmepumpe gemessen wird: pv_surplus fällt gegen null, solange die Wärmepumpe den Überschuss aufnimmt, mit dem sie versorgt wird — dort bleibt das SG-Ready-Signal (oder pv_production) der verlässliche Indikator, und die SG-Ready-Quelle hält die Diagnose aussagekräftig.

Solarthermie

Diese Entitäten existieren nur, solange die Option Solaranlage aktiviert ist (Standard). Anlagen ohne Kollektoren können die Option in den Einstellungen der Integration abschalten: Die Solarregister verlassen die Abfrage, und die leere Gerätegruppe Solaranlage verschwindet nach einem Neuladen. Erneutes Aktivieren stellt die Entitäten mit ihren bisherigen IDs wieder her.

Die Integration bemerkt es auch von selbst: Wenn jedes Solarregister einen ganzen Tag lang „nicht konfiguriert“ meldet, bietet ein Reparaturvorschlag an, das Modul abzuschalten (oder zu behalten, was diese Runde des Vorschlags verwirft).

ISC (Intelligent Surface Cooling)

Booster A/B (2. Wärmeerzeuger)

Kaskade (mehrere Wärmepumpen)

Heizkreis-Sensoren (pro Heizkreis A–G)

Berechnete Sensoren

Diese Sensoren werden aus Registerwerten desselben Schnappschusses abgeleitet. Nichts wird geschätzt: Jeder Operand ist ein dekodierter Registerwert, und der Sensor meldet lieber gar keinen Wert als eine Vermutung, wenn seine Quellen nicht aussagekräftig sind.

Die Vorlauf-Abweichung je Heizkreis vergleicht die gemessene Vorlauftemperatur eines Heizkreises (hc_{x}_flow_temp) mit dem Vorlauf-Sollwert, den der Regler für diesen Heizkreis aktuell anfordert (hc_{x}_setpoint_flow_temp):

• Positiv — der Heizkreis läuft über dem angeforderten Sollwert (Zuvielregelung, typischerweise eine zu hoch eingestellte Heizkurve oder ein Mischer, der zu weit öffnet).
• Um null — der Heizkreis folgt seiner Heizkurve.
• Negativ — der Heizkreis erreicht seinen Sollwert nicht (unterdimensionierte Wärmequelle, hohe Last, Abtauen oder eine begrenzende Einstellung).

Der Sensor wird nicht verfügbar, während der Heizkreis ruht (der Regler meldet 0.0), und bei nicht konfigurierten Heizkreisen (-1.0). Das ist beabsichtigt: Eine Abweichung, die aus einem Platzhalterwert berechnet würde, wäre bedeutungslos. Die Entität selbst wird erzeugt, sobald beide Register existieren, sodass ein Home-Assistant-Neustart im Standby sie nicht verschwinden lässt.

Die Vorlauf-Abweichung der Wärmepumpe (calculated_hp_flow_deviation) vergleicht den Vorlauf der Wärmepumpe selbst (hp_flow_temp, Register 1050) mit dem höchsten Kreis-Sollwert, der aktuell Vorlauf anfordert. Ein Register für einen Wärmepumpen-Sollwert existiert nicht (gegen die komplette Navigator-10-Registerkarte verifiziert), deshalb wird der angeforderte Wert aus den aktiven Kreis-Sollwerten abgeleitet — ruhende Kreise mit 0.0 und nicht konfigurierte Kreise mit -1.0 bleiben außen vor. Der Sensor meldet ausschließlich im reinen Heizbetrieb (Register 1090): Während einer Warmwasser-Ladung steigt der Wärmepumpen-Vorlauf auf Ladetemperatur, während die Kreis-Sollwerte ihren Kurvenwerten folgen — diese Differenz als „Abweichung" zu melden wäre irreführend; dasselbe gilt für Kühlen, Abtauen, Standby und Kombinationen, die stattdessen gar keinen Wert melden. Feldbelege: Sonde vom 2026-10-20 auf der Referenzanlage, siehe docs/dev/open-work-audit.md.

Optionale Web-Supplement-Sensoren

Wenn Web-Supplement-Daten aktiviert sind und eine lokale Navigator-Web-PIN konfiguriert ist, ergänzt die Integration schreibgeschützte Diagnosesensoren aus der lokalen Web-API. Diese Sensoren sind rein ergänzend; die Modbus-Entitäten bleiben die primäre Datenquelle.

Typische reine Web-Sensoren sind unter anderem:

Das Wärmepumpenmodell ist bewusst keine eigene Entität: Die Navigator-10- Firmware 20.24-1580 (ab 29.09.2026 installiert) hat die Modell-Zeile aus der Sensor-Seite entfernt, und kein anderes zugängliches Web-Frame meldet das Modell — live am Regler verifiziert; eine Entität würde auf aktueller Firmware dauerhaft nicht verfügbar sein. Wo eine Firmware die Zeile noch liefert (Navigator-2.0-Web, ältere Navigator-10-Firmware), erscheint der Wert als heatpump_model-Attribut am Sensor Navigator-Version (Web).

Anforderungsgrund aus der Weboberfläche (nur Navigator 10)

Die Navigator-Regler legen über Modbus kein internes Statusregister für den PV-Modus offen, aber die Weboberfläche des Navigator 10 rendert den „Anforderungsgrund“ der Anzeige — einschließlich PV — aus einer Bitmaske im WebSocket-Frame home/detail. Ist das Web-Supplement auf einem Navigator 10 aktiv, wertet die Integration diesen Frame bei jeder Web-Abfrage aus und stellt bereit:

• Anforderungsgrund (Web) (web_demand_reason): der lesbare Anforderungsgrund, formuliert wie die Anzeige des Reglers selbst — zum Beispiel PV, Heizkreis A, Zeitprogramm, Mehrere Anforderungen, Keine Anforderung oder Aus — mit den rohen operationMode/info-Werten aller beitragenden Widgets als Attribute.
• PV-Anforderungsgrund (Web) (web_demand_reason_pv): Binärsensor, der on ist, solange der Regler selbst PV als Anforderungsgrund meldet (Bit 32), sowohl in der Tabelle der Heiz- als auch der Warmwasser-Anforderungsgründe.

Dies ist das vom Gerät gemeldete Gegenstück zur abgeleiteten Diagnose calculated_pv_surplus_operation: Die Web-Entität bildet ab, was der Regler entschieden hat, die Modbus-Entität funktioniert ohne Web-PIN. Auf dem Navigator 2.0 (andere, PHP-basierte Weboberfläche) steht nur die abgeleitete Modbus-Entität zur Verfügung.

Mit aktivierter Gerätehierarchie teilen sich alle PV-Entitäten — die PV-Register (pv_surplus, pv_production, pv_target_value), smart_grid_status, die abgeleitete Diagnose und die beiden Web-Entitäten — das dedizierte Untergerät Photovoltaik statt des Hauptgeräts. | Infosystem-Meldungen (Web) | Zusammenfassung aktiver Navigator-10-Infosystem-Meldungen | | Heißgastemperatur (Web) | Reine Web-Diagnosetemperatur, wenn verfügbar | | Verdampferdruck (Web) | Reiner Web-Wert des Kältemitteldrucks, wenn verfügbar | | Platinentemperatur (Web) | Temperatur der Reglerplatine, wenn verfügbar | | Momentane/prognostizierte Leistung Heizen / Kühlen / Warmwasser (Web) | Die aktuelle oder prognostizierte thermische Leistung des Reglers für diesen Modus |

„Momentane/prognostizierte Leistung“ ist keine Live-Messung

Der Navigator bezeichnet diese drei Werte als mom./prog. Leistung Heizen, mom./prog. Leistung Kühlen und mom./prog. Leistung Vorrang — momentane bzw. prognostizierte Leistung. Sie melden, was der Regler für diesen Modus aktuell zu liefern erwartet; ein Wert ungleich null bei ausgeschaltetem Heizen oder Kühlen ist deshalb normal und kein Fehler. Ein Wert, der sich ändert, während der Verdichter ruht, ist eine Neuplanung des Reglers, kein laufender Betrieb der Wärmepumpe.

Für die tatsächliche elektrische Leistungsaufnahme verwende stattdessen Elektrische Leistungsaufnahme Wärmepumpe / current_electrical_power.

Geräteseitige Wärmemengen, Warmwasser-Detail und Regler-Uhrzeit (nur Navigator 10)

Drei weitere read-only-WebSocket-Controller werden bei jedem Web-Poll ausgewertet (live verifiziert auf Firmware jsonVersion 11, September 2026):

• Wärmemenge Heizen/Warmwasser gesamt und heute (Web) (web_heat_quantity_heating_total, web_heat_quantity_hotwater_total, web_heat_quantity_heating_today, web_heat_quantity_hotwater_today): der statistic/detail-Wärmemengenblock des Reglers — die Gesamtwerte und die Werte des heutigen Tages in kWh. Sie sind ein unabhängiger Gegencheck für die eigenen Energiestatistiken der Integration und funktionieren ohne jeden Modbus-Zugriff.
• Warmwasser-Zirkulation (Web) (web_dhw_circulation_active): Binärsensor der Warmwasser-Zirkulationspumpe aus dem Frame system.freshwater/overview — ein Zustand, den die Modbus-Map nicht bereitstellt.
• Warmwasser Statusinfo (Web) (web_dhw_status_info): die numerische Statusinformation des Freshwater-Blocks, Diagnose-Kategorie.
• Regler-Uhrzeit (Web) (web_controller_clock): die eigene Uhr des Reglers als Zeitstempel-Sensor, mit jsonVersion, aktiver Benutzerebene, Sprache, Meldungsanzahl, Frostschutz-Flag und Netzwerk-Flag als Attribute. Die Regler-Uhr kann driften — dieser Sensor macht den Drift sichtbar.

Verbindungsstatus

Diagnostische Entitäten machen die tatsächliche Verbindung auf dem Dashboard sichtbar — sie existieren in jedem Verbindungsmodus, ein Fallback fällt so sofort ins Auge:

• Verbindungsmodus (connection_mode): welche Transporte gerade tatsächlich leben — Modbus + Web, Modbus only oder Web only. Die Web-Hälfte folgt dem letzten Web-Abruf (ein Supplement, das nicht mehr antwortet, kippt den Zustand auf Modbus only und bei Erholung zurück). Die Attribute führen den konfigurierten Modus (die Option connection_mode unter Konfigurieren → Modbus-Sektion, Standard auto) und die erkannte Web-Variante (nav10 oder nav20). Jeder Transportwechsel wird zusätzlich als INFO-Zeile ins Log geschrieben (IDM connection state changed: …), damit Support-Fälle die Frage „seit wann antwortet der Web-Pfad nicht" beantworten können — ohne Log-Spam.
• Verbindung neu laden (connection_reload, diagnostischer Button): Ein Tipp lädt den Konfigurationseintrag der Integration neu. Für die Momente, in denen Home Assistant sonst auf seinen Setup-Wiederholungs- Backoff wartet — nach einem Aus der Wärmepumpe startet der Tipp Erkennung, Abfrage und Web-Supplement sofort neu und räumt damit auch die „Nicht erreichbar"-Reparaturkarte weg. Dasselbe erreicht man über Reparaturen → Erneut versuchen oder ein manuelles Neuladen; der Button legt es einfach aufs Dashboard.
• Letzte Web-Aktualisierung (Web) (web_last_success): wann die lokale Weboberfläche zuletzt erfolgreich geantwortet hat — das Web-Gegenstück zur Modbus-Letzter Erfolg-Diagnose, immer vorhanden, wenn ein Web-PIN konfiguriert ist.

System-Controller (nur Navigator 10)

Vier nur lesende WebSocket-Controller, die das mitgelieferte Frontend für seine Leistungsseite, Wetterkachel, den iON-Status und das Energiefluss-Widget nutzt, sind Teil des Web-Supplements (idm-heatpump-api 2.12.0 oder neuer). Sie sind additiv — die Frames werden mit dem regulären Web-Poll gelesen, und jede Entität meldet unavailable, bis ihr Frame angekommen ist:

• Wärmepumpen-Verbrauchsleistung (Web) (web_hp_power_consumption): die momentane elektrische Verbrauchsleistung in kW, mit Leistungsmodus, Betriebsart, Messquelle, Batterie-Flag und der Produktions-Vorlauftemperatur als Attribute.
• Wärmepumpen-Umgebungsleistung (Web) (web_hp_power_environment): die leistungsseitige Quellenleistung in kW, mit der Quellen-Messquelle und der Quellen-Eintrittstemperatur als Attribute.
• Heizstab (Web) (web_hp_heating_rod): Binärsensor für den Heizstab- Zustand der Leistungsseite.
• Netzleistung (Web) (web_energyflow_grid) und PV-Leistung (Web) (web_energyflow_pv): Netz- und PV-Leistung des Energiefluss-Widgets in kW — beim aktivierten Geräte-Hierarchie-Modus auf dem PV-Subgerät. Die Firmware T_NAV10_20.24-1580 hat den house-Kanal aus dem Frame entfernt; liefern ältere Firmware-Versionen ihn noch, steht er als Attribut bereit.
• Wettervorhersage (Web) (web_weather_forecast): die eigene Vorhersage des Reglers, die er über den myiDM-Dienst bezieht — die heutige Temperatur als Zustand, heute plus bis zu sechs Prognosetage (Temperatur min/max/ist, Bewölkung, Regenwahrscheinlichkeit, Sonnenminuten, Wettersymbol, Wind) als Attribute.
• iON-Optimierung aktiv (Web) (web_ion_active): diagnostischer Binärsensor für IDMs Cloud-Energioptimierung, mit aktivierter Einstellung und Abo-Status als Attribute.

Web-only-Steuerung (Navigator 10, Phase 4)

Ein Nur-Web-Eintrag ist nicht mehr rein lesend: Mit verbundener WebSocket-Variante erhält er zwei Steuerelemente, die über die lokale Web-Oberfläche schreiben — jeder andere Verbindungsmodus schreibt weiterhin genauso wie bisher über Modbus:

• Betriebsart (Web) (web_system_mode): Auswahleinheit für die Betriebsart. Sie liest den aktuellen Modus und die vom Regler selbst vorgegebenen wählbaren Werte aus der home/overview-Kachel und schreibt über home/save — dieselbe Numerierung wie das Modbus-Register system_mode, vor dem Senden validiert. Ein abgelehnter Schreibvorgang meldet einen Fehler, statt still zu scheitern.
• Fehler quittieren (Web) (web_acknowledge_errors): der Quittieren-Knopf, schreibt notification/save.
• Warmwasser-Solltemperatur (Web) (web_dhw_setpoint): die Warmwasser-Solltemperatur als Zahl-Entität. Grenzen, Schrittweite und der aktuelle Wert stammen aus der vom Gerät selbst deklarierten Parameterdefinition, und jeder Schreibvorgang wird vor dem Senden gegen genau diese Grenzen validiert — dieselbe Schreibsicherheit wie im Register-Pfad.
• Heizkreis X (Web) Climate-Karte je Heizkreis (Raumtemperatur, Solltemperatur, Betriebsart; HVACAction aus dem Pumpenstatus) und die Warmwasser (Web) Water-Heater-Karte (Speichertemperatur oben + Sollwert) — dieselben validierten Web-Schreibvorgänge, als Standard- Home-Assistant-Karten.
• Heizkreis X Raumsolltemperatur (Web) / Heizkreis X Betriebsart (Web) (je konfiguriertem Heizkreis): die normale Raumsolltemperatur (Parameter HK<x>04) als Zahl und die Heizkreis-Betriebsart (Parameter HK<x>01) als Auswahl, mit den vom Gerät selbst deklarierten Grenzen bzw. Optionen. Ein system.heatingcircuit/detail-Rahmen je Heizkreis liefert zusätzlich Raumtemperatur und Pumpenstatus. Der einmalige Warmwasser-Boost bleibt bewusst vom Web-Pfad fern: Diese Firmware bietet ihn nur als Wochen-Zeitplan an, und das Schreiben ganzer Zeitplan-Zeichenketten ist ausgeschlossen.

Die Dienste set_system_mode und acknowledge_errors nutzen für Nur-Web-Einträge automatisch denselben Web-Pfad. Schreibvorgänge verwenden die autorisierte Web-Sitzung des Abfragezyklus und lesen den Zustand nach jedem Schreiben zurück, wie die offizielle Web-Oberfläche. Sollwerte und weitere Steuermöglichkeiten erfordern weiterhin Modbus.

Auf dem Navigator 2.0 liefern die Statistik-Seiten dieselbe Form aus der älteren Weboberfläche: Sensoren Laufzeit / Wärmemenge / elektrische Energie, gesamt je Kategorie (Web 2.0) — Stunden für Laufzeiten, kWh für die Energiemengen, normalisiert mit der Einheitenskala der Seite selbst.

Antwortet eine Firmware auf einen dieser Controller nicht, bleiben die betroffenen Entitäten einfach nicht verfügbar; der Rest der Web-Snapshots ist unbeeinflusst.

Dupliziert ein Webwert eine bestehende Modbus-Entität, wird die Web-Entität übersprungen. Das verhindert doppelte Dashboard-Werte und hält Modbus als maßgebliche Quelle für registergestützte Daten.

Verfügbar sind nur Werte, die der aktuelle lokale Web-Schnappschuss zurückliefert. Optionale Navigator-10-Infosystem-Meldungen werden unabhängig gelesen; schlägt diese optionale Anfrage fehl, bleiben die anderen gültigen Webwerte verfügbar. Siehe Lokale Navigator-Weboberfläche für Details zum Protokoll und zum reinen Web-Betrieb.

Interner Meldungs-Sensor

Der Diagnosesensor internal_message gibt die aktive IDM-interne Meldung als lesbaren Text aus, zum Beispiel einen Code plus Meldungsbeschreibung. Er stellt zusätzlich die strukturierten Attribute message_code und message_text bereit, sodass Automationen sowohl auf den numerischen Code als auch auf die lesbare Beschreibung reagieren können.

Binärsensoren

Navigator 1.0/1.7 — Momentary-Coils (c3000/c3003)

Der 1.x-Coil-Block (ma_de_812049 Rev.1) besteht aus momentanen Kommandobits, keinen Statussignalen: Der Regler führt eine Anforderung aus, sobald das Bit gesetzt ist, und das Bit fällt sofort auf 0 zurück (auf realer 1.7-Hardware bestätigt, Issue #319). Die Coils tragen deshalb keine Zustands-Entitäten:

• c3003 — Anforderung Vorrangladung trägt den Button Vorrangladung anfordern (siehe Abschnitt Button): ein einzelner Single-Coil-Write von ON (Function Code 05), der 1.x-Warmwasser-Boost. Ein Switch wird bewusst nicht angeboten — ein Switch würde auch OFF schreiben, was ein momentanes Kommandobit niemals erhalten darf.
• c3000 — Störung quittieren trägt den Störung quittieren-Button (siehe Dienste), auf der 1.x-Familie ein Single-Coil-Write (Function Code 05) und auf der gemeinsamen Navigator-2.0/10-Familie ein Holding-Register-Write.
• c3001/c3002 — Anforderung Heizen/Kühlen werden nicht exponiert: Heizen oder Kühlen anfordern ist Aufgabe der Betriebsart-Selects.

Zahl-Entitäten (schreibbar)

Warmwasser

Heizkreis (pro Heizkreis)

Als Experte markierte Einträge formen die Heizkurve der gesamten Anlage und schreiben in EEPROM-Register. Sie werden bei neuen Installationen deaktiviert erzeugt — aktiviere sie unter Einstellungen -> Geräte & Dienste -> IDM Heatpump -> Entitäten. Bestehende Installationen behalten den Zustand, den die Entität bereits hatte. hc_{x}_setpoint_flow_constant und hc_{x}_setpoint_flow_cooling sind aus demselben Grund Experte-Entitäten.

hc_{x}_ext_room_temp lässt sich manuell wie jede andere Zahl-Entität steuern oder wird automatisch durch die optionale Raumtemperatur-Weiterleitung gefüllt. Ist die Weiterleitung aktiviert, werden ausgewählte Home-Assistant-Temperatursensoren bei Zustandsänderungen und periodisch (Standardintervall: 300 Sekunden) in diese externen Raumtemperatur-Register geschrieben.

GLT / externe Steuerung

Leistungsgrenzen

Diese Register sind modellabhängig und standardmäßig deaktiviert. Verwende sie nicht für gesetzliche oder vertragliche Laststeuerung, bevor das Verhalten für deine genaue Hardware und Firmware verifiziert ist.

Auswahl-Entitäten

Schalter-Entitäten

Klima-Entitäten

Klima-Entitäten kombinieren eine Modusauswahl und eine Zieltemperatur in der Standard-Thermostatkarte von Home Assistant. Zwei Typen werden erstellt:

Heizkreis-Klima-Entität (climate.hc_x)

Je eine pro konfiguriertem Heizkreis (A–G). Steuert den Betriebsmodus des Heizkreises und seine normale (Tag-)Raum-Solltemperatur.

Zonenraum-Klima-Entität (climate.zm{z}_room{r})

Je eine pro konfiguriertem Raum in jedem Zonenmodul. Steuert den Betriebsmodus des Raums und seinen Temperatur-Sollwert.

Schreibvorgänge laufen über den zentralen Schreibpfad des Koordinators mit optimistischen Updates und übersetzten Fehlermeldungen.

Warmwasserbereiter

Eine einzige Warmwasserbereiter-Entität (water_heater.idm_heatpump) stellt die Steuerung der Warmwasser-Zieltemperatur mit Rückmeldung der Ist-Temperatur bereit. Sie wird erzeugt, wenn das Zielregister (dhw_setpoint) und ein Warmwasser-Temperaturregister existieren — die gemeinsame Familie meldet dhw_temp_top, die Navigator-1.0/1.7-Karte bietet stattdessen dhw_temp (Trinkwassererwärmertemperatur, Adresse 1012).

Nutzt denselben Schreibpfad des Koordinators wie die Klima-Entitäten.

Button

Buttons sind Einmal-Aktionen. Welche Buttons existieren, hängt vom Navigator-Modell, vom Funktionsprofil und vom Verbindungsmodus ab:

In einem Web-only-Eintrag am Navigator 10 ergänzt das Web-Supplement einen eigenen Quittieren-Button mit demselben Namen, der über die Weboberfläche statt über Modbus arbeitet. Die Modbus-Buttons werden im Web-only-Modus nicht erstellt.

Der Hauptbutton (button.idm_heatpump_acknowledge_errors) quittiert aktive Fehler an der Wärmepumpe, indem er 1 in das Nur-Schreib-Register error_acknowledge schreibt. Er ist immer verfügbar, damit Automationen auf Änderungen des Alarmzustands reagieren können.

Bei erkanntem Navigator 1.0/1.7 kommt ein zweiter Button hinzu (button.idm_heatpump_request_dhw_priority_charge, Vorrangladung anfordern): Er fordert eine Warmwasser-Vorrangladung an — ein einzelner FC05-Write von ON auf Coil c3003. Nur für manuelle Nutzung — die offizielle Tabelle stellt den Coil-Block unter den EEPROM-Hinweis, also kein Zeitplan und keine getaktete Automation.

Auf mindestens einer 1.x-Firmware endet die per Coil angeforderte Vorrangladung nicht von selbst: Der Regler bleibt im Warmwassermodus, bis der Fehler 020 (Wärmepumpenvorlauf Maximaltemperatur) auslöst (Issue #319). Verhält sich deine Anlage so, nutze stattdessen die Betriebsart Warmwasser einmalig (der system_mode-Select oder der Warmwasser-Boost) — dieser Weg beendet die Ladung auf der betroffenen Hardware normal. Auf verifizierter Firmware fällt der Coil unmittelbar nach dem Schreiben auf 0 zurück, deshalb schreibt der Button niemals OFF; melde das Verhalten deiner Firmware gerne im Issue.

Entitäten der optionalen Funktionen

Die optionalen Funktionspakete ergänzen die folgenden Entitäten. Die Tabellen listen jede Entität, die jedes Paket erzeugen kann, mit dem exakten Namen, den Home Assistant in einer deutschen Installation zeigt (englische Installationen zeigen die englischen Namen aus den Übersetzungsdateien). Entitäten einer deaktivierten Funktion werden aus der Registry entfernt; beim erneuten Aktivieren werden dieselben Entitäts-IDs wiederhergestellt.

Betriebsanalyse (Smart-Profil)

Abgeleitet aus beobachteten Verdichter-, Abtau- und Betriebsart-Übergängen. Restart-sicher: Die Zähler überleben Home-Assistant-Neustarts, und Kommunikationslücken werden nie als Betriebsereignisse gewertet.

Energiestatistik (Smart-Profil)

Persistente Summen, berechnet aus den Leistungsregistern und pro Konfigurationseintrag gespeichert — Tag, Monat und Lebenszeit. Sie überstehen Neustarts; die Registerzähler des Geräts (Wärmemenge Heizen, Wärmemenge Warmwasser, …) sind eigene Entitäten unter Energie & Leistung. Kosten und CO₂ nutzen die optionalen Preis- und Emissionsfaktoren aus dem Smart-Profil.

Health Monitor (Smart-Profil-Option)

Schreibgeschützte Problemprüfungen plus ein kombinierter Bericht. Jede Prüfung ist ein Binärsensor, der an wird, wenn ihr Kriterium erfüllt ist; der Bericht bündelt die Befunde als Attribute.

Komfortberatung (Smart-Profil-Optionen)

Schreibgeschützte Empfehlungen, je eine Entität:

Die Heizkurven-Entität wird für den im Komfort-Zeitplan ausgewählten Heizkreis erzeugt; die Wetter-Entität erfordert eine konfigurierte Wetter-Integration.

Predictive Advisor (Smart-Profil-Option)

Strikt schreibgeschütztes Empfehlungs-Framework — der Advisor schreibt niemals auf die Wärmepumpe. Siehe Predictive Advisor für Schwellwerte, Beobachtungsstufen und das idm_advisor_recommendation-Ereignis.

KI-Anlagenberater (experimentell, standardmäßig aus)

Deterministische Berichte aus Messwerten mit optionalen freien Erklärungen über lokales Ollama, eine HA-AI-Task-Entität oder ausdrücklich genehmigte Cloud-Anfragen. Siehe Experimenteller KI-Berater und Lokales Ollama für die Datenschutzgrenze.

Die vier Buttons stehen auch unter Button. Bei deaktivierter Gerätehierarchie ziehen die KI-Entitäten trotzdem auf ihr eigenes Gerät iDM KI-Anlagenberater um — die KI-Gruppe ist das einzige Untergerät, das unabhängig von der Hierarchie-Option existiert.

Assist-Agent (immer aktiv)

Eine lokale, deterministische Konversations-Entität. Sie beantwortet Fragen in natürlicher Sprache zur laufenden Anlage — warum die Wärmepumpe läuft, Advisor-Empfehlungen, Temperaturen, Warmwasser, Verbrauch/COP und Status — auf Deutsch oder Englisch. Alles wird aus dem lokalen Coordinator-Snapshot per Keyword-Routing berechnet; keine Anfrage verlässt die Instanz, kein Sprachmodell ist beteiligt. Siehe Konfiguration → Assist.

Gerätegruppen (Gerätehierarchie)

Mit aktivierter Gerätehierarchie (Konfigurieren → Funktionen) verteilt die Integration ihre Entitäten auf Untergeräte, damit das Hauptgerät der Wärmepumpe beim Regler bleibt. Diese Gruppen sind Child-Devices der Wärmepumpe; ein Upgrade von einer älteren Integrationsversion konvertiert die vorher über via_device verknüpften Geräte an Ort und Stelle und behält ihre Geräte-IDs. Zonenmodule bleiben gewöhnliche verknüpfte Geräte — eigene Hardware, kein logischer Teil — und ihre Räume sind Kinder des Moduls.

Die Entitäten des Predictive Advisor (advisor_*) bleiben bewusst auf dem Hauptgerät der Wärmepumpe: Sie beschreiben die Anlage als Ganzes, nicht ein entfernbares Modul. Wird die Hierarchie deaktiviert, wandert jede Gruppe zurück auf das Hauptgerät (außer der KI-Gruppe); die Entitäts-IDs ändern sich dabei nie.

Zonenmodule

Für jedes aktivierte Zonenmodul (bis zu 10) werden Entitäten auf Raumebene erstellt:

Zusätzlich pro Zone: zm{z}_mode_heat_cool, zm{z}_dehumidification

Differenztemperaturgeregelte Heizkreise

Ist ein Navigator-10-Heizkreis als Differenztemperaturgeregelt eingerichtet, wähle ihn unter Konfigurieren → Anlage → Differenztemperaturgeregelte Heizkreise und zusätzlich in der Liste installierter Heizkreise aus. Im erweiterten Formular steht die Auswahl neben Heizkreise. Standardmäßig ist sie leer; normale Heizkreise behalten ihr Verhalten. Die manuelle Auswahl ist maßgeblich und unabhängig vom separaten Modul für die interne Differenztemperaturregelung; mit konfiguriertem Web-PIN werden Kreise dieses Typs am Navigator 10 zusätzlich automatisch über die lokale Webschnittstelle erkannt.

Die in Issue #429 gemeldeten Messwerte für HK D werden folgendermaßen zugeordnet. Andere ausgewählte Kreise verwenden die entsprechenden Register der Bibliothek:

Die Temperaturdifferenz steht in jedem Funktionsprofil zur Verfügung. Fehlende, nicht unterstützte oder ungültige Messwerte ergeben keine nutzbare Differenz. Der Status ersetzt keine Pumpenmessung; aus der Differenz wird kein Ladezustand abgeleitet.

Umstellung: Speicher- und Referenzsensor behalten ihre bisherigen Unique-IDs und Entity-IDs (hc_d_flow_temp / hc_d_room_temp). Nur ihre Standardnamen ändern sich; selbst vergebene Namen bleiben bestehen. Automationen mit diesen IDs funktionieren weiter. Normale Heizkreis-Sollwerte, Heizkurve, Heiz-/Kühlgrenzen, externe Raumtemperaturvorgaben, Climate-Entitäten, Vorlaufabweichung und Web-Mischer-/Vorlaufsensoren werden für ausgewählte Differenzkreise aus der Registry entfernt. Passe betroffene Dashboards und Automationen an. Beim Abwählen entstehen normale Heizkreis-Entitäten erneut; der Differenzsensor entfällt. Anpassungen entfernter Regler bleiben nicht erhalten.

Entity-IDs: Das Gerät des Kreises heißt Heizkreis D und trägt den Typ als Modell (Differential temperature control), denn Home Assistant stellt jeder neuen Entity-ID eines Geräts den Namens-Slug voran — ein Typ-Suffix im Namen verdoppelte die Länge aller IDs. Entity-IDs, die registriert wurden, solange der Gerätename noch mit (Differenztemperaturgeregelt) endete (0.20.1-b1…b4), werden beim nächsten Start automatisch gekürzt: sensor.heizkreis_d_differenztemperaturgeregelt_temperaturdifferenz_hk_d wird zu sensor.heizkreis_d_temperaturdifferenz_hk_d. Passe Dashboards an, die mit den langen Vorab-IDs erstellt wurden; selbst umbenannte Entity-IDs und kurz vergebene IDs, die bereits einem anderen Objekt gehören, bleiben unangetastet.

Unbestätigte Parameter: Die API enthält keine bestätigten Register zur Heizkreistyp-Erkennung oder für Hysterese, Schwellwert und Maximaltemperatur dieses Typs. Der gemeldete Wert 60 °C bei hc_d_setpoint_flow_constant (1452) belegt nicht dessen Bedeutung als Schwellwert. Diese Parameter werden daher nicht unter vermuteten Namen angezeigt. Es kommen keine neuen Schreibzugriffe hinzu. Die Zuordnung basiert auf dem Navigator-10-Bericht in #429 und muss noch an der Anlage des Melders bestätigt werden.

Unabhängige Firmware-Beobachtungen

Unter Neu konfigurieren → Firmware-Abfrage aktiviert ein eigener freiwilliger Schalter den Sensor Neueste gemeldete Firmware. Er ist standardmäßig aus und übernimmt keine Telemetrie-Einwilligung. Die Firmware-Abfrage funktioniert ohne myIDM-ID und ohne Telemetrie. Telemetrie auszuschalten beendet eine separat freigegebene Firmware-Abfrage nicht. Ausschalten der Firmware-Abfrage bricht laufende Anfragen ab und entfernt Sensor und Registry-Eintrag sofort. Ohne diese Einwilligung gibt es keinen Kontakt zum Firmware-Katalog.

Übertragen werden ausschließlich Navigator-Familie, Regler-/Anlagenmodell und installierte Firmware, nach bis zu 30 Minuten zufälliger Startverzögerung, danach alle sechs Stunden zuzüglich bis zu 30 Minuten zufälliger Verzögerung. Keine myIDM-ID, Betriebszähler, Temperaturen, Zugangsdaten oder fremden HA-Daten. Es gibt keine dauerhafte Firmware-Warteschlange; die Integration hält nur das aktuelle Ergebnis. HA kann Sensorzustände gemäß deiner Recorder-/Backup-Konfiguration speichern. Der Server verarbeitet die Abfrage vorübergehend und speichert keinen Anlagenbericht. Die Verbindungs-IP ist technisch sichtbar; kurzlebige Ratenkennungen verfallen nach spätestens zwei Stunden beim nächsten stündlichen Bereinigungslauf. Beide Funktionen verlinken vor ihrem Zustimmungsschalter deutlich auf die vollständigen Datenschutzhinweise.

Der Katalog verwendet nur freigegebene Community-Telemetrie, keine alten Diagnose-ZIPs. Navigator/Regler, bekanntes Anlagenmodell, Firmware-Präfix/Kanal und Hauptreihe müssen passen. Fehlende Anlagenmodelle werden nur mit anderen Meldungen ohne Typangabe innerhalb derselben bekannten Regler-/Firmware-Reihe verglichen. Test- und stabile Kanäle bleiben getrennt; Buildnummern werden numerisch verglichen. Unbekannte Zuordnung oder fehlende Meldungen liefern keine Versionsempfehlung.

Das ist keine offizielle IDM-Verfügbarkeit, Installationsberechtigung oder Kompatibilitätsfreigabe. Eignungsprüfung und Installation bleiben bei IDM/Fachbetrieb. Telemetrie hilft beim Aufbau des Katalogs, ist aber keine Voraussetzung für seine Abfrage. Telemetrie verwendet weiterhin Hinweisfassung v3, die unabhängige Firmware-Einwilligung idm-firmware-v1. Deren Zeitpunkt und Fassung werden nur lokal gespeichert und nicht bei der Firmware-Abfrage übertragen.

Datenschutz und Übertragung.

Bei aktivierter Gerätehierarchie liegen Zuletzt gemeldete Firmware und der Indikator für eine unbestätigte neuere Version im logischen Gerät Diagnose neben der installierten Softwareversion. Ohne Hierarchie bleiben es Diagnose-Entitäten am Anlagengerät. Unique-IDs und Entitätshistorie bleiben erhalten. Eine passende neuere Beobachtung kann einen Reparaturhinweis auslösen; die Bestätigung wird je Gerät/Version gespeichert. Siehe Aktivierung und Einordnung.