Skip to main content

· One min read

It's now possible to provide translations for device names, including support for static values to be used as placeholders.

An example sensor with a translated device name:

class TestEntity(SensorEntity):
"""Example entity."""

_attr_has_entity_name = True

def __init__(self) -> None:
"""Initialize example entity."""
self._attr_device_info = DeviceInfo(
translation_key="n_ch_power_strip",
translation_placeholders={"number_of_sockets": "2"},
)

The strings.json file would look like:

{
"device": {
"n_ch_power_strip": {
"name": "Power strip with {number_of_sockets} sockets"
}
}
}

The resulting device would be called Power strip with 2 sockets.

A warning is logged when a translation placeholder is expected but not provided by the device. When this happens on a system that is not on a stable version (dev, nightly, or beta), an error will be raised to be able to catch the mistakes quickly.

Please don't forget to be kind towards your translators, as they need to understand what kind of name or value will be passed in from the placeholder name ❤️.

· 2 min read

As of Home Assistant 2024.3, we deprecate the use of the @bind_hass decorator and thus also the use of hass.components. Using hass.components will issue a warning in the logs. Authors of custom integrations are encouraged to update their code to prevent any issues before Home Assistant 2024.9.

Starting from Home Assistant 2024.9, the @bind_hass decorator and hass.components will be removed and will no longer work.

Use of @bind_hass decorator

Integrations that use the @bind_hass decorator should be updated to remove them and pass the hass object as first parameter to the function instead:

New example

from homeassistant.core import HomeAssistant
from homeassistant.components.persistent_notification import async_create

def create_notification(hass: HomeAssistant, message: str):
"""Create a notification."""
async_create(
hass,
message,
title='Important notification'
)

async def async_setup(hass: HomeAssistant, config):
"""Set up the component."""
create_notification(hass, "You're already using the latest version!")

Old example

from homeassistant.core import HomeAssistant
from homeassistant.loader import bind_hass
from homeassistant.components.persistent_notification import async_create

@bind_hass
def create_notification(hass: HomeAssistant, message: str):
"""Create a notification."""
async_create(
hass,
message,
title='Important notification'
)

async def async_setup(hass: HomeAssistant, config):
"""Set up the component."""
create_notification("You're already using the latest version!")

Use of hass.components

Integrations that use hass.components should be updated to import the functions and classes directly from the integration package and pass the hass object as first parameter. Remember to include the imported components under dependencies in your manifest.json.

New example

from homeassistant.core import HomeAssistant
from homeassistant.components.persistent_notification import async_create

async def async_setup(hass: HomeAssistant, config):
"""Set up the component."""
async_create(
hass,
"You're already using the latest version!",
title='Important notification'
)

Old example

from homeassistant.core import HomeAssistant

async def async_setup(hass: HomeAssistant, config):
"""Set up the component."""
hass.components.persistent_notification.async_create(
"You're already using the latest version!",
title='Important notification'
)

· One min read

In Home Assistant 2024.3, we introduced a new single_config_entry option for the integration manifest file. This option allows you to set that your integration supports only one config entry.

Home Assistant will take care and prevent the initialization of a config flow if there is already a config entry for the integration. This way you won't have to implement any check in the config flow.

Integrations that have this option not set in their manifest and do the check in the config flow should replace it with the new option.

· One min read

As of Home Assistant Core 2024.3 we have added a new toggle method to ClimateEntity and users can now call climate.toggle in their service calls.

Integrations that support turn_on and turn_off implicitly also support the toggle method.

Read more about the toggle method in our documentation

Example (default implementation):

async def async_toggle(self) -> None:
"""Toggle the entity."""
if self.hvac_mode == HVACMode.OFF:
await self.async_turn_on()
else:
await self.async_turn_off()

· One min read

Starting from Home Assistant 2024.3, modifications to a ConfigEntry should use hass.config_entries.async_update_entry. Directly setting attributes on the ConfigEntry object is deprecated and will start to fail in version 2024.9 and later. There is no deprecation period for directly setting unique_id on the ConfigEntry as doing so will corrupt the internal state, and doing so will start to fail immediately.

The following attributes must now be set via hass.config_entries.async_update_entry:

  • data
  • minor_version
  • options
  • pref_disable_new_entities
  • pref_disable_polling
  • title
  • unique_id
  • version

Tests must ensure that MockConfigEntry objects are added to Home Assistant via entry.add_to_hass(hass) before calling hass.config_entries.async_update_entry.

· One min read

Change

Light entities are now required to set the supported_color_modes and color_mode properties, and a warning will be logged asking users to report an issue if that's not done.

In addition, a warning will be logged if the light reports an invalid combination of supported_color_modes or a color_mode other than ColorMode.UNKNOWN, which is not included in the light's supported_color_modes.

In the Home Assistant 2025.3 release, the warnings will be removed, and lights that have still not been upgraded to a color mode or that violate the color mode rules will no longer work.

More details can be found in the documentation.

· One min read

In Home Assistant 2024.2, integrations have a new way to provide icons. To support this new feature, ha-state-icon component properties have changed.

Read more about icon translations in our documentation.

If you are a custom card developer using this component, you must adjust the properties passed to the component to avoid displaying the wrong icons in your custom card.

Before 2024.2

<ha-state-icon .state=${stateObj}></ha-state-icon>

After 2024.2

<ha-state-icon .hass=${hass} .stateObj=${stateObj}></ha-state-icon>

Backward compatibility

If you want to support both old and new version on Home Assistant, you can pass all the properties.

<ha-state-icon
.hass=${hass}
.stateObj=${stateObj}
.state=${stateObj}
></ha-state-icon>

· One min read

As of Home Assistant Core 2024.2 we have added two new flags into ClimateEntityFeature: TURN_ON, TURN_OFF.

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

There will be a 10 month deprecation period (2025.1) where ClimateEntity will set these on behalf of the integrations implementing the respective methods and from 2025.1 it will make integrations unable to use the respective methods if entity features has 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 ClimateEntity 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 can be removed once deprecation has ended.

· 2 min read

Background

The primary reason for introducing light color modes was that a light's state should not be ambiguous. As an example, a light which supports color and white with adjustable color temperature must be in either color mode hs (for example) or color_temp.

However, effects complicate this because when the same light is rendering an effect, none of the hs_color, color_temp, or brightness state attributes may be meaningful.

Changes

Requirements on color_mode are less strict when a light is rendering an effect

More restrictive color modes than what's otherwise supported by the light are allowed when an effect is active:

  • A light which supports colors is allowed to indicate color modes on_off and brightness when controlled by an effect
  • A light which supports brightness is allowed to indicate color mode on_off when controlled by an effect.

For example, a light which has its supported_color_modes set to {"hs", "color_temp"} is allowed to set its color_mode to on_off when rendering an effect which can't be adjusted and to brightness when rendering an effect which allows brightness to be controlled.

A special effect EFFECT_OFF which means no effect / turn off effect has been added

There was previously no standard way for a light which supports effects to show that no effect is active. This has been solved by adding an the pre-defined effect EFFECT_OFF to indicate no effect is active.

More details can be found in the documentation and in architecture discussion #960.

· One min read

In Home Assistant 2024.2, we will introduce hass.services.async_services_for_domain(), which is a new way to enumerate services by domain, allowing integrations to inspect which services are available without having to obtain all the services on the system. We found that most integrations are only interested in the services they provide, and it was expensive to enumerate all the services in the system when an integration was only interested in their services.

Integrations that call hass.services.async_services()[DOMAIN] to get services for a specific domain should replace the call with hass.services.async_services_for_domain(DOMAIN).