Before 2022.8, it was impossible to await config entry platforms forwards without a deadlock if one of the platforms loaded by the config entry was not already loaded.

Integrations need to be refactored to replace calls to hass.config_entries.async_setup_platforms with awaiting hass.config_entries.async_forward_entry_setups to ensure that Home Assistant does not inadvertently reload the integration while entities and platforms are still being set up.

hass.config_entries.async_setup_platforms is scheduled to be removed in 2022.12.

As of Home Assistant Core 2022.8, a Store (from homeassistant/helpers/storage.py) is defined as a Generic Store(Generic[_T]). It is recommended that the type of data being stored be defined in the Store definition. It should be JSON-serialisable (dict or list), for example:

• Standard definition using a dict: self._store = Store[dict[str, int]](hass, STORAGE_VERSION, STORAGE_KEY)
• Using a TypedDict: self._store = Store[EnergyPreferences](hass, STORAGE_VERSION, STORAGE_KEY)
• Accessing an existing Store: store: Store[dict[str, Any]] = hass.data[DOMAIN][DATA_STORE]
• Inherited Store: class MyCustomStorage(Store[list[int]]):

For more information about generics, see PEP 483

WeatherEntity now supports temperature unit conversion following a similar pattern as the unit conversion supported by NumberEntity and SensorEntity.

Precipitation, pressure, temperature, visibility and wind speed are automatically converted according to the unit system configured by the users. In addition, users can override units for specific weather entities.

To make this possible, custom component integrations should be updated to override properties native_precipitation_unit, native_pressure, native_pressure_unit, native_temperature, native_temperature_unit,native_visibility, native_visibility_unit, native_wind_speed and native_wind_speed_unit, instead of precipitation_unit, pressure, pressure_unit, temperature, temperature_unit,visibility, visibility_unit, wind_speed and wind_speed_unit.

The same renaming has been done for the corresponding _attr_* attributes as well as for members of the Forecast typed dict

In Home Assistant Core 2023.1, overriding precipitation_unit, pressure, pressure_unit, temperature, temperature_unit,visibility, visibility_unit, wind_speed, wind_speed_unit, setting _attr_precipitation_unit, _attr_pressure, _attr_pressure_unit, _attr_temperature, _attr_temperature_unit, _attr_visibility, _attr_visibility_unit, _attr_wind_speed, _attr_wind_speed_unit and setting precipitation, pressure, temperature, templow, wind_speed on instances of Forecast is no longer supported.

NumberEntity now supports temperature unit conversion following a similar pattern as the unit conversion supported by SensorEntity.

Temperature conversion will automatically be done for number entities with device class set to temperature to the temperature unit configured by the user.

To make this possible, custom component integrations should be updated to override properties native_max_value, native_min_value, native_step, native_unit_of_measurement, native_value instead of max_value, min_value, step, unit_of_measurement, value and to override methods async_set_native_value and set_native_value instead of async_set_value and set_value.

The same renaming has been done for _attr_* attributes as well as members of NumberEntityDescription.

In Home Assistant Core 2023.1, overriding async_set_value, max_value, min_value, set_value, step, unit_of_measurement, value, setting _attr_max_value, _attr_min_value, _attr_unit_of_measurement, _attr_step, _attr_value and setting max_value, min_value, unit_of_measurement, step on instances of NumberEntityDescription is no longer supported.

Before 2022.7, it was possible to trigger a reload of a config entry while it was still setting up. Reloading during config entry setup often led to unexpected failure modes, which required restarting Home Assistant to get the config entry back in a good state. Attempting a reload during setup now raises the OperationNotAllowed exception.

As of Home Assistant Core 2022.7, all RESULT_TYPE_* constants for data entry flow result types are deprecated:

• RESULT_TYPE_FORM
• RESULT_TYPE_CREATE_ENTRY
• RESULT_TYPE_ABORT
• RESULT_TYPE_EXTERNAL_STEP
• RESULT_TYPE_EXTERNAL_STEP_DONE
• RESULT_TYPE_SHOW_PROGRESS
• RESULT_TYPE_SHOW_PROGRESS_DONE
• RESULT_TYPE_MENU

Use the new FlowResultType enum instead.

Starting with Home Assistant 2022.7, the update coordinator supports keeping track of context for each listening entity. This can be used to limit the requests against APIs based on enabled entities.

This could be a breaking change for custom components that rely on update coordinators and inspect the internal variable self._listeners and/or overload the method async_remove_listener() to detect when there is no listeners anymore. Switch to using async_update_listeners() to trigger updates on all listeners, and overload _unschedule_refresh() to detect when there is no listeners.

See the updated integration fetching documentation for more information on current use.

Starting with Home Assistant 2022.6, the media player integration has received two updates to the media_player.play_media service. The enqueue attribute has been changed to a string in PR #72406 and a new announce boolean attribute was added in PR #72566.

See the updated media player play_media documentation for more information.

Before 2022.6, the entity_matches_only flag prevented the logbook from providing context data in exchange for performance improvement when querying specific entities. Selecting the context data for particular entities is no longer an intensive process with the new logbook design. No immediate action is required as the flag will be ignored, and removing the flag from any active code paths can be done at your leisure.

We started to update our base images to use the new s6-Overlay v3. A migration article also explains the new possibilities around this change. This blog post explains the minimal changes needed to be able to use our new base images.

We have updated our example add-on to include the new behaviors.

Minimum​

Add init: false to your addon's config.yaml if you don't have this already. In V3, S6 enforces that their init is used correctly. If Docker default system init is used you will see the following error when you start your addon:

s6-overlay-suexec: fatal: can only run as pid 1

Make sure all your executable/script files have the execution permission set on your git repository rootfs folder. You can update the permissions using:

$ git update-index --chmod=+x rootfs/etc/service.d/my-service/run

If you use finish scripts in your S6-overlay services, for example, to stop the container on an error, you have to replace the line s6-svscanctl -t /var/run/s6/services with /run/s6/basedir/bin/halt.

AppArmor​

You have to tweak your AppArmor profile to get it working with the new s6-Overlay. We updated our documentation with the default profile. The following changes need to be made:

# S6-Overlay
  /init ix,
  /bin/** ix,
  /usr/bin/** ix,
  /run/{s6,s6-rc*,service}/** ix,
  /package/** ix,
  /command/** ix,
  /etc/services.d/** rwix,
  /etc/cont-init.d/** rwix,
  /etc/cont-finish.d/** rwix,
  /run/{,**} rwk,
  /dev/tty rw,

host_pid option​

Addons running without protection mode enabled can set host_pid: true in their configuration. As described in the documentation:

Allow to run container on host PID namespace. Works only for not protected add-ons.

This is a problem because S6 expects to be PID 1 (it's literally in the tagline) and that's impossible when using the host PID namespace.

In V2, S6 didn't actually check that it was running as PID 1. This is why it "worked" when in this mode in the past (although it required some workarounds to keep s6 from breaking systems when running this way). In V3 S6 checks that it is actually PID 1 and refuses to start otherwise.

To fix this, don't use s6 overlay in your addon as it's not designed for this use case. You can continue to use the addon base images by overriding /init with a no-op script and then use the normal docker init system. Or you can switch to a different base image like stock alpine or debian and add what you need.