Blog

0.16: Embedded MQTT broker, Uber, Yamaha receivers and Growl

Party people, 0.16 is here! The big thing with this release is that we have completely removed the barrier to get started by MQTT by being able to launch an embedded MQTT server: hbMQTT. Just add mqtt: to your config and a broker is launched and connected with Home Assistant.

Further in this release a bunch of cool new stuff, bug fixes and rewrites for the Vera and Tellstick component (see backward-incompatible changes section at bottom for this!).

Rock on.

Backward-incompatible changes

  • Automation: support for old deprecated config has been removed

  • Tellstick configuration has changed

tellstick:
  signal_repetitions: X
  • Vera configuration has changed
vera:
  vera_controller_url: http://192.168.1.161:3480/
  # Optional to exclude devices - this is a list of vera device ids
  exclude: [ 13, 14, 16, 20, 23, 72, 73, 74, 75, 76, 77, 78, 88, 89, 99]
  # Optional to import switches as lights - this is a list of vera device ids
  lights: [15, 17, 19, 21, 22, 24, 26, 43, 64, 70, 87]

0.15: Unforked Open Z-Wave, templated service calls, extended scene support and PEP257 compliance.

Two weeks has past so here is 0.15! We have been focussing a lot on quality. Making sure the system is more stable and reliable. I usually try to highlight one cool thing in the release notes but this release has 4 exciting announcements!

  • @fabaff has upgraded the codebase to follow the PEP257 documentation standard.
  • @partofthething has migrated us to use the main Python Open Z-Wave library instead of our forked version.
  • To make our automations more powerful, @persandstrom added the option to use templates to dynamically create service calls. This works for automation, Alexa, universal media player, template switch. Learn more.
  • @MartinHjelmare has upgraded our scene support to now support all built-in services and components.

Besides bug fixes, this release also brings:

# Example using templates for service and data in service call.
# Works for automation, Alexa, universal media player, template switch.
automation:
  - trigger:
      - platform: state
        entity_id: switch.bathroom
    action:
      service: >
        {% if is_state('switch.bathroom', 'on') %}
          switch.turn_on
        {% else %}
          switch.turn_off
        {% endif %}
      target:
        entity_id: switch.{{ states('input_select.is') }}

Backward-incompatible changes

  • Media Player: Attributes to call service play_media has been renamed to media_content_type and media_content_id, to match the corresponding media player state attributes. This change affects automations, scripts and scenes.

0.14: Steam, D-Link smart plugs and Neurio Energy Sensors

It’s been another two weeks which means it’s time for release: 0.14!

Camera feeds are now directly embedded in the frontend.

Backwards incompatible changes

  • Component: Simple Alarm has been removed. Still available in the cookbook.
  • Script: Turning on a script that is already on is now a no-op instead of skipping current delay.
  • Wemo switches now have to be set up via the main Wemo component
  • Command line platforms for switch, sensor and binary_sensor have been renamed to command_line.
  • The rfxtrx sensors entity ids will incur a one time change to move to a stable format. See the docs for more details.

Community Highlights

Home Assistant land has been busy and a lot of people have been creating awesome stuff.

Home automation demo by Part of the Thing

Haaska - Alexa Skill Adapter for Home Assistant

Haaska allows you to control lights, switches, and scenes exposed by your Home Assistant instance using an Amazon Echo. This is different from our own Alexa component because it will teach the Amazon Echo directly about the devices instead of teaching it to talk to Home Assistant. It will not allow you to use custom sentences but it will allow you to skip the ‘Ask Home Assistant’ part when giving commands:

  • “Alexa, set kitchen to twenty percent”
  • “Alexa, turn on evening scene”
  • “Alexa, turn off bedroom light”

Haaska on GitHub

Integrating Home Assistant with HomeKit

Contributor Maddox has created a plugin for HomeBridge, an open-source HomeKit bridge. This will allow you to control your home using Siri on your Apple devices. HomeBridge has recently restructured so you’ll have to install the plugin separately with the homebridge-homeassistant npm package.

Example config.json entry to load Home Assistant:

"platforms": [
    {
        "platform": "HomeAssistant",
        "name": "HomeAssistant",
        "host": "http://192.168.1.50:8123",
        "password": "xxx",
        "supported_types": ["light", "switch", "media_player", "scene"]
    }
]

HomeBridge on GitHub HomeBridge Home Assistant Plugin

Custom alarm system with Home Assistant

User thaijames describes in the Home Assistant forums how he has created his own NFC-based alarm system using Home Assistant, DIY components and Garfield dolls.

Hold your NFC tag against the belly of Garfield to unlock the alarm.


Multi-room audio with Snapcast, Mopidy, and Home Assistant

Would you like to listen to music in every room in your home, controlled from one source? Then multi-room audio is for you.

Multi-room audio can be achieved by having a computer attached to speakers in every room. On each computer, services run to play and/or control the audio. With this DIY approach, the kind of computer and speakers is very much up to you. It could be your desktop computer with attached powered speakers, your HTPC hooked up to your TV and receiver, a Raspberry Pi with Amp or DAC, or even an Android device.

You’ll need two key software packages, besides Home Assistant. The first is Mopidy, a music server that can play local files, or connect to streaming music services like Spotify. The second is Snapcast, which enables synchronized audio streaming across your network. Both can be integrated into Home Assistant. Each room audio device will run an instance of the Snapcast client, and optionally a Mopidy instance. Your server will run a special instance of Mopidy and the Snapcast server.

Finally, you also need a player to control Mopidy. Any MPD-compatible player will work, and there are several Mopidy-only web-based options available. On Android, Remotedy is particularly nice since you can access multiple Mopidy instances in one place.

Home Assistant will provide device status, and volume control for each room. If you want to play music in all your rooms (on all your clients), access the server instance of Mopidy. If you want to play music only in a specific room, access that specific Mopidy instance. If you’re using a web UI for Mopidy, you can add links to each instance in Home Assistant with the weblink component.

Read on →

0.13: Speedtest.net, Bloomsky, Splunk and Garage Doors

The focus of 0.13 was on test coverage, big cheers to @rmkraus for his hard work on this. I’m proud to announce that we’ve hit the 90% test coverage of the core + important components. A big milestone for the project.

Examples of the new [input_select] and weblink components.

Not only did we gain a lot of test coverage, we also attracted a lot of new developers that contributed a variety of components and platforms:


Classifying the Internet of Things

The core of home automation is knowing what’s going on. The faster we know about a state change, the better we can serve the user. If you want to have your lights to turn on when you arrive at home, it doesn’t help if it only knows about it after you’ve already opened the door and manually (!!) turned on the lights.

Each smart device consists of the ‘normal’ device and the piece that makes it ‘smart’: the connectivity. The connectivity part of a device can consists of either control, state or both.

State describes what a device is up to right now. For example, a light can be on with a red color and a medium brightness.

Control is about controlling the smart device by sending commands via an API. These commands can vary from configuring how a device works to mimicking how a user would interact with a device. A media player can allow skipping to the next track and a sensor could allow to configure its sensitivity or polling interval.

The Home Assistant APIs are setup to be as convenient as possible. However, a network is always as weak as it’s weakest link. In our case these are the integrations. Take for example controlling a light that does not report state. The only state Home Assistant can report on after sending a command is the assumed state: what do we expect the state of the light to be if the command worked.

We want our users to get the best home automation experience out there and this starts with making sure they have devices that work well with Home Assistant. That’s why we will start applying the following classifiers to our integrations:

Classifier Description
Assumed State We are unable to get the state of the device. Best we can do is to assume the state based on our last command.
Cloud Polling Integration of this device happens via the cloud and requires an active internet connection. Polling the state means that an update might be noticed later.
Cloud Push Integration of this device happens via the cloud and requires an active internet connection. Home Assistant will be notified as soon as a new state is available.
Local Polling Offers direct communication with device. Polling the state means that an update might be noticed later.
Local Push Offers direct communication with device. Home Assistant will be notified as soon as a new state is available.

The background to how we got to these classifiers can be read after the break.

Read on →

Smarter SmartThings with MQTT and Home Assistant

This is a guest post by Home Assistant users Jeremiah Wuenschel and St. John Johnson.

So you own a SmartThings Hub. You probably bought it when you were looking to get into the whole Home Automation hobby because it worked with pretty much everything and offered you the ability to automate anything. After a week of ownership, you realized that building dashboards and automating required writing way more Groovy then you expected. Then one day you were browsing reddit and discovered the amazingness that is Home Assistant! A solution that offered dashboards, graphs, working support for Nest, and REAL EASY automation!

You spent your weekend getting everything set up, showing it off to your significant other, but in the end you got stumped when it came to integrating with all your existing SmartThings toys. What do I do now? Should I buy another hub? Should I just buy a Z-Wave stick?

That’s where we came in. We wanted a solution that can bridge the awesomeness of Home Assistant with the SmartThings hub that works with almost everything.

Read on →

0.12: Insteon, LIFX, Twitter and Zigbee

Another sprint has come to an end and it seems that we have not slowed down a single bit 🚀. 0.12 is full of new components, platforms and organizational additions.

I would like to give a shout out to Greg Dowling (@pavoni) as every release includes new work from him. He is constantly adding support for new platforms or improving the reliability of existing components and platforms. Keep up the good work!

This release includes a very frequent requested feature: the ability to organize entities in different tabs in the frontend. See the demo to see this in action and read more in the group documentation how to get started.

Example of the new views in the frontend. Learn more.

Backwards incompatible changes

  • Nest config has moved from thermostat to the Nest component.
  • Entity IDs for Z-Wave devices are now generated in a deterministic way causing all IDs to change starting this release. This is a one time change. (Changed again in 0.31)

Perfect Home Automation

People often ask me about my vision for Home Assistant. Before I can describe where I want to go with Home Assistant, I should first talk about how home automation would look in my ideal world. This will be the aim of this post. I’m not going to focus on protocols, networks or specific hubs. That’s all implementation details. Instead, this post will focus on what is most important: the interaction between the users and their home.

You should not have to adapt to technology.

When people start using home automation, they always experience home control first: being able to control devices in new ways using a phone or computer. They believe the future is now and their app will be their remote for their lives. They only focus on what they are getting, not on what they are losing. You install some light bulbs and all of a sudden you are no longer able to use the light switches. You’ll arrive at home at night and have to pull out your phone, open the app, let it connect and finally you’ll be able to turn on the light. All while turning the light on could have been a switch away.

Yes, you can solve this with presence detection. What if your phone runs out of battery? You’ll have to resort to the switch again.

If you find that using your new home devices is cumbersome, the promise of home automation technology has failed you. Your lights should work with both a switch (or button) at the entrance of your room and via presence detection. Honestly, there are hardly any valid use cases for being able to control lights from your phone except for showing off.

Read on →