Update: multi-pan has been fixed and users can once again opt-in to the experimental version starting Home Assistant 2023.2.

In Home Assistant 2022.12 we soft-launched our experimental multi-pan feature: allowing to run both Zigbee and Thread using the single radio found in both Home Assistant Yellow and Home Assistant SkyConnect. Users had to find it in the hardware menu, confirm the experimental note and opt-in.

We just found a serious bug in the firmware that we need to fix. That's why we have decided to temporarily disable allowing users to opt in to multi-pan starting Home Assistant 2022.12.1.

The bug is that Zigbee end-devices cannot rejoin the network through the coordinator: it kicks them and asks them to re-join, over and over. Normal EmberZNet firmware does not behave this way. It only affects end devices joined directly to the coordinator, not ones joining through an intermediate router, and only those that attempt to re-join the network.

We're working with Silicon Labs to get this issue resolved as soon as possible. Once resolved, we will re-enable multi-pan.

Enabling multi-pan installs a special firmware on your radio. To disable multi-pan, the original Zigbee firmware needs to be installed again. This is not something that can be done automatically from Home Assistant yet. We will be updating this post soon with instructions on how to do this via your browser.

From the Home Assistant Core 2022.12 release, we are using different colors per domain when an entity is active. These CSS variables are no longer used:

• --paper-item-icon-active-color
• --state-icon-active-color

This means that any theme that has previously overridden these CSS variables will use the built-in colors for active states. All theses new colors are available as CSS variables too.

More details about theme configuration can be found in the Home Assistant documentation.

The last few months saw many changes to the supported unit systems, and how numerical sensors are influenced by them. This blog post attempts to summarize the changes.

• The unit used for the state of a sensor whose device class is either of distance, gas, precipitation, precipitation_intensity, speed, volume, water, weight, or wind_speed is influenced by the unit system and automatically converted.
  • Integrations can override the unit system rules by setting the entity property suggested_unit_of_measurement.
  • To avoid breaking changes, the unit of a sensor is automatically converted according to the unit system rules only the first time the sensor is added to Home Assistant. This means sensors already in the user's system won't be affected by the new unit conversion rule.
  • If the user changes the unit system in their preferences, the units of sensors already in the user's system won't be affected by the unit system change.
  • Integrations, in most cases, no longer have to do any unit conversion as it is now automatically handled.
  • Existing integration specific code implementing unit conversion can, in most cases, be removed as the sensor's state will be automatically converted after the custom code is removed. For details on how this works, see core PR #83228. Note: This only works for sensors with a unique_id.
  • Custom option flows which allows the user to select sensor units for an integration can, in most cases, be removed. The user can instead override the sensor's unit via entity settings in frontend if the automatic conversion according to the selected unit system is not to their liking. Note: This only works for sensors with a unique_id.
• The behavior of temperature sensors is mostly unchanged; the unit of a temperature sensors state will always reflect the unit system unless:
  • The user has overridden the unit via entity settings in the frontend.
  • The temperature sensor has a non-None suggested_unit_of_measurement property.
• The IMPERIAL_SYSTEM unit system has been deprecated, and replaced with US_CUSTOMARY_SYSTEM. Furthermore, the is_metric and name properties of a unit system are deprecated and should not be used. More details about these changes can be found in this blog post.
• The unit conversion utilities have been refactored and moved, unit converters are now available as static classes in homeassistant/util/unit_conversion. More details about these changes can be found in this blog post.

As of Home Assistant Core 2023.1, the following unit constants are deprecated and replaced by a corresponding enum:

• UnitOfApparentPower enumerator replaces POWER_VOLT_AMPERE constant
• UnitOfDataRate enumerator replaces DATA_RATE_*** constants
• UnitOfElectricCurrent enumerator replaces ELECTRIC_CURRENT_*** constants
• UnitOfElectricPotential enumerator replaces ELECTRIC_POTENTIAL_*** constants
• UnitOfFrequency enumerator replaces FREQUENCY_*** constants
• UnitOfInformation enumerator replaces DATA_*** constants
• UnitOfIrradiance enumerator replaces IRRADIATION_*** constants
• UnitOfSoundPressure enumerator replaces SOUND_PRESSURE_*** constants
• UnitOfTime enumerator replaces TIME_*** constants
• UnitOfVolumeFlowRate enumerator replaces VOLUME_FLOW_RATE_*** constants

The method for integrations to provide translations for states of its entities under other integrations, for example to translate an integration's sensors has changed.

Integrations should no longer use custom device classes together with a strings.<platform name>.json file. Instead, entities should set the translation_key property on an entity and include that translation_key in the integration's strings.json.

The following example strings.json is for a Moon domain sensor entity with its translation_key property set to phase:

{
  "entity": {
    "sensor": {
      "phase": {
        "state": {
          "new_moon": "New moon",
          "first_quarter": "First quarter",
          "full_moon": "Full moon",
          "last_quarter": "Last quarter"
        }
      }
    }
  }
}

For more details, see the translation and entity documentation.

As of Home Assistant Core 2022.12, the following unit constants are deprecated and replaced by a corresponding enum:

• UnitOfPrecipitationDepth enumerator replaces PRECIPITATION_*** constants

Some changes have been made to the long-term statistics-related APIs to reduce response size and database load.

The changes are implemented in this PR.

This affects authors of code calling the following WS APIs:

• recorder/statistics_during_period
  • A new optional parameter types has been added, which allows providing a list of statistics characteristics to include in the response. Possible values are: "last_reset", "max", "mean", "min", "state", "sum"
  • Timestamps start, end and last_reset are now an integer number of ms since the UNIX epoch instead of ISO-formatted strings. The new format means the timestamps can be passed directly to js Date() constructor.
  • The statistic_id is no longer repeated for each list item in the returned map. This was not used because the return type is a map, keyed by statistic_id.

This affects authors of code calling the following Python APIs:

• homeassistant.recorder.statistics.get_last_short_term_statistics
  • A new parameter types has been added, which allows providing a set of statistics characteristics to include in the response. Possible values are: "last_reset", "max", "mean", "min", "state", "sum"
  • Timestamps start, end and last_reset are now an datetime objects instead of ISO-formatted strings.
  • The statistic_id is no longer repeated for each list item in the returned map. This was not used because the return type is a map, keyed by statistic_id.
• homeassistant.recorder.statistics.get_latest_short_term_statistics
  • A new parameter types has been added, which allows providing a set of statistics characteristics to include in the response. Possible values are: "last_reset", "max", "mean", "min", "state", "sum"
  • Timestamps start, end and last_reset are now an datetime objects instead of ISO-formatted strings.
  • The statistic_id is no longer repeated for each list item in the returned map. This was not used because the return type is a map, keyed by statistic_id.
• homeassistant.recorder.statistics.statistics_during_period
  • A new parameter types has been added, which allows providing a set of statistics characteristics to include in the response. Possible values are: "last_reset", "max", "mean", "min", "state", "sum"
  • Timestamps start, end and last_reset are now an datetime objects instead of ISO-formatted strings.
  • The statistic_id is no longer repeated for each list item in the returned map. This was not used because the return type is a map, keyed by statistic_id.

As of Home Assistant Core 2022.11, the following unit constants are deprecated and replaced by a corresponding enum:

• UnitOfEnergy enumerator replaces ENERGY_*** constants
• UnitOfLength enumerator replaces LENGTH_*** constants
• UnitOfMass enumerator replaces MASS_*** constants
• UnitOfPower enumerator replaces POWER_*** constants
• UnitOfPressure enumerator replaces PRESSURE_*** constants
• UnitOfSpeed enumerator replaces SPEED_*** constants
• UnitOfTemperature enumerator replaces TEMP_*** constants
• UnitOfVolume enumerator replaces VOLUME_*** constants

As of Home Assistant Core 2022.11, the following constants are deprecated for volumetric flux (like precipitation intensity), replaced by UnitOfVolumetricFlux enum:

• PRECIPITATION_INCHES_PER_HOUR replaced by UnitOfVolumetricFlux.INCHES_PER_HOUR
• PRECIPITATION_MILLIMETERS_PER_HOUR replaced by UnitOfVolumetricFlux.MILLIMETERS_PER_HOUR
• SPEED_INCHES_PER_DAY replaced by UnitOfVolumetricFlux.INCHES_PER_DAY
• SPEED_INCHES_PER_HOUR replaced by UnitOfVolumetricFlux.INCHES_PER_HOUR
• SPEED_MILLIMETERS_PER_DAY replaced by UnitOfVolumetricFlux.MILLIMETERS_PER_DAY

For the 2022.11 release, we have been adjusting our integration manifests to better differentiate between hubs, devices, and services. Additionally, we are introducing a new type of integration: A virtual integration.

Differentiating hubs, devices, and services​

A confusing aspect: config entries can either integrate a single device (ESPHome), a whole range of devices via a hub (Hue), or a service (AdGuard).

We want to start to distinguish between those in the UI in the near future, but are not currently able to do this because integrations don’t expose this information.

We already have a integration_type manifest property, which we have extended to support these new types:

• device: The integration integrates a single device at a time.
• hub: The integration integrates multiple devices.
• service: The integration integrates a service.

The difference between a hub and a service or device is defined by the nature of the integration. A hub provides a gateway to multiple other devices or services. service and device are integrations that provide a single device or service per config entry.

Virtual integrations​

Some products are supported by integrations that are not named after the product. For example, Roborock vacuums are integrated via the Xiaomi Miio integration.

There are also cases where a product line only supports a standard IoT standard like Zigbee or Z-Wave. For example, the U-tec ultraloq works via Z-Wave and has no specific dedicated integration.

For end-users, it can be confusing to find how to integrate those products with Home Asssistant. To help with these above cases, we introduce: Virtual integrations.

Virtual integrations are not real integrations but are used to help users find the right integration for their device. They only have a single manifest file without any additional code.

There are two types of virtual integrations: A virtual integration supported by another integration and one that uses an existing IoT standard.

Read more about it in our developer documentation.

Removing the supported brands feature​

Virtual integrations replace the previous "supported brands" feature. This feature was only used by Home Assistant Core integrations, and all those have been migrated to use virtual integrations instead.

There is no usage left, therefore, the supported brands feature has been removed without a deprecation period.