As of Home Assistant Core 2024.10, the constants used to return state in Camera are deprecated and replaced by the CameraState enum.

There is a one-year deprecation period, and the constants will stop working from 2025.10 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.

As of Home Assistant Core 2024.10, the constants used to return state in LockEntity are deprecated and replaced by the LockState enum.

There is a one-year deprecation period, and the constants will stop working from 2025.10 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.

On February 27, 2024, we announced the deprecation of the @bind_hass decorator and the hass.components attribute for the Home Assistant 2024.9 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.3, the @bind_hass decorator and hass.components will be removed.

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

Starting from Home Assistant 2024.10 calories have been added to the units of measurement in the energy sensor class. Typically, these sensors measure heat energy, water heating, food energy, or human energy expenditure.

With the merge of core PR #89242, which landed in Home Assistant Core 2023.4, Template.hass will be set on Template objects created during schema validation.

Before this change, it was necessary to check and set Template.hass before rendering templates, and this happened in numerous places throughout the codebase. Such code has been removed from Home Assistant Core, which impacts custom integration authors:

• Custom integrations which create Template objects manually must pass a valid hass object to the constructor. This is in particular the case when creating templates for config entries. Not passing a hass object will trigger a deprecation warning and fail in Home Assistant Core 2025.10.
• The helper function template.attach no longer serves a purpose and is no longer used by core. It has been marked as deprecated, and scheduled for removal in Home Assistant Core 2025.10.

The icon translations schema has been adjusted to allow assigning icons for sections in services. Icons for services should now be provided according to a more explicit schema, which allows specifying icons for sections.

This allows specifying service icons like this:

  "services": {
    "test_service_1": {
      "service": "mdi:flask",
      "sections": {
        "section_1": "mdi:test-tube"
      }
    }
  }

The old format is supported during a deprecation period of one year, to give time for custom integrations to migrate to the new schema:

  "services": {
    "test_service_1": "mdi:flask"
  }

See core PR #124656 for implementation details.

Impact on custom cards​

Icons data sent to the frontend will always be according to the new format, custom cards displaying service icons need to be adjusted.

Registering entity service actions allows integration authors to pass in:

• No schema (None)
• A dictionary, which will be converted to a voluptuous schema by passing it to cv.make_entity_service_schema
• A custom voluptuous schema

For the third case, a warning will now be logged when registering an entity action with a custom schema which does not meet at least one of these criteria:

• A validator returned by cv.make_entity_service_schema
• A validator returned by cv.make_entity_service_schema, wrapped in a vol.Schema
• A validator returned by cv.make_entity_service_schema, wrapped in a vol.All

In Home Assistant Core 2025.10, it will no longer be possible to register an entity action with a custom schema not meeting this requirement.

The reason for the change is that if cv.make_entity_service_schema is not used, the service will not automatically support all possible ways of targeting entities.

More details can be found in the developer documentation and in core PRs #124102 and #125057.

As of Home Assistant Core 2024.9, integrations implementing LawnMowerEntity can indicate that their mower is returning to the dock by using the new LawnMowerActivity.RETURNING state.

More details can be found in the documentation

Example​

    async def async_dock(self) -> None:
        """Start docking."""
        self._attr_activity = LawnMowerActivity.RETURNING
        self.async_write_ha_state()

or by returning LawnMowerActivity.RETURNING in the activity property of your lawn_mower entity.

    @property
    def activity(self) -> LawnMowerActivity:
        """Return the state of the mower."""
        mower = self.mower
        if mower.state is RETURNING:
            return LawnMowerActivity.RETURNING
        ...

In Home Assistant 2024.8, we are introducing the _async_setup method for the data update coordinator. This method allows you to run asynchronous code to prepare your DataUpdateCoordinator instance or to load data that only needs to be loaded once.

You can override _async_setup in your coordinator, and it will be automatically called during coordinator.async_config_entry_first_refresh(). It offers the same error handling as _async_update_data and will handle ConfigEntryError and ConfigEntryAuthFailed accordingly.

Example​

class MyUpdateCoordinator(DataUpdateCoordinator[MyDataType]):

    prereq_data: SomeData

    def __init__(
        self,
        hass: HomeAssistant,
    ) -> None:
        """Initialize coordinator."""
        super().__init__(hass, _LOGGER, name=DOMAIN, update_interval=SCAN_INTERVAL)
        self.my_api = MyApi()


    async def _async_setup(self) -> None:
        """Do initialization logic."""
        self.prereq_data = await self.my_api.get_initial_data()

    async def _async_update_data(self) -> MyDataType:
        """Do the usual update"""
        return await self.my_api.update(self.prereq_data)

Avoiding checks for initialization status​

This change allows you to refactor code that loaded the initial data in the _async_update_data method by checking an initialization variable, like

async def _async_update_data(self) -> ...:
    if not self.something:
        self.something = self.client.fetch()
    return self.client.fetch_data()

into

async def _async_setup(self) -> None:
    self.something = self.client.fetch()

async def _async_update_data(self) -> ...:
    return self.client.fetch_data()

More information​

Read more about this in the documentation

As of Home Assistant Core 2024.8, we have implemented validation for the temperature action call provided by the ClimateEntity.

Integrations no longer need to check this within their own set temperature methods (async_set_temperature/set_temperature).

However, it's important that integrations specify the min_temp and max_temp properties correctly, or the user might not be able to set their correct temperature if validation fails. Likewise, integrations that handle devices which can operate on both Celsius and Fahrenheit need to convert their respective min_temp and max_temp values accordingly.

Example​

Converts a device's native min/max value into the temperature_unit specified by the integration.

class MyClimateEntity(ClimateEntity):
    """Implementation of my climate entity."""

    @property
    def min_temp(self) -> float:
        """Return the minimum temperature."""
        return TemperatureConverter.convert(
                self.device.min_temp, UnitOfTemperature.CELSIUS, self.temperature_unit
            )

    @property
    def max_temp(self) -> float:
        """Return the maximum temperature."""
        return TemperatureConverter.convert(
                self.device.max_temp, UnitOfTemperature.CELSIUS, self.temperature_unit
            )