Skip to main content

Additional validation in Climate set temperature

· One min read

As of Home Assistant Core 2024.10, we have added further validation of the parameters passed to the set_temperature method. This means that integrations don't need to implement this validation in their own methods.

Before 2024.10 it was possible to set the temperature parameter in the action when the entity did not set ClimateEntityFeature.TARGET_TEMPERATURE or target_temp_low/target_temp_high parameters when the entity did not set ClimateEntityFeature.TARGET_TEMPERATURE_RANGE. This will no longer be possible and a ServiceValidationError will be raised informing the user that they used an incorrect parameter in the action call.

Also, when setting a temperature range, it was possible to set target_temp_low to a higher value than target_temp_high. This will raise a ServiceValidationError informing the user the high value needs to be higher than the low value.

Enforce SourceType and add shorthand attributes and EntityDescription to device_tracker

· One min read

The source_type property of device_tracker entities is now always expected to be a SourceType enum value. Standard strings are no longer valid.

TrackerEntity and ScannerEntity now have a dedicated ScannerEntityDescription and TrackerEntityDescription, which need to be used as base class when associating an EntityDescription to the Entity.

The source_type for these entities now also defaults to SourceType.GPS and SourceType.ROUTER, and it may be possible to drop the overriding property.

The following shorthand attributes have also been added:

  • BaseTrackerEntity._attr_source_type
  • TrackerEntity._attr_latitude
  • TrackerEntity._attr_location_accuracy
  • TrackerEntity._attr_location_name
  • TrackerEntity._attr_longitude
  • TrackerEntity._attr_source_type (defaults to SourceType.GPS)
  • ScannerEntity._attr_hostname
  • ScannerEntity._attr_ip_address
  • ScannerEntity._attr_mac_address
  • ScannerEntity._attr_source_type (defaults to SourceType.ROUTER)

More details can be found in the device-tracker documentation.

Deprecating constants for Media Player

· One min read

As of Home Assistant Core 2022.5, the feature flag constants used in MediaPlayerEntity were deprecated and replaced by the MediaPlayerEntityFeature enum. Later, in 2022.10, the repeat mode, media type, and media class constants were deprecated and replaced by RepeatMode, MediaType, and MediaClass, respectively.

However, no proper deprecation was done, so now in 2024.10 we start the one-year deprecation period, and the constants will stop working from 2025.10, to ensure all custom integration authors have time to adjust.

Deprecating feature flag constants for Vacuum

· One min read

As of Home Assistant Core 2022.5, the feature flag constants used in StateVacuumEntity were deprecated and replaced by the VacuumEntityFeature enum.

However, there was no proper deprecation done and therefore now in 2024.10 we start the one-year deprecation period. The constants will stop working from 2025.10, to ensure all custom integration authors have time to adjust.

Deprecating state constants for camera

· One min read

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.

Deprecating state constants for lock

· One min read

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.

Extend deprecation period of @bind_hass and hass.components

· One min read

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.

Template.hass is no longer automatically set when rendering templates

· One min read

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.

Changes to the icon translations schema

· One min read

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.