<?xml version="1.0" encoding="UTF-8" ?> <?xml-stylesheet type="text/xsl" href="rss.xsl"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel> <title>ESPHome Developer Documentation</title><link>https://developers.esphome.io/</link><atom:link href="https://developers.esphome.io/feed_rss_created.xml" rel="self" type="application/rss+xml" /> <managingEditor>ESPHome</managingEditor><docs>https://github.com/esphome/developers.esphome.io/</docs><language>en</language> <pubDate>Mon, 15 Jun 2026 01:34:48 -0000</pubDate> <lastBuildDate>Mon, 15 Jun 2026 01:34:48 -0000</lastBuildDate> <ttl>1440</ttl> <generator>MkDocs RSS plugin - v1.19.0</generator> <image> <url>None</url> <title>ESPHome Developer Documentation</title> <link>https://developers.esphome.io/</link> </image> <item> <title>Modbus Server Split Out of modbus_controller</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Modbus Server Split Out of modbus_controller&lt;/h1&gt; &lt;p&gt;Modbus server mode has been split out of &lt;code&gt;modbus_controller&lt;/code&gt; into a new dedicated &lt;code&gt;modbus_server&lt;/code&gt; component. Configurations that used &lt;code&gt;modbus_controller&lt;/code&gt; as a Modbus server (the &lt;code&gt;role: server&lt;/code&gt; setting lives on the &lt;code&gt;modbus:&lt;/code&gt; bus, not on &lt;code&gt;modbus_controller&lt;/code&gt;) must move their &lt;code&gt;server_registers:&lt;/code&gt; and &lt;code&gt;server_courtesy_response:&lt;/code&gt; blocks under a new top-level &lt;code&gt;modbus_server:&lt;/code&gt; entry.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for YAML configurations using server mode in &lt;strong&gt;ESPHome 2026.5.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/05/14/modbus-server-split-out-of-modbus_controller/</link> <pubDate>Wed, 03 Jun 2026 22:11:30 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/05/14/modbus-server-split-out-of-modbus_controller/</guid> </item> <item> <title>Main Loop Cadence Decoupled from Scheduler Wake Timing</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Main Loop Cadence Decoupled from Scheduler Wake Timing&lt;/h1&gt; &lt;p&gt;Every component&#39;s &lt;code&gt;loop()&lt;/code&gt; now runs at the configured &lt;code&gt;loop_interval_&lt;/code&gt; (default ~62 Hz). Previously, &lt;strong&gt;when other scheduler activity was running&lt;/strong&gt; — &lt;code&gt;set_interval&lt;/code&gt; / &lt;code&gt;set_timeout&lt;/code&gt; / &lt;code&gt;PollingComponent&lt;/code&gt; updates with sub-&lt;code&gt;loop_interval_&lt;/code&gt; cadences — the component phase got pulled forward up to ~128 Hz; quiet configs with no such scheduler entries were unaffected and always ran at the documented rate. Background events (MQTT RX, USB RX, BLE events, ESPNOW, camera, &lt;code&gt;micro_wake_word&lt;/code&gt;, speaker, USB host/CDC, lwIP socket) still wake their component within one tick via the existing &lt;code&gt;wake_loop_*&lt;/code&gt; paths. &lt;code&gt;App.set_loop_interval()&lt;/code&gt; — the documented knob for power savings — finally works.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;behavior change&lt;/strong&gt; in &lt;strong&gt;ESPHome 2026.5.0 and later&lt;/strong&gt; with no API break, but it affects every component whose &lt;code&gt;loop()&lt;/code&gt; implicitly depended on running at ~2× the configured rate when scheduler activity was driving the pull-forward.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/05/14/main-loop-cadence-decoupled-from-scheduler-wake-timing/</link> <pubDate>Wed, 03 Jun 2026 22:11:25 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/05/14/main-loop-cadence-decoupled-from-scheduler-wake-timing/</guid> </item> <item> <title>ClimateTraits Boolean Accessors Removed in Favor of Feature Flags</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;ClimateTraits Boolean Accessors Removed in Favor of Feature Flags&lt;/h1&gt; &lt;p&gt;The ten deprecated &lt;code&gt;ClimateTraits::get/set_supports_*&lt;/code&gt; accessors have been removed. External climate components must migrate to the &lt;code&gt;add_feature_flags()&lt;/code&gt; / &lt;code&gt;has_feature_flags()&lt;/code&gt; API introduced in 2025.11.0 — the 6-month deprecation window has elapsed.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.5.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/05/14/climatetraits-boolean-accessors-removed-in-favor-of-feature-flags/</link> <pubDate>Wed, 03 Jun 2026 22:08:56 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/05/14/climatetraits-boolean-accessors-removed-in-favor-of-feature-flags/</guid> </item> <item> <title>FloatOutput Power Scaling Fields Gated Behind USE_OUTPUT_FLOAT_POWER_SCALING</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;FloatOutput Power Scaling Fields Gated Behind USE_OUTPUT_FLOAT_POWER_SCALING&lt;/h1&gt; &lt;p&gt;The &lt;code&gt;min_power_&lt;/code&gt; / &lt;code&gt;max_power_&lt;/code&gt; / &lt;code&gt;zero_means_zero_&lt;/code&gt; fields and their setters on &lt;code&gt;FloatOutput&lt;/code&gt; are now gated behind a new &lt;code&gt;USE_OUTPUT_FLOAT_POWER_SCALING&lt;/code&gt; build flag. The codegen turns the flag on automatically whenever a YAML config references the feature. Lambdas that call &lt;code&gt;id(out).set_min_power(...)&lt;/code&gt; / &lt;code&gt;set_max_power(...)&lt;/code&gt; / &lt;code&gt;set_zero_means_zero(...)&lt;/code&gt; without any matching YAML key or action will now fail to compile with a clear &lt;code&gt;static_assert&lt;/code&gt; pointing at the one-line YAML fix.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components and YAML configs that drive power scaling exclusively from lambdas in &lt;strong&gt;ESPHome 2026.5.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/05/14/floatoutput-power-scaling-fields-gated-behind-use_output_float_power_scaling/</link> <pubDate>Wed, 03 Jun 2026 22:08:41 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/05/14/floatoutput-power-scaling-fields-gated-behind-use_output_float_power_scaling/</guid> </item> <item> <title>Default-Constructed PollingComponent No Longer Polls</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Default-Constructed PollingComponent No Longer Polls&lt;/h1&gt; &lt;p&gt;The no-argument &lt;code&gt;PollingComponent()&lt;/code&gt; constructor now initializes the update interval to &lt;code&gt;SCHEDULER_DONT_RUN&lt;/code&gt; (&lt;code&gt;UINT32_MAX&lt;/code&gt;) instead of &lt;code&gt;1&lt;/code&gt;. External components that subclass &lt;code&gt;PollingComponent&lt;/code&gt;, instantiate it with no constructor argument, and never call &lt;code&gt;set_update_interval()&lt;/code&gt; will stop polling. Pass an interval to the constructor or call &lt;code&gt;set_update_interval()&lt;/code&gt; explicitly.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.5.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/05/14/default-constructed-pollingcomponent-no-longer-polls/</link> <pubDate>Wed, 03 Jun 2026 22:08:33 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/05/14/default-constructed-pollingcomponent-no-longer-polls/</guid> </item> <item> <title>RingBuffer Moved Out of Core Into ring_buffer Helper Component</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;RingBuffer Moved Out of Core Into ring_buffer Helper Component&lt;/h1&gt; &lt;p&gt;&lt;code&gt;RingBuffer&lt;/code&gt; has moved from &lt;code&gt;esphome/core/ring_buffer.h&lt;/code&gt; into a new &lt;code&gt;ring_buffer&lt;/code&gt; helper component at &lt;code&gt;esphome/components/ring_buffer/ring_buffer.h&lt;/code&gt; under the &lt;code&gt;esphome::ring_buffer&lt;/code&gt; namespace. The old location is deprecated and will be removed in &lt;strong&gt;ESPHome 2026.11.0&lt;/strong&gt;.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.5.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/05/14/ringbuffer-moved-out-of-core-into-ring_buffer-helper-component/</link> <pubDate>Mon, 18 May 2026 13:33:48 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/05/14/ringbuffer-moved-out-of-core-into-ring_buffer-helper-component/</guid> </item> <item> <title>TemplatableFn: 4-Byte Templatable Storage for Trivially Copyable Types</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;TemplatableFn: 4-Byte Templatable Storage for Trivially Copyable Types&lt;/h1&gt; &lt;p&gt;The &lt;code&gt;TEMPLATABLE_VALUE&lt;/code&gt; macro now uses &lt;code&gt;TemplatableFn&lt;/code&gt; (4 bytes) instead of &lt;code&gt;TemplatableValue&lt;/code&gt; (8 bytes) for trivially copyable types like &lt;code&gt;float&lt;/code&gt;, &lt;code&gt;uint32_t&lt;/code&gt;, &lt;code&gt;bool&lt;/code&gt;, and enums. External components that call macro-generated setters with raw C++ constants instead of going through &lt;code&gt;cg.templatable()&lt;/code&gt; will fail to compile.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/templatablefn-4-byte-templatable-storage-for-trivially-copyable-types/</link> <pubDate>Thu, 09 Apr 2026 23:59:26 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/templatablefn-4-byte-templatable-storage-for-trivially-copyable-types/</guid> </item> <item> <title>wake_loop Moved from Socket Component into Core</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;wake_loop Moved from Socket Component into Core&lt;/h1&gt; &lt;p&gt;&lt;code&gt;wake_loop_threadsafe()&lt;/code&gt; and related wake primitives have moved from the socket component into core. The &lt;code&gt;require_wake_loop_threadsafe()&lt;/code&gt; opt-in is deprecated (now a no-op) — wake works unconditionally on all platforms.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/wake_loop-moved-from-socket-component-into-core/</link> <pubDate>Thu, 09 Apr 2026 23:24:44 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/wake_loop-moved-from-socket-component-into-core/</guid> </item> <item> <title>BLE Event Handler Dispatch Devirtualized</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;BLE Event Handler Dispatch Devirtualized&lt;/h1&gt; &lt;p&gt;Virtual handler interfaces (&lt;code&gt;GAPEventHandler&lt;/code&gt;, &lt;code&gt;GAPScanEventHandler&lt;/code&gt;, &lt;code&gt;GATTcEventHandler&lt;/code&gt;, &lt;code&gt;GATTsEventHandler&lt;/code&gt;, &lt;code&gt;BLEStatusEventHandler&lt;/code&gt;) have been replaced with callback-based dispatch. External components that inherit from these interfaces must update their registration approach.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;developer breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/ble-event-handler-dispatch-devirtualized/</link> <pubDate>Thu, 09 Apr 2026 23:19:12 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/ble-event-handler-dispatch-devirtualized/</guid> </item> <item> <title>Climate and Fan Custom Mode Vectors Moved to Entity</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Climate and Fan Custom Mode Vectors Moved to Entity&lt;/h1&gt; &lt;p&gt;Custom mode vectors (&lt;code&gt;custom_fan_modes&lt;/code&gt;, &lt;code&gt;custom_presets&lt;/code&gt; for climate; &lt;code&gt;preset_modes&lt;/code&gt; for fan) are now stored on the entity base class instead of being rebuilt inside traits on every call. The old &lt;code&gt;ClimateTraits&lt;/code&gt; and &lt;code&gt;FanTraits&lt;/code&gt; setter methods are deprecated.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/climate-and-fan-custom-mode-vectors-moved-to-entity/</link> <pubDate>Thu, 09 Apr 2026 23:17:33 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/climate-and-fan-custom-mode-vectors-moved-to-entity/</guid> </item> <item> <title>Modbus Helper Functions Moved to modbus::helpers</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Modbus Helper Functions Moved to modbus::helpers&lt;/h1&gt; &lt;p&gt;Shared helper functions and types have been moved from &lt;code&gt;modbus_controller&lt;/code&gt; to &lt;code&gt;modbus::helpers&lt;/code&gt; to enable reuse by other modbus-based components. Deprecated shims keep the old names working until &lt;strong&gt;ESPHome 2026.10.0&lt;/strong&gt;.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;developer breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/modbus-helper-functions-moved-to-modbushelpers/</link> <pubDate>Thu, 09 Apr 2026 23:17:23 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/modbus-helper-functions-moved-to-modbushelpers/</guid> </item> <item> <title>Trigger Trampolines Eliminated with build_callback_automation</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Trigger Trampolines Eliminated with build_callback_automation&lt;/h1&gt; &lt;p&gt;Common entity trigger classes have been replaced with lightweight forwarder structs that fit inline in the callback system. The new &lt;code&gt;build_callback_automation()&lt;/code&gt; API eliminates per-trigger object allocations. Several entity callback signatures have also changed to pass state as an argument.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/trigger-trampolines-eliminated-with-build_callback_automation/</link> <pubDate>Thu, 09 Apr 2026 23:16:35 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/trigger-trampolines-eliminated-with-build_callback_automation/</guid> </item> <item> <title>Sensor .raw_state Deprecated in Favor of get_raw_state()</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Sensor .raw_state Deprecated in Favor of get_raw_state()&lt;/h1&gt; &lt;p&gt;Direct access to the sensor &lt;code&gt;.raw_state&lt;/code&gt; member is now deprecated. Use &lt;code&gt;get_raw_state()&lt;/code&gt; instead. The &lt;code&gt;.raw_state&lt;/code&gt; member will be removed in &lt;strong&gt;ESPHome 2026.10.0&lt;/strong&gt;.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/sensor-raw_state-deprecated-in-favor-of-get_raw_state/</link> <pubDate>Thu, 09 Apr 2026 23:13:12 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/sensor-raw_state-deprecated-in-favor-of-get_raw_state/</guid> </item> <item> <title>FlushResult Renamed to UARTFlushResult</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;FlushResult Renamed to UARTFlushResult&lt;/h1&gt; &lt;p&gt;The &lt;code&gt;FlushResult&lt;/code&gt; enum introduced in ESPHome 2026.3.0 has been renamed to &lt;code&gt;UARTFlushResult&lt;/code&gt; with prefixed enum values to follow ESPHome&#39;s naming conventions and avoid macro collisions.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/flushresult-renamed-to-uartflushresult/</link> <pubDate>Thu, 09 Apr 2026 22:14:54 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/flushresult-renamed-to-uartflushresult/</guid> </item> <item> <title>CallbackManager: std::function Replaced with Lightweight Callback</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;CallbackManager: std::function Replaced with Lightweight Callback&lt;/h1&gt; &lt;p&gt;&lt;code&gt;CallbackManager&lt;/code&gt; and &lt;code&gt;LazyCallbackManager&lt;/code&gt; now use a lightweight 8-byte &lt;code&gt;Callback&lt;/code&gt; struct instead of &lt;code&gt;std::function&lt;/code&gt; (16 bytes). External components that define their own callback registration methods using &lt;code&gt;std::function&lt;/code&gt; should update to templates for optimal performance.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.4.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/04/09/callbackmanager-stdfunction-replaced-with-lightweight-callback/</link> <pubDate>Thu, 09 Apr 2026 22:08:33 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/04/09/callbackmanager-stdfunction-replaced-with-lightweight-callback/</guid> </item> <item> <title>call_loop(), mark_failed(), and call_dump_config() Are No Longer Virtual</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;call_loop(), mark_failed(), and call_dump_config() Are No Longer Virtual&lt;/h1&gt; &lt;p&gt;&lt;code&gt;Component::call_loop()&lt;/code&gt;, &lt;code&gt;Component::mark_failed()&lt;/code&gt;, and &lt;code&gt;Component::call_dump_config()&lt;/code&gt; are no longer virtual methods. External components that override any of these methods must remove them entirely and move logic to &lt;code&gt;loop()&lt;/code&gt; or &lt;code&gt;dump_config()&lt;/code&gt;. This saves 800+ bytes of flash globally from vtable elimination.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.3.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/03/12/call_loop-mark_failed-and-call_dump_config-are-no-longer-virtual/</link> <pubDate>Fri, 27 Mar 2026 18:18:45 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/03/12/call_loop-mark_failed-and-call_dump_config-are-no-longer-virtual/</guid> </item> <item> <title>UART flush() Now Returns FlushResult</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;UART flush() Now Returns FlushResult&lt;/h1&gt; &lt;p&gt;The &lt;code&gt;UARTComponent::flush()&lt;/code&gt; method return type has changed from &lt;code&gt;void&lt;/code&gt; to &lt;code&gt;FlushResult&lt;/code&gt;. External components that subclass &lt;code&gt;UARTComponent&lt;/code&gt; and override &lt;code&gt;flush()&lt;/code&gt; must update their override to return a &lt;code&gt;FlushResult&lt;/code&gt; value.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.3.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/03/12/uart-flush-now-returns-flushresult/</link> <pubDate>Fri, 27 Mar 2026 18:18:35 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/03/12/uart-flush-now-returns-flushresult/</guid> </item> <item> <title>register_action Now Requires Explicit synchronous= Parameter</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;register_action Now Requires Explicit synchronous= Parameter&lt;/h1&gt; &lt;p&gt;All &lt;code&gt;register_action()&lt;/code&gt; calls now require an explicit &lt;code&gt;synchronous=True&lt;/code&gt; or &lt;code&gt;synchronous=False&lt;/code&gt; parameter. This enables the StringRef optimization for synchronous actions (zero-copy string argument passing) while ensuring asynchronous actions safely use owning &lt;code&gt;std::string&lt;/code&gt; to prevent dangling references. Existing external components will continue to work but will see a warning at config time until updated.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.3.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/03/12/register_action-now-requires-explicit-synchronous-parameter/</link> <pubDate>Fri, 27 Mar 2026 18:18:25 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/03/12/register_action-now-requires-explicit-synchronous-parameter/</guid> </item> <item> <title>Socket Abstraction Layer Devirtualized</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;Socket Abstraction Layer Devirtualized&lt;/h1&gt; &lt;p&gt;The &lt;code&gt;socket::Socket&lt;/code&gt; and &lt;code&gt;socket::ListenSocket&lt;/code&gt; types have been changed from virtual base classes to concrete type aliases. Listen sockets now use the &lt;code&gt;ListenSocket&lt;/code&gt; type instead of &lt;code&gt;Socket&lt;/code&gt;. These changes save 1,020–3,228 bytes of flash across platforms by eliminating virtual dispatch overhead.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.3.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/03/12/socket-abstraction-layer-devirtualized/</link> <pubDate>Fri, 27 Mar 2026 18:18:12 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/03/12/socket-abstraction-layer-devirtualized/</guid> </item> <item> <title>get_loop_priority() Now Conditionally Compiled with USE_LOOP_PRIORITY</title> <author>J. Nick Koston</author> <description>&lt;h1&gt;get_loop_priority() Now Conditionally Compiled with USE_LOOP_PRIORITY&lt;/h1&gt; &lt;p&gt;The &lt;code&gt;get_loop_priority()&lt;/code&gt; virtual method on &lt;code&gt;Component&lt;/code&gt; is now only available when &lt;code&gt;USE_LOOP_PRIORITY&lt;/code&gt; is defined. This define is only set on RP2040, the only platform where loop priority has an effect. External components that override &lt;code&gt;get_loop_priority()&lt;/code&gt; must guard the override with &lt;code&gt;#ifdef USE_LOOP_PRIORITY&lt;/code&gt;.&lt;/p&gt; &lt;p&gt;This is a &lt;strong&gt;breaking change&lt;/strong&gt; for external components in &lt;strong&gt;ESPHome 2026.3.0 and later&lt;/strong&gt;.&lt;/p&gt;</description> <link>https://developers.esphome.io/blog/2026/03/12/get_loop_priority-now-conditionally-compiled-with-use_loop_priority/</link> <pubDate>Fri, 27 Mar 2026 18:17:58 +0000</pubDate> <source url="https://developers.esphome.io/feed_rss_created.xml">ESPHome Developer Documentation</source><guid isPermaLink="true">https://developers.esphome.io/blog/2026/03/12/get_loop_priority-now-conditionally-compiled-with-use_loop_priority/</guid> </item> </channel> </rss>