ESPHome 2026.10 and your Vome home

Plain-text firmware updates now have an end date, devices can call Home Assistant instead of waiting to be called, and a few configs need a one-line edit. What it means for a home we run, and what to do before March.

Posted 22 October 2026 esphomereleasessecurity

ESPHome 2026.10 came out on 21 October. Most of it is faster builds and smaller updates, which ask nothing of you. We read it for the parts that touch homes we run. One of them has a deadline.

Plain-text firmware updates stop in 2027.3

ESPHome 2026.9 added encrypted firmware updates. Until now, a device that never switched them on carried on updating in plain text, so anyone on the same Wi-Fi could in principle read its Wi-Fi password and API key as the update went past. From ESPHome 2027.3.0, the plain-text fallback is removed. A device whose config has no OTA encryption: will stop taking updates over the network at all.

The fix is two lines, on any device that already has an API encryption key:

ota:
  - platform: esphome
    encryption:

Do it while you are on 2026.10. After 2027.3, switching it on needs a one-off helper for the last plain-text install, which is more fiddly than it needs to be. Our knowledge base has the whole change, and the helper.

If Claude is connected to your home through Vome, you can ask it which of your devices still update in plain text. It reads each device's config and can add the two lines for you.

Devices can call Home Assistant now

The outgoing_connection option we wrote about in our Home Assistant 2026.10 post is final. The device dials Home Assistant on TCP 6054 instead of waiting to be reached. Nothing changed from the beta that matters here:

• encryption is still required, and the key is still the only proof of who is on either end;
• the device still opens with a short plain hello naming itself, and everything after it is encrypted;
• the address it dials is still an IP, fixed in its firmware.

For a home we host, this is what would let a sensor in the house reach Home Assistant with no box and no tunnel in between. We are working on taking those calls, and the part we are being careful about is the address: it goes into each device's firmware, so it has to be one we can keep for good.

Before you update a device

The first two change behaviour without an error; the third fails validation, so you see it before anything is flashed.

• A light that now really boots on. A light with initial_state: on and no restore_mode: used to start off anyway. Now it starts on. If you were relying on it starting dark, say so explicitly.
• ESP8266: the first build is slow once. These boards now build with ESPHome's own toolchain instead of PlatformIO, so the first build after updating downloads it and starts from scratch. Builds after that are quick again.
• A few component types need an edit. IR and RF receivers on ESP8266 and some other chips (buffer_size: now counts bytes, so multiply it by 4), the speaker media player, and Sendspin. The knowledge base article has each fix.

Smaller things

• Updates are about a third smaller on ESP32, RP2040 and LibreTiny once a device is running 2026.10. Nothing to configure.
• Device Builder has its own optional MCP endpoint, so an AI app that can reach your Device Builder can edit, validate and build configs. Vome's ESPHome tools reach Device Builder through your home's Vome link instead, with each home's permissions and an audit log applied, so they also work when you are not at home.