Add draft voice assistant

source/_posts/2019-11-20-privacy-focused-voice-assistant.markdown

@@ -0,0 +1,86 @@
+---
+layout: post
+title: "Almond & Ada: Privacy focused voice assistant"
+description: "Say Hi! to Almond, a privacy focused virtual assistant and Ada, a voice assistant powered by Home Assistant."
+date: 2019-11-14 0:43:02
+date_formatted: "November 20, 2019"
+author: Paulus Schoutsen
+author_twitter: balloob
+comments: true
+categories: Announcements
+og_image: /images/blog/2019-voice-assistant/almond.png
+---
+
+TL; DR:
+
+- Teamed up with [Almond](https://almond.stanford.edu/), available in Home Assistant 0.102.
+- Introducing [Ada](https://github.com/home-assistant/ada), voice assistant powered by Home Assistant integrations. Available as hass.io add-on.
+- New beta speech-to-text and text-to-speech service for Home Assistant Cloud subscribers.
+
+---
+
+Voice assistants are a great way to interact with your house, ask a quick question, set a timer or control your devices. The more an assistant know about you, your home and it's other inhabitants, the better it is able to help you.
+
+Todays available virtual assistants work great, but they have a big problem. They store your data in the cloud, don't provide APIs to allow other companies to build products on top and are run by companies whose core business is building profiles on their users to help serve ads and product suggestions.
+
+The backbone to our homes needs to be one that keeps data local and has APIs allowing other companies to build on top. Innovation happens when many different people, with many different backgrounds, do many different experiments until we find something that sticks. This cannot be left to a single company.
+
+Recently we got in touch with the [Open Virtual Assistant Lab at Stanford University](https://oval.cs.stanford.edu/). They have been working the last four years on a virtual assistant named Almond. And it's a perfect match for Home Assistant.
+
+<!--more-->
+
+## Almond
+
+[Almond](https://almond.stanford.edu/) is an open, privacy preserving virtual assistant that is open source. With Almond, you can run a virtual assistant at home that can tell you the news or control your house. It is powered by [LUInet](https://almond.stanford.edu/doc/genie-intro.md), a state-of-the-art neural network developed at Stanford. And it now works with Home Assistant.
+
+The Almond team has updated Almond to make it aware of all the different device types in Home Assistant and allow Almond to control them. In turn, we have upgraded the conversation integration in Home Assistant to support Almond, allowing users to converse with Almond via the frontend.
+
+<p class='img'><img src='/images/blog/2019-voice-assistant/almond.png' alt='Screenshot showing Almond integration in Home Assistant.'>Screenshot showing Almond integration in Home Assistant.</p>
+
+Almond will be available to users today in the Home Assistant 0.102 release. It requires Almond Server, which you can either install yourself, use the new Almond hass.io add-on or rely on Almond Web, a cloud version hosted by Stanford. By default, Almond Server will rely on a cloud version of LUInet, but it is possible to run it locally.
+
+Almond is set up in a way such that your privacy is still partially preserved even with LUInet running in the cloud. This is made possible because LUInet is only responsible for converting the text into a program, whose details are filled in locally by the Almond Server. For example, LUInet will convert "turn on the lights" into code that Almond Server understands. Only Almond Server will know which lights the user has, how to control them and the context of how the text was received.
+
+### Almond vs …
+
+You're probably wondering if Almond is as good as Alexa or Google. And it's not yet. However, it doesn't matter.
+
+If you want to have an assistant in your home that is to know everything about you, it needs to be one that cares about privacy. It needs to be one that is open. That's not negotionable.
+
+Almond has room for improvement. But it's open source, and with the Home Assistant community we'll work with the Almond team on making it better. And you can start helping right now:
+
+Almond is gathering sentences that you want to use to control the devices in your home. We already have a basic set of sentences, but the more the better. You can submit those sentences [here](https://docs.google.com/forms/d/e/1FAIpQLSeStJfjvueNAiueRVmP47XALRaJlx7tttzJjRfVjX4J546-uA/viewform).
+
+You are also able to help train LUInet directly by teaching it how to interpretet sentences [here](https://almond.stanford.edu/developers/train).
+
+## Ada
+
+Almond is not the full story. Almond only works with text input, and generates text as output. It doesn't handle speech-to-text to receive input nor text-to-speech to speak answers. Those technologies are out of scope for Almond. However, not out of scope for Home Assistant! Home Assistant already has a text-to-speech integration with different backends. In Home Assistant 0.102 we're introducing a new speech-to-text integration to complement this.
+
+Now we almost have all the pieces for a voice assistant built-in to Home Assistant, and so we decided to finish it off by introducing a new project called [Ada](https://github.com/home-assistant/ada). Ada integrates hotword detection and will route all data to the various integrations to provide a full voice assistant experience.
+
+<a href='/images/blog/2019-voice-assistant/overview.svg'><img src='/images/blog/2019-voice-assistant/overview.svg' alt='Architectural overview of how all pieces fit together.' style='border: 0;box-shadow: none;'></a>
+
+Ada is still very much in the beginning. We'll be working on improving it. If you have expertise in this area and want to help, please get in touch.
+
+Ada will also be available as a [Hass.io](http://hass.io) add-on. This means that you can plug a microphone and speakers into your Raspberry Pi and turn Hass.io into a full, privacy focused, voice assistant.
+
+To make it easier to add speech-to-text and text-to-speech integrations to your system, Nabu Casa is introducing a new beta service offering speech-to-text and text-to-speech services to Home Assistant Cloud subscribers powered by Azure Cognitive Services.
+
+<div class='videoWrapper'>
+<iframe width="560" height="315" src="https://www.youtube.com/embed/8VFZiHcjp78" frameborder="0" allowfullscreen></iframe>
+</div>
+
+## Can a virtual assistant still be private if parts run in the cloud?
+
+With Home Assistant we care about privacy and local control. We want to be able to offer home automation that keeps working if there is no internet. Home automation that is fast and reliable.
+
+But we also want privacy to be accessible. A user should be able to get a private solution without running a big server at home. Privacy should not be something that is reserved for the rich.
+
+With the current approach, some things will still run in the cloud, but the home data and control stays local. We will bring more things local when faster technology becomes more accessible and/or new projects emerge that can help with this.
+
+We cannot wait until all the pieces are in place to run 100% locally. We need to help build the future we want to see.
+
+## What's next?
+
+With Almond and Ada we've put the building blocks in place to create voice assistants. It's now time to use it, improve it and surprise us by sharing the things you'll use it for.

source/_posts/2019-11-20-release-102.markdown

@@ -70,6 +70,8 @@ scene: !include scenes.yaml
 
 https://github.com/tuanha2000vn/hasskit/
 
+https://www.reddit.com/r/homeassistant/comments/dz1qsi/picture_elements_are_so_fun_i_made_a_bad_video/
+
 ## New Integrations
 
 - Add Unifi Led ([@florisvdk] - [#27475]) ([unifiled docs]) (new-integration)
@@ -103,34 +105,36 @@ Experiencing issues introduced by this release? Please report them in our [issue
 
 ## Breaking Changes
 
-- __Huawei LTE__ - Configuration has been consolidated below `huawei_lte`. Device tracker no longer uses known_devices.yaml but entity registry. - ([@scop] - [#26675]) ([huawei_lte docs])
-  
+- **Huawei LTE** - Configuration has been consolidated below `huawei_lte`. Device tracker no longer uses known_devices.yaml but entity registry. - ([@scop] - [#26675]) ([huawei_lte docs])
+
   Example configuration yaml:
+
   ```yaml
   huawei_lte:
     - url: http://192.168.100.1/
       username: admin
       password: something
   ```
-  
-- __Ikea Tradfri__ - This removes the battery sensor that was created for the signal repeater. The sensor would never have a state, and after some inspection, it does not look like that device present any valuable metrics. - ([@ludeeus] - [#28181]) ([tradfri docs])
 
-- __UPNP/IGD__ -  All UPNP/IGD sensors are now in one device. You have to remove and re-add the integration to get rid of the previous devices. ([@escoand] - [#27517]) ([upnp docs])
+- **Ikea Tradfri** - This removes the battery sensor that was created for the signal repeater. The sensor would never have a state, and after some inspection, it does not look like that device present any valuable metrics. - ([@ludeeus] - [#28181]) ([tradfri docs])
 
-- __PS4__ - State `off` is now State `standby`. Affects user defined scripts, automations, etc. ([@ktnrg45] - [#28261]) ([ps4 docs])
+- **UPNP/IGD** - All UPNP/IGD sensors are now in one device. You have to remove and re-add the integration to get rid of the previous devices. ([@escoand] - [#27517]) ([upnp docs])
 
-- __SSDP__ -  `ssdp` in manifest.json has changed; it is now a list of dicts, and as we now match using the UPnP device description fields directly, `device_type` has to be renamed to `deviceType`. No included integrations use it at the moment, nor are they broken by this change. If any custom integrations are using it, they need to adjust accordingly. ([@scop] - [#28285]) ([ssdp docs])
+- **PS4** - State `off` is now State `standby`. Affects user defined scripts, automations, etc. ([@ktnrg45] - [#28261]) ([ps4 docs])
 
-- __HomematicIP Cloud__ - The attribute naming between Homematic IP `HmIP-BSM` (light) and `HmIP-FSM/HmIP-PSM` (switch) was different and in case of light not correct. The attributes for `HmIP-BSM` have been renamed:
-  
-  * energy_counter_kwh --> today_energy_kwh
-  * power_consumption --> current_power_w
+- **SSDP** - `ssdp` in manifest.json has changed; it is now a list of dicts, and as we now match using the UPnP device description fields directly, `device_type` has to be renamed to `deviceType`. No included integrations use it at the moment, nor are they broken by this change. If any custom integrations are using it, they need to adjust accordingly. ([@scop] - [#28285]) ([ssdp docs])
+
+- **HomematicIP Cloud** - The attribute naming between Homematic IP `HmIP-BSM` (light) and `HmIP-FSM/HmIP-PSM` (switch) was different and in case of light not correct. The attributes for `HmIP-BSM` have been renamed:
+
+  - energy_counter_kwh --> today_energy_kwh
+  - power_consumption --> current_power_w
 
   Please check your automations, scripts, scenes, etc., if you are using the old attributes in templates, and replace them with the new ones. - ([@SukramJ] - [#28271]) ([homematicip_cloud docs])
 
-- __Plugwise__ - Detection of a legacy Anna (firmware 1.8.x) is no longer automatic: owners of a legacy Anna have to provide info in configuration.yaml, the last line. This change was needed to be able to fix issue #26520. - ([@bouwew] - [#28237]) ([plugwise docs])
+- **Plugwise** - Detection of a legacy Anna (firmware 1.8.x) is no longer automatic: owners of a legacy Anna have to provide info in configuration.yaml, the last line. This change was needed to be able to fix issue #26520. - ([@bouwew] - [#28237]) ([plugwise docs])
 
   Example configuration yaml:
+
   ```yaml
   climate:
     - platform: plugwise
@@ -138,19 +142,20 @@ Experiencing issues introduced by this release? Please report them in our [issue
       password: your_password
       host: your_anna_ip
       legacy_anna: true
-   ```
-   
-- __Android TV__ - The `source` and `sources_list` attributes for Fire TV devices will use friendly app names instead of app IDs (e.g., "Netflix" instead of "com.netflix.ninja"). If you are using these attributes in automations, sensors, etc., you will need to update them.
-  * If you are currently checking that the `source` attribute of a Fire TV device is a particular app ID, you have two options:
-    * Check the `app_id` attribute instead
-    * Replace that app ID with the friendly name for the app.
-  * If you are currently checking the `sources_list` attribute, then you will need to check for friendly app names instead of app IDs.
-  
-  You can still use app IDs for the media_player.select_source service. - ([@JeffLIrion] - [#28417]) ([androidtv docs])
-  
-- __Homekit__ - Thermostats supported by the Homekit Controller component were reporting "off" for the running status when the HVAC was powered on but not actively heating or cooling. This `hvac_action` attribute will now properly return "idle" instead of off. Any logic that tests for the `hvac_action` condition of `off` will need to change to `idle`. There is no change to any other states. - ([@GaryOkie] - [#28625]) ([homekit_controller docs])
+  ```
 
-- __OpenALPR local__ - The "alp_bin" option has been corrected to "alpr_bin" as is outlined in the documentation. Users should check their config and update if necessary. ([@HexF] - [#28746]) ([openalpr_local docs])
+- **Android TV** - The `source` and `sources_list` attributes for Fire TV devices will use friendly app names instead of app IDs (e.g., "Netflix" instead of "com.netflix.ninja"). If you are using these attributes in automations, sensors, etc., you will need to update them.
+
+  - If you are currently checking that the `source` attribute of a Fire TV device is a particular app ID, you have two options:
+    - Check the `app_id` attribute instead
+    - Replace that app ID with the friendly name for the app.
+  - If you are currently checking the `sources_list` attribute, then you will need to check for friendly app names instead of app IDs.
+
+  You can still use app IDs for the media_player.select_source service. - ([@JeffLIrion] - [#28417]) ([androidtv docs])
+
+- **Homekit** - Thermostats supported by the Homekit Controller component were reporting "off" for the running status when the HVAC was powered on but not actively heating or cooling. This `hvac_action` attribute will now properly return "idle" instead of off. Any logic that tests for the `hvac_action` condition of `off` will need to change to `idle`. There is no change to any other states. - ([@GaryOkie] - [#28625]) ([homekit_controller docs])
+
+- **OpenALPR local** - The "alp_bin" option has been corrected to "alpr_bin" as is outlined in the documentation. Users should check their config and update if necessary. ([@HexF] - [#28746]) ([openalpr_local docs])
 
 ## Beta Fixes