ESPHome 2026.1.0: Automatic WiFi roaming and ESP-IDF by default

Jan 21, 2026

Template Water Heater

Release Overview

ESPHome 2026.1.0 delivers one of the most requested features: automatic WiFi roaming. Devices now switch to better access points after connecting, solving the problem of devices getting stuck on distant APs after power outages or AP reboots.

The web server now uses entity names directly in URLs with collision-free encoding, fixing issues that plagued non-ASCII configurations.

This release completes major security transitions: API password authentication has been removed and API encryption is now required, while OTA updates require SHA256 authentication. ESP-IDF is now the default for ESP32, ESP32-C3, ESP32-S2, and ESP32-S3, delivering up to 40% smaller binaries and faster compile times.

Months of performance optimization work culminates here: heap churn reduction plus allocator work enabled moving heap functions from IRAM to flash (saving ~6KB of IRAM on ESP32), removing object_id storage from RAM saves hundreds to thousands of bytes, zero-copy API support delivers ~42% more entities per packet, and ESP32 camera streaming improves by ~10% with lower latency. These optimizations translate directly into headroom for existing devices and reliability for years to come.

LibreTiny platforms (BK72xx, RTL87xx, LN882x) receive thread-safe WiFi, atomics support, and deep sleep that bring them closer to first-class status. New hardware support includes the RD-03D mmWave radar and BTHome v2 parsing for Xiaomi sensors, while Zigbee on nRF52 expands with sensor, binary sensor, and switch support.

Upgrade Checklist

If you used api: password:, replace it with api: encryption: key:
If you rely on Arduino-only components, explicitly set ESP32 framework to type: arduino
If you used web server URLs directly, note the new name-based URLs and the / restriction in entity names
If you have lambdas using Fan, Select, Climate, Event, or Light state methods, check the Lambda API Changes below

Building forward without leaving users behind

At the end of 2024, ESPHome completed the transition from ESP-IDF 4.x to ESP-IDF 5.x for ESP32. By early 2025, as we began addressing the higher baseline memory costs on ESP32, something important became clear. Users were telling us that their devices were running out of RAM, firmware builds were failing because flash limits were exceeded, and devices that had worked reliably for years were suddenly unstable or impossible to update.

ESPHome had grown powerful. It had also grown heavy.

That growth did not happen overnight. Since 2019, the ESPHome codebase has steadily expanded. New components, new platforms, and new capabilities were added year after year. The project kept moving forward because it had to. User demand, new hardware, and ecosystem changes did not wait.

What we did not have for a long time was enough capacity to do more than one hard thing at once.

As we started reducing memory usage on ESP32 in early 2025, the work exposed a broader pattern. ESP8266 does not use ESP-IDF, but the ESP32 transition helped us see something we had missed. As development increasingly focused on ESP32, ESP8266 became less sustainable by default. Not because users needed ESP32 features, but because that was where optimization, testing, and attention naturally concentrated. When configurations became tight or devices unstable, the path of least resistance was often to move to ESP32.

Over time, that behavior became normalized.

The ESP-IDF upgrade forced us to step back and examine why so many users had already migrated. The answer was uncomfortable but clear. ESP8266 was not failing because it could not meet user needs. It was failing because we were no longer treating it as a first class platform. By the time runtime heap on ESP8266 routinely dropped below 10k, the outcome was predictable. Even modest real world configurations became fragile, and we eventually had to advise users not to use ESP8266 at all.

That realization marked a real inflection point.

Not because the ESP32 transition was wrong, but because it revealed a dependency we had allowed to form. Progress had quietly become tied to hardware replacement. People were being left behind, not by design, but by momentum. With millions of ESP8266 devices already deployed and likely to remain in homes for years, that was not an acceptable outcome.

What changed was not direction. What changed was scale.

Increased support for the Open Home Foundation changed the equation. With more Home Assistant users supporting the ecosystem through hardware purchases and Home Assistant Cloud subscriptions, ESPHome now has two full time developers and a broader base of part time contributors. That made it possible to keep moving forward while also tackling long standing performance, memory, and sustainability work.

In the middle of 2025, pressure increased again when ESPHome upgraded from Arduino 2 to Arduino 3 for ESP32. The new Arduino core brought important long term improvements, but it also increased baseline RAM and flash usage. On top of the ESP-IDF 5 transition, the impact compounded. Rather than accepting that cost, we made a structural change and moved Arduino to run as an ESP-IDF component.

This gave us tighter control over integration, build behavior, and memory ownership, and allowed us to systematically reduce the overhead introduced by the transition.

Over the following months, work continued in parallel. New components kept landing. New platforms were supported. At the same time, we removed duplication between layers, tightened boundaries, and eliminated unused paths that had quietly accumulated over time. The goal was not just compatibility, but sustainability.

This work was guided by the principles of the Open Home Foundation. Privacy, choice, and sustainability are not abstract ideals. They show up in practical ways, in how long devices remain usable, how often hardware needs to be replaced, and whether users are forced to discard perfectly good devices just to keep their software up to date. We chose sustainability through efficiency.

By the start of 2026, these efforts converged. The ESP-IDF 5 transition, the Arduino 3 integration, and the memory reduction work across ESPHome all fell into place, producing a step change in performance, RAM availability, and flash usage across supported platforms.

The results were tangible.

On ESP8266, available heap increased from under 10k to over 30k in realistic configurations. On a platform that often only has about 45k of heap available when nearly nothing is configured, that shift fundamentally changes what is possible. Devices that were unstable became reliable, and devices that could not be updated regained headroom.

In parallel, we addressed long standing performance and latency issues on ESP32-C3. Bluetooth proxies on this platform were unreliable and frustrating, but through scheduler tuning, memory optimizations, and transport improvements, they are now viable. ESP32-S3 remains the better choice for heavy Bluetooth workloads, but C3 is no longer a dead end.

ESP8266 is no longer a platform we warn users away from. It can continue serving existing deployments well into the future, even as new projects naturally gravitate toward ESP32.

What changed in 2026 is not just memory numbers or latency graphs.

What changed is intent.

ESPHome continues to move forward with new hardware support, new components, and new features, while treating sustainability as a first class requirement rather than an afterthought.

In 2026, ESPHome is faster, leaner, and more durable. It respects the hardware it runs on and the users who already invested in it.

We learned how to move forward without leaving users behind.

WiFi Roaming Support

One of the most requested features for years: ESPHome devices now automatically switch to better access points after connecting (esphome#12809).

This addresses three scenarios where devices get stuck on suboptimal APs:

AP reboot - Device connects to a distant AP while the nearby one restarts, never switches back
Power outage - Devices connect to whichever AP recovers first, often the worst option
Improv provisioning - Bluetooth or serial setup may pick a suboptimal AP

For Bluetooth proxies or Z-Wave adapters, a poor WiFi connection cascades into widespread failures. Until now, the only fix was manually restarting each device.

Post-connect roaming is designed for stationary devices and is intentionally conservative. If you already configured 802.11k or 802.11v roaming, post-connect roaming disables itself automatically. Devices scan up to 3 times after connecting (every 5 minutes), skip scanning when signal is already excellent, and only roam when finding a meaningfully better signal. Users shouldn’t need to understand RSSI thresholds to get reliable WiFi behavior.

# Enabled by default, but can be disabled:
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  post_connect_roaming: false  # To disable

Web Server Improvements

The web server now uses entity names directly in URLs instead of sanitized object_id values (esphome#12627), fixing long-standing issues with URL collisions. This change is part of the broader effort to eliminate object_id collisions with non-ASCII characters - a key step toward proper UTF-8 support so users can use non-ASCII entity names in Home Assistant without collisions.

Problems Solved:

UTF-8 name collisions - Different UTF-8 names like "温度传感器" (temperature) and "湿度传感器" (humidity) previously both became "___", making them indistinguishable
Sub-device collisions - Multiple devices with entities named “Temperature” now have unique URLs like /sensor/Garage/Temperature

New URL Format:

# Main device entity
/sensor/Temperature

# Sub-device entity
/sensor/Garage/Temperature

# UTF-8 names work correctly
/sensor/温度

Old URLs using object_id format (e.g., /sensor/temperature_sensor) continue to work during a deprecation period until 2026.7.0.

SSE Entity IDs: A deprecation path was added for SSE event entity IDs. The payload now includes a temporary name_id field (new format like sensor/Temperature) alongside id (legacy format like sensor-temperature). Timeline: In 2026.8.0, name_id will be removed and id will switch to the new format. Third-party integrations should prefer name_id now, falling back to id for compatibility with older firmware. Integrations requiring the legacy format after 2026.8.0 must implement their own conversion logic.

Important restrictions:

Names may not include / because it is reserved as a URL path separator
Names used in URLs are limited to 120 characters

Brotli Compression for Web Assets

Web server and captive portal assets now use Brotli compression by default, saving significant flash space (esphome#12959):

captive_portal: 348 bytes saved (24%)
web_server v2: 1,210 bytes saved (10%)
web_server v3: 9,420 bytes saved (12%)

Security Enhancements

This release includes significant security improvements that complete long-standing deprecations:

API Password Authentication Removed

Password authentication has been removed from the API component after being deprecated since May 2022 (esphome#12819). Password authentication only verified identity while all data was still transmitted in plaintext. Noise-based encryption provides both authentication and a fully encrypted data stream.

If your configuration still has password:, it will fail to compile. Users must migrate to encryption:

api:
  encryption:
    key: !secret api_encryption_key
# Generate a key with: openssl rand -base64 32

OTA Authentication Upgraded

MD5 authentication support has been removed from OTA updates (esphome#12707). SHA256 is now mandatory, preventing protocol downgrade attacks.

NOTE

ESPHome versions before 2025.10.0 that use password authentication cannot OTA to devices running 2026.1.0 or later.

If you use multiple systems to install and/or update your ESPHome devices, be sure they’re all up-to-date! If you need to downgrade to a version before 2025.10.0, downgrade to 2025.12.x first, then OTA to an earlier version.

HMAC-SHA256 Support

A new hmac_sha256 component provides HMAC support using the more secure SHA256 algorithm (esphome#12437).

ESP-IDF Default Framework

This release completes the transition announced in ESPHome 2025.8.0: ESP-IDF is now the default framework for ESP32, ESP32-C3, ESP32-S2, and ESP32-S3 (esphome#12746). Users have been warned about this change for months.

Benefits:

Up to 40% smaller firmware binaries - More room for features
Up to 2-3x faster compile times - Quicker development cycles
Better performance - Improved runtime characteristics
Access to newer features - Full ESP-IDF capabilities

This release also bumps to ESP-IDF 5.5.2 (esphome#12681).

To continue using Arduino for components that require it (such as heatpumpir or midea), explicitly set type: arduino in your configuration. See the Arduino to ESP-IDF Migration Guide for details.

esp32:
  board: esp32dev
  framework:
    type: arduino  # Explicitly use Arduino if needed

Performance & Memory Optimizations

This release represents the culmination of months of work to reduce heap churn and memory usage throughout ESPHome, resulting in significant improvements across all platforms.

Heap Churn Reduction

Systematic elimination of unnecessary dynamic allocations means heap functions (malloc, free, realloc) are now primarily called during setup, not during normal operation. This enabled moving heap functions from IRAM to flash on ESP32, saving ~6KB of IRAM (esphome#12862).

Key optimizations include:

StaticVector and FixedVector replacing std::vector where sizes are known
const char* for static strings instead of std::string
Pre-allocated buffers instead of dynamic allocation in hot paths
Stack allocation where possible
Audio/video components using pre-allocated ring buffers

Object ID RAM Removal

The object_id field is no longer stored in RAM, saving significant memory especially on ESP8266 (esphome#12631):

ESP8266 (37 entities): ~886 bytes saved (~24 bytes/entity)
ESP32 (102 entities): ~497 bytes saved (~5 bytes/entity)
Large setups (800 entities): ~3,600 bytes saved

ESP8266 Memory Optimizations

ESP8266 receives additional memory optimizations:

Unused waveform code excluded - Saves 596 bytes RAM when esp8266_pwm is not used (esphome#12690)
Unused Serial objects excluded - Saves 32-64 bytes RAM (esphome#12736)

ESP-IDF 5.5.2 Compiler Improvements

The bump to ESP-IDF 5.5.2 includes compiler improvements that reduce flash usage by ~35KB (~4%) on typical ESP32 configurations (esphome#12681). The libc component alone shrank by ~15KB.

Logging Optimizations

Over 100 components received logging optimizations that combine consecutive log statements into single calls (esphome#12838, esphome#12860, esphome#12856, and many more). Each ESP_LOG* call involves formatting, memory allocation, serial output, and network packet transmission. Combining them significantly reduces event loop blocking and the number of network packets sent to connected clients.

Additional logging improvements:

Thread-safe logging on host platform - Consistent behavior across platforms (esphome#13010)
RAII guards for recursion protection - Optimized hot path performance (esphome#13194)
StaticVector for log listeners - Compile-time sizing eliminates heap allocation (esphome#13196)

Zero-Copy API Protocol

Zero-copy message handling is now complete and enabled by default for all protobuf messages (esphome#12816), eliminating unnecessary memory copies during API communication. Combined with removing object_id from the wire protocol (esphome#12818) and 33% smaller batch items (esphome#13199), this provides:

~42% more entities per packet (24 → 34)
Faster Home Assistant reconnects - especially noticeable for large setups
Reduced protocol overhead - no longer sending the name twice
Lower CPU usage - zero-copy eliminates buffer allocations during message processing
33% less RAM per queued message - batch items reduced from 12 to 8 bytes

ESP32 Network Latency Reduction

Socket operations on ESP32 now call lwip_read() and lwip_write() directly instead of going through ESP-IDF’s VFS layer (esphome#13179). This reduces latency for API connections, async TCP, and voice assistant components by eliminating unnecessary function pointer dispatches.

PSRAM Workaround Optimization

ESP32 r3.0+ users with PSRAM can now save ~10KB of IRAM by setting minimum_chip_revision: "3.0" (esphome#13074). This disables workarounds for silicon bugs that were fixed in newer chip revisions.

LibreTiny Platform Improvements

LibreTiny platforms (BK72xx, RTL87xx, LN882x) receive significant improvements that bring them closer to first-class platform status:

Thread-safe logging - Prevents buffer corruption and connection failures when non-main tasks log messages (esphome#13062)
Cortex-M4 atomics support - Enables proper atomic operations on RTL87xx and LN882x platforms (esphome#13191)
Thread-safe WiFi - Improved WiFi reliability in multi-threaded scenarios (esphome#13191)
Board regeneration - Updated board definitions with consolidated platform code (esphome#13191)
Deep sleep support - BK7231n and BK7231t chips now support deep sleep with configurable timer and GPIO wake-up (esphome#12267)
BLE stack disabled on BK7231N - Saves ~21KB RAM and ~225KB flash since ESPHome has no BLE support on LibreTiny (esphome#13131)
LibreTiny 1.9.2 - Fixes GPIO interrupt issues on LN882H that caused HLW8012/BL0937 power sensors to report zero (esphome#13077)

New Hardware Support

RD-03D mmWave Radar

The rd03d component adds support for the Ai-Thinker RD-03D 24GHz millimeter-wave radar module with multi-target trajectory tracking (esphome#12764).

Features:

Multi-target tracking - Tracks up to 3 simultaneous targets
Rich sensor data - X, Y coordinates, speed, distance, and angle for each target

BTHome MiThermometer

The bthome_mithermometer platform enables receiving data from Xiaomi Mijia BLE sensors running PVVX firmware with BTHome v2 format (esphome#12635). Starting with PVVX firmware version 6, BTHome v2 is the only supported format.

Air Quality Index Sensor

A new standalone aqi sensor computes Air Quality Index from particulate matter readings (esphome#12203, esphome#12958). It supports both EPA AQI (US) and CAQI (European) calculation methods.

sensor:
  - platform: pmsx003
    pm_2_5:
      id: pm25
    pm_10_0:
      id: pm10

  - platform: aqi
    name: "Air Quality Index"
    pm_2_5: pm25
    pm_10_0: pm10
    calculation_type: AQI  # or CAQI for European standard

Zigbee Support for nRF52

ESPHome now supports Zigbee on nRF52 platforms, bringing a new connectivity option alongside WiFi, Bluetooth, and Thread:

Binary sensor support - Expose GPIO states via Zigbee (esphome#11535)
Sensor support - Expose ESPHome sensors via Zigbee’s Analog Input cluster with automatic unit mapping (esphome#12187)
Switch support - Control ESPHome switches via Zigbee as binary output (esphome#13083)
wipe_on_boot: once - Wipe network settings only on first boot, preserving connections after OTA updates
Framework version support - Configure nRF-SDK version with experimental support for SDK 2.9.2 and 3.2.0 (esphome#12489)

OTA Rollback Support

ESP32 devices using ESP-IDF now support automatic OTA rollback (esphome#12460). When enabled (the default), the bootloader automatically rolls back to the previous firmware if the device crashes or resets before the boot is marked as successful.

This feature works with the safe_mode component - after a successful boot (determined by the safe_mode boot timer), the firmware is marked as valid. If the device crashes before that point, it automatically rolls back.

Note: Your bootloader must be compiled with the appropriate sdkconfig. If upgrading from an older bootloader, a serial flash may be required.

Platform & Component Improvements

AC Dimmer ESP-IDF Support

The ac_dimmer component now supports ESP-IDF framework in addition to Arduino (esphome#7072).

DSMR ESP-IDF Support

The dsmr component now supports ESP-IDF framework and fixes multiple bugs with the DSMR parsing (esphome#11036).

ESP32 Camera Performance

The esp32_camera component received significant performance improvements (esphome#12601):

~10% more frames delivered during streaming (510-523 vs 467-474 per 60 seconds)
~50% reduction in idle CPU usage by skipping work when no frames are pending
Lower latency through burst frame delivery and immediate wake signals instead of polling

Water Heater Component

ESPHome now includes a dedicated water_heater entity type for controlling water heaters, boilers, and similar hot water appliances (esphome#12498, esphome#12516, esphome#12511).

Template platform - Full control via automations and lambdas
Multiple operating modes - Support for eco, gas, and custom modes
Web server support - Control and monitor via the built-in web interface

NOTE

Home Assistant integration for water heater entities is not yet available. See home-assistant/core#159201 for progress.

water_heater:
  - platform: template
    name: "Boiler"
    supported_modes:
      - eco
      - gas
    visual:
      min_temperature: 10.0
      max_temperature: 85.0

Experimental: IR/RF Proxy Component

WARNING

This component is experimental and the API is likely to change in future releases.

The new ir_rf_proxy component provides an API-accessible interface for transmitting and receiving infrared and RF signals, bridging Home Assistant with ESPHome’s existing remote_receiver and remote_transmitter components (esphome#12985).

Key Features:

Home Assistant integration - IR/RF transmission and reception exposed through the native API
Flexible hardware support - Works with both infrared and RF configurations
Raw timing arrays - Maximum flexibility with minimal on-device processing
Bidirectional operation - Define multiple proxy instances for transmit and receive

This component is part of a broader effort to make IR & RF easier to use from within Home Assistant. A new experimental infrared entity platform (esphome#13129) provides the underlying infrastructure.

infrared:
  - platform: ir_rf_proxy
    name: IR Proxy Transmitter
    remote_transmitter_id: ir_tx
  - platform: ir_rf_proxy
    name: IR Proxy Receiver
    remote_receiver_id: ir_rx

Additional Features

UART event component - Trigger ESPHome events when receiving specific UART sequences (esphome#11765)
Templatable MQTT topics - Dynamic state and command topics via lambdas (esphome#12441)
Update check action - Trigger HTTP-based update checks from automations (esphome#12415)
SPI flexible data rates - Any achievable data rate within 5% can now be specified (esphome#12753)
Hub75 improvements - Rotation support, expanded bit depths (4-12), and brightness action (esphome#12674, esphome#12521)
ESP32 CAN listen-only mode - Passive bus monitoring without sending ACK signals (esphome#13084)
MMC5603 temperature compensation - Eliminates thermal variation in magnetometer readings (esphome#12556)
MHZ19 configurable detection range - Set detection range at setup or dynamically via action (esphome#12677)
ESP32 RMT LED strip inverted logic - Support for simple transistor-based level shifters (esphome#12825)
ESP32 Hosted HTTP updates - Fetch coprocessor firmware from remote manifests (esphome#13090)
Thermostat boolean heat_cool_mode - Simplified configuration without requiring automations (esphome#13069)

Breaking Changes

Platform Changes

ESP32: ESP-IDF is now the default framework for ESP32, ESP32-C3, ESP32-S2, and ESP32-S3. Users who relied on the implicit Arduino default must now explicitly specify type: arduino if they need Arduino-specific features or have components that don’t yet support ESP-IDF (such as heatpumpir, midea, or light with wled effect). esphome#12746
ESP8266: Unused Arduino Serial objects are now excluded from builds. Users who directly use Serial or Serial1 in lambdas must now explicitly enable them with enable_serial: true or enable_serial1: true under the esp8266: configuration. Most users are unaffected as Serial usage typically goes through the uart component. esphome#12736
ESP8266: Unused waveform code is now excluded from builds when esp8266_pwm is not used, saving 596 bytes of RAM. Users who directly use Arduino waveform functions in lambdas must add an esp8266_pwm component to their configuration. esphome#12690

Security Changes

API: Password authentication has been removed after being deprecated since May 2022. Configurations with password: will fail to build. Users must migrate to encryption: with a key generated via openssl rand -base64 32. esphome#12819
```
api:
  encryption:
    key: !secret api_encryption_key
```
OTA: ESPHome versions before 2025.10.0 cannot perform OTA updates to devices running this version. MD5 authentication support has been removed; SHA256 is now mandatory. esphome#12707

Component Changes

Sprinkler: Internal latching valve support has been removed. The configuration variables pump_pulse_duration, pump_off_switch_id, pump_on_switch_id, valve_pulse_duration, valve_off_switch_id, and valve_on_switch_id are no longer available. Users with latching valves must now use an H-Bridge switch with the standard valve_switch_id and/or pump_switch_id configuration. esphome#12603
Web Server: URLs now use entity names instead of sanitized object_id values. Old URLs (e.g., /sensor/temperature_sensor) still work but are deprecated and will be removed in 2026.7.0. Additionally, the / character is no longer allowed in entity, device, or area names (reserved as URL path separator), and names are limited to 120 characters maximum. esphome#12627
ESP32 Hosted: The update configuration now requires an explicit type: field. Existing embedded mode configurations must add type: embedded. A new type: http mode allows fetching firmware from remote manifests. esphome#13090
HM3301: The AQI sensor configuration has been refactored into a shared aqi component. Existing aqi: configurations under hm3301 continue to work but the implementation is now shared with pmsx003. esphome#12203
MMC5603: The auto_set_reset option is now enabled by default to eliminate temperature-related drift. This reduces maximum read frequency from 150Hz to 75Hz. Users requiring high-frequency reads can set auto_set_reset: false. esphome#12556
Ultrasonic: The timeout option is deprecated and will be removed in 2026.8.0. A fixed 80ms measurement timeout is now used to fix reliability issues with some SR04 sensors that have a 12.3ms delay before sending pulses. esphome#12897

Behavior Changes

API: The on_client_disconnected trigger now fires after the client is removed from the connection list, so api.connected correctly reflects the true connection state. Users who added delay: 1ms workarounds can remove them. Users who relied on the disconnecting client still being counted may need to adjust their logic. esphome#13088
Display Drivers: Multiple display drivers now correctly honor clipping for fill() and clear() operations. Code that relied on the previous (incorrect) behavior where fills ignored clipping regions may produce different results. esphome#12808
Build Info: The compilation_time field in the native API now correctly updates on every compile (previously only updated when main.cpp was rebuilt). The version text sensor format has changed to include config hash. esphome#12425

Deprecations

custom_components folder: The custom_components folder is deprecated and will be removed in 2026.6.0. Users should migrate to external_components instead. A warning appears if the folder exists and contains files. esphome#12552

Lambda API Changes

Users with lambdas that access component state should note the following changes. These methods now return StringRef instead of const char*, which is safer but requires minor syntax changes:

Fan: get_preset_mode() returns StringRef. Use .empty() instead of != nullptr checks, and == for string comparison instead of strcmp(). esphome#13092
Select: current_option() returns StringRef. Use .empty() instead of != nullptr checks. esphome#13095
Climate: get_custom_fan_mode() and get_custom_preset() return StringRef. Use has_custom_fan_mode() or .empty() instead of != nullptr checks. esphome#13103
Event: get_last_event_type() returns StringRef. Use has_event() or .empty() instead of != nullptr checks. esphome#13104
Light: get_effect_name() returns StringRef instead of std::string. esphome#13105

Breaking Changes for Developers

Application API: get_compilation_time() deprecated (removal 2026.7.0), get_compilation_time_ref() removed. Use get_build_time() (Unix timestamp), get_config_hash(), get_config_version_hash(), or get_build_time_string(buffer) instead. esphome#12425
Fan API: Fan::get_preset_mode() returns StringRef instead of const char*. Returns empty ref when no preset is set. Use has_preset_mode() or .empty() instead of nullptr checks. New apply_preset_mode_(call) helper for derived classes. esphome#13092
Select API: Select::current_option() returns StringRef instead of const char*. Returns empty ref when no state is set. esphome#13095
Climate API: Climate::get_custom_fan_mode() and Climate::get_custom_preset() return StringRef instead of const char*. New StringRef overloads for set_custom_fan_mode_() and set_custom_preset_() protected setters. esphome#13103
Event API: Event::get_last_event_type() returns StringRef instead of const char*. New has_event() method added. esphome#13104
Light API: LightEffect::get_name() returns StringRef instead of const char*. LightState::get_effect_name() returns StringRef instead of std::string. New str_equals_case_insensitive(StringRef, StringRef) helper in helpers.h. esphome#13105
ESP8266 Serial: External components using Arduino Serial or Serial1 directly must call enable_serial() or enable_serial1() from esphome.components.esp8266.const in their to_code() function. esphome#12736

For detailed migration guides and API documentation, see the ESPHome Developers Documentation.

Release 2026.1.1 - January 22

[wifi] Process scan results one at a time to avoid heap allocation esphome#13400 by @bdraco
[lvgl] Validate LVGL dropdown symbols require Unicode codepoint ≥ 0x100 esphome#13394 by @Copilot
[http_request] Fix verify_ssl: false not working on ESP32 esphome#13422 by @swoboda1337
[esp32] Add warning for experimental 400MHz on ESP32-P4 esphome#13433 by @swoboda1337
[wifi] Fix bk72xx manual_ip preventing API connection esphome#13426 by @bdraco
[spi] Fix display init failure by marking displays as write-only for half-duplex mode esphome#13431 by @bdraco
[http_request] Fix OTA failures on ESP8266/Arduino by making read semantics consistent esphome#13435 by @bdraco
[dht] Increase delay for DHT22 and RHT03 esphome#13446 by @rguca
[api] Limit Nagle batching for log messages to reduce LWIP buffer pressure esphome#13439 by @bdraco
[wifi] Fix stale error_from_callback_ causing immediate connection failures esphome#13450 by @bdraco
[fingerprint_grow] Use buffer-based dump_summary to fix deprecation warnings esphome#13447 by @swoboda1337
[aqi] Remove unit_of_measurement to fix Home Assistant warning esphome#13448 by @swoboda1337
[time] Always call time sync callbacks even when time unchanged esphome#13456 by @bdraco

Release 2026.1.2 - January 25

[st7701s] Fix dump_summary deprecation warning esphome#13462 by @bdraco
[mipi_rgb] Fix dump_summary deprecation warning esphome#13463 by @bdraco
[rpi_dpi_rgb] Fix dump_summary deprecation warning esphome#13461 by @bdraco
[ir_rf_proxy] Remove unnecessary headers, add tests esphome#13464 by @kbx81
[mipi_rgb] Add software reset command to st7701s init sequence esphome#13470 by @clydebarrow
[slow_pwm] Fix dump_summary deprecation warning esphome#13460 by @bdraco
[sen5x] Fix store baseline functionality esphome#13469 by @mikelawrence
[lvgl] Fix setting empty text esphome#13494 by @clydebarrow
[light] Fix cwww state restore esphome#13493 by @kbx81
[rd03d] Fix speed and resolution field order esphome#13495 by @jasstrong
[modbus_controller] Fix YAML serialization error with custom_command esphome#13482 by @swoboda1337
[i2c] Increase ESP-IDF I2C transaction timeout from 20ms to 100ms esphome#13483 by @swoboda1337
[wifi] Fix watchdog timeout on P4 WiFi scan esphome#13520 by @clydebarrow
[wifi] Fix scan flag race condition causing reconnect failure on ESP8266/LibreTiny esphome#13514 by @bdraco

Release 2026.1.3 - January 29

Update webserver local assets to 20260122-204614 esphome#13455 by @esphomebot
[mhz19] Fix Uninitialized var warning message esphome#13526 by @sebcaps
[ota] Improve error message when device closes connection without responding esphome#13562 by @bdraco
[socket] ESP8266: call delay(0) instead of esp_delay(0, cb) for zero timeout esphome#13530 by @bdraco
[web_server] Add name_id to SSE for entity ID format migration esphome#13535 by @bdraco
Update webserver local assets to 20260127-190637 esphome#13573 by @esphomebot
[ld2450] preserve precision of angle esphome#13600 by @ccutrer
[wifi] Fix ESP8266 yield panic when WiFi scan fails esphome#13603 by @bdraco
[http_request] Fix empty body for chunked transfer encoding responses esphome#13599 by @bdraco

Release 2026.1.4 - February 4

[mipi_spi] Fix log_pin() FlashStringHelper compatibility esphome#13624 by @J0k3r2k1
[max7219] Allocate buffer in constructor esphome#13660 by @swoboda1337
[mqtt] resolve warnings related to use of ip.str() esphome#13719 by @rwrozelle
[core] Add missing uint32_t ID overloads for defer() and cancel_defer() esphome#13720 by @bdraco
[http_request] Fix requests taking full timeout when response is already complete esphome#13649 by @bdraco
[cse7766] Fix power reading stuck when load switches off esphome#13734 by @bdraco
[wifi] Fix wifi.connected condition returning false in connect state listener automations esphome#13733 by @bdraco
[ultrasonic] adjust timeouts and bring the parameter back esphome#13738 by @ssieb

Release 2026.1.5 - February 11

[rd03d] Revert incorrect field order swap esphome#13769 by @jasstrong
[core] Add capacity check to register_component_ esphome#13778 by @swoboda1337
[ota] Fix CLI upload option shown when only http_request platform configured esphome#13784 by @swoboda1337
[dashboard] Close WebSocket after process exit to prevent zombie connections esphome#13834 by @bdraco
[nrf52,logger] fix printk esphome#13874 by @tomaszduda23
[lvgl] Fix crash with unconfigured top_layer esphome#13846 by @clydebarrow
[esp32] Set UV_CACHE_DIR inside data dir so Clean All clears it esphome#13888 by @swoboda1337
[aqi] Fix AQI calculation for specific pm2.5 or pm10 readings esphome#13770 by @xconverge

Full List of Changes

For the complete list of every merged pull request in this release, see the full 2026.1.0 changelog.