SukramJ/homematicip_local 2.11.2b5

on GitHub

What's Changed

Integration

• openccu-loom: connect through an openccu-lite box. A daemon running
  on an openccu-lite box (openccu-lite 1.0.0-dev.36 or newer) can now be
  reached through the box's web server (https://<box>/addons/loom/), so
  the daemon port may stay firewalled — and no box password is stored.
  Both loom setup forms (manual and discovered) grow a switch "Through an
  openccu-lite box": switched on, Home Assistant pairs with the box, the
  box's administrator compares the six-digit code on the box's status page
  and approves, and the entry keeps only the box token (scope
  addon:openccu-loom, operator rights in the daemon). A box token created
  on the box's token page can be pasted in the setup form instead, and then
  no pairing runs. Host and TLS then describe the box; the daemon port
  field is unused, and an API token beside the box token is refused. The
  options flow takes a box token from the box's token page as well. When
  the box later refuses the token —
  revoked, or without the add-on's scope — Home Assistant asks to
  reauthenticate, which pairs with the box again. Requires
  openccu-loom-client 2026.10.4 and OpenCCU-Loom 0.84.1 (API 13.3.0);
  0.84.1 is the daemon release that lets a program pair with it at all.

• openccu-loom: the daemon port and TLS hints are right. The port
  field said a blank port means 8443 with TLS and 8080 without; the client
  uses 8119 either way. The TLS switch now explains that the daemon serves
  plain HTTP out of the box — with TLS on against it, the connection
  failed with a cannot-connect error.

• Fix: diagnostics no longer carry the openccu-loom API token. The
  daemon bearer token of a loom entry was not on the redaction list, so a
  downloaded diagnostics file included it in clear. It is redacted now,
  together with the openccu-lite box token.

• 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

• Breaking: Home Assistant 2026.9 or newer is required (was 2026.8). The integration builds its schemas with probatio, the validation library Home Assistant ships from 2026.9 on and types its own helpers against from 2026.10. Validation behaves as before: since 2026.9 Home Assistant aliases voluptuous to probatio's compatibility shim at startup, so the integration's schemas and Invalid were already probatio objects at runtime — importing probatio directly makes the integration independent of that alias and type-checks its schemas against the types Home Assistant declares. The repair flow's steps are typed with RepairsFlowResult, the result type RepairsFlow declares

Dependencies

Bump openccu-loom-client to 2026.10.4

• Bump for the openccu-loom backend (Beta); it has no runtime effect on the direct-CCU backend, where the client is not loaded. It regenerates the wire bindings against daemon api 13.3.0 (openccu-loom 0.84.0), brings the box-token ingress and box pairing the openccu-lite box connection above needs, and reports an unreachable daemon during pairing as a connection error the setup form shows. Kept to one line: loom details stay out of scope while the backend is Beta

Bump ruff to 0.16.10

• Development only (pin and pre-commit rev). mypy stays at 2.3.1, the version Home Assistant core pins

Bump openccu-data to 2026.9.1

• The release adds CCU WebUI device images to the repository tree only — they are not part of the Python package — so nothing reaches this integration at runtime. Bumped so the manifest pin and the test requirement name the same version

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
• pylint 4.0.9 → 4.1.1 in requirements_test.txt. The device-action schema test no longer reaches the schema library through cv.vol: Home Assistant 2026.10 no longer re-exports it from config_validation
• pytest-homeassistant-custom-component-framework 1.0.56 → 1.0.57, which brings Home Assistant 2026.10.0b0. Its schema types moved from voluptuous to probatio, which mypy reported as 308 errors in four files; integration and tests import probatio directly now