mirror of
https://github.com/home-assistant/developers.home-assistant.git
synced 2025-07-15 21:36:31 +00:00
parent
6549927701
commit
6041e8382f
@ -130,7 +130,7 @@ An HTTP status code of 400 will be returned if an invalid request has been issue
|
||||
|
||||
> client_id is not need for revoke refresh token
|
||||
|
||||
The token endpoint is also capable of revoking a refresh token. Revoking a refresh token will immedeatly revoke the refresh token and all access tokens that it has ever granted. To revoke a refresh token, make the following request:
|
||||
The token endpoint is also capable of revoking a refresh token. Revoking a refresh token will immediately revoke the refresh token and all access tokens that it has ever granted. To revoke a refresh token, make the following request:
|
||||
|
||||
```
|
||||
token=IJKLMNOPQRST&
|
||||
@ -141,7 +141,7 @@ The request will always respond with an empty body and HTTP status 200, regardle
|
||||
|
||||
## Long-lived access token
|
||||
|
||||
A long-lived access token is usally used for 3rd party API calls and webhook-ish integrations. To generate a long-lived access token, an active websocket connection has to be established.
|
||||
A long-lived access token is usually used for 3rd party API calls and webhook-ish integrations. To generate a long-lived access token, an active websocket connection has to be established.
|
||||
|
||||
Send websocket command `auth/long_lived_access_token` will create a long-lived access token for current user. Access token will not be saved in Home Assistant. User need to record the token in secure place.
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: "Multi-factor Authentication Modules"
|
||||
---
|
||||
|
||||
Multi-factor Authentication Modules are used in conjunction with [Authentication Provider](auth_auth_provider.html) to provide a fully configurable authentication framework. Each MFA module may provide one multi-factor authentication function. User can enable mulitple mfa module, but can only select one module in login process.
|
||||
Multi-factor Authentication Modules are used in conjunction with [Authentication Provider](auth_auth_provider.html) to provide a fully configurable authentication framework. Each MFA module may provide one multi-factor authentication function. User can enable multiple mfa modules, but can only select one module in login process.
|
||||
|
||||
## Defining an mfa auth module
|
||||
|
||||
@ -26,7 +26,7 @@ Multi-factor Auth modules shall extend the following methods of `MultiFactorAuth
|
||||
|
||||
## Setup Flow
|
||||
|
||||
Before user can use a multi-factor auth module, it has to be enabled or set up. All availiable modules will be listed in user profile page, user can enable the module he/she wants to use. A setup data entry flow will guide user finish the neccessary steps.
|
||||
Before user can use a multi-factor auth module, it has to be enabled or set up. All availaable modules will be listed in user profile page, user can enable the module he/she wants to use. A setup data entry flow will guide user finish the necessary steps.
|
||||
|
||||
Each MFA module need to implement a setup flow handler extends from `mfa_modules.SetupFlow` (if only one simple setup step need, `SetupFlow` can be used as well). For example for Google Authenticator (TOTP, Time-based One Time Password) module, the flow will need to be:
|
||||
- Generate a secret and store it on instance of setup flow
|
||||
|
@ -4,7 +4,7 @@ title: Config Flow Handlers
|
||||
|
||||
Config Entries uses the [Data Flow Entry framework](data_entry_flow_index.md) to allow users to create entries. Components that want to support config entries will need to define a Config Flow Handler. This handler will manage the creation of entries from user input, discovery or other sources (like hassio).
|
||||
|
||||
Config Flow Handlers controll the data that is stored in a config entry. This means that there is no need to validate that the config is correct when Home Assistant starts up. It will also prevent breaking changes, because we will be able to migrate configuration entries to new formats if the version changes.
|
||||
Config Flow Handlers control the data that is stored in a config entry. This means that there is no need to validate that the config is correct when Home Assistant starts up. It will also prevent breaking changes, because we will be able to migrate configuration entries to new formats if the version changes.
|
||||
|
||||
When instantiating the handler, Home Assistant will make sure to load all dependencies and install the requirements of the component.
|
||||
|
||||
|
@ -64,7 +64,7 @@ The entity base class has a few properties that are common among all entities in
|
||||
| entity_picture | URL | `None` | Url of a picture to show for the entity.
|
||||
| name | string | `None` | Name of the entity
|
||||
| should_poll | boolean | `True` | Should Home Assistant check with the entity for an updated state. If set to `False`, entity will need to notify Home Assistant of new updates by calling one of the [schedule update methods](#methods).
|
||||
| unique_id | string | `None` | A unique identifier for this entity. Needs to be unique within a platform (ie `light.hue`). Should not be configurable by the user or be changable. [Learn more.](entity_registry_index.md#unique-id-requirements)
|
||||
| unique_id | string | `None` | A unique identifier for this entity. Needs to be unique within a platform (ie `light.hue`). Should not be configurable by the user or be changeable. [Learn more.](entity_registry_index.md#unique-id-requirements)
|
||||
|
||||
## Advanced properties
|
||||
|
||||
|
@ -14,7 +14,7 @@ sidebar_label: Vacuum
|
||||
| battery_level | int | `none` | Current battery level.
|
||||
| battery_icon | string | function | Battery icon to show in UI.
|
||||
| cleaning_mode | string | `none` | The current cleaning mode.
|
||||
| cleaning_mode_list | list | `NotImplementedError()`| List of avaliable fan speeds and cleaning modes.
|
||||
| cleaning_mode_list | list | `NotImplementedError()`| List of available fan speeds and cleaning modes.
|
||||
| error | string | **Required** with `STATE_ERROR` | An error message if the vacuum is in `STATE_ERROR`.
|
||||
|
||||
|
||||
@ -52,4 +52,4 @@ Locate the vacuum cleaner.
|
||||
Set the cleaning mode.
|
||||
|
||||
### `send_command` or `async_send_command`
|
||||
Send a command to a vacuum cleaner.
|
||||
Send a command to a vacuum cleaner.
|
||||
|
@ -10,7 +10,7 @@ To register a command, you need to have a message type, a message schema and a m
|
||||
|
||||
### Message Types
|
||||
|
||||
Message types are made up the domain and the message type, seperated by a forward slash. In the below example, we're defining `media_player/thumbnail`.
|
||||
Message types are made up the domain and the message type, separated by a forward slash. In the below example, we're defining `media_player/thumbnail`.
|
||||
|
||||
```python
|
||||
# The type of the message
|
||||
|
@ -47,7 +47,7 @@ We use a unidirectional data flow (like Flux, Redux). When you make a change in
|
||||
|
||||
## Routing
|
||||
|
||||
The frontend uses decentralized routing. Each component only knows enough about the routing to know how to handle the part it's repsonsible for. Further routing is passed down the component tree.
|
||||
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.
|
||||
|
||||
|
@ -2,11 +2,11 @@
|
||||
title: "Add-on security"
|
||||
---
|
||||
|
||||
Hass.io rates every add-on based on the wanted rights. A 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.
|
||||
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.
|
||||
|
||||
## Protection
|
||||
|
||||
Default, all add-on run in a protection enabled modu. 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, a add-on with disabled protection can destroy your system!
|
||||
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
|
||||
|
||||
|
@ -28,7 +28,7 @@ To get these info, do the following steps:
|
||||
|
||||
## Having Home Assistant connect to remote Hass.io
|
||||
|
||||
The connection with the supervisor is hidden inside the host and is only accessible from applications running on the host. So to make it accessible for our Home Assistant instance, we will need to route the connection to our computer running Home Assitant. We're going to do this by forwarding ports via an SSH connection.
|
||||
The connection with the supervisor is hidden inside the host and is only accessible from applications running on the host. So to make it accessible for our Home Assistant instance, we will need to route the connection to our computer running Home Assistant. We're going to do this by forwarding ports via an SSH connection.
|
||||
|
||||
We are going to SSH from our machine running Home Assistant into the remote Hass.io host. We're going to configure our SSH connection to forward all local connections to localhost port 10081 to be sent from the Hass.io host to the IP address that we got as `HASSIO` value in the last step.
|
||||
|
||||
@ -56,7 +56,7 @@ Voila. Your local Home Assistant installation will now connect to a remote Hass.
|
||||
|
||||
> This requires Home Assistant 0.71 or later.
|
||||
|
||||
We need a couple more steps to do frontend development. First, make sure you have a Home Assitant frontend development set up ([instructions](frontend_index.md)).
|
||||
We need a couple more steps to do frontend development. First, make sure you have a Home Assistant frontend development set up ([instructions](frontend_index.md)).
|
||||
|
||||
Update the Hass.io component configuration in your `configuration.yaml` to point at the frontend repository:
|
||||
|
||||
|
@ -6,7 +6,7 @@ original_id: config_entries_config_flow_handler
|
||||
|
||||
Config Entries uses the [Data Flow Entry framework](data_entry_flow_index.md) to allow users to create entries. Components that want to support config entries will need to define a Config Flow Handler. This handler will manage the creation of entries from user input, discovery or other sources (like hassio).
|
||||
|
||||
Config Flow Handlers controll the data that is stored in a config entry. This means that there is no need to validate that the config is correct when Home Assistant starts up. It will also prevent breaking changes, because we will be able to migrate configuration entries to new formats if the version changes.
|
||||
Config Flow Handlers control the data that is stored in a config entry. This means that there is no need to validate that the config is correct when Home Assistant starts up. It will also prevent breaking changes, because we will be able to migrate configuration entries to new formats if the version changes.
|
||||
|
||||
When instantiating the handler, Home Assistant will make sure to load all dependencies and install the requirements of the component.
|
||||
|
||||
|
@ -66,7 +66,7 @@ The entity base class has a few properties that are common among all entities in
|
||||
| entity_picture | URL | `None` | Url of a picture to show for the entity.
|
||||
| name | string | `None` | Name of the entity
|
||||
| should_poll | boolean | `True` | Should Home Assistant check with the entity for an updated state. If set to `False`, entity will need to notify Home Assistant of new updates by calling one of the [schedule update methods](#methods).
|
||||
| unique_id | string | `None` | A unique identifier for this entity. Needs to be unique within a platform (ie `light.hue`). Should not be configurable by the user or be changable. [Learn more.](entity_registry_index.md#unique-id-requirements)
|
||||
| unique_id | string | `None` | A unique identifier for this entity. Needs to be unique within a platform (ie `light.hue`). Should not be configurable by the user or be changeable. [Learn more.](entity_registry_index.md#unique-id-requirements)
|
||||
|
||||
## Advanced properties
|
||||
|
||||
|
@ -12,7 +12,7 @@ To register a command, you need to have a message type, a message schema and a m
|
||||
|
||||
### Message Types
|
||||
|
||||
Message types are made up the domain and the message type, seperated by a forward slash. In the below example, we're defining `media_player/thumbnail`.
|
||||
Message types are made up the domain and the message type, separated by a forward slash. In the below example, we're defining `media_player/thumbnail`.
|
||||
|
||||
```python
|
||||
# The type of the message
|
||||
|
@ -49,7 +49,7 @@ We use a unidirectional data flow (like Flux, Redux). When you make a change in
|
||||
|
||||
## Routing
|
||||
|
||||
The frontend uses decentralized routing. Each component only knows enough about the routing to know how to handle the part it's repsonsible for. Further routing is passed down the component tree.
|
||||
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.
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Hass.io <> Home Assitant integration development
|
||||
title: Hass.io <> Home Assistant integration development
|
||||
sidebar_label: HASS Integration development
|
||||
id: version-0.72-hassio_hass
|
||||
original_id: hassio_hass
|
||||
@ -30,7 +30,7 @@ To get these info, do the following steps:
|
||||
|
||||
## Having Home Assistant connect to remote Hass.io
|
||||
|
||||
The connection with the supervisor is hidden inside the host and is only accessible from applications running on the host. So to make it accessible for our Home Assistant instance, we will need to route the connection to our computer running Home Assitant. We're going to do this by forwarding ports via an SSH connection.
|
||||
The connection with the supervisor is hidden inside the host and is only accessible from applications running on the host. So to make it accessible for our Home Assistant instance, we will need to route the connection to our computer running Home Assistant. We're going to do this by forwarding ports via an SSH connection.
|
||||
|
||||
We are going to SSH from our machine running Home Assistant into the remote Hass.io host. We're going to configure our SSH connection to forward all local connections to localhost port 10081 to be sent from the Hass.io host to the IP address that we got as `HASSIO` value in the last step.
|
||||
|
||||
@ -58,7 +58,7 @@ Voila. Your local Home Assistant installation will now connect to a remote Hass.
|
||||
|
||||
> This requires Home Assistant 0.71 or later.
|
||||
|
||||
We need a couple more steps to do frontend development. First, make sure you have a Home Assitant frontend development set up ([instructions](frontend_index.md)).
|
||||
We need a couple more steps to do frontend development. First, make sure you have a Home Assistant frontend development set up ([instructions](frontend_index.md)).
|
||||
|
||||
Update the Hass.io component configuration in your `configuration.yaml` to point at the frontend repository:
|
||||
|
||||
|
@ -18,7 +18,7 @@ The Lovelace UI is:
|
||||
|
||||
## 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.
|
||||
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 separate file, controlled by the user.
|
||||
|
||||

|
||||
|
||||
|
@ -16,7 +16,7 @@ original_id: entity_vacuum
|
||||
| battery_level | int | `none` | Current battery level.
|
||||
| battery_icon | string | function | Battery icon to show in UI.
|
||||
| cleaning_mode | string | `none` | The current cleaning mode.
|
||||
| cleaning_mode_list | list | `NotImplementedError()`| List of avaliable fan speeds and cleaning modes.
|
||||
| cleaning_mode_list | list | `NotImplementedError()`| List of available fan speeds and cleaning modes.
|
||||
| error | string | **Required** with `STATE_ERROR` | An error message if the vacuum is in `STATE_ERROR`.
|
||||
|
||||
|
||||
@ -54,4 +54,4 @@ Locate the vacuum cleaner.
|
||||
Set the cleaning mode.
|
||||
|
||||
### `send_command` or `async_send_command`
|
||||
Send a command to a vacuum cleaner.
|
||||
Send a command to a vacuum cleaner.
|
||||
|
@ -123,7 +123,7 @@ this.hass.callWS({
|
||||
|
||||
### `hass.callApi(method, path, data)`
|
||||
|
||||
Call an API on the Home Assistant server. For example, if you want to fetch all Hass.io snapshots by issueing a GET request to `/api/hassio/snapshots`:
|
||||
Call an API on the Home Assistant server. For example, if you want to fetch all Hass.io snapshots by issuing a GET request to `/api/hassio/snapshots`:
|
||||
|
||||
```js
|
||||
hass.callApi('get', 'hassio/snapshots')
|
||||
|
@ -130,7 +130,7 @@ An HTTP status code of 400 will be returned if an invalid request has been issue
|
||||
|
||||
### Revoking a refresh token
|
||||
|
||||
The token endpoint is also capable of revoking a refresh token. Revoking a refresh token will immedeatly revoke the refresh token and all access tokens that it has ever granted. To revoke a refresh token, make the following request:
|
||||
The token endpoint is also capable of revoking a refresh token. Revoking a refresh token will immediately revoke the refresh token and all access tokens that it has ever granted. To revoke a refresh token, make the following request:
|
||||
|
||||
```
|
||||
token=IJKLMNOPQRST&
|
||||
|
@ -4,7 +4,7 @@ id: version-0.77.0-auth_auth_module
|
||||
original_id: auth_auth_module
|
||||
---
|
||||
|
||||
Multi-factor Authentication Modules are used in conjunction with [Authentication Provider](auth_auth_provider.html) to provide a fully configurable authentication framework. Each MFA module may provide one multi-factor authentication function. User can enable mulitple mfa module, but can only select one module in login process.
|
||||
Multi-factor Authentication Modules are used in conjunction with [Authentication Provider](auth_auth_provider.html) to provide a fully configurable authentication framework. Each MFA module may provide one multi-factor authentication function. User can enable multiple mfa modules, but can only select one module in login process.
|
||||
|
||||
## Defining an mfa auth module
|
||||
|
||||
@ -27,7 +27,7 @@ Multi-factor Auth modules shall extend the following methods of `MultiFactorAuth
|
||||
|
||||
## Setup Flow
|
||||
|
||||
Before user can use a multi-factor auth module, it has to be enabled or set up. All availiable modules will be listed in user profile page, user can enable the module he/she wants to use. A setup data entry flow will guide user finish the neccessary steps.
|
||||
Before user can use a multi-factor auth module, it has to be enabled or set up. All availaable modules will be listed in user profile page, user can enable the module he/she wants to use. A setup data entry flow will guide user finish the necessary steps.
|
||||
|
||||
Each MFA module need to implement a setup flow handler extends from `mfa_modules.SetupFlow` (if only one simple setup step need, `SetupFlow` can be used as well). For example for Google Authenticator (TOTP, Time-based One Time Password) module, the flow will need to be:
|
||||
- Generate a secret and store it on instance of setup flow
|
||||
|
@ -6,7 +6,7 @@ original_id: config_entries_config_flow_handler
|
||||
|
||||
Config Entries uses the [Data Flow Entry framework](data_entry_flow_index.md) to allow users to create entries. Components that want to support config entries will need to define a Config Flow Handler. This handler will manage the creation of entries from user input, discovery or other sources (like hassio).
|
||||
|
||||
Config Flow Handlers controll the data that is stored in a config entry. This means that there is no need to validate that the config is correct when Home Assistant starts up. It will also prevent breaking changes, because we will be able to migrate configuration entries to new formats if the version changes.
|
||||
Config Flow Handlers control the data that is stored in a config entry. This means that there is no need to validate that the config is correct when Home Assistant starts up. It will also prevent breaking changes, because we will be able to migrate configuration entries to new formats if the version changes.
|
||||
|
||||
When instantiating the handler, Home Assistant will make sure to load all dependencies and install the requirements of the component.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user