Turn any remote into a first-class Home Assistant device (Universal remote integration)

[mkerstner]

Problem statement

With IR sending (#121) and receiving (#122) now shipped, Home Assistant can talk to IR devices, but only through per-device reference integrations that already know a given manufacturer's protocol. There is still no general-purpose path for a user to take an arbitrary remote and make it work with Home Assistant.

The opportunity is to close that gap with a Universal Remote integration: learn IR (and later RF) commands from any physical remote, store them, and expose them back to the user as usable entities. As @balloob framed it, you ideally should be able to grab a random second-hand remote for 20 cents, teach Home Assistant its commands, and immediately have those commands available, both as received events (press a button and it fires an event entity) and as sendable commands (create a button, light, or media player that replays a learned command). This is the natural continuation of the IR work and stays squarely in line with our sustainability value by reviving legacy remotes and devices instead of replacing them.

Community signals

• Discord discussion @abmantis @balloob et al shaped the "Universal Remote" concept, that is, learn commands from any second-hand remote, fire event entities on receive, and expose learned commands as sendable entities (button/light/media_player) via a type-first, point-and-teach config flow modelled on the Google TV Streamer IR onboarding.

• Feature request, Manual learning for IR blasters that work with TASMOTA/ESPHOME: users explicitly asking for a first-class learn workflow on the same ESPHome/Tasmota hardware our IR stack targets, a direct demand for this integration.

• Architecture discussion, Support learning different command types with remote #438: ongoing core-level design conversation about remote.learn_command and command types (IR/RF), confirming this is an unresolved platform gap, not just a user workaround.

• Community how-to, Trigger scripts via IR commands / DIY universal remote: users cobbling together a "universal remote" by hand, showing the use case is wanted but has no native, guided path today.

• Existing workaround thread, Broadlink integration: learning commands (and the recurring "How I finally managed to learn IR codes to Broadlink RM Pro" posts): learning IR today is a fiddly Developer-Tools/JSON process, evidencing strong demand for a proper config-flow UX.

• Community-built integration, HA_universal_remote (omaramin-2000): a custom integration for universal IR/RF remotes over ESPHome/Tasmota already exists, proof the community is filling this gap themselves and would benefit from a supported, first-class version.

• Continuation of #101, #121 and #122.

Scope & Boundaries

In scope

• A Universal Remote integration that can learn IR commands from any remote via a guided config flow and store them.
• Receiving: a learned command, when received, sets/fires an event entity so it can drive automations
• Sending: replay learned commands, and let the user surface them as entities, starting with button, with a path toward richer types (light, media_player, etc.) assembled from a set of learned commands
• A guided, type-first config flow: user selects an entity type, is prompted to point-and-teach each required command (on, off, volume up, and so on), with confirmation feedback ("did it work?") in the spirit of the Google TV Streamer onboarding
• Building on the existing Infrared integration and ESPHome IR proxy stack delivered in Infrared (IR) is becoming a first-class citizen of Home Assistant and can send IR commands #121/Infrared (IR) is becoming a first-class citizen of Home Assistant and can receive IR commands #122; at least one working reference setup end-to-end (learn, store, send/receive)

Not in scope

• RF learning/sending (tracked separately alongside #102); the architecture should not preclude adding it later.
• Pre-populated manufacturer command databases / cloud code lookups, since the initial focus is user-taught commands, not a shipped code library.
• Full stateful device modelling (e.g. tracking real on/off state of a "dumb" IR device that gives no feedback) beyond what a learned-command entity can reasonably represent.

Foreseen solution

This is just a proposal and should be checked / challenged

• A new integration layered on the shipped IR send/receive foundation: Infrared integration, the ESPHome IR/RF proxy, and the receiver event-entity work from #122.
• A "learn command" storage mechanism keyed to user-defined names, replayable on demand, replacing today's fiddly Developer-Tools/JSON workflow surfaced in the community signals.
• A type-first config flow with point-and-teach steps and confirmation feedback, modelled on the Google TV Streamer IR onboarding UX.
• Learned commands exposed initially as event entities (receive) and button entities (send), with a defined path to composing higher-level entity types.
• Align with the core remote.learn_command / command-type direction discussed in architecture #438.

Proposed learning config flow

The learning experience is a guided, type-first wizard, replacing today's Developer-Tools/JSON workflow. No YAML, no manual code handling.

See demo / discussion for how we could envision it:

• Concept for a Universal remote integration ux-design#65

Commands are stored per device as a fixed set of type-defined slots (protocol + code where recognised, otherwise raw timings as a fallback), and the entity exposes only the features it has commands for. After setup, a device options menu covers add command, re-teach, test (send on demand), rename, remove, delete, move to another proxy, and export/import of a device's learned commands for sharing or restore.

Risks & open questions

• Which entity types to support at launch beyond button, and how to compose a light/media_player from a set of learned commands (mapping commands to entity features)?
• How to handle stateless / feedback-less IR devices: do we want to model optimistic states, and how do we communicate uncertainty to the user?
• Storage and identity of learned commands: naming, de-duplication, sharing/export between users, and migration.
• Should this be designed transport-agnostic from day one so RF can slot in later without a rewrite?
• Relationship to existing community/custom integrations (e.g. HA_universal_remote): is there prior art or a maintainer to collaborate with?

Appetite

Medium, 1 to 2 cycles. Draft opportunity to shape further; intended primarily as a home to link ongoing discussion and context to.

Execution issues

No response

Decision log

Date	Decision	Outcome

[mkerstner]

UX discussion here: OpenHomeFoundation/ux-design#65

[Hedda]

For some additional inspiration suggest also check out "HAIR" (HA-IR from @DAB-LABS) custom component (which is another community signal too):

• https://github.com/DAB-LABS/HAIR

I believe that custom component is one possible way to more or less achieve this (however I think it is currently more focused on doing the reverse). Anyway could be of interest for brainstorming different ways forward.

[Hedda]

There was recently also this draft pull request opened for Home Assistant's core for a new profile/manifest-driven infrared emitter/receiver layer integration "with robust learn/receive flow and profile-based arm commands" containing a different solution. See:

• Add manifest-driven ZHA Infrared integration with robust learn/receive flow and profile-based arm commands home-assistant/core#175403

That implementation was primarily focused on made to work on top of ZHA/Zigbee-based IR proxy devices, but apparently its architecture was intentionally made generic for broader support.

Then there is in addition to that another open draft pull request for a generic virtual infrared remote integration too here:

• Add virtual remote integration home-assistant/core#171651