Keep Awake on a Schedule

[rigorimpossible]

Description of the new feature / enhancement

There needs to be a schedule for the keep awake feature allowing users to set a specific time range, similar to the Night Light feature. So that the computer would only be awake during that time period and after that, the computer can sleep or whatever.

Scenario when this would be used?

When work hours are done, the computer can now freely sleep.

Supporting information

Sleep after a scheduled keep awake.

[dend]

Thank you for the suggestion, @rigorimpossible! Closing this issue as a wont-fix mainly because this would overlap heavily with capabilities built into Windows Task Scheduler to run processes at a certain time (see #23340 and #22634). I think the idea has merits but also a lot of caveats that would need to be considered. This could be something that we look into in the future but not on the immediate horizon (there are some architectural changes that need to roll out first).

[dend]

Re-opening this issue as I want to revisit adding the scheduling functionality to Awake.

[SilverGreen93]

This feature will be of great use for me too. I want to keep my PC from sleeping only during work hours. After work, I want to set it to sleep. Hope to see the ability to define a schedule in the future.

[guoh27]

The Windows Task Scheduler is too complex and requires command line parameters. I think it is better to add it in the GUI.

[trajore]

I want to work on this feature

[trajore]

I want to work on this feature

Scheduled Mode Proposal (Awake) [Spec Summary for Discussion]

1. Goal

Add a new Scheduled mode to Awake that keeps the PC awake only during a user-defined daily time window (supports crossing midnight), reverting to normal sleep behavior outside that window.

2. Why?

Right now, you either leave Awake running (and maybe forget to turn it off) or keep re‑setting timers. People with fixed work hours or night shifts want a “set once” option. Personal context: I often forget to turn Indefinite Awake off (laptop ends up heating in my bag 😅). A daily Scheduled mode would solve that. Below is the proposal:

3. Scope (MVP)

• One daily window (start + end times, local clock, minutes since midnight).
• Cross‑midnight windows supported (e.g., 22:00–06:00).
• Half‑open interval [start, end); if start == end --> treated as disabled (warn user).
• Execution state asserted only inside window.
• Persist & auto-resume on startup.
• Tray: new “Scheduled” mode.
• Settings UI: start time, end time, overnight info tip, disabled warning.
• Telemetry: single “Configured” event (basic adoption metrics).

4. Not Doing (for now)

• Multiple windows
• Weekday filters
• Calendars / work hours integration
• DST smoothing magic
• Activation/deactivation telemetry spam
• Power policy tweaks or battery logic

5. Data Model

• Add enum member: SCHEDULED = 4 (appended to preserve existing values).
• Persist scheduleStartMinutes & scheduleEndMinutes (ints 0–1439).
• Derived: crossesMidnight = start > end; window length computed.

6. Core Logic

• Active rules:
  • Disabled if start == end
  • Non‑crossing: start <= now < end
  • Crossing: now >= start OR now < end
• Single timer schedules next boundary (no polling loops).
• Enter -> assert execution state (like Indefinite); Exit -> clear.
• Logging only on transitions & invalid config.

7. UI / UX

• Mode dropdown adds “Scheduled (daily window)”.
• Time pickers & info tip (overnight explanation).
• Warning if start == end.
• Tray baseline: [Scheduled] (later enhancement: show remaining / inactive state).

8. Telemetry (MVP)

Event: AwakeScheduledKeepAwakeEvent Fields: startMinutes, endMinutes, windowMinutes, crossesMidnight, keepDisplayOn, activationPhase="Configured".

9. Planned PRs

1. Scaffolding: enum, persisted fields, resources, tray option, telemetry class (no logic).
2. Backend: schedule evaluator + timer + activation + “Configured” telemetry.
3. Settings UI: time pickers + validation.
4. Polish: tray remaining-time / inactive labeling, optional activation/deactivation telemetry & docs.
5. (Optional) Hardening: time change / resume handling, DST notes.

I wanted each PR to be backward‑compatible that leaves Awake stable even if later phases delay.

10. Testing

• Unit tests: evaluator (day, overnight, disabled, edge boundaries).
• ViewModel tests: minutes ↔ time mapping, validation.
• Manual: switching modes, cross-midnight, modifying window while active.

11. Risks & Mitigation

Risk	Mitigation
Off-by-one boundaries	Pure evaluator + unit tests
Timer drift on clock change	Accept initially; optional hardening later
User confusion (start == end)	Inline warning & log
Enum regression	Append only, review checklist

12. Open Questions (Need Maintainer Input)

1. Tray inactive text: show “[Inactive]” or “Starts in hh:mm”? (Default: “[Inactive]”, countdown later)
2. Include remaining time in MVP (Phase 2) or defer to polish (Phase 4)?
3. Is a separate activation/deactivation telemetry event desired early, or keep telemetry minimal initially?
4. Auto-adjust end when start == end (e.g., +60 min) or leave as explicit “disabled” state (current proposal: warning only)?
5. Any objection to using minutes (int) vs storing formatted time strings?

13. Rollback Strategy

If issues arise, the plan is to disable scheduler invocation (keeping persisted values harmless). No breaking migration needed.

If this direction looks good, I’ll start with PR 1 exactly as described.

Feedback appreciated on open questions & any additional constraints maintainers want applied. @dend @cinnamon-msft

Best Tanmay