Skip to main content

· 2 min read

As of Home Assistant Core 2022.5, all SUPPORT_* constants are deprecated, each entity platform is providing an EntityFeature enum to replace them.

This applies to, the following platforms:

  • Alarm Control Panel

    Deprecated supported feature constants:

    • SUPPORT_ALARM_ARM_AWAY
    • SUPPORT_ALARM_ARM_CUSTOM_BYPASS
    • SUPPORT_ALARM_ARM_HOME
    • SUPPORT_ALARM_ARM_NIGHT
    • SUPPORT_ALARM_ARM_VACATION
    • SUPPORT_ALARM_TRIGGER

    Use the new AlarmControlPanelEntityFeature enum instead.

  • Camera

    Deprecated supported feature constants:

    • SUPPORT_ON_OFF
    • SUPPORT_STREAM

    Use the new CameraEntityFeature enum instead.

  • Cover

    Deprecated supported feature constants:

    • SUPPORT_OPEN
    • SUPPORT_CLOSE
    • SUPPORT_SET_POSITION
    • SUPPORT_STOP
    • SUPPORT_OPEN_TILT
    • SUPPORT_CLOSE_TILT
    • SUPPORT_STOP_TILT
    • SUPPORT_SET_TILT_POSITION

    Use the new CoverEntityFeature enum instead.

  • Climate

    Deprecated supported feature constants:

    • SUPPORT_TARGET_TEMPERATURE
    • SUPPORT_TARGET_TEMPERATURE_RANGE
    • SUPPORT_TARGET_HUMIDITY
    • SUPPORT_FAN_MODE
    • SUPPORT_PRESET_MODE
    • SUPPORT_SWING_MODE
    • SUPPORT_AUX_HEAT

    Use the new ClimateEntityFeature enum instead.

  • Humidifier

    Deprecated supported feature constants:

    • SUPPORT_MODES

    Use the new HumidifierEntityFeature enum instead.

  • Fan

    Deprecated supported feature constants:

    • SUPPORT_SET_SPEED
    • SUPPORT_OSCILLATE
    • SUPPORT_DIRECTION
    • SUPPORT_PRESET_MODE

    Use the new FanEntityFeature enum instead.

  • Light

    Deprecated supported feature constants:

    • SUPPORT_EFFECT
    • SUPPORT_FLASH
    • SUPPORT_TRANSITION

    Use the new LightEntityFeature enum instead.

    Note that the following light constants were already deprecated, thus LightEntityFeature does not provide a replacement for those.

    • SUPPORT_BRIGHTNESS
    • SUPPORT_COLOR_TEMP
    • SUPPORT_COLOR
    • SUPPORT_WHITE_VALUE

    These cases should instead be migrated to the new color modes.

  • Lock

    Deprecated supported feature constants:

    • SUPPORT_OPEN

    Use the new LockEntityFeature enum instead.

  • Media Player

    Deprecated supported feature constants:

    • SUPPORT_PAUSE
    • SUPPORT_SEEK
    • SUPPORT_VOLUME_SET
    • SUPPORT_VOLUME_MUTE
    • SUPPORT_PREVIOUS_TRACK
    • SUPPORT_NEXT_TRACK
    • SUPPORT_TURN_ON
    • SUPPORT_TURN_OFF
    • SUPPORT_PLAY_MEDIA
    • SUPPORT_VOLUME_STEP
    • SUPPORT_SELECT_SOURCE
    • SUPPORT_STOP
    • SUPPORT_CLEAR_PLAYLIST
    • SUPPORT_PLAY
    • SUPPORT_SHUFFLE_SET
    • SUPPORT_SELECT_SOUND_MODE
    • SUPPORT_BROWSE_MEDIA
    • SUPPORT_REPEAT_SET
    • SUPPORT_GROUPING

    Use the new MediaPlayerEntityFeature enum instead.

  • Remote

    Deprecated supported feature constants:

    • SUPPORT_LEARN_COMMAND
    • SUPPORT_DELETE_COMMAND
    • SUPPORT_ACTIVITY

    Use the new RemoteEntityFeature enum instead.

  • Siren

    Deprecated supported feature constants:

    • SUPPORT_DURATION
    • SUPPORT_TONES
    • SUPPORT_TURN_OFF
    • SUPPORT_TURN_ON
    • SUPPORT_VOLUME_SET

    Use the new SirenEntityFeature enum instead.

  • Vacuum

    Deprecated supported feature constants:

    • SUPPORT_TURN_ON
    • SUPPORT_TURN_OFF
    • SUPPORT_PAUSE
    • SUPPORT_STOP
    • SUPPORT_RETURN_HOME
    • SUPPORT_FAN_SPEED
    • SUPPORT_BATTERY
    • SUPPORT_STATUS
    • SUPPORT_SEND_COMMAND
    • SUPPORT_LOCATE
    • SUPPORT_CLEAN_SPOT
    • SUPPORT_MAP
    • SUPPORT_STATE
    • SUPPORT_START

    Use the new VacuumEntityFeature enum instead.

  • Water Heater

    Deprecated supported feature constants:

    • SUPPORT_TARGET_TEMPERATURE
    • SUPPORT_OPERATION_MODE
    • SUPPORT_AWAY_MODE

    Use the new WaterHeaterEntityFeature enum instead.

· 2 min read

There are a handful of new features for developers in 2022.4.

  • Integration Type: Integrations can now mark themselves as helper.
  • Backup platform: Integrations can now pause work during a backup by implementing the new backup platform.
  • hidden_by in entity registry: Entities can now be hidden via the entity registry. These entities should default to not be included when exposing entities to an external UI like voice assistants.
  • New and updated selectors: We added a bunch of new selectors to be used in blueprints, services.yaml, and config flows.
  • Selectors in backend flows: You can now use the selector helper in your config flows. It is configured and renders just like selectors in services.yaml/blueprints.
  • ha-form context: Context is a new way to allow selectors to be dynamically configured based on values from other fields. Currently only available for the attribute selector.
  • config flow helper text for fields: Config flow fields can now have a description.
  • Schema Config Flow helper: New helper to create config flows based on a config schema. Example implementation
  • Show Menu step: This new step in a data entry flow shows a menu to the user.
  • Fan speed: We introduced a new format and this transition is now completed.
  • Device State Attributes: Backwards compatibility support for this property has been removed after being deprecated since Home Assistant 2021.4. Use extra_state_attributes instead.
  • Cameras without width/height: The compatbility layer for cameras without width/height has been removed.
  • Calendar offset: Calendar method signatures for calculate_offset and is_offset_reached have changed, in preparation for typing improvements in Calendar, and potential simplification of offsets more generally.

· 2 min read

Home Assistant 2022.4 will provide a brand new entity platform: the update entity.

The update entity can be provided by integrations to indicate there is an update available, for a device or service, towards the Home Assistant user. It allows you to provide additional information about the update, such as the latest version available, a summary of the release notes and a link to the full release announcement online.

Additionally, the install method can be implemented, so the user can install the update directly from within Home Assistant.

Adding the update platform to your integration is relatively simple to do, as it is just a couple of properties and, if available for the integration, a single install method. Most other details are handled by Home Assistant automatically.

In Home Assistant Core 2021.12 we moved updates provided by the Supervisor to the Configuration panel, using this new platform, we will be able to extend that in the near future by the information provided by these brand new entities.

See our developer documentation for how to implement this in an integration.

If your integration previously provided a binary_sensor or button entity with the update device class, please consider replacing those with the update entity.

· One min read

In the Home Assistant Core 2022.3 release, Erik Montnemery added support for any integration to opt in to show a "delete device" button on the device page in the Home Assistant interface.

See our developer documentation for how to implement this in an integration.

So far five integrations have opted in to this feature:

Why is this needed?

Before this feature was added, integrations were advised to automatically clean up stale devices from the config entry. But not all integrations are able to automatically determine if a device should be removed, so a manual option where the user can make the choice is in some cases still needed.

To solve this need, some integrations had implemented an integration specific websocket command with accompanying frontend support to allow manual removal of a device. With this new feature, integrations do no longer need to add any websocket or frontend code but can easily support, just by implementing the backend callback function, manual device removal.

Happy days!

· 2 min read

In the Home Assistant Core 2022.3 release, we are removing all of the paper-dropdown-menu and paper-input elements in the Frontend Repository. This means that any custom card that was previously using these elements in the card or card editor will no longer render correctly and will require updates to its codebase.

Custom Cards using the elements used in the Home Assistant Frontend have never been supported.

Why did we do this?

We are converting our codebase from the deprecated paper elements to the new Material Web Components from Google. This is to keep our frontend up to date with the latest components and features.

What should custom cards do?

Our advice is to bundle the Material Web Components in your custom card using Scoped Custom Element Registry. The Home Assistant Frontend loads the polyfill needed for this to work starting with the release of Home Assistant 2022.3.

This will allow any custom card to utilize the same MWC elements that are used in the Lovelace Editors. You can see an example of this usage in the Boilerplate Card. Other HA elements like the icon picker (<ha-icon-picker>) are not supported in this same way.

See this old blog post for more information.

· 2 min read

Home Assistant Core 2021.11 introduces two new concepts to make managing devices easier, device configuration URL and entity categories.

Device configuration URL

It's now possible to provide a configuration_url as part of the device registry information. The configuration_url is used in the device card to allow the user to visit the device for configuration or diagnostics which is not available in Home Assistant. Note that the URL linked to is not proxied by Home Assistant, so this typically won't work when connecting to Home Assistant remotely.

Screenshot showing visit device

Entity categories

Entities now have an optional property entity_category for classifying non-primary entities. Set to config for entities that allow changing the configuration of a device, for example, a switching entity making it possible to turn the background illumination of a switch on and off. Set to diagnostic for an entity exposing some configuration parameter or diagnostics of a device but does not allow changing it, for example, a sensor showing RSSI or MAC address with allowed values.

Entities which have the entity_category set:

  • Are not included in a service call targetting a whole device or area.
  • Are, by default, not exposed to Google Assistant or Alexa.
  • Are shown on a separate card on the device configuration page.
  • Do not show up on the automatically generated Lovelace Dashboards.

Screenshot showing seperation of entity categories

· 4 min read

Note: This post was edited 2021-10-21 to remove references to total accumulated increases and decreases which were removed and never included in the Home Assistant 2021.10 release.

A new state class, total has been added and the last_reset attribute has been added back to SensorEntity and is no longer deprecated. The driver for the change is to support cases where total_increasing, which was introduced in Home Assistant 2021.9, is too restrictive to cover all cases. Note that setting last_reset for sensors with state class measurement is still deprecated.

State classes

There are 3 defined state classes:

  • measurement, the state represents a measurement in present time, for example a temperature, electric power, etc. For supported sensors, statistics of min, max and average sensor readings are updated periodically.
  • total, the state represents a total amount that can both increase and decrease, e.g. a net energy meter. When supported, the accumulated growth or decline of the sensor's value since it was first added is updated periodically.
  • total_increasing, a monotonically increasing total, e.g. an amount of consumed gas, water or energy. When supported, the accumulated growth of the sensor's value since it was first added is updated periodically.

State class total

For sensors with state class total, the last_reset attribute can optionally be set to gain manual control of meter cycles. The sensor's state when it's first added to Home Assistant is used as an initial zero-point. When a last_reset changes, the zero-point will be set to 0. If last_reset is not set, the sensor's value when it was first added is used as the zero-point when calculating sum statistics.

Example of state class total without last_reset:

tstatesum
2021-08-01T13:00:0010000
2021-08-01T14:00:00101010
2021-08-01T15:00:000-1000
2021-08-01T16:00:005-995

Example of state class total with last_reset:

tstatelast_resetsum
2021-08-01T13:00:0010002021-08-01T13:00:000
2021-08-01T14:00:0010102021-08-01T13:00:0010
2021-08-01T15:00:0010052021-08-01T13:00:005
2021-08-01T16:00:0002021-09-01T16:00:005
2021-08-01T17:00:0052021-09-01T16:00:0010

Example of state class total where the there initial state at the beginning of the new meter cycle is not 0, but 0 is used as zero-point:

tstatelast_resetsum
2021-08-01T13:00:0010002021-08-01T13:00:000
2021-08-01T14:00:0010102021-08-01T13:00:0010
2021-08-01T15:00:0010052021-08-01T13:00:005
2021-08-01T16:00:0052021-09-01T16:00:0010
2021-08-01T17:00:00102021-09-01T16:00:0015

State class total_increasing

For sensors with state_class total_increasing, a decreasing value is interpreted as the start of a new meter cycle or the replacement of the meter. It is important that the integration ensures that the value cannot erroneously decrease in the case of calculating a value from a sensor with measurement noise present. This state class is useful for gas meters, electricity meters, water meters etc.

The sensor's state when it's first added to Home Assistant is used as an initial zero-point. When a new meter cycle is detected the zero-point will be set to 0. Please refer to the tables below for how this affects the statistics.

Example of state class total_increasing with a new meter cycle:

tstatesum
2021-08-01T13:00:0010000
2021-08-01T14:00:00101010
2021-08-01T15:00:00010
2021-08-01T16:00:00515

Example of state class total_increasing where the there initial state at the beginning of the new meter cycle is not 0, but 0 is used as zero-point:

tstatesum
2021-08-01T13:00:0010000
2021-08-01T14:00:00101010
2021-08-01T15:00:00515
2021-08-01T16:00:001020

· 4 min read

It's been a while since we posted about changes to the Supervisor. Here are some highlights from the past year and the future. This information is mainly for add-on developers, but there is little something for everyone in here. If you have not yet seen it, we have posted a blog on the main site that you should read.

Snapshot -> Backup

First up, as mentioned in the blog on the main site, we have started a transition away from the name "snapshot" that has been with us since the beginning of the Supervisor and are now moving to the more recognizable "backup".

These changes are live now on the dev channel for the Supervisor, so you can start testing and adjusting your tools/add-ons to make sure they will still work when your users get this.

API changes

With the transition from "snapshot" to "backup", a new base section in the Supervisor API has been added /backups that operates the same way as /snapshots with all the same endpoints as the old section has but there are two key differences:

  • If you access /backups the data returned now will be {"backups": []} instead of {"snapshots": []}
  • To delete a snapshot you now have to use the DELETE HTTP method with the /backups endpoint, previously both POST and DELETE were supported.

The old /snapshots endpoints are now deprecated and are scheduled for removal in Q4 of this year.

Backup structure changes

For consistency, we have also changed the name of the meta file inside the backup tar from snapshot.json to backup.json. If you have a tool that uses that file you should look for both so your tool will work for existing as well as new backups.

Streaming ingress

Some add-ons need to receive large payloads from the user, for instance with uploading. Previously, there has been a limit of 16 MB per request for add-ons running behind ingress and this is still the default. If you need to receive larger payloads, you can enable this by setting ingress_stream to True in the add-on configuration. When you do this the request is streamed from the client to your add-on, and the request has no size limit and virtually no overhead.

Note that not all webservers are able to handle this by default, so you might need to adjust it.

Deprecated API endpoints

Over the past years, we have restructured parts of our API endpoints, but we have also kept old endpoints working. If you use any of the deprecated endpoints in your tools/add-ons you should move to use the new ones now. All deprecated endpoints are scheduled for removal in Q4 this year.

Here is a list of the deprecated endpoints and their replacements:

Deprecated endpointsReplaced with
/homeassistant/*/core/*
/snapshots/*/backups/*

In addition to this, the following are also deprecated and are also scheduled for removal in Q4 this year.

  • The environment variable HASSIO_TOKEN has been replaced with SUPERVISOR_TOKEN.
  • Using X-Hassio-Key header has been replaced with using Authorization with a Bearer token.
  • Using http://hassio/ to communicate with the Supervisor has been replaced with http://supervisor/.

Supervised installation

Maintaining a supervised installation is currently not the best experience. The script that most users use to install is behind what the Supervisor wants from the host. Since there are no real upgrade paths for those using it, users of it need to manually adjust their installation.

Recently we created the OS Agent as mentioned in the blog on the main site. This allows for better communication between the host OS and the Supervisor, and to bring in more features. To take advantage of these features users of current supervised installations have to install the OS Agent manually.

An alternative to this route is to package and distribute the supervised installation as a deb package that can be installed and upgraded with apt on the host. For this to be viable, we are looking for a person (or a group of people) that wants to create and maintain this type of deployment, and bring the supervised installation method up to par with our OS, and more importantly make updates needed on the host easier for the users.

If you have questions about these changes feel free to reach out in the #devs_supervisor channel on our Discord server.

Until next time 👋

· 2 min read

A new state class, total_increasing has been added. In addition, the last_reset attribute is removed from SensorEntity. The driver for the changes is to make it easier to integrate with devices, like utility meters.

State classes

There are 2 defined state classes:

  • measurement, the state represents a measurement in present time, for example a temperature, electric power, the value of a stock portfolio, etc. For supported sensors, statistics of hourly min, max and average sensor readings or of the accumulated growth or decline of the sensor's value since it was first added is updated hourly.
  • total_increasing, a monotonically increasing total, e.g. an amount of consumed gas, water or energy. When supported, the accumulated growth of the sensor's value since it was first added is updated hourly.

STATE_CLASS_TOTAL_INCREASING

For sensors with state_class STATE_CLASS_TOTAL_INCREASING, a decreasing value is interpreted as the start of a new meter cycle or the replacement of the meter. It is important that the integration ensures that the value cannot erroneously decrease in the case of calculating a value from a sensor with measurement noise present. This state class is useful for gas meters, electricity meters, water meters etc.

The sensor's state when it's first added to Home Assistant is used as an initial zero-point. When a new meter cycle is detected the zero-point will be set to 0. Please refer to the tables below for how this affects the statistics.

Example of STATE_CLASS_TOTAL_INCREASING with a new meter cycle:

tstatesum
2021-08-01T13:00:0010000
2021-08-01T14:00:00101010
2021-08-01T15:00:00010
2021-08-01T16:00:00515

Example of STATE_CLASS_TOTAL_INCREASING where the there initial state at the beginning of the new meter cycle is not 0, but 0 is used as zero-point:

tstatesum
2021-08-01T13:00:0010000
2021-08-01T14:00:00101010
2021-08-01T15:00:00515
2021-08-01T16:00:001020

This state class used to be represented by state class measurement in combination with a last_reset value. This approach has been deprecated and will be interpreted as a total_increasing state class instead with an automatic last reset.

· One min read

Temperature unit conversions are moving from the Entity base class to the SensorEntity base class. Unit conversions will only be done if the sensor's device_class attribute is set to DEVICE_CLASS_TEMPERATURE. If the device_class is not set or is not set to DEVICE_CLASS_TEMPERATURE temperature conversion will take place during a transition period and a warning will be logged.

To facilitate this, the sensor entity model has been updated with two new properties, native_value and native_unit_of_measurement. This allows us to add additional unit conversions in the future instead of relying on the integrations to do it themselves.

Sensor implementations should no longer implement the state() property function or set the _attr_state attribute. Sensor implementations should also not implement the unit_of_measurement property function, set the _attr_unit_of_measurement attribute or set the unit_of_measurement member of EntityDescription.

native_value

The value reported by the sensor. The actual state written to the state machine may be modified by SensorEntity due to unit conversions.

native_unit_of_measurement

The unit of measurement of the sensor, if any. The unit_of_measurement written to the state machine may be modified by SensorEntity due to unit conversions.