Blog

Entity Names Kept in Flash on ESP8266

Nov 18, 2026

Entity names are now stored in flash on ESP8266 instead of RAM. EntityBase::get_name() is deprecated on all platforms and replaced by get_name_to() for a copy of the name and get_log_name() for logging. It keeps working everywhere with a deprecation warning until it is removed in 2027.5.0. On ESP8266 the first call for an entity makes a RAM copy of its name and keeps it, so callers pay back the RAM this change saves for that entity.

This is a developer breaking change for external components in ESPHome 2026.11.0 and later.

http_request: Requests That Do Not Block the Loop

Oct 23, 2026

Clyde Stubbs

ESPHome Maintainer

ESPHome 2026.11.0 adds a way to run an HTTP request from a component without stopping the main loop while it waits for the server. HttpRequestComponent::begin() starts the request, HttpContainer::poll() moves it forward from loop(), and HttpContainer::read_available() reads the body without waiting for data that has not arrived. The http_request.get, post and send actions now use it.

This is a new developer-facing feature in ESPHome 2026.11.0 and later. Existing code does not need to change: start(), get() and post() still block until the response headers arrive, as before.

Display Pixel Blocks Drop the Color Order and Get a Driver Hook

Oct 16, 2026

Clyde Stubbs

ESPHome Maintainer

ESPHome 2026.11.0 removes the ColorOrder argument from Display::draw_pixels_at() and from the ColorUtil color conversions. Pixel blocks and packed colors are always RGB. draw_pixels_at() is no longer virtual: a display driver that copies blocks itself now overrides the protected draw_pixels_internal(). The forms that take a ColorOrder still work, with a deprecation warning, until 2027.5.0.

This is a developer breaking change for external display components in ESPHome 2026.11.0 and later, with a deprecation period until 2027.5.0.

remote_base Protocol Methods Are No Longer Virtual and Receiver Lists Are Sized From Codegen

Oct 14, 2026

J. Nick Koston

ESPHome Maintainer

RemoteProtocol<T> no longer declares encode(), decode() and dump() as virtual, the receiver’s listener and dumper lists are fixed size StaticVectors sized during code generation, and a protocol’s source file is only compiled when the configuration uses it. External components that derive from RemoteProtocol, that register listeners or dumpers from C++, or that use a protocol class from their own C++ need small changes.

This is a developer breaking change for external components in ESPHome 2026.10.0 and later.

InternalGPIOPin Is the Platform Pin Class Instead of a Virtual Base

Oct 9, 2026

J. Nick Koston

ESPHome Maintainer

InternalGPIOPin is no longer an abstract class. It is now a type alias for the one pin class each platform provides (esp32::ESP32InternalGPIOPin, esp8266::ESP8266GPIOPin, rp2::RP2GPIOPin, libretiny::ArduinoInternalGPIOPin, zephyr::ZephyrGPIOPin or host::HostGPIOPin), so every call through an InternalGPIOPin * is a direct call. GPIOPin keeps its virtual interface.

This is a developer breaking change for external components in ESPHome 2026.11.0 and later.