Problem statement
When someone sets a timer with Voice, they lose track of it almost immediately. They can ask what timers are running, how much time is left, or which timer is which — but there's no reliable way to see them on a dashboard. A common, everyday task ("set a 10-minute pasta timer") becomes a black box: the timer is running somewhere, but the user has no visibility into it and only limited, unreliable control once it's set.
This also means Voice timers can't fit into the rest of someone's home. A user can't glance at a card to check their timers and can't cancel or adjust a timer easily. To get any of this today, people end up building their own timer plumbing out of helpers, scripts, and automations — effectively rebuilding timer management themselves.
At the root, this is because Voice timers aren't exposed as real Home Assistant entities, so nothing else in the system can see or act on them. And this is something on how Timers are written into Home Assistant, and we have an opportunity to improve this implementation so it scales better.
Community signals
Exposing Voice timers to HA is a long-standing, recurring request. When the team surveyed the community, timers ranked as the third most requested voice feature, and a forum request to display named Voice PE timers has gathered 114 upvotes, echoing this exact problem: timers run only on the device, with no HA entity. It also shows up on GitHub (e.g. esphome/home-assistant-voice-pe#387, asking to expose timers for on-screen display) and in the architecture discussion (#1407, 12 participants).
The persistent demand is clearest in the workarounds people build to fill the gap: per-area timer helpers wired up with automations, custom persistent-timer projects, and dedicated dashboard cards — all to get something the platform doesn't offer natively.
Scope & Boundaries
In scope
- Change the underlying implementation of timers so Voice timers become real, queryable Home Assistant entities (a new
timer_list domain / entity platform)
- Accurate per-timer data: name, duration, started/created time, remaining time, and status (active / paused / ringing / finished)
- One
timer_list entity per device/satellite
- A simple interface to display and control timers (design to follow)
Not in scope
- Redesigning or migrating the existing single-item timer helper (subject of a separate architecture proposal)
- Alarms, reminders, and recurring schedules
- Persistence of timers across restarts
mobile_app timer support (currently a known gap in the POC)
Foreseen solution
Introduce a new timer_list domain, modeled after the todo entity: a single, stable entity holds an arbitrary number of concurrent timer items, so there is no entity-registry churn (items are data on the entity, not entities themselves). Each item carries a name, duration, created/started time, status, and remaining time. Voice intents add, cancel, and pause items on a per-satellite timer_list entity, which exposes timers to automations, dashboards, and the API through services, automation triggers (timer started / updated / finished / cancelled), and a websocket subscription.
A proof-of-concept already exists that demonstrates the interaction: home-assistant/core#174847 (timer_list base platform + a local_timer_list helper, with Voice timers delegating to a per-satellite entity). It has no interface yet — just the interaction. The interface still needs to be designed, but it would be simple (for example, a card that shows active timers with a countdown/progress and basic controls).
Discussion and background: home-assistant/architecture#1407 (body and comments).
Risks & open questions
- The interface has not been designed yet (though it is expected to be simple)
- In the POC, timers are in-memory only and do not survive a restart
- The automation trigger model needs to support targeting a specific timer item within a list
- Community members have asked to broaden this into a shared model for timers/alarms/reminders, and for offline/distributed ownership across devices. We need to decide explicitly what stays out of scope
Appetite
Big - This is the biggest prio for Voice right now
Execution issues
No response
Decision log
Problem statement
When someone sets a timer with Voice, they lose track of it almost immediately. They can ask what timers are running, how much time is left, or which timer is which — but there's no reliable way to see them on a dashboard. A common, everyday task ("set a 10-minute pasta timer") becomes a black box: the timer is running somewhere, but the user has no visibility into it and only limited, unreliable control once it's set.
This also means Voice timers can't fit into the rest of someone's home. A user can't glance at a card to check their timers and can't cancel or adjust a timer easily. To get any of this today, people end up building their own timer plumbing out of helpers, scripts, and automations — effectively rebuilding timer management themselves.
At the root, this is because Voice timers aren't exposed as real Home Assistant entities, so nothing else in the system can see or act on them. And this is something on how Timers are written into Home Assistant, and we have an opportunity to improve this implementation so it scales better.
Community signals
Exposing Voice timers to HA is a long-standing, recurring request. When the team surveyed the community, timers ranked as the third most requested voice feature, and a forum request to display named Voice PE timers has gathered 114 upvotes, echoing this exact problem: timers run only on the device, with no HA entity. It also shows up on GitHub (e.g. esphome/home-assistant-voice-pe#387, asking to expose timers for on-screen display) and in the architecture discussion (#1407, 12 participants).
The persistent demand is clearest in the workarounds people build to fill the gap: per-area
timerhelpers wired up with automations, custom persistent-timer projects, and dedicated dashboard cards — all to get something the platform doesn't offer natively.Scope & Boundaries
In scope
timer_listdomain / entity platform)timer_listentity per device/satelliteNot in scope
mobile_apptimer support (currently a known gap in the POC)Foreseen solution
Introduce a new
timer_listdomain, modeled after thetodoentity: a single, stable entity holds an arbitrary number of concurrent timer items, so there is no entity-registry churn (items are data on the entity, not entities themselves). Each item carries a name, duration, created/started time, status, and remaining time. Voice intents add, cancel, and pause items on a per-satellitetimer_listentity, which exposes timers to automations, dashboards, and the API through services, automation triggers (timer started / updated / finished / cancelled), and a websocket subscription.A proof-of-concept already exists that demonstrates the interaction: home-assistant/core#174847 (
timer_listbase platform + alocal_timer_listhelper, with Voice timers delegating to a per-satellite entity). It has no interface yet — just the interaction. The interface still needs to be designed, but it would be simple (for example, a card that shows active timers with a countdown/progress and basic controls).Discussion and background: home-assistant/architecture#1407 (body and comments).
Risks & open questions
Appetite
Big - This is the biggest prio for Voice right now
Execution issues
No response
Decision log