Configuration Day Night Shade

Day/Night Shade (dual-fabric)

Added in v2026.8.0.

A day/night shade carries two fabrics on one window — a light-filtering sheer and an opaque blackout — and the useful question is never just "how far down is it?" but "how far down, and through which fabric?". This cover type models those as two separate quantities: a coverage figure that sun tracking computes exactly as it would for a plain vertical blind, and a fabric blend that decides which cloth sits in front of the glass.

Where day/night shades get complicated is that manufacturers wire that pair up in three completely different ways, and the hardware you own decides which one you pick. The Control Model setting is where you tell the integration which it is; everything else on this page follows from that choice.

Geometry settings

Variable	Default	Range	Description
Sheer Fabric Opacity (%)	30	0–100	How much light the light-filtering sheer fabric blocks. Used only to estimate filtering and to decide when hot summer sun needs the blackout fabric instead. The default describes a light voile.
Blackout Fabric Opacity (%)	100	0–100	How much light the opaque blackout fabric blocks. Used only for the filtering estimate.
Blackout Engage Threshold (%)	65	0–100	When the sun is in the tracking window during summer and the sheer fabric's opacity is below this value, the shade escalates to blackout to block the heat. Raise it to reach for blackout sooner; lower it to stay on the sheer fabric longer.
Control Model	Position + tilt		How the coverage/fabric pair maps onto your physical cover. See below.
Middle Rail Entity	none		Two rail entities only. Which of this instance's covers is the middle rail.
Move Both Rails Together	False		Two rail entities only. Whether the rails may travel simultaneously. See the warning below.
Fix Unreachable Rail Commands	True		Two rail entities only. Whether to clear a blocking rail out of the way so your command completes.

Control models

Position + tilt (dual axis) — the default, and the right answer for hardware that exposes both axes. Coverage goes out as set_cover_position, the fabric blend as set_cover_tilt_position.

Split range (single axis) — one motor, one position range, encoding both quantities. The lower half (0–50%) selects the blackout fabric, the upper half (50–100%) the sheer. Pick this when the cover has no tilt axis and its documented behaviour is that driving it past the midpoint swaps fabrics.

Two rail entities (dual entity) — the shade appears in Home Assistant as two separate cover entities, a bottom rail and a middle rail, and the fabric blend is expressed as the middle rail's absolute position. Choose this model, then nominate which of the instance's covers is the middle rail; the other is the bottom rail.

The middle rail must be selected. If the Control Model is Two rail entities and no middle rail is nominated (or the nominated cover isn't in this instance's cover list), both rails receive the same position and the shade behaves like a plain blind. The integration raises a repair issue — Day/night middle rail not selected — rather than letting this pass silently.

Rail coupling on the two-entity model

The two rails share one track, so the middle rail can never drop below the bottom rail. The integration enforces that ordering on every command it issues, which means automatic sun tracking is always safe: it derives both rail positions from a single coverage figure and moves them as a set, so it never asks for a position a rail cannot reach.

Commands from outside that path are the interesting case, and two settings govern them.

Move Both Rails Together

Off by default, and worth leaving off. With it off, the following rail waits until the leading rail has fully cleared its target before moving at all — two travel times instead of one, but always correct, because the decision rests on a position the integration has actually read.

⚠️ Turning this on is for experienced users, and it is behind most reported dual-rail problems. Releasing the following rail early depends on your motors publishing an opening/closing state, or intermediate positions, while they travel. Many publish neither — some report nothing between the command and their arrival, which leaves the integration inferring motion it cannot observe. When that inference is wrong, the following rail is released into a rail that has not moved, which can stall a motor, trip its over-current protection, or lose its calibration. Only enable it if you can watch your own rails and confirm they hold their separation for the whole move.

Fix Unreachable Rail Commands

On by default. This handles a command that asks one rail to travel into space the other is occupying, which arrives by two different routes.

A command sent straight at a rail entity — from a dashboard, a script, or a handheld remote — never passes through Adaptive Cover Pro, so nothing sequences it and the motor either refuses it or stalls part-way. A command sent through the integration — the card's per-rail slider, set_position / set_axes, the proxy cover, the My Position button — is held back by the rail-clearance check instead, which is safe but leaves nothing moving.

With the setting on, the blocking rail is moved out of the way first and your command is re-issued so it completes; both rails then engage manual override. The trade-off is explicit: the integration may move a rail you did not command. With it off, your command is left exactly as sent — it may not reach its target, or may not happen at all — and a warning is logged.

See also

• Cover Types — how this type compares to the others
• Configuration-Position — the coverage figure obeys the usual position limits
• Climate Mode — the summer branch is what drives the blackout escalation