jeans/developers.home-assistant
jeans/developers.home-assistant
1
0
Fork 0
mirror of https://github.com/home-assistant/developers.home-assistant.git synced 2025-07-09 10:26:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

0.87 (#177)

Browse Source
This commit is contained in:
Fabian Affolter 2019-02-08 10:40:51 +01:00 committed by GitHub
parent ea504a0fd9
commit 440d3b6e61
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 820 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
website/versioned_docs/version-0.87.0/area_registry_index.md Normal file
View File

@ -0,0 +1,13 @@
---
title: Area Registry
sidebar_label: Introduction
id: version-0.87.0-area_registry_index
original_id: area_registry_index
---
The area registry is a registry where Home Assistant keeps track of areas. An area represents a physical location for Home Assistant. It can be used to place devices in different areas.
| Attribute | Description |
| --------- | ----------- |
| id | Unique ID of area (generated by Home Assistant)
| name | Name of this area

112
website/versioned_docs/version-0.87.0/development_environment.md Normal file
View File

@ -0,0 +1,112 @@
---
title: Set up Development Environment
id: version-0.87.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
```bash
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
```
From Windows Store install Ubuntu.
When the Linux subsystem is set up, 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
```

75
website/versioned_docs/version-0.87.0/device_registry_index.md Normal file
View File

@ -0,0 +1,75 @@
---
title: Device Registry
sidebar_label: Introduction
id: version-0.87.0-device_registry_index
original_id: device_registry_index
---
The device registry is a registry where Home Assistant keeps track of devices. A device is represented in Home Assistant via one or more entities. For example, a battery-powered temperature and a humidity sensor might expose entities for temperature, humidity and battery level.
<img
src='/img/en/device_registry/overview.png'
alt='Device registry overview'
/>
| Attribute | Description |
| --------- | ----------- |
| id | Unique ID of device (generated by Home Assistant)
| name | Name of this device
| connections | A set of tuples of `(connection_type, connection identifier)`. Connection types are defined in the device registry module.
| identifiers | Set of identifiers. They identify the device in the outside world. An example is a serial number.
| manufacturer | The manufacturer of the device.
| model | The model of the device.
| config_entries | Config entries that are linked to this device.
| sw_version | The firmware version of the device.
| via_hub | Identifier of a device that routes messages between this device and Home Assistant. Examples of such devices are hubs. This is used to show device topology in Home Assistant.
| area_id | The Area which the device is placed in.
## Defining devices
> Entity device info is only read if the entity is loaded via a [config entry](config_entries_index.md).
Each entity is able to define a device via the `device_info` property. This property is read when an entity is added to Home Assistant via a config entry. A device will be be matched up with an existing device via supplied identifiers and connections, like serial numbers or MAC addresses.
```python
# Inside a platform
class HueLight(LightEntity):
@property
def device_info(self):
return {
'identifiers': {
# Serial numbers are unique identifiers within a specific domain
(hue.DOMAIN, self.unique_id)
},
'name': self.name,
'manufacturer': self.light.manufacturername,
'model': self.light.productname,
'sw_version': self.light.swversion,
'via_hub': (hue.DOMAIN, self.api.bridgeid),
}
```
Components are also able to register devices in the case that there are no entities representing them. An example is a hub that communicates with the lights.
```python
# Inside a component
from homeassistant.helpers import device_registry as dr
device_registry = await dr.async_get_registry(hass)
device_registry.async_get_or_create(
config_entry=entry.entry_id,
connections={
(dr.CONNECTION_NETWORK_MAC, config.mac)
},
identifiers={
(DOMAIN, config.bridgeid)
},
manufacturer='Signify',
name=config.name,
model=config.modelid,
sw_version=config.swversion,
)
```

150
website/versioned_docs/version-0.87.0/documentation_create_page.md Normal file
View File

@ -0,0 +1,150 @@
---
title: Create a new page
id: version-0.87.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.
### Components and platforms
If you have a component that is taking care of setting up platforms then you don't need to create a new page for every supported platform. Simply add all supported types to `ha_category:` and use `redirect_from:` to list the dummy URL of the platforms.
```text
...
ha_category:
- DIY
- Binary Sensor
- Switch
redirect_from:
- /components/binary_sensor.raspihats/
- /components/switch.raspihats/
---
...
```
### 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`.

126
website/versioned_docs/version-0.87.0/documentation_standards.md Normal file
View File

@ -0,0 +1,126 @@
---
title: Standards
id: version-0.87.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 %}
```

64
website/versioned_docs/version-0.87.0/frontend_architecture.md Normal file
View File

@ -0,0 +1,64 @@
---
title: Home Assistant Frontend Architecture
sidebar_label: Architecture
id: version-0.87.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 components 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/blog/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.

107
website/versioned_docs/version-0.87.0/frontend_development.md Normal file
View File

@ -0,0 +1,107 @@
---
title: Frontend development
sidebar_label: Development
id: version-0.87.0-frontend_development
original_id: frontend_development
---
The Home Assistant frontend is built using web components and powered by the [Polymer](https://www.polymer-project.org/) framework.
> Do not use development mode in production. Home Assistant uses aggressive caching to improve the mobile experience. This is disabled during development so that you do not have to restart the server in between changes.
## Setting up the environment
> All commands below need to be run from inside the home-assistant-polymer repository.
### Getting the code
First step is to fork the [home-assistant-polymer repository][hass-polymer] and add the upstream remote. You can place the forked repository anywhere on your system.
```bash
$ git clone https://github.com/YOUR_GIT_USERNAME/home-assistant-polymer.git
$ cd home-assistant-polymer
$ git remote add upstream https://github.com/home-assistant-polymer/home-assistant-polymer.git
```
### Configuring Home Assistant
You will need to have an instance of Home Assistant set up. See our guide on [setting up a development environment](https://developers.home-assistant.io/docs/en/development_environment.html).
Next step is to configure Home Assistant to use the development mode for the frontend. Do this by updating the frontend config in your `configuration.yaml` and set the path to the home-assistant-polymer repository that you cloned in the last step:
```yaml
frontend:
# Example absolute path: /home/paulus/dev/hass/home-assistant-polymer
development_repo: <absolute path to home-assistant-polymer repo>
```
### Installing Node.js
Node.js is required to build the frontend. The preferred method of installing node.js is with [nvm](https://github.com/creationix/nvm). Install nvm using the instructions in the [README](https://github.com/creationix/nvm#install-script), and install the correct node.js by running the following command:
```bash
$ nvm install
```
[Yarn](https://yarnpkg.com/en/) is used as the package manager for node modules. [Install yarn using the instructions here.](https://yarnpkg.com/en/docs/install)
Next, development dependencies need to be installed to bootstrap the frontend development environment. First activate the right Node version and then download all the dependencies:
```bash
$ nvm use
$ script/bootstrap
```
## Development
During development, you will need to run the development script to maintain a development build of the frontend that auto updates when you change any of the source files. To run this server, run:
```bash
$ nvm use
$ script/develop
```
Make sure you have cache disabled and correct settings to avoid stale content:
> Instructions are for Google Chrome
1. Disable cache by ticking the box in `Network` > `Disable cache`
<p class='img'>
<img src='/img/en/development/disable-cache.png' />
</p>
2. Enable Bypass for network in `Application` > `Service Workers` > `Bypass for network`
<p class='img'>
<img src='/img/en/development/bypass-for-network.png' />
</p>
## Creating pull requests
If you're planning on issuing a PR back to the Home Assistant codebase you need to fork the polymer project and add your fork as a remote to the Home Assistant Polymer repo.
```bash
$ git remote add fork <github URL to your fork>
```
When you've made your changes and are ready to push them change to the working directory for the polymer project and then push your changes
``` bash
$ git add -A
$ git commit -m "Added new feature X"
$ git push -u fork HEAD
```
## Building the Polymer frontend
If you're making changes to the way the frontend is packaged, it might be necessary to try out a new packaged build of the frontend in the main repository (instead of pointing it at the frontend repo). To do so, first build a production version of the frontend by running `script/build_frontend`.
To test it out inside Home assistant, run the following command from the main Home Assistant repository:
```bash
$ pip3 install -e /path/to/home-assistant-polymer/
$ hass --skip-pip
```
[hass-polymer]: https://github.com/home-assistant/home-assistant-polymer

172
website/versioned_sidebars/version-0.87.0-sidebars.json Normal file
View File

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

1
website/versions.json
View File

@ -1,4 +1,5 @@
[
"0.87.0",
"0.86.0",
"0.85",
"0.84.0",