The Home Assistant 2026.5 release notes carried two headlines for anyone working on small commercial buildings. The serial-port proxy got most of the trade-press attention. The other one is bigger.
The 2026.5 release made sub-gigahertz RF a first-class platform in Home Assistant. The translation: a $10 CC1101 transceiver wired to an ESP32 now natively controls the 315, 433, 868, and 915 MHz device universe. Motorized blinds. Curtains. Garage doors. Ceiling fans. Wireless wall switches. RF outlets. Doorbells. Holiday string lights. The entire stranded inventory of legacy radio devices that sat outside the local-first stack for a decade because nobody wanted to write a one-off bridge.
The Nabu Casa framing in the release notes is explicit: "Instead of throwing out a working motorized blind because it's 'dumb', you can integrate it." That is a consumer-facing line. The small-building version is more direct: the entire RF inventory of a 1990s-to-2010s commercial site now has a $10 on-ramp into the same stack that runs the sump pump.
What changed, in one paragraph
Until 2026.5, RF in Home Assistant was the domain of either expensive single-purpose hubs (the Broadlink RM4 Pro at $90, limited to 433 MHz, cloud-dependent for many integrations) or one-off ESPHome custom components that worked if you were willing to debug timing diagrams. The 2026.5 release puts a native RF transmit/receive platform in core, with the CC1101 as the recommended hardware and ESPHome as the wiring. Two device-specific integrations shipped the same day — Honeywell String Lights and Novy Cooker Hood — and the platform is open enough that the long tail of brand-specific bridges can land as community integrations without forking anything.
The bill of materials is short.
| Part | What it does | Cost |
|---|---|---|
| ESP32-S3 mini board | The SPI host that runs ESPHome and talks to Home Assistant over Wi-Fi or Ethernet | $3-7 |
| CC1101 module | Sub-GHz transceiver. Supports 300-928 MHz, OOK/FSK/GFSK/MSK modulation, programmable from 600 baud to 500 kbaud | $5-12 |
| Antenna and dupont wires | SMA or whip antenna, six SPI jumpers | $2-5 |
| Total | One RF bridge per site, covers every device in line-of-sight range | $10-25 |
One bridge per site. Most small commercial buildings will need exactly one. The bridge is software-defined — a config change makes the same hardware switch between a Dooya blinds remote, a Hormann garage opener, and a Honeywell doorbell.
Why this matters for buildings, not for hobbyists
The hobbyist version of this story is "now I can dim my holiday lights from the same dashboard." The boiler-room version is different.
A 1990s-to-2010s small commercial site has accumulated a 433 MHz remote drawer. A typical site:
- Two to six motorized blinds or shades, each with a wall remote that nobody knows where it is. The blinds get adjusted twice a year and break the third year because the remote battery dies and nobody notices.
- One to three garage or overhead-door openers. Some are old enough to use fixed codes; the newer ones use rolling codes and cannot be cloned, but the position sensor and door status can be read over the same RF bus.
- A wireless doorbell and one or two wireless chimes. The chime is the canonical "fire-and-forget" alert path nobody monitors.
- A handful of RF outlets and lamp modules from the X10 / generic 433 MHz generation.
- Two or three legacy occupancy or door/window sensors from an alarm panel that has long since been decommissioned but is still wired in. The sensors still work; the panel does not.
Before 2026.5, integrating any of those into the local monitoring stack cost more than the device. The choice was either a $90 Broadlink hub (cloud-tethered, limited), a $400 industrial sub-GHz bridge, or eight hours of custom-component work on ESPHome. Most operators chose option four: leave them stranded.
After 2026.5, the cost collapsed to a $10 ESP32+CC1101 bridge plus the integration labor to write the device-specific YAML. For most of the long tail, the YAML is shorter than this paragraph.
What the YAML looks like
This is the Dooya blinds example, which is the most common motorized-blind brand in small commercial sites in the northeast US. The community published the working protocol last year; the 2026.5 release just made it land in core without a fork.
esphome:
name: rf-bridge
esp32:
board: esp32-s3-devkitc-1
spi:
clk_pin: GPIO12
mosi_pin: GPIO11
miso_pin: GPIO13
cc1101:
cs_pin: GPIO10
gdo0_pin: GPIO4
remote_transmitter:
pin: GPIO4
carrier_duty_percent: 100%
cover:
- platform: template
name: "Boiler Room Blinds"
open_action:
- remote_transmitter.transmit_raw:
carrier_frequency: 433920000
code: [<dooya_open_code>]
close_action:
- remote_transmitter.transmit_raw:
carrier_frequency: 433920000
code: [<dooya_close_code>]
That is the entire bridge for one device. The same hardware, with different cover or switch entries, handles the rest of the site. The integration labor per device is about fifteen minutes once you have the protocol; the protocols for the common brands are already in the community wiki.
The retrofit math
This is the part that changes the conversation with a building owner.
| Layer | Before 2026.5 | After 2026.5 |
|---|---|---|
| RF bridge hardware per site | $90 Broadlink (cloud) or $400 industrial bridge | $10-25 ESP32 + CC1101 |
| Per-device integration labor | 4-8 hours custom ESPHome component | 15-30 minutes YAML per device |
| Cloud dependency | Yes for Broadlink, no for the industrial bridge but at 16x the cost | None. Bridge talks to the local Home Assistant over LAN. |
| Brand coverage | Whatever the bridge vendor decided to ship | Anything in 300-928 MHz with a documented protocol |
| Lifecycle risk | Bridge vendor goes dark, integration goes dark | Open-source firmware, open-source platform, replaceable hardware |
The cost of integrating a site's entire stranded RF inventory dropped from "more than the building owner will pay" to "cheaper than the labor to argue about whether to do it."
What we are doing about it on the 40-device community center deployment
The 40-device upstate New York community center has, on inventory, four motorized blinds with dead remotes, two garage openers, a doorbell that nobody hears in the back office, and what we count as eleven X10-era outlets that have been ignored for fifteen years.
The plan for the next site visit, in light of 2026.5, is one bridge.
- One ESP32-S3 + CC1101 bridge mounted near the breaker panel where it has line-of-sight to most of the building. Total hardware cost: $22 with antenna.
- Three hours of YAML and on-site signal capture, working through the device list. Capture each remote's code, write the YAML, smoke-test, commit.
- Eleven outlets reconnected to monitoring as a side effect — current draw from a $4 clamp sensor on each major circuit, cross-referenced against which outlets are commanded on. This converts the previously dead X10 inventory into a useful current-monitoring fleet without replacing anything.
- One doorbell event routed to the operator dashboard, replacing the chime that nobody hears.
Total marginal cost: ~$25 in hardware, ~$300 in labor for a three-hour visit. Six previously-dead devices come back online; eleven get a monitoring use case they did not have before. The retrofit price list got a new line item: "Legacy RF inventory integration, $300 flat, one site visit."
What this is not
Three quick clarifications, because "native RF support" can be read too triumphantly.
Rolling-code devices still cannot be cloned. Modern garage door remotes (post-2010 from the major brands) use rolling codes that change every press. The CC1101 cannot replay those — replay would defeat the security model. What you can do is read the door position over the same RF bus, monitor when it opens and closes, and tie that into the building dashboard. Replay still works for the older fixed-code devices, of which there are a lot, but plan for the modern ones to be read-only.
Sub-GHz spectrum is shared. If your site is in a dense neighborhood with a hundred 433 MHz garage door openers and weather stations, expect occasional false reads and missed transmissions. The CC1101 supports a few mitigations (carrier sense, FEC), but the spectrum is what it is. Plan for the alert layer to tolerate jitter.
This does not replace Zigbee or Z-Wave. Mesh-network sensor fleets still belong on Zigbee or Z-Wave because the protocols handle routing, encryption, and battery management in ways the CC1101 does not. The 2026.5 RF platform is for the long tail of one-off remote-controlled devices that were never going to get a Zigbee replacement.
The pattern, three releases in a row
The 2026.x release train has been quietly removing every excuse not to use the local stack for small commercial buildings.
| Release | What it shipped | What it unlocked for buildings |
|---|---|---|
| ESPHome 2026.4 | Main-loop and watchdog rework; sensor refresh rates faster on commodity ESP32s | Tighter sample windows on vibration and current sensors at the same hardware cost |
| Home Assistant 2026.5 (serial proxy) | A $5 ESP32 replaces a $400 serial-to-Ethernet converter for Modbus and P1 meters | Industrial-protocol retrofit at consumer hardware prices |
| Home Assistant 2026.5 (native RF) | $10 CC1101 + ESP32 native bridge for the entire 300-928 MHz device universe | The stranded legacy RF inventory finally has a $10 on-ramp |
Three releases in three months. Each one closed a different retrofit gap. The cumulative effect is that the local-first stack now has a credible on-ramp for every category of legacy device a small commercial building actually contains: serial-protocol industrial meters, sub-GHz RF remotes, $4 ESPHome sensors. The only category left without a sub-$50 bridge is proprietary BACnet, and the community is two-thirds of the way there on that one as well.
One bridge per site. Every legacy RF device, online in the local stack.
$10 in hardware, one site visit, $300 flat for the legacy RF integration. Connected into the same Home Assistant + ESPHome stack as the sump pump and the boiler vibration sensors. No cloud round-trip.
See What We BuildRelated reading: The smart home bubble popped, the sump pump kept running | Home Assistant 2026.5 plugged ESPHome into every serial port | The agentic sump pump | ESPHome 2026.4 made the sensor layer faster