SukramJ/homematicip_local 2.8.0b8

on GitHub

What's Changed

Integration

• Fix hub, system-variable, install-mode, virtual-remote and virtual-remote event-group entities disappearing on upgrade (frontend#63): after the move to serial-anchored hub unique_ids, the one-time re-anchor migration only matched registries anchored on the current entry_id[-10:]. A registry inherited from any other anchor (a prior entry_id after a delete + re-add, or a stale serial) fell through, no longer matched the live keys, and was then permanently deleted by the startup orphan cleanup. The migration now realigns whatever value fills the central-id slot onto the live anchor (covering plain hub keys and the virtual-remote event groups), runs before entities are recreated, and skips on a unique_id collision instead of aborting. As defence-in-depth the orphan cleanup no longer deletes an entry whose data point still exists under a different central-id anchor (it leaves the realign migration to re-anchor it), and no longer deletes the integration-native create_backup button (which has no aiohomematic data point and is recreated on every setup)
• Fix permanent mass deletion of entity-registry entries after a transient auth error (aiohomematic#3215): the startup orphan cleanup now refuses to run when it would remove more than half of the integration's registry entries — this guards against the central reporting RUNNING (clients connected) while the device descriptions failed to load, which previously wiped hundreds of entities and re-detected devices as new
• Set EventDeviceClass.DOORBELL for HmIP-DBB event entities so they work with the new Home Assistant doorbell automation trigger; all other event entities continue to use EventDeviceClass.BUTTON
• Routed the event entity device class through the EntityDescriptionRegistry (new HmEventEntityDescription, event() factory, EVENT_RULES, default for DataPointCategory.EVENT_GROUP) instead of hardcoding it on the entity class
• The openccu-loom backend (loom client + integration adapter) is bundled as groundwork for a future alternative to the direct-CCU (aiohomematic) backend, but is not user-selectable in 2.8.0: the backend master switch (LOOM_BACKEND_SELECTABLE in const.py) is off, so a fresh setup goes straight to the direct-CCU step and the loom path behaves as if it were absent. No user-facing behaviour change.

Blueprints

• The Show device error blueprint gains two optional filters — a device selector (target_devices, empty = all devices) and a comma-separated, case-insensitive ignore list of error parameters (ignored_parameters, e.g. CONFIG_PENDING, STICKY_UNREACH) — so noisy or expected errors can be suppressed without disabling the automation. The description now also explains that some errors are expected and self-resolve: after deleting a direct link (Direktverknüpfung) in the CCU/OCCU the removal is delivered to the device via a configuration transfer, and until that completes CONFIG_PENDING stays true and the link still lives in the device; for battery/RF devices the transfer only runs on the next radio contact (e.g. a button press), after which the notification clears automatically — no factory reset required (aiohomematic#3246)

Dependencies

New bundled dependency: openccu-loom-client==2026.6.24 (pins openccu-loom-types==0.1.29)

• Bundled for the not-yet-enabled openccu-loom backend (see Integration); it has no runtime effect while the backend master switch is off. Pulls openccu-loom-types==0.1.29 transitively.

Bump aiohomematic to 2026.6.8

• Keep the idle value 31 for the HmIP-FWI fingerprint reader's CODE_ID (#3238): the CCU declares the parameter maximum as 21, but the device reports 31 when idle, so the number entity dropped the idle value and could not return to 31. A paramset patch now expands the CODE_ID maximum to 31 for HmIP-FWI; the paramset cache schema is bumped to version 4 so the corrected bounds are rebuilt from the CCU
• Roll back optimistic values immediately on a failed collector send (#3238): a write the CCU rejected (e.g. an XML-RPC RESPONSE_NAK after all retries were exhausted) previously left the optimistic value active for the full 30 s optimistic_update_timeout on the collector path, so the entity kept displaying a value that never reached the device until the timeout rollback fired. The collector send path now mirrors the direct-send path and rolls back the affected data points' optimistic values immediately on a send error
• Fully fix sensors reporting a spurious 0 after a CCU restart (#3228): the initial 2026.6.3 fix only covered the ReGa bulk-load path, but the placeholder also arrived through the per-parameter getValue fallback. Three follow-ups complete it — (a) the paired *_STATUS parameter is now loaded on init so a freshly loaded default whose status is UNKNOWN no longer overwrites an already known value (#3233), (b) the bulk-load ReGa script was reworked to v2.5 because the earlier vDPValue == "" skip also dropped legitimate numeric zeros (an empty string coerces to 0 in ReGa) — it now only coerces genuine string variables and gates VirtualDevices on a valid LastTimestamp(), and (c) the getValue fallback is skipped entirely for VirtualDevices, whose aggregated ACTUAL_TEMPERATURE has no physical device behind it and could therefore only ever return the CCU default 0. The gated ReGa bulk fetch is now the single source of truth, and such a data point stays unavailable until a real reading arrives via event. Physical interfaces and real 0 readings are unaffected
• Fix HmIP-RGBW / HmIP-DRG-DALI cannot be switched on (briefly flashes, then turns off again) (#3210)
• Make interrupted device creation observable — CancelledError mid-build now logs a clear warning instead of silently abandoning the run with zero entities (#3213)
• Revert the contract/event-type extraction (#3214): public event types stay in aiohomematic.central.events, no separate aiohomematic-contract runtime dependency

aiohomematic-config remains at 2026.5.0

• No API or behavior changes for the integration since 2.7.2

homematicip-local-frontend

• Bundled homematic-config.js rebuilt; the prior 2.7.2 build already covered HA 2026.6 compatibility ("HA 2026.6 Compatibility — ha-radio Removal (#60)")