Merge branch 'current' into next
This commit is contained in:
Paulus Schoutsen
commit
be8ea1aef1
77 changed files with 1151 additions and 293 deletions
|
|
@ -27,7 +27,7 @@ binary_sensor:
|
|||
monitored_conditions:
|
||||
- 'fan'
|
||||
- 'hvac_ac_state'
|
||||
'hvac_heater_state'
|
||||
- 'hvac_heater_state'
|
||||
- 'hvac_aux_heater_state'
|
||||
- 'hvac_heat_x2_state'
|
||||
- 'hvac_heat_x3_state'
|
||||
|
|
|
|||
|
|
@ -20,3 +20,176 @@ climate:
|
|||
platform: demo
|
||||
```
|
||||
|
||||
## {% linkable_title Services %}
|
||||
|
||||
### {% linkable_title Climate control services %}
|
||||
Available services: `climate.set_aux_heat`, `climate.set_away_mode`, `climate.set_temperature`, `climate.set_humidity`, `climate.set_fan_mode`, `climate.set_operation_mode`, `climate.set_swing_mode`
|
||||
|
||||
<p class='note'>
|
||||
Not all climate services may be available for your platform. Be sure to check the available services Home Assistant has enabled by checking <img src='/images/screenshots/developer-tool-services-icon.png' alt='service developer tool icon' class="no-shadow" height="38" /> **Services**.
|
||||
</p>
|
||||
|
||||
### {% linkable_title Service `climate.set_aux_heat` %}
|
||||
|
||||
Turn auxiliary heater on/off for climate device
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`'s of climate devices to control. Else targets all.
|
||||
| `aux_heat` | no | New value of auxiliary heater.
|
||||
|
||||
#### {% linkable_title Automation example %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
platform: time
|
||||
after: "07:15:00"
|
||||
action:
|
||||
- service: climate.set_aux_heat
|
||||
data:
|
||||
entity_id: climate.kitchen
|
||||
aux_heat: true
|
||||
```
|
||||
|
||||
### {% linkable_title Service `climate.set_away_mode` %}
|
||||
|
||||
Turn away mode on/off for climate device
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`'s of climate devices to control. Else targets all.
|
||||
| `away_mode` | no | New value of away mode.
|
||||
|
||||
#### {% linkable_title Automation example %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
platform: time
|
||||
after: "07:15:00"
|
||||
action:
|
||||
- service: climate.set_away_mode
|
||||
data:
|
||||
entity_id: climate.kitchen
|
||||
away_mode: true
|
||||
```
|
||||
|
||||
### {% linkable_title Service `climate.set_temperature` %}
|
||||
|
||||
Set target temperature of climate device
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`'s of climate devices to control. Else targets all.
|
||||
| `temperature` | no | New target temperature for hvac
|
||||
| `target_temp_high` | yes | New target high temperature for hvac
|
||||
| `target_temp_low` | yes | New target low temperature for hvac
|
||||
| `operation_mode` | yes | Operation mode to set temperature to. This defaults to current_operation mode if not set, or set incorrectly.
|
||||
|
||||
#### {% linkable_title Automation example %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
platform: time
|
||||
after: "07:15:00"
|
||||
action:
|
||||
- service: climate.set_temperature
|
||||
data:
|
||||
entity_id: climate.kitchen
|
||||
temperature: 24
|
||||
operation_mode: Heat
|
||||
```
|
||||
|
||||
### {% linkable_title Service `climate.set_humidity` %}
|
||||
|
||||
Set target humidity of climate device
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`'s of climate devices to control. Else targets all.
|
||||
| `humidity` | no | New target humidity for climate device
|
||||
|
||||
#### {% linkable_title Automation example %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
platform: time
|
||||
after: "07:15:00"
|
||||
action:
|
||||
- service: climate.set_humidity
|
||||
data:
|
||||
entity_id: climate.kitchen
|
||||
humidity: 60
|
||||
```
|
||||
|
||||
### {% linkable_title Service `climate.set_fan_mode` %}
|
||||
|
||||
Set fan operation for climate device
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`'s of climate devices to control. Else targets all.
|
||||
| `fan_mode` | no | New value of fan mode
|
||||
|
||||
#### {% linkable_title Automation example %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
platform: time
|
||||
after: "07:15:00"
|
||||
action:
|
||||
- service: climate.set_fan_mode
|
||||
data:
|
||||
entity_id: climate.kitchen
|
||||
fan_mode: 'On Low'
|
||||
```
|
||||
|
||||
### {% linkable_title Service `climate.set_operation_mode` %}
|
||||
|
||||
Set operation mode for climate device
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`'s of climate devices to control. Else targets all.
|
||||
| `operation_mode` | no | New value of operation mode
|
||||
|
||||
#### {% linkable_title Automation example %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
platform: time
|
||||
after: "07:15:00"
|
||||
action:
|
||||
- service: climate.set_operation_mode
|
||||
data:
|
||||
entity_id: climate.kitchen
|
||||
operation_mode: Heat
|
||||
```
|
||||
|
||||
### {% linkable_title Service `climate.set_swing_mode` %}
|
||||
|
||||
Set operation mode for climate device
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | yes | String or list of strings that point at `entity_id`'s of climate devices to control. Else targets all.
|
||||
| `swing_mode` | no | New value of swing mode
|
||||
|
||||
#### {% linkable_title Automation example %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
platform: time
|
||||
after: "07:15:00"
|
||||
action:
|
||||
- service: climate.set_swing_mode
|
||||
data:
|
||||
entity_id: climate.kitchen
|
||||
swing_mode: 1
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Z-Wave Thermostat"
|
||||
description: "Instructions how to setup the Z-Wave thermostat within Home Assistant."
|
||||
title: "Z-Wave Climate"
|
||||
description: "Instructions how to setup the Z-Wave thermostat or HVAC within Home Assistant."
|
||||
date: 2016-04-03 9:52
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -13,10 +13,72 @@ ha_release: 0.17
|
|||
---
|
||||
|
||||
|
||||
To get your Z-Wave thermostat or HVAC unit working with Home Assistant, follow the instructions for the general [Z-Wave component](/components/zwave/).
|
||||
To get your Z-Wave thermostat or HVAC unit working with Home Assistant, follow the instructions for the general [Z-Wave component](/getting-started/z-wave/).
|
||||
|
||||
<p class='note'>
|
||||
Thermostats with support for fan modes or different operating modes, will be handled like a HVAC device and will also be detected as one.
|
||||
|
||||
If the thermostat support different operationg modes, you will get one thermostat entity for each mode. These can be hidden with settings using the customize setting in the `configuration.yaml` file.
|
||||
If the thermostat support different operating modes, you will get one thermostat entity for each mode. These can be hidden with settings using the customize setting in the `configuration.yaml` file.
|
||||
</p>
|
||||
|
||||
To enable the climate component for your Z-Wave network, add the following to your `configuration.yaml` file.
|
||||
|
||||
```yaml
|
||||
climate:
|
||||
platform: zwave
|
||||
```
|
||||
|
||||
Once enabled, any Z-Wave climate devices will be available to Home Assistant. Multiple entities may be created. The following entities are created for a Remotec ZXT-120.
|
||||
|
||||
- **climate.remotec_zxt120_heating_1_id** Allows you to control the connected device. See below for examples.
|
||||
- **sensor.remotec_zxt120_temperature_38** A sensor which returns the current temperature set on the attached device.
|
||||
|
||||
### {% linkable_title Automating Z-Wave Climate Devices %}
|
||||
|
||||
The following examples will instruct a Remotec ZXT-120 to turn the attached device mode to Heating, and set the temperature at 24 degrees after 8pm. Add it to `automation.yaml`.
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: Turn on Heater at 8pm
|
||||
trigger:
|
||||
- platform: time
|
||||
after: "20:00:00"
|
||||
action:
|
||||
- service: climate.set_operation_mode
|
||||
entity_id: climate.remotec_zxt120_heating_1_id
|
||||
data:
|
||||
operation_mode: Heat
|
||||
- service: climate.set_temperature
|
||||
entity_id: climate.remotec_zxt120_heating_1_39
|
||||
data:
|
||||
temperature: 24
|
||||
```
|
||||
|
||||
Generally in Home Assistant you can use the `homeassistant/turn_off` service to turn devices off. For the Remotec ZXT-120, you must instead make a service call like the following.
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: Turn off Heater at 9pm
|
||||
trigger:
|
||||
- platform: time
|
||||
after: "21:00:00"
|
||||
action:
|
||||
- service: climate.set_operation_mode
|
||||
entity_id: climate.remotec_zxt120_heating_1_id
|
||||
data:
|
||||
operation_mode: 'Off'
|
||||
```
|
||||
|
||||
**Note:** In the example above, the word `Off` is encased in single quotes to be valid YAML.
|
||||
|
||||
### {% linkable_title Test if it works %}
|
||||
|
||||
A simple way to test if your Z-Wave climate device is working is to use <img src='/images/screenshots/developer-tool-services-icon.png' alt='service developer tool icon' class="no-shadow" height="38" /> **Services** from the **Developer Tools**. Choose the applicable Climate service from the list of **Available services:** and enter something like the sample below into the **Service Data** field and then press **CALL SERVICE**.
|
||||
|
||||
```json
|
||||
{
|
||||
"entity_id": "climate.remotec_zxt120_heating_1_id",
|
||||
"operation_mode": "Heat"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,6 @@ cover:
|
|||
state_open: "OPEN"
|
||||
state_closed: "STATE"
|
||||
optimistic: false
|
||||
retain: false
|
||||
value_template: '{% raw %}{{ value.x }}{% endraw %}'
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ The following optional parameters can be used with any platform. However device
|
|||
|---------------------|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `track_new_devices` | True | If new discovered devices are tracked by default |
|
||||
| `interval_seconds` | 12 | Seconds between each scan for new devices |
|
||||
| `consider_home` | 180 | Seconds to wait till marking someone as not home after not being seen. This parameter is most useful for households with Apple iOS devices that go into sleep mode while still at home to conserve battery life. iPhones will occasionally drop off the network and then re-appear. `consider_home` helps prevent false alarms in presence detection when using IP scanners such as Nmap. |
|
||||
| `consider_home` | 180 | Seconds to wait till marking someone as not home after not being seen. This parameter is most useful for households with Apple iOS devices that go into sleep mode while still at home to conserve battery life. iPhones will occasionally drop off the network and then re-appear. `consider_home` helps prevent false alarms in presence detection when using IP scanners such as Nmap. `consider_home` accepts various time representations, (E.g. the following all represents 3 minutes: `180`, `0:03`, `0:03:00`) |
|
||||
|
||||
The extended example from above would look like the following sample:
|
||||
|
||||
|
|
@ -73,3 +73,4 @@ devicename:
|
|||
| `gravatar` | None | An email address for the device's owner. If provided, it will override `picture` |
|
||||
| `track` | False | If `yes`/`on`/`true` then the device will be tracked. Otherwise its location and state will not update |
|
||||
| `hide_if_away` | False | If `yes`/`on`/`true` then the device will be hidden if it is not at home |
|
||||
| `consider_home` | [uses platform setting] | Allows you to override the global `consider_home` setting from the platform configuration on a per device level |
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ device_tracker:
|
|||
Configuration variables:
|
||||
|
||||
- **host** (*Required*): The IP address of your router, e.g. `192.168.1.1`.
|
||||
- **username** (*Required*: The username of an user with administrative privileges, usually `admin`.
|
||||
- **username** (*Required*): The username of an user with administrative privileges, usually `admin`.
|
||||
- **password** (*Required*): The password for your given admin account.
|
||||
- **port** (*Optional*): The port your router communicates with (defaults to 5000, but 80 is also known to be used on some models)
|
||||
|
||||
|
|
|
|||
|
|
@ -49,16 +49,16 @@ device_tracker:
|
|||
Owntracks can also be used with other device trackers, such as [Nmap](/components/device_tracker.nmap_scanner/) or [Netgear](/components/device_tracker.netgear/). To do this, fill in the `mac` field to the Owntracks entry in `known_devices.yaml` with the MAC address of the device you want to track. This way the state of the device will be determined by the source that reported last. The naming convention for known device list is `<username>_<device-id>` and could be set in app configuration. More details about this config can found in [device tracker](/components/device_tracker/).
|
||||
|
||||
### {% linkable_title Using Owntracks regions %}
|
||||
Owntracks can track regions, and send region entry and exit information to Home Assistant(HA). You set up a region in the Owntracks app which you should name the same as your HA Zone, and then make sure to turn on the `share` option for the region in the owntracks app. Please see the [owntracks documentation](http://owntracks.org/booklet/guide/waypoints/)
|
||||
Owntracks can track regions, and send region entry and exit information to Home Assistant (HA). You set up a region in the Owntracks app which you should name the same as your HA Zone, and then make sure to turn on the `share` option for the region in the owntracks app. Please see the [owntracks documentation](http://owntracks.org/booklet/guide/waypoints/).
|
||||
|
||||
Home Assistant will use the enter and leave messages to set your zone location. Your location will be set to the center of zone when you enter. Location updates from OwnTracks will be ignored while you are inside a zone.
|
||||
|
||||
When you exit a zone, Home Assistant will start using location updates to track you again. To make sure that Home Assistant correctly exits a zone (which it calculates based on your GPS co-ordinates), you may want to set your Zone radius in HA to be slightly smaller that the Owntracks region radius.
|
||||
|
||||
### {% linkable_title Using Owntracks regions - forcing Owntracks to update using %}iBeacons
|
||||
When run in the usual `significant changes mode` (which is kind to your phone battery), Owntracks sometimes doesn't update your location as quickly as you'd like when you arrive at a zone. This can be annoying if you want to trigger an automation when you get home. You can improve the situation using iBeacons.
|
||||
When run in the usual *significant changes mode* (which is kind to your phone battery), Owntracks sometimes doesn't update your location as quickly as you'd like when you arrive at a zone. This can be annoying if you want to trigger an automation when you get home. You can improve the situation using iBeacons.
|
||||
|
||||
iBeacons are simple bluetooth devices that send out an "I'm here" message. They are supported by IOS and some Android devices. Owntracks explain more [here](http://owntracks.org/booklet/guide/beacons/)
|
||||
iBeacons are simple bluetooth devices that send out an "I'm here" message. They are supported by IOS and some Android devices. Owntracks explain more [here](http://owntracks.org/booklet/guide/beacons/).
|
||||
|
||||
When you enter an iBeacon region, Owntracks will send a `region enter` message to HA as described above. So if you want to have an event triggered when you arrive home, you can put an iBeacon outside your front door. If you set up an OwnTracks iBeacon region called `home` then getting close to the beacon will trigger an update to HA that will set your zone to be `home`.
|
||||
|
||||
|
|
@ -73,13 +73,13 @@ When your phone sees a mobile iBeacon that it knows about, it will tell HA the l
|
|||
|
||||
To use mobile iBeacons with HA, you just set up a region that doesn't match your Zone names. If HA sees an entry event for a iBeacon region that doesn't match a Zone name (say `keys`) - it will start tracking it, calling the device `device_tracker.beacon_keys`).
|
||||
|
||||
This allows you to write zone automations for devices that can't track themselves (for example `alert me if I leave the house and my keys are still at home`). Another example would be `open the gates if my car arrives home`.
|
||||
This allows you to write zone automations for devices that can't track themselves (for example *alert me if I leave the house and my keys are still at home*). Another example would be *open the gates if my car arrives home*.
|
||||
|
||||
### {% linkable_title Using mobile and fixed iBeacons together %}
|
||||
You can use iBeacons of both types together, so if you have a Zone `drive` with an iBeacon region called `-drive` and you arrive home with a mobile iBeacon called `-car`, then `device_tracker.beacon_car` will be set to a state of `drive`.
|
||||
|
||||
### {% linkable_title Importing Owntracks waypoints as zones %}
|
||||
By default, any Owntracks user connected to Home Assistant can export their waypoint definitions (from the `Export - Export to Endpoint` menu item) which will then be translated to zone definitions in Home Assistant. The zones will be named `<user>-<device> - <waypoint name>`. This functionality can be controlled in 2 ways:
|
||||
By default, any Owntracks user connected to Home Assistant can export their waypoint definitions (from the *Export - Export to Endpoint* menu item) which will then be translated to zone definitions in Home Assistant. The zones will be named `<user>-<device> - <waypoint name>`. This functionality can be controlled in 2 ways:
|
||||
|
||||
1. The configuration variable `waypoints` can be set to `False` which will disable importing waypoints for all users.
|
||||
2. The configuration variable `waypoint_whitelist` can contain a list of users who are allowed to import waypoints.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ The `digital_ocean` component allows you to access the information about your [D
|
|||
|
||||
Obtain your API key from your [Digital Ocean dashboard](https://cloud.digitalocean.com/settings/api/tokens).
|
||||
|
||||
To integrate your Digital Ocena droplets with Home Assistant, add the following section to your `configuration.yaml` file:
|
||||
To integrate your Digital Ocean droplets with Home Assistant, add the following section to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Configuration variables:
|
|||
- `script`
|
||||
- `scene`
|
||||
|
||||
- **expose_by_default** (*Optional*): Whether or not entities should be exposed via the bridge by default instead of explicitly (see the 'emulated_hue' customization below). If not specified, this defaults to true.
|
||||
- **expose_by_default** (*Optional*): Whether or not entities should be exposed via the bridge by default instead of explicitly (see the 'emulated_hue' customization below). If not specified, this defaults to true. Warning: If you have a lot of devices (more than 49 total across all exposed domains), you should be careful with this opton. Exposing more devices than Alexa supports can result in it not seeing any of them. If you are having trouble getting any devices to show up, try disabling this, and explicitly exposing just a few devices at a time to see if that fixes it.
|
||||
|
||||
- **exposed_domains** (*Optional*): The domains that are exposed by default if `expose_by_default` is set to true. If not specified, this defaults to the following list:
|
||||
- `switch`
|
||||
|
|
|
|||
|
|
@ -14,13 +14,15 @@ ha_release: 0.9
|
|||
|
||||
The `influxdb` component makes it possible to transfer all state changes to an external [InfluxDB](https://influxdb.com/) database. For more details, [see the blog post on InfluxDB](/blog/2015/12/07/influxdb-and-grafana/).
|
||||
|
||||
To use the `influxdb` component in your installation, add the following to your `configuration.yaml` file:
|
||||
The default InfluxDB configuration doesn't enforce authentication. If you have installed InfluxDB on the same host where Home Assistant is running and haven't made any configuration changes, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
influxdb:
|
||||
```
|
||||
|
||||
You will still need to create a database named `home_assistant` via InfluxDB's web interface or command line. For instructions how to create a database check the [InfluxDB documentation](https://docs.influxdata.com/influxdb/v1.0/introduction/getting_started/#creating-a-database) relevant to the version you have installed.
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **host** (*Optional*): IP address of your database host, eg. http://192.168.1.10. Defaults to `localhost`.
|
||||
|
|
@ -37,7 +39,6 @@ Configuration variables:
|
|||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
In this section you find some real life examples of how to use this component.
|
||||
|
||||
### {% linkable_title Full configuration %}
|
||||
|
||||
|
|
|
|||
|
|
@ -15,11 +15,9 @@ ha_iot_class: "Local Push"
|
|||
|
||||
Receive signals from a keyboard and use it as a remote control.
|
||||
|
||||
This component allows to use a keyboard as remote control. It will fire `keyboard_remote_command_received` events witch can then be used
|
||||
in automation rules.
|
||||
This component allows you to use a keyboard as remote control. It will fire `keyboard_remote_command_received` events which can then be used in automation rules.
|
||||
|
||||
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.
|
||||
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
|
||||
|
|
@ -34,11 +32,11 @@ Configuration variables:
|
|||
- **device_descriptor** (*Required*): List of URLS for your feeds.
|
||||
- **key_value** (*Required*): Possible values are `key_up`, `key_down`, and `key_hold`. Be careful, `key_hold` will fire a lot of events.
|
||||
|
||||
And an automation rule to bring breath live into it.
|
||||
And an automation rule to breathe life into it:
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
alias: Keyboard All light on
|
||||
alias: Keyboard all lights on
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: keyboard_remote_command_received
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: 0.7.5
|
|||
---
|
||||
|
||||
|
||||
The `blinkstick` platform let you can control your [Blinkstick](https://www.blinkstick.com/) lights from within Home Assistant.
|
||||
The `blinkstick` platform lets you control your [Blinkstick](https://www.blinkstick.com/) lights from within Home Assistant.
|
||||
|
||||
To add blinkstick to your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ ha_category: Light
|
|||
ha_release: 0.21
|
||||
---
|
||||
|
||||
An EnOcean light can take many formes. Currently only one type has been tested: Eltako FUD61 dimmer.
|
||||
An EnOcean light can take many forms. Currently only one type has been tested: Eltako FUD61 dimmer.
|
||||
|
||||
|
||||
To use your EnOcean device, you first have to set up your [EnOcean hub](/components/enocean/) and then add the following to your `configuration.yaml` file:
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Example of bulbs:
|
|||
- [Flux WiFi Smart LED Light Bulb4](http://smile.amazon.com/Flux-WiFi-Smart-Light-Bulb/dp/B01A6GHHTE)
|
||||
- [WIFI smart LED light Bulb1](http://smile.amazon.com/gp/product/B01CS1EZYK)
|
||||
|
||||
The chances are high that you bulb or controller (eg. WiFi LED CONTROLLER) will work if you can control the device with the MagicHome app.
|
||||
The chances are high that your bulb or controller (eg. WiFi LED CONTROLLER) will work if you can control the device with the MagicHome app.
|
||||
|
||||
To enable those lights, add the following lines to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -13,13 +13,13 @@ ha_iot_class: "Local Polling"
|
|||
featured: true
|
||||
---
|
||||
|
||||
Philips Hue support is integrated into Home Assistant as a light platform. The preferred way to setup the Philips Hue platform is by enabling the [the discovery component](/components/discovery/).
|
||||
Philips Hue support is integrated into Home Assistant as a light platform. The preferred way to setup the Philips Hue platform is by enabling the [discovery component](/components/discovery/).
|
||||
|
||||
Once discovered, locate "configurator.philips_hue" in the entities list ( < > ) and add it to configuration.yaml. Restart home assistant so that it is visible in the home assistant dashboard. Once home assistant is restarted, locate and click on configurator.philips_hue to bring up the initiation dialog. This will prompt you to press the Hue button to register the Hue hub in home assistant. Once complete, the configurator entity can be removed from configuration.yaml.
|
||||
Once discovered, if you have a custom default view, locate `configurator.philips_hue` in the entities list ( < > ) and add it to a group in `configuration.yaml`. Restart Home Assistant so that the configurator is visible in the Home Assistant dashboard. Once Home Assistant is restarted, locate and click on `configurator.philips_hue` to bring up the initiation dialog. This will prompt you to press the Hue button to register the Hue hub in home assistant. Once complete, the configurator entity isn't needed anymore and can be removed from any visible group in `configuration.yaml`.
|
||||
|
||||
Restarting home assistant once more should result in the Hue lights listed as "light" entities. Add these light entities to configuration.yaml and restart home assistant once more to complete the installation.
|
||||
Restarting Home Assistant once more should result in the Hue lights listed as "light" entities. Add these light entities to configuration.yaml and restart home assistant once more to complete the installation.
|
||||
|
||||
If you want to enable the light component directly, add the following lines to your `configuration.yaml`:
|
||||
If you want to enable the component without relying on the [discovery component](/components/discovery/), add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Turns one light on or multiple lights on using [groups]({{site_root}}/components
|
|||
| `transition` | yes | Integer that represents the time the light should take to transition to the new state in seconds. *not supported by Wink
|
||||
| `profile` | yes | String with the name of one of the built-in profiles (relax, energize, concentrate, reading) or one of the custom profiles defined in `light_profiles.csv` in the current working directory. Light profiles define a xy color and a brightness. If a profile is given and a brightness or xy color then the profile values will be overwritten.
|
||||
| `xy_color` | yes | A list containing two floats representing the xy color you want the light to be. Two comma seperated floats that represent the color in XY.
|
||||
| `rgb_color` | yes | A list containing three integers representing the rgb color you want the light to be. Three comma seperated integers that represent the color in RGB
|
||||
| `rgb_color` | yes | A list containing three integers representing the rgb color you want the light to be. Three comma seperated integers that represent the color in RGB. You can find a great chart here: [Hue Color Chart](http://www.developers.meethue.com/documentation/hue-xy-values)
|
||||
| `color_temp` | yes | An INT in mireds representing the color temperature you want the light to be.
|
||||
| `color_name` | yes | A human readable string of a color name, such as `blue` or `goldenrod` or [`chucknorris`](http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color). If your browser can display it, so can Home Assistant.
|
||||
| `brightness` | yes | Integer between 0 and 255 for how bright the color should be.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ ha_release: 0.26
|
|||
---
|
||||
|
||||
|
||||
The `mqtt_json` light platform let you control a MQTT-enabled light that can receive [JSON](https://en.wikipedia.org/wiki/JSON) messages.
|
||||
The `mqtt_json` light platform lets you control a MQTT-enabled light that can receive [JSON](https://en.wikipedia.org/wiki/JSON) messages.
|
||||
|
||||
This platform supports on/off, brightness, RGB colors, transitions, and short/long flashing. The messages sent to/from the lights look similar to this, omitting fields when they aren't needed:
|
||||
|
||||
|
|
@ -32,9 +32,9 @@ This platform supports on/off, brightness, RGB colors, transitions, and short/lo
|
|||
```
|
||||
|
||||
|
||||
In an ideal scenario, the MQTT device will have a state topic to publish state changes. If these messages are published with the RETAIN flag, the MQTT light will receive an instant state update after subscription and will start with correct state. Otherwise, the initial state of the light will be off.
|
||||
In an ideal scenario, the MQTT device will have a state topic to publish state changes. If these messages are published with the RETAIN flag, the MQTT light will receive an instant state update after subscription and will start with the correct state. Otherwise, the initial state of the light will be off.
|
||||
|
||||
When a state topic is not available, the light will work in optimistic mode. In this mode, the light will immediately change state after every command. Otherwise, the light will wait for state confirmation from device (message from `state_topic`).
|
||||
When a state topic is not available, the light will work in optimistic mode. In this mode, the light will immediately change state after every command. Otherwise, the light will wait for state confirmation from the device (message from `state_topic`).
|
||||
|
||||
Optimistic mode can be forced, even if state topic is available. Try enabling it if the light is operating incorrectly.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ light:
|
|||
|
||||
Configuration variables:
|
||||
|
||||
- **name** (*Required*): The name you' would like to give the light in Home Assistant.
|
||||
- **name** (*Required*): The name you would like to give the light in Home Assistant.
|
||||
- **pin** (*Required*): The number identifying which pin to use.
|
||||
- **address** (*Optional*): The long 64 bit address of the remote ZigBee device whose digital output pin you wouldd like to switch. Do not include this variable if you want to switch the local ZigBee device's pins.
|
||||
- **on_state** (*Optional*): Either `high` (default) or `low`, depicting whether the digital output pin is pulled `high` or `low` when the light is turned on.
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ footer: true
|
|||
logo: denon.png
|
||||
ha_category: Media Player
|
||||
ha_iot_class: "Local Polling"
|
||||
ha_release: 0.7.2
|
||||
---
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -34,6 +34,8 @@ Configuration variables:
|
|||
|
||||
- **name** (*Optional*): Name of the device
|
||||
- **host** (*Optional*): IP address or hostname of the device
|
||||
- **source_ignore** (*Optional*): List of sources to hide in the front-end
|
||||
- **source_names** (*Optional*): Mapping of internal AVR source names to custom ones, allowing to rename e.g. `HDMI1` to `ChromeCast`
|
||||
|
||||
A few notes:
|
||||
|
||||
|
|
@ -41,5 +43,18 @@ A few notes:
|
|||
- For receivers that support more than one zone, Home Assistant will add one media player per zone supported by the player, named "$name Zone 2" and "$name Zone 3".
|
||||
- In some cases, autodiscovery fails due to a known bug in the receiver's firmware. It is possible to manually specify the reveiver's IP address or via it's hostname (if it is discoverably by your DNS) then.
|
||||
- Please note: If adding the IP address or hostname manually, you **must** enable network standby on your receiver, or else startup of Home Assistant will hang if you have your receiver switched off.
|
||||
- Currently the only controls that are available is Power On/Off, Mute, and Volume control. Other functions such as source select are in progress of being developed.
|
||||
- Currently, this component supports powering on/off, mute, volume control and source selection.
|
||||
|
||||
A full configuration example will look like the sample below:
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
media_player:
|
||||
- platform: yamaha
|
||||
host: 192.168.0.10
|
||||
source_ignore:
|
||||
- "AUX"
|
||||
- "HDMI6"
|
||||
source_names:
|
||||
HDMI1: "ChromeCast"
|
||||
AV4: "Vinyl"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -111,6 +111,22 @@ By default, every notification sent has a randomly generated UUID (v4) set as it
|
|||
}
|
||||
```
|
||||
|
||||
Example of adding a tag to your configuration. This won't create new notification if there already exists one with the same tag.
|
||||
|
||||
```yaml
|
||||
- alias: Push/update notification of sensor state with tag
|
||||
trigger:
|
||||
- platform: state
|
||||
entity_id: sensor.sensor
|
||||
action:
|
||||
service: notify.html5
|
||||
data_template:
|
||||
message: "Last known sensor state is {% raw %}{{ states('sensor.sensor') }}{% endraw %}."
|
||||
data:
|
||||
data:
|
||||
tag: 'notification-about-sensor'
|
||||
```
|
||||
|
||||
#### {% linkable_title Targets %}
|
||||
|
||||
If you do not provide a `target` parameter in the notify payload a notification will be sent to all registered targets as listed in `html5_push_registrations.conf`. You can provide a `target` parameter like so:
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@ Configuration variables:
|
|||
- **name** (*Optional*): Setting the optional parameter `name` allows multiple notifiers to be created. The default value is `notify`. The notifier will bind to the service `notify.NOTIFIER_NAME`.
|
||||
- **api_key** (*Required*): Your API key for Pushetta.
|
||||
- **channel_name** (*Required*): The name of your channel.
|
||||
- **send_test_msg** (*Optional*): Disable/enable the test message send on Home Asssitant's startup to test the API key and the existance of the channel. Default to `False`.
|
||||
|
||||
It's easy to test your Pushetta setup outside of Home Assistant. Assuming you have a channel *home-assistant*, just fire a request and check the channel page in the dashboard for a new message.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ The `telegram` platform uses [Telegram](https://web.telegram.org) to delivery no
|
|||
|
||||
The requirements are:
|
||||
|
||||
- You need a [Telegram bot](https://core.telegram.org/bots). Please follow those [instructions](https://core.telegram.org/bots#botfather) to create one and get the token for your bot. Keep in mind that bots are not allowed to contact users. You need to make the first contact with your user. Meaning that you need to send a message to the bot from your user.
|
||||
- You need a [Telegram bot](https://core.telegram.org/bots). Please follow those [instructions](https://core.telegram.org/bots#6-botfather) to create one and get the token for your bot. Keep in mind that bots are not allowed to contact users. You need to make the first contact with your user. Meaning that you need to send a message to the bot from your user.
|
||||
- The `chat_id` of an user.
|
||||
|
||||
The quickest way to retrieve your `chat_id` is visiting [https://api.telegram.org/botYOUR_API_TOKEN/getUpdates](https://api.telegram.org/botYOUR_API_TOKEN/getUpdates) or to use `$ curl -X GET https://api.telegram.org/botYOUR_API_TOKEN/getUpdates`. Replace `YOUR_API_TOKEN` with your actual token.
|
||||
|
|
@ -55,7 +55,7 @@ Configuration variables:
|
|||
|
||||
- **name** (*Optional*): Setting the optional parameter `name` allows multiple notifiers to be created. The default value is `notify`. The notifier will bind to the service `notify.NOTIFIER_NAME`.
|
||||
- **api_key** (*Required*): The API token of your bot.
|
||||
- **chat_id** (*Required*: The chat ID of your user.
|
||||
- **chat_id** (*Required*): The chat ID of your user.
|
||||
|
||||
To use notifications, please see the [getting started with automation page](/getting-started/automation/).
|
||||
|
||||
|
|
|
|||
|
|
@ -19,23 +19,14 @@ To use your aREST enabled device in your installation, add the following to your
|
|||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
platform: arest
|
||||
resource: http://IP_ADDRESS
|
||||
name: Office
|
||||
monitored_variables:
|
||||
- name: temperature
|
||||
unit_of_measurement: '°C'
|
||||
value_template: '{% raw %}{{ value | round(1) }}{% endraw %}'
|
||||
- name: humidity
|
||||
unit_of_measurement: '%'
|
||||
pins:
|
||||
A0:
|
||||
name: Pin 0 analog
|
||||
unit_of_measurement: "ca"
|
||||
value_template: '{% raw %}{{ value_json.light }}{% endraw %}'
|
||||
3:
|
||||
name: Pin 3 digital
|
||||
- platform: arest
|
||||
resource: http://10.100.0.117
|
||||
monitored_variables:
|
||||
temperature:
|
||||
name: temperature
|
||||
pins:
|
||||
A0:
|
||||
name: Pin 0 analog
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ ha_release: 0.30
|
|||
|
||||
The `darksky` platform uses the [Dark Sky](https://darksky.net/) web service as a source for meteorological data for your location. The location is based on the `longitude` and `latitude` coordinates configured in your `configuration.yaml` file. The coordinates are auto-detected but to take advantage of the hyper-local weather reported by Dark Sky, you can refine them down to your exact home address. GPS coordinates can be found by using [Google Maps](https://www.google.com/maps) and clicking on your home or [Openstreetmap](http://www.openstreetmap.org/).
|
||||
|
||||
You need an API key which is free but requires [registration](hhttps://darksky.net/dev/register). You can make up to 1000 calls per day for free which means that you could make one approximately every 86 seconds.
|
||||
You need an API key which is free but requires [registration](https://darksky.net/dev/register). You can make up to 1000 calls per day for free which means that you could make one approximately every 86 seconds.
|
||||
|
||||
<p class='note warning'>
|
||||
[Dark Sky](https://darksky.net/) will charge you $0.0001 per API call if you enter your credit card details and create more than 1000 calls per day.
|
||||
|
|
@ -26,39 +26,40 @@ To add Dark Sky to your installation, add the following to your `configuration.y
|
|||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
platform: darksky
|
||||
api_key: YOUR_APP_KEY
|
||||
monitored_conditions:
|
||||
- summary
|
||||
- icon
|
||||
- nearest_storm_distance
|
||||
- nearest_storm_bearing
|
||||
- precip_type
|
||||
- precip_intensity
|
||||
- precip_probability
|
||||
- temperature
|
||||
- apparent_temperature
|
||||
- dew_point
|
||||
- wind_speed
|
||||
- wind_bearing
|
||||
- cloud_cover
|
||||
- humidity
|
||||
- pressure
|
||||
- visibility
|
||||
- ozone
|
||||
- minutely_summary
|
||||
- hourly_summary
|
||||
- daily_summary
|
||||
- temperature_max
|
||||
- temperature_min
|
||||
- apparent_temperature_max
|
||||
- apparent_temperature_min
|
||||
- precip_intensity_max
|
||||
- platform: darksky
|
||||
api_key: YOUR_API_KEY
|
||||
monitored_conditions:
|
||||
- summary
|
||||
- icon
|
||||
- nearest_storm_distance
|
||||
- nearest_storm_bearing
|
||||
- precip_type
|
||||
- precip_intensity
|
||||
- precip_probability
|
||||
- temperature
|
||||
- apparent_temperature
|
||||
- dew_point
|
||||
- wind_speed
|
||||
- wind_bearing
|
||||
- cloud_cover
|
||||
- humidity
|
||||
- pressure
|
||||
- visibility
|
||||
- ozone
|
||||
- minutely_summary
|
||||
- hourly_summary
|
||||
- daily_summary
|
||||
- temperature_max
|
||||
- temperature_min
|
||||
- apparent_temperature_max
|
||||
- apparent_temperature_min
|
||||
- precip_intensity_max
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **api_key** (*Required*): Your API key.
|
||||
- **name** (*Optional*): Additional name for the sensors. Default to platform name.
|
||||
- **monitored_conditions** array (*Required*): Conditions to display in the frontend.
|
||||
- **summary**: A human-readable text summary of the current conditions.
|
||||
- **precip_type**: The type of precipitation occurring.
|
||||
|
|
@ -85,4 +86,8 @@ Configuration variables:
|
|||
- **units** (*Optional*): Specify the unit system. Default to `si` or `us` based on the temperature preference in Home Assistant. Other options are `auto`, `us`, `si`, `ca`, and `uk2`.
|
||||
`auto` will let forecast.io decide the unit system based on location.
|
||||
|
||||
<p class='note warning'>
|
||||
Note: While the platform is called "darksky" the sensors will show up in Home Assistant as "dark_sky" (eg: sensor.dark_sky_summary).
|
||||
</p>
|
||||
|
||||
Details about the API are available in the [Dark Sky documentation](https://darksky.net/dev/docs).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Emoncms Sensor"
|
||||
description: "Instructions on how to integrate emoncms feeds as sensors into Home Assistant."
|
||||
description: "Instructions on how to integrate Emoncms feeds as sensors into Home Assistant."
|
||||
date: 2016-09-08 00:15
|
||||
logo: emoncms.png
|
||||
sidebar: true
|
||||
|
|
@ -14,102 +14,96 @@ ha_iot_class: "Local Polling"
|
|||
---
|
||||
|
||||
|
||||
The `emoncms` sensor platform creates sensors for the feeds available in your local or cloud based version of [emoncms](https://emoncms.org).
|
||||
The `emoncms` sensor platform creates sensors for the feeds available in your local or cloud based version of [Emoncms](https://emoncms.org).
|
||||
|
||||
To enable this sensor, add the following lines to your `configuration.yaml`, it will list all feeds as a sensor:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry using cloud based emoncms
|
||||
# Example configuration.yaml entry using cloud based Emoncms
|
||||
sensor:
|
||||
platform: emoncms
|
||||
api_key: put your emoncms read api key here
|
||||
api_key: API_KEY
|
||||
url: https://emoncms.org
|
||||
id: 1
|
||||
```
|
||||
|
||||
## {% linkable_title Configuration variables %}
|
||||
|
||||
- **api_key** (*Required*): The read api key for your emoncms user.
|
||||
- **url** (*Required*): The base url of emoncms, use "https://emoncms.org" for the cloud based version.
|
||||
- **id** (*Required*): Positive Integer identifier for the sensor. Must be unique if you specify multiple emoncms sensors.
|
||||
- **include_only_feed_id** (*optional*): Positive integer list of emoncms feed id's. Only the feeds with feed id's specified here will be displayed. Can not be specified if `exclude_feed_id` is specified.
|
||||
- **exclude_feed_id** (*optional*): Positive integer list of emoncms feed id's. All the feeds will be displayed as sensors except the ones listed here. Can not be specified if `include_only_feed_id` is specified.
|
||||
- **sensor_names** (*optional*): Dictionary of names for the sensors created that are created based on feedid. The dictionary consists of feedid:name pairs. Sensors for feeds with their feedid mentioned here will get the chosen name instead of the default name
|
||||
- **api_key** (*Required*): The read API key for your Emoncms user.
|
||||
- **url** (*Required*): The base URL of Emoncms, use "https://emoncms.org" for the cloud based version.
|
||||
- **id** (*Required*): Positive integer identifier for the sensor. Must be unique if you specify multiple Emoncms sensors.
|
||||
- **include_only_feed_id** (*Optional*): Positive integer list of Emoncms feed IDs. Only the feeds with feed IDs specified here will be displayed. Can not be specified if `exclude_feed_id` is specified.
|
||||
- **exclude_feed_id** (*Optional*): Positive integer list of Emoncms feed IDs. All the feeds will be displayed as sensors except the ones listed here. Can not be specified if `include_only_feed_id` is specified.
|
||||
- **sensor_names** (*Optional*): Dictionary of names for the sensors created that are created based on feed ID. The dictionary consists of `feedid: name` pairs. Sensors for feeds with their feed ID mentioned here will get the chosen name instead of the default name
|
||||
- **value_template** (*Optional*): Defines a [template](/topics/templating/) to alter the feed value.
|
||||
- **scan_interval** (*Optional*): Defines the update interval of the sensor in seconds.
|
||||
- **unit_of_measurement** (*Optional*): Defines the unit of measurement of for all the sensors. default is "W".
|
||||
|
||||
## {% linkable_title Default naming scheme %}
|
||||
|
||||
The names of the sensors created by this component, will be a combination of static text, `id` from the config and `feedid` from the emoncms feed, unless `sensor_names` is used.
|
||||
An example name would be "emoncms1_feedid_10"
|
||||
The names of the sensors created by this component, will be a combination of static text, `id` from the config and `feedid` from the Emoncms feed, unless `sensor_names` is used. An example name would be `emoncms1_feedid_10`.
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
### {% linkable_title Examples %}
|
||||
|
||||
In this section you find some more examples of how this sensor can be used.
|
||||
|
||||
Display only feeds with their feed IDs specified in `include_only_feed_id`.
|
||||
|
||||
```yaml
|
||||
# Display only feeds with their feed id's specified in "include_only_feed_id"
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: emoncms
|
||||
api_key: put your emoncms read api key here
|
||||
api_key: API_KEY
|
||||
url: https://emoncms.org
|
||||
id: 1
|
||||
unit_of_measurement: "W"
|
||||
include_only_feed_id:
|
||||
- 107
|
||||
- 106
|
||||
- 105
|
||||
```
|
||||
|
||||
Display all feeds except feeds with their feed id specified in `exclude_feed_id`.
|
||||
|
||||
```yaml
|
||||
# Display all feeds except feeds with their feed id specified in "exclude_feed_id"
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: emoncms
|
||||
api_key: put your emoncms read api key here
|
||||
api_key: API_KEY
|
||||
url: https://emoncms.org
|
||||
id: 1
|
||||
unit_of_measurement: "KWH"
|
||||
exclude_feed_id:
|
||||
- 107
|
||||
- 106
|
||||
- 105
|
||||
```
|
||||
|
||||
Display only feeds with their feed id's specified in `include_only_feed_id` and give the feed sensors a name using "sensor_names". You don't have to specify all feeds names in "sensor_names", the remaining sensor names will be chosen based on "id" and the Emoncms `feedid`.
|
||||
|
||||
```yaml
|
||||
# Display only feeds with their feed id's specified in "include_only_feed_id" and give the feed sensors a name using "sensor_names". You don't have to specify all feeds names in "sensor_names", the remaining sensor names will be chosen based on "id" and the emoncms feedid
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: emoncms
|
||||
api_key: put your emoncms read api key here
|
||||
url: https://emoncms.org
|
||||
api_key: API_KEY
|
||||
url: https://emoncms.org
|
||||
id: 1
|
||||
unit_of_measurement: "KW"
|
||||
include_only_feed_id:
|
||||
- 5
|
||||
- 18
|
||||
- 29
|
||||
- 48
|
||||
- 61
|
||||
- 110
|
||||
- 116
|
||||
- 120
|
||||
sensor_names:
|
||||
5: "feed 1"
|
||||
18: "feed 2"
|
||||
29: "feed 3"
|
||||
48: "kwh feed"
|
||||
61: "amp feed"
|
||||
110: "watt feed"
|
||||
```
|
||||
|
||||
Use a `value_template` to add 1500 to the feed value for all specified feed IDs in `include_feed_id`.
|
||||
|
||||
```yaml
|
||||
# Use a "value_template" to add 1500 to the feed value for all specified feed id's in "include_feed_id"
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: emoncms
|
||||
api_key: put your emoncms read api key here
|
||||
api_key: API_KEY
|
||||
url: https://emoncms.org
|
||||
scan_interval: 15
|
||||
id: 1
|
||||
|
|
@ -117,16 +111,15 @@ sensor:
|
|||
include_only_feed_id:
|
||||
- 107
|
||||
- 106
|
||||
- 105
|
||||
- 61
|
||||
```
|
||||
|
||||
Display feeds from the same Emoncms instance with 2 groups of feeds, diffrent `scan_interval` and a diffrent `unit_of_measurement`.
|
||||
|
||||
```yaml
|
||||
# Display feeds from the same emoncms instance with 2 groups of feeds, diffrent scan_interval and a diffrent unit_of_measurement
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
- platform: emoncms
|
||||
api_key: put your emoncms read api key here
|
||||
api_key: API_KEY
|
||||
url: https://emoncms.org
|
||||
scan_interval: 30
|
||||
id: 1
|
||||
|
|
@ -134,7 +127,6 @@ sensor:
|
|||
include_only_feed_id:
|
||||
- 107
|
||||
- 106
|
||||
- 105
|
||||
- platform: emoncms
|
||||
api_key: put your emoncms read api key here
|
||||
url: https://emoncms.org
|
||||
|
|
@ -143,7 +135,5 @@ sensor:
|
|||
unit_of_measurement: "A"
|
||||
include_only_feed_id:
|
||||
- 108
|
||||
- 109
|
||||
- 110
|
||||
- 61
|
||||
```
|
||||
|
|
|
|||
|
|
@ -50,11 +50,11 @@ Thus the trick is extract the battery level from the payload.
|
|||
```yaml
|
||||
# Example configuration.yml entry
|
||||
sensor:
|
||||
platform: mqtt
|
||||
state_topic: "owntracks/tablet/tablet"
|
||||
name: "Battery Tablet"
|
||||
unit_of_measurement: "%"
|
||||
value_template: {% raw %}'{{ value_json.batt }}'{% endraw %}
|
||||
- platform: mqtt
|
||||
state_topic: "owntracks/tablet/tablet"
|
||||
name: "Battery Tablet"
|
||||
unit_of_measurement: "%"
|
||||
value_template: {% raw %}'{{ value_json.batt }}'{% endraw %}
|
||||
```
|
||||
|
||||
### {% linkable_title Get temperature and humidity %}
|
||||
|
|
@ -73,17 +73,15 @@ Then use this configuration example to extract the data from the payload:
|
|||
|
||||
```yaml
|
||||
# Example configuration.yml entry
|
||||
sensor 1:
|
||||
platform: mqtt
|
||||
state_topic: 'office/sensor1'
|
||||
name: 'Temperature'
|
||||
unit_of_measurement: '°C'
|
||||
value_template: '{{ value_json.temperature }}'
|
||||
|
||||
sensor 2:
|
||||
platform: mqtt
|
||||
state_topic: 'office/sensor1'
|
||||
name: 'Humidity'
|
||||
unit_of_measurement: '%'
|
||||
value_template: '{{ value_json.humidity }}'
|
||||
sensor:
|
||||
- platform: mqtt
|
||||
state_topic: 'office/sensor1'
|
||||
name: 'Temperature'
|
||||
unit_of_measurement: '°C'
|
||||
value_template: {% raw %}'{{ value_json.temperature }}'{% endraw %}
|
||||
- platform: mqtt
|
||||
state_topic: 'office/sensor1'
|
||||
name: 'Humidity'
|
||||
unit_of_measurement: '%'
|
||||
value_template: {% raw %}'{{ value_json.humidity }}'{% endraw %}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ To enable this sensor in your installation, add the following to your `configura
|
|||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
platform: neurio_energy
|
||||
api_key: API_KEY
|
||||
api_secret: API_SECRET
|
||||
api_key: CLIENT_ID
|
||||
api_secret: CLIENT_SECRET
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
|
|
|||
|
|
@ -17,12 +17,12 @@ The `onewire` platform supports sensors which are using the One wire (1-wire) bu
|
|||
Supported devices:
|
||||
|
||||
- [DS18B20](https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf)
|
||||
- DS18S20
|
||||
- DS1822
|
||||
- DS1825
|
||||
- DS28EA00 temperature sensors
|
||||
- [DS18S20](https://www.maximintegrated.com/en/products/analog/sensors-and-sensor-interface/DS18S20.html)
|
||||
- [DS1822](https://datasheets.maximintegrated.com/en/ds/DS1822.pdf)
|
||||
- [DS1825](https://datasheets.maximintegrated.com/en/ds/DS1825.pdf)
|
||||
- [DS28EA00](https://datasheets.maximintegrated.com/en/ds/DS28EA00.pdf) temperature sensors
|
||||
|
||||
There is also support for bus masters which use fuse to mount device tree.
|
||||
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)). 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. If you are using Raspberry Pi and IO pin connected bus setup, don't use the 'mount_dir' option.
|
||||
|
||||
To enable One wire sensors in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -38,6 +38,7 @@ sensor:
|
|||
Configuration variables:
|
||||
|
||||
- **api_key** (*Required*): Your API key for http://openweathermap.org/.
|
||||
- **name** (*Optional*): Additional name for the sensors. Default to platform name.
|
||||
- **forecast** (*Optional*): Enables the forecast. The default is to display the current conditions.
|
||||
- **monitored_conditions** array (*Required*): Conditions to display in the frontend.
|
||||
- **weather**: A human-readable text summary.
|
||||
|
|
|
|||
|
|
@ -16,6 +16,8 @@ ha_release: "0.30"
|
|||
|
||||
The `statistics` sensor platform is consuming the state from other sensors. Beside the maximal and the minimal value also the total, the mean, the median, the variance, and the standard deviation are as attributes available. If it's a binary sensor then only the state changes are counted.
|
||||
|
||||
It can take time till the sensor starts to work because a couple of atrributes need more than one value to do the calculation.
|
||||
|
||||
To enable the statistics sensor, add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
|
|
@ -29,7 +31,10 @@ sensor:
|
|||
|
||||
Configuration variables:
|
||||
|
||||
- **entity_id** (*Required*): The entity to monitor.
|
||||
- **name** (*Optional*): Name of the sensor to use in the frontend.
|
||||
- **entity_id** (*Required*): The entity to monitor. Only [sensors](/components/sensor/) and [binary sensor](/components/binary_sensor/).
|
||||
- **name** (*Optional*): Name of the sensor to use in the frontend. Defaults to `Stats`.
|
||||
- **sampling_size** (*Optional*): Size of the sampling. If the limit is reached then the values are rotated. Defaults to `20`.
|
||||
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/screenshots/stats-sensor.png' />
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ sidebar: true
|
|||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: swiss-hydrological-data.png
|
||||
ha_category: Weather
|
||||
ha_iot_class: "Cloud Polling"
|
||||
ha_release: 0.22
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Configuration variables:
|
|||
|
||||
- **woeid** (*Optional*): See above.
|
||||
- **forecast** (*Optional*): Day of forecast. The default is the current day to display conditions.
|
||||
- **name** (*Optional*): The name of the sensor. To easily recognize each sensor when adding more than one Yahoo weather sensor, it is recommended to use the name option.
|
||||
- **name** (*Optional*): The name of the sensor. To easily recognize each sensor when adding more than one Yahoo weather sensor, it is recommended to use the name option. Defaults to `Yweather`.
|
||||
- **monitored_conditions** array (*Required*): Conditions to display in the frontend.
|
||||
- **weather**: A human-readable text summary with picture from yahoo.
|
||||
- **weather_current**: A human-readable text summary with picture from yahoo from current conditon.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ footer: true
|
|||
logo: anel.png
|
||||
ha_category: Switch
|
||||
ha_iot_class: "Local Polling"
|
||||
ha_release: 0.30
|
||||
ha_release: "0.30"
|
||||
---
|
||||
|
||||
The `anel_pwrctrl` switch platform allows you to control [ANEL PwrCtrl](http://anel-elektronik.de/SITE/produkte/produkte.htm) devices.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ comments: false
|
|||
sharing: true
|
||||
footer: true
|
||||
logo: digital_ocean.png
|
||||
ha_category: System Monitor
|
||||
ha_category: Switch
|
||||
ha_release: "0.30"
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -14,51 +14,77 @@ ha_iot_class: "Local Polling"
|
|||
---
|
||||
|
||||
|
||||
A switch platform that issues 433 MHz commands using [pilight](https://www.pilight.org/) to turn a 433 MHz device on or off. The pilight HA hub has to be set up.
|
||||
The `pilight` switch platform is issuing 433 MHz commands using [pilight](https://www.pilight.org/) to turn a 433 MHz device on or off. The Pilight Home Assistant hub has to be set up.
|
||||
|
||||
Additionally RF commands can be defined that trigger this switch to turn on and off. This allows you to also use the remote shipped with your 433 MHz switch without mixing up the HA states. You can even define several on/off commands, thus several RF remotes to toggle this switch.
|
||||
Additionally RF commands can be defined that trigger this switch to turn on and off. This allows you to also use the remote shipped with your 433 MHz switch without mixing up the Home Assistant states. You can even define several on/off commands, thus several RF remotes to toggle this switch.
|
||||
|
||||
To be really sure that HA knows the actual state of your device it is recommended to use the RF remote with codes unknown to any of your 433 MHz devices. Thus you use the remote to trigger this switch to send the correct RF code to the device.
|
||||
To be really sure that Home Assistant knows the actual state of your device it is recommended to use the RF remote with codes unknown to any of your 433 MHz devices. Thus you use the remote to trigger this switch to send the correct RF code to the device.
|
||||
|
||||
To define a pilight switch, add the following lines to your `configuration.yaml`:
|
||||
To define a Pilight switch, add the following lines to your `configuration.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
switch:
|
||||
platform: pilight
|
||||
switches:
|
||||
Bed light:
|
||||
on_code:
|
||||
protocol: intertechno_old # protocol has to be defined
|
||||
unit: 3 # these entries are protocol specific and can differ
|
||||
id: 4 # these entries are protocol specific and can differ
|
||||
'on': 1 # on has to be in apostrophes to be parsed correctly
|
||||
off_code:
|
||||
protocol: intertechno_old # protocol has to be defined
|
||||
unit: 3 # these entries are protocol specific and can differ
|
||||
id: 4 # these entries are protocol specific and can differ
|
||||
'off': 1 # off has to be in apostrophes to be parsed correctly
|
||||
on_code_receive: # optional
|
||||
protocol: daycom # protocol has to be defined
|
||||
systemcode: 14462 # these entries are protocol specific and can differ
|
||||
unit: 6 # these entries are protocol specific and can differ
|
||||
id: 34 # these entries are protocol specific and can differ
|
||||
state: 'on' # off has to be in apostrophes to be parsed correctly
|
||||
off_code_receive: # optional
|
||||
protocol: daycom # protocol has to be defined
|
||||
systemcode: 14462 # these entries are protocol specific and can differ
|
||||
unit: 6 # these entries are protocol specific and can differ
|
||||
id: 34 # these entries are protocol specific and can differ
|
||||
state: 'off' # on has to be in apostrophes to be parsed correctly
|
||||
- platform: pilight
|
||||
switches:
|
||||
Bed light:
|
||||
on_code:
|
||||
protocol: intertechno_old
|
||||
'on': 1
|
||||
off_code:
|
||||
protocol: intertechno_old
|
||||
'off': 1
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **switches** (*Required*): The array that contains all command switches.
|
||||
- **entry** (*Required*): Name of the command switch. Multiple entries are possible.
|
||||
- **switches** array (*Required*): The list that contains all command switches.
|
||||
- **[entry]** (*Required*): Name of the command switch. Multiple entries are possible.
|
||||
- **on_code** (*Required*): The code to turn the device on.
|
||||
- **off_code** (*Required*): The code to turn the device off.
|
||||
- **on_code_receive** (*Optional*): If given, this command will turn the switch on if it is received by pilight.
|
||||
- **off_code_receive** (*Optional*): If given, this command will turn the switch off if it is received by pilight.
|
||||
- **on_code_receive** (*Optional*): If given, this command will turn the switch on if it is received by Pilight.
|
||||
- **off_code_receive** (*Optional*): If given, this command will turn the switch off if it is received by Pilight.
|
||||
|
||||
For possible code entries look at the [pilight API](https://www.pilight.org/development/api/). All commands allowed by [pilight-send](https://wiki.pilight.org/doku.php/psend) can be used.
|
||||
Variables for the different codes:
|
||||
|
||||
- **protocol** (*Required*): Protocol to use, eg. `intertechno_old` or `daycom`.
|
||||
- **systemcode** (*Optional*): The systemcode of the device.
|
||||
- **unit** (*Optional*): The unit to use.
|
||||
- **id** (*Optional*): ID of the device
|
||||
- **state** (*Optional*): `'on'` or `'off'` has to be in apostrophes to be parsed correctly.
|
||||
- **'off'** (*Optional*): `1` or `0`
|
||||
- **'on'** (*Optional*): `1` or `0`
|
||||
|
||||
For possible code entries look at the [pilight API](https://www.pilight.org/development/api/). All commands allowed by [pilight-send](https://wiki.pilight.org/doku.php/psend) can be used. Which means that if for a certain protocol there are different parameters used, you should be able to replace the variables above by the proper ones required by the specific protocol. When using the `elro_800_switch` or `mumbi` protocol for example, you will have to replace the variable `unit` with `unitcode` or there will be errors occuring.
|
||||
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
```yaml
|
||||
switch:
|
||||
- platform: pilight
|
||||
switches:
|
||||
Bed light:
|
||||
on_code:
|
||||
protocol: intertechno_old
|
||||
unit: 3
|
||||
id: 4
|
||||
'on': 1
|
||||
off_code:
|
||||
protocol: intertechno_old
|
||||
unit: 3
|
||||
id: 4
|
||||
'off': 1
|
||||
on_code_receive:
|
||||
protocol: daycom
|
||||
systemcode: 14462
|
||||
unit: 6
|
||||
id: 34
|
||||
state: 'on'
|
||||
off_code_receive:
|
||||
protocol: daycom
|
||||
systemcode: 14462
|
||||
unit: 6
|
||||
id: 34
|
||||
state: 'off'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -9,6 +9,8 @@ sharing: true
|
|||
footer: true
|
||||
logo: tp-link.png
|
||||
ha_category: Switch
|
||||
ha_iot_class: "Local Polling"
|
||||
ha_release: "0.24"
|
||||
---
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ footer: true
|
|||
---
|
||||
|
||||
<p class='note warning'>
|
||||
**This component has been deprecated in favor of the "[climate](/components/climate/)" component and will be removed in the future. Please use cover.**
|
||||
**This component has been deprecated in favor of the "[climate](/components/climate/)" component and will be removed in the future. Please use climate.**
|
||||
</p>
|
||||
|
||||
Thermostats offer Home Assistant a peek into the current and target temperature in a house. Some thermostats will also offer an away mode that will lower use of heating/cooling.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue