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.

In the Home Assistant Core 2022.3 release, we add custom features for the tile card. If you are a developer of custom cards, you can now build your own features to the tile card instead of building a whole card.

type: tile
entity: button.push
features:
  - type: custom:button-press-tile-feature

Custom tile features can even be added to the tile card editor like any other built-in tile feature using similar syntax as custom cards.

window.customTileFeatures = window.customTileFeatures || [];
window.customTileFeatures.push({
  type: "button-press-tile-feature",
  name: "Button press",
});

For more details, see the custom tile features documentation.

Home Assistant's MQTT integration no longer supports deprecated callback signatures for MQTT subscribe.

Custome integrations that still used the deprecated callback signature for the callback function on MQTT subscribe will break unless updated. An exception will be raised if a not supported callback type is detected.

Examples of deprecated callback functions that will no longer work:

async def async_deprecated_callback1(topic: str, payload: ReceivePayloadType, qos: int) -> None:
    """Deprecated async callback example 1."""
    ...


@callback
def async_deprecated_callback2(topic: str, payload: ReceivePayloadType, qos: int) -> None:
    """Deprecated async callback example 2."""
    ...

Example of a correct callback signature:

@callback
def async_correct_callback(msg: ReceiveMessage) -> None:
    """Callback example 1."""
    ...

Home Assistant now supports snapshot testing for our Python codebase.

Snapshot testing (also known as approval tests) are tests that assert values against a stored reference value (the snapshot); ensuring the output of code remains the same over time.

Snapshot tests are different from regular (functional) tests and do not replace functional tests, but they can be very useful for testing larger test outputs. Within Home Assistant they could, for example, be used to test entity states, device or entity registry items, or the output of a diagnostic dump.

Take, for example, this diagnostic test, which uses a snapshot to assert the output of a diagnostic dump:

# tests/components/example/test_diagnostics.py
async def test_diagnostics(
    hass: HomeAssistant,
    hass_client: ClientSessionGenerator,
    init_integration: MockConfigEntry,
    snapshot: SnapshotAssertion,
) -> None:
    """Test diagnostics."""
    assert (
        await get_diagnostics_for_config_entry(hass, hass_client, init_integration)
        == snapshot
    )

When this test is run for the first time, it will fail, as no snapshot exists. To create (or update) a snapshot, run pytest with the --snapshot-update flag, which will create a snapshot file in the snapshots directory of this component.

The snapshot file is named after the test file, in this case: tests/components/example/snapshots/test_diagnostics.ambr. The snapshot files are human-readable and must be committed to the repository.

Any sequential runs of the tests will then compare the results against the snapshot. If the results are different, the test will fail.

Snapshots are an easy way to ensure the output of code remains the same over time and can greatly reduce the amount of testing code needed (while providing) a full assert against a complete output.

Snapshot testing in Home Assistant is build on top of Syrupy, which has been extended to handle Home Assistant-specific data structures.

More information on testing integrations, can be found in our documentation.

As of Home Assistant Core 2023.3, some constants and functions have been moved between homeassistant.helpers.json and homeassistant.util.json :

• save_json and find_paths_unserializable_data functions should now be imported from homeassistant.helpers.json
• json_loads function should now be imported from homeassistant.util.json
• JSON_ENCODE_EXCEPTIONS and JSON_DECODE_EXCEPTIONS constants should now be imported from homeassistant.util.json

We've added a new built-in intent: HassGetState

This intent will enable users to ask questions to Assist once we've added translations to the intents repository. You can try it out now by adding custom sentences:

# Example <config>/custom_sentences/en/get_state.yaml

language: en
intents:
  HassGetState:
    data:
      - sentences:
          - what is <name> [in <area>]
          - is <name> {state} [in <area>]

responses:
  intents:
    HassGetState:
      default: "{{ slots.name }} is {{ state.state_with_unit }}"

lists:
  state:
    values:
      - "on"
      - "off"
      - open
      - closed
      - locked
      - unlocked
      - wet
      - dry

With these sentences, you can now ask Assist things like "what is the outside temperature?", "is the front door locked?", or "is the floor in the basement wet?" This relies on having entity names (or aliases) set up just right, of course. For example, a sensor named "outside temperature" and a binary moisture sensor named "floor" in the "basement" area.

As we add translations, more types of questions will be possible such as "which lights are in the living room?" and "are any doors unlocked?"