The async_listen helper in the labs integration has been deprecated in favor of async_subscribe_preview_feature.

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.

By replacing pre-commit with prek we can increase the performance of our checks. Prek uses the same .pre-commit-config.yaml as pre-commit and is a complete replacement. Due to the fact that prek is written in Rust and allows the execution of different jobs in parallel, we can check our code even faster.

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

Summary of changes​

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.

It is now possible to use translation placeholders for (custom) service actions.

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.

The Store class from homeassistant/helpers/storage.py accepts a new constructor argument serialize_in_event_loop

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.

Add a status callback for MQTT subscriptions​

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

Button entities representing a device identification mechanism (using IDENTIFY device class) are now required to have their entity category set to DIAGNOSTIC.

For more details on entity category, see the documentation.

We're excited to announce a new system for shipping preview features in Home Assistant: Labs. Labs provides a standardized way for integrations to offer fully tested features that users can opt into before they become standard, allowing us to gather feedback and refine the design based on real-world usage.

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.

Integrations using the Data Update Coordinator can enhance the UpdateFailed exception with a new parameter retry_after to defer the next scheduled refresh by a specified number of seconds and then resume the normal cadence once the API has recovered.

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.

The capability_attributes field has been removed from CalculatedState. Capability attributes are still included in all attributes, which remain available in CalculatedState.

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

For details, see core PR 151672.