Skip to main content

Reauth and reconfigure flows need to be linked to a config entry

· One min read

Starting a reauth or a reconfigure flow without a link to the config entry has been deprecated, and will start failing in 2025.12.

Custom integrations should be updated to trigger the reauth flow using the entry.async_start_reauth(hass) helper.

    async def async_press(self) -> None:
"""Handle the button press."""
try:
await self.device.press_button()
except DevicePasswordProtected as ex:
self.entry.async_start_reauth(self.hass)

Old incorrect code:

    async def async_press(self) -> None:
"""Handle the button press."""
try:
await self.device.press_button()
except DevicePasswordProtected as ex:
# old incorrect code:
self.hass.async_create_task(
hass.config_entries.flow.async_init(DOMAIN, context={"source": SOURCE_REAUTH}
)
)

Custom integrations can also raise a ConfigEntryAuthFailed exception during the initialization phase, or within the update method of a data update coordinator.

async def async_setup_entry(hass: HomeAssistant, entry: ConfigEntry) -> bool:
"""Set up integration from a config entry."""
username = entry.data[CONF_USERNAME]
password = entry.data[CONF_PASSWORD]

if not _credentials_valid(username, password):
raise ConfigEntryAuthFailed()

Starting a reconfigure flow is only done by the frontend and custom integrations should not need to change anything for these flows.

More details can be found in the reconfigure and reauthentication documentation.

The core config class has been moved

· One min read

Summary of changes

The definition of the core config class, an instance of which is available as hass.config has been moved from homeassistant/core.py to homeassistant/core_config.py. The move was done to make it easier to read and understand the core code. Custom integrations which currently import Config from homeassistant.core need to be updated to instead import from homeassistant.core_config.

info

Normally, integrations won't need to use the core Config class. But there's been custom integrations that have incorrect type annotations where the config object passed to the integration's async_setup is specified as a Config instance:

from homeassistant.core import Config

async def async_setup(hass: HomeAssistant, config: Config) -> bool:
"""Set up the integration."""

A correct type annotation would be like this:

from homeassistant.helpers.typing import ConfigType

async def async_setup(hass: HomeAssistant, config: ConfigType) -> bool:
"""Set up the integration."""

Backwards compatibility

Until Home Assistant Core 2025.11, it's possible to import from homeassistant.core, and doing so will log a warning asking users to open an issue on the custom integration's bug tracker.

Changes to the update entity

· One min read

Summary of changes

The update entity has been adjusted:

  • The in_progress property and the corresponding state attribute should now only be a bool indicating if an update is in progress, or None if unknown.
  • A new property and a corresponding state attribute update_percentage has been added which can either return an int or float indicating the progress from 0 to 100% or None.
  • A new property and a corresponding state attribute display_precision has been added to control the number of decimals to display in the frontend when update_percentage is a float.

Backwards compatibility

Until Home Assistant Core 2025.12, a numerical value in the in_progress property will be automatically copied to the update_percentage state attribute.

Documentation and core implementation

See the update entity developer documentation for details.

PRs:

New alarm control panel state property and state enum

· One min read

As of Home Assistant Core 2024.11, we have introduced the alarm_state property in the AlarmControlPanelEntity. This newly added property should be used instead of directly setting the state property.

The new alarm_state property should return its state using the new AlarmControlPanelState enum instead of as previously, setting the state using the STATE_ALARM_* constants.

There is a one-year deprecation period, and the constants will stop working from 2025.11 to ensure all custom integration authors have time to adjust.

Example


from homeassistant.components.alarm_control_panel import AlarmControlPanelEntity, AlarmControlPanelState

class MyAlarm(AlarmControlPanelEntity):
"""My alarm."""

@property
def alarm_state(self) -> AlarmControlPanelState | None:
"""Return the state of the alarm."""
if self.device.is_on():
return AlarmControlPanelState.ARMED_AWAY
return AlarmControlPanelState.DISARMED

More details can be found in the alarm control panel documentation.

New helpers and best practises for reauth and reconfigure flows

· 2 min read

New helper methods have been added to the ConfigFlow to facilitate management of reauth and reconfigure flows:

  • self._get_reauth_entry() and self._get_reconfigure_entry() give access at any time to the corresponding config entry
    • these should be used over self.hass.config_entries.async_get_entry(self.context["entry_id"])
    • the config entry should be requested when needed (local variable, once per step) and not cached as class attributes
    • if the steps are shared with discovery or user flows, self.source should be checked against SOURCE_REAUTH and SOURCE_RECONFIGURE before accessing the entry
  • self._abort_if_unique_id_mismatch allows you to abort if the unique_id does not match the unique_id of the config entry to reauthenticate or reconfigure
    • this should be used after a call to self.async_set_unique_id
    • if the steps are shared with discovery or user flows, self.source should be checked against SOURCE_REAUTH and SOURCE_RECONFIGURE
    • other sources should continue to use self._abort_if_unique_id_configured
  • self.async_update_reload_and_abort has been adjusted to update the default message for reconfigure flows
    • the new message reconfigure_successful must be present in strings.json
  • self.async_update_reload_and_abort has a new argument data_updates to merge the data updates with the pre-existing data
    • this is preferred over the data argument, as it reduces the risk of data loss if the schema is updated

More details can be found in the reconfigure and reauthentication documentation.

Extend deprecation period of hass.helpers

· One min read

On March 30, 2024, we announced the deprecation of the hass.helpers attribute for the Home Assistant 2024.11 release. Due to the large number of custom integrations that still use them and the recent HACS v2 update, we have decided to extend the deprecation period for another six months.

This means that starting with Home Assistant 2025.5, hass.helpers will be removed.

We encourage all developers of custom integrations to update their code to avoid any issues prior to the Home Assistant 2025.5 release.

Deprecating state constants for cover

· One min read

As of Home Assistant Core 2024.11, the constants used to return state in CoverEntity are deprecated and replaced by the CoverState enum.

There is a one-year deprecation period, and the constants will stop working from 2025.11 to ensure all custom integration authors have time to adjust.

As the state property is not meant to be overwritten, in most cases this change will only affect other Entity properties or tests rather than the state property.

More details can be found in the cover documentation.

Changes to the UnitOfConductivity enum

· One min read

The UnitOfConductivity enum has been changed from:

  class UnitOfConductivity(StrEnum):
"""Conductivity units."""

SIEMENS = "S/cm"
MICROSIEMENS = "µS/cm"
MILLISIEMENS = "mS/cm"

To:

  class UnitOfConductivity(StrEnum):
"""Conductivity units."""

SIEMENS_PER_CM = "S/cm"
MICROSIEMENS_PER_CM = "µS/cm"
MILLISIEMENS_PER_CM = "mS/cm"

The old enum members can be used during a deprecation period of one year, to give time for custom integrations to migrate to the new enum members.

See core PR #127919 for implementation details.

Introducing the Assist satellite entity

· One min read

Users typically interact with Assist using remote voice satellites, such as the ESP32-S3-BOX-3 running ESPHome, analog phones running VoIP, and more. The integrations managing these satellites have used ad-hoc binary_sensor and select entities to allow users to configure the satellite's pipeline, automate based on the pipeline state, etc.

The new AssistSatelliteEntity provides an entity which represents a voice satellite. Its state follows the underlying Assist pipeline, allowing for easy automation. Additionally:

  • A new announce action is available for making announcements on supported devices.
  • Several websocket commands are also available, providing a uniform way to get and set the active on-device wake words.

The esphome and voip integrations have been transitioned to use AssistSatelliteEntity, and the wyoming integration will be next.

Version compare for Update platform can now be overwritten

· One min read

With the merge of core PR #124797, which will land in Home Assistant Core 2024.10, there is a new method in the update platform: version_is_newer().

Before this change, the compare logic between firmware installed version, new available version and beta version was hardcoded:

def version_is_newer(self, latest_version: str, installed_version: str) -> bool:
"""Return True if latest_version is newer than installed_version."""
return AwesomeVersion(latest_version) > installed_version

Now the new method allows developers to customize this comparison, writing their own method. Here's an example (implemented for Shelly gen1 devices):

def version_is_newer(self, latest_version: str, installed_version: str) -> bool:
"""Return True if available version is newer then installed version."""
return AwesomeVersion(
latest_version,
find_first_match=True,
ensure_strategy=[AwesomeVersionStrategy.SEMVER],
) > AwesomeVersion(
installed_version,
find_first_match=True,
ensure_strategy=[AwesomeVersionStrategy.SEMVER],
)