Merge branch 'master' into next
Conflicts: source/_components/zwave.markdown
This commit is contained in:
Paulus Schoutsen
commit
3dc15ca6de
54 changed files with 610 additions and 469 deletions
|
|
@ -9,17 +9,50 @@ sharing: true
|
|||
footer: true
|
||||
logo: amazon-echo.png
|
||||
ha_category: Voice
|
||||
featured: false
|
||||
featured: true
|
||||
---
|
||||
|
||||
The Alexa component allows you to integrate Home Assistant into Alexa/Amazon Echo. This component will allow you to query information and call services within Home Assistant by using your voice. There are no supported sentences out of the box as of now, you will have to define them all yourself.
|
||||
There are two ways that you can use Amazon Echo and Home Assistant together.
|
||||
|
||||
No matter which method(s) you decide to use, please remember that Amazon Echo requires an active Internet connection to function. If your Internet is down or experiencing issues (or Amazon's infrastructure is having issues), neither of these methods will work.
|
||||
|
||||
### {% linkable_title I just want to turn devices on and off using Echo %}
|
||||
|
||||
If you just want to be able to turn anything with a switch (like lights, switches, media players, etc) on and off, check out Michael Auchter's [Haaska][haaska-github-link] which integrates the [Alexa Lighting API][alexa-lighting-api] into Home Assistant.
|
||||
|
||||
[haaska-github-link]: https://github.com/auchter/haaska
|
||||
[alexa-lighting-api]: https://developer.amazon.com/public/binaries/content/assets/html/alexa-lighting-api.html
|
||||
|
||||
Implementing Haaska means you can turn things on and off by simply saying
|
||||
|
||||
> Alexa, turn the living room lights on.
|
||||
|
||||
or
|
||||
|
||||
> Alexa, set the living room lights to twenty percent.
|
||||
|
||||
instead of
|
||||
|
||||
> Alexa, tell Home Assistant to turn the living room lights on.
|
||||
|
||||
or
|
||||
|
||||
> Alexa, tell Home Assistant to set the living room lights to twenty percent.
|
||||
|
||||
In addition, you would need to build custom intents for each device and on/off combination using the below method, whereas everything just works without any extra work by using Haaska.
|
||||
|
||||
Please note that you can use Haaska and the built-in Alexa component side-by-side without issue if you wish.
|
||||
|
||||
### {% linkable_title I want to build custom commands to use with Echo %}
|
||||
|
||||
The built-in Alexa component allows you to integrate Home Assistant into Alexa/Amazon Echo. This component will allow you to query information and call services within Home Assistant by using your voice. There are no supported sentences out of the box as of now, you will have to define them all yourself.
|
||||
|
||||
<div class='videoWrapper'>
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/1Ke3mtWd_cQ" frameborder="0" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
### {% linkable_title Requirements before using %}
|
||||
Amazon requires the endpoint of a skill to be hosted via SSL. Self-signed certificates are ok because our skills will only run in development mode. Read more on [our blog][blog-lets-encrypt] about how to set up encryption for Home Assistant. If you are unable to get https up and running, consider using [this AWS Lambda proxy for Alexa skills](https://forums.developer.amazon.com/forums/thread.jspa?messageID=18604).
|
||||
#### {% linkable_title Requirements before using %}
|
||||
Amazon requires the endpoint of a skill to be hosted via SSL. Self-signed certificates are ok because our skills will only run in development mode. Read more on [our blog][blog-lets-encrypt] about how to set up encryption for Home Assistant. If you are unable to get HTTPS up and running, consider using [this AWS Lambda proxy for Alexa skills](https://forums.developer.amazon.com/forums/thread.jspa?messageID=18604).
|
||||
|
||||
[blog-lets-encrypt]: https://home-assistant.io/blog/2015/12/13/setup-encryption-using-lets-encrypt/
|
||||
|
||||
|
|
@ -35,7 +68,7 @@ To get started with Alexa skills:
|
|||
- https
|
||||
- https://YOUR_HOST/api/alexa?api_password=YOUR_API_PASSWORD
|
||||
|
||||
### {% linkable_title Configuring your Amazon Alexa skill %}
|
||||
#### {% linkable_title Configuring your Amazon Alexa skill %}
|
||||
|
||||
Alexa works based on intents. Each intent has a name and variable slots. For example, a `LocateIntent` with a slot that contains a `User`. Example intent schema:
|
||||
|
||||
|
|
|
|||
|
|
@ -15,6 +15,10 @@ This page will go into more detail about the various options the `automation` co
|
|||
|
||||
A configuration section of an automation requires a `trigger` and an `action` section. `condition` and `condition_type` are optional. To keep this page compact, all following sections will not show the full configuration but only the relevant part.
|
||||
|
||||
- [Jump to conditions](#conditions)
|
||||
- [Jump to actions](#actions)
|
||||
- [Jump to troubleshooting](#troubleshooting)
|
||||
|
||||
```yaml
|
||||
# Example of entry in configuration.yaml
|
||||
automation:
|
||||
|
|
@ -69,10 +73,6 @@ automation:
|
|||
message: 'Paulus left the house'
|
||||
```
|
||||
|
||||
- [Jump to conditions](#conditions)
|
||||
- [Jump to actions](#actions)
|
||||
- [Jump to troubleshooting](#troubleshooting)
|
||||
|
||||
## {% linkable_title Triggers %}
|
||||
|
||||
Triggers are what starts the processing of an automation rule. It is possible to specify multiple triggers for the same rule. Once a trigger starts, Home Assistant will validate the conditions, if any, and call the action.
|
||||
|
|
@ -207,9 +207,9 @@ automation:
|
|||
|
||||
## {% linkable_title Conditions %}
|
||||
|
||||
Conditions are an optional part of an automation rule and be used to prevent an action from happening when triggered. Conditions look very familiar to triggers but are very different. A trigger will look at events happening at the system while a condition only looks at how the system looks right now. A trigger can observe that a switch is being turned on. A condition can only see if a switch is on or off.
|
||||
Conditions are an optional part of an automation rule and be used to prevent an action from happening when triggered. Conditions look very similar to triggers but are very different. A trigger will look at events happening in the system while a condition only looks at how the system looks right now. A trigger can observe that a switch is being turned on. A condition can only see if a switch is currently on or off.
|
||||
|
||||
An automation rule can have mulitiple conditions. By default the action will only fire if all conditions pass. An optional key `condition_type: 'or'` can be set on the automation rule to fire action if any condition matches. In the example below, the automation would trigger if the time is before 05:00 _OR_ after 20:00.
|
||||
An automation rule can have multiple conditions. By default the action will only fire if all conditions pass. An optional key `condition_type: 'or'` can be set on the automation rule to fire action if any condition matches. In the example below, the automation would trigger if the time is before 05:00 _OR_ after 20:00.
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -230,18 +230,17 @@ automation:
|
|||
|
||||
#### {% linkable_title Numeric state condition %}
|
||||
|
||||
Attempts to parse the state of specified entity as a number and triggers if value is above and/or below a threshold.
|
||||
This type of condition attempts to parse the state of specified entity as a number and triggers if the value matches all of the above or below thresholds.
|
||||
Either `above` or `below`, or both need to be specified. If both are used, the condition is true when the value is >= `before` *and** < `after`.
|
||||
You can optionally use a `value_template` to make the value of the entity the same type of value as the condition.
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
condition:
|
||||
platform: numeric_state
|
||||
entity_id: sensor.temperature
|
||||
# At least one of the following required
|
||||
above: 17
|
||||
below: 25
|
||||
# Optional
|
||||
value_template: '{% raw %}{{ state.attributes.battery }}{% endraw %}'
|
||||
```
|
||||
|
||||
#### {% linkable_title State condition %}
|
||||
|
|
@ -259,7 +258,6 @@ automation:
|
|||
hours: 1
|
||||
minutes: 10
|
||||
seconds: 5
|
||||
|
||||
```
|
||||
|
||||
#### {% linkable_title Sun condition %}
|
||||
|
|
@ -277,7 +275,7 @@ automation:
|
|||
|
||||
#### {% linkable_title Template condition %}
|
||||
|
||||
The template condition will test if [given template][template] renders a value equal to true. This is achieved by having the template result in a true boolean expression or by having the template render 'true'.
|
||||
The template condition will test if the [given template][template] renders a value equal to true. This is achieved by having the template result in a true boolean expression or by having the template render 'true'.
|
||||
|
||||
|
||||
```yaml
|
||||
|
|
@ -322,7 +320,7 @@ automation:
|
|||
|
||||
## {% linkable_title Actions %}
|
||||
|
||||
When an automation rule fires, it calls a service. For this service you can specify an entity id it should apply to and optional service parameters (to specify for example the brightness).
|
||||
When an automation rule fires, it calls a service. For this service you can specify the entity_id that it should apply to and optional service parameters (to specify for example the brightness).
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -346,11 +344,11 @@ automation:
|
|||
message: Something just happened, better take a look!
|
||||
```
|
||||
|
||||
If you want to specify multiple services to be called or include a delay, have a look at the [script component](/components/script/). If you want to describe how certain entities should look, check out the [scene component](/components/scene/).
|
||||
If you want to specify multiple services to be called, or to include a delay, have a look at the [script component](/components/script/). If you want to describe the desired state of certain entities, check out the [scene component](/components/scene/).
|
||||
|
||||
## {% linkable_title Troubleshooting %}
|
||||
|
||||
You can verify that your automation rules are being initialized correctly by watching both the realtime logs and also the logbook. The realtime logs will show the rules being initialized (once for each trigger):
|
||||
You can verify that your automation rules are being initialized correctly by watching both the realtime logs (`homeassistant.log` in the configuration directory) and also the [Logbook](/components/logbook/). The realtime logs will show the rules being initialized (once for each trigger), example:
|
||||
|
||||
```plain
|
||||
INFO [homeassistant.components.automation] Initialized rule Rainy Day
|
||||
|
|
@ -359,7 +357,7 @@ INFO [homeassistant.components.automation] Initialized rule Rainy Day
|
|||
INFO [homeassistant.components.automation] Initialized rule Rain is over
|
||||
```
|
||||
|
||||
The Logbook component will show a line entry when an automation is triggered. You can look at the previous entry to determine which trigger in the rule triggered the event.
|
||||
The Logbook component will show a line entry when an automation is triggered. You can look at the previous entry to determine which trigger in the rule triggered the event.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ binary_sensor:
|
|||
resource: http://IP_ADDRESS/ENDPOINT
|
||||
method: GET
|
||||
name: REST GET binary sensor
|
||||
sensor_class: opening
|
||||
value_template: '{% raw %}{{ value_json.state }}{% endraw %}'
|
||||
```
|
||||
|
||||
|
|
@ -33,18 +34,20 @@ binary_sensor:
|
|||
platform: rest
|
||||
resource: http://IP_ADDRESS/ENDPOINT
|
||||
method: POST
|
||||
name: REST POST binary sensor
|
||||
sensor_class: opening
|
||||
value_template: '{% raw %}{{ value_json.state }}{% endraw %}'
|
||||
payload: '{ "device" : "door" }'
|
||||
name: REST POST binary sensor
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **resource** (*Required*): The resource or endpoint that contains the value.
|
||||
- **method** (*Optional*): The method of the request. Default is GET.
|
||||
- **name** (*Optional*): Name of the REST binary sensor.
|
||||
- **sensor_class** (*Optional*): The [type/class](/components/binary_sensor/) of the sensor to set the icon in the frontend.
|
||||
- **value_template** (*Optional*): Defines a [template](/topics/templating/) to extract the value.
|
||||
- **payload** (*Optional*): The payload to send with a POST request. Usualy formed as a dictionary.
|
||||
- **name** (*Optional*): Name of the REST binary sensor.
|
||||
|
||||
<p class='note warning'>
|
||||
Make sure that the URL matches exactly your endpoint or resource.
|
||||
|
|
|
|||
|
|
@ -10,23 +10,22 @@ footer: true
|
|||
ha_category: Binary Sensor
|
||||
---
|
||||
|
||||
|
||||
The TCP Binary Sensor is a type of [TCP Sensor](/components/sensor.tcp/) which is either "off" or "on". In order to use this sensor type, in addition to the configuration for the TCP Sensor, you must supply a `value_on` value to represent what is returned when the device is turned on.
|
||||
|
||||
To enable this sensor, add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
sensor:
|
||||
binary_sensor:
|
||||
# Example configuration.yaml entry
|
||||
- platform: tcp
|
||||
name: TCP Binary Sensor
|
||||
host: IP_ADDRESS
|
||||
port: PORT
|
||||
payload: "r State\n"
|
||||
value_on: 1
|
||||
timeout: 5
|
||||
value_template: "{% raw %}{{ value.split(';')[0] }}{% endraw %}"
|
||||
unit: UNIT_OF_MEASUREMENT
|
||||
platform: tcp
|
||||
name: TCP Binary Sensor
|
||||
host: IP_ADDRESS
|
||||
port: PORT
|
||||
payload: "r State\n"
|
||||
value_on: 1
|
||||
timeout: 5
|
||||
value_template: "{% raw %}{{ value.split(';')[0] }}{% endraw %}"
|
||||
buffer_size: BUFFER_SIZE
|
||||
```
|
||||
|
||||
Configuration options for the a TCP Sensor:
|
||||
|
|
@ -38,6 +37,5 @@ Configuration options for the a TCP Sensor:
|
|||
- **value_on** (*Required*): The value returned when the device is "on".
|
||||
- **timeout** (*Optional*): How long in seconds to wait for a response from the service before giving up and disconnecting. Defaults to 10.
|
||||
- **value_template** (*Optional*): Defines a [template](/topics/templating/) to extract the value. By default it's assumed that the entire response is the value.
|
||||
- **unit** (*Optional*): The unit of measurement to use for the value.
|
||||
- **buffer_size** (*Optional*): The size of the receive buffer in bytes. Set this to a larger value if you expect to receive a response larger than the default. Defaults to 1024.
|
||||
|
||||
|
|
|
|||
17
source/_components/binary_sensor.vera.markdown
Normal file
17
source/_components/binary_sensor.vera.markdown
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Vera Binary Sensor"
|
||||
description: "Instructions how to integrate Vera binary sensors into Home Assistant."
|
||||
date: 2016-03-26 23:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: vera.png
|
||||
ha_category: Binary Sensor
|
||||
ha_iot_class: "Local Push"
|
||||
---
|
||||
|
||||
The `vera` platform allows you to get data from your [Vera](http://getvera.com/) binary sensors from within Home Assistant.
|
||||
|
||||
They will be automatically discovered if the vera component is loaded.
|
||||
|
|
@ -31,3 +31,7 @@ Configuration variables:
|
|||
- **name** *Optional*: This parameter allows you to override the name of your camera.
|
||||
- **username** *Optional*: The username for accessing your camera.
|
||||
- **password** *Optional*: The password for accessing your camera.
|
||||
|
||||
<p class='note'>
|
||||
There is a <a href="https://github.com/shazow/urllib3/issues/800" target="_blank">known issue in urllib3</a> that you will get error messages in your logs like <code>[StartBoundaryNotFoundDefect(), MultipartInvariantViolationDefect()], unparsed data: ''</code> but the component still works fine. You can ignore the messages.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -12,7 +12,8 @@ ha_category: "Voice"
|
|||
---
|
||||
|
||||
|
||||
The conversation component can process sentences into commands for Home Assistant. It is currently limited to parsing commands in the format `turn <Friendly Name> <on/off>`.
|
||||
The conversation component can process sentences into commands for Home Assistant. It is currently limited to parsing commands in the format `turn <Friendly Name> <on/off>`.
|
||||
|
||||
|
||||
To enable the conversion option in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
@ -26,3 +27,7 @@ When this component is active and you are using a supported browser voice comman
|
|||
<p class='img'>
|
||||
<img src="/images/screenshots/voice-commands.png" />
|
||||
</p>
|
||||
|
||||
<p class='note'>
|
||||
Apple iPhones do not support this feature in any browser.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ sharing: true
|
|||
footer: true
|
||||
logo: ecobee.png
|
||||
ha_category: Hub
|
||||
featured: true
|
||||
---
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -33,8 +33,8 @@ Configuration variables:
|
|||
|
||||
On top of the `http` component is a [REST API](/developers/rest_api/) and a [Python API](/developers/python_api/) available.
|
||||
|
||||
The `http` platforms are not a real platform within the meaning of the terminology used around Home Assistant. Home Assistant's [REST API](/developers/rest_api/) is consuming and proceeding messages received over HTTP.
|
||||
The `http` platforms are not real platforms within the meaning of the terminology used around Home Assistant. Home Assistant's [REST API](/developers/rest_api/) sends and receives messages over HTTP.
|
||||
|
||||
To use those kind of sensors in your installation no configuration in Home Assistant is needed. All configuration is done on the devices themselves. This means that you must be able to edit the target URL or endpoint and the payload. The entity will be created after the first message has arrived.
|
||||
|
||||
All [requests](/developers/rest_api/#post-apistatesltentity_id) needs to be sent to the endpoint of the device and must be **POST**.
|
||||
All [requests](/developers/rest_api/#post-apistatesltentity_id) need to be sent to the endpoint of the device and must be **POST**.
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ sharing: true
|
|||
footer: true
|
||||
logo: influxdb.png
|
||||
ha_category: "History"
|
||||
featured: true
|
||||
---
|
||||
|
||||
The `influxdb` component makes it possible to transfer all state changes to an external [InfluxDB](https://influxdb.com/) database. For more details, [see the blog post on InfluxDB](/blog/2015/12/07/influxdb-and-grafana/).
|
||||
|
|
@ -25,6 +26,9 @@ influxdb:
|
|||
password: MY_PASSWORD
|
||||
ssl: true
|
||||
verify_ssl: true
|
||||
blacklist:
|
||||
- entity.id1
|
||||
- entity.id2
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
|
@ -36,3 +40,4 @@ Configuration variables:
|
|||
- **password** (*Optional*): The password for the database user account.
|
||||
- **ssl** (*Optional*): Use https instead of http to connect. Defaults to false.
|
||||
- **verify_ssl** (*Optional*): Verify SSL certificate for https request. Defaults to false.
|
||||
- **blacklist** (*Optional*): List of entities not logged to influxdb.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ The `input_boolean` component allows the user to define boolean values that can
|
|||
# Example configuration.yaml entry
|
||||
input_boolean:
|
||||
notify_home:
|
||||
name: Notify when someome arrives home
|
||||
name: Notify when someone arrives home
|
||||
initial: off
|
||||
icon: mdi:car
|
||||
```
|
||||
|
|
@ -31,3 +31,22 @@ Configuration variables:
|
|||
|
||||
Pick an icon that you can find on [materialdesignicons.com](https://materialdesignicons.com/) to use for your input and prefix the name with `mdi:`. For example `mdi:car`, `mdi:ambulance`, or `mdi:motorbike`.
|
||||
|
||||
Here's an example of an automation using the above input_boolean. This action will only occur if the switch is on.
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
alias: Arriving home
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: binary_sensor.motion_garage
|
||||
to: 'on'
|
||||
condition:
|
||||
platform: state
|
||||
entity_id: input_boolean.notify_home
|
||||
state: 'on'
|
||||
action:
|
||||
service: notify.pushbullet
|
||||
data:
|
||||
title: ""
|
||||
message: "Honey, I'm home!"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ light:
|
|||
|
||||
Configuration variables:
|
||||
|
||||
- **host** (*Required*): IP address aof the device, eg. 192.168.1.10.
|
||||
- **host** (*Required*): IP address of the device, eg. 192.168.1.10.
|
||||
- **allow_unreachable** (*Optional*): This will allow unreachable bulbs to report their state correctly. By default *name* from the device is used.
|
||||
- **filename** (*Optional*): Make this unique if specifying multiple Hue hubs.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ light:
|
|||
living_room:
|
||||
name: Living Room
|
||||
packetid: XXXXX
|
||||
fire_event: True
|
||||
automatic_add: True
|
||||
```
|
||||
|
||||
|
|
@ -31,3 +32,4 @@ Configuration variables:
|
|||
- **devices** (*Required*): A list of devices with their name to use in the frontend.
|
||||
- **automatic_add** (*Optional*): To enable the automatic addition of new lights.
|
||||
- **signal_repetitions** *Optional*: Because the rxftrx device sends its actions via radio and from most receivers it's impossible to know if the signal was received or not. Therefore you can configure the switch to try to send each signal repeatedly.
|
||||
- **fire_event** *Optional*: Fires an event even if the state is the same as before. Can be used for automations.
|
||||
|
|
|
|||
|
|
@ -9,31 +9,12 @@ sharing: true
|
|||
footer: true
|
||||
logo: vera.png
|
||||
ha_category: Light
|
||||
ha_iot_class: "Local Push"
|
||||
---
|
||||
|
||||
The `vera` platform allows you to control your [Vera](http://getvera.com/) lights from within Home Assistant.
|
||||
|
||||
This `vera` light platform allows you to control your [Vera](http://getvera.com/) lights.
|
||||
They will be automatically discovered if the vera component is loaded.
|
||||
|
||||
This platform is useful if you wish for switches connected to your Vera controller to appear as lights in Home Assistant. All switches will be added as a light unless you exclude them in the configuration file.
|
||||
For more configuration information see the [Vera component](/components/vera/) documentation.
|
||||
|
||||
To use your Vera lights in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
light:
|
||||
platform: vera
|
||||
vera_controller_url: http://YOUR_VERA_IP:3480/
|
||||
device_data:
|
||||
12:
|
||||
name: My awesome sensor
|
||||
exclude: true
|
||||
13:
|
||||
name: Another sensor
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **vera_controller_url** (*Required*): This is the base URL of your vera controller including the port number if not running on 80, eg. http://192.168.1.21:3480/
|
||||
- **device_data** array (*Optional*):This contains an array additional device information for your Vera devices. It is not required and if not specified all sensors configured in your Vera controller will be added with default values. You should use the id of your Vera device as the key for the device within `device_data`.
|
||||
- **name** (*Optional*):This parameter allows you to override the name of your Vera device in the frontend, if not specified the value configured for the device in your Vera will be used.
|
||||
- **exclude** (*Optional*): This parameter allows you to exclude the specified device, it should be set to "True" if you want this device excluded.
|
||||
|
|
|
|||
|
|
@ -11,11 +11,11 @@ logo: home-assistant.png
|
|||
ha_category: "Other"
|
||||
---
|
||||
|
||||
The logger component lets one define the level of logging activities in Home Assistant.
|
||||
The logger component lets you define the level of logging activities in Home Assistant.
|
||||
|
||||
To enable the logger in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
By default log all messages and ignore log event lowest than critical for custom omponents.
|
||||
By default log all messages and ignore events lower than critical for specified components.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
@ -26,7 +26,7 @@ logger:
|
|||
homeassistant.components.camera: critical
|
||||
```
|
||||
|
||||
By default ignore all messages lowest than critical and log event for custom components.
|
||||
By default ignore all messages lower than critical and log event for specified components.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
@ -41,7 +41,7 @@ logger:
|
|||
|
||||
Possible log severities are:
|
||||
|
||||
- citical
|
||||
- critical
|
||||
- fatal
|
||||
- error
|
||||
- warning
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Sonos"
|
||||
description: "Instructions how to integrateSonos devices into Home Assistant."
|
||||
description: "Instructions how to integrate Sonos devices into Home Assistant."
|
||||
date: 2015-09-12 13:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -23,3 +23,12 @@ media_player:
|
|||
platform: sonos
|
||||
```
|
||||
|
||||
You can also specify hosts to connect to if they cannot be found with auto-discovery.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
media_player:
|
||||
platform: sonos
|
||||
hosts: IP
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -46,18 +46,22 @@ The MQTT component needs you to run an MQTT broker for Home Assistant to connect
|
|||
|
||||
#### {% linkable_title Use the embedded broker %}
|
||||
|
||||
Home Assistant contains an embedded MQTT broker. If no broker configuration is given, the [HBMQTT broker](https://pypi.python.org/pypi/hbmqtt) is started and Home Asssistant connects to it. Default settings for the embedded broker:
|
||||
Home Assistant contains an embedded MQTT broker. If no broker configuration is given, the [HBMQTT broker](https://pypi.python.org/pypi/hbmqtt) is started and Home Asssistant connects to it. Embedded broker default configuration:
|
||||
|
||||
| Setting | Value |
|
||||
| ------- | ----- |
|
||||
| Host | localhost
|
||||
| Port | 1883
|
||||
| Version | 3.1
|
||||
| Protocol | 3.1.1
|
||||
| User | homeassistant
|
||||
| Password | Your API password
|
||||
| Websocket port | 8080
|
||||
|
||||
If you want to customize the settings of the embedded broker, use `embedded:` and the values shown in the [HBMQTT Broker configuration](http://hbmqtt.readthedocs.org/en/latest/references/broker.html#broker-configuration).
|
||||
<p class='note'>
|
||||
This broker does not currently work with OwnTracks because of a protocol version issue.
|
||||
</p>
|
||||
|
||||
If you want to customize the settings of the embedded broker, use `embedded:` and the values shown in the [HBMQTT Broker configuration](http://hbmqtt.readthedocs.org/en/latest/references/broker.html#broker-configuration). This will replace the default configuration.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Some examples of its use include:
|
|||
The Proximity entity which is created has the following values:
|
||||
|
||||
- `state`: Distance from the monitored zone (in km)
|
||||
- `dir_of_travel`: Direction of the closest device to the monitoed zone. Values are:
|
||||
- `dir_of_travel`: Direction of the closest device to the monitored zone. Values are:
|
||||
- 'not set'
|
||||
- 'arrived'
|
||||
- 'towards'
|
||||
|
|
|
|||
|
|
@ -11,9 +11,7 @@ logo: home-assistant.png
|
|||
ha_category: Organization
|
||||
---
|
||||
|
||||
A user can create scenes that capture the states you want certain entities to be. For example a scene can contain that light A should be turned on and light B should be bright red.
|
||||
|
||||
Scenes can be activated using the service `scene.turn_on`.
|
||||
You can create scenes that capture the states you want certain entities to be. For example a scene can specify that light A should be turned on and light B should be bright red.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
@ -33,3 +31,19 @@ scene:
|
|||
brightness: 100
|
||||
light.ceiling: off
|
||||
```
|
||||
|
||||
Scenes can be activated using the service `scene.turn_on` (there is no 'scene.turn_off' service).
|
||||
|
||||
```yaml
|
||||
# Example automation
|
||||
...
|
||||
automation:
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: device_tracker.sweetheart
|
||||
from: 'not_home'
|
||||
to: 'home'
|
||||
action:
|
||||
service: scene.turn_on
|
||||
entity_id: scene.romantic
|
||||
```
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ In this section you find some real life examples of how to use this sensor.
|
|||
|
||||
### {% linkable_title Get battery level %}
|
||||
|
||||
If you are using the [Owntracks](components/device_tracker.owntracks/) and enable the reporting of the battery level then you can use a MQTT sensor to keep track of your battery. A regular MQTT message from Owntracks looks like this:
|
||||
If you are using the [Owntracks](/components/device_tracker.owntracks/) and enable the reporting of the battery level then you can use a MQTT sensor to keep track of your battery. A regular MQTT message from Owntracks looks like this:
|
||||
|
||||
```bash
|
||||
owntracks/tablet/tablet {"_type":"location","lon":7.21,"t":"u","batt":92,"tst":144995643,"tid":"ta","acc":27,"lat":46.12}
|
||||
|
|
@ -56,6 +56,6 @@ sensor:
|
|||
state_topic: "owntracks/tablet/tablet"
|
||||
name: "Battery Tablet"
|
||||
unit_of_measurement: "%"
|
||||
value_template: '{{ value_json.batt }}'
|
||||
value_template: {% raw %}'{{ value_json.batt }}'{% endraw %}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Configuration variables:
|
|||
- **resource** (*Required*): The resource or endpoint that contains the value.
|
||||
- **method** (*Optional*): The method of the request. Default is GET.
|
||||
- **value_template** (*Optional*): Defines a [template](/topics/templating/) to extract the value.
|
||||
- **payload** (*Optional*): The payload to send with a POST request. Usualy formed as a dictionary.
|
||||
- **payload** (*Optional*): The payload to send with a POST request. Depends on the service, but usually formed as JSON.
|
||||
- **name** (*Optional*): Name of the REST sensor.
|
||||
- **unit_of_measurement** (*Optional*): Defines the unit of measurement of the sensor, if any.
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ In this section you find some real life examples of how to use this sensor.
|
|||
|
||||
### {% linkable_title External IP address %}
|
||||
|
||||
Always want to know your external IP address. [JSON Test](http://www.jsontest.com) will provide you this information at their http://ip.jsontest.com/ endpoint.
|
||||
You can find your external IP address using the service [JSON Test](http://www.jsontest.com) at their http://ip.jsontest.com/ endpoint.
|
||||
|
||||
To display the IP address, the entry for a sensor in the `configuration.yaml` file will look like this.
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ Add something similar to the entry below to your `configuration.yaml` file:
|
|||
|
||||
### {% linkable_title Value for other Home Assistant instance %}
|
||||
|
||||
The Home Assistant [API](/developers/rest_api/) is exposing the data from your attached sensors. If you are running multiple Home Assistant instances which are not [connected](/developers/architecture/#multiple-connected-instances) you can still get information from them.
|
||||
The Home Assistant [API](/developers/rest_api/) exposes the data from your attached sensors. If you are running multiple Home Assistant instances which are not [connected](/developers/architecture/#multiple-connected-instances) you can still get information from them.
|
||||
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -17,14 +17,14 @@ To enable this sensor, add the following lines to your `configuration.yaml`:
|
|||
```yaml
|
||||
sensor:
|
||||
# Example configuration.yaml entry
|
||||
- platform: tcp
|
||||
name: Central Heating Pressure
|
||||
host: IP_ADDRESS
|
||||
port: PORT
|
||||
timeout: 5
|
||||
payload: PAYLOAD
|
||||
value_template: "{% raw %}{{ value.split(';')[0] }}{% endraw %}"
|
||||
unit: UNIT_OF_MEASUREMENT
|
||||
platform: tcp
|
||||
name: Central Heating Pressure
|
||||
host: IP_ADDRESS
|
||||
port: PORT
|
||||
timeout: 5
|
||||
payload: PAYLOAD
|
||||
value_template: "{% raw %}{{ value.split(';')[0] }}{% endraw %}"
|
||||
unit: UNIT_OF_MEASUREMENT
|
||||
```
|
||||
|
||||
Configuration options for the a TCP Sensor:
|
||||
|
|
@ -56,19 +56,19 @@ You will notice that the output from the service is not just a single value (it
|
|||
```yaml
|
||||
sensor:
|
||||
# Example configuration.yaml entry
|
||||
- platform: tcp
|
||||
name: Central Heating Pressure
|
||||
host: 10.0.0.127
|
||||
port: 8888
|
||||
timeout: 5
|
||||
payload: "r WaterPressure\n"
|
||||
value_template: "{% raw %}{{ value.split(';')[0] }}{% endraw %}"
|
||||
unit: Bar
|
||||
platform: tcp
|
||||
name: Central Heating Pressure
|
||||
host: 10.0.0.127
|
||||
port: 8888
|
||||
timeout: 5
|
||||
payload: "r WaterPressure\n"
|
||||
value_template: "{% raw %}{{ value.split(';')[0] }}{% endraw %}"
|
||||
unit: Bar
|
||||
```
|
||||
|
||||
### {% linkable_title hddtemp %}
|
||||
|
||||
The tool `hddtemp` collects the temperatur of your harddisks.
|
||||
The tool `hddtemp` collects the temperature of your harddisks.
|
||||
|
||||
```bash
|
||||
$ hddtemp
|
||||
|
|
@ -90,12 +90,12 @@ The entry for the `configuration.yaml` file for a `hddtemp` sensor could look li
|
|||
```yaml
|
||||
sensor:
|
||||
# Example configuration.yaml entry
|
||||
- platform: tcp
|
||||
name: HDD temperature
|
||||
host: 127.0.0.1
|
||||
port: 7634
|
||||
timeout: 5
|
||||
payload: "\n"
|
||||
value_template: "{% raw %}{{ value.split('|')[3] }}{% endraw %}"
|
||||
unit: "°C"
|
||||
platform: tcp
|
||||
name: HDD temperature
|
||||
host: 127.0.0.1
|
||||
port: 7634
|
||||
timeout: 5
|
||||
payload: "\n"
|
||||
value_template: "{% raw %}{{ value.split('|')[3] }}{% endraw %}"
|
||||
unit: "°C"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -9,29 +9,10 @@ sharing: true
|
|||
footer: true
|
||||
logo: vera.png
|
||||
ha_category: Sensor
|
||||
ha_iot_class: "Local Push"
|
||||
---
|
||||
|
||||
The `vera` platform allows you to get data from your [Vera](http://getvera.com/) sensors from within Home Assistant.
|
||||
|
||||
They will be automatically discovered if the vera component is loaded.
|
||||
|
||||
This `vera` sensor platform allows you to get data from your [Vera](http://getvera.com/) sensors.
|
||||
|
||||
To use your Vera sensor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
platform: vera
|
||||
vera_controller_url: http://YOUR_VERA_IP:3480/
|
||||
device_data:
|
||||
12:
|
||||
name: My awesome sensor
|
||||
exclude: true
|
||||
13:
|
||||
name: Another sensor
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **vera_controller_url** (*Required*): This is the base URL of your vera controller including the port number if not running on 80, eg. http://192.168.1.21:3480/
|
||||
- **device_data** array (*Optional*):This contains an array additional device information for your Vera devices. It is not required and if not specified all sensors configured in your Vera controller will be added with default values. You should use the id of your Vera device as the key for the device within `device_data`.
|
||||
- **name** (*Optional*):This parameter allows you to override the name of your Vera device in the frontend, if not specified the value configured for the device in your Vera will be used.
|
||||
- **exclude** (*Optional*): This parameter allows you to exclude the specified device, it should be set to "True" if you want this device excluded.
|
||||
|
|
|
|||
|
|
@ -22,12 +22,12 @@ homeassistant:
|
|||
longitude: -117.22743
|
||||
|
||||
sun:
|
||||
elevation: 123
|
||||
elevation: 102
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **elevation** (*Optional*): The solar elevation angle is the altitude of the sun. If ommitted will be retrieved from Google Maps.
|
||||
- **elevation** (*Optional*): The (physical) elevation of your location, in metres above sea level. If ommitted will be retrieved from Google Maps.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/screenshots/more-info-dialog-sun.png' />
|
||||
|
|
@ -59,5 +59,6 @@ The sun event need to have the type 'sun', which service to call, which event (s
|
|||
|
||||
| State Attributes | Description |
|
||||
| --------- | ----------- |
|
||||
| `next_rising` | Date and time of the next sun rising
|
||||
| `next_setting` | Date and time of the next sun setting
|
||||
| `next_rising` | Date and time of the next sun rising (in UTC).
|
||||
| `next_setting` | Date and time of the next sun setting (in UTC).
|
||||
| `elevation` | Solar elevation. This is the angle between the sun and the horizon. Negative values mean the sun is below the horizon.
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ switch:
|
|||
|
||||
### {% linkable_title Control your VLC player %}
|
||||
|
||||
This switch will control a local VLC media player ([Source](https://automic.us/forum/viewtopic.php?f=4&t=144)).
|
||||
This switch will control a local VLC media player ([Source](https://community.home-assistant.io/t/vlc-player/106)).
|
||||
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ switch:
|
|||
living_room:
|
||||
name: Living Room
|
||||
packetid: XXXXX
|
||||
fire_event: True
|
||||
automatic_add: True
|
||||
```
|
||||
|
||||
|
|
@ -31,3 +32,4 @@ Configuration variables:
|
|||
- **devices** (*Required*): A list of devices with their name to use in the frontend.
|
||||
- **automatic_add** (*Optional*): To enable the automatic addition of new switches.
|
||||
- **signal_repetitions** *Optional*: Because the rxftrx device sends its actions via radio and from most receivers it's impossible to know if the signal was received or not. Therefore you can configure the switch to try to send each signal repeatedly.
|
||||
- **fire_event** *Optional*: Fires an event even if the state is the same as before. Can be used for automations.
|
||||
|
|
|
|||
|
|
@ -9,29 +9,11 @@ sharing: true
|
|||
footer: true
|
||||
logo: vera.png
|
||||
ha_category: Switch
|
||||
ha_iot_class: "Local Push"
|
||||
---
|
||||
|
||||
The `vera` platform allows you to control your [Vera](http://getvera.com/) switches from within Home Assistant.
|
||||
|
||||
This `vera` switch platform allows you to control your [Vera](http://getvera.com/) switches.
|
||||
They will be automatically discovered if the vera component is loaded.
|
||||
|
||||
To use your Vera switches in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
switch:
|
||||
platform: vera
|
||||
vera_controller_url: http://YOUR_VERA_IP:3480/
|
||||
device_data:
|
||||
12:
|
||||
name: My awesome sensor
|
||||
exclude: true
|
||||
13:
|
||||
name: Another sensor
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **vera_controller_url** (*Required*): This is the base URL of your vera controller including the port number if not running on 80, eg. http://192.168.1.21:3480/
|
||||
- **device_data** array (*Optional*):This contains an array additional device information for your Vera devices. It is not required and if not specified all sensors configured in your Vera controller will be added with default values. You should use the id of your Vera device as the key for the device within `device_data`.
|
||||
- **name** (*Optional*):This parameter allows you to override the name of your Vera device in the frontend, if not specified the value configured for the device in your Vera will be used.
|
||||
- **exclude** (*Optional*): This parameter allows you to exclude the specified device, it should be set to "True" if you want this device excluded.
|
||||
For more configuration information see the [Vera component](/components/vera/) documentation.
|
||||
|
|
|
|||
|
|
@ -11,8 +11,22 @@ logo: vera.png
|
|||
ha_category: Hub
|
||||
---
|
||||
|
||||
The [Vera](http://getvera.com) hub is a controller ainly connecting to Z-Wave devices.
|
||||
|
||||
The [Vera](http://getvera.com) ecosystem is using Z-Wave for communication between the Vera controller and the devices.
|
||||
Switches, Lights (inc Dimmers), Sensors and Binary sensors are supported - and will be automaticaly added when HA connects to your Vera controller.
|
||||
|
||||
To use Vera devices in your installation, add the following to your configuration.yaml file using the IP and port number of your Vera controller:
|
||||
|
||||
```yaml
|
||||
vera:
|
||||
vera_controller_url: http://192.168.1.161:3480/
|
||||
```
|
||||
|
||||
By default your switches will be added to HA as switches, however if some of them are light switches, you can tell HA this using the optional ```lights``` parameter as shown below.
|
||||
|
||||
Vera imports detailed zwave devices into HA - this can include system devices and other devices that you don't use, you can tell HA not to load these devices using the ```exclude:``` parameter as shown below.
|
||||
|
||||
You can find the vera device id either by looking at your vera controller - or by checking the ```Vera Device Id``` attribute on each device imported into HA.
|
||||
|
||||
```yaml
|
||||
vera:
|
||||
|
|
@ -22,3 +36,4 @@ vera:
|
|||
# Optional to import switches as lights - this is a list of vera device ids
|
||||
lights: [15, 17, 19, 21, 22, 24, 26, 43, 64, 70, 87]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ logo:
|
|||
ha_category: Other
|
||||
---
|
||||
|
||||
The `weblinks` component allows you to display links in the Home Assistant frontend.
|
||||
The `weblink` component allows you to display links in the Home Assistant frontend.
|
||||
|
||||
To use this component in your installation, add the following to your `configuration.yaml` file:
|
||||
To use this component in your installation, add something like the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ sharing: true
|
|||
footer: true
|
||||
logo: belkin_wemo.png
|
||||
ha_category: Hub
|
||||
featured: true
|
||||
---
|
||||
|
||||
The `wemo` component is the main component to integrate various [Belkin WeMo](http://www.belkin.com/us/Products/home-automation/c/wemo-home-automation/) devices with Home Assistant.
|
||||
|
|
|
|||
|
|
@ -51,6 +51,10 @@ Configuration variables:
|
|||
|
||||
If no configuration is given, the `zone` component will create a zone for home. This zone will use location given in the `configuration.yaml` file and have a radius of 100 meters. To override this, create a zone configuration and name it **'Home'**.
|
||||
|
||||
<p class='note'>
|
||||
Devices that are in the zone **'Home'** will not appear on the map in the Home Assistant UI.
|
||||
</p>
|
||||
|
||||
#### {% linkable_title Icons %}
|
||||
|
||||
It is preferred to pick an icon to use for your zone. Pick any zone that you can find on [materialdesignicons.com](https://materialdesignicons.com/) and prefix the name with `mdi:`. For example `mdi:school`, `mdi:worker`, `mdi:home`, `mdi:cart`, or `mdi:castle`.
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ sharing: true
|
|||
footer: true
|
||||
logo: z-wave.png
|
||||
ha_category: Hub
|
||||
featured: true
|
||||
---
|
||||
|
||||
[Z-Wave](http://www.z-wave.com/) integration for Home Assistant allows you to observe and control connected Z-Wave devices. Z-Wave support requires a [supported Z-Wave USB stick](https://github.com/OpenZWave/open-zwave/wiki/Controller-Compatibility-List) to be plugged into the host.
|
||||
|
|
@ -25,7 +26,7 @@ Make sure you have the correct dependencies installed before running the script:
|
|||
$ sudo apt-get install cython3 libudev-dev python3-sphinx python3-setuptools
|
||||
```
|
||||
|
||||
Make sure you have at least version 0.23 of cython.
|
||||
Make sure you have at least version 0.23 of cython.
|
||||
|
||||
```bash
|
||||
$ sudo pip3 install --upgrade cython
|
||||
|
|
@ -61,7 +62,7 @@ With this installation, your `config_path` needed below will resemble:
|
|||
zwave:
|
||||
usb_path: /dev/ttyUSB0
|
||||
config_path: /usr/local/share/python-openzwave/config
|
||||
polling_interval: 10000
|
||||
polling_interval: 60000
|
||||
customize:
|
||||
sensor.greenwave_powernode_6_port_energy_10:
|
||||
polling_intensity: 1
|
||||
|
|
@ -71,7 +72,7 @@ Configuration variables:
|
|||
|
||||
- **usb_path** (*Required*): The port where your device is connected to your Home Assistant host.
|
||||
- **config_path** (*Optional*): The path to the Python Open Z-Wave configuration files.
|
||||
- **polling_interval** (*Optional*): The time period in milliseconds between polls of a nodes value.
|
||||
- **polling_interval** (*Optional*): The time period in milliseconds between polls of a nodes value. Be careful about using polling values below 30000 (30 seconds) as polling can flood the zwave network and cause problems.
|
||||
- **customize** (*Optional*): This attribute contains node-specific override values:
|
||||
- **polling_intensity** (*Optional*): Enables polling of a value and sets the frequency of polling (0=none, 1=every time through the list, 2-every other time, etc)
|
||||
|
||||
|
|
@ -102,7 +103,7 @@ automation:
|
|||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
event_data:
|
||||
entity_id: zwaveme_zme_wallcs_secure_wall_controller_8
|
||||
scene_id: 11
|
||||
```
|
||||
|
|
@ -111,12 +112,105 @@ The *entity_id* and *scene_id* of all triggered events can be seen in the consol
|
|||
|
||||
#### {% linkable_title Services %}
|
||||
|
||||
The Z-Wave component exposes two services to help maintain the network.
|
||||
The Z-Wave component exposes four services to help maintain the network.
|
||||
|
||||
| Service | Description |
|
||||
| ------- | ----------- |
|
||||
| add_node | |
|
||||
| remove_node | |
|
||||
| heal_network | |
|
||||
| soft_reset | |
|
||||
| add_node | Put the zwave controller in inclusion mode. Allows one to add a new device to the zwave network.|
|
||||
| remove_node | Put the zwave controller in exclusion mode. Allows one to remove a device from the zwave network.|
|
||||
| heal_network | Tells the controller to "heal" the network. Bascially asks the nodes to tell the controller all of their neighbors so the controller can refigure out optimal routing. |
|
||||
| soft_reset | Tells the controller to do a "soft reset". This is not supposed to lose any data, but different controllers can behave differently to a "soft reset" command.|
|
||||
| test_network | Tells the controller to send no-op commands to each node and measure the time for a response. In theory, this can also bring back nodes which have been marked "presumed dead".|
|
||||
|
||||
The soft_reset and heal_network commands can be used as part of an automation script
|
||||
to help keep a zwave network running relliably. For example:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml automation entry
|
||||
automation:
|
||||
- alias: soft reset at 2:30am
|
||||
trigger:
|
||||
platform: time
|
||||
after: '2:30:00'
|
||||
action:
|
||||
service: zwave.soft_reset
|
||||
|
||||
- alias: heal at 2:31am
|
||||
trigger:
|
||||
platform: time
|
||||
after: '2:31:00'
|
||||
action:
|
||||
service: zwave.heal_network
|
||||
```
|
||||
|
||||
#### {% linkable_title Device Specific Notes & Configuration %}
|
||||
|
||||
##### {% linkable_title Aeon Minimote %}
|
||||
|
||||
Here's a handy configuration for the Aeon Labs Minimote that defines all possible button presses. Put it into `automation.yaml`.
|
||||
|
||||
```yaml
|
||||
- alias: Minimote Button 1 Pressed
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 1
|
||||
|
||||
- alias: Minimote Button 1 Held
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 2
|
||||
|
||||
- alias: Minimote Button 2 Pressed
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 3
|
||||
|
||||
- alias: Minimote Button 2 Held
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 4
|
||||
|
||||
- alias: Minimote Button 3 Pressed
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 5
|
||||
|
||||
- alias: Minimote Button 3 Held
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 6
|
||||
|
||||
- alias: Minimote Button 4 Pressed
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 7
|
||||
|
||||
- alias: Minimote Button 4 Held
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.scene_activated
|
||||
event_data:
|
||||
entity_id: aeon_labs_minimote_1
|
||||
scene_id: 8
|
||||
```
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue