Note: The changes described here have been reverted and replaced with rounding for presentation, more details can be found in this blog post.

SensorEntity can now do rounding of a numerical native_value when it's converted to the sensor state. This is implemented as a part of core PR #86074. The rounding is opt-in by integrations setting the native_precision property. It is recommended that this property is set by integrations because it ensures the number of decimals is reasonable also after unit conversion.

A summary of the changes, copied from the PR description:

• By default, no rounding is done
  • Integrations can influence the state precision by setting a new property native_precision
• The state precision is influenced by unit conversion
  • Converting from a smaller to a larger unit increases the display precision
  • Converting from a larger to a smaller unit decreases the display precision if the integration has set native_precision
  • Minimum precision when converting from a larger to a smaller unit is 0, i.e. there's no rounding to tens, hundreds etc.
• User can override the display precision from the frontend
  • There's no minimum precision, i.e. rounding to tens, hundreds, etc. is possible by setting a negative precision
• Integrations are encouraged to drop rounding for display and instead set property native_precision
• Trailing zeroes are added to the sensor state's string representation to match the precision if:
  • The precision is set by user
  • The native_precision property is not None
  • Unit conversion is done

The Home Assistant 2023.2 release contains PR 86592 and PR 86484 which include breaking changes to the conversation agent API to future proof it.

• Setting an agent now requires a config entry: `conversation.async_set_agent(hass, config_entry, agent).
• Unsetting an agent now goes via a new endpoint: `conversation.async_unset_agent(hass, config_entry)
• AbstractConversationAgent API has changed:
  • All onboarding logic removed
  • async_process now takes new ConversationInput parameter with the same arguments. Language is now always set.
  • async_process should now always return a ConversationResult. It's no longer allowed to return None or expect error handling to be done for you.

The intents HassCoverOpen and HassCoverClose have been deprecated as of Home Assistant 2023.02. Instead, use the intents HassTurnOn and HassTurnOff. This was done because some languages do not differentiate between Open/On and Close/Off.

Integrations that need to use a Bluetooth adapter should add bluetooth_adapters in dependencies in their manifest.json. The manifest.json entry ensures that all supported remote adapters are connected before the integration tries to use them. This replaces the need to add bluetooth in dependencies.

Integrations that provide a Bluetooth adapter should add bluetooth in dependencies in their manifest.json and be added to after_dependencies to the bluetooth_adapters integration.

Be sure to check out Best practices for integration authors when building new Bluetooth integrations.

For Home Assistant Core 2023.2 the database schema has changed.

This change affects custom integrations that do not use the recorder history API and access the last_updated, last_changed, or time_fired columns directly.

The documentation for the events and states have been updated and is available at the Data Science Portal.

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.