Sleep Schedule with Dynamic Alarm Sync and Offset

[adyversus]

Feature Request: Sleep Schedule with Dynamic Alarm Sync and Offset

Is your feature request related to a problem? Please describe.
Currently, if the sun rises (e.g., 6:00 AM) before a user's scheduled alarm (e.g., 9:00 AM), the adaptive tracking opens the covers, potentially waking the user prematurely. While "Manual Overrides" exist, they require external automations to manage and reset.

Describe the solution you'd like
I would like to propose a "Sleep/Privacy Mode" integrated into the Priority Override Pipeline. This would allow the cover to ignore sun-tracking during a defined sleep window that is linked to a mobile alarm.
Requested Parameters:

1. Sleep Start Time: A fixed time (e.g., 22:00) when the cover moves to a "Closed" position and tracking is disabled.
2. Wake-up Alarm Entity: A selector for a sensor.next_alarm (from the HA Companion App or other alarm entities).
3. Wake-up Offset (Optional): A duration in minutes (e.g., -10) to trigger the transition back to "Adaptive" tracking before the alarm rings to simulate a natural sunrise.

The Scenario Logic
• 22:00 (Start): The cover automatically closes (0%). The integration enters "Sleep Mode" and ignores all Solar/Climate calculations.
• 06:00 (Sunrise): The sun rises, but the cover remains closed, suppressing the standard "Start Time" or "Sunrise" triggers.
• 08:50 (Alarm - Offset): (Calculated as Alarm at 09:00 minus 10 minutes). The "Sleep Mode" ends, and the cover transitions to its current Adaptive/Solar position.
• 09:00 (Alarm): The alarm rings; the room is already brightened by natural light.
Describe alternatives you've considered
• Manual Overrides: Requires a 12-hour timeout or "Infinity" setting, which then needs a separate automation to call adaptive_cover_pro.reset_manual_override at alarm time.
• Complex Templates: Creating template sensors to calculate next_alarm - offset is difficult for average users.
Additional context
Integrating this into the core "Override Pipeline" (perhaps between Manual and Solar) would make Adaptive Cover Pro a complete "set-and-forget" solution for bedrooms, improving both sleep quality and the wake-up experience.

---

Pro-tip: When you post this, you can title it: [Feature Request] Integrated Sleep Mode with Alarm Offset.

[jrhubott]

Nobody wants their bedroom blinds flying open at 6 AM when the alarm isn't until 9, so I get exactly why you'd want this. You can actually build it today with a template binary sensor paired with either Force Override or a Custom Position slot.

1. Create a template binary sensor in configuration.yaml or via the Template integration:

template:
  - binary_sensor:
      - name: "Sleep Mode Active"
        state: >
          {% set alarm_str = states('sensor.phone_next_alarm') %}
          {% if alarm_str not in ['unavailable', 'unknown', ''] %}
            {% set wake_time = alarm_str | as_datetime | as_local - timedelta(minutes=10) %}
            {{ now().hour >= 22 or now() < wake_time }}
          {% else %}
            {{ now().hour >= 22 }}
          {% endif %}

Replace sensor.phone_next_alarm with your alarm entity and 10 with your offset in minutes.

2. Wire it up in Adaptive Cover Pro. Two options here, depending on how strict you want the sleep lock:

Force Override (priority 100) keeps the cover at 0% no matter what. If you physically move it at 2 AM, it'll push back. Pick this if you really need it to stay closed.

Custom Position (priority 77 by default) also closes the cover during sleep, but Manual Override at priority 80 still wins. Get up in the middle of the night and open the blind yourself, it respects that. For a bedroom, this is probably the better default. Add the sensor to Custom Position Sensor 1, set Custom Position 1 to 0, and leave the priority at 77.

As for building this natively, it's something I'd like to add eventually. The complication is alarm entity diversity: Companion App, Google Calendar, custom sensors all work differently, and getting that right natively would take more work than it sounds. The template route gives you the same result today with full control over the logic.

For details, see the Force Override and Custom Position wiki pages.