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.

Home Assistant is world's biggest open-source home automation platform. It supports over 1000 devices and services, and it is used everywhere: homes, boats and museums.

Today I want to talk about our UI, what we're trying to solve and how we solve it. Before we dive into why, what and how, let's take a look at our user interface. This is an embedded version of our demo, which is fully interactive.

The embedded demo has been hidden because the screen is too small. Open the demo in a new screen.

When building a platform for the Internet of Things, there are many use cases that warrant a user interface. Note that for the sake of this blog post, we're focusing on graphical user interfaces on devices with screens the size of a phone, or bigger.

Security. Users that want to have a quick glance at their house when they are away from home. They quickly want to check if their garage door is closed or maybe they got notified of unexpected motion in the backyard or water below the sink and need to check out. These users will want to see a logbook with recent security related incidents, the current camera streams and the current state of the doors, windows, water- and motion sensors.

Control all the things. Users want to have a single place to control all their devices. Their goal of the user interface is to quickly see each part of the house at a glance and control lights, switches, thermostats and the music.

Control single room. Users that are building interfaces for devices in each room. These devices need to expose all controls of a single room, with optional extra information about the whole house and options to control other parts of the house.

Monitor. Users want to build their own dashboards to visualize all the current and historical data inside Home Assistant and other databases, like InfluxDB. They want to keep track of their energy usage, track their internet speeds or current commute time.

Administer and Automate. Users that want to have dashboards that contain their controls to administrate Home Assistant. It contains their automations, scripts and various input controls to allow configuring the parameters of their automations and scripts.

The odds are that if you are using Home Assistant right now, your UI is a hybrid of a couple of the mentioned use cases. Todays blog post is going to talk about what technologies we have used to built a UI that allows users to build UIs that fit all these use case.

We have finished the great migration. The result will be released as part of Home Assistant 0.92. The release has been a bit delayed because we had a lot of things to fix! With the migration done, we now consider components and platforms that share the same name to be part of the same integration. Each integration is either a single Python file, or a folder with an __init__.py. file. We have updated the documentation and introduced a new section for integrations.

Home Assistant 0.92 introduces a new manifest.json for integrations. This file, which is optional for custom components, is used by integrations to specify metadata: name, link to the documentation, dependencies, requirements and code owners. We are exploring leveraging manifest.json for additional future features, like tracking breaking changes or allowing custom components to provide config flows and being discovered.

With all these changes, we had to drop a few deprecated things and change some behavior:

• Platforms can no longer be in the directory of the entity component, like light/my_platform.py. Instead, create a new my_platform folder in your custom_components, create an empty __init__.py file and move light/my_platform.py to my_platform/light.py.
• Platforms can no longer have dependencies or requirements. Instead, create a manifest.json in the my_platform folder to specify them, or add REQUIREMENTS or DEPENDENCIES constants to the __init__.py file.
• A platform will now always require the component, if available, to be set up first.
• It is no longer possible to provide translations for components that are contained in a single Python file. Convert them to an integration in a directory.
• If you want to override a built-in integration, you need to specify a manifest.json for your custom integration. Note that we strongly discourage overriding built-in integrations. Instead, if you want to run an integration with custom changes change the integration name. For example if you want to run a custom version of the MQTT integration, named mqtt in Home Assistant:
  • Copy the content of the mqtt folder from the Home Assistant repository to a new folder <config>/custom_components/mqtt_custom/
  • Open mqtt_custom/manifest.json and change the value for domain from mqtt to mqtt_custom
  • Open mqtt_custom/__init__.py and change the value of DOMAIN from mqtt to mqtt_custom
  • Anywhere in your config where you referenced mqtt, reference mqtt_custom. So use mqtt_custom: to specify the host and use platform: mqtt_custom when specifying platforms.