mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-07-25 02:07:15 +00:00
Merge branch 'current' into next
This commit is contained in:
Paulus Schoutsen
commit
be8ea1aef1
@ -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.
|
||||
|
||||
@ -10,7 +10,7 @@ footer: true
|
||||
ha_category: Infrastructure
|
||||
---
|
||||
|
||||
This is an example about how you can configure Apache to act as a proxy for home assistant.
|
||||
This example demonstrates how you can configure Apache to act as a proxy for home assistant.
|
||||
|
||||
This is useful if you want to have:
|
||||
|
||||
@ -35,7 +35,7 @@ To be able to access to your home assistant instance by using https://home.examp
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
and make sure that this file is read by apache's main configiuration file `/etc/httpd/conf/httpd.conf`
|
||||
and make sure that this file is read by Apache's main configuration file `/etc/httpd/conf/httpd.conf`
|
||||
|
||||
```text
|
||||
...
|
||||
|
||||
@ -10,7 +10,7 @@ footer: true
|
||||
ha_category: Automation Examples
|
||||
---
|
||||
|
||||
#### {% linkable_title Turn on the living room lights 45 minutes before sunset if anyone home %}
|
||||
#### {% linkable_title Turn on the living room lights 45 minutes before sunset if anyone is at home %}
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
||||
@ -2,12 +2,12 @@
|
||||
layout: page
|
||||
title: "Configuration.yaml by Carlo Costanzo"
|
||||
description: ""
|
||||
date: 2016-02-07 11:45
|
||||
date: 2016-10-11 11:45
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Example configuration.yaml
|
||||
ha_external_link: https://gist.github.com/CCOSTAN/9934de973a293b809868
|
||||
ha_external_link: https://github.com/CCOSTAN/Home-AssistantConfig
|
||||
---
|
||||
|
||||
|
||||
@ -49,6 +49,6 @@ automation:
|
||||
data:
|
||||
title: 'New Home Assistant Release'
|
||||
target: 'YOUR_TARGET_HERE' #See Pushbullet component for usage
|
||||
message: "Home Assistant {{ states.updater.updater.state }} is now available."
|
||||
message: "Home Assistant {% raw %} {{ states.updater.updater.state }} {% endraw %} is now available."
|
||||
```
|
||||
|
||||
|
||||
34
source/_cookbook/tls_self_signed_certificate.markdown
Normal file
34
source/_cookbook/tls_self_signed_certificate.markdown
Normal file
@ -0,0 +1,34 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Self-signed certificate for SSL/TLS"
|
||||
description: "Configure a self-signed certificate to use with Home Assistant"
|
||||
date: 2016-10-06 08:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Infrastructure
|
||||
---
|
||||
|
||||
If your Home Assistant instance is only accessible from your local network you can still protect the communication between your browsers and the frontend with SSL/TLS. [Let's encrypt](blog/2015/12/13/setup-encryption-using-lets-encrypt/) will only work if you have a DNS entry and remote access is allowed. The solution is to use a self-signed certificate. As you most likely don't have a certification authority (CA) your browser will conplain about the security. If you have a CA then this will not be an issue.
|
||||
|
||||
To create locally a certificate you need the [OpenSSL](https://www.openssl.org/) command-line tool.
|
||||
|
||||
Change to your Home Assistant [configuration directory](/getting-started/configuration/) like `~/.homeassistant`. This will make it easier to backup your certificate and the key. Run the command shown below.
|
||||
|
||||
```bash
|
||||
$ openssl req -new -x509 -sha256 -newkey rsa:4096 -nodes -keyout privkey.pem -days 730 -out fullchain.pem
|
||||
```
|
||||
|
||||
For details about the parameters, please check the OpenSSL documentation. Provide the requested information during the generation process. At the end you will have two files called `privkey.pem` and `fullchain.pem`. The key and the certificate.
|
||||
|
||||
Update the `http:` entry in your `configuration.yaml` file and let it point to your created files.
|
||||
|
||||
```yaml
|
||||
http:
|
||||
api_password: YOUR_SECRET_PASSWORD
|
||||
ssl_certificate: /home/fab/.homeassistant/fullchain.pem
|
||||
ssl_key: /home/fab/.homeassistant/privkey.pem
|
||||
```
|
||||
|
||||
A tutorial "[Working with SSL Certificates, Private Keys and CSRs](https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs)" could give you some insight about special cases.
|
||||
@ -43,9 +43,16 @@
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
Frontend Development
|
||||
{% active_link /developers/asyncio/ Asynchronous Programming %}
|
||||
<ul>
|
||||
<li>{% active_link /developers/asyncio_categorizing_functions/ Categorizing Functions %}</li>
|
||||
<li>{% active_link /developers/asyncio_working_with_async/ Working with Async %}</li>
|
||||
<li>{% active_link /developers/asyncio_misc/ Miscellaneous %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
{% active_link /developers/frontend/ Frontend Development %}
|
||||
<ul>
|
||||
<li>{% active_link /developers/frontend/ Setup Frontend Environment %}</li>
|
||||
<li>{% active_link /developers/frontend_add_card/ Add State Card %}</li>
|
||||
<li>{% active_link /developers/frontend_add_more_info/ Add More Info Dialog %}</li>
|
||||
<li>{% active_link /developers/frontend_creating_custom_panels/ Add Custom Panels %}</li>
|
||||
|
||||
@ -27,6 +27,7 @@
|
||||
<li>{% active_link /getting-started/customizing-devices/ Customizing devices and services %}</li>
|
||||
<li>{% active_link /getting-started/presence-detection/ Presence Detection %}</li>
|
||||
<li>{% active_link /getting-started/troubleshooting-configuration/ Troubleshooting %}</li>
|
||||
<li>{% active_link /getting-started/securing/ Security Check Points %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
@ -97,6 +97,22 @@ sensor
|
||||
- Device Tracker: The `known_device.yaml` file is now validated ([@kellerza])
|
||||
- Minor features and bug fixes by [@tchellomello], [@pavoni], [@fabaff], [@pvizeli], [@lwis], [@turbokongen], [@Danielhiversen], [@persandstrom], [@balloob], [@robbiet480], [@sam-io], [@bbangert], and you if you are missing here.
|
||||
|
||||
### {% linkable_title Release 0.30.1 - October 8 %}
|
||||
|
||||
- Device Tracker `known_devices.yaml` validation is now more accepting ([@kellerza])
|
||||
- Handle X10 light numbers greater than 9 ([@mtl010957])
|
||||
- Fix command line covers without a template ([@roidayan])
|
||||
|
||||
### {% linkable_title Release 0.30.2 - October 12 %}
|
||||
|
||||
- Handle Volvo's with dashes in their name ([@molobrakos])
|
||||
- Fix some html5 push notification configuration options were discarded after first use ([@T3m3z])
|
||||
- Fix Homematic device name with autodiscovery ([@pvizeli])
|
||||
- Make 'pin' optional for zigbee device config ([@flyte])
|
||||
- Fix when sending a notification to a service with target attached (i.e. `notify.html5_unnamed_device_2`) the target was not submitted to the platform as a list causing iteration over every character in the string. ([@robbiet480])
|
||||
- Fix for Slack targets ([@fabaff])
|
||||
- Fix for Pushover targets ([@Nixon506E])
|
||||
|
||||
### {% linkable_title Breaking changes %}
|
||||
|
||||
- All deprecated condition options from `automation` have been removed (deprecated since May and have printed warnings to your console):
|
||||
@ -136,6 +152,11 @@ sensor
|
||||
[@tchellomello]: https://github.com/tchellomello
|
||||
[@turbokongen]: https://github.com/turbokongen
|
||||
[@w1ll1am23]: https://github.com/w1ll1am23
|
||||
[@mtl010957]: https://github.com/mtl010957
|
||||
[@roidayan]: https://github.com/roidayan
|
||||
[@T3m3z]: https://github.com/T3m3z
|
||||
[@flyte]: https://github.com/flyte
|
||||
[@Nixon506E]: https://github.com/Nixon506E
|
||||
|
||||
[arest]: https://arest.io/
|
||||
[arest-sensor]: /components/sensor.arest/
|
||||
|
||||
125
source/_topics/database.markdown
Normal file
125
source/_topics/database.markdown
Normal file
@ -0,0 +1,125 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Home Assistant Database"
|
||||
description: "Details about the database which Home Assistant is using."
|
||||
date: 2016-10-10 10:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
The default database that is used for Home Assistant is [SQLite](https://www.sqlite.org/) and is stored in your [configuration directory](/getting-started/configuration/), eg. `<path to config dir>/.homeassistant/home-assistant_v2.db`. You will need an installation of `sqlite3`, the command-line for SQLite database, or [DB Browser for SQLite](http://sqlitebrowser.org/) which provide an editor for executing SQL commands.
|
||||
First load your database with `sqlite3`.
|
||||
|
||||
```bash
|
||||
$ sqlite3 home-assistant_v2.db
|
||||
SQLite version 3.13.0 2016-05-18 10:57:30
|
||||
Enter ".help" for usage hints.
|
||||
sqlite>
|
||||
```
|
||||
|
||||
It helps to set some options to make the output better readable.
|
||||
|
||||
```bash
|
||||
sqlite> .header on
|
||||
sqlite> .mode column
|
||||
```
|
||||
|
||||
You could also start `sqlite3` and attach the database later. Not sure what database you are working with? Check it, especially if you are going to delete data.
|
||||
|
||||
```bash
|
||||
sqlite> .databases
|
||||
seq name file
|
||||
--- --------------- ----------------------------------------------------------
|
||||
0 main /home/fab/.homeassistant/home-assistant_v2.db
|
||||
```
|
||||
|
||||
### {% linkable_title Schema %}
|
||||
|
||||
Get all available tables from your current Home Assistant database.
|
||||
|
||||
```bash
|
||||
sqlite> SELECT sql FROM sqlite_master;
|
||||
|
||||
-------------------------------------------------------------------------------------
|
||||
CREATE TABLE events (
|
||||
event_id INTEGER NOT NULL,
|
||||
event_type VARCHAR(32),
|
||||
event_data TEXT,
|
||||
origin VARCHAR(32),
|
||||
time_fired DATETIME,
|
||||
created DATETIME,
|
||||
PRIMARY KEY (event_id)
|
||||
)
|
||||
CREATE INDEX ix_events_event_type ON events (event_type)
|
||||
CREATE TABLE recorder_runs (
|
||||
run_id INTEGER NOT NULL,
|
||||
start DATETIME,
|
||||
"end" DATETIME,
|
||||
closed_incorrect BOOLEAN,
|
||||
created DATETIME,
|
||||
PRIMARY KEY (run_id),
|
||||
CHECK (closed_incorrect IN (0, 1))
|
||||
)
|
||||
CREATE TABLE states (
|
||||
state_id INTEGER NOT NULL,
|
||||
domain VARCHAR(64),
|
||||
entity_id VARCHAR(64),
|
||||
state VARCHAR(255),
|
||||
attributes TEXT,
|
||||
event_id INTEGER,
|
||||
last_changed DATETIME,
|
||||
last_updated DATETIME,
|
||||
created DATETIME,
|
||||
PRIMARY KEY (state_id),
|
||||
FOREIGN KEY(event_id) REFERENCES events (event_id)
|
||||
)
|
||||
CREATE INDEX states__significant_changes ON states (domain, last_updated, entity_id)
|
||||
CREATE INDEX states__state_changes ON states (last_changed, last_updated, entity_id)
|
||||
CREATE TABLE sqlite_stat1(tbl,idx,stat)
|
||||
```
|
||||
|
||||
To only show the details about the `states` table as we are using that one in the next examples.
|
||||
|
||||
```bash
|
||||
sqlite> SELECT sql FROM sqlite_master WHERE type = 'table' AND tbl_name = 'states';
|
||||
```
|
||||
|
||||
### {% linkable_title Query %}
|
||||
|
||||
The identification of the available columns in the table is done and we are now able to create a query. Let's list of your Top 10 entities.
|
||||
|
||||
```bash
|
||||
sqlite> .width 30, 10,
|
||||
sqlite> SELECT entity_id, COUNT(*) as count FROM states GROUP BY entity_id ORDER BY count DESC LIMIT 10;
|
||||
entity_id count
|
||||
------------------------------ ----------
|
||||
sensor.cpu 28874
|
||||
sun.sun 21238
|
||||
sensor.time 18415
|
||||
sensor.new_york 18393
|
||||
cover.kitchen_cover 17811
|
||||
switch.mystrom_switch 14101
|
||||
sensor.internet_time 12963
|
||||
sensor.solar_angle1 11397
|
||||
sensor.solar_angle 10440
|
||||
group.all_switches 8018
|
||||
```
|
||||
|
||||
### {% linkable_title Delete %}
|
||||
|
||||
If you don't want to keep certain entities, you can delete them permanently.
|
||||
|
||||
```bash
|
||||
sqlite> DELETE FROM states WHERE entity_id="sensor.cpu";
|
||||
```
|
||||
|
||||
The `VACUUM` command cleans the your database.
|
||||
|
||||
```bash
|
||||
sqlite> VACUUM;
|
||||
```
|
||||
|
||||
For a more interactive way to work with the database or the create statistics, checkout our [Jupyther notebooks](http://nbviewer.jupyter.org/github/home-assistant/home-assistant-notebooks/blob/master/).
|
||||
|
||||
@ -3,7 +3,7 @@ layout: page
|
||||
title: "Entity component platform options"
|
||||
description: "Shows how to customize polling interval for any component via configuration.yaml."
|
||||
date: 2016-02-12 23:17 -0800
|
||||
sidebar: true
|
||||
sidebar: false
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
|
||||
@ -58,10 +58,6 @@ zwave:
|
||||
config_path: /usr/local/share/python-openzwave/config
|
||||
polling_interval: 10000
|
||||
|
||||
#zigbee:
|
||||
# device: /dev/ttyUSB1
|
||||
# baud: 115200
|
||||
|
||||
mqtt:
|
||||
broker: 127.0.0.1
|
||||
```
|
||||
@ -115,10 +111,7 @@ This (large) sensor configuration gives us another example:
|
||||
|
||||
```yaml
|
||||
### sensors.yaml
|
||||
##############################################################
|
||||
### METEOBRIDGE ####
|
||||
##############################################################
|
||||
|
||||
### METEOBRIDGE #############################################
|
||||
- platform: tcp
|
||||
name: 'Outdoor Temp (Meteobridge)'
|
||||
host: 192.168.2.82
|
||||
@ -134,27 +127,14 @@ This (large) sensor configuration gives us another example:
|
||||
payload: "Content-type: text/xml; charset=UTF-8\n\n"
|
||||
value_template: "{% raw %}{{value.split (' ')[3]}}{% endraw %}"
|
||||
unit: Percent
|
||||
- platform: tcp
|
||||
name: 'Outdoor Dewpoint (Meteobridge)'
|
||||
host: 192.168.2.82
|
||||
port: 5556
|
||||
timeout: 6
|
||||
payload: "Content-type: text/xml; charset=UTF-8\n\n"
|
||||
value_template: "{% raw %}{{value.split (' ')[4] }}{% endraw %}"
|
||||
unit: C
|
||||
###################################
|
||||
#### STEAM FRIENDS ####
|
||||
##################################
|
||||
|
||||
#### STEAM FRIENDS ##################################
|
||||
- platform: steam_online
|
||||
api_key: [not telling]
|
||||
accounts:
|
||||
- 76561198012067051
|
||||
|
||||
##################################
|
||||
#### TIME/DATE ####
|
||||
##################################
|
||||
|
||||
#### TIME/DATE ##################################
|
||||
- platform: time_date
|
||||
display_options:
|
||||
- 'time'
|
||||
@ -165,12 +145,6 @@ This (large) sensor configuration gives us another example:
|
||||
- platform: worldclock
|
||||
time_zone: America/New_York
|
||||
name: 'Ann Arbor'
|
||||
- platform: worldclock
|
||||
time_zone: Europe/Vienna
|
||||
name: 'Innsbruck'
|
||||
- platform: worldclock
|
||||
time_zone: America/New_York
|
||||
name: 'Ann Arbor'
|
||||
```
|
||||
|
||||
You'll notice that this example includes a secondary parameter section (under the steam section) as well as a better example of the way comments can be used to break down files into sections.
|
||||
|
||||
39
source/_topics/webserver_details.markdown
Normal file
39
source/_topics/webserver_details.markdown
Normal file
@ -0,0 +1,39 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Details about the web server"
|
||||
description: "Use nmap to scan your Home Assistant instance."
|
||||
date: 2016-10-06 08:00
|
||||
sidebar: false
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Infrastructure
|
||||
---
|
||||
|
||||
It was only a matter of time till the first queries for tools like [https://www.shodan.io](https://www.shodan.io/search?query=Home+Assistant) to search for Home Assistant instances showed up.
|
||||
|
||||
To get an idea about how your Home Assistant instance looks like for network scanner, you can use `nmap`. The `nmap` tool is already available if you are using the [nmap device tracker](/components/device_tracker/).
|
||||
|
||||
```yaml
|
||||
$ nmap -sV -p 8123 --script=http-title,http-headers 192.168.1.3
|
||||
|
||||
Starting Nmap 7.12 ( https://nmap.org ) at 2016-10-06 10:01 CEST
|
||||
Nmap scan report for 192.168.1.3 (192.168.1.3)
|
||||
Host is up (0.00011s latency).
|
||||
PORT STATE SERVICE VERSION
|
||||
8123/tcp open http CherryPy wsgiserver
|
||||
| http-headers:
|
||||
| Content-Type: text/html; charset=utf-8
|
||||
| Content-Length: 4309
|
||||
| Connection: close
|
||||
| Date: Thu, 06 Oct 2016 08:01:31 GMT
|
||||
| Server: Home Assistant
|
||||
|
|
||||
|_ (Request type: GET)
|
||||
|_http-server-header: Home Assistant
|
||||
|_http-title: Home Assistant
|
||||
|
||||
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
|
||||
Nmap done: 1 IP address (1 host up) scanned in 6.70 seconds
|
||||
```
|
||||
|
||||
12
source/configuration_yaml_by_mertenats.markdown
Normal file
12
source/configuration_yaml_by_mertenats.markdown
Normal file
@ -0,0 +1,12 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Configuration.yaml by mertenats"
|
||||
description: ""
|
||||
date: 2016-10-08 19:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Example configuration.yaml
|
||||
ha_external_link: https://github.com/mertenats/open-home-automation/tree/master/openhome
|
||||
---
|
||||
27
source/developers/asyncio.markdown
Normal file
27
source/developers/asyncio.markdown
Normal file
@ -0,0 +1,27 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Asynchronous Programming"
|
||||
description: "Introduction to the asynchronous core of Home Assistant."
|
||||
date: 2016-10-17 21:49
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
On September 29, 2016 we released [Home Assistant 0.29][0.29] as part of our bi-weekly release schedule. This release introduced a complete overhaul of the core spearheaded by [Ben Bangert][ben].
|
||||
|
||||
The old core was set up like a “traditional” threaded application. Each resource that was not thread safe (ie. the state of entities) would be protected by a lock. This caused a lot of waiting and potential inconsistency because a task could now end up waiting halfway through it’s job until some resource got freed.
|
||||
|
||||
Our new core is based on an Python’s built-in asyncio module. Instead of having all threads have access to the core API objects, access is now limited to a special thread called the event loop. All components will now schedule themselves as a task to be executed by the event loop. This gives us the guarantee that only one task is executed at once, meaning we no longer need any locks.
|
||||
|
||||
The only problem with running everything inside the event loop is when a task is doing blocking I/O, what most third-party Python libraries are doing. For example while requesting new information from a device, the core will stop running until we get a response from the device. To handle this, a task is able to suspend itself until the response is available after which it will be enqueued for the event loop to process the result.
|
||||
|
||||
For a task to be able to suspend itself, all code that it calls has to have this capability added. This means in practice that each device integration will need a full rewrite of the library that offers the integration! As this is not something that can be achieved, ever, a 100% backwards compatible API has been added so that no platform will require updating.
|
||||
|
||||
The backwards compatible API works by scheduling a task from a different thread and blocking that thread until the task has been processed by the event loop.
|
||||
|
||||
### [Next step: Categorizing Functions »](/developers/asyncio_categorizing_functions/)
|
||||
|
||||
[0.29]: https://home-assistant.io/blog/2016/09/29/async-sleepiq-emoncms-stocks/
|
||||
[ben]: https://github.com/bbangert/
|
||||
79
source/developers/asyncio_categorizing_functions.markdown
Normal file
79
source/developers/asyncio_categorizing_functions.markdown
Normal file
@ -0,0 +1,79 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Categorizing Functions"
|
||||
description: "A categorization of functions to work with the asynchronous core of Home Assistant."
|
||||
date: 2016-10-17 21:49
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
A piece of work within Home Assistant is represented by a function that will be invoked. It will either run inside our event loop or inside our thread pool, depending on if it is async safe.
|
||||
|
||||
Home Assistant uses the convention that all functions that must be run from within the event loop are prefixed with `async_`.
|
||||
|
||||
## {% linkable_title The coroutine function %}
|
||||
|
||||
Coroutines are special functions based on Python’s generators syntax which allows them to suspend execution while waiting on a result.
|
||||
|
||||
Invoking a coroutine function will return a Generator object back, but will not actually begin execution. This object will execute the task when it is either yielded from (from within another coroutine) or it is scheduled on the event loop.
|
||||
|
||||
To declare a function a coroutine, import the coroutine annotation from the asyncio package and annotate your function.
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
@asyncio.coroutine
|
||||
def async_look_my_coroutine(target):
|
||||
result = yield from entity.async_turn_on()
|
||||
if result:
|
||||
print("hello {}".format(target))
|
||||
|
||||
hass.loop.create_task(async_look_my_coroutine("world")
|
||||
```
|
||||
|
||||
In this example, we schedule the coroutine by calling `hass.loop.create_task`. This will add the coroutine to the queue of tasks to be run. When the event loop is running `async_look_my_coroutine` it will suspend the task when `yield from entity.async_turn_on()` is called. At that point a new task will be scheduled to execute `entity.async_turn_on()`. When that job has been executed, `async_look_my_coroutine` will resume.
|
||||
|
||||
## {% linkable_title The callback function %}
|
||||
|
||||
This is a normal function that is considered safe to be run from within the event loop. A callback is unable to suspend itself and thus cannot do any I/O or call a coroutine. A callback is capable of scheduling a new task but it will not be able to wait for the results.
|
||||
|
||||
To declare a function as a callback, import the callback annotation from the core package and annotate your function.
|
||||
|
||||
A common use case for a callback in Home Assistant is as a listener for an event or a service call. It can process the incoming information and then schedule the right calls to be made. Example from the automation component.
|
||||
|
||||
```python
|
||||
from homeassistant.core import callback
|
||||
|
||||
@callback
|
||||
def async_trigger_service_handler(service_call):
|
||||
"""Handle automation trigger service calls."""
|
||||
vars = service_call.data.get(ATTR_VARIABLES)
|
||||
for entity in component.async_extract_from_service(service_call):
|
||||
hass.loop.create_task(entity.async_trigger(vars, True))
|
||||
```
|
||||
|
||||
In this example, `entity.async_trigger` is a coroutine function. Invoking the coroutine function will return a coroutine task. The passed in parameters will be used when the task gets executed.
|
||||
|
||||
To execute the task we have to schedule it for execution on the event loop. This is done by calling `hass.loop.create_task`.
|
||||
|
||||
### {% linkable_title Why even have callbacks? %}
|
||||
|
||||
You might wonder, if a coroutine can do everything a callback can do, why even have a callback. The reason is performance and better state consistency of the core API objects.
|
||||
|
||||
When coroutine A waits for coroutine B, it will suspend itself and schedule a new task to run B. This means that the event loop is now running A, B and then A again. If B is a callback, A will never have to suspend itself and thus the event loop is just running A. The consistency implication is that other events queued to run on the event loop continue to wait until callbacks complete, but will be interleaved when yielding to another coroutine.
|
||||
|
||||
## {% linkable_title Event loop and thread safe %}
|
||||
|
||||
These are functions that are safe to run both in a thread and inside the event loop. These functions are usually performing a computation or transform data in memory. Anything that does I/O does not fall under this category. Many standard library functions fall in this category. For example generating the sum of a set of numbers using sum or merging two dictionaries.
|
||||
|
||||
There is no special annotation to mark functions as part of this category and care should be taken when using these functions from inside the event loop. When in doubt, look at their implementation.
|
||||
|
||||
## {% linkable_title Other functions %}
|
||||
|
||||
These are all the functions that did not fit in the previous categories. These functions are either thread-safe or not considered safe to be run within the event loop. These are functions that use sleep, or perform I/O.
|
||||
|
||||
There is no special annotation necessary to be considered part of this category.
|
||||
|
||||
### [Next step: Working with Async »](/developers/asyncio_working_with_async/)
|
||||
22
source/developers/asyncio_misc.markdown
Normal file
22
source/developers/asyncio_misc.markdown
Normal file
@ -0,0 +1,22 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Miscellaneous Async"
|
||||
description: "A collection of miscellaneous topics about async that didn't fit on the other pages."
|
||||
date: 2016-10-17 21:49
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
## {% linkable_title What about ‘async’ and ‘await’ syntax? %}
|
||||
Python 3.5 introduced new syntax to formalize the asynchronous pattern. This is however not compatible with Python 3.4. The minimum required Python version for Home Assistant is based on the Python version shipped with Debian stable, which is currently 3.4.2.
|
||||
|
||||
For more information, Brett Cannon wrote [an excellent breakdown][brett] on 'async' and 'await' syntax and how asynchronous programming works.
|
||||
|
||||
## {% linkable_title Acknowledgements %}
|
||||
|
||||
Huge thanks to [Ben Bangert][ben] for starting the conversion of the core to async, guiding other contributors while taking their first steps with async programming and peer reviewing this documentation.
|
||||
|
||||
[brett]: http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5
|
||||
[ben]: https://github.com/bbangert/
|
||||
113
source/developers/asyncio_working_with_async.markdown
Normal file
113
source/developers/asyncio_working_with_async.markdown
Normal file
@ -0,0 +1,113 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Working with Async"
|
||||
description: "A breakdown of all the different ways to work with the asynchronous core of Home Assistant."
|
||||
date: 2016-10-17 21:49
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
Although we have a backwards compatible API, using the async core directly will be a lot faster. Most core components have already been rewritten to leverage the async core. This includes the EntityComponent helper (foundation of light, switch, etc), scripts, groups and automation.
|
||||
|
||||
## {% linkable_title Interacting with the core %}
|
||||
|
||||
[All methods in the Home Assistant core][dev-docs] are implemented in two flavors: an async version and a version to be called from other threads. The versions for other are merely wrappers that call the async version in a threadsafe manner using [the available async utilities][dev-docs-async].
|
||||
|
||||
So if you are making calls to the core (the hass object) from within a callback or coroutine, use the methods that start with async_. If you need to call an async_ function that is a coroutine, your task must also be a coroutine.
|
||||
|
||||
## {% linkable_title Implementing an async component %}
|
||||
|
||||
We currently do not support async setup for components. We do however support using async functions as service handlers. Just define your handlers as a callback or coroutine and register them as usual.
|
||||
|
||||
## {% linkable_title Implementing an async platform %}
|
||||
|
||||
For platforms we support async setup. Instead of setup_platform you need to have a coroutine async_setup_platform.
|
||||
|
||||
```python
|
||||
setup_platform(hass, config, add_entities, discovery_info=None):
|
||||
# Setup your platform outside of the event loop.
|
||||
```
|
||||
|
||||
Will turn into:
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
@asyncio.coroutine
|
||||
def async_setup_platform(hass, config, async_add_entities,
|
||||
discovery_info=None):
|
||||
# Setup your platform inside of the event loop
|
||||
```
|
||||
|
||||
The only difference with the original parameters is that the add_entities function has been replaced by the coroutine `async_add_entities`.
|
||||
|
||||
## {% linkable_title Implementing an async entity %}
|
||||
|
||||
You can make your entity async friendly by converting your update method to be async. This requires the dependency of your entities to also be async friendly!
|
||||
|
||||
```python
|
||||
class MyEntity(Entity):
|
||||
def update(self):
|
||||
"""Retrieve latest state."""
|
||||
self._state = fetch_state()
|
||||
```
|
||||
|
||||
Will turn into:
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
class MyEntity(Entity):
|
||||
@asyncio.coroutine
|
||||
def async_update(self):
|
||||
"""Retrieve latest state."""
|
||||
self._state = yield from async_fetch_state()
|
||||
```
|
||||
|
||||
Make sure that all properties defined on your entity do not result in I/O being done. All data has to be fetched inside the update method and cached on the entity. This is because these properties are read from within the event loop and thus doing I/O will result in the core of Home Assistant waiting until your I/O is done.
|
||||
|
||||
## {% linkable_title Calling async functions from threads %}
|
||||
|
||||
Sometimes it will happen that you’re in a thread and you want to call a function that is only available as async. Home Assistant includes a few async helper utilities to help with this.
|
||||
|
||||
In the following example, `say_hello` will schedule `async_say_hello` and block till the function has run and get the result back.
|
||||
|
||||
```python
|
||||
from homeassistant.util.async import run_callback_threadsafe
|
||||
|
||||
def say_hello(hass, target):
|
||||
return run_callback_threadsafe(
|
||||
hass.loop, async_say_hello, target).result()
|
||||
|
||||
def async_say_hello(hass, target):
|
||||
return "Hello {}!".format(target)
|
||||
```
|
||||
|
||||
## {% linkable_title Dealing with passed in functions %}
|
||||
|
||||
If your code takes in functions from other code, you will not know which category the function belongs to and how they should be invoked. This usually only occurs if your code supplies an event helper like `mqtt.async_subscribe` or `track_state_change_listener`.
|
||||
|
||||
To help with this, there are two helper methods on the hass object that you can call from inside the event loop:
|
||||
|
||||
#### {% linkable_title hass.async_run_job %}
|
||||
|
||||
Use this method if the function should be called as soon as possible. This will call callbacks immediately, schedule coroutines for execution on the event loop and schedule other functions to be run inside the thread pool.
|
||||
|
||||
| Callback | Call immediately.
|
||||
| Coroutine | Schedule for execution on the event loop.
|
||||
| Other functions | Schedule for execution in the thread pool.
|
||||
|
||||
#### {% linkable_title hass.async_add_job %}
|
||||
|
||||
Use this method if the function should be called but not get priority over already scheduled calls.
|
||||
|
||||
| Callback | Schedule for execution on the event loop.
|
||||
| Coroutine | Schedule for execution on the event loop.
|
||||
| Other functions | Schedule for execution in the thread pool.
|
||||
|
||||
### [Next step: Miscellaneous »](/developers/asyncio_misc/)
|
||||
|
||||
[dev-docs]: https://dev-docs.home-assistant.io/en/master/api/core.html
|
||||
[dev-docs-async]: https://dev-docs.home-assistant.io/en/dev/api/util.html#module-homeassistant.util.async
|
||||
@ -82,5 +82,5 @@ SENSOR_TYPES = {
|
||||
PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
|
||||
...
|
||||
vol.Optional(CONF_MONITORED_VARIABLES, default=[]):
|
||||
vol.All(ensure_list, [vol.In(SENSOR_TYPES)]),
|
||||
vol.All(cv.ensure_list, [vol.In(SENSOR_TYPES)]),
|
||||
```
|
||||
|
||||
@ -11,9 +11,11 @@ footer: true
|
||||
|
||||
In the package [`homeassistant.remote`](https://github.com/home-assistant/home-assistant/blob/master/homeassistant/remote.py) a Python API on top of the [HTTP API](/developers/api/) can be found.
|
||||
|
||||
This page is not a full documentation it's more a collection of some example. A simple way to get all current entities is to visit the "Set State" page in the "Developer Tools". For the examples below just choose one from the available entries. Here the sensor `sensor.office_temperature` and the switch `switch.livingroom_pin_2` are used.
|
||||
Note: This page is not full documentation for this API, but a collection of examples showing its use.
|
||||
|
||||
First, import the module and setup the basics.
|
||||
A simple way to get all current entities is to visit the "Set State" page in the "Developer Tools". For the examples below just choose one from the available entries. Here the sensor `sensor.office_temperature` and the switch `switch.livingroom_pin_2` are used.
|
||||
|
||||
First import the module and setup the basics:
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -22,7 +24,7 @@ api = remote.API('127.0.0.1', 'password')
|
||||
print(remote.validate_api(api))
|
||||
```
|
||||
|
||||
This snippet shows how to use the `homeassistant.remote` package in another way.
|
||||
Here's another way to use the `homeassistant.remote` package:
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -35,7 +37,7 @@ living_room = hass.states.get('group.living_room')
|
||||
|
||||
### {% linkable_title Get configuration %}
|
||||
|
||||
Get the current configuration of a Home Assistant instance.
|
||||
Get the current configuration of a Home Assistant instance:
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -47,7 +49,7 @@ print(remote.get_config(api))
|
||||
|
||||
### {% linkable_title Get details about services, events, and entitites %}
|
||||
|
||||
Similar to the output in the "Developer Tools" of the frontend.
|
||||
The output from this is similar to the output you'd find via the frontend, using the DevTools console.
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -72,7 +74,7 @@ for entity in entities:
|
||||
|
||||
### {% linkable_title Get the state of an entity %}
|
||||
|
||||
To get the details of a single entity the `get_state` method is used.
|
||||
To get the details of a single entity, use `get_state`:
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -86,13 +88,13 @@ print('{} is {} {}.'.format(office_temperature.attributes['friendly_name'],
|
||||
)
|
||||
```
|
||||
|
||||
The output is composed out of the details which are stored for this entity.
|
||||
This outputs the details which are stored for this entity, ie:
|
||||
|
||||
```bash
|
||||
Office Temperature is 19 °C.
|
||||
```
|
||||
|
||||
The exact same thing is working for a switch. The difference is that both entities have different attributes.
|
||||
Switches work the same way. The only difference is that both entities have different attributes.
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -107,7 +109,7 @@ print('{} is {}.'.format(switch_livingroom.attributes['friendly_name'],
|
||||
|
||||
### {% linkable_title Set the state of an entity %}
|
||||
|
||||
Of course, it's possible to set the state.
|
||||
Of course, it's possible to set the state as well:
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -118,11 +120,11 @@ remote.set_state(api, 'sensor.office_temperature', new_state=123)
|
||||
remote.set_state(api, 'switch.livingroom_pin_2', new_state=STATE_ON)
|
||||
```
|
||||
|
||||
The state will be set to those value until the next update occurs.
|
||||
The state will be set to the new values until the next update occurs.
|
||||
|
||||
### {% linkable_title Blinking all entities of a domain %}
|
||||
|
||||
If you want to turn on all entities of a domain, just use a service which was retrieved by `get_services`.
|
||||
If you want to turn on all entities of a domain, retrieve the service via `get_services` and act on that:
|
||||
|
||||
|
||||
```python
|
||||
@ -139,7 +141,7 @@ remote.call_service(api, domain, 'turn_off')
|
||||
|
||||
### {% linkable_title Control a single entity %}
|
||||
|
||||
To turn on or off a single switch. The ID of the entity is needed as an attribute.
|
||||
To turn on or off a single switch, pass the ID of the entity:
|
||||
|
||||
```python
|
||||
import time
|
||||
@ -156,9 +158,9 @@ remote.call_service(api, domain, 'turn_off', {'entity_id': '{}'.format(switch_na
|
||||
|
||||
### {% linkable_title Specify a timeout %}
|
||||
|
||||
The default timeout for an API call with `call_service` is 5 seconds. Service
|
||||
The default timeout for an API call with `call_service` is 5 seconds. Services
|
||||
taking longer than this to return will raise
|
||||
`homeassistant.exceptions.HomeAssistantError: Timeout` unless provided with a
|
||||
`homeassistant.exceptions.HomeAssistantError: Timeout`, unless provided with a
|
||||
longer timeout.
|
||||
|
||||
```python
|
||||
@ -180,7 +182,7 @@ remote.call_service(api, domain, 'turn_on', {'entity_id': switch_name},
|
||||
|
||||
### {% linkable_title Send a notification %}
|
||||
|
||||
The example uses the jabber notification platform to send a single message to the given recipient in the `configuration.yaml` file.
|
||||
The example uses the Jabber notification platform to send a single message to the given recipient in the `configuration.yaml` file:
|
||||
|
||||
```python
|
||||
import homeassistant.remote as remote
|
||||
@ -192,4 +194,4 @@ data = {"title":"Test", "message":"A simple test message from HA."}
|
||||
remote.call_service(api, domain, 'jabber', data)
|
||||
```
|
||||
|
||||
For more details please check the source of [homeassistant.remote](https://github.com/home-assistant/home-assistant/blob/master/homeassistant/remote.py).
|
||||
For more details, please check the source of [homeassistant.remote](https://github.com/home-assistant/home-assistant/blob/master/homeassistant/remote.py).
|
||||
|
||||
@ -54,7 +54,7 @@ Successful calls will return status code 200 or 201. Other status codes that can
|
||||
The API supports the following actions:
|
||||
|
||||
#### {% linkable_title GET /api/ %}
|
||||
Returns message if API is up and running.
|
||||
Returns a message if the API is up and running.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -142,7 +142,7 @@ $ curl -X GET -H "x-ha-access: YOUR_PASSWORD" \
|
||||
```
|
||||
|
||||
#### {% linkable_title GET /api/events %}
|
||||
Returns an array of event objects. Each event object contain event name and listener count.
|
||||
Returns an array of event objects. Each event object contains event name and listener count.
|
||||
|
||||
```json
|
||||
[
|
||||
@ -193,7 +193,7 @@ $ curl -X GET -H "x-ha-access: YOUR_PASSWORD" \
|
||||
```
|
||||
|
||||
#### {% linkable_title GET /api/history %}
|
||||
Returns an array of state changes in the past. Each object contains further detail for the entities.
|
||||
Returns an array of state changes in the past. Each object contains further details for the entities.
|
||||
|
||||
```json
|
||||
[
|
||||
@ -377,7 +377,7 @@ Returns a message if successful.
|
||||
```
|
||||
|
||||
#### {% linkable_title POST /api/services/<domain>/<service> %}
|
||||
Calls a service within a specific domain. Will return when the service has been executed or 10 seconds has past, whichever comes first.
|
||||
Calls a service within a specific domain. Will return when the service has been executed or after 10 seconds, whichever comes first.
|
||||
|
||||
You can pass an optional JSON object to be used as `service_data`.
|
||||
|
||||
@ -416,7 +416,7 @@ $ curl -X POST -H "x-ha-access: YOUR_PASSWORD" \
|
||||
```
|
||||
|
||||
<p class='note'>
|
||||
The result will include any changed states that changed while the service was being executed, even if their change was the result of something else happening in the system.
|
||||
The result will include any states that changed while the service was being executed, even if their change was the result of something else happening in the system.
|
||||
</p>
|
||||
|
||||
#### {% linkable_title POST /api/template %}
|
||||
@ -443,7 +443,7 @@ $ curl -X POST -H "x-ha-access: YOUR_PASSWORD" \
|
||||
```
|
||||
|
||||
#### {% linkable_title POST /api/event_forwarding %}
|
||||
Setup event forwarding to another Home Assistant instance.
|
||||
Set up event forwarding to another Home Assistant instance.
|
||||
|
||||
Requires a JSON object that represents the API to forward to.
|
||||
|
||||
@ -455,7 +455,7 @@ Requires a JSON object that represents the API to forward to.
|
||||
}
|
||||
```
|
||||
|
||||
It will return a message if event forwarding was setup successful.
|
||||
It will return a message if event forwarding was set up successfully.
|
||||
|
||||
```json
|
||||
{
|
||||
|
||||
@ -22,7 +22,7 @@ $ curl -X GET -H "x-ha-access: YOUR_PASSWORD" \
|
||||
-H "Content-Type: application/json" http://localhost:8123/api/stream
|
||||
```
|
||||
|
||||
For more comfort put the HTML snippet below in a file `sse.html` in your `www` folder of your Home Assistant configuration directory (`.homeassistant`)
|
||||
You can create a convenient view for this by creating an HTML file (`sse.html`) in the `www` folder of your Home Assistant configuration directory (`.homeassistant`). Paste this snippet into the file:
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
@ -44,7 +44,7 @@ Visit [http://localhost:8123/local/sse.html](http://localhost:8123/local/sse.htm
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
A simplest way to consume server-sent events is `httpie`.
|
||||
A simple way to consume server-sent events is to use a command-line http client like [httpie][https://httpie.org/]. Installation info is on the site (if you use Homebrew, it's `brew install httpie`). Once installed, run this snippet from your terminal:
|
||||
|
||||
```bash
|
||||
$ http --stream http://localhost:8123/api/stream x-ha-access:YOUR_PASSWORD content-type:application/json
|
||||
@ -52,17 +52,21 @@ $ http --stream http://localhost:8123/api/stream x-ha-access:YOUR_PASSWORD conte
|
||||
|
||||
### {% linkable_title Website %}
|
||||
|
||||
The [home-assistant-sse](https://github.com/fabaff/home-assistant-sse) repository contains an more advanced example.
|
||||
The [home-assistant-sse](https://github.com/fabaff/home-assistant-sse) repository contains a more advanced example.
|
||||
|
||||
### {% linkable_title Python %}
|
||||
|
||||
If you want to test the server-sent events without creating a website then the Python module [`sseclient` ](https://pypi.python.org/pypi/sseclient/) can help. Install it first:
|
||||
If you want to test the server-sent events without creating a website, the Python module [`sseclient` ](https://pypi.python.org/pypi/sseclient/) can help. To install (assuming Python and pip3 are already installed):
|
||||
|
||||
```bash
|
||||
$ pip3 install sseclient
|
||||
```
|
||||
|
||||
<<<<<<< HEAD
|
||||
The simplest script to consume the SSE looks like the following snippet.
|
||||
=======
|
||||
The simplest script to consume the SSE in Python looks like this:
|
||||
>>>>>>> current
|
||||
|
||||
```python
|
||||
from sseclient import SSEClient
|
||||
|
||||
@ -72,12 +72,16 @@ You can use the default markdown syntax to generate syntax highlighted code. For
|
||||
```{% endraw %}
|
||||
```
|
||||
|
||||
If you are using templates then those parts need to be [escaped](http://stackoverflow.com/a/24102537). Otherwise, they will be rendered and appear blank on the website.
|
||||
|
||||
Note that you can replace `yaml` next to \`\`\` with the language that is within the block.
|
||||
|
||||
When you're writing code that is to be executed on the terminal, prefix it with `$`.
|
||||
|
||||
### {% linkable_title Templates %}
|
||||
|
||||
For the [configuration templating](/topics/templating/) is [Jinja](http://jinja.pocoo.org/) used.
|
||||
|
||||
If you are using templates then those parts needs to be [escaped](http://stackoverflow.com/a/24102537). Otherwise they will be rendered and appear blank on the website.
|
||||
|
||||
### {% linkable_title HTML %}
|
||||
|
||||
The direct usage of HTML is supported but not recommended. The note boxes are an exception.
|
||||
|
||||
@ -11,13 +11,6 @@ footer: true
|
||||
|
||||
Conditions are an optional part of an automation rule and be used to prevent an action from happening when triggered. Conditions look very similar to triggers but are very different. A trigger will look at events happening in the system while a condition only looks at how the system looks right now. A trigger can observe that a switch is being turned on. A condition can only see if a switch is currently on or off.
|
||||
|
||||
If your triggers and conditions are exactly the same, you can use a shortcut to specify conditions. In this case, triggers that are not valid conditions will be ignored.
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
condition: use_trigger_values
|
||||
```
|
||||
|
||||
The available conditions for an automation are the same as for the script syntax. So see that page for a [full list of available conditions][script-condition].
|
||||
|
||||
Example of using condition:
|
||||
|
||||
@ -17,6 +17,7 @@ In this example, we are defining a trigger to track the sunset and tell it to fi
|
||||
# Example configuration.yaml entry
|
||||
automation:
|
||||
alias: Turn on light when sun sets
|
||||
initial_state: True
|
||||
hide_entity: False
|
||||
trigger:
|
||||
platform: sun
|
||||
@ -25,7 +26,7 @@ automation:
|
||||
service: light.turn_on
|
||||
```
|
||||
|
||||
Starting with 0.28 automation rules can be reloaded from the [frontend](/components/automation/) and are shown by default. With [`hide_entity:`](/components/automation/) you can control this behaviour. It's is very handy if you are working on your rules but when a rule is finished and you don't want to see that rule in your frontend, you can set `hide_entity:` to `True`.
|
||||
Starting with 0.28 automation rules can be reloaded from the [frontend](/components/automation/) and are shown by default. With [`hide_entity:`](/components/automation/) you can control this behaviour. It's is very handy if you are working on your rules but when a rule is finished and you don't want to see that rule in your frontend, you can set `hide_entity:` to `True`. To set an automation to be disabled when HASS starts set `initial_state:` to `False`.
|
||||
|
||||
After a few days of running this automation rule you come to realize that this automation rule is not good enough. It was already dark when the lights went on and the one day you weren't home, the lights turned on anyway. Time for some tweaking. Let's add an offset to the sunset trigger and a condition to only turn on the lights if anyone is home.
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ footer: true
|
||||
|
||||
In Home Assistant 0.19 we introduced a new powerful feature: variables in scripts and automations. This makes it possible to adjust your condition and action based on the information of the trigger.
|
||||
|
||||
The trigger data made is available during template rendering as the `trigger` variable.
|
||||
The trigger data made is available during [template](/topics/templating/) rendering as the `trigger` variable.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entries
|
||||
|
||||
@ -31,7 +31,7 @@ The first line is the trigger of the automation rule. Triggers describe events t
|
||||
|
||||
The second line is the condition part of the automation rule. Conditions are optional tests that can limit an automation rule to only work in your specific use cases. A condition will test against the current state of the system. This includes the current time, devices, people and other things like the sun. In this case we only want to act when the sun has set.
|
||||
|
||||
The third part is the action which will be performed when a rule is triggered and all conditions are met.For example, it can turn a light on, set the temperature on your thermostat or activate a scene.
|
||||
The third part is the action which will be performed when a rule is triggered and all conditions are met. For example, it can turn a light on, set the temperature on your thermostat or activate a scene.
|
||||
|
||||
<p class='note'>
|
||||
The difference between a condition and a trigger can be confusing as they are very similar. Triggers look at the actions, while conditions look at the results: turning a light on vs a light being on.
|
||||
|
||||
@ -9,7 +9,7 @@ sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
Below you can find the standard instructions. See the sidebar for installation instructions for specific platforms. If you're running a Linux-based platform, we suggest to follow the [VirtualEnv Linux instructions] to avoid having to use root.
|
||||
Below you can find the standard instructions. See the sidebar for installation instructions for specific platforms. If you're running a Linux-based platform, we suggest you to follow the [VirtualEnv Linux instructions] to avoid using root.
|
||||
|
||||
[Virtualenv Linux instructions]: /getting-started/installation-virtualenv/
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Hassbian image for Raspberry Pi"
|
||||
description: "Instructions to flash the Home Assistant Hassbian image on a Raspberry Pi."
|
||||
title: "HASSbian image for Raspberry Pi"
|
||||
description: "Instructions to flash the Home Assistant HASSbian image on a Raspberry Pi."
|
||||
date: 2016-09-26 21:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
@ -9,15 +9,15 @@ sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
The easiest way to install Home Assistant on your Raspberry Pi is by using Hassbian: a Raspberry Pi image with Home Assistant built-in. The image will install the latest version of Home Assistant on initial boot (~5 minutes).
|
||||
The easiest way to install Home Assistant on your Raspberry Pi is by using HASSbian: a Raspberry Pi image with Home Assistant built-in. The image will install the latest version of Home Assistant on initial boot (~5 minutes).
|
||||
|
||||
1. [Download the latest image][image-download]
|
||||
2. Flash the image to an SD card:
|
||||
- [Windows][flash-windows]
|
||||
- [Linux][flash-linux]
|
||||
- [Mac][flash-macos]
|
||||
- [Mac OS][flash-macos]
|
||||
3. Ensure your Raspberry Pi has access to the internet.
|
||||
4. Insert SD card to Raspberry Pi and turn it on. Initial installation of Home Assistant will take 5 minutes.
|
||||
4. Insert SD card to Raspberry Pi and turn it on. Initial installation of Home Assistant will take about 5 minutes.
|
||||
|
||||
These instructions are also available as a [video](https://www.youtube.com/watch?v=iIz6XqDwHEk).
|
||||
|
||||
@ -36,21 +36,104 @@ Some extra tips:
|
||||
|
||||
### {% linkable_title Technical Details %}
|
||||
|
||||
- Home Assistant is installed in a virtual Python environment at `src/homeassistant`
|
||||
- Home Assistant is installed in a virtual Python environment at `/src/homeassistant/`
|
||||
- Home Assistant will be started as a service run by the user `homeassistant`
|
||||
- The configuration is located at `/home/homeassistant/.homeassistant`
|
||||
|
||||
{% comment %}
|
||||
### {% linkable_title Managing your HASSbian installation %}
|
||||
#### {% linkable_title Login to HASSbian on the Raspberry Pi %}
|
||||
To login to your Raspberry Pi running HASSbian your going to be using a ssh client. Depending on your platform there are several alternatives for doing this. Linux and Max OS generally have a ssh client installed. Windows users are recommended to download and install the ssh client [Putty][ssh-putty].
|
||||
|
||||
TODO:
|
||||
Connect to the Raspberry Pi over ssh. Default user name is `pi` and password is `raspberry`.
|
||||
Linux and Mac OS users execute the following command in a terminal.
|
||||
```bash
|
||||
$ ssh pi@ip-address-of-pi
|
||||
```
|
||||
Windows users start [Putty][ssh-putty], enter the IP address of the Raspberry Pi in the *Host name* field and port 22 in the *Port* field. Then click *Open* and a terminal window will open. Enter the credentials. Default user name is `pi` and password is `raspberry`.
|
||||
|
||||
Add instructions:
|
||||
#### {% linkable_title Start/Stop/Restart Home Assistant on HaSSbian %}
|
||||
Log in as the `pi` account account and execute the following commands:
|
||||
```bash
|
||||
sudo systemctl stop home-assistant@homeassistant.service
|
||||
```
|
||||
Replace `stop` with `start` or `restart` to get the desired functionality.
|
||||
To get the current state of the `homeassistant.service` replace `stop` with `status`.
|
||||
|
||||
- How to login via shell (?) or at least mention how to work with a Pi
|
||||
- How to restart HASS
|
||||
- How to see the logs for config validation
|
||||
- How to update the config
|
||||
#### {% linkable_title Update Home Assistant on HASSbian %}
|
||||
Log in as the `pi` account and execute the following commands:
|
||||
```bash
|
||||
sudo systemctl stop home-assistant@homeassistant.service
|
||||
sudo su -s /bin/bash homeassistant
|
||||
source /srv/homeassistant/bin/activate
|
||||
pip3 install --upgrade homeassistant
|
||||
exit
|
||||
sudo systemctl start home-assistant@homeassistant.service
|
||||
```
|
||||
This will in order do the following:
|
||||
- Stop the Home Assistant service running on HASSbian
|
||||
- Open a shell as the `homeassistant` user running the Homeassistant service and that has ownership over the Home Assistant installation.
|
||||
- Change into the virtual Python environment at `/src/homeassistant/` containing the Home Assistant installation.
|
||||
- Upgrade the Home Assistant installation to the latest release.
|
||||
- Exit the shell and return to the `pi` user.
|
||||
- Restart the Home Assistant service.
|
||||
|
||||
{% endcomment %}
|
||||
#### {% linkable_title Manually launch Home Assistant on HASSbian %}
|
||||
Log in as the `pi` account and execute the following commands:
|
||||
```bash
|
||||
sudo su -s /bin/bash homeassistant
|
||||
source /srv/homeassistant/bin/activate
|
||||
hass
|
||||
```
|
||||
This will start Home Assistant in your shell and output anything that ends up in the log and more into the console. This will fail if the Home Assistant service is already running so don't forget to [stop][stop-homeassistant] it first.
|
||||
|
||||
#### {% linkable_title Check your configuration on HASSbian %}
|
||||
Log in as the `pi` account and execute the following commands:
|
||||
```bash
|
||||
sudo su -s /bin/bash homeassistant
|
||||
source /srv/homeassistant/bin/activate
|
||||
hass --script check_config
|
||||
```
|
||||
This will output any errors in your configuration files to console.
|
||||
|
||||
#### {% linkable_title Read the Home Assistant log file on HASSbian %}
|
||||
Log in as the `pi` account and execute the following commands:
|
||||
```bash
|
||||
sudo su -s /bin/bash homeassistant
|
||||
cd /home/homeassistant/.homeassistant
|
||||
nano homeassistant.log
|
||||
```
|
||||
This will in order do the following:
|
||||
- Open a shell as the `homeassistant` user.
|
||||
- Change directory to the Home Assistant configuration directory.
|
||||
- Open the log file in the nano editor.
|
||||
|
||||
Optionaly, you can also view the log with `journalctl`.
|
||||
Log in as the `pi` account and execute the following commands:
|
||||
```bash
|
||||
sudo journalctl -fu home-assistant@homeassistant.service
|
||||
```
|
||||
|
||||
#### {% linkable_title Edit the Home Assistant configuration on HASSbian %}
|
||||
Log in as the `pi` account and execute the following commands:
|
||||
```bash
|
||||
sudo su -s /bin/bash homeassistant
|
||||
cd /home/homeassistant/.homeassistant
|
||||
nano configuration.yaml
|
||||
```
|
||||
This will in order do the following:
|
||||
- Open a shell as the `homeassistant` user.
|
||||
- Change directory to the Home Assistant configuration directory.
|
||||
- Open the configuration file in the nano editor.
|
||||
It's generally recommended that you read the [Getting started][configuring-homeassistant] guide for how to configure Home Assistant.
|
||||
|
||||
#### {% linkable_title Upgrade and update HASSbian %}
|
||||
HASSbian is based on Raspbian and uses the same repositories. Any changes to Raspbian will be reflected in HASSbian. To update and upgrade system packages and installed software (excluding Home Assistant) do the following.
|
||||
Log in as the `pi` account and execute the following commands:
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get upgrade
|
||||
```
|
||||
Press `Y` to confirm that you would like to continue.
|
||||
|
||||
### {% linkable_title Troubleshooting %}
|
||||
|
||||
@ -69,3 +152,6 @@ In addition to this site, check out these sources for additional help:
|
||||
[flash-macos]: https://www.raspberrypi.org/documentation/installation/installing-images/mac.md
|
||||
[flash-windows]: https://www.raspberrypi.org/documentation/installation/installing-images/windows.md
|
||||
[pi-components]: /getting-started/installation-raspberry-pi/#raspberry-pi-hardware-specific-components
|
||||
[ssh-putty]: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
|
||||
[stop-homeassistant]: /getting-started/installation-raspberry-pi-image/#startstoprestart-home-assistant-on-hassbian
|
||||
[configuring-homeassistant]: /getting-started/configuration/
|
||||
|
||||
@ -44,7 +44,7 @@ Home Assistant will know the location of your device if you are using OwnTracks.
|
||||
### [Next step: Setting up automation »](/getting-started/automation/)
|
||||
|
||||
[routers]: /components/#presence-detection
|
||||
[nmap]: /components/device_tracker.nmap_scanner/
|
||||
[nmap]: /components/device_tracker.nmap_tracker/
|
||||
[ha-owntracks]: /components/device_tracker.owntracks/
|
||||
[ha-locative]: /components/device_tracker.locative/
|
||||
[mqtt-self]: /components/mqtt/#run-your-own
|
||||
|
||||
28
source/getting-started/securing.markdown
Normal file
28
source/getting-started/securing.markdown
Normal file
@ -0,0 +1,28 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Securing"
|
||||
description: "Instructions how to secure your Home Assistant installation."
|
||||
date: 2016-10-06 06:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
One of the reasons to use Home Assistant is that it's not depending on cloud services. Even if you are only using Home Assistant in your local network, you should consider securing your instance.
|
||||
|
||||
### {% linkable_title Checklist %}
|
||||
|
||||
- [Protect your web interface with a password](https://home-assistant.io/getting-started/basic/#password-protecting-the-web-interface)
|
||||
- Secure your host. Sources could be [Red Hat Enterprise Linux 7 Security Guide](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf), [CIS Red Hat Enterprise Linux 7 Benchmark](https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v1.0.0.pdf), or the [Securing Debian Manual](https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html).
|
||||
- Restrict network access to your device. Set `PermitRootLogin no` in your sshd config (usually `/etc/ssh/sshd_config`) and to use keys for authentication instead of passwords.
|
||||
- Don't run Home Assistant as root.
|
||||
- Keep your [secrets](/topics/secrets/) safe.
|
||||
|
||||
Additional points if you want to allow remote access:
|
||||
|
||||
- Protect your communication with [TLS](blog/2015/12/13/setup-encryption-using-lets-encrypt/)
|
||||
- Protect your communication with [Tor](/cookbook/tor_configuration/)
|
||||
- Use a [proxy](/cookbook/apache_configuration/)
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ The default way to update Home Assistant to the latest release, when available,
|
||||
$ pip3 install --upgrade homeassistant
|
||||
```
|
||||
|
||||
Different installation methods as [Raspberry Pi All-In-One Installer](/getting-started/installation-raspberry-pi-all-in-one/#upgrading), [Vagrant](/getting-started/installation-vagrant/), or [Virtualenv](/getting-started/installation-virtualenv/#upgrading-home-assistant) may have an alternative way for updating Home Assistant.
|
||||
Different installation methods as [HASSbian](/getting-started/installation-raspberry-pi-image/#update-home-assistant-on-hassbian), [Raspberry Pi All-In-One Installer](/getting-started/installation-raspberry-pi-all-in-one/#upgrading), [Vagrant](/getting-started/installation-vagrant/), or [Virtualenv](/getting-started/installation-virtualenv/#upgrading-home-assistant) may have an alternative way for updating Home Assistant.
|
||||
|
||||
After updating, restart Home Assistant for the changes to take effect. This means that you have to restart `hass` itself or the [autostarting](/getting-started/autostart/) daemon if you use any.
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ footer: true
|
||||
|
||||
##### {% linkable_title Motion or alarm sensors %}
|
||||
|
||||
In order for Home Assistant to recognize some sensors, you will need to change its configuration from `Basic Set (default)` to `Binary Sensor report` or `Alarm report`.
|
||||
In order for Home Assistant to recognize the sensor properly, you will need to change its configuration from `Basic Set (default)` to `Binary Sensor report` or `Alarm report`.
|
||||
These devices will either show as a binary sensor or a sensor called `Alarm xxxx` and will report a numeric value. Test to see what value is what. Sometimes this is noted in the device manual.
|
||||
|
||||
As of version 0.30 you can set the settings of a Z-Wave device through the dev_service page of Home Assistant with the service: `zwave/set_config_parameter`.
|
||||
@ -35,7 +35,7 @@ Example entry in dev-service, setting binary reports for an Aeotec Multisensor 6
|
||||
|
||||
These devices require a network key to be set for the Z-Wave network before they are paired. This key is set in OpenZWave's `options.xml` which is located in OpenZWave's directory. This should also be the same directory as `config_path:` in your `configuration.yaml`. If it's not, make sure you have the same values in all the files you are using.
|
||||
The option is commented out by default in `options.xml` and is a default key. Make your own unique key. The key is in Hexadecimals.
|
||||
It is best to pair these devices in OpenZWave Control Panel or another Z-Wave tool that can show you logs while pairing. Home Assistant stores logs from Z-Wave in `OZW.log` in the Home Assistant config directory.
|
||||
It is best to pair these devices in OpenZWave Control Panel or another Z-Wave tool that can show you logs while pairing. Home Assistant stores logs from Z-Wave in `OZW.log` in the Home Assistant config directory.
|
||||
You should see communication from the node with lines starting with `info: NONCES` in `OZW.log` when the device is paired successfully with a secure connection. If you use OpenZWave Control Panel to pair, test the device before you save the configuration.
|
||||
Make sure you copy the newly saved `zwcfg_[home_id].xml`into your Home Assistant configuration directory.
|
||||
|
||||
|
||||
@ -9,13 +9,13 @@ sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
You may wish to modify the Z-Wave settings in your `ozw*.xml` file stored in the `.homeassistant` configuration directory, or certain situations/devices may require it (i.e. Aeon Multisensor 6). To do this, utilize [Open-Zwave Control Panel](https://github.com/OpenZWave/open-zwave-control-panel). Alternatively, use [Domoticz](https://www.domoticz.com/), which incorporates the Open-Zwave Control Panel project into an easy to use Raspberry Pi image.
|
||||
You may wish to modify the Z-Wave settings in your `ozw*.xml` file (stored in the `.homeassistant` configuration directory), or certain situations/devices may require it (i.e. Aeon Multisensor 6). To do this, utilize [Open-Zwave Control Panel](https://github.com/OpenZWave/open-zwave-control-panel). Alternatively, use [Domoticz](https://www.domoticz.com/), which incorporates the Open-Zwave Control Panel project into an easy to use Raspberry Pi image.
|
||||
|
||||
The reasoning for using these tools is that your Z-Wave controller stores the values and data that are used to control the network. The XML file in the `.homeassistant` configuration directory acts as a settings/values cache for the Z-Wave network, so modifying it directly won't change the network values. The [Open-Zwave Control Panel](https://github.com/OpenZWave/open-zwave-control-panel) writes values directly to the network and will provide you with an updated `.xml` file to overwrite in your `.homeassistant` configuration directory. This is the most foolproof way to make modifications to your Z-Wave devices.
|
||||
|
||||
Although totally normal for your Z-Wave stick (Aeon Aeotec Z-Stick Gen5 for example) to cycle through its LEDs (Yellow, Blue and Red) while plugged into your system. If you don like this behaviour then you could turn it off.
|
||||
It's totally normal for your Z-Wave stick (Aeon Aeotec Z-Stick Gen5 for example) to cycle through its LEDs (Yellow, Blue and Red) while plugged into your system. If you don't like this behaviour it can be turned off.
|
||||
|
||||
Use the following commands from a terminal session on your Pi where your Z-Wave stick is connected as an example.
|
||||
Use the following example commands from a terminal session on your Pi where your Z-Wave stick is connected.
|
||||
|
||||
Turn off "Disco lights":
|
||||
|
||||
|
||||
@ -131,7 +131,7 @@ cat /dev/urandom | tr -dc '0-9A-F' | fold -w 32 | head -n 1 | sed -e 's/\(..\)/0
|
||||
|
||||
#### {% linkable_title zwave.network_complete %}
|
||||
|
||||
Home Assistant will trigger a event when the Z-Wave network is complete. Meaning all of the nodes on the network have been queried. This can take quite som time, depending on wakeup intervals on the battery powered devices on the network.
|
||||
Home Assistant will trigger a event when the Z-Wave network is complete. Meaning all of the nodes on the network have been queried. This can take quite some time, depending on wakeup intervals on the battery powered devices on the network.
|
||||
|
||||
```yaml
|
||||
- alias: Z-Wave network is complete
|
||||
@ -220,7 +220,7 @@ The `zwave` component exposes ten services to help maintain the network.
|
||||
| add_node_secure | Put the Z-Wave controller in secure inclusion mode. Allows one to add a new device with secure communications to the Z-Wave network. |
|
||||
| association | Add or remove an association in th Z-Wave network
|
||||
| cancel_command | Cancels a running Z-Wave command. If you have started a add_node or remove_node command, and decides you are not going to do it, then this must be used to stop the inclusion/exclusion command. |
|
||||
| heal_network | Tells the controller to "heal" the Z-Wave network. Bascially asks the nodes to tell the controller all of their neighbors so the controller can refigure out optimal routing. |
|
||||
| heal_network | Tells the controller to "heal" the Z-Wave network. Basically asks the nodes to tell the controller all of their neighbors so the controller can refigure out optimal routing. |
|
||||
| remove_node | Put the Z-Wave controller in exclusion mode. Allows one to remove a device from the Z-Wave network.|
|
||||
| set_config_parameter | Let's the user set a config parameter to a node.
|
||||
| soft_reset | Tells the controller to do a "soft reset". This is not supposed to lose any data, but different controllers can behave differently to a "soft reset" command.|
|
||||
|
||||
@ -3,7 +3,7 @@ layout: page
|
||||
title: "Talking points"
|
||||
description: "Talking points for your Home Assistant talk or presentation."
|
||||
date: 2016-10-06 06:00
|
||||
sidebar: true
|
||||
sidebar: false
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 76 KiB After Width: | Height: | Size: 3.3 KiB |
BIN
source/images/supported_brands/swiss-hydrological-data.png
Normal file
BIN
source/images/supported_brands/swiss-hydrological-data.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.0 KiB |
@ -15,8 +15,8 @@ hide_github_edit: true
|
||||
<div class="grid">
|
||||
<div class="grid__item one-third lap-one-third palm-one-whole">
|
||||
<div class='current-version material-card text'>
|
||||
<h1>Current Version: 0.30</h1>
|
||||
Released: <span class='release-date'>October 8, 2016</span>
|
||||
<h1>Current Version: 0.30.2</h1>
|
||||
Released: <span class='release-date'>October 12, 2016</span>
|
||||
|
||||
<div class='links'>
|
||||
<a href='/blog/2016/10/08/hassbian-rest-digital-ocean/'>Release notes</a>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user