Paulus Schoutsen
GitHub
commit
559cfe67c7
55 changed files with 1612 additions and 121 deletions
|
|
@ -18,3 +18,19 @@ The `spc` alarm control panel platform allows you to control your [Vanderbilt SP
|
|||
|
||||
The requirement is that you have setup your [SPC hub](/components/spc/).
|
||||
|
||||
The `changed_by` attribute enables one to be able to take different actions depending on who armed/disarmed the alarm in [automation](/getting-started/automation/).
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: Alarm status changed
|
||||
trigger:
|
||||
- platform: state
|
||||
entity_id: alarm_control_panel.alarm_1
|
||||
action:
|
||||
- service: notify.notify
|
||||
data_template:
|
||||
message: >
|
||||
{% raw %}Alarm changed from {{ trigger.from_state.state }}
|
||||
to {{ trigger.to_state.state }}
|
||||
by {{ trigger.to_state.attributes.changed_by }}{% endraw %}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -135,6 +135,13 @@ Custom slot type for scene support.
|
|||
|
||||
The names must exactly match the scene names (minus underscores - amazon discards them anyway and we later map them back in with the template).
|
||||
|
||||
In the new Alexa Skills Kit, you can also create synonyms for slot type values, which can be used in place of the base value in utterances. Synonyms will be replaced with their associated slot value in the intent request sent to the Alexa API endpoint, but only if there are not multiple synonym matches. Otherwise, the value of the synonym that was spoken will be used.
|
||||
|
||||
<p class='img'>
|
||||
<img src='/images/components/alexa/scene_slot_synonyms.png' />
|
||||
Custom slot values with synonyms.
|
||||
</p>
|
||||
|
||||
Add a sample utterance:
|
||||
|
||||
```text
|
||||
|
|
|
|||
|
|
@ -24,6 +24,7 @@ The way these sensors are displayed in the frontend can be modified in the [cust
|
|||
- **moving**: `On` means moving, `Off` means stopped
|
||||
- **occupancy**: `On` means occupied, `Off` means not occupied
|
||||
- **opening**: `On` means open, `Off` means closed
|
||||
- **plug**: `On` means device is plugged in, `Off` means device is unplugged
|
||||
- **power**: Power, over-current, etc.
|
||||
- **safety**: `On` means unsafe, `Off` means safe
|
||||
- **smoke**: `On` means smoke detected
|
||||
|
|
|
|||
|
|
@ -44,4 +44,47 @@ Configuration variables:
|
|||
- **invert_logic** (*Optional*): Inverts the input logic, default is `false`.
|
||||
- **device_class** (*Optional*): See device classes in [binary_sensor component](/components/binary_sensor/), default is `None`
|
||||
|
||||
## {% linkable_title Directions for installing smbus support on Raspberry Pi %}
|
||||
|
||||
Enable I2c interface with the Raspberry Pi configuration utility:
|
||||
|
||||
```bash
|
||||
# pi user environment: Enable i2c interface
|
||||
$ sudo raspi-config
|
||||
```
|
||||
|
||||
Select `Interfacing options->I2C` choose `<Yes>` and hit `Enter`, then go to `Finish`.
|
||||
|
||||
Install dependencies for use the `smbus-cffi` module and enable your _homeassistant_ user to join the _i2c_ group:
|
||||
|
||||
```bash
|
||||
# pi user environment: Install i2c dependencies and utilities
|
||||
$ sudo apt-get install build-essential libi2c-dev i2c-tools python-dev libffi-dev
|
||||
|
||||
# pi user environment: Add homeassistant user to the i2c group
|
||||
$ sudo usermod -a -G i2c homeassistant
|
||||
```
|
||||
|
||||
### {% linkable_title Check the i2c address of the sensor %}
|
||||
|
||||
After installing `i2c-tools`, a new utility is available to scan the addresses of the connected sensors, so you can see the sensor address:
|
||||
|
||||
```bash
|
||||
$ /usr/sbin/i2cdetect -y 1
|
||||
```
|
||||
|
||||
It will output a table like this:
|
||||
|
||||
```text
|
||||
0 1 2 3 4 5 6 7 8 9 a b c d e f
|
||||
00: -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- --
|
||||
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
40: 40 -- -- -- -- -- UU -- -- -- -- -- -- -- -- --
|
||||
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
70: -- -- -- -- -- -- -- 77
|
||||
```
|
||||
|
||||
For more details about the `raspihats` add-on boards for Raspberry PI, visit [raspihats.com](http://www.raspihats.com/).
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: 0.28
|
|||
ha_iot_class: "Local Push"
|
||||
---
|
||||
|
||||
The `trend` platform allows you to create sensors which show the trend of numeric `state` or`state_attributes` from other entities. This sensor requires two updates of the underlying sensor to establish a trend. Thus it can take some time to show an accurate state. It can be useful as part of automations, where you want to base an action on a trend.
|
||||
The `trend` platform allows you to create sensors which show the trend of numeric `state` or`state_attributes` from other entities. This sensor requires at least two updates of the underlying sensor to establish a trend. Thus it can take some time to show an accurate state. It can be useful as part of automations, where you want to base an action on a trend.
|
||||
|
||||
To enable Trend binary sensors in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
@ -29,39 +29,54 @@ binary_sensor:
|
|||
Configuration variables:
|
||||
|
||||
- **sensors** array (*Required*): List of your sensors.
|
||||
- **friendly_name** (*Optional*): Name to use in the Frontend.
|
||||
- **device_class** (*Optional*): The [type/class](/components/binary_sensor/) of the sensor to set the icon in the frontend.
|
||||
- **entity_id** (*Required*): The entity that this sensor tracks.
|
||||
- **attribute** (*Optional*): The attribute of the entity that this sensor tracks. If no attribute is specified then the sensor will track the state.
|
||||
- **invert** (*Optional*): Invert the result (so `true` means descending rather than ascending)
|
||||
- **device_class** (*Optional*): The [type/class](/components/binary_sensor/) of the sensor to set the icon in the frontend.
|
||||
- **friendly_name** (*Optional*): Name to use in the Frontend.
|
||||
- **invert** (*Optional*): Invert the result (so `true` means descending rather than ascending). Defaults to `False`
|
||||
- **max_samples** (*Optional*): Limit the maximum number of stored samples. Defaults to `2`.
|
||||
- **min_gradient** (*Optional*): The minimum rate at which the observed value must be changing for this sensor to switch on. Defaults to `0.0`
|
||||
- **sample_duration** (*Optional*): The duration **in seconds** to store samples for. Samples older than this value will be discarded. Defaults to `0`
|
||||
|
||||
## {% linkable_title Using Multiple Samples %}
|
||||
|
||||
If the optional `sample_duration` and `max_samples` parameters are specified then multiple samples can be stored and used to detect long-term trends.
|
||||
|
||||
Each time the state changes, a new sample is stored along with the sample time. Samples older than `sample_duration` seconds will be discarded.
|
||||
|
||||
A trend line is then fitted to the available samples, and the gradient of this line is compared to `min_gradient` to determine the state of the trend sensor. The gradient is measured in sensor units per second - so if you want to know when the temperature is falling by 2 degrees per hour, use a gradient of (-2) / (60 x 60) = -0.00055
|
||||
|
||||
The current number of stored samples is displayed on the States page.
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
In this section you find some real life examples of how to use this sensor.
|
||||
|
||||
### {% linkable_title Temperature trend %}
|
||||
|
||||
This example indicates `true` if the temperature is rising:
|
||||
This example indicates `true` if the sun is still rising:
|
||||
|
||||
```yaml
|
||||
binary_sensor:
|
||||
- platform: trend
|
||||
sensors:
|
||||
temperature_up:
|
||||
friendly_name: 'Temp increasing'
|
||||
entity_id: sensor.skylight_temperature
|
||||
sun_rising:
|
||||
entity_id: sun.sun
|
||||
```
|
||||
|
||||
This example creates two sensors to indicate whether the temperature is rising or falling at a rate of at least 3 degrees an hour, and collects samples over a two hour period:
|
||||
|
||||
```yaml
|
||||
binary_sensor:
|
||||
- platform: trend
|
||||
sensors:
|
||||
temp_falling:
|
||||
entity_id: sensor.outside_temperature
|
||||
sample_duration: 7200
|
||||
min_gradient: -0.0008
|
||||
device_class: cold
|
||||
|
||||
temp_rising:
|
||||
entity_id: sensor.outside_temperature
|
||||
sample_duration: 7200
|
||||
min_gradient: 0.0008
|
||||
device_class: heat
|
||||
```
|
||||
|
||||
And this one indicates `true` if the temperature is falling:
|
||||
|
||||
```yaml
|
||||
binary_sensor:
|
||||
- platform: trend
|
||||
sensors:
|
||||
temperature_down:
|
||||
friendly_name: 'Temp decreasing'
|
||||
entity_id: sensor.skylight_temperature
|
||||
device_class: cold
|
||||
invert: Yes
|
||||
```
|
||||
|
|
|
|||
54
source/_components/binary_sensor.vultr.markdown
Normal file
54
source/_components/binary_sensor.vultr.markdown
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Vultr Binary Sensor"
|
||||
description: "Instructions on how to set up Vultr binary sensors within Home Assistant."
|
||||
date: 2017-10-17 21:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: System Monitor
|
||||
logo: vultr.png
|
||||
ha_release: "0.58"
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
The `vultr` binary sensor platform allows you to monitor your [Vultr](https://www.vultr.com/) subscription to see if it is powered on or not.
|
||||
|
||||
To use this binary sensor, you first have to set up your [Vultr hub](/components/vultr/).
|
||||
|
||||
<p class='note'>
|
||||
The following examples assume a subscription that has an ID of `123456` and a label of `Web Server`
|
||||
</p>
|
||||
|
||||
Minimal `configuration.yaml` (produces `binary_sensor.vultr_web_server`):
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
binary_sensor:
|
||||
- platform: vultr
|
||||
subscription: 123456
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
subscription:
|
||||
description: The subscription you want to monitor, this can be found in the URL when viewing a server.
|
||||
required: true
|
||||
type: string
|
||||
name:
|
||||
description: The name you want to give this binary sensor.
|
||||
required: false
|
||||
default: "Vultr {subscription label}"
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
|
||||
Full `configuration.yaml` (produces `binary_sensor.totally_awesome_server`):
|
||||
|
||||
```yaml
|
||||
binary_sensor:
|
||||
- platform: vultr
|
||||
name: totally_awesome_server
|
||||
subscription: 12345
|
||||
```
|
||||
|
||||
|
|
@ -25,10 +25,11 @@ To use your KNX thermostats in your installation, add the following lines to you
|
|||
climate:
|
||||
- platform: knx
|
||||
name: HASS-Kitchen.Temperature
|
||||
temperature_address: '6/2/1'
|
||||
setpoint_address: '5/1/2'
|
||||
target_temperature_address: '5/1/1'
|
||||
operation_mode_address: '5/1/3'
|
||||
temperature_address: '5/1/1'
|
||||
setpoint_shift_address: '5/1/2'
|
||||
setpoint_shift_state_address: '5/1/3'
|
||||
target_temperature_address: '5/1/4'
|
||||
operation_mode_address: '5/1/5'
|
||||
```
|
||||
|
||||
Alternatively, if your device has dedicated binary group addresses for frost/night/comfort mode:
|
||||
|
|
@ -38,12 +39,13 @@ Alternatively, if your device has dedicated binary group addresses for frost/nig
|
|||
climate:
|
||||
- platform: knx
|
||||
name: HASS-Kitchen.Temperature
|
||||
temperature_address: '6/2/1'
|
||||
setpoint_address: '5/1/2'
|
||||
target_temperature_address: '5/1/1'
|
||||
operation_mode_frost_protection_address: '5/1/3'
|
||||
operation_mode_night_address: '5/1/4'
|
||||
operation_mode_comfort_address: '5/1/5'
|
||||
temperature_address: '5/1/1'
|
||||
setpoint_shift_address: '5/1/2'
|
||||
setpoint_shift_state_address: '5/1/3'
|
||||
target_temperature_address: '5/1/4'
|
||||
operation_mode_frost_protection_address: '5/1/5'
|
||||
operation_mode_night_address: '5/1/6'
|
||||
operation_mode_comfort_address: '5/1/7'
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
|
@ -51,7 +53,16 @@ Configuration variables:
|
|||
- **name** (*Optional*): A name for this device used within Home Assistant.
|
||||
- **temperature_address**: KNX group address for reading current room temperature from KNX bus.
|
||||
- **target_temperature_address**: KNX group address for reading current target temperature from KNX bus.
|
||||
- **setpoint_address**: KNX group address for basis setpoint
|
||||
|
||||
The `knx` component sets the desired target temperature by modifying the setpoint_shift. The module provides the following configuration options:
|
||||
|
||||
* **setpoint_shift_address**: (*Optional*) KNX address for setpoint_shift
|
||||
* **setpoint_shift_state_address**: (*Optional*) Explicit KNX address for reading setpoint_shift.
|
||||
* **setpoint_shift_step**: (*Optional*) Defines for step size in Kelvin for each step of setpoint_shift. Default is 0.5 K.
|
||||
* **setpoint_shift_min**: (*Optional*) Minimum value of setpoint shift. Default is "-6".
|
||||
* **setpoint_shift_max**: (*Optional*) Maximum value of setpoint shift. Default is "6".
|
||||
|
||||
The operation modes may be controlled with the following directives:
|
||||
|
||||
- **operation_mode_address** (*Optional*): KNX address for operation mode (Frost protection/night/comfort).
|
||||
- **operation_mode_state_address** (*Optional*): Explicit KNX address for reading operation mode
|
||||
|
|
@ -63,5 +74,3 @@ Configuration variables:
|
|||
- **operation_mode_comfort_address** (*Optional*): KNX address for switching on/off comfort mode.
|
||||
|
||||
`operation_mode_frost_protection_address` / `operation_mode_night_address` / `operation_mode_comfort_address` are not necessary if `operation_mode_address` was specified.
|
||||
|
||||
|
||||
|
|
|
|||
44
source/_components/device_tracker.hitron_coda.markdown
Normal file
44
source/_components/device_tracker.hitron_coda.markdown
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Hitron CODA Routers"
|
||||
description: "Instructions on how to integrate Hitron CODA Routers into Home Assistant."
|
||||
date: 2017-10-03 15:40
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: hitron.png
|
||||
ha_category: Presence Detection
|
||||
ha_release: 0.58
|
||||
---
|
||||
|
||||
This component offers presence detection by examining devices connected to a [Rogers Hitron CODA](https://www.rogers.com/customer/support/article/wi-fi-password-hitron-coda4582-cgn3amr-cgnm3552-cgn3acr-cgn3)
|
||||
Router.
|
||||
|
||||
To use a Hitron router in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
device_tracker:
|
||||
- platform: hitron_coda
|
||||
host: !secret router_ip
|
||||
username: !secret router_username
|
||||
password: !secret router_password
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
host:
|
||||
description: The IP address of your router, e.g., `192.168.0.1`.
|
||||
required: true
|
||||
type: string
|
||||
username:
|
||||
description: The username to login into the router (user should have read access to the web interface of the router). Usually "cusadmin".
|
||||
required: true
|
||||
type: string
|
||||
password:
|
||||
description: The password for the specified username. Usually your WiFi password.
|
||||
required: true
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
See the [device tracker component page](/components/device_tracker/) for instructions how to configure the people to be tracked.
|
||||
46
source/_components/device_tracker.tile.markdown
Normal file
46
source/_components/device_tracker.tile.markdown
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Tile"
|
||||
description: "Instructions how to use Tile to track devices in Home Assistant."
|
||||
date: 2017-11-08 20:40:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: tile.png
|
||||
ha_release: 0.58
|
||||
ha_category: Presence Detection
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
The `tile` platform allows Home Assistant to utilize [Tile® Bluetooth trackers](https://www.thetileapp.com).
|
||||
The official Tile mobile app handles the actual tracking of Tile devices using
|
||||
the mobile device's Bluetooh and GPS.
|
||||
|
||||
To integrate Tile into Home Assistant, add the following section to your
|
||||
`configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
device_tracker:
|
||||
- platform: tile
|
||||
username: email@address.com
|
||||
password: MY_PASSWORD_123
|
||||
monitored_variables:
|
||||
- TILE
|
||||
- PHONE
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
username:
|
||||
description: the email address for the Tile account
|
||||
required: true
|
||||
type: string
|
||||
password:
|
||||
description: the password for the Tile account
|
||||
required: true
|
||||
type: string
|
||||
monitored_variables:
|
||||
description: the Tile types to monitor; valid values are `TILE` and `PHONE` (default is for all types to be included)
|
||||
required: false
|
||||
type: list
|
||||
{% endconfiguration %}
|
||||
|
|
@ -38,7 +38,7 @@ This will download the file from the given URL.
|
|||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ---------------------------------------------- |
|
||||
| `url` | no | The url of the file to download. |
|
||||
| `url` | no | The URL of the file to download. |
|
||||
| `subdir` | yes | Download into subdirectory of **download_dir** |
|
||||
| `filename` | yes | Determine the filename. |
|
||||
|
||||
| `overwrite` | yes | Whether to overwrite the file or not, defaults to `false`. |
|
||||
|
|
|
|||
|
|
@ -19,6 +19,11 @@ frontend:
|
|||
```
|
||||
|
||||
{% configuration %}
|
||||
javascript_version:
|
||||
description: "Version of the JavaScript to serve to clients. Options: `es5` - transpiled so old browsers understand it. `latest` - not transpiled, so will work on recent browsers only. `auto` - select a version according to the browser user-agent. The value in the config can be overiden by putting `es5` or `latest` in the URL. For example `http://localhost:8123/states?es5` "
|
||||
required: false
|
||||
type: string
|
||||
default: es5
|
||||
themes:
|
||||
description: Allow to define different themes. See below for further details.
|
||||
required: false
|
||||
|
|
|
|||
|
|
@ -28,6 +28,8 @@ google_assistant:
|
|||
project_id: someproject-2d0b8
|
||||
client_id: [long URL safe random string]
|
||||
access_token: [a different long URL safe random string]
|
||||
agent_user_id: [a string to identify user]
|
||||
api_key: [an API Key generated for the Google Actions project]
|
||||
exposed_domains:
|
||||
- switch
|
||||
- light
|
||||
|
|
@ -43,6 +45,8 @@ google_assistant:
|
|||
* *project_id* (Required): Project ID from the Google Developer console (looks like `words-2ab12`)
|
||||
* *client_id* (Required): A long random URL safe string (no spaces or special characters) that will be used for Implicit OAuth.
|
||||
* *access_token* (Required): Another different long random URL safe string.
|
||||
* *agent_user_id* (Optional): A string to identify the user, e.g., email address. If not provided, the component will generate one.
|
||||
* *api_key* (Optional): An API Key generated for the project from Google Console. See setup below. If not provided then the request_sync service is not exposed
|
||||
* *exposed_domains* (Optional): An array of Home Assistant domains to expose to Google Assistant. Options include:
|
||||
- `switch`
|
||||
- `light`
|
||||
|
|
@ -123,3 +127,10 @@ homeassistant:
|
|||
2. Under the gear icon, click `Permissions`
|
||||
3. Click `Add`, type the new user's e-mail address and choose `Project -> Editor` role
|
||||
4. Have the new user go to [developer console](https://console.actions.google.com/) and repeat steps starting from point 7.
|
||||
11. If you want to use the request_sync service in Home Assistant, then Enable Homegraph API for your project:
|
||||
1. Go to https://console.cloud.google.com/apis/api/homegraph.googleapis.com/overview
|
||||
2. Select your project and click Enable Homegraph API
|
||||
3. Go to Credentials and select API Key from Create Credentials
|
||||
4. Note down the generated API Key and use this in the configuration
|
||||
|
||||
*Note:* The request_sync service requires that the initial sync from Google includes the agent_user_id. If not, the service will log an error that reads something like "Request contains an invalid argument". If this happens, then unlink the account from Home Control and relink.
|
||||
|
|
|
|||
|
|
@ -18,6 +18,10 @@ The [KNX](http://www.knx.org) integration for Home Assistant allows you to conne
|
|||
|
||||
The component requires a local KNX/IP interface like the [Weinzierl 730](http://www.weinzierl.de/index.php/en/all-knx/knx-devices-en/knx-ip-interface-730-en). Through this, it will send and receive commands to and from other devices to the KNX bus.
|
||||
|
||||
<p class='note warning'>
|
||||
Please note, the `knx` platform does not support Windows and needs at least python version 3.5.
|
||||
</p>
|
||||
|
||||
There is currently support for the following device types within Home Assistant:
|
||||
|
||||
- [Binary Sensor](/components/binary_sensor.knx)
|
||||
|
|
|
|||
|
|
@ -15,14 +15,19 @@ ha_iot_class: "Cloud Polling"
|
|||
|
||||
The `linode` component allows you to access the information about your [Linode](https://linode.com) systems from Home Assistant.
|
||||
|
||||
Obtain your API key from Linode account.
|
||||
Obtain your oAuth2 Access Token from Linode account.
|
||||
* <http://cloud.linode.com>
|
||||
* Log in
|
||||
* Select API Tokens
|
||||
* Create a Personal Access Token,
|
||||
* Assigned scope (Please choose the least possible access required.)
|
||||
|
||||
To integrate Linode with Home Assistant, add the following section to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
linode:
|
||||
access_token: YOUR_API_KEY
|
||||
access_token: YOUR_ACCESS_TOKEN
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
|
|
@ -31,4 +36,3 @@ linode:
|
|||
required: true
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
|
|
|
|||
|
|
@ -27,17 +27,25 @@ The currently supported Caseta devices are:
|
|||
|
||||
When configured, the `lutron_caseta` component will automatically discover the currently supported devices as setup in the Lutron Smart Bridge. The name assigned in the Lutron mobile app will be used to form the `entity_id` used in Home Assistant. e.g. a dimmer called 'Bedroom Lamp' becomes `light.bedroom_lamp` in Home Assistant.
|
||||
|
||||
To use Lutron Caseta devices in your installation, add the following to your `configuration.yaml` file using the IP of your Smart Bridge:
|
||||
To use Lutron Caseta devices in your installation, you must first log in to your Lutron account and generate a certificate that allows Home Assistant to connect to your bridge. This can be accomplished by downloading and executing [this script](/assets/get_lutron_cert.zip), which will generate three files: caseta.key, caseta.crt, caseta-bridge.crt when you run it. See the instructions at the top of the script for more information.
|
||||
|
||||
Once you have the three necessary files, place them in your configuration directory and add the following to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
lutron_caseta:
|
||||
host: IP_ADDRESS
|
||||
keyfile: caseta.key
|
||||
certfile: caseta.crt
|
||||
ca_certs: caseta-bridge.crt
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **host** (*Required*): The IP address of the Lutron Smart Bridge.
|
||||
- **keyfile** (*Required*): The private key that Home Assistant will use to authenticate to the bridge.
|
||||
- **certfile** (*Required*): The certificate chain that Home Assistant will use to authenticate to the bridge.
|
||||
- **ca_certs** (*Required*): The list of certificate authorities (usually only one) that Home Assistant will expect when connecting to the bridge.
|
||||
|
||||
<p class='note'>
|
||||
It is recommended to assign a static IP address to your Lutron Smart Bridge. This ensures that it won't change IP address, so you won't have to change the `host` if it reboots and comes up with a different IP address.
|
||||
|
|
|
|||
|
|
@ -51,18 +51,26 @@ Configuration variables:
|
|||
|
||||
- **name** (*Required*): The name to assign the player
|
||||
- **children** (*Required*): Ordered list of child media players this entity will control
|
||||
- **state_template** (*Optional*): A [template](/topics/templating/) can be specified to render the state of the media player. This way, the state could depend on entities different from media players, like Switches or Input Booleans.
|
||||
- **commands** (*Optional*): Commands to be overwritten. Possible entries are *turn_on*, *turn_off*, *select_source*, *volume_set*, *volume_up*, *volume_down*, and *volume_mute*.
|
||||
- **attributes** (*Optional*): Attributes that can be overwritten. Possible entries are *is_volume_muted*, *state*, *source*, *source_list, and *volume_level*. The values should be an entity id and state attribute separated by a bar (\|). If the entity id's state should be used, then only the entity id should be provided.
|
||||
|
||||
The universal media player will primarily imitate one of its *children*. The first child in the list that is active (not idle/off) will be controlled the universal media player. The universal media player will also inherit its state from the first active child. Entities in the *children* list must be media players.
|
||||
The Universal Media Player will primarily imitate one of its *children*. The Universal Media Player will control the first child on the list that is active (not idle/off). The Universal Media Player will also inherit its state from the first active child if a `state_template` is not provided. Entities in the *children* list must be media players, but the state template can contain any entity.
|
||||
|
||||
It is recommended that the command *turn_on*, the command *turn_off*, and the attribute *state* all be provided together. The *state* attribute indicates if the Media Player is on or off. If *state* indicates the media player is off, this status will take precedent over the states of the children. If all the children are idle/off and *state* is on, the universal media player's state will be on.
|
||||
It is recommended that the command *turn_on*, the command *turn_off*, and the attribute *state* all be provided together. The *state* attribute indicates if the Media Player is on or off. If *state* indicates the media player is off, this status will take precedence over the states of the children. If all the children are idle/off and *state* is on, the Universal Media Player's state will be on.
|
||||
|
||||
It is also recommended that the command *volume_up*, the command *volume_down*, the command *volume_mute*, and the attribute *is_volume_muted* all be provided together. The attribute *is_volume_muted* should return either True or the on state when the volume is muted. The *volume_mute* service should toggle the mute setting.
|
||||
|
||||
When providing *select_source* as a command, it is recommended to also provide the attributes *source*, and *source_list*. The *source* attribute is the currently select source, while the *source_list* attribute is a list of all available sources.
|
||||
|
||||
Below is an example configuration.
|
||||
## {% linkable_title Usage examples %}
|
||||
|
||||
#### {% linkable_title Chromecast & Kodi control with switches %}
|
||||
|
||||
In this example, a switch is available to control the power of the television. Switches are also available to turn the volume up, turn the volume down, and mute the audio. These could be command line switches or any other entity in Home Assistant. The *turn_on* and *turn_off* commands will be redirected to the television, and the volume commands will be redirected to an audio receiver. The *select_source* command will be passed directly to an A/V receiver.
|
||||
|
||||
The children are a Chromecast and a Kodi player. If the Chromecast is playing, the Universal Media Player will reflect its status. If the Chromecast is idle and Kodi is playing, the Universal Media player will change to reflect its status.
|
||||
|
||||
|
||||
```yaml
|
||||
media_player:
|
||||
|
|
@ -112,6 +120,107 @@ media_player:
|
|||
|
||||
```
|
||||
|
||||
In this example, a switch is available to control the power of the television. Switches are also available to turn the volume up, turn the volume down, and mute the audio. These could be command line switches or any other entity in Home Assistant. The *turn_on* and *turn_off* commands will be redirected to the television and the volume commands will be redirected to an audio receiver. The *select_source* command will be passed directly to an A/V receiver.
|
||||
#### {% linkable_title Kodi CEC-TV control %}
|
||||
|
||||
The children are a Chromecast and a Kodi player. If the Chromecast is playing, the Universal Media Player will reflect its status. If the Chromecast is idle and Kodi is playing, the Universal Media player will change to reflect its status.
|
||||
In this example, a [Kodi Media Player](/components/media_player.kodi/) runs in a CEC capable device (OSMC/OpenElec running in a Raspberry Pi 24/7, for example), and, with the JSON-CEC Kodi addon installed, it can turn on and off the attached TV.
|
||||
|
||||
We store the state of the attached TV in a hidden [Input Boolean](/components/input_boolean/), so we can differentiate the TV being on or off, while Kodi is always 'idle', and use the Universal Media Player to render its state with a template. We can hide the Kodi Media Player too, and only show the universal one, which now can differentiate between the 'idle' and the 'off' state (being the second when it is idle and the TV is off).
|
||||
|
||||
Because the Input Boolean used to store the TV state is only changing when using the Home Assistant `turn_on` and `turn_off` actions, and Kodi could be controlled by so many ways, we also define some automations to update this Input Boolean when needed.
|
||||
|
||||
In an Apple HomeKit scene, we can now expose this Universal Media Player as an on/off switch in Homebridge, and, that way, use Siri to turn on and off the TV.
|
||||
|
||||
The complete yaml config is:
|
||||
|
||||
```yaml
|
||||
homeassistant:
|
||||
customize:
|
||||
input_boolean.kodi_tv_state:
|
||||
hidden: true
|
||||
homebridge_hidden: true
|
||||
media_player.kodi:
|
||||
hidden: true
|
||||
homebridge_hidden: true
|
||||
media_player.kodi_tv:
|
||||
friendly_name: Kodi
|
||||
homebridge_name: Kodi
|
||||
homebridge_media_player_switch: on_off
|
||||
|
||||
input_boolean:
|
||||
kodi_tv_state:
|
||||
|
||||
media_player:
|
||||
- platform: universal
|
||||
name: Kodi TV
|
||||
state_template: >
|
||||
{% raw %}{% if (is_state('media_player.kodi', 'idle') and (is_state('input_boolean.kodi_tv_state', 'off') %}
|
||||
off
|
||||
{% else %}
|
||||
{{ states('media_player.kodi') }}
|
||||
{% endif %}{% endraw %}
|
||||
children:
|
||||
- media_player.kodi
|
||||
commands:
|
||||
turn_on:
|
||||
service: media_player.turn_on
|
||||
data:
|
||||
entity_id: media_player.kodi
|
||||
turn_off:
|
||||
service: media_player.turn_off
|
||||
data:
|
||||
entity_id: media_player.kodi
|
||||
attributes:
|
||||
is_volume_muted: media_player.kodi|is_volume_muted
|
||||
volume_level: media_player.kodi|volume_level
|
||||
|
||||
- platform: kodi
|
||||
name: Kodi
|
||||
host: 192.168.1.10
|
||||
turn_on_action:
|
||||
- service: input_boolean.turn_on
|
||||
data:
|
||||
entity_id: input_boolean.kodi_tv_state
|
||||
- service: media_player.kodi_call_method
|
||||
data:
|
||||
entity_id: media_player.kodi
|
||||
method: Addons.ExecuteAddon
|
||||
addonid: script.json-cec
|
||||
params:
|
||||
command: activate
|
||||
turn_off_action:
|
||||
- service: input_boolean.turn_off
|
||||
data:
|
||||
entity_id: input_boolean.kodi_tv_state
|
||||
- service: media_player.media_stop
|
||||
data:
|
||||
entity_id: media_player.kodi
|
||||
- service: media_player.kodi_call_method
|
||||
data:
|
||||
entity_id: media_player.kodi
|
||||
method: Addons.ExecuteAddon
|
||||
addonid: script.json-cec
|
||||
params:
|
||||
command: standby
|
||||
|
||||
automation:
|
||||
- alias: Turn on the TV when Kodi is activated
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: media_player.kodi_tv
|
||||
from: 'off'
|
||||
to: 'playing'
|
||||
action:
|
||||
- service: media_player.turn_on
|
||||
entity_id: media_player.kodi_tv
|
||||
|
||||
- alias: Turn off the TV when Kodi is in idle > 15 min
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: media_player.kodi_tv
|
||||
to: 'idle'
|
||||
for:
|
||||
minutes: 15
|
||||
action:
|
||||
- service: media_player.turn_off
|
||||
entity_id: media_player.kodi_tv
|
||||
```
|
||||
|
|
|
|||
|
|
@ -32,6 +32,12 @@ Configuration variables:
|
|||
Default is false.
|
||||
- **publish_timestamps** (*Optional*): Publish the last_changed and last_updated timestamps for the entity.
|
||||
Default is false.
|
||||
- **exclude** (*Optional*): Configure which components should be excluded from recordings. See *Include/Exclude* section below for details.
|
||||
- **entities** (*Optional*): The list of entity ids to be excluded from recordings.
|
||||
- **domains** (*Optional*): The list of domains to be excluded from recordings.
|
||||
- **include** (*Optional*): Configure which components should be included in recordings. If set, all other entities will not be recorded.
|
||||
- **entities** (*Optional*): The list of entity ids to be included from recordings.
|
||||
- **domains** (*Optional*): The list of domains to be included from recordings.
|
||||
|
||||
## Operation
|
||||
|
||||
|
|
@ -44,6 +50,56 @@ For example, with the example configuration above, if an entity called 'light.ma
|
|||
|
||||
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`.
|
||||
|
||||
All states and attributes are passed through JSON serialization before publishing. **Please note** that this causes strings to be quoted (e.g., the string 'on' will be published as '"on"'). You can access the JSON deserialized values (as well as unquoted strings) at many places by using `value_json` instead of `value`.
|
||||
All states and attributes are passed through JSON serialization before publishing. **Please note** that this causes strings to be quoted (e.g., the string 'on' will be published as '"on"'). You can access the JSON deserialized values (as well as unquoted strings) at many places by using `value_json` instead of `value`.
|
||||
|
||||
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`.
|
||||
|
||||
## Include/exclude
|
||||
|
||||
The **exclude** and **include** configuration variables can be used to filter the items that are published to MQTT.
|
||||
|
||||
1\. If neither **exclude** or **include** are specified, all entities are published.
|
||||
|
||||
2\. If only **exclude** is specified, then all entities except the ones listed are published.
|
||||
|
||||
```yaml
|
||||
# Example of excluding entities
|
||||
mqtt_statestream:
|
||||
base_topic: homeassistant
|
||||
exclude:
|
||||
domains:
|
||||
- switch
|
||||
entities:
|
||||
- sensor.nopublish
|
||||
```
|
||||
In the above example, all entities except for *switch.x* and *sensor.nopublish* will be published to MQTT.
|
||||
|
||||
3\. If only **include** is specified, then only the specified entries are published.
|
||||
|
||||
```yaml
|
||||
# Example of excluding entities
|
||||
mqtt_statestream:
|
||||
base_topic: homeassistant
|
||||
include:
|
||||
domains:
|
||||
- sensor
|
||||
entities:
|
||||
- lock.important
|
||||
```
|
||||
In this example, only *sensor.x* and *lock.important* will be published.
|
||||
|
||||
4\. If both **include** and **exclude** are specified then all entities specified by **include** are published except for the ones
|
||||
specified by **exclude**.
|
||||
|
||||
```yaml
|
||||
# Example of excluding entities
|
||||
mqtt_statestream:
|
||||
base_topic: homeassistant
|
||||
include:
|
||||
domains:
|
||||
- sensor
|
||||
exclude:
|
||||
entities:
|
||||
- sensor.noshow
|
||||
```
|
||||
In this example, all sensors except for *sensor.noshow* will be published.
|
||||
|
|
|
|||
|
|
@ -156,6 +156,35 @@ homeassistant:
|
|||
```
|
||||
</p>
|
||||
|
||||
### {% linkable_title Video support %}
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
service: notify.NOTIFIER_NAME
|
||||
data:
|
||||
title: Send a video
|
||||
message: That's an example that sends a video.
|
||||
data:
|
||||
video:
|
||||
- url: http://192.168.1.28/camera.mp4
|
||||
username: admin
|
||||
password: secrete
|
||||
- file: /tmp/video.mp4
|
||||
caption: Video Title xy
|
||||
- url: http://somebla.ie/video.mp4
|
||||
caption: I.e. for a Title
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **url** or **file** (*Required*): For local or remote path to a video.
|
||||
- **caption** (*Optional*): The title of the video.
|
||||
- **username** (*Optional*): Username for a URL which require HTTP authentication.
|
||||
- **password** (*Optional*): Username for a URL which require HTTP authentication.
|
||||
- **authentication** (*Optional*): Set to 'digest' to use HTTP digest authentication, defaults to 'basic'.
|
||||
- **keyboard** (*Optional*): List of rows of commands, comma-separated, to make a custom keyboard.
|
||||
- **inline_keyboard** (*Optional*): List of rows of commands, comma-separated, to make a custom inline keyboard with buttons with associated callback data.
|
||||
|
||||
### {% linkable_title Document support %}
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ recorder:
|
|||
|
||||
Configuration variables:
|
||||
|
||||
- **purge_interval** (*Optional*): (days) Enable scheduled purge of older events and states. The purge task runs every x days, starting from when Home Assistant is started. If you restart your instance more frequently, than the purge will never take place. You can use [service](#service-purge) call `recorder.purge` when needed.
|
||||
- **purge_interval** (*Optional*): (days) Enable scheduled purge of older events and states. The purge task runs every x days from when the `recorder component` is first enabled. If a scheduled purge is missed (e.g. if Home Assistant was not running) then the schedule will resume soon after Home Assistant restarts. You can use [service](#service-purge) call `recorder.purge` when required without impacting the purge schedule.
|
||||
- **purge_keep_days** (*Required with `purge_interval`*): Specify number of history days to keep in recorder database after purge.
|
||||
- **exclude** (*Optional*): Configure which components should be excluded from recordings.
|
||||
- **entities** (*Optional*): The list of entity ids to be excluded from recordings.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ sharing: true
|
|||
footer: true
|
||||
logo: logitech.png
|
||||
ha_category: Remote
|
||||
ha_iot_class: "Local Polling"
|
||||
ha_iot_class: "Local Push"
|
||||
ha_release: "0.34"
|
||||
---
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ Configuration variables:
|
|||
- **host** (*Optional*): The Harmony device's IP address. Leave empty for the IP to be discovered automatically.
|
||||
- **port** (*Optional*): The Harmony device's port. Defaults to 5222.
|
||||
- **activity** (*Optional*): Activity to use when turnon service is called without any data.
|
||||
- **scan_interval** (*Optional*): Amount in seconds in between polling for device's current activity. Defaults to 30 seconds.
|
||||
- **delay_secs** (*Optional*): Default duration in seconds between sending commands to a device.
|
||||
|
||||
Configuration file:
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ Upon startup one file will be written to your Home Assistant configuration direc
|
|||
Supported services:
|
||||
|
||||
- **Turn Off**: Turn off all devices that were switched on from the start of the current activity.s
|
||||
- **Turn On**: Start an activity, will start the default activity from configuration.yaml if no activity is specified. The specified activity can either be the activity name or the activity ID from the configuration file written to your [Home Assistant configuration directory](/docs/configuration/). The service will respond faster if the activity ID is passed instead of the name.
|
||||
- **Turn On**: Start an activity, will start the default activity from configuration.yaml if no activity is specified. The specified activity can either be the activity name or the activity ID from the configuration file written to your [Home Assistant configuration directory](/docs/configuration/).
|
||||
- **Send Command**: Send a single command or a set of commands to one device, device ID and available commands are written to the configuration file at startup. You can optionally specify the number of times you wish to repeat the command(s) and delay you want between repeated command(s).
|
||||
- **Sync**: Synchronizes the Harmony device with the Harmony web service if any changes are made from the web portal or app.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@ sensor:
|
|||
- last_capture
|
||||
- total_cameras
|
||||
- battery_level
|
||||
- signal_strength
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
|
@ -35,5 +36,6 @@ Configuration variables:
|
|||
- **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.
|
||||
- **signal_strength**: Return the wireless signal strength of your Arlo camera.
|
||||
|
||||
If no **monitored_conditions** are specified, all of above will be enabled by default.
|
||||
|
|
|
|||
99
source/_components/sensor.lacrosse.markdown
Normal file
99
source/_components/sensor.lacrosse.markdown
Normal file
|
|
@ -0,0 +1,99 @@
|
|||
---
|
||||
layout: page
|
||||
title: "LaCrosse Sensor"
|
||||
description: "Instructions how to integrate LaCrosse sensor data received from Jeelink into Home Assistant."
|
||||
date: 2017-10-29 15:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: home-assistant.png
|
||||
ha_category: Sensor
|
||||
ha_release: 0.58
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
The `lacrosse` sensor platform is using the data provided by a [Jeelink](https://www.digitalsmarties.net/products/jeelink) USB dongle or this [Arduino sketch](https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip).
|
||||
|
||||
#### {% linkable_title Tested Devices %}
|
||||
|
||||
- Technoline TX 29 IT (temperature only)
|
||||
- Technoline TX 29 DTH-IT (including humidity)
|
||||
|
||||
## {% linkable_title Setup %}
|
||||
|
||||
Since the sensor change their ID after each powercycle/battery change you can check what sensor IDs are availble by using the command-line tool `pylacrosse` from the pylacrosse package.
|
||||
|
||||
```bash
|
||||
$ sudo pylacrosse -D /dev/ttyUSB0 scan
|
||||
```
|
||||
To use your `lacrosse` compatible sensor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: lacrosse
|
||||
sensors:
|
||||
sensor_identifier:
|
||||
type: SENSOR_TYPE
|
||||
id: SENSOR_ID
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
device:
|
||||
description: The serial baudrate.
|
||||
required: true
|
||||
type: string
|
||||
default: /dev/ttyUSB0
|
||||
baud:
|
||||
description: The serial baudrate.
|
||||
required: true
|
||||
type: int
|
||||
default: 57600
|
||||
sensors:
|
||||
description: A list of your sensors.
|
||||
required: true
|
||||
type: map
|
||||
keys:
|
||||
name:
|
||||
description: The name of the sensor.
|
||||
required: false
|
||||
type: string
|
||||
type:
|
||||
description: "The type of the sensor. Options: `battery`, `humidity`, `temperature`"
|
||||
required: true
|
||||
type: string
|
||||
id:
|
||||
description: The LaCrosse Id of the sensor.
|
||||
required: true
|
||||
type: int
|
||||
{% endconfiguration %}
|
||||
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
To setup a lacrosse sensor with multiple sensors, add the following to your `configuration.yaml` file:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: lacrosse
|
||||
device: /dev/ttyUSB0
|
||||
baud: 57600
|
||||
sensors:
|
||||
kitchen_humidity:
|
||||
name: Kitchen Humidity
|
||||
type: humidity
|
||||
id: 72
|
||||
kitchen_temperature:
|
||||
name: Kitchen Temperature
|
||||
type: temperature
|
||||
id: 72
|
||||
kitchen_lacrosse_battery:
|
||||
name: Kitchen Sensor Battery
|
||||
type: battery
|
||||
id: 72
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
|
|
@ -49,13 +49,15 @@ Configuration variables:
|
|||
- **name** (*Required*): Name of the sensor.
|
||||
- **slave** (*Required*): The number of the slave (Optional for tcp and upd Modbus).
|
||||
- **register** (*Required*): Register number.
|
||||
- **register_type** (*Optional*): Modbus register type (holding, input), default holding
|
||||
- **register_type** (*Optional*): Modbus register type (holding, input), default holding.
|
||||
- **unit_of_measurement** (*Optional*): Unit to attach to value.
|
||||
- **count** (*Optional*): Number of registers to read.
|
||||
- **scale** (*Optional*): Scale factor (output = scale * value + offset), default 1
|
||||
- **offset** (*Optional*): Final offset (output = scale * value + offset), default 0
|
||||
- **precision** (*Optional*): Number of valid decimals, default 0
|
||||
- **data_type** (*Optional*): Response representation (int, float). If float selected, value will be converted to IEEE 754 floating point format. default int
|
||||
- **reverse_order** (*Optional*): Reverse the order of registers when count >1, default False.
|
||||
- **scale** (*Optional*): Scale factor (output = scale * value + offset), default 1.
|
||||
- **offset** (*Optional*): Final offset (output = scale * value + offset), default 0.
|
||||
- **precision** (*Optional*): Number of valid decimals, default 0.
|
||||
- **data_type** (*Optional*): Response representation (int, uint, float, custom). If float selected, value will be converted to IEEE 754 floating point format. Default int.
|
||||
- **structure** (*Optional*): If data_type is custom specify here a double quoted python struct format string to unpack the value. See python documentation for details. Ex: ">i".
|
||||
|
||||
It's possible to change the default 30 seconds scan interval for the sensor updates as shown in the [Platform options](/docs/configuration/platform_options/#scan-interval) documentation.
|
||||
|
||||
|
|
@ -72,7 +74,6 @@ sensor:
|
|||
slave: 10
|
||||
register: 0
|
||||
register_type: holding
|
||||
update_interval: 2.5
|
||||
unit_of_measurement: °C
|
||||
count: 1
|
||||
scale: 0.1
|
||||
|
|
|
|||
39
source/_components/sensor.pyload.markdown
Normal file
39
source/_components/sensor.pyload.markdown
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
---
|
||||
layout: page
|
||||
title: "pyLoad Sensor"
|
||||
description: "Instructions how to integrate pyLoad download sensor within Home Assistant."
|
||||
date: 2017-10-23 09:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: pyload.png
|
||||
ha_category: Downloading
|
||||
ha_release: 0.58
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
|
||||
The `pyload` platform allows you to monitor your downloads with [pyLoad](https://pyload.net/) from within Home Assistant and setup automation based on the information.
|
||||
|
||||
To enable this sensor, add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: pyload
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **host** (*Optional*): This is the IP address of your pyLoad download manager, eg. 192.168.0.100. Defaults to `localhost`.
|
||||
- **port** (*Optional*): The port your pyLoad interface uses. Defaults to 8000.
|
||||
- **name** (*Optional*): The name to use when displaying this pyLoad instance.
|
||||
- **username** (*Optional*): Your pyLoad username.
|
||||
- **password** (*Optional*): Your pyLoad password.
|
||||
|
||||
If everything is setup correctly, the download speed will show up in the frontend.
|
||||
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/components/pyload/pyload_speed.png' />
|
||||
</p>
|
||||
|
|
@ -31,14 +31,23 @@ sensor:
|
|||
```
|
||||
|
||||
{% configuration %}
|
||||
serial_port:
|
||||
description: Local serial port where the sensor is connected and access is granted.
|
||||
required: true
|
||||
type: string
|
||||
name:
|
||||
description: Friendly name to use for the frontend. Default to "Serial sensor".
|
||||
required: false
|
||||
type: string
|
||||
serial_port:
|
||||
description: Local serial port where the sensor is connected and access is granted.
|
||||
required: true
|
||||
type: string
|
||||
name:
|
||||
description: Friendly name to use for the frontend. Default to "Serial sensor".
|
||||
required: false
|
||||
type: string
|
||||
baudrate:
|
||||
description: Baudrate of the serial port.
|
||||
required: false
|
||||
default: 9600 Bps
|
||||
type: int
|
||||
value_template:
|
||||
description: "Defines a [template](/docs/configuration/templating/#processing-incoming-data) to extract a value from the serial line."
|
||||
required: false
|
||||
type: template
|
||||
{% endconfiguration %}
|
||||
|
||||
|
||||
|
|
@ -52,4 +61,35 @@ sensor:
|
|||
```
|
||||
{% endraw %}
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
### {% linkable_title Arduino %}
|
||||
|
||||
For controllers of the Arduino family a possible sketch to read the temperature and the humidity could look like the sample below.
|
||||
|
||||
```
|
||||
#include <ArduinoJson.h>
|
||||
|
||||
void setup() {
|
||||
Serial.begin(115200);
|
||||
}
|
||||
|
||||
void loop() {
|
||||
StaticJsonBuffer<100> jsonBuffer;
|
||||
JsonObject& json = prepareResponse(jsonBuffer);
|
||||
json.printTo(Serial);
|
||||
Serial.println();
|
||||
delay(2000);
|
||||
}
|
||||
|
||||
JsonObject& prepareResponse(JsonBuffer& jsonBuffer) {
|
||||
JsonObject& root = jsonBuffer.createObject();
|
||||
root["temperature"] = analogRead(A0);
|
||||
root["humidity"] = analogRead(A1);
|
||||
return root;
|
||||
}
|
||||
```
|
||||
|
||||
### {% linkable_title Digispark USB Development Board %}
|
||||
|
||||
This [blog post](/blog/2017/10/23/simple-analog-sensor/) describes the setup with a Digispark USB Development Board.
|
||||
|
|
|
|||
62
source/_components/sensor.viaggiatreno.markdown
Normal file
62
source/_components/sensor.viaggiatreno.markdown
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
layout: page
|
||||
title: "ViaggiaTreno Italian Railroads"
|
||||
description: "Instructions on how to integrate Italian Railroads data (from ViaggiaTreno API) into Home Assistant."
|
||||
date: 2017-11-07 14:35
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: train.png
|
||||
ha_category: Transport
|
||||
ha_iot_class: "Cloud Polling"
|
||||
ha_release: 0.58
|
||||
---
|
||||
|
||||
The `viaggiatreno` sensor will give you information about configured train ids and stations using the public [ViaggiaTreno](http://viaggiatreno.it) API.
|
||||
|
||||
To activate the sensor you need at least two parameters: the `train_id` and the `station_id`.
|
||||
|
||||
The first is available just looking at the [ViaggiaTreno](http://viaggiatreno.it/) timetable, the latter can be obtained using the dedicated API endpoint:
|
||||
`http://www.viaggiatreno.it/viaggiatrenonew/resteasy/viaggiatreno/autocompletaStazione/<Station name>`
|
||||
(e.g., `http://www.viaggiatreno.it/viaggiatrenonew/resteasy/viaggiatreno/autocompletaStazione/ROMA` will list all station names (with ids) that starts with *ROMA*).
|
||||
|
||||
<p class='note'>
|
||||
Note that the `station_id` is referred to the train's **departing station**. If a train number does not match with the station id, no data will be returned to the sensor.
|
||||
</p>
|
||||
|
||||
Then add the data to your `configuration.yaml` file as shown in the example:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: viaggiatreno
|
||||
train_id: 12279
|
||||
station_id: S08409
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
train_id:
|
||||
description: The ID of the train.
|
||||
required: true
|
||||
type: int
|
||||
station_id:
|
||||
description: The ID of the starting station.
|
||||
required: true
|
||||
type: int
|
||||
train_name:
|
||||
description: The name of the sensor. Defaults to 'Train <train id> from <station id>'.
|
||||
required: false
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
<p class='note'>
|
||||
In a future implementation, the station name could be used to automatically search best-matching station id, without the need to specify it.
|
||||
</p>
|
||||
|
||||
The public timetables are coming from [ViaggiaTreno](http://viaggiatreno.it).
|
||||
|
||||
<p class='note'>
|
||||
Instructions (in Italian) for the API are available at:
|
||||
https://github.com/bluviolin/TrainMonitor/wiki/API-del-sistema-Viaggiatreno
|
||||
</p>
|
||||
76
source/_components/sensor.vultr.markdown
Normal file
76
source/_components/sensor.vultr.markdown
Normal file
|
|
@ -0,0 +1,76 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Vultr Sensor"
|
||||
description: "Instructions on how to integrate Vultr sensor within Home Assistant."
|
||||
date: 2017-10-17 21:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: vultr.png
|
||||
ha_release: "0.58"
|
||||
ha_category: System Monitor
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `vultr` sensor platform will allow you to view current bandwidth usage and pending charges against your [Vultr](https://www.vultr.com/) subscription.
|
||||
|
||||
To use this sensor, you must set up your [Vultr hub](/components/vultr/).
|
||||
|
||||
<p class='note'>
|
||||
The following examples assume a subscription that has an ID of `123456` and a label of `Web Server`
|
||||
</p>
|
||||
|
||||
Minimal `configuration.yaml` (produces `sensor.vultr_web_server_current_bandwidth_used` and `sensor.vultr_web_server_pending_charges`):
|
||||
|
||||
```yaml
|
||||
sensor:
|
||||
- platform: vultr
|
||||
subscription: 123456
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
subscription:
|
||||
description: The Vultr subscription to monitor, this can be found in the URL when viewing a subscription.
|
||||
required: true
|
||||
type: string
|
||||
name:
|
||||
description: The name to give this sensor.
|
||||
required: false
|
||||
default: "Vultr {Vultr subscription label} {monitored condition name}"
|
||||
type: string
|
||||
monitored_conditions:
|
||||
description: List of items you want to monitor for each subscription.
|
||||
required: false
|
||||
detault: All conditions
|
||||
type: list
|
||||
keys:
|
||||
current_bandwidth_used:
|
||||
description: The current (invoice period) bandwidth usage in Gigabytes (GB).
|
||||
temperature:
|
||||
pending_charges: The current (invoice period) charges that have built up for this subscription. Value is in US Dollars (US$).
|
||||
{% endconfiguration %}
|
||||
|
||||
Full `configuration.yaml` using `{}` to format condition name (produces `sensor.server_current_bandwidth_used` and `sensor.server_pending_charges`):
|
||||
|
||||
```yaml
|
||||
sensor:
|
||||
- platform: vultr
|
||||
name: Server {}
|
||||
subscription: 123456
|
||||
monitored_conditions:
|
||||
- current_bandwidth_used
|
||||
- pending_charges
|
||||
```
|
||||
|
||||
Custom `configuration.yaml` with only one condition monitored (produces `sensor.web_server_bandwidth`):
|
||||
```yaml
|
||||
sensor:
|
||||
- platform: vultr
|
||||
name: Web Server Bandwidth
|
||||
subscription: 123456
|
||||
monitored_conditions:
|
||||
- current_bandwidth_used
|
||||
```
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ ha_iot_class: "Local Push"
|
|||
---
|
||||
|
||||
|
||||
The `modbus` switch platform allows you to control [Modbus](http://www.modbus.org/) coils.
|
||||
The `modbus` switch platform allows you to control [Modbus](http://www.modbus.org/) coils or registers.
|
||||
|
||||
To use your Modbus switches in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
@ -30,11 +30,28 @@ switch:
|
|||
- name: Switch2
|
||||
slave: 2
|
||||
coil: 14
|
||||
registers:
|
||||
- name: Register1
|
||||
slave: 1
|
||||
register: 11
|
||||
command_on: 1
|
||||
command_off: 0
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **coils** (*Optional*): A list of relevant coils to read from/write to
|
||||
- **coils** (*Optional*): A list of relevant coils to read from/write to.
|
||||
- **slave** (*Required*): The number of the slave (can be omitted for tcp and udp Modbus).
|
||||
- **name** (*Required*): Name of the sensor
|
||||
- **coil** (*Required*): Coil number
|
||||
- **name** (*Required*): Name of the switch.
|
||||
- **coil** (*Required*): Coil number.
|
||||
- **registers** (*Optional*): A list of relevant registers to read from/write to.
|
||||
- **slave** (*Required*): The number of the slave (can be omitted for tcp and udp Modbus).
|
||||
- **name** (*Required*): Name of the switch.
|
||||
- **register** (*Required*): Register number.
|
||||
- **command_on** (*Required*): Value to write to turn on the switch.
|
||||
- **command_off** (*Required*): Value to write to turn off the switch.
|
||||
- **verify_state** (*Optional*): Define if is possible to readback the status of the switch. (default: True)
|
||||
- **verify_register** (*Optional*): Register to readback. (default: same as register)
|
||||
- **register_type** (*Optional*): Modbus register type: holding or input. (default: holding)
|
||||
- **state_on** (*Optional*): Register value when switch is on. (default: same as command_on)
|
||||
- **state_off** (*Optional*): Register value when switch is off. (default: same as command_off)
|
||||
|
|
|
|||
|
|
@ -1,46 +1,46 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Rain Bird Switch"
|
||||
description: "Instructions on how to integrate your Rain Bird LNK WiFi Module as Switches within Home Assistant."
|
||||
date: 2017-08-25 12:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: rainbird.png
|
||||
ha_category: Hub
|
||||
ha_release: 0.57
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
This `rainbird` switch platform allows interacting with [LNK WiFi](http://www.rainbird.com/landscape/products/controllers/LNK-WiFi.htm) module of the Rain Bird Irrigation system in Home Assistant.
|
||||
|
||||
To enable stations as switches inside Home Assistant, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
switch:
|
||||
platform: rainbird
|
||||
host: '1.1.1.1'
|
||||
password: 'secretpassword'
|
||||
sprinkler_1:
|
||||
zone: 1
|
||||
friendly_name: "Front sprinklers"
|
||||
trigger_time: 20
|
||||
scan_interval: 10
|
||||
sprinkler_2:
|
||||
friendly_name: "Back sprinklers"
|
||||
zone: 2
|
||||
trigger_time: 20
|
||||
scan_interval: 10
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **stickip** (*Required*): The IP address of your LNK WiFi Module.
|
||||
- **password** (*Required*): The password for accessing the module.
|
||||
- **zone** (*Required*): Station zone identifier.
|
||||
- **friendly_name** (*Optional*): Just a friendly name for the station.
|
||||
- **trigger_time** (*Required*): The default duration to sprinkle the zone.
|
||||
- **scan_interval** (*Optional*): How fast to refresh the switch.
|
||||
|
||||
Please note that due to the implementation of the API within the LNK Module, there is a concurrency issue. For example, the Rain Bird app will give connection issues (like already a connection active).
|
||||
---
|
||||
layout: page
|
||||
title: "Rain Bird Switch"
|
||||
description: "Instructions on how to integrate your Rain Bird LNK WiFi Module as Switches within Home Assistant."
|
||||
date: 2017-08-25 12:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: rainbird.png
|
||||
ha_category: Hub
|
||||
ha_release: 0.57
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
This `rainbird` switch platform allows interacting with [LNK WiFi](http://www.rainbird.com/landscape/products/controllers/LNK-WiFi.htm) module of the Rain Bird Irrigation system in Home Assistant.
|
||||
|
||||
To enable stations as switches inside Home Assistant, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
switch:
|
||||
platform: rainbird
|
||||
host: '1.1.1.1'
|
||||
password: 'secretpassword'
|
||||
sprinkler_1:
|
||||
zone: 1
|
||||
friendly_name: "Front sprinklers"
|
||||
trigger_time: 20
|
||||
scan_interval: 10
|
||||
sprinkler_2:
|
||||
friendly_name: "Back sprinklers"
|
||||
zone: 2
|
||||
trigger_time: 20
|
||||
scan_interval: 10
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **stickip** (*Required*): The IP address of your LNK WiFi Module.
|
||||
- **password** (*Required*): The password for accessing the module.
|
||||
- **zone** (*Required*): Station zone identifier.
|
||||
- **friendly_name** (*Optional*): Just a friendly name for the station.
|
||||
- **trigger_time** (*Required*): The default duration to sprinkle the zone.
|
||||
- **scan_interval** (*Optional*): How fast to refresh the switch.
|
||||
|
||||
Please note that due to the implementation of the API within the LNK Module, there is a concurrency issue. For example, the Rain Bird app will give connection issues (like already a connection active).
|
||||
|
|
|
|||
|
|
@ -45,4 +45,48 @@ Configuration variables:
|
|||
- **invert_logic** (*Optional*): Inverts the output logic, default is `False`.
|
||||
- **initial_state** (*Optional*): Initial state, default is `None`, can also be `True` or `False`. `None` means no state is forced on the corresponding digital output when this switch is instantiated.
|
||||
|
||||
|
||||
## {% linkable_title Directions for installing smbus support on Raspberry Pi %}
|
||||
|
||||
Enable I2c interface with the Raspberry Pi configuration utility:
|
||||
|
||||
```bash
|
||||
# pi user environment: Enable i2c interface
|
||||
$ sudo raspi-config
|
||||
```
|
||||
|
||||
Select `Interfacing options->I2C` choose `<Yes>` and hit `Enter`, then go to `Finish`.
|
||||
|
||||
Install dependencies for use the `smbus-cffi` module and enable your _homeassistant_ user to join the _i2c_ group:
|
||||
|
||||
```bash
|
||||
# pi user environment: Install i2c dependencies and utilities
|
||||
$ sudo apt-get install build-essential libi2c-dev i2c-tools python-dev libffi-dev
|
||||
|
||||
# pi user environment: Add homeassistant user to the i2c group
|
||||
$ sudo usermod -a -G i2c homeassistant
|
||||
```
|
||||
|
||||
### {% linkable_title Check the i2c address of the sensor %}
|
||||
|
||||
After installing `i2c-tools`, a new utility is available to scan the addresses of the connected sensors, so you can see the sensor address:
|
||||
|
||||
```bash
|
||||
$ /usr/sbin/i2cdetect -y 1
|
||||
```
|
||||
|
||||
It will output a table like this:
|
||||
|
||||
```text
|
||||
0 1 2 3 4 5 6 7 8 9 a b c d e f
|
||||
00: -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- --
|
||||
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
40: 40 -- -- -- -- -- UU -- -- -- -- -- -- -- -- --
|
||||
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
70: -- -- -- -- -- -- -- 77
|
||||
```
|
||||
|
||||
For more details about the Raspihats add-on boards for Raspberry PI, visit [raspihats.com](http://www.raspihats.com/).
|
||||
|
|
|
|||
55
source/_components/switch.vultr.markdown
Normal file
55
source/_components/switch.vultr.markdown
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Vultr Switch"
|
||||
description: "Instructions on how to set up Vultr switches within Home Assistant."
|
||||
date: 2017-10-17 21:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: vultr.png
|
||||
ha_category: Switch
|
||||
ha_release: "0.58"
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
The `vultr` switch platform allows you to control (start/stop) your [Vultr](https://www.vultr.com/) subscription.
|
||||
|
||||
To control your Vultr subscription, you first have to set up your [Vultr hub](/components/vultr/).
|
||||
|
||||
<p class='note'>
|
||||
The following examples assume a subscription that has an ID of `123456` and a label of `Web Server`
|
||||
</p>
|
||||
|
||||
Minimal `configuration.yaml` (produces `switch.vultr_web_server`):
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
switch:
|
||||
- platform: vultr
|
||||
subscription: 123456
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
subscription:
|
||||
description: List of droplets you want to control.
|
||||
required: true
|
||||
type: string
|
||||
name:
|
||||
description: The name you want to give this switch.
|
||||
required: false
|
||||
default: "Vultr {subscription label}"
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
|
||||
Full `configuration.yaml` (produces `switch.amazing_server`):
|
||||
|
||||
```yaml
|
||||
switch:
|
||||
- platform: vultr
|
||||
name: Amazing Server
|
||||
subscription: 123456
|
||||
```
|
||||
|
||||
|
||||
37
source/_components/system_log.markdown
Normal file
37
source/_components/system_log.markdown
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
layout: page
|
||||
title: "System Log"
|
||||
description: "Summary of errors and warnings in Home Assistant during runtime."
|
||||
date: 2017-11-11 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: home-assistant.png
|
||||
ha_category: Other
|
||||
ha_release: 0.58
|
||||
---
|
||||
|
||||
The `system_log` component stores information about all logged errors and warnings in Home Assistant. All collected information is accessible directly in the frontend, just navigate to the `Info` section under `Developer Tools`. In order to not overload Home Assistant with log data, only the 50 last errors and warnings will be stored. Older entries are automatically discarded from the log. It is possible to change the amount of stored log entries using the parameter `max_entries`.
|
||||
|
||||
This component is automatically loaded by the `frontend` (so no need to do anything if you are using the frontend). If you are not doing so, or if you wish to change a parameter, add the following section to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
system_log:
|
||||
max_entries: MAX_ENTRIES
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
max_entries:
|
||||
description: Number of entries to store (older entries are discarded).
|
||||
required: false
|
||||
type: int
|
||||
default: 50
|
||||
{% endconfiguration %}
|
||||
|
||||
## {% linkable_title Services %}
|
||||
|
||||
### {% linkable_title Service `clear` %}
|
||||
|
||||
To manually clear the system log, call this service.
|
||||
|
||||
|
|
@ -52,6 +52,23 @@ Send a photo.
|
|||
| `keyboard` | yes | List of rows of commands, comma-separated, to make a custom keyboard. Example: `["/command1, /command2", "/command3"]` |
|
||||
| `inline_keyboard` | yes | List of rows of commands, comma-separated, to make a custom inline keyboard with buttons with associated callback data. Example: `["/button1, /button2", "/button3"]` or `[[["Text btn1", "/button1"], ["Text btn2", "/button2"]], [["Text btn3", "/button3"]]]` |
|
||||
|
||||
|
||||
#### {% linkable_title Service `telegram_bot/send_video` %}
|
||||
Send a video.
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
|---------------------------|----------|--------------------------------------------------|
|
||||
| `url` | no | Remote path to a video. |
|
||||
| `file` | no | Local path to a video. |
|
||||
| `caption` | yes | The title of the video. |
|
||||
| `username` | yes | Username for a URL which requires HTTP basic authentication. |
|
||||
| `password` | yes | Password for a URL which requires HTTP basic authentication. |
|
||||
| `authentication` | yes | Define which authentication method to use. Set to `digest` to use HTTP digest authentication. Defaults to `basic`. |
|
||||
| `target` | yes | An array of pre-authorized chat_ids to send the notification to. Defaults to the first allowed chat_id. |
|
||||
| `disable_notification` | yes | True/false to send the message silently. iOS users and web users will not receive a notification. Android users will receive a notification with no sound. Defaults to False. |
|
||||
| `keyboard` | yes | List of rows of commands, comma-separated, to make a custom keyboard. Example: `["/command1, /command2", "/command3"]` |
|
||||
| `inline_keyboard` | yes | List of rows of commands, comma-separated, to make a custom inline keyboard with buttons with associated callback data. Example: `["/button1, /button2", "/button3"]` or `[[["Text btn1", "/button1"], ["Text btn2", "/button2"]], [["Text btn3", "/button3"]]]` |
|
||||
|
||||
#### {% linkable_title Service `telegram_bot/send_document` %}
|
||||
Send a document.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,4 +24,6 @@ tellstick:
|
|||
Configuration variables:
|
||||
|
||||
- **signal_repetitions** (*Optional*): Because the tellstick 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 and light to try to send each signal repeatedly.
|
||||
- **host** (*Optional*): If you run tellstick on a other server or with a hass.io add-on.
|
||||
- **port** (*Optional*): If needed with host config option.
|
||||
|
||||
|
|
|
|||
40
source/_components/vultr.markdown
Normal file
40
source/_components/vultr.markdown
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Vultr"
|
||||
description: "Instructions on how to integrate Vultr within Home Assistant."
|
||||
date: 2017-10-17 21:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
featured: false
|
||||
ha_category: Hub
|
||||
ha_release: "0.58"
|
||||
logo: vultr.png
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `vultr` component allows you to access information about and interact with your [Vultr](https://www.vultr.com) subscriptions (Virtual Private Servers) from Home Assistant.
|
||||
|
||||
Obtain your API key from your [Vultr Account](https://my.vultr.com/settings/#settingsapi).
|
||||
|
||||
<p class='note'>
|
||||
Ensure you allow the public IP of Home Assistant under the Access Control heading.
|
||||
</p>
|
||||
|
||||
To integrate your Vultr subscriptions with Home Assistant, add the following section to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
vultr:
|
||||
api_key: ABCDEFG12345
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
api_key:
|
||||
description: Your Vultr API key.
|
||||
required: true
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue