mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-07-24 01:37:23 +00:00
👕 Markdownlint fixes (#5734)
This commit is contained in:
Franck Nijhof
Fabian Affolter
parent
4c0d2624d7
commit
bd5f24cdd4
@ -58,7 +58,7 @@ Configuration variables:
|
||||
- **sdcard**: Return the SD card usage by reporting the total and used space
|
||||
- **ptz_preset**: Return the number of PTZ preset positions configured for the given camera
|
||||
- **switches** array (*Optional*): Switches to display in the frontend. By default, *none* of the switches are shown. The following switches can be monitored.
|
||||
- **motion_detection**: Enable/disable motion detection setting
|
||||
- **motion_detection**: Enable/disable motion detection setting
|
||||
- **motion_recording**: Enable/disable recording on motion detection setting
|
||||
|
||||
**Note:** Amcrest cameras with newer firmware no longer have the ability to stream `high` definition video with MJPEG encoding. You may need to use `low` resolution stream or the `snapshot` stream source instead. If the quality seems too poor, lower the `Frame Rate (FPS)` and max out the `Bit Rate` settings in your camera's configuration manager. If you defined the *stream_source* to **mjpeg**, make sure your camera supports *Basic* HTTP authentication. Newer Amcrest firmware may not work, then **rtsp** is recommended instead.
|
||||
|
||||
@ -19,10 +19,9 @@ See the [Axis main component](/components/axis/) for configuration instructions.
|
||||
|
||||
The following sensor types are supported:
|
||||
|
||||
|
||||
* Motion detection
|
||||
* Passive IR motion detection
|
||||
* Sound detection
|
||||
* Day/night mode
|
||||
* Tampering detection
|
||||
* Input port
|
||||
- Motion detection
|
||||
- Passive IR motion detection
|
||||
- Sound detection
|
||||
- Day/night mode
|
||||
- Tampering detection
|
||||
- Input port
|
||||
|
||||
@ -13,7 +13,6 @@ ha_release: 0.14
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `bloomsky` component allows you to access your [BloomSky](https://www.bloomsky.com/) weather station's [sensors](/components/sensor.bloomsky), [binary sensors](/components/binary_sensor.bloomsky), and [camera](/components/camera.bloomsky) from Home Assistant.
|
||||
|
||||
Obtain your API key from your [BloomSky dashboard](https://dashboard.bloomsky.com). Click `developers` in the bottom left of the screen.
|
||||
|
||||
@ -13,7 +13,6 @@ ha_iot_class: "Local Polling"
|
||||
ha_release: 0.62
|
||||
---
|
||||
|
||||
|
||||
The `Xeoma` camera platform allows you to view the video feeds from a [Xeoma](http://felenasoft.com/xeoma) video surveillance server.
|
||||
|
||||
To enable Xeoma camera feeds, add the following lines to your `configuration.yaml`:
|
||||
@ -48,7 +47,7 @@ cameras:
|
||||
required: false
|
||||
type: list
|
||||
keys:
|
||||
image_name:
|
||||
image_name:
|
||||
description: The name of the JPEG image for this camera as configured in Xeoma (without .jpg extension).
|
||||
required: true
|
||||
type: string
|
||||
@ -82,8 +81,7 @@ camera:
|
||||
```
|
||||
|
||||
To use this platform, you must have the Xeoma Web Server module enabled in at least one of your camera chains.
|
||||
|
||||
This platform will parse the Xeoma web interface to find all enabled cameras and add them all to Home Assistant. You can
|
||||
hide individual cameras using the platform configuration.
|
||||
|
||||
|
||||
This platform will parse the Xeoma web interface to find all enabled cameras and add them all to Home Assistant. You can hide individual cameras using the platform configuration.
|
||||
|
||||
The `image_name` configuration value for each camera should match the name supplied to the Xeoma Web Server configuration (under _Path to access images_) with the _.jpg_ extension removed.
|
||||
|
||||
@ -12,8 +12,7 @@ ha_category: Cover
|
||||
ha_release: 0.44
|
||||
---
|
||||
|
||||
|
||||
The `opengarage` cover platform lets you control the open-source [OpenGarage.io](https://opengarage.io/) device through Home Assistant.
|
||||
The `opengarage` cover platform lets you control the open-source [OpenGarage.io](https://opengarage.io/) device through Home Assistant.
|
||||
|
||||
To enable OpenGarage Covers in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
@ -36,12 +35,10 @@ Configuration variables:
|
||||
|
||||
- **covers** array (*Required*): List of your doors.
|
||||
- **identifier** (*Required*): Name of the cover as slug. Multiple entries are possible.
|
||||
- **host** (*Required*): IP address of device.
|
||||
- **port** (*Optional*): HTTP Port. Default is `80`.
|
||||
- **device_key** (*Required*): Access key to control device. Default is `opendoor`.
|
||||
- **name** (*Optional*): Name to use in the Frontend. If not provided, it will use name configured in device.
|
||||
|
||||
|
||||
- **host** (*Required*): IP address of device.
|
||||
- **port** (*Optional*): HTTP Port. Default is `80`.
|
||||
- **device_key** (*Required*): Access key to control device. Default is `opendoor`.
|
||||
- **name** (*Optional*): Name to use in the Frontend. If not provided, it will use name configured in device.
|
||||
|
||||
**Example with more detail:**
|
||||
<p class='img'>
|
||||
@ -53,7 +50,7 @@ Configuration variables:
|
||||
cover:
|
||||
platform: opengarage
|
||||
covers:
|
||||
garage:
|
||||
garage:
|
||||
host: 192.168.1.12
|
||||
device_key: opendoor
|
||||
name: honda
|
||||
@ -93,12 +90,12 @@ sensor:
|
||||
{% endif %}'{% endraw %}
|
||||
|
||||
group:
|
||||
garage:
|
||||
garage:
|
||||
name: Garage
|
||||
entities:
|
||||
- cover.honda
|
||||
- sensor.garage_status
|
||||
- sensor.garage_car_present
|
||||
- sensor.garage_car_present
|
||||
|
||||
customize:
|
||||
cover.honda:
|
||||
|
||||
@ -12,12 +12,11 @@ logo: linksys.png
|
||||
ha_release: 0.48
|
||||
---
|
||||
|
||||
The `linksys_smart` platform offers presence detection by looking at connected devices to a Linksys Smart Wifi based router.
|
||||
The `linksys_smart` platform offers presence detection by looking at connected devices to a Linksys Smart Wifi based router.
|
||||
|
||||
Tested routers:
|
||||
Tested routers:
|
||||
LINKSYS WRT3200ACM MU-MIMO Gigabit Wi-Fi Wireless Router
|
||||
LINKSYS WRT1900ACS Dual-band Wi-Fi Router
|
||||
|
||||
|
||||
<p class='note'>
|
||||
For this platform to work correctly, it is necessary to disable the "Access via wireless" feature in the Local Management Access section of the router administration page. If "Access via wireless" is not disabled, a connectivity conflict arises because the Home Assistant integration is trying to pass userid and password, but the router is only expecting a password.
|
||||
|
||||
@ -70,14 +70,13 @@ Configuration variables:
|
||||
- **password** (*Required*): The password for your given account.
|
||||
- **dhcp_software** (*Optional*): The DHCP software used in your router: `dnsmasq`, `dhcpd`, or `none`. Defaults to `dnsmasq`.
|
||||
|
||||
|
||||
See the [device tracker component page](/components/device_tracker/) for instructions how to configure the people to be tracked.
|
||||
|
||||
## Troubleshooting
|
||||
## {% linkable_title Troubleshooting %}
|
||||
|
||||
If you find that this never creates `known_devices.yaml`, or if you need more information on the communication chain between Home Assistant and OpenWRT, follow these steps to grab the packet stream and gain insight into what's happening.
|
||||
|
||||
### Increase Log Level
|
||||
### {% linkable_title Increase Log Level %}
|
||||
|
||||
1. On your Home Assistant device, stop Home Assistant
|
||||
2. Adjust `configuration.yaml` to log more detail for the `device_tracker` component
|
||||
@ -167,6 +166,6 @@ Connection: keep-alive
|
||||
```
|
||||
11. In this case we are actually receiving a valid response with no data. The request says that we are looking for ARP information from `hostapd.*`, which is the access point on the router. In my environment I don't use the AP on the router, and so it was correctly returning no data. Armed with this information, I know that I cannot use this component for device tracking or presence.
|
||||
|
||||
### Cleanup
|
||||
### {% linkable_title Cleanup %}
|
||||
|
||||
When you're done troubleshooting, remember to reset your logging configuration and delete any capture files that contain sensitive information.
|
||||
|
||||
@ -14,25 +14,24 @@ ha_release: 0.9
|
||||
ha_iot_class: "Cloud Push"
|
||||
---
|
||||
|
||||
|
||||
The `ecobee` component lets you control a thermostats and view sensor data from [ecobee](https://ecobee.com) thermostats.
|
||||
|
||||
You will need to obtain an API key from ecobee's [developer site](https://www.ecobee.com/developers/) to use this component. To get the key, first you need to register your thermostat which should be done as part of the ecobee installation. Once you have done that perform the following steps.
|
||||
|
||||
1. Click on the **Become a developer** link on the [developer site](https://www.ecobee.com/developers/).
|
||||
1. Click on the **Become a developer** link on the [developer site](https://www.ecobee.com/developers/).
|
||||
2. Login with your ecobee credentials.
|
||||
3. Accept the SDK agreement.
|
||||
4. Fill in the fields.
|
||||
5. Click **save**.
|
||||
5. Click **save**.
|
||||
|
||||
Now login to the regular consumer portal, and in the hamburger menu there will be a new option **Developer**. Now we can create the Application to hook up to Home Assistant.
|
||||
|
||||
1. Select the Developer option.
|
||||
2. Select **Create New**.
|
||||
3. Give your app a name (it appears to need to be unique across all users, as I tried 'home-assistant' and it said it was already in use. Try <yournameoralias>-home-assistant) and a summary (neither of these are important as they are not used anywhere).
|
||||
4. For Authorization method select **ecobee PIN**.
|
||||
5. You don't need an Application Icon or Detailed Description.
|
||||
6. Click **Create**.
|
||||
1. Select the Developer option.
|
||||
2. Select **Create New**.
|
||||
3. Give your app a name (it appears to need to be unique across all users, as I tried 'home-assistant' and it said it was already in use. Try <yournameoralias>-home-assistant) and a summary (neither of these are important as they are not used anywhere).
|
||||
4. For Authorization method select **ecobee PIN**.
|
||||
5. You don't need an Application Icon or Detailed Description.
|
||||
6. Click **Create**.
|
||||
|
||||
Now under the Name and Summary Section you will have an API key. Copy this key and use it in you configuration section below. Click the **X** to close the Developer section.
|
||||
|
||||
@ -40,8 +39,8 @@ The first time you run Home Assistant with this component it will give you a PIN
|
||||
|
||||
The PIN can be found from the Home Assistant portal on the Ecobee card or from the **configurator.ecobee** entity in states in the portal.
|
||||
|
||||
- If you do not have an ecobee card, you may be using groups with `default_view` that don't show the card. To get around this you can temporarily comment out the `default_view` section or add the `configurator.ecobee` component to your `default_view` and restart Home Assistant.
|
||||
|
||||
- If you do not have an ecobee card, you may be using groups with `default_view` that don't show the card. To get around this you can temporarily comment out the `default_view` section or add the `configurator.ecobee` component to your `default_view` and restart Home Assistant.
|
||||
|
||||
Once you enter the PIN on the ecobee site, wait approximately 5 minutes and then click on the **I have authorized the app** link at the bottom of the ecobee pop-up window. If everything worked correctly, you should now be able to restart Home Assistant again to see the full ecobee card with all of the sensors populated or see the list of sensors in the developer tools. Now you can re-enable your `default_view` (if you had to disable it) and add the ecobee sensors to a group and/or view.
|
||||
|
||||
To set it up, add the following information to your `configuration.yaml` file:
|
||||
@ -62,4 +61,4 @@ Configuration variables:
|
||||
<img src='{{site_root}}/images/screenshots/ecobee-thermostat-card.png' />
|
||||
</p>
|
||||
|
||||
If for whatever reason you delete and re-create your ecobee app at ecobee.com such that your developer API key changes, you will need to delete your `/conf/ecobee.conf file`. You will also need to update the `api_key:` in the `configuration.yaml` or `secrets.yaml` file.
|
||||
If for whatever reason you delete and re-create your ecobee app at ecobee.com such that your developer API key changes, you will need to delete your `/conf/ecobee.conf file`. You will also need to update the `api_key:` in the `configuration.yaml` or `secrets.yaml` file.
|
||||
|
||||
@ -19,13 +19,13 @@ The `xiaomi_miio` fan platform allows you to control the Xiaomi Air Purifier and
|
||||
|
||||
### Air Purifier 2 et al.
|
||||
|
||||
* Power (on, off)
|
||||
* Operation modes (auto, silent, favorite, idle)
|
||||
* Buzzer (on, off)
|
||||
* Child lock (on, off)
|
||||
* LED (on, off), LED brightness (bright, dim, off)
|
||||
* Favorite Level (0...16)
|
||||
* Attributes
|
||||
- Power (on, off)
|
||||
- Operation modes (auto, silent, favorite, idle)
|
||||
- Buzzer (on, off)
|
||||
- Child lock (on, off)
|
||||
- LED (on, off), LED brightness (bright, dim, off)
|
||||
- Favorite Level (0...16)
|
||||
- Attributes
|
||||
- model
|
||||
- temperature
|
||||
- humidity
|
||||
@ -53,12 +53,12 @@ The `xiaomi_miio` fan platform allows you to control the Xiaomi Air Purifier and
|
||||
|
||||
### Air Purifier Pro (zhimi.airpurifier.v6)
|
||||
|
||||
* Power (on, off)
|
||||
* Operation modes (auto, silent, favorite)
|
||||
* Child lock (on, off)
|
||||
* LED (on, off)
|
||||
* Favorite Level (0...16)
|
||||
* Attributes
|
||||
- Power (on, off)
|
||||
- Operation modes (auto, silent, favorite)
|
||||
- Child lock (on, off)
|
||||
- LED (on, off)
|
||||
- Favorite Level (0...16)
|
||||
- Attributes
|
||||
- model
|
||||
- temperature
|
||||
- humidity
|
||||
@ -89,11 +89,11 @@ The `xiaomi_miio` fan platform allows you to control the Xiaomi Air Purifier and
|
||||
|
||||
### Air Purifier V3 (zhimi.airpurifier.v3)
|
||||
|
||||
* Power (on, off)
|
||||
* Operation modes (auto, silent, favorite, idle, medium, high, strong)
|
||||
* Child lock (on, off)
|
||||
* LED (on, off)
|
||||
* Attributes
|
||||
- Power (on, off)
|
||||
- Operation modes (auto, silent, favorite, idle, medium, high, strong)
|
||||
- Child lock (on, off)
|
||||
- LED (on, off)
|
||||
- Attributes
|
||||
- model
|
||||
- aqi
|
||||
- mode
|
||||
@ -121,13 +121,13 @@ The `xiaomi_miio` fan platform allows you to control the Xiaomi Air Purifier and
|
||||
|
||||
### Air Humidifier (zhimi.humidifier.v1)
|
||||
|
||||
* On, Off
|
||||
* Operation modes (silent, medium, high)
|
||||
* Buzzer (on, off)
|
||||
* Child lock (on, off)
|
||||
* LED brightness (bright, dim, off)
|
||||
* Target humidity (30, 40, 50, 60, 70, 80)
|
||||
* Attributes
|
||||
- On, Off
|
||||
- Operation modes (silent, medium, high)
|
||||
- Buzzer (on, off)
|
||||
- Child lock (on, off)
|
||||
- LED brightness (bright, dim, off)
|
||||
- Target humidity (30, 40, 50, 60, 70, 80)
|
||||
- Attributes
|
||||
- model
|
||||
- temperature
|
||||
- humidity
|
||||
@ -143,14 +143,14 @@ The `xiaomi_miio` fan platform allows you to control the Xiaomi Air Purifier and
|
||||
|
||||
### Air Humidifier CA (zhimi.humidifier.ca1)
|
||||
|
||||
* On, Off
|
||||
* Operation modes (silent, medium, high, auto)
|
||||
* Buzzer (on, off)
|
||||
* Child lock (on, off)
|
||||
* LED brightness (bright, dim, off)
|
||||
* Target humidity (30, 40, 50, 60, 70, 80)
|
||||
* Dry mode (on, off)
|
||||
* Attributes
|
||||
- On, Off
|
||||
- Operation modes (silent, medium, high, auto)
|
||||
- Buzzer (on, off)
|
||||
- Child lock (on, off)
|
||||
- LED brightness (bright, dim, off)
|
||||
- Target humidity (30, 40, 50, 60, 70, 80)
|
||||
- Dry mode (on, off)
|
||||
- Attributes
|
||||
- model
|
||||
- temperature
|
||||
- humidity
|
||||
|
||||
@ -131,8 +131,8 @@ The values of variables are polled from the CCU/Homegear in an interval of 30 se
|
||||
|
||||
When HomeMatic devices change their state or some other internal value, the CCU/Homegear sends event messages to Home Assistant. These events are automatically parsed and the entities in Home Assistant are updated. However, you can also manually use these events to trigger automations. Two event-types are available:
|
||||
|
||||
* **homematic.keypress**: For devices with buttons, see information below
|
||||
* **homematic.impulse**: For impulse sensors
|
||||
- **homematic.keypress**: For devices with buttons, see information below
|
||||
- **homematic.impulse**: For impulse sensors
|
||||
|
||||
#### {% linkable_title Devices with buttons %}
|
||||
|
||||
@ -171,13 +171,15 @@ It may happen that "your_nice_name" is not resolved correctly; the according mes
|
||||
|
||||
### {% linkable_title Services %}
|
||||
|
||||
* *homematic.virtualkey*: Simulate a keypress (or other valid action) on CCU/Homegear with device or virtual keys.
|
||||
* *homematic.reconnect*: Reconnect to CCU/Homegear without restarting Home Assistant (useful when CCU has been restarted)
|
||||
* *homematic.set_variable_value*: Set the value of a system variable.
|
||||
* *homematic.set_device_value*: Control a device manually (even devices without support). Equivalent to setValue-method from XML-RPC.
|
||||
- *homematic.virtualkey*: Simulate a keypress (or other valid action) on CCU/Homegear with device or virtual keys.
|
||||
- *homematic.reconnect*: Reconnect to CCU/Homegear without restarting Home Assistant (useful when CCU has been restarted)
|
||||
- *homematic.set_variable_value*: Set the value of a system variable.
|
||||
- *homematic.set_device_value*: Control a device manually (even devices without support). Equivalent to setValue-method from XML-RPC.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
Simulate a button being pressed
|
||||
|
||||
Simulate a button being pressed:
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
@ -188,7 +190,8 @@ action:
|
||||
param: PRESS_LONG
|
||||
```
|
||||
|
||||
Open KeyMatic
|
||||
Open KeyMatic:
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
@ -199,7 +202,8 @@ action:
|
||||
param: OPEN
|
||||
```
|
||||
|
||||
Set boolean variable to true
|
||||
Set boolean variable to true:
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
@ -215,7 +219,8 @@ action:
|
||||
If you are familiar with the internals of HomeMatic devices, you can manually set values on the devices. This can serve as a workaround if support for a device is currently not available, or only limited functionality has been implemented.
|
||||
Using this service provides you direct access to the setValue-method of the primary connection. If you have multiple hosts, you may select the one hosting a specific device by providing the proxy-parameter with a value equivalent to the name you have chosen. In the example configuration from above `rf`, `wired` and `ip` would be valid values.
|
||||
|
||||
Manually turn on a switch actor
|
||||
Manually turn on a switch actor:
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
@ -227,7 +232,8 @@ action:
|
||||
value: true
|
||||
```
|
||||
|
||||
Manually set temperature on thermostat
|
||||
Manually set temperature on thermostat:
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
@ -239,7 +245,8 @@ action:
|
||||
value: 23.0
|
||||
```
|
||||
|
||||
Manually set lock on KeyMatic devices
|
||||
Manually set lock on KeyMatic devices:
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
@ -247,7 +254,8 @@ action:
|
||||
entity_id: lock.leq1234567
|
||||
```
|
||||
|
||||
Manually set unlock on KeyMatic devices
|
||||
Manually set unlock on KeyMatic devices:
|
||||
|
||||
```yaml
|
||||
...
|
||||
action:
|
||||
@ -259,7 +267,7 @@ action:
|
||||
|
||||
When the connection to your HomeMatic CCU or Homegear is lost, Home Assistant will stop getting updates from devices. This may happen after rebooting the CCU for example. Due to the nature of the communication protocol this cannot be handled automatically, so you must call *homematic.reconnect* in this case. That's why it is usually a good idea to check if your HomeMatic components are still updated properly, in order to detect connection losses. This can be done in several ways through an automation:
|
||||
|
||||
* If you have a sensor which you know will be updated frequently (e.g. an outdoor temperature sensor or light sensor) you could set up an automation like this:
|
||||
- If you have a sensor which you know will be updated frequently (e.g. an outdoor temperature sensor or light sensor) you could set up an automation like this:
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
@ -273,7 +281,8 @@ When the connection to your HomeMatic CCU or Homegear is lost, Home Assistant wi
|
||||
# Reconnect, if sensor has not been updated for over 3 hours
|
||||
service: homematic.reconnect
|
||||
```
|
||||
* If you have a CCU you can also create a system variable on the CCU, which stores it's last reboot time. Since Home Assistant can still refresh system variables from the CCU (even after a reboot), this is a pretty reliable way to detect situations where you need to call *homematic.reconnect*. This is how this can be done:
|
||||
|
||||
- If you have a CCU you can also create a system variable on the CCU, which stores it's last reboot time. Since Home Assistant can still refresh system variables from the CCU (even after a reboot), this is a pretty reliable way to detect situations where you need to call *homematic.reconnect*. This is how this can be done:
|
||||
|
||||
1. Create a string variable **V_Last_Reboot** on the CCU
|
||||
|
||||
@ -309,4 +318,3 @@ When the connection to your HomeMatic CCU or Homegear is lost, Home Assistant wi
|
||||
action:
|
||||
service: homematic.reconnect
|
||||
```
|
||||
|
||||
|
||||
@ -29,6 +29,7 @@ isy994:
|
||||
username: ISY_USERNAME
|
||||
password: ISY_PASSWORD
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **host** (*Required*): The host entry should be in full URL format, eg. http://192.168.10.100:80
|
||||
@ -69,15 +70,15 @@ automation:
|
||||
|
||||
All `isy994_control` events will have an `entity_id` and `control` parameter in its `event_data`. You'll need to refer to ISY994 documentation for the list of every possible control type, but the common ones are:
|
||||
|
||||
- `DON`: On button
|
||||
- `DOF`: Off button
|
||||
- `DFON`: "Fast On", usually from double-tapping an On button
|
||||
- `DFOF`: "Fast Off", usually from double-tapping an Off button
|
||||
- `FDUP`: "Fade Up", usually while holding down an On button
|
||||
- `FDDOWN`: "Fade Down", usually while holding down an Off button
|
||||
- `FDSTOP`: "Fade Stop", when releasing a long-held button
|
||||
- `BRT`: "Brighten", from controllers that issue a single command to slightly brighten a light
|
||||
- `DIM`: "Dim", from controllers that issue a single command to slightly dim a light
|
||||
- `DON`: On button.
|
||||
- `DOF`: Off button.
|
||||
- `DFON`: "Fast On", usually from double-tapping an On button.
|
||||
- `DFOF`: "Fast Off", usually from double-tapping an Off button.
|
||||
- `FDUP`: "Fade Up", usually while holding down an On button.
|
||||
- `FDDOWN`: "Fade Down", usually while holding down an Off button.
|
||||
- `FDSTOP`: "Fade Stop", when releasing a long-held button.
|
||||
- `BRT`: "Brighten", from controllers that issue a single command to slightly brighten a light.
|
||||
- `DIM`: "Dim", from controllers that issue a single command to slightly dim a light.
|
||||
|
||||
### {% linkable_title Insteon Scenes %}
|
||||
|
||||
@ -87,7 +88,7 @@ All Insteon scenes configured in the ISY994 will show up as switches in Home Ass
|
||||
|
||||
Using the Programs tab in the controller's Administrative Console, custom devices can be created that will appear natively inside of Home Assistant. Home Assistant will scan the following folders and build the device to the associated domains:
|
||||
|
||||
```
|
||||
```text
|
||||
My Programs
|
||||
├── HA.binary_sensor
|
||||
| ├── Movement In House
|
||||
@ -125,11 +126,12 @@ My Programs
|
||||
```
|
||||
|
||||
A device is created by creating a directory, with the name for the device, under any of the following root directories:
|
||||
* *HA.binary_sensor* will create a binary sensor (see [Customizing Devices](/getting-started/customizing-devices/) to set the sensor class)
|
||||
* *HA.cover* will create a cover
|
||||
* *HA.fan* will create a fan
|
||||
* *HA.lock* will create a lock
|
||||
* *HA.switch* will create a switch
|
||||
|
||||
- *HA.binary_sensor* will create a binary sensor (see [Customizing Devices](/getting-started/customizing-devices/) to set the sensor class).
|
||||
- *HA.cover* will create a cover.
|
||||
- *HA.fan* will create a fan.
|
||||
- *HA.lock* will create a lock.
|
||||
- *HA.switch* will create a switch.
|
||||
|
||||
A program, named *status*, is required under the program device directory. A program, named *actions*, is required for all program devices except for binary_sensor. Any other programs in these device directories will be ignored. The *status* program requires that you create a variable with the name of your choice. This variable will store the actual status of the new device and will be updated by the *action* program.
|
||||
|
||||
@ -138,21 +140,23 @@ A program, named *status*, is required under the program device directory. A pro
|
||||
</p>
|
||||
|
||||
The *status* program in this directory is what indicates the state of the device:
|
||||
* *binary_sensor* on if the clause returns true, otherwise off
|
||||
* *cover* closed if the clause returns true, otherwise open
|
||||
* *fan* on if the clause returns true, otherwise off
|
||||
* *lock* locked if the clause returns true, otherwise unlocked
|
||||
* *switch* on if the clause returns true, otherwise off
|
||||
|
||||
- *binary_sensor* on if the clause returns true, otherwise off.
|
||||
- *cover* closed if the clause returns true, otherwise open.
|
||||
- *fan* on if the clause returns true, otherwise off.
|
||||
- *lock* locked if the clause returns true, otherwise unlocked.
|
||||
- *switch* on if the clause returns true, otherwise off.
|
||||
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/isy994/isy994_SwitchStatusExample.png' />
|
||||
</p>
|
||||
|
||||
The *actions* program indicates what should be performed for the following device services:
|
||||
* *cover* the THEN clause is evaluated for the open_cover service, the ELSE clause is evaluated for the close_cover service
|
||||
* *fan* the THEN clause is evaluated for the turn_on service, the ELSE clause is evaluated for the turn_off service
|
||||
* *lock* the THEN clause is evaluated for the lock service, the ELSE clause is evaluated for the unlock service
|
||||
* *switch* the THEN clause is evaluated for the turn_on service, the ELSE clause is evaluated for the turn_off service
|
||||
|
||||
- *cover* the THEN clause is evaluated for the open_cover service, the ELSE clause is evaluated for the close_cover service.
|
||||
- *fan* the THEN clause is evaluated for the turn_on service, the ELSE clause is evaluated for the turn_off service.
|
||||
- *lock* the THEN clause is evaluated for the lock service, the ELSE clause is evaluated for the unlock service.
|
||||
- *switch* the THEN clause is evaluated for the turn_on service, the ELSE clause is evaluated for the turn_off service.
|
||||
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/isy994/isy994_SwitchActionsExample.png' />
|
||||
|
||||
@ -12,7 +12,6 @@ ha_category: Hub
|
||||
ha_release: "0.24"
|
||||
---
|
||||
|
||||
|
||||
The `joaoapps_join` component exposes services from [Join](http://joaoapps.com/join). In Home Assistant, the Join features are divided up in two locations, the Join component, and the Join notify platform. The notify platform allows us to send messages to Join devices, the component allows us to access the other special features that Join offers.
|
||||
|
||||
In the `configuration.yaml` file you need to provide the api key and device id or name of the target device. You can find your device id and api key [here](https://joinjoaomgcd.appspot.com/).
|
||||
@ -57,4 +56,3 @@ The services exposed in the `joaoapps_join` component can be used with the servi
|
||||
| joaoapps_join/send_url | `{"url":"http://google.com"}` |
|
||||
| joaoapps_join/send_wallpaper | `{"url":"http://www.planwallpaper.com/static/images/ZhGEqAP.jpg"}` |
|
||||
| joaoapps_join/send_file | `{"url":"http://download.thinkbroadband.com/5MB.zip"}` |
|
||||
|
||||
|
||||
@ -12,7 +12,6 @@ ha_category: Hub
|
||||
ha_release: 0.47
|
||||
---
|
||||
|
||||
|
||||
The `juicenet` sensor platform pulls data from a [JuiceNet](https://emotorwerks.com/products/juicenet/) charging station equipped with a wifi connection. It will access and make available all of the devices attached to your account.
|
||||
|
||||
## {% linkable_title Configuration %}
|
||||
|
||||
@ -12,15 +12,14 @@ ha_category: Automation
|
||||
ha_release: pre 0.7
|
||||
---
|
||||
|
||||
|
||||
The `keyboard` component simulates key presses on the host machine. It currently offers the following Buttons as a Service (BaaS):
|
||||
|
||||
* `keyboard/volume_up`
|
||||
* `keyboard/volume_down`
|
||||
* `keyboard/volume_mute`
|
||||
* `keyboard/media_play_pause`
|
||||
* `keyboard/media_next_track`
|
||||
* `keyboard/media_prev_track`
|
||||
- `keyboard/volume_up`
|
||||
- `keyboard/volume_down`
|
||||
- `keyboard/volume_mute`
|
||||
- `keyboard/media_play_pause`
|
||||
- `keyboard/media_next_track`
|
||||
- `keyboard/media_prev_track`
|
||||
|
||||
To load this component, add the following lines to your `configuration.yaml`:
|
||||
|
||||
@ -33,7 +32,7 @@ keyboard:
|
||||
You may need to install platform-specific [dependencies for PyUserInput](https://github.com/PyUserInput/PyUserInput#dependencies) in order to use the keyboard component. In most cases this can be done by running:
|
||||
|
||||
```bash
|
||||
$ pip3 install [package name]
|
||||
pip3 install [package name]
|
||||
```
|
||||
|
||||
#### {% linkable_title Windows %}
|
||||
|
||||
@ -19,7 +19,6 @@ This component allows you to use one or more keyboards as remote controls. It wi
|
||||
|
||||
The `evdev` package is used to interface with the keyboard and thus this is Linux only. It also means you can't use your normal keyboard for this because `evdev` will block it.
|
||||
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
keyboard_remote:
|
||||
@ -47,7 +46,7 @@ keyboard_remote:
|
||||
type: 'key_up'
|
||||
```
|
||||
|
||||
or like the following for one keyboard:
|
||||
Or like the following for one keyboard:
|
||||
|
||||
```yaml
|
||||
keyboard_remote:
|
||||
@ -70,15 +69,18 @@ automation:
|
||||
service: light.turn_on
|
||||
entity_id: light.all
|
||||
```
|
||||
|
||||
`device_descriptor` or `device_name` may be specificed in the trigger so the automation will be fired only for that keyboard. This is especially useful if you wish to use several bluetooth remotes to control different devices. Omit them to ensure the same key triggers the automation for all keyboards/remotes.
|
||||
|
||||
## {% linkable_title Disconnections %}
|
||||
|
||||
This component manages disconnections and re-connections of the keyboard, for example in the case of a Bluetooth device that turns off automatically to preserve battery.
|
||||
|
||||
If the keyboard disconnects, the component will fire an event `keyboard_remote_disconnected`.
|
||||
When the keyboard reconnects, an event `keyboard_remote_connected` will be fired.
|
||||
|
||||
Here's an automation example that plays a sound through a media player whenever the keyboard connects/disconnects:
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: Keyboard Connected
|
||||
@ -104,13 +106,14 @@ automation:
|
||||
```
|
||||
|
||||
## {% linkable_title Permissions %}
|
||||
|
||||
There might be permissions problems with the event input device file. If this is the case, the user that Home Assistant runs as must be allowed read and write permissions with:
|
||||
|
||||
```bash
|
||||
$ sudo setfacl -m u:HASS_USER:rw /dev/input/event*
|
||||
sudo setfacl -m u:HASS_USER:rw /dev/input/event*
|
||||
```
|
||||
|
||||
where `HASS_USER` is the user who runs Home Assistant.
|
||||
Where `HASS_USER` is the user who runs Home Assistant.
|
||||
|
||||
If you want to make this permanent, you can use a udev rule that sets it for all event input devices. Add a file `/etc/udev/rules.d/99-userdev-input.rules` containing:
|
||||
|
||||
@ -118,8 +121,8 @@ If you want to make this permanent, you can use a udev rule that sets it for all
|
||||
KERNEL=="event*", SUBSYSTEM=="input", RUN+="/usr/bin/setfacl -m u:HASS_USER:rw $env{DEVNAME}"
|
||||
```
|
||||
|
||||
You can check ACLs permissions with
|
||||
You can check ACLs permissions with:
|
||||
|
||||
```bash
|
||||
$ getfacl /dev/input/event*
|
||||
getfacl /dev/input/event*
|
||||
```
|
||||
|
||||
@ -39,6 +39,7 @@ kira:
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **sensors** (*Optional*): Kira sensors to register
|
||||
- **name** (*Optional*): Name of this sensor.
|
||||
- **host** (*Optional*): Bind address for this sensor. 0.0.0.0 is default.
|
||||
@ -70,6 +71,7 @@ The first time the Kira component is loaded, `kira_codes.yaml` will be created i
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **name** (*Required*): The name of this code.
|
||||
- **code** (*Required*): The data for this code (see below).
|
||||
- **device** (*Optional*): The device this code is associated with. Default is "unknown".
|
||||
@ -81,6 +83,7 @@ Some manufacturers (e.g., Samsung) require an IR code to be sent a number of tim
|
||||
### {% linkable_title Code Types %}
|
||||
|
||||
When creating an entry in `kira_codes.yaml`, a few different kinds of codes can be used.
|
||||
|
||||
- **kira**: This is the native wire protocol used by Kira modules. These can be captured using netcat.
|
||||
- **pronto**: Pronto codes are supported.
|
||||
- **nec**: If the device uses NEC IR codes and the manufacturer has published them, they can be used here.
|
||||
|
||||
@ -14,7 +14,7 @@ ha_release: "0.70"
|
||||
|
||||
The `konnected` component lets you connect wired sensors and switches to a NodeMCU ESP8226 based device running the [open source Konnected software](https://github.com/konnected-io/konnected-security). Reuse the wired sensors and siren from an old or pre-wired alarm system installation and integrate them directly into Home Assistant.
|
||||
|
||||
Visit the [Konnected.io website](https://konnected.io) for more information about the Konnected Alarm Panel board and compatible hardware.
|
||||
Visit the [Konnected.io website](https://konnected.io) for more information about the Konnected Alarm Panel board and compatible hardware.
|
||||
|
||||
The component currently supports the following device types in Home Assistant:
|
||||
|
||||
@ -45,7 +45,7 @@ konnected:
|
||||
switches:
|
||||
- pin: 5
|
||||
```
|
||||
|
||||
|
||||
{% configuration %}
|
||||
access_token:
|
||||
description: Any random string. This is used to ensure that only those devices which you have configured can authenticate to Home Assistant to change a device state.
|
||||
@ -55,7 +55,7 @@ api_host:
|
||||
description: Override the IP address/host (and port number) of Home Assistant that the Konnected device(s) will use to communicate sensor state updates. If omitted, this is defaulted to the value of `base_url` in the `http` component. If you've set `base_url` to an external hostname, then you'll want to set this value back to your _local_ IP address and port (e.g. `http://192.168.1.101:8123`).
|
||||
required: false
|
||||
type: url
|
||||
default: value of `base_url`
|
||||
default: value of `base_url`
|
||||
devices:
|
||||
description: A list of Konnected devices that you have on your network.
|
||||
required: true
|
||||
@ -71,15 +71,15 @@ devices:
|
||||
type: list
|
||||
keys:
|
||||
pin:
|
||||
description: The number corresponding to the _IO index_ of the labeled pin on the NodeMCU dev board. See the [NodeMCU GPIO documentation](https://nodemcu.readthedocs.io/en/master/en/modules/gpio/) for more details. Valid values are 1, 2, 5, 6, 7 and 9.
|
||||
description: The number corresponding to the _IO index_ of the labeled pin on the NodeMCU dev board. See the [NodeMCU GPIO documentation](https://nodemcu.readthedocs.io/en/master/en/modules/gpio/) for more details. Valid values are 1, 2, 5, 6, 7 and 9.
|
||||
required: exclusive
|
||||
zone:
|
||||
description: The number corresponding to the labeled zone on the [Konnected Alarm Panel](https://konnected.io) board. Valid values are 1, 2, 3, 4, 5 and 6.
|
||||
required: exclusive
|
||||
type:
|
||||
description: Any [binary sensor](/components/binary_sensor/) class, typically `door`, `window`, `motion` or `smoke`.
|
||||
required: true
|
||||
name:
|
||||
required: true
|
||||
name:
|
||||
description: The name of the device used in the front end.
|
||||
required: false
|
||||
default: automatically generated
|
||||
@ -89,12 +89,12 @@ devices:
|
||||
type: list
|
||||
keys:
|
||||
pin:
|
||||
description: The number corresponding to the _IO index_ of the labeled pin on the NodeMCU dev board. See the [NodeMCU GPIO documentation](https://nodemcu.readthedocs.io/en/master/en/modules/gpio/) for more details. Valid values are 1, 2, 5, 6, 7 and 8.
|
||||
description: The number corresponding to the _IO index_ of the labeled pin on the NodeMCU dev board. See the [NodeMCU GPIO documentation](https://nodemcu.readthedocs.io/en/master/en/modules/gpio/) for more details. Valid values are 1, 2, 5, 6, 7 and 8.
|
||||
required: exclusive
|
||||
zone:
|
||||
description: The number corresponding to the labeled zone on the [Konnected Alarm Panel](https://konnected.io) board or the word `out` to specify the dedicated ALARM/OUT terminal on the Konnected board. Valid values are 1, 2, 3, 4, 5 and out.
|
||||
required: exclusive
|
||||
name:
|
||||
name:
|
||||
description: The name of the device used in the front end.
|
||||
required: false
|
||||
default: automatically generated
|
||||
@ -104,7 +104,7 @@ devices:
|
||||
required: false
|
||||
{% endconfiguration%}
|
||||
|
||||
#### Configuration Notes
|
||||
#### {% linkable_title Configuration Notes %}
|
||||
|
||||
- Either **pin** or **zone** is required for each actuator or sensor. Do not use both in the same definition.
|
||||
- Pin `D8` or the `out` zone will only work when activation is set to high (the default).
|
||||
@ -145,12 +145,12 @@ konnected:
|
||||
|
||||
Konnected runs on an ESP8266 board with the NodeMCU firmware. It is commonly used with the NodeMCU dev kit WiFi module and optionally Konnected's Alarm Panel hardware. The following table shows the pin mapping between the Konnected hardware labeled zones, the NodeMCU labeled pins and the ESP8266 GPIO pins.
|
||||
|
||||
| Konnected Alarm Panel Zone | NodeMCU pin | IO Index | ESP8266 GPIO |
|
||||
| Konnected Alarm Panel Zone | NodeMCU pin | IO Index | ESP8266 GPIO |
|
||||
|---|---|---|---|
|
||||
| 1 | D1 | 1 | GPIO5 |
|
||||
| 2 | D2 | 2 | GPIO4 |
|
||||
| 1 | D1 | 1 | GPIO5 |
|
||||
| 2 | D2 | 2 | GPIO4 |
|
||||
| 3 | D5 | 5 | GPIO14 |
|
||||
| 4 | D6 | 6 | GPIO12 |
|
||||
| 5 | D7 | 7 | GPIO13 |
|
||||
| 6 | RX | 9 | GPIO3 |
|
||||
| ALARM or OUT | D8 | 8 | GPIO15 |
|
||||
| ALARM or OUT | D8 | 8 | GPIO15 |
|
||||
|
||||
@ -13,13 +13,11 @@ ha_release: 0.9
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The Wink lock platform allows you to control your [Wink](http://www.wink.com/) locks.
|
||||
|
||||
The requirement is that you have setup [Wink](/components/wink/).
|
||||
|
||||
|
||||
### Supported lock devices
|
||||
### {% linkable_title Supported lock devices %}
|
||||
|
||||
- Kwikset
|
||||
- Schlage
|
||||
@ -56,7 +54,7 @@ You can use the service wink/wink_set_lock_alarm_sensitivity to set the alarm se
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `sensitivity` | no | String one of low, medium_low, medium, medium_high, high
|
||||
| `sensitivity` | no | String one of low, medium_low, medium, medium_high, high.
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`s of locks.
|
||||
|
||||
Example:
|
||||
@ -140,7 +138,6 @@ You can use the service wink/wink_add_new_lock_key_code to add a new user code t
|
||||
| `name` | no | the name of the new key code
|
||||
| `code` | no | The new code. Must match length of existing codes.
|
||||
|
||||
|
||||
<p class='note'>
|
||||
Calling service wink/pull_newly_added_wink_devices will add the new key code to Home Assistant. The device will also show up on the next restart of Home Assistant.
|
||||
</p>
|
||||
|
||||
@ -12,7 +12,6 @@ ha_category: Notifications
|
||||
ha_release: 0.67
|
||||
---
|
||||
|
||||
|
||||
The `mastodon` platform uses [MAstodon](https://joinmastodon.org/) to delivery notifications from Home Assistant.
|
||||
|
||||
Go to **Preferences** in the Mastodon web interface, then to **Development** and create a new application.
|
||||
|
||||
@ -13,7 +13,6 @@ ha_release: pre 0.7
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
Integrate your [Efergy](https://efergy.com) meter information into Home Assistant.
|
||||
|
||||
## {% linkable_title Setup %}
|
||||
@ -49,15 +48,13 @@ sensor:
|
||||
Configuration variables:
|
||||
|
||||
- **app_token** (*Required*): The App Token for your account.
|
||||
- **utc_offset** (*Required*): Some variables (currently only the daily_cost) require that the
|
||||
negative number of minutes your timezone is ahead/behind UTC time.
|
||||
- **utc_offset** (*Required*): Some variables (currently only the daily_cost) require that the negative number of minutes your timezone is ahead/behind UTC time.
|
||||
- **monitored_variables** array (*Required*): Variables to monitor.
|
||||
- **type** (*Required*): Name of the variable.
|
||||
- **instant_readings**: Instant energy consumption.
|
||||
- **budget**: Monthly budget.
|
||||
- **cost**: The cost for energy consumption (with the tariff that has been set in Efergy) over a given period.
|
||||
- **amount**: The amount of energy consumed over a given period.
|
||||
- **current_values**: This returns the current energy usage of each device on your account, as `efergy_\<sid of device\>`. If you only have one device in your account, this is effectively the same as instant_readings.
|
||||
- **instant_readings**: Instant energy consumption.
|
||||
- **budget**: Monthly budget.
|
||||
- **cost**: The cost for energy consumption (with the tariff that has been set in Efergy) over a given period.
|
||||
- **amount**: The amount of energy consumed over a given period.
|
||||
- **current_values**: This returns the current energy usage of each device on your account, as `efergy_\<sid of device\>`. If you only have one device in your account, this is effectively the same as instant_readings.
|
||||
- **period** (*Optional*): Some variables take a period argument. Valid options are "day", "week", "month", and "year".
|
||||
- **currency** (*Optional*): This is used to display the cost/period as the unit when monitoring the cost. It should correspond to the actual currency used in your dashboard.
|
||||
|
||||
|
||||
@ -13,12 +13,12 @@ ha_release: 0.36
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
|
||||
The `fritzbox_netmonitor` sensor monitors the network statistics exposed by [AVM Fritz!Box](http://avm.de/produkte/fritzbox/) routers.
|
||||
|
||||
<p class='note warning'>
|
||||
It might be necessary to install additional packages: <code>$ sudo apt-get install libxslt-dev libxml2-dev python3-lxml</code>
|
||||
If you are working with the All-in-One installation, you may also need to execute also within your virtual environment the command <code> pip install lxml</code>; be patient this will take a while.</p>
|
||||
If you are working with the All-in-One installation, you may also need to execute also within your virtual environment the command <code> pip install lxml</code>; be patient this will take a while.
|
||||
</p>
|
||||
|
||||
To use the Fritz!Box network monitor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
||||
@ -20,6 +20,7 @@ Direct connection via serial (RS485) or via telnet terminal server is supported.
|
||||
Since this serial protocol is proprietary and closed, only most temperature sensors and a few control relays are supported, the rest is still WIP (see https://www.mikrocontroller.net/topic/274137).
|
||||
|
||||
Direct connection via serial port:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
- platform: kwb
|
||||
@ -30,6 +31,7 @@ Direct connection via serial port:
|
||||
```
|
||||
|
||||
Telnet terminal server with a serial-ethernet converter:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
- platform: kwb
|
||||
|
||||
@ -14,7 +14,6 @@ ha_iot_class: "Cloud Push"
|
||||
redirect_from: /components/sensor.loop_energy/
|
||||
---
|
||||
|
||||
|
||||
Integrate your [Loop Energy](https://www.your-loop.com/) meter information into Home Assistant. To use this sensor you need the client serial number and secret keys for your devices.
|
||||
|
||||
The library used to get the data isn't officially supported and the only way to get the keys is to log into loop energy's website and type a command into your browser console.
|
||||
|
||||
@ -13,7 +13,6 @@ 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`:
|
||||
@ -55,10 +54,8 @@ ssl:
|
||||
default: false
|
||||
{% endconfiguration %}
|
||||
|
||||
|
||||
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>
|
||||
|
||||
|
||||
@ -13,7 +13,6 @@ ha_iot_class: "Cloud Polling"
|
||||
ha_release: "0.50"
|
||||
---
|
||||
|
||||
|
||||
The `uk_transport` sensor will display the time in minutes until the next departure in a specified direction from of a configured train station or bus stop. The sensor uses [transportAPI](http://www.transportapi.com/) to query live departure data and requires a developer application ID and key which can be obtained [here](https://developer.transportapi.com/). The [free tier](http://www.transportapi.com/plans/) allows 1000 requests daily, which is sufficient for a single sensor refreshing every 87 seconds.
|
||||
|
||||
<p class='note warning'>
|
||||
@ -26,7 +25,6 @@ Train departure sensors require three character long `origin` and `destination`
|
||||
|
||||
To add a single train departure sensor add the following to your `configuration.yaml` file:
|
||||
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry for a single sensor
|
||||
sensor:
|
||||
@ -69,17 +67,15 @@ A large amount of information about upcoming departures is available within the
|
||||
next_trains_platform:
|
||||
friendly_name: 'Next train platform'
|
||||
value_template: {% raw %}'{{states.sensor.next_train_to_wat.attributes.next_trains[0].platform}}'{% endraw %}
|
||||
|
||||
```
|
||||
|
||||
Bus sensors require as their `origin` a bus stop ATCO code which can be found by browsing OpenStreetMap data as
|
||||
follows:
|
||||
|
||||
1. On [OpenStreetMap.org](http://www.openstreetmap.org/) zoom right in on a bus
|
||||
stop you're interested in
|
||||
2. Click the layers picker button on the right hand side
|
||||
3. Tick the 'map data' layer, and wait for clickable objects to load
|
||||
4. Click the bus stop node to reveal its tags on the left
|
||||
1. On [OpenStreetMap.org](http://www.openstreetmap.org/) zoom right in on a bus stop you're interested in.
|
||||
2. Click the layers picker button on the right hand side.
|
||||
3. Tick the 'map data' layer, and wait for clickable objects to load.
|
||||
4. Click the bus stop node to reveal its tags on the left.
|
||||
|
||||
The `destination` must be a valid location in the "direction" field returned by a GET query to `/uk/bus/stop/{atcocode}/live.json` as described in the [API reference webpage](https://developer.transportapi.com/docs?raml=https://transportapi.com/v3/raml/transportapi.raml##bus_information). A bus sensor is added in the following `configuration.yaml` file entry:
|
||||
|
||||
@ -116,7 +112,6 @@ And the template sensor for viewing the next bus attributes.
|
||||
next_bus_estimated:
|
||||
friendly_name: 'Next bus estimated'
|
||||
value_template: {% raw %}'{{states.sensor.next_bus_to_wantage.attributes.next_buses[0].estimated}}'{% endraw %}
|
||||
|
||||
```
|
||||
|
||||
Powered by [transportAPI](http://www.transportapi.com/)
|
||||
|
||||
@ -15,8 +15,7 @@ ha_release: 0.37
|
||||
|
||||
The `wsdot` sensor will give you travel time information from the [Washington State Department of Transportation (WSDOT)](http://wsdot.com/).
|
||||
|
||||
First, you need to get a free Traveler Information `api_key` from the [WSDOT API webpage](http://wsdot.com/traffic/api/). Just enter your email address to instantly get the key.
|
||||
|
||||
First, you need to get a free Traveler Information `api_key` from the [WSDOT API webpage](http://wsdot.com/traffic/api/). Just enter your email address to instantly get the key.
|
||||
|
||||
Once you have the code, create `wsdot` sensors by editing your `configuration.yaml` file as follows:
|
||||
|
||||
@ -38,11 +37,11 @@ Configuration variables:
|
||||
- **id** (*Required*): Name of the route.
|
||||
- **name** (*Optional*): Name of the route. Default just uses `id`.
|
||||
|
||||
Figuring out which Travel Time ID (`id`) is associated with your routes is a bit of a challenge. If you visit `http://wsdot.com/Traffic/api/TravelTimes/TravelTimesREST.svc/GetTravelTimesAsJson?AccessCode=[your_api_key_here]` substituting your `api_key`, you will get a list of all available routes. Search through it and then find the key `TravelTimeID`. That tells you the number you need.
|
||||
Figuring out which Travel Time ID (`id`) is associated with your routes is a bit of a challenge. If you visit `http://wsdot.com/Traffic/api/TravelTimes/TravelTimesREST.svc/GetTravelTimesAsJson?AccessCode=[your_api_key_here]` substituting your `api_key`, you will get a list of all available routes. Search through it and then find the key `TravelTimeID`. That tells you the number you need.
|
||||
|
||||
Some common examples include:
|
||||
|
||||
```
|
||||
```text
|
||||
73 Issaquah-Seattle (WB PM)
|
||||
74 Seattle-Issaquah (EB AM)
|
||||
75 HOV Issaquah-Seattle (WB REV)
|
||||
@ -78,4 +77,3 @@ Here's an example of the sensor in use:
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/screenshots/wsdot_sensor.png' />
|
||||
</p>
|
||||
|
||||
|
||||
@ -13,7 +13,6 @@ ha_release: 0.27
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `wunderground` platform uses [Weather Underground](http://www.wunderground.com) as a source for current weather information.
|
||||
|
||||
<p class='note warning'>
|
||||
@ -119,8 +118,7 @@ in the `_1h_` part of the sensor name with `1` to `36`. e.g., `weather_24h` will
|
||||
|
||||
### {% linkable_title Additional examples %}
|
||||
|
||||
#### Daily forecast
|
||||
|
||||
#### {% linkable_title Daily forecast %}
|
||||
|
||||
```yaml
|
||||
sensor:
|
||||
@ -152,8 +150,7 @@ group:
|
||||
|
||||
|
||||
|
||||
#### Weather overview
|
||||
|
||||
#### {% linkable_title Weather overview %}
|
||||
|
||||
```yaml
|
||||
sensor:
|
||||
@ -190,13 +187,12 @@ group:
|
||||
|
||||
|
||||
|
||||
|
||||
<p class='note warning'>
|
||||
Note: While the platform is called “wunderground” the sensors will show up in Home Assistant as “PWS” (eg: sensor.pws_weather).
|
||||
</p>
|
||||
|
||||
Note that the Weather Underground sensor is added to the entity_registry, so second and subsequent Personal Weather Station ID (pws_id) will have their monitored conditions suffixed with an index number e.g.
|
||||
|
||||
- sensor.pws_weather_1d_metric_2
|
||||
- sensor.pws_weather_1d_metric_2
|
||||
|
||||
Additional details about the API are available [here](https://www.wunderground.com/weather/api/d/docs).
|
||||
|
||||
@ -17,8 +17,8 @@ The `xiaomi_miio` sensor platform is observing your Xiaomi Mi Air Quality Monito
|
||||
|
||||
Currently, the supported features are:
|
||||
|
||||
* Air Quality Index (AQI)
|
||||
* Attributes
|
||||
- Air Quality Index (AQI)
|
||||
- Attributes
|
||||
- power
|
||||
- charging
|
||||
- battery
|
||||
|
||||
@ -24,7 +24,6 @@ Info on how to get API access is described in the [smappy wiki](https://github.c
|
||||
|
||||
To use the `smappee` component in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
smappee:
|
||||
|
||||
@ -18,7 +18,7 @@ The `rachio` switch platform allows you to toggle zones connected to your [Rachi
|
||||
Once configured, a switch will be added for every zone that is enabled on every controller in the account provided, as well as a switch to toggle each controller's standby mode.
|
||||
|
||||
<p class='note'>
|
||||
You must have the [Rachio component](/components/rachio/) configured to use this switch.
|
||||
You must have the [Rachio component](/components/rachio/) configured to use this switch.
|
||||
</p>
|
||||
|
||||
To add this platform to your installation, add the following to your `configuration.yaml` file:
|
||||
@ -44,7 +44,6 @@ In this section, you find some real-life examples of how to use this switch.
|
||||
|
||||
### {% linkable_title `groups.yaml` example %}
|
||||
|
||||
|
||||
```yaml
|
||||
irrigation:
|
||||
name: Irrigation
|
||||
|
||||
@ -13,7 +13,6 @@ ha_release: 0.41
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `tado` component platform is used as an interface to the [my.tado.com](https://my.tado.com/webapp/#/account/sign-in) website. It adds climate devices for every tado zone and sensors for some additional information of the zones.
|
||||
|
||||
To use your tado thermostats in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
@ -136,13 +136,13 @@ easily via a hidden menu item at the Mi-Home app or using the `miio` command lin
|
||||
You can install the command line tool with:
|
||||
|
||||
```bash
|
||||
$ npm install -g miio
|
||||
npm install -g miio
|
||||
```
|
||||
|
||||
Discovering devices on current network
|
||||
|
||||
```bash
|
||||
$ miio discover
|
||||
miio discover
|
||||
```
|
||||
|
||||
This will list devices that are connected to the same network as your computer. Let it run for a while so it has a chance to reach all devices, as it might take a minute or two for all devices to answer.
|
||||
@ -159,10 +159,10 @@ Support: At least basic
|
||||
|
||||
The information output is:
|
||||
|
||||
* __Device ID__ - the unique identifier of the device, does not change if the device is reset.
|
||||
* __Model ID__ - the model id if it could be determined, this indicates what type of device it is
|
||||
* __Address__ - the IP that the device has on the network
|
||||
* __Token__ - the token of the device or ??? if it could not be automatically determined
|
||||
- __Device ID__ - the unique identifier of the device, does not change if the device is reset.
|
||||
- __Model ID__ - the model id if it could be determined, this indicates what type of device it is
|
||||
- __Address__ - the IP that the device has on the network
|
||||
- __Token__ - the token of the device or ??? if it could not be automatically determined
|
||||
|
||||
#### {% linkable_title Windows and Android %}
|
||||
|
||||
@ -174,7 +174,7 @@ To fetch the token follow these instructions depending on your mobile phone plat
|
||||
4. Change the MiToolKit language to English if you need to.
|
||||
5. Click "Extract Token"
|
||||
6. On the phone, you must confirm the backup. DO NOT enter any password and press the button to make the backup.
|
||||
8. Once you have confirmed the backup the token extraction will begin, it should appear in the MiToolKit shortly.
|
||||
7. Once you have confirmed the backup the token extraction will begin, it should appear in the MiToolKit shortly.
|
||||
|
||||
#### {% linkable_title Linux and Android (not rooted) %}
|
||||
|
||||
@ -183,14 +183,14 @@ Follow the pairing process using your phone and Mi-Home app. You will be able to
|
||||
Before you begin you need to install `libffi-dev` and `libssl-dev` by running the command below. This is needed for `python-miio` to be installed correctly.
|
||||
|
||||
```bash
|
||||
$ sudo apt-get install libffi-dev libssl-dev
|
||||
sudo apt-get install libffi-dev libssl-dev
|
||||
```
|
||||
|
||||
If your Home Assistant installation is running in a [Virtualenv](/docs/installation/virtualenv/#upgrading-home-assistant), make sure you activate it by running the commands below.
|
||||
|
||||
```bash
|
||||
$ sudo -u homeassistant -H -s
|
||||
$ source /srv/homeassistant/bin/activate
|
||||
sudo -u homeassistant -H -s
|
||||
source /srv/homeassistant/bin/activate
|
||||
```
|
||||
|
||||
To fetch the token follow these instructions depending on your mobile phone platform.
|
||||
@ -205,7 +205,6 @@ To fetch the token follow these instructions depending on your mobile phone plat
|
||||
8. Untar the unpacked data: `tar -xvf unpacked.tar`
|
||||
9. `sqlite3 apps/com.xiaomi.smarthome/db/miio2.db 'select token from devicerecord where name like "%Vacuum%";'` returns the token for your Xiaomi vacuum bot.
|
||||
|
||||
|
||||
#### {% linkable_title Linux and Android (rooted!) %}
|
||||
|
||||
Follow the pairing process using your phone and Mi-Home app. You will be able to retrieve the token from a SQLite file inside your phone.
|
||||
@ -213,14 +212,14 @@ Follow the pairing process using your phone and Mi-Home app. You will be able to
|
||||
Before you begin you need to install `libffi-dev` and `libssl-dev` by running the command below. This is needed for `python-miio` to be installed correctly.
|
||||
|
||||
```bash
|
||||
$ sudo apt-get install libffi-dev libssl-dev
|
||||
sudo apt-get install libffi-dev libssl-dev
|
||||
```
|
||||
|
||||
If your Home Assistant installation is running in a [Virtualenv](/docs/installation/virtualenv/#upgrading-home-assistant), make sure you activate it by running the commands below.
|
||||
|
||||
```bash
|
||||
$ sudo -u homeassistant -H -s
|
||||
$ source /srv/homeassistant/bin/activate
|
||||
sudo -u homeassistant -H -s
|
||||
source /srv/homeassistant/bin/activate
|
||||
```
|
||||
|
||||
To fetch the token follow these instructions depending on your mobile phone platform.
|
||||
|
||||
@ -22,4 +22,4 @@ It is HIGHLY recommended that you set the `api_password`, especially if you are
|
||||
websocket_api:
|
||||
```
|
||||
|
||||
For details to use the WebSocket API, please refer to the [WebSocket API documentation](/developers/websocket_api/) .
|
||||
For details to use the WebSocket API, please refer to the [WebSocket API documentation](/developers/websocket_api/) .
|
||||
|
||||
@ -9,9 +9,8 @@ footer: true
|
||||
ha_category: Usage
|
||||
---
|
||||
|
||||
After upgrading to a new version, you may notice your browser gets stuck at the "loading data" login screen. Close the window/tab and go into your browser settings and delete all the cookies for your URL. You can then log back in and it should work.
|
||||
|
||||
After upgrading to a new version, you may notice your browser gets stuck at the "loading data" login screen. Close the window/tab and go into your browser settings and delete all the cookies for your URL. You can then log back in and it should work.
|
||||
|
||||
Android Chrome
|
||||
Android Chrome:
|
||||
|
||||
chrome -> settings -> site settings -> storage -> search for your URL for Home Assistant-> "clear & reset"
|
||||
|
||||
@ -9,5 +9,4 @@ footer: true
|
||||
ha_category: Usage
|
||||
---
|
||||
|
||||
|
||||
Close the windows or tab and clear the cache. The frontend is aggressively caching and clearing the cache ensures that the frontend is reloaded when you access it the next time.
|
||||
|
||||
@ -9,7 +9,6 @@ footer: true
|
||||
ha_category: Configuration
|
||||
---
|
||||
|
||||
|
||||
When a component does not show up, many different things can be the case. Before you try any of these steps, make sure to look at the `home-assistant.log` file and see if there are any errors related to your component you are trying to set up.
|
||||
|
||||
If you have incorrect entries in your configuration files you can use the `check_config` script to assist in identifying them: `hass --script check_config`.
|
||||
|
||||
@ -9,5 +9,4 @@ footer: true
|
||||
ha_category: Configuration
|
||||
---
|
||||
|
||||
|
||||
And not JSON or XML for the [configuration file](/docs/configuration/)? Because [YAML](/docs/configuration/yaml/) can be written by hand, you don't have to care about commas or tag and it's a superset of JSON.
|
||||
|
||||
@ -9,7 +9,6 @@ footer: true
|
||||
ha_category: Usage
|
||||
---
|
||||
|
||||
|
||||
It can happen that you get a traceback that notify you about connection issues while running Home Assistant. Eg.
|
||||
|
||||
```bash
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user