Recently, Home Assistant started to support images & icons for integrations to show up in the frontend. They look amazing and really brings some color to the UI of Home Assistant.

We got a lot of questions lately on how custom integrations (also known as custom components) can add their images. As of today, that is possible!

Created a custom integration? Want the logo & icon for your integration to show up in the Home Assistant frontend? In that case, head over to our GitHub brands repository to add yours!

PS: Did you know you can also add your custom integration to our Python wheels repository? It will make the installation of your custom integration in Home Assistant lightning fast!

If you are the author of a custom Lovelace card and use translations, please pay attention as the state translation keys have changed.

Before 0.109, state translations lived under state.<domain>.<state> or state.<domain>.<device class>.<state> for binary sensors. Starting with version 0.109, these translations are now part of the backend and so they have the key format for backend translations. We have standardized the state format to always include a device class. The device class _ is reserved as a fallback for entities without a device class.

In future releases, we're planning to migrate state attribute translations to the backend too. We'll publish this on this blog when it happens.

Hassfest is an internal tool that we use in Home Assistant to make sure that all integrations have valid data. We've now made Hassfest able to validate any integration, including custom integrations. To make it easy to get started with this, @ludeeus has created a GitHub Action that gets you up and running in less than a minute.

To install it, follow these steps:

1. Go to your custom component repository on GitHub

2. Click on "Create new file"

3. For filename, paste .github/workflows/hassfest.yaml

4. Paste the following contents:

   name: Validate with hassfest
   
   on:
     push:
     pull_request:
     schedule:
       - cron: "0 0 * * *"
   
   jobs:
     validate:
       runs-on: "ubuntu-latest"
       steps:
         - uses: "actions/checkout@v3"
         - uses: home-assistant/actions/hassfest@master
   

GitHub will now lint all incoming PRs and commits with hassfest, and will also run it once every night to check against the latest requirements.

The Hassfest action will track the beta release channel. That way you will be notified if your integration is incompatible with newer versions of Home Assistant.

Home Assistant uses a lot of different Docker containers for all kinds of purposes. Not only the Home Assistant Core that is available as Docker containers but also our Supervisor and all add-ons are leveraging Docker.

In many situations, we need to run multiple processes in our containers, that all need to be managed. We used to do this using simple Bash scripting, but quickly learned we need a proper process manager to handle this.

We decided to use the S6 Overlay init system, which is based on the excellent S6 toolset that provides process supervision and management, logging, and system initialization.

The S6 Overlay has been added to our Docker base images, which is used by every Docker image Home Assistant ships.

All containers have been updated, and changes are automatically handled by the Home Assistant Supervisor; For Home Assistant users, there is no noticeable impact.

For users of the Home Assistant Core containers on Docker, this might impact the way you run or start the container. If you run your Home Assistant Core container with an override of the Docker entry point or command, you need to adapt those. For example, some container management systems, like Portainer and Synology, automatically override those for you so you are impacted.

In those cases:

• The entry point has changed to: /init
• The command (CMD) has changed to: (Empty/not set)

If you override the command endpoint to start Home Assistant, the init system in the entry point will still be active in the background and a second launch Home Assistant. This can lead to unexpected behavior.

We've migrated our translation scripts in the Home Assisstant Core repository under a single namespace. It can now all be invoked using python3 -m script.translations.

This will help us prepare for our Translations 2.0 effort that will clean up translations and make it scale better.

We made some changes that can affect custom Lovelace cards in Home Assistant Core 0.106, if you are a custom card developer, please read the following.

Freeze config​

We used to give a copy of the configuration to every card because some cards altered the configuration Lovelace passed to them. In 0.105 we stopped doing this because it is not good for performance to create a deep copy for every card. This resulted in some problems because cards were still altering the configuration. In 0.106 we freeze the configuration. This means that a custom card cannot alter the configuration. If it tries to do it anyway, it will throw an exception or fail silently, depending on if it is run in strict mode.

Please check if your custom card still works with 0.106 and make adjustments to not alter the configuration. You can create a copy of the configuration yourself if you need to.

Helper functions​

A second change that was made, is that we no longer load all element types by default. We load them when they are needed. This will also help performance but might break your custom card.

We introduced a set of helpers that you can use to create a Lovelace element, these are the same functions Home Assistant uses internally and will always be up to date to the version the user is using. You can use them as follows:

const helpers = await loadCardHelpers();
const element = helpers.createRowElement(config);
element.hass = this.hass;

For more info see https://github.com/home-assistant/frontend/pull/4853

At the State of the Union we introduced that we're working on a new Z-Wave integration. It's based on a new project by the Open Z-Wave project called OZWDaemon and we will communicate with it over MQTT.

This new approach allows us to integrate directly with the core of Open Z-Wave without relying on bindings via other languages. This allows us to easily keep up to date with the latest Open Z-Wave versions.

There has been some great progress on the integration thanks to @cgarwood and @marcelveldt and you can start testing it out today as a custom component. It's still early and not every device type is supported yet. Currently it supports lights, switches, sensors and binary sensors. The custom component is powered by the new python-openzwave-mqtt package.

Please try it out. If you find any bugs, create an issue. If you are using Home Assistant 0.105, use the new mqtt.dump service on topic openzwave/# to make a dump of your Open Z-Wave instance and attach that to your issue. The dump will be written to mqtt_dump.txt in your config folder.

Once the integration is mature enough, it will become part of Home Assistant Core.

The Home Assistant UI has two different modes. There is a simple mode and an advanced mode. Simple mode has been introduced recently in Home Assistant 0.96. In this post I want to outline my vision for simple mode in Home Assistant 1.0.

With simple mode we focus on the core Home Assistant experience. We're trying to answer the question: what is it that we want anyone to be able to do. Can we make it intuitive enough that people, young and old, can install Home Assistant and use it.

Core concepts​

Simple mode is the simplified interface for non-power users. This is the default UI. Simple mode offers a subset of Home Assistant that is intuitive: easy to understand and easy to use.

In simple mode, we will structure the configuration to how the user thinks about their house:

• Inputs: devices and persons
• Outputs: scenes, scripts, automations

There are other inputs, but they are there to support devices and persons:

• Integrations allow you to interact with your devices
• Users allow persons to log in and access Home Assistant
• Areas allow devices to be grouped
• Zones label locations on the map to allow tracking persons that carry a GPS emitting device

As a user in simple mode, you will not be exposed to events, entity IDs, YAML or services.

This year we're again participating in Hacktoberfest. Hacktoberfest is a worldwide event to celebrate open source. If you make four pull request in the month of October, you'll get a free Hacktoberfest t-shirt.

Home Assistant is currently racing towards our magical 1.0 release. Home Assistant 1.0 is all about user friendliness. As part of this, we have recently introduced device automations and are expanding how scenes work in Home Assistant.

Home Assistant supports a wide range of products, and so not each feature that we built supports each product type yet. For this Hacktoberfest, we've prepared issues to help integrations use the latest Home Assistant features.

To make it easier to get started, we have introduced a new scaffolding script. This script is able to create all the boilerplate necessary to add new features to existing entity integrations. Including tests! You will only need to focus on code to work with the specific integration. Instructions on how to use it are included in each issue linked below.

If you want to see all available issues instead of the tailored list below, check here (requires being logged in to GitHub).

Update Sep 30: Added docs section, updated the links in the Almond section, added link to all Home Assistant Hacktoberfest issues.

Update Okt 1: Added frontend section.

Scenes​

Scenes allow a user to define how a light should look (ie, it should be on and the color should be blue). When a scene is activated, it is then up to Home Assistant to figure out which services to call to make this happen.

Scenes are a powerful tool that is easy to understand for users. It's therefore important that we improve our scene support. We have prepared the following issues:

• Add scene.create service to create scenes on the fly.
• Add scene.apply service to apply a scene defined as service data.
• Add activate scene to script syntax
• Add reproduce state support to entity integrations. (multiple issues)

Today we have officially adopted the Python code formatting tool Black. All code has been formatted with Black and all future contributions will be checked to make sure that they have been formatted using Black.

As part of adopting Black, all style checks in flake8 and pylint have been disabled.

To make sure that all files are Black when you commit your changes, we are using pre-commit. The hook is automatically installed for new dev environments (as part of script/setup).

If you have an existing developer installation, please run inside your virtual environment:

pip install pre-commit
pre-commit install

pre-commit does not change your files, but merely confirms that the changed files are formatted by Black. We suggest that you set up your editor to automatically format files with Black when you hit save. Instructions for various editors can be found here.