What is new in ESPHome 2026.10?
The ESPHome team announced the release on its blog on 21 October 2026. The headline changes are about build speed, upload size and connectivity rather than new device types:
| Change | What it does | Who benefits |
|---|---|---|
| Native ESP8266 toolchain | Now the default; a cold compile fell from 17.8 s to 9.2 s on the team's test machine | Anyone still running ESP8266 devices |
| Compressed OTA | Images are about one third smaller on ESP32, RP2040, LibreTiny and host builds | Devices on weak Wi-Fi |
outgoing_connection | The device opens the API connection to Home Assistant itself | VLAN, NAT and routed set-ups |
| Browser flashing | Device Builder adds nRF52, Raspberry Pi Pico and LibreTiny chips | Non-ESP32 projects |
| 20 new components | Includes Improv over BLE, UART bridging, a CO2 sensor (STCC4) and Xiaomi body scale support | Sensor and bridge builders |
On ESP8266, builds now use an ESPHome-built xtensa toolchain instead of the PlatformIO package, and the first build after upgrading is a clean build. You can keep the old path with toolchain: platformio under esp8266:, but ESPHome marks it deprecated and plans to remove it in 2027.4.0.
Compressed uploads are negotiated between client and device, so older firmware and clients keep working. If a device lacks the memory to decompress, it falls back to an uncompressed upload. In the team's test with 15% simulated packet loss on an ESP32, upload times dropped from 317 s and 113 s to 74 s and 67 s.
Can ESPHome devices now connect out to Home Assistant?
Yes. A new outgoing_connection option under api: makes the device initiate the native API connection itself, which helps when Home Assistant cannot reach the device inbound, for example across VLANs or behind NAT. Without a host: setting the device reconnects to the last client that dialled in; with one, it always dials out.
It requires API encryption, because the connection can leave your local network and the Noise key is the only reliable way to verify the other end. ESPHome says the matching aioesphomeapi library and Home Assistant core already support it, and a setup wizard block that needs Home Assistant 2026.11 or newer to display is also included. Older versions simply ignore it.
What could break when you upgrade?
A few changes can alter behaviour on devices that are already working, so test on one device before updating a whole fleet. The ones most likely to catch Home Assistant users out:
- Lights with
initial_state:now honour it at boot, so a light that used to stay off after a power cut may switch on. - Speakers:
codec_support_enabledwas removed, and volume and mute are now independent. - Climate IR:
heat_coolis no longer offered unless you addsupports_heat_cool: true. - Remote receiver:
buffer_sizeis now in bytes on several chips, so multiply existing values by 4. - Sendspin: every connection is now encrypted and Music Assistant 2.10.7 or newer is required.
The light change is the one worth checking first, because an unexpected switch-on after a power cut is easy to miss until it happens at 3am. ESPHome also deprecates restore_mode: in favour of a new restore_state: key; the old one still works for now.
Why does this matter for Home Assistant users?
If you only use ESPHome through ready-made devices, very little changes day to day. If you build your own, the practical wins are faster compile times on ESP8266 boards and quicker updates on weak Wi-Fi, both of which show up in the ESPHome Device Builder dashboard. The outgoing connection option removes a common reason people give up on putting IoT devices on a separate VLAN.
New to the platform? Our ESPHome beginner's guide covers the basics, and the ESPHome Starter Kit write-up shows the official no-solder route. For the main platform release from earlier this month, see what changed in Home Assistant 2026.10.
Should you upgrade now or wait?
Upgrade one non-critical device first, then the rest. Compile a device that restores lights after power loss and confirm its boot state, check any speaker, climate IR or Sendspin configs against the list above, and expect the first ESP8266 build to take longer than usual because it is a clean build. If you rely on custom or external components, wait a few days: the release also contains developer-facing breaking changes that external code may need to catch up with.
