Home Assistant

Introducing Hass.io

Paulus Schoutsen three minutes reading time
  • Announcements
 Comments

TL;DR: Today we’re introducing Hass.io. Hass.io is an operating system that will take care of installing and updating Home Assistant, is managed from the Home Assistant UI, allows creating/restoring snapshots of your configuration and can easily be extended using Hass.io add-ons including Google Assistant and Let’s Encrypt.

Home Assistant is 2 months away from being 4 years old. In that time the Internet of Things has really taken off and we’ve seen many new devices and services. We saw the introduction of voice assistants like Google Home and new standards like Apple HomeKit.

Some things have been supported natively in Home Assistant, others have been integrated into Home Assistant via third party applications. All these moving parts caused our users to spend a lot of time maintaining their systems and applications instead of automating their homes.

So we decided to take a step back from day-to-day Home Assistant development and see if we could offer a solution that makes updating a breeze for our users. A solution that you can flash to your Raspberry Pi and no longer worry about. A solution that would still be local first and respect the user’s privacy.

And this is how Pascal Vizeli came up with Hass.io, an operating system based on ResinOS and Docker. Hass.io will take care of installing and updating Home Assistant, is managed from the Home Assistant UI, allows taking/restoring snapshots of your configuration and can easily be extended using Hass.io add-ons.

Hass.io dashboard

To install add-ons, a user can browse the built-in add-on store and install, configure and update any available application. Want to turn your device into a Google Assistant or make your configuration accessible via Samba/Windows networking? Both are a couple of clicks away! (Video demo - 38s, no audio)

At launch we have included a couple of built-in add-ons like Google Assistant, Let’s Encrypt and Duck DNS. Besides our internal add-ons, it is also possible to create and share your own add-on repositories. During our beta period we’ve already seen some great add-ons being shared: Homebridge, InfluxDB, HASS Configurator and AppDaemon.

As we strongly believe in the openness of technology, we are releasing Hass.io as open source under the Apache 2.0 license. That way any user can make sure that the code that runs in their homes is secure and safe.

Some frequently asked questions are answered below in the read more section.

Hass.io has been built by Pascal Vizeli, the UI has been made by Paulus Schoutsen and BRUHAutomation made the introduction video. Big thanks to Resin.io for building ResinOS and helping us get started with it. Also a big thanks to the community for early feedback, helping out with the documentation and add-on development ❤️

Read on →

Home Assistant Podcast #4

Phil Hawthorne Less than one minute reading time
  • Media
 Comments

We quickly cover off a few community items including the move to Discord and Carlo talks with Phil about his use of Floorplan.

Listen online

0.49: Themes 🎨, kiosk mode and Prometheus.io

Paulus Schoutsen 13 minutes reading time
  • Release-Notes
 Comments

WE HAVE THEMES 🎨👩‍🎨

Our already amazing frontend just got even more amazing thanks to @andrey-git. With the new theme support you can be in control of the primary color, accent color and a whole bunch more.

You can specify themes using new configuration options under frontend.

frontend:
  themes:
    green:
      primary-color: "#6CA518"

Once a theme is defined, use the new frontend service frontend.set_theme to activate it. More information in the docs.

Screenshot of a green dashboard Screenshot of a green dashboard

Not all parts of the user interface are themable yet. Expect improvements in future releases.

Kiosk mode

Another great new improvement for the frontend is the addition of a kiosk mode. When the frontend is viewed in kiosk mode, the tab bar will be hidden.

To activate kiosk mode, navigate to https://hass.example.com:8123/kiosk/group.living_room_view. Note that for default_view the url is just https://hass.example.com:8123/kiosk

This feature has also been brought to you by @Andrey-git! Big shout out to him for his continuous efforts to bring Home Assistant to the next level.

New Platforms

Release 0.49.1 - July 24

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat. The release notes have comments enabled but it’s preferred if you use the former communication channels. Thanks.

Reporting Issues

Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.

Read on →

Home Assistant Podcast #3

Paulus Schoutsen Less than one minute reading time
  • Media
 Comments

The third episode of the Home Assistant Podcast is out. Paulus joins to talk about some stats and the release of 0.47 and Petar tells all about his Floorplan project for Home Assistant.

Listen online

Home Assistant is moving to Discord

Dale Higgs four minutes reading time
  • Community
 Comments

Communities grow, things change. We understand that some people don’t like change, and that is why we are trying to make our chat transition from Gitter to Discord as smooth as possible for everyone. Join us now with just a click!

Click Read on → to find out more about why we’re moving.

Read on →

0.48: Snips.ai, Shiftr.io and a massive History query speed up

Paulus Schoutsen 14 minutes reading time
  • Release-Notes
 Comments

It’s time for a great new release!

We’ve started the process of upgrading our frontend technology. If you notice something not working that did work before, please open an issue.

Pascal has added a new option to Home Assistant core to set a list of whitelisted folders that Home Assistant can read from. When a component allows to send files (like Telegram), it will only be allowed to send files from those directories. The only default whitelisted folder is the public <config>/www directory.

Z-Wave will, as announced in the last release, be defaulting to generate the new entity ids. More info in the blog post. You can still opt-in for the old style.

zwave:
  new_entity_ids: false

Big speed up in querying the history

Thanks to the work by @cmsimike in #8255 you’ll see a significant speed up when using the history view. In his local tests queries went from 1 minute to 90ms! ⚡️

Snips.ai component

Snips has contributed a component to integrate with their Snips.ai local voice assistant. This will allow you to hook a speaker and a microphone into your Raspberry Pi and make your own local Amazon Echo quickly. See the docs for further instructions.

Also a shoutout to @michaelarnauts for keeping an eye on our Docker build and once again reducing the file size 👍

Release 0.48.1 - July 5

New Platforms

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat. The release notes have comments enabled but it’s preferred if you use the former communication channels. Thanks.

Reporting Issues

Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.

Read on →

0.47: Python Scripts, Sesame Smart Lock, Gitter, Onvif cameras

Paulus Schoutsen 16 minutes reading time
  • Release-Notes
 Comments

In this release a ton of new stuff! And who doesn’t like new stuff? This release we’re passing the 700 integrations for Home Assistant. As of today we’re 1369 days old, which means that roughly every two days a new integration gets added!

Python Scripts

The biggest change is a new type of script component: Python scripts. This new component will allow you to write scripts to manipulate Home Assistant: call services, set states and fire events. Each Python script is made available as a service. Head over to the docs to see how to get started.

Updater

The updater has received a new opt-in option to let us know which components you use. This will allow us to focus development efforts on the components that are popular.

updater:
  include_used_components: true

And as a reminder. We will never share gathered data in a manner that can be used to identify anyone. We do plan on making aggregate data public soon. This will include total number of users and which hardware/software platform people use to run Home Assistant.

Z-Wave

Z-Wave is also getting a big update in this release. The confusing entity_ids will be on their way out. There is a zwave blog post that gives more detail, but the upgrade steps will be as follows:

  1. Run Home Assistant as normal and the old IDs will still be used.
  2. The new entity IDs will be shown in the more-info dialog for each entity. Check to make sure none of them will have conflicts once the new names are applied.
  3. Rename entities using the ui card as described in the blog post to avoid conflicts. Restart Home Assistant to observe the changes.
  4. Update all places mentioning IDs (groups, automation, customization, etc.) in configuration.yaml.
  5. Add new_entity_ids: true to your zwave config.
  6. Restart Home Assistant to run with new IDs.
  7. The old entity IDs will be available in the more info dialog to trace down any remaining errors.

Monkey Patching Python 3.6

Some people have noticed that running Home Assistant under Python 3.6 can lead to segfaults. It seems to be related to the earlier segfault issues that we experienced when we released the asyncio-based core. We thought that those issues would have been fixed when Python bug 26617 was resolved. Although we see less reports compared to the old bug, there are still users experiencing them (gdb stacktrace points at PyObject_GC_Del()).

Since Python 3.6, the Task and Future classes have been moved to C. This gives a nice speed boost but also prevents us from monkey patching the Task class to avoid the segfault. Ben Bangert managed to brew up another monkey patch to stop Python 3.6 from using the C classes, falling back to the Python versions instead. This allows us to apply the original monkey patch again.

Both monkey patches are now active by default starting version 0.47 to avoid our users experiencing segfaults. This comes at a cost of not being able to benefit from all optimizations that were introduced in Python 3.6.

To run without the monkey patch, start Home Assistant with HASS_NO_MONKEY=1 hass. We will further investigate this issue and try to fix it in a future version of Python.

Release 0.47.1 - June 21

New platforms

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat. The release notes have comments enabled but it’s preferred if you use the former communication channels. Thanks.

Reporting Issues

Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.

Read on →

ZWave Entity IDs

Adam Mills two minutes reading time
  • Technology
 Comments

ZWave entity_ids have long been a source of frustration in Home Assistant. The first problem we faced was that depending on the order of node discovery, entity_ids could be discovered with different names on each run. To solve this we added the node id as a suffix to the entity_id. This ensured that entity_ids were generated deterministically on each run, but additional suffixes had to be added to handle edge cases where there would otherwise be a conflict. The resulting entity_ids worked, but have been difficult to work with and makes ZWave a strange exception among other Home Assistant components.

Thanks to the awesome work of @turbokongen, a growing number of ZWave configuration options are now available from the new ZWave panel in the Home Assistant frontend. Among these new features is support for renaming of ZWave nodes and their underlying values. (These renames are persisted in zwcfg_*.xml) This is important, because these items are combined to form the Home Assistant entity name, which is used to generate the entity_id. Now that these options are available, ZWave users can rename nodes and values, influencing the entity_ids that are generated by Home Assistant.

Now that users are able to control these names, we will be making changes to how the entity_ids are generated for ZWave entities. The ZWave entity_ids are going to switch back to using the standard entity_id generation from Home Assistant core, based on the entity names. Moving forward, if there is a conflict when generating entity_ids, a suffix will be added, and it will be the responsibility of the user to rename their nodes and values to avoid the conflict. This is the same as any other platform in Home Assistant where two devices are discovered with the same name.

With the release of 0.47, this feature will be opt-in. Setting new_entity_ids: true under zwave: in your configuration.yaml will enable the new generation. After 0.48 this feature will become opt-out. From 0.48 onward, unless you’ve declared new_entity_ids: false you will switch to the new entity_id generation. At an undecided point in the future, the old entity_id generation will be removed completely.

I’m sure all ZWave users understand that the current entity_ids aren’t easy to use. They’re annoying to type in configuration.yaml, and break if a node needs to be re-included to the network. We know that breaking changes are painful, and so we’re doing what we can to roll this change out as smoothly as possible. The end result should be a dramatic simplification of most ZWave configurations. We hope that this change will ultimately make ZWave much easier to work with, and bring ZWave configuration just a little closer to the rest of the Home Assistant platforms.