{ "version": "https://jsonfeed.org/version/1", "title": "Home Assistant Developer Docs Blog", "home_page_url": "https://developers.home-assistant.io/blog", "description": "Home Assistant Developer Docs Blog", "items": [ { "id": "https://developers.home-assistant.io/blog/2026/02/16/labs-async-listen-deprecation", "content_html": "

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

\n

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.

\n

Old usage​

\n
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,
)
\n

New usage​

\n
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,
)
\n

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

\n

async_listen will be removed in Home Assistant 2027.3.

\n

For more details, see core PR #162648.

", "url": "https://developers.home-assistant.io/blog/2026/02/16/labs-async-listen-deprecation", "title": "async_listen in Labs is deprecated", "summary": "The asynclisten helper in the labs integration has been deprecated in favor of asyncsubscribepreviewfeature.", "date_modified": "2026-02-16T00:00:00.000Z", "author": { "name": "Artur Pragacz", "url": "https://github.com/arturpragacz" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/01/13/replace-pre-commit-with-prek", "content_html": "

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.

\n

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

", "url": "https://developers.home-assistant.io/blog/2026/01/13/replace-pre-commit-with-prek", "title": "Replacing pre-commit with prek", "summary": "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.", "date_modified": "2026-01-13T00:00:00.000Z", "author": { "name": "Robert Resch", "url": "https://github.com/edenhaus" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/01/05/pyserial-asyncio-fast", "content_html": "

Summary of changes​

\n

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

\n

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

\n

Background​

\n

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.

\n

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

\n

Migration​

\n

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

\n

Requirements​

\n
# Old
  install_requires=[
    \"pyserial-asyncio\"
  ]

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

Usage​

\n
# 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)
\n

More examples are available in the tracking pull request.

", "url": "https://developers.home-assistant.io/blog/2026/01/05/pyserial-asyncio-fast", "title": "Solving pyserial-asyncio blocking the event loop", "summary": "Summary of changes", "date_modified": "2026-01-05T00:00:00.000Z", "author": { "name": "epenet", "url": "https://github.com/epenet" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/27/service-translation-placeholders", "content_html": "

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

\n

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

\n

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

", "url": "https://developers.home-assistant.io/blog/2025/11/27/service-translation-placeholders", "title": "Introducing description placeholders for service action translations", "summary": "It is now possible to use translation placeholders for (custom) service actions.", "date_modified": "2025-11-27T00:00:00.000Z", "author": { "name": "Jan Bouwhuis", "url": "https://github.com/jbouwh" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/25/storage-helper-opt-in-serialize-in-executor", "content_html": "

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

\n

If serialize_in_event_loop is True (the default):

\n\n

If serialize_in_event_loop is False:

\n\n

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.

\n

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.

\n

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

", "url": "https://developers.home-assistant.io/blog/2025/11/25/storage-helper-opt-in-serialize-in-executor", "title": "Serialization of Store data in worker thread is now opt-in", "summary": "The Store class from homeassistant/helpers/storage.py accepts a new constructor argument serializeinevent_loop", "date_modified": "2025-11-25T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/23/mqtt-subscribe-wait", "content_html": "

Add a status callback for MQTT subscriptions​

\n

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.

\n

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

\n

Example:

\n
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
", "url": "https://developers.home-assistant.io/blog/2025/11/23/mqtt-subscribe-wait", "title": "Add a status callback for MQTT subscriptions", "summary": "Add a status callback for MQTT subscriptions", "date_modified": "2025-11-23T00:00:00.000Z", "author": { "name": "Jan Bouwhuis", "url": "https://github.com/jbouwh" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/21/identify-buttons-diagnostic-category", "content_html": "

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

\n

For more details on entity category, see the documentation.

", "url": "https://developers.home-assistant.io/blog/2025/11/21/identify-buttons-diagnostic-category", "title": "Device identification buttons are now classified as diagnostic", "summary": "Button entities representing a device identification mechanism (using IDENTIFY device class) are now required to have their entity category set to DIAGNOSTIC.", "date_modified": "2025-11-21T00:00:00.000Z", "author": { "name": "Artur Pragacz", "url": "https://github.com/arturpragacz" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/20/labs-preview-features", "content_html": "

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.

\n

What are Labs preview features?​

\n

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.

\n

Think of it this way:

\n\n

How it works​

\n

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.

\n

Why Labs?​

\n

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

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

Example: Kitchen Sink special repair​

\n

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.

\n

Getting started​

\n

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

\n\n

What's next?​

\n

We encourage integration developers to consider Labs for:

\n\n

Labs is not for:

\n\n

Try it yourself​

\n

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.

", "url": "https://developers.home-assistant.io/blog/2025/11/20/labs-preview-features", "title": "Introducing Labs: Preview features before they become standard", "summary": "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.", "date_modified": "2025-11-20T00:00:00.000Z", "author": { "name": "Frenck", "url": "https://github.com/frenck" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/17/retry-after-update-failed", "content_html": "

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.

\n

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.\nThe 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.

\n

Example of the usage:

\n
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
\n

ConfigEntryNotReady​

\n

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.

", "url": "https://developers.home-assistant.io/blog/2025/11/17/retry-after-update-failed", "title": "Data Update Coordinator now supports Retry After", "summary": "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.", "date_modified": "2025-11-17T00:00:00.000Z", "author": { "name": "Erwin Douna", "url": "https://github.com/erwindouna" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/10/calculated-state-capability-attributes-removed", "content_html": "

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

\n

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

\n

For details, see core PR 151672.

", "url": "https://developers.home-assistant.io/blog/2025/11/10/calculated-state-capability-attributes-removed", "title": "The capability_attributes field removed from CalculatedState", "summary": "The capability_attributes field has been removed from CalculatedState. Capability attributes are still included in all attributes, which remain available in CalculatedState.", "date_modified": "2025-11-10T00:00:00.000Z", "author": { "name": "Artur Pragacz", "url": "https://github.com/arturpragacz" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/05/config-entry-oauth2-error-handling", "content_html": "

Integrations using Application Credentials and Configuration via OAuth2 need to update their error handling to correctly handle configuration when the internet is down.

\n

Currently integrations using configuration via OAuth2 call config_entry_oauth2_flow.async_get_config_entry_implementation in async_setup_entry in their __init__.py. Previously when there was no network, this would raise ValueError: Implementation not available, which was a non-retryable error, resulting in the integration needing to be manually reconfigured after internet was restored (see Issues 153956 and 144582). core PR 154579 added config_entry_oauth2_flow.ImplementationUnavailableError and raises it in config_entry_oauth2_flow.async_get_config_entry_implementation when OAuth2 configuration is unavailable because of missing internet. Integrations should catch this error and raise ConfigEntryNotReady.\nThe changed behavior with the new exception will be released in 2025.12.

\n

Here is an example of the migration,

\n
-    implementation = await async_get_config_entry_implementation(hass, entry)
+    try:
+        implementation = await async_get_config_entry_implementation(hass, entry)
+    except ImplementationUnavailableError as err:
+        raise ConfigEntryNotReady(
+            \"OAuth2 implementation temporarily unavailable, will retry\"
+        ) from err
\n

New integrations will find the correct try / except block generated by python3 -m script.scaffold config_flow_oauth2.

", "url": "https://developers.home-assistant.io/blog/2025/11/05/config-entry-oauth2-error-handling", "title": "Improved error handling for oauth2 configuration without internet", "summary": "Integrations using Application Credentials and Configuration via OAuth2 need to update their error handling to correctly handle configuration when the internet is down.", "date_modified": "2025-11-05T00:00:00.000Z", "author": { "name": "Will Moss", "url": "https://github.com/wmoss" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/11/04/convert-interval-deprecation", "content_html": "

The method convert_interval in TemperatureConverter (allowing conversions between °F and °C intervals) has been deprecated in favor of TemperatureDeltaConverter.convert.\nThe new converter and device class are now the preferred way to deal with temperature intervals.

\n

For details, see core PR 155689 and core PR 147358.

", "url": "https://developers.home-assistant.io/blog/2025/11/04/convert-interval-deprecation", "title": "TemperatureConverter.convert_interval deprecation", "summary": "The method convert_interval in TemperatureConverter (allowing conversions between °F and °C intervals) has been deprecated in favor of TemperatureDeltaConverter.convert.", "date_modified": "2025-11-04T00:00:00.000Z", "author": { "name": "Davide Perteghella", "url": "https://github.com/krahabb" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/10/24/service-web-api-changes", "content_html": "

Action translations defined in strings.json are no longer included in responses from the WebSocket get_services command and the REST /api/services endpoint because they were incomplete and the Home Assistant frontend did not use them.

\n

Legacy, untranslated action names and descriptions from services.yaml remain in both the WebSocket and REST responses.

\n

Fetch complete action translations with the WebSocket command frontend/get_translations.

\n

For details, see core PR 147120.

", "url": "https://developers.home-assistant.io/blog/2025/10/24/service-web-api-changes", "title": "Service translations removed from WebSocket get_services and REST /api/services", "summary": "Action translations defined in strings.json are no longer included in responses from the WebSocket get_services command and the REST /api/services endpoint because they were incomplete and the Home Assistant frontend did not use them.", "date_modified": "2025-10-24T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/10/16/recorder-statistics-api-changes", "content_html": "

The Python and WS APIs for injecting and modifying statistics have changed.

\n

The following changes have been made to the WS API:

\n\n

The following changes have been made to the Python API:

\n", "url": "https://developers.home-assistant.io/blog/2025/10/16/recorder-statistics-api-changes", "title": "Changes to the recorder statistics API", "summary": "The Python and WS APIs for injecting and modifying statistics have changed.", "date_modified": "2025-10-16T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/10/14/device-filter-removed-from-target-selector", "content_html": "

The device filter option is no longer supported by the target selector and has been removed from the target selector documentation.

\n

Hassfest has been updated to fail on services with device filter on targets.

\n

Validation of target selectors that specify a device filter will fail in Home Assistant Core 2026.11.

\n

Background​

\n

Core helpers that extract entities from targets did not support the device filter. When the user picked a floor, area, label, or category, the filter was ignored. The frontend also ignored the device filter when selecting entities for a target.

\n

A review of all core integrations found no correct use of a device filter on target selectors. We removed the device filter from the target selector rather than implement support for it in Core and the frontend.

\n

Impact on custom integrations and blueprints​

\n

Update custom integrations and blueprints to remove device filters from target selectors.

\n

If you have a valid use case for device filters on target selectors, reach out on Discord.

", "url": "https://developers.home-assistant.io/blog/2025/10/14/device-filter-removed-from-target-selector", "title": "Device filter has been removed from target selector", "summary": "The device filter option is no longer supported by the target selector and has been removed from the target selector documentation.", "date_modified": "2025-10-14T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/10/05/coordinator-retrigger", "content_html": "

The update coordinator with debouncer active will now accept a request for an update\nwhile an update is currently in progress. The request will be queued up to be performed\nafter the current update finishes.

\n

Consider the following case:

\n
async def _update():
    a = await get_a()
    # A: User or other logic request a new update here through async_schedule_update()
    b = await get_b()
    return (a,b)
\n

A user or code that request an updates at timestamp A expects that the entities linked will\nall get new data from that time. However, since we previously ignored that request, entities\nwould have data for the value of a that is from a time before the update request that was ignored.

\n

To make sure we avoid this case, the update coordinator will now schedule an additional\nupdate, if a request is received while currently executing an update.

\n

A side effect of this is that it is now possible to schedule an update from inside an update\nfunction of the coordinator. That is useful if for example a connection is lost mid update,\nand we want all entities to indicate directly as unavailable, yet we want to attempt a\nre-connect as quick as possible but do that in the next update cycle.

", "url": "https://developers.home-assistant.io/blog/2025/10/05/coordinator-retrigger", "title": "Update coordinator now allows retriggering", "summary": "The update coordinator with debouncer active will now accept a request for an update", "date_modified": "2025-10-05T00:00:00.000Z", "author": { "name": "Joakim Plate", "url": "https://github.com/elupus" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/09/25/entity-services-api-changes", "content_html": "

Platform entity services should be registered by calling the helper service.async_register_platform_entity_service from the integration's async_setup instead of calling platform.async_register_entity_service during platform set up.

\n

Existing integrations should be migrated to the new API to ensure loading the services does not depend on platform setup.

\n

For examples of migrating, see core PR 152172 and core PR 152047.

", "url": "https://developers.home-assistant.io/blog/2025/09/25/entity-services-api-changes", "title": "Improved API for registering platform entity services", "summary": "Platform entity services should be registered by calling the helper service.asyncregisterplatformentityservice from the integration's asyncsetup instead of calling platform.asyncregisterentity_service during platform set up.", "date_modified": "2025-09-25T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/09/22/deprecate-hass-argument-service-helpers", "content_html": "

Summary of changes​

\n

Providing hass argument to the following service helpers is deprecated:\nverify_domain_control, extract_entity_ids, async_extract_entities,\nasync_extract_entity_ids, and async_extract_config_entry_ids.

\n

Since release 2025.1 (via core PR #133062),\na reference to HomeAssistant is available as a property of the ServiceCall object,\nand it became redundant to pass the hass object to the above helpers.

\n

To update your integration, just remove the hass argument.

\n

Support for the hass argument will be removed in Home Assistant 2026.10.

\n

Examples​

\n

ID extraction helpers​

\n
# Old
# target_entry_ids = await async_extract_config_entry_ids(hass, service_call)
# entity_ids = await async_extract_entity_ids(hass, service_call)
# entities = await service.async_extract_entities(hass, platform_entities.values(), service_call)

# New
target_entry_ids = await async_extract_config_entry_ids(service_call)
entity_ids = await async_extract_entity_ids(service_call)
entities = await service.async_extract_entities(platform_entities.values(), service_call)
\n

Decorator helper​

\n
# Old
# @verify_domain_control(hass, DOMAIN)
# async def do_action(call: ServiceCall) -> None:
#     ...

# New
@verify_domain_control(DOMAIN)
async def do_action(call: ServiceCall) -> None:
    ...
", "url": "https://developers.home-assistant.io/blog/2025/09/22/deprecate-hass-argument-service-helpers", "title": "Deprecate hass argument in service helpers", "summary": "Summary of changes", "date_modified": "2025-09-22T00:00:00.000Z", "author": { "name": "epenet", "url": "https://github.com/epenet" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/08/20/micro-sign-encoding", "content_html": "

One preferred encoding to represent μ in units of measurement​

\n

The unit prefix μ is used by unit of measurement constants like μV and μS.\nThere are however two different Unicode encodings of μ:

\n
    \n
  1. The MICRO SIGN
    2. \n
  2. The Greek Small Letter Mu
    3. \n
\n

Home Assistant previously mixed the two encodings, which caused issues because string comparisons between the two encodings would fail causing unit of measurement validations to fail.

\n

We chose the \"Greek Small Letter Mu\" because the \"MICRO SIGN\" encoding is there for compatibility with old 8-bit western European character sets, and the unicode consortium recommends against using it.

\n

With #144853 we have fixed this in the core of Home Assistant by consequently using the Greek Small Letter Mu version to encode μ. In Python literal strings this variant is encoded as \"\\u03bc\".

\n

Developers should check if their code and libraries have a dependency with the ambiguous MICRO SIGN (μ) \"\\u00b5\", and migrate their code to use the Greek Small Letter Mu \"\\u03bc\" instead to avoid issues.

\n

The sensor and number entity platforms now include a built-in feature to automatically convert units that use the ambiguous MICRO SIGN (μ) encoding.

\n

Find instances in Visual Studio Code​

\n

In Visual Studio Code, enable Match Case in the Search (files) panel to find only the chosen encoding. Copy the exact μ character from above and paste it into the search box. The editor’s page search matches all variants; use the global search instead.

\n

New linter​

\n

To avoid issues with new or changed code, #144853 adds a linter that warns about incorrect literal assignments using the non-preferred encoding of μ.

", "url": "https://developers.home-assistant.io/blog/2025/08/20/micro-sign-encoding", "title": "Standardize encoding of μ in units of measurement", "summary": "One preferred encoding to represent μ in units of measurement", "date_modified": "2025-08-20T00:00:00.000Z", "author": { "name": "Jan Bouwhuis", "url": "https://github.com/jbouwh" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2025/08/01/suggested-area-removed-from-deviceentry", "content_html": "

The DeviceEntry.suggested_area attribute is deprecated and will be removed in HA Core 2026.9. Also, suggested_area will no longer be present in EVENT_DEVICE_REGISTRY_UPDATED events when HA Core 2026.9 is released.

\n

Note:\nSetting suggested_area in DeviceInfo, and passing suggested_area to DeviceRegistry.async_get_or_create is still supported and influences the area of created devices, although that may change in the future.

\n

Use DeviceEntry.area_id to determine a device’s area in custom integrations. Don’t access DeviceEntry.suggested_area.

\n

During the deprecation period, accessing DeviceEntry.suggested_area will log a warning.

\n

For more details, refer to the DeviceEntry documentation and core PR 149730 which deprecated DeviceEntry.suggested_area.

", "url": "https://developers.home-assistant.io/blog/2025/08/01/suggested-area-removed-from-deviceentry", "title": "The DeviceEntry.suggested_area attribute is deprecated and will be removed", "summary": "The DeviceEntry.suggestedarea attribute is deprecated and will be removed in HA Core 2026.9. Also, suggestedarea will no longer be present in EVENTDEVICEREGISTRY_UPDATED events when HA Core 2026.9 is released.", "date_modified": "2025-08-01T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] } ] }