Fabian Affolter
GitHub
commit
ae690e4953
60 changed files with 1387 additions and 88 deletions
|
|
@ -51,7 +51,7 @@ Configuration variables:
|
|||
- **password** (*Required*): Password for your Abode account.
|
||||
- **name** (*Optional*): The name for your alarm controller.
|
||||
- **polling** (*Optional*): Enable polling if cloud push updating is less reliable. Will update the devices once every 30 seconds. Defaults to False.
|
||||
- **exclude** (*Optional*): A list of devices to exclude from Home Assistant by their Abode `device_id`, found within the component attributes.
|
||||
- **exclude** (*Optional*): A list of devices to exclude from Home Assistant by their Abode `device_id` or `automation_id`, found within the component attributes.
|
||||
- **lights** (*Optional*): A list of switch devices that Home Assistant should treat as lights by the switches Abode `device_id`, found within the component attributes.
|
||||
|
||||
## {% linkable_title Events %}
|
||||
|
|
@ -106,4 +106,4 @@ Trigger a quick action automation on your Abode system.
|
|||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | No | String or list of strings that point at `entity_id`s of binary_sensors that represent your Abode quick actions.
|
||||
| `entity_id` | No | String or list of strings that point at `entity_id`s of binary_sensors that represent your Abode quick actions.
|
||||
|
|
|
|||
|
|
@ -55,13 +55,14 @@ alarm_control_panel:
|
|||
report_server_enabled: True
|
||||
report_server_port: PORT_OF_EGARDIASERVER (85 as per the instructions above)
|
||||
report_server_codes:
|
||||
arm: XXXXXXXXXXXXXXXX
|
||||
disarm: XXXXXXXXXXXXXXXX
|
||||
arm: XXXXXXXXXXXXXXXX, XXXXXXXXXXXXXXXX
|
||||
disarm: XXXXXXXXXXXXXXXX, XXXXXXXXXXXXXXXX
|
||||
armhome: XXXXXXXXXXXXXXXX
|
||||
triggered: XXXXXXXXXXXXXXXX, XXXXXXXXXXXXXXXX, XXXXXXXXXXXXXXXX
|
||||
standby: XXXXXXXXXXXXXXXX
|
||||
ignore: XXXXXXXXXXXXXXXX
|
||||
```
|
||||
Note that you can have more than one code for triggered since every sensor generates its own code. arm, disarm, armhome and standby will all be one code.
|
||||
Note that for triggered, arm and disarm multiple codes can be entered since each sensor triggers with a different code and each user of the system has its own arm and disarm codes. Also note that your system will do regular system checks which will be reported as well. Since Home Assistant provides no way of handling them properly, you can enter those codes as ignore (again, multiple codes can be used here). The egardia component will ignore these codes and continue returning the old status if it receives any of the codes that are listed as ignore. This is useful for example when you have armed your alarm at night: normally a system check will occur at least once during the night and if that code is not specified anywhere Home Assistant will set the status of the alarm to its default, which is unarmed. This is in fact wrong. Listing the code as ignore changes this behavior and Home Assistant will continue to show the status the alarm is in (disarm, arm, armhome, triggered) even when system checks occur.
|
||||
|
||||
5. Start the `egardiaserver.py` script on boot of your Home Assistant machine, for example by using systemd. To use this method, create a shell script named `egardiaserver.sh` that contains the following:
|
||||
```bash
|
||||
source /srv/homeassistant/homeassistant_venv/bin/activate
|
||||
|
|
|
|||
|
|
@ -52,9 +52,9 @@ $ ffmpeg -i YOUR_INPUT -an -filter:v select=gt(scene\,0.1) -f framemd5 -
|
|||
|
||||
If you are running into trouble with this sensor, please refer to the [troubleshooting section](/components/ffmpeg/#troubleshooting).
|
||||
|
||||
#### {% linkable_title Tipps %}
|
||||
#### {% linkable_title Tips %}
|
||||
|
||||
- Use motion only in a customer area with [crop filter](https://ffmpeg.org/ffmpeg-filters.html#crop):
|
||||
- Use motion only in a custom area with [crop filter](https://ffmpeg.org/ffmpeg-filters.html#crop):
|
||||
|
||||
```yaml
|
||||
extra_arguments: -filter:v "crop=100:100:12:34"
|
||||
|
|
|
|||
|
|
@ -14,9 +14,13 @@ ha_iot_class: "depends"
|
|||
---
|
||||
|
||||
|
||||
The `mqtt` binary sensor platform uses the MQTT message payload as the sensor value. If messages in this `state_topic` are published with *RETAIN* flag, the sensor will receive an instant update with the last known value. Otherwise, the initial state will be off.
|
||||
The `mqtt` binary sensor platform uses an MQTT message payload to set the binary sensor to one of two states: `on` or `off`.
|
||||
|
||||
To use your MQTT binary sensor in your installation, add the following to your `configuration.yaml` file:
|
||||
The binary sensor state will be updated only after a new message is published on `state_topic` matching `payload_on` or `payload_off`. If these messages are published with the `retain` flag set, the binary sensor will receive an instant state update after subscription and Home Assistant will display the correct state on startup. Otherwise, the initial state displayed in Home Assistant will be `unknown`.
|
||||
|
||||
The `mqtt` binary sensor platform optionally supports an `availability_topic` to receive online and offline messages (birth and LWT messages) from the MQTT device. During normal operation, if the MQTT cover device goes offline (i.e. publishes `payload_not_available` to `availability_topic`), Home Assistant will display the binary sensor as `unavailable`. If these messages are published with the `retain` flag set, the binary sensor will receive an instant update after subscription and Home Assistant will display the correct availability state of the binary sensor when Home Assistant starts up. If the `retain` flag is not set, Home Assistant will display the binary sensor as `unavailable` when Home Assistant starts up. If no `availability_topic` is defined, Home Assistant will consider the MQTT device to be available.
|
||||
|
||||
To use an MQTT binary sensor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
@ -27,32 +31,37 @@ binary_sensor:
|
|||
|
||||
Configuration variables:
|
||||
|
||||
- **name** (*Optional*): The name of the binary sensor. Default is `MQTT Binary Sensor`.
|
||||
- **state_topic** (*Required*): The MQTT topic subscribed to receive sensor values.
|
||||
- **name** (*Optional*): The name of the sensor. Default is 'MQTT Sensor'.
|
||||
- **qos** (*Optional*): The maximum QoS level of the state topic. Default is 0.
|
||||
- **payload_on** (*Optional*): The payload that represents on state. Default is "ON".
|
||||
- **payload_off** (*Optional*): The payload that represents state. Default is "OFF".
|
||||
- **payload_on** (*Optional*): The payload that represents the on state. Default is `ON`.
|
||||
- **payload_off** (*Optional*): The payload that represents the off state. Default is `OFF`.
|
||||
- **availability_topic** (*Optional*): The MQTT topic subscribed to receive birth and LWT messages from the MQTT device. If `availability_topic` is not defined, the binary sensor availability state will always be `available`. If `availability_topic` is defined, the binary sensor availability state will be `unavailable` by default.
|
||||
- **payload_available** (*Optional*): The payload that represents the online state. Default is `online`.
|
||||
- **payload_not_available** (*Optional*): The payload that represents the offline state. Default is `offline`.
|
||||
- **qos** (*Optional*): The maximum QoS level to be used when receiving messages. Default is `0`.
|
||||
- **device_class** (*Optional*): The [type/class](/components/binary_sensor/) of the sensor to set the icon in the frontend.
|
||||
- **value_template** (*Optional*): Defines a [template](/docs/configuration/templating/#processing-incoming-data) to extract a value from the payload.
|
||||
|
||||
For a quick check you can use the command line tools shipped with `mosquitto` to send MQTT messages. Set the state of a sensor manually:
|
||||
To test, you can use the command line tool `mosquitto_pub` shipped with `mosquitto` or the `mosquitto-clients` package to send MQTT messages. To set the state of the binary sensor manually:
|
||||
|
||||
```bash
|
||||
$ mosquitto_pub -h 127.0.0.1 -t home-assistant/window/contact -m "OFF"
|
||||
```
|
||||
|
||||
An extended configuration for the same sensor could look like this if you want/need to be more specific.
|
||||
The example below shows a full configuration for a binary sensor:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
binary_sensor:
|
||||
- platform: mqtt
|
||||
name: "Window Contact Sensor"
|
||||
state_topic: "home-assistant/window/contact"
|
||||
name: "Windows contact"
|
||||
payload_on: "ON"
|
||||
payload_off: "OFF"
|
||||
availability_topic: "home-assistant/window/availability"
|
||||
payload_available: "online"
|
||||
payload_not_available: "offline"
|
||||
qos: 0
|
||||
payload_on: "1"
|
||||
payload_off: "0"
|
||||
device_class: opening
|
||||
value_template: '{% raw %}{{ value.x }}{% endraw %}'
|
||||
```
|
||||
|
||||
|
|
|
|||
30
source/_components/binary_sensor.raincloud.markdown
Normal file
30
source/_components/binary_sensor.raincloud.markdown
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Melnor Raincloud Binary Sensor"
|
||||
description: "Instructions on how to integrate your Melnor Raincloud sprinkler system within Home Assistant."
|
||||
date: 2017-09-04 10:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: raincloud.jpg
|
||||
ha_category: Binary Sensor
|
||||
ha_release: "0.55"
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
To get your [Melnor RainCloud](https://wifiaquatimer.com) binary sensors working within Home Assistant, please follow the instructions for the general [Raincloud component](/components/raincloud).
|
||||
|
||||
Once you have enabled the [Raincloud component](/components/raincloud), add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
binary_sensor:
|
||||
- platform: raincloud
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **monitored_conditions** array (*Optional*): Conditions to display in the frontend. If not specified, all conditions below will be enabled by default. The following conditions can be monitored.
|
||||
- **is_watering**: Return if is currently watering per zone.
|
||||
- **status**: Return status from the Melnor RainCloud Controller and Melnor RainCloud Faucet.
|
||||
|
|
@ -14,7 +14,9 @@ ha_release: 0.34
|
|||
---
|
||||
|
||||
|
||||
The `threshold` binary sensor platform is consuming the state from another sensor. If the value is below (`lower`) or higher (`upper`) than the given threshold then state of this sensor change..
|
||||
The `threshold` binary sensor platform observes the state of another sensor. If the value is below (`lower`) or higher (`upper`) than the given threshold then state of the threshold sensor is changed.
|
||||
|
||||
If the sensor is configured with no hysteresis and the sensor value is equal to the threshold, the sensor is turned off since it is not `lower` or `upper` with respect to the threshold.
|
||||
|
||||
It's an alternative to the template binary sensor's `value_template:` to get the abnormal/too high/too low states.
|
||||
|
||||
|
|
@ -36,7 +38,7 @@ binary_sensor:
|
|||
Configuration variables:
|
||||
|
||||
- **entity_id** (*Required*): The entity to monitor. Only [sensors](/components/sensor/) are supported.
|
||||
- **threshold** (*Required*): The value which is the threshold.
|
||||
- **threshold** (*Required*): The threshold which the observed value is compared against.
|
||||
- **type** (*Required*): `lower` if the value needs to be below the threshold or `upper` if higher.
|
||||
- **hysteresis** (*Optional*): The distance the observed value must be from the threshold before the state is changed. Defaults to `0.0`
|
||||
- **name** (*Optional*): Name of the sensor to use in the frontend. Defaults to `Stats`.
|
||||
|
||||
|
|
|
|||
90
source/_components/climate.mqtt.markdown
Normal file
90
source/_components/climate.mqtt.markdown
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT HVAC"
|
||||
description: "Instructions how to integrate MQTT HVAC into Home Assistant."
|
||||
date: 2017-07-31 19:59
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: heat-control.png
|
||||
ha_category: Climate
|
||||
ha_release: 0.55
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
The `mqtt` climate platform let you control your MQTT enabled HVAC devices.
|
||||
|
||||
The platform currently works in optimistic mode, which means it does not obtain states from MQTT topics, but it sends and remembers control commands.
|
||||
|
||||
It uses a sensor under the hood to obtain the current temperature.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
climate:
|
||||
- platform: mqtt
|
||||
name: Study
|
||||
current_temperature_topic: /sensors/hvac_study/current_temp
|
||||
temperature_command_topic: /sensors/hvac_study/target_temp
|
||||
```
|
||||
|
||||
Configuration variables *except* for MQTT topics:
|
||||
|
||||
- **name** (*Required*): Name of MQTT HVAC.
|
||||
- **qos** (*Optional*): The maximum QoS level of the state topic. Default is `0` and will also be used to publishing messages.
|
||||
- **retain** (*Optional*): If the published message should have the retain flag on or not.
|
||||
- **send_if_off** (*Optional*): Set to `false` to suppress sending of all MQTT messages when the current mode is `Off`. Defaults to `true`.
|
||||
- **initial** (*Optional*): Set the initial target temperature. Defaults to 21 degrees.
|
||||
- **payload_on** (*Optional*): For MQTT topics that control an `on` / `off` value (e.g., `aux_command_topic`), set the value that should be sent for `on`. Defaults to 'ON'.
|
||||
- **payload_off** (*Optional*): For MQTT topics that control an `on` / `off` value (e.g., `aux_command_topic`), set the value that should be sent for `off`. Defaults to 'OFF'.
|
||||
|
||||
Configuration of the MQTT topics:
|
||||
|
||||
- **current_temperature_topic** (*Optional*): The MQTT topic on which to listen for the current temperature
|
||||
- **power_command_topic** (*Optional*): The MQTT topic to publish commands to change the power state. This is useful if your device has a separate power toggle in addition to mode.
|
||||
- **mode_command_topic** (*Optional*): The MQTT topic to publish commands to change the HVAC operation mode.
|
||||
- **mode_state_topic** (*Optional*): The MQTT topic to subscribe for changes of the HVAC operation mode. If this is not set, the operation mode works in optimistic mode (see below).
|
||||
- **temperature_command_topic** (*Optional*): The MQTT topic to publish commands to change the target temperature.
|
||||
- **temperature_state_topic** (*Optional*): The MQTT topic to subscribe for changes in the target temperature. If this is not set, the target temperature works in optimistic mode (see below).
|
||||
- **fan_mode_command_topic** (*Optional*): The MQTT topic to publish commands to change the fan mode.
|
||||
- **fan_mode_state_topic** (*Optional*): The MQTT topic to subscribe for changes of the HVAC fan mode. If this is not set, the fan mode works in optimistic mode (see below).
|
||||
- **swing_mode_command_topic** (*Optional*): The MQTT topic to publish commands to change the swing mode.
|
||||
- **swing_mode_state_topic** (*Optional*): The MQTT topic to subscribe for changes of the HVAC swing mode. If this is not set, the swing mode works in optimistic mode (see below).
|
||||
- **away_mode_command_topic** (*Optional*): The MQTT topic to publish commands to change the away mode.
|
||||
- **away_mode_state_topic** (*Optional*): The MQTT topic to subscribe for changes of the HVAC away mode. If this is not set, the away mode works in optimistic mode (see below).
|
||||
- **hold_command_topic** (*Optional*): The MQTT topic to publish commands to change the hold mode.
|
||||
- **hold_state_topic** (*Optional*): The MQTT topic to subscribe for changes of the HVAC hold mode. If this is not set, the hold mode works in optimistic mode (see below).
|
||||
- **aux_command_topic** (*Optional*): The MQTT topic to publish commands to switch auxiliary heat.
|
||||
- **aux_state_topic** (*Optional*): The MQTT topic to subscribe for changes of the auxiliary heat mode. If this is not set, the auxiliary heat mode works in optimistic mode (see below).
|
||||
|
||||
#### Optimistic mode
|
||||
|
||||
If a property works in *optimistic mode* (when the corresponding state topic is not set), home assistant will assume that any state changes published to the command topics did work and change the internal state of the entity immediately after publishing to the command topic. If it does not work in optimistic mode, the internal state of the entity is only updated when the requested update is confirmed by the device through the state topic.
|
||||
|
||||
### {% linkable_title Example %}
|
||||
|
||||
A full configuration example looks like the one below.
|
||||
|
||||
```yaml
|
||||
# Full example configuration.yaml entry
|
||||
climate:
|
||||
- platform: mqtt
|
||||
name: Study
|
||||
target_sensor: sensor.study_temperature
|
||||
modes:
|
||||
- off
|
||||
- cool
|
||||
- fan_only
|
||||
swing_modes:
|
||||
- on
|
||||
- off
|
||||
fan_modes:
|
||||
- high
|
||||
- medium
|
||||
- low
|
||||
power_command_topic: "study/ac/power/set"
|
||||
mode_command_topic: "study/ac/mode/set"
|
||||
temperature_command_topic: "study/ac/temperature/set"
|
||||
fan_mode_command_topic: "study/ac/fan/set"
|
||||
swing_mode_command_topic: "study/ac/swing/set"
|
||||
```
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Wink Thermostat"
|
||||
description: "Instructions how to setup the Wink binary sensors within Home Assistant."
|
||||
title: "Wink Climate"
|
||||
description: "Instructions how to setup the Wink climate devices within Home Assistant."
|
||||
date: 2016-11-01 22:36
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -14,20 +14,21 @@ ha_iot_class: "Cloud Polling"
|
|||
---
|
||||
|
||||
|
||||
The Wink climate platform allows you to get data from your [Wink](http://www.wink.com/) thermostats.
|
||||
The Wink climate platform allows you to get data from your [Wink](http://www.wink.com/) thermostats, Air Conditioners, and Water Heaters.
|
||||
|
||||
The requirement is that you have setup [Wink](/components/wink/).
|
||||
|
||||
|
||||
### {% linkable_title Supported climate devices %}
|
||||
|
||||
- Nest (No wink hub required)
|
||||
- Ecobee (No wink hub required)
|
||||
- Sensi (No wink hub required)
|
||||
- Nest (No Wink hub required)
|
||||
- Ecobee (No Wink hub required)
|
||||
- Sensi (No Wink hub required)
|
||||
- Carrier (Unconfirmed)
|
||||
- Honeywell (No wink hub required)
|
||||
- Honeywell (No Wink hub required)
|
||||
- Generic Z-Wave
|
||||
- Quirky Aros window AC unit
|
||||
- Rheem Econet water heaters (No Wink hub required)
|
||||
|
||||
<p class='note'>
|
||||
The above devices are confirmed to work, but others may work as well.
|
||||
|
|
|
|||
|
|
@ -13,39 +13,44 @@ ha_iot_class: "depends"
|
|||
ha_release: 0.18
|
||||
---
|
||||
|
||||
The `mqtt` cover platform enables the possibility to control an MQTT cover. The device state will be updated only after receiving the a new
|
||||
state from `state_topic`. If these messages are published with `RETAIN` flag, the MQTT device will receive an instant state update after subscription and will start with correct state. Otherwise, the initial state will be `unknown`.
|
||||
The `mqtt` cover platform allows you to control an MQTT cover (such as blinds, a rollershutter, or a garage door).
|
||||
|
||||
There is a state attribute that stores the relative position of the device, where 0 means the device is `closed` and all other intermediate positions means the device is `open`.
|
||||
The device state (`open` or `closed`) will be updated only after a new message is published on `state_topic` matching `state_open` or `state_closed`. If these messages are published with the `retain` flag set, the cover will receive an instant state update after subscription and Home Assistant will display the correct state on startup. Otherwise, the initial state displayed in Home Assistant will be `unknown`.
|
||||
|
||||
When a state topic is not available, the cover will work in optimistic mode. In this mode, the cover will immediately change state after every command. Otherwise, the cover will wait for state confirmation from device (message from `state_topic`).
|
||||
There is an attribute that stores the relative position of the device, where 0 means the device is `closed` and all other intermediate positions means the device is `open`.
|
||||
|
||||
Optimistic mode can be forced, even if `state_topic` is available. Try to enable it, if experiencing incorrect cover operation.
|
||||
If a state topic is not defined, the cover will work in optimistic mode. In this mode, the cover will immediately change state (`open` or `closed`) after every command sent by Home Assistant. If a state topic is defined, the cover will wait for a message on `state_topic` matching `state_open` or `state_closed` before changing state in Home Assistant.
|
||||
|
||||
Optimistic mode can be forced, even if a `state_topic` is defined. Try to enable it if experiencing incorrect cover operation.
|
||||
|
||||
The `mqtt` cover platform optionally supports an `availability_topic` to receive online and offline messages (birth and LWT messages) from the MQTT cover device. During normal operation, if the MQTT cover device goes offline (i.e. publishes `payload_not_available` to `availability_topic`), Home Assistant will display the cover as "unavailable". If these messages are published with the `retain` flag set, the cover will receive an instant update after subscription and Home Assistant will display correct availability state of the cover when Home Assistant starts up. If the `retain` flag is not set, Home Assistant will display the cover as "unavailable" when Home Assistant starts up.
|
||||
|
||||
To use your MQTT cover in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yml entry
|
||||
# Example configuration.yaml entry
|
||||
cover:
|
||||
- platform: mqtt
|
||||
name: "MQTT Cover"
|
||||
state_topic: "home-assistant/cover"
|
||||
command_topic: "home-assistant/cover/set"
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **name** (*Optional*): The name of the sensor. Default is `MQTT Cover`.
|
||||
- **state_topic** (*Optional*): The MQTT topic subscribed to receive sensor values.
|
||||
- **command_topic** (*Optional*): The MQTT topic to publish commands to control the rollershutter.
|
||||
- **command_topic** (*Optional*): The MQTT topic to publish commands to control the cover.
|
||||
- **payload_open** (*Optional*): The payload that opens the cover. Default is `OPEN`.
|
||||
- **payload_close** (*Optional*): The payload that closes the cover. Default is `CLOSE`.
|
||||
- **payload_stop** (*Optional*): The payload that stops the rollershutter. default is `STOP`.
|
||||
- **state_open** (*Optional*): The payload that represents open state. Default is `open`.
|
||||
- **state_closed** (*Optional*): The payload that represents closed state. Default is `closed`.
|
||||
- **payload_stop** (*Optional*): The payload that stops the cover. default is `STOP`.
|
||||
- **state_topic** (*Optional*): The MQTT topic subscribed to receive cover state messages.
|
||||
- **state_open** (*Optional*): The payload that represents the open state. Default is `open`.
|
||||
- **state_closed** (*Optional*): The payload that represents the closed state. Default is `closed`.
|
||||
- **availability_topic** (*Optional*): The MQTT topic subscribed to to receive birth and LWT messages from the MQTT cover device. If `availability_topic` is not defined, the cover availability state will always be "available". If `availability_topic` is defined, the cover availability state will be "unavailable" by default.
|
||||
- **payload_available** (*Optional*): The payload that represents the online state. Default is `online`.
|
||||
- **payload_not_available** (*Optional*): The payload that represents the offline state. Default is `offline`.
|
||||
- **optimistic** (*Optional*): Flag that defines if switch works in optimistic mode. Default is `true` if no state topic defined, else `false`.
|
||||
- **qos** (*Optional*): The maximum QoS level of the state topic. Default is `0`. Will also be used when publishing messages.
|
||||
- **retain** (*Optional*): If the published message should have the retain flag on or not. Default is `false`.
|
||||
- **qos** (*Optional*): The maximum QoS level to be used when receiving and publishing messages. Default is `0`.
|
||||
- **retain** (*Optional*): Defines if published messages should have the retain flag set. Default is `false`.
|
||||
- **value_template** (*Optional*): Defines a [template](/docs/configuration/templating/#processing-incoming-data) to extract a value from the payload.
|
||||
- **set_position_topic** (*Optional*): The MQTT topic to publish position commands to.
|
||||
- **set_position_template** (*Optional*): Defines a [template](/topics/templating/) to define the position to be sent to the `set_position_topic` topic. Incoming position value is available for use in the template `{{position}}`. If no template is defined, the numeric position (0-100) will be written directly to the topic.
|
||||
|
|
@ -60,7 +65,7 @@ Configuration variables:
|
|||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
In this section you find some real life examples of how to use this sensor.
|
||||
In this section you find some real life examples of how to use this platform.
|
||||
|
||||
### {% linkable_title Full configuration without tilt %}
|
||||
|
||||
|
|
@ -70,16 +75,19 @@ The example below shows a full configuration for a cover without tilt.
|
|||
# Example configuration.yml entry
|
||||
cover:
|
||||
- platform: mqtt
|
||||
state_topic: "home-assistant/cover"
|
||||
command_topic: "home-assistant/cover/set"
|
||||
name: "MQTT Cover"
|
||||
command_topic: "home-assistant/cover/set"
|
||||
state_topic: "home-assistant/cover/state"
|
||||
availability_topic: "home-assistant/cover/availability"
|
||||
qos: 0
|
||||
retain: true
|
||||
payload_open: "OPEN"
|
||||
payload_close: "CLOSE"
|
||||
payload_stop: "STOP"
|
||||
state_open: "OPEN"
|
||||
state_closed: "STATE"
|
||||
state_open: "open"
|
||||
state_closed: "closed"
|
||||
payload_available: "online"
|
||||
payload_not_available: "offline"
|
||||
optimistic: false
|
||||
value_template: '{% raw %}{{ value.x }}{% endraw %}'
|
||||
```
|
||||
|
|
@ -92,27 +100,30 @@ The example below shows a full configuration for a cover.
|
|||
# Example configuration.yml entry
|
||||
cover:
|
||||
- platform: mqtt
|
||||
state_topic: "home-assistant/cover"
|
||||
command_topic: "home-assistant/cover/set"
|
||||
name: "MQTT Cover"
|
||||
command_topic: "home-assistant/cover/set"
|
||||
state_topic: "home-assistant/cover/state"
|
||||
availability_topic: "home-assistant/cover/availability"
|
||||
qos: 0
|
||||
retain: true
|
||||
payload_open: "OPEN"
|
||||
payload_close: "CLOSE"
|
||||
payload_stop: "STOP"
|
||||
state_open: "OPEN"
|
||||
state_closed: "STATE"
|
||||
state_open: "open"
|
||||
state_closed: "closed"
|
||||
payload_available: "online"
|
||||
payload_not_available: "offline"
|
||||
optimistic: false
|
||||
value_template: '{% raw %}{{ value.x }}{% endraw %}'
|
||||
tilt_command_topic: 'home-assistant/cover/tilt'
|
||||
tilt_status_topic: 'home-assistant/cover/tilt-status'
|
||||
tilt_status_topic: 'home-assistant/cover/tilt-state'
|
||||
tilt_min: 0
|
||||
tilt_max: 180
|
||||
tilt_closed_value: 70
|
||||
tilt_opened_value: 180
|
||||
```
|
||||
|
||||
For a check you can use the command line tools `mosquitto_pub` shipped with `mosquitto` to send MQTT messages. This allows you to operate your cover manually:
|
||||
To test, you can use the command line tool `mosquitto_pub` shipped with `mosquitto` or the `mosquitto-clients` package to send MQTT messages. This allows you to operate your cover manually:
|
||||
|
||||
```bash
|
||||
$ mosquitto_pub -h 127.0.0.1 -t home-assistant/cover/set -m "CLOSE"
|
||||
|
|
|
|||
|
|
@ -29,10 +29,10 @@ device_tracker:
|
|||
|
||||
Configuration variables:
|
||||
|
||||
- **host** (*Required*): The IP address of your router, e.g. `192.168.1.1`.
|
||||
- **username** (*Required*): The username of an user with administrative privileges, usually `admin`.
|
||||
- **host** (*Optional*): The IP address of your router, e.g. `192.168.1.1`. If not provided `routerlogin.net` will be used.
|
||||
- **username** (*Optional*): The username of an user with administrative privileges. If not provided `admin` will be used.
|
||||
- **port** (*Optional*): The port your router communicates with (defaults to `5000`, but `80` is also known to be used on some models).
|
||||
- **password** (*Required*): The password for your given admin account.
|
||||
- **port** (*Optional*): The port your router communicates with (defaults to 5000, but 80 is also known to be used on some models)
|
||||
|
||||
List of models that are known to use port 80:
|
||||
- Nighthawk X4S - AC2600 (R7800)
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ sharing: true
|
|||
footer: true
|
||||
logo: owntracks.png
|
||||
ha_category: Presence Detection
|
||||
featured: true
|
||||
featured: false
|
||||
ha_release: 0.7.4
|
||||
---
|
||||
|
||||
|
|
|
|||
36
source/_components/device_tracker.owntracks_http.markdown
Normal file
36
source/_components/device_tracker.owntracks_http.markdown
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
layout: page
|
||||
title: "OwnTracks (via HTTP)"
|
||||
description: "Instructions how to use Owntracks via HTTP to track devices in Home Assistant."
|
||||
date: 2017-09-28 07:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: owntracks.png
|
||||
ha_category: Presence Detection
|
||||
featured: true
|
||||
ha_release: 0.55
|
||||
---
|
||||
|
||||
OwnTracks is a free and open source application that allows you to track your location in Home Assistant. This is a platform that supports OwnTracks via their HTTP publishing method.
|
||||
|
||||
To integrate Owntracks tracking via HTTP in Home Assistant, add the following section to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
device_tracker:
|
||||
- platform: owntracks_http
|
||||
```
|
||||
|
||||
For configuration options and usage instructions, read the documentation for the [OwnTracks platform](/components/device_tracker.owntracks/).
|
||||
|
||||
## {% linkable_title Configuring OwnTracks to submit data via HTTP %}
|
||||
|
||||
Open OwnTracks and go to Connection preferences:
|
||||
|
||||
- Mode: Private HTTP
|
||||
- Host: <Home Assistant url>/api/owntracks/<your name>/<device name>
|
||||
- Identification: turn authentication on, username `homeassistant` and password is your API password that you use to login to Home Assistant.
|
||||
|
||||
Host example: If I host my Home Assistant at `https://example.duckdns.org`, my name is Paulus and my phone is a Pixel I would set the host to be `https://example.duckdns.org/api/owntracks/paulus/pixel`. This will result in an entity with an ID of `device_tracker.paulus_pixel`. You can pick any name for the user and the device.
|
||||
36
source/_components/duckdns.markdown
Normal file
36
source/_components/duckdns.markdown
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
layout: page
|
||||
title: "DuckDNS"
|
||||
description: "Keep your computer registered with the DuckDNS dynamic DNS."
|
||||
date: 2017-09-23 07:08
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: duckdns.png
|
||||
ha_category: Utility
|
||||
featured: false
|
||||
ha_release: 0.55
|
||||
---
|
||||
|
||||
With the DuckDNS component you can keep your DuckDNS record up to date. DuckDNS is a free dynamic DNS service that allows you to point a subdomain under `duckdns.org` at your computer.
|
||||
|
||||
To use the component in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
duckdns:
|
||||
domain: mysubdomain
|
||||
access_token: abcdefgh
|
||||
```
|
||||
|
||||
{% configuration binary_sensor.template %}
|
||||
domain:
|
||||
description: Your duckdns subdomain (without the `.duckdns.org` suffix).
|
||||
required: true
|
||||
type: string
|
||||
access_token:
|
||||
description: Your DuckDNS access token. Log in to the site to get one.
|
||||
required: true
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
62
source/_components/history_graph.markdown
Normal file
62
source/_components/history_graph.markdown
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
layout: page
|
||||
title: "History Graph"
|
||||
description: "Instructions for setting up History Graph."
|
||||
date: 2017-09-20 15:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: History
|
||||
logo: home-assistant.png
|
||||
ha_release: "0.55"
|
||||
---
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/screenshots/history_graph.png' />
|
||||
</p>
|
||||
|
||||
The `history_graph` component will make the UI display a graph similar to the graphs in `more-info` popups and the [history](/components/history/) panel.
|
||||
|
||||
To use this component in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Minimal configuration.yaml entry
|
||||
history_graph:
|
||||
gr1:
|
||||
entities:
|
||||
- light.ceiling.lights
|
||||
|
||||
```
|
||||
|
||||
### {% linkable_title Configuration variables %}
|
||||
|
||||
| Attribute | Optional | Default | Description |
|
||||
|---------------------------|----------|-------------------------------------------------------|
|
||||
| `entities` | no | | List of entities whose history to show as a graph. |
|
||||
| `name` | yes | ID | Name to display. |
|
||||
| `hours_to_show` | yes | 24 | Number of hours to show. |
|
||||
| `refresh` | yes | 0 | Number of seconds between graph refreshes. 0 for no refreshes. |
|
||||
|
||||
### {% linkable_title Full Example %}
|
||||
|
||||
```yaml
|
||||
# Full configuration.yaml entry
|
||||
history_graph:
|
||||
gr1:
|
||||
name: Lights Graph
|
||||
entities:
|
||||
- light.ceiling.lights
|
||||
- light.bed_light
|
||||
hours_to_show: 240
|
||||
refresh: 60
|
||||
gr2:
|
||||
name: Temperature
|
||||
entities:
|
||||
- sensor.outside_temperature
|
||||
- sensor.inside_temperature
|
||||
hours_to_show: 120
|
||||
# refresh: 0
|
||||
|
||||
```
|
||||
|
||||
|
||||
50
source/_components/input_datetime.markdown
Normal file
50
source/_components/input_datetime.markdown
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Input Datetime"
|
||||
description: "Instructions how to integrate the Input Datetime component into Home Assistant."
|
||||
date: 2017-09-14 16:01
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: home-assistant.png
|
||||
ha_category: Automation
|
||||
ha_release: 0.55
|
||||
---
|
||||
|
||||
The `input_datetime` component allows the user to define date and time values that can be controlled via the frontend and can be used within automations and templates.
|
||||
|
||||
To add three datetime inputs to your installation, one with both date and time, and one with date or time each, add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
input_datetime:
|
||||
both_date_and_time:
|
||||
name: Input with both date and time
|
||||
has_date: true
|
||||
has_time: true
|
||||
only_date:
|
||||
name: Input with only date
|
||||
has_date: true
|
||||
has_time: false
|
||||
only_time:
|
||||
name: Input with only time
|
||||
has_date: false
|
||||
has_time: true
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **[alias]** (*Required*): Alias for the datetime input. Multiple entries are allowed.
|
||||
- **name** (*Optional*): Friendly name of the datetime input.
|
||||
- **has_time** (*Optional*): Set to `true` if this input should have time. Defaults to `false`.
|
||||
- **has_date** (*Optional*): Set to `true` if this input should have a date. Defaults to `false`.
|
||||
- **initial** (*Optional*): Set the initial value of this input. Defaults to '1970-01-01 00:00'.
|
||||
|
||||
A datetime input entity's state exports several attributes that can be useful in automations and templates:
|
||||
|
||||
- **has_time**: `true` if this entity has time.
|
||||
- **has_date**: `true` if this entity has a date.
|
||||
- **year**, **month**, **day** (Only available if *has_date* is true): The year, month and day of the date.
|
||||
- **hour**, **minute**, **second** (Only available if *has_time* is true): The hour, minute and second of the time.
|
||||
- **timestamp**: A timestamp representing the time held in the input. If *has_date* is true, this is the UNIX timestamp of the date / time held by the input. Otherwise (i.e., if only *has_time* is true) the number of seconds since midnight representing the time held by the input.
|
||||
|
|
@ -87,7 +87,7 @@ script:
|
|||
sequence:
|
||||
- service: wink.wink_set_lock_alarm_state
|
||||
data:
|
||||
enabled: false
|
||||
enabled: false
|
||||
```
|
||||
|
||||
### {% linkable_title Service `wink_set_lock_beeper_state` %}
|
||||
|
|
@ -130,6 +130,20 @@ script:
|
|||
enabled: false
|
||||
```
|
||||
|
||||
### {% linkable_title Service `wink_add_new_lock_key_code` %}
|
||||
|
||||
You can use the service wink/wink_add_new_lock_key_code to add a new user code to your Wink lock.
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | no | String or list of strings that point at `entity_id`s of locks.
|
||||
| `name` | no | the name of the new key code
|
||||
| `code` | no | The new code. Must match length of existing codes.
|
||||
|
||||
|
||||
<p class='note'>
|
||||
Calling service wink/pull_newly_added_wink_devices will add the new key code to Home Assistant. The device will also show up on the next restart of Home Assistant.
|
||||
</p>
|
||||
|
||||
<p class='note'>
|
||||
If supported by your lock, a binary sensor will be created for each user key code you have defined. These key codes will turn on when the code is entered and automatically turn off after a few seconds.
|
||||
|
|
|
|||
|
|
@ -24,6 +24,9 @@ Currently known supported models:
|
|||
- TX-49DX650B
|
||||
- TX-50DX700B
|
||||
- TX-L42ET50
|
||||
- TX-P50GT60E
|
||||
- TX-65EXW784
|
||||
- TX-32AS520E
|
||||
|
||||
If your model is not on the list then give it a test, if everything works correctly then add it to the list on [GitHub](https://github.com/home-assistant/home-assistant.io).
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ media_player:
|
|||
Configuration variables:
|
||||
|
||||
- **host** (*Optional*): The IP of the LG webOS Smart TV, e.g. `192.168.0.10`.
|
||||
- **mac** (*Optional*): The MAC address of the TV, e.g. `C8:08:E9:99:99:1A`.
|
||||
- **turn_on_action** (*Optional*): Defines an [action](/docs/automation/action/) to turn the TV on.
|
||||
- **name** (*Optional*): The name you would like to give to the LG webOS Smart TV.
|
||||
- **timeout** (*Optional*): The timeout for connections to the TV in seconds.
|
||||
- **filename** (*Optional*): The filename where the pairing key with the TV should be stored. This path is relative to Home Assistant's config directory. It defaults to `webostv.conf`.
|
||||
|
|
@ -36,7 +36,7 @@ Configuration variables:
|
|||
- ***sources** array (*Optional*): List of hardware inputs.
|
||||
|
||||
If you do not specify `host:`, all LG webOS Smart TVs within your network will be auto-discovered if they use the default name setting of `[LG] webOS TV`.
|
||||
Home Assistant is able to turn on a LG webOS Smart TV if you specify its MAC address with `mac:`. Some models require the **Mobile TV On** setting and/or a wired network connection to use Wake-on-LAN.
|
||||
Home Assistant is able to turn on a LG webOS Smart TV if you specify an action, like HDMI-CEC or WakeOnLan.
|
||||
|
||||
A full configuration example will look like the sample below:
|
||||
|
||||
|
|
@ -45,10 +45,13 @@ A full configuration example will look like the sample below:
|
|||
media_player:
|
||||
- platform: webostv
|
||||
host: 192.168.0.10
|
||||
mac: C8:08:E9:99:99:1A
|
||||
name: Living Room TV
|
||||
timeout: 5
|
||||
filename: webostv.conf
|
||||
turn_on_action:
|
||||
service: persistent_notification.create
|
||||
data:
|
||||
message: "Turn on action"
|
||||
customize:
|
||||
sources:
|
||||
- livetv
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
layout: page
|
||||
title: "MQTT Statestream"
|
||||
description: "Instructions how to setup MQTT Statestream within Home Assistant."
|
||||
date: 2017-09-11 08:00
|
||||
date: 2017-10-01 20:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
|
|
@ -21,11 +21,17 @@ To enable MQTT Statestream in Home Assistant, add the following section to your
|
|||
# Example configuration.yaml entry
|
||||
mqtt_statestream:
|
||||
base_topic: homeassistant
|
||||
publish_attributes: true
|
||||
publish_timestamps: true
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **base_topic** (*Required*): Base topic used to generate the actual topic used to publish.
|
||||
- **publish_attributes** (*Optional*): Publish attributes of the entity as well as the state.
|
||||
Default is false.
|
||||
- **publish_timestamps** (*Optional*): Publish the last_changed and last_updated timestamps for the entity.
|
||||
Default is false.
|
||||
|
||||
## Operation
|
||||
|
||||
|
|
@ -34,4 +40,8 @@ When any Home Assistant entity changes, this component will publish that change
|
|||
The topic for each entity is different, so you can easily subscribe other systems to just the entities you are interested in.
|
||||
The topic will be in the form `base_topic/domain/entity/state`.
|
||||
|
||||
For example, with the example configuration above, if an entity called 'light.master_bedroom_dimmer' is turned on, this component will publish `on` to `homeassistant/light/master_bedroom_dimmer/state`.
|
||||
For example, with the example configuration above, if an entity called 'light.master_bedroom_dimmer' is turned on, this component will publish `on` to `homeassistant/light/master_bedroom_dimmer/state`.
|
||||
|
||||
If that entity also has an attribute called `brightness`, the component will also publish the value of that attribute to `homeassistant/light/master_bedroom_dimmer/brightness`.
|
||||
|
||||
The last_updated and last_changed values for the entity will be published to `homeassistant/light/master_bedroom_dimmer/last_updated` and `homeassistant/light/master_bedroom_dimmer/last_changed`, respectively. The timestamps are in ISO 8601 format - for example, `2017-10-01T23:20:30.920969+00:00`.
|
||||
|
|
|
|||
|
|
@ -50,6 +50,51 @@ automation:
|
|||
- +919784516314
|
||||
```
|
||||
|
||||
You can also send messages to users that do not have stored their phone number with Facebook, but this requires a bit more work. The Messenger platform uses page specific user IDs instead of a global user ID. You will need to enable a webhook for the "messages" event in Facebook's developer console. Once a user writes a message to a page, that webhook will then receive the user's page specifc ID as part of the webhook's payload. Below is a simple PHP script that reacts to the message "get my id" and sends a reply containing the user's ID:
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
$access_token = "";
|
||||
$verify_token = "";
|
||||
|
||||
if (isset($_REQUEST['hub_challenge'])) {
|
||||
$challenge = $_REQUEST['hub_challenge'];
|
||||
$hub_verify_token = $_REQUEST['hub_verify_token'];
|
||||
|
||||
if ($hub_verify_token === $verify_token) {
|
||||
echo $challenge;
|
||||
}
|
||||
}
|
||||
|
||||
$input = json_decode(file_get_contents('php://input'), true);
|
||||
$sender = $input['entry'][0]['messaging'][0]['sender']['id'];
|
||||
$message = $input['entry'][0]['messaging'][0]['message']['text'];
|
||||
|
||||
if (preg_match('/get my id/', strtolower($message))) {
|
||||
$url = 'https://graph.facebook.com/v2.10/me/messages?access_token=' . $access_token;
|
||||
$ch = curl_init($url);
|
||||
$jsonData = '{
|
||||
"recipient":{
|
||||
"id":"' . $sender . '"
|
||||
},
|
||||
"message":{
|
||||
"text":"Your ID: ' . $sender . '"
|
||||
}
|
||||
}';
|
||||
|
||||
$jsonDataEncoded = $jsonData;
|
||||
curl_setopt($ch, CURLOPT_POST, 1);
|
||||
curl_setopt($ch, CURLOPT_POSTFIELDS, $jsonDataEncoded);
|
||||
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']);
|
||||
|
||||
if (!empty($input['entry'][0]['messaging'][0]['message'])) {
|
||||
$result = curl_exec($ch);
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### {% linkable_title Rich messages %}
|
||||
You could also send rich messing (cards, buttons, images, videos, etc). [Info](https://developers.facebook.com/docs/messenger-platform/send-api-reference) to which types or messages and how to build them.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,10 +25,28 @@ notify:
|
|||
device_key: ABCDE
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **name** (*Optional*): Setting the optional parameter `name` allows multiple notifiers to be created. The default value is `notify`. The notifier will bind to the service `notify.NOTIFIER_NAME`.
|
||||
- **device_key** (*Required*): The device key of your device.
|
||||
{% configuration %}
|
||||
name:
|
||||
description: Setting the optional parameter `name` allows multiple notifiers to be created. The default value is `notify`. The notifier will bind to the service `notify.NOTIFIER_NAME`.
|
||||
required: false
|
||||
type: string
|
||||
device_key:
|
||||
description: The device key of your device.
|
||||
required: true
|
||||
type: string
|
||||
event:
|
||||
description: The event for the events.
|
||||
required: false
|
||||
type: string
|
||||
password:
|
||||
description: The password of the encryption used by your device.
|
||||
required: inclusive
|
||||
type: string
|
||||
salt:
|
||||
description: The salt used by your device.
|
||||
required: inclusive
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
To test if the service works, just send a message with `curl` from the command-line.
|
||||
|
||||
|
|
|
|||
33
source/_components/raincloud.markdown
Normal file
33
source/_components/raincloud.markdown
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Melnor Raincloud"
|
||||
description: "Instructions on how to integrate your Melnor Raincloud sprinkler system within Home Assistant."
|
||||
date: 2017-09-04 10:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: raincloud.jpg
|
||||
ha_category: Hub
|
||||
ha_release: 0.55
|
||||
---
|
||||
|
||||
The `raincloud` component allows you to integrate your [Melnor RainCloud](https://wifiaquatimer.com) sprinkler system in Home Assistant.
|
||||
|
||||
To enable it, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
||||
raincloud:
|
||||
username: you@example.com
|
||||
password: secret
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **username** (*Required*): The username for accessing your Melnor RainCloud account.
|
||||
- **password** (*Required*): The password for accessing your Melnor RainCloud account.
|
||||
- **scan_interval** (*Optional*): Defines the update interval of the sensor in seconds. Defaults to 20seconds.
|
||||
|
||||
Finish its configuration by visiting the [Raincloud binary sensor](/components/binary_sensor.raincloud/), [Raincloud sensor](/components/sensor.raincloud/) and [Raincloud switch](/components/switch.raincloud/) documentation.
|
||||
|
|
@ -85,6 +85,23 @@ rflink:
|
|||
port: 1234
|
||||
```
|
||||
|
||||
### {% linkable_title Adding devices Automatically %}
|
||||
|
||||
In order to have your devices being detected and added automatically, you need to add the following to the configuration.
|
||||
When pressing the button on the physical remote, RFLink detects the signal and the device should be added automatically to Home Assistant.
|
||||
|
||||
```yaml
|
||||
light:
|
||||
- platform: rflink
|
||||
automatic_add: true
|
||||
switch:
|
||||
- platform: rflink
|
||||
automatic_add: true
|
||||
sensor:
|
||||
- platform: rflink
|
||||
automatic_add: true
|
||||
```
|
||||
|
||||
### {% linkable_title Ignoring devices %}
|
||||
|
||||
RFLink platform can be configured to completely ignore a device on a platform level. This is useful when you have neighbors which also use 433 MHz technology.
|
||||
|
|
|
|||
|
|
@ -25,6 +25,7 @@ sensor:
|
|||
- captured_today
|
||||
- last_capture
|
||||
- total_cameras
|
||||
- battery_level
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
|
@ -33,5 +34,6 @@ Configuration variables:
|
|||
- **captured_today**: Return the number of videos captured on the current day.
|
||||
- **last_capture**: Return the timestamp from the last video captured by your Arlo camera.
|
||||
- **total_cameras**: Return the number of recognized and active cameras linked on your Arlo account.
|
||||
- **battery_level**: Return the battery level of your Arlo camera.
|
||||
|
||||
If no **monitored_conditions** are specified, all of above will be enabled by default.
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ sensor:
|
|||
required: false
|
||||
type: string
|
||||
name:
|
||||
description: "Version of DSMR used by meter, choices: 2.2, 4. Defaults to 2.2."
|
||||
description: "Version of DSMR used by meter. Choices: 2.2, 4, 5. Defaults to 2.2."
|
||||
required: false
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
|
|
|||
|
|
@ -13,7 +13,10 @@ ha_release: 0.21
|
|||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
A sensor platform for the [DTE](https://www.dteenergy.com/) Energy Bridge.
|
||||
A sensor platform for the [DTE](https://www.dteenergy.com/) Energy Bridge. To find out which version of the DTE Energy Bridge sensor you have, find the status LED on your box.
|
||||
|
||||
- If the status LED is on the top, you have a v1.
|
||||
- If the status LED is on the front, you have a v2.
|
||||
|
||||
To enable this sensor, add the following lines to your `configuration.yaml` file:
|
||||
|
||||
|
|
@ -28,3 +31,4 @@ Configuration variables:
|
|||
|
||||
- **ip** (*Required*): The IP address of your bridge.
|
||||
- **name** (*Optional*): Name to use in the frontend.
|
||||
- **version** (*Optional*): Hardware version of the sensor. Defaults to 1.
|
||||
|
|
|
|||
107
source/_components/sensor.geo_rss_events.markdown
Normal file
107
source/_components/sensor.geo_rss_events.markdown
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
---
|
||||
layout: page
|
||||
title: GeoRSS Events Sensor
|
||||
description: "Instructions on how to set up GeoRSS sensors within Home Assistant."
|
||||
date: 2017-07-31
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: rss.png
|
||||
ha_category: Sensor
|
||||
ha_version: 0.55
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
The `geo_rss_events` sensor retrieves events from a GeoRSS feed and
|
||||
shows information of those events filtered by distance to Home Assistant's
|
||||
location and grouped by category.
|
||||
|
||||
This sensor is particularly useful if events occur unexpectedly in the
|
||||
vicinity of the home while the GeoRSS feed also contains many events
|
||||
representing distant unrelated entries. Typical examples are bush fires
|
||||
alerts or earthquakes.
|
||||
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/screenshots/geo-rss-incidents-group-screenshot.png' />
|
||||
</p>
|
||||
|
||||
The reference point for comparing the distance is defined by `latitude`
|
||||
and `longitude` in the basic configuration.
|
||||
|
||||
Only entries of the feed are considered that define a location as `point`
|
||||
or `polygon` in *georss.org* format or as *WGS84 latitude/longitude*.
|
||||
|
||||
The data is updated every 5 minutes.
|
||||
|
||||
## {% linkable_title Configuration %}
|
||||
|
||||
To enable the GeoRSS events sensor, add the following lines to your
|
||||
`configuration.yaml`. This is an example configuration showing bush fire
|
||||
incidents from the NSW Rural Fire Service.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: geo_rss_events
|
||||
name: NSW Fire Service
|
||||
url: http://www.rfs.nsw.gov.au/feeds/majorIncidents.xml
|
||||
unit_of_measurement: 'Incidents'
|
||||
categories:
|
||||
- 'Emergency Warning'
|
||||
- 'Watch and Act'
|
||||
- 'Advice'
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **url** (*Required*): Full URL of the GeoRSS feed.
|
||||
- **name** (*Optional*): Name of the sensor used in generating the entity id. Default is 'Event Service'.
|
||||
- **radius** (*Optional*): The distance in kilometres around the Home Assistant's coordinates in which events are considered. Default is: 20km.
|
||||
- **categories** (*Optional*): List of event category names found in the GeoRSS feed. A separate sensor is created for each category defined. Default is to join events from all categories into an 'Any' category.
|
||||
- **unit_of_measurement** (*Optional*): The type of events found in the GeoRSS feed. Default is 'Events'.
|
||||
|
||||
## {% linkable_title Example Feeds %}
|
||||
|
||||
**Bush Fire Alerts**
|
||||
|
||||
```yaml
|
||||
sensor:
|
||||
- platform: geo_rss_events
|
||||
name: Qld Fire and Emergency Services
|
||||
url: https://www.qfes.qld.gov.au/data/alerts/bushfireAlert.xml
|
||||
unit_of_measurement: 'Alerts'
|
||||
- platform: geo_rss_events
|
||||
name: Tas Fire Service
|
||||
url: http://www.fire.tas.gov.au/Show?pageId=colBushfireSummariesRss
|
||||
unit_of_measurement: 'Alerts'
|
||||
- platform: geo_rss_events
|
||||
name: WA Department of Fire and Emergency Services
|
||||
url: https://www.emergency.wa.gov.au/data/incident_FCAD.rss
|
||||
- platform: geo_rss_events
|
||||
name: ACT Emergency Services Agency
|
||||
url: http://www.esa.act.gov.au/feeds/currentincidents.xml
|
||||
```
|
||||
|
||||
|
||||
**Earthquake Alerts**
|
||||
|
||||
```yaml
|
||||
sensor:
|
||||
- platform: geo_rss_events
|
||||
name: USGS All Earthquakes
|
||||
url: https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_day.atom
|
||||
categories:
|
||||
- 'Past Hour'
|
||||
- 'Past Day'
|
||||
- platform: geo_rss_events
|
||||
name: BGS Worlwide Earthquakes
|
||||
url: http://www.bgs.ac.uk/feeds/worldSeismology.xml
|
||||
categories:
|
||||
- 'EQMH'
|
||||
- platform: geo_rss_events
|
||||
name: Recent significant earthquake reports (Canada)
|
||||
url: http://www.earthquakescanada.nrcan.gc.ca/index-en.php?tpl_region=canada&tpl_output=rss
|
||||
categories:
|
||||
- 'Earthquake Report'
|
||||
```
|
||||
32
source/_components/sensor.raincloud.markdown
Normal file
32
source/_components/sensor.raincloud.markdown
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Melnor Raincloud Sensor"
|
||||
description: "Instructions on how to integrate your Melnor Raincloud sprinkler system within Home Assistant."
|
||||
date: 2017-09-04 10:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: raincloud.jpg
|
||||
ha_category: Sensor
|
||||
ha_release: "0.55"
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
To get your [Melnor RainCloud](https://wifiaquatimer.com) sensors working within Home Assistant, please follow the instructions for the general [Raincloud component](/components/raincloud).
|
||||
|
||||
Once you have enabled the [Raincloud component](/components/raincloud), add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: raincloud
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **monitored_conditions** array (*Optional*): Conditions to display in the frontend. If not specified, all conditions below will be enabled by default. The following conditions can be monitored.
|
||||
- **battery**: Return the battery level the Melnor RainCloud faucet.
|
||||
- **next_cycle**: Return the next schedulle watering cycle per zone.
|
||||
- **rain_delay**: Return the number of days the automatic watering will be delayed due to raining per zone.
|
||||
- **watering_time**: Return the watering remaining minutes per zone.
|
||||
79
source/_components/sensor.thethingsnetwork.markdown
Normal file
79
source/_components/sensor.thethingsnetwork.markdown
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
layout: page
|
||||
title: "The Things Network Sensor"
|
||||
description: "Instructions how to integrate The Things Network sensors into Home Assistant."
|
||||
date: 2017-09-30 08:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: thethingsnetwork.png
|
||||
ha_category: Sensor
|
||||
ha_iot_class: "Local Polling"
|
||||
ha_release: 0.55
|
||||
---
|
||||
|
||||
The `thethingsnetwork` sensor platform allows you to get data from a [The Things Network Storage Integration](https://www.thethingsnetwork.org/docs/applications/storage/).
|
||||
|
||||
This platform requires that the [The Things Network component](/components/thethingsnetwork/) is set up and the [The Things Network Storage Integration](https://www.thethingsnetwork.org/docs/applications/storage/) as well.
|
||||
|
||||
Visit the [The Things Network Console](https://console.thethingsnetwork.org/) website, log in with your The Things Network credentials, choose your application from **Applications** and go to **Integrations**.
|
||||
|
||||
Add a new integration.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/thethingsnetwork/add_integration.png' />
|
||||
Add a The Things Network integration
|
||||
</p>
|
||||
|
||||
Select **Data Storage**.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/thethingsnetwork/choose_integration.png' />
|
||||
Choose a The Things Network integration
|
||||
</p>
|
||||
|
||||
Click **Add integration** to finish the process.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/thethingsnetwork/confirm_integration.png' />
|
||||
Add a The Things Network Data Storage integration
|
||||
</p>
|
||||
|
||||
When done, the status of the integration should be **Running**. You could check the output after clicking on **go to platform** in an interactive web interface.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/thethingsnetwork/storage_integration.png' />
|
||||
Add a The Things Network integration
|
||||
</p>
|
||||
|
||||
Select **Devices** to get the ID of your device that you want to use.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/thethingsnetwork/devices.png' />
|
||||
Devices overview
|
||||
</p>
|
||||
|
||||
To enable this platform, add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: thethingsnetwork
|
||||
device_id: ha-demo
|
||||
values:
|
||||
sensor_value: unit of measurment
|
||||
voltage: V
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
device_id:
|
||||
description: The ID of the device.
|
||||
required: true
|
||||
type: string
|
||||
values:
|
||||
description: The sensor values with their unit of measurement
|
||||
required: true
|
||||
type: list
|
||||
{% endconfiguration %}
|
||||
|
||||
33
source/_components/sensor.tibber.markdown
Normal file
33
source/_components/sensor.tibber.markdown
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Tibber"
|
||||
description: "Instructions how to integrate Tibber within Home Assistant."
|
||||
date: 2017-10-03 17:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: tibber.png
|
||||
ha_category: Sensor
|
||||
ha_release: 0.55
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `tibber` sensor provides the current electricity price if you are a [Tibber](https://tibber.com/) customer.
|
||||
|
||||
To add Tibber to your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: tibber
|
||||
access_token: d1007ead2dc84a2b82f0de19451c5fb22112f7ae11d19bf2bedb224a003ff74a
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
access_token:
|
||||
description: Go to [developer.tibber.com/](https://developer.tibber.com/) to get your API token.
|
||||
required: true
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "ZigBee Home Automation Sensor"
|
||||
description: "Instructions how to setup ZigBee Home Automation sensors within Home Assistant."
|
||||
description: "Instructions on how to setup ZigBee Home Automation sensors within Home Assistant."
|
||||
date: 2017-02-22 00:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -13,3 +13,4 @@ ha_iot_class: "Local Polling"
|
|||
---
|
||||
|
||||
To get your ZigBee sensors working with Home Assistant, follow the instructions for the general [ZigBee Home Automation Component](/components/zha/).
|
||||
|
||||
|
|
|
|||
31
source/_components/switch.raincloud.markdown
Normal file
31
source/_components/switch.raincloud.markdown
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Melnor Raincloud Switch"
|
||||
description: "Instructions on how to integrate your Melnor Raincloud sprinkler system within Home Assistant."
|
||||
date: 2017-09-04 10:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: raincloud.jpg
|
||||
ha_category: Switch
|
||||
ha_release: "0.55"
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
To get your [Melnor RainCloud](https://wifiaquatimer.com) binary sensors working within Home Assistant, please follow the instructions for the general [Raincloud component](/components/raincloud).
|
||||
|
||||
Once you have enabled the [Raincloud component](/components/raincloud), add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
switch:
|
||||
- platform: raincloud
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **watering_minutes** (*Optional*): Value in minutes to watering your garden via frontend. Defaults to 15.
|
||||
- **monitored_conditions** array (*Optional*): Conditions to display in the frontend. If not specified, all conditions below will be enabled by default. The following conditions can be monitored.
|
||||
- **auto_watering**: Toggle the watering scheduled per zone.
|
||||
- **manual_watering**: Toggle manually the watering per zone. It will inherent the value in minutes specified on the RainCloud hub component.
|
||||
63
source/_components/thethingsnetwork.markdown
Normal file
63
source/_components/thethingsnetwork.markdown
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
layout: page
|
||||
title: "The Things Network"
|
||||
description: "Instructions for how to integrate The Things Network within Home Assistant."
|
||||
date: 2017-09-30 08:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: thethingsnetwork.png
|
||||
ha_category: Hub
|
||||
ha_release: 0.55
|
||||
ha_iot_class: depends
|
||||
---
|
||||
|
||||
The `thethingsnetwork` component allows one to interact with the [The Things Network](https://www.thethingsnetwork.org). This community-driven and open network supports [LoRaWAN](https://www.lora-alliance.org/) for long range (~5 to 15km) communication with a low bandwidth (51 bytes/message). [Gateways](https://www.thethingsnetwork.org/docs/gateways/) transfers the received data from the sensors to the The Things Network.
|
||||
|
||||
The Things network support various integrations to make the data available:
|
||||
|
||||
| The Things Network Integration | Home Assistant platform |
|
||||
|---|---|
|
||||
| [MQTT](https://www.thethingsnetwork.org/docs/applications/mqtt/) | |
|
||||
| [Storage](https://www.thethingsnetwork.org/docs/applications/storage/) | [`thethingsnetwork`](/component/sensor.thethingsnetwork/) |
|
||||
| [HTTP](https://www.thethingsnetwork.org/docs/applications/http/} | |
|
||||
|
||||
### {% linkable_title Setup %}
|
||||
|
||||
Visit the [The Things Network Console](https://console.thethingsnetwork.org/) website, log in with your The Things Network credentials, choose your application from **Applications**.
|
||||
|
||||
The **Application ID** is used to identify the scope of your data.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/thethingsnetwork/applications.png' />
|
||||
Application overview
|
||||
</p>
|
||||
|
||||
You need an access key to be able to read the data from your application.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/thethingsnetwork/access_key.png' />
|
||||
Access keys
|
||||
</p>
|
||||
|
||||
To enable this component, add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
thethingsnetwork:
|
||||
app_id: sensor-123
|
||||
access_key: ttn-account-v2.xxxxxxxxxxx_yyyyyyyyyyy
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
app_id:
|
||||
description: The Application ID.
|
||||
required: true
|
||||
type: string
|
||||
access_key:
|
||||
description: The access key.
|
||||
required: true
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
|
|
@ -80,6 +80,26 @@ Use this call to enter the remote control mode, make one move, and stop and exit
|
|||
| `rotation` | no | Rotation, between -179 degrees and 179 degrees. |
|
||||
| `duration` | no | Parameter affecting the duration of the movement. |
|
||||
|
||||
### {% linkable_title Attributes %}
|
||||
|
||||
In addition to all [`vacuum` component attributes] (`battery_icon`, `cleaned_area`, `fan_speed`, `fan_speed_list`, `status`, `params`), the `xiaomi` platform introduces specific attributes to get information of the botvac.
|
||||
|
||||
These are: `cleaning_time`, `do_not_disturb`, `main_brush_left`, `side_brush_left`, `filter_left`, `cleaning_count`, `total_cleaned_area` and `total_cleaning_time`.
|
||||
|
||||
The following table shows the units of measurement for the single attributes.
|
||||
|
||||
| Attribute | Unit of measurement | Description |
|
||||
|---------------------------|---------------------|-------------------------------------------------------|
|
||||
| `do_not_disturb` | | DND mode on / off |
|
||||
| `cleaning_time` | minutes | Last / actual cleaning time in minutes |
|
||||
| `cleaned_area` | square meter | Last / actual cleaned area in square meter |
|
||||
| `main_brush_left` | hours | Hours left until a change of the main brush is needed |
|
||||
| `side_brush_left` | hours | Hours left until a change of the side brush is needed |
|
||||
| `filter_left` | hours | Hours left until a change of the filter is needed |
|
||||
| `cleaning_count` | | Number of total cleaning passage |
|
||||
| `total_cleaned_area` | square meter | Total cleaned area in square meter |
|
||||
| `total_cleaning_time` | minutes | Total cleaning time in minutes |
|
||||
|
||||
### {% linkable_title Retrieving the Access Token %}
|
||||
|
||||
<p class='note'>
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ This method will require you to setup a developer account with Wink. This proces
|
|||
This form of authentication doesn't require any settings in the configuration.yaml other than `wink:` this is because you will be guided through setup via the configurator on the frontend.
|
||||
|
||||
<p class='note'>
|
||||
When using the configurator make sure the initial setup is performed on the same local network as the Home Assistant server, if not from the same box Home Assistant is running on. This will allow for authentication redirects to happen correctly.
|
||||
When using the configurator make sure the initial setup is performed on the same local network as the Home Assistant server, if not from the same box Home Assistant is running on. This will allow for authentication redirects to happen correctly.
|
||||
</p>
|
||||
|
||||
```yaml
|
||||
|
|
@ -79,7 +79,7 @@ Local control:
|
|||
|
||||
- Using local control doesn't appear to make commands any quicker, but does function in an internet/Wink outage.
|
||||
|
||||
- Local control is also only available for the Wink hub v1 and v2, not the Wink relay.
|
||||
- Local control is also only available for the Wink hub v1 and v2, not the Wink relay.
|
||||
|
||||
- Local control isn't used during start-up of Home Assistant; this means initial setup requires an active internet connection.
|
||||
|
||||
|
|
@ -98,15 +98,50 @@ Error sending local control request. Sending request online
|
|||
|
||||
### {% linkable_title Service `refresh_state_from_wink` %}
|
||||
|
||||
The Wink component only obtains the device states from the Wink API once, during startup. All updates after that are pushed via a third party called PubNub. On rare occasions where an update isn't pushed device states can be out of sync.
|
||||
The Wink component only obtains the device states from the Wink API once, during startup. All updates after that are pushed via a third party called PubNub. On rare occasions where an update isn't pushed device states can be out of sync.
|
||||
|
||||
You can use the service wink/refresh_state_from_wink to pull the most recent state from the Wink API for all devices. If `local_control` is set to `True` states will be pulled from the devices controlling hub, not the online API.
|
||||
|
||||
### {% linkable_title Service `add_new_devices` %}
|
||||
### {% linkable_title Service `pull_newly_added_devices_from_wink` %}
|
||||
|
||||
You can use the service wink/add_new_devices to pull any newly paired Wink devices to an already running instance of Home-Assistant. Any new devices will also be added if Home-Assistant is restarted.
|
||||
|
||||
### {% linkable_title Service `delete_wink_device` %}
|
||||
|
||||
You can use the service wink/delete_wink_device to remove/unpair a device from Wink.
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | no | String that points at the `entity_id` of device to delete.
|
||||
|
||||
### {% linkable_title Service `pair_new_device` %}
|
||||
|
||||
You can use the service wink/pair_new_device to pair a new device to your Wink hub/relay
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `hub_name` | no | The name of the hub to pair a new device to.
|
||||
| `pairing_mode` | no | One of the following [zigbee, zwave, zwave_exclusion, zwave_network_rediscovery, lutron, bluetooth, kidde]
|
||||
| `kidde_radio_code` | conditional | A string of 8 1s and 0s one for each dip switch on the kidde device left --> right = 1 --> 8 (Required if pairing_mode = kidde)
|
||||
|
||||
<p class='note'>
|
||||
The Wink hub, by default, can only be accessed via the cloud. This means it requires an active internet connection and you will experience delays when controlling and updating devices (~3s).
|
||||
Calling service wink/pull_newly_added_wink_devices after a device is paired will add that new device to Home Assistant. The device will also show up on the next restart of Home Assistant.
|
||||
</p>
|
||||
|
||||
### {% linkable_title Service `rename_wink_device` %}
|
||||
|
||||
You can use the service wink/rename_wink_device to change the name of a device.
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | no | String that points at the `entity_id` of device to rename.
|
||||
| `name` | no | The name to change it to.
|
||||
|
||||
<p class='note'>
|
||||
Home Assistant entity_ids for Wink devices are based on the Wink device's name. Calling this service will not change the entity_id of the deivce until Home Assistant is restarted.
|
||||
</p>
|
||||
|
||||
<p class='note'>
|
||||
The Wink hub, by default, can only be accessed via the cloud. This means it requires an active internet connection and you will experience delays when controlling and updating devices (~3s).
|
||||
</p>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue