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.

How Home Assistant is using Azure Pipelines to automate all the things.

Here at Home Assistant, we love automation! Not only in our homes, but also when doing development work. We do a release every three weeks and it includes code from over 80 different people. All is managed by only two people working on this full-time (thanks Nabu Casa!).

We distribute Home Assistant as a Python package, and as part of our all-in-one system called Hass.io. Hass.io has its own operating system, a supervisor Docker container and the Home Assistant docker container. Besides that, Hass.io supports add-ons, of which we have a set of official add-ons that we also maintain. Everything we do for Hass.io, we have to do five times, once for each of our supported architectures: amd64, i386, armv6, armv7, aarch64.

To still be able to move fast, we spend a lot of time on automating build tasks. After working with TravisCI and CircleCI, we have finally landed on Azure Pipelines.

We started out with Travis but realized that we could significantly speed up our builds by leveraging the CircleCI open source plan that includes 4 workers, test distribution and build artifact caching. We tried to get more workers with CircleCI but adding workers under their new pricing plan was too expensive.

Pascal Vizeli had experience with Azure from a previous job, and he was able to migrate and build all the YAML based pipelines in days. He did this with support from Kees Schollaart, who is a DevRel at Azure but famous in our community for creating the Home Assistant Companion extension for VS Code. He helped us a lot whenever we got stuck.

Azure’s open source plan comes with 10 free agents, and after we reached out to Microsoft, we were provided 20 additional agents to help us automate all the things!

Interested to see what we do with all this Azure power?

This post is about the upcoming changes for the Home Assistant climate integration. These changes are being implemented right now and are no longer up for discussion. If you want to see changes, consider opening an architecture issue.

Starting with Home Assistant 0.96, we're shipping a big architectural clean up of our climate integrations. This effort is lead by Pascal Vizeli.

Over the years, the climate integration has grown from being a simple place for thermostats to hosting ACs, heat pumps and ventilation systems. During this growth, mistakes have been made which resulted in a confusing and hard to work with design. Work is underway to get this all cleaned up and we're going to ship this in Home Assistant 0.96.

The biggest mistake we made is that we conflated operating and operation mode. Operation mode is what you want your thermostat to do, for example, heat the house to 19 °C. The operating mode is what the thermostat is currently doing. Is it heating because the house is too cold? Or did it already reach the target temperature and is it currently idle?

On top of that, we've noticed that a lot of integrations overload operation mode with a wide range of delightful options like "eco", "comfort", "boost" or "sleep". After carefully analyzing all the different climate systems out there, we have come to the conclusion that these alternative operation modes are variations of the existing operation modes (heat, cool, heat-cool), but might have different target temperature ranges or try to heat/cool at a slower pace to conserve energy.

To support as many different thermostats as possible, we have decided to allow climate devices to specify a new "preset" mode that they are operating under. It covers hold mode, away mode, or any custom operation mode that a thermostat includes.

You might wonder, why go for a preset instead of allowing to overload operation mode? On first glance, it might seem fine for an integration to list the possible options and the current chosen option, easy to make a UI for. However, that's not the only way Home Assistant is used. We are also serving as a single place to control any thermostat for external systems like Google Assistant or Amazon Alexa. They have a limited set of operation modes they expect.

A gist of the changes:

• operation_mode has been renamed to hvac_mode to emphasize what the mode is for.
• We split HVAC mode auto into auto and heat_cool. If it's heat_cool, the user has set a temperature range the device has to use heating and cooling to stay within. Auto mode is now limited to devices that are running on a schedule or AI.
• The state of a climate entity is now always equal to the HVAC mode.
• hvac_action is introduced for integrations that know the current action: heating, cooling, idle.
• set_away_mode and set_hold_mode have been merged into set_preset_mode. So instead of turn_away_mode_on(), we will now call set_preset_mode("away").
• The is_on property has been removed. If a device is able to turn off, it should include the hvac mode HVAC_MODE_OFF.
• Property names have been aligned, anything ending with "_list" is now named "_modes".

If you are a maintainer of an integration that has a climate platform or maintain a custom component that has one, make sure you follow the pull request and test your integration during the beta to make sure that it works like expected.