Architecture proposal: native alarms for Assist (implementation offer)

[officialxndr]

TL;DR

Home Assistant has first-class timers in Assist but no alarms. Missing alarms is the
single most-cited reason people can't retire a Google/Alexa speaker for HA Voice. I'd like to
implement native alarms, modeled on the existing timer system, and I'm looking for design
sign-off before writing the core PR. I have a working end-to-end prototype (in a Voice
Satellite fork) that already validates the hard parts — scheduling, persistence, DST, and
recurrence — so this is a concrete offer, not just an idea.

Why now / relationship to existing discussions

• Add basic set of intents for "time/tasks management" for feature parity with other voice assistants (Alexa, google home) #1046 (this track): @synesthesiam noted the time/task intents are partially shipped and
  "we're still missing… date/time and reminders, so maybe it's best to keep this open." Alarms
  are the obvious next piece.
• Alarm clock support #1089: proposes a unified alarm entity (recurrence, on/off, fires events; snooze
  "left to the actual integration"). Unresolved.
• Collect long-term statistics #559: voice request — set + spoken confirmation, smart time parsing, query, cancel/edit,
  dismiss via "stop", persistence across reboots.

Proposed design (v1 — the Assist/voice subsystem)

Mirror homeassistant/components/intent/timers.py with an alarm subsystem, because satellites
already understand the timer handler pattern and this keeps Assist consistent:

• AlarmManager + AlarmInfo in the intent component, analogous to TimerManager, but:
  • fire-time based, scheduled with async_track_point_in_time (recomputed in local time
    after each fire, so DST is correct) instead of asyncio.sleep.
  • persisted via Store; on startup, re-arm future alarms and **drop alarms overdue by

    1h** rather than firing them (per @synesthesiam's note about reboots).

  • recurrence: one-off (optional date), daily, or specific weekdays.
• Device handler hook async_register_alarm_handler(device_id, handler) mirroring the timer
  one, with events SET / CANCELLED / FIRED / SNOOZED / DISMISSED, plus
  async_device_supports_alarms(...). The ringing UI, snooze, and dismiss live on the
  device (satellite/Voice PE) — matching Alarm clock support #1089's "snooze left to the integration."
• New intents: HassSetAlarm, HassCancelAlarm, HassCancelAllAlarms, HassAlarmStatus,
  and (if we want voice snooze/dismiss beyond "stop") HassSnoozeAlarm / HassDismissAlarm,
  with sentences + responses in home-assistant-intents (smart time parsing, spoken
  confirmation).

This deliberately scopes v1 to the voice/Assist experience. The automation-facing alarm
entity from #1089 can be a follow-up (or we converge — see open questions).

Open questions I'd like the team to settle before I code

1. Manager vs. entity vs. both. Implement alarms as a timer-style subsystem in the intent
   component (my proposal), as the Alarm clock support #1089 entity, or a shared core that backs both?
   (Your "store fire-times for both" comment in Add basic set of intents for "time/tasks management" for feature parity with other voice assistants (Alexa, google home) #1046 suggests a shared core is possible.)
2. Snooze: device-side only (per Alarm clock support #1089), or also a HassSnoozeAlarm intent + manager API?
3. Persistence: Store inside the intent component, or model alarms as entities with
   RestoreEntity?
4. Intent names + slots: OK with HassSetAlarm / HassCancelAlarm / HassAlarmStatus…
   and slots {time, date, am_pm, recurrence/day, name}?
5. Overdue policy: confirm ">1h past ⇒ drop"; and how to treat missed recurring alarms.

What I'm offering

• A working reference implementation of the engine (persistence, async_track_point_in_time
  scheduling, daily/weekday recurrence, DST-safe recompute, snooze, dismiss) running today in a
  Voice Satellite fork — happy to link it.
• I've mapped it onto timers.py and drafted an AlarmManager skeleton for the intent
  component (attached/linked below).
• I'll do the core PR + the home-assistant-intents PR (English sentences/responses) + tests +
  docs, and iterate to your conventions.

Proposed delivery order

1. home-assistant-intents: intents.yaml + sentences/en + responses/en for the new intents.
2. core: intent alarm subsystem + intent handlers + assist_satellite handler hook + tests.
3. Frontend (alarm visibility) + docs.
4. Voice PE / ESPHome firmware support (separate).

Could you confirm whether you'd accept this, and weigh in on the five questions? I'll align the
design to whatever you prefer before opening PRs.