Stabilität & Release-Reife

Diese Seite hält fest, was verifiziert wurde, was unsicher bleibt und was gelten musste, bevor das Beta-Label entfernt wurde. Sie ist bewusst strenger als ein normales Changelog.

Release-Entscheidung zu 0.26.13

Der reichhaltigere Hinweistitel ist rein darstellerisch: Der Titel ist eine Übersetzungszeichenkette, abgesichert durch einen Platzhalter- und EN/DE-Paritätstest; kein Integrationsmodul wurde geändert, also bleiben bestehende Quittierungen, Entity-IDs und das Einwilligungsmodell unberührt. API 2.16.2 bleibt seit 0.26.12 gepinnt; das Release härtet nur die Release-Infrastruktur — der Pin-Updater deckt jetzt die Ablehnungs-Fixture des Paritätstests ab, und die datierten Pin-Vergleiche auf dieser Seite (unverändert gegenüber 0.26.1/0.26.0/0.25.0) sind in ihren veröffentlichten Fassungen restauriert und als Historien-Aussagen geschützt. Die echten HA-Lebenszyklus-Smoke-Tests bestehen gegen Home Assistant 2026.11.0; eine Live-Anlage wurde für dieses Release nicht erneut geprüft. Detailnachweis

Release-Entscheidung zu 0.26.12

Firmwarefreigabe behält bestehende Zustimmungen mit idm-firmware-v1, aktiviert keine ausgeschalteten Optionen und ändert die Telemetrie-Einstellungen nicht. Synthetische Tests prüfen vorhandene Zustimmung, die Gleichheit bei einer einzigen Versionssichtung, Komponentenangaben und unterdrückte unklare Pro-Updatehinweise. Der verschlüsselte, begrenzte Quellenindex bleibt an seine Aufbewahrung gebunden; Servertests prüfen Ablauf, alte HTTP-Clients, Neustart und veränderte Chiffrate. Vollständige Integrations-/Config-Flow-Coverage, strenge Typprüfung und echte HA-Lebenszyklustests müssen vor Veröffentlichung bestehen. Kein neuer Anlagen-Schreibzugriff, keine physische Pro-Erkennung und keine Firmwareinstallation werden zugesichert. API 2.16.2 bleibt gepinnt. Nachweis

Release-Entscheidung zu 0.26.11

Die bestätigte Antwort zu einem nicht vorhandenen Heizkreis wird von der API gezielt erkannt. Synthetische Tests prüfen Anfragezuordnung, unbekannte Antworten und den Erhalt anderer erfolgreicher Kreise. Die lokale Gesamtsuite besteht mit 3.523 Tests (zwei übersprungen), 98,58 % Integrations-Coverage und 100 % Config-Flow-Coverage. Strenge Typprüfung für 88 Module und 14 echte HA-Lebenszyklustests bestehen. CI und Release wiederholen die Prüfungen. Kein neuer physischer Anlagenlauf, kein erzwungener Fehler und keine Pro-Browseranmeldung wurden geprüft. Historien, Zustimmungen und Schreibverhalten bleiben erhalten. Der Quellstand pinnt API 2.16.2; offene Punkte stehen unter Erkenntnisse.

Release-Entscheidung zu 0.26.10

Das Telemetrie-Untergeät ist eine reine Platzierungsänderung: Auflösung, einwilligungsgesteuertes Anlegen und die Bereinigung veralteter Geräte sind unit-getestet, Entity-IDs und Historie bleiben konstruktionsgemäß erhalten (nur die Gerätezuordnung ändert sich), und die echten HA-Tests bestehen gegen Home Assistant 2026.11.0. Eine Live-Anlage mit aktivierter Hierarchie wurde nach dem Umzug nicht erneut geprüft. Das getestete Abhängigkeitspaar bleibt API 2.16.1 mit den bestehenden Transport-Floors. Detailnachweis

Release-Entscheidung zu 0.26.9

Die Transparenz der Telemetrie-Zustellung ist unit- und vertragstestgeprüft, nicht im Feld belegt: Status-Sensor, Repairs-Schwelle, 4xx/429-Trennung, Berichtskennung-Stabilität, Sperrzeit-Fehler und gemeinsamer Timer sind in der lokalen Suite gegen gestubbte Endpunkte abgedeckt; während der Entwicklung wurde keine echte Übertragung an IDM Tools durchgeführt. Übertragenes Schema, Einwilligungsfassung idm-telemetry-v3, Zeitpläne und Löschprozess bleiben unverändert. Das getestete Abhängigkeitspaar bleibt API 2.16.1 mit den bestehenden Transport-Floors; die echten HA-Lebenszyklustests bestehen gegen Home Assistant 2026.11.0. Detailnachweis

Release-Entscheidung zu 0.26.8

Der beim Start ausgelassene GLT-Lesesensor ist reproduziert und korrigiert; aktuelle Sentinel-Werte bestimmen weiterhin die Verfügbarkeit. Der echte HA-Regressionstest prüft stabile Entitäts-IDs, Rücklese-Polling der Number und Erholung beim Neuladen mit Weiterleitung aus/ein/aus. Das Flackern am Regler bleibt offen. API 2.16.1 und die Transport-Mindestversionen bleiben gleich. Zwei geprüfte private Captures zu #577 belegen keinen neuen Parserfehler und keine gesicherte Zuordnung zum ursprünglich gemeldeten Modul. Detailnachweis

Release-Entscheidung zu 0.26.7

Der Maintainer hat einen stabilen Folgepatch der 0.26-Reihe für einen Community-Feldbericht (#668) angefordert: Ein Navigator-2.0-Heizkreis ohne angeschlossenen Raumfühler antwortet auf Register 1364 mit etwa −327,22 °C uninitialisiertem Speicher und ließ die Prüfung auf unplausible Werte dauerhaft ansprechen — derselbe Sentinel, den der Advisor seit #504 als fehlend behandelt. Die Korrektur stuft Werte ≤ −300 °C als Fühler nicht vorhanden ein, einheitlich für Gesundheitsprüfung, Sensor-Verfügbarkeit und Klima-/Boiler-Veröffentlichung; die Dekodierung bleibt unverändert, wirklich unplausible Werte lösen weiterhin aus. Die Band-Regel publiziert die gepinnte API 2.16.1 (is_uninitialized_temperature) und wird als einzige Regel importiert. Regressionstests decken Gesundheitsprüfung, Entitäts-Verfügbarkeit mit und ohne Rohwertmodus, die Begrenzung auf Temperatur-Register sowie Klima-/Boiler-Veröffentlichung ab; die lokale Suite bestand vollständig (3492 Tests, 98,64 % Abdeckung), der Config Flow erreichte 100 %, die strenge Typprüfung und 13 echte HA-Lebenszyklustests gegen Home Assistant 2026.11.0 bestanden. Eine Anlage mit Fühler wurde nicht erneut im Feld getestet; eine frische Hardwareinstallation aus dem veröffentlichten ZIP ist nicht erfolgt. Detaillierte Nachweise.

Release-Entscheidung zu 0.26.6

Der Maintainer hat nach einem autorisierten Navigator-10-Live-Test einen stabilen Patch der 0.26-Reihe mit standardmäßig ausgeschaltetem Workaround angefordert: Wiederholt erfolgreiche Nullwert-Schreibvorgänge bestanden gleichzeitig mit Meldung 20300; ein 60-Sekunden-Test mit 0,01 kW Produktion ließ sie nach etwa 20 Sekunden ohne Quittierung verschwinden. Das belegt eine Anlage/Firmware, keine allgemeine Watchdog- oder Firmwarediagnose. Laufzeitabhängigkeiten und HA-Mindestversion bleiben unverändert. Regressionstests prüfen exakte Nullwerte, ungültige Quellen, positive Produktion und unveränderte Hausverbrauchs-/Überschussberechnungen über Einrichtung, Optionen und Neukonfiguration. Vor der reinen Release-Metadatenpflege bestanden lokal 3463 Tests mit 98,64 % Abdeckung, der Config Flow erreichte 100 %, die strenge Typprüfung und 13 echte HA-Lebenszyklustests bestanden. Der stabile Folgepatch wird bewusst ohne siebentägigen unveränderten Dauertest veröffentlicht; eine frische Hardwareinstallation aus dem veröffentlichten ZIP ist nicht durchgeführt. Detaillierte Feldnachweise.

Release-Entscheidung zu 0.26.5

Regressionstests prüfen beide Firmware-Präfixe, falsche Präfixe und die gemeinsame Zuordnung der Firmware-Entitäten zu Diagnose. Bestehende IDs und Zustimmungen bleiben erhalten. Eine Schnittstelle allein beweist kein Reglermodell; widersprüchliche oder fehlende Metadaten müssen als unbestimmt behandelt werden.

Release-Entscheidung zu 0.26.4

Ein Regressionstest reproduziert einen neueren Analyse-Speicherstand ohne passende Telemetrie-Beobachtungszeit. Die Korrektur setzt das gespeicherte Zähler-/Zeitpaar gemeinsam fort, erhält eingefrorene Wiederholungen und lässt alte Betriebszeitfenster einmalig aus. Typprüfung, Regressionstests und echte Home-Assistant-Lebenszyklustests bestehen; CI prüft die vollständigen Release-Kriterien. Serverprüfungen verwenden synthetische Daten und verändern Originale nicht. Flottenweite Leistung oder der genaue Verlauf älterer Aggregate sind damit nicht belegt.

Release-Entscheidung zu 0.26.3

0.26.3 ergänzt freiwillige, standardmäßig ausgeschaltete Anlagenmeldungen und eine unabhängig zustimmungspflichtige Firmware-Abfrage. Der vorhandene lokale Betrieb bleibt unabhängig. Neustartfeste Meldungen und verteilte Versandzeiten sind getestet; die einmalige Bereinigung entfernt nur historische Technikercode-IDs derselben Integration. Typprüfung, gezielte Tests und reale HA-Lebenszyklustests bestehen. Der Server verwendet ein unabhängiges Löschjournal in LXC 117. Mehrtägiger Betrieb und eine rechtliche Einzelfallprüfung werden durch diese technischen Prüfungen nicht ersetzt.

Release-Entscheidung zu 0.26.2

0.26.2 ist ein stabiler Feature-Patch mit fünf neuen UI-Sprachen. Home Assistant legt translations/<lang>.json über translations/en.json, daher liefern die fünf neuen Dateien genau die sichtbare UI-Fläche — Config- und Options-Flow-Schritte, Fehler, Abbrüche, Dienste, Issues/Reparaturen, Selektoren und Exceptions, je 419 Strings — während Entitätsnamen auf Englisch zurückfallen. Ein neuer parametrisierter Parity-Test bewacht jede Datei: keine Waisen-Keys, keine leeren Werte, und jeder {Platzhalter} der englischen Quelle muss die Übersetzung überleben — eine schlechte Übersetzung kann keinen Bildschirm brechen. Die fünf Übersetzungen entstanden in einem Durchgang und sind noch nicht muttersprachlich gegengelesen; Feldkorrekturen sind willkommen und können als Patch-Releases erscheinen. Die Installateur-Checkliste (EN+DE im Wiki, fünf druckbare Übersetzungen unter docs/examples/) dokumentiert den Freischaltweg über die Installateur-Ebene, und die Dokumentations-Startseite leitet deutsche Browser nur einmal pro Sitzung weiter (der explizite Umschalter bleibt verfügbar). Vollständige Qualitätschranke auf dem Schnitt: zweibeinige CI-Matrix mit Coverage-Schranken, strenges mypy, ruff, hassfest, Real-Home-Assistant-Lebenszyklus-Smoke-Tests, CodeQL/pip-audit, Anmeldedaten-Scan. Runtime-Pins unverändert gegenüber 0.26.1 (idm-heatpump-api[web]==2.16.1).

Release-Entscheidung zu 0.26.1

0.26.1 ist ein schneller stabiler Patch auf der 0.26.0-Linie mit genau einer Änderung: Das Feature der Fachmann-Zugangscodes ist aus Sicherheitsgründen entfernt (Berechnungsmodul, beide Sensor-Entitäten, die Option Fachmann-Ebene, Tests und Dokumentation). Die Installer-Codes des Reglers zu berechnen und als Sensoren bereitzustellen verkürzte eine Zugriffsebene, die iDM geschulten Installateuren vorbehält — im Widerspruch zu den eigenen Schreibsicherheitsregeln des Projekts und der Community-Norm, Installateur-Funktionen nie zu entsperren. Jeder Wiki-Schritt, der Nutzer bisher zur Anmeldung auf dieser Ebene aufforderte, besagt nun, dass der Heizungsinstallateur Modbus TCP bzw. die GLT-PV-Funktion aktiviert, und die Anleitung fährt von dort fort. Die vollständige Qualitätschranke lief auf dem Schnitt selbst (zweibeinige CI-Matrix mit Coverage-Schranken, strenges mypy, ruff, hassfest, Real-Home-Assistant-Lebenszyklus-Smoke-Tests, CodeQL/pip-audit, Anmeldedaten-Scan); Registerkatalog und alle Runtime-Pins bleiben identisch zu 0.26.0 (idm-heatpump-api[web]==2.16.1 — keine Runtime-Abhängigkeit hat sich bewegt). Das Entfernen der beiden Entitäten braucht keine Migration; Einstellungen, Dashboards und alle anderen Entitäten bleiben unberührt, ein Rollback auf 0.26.0 stellt das bisherige Verhalten wieder her. Ein repo-weiter Scan bestätigte, dass kein Original- oder konvertiertes iDM-Dokument eingecheckt ist, und ein kurzer Provenienz-Hinweis eröffnet nun die Registerseiten.

Release-Entscheidung zu 0.26.0

0.26.0 ist ein bewusster schneller stabiler Schnitt ohne öffentliche Beta-Linie: der Netzwerkscan im Einrichtungsassistenten (entwickelt und gemergt als 0.26.0-b1, #648) plus die Korrektur des B10-Hochdruck-Web-Sensors (#649). Die Begründung: Der B10-Fix ist eine einzeilige Metadaten-Änderung (inverted=True, kein Schreibpfad, keine Änderung am Polling — ausschließlich Anzeige-Semantik eines einzelnen binären Web-Sensors) mit eindeutigem Feldbefund, und eine Beta-Zyklus-Wartezeit würde betroffene Anlagen weiter mit einer dauerhaft einstehenden Fehlalarm-Störung belassen. Der Netzwerkscan greift nur im Setup, sendet keine Modbus-Bytes (einzelner TCP-Connect auf Port 502) und liest nichts. Die vollständige Qualitätschranke lief auf dem Schnitt selbst: die zweibeinige CI-Matrix (Python 3.14 × HA 2026.11.0 × manifest-pinned/api-main) mit Coverage-Schranken, strenges mypy, ruff, hassfest, die Real-Home-Assistant-Lebenszyklus-Smoke-Tests, CodeQL/pip-audit und der Anmeldedaten-Scan. Der API-Pin bleibt beim validierten idm-heatpump-api[web]==2.16.1 — identisch zu 0.25.0, kein Runtime-Pin hat sich bewegt. Kein Beta-Soak: für die beiden oben umrissenen, eng begrenzten Änderungen bewusst akzeptiert; alles Größere kehrt auf die Beta-Linie zurück. Ein Rollback ist sicher (keine Änderung an gespeicherten Daten, keine Entity-ID-Änderung).

Release-Entscheidung zu 0.25.0

0.25.0 ist der stabile Schnitt der b1–b9-Linie (2026-10-29 bis 2026-11-04; der unveröffentlichte b8-Kandidat ist vollständig in b9 enthalten) und das Release auf die Home-Assistant-2026.11-Plattform. Jede Beta der Linie durchlief vor ihrem Merge die vollständige Qualitätsschranke — die zweibeinige CI-Matrix (Python 3.14 × HA 2026.11.0 × manifest-pinned/api-main) mit den Coverage-Schranken, strenges mypy gegen die echte Home-Assistant-Runtime, ruff, hassfest, die Real-Home-Assistant-Lebenszyklus-Smoke-Tests und der Anmeldedaten-Scan — und der Schnitt selbst rannte die gesamte Suite gegen den promovierten stabilen API-Pin (3.350+ Tests, 98,8 % Coverage am minimalen Home Assistant 2026.11.0). Die Advisor-Ergänzungen sind strikt lesend (gemeinsame Evidenz-Ablage, kein Schreibpfad, kein EEPROM-sensitives Register); das GLT-Sentinel-Logging ist reine Diagnose und ohne Debug-Logging stumm. Das 2026.11-Minimum steht im Manifest-Schlüssel homeassistant und in HACS und wird beim Setup geprüft (#632, Feldmeldung von @x29a); Installationen auf 2026.8–2026.10 bleiben bei 0.24.0-b2. idm-heatpump-api 2.16.0 — identischer Code zum Linien-Pin 2.16.0b3, reine Promotion — ist der validierte Partner dieses Schnitts und lag vor dem Integrations-Tag auf PyPI.

Prüfumfang zu 0.23.2-b4

Diese Beta behebt die Navigator-10-Doppellabel-Sensoren (#598) rein auf Integrationsseite; der API-Pin bleibt 2.14.5b2. B33/B113 und B34/B114 liegen jetzt auf eigenen Zwischenkreis-Wertschlüsseln — und überschreiben dabei bewusst die Zuordnung der Bibliothek auf die schlichten Vorlauf/Rücklauf-Schlüssel, die ein setdefault nicht ersetzen konnte — sodass die Entitäten neben einer Modbus-Verbindung existieren. Anlagen ohne Trennwärmetauscher behalten die Duplikat-Unterdrückung für schlichtes B33/B34. Die komplette Integrationssuite (3.149 Tests, 99,82 % Coverage), strenges mypy, ruff und die Real-Home-Assistant-Smoke-Tests liefen gegen den gepinnten Stand grün.

Issue #598 bleibt offen, bis der Melder die umbenannten Entitäten an seiner Anlage bestätigt. Issue #577 bleibt für die Webantworten des Navigator 1.7 und die genauen Rohabfragen der Statusregister offen. Issue #493 wurde nach dem gemeldeten Rückfall wieder geöffnet; Ursache und reglerinternes Beibehalten der Werte sind nicht bewiesen. Diese Beta beansprucht keine Behebung von #577 oder #493.

Prüfumfang zu 0.23.2-b3

Diese Beta pinnt das API-Wartungsprerelease 2.14.5b2. Die Modellerkennung bündelt ihre Heizkreis-Probes hinter einzelnen Gate-Probes mit Per-Slot-Fallback; erkannte Modelle, Heizkreise und Entitäten ändern sich nicht, und weder Register-Map noch Schreibpfade haben sich bewegt. Die komplette Integrationssuite (3.149 Tests, 99,82 % Coverage) sowie die Guards für Abhängigkeits-Aktualität und Dokuversions liefen gegen das veröffentlichte PyPI-Artefakt grün.

Issue #577 bleibt für die Webantworten des Navigator 1.7 und die genauen Rohabfragen der Statusregister offen. Issue #493 wurde nach dem gemeldeten Rückfall wieder geöffnet; Ursache und reglerinternes Beibehalten der Werte sind nicht bewiesen. Die früheren Release-Entscheidungen unten dokumentieren den jeweiligen damaligen Stand, nicht den heutigen Issue-Status. Diese Beta beansprucht keine Behebung dieser beiden Issues.

Prüfumfang zu 0.23.2-b2

Diese Beta ergänzt die Erkennung von Doppelkennungen für Navigator 10-Sensoren (B33/B113 und B34/B114) auf Anlagen mit Trennwärmetauscher / frostgeschütztem Außenkreis (#598) und bereinigt Python 3.14 Event-Loop-Warnungen sowie Quality-Scale-Pins (#599).

Release-Entscheidung zu 0.23.2

0.23.2 ist der stabile Schnitt der fünf Betas b1–b5 (2026-10-24 bis 2026-10-27). Jedes Beta der Linie lief vor dem Merge durch das volle Qualitäts-Gate — die vierbeinige CI-Matrix (Python 3.14 × HA 2026.11.0 × manifest-gepinnt/api-main) mit den Coverage-Gates, strict mypy gegen die echte Home-Assistant-Runtime, ruff, hassfest, die echte Lifecycle-Smoke-Strecke und der Credentials-Scan — und der Schnitt selbst lief die komplette Suite erneut gegen den beförderten stabilen API-Pin (3.175+ Tests, 99,7 % Coverage). Die Advisor-Änderungen sind strikt lesend (additive Storage-Felder, kein Schreibpfad, kein EEPROM-sensitives Register); die Anomalie-Maschinerie re-baselinert sich nach dem Update einmal pro Anlage, was die Upgrade-Notes benennen. Der Dual-Label-Fix (#598) wurde für b4 vom Reporter live auf seiner AERO ALM 6–15 bestätigt; die M125-Pumpen-Zuordnung (API #151) trägt die Live-WebSocket-Evidenz des Reporters für die Setting-Tabelle. idm-heatpump-api 2.14.5 ist das mit diesem Schnitt validierte Paar. #598 und API #151 sind geschlossen; #577, #493 und #596 warten auf Reporter-Felddaten und werden hier nicht als gefixt beansprucht.

Release-Entscheidung zu 0.23.1

0.23.1 ist ein stabiles Fix-Release direkt von main, ohne Prerelease-Linie: Beide Fixes sind klein, lokal begrenzt und von fokussierten Tests getragen. Das volle Qualitäts-Gate lief vor dem Merge über beide Pull Requests (#579, #580): die vierbeinige CI-Matrix (Python 3.14 × HA 2026.11.0 × manifest-gepinnt/api-main) mit den Coverage-Gates, strict mypy gegen die echte Home-Assistant-Runtime, ruff, hassfest, die echte Lifecycle-Smoke-Strecke und der Credentials-Scan. Die Registerkarten-Korrektur wurde vor der Code-Änderung lokal am puren Resolver reproduziert, die Zähler-Sicherung mit den exakten Werten des Reporters verifiziert (10036.0 → 10035.99). Feld-Bestätigung wird von beiden Reportern zur Release erwartet; #577 bleibt offen, bis der Reporter den Automatikmodus auf seiner Hybrid-Anlage bestätigt hat.

Release-Entscheidung zu 0.23.0

0.23.0 ist der stabile Schnitt der Linie aus vierzehn Prereleases (b1–b14, 17.–20.10.2026). Für den Schnitt bestand das volle Qualitäts-Gate auf dem Release-Baum: die vierbeinige CI-Matrix (Python 3.14 × HA 2026.11.0 × manifest-gepinnt/api-main) mit den Coverage-Gates, strict mypy gegen die echte Home-Assistant-Runtime, ruff, hassfest, HACS, die echte Lifecycle-Smoke-Strecke und die Paket-zu-Tag-Verifikation des Release-Workflows. Die Linie lief durchgehend im Feld: Jede Beta lief beim Erscheinen live auf der Navigator-10-Anlage des Maintainers (die Advisor-Arbeiten b10–b14 wurden dort Stunde für Stunde verifiziert, endend in einer beobachteten Warmwasser-Ladung innerhalb des empfohlenen PV-Fensters am 20.10.2026), die FLOAT32-Korrektur des Durchfluss-Registers wurde auf zwei Anlagen live bestätigt (Diskussion #516), und die Reporter zu #532, #537–#539 und #546 haben ihre Fixes direkt validiert. Der unveränderte b14-Kandidat soakte vor diesem Schnitt etwa einen Tag — unterhalb des Sieben-Tage-Gates, und der Code der Linie änderte sich fast täglich. Der Maintainer entschied sich dennoch für den Schnitt: Die einzigen Schreibpfad-Änderungen der Linie beschränken sich auf das Scheduling der Schreib-Bestätigungen (#537 samt Per-Task-Nachzug, live auf der Referenzanlage seit 17./18.10.2026), die Register-Map-Änderung ist eine Korrektur des Lesetyps, die Advisor- und Speicher-Änderungen sind lokal (additive Speicherfelder, einmaliges Gebäudemodell-Neulernen, Modus-Zähler ab null), und kein EEPROM-sensibles Register wird von einem neuen Pfad berührt. Issue #493 ist geschlossen (controller-intern auf der Firmware des Reporters; der zyklische GLT-Refresh bleibt); idm-heatpump-api 2.14.4 ist das mit diesem Schnitt validierte Paar.

Release-Entscheidung zu 0.23.0-b10

0.23.0-b10 bündelt den Advisor-Review-Durchlauf (Prognose-Zeitpfad, Empfehlungs-Lebenszyklus, Modellqualität, Schreib-Drossel) mit den neuen Modus-COP-Statistiken. Die risikoreichsten Punkte und ihre Begrenzung: Der Versions-Bump der Gebäudemodell-Speicherung erzwingt ein einmaliges Neulernen der Wärmeverlust- und Vorlaufkurven-Modelle (derselbe Mechanismus wie b7/#546, im Changelog dokumentiert); der refreshed_at-TTL-Anker ist ein additives Speicherfeld, das aus älteren Stores defensiv gelesen wird; und die Modus-Energiezähler starten bei Adoption bei null, ohne die bestehenden Gesamt-Summen anzufassen. Die Prognose-Fixes (Fensterzeiten in Ortszeit, Viertelstunden-Faltung, Preis-Dedup) sind reine Lese-Pfade. Die Live-Verifikation auf der Referenzanlage folgt diesem Release: neue Sensoren energy_cop_heating_* / energy_cop_dhw_*, Ortszeit-Fenster in der Warmwasser-Empfehlung und das einmalige Modell-Neulernen; die Evidenz- Datei docs/release-evidence/0.23.0-b10.md hält das Ergebnis fest.

Release-Entscheidung zu 0.23.0-b5

0.23.0-b5 bringt die Advisor-Darstellungs-Politur und den Web-Wert-Fallback aus demselben Feld-Durchlauf: die Themen-Ablösung der Empfehlungen (ein aktiver Eintrag pro Thema, Nutzer-Status vererbt über die tägliche Neuausgabe) und der #516-Fallback (Web-Werte füllen Register, deren Modbus-Lesung das Nicht-vorhanden-Muster trägt; echte Modbus-Werte gewinnen immer). Beides sind Lese-Pfad-Änderungen mit fokussierten Tests. Die drei b4-Fixes wurden nach HACS-Update und Neustart live auf der Referenzanlage verifiziert: Die periodischen koordinator-weiten Nicht-verfügbar-Fenster sind weg (#537, über zwei Weitergabe-Intervalle verifiziert), der Anforderungsgrund meldet nur noch englische Labels (#538) und der Advisor zeigt flow_sensor: false mit als nicht verfügbar zählenden Durchfluss-Samples auf der No-TWT-Anlage (#539) — was dieser Fallback nun überall dort wieder anheben kann, wo das Web-Supplement einen echten Flowmeter-Wert liefert. Die Issues #537/#538/#539 wurden als erledigt geschlossen.

Release-Entscheidung zu 0.23.0-b4

0.23.0-b4 bringt die drei Befunde aus der Advisor-Feld-Validierung (Referenzanlage, 0.23.0-b3, Evidenz in den Issues #537/#538/#539). Das Verfügbarkeits-Flattern (#537) ist der gewichtige: Die Ursache ist ein lautlos verschluckter CancelledError im Home-Assistant-Koordinator, nachgewiesen durch eine echte-HA-Sonde, behoben durch eine Scheduling-Wache — abgesichert durch drei neue Real-Home-Assistant-Regressionstests neben dem Lifecycle-Smoke. #538 und #539 sind Lese-Pfad-Klassifizierungen (Label-Vokabular-Mapping, No-TWT-Durchfluss-Filter). Alle drei bleiben offen bis zur Bestätigung auf der Referenzanlage nach dem HACS-Update. Die Kernfrage des Advisors beantwortete derselbe Durchlauf: Die Heizkurven-Empfehlungen passen zur Controller-Eigenanzeige und den Raumtemperaturen bei täglich steigender Konfidenz — der Advisor selbst brauchte keine Änderung.

Release-Entscheidung zu 0.23.0-b1

0.23.0-b1 eröffnet die 0.23-Linie mit zwei Fixes aus den Beweisen von Issue #532 (Navigator-2.0-Reporter, Diagnostics und Log angehängt): Die registerseitigen „nicht vorhanden"-Sentinels liegen im frisch veröffentlichten Geräte-Logik-Patch (im Manifest exakt gepinnt; Kompatibilitätsmatrix aktualisiert), die integrationseitige Behandlung des ----Web-Platzhalters dazu. Beides sind Klassifizierungs-Änderungen im Lese-Pfad — kein Schreibpfad, keine Registeradressen, keine Konfigurationsoberfläche hat sich bewegt. Das Prerelease wurde geschnitten, um dem Reporter und dem Feld schnell einen testbaren Build zu geben; das Issue bleibt offen, bis der Reporter bestätigt, dass die Warnungen und die Listener-Fehler-Flut auf seiner Anlage verschwunden sind. Bewusste Nicht-Änderungen: ext_humidity über 100 % bleibt abgewiesen (KNX-Quelldaten), die Corrupt-Batch-Recovery von Issue #69 bleibt unangetastet (Sentinels pro Register, nicht validatorweit), und die Navigator-1.7-Map wird nicht verändert (eigene Protokollfamilie, kein Hardware-Capture).

Release-Entscheidung zu 0.22.0

0.22.0 ist der stabile Schnitt der Resilienz-Linie aus sieben Prereleases (b1–b7, 13.–15.10.2026) inklusive der nie beförderten 0.21.3-Linie. Für den Schnitt bestand die vollständige Qualitätsprüfung auf dem getaggten Baum: die Zwei-Beine-Matrix (Python 3.14 × HA 2026.11.0 × manifest-pinned/api-main) mit Coverage 95 % und config_flow 100 %, strict mypy gegen die echte Home-Assistant-Runtime, ruff, hassfest, HACS, der Lifecycle-Smoke mit echtem Home Assistant inkl. der Assertion gegen leckende Tasks, Paketierung, Prüfsummen- und Paket-zu-Tag-Verifikation. Die Linie lief durchgehend im Feld: Die Ausfall-Dämpfung und das fünfminütige Ruhe-Fenster liefen auf der Anlage des Maintainers durch wiederkehrende Modbus-Proxy-Ausfälle (ab b1 verifiziert sauber — Dämpfung wirkt, Repairs räumen sich selbst ab), und externe Reporter haben den bidirektionalen Netzleistungszähler validiert (#519, bestätigt auf b5 mit dem Rundungs-Follow-up auf b6) sowie die #493- und #504-Untersuchungen vorangetrieben, deren Fixes über die absorbierte 0.21.3-Linie und die 0.22-Betas ausgeliefert wurden. Der unveränderte b7-Kandidat lief weniger als einen Tag — unter dem siebentägigen Gate 6, und der Code der Linie änderte sich fast täglich; der Maintainer entschied dennoch zu schneiden, weil die Änderungen an der Schreibfläche auf GLT-RAM-Inputs beschränkt sind (kein EEPROM-sensibles Register wird von einem neuen Pfad berührt, und die RAM-Refresh-Kadenz ist auf den betroffenen Firmwares zwingend), während Registerkarte, Modellerkennungskern und Web-Supplement gegenüber dem 0.21.x-Stable unverändert sind. Issue #493 bleibt für ein firmware-spezifisches Batterie-Anzeige-Flackern eines Reporters offen: Die integrationsseitige Behandlung (zyklischer RAM-Refresh) ist auf der Referenzanlage validiert, das restliche Flackern ist controller-intern und mit dem IDM-Support in Klärung, und es betrifft weder Steuerung noch Datenintegrität. Keine Konfigurationsmigration nötig; ein Rollback auf 0.21.2 bleibt möglich.

Release-Entscheidung zu 0.21.2

Dieser Wartungskandidat behebt das neu gemeldete #489: optionale externe Leistungsquellen sind Vorschläge statt erzwungener Standardwerte, und SOC mit Nachkommastellen wird geprüft und für den GLT-Eingang gerundet. Tests prüfen Leeren aller sechs Quellen, Erhalten anderer Zuordnungen, Null-/Leerwerte und Umrechnung, auch mit echter HA-Selector-Validierung. Vollständige Coverage-, Typ-, Lint-, Lebenszyklus- und GitHub-Prüfungen sind vor Veröffentlichung erforderlich. Abhängigkeiten und Transport bleiben gleich. Leeren stoppt Weiterleitung und optionale HA-Batteriebedingung; es setzt kein Reglerregister zurück und beweist nicht, dass der Navigator seinen letzten Messwert vergessen hat.

Release-Entscheidung zu 0.21.1

Dieser Wartungskandidat behebt bestätigte Integrationsfehler bei Sperrzeiten und Betriebsartsteuerung automatischer PV-Warmwasser-Boosts (#487) und ergänzt den reglerabhängigen Fachmann-Code für Navigator 1.7 (#486). Abhängigkeiten, Transport und Registertabellen bleiben gleich. Die Veröffentlichung setzt beide vollständigen Coverage-Prüfungen, strikte Typprüfung gegen die Runtime, Lint, den echten HA-Lebenszyklustest und die GitHub-Qualitätsprüfungen voraus.

Die Tests prüfen Start, Nachsetzen, Rollback und Wiederherstellung ohne Betriebsartwechsel, neustartfeste Sperrzeit, ungültige Werte und Codeauswahl. Es erfolgten keine Schreibzugriffe auf echte Regler und kein längerer Feldtest. Automatische Tests beweisen weder die alleinige Ursache der gemeldeten Pufferzyklen noch die Annahme des Navigator-1.7-Codes am Gerät. Die PV-Puffer- steuerung des Navigators bleibt unabhängig. Die optionalen Parameter aus #429 bleiben mangels bestätigter Registerzuordnung nicht verfügbar; es wird keine Zuordnung geraten.

Aktueller Status

Den stabilen Kanal zeigt das aktuelle stabile Release. Die Quellstand-Versionen unten werden automatisch geprüft. Alte Releases behalten die Abhängigkeiten ihres getaggten Manifests.

Release-Entscheidung zu 0.21.0

0.21.0 ist der stabile Schnitt der Predictive-Advisor-Linie aus vier Prereleases (b1–b4, 07.–11.10.2026). Der Advisor ist konstruktionsbedingt strikt nur lesend — sein Modul besitzt keinen Schreibpfad, und das Annehmen einer Empfehlung vermerkt lediglich eine Bestätigung — und arbeitet voll lokal und deterministisch. Für den Schnitt bestand die vollständige Qualitätsprüfung auf dem getaggten Baum: die Zwei-Beine-Matrix (Python 3.14 × HA 2026.11.0 × manifest-pinned/api-main) mit Coverage 95 % und config_flow 100 %, strict mypy gegen die echte Home-Assistant-Runtime, ruff 0.17, hassfest, HACS, der Lifecycle-Smoke mit echtem Home Assistant inkl. der Assertion gegen leckende Tasks, Paketierung, Prüfsummen- und Paket-zu-Tag-Verifikation. Die Linie war innerhalb von Tagen im Feld — die Issues #460 und #471 wurden von externen Reportern gestellt, diagnostiziert und innerhalb der Linie gefixt (b2–b4 und die parallelen 0.20.x-Schnitte). Der unveränderte b4-Kandidat lief vom 11.10. bis zum Schnitt — ein Tag, unter dem siebentägigen Gate 6; der Maintainer entschied dennoch zu schneiden, weil der Advisor kein Schreibrisiko trägt und der Transport- und Polling-Kern dieses Baums byte-identisch mit der 0.20.x-Linie ist, die seit dem 09.10. der stabile Kanal ist. Die Lernphasen des Advisors (7-Tage-Basenlinien vor Heizkurven-Empfehlungen, gestufte Beobachtung) entfalten sich in den ersten Betriebstagen statt in einem Dauertest. Keine Konfigurationsmigration nötig; ein Rollback auf 0.20.x bleibt möglich.

Release-Entscheidung zu 0.20.4

0.20.4 ist ein Wartungsschnitt auf Basis von 0.20.3, abgezweigt vom Tag v0.20.3: Er cherry-gemappt den Fix zu Issue #471 (das Weiterleitungsintervall der externen Leistungswerte wird zu einem echten Optionsfeld — die erweiterte Guided-Seite crashte am fehlenden Schlüssel — plus stille Überspringung im Schreib-Cooldown und ein Regressionstest über jedes geführte Feature und Level) und hebt den modbus-connection-Floor auf >=4.12.4, dem eigenen Core-Modbus-Pin von Home Assistant 2026.10.1 folgend; die für 0.20.3 gebaute HA-Pin-Deckelung erlaubt die Anhebung jetzt. Der Release-Lauf validierte den getaggten Baum mit der vollständigen Qualitätsmatrix inklusive der Lifecycle-Suite mit echtem Home Assistant; Paketierung, Prüfsummen- und Paket-zu-Tag-Verifikation bestanden. Die Abhängigkeitsänderungen starten formal die Dauertest-Uhr (Gate 6) neu; der Maintainer veröffentlichte aus denselben Gründen wie bei 0.20.2 und 0.20.3 — das funktionale Delta ist ein Configuration-Flow-Fix mit Regressionstests, und der Transport-Bump folgt exakt dem Paar, das Home Assistant selbst in seinem neuesten stabilen Release installiert. Die 0.21.0-Linie trägt den Guided-Fix seit 0.21.0-b4.

Release-Entscheidung zu 0.20.3

0.20.3 ist ein reiner Pin- und Dokumentations-Schnitt auf Basis von 0.20.2, abgezweigt vom Tag v0.20.2: Die Geräte-Logik zieht auf idm-heatpump-api[web]==2.14.4, deren einzige Änderung den Validierungsbereich von dhw_charge_off_temp vom dokumentierten 46..53 °C auf 46..67 °C weitet — die Anlage des Reporters in Issue #460 misst dort 63 °C, und die Weboberfläche des Reglers bietet 50..67 °C an. Der Baum trägt zusätzlich zwei cherry-gemappte Wartungsfixes, ohne die an diesem Tag nicht gebaut und Released werden konnte: die ruff-0.17-Lint-Befunde und die Home-Assistant-Pin-Deckelung, die den modbus-connection-Floor bei der 4.12.3 hält, die Home Assistant selbst pinnt (Upstream 4.12.4 ist neben HA nicht installierbar; ohne die Deckel-Regel war jedes Release blockiert, auch dieses). Der Release-Lauf validierte den getaggten Baum mit der vollständigen Qualitätsmatrix; Paketierung, Prüfsummen- und Paket-zu-Tag-Verifikation bestanden. Die Abhängigkeitsänderung startet formal die Dauertest-Uhr (Gate 6) neu; der Maintainer entschied aus denselben Gründen wie bei 0.20.2 zu veröffentlichen — das Delta ist ein Register-Datenpatch der Bibliothek bei baumidentischen Transport-Pins —, und die 0.21.0-Linie trägt denselben Pin seit 0.21.0-b3.

Release-Entscheidung zu 0.20.2

0.20.2 ist ein reiner Pin- und Dokumentations-Schnitt auf Basis von 0.20.1, abgezweigt vom Tag v0.20.1: Die Geräte-Logik zieht auf idm-heatpump-api[web]==2.14.4, deren einzige Änderung die WARNUNG pro Abfrage bei einem dauerhaft ungültigen Registerwert beruhigt (Issue #460) — eine Warnung pro Register und Episode statt eine pro Abfrage. Gegen 0.20.1 änderte sich kein Integrations-Code. Der Release-Lauf validierte den getaggten Baum mit der vollständigen Qualitätsmatrix; Paketierung, Prüfsummen- und Paket-zu-Tag-Verifikation bestanden. Die Abhängigkeitsänderung startet formal die Dauertest-Uhr (Gate 6) neu; der Maintainer entschied dennoch zu veröffentlichen, weil das Delta ein reiner Logging-Patch der Bibliothek ist, der bereits die volle Prüfung durchlaufen hat, und die 0.21.0-Beta-Linie denselben Pin seit 0.21.0-b2 trägt. Die 0.21.0-Linie läuft von diesem Schnitt unabhängig weiter.

Release-Entscheidung zu 0.20.1

0.20.1 ist der stabile Schnitt der selbstheilenden Linie aus fünf Prereleases (b1–b5, 30.09.–02.10.2026); am stabilen Tag änderte sich gegen b5 kein Code. Für den Schnitt waren automatisierte CI — inklusive der Lifecycle-Suite mit echtem Home Assistant sowohl auf dem Minimum 2026.11.0 als auch auf der 2026.10.0-Beta — sowie HACS, Hassfest, Sicherheitsprüfungen, Release-Paketierung, Verifikation der veröffentlichten Prüfsummen und der Paket-zu-Tag-Vergleich erfolgreich. Die Linie lief ab dem 30.09.2026 auf der Navigator-10-Anlage des Maintainers; der unveränderte b5-Kandidat lief vom 02.10. bis zum Schnitt — vier Tage, unter dem siebentägigen Gate 6 — ohne dass ein bestätigter Datenfehler, eine Reconnect-Schleife, ein unsicherer Schreibzugriff oder eine Setup-Regression im Tracker gemeldet wurde. Die Issues #429 (Differenztemperaturkreise, auf der Hardware des Reporters live validiert) und #319 (Vorrangladung am Navigator 1.x) wurden innerhalb der Linie abgeschlossen. Die Transport-Pins wurden Home-Assistant-eigene Mindestversionen — hassfest lehrt exakte Pins dafür ab — und die Gerätelogik ist auf idm-heatpump-api[web]==2.14.4 gepinnt. Das Gate-6-Defizit ist hier festgehalten, damit es sichtbar bleibt.

Frühere Release-Entscheidungen

0.20.0 war der web-first stabile Schnitt: Jede Schreibschnittstelle des steuerbaren Web-only-Modus — Betriebsart, Fehlerquittierung, Warmwasser-Sollwert, Heizkreis-Sollwerte und -Betriebsarten — war capture-bestätigt (28.09.2026) und auf der Anlage des Maintainers mit umkehrbaren Round-Trips live validiert; die Familie Navigator 1.0/1.7 wurde über den offiziellen Coil-Block (c3000–c3003) mit vom Tester bestätigtem Verhalten vervollständigt (#319). Die automatisierten Gates waren erfolgreich. Für diesen Schnitt existiert keine eigene Evidence-Datei — seine Validierung ist im Evidence-Eintrag der 0.20.1-Linie festgehalten — und das Release wurde nach sechs Tagen von 0.20.1 abgelöst, als die selbstheilende Linie bereit war.

0.19.0 ist der stabile Schnitt der Linie aus sechzehn Betas. Sie macht den Navigator 1.0/1.7 zum vollwertigen Familienmitglied — der vollständige offizielle Schreibblock, ein firmware-ehrter Bereichsfilter, der capture-verifizierte FW030-Float-Sollwert und eine Warmwasser-Karte — und ergänzt PV-Sichtbarkeit (Issue #353), die Solar-Abschaltung, den Diagnoseexport je Register, einen ehrlicheren KI-Berater und das deutsche Wiki-Spiegel. Automatisierte CI (inklusive der Smoke-Tests mit echtem Home Assistant), HACS, Hassfest, Sicherheitsprüfungen, Release-Paketierung, Verifikation der veröffentlichten Prüfsummen und der Paket-zu-Tag-Vergleich waren erfolgreich; 0.19.0-b15 lief mit sauberem Log auf der Produktionsanlage des Maintainers, und die Register-Korrekturen für den Navigator 1.0/1.7 wurden durch die Nach-Update-Diagnose eines Testers auf der veröffentlichten Version bestätigt (Issue #364). Die Entscheidungen zu 0.17.x/0.16.x unten bleiben wie veröffentlicht.

0.17.2-b6/0.18.0: Für den Kandidaten waren automatisierte CI, HACS, Hassfest, Sicherheitsprüfungen, Release-Paketierung, Verifikation der veröffentlichten Prüfsummen und der Paket-zu-Tag-Vergleich erfolgreich. Die rein lesende Beobachtung der laufenden Anlage im Audit vom 18. September nutzte Beta 5; sie war keine Hardware-Validierung und kein siebentägiger Dauertest von Beta 6. Der Kandidaten-Eintrag hielt den Zustand vor der Veröffentlichung fest.

0.17.0 ist der stabile Schnitt der Linie, die am 2026-09-09 mit 0.17.0-beta.1 eröffnet wurde. Sie trägt das vollständige Code-Audit-Ergebnis, die Modell-Abgleichskorrekturen aus beta.3 und die Navigator-1.0/1.7-Protokollfamilie aus beta.4, auf idm-heatpump-api 2.1.1 und modbus-connection 4.11.1.

Maintainer-Entscheidung zu 0.17.0: Der stabile Tag wurde am 2026-09-13 geschnitten, am Tag der Veröffentlichung von 0.17.0-beta.4, sodass Gate 6 (sieben aufeinanderfolgende 24-Stunden-Zeiträume im Dauertest mit einem unveränderten Kandidaten) für beta.4 nicht erfüllt war — obwohl beta.1 bis beta.3 seit dem 2026-09-09 im Feld waren, ohne Regressionsmeldung. Das Live-Hardware-Follow-up von Gate 3 bleibt doppelt offen: Kein Navigator 1.0/1.7-Gerät gehört einem Maintainer (der Aufruf an Tester ist #319), und die Verifizierung der KNX-Bridge am physischen Bus ist unverändert gegenüber 0.16.0. Automatisierter Preflight, Aktualität der Dependency-Pins und die volle CI-Matrix gingen hingegen durch, und eine rein lesende Modellerkennungs-Sonde gegen den Navigator 10 des Maintainers bestätigte am 2026-09-13, dass die neue Erkennung einen Controller derselben Familie nicht falsch einordnet. Dies ist eine bewusste Maintainer-Entscheidung zum Release-Zeitpunkt, kein Versehen — hier und in docs/release-evidence/0.17.0.md festgehalten, damit es sichtbar bleibt.

Integration im Quellstand 0.27.0-b4 und idm-heatpump-api 2.16.2 bilden das aktuelle exakt gepinnte Integrations-/API-Paar. Die API-Version ist in PEP-440-Form geschrieben, weil genau das pip auflöst; die Integration behält SemVer-Tags für HACS. Bis einschließlich 0.14.1 war der direkte Socket auf modbus-connection==4.0.0a3 mit tmodbus==0.5.0 gepinnt.

0.16.0 wirft pymodbus vollständig heraus — ein Breaking Change und der Grund, warum die Linie mit einer Beta eröffnet wurde. idm-heatpump-api 2.0.0 besitzt eine eigene Ausnahme-Hierarchie (IdmModbusError und Unterklassen), statt von pymodbus zu erben, und verlagert seinen eingebauten Modbus-TCP-Transport hinter ein optionales Extra. Diese Integration injiziert einen tmodbus-basierten Transport und installiert damit nun keinen Modbus-Stack mehr, den sie nicht spricht. Die Transport-Pins sind modbus-connection>=4.12.7 und tmodbus[async-serial]>=0.6.2.

0.17.0-beta.2 entfernt eine Sache, die 0.17.0-beta.1 eingeführt hatte: das Repair-Issue für ein Register, das die Wärmepumpe nicht implementiert. Ein Controller, der für etwa firmware_version mit Illegal Data Address antwortet, verhält sich normal — dieses Modell, diese Firmware oder Hardwareoption hat die Funktion schlicht nicht — aber eine Warnungskarte unter Einstellungen → Reparaturen liest sich wie ein Defekt, und sie forderte eine Aktion, die es nicht gibt. Die Erklärung bleibt, als Log-Zeile und im Diagnose-Download. Alles andere ist identisch mit 0.17.0-beta.1; die Dauertest-Uhr startet neu, weil sich der Code geändert hat.

0.17.0-beta.1 ist der erste Kandidat der 0.17.0-Linie und trägt das Ergebnis des Code-Audits aus docs/dev/code-audit-2026-09.md. Acht Fehler sind behoben, darunter eine Abfrage, die ihren Config-Eintrag überlebte, ein fehlgeschlagenes Setup, das lebende Entitäten zurückließ, eine zweite Wärmepumpe hinter einem Modbus-Gateway, die nicht mehr hinzugefügt werden konnte, weitergeleitete Temperaturen, die nicht nach Grad Celsius umgerechnet wurden, und Sentinel-Messwerte, die einen Temperaturzustand erreichten. Sechs Robustheits- und drei Performance-Punkte kamen hinzu, ebenso die Extraktionen, die den betroffenen Code testbar machten: model_resolution.py für den Modell-Abgleich und eine öffentliche Coordinator-Fläche für die sieben Module, die früher in seine privaten Attribute griffen. Beide Runtime-Pins zogen nach (modbus-connection 4.11.1, idm-heatpump-api 2.0.1); keine Register-Map und kein Entitätsbezeichner änderte sich. Es ist eine Beta, weil das Audit Modellerkennung, Setup und Teardown, schreibende Entitäten und Dienste berührte und weil die Abhängigkeitsänderung die Dauertest-Uhr neu startet.

0.16.2 ist ein Patch auf 0.16.1: validate_overrides akzeptierte einen KNX-Gruppenadress-Override, der die abgeleitete Adresse (base + Objektnummer) eines anderen bedienten Objekts beanspruchte, und die Bridge leitete diese Adresse anschließend nur an eines der beiden Register. Adressauflösung und der KNX-Optionenschritt lehnen jetzt jede doppelt beanspruchte Adresse ab. tmodbus[async-serial] zog von 0.6.1 auf 0.6.2; kein Register und keine Entität änderte sich.

0.16.1 ist ein Patch auf 0.16.0: Zeigte das lokale Web-Supplement auf eine IP-Adresse, schloss die Integration eine Home-Assistant-aiohttp-Session, statt sie zu entkoppeln — was Home Assistant im Log meldet und was bis in einen mit jeder anderen Integration geteilten Connector hineinreicht. Die Per-IP-Session wird jetzt mit detach() freigegeben und mit auto_cleanup=False erzeugt, damit ein neu gebauter Web-Client die alte nicht bis zum Stopp von Home Assistant gepinnt hält. Nichts anderes änderte sich — Register, Entitäten, die KNX-Bridge, die Schreibwächter und die Runtime-Pins sind identisch mit 0.16.0.

0.16.0 ist der stabile Schnitt dieser Linie, im Code identisch mit 0.16.0-rc.6. Die Hauptfunktion ist die experimentelle KNX-Bridge: Die Integration bedient die 654 IDM-KNX-Kommunikationsobjekte selbst, über die Home-Assistant-Integration knx, sodass das Weinzierl-Gateway-Modul KNX IP BAOS 774 nicht mehr nötig ist. Die Bridge ist Opt-in und standardmäßig aus, und ihr Verhalten am physischen Bus bleibt unverifiziert — siehe die offenen Gates unten.

Maintainer-Entscheidung zu 0.16.0: Der stabile Tag wurde am 2026-08-28 geschnitten, einen Tag nach der Veröffentlichung von 0.16.0-rc.6, sodass Gate 6 (sieben aufeinanderfolgende 24-Stunden-Zeiträume im Dauertest mit einem unveränderten Kandidaten) nicht erfüllt war — der früheste mögliche Abschluss war der 2026-09-03. Auch Gate 3s Live-KNX-Follow-up (Interoperabilität physischer Gruppenadress-Telegramme und Buslast beim ersten Export) und die Navigator-2.0/Pro-Hardware-Abdeckung bleiben offen. Automatisierter Preflight, Aktualität der Dependency-Pins und die RC5/RC6-Live-Smoke-Nachweise am Navigator 10 des Maintainers gingen hingegen durch. Dies ist eine bewusste Maintainer-Entscheidung zum Release-Zeitpunkt, kein Versehen — hier und in docs/release-evidence/0.16.0.md festgehalten, damit es sichtbar bleibt.

0.16.0-rc.6 behält die Latest-Value-KNX-Warteschlange aus RC5 bei und ergänzt eine Startup-Wiederherstellung für den Ereignisfilter. Home Assistant kann die KNX-Dienste bereitstellen, bevor seine KNX-Runtime bereit ist; die Bridge wiederholt jetzt nur die fehlenden Gruppenadress-Batches, statt ein manuelles IDM-Reload zu verlangen. Die Schreibwächter und der konfigurierbare 60-Sekunden-EEPROM-Standard sind unverändert. Interoperabilität physischer Gruppenadress-Telegramme und Buslast bleiben offen.

0.15.1 war die letzte Linie mit pymodbus: Sie pinnte idm-heatpump-api 1.0.3, zog das Transportpaar auf modbus-connection>=4.12.7 / tmodbus[async-serial]>=0.6.2 und trug die Schreib-Diagnose-Arbeiten aus #237.

0.15.0 zog dieses Paar auf modbus-connection==4.8.1 und tmodbus[async-serial]==0.5.1, ergänzt Raumtemperatursensoren für alle Heizkreise (A–G) über idm-heatpump-api, Connection-Pacing-Optionen, NC-Kontakt-Invertierung und das Aufräumen verwaister Sensoren. Sie schließt den Zyklus 0.15.0-beta.1 bis 0.15.0-beta.3 ab. Hardware-Smoke-Nachweise für den Zyklus sind in docs/release-evidence/0.15.0-beta.2.md festgehalten; der stabile Schnitt in docs/release-evidence/0.15.0.md.

Maintainer-Entscheidung zu 0.15.0: Der stabile Tag wurde am selben Tag geschnitten, an dem 0.15.0-beta.3 veröffentlicht wurde, sodass Gate 6 (sieben aufeinanderfolgende 24-Stunden-Zeiträume im Dauertest mit einem unveränderten Kandidaten) nicht erfüllt war, und für den stabilen Kandidaten selbst existiert kein signierter Clean-Home-Assistant-Smoke-Test (Gate 2). Automatisierter Preflight, Aktualität der Dependency-Pins und die Hardware-Verifizierung des Beta-Zyklus gingen hingegen durch. Dies ist eine bewusste Maintainer-Entscheidung zum Release-Zeitpunkt, kein Versehen — hier und in docs/release-evidence/0.15.0.md festgehalten, damit es sichtbar bleibt.

idm-heatpump-api 1.0.2 erweiterte den optionalen lokalen Web-Client um die Raumtemperaturen der Heizkreise B61–B67 (room_temperature_HK_A bis G), live verifiziert an einem Navigator 10 ALM 6-15 (B64 = 21.8 °C). 1.0.3, die Version, die 0.15.0 pinnt, ist ein Wartungs-Release dieser Bibliothek: Sie enthält nur CI- und Security-Toolchain-Updates, ihr öffentliches Verhalten ist identisch mit 1.0.2.

Maintainer-Entscheidung zu den unten stehenden Stable-Release-Gates: 0.11.0 wurde als stabil veröffentlicht, ohne Gate 6 abzuwarten (den siebentägigen Dauertest, zurückgesetzt durch die am selben Tag ausgelieferten Kandidatenänderungen 0.11.0-beta.7/beta.8) und ohne Gate 3s Live-Follow-up, #192, zu schließen (eine Anzeige-Diskrepanz der Modellerkennung bei Navigator 2.0/Terra SWM; das ursprüngliche #44 ist geschlossen, aber das zugrunde liegende Erkennungsthema kann erneut auftreten). Dies ist eine bewusste Maintainer-Entscheidung, kein Versehen — hier festgehalten, damit es sichtbar bleibt. Die Gates 1, 4, 5 und 7 sind erfüllt; Gate 2 (Clean-Install-Smoke-Test) wurde im Rahmen dieses Schnitts nicht unabhängig erneut ausgeführt.

Der vorherige Beta-Zyklus (0.11.0-beta.1 bis 0.11.0-beta.8, 04.–14.08.2026) ist in docs/CHANGELOG.md erhalten, und der Zyklus 0.8.5-beta.1 bis 0.8.5-beta.8 davor bleibt in seinen historischen Nachweisdateien erhalten.

Das Stabilitäts-Audit vom Juli 2026 hat verifiziert:

vollständige Lint-, Formatierungs-, strenge Typprüfungs- und Test-Suiten in beiden Repositorys;
gruppierte Lesezugriffe nur über exakt benachbarte, sich nicht überlappende Registerbereiche;
Transport-/Keine-Antwort-Fehler können ansonsten gültige Register nicht dauerhaft deaktivieren;
registerspezifische Nicht-verfügbar-Sentinels werden als ungenutzt behandelt, nicht als beschädigt;
Zonenraum-Modi werden einzeln geprüft und nach einer Abweichung auf den sicheren Einzel-Lesepfad der API verschoben;
nicht unterstützte optionale Adressen werden isoliert, ohne unbeteiligte Werte zu verlieren;
fortgeschrittene Roh-Schreibzugriffe erfordern eine explizite Risikobestätigung und behalten Datentyp-/Numerik-Validierung.
die Protokoll-Erkennung des lokalen Web testet beide unterstützten Navigator-Familien nur, solange eine Erkennung nötig ist, speichert dann das erfolgreiche Protokoll dauerhaft und verbindet sich damit wieder, ohne zur Laufzeit die Generation zu wechseln;
die Diagnose schwärzt Modbus-/Web-Verbindungseinstellungen und den lokalen Web-PIN und reduziert detaillierte Web-Fehler auf eine sichere Fehlerkategorie.

Hardware-Nachweise (nur lesend)

Auf dem Navigator-10-System des Maintainers deckten wiederholte Batch-gegen-Einzel-Prüfungen 170 Registerdefinitionen in 45 Gruppen und 309 Vergleiche ohne rohen Unterschied ab. Die anfangs gemeldeten Werte 254, 255 und -1.0 waren in beiden Lesemodi identisch und wurden daher als registerspezifische Nicht-verfügbar-Sentinels erfasst.

Die Kaskaden-Fähigkeitssonde an Adresse 1147 lieferte roh FFFF (dekodiert UCHAR 255). Diese als nicht verfügbar zu behandeln reduzierte die erkannte Register-Map von 170 auf 153 Definitionen. Drei vollständige rein lesende Abfragen dauerten im Schnitt etwa 2,38 Sekunden; 151 Werte wurden zurückgegeben, kein Register wurde in Batch-Quarantäne gestellt und nur das von dieser Firmware nicht unterstützte Firmware-Register wurde isoliert. Diese Zahlen beschreiben ein System und sind keine universellen Leistungsgarantien.

Am 2026-08-26 lief auf der Home-Assistant-Instanz des Maintainers die Integration 0.16.0-beta.1 mit API 2.0.0b1 über den Produktions-tmodbus-Adapter. Die geschwärzte Diagnose meldete 8.836 erfolgreiche Abfragen, null Fehlschläge, eine letzte Abfrage von 12,4 ms, keine aufeinanderfolgenden Fehlschläge oder Modellkonflikte und ein verbundenes Navigator-10-Web-Supplement. Home Assistant zeigte 8 Geräte und 218 Entitäten, keine IDM-Integrations-Log-Fehler, und der Lauf führte keine Modbus-Schreibzugriffe aus. Der RC ändert nur den exakten API-Pin von der validierten Beta auf das stabile API-Artefakt und aktualisiert die Release-Dokumentation; das stabile API-Release hat keine Runtime-Änderungen gegenüber seiner Beta.

Gates für stabile Releases

Die folgenden Gates wurden für das stabile Release 0.8.5 erfüllt und bleiben die Anforderungen, die jeder künftige stabile Schnitt erneut erfüllen muss:

Die auditierte API-Version veröffentlichen, die Integration exakt auf diese Version pinnen und beide vollständigen Suites gegen das veröffentlichte Artefakt erneut ausführen.
Den Release-Smoke-Test des Repositorys auf einer sauberen Home-Assistant-Installation ausführen, einschließlich Setup, Neustart, Rekonfiguration, Diagnose, Entladen/Neuladen und sicherer Entitäts-Schreibzugriffe.
Den Navigator-2.0/Terra-SWM-Modellerkennungs-Bericht mit einem exakten, rein lesenden Sonden-Mitschnitt auflösen oder ausdrücklich klassifizieren. Die Behandlung der bloßen Anwesenheit von Adresse 4108 darf nicht auf Annahmen hin geändert werden.
Eine Bestätigung aus der Community für den Navigator-2.0-Raummodus-Batch-Fix und die Acht-Raum-Zonenkonfiguration einholen.
Handlungsfähige Diagnosen für den ungelösten Bericht zu generischen Serverfehlern einholen, statt eine Code-Änderung zu raten.
Eine Beta-Dauertestphase ohne neue bestätigte Berichte zu Datenkorruption, Reconnect-Schleifen, unsicheren Schreibzugriffen oder Setup-Regressionen abschließen.
Verifizieren, dass Release Notes, README, Wiki, Dependency-Pin, Manifest-Version und die Inhalte des generierten Pakets übereinstimmen.

Beta-Dauertest-Richtlinie

Das Dauertest-Gate bedeutet mindestens sieben aufeinanderfolgende 24-Stunden-Zeiträume auf einem unveränderten Kandidaten. Für 0.8.1-beta.31 startete die Uhr mit der Veröffentlichung am 2026-07-11T18:59:52Z; der früheste mögliche Abschluss ist 2026-07-18T18:59:52Z.

Erfasse Beobachtungen zur Veröffentlichung, ungefähr zur Halbzeit und nach den vollen sieben Tagen. Prüfe bei jeder Beobachtung neue und aktualisierte Issues sowie Hardware-Feedback. Ein bestätigtes Datenkorruptionsproblem, eine Reconnect-Schleife, ein unsicherer Schreibzugriff oder eine Setup-Regression lässt den Dauertest scheitern.

Eine Änderung am Kandidaten-Code, an Runtime-Abhängigkeiten, an der Paketierung, am Config-Flow-Verhalten, an der Abfrage oder am Schreibverhalten startet einen neuen Kandidaten und setzt die Uhr auf dessen Veröffentlichungszeitpunkt zurück. Rein dokumentarische oder nur die Nachweise betreffende Korrekturen starten sie nicht neu. Verstrichene Zeit allein genügt nicht: Die Kandidaten-Nachweise müssen zusätzlich einen bestandenen Clean-HA-Smoke-Test und eine Freigabe des Maintainers enthalten.

Nachweise melden

Füge bei einem Wert- oder Kompatibilitätsproblem den geschwärzten Diagnose-Export, Navigator- und Wärmepumpen-Modell, Firmware, Integrations-/API-Versionen, aktive Heizkreise/Zonen/Funktionen, Zeitstempel, Register-/Entitätsnamen und den Wert hinzu, den der Navigator zur gleichen Zeit angezeigt hat. Veröffentliche niemals private IP-Adressen, PINs, Seriennummern oder Kunden-/Installateursdaten.

Zur Protokolluntersuchung sollten Maintainer den exakten Function Code, die Startadresse, die Anzahl und die rohen Wörter sowohl des normalen Batch-Lesens als auch eines Einzellesens mitschneiden. Hardware-Untersuchungen sind rein lesend, außer der Besitzer hat einen bestimmten Schreibzugriff ausdrücklich autorisiert.

Mögliche Verbesserungen

Einen Opt-in-Dienst für geschwärzte Protokoll-Mitschnitte ausgewählter Register ergänzen, damit Nutzer Batch-/Einzel-Nachweise ohne eigene Skripte sammeln können.
Anonymisierte Kompatibilitätsberichte nach Navigator-Modell und Firmware dauerhaft speichern, einschließlich Fähigkeits-Sentinels.
Vorhandene Abfragedauer-/Zählerdiagnosen bei Bedarf um Zahlen einzelner Anfragen erweitern; diese Anfragezahlen werden derzeit nicht ausgegeben.
Adaptive Hinweise zum Abfrageintervall erwägen, wenn eine konfigurierte Abfrage ihr Intervall nicht zuverlässig einhält.
Die vorhandenen Climate-Entitäten für Heizkreis-, Raum- und Kühlsemantik auf weiteren Anlagen prüfen; die Plattform ist bereits implementiert.