My Adaptive Cover Pro setup for a ground-floor bedroom

[elmakus]

I am using Adaptive Cover Pro for external venetian blinds in a ground-floor bedroom. The cover supports both position and tilt, and my goal is not only “maximum thermal optimization”, but a practical setup that balances:

• summer heat protection
• privacy on the ground floor
• night airflow
• sleep comfort
• storm comfort
• manual override
• avoiding unnecessary mechanical noise from the slats
• real-life acceptance factor: the room should not become a cave while somebody is at home

The apartment is not easy to equip with normal air conditioning, so I am trying to use a combination of external blinds and, later, automated window ventilation to reduce summer heat as much as possible.

I already have Vektiva Smarwi smart window openers at home, but I still need to find time to install them. My long-term idea is to combine:

1. Adaptive Cover Pro for solar shading / privacy / thermal behavior
2. local outside temperature sensors near each window/blind
3. Smarwi window openers for controlled ventilation when it makes sense

So the system can eventually decide not only how to position the blinds, but also when opening the windows could actually help cool the apartment.

---

Why I use helpers instead of one big template

I split the logic into Home Assistant helpers and keep ACP Custom Positions mostly as a clean mapping:

helper is active -> ACP target position/tilt with priority

This makes the system much easier to debug. Each helper answers one question, for example:

• what thermal season/microseason are we in?
• should the home try to keep heat out or keep heat in?
• is this room locally hot outside?
• is somebody maybe sleeping in this bedroom?
• is the bedroom light on?
• is it dark enough outside for night airflow?
• is there a recent thunderstorm?

Then ACP priority decides which active policy physically wins.

Multiple helpers are allowed to be active at the same time. I do not try to make every helper exclude all higher-priority helpers. ACP priority is the conflict resolver.

---

Position / tilt targets

I describe my targets as:

position / tilt

For this bedroom setup, the important targets are:

Target	Meaning	Why I use it
30/0	Partly lowered, slats closed	Present-like heat protection. It blocks some heat but still leaves a daylight gap at the bottom.
0/18	Fully lowered, privacy tilt	Ground-floor privacy while still allowing some air and light.
0/1	Fully lowered, almost closed	Sleep/storm comfort target. I am testing tilt 1 instead of 0 to avoid mechanical clicking/knocking when moving from 0/x to 0/0.
0/100	Fully lowered, open slats	Night airflow / lowered-open base state.

The 30/0 target is a deliberate compromise. Full closure would block heat better, but while somebody may be home it makes the room too dark. 30/0 is my “maximum acceptable” heat protection for present-like mode.

---

Lowered-open state: 0/100

One important target in my setup is:

0/100

This means:

blind lowered, slats open

I use this as a useful evening/night base state. The blind is already physically lowered, but the slats stay open for airflow and for a less “closed-in” feeling.

This is especially useful in a ground-floor bedroom. If the blind is already lowered and somebody later turns on the bedroom light, ACP does not need to move the whole blind down first. It can usually react mostly by changing tilt:

0/100 -> 0/18

instead of doing a larger movement like:

100/100 -> 0/18

That is faster, quieter, and less visible from outside.

In my setup this 0/100 state is mainly expressed through the home_present_night_airflow Custom Position:

binary_sensor.home_present_night_airflow
position: 0
tilt: 100
priority: 72

This helper becomes active when somebody may be home and it is already deeply dark outside.

I also have ACP sunset values configured as:

sunset_position: 0
sunset_tilt: 100

but the intentional and easiest-to-understand part of my setup is the Custom Position rule above. So I treat 0/100 primarily as my night-airflow / lowered-open base state, not as a pure “close at sunset” rule.

---

Light, privacy, airflow, and solar thresholds

I use several different sun elevation thresholds, and each one has a different purpose. I do not use one single “sunset” threshold for everything.

Trigger / threshold	Target	Purpose
ACP configured sunset target	0/100	Configured lowered-open fallback target. I have this configured in ACP, but I do not treat it as the main explanation of my evening/night logic because most of my intentional behavior is handled through Custom Position helpers.
home_present_night_airflow / deep darkness	0/100	Lowered-open night base state. The blind is already down, but slats stay open for airflow and to avoid a closed-in feeling. It also makes later privacy changes faster because only tilt may need to change.
sun elevation < 7°	0/18	Stronger low-light privacy pre-positioning. At this point I assume the room will probably need artificial light if somebody enters, so the blind is already in privacy tilt.
bedroom light turns on	0/18	Actual privacy enforcement. If the blind is already pre-positioned, this usually does not need a large movement.
sun elevation >= 15°	solar tracking allowed	Real solar shading only when the sun is high enough and in the window FOV.

The difference between 0/100 and 0/18 is important for me.

0/100 is a lowered-open base state: the blind is already down, but the room still feels open and airflow is possible.

0/18 is the stronger privacy pre-positioning state. Below about 7° sun elevation I assume that if someone enters the room, they will probably need to turn on the light, for example to take something from the wardrobe. So I want the blind already in privacy tilt before that happens.

The bedroom light rule then acts as actual privacy enforcement. If the blind is already pre-positioned, turning on the light usually does not need to trigger a large movement.

---

Solar tracking and daytime gate

Solar tracking is gated by sun elevation and window geometry.

In this setup I only want solar tracking when the sun is high enough to matter for this window, so both the solar minimum elevation and my daytime gate are based around 15° elevation.

min_elevation: 15

My daytime gate template is also based on sun elevation:

{% set elevation = state_attr('sun.sun', 'elevation') | float(none) %}
{{ elevation is not none and elevation >= 15 }}

The bedroom window faces approximately azimuth 104°, with a wide field of view of about ±85°.

That gives a rough sun-in-window sector of:

104° - 85° = 19°
104° + 85° = 189°

So ACP only treats the sun as relevant for this window when the sun is roughly within 19°..189°, and above the minimum elevation.

Outside of valid solar-tracking conditions, ACP falls back to the normal priority pipeline: Custom Positions first, then default behavior.

Evening and night behavior is mostly handled by my own helpers:

• home_present_low_light_privacy below 7° -> 0/18
• home_present_night_airflow at or below -10° -> 0/100

I also have sunset_position: 0 and sunset_tilt: 100 configured, but the main intentional evening/night behavior in my setup is expressed through the Custom Position helpers above.

---

Occupancy model

I design the logic around two occupancy groups:

present-like
away-like

The concrete Home Assistant house mode states are implementation details. The cover logic mostly cares whether somebody may need comfort/privacy inside, or whether nobody is expected to care about daylight comfort.

In my current setup:

{% set house_mode = states('input_select.house_mode') %}
{% set present_ok = house_mode in ['Home', 'Neighborhood', 'Guest'] %}
{% set away_ok = house_mode in ['Away', 'Far', 'Returning'] %}

So the helpers use present_ok or away_ok, not a long cover-specific list of house-mode decisions.

---

Helper dependency graph

The setup is built as a small chain of helpers, not one giant template.

High-level dependency graph:

general outdoor temperature
  -> 7-day average outdoor temperature
      -> microseason
          -> passive thermal mode
              -> home/room thermal policy helpers
                  -> ACP Custom Position priorities

Room-local heat risk uses a separate local sensor path:

local bedroom cover/window temperature
  -> bedroom cover outside hot temperature
      -> bedroom present outside heat risk
          -> ACP slot: 30/0, priority 71

---

Base weather / thermal helpers

General outdoor temperature sensor

This is my general outdoor temperature source from a local weather integration.

In my private setup this is a specific local weather-station entity, but for a public example I would describe it generically as:

sensor.<general_outdoor_temperature>

It is not the final decision helper. It is used as the input for the 7-day average temperature helper.

sensor.outdoor_7d_avg_temp

This is a statistics helper over the general outdoor temperature.

Configuration:

source: sensor.<general_outdoor_temperature>
state_characteristic: mean
max_age: 168 hours
precision: 2

So it gives a rolling 7-day outdoor average temperature.

I use this instead of the current outdoor temperature for seasonal classification because one hot or cold day should not flip the whole home strategy immediately.

sensor.microseason

This helper converts the rolling 7-day outdoor average into a more useful “thermal season” than the calendar season.

It uses:

sensor.outdoor_7d_avg_temp
current month
previous microseason state

Template:

{% set avg = states('sensor.outdoor_7d_avg_temp') | float(none) %}
{% set month = now().month %}
{% set previous = states('sensor.microseason') | lower %}
{% set valid = [
  'winter',
  'early_spring',
  'spring',
  'early_summer',
  'summer',
  'early_autumn',
  'autumn',
  'late_autumn'
] %}
{% set last = previous if previous in valid else 'winter' %}
{% set half = 'warming' if month <= 6 else 'cooling' %}
{% set candidates = namespace(list=[]) %}

{% if avg is not none %}
  {% if avg <= 0.5 %}
    {% set candidates.list = candidates.list + ['winter'] %}
  {% endif %}

  {% if half == 'warming' and avg >= -0.5 and avg <= 5.5 %}
    {% set candidates.list = candidates.list + ['early_spring'] %}
  {% endif %}
  {% if half == 'warming' and avg >= 4.5 and avg <= 12.5 %}
    {% set candidates.list = candidates.list + ['spring'] %}
  {% endif %}

  {% if half == 'warming' and avg >= 11.5 and avg <= 18.5 %}
    {% set candidates.list = candidates.list + ['early_summer'] %}
  {% endif %}

  {% if avg >= 17.5 %}
    {% set candidates.list = candidates.list + ['summer'] %}
  {% endif %}
  {% if half == 'cooling' and avg >= 11.5 and avg <= 18.5 %}
    {% set candidates.list = candidates.list + ['early_autumn'] %}
  {% endif %}

  {% if half == 'cooling' and avg >= 4.5 and avg <= 12.5 %}
    {% set candidates.list = candidates.list + ['autumn'] %}
  {% endif %}

  {% if half == 'cooling' and avg >= -0.5 and avg <= 5.5 %}
    {% set candidates.list = candidates.list + ['late_autumn'] %}
  {% endif %}
{% endif %}
{{ last if last in candidates.list else (candidates.list[0] if candidates.list else last) }}

The important idea is that I split the year into practical thermal periods:

Microseason	Meaning
winter	Clearly heat-retention season.
early_spring	Warming half of the year, still cool.
spring	Moderate warming period.
early_summer	Transition toward cooling / heat protection.
summer	Heat protection season.
early_autumn	Still summer-like enough to keep heat out.
autumn	Cooling half, moderate.
late_autumn	Transition back toward winter.

The helper also uses the previous state as a simple stabilizer: if the previous microseason is still one of the currently valid candidates, it keeps it. That avoids unnecessary bouncing near threshold boundaries.

sensor.home_passive_thermal_mode

This helper turns the detailed microseason into a simple home-level strategy:

keep_heat_out
keep_heat_in

Template:

{% set season = states('sensor.microseason') | lower %}

{% if season in ['early_summer', 'summer', 'early_autumn'] %}
  keep_heat_out
{% else %}
  keep_heat_in
{% endif %}

Meaning:

Value	Used when	Meaning
keep_heat_out	early_summer, summer, early_autumn	Prefer reducing unwanted heat gain.
keep_heat_in	all other microseasons	Prefer reducing heat loss.

This helper still does not decide the blind position directly. It is a shared input for room and home policy helpers.

---

Room-local outside temperature helpers

Local bedroom cover/window temperature sensor

This is a local Zigbee temperature sensor mounted near the bedroom cover/window.

Public example name:

sensor.bedroom_cover_outside_temperature

In my real setup the entity name is slightly more verbose because of how the Zigbee integration generated it, but the meaning is:

local temperature near this specific bedroom blind/window

It is intentionally different from the general outdoor weather-station temperature. It should represent the microclimate near this specific blind/window.

binary_sensor.bedroom_cover_outside_hot_temperature

This is the bedroom-local hot-temperature threshold helper.

Configuration:

source: sensor.bedroom_cover_outside_temperature
upper: 30
hysteresis: 1

Meaning:

on  -> local bedroom cover/window temperature is hot
off -> local temperature has fallen below the hysteresis band

This helper is room-local. Other windows/rooms should get their own equivalent local temperature helper.

binary_sensor.bedroom_present_outside_heat_risk

This helper combines occupancy, passive thermal mode, and the local bedroom outside temperature.

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set present_ok = house_mode in ['Home', 'Neighborhood', 'Guest'] %}

{{ present_ok
   and is_state('sensor.home_passive_thermal_mode', 'keep_heat_out')
   and is_state('binary_sensor.bedroom_cover_outside_hot_temperature', 'on') }}

It is active when:

• the home is present-like
• passive thermal mode is keep_heat_out
• the local bedroom cover/window temperature is hot

ACP target:

30/0
priority 71

This is softer present-like heat protection. It reduces heat gain but keeps a daylight gap.

---

Away-like heat helpers

binary_sensor.home_away_heat_protection

This is a global away-like heat protection helper.

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set away_ok = house_mode in ['Away', 'Far', 'Returning'] %}
{% set elevation = state_attr('sun.sun', 'elevation') | float(none) %}
{% set daytime_ok = elevation is not none and elevation >= 7 %}

{{ away_ok
   and is_state('sensor.home_passive_thermal_mode', 'keep_heat_out')
   and daytime_ok }}

It is active when:

• the home is away-like
• passive thermal mode is keep_heat_out
• sun elevation is at least 7°

ACP target:

0/0
priority 76

It does not use current outdoor temperature. If nobody is home and the home is in a heat-out period, the goal is to block solar heat gain aggressively.

binary_sensor.bedroom_away_heat_retention

This is a room-local heat-retention helper for the bedroom.

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set away_ok = house_mode in ['Away', 'Far', 'Returning'] %}
{% set azimuth = state_attr('sun.sun', 'azimuth') | float(none) %}

{% set sun_in_bedroom_window =
  azimuth is not none
  and azimuth >= 19
  and azimuth <= 189
%}

{{ away_ok
   and is_state('sensor.home_passive_thermal_mode', 'keep_heat_in')
   and not sun_in_bedroom_window }}

Bedroom geometry:

window azimuth: 104°
field of view: ±85°
sun-in-window sector: 19°..189°

It is active when:

• the home is away-like
• passive thermal mode is keep_heat_in
• the sun is outside the bedroom window sector

ACP target:

0/0
priority 76

This helper is room-local because each room/window has different geometry.

---

Sleep and privacy helpers

binary_sensor.bedroom_sleep_blackout

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set present_ok = house_mode in ['Home', 'Neighborhood', 'Guest'] %}

{% set sleeping =
  is_state('binary_sensor.person_1_sleeping', 'on')
  or is_state('binary_sensor.person_2_sleeping', 'on')
  or is_state('binary_sensor.child_sleeping_in_our_bedroom', 'on')
%}
{% set elevation = state_attr('sun.sun', 'elevation') | float(none) %}
{% set light_ok = elevation is not none and elevation > -10 %}

{{ present_ok and sleeping and light_ok }}

It is active when:

• the home is present-like
• at least one bedroom sleep signal is active
• sun elevation is above -10°

ACP target:

0/1
priority 78

It turns off at deep night so that night airflow can operate normally when it is already naturally dark.

binary_sensor.bedroom_light_privacy

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set present_ok = house_mode in ['Home', 'Neighborhood', 'Guest'] %}

{{ present_ok
   and is_state('switch.bedroom_light', 'on') }}

It is active when:

• the home is present-like
• the bedroom light is on

ACP target:

0/18
priority 74

This does not depend on outdoor brightness. If the room light is on, privacy is desired.

---

Storm helpers

binary_sensor.weather_thunderstorm

Template:

{% set condition = states('weather.<local_weather_entity>') %}
{{ condition in ['lightning', 'lightning-rainy'] }}

It is active only when the weather entity currently reports a thunderstorm-like condition.

I do not use MeteoSwiss warnings for this rule right now.

binary_sensor.weather_thunderstorm_recent

This is a technical hold helper based on binary_sensor.weather_thunderstorm.

Behavior:

turn on immediately when weather_thunderstorm turns on
remain on for 10 minutes after weather_thunderstorm turns off

It should not include house-mode logic. House-mode logic belongs in home_present_storm_comfort.

binary_sensor.home_present_storm_comfort

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set present_ok = house_mode in ['Home', 'Neighborhood', 'Guest'] %}

{{ present_ok
   and is_state('binary_sensor.weather_thunderstorm_recent', 'on') }}

ACP target:

0/1
priority 95

This is a comfort policy, not a hardware safety policy. It can release immediately if the home becomes away-like, even if the technical storm-recent helper is still in its 10-minute hold period.

---

Light / night helpers

binary_sensor.home_present_night_airflow

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set present_ok = house_mode in ['Home', 'Neighborhood', 'Guest'] %}
{% set elevation = state_attr('sun.sun', 'elevation') | float(none) %}
{% set dark_ok = elevation is not none and elevation <= -10 %}

{{ present_ok and dark_ok }}

It is active when:

• the home is present-like
• sun elevation is at or below -10°

ACP target:

0/100
priority 72

This keeps the blind lowered but opens the slats for night airflow.

binary_sensor.home_present_low_light_privacy

Template:

{% set house_mode = states('input_select.house_mode') %}
{% set present_ok = house_mode in ['Home', 'Neighborhood', 'Guest'] %}
{% set elevation = state_attr('sun.sun', 'elevation') | float(none) %}
{% set low_light_ok = elevation is not none and elevation < 7 %}

{{ present_ok and low_light_ok }}

It is active when:

• the home is present-like
• sun elevation is below 7°

ACP target:

0/18
priority 70

The 7° threshold is my “indoor light likely needed soon” threshold.

At this point I assume the room will probably need artificial light if somebody enters, so the blind is already in privacy tilt before the bedroom light is actually switched on.

---

Manual override

Manual override is triggered from the Shelly wall-switch input sensors, not from generic inferred external movement.

Relevant idea:

physical wall switch input changes -> ACP manual override

I ignore generic inferred external position changes, but explicit Shelly input changes are used as the manual-control signal.

In practical terms, if someone presses the wall switch, ACP should stop fighting them and should hold manual override for the configured duration.

For this cover, manual override sits at priority 80, so it wins over normal solar tracking and most comfort helpers, but my storm comfort Custom Position is intentionally higher at priority 95.

---

Final ACP priority ladder

Priority	Helper / handler	Target	Why
95	home_present_storm_comfort	0/1	Highest automatic comfort override for thunderstorms while someone may be home.
80	manual override	hold current/manual state	Physical wall-switch interaction should pause most automation.
78	bedroom_sleep_blackout	0/1	Darken bedroom when someone may be sleeping and outside light may disturb sleep.
76	home_away_heat_protection OR bedroom_away_heat_retention	0/0	Full unattended thermal closure.
74	bedroom_light_privacy	0/18	Ground-floor privacy whenever bedroom light is on.
72	home_present_night_airflow	0/100	Lowered cover with open slats for night airflow.
71	bedroom_present_outside_heat_risk	30/0	Softer present-like heat protection based on local bedroom outside temperature.
70	home_present_low_light_privacy	0/18	Low-light privacy pre-positioning.
40	solar tracking	calculated	Direct sun shading when sun is in the window FOV and high enough.
0	default	100	Fully open when no stronger rule is active.

The simplified decision flow is:

storm comfort
  > manual override
  > sleep blackout
  > away thermal policy
  > bedroom light privacy
  > night airflow
  > present outside heat risk
  > low-light privacy
  > solar tracking
  > default

---

Notes on unused ACP features in this instance

For this bedroom instance, I currently do not use these ACP features as the main logic layer:

weather override: not configured
motion sensors: not configured
cloud suppression: not configured
climate mode: not configured
glare zones: not configured
proxy cover: disabled
my-position entities: disabled
minimum position limit: disabled
maximum position limit: disabled

I keep most of that logic outside ACP for now because I want to understand and debug the behavior clearly.

For example, my weather/storm behavior is handled through my own helper and then mapped into ACP as Custom Position #1.

---

Why this setup is not purely thermal

If this were only about thermal performance, many rules would simply close the blind fully.

But this is a bedroom that people actually use, so the real target is a compromise:

thermal performance
+ privacy
+ daylight comfort
+ sleep comfort
+ airflow
+ low noise
+ manual control acceptance

For example:

• 30/0 is weaker than full closure, but much more acceptable while someone is home.
• 0/18 gives privacy without fully sealing the room visually.
• 0/100 gives night airflow while still keeping the blind physically lowered.
• 0/1 is used instead of exact 0/0 in some comfort rules to reduce slat knocking/clicking on my hardware.
• Solar tracking is allowed only when the sun is actually relevant for this window.

That is why I find ACP Custom Positions useful: ACP handles the final priority decision, but I can keep the meaning of each rule understandable.

---

Debugging approach

The biggest advantage of this structure is debugging.

If the blind is in an unexpected position, I can check:

1. Which helper is active?
2. Which ACP handler won?
3. What priority did it have?
4. Was solar tracking actually valid?
5. Was the sun in FOV?
6. Was manual override active?
7. Did ACP fall back to default behavior?

In ACP diagnostics, the decision trace makes this very clear because it lists each handler and whether it matched.

Example:

custom_position_1 -> not active
weather -> not active
manual_override -> not active
custom_position_2 -> not active
...
solar -> not active / sun outside FOV
default -> active

or during direct sun:

solar -> active
reason: sun in FOV

or during manual wall-switch use:

manual_override -> active
reason: input_sensor

This is much easier to debug than one huge automation with all logic embedded in one place.

---

Current limitations / things I may still change

This setup is still evolving.

Things I may still adjust:

• increase the Venetian drift-reset threshold after testing
• tune the 30/0 present-like heat-protection target
• add local window-opening logic with Smarwi
• use more local outside temperature sensors per window
• tune the privacy/night thresholds after living with the setup longer
• possibly use different drift-reset directions for different blinds

I am sharing this mainly as a practical example of how ACP can be used as a priority-based cover policy engine, with most of the “why” expressed through small Home Assistant helpers.

[FredM67]

A huge thank you for all the details.... Great job, great sharing.

[elmakus]

Small update: I edited the original post and expanded it quite a bit.

The first version mostly described how I use Custom Positions, but it did not explain the full ACP decision flow around them — solar tracking, default behavior, the different sun elevation thresholds, manual override, and why the priorities are arranged the way they are.

The updated version should now give a better picture of the whole setup, not just the Custom Position helpers.

A few notes about the ACP features I currently do not use in this instance:

• weather override: not configured, because for now the only weather-related behavior I really care about is thunderstorm comfort, and I handle that through my own helper + Custom Position. I may later add native ACP behavior for hail.
• cloud suppression: not configured yet, but I will definitely need to look into it when I have time.
• climate mode: for my use case, I currently prefer expressing the logic through Custom Positions, because I want explicit priorities and easy-to-debug helper states.
• motion sensors: I have not looked deeply into this yet, but my understanding is that it is more related to presence/motion in a specific room. In my current logic, room-level presence is not very important. I mostly care whether the home is in a present-like or away-like mode, not whether somebody is currently detected in this specific bedroom.

When I later move a similar ACP setup to the living room, I will probably add another Custom Position for projector mode. For example, when the projector turns on, all relevant blinds should close to 0/0 to improve screen visibility.

If anyone has questions about the configuration, or ideas for tweaking/improving it, I am happy to answer and discuss. I am still tuning this setup, so suggestions and different approaches are very welcome.