jeans/home-assistant.io
jeans/home-assistant.io
1
0
Fork 0
mirror of https://github.com/home-assistant/home-assistant.io.git synced 2025-07-19 07:17:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fixed typos and format inconsistencies (#1123)

Browse Source 
Please check these sentences:
"We test the configuration to ensure that users have a great experience and minimize notifications if something is wrong with a platform or component setup before Home Assistant runs."
"If a sensor has a pre-defined list of available options, test to make sure the configuration entry matches the list."

I wasn't sure if I got the intent correct, and in the second one I wasn't sure what you meant by "it"
This commit is contained in:
Hillary Fraley 2016-10-04 16:39:18 -04:00 committed by Fabian Affolter
parent 7b5efaa7a1
commit 93b097fd9c
1 changed files with 16 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
source/developers/development_validation.markdown
View File

@ -9,11 +9,11 @@ sharing: true
footer: true
---
The `configuration.yaml` file contains the configuration options for components and platforms. To ensure that the given configuration provided by the user is valid we use [voluptuous](https://pypi.python.org/pypi/voluptuous) to check it. Certain entries are optional or could be required for the setup of a platform or a component. Others must be of a definied type or out of an already defined list.
The `configuration.yaml` file contains the configuration options for components and platforms. We use [voluptuous](https://pypi.python.org/pypi/voluptuous) to make sure that the configuration provided by the user is valid. Some entries are optional or could be required to set up a platform or a component. Others must be a defined type or from an already-defined list.
The goal of testing the configuration is to assure that users have a great experience due to notifications if something is wrong with a platform or component setup before Home Assistant is running.
We test the configuration to ensure that users have a great experience and minimize notifications if something is wrong with a platform or component setup before Home Assistant runs.
Beside the [voluptuous](https://pypi.python.org/pypi/voluptuous) default types are a bunch of custom types available. To get a full overview take a look at the [config_validation.py](https://github.com/home-assistant/home-assistant/blob/master/homeassistant/helpers/config_validation.py) helper.
Besides [voluptuous](https://pypi.python.org/pypi/voluptuous) default types, many custom types are available. For an overview, take a look at the [config_validation.py](https://github.com/home-assistant/home-assistant/blob/master/homeassistant/helpers/config_validation.py) helper.
- Types: `string`, `byte`, and `boolean`
- Entity ID: `entity_id` and `entity_ids`
@ -21,21 +21,21 @@ Beside the [voluptuous](https://pypi.python.org/pypi/voluptuous) default types a
- Time: `time`, `time_zone`
- Misc: `template`, `slug`, `temperature_unit`, `latitude`, `longitude`, `isfile`, `sun_event`, `ensure_list`, `port`, `url`, and `icon`
To validate plaforms using [MQTT](/components/mqtt/) there are `valid_subscribe_topic` and `valid_publish_topic` present.
To validate plaforms using [MQTT](/components/mqtt/), `valid_subscribe_topic` and `valid_publish_topic` are available.
Some things to keep in mind:
- Use the constants which are definded in `const.py`.
- Import `PLATFORM_SCHEMA` from parent component and extend it.
- Preferred order is `required` first, then `optional`.
- Use the constants defined in `const.py`
- Import `PLATFORM_SCHEMA` from the parent component and extend it
- Preferred order is `required` first and `optional` second
### {% linkable_title Snippets %}
This section contains a couple of snippets for the validation we use.
This section contains snippets for the validation we use.
### {% linkable_title Default name %}
#### {% linkable_title Default name %}
It's common to set a default for a sensor if the user is not providing a name to use.
It's common to set a default for a sensor if the user doesn't provide a name to use.
```python
DEFAULT_NAME = 'Sensor name'
@ -45,9 +45,9 @@ PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
vol.Optional(CONF_NAME, default=DEFAULT_NAME): cv.string,
```
### {% linkable_title Limit the values %}
#### {% linkable_title Limit the values %}
In certain cases you want to limit the user's input to a couple of options.
You might want to limit the user's input to a couple of options.
```python
DEFAULT_METHOD = 'GET'
@ -57,9 +57,9 @@ PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
vol.Optional(CONF_METHOD, default=DEFAULT_METHOD): vol.In(['POST', 'GET']),
```
### {% linkable_title Port %}
#### {% linkable_title Port %}
As all port numbers are coming out of the range 1 till 65535.
All port numbers are from a range of 1 to 65535.
```python
DEFAULT_PORT = 993
@ -69,9 +69,9 @@ PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
vol.Optional(CONF_PORT, default=DEFAULT_PORT): cv.port,
```
### {% linkable_title Lists %}
#### {% linkable_title Lists %}
If a sensor has a pre-defined list of available options it should be tested if the configuration entry matches it.
If a sensor has a pre-defined list of available options, test to make sure the configuration entry matches the list.
```python
SENSOR_TYPES = {
@ -84,5 +84,3 @@ PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
vol.Optional(CONF_MONITORED_VARIABLES, default=[]):
vol.All(ensure_list, [vol.In(SENSOR_TYPES)]),
```