Short Answer: Broadlink Is the Fastest Retrofit, ESPHome Is the Cleanest Long-Term Path

If your actual goal is to make an old TV, mini-split, fan, or amplifier behave locally inside Home Assistant, the most practical answer today is to choose between two different kinds of local control.

Broadlink is still the easiest path when you need Home Assistant to learn arbitrary remote codes and replay them now. Home Assistant's Broadlink documentation still supports remote.learn_command and remote.send_command, and those actions remain available even after the new infrared platform arrived.

ESPHome is the cleaner path when you want a device you fully own, want to use the new native infrared entity model, want to receive IR events as well as transmit them, or want to build around Home Assistant's newer IR-first integrations. And if your air conditioner is already supported by ESPHome climate_ir, that usually beats learning a pile of raw power and mode commands by hand.

Tara's IR rule: use infrared to rescue legacy gear that has no better local interface, not to ignore a better interface that already exists.

Why This Question Keeps Coming Up

This topic is current, not fabricated. On June 18, 2026, a fresh r/homeassistant thread asked for the best option for an IR blaster that works well with HA. A month earlier, another Reddit thread asked whether anyone was building a more generic integration for the new infrared support because the poster wanted to use a Broadlink RM4 and saw that LG Infrared only solved LG devices.

The Home Assistant Community forum shows the same demand, but with more implementation pain. A thread published on April 2, 2026 asked how the new 2026.4 IR features should apply to a common Tuya Zigbee IR blaster that still appeared as a switch instead of a native IR entity. Another thread from February 23, 2026 asked what RF and IR transceivers people should buy in 2026 because older bridge workflows were awkward for code capture and playback. A March 2026 community project exists purely because some users still want local, no-cloud rescue paths for Tuya-style IR hardware.

That pattern matters. The community is not merely asking which cheap puck to buy. People are asking which local architecture is worth committing to now that Home Assistant has a real infrared platform, but not yet universal device coverage.

What Actually Changed in Home Assistant in 2026

On April 1, 2026, Home Assistant 2026.4 introduced the new Infrared integration as a building-block abstraction layer between IR hardware and device-specific integrations. The official docs are explicit: this is not something you add directly like a normal integration. It is a stateless entity model that other integrations can use for emitters and receivers.

That same April release introduced the practical idea of infrared proxies through ESPHome, similar to how Bluetooth proxies let you move radios toward the devices instead of dragging the main hub into a bad physical location.

On May 6, 2026, Home Assistant 2026.5 added Broadlink support as an infrared emitter on the new platform and also noted that SMLIGHT SLZB devices can expose an infrared platform. On June 3, 2026, Home Assistant 2026.6 pushed the receiver side further: ESPHome could now act as an IR listener for the house, and LG Infrared became the first device integration to expose remote button events through the new model.

A local smart home hub using IR control to bring legacy devices into Home Assistant
The new infrared platform helps Home Assistant talk to legacy gear locally, but you still need to choose whether you want the fastest retrofit path or the cleanest long-term hardware ownership.

Which Path Fits Your House

The most useful way to choose is to start from the device and workflow, not the gadget marketing.

Situation Better answer Why
You want to learn arbitrary commands for a TV, fan, projector, amp, or AC remote right now Broadlink learned-command path Home Assistant's Broadlink docs still support direct learning, replay, sequences, and base64 command injection without waiting for a device-specific IR integration.
You want a fully owned local node, native IR entities, or a receiver that can trigger automations ESPHome IR proxy ESPHome's infrared and IR/RF proxy components were designed for the new Home Assistant infrared API and can both send and receive raw timings.
You have a supported mini-split or window AC and want thermostat-style control instead of button macros ESPHome climate_ir ESPHome's climate IR component already models compatible air conditioners as climate devices instead of a loose collection of learned button presses.
You already own a Tuya-style IR puck and want to keep it off the cloud Only as a rescue path Community projects exist to replace Tuya cloud dependencies with Tasmota, MQTT, or ESPHome-style local control, but that is a salvage path, not the cleanest new install.
The device already supports local IP, serial, MQTT, Zigbee, Z-Wave, Matter, or a vendor-local API Use that instead of IR Infrared is typically one-way and assumed-state. If the device offers a richer local interface, that will be easier to automate and support.

This is still the most universally useful retrofit path.

Home Assistant's Broadlink documentation explicitly says the infrared entity is complementary to the older remote entity and that the existing remote.learn_command and remote.send_command actions remain available. In other words, the new IR platform did not kill the older learned-command workflow that many people still depend on.

What Broadlink is good at

  • Learning arbitrary button presses from remotes you already own.
  • Sending named commands back to a device later.
  • Sending sequences such as power on, set input, and turn off display in order.
  • Sending raw base64 codes when you already have them from elsewhere.

The official docs also spell out something practical many users miss: learned codes are stored in /config/.storage/ in a device-specific JSON file, which makes the setup portable and inspectable even though Home Assistant warns you not to edit those files by hand.

If you are automating a legacy AV stack or a single-room mini-split and you do not need the new native IR entity model, Broadlink lets you move immediately. The best June 2026 Reddit thread on this topic still had users recommending the RM4 Mini while noting the same practical tradeoff: you learn the IR commands in Home Assistant first, then it works well afterward.

That is why the Broadlink path remains the least risky answer for arbitrary remotes: it already solves the "I have a dumb device and a working remote" problem without requiring Home Assistant to have a device-specific infrared integration for that exact appliance.

Do not confuse "can learn and send raw IR commands" with "will automatically appear as a shiny native infrared device in every Home Assistant config flow." The new native IR platform and the old Broadlink remote path are related, but they are not identical. A Home Assistant maintainer explained on Reddit in the April 2026 IR release thread that the new infrared platform does not automatically appear alongside existing Broadlink remote entities because the command format expectations differ.

Path 2: Use ESPHome When You Want Full Ownership and the New Native IR Model

ESPHome is the cleaner path when you are designing around local ownership instead of simply retrofitting an existing Broadlink puck.

ESPHome's own docs now provide a ready-made Infrared & radio frequency proxy project whose stated purpose is to allow Home Assistant to control infrared and radio frequency devices. If you want the shortest ESPHome path, start there instead of freehanding a YAML from memory.

What the ESPHome IR model exposes

ESPHome's infrared component represents an infrared entity as a stateless component that can either transmit raw timing sequences or receive them and forward them to API clients such as Home Assistant. That is the architectural difference from the older "learned remote button names" model. The new API is built around raw timings, optional carrier frequency, repeat count, and receiver events.

Its IR/RF proxy docs also clarify an important hardware detail: an IR proxy instance must be configured as either a transmitter or a receiver, not both. If you want both directions, create separate instances. And for infrared transmission specifically, ESPHome says the linked remote_transmitter should normally use a carrier_duty_percent around 30-50%.

Why this path is stronger long term

  • You can fully own the hardware and firmware.
  • You can choose exactly where the emitter or receiver sits in the room.
  • You can use the new Home Assistant infrared entity flows instead of only the legacy remote model.
  • You can receive IR events and use a handheld remote as an automation trigger source.

This is the path to choose if the house is going to stay on Home Assistant for years and you do not want the IR layer to remain a sealed appliance.

Path 3: If Your AC Is Supported, Use ESPHome Climate IR Instead of Button Macros

This is the most overlooked path, and for air conditioners it is often the best one.

ESPHome's IR Remote Climate component says it controls compatible AC units by sending the same infrared control signal the handheld remote would use, and it explicitly notes that there is a growing list of compatible units. When your model is supported, you get an actual climate entity instead of scattered power, mode, temperature, and fan-speed button macros.

That matters because many air conditioners do not work like televisions. Their remotes often send a full state packet, not a small command such as "volume up." If you model that device with disconnected learned button presses, you can create a lot of brittle automations. If climate_ir supports the unit, use it.

What the New Native IR Platform Can Actually Do Today

As of June 19, 2026, the official Home Assistant documentation I could verify shows a promising but still short list of device-specific infrared integrations.

  • LG Infrared can control an LG TV through a configured emitter and can also create event entities from receiver-side remote button presses.
  • Samsung Infrared can control Samsung TVs through a configured IR transmitter.
  • Marantz Infrared can control a Marantz PM6006 amplifier through a configured IR transmitter.

That is real progress, but it is not the same as saying the new infrared platform is already a universal replacement for Broadlink-style learning across every TV, AV receiver, fan, or mini-split in a house.

The important distinction: the new IR platform is a standard way for Home Assistant to talk to IR hardware and device integrations. It is not yet a universal library that understands every arbitrary remote in your home.

The Constraint You Must Respect: Infrared Is Usually One-Way and Assumed-State

Home Assistant's Samsung and Marantz infrared docs are explicit that these integrations operate in a one-way, fire-and-forget fashion and therefore use assumed states. That is the core operational truth of most IR control.

Home Assistant can send a signal. It usually cannot confirm the device actually changed state, whether the line of sight was blocked, or what the exact real-world state is now. That is why IR is acceptable for many TVs and fans, acceptable with care for some mini-splits, and the wrong primitive for anything safety-critical.

Prefer better local protocols when they exist

If an amplifier supports serial, a TV supports a local IP API, or a device can be paired locally over Zigbee, Z-Wave, Matter, or another proper protocol, use that instead. Infrared is excellent for legacy rescue. It is not the first protocol you should choose when a better local protocol already exists.

Do not use IR as the sole control path for safety-critical devices

Do not build a system where a one-way infrared command is the only truth source for a garage door, lock, alarm mode, or other state that matters for real safety or liability. If you automate a door or cover at all, pair the control path with physical position sensing and a protocol that can provide confirmed state.

The Rough Edges Still Showing in June 2026

1. Native IR is real, but not universal yet

The Home Assistant Community thread about ZHA Infrared Remote Control: 2026.4 IR features is a good example. The user wanted to use the new IR UI and native remote features, but their Tuya TS1201 still appeared as a switch-like entity instead of a native IR device. That is exactly the kind of gap you should assume still exists on some hardware.

Two Home Assistant core issues from late April and early May 2026 documented Broadlink users not seeing RM4 Mini or RM4 devices behave as expected in native infrared workflows right away. Both issues are now closed, so they are not proof of a permanent defect. They are still useful evidence that the native Broadlink IR path was rough enough in early 2026.5 that you should verify your exact hardware before rebuilding a working room around it.

3. Tuya rescue paths exist because official support remains awkward

The Home Assistant Community project for Local Control for Tuya IR Blasters exists because users still want to replace Tuya cloud control with local Tasmota and MQTT paths. That is useful if you already own the hardware. It is not a great reason to make that hardware your first-choice architecture for a fresh local install.

Tara's Take

If a homeowner asks, "How do I bring my dumb TV and old mini-split into Home Assistant locally?" the answer is no longer "you need a random pile of custom hacks." Home Assistant now has a real IR architecture, and ESPHome has a proper local proxy story for it.

But the operationally boring answer is still to separate the use cases.

Use Broadlink when you need the quickest universal retrofit and already know the device will be infrared-only for the foreseeable future.

Use ESPHome when you want the IR layer to be fully owned, receiver-capable, and aligned with the new Home Assistant-native entity model.

Skip infrared entirely when the device already offers local network or serial control that can report real state back to Home Assistant.

If this IR question is really a hardware, protocol, or no-cloud planning question in disguise, these guides are the next useful read.

FAQ

What is the best Home Assistant IR path right now?

For the fastest universal retrofit, Broadlink's learned-command path is still the least work. For full local ownership, native infrared entities, and receiver events, ESPHome is the cleaner long-term path. If your mini-split is supported by ESPHome climate_ir, that is usually better than learning raw button codes.

Can one IR blaster control more than one device?

Yes. One emitter can store and send commands for multiple devices as long as the placement and line of sight work for that room. The tradeoff is still state: Home Assistant usually cannot confirm the real device state over IR alone.

Can Home Assistant learn commands from my existing remote?

Yes. Broadlink can learn named commands through remote.learn_command, and ESPHome receivers can capture raw timing sequences and forward them as Home Assistant events. Which is better depends on whether you want a fast retrofit or a fully owned ESPHome setup.

Can I use the new native infrared platform with every Broadlink or Zigbee IR device?

Not automatically. Community threads and early 2026.5 issue reports showed some Broadlink and Zigbee IR devices failing to appear as native infrared entities in every workflow. Treat native IR as promising and improving, but verify your exact hardware path before you rip out a working learned-command setup.

Should I use infrared if the device also supports local IP or serial control?

Usually no. If the device has a good local network or serial integration, that path will usually be more reliable, easier to automate, and better at reporting real state than infrared.