The number of decimal digits shown when displaying a sensor state is now configurable by the user. Integrations can suggest the number of decimal digits by setting the property suggested_display_precision. Integrations are encouraged to remove rounding for display and instead set property suggested_display_precision.

Round for presentation is done by the frontend, as well as by new template functions introduced in core PR #87619.

The number of displayed decimal digits 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 suggested_display_precision
• Minimum precision when converting from a larger to a smaller unit is 0, i.e. there's no rounding to tens, hundreds etc.

The number of displayed decimal digits is not influenced by unit conversion if the user has set the display precision themselves.

Note: A similar concept where the sensor's state was rounded, detailed in an earlier blog post, has been reverted.

Home Assistant gets lots of contributions, which is absolutely amazing! But when having lots of PRs, it becomes harder to keep track of the state of those.

To help with this, we are introducing a new process to our review process that automatically drafts PRs when they require more work before they can be reviewed again (or merged).

We have adjusted our bot to automatically draft PRs if a review has requested changes to be made. Once the changes have been made, the author of the PR can click the "Ready for review" button to un-draft the PR and make it ready for review again.

Before you click the "Ready for review" button, make sure you have addressed all requested changes, and all our CI jobs and checks are passing successfully.

What is a draft PR?​

A draft PR is a PR that is not ready for review yet. It is a way to let others know that you are working on something, but it is not ready for review and merging yet.

Draft PRs are recognizable by the "Draft" label in the top right of the PR and show up with a grey merge icon eveywhere in the GitHub UI.

This doesn't mean you should open a PR to start working on something; please only open a PR if you think it is ready for review and merging. However, after opening a PR, there may be a reason to put it back into draft state.

For example, opening a PR will automatically trigger our CI jobs and checks. These checks can reveal issues in your code that need adjustments, or of course, an actual review took place that requested changes.

You can put any of your PRs back into draft at any moment, by clicking the "Convert to draft" link in the top right of your PR.

Why are we doing this?​

As a reviewer, you are presented with a lot of PRs. Some of them are ready for review, and some of them are not. Typically, the only way to find out, is to open the PR and look at it, to discover it is still in progress.

This is not only a waste of time but also a waste of energy. Especially considering this happens to multiple reviewers on the same PR multiple times a day.

The draft state of a PR is visible in all places in GitHub. In notifications, searches, and just the overview of PRs. Above all, it is easily filterable.

This gives reviewers a better focus on what can actually use their attention right now.

More background information can be found in this Google Document.

Or, read all about our review process on this page.

We have removed all translation files from the Home Assistant Core repository and put in place a helper script to compile English translations from the translation strings files (strings.json) for development purposes.

Previously, all translation files (including all languages) were part of the Home Assistant Core repository. Every night we would update the translations by downloading them from Lokalise and committing them into the Core repository.

Instead, we have moved this process @ build time. We now download the latest translations from Lokalise when we ship a new release (including betas & nightly builds).

This approach comes with some benefits:

• We no longer have to commit translation files into the Core repository. This means as a developer, this is also no longer a confusing burden.
• People will no longer (incorrectly) try to contribute language translations via GitHub.
• Each release, including patch, beta, and nightly versions, will now also have the latest translations.

Local development​

For local development, we have our translations development helper script. This always has been in place already, except now, it can compile the English translations for all integrations at once.

python3 -m script.translations develop --all

This script is automatically run when a dev environment is set up, and each time you run running Home Assistant in your VSCode (as a pre-launch task).

The intents repository which powers Assist, has had two important changes.

First, data blocks in the intents YAML can now have a response key. For example:

language: en
intents:
  HassTurnOn:
    data:
      - sentences:
          - "open {name}"
        response: cover

A response with a matching key must be defined in responses/<language>/<intent>.yaml:

language: en
responses:
  intents:
    HassTurnOn:
      cover: "Opened {{ slots.name }}"

Response templates are in the Jinja2 format, and may access the matched intent's slots as well as the state of the affected entity.

The second change comes from hassil, the parser for our intent template syntax. In addition to an 8-10x speed-up in parsing, whitespace inside templates is taken literally.

Previously, a template like light(s | ing) would match both "lights" and "lighting". Now, "light s" and "light ing" would be matched instead due to the extra space around |. The correct template would be light(s|ing)

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.