SukramJ/homematicip_local 2.11.2b2

on GitHub

What's Changed

Integration

• openccu-loom: pair instead of pasting a token. Both loom setup forms
  (manual and discovered) grow a "Pair with the daemon" switch: the flow
  shows a six-digit code, the daemon's administrator types it on the
  daemon's tokens panel, and the approved token flows into the entry
  exactly as a pasted one would — including the single-CCU auto-selection.
  Rejected, expired, switched-off pairing and a certificate mismatch each
  return to the form with a clear error. Paired tokens carry the operator
  role; the form says which features (backups, system update, device
  removal) still need a pasted admin token. Requires openccu-loom-client
  2026.9.8 and an openccu-loom daemon ≥ 0.81.0; on an older daemon the
  switch reports that pairing is unavailable and the token paste keeps
  working.

• openccu-loom: a daemon 403 now says what to do. With an
  operator-role token, the admin-tier surfaces (create backup everywhere
  it is offered, install the system update, clear caches/incidents,
  record a session, remove a device) answered a generic failure, an
  unhandled traceback, or nothing at all. Every one of them now names the
  cause and the fix: create an admin token on the daemon and update the
  integration's token. Removing a device also no longer dies on a
  call-shape mismatch before the daemon was ever asked (fixed in
  openccu-loom-client 2026.9.8; the contract exemption is gone).

• Fix: a connection_failed repair stayed after the connection was healthy again. Moving the CCU to a different host is the ordinary way there — the interfaces fail, their repairs appear, the entry is reconfigured onto the new address — and afterwards the repairs stayed visible next to connection sensors reading on, with every device operating normally. Nothing short of deleting and re-adding the integration took them back.

  The repair is raised from a connection_state event and withdrawn by the opposite one, and that one is published only for an interface the central's connection state tracker actually holds (CentralConnectionState.remove_issue). That tracker belongs to the central, so it is rebuilt empty with every setup of the config entry — a reload, a reconfigure, a restart. Whatever a previous session left in the issue registry, which does survive all three, therefore had nobody left to withdraw it.

  The startup cleanup that already handled the other transient repair types covers connection and callback now. It runs before the central starts, so an interface that is still down raises its repair again within seconds. client is deliberately left out of it: a fresh client always transitions to CONNECTED, and that transition withdraws the repair on its own.

• Callback repairs are withdrawn by sweeping the issue registry instead of rebuilding every id from {instance_name}-{interface}. That composition is the aiohomematic interface id; on the openccu-loom backend the daemon names the leading component itself, so a callback repair raised there was never addressed by the id the integration built for it. Both halves go through one helper now — support.get_issue_id composes the id, and the sweep matches the prefix that helper produces — so the two cannot drift apart

• Four issue types the startup cleanup carried as legacy (pending_pong_mismatch, unknown_pong_mismatch, interface_not_reachable, xmlrpc_server_receives_no_events) are gone from it. They could never have matched anything: repairs of that generation were keyed {interface_event_type}-{interface_id}, so the id carries no entry id in front — which the cleanup requires as a prefix — a hyphen where it looks for an underscore, and the interface event type where the list names the translation key

• Fix: the button blueprints asked the CCU for direct links on every keypress, even with the warning switched off. Warn if direct connections exist in CCU defaulted to on, so an automation that had never stored a value for that input inherited it — the option looked off in the automation editor while the CCU round trip ran ahead of every action. That made the guard added in 2.11.0 ineffective for exactly the automations that never touched the option, and it is the delay reported in #3402: the action can never be faster than the CCU answers, and that answer time swings from milliseconds to seconds.

  The option defaults to off now in all five blueprints that carry it (2-, 6-, 8-button, key ring remote control, and the 6-button one in blueprints/community), and its description says what enabling it costs. Re-import the blueprints to pick this up. An automation that has an explicit true stored keeps it — the default only applies where nothing was ever saved — so if you want the warning gone there, switch the option off and save

Dependencies

Bump aiohomematic to 2026.9.4

• Fix: BidCos-RF data points stayed on restored after a start. The ReGa bulk fetch is the only source of an initial value on the interfaces without a per-parameter getValue fallback (BidCos-RF, VirtualDevices, CUxD, CCU-Jack), and its snapshot is taken once during start_clients() and expires after MAX_CACHE_AGE. Its consumer for any channel but 0 is the integration adding its entities, which happens after the platforms have been forwarded — in a real installation reliably later than that, so the snapshot was gone by then and the data point stayed unset for good. Covers were the visible case, because a shutter reports nothing until it is moved: HM-LC-Bl1PBU-FM blinds sat at value_state=restored with current_position: 0 until they were operated by hand. The init path refreshes an expired snapshot now instead of giving up; the getValue fallback stays disabled

• Fix: battery and diagnostic data points stayed on restored after a start. Parameters on the init ignore list (LOW_BAT, LOWBAT, OPERATING_VOLTAGE, DUTY_CYCLE, DUTYCYCLE, the ERROR_*, RSSI_* and *_ERROR patterns, and every data point of HmIP-SWSD* / HmIP-SWD) skip the per-parameter getValue on purpose so a battery-powered device is not woken, which leaves the bulk snapshot as their only source — and this path read it without refreshing it first. Unlike a cover's LEVEL these do not recover on their own: LOW_BAT is sent only when it changes, so a device that reported a low battery before the start kept showing a normal one until the battery was replaced. This affected every interface, not only those without the fallback

• Fix: a fresh snapshot for one interface skipped the others. CentralDataCache.load() left the loop over all clients with return instead of continue when it hit a recently refreshed interface, so every client behind it was never loaded

• Fix: changed_within_seconds() ignored whole days. It read timedelta.seconds, which drops the day part, so a change from exactly 24 h ago counted as recent

• MAX_CACHE_AGE is 15 s instead of 10 s. It governs the lifetime of the central data cache, the device details cache refresh guard (MAX_CACHE_AGE / 3) and the default staleness window of changed_within_seconds()

Bump aiohomematic to 2026.9.3

• Fix: devices stayed unavailable after a reconnect. A device that became reachable again while the connection to the CCU was down — the CCU restarts and resets the flag, or the device recovers while the proxy is gone — stayed unavailable in Home Assistant for as long as the central ran. Events flowed and commands worked; the entities of that device remained greyed out until the integration was reloaded or homematicip_local.force_device_availability was applied by hand.

  The CCU announces UNREACH only when the value changes, so that recovery transition is never delivered after such an outage. Nothing closed the gap afterwards: UN_REACH and STICKY_UN_REACH are hidden parameters and carry DataPointUsage.NO_CREATE, which is exactly what the recovery data load skips — it iterates the readable generic data points — while the one path that does read them over RPC runs only for newly created devices.

  The connection recovery re-reads the channel 0 VALUES paramset of every device on the interface now and applies UN_REACH, STICKY_UN_REACH and CONFIG_PENDING through the regular event path, in the staged data load as well as in the circuit-breaker recovery. It reads them with getParamset rather than the per-parameter getValue fallback, because that fallback is skipped on BidCos-RF, VirtualDevices, CUxD and CCU-Jack — building on it would have produced a fix that does nothing on four of six interfaces. A read that fails, or a paramset that does not carry the parameter, leaves the data point untouched instead of defaulting it: a boolean without a value falls back to false, so a swallowed read error would have reported every unreachable device as reachable

Development

• aiohomematic-test-support 2026.9.2 → 2026.9.4, following the aiohomematic pin above — CI runs against requirements_test.txt, so the two move together
• ruff 0.16.6 → 0.16.7, in the prek hook revision and in requirements_test_pre_commit.txt, which have to name the same version