2.10.1b6

What's Changed

Integration

• Fix: system variable and program entities keep their history when their key moves onto the CCU id. Both backends used to key these two families on the slug of a renameable name, so a rename in the CCU WebUI re-keyed the entity and took its history, area and every automation with it. Both moved onto the id the CCU already carries — aiohomematic in 2026.8.8, openccu-loom in 0.68.0 — and without this pass the existing registry entries would have orphaned on that upgrade.

  The old key is reconstructed here rather than transported over the wire: the data point carries legacy_name, and the old key was the slug of it. It runs deferred, 60 s after the start and immediately before the orphan cleanup, because it needs loaded hub data — which means the freshly keyed twins already exist. That collision is resolved rather than skipped: the twin is seconds old and holds nothing, the registry entry holds the history, so the twin gives way. But a live entity binds to its registry entry once, at async_add_entities, so the historied entry the rename hands the key to has no entity behind it — which is why a migrating pass schedules one config entry reload: the entities re-bind within seconds, with their history, instead of only on the next restart. That reload is asked for once per entry and the record is kept in hass.data, which survives it; a second migrating pass logs a warning and leaves the re-bind to the next restart, because reaching it would mean the pass did not converge and reloading again would not converge either. Idempotent, and a no-op on an installation that never carried a slug key.

  The orphan cleanup that follows in the same pass now spares hub entries the migration has yet to take. Should it decline — get_hub_data_points() raising, or a data point yielding no old key — the historied entry keeps its slug key, and a hub entry has no device address, so the sweep read it as an orphan and deleted it with its history, name and area. It now rebuilds the pre-id key for every live hub data point and keeps any entry still holding one. The next start retries the migration; deletion has no next start

• Fix: CUxD entities keep their history now that their key carries the central id. CUxD hands out the same synthetic addresses on every CCU, so two CCUs bridged into one Home Assistant declared byte-identical unique_ids for their CUxD data points and Home Assistant kept only the first. aiohomematic scopes the family by central id from 2026.8.7 on, as the openccu-loom daemon always did — so every entity keyed before that adoption moves once, on both backends, because the loom client rebuilds through aiohomematic the keys the daemon does not stamp (custom data points, week profiles, the combined duration number, the device-update entity, event groups). Without the pass those entities orphan: they keep their history, area and customisations while the platform spawns freshly keyed duplicates beside them, and the orphan sweep eventually deletes the originals. Idempotent, and an installation without CUxD devices sees nothing happen

• Fix: a sub-device channel without a group master could make its device its own via device. With sub devices enabled, the via device was moved up to the Homematic device as soon as a channel reported itself as part of a multi-channel group — before the group master, which supplies the sub-device identifier, was resolved. Without a master the identifier stayed on the device, so device and via device were the same. HA used to ignore such a self-reference with a log line; since 2026.9 it raises a HomeAssistantError that no platform catches, which would take down the whole platform setup (device registry follow-up changes). The split is now conditional on the group master, so a channel without one simply stays on its device, below the central

• Fix: setup no longer retries forever against an incompatible openccu-loom daemon. Only an authentication failure had its own case, so a daemon speaking a contract this build cannot ended up on the generic "not ready" path and was retried indefinitely with nothing saying why. It is reported as a setup error now. openccu-loom backend only

Development

• Covers and sirens dispatch on aiohomematic's category protocols — GarageDataPointProtocol, TiltCoverDataPointProtocol, CoverDataPointProtocol, SoundPlayerDataPointProtocol — instead of on the concrete custom data point classes. Both backends satisfy them structurally, so these two platforms no longer decide which entity a data point becomes from the per-backend class tuples in backend_types.py. The one case the protocols do not carry stays explicit: an IP blind configured as a shutter presents no tilt and becomes a plain cover, read from operation_mode, which lives on the concrete class
• backend_types.py names the loom twin it could not find instead of failing mute, and its docstring no longer claims a mapping the backend surface contract test disproves
• Two test gaps closed. The hub key migration now runs against a real entity registry — two system variables whose names differ only in punctuation slug to one key, and the pass has to hand the history to one entity and leave the other alone — rather than against the key rebuild in isolation. And the hub singletons (alarm and service messages, inbox, connectivity, metrics, install mode), the per-device update data points, the event groups and the alarm panels are covered on spawn: they are announced through DataPointsCreatedEvent rather than enumerated in a platform's setup tail, which is why a full green suite said nothing when a change to the setup order dropped all of them mid-release
• Beyond the entries above, the integration's own changes in this release are openccu-loom backend (Beta) work; its details stay out of scope for this changelog until it leaves Beta

Dependencies

Bump aiohomematic to 2026.8.8

The manifest still pinned 2026.8.7 while CI already ran 2026.8.8 — across the very release that adopts 2026.8.8's re-keying of system variables and programs. The registry migration added for it was therefore tested against a backend that had re-keyed and would have shipped against one that had not.

tests/test_dependency_pins.py now pins the two files together, the way the sister client repository does. Bite proof: restoring 2026.8.7 in the manifest fails it by name.

Bump openccu-loom-client to 2026.8.36

• Fixes a refresh that raised instead of refreshing. On the openccu-loom backend, 2026.8.33 and 2026.8.34 failed to add any entity whose custom data point refreshes on start-up — switches, covers, lights, thermostats — because the client validated the wrong response shape for a single custom data point. Nobody should run those two versions on this backend; this release is the reason.
• CustomDPDetail is generated rather than hand-written, and it was the one hand-written model in the client's wire layer — the gap behind the regression above. The generated model requires state where the hand-written one let it be absent, which is the daemon's own contract: state is in the schema's required and is emitted without omitempty, so no payload this integration sees changes shape. The wire types are regenerated with it, purely additively — 17 new models, no removed or renamed field.
• This raises the minimum daemon to openccu-loom 0.68.1 or newer. Bump for the openccu-loom backend (Beta); it has no runtime effect on the direct-CCU backend, where the client is not loaded. The client is generated against daemon API 7.24.0, up from 7.13.0 in 2.10.0, and checks it at connect time — same major, minor at least 24 — so an older daemon is rejected outright rather than half-working. Installations that cannot update the daemon should stay on 2.10.0.
• CUxD entities re-key once; the migration that carries them is the integration entry above. The client's own key rebuild now scopes CUX* addresses by the central, matching what the daemon always emitted.
• The client no longer ships openccu-loom-types as a separate dependency — it is folded in — so this bump removes a package from the install rather than pinning one. It also floors aiohomematic at 2026.8.8, which this release already pins.
• The rest is not user-visible from here: a bootstrap that is one request instead of one per device, six admin API façades and thirteen unreachable modules removed from the wheel. The backend's details stay out of scope for this changelog until it leaves Beta.

Bump aiohomematic to 2026.8.6

• One added field, InboxDeviceData.awaiting_release, for the openccu-loom backend's onboarding states. It defaults to false and no direct-CCU path sets it

Bump aiohomematic-config to 2026.8.1

• Packaging and tooling only, no behaviour change: the package raises its own aiohomematic requirement to >=2026.8.5, is marked production/stable, and updates its development dependencies