There have been a couple of changes to entity naming:

• Marking an entity as the single main feature of a device is now done by explicitly setting the entity's name property to None, implicitly marking an entity as the single main feature of a device by not setting the name property is no longer supported.
• Unnamed entities from certain platforms now get a default name based on their device class, this includes binary_sensor, button, number and sensor entities.

More details can be found in the entity naming documentation.

Service call descriptions have been changed to support filtering. It's possible to add a filter to a service call to not show entities which do not support the service call, it's also possible to add a filter to a service call field to not show fields which are not supported by a selected entity to the user.

For example:

• The brightness service call parameter for light.turn_on will only be shown if the light supports brightness.
• The climate.set_aux_heat service call will only allow picking a climate entity which supports auxiliary heat.

This features was introduced in core PR #86162 and is documented here.

This change affects Service Call APIs: hass.services.async_call and hass.services.call.

For Home Assistant Core 2023.7 some input arguments and the return values for service calls have been changed to prepare to better support Service return values.

Previously, the return value of True on success and False if a timeout occurred. The limit argument that sets a timeout has been removed, and the boolean return value has been removed. Callers that would like a timeout should now set their own using asyncio.

The way Home Assistant's MQTT integration processes MQTT messages and how subscribes and unsubscribes are performed has changed.

Updates were made in the way MQTT subscribes, unsubscribes are performed​

Subscribes and unsubscribes are not immediately sent to the broker anymore. Debouncer code was added that will delay subscribes to the broker and bundle them when more are added within the debounce time. At the point where the actual (un)subscribes are done, the (un)subscribes are bundled into one call to the broker. These changes will speed up the MQTT integration and the startup of integrations that register a lot of MQTT entities, especially when shared topics are subscribed to (e.g. to publish the availability). In the MQTT debug logging the mid number shows what (un)subscribe calls have been bundled in one call to the MQTT broker.

The way how retained messages are processed has changed​

The way MQTT messages with a set retain flag are handled has changed such that existing subscribers are no longer passed retained messages re-sent by the broker as a result of new subscribers subscribing to the same topic. Instead, retained messages re-sent by the broker are only passed to the new subscriber.

The new behavior avoids flooding subscribers with the same retained message over and over and is also better aligned with the MQTT specification, see OASIS MQTT Version 3.1.1 spec (on how the RETAIN flag is used) and Normative Statement Number MQTT-3.3.1-9.

Nabu Casa is seeking a passionate and experienced Python developer to join the Home Assistant core team as a full-time Software Engineer. As a member of our team, you will be responsible for reviewing contributions and developing new features that align with our roadmap.

Learn more @ Nabu Casa

This change affects WebSocket APIs: recorder/statistic_during_period and recorder/statistics_during_period. The Home Assistant project does not currently document these APIs, as they may change.

For Home Assistant Core 2023.6 the statistics WebSocket API will no longer return columns that it knows will be empty. Callers should treat the lack of values the same as null values.

To reduce database overhead, if the statistics backend knows in advance that all rows for a column will be empty values, the column will no longer be returned.

With Home Assistant OS 10, we update to the latest Docker release 23.0. With the new Docker version the maximum number of open file descriptors for add-ons changed to infinity (sort of).

If you are an add-on developer and experience out-of-memory issues on Home Assistant OS 10, you can apply the old limit by using ulimit -n 1048576 before starting your service.

Background: During Home Assistant OS release candidate phase, the higher limit turned out to be problematic for several add-ons (Node-RED, Network UPS Tools, and the EMQX MQTT broker, see Home Assistant OS issue #2438). In all cases, the problems manifested as an out-of-memory error, where it worked on the same hardware as the previous Home Assistant OS release. Also in all three cases, memory got allocated dynamically depending on the number of open file descriptors allowed (which can be determined via prlimit64 syscall, which returns a limit of 1073741816).

We considered returning to the old limit; however, according to the change in the Docker (moby) repository using infinity as a limit has less overhead. Therefore we decided to stick with the new default.

The Home Assistant frontend used to use the Polymer Library for her web components. Polymer has since been deprecated and superseded by Lit.

In the last couple of years, we migrated most of the frontend to Lit, and we only have a few places and dependencies that still use Polymer.

This is good news, as Lit is way faster and lighter than Polymer.

In Home Assistant 2023.4, we finally removed the last piece of Polymer from the entry point of Home Assistant, meaning it is not loaded when the app starts, but only when a component needs it.

For custom cards and panels, we have supplied Polymer on the window object, so it was easier to access and use. But nowadays it is hardly used anymore, and since Home Assistant no longer uses it, it is mainly a big chunk of unused code that is slowing down the loading of Home Assistant.

That's why we decided to remove it.

In Home Assistant 2023.5 Polymer will no longer be provided by Home Assistant. If you use Polymer now, we recommend you switch to Lit. If you want to keep using Polymer, you will have to load Polymer yourself.

In Home Assistant 2023.4, we will log a warning every time Polymer is accessed. If you got a log message, find the custom card, panel, or more info that uses Polymer, and notify the author of this deprecation.

Home Assistant has improved best practices for Calendar entities to ensure that calendar triggers/automations and the UI work correctly in all cases.

In particular, there are now more documented expectations and enforcement of invariants including:

• A CalendarEvent property end is exclusive. e.g. An all day event that lasts one day should have an end date with 1 day after the start date.
• A CalendarEvent can accept a datetime in any timezone. Floating dates without a timezone are not allowed.
• The CalendarEvent invariants are now enforced when created.
• Events returned by async_get_events are expected to be returned in order.
• All Day events returned by async_get_events must be evaluated in the Home Assistant local timezone. That is, an all day event should be ordered as if it starts at midnight in the local time.

The Calendar Entity developer documentation has been updated with additional detail.

It's now possible to translate the name of entities, and this is preferred over hard coding a name in natural language in the Python implementation. Also, entity components provide shared translations, for example, for binary sensor device classes, which should be used to avoid translating the same thing multiple times.

Also, the frontend now has full support for translated entity state attributes for both the names and their values.

Translating entity name​

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

{
  "entity": {
    "sensor": {
      "thermostat_mode": {
        "name": "Thermostat mode"
      }
    }
  }
}

The following example strings.json is for a sensor entity with its translation_key property set to temperature_sensor where a shared translation provided by the sensor integration is used:

{
  "entity": {
    "sensor": {
      "temperature_sensor": {
        "name": "[%key:component::sensor::entity_component::temperature::name%]"
      }
    }
  }
}

Translating entity attributes​

The following example strings.json is for a demo domain climate entity with its translation_key property set to ubercool, which has custom fan_mode and swing_mode settings:

{
  "entity": {
    "climate": {
      "ubercool": {
        "state_attributes": {
          "fan_mode": {
            "state": {
              "auto_high": "Auto High",
              "auto_low": "Auto Low",
              "on_high": "On High",
              "on_low": "On Low"
            }
          },
          "swing_mode": {
            "state": {
              "1": "1",
              "2": "2",
              "3": "3",
              "auto": "Auto",
              "off": "Off"
            }
          }
        }
      }
    }
  }
}

For more details, see the entity name translation entity attribute translation and entity documentation.