The websocket command entity/source has been greatly simplified:

• It's no longer possible to get information for a single entity
• Only the domain of the entities is included in the response, custom_component, config_entry and source are no longer present.

New response example​

{
  "light.entity_1": {
    "domain": "template",
  },
  "switch.entity_2": {
    "domain": "shelly",
  },
}

Old response example​

{
  "light.entity_1": {
    "custom_component": false,
    "domain": "template",
    "source": "platform_config",
  },
  "switch.entity_2": {
    "custom_component": false,
    "config_entry": "<config_entry_id>",
    "domain": "shelly",
    "source": "config_entry",
  },
}

The change was introduced in core PR#99439

In the Home Assistant Core 2023.9 release, we introduced 3 new methods to the hass object to allow entity state formatting with localization support for custom cards:

• hass.formatEntityState
• hass.formatEntityAttributeValue
• hass.formatEntityAttributeName

Example:

hass.formatEntityState(hass.states["cover.living_room_shutter"]); 
// It will return "Open" if the user language is English.
// It will return "Ouvert" if the user language is French.

For more details, refer to the entity state formatting documentation.

The signature of HomeAssistant.__init__ has been changed from no arguments to require the configuration directory as a string to be passed to it. Scripts, tests etc. outside of the HomeAssistant core repo which create HomeAssistant objects will need to be updated.

The change was introduced in core PR#98442

If backwards compatibility is important, this is a way to achieve it:

    try:
        hass = HomeAssistant()  # pylint: disable=no-value-for-parameter
    except TypeError:
        hass = HomeAssistant(config_dir)  # pylint: disable=too-many-function-args

Numerical sensors are no longer allowed to set their state to Not a Number or to positive or negative infinity.

The change was introduce in core PR#98110

For more details, refer to the sensor documentation.

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 DataUpdateCoordinator can now reduce unnecessary updates when API data can be compared.

When using the DataUpdateCoordinator, the data being polled is often expected to stay mostly the same. For example, if you are polling a light that is only turned on once a week, that data may be the same nearly all the time. The default behavior is always calling back listeners when the data is updated, even if it does not change. If the data returned from the API can be compared for changes with the Python __eq__ method, set always_update=False when creating the DataUpdateCoordinator to avoid unnecessary callbacks and writes to the state machine.

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);