WeatherEntity now allows a single weather entity to support different forecast types meaning it's no longer necessary to create multiple entities for the same location, as an example, an entity providing daily forecast and another entity providing hourly forecast.

Integrations providing weather entities should be updated to implement one or several of the new async methods async_forecast_daily, async_forecast_hourly and async_forecast_twice_daily.

For the upcoming Home Assistant Core 2024.3 release, integrations should remove the deprecated forecast property and also remove any duplicated weather entities which were added to provide multiple forecasts.

See weather developer documentation for details on how to implement the new forecast methods.

The "Weather Forecast Card" has been updated to provide the user with an option to select the preferred forecast to show, if the integration are using the new methods.

The way MQTT entities are named and how device configuration can be shared between discovered entities has changed

Sharing of device configuration​

Discovered MQTT entities can share device configuration, meaning one entity can include the full device configuration and other entities can link to that device by only setting mandatory fields. The mandatory fields were previously limited to at least one of connection and identifiers, but has now been extended to at least one of connection and identifiers as well as the name.

Naming of MQTT entities​

Naming of MQTT entities has been changed to be aligned with the entity naming guidelines:

• The has_entity_name entity will be set to True on all MQTT entities
• Unnamed binary_sensor, button, number and sensor entities will now be named by their device class instead of being named `MQTT binary sensor" etc.
• It's now allowed to set an MQTT entity's name to None to mark it as the main feature of a device

We now support translating services in Home Assistant. Previously, the names & descriptions of services and their service fields have been hardcoded into the services.yaml files of each integration.

We have now added support for translating these names & descriptions using our translation system. This means that the names & descriptions of services and their service fields can now be translated into any language.

To achieve this, the name and description keys from each service and service field moves from the hardcoded services.yaml files to the translation files of each integration.

An updated example of a services.yaml service description can be found in our documentation. The backend localization has been extended to have an example of a translated service, matching the example from the service description.

The services translation is available as of Home Assistant 2023.8. We hope this will make Home Assistant more accessible to non-English users.

The Vacuum entity has seen some recent changes:

• The VacuumEntity base class was superseded by StateVacuumEntity by PR 15573 which was merged in August 2018, and has now been scheduled for removal in Home Assistant Core 2024.2.0. All core integrations are already updated, but custom component integration authors need to update their integrations. PR 95920 is a recent example of migrating from VacuumEntity to StateVacuumEntity.
• Services supported by VacuumEntity and StateVacuumEntity differ, but the documentation was a bit ambiguous causing some integrations to implement services from the wrong base class. This is now prevented by PR 95833. All core integrations are already updated, but custom component integration authors need to update their integrations.
• The battery_icon + battery_level state attributes have been deprecated. Integrations can instead report battery status by adding a sensor with device class battery to the same device as the vacuum entity, see architecture discussion 938 for details.
• The map state attribute has been deprecated. Integrations can instead provide a map image by adding an image entity to the same device as the vacuum entity, see architecture discussion 939 for details.

For more details, refer to the vacuum documentation.

In the Home Assistant Core 2023.7 release, we introduced hass-action for custom cards.

If you are a custom cards developer, you can now use any card action in your custom card by using the new hass-action.

Example :

// Define the action config
const actionConfig = {
  entity: "sensor.temperature",
  tap_action: {
    action: "more-info",
  },
  hold_action: {
    action: "assist",
    start_listening: true,
  },
};

// Open more info on tap action
const event = new Event("hass-action", {
  bubbles: true,
  composed: true,
});
event.detail = {
  config: actionConfig,
  action: "tap",
};
this.dispatchEvent(event);

// Open assist dialog on hold action
const event = new Event("hass-action", {
  bubbles: true,
  composed: true,
});
event.detail = {
  config: actionConfig,
  action: "hold",
};
this.dispatchEvent(event);

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