SukramJ/homematicip_local 2.10.1b3

on GitHub

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, with the orphan cleanup and before it, 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. Idempotent, and a no-op on an installation that never carried a slug key

• 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

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

• This raises the minimum daemon to openccu-loom 0.67.0 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.23.0, up from 7.13.0, and checks it at connect time — 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, and the migration for it is in this release. The client's own key rebuild now scopes CUX* addresses by the central, matching what the daemon always emitted; without the pass those entities would have orphaned instead of moving. An installation without CUxD devices sees nothing.
• 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