[Feature Idea] Building Profile entry — shared sensor config across cover instances

[FredM67]

Problem

Every ACP instance today is a fully independent config entry. All settings — including weather sensors, lux/irradiance sensors, cloud coverage, outside temperature — must be configured separately on each cover, even though in most buildings these sensors are physically shared across all openings (one weather station, one outdoor lux sensor, etc.).

The existing Sync feature (Options → "Copy to Other Covers") partially addresses this, but it has a fundamental limitation: it is a one-time manual push. If you later swap your weather station entity, you have to sync again to every cover. There is also no enforcement that irrelevant sensors are excluded — e.g. a rain sensor being configured on a venetian blind (which is behind the window pane and physically unaffected by rain).

---

Proposed solution: Building Profile entry

Add a new virtual entry type — sensor_type = "building_profile" — within the same integration domain (adaptive_cover_pro). No separate HACS package, no new integration manifest entry.

A Building Profile holds only the sensor entity IDs that are building-level (one per building/weather station), with no geometry, no thresholds, and no cover entities:

Sensor	Profile-owned
Wind speed sensor	yes
Wind direction sensor	yes
Rain / is_raining sensor	yes
Severe weather sensors (hail, frost, storm)	yes
Lux (illuminance) sensor	yes
Irradiance sensor	yes
Cloud coverage sensor	yes
Weather entity (weather.*)	yes
Outside temperature sensor	yes
Is-sunny binary sensor	yes

Each cover instance gets one new optional field: "Building Profile" — a selector listing all existing profile entries in the domain. When linked:

• Sensor entity IDs come from the profile automatically (no duplication)
• The cover's own weather_override and light_cloud config screens only show thresholds and modes (wind speed threshold, rain threshold, lux threshold, etc.) — not sensor pickers
• When the profile's sensor config changes (e.g. you replace your weather station), all linked covers update automatically with no manual sync

Covers without a linked profile continue to work exactly as today — fully backward compatible.

---

Why thresholds stay per-cover

A south-facing exposed awning may retract at 40 km/h wind; a sheltered east-facing awning can tolerate 60 km/h. A bedroom lux threshold for "close the blind" differs from the living room. The sensor is building-level; the reaction is cover-level. This is exactly the split the existing _SYNC_UI_CATEGORIES already models (*_values vs *_sensors) — the profile formalises it structurally.

---

Cover-type sensor filtering (companion improvement)

Not all sensors are meaningful for all cover types. A rain sensor is physically irrelevant for a venetian blind (behind the window pane); wind speed is irrelevant for a vertical blind inside a reveal. As part of this change, the weather override config screen should only show sensors relevant to each type:

Sensor	Vertical blind	Awning	Tilt	Venetian	Oscillating awning
Wind speed / direction	—	show	—	—	show
Rain / severe / hail / frost	—	show	—	—	show
Lux / irradiance / cloud	show	show	show	show	show

This can be implemented with a single new ClassVar[bool] on CoverTypePolicy (e.g. weather_retraction_relevant) and a guard in weather_override_schema() in config_dynamic.py.

---

Implementation sketch

The changes are localised to a small number of files with no breaking changes:

const.py

• Add CoverType.BUILDING_PROFILE = "building_profile"
• Add CONF_BUILDING_PROFILE_ID = "building_profile_id"
• Add _BUILDING_PROFILE_SENSOR_KEYS frozenset (the canonical list of profile-owned keys)

config_flow.py

• Add "building_profile" to the initial cover-type selector
• When selected, show only a sensor entity picker screen → summary (no geometry, no handlers)
• For cover instances: add an optional async_step_profile_link screen listing existing profiles
• When a profile is linked, hide sensor pickers from weather_override and light_cloud steps

config_types.py

• Add RuntimeConfig.from_options_with_profile(options, profile_options) factory that merges profile sensor keys over the cover's own options before constructing the dataclass

__init__.py

• After coordinator setup, if CONF_BUILDING_PROFILE_ID is set, register an add_update_listener on the profile entry that triggers a reload of the cover entry
• Include the profile's sensor entities in the async_track_state_change_event registration so the coordinator reacts immediately when a profile sensor changes state

cover_types/base.py

• Add weather_retraction_relevant: ClassVar[bool] = False
• AwningPolicy and OscillatingAwningPolicy set it True

migrations.py

• Minor version bump (additive only — CONF_BUILDING_PROFILE_ID absent on old entries = standalone, no data transformation needed)

cover_types/

• Add a BuildingProfilePolicy no-op policy so get_policy("building_profile") returns cleanly and async_setup_entry loads no platforms for profile entries

---

What happens to the Sync feature

It does not go away. With a profile in place:

• *_sensors sync categories become irrelevant for linked covers (sensors come from the profile) and can be hidden from the sync screen when a profile is linked
• *_values sync categories (thresholds, modes, flags) remain useful — each cover keeps its own thresholds, and sync is still the right tool to align them across similar covers

---

Backward compatibility

• All existing entries have no CONF_BUILDING_PROFILE_ID → treated as standalone, behaviour unchanged
• The building_profile entry type is additive; no existing entry type is modified
• Profile entries load no platforms (no entities registered) so they are invisible to HA automations and dashboards

---

Does this align with the project direction? Happy to elaborate on any part or work up a more detailed spec for a specific component.

[jrhubott]

I agree that managing many covers gets challenging given the number of configurable options, and the shared-sensor case is the clearest example: one weather station and one outdoor lux sensor end up entered on every cover, then re-entered whenever a sensor changes.

I've opened #693 to track this as an enhancement so we can work through the design before any implementation. I carried over your Building Profile proposal and implementation sketch as the starting point, kept the building-level-sensor / cover-level-threshold split, and added a few open questions at the bottom (one profile vs. composing several, what a profile owns beyond the entity ID, and whether the cover-type sensor filtering is worth shipping on its own first).

Let's continue the detailed discussion on #693.