Stability & Release Readiness

This page records what has been verified, what remains uncertain and what had to be true before the beta label was removed. It is deliberately stricter than a normal changelog.

Current Status

The published stable channel is 0.19.0, the stable cut of the line that ran through sixteen betas. It makes the Navigator 1.0/1.7 family a full citizen — the complete official holding block, a firmware-honest range guard, the capture-verified FW030 float setpoint and a water heater card — and adds PV visibility (issue #353), the solar thermal opt-out, the per-register diagnostics report, a more honest AI adviser and the German wiki mirror. The 0.17.x/0.16.x decisions below remain as published.

For the stable cut, automated CI (including the real-Home-Assistant smoke leg), HACS, Hassfest, security checks, release packaging, published checksum verification and package-to-tag comparison passed. 0.19.0-b15 ran on the maintainer's production plant with a clean log, and the Navigator 1.0/1.7 register corrections were confirmed by a tester's post-update diagnostics on the released version (issue #364). The b16 water-heater addition is covered by the automated suite; the 1.x register map itself rests on the official documentation confirmed by two independent hardware captures.

Earlier release decisions

0.17.2-b6/0.18.0: automated CI, HACS, Hassfest, security checks, release packaging, published checksum verification and package-to-tag comparison passed for the candidate. The read-only running-plant observation in the September 18 audit used beta 5; it was not hardware validation or a seven-day soak of beta 6. The candidate record captured the pre-publication state.

0.17.0 is the stable cut of the line that opened with 0.17.0-beta.1 on 2026-09-09. It carries the full code-audit result, the model-reconciliation corrections of beta.3 and the Navigator 1.0/1.7 protocol family of beta.4, on idm-heatpump-api 2.1.1 and modbus-connection 4.11.1.

Maintainer decision on 0.17.0: the stable tag was cut on 2026-09-13, the day 0.17.0-beta.4 was published, so gate 6 (seven consecutive 24-hour periods of soak on an unchanged candidate) was not satisfied for beta.4 — although beta.1 through beta.3 had been in the field since 2026-09-09 with no regression report. Gate 3's live hardware follow-up remains open twice over: no Navigator 1.0/1.7 device is maintainer-owned (the call for testers is #319), and the KNX bridge's physical-bus verification is unchanged from 0.16.0. Automated preflight, dependency-pin freshness and the full CI matrix did pass, and a read-only model-detection probe against the maintainer's Navigator 10 on 2026-09-13 confirmed the new detection does not misclassify a shared-family controller. This is a conscious maintainer call taken at release time, not an oversight — recorded here and in docs/release-evidence/0.17.0.md so it stays visible.

Integration 0.19.0 and idm-heatpump-api 2.6.0 form the current exactly pinned integration/API pair. The API version is written in PEP 440 form because that is what pip resolves; the integration keeps SemVer tags for HACS. Up to and including 0.14.1 the direct socket was pinned to modbus-connection==4.0.0a3 with tmodbus==0.5.0.

0.16.0 drops pymodbus entirely — a breaking change, and the reason the line opened with a beta. idm-heatpump-api 2.0.0 owns its own exception hierarchy (IdmModbusError and subclasses) instead of inheriting from pymodbus, and moves its built-in Modbus TCP transport behind an optional extra. This integration injects a tmodbus-backed transport, so it now installs no Modbus stack it does not speak. The transport pins are modbus-connection==4.12.2 and tmodbus[async-serial]==0.6.2.

0.17.0-beta.2 removes one thing 0.17.0-beta.1 introduced: the repair issue for a register the heat pump does not implement. A controller that answers Illegal Data Address for, say, firmware_version is behaving normally — that model, firmware or hardware option simply lacks the function — but a warning card in Settings → Repairs reads like a defect, and it asked for an action that does not exist. The explanation stays, as a log line and in the diagnostics download. Everything else is identical to 0.17.0-beta.1; the soak clock restarts because the code changed.

0.17.0-beta.1 is the first candidate of the 0.17.0 line and carries the result of the code audit in docs/dev/code-audit-2026-09.md. Eight bugs are fixed, among them a poll that outlived its config entry, a failed setup that left live entities behind, a second heat pump behind one Modbus gateway that could no longer be added, forwarded temperatures that were not converted to degrees Celsius, and sentinel readings that reached a temperature state. Six robustness items and three performance items came with them, plus the extractions that made the affected code testable: model_resolution.py for the model reconciliation and a public coordinator surface for the seven modules that used to reach into its private attributes. Both runtime pins moved forward (modbus-connection 4.11.1, idm-heatpump-api 2.0.1); no register map or entity identifier changed. It is a beta because the audit touched model detection, setup and teardown, write-enabled entities and services, and because the dependency change restarts the soak clock.

0.16.2 is a patch on 0.16.1: validate_overrides accepted a KNX group-address override that claimed the derived address (base + object number) of another served object, and the bridge then routed that address to only one of the two registers. Address resolution and the KNX options step now refuse any address claimed twice. tmodbus[async-serial] moved from 0.6.1 to 0.6.2; no register or entity changed.

0.16.1 is a patch on 0.16.0: with the local web supplement pointed at an IP address, the integration closed a Home Assistant aiohttp session instead of detaching it, which Home Assistant reports in the log and which reaches into a connector shared with every other integration. The per-IP session is now released with detach() and created with auto_cleanup=False so a rebuilt web client does not leave the old one pinned until Home Assistant stops. Nothing else changed — registers, entities, the KNX bridge, the write guards and the runtime pins are identical to 0.16.0.

0.16.0 is the stable cut of that line, identical in code to 0.16.0-rc.6. Its headline feature is the experimental KNX bridge: the integration serves the 654 IDM KNX communication objects itself, through the Home Assistant knx integration, so the Weinzierl KNX IP BAOS 774 gateway module is no longer needed. The bridge is opt-in and off by default, and its physical-bus behaviour remains unverified — see the open gates below.

Maintainer decision on 0.16.0: the stable tag was cut on 2026-08-28, one day after 0.16.0-rc.6 was published, so gate 6 (seven consecutive 24-hour periods of soak on an unchanged candidate) was not satisfied — its earliest eligible completion was 2026-09-03. Gate 3's live KNX follow-up (physical group-address telegram interoperability and first-export bus load) and Navigator 2.0/Pro hardware coverage also remain open. Automated preflight, dependency-pin freshness and the RC5/RC6 live smoke evidence on the maintainer Navigator 10 did pass. This is a conscious maintainer call taken at release time, not an oversight — recorded here and in docs/release-evidence/0.16.0.md so it stays visible.

0.16.0-rc.6 retains RC5's latest-value KNX queue and adds startup recovery for the event filter. Home Assistant can expose the KNX services before its KNX runtime is ready; the bridge now retries only the missing group-address batches instead of requiring a manual IDM reload. The write guards and configurable 60-second EEPROM default are unchanged. Physical group-address telegram interoperability and bus load remain open.

0.15.1 was the last line with pymodbus: it pinned idm-heatpump-api 1.0.3, moved the transport pair to modbus-connection==4.12.2 / tmodbus[async-serial]==0.6.2, and carried the write-diagnostics work from #237.

0.15.0 moved that pair to modbus-connection==4.8.1 and tmodbus[async-serial]==0.5.1, adds room temperature sensors for all heating circuits (A–G) via idm-heatpump-api, connection-pacing options, NC contact inversion and orphaned sensor cleanup. It closes the 0.15.0-beta.1 through 0.15.0-beta.3 cycle. Hardware smoke evidence for the cycle is recorded in docs/release-evidence/0.15.0-beta.2.md; the stable cut is recorded in docs/release-evidence/0.15.0.md.

Maintainer decision on 0.15.0: the stable tag was cut on the same day 0.15.0-beta.3 was published, so gate 6 (seven consecutive 24-hour periods of soak on an unchanged candidate) was not satisfied, and no signed clean-Home-Assistant smoke test exists for the stable candidate itself (gate 2). Automated preflight, dependency-pin freshness and the beta-cycle hardware verification did pass. This is a conscious maintainer call taken at release time, not an oversight — recorded here and in docs/release-evidence/0.15.0.md so it stays visible.

idm-heatpump-api 1.0.2 expanded the optional local web client to map heating-circuit room temperatures B61–B67 (room_temperature_HK_A through G), verified live on a Navigator 10 ALM 6-15 (B64 = 21.8 °C). 1.0.3, the version 0.15.0 pins, is a maintenance release of that library: it carries CI and security-toolchain updates only and its public behavior is identical to 1.0.2.

Maintainer decision on the stable-release gates below: 0.11.0 was published as stable without waiting out gate 6 (the seven-day soak, reset by the 0.11.0-beta.7/beta.8 candidate changes shipped the same day) and without closing gate 3's live follow-up, #192 (a Navigator 2.0/Terra SWM model-detection display mismatch; the original #44 is closed, but the underlying detection topic has an open recurrence). This is a conscious maintainer call, not an oversight — recorded here so it stays visible. Gates 1, 4, 5 and 7 are satisfied; gate 2 (clean-install smoke test) was not independently re-run as part of this cut.

The previous beta cycle (0.11.0-beta.1 through 0.11.0-beta.8, 04.–14.08.2026) is preserved in docs/CHANGELOG.md, and the 0.8.5-beta.1 through 0.8.5-beta.8 cycle before it remains preserved in its historical evidence files.

The July 2026 stability audit verified:

• full lint, formatting, strict type checking and test suites in both repositories;
• grouped reads only across exactly adjacent, non-overlapping register ranges;
• transport/no-response errors cannot permanently disable otherwise valid registers;
• register-specific unavailable sentinels are treated as unused rather than corrupt;
• zone-room modes are individually checked and moved to the API's safe individual-read path after a mismatch;
• unsupported optional addresses are isolated without losing unrelated values;
• advanced raw writes require explicit risk acknowledgement and retain datatype/numeric validation.
• local web protocol discovery tests both supported Navigator families only while detection is needed, then persists and reconnects the successful protocol without runtime generation switching;
• diagnostics redact Modbus/web connection settings and the local web PIN, and reduce detailed web failures to a safe error category.

Read-only Hardware Evidence

On the maintainer Navigator 10 system, repeated batch-versus-individual checks covered 170 register definitions in 45 groups and 309 comparisons without a raw mismatch. The initially reported values 254, 255 and -1.0 were identical in both read modes and were therefore recorded as register-specific unavailable sentinels.

The cascade capability probe at address 1147 returned raw FFFF (decoded UCHAR 255). Treating that as unavailable reduced the detected register map from 170 to 153 definitions. Three complete read-only polls averaged about 2.38 seconds; 151 values were returned, no register was batch-quarantined and only the firmware register unsupported by that firmware was isolated. These numbers describe one system and are not universal performance guarantees.

On 2026-08-26 the maintainer Home Assistant instance ran integration 0.16.0-beta.1 with API 2.0.0b1 through the production tmodbus adapter. The redacted diagnostics reported 8,836 successful polls, zero failures, a 12.4 ms last poll, no consecutive failures or model conflict, and a connected Navigator 10 web supplement. Home Assistant exposed 8 devices and 218 entities, showed no IDM integration log errors, and the run performed no Modbus writes. The RC only changes the exact API pin from the validated beta to the stable API artifact and updates release documentation; the API stable release has no runtime changes from its beta.

Stable-release Gates

The following gates were satisfied for the 0.8.5 stable release and remain the requirements any future stable cut must meet again:

1. Publish the audited API version, pin the integration to that exact version and rerun both complete suites against the published artifact.
2. Run the repository release smoke test on a clean Home Assistant installation, including setup, restart, reconfigure, diagnostics, unload/reload and safe entity writes.
3. Resolve or explicitly classify the Navigator 2.0/Terra SWM model-detection report with an exact read-only probe capture. Address 4108 presence alone must not be changed from assumptions.
4. Obtain community confirmation for the Navigator 2.0 room-mode batch fix and eight-room zone configuration.
5. Obtain actionable diagnostics for the unresolved generic server-error report instead of guessing at a code change.
6. Complete a beta soak period without new confirmed data-corruption, reconnect-loop, unsafe-write or setup-regression reports.
7. Verify release notes, README, Wiki, dependency pin, manifest version and generated package contents agree.

Beta Soak Policy

The soak gate means at least seven consecutive 24-hour periods on one unchanged candidate. For 0.8.1-beta.31, the clock started at publication on 2026-07-11T18:59:52Z; the earliest possible completion is 2026-07-18T18:59:52Z.

Record observations at publication, around the midpoint, and after the full seven days. At each observation, review new and updated issues and hardware feedback. A confirmed data-corruption problem, reconnect loop, unsafe write, or setup regression fails the soak.

A change to candidate code, runtime dependencies, packaging, config-flow behavior, polling, or write behavior starts a new candidate and restarts the clock at its publication time. Documentation-only or evidence-only corrections do not restart it. Elapsed time alone is insufficient: the candidate evidence must also contain a passing clean-HA smoke test and a maintainer sign-off.

Reporting Evidence

For a value or compatibility problem, include the redacted diagnostics export, Navigator and heat-pump model, firmware, integration/API versions, active circuits/zones/features, timestamp, register/entity name and the value shown by the Navigator at the same time. Never publish private IP addresses, PINs, serial numbers or customer/installer data.

For protocol investigation, maintainers should capture the exact function code, start address, count and raw words for both the normal batch and an individual read. Hardware investigation is read-only unless the owner has explicitly authorized a specific write.

Candidate Improvements

• Add an opt-in redacted protocol capture service for selected registers so users can gather batch/individual evidence without custom scripts.
• Persist anonymized compatibility reports by Navigator model and firmware, including capability sentinels.
• Add poll timing/request counts to diagnostics to expose slow controllers and over-configured zone setups.
• Consider adaptive scan guidance when a configured poll cannot reliably finish within its interval.
• Keep a climate entity deferred until IDM circuit/room/cooling semantics can be represented without hiding important controller state.