mirror of
https://github.com/home-assistant/developers.home-assistant.git
synced 2025-07-23 09:16:32 +00:00
Release 0.73.0
This commit is contained in:
Paulus Schoutsen
parent
8ad362e792
commit
f599a713ba
89
website/versioned_docs/version-0.73.0/auth_api.md
Normal file
89
website/versioned_docs/version-0.73.0/auth_api.md
Normal file
@ -0,0 +1,89 @@
|
||||
---
|
||||
title: Authentication API
|
||||
sidebar_label: API
|
||||
id: version-0.73.0-auth_api
|
||||
original_id: auth_api
|
||||
---
|
||||
|
||||
> This is experimental. It is not persisted and is not yet intended for production.
|
||||
|
||||
This page will describe the steps required to fetch an access token for a user and how to refresh it. We follow the OAuth 2 specification.
|
||||
|
||||
## Requirements
|
||||
|
||||
A client needs to be created inside Home Assistant before a client can request users to authorize it or fetch a new access token. The only way currently to create a client is programmatically:
|
||||
|
||||
```python
|
||||
client = await hass.auth.async_get_or_create_client(
|
||||
'Example client',
|
||||
redirect_uris=['http://www.example.com/hass_callback']
|
||||
)
|
||||
print(client.id)
|
||||
```
|
||||
|
||||
## Authorize
|
||||
|
||||
[](https://www.websequencediagrams.com/?lz=dGl0bGUgQXV0aG9yaXphdGlvbiBGbG93CgpVc2VyIC0-IENsaWVudDogTG9nIGludG8gSG9tZSBBc3Npc3RhbnQKABoGIC0-IFVzZXI6AEMJZSB1cmwgAD4JACgOOiBHbyB0bwAeBWFuZCBhAC0ICgBQDgB1DACBFw5jb2RlAHELAE4RZXQgdG9rZW5zIGZvcgAoBgBBGlQAJQUK&s=qsd)
|
||||
|
||||
- The authorize url should contain `client_id`, `redirect_uri` and, if available, `client_secret` as query parameters. Example: `http://your-instance.com/auth/authorize?client_id=ABCDE&client_secret=QWERTY&redirect_uri=https%3A%2F%2Fexample.com%2Fhass_callback`
|
||||
- The user will navigate to this link, log into Home Assistant and authorize the client.
|
||||
- Once authorized, the user will be redirected back to the passed in redirect uri with the authorization code as part of the query parameters. Example: https://example.com/hass_callback?code=12345
|
||||
- This authorization code can be exchanged for tokens by sending it to the token endpoint (see next section).
|
||||
- As specified in the OAuth 2 specification, it is possible to pass an optional state string to the authorize url using the `state` query parameter. This string will be added as query parameter to the redirect url.
|
||||
|
||||
## Token
|
||||
|
||||
The token endpoint returns tokens given valid grants. This grant is either an authorization code retrieved from the authorize endpoint or a refresh token.
|
||||
|
||||
All interactions with this endpoint need to be HTTP POST requests to `http://your-instance.com/auth/token` with the request body encoded in `application/x-www-form-urlencoded`.
|
||||
|
||||
### Authorization code
|
||||
|
||||
Use the grant type `authorization_code` to retrieve the tokens after a user has successfully finished the authorize step. The request body is:
|
||||
|
||||
```
|
||||
grant_type=authorization_code&code=12345
|
||||
```
|
||||
|
||||
The return response will be an access and refresh token:
|
||||
|
||||
```json
|
||||
{
|
||||
"access_token": "ABCDEFGH",
|
||||
"expires_in": 1800,
|
||||
"refresh_token": "IJKLMNOPQRST",
|
||||
"token_type": "Bearer"
|
||||
}
|
||||
```
|
||||
|
||||
### Refresh token
|
||||
|
||||
Use the grant type `refresh_token` to retrieve an access token using a refresh token. The request body is:
|
||||
|
||||
```
|
||||
grant_type=refresh_token&refresh_token=QWERTY
|
||||
```
|
||||
|
||||
The return response will be an access token:
|
||||
|
||||
```json
|
||||
{
|
||||
"access_token": "ABCDEFGH",
|
||||
"expires_in": 1800,
|
||||
"token_type": "Bearer"
|
||||
}
|
||||
```
|
||||
|
||||
## Making authenticated requests
|
||||
|
||||
Once you have an access token, you can make authenticated requests to the Home Assistant APIs.
|
||||
|
||||
For the websocket connection, pass the access token in the [authentication message](http://localhost:3000/docs/en/external_api_websocket.html#authentication-phase).
|
||||
|
||||
For HTTP requests, pass the token type and access token as the authorization header:
|
||||
|
||||
```
|
||||
Authorization: Bearer ABCDEFGH
|
||||
```
|
||||
|
||||
If the access token is no longer valid, you will get a response with HTTP status code 401 unauthorized. This means that you will need to refresh the token. If the refresh token doesn't work, the tokens are no longer valid and the client should ask the user to authorize again.
|
||||
@ -0,0 +1,85 @@
|
||||
---
|
||||
title: Style guidelines
|
||||
id: version-0.73.0-development_guidelines
|
||||
original_id: development_guidelines
|
||||
---
|
||||
|
||||
Home Assistant enforces strict [PEP8 style](https://www.python.org/dev/peps/pep-0008/) and [PEP 257 (Docstring Conventions)](https://www.python.org/dev/peps/pep-0257/) compliance on all code submitted. We automatically test every pull request as part of the linting process with [Coveralls](https://coveralls.io/github/home-assistant/home-assistant) and [Travis CI](https://travis-ci.org/home-assistant/home-assistant).
|
||||
|
||||
Summary of the most relevant points:
|
||||
|
||||
- Line length is limited to 79 characters (see below).
|
||||
- Use 4 spaces per indentation level. We don't use tabs.
|
||||
- Comments should be full sentences and end with a period.
|
||||
- [Imports](https://www.python.org/dev/peps/pep-0008/#imports) should be ordered.
|
||||
- Constants and the content of lists and dictionaries should be in alphabetical order.
|
||||
- Avoid trailing whitespace but surround binary operators with a single space.
|
||||
- Line separator should be set to `LF`.
|
||||
|
||||
The maximum line length comes directly from the [PEP8 style guide](https://www.python.org/dev/peps/pep-0008/#maximum-line-length), and is also used by the Python standard library. All code must pass these linting checks, and no exceptions will be made. There have already been numerous requests to increase the maximum line length, but after evaluating the options, the Home Assistant maintainers have decided to stay at 79 characters. This decision is final.
|
||||
|
||||
Those points may require that you adjust your IDE or editor settings.
|
||||
|
||||
## Our recommendations
|
||||
|
||||
For some cases [PEPs](https://www.python.org/dev/peps/) don't make a statement. This section covers our recommendations about the code style. Those points were collected from the existing code and based on what contributors and developers were using the most. This is basically a majority decision, thus you may not agree with it. But we would like to encourage you follow those recommendations to keep the code unified.
|
||||
|
||||
### Quotes
|
||||
|
||||
Use single quotes `'` for single word and `"` for multiple words or sentences.
|
||||
|
||||
```python
|
||||
ATTR_WATERLEVEL = 'level'
|
||||
CONF_ATTRIBUTION = "Data provided by the WUnderground weather service"
|
||||
SENSOR_TYPES = {
|
||||
'alerts': ['Alerts', None],
|
||||
}
|
||||
```
|
||||
|
||||
### File headers
|
||||
|
||||
The docstring in the file header should contain a link to the documentation to make it easy to find further information, especially about the configuration or details which are not mentioned in the code.
|
||||
|
||||
```python
|
||||
"""
|
||||
Support for MQTT lights.
|
||||
|
||||
For more details about this platform, please refer to the documentation at
|
||||
https://home-assistant.io/components/light.mqtt/
|
||||
"""
|
||||
```
|
||||
|
||||
### Requirements
|
||||
|
||||
Please place [Platform requirements](creating_platform_code_review.md#1-requirements) right after the imports.
|
||||
|
||||
```python
|
||||
[...]
|
||||
from homeassistant.helpers.entity import Entity
|
||||
|
||||
REQUIREMENTS = ['xmltodict==0.11.0']
|
||||
```
|
||||
|
||||
### Log messages
|
||||
|
||||
There is no need to add the platform or component name to the log messages. This will be added automatically. Like `syslog` messages there shouldn't be any period at the end. Try to avoid brackets and additional quotes around the output to make it easier for users to parse the log. A widely style is shown below but you are free to compose the messages as you like.
|
||||
|
||||
```python
|
||||
_LOGGER.error("No route to device: %s", self._resource)
|
||||
```
|
||||
|
||||
```bash
|
||||
2017-05-01 14:28:07 ERROR [homeassistant.components.sensor.arest] No route to device: 192.168.0.18
|
||||
```
|
||||
|
||||
Don't print out wrong API keys, tokens, usernames, or passwords.
|
||||
Also note that `_LOGGER.info` is reserved for the core, use `_LOGGER.debug` in anything else.
|
||||
|
||||
### Ordering of imports
|
||||
|
||||
Instead of order the imports manually, use [`isort`](https://github.com/timothycrosley/isort).
|
||||
|
||||
```bash
|
||||
$ pip3 install isort
|
||||
$ isort homeassistant/components/sensor/fixer.py
|
||||
```
|
||||
@ -0,0 +1,122 @@
|
||||
---
|
||||
title: Create a new page
|
||||
id: version-0.73.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
|
||||
---
|
||||
|
||||
Content...Written in markdown.
|
||||
|
||||
### {% linkable_title Linkable Header %}
|
||||
...
|
||||
```
|
||||
|
||||
There are [pre-definied 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.
|
||||
- If you're adding a new component, for the `ha_release` part of the header, just increment of the current release. 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:` is needed to list the platform or component in the appropriate category on the website.
|
||||
|
||||
### 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 {% raw %}`{% configuration %} ... {% endconfiguration %}`{% endraw %} 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: list
|
||||
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: `string`, `int`, `time`, `template` or `map`. For multiple possibilities use `[string, int]`. If you use `map` then you need to define `keys:` (see the [`template` sensor](/components/sensor.template/) for an example).
|
||||
- **`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 {% raw %}`{% endraw %}.
|
||||
|
||||
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/) is [Jinja](http://jinja.pocoo.org/) 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 `home-assistant.github.io/source/_includes/asides/docs_navigation.html`.
|
||||
38
website/versioned_docs/version-0.73.0/documentation_index.md
Normal file
38
website/versioned_docs/version-0.73.0/documentation_index.md
Normal file
@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Documentation
|
||||
id: version-0.73.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 about 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.
|
||||
|
||||
For larger changes, we suggest that you clone the website repository. This way, you can review your changes locally. The process for working on the website is no different from working on Home Assistant itself. You work on your change and propose it via a Pull Request (PR).
|
||||
|
||||
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.github.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`
|
||||
|
||||
Then you can work on the documentation:
|
||||
|
||||
- Fork home-assistant.io [git repository](https://github.com/home-assistant/home-assistant.github.io).
|
||||
- Create/edit/update a page in the directory `source/_components/` for your platform/component.
|
||||
- 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.github.io if your documentation is a new feature, platform, or component.
|
||||
- Create a Pull Request (PR) against the **current** branch of home-assistant.github.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
|
||||
```
|
||||
|
||||
112
website/versioned_docs/version-0.73.0/documentation_standards.md
Normal file
112
website/versioned_docs/version-0.73.0/documentation_standards.md
Normal file
@ -0,0 +1,112 @@
|
||||
---
|
||||
title: Standards
|
||||
id: version-0.73.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".
|
||||
* 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.
|
||||
|
||||
## Component and Platform Pages
|
||||
|
||||
* The **Configuration Variables** section must use the `{% configuration %}` tag.
|
||||
* Configuration variables must document the requirement status.
|
||||
* Configuration variables must document the default value, if any.
|
||||
* Configuration variables must document the accepted value types.
|
||||
* 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.
|
||||
|
||||
## 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
|
||||
|
||||
#### {% linkable_title 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 %}
|
||||
```
|
||||
|
||||
104
website/versioned_docs/version-0.73.0/frontend_development.md
Normal file
104
website/versioned_docs/version-0.73.0/frontend_development.md
Normal file
@ -0,0 +1,104 @@
|
||||
---
|
||||
title: Frontend development
|
||||
sidebar_label: Development
|
||||
id: version-0.73.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 git clone the [home-assistant-polymer repository][hass-polymer]. You can place the repository anywhere on your system.
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/home-assistant/home-assistant-polymer.git
|
||||
$ cd home-assistant-polymer
|
||||
```
|
||||
|
||||
### Configuring Home Assistant
|
||||
|
||||
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
|
||||
202
website/versioned_docs/version-0.73.0/hassio_addon_config.md
Normal file
202
website/versioned_docs/version-0.73.0/hassio_addon_config.md
Normal file
@ -0,0 +1,202 @@
|
||||
---
|
||||
title: Add-On Configuration
|
||||
id: version-0.73.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.
|
||||
| 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_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`.
|
||||
| privileged | list | no | Privilege for access to hardware/system. Available access: `NET_ADMIN`, `SYS_ADMIN`, `SYS_RAWIO`, `SYS_TIME`, `SYS_NICE`
|
||||
| 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.
|
||||
| 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.
|
||||
| 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.
|
||||
|
||||
### 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.
|
||||
216
website/versioned_docs/version-0.73.0/lovelace_custom_card.md
Normal file
216
website/versioned_docs/version-0.73.0/lovelace_custom_card.md
Normal file
@ -0,0 +1,216 @@
|
||||
---
|
||||
title: Custom Cards
|
||||
id: version-0.73.0-lovelace_custom_card
|
||||
original_id: lovelace_custom_card
|
||||
---
|
||||
|
||||
You're not just limited to the cards that we decided to include in the Lovelace UI. You can build and use your own!
|
||||
|
||||
## API
|
||||
|
||||
- You define your custom card as a [custom element](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements). It's up to you to decide how to render your DOM inside your element. You can use Polymer, Angular, Preact or any other popular framework (except for React – more info [here](https://custom-elements-everywhere.com/)).
|
||||
- Home Assistant will set the `config` property when the configuration changes (rare).
|
||||
- Home Assistant will set the `hass` property when the state of Home Assistant changes (frequent). Whenever the state changes, the component will have to update itself to represent the latest state.
|
||||
- Home Assistant will call `getCardSize()` to request the size of the card. Size of the card is used for the automatic distribution of cards across columns. Both `config` and `hass` properties will be available. Defaults to `1` if function is not defined.
|
||||
|
||||
You define your custom card as a [custom element](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements). It's up to you to decide how to render your DOM inside your element. You can use Polymer, Angular, Preact or any other popular framework (except for React – [more info here](https://custom-elements-everywhere.com/)).
|
||||
|
||||
```js
|
||||
const element = document.createElement('some-custom-card');
|
||||
```
|
||||
|
||||
Home Assistant will call `setConfig(config)` when the configuration changes (rare). If you throw an exception if the configuration is invalid, an error card will render to notify the user.
|
||||
|
||||
```js
|
||||
try {
|
||||
element.setConfig(config);
|
||||
} catch (err) {
|
||||
showErrorCard(err.message, config);
|
||||
}
|
||||
```
|
||||
|
||||
Home Assistant will set the `hass` property when the state of Home Assistant changes (frequent). Whenever the state changes, the component will have to update itself to represent the latest state.
|
||||
|
||||
```js
|
||||
element.hass = hass;
|
||||
```
|
||||
|
||||
Your card can define a `getCardSize` method that returns the size of your card as a number. A height of 1 is equivalent to 50 pixels. This will help Home Assistant distribute the cards evenly over the columns. A card size of `1` will be assumed if the method is not defined.
|
||||
|
||||
```js
|
||||
if ('getCardSize' in element) {
|
||||
return element.getCardSize();
|
||||
} else {
|
||||
return 1;
|
||||
}
|
||||
```
|
||||
|
||||
## Defining your card
|
||||
|
||||
Create a new file in your Home Assistant config dir as `<config>/www/content-card-example.js` and put in the following contents:
|
||||
|
||||
```js
|
||||
class ContentCardExample extends HTMLElement {
|
||||
set hass(hass) {
|
||||
if (!this.content) {
|
||||
const card = document.createElement('ha-card');
|
||||
card.header = 'Example card';
|
||||
this.content = document.createElement('div');
|
||||
this.content.style.padding = '0 16px 16px';
|
||||
card.appendChild(this.content);
|
||||
this.appendChild(card);
|
||||
}
|
||||
|
||||
const entityId = this.config.entity;
|
||||
const state = hass.states[entityId];
|
||||
const stateStr = state ? state.state : 'unavailable';
|
||||
|
||||
this.content.innerHTML = `
|
||||
The state of ${entityId} is ${stateStr}!
|
||||
<br><br>
|
||||
<img src="http://via.placeholder.com/350x150">
|
||||
`;
|
||||
}
|
||||
|
||||
setConfig(config) {
|
||||
if (!config.entity) {
|
||||
throw new Error('You need to define an entity');
|
||||
}
|
||||
this.config = config;
|
||||
}
|
||||
|
||||
// The height of your card. Home Assistant uses this to automatically
|
||||
// distribute all cards over the available columns.
|
||||
getCardSize() {
|
||||
return 3;
|
||||
}
|
||||
}
|
||||
|
||||
customElements.define('content-card-example', ContentCardExample);
|
||||
```
|
||||
|
||||
## Referencing your new card
|
||||
|
||||
In our example card we defined a card with the tag `content-card-example` (see last line), so our card type will be `custom:content-card-example`. And because you created the file in your `<config>/www` directory, it will be accessible in your browser via the url `/local/`.
|
||||
|
||||
```yaml
|
||||
# Example ui-lovelace.yaml
|
||||
resources:
|
||||
- url: /local/content-card-example.js
|
||||
type: js
|
||||
views:
|
||||
- name: Example
|
||||
cards:
|
||||
- type: "custom:content-card-example"
|
||||
entity: input_boolean.switch_tv
|
||||
```
|
||||
|
||||
## Advanced example
|
||||
|
||||
Resources to load in Lovelace can be imported as a JS script, an HTML import or as a JS module import. Below is an example of a custom card using JS modules that does all the fancy things.
|
||||
|
||||
|
||||
|
||||
Create a new file in your Home Assistant config dir as `<config>/www/wired-cards.js` and put in the following contents:
|
||||
|
||||
```js
|
||||
import 'https://unpkg.com/wired-card@0.6.5/wired-card.js?module';
|
||||
import 'https://unpkg.com/wired-toggle@0.6.5/wired-toggle.js?module';
|
||||
import {
|
||||
LitElement, html
|
||||
} from 'https://unpkg.com/@polymer/lit-element@^0.5.2/lit-element.js?module';
|
||||
|
||||
function loadCSS(url) {
|
||||
const link = document.createElement('link');
|
||||
link.type = 'text/css';
|
||||
link.rel = 'stylesheet';
|
||||
link.href = url;
|
||||
document.head.appendChild(link);
|
||||
}
|
||||
|
||||
loadCSS('https://fonts.googleapis.com/css?family=Gloria+Hallelujah');
|
||||
|
||||
class WiredToggleCard extends LitElement {
|
||||
static get properties() {
|
||||
return {
|
||||
hass: Object,
|
||||
config: Object,
|
||||
}
|
||||
}
|
||||
|
||||
_render({ hass, config }) {
|
||||
return html`
|
||||
<style>
|
||||
:host {
|
||||
font-family: 'Gloria Hallelujah', cursive;
|
||||
}
|
||||
wired-card {
|
||||
background-color: white;
|
||||
padding: 16px;
|
||||
display: block;
|
||||
font-size: 18px;
|
||||
}
|
||||
.state {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
padding: 8px;
|
||||
align-items: center;
|
||||
}
|
||||
wired-toggle {
|
||||
margin-left: 8px;
|
||||
}
|
||||
</style>
|
||||
<wired-card elevation="2">
|
||||
${config.entities.map(ent => hass.states[ent]).map((state) =>
|
||||
html`
|
||||
<div class='state'>
|
||||
${state.attributes.friendly_name}
|
||||
<wired-toggle
|
||||
checked="${state.state === 'on'}"
|
||||
on-change="${ev => this._toggle(state)}"
|
||||
></wired-toggle>
|
||||
</div>
|
||||
`
|
||||
)}
|
||||
</wired-card>
|
||||
`;
|
||||
}
|
||||
|
||||
setConfig(config) {
|
||||
if (!config.entities) {
|
||||
throw new Error('You need to define entities');
|
||||
}
|
||||
this.config = config;
|
||||
}
|
||||
|
||||
// The height of your card. Home Assistant uses this to automatically
|
||||
// distribute all cards over the available columns.
|
||||
getCardSize() {
|
||||
return this.config.entities.length + 1;
|
||||
}
|
||||
|
||||
_toggle(state) {
|
||||
this.hass.callService('homeassistant', 'toggle', {
|
||||
entity_id: state.entity_id
|
||||
});
|
||||
}
|
||||
}
|
||||
customElements.define('wired-toggle-card', WiredToggleCard);
|
||||
```
|
||||
|
||||
And for your configuration:
|
||||
|
||||
```yaml
|
||||
# Example ui-lovelace.yaml
|
||||
resources:
|
||||
- url: /local/wired-cards.js
|
||||
type: module
|
||||
views:
|
||||
- name: Example
|
||||
cards:
|
||||
- type: "custom:wired-toggle-card"
|
||||
entities:
|
||||
- input_boolean.switch_ac_kitchen
|
||||
- input_boolean.switch_ac_livingroom
|
||||
- input_boolean.switch_tv
|
||||
```
|
||||
102
website/versioned_docs/version-0.73.0/lovelace_index.md
Normal file
102
website/versioned_docs/version-0.73.0/lovelace_index.md
Normal file
@ -0,0 +1,102 @@
|
||||
---
|
||||
title: Lovelace UI
|
||||
sidebar_label: Introduction
|
||||
id: version-0.73.0-lovelace_index
|
||||
original_id: lovelace_index
|
||||
---
|
||||
|
||||
> This is an experimental feature. Configuration might change in future versions.
|
||||
|
||||
Starting with Home Assistant 0.72, we're experimenting with a new way of defining your interface. We're calling it the Lovelace UI.
|
||||
|
||||
The Lovelace UI is:
|
||||
|
||||
- **Extremely fast**. We create the user interface when the UI configuration changes. When a state changes, we just make the UI represent the current state.
|
||||
- **Extremely customizable**. We have a new file for just configuration. In the past, we declined UI specific options because they did not fit in the state machine. They will fit in a configuration file for a user interface.
|
||||
- **Extremely extensible**. It's based on the web standard [custom elements](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements). Don't like the built-in cards? Make your own! Custom cards are treated the same as built-in cards and are configured the same way. [Check the docs.](lovelace_custom_card.md)
|
||||
- **Making the backend faster**. With Lovelace, the backend will no longer need to maintain entities like groups for the sole purpose of showing them on the frontend.
|
||||
|
||||
Documentation is still in flux. Latest card descriptions can currently be found [here](https://github.com/ciotlosm/docs-lovelace).
|
||||
|
||||
## How it works
|
||||
|
||||
The old user interface relied solely on the state machine. This caused trouble as it meant that the state machine was now not only the source for device states, but also for user interface configuration. With Lovelace, we're taking a completely different approach. All user interface configuration will live in a seperate file, controlled by the user.
|
||||
|
||||
|
||||
|
||||
<!-- source: https://docs.google.com/drawings/d/1O1o7-wRlnsU1lLgfdtn3s46P5StJjSL5to5RU9SV8zs/edit?usp=sharing -->
|
||||
|
||||
## Trying it out
|
||||
|
||||
Create a new file `<config>/ui-lovelace.yaml` and add the following content:
|
||||
|
||||
```yaml
|
||||
title: My Awesome Home
|
||||
views:
|
||||
# View tab title.
|
||||
- title: Example
|
||||
# Optional unique id for direct access /lovelace/${id}
|
||||
id: example
|
||||
# Each view can have a different theme applied. Theme should be defined in the frontend.
|
||||
theme: dark-mode
|
||||
# The cards to show on this view.
|
||||
cards:
|
||||
# The entities card will take a list of entities and show their state.
|
||||
- type: entities
|
||||
# Title of the entities card
|
||||
title: Example
|
||||
# The entities here will be shown in the same order as specified.
|
||||
entities:
|
||||
- input_boolean.switch_ac_kitchen
|
||||
- input_boolean.switch_ac_livingroom
|
||||
- input_boolean.switch_tv
|
||||
|
||||
# The filter card will filter available entities for certain criteria
|
||||
# and render it as type 'entities'.
|
||||
- type: entity-filter
|
||||
# Filter criteria. They are all optional.
|
||||
filter:
|
||||
- domain: input_boolean
|
||||
state: 'on'
|
||||
# This config will be passed to the card rendering the filter results
|
||||
card_config:
|
||||
title: Input booleans that are on
|
||||
|
||||
# Specify a tab icon if you want the view tab to be an icon.
|
||||
- icon: mdi:home-assistant
|
||||
# Title of the view. Will be used as the tooltip for tab icon
|
||||
title: Second view
|
||||
cards:
|
||||
- type: entities
|
||||
title: Lots of Kitchen AC
|
||||
entities:
|
||||
# It is totally possible to render duplicates.
|
||||
- input_boolean.switch_ac_kitchen
|
||||
- input_boolean.switch_ac_kitchen
|
||||
- input_boolean.switch_ac_kitchen
|
||||
- input_boolean.switch_ac_kitchen
|
||||
- input_boolean.switch_ac_kitchen
|
||||
- input_boolean.switch_ac_kitchen
|
||||
```
|
||||
|
||||
Add to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
input_boolean:
|
||||
switch_ac_kitchen:
|
||||
name: AC kitchen
|
||||
switch_ac_livingroom:
|
||||
name: AC living room
|
||||
switch_tv:
|
||||
name: TV
|
||||
```
|
||||
|
||||
Now restart Home Assistant, navigate to `<YOUR HASS URL>/lovelace`. When you make changes to `ui-lovelace.yaml`, you don't have to restart Home Assistant or refresh the page. Just hit the refresh button at the top of the UI.
|
||||
|
||||
## Current limitations
|
||||
|
||||
This is the very very early version aimed at gathering feedback. Discussion and suggestions are welcome in the [ui-schema repository](https://github.com/home-assistant/ui-schema).
|
||||
|
||||
## Change log
|
||||
|
||||
[See here](https://github.com/ciotlosm/docs-lovelace/blob/master/changelog.md)
|
||||
154
website/versioned_sidebars/version-0.73.0-sidebars.json
Normal file
154
website/versioned_sidebars/version-0.73.0-sidebars.json
Normal file
@ -0,0 +1,154 @@
|
||||
{
|
||||
"version-0.73.0-Architecture": {
|
||||
"Architecture": [
|
||||
"version-0.73.0-architecture_index",
|
||||
"version-0.73.0-architecture_components",
|
||||
"version-0.73.0-architecture_entities",
|
||||
"version-0.73.0-architecture_hassio"
|
||||
],
|
||||
"Entities": [
|
||||
"version-0.73.0-entity_index",
|
||||
"version-0.73.0-entity_alarm_control_panel",
|
||||
"version-0.73.0-entity_binary_sensor",
|
||||
"version-0.73.0-entity_climate",
|
||||
"version-0.73.0-entity_cover",
|
||||
"version-0.73.0-entity_fan",
|
||||
"version-0.73.0-entity_light",
|
||||
"version-0.73.0-entity_lock",
|
||||
"version-0.73.0-entity_media_player",
|
||||
"version-0.73.0-entity_remote",
|
||||
"version-0.73.0-entity_sensor",
|
||||
"version-0.73.0-entity_switch",
|
||||
"version-0.73.0-entity_vacuum",
|
||||
"version-0.73.0-entity_weather"
|
||||
],
|
||||
"Authentication": [
|
||||
"version-0.73.0-auth_index",
|
||||
"version-0.73.0-auth_api",
|
||||
"version-0.73.0-auth_auth_provider"
|
||||
],
|
||||
"Configuration.yaml": [
|
||||
"version-0.73.0-configuration_yaml_index"
|
||||
],
|
||||
"Config Entries": [
|
||||
"version-0.73.0-config_entries_index",
|
||||
"version-0.73.0-config_entries_config_flow_handler"
|
||||
],
|
||||
"Data Entry Flow": [
|
||||
"version-0.73.0-data_entry_flow_index"
|
||||
],
|
||||
"Entity Registry": [
|
||||
"version-0.73.0-entity_registry_index"
|
||||
]
|
||||
},
|
||||
"version-0.73.0-Extending Frontend": {
|
||||
"Frontend": [
|
||||
"version-0.73.0-frontend_index",
|
||||
"version-0.73.0-frontend_architecture",
|
||||
"version-0.73.0-frontend_development"
|
||||
],
|
||||
"Extending the frontend": [
|
||||
"version-0.73.0-frontend_add_card",
|
||||
"version-0.73.0-frontend_add_more_info",
|
||||
"version-0.73.0-frontend_add_websocket_api"
|
||||
],
|
||||
"Custom UI": [
|
||||
"version-0.73.0-frontend_creating_custom_ui",
|
||||
"version-0.73.0-frontend_creating_custom_panels"
|
||||
],
|
||||
"Lovelace UI": [
|
||||
"version-0.73.0-lovelace_index",
|
||||
"version-0.73.0-lovelace_custom_card"
|
||||
]
|
||||
},
|
||||
"version-0.73.0-Extending HASS": {
|
||||
"Developing a feature": [
|
||||
"version-0.73.0-development_index",
|
||||
"version-0.73.0-development_environment",
|
||||
"version-0.73.0-development_submitting",
|
||||
"version-0.73.0-development_checklist",
|
||||
"version-0.73.0-development_guidelines",
|
||||
"version-0.73.0-development_testing",
|
||||
"version-0.73.0-development_catching_up",
|
||||
"version-0.73.0-development_validation",
|
||||
"version-0.73.0-development_typing"
|
||||
],
|
||||
"Development 101": [
|
||||
"version-0.73.0-dev_101_index",
|
||||
"version-0.73.0-dev_101_hass",
|
||||
"version-0.73.0-dev_101_events",
|
||||
"version-0.73.0-dev_101_states",
|
||||
"version-0.73.0-dev_101_services",
|
||||
"version-0.73.0-dev_101_config"
|
||||
],
|
||||
"Creating Platforms": [
|
||||
"version-0.73.0-creating_platform_index",
|
||||
"version-0.73.0-creating_platform_code_review",
|
||||
"version-0.73.0-creating_platform_example_light",
|
||||
"version-0.73.0-creating_platform_example_sensor"
|
||||
],
|
||||
"Creating Components": [
|
||||
"version-0.73.0-creating_component_index",
|
||||
"version-0.73.0-creating_component_code_review",
|
||||
"version-0.73.0-creating_component_deps_and_reqs",
|
||||
"version-0.73.0-creating_component_events",
|
||||
"version-0.73.0-creating_component_states",
|
||||
"version-0.73.0-creating_component_discovery",
|
||||
"version-0.73.0-creating_component_loading",
|
||||
"version-0.73.0-creating_component_generic_discovery"
|
||||
]
|
||||
},
|
||||
"version-0.73.0-Misc": {
|
||||
"Introduction": [
|
||||
"version-0.73.0-misc"
|
||||
],
|
||||
"External API": [
|
||||
"version-0.73.0-external_api_rest",
|
||||
"version-0.73.0-external_api_rest_python",
|
||||
"version-0.73.0-external_api_websocket",
|
||||
"version-0.73.0-external_api_server_sent_events"
|
||||
],
|
||||
"Internationalization": [
|
||||
"version-0.73.0-internationalization_index",
|
||||
"version-0.73.0-internationalization_backend_localization",
|
||||
"version-0.73.0-internationalization_custom_component_localization",
|
||||
"version-0.73.0-internationalization_translation"
|
||||
],
|
||||
"Documentation": [
|
||||
"version-0.73.0-documentation_index",
|
||||
"version-0.73.0-documentation_standards",
|
||||
"version-0.73.0-documentation_create_page"
|
||||
],
|
||||
"Intents": [
|
||||
"version-0.73.0-intent_index",
|
||||
"version-0.73.0-intent_firing",
|
||||
"version-0.73.0-intent_handling",
|
||||
"version-0.73.0-intent_conversation",
|
||||
"version-0.73.0-intent_builtin"
|
||||
],
|
||||
"asyncio": [
|
||||
"version-0.73.0-asyncio_index",
|
||||
"version-0.73.0-asyncio_101",
|
||||
"version-0.73.0-asyncio_categorizing_functions",
|
||||
"version-0.73.0-asyncio_working_with_async"
|
||||
],
|
||||
"Hass.io": [
|
||||
"version-0.73.0-hassio_debugging",
|
||||
"version-0.73.0-hassio_hass"
|
||||
],
|
||||
"Hass.io Add-Ons": [
|
||||
"version-0.73.0-hassio_addon_index",
|
||||
"version-0.73.0-hassio_addon_tutorial",
|
||||
"version-0.73.0-hassio_addon_config",
|
||||
"version-0.73.0-hassio_addon_communication",
|
||||
"version-0.73.0-hassio_addon_testing",
|
||||
"version-0.73.0-hassio_addon_publishing",
|
||||
"version-0.73.0-hassio_addon_presentation",
|
||||
"version-0.73.0-hassio_addon_repository"
|
||||
],
|
||||
"Maintainer docs": [
|
||||
"version-0.73.0-maintenance",
|
||||
"version-0.73.0-releasing"
|
||||
]
|
||||
}
|
||||
}
|
||||
@ -1,3 +1,4 @@
|
||||
[
|
||||
"0.73.0",
|
||||
"0.72"
|
||||
]
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user