ESPHome 2026.10.0: Native ESP8266 builds and compressed updates - ESPHome - Smart Home Made Simple

Every month ESPHome ships a release like this one, so you can learn about new features, fixes, and other changes worth knowing about before you update.
Here’s the plain-language rundown for anyone short on time or newer to ESPHome; the full technical post continues below for anyone who wants it.
Action needed if you use any of these:
New features: Updates install about a third smaller and proportionally faster on every platform ESPHome supports, and ESP8266 builds are considerably quicker end-to-end, including on recent Apple Silicon Macs that no longer need Rosetta.
Also in this release: 20 new components (including Wi-Fi motion sensing, a persistent counter, a new CO2 sensor, USB-UART bridging and TCP-UART), broader Zigbee cluster coverage, live light transition reporting, CSS color names in light actions, and a long list of smaller fixes and improvements.
If you’re running a typical config, there’s nothing else you need to look at before updating - aside from the items above, your setup should carry over cleanly.
If you’re running custom lambdas, external components, or a non-standard config, or you just want the full technical detail, keep reading below for the full release overview and feature writeups.
The ESPHome Starter Kit is the easiest way to start building your own smart home devices – no soldering, breadboarding, or coding required.
ESPHome 2026.10.0 lands two platform-wide defaults that touch most of the fleet: the native ESP8266 Arduino toolchain is now the default build path, retiring Rosetta on Apple Silicon and cutting cold compile time nearly in half, and OTA uploads are compressed on ESP32, RP2040, LibreTiny and host through a new deflate decoder, so updates ship about a third fewer bytes and finish proportionally faster on slow or lossy links. The native API’s protobuf and controller-dispatch hot paths got another round of per-byte and per-instruction optimizations, 20+ field-packing PRs and a sweep moving codegen data from heap and RAM into flash tables trim RAM across every build, and the register_apply_action and sub_* codegen helpers remove hundreds of boilerplate C++ classes and Python lines across more than 150 components with no YAML changes. ESP-IDF builds now run cmake and ninja directly instead of through idf.py, and a --skip-bootloader flag plus mbedTLS and tool-startup trims save several more seconds per compile on Home Assistant Green class hardware. On top of that, 20 new components land, including Wi-Fi CSI motion sensing, USB-UART bridges with mux and tap seams, TCP-UART and UART-TCP, SPI Ethernet on KSZ8851SNL, a persistent counter sensor and a Sensirion STCC4 CO2 sensor, alongside a device-side Home Assistant onboarding wizard, outgoing API connections for NAT-ed devices, broader Zigbee cluster coverage and new light transition, color, resume-effect and e-paper features. The bundled Device Builder can now flash every supported chip family from the browser.
The native Arduino toolchain foundation that landed dormant in 2026.9.0 is now the default for every ESP8266 build. @bdraco finished the stack with the compile driver and dispatch layer (#18539), ESPHome-built xtensa gcc 10.3 archives for Linux x86_64/arm64, macOS x86_64/arm64 and Windows x86_64 served from esphome-libs/xtensa-lx106-elf-toolchain instead of the registry package (#19849), and flipped the default to toolchain: arduino in #19886. The CI matrix now compiles every ESP8266 component test the same way (#19714, #19740).
Roughly 40% of ESPHome devices run on ESP8266, so the change touches a large slice of the fleet; the first build after upgrading is a clean build because the build directory’s toolchain changed.
@bdraco extended compressed OTA, which the ESP8266 already had via its gzip-aware bootloader, to every other platform ESPHome supports (#19037). RP2040 takes the same gzip path through the Arduino Pico stub. ESP32, LibreTiny and host inflate a raw deflate stream through a 4 KB window as it arrives, so an image goes over the network about one third smaller than before.
The flash cost is about 2 KB on ESP32 and under 100 bytes on ESP8266 and RP2040 for the negotiation glue.
A sustained push on the native API’s hot paths continued through this release. @bdraco collapsed the three protobuf decode virtuals into one and removed the vtable from decode (#19016, #19029), made generated encode and size entry points type-erased (#19015), passed the encode cursor by value through the protobuf helpers so it stays in a register (#19014), counted packed varints a machine word at a time (#20122), decoded base64 in a single pass (#20123), and kept the write cursor in a register while emitting sub-message tags inline (#20124).
A separate change dispatches controller updates through generated direct calls instead of a runtime registry: APIServer and WebServer drop the Controller base class and the state-publish path goes from 25 instructions with 8 loads and 2 indirect calls to 10 instructions with 2 loads and direct calls only, costing 256 B less flash and 24 B less RAM on a typical ESP32 build (#19588). The web server also builds state documents in a stack arena and sends events straight from the caller’s buffers so a state event does no heap allocation at all (#19376, #19383).
External components that subclass Controller or hand-write a non-const AudioFile * need small updates; the migration notes are in each PR.
@bdraco led a tree-wide sweep to shrink per-instance structures and move constant codegen data out of RAM.
@bdraco finished one of the largest coordinated refactors in recent memory. register_apply_action and register_apply_condition turn an action or condition that only forwards config values to its parent into a field table with no C++ class and no builder, with constants and inline lambdas baked into one stateless function (#19469, #19655).
Over 80 components moved onto it in this release, covering actions and conditions on cover, fan, climate, light, switch, valve, lock, number, text,