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 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.

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, Fachmann-Codes oder Web-Supplement-Daten kann zusätzliche Entitäten hinzufügen.

Entitäten werden in Home Assistant, wo möglich, nach Funktion gruppiert. Die optionalen Fachmann-Code-Sensoren stehen oben angeheftet, gefolgt von Konfigurations-Entitäten, 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.

Zugangscodes der Fachmann-Ebene

Wenn die Option in den Integrationsoptionen aktiviert ist, zeigen zwei zusätzliche Sensoren die aktuellen Zugangscodes für Fachmann Ebene 1 und Fachmann Ebene 2. Sie aktualisieren sich einmal pro Minute, stehen oben in der Entitätsliste des IDM-Geräts und sind keine Modbus-Register.

Die Option ist standardmäßig deaktiviert. Behandle die Werte als sensibel: beschränke den Zugriff auf ihre Dashboard-Karten und veröffentliche sie niemals in Screenshots, Logs oder Supportanfragen. Siehe Konfiguration für Einrichtung und Sicherheitshinweise. Die Berechnungsmethode ist bewusst nicht dokumentiert.

Systemtemperaturen & Drücke

Navigator 10 — Wärmesenke (Trennwärmetauscher)

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.

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.

Hier werden bewusst Werte innerhalb eines Heizkreises verglichen. Eine Abweichung auf Wärmepumpen-Ebene bräuchte ein eindeutiges Register für den Vorlauf-Sollwert, den die Wärmepumpe selbst anfordert, und bleibt ein offener Punkt auf der Roadmap.

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:

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.

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 — Anforderungs-Coils (c3001–c3003)

Die 1.x-Familie meldet ihren live-Anforderungsstatus über den offiziellen Coil-Block (ma_de_812049 Rev.1), gelesen mit dem Modbus-Function-Code 01. Diese Entitäten existieren nur bei erkanntem Navigator 1.0/1.7:

Der Quittierungs-Coil c3000 hat keinen Sensor: Er trägt den Störung quittieren-Button (siehe Dienste), der auf der 1.x-Familie einen Single-Coil-Write (Function Code 05) sendet und auf der gemeinsamen Navigator-2.0/10-Familie einen Holding-Register-Write.

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

Ein einzelner Button (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.

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