Misc fixes: e.g. -> e.g., and proper case for Home Assistant (#4942)

* e.g. to e.g., and proper case for Home Assistant

* Instructions how to -> Instructions on how to
This commit is contained in:
Alok Saboo 2018-03-17 15:20:37 -04:00 committed by Franck Nijhof
parent 3fd5cd5f94
commit 1aca7b08cf
764 changed files with 883 additions and 885 deletions

View file

@ -28,7 +28,7 @@ Not all existing platforms follow the requirements in this checklist. This canno
### {% linkable_title 3. Configuration %}
1. Voluptuous schema present for config validation
2. Voluptuous schema extends schema from component<br>(e.g. `light.hue.PLATFORM_SCHEMA` extends `light.PLATFORM_SCHEMA`)
2. Voluptuous schema extends schema from component<br>(e.g., `light.hue.PLATFORM_SCHEMA` extends `light.PLATFORM_SCHEMA`)
3. Default parameters specified in voluptuous schema, not in `setup_platform(…)`
4. Your `PLATFORM_SCHEMA` should use as many generic config keys as possible from `homeassistant.const`
```python
@ -58,7 +58,7 @@ Not all existing platforms follow the requirements in this checklist. This canno
### {% linkable_title 5. Entity %}
1. Extend entity from component, e.g. `class HueLight(Light)`
1. Extend entity from component, e.g., `class HueLight(Light)`
2. Do not call `update()` in constructor, use `add_devices(devices, True)` instead.
3. Do not do any I/O inside properties. Cache values inside `update()` instead.
4. The state and/or attributes should not contain relative time since something happened. Instead it should store UTC timestamps.

View file

@ -1,7 +1,7 @@
---
layout: page
title: "Requirements & Dependencies"
description: "Instructions how to define requirements and dependencies."
description: "Instructions on how to define requirements and dependencies."
date: 2016-04-16 13:32
sidebar: true
comments: false

View file

@ -1,7 +1,7 @@
---
layout: page
title: "Handling events"
description: "Instructions how to handle events with your component."
description: "Instructions on how to handle events with your component."
date: 2016-04-16 13:32
sidebar: true
comments: false

View file

@ -1,7 +1,7 @@
---
layout: page
title: "Loading your components"
description: "Instructions how to get your component loaded by Home Assistant."
description: "Instructions on how to get your component loaded by Home Assistant."
date: 2016-04-16 13:32
sidebar: true
comments: false

View file

@ -1,7 +1,7 @@
---
layout: page
title: "Handling states"
description: "Instructions how to handle states with your component."
description: "Instructions on how to handle states with your component."
date: 2016-07-01 20:00
sidebar: true
comments: false

View file

@ -1,7 +1,7 @@
---
layout: page
title: "Handling visibility"
description: "Instructions how to handle visibility with your component."
description: "Instructions on how to handle visibility with your component."
date: 2016-07-01 20:00
sidebar: true
comments: false

View file

@ -16,7 +16,7 @@ To ensure that the documentation for Home Assistant is consistent and easy to fo
* 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".
* 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 {% raw %}`{% linkable_title %}`{% endraw %} tag.
## {% linkable_title Component and Platform Pages %}

View file

@ -17,7 +17,7 @@ There are different ways for communication between add-ons inside Hass.io.
We use an internal network that allows to communicate with every add-on, even to/from Home Assistant, by using his name or alias. Only the add-ons which run on the host network are a bit limited. These can talk with all internal add-ons by their name but all other add-on can't address these add-on by name - using an alias works for both!
Name/alias are used for communication inside Hass.io.
The name is generated using the following format: `{REPO}_{SLUG}`, e.g. `local_xy` or `3283fh_myaddon`. In this example, `{SLUG}` is defined in an add-ons `config.json`. If an add-on is installed locally, `{REPO}` will be `local`. If the add-on is installed from a Github repository, `{REPO}` is a hashed identifier generated from the GitHub repository's URL (ex: https://github.com/xy/my_hassio_addons). See [here](https://github.com/home-assistant/hassio/blob/587047f9d648b8491dc8eef17dc6777f81938bfd/hassio/addons/utils.py#L17) to understand how this identifier is generated. Note that this identifier is required in certain service calls that use the [Hass.io add-on API](hassio-addon-api). You can view the repository identifiers for all currently installed add-ons via a GET request to the hassio API `addons` endpoint.
The name is generated using the following format: `{REPO}_{SLUG}`, e.g., `local_xy` or `3283fh_myaddon`. In this example, `{SLUG}` is defined in an add-ons `config.json`. If an add-on is installed locally, `{REPO}` will be `local`. If the add-on is installed from a Github repository, `{REPO}` is a hashed identifier generated from the GitHub repository's URL (ex: https://github.com/xy/my_hassio_addons). See [here](https://github.com/home-assistant/hassio/blob/587047f9d648b8491dc8eef17dc6777f81938bfd/hassio/addons/utils.py#L17) to understand how this identifier is generated. Note that this identifier is required in certain service calls that use the [Hass.io add-on API](hassio-addon-api). You can view the repository identifiers for all currently installed add-ons via a GET request to the hassio API `addons` endpoint.
Use `hassio` for communication with the internal API.