Merge branch 'current' into next
This commit is contained in:
Paulus Schoutsen
commit
cc025a6a72
107 changed files with 293 additions and 181 deletions
|
|
@ -33,7 +33,7 @@ Configuration variables:
|
|||
- **pins** array (*Required*): Array of used pins.
|
||||
- **pin_name** (*Required*): Pin numbers and corresponding names.
|
||||
- **name** (*Required*): Friendly name to use for the frontend.
|
||||
- **bouncetime** (*Optional*): Debounce time for reading input pin defined in miliseconds [ms]. Defaults to `50 ms`.
|
||||
- **bouncetime** (*Optional*): Debounce time for reading input pin defined in milliseconds [ms]. Defaults to `50 ms`.
|
||||
- **invert_logic** (*Optional*): If `true`, inverts the input logic to ACTIVE LOW. Default is `false` (ACTIVE HIGH).
|
||||
- **pull_mode** (*Optional*): Type of internal pull resistor connected to input. Options are `UP` - pull-up resistor and `DOWN` - pull-down resistor. Defaults to `UP`.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,6 +37,17 @@ The sensor exposes the different round trip times values measured by `ping` as a
|
|||
- `round trip time min`
|
||||
- `round trip time max`
|
||||
|
||||
The default polling interval is 5 minutes. As many components [based on the entity class](/docs/configuration/platform_options), it is possible to overwrite this scan interval by specifying a `scan_interval` configuration key (value in seconds). In the example below we setup the `ping` binary sensor to poll the devices every 30 seconds.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry to ping host 192.168.0.1 with 2 packets every 30 seconds.
|
||||
binary_sensor:
|
||||
- platform: ping
|
||||
host: 192.168.0.1
|
||||
count: 2
|
||||
scan_interval: 30
|
||||
```
|
||||
|
||||
<p class='note'>
|
||||
When run on Windows systems, the round trip time attributes are rounded to the nearest millisecond and the mdev value is unavailable.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ The requirement is that you have setup the [`xiaomi aqara` component](/component
|
|||
| Smoke Detector | smoke | JTYJ-GD-01LM/BW | on, off | | | |
|
||||
| Gas Leak Detector | natgas | JTQJ-BF-01LM/BW | on, off | | | |
|
||||
| Water Leak Sensor | sensor_wleak.aq1 | SJCGQ11LM | on, off | | | |
|
||||
| Button (1st gen) | switch | WXKG01LM | on (thru long_click_press), off | `click`| `click_type`| `long_click_press`, `long_click_release`, `hold`, `single`, `double` |
|
||||
| Button (1st gen) | switch | WXKG01LM | on (through long_click_press), off | `click`| `click_type`| `long_click_press`, `long_click_release`, `hold`, `single`, `double` |
|
||||
| Button (2nd gen) | sensor_switch.aq2 | WXKG11LM | off (always) | `click` | `click_type` | `single`, `double` |
|
||||
| Aqara Wireless Switch (Single) | 86sw1 | WXKG03LM | off (always) | `click` | `click_type` | `single` |
|
||||
| Aqara Wireless Switch (Double) | 86sw2 | WXKG02LM | off (always) | `click` | `click_type` | `single`, `both` |
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: 0.12
|
|||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
A `zigbee` binary sensor in this context is a device connected to one of the digital input pins on a [ZigBee](http://www.zigbee.org/) module. The states reported by such a device are limited to `on` or `off`. By default, a binary sensor is considered `on` when the ZigBee device's digital input pin is held 'high' and considered `off` when it is held `low`. This behaviour can be inverted by setting the `on_state` configuration variable to `low`.
|
||||
A `zigbee` binary sensor in this context is a device connected to one of the digital input pins on a [ZigBee](http://www.zigbee.org/) module. The states reported by such a device are limited to `on` or `off`. By default, a binary sensor is considered `on` when the ZigBee device's digital input pin is held 'high' and considered `off` when it is held `low`. This behavior can be inverted by setting the `on_state` configuration variable to `low`.
|
||||
|
||||
To enable a digital input pin as binary sensor in your installation, add the following lines to your `configuration.yaml`:
|
||||
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ For 'temp', the current temperature is taken as the target temperature.
|
|||
When None is provided as parameter, the hold_mode is turned off.
|
||||
It is not possible to set a vacation hold; such hold has to be
|
||||
defined on the thermostat directly. However, a vacation hold can be
|
||||
cancelled.
|
||||
canceled.
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ $ sudo apt install bluetooth libbluetooth-dev pkg-config libboost-python-dev lib
|
|||
Before you get started with this platform, please note that:
|
||||
|
||||
- This platform is incompatible with Windows
|
||||
- This platform requires access to the bluetooth stack, see [Rootless Setup section](#rootless-setup) for further infomation
|
||||
- This platform requires access to the bluetooth stack, see [Rootless Setup section](#rootless-setup) for further information
|
||||
|
||||
To use the Bluetooth tracker in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Some BTLE devices (e.g. fitness trackers) are only visible to the devices that t
|
|||
|
||||
## {% linkable_title Rootless Setup %}
|
||||
|
||||
Normaly accessing the Bluetooth stack is reserved for root, but running programs that are networked as root is a bad security wise. To allow non-root access to the Bluetooth stack we can give Python 3 the missing capabilities to access the Bluetooth stack. Quite like setting the setuid bit (see [Stack Exchange](http://unix.stackexchange.com/questions/96106/bluetooth-le-scan-as-non-root) for more information).
|
||||
Normally accessing the Bluetooth stack is reserved for root, but running programs that are networked as root is a bad security wise. To allow non-root access to the Bluetooth stack we can give Python 3 the missing capabilities to access the Bluetooth stack. Quite like setting the setuid bit (see [Stack Exchange](http://unix.stackexchange.com/questions/96106/bluetooth-le-scan-as-non-root) for more information).
|
||||
|
||||
```bash
|
||||
$ sudo apt-get install libcap2-bin
|
||||
|
|
|
|||
|
|
@ -68,14 +68,14 @@ Add the above URL after you modified it with your settings into the **URL** fiel
|
|||
- Use the domain that Home Assistant is available on the internet or the public IP address. Can be a local IP address if you are using a VPN setup.
|
||||
- Only remove `[Port]` if your Home Assistant instance is using port 80. Otherwise set it to 8123.
|
||||
- For Home Assistant only the above URL, as written, will work - do not add or remove any parameters.
|
||||
- Make sure to include your [API password](/components/http/) if you have configured a password. Add `&api_password=[Your pasword]` to the end of the URL.
|
||||
- Make sure to include your [API password](/components/http/) if you have configured a password. Add `&api_password=[Your password]` to the end of the URL.
|
||||
- You can change the name of your device name by replacing `&device=%SER` with `&device=[Devicename]`.
|
||||
|
||||
If your battery drains fast then you can tune the performence of GPSLogger under **Performance** -> **Location providers**
|
||||
If your battery drains fast then you can tune the performance of GPSLogger under **Performance** -> **Location providers**
|
||||
|
||||
<p class='img'>
|
||||
<img width='300' src='/images/components/gpslogger/performance.png' />
|
||||
Performance
|
||||
</p>
|
||||
|
||||
A request can be forced from the app to test if everything is working fine. A succesful request will update the `known_devices.yaml` file with the device's serial number.
|
||||
A request can be forced from the app to test if everything is working fine. A successful request will update the `known_devices.yaml` file with the device's serial number.
|
||||
|
|
|
|||
|
|
@ -39,11 +39,11 @@ frontend:
|
|||
required: true
|
||||
type: [list, string]
|
||||
extra_html_url:
|
||||
description: "List of addtional [resources](/developers/frontend_creating_custom_ui/) to load in `latest` javascript mode."
|
||||
description: "List of additional [resources](/developers/frontend_creating_custom_ui/) to load in `latest` javascript mode."
|
||||
required: false
|
||||
type: list
|
||||
extra_html_url_es5:
|
||||
description: "List of addtional [resources](/developers/frontend_creating_custom_ui/) to load in `es5` javascript mode."
|
||||
description: "List of additional [resources](/developers/frontend_creating_custom_ui/) to load in `es5` javascript mode."
|
||||
required: false
|
||||
type: list
|
||||
development_repo:
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ group:
|
|||
- group.all_scripts
|
||||
```
|
||||
|
||||
## {% linkable_title Group behaviour %}
|
||||
## {% linkable_title Group behavior %}
|
||||
|
||||
When any member of a group is `on` then the group will also be `on`. Similarly with a device tracker, when any member of the group is `home` then the group is `home`.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ The Hive Home Assistant platform currently supports the following Hive devices:
|
|||
- Hive Active Heating (including hot water and Hive Multizone)
|
||||
- Hive Active Light Dimmable
|
||||
- Hive Active Light Cool to Warm White
|
||||
- Hive Active Light Colour Changing
|
||||
- Hive Active Light Color Changing
|
||||
- Hive Active Plug
|
||||
- Hive Window or Door Sensor
|
||||
- Hive Motion Sensor
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ If you are running Home Assistant over SSL or from within a container, you will
|
|||
|
||||
Alpr entities attribute have a vehicle counter `vehicles` and all found plates as `plates`.
|
||||
|
||||
This event is trigger after OpenALPR found a new licence plate.
|
||||
This event is trigger after OpenALPR found a new license plate.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml automation entry
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ A datetime input entity's state exports several attributes that can be useful in
|
|||
| --------- | ----------- |
|
||||
| `has_time` | `true` if this entity has a time.
|
||||
| `has_date` | `true` if this entity has a date.
|
||||
| `year`<br>`month`<br>`day` | The year, month and day of the date.<br>(only availabel if `has_date: true`)
|
||||
| `year`<br>`month`<br>`day` | The year, month and day of the date.<br>(only available if `has_date: true`)
|
||||
| `hour`<br>`minute`<br>`second` | The hour, minute and second of the time.<br>(only available if `has_time: true`)
|
||||
| `timestamp` | A timestamp representing the time held in the input.<br>If `has_date: true`, this is the UNIX timestamp of the date / time held by the input. Otherwise if only `has_time: true`, this is the number of seconds since midnight representing the time held by the input.
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ input_number:
|
|||
required: true
|
||||
type: float
|
||||
max:
|
||||
description: Maxium value.
|
||||
description: Maximum value.
|
||||
required: true
|
||||
type: float
|
||||
name:
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ knx:
|
|||
|
||||
- **fire_event** (*Optional*): If set to True, platform will write all received KNX messages to event bus
|
||||
- **fire_event_filter** (*Optional*): If `fire_event` is set `fire_event_filter` has to be specified. `fire_event_filter` defines a list of patterns for filtering KNX addresses. Only telegrams which match this pattern are sent to the HOme Assistant event bus.
|
||||
- **state_updater** (*Optional*): The component will collect the current state of each configured device from the KNX bus to display it correctly within Home-Assistant. Set this option to False to prevent this behaviour.
|
||||
- **state_updater** (*Optional*): The component will collect the current state of each configured device from the KNX bus to display it correctly within Home-Assistant. Set this option to False to prevent this behavior.
|
||||
- **time_address** (*Optional*): Broadcast current local time to KNX bus with configured group address.
|
||||
|
||||
### {% linkable_title Services %}
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ The 'hive' light component integrates your Hive lights into Home Assistant, enab
|
|||
The Hive light component supports the following Hive products:
|
||||
- **Hive Active Light Dimmable**
|
||||
- **Hive Active Light Cool to Warm White**
|
||||
- **Hive Active Light Colour Changing**
|
||||
- **Hive Active Light Color Changing**
|
||||
|
||||
|
||||
<p class='note'>
|
||||
|
|
|
|||
|
|
@ -61,8 +61,7 @@ This component is tested to work with the following models. If you have a differ
|
|||
- **YLDP03YL**: LED Bulb (Color) - E26
|
||||
- **YLDD01YL**: Lightstrip (Color)
|
||||
- **YLDD02YL**: Lightstrip (Color)
|
||||
|
||||
|
||||
- **MJCTD01YL**: Xiaomi Mijia Bedside Lamp - WIFI Version!
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: 0.12
|
|||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
A ZigBee light in this context is a light connected to one of the digital output pins on a ZigBee module. It can simply be switched on and off. By default, a light is considered `on` when the ZigBee device's digital output is held `high` and considered `off` when it is held `low`. This behaviour can be inverted by setting the `on_state` configuration variable to `low`.
|
||||
A ZigBee light in this context is a light connected to one of the digital output pins on a ZigBee module. It can simply be switched on and off. By default, a light is considered `on` when the ZigBee device's digital output is held `high` and considered `off` when it is held `low`. This behavior can be inverted by setting the `on_state` configuration variable to `low`.
|
||||
|
||||
To configure a digital output pin as light, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ The configuration is slightly different :
|
|||
- The former single `lirc` service is replaced with the three systemd services `lircd.service`, `lircmd.service` and `irexec.service`. There is no counterpart to the 0.9.0 `lirc` service which covered all of these. Using a separate transmitter device requires yet another service.
|
||||
- 0.9.4 defaults to using systemd for controlling the services. This is not just start/stop functionality, systemd is used to implement new features and to address shortcomings in 0.9.0. However, traditional systemV scripts are also installed and could be used although this is less tested and not really documented.
|
||||
|
||||
For more infomation have a look at `/usr/share/doc/lirc/README.Debian.gz` where the update process is explained when you have updated from jessie to stretch.
|
||||
For more information have a look at `/usr/share/doc/lirc/README.Debian.gz` where the update process is explained when you have updated from jessie to stretch.
|
||||
</p>
|
||||
|
||||
### {% linkable_title Configuring LIRC %}
|
||||
|
|
|
|||
|
|
@ -67,6 +67,6 @@ A few notes:
|
|||
|
||||
- Additional option the control Denon AVR receivers with a builtin web server is using the HTTP interface with denonavr platform.
|
||||
- denonavr platform supports some additional functionalities like album covers, custom input source names and auto discovery.
|
||||
- Marantz receivers seem to a have quite simliar interface. Thus if you own one, give it a try.
|
||||
- Marantz receivers seem to a have quite similar interface. Thus if you own one, give it a try.
|
||||
|
||||
[Denon]: /components/media_player.denon/
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Configuration variables:
|
|||
volume control and source selection. Playback controls, for instance
|
||||
play and stop are available for sources that supports it.
|
||||
- The `play_media` service is implemented for `NET RADIO` source
|
||||
only. The `media_id` is a `>` separted string of the menu path on
|
||||
only. The `media_id` is a `>` separated string of the menu path on
|
||||
the vtuner service. For instance `Bookmarks>Internet>WAMC 90.3 FM`.
|
||||
|
||||
### {% linkable_title Example configuration %}
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ ha_release: 0.56
|
|||
With the `namecheapdns` component you can automatically update your dynamic DNS entry at [namecheapdns](https://www.namecheap.com/store/domains/freedns/).
|
||||
|
||||
<p class='note warning'>
|
||||
Namecheap only supports IPv4 adresses to update.
|
||||
Namecheap only supports IPv4 addresses to update.
|
||||
</p>
|
||||
|
||||
To use the component in your installation, add the following to your `configuration.yaml` file:
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ 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:
|
||||
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 specific 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
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ notify:
|
|||
|
||||
### {% linkable_title Examples %}
|
||||
|
||||
Message to two devices with formated text.
|
||||
Message to two devices with formatted text.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -53,7 +53,7 @@ Message to two devices with formated text.
|
|||
}
|
||||
```
|
||||
|
||||
Message to one device with formated text and image from an external URL.
|
||||
Message to one device with formatted text and image from an external URL.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -75,7 +75,7 @@ Message to one device with formated text and image from an external URL.
|
|||
}
|
||||
```
|
||||
|
||||
Message to two devices and one device group with formated text and local image.
|
||||
Message to two devices and one device group with formatted text and local image.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Configuration variables:
|
|||
- **host** (*Required*): The IP address of the computer running the pilight-daemon, e.g. 192.168.1.32.
|
||||
- **port** (*Required*): The network port to connect to. The usual port is [5000](https://manual.pilight.org/development/api.html).
|
||||
- **send_delay** (*Optional*): You can define a send delay as a fraction of seconds if you experience transmission problems when you try to switch multiple switches at once. This can happen when you use a [pilight USB Nano](https://github.com/pilight/pilight-usb-nano) as hardware and switches a whole group of multiple switches on or off. Tested values are between 0.3 and 0.8 seconds depending on the hardware.
|
||||
- **whitelist** (*Optional*): You can define a whitelist to prevent that too many unwanted RF codes (e.g. the neighbours weather station) are put on your HA event bus. All defined subsections have to be matched. A subsection is matched if one of the items are true.
|
||||
- **whitelist** (*Optional*): You can define a whitelist to prevent that too many unwanted RF codes (e.g. the neighbors weather station) are put on your HA event bus. All defined subsections have to be matched. A subsection is matched if one of the items are true.
|
||||
|
||||
In this example only received RF codes using a daycom or Intertechno protocol are put on the event bus and only when the device id is 42. For more possible settings please look at the receiver section of the pilight [API](https://manual.pilight.org/development/api.html).
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Configuration variables:
|
|||
|
||||
{% configuration %}
|
||||
name:
|
||||
description: Name of the RTM account, as you can have serveral accounts in RTM. The name must be unique.
|
||||
description: Name of the RTM account, as you can have several accounts in RTM. The name must be unique.
|
||||
required: true
|
||||
type: string
|
||||
api_key:
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Configuration variables:
|
|||
- **groundtemperature**: The current ground temperature (in [C](https://en.wikipedia.org/wiki/Celsius)).
|
||||
- **windspeed**: The wind speed in [m/s](https://en.wikipedia.org/wiki/M/s).
|
||||
- **windforce**: The wind speed/force in [Bft](https://en.wikipedia.org/wiki/Beaufort_scale).
|
||||
- **winddirection**: Where the wind is coming from: N (North),Z (south), NO (Noth-East), etc.
|
||||
- **winddirection**: Where the wind is coming from: N (North),Z (south), NO (North-East), etc.
|
||||
- **windazimuth**: Where the wind is coming from in degrees, with true north at 0° and progressing clockwise.
|
||||
- **pressure**: The sea-level air pressure in [hPa](https://en.wikipedia.org/wiki/Hectopascal).
|
||||
- **visibility**: Visibility in meters ([m](https://en.wikipedia.org/wiki/Metre)).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Deutsche Bahn"
|
||||
description: "Instructions how to integrate timetable data for travelling in Germany within Home Assistant."
|
||||
description: "Instructions how to integrate timetable data for traveling in Germany within Home Assistant."
|
||||
date: 2015-06-02 21:45
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Dublin Bus Transport"
|
||||
description: "Instructions how to integrate timetable data for travelling on Dublin Bus within Home Assistant."
|
||||
description: "Instructions how to integrate timetable data for traveling on Dublin Bus within Home Assistant."
|
||||
date: 2017-01-09 21:45
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ ha_release: 0.44
|
|||
The `envirophat` sensor platform allows you to display information collected by an [Enviro pHAT](https://shop.pimoroni.com/products/enviro-phat) add-on board for the Raspberry Pi. The board features a wide range of sensors, such as:
|
||||
|
||||
- BMP280 temperature/pressure sensor
|
||||
- TCS3472 light and RGB colour sensor with two LEDs for illumination
|
||||
- TCS3472 light and RGB color sensor with two LEDs for illumination
|
||||
- LSM303D accelerometer/magnetometer sensor
|
||||
- ADS1015 4-channel 3.3v, analog to digital sensor (ADC)
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ 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.
|
||||
- **radius** (*Optional*): The distance in kilometers 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'.
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Configuration variables for the server:
|
|||
|
||||
### {% linkable_title Full configuration %}
|
||||
|
||||
The example configuration entry bellow create two request to your local InfluxDB instance, one to the database `db1`, the other to `db2`:
|
||||
The example configuration entry below create two request to your local InfluxDB instance, one to the database `db1`, the other to `db2`:
|
||||
|
||||
- `select last(value) as value from "°C" where "name" = "foo"`
|
||||
- `select min(tmp) as value from "%" where "entity_id" = ''salon'' and time > now() - 1h`
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The `lacrosse` sensor platform is using the data provided by a [Jeelink](https:/
|
|||
|
||||
## {% 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.
|
||||
Since the sensor change their ID after each powercycle/battery change you can check what sensor IDs are available by using the command-line tool `pylacrosse` from the pylacrosse package.
|
||||
|
||||
```bash
|
||||
$ sudo pylacrosse -d /dev/ttyUSB0 scan
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: 0.28
|
|||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
The `linux_battery` sensor platform is using the information stored in `/sys/class/power_supply/` on your local Linux system to display details about the current state of your battery.
|
||||
The `linux_battery` sensor platform is using the information stored in `/sys/class/power_supply/` on your local Linux system to display details about the current state of your battery.
|
||||
|
||||
To setup a battery sensor to your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
@ -23,8 +23,20 @@ sensor:
|
|||
- platform: linux_battery
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **name** (*Optional*): Friendly name to use for the frontend. Default to "Battery".
|
||||
- **battery** (*Optional*): Number of the battery. Default to `1`.
|
||||
|
||||
{% configuration %}
|
||||
name:
|
||||
description: Friendly name to use for the frontend.
|
||||
required: false
|
||||
default: Battery
|
||||
type: string
|
||||
battery:
|
||||
description: Number of the battery.
|
||||
required: false
|
||||
default: 1
|
||||
type: integer
|
||||
system:
|
||||
description: "The local system type. Support `linux` and `android`."
|
||||
required: false
|
||||
default: linux
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ ha_release: 0.52
|
|||
|
||||
The `london_air` component [queries](http://api.erg.kcl.ac.uk/AirQuality/Hourly/MonitoringIndex/GroupName=London/Json) the London air quality [data feed](https://www.londonair.org.uk/LondonAir/API/) provided by Kings College London. A single sensor will be added for each `location` ([local authority district or borough](https://en.wikipedia.org/wiki/List_of_London_boroughs)) specified in the configuration file. The state of each sensor is the overall air quality in that borough. Note that only 28 of the 32 boroughs have data available.
|
||||
|
||||
Boroughs can have multiple monitoring sites at different geographical positions within the borough, and each of those sites can monitor up to six different kinds of pollutant. The pollutants are described [here](http://api.erg.kcl.ac.uk/AirQuality/Information/Species/Json) and are Carbon Monoxide ([CO2](http://www.londonair.org.uk/LondonAir/guide/WhatIsCO.aspx)), Nitrogen Dioxide ([NO2](http://www.londonair.org.uk/LondonAir/guide/WhatIsNO2.aspx)), Ozone ([O3](http://www.londonair.org.uk/LondonAir/guide/WhatIsO3.aspx)), Sulphur Dioxide ([SO2](http://www.londonair.org.uk/LondonAir/guide/WhatIsSO2.aspx)), PM2.5 & PM10 [particulates](http://www.londonair.org.uk/LondonAir/guide/WhatIsPM.aspx). The `latitude` and `longitude` of each site is accessible through a `data` attribute of the sensor, as are details about the pollutants monitored at that site. The `sites` attribute of a sensor displays how many monitoring sites that sensor covers. The `updated` attribute of a sensor states when the data was last published. Nominally data is published hourly, but in my experience this can vary. To limit the number of requests made by the sensor, a single API request is made every 30 minutes.
|
||||
Boroughs can have multiple monitoring sites at different geographical positions within the borough, and each of those sites can monitor up to six different kinds of pollutant. The pollutants are described [here](http://api.erg.kcl.ac.uk/AirQuality/Information/Species/Json) and are Carbon Monoxide ([CO2](http://www.londonair.org.uk/LondonAir/guide/WhatIsCO.aspx)), Nitrogen Dioxide ([NO2](http://www.londonair.org.uk/LondonAir/guide/WhatIsNO2.aspx)), Ozone ([O3](http://www.londonair.org.uk/LondonAir/guide/WhatIsO3.aspx)), Sulfur Dioxide ([SO2](http://www.londonair.org.uk/LondonAir/guide/WhatIsSO2.aspx)), PM2.5 & PM10 [particulates](http://www.londonair.org.uk/LondonAir/guide/WhatIsPM.aspx). The `latitude` and `longitude` of each site is accessible through a `data` attribute of the sensor, as are details about the pollutants monitored at that site. The `sites` attribute of a sensor displays how many monitoring sites that sensor covers. The `updated` attribute of a sensor states when the data was last published. Nominally data is published hourly, but in my experience this can vary. To limit the number of requests made by the sensor, a single API request is made every 30 minutes.
|
||||
|
||||
To add sensors to Home-assistant for all possible areas/boroughs add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Nederlandse Spoorwegen"
|
||||
description: "Instructions how to integrate timetable data for travelling by train in the Netherlands within Home Assistant."
|
||||
description: "Instructions how to integrate timetable data for traveling by train in the Netherlands within Home Assistant."
|
||||
date: 2017-10-25 13:35
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -40,10 +40,10 @@ Configuration variables:
|
|||
|
||||
- **email** (*Required*): The email address you used to request the API password.
|
||||
- **password** (*Required*): The API password provided by the Nederlandse Spoorwegen.
|
||||
- **routes** array (*Required*): List of travelling routes.
|
||||
- **routes** array (*Required*): List of traveling routes.
|
||||
- **name** (*Required*): Name of the route.
|
||||
- **from** (*Required*): The start station.
|
||||
- **to** (*Required*): Direction of the travelling.
|
||||
- **to** (*Required*): Direction of the traveling.
|
||||
- **via** (*Optional*): Optional other station you wish to visit in between.
|
||||
|
||||
The data are coming from [Nederlandse Spoorwegen](https://www.ns.nl/).
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Supported devices:
|
|||
The 1-Wire bus can be connected directly to the IO pins of Raspberry Pi or using dedicated interface adapter (e.g [DS9490R](https://datasheets.maximintegrated.com/en/ds/DS9490-DS9490R.pdf)).
|
||||
|
||||
#### Raspberry Pi setup
|
||||
In order ot setup 1-Wire support on Raspberry Pi, you'll need to edit `/boot/config.txt` following [this documentation](https://www.waveshare.com/wiki/Raspberry_Pi_Tutorial_Series:_1-Wire_DS18B20_Sensor#Enable_1-Wire). Don't use the `mount_dir` option.
|
||||
In order to setup 1-Wire support on Raspberry Pi, you'll need to edit `/boot/config.txt` following [this documentation](https://www.waveshare.com/wiki/Raspberry_Pi_Tutorial_Series:_1-Wire_DS18B20_Sensor#Enable_1-Wire). Don't use the `mount_dir` option.
|
||||
|
||||
#### Interface adapter setup
|
||||
When an interface adapter is used, sensors can be accessed on Linux hosts via [owfs 1-Wire file system](http://owfs.org/). When using an interface adapter and the owfs, the `mount_dir` option must be configured to correspond a directory, where owfs device tree has been mounted.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ ha_iot_class: "Cloud Polling"
|
|||
---
|
||||
|
||||
|
||||
The `pvoutput` sensor platform consumes informations from [PVOutput](http://pvoutput.org/) which were uploaded by your solar photovoltaic (PV) system.
|
||||
The `pvoutput` sensor platform consumes information from [PVOutput](http://pvoutput.org/) which were uploaded by your solar photovoltaic (PV) system.
|
||||
|
||||
To add PVOutput details to your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ sensor:
|
|||
User-Agent: Home Assistant REST sensor
|
||||
```
|
||||
|
||||
### {% linkable_title Fetch multiple JSON values and present them as attibutes %}
|
||||
### {% linkable_title Fetch multiple JSON values and present them as attributes %}
|
||||
|
||||
[JSON Test](http://www.jsontest.com) returns the current time, date and milliseconds since epoch from [http://date.jsontest.com/](http://date.jsontest.com/).
|
||||
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ sensor:
|
|||
|
||||
### {% linkable_title Get the latest podcast episode file URL %}
|
||||
|
||||
If you want to get the file URL for the latest episode of your [favourite podcast](https://hasspodcast.io/), so you can pass it on to a compatible media player.
|
||||
If you want to get the file URL for the latest episode of your [favorite podcast](https://hasspodcast.io/), so you can pass it on to a compatible media player.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Swiss Public Transport"
|
||||
description: "Instructions how to integrate timetable data for travelling in Switzerland within Home Assistant."
|
||||
description: "Instructions how to integrate timetable data for traveling in Switzerland within Home Assistant."
|
||||
date: 2015-06-02 21:45
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Västtrafik Public Transport"
|
||||
description: "Instructions how to integrate timetable data for travelling in Sweden within Home Assistant."
|
||||
description: "Instructions how to integrate timetable data for traveling in Sweden within Home Assistant."
|
||||
date: 2016-10-05 08:45
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -14,7 +14,7 @@ ha_release: "0.30"
|
|||
---
|
||||
|
||||
|
||||
The `vasttrafik` sensor will provide you travelling details for the larger Göteborg area in Sweden from the [Västtrafik](https://vasttrafik.se/) public transportation service.
|
||||
The `vasttrafik` sensor will provide you traveling details for the larger Göteborg area in Sweden from the [Västtrafik](https://vasttrafik.se/) public transportation service.
|
||||
|
||||
You must create an application [here](https://developer.vasttrafik.se/portal/#/applications) to obtain a `key` and a `secret`.
|
||||
|
||||
|
|
@ -34,10 +34,10 @@ Configuration variables:
|
|||
|
||||
- **key** (*Required*): The API key to access your Västtrafik account.
|
||||
- **secret** (*Required*): The API secret to access your Västtrafik account.
|
||||
- **departures** array (*Required*): List of travelling routes.
|
||||
- **departures** array (*Required*): List of traveling routes.
|
||||
- **name** (*Optional*): Name of the route.
|
||||
- **from** (*Required*): The start station.
|
||||
- **heading** (*Optional*): Direction of the travelling.
|
||||
- **heading** (*Optional*): Direction of the traveling.
|
||||
- **delay** (*Optional*): Delay in minutes. Defaults to 0.
|
||||
|
||||
The data are coming from [Västtrafik](https://vasttrafik.se/).
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: 0.12
|
|||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
A ZigBee switch in this context is a device connected to one of the digital output pins on a ZigBee module. It can simply be switched on and off. By default, a switch is considered `on` when the ZigBee device's digital output is held `high` and considered `off` when it is held `low`. This behaviour can be inverted by setting the `on_state` configuration variable to `low`.
|
||||
A ZigBee switch in this context is a device connected to one of the digital output pins on a ZigBee module. It can simply be switched on and off. By default, a switch is considered `on` when the ZigBee device's digital output is held `high` and considered `off` when it is held `low`. This behavior can be inverted by setting the `on_state` configuration variable to `low`.
|
||||
|
||||
To configure a digital output pin as switch, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ ha_release: 0.57
|
|||
|
||||
The `timer` component aims to simplify automations based on (dynamic) durations.
|
||||
|
||||
When a timer finishes or gets cancelled the corresponding events are fired. This allows you to differentiate if a timer has switched from `active` to `idle` because the given duration has elapsed or it has been cancelled. To control timers in your automations you can use the services mentioned below. When calling the `start` service on a timer that is already running, it resets the duration it will need to finish and restart the timer without triggering any events. This for example makes it easy to create timed lights that get triggered by motion.
|
||||
When a timer finishes or gets canceled the corresponding events are fired. This allows you to differentiate if a timer has switched from `active` to `idle` because the given duration has elapsed or it has been canceled. To control timers in your automations you can use the services mentioned below. When calling the `start` service on a timer that is already running, it resets the duration it will need to finish and restart the timer without triggering any events. This for example makes it easy to create timed lights that get triggered by motion.
|
||||
|
||||
<p class='note warning'>
|
||||
With the current implementation timers don't persist over restarts. After a restart they will be idle again, together with their initial configuration.
|
||||
|
|
@ -42,7 +42,7 @@ Pick an icon that you can find on [materialdesignicons.com](https://materialdesi
|
|||
|
||||
| Event | Description |
|
||||
| --------------- | ----------- |
|
||||
| timer.cancelled | Fired when a timer has been cancelled |
|
||||
| timer.cancelled | Fired when a timer has been canceled |
|
||||
| timer.finished | Fired when a timer has completed |
|
||||
|
||||
## {% linkable_title Services %}
|
||||
|
|
@ -67,7 +67,7 @@ Pause a running timer. This will retain the remaining duration for later continu
|
|||
|
||||
#### {% linkable_title Service `timer.cancel` %}
|
||||
|
||||
Cancel an active timer. This resets the duration to the last known initial value without firing the `timer.finished` event. If no `entity_id` is given all active timers will be cancelled.
|
||||
Cancel an active timer. This resets the duration to the last known initial value without firing the `timer.finished` event. If no `entity_id` is given all active timers will be canceled.
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ Configuration variables:
|
|||
- **username** (*Required*): The username associated with your Volvo On Call account.
|
||||
- **password** (*Required*): The password for your given Volvo On Call account.
|
||||
- **region** (*Optional*): The region where the Volvo is registered. Needs to be set for users in North America or China.
|
||||
- **service_url** (*Optional*): The service URL to use for Volvo On Call. Normally not neccessary to specify.
|
||||
- **service_url** (*Optional*): The service URL to use for Volvo On Call. Normally not necessary to specify.
|
||||
- **name** (*Optional*): Make it possible to provide a name for the vehicles.
|
||||
- **resources** (*Optional*): A list of resources to display (defaults to all available).
|
||||
- **scandinavian_miles** (*Optional*): If set to yes, Scandinavian miles ("mil") are used for distances and fuel range (defaults to no).
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ wink:
|
|||
|
||||
### {% linkable_title Full oauth authentication (legacy). %}
|
||||
|
||||
This should be used for users that obtained their client_id and client_secret via email from Wink support prior to [developer.wink.com's](https://developer.wink.com) existance.
|
||||
This should be used for users that obtained their client_id and client_secret via email from Wink support prior to [developer.wink.com's](https://developer.wink.com) existence.
|
||||
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue