Adaptive Cover Pro ⛅ v2.28.0-beta.11

ℹ Using release notes from: release_notes/v2.28.0-beta.11.md
Beta.11 is a single-fix release: it makes the custom-position sensor migration that shipped in beta.10 actually run. The migration code in __init__.py's async_migrate_entry was correct but unreachable — MINOR_VERSION in ConfigFlowHandler (config_flow.py) was still 2, so Home Assistant never triggered entry migration for configs sitting at minor version 3.2. Raising MINOR_VERSION to 3 unblocks the gate and causes the v3.2 → v3.3 step to execute on next restart.

🎯 Highlights

Beta — please test and report back.

• If you had a custom-position slot configured before beta.7 (#563), upgrade to beta.11 and confirm your previously-configured sensor now appears in the multi-select "Sensors" field for that slot.
• Verify no custom-position data is lost: the migration is additive — the legacy custom_position_sensor_N key is kept alongside the new list key.
• Confirm that a rollback to beta.10 leaves the config entry intact and functional.
• Check that custom-position slots configured after beta.7 (which already use the list key) are unchanged by the migration.

🐛 Fixes

MINOR_VERSION gate was blocking the custom-position sensor migration (#563, #607)

The beta.10 migration that copies a legacy single-sensor custom_position_sensor_N value into the new multi-sensor list key lived in async_migrate_entry in __init__.py. It was never reached because MINOR_VERSION on ConfigFlowHandler in config_flow.py was 2 — one short of the 3 that Home Assistant requires to consider a config entry eligible for the v3.2 → v3.3 migration step. Entries created or last migrated at minor version 3.2 sat there indefinitely; the migration was dead code.

The fix is a one-line bump: MINOR_VERSION = 3. On the next restart, Home Assistant sees the entry is behind the current minor version, calls async_migrate_entry, and the v3.3 step runs. Users who upgraded to beta.10 and found their "Sensors" multi-select empty will see their legacy sensor restored without any manual reconfiguration. The migration remains additive and rollback-safe.

A regression test — test_config_flow_minor_version_reaches_highest_migration_target in tests/test_config_entry_migration.py — asserts that MINOR_VERSION always equals the highest migration target, so this class of mistake is caught in CI going forward.

Previously in this beta line

• Solar-tracking position forecast in diagnostics, vertical extreme-gamma/high-elevation edge cases removed, legacy custom-position sensor migration added (beta.10, #563, #597, #598, #599, #600, #601)
• FOV generate-from-measurements button replaces two-mode selector, position matching opt-in with disable-retry option, climate status sensor always exposes threshold setpoints and typed inactive_reason slugs, FOV preview shown at depth 0 (beta.9, #565, #589, #590, #591, #592, #595, #596)
• Measurements-mode FOV sliders visible with editable suggested value, config summary shows [template] for Jinja2 threshold values (beta.8, #565, #577, #587, #588)
• Force Override merged into Custom Positions, FOV formula corrected (beta.7, #563, #565, #584, #583)
• Jinja2 templates in threshold fields and optional occupancy template (beta.6, #577, #578)
• Configuration Summary translated to user's language (beta.4/beta.5, #258, #575, #576)
• Set-position covers can reach true 0% in solar tracking (beta.3/beta.4, #569, #572)
• Same-position gate reverted to exact equality, restoring 1–3% tracking moves (beta.3, #567, #574)
• String entity_id in service targets now normalizes correctly (beta.3, #570, #571)
• FOV mode persisted on re-render, fixing save loop (beta.2/beta.3, #565)
• Measurements-mode config-flow save and imperial shaded-area compounding fixes (beta.2, #565)
• Low-sun edge case returns closed position (beta.1, #559, #562)
• Write-gating, geometry caching, and sun availability guard (beta.1, #543)

Compatibility

Requires Home Assistant 2026.3.0+. No new coupled-component requirements.

References