ESPHome 2026.10: Faster ESP8266 Builds, Compressed OTA

ESPHome has shipped its October 2026 release, and this one touches nearly every device in a typical DIY smart home. Version 2026.10.0, released October 21, makes the native ESP8266 toolchain the default build path, compresses over-the-air updates on every remaining platform, and adds 20 new components alongside a long list of smaller fixes and improvements. If you maintain ESPHome devices alongside Home Assistant, this is a release worth reading about before you hit update.

Native ESP8266 builds are now the default

The headline change is the one most of the fleet will feel. The native Arduino toolchain foundation for ESP8266, which landed in a dormant state with the 2026.9.0 release, is now the default for every ESP8266 build. Instead of compiling through PlatformIO, ESPHome now uses its own ESPHome-built xtensa gcc 10.3 toolchain archives, distributed for Linux x86_64 and arm64, macOS x86_64 and arm64, and Windows x86_64.

The performance difference is substantial. ESPHome’s own timings on an M5 Max show a cold compile of the same configuration dropping from 17.8 seconds to 9.2 seconds, a warm ccache rebuild from 7.6 to 2.8 seconds, a no-op rebuild from 2.2 to 0.4 seconds, and a one-line edit from 20.7 to 9.6 seconds. In practice, that means iterating on a sensor config no longer means staring at a progress bar nearly as long.

There is also a forward-compatibility story here. The old registry toolchain package had no arm64 macOS build, so compiling for ESP8266 on recent Macs required Rosetta 2, which Apple plans to end with macOS 28. The ESPHome-built archives are native on every supported host, so Apple Silicon users can drop the translation layer entirely.

Because this changes the toolchain underneath existing builds, the first compile after upgrading will be a full clean build on ESP8266 devices, so expect it to take a little longer than usual. ESPHome estimates that roughly 40% of all ESPHome devices run on ESP8266, which gives a sense of how broad this change is. If you need to stay on the old path for now, you can set toolchain: platformio under the esp8266: section of your config, but that path warns at validation and goes away in 2027.4.0, so the migration clock is running.

Compressed OTA uploads on ESP32, RP2040, LibreTiny and host

The second platform-wide default extends compressed over-the-air updates, which the ESP8266 already enjoyed through its gzip-aware bootloader, to every other platform ESPHome supports. A new deflate decoder means updates on ESP32, RP2040, LibreTiny and host builds now ship about a third fewer bytes and finish proportionally faster on slow or lossy links.

The mechanism is designed to be invisible. A client bit and a server bit negotiate compression automatically, and old clients or old firmware never see it, so devices still running pre-2026.10.0 firmware update exactly as before. Compression only kicks in when both the device firmware and the esphome command line are on 2026.10.0 or newer; anything older simply falls back to an uncompressed upload. The integrity check covers the decoder itself: the client sends the MD5 of the inflated image, so a corrupted decode cannot slip through.

The payoff is biggest where networks are worst. Measured on an ESP32 with 15% simulated packet loss, upload time dropped from 317/113 seconds to 74/67 seconds, which matters for mesh-hop updates, VPN uploads, or devices hanging off a weak garage signal. The decoder session itself is allocation-safe: it is built through ESPHome’s RAM allocator so that a heap-exhausted device falls back to an uncompressed upload instead of rebooting mid-update.

Connections that reach Home Assistant on their own

On the networking side, a new outgoing_connection option under the api: section flips the usual direction of the native API. Instead of Home Assistant reaching out to the device, the device dials Home Assistant itself. That helps devices that sit on a VLAN or behind NAT that Home Assistant cannot reach inbound, since no inbound firewall rules need to be opened. It only works with API encryption enabled.

The release also includes a device-side Home Assistant onboarding wizard, and the bundled Device Builder can now flash every supported chip family from the browser, continuing ESPHome’s push to make getting devices onto the network as painless as maintaining them afterward.

20 new components and broader Zigbee coverage

As with most monthly ESPHome releases, the feature list keeps going. This cycle adds 20 new components, including Wi-Fi CSI motion sensing for ESP32 boards, USB-UART bridges with mux and tap seams, TCP-UART and UART-TCP bridges, SPI Ethernet on the KSZ8851SNL chip, a persistent counter sensor, and a Sensirion STCC4 CO2 sensor. Zigbee gets broader cluster coverage, and lights gain live transition reporting, CSS color names in light actions, resume-effect support, and e-paper display improvements.

Under the hood, a tree-wide memory sweep trims RAM across every build: roughly twenty field-packing changes reclaim padding bytes across speaker, voice assistant, Wi-Fi and other components, constant codegen data moves from RAM into flash tables, and LightState shrinks from 180 to 168 bytes. None of this requires YAML changes, but it all adds up on memory-constrained chips.

Before you update: the checklist

ESPHome says a typical config should carry over cleanly, but a handful of breaking-adjacent changes deserve a look before you update:

• Lights with initial_state: now actually respect it at boot. If a light was configured to come up on but was quietly staying off, double-check the boot behavior is what you want after updating.
• The codec_support_enabled option on speaker media players is gone. Remove it from your config and set the pipeline format: to NONE to keep the old behavior; configs that still carry the key now fail validation.
• IR climate devices with supports_heat: false or supports_cool: false no longer offer the combined heat/cool auto mode by default. Add supports_heat_cool: true to bring it back if you relied on it.
• remote_receiver buffer sizes: if you set buffer_size: on ESP8266, RP2040, LibreTiny, ESP32-C2 or ESP32-C61, multiply the value by 4 to keep the same number of buffered pulses.
• Sendspin speakers now encrypt every connection and need Music Assistant 2.10.7 or 2.11.0b4 or newer. Update Music Assistant first, or the device will not connect. Sendspin switches also need type: enabled added to each entry.
• Host platform builds: Windows host builds are no longer supported, and unsupported platformio_options keys must be removed.

The full upgrade checklist in the official release notes covers a few more edge cases, including e-paper luminance conversion, overlapping usb_uart entries, and lambda tag references, so it is worth a skim if you run custom lambdas or external components.

Why it matters

Taken together, 2026.10.0 continues a clear trajectory. Last month’s 2026.9.0 release brought encrypted OTA updates and laid the groundwork for the native ESP8266 toolchain; this month makes the toolchain default and shrinks every update by a third. The updates reaching your devices are getting smaller and more secure at the same time, which is exactly what you want when your fleet lives on garden soil sensors and attic repeaters.

The direction of travel is also spelled out: the PlatformIO path for ESP8266 is deprecated and disappears in 2027.4.0, and the ESP8266 bootloader’s compression model is now the template for every platform. For the large share of the DIY community still running ESP8266 hardware, this release is less a feature drop and more a maintenance milestone, one that makes the whole toolchain faster, leaner, and ready for a post-Rosetta world. Monthly ESPHome releases have become a reliable rhythm for Home Assistant tinkerers, and October’s is one of the more consequential of the year.