jeena/home-assistant.github.io
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

Merge branch 'current' into next

Browse source
This commit is contained in:
Fabian Affolter 2017-02-23 19:09:23 +01:00
commit 4edd1cf0ee
No known key found for this signature in database
GPG key ID: DDF3D6F44AAB1336
139 changed files with 1318 additions and 909 deletions
Download patch file Download diff file Expand all files Collapse all files

51
source/_docs/configuration/basic.markdown Normal file
View file

@ -0,0 +1,51 @@
---
layout: page
title: "Setup basic information"
description: "Setting up the basic info of Home Assistant."
date: 2015-03-23 12:50
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/basic/
---
By default, Home Assistant will try to detect your location from IP address geolocation. Home Assistant will automatically select a temperature unit and time zone based on this location. You can overwrite this by adding the following information to your `configuration.yaml`:
```yaml
homeassistant:
# Omitted values in this section will be auto detected using freegeoip.io
# Location required to calculate the time the sun rises and sets
latitude: 32.87336
longitude: 117.22743
# Impacts weather/sunrise data (altitude above sea level in meters)
elevation: 430
# 'metric' for Metric, 'imperial' for Imperial
unit_system: metric
# Pick yours from here:
# http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
time_zone: America/Los_Angeles
# Name of the location where Home Assistant is running
name: Home
```
### {% linkable_title Password protecting the web interface %}
First, you'll want to add a password for the Home Assistant web interface. Use your favourite text editor to open `configuration.yaml` and edit the `http` section:
```yaml
http:
api_password: YOUR_PASSWORD
```
<p class='note warning'>
If you decide to expose your Home Assistant instance to the internet and forget to set a password, your installation could be accessed by everybody.
</p>
See the [HTTP component documentation](/components/http/) for more options, such as the use of HTTPS encryption.

70
source/_docs/configuration/customizing-devices.markdown Normal file
View file

@ -0,0 +1,70 @@
---
layout: page
title: "Customizing devices and services"
description: "Simple customization for devices and services in the frontend."
date: 2016-04-20 06:00
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/customizing-devices/
---
By default, all of your devices will be visible and have a default icon determined by their domain. You can customize the look and feel of your front page by altering some of these parameters. This can be done by overriding attributes of specific entities.
```yaml
homeassistant:
name: Home
unit_system: metric
# etc
customize:
# Add an entry for each entity that you want to overwrite.
sensor.living_room_motion:
hidden: true
thermostat.family_room:
entity_picture: https://example.com/images/nest.jpg
friendly_name: Nest
switch.wemo_switch_1:
friendly_name: Toaster
entity_picture: /local/toaster.jpg
switch.wemo_switch_2:
friendly_name: Kitchen kettle
icon: mdi:kettle
switch.rfxtrx_switch:
assumed_state: false
```
### {% linkable_title Possible values %}
| Attribute | Description |
| --------- | ----------- |
| `friendly_name` | Name of the entity
| `hidden` | Set to `true` to hide the entity.
| `entity_picture` | Url to use as picture for entity
| `icon` | Any icon from [MaterialDesignIcons.com](http://MaterialDesignIcons.com). Prefix name with `mdi:`, ie `mdi:home`.
| `assumed_state` | For switches with an assumed state two buttons are shown (turn off, turn on) instead of a switch. By setting `assumed_state` to `false` you will get the default switch icon.
| `device_class` | Sets the class of the device, changing the device state and icon that is displayed on the UI (see below).
### {% linkable_title Device Class %}
Device class is currently supported by the following platforms:
* [Binary Sensor](/components/binary_sensor/)
* [Cover](/components/cover/)
### {% linkable_title Device Class %}
Device class is currently supported by the following platforms:
* [Binary Sensor](/components/binary_sensor/)
* [Cover](/components/cover/)
### {% linkable_title Reloading customize %}
Home Assistant offers a service to reload the core configuration while Home Assistant is running called `homeassistant/reload_core_config`. This allows you to change your customize section and see it being applied without having to restart Home Assistant. To call this service, go to the <img src='/images/screenshots/developer-tool-services-icon.png' alt='service developer tool icon' class="no-shadow" height="38" /> service developer tools, select the service `homeassistant/reload_core_config` and click "Call Service".
<p class='note warning'>
New customize information will be applied the next time the state of the entity gets updated.
</p>

70
source/_docs/configuration/devices.markdown Normal file
View file

@ -0,0 +1,70 @@
---
layout: page
title: "Adding devices to Home Assistant"
description: "Steps to help you get your devices in Home Assistant."
date: 2015-09-19 09:40
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/devices/
---
Home Assistant will be able to automatically discover many devices and services available on your network if you have [the discovery component](/components/discovery/) enabled (the default setting).
See the [components overview page](/components/) to find installation instructions for your devices and services. If you can't find support for your favorite device or service, [consider adding support](/developers/add_new_platform/).
Usually every entity needs its own entry in the `configuration.yaml` file. There are two styles for multiple entries:
#### {% linkable_title Style 1: Collect every entity under the "parent" %}
```yaml
sensor:
- platform: mqtt
state_topic: "home/bedroom/temperature"
name: "MQTT Sensor 1"
- platform: mqtt
state_topic: "home/kitchen/temperature"
name: "MQTT Sensor 2"
- platform: rest
resource: http://IP_ADDRESS/ENDPOINT
switch:
- platform: vera
```
#### {% linkable_title Style 2: List each device separately %}
You need to append numbers or strings to differentiate the entries, as in the example below. The appended number or string must be unique.
```yaml
media_player livingroom:
platform: mpd
server: IP_ADDRESS
media_player kitchen:
platform: plex
camera 1:
platform: generic
camera 2:
platform: mjpeg
```
### {% linkable_title Grouping devices %}
Once you have several devices set up, it is time to organize them into groups.
Each group consists of a name and a list of entity IDs. Entity IDs can be retrieved from the web interface by using the Set State page in the Developer Tools (<img src='/images/screenshots/developer-tool-states-icon.png' alt='service developer tool icon' class="no-shadow" height="38" />).
```yaml
# Example configuration.yaml entry showing two styles
group:
living_room: light.table_lamp, switch.ac
bedroom:
- light.bedroom
- media_player.nexus_player
```
For more details please check the [Group](/components/group/) page.

85
source/_docs/configuration/events.markdown Normal file
View file

@ -0,0 +1,85 @@
---
layout: page
title: "Events"
description: "Describes all there is to know about events in Home Assistant."
date: 2016-03-12 12:00 -0800
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /topics/events/
---
The core of Home Assistant is the event bus. The event bus allows any component to fire or listen for events. It is the core of everything. For example, any state change will be announced on the event bus as a `state_changed` event containing the previous and the new state of an entity.
Home Assistant contains a few built-in events that are used to coordinate between various components.
### {% linkable_title Event `homeassistant_start` %}
Event `homeassistant_start` is fired when all components from the configuration have been intitialized. This is the event that will start the timer firing off `time_changed` events.
### {% linkable_title Event `homeassistant_stop` %}
Event `homeassistant_stop` is fired when Home Assistant is shutting down. It should be used to close any open connection or release any resources.
### {% linkable_title Event `state_changed` %}
Event `state_changed` is fired when a state changes. Both `old_state` and `new_state` are state objects. [Documentation about state objects.](/topics/state_object/)
Field | Description
----- | -----------
`entity_id` | Entity ID of the changed entity. Example: `light.kitchen`
`old_state` | The previous state of the entity before it changed. This field is ommitted if the entity is new.
`new_state` | The new state of the entity. This field is ommitted if the entity is removed from the state machine.
### {% linkable_title Event `time_changed` %}
Event `time_changed` is fired every second by the timer and contains the current time.
Field | Description
----- | -----------
`now` | A [datetime object](https://docs.python.org/3.4/library/datetime.html#datetime.datetime) containing the current time in UTC.
### {% linkable_title Event `service_registered` %}
Event `service_registered` is fired when a new service has been registered within Home Assistant.
Field | Description
----- | -----------
`domain` | Domain of the service. Example: `light`.
`service` | The service to call. Example: `turn_on`
### {% linkable_title Event `call_service` %}
Event `call_service` is fired to call a service.
Field | Description
----- | -----------
`domain` | Domain of the service. Example: `light`.
`service` | The service to call. Example: `turn_on`
`service_data` | Dictionary with the service call parameters. Example: `{ 'brightness': 120 }`.
`service_call_id` | String with a unique call id. Example: `23123-4`.
### {% linkable_title Event `service_executed` %}
Event `service_executed` is fired by the service handler to indicate the service is done.
Field | Description
----- | -----------
`service_call_id` | String with the unique call id of the service call that was executed. Example: `23123-4`.
### {% linkable_title Event `platform_discovered` %}
Event `platform_discovered` is fired when a new platform has been discovered by the discovery component.
Field | Description
----- | -----------
`service` | The service that is discovered. Example: `zwave`.
`discovered` | Information that is discovered. Can be a dict, tuple etc. Example: `(192.168.1.10, 8889)`.
### {% linkable_title Event `component_loaded` %}
Event `component_loaded` is fired when a new component has been loaded and initialized.
Field | Description
----- | -----------
`component` | Domain of the component that has just been initialized. Example: `light`.

180
source/_docs/configuration/group_visibility.markdown Normal file
View file

@ -0,0 +1,180 @@
---
layout: page
title: "Group Visibility"
description: "Instructions how to change group visibility using automations."
date: 2016-10-29 13:00
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /topics/group_visibility/
---
After filling Home Assistant with all your precious home automation devices, you usually end up with a cluttered interface and lots of groups that are not interesting in your current context. What if you just want to show groups that are interesting _now_ and hide the rest? That's when group visibility comes to play.
## {% linkable_title Changing visibility of a group %}
To change visibility of a group, use the service `group.set_visibility`, pass the group name as `entity_id` and use `visible` to decide wheter the group should be shown or hidden.
```yaml
service: group.set_visibility
entity_id: group.basement
data:
visible: False
```
<p class='note'>
If a sensor belongs to only one group and that group is hidden, the sensor will "jump" to the top of the web interface. Add the sensor to an additional (visible) group if you do not want this to happen.
</p>
## {% linkable_title Automations %}
First you should decide under which circumstances a group should be visible or not. Depending on the complexity, you might have to write two automations: one that hides the group and another that shows it.
In this example, the group `group.basement` is hidden when the sun sets and shown again when it rises:
```yaml
automation:
trigger:
platform: sun
event: sunset
action:
service: group.set_visibility
entity_id: group.basement
data:
visible: False
automation 2:
trigger:
platform: sun
event: sunrise
action:
service: group.set_visibility
entity_id: group.basement
data:
visible: True
```
## {% linkable_title Easier automations %}
One of the most common uses cases are to show groups during certain times of day, maybe commuting information during a work day morning or light switches when it is getting dark. The complexity of automations needed to make this happen will quickly get out of hand. So, one way to make the automations easier is to create a sensor that alters its state depending on time of day. One way of doing that is using a `command_line` sensor and a script:
```python
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from datetime import time, datetime
def mk_occasion(name, start, end, days=None):
s = start.split(':')
e = end.split(':')
return {'name' : name,
'start': time(int(s[0]), int(s[1]), int(s[2])),
'end' : time(int(e[0]), int(e[1]), int(e[2])),
'days' : days}
# Matching is done from top to bottom
OCCASIONS = [
# More specific occasions
mk_occasion('work_morning', '06:00:00', '07:10:00', range(5)),
# General matching
mk_occasion('weekday', '00:00:00', '23:59:59', range(5)),
mk_occasion('weekend', '00:00:00', '23:59:59', [5, 6])
]
def get_current_occasion(occasion_list, default_occasion='normal'):
now = datetime.now()
for occasion in OCCASIONS:
if occasion['start'] <= now.time() <= occasion['end'] and \
(occasion['days'] is None or now.weekday() in occasion['days']):
return occasion['name']
return default_occasion
if __name__ == '__main__':
print(get_current_occasion(OCCASIONS))
```
This script will output "work_morning" from 06:00-07:10 during weekdays (monday-friday), "weekday" during all other time from monday-friday and "weekend" on saturdays and sundays. Adjust according to your needs. To create the sensor, just add it like this:
```yaml
sensor:
- platform: command_line
name: Occasion
command: "python3 occasion.py"
```
To simplify things, we create a Home Assistant script that changes the visibility of a group, but also verifies that an entity is in a specific state:
```yaml
script:
group_visibility:
sequence:
- service: group.set_visibility
data_template:
entity_id: '{% raw %}{{ entity_id }}{% endraw %}'
visible: '{% raw %}{{ is_state(cond, visible_state) }}{% endraw %}'
```
The last part is writing an automation that hides or shows the group:
```yaml
automation:
- alias: Work morning
trigger:
- platform: state
entity_id: sensor.occasion
- platform: event
event_type: homeassistant_start
action:
service: script.group_visibility
data:
entity_id: group.work_sensors
cond: sensor.occasion
visible_state: 'work_morning'
```
Our previously defined script will be called if `sensor.occasion` changes state OR when Home Assistant has started. The group `group.work_sensors` will be shown when `sensor.occasion` changes state to "work_morning" and hidden otherwise.
### {% linkable_title The complete example %}
```yaml
group:
default_view:
entities:
- group.work_sensors
# Only visible when it's time to go to work
work_sensors:
name: Time to go to work
entities:
- sensor.something1
- sensor.something2
sensor:
- platform: command_line
name: Occasion
command: "python3 occasion.py"
script:
group_visibility:
sequence:
- service: group.set_visibility
data_template:
entity_id: '{% raw %}{{ entity_id }}{% endraw %}'
visible: '{% raw %}{{ is_state(cond, visible_state) }}{% endraw %}'
automation:
- alias: Work morning
trigger:
- platform: state
entity_id: sensor.occasion
- platform: event
event_type: homeassistant_start
action:
service: script.group_visibility
data:
entity_id: group.work_sensors
cond: sensor.occasion
visible_state: 'work_morning'
```

92
source/_docs/configuration/packages.markdown Normal file
View file

@ -0,0 +1,92 @@
---
layout: page
title: "Packages"
description: "Describes all there is to know about configuration packages in Home Assistant."
date: 2017-01-10 20:00 +0200
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /topics/packages/
---
Packages in Home Assistant provides a way to bundle different component's configuration together. We were already introduced to the two configuration styles (specifying platforms entries together or individually) on the [adding devices](/docs/configuration/devices/) page. Both of these configuration methods require you to create the component key in the main `configuration.yaml` file. With packages we have a way to include different components, or parts of configuration using any of the `!include` directives introduced in [splitting the configuration](/docs/configuration/splitting_configuration).
Packages are configured under the core `homeassistant/packages` in the configuration and take the format of a packages name (no spaces, all lower case) followed by a dictionary with the package config. For example, package `pack_1` would be created as:
```yaml
homeassistant:
...
packages:
pack_1:
...package configuration here...
```
The package configuration can include: `switch`, `light`, `automation`, `groups` or the majority of the Home Assistant components.
It can be specified inline or in a seperate YAML file using `!include`.
Inline example, main `configuration.yaml`:
```yaml
homeassistant:
...
packages:
pack_1:
switch:
- platform: rest
...
light:
- platform: rpi
...
```
Include example, main `configuration.yaml`:
```yaml
homeassistant:
...
packages:
pack_1: !include my_package.yaml
```
The file `my_package.yaml` contains the "top-level" configuration:
```
switch:
- platform: rest
...
light:
- platform: rpi
...
```
There are some rules for packages that will be merged:
1. Component names may only use the basic form (e.g. `switch` and `switch 1` or `switch aa` is not accepted).
2. Platform based components (`light`, `switch`, etc) can always be merged.
3. Components where entities are identified by a key that will represent the entity_id (`{key: config}`) need to have unique 'keys' between packages and the main configuration file.
For example if we have the following in the main config. You are not allowed to re-use "my_input" again for `input_boolean` in a package:
```yaml
input_boolean:
my_input:
```
4. Any component that is not a platform [2], or dictionaries with Entity ID keys [3] cannot be merged and can only occur once between all packages and the main configuration.
<p class='note tip'>
Components inside packages can only specify platform entries using configuration style 1, where all the platforms are grouped under the component name.
</p>
### {% linkable_title Create a packages folder %}
One way to organise packages would be to create a folder named "packages" in your Home Assistant configuration directory. In the packages directory you can store any number of packages in a YAML file. This entry in your `configuration.yaml` will load all packages:
```yaml
homeassistant:
packages: !include_dir_named packages
```
This uses the concept splitting the configuration and will include all files in a directory with the keys representing the filenames.
See the documentation about [splitting the configuration](/docs/configuration/splitting_configuration/) for more information about `!include_dir_named` and other include statements that might be helpful.

35
source/_docs/configuration/platform_options.markdown Normal file
View file

@ -0,0 +1,35 @@
---
layout: page
title: "Entity component platform options"
description: "Shows how to customize polling interval for any component via configuration.yaml."
date: 2016-02-12 23:17 -0800
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /topics/platform_options/
---
Any component that is based on the entity component allows various extra options to be set per platform.
### {% linkable_title Entity namespace %}
By setting an entity namespace, all entities will be prefixed with that namespace. That way `light.bathroom` can become `light.holiday_house_bathroom`.
```yaml
# Example configuration.yaml entry
light:
platform: hue
entity_namespace: holiday_house
```
### {% linkable_title Scan Interval %}
Platforms that require polling will be polled in an interval specified by the main component. For example a light will check every 30 seconds for a changed state. It is possible to overwrite this scan interval for any platform that is being polled by specifying a `scan_interval` config key. In the example below we setup the Philips Hue lights but tell Home Assistant to poll the devices every 10 seconds instead of the default 30 seconds.
```yaml
# Example configuration.yaml entry to poll Hue lights every 10 seconds.
light:
platform: hue
scan_interval: 10
```

24
source/_docs/configuration/remote.markdown Normal file
View file

@ -0,0 +1,24 @@
---
layout: page
title: "Remote access"
description: "Setting up remote access for Home Assistant."
date: 2015-03-23 12:50
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/basic/#remote-access
---
If you're interested in logging in to Home Assistant while away, you'll have to make your instance remotely accessible.
The most common approach is to set up port forwarding from your router to port 8123 on the computer that is hosting Home Assistant. General instructions on how to do this can be found by searching `<router model> port forwarding instructions`.
A problem with making a port accessible is that some Internet Service Providers only offer dynamic IPs. This can cause you to lose access to Home Assistant while away. You can solve this by using a free Dynamic DNS service like [DuckDNS](https://www.duckdns.org/).
Remember: Just putting a port up is not secure. You should definitely consider encrypting your traffic if you are accessing your Home Assistant installation remotely. For details please check the [set up encryption using Let's Encrypt](/blog/2015/12/13/setup-encryption-using-lets-encrypt/) blog post.
Protect your communication with a [self-signed certificate](/cookbook/tls_self_signed_certificate/) between your client and the Home Assistant instance.
For another way to access your Home Assistant frontend, check out [the instructions how to use Tor](/cookbook/tor_configuration/).

91
source/_docs/configuration/secrets.markdown Normal file
View file

@ -0,0 +1,91 @@
---
layout: page
title: "Storing secrets"
description: "Storing secrets outside of your configuration.yaml."
date: 2016-07-01 08:30
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /topics/secrets/
---
The `configuration.yaml` file is a plain-text file, thus it is readable by anyone who has access to the file. The file contains passwords and API tokens which need to be redacted if you want to share your configuration. By using `!secrets` you can remove any private information from you configuration files. This separation can also help you to keep easier track of your passwords and API keys. As they are all stored at one place and no longer spread across the `configuration.yaml` file or even multiple yaml files if you [split up your configuration](/topics/splitting_configuration/).
### {% linkable_title Using secrets.yaml %}
The workflow for moving private information to `secrets.yaml` is very similar to the [splitting of the configuration](/topics/splitting_configuration/). Create a `secrets.yaml` file in your Home assistant configuration directory (The location of the folder differs between operating systems: on OS X and Linux it's `~/.homeassistant` and on Windows it's `%APPDATA%/.homeassistant`).
The entries for password and API keys in the `configuration.yaml` file usually looks like the example below.
```yaml
http:
api_password: YOUR_PASSWORD
```
Those entries need to be replaced with `!secret` and a identifier.
```yaml
http:
api_password: !secret http_password
```
The `secrets.yaml` file contains the corresponding password assigned to the identifier.
```yaml
http_password: YOUR_PASSWORD
```
### {% linkable_title Debugging secrets %}
When you start splitting your configuration into multiple files, you might end up with configuration in sub folders. Secrets will be resolved in this order:
- A `secrets.yaml` located in the same folder as the yaml file referencing the secret,
- next, parent folders will be searched for a `secrets.yaml` file with the secret, stopping at the folder with the main `configuration.yaml`,
- lastly, `keyring` will be queried for the secret (more info below)
To see where secrets are being loaded from you can either add an option to your `secrets.yaml` file or use the `check_config` script.
*Option 1*: Print where secrets are retrieved from to the Home Assistant log by adding the following to `secrets.yaml`:
```yaml
logger: debug
```
This will not print the actual secret's value to the log.
*Option 2*: View where secrets are retrieved from and the contents of all `secrets.yaml` files used, you can use the `check_config` script from the command line:
```bash
hass --script check_config --secrets
```
This will print all your secrets
### {% linkable_title Storing passwords in a keyring managed by your OS %}
Using [Keyring](http://pythonhosted.org/keyring/) is an alternative way to `secrets.yaml`. They can be managed from the command line via the keyring script.
```bash
$ hass --script keyring --help
```
To store a password in keyring, replace your password or API key with `!secret` and an identifier in `configuration.yaml` file.
```yaml
http:
api_password: !secret http_password
```
Create an entry in your keyring.
```bash
$ hass --script keyring set http_password
```
If you launch Home Assistant now, you will be prompted for the keyring password to unlock your keyring.
```bash
$ hass
Config directory: /home/fab/.homeassistant
Please enter password for encrypted keyring:
```
<p class='note warning'>
If your are using the Python Keyring, [autostarting](/getting-started/autostart/) of Home Assistant will no longer work.
</p>

30
source/_docs/configuration/securing.markdown Normal file
View file

@ -0,0 +1,30 @@
---
layout: page
title: "Securing"
description: "Instructions how to secure your Home Assistant installation."
date: 2016-10-06 06:00
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/securing/
---
One major advantage of Home Assistant is that it's not dependent on cloud services. Even if you're only using Home Assistant on a local network, you should take steps to secure your instance.
### {% linkable_title Checklist %}
- [Protect your web interface with a password](https://home-assistant.io/getting-started/basic/#password-protecting-the-web-interface)
- Secure your host. Sources could be [Red Hat Enterprise Linux 7 Security Guide](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf), [CIS Red Hat Enterprise Linux 7 Benchmark](https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v1.0.0.pdf), or the [Securing Debian Manual](https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html).
- Restrict network access to your devices. Set `PermitRootLogin no` in your sshd config (usually `/etc/ssh/sshd_config`) and to use SSH keys for authentication instead of passwords.
- Don't run Home Assistant as root – consider the Principle of Least Privilege.
- Keep your [secrets](/topics/secrets/) safe.
If you want to allow remote access, consider these additional points:
- Protect your communication with [TLS](/blog/2015/12/13/setup-encryption-using-lets-encrypt/)
- Protect your communication with [Tor](/cookbook/tor_configuration/)
- Protect your communication with a [self-signed certificate](/cookbook/tls_self_signed_certificate/)
- Use a [proxy](/cookbook/apache_configuration/)

443
source/_docs/configuration/splitting_configuration.markdown Normal file
View file

@ -0,0 +1,443 @@
---
layout: page
title: "Splitting up the configuration"
description: "Splitting the configuration.yaml into several files."
date: 2016-03-25 23:30
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/yaml/
---
So you've been using Home Assistant for a while now and your [configuration.yaml file brings people to tears](https://home-assistant.io/cookbook/configuration_yaml_from_bassclarinetl2/) or you simply want to start off with the distributed approach, here's how to "split the configuration.yaml" into more manageable (read: humanly readable) pieces.
First off, several community members have sanitized (read: without api keys/passwords etc) versions of their configurations available for viewing, you can see a list of them [here](https://home-assistant.io/cookbook/#example-configurationyaml).
As commenting code doesn't always happen, please read on for the details.
Now despite the logical assumption that the `configuration.yaml` will be replaced by this process it will in fact remain, albeit in a much less cluttered form.
In this lighter version we will still need what could be called the core snippet:
```yaml
homeassistant:
# Name of the location where Home Assistant is running
name: My Home Assistant Instance
# Location required to calculate the time the sun rises and sets
latitude: 37
longitude: -121
# 'metric' for Metric, 'imperial' for Imperial
unit_system: imperial
# Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
time_zone: America/Los_Angeles
customize: !include customize.yaml
```
Note that each line after `homeassistant:` is indented two (2) spaces. Since the configuration files in Home Assistant are based on the YAML language, indentation and spacing are important. Also note that seemingly strange entry under `customize:`.
`!include filename.yaml` is the statement that tells Home Assistant to insert the contents of `filename.yaml` at that point. This is how we are going to break a monolithic and hard to read file (when it gets big) into more manageable chunks.
Now before we start splitting out the different components, let's look at the other components (in our example) that will stay in the base file:
```yaml
history:
frontend:
logbook:
http:
api_password: ImNotTelling!
ifttt:
key: [nope]
wink:
access_token: [wouldn't you]
refresh_token: [like to know]
zwave:
usb_path: /dev/ttyUSB0
config_path: /usr/local/share/python-openzwave/config
polling_interval: 10000
mqtt:
broker: 127.0.0.1
```
As with the core snippet, indentation makes a difference. The component headers (`mqtt:`) should be fully left aligned (aka no indent), and the parameters (`broker:`) should be indented two (2) spaces.
While some of these components can technically be moved to a separate file they are so small or "one off's" where splitting them off is superfluous. Also, you'll notice the # symbol (hash/pound). This represents a "comment" as far as the commands are interpreted. Put another way, any line prefixed with a `#` will be ignored. This makes breaking up files for human readability really convenient, not to mention turning off features while leaving the entry intact. (Look at the `zigbee:` entry above and the b entry further down)
Now, lets assume that a blank file has been created in the Home Assistant configuration directory for each of the following:
```text
automation.yaml
zones.yaml
sensors.yaml
switches.yaml
device_tracker.yaml
customize.yaml
```
`automation.yaml` will hold all the automation component details. `zones.yaml` will hold the zone component details and so forth. These files can be called anything but giving them names that match their function will make things easier to keep track of.
Inside the base configuration file add the following entries:
```yaml
automation: !include automation.yaml
zone: !include zones.yaml
sensor: !include sensors.yaml
switch: !include switches.yaml
device_tracker: !include device_tracker.yaml
```
Note that there can only be one `!include:` for each component so chaining them isn't going to work. If that sounds like greek, don't worry about it.
Alright, so we've got the single components and the include statements in the base file, what goes in those extra files?
Let's look at the `device_tracker.yaml` file from our example:
```yaml
- platform: owntracks
- platform: nmap_tracker
hosts: 192.168.2.0/24
home_interval: 3
track_new_devices: yes
interval_seconds: 40
consider_home: 120
```
This small example illustrates how the "split" files work. In this case, we start with a "comment block" identifying the file followed by two (2) device tracker entries (`owntracks` and `nmap`). These files follow ["style 1"](/getting-started/devices/#style-2-list-each-device-separately) that is to say a fully left aligned leading entry (`- platform: owntracks`) followed by the parameter entries indented two (2) spaces.
This (large) sensor configuration gives us another example:
```yaml
### sensors.yaml
### METEOBRIDGE #############################################
- platform: tcp
name: 'Outdoor Temp (Meteobridge)'
host: 192.168.2.82
timeout: 6
payload: "Content-type: text/xml; charset=UTF-8\n\n"
value_template: "{% raw %}{{value.split (' ')[2]}}{% endraw %}"
unit: C
- platform: tcp
name: 'Outdoor Humidity (Meteobridge)'
host: 192.168.2.82
port: 5556
timeout: 6
payload: "Content-type: text/xml; charset=UTF-8\n\n"
value_template: "{% raw %}{{value.split (' ')[3]}}{% endraw %}"
unit: Percent
#### STEAM FRIENDS ##################################
- platform: steam_online
api_key: [not telling]
accounts:
- 76561198012067051
#### TIME/DATE ##################################
- platform: time_date
display_options:
- 'time'
- 'date'
- platform: worldclock
time_zone: Etc/UTC
name: 'UTC'
- platform: worldclock
time_zone: America/New_York
name: 'Ann Arbor'
```
You'll notice that this example includes a secondary parameter section (under the steam section) as well as a better example of the way comments can be used to break down files into sections.
That about wraps it up.
If you have issues checkout `home-assistant.log` in the configuration directory as well as your indentations. If all else fails, head over to the [Gitter Chatroom](https://gitter.im/balloob/home-assistant) and ask away.
### {% linkable_title Debugging multiple configuration files %}
If you have many configuration files, the `check_config` script allows you to see how Home Assistant interprets them:
- Listing all loaded files: `hass --script check_config --files`
- Viewing a component's config: `hass --script check_config --info light`
- Or all components' config: `hass --script check_config --info all`
You can get help from the command line using: `hass --script check_config --help`
### {% linkable_title Advanced Usage %}
We offer four advanced options to include whole directories at once.
- `!include_dir_list` will return the content of a directory as a list with each file content being an entry in the list.
- `!include_dir_named` will return the content of a directory as a dictionary which maps filename => content of file.
- `!include_dir_merge_list` will return the content of a directory as a list by merging all files (which should contain a list) into 1 big list.
- `!include_dir_merge_named` will return the content of a directory as a dictionary by loading each file and merging it into 1 big dictionary.
These work recursively. As an example using `!include_dir_* automation`, will include all 6 files shown below:
```bash
.
└── .homeassistant
├── automation
│   ├── lights
│   │   ├── turn_light_off_bedroom.yaml
│   │   ├── turn_light_off_lounge.yaml
│   │   ├── turn_light_on_bedroom.yaml
│   │   └── turn_light_on_lounge.yaml
│   ├── say_hello.yaml
│   └── sensors
│   └── react.yaml
└── configuration.yaml (not included)
```
#### {% linkable_title Example: `!include_dir_list` %}
`configuration.yaml`
```yaml
automation:
- alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
- alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
```
can be turned into:
`configuration.yaml`
```yaml
automation: !include_dir_list automation/presence/
```
`automation/presence/automation1.yaml`
```yaml
alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
```
`automation/presence/automation2.yaml`
```yaml
alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
```
It is important to note that each file must contain only **one** entry when using `!include_dir_list`.
#### {% linkable_title Example: `!include_dir_named` %}
`configuration.yaml`
```yaml
{% raw %}
alexa:
intents:
LocateIntent:
action:
service: notify.pushover
data:
message: Your location has been queried via Alexa.
speech:
type: plaintext
text: >
{%- for state in states.device_tracker -%}
{%- if state.name.lower() == User.lower() -%}
{{ state.name }} is at {{ state.state }}
{%- endif -%}
{%- else -%}
I am sorry. Pootie! I do not know where {{User}} is.
{%- endfor -%}
WhereAreWeIntent:
speech:
type: plaintext
text: >
{%- if is_state('device_tracker.iphone', 'home') -%}
iPhone is home.
{%- else -%}
iPhone is not home.
{% endif %}{% endraw %}
```
can be turned into:
`configuration.yaml`
```yaml
alexa:
intents: !include_dir_named alexa/
```
`alexa/LocateIntent.yaml`
```yaml
{% raw %}
action:
service: notify.pushover
data:
message: Your location has been queried via Alexa.
speech:
type: plaintext
text: >
{%- for state in states.device_tracker -%}
{%- if state.name.lower() == User.lower() -%}
{{ state.name }} is at {{ state.state }}
{%- endif -%}
{%- else -%}
I am sorry. Pootie! I do not know where {{User}} is.
{%- endfor -%}{% endraw %}
```
`alexa/WhereAreWeIntent.yaml`
```yaml
{% raw %}
speech:
type: plaintext
text: >
{%- if is_state('device_tracker.iphone', 'home') -%}
iPhone is home.
{%- else -%}
iPhone is not home.
{% endif %}{% endraw %}
```
#### {% linkable_title Example: `!include_dir_merge_list` %}
`configuration.yaml`
```yaml
automation:
- alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
- alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
```
can be turned into:
`configuration.yaml`
```yaml
automation: !include_dir_merge_list automation/
```
`automation/presence.yaml`
```yaml
- alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
- alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
```
It is important to note that when using `!include_dir_merge_list`, you must include a list in each file (each list item is denoted with a hyphen [-]). Each file may contain one or more entries.
#### {% linkable_title Example: `!include_dir_merge_named` %}
`configuration.yaml`
```yaml
group:
bedroom:
name: Bedroom
entities:
- light.bedroom_lamp
- light.bedroom_overhead
hallway:
name: Hallway
entities:
- light.hallway
- thermostat.home
front_yard:
name: Front Yard
entities:
- light.front_porch
- light.security
- light.pathway
- sensor.mailbox
- camera.front_porch
```
can be turned into:
`configuration.yaml`
```yaml
group: !include_dir_merge_named group/
```
`group/interior.yaml`
```yaml
bedroom:
name: Bedroom
entities:
- light.bedroom_lamp
- light.bedroom_overhead
hallway:
name: Hallway
entities:
- light.hallway
- thermostat.home
```
`group/exterior.yaml`
```yaml
front_yard:
name: Front Yard
entities:
- light.front_porch
- light.security
- light.pathway
- sensor.mailbox
- camera.front_porch
```

43
source/_docs/configuration/state_object.markdown Normal file
View file

@ -0,0 +1,43 @@
---
layout: page
title: "State Objects"
description: "Describes all there is to know about state objects in Home Assistant."
date: 2016-03-12 12:00 -0800
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /topics/state_object/
---
Your devices are represented in Home Assistant as entities. The entities will write their current state to the state machine for other entities/templates/frontend to access. States are a current representation of the entity.
If you overwrite a state via the states dev tool or the API, it will not impact the actual device. If the device state is being polled, it will overwrite the state in the state machine the next polling.
All states will always have an entity id, a state and a timestamp when last updated and last changed.
Field | Description
----- | -----------
`state.state` | String representation of the current state of the entity. Example `off`
`state.entity_id` | Entity ID. Format: `<domain>.<object_id>`. Example: `light.kitchen`.
`state.domain` | Domain of the entity. Example: `light`.
`state.object_id` | Object ID of entity. Example: `kitchen`.
`state.name` | Name of the entity. Based on `friendly_name` attribute with fall back to object ID. Example: `Kitchen Ceiling`.
`state.last_updated` | Time the state was written to the state machine. Note that writing the exact same state including attributes will not result in this field being updated. Example: `14:10:03 13-03-2016`.
`state.last_changed` | Time the state changed. This is not updated when there are only updated attributes. Example: `14:10:03 13-03-2016`.
`state.attributes` | A dictionary with extra attributes related to the current state.
The attributes of an entity are optional. There are a few attributes that are used by Home Assistant for representing the entity in a specific way. Each component will also have it's own attributes to represent extra state data about the entity. For example, the light component has attributes for the current brightness and color of the light. When an attribute is not available, Home Assistant will not write it to the state.
When using templates, attributes will be available by their name. For example `state.attributes.assumed_state`.
Attribute | Description
--------- | -----------
`friendly_name` | Name of the entity. Example: `Kitchen Ceiling`.
`icon` | Icon to use for the entity in the frontend. Example: `mdi:home`.
`hidden` | Boolean if the entity should not be shown in the frontend. Example: `true`.
`entity_picture` | Url to a picture that should be used instead of showing the domain icon. Example: `http://example.com/picture.jpg`.
`assumed_state` | Boolean if the current state is an assumption. [More info](https://home-assistant.io/blog/2016/02/12/classifying-the-internet-of-things/#classifiers) Example: `True`.
`unit_of_measurement` | The unit of measurement the state is expressed in. Used for grouping graphs or understanding the entity. Example: `°C`.
When an attribute contains spaces, you can retrieve it like this: `states.sensor.livingroom.attributes["Battery numeric"]`.

214
source/_docs/configuration/templating.markdown Normal file
View file

@ -0,0 +1,214 @@
---
layout: page
title: "Templating"
description: "Instructions how to use the templating feature of Home Assistant."
date: 2015-12-12 12:00
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /topics/templating/
---
This is an advanced feature of Home Assistant. You'll need a basic understanding of the following things:
- [Home Assistant architecture], especially states.
- [State object]
[Home Assistant architecture]: /developers/architecture/
[State object]: /topics/state_object/
Templating is a powerful feature in Home Assistant that allows the user control over information that is going into and out of the system. It is used for:
- Formatting outgoing messages in, for example, the [notify] and [alexa] components.
- Process incoming data from sources that provide raw data, like [MQTT], [REST sensor], or the [command line sensor].
- [Advanced Automation templating]auto-template]
[notify]: /components/notify/
[alexa]: /components/alexa/
[MQTT]: /components/mqtt/
[REST sensor]: /components/sensor.rest/
[command line sensor]: /components/sensor.command_line/
[auto-template]: /getting-started/automation-templating/
## {% linkable_title Building templates %}
Templating in Home Assistant is powered by the [Jinja2](http://jinja.pocoo.org/) templating engine. This means that we are using their syntax and make some custom Home Assistant variables available to templates during rendering. We will not go over the basics of the syntax, as Jinja2 does a lot better job at this in their [Jinja2 documentation](http://jinja.pocoo.org/docs/dev/templates/).
<p class='note'>
The frontend has a template editor developer tool to help develop and debug templates.
</p>
Templates can get big pretty fast. To keep a clear overview, consider using YAML multiline strings to define your templates:
```yaml
script:
msg_who_is_home:
sequence:
- service: notify.notify
message: >
{% raw %}{% if is_state('device_tracker.paulus', 'home') %}
Ha, Paulus is home!
{% else %}
Paulus is at {{ states('device_tracker.paulus') }}.
{% endif %}{% endraw %}
```
[Jinja2](http://jinja.pocoo.org/) supports a width variety of operations:
- [Mathematical operation](http://jinja.pocoo.org/docs/dev/templates/#math)
- [Comparisons](http://jinja.pocoo.org/docs/dev/templates/#comparisons)
- [Logic](http://jinja.pocoo.org/docs/dev/templates/#logic)
## {% linkable_title Home Assistant template extensions %}
Home Assistant adds extensions to allow templates to access all of the current states:
- Iterating `states` will yield each state sorted alphabetically by entity ID.
- Iterating `states.domain` will yield each state of that domain sorted alphabetically by entity ID.
- `states.sensor.temperature` returns the state object for `sensor.temperature`.
- `states('device_tracker.paulus')` will return the state string (not the object) of the given entity or `unknown` if it doesn't exist.
- `is_state('device_tracker.paulus', 'home')` will test if the given entity is specified state.
- `is_state_attr('device_tracker.paulus', 'battery', 40)` will test if the given entity is specified state.
- `now()` will be rendered as current time in your time zone.
- `utcnow()` will be rendered as UTC time.
- `as_timestamp` will convert datetime object or string to UNIX timestamp
- `distance()` will measure the distance in meters between home, entity, coordinates.
- `closest()` will find the closest entity.
- `relative_time(timestamp)` will format the date time as relative time vs now (ie 7 seconds)
- `float` will format the output as float.
- `strptime(string, format)` will parse a string to a datetime based on a [format][strp-format].
- Filter `round(x)` will convert the input to a number and round it to `x` decimals.
- Filter `timestamp_local` will convert an UNIX timestamp to local time/data.
- Filter `timestamp_utc` will convert an UNIX timestamp to UTC time/data.
- Filter `timestamp_custom(format_string, local_boolean)` will convert an UNIX timestamp to a custom format, the use of a local timestamp is default, supporting [Python format options](https://docs.python.org/3/library/time.html#time.strftime).
- Filter `max` will obtain the larget item in a sequence.
- Filter `min` will obtain the smallest item in a sequence.
[strp-format]: https://docs.python.org/3.4/library/datetime.html#strftime-and-strptime-behavior
## {% linkable_title Examples %}
### {% linkable_title States %}
The next two statements result in same value if state exists. The second one will result in an error if state does not exist.
```text
{% raw %}{{ states('device_tracker.paulus') }}
{{ states.device_tracker.paulus.state }}{% endraw %}
```
### {% linkable_title Attributes %}
Print an attribute if state is defined
```text
{% raw %}{% if states.device_tracker.paulus %}
{{ states.device_tracker.paulus.attributes.battery }}
{% else %}
??
{% endif %}{% endraw %}
```
### {% linkable_title Sensor states %}
Print out a list of all the sensor states.
```text
{% raw %}{% for state in states.sensor %}
{{ state.entity_id }}={{ state.state }},
{% endfor %}
{% if is_state('device_tracker.paulus', 'home') %}
Ha, Paulus is home!
{% else %}
Paulus is at {{ states('device_tracker.paulus') }}.
{% endif %}
{{ states.sensor.temperature | float + 1 }}
{{ (states.sensor.temperature | float * 10) | round(2) }}
{% if states('sensor.temperature') | float > 20 %}
It is warm!
{%endif %}
{{ as_timestamp(states.binary_sensor.garage_door.last_changed) }}
{{ as_timestamp(now()) - as_timestamp(states.binary_sensor.garage_door.last_changed) }}{% endraw %}
```
### {% linkable_title Distance examples %}
If only 1 location is passed in, Home Assistant will measure the distance from home.
```text
{% raw %}Using Lat Lng coordinates: {{ distance(123.45, 123.45) }}
Using State: {{ distance(states.device_tracker.paulus) }}
These can also be combined in any combination:
{{ distance(123.45, 123.45, 'device_tracker.paulus') }}
{{ distance('device_tracker.anne_therese', 'device_tracker.paulus') }}{% endraw %}
```
### {% linkable_title Closest examples %}
Find entities closest to the Home Assistant location:
```text
{% raw %}Query all entities: {{ closest(states) }}
Query all entities of a specific domain: {{ closest('states.device_tracker') }}
Query all entities in group.children: {{ closest('group.children') }}
Query all entities in group.children: {{ closest(states.group.children) }}{% endraw %}
```
Find entities closest to a coordinate or another entity. All previous arguments still apply for 2nd argument.
```text
{% raw %}Closest to a coordinate: {{ closest(23.456, 23.456, 'group.children') }}
Closest to an entity: {{ closest('zone.school', 'group.children') }}
Closest to an entity: {{ closest(states.zone.school, 'group.children') }}{% endraw %}
```
### {% linkable_title Combined %}
Since closest returns a state, we can combine it with distance too.
```text
{% raw %}{{ closest(states).name }} is {{ distance(closest(states)) }} meters away.{% endraw %}
```
## {% linkable_title Processing incoming data %}
The other part of templating is processing incoming data. It will allow you to modify incoming data and extract only the data you care about. This will work only for platforms and components that mentioned support for this in their documentation.
It depends per component or platform, but it is common to be able to define a template using the `value_template` configuration key. When a new value arrives, your template will be rendered while having access to the following values on top of the usual Home Assistant extensions:
| Variable | Description |
| ------------ | -------------------------------------- |
| `value` | The incoming value. |
| `value_json` | The incoming value parsed as JSON. |
```text
# Incoming value:
{"primes": [2, 3, 5, 7, 11, 13]}
# Extract third prime number
{% raw %}{{ value_json.primes[2] }}{% endraw %}
# Format output
{% raw %}{{ "%+.1f" | value_json }}{% endraw %}
# Math
{% raw %}{{ value_json | float * 1024 }}{% endraw %}
{% raw %}{{ float(value_json) * (2**10) }}{% endraw %}
# Timestamps
{% raw %}{{ value_json.tst | timestamp_local }}{% endraw %}
{% raw %}{{ value_json.tst | timestamp_utc }}{% endraw %}
{% raw %}{{ value_json.tst | timestamp_custom('%Y' True) }}{% endraw %}
# Square bracket notation
{% raw %}{{ value_json["001"] }}{% endraw %}
```

89
source/_docs/configuration/troubleshooting.markdown Normal file
View file

@ -0,0 +1,89 @@
---
layout: page
title: "Troubleshooting your configuration"
description: "Common problems with tweaking your configuration and their solutions."
date: 2015-01-20 22:36
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/troubleshooting-configuration/
---
It can happen that you run into trouble while configuring Home Assistant. Perhaps a component is not showing up or is acting strangely. This page will discuss a few of the most common problems.
Before we dive into common issues, make sure you know where your configuration directory is. Home Assistant will print out the configuration directory it is using when starting up.
Whenever a component or configuration option results in a warning, it will be stored in `home-assistant.log` in the configuration directory. This file is reset on start of Home Assistant.
### {% linkable_title My component does not show up %}
When a component does not show up, many different things can be the case. Before you try any of these steps, make sure to look at the `home-assistant.log` file and see if there are any errors related to your component you are trying to set up.
If you have incorrect entries in your configuration files you can use the `check_config` script to assist in identifying them: `hass --script check_config`.
#### {% linkable_title Problems with the configuration %}
One of the most common problems with Home Assistant is an invalid `configuration.yaml` file.
- You can test your configuration using the command line with: `hass --script check_config`
- You can verify your configuration's yaml structure using [this online YAML parser](http://yaml-online-parser.appspot.com/) or [YAML Lint](http://www.yamllint.com/).
- To learn more about the quirks of YAML, read [YAML IDIOSYNCRASIES](https://docs.saltstack.com/en/latest/topics/troubleshooting/yaml_idiosyncrasies.html) by SaltStack (the examples there are specific to SaltStack, but do explain YAML issues well).
`configuration.yaml` does not allow multiple sections to have the same name. If you want to load multiple platforms for one component, you can append a [number or string](/getting-started/devices/#style-2-list-each-device-separately) to the name or nest them using [this style](/getting-started/devices/#style-1-collect-every-entity-under-the-parent):
```yaml
sensor:
- platform: forecast
...
- platform: bitcoin
...
```
Another common problem is that a required configuration setting is missing. If this is the case, the component will report this to `home-assistant.log`. You can have a look at [the various component pages](/components/) for instructions on how to setup the components.
See the [logger](/components/logger/) component for instructions on how to define the level of logging you require for specific modules.
If you find any errors or want to expand the documentation, please [let us know](https://github.com/home-assistant/home-assistant.io/issues).
#### {% linkable_title Problems with dependencies %}
Almost all components have external dependencies to communicate with your devices and services. Sometimes Home Assistant is unable to install the necessary dependencies. If this is the case, it should show up in `home-assistant.log`.
The first step is trying to restart Home Assistant and see if the problem persists. If it does, look at the log to see what the error is. If you can't figure it out, please [report it](https://github.com/home-assistant/home-assistant/issues) so we can investigate what is going on.
#### {% linkable_title Problems with components %}
It can happen that some components either do not work right away or stop working after Home Assistant has been running for a while. If this happens to you, please [report it](https://github.com/home-assistant/home-assistant/issues) so that we can have a look.
#### {% linkable_title Multiple files %}
If you are using multiple files for your setup, make sure that the pointers are correct and the format of the files is valid.
```yaml
light: !include devices/lights.yaml
sensor: !include devices/sensors.yaml
```
Contents of `lights.yaml` (notice it does not contain `light: `):
```yaml
- platform: hyperion
host: 192.168.1.98
...
```
Contents of `sensors.yaml`:
```yaml
- platform: mqtt
name: "Room Humidity"
state_topic: "room/humidity"
- platform: mqtt
name: "Door Motion"
state_topic: "door/motion"
...
```
<p class='note'>
Whenever you report an issue, be aware that we are volunteers who do not have access to every single device in the world nor unlimited time to fix every problem out there.
</p>

63
source/_docs/configuration/yaml.markdown Normal file
View file

@ -0,0 +1,63 @@
---
layout: page
title: "YAML"
description: "Details about YAML to configure Home Assistant."
date: 2015-03-23 12:50
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /getting-started/yaml/
---
Home Assistant uses the [YAML](http://yaml.org/) syntax for configuration. YAML might take a while to get used to but is really powerful in allowing you to express complex configurations.
For each component that you want to use in Home Assistant, you add code in your `configuration.yaml` file to specify its settings.
The following example entry specifies that you want to use the [notify component](/components/notify) with the [pushbullet platform](/components/notify.pushbullet).
```yaml
notify:
platform: pushbullet
api_key: "o.1234abcd"
name: pushbullet
```
- A **component** provides the core logic for some functionality (like `notify` provides sending notifications).
- A **platform** makes the connection to a specific software or hardware platform (like `pushbullet` works with the service from pushbullet.com).
The basics of YAML syntax are block collections and mappings containing key-value pairs. Each item in a collection starts with a `-` while mappings have the format `key: value`. If you specify duplicate keys, the last value for a key is used.
Note that indentation is an important part of specifying relationships using YAML. Things that are indented are nested "inside" things that are one level higher. So in the above example, `platform: pushbullet` is a property of (nested inside) the `notify` component.
Getting the right indentation can be tricky if you're not using an editor with a fixed width font. Tabs are not allowed to be used for indentation. Convention is to use 2 spaces for each level of indentation.
You can use [YAMLLint](http://www.yamllint.com/) to check if your YAML-syntax is correct before loading it into Home Assistant which will save you some time.
*Please pay attention on not putting in private data, as it is a 3rd-party website not maintained by Home Assistant.*
Text following a **#** are comments and are ignored by the system.
The next example shows an [input_select](/components/input_select) component that uses a block collection for the options values.
The other properties (like name) are specified using mappings. Note that the second line just has `threat:` with no value on the same line. Here threat is the name of the input_select and the values for it are everything nested below it.
```yaml
input_select:
threat:
name: Threat level
# A collection is used for options
options:
- 0
- 1
- 2
- 3
initial: 0
```
The following example shows nesting a collection of mappings in a mapping. In Home Assistant, this would create two sensors that each use the MQTT platform but have different values for their `state_topic` (one of the properties used for MQTT sensors).
```yaml
sensor:
- platform: mqtt
state_topic: sensor/topic
- platform: mqtt
state_topic: sensor2/topic
```