ESPHome 2026.1.0 - January 2026

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 (#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 (#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.

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 (#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 (#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 (#12707). SHA256 is now mandatory, preventing protocol downgrade attacks.

ℹ️ Important

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, and than OTA to an earlier version.

HMAC-SHA256 Support

A new hmac_sha256 component provides HMAC support using the more secure SHA256 algorithm (#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 (#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 (#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 (#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 (#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 (#12690)
  • Unused Serial objects excluded - Saves 32-64 bytes RAM (#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 (#12681). The libc component alone shrank by ~15KB.

Logging Optimizations

Over 100 components received logging optimizations that combine consecutive log statements into single calls (#12838, #12860, #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 (#13010)
  • RAII guards for recursion protection - Optimized hot path performance (#13194)
  • StaticVector for log listeners - Compile-time sizing eliminates heap allocation (#13196)

Zero-Copy API Protocol

Zero-copy message handling is now complete and enabled by default for all protobuf messages (#12816), eliminating unnecessary memory copies during API communication. Combined with removing object_id from the wire protocol (#12818) and 33% smaller batch items (#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 (#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" (#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 (#13062)
  • Cortex-M4 atomics support - Enables proper atomic operations on RTL87xx and LN882x platforms (#13191)
  • Thread-safe WiFi - Improved WiFi reliability in multi-threaded scenarios (#13191)
  • Board regeneration - Updated board definitions with consolidated platform code (#13191)
  • Deep sleep support - BK7231n and BK7231t chips now support deep sleep with configurable timer and GPIO wake-up (#12267)
  • BLE stack disabled on BK7231N - Saves ~21KB RAM and ~225KB flash since ESPHome has no BLE support on LibreTiny (#13131)
  • LibreTiny 1.9.2 - Fixes GPIO interrupt issues on LN882H that caused HLW8012/BL0937 power sensors to report zero (#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 (#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 (#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 (#12203, #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 (#11535)
  • Sensor support - Expose ESPHome sensors via Zigbee’s Analog Input cluster with automatic unit mapping (#12187)
  • Switch support - Control ESPHome switches via Zigbee as binary output (#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 (#12489)

OTA Rollback Support

ESP32 devices using ESP-IDF now support automatic OTA rollback (#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 (#7072).

DSMR ESP-IDF Support

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

ESP32 Camera Performance

The esp32_camera component received significant performance improvements (#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 (#12498, #12516, #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 (#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 (#13129) provides the underlying infrastructure.

ir_rf_proxy:
  - name: "Living Room IR Blaster"
    remote_transmitter_id: ir_tx

  - name: "Bedroom IR Receiver"
    remote_receiver_id: ir_rx

Additional Features

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

  • Select: current_option() returns StringRef. Use .empty() instead of != nullptr checks. #13095

  • Climate: get_custom_fan_mode() and get_custom_preset() return StringRef. Use has_custom_fan_mode() or .empty() instead of != nullptr checks. #13103

  • Event: get_last_event_type() returns StringRef. Use has_event() or .empty() instead of != nullptr checks. #13104

  • Light: get_effect_name() returns StringRef instead of std::string. #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. #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. #13092

  • Select API: Select::current_option() returns StringRef instead of const char*. Returns empty ref when no state is set. #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. #13103

  • Event API: Event::get_last_event_type() returns StringRef instead of const char*. New has_event() method added. #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. #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. #12736

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

Full list of changes

New Features

New Components

  • Add hmac-sha256 support esphome#12437 by @dwmw2 (new-component)
  • [aqi, hm3301, pmsx003] Air Quality Index improvements esphome#12203 by @jasstrong (new-component) (new-feature) (breaking-change)
  • [water_heater] (1/4) Implement API/Core/component for new water_heater component esphome#12498 by @dhoeben (new-component) (new-feature)
  • Add BTHome advertisments parsing to Xiaomi Mijia BLE Sensors esphome#12635 by @nagyrobi (new-component) (new-feature) (new-platform)
  • [nrf52,zigbee] add support for binary_input esphome#11535 by @tomaszduda23 (new-component) (new-feature)
  • [rd03d] Add Ai-Thinker RD-03D mmWave radar component esphome#12764 by @jasstrong (new-component) (new-feature) (new-platform)
  • [infrared] Implement experimental API/Core/component for new component/entity type esphome#13129 by @kbx81 (new-component)
  • [ir_rf_proxy] New component esphome#12985 by @kbx81 (new-component) (new-feature)

New Platforms

Breaking Changes

All changes

All Changelogs