Control RF Devices with Home Assistant: IR/RF Proxy Guide

Walk into any UK DIY shed and you will find them: remote-controlled ceiling fans, motorised roller blinds, wireless mains outlets, all sold on the premise of convenience. They use 433.92 MHz radio signals — the same unlicensed band that has powered cheap remote controls for decades. The catch? Every smart home platform, Home Assistant included, has treated these devices as invisible. They were analogue islands in an increasingly connected home.

That has changed in 2026. A combination of the new ESPHome ir_rf_proxy component and native RF support in Home Assistant 2026.5 means that 433 MHz RF devices are now first-class citizens in your automations — no cloud, no proprietary hub, no reflashing firmware for each new command.

The Problem With RF Devices in Home Assistant

Radio frequency devices speak a one-way dialect. A 433 MHz RF remote fires a burst of radio pulses encoding an "on" or "channel 2" command, and the receiver acts on it. There is no acknowledgement, no network address, no API. Until recently, intercepting and replaying those pulses required either a proprietary bridge or writing raw timing values into ESPHome firmware — and reflashing the device every time you wanted to add a new command.

Infrared (IR) faced a similar problem. Home Assistant could send IR commands to a TV or air conditioner via ESPHome, but each command had to be baked into the firmware at compile time. If you bought a new TV or wanted to control a second air conditioner, you needed to edit your YAML, recompile, and reflash over the air. It was workable but slow, and it made IR feel like a second-tier integration rather than a proper platform.

Both of those limitations are now resolved.

The ESPHome IR/RF Proxy Component

The ir_rf_proxy component, introduced in ESPHome 2026.1.0, acts as a runtime bridge between Home Assistant and your radio hardware. Instead of encoding commands in firmware, the proxy streams raw timing data — alternating microsecond mark and space durations — between Home Assistant and the ESP device over the encrypted native API. You can transmit a new command or capture a signal from an existing remote without touching the YAML or reflashing anything.

The component supports two platforms:

• Infrared platform — creates an infrared entity linked to a remote_transmitter or remote_receiver. The transmitter requires a carrier duty cycle of 30–50% (typical for IR LEDs). The receiver can declare its demodulation frequency, for example 38 kHz for a TSOP38238 receiver module.
• Radio frequency platform — creates a radio_frequency entity. The transmitter is set to 100% duty cycle because RF hardware handles its own modulation. You declare the carrier frequency — typically 433.92 MHz for UK remotes or 868 MHz for some European devices.

For 433 MHz work, the CC1101 transceiver module is the recommended hardware. Costing around £3–£5, the CC1101 covers all common sub-GHz bands (315, 433, 868, and 915 MHz) and wires directly to an ESP32 via SPI. ESPHome's CC1101 integration exposes on_transmit and on_complete triggers that the proxy uses to switch the module between transmit and receive modes automatically.

The component is part of the broader ESPHome ecosystem for Home Assistant, which handles everything from DHT22 temperature sensors to custom displays — all without an MQTT broker or cloud dependency.

Experimental Status — Read This First

The ir_rf_proxy component carries an explicit instability warning from the ESPHome team: "This component is EXPERIMENTAL. The API may change at any time without following the normal breaking changes policy."

In practice this means the YAML configuration syntax, the entity types exposed to Home Assistant, or the underlying API protocol could change in a future ESPHome release without the usual deprecation notice. If you build automations around this component, be prepared to update your configuration when upgrading ESPHome. For a home lab or personal project this is entirely acceptable; for a production deployment relied on by other household members, factor the risk in accordingly.

Home Assistant 2026.5 — RF as a First-Class Platform

The ESPHome component alone would be useful, but Home Assistant 2026.5 went further by adding native RF entity support to the core. The release notes describe radio frequency joining infrared as a "first-class citizen" — meaning the RF transmitter is now a proper Home Assistant entity type, not a workaround or custom component.

The architecture is straightforward. An RF transmitter (your ESPHome device with CC1101, or a supported Broadlink RM4 Pro) registers as an radio_frequency entity. Device-specific integrations — for blinds, fans, outlets, and so on — then reference that transmitter entity to send commands. When you set up a new RF device in Home Assistant, you simply pick your transmitter from a dropdown; no YAML on the Home Assistant side is required.

The 2026.5 release shipped with two device integrations out of the box: Honeywell RF string lights and Novy cooker hoods. These are narrow examples, but they demonstrate the pattern that third-party integrations can follow. Existing ESPHome users can already use the ESPHome Device Builder to flash and configure RF-capable boards without touching a terminal.

For UK homes, the most immediately useful targets are the 433.92 MHz RF outlets and sockets sold widely on Amazon and in hardware shops — the kind that come with a handheld remote and no Wi-Fi chip. Those outlets can now be switched by Home Assistant automations, timed schedules, or voice assistants without any hardware modification to the outlet itself.

Home Assistant 2026.6 — Listening to IR Remotes

Home Assistant 2026.6 completed the picture for infrared by adding IR receiver event entities. Previously, Home Assistant could send commands to a TV or air conditioner but had no way to know what was happening at the physical remote. If someone adjusted the volume with the original remote, Home Assistant's state for that device became stale immediately.

The 2026.6 IR receiver integration changes this. When an ESPHome device with an IR receiver captures a signal, it fires an event in Home Assistant that can be used directly as an automation trigger. The release notes put it plainly: Home Assistant can now keep itself in sync with the original remote — use the remote that came with the device, and Home Assistant sees it happen instead of being left in the dark with stale state.

The first device integration to use this is LG Infrared, which exposes received commands as named events. But the ESPHome IR receiver support is generic — any IR remote near the receiver will produce events, which means you can repurpose a spare remote as an in-room Home Assistant controller with no additional hardware cost.

This pairs naturally with the Home Assistant automations system: an IR event trigger can fire any automation, run a script, or change a scene — treating a £2 TV remote as a fully programmable input device.

What You Need to Get Started

For RF Control (433 MHz)

• ESP32 development board — any DevKit board works; the Wemos D1 Mini32 or a generic 38-pin ESP32 board costs £3–£6 from UK suppliers such as The Pi Hut or Pimoroni.
• CC1101 transceiver module — around £3–£5 on eBay UK or AliExpress. Covers 315, 433, 868, and 915 MHz bands. Connects via SPI (6 wires plus power).
• ESPHome 2026.1.0 or later — installed as a Home Assistant add-on or standalone Docker container.
• Home Assistant 2026.5 or later — required for the radio_frequency entity platform.

For Infrared Control and Receiving

• ESP32 board — same as above.
• IR LED (transmit) — a 940 nm IR LED and a 2N2222 transistor as a driver. Total component cost under £1.
• IR receiver module (receive) — a TSOP38238 or similar 38 kHz demodulator. Around £1–£2. Plug in and point it towards the remote you want to capture.
• Home Assistant 2026.6 or later — required for IR receiver event entities.

What You Can Automate

Combining RF transmit, RF receive, IR transmit, and IR receive opens up a class of devices that were previously inaccessible to Home Assistant entirely:

• RF ceiling fans — set speed and light state on a schedule, or tie them to a temperature sensor.
• Motorised blinds and roller shutters — open at sunrise, close at sunset or when a Lux sensor detects direct sunlight on a window.
• RF mains outlets — control lamps, heaters, or Christmas lights without replacing the socket.
• Air conditioner state sync — capture IR commands from the original remote so Home Assistant always knows the current mode and temperature setpoint.
• Spare remotes as controllers — dedicate an old TV remote as a bedside panel: volume-up becomes bedroom lights on, volume-down becomes lights off.
• Garage doors and gate motors — many use 433 MHz rolling-code or fixed-code remotes compatible with the CC1101 receiver.

The common thread is longevity: none of these devices need to be replaced. A ceiling fan bought in 2015 with a 433 MHz remote can join a 2026 Home Assistant setup without modification, extending its useful life rather than adding to landfill.

Next Steps

The ESPHome documentation at esphome.io/components/ir_rf_proxy covers the full YAML configuration for both IR and RF platforms, including CC1101 wiring and the on_transmit/on_complete trigger pattern. Given the experimental status of the component, it is worth bookmarking the changelog so you catch any breaking changes early.

If you are new to ESPHome, start with the ESPHome beginner's guide to set up the add-on and flash your first device before layering in the IR/RF proxy. Once you are comfortable with the YAML structure, adding the proxy platform is a matter of a few extra lines — and no reflashing required from that point on.