v1.2.6: Heat Pump DHW Mode, Blueprints & Solar Fixes

[1.2.6] - 2026-03-08

Added

• DHW mode support for air-to-water heat pumps. Units that periodically switch to domestic hot water production now have a dedicated MODE_DHW state. During a DHW cycle the heat pump delivers zero heat to the space; the model correctly observes this as zero contribution and learns accordingly. The previous behaviour treated DHW like MODE_OFF (skipping the learning update entirely), which caused systematic upward drift in the learned coefficient proportional to the DHW duty cycle — equivalent to a heating-cable hysteresis error. Setting a unit to MODE_DHW eliminates the drift at all learning rates. At the default learning rate (1%) the steady-state oscillation amplitude stays within ±7% of the true coefficient even in extreme DHW-heavy operating profiles.
• Blueprints for automatic mode state mapping are now included in the repository under blueprints/. heat_pump_mode_sync.yaml maps a heat pump's operation mode sensor (Heating / Domestic Hot Water / Defrost) to the Heating Analytics mode select helper automatically — Defrost is handled transparently by preserving the current mode so defrost energy is attributed to the active heating or DHW cycle. climate_sync.yaml maps standard climate entity states (heat / cool / off) to the mode helper, with an optional guest mode prefix for tracking occupancy separately.
• Solar screen transmittance floor (MIN_SOLAR_TRANSMITTANCE = 0.20). The previous screen correction applied a pure linear scale (effective = correction_percent / 100), collapsing the effective solar vector to zero when all screens were closed. This suppressed solar-coefficient learning (the vector_magnitude ≤ 0.01 guard in the learning engine returns early when the vector is near-zero) and forced the base thermal model to silently absorb residual solar gain as a systematic downward bias in temperature-bucket coefficients. Physically, a closed screen still transmits ~10–15 % of solar irradiance through its fabric (G-value/SHGC), and unmonitored windows without screens contribute additional baseline gain. The new formula effective = MIN + (1 − MIN) × (correction_percent / 100) ensures the effective vector stays non-zero at all screen positions. At 0 % open: effective = 0.20; at 100 % open: effective = 1.0 (unchanged). Existing learned solar coefficients were calibrated against the old scale and will converge to corrected values via EMA (lr = 0.01) over a few weeks of sunny weather — no manual reset required.

Fixed

• Multiple instances share the same storage file. The storage key was the fixed string heating_analytics.storage, causing all instances on the same HA installation to read and write the same file — each restart overwrote the other's learned model with its own data. Each StorageManager instance now uses a per-entry key (heating_analytics.storage_<entry_id>). On first load with the new code, a one-time migration from the legacy shared file is attempted only if the stored daily_history contains at least one sensor that is also configured for the instance — a mismatch means the stored data belongs to a different instance, so that instance starts fresh instead. Existing single-instance installations migrate their learned data automatically; new or secondary instances start with a clean slate.
• Config flow blocks submission when switching source to "Weather Entity" ("Ikke alle obligatoriske felt er fylt ut"). Four root causes: (1) HA's frontend validates vol.Required fields before submitting to Python. When the user switched the source dropdown from Dedicated Sensor to Weather Entity, the now-irrelevant sensor EntitySelector remained visible on the form (config flow does not re-render on dropdown change) and its vol.Required marker blocked submission entirely — the backend reload logic never ran. Fixed by declaring outdoor temperature and wind speed sensor fields as vol.Optional in the schema; required validation for SOURCE_SENSOR mode is enforced in _validate_weather_fallback instead. A backend reload condition is also added so the form re-renders on the next submit to hide the unneeded field. (2) wind_speed_sensor had no backend required-validation when SOURCE_SENSOR was selected; the check existed for outdoor_temp_sensor but not for wind speed. Added the symmetric check. (3) Switching back to Dedicated Sensor after a prior Weather Entity save showed "Entity None is not a valid entity ID" because the sensor key was stored as None. Fixed by omitting the default kwarg when the stored value is falsy. (4) The None value also lingered in entry.data when HA/voluptuous silently dropped an absent Optional key on a re-save. Fixed by popping all four optional entity keys (outdoor_temp_sensor, wind_speed_sensor, wind_gust_sensor, secondary_weather_entity) from new_data when absent or falsy, rather than only handling secondary_weather_entity.