What changed and why​

The old builder ran every architecture build inside a single privileged Docker-in-Docker container using QEMU emulation. This was slow, required elevated privileges, and those who were already familiar with Docker needed to learn how to use the custom Home Assistant's builder container. The old builder also had unnecessary maintenance overhead. Today, what the builder does can be fully replaced with Docker BuildKit, which is natively supported on GitHub Actions runners and has built-in multi-arch support with QEMU emulation if needed.

For your CI, the replacement is a set of focused composite GitHub Actions that delegate building to the runner's native Docker with Docker BuildKit. Outside the CI, the migration means that your Dockerfile is now the single source of truth for building your app image, and you can use docker build directly to build and test your app locally without needing to use the builder container.

Migration process​

The migration has two parts: updating your Dockerfiles and updating your GitHub Actions workflows.

Update Dockerfiles​

The new build workflow doesn't use build.yaml anymore. Move the content into your Dockerfile as follows:

• build_from - replace the build_from key in build.yaml with a FROM statement in your Dockerfile:

  FROM ghcr.io/home-assistant/base:latest
  

  As the base images are now published as multi-platform manifests, there is usually no need to define per-arch base images anymore. The build-image action still supplies BUILD_ARCH as a build argument though, so you can use that in your Dockerfile if you need to use it in the template for the base image name.

• labels - move any custom Docker labels directly into your Dockerfile with a LABEL statement:

  LABEL \
      org.opencontainers.image.title="Your awesome app" \
      org.opencontainers.image.description="Description of your app." \
      org.opencontainers.image.source="https://github.com/your/repo" \
      org.opencontainers.image.licenses="Apache License 2.0"
  

  If you are creating a custom workflow, note that the legacy builder used to add the io.hass.type, io.hass.name, io.hass.description, and io.hass.url labels automatically. The new actions do not infer these values, so add them explicitly via the labels input of the build-image (or similar) action.

• args - move custom build arguments into your Dockerfile as ARG definitions with default values:

  ARG MY_BUILD_ARG="default-value"
  

  Default values in ARG replace what was previously supplied via build.yaml's args dictionary. They can still be overridden at build time with --build-arg if needed.

With the content of build.yaml migrated, you can delete the file from your repository.

Update GitHub Actions workflows​

Remove any workflow steps using home-assistant/builder@master and replace them with the new composite actions. See the example workflow in our example app repository for a complete working example. Alternatively, use the individual actions in a more custom workflow as needed.

Image naming​

The preferred way to reference a published app image is now the generic (multi-arch) name without an architecture prefix:

# config.yaml
image: "ghcr.io/my-org/my-app"

The {arch} placeholder (e.g. ghcr.io/my-org/{arch}-my-app) is still supported as a compatibility fallback, but it's encouraged to use the generic name and let the manifest handle the platform resolution.

Local builds​

After updating your Dockerfile, you can use docker build to build the app image directly - you can refer to Local app testing for more details.

Apps built locally by Supervisor​

For backward compatibility, Supervisor still reads build.yaml file if it's present and populates the image build arguments with values read from this file. This will produce warnings and eventually be removed in the future, so it's recommended to migrate to the new Dockerfile-based approach as described above.

See the architecture discussion for the full background.

Architecture​

The infrared domain sits between two types of integrations:

• Emitter integrations (ESPHome, Broadlink, …) implement the InfraredEntity base class to provide hardware-specific IR transmission.
• Consumer integrations (LG, Samsung, Daikin, …) use helper functions to send device-specific IR commands through available emitters.

Users select which emitter to use during the consumer integration's config flow.

Implementing an emitter integration​

Emitter integrations provide the infrared platform by subclassing InfraredEntity and implementing async_send_command. The command's get_raw_timings() method returns protocol-agnostic timing data that the hardware can transmit:

from homeassistant.components.infrared import InfraredCommand, InfraredEntity

class MyInfraredEntity(InfraredEntity):
    """My IR transmitter."""

    async def async_send_command(self, command: InfraredCommand) -> None:
        """Send an IR command."""
        timings = [
            interval
            for timing in command.get_raw_timings()
            for interval in (timing.high_us, -timing.low_us)
        ]
        await self._device.transmit(
            carrier_frequency=command.modulation,
            timings=timings,
        )

The raw protocol-agnostic timings should be converted to the specific format required by the hardware.

Building a consumer integration​

Consumer integrations control IR devices by sending commands through an emitter entity. They don't interact with IR hardware directly.

1. Declare the dependency in manifest.json:

{
  "dependencies": ["infrared"]
}

2. Let the user pick an emitter in the config flow:

from homeassistant.components import infrared

emitters = infrared.async_get_emitters(hass)
if not emitters:
    return self.async_abort(reason="no_emitters")

3. Send IR commands using the helper function and the infrared-protocols library:

from infrared_protocols.codes.lg.tv import LGTVCode, make_lg_tv_command
from homeassistant.components import infrared

await infrared.async_send_command(
    hass,
    self._infrared_entity_id,
    make_lg_tv_command(LGTVCode.VOLUME_UP),
    context=self._context,
)

IR protocols and codes​

IR protocol encoders and device code sets live outside Home Assistant in the infrared-protocols library. Common protocols (NEC, Samsung, etc.) and well-known device codes should be contributed there. For niche or proprietary protocols, a separate third-party library can also be used.

For full details, see the infrared entity documentation.

ha-input​

We keep migrating our Material Design based components to Web Awesome based. This time we migrated the input components, which leads to an API change but the look and feel stays the same for now.

• ha-input is the successor of ha-textfield
  • ha-textfield API stays but the component is migrated to use ha-input internally and will be removed in 2026.5
  • Also replaces ha-outlined-text-field
• ha-input-search replaces search-input and search-input-outlined
• ha-input-multi replaces ha-multi-textfield
• ha-input-copy replaces copy-textfield

This component also introduces new semantic theme variables for form backgrounds:

--ha-color-form-background: var(--ha-color-neutral-95);
--ha-color-form-background-hover: var(--ha-color-neutral-90);
--ha-color-form-background-disabled: var(--ha-color-neutral-80);

Date picker​

We finally removed the Vue 2 dependency by replacing the date and date range picker with Cally.

Each dialog managed by the dialog manager was only opened once and stayed in the DOM for the lifetime of the application. This causes:

• More memory usage: Dialogs accumulate in the DOM even when not visible
• More bugs because of missing state reset: Dialog state persists between opens, leading to stale data or unexpected behavior

The Solution: DialogMixin​

We implemented a new way of handling dialogs using DialogMixin. With this approach:

• Dialogs are created when opened and destroyed when closed: No need to manually reset the state of the dialog when it is closed
• Closed events are automatically handled: The dialog mixin takes care of cleanup
• Subscribe mixin can now be used in dialogs: Since dialogs are properly destroyed, subscriptions are cleaned up automatically
• Use normal Lit lifecycle methods: Use connectedCallback to initialize when the dialog is opened instead of relying on the showDialog method

Example​

Check out ha-dialog-date-picker for a reference implementation. DialogMixin adds dialog params to this.params if available.

In the Home Assistant frontend, a Context is a way to share data across the component tree without explicitly passing it through every level as a property. Instead of threading the hass object down through multiple layers of components, you can provide specific pieces of data via context and consume them only where needed.

The key benefits of using context over passing the entire hass object are:

• Easier usage: Components can directly consume the data they need without requiring parent components to pass it down. This reduces prop drilling and makes components more self-contained and reusable.
• Reducing unnecessary component re-renders: When a component receives hass as a property, any change to hass triggers a re-render of that component and all its children—even if the component only cares about a small subset of the data. By using context to provide only the specific data a component needs, you ensure that components only re-render when their actual dependencies change, leading to better performance and a more responsive UI.

Introducing LazyContext​

We've introduced a new LazyContext pattern that should replace the traditional subscription-based approach and the usage of the SubscribeMixin. Previously, components would subscribe to data sources and manage subscription lifecycles manually, often leading to boilerplate code and potential memory leaks if subscriptions weren't properly cleaned up.

LazyContext simplifies this by:

• Lazy loading: Data is only fetched when a component actually consumes the context
• Automatic cleanup: Subscriptions are managed automatically
• Shared state: Multiple components consuming the same context share a single subscription
• Optimized re-renders: Only components that consume the context re-render when data changes

This approach centralizes data-fetching logic and makes it easier to reason about when and how data flows through your application.

Examples​

Defining a LazyContext​

To define a lazy context, use LazyContextProvider and provide a fetch function:

new LazyContextProvider(this, {
  context: labelsContext,
  subscribeFn: (connection, setValue) => subscribeLabelRegistry(connection, setValue),
})

Consuming a context with lit​

To consume a context in a component, use the @consume decorator:

@state()
@consume({ context: labelsContext, subscribe: true })
private _labels?: LabelRegistryEntry[];

Check out the updated custom card example to use it in vanilla JS: Custom card example.

Using @transform for derived Data​

Only available within the home-assistant frontend codebase

The @transform decorator allows you to derive data from a context value, ensuring your component only re-renders when the transformed value actually changes.

@state()
@consume({ context: statesContext, subscribe: true })
@transform({
  transformer: function (this: HuiButtonCard, entityStates: HassEntities) {
    return this._config?.entity ? entityStates?.[this._config?.entity] : undefined;
  },
  watch: ["_config"],
})
private _stateObj?: HassEntity;

With @transform, even if the full states object updates, your component will only re-render if the transformed result (_stateObj) actually changes. The watch option allows you to specify additional properties that should trigger re-evaluation of the transformer function—in this case, when _config changes, the transformer runs again to extract the correct entity state.

class ExampleBackupAgent(BackupAgent):

    async def async_upload_backup(
        self,
        *,
        open_stream: Callable[[], Coroutine[Any, Any, AsyncIterator[bytes]]],
        backup: AgentBackup,
        on_progress: OnProgressCallback,
        **kwargs: Any,
    ) -> None:
        """Upload a backup."""
        ...
        bytes_uploaded = 0
        async for chunk in await open_stream():
            await do_upload(chunk)
            bytes_uploaded += len(chunk)
            on_progress(bytes_uploaded=bytes_uploaded)
        ...

The backup manager uses these progress reports to fire UploadBackupEvent events, enabling the frontend to display real-time upload progress to the user.

Check the backup agent documentation for more details.

Local brand images for custom integrations​

Add a brand/ directory to your custom integration with your icon and logo files:

custom_components/my_integration/
├── __init__.py
├── manifest.json
└── brand/
    ├── icon.png
    └── logo.png

The following image filenames are supported:

• icon.png / dark_icon.png
• logo.png / dark_logo.png
• icon@2x.png / dark_icon@2x.png
• logo@2x.png / dark_logo@2x.png

Local brand images automatically take priority over images from the brands CDN. That's it — no extra configuration needed.

For more details, see the integration file structure documentation.

Brand images now served through a local API​

To make local brand images possible, all brand images are now served through the Home Assistant local API instead of being fetched directly from the CDN by the browser.

A new brands system integration proxies brand images through two endpoints:

• /api/brands/integration/{domain}/{image} — Integration icons and logos
• /api/brands/hardware/{category}/{image} — Hardware images

Images are cached locally on disk and served with a stale-while-revalidate strategy, so they remain available during internet outages.

Impact on the frontend​

The brandsUrl() and hardwareBrandsUrl() helpers in src/util/brands-url.ts now return local API paths instead of CDN URLs. If your custom card or panel uses these helpers, no changes are needed.

If you are constructing brand image URLs manually, update them:

// Old
const url = `https://brands.home-assistant.io/_/${domain}/icon.png`;

// New
import { brandsUrl } from "../util/brands-url";
const url = brandsUrl({ domain, type: "icon" });

These endpoints require authentication. The brandsUrl() helper handles this automatically by appending an access token. If you construct URLs manually, obtain a token via the brands/access_token WebSocket command and append it as a token query parameter.

In October 2022, Home Assistant migrated the preferred color temperature unit from mired to kelvin.

In February 2024, Home Assistant requested explicit supported_color_modes and color_mode properties (triggering deprecation of legacy fallback color mode support).

In December 2024, Home Assistant requested explicit Kelvin support (triggering deprecation of mired support).

It is now time to clean up the legacy code and remove the corresponding attributes, constants and properties:

• Remove deprecated ATTR_COLOR_TEMP, ATTR_MIN_MIREDS, ATTR_MAX_MIREDS, ATTR_KELVIN, COLOR_MODE_***, and SUPPORT_*** constants
• Remove deprecated state attributes ATTR_COLOR_TEMP, ATTR_MIN_MIREDS and ATTR_MAX_MIREDS
• Remove deprecated support for ATTR_KELVIN and ATTR_COLOR_TEMP arguments from the light.turn_on service call
• Remove deprecated support for LightEntity.color_temp, LightEntity.min_mireds and LightEntity.max_mireds properties from the entity
• Remove deprecated support for LightEntity._attr_color_temp, LightEntity._attr_min_mireds and LightEntity._attr_max_mireds shorthand attributes from the entity

Additionally, failing to provide valid supported_color_modes and color_mode properties no longer works and will raise an error.

Examples​

Custom minimum/maximum color temperature​

class MyLight(LightEntity):
    """Representation of a light."""

    # Old
    # _attr_min_mireds = 200 # 5000K
    # _attr_max_mireds = 400 # 2500K

    # New
    _attr_min_color_temp_kelvin = 2500 # 400 mireds
    _attr_max_color_temp_kelvin = 5000 # 200 mireds

Default minimum/maximum color temperature​

from homeassistant.components.light import DEFAULT_MAX_KELVIN, DEFAULT_MIN_KELVIN

class MyLight(LightEntity):
    """Representation of a light."""

    # Old did not need to have _attr_min_mireds / _attr_max_mireds set
    # New needs to set the default explicitly
    _attr_min_color_temp_kelvin = DEFAULT_MIN_KELVIN
    _attr_max_color_temp_kelvin = DEFAULT_MAX_KELVIN

Dynamic minimum/maximum color temperature​

from homeassistant.util import color as color_util

class MyLight(LightEntity):
    """Representation of a light."""

    # Old
    # def min_mireds(self) -> int:
    #     """Return the coldest color_temp that this light supports."""
    #     return device.coldest_temperature
    #
    # def max_mireds(self) -> int:
    #     """Return the warmest color_temp that this light supports."""
    #     return device.warmest_temperature

    # New
    def min_color_temp_kelvin(self) -> int:
        """Return the warmest color_temp that this light supports."""
        return color_util.color_temperature_mired_to_kelvin(device.warmest_temperature)

    def max_color_temp_kelvin(self) -> int:
        """Return the coldest color_temp that this light supports."""
        return color_util.color_temperature_mired_to_kelvin(device.coldest_temperature)

Checking color temperature in service call​

from homeassistant.components.light import ATTR_COLOR_TEMP_KELVIN
from homeassistant.util import color as color_util

class MyLight(LightEntity):
    """Representation of a light."""
    def turn_on(self, **kwargs: Any) -> None:
        """Turn on the light."""
        # Old
        # if ATTR_COLOR_TEMP in kwargs:
        #     color_temp_mired = kwargs[ATTR_COLOR_TEMP]
        #     color_temp_kelvin = color_util.color_temperature_mired_to_kelvin(color_temp_mired)

        # Old
        # if ATTR_KELVIN in kwargs:
        #     color_temp_kelvin = kwargs[ATTR_KELVIN]
        #     color_temp_mired = color_util.color_temperature_kelvin_to_mired(color_temp_kelvin)

        # New
        if ATTR_COLOR_TEMP_KELVIN in kwargs:
            color_temp_kelvin = kwargs[ATTR_COLOR_TEMP_KELVIN]
            color_temp_mired = color_util.color_temperature_kelvin_to_mired(color_temp_kelvin)

Background information​

• Community discussion about Kelvin temperature
• Core PR #79591: Migration to Kelvin
• Architecture discussion #564
• Color modes documentation

Starting as of 2026.3, we're enhancing how the OAuth 2.0 helper handles token request and refresh token failures. This change makes error handling more robust, decoupled from the aiohttp library and helps integrations, that utilize the Data Update Coordinator, to automatically trigger the right error handling.

What changes​

When an OAuth 2.0 token request or token refresh failed, Home Assistant would allow the underlying aiohttp.ClientResponseError to propagate directly to the integration. This behavior is being changed and enhanced.

We're introducing three new exceptions that provide clearer semantics:

• OAuth2TokenRequestTransientError - Recoverable errors, that can be retried.
• OAuth2TokenRequestReauthError - Non-recoverable errors, that require a reauthentication.
• OAuth2TokenRequestError - Base exception for when the above two criteria aren't met or to enable the integration to catch all token request exceptions.

Data Update Coordinator​

Most integrations that use the OAuth 2.0 helper, also use the Data Update Coordinator. When a token request or refresh token fails, the exceptions will bubble up in the Data Update Coordinator and now triggers the following error handling:

For unrecoverable errors (400+, except 429 (rate limit)):

• OAuth2TokenRequestReauthError: Data Update Coordinator raises ConfigEntryAuthFailed if exceptions should be raised or starts a reauthentication flow.

For transient errors (500+ and 429):

• OAuth2TokenRequestTransientError: Data Update Coordinator treats it as an UpdateFailed and the retry mechanism will be triggered.

This means that integrations that use the OAuth 2.0 helper in combination with the Data Update Coordinator don’t need to do any special handling of the new exceptions.

Migration​

Integrations that today use the OAuth 2.0 helper and handle aiohttp.ClientResponseError explicitly should adjust their error handling to deal with the new exceptions. To ease this transition, we have added a compatibility layer by having the new OAuth exceptions inherit from aiohttp.ClientResponseError. Existing code that catches this exception type should continue to work. It is however encouraged to refactor the code to use the new exceptions. See the code example for details.

Code example of migration​

Update the exception handling and then continue to work out if it's a (non-)recoverable error in the integration. For example:

    try:
        await auth.async_get_access_token()
    except OAuth2TokenRequestReauthError as err:
        raise ConfigEntryAuthFailed(
            translation_domain=DOMAIN, translation_key="reauth_required"
        ) from err
    except (OAuth2TokenRequestError, ClientError) as err:
        raise ConfigEntryNotReady(
            translation_domain=DOMAIN, translation_key="auth_server_error"
        ) from err

Custom integrations using the webhook config flow helper must add translation strings for the reconfiguration flow.

Example translation strings for a reconfiguration flow:

{
  "config": {
    "abort": {
      "reconfigure_successful": "**Reconfiguration was successful**\n\nIn Sleep as Android go to *Settings → Services → Automation → Webhooks* and update the webhook with the following URL:\n\n`{webhook_url}`"
    },
    "step": {
      "reconfigure": {
        "description": "Are you sure you want to re-configure the Sleep as Android integration?",
        "title": "Reconfigure Sleep as Android"
      }
    }
  }
}

For more details, see core PR #151729.

The new async_subscribe_preview_feature function provides a more consistent API, where the listener callback receives an EventLabsUpdatedData parameter containing the updated feature state. This eliminates the need to separately call async_is_preview_feature_enabled inside the listener to check the current value.

Old usage​

from homeassistant.components.labs import async_is_preview_feature_enabled, async_listen

def my_listener() -> None:
    if async_is_preview_feature_enabled(hass, DOMAIN, "my_feature"):
        # feature enabled
        ...

async_listen(
    hass,
    domain=DOMAIN,
    preview_feature="my_feature",
    listener=my_listener,
)

New usage​

from homeassistant.components.labs import EventLabsUpdatedData, async_subscribe_preview_feature

async def my_listener(event_data: EventLabsUpdatedData) -> None:
    if event_data["enabled"]:
        # feature enabled
        ...

async_subscribe_preview_feature(
    hass,
    domain=DOMAIN,
    preview_feature="my_feature",
    listener=my_listener,
)

Note that the new listener is a coroutine function and receives EventLabsUpdatedData as a parameter.

async_listen will be removed in Home Assistant 2027.3.

For more details, see core PR #162648.

New development environments will automatically install prek and for existing ones please just update the test requirements by running uv pip install requirements_test.txt

Starting in 2026.7, installation of pyserial-asyncio will be blocked in Home Assistant.

Library maintainers and custom integrations are advised to migrate to pyserial-asyncio-fast.

Background​

pyserial-asyncio blocks the event loop because it does a blocking sleep. The library is also not maintained so efforts to improve the situation haven't been released.

pyserial-asyncio-fast was created as a drop-in replacement (see the repository), and all core integrations have now been migrated.

Migration​

pyserial-asyncio-fast was designed as a drop-in replacement of pyserial-asyncio, and the necessary changes are trivial.

Requirements​

# Old
  install_requires=[
    "pyserial-asyncio"
  ]

# New
  install_requires=[
    "pyserial-asyncio-fast"
  ]

Usage​

# Old
import serial_asyncio

async def connect():
    conn = await serial_asyncio.open_serial_connection(**self.serial_settings)

# New
import serial_asyncio_fast

async def connect():
    conn = await serial_asyncio_fast.open_serial_connection(**self.serial_settings)

More examples are available in the tracking pull request.

The service action example now shows how to supply the available description placeholders during the registration of the service action.

Move URLs from service descriptions and translation strings into description placeholders.

If serialize_in_event_loop is True (the default):

• The data_func passed to Store.async_delay_save is called from the event loop
• Data produced by data_func passed to Store.async_delay_save is serialized to JSON in the event loop
• Data passed to Store.async_save is serialized to JSON in the event loop

If serialize_in_event_loop is False:

• The data_func passed to Store.async_delay_save is called from a separate thread, which means it must be thread safe and must not access the hass object
• Data produced by data_func passed to Store.async_delay_save is serialized to JSON in a separate thread, which means it must be thread safe
• Data passed to Store.async_save is serialized to JSON in a separate thread, which means it must be thread safe

The behavior has changed; data_func passed to Store.async_delay_save was previously always called from a separate thread and data produced by it or data passed to Store.async_save was previously always serialized by a separate thread.

The reason for the change is that it was not documented that data_func would be called by a thread other than the event loop or that JSON serialization would happen in a thread other than the event loop, and the data_func and data produced by it or passed to Store.async_save was generally not thread safe.

For more details, see core PR 157158 and core PR 157263.

Integrations that use MQTT might need to wait for a subscription to complete before they initiate actions. The default behavior is that a subscription is queued and debounced, so callers usually do not wait for broker confirmation. Some integrations must guarantee that the broker finished the subscription.

The new mqtt.async_on_subscribe_done helper can be used to monitor MQTT subscriptions, to allow doing additional tasks. Make sure the same QoS is used as in the MQTT subscription.

Example:

from homeassistant.components import mqtt

async def async_setup_entry(hass: HomeAssistant, entry: ConfigEntry) -> bool:
    """Setup integration MQTT subscription monitoring."""

    def _on_subscribe_status() -> None:
        """Handle subscription ready signal."""
        # Do stuff

    # Handle subscription ready status update
    await mqtt.async_on_subscribe_done(
        hass,
        "myintegration/status",
        qos=1,
        on_subscribe_status=_on_subscribe_status,
    )

    # Do stuff

For more details on entity category, see the documentation.

What are Labs preview features?​

Labs preview features are different from beta testing. While beta testing evaluates the stability of upcoming Home Assistant releases, Labs is about refining user interfaces and design. Labs features are fully tested and functional, but their design and behavior may still change as we gather real-world usage and feedback. This means they might have breaking changes, be extended with new functionality, or even be removed if they don't work out.

Think of it this way:

• Beta: Evaluates the stability of upcoming Home Assistant releases
• Labs: Fully tested features with evolving design and user interface, refined through real-world usage and feedback

How it works​

Integrations declare preview features in their manifest.json with links for feedback, documentation, and issue reporting. Users can then enable these features in Settings → System → Labs, and they activate immediately without requiring a restart. The integration code checks whether a feature is enabled and responds accordingly.

Why Labs?​

Many of our most significant improvements benefit from real-world testing before becoming standard. Labs provides:

1. Structured feedback channels: Each feature has dedicated URLs for feedback, documentation, and issue reporting
2. Runtime activation: Features enable and disable instantly, no configuration updates or restart required
3. Clear expectations: Users know they're trying fully tested features whose design may change based on feedback
4. Iterative development: Integrate user feedback directly into the development process

Example: Kitchen Sink special repair​

The Kitchen Sink demo integration includes a working example. When enabled, the "special repair" feature creates a repair issue to demonstrate how Labs features can interact with other Home Assistant integrations. See the developer documentation for the complete implementation.

Getting started​

Ready to add a Labs preview feature to your integration? Check out our comprehensive guide which covers:

• When to use Labs (and when not to)
• How to define features in your manifest
• Implementation patterns for backend and frontend features
• Runtime activation requirements
• Testing approaches
• Feature lifecycle (preview → standard or removal)

What's next?​

We encourage integration developers to consider Labs for:

• Major UI changes or redesigns
• Significant architectural changes that benefit from real-world testing
• Features where user feedback will shape the final design

Labs is not for:

• Permanent configuration options (use integration options instead)
• Minor changes that can go directly into releases
• Features with critical bugs or that are fundamentally incomplete

Try it yourself​

Want to see Labs in action? Install the Kitchen Sink demo integration and enable the "Special repair" feature in Settings → System → Labs. You'll see firsthand how preview features work.

In situations where polling API's would return a sign of being overwhelmed, by throwing an HTTP 429 or providing a Retry-After in the response header, integrations can now honor these backoff signals. The integration and API client must detect these backoff signals and sanitize the API's desired backoff period. The UpdateFailed exception accepts a retry_after parameter (a float in seconds) to delay the next scheduled refresh. Once the API recovers and UpdateFailed is no longer raised, the integration resumes its normal update_interval.

Example of the usage:

try:
    request = await self.client.get_information()
except APIClientRateLimited as err:
    raise UpdateFailed(
        retry_after=60  # This can also be retrieved from the API response itself, or provide a default
    ) from err

ConfigEntryNotReady​

The retry_after parameter is ignored during the Update Coordinator setup phase (async_config_entry_first_refresh). If the first refresh fails, Home Assistant raises a ConfigEntryNotReady exception, allowing config entry setup to retry automatically using the built-in retry. Once the coordinator setup succeeds, retry_after applies to following refreshes.

CalculatedState is the container with state and attributes returned by Entity._async_calculate_state.

For details, see core PR 151672.