Cut version 80

website/versioned_docs/version-0.80.0/auth_index.md

@@ -0,0 +1,52 @@
+---
+title: Authentication
+sidebar_label: Introduction
+id: version-0.80.0-auth_index
+original_id: auth_index
+---
+
+Home Assistant has a built-in authentication system allowing different users to interact with Home Assistant. The authentication system consist of various parts.
+
+![Overview of how the different parts interact](/img/en/auth/architecture.png)
+
+## Authentication providers
+
+An authentication provider is used for users to authenticate themselves. It's up to the authentication provider to choose the method of authentication and the backend to use. By default we enable the built-in Home Assistant authentication provider which stores the users securely inside your configuration directory.
+
+The authentication providers that Home Assistant will use are specified inside `configuration.yaml`. It is possible to have multiple instances of the same authentication provider active. In that case, each will be identified by a unique identifier. Authentication providers of the same type will not share credentials.
+
+## Credentials
+
+Credentials store the authentication of a user with a specific authentication provider. It is produced when a user successfully authenticates. It will allow the system to find the user in our system. If the user does not exist, a new user will be created. This user will not be activated but will require approval by the owner.
+
+It is possible for a user to have multiple credentials linked to it. However, it can only have a single credential per specific authentication provider.
+
+## Users
+
+Each person is a user in the system. To log in as a specific user, authenticate with any of the authentication providers that are linked to this user. When a user logs in, it will get a refresh and an access token to make requests to Home Assistant.
+
+### Owner
+
+The user that is created during onboarding will be marked as "owner". The owner is able to manage other users and will always have access to all permissions.
+
+## Groups
+
+Users are a member of one or more groups. Group membership is how a user is granted permissions.
+
+## Permission Policy
+
+This is the permission policy that describes to which resources a group has access. For more information about permissions and policies, see [Permissions](auth_permissions.md).
+
+## Access and refresh tokens
+
+Applications that want to access Home Assistant will ask the user to start an authorization flow. The flow results in an authorization code when a user successfully authorizes the application with Home Assistant. This code can be used to retrieve an access and a refresh token. The access token will have a limited lifetime while refresh tokens will remain valid until a user deletes it.
+
+The access token is used to access the Home Assistant APIs. The refresh token is used to retrieve a new valid access token.
+
+### Refresh token types
+
+There are three different types of refresh tokens:
+
+- *Normal*: These are the tokens that are generated when a user authorizes an application. The application will hold on to these tokens on behalf of the user.
+- *Long-lived Access Token*: These are refresh tokens that back a long lived access token. They are created internally and never exposed to the user.
+- *System*: These tokens are limited to be generated and used by system users like Hass.io. They are never exposed to the user.

website/versioned_docs/version-0.80.0/auth_permissions.md

@@ -0,0 +1,93 @@
+---
+title: Permissions
+id: version-0.80.0-auth_permissions
+original_id: auth_permissions
+---
+
+> This is an experimental feature that is not enabled or enforced yet
+
+Permissions limit the things a user has access to or can control. Permissions are attached to groups, of which a user can be a member. The combined permissions of all groups a user is a member of decides what a user can and cannot see or control.
+
+Permissions do not apply to the user that is flagged as "owner". This user  will always have access to everything.
+
+## General permission structure
+
+Policies are dictionaries that at the root level consist of different categories of permissions. In the current implementation this is limited to just entities.
+
+```python
+{
+  "entities": …
+}
+```
+
+Each category can further split into subcategories that describe parts of that category.
+
+```python
+{
+  "entities": {
+    "domains": …,
+    "entity_ids": …
+  }
+}
+```
+
+If a category is ommitted, the user will not have permission to that category.
+
+When defining a policy, any dictionary value at any place can be replaced with `True` or `None`. `True` means that permission is granted and `None` means use default, which is deny access.
+
+## Entities
+
+Entity permissions can be set on a per entity and per domain basis using the subcategories `entity_ids` and `domains`. Granting access to an entity means a user will be able to read the state and control it.
+
+If an entity is specified in both the `entity_ids` and `domains` subcategory, the `entity_ids` result will be used, unless it is `None`. In the following example, the user will have access to all light entities except for `light.kitchen`.
+
+```python
+{
+  "entities": {
+    "domains": {
+      "light": True
+    },
+    "entity_ids": {
+      "light.kitchen": False
+    }
+  }
+}
+```
+
+## Merging policies
+
+If a user is a member of multiple groups, the groups permission policies will be combined into a single policy at runtime. When merging policies, we will look at each level of the dictionary and compare the values for each source using the following methodology:
+
+1. If any of the values is `True`, the merged value becomes `True`.
+2. If any value is a dictionary, the merged value becomes a dictionary created by recursively checking each value using this methodology.
+3. If all values are `None`, the merged value becomes `None`.
+
+Let's look at an example:
+
+```python
+{
+  "entities": {
+    "entity_ids": {
+      "light.kitchen": True
+    }
+  }
+}
+```
+
+```python
+{
+  "entities": {
+    "entity_ids": True
+  }
+}
+```
+
+Once merged becomes
+
+```python
+{
+  "entities": {
+    "entity_ids": True
+  }
+}
+```

website/versioned_docs/version-0.80.0/development_catching_up.md

@@ -0,0 +1,38 @@
+---
+title: Catching up with Reality
+id: version-0.80.0-development_catching_up
+original_id: development_catching_up
+---
+
+If it's taking a while to develop your feature, and you want to catch up with what's in the current Home Assistant `dev` branch, you can use `git rebase`. This will pull the latest Home Assistant changes locally, rewind your commits, bring in the latest changes from Home Assistant, and replay all of your commits on top.
+
+> If you use the workflow below, it is important that you force push the update as described. Git might prompt you to do `git pull` first. Do **NOT** do that! It would mess up your commit history.
+
+```bash
+# Run this from your feature branch
+$ git fetch upstream dev  # to pull the latest changes into a local dev branch
+$ git rebase upstream/dev # to put those changes into your feature branch before your changes
+```
+
+If rebase detects conflicts, repeat this process until all changes have been resolved:
+
+1. `git status` shows you the file with the conflict; edit the file and resolve the lines between `<<<< | >>>>`
+3. Add the modified file: `git add <file>` or `git add .`
+4. Continue rebase: `git rebase --continue`
+5. Repeat until you've resolved all conflicts
+
+After rebasing your branch, you will have rewritten history relative to your GitHub fork's branch. When you go to push you will see an error that your history has diverged from the original branch. In order to get your GitHub fork up-to-date with your local branch, you will need to force push, using the following command:
+
+```bash
+# Run this from your feature branch
+$ git push origin --force
+```
+
+Other workflows are covered in detail in the [Github documentation](https://help.github.com/articles/fork-a-repo/). Add an additional `remote` after you clone your fork.
+
+```bash
+$ git remote add upstream https://github.com/home-assistant/home-assistant.git
+```
+
+Then, `git pull --rebase upstream dev`.
+

website/versioned_docs/version-0.80.0/development_environment.md

@@ -0,0 +1,111 @@
+---
+title: Set up Development Environment
+id: version-0.80.0-development_environment
+original_id: development_environment
+---
+
+You'll need to set up a development environment if you want to develop a new feature or component for Home Assistant. Read on to learn how to set up.
+
+## Preparing your environment
+
+### Developing on Linux
+
+Install the core dependencies.
+
+```bash
+$ sudo apt-get install python3-pip python3-dev python3-venv
+```
+
+In order to run `script/setup` below you will need some more dependencies.
+
+```bash
+$ sudo apt-get install autoconf libssl-dev libxml2-dev libxslt1-dev libjpeg-dev libffi-dev libudev-dev zlib1g-dev
+```
+
+> Different distributions have different package installation mechanisms and sometimes packages names as well. For example Centos would use: `sudo yum install epel-release && sudo yum install python36 python36-devel mysql-devel gcc`
+
+Additional dependencies exist if you plan to perform Frontend Development, please read the [Frontend](frontend_index.md) section to learn more.
+
+### Developing on Windows
+
+Due to Home Assistant is mainly designed and developed on Linux distributions, on Windows 10 you can setup a [Linux subsystem](https://docs.microsoft.com/windows/wsl/install-win10).
+
+Open Powershell as an Administrator and run
+```
+Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
+```
+
+From Windows Store install Ubuntu.
+
+When the Linux subsystem is setup, perform install as for Linux
+
+```bash
+$ sudo apt-get update
+$ sudo apt-get install python3-pip python3-dev python3-venv
+$ sudo apt-get install autoconf libssl-dev libxml2-dev libxslt1-dev libjpeg-dev libffi-dev libudev-dev zlib1g-dev
+```
+
+Hint: Git is included in Linux subsytem.
+
+When invoking your installation (see below), make sure to specify a folder for configuration which is accessible from Windows.
+
+```bash
+mkdir -p ../config
+hass -c ../config
+```
+
+### Developing on OS X
+
+Install [Homebrew](https://brew.sh/), then use that to install Python 3:
+
+```bash
+$ brew install python3 autoconf
+```
+
+## Setup Local Repository
+
+Visit the [Home Assistant repository](https://github.com/home-assistant/home-assistant) and click **Fork**.
+Once forked, setup your local copy of the source using the commands:
+
+```bash
+$ git clone https://github.com/YOUR_GIT_USERNAME/home-assistant.git
+$ cd home-assistant
+$ git remote add upstream https://github.com/home-assistant/home-assistant.git
+```
+
+## Setting up virtual environment
+
+To isolate your environment from the rest of the system, set up a [`venv`](https://docs.python.org/3/library/venv.html). Within the `home-assistant` directory, create and activate your virtual environment.
+
+```bash
+$ python3 -m venv .
+$ source bin/activate
+```
+
+Install the requirements with a provided script named `setup`.
+
+```bash
+$ script/setup
+```
+
+Invoke your installation, adjusting the [configuration](https://www.home-assistant.io/docs/configuration/) if required. 
+
+```bash
+$ hass
+```
+
+## Logging
+
+By default logging in home-assistant is tuned for operating in production (set to INFO by default, with some modules set to even less verbose logging levels).
+
+You can use the [logger](https://www.home-assistant.io/components/logger/) component to adjust logging to DEBUG to see even more details about what is going on:
+
+```yaml
+logger:
+  default: info
+  logs:
+    homeassistant.core: debug
+    nest.nest: debug
+    asyncio: debug
+    homeassistant.components.cloud.iot: debug
+```

website/versioned_docs/version-0.80.0/development_submitting.md

@@ -0,0 +1,44 @@
+---
+title: Submit your work
+id: version-0.80.0-development_submitting
+original_id: development_submitting
+---
+
+> Always base your Pull Requests of of the current **`dev`** branch, not `master`.
+
+Submit your improvements, fixes, and new features to Home Assistant one at a time, using GitHub [Pull Requests](https://help.github.com/articles/using-pull-requests). Here are the steps:
+
+ 1. From your fork's dev branch, create a new branch to hold your changes:
+
+      `git checkout -b some-feature`
+
+ 2. Make your changes, create a [new platform](creating_platform_index.md), develop a [new component](creating_component_index.md), or fix [issues](https://github.com/home-assistant/home-assistant/issues).
+
+ 3. [Test your changes](development_testing.md) and check for style violations.
+
+ 4. If everything looks good according to these [musts](development_checklist.md), commit your changes:
+
+    `git add .`
+
+    `git commit -m "Added some-feature"`
+
+     * Write a meaningful commit message and not only `Update` or `Fix`.
+     * Use a capital letter to start with your commit message.
+     * Don't prefix your commit message with `[bla.bla]` or `platform:`.
+     * Consider adding tests to ensure that your code works.
+
+ 5. Push your committed changes back to your fork on GitHub:
+
+    `git push origin HEAD`
+
+ 6. Follow [these steps](https://help.github.com/articles/creating-a-pull-request/) to create your pull request.
+
+     * On GitHub, navigate to the main page of the Home Assistant repository.
+     * In the "Branch" menu, choose the branch that contains your commits (from your fork).
+     * To the right of the Branch menu, click **New pull request**.
+     * Use the base branch dropdown menu to select the branch you'd like to merge your changes into, then use the compare branch drop-down menu to choose the topic branch you made your changes in. Make sure the Home Assistant branch matches with your forked branch (`dev`) else you will propose ALL commits between branches.
+     * Type a title and complete the provided description for your pull request.
+     * Click **Create pull request**.
+
+ 7. Check for comments and suggestions on your pull request and keep an eye on the [CI output](https://travis-ci.org/home-assistant/home-assistant/).
+

website/versioned_docs/version-0.80.0/development_testing.md

@@ -0,0 +1,78 @@
+---
+title: Testing your code
+id: version-0.80.0-development_testing
+original_id: development_testing
+---
+
+As it states in the [Style guidelines section](development_guidelines.md) all code is checked to verify the following:
+
+- All the unit tests pass
+- All code passes the checks from the linting tools
+
+Local testing is done using Tox, which has been installed as part of running `script/setup` in the [virtual environment](development_environment.md). To start the tests, activate the virtual environment and simply run the command:
+
+```bash
+$ tox
+```
+**Important:** Run `tox` before you create your pull request to avoid annoying fixes.
+
+Running Tox will run unit tests against the locally available Pythons, as well as validate the code and document style using `pycodestyle`, `pydocstyle` and  `pylint`. You can run tests on only one tox target -- just use `-e` to select an environment. For example, `tox -e lint` runs the linters only, and `tox -e py36` runs unit tests only on Python 3.6.
+
+Tox uses virtual environments under the hood to create isolated testing environments. The tox virtual environments will get out-of-date when requirements change, causing test errors. Run `tox -r` to tell Tox to recreate the virtual environments.
+
+### Adding new dependencies to test environment
+
+If you are working on tests for a component or platform and you need the dependencies available inside the Tox environment, update the list inside `script/gen_requirements_all.py`. Then run the script and then run `tox -r` to recreate the virtual environments.
+
+### Running single tests using Tox
+
+You can pass arguments via Tox to py.test to be able to run single test suites or test files. Replace `py36` with the Python version that you use.
+
+```bash
+# Stop after the first test fails
+$ tox -e py36 -- tests/test_core.py -x
+# Run test with specified name
+$ tox -e py36 -- tests/test_core.py -k test_split_entity_id
+# Fail a test after it runs for 2 seconds
+$ tox -e py36 -- tests/test_core.py --timeout 2
+# Show the 10 slowest tests
+$ tox -e py36 -- tests/test_core.py --duration=10
+```
+
+### Testing outside of Tox
+
+Running tox will invoke the full test suite. Even if you specify which tox target to run, you still run all tests inside that target. That's not very convenient to quickly iterate on your code! To be able to run the specific test suites without Tox, you'll need to install the test dependencies into your Python environment:
+
+```bash
+$ pip3 install -r requirements_test_all.txt
+```
+
+Now that you have all test dependencies installed, you can run tests on individual files:
+
+```bash
+$ flake8 homeassistant/core.py
+$ pylint homeassistant/core.py
+$ pydocstyle homeassistant/core.py
+$ py.test tests/test_core.py
+```
+
+You can also run linting tests against all changed files, as reported by `git diff upstream/dev... --diff-filter=d --name-only`, using the `lint` script:
+
+```bash
+$ script/lint
+```
+
+### Preventing Linter Errors
+
+Save yourself the hassle of extra commits just to fix style errors by enabling the Flake8 git commit hook. Flake8 will check your code when you try to commit to the repository and block the commit if there are any style errors, which gives you a chance to fix them!
+
+```bash
+$ pip3 install flake8 flake8-docstrings
+$ flake8 --install-hook=git
+```
+
+The `flake8-docstrings` extension will check docstrings according to [PEP257](https://www.python.org/dev/peps/pep-0257/) when running Flake8.
+
+### Notes on PyLint and PEP8 validation
+
+If you can't avoid a PyLint warning, add a comment to disable the PyLint check for that line with `# pylint: disable=YOUR-ERROR-NAME`. Example of an unavoidable one is if PyLint incorrectly reports that a certain object doesn't have a certain member.

website/versioned_docs/version-0.80.0/documentation_create_page.md

@@ -0,0 +1,133 @@
+---
+title: Create a new page
+id: version-0.80.0-documentation_create_page
+original_id: documentation_create_page
+---
+
+For a platform or component page, the fastest way is to make a copy of an existing page and edit it. The [Component overview](https://www.home-assistant.io/components/) and the [Examples section](https://www.home-assistant.io/cookbook/) are generated automatically, so there is no need to add a link to those pages.
+
+Please honor the [Standards](documentation_standards.md) we have for the documentation.
+
+If you start from scratch with a page, you need to add a header. Different sections of the documentation may need different headers.
+
+```text
+---
+layout: page
+title: "Awesome Sensor"
+description: "home-assistant.io web presence"
+date: 2015-06-17 08:00
+sidebar: true
+comments: false
+sharing: true
+footer: true
+ha_release: "0.38"
+ha_category: Sensor
+ha_iot_class: "Local Polling"
+ha_qa_scale: silver
+---
+
+Content... Written in markdown. 
+
+### {% linkable_title Linkable Header %}
+...
+```
+
+Please keep in mind that if the `date:` entry is in the future then the page will not show up.
+
+Additional keys for the file header:
+
+- `logo`: Please check the separate section below.
+- `ha_release`: The release when the integration was included, e.g., "0.38". If the current release is 0.37, make `ha_release` 0.38. If it's 0.30 or 0.40 please quote it with `" "`.
+- `ha_category`: This entry is used to group the integration on the [Components overview](https://www.home-assistant.io/components/).
+- `ha_iot_class`: [IoT class](https://www.home-assistant.io/blog/2016/02/12/classifying-the-internet-of-things) is the classifier for the device's behavior.
+- `ha_qa_scale`: [Quality scale](https://www.home-assistant.io/docs/quality_scale/) is the representation of the integration's quality.
+
+There are [pre-defined variables](https://jekyllrb.com/docs/variables/) available but usually, it's not necessary to use them when writing documentation.
+
+A couple of points to remember:
+
+- Document the needed steps to retrieve API keys or access token for the third party service or device if needed.
+- Add screenshots to support the user where it makes sense.
+- Add the type of the device(s) (incl. firmware) you have tested when you know that there are multiple out there.
+
+### Configuration
+
+Every platform page should contain a configuration sample. This sample must contain only the **required** variables to make it easy to copy and paste it for users into their `configuration.yaml` file.
+
+The **Configuration Variables** section must use the `{% configuration %} ... {% endconfiguration %}` tag.
+
+```text
+{% configuration %}
+api_key:
+  description: The API key to access the service.
+  required: true
+  type: string
+name:
+  description: Name to use in the frontend.
+  required: false
+  default: The default name to use in the frontend.
+  type: string
+monitored_conditions:
+  description: Conditions to display in the frontend.
+  required: true
+  type: map
+  keys:
+    weather:
+      description: A human-readable text summary.
+    temperature:
+      description: The current temperature.
+{% endconfiguration %}
+```
+
+Available keys:
+
+- **`description:`**: That the variable is about.
+- **`required:`**: If the variable is required.
+
+```text
+required: true            #=> Required
+required: false           #=> Optional
+required: inclusive       #=> Inclusive
+required: exclusive       #=> Exclusive
+required: any string here #=> Any string here
+```
+- **`type:`**: The type of the variable. Allowed entries: `boolean`, `string`, `integer`, `float`, `time`, `template`, `device_class`, `icon` or `map`/`list` (for a list of entries). For multiple possibilities use `[string, integer]`. If you use `map`/`list` then should define `keys:` (see the [`template` sensor](https://www.home-assistant.io/components/sensor.template/) for an example). If you use `boolean`, then `default:` must be defined.
+- **`default:`**: The default value for the variable.
+
+### Embedding Code
+
+You can use the [default markdown syntax](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#code) to generate syntax highlighted code. For inline code wrap your code in back-ticks. 
+
+When you're writing code that is to be executed on the terminal, prefix it with `$`.
+
+### Templates
+
+For the [configuration templating](https://www.home-assistant.io/docs/configuration/templating/) [Jinja](http://jinja.pocoo.org/) is used. Check the [Documentation Standards](documentation_standards.md) for further details.
+
+If you are don't escape templates then they will be rendered and appear blank on the website.
+
+### HTML
+
+The direct usage of HTML is supported but not recommended. The note boxes are an exception.
+
+```html
+<p class='note warning'>
+  You need to enable telnet on your router. 
+</p>
+```
+
+### Images, icons and logos
+
+The images which are displayed on the pages are stored in various directories according to their purpose. If you want to use a logo and placed `logo:` in the file header then this image should be stored in `source/images/supported_brands`. The background must be transparent.
+
+| Type         | Location                                      |
+| :----------- |:----------------------------------------------|
+| logos        | source/images/supported_brands                |
+| blog         | source/images/blog                            |
+| screenshots  | source/images/components                      |
+
+Not everything (product, component, etc.) should have a logo. To show something for internal parts of Home Assistant we are using the [Material Design Icons](https://materialdesignicons.com/).
+
+### Linking From The Sidebar
+
+If you are adding a new page that requires linking from the sidebar, you need to edit the `docs_navigation.html` file in `source/_includes/asides/docs_navigation.html`.

website/versioned_docs/version-0.80.0/documentation_index.md

@@ -0,0 +1,53 @@
+---
+title: Documentation
+id: version-0.80.0-documentation_index
+original_id: documentation_index
+---
+
+The user documentation is located at [https://www.home-assistant.io](https://www.home-assistant.io). This section here is the place where we provide documentation and additional details about creating or modifying content.
+
+The [home-assistant.io](https://home-assistant.io) website is built using [Jekyll](http://github.com/mojombo/jekyll) and [these dependencies](https://pages.github.com/versions/). The pages are written in [Markdown](http://daringfireball.net/projects/markdown/). To add a page, you don't need to know HTML.
+
+You can use the "**Edit this page on GitHub**" link to edit pages without creating a fork. Keep in mind that you can't upload images while working this way. You work on your change and propose it via a Pull Request (PR).
+
+Once you've created a Pull Request (PR), you can see a preview of the proposed changes by clicking *Details* against Netlify checker in the checkers section of the PR as soon as deployment is complete.
+
+For larger changes, we suggest that you clone the website repository. This way, you can review your changes locally. The process of working on the website is no different from working on Home Assistant itself.
+
+To test your changes locally, you need to install **Ruby** and its dependencies (gems):
+
+- [Install Ruby](https://www.ruby-lang.org/en/documentation/installation/) if you don't have it already. Ruby version 2.3.0 or higher is required.
+- Install `bundler`, a dependency manager for Ruby: `$ gem install bundler`
+- In your home-assistant.io root directory, run `$ bundle` to install the gems you need.
+
+Shortcut for Fedora: `$ sudo dnf -y install gcc-c++ ruby ruby-devel rubygem-bundler rubygem-json && bundle`
+Shortcut for Debian/Ubuntu: `$ sudo apt-get install ruby ruby-dev ruby-bundler ruby-json && bundle`
+
+Then you can work on the documentation:
+
+- Fork home-assistant.io [git repository](https://github.com/home-assistant/home-assistant.io).
+- Create/edit/update a page. The components/platforms documentation is located in `source/_components/`. `source/_docs/` contains the Home Assistant documentation itself. 
+- Test your changes to home-assistant.io locally: run `rake preview` and navigate to [http://127.0.0.1:4000](http://127.0.0.1:4000)
+- Create a Pull Request (PR) against the **next** branch of home-assistant.io if your documentation is a new feature, platform, or component.
+- Create a Pull Request (PR) against the **current** branch of home-assistant.io if you fix stuff, create Cookbook entries, or expand existing documentation.
+
+It could be necessary that you run `rake generate` prior to `rake preview` for the very first preview.
+
+Site generated by `rake` is only available locally. If you are developing on a headless machine, use port forwarding:
+
+```bash
+$ ssh -L 4000:localhost:4000 user_on_headless_machine@ip_of_headless_machine
+```
+## Speeding up site generation
+
+Every release we post long changelogs to the website. This slows down generation of the website significantly! We include some tools to temporarily exclude components and blog posts that you're not working on out of the way.
+
+```bash
+bundle exec rake isolate[filename-of-blogpost-or-component]
+```
+
+When you're done working on the site, run the following command to move the pages back again:
+
+```bash
+bundle exec rake integrate
+```

website/versioned_docs/version-0.80.0/documentation_standards.md

@@ -0,0 +1,126 @@
+---
+title: Standards
+id: version-0.80.0-documentation_standards
+original_id: documentation_standards
+---
+
+To ensure that the documentation for Home Assistant is consistent and easy to follow for both novice and expert users, we ask that you follow a very strict set of standards for developing the documentation.
+
+## General Documentation
+
+* The language of the documentation should be American-English.
+* Don't put two spaces after a period and avoid the "Oxford comma".
+* There is no limit for the line length. You are allowed to write in a flowing text style. This will make it easier to use the GitHub online editor in the future.
+* Be objective and not gender favoring, polarizing, race related or religion inconsiderate.
+* The case of brand names, services, protocols, components, and platforms must match its respective counterpart. e.g., "Z-Wave" **not** "Zwave", "Z-wave", "Z Wave" or "ZWave". Also, "Input Select" **not** "input select" or "Input select".
+* All headings should use the `{% linkable_title %}` tag.
+* Do not use ALL CAPITALS for emphasis - use italics instead
+
+## Component and Platform Pages
+
+* The **Configuration Variables** section must use the `{% configuration %}` tag.
+* Configuration variables must document the requirement status (`false` or `true`)
+* Configuration variables must document the default value, if any.
+* Configuration variables must document the accepted value types (see [Configuration variables details](documentation_create_page.md#configuration))
+  * For configuration variables that accept multiple types, separate the types with a comma (i.e. `string, int`).
+* Use YAML sequence syntax in the sample code if it is supported.
+* All examples should be formatted to be included in `configuration.yaml` unless explicitly stated.
+  * Use capital letters and `_` to indicate that the value needs to be replaced. E.g., `api_key: YOUR_API_KEY` or `api_key: REPLACE_ME`.
+  * If you know that the API key or value contains [control characters](https://en.wikipedia.org/wiki/YAML#Syntax), e.g., `#`, `[`, `?`, etc., wrap it in quotes and add a note.
+* Component and platform names should be a link to their respective documentation pages.
+
+Example configuration block
+
+```yaml
+{% configuration %}
+some_key:
+  description: This is a description of what this key is for.
+  required: false
+  type: string
+  default: Optional default value - leave out if there isn't one
+{% endconfiguration %}
+```
+
+## Templates
+
+* All examples containing Jinja2 templates should be wrapped **outside** of the code markdown with the `{% raw %}` tag.
+* Do not use `states.switch.source.state` in templates. Instead use `states()` and `is_state()`.
+* Use double quotes (`"`) for ([more information](#single-vs-double-quotation-marks)):
+  * `friendly_name`
+  * Single-line templates:
+    * `value_template`
+    * `level_template`
+    * `icon_template`
+    * Children of `data_template`
+* Use single quotes (`'`) for ([more information](#single-vs-double-quotation-marks):
+  * Strings inside of templates:
+    * States
+    * Entity IDs
+  * `unit_of_measurement`
+* No whitespace around pipe character (`|`) for Jinja2 filters.
+* Single whitespace after Jinja2 opening delimiters ({% raw %}`{{`{% endraw %}).
+* Single whitespace before Jinja2 closing delimiters ({% raw %}`}}`{% endraw %}).
+* Do not quote values for:
+  * `device_class`
+  * `platform`
+  * `condition`
+  * `service`
+
+## Renaming Pages
+
+It can happen that a component or platform is renamed, in this case the documentation needs to be updated as well. If you rename a page, add  `redirect_from:` to the file header and let it point to the old location/name of the page. Please consider to add details, like release number or old component/platform name, to the page in a [note](/developers/documentation/create_page/#html).
+
+```text
+---
+...
+redirect_from: /getting-started/android/
+---
+```
+
+Adding a redirect also applies if you move content around in the [documentation](/docs/).
+
+## Single vs. Double Quotation Marks
+
+Use single quotes (`'`) for strings inside of a template. It is more obvious to escape a single quote when necessary (i.e. `name` is a possessive noun), because the single quotes that wrap the string are closer in position to the apostrophe inside the string. Use double quotes (`"`) outside of a template (unless it is a multi-line template, in which case outside quotes are not required).
+
+### Examples
+
+#### Double Quotes Outside, Single Quotes Inside (Valid)
+
+```yaml
+automation:
+  ...
+  action:
+    - service: notify.notify
+      data_template:
+        message: "{% if trigger.to_state.name == 'Dale\'s Bedroom' %}Someone's in your base, killing your noobs!{% else %}It's just another door.{% endif %}"
+```
+
+#### Single Quotes Outside, Double Quotes Inside (Invalid)
+
+```yaml
+automation:
+  ...
+  action:
+    - service: notify.notify
+      data_template:
+        message: '{% if trigger.to_state.name == "Dale's Bedroom" %}Someone's in your base, killing your noobs!{% else %}It's just another door.{% endif %}'
+```
+
+#### Multi-Line Template (Valid)
+
+
+```yaml
+automation:
+  ...
+  action:
+    - service: notify.notify
+      data_template:
+        message: >-
+          {% if trigger.to_state.name == 'Dale\'s Bedroom' %}
+            Someone's in your base, killing your noobs!
+          {% else %}
+            It's just another door.
+          {% endif %}
+```
+

website/versioned_docs/version-0.80.0/entity_sensor.md

@@ -0,0 +1,30 @@
+---
+title: Sensor Entity
+sidebar_label: Sensor
+id: version-0.80.0-entity_sensor
+original_id: entity_sensor
+---
+
+A sensor is a read-only entity that provides some information. Information has a value and optionally, a unit of measurement.
+
+## Properties
+
+> Properties should always only return information from memory and not do I/O (like network requests). Implement `update()` or `async_update()` to fetch data.
+
+| Name | Type | Default | Description
+| ---- | ---- | ------- | -----------
+| state | string | **Required** | The value of the sensor.
+| unit_of_measurement | string | `None` | The unit of measurement that the sensor is expressed in.
+| device_class | string | `None` | Type of sensor.
+
+### Available device classes
+
+If specifying a device class, your sensor entity will need to also return the correct unit of measurement.
+
+| Type | Unit | Description
+| ---- | ---- | -----------
+| battery | % | % of battery that is left.
+| humidity | % | % of humidity in the air.
+| illuminance | lx/lm | Light level.
+| temperature | C/F | Temperature.
+| pressure | hPa,mbar | Pressure.

website/versioned_docs/version-0.80.0/entity_water_heater.md

@@ -0,0 +1,47 @@
+---
+title: Water Heater Entity
+sidebar_label: Water Heater
+id: version-0.80.0-entity_water_heater
+original_id: entity_water_heater
+---
+
+## Properties
+
+> Properties should always only return information from memory and not do I/O (like network requests). Implement `update()` or `async_update()` to fetch data.
+
+| Name | Type | Default | Description
+| ---- | ---- | ------- | -----------
+| min_temp | float | 110°F | The minimum temperature that can be set.
+| max_temp | float | 140°F | The maximum temperature that can be set.
+| temperature | float | none | The current temperature in °C or °F.
+| operation_mode | string | none | The current operation mode.
+| operation_list | list | none | List of possible operation modes.
+| away_mode | string | none | The current status of away mode. (on, off)
+
+The allowed operation modes are specified in the base component and implementations of the water_heater component cannot differ.
+
+Properties have to follow the units defined in the `unit_system`.
+
+## States
+| State | Description
+| ----- | -----------
+| `STATE_ECO` | Energy efficient mode, provides energy savings and fast heating.
+| `STATE_ELECTRIC` | Electric only mode, uses the most energy.
+| `STATE_PERFORMANCE` | High performance mode.
+| `STATE_HIGH_DEMAND` | Meet high demands when water heater is undersized.
+| `STATE_HEAT_PUMP` | Slowest to heat, but uses less energy.
+| `STATE_GAS` | Gas only mode, uses the most energy.
+| `STATE_OFF` | The water heater is off.
+
+## Methods
+### `set_temperature` or `async_set_temperature`
+Sets the temperature the water heater should heat water to.
+
+### `set_operation_mode`or `async_set_operation_mode`
+Sets the operation mode of the water heater. Must be in the operation_list.
+
+### `turn_away_mode_on` or `async_turn_away_mode_on`
+Set the water heater to away mode.
+
+### `turn_away_mode_off` or `async_turn_away_mode_off`
+Set the water heater back to the previous operation mode. Turn off away mode.

website/versioned_docs/version-0.80.0/frontend_architecture.md

@@ -0,0 +1,64 @@
+---
+title: Home Assistant Frontend Architecture
+sidebar_label: Architecture
+id: version-0.80.0-frontend_architecture
+original_id: frontend_architecture
+---
+
+The Home Assistant frontend is built using web components. This is a modern web technology allowing us to encapsulate templates, styling and logic into a single file and expose it as an HTML tag in the browser. These componens are composable, allowing a very dynamic and powerful foundation of our application.
+
+## Structure
+
+The Home Assistant frontend can be broken up in 4 parts:
+
+### Bootstrap
+
+File: `src/entrypoints/core.js`
+
+This is a very tiny script which is the first thing that is loaded on the page. It is responsible for checking for authentication credentials and setting up the websocket connection with the backend.
+
+The script allows us to start downloading the data while also downloading the rest of the UI in parallel.
+
+### App shell
+
+File: `src/entrypoints/app.js`
+
+This is everything that is required to render the sidebar and handle the routing.
+
+### Panels
+
+Folder: `src/panels/`
+
+Each page in Home Assistant is a panel. Components can register extra panels to be shown to the user. Examples of panels are "states", "map", "logbook" and "history".
+
+### More info dialog
+
+Folder: `src/dialogs/more-info`
+
+This is a dialog that allows users to see more information about an entity and control its state.
+
+The more info dialog can be triggered from any component in the app by firing a DOM event `hass-more-info` with as detail `{ entityId: 'light.kitchen' }`.
+
+## Data Flow
+
+The frontend leverages the [Websocket API](external_api_websocket.md) and the [Rest API](external_api_rest.md) to interact with Home Assistant.
+
+The data is made available as the `hass` property which is passed down to every component. The `hass` property contains the whole application state and has methods to call APIs.
+
+We use a unidirectional data flow (like Flux, Redux). When you make a change in the backend (like turning on a light), the `hass` object will be updated at the root of the application and will be made available to every component that needs it.
+
+## Routing
+
+The frontend uses decentralized routing. Each component only knows enough about the routing to know how to handle the part it's responsible for. Further routing is passed down the component tree.
+
+For example, the `<home-assistant>` main component will look at the first part of the url to decide which panel should be loaded. Each panel can have its own mapping between the url and what content to show.
+
+For the routing, we use the [`<app-route>`](https://www.polymer-project.org/3.0/toolbox/routing) web component.
+
+## Bundling
+
+We use Webpack to bundle up the application. We have various gulp scripts to help with generating the icon set and the index.html.
+
+We're aggresively code splitting our application by leveraging the dynamic import syntax (`import('path/to/some/file.js')`). When encountering an `import()`, Webpack will split the code into different chunks and makes sure that they are loaded when needed.
+
+

website/versioned_docs/version-0.80.0/hassio_addon_communication.md

@@ -0,0 +1,44 @@
+---
+title: Add-On Communication
+id: version-0.80.0-hassio_addon_communication
+original_id: hassio_addon_communication
+---
+
+There are different ways for communication between add-ons inside Hass.io.
+
+## Network
+
+We use an internal network that allows to communicate with every add-on, even to/from Home Assistant, by using its name or alias. Only the add-ons which run on the host network are a bit limited. These can talk with all internal add-ons by their name but all other add-on can't address these add-on by name - using an alias works for both!
+
+Name/alias are used for communication inside Hass.io.
+The name is generated using the following format: `{REPO}_{SLUG}`, e.g., `local_xy` or `3283fh_myaddon`. In this example, `{SLUG}` is defined in an add-ons `config.json`. You can use this name also as DNS name but you need replace the `_` with `-` to have a valid hostname. If an add-on is installed locally, `{REPO}` will be `local`. If the add-on is installed from a Github repository, `{REPO}` is a hashed identifier generated from the GitHub repository's URL (ex: https://github.com/xy/my_hassio_addons). See [here](https://github.com/home-assistant/hassio/blob/587047f9d648b8491dc8eef17dc6777f81938bfd/hassio/addons/utils.py#L17) to understand how this identifier is generated. Note that this identifier is required in certain service calls that use the [Hass.io add-on API][hassio-addon-api]. You can view the repository identifiers for all currently installed add-ons via a GET request to the hassio API `addons` endpoint.
+
+Use `hassio` for communication with the internal API.
+
+## Home Assistant
+
+An add-on can talk to the [Home Assistant API][hass-api] using the internal proxy. That makes it very easy to communicate with the API without knowing the password, port or any other information of the Home Assistant instance. Use this URL: `http://hassio/homeassistant/api` and internal communication is redirected to the right place. The next stept is to add `homeassistant_api: true` to `config.json` and read the environment variable `HASSIO_TOKEN` and use this as Home-Assistant password.
+
+There is also a proxy for the [Home Assistant Websocket API][hass-websocket]. It works like the API proxy above and requires `HASSIO_TOKEN` as password. Use this URL: `http://hassio/homeassistant/websocket`.
+
+It is also possible to talk direct to the Home Assistant instance which is named `homeassistant` over the internal network. But you need to know the configuration that is used by the running instance.
+
+We have severals services for Hass.io inside Home Assistant to run tasks. To send data over STDIN to an add-on use the `hassio.addon_stdin` service.
+
+## Hass.io API
+
+To enables calls to the [Hass.io API][hassio-api], add `hassio_api: true` to `config.json` and read the environment variable `HASSIO_TOKEN`. Now you can use the API over the URL: `http://hassio/`. Use the `HASSIO_TOKEN` with header `X-HASSIO-KEY`. It could be that you need also change the Hass.io API role like `hassio_role: default`.
+
+Add-ons can call some API commands without need set `hassio_api: true`:
+- `/homeassistant/api`
+- `/homeassistant/websocket`
+- `/homeassistant/stream`
+- `/addons/self/*`
+- `/services*`
+- `/discovery*`
+- `/info`
+
+[hass-api]: https://www.home-assistant.io/developers/rest_api/
+[hass-websocket]: https://www.home-assistant.io/developers/websocket_api/
+[hassio-api]: https://github.com/home-assistant/hassio/blob/master/API.md
+[hassio-addon-api]: https://github.com/home-assistant/hassio/blob/dev/API.md#restful-for-api-addons

website/versioned_docs/version-0.80.0/hassio_addon_config.md

@@ -0,0 +1,209 @@
+---
+title: Add-On Configuration
+id: version-0.80.0-hassio_addon_config
+original_id: hassio_addon_config
+---
+
+Each add-on is stored in a folder. The file structure looks like this:
+
+```text
+addon_name/
+  build.json
+  CHANGELOG.md
+  config.json
+  Dockerfile
+  icon.png
+  logo.png
+  README.md
+  run.sh
+```
+
+## Add-on script
+
+As with every Docker container, you will need a script to run when the container is started. A user might run many add-ons, so it is encouraged to try to stick to Bash scripts if you're doing simple things.
+
+When developing your script:
+
+ - `/data` is a volume for persistent storage.
+ - `/data/options.json` contains the user configuration. You can use `jq` inside your shell script to parse this data. However, you might have to install `jq` as a separate package in your container (see `Dockerfile` below).
+
+```bash
+CONFIG_PATH=/data/options.json
+
+TARGET="$(jq --raw-output '.target' $CONFIG_PATH)"
+```
+
+So if your `options` contain
+```json
+{ "target": "beer" }
+```
+then there will be a variable `TARGET` containing `beer` in the environment of your bash file afterwards.
+
+## Add-on Docker file
+
+All add-ons are based on Alpine Linux 3.6. Hass.io will automatically substitute the right base image based on the machine architecture. Add `tzdata` if you need run in a different timezone. `tzdata` Is is already added to our base images.
+
+```
+ARG BUILD_FROM
+FROM $BUILD_FROM
+
+ENV LANG C.UTF-8
+
+# Install requirements for add-on
+RUN apk add --no-cache jq
+
+# Copy data for add-on
+COPY run.sh /
+RUN chmod a+x /run.sh
+
+CMD [ "/run.sh" ]
+```
+
+If you don't use local build on device or our build script, make sure that the Dockerfile have also a set of labels include:
+```
+LABEL io.hass.version="VERSION" io.hass.type="addon" io.hass.arch="armhf|aarch64|i386|amd64"
+```
+
+It is possible to use own base image with `build.json` or if you do not need support for automatic multi-arch building you can also use a simple docker `FROM`.
+
+### Build Args
+
+We support the following build arguments by default:
+
+| ARG | Description |
+|-----|-------------|
+| BUILD_FROM | Hold image for dynamic builds or buildings over our systems.
+| BUILD_VERSION | Add-on version (read from `config.json`).
+| BUILD_ARCH | Hold current build arch inside.
+
+## Add-on config
+
+The config for an add-on is stored in `config.json`.
+
+```json
+{
+  "name": "xy",
+  "version": "1.2",
+  "slug": "folder",
+  "description": "long description",
+  "arch": ["amd64"],
+  "url": "website with more information about add-on (ie a forum thread for support)",
+  "startup": "application",
+  "boot": "auto",
+  "ports": {
+    "123/tcp": 123
+  },
+  "map": ["config:rw", "ssl"],
+  "options": {},
+  "schema": {},
+  "image": "repo/{arch}-my-custom-addon"
+}
+```
+
+| Key | Type | Required | Description |
+| --- | ---- | -------- | ----------- |
+| name | string | yes | Name of the add-on
+| version | string | yes | Version of the add-on
+| slug | string | yes | Slug of the add-on
+| description | string | yes | Description of the add-on
+| arch | list | no | List of supported arch: `armhf`, `aarch64`, `amd64`, `i386`. Default all.
+| url | url | no | Homepage of the addon. Here you can explain the add-ons and options.
+| startup | bool | yes | `initialize` will start addon on setup of Hass.io. `system` is for things like databases and not dependent on other things. `services` will start before Home Assistant, while `application` is started afterwards. Finally `once` is for applications that don't run as a daemon.
+| webui | string | no | A URL for web interface of this add-on. Like `http://[HOST]:[PORT:2839]/dashboard`, the port needs the internal port, which will be replaced with the effective port. It is also possible to bind the proto part to a config options with: `[PROTO:option_name]://[HOST]:[PORT:2839]/dashboard` and he lookup if they is True and going to `https`.
+| boot | string | yes | `auto` by system and manual or only `manual`
+| ports | dict | no | Network ports to expose from the container. Format is `"container-port/type": host-port`.
+| host_network | bool | no | If that is True, the add-on run on host network.
+| host_ipc | bool | no | Default False. Allow to share the IPC namespace with others.
+| host_dbus | bool | no | Default False. Map Host dbus service into add-on.
+| host_pid | bool | no | Default False. Allow to run container on host PID namespace. Work only for not protected add-ons.
+| devices | list | no | Device list to map into the add-on. Format is: `<path_on_host>:<path_in_container>:<cgroup_permissions>`. i.e. `/dev/ttyAMA0:/dev/ttyAMA0:rwm`
+| auto_uart | bool | no | Default False. Auto mapping all UART/Serial device from host into add-on.
+| hassio_role | str | no | Default `default`. Role based access to Hass.io API. Available: `default`, `homeassistant`, `backup`, `manager`, `admin`.
+| hassio_api | bool | no | This add-on can access to Hass.io REST API. It set the host alias `hassio`.
+| homeassistant_api | bool | no | This add-on can access to Hass.io Home-Assistant REST API proxy. Use `http://hassio/homeassistant/api`.
+| docker_api | bool | no | Allow read-oly access to docker API for add-on. Work only for not protected add-ons.
+| privileged | list | no | Privilege for access to hardware/system. Available access: `NET_ADMIN`, `SYS_ADMIN`, `SYS_RAWIO`, `SYS_TIME`, `SYS_NICE`, `SYS_RESOURCE`, `SYS_PTRACE`.
+| full_access | bool | no | Give full access to hardware like the privileged mode in docker. Work only for not protected add-ons.
+| apparmor | bool/string | no | Enable or disable AppArmor support. If it is enable, you can also use custom profiles with the name of the profile.
+| map | list | no | List of maps for additional Hass.io folders. Possible values: `config`, `ssl`, `addons`, `backup`, `share`. Defaults to `ro`, which you can change by adding `:rw` to the end of the name.
+| environment | dict | no | A dict of environment variable to run add-on.
+| audio | bool | no | Boolean. Mark this add-on to use internal an audio system. The ALSA configuration for this add-on will be mount automatic.
+| gpio | bool | no | Boolean. If this is set to True, `/sys/class/gpio` will map into add-on for access to GPIO interface from kernel. Some library need also `/dev/mem` and `SYS_RAWIO` for read/write access to this device. On system with AppArmor enabled, you need disable AppArmor or better for security, provide you own profile for the add-on.
+| devicetree | bool | no | Boolean. If this is set to True, `/device-tree` will map into add-on.
+| stdin | bool | no | Boolean. If that is enable, you can use the STDIN with Hass.io API.
+| legacy | bool | no | Boolean. If the docker image have no hass.io labels, you can enable the legacy mode to use the config data.
+| options | dict | yes | Default options value of the add-on
+| schema | dict | yes | Schema for options value of the add-on. It can be `False` to disable schema validation and use custom options.
+| image | string | no | For use with Docker Hub and other container registries.
+| timeout | integer | no | Default 10 (second). The timeout to wait until the docker is done or will be killed.
+| tmpfs | string | no | Mount a tmpfs file system in `/tmpfs`. Valide format for this option is : `size=XXXu,uid=N,rw`. Size is mandatory, valid units (`u`) are `k`, `m` and `g` and `XXX` has to be replaced by a number. `uid=N` (with `N` the uid number) and `rw` are optional.
+| discovery | list | no | A list of services they this Add-on allow to provide for Home Assistant. Currently supported: `mqtt`
+| services | list | no | A list of services they will be provided or consumed with this Add-on. Format is `service`:`function` and functions are: `provide` (this add-on can provide this service), `want` (this add-on can use this service) or `need` (this add-on need this service to work correctly).
+| login_backend | bool | no | Allow access to Home Assistent user backend.
+
+### Options / Schema
+
+The `options` dictionary contains all available options and their default value. Set the default value to `null` if the value is required to be given by the user before the add-on can start, and it show it inside default values. Only nested arrays and dictionaries are supported with a deep of two size. If you want make an option optional, put `?` to the end of data type, otherwise it will be a required value.
+
+```json
+{
+  "message": "custom things",
+  "logins": [
+    { "username": "beer", "password": "123456" },
+    { "username": "cheep", "password": "654321" }
+  ],
+  "random": ["haha", "hihi", "huhu", "hghg"],
+  "link": "http://example.com/",
+  "size": 15,
+  "count": 1.2
+}
+```
+
+The `schema` looks like `options` but describes how we should validate the user input. For example:
+
+```json
+{
+  "message": "str",
+  "logins": [
+    { "username": "str", "password": "str" }
+  ],
+  "random": ["match(^\w*$)"],
+  "link": "url",
+  "size": "int(5,20)",
+  "count": "float",
+  "not_need": "str?"
+}
+```
+
+We support:
+- str
+- bool
+- int / int(min,) / int(,max) / int(min,max)
+- float / float(min,) / float(,max) / float(min,max)
+- email
+- url
+- port
+- match(REGEX)
+
+## Add-on extended build
+
+Additional build options for an add-on is stored in `build.json`. This file will be read from our build systems.
+You need this only, if you not use the default images or need additionals things.
+
+```json
+{
+  "build_from": {
+    "armhf": "mycustom/base-image:latest"
+  },
+  "squash": false,
+  "args": {
+    "my_build_arg": "xy"
+  }
+}
+```
+
+| Key | Required | Description |
+| --- | -------- | ----------- |
+| build_from | no | A dictionary with the hardware architecture as the key and the base Docker image as value.
+| squash | no | Default `False`. Be carfully with this option, you can not use the image for caching stuff after that!
+| args | no | Allow to set additional Docker build arguments as a dictionary.

website/versioned_docs/version-0.80.0/hassio_addon_security.md

@@ -0,0 +1,34 @@
+---
+title: Add-on security
+id: version-0.80.0-hassio_addon_security
+original_id: hassio_addon_security
+---
+
+Hass.io rates every add-on based on the wanted rights. An add-on with a rating of 6 is very secure. If an add-on has a rating of 1, you shouldn't run this add-on unless you are 100% sure that you can trust the source.
+
+## API Role
+
+For access to Hass.io API you need define a role or you run in default mode. This is only required for Hass.io API not Home Assistant proxy. Any of the role have also the default API calls inheret for that are no settings are required.
+
+### Available Roles
+
+| Role | Description |
+|------|-------------|
+| default | Have access to all `info` calls |
+| homeassistant | Can access to all Home Assistant API endpoints |
+| backup | Can access to all snapshot API endpoints |
+| manager | Is for Add-ons they run CLIs and need extended rights |
+| admin | Have access to every API call. That is the only one they can disable/enable the Add-on protection mode |
+
+## Protection
+
+Default, all add-ons run in protection enabled mode. This mode prevents the add-on from getting any rights on the system. If an add-on requires more rights, you can disable this protection via the API add-on options for that add-on. But be carful, an add-on with disabled protection can destroy your system!
+
+## Making a secure add-on
+
+As a developer, follow the following best practices to make your add-on secure:
+
+- Don't run on host network
+- Create an AppArmor profile
+- Map folders read only if you don't need write access
+- If you need any API access, make sure you that you not grant to highest permission if you don't need it

website/versioned_docs/version-0.80.0/hassio_debugging.md

@@ -0,0 +1,50 @@
+---
+title: Debugging Hass.io
+id: version-0.80.0-hassio_debugging
+original_id: hassio_debugging
+---
+
+> This section is not for users. Use the [SSH add-on] to SSH into Hass.io. This is for <b>developers</b> of Hass.io. Do not ask for support if you are using these options.
+
+[SSH add-on]: https://www.home-assistant.io/addons/ssh/
+
+The following debug tips and tricks are for people who are running the Hass.io image and are working on the base image. If you use the generic Linux installer script, you should be able to access your host and logs as per your host.
+
+## SSH access to the host
+
+### resinOS based Hass.io (deprecated)
+Create an `authorized_keys` file containing your public key, and place it in the root of the boot partition of your SD card. Once the device is booted, you can access your device as root over SSH on port 22222.
+
+### HassOS based Hass.io
+Use a USB drive formatted with FAT, ext4, or NTFS and name it CONFIG (case sensitive). Create an `authorized_keys` file containing your public key, and place it in the root of the USB drive. From the UI, navigate to the hass.io system page and choose "Import from USB". You can now access your device as root over SSH on port 22222. Alternatively, the file will be imported from the USB when the hass.io device is rebooted.
+
+### Generating Keys
+Windows instructions how to generate and use private/public keys with Putty are [here][windows-keys]. Instead of the droplet instructions, add the public key as per above instructions.
+
+Alternative instructions, for Mac, Windows and Linux can be found [here](https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#platform-mac).
+
+Follow steps 1-4 under 'Generating a new SSH key' (The other sections are not applicable to Hass.io and can be ignored.)
+
+Step 3 in the link above, shows the path to the private key file `id_rsa` for your chosen operating system. Your public key, `id_rsa.pub`, is saved in the same folder. Next, select all text from text box "Public key for pasting into OpenSSH authorized_keys file" and save it to the root of your SD card as `authorized_keys`.
+
+> Make sure when you are copying the public key to the root of the /resin-boot partition of the SD card that you rename the file correctly to `authorized_keys` with no `.pub` file extension.
+
+You should then be able to SSH into your Hass.io device. On mac/linux, use:
+```
+ssh root@hassio.local -p 22222
+```
+
+## Checking the logs
+
+```bash
+# Logs from the supervisor service on the Host OS
+journalctl -f -u hassos-supervisor.service
+
+# Hass.io supervisor logs
+docker logs hassos_supervisor
+
+# Home Assistant logs
+docker logs homeassistant
+```
+
+[windows-keys]: https://www.digitalocean.com/community/tutorials/how-to-use-ssh-keys-with-putty-on-digitalocean-droplets-windows-users

website/versioned_docs/version-0.80.0/integration_quality_scale_index.md

@@ -0,0 +1,56 @@
+---
+title: Integration Quality Scale
+sidebar_label: Introduction
+id: version-0.80.0-integration_quality_scale_index
+original_id: integration_quality_scale_index
+---
+
+The Integration Quality Scale scores each integration based on the code quality and user experience. Each level of the quality scale consists of a list of requirements. If an integration matches all requirements, it's considered to have reached that level.
+
+> Suggestions for changes can be done by creating an issue in the [architecture repo](https://github.com/home-assistant/architecture/issues/).
+
+# No score
+
+This integration passes the bare minimum requirements to become part of the index.
+
+ - Satisfy all requirements for [creating components](creating_component_code_review.md) and [creating platforms](creating_platform_code_review.md).
+ - Configurable via `configuration.yaml`
+
+# Silver 🥈
+
+This integration is able to cope when things go wrong. It will not print any exceptions nor will it fill the log with retry attempts.
+
+- Set an appropriate `SCAN_INTERVAL` (if a polling integration)
+- Raise `PlatformNotReady` if unable to connect during platform setup (if appropriate)
+- Handles expiration of auth credentials. Refresh if possible or print correct error and fail setup. If based on a config entry, should trigger a new config entry flow to re-authorize.
+- Handles internet unavailable. Log a warning once when unavailable, log once when reconnected.
+- Handles device/service unavailable. Log a warning once when unavailable, log once when reconnected.
+- Set `available` property to `False` if appropriate ([docs](entity_index.md#generic-properties))
+- Entities have unique ID (if available) ([docs](entity_registry_index.md#unique-id-requirements))
+
+# Gold 🥇
+
+This is a solid integration that is able to survive poor conditions and can be configured via the user interface.
+
+- Configurable via config entries.
+  - Don't allow configuring already configured device/service (example: no 2 entries for same hub)
+  - Tests for the config flow
+  - Discoverable (if available)
+- Entities have device info (if available) ([docs](device_registry_index.md#defining-devices))
+- States are translated in the frontend (text-based sensors only, [docs](internationalization_index.md))
+- Tests for reading data from/controlling the integration ([docs](development_testing.md))
+- Has a code owner
+
+# Platinum 🏆
+
+Best of the best. The integration is completely async, meaning it's super fast. Integrations that reach platinum level will require  approval by the code owner for each PR.
+
+- Set appropriate `PARALLEL_UPDATES` constant
+- Support config entry unloading (called when config entry is removed)
+- Integration + dependency are async
+- Uses aiohttp and allows passing in websession (if making HTTP requests)
+
+# Internal 🏠
+
+Integrations which are part of Home Assistant are not rated but marked as **internal**.
+

website/versioned_sidebars/version-0.80.0-sidebars.json

@@ -0,0 +1,162 @@
+{
+  "version-0.80.0-Architecture": {
+    "Architecture": [
+      "version-0.80.0-architecture_index",
+      "version-0.80.0-architecture_components",
+      "version-0.80.0-architecture_entities",
+      "version-0.80.0-architecture_hassio"
+    ],
+    "Entities": [
+      "version-0.80.0-entity_index",
+      "version-0.80.0-entity_alarm_control_panel",
+      "version-0.80.0-entity_binary_sensor",
+      "version-0.80.0-entity_climate",
+      "version-0.80.0-entity_cover",
+      "version-0.80.0-entity_fan",
+      "version-0.80.0-entity_light",
+      "version-0.80.0-entity_lock",
+      "version-0.80.0-entity_media_player",
+      "version-0.80.0-entity_remote",
+      "version-0.80.0-entity_sensor",
+      "version-0.80.0-entity_switch",
+      "version-0.80.0-entity_vacuum",
+      "version-0.80.0-entity_water_heater",
+      "version-0.80.0-entity_weather"
+    ],
+    "Authentication": [
+      "version-0.80.0-auth_index",
+      "version-0.80.0-auth_permissions",
+      "version-0.80.0-auth_api",
+      "version-0.80.0-auth_auth_provider",
+      "version-0.80.0-auth_auth_module"
+    ],
+    "Configuration.yaml": [
+      "version-0.80.0-configuration_yaml_index"
+    ],
+    "Config Entries": [
+      "version-0.80.0-config_entries_index",
+      "version-0.80.0-config_entries_config_flow_handler"
+    ],
+    "Data Entry Flow": [
+      "version-0.80.0-data_entry_flow_index"
+    ],
+    "Entity Registry": [
+      "version-0.80.0-entity_registry_index"
+    ],
+    "Device Registry": [
+      "version-0.80.0-device_registry_index"
+    ]
+  },
+  "version-0.80.0-Extending Frontend": {
+    "Frontend": [
+      "version-0.80.0-frontend_index",
+      "version-0.80.0-frontend_architecture",
+      "version-0.80.0-frontend_development",
+      "version-0.80.0-frontend_data",
+      "version-0.80.0-frontend_external_auth"
+    ],
+    "Extending the frontend": [
+      "version-0.80.0-frontend_add_card",
+      "version-0.80.0-frontend_add_more_info",
+      "version-0.80.0-frontend_add_websocket_api"
+    ],
+    "Custom UI": [
+      "version-0.80.0-lovelace_custom_card",
+      "version-0.80.0-frontend_creating_custom_ui",
+      "version-0.80.0-frontend_creating_custom_panels"
+    ]
+  },
+  "version-0.80.0-Extending HASS": {
+    "Developing a feature": [
+      "version-0.80.0-development_index",
+      "version-0.80.0-development_environment",
+      "version-0.80.0-development_submitting",
+      "version-0.80.0-development_checklist",
+      "version-0.80.0-development_guidelines",
+      "version-0.80.0-development_testing",
+      "version-0.80.0-development_catching_up",
+      "version-0.80.0-development_validation",
+      "version-0.80.0-development_typing"
+    ],
+    "Development 101": [
+      "version-0.80.0-dev_101_index",
+      "version-0.80.0-dev_101_hass",
+      "version-0.80.0-dev_101_events",
+      "version-0.80.0-dev_101_states",
+      "version-0.80.0-dev_101_services",
+      "version-0.80.0-dev_101_config"
+    ],
+    "Integration Quality Scale": [
+      "version-0.80.0-integration_quality_scale_index"
+    ],
+    "Creating Platforms": [
+      "version-0.80.0-creating_platform_index",
+      "version-0.80.0-creating_platform_code_review",
+      "version-0.80.0-creating_platform_example_light",
+      "version-0.80.0-creating_platform_example_sensor"
+    ],
+    "Creating Components": [
+      "version-0.80.0-creating_component_index",
+      "version-0.80.0-creating_component_code_review",
+      "version-0.80.0-creating_component_deps_and_reqs",
+      "version-0.80.0-creating_component_events",
+      "version-0.80.0-creating_component_states",
+      "version-0.80.0-creating_component_discovery",
+      "version-0.80.0-creating_component_loading",
+      "version-0.80.0-creating_component_generic_discovery"
+    ]
+  },
+  "version-0.80.0-Misc": {
+    "Introduction": [
+      "version-0.80.0-misc"
+    ],
+    "External API": [
+      "version-0.80.0-external_api_rest",
+      "version-0.80.0-external_api_websocket",
+      "version-0.80.0-external_api_server_sent_events"
+    ],
+    "Internationalization": [
+      "version-0.80.0-internationalization_index",
+      "version-0.80.0-internationalization_backend_localization",
+      "version-0.80.0-internationalization_custom_component_localization",
+      "version-0.80.0-internationalization_translation"
+    ],
+    "Documentation": [
+      "version-0.80.0-documentation_index",
+      "version-0.80.0-documentation_standards",
+      "version-0.80.0-documentation_create_page"
+    ],
+    "Intents": [
+      "version-0.80.0-intent_index",
+      "version-0.80.0-intent_firing",
+      "version-0.80.0-intent_handling",
+      "version-0.80.0-intent_conversation",
+      "version-0.80.0-intent_builtin"
+    ],
+    "asyncio": [
+      "version-0.80.0-asyncio_index",
+      "version-0.80.0-asyncio_101",
+      "version-0.80.0-asyncio_categorizing_functions",
+      "version-0.80.0-asyncio_working_with_async"
+    ],
+    "Hass.io": [
+      "version-0.80.0-hassio_debugging",
+      "version-0.80.0-hassio_hass"
+    ],
+    "Hass.io Add-Ons": [
+      "version-0.80.0-hassio_addon_index",
+      "version-0.80.0-hassio_addon_tutorial",
+      "version-0.80.0-hassio_addon_config",
+      "version-0.80.0-hassio_addon_communication",
+      "version-0.80.0-hassio_addon_testing",
+      "version-0.80.0-hassio_addon_publishing",
+      "version-0.80.0-hassio_addon_presentation",
+      "version-0.80.0-hassio_addon_repository",
+      "version-0.80.0-hassio_addon_security"
+    ],
+    "Maintainer docs": [
+      "version-0.80.0-maintenance",
+      "version-0.80.0-releasing"
+    ]
+  }
+}

website/versions.json

@@ -1,4 +1,5 @@
 [
+  "0.80.0",
   "0.79.0",
   "0.78.0",
   "0.77.0",