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-23 01:06:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix bunch of links (#545)

Browse Source
This commit is contained in:
Franck Nijhof 2020-05-19 09:56:08 +02:00 committed by GitHub
parent 0145bbbfa7
commit 698139469a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
14 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
blog/2019-05-22-internet-of-things-and-the-modern-web.md
View File

@ -75,7 +75,7 @@ In case you are wondering how an open source project got such an extensive list
* **Easy state management.** To be able to share our state with any component, internal or external, we decided to roll our own state management. It’s a simple object that contains the current state of the house and it is passed down our component tree. Whenever the state changes, we make a copy and update the changed parts and then pass it down again to all the components. Components will then re-render and show the latest state. All state updates are managed by Home Assistant JS Websocket, and are all generated on the server. They are pushed to the frontend using web sockets, allowing all open UIs to stay in sync because they all receive the latest changes as soon as possible.
[Home Assistant JS Websocket](https://github.com/home-assistant/home-assistant-js-websocket/) is our 4KB WebSocket + Auth library that can be added to any site to integrate it with Home Assistant instances. For a standalone Home Assistant UI built using 50 lines of JavaScript, see [this glitch](https://hass-auth-demo.glitch.me/).
* **Easy extension development using modules and unpkg.** Developers are able to develop their own cards without running any tooling. All you need is to create a JavaScript file, reference it in the resource section of your config and you can start using it ([example in the docs](https://developers.home-assistant.io/docs/en/lovelace_custom_card.html#advanced-example)). We default to importing resources as type=module, so that developers can import their dependencies straight from http://unpkg.com during development.
* **Easy extension development using modules and unpkg.** Developers are able to develop their own cards without running any tooling. All you need is to create a JavaScript file, reference it in the resource section of your config and you can start using it ([example in the docs](/docs/frontend/custom-ui/lovelace-custom-card#advanced-example)). We default to importing resources as type=module, so that developers can import their dependencies straight from http://unpkg.com during development.
* **Make it easy to find bloat in bundles.** If we can make it easier to find things that we ship unnecessarily, developers are more likely to find it and spend time on removing the bloat. For that reason, we include scripts in our repository that allows anyone to quickly run a bundle analysis using the [webpack-bundle-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer) and see what packages add to our bundle size. These analysis look [like this](https://s3.amazonaws.com/home-assistant-demos/bundle-analysis/report-20190522.html).
* **Code split translations.** We use [lokalise.co](https://lokalise.co/) to manage our translations. All translation strings in our code base are automatically uploaded to lokalise.co where volunteers are translating the available strings. We have build tooling to split our translations based on the different panels in our UI. This allows us to only load the translations on the fly that we need.
* **Decentralized routing.** The top level of the application only knows how to route the first part of the url. It knows which code to load and which web component to instantiate. It will pass the rest of the url to the panel and further routing can be done from there. This will avoid the initial bundle to keep growing as more parts are splitter out. We have also created a simple to use router for web components with support for code splitting and loading screens, making it easy for our developers to do the right thing.

6
docs/add-ons/communication.md
View File

@ -15,7 +15,7 @@ Use `supervisor` for communication with the internal API.
## Home Assistant Core
An add-on can talk to the [Home Assistant Core API][core-api] using the internal proxy. This makes it very easy to communicate with the API without knowing the password, port or any other information about the Home Assistant instance. Using this URL: `http://supervisor/core/api` ensures that internal communication is redirected to the right place. The next step is to add `homeassistant_api: true` to the `config.json` file and read the environment variable `SUPERVISOR_TOKEN`. Use this as the Home Assistant Core [bearer token](https://developers.home-assistant.io/docs/en/auth_api.html#making-authenticated-requests) when making requests.
An add-on can talk to the [Home Assistant Core API][core-api] using the internal proxy. This makes it very easy to communicate with the API without knowing the password, port or any other information about the Home Assistant instance. Using this URL: `http://supervisor/core/api` ensures that internal communication is redirected to the right place. The next step is to add `homeassistant_api: true` to the `config.json` file and read the environment variable `SUPERVISOR_TOKEN`. Use this as the Home Assistant Core [bearer token](/auth_api.md#making-authenticated-requests) when making requests.
For example `curl -X GET -H "Authorization: Bearer ${SUPERVISOR_TOKEN}" -H "Content-Type: application/json" http://supervisor/core/api/discovery_info`
@ -60,8 +60,8 @@ MQTT_USER=$(bashio::services mqtt "username")
MQTT_PASSWORD=$(bashio::services mqtt "password")
```
[core-api]: https://developers.home-assistant.io/docs/api/rest/
[core-websocket]: https://developers.home-assistant.io/docs/api/websocket/
[core-api]: /api/rest.md
[core-websocket]: /api/websocket.md
[supervisor-api]: https://github.com/home-assistant/supervisor/blob/master/API.md
[supervisor-addon-api]: https://github.com/home-assistant/supervisor/blob/dev/API.md#restful-for-api-addons
[supervisor-services-api]:https://github.com/home-assistant/supervisor/blob/dev/API.md#services-1

8
docs/api/native-app-integration/setup.md
View File

@ -28,11 +28,11 @@ First, you must ensure that the `mobile_app` component is loaded. There are two
- You can publish a Zeroconf/Bonjour record `_hass-mobile-app._tcp.local.` to trigger the automatic load of the `mobile_app` component. You should wait at least 60 seconds after publishing the record before continuing.
- You can ask the user to add `mobile_app` to their configuration.yaml and restart Home Assistant. If the user already has `default_config` in their configuration, then `mobile_app` will have been already loaded.
You can confirm the `mobile_app` component has been loaded by checking the `components` array of the [`/api/config` REST API call](/docs/api/rest/#get-apiconfig). If you continue to device registration and receive a 404 status code, then it most likely hasn't been loaded yet.
You can confirm the `mobile_app` component has been loaded by checking the `components` array of the [`/api/config` REST API call](/api/rest.md#get-apiconfig). If you continue to device registration and receive a 404 status code, then it most likely hasn't been loaded yet.
### Registering the device
To register the device, make an authenticated POST request to `/api/mobile_app/registrations`. [More info on making authenticated requests.](auth_api.md#making-authenticated-requests)
To register the device, make an authenticated POST request to `/api/mobile_app/registrations`. [More info on making authenticated requests.](/auth_api.md#making-authenticated-requests)
Example payload to send to the registration endpoint:
@ -65,7 +65,7 @@ Example payload to send to the registration endpoint:
| `model` | V | string | The model of the device running the app. |
| `os_name` | V | string | The name of the OS running the app. |
| `os_version` | V | string | The OS version of the device running the app. |
| `supports_encryption` | V | bool | If the app supports encryption. See also the [encryption section](/docs/api/native-app-integration/sending-data/#implementing-encryption). |
| `supports_encryption` | V | bool | If the app supports encryption. See also the [encryption section](/api/native-app-integration/sending-data.md#implementing-encryption). |
| `app_data` | | Dict | App data can be used if the app has a supporting component that extends `mobile_app` functionality. |
When you get a 200 response, the mobile app is registered with Home Assistant. The response is a JSON document and will contain the URLs on how to interact with the Home Assistant instance. You should permanently store this information.
@ -83,5 +83,5 @@ When you get a 200 response, the mobile app is registered with Home Assistant. T
| --------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cloudhook_url` | string | The cloudhook URL provided by Home Assistant Cloud. Only will be provided if user is actively subscribed to Nabu Casa. |
| `remote_ui_url` | string | The remote UI URL provided by Home Assistant Cloud. Only will be provided if user is actively subscribed to Nabu Casa. |
| `secret` | string | The secret to use for encrypted communication. Will only be included if encryption is supported by both the app and the Home Assistant instance. [More info](/docs/api/native-app-integration/sending-data/#implementing-encryption). |
| `secret` | string | The secret to use for encrypted communication. Will only be included if encryption is supported by both the app and the Home Assistant instance. [More info](/api/native-app-integration/sending-data.md#implementing-encryption). |
| `webhook_id` | string | The webhook ID that can be used to send data back. |

2
docs/auth_api.md
View File

@ -179,7 +179,7 @@ Additionally, a long-lived access token can be created using the UI tool located
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](/docs/api/websocket/#authentication-phase).
For the websocket connection, pass the access token in the [authentication message](/api/websocket.md#authentication-phase).
For HTTP requests, pass the token type and access token as the authorization header:

2
docs/auth_auth_module.md
View File

@ -2,7 +2,7 @@
title: "Multi-factor Authentication Modules"
---
Multi-factor Authentication Modules are used in conjunction with [Authentication Provider](/docs/auth_auth_provider/) 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.
Multi-factor Authentication Modules are used in conjunction with [Authentication Provider](auth_auth_provider.md) 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

2
docs/config_entries_index.md
View File

@ -95,7 +95,7 @@ digraph G {
## Setting up an entry
During startup, Home Assistant first calls the [normal component setup](https://developers.home-assistant.io/docs/en/creating_component_index.html),
During startup, Home Assistant first calls the [normal component setup](/creating_component_index.md),
and then call the method `async_setup_entry(hass, entry)` for each entry. If a new Config Entry is
created at runtime, Home Assistant will also call `async_setup_entry(hass, entry)` ([example](https://github.com/home-assistant/home-assistant/blob/0.68.0/homeassistant/components/hue/__init__.py#L119)).

2
docs/dev_101_states.md
View File

@ -21,7 +21,7 @@ To get started, create the file `<config dir>/custom_components/hello_state.py`
Support for showing text in the frontend.
For more details about this component, please refer to the documentation at
https://developers.home-assistant.io/docs/en/dev_101_states.html
https://developers.home-assistant.io/docs/dev_101_states
"""
import logging

2
docs/development_checklist.md
View File

@ -11,4 +11,4 @@ Before you commit any changes, check your work against these requirements:
- The `.coveragerc` file is updated to exclude your platform if there are no tests available or your new code uses a third-party library for communication with the device, service, or sensor
- The code is formatted using Black, as per these [guidelines](https://developers.home-assistant.io/blog/2019/07/31/black.html). This can be done running the command `black --fast homeassistant`.
- Documentation is developed for [home-assistant.io](https://home-assistant.io/)
- Visit the [website documentation](/docs/documenting.html) for more information about contributing to [home-assistant.io](https://github.com/home-assistant/home-assistant.io).
- Visit the [website documentation](/documenting.md) for more information about contributing to [home-assistant.io](https://github.com/home-assistant/home-assistant.io).

2
docs/documenting/create-page.md
View File

@ -35,7 +35,7 @@ Additional keys for the file header:
- `ha_category`: This entry is used to group the integration on the [Integration overview](https://www.home-assistant.io/integrations/).
- `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_quality_scale`: [Quality scale](https://www.home-assistant.io/docs/quality_scale/) is the representation of the integration's quality.
- `ha_config_flow`: Set to `true` if the integration has a [Data Entry Flow](https://developers.home-assistant.io/docs/en/data_entry_flow_index.html), omit otherwise.
- `ha_config_flow`: Set to `true` if the integration has a [Data Entry Flow](/data_entry_flow_index.md), omit otherwise.
- `ha_codeowners`: GitHub usernames or team names (starting with `@`) of people that are responsible for this integration. This should match with the codeowners as listed in the integration manifest file.
- `ha_domain`: The domain of the integration in Home Assistant Core. This must match the name from the integration manifest file.

2
docs/documenting/standards.md
View File

@ -66,7 +66,7 @@ some_key:
## Renaming Pages
It can happen that an integration 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 integration/platform name, to the page in a [note](/docs/documenting/create-page/#html).
It can happen that an integration 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 integration/platform name, to the page in a [note](/documenting/create-page.md/#html).
```text
---

2
docs/entity_registry_disabled_by.md
View File

@ -35,6 +35,6 @@ If `disable_new_entities` is set to `True` and `entity_registry_enabled_default`
Some integrations will want to offer options to the user to control which entities are being added to Home Assistant. For example, the Unifi integration offers options to enable/disable wireless and wired clients.
Integrations can offer options to users either via [configuration.yaml](/docs/configuration_yaml_index) or using an [Options Flow](config_entries_options_flow_handler.md).
Integrations can offer options to users either via [configuration.yaml](/configuration_yaml_index.md) or using an [Options Flow](/config_entries_options_flow_handler.md).
If this option is offered by integrations, you should not leverage the disabled_by property in the entity registry. Instead, if entities are disabled via a config options flow, remove them from the device and entity registry.

2
docs/frontend/development.md
View File

@ -23,7 +23,7 @@ git remote add upstream https://github.com/home-assistant/home-assistant/fronten
### 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).
You will need to have an instance of Home Assistant set up. See our guide on [setting up a development environment](/development_environment.md).
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 frontend repository that you cloned in the last step:

2
docs/operating-system/debugging.md
View File

@ -35,7 +35,7 @@ You will initially be logged in to Home Assistant CLI for HassOS where you can p
[CLI functions]: https://www.home-assistant.io/hassio/commandline/
[Home Assistant OS]: https://github.com/home-assistant/hassos
[Supervisor Architecture]: https://developers.home-assistant.io/docs/architecture_index/
[Supervisor Architecture]: /architecture_index.md
## Checking the logs

2
docs/supervisor/developing.md
View File

@ -41,7 +41,7 @@ Voila. Your local Home Assistant installation will now connect to a remote Hass.
## Frontend development
To do frontend development you need to have a [Home Assistant frontend development environment](frontend_index.md) set up.
To do frontend development you need to have a [Home Assistant frontend development environment](/frontend/development.md) set up.
Update the Hass.io component configuration in your `configuration.yaml` to point at the frontend repository: