Turn any remote into a first-class Home Assistant device

[mkerstner]

Problem statement

With IR sending (#121) and receiving (#122) now shipped, Home Assistant can talk to IR devices using the infrastructure built around the approach to have 1-integration-per-brand references that know a given manufacturer's protocol.

This way, for users enabling sending and receiving commands remains as easy as selecting a supported brand from a list of.

While the original opportunity was around ways to learn and store IR commands discussions and feedback has shown that there already is quite some traction around that topic based on the infrared infrastructure recently introduced.

So, consequently focusing more on how to create those 1-integration-per-brand integrations easier is key - while relying and what our wonderful community already is working on, e.g. @DAB-LABS with their HAIR HACS integration.

=> Jump directly to this comment here to follow the latest idea & approach around this topic.

The opportunity is to close that gap with a Universal Remote integration: Use IR commands from any physical remote and expose them back. 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, HAIR

• 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

• 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;
• 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

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

Current experimentation is driven based on the HAIR HACS integration to create 1-integration-per-brand integrations.

=> Chime in on the Discord discussion

• 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

See demo / discussion for how we could envision it.

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

• Mainly risk of coverage of supported brands

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

UPDATE: An extended variant of that last mentioned PR for virtual remote integration is available as a custom integration component via HACS:

• https://github.com/orandasoft/universal-remote

[orandasoft]

I have continued developing the original virtual_remote integration that I submitted as a Home Assistant Core pull request. The project has since evolved into the HACS-based Universal Remote integration and now includes the following functionality:

• Create multiple logical remotes using existing infrared emitter and receiver entities
• Send infrared commands through a linked infrared emitter entity
• Import complete command lists from supported infrared-protocols library codesets
• Add and manage custom infrared commands manually or through command learning
• Create optional button entities for individual commands
• Add a TV media player entity with power, volume, channel, playback, and source controls
• Expose received commands as Home Assistant events for automations using the infrared receiver entity
• Support NEC and NEC1-F16 decoding, including LG TV Japan commands (other protocols will be added as the decoders become available in the infrared-protocols library)
• Add Japanese TV tuner selection with tuner-aware number buttons
• Provide diagnostics and repair notifications for missing linked infrared entities

I intend to add these features as well

• import of flipper .ir commands
• export of infrared commands as a flipper .ir compatible file

The latest version can be installed through HACS as a custom repository integration: https://github.com/orandasoft/universal-remote

[DAB-LABS]

Maintainer of HAIR here, a HACS integration doing exactly this on the native infrared platform. We launched in May, so call this ten intense weeks of field notes and our users have already stepped on most of the rakes this flow might meet, so I thought I'd share my experience:

• Repeat frames will eat a naive learn flow. Held buttons re-send frames (some protocols every ~100ms), and a receiver hears them all. You need repeat filtering and dedup by timing fingerprint or one press becomes ten "commands".
• Receiver jitter means exact matching fails. Same button, same remote, timings drift a few percent per press which can amplify when retransmitted. Match on classified pulse patterns, not raw values.
• The echo problem: once users have both a blaster and a receiver, the house hears its own sends. If event entities fire on those, every automation becomes a feedback loop. We gate triggers on "did this capture correlate with our own transmit" and it has to be built in from day one, could be a miserable retrofit.
• Stateful AC remotes will poison the learn flow. Their frames are full state snapshots, not buttons. Two different buttons can emit identical frames (verified in community capture files), and a learned "mode: cool" secretly carries whatever temp/fan was on the remote at capture. Worth deciding early whether v1 scopes ACs out.
• Some remotes are anti-replay by design. Dyson fans put a rolling counter in every frame and reject a replayed one, which caps naive capture-and-replay at ~33% reliability. We handle it by decoding and re-encoding with an advanced counter. Rare, but it means "replay what you learned" cannot be the whole architecture.
• On the platform contract: an explicit capture-window/arm primitive (arm for N seconds on demand) would serve this better than standing listeners, same conclusion as the recent Broadlink receiver discussion in core #175259.

Happy to share more of what this looks like in practice if useful.

Whatever v1 ships, integrations like mine can build above it as long as learned commands stay addressable on the platform.

~DAB

[mkerstner]

@orandasoft and @DAB-LABS -> Awesome, thanks for sharing your insights and experience!
There for sure is overlap and learnings that we should jointly review.

Not sure if you saw but we've expanded the initial flow in the UX demo to also incorporate not just the manual learning path but also using existing IR databases as a preferred path to reduce potential friction and better UX by just taking known commands if available. Curious about your thoughts on that given your experience.