Skip to content

2.9.1

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 10 Aug 20:05
2.9.1
4d2fd7f

☕ Support This Project

If you find this integration useful, consider supporting its development:

GitHub Sponsors

Ko-fi

Your support helps maintain and improve this integration. Thank you! 🙏

What's Changed

Dependencies

Bump aiohomematic to 2026.8.2

  • Fix the calculated sensors (DEW_POINT, VAPOR_CONCENTRATION, FROST_POINT, ENTHALPY, DEW_POINT_SPREAD, APPARENT_TEMPERATURE, OPERATING_VOLTAGE_LEVEL) freezing on their restored state after the update to 2026.8.1, while the underlying temperature and humidity entities kept updating (#3343). Their source data points were resolved lazily on first value access, which the climate sensors never triggered — and with the stricter validity gating of 2026.8.1 an unresolved source set reported is_valid=False. Home Assistant reads validity before the value, so it kept serving the restored state and never performed the read that would have resolved the sources; the per-source update subscription is created during that same resolution, so no source update reached the calculated data point either. Sources are now resolved when the calculated data point is constructed. The regression affects every installation running 2.9.0 — updating is recommended for all installations
  • The change is backed by a new contract test in aiohomematic that pins source resolution and subscription at construction time, so a calculated data point can report its validity without a prior value read

Bump openccu-loom-client to 2026.8.9 (pins openccu-loom-types==0.3.10)

  • Bump for the openccu-loom backend (Beta); it has no runtime effect on the direct-CCU backend, where the client is not loaded. Advances the bundled loom client from 2026.8.6 to 2026.8.9 and its transitively pinned openccu-loom-types from 0.3.3 to 0.3.10. It raises the minimum daemon to openccu-loom 0.57.0 or newer — the client refuses to connect to a lower API minor rather than half-initializing against it

Development

  • The openccu-loom backend (Beta) hands its CCU, diagnostics and configuration surfaces to the daemon, which owns that state and covers it for every CCU it serves: the config panel is no longer registered for loom entries, and their device pages link to the daemon's own Config UI instead. Entries on the direct-CCU backend are unchanged — the panel is registered once for the whole integration, so a mixed installation keeps it. The user-facing details stay out of scope for this changelog until the backend leaves Beta
Assets 2
Loading