<![CDATA[Home Assistant]]> 2018-02-20T00:10:30+00:00 https://home-assistant.io/ Octopress <![CDATA[Cloud Update]]> 2018-02-19T01:00:00+00:00 https://home-assistant.io/blog/2018/02/19/cloud-update We’re happy to announce that the Home Assistant skill is now available in Canada, UK, Germany, India and Australia! Check it out in the Amazon Alexa Skill store.

In the meanwhile, we have also been working on the Google Assistant integration. We passed the first verification and are now working with Google to do the final verification. Stay tuned!

In less than 2 weeks the open beta is about to expire. We’re still working on setting up the company and payment system so we can start accepting payments. Until we do, Home Assistant Cloud will remain free.

]]> <![CDATA[0.63: Entity Registry, SQL Sensor, Mercedes cars]]> 2018-02-10T01:00:00+00:00 https://home-assistant.io/blog/2018/02/10/release-63

Date set for dropping Python 3.4 support

As announced in October, we’re going to drop Python 3.4 support in 2018. We’ve now decided that in two releases, 0.65, the minimum Python version that will be supported is bumped to 3.5.3. This won’t impact most users. You are already fine if you’re using Hass.io, the latest Debian stable (Stretch) or a derivative of that (Raspbian, Ubuntu).

Entity Registry

This release introduces the entity registry. The entity registry allows integrations to reserve entity IDs. This means that we’ll automatically grant an entity ID to a device. It’s reserved so that no other device will ever get that entity ID. It also means that as a user, you will be able to customize the entity IDs for these devices.

For an integration to leverage the entity registry, it needs to define a unique ID for each of their entities. A unique ID is something that we can uniquely identify the device and that is not configurable. So a serial number and mac address are ok, IP addresses or names are not.

Examples of integrations that have unique IDs defined in this release are Z-Wave, Hue, Nest, LIFX, Sonos, Apple TV.

To update the entity ID that will be assigned to your device, update <config>/entity_registry.yaml and restart Home Assistant (reloading on the fly is planned for a future release).

The entity registry will assign an entity ID the first time that a device is seen. This should be the same entity ID as it always was before. If this is not the case, update the registration entity to change it back to the old entity ID.

We’re planning a lot of cool stuff around the entity registry. Stay tuned!

New Platforms

Release 0.63.1 - February 12

Release 0.63.2 - February 14

Release 0.63.3 - February 17

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.

Breaking Changes

  • updated sensor name (@philklei - #12084) (sensor.tahoma docs) (breaking change)
  • Originally Canary camera is added per location and only displays an image that was captured due to motion. Now it is per device (each location can have multiple devices) with live stream support. (@snjoetw - #11949) (canary docs) (camera.canary docs) (breaking change)
  • Avoid influxdb filling connection pool: The influxdb retry_queue_limit configuration variable no longer has any effect and can be removed. (@amelchio - #12182) (influxdb docs) (breaking change)
  • Some spelling mistakes in default entity names have been fixed in (@OttoWinter - #12041). This is causing these entity_id changes:
    • Seven segments display: image_processing.seven_segement_ocr_[...] → image_processing.seven_segment_ocr_[...]
    • Rain Bird Switch: switch.sprinker_[...] → switch.sprinkler_[...]
    • OpenEVSE Sensor: sensor.ambient_termperature → sensor.ambient_temperature
    • Fido: sensor.[...]_internaltional_remaining → sensor.[...]_international remaining
  • From version 0.64, Home Assistant will by default purge recorded state history that is older than 10 days. If you want to keep your recorded data for longer than that, you must configure the number of days to retain: 
      recorder:
    purge_keep_days: 30

    If you want to keep the previous default of never deleting history, use this configuration:

      recorder:
    purge_interval: 0

    (@amelchio - #11976)

  • Fix duplicate entity_ids in System Monitor (@fanaticDavid - #12124) (sensor.systemmonitor docs) (breaking change)

    Resource Old Entity ID New Entity ID
    disk_use sensor.disk_used sensor.disk_use
    disk_use_percent sensor.disk_used sensor.disk_use_percent
    load_15m sensor.average_load_15m sensor.load_15m
    load_1m sensor.average_load_1m sensor.load_1m
    load_5m sensor.average_load_5m sensor.load_5m
    memory_free sensor.ram_available sensor.memory_free
    memory_use sensor.ram_used sensor.memory_use
    memory_use_percent sensor.ram_used sensor.memory_use_percent
    network_in sensor.received sensor.network_in
    network_out sensor.sent sensor.network_out
    packets_in sensor.packets_received sensor.packets_in
    packets_out sensor.packets_sent sensor.packets_out
    processor_use sensor.cpu_used sensor.processor_use
    swap_use sensor.swap_used sensor.swap_use
    swap_use_percent sensor.swap_used sensor.swap_use_percent
  • Developers only: Following EntityComponent methods have been removed: extract_from_service, async_update_group, async_reset, prepare_reload (@balloob - #12237) (breaking change)

All changes

]]> <![CDATA[Disabling Disqus comments]]> 2018-02-09T01:00:00+00:00 https://home-assistant.io/blog/2018/02/09/disabling-disqus Last week, starting with the release of Home Assistant 0.62, we switched to using our community forums for comments on our blog posts. By doing so, people are able to use their existing Home Assistant community accounts to comment on our blog posts and engage with one another. It has been easier for our users to stay in the loop with one less channel to keep track off.

Previously, we were using the free version of Disqus to power comments on our blog. After the switch, to preserve the old comments, we decided to keep Disqus active on the older blog post pages. However, today we decided to turn them off.

Today Disqus changed their advertisement strategy and turned on irrelevant graphical advertisement above and below the comment thread (screenshot). On a phone, it took so much screen real estate that it filled the whole page with an advertisement for weight loss milk. Previously, Disqus had advertisements in an unobtrusive way: showing suggested content a visitor might also be interesed in.

Today we have switched all blog posts to the new commenting system and are no longer serving Disqus comments. We are exploring ways to restore the old comments.

]]> <![CDATA[0.62: MyChevy, Iota and Venstar Thermostat]]> 2018-01-27T01:00:00+00:00 https://home-assistant.io/blog/2018/01/27/release-62

Second release of the year and it’s buzzing on GitHub. This release we had 70 people contribute code. We’ve also managed to finally get our PR count below a 100 open PRs again. A lot of cool stuff still waiting to make it to a future Home Assistant release.

I want to give a shout out to @martinhjelmare and @frenck. Martin is doing an amazing job at code reviews and Franck has been kicking ass with Hass.io add-ons and keeping track of our documentation PRs. Thanks for this amazing work!

MyChevy

With this new integration by @sdague you are able to keep an eye on your Chevy Bolt EV. Keep track if your car is plugged in, the battery stats and the range it is currently capable of driving. Hip!

New Platforms

Release 0.62.1 - January 30

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.

Breaking Changes

  • Tahoma platform will get new entity IDs (@glpatcern - #11547) (tahoma docs) (cover.tahoma docs) (breaking change)
  • Mold indicator: attribute names no longer include spaces or periods (@olskar - #11694) (sensor.mold_indicator docs) (breaking change)
  • Custom component devs only: EntityComponent.add_entity(entity) and EntityComponent.async_add_entity(entity) have been removed. Use EntityComponent.add_entities([entity]) and EntityComponent.async_add_entities([entity]) instead. Also EntityComponent.entities is no longer a dictionary but instead an iterable. Use EntityComponent.get_entity(entity_id) to get entity by id. (@balloob - #11691) (breaking change)

All changes

]]> <![CDATA[Clarification about Emulated Hue]]> 2018-01-21T01:00:00+00:00 https://home-assistant.io/blog/2018/01/21/clarification-emulated-hue There are some misconceptions floating around about the future of the Emulated Hue component and I would like to set the record straight. The Emulated Hue component is not going to be removed nor will we ever remove any functionality from Home Assistant to push you to support the Home Assistant project by subscribing to the Community Support Package.

The reason people are concerned about the future of the Emulated Hue component is because of a poor choice of words in a deprecation message. This message was introduced a year ago when we deprecated the config option type: alexa for the Emulated Hue component:

Alexa type is deprecated and will be removed in a future version

That config option should never have been called type: alexa but instead have been called mode: legacy. If you think about it, why would emulating something even have different modes it emulates based on the consumer? That means that one of the two emulation modes is incorrect.

The old implementation was not 100% correct. It was correct enough to work with Alexa (the original target) but not with Google Home. When fixing Emulated Hue we added type: alexa to re-enable the old implementation so that people did not have to go through the trouble to re-add their Alexa devices. The option was deprecated to indicate that we would remove the incorrect emulation in the future. However, we forgot about actually following through with that.

The mistake we made was calling the correct mode google_home although it had nothing to do with Google Home. It confused people and they kept adding type: alexa to their configuration, triggering the deprecation warning.

The warning will be updated starting Home Assistant 0.62 and will also include a link to this blog post.

More info:

]]> <![CDATA[0.61: Coinbase, Discogs, iGlo, Sochain]]> 2018-01-14T18:00:00+00:00 https://home-assistant.io/blog/2018/01/14/release-61

Almost a 100 contributors to this release 🎉 That’s what you get when you skip a release. It’s a little late but “Happy New Year” and welcome to 0.61 the first release 2018.

This release contain some breaking changes. Please make sure that you check the section below if you are running into trouble.

Assistant configs

We made a mistake in the foundation of both the Google Assistant and Alexa integrations: they were storing their config inside customize. This is not the right place and we moved them to be under the components itself. See the breaking changes section on how to migrate.

Hass.io updates

@pvizeli has made it easier to create and restore snapshots for Hass.io by calling the new services. This way it will be easy to automate the creation of a snapshot at night. The updater has also been fixed and will now report on new versions of Hass.io that are available.

Improved loading speed

@amelchio has made startup of Home Assistant even faster. All service descriptions are now loaded only when needed by the frontend instead of during startup. This did mean that we had to enforce our service convention. We found a few platforms that didn’t follow this and they have been updated:

todoist.new_task -> calendar.todoist_new_task

snapcast.snapcast_snapshot -> media_player.snapcast_snapshot
snapcast.snapcast_restore -> media_player.snapcast_restore

mopar.remote_command -> sensor.mopar_remote_command

broadlink.learn_command_192_168_0_107 -> switch.broadlink_learn_command_192_168_0_107
broadlink.send_packet_192_168_0_107 -> switch.broadlink_send_packet_192_168_0_107

New Platforms

Release 0.61.1 - January 16

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.

Breaking Changes

  • Extend Threshold binary sensor to support ranges. This means that you can now set up and lower. (@DanNixon - #11110) (binary_sensor.threshold docs) (breaking change)
  • The Steam game platform contains changes:
    • game attribute no longer set in device_state_attributes if no game is currently being played as the string “None” is no longer passed if no current game is being played, instead the game attribute is not present.
    • States now use lower snake case.
    • The “Play” and “Trade” states has been renamed to “looking_to_play” and “looking_to_trade”. (@frwickst - #11182) (sensor.steam_online docs) (breaking change)
  • The tile platform now shows only active Tiles by default; to show all Tiles, including expired/inactive ones, show_inactive must be True. The following state attributes have been removed: last_seen and last_updated. (@bachya - #11172) (device_tracker.tile docs) (breaking change)
  • The hidden_string feature has been removed from the isy994 component. Previously, this allowed entities to be “hidden” in Home Assistant if a configured string was present in an ISY device’s name or folder path. This was removed because hiding devices is now done via the customization feature. Note however, that this feature was replaced by a new ignore_string config option, which will now cause Home Assistant to completely ignore devices with the matching string so that they will not be imported as a Home Assistant device at all. This can be helpful if you have nodes in the ISY that aren’t useful at all in Hass (IR transmitter nodes are a good example.) (@OverloadUT - #11243) (isy994 docs) (binary_sensor.isy994 docs) (cover.isy994 docs) (fan.isy994 docs) (light.isy994 docs) (lock.isy994 docs) (sensor.isy994 docs) (switch.isy994 docs) (breaking change)
  • The egardia alarm panel platform no longer a need the users to run a separate Egardiaserver component. It can now also run on HASS.io. (@jeroenterheerdt - #11344) (alarm_control_panel.egardia docs) (breaking change)
  • The binary sensor platform of the DoorBird integration has been deleted, so remove DoorBird from your binary_sensor configuration. Instead, set the doorbell_events option of the doorbird component to True. The last_visitor option has been removed from the camera component, as it is now always added as an entity. (@Klikini - #11193) (camera.doorbird docs) (breaking change)
  • The following attributes of the TP-Link switch and light platform have been renamed:
    • Light: current_consumption -> current_power_w, daily_consumption -> daily_energy_kwh and monthly_consumption -> monthly_energy_kwh
    • Switch: current -> current_a, current_consumption -> current_power_w, total_consumption -> total_energy_kwh and daily_consumption -> today_energy_kwh (@DanNixon - #10979) (light.tplink docs) (switch.tplink docs) (breaking change)
  • Move IMAP Email Content body to an attribute (@notoriousbdg - #11096) (sensor.imap_email_content docs) (breaking change)
  • Automations which were using state that was returning target_temperature of the netatmo climate platform needs an update. (@ciotlosm - #11345) (climate.netatmo docs) (breaking change)
  • The default availability payloads for the MQTT switch platform have changed from “ON” and “OFF” to “online” and “offline” (in order to match the majority of MQTT platforms that already supported availability reporting). (@DanNixon - #11336) (breaking change)

  • Customizations for how entities are exposed to Alexa are no longer set via customize. Instead they are set via the configuration of the cloud component:

      cloud:
    alexa:
      entity_config:
        switch.kitchen:
          name: 'Name for Alexa'
          description: 'Description for Alexa'
          display_categories: 'LIGHT'

    (@balloob - #11461) (cloud docs) (alexa.smart_home docs) (breaking change)

  • The extension of the alpha_vantage requires an update of the configuration as now are exchange data available as well. (@ChristianKuehnel - #11427) (sensor.alpha_vantage docs) (breaking change)
  • The prometheus component now supports pushing all sensors and fixes wrong metrics. If may require that you update your configuration. (@michaelkuty - #11159) (prometheus docs) (breaking change)
  • Insteon local devices will now use their address as the entity_id and name. The friendly name can be customized using the standard customization configuration. (@camrun91 - #11088) (insteon_local docs) (fan.insteon_local docs) (light.insteon_local docs) (switch.insteon_local docs) (breaking change)

  • Google Assistant is no longer configured via customize but instead has its configuration under the google_assistant entry in your configuration.yaml. The attributes will no longer have to be prefixed with google_assistant_ either.

    Old option New option
    google_assistant expose
    aliases aliases
    google_assistant_name name
    google_assistant_type type

    Before:

      homeassistant:
    customize:
      switch.kitchen:
        google_assistant: false
        google_assistant_name: nice lights
        google_assistant_type: light
        aliases:
          - roof lights

  google_assistant:

    After:

      google_assistant:
    entity_config:
      switch.kitchen:
        expose: false
        alias: roof lights
        name: nice lights
        type: light

    (@balloob - #11499) (cloud docs) (google_assistant docs) (breaking change)

  • The climate.set_aux_heat service is no longer available for the Sensibo climate platform. Now call climate.turn_on or climate.turn_off. (@andrey-git - #11579) (climate.sensibo docs) (breaking change)

  • Release 0.61.0 introduced a lazy service loading strategy that relied on all components and platforms following our naming convention. After the release we realized that not all services did, which have been addressed by this fix. This results in certain services changing names:

     todoist.new_task -> calendar.todoist_new_task

 snapcast.snapcast_snapshot -> media_player.snapcast_snapshot
 snapcast.snapcast_restore -> media_player.snapcast_restore

 mopar.remote_command -> sensor.mopar_remote_command

 broadlink.learn_command_192_168_0_107 -> switch.broadlink_learn_command_192_168_0_107
 broadlink.send_packet_192_168_0_107 -> switch.broadlink_send_packet_192_168_0_107

    (@amelchio - #11677) (calendar.todoist docs) (media_player.snapcast docs) (media_player.soundtouch docs) (sensor.mopar docs) (switch.broadlink docs) (switch.scsgate docs) (breaking change)

All changes

]]> <![CDATA[Thank You]]> 2017-12-28T22:00:00+00:00 https://home-assistant.io/blog/2017/12/28/thank-you 2017 is almost over and this means it’s time to do a little recap of our 2017. This was a great year for Home Assistant. Again, we were able to stick to our bi-weekly release cycle. There were 25 releases over the year and each release included the work of around 60 contributors.

We got 10.000 stars on GitHub, reached 10.000 commits in the main repo (over 4300 were made in 2017), got a Thomas-Krenn award, participated in Hacktoberfest, we have now almost 1000 integrations (the exact number is 938), we moved to Discord and we are up to over 2 million pageviews per month on our forum. Beside that we announced the Home Assistant cloud and have regular Home Assistant Podcasts.

We also do not want to forget to mention Hass.io and all the great Hass.io add-ons.

Uff, what a year…Thank you, dear community for being so helpful, supportive and awesome 🙇.

A very big thanks goes out to the developers of the Python language and all the open source libraries and tools that Home Assistant depends on. You are the foundation for our success and all of you can be proud of yourself.

We would also like to thanks all the companies that offer their services for free to open source projects. Without these we would not be able to operate at our speed or scale. Thank you GitHub, TravisCI, CloudFlare, Discord and Discourse!

Some of us are taking a break and spending some quality time with family and loved ones.

Stay tuned for more Home Assistant awesomeness in 2018. We will keep the pace but first: Happy New Year!

– Home Assistant Organization

]]> <![CDATA[Introducing Home Assistant Cloud]]> 2017-12-17T03:00:00+00:00 https://home-assistant.io/blog/2017/12/17/introducing-home-assistant-cloud Today we’re introducing the next step in the Home Assistant saga: the Home Assistant Cloud. The goal of the Home Assistant Cloud is to bridge the gap between your local Home Assistant instance and services in the cloud while delivering the maximum possible security and privacy.

The first service that is supported via the Home Assistant Cloud is the Amazon Alexa Smart Home skill. This integration will allow you to control all your devices in Home Assistant via Amazon Alexa. You will be able to say “Alexa, turn on the kitchen lights” and your local Home Assistant will turn on the lights. Because Alexa talks to Home Assistant, it doesn’t matter what kind of lights they are! Anything that is linked to Home Assistant will work. IKEA lights, a 10 year old X10 switch or something you’ve made yourself. As long as Home Assistant can control it, you can control it via Alexa.

We have designed the Home Assistant Cloud with security in mind. When you activate the new Cloud component, your instance will create a secure connection to the Home Assistant Cloud. There is no need for any further configuration or to expose your instance to the internet.

Integrations like Alexa will deliver messages to our cloud which we will forward to your local instance for processing. We just forward the response back to Alexa. This means that we do not have to store the state of your house in our cloud, we’re just the messenger!

We are making the beta of the Home Assistant Cloud publicly available today. During the beta period the Home Assistant Cloud will be free to use. We are currently planning to run a beta till March 1, 2018 0:00 UTC. Once the beta ends, the Home Assistant Cloud will be part of our Community Support package which will run at $5 USD/month.

By subscribing to the Community Support package you will show your support for the Home Assistant organization, its projects and its community. It will help fund development, cover our operating costs and gives you access to use Home Assistant Cloud.

So if you ever felt like donating money to support the development of Home Assistant and Hass.io: sign up for the Home Assistant Cloud!

Why not take donations?

With donations you have to convince people to keep donating and it will be hard to plan around the amount of available money. The biggest concern is what do you do when there is not enough money. We could shut down the servers or again depend on the wallets of our developers. We could run Wikipedia style advertisements for donating, but those are even more annoying than running advertisements.

Getting started

Upgrade Home Assistant to 0.60 and enable the cloud and config components:

# Example configuration.yaml entry
cloud:
config:

Now restart Home Assistant and navigate to the configuration panel. It will offer a new cloud section. Here you can create an account and login. Once logged in, your instance will connect to the cloud.

The next step is to configure Alexa. This can be done by enabling the Home Assistant skill for Alexa and link your Home Assistant cloud account.

Once you’re done, ask Alexa to discover devices (“Alexa, discover devices”) and you are all set to control them: “Alexa, turn on <device name>”.

See the Cloud component configuration to learn how to filter which devices get exposed to Alexa.

FAQ

Last updated: December 26, 2017

I thought the Home Assistant crew didn’t like the cloud?

You are right, we don’t! The Home Assistant Cloud is not an alternative to running your local Home Assistant instance. All control and automations are still running locally.

Instead, the Home Assistant Cloud is an extension of your local instance. It allows to communicate with companies that force us to communicate via a public available cloud endpoint like Amazon Alexa and Google Assistant.

Home Assistant Cloud is only used to route the messages to your local Home Assistant instance. All messages are processed locally.

(Some people have suggested we rename to Home Assistant Bridge to avoid this confusion)

Will Home Assistant and Hass.io remain open source?

Yes. Yes. Yes! Home Assistant is the work of hundreds of developers all working together in creating something amazing. The only thing that will require a subscription is the optional cloud functionality.

Where is the source code for the Alexa skill?

All messages are processed locally and so the Alexa skill code is part of the Home Assistant code. The Home Assistant Cloud only routes the messages to your local Home Assistant instance. This means that you can audit the source code to check all the things that the cloud can do:

What other features will come to the cloud?

We have a lot of ideas! We are not going to make any promises but here are some things that we’re looking into:

  • Google Home / Google Assistant Smart Home skill
  • Allow easy linking of other cloud services to Home Assistant. No more local juggling with OAuth flows. For example, link your Fitbit account and the Fitbit component will show up in Home Assistant.
  • Encrypted backups of your Hass.io data
  • Text to speech powered by AWS Polly
  • Generic HTTP cloud endpoint for people to send messages to their local instance. This will allow people to build applications on top of the Home Assistant cloud.
  • IFTTT integration
  • Alexa shopping list integration

What countries are supported at launch?

Only US is currently supported. The reason for this limitation is that we need to do extra steps and certifications for each country’s Alexa skill. This is in progress but the timeline depends on Amazon.

How is the connection made to the cloud?

The connection is made using a WebSocket connection over HTTPS. See the source here.

I think that the price is too high for what I get.

The Home Assistant Cloud functionality is a perk for becoming a supporter of the Home Assistant project. As a supporter you will help fund development, cover our operating costs and gives you access to use Home Assistant Cloud. You are not paying to just maintain the cloud servers.

The perks offered for being a supporter will also extend over time, as noted in this answer.

What will the Home Assistant organization do with the funds ?

The plan is to hire developers to work fulltime on Home Assistant. We have grown a lot in the last 4 years and the work load is pushing the limits of what our core developers can do. Open source burn out is very common (1, 2) and we want to avoid this by moving most organization and release chores to a paid position.

For more background on these topics, check out HASS Podcast 15.

]]> <![CDATA[0.60: Beckhoff/TwinCAT, WebDav, Gearbest, iAlarm]]> 2017-12-17T02:00:00+00:00 https://home-assistant.io/blog/2017/12/17/release-60

The biggest change for 0.60 will be covered in a separate blog post. Thus, we will keep it short here. Just one thing: This is the last release in 2017. We will be back to our bi-weekly release cycle in 2018.

A big “Thank you” to all people who supported us to make this release possible.

TwinCAT

With the brand-new ADS (automation device specification) component by @stlehmann allows you to hook Home Assistant into this fieldbus independent interface which is often used between Beckhoff devices running with TwinCAT.

WebDav calendar

Thanks to @maxlaverse Home Assistant support now WebDav calendars.

Tracking prices

With the new gearbest sensor there is now an additional sensor available to track the price of a product.

Financial details

Yahoo! has discontinued their financial service. To fill this gap we have now the alpha_vantage sensor which is intruded in this release and allows you to monitor the stock market.

New Platforms

Release 0.60.1 - January 6

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.

Breaking Changes

All changes

]]> <![CDATA[0.59: Order pizza, Entity Picker, Color Wheel]]> 2017-12-03T02:00:00+00:00 https://home-assistant.io/blog/2017/12/03/release-59

We are proud to announce the availability of Home Assistant 0.59. To keep you in the loop: This is the second last release in 2017. We have stuck to our bi-weekly release cycle for another year but we decided that we will take a little break between Christmas and New Year.

Dominos Pizza platform

With the Dominos Pizza integration made by @wardcraigj your home is now taking care that you don’t starve. In combination with a Skybell or a DoorBird you will know exactly when the pizza is in front of your door.

Color picker

@NovapaX created a new color picker. While dragging the color badge with your finger, a badge will appear above your finger so you can see the current color.

Screenshot of the color wheel. Screenshot of the color wheel.

Shopping list tweaks

@balloob has refreshed the shopping list UI to make it more usable. It’s now possible to add items by typing, instead of just voice. Also editing has been made easier.

Entity picker

@balloob improved the way if you want to pick an entity. In the automation editor, the script editor and the service section of the Developer Tools it’s much easier to identify the right one! The automation editor will only suggest relevant entities.

Screenshot of the Entity Picker. Screenshot of the of the Entity Picker.

Hass.io Add-ons

If you follow our twitter feed then you may already know that @frenck spent some time to bring new stuff to the Community Hass.io Add-ons repository.

New Platforms

Release 0.59.1 - December 4

Release 0.59.2 - December 6

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.

Breaking Changes

All changes

]]> <![CDATA[Set up Hass.io on top of a virtual machine]]> 2017-11-29T06:00:00+00:00 https://home-assistant.io/blog/2017/11/29/hassio-virtual-machine The images for the Raspberry Pi family and the Intel NUC are an easy way to get started with Hass.io. For a test or if you have a system which is already hosting virtual machines then the Hass.io installer is an option to use Hass.io in a virtualized environment. In this guide the host is a Fedora 27 system with libvirt support and the guest will be running Debian 9. Hass.io will be installed on the guest.

Assuming that you already have setup libvirtd. You might need to install virt-builder and virt-viewer additionally.

$ sudo dnf -y install libguestfs-tools-c virt-install virt-viewer

We will create a virtual machine with Debian 9 and a 10 GB disk image in the QCOW format. Use $ virt-builder --list to get an overview about what’s operating systems are available if you prefer to use a different system.

$ sudo virt-builder debian-9 \
    --output /var/lib/libvirt/images/hassio.img \
    --format qcow2 \
    --size 10G \
    --root-password password:test123 \
    --hostname hassio \
    --firstboot-command "dpkg-reconfigure openssh-server"
[...]
[ 147.6] Finishing off
                   Output file: /var/lib/libvirt/images/hassio.img
                   Output size: 10.0G
                 Output format: qcow2
            Total usable space: 9.3G
                    Free space: 8.1G (87%)

Now, we are making our new virtual machine available for libvirtd. If you get an error that the OS is unknown, use $ osinfo-query os to get the name to use with --os-variant. To access the virtual machine is connected to the bridge bridge0.

$ sudo virt-install --name hassio --import --ram 1024 \
     --os-variant debian9 -w bridge=bridge0 \
     --autostart --disk /var/lib/libvirt/images/hassio.img

Hass.io virtual machine in Virtual Machine Manager

Depending on your preferences you can use the Virtual Machine Manager (virt-manager) or virsh to manage the created virtual machine. Log in and create an user with # useradd ha and set a password with # passwd ha. We will need that user to make a SSH connection to the virtual machine.

Log in as ha with the given password. If your are using the default network of libvirtd then the DHCP range is defined in /var/lib/libvirt/dnsmasq/default.conf. In this guide the virtual machine is present at 192.168.0.109.

$ ssh ha@192.168.0.109
ha@192.168.0.109's password: 
Linux hassio 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64
[...]
$

Install the requirements after you switch the user to root.

$ su
Password: 
root@hassio:/home/ha# 
root@hassio:/home/ha# apt-get update
root@hassio:/home/ha# apt-get install bash socat jq curl avahi-daemon \
    apt-transport-https ca-certificates

We want the latest Docker release. This requires additional steps to set it up as unlike other distributions Debian is lacking behind with current packages.

root@hassio:/home/ha# wget https://download.docker.com/linux/debian/gpg 
root@hassio:/home/ha# apt-key add gpg
OK
root@hassio:/home/ha# echo "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | tee -a /etc/apt/sources.list.d/docker.list
root@hassio:/home/ha# apt-get update

Now, it’s possible to install a current release of Docker.

root@hassio:/home/ha# apt-get -y install docker-ce

Start docker and enable it.

root@hassio:/home/ha# systemctl start docker && systemctl enable docker

An installation script will take care about the setup of all moving parts.

root@hassio:/home/ha# curl -sL https://raw.githubusercontent.com/home-assistant/hassio-build/master/install/hassio_install | bash -
[INFO] Install supervisor docker
[INFO] Install generic HostControl
[INFO] Install startup scripts
[INFO] Init systemd
Created symlink /etc/systemd/system/multi-user.target.wants/hassio-supervisor.service → /etc/systemd/system/hassio-supervisor.service.
[INFO] Start services

If it’s done, then there will be two new containers.

root@hassio:/home/ha# docker ps
CONTAINER ID        IMAGE                                    COMMAND                  CREATED             STATUS              PORTS               NAMES
ada5bbfc74f0        homeassistant/qemux86-64-homeassistant   "/usr/bin/entry.sh..."   4 minutes ago       Up 4 minutes                            homeassistant
5954ac452ffc        homeassistant/amd64-hassio-supervisor    "/usr/bin/entry.sh..."   7 minutes ago       Up 7 minutes                            hassio_supervisor

After a connection to the container which is containing Home Assistant is made, you will see the log output.

root@hassio:/home/ha# docker attach --sig-proxy=false ada5bbfc74f0
2017-11-28 19:24:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sun.sun, old_state=<state sun.sun=below_horizon; next_dawn=2017-11-29T06:17:58+00:00,...

For further details about the container, inspect can help.

root@hassio:/home/ha# docker inspect bb32b525d1ad
[...]
            "OnBuild": null,
            "Labels": {
                "io.hass.arch": "amd64",
                "io.hass.machine": "qemux86-64",
                "io.hass.type": "homeassistant",
                "io.hass.version": "0.58.1"
            }
[...]

Hass.io is now ready. The frontend is available at http://192.168.0.109:8123. Yes, the IP address is the one of the guest.

Hass.io overview

Keep in mind that there are limitations with this approach. Not all add-ons will work and some don’t make sense to use as the hardware is not present. E.g., use the SSH community add-on instead of the default SSH add-on.

]]> <![CDATA[0.58: More translations, faster frontend, system log]]> 2017-11-18T04:00:00+00:00 https://home-assistant.io/blog/2017/11/18/release-58

The Hass.io release of 0.58 will be delayed by a couple of days because Pascal is moving this weekend.

Translation update

Translations are up and running in full speed. Shortly after the last release we got our translation pipeline figured out. @armills and @c727 are doing an amazing job managing this project. We’ve doubled the number of supported languages to 42 and the amount of keys to translate went from 8 to 130. Our translators are on top of their game and 79% is already translated.

Talking about our translators, we now have 445 people with an account to help with translations. Not bad for 3 weeks!

And because more translations is more better, @robbiet480 has added the iOS app to Lokalise, our translation management platform. The iOS app is currently supported in 7 different languages.

Learn more about how to help with translations

Frontend improvements continue

Thanks to @Andrey-git we now are able to serve the frontend in modern JavaScript. Leveraging modern JavaScript makes the frontend faster to load and run. For now it’s opt-in but we’re looking into making it opt-out in the future. The ES5 version of the frontend will remain available for older devices.

To try it once, add ?latest to your Home Assistant bookmark. To make it the default on your installation, update your config to look like this:

frontend:
  javascript_version: latest

For Custom UI users: your custom UI will need to be updated before it can work with the new version of the frontend.

System log enhanced

Our about screen that shows the error logs has gained a nice upgrade by @postlund. Now the 50 latest exceptions will be displayed with the option to get more information.

Screenshot of the about screen showing the system log. Screenshot of the about screen showing the system log.

New Platforms

Release 0.58.1 - November 21

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.

Breaking Changes

  • hass.states.is_state_attr(entity_id, attribute, value) has been removed. The template version still exists. Unused method parameter wait has been removed from hass.bus.async_fire (@balloob - #10305) (breaking change)
  • Refactor Neato botvac components as a vacuum (@jabesq - #9946) (neato docs) (switch.neato docs) (vacuum.neato docs) (breaking change) (new-platform)
  • Lutron released a firmware updated for the Caseta system which removed our ability to connect to and control the bridge device over SSH, breaking compatibility with pylutron_caseta and Home Assistant. Component has been updated to work again, please see the docs on how to set it up. (@mdonoughe - #10286) (lutron_caseta docs) (breaking change)

All changes

]]> <![CDATA[Secure remote access to Home Assistant using Tor]]> 2017-11-12T08:00:00+00:00 https://home-assistant.io/blog/2017/11/12/tor Routers and gateways provided by broadband internet providers are very often limited regarding features and configuration possibilities. Most of these limitations affect the opportunities that allow users to set up port-forwarding, DMZ, and DHCP reservations since the suppliers figured that average user does not want (or should not) deal with these. Making your Home Assistant instance available remotely (and securely), in this case, becomes more difficult. Are you one of those unlucky ones?

There are a couple of options available to achieve a remote (and secure) accessible Home Assistant instance. However, almost all of them require you to: open one or more ports on your router, expose a public IP address, and require you to reserve a fixed IP in your DHCP server (or set up a static IP address). Examples of these are:

  • Combination of DuckDNS (or similar), Let’s Encrypt (SSL), DHCP reservation, and forwarding a port to your device running Home Assistant.
  • Setup a VPN, which often requires more hardware and software. Additionally, it also requires port-forwarding, DHCP reservation and most likely DuckDNS (or similar).
  • SSH tunnel-ing. Which still requires port-forwarding, DHCP reservation and most likely (yeah, you’ve guessed it) DuckDNS (or similar).

There is, however, another option available that most people do not realize: Tor. Tor offers a capability that they refer to as Tor’s Hidden Services, which allows you to securely access your Home Assistant installation without the need for all these things. No need to forward and open ports, no need to expose your public IP, no DNS entry, no need for SSL certificates, and you do not have to assign a fixed IP to the device running your Home Assistant.

The most amazing part? It is super easy to set up!

Setting up Tor

Our documentation provides a detailed guide about setting up a Tor’s Hidden Service. The setup is straight-forward:

  1. Install Tor. On a Debian-based system: $ sudo apt-get install tor. On Fedora: $ sudo dnf install tor

  2. Modify Tor’s main configuration file /etc/tor/torrc to include the following lines:

     ############### This section is just for location-hidden services ###

 ## Once you have configured a hidden service, you can look at the
 ## contents of the file ".../hidden_service/hostname" for the address
 ## to tell people.
 ...
 HiddenServiceDir /var/lib/tor/homeassistant/
 HiddenServicePort 80 127.0.0.1:8123
 ...
  3. Restart Tor: $ sudo systemctl restart tor

  4. The Tor-generated hostname file contains the hostname you need to access your installation.

     $ sudo cat /var/lib/tor/homeassistant/hostname
 abcdef1234567890.onion

Tor add-on for Hass.io

Franck Nijhof (@frenck) created the Tor add-on for Hass.io. This add-on makes the installation and the setup extremely simple. Go to the Hass.io panel, then to the Store, copy https://github.com/hassio-addons/repository into the text box of Add-On Repositories and save it.

A new entry Tor will show-up in the list of add-ons. Click on it to install it. The configuration is done in Options. Please refer to the Configuration documentation for further details. A possible configuration could look like the sample below (which is the default configuration).

{
  "log_level": "info",
  "socks": false,
  "hidden_services": true,
  "stealth": false,
  "client_names": [],
  "ports": [
    "8123:80"
  ]
}

When you are done, press Save and then Start. In the Logs section, you can see what the add-on is doing. Watch out for an entry like the one below, which will tell you your hostname on the Tor network.

INFO: -----------------------------------------------------------
INFO: Your Home Assistant instance is available on Tor!
INFO: Address: abcdef1234567890.onion
INFO: -----------------------------------------------------------

Don’t worry if you missed it, restarting the add-on will display it again. The details are also stored and available in the /ssl/tor/hidden_service/hostname file.

Tor clients

To access you Home Assistant via the Tor Hidden Service, you will need a Tor client. There are multiple clients, for different devices and platforms, available. The Tor Browser is by far the simplest option, which is available for Windows, MacOS & Linux.

Simply download and install the Tor Browser, start it, and enter the “dot onion” address you’ve gained from the earlier steps (abcdef1234567890.onion in this case). Voila!

Some other clients:

Cranking up security

The setup described in this blog post is easy and relatively secure, but anyone who knows your .onion address can still connect to your Home Assistant instance (Remember to use passwords!). With all of the discussion about putting your IoT on the Tor Network, maybe you want to add an extra layer of defense, especially if you’re going to be the only one that uses it. Tor offers an additional layer of security, called “Hidden Service Authentication”, usually referred to as “Stealth”-mode.

This “Stealth”-mode adds an extra layer of security to your Hidden Service by only responding to a client that passes a unique secret cookie as it connects. Obviously, this requires additional configuration on the Tor client applications.

Additional information can be found in the Tor documentation and the Tor add-on repository, including how to setup the “Stealth”-mode. The Tor Project itself provides details about a variaty of topics in their documentation.

]]> <![CDATA[Home Assistant and The Things Network (TTN)]]> 2017-11-10T12:00:00+00:00 https://home-assistant.io/blog/2017/11/10/ttn-with-mqtt The Home Assistant integration for The Things Network (TTN) uses their Storage feature to get the sensor data. The easiest way to observe TTN sensors would be MQTT as it doesn’t requires any additional configuration.

At the moment Home Assistant only supports one MQTT broker. This means that you can’t subscribe to topics which are located on different brokers.

Subscribe to the TTN Broker

To check what your devices are sending, subscribe to the topic +/devices/+/up with a command-line tool like mosquitto_sub. The <Region> is the postfix of the Handler entry in your Application overview. <AppID> is the Application ID and <AppKey> is your access key.

$ mosquitto_sub -v -h <Region>.thethings.network -t '+/devices/+/up' -u '<AppID>' -P '<AppKey>'
{
	"app_id": "ha-demo",
	"dev_id": "device01",
	"hardware_serial": "AJDJENDNHRBFBBT",
	"port": 1,
    [...]

The payload contains details about the device itself and the sensor data. The sensor data is stored in payload_fields. Depending on the device configuration it may contain a single value or multiple values.

The relay

To be able to work locally with the MQTT data that is received from the devices connected to TTN, we need to transfer it to the local broker. With this simple script below all messages from a given device are re-published on your local MQTT broker after they are received. Modify the script with your details as outlined in the previous section.

"""Relay MQTT messages from The Things Network to a local MQTT broker."""
import paho.mqtt.client as mqtt
import paho.mqtt.publish as publish

DEVICE_NAME = '<DeviceID>'

TTN_BROKER = '<Region>.thethings.network'
TTN_USERNAME = '<AppID>'
TTN_PASSWORD = '<AppKey>'
TTN_TOPIC = '+/devices/{}/up'.format(DEVICE_NAME)

LOCAL_BROKER = '192.168.0.2'
LOCAL_TOPIC = 'home/ttn/garden_temp'


def on_connect(client, userdata, flags, rc):
    """Subscribe to topic after connection to broker is made."""
    print("Connected with result code", str(rc))
    client.subscribe(TTN_TOPIC)


def on_message(client, userdata, msg):
    """Relay message to a different broker."""
    publish.single(
        LOCAL_TOPIC, payload=msg.payload, qos=0, retain=False,
        hostname=LOCAL_BROKER, port=1883, client_id='ttn-local',
        keepalive=60, will=None, auth=None, tls=None, protocol=mqtt.MQTTv311)


client = mqtt.Client()
client.username_pw_set(TTN_USERNAME, password=TTN_PASSWORD)
client.on_connect = on_connect
client.on_message = on_message
client.connect(TTN_BROKER, 1883, 60)

client.loop_forever()

Save it and run it. As soon as a MQTT message is received from your device you should see it on your local broker (here 192.168.0.2) if you subscribe to # or the topic given in the script above home/ttn/garden_temp.

$ mosquitto_sub -h 192.168.0.2 -t "#" -d

The sensor

All we would need now, is a mqtt sensor with a value_template. With a sophisticated custom sensor it would be possible to displaying a little more than just the state. The device is only sending the temperature {"temperature": 7.5} but there are other details available which the sensor should show.

"""Support for The Things Network MQTT sensors."""
import asyncio
from datetime import timedelta
import json
import logging

import voluptuous as vol

import homeassistant.components.mqtt as mqtt
from homeassistant.components.mqtt import CONF_STATE_TOPIC
from homeassistant.const import CONF_NAME, CONF_UNIT_OF_MEASUREMENT
from homeassistant.core import callback
import homeassistant.helpers.config_validation as cv
from homeassistant.helpers.entity import Entity

_LOGGER = logging.getLogger(__name__)

DEFAULT_NAME = 'MQTT TTN Sensor'
DEFAULT_FORCE_UPDATE = False
DEPENDENCIES = ['mqtt']

PLATFORM_SCHEMA = mqtt.MQTT_RO_PLATFORM_SCHEMA.extend({
    vol.Optional(CONF_NAME, default=DEFAULT_NAME): cv.string,
    vol.Optional(CONF_UNIT_OF_MEASUREMENT): cv.string,

})


@asyncio.coroutine
def async_setup_platform(hass, config, async_add_devices, discovery_info=None):
    """Set up the TTN MQTT Sensor."""
    async_add_devices([MqttTtnSensor(
        config.get(CONF_NAME), config.get(CONF_STATE_TOPIC),
        config.get(CONF_UNIT_OF_MEASUREMENT))
    ])


class MqttTtnSensor(Entity):
    """Representation of a sensor."""

    def __init__(self, name, state_topic, unit_of_measurement):
        """Initialize the sensor."""
        self._state = None
        self._name = name
        self._unit_of_measurement = unit_of_measurement
        self._attributes = {}
        self._state_topic = state_topic

    def async_added_to_hass(self):
        """Subscribe to MQTT events."""
        @callback
        def message_received(topic, payload, qos):
            """Handle new MQTT messages."""

            try:
                data = json.loads(payload)
            except json.JSONDecodeError:
                _LOGGER.error("Invalid JSON data received: %s", data)

            self._state = data['payload_fields'][next(
                iter(data['payload_fields']))]
            self._attributes = data
            del self._attributes['payload_fields']
            del self._attributes['metadata']
            self.async_schedule_update_ha_state()

        return mqtt.async_subscribe(
            self.hass, self._state_topic, message_received, 0)

    @property
    def should_poll(self):
        """No polling needed."""
        return False

    @property
    def name(self):
        """Return the name of the sensor."""
        return self._name

    @property
    def unit_of_measurement(self):
        """Return the unit this state is expressed in."""
        return self._unit_of_measurement

    @property
    def state_attributes(self):
        """Return the attributes of the entity."""
        return self._attributes

    @property
    def state(self):
        """Return the state of the entity."""
        return self._state

Store it in <config_dir>/custom_components/sensor/mqtt_ttn.py and it will handle the messages.

The configuration

Now create the mqtt_ttn sensor entry for your device.

sensor:
  - platform: mqtt_ttn
    name: TTN Sensor
    state_topic: "home/ttn/garden_temp"

This solution is not production-ready, scalable or stable but it could fill the gape till Home Assistant is able to connect to multiple MQTT brokers. If you have multiple devices relay all messages to your local broker and add a configuration variable to mqtt_ttn sensor which allows you to select the device.

]]> <![CDATA[Translating Home Assistant]]> 2017-11-06T01:00:00+00:00 https://home-assistant.io/blog/2017/11/05/frontend-translations The Home Assistant sidebar in 12 different languages The Home Assistant sidebar in 12 different languages.

Translations

As mentioned in the 0.57 release notes, Home Assistant has launched a translated frontend. With the immediate influx of translations, we’ve made integration with a translation tool a top priority. @c727 took the initiative to evaluate several tools, and we’re happy to announce that Home Assistant will be partnering with Lokalise to manage our translations!

Lokalise allows us to open up translations for all of our multilingual users willing to contribute. Users can join the project using our public signup link, and start translating right away. We’ve created a translation startup guide with additional details about how to contribute. Instructions are provided there for how to request a new language.

Now that we have a system in place, expect a lot more of the interface to be translatable soon. We still have some technical hurdles to overcome, but the hardest work is behind us now. The community has already done an outstanding job of providing translations. The future is looking bright!

]]> <![CDATA[0.57: Translations, Hacktoberfest, Timers]]> 2017-11-04T04:00:00+00:00 https://home-assistant.io/blog/2017/11/04/release-57 The Home Assistant sidebar in 12 different languages The Home Assistant sidebar in 12 different languages.

Whaaaaaats up everyone?! 😁 It’s been another crazy 2 weeks here at the virtual Home Assistant headquarters with a ton of great contributions from all over the world. New features, bug fixes, performance improvements. It’s a lot so let’s jump right in.

Translations

The first great feature, if you haven’t guessed it yet from the screenshot above: we are now able to translate the UI! Currently the translations are limited to the sidebar menu items. Even without a translation tool available, our contributors have jumped in and submitted translations for these menu items in over twenty languages! Home Assistant will automatically pick an available translation based on your browser settings, or a translation can be manually selected in the configuration panel.

We’re currently working on an integration with the web based translation tool lokalise.co, to make the translation process accessible to anyone who would like to contribute. Stay tuned for a blog post with more documentation soon.

Frontend improvements

As part of getting translations to work, we did a lot of cleanup work on the frontend side. The re-organization should allow us to iterate faster on the frontend. We’ve already seen a lot of clean up as part of this thanks to @armills and @andrey-git for keep raising the quality!

Hacktoberfest

Hacktoberfest 2017 is over! FINALLY. Each year we’re attracting more developers that want to contribute to Home Assistant. This is great but also very exhausting to our code reviewers. I want to give an enormous gigantic huge big shout out to our reviewers @pvizeli, @andrey-git, @armills, @MartinHjelmare, @fabaff. You have all done an amazing job and we couldn’t run Home Assistant without any of you! ❤

Hacktoberfest is obviously about the people contributing to open source. Big thanks to everyone that has taken the time to learn our code base and make contributions. We hope it was a pleasant experience and show how great open source can be. Hope to see many contributions in the future 👍

Here are our Hacktoberfest 2017 stats. It’s a miracle everyone is still alive:

This means that we processed over 20 Pull requests per day. The result was already visible in 0.56. This release is almost the same. In those releases we were able to add over 40 new integrations.

IKEA TRÅDFRI

Good news and bad news on this front. The bad news is that IKEA changed the internal API for TRÅDFRI with a firmware update, breaking the Home Assistant integration. The good news is that they were nice enough to email us with instructions on the breaking changes.

Long time contributor @lwis jumped on the case and managed to migrate our integration in Home Assistant in time for this release. Great work!

Pumpkin with Home Assistant logo carved in. @clhett01 made us a pumpkin (via Twitter)

Timer

Okay, one more highlight before we’ll let you check out the changelog. Contributor @danielperna84 (famous for creating the HASS Configurator), had another great component up his sleeve: the Timer component. With the timer component you’ll be able to start countdown timers. A neat tool for your automation toolbox! More info in the timer docs.

New Platforms

release 0.57.1 - november 4

  • Fix login screen not showing when no password stored (@balloob)

release 0.57.2 - november 5

  • Update frontend with fixes for setting temperature on climate card (@balloob)
  • Fix setting max brightness for TRADFRI (@ggravlingen - #10359)

release 0.57.3 - november 11

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.

Breaking Changes

  • IKEA TRÅDFRI: We no longer support entering the key in the configuration. (@lwis - #10282) (tradfri docs) (breaking change)
  • API.AI was renamed to Dialogflow. This requires to rename the entry in your configuration.yaml file from apiai: to dialogflow. (@fabaff - #10006) (dialogflow docs) (breaking change)
  • Wink: Removed support for entering your username and password in your config. Use the new authentication method instead. (@w1ll1am23 - #10277) (wink docs) (breaking change)
  • Use feed name assigned in EmonCMS if there is one. This changes the default behavior but still uses configured ‘name’ if it’s set, so it won’t break the configuration of people who have customized their feed names in HA config. (@KlaasH - #10021) (sensor.emoncms docs) (breaking change)
  • The namecheapdns now uses password: instead of access_token in the configuration. Also, host is now optional which allow people who are not using subdomains to keep their configuration shorter. (@fabaff - #10063) (namecheapdns docs) (breaking change)
  • Fix recorder crash for long state string - enforce a maximum state of 255 characters at core level (@milanvo - #9696) (breaking change)
  • Add display currency setting to CoinMarketCap sensor. The name of the sensor attribute ‘24h_volume_usd’ is changed to ‘24h_volume’. (@R1chardTM - #10093) (sensor.coinmarketcap docs) (breaking change)

  • MQTT Statestream now serializes all data to JSON before publishing. This means that string attributes and values will be quoted from now on (e.g.: ‘“on”’ instead of ‘on’). You can still read these strings without the quotes by using ‘value_json’ instead of ‘value’ where applicable (e.g., templates). This causes automatic JSON deserialization. Other simple types are not affected.

    This fixes errors when an entity has an attribute that is not “a string, bytearray, int, float or None” and mqtt_statestream is used. As of now, the attribute is just handed over to paho, and paho can only send the aforementioned types. This patch fixes the issue by just casting everything to string before handing it over to paho.

    There are a number of components / entities which have “other” attributes, e.g. light that have an RGB attribute which is a list. (@tinloaf - #9872) (mqtt_statestream docs) (breaking change)

  • Generic thermostat: the configuration option tolerance has been removed and has been replaced by cold_tolerance and hot_tolerance. This allows on and off states to have different error bands. (@biggms - #9843) (climate.generic_thermostat docs) (breaking change)
  • Developers only: frontend has been refactored. The method register_panel has been turned into a coroutine function called async_register_panel. The parameter url_path has been renamed to frontend_url_path. For frontend, development, you no longer pass development: 1 to the http component but instead configure the frontend component to be in development mode by pointing it at a local checkout of the Polymer repo: (@balloob - #9915) (breaking change)

All changes

]]> <![CDATA[Home Assistant and SSH]]> 2017-11-02T08:00:00+00:00 https://home-assistant.io/blog/2017/11/02/secure-shell-tunnel Most system engineers are very familiar with SSH (Secure shell). This tool which contains a server part and a client part is used to access a remote system in a secure way. It can also help you if your are running Home Assistant but don’t want to expose it to the public. On a Linux system SSH is often available by default. If you are using a Windows installation additional steps are required which are not covered here.

In this blog post we are going to use the tunneling option of SSH to create a secure connection and forward the Home Assistant frontend to a local system.

The involved parties are:

  • Remote system: Where Home Assistant is running, usually in your home network.
  • Local system: Where you want to see the frontend.

The prerequirements are that you need to allow the forwarding of port 22 from your router to the system where Home Assistant is running in your network. It might also be needed that you enable the SSH daemon by $ sudo systemctl start sshd on the remote system and to adjust the host firewall. If you are running Hass.io then enable the SSH Server add-on. You must also have a public IP address or hostname which can be provided by dynamic DNS (e.g., NO-IP or DuckDNS). On your local system you need only a SSH client and you need to be in a network where SSH is allowed.

First let’s have a look at the command we are going to use. Use man ssh to get more information.

$ ssh -L 8000:localhost:8123 user@[IP_ADDRESS_REMOTE]
      |  |    |         |    |    |
      |  |    |         |    |    |_ IP address or hostname of your router.
      |  |    |         |    |_ Username on the remote system.
      |  |    |         |_ Port where the application is running.
      |  |    |_ We want the frontend on this system.
      |  |_ The port on our local system to use (above 1024).
      |_ We want to do local port forwarding.

A possible example could look like the command below.

$ ssh -L 8000:localhost:8123 ha@192.168.0.11

The first time you establish the connection you need to accept the fingerprint.

The authenticity of host '192.168.0.11 (192.168.0.11)' can't be established.
ECDSA key fingerprint is SHA256:asdf2faasd4gk45454fadr78wfadfasdfeg4vvvsae33.
ECDSA key fingerprint is MD5:44:d4:f7:44:d4:aa:b8:de:ef:09:3e:0d:4e:12:11:09.
Are you sure you want to continue connecting (yes/no)? 
Warning: Permanently added '192.168.0.162' (ECDSA) to the list of known hosts.
ha@192.168.0.11's password: 
Last login: Fri Oct 27 17:50:09 2017
[ha@home-assistant ~]$

Now you are able to use your frontend on your local system: http://localhost:8000

Things to keep in mind:

  • You need a public IP address or hostname (Dynamic DNS will work) if you want to use it from the internet.
  • You need to setup port forwarding on your router.
  • Don’t allow root to use SSH. Set PermitRootLogin no on the remote system.
  • Your local port must be above 1024. Only root is allowed to forward privileged ports which are below 1024.
  • Use SSH keys for authentication instead of passwords to avoid bruteforce attacks.
]]> <![CDATA[Home Assistant Demo]]> 2017-10-28T08:00:00+00:00 https://home-assistant.io/blog/2017/10/28/demo If you are planning to host a Home Assistant meetup or doing a talk, then you probably want to show Home Assistant to an audience. You could use a Wireless router, bulbs, switches, and a single board computer to do a realistic demo. For a workshop, this is what I usually do because I think that working with physical hardware is more fun for the participants. The issue is that you need time to set up, power and space. For a talk or in a location, where you only have a beamer and a table or a lectern, the physical hardware approach is not very convenient.

The simplest way to show Home Assistant to others is the online demo at https://home-assistant.io/demo/

Home Assistant’s online demo

--demo-mode and Demo platform

To be safe for your talk, you don’t want to depend on an internet connection. The demo mode --demo-mode allows you to run a demo locally including the latest features. Make sure that you have a backup of your configuration.

$ hass --demo-mode

If you already have a configuration.yaml file in place then you will get a combination of your setup with all available demo platforms. This can be overwhelming for the audience. The suggestion is that you tailor the demo to your needs by only showing a few selected platforms. For example:

sensor:
  - platform: demo
binary_sensor:
  - platform: demo
switch:
  - platform: demo

Home Assistant’s demo platforms

random platforms

Till now the frontend is static. Nothing is changing over time. Starting with 0.57 we ship a random binary sensor platform in addition to the already available random sensor.

By adding those platform to your configuration.yaml file, your demo will become more interactive.

sensor:
  - platform: demo
    name: Temperature
    unit_of_measurement: "°C"
binary_sensor:
  - platform: random
    name: Front Door
  - platform: random
    name: Back Door
    scan_interval: 5

Demo with random platforms

The random and the demo platforms can, of course, be used together. With a little work and some of the template platforms or the input_* components it would even be possible to simulate a complete apartment or a house. For a hint check the sample below:

input_boolean:
  on_off:
    name: On or off
binary_sensor:
  - platform: template
    sensors:
      on_tester:
        value_template: "{{ states.input_boolean.on_off.state == 'on' }}"
        friendly_name: 'Movement'
        device_class: motion

MQTT Discovery

This is a section for advanced users as it will require to run a separate script. Instead of adding demo platforms to the configuration this setup make use of MQTT discovery and the embedded MQTT broker. Simply add MQTT to your configuration.yaml file with discovery:

mqtt:
  discovery: true

Download the sample script. It depends on paho-mqtt. If you run the script inside your Home Assistant’s virtual environment then you are good to go as the dependency should be present if you have used MQTT before. Otherwise, install it with $ pip3 install paho-mqtt. The same applies to the embedded broker.

(ha)[ha-demo]$ python3 ha-mqtt-demo.py
Demo is running... -> CTRL + C to shutdown

It will create sensors, a light, and a switch and update the states as long the script is running. It possible to stop and restart script without losing the entities.

Some users share their slides and other documents in our assets repository. Also, take a look at that repository if you need a logo for your slides.

]]> <![CDATA[Serial analog sensor]]> 2017-10-23T06:00:00+00:00 https://home-assistant.io/blog/2017/10/23/simple-analog-sensor This blog post is about building a super simple analog sensor for Home Assistant. The physical sensor will send the data over its virtual serial port as it will be connected over USB. The concept is similar to the TEMPer USB devices. The attatched sensor type to the microcontroller can be any kind of sensor which gives you an analog signal from brightness over soil moisture to temperature.

The microcontroller will only transfer the voltage of an analog input pin which will be between 0 and 1024. Home Assistant will use the new serial sensor platform to read the data and perform actions to convert the raw reading into a real measurement. This means that you don’t have to adjust the code of your microcontroller if you change the attached sensor type.

The assembled sensor

All parts needed in this how-to can be bought for less than 2 Euro or 2 USD from China. I’m going to use the following items which were already available in my craft crate:

  • Digispark USB Development Board
  • Temperature sensor TMP36 (or any other sensor that gives you an analog signal)
  • Cables (if you don’t want to connect the sensor directly to the board)

The cabling is easy.

Sensor Digispark
GND GND
VCC 5V
VOUT P4

There are other boards with the same size available. Like those with the far more powerful Mega32U4 chip. However, it would work with boards from the Arduino family as well if you adjust the code provided below.

The sketch is pretty simple. We are going to send the readings to a virtual serial output every 5 seconds. No logic needed. A little plus is that the onboard LED is blinking as an indicator that the board is working. Upload the code to your Digispark board. Keep in mind that the upload process is different than with Arduino or ESP8266 boards.

#include <DigiCDC.h>

#define LED_PIN 1
#define INPUT_PIN 2  // Physical pin P4 is analog input 2

void setup() {
  SerialUSB.begin();
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  if (SerialUSB.available()) {
    digitalWrite(LED_PIN, HIGH);
    SerialUSB.delay(250);

    int reading = analogRead(INPUT_PIN);
    SerialUSB.println(reading);

    digitalWrite(LED_PIN, LOW);
    SerialUSB.delay(5000);
  }
}

To make it work with other boards simply use Serial.begin(115200); and Serial.println(reading);.

If you connect with a tool like minicom to your system’s serial port /dev/ttyACM0, then you will get the data. To use the sensor with Home Assistant the serial sensor platform needs to be set up.

sensor:
  - platform: serial
    port: /dev/ttyACM0

The physical sensor reads the current voltage of the pin. A template sensor takes the reading and converts it into a measurement. The data sheet of the sensor unit usually contains details about the involved calculations.

  - platform: template
    sensors:
      temperature:
        friendly_name: Temperature
        unit_of_measurement: "°C"
        value_template: "{{ (((states('sensor.serial_sensor') | float * 5 / 1024 ) - 0.5) * 100) | round(1) }}"

Hide the serial sensor if you don’t want to see the raw data in the frontend and you are done. The whole setup with a Digispark is not very reliable because there is no hardware USB support. As a showcase and if you don’t build your automation rules around it does the sensor what it should for a very small price.

]]> <![CDATA[0.56: Skybell, Google Assistant, Travis CI and Toon]]> 2017-10-21T10:00:00+00:00 https://home-assistant.io/blog/2017/10/21/release-56

We reached another milestone aka number: 10000. GitHub is assigning numbers to pull requests and issues and the “10000” is a PR. Our ratio is around 1/3 issues and 2/3 pull requests. To be more precise: 64% pull requests and 36% issues.

If you haven’t noticed, there is now a glossary that collects some Home Assistant relevant terms. Talking about the documentation: @DubhAd rewrote large parts of the Z-Wave section. More structure to get started and to find details during the setup and the configuration.

Google Assistant / Google Home integration

This release includes a new component to integrate Home Assistant with Google Assistant by Phil Kates. We integrate via the Smart Home API, this means that you will be able to control your devices in Home Assistant via any device that has Google Assistant. Learn more in the documentation.

Hacktoberfest

Hacktoberfest is still on and so far we have received a lot improvements. We can’t make any promises to review everything by the end of October, but we are trying to make sure that you will get your t-shirt.

Map

The map is now its own component. Similar to configuration (config:), it will not show up without adding it to your configuration.yaml file.

map:

Travis CI

Why not observe your Travis CI jobs with Home Assistant? @tchellomello created a Travis CI sensor which allows one to check on the current state of Travis jobs. Now you can make sure that the coffee is ready when the build passed.

New Platforms

0.56.1 - October 22

0.56.2 - October 23

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.

Breaking Changes

All changes

]]>