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
            )

As of Home Assistant Core 2024.8, we have added two new flags to FanEntityFeature: TURN_ON, TURN_OFF.

Integrations implementing the turn_on service call need to set the TURN_ON feature flag. Integrations implementing the turn_off service call need to set the TURN_OFF feature flag.

There will be a 6-month deprecation period (2025.2) during which FanEntity will set these on behalf of the integrations implementing the respective methods. From 2025.2, integrations will be unable to use the respective methods if entity features have not been set accordingly.

Implementing the methods without setting the respective feature flag, will create a warning log entry guiding the user to create an issue for the integration.

Integrations should set the attribute _enable_turn_on_off_backwards_compatibility in your FanEntity subclass instance to False once it has been migrated into using or not using the new feature flags. This will stop the automatic setting of the new feature flags during the deprecation period, and should be removed once deprecation has ended.

Starting from 2024.8, you can now add a model identifier to the DeviceInfo class. This identifier can be used to identify the device model in integrations and the frontend.

For example, the Philips Hue ambiance spot was previously listed as "Hue ambiance spot (LTG002)". This can now be split up, where the model is "Hue ambiance spot" and the model_id is "LTG002".

The term "Services" has been a source of confusion for many users, as it is not immediately clear what it refers to; it could be a web or STT service, but in the context of Home Assistant, it means something entirely different (service calls).

In Home Assistant 2024.8, "Services" (as in service calls) will be renamed to "Actions". This change is part of our ongoing effort to make Home Assistant more user-friendly and easier for new users to understand. The term fits in with the UI changes we have been implementing over the past months (call services no longer exist in our automations and script editors). Effectively, one is performing actions in one's automations.

This change will be reflected in the Home Assistant UI, documentation, and other places where the term "Services" is used. For example, the "Services" tab in the Developer Tools will be renamed to "Actions".

For developers, there is no need to worry about this change. In the developer documentation, we will update all references to "services" to "service actions", as we have different types of actions in our backend (for example, device actions). The underlying functionality will remain the same, and the transition is seamless.

This is, just like the end-user change, a terminology change only.

The ClimateEntity has an hvac_action property, which describes what the climate entity is currently doing (which is not the same as its mode).

We have added DEFROSTING as a possible HVACAction to represent when an entity is currently defrosting.

Defrosting is when the system runs in reverse for some time to melt down accumulated ice. It occurs typically in colder environments and should not be mixed with, for example, cars that are defrosting by heating their windows.

from homeassistant.components.climate.const import HVACAction

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

    def hvac_action(self) -> HVACAction | None:
        """Return the current running hvac operation if supported."""
        return HVACAction.DEFROSTING

More details can be found in the climate entity documentation

Background for the original change is in architecture discussion #1090.

The way how state attributes are excluded from the recording was previously changed in September 2023.

The previous implementation was limited as there was no way to handle dynamic attributes or any easy way to simply exclude all attributes instead of listing them individually.

It is now possible within an integration to tell recording to not record any attribute by using the MATCH_ALL constant, which will automatically remove all attributes from recording except device_class, state_class, unit_of_measurement, and friendly_name.

from homeassistant.const import MATCH_ALL

class ExampleEntity(Entity):
    """Implementation of an entity."""

    _unrecorded_attributes = frozenset({MATCH_ALL})

More details can be found in the entity documentation.

Background for the original change is in architecture discussion #964.