SukramJ/homematicip_local 2.8.3b3

on GitHub

What's Changed

Integration

• Expose the HmIP-DSD-PCB doorbell sensor's event with the doorbell event device class instead of the generic button (#3276). Its ring input channel produces an event group that previously fell back to the button default; it now matches the doorbell rule alongside the HmIP-DBB
• Expose color temperature for the HmIP-LSC (#3277). supported_color_modes now also honours the light's static color capabilities (capabilities.hs_color/capabilities.color_temperature), so a light that supports both color and color temperature — like the HmIP-LSC, which has no DEVICE_OPERATION_MODE and switches between the two at runtime — advertises {hs, color_temp} statically while color_mode keeps reporting the currently active mode via has_*. Lights with a single, mode-based color capability are unaffected
• Fix light.turn_on not switching the HmIP-LSC from color to color temperature (#3277). async_turn_on treated the two color modes as independent and, when only a color temperature was requested, still forwarded the current hs_color — so HUE/SATURATION and COLOR_TEMPERATURE were written together in one putParamset and the device kept the old color. The modes are now mutually exclusive: an explicit color_temp_kelvin or hs_color request is sent on its own, and the current value is only restored when no color is requested

Dependencies

Bump aiohomematic to 2026.7.5

• Fix the climate entity for HmIP-WTH-B (and other thermostats) failing to load — staying permanently unavailable — when the device's SETPOINT paramset description is incomplete (missing MAX, e.g. after a failed getParamsetDescription) (#3281). max_temp returned None, so caching the week profile raised an uncaught TypeError out of Home Assistant's entity setup, while an identical device with a complete paramset description worked fine. max_temp now falls back to a fixed upper bound (30.5) when neither a TEMPERATURE_MAXIMUM value nor a SETPOINT MAX is available (mirroring the existing min_temp guard), and the week-profile conversion now degrades gracefully — the entity loads and only the schedule stays uncached
• Internal aiohomematic simplification (−5,800 LOC) from a consumer-surface audit against this integration: removes the unused hmcli console script, the HomematicAPI facade, SysvarStateChangedEvent, the tracing / logging_context modules and the Kind/payload property-metadata subsystem, and flattens 37 zero-use interface protocols (120 → 83). Every removed symbol was verified to have zero usage in homematicip_local, so there is no user-facing effect
• Fix valve-only HmIP-HEATING groups (built from HmIP-eTRV valves without a wall thermostat) freezing current_temperature / current_humidity at the last-(re)start value (#3279). Follow-up to #3255: these groups always expose HUMIDITY and HEATING_COOLING on the group channel, but only a group containing a wall thermostat (HmIP-WTH/STHD) ever receives events for them — in a valve-only group those readable data points never refresh, and since #3228 VirtualDevices get no getValue fallback, so they dragged the whole custom climate data point to is_valid=False (leaving the climate entity in value_state=restored with a frozen current temperature) even though ACTUAL_TEMPERATURE kept arriving via events. #3255 only excluded the actuator values LEVEL / STATE; the climate validity check now also ignores HUMIDITY / HEATING_COOLING, so a group's climate validity follows its aggregated ACTUAL_TEMPERATURE regardless of whether a wall thermostat is present
• HmIP-LSC now exposes color temperature in addition to color (#3277): a dedicated CustomDpIpRGBWColorTempLight advertises both color modes statically and derives the active mode from the value the device reports