Several new sensor device classes have been added:

• distance, a distance measured in either of cm, ft, in, km, m, mi, mm, yd
• speed, a speed measured in either of ft/s, in/d, in/h, km/h, kn, m/s, mm/d, mph
• volume, a volume measured in either of fl. oz., ft³, gal, L, mL, m³
• weight, a mass measured in either of g, kg, lb, mg, oz, µg

Like pressure and temperatures sensors, users can freely choose the display unit from the UI for sensors using any of the new device classes.

Long term statistics​

Long term statistics will store distance as m, speed as m/s, volume as m³ and weight as g. For existing sensors which are modified to one of the new device classes, statistics will continue to be recorded in the sensor's state_unit but users will be given the option to have existing statistics converted to the normalized unit.

For Home Assistant Core 2022.10 we have changed the async_track_unavailable bluetooth API to send the last BluetoothServiceInfoBleak to the callback instead of the address.

Below is a new example of the usage:

from homeassistant.components import bluetooth

def _unavailable_callback(info: bluetooth.BluetoothServiceInfoBleak) -> None:
    _LOGGER.debug("%s is no longer seen", info.address)
   
cancel = bluetooth.async_track_unavailable(hass, _unavailable_callback, "44:44:33:11:23:42", connectable=True)

As of Home Assistant Core 2022.10, the following media player constants are deprecated:

• MEDIA_CLASS_ALBUM

• MEDIA_CLASS_APP

• MEDIA_CLASS_ARTIST

• MEDIA_CLASS_CHANNEL

• MEDIA_CLASS_COMPOSER

• MEDIA_CLASS_CONTRIBUTING_ARTIST

• MEDIA_CLASS_DIRECTORY

• MEDIA_CLASS_EPISODE

• MEDIA_CLASS_GAME

• MEDIA_CLASS_GENRE

• MEDIA_CLASS_IMAGE

• MEDIA_CLASS_MOVIE

• MEDIA_CLASS_MUSIC

• MEDIA_CLASS_PLAYLIST

• MEDIA_CLASS_PODCAST

• MEDIA_CLASS_SEASON

• MEDIA_CLASS_TRACK

• MEDIA_CLASS_TV_SHOW

• MEDIA_CLASS_URL

• MEDIA_CLASS_VIDEO

• MEDIA_TYPE_ALBUM

• MEDIA_TYPE_APP

• MEDIA_TYPE_APPS

• MEDIA_TYPE_ARTIST

• MEDIA_TYPE_CHANNEL

• MEDIA_TYPE_CHANNELS

• MEDIA_TYPE_COMPOSER

• MEDIA_TYPE_CONTRIBUTING_ARTIST

• MEDIA_TYPE_EPISODE

• MEDIA_TYPE_GAME

• MEDIA_TYPE_GENRE

• MEDIA_TYPE_IMAGE

• MEDIA_TYPE_MOVIE

• MEDIA_TYPE_MUSIC

• MEDIA_TYPE_PLAYLIST

• MEDIA_TYPE_PODCAST

• MEDIA_TYPE_SEASON

• MEDIA_TYPE_TRACK

• MEDIA_TYPE_TVSHOW

• MEDIA_TYPE_URL

• MEDIA_TYPE_VIDEO

• REPEAT_MODE_ALL

• REPEAT_MODE_OFF

• REPEAT_MODE_ONE

• REPEAT_MODES

Use the new MediaClass, MediaType, and RepeatMode enum instead.

The use of STATE_* constants to reflect media player state is also deprecated. Please use the new MediaPlayerState enum instead.

The issue registry has been moved from homeassistant.components.repairs to homeassistant.helpers and is now loaded together with the other registries very early during bootstrapping, before setup of any integrations.

This allows creating issues during validation of the configuration.

It's now possible to get a reference to the HomeAssistant instance by calling core.async_get_hass().

Although this means it's no longer strictly necessary to pass hass around, the recommendation is still to only use core.async_get_hass where it's very cumbersome or downright impossible to pass hass to the code which needs it. An example where this can be useful is voluptuous validators, which previously couldn't access hass because voluptuous has no way of passing user data to validators.

@callback
def async_get_hass() -> HomeAssistant:
    """Return the HomeAssistant instance.
    Raises LookupError if no HomeAssistant instance is available.
    This should be used where it's very cumbersome or downright impossible to pass
    hass to the code which needs it.
    """

LightEntity no longer supports white_value, it's replaced by color mode white.

Background​

Light's white_value was deprecated in Home Assistant Core 2021.4 by PR #47720 and replaced by color mode white in Home Assistant Core 2021.7 by PR #51411.

For Home Assistant Core 2022.9, we have deprecated AutomationActionType, AutomationTriggerInfo, and AutomationTriggerData from homeassistant/components/automation/__init__.py. They are being replaced by TriggerActionType, TriggerInfo, and TriggerData from homeassistant/helpers/trigger.py.

Furthermore, we recommend updating the automation_info parameter name for the async_attach_trigger function to trigger_info.

For Home Assistant Core 2022.9 we have changed the PassiveBluetoothProcessorCoordinator and PassiveBluetoothDataProcessor bluetooth API's to make PassiveBluetoothProcessorCoordinator responsible for parsing. The coordinator then pushes parsed data to PassiveBluetoothDataProcessor instances.

PassiveBluetoothProcessorCoordinator now takes a mandatory update_method callback that receives bluetooth advertisements (in the form of BluetoothServiceInfoBleak) and returns the data that should be handed off to any subscribed PassiveBluetoothDataProcessor:

def my_parser(service_info: BluetoothServiceInfoBleak) -> MyDataClass:
    ...

    return MyDataClass(
        a=some_parsed_data,
        b=some_other_parsed_data,
    )


coordinator = PassiveBluetoothProcessorCoordinator(
    hass,
    _LOGGER,
    address=address,
    mode=BluetoothScanningMode.PASSIVE,
    update_method=my_parser,
)

PassiveBluetoothDataProcessor still takes an update_method, but instead of a BluetoothServiceInfoBleak, it now receives the data returned from PassiveBluetoothProcessorCoordinator's update_method. It should still return a PassiveBluetoothDataUpdate as before:

def sensor_update_to_bluetooth_data_update(
    sensor_update: MyDataClass,
) -> PassiveBluetoothDataUpdate:
    """Convert a sensor update to a bluetooth data update."""
    ...
    return PassiveBluetoothDataUpdate( ... )

processor = PassiveBluetoothDataProcessor(sensor_update_to_bluetooth_data_update)

All the built-in integrations have already been converted, so take a look at them for more examples.

This change will help integrations that need to start parsing data before loading a platform (for example, the list of platforms to load depend on data from the advertisements) or changes where a single advertisement drives multiple platforms (you won't have to parse the broadcast twice).

For Home Assistant Core 2022.9, we have deprecated the device_tracker SOURCE_TYPE_* constants. Use the new SourceType enum instead.

Deprecated constants:

• SOURCE_TYPE_GPS
• SOURCE_TYPE_ROUTER
• SOURCE_TYPE_BLUETOOTH
• SOURCE_TYPE_BLUETOOTH_LE

We are working on improving and standardizing our entity naming. This will allow us to show, in the UI, entities in the right context in the future while removing some error-prone magic mangling of entity names from the code base.

The short story is:

• Devices have their name as they have today, for example, "Dishwasher".
• Entities will have their own name (without device, area). Or, they may optionally set the name to None (in that case they inherit the device name).
• Device, Area, and Entity names all start with a capital letter, the rest of the words are lower case (unless it's a word that represents a brand/name/abbreviation of course).
• Every entity which has been migrated to follow these rules should set the has_entity_name property to True.

During the migration period, we use the has_entity_name property to create "backward compatible" friendly names. In the future, we can show deprecation warnings for entities that don't set this property, and later, remove it entirely.

The frontend is going to be adjusted for this. It will be able to show the entities/devices in various ways, what suits the context the most.

Example​

This illustrates how devices and entities should be named according to the new recommendations (type: entity name / state object's friendly_name / entity_id). Developers only need to set device name and entity name, the friendly_name and entity_id are automatically generated.

• Device: Dishwasher
  • Switch: None / Dishwasher / switch.dishwasher
  • Sensor: Power usage / Dishwasher Power usage / sensor.dishwasher_power_usage
• Device: Laundry machine
  • Switch: None / Laundry machine / switch.laundry_machine
  • Sensor: Power usage / Laundry machine Power usage / sensor.laundry_machine_power_usage

Background​

Home Assistant models the home of a user into three levels:

• Area (eg. Living Room)
• Device (eg. Switch)
• Entity (eg. Power usage)

Entities in Home Assistant are the data points provided by a device and can represent specific controls (a switch of the device, a light of the device).

Because Home Assistant used to only have entities in the first many years of its existence, a lot of functionality is based around entities in Home Assistant, the main one being the UI.

Let’s say you have 2 Shelly switches that report power usage named Dishwasher and Laundry Machine. Both devices have a switch entity and a power sensor. The devices and entities would previously look like this (type: entity name / state object friendly_name / entity_id):

• Device: Dishwasher
  • Switch: Dishwasher Switch / Dishwasher Switch / switch.dishwasher_switch
  • Sensor: Dishwasher Power usage / Dishwasher Power usage / sensor.dishwasher_power_usage
• Device: Laundry machine
  • Switch: Laundry machine Switch / Laundry machine Switch / switch.laundry_machine_switch
  • Sensor: Laundry machine Power usage / Laundry machine Power usage / sensor.laundry_machine_power_usage

Why is this a problem?​

There is not a single source of truth for a device name because entities included the device name in their name.

Because we “solved” a problem for the UI and the entity_id by including the device name in the entity name, we now have this solution applied to all places where we use entities and have to work around this solution.

This naming scheme makes it unnecessarily difficult to migrate the UI towards hierarchical views of areas->devices->entities instead of long lists of entities.