Advanced Use Cases Sun In FOV Custom Position

Custom Position only when the sun is in the field of view

A common request: "I want a custom position that applies only while the sun is in my window's field of view (FOV), and the normal default position the rest of the time." This is achievable today with no code changes — the key is to gate the custom-position slot's trigger on the sun being in the FOV, instead of leaving it always active.

---

Why a custom position normally wins all day

A custom-position slot fires whenever its trigger is active, independent of where the sun is. With the default priority of 77 it then outranks solar tracking (40) and cloud suppression (60), so if the slot's trigger is always on, its position is applied around the clock.

For reference, the relevant slice of the priority chain:

... → Custom Position(77) → Cloud Suppression(60) → Solar(40) → Default(0)

Two things follow:

• Cloud suppression is not the culprit when the sun is outside the FOV. Cloud suppression only evaluates when the sun is in the FOV (it checks direct_sun_valid first and passes through otherwise). When the sun is outside the FOV, both the custom slot and cloud suppression need to step aside for the default position to take over.
• The fix is to make the trigger track the FOV. Once the trigger is on only while the sun is in the FOV, the slot wins during those hours and yields to the default position the rest of the day.

---

The building block: the "Sun Infront" binary sensor

Adaptive Cover Pro exposes a built-in binary sensor per cover:

Entity	State
binary_sensor.<your_cover_name>_sun_infront ("Sun Infront")	on exactly when the sun is within the window's field of view — azimuth inside the configured FOV, elevation valid, and not inside the sunset-offset or blind-spot windows

This is the same direct_sun_valid signal the solar handler uses internally, surfaced as an entity you can reference directly or in a template.

---

Option 1 (simplest): wire the sensor straight into the slot

In the cover's options under Custom Positions, set Trigger Sensor for your slot to binary_sensor.<your_cover_name>_sun_infront. Leave priority at 77.

Sun position	Sun Infront	Result
In FOV	on	Custom position wins (77 > 60 > 40)
Outside FOV	off	Slot passes, cloud suppression passes → default position

That's the whole recipe for the basic case.

---

Option 2: combine sun-in-FOV with another condition

Custom-position slots have a built-in Condition Template field and a Combine Mode (OR / AND), so you can require both "sun in FOV" and some condition of your own — without an external template sensor.

Set up the slot as:

Setting	Value
Trigger Sensor	binary_sensor.<your_cover_name>_sun_infront
Condition Template	your extra condition (see below)
Combine Mode	AND
Custom Position	your desired %
Priority	77

Example Condition Template — only apply the custom position when you're working from home:

{{ is_state('input_boolean.work_from_home', 'on') }}

With Combine Mode = AND, the slot is active only when the sun is in the FOV and the template is truthy. Outside the FOV (or when you're not WFH) the slot yields to the default position.

---

Option 3: reference the FOV state in your own Jinja

If you'd rather build the whole condition in a single template (e.g. for a standalone Template binary sensor reused elsewhere), the FOV state is available to Jinja two ways:

{# Direct — the dedicated binary sensor #}
{{ is_state('binary_sensor.living_room_sun_infront', 'on') }}

{# Or via the Control Status sensor's attribute #}
{{ state_attr('sensor.living_room_control_status', 'in_field_of_view') }}

A standalone Template binary sensor that ANDs sun-in-FOV with another condition, then wired into the slot's Trigger Sensor:

template:
  - binary_sensor:
      - name: "Living Room Custom Trigger"
        state: >
          {{ is_state('binary_sensor.living_room_sun_infront', 'on')
             and is_state('input_boolean.work_from_home', 'on') }}

(Replace living_room with your cover's actual entity slug.) Options 2 and 3 reach the same result — Option 2 keeps the logic inside the integration; Option 3 is handy when you already maintain template sensors or want to reuse the trigger in other automations.

---

Letting cloud suppression override the custom position

If you want the custom position to apply only when it's actually sunny in the FOV — i.e. let cloud suppression take over on a cloudy-but-sun-in-FOV moment — set the slot's priority below 60 (e.g. 55). The chain becomes:

... → Cloud Suppression(60) → Custom Position(55) → Solar(40) → Default(0)

Now cloud suppression wins when it indicates no real direct sun, even though the sun is geometrically in the FOV; otherwise your custom position applies.

---

Diagnosing the behavior

Check sensor.{your_device}_decision_trace. The state shows which handler won; the trace attribute lists every handler that evaluated and why. While the sun is in the FOV you should see custom_position (or cloud_suppression if you chose the priority-55 variant); once the sun leaves the FOV you should see default.

---

Related pages

• How It Decides: full priority chain
• Custom Position: slot configuration reference (trigger sensors, condition templates, combine mode, priority)
• Sun Tracking: field-of-view and tracking settings
• Diagnostic Sensors: the Sun Infront binary sensor and Control Status attributes
• Advanced Use Cases: all advanced use case recipes