ESPHome published a migration notice on 14 October 2026 for custom infrared and RF components targeting ESPHome 2026.10. The important distinction: ordinary YAML configurations are largely unaffected, but external components using the remote-control internals may need code changes. A successful build on an older version is not proof that the same extension will compile after upgrading.
This is a new explanation of a development change, not a stable-release announcement. The underlying pull request was merged on 11 September. As checked on 16 October, GitHub still marks 2026.10.0b4 as a prerelease; our earlier beta coverage concerns separate BLE and ESP8266AliExpress price fixes.
Quick summary
| Your setup | What to check |
|---|---|
| Built-in components configured through YAML | Usually no migration; check any embedded C++ lambdas. |
| A custom remote protocol or receiver extension | Check its compatibility with ESPHome 2026.10 before rebuilding. |
| A working household controller | Test the update on a spare node before replacing known-working firmware. |
Why change the remote-control internals?
The merged change reduces the amount of remote-protocol code retained in a firmware image. It replaces virtual protocol methods with direct methods, sizes receiver registration lists during code generation and builds bundled protocol sources only when requested. Selecting every decoder with dump: all still keeps all of those protocols.
The project reports flash reductions of 14.6 KB for one ESP8266AliExpress price test configuration and 11.9 KB for an ESP32AliExpress price ESP-IDF configuration. Those are upstream build measurements, not our benchmarks or a guaranteed saving for every node. Smaller firmware also does not establish longer infrared range or better appliance compatibility.
Which custom code needs attention?
The migration guide identifies extensions that inherit from RemoteProtocol<T>, register receiver listeners from C++, or call a bundled protocol directly. Its warning concerns a software interface, not an ESP32AliExpress price chip or development-board revision.
| Custom-code pattern | Migration direction |
|---|---|
| Protocol methods marked override | Remove that specifier from encode, decode and dump. |
| Receiver registration inside C++ setup() | Move registration into Python code generation so capacity is counted. |
| A bundled protocol used only from C++ or a lambda | Request its source explicitly, or reference it elsewhere in the configuration. |
| Separate listener and dumper dispatch calls | Use the combined receiver dispatch helper. |
There is an important YAML exception: a lambda that directly invokes a protocol can need an explicit protocol reference. Conversely, having remote_receiver: in a normal configuration does not by itself mean a rewrite is required.
A practical update plan for existing projects
First inspect external_components:. ESPHome can load extensions from Git repositories or local folders, and those extensions can replace bundled components. Check the selected branch or tag and the maintainer’s compatibility notes. The external-component documentation also describes repository caching: editing upstream code does not mean a cached checkout has refreshed immediately.
Our recommendation is to preserve the YAML, extension revision, builder version and known-working firmware together. Compile a representative test configuration before scheduling an over-the-air update. If compilation fails, inspect the first error and the affected extension rather than changing appliance timings at random.
Keep software migration separate from physical troubleshooting. The remote transmitter component generates control signals through configured hardware; a bare development board is not an infrared emitter or a 433 MHz transmitter. Our IR receiver guide covers capture setup, while the IR blaster troubleshooting guide covers range and appliance-command problems.
For a reliable controller with no urgent need for beta features, there is no requirement to install a prerelease simply because this notice exists. For extension maintainers, however, it is a useful prompt to test compatibility now and publish the supported version range.
Sources
ESPHome developer migration notice — 14 October 2026.
Pull request #19084: implementation, migration details and build measurements.
Official ESPHome releases and prerelease status — checked 16 October 2026.
External components: sources, revisions and refresh behaviour.
.jpg){kind=link}