ESPHome 2026.10.0 was published on 21 October 2026. It makes two changes that touch most of the fleet. ESP8266 projects now build with a native Arduino toolchain by default, and firmware sent over the air is now compressed on ESP32, RP2040, LibreTiny and host targets. The official release blog calls it "Native ESP8266 builds and compressed updates." The release also adds 20 new components and includes several breaking changes. Anyone running a fleet of devices should read those before clicking update.

The GitHub release for tag 2026.10.0 was published by jesserockz at 11:42 on 21 October. It is marked Latest and immutable.

Native ESP8266 builds become the default

The biggest change for owners of older boards is the build path. In 2026.10.0 the ESP8266 platform uses a native ESP8266 Arduino toolchain by default. The release blog lists two practical results. Apple Silicon Macs no longer need Rosetta to build ESP8266 firmware, and cold compile time is cut "nearly in half."

The blog gives benchmark figures measured on an M5 Max machine. In each pair below, the first number is the new default path and the second is the old path:

  • Cold compile: 9.2 s vs 17.8 s
  • Warm rebuild with ccache: 2.8 s vs 7.6 s
  • No-op rebuild: 0.4 s vs 2.2 s
  • One-line edit: 9.6 s vs 20.7 s

These are the project's own numbers from one Apple Silicon machine. Results on a Linux server, a Raspberry Pi running the Home Assistant add-on, or a Windows desktop will be different. Still, a one-line edit dropping from over 20 seconds to under 10 makes a real difference when you iterate on a sensor config. The blog also says the first compile after upgrading is a clean build, because the build directory's toolchain changed.

The old build path is still available. Setting toolchain: platformio under the esp8266: block keeps the previous behaviour. The release blog tells users to plan to migrate before ESPHome 2027.4.0, when the PlatformIO path goes away. Treat the PlatformIO option as a temporary fallback, not a permanent setting.

Compressed OTA, negotiated per device

The second headline change is about over-the-air updates. On ESP32, RP2040, LibreTiny and host targets, OTA uploads are now compressed. According to the blog, ESP32, LibreTiny and host inflate a raw deflate stream on the device as it arrives, while RP2040 takes the gzip path through the Arduino Pico stub. The blog says an image goes over the network about one third smaller than before. The blog says this is a big win on slow or lossy links, and it cites a measurement on an ESP32 at 15% simulated packet loss.

Compression is negotiated between the uploader and the device. The blog says old clients and old firmware never see it, so devices on firmware older than 2026.10.0 update exactly as before. For integrity, the client sends the MD5 of the inflated image, so the check covers the decoder. The blog also notes that ESP8266 already had compressed OTA through its gzip-aware bootloader.

The full 2026.10.0 changelog lists the compression change as "Compress OTA uploads on ESP32, RP2040, LibreTiny and host." It also lists a related OTA change: a new allow_plaintext_upload option under ota:, which the blog says lets one migration install land on devices that never migrated to encrypted OTA, after the plaintext fallback is removed in 2027.3.0.

Twenty new components

The release blog counts 20 new components. These are among those it names:

  • ESPectre: Wi-Fi-based motion detection
  • Counter
  • STCC4: CO2 sensor
  • TF-Luna
  • PZEM-6L24
  • TAS2780 and TAS5805M
  • RX8025T
  • ICNT86
  • CDC-ACM UART bridge
  • UART mux
  • TCP UART

The changelog adds detail on the serial-plumbing additions. There is a new [bridge] component with a cdc_acm_uart platform, and a new [uart_mux] component to share a UART between a CDC-ACM bridge and local consumers. The [serial_proxy] component gains a tap interface and a port mode, and the changelog marks that change as breaking. Together with TCP UART, these additions suggest ESPHome nodes can serve as serial gateways, not only as sensor endpoints. That reading is ours, not the project's.

The changelog also lists several platform changes:

  • A forced roam check in [wifi].
  • A new [esp32] flash chip option that drops the unused flash vendor drivers.
  • On ESP32, the NVS cache is kept in PSRAM when PSRAM is guaranteed.

Breaking changes to check before updating

The release blog's upgrade checklist and breaking-change notes include these items:

  • Lights: a light with an initial_state now follows it at boot. If a config relies on the old boot behaviour, a light may come up differently after the update.
  • codec_support_enabled on speaker media players has been removed. Configs that still carry the key 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.
  • Sendspin: requires Music Assistant 2.10.7, or 2.11.0b4 or newer.
  • remote_receiver: on ESP8266, RP2040, LibreTiny, ESP32-C2 and ESP32-C61, buffer_size is now interpreted as bytes, so an explicit value must be multiplied by four to keep the same number of buffered pulses.
  • Host builds on Windows are no longer supported.

The changelog also flags the [serial_proxy] tap interface and port mode change as breaking. Anyone using serial_proxy in production should check that entry before updating.

What It Means for Makers

Who it's for: anyone who builds ESPHome firmware on a Mac, or who still runs ESP8266 boards. The native toolchain removes the Rosetta dependency on Apple Silicon. In the project's M5 Max figures, a cold build drops from 17.8 s to 9.2 s and a one-line edit from 20.7 s to 9.6 s. People who flash many ESP32, RP2040 or LibreTiny nodes over Wi-Fi get the compressed OTA path, which the project says sends about a third fewer bytes.

What it replaces or enables: for ESP8266, the native Arduino toolchain replaces the PlatformIO path as the default. You can still opt into PlatformIO with toolchain: platformio, but the project tells users to plan to migrate before 2027.4.0. Compressed OTA is negotiated, so older devices keep updating as before. The new bridge, UART mux and TCP UART components make it possible to use an ESPHome node as a serial gateway. ESPectre adds Wi-Fi-based motion sensing to the component list.

Price and availability: the sources do not mention a price. ESPHome 2026.10.0 has been available since 21 October 2026 as GitHub tag 2026.10.0, marked Latest. It is a shipping release, not a beta. The Home Assistant Community announcement thread repeats the official blog text, including the benchmark figures and the MD5 integrity note.

Before updating, check your configs for lights that depend on boot-time behaviour, speaker media players using codec_support_enabled, IR climate entities that rely on heat/cool auto mode, Sendspin setups, remote_receiver buffer sizes, serial_proxy users, and Windows host builds. These are the areas where 2026.10.0 changes behaviour rather than just adding features.

Sources