{ "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/07/05/modernizing-modbus", "content_html": "

Modbus is everywhere in the modern home: solar inverters, energy meters, heat pumps, and all kinds of industrial equipment that has found its way indoors. Home Assistant has long supported these devices through the YAML-based modbus integration, where users hand-write register maps in their configuration. That integration is not going anywhere, and existing setups keep working. But hand-writing register maps puts the burden of understanding a device's protocol on every user, and it does not fit the config-flow, UI-first direction the rest of Home Assistant has taken.

\n

So we are adding a new way to use Modbus: an integration-based approach, where a device integration owns the device-specific knowledge and the user simply picks their device in the UI, the same as any other integration.

\n

Sharing a connection​

\n

A Modbus connection is a single, exclusive resource: only one party can talk on the bus at a time. A serial (RS-485) bus, or a TCP-to-serial gateway, can carry many devices at once, sometimes from different manufacturers. If two integrations each open their own connection to the same bus, they fight over it, and historically Home Assistant did not support sharing a bus between integrations at all.

\n

The new modbus_connection integration solves this by making a connection something device integrations route through rather than own. The user sets up a connection once in the UI, and modbus_connection keeps it open and manages its lifecycle, including reconnecting after a drop. Device integrations then borrow what they need from that shared connection instead of managing their own. We have revamped the Modbus developer documentation to cover how that works, with example code.

\n

A standalone library​

\n

The connection abstraction underneath modbus_connection lives in modbus-connection, a new library we designed for this purpose and published on PyPI. It is not bound to Home Assistant and can be used standalone in any Python project. It presents a common, backend-neutral interface, so device library authors write against one API regardless of the underlying Modbus implementation, and it ships a device-modelling framework and a pytest plugin to make building and testing a device library straightforward.

\n

This keeps concerns where they belong. A device library is a normal PyPI package that knows how to talk to a specific device, and a consuming integration in Home Assistant wires that library up to a shared connection and exposes entities. Both can be developed and tested independently.

\n

For more background, see our research.

\n

Let's get building​

\n

With these new building blocks in place, it is now possible to turn a collection of YAML configuration for Modbus into manufacturer-specific integrations that people can set up via the UI. If you're (interested in) working on this, stop by the #modbus channel on the Home Assistant Discord and we'll be happy to help.

\n

If you're using an AI agent, you can give it the following prompt:

\n
\n

I want to create a new integration for Home Assistant using the new Modbus Connection integration as documented here: https://developers.home-assistant.io/docs/modbus/introduction

\n

The YAML we want to turn into a device library can be found here: TODO INSERT LOCATION OF MODBUS YAML!

\n

The deliverables of this task are going to be 3 folders:

\n\n
", "url": "https://developers.home-assistant.io/blog/2026/07/05/modernizing-modbus", "title": "Modernizing Modbus in Home Assistant", "summary": "Modbus is everywhere in the modern home: solar inverters, energy meters, heat pumps, and all kinds of industrial equipment that has found its way indoors. Home Assistant has long supported these devices through the YAML-based modbus integration, where users hand-write register maps in their configuration. That integration is not going anywhere, and existing setups keep working. But hand-writing register maps puts the burden of understanding a device's protocol on every user, and it does not fit the config-flow, UI-first direction the rest of Home Assistant has taken.", "date_modified": "2026-07-05T00:00:00.000Z", "author": { "name": "Paulus Schoutsen", "url": "https://github.com/balloob" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/07/03/media-source-search", "content_html": "

Media sources can now implement search. By adding an async_search_media method to your MediaSource, users can search through your media directly from the media browser.

\n
from homeassistant.components.media_player import SearchMedia, SearchMediaQuery

async def async_search_media(
    self, item: MediaSourceItem, query: SearchMediaQuery
) -> SearchMedia:
    \"\"\"Search media.\"\"\"
    results = [...]  # list of BrowseMediaSource items
    return SearchMedia(result=results)
\n

To tell the media browser which items can be searched, set the can_search flag to True on the BrowseMediaSource items you return while browsing (typically directories). Other integrations can trigger a search through the new media_source.async_search_media helper.

\n

For more info, see the updated documentation.

", "url": "https://developers.home-assistant.io/blog/2026/07/03/media-source-search", "title": "Media sources can now be searched", "summary": "Media sources can now implement search. By adding an asyncsearchmedia method to your MediaSource, users can search through your media directly from the media browser.", "date_modified": "2026-07-03T00:00:00.000Z", "author": { "name": "Josef Zweck", "url": "https://github.com/zweckj" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/06/30/async-initialize-triggers-home-assistant-start-deprecated", "content_html": "

The dedicated home_assistant_start flag of async_initialize_triggers is deprecated and will be removed in Home Assistant Core 2027.8. During the deprecation period the parameter no longer has any effect.

\n

The flag existed because the homeassistant start trigger was a pseudo trigger: instead of acting like a real trigger, it relied on the caller of the trigger API passing home_assistant_start=True so that async_initialize_triggers would fire the trigger during startup.

\n

The start trigger has been rewritten to work as a real trigger, so the flag is no longer needed. Callers of async_initialize_triggers should simply stop passing home_assistant_start.

\n

To make the new implementation possible, the rewrite adds HomeAssistant.async_add_startup_job, which registers a job to be called after all listeners to EVENT_HOMEASSISTANT_START have executed, but before EVENT_HOMEASSISTANT_STARTED is fired. This mirrors the approach already used for the homeassistant shutdown trigger, and avoids adding yet another core state and event to the already complex relationship between core states and events.

\n

For more details, see core PR 175160.

", "url": "https://developers.home-assistant.io/blog/2026/06/30/async-initialize-triggers-home-assistant-start-deprecated", "title": "Deprecation of the home_assistant_start flag of async_initialize_triggers", "summary": "The dedicated homeassistantstart flag of asyncinitializetriggers is deprecated and will be removed in Home Assistant Core 2027.8. During the deprecation period the parameter no longer has any effect.", "date_modified": "2026-06-30T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/06/30/new-unit-enumerators", "content_html": "

As of Home Assistant Core 2026.7, the following unit constants are deprecated and replaced\nby a corresponding enum:

\n\n

CONCENTRATION_PARTS_PER_CUBIC_METER was only used by a single integration and is deprecated\nwithout a replacement unit.

\n

Please note that the use of PERCENTAGE constant is also deprecated when used as a unit of\nmeasurement, even if the constant itself is not deprecated.

", "url": "https://developers.home-assistant.io/blog/2026/06/30/new-unit-enumerators", "title": "Introducing new unit enumerators", "summary": "As of Home Assistant Core 2026.7, the following unit constants are deprecated and replaced", "date_modified": "2026-06-30T00:00:00.000Z", "author": { "name": "epenet", "url": "https://github.com/epenet" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/06/23/frontend-component-updates-2026.7", "content_html": "

Component updates​

\n

Component sizes use Web Awesome names​

\n

ha-button, ha-button-toggle-group, and ha-slider now use the short Web Awesome size names.

\n

For ha-button, use:

\n
<ha-button size=\"s\">Save</ha-button>
\n

Supported values are xs, s, m, l, and xl.

\n

For ha-button-toggle-group, use s or m:

\n
<ha-button-toggle-group size=\"s\" .buttons=${buttons}></ha-button-toggle-group>
\n

ha-slider uses s or m.

\n

If your custom card or editor still uses small, medium, or large on these components, migrate them to short values like s, m, or l.

\n

Virtualized lists​

\n

We added two list components for large data sets:

\n\n

Use these when a picker or dialog can render enough rows to affect scrolling or initial render time. The virtualized list renders only the visible rows while keeping the roving-tabindex keyboard navigation from ha-list-base.

\n

Rows expose accessibility metadata with aria-setsize and aria-posinset, so assistive technologies still get the full list position even though only part of the list is in the DOM.

\n

For selectable lists, render ha-list-item-option rows.

\n

Context and editor infrastructure​

\n

Dirty state tracking​

\n

Dialogs and editors now have shared dirty-state infrastructure:

\n\n

Use DirtyStateProviderMixin for new dialogs or editors that need to block scrim close, enable Save only after edits, or coordinate dirty state with child components.

\n
class MyDialog extends DirtyStateProviderMixin<MyState>()(LitElement) {
  public openDialog() {
    this._initDirtyTracking({ type: \"shallow\" }, this._state);
  }

  private _stateChanged(state: MyState) {
    this._updateDirtyState(state);
  }
}
\n

isDirtyState is the raw comparison and is usually right for enabling Save. isEffectiveDirtyState can ignore equivalent config output, for example when an editor normalizes an explicit default back to the same effective config.

\n

Related context​

\n

Pages and editors can now publish related context for nearby pickers:

\n\n

When a card editor, badge editor, automation trace page, or similar surface knows the current entity, device, or area, it can provide that context. Entity pickers and add-element searches can then prioritize related entities, devices, and areas.

\n
fireEntityRelatedContext(this, \"light.kitchen\");
\n

Clear the context with undefined when the editor no longer has a related item.

\n

Narrow viewport context​

\n

narrowViewportContext exposes whether the main Home Assistant viewport is in the narrow layout.

\n

Components that only need narrow-layout state can consume this context instead of receiving narrow through several layers of properties.

\n
@consume({ context: narrowViewportContext, subscribe: true })
private _narrow!: boolean;
\n

Lovelace updates​

\n

Strategy regeneration control​

\n

Lovelace strategies can now avoid unnecessary regeneration.

\n

Strategies may declare registryDependencies to use the default reference-change check for only the registries they depend on:

\n
static registryDependencies = [\"entities\", \"areas\"] as const;
\n

For custom logic, implement shouldRegenerate():

\n
static shouldRegenerate(config, oldHomeAssistant, newHomeAssistant) {
  return oldHomeAssistant.entities !== newHomeAssistant.entities;
}
\n

If neither is provided, strategies keep the previous default behavior and regenerate on changes to entities, devices, areas, or floors.

", "url": "https://developers.home-assistant.io/blog/2026/06/23/frontend-component-updates-2026.7", "title": "Frontend component updates in 2026.7", "summary": "Component updates", "date_modified": "2026-06-23T00:00:00.000Z", "author": { "name": "Jan-Philipp Benecke", "url": "https://github.com/jpbede" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/06/15/device-tracker-changes", "content_html": "

Summary​

\n

There have been multiple recent changes to the device tracker entity model:

\n\n

Details​

\n

Deprecation of battery_level​

\n

The battery_level property has been deprecated in all device tracker base classes, and will stop working in Home Assistant Core 2027.7. Integrations should communicate battery level via a battery sensor instead.

\n

More details can be found in architecture proposal #627

\n

Deprecation of location_name​

\n

The location_name property of TrackerEntity has been deprecated, and will stop working in Home Assistant Core 2027.7.

\n

Integrations with device trackers which do not know or do not want to report the exact coordinates and today use location_name to report the name of a zone should instead report a list of zone entity IDs through the in_zones property.\nDevice trackers which use location_name to give extra context can instead do that via a separate sensor or an extra state attribute.

\n

More details can be found in architecture proposal #1387

\n

Introduction of the BaseScannerEntity base class​

\n

The BaseScannerEntity class should be used by integrations which have scanners which do not track connection to a WLAN or other local network, for example scanners which track connection to a BLE beacon.

\n

Users can associate BaseScannerEntity and ScannerEntity with any zone​

\n

BaseScannerEntity and ScannerEntity store the associated zone as an entity registry option. The base class will set the state of the entity to the name of the associated zone when connected, and the in_zones state attribute to all zones which contain the associated zone.

\n

More details can be found in architecture proposal #1389

\n

Introduction of the in_zones state attribute​

\n

A new state attribute in_zones is present in the state of device tracker entities. The state attribute is automatically calculated by BaseScannerEntity and ScannerEntity. TrackerEntity will derive the in_zones state attribute from the in_zones property if not None, if it is None it will be calculated from the reported location.

\n

The in_zones state attribute is a list of zone entity IDs sorted by size, with the smallest zone first, then by distance to center.

\n

Introduction of the tracking_type capability attribute​

\n

A new capability attribute tracking_type is present in the state of device tracker entities. The state attribute is set to connection by BaseScannerEntity and ScannerEntity and to location by TrackerEntity. Integrations should not override this behavior.

", "url": "https://developers.home-assistant.io/blog/2026/06/15/device-tracker-changes", "title": "Changes to device tracker entity models", "summary": "Summary", "date_modified": "2026-06-15T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/27/custom-card-suggestions", "content_html": "

As of Home Assistant 2026.6, custom cards can show up as suggestions in the card picker. When a user selects an entity, custom cards that opt in are listed under a Community section, below the built-in suggestions.

\n

To opt in, add a getEntitySuggestion function to your window.customCards entry. It receives the hass object and the selected entity id, and returns a suggestion (or null if the entity is not supported):

\n
window.customCards.push({
  type: \"my-card\",
  name: \"My Card\",
  getEntitySuggestion: (hass, entityId) => {
    if (entityId.split(\".\")[0] !== \"light\") {
      return null;
    }
    return {
      config: { type: \"custom:my-card\", entity: entityId },
    };
  },
});
\n

You can also return an array of suggestions to offer several variants, each with its own label.

\n

Only suggest your card when it makes sense for the entity. Check the domain, device class, or supported features with the hass object, and return null otherwise. Suggesting your card for every entity makes the picker noisy.

\n

See the custom card documentation for the full reference.

", "url": "https://developers.home-assistant.io/blog/2026/05/27/custom-card-suggestions", "title": "Custom card suggestions in the card picker", "summary": "As of Home Assistant 2026.6, custom cards can show up as suggestions in the card picker. When a user selects an entity, custom cards that opt in are listed under a Community section, below the built-in suggestions.", "date_modified": "2026-05-27T00:00:00.000Z", "author": { "name": "Paul Bottein", "url": "https://github.com/piitaya" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/27/frontend-component-updates-2026.6", "content_html": "

Component updates​

\n

ha-radio updates​

\n

ha-radio was removed from our codebase, we use the webawesome based ha-radio-group with ha-radio-option now. No need for a ha-formfield around a ha-radio anymore and you can use the new CSS properties to customize the radio group and options.

\n

New component specific tokens:

\n
--ha-radio-group-required-marker
--ha-radio-group-required-marker-offset

--ha-radio-option-active-color
--ha-radio-option-heigh
--ha-radio-option-toggle-size
--ha-radio-option-border-width
--ha-radio-option-border-color
--ha-radio-option-border-color-hover
--ha-radio-option-background-color
--ha-radio-option-background-color-hover
--ha-radio-option-checked-background-color
--ha-radio-option-checked-icon-color
--ha-radio-option-checked-icon-scale
--ha-radio-option-control-margin
\n

ha-drawer updates​

\n

ha-drawer was updated to use the webawesome drawer component. The API is mostly the same it just uses now --ha-sidebar-width instead of --mdc-drawer-width

\n

top bar​

\n\n

The --ha-top-app-bar-width token replaces --mdc-top-app-bar-width.

\n

New decorators​

\n

@consumeLocalize​

\n

Following up on the context entry decorators introduced last release, we added a shortcut for the most common single-field read off internationalizationContext: the localize function.

\n

Before:

\n
@state()
@consume({ context: internationalizationContext, subscribe: true })
@transform<HomeAssistantInternationalization, LocalizeFunc>({
  transformer: ({ localize }) => localize,
})
private _localize!: LocalizeFunc;
\n

After:

\n
@state()
@consumeLocalize()
private _localize!: LocalizeFunc;
\n

Use @consumeLocalize() whenever a component only needs the localize function. For other single-field reads off internationalizationContext (e.g. locale, language), keep using @consume + @transform.

", "url": "https://developers.home-assistant.io/blog/2026/05/27/frontend-component-updates-2026.6", "title": "Frontend component updates in 2026.6", "summary": "Component updates", "date_modified": "2026-05-27T00:00:00.000Z", "author": { "name": "Wendelin Peleska", "url": "https://github.com/wendevlin" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/26/advanced-mode-config-flow-deprecation", "content_html": "

Summary​

\n

User profile advanced mode is going away, which means integrations can no longer check if advanced mode is enabled or not in data entry flows.

\n

Integrations authors need to update integrations to use an alternative user friendly way to present additional options in the UI, for example group additional options in a section.

\n

FlowHandler.show_advanced_options​

\n

The FlowHandler.show_advanced_options property has been deprecated and will be removed with the release of Home Assistant Core 2027.6. During the deprecation period, FlowHandler.show_advanced_options unconditionally returns True to not make options gated by this flag inaccessible to users.

\n

FlowHandler.context['show_advanced_options']​

\n

There is no longer a show_advanced_options key in FlowHandler.context.

\n

Background​

\n

The Advanced mode toggle in the user profile is a single binary switch that gates a collection of unrelated features across Home Assistant, from app (add-on) visibility (Terminal & SSH) to configuration options and UI elements, and we've been working on removing it during the past year.

\n

For a more in-depth explanation, see roadmap issue #54.

", "url": "https://developers.home-assistant.io/blog/2026/05/26/advanced-mode-config-flow-deprecation", "title": "Deprecation of advanced mode in data entry flow", "summary": "Summary", "date_modified": "2026-05-26T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/20/browse-media-source-root-class", "content_html": "

The BrowseMediaSource class in the media_source integration has been tightened up. The domain parameter is now a required str instead of str | None, and the special \"list every media source\" root node has moved to its own class, RootBrowseMediaSource.

\n

Previously, domain was optional only to represent one edge case: the top-level node returned when browsing media-source:// with no specific source selected. That made the type hint misleading for the 99% case — every actual media source has a domain — and added a None branch that consumers had to think about. Splitting the root into its own class removes that branch.

\n

What changed​

\n\n

Impact on custom integrations​

\n

Most integrations don't need any changes. If you implement a media_source.py platform, you were already passing your own domain to BrowseMediaSource — that keeps working.

\n

You only need to act if:

\n\n

See the updated media source platform documentation for the full reference.

", "url": "https://developers.home-assistant.io/blog/2026/05/20/browse-media-source-root-class", "title": "BrowseMediaSource: domain is now required", "summary": "The BrowseMediaSource class in the media_source integration has been tightened up. The domain parameter is now a required str instead of str | None, and the special \"list every media source\" root node has moved to its own class, RootBrowseMediaSource.", "date_modified": "2026-05-20T00:00:00.000Z", "author": { "name": "Paulus Schoutsen", "url": "https://github.com/balloob" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/13/condition-script-api-changes", "content_html": "

Summary​

\n

The condition and script APIs have been changed.

\n

Conditions are now instances of condition classes, which are evaluated by calling the async_check method and discarded by calling the async_unload method. Also, conditions may optionally implement an _async_setup or _async_unload method. Note that users of conditions don't need to call the condition's async_setup method.

\n

During a deprecation period, which ends with the release of Home Assistant Core 2027.1, it's possible to use the condition object as a callable.

\n

Scripts also have an async_unload method which must be called when the script is no longer needed.

\n

Impact on custom integrations​

\n

Custom integrations which create conditions or scripts​

\n

Custom integrations which create condition objects should evaluate them by calling the async_check method and call the async_unload method when the condition is no longer needed.

\n

Example:

\n
from homeassistant.helpers.condition import (
    async_condition_from_config,
    async_validate_condition_config,
)

# Validate condition config
validated_config = await async_validate_condition_config(hass, config)

# Create a condition
condition = await async_condition_from_config(hass, validated_config)

...

# Evaluate the condition
result = condition.async_check(...)
...

# Discard the condition
condition.async_unload()
\n

Custom integrations which create scripts should call the async_unload method when the script is no longer needed.

\n

Example:

\n
from homeassistant.helpers.script import (
    Script,
    async_validate_actions_config,
)

# Validate script config
validated_config = await async_validate_actions_config(hass, config)

# Create a script
script = Script(hass, validated_config, ...)

...

# Execute the script
result = await script.async_run(...)
...

# Discard the script
await script.async_unload()
\n

Custom integrations which provide a condition platform​

\n

Integrations which provide a condition platform don't need to change, but may implement _async_setup and _async_unload method if the platform needs to perform async initialization or do tear down.

\n

Example:

\n

from homeassistant.core import HomeAssistant
from homeassistant.helpers.condition import (
    Condition,
    ConditionCheckParams,
    ConditionConfig,
)
from homeassistant.helpers.typing import ConfigType

class CustomCondition(Condition):
    \"\"\"A custom condition.\"\"\"

    @classmethod
    async def async_validate_config(
        cls, hass: HomeAssistant, config: ConfigType
    ) -> ConfigType:
        \"\"\"Validate config.\"\"\"
        ...

    def __init__(self, hass: HomeAssistant, config: ConditionConfig) -> None:
        \"\"\"Initialize condition.\"\"\"
        super().__init__(hass, config)
        ...

    async def _async_setup(self) -> None:
        \"\"\"Set up the condition checker.\"\"\"
        ...

    def _async_unload(self) -> None:
        \"\"\"Clean up any resources held by the checker.\"\"\"
        ...

    def _async_check(self, **kwargs: Unpack[ConditionCheckParams]) -> bool:
        \"\"\"Check the condition.\"\"\"
        ...
", "url": "https://developers.home-assistant.io/blog/2026/05/13/condition-script-api-changes", "title": "Changes to the condition and script APIs", "summary": "Summary", "date_modified": "2026-05-13T00:00:00.000Z", "author": { "name": "Erik Montnemery", "url": "https://github.com/emontnemery" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/11/format-entity-name-helper", "content_html": "

As of Home Assistant 2026.4, the hass object exposes a formatEntityName helper. It is the same function used by the built-in cards (tile card, entity rows, ...) to compute the display name of an entity from its registry context (entity, device, area, floor). Custom cards can use it to produce names that stay consistent with the rest of the dashboard.

\n

Given a temperature sensor named Temperature on a device named Thermostat:

\n
const stateObj = hass.states[\"sensor.living_room_thermostat_temperature\"];

hass.formatEntityName(
  stateObj,
  [{ type: \"device\" }, { type: \"entity\" }],
  { separator: \" · \" }
); // \"Thermostat · Temperature\"
\n

The frontend also ships an entity_name selector. If your card uses the built-in form editor, you can offer users the same name picker the built-in cards use — accepting either a free-form string or a composition of registry items.

\n

Take a look at the updated data documentation for the full reference and more examples.

", "url": "https://developers.home-assistant.io/blog/2026/05/11/format-entity-name-helper", "title": "Format entity names in custom cards", "summary": "As of Home Assistant 2026.4, the hass object exposes a formatEntityName helper. It is the same function used by the built-in cards (tile card, entity rows, ...) to compute the display name of an entity from its registry context (entity, device, area, floor). Custom cards can use it to produce names that stay consistent with the rest of the dashboard.", "date_modified": "2026-05-11T00:00:00.000Z", "author": { "name": "Paul Bottein", "url": "https://github.com/piitaya" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/11/mqtt-publish-api-changes", "content_html": "

In the future, the MQTT publish API will require explicit values for qos and retain. Passing None for either argument will no longer be supported.\nCustom integrations should update their code to accept the defaults, or pass valid typed arguments.\nThe fallbacks of None to a valid value for qos and retain will stop working with HA Core 2027.6.

\n

The new API signatures are:

\n
def publish(
    hass: HomeAssistant,
    topic: str,
    payload: PublishPayloadType,
    qos: int = 0,
    retain: bool = False,
    encoding: str | None = DEFAULT_ENCODING,
) -> None:
    \"\"\"Publish message to a MQTT topic.\"\"\"
    hass.create_task(async_publish(hass, topic, payload, qos, retain, encoding))
\n

and

\n
async def async_publish(
    hass: HomeAssistant,
    topic: str,
    payload: PublishPayloadType,
    qos: int = 0,
    retain: bool = False,
    encoding: str | None = DEFAULT_ENCODING,
) -> None:
    \"\"\"Publish message to a MQTT topic.\"\"\"
", "url": "https://developers.home-assistant.io/blog/2026/05/11/mqtt-publish-api-changes", "title": "MQTT publish API changes", "summary": "In the future, the MQTT publish API will require explicit values for qos and retain. Passing None for either argument will no longer be supported.", "date_modified": "2026-05-11T00:00:00.000Z", "author": { "name": "Jan Bouwhuis", "url": "https://github.com/jbouwh" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/11/mqtt-publish-api-message-expiry-interval", "content_html": "

The MQTT publish API now supports setting a message expiry interval.\nPreviously, retained messages were stored by the broker until they were replaced or explicitly cleared. With a message_expiry_interval set (in seconds), a published message — including a retained one — will automatically expire after the specified interval.\nThis option is only supported when using MQTT protocol version 5; it is ignored when using earlier protocol versions.

\n

The new API signatures are:

\n
def publish(
    hass: HomeAssistant,
    topic: str,
    payload: PublishPayloadType,
    qos: int = 0,
    retain: bool = False,
    encoding: str | None = DEFAULT_ENCODING,
    *,
    message_expiry_interval: int | None = None,
) -> None:
    \"\"\"Publish message to a MQTT topic.\"\"\"
\n

and

\n
async def async_publish(
    hass: HomeAssistant,
    topic: str,
    payload: PublishPayloadType,
    qos: int = 0,
    retain: bool = False,
    encoding: str | None = DEFAULT_ENCODING,
    *,
    message_expiry_interval: int | None = None,
) -> None:
    \"\"\"Publish message to a MQTT topic.\"\"\"
", "url": "https://developers.home-assistant.io/blog/2026/05/11/mqtt-publish-api-message-expiry-interval", "title": "MQTT publish API supports message expiry interval", "summary": "The MQTT publish API now supports setting a message expiry interval.", "date_modified": "2026-05-11T00:00:00.000Z", "author": { "name": "Jan Bouwhuis", "url": "https://github.com/jbouwh" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/07/config-entry-listener-together-with-reloading-methods", "content_html": "

As of Home Assistant Core 2026.6, using a config entry listener together with any reloading methods in a config flow is deprecated and will result in an error from 2026.12.

\n

Background​

\n

Using a config entry listener together with any reloading methods in a config flow can cause the integration to reload twice and/or create a race condition.

\n

Possible solutions​

\n\n

More details can be found in the core PR.

", "url": "https://developers.home-assistant.io/blog/2026/05/07/config-entry-listener-together-with-reloading-methods", "title": "Deprecating config entry listener with reloading methods in config flow", "summary": "As of Home Assistant Core 2026.6, using a config entry listener together with any reloading methods in a config flow is deprecated and will result in an error from 2026.12.", "date_modified": "2026-05-07T00:00:00.000Z", "author": { "name": "G Johansson", "url": "https://github.com/gjohansson-ST" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/04/frontend-component-updates-2026.5", "content_html": "

Component updates​

\n

ha-progress-bar​

\n

A new component replaces mwc-progress-bar in our codebase and is fully themeable. Check out this PR for a fully custom progress bar.

\n

New component specific tokens:

\n
--ha-progress-bar-indicator-color
--ha-progress-bar-indicator-background
--ha-progress-bar-track-color
--ha-progress-bar-track-height
--ha-progress-bar-border-radius
--ha-progress-bar-animation-duration
--ha-progress-bar-indicator-highlight-image
--ha-progress-bar-indicator-highlight-width
--ha-progress-bar-indicator-highlight-height
\n

ha-switch​

\n

ha-switch was migrated to webawesome. It now has many CSS properties to make customization easier. We also removed some tokens from the old switch:

\n

Removed tokens:

\n
--switch-unchecked-button-color
--switch-unchecked-track-color
--switch-unchecked-color
--switch-checked-button-color
--switch-checked-track-color
--switch-checked-color
\n

New component specific tokens:

\n
--ha-switch-size
--ha-switch-thumb-size
--ha-switch-width
--ha-switch-background-color
--ha-switch-thumb-background-color
--ha-switch-background-color-hover
--ha-switch-thumb-background-color-hover
--ha-switch-checked-background-color
--ha-switch-checked-thumb-background-color
--ha-switch-checked-background-color-hover
--ha-switch-checked-thumb-background-color-hover
--ha-switch-border-color
--ha-switch-thumb-border-color
--ha-switch-thumb-border-color-hover
--ha-switch-checked-border-color
--ha-switch-checked-thumb-border-color
--ha-switch-checked-border-color-hover
--ha-switch-checked-thumb-border-color-hover
--ha-switch-thumb-box-shadow
--ha-switch-disabled-opacity
--ha-switch-required-marker
--ha-switch-required-marker-offset
\n

ha-checkbox​

\n

ha-checkbox was also migrated to webawesome and got new CSS properties. You can no longer use MDC tokens for it, but we added a set of tokens to customize the new checkbox.

\n

New component specific tokens:

\n
--ha-checkbox-size
--ha-checkbox-border-color
--ha-checkbox-border-color-hover
--ha-checkbox-background-color
--ha-checkbox-background-color-hover
--ha-checkbox-checked-background-color
--ha-checkbox-checked-background-color-hover
--ha-checkbox-checked-icon-color
--ha-checkbox-checked-icon-scale
--ha-checkbox-border-radius
--ha-checkbox-border-width
--ha-checkbox-required-marker
--ha-checkbox-required-marker-offset
\n

ha-textarea​

\n

ha-textarea was migrated to webawesome and got new CSS properties. You can no longer use MDC tokens for it, but we added a set of tokens to customize the new textarea.

\n

The API changed slightly. To make your textarea grow in size, set the resize prop to auto.

\n

ha-adaptive-popover​

\n

You might already know the (fairly new) ha-adaptive-dialog component. It combines a dialog and bottom sheet by showing a dialog on desktop and a bottom sheet on mobile.\nWe added ha-adaptive-popover as the popover counterpart to the adaptive dialog. It shows a popover on desktop and a bottom sheet on mobile. It is based on ha-adaptive-dialog and is currently used in the tile card date picker feature.

\n

Removed ha-fab​

\n

ha-fab was removed, we use just a normal ha-button now, since the position styling was always done from the parent component.

\n

Style updates​

\n

Box shadow tokens​

\n

We added new global box shadow tokens: --ha-box-shadow-s, --ha-box-shadow-m, --ha-box-shadow-l

\n

But we also removed the old box shadow tokens:

\n
--ha-color-shadow-light
--ha-color-shadow-dark
--ha-shadow-offset-x-...
--ha-shadow-blur-...
--ha-shadow-spread-..
\n

Surface colors​

\n

In the next release we plan to change the way we handle surface background colors. The tokens are introduced now but are just used for ha-tooltip.

\n

New tokens:

\n
--ha-color-surface-default
--ha-color-surface-low
--ha-color-surface-lower
--ha-color-surface-default-inverted
--ha-color-surface-low-inverted
--ha-color-surface-lower-inverted
", "url": "https://developers.home-assistant.io/blog/2026/05/04/frontend-component-updates-2026.5", "title": "Frontend component updates in 2026.5", "summary": "Component updates", "date_modified": "2026-05-04T00:00:00.000Z", "author": { "name": "Wendelin Peleska", "url": "https://github.com/wendevlin" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/05/04/frontend-context-groups-decorators", "content_html": "

Last release we introduced the lazy context and we wanted to use hass context and lazy context more in favor of passing the hass object.\nWe found that small tasks often required subscribing to many contexts, so we grouped Hass contexts into logical groups.

\n

Context groups​

\n

Following context groups have been added:

\n\n

Consume context entry decorators​

\n

In the last blogpost I showed how to use context with @transform. @transform is powerful, but sometimes you only need a single context entry and do not want to define a transform function.\nTo support that, we added decorators that consume a single context entry directly.\nYou pass an array that defines where the entity ID comes from (usually a config property), and the decorator consumes the correct context and maps the entity ID to the correct registry entry.\nIt also watches the defined path and updates the entry when needed.

\n

New decorators:

\n\n

sample usage:

\n
@state()
@consumeEntityRegistryEntry({ entityIdPath: [\"_config\", \"entity\"] })
_entity?: EntityRegistryDisplayEntry;
\n

We may add more of these decorators in the future, e.g. for areas, devices, etc.

\n

Deprecate contexts​

\n

These contexts are still available, but they can be removed in a future release. Use the new context groups instead.

\n", "url": "https://developers.home-assistant.io/blog/2026/05/04/frontend-context-groups-decorators", "title": "Frontend context groups, new context decorators and deprecated contexts", "summary": "Last release we introduced the lazy context and we wanted to use hass context and lazy context more in favor of passing the hass object.", "date_modified": "2026-05-04T00:00:00.000Z", "author": { "name": "Wendelin Peleska", "url": "https://github.com/wendevlin" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/04/27/pyserial-to-serialx", "content_html": "

Existing integrations and libraries communicating with serial ports should migrate from pyserial, pyserial-asyncio, and pyserial-asyncio-fast to serialx. This new library features native asyncio support on all platforms and will allow your integrations and libraries to take advantage of ESPHome serial proxies in Home Assistant, and includes critical fixes for asyncio event loop stability.

\n

Background​

\n

pyserial has been the de facto serial library in Python for many years and has broad support for all popular platforms. Its API, however, predates asyncio in Python and is sync-only. The pyserial-asyncio package was eventually released to bridge pyserial with asyncio. Unfortunately, pyserial-asyncio development never reached 1.0 stability or cross-platform support, and neither pyserial nor pyserial-asyncio have had PyPI releases in almost five years. We forked pyserial-asyncio and released pyserial-asyncio-fast to fix outstanding issues affecting Core event loop stability.

\n

We developed serialx from the ground up as a modern Python serial library with native sync and async APIs. It is import-compatible with the serial, serial_asyncio, and serial_asyncio_fast modules and allows existing packages to migrate with very minimal changes, if any.

\n

Migration​

\n

The serialx documentation has an extensive migration guide that goes into more detail.

\n

Most packages just need to replace pyserial, pyserial-asyncio, and pyserial-asyncio-fast with serialx in their setup.py or pyproject.toml file and update exception handling to replace broad catching of SerialException with more granular error handling (such as OSError and TimeoutError).

\n

Packages directly constructing a sync serial.Serial() object should migrate to using the serialx.serial_for_url() helper to ensure automatic compatibility with all supported protocols.

\n

Prompt for your agent​

\n

The migration itself is mechanical, paste the following instructions into your agent of choice:

\n
\n

Migrate my code from pyserial, pyserial-asyncio, and pyserial-asyncio-fast to serialx using\nhttps://raw.githubusercontent.com/puddly/serialx/refs/heads/dev/docs/how-to/pyserial-migration.md

\n
", "url": "https://developers.home-assistant.io/blog/2026/04/27/pyserial-to-serialx", "title": "Serious about serial: migrating from pyserial to serialx", "summary": "Existing integrations and libraries communicating with serial ports should migrate from pyserial, pyserial-asyncio, and pyserial-asyncio-fast to serialx. This new library features native asyncio support on all platforms and will allow your integrations and libraries to take advantage of ESPHome serial proxies in Home Assistant, and includes critical fixes for asyncio event loop stability.", "date_modified": "2026-04-27T00:00:00.000Z", "author": { "name": "Nikita Nikishin", "url": "https://github.com/puddly" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/04/24/radio-frequency-entity-platform", "content_html": "

Home Assistant now has a radio_frequency entity platform that decouples RF transceiver hardware from the devices it controls. Instead of each device integration talking directly to specific RF hardware, transmitter integrations (like esphome) expose RadioFrequencyTransmitterEntity instances, and device integrations send commands through them via helper functions.

\n

This mirrors the infrared entity platform and was approved in architecture discussion #1365.

\n

Architecture​

\n

The radio_frequency domain sits between two types of integrations:

\n\n

Users select which transmitter to use during the consumer integration's config flow, filtered by the frequency the device operates on.

\n

Implementing a transmitter integration​

\n

Transmitter integrations provide the radio_frequency platform by subclassing RadioFrequencyTransmitterEntity, declaring their supported_frequency_ranges, and implementing async_send_command:

\n
from rf_protocols import RadioFrequencyCommand
from homeassistant.components.radio_frequency import RadioFrequencyTransmitterEntity

class MyRadioFrequencyTransmitterEntity(RadioFrequencyTransmitterEntity):
    \"\"\"My RF transmitter.\"\"\"

    @property
    def supported_frequency_ranges(self) -> list[tuple[int, int]]:
        \"\"\"Return the list of (min_hz, max_hz) ranges this hardware can transmit on.\"\"\"
        return [(300_000_000, 348_000_000), (433_050_000, 434_790_000)]

    async def async_send_command(self, command: RadioFrequencyCommand) -> None:
        \"\"\"Send an RF command.\"\"\"
        await self._device.transmit(
            frequency=command.frequency,
            modulation=command.modulation,
            timings=command.get_raw_timings(),
        )
\n

The base class tracks the timestamp of the last sent command as the entity state, so transmitter integrations only need to handle the actual transmission.

\n

Building a consumer integration​

\n

Consumer integrations control RF devices by sending commands through a transmitter entity. They don't interact with RF hardware directly. The snippets below are adapted from the honeywell_string_lights integration, which uses the platform to drive a Honeywell String Lights set.

\n

1. Declare the dependency in manifest.json:

\n
{
  \"dependencies\": [\"radio_frequency\"]
}
\n

2. Load the device's commands from the rf-protocols library:

\n
from rf_protocols import get_codes

COMMANDS = get_codes(\"honeywell/string_lights\")
\n

Each loaded command exposes the frequency and modulation the device uses, which the config flow needs to filter transmitters.

\n

3. Let the user pick a transmitter in the config flow, using a sample command to filter by the frequency and modulation the device requires:

\n
from rf_protocols import RadioFrequencyCommand
from homeassistant.components.radio_frequency import async_get_transmitters
from homeassistant.exceptions import HomeAssistantError

sample_command: RadioFrequencyCommand = await self.hass.async_add_executor_job(
    COMMANDS.load_command, \"turn_on\"
)
try:
    transmitters = async_get_transmitters(
        self.hass, sample_command.frequency, sample_command.modulation
    )
except HomeAssistantError:
    return self.async_abort(reason=\"no_transmitters\")

if not transmitters:
    return self.async_abort(reason=\"no_compatible_transmitters\")
\n

Only ModulationType.OOK (on-off keying) is supported right now; later releases can add other modulation types.

\n

4. Send RF commands using the helper function and the stored transmitter entity ID:

\n
from homeassistant.components.radio_frequency import async_send_command

async def async_turn_on(self, **kwargs: Any) -> None:
    \"\"\"Turn on the light.\"\"\"
    command = await self.hass.async_add_executor_job(
        COMMANDS.load_command, \"turn_on\"
    )
    await async_send_command(self.hass, self._transmitter, command)
    self._attr_is_on = True
    self.async_write_ha_state()
\n

RF protocols and codes​

\n

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

\n

For full details, see the radio frequency entity documentation.

", "url": "https://developers.home-assistant.io/blog/2026/04/24/radio-frequency-entity-platform", "title": "New radio frequency entity platform for RF device integrations", "summary": "Home Assistant now has a radio_frequency entity platform that decouples RF transceiver hardware from the devices it controls. Instead of each device integration talking directly to specific RF hardware, transmitter integrations (like esphome) expose RadioFrequencyTransmitterEntity instances, and device integrations send commands through them via helper functions.", "date_modified": "2026-04-24T00:00:00.000Z", "author": { "name": "Paulus Schoutsen", "url": "https://github.com/balloob" }, "tags": [] }, { "id": "https://developers.home-assistant.io/blog/2026/04/21/registering-custom-dashboard-strategies", "content_html": "

As of Home Assistant 2026.5, you can now register custom dashboard strategies, just as you can with custom cards, making them easier to discover and add using the new dashboard dialog under the Community dashboards section.

\n

Previously, you had to send users to create a blank dashboard, edit in YAML mode, and paste in your custom strategy. Now you can register a friendly name, description, and documentation.

\n

To register your strategy, call window.customStrategies.push() with an object containing the following keys:

\n\n

Example:

\n
window.customStrategies = window.customStrategies || [];
window.customStrategies.push({
  type: \"my-demo\",
  strategyType: \"dashboard\",
  name: \"My demo dashboard\",
  description: \"A starter dashboard generated from JavaScript.\",
  documentationURL: \"https://example.com/my-demo-dashboard\",
});
\n

This metadata is separate from the custom element itself. Your strategy still needs to be registered with a tag like ll-strategy-dashboard-my-demo, and users still need the resource loaded before Home Assistant can discover it. You can use HACS for this as other resources can be added, like custom cards.

\n

Take a look at the updated custom strategies documentation with example code and further details.

", "url": "https://developers.home-assistant.io/blog/2026/04/21/registering-custom-dashboard-strategies", "title": "Registering custom dashboard strategies", "summary": "As of Home Assistant 2026.5, you can now register custom dashboard strategies, just as you can with custom cards, making them easier to discover and add using the new dashboard dialog under the Community dashboards section.", "date_modified": "2026-04-21T00:00:00.000Z", "author": { "name": "Aidan Timson", "url": "https://github.com/timmo001" }, "tags": [] } ] }