Configuration Custom Position

Custom Position

Up to 5 custom position slots, each pairing a trigger (one or more binary sensors, an optional Jinja2 condition template, or both) with a fixed cover position. When the slot is active, the cover moves to the configured position; each slot has an independently configurable priority (1–100).

Slot 5 at priority 100 is the safety-priority slot — it inherits the semantics of the former Force Override feature. If you were using Force Override, your configuration has been migrated to slot 5 automatically. See Safety Priority below.

Variable	Default	Range	Description
Trigger Sensors 1–5	None		One or more binary sensors. When any sensor in the list is on, the slot is triggered (OR logic). Can be combined with a condition template.
Condition Template 1–5	None		Optional Jinja2 condition template. Renders once per cycle; a truthy result triggers the slot. Combined with the sensor list via the Combine Mode setting.
Combine Mode 1–5	OR	OR / AND	How sensor state and template result are combined. OR (default): the slot is active if either the sensor list OR the template is truthy. AND: the slot is active only when both are truthy simultaneously.
Custom Position 1–5	0	0–100	Cover position (%) to move to when the slot is active.
Custom Position Priority 1–5	77	1–100	Pipeline evaluation priority. Higher = evaluated before lower-priority handlers. Priority 100 enables safety semantics (see below).
Minimum Mode 1–5	Off		When enabled, the position acts as a minimum floor: the cover won't go below it, but higher positions from solar tracking or other handlers are still allowed through.
Use My Preset 1–5	Off		When enabled, sends the Somfy My position command instead of the numeric position value. Requires My Position Value to be set in Position settings. See My Position Support.
Tilt for Slot 1–5	Unset	0–100	Venetian covers only — ignored for other cover types. Tilt angle (%) to set when the slot is active. Leave unset to let the engine calculate tilt automatically.
Tilt Only 1–5	Off		Venetian covers only. When enabled, the slot fixes only the slat angle and does not claim the carriage position — solar tracking still decides how far the blind hangs. Overrides Minimum Mode and Use My Preset for that slot. See Tilt-only mode below.

How it fits in the pipeline

Weather(90) → Manual(80) → Custom(1–100) → Motion(75) → Cloud(60) → Climate(50) → Glare(45) → Solar(40) → Default(0)

Custom position slots are evaluated in descending priority order. A slot at priority 100 fires before Weather (90). A slot at default priority 77 fires after Manual (80) but before Motion (75). Multiple slots can be configured at different priorities to stack logic.

Automatic Control and the schedule window

These are two separate gates, and custom position slots interact with them differently.

Automatic Control (the toggle switch): all custom position slots fire even when Automatic Control is disabled. The cover moves to the configured position regardless of whether the automation switch is off. This is intentional — a sensor-triggered override is an explicit user action that should take effect immediately.

Schedule window (start/end time): only priority-100 slots bypass the time window. Slots at default priority (77) or any other priority below 100 are blocked outside the configured start/end window and do not send a command. If you need a custom position to fire at any hour — a storm shutter, a security input, anything that can't wait for the window to open — set its priority to 100.

The difference matters most for night-time or off-hours use cases. A slot at priority 77 with auto control off: fires. The same slot outside the time window at 2 AM: does not fire.

Priority-100 slots also retry via the reconciliation path when a cover misses a command (e.g. it was in transit). Slots at lower priorities do not — if the command didn't land, it won't be resent.

Safety Priority — the Force Override replacement

Any custom position slot whose priority is set to 100 inherits the former Force Override safety semantics:

• Commands fire outside the configured start/end schedule window — a safety-priority slot is never blocked by the time window.
• Both the delta-position and delta-time send gates are bypassed — the command goes out immediately regardless of how recently the cover was last commanded.
• Commands are retried by the reconciliation loop if the cover missed them (e.g. during transit).
• When the slot deactivates, the cover returns immediately to the pipeline-calculated position, bypassing the delta gates on release as well.

Slot 5 at priority 100 is the default migration target. If your install had Force Override configured before v2.28.0-beta.7, the v3.2 migration copied your sensors and position into slot 5 automatically. No action required — your Force Override behaviour is preserved exactly.

Migration from Force Override

If you upgrade from a version that had a dedicated Force Override step:

1. Open your cover's options and go to Custom Positions.
2. Slot 5 should be pre-populated with your previous Force Override trigger sensor and target position at priority 100.
3. Verify the settings look correct, then save.

If you want to migrate a Force Override to a different slot (e.g. slot 1 with priority 100), you can copy the values manually and clear slot 5.

The set_force_override service is retained for one release as a deprecation shim — existing automations that call it continue to work, but log a deprecation warning. Replace those calls with adaptive_cover_pro.set_custom_position targeting slot 5.

Minimum Mode and external commands

Minimum mode is enforced inside ACP's pipeline — it constrains the position ACP itself sends to the cover. It does not intercept direct cover.set_cover_position calls from a dashboard, script, or other automation. A direct call to cover.set_cover_position reaches the cover unchanged and also marks the cover as manually overridden, pausing ACP automation.

To enforce the active minimum-mode floor from automations and dashboards, call the integration's own service:

service: adaptive_cover_pro.set_position
target:
  entity_id: cover.living_room_blind
data:
  position: 30

The service clamps the requested position up to the highest active minimum-mode floor before sending the command. If no slot is active, the call is a pass-through. Tilt is not affected. See Known Limitations.

Tilt-only mode (venetian)

Venetian covers only. This mode has no effect on vertical blinds, awnings, or tilt-only covers — the option only appears for venetian (dual-axis) covers.

Normally a custom position slot claims both axes: when its trigger is active, it pins the carriage position and the slat tilt. Tilt-only mode decouples them. When the slot is active:

• Only the slat angle is fixed, to the slot's Tilt value.
• The carriage position is released — solar tracking (or whatever handler wins the position pipeline) continues to decide how far the blind hangs.
• Minimum Mode and Use My Preset are ignored for that slot (the config summary shows a warning when you combine them).

The canonical use case: open the slats fully on overcast days for maximum daylight with no glare, while still letting the sun-tracking algorithm position the blind. See the full recipe in Advanced Use Cases → Venetian Tilt-Only on Overcast Days.

How it interacts with priority

A tilt-only slot resolves on the tilt axis independently of the position winner. Among multiple active tilt-only slots, the highest-priority one supplies the tilt. The slot's tilt is applied only when the winning position handler hasn't already set its own tilt — so a higher-priority handler that explicitly controls tilt keeps it. In the normal "solar wins position" case (solar leaves tilt for the engine), the tilt-only value flows straight through.

Interaction with global tilt-only mode

Venetian covers also have a global Tilt-only control method (set under the venetian/tilt settings) that closes the carriage and works the slats. When a per-slot tilt-only contribution is active, that global carriage-close is suppressed for the cycle so the position axis genuinely follows the sun, as intended. The two features don't fight.

Decision trace

A tilt-only slot won't appear as the position winner (that's solar, by design). Instead it shows up as a matched custom_position step on the tilt axis in sensor.{your_device}_decision_trace — look for the slot reporting the fixed slat angle with the position handed off to sun tracking.

Multi-sensor OR and condition templates

Each slot supports three trigger types that can be mixed:

Trigger Sensors (OR logic): configure multiple binary sensors in the same slot. The slot activates when any sensor is on. This replaces the pattern of using a template binary sensor to OR multiple inputs together.

Condition Template: an optional Jinja2 expression. When it renders truthy, it contributes to the slot's trigger. You can reference any HA state, attribute, or helper:

{{ is_state('sun.sun', 'above_horizon') and state_attr('sun.sun', 'elevation') | float > 20 }}

Combine Mode (OR / AND): controls how the sensor list and the condition template interact:

• OR (default): the slot is active when the sensor list or the template is truthy — either alone is sufficient.
• AND: the slot is active only when both the sensor list and the template are truthy at the same time.

Tip: AND mode with no trigger sensors configured degenerates to template-only OR — the config summary displays a warning in this case. Configure at least one sensor if you intend AND behaviour.

Example use cases:

• A bedroom schedule sensor forces blinds closed (0%) for an afternoon nap
• A movie sensor moves living room blinds to 80% when the TV is on
• A Somfy cover uses its stored My preset when a specific scene is active
• Multiple sensors at different priorities let you stack logic (e.g. "watching TV" overrides general solar but a "morning coffee" sensor takes priority over both)
• A safety-priority slot (priority 100) closes all covers when a storm sensor or alarm input fires, even outside the automation schedule window