mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-07-24 09:46:59 +00:00
Merge remote-tracking branch 'origin/current' into next
This commit is contained in:
Paulus Schoutsen
commit
fd6f73a713
11
_config.yml
11
_config.yml
@ -140,11 +140,16 @@ social:
|
||||
# Home Assistant release details
|
||||
current_major_version: 0
|
||||
current_minor_version: 62
|
||||
current_patch_version: 0
|
||||
date_released: 2018-01-27
|
||||
current_patch_version: 1
|
||||
date_released: 2018-01-30
|
||||
|
||||
# Either # or the anchor link to latest release notes in the blog post.
|
||||
# Must be prefixed with a # and have double quotes around it.
|
||||
# Major release:
|
||||
patch_version_notes: "#"
|
||||
patch_version_notes: "#release-0621---january-30"
|
||||
# Minor release (Example #release-0431---april-25):
|
||||
|
||||
# Date we moved to Discourse for comments
|
||||
# disqus_end_date: 2018-01-26 0:00:00
|
||||
# Disqus is adding gross ads, move all comments to discourse.
|
||||
disqus_end_date: 2010-01-26 0:00:00
|
||||
|
||||
@ -49,6 +49,7 @@ Screenshot of the HASS Configurator.
|
||||
"banlimit": 0,
|
||||
"ignore_pattern": ["__pycache__"],
|
||||
"dirsfirst": false,
|
||||
"sesame": "somesecretnobodycanguess"
|
||||
}
|
||||
```
|
||||
|
||||
@ -60,6 +61,7 @@ Screenshot of the HASS Configurator.
|
||||
- **banlimit** (*Optional*): Ban access from IPs after `banlimit` failed login attempts. The default value `0` disables this feature. Restart the add-on to clear the list of banned IP addresses.
|
||||
- **ignore_pattern** (*Optional*): Files and folders to ignore in the UI.
|
||||
- **dirsfirst** (*Optional*): List directories before files in the file browser.
|
||||
- **sesame** (*Optional*): Secret token to dynamically allow access from the IP the request originates from. Open your bookmark https://hassio.yourdomain.com:8123/somesecretnobodycanguess while `allowed_networks` is set to `[]` and boom! Open Sesame! You can use the _Network status_ menu to revoke IP addresses for which access has been granted.
|
||||
|
||||
### {% linkable_title Embedding into Home-Assistant %}
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ sharing: true
|
||||
footer: true
|
||||
logo: home-assistant.png
|
||||
ha_category: Alarm
|
||||
ha_release: 0.50
|
||||
ha_release: "0.50"
|
||||
---
|
||||
|
||||
This platform extends the [manual alarm](/components/alarm_control_panel.manual/) by adding support for MQTT control of the alarm by a remote device. It can be used to create external keypads which simply change the state of the manual alarm in Home Assistant.
|
||||
|
||||
@ -20,7 +20,7 @@ Please visit the [AlarmDecoder website](https://www.alarmdecoder.com/) for furth
|
||||
There is currently support for the following device types within Home Assistant:
|
||||
|
||||
- [Binary Sensor](/components/binary_sensor.alarmdecoder/): Reports on zone status
|
||||
- [Sensor](/components/sensor.alarmdecoder/): Emulates an keypad display
|
||||
- [Sensor](/components/sensor.alarmdecoder/): Emulates a keypad display
|
||||
- [Alarm Control Panel](/components/alarm_control_panel.alarmdecoder/): Reports on alarm status, and can be used to arm/disarm the system
|
||||
|
||||
This is a fully event-based component. Any event sent by the AlarmDecoder device will be immediately reflected within Home Assistant.
|
||||
|
||||
@ -14,7 +14,7 @@ ha_release: 0.9
|
||||
---
|
||||
|
||||
|
||||
The `arest` binary sensor platform allows you to get all data from your devices (like Arduinos with a ethernet/wifi connection, the ESP8266, and the Raspberry Pi) running the [aREST](http://arest.io/) RESTful framework.
|
||||
The `arest` binary sensor platform allows you to get all data from your devices (like Arduinos with an ethernet/wifi connection, the ESP8266, and the Raspberry Pi) running the [aREST](http://arest.io/) RESTful framework.
|
||||
|
||||
To use your aREST binary sensor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: gc100 Binary Sensor
|
||||
description: "Instructions on how to set up an gc100 binary sensor within Home Assistant."
|
||||
description: "Instructions on how to set up a gc100 binary sensor within Home Assistant."
|
||||
date: 2017-10-27 17:26
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
||||
@ -13,12 +13,11 @@ ha_release: 0.9
|
||||
ha_iot_class: "depends"
|
||||
---
|
||||
|
||||
|
||||
The `mqtt` binary sensor platform uses an MQTT message payload to set the binary sensor to one of two states: `on` or `off`.
|
||||
|
||||
The binary sensor state will be updated only after a new message is published on `state_topic` matching `payload_on` or `payload_off`. If these messages are published with the `retain` flag set, the binary sensor will receive an instant state update after subscription and Home Assistant will display the correct state on startup. Otherwise, the initial state displayed in Home Assistant will be `unknown`.
|
||||
|
||||
The `mqtt` binary sensor platform optionally supports an `availability_topic` to receive online and offline messages (birth and LWT messages) from the MQTT device. During normal operation, if the MQTT cover device goes offline (i.e. publishes `payload_not_available` to `availability_topic`), Home Assistant will display the binary sensor as `unavailable`. If these messages are published with the `retain` flag set, the binary sensor will receive an instant update after subscription and Home Assistant will display the correct availability state of the binary sensor when Home Assistant starts up. If the `retain` flag is not set, Home Assistant will display the binary sensor as `unavailable` when Home Assistant starts up. If no `availability_topic` is defined, Home Assistant will consider the MQTT device to be available.
|
||||
The `mqtt` binary sensor platform optionally supports an `availability_topic` to receive online and offline messages (birth and LWT messages) from the MQTT device. During normal operation, if the MQTT cover device goes offline (i.e., publishes `payload_not_available` to `availability_topic`), Home Assistant will display the binary sensor as `unavailable`. If these messages are published with the `retain` flag set, the binary sensor will receive an instant update after subscription and Home Assistant will display the correct availability state of the binary sensor when Home Assistant starts up. If the `retain` flag is not set, Home Assistant will display the binary sensor as `unavailable` when Home Assistant starts up. If no `availability_topic` is defined, Home Assistant will consider the MQTT device to be available.
|
||||
|
||||
To use an MQTT binary sensor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
@ -83,6 +82,13 @@ force_update:
|
||||
default: False
|
||||
{% endconfiguration %}
|
||||
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
In this section, you will find some real-life examples of how to use this sensor.
|
||||
|
||||
### {% linkable_title Full configuration %}
|
||||
|
||||
To test, you can use the command line tool `mosquitto_pub` shipped with `mosquitto` or the `mosquitto-clients` package to send MQTT messages. To set the state of the binary sensor manually:
|
||||
|
||||
```bash
|
||||
@ -91,6 +97,7 @@ $ mosquitto_pub -h 127.0.0.1 -t home-assistant/window/contact -m "OFF"
|
||||
|
||||
The example below shows a full configuration for a binary sensor:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
binary_sensor:
|
||||
@ -104,5 +111,32 @@ binary_sensor:
|
||||
payload_not_available: "offline"
|
||||
qos: 0
|
||||
device_class: opening
|
||||
value_template: '{% raw %}{{ value.x }}{% endraw %}'
|
||||
value_template: '{{ value.x }}'
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### {% linkable_title Get the state of a device with ESPEasy %}
|
||||
|
||||
Assuming that you have flashed your ESP8266 unit with [ESPEasy](https://github.com/letscontrolit/ESPEasy). Under "Config" is a name ("Unit Name:") set for your device (here it's "bathroom"). A configuration for a "Controller" for MQTT with the protocol "OpenHAB MQTT" is present and the entries ("Controller Subscribe:" and "Controller Publish:") are adjusted to match your needs. In this example, the topics are prefixed with "home". Also, add a "Switch Input" in the "Devices" tap with the name "switch" and "button" as value.
|
||||
|
||||
As soon as the unit is online, you will get the state of the attached button.
|
||||
|
||||
```bash
|
||||
home/bathroom/status Connected
|
||||
...
|
||||
home/bathroom/switch/button 1
|
||||
```
|
||||
|
||||
The configuration will look like the example below:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Example configuration.yml entry
|
||||
binary_sensor:
|
||||
- platform: mqtt
|
||||
name: Bathroom
|
||||
state_topic: "home/bathroom/switch/button"
|
||||
payload_on: "1"
|
||||
payload_off: "0"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Raspihats Binary Sensor"
|
||||
description: "Instructions how to integrate Raspihats add-on boards for Raspberry PI into Home Assistant as a binary_sensor."
|
||||
description: "Instructions how to integrate Raspihats add-on boards for Raspberry Pi into Home Assistant as a binary_sensor."
|
||||
date: 2017-05-01 04:09
|
||||
sidebar: true
|
||||
comments: false
|
||||
@ -87,4 +87,4 @@ It will output a table like this:
|
||||
70: -- -- -- -- -- -- -- 77
|
||||
```
|
||||
|
||||
For more details about the `raspihats` add-on boards for Raspberry PI, visit [raspihats.com](http://www.raspihats.com/).
|
||||
For more details about the `raspihats` add-on boards for Raspberry Pi, visit [raspihats.com](http://www.raspihats.com/).
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Raspberry PI GPIO Binary Sensor"
|
||||
description: "Instructions how to integrate the GPIO sensor capability of a Raspberry PI into Home Assistant."
|
||||
title: "Raspberry Pi GPIO Binary Sensor"
|
||||
description: "Instructions how to integrate the GPIO sensor capability of a Raspberry Pi into Home Assistant."
|
||||
date: 2015-08-30 19:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
||||
@ -9,7 +9,7 @@ sharing: true
|
||||
footer: true
|
||||
ha_category: Camera
|
||||
logo: camcorder.png
|
||||
ha_release: 0.40
|
||||
ha_release: "0.40"
|
||||
ha_iot_class: "depends"
|
||||
---
|
||||
|
||||
|
||||
@ -60,7 +60,7 @@ camera:
|
||||
|
||||
### {% linkable_title Local image with Hass.io %}
|
||||
|
||||
You can show an static image with this platform. Just place the image here: `/config/www/your_image.png`
|
||||
You can show a static image with this platform. Just place the image here: `/config/www/your_image.png`
|
||||
|
||||
```yaml
|
||||
camera:
|
||||
@ -68,3 +68,14 @@ camera:
|
||||
name: Some Image
|
||||
still_image_url: https://127.0.0.1:8123/local/your_image.png
|
||||
```
|
||||
|
||||
### {% linkable_title Sharing a camera feed from one Home Assistant instance to another %}
|
||||
|
||||
If you are running more than one Home Assistant instance (let's call them the 'host' and 'receiver' instances) you may wish to display the camera feed from the host instance on the receiver instance. You can use the [REST API](/developers/rest_api/#get-apicamera_proxycameraltentity_id) to access the camera feed on the host (IP address 127.0.0.5) and display it on the receiver instance by configuring the receiver with the the following:
|
||||
|
||||
```yaml
|
||||
camera:
|
||||
- platform: generic
|
||||
name: Host instance camera feed
|
||||
still_image_url: https://127.0.0.5:8123/api/camera_proxy/camera.live_view
|
||||
```
|
||||
|
||||
@ -40,7 +40,7 @@ Take a snapshot from a camera.
|
||||
|
||||
| Service data attribute | Optional | Description |
|
||||
| ---------------------- | -------- | ----------- |
|
||||
| `entity_id` | no | Name(s) of entities to create a snopshot from, e.g., `camera.living_room_camera`. |
|
||||
| `entity_id` | no | Name(s) of entities to create a snapshot from, e.g., `camera.living_room_camera`. |
|
||||
| `filename ` | no | Template of a file name. Variable is `entity_id`, e.g., {% raw %}`/tmp/snapshot_{{ entity_id }}`{% endraw %}. |
|
||||
|
||||
The path part of `filename` must be an entry in the `whitelist_external_dirs` in your [`homeassistant:`](/docs/configuration/basic/) section of your `configuration.yaml` file.
|
||||
|
||||
@ -201,7 +201,7 @@ climate:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
This will parse the incoming `"auto"` as JSON, resulting in `auto`. Obvisouly, in this case you could also just set `value_template: {% raw %}"{{ value_json }}"{% endraw %}`.
|
||||
This will parse the incoming `"auto"` as JSON, resulting in `auto`. Obviously, in this case you could also just set `value_template: {% raw %}"{{ value_json }}"{% endraw %}`.
|
||||
|
||||
|
||||
### {% linkable_title Example %}
|
||||
|
||||
@ -15,7 +15,7 @@ ha_iot_class: "Local Polling"
|
||||
|
||||
This platform supports the ESP82666 based "WiFi MQTT Relay / Thermostat" sold by [OpenEnergyMonitor](https://shop.openenergymonitor.com/wifi-mqtt-relay-thermostat/). The underlying [library](http://oemthermostat.readthedocs.io/) only supports this single relay variant of the [original device](https://harizanov.com/2014/12/wifi-iot-3-channel-relay-board-with-mqtt-and-http-api-using-esp8266/).
|
||||
|
||||
This platform controls the setpoint of the thermostat in it's "manual" mode, therefore there is a configuration option the away setpoint.
|
||||
This platform controls the setpoint of the thermostat in its "manual" mode, therefore there is a configuration option the away setpoint.
|
||||
|
||||
To set it up, add the following information to your `configuration.yaml` file:
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: home-assistant.png
|
||||
ha_release: 0.60
|
||||
ha_release: "0.60"
|
||||
ha_category: Cloud
|
||||
ha_iot_class: "Cloud Push"
|
||||
---
|
||||
|
||||
@ -8,7 +8,7 @@ comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: home-assistant.png
|
||||
ha_release: 0.60
|
||||
ha_release: "0.60"
|
||||
ha_category: Voice
|
||||
ha_iot_class: "Cloud Push"
|
||||
---
|
||||
|
||||
@ -28,7 +28,6 @@ coinbase:
|
||||
- BTC
|
||||
- ETH
|
||||
- LTC
|
||||
=======
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
|
||||
@ -134,7 +134,7 @@ tilt_max:
|
||||
type: integer
|
||||
default: 100
|
||||
tilt_closed_value:
|
||||
description: The value that will be sent on an `close_cover_tilt` command.
|
||||
description: The value that will be sent on a `close_cover_tilt` command.
|
||||
required: false
|
||||
type: integer
|
||||
default: 0
|
||||
|
||||
@ -85,7 +85,7 @@ Device configuration variables:
|
||||
|
||||
- **name** (*Optional*): Name for the device, defaults to Rflink ID.
|
||||
- **aliases** (*Optional*): Alternative Rflink ID's this device is known by.
|
||||
- **fire_event** (*Optional*): Fire an `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **fire_event** (*Optional*): Fire a `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **signal_repetitions** (*Optional*): Repeat every Rflink command this number of times (default: 1).
|
||||
- **fire_event_** (*Optional*): Set default `fire_event` for RFLink switch devices (see below).
|
||||
- **signal_repetitions** (*Optional*): Set default `signal_repetitions` for RFLink switch devices (see below).
|
||||
|
||||
@ -50,5 +50,5 @@ To disable the drainage of the battery, a dynamic interval is being used for eac
|
||||
4 services are available for this component:
|
||||
- **icloud_update**: This service can be used to ask for an update of a certain iDevice. The `account_name` and `device_name` are optional.
|
||||
- **icloud_lost_iphone**: This service will play the Lost iPhone sound on a certain iDevice. The `account_name` and `device_name` are optional.
|
||||
- **icloud_set_interval**: This service will change the dynamic interval of an iDevice. The `account_name` and `device_name` are optional. If `interval` is used in the service_data, the iDevice will be updated with that new interval. That interval will be fixed until the iDevice changes zone or if this service is called again. If `interval` isn't used in the service_data, the interval for that iDevice will revert back to it's default dynamic interval based on it's current zone, it's distance towards home and it's battery level.
|
||||
- **icloud_set_interval**: This service will change the dynamic interval of an iDevice. The `account_name` and `device_name` are optional. If `interval` is used in the service_data, the iDevice will be updated with that new interval. That interval will be fixed until the iDevice changes zone or if this service is called again. If `interval` isn't used in the service_data, the interval for that iDevice will revert back to its default dynamic interval based on its current zone, its distance towards home and its battery level.
|
||||
- **icloud_reset_account**: This service can be used to reset an iCloud account. This is helpful when not all devices are being found by the component or if you have added a new iDevice to your account. The `account_name` is optional.
|
||||
|
||||
@ -96,7 +96,7 @@ iBeacons don't need to be stationary. You could put one on your key ring, or in
|
||||
|
||||
When your phone sees a mobile iBeacon that it knows about, it will tell HA the location of that iBeacon. If your phone moves while you are connected to the iBeacon, HA will update the location of the iBeacon. But when your phone loses the connection, HA will stop updating the iBeacon location.
|
||||
|
||||
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`).
|
||||
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 an 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*.
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ ha_category: Presence Detection
|
||||
ha_release: 0.37
|
||||
---
|
||||
|
||||
The `tado` device tracker is using the [Tado Smart Thermostat](https://www.tado.com/) and it's support for person presence detection based on smartphone location by geofencing.
|
||||
The `tado` device tracker is using the [Tado Smart Thermostat](https://www.tado.com/) and its support for person presence detection based on smartphone location by geofencing.
|
||||
|
||||
This tracker uses the Tado API to determine if a mobile device is at home. It tracks all devices in your home that Tado knows about.
|
||||
|
||||
|
||||
@ -64,19 +64,18 @@ See the [device tracker component page](/components/device_tracker/) for instruc
|
||||
|
||||
### {% linkable_title Configuring Users %}
|
||||
|
||||
The Unifi controller allows you to create multiple users on it besides
|
||||
the main administrator. It is recommended that you create a limited
|
||||
user that has `read-only` permissions for the Unifi device tracker.
|
||||
The Unifi controller allows you to create multiple users on it besides the main administrator. It is recommended that you create a limited user that has `read-only` permissions for the Unifi device tracker.
|
||||
|
||||
### {% linkable_title Conflicts with MQTT %}
|
||||
|
||||
The Unifi controller can either be a dedicated hardware device
|
||||
(Unifi's cloud key), or as software any Linux system. If you run the
|
||||
the Unifi controller on the same operating system as Home Assistant
|
||||
there may be conflicts in ports if you have the MQTT component as
|
||||
well.
|
||||
The Unifi controller can either be a dedicated hardware device (Unifi's cloud key), or as software any Linux system. If you run the the Unifi controller on the same operating system as Home Assistant there may be conflicts in ports if you have the MQTT component as well.
|
||||
|
||||
It is recommended that you run the Unifi controller in a dedicate
|
||||
virtual machine to avoid that situation.
|
||||
It is recommended that you run the Unifi controller in a dedicate virtual machine to avoid that situation.
|
||||
|
||||
### {% linkable_title Troubleshooting and Time Synchronization %}
|
||||
|
||||
Presence detection depends on accurate time configuration between Home Assistant and the Unifi controller.
|
||||
|
||||
If Home Assistant and the Unifi controller are running on separate machines or VMs ensure that all clocks are syncronized. Failing to have syncronized clocks will lead to Home Assistant failing to mark a device as home.
|
||||
|
||||
[Related Issue](https://github.com/home-assistant/home-assistant/issues/10507)
|
||||
|
||||
@ -13,7 +13,7 @@ ha_release: 0.23
|
||||
ha_iot_class: "Local Push"
|
||||
---
|
||||
|
||||
The `envisalink` component will allow Home Assistant users who own either a DSC or Honeywell alarm panel to leverage their alarm system and it's sensors to provide Home Assistant with rich information about their homes. Connectivity between Home Assistant and the alarm panel is accomplished through a device produced by Eyez On, known as the Envisalink. The Envisalink evl3 and evl4 boards provide a TCP/IP interface to the alarm panel, where it emulates an alarm keypad. This board also exposes a raw TCP/IP based API, upon which this component is built. Currently, the Envisalink version 4 is the latest model. This component supports both the evl3 and the evl4.
|
||||
The `envisalink` component will allow Home Assistant users who own either a DSC or Honeywell alarm panel to leverage their alarm system and its sensors to provide Home Assistant with rich information about their homes. Connectivity between Home Assistant and the alarm panel is accomplished through a device produced by Eyez On, known as the Envisalink. The Envisalink evl3 and evl4 boards provide a TCP/IP interface to the alarm panel, where it emulates an alarm keypad. This board also exposes a raw TCP/IP based API, upon which this component is built. Currently, the Envisalink version 4 is the latest model. This component supports both the evl3 and the evl4.
|
||||
|
||||
Please visit the [eyezon website](http://www.eyezon.com/) for further information about the evl3 and evl4 boards.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ sharing: true
|
||||
footer: true
|
||||
logo: insteon.png
|
||||
ha_category: Fan
|
||||
ha_release: 0.30
|
||||
ha_release: "0.30"
|
||||
---
|
||||
|
||||
The `insteon_hub` fan component lets you control your fans connected to an [Insteon Hub](http://www.insteon.com/insteon-hub/) with Home Assistant.
|
||||
|
||||
@ -107,6 +107,19 @@ entity_config:
|
||||
type: string
|
||||
{% endconfiguration %}
|
||||
|
||||
### {% linkable_title Available domains %}
|
||||
Currently, the following domains are available to be used with Google Assistant, listed with their default types:
|
||||
|
||||
- group = switch (on/off)
|
||||
- scene = scene (on)
|
||||
- script = scene (on)
|
||||
- switch = switch (on/off)
|
||||
- fan = switch (on/off)
|
||||
- light = light (on/off/brightness/rgb color/color temp)
|
||||
- cover = switch (on/off/set position (brightness) )
|
||||
- media_player = switch (on/off/set volume (brightness) )
|
||||
- climate = thermostat (temperature setting)
|
||||
|
||||
It's very important that you use very long strings for `client_id` and `access_token`. Those are essentially the credentials to your Home Assistant instance. You can generate them with the following command:
|
||||
|
||||
```bash
|
||||
|
||||
@ -30,7 +30,7 @@ http:
|
||||
Configuration variables:
|
||||
|
||||
- **api_password** (*Optional*): Protect Home Assistant with a password.
|
||||
- **server_host** (*Optional*): Only listen to incoming requests on specific IP/host (default: accept all)
|
||||
- **server_host** (*Optional*): Only listen to incoming requests on specific IP/host (default: bind to `0.0.0.0` which means accept all IPv4 connections). Use `server_host: "::0"` if you want to listen to (and only) IPv6.
|
||||
- **server_port** (*Optional*): Let you set a port to use. Defaults to 8123.
|
||||
- **base_url** (*Optional*): The URL that Home Assistant is available on the internet. For example: `hass-example.duckdns.org:8123`. Defaults to the local IP address. The iOS app finds local installations, if you have an outside URL use this so that you can auto-fill when discovered in the app.
|
||||
- **ssl_certificate** (*Optional*): Path to your TLS/SSL certificate to serve Home Assistant over a secure connection.
|
||||
|
||||
@ -11,7 +11,7 @@ logo: philips_hue.png
|
||||
ha_category: Hub
|
||||
ha_iot_class: "Local Polling"
|
||||
featured: true
|
||||
ha_release: 0.60
|
||||
ha_release: "0.60"
|
||||
---
|
||||
|
||||
Philips Hue support is integrated into Home Assistant as a Hub that can drive the light platform. The preferred way to setup the Philips Hue platform is by enabling the [discovery component](/components/discovery/).
|
||||
@ -54,7 +54,7 @@ You will need to convert each bridge into an entry in the new configuration styl
|
||||
|
||||
### {% linkable_title Multiple Hue bridges %}
|
||||
|
||||
Multiple Hue bridges work transparently with discovery, you don't have to do anything. If you prefer to configure them manually and use multiple Hue bridges then it's needed that you provide a configuration file for every bridge. The bridges can't share a single configuration file.
|
||||
Multiple Hue bridges work transparently with discovery, you don't have to do anything. If you prefer to configure them manually and use multiple Hue bridges then it's needed that you provide a configuration file for every bridge. The bridges can't share a single configuration file.
|
||||
|
||||
Add `filename` to your Hue configuration entry in your `configuration.yaml` file:
|
||||
|
||||
@ -103,7 +103,7 @@ More information can be found on the [Philips Hue API documentation](https://www
|
||||
|
||||
### {% linkable_title Using Hue Scenes in Home Assistant %}
|
||||
|
||||
The Hue platform has it's own concept of scenes for setting the colors of a group of lights at once. Hue Scenes are very cheap, get created by all kinds of apps (as it is the only way to have 2 or more lights change at the same time), and are rarely deleted. A typical Hue hub might have hundreds of scenes stored in them, many that you've never used, almost all very poorly named.
|
||||
The Hue platform has its own concept of scenes for setting the colors of a group of lights at once. Hue Scenes are very cheap, get created by all kinds of apps (as it is the only way to have 2 or more lights change at the same time), and are rarely deleted. A typical Hue hub might have hundreds of scenes stored in them, many that you've never used, almost all very poorly named.
|
||||
|
||||
To avoid user interface overload we don't expose scenes directly. Instead there is a hue.hue_activate_scene service which can be used by `automation` or `script` components.
|
||||
This will have all the bulbs transitioned at once, instead of one at a time using standard scenes in Home Assistant.
|
||||
|
||||
@ -13,7 +13,7 @@ featured: false
|
||||
ha_release: 0.38
|
||||
---
|
||||
|
||||
The `microsoft_face_detect` image processing platform allows you to use the [Microsoft Face Identify](https://www.microsoft.com/cognitive-services/en-us/) API through Home Assistant. This platform enables you do detect face on camera and fire a event with attributes.
|
||||
The `microsoft_face_detect` image processing platform allows you to use the [Microsoft Face Identify](https://www.microsoft.com/cognitive-services/en-us/) API through Home Assistant. This platform enables you do detect face on camera and fire an event with attributes.
|
||||
|
||||
Please refer to the [component](/components/microsoft_face/) configuration on how to setup the API key.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ featured: false
|
||||
ha_release: 0.37
|
||||
---
|
||||
|
||||
The `microsoft_face_identify` image processing platform lets you use [Microsoft Face identify](https://www.microsoft.com/cognitive-services/en-us/) API through Home Assistant. This platform allow you do identify persons on camera and fire a event with identify persons.
|
||||
The `microsoft_face_identify` image processing platform lets you use [Microsoft Face identify](https://www.microsoft.com/cognitive-services/en-us/) API through Home Assistant. This platform allow you do identify persons on camera and fire an event with attributes.
|
||||
|
||||
Please refer to the [component](/components/microsoft_face/) configuration on how to setup the API key.
|
||||
|
||||
|
||||
@ -48,123 +48,13 @@ Configuration variables:
|
||||
- **tags** (*Optional*): Tags to mark the data.
|
||||
- **tags_attributes** (*Optional*): The list of attribute names which should be reported as tags and not fields to InfluxDB. For example, if set to `friendly_name`, it will be possible to group by entities' friendly names as well, in addition to their ids.
|
||||
|
||||
## {% linkable_title Data migration %}
|
||||
## {% linkable_title Helper scripts %}
|
||||
|
||||
Starting with 0.36 the InfluxDB component has a new schema to store values in the InfluxDB databases.
|
||||
|
||||
- There will no longer be any tags/fields named `time`.
|
||||
- All numeric fields (int/float/bool) will be stored as float inside InfluxDB database.
|
||||
- All string fields corresponding to state attributes will be renamed as `FIELDNAME_str`, where `FIELDNAME` is the state attribute, to avoid type conflicts.
|
||||
- All string fields corresponding to a state will be renamed as `state` (former value).
|
||||
- Fields named `value` will always be stored as float.
|
||||
- Fields named `state` will always be stored as string.
|
||||
|
||||
### {% linkable_title Migration script %}
|
||||
|
||||
If you need to migrate your database, you may require to run the `influxdb_migrator` script. Run the script after upgrade to 0.36 but before the first regular start of `hass` version 0.36.
|
||||
|
||||
These are the steps the script will perform:
|
||||
1. Create a new database (called `DBNAME__old`) to store old data.
|
||||
2. Copy data from `DBNAME` database to `DBNAME__old` database.
|
||||
3. Empty `DBNAME` database (using `drop` then `create`). `DBNAME` database is now considered as the new database.
|
||||
4. For each measurement of `DBNAME__old` database:
|
||||
1. Read all points from the current measurement (in groups of 1000 points by default) and convert them.
|
||||
2. Send group of points to `DBNAME` database.
|
||||
5. Delete the `DBNAME__old` database if needed.
|
||||
|
||||
Example to run the script:
|
||||
|
||||
```bash
|
||||
$ hass --script influxdb_migrator \
|
||||
-H IP_INFLUXDB_HOST -u INFLUXDB_USERNAME -p INFLUXDB_PASSWORD \
|
||||
-d INFLUXDB_DB_NAME
|
||||
```
|
||||
Script arguments:
|
||||
|
||||
```
|
||||
required arguments:
|
||||
-d dbname, --dbname dbname InfluxDB database name
|
||||
|
||||
optional arguments:
|
||||
-h, --help show this help message and exit
|
||||
-H host, --host host InfluxDB host address
|
||||
-P port, --port port InfluxDB host port
|
||||
-u username, --username username
|
||||
InfluxDB username
|
||||
-p password, --password password
|
||||
InfluxDB password
|
||||
-s step, --step step How many points to migrate at the same time
|
||||
-o override_measurement, --override-measurement override_measurement
|
||||
Store all your points in the same measurement
|
||||
-D, --delete Delete old database
|
||||
```
|
||||
|
||||
- If you run the script with only the `-h` option, you will get a help printout with a short explanation of the different options.
|
||||
- The host option defaults to `'127.0.0.1'`.
|
||||
- The port option defaults to `8086`.
|
||||
- You should be able to omit username and password if InfluxDB authentication is disabled, which it is by default.
|
||||
- The step option defaults to `1000`.
|
||||
|
||||
|
||||
## {% linkable_title Data import script %}
|
||||
|
||||
If you want to import all the recorded data from your recorder database you can use the data import script.
|
||||
It will read all your state_change events from the database and add them as data-points to the InfluxDB.
|
||||
You can specify the source database either by pointing the `--config` option to the config directory which includes the default SQLite database or by giving a sqlalchemy connection URI with `--uri`.
|
||||
The writing to InfluxDB is done in batches that can be changed with `--step`.
|
||||
|
||||
You can control, which data is imported by using the command line options `--exclude_entities` and `--exclude_domains`.
|
||||
Both get a comma separated list of either entity-ids or domain names that are excluded from the import.
|
||||
|
||||
To test what gets imported you can use the `--simulate` option, which disables the actual write to the InfluxDB instance.
|
||||
This only writes the statistics how much points would be imported from which entity.
|
||||
|
||||
Example to run the script:
|
||||
|
||||
```bash
|
||||
$ hass --script influxdb_import --config CONFIG_DIR \
|
||||
-H IP_INFLUXDB_HOST -u INFLUXDB_USERNAME -p INFLUXDB_PASSWORD \
|
||||
--dbname INFLUXDB_DB_NAME --exclude_domains automation,configurator
|
||||
```
|
||||
Script arguments:
|
||||
|
||||
```
|
||||
required arguments:
|
||||
-d dbname, --dbname dbname
|
||||
InfluxDB database name
|
||||
|
||||
optional arguments:
|
||||
-h, --help show this help message and exit
|
||||
-c path_to_config_dir, --config path_to_config_dir
|
||||
Directory that contains the Home Assistant
|
||||
configuration
|
||||
--uri URI Connect to URI and import (if other than default
|
||||
sqlite) eg: mysql://localhost/homeassistant
|
||||
|
||||
-H host, --host host InfluxDB host address
|
||||
-P port, --port port InfluxDB host port
|
||||
-u username, --username username
|
||||
InfluxDB username
|
||||
-p password, --password password
|
||||
InfluxDB password
|
||||
-s step, --step step How many points to import at the same time
|
||||
-t tags, --tags tags Comma separated list of tags (key:value) for all
|
||||
points
|
||||
-D default_measurement, --default-measurement default_measurement
|
||||
Store all your points in the same measurement
|
||||
-o override_measurement, --override-measurement override_measurement
|
||||
Store all your points in the same measurement
|
||||
-e exclude_entities, --exclude_entities exclude_entities
|
||||
Comma separated list of excluded entities
|
||||
-E exclude_domains, --exclude_domains exclude_domains
|
||||
Comma separated list of excluded domains
|
||||
-S, --simulate Do not write points but simulate preprocessing
|
||||
and print statistics
|
||||
```
|
||||
- [Helper script `influxdb_import`](/docs/tools/influxdb_import/)
|
||||
- [Helper script `db_migrator`](/docs/tools/db_migrator/) (only used for [Home Assistant 0.36](/blog/2017/01/14/iss-usps-images-packages/#influxdb-export))
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
|
||||
### {% linkable_title Full configuration %}
|
||||
|
||||
```yaml
|
||||
|
||||
@ -12,7 +12,7 @@ ha_category: Intent
|
||||
ha_release: "0.50"
|
||||
---
|
||||
|
||||
The intent_script component allows users to configure actions and responses to intents. Intents can be fired by any component that supports it. Examples are Alexa (Amazon Echo), API.ai (Google Assistant) and Snips.
|
||||
The intent_script component allows users to configure actions and responses to intents. Intents can be fired by any component that supports it. Examples are [Alexa](/components/alexa/) (Amazon Echo), [API.ai](/components/dialogflow/) (Google Assistant) and [Snips](/components/snips/).
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
||||
@ -10,7 +10,6 @@ footer: true
|
||||
logo: philips_hue.png
|
||||
ha_category: Light
|
||||
ha_iot_class: "Local Polling"
|
||||
featured: true
|
||||
ha_release: pre 0.7
|
||||
---
|
||||
|
||||
|
||||
@ -61,5 +61,5 @@ lights:
|
||||
{% endconfiguration %}
|
||||
|
||||
In the example above 12345 is ihc resource id and "tablelight" is the name.
|
||||
The IHC resource id can be a light level for dimmers or an boolean output of a relay.
|
||||
The IHC resource id can be a light level for dimmers or a boolean output of a relay.
|
||||
For more information about IHC resource ids see [Manual Setup](/components/ihc/#manual-setup)
|
||||
|
||||
@ -50,7 +50,7 @@ Device configuration variables:
|
||||
- **name** (*Optional*): Name for the device, defaults to Rflink ID.
|
||||
- **type** (*Optional*): Override automatically detected type of the light device, can be: switchable, dimmable, hybrid or toggle. See 'Light Types' below. (default: Switchable)
|
||||
- **aliases** (*Optional*): Alternative Rflink ID's this device is known by.
|
||||
- **fire_event** (*Optional*): Fire an `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **fire_event** (*Optional*): Fire a `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **signal_repetitions** (*Optional*): Repeat every Rflink command this number of times (default: 1).
|
||||
- **fire_event_** (*Optional*): Set default `fire_event` for RFLink switch devices (see below).
|
||||
- **signal_repetitions** (*Optional*): Set default `signal_repetitions` for RFLink switch devices (see below).
|
||||
@ -86,7 +86,7 @@ Any on/off command from any alias ID updates the current state of the light. How
|
||||
|
||||
Light devices can come in different forms. Some only switch on and off, other support dimming. Dimmable devices might not always respond nicely to repeated `on` command as they turn into a pulsating state until `on` is pressed again (for example KlikAanKlikUit). The RFLink component support three types of lights to make things work in every situation:
|
||||
|
||||
- *Hybrid*: This type sends a `dim` followed by an a `on` command; and `off` commands. This will make dimmable devices turn on at the requested dim level and on/off devices on. One caveat is this type is not compatible with signal repetition as multiple `on` signals will cause dimmers to go into disco mode.
|
||||
- *Hybrid*: This type sends a `dim` followed by an an `on` command; and `off` commands. This will make dimmable devices turn on at the requested dim level and on/off devices on. One caveat is this type is not compatible with signal repetition as multiple `on` signals will cause dimmers to go into disco mode.
|
||||
- *Switchable*: Device type that sends only `on` and `off` commands. It work for both on/off and dimmable type switches. However dimmables might have issues with signal repetition (see above).
|
||||
- *Dimmable*: Sends only `dim` and `off` commands. This does not work on on/off type devices as they don't understand the `dim` command. For dimmers this does not cause issues with signal repetitions.
|
||||
- *Toggle*: Device type that sends only `on` commands to turn on or off the device. Some switches like for example Livolo light switches use the same 'on' command to switch on and switch off the lights. If the light is on and 'on' gets sent, the light will turn off and if the light is off and 'on' gets sent, the light will turn on. If the device has an unknown state, it will assume it is off by default.
|
||||
|
||||
@ -73,7 +73,7 @@ logbook:
|
||||
|
||||
### {% linkable_title Exclude Events %}
|
||||
|
||||
Entities customized as hidden are excluded from the logbook by default, but sometimes you want to show the entity in the UI and not in the logbook. For instance you use the `sensor.date`to show the current date in the UI, but you do not want an logbook entry for that sensor every day.
|
||||
Entities customized as hidden are excluded from the logbook by default, but sometimes you want to show the entity in the UI and not in the logbook. For instance you use the `sensor.date`to show the current date in the UI, but you do not want a logbook entry for that sensor every day.
|
||||
To exclude these entities just add them to the `exclude` > `entities` list in the configuration of the logbook.
|
||||
|
||||
To exclude all events from a whole domain add it to the `exclude` > `domain` list. For instance you use the `sun` domain only to trigger automations on the `azimuth attribute, then you possible are not interested in the logbook entries for sun rise and sun set.
|
||||
|
||||
@ -10,7 +10,7 @@ ha_version: 0.51
|
||||
footer: true
|
||||
---
|
||||
|
||||
Mailboxes provide an list of messages with short information about each. Mailbox messages appear on a separate panel in the frontend.
|
||||
Mailboxes provide a list of messages with short information about each. Mailbox messages appear on a separate panel in the frontend.
|
||||
|
||||
Home Assistant currently supports only the [Asterisk Voicemail](/component/mailbox.asterisk_mbox) mailbox.
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ ha_category: Notifications
|
||||
ha_release: 0.38
|
||||
---
|
||||
|
||||
The component supports push messages and generates events based on inbound data. To use, add a Route set to Store and Notify with a URL of the following form: `https://<domain>/api/mailgun?api_password=<password>`
|
||||
The component supports push messages and generates events based on inbound data. To use, add a Route set to Store and Notify with a URL of the following form: `https://<home-assistant-domain>/api/mailgun?api_password=<password>`
|
||||
|
||||
To send messages, use the [Mailgun notify platform][notify].
|
||||
|
||||
@ -25,11 +25,10 @@ To send messages, use the [Mailgun notify platform][notify].
|
||||
mailgun:
|
||||
domain: mg.example.com
|
||||
api_key: token-XXXXXXXXX
|
||||
sandbox: False
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **domain** (*Optional*): This is the domain name to be used when sending out mail. Defaults to the first custom domain you have set up.
|
||||
- **sandbox** (*Optional*): Whether to use the sandboxed domain for outgoing mail. The `domain` item takes precedence over this. Defaults to `False`.
|
||||
- **domain** (*Required*): This is the domain name to be used when sending out mail. Defaults to the first custom domain you have set up.
|
||||
- **api_key** (*Required*): This is the API token that has been generated in your Mailgun account.
|
||||
- **sandbox** (*Optional*): Whether to use the sandboxed domain for outgoing mail. The `domain` item takes precedence over this. Defaults to `False`.
|
||||
|
||||
@ -15,7 +15,7 @@ ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
|
||||
Google Cast devices like Android TVs and Chromecasts will be automatically discovered if you enable [the discovery component]({{site_root}}/components/discovery/). There is a issue where Chromecasts can only be discovered if your device is connected to the same subnet as your Chromecast.
|
||||
Google Cast devices like Android TVs and Chromecasts will be automatically discovered if you enable [the discovery component]({{site_root}}/components/discovery/). There is an issue where Chromecasts can only be discovered if your device is connected to the same subnet as your Chromecast.
|
||||
|
||||
The Chromecast platform can also be forced to load by adding the following lines to your `configuration.yaml`:
|
||||
|
||||
|
||||
@ -58,7 +58,7 @@ If you're running Home Assistant in a virtual environment, you'll need to symlin
|
||||
ln -s /path/to/your/installation/of/gi /path/to/your/venv/lib/python3.4/site-packages
|
||||
```
|
||||
|
||||
On a Raspberry PI, you may need to add the Home Assistant user to the `audio` group:
|
||||
On a Raspberry Pi, you may need to add the Home Assistant user to the `audio` group:
|
||||
|
||||
```bash
|
||||
sudo usermod -a -G audio <ha_user>
|
||||
@ -68,7 +68,7 @@ sudo usermod -a -G audio <ha_user>
|
||||
|
||||
### {% linkable_title Using with TTS %}
|
||||
|
||||
To play TTS on your local computer (for example, if you have speakers attached to your Raspberry PI:
|
||||
To play TTS on your local computer (for example, if you have speakers attached to your Raspberry Pi:
|
||||
|
||||
```yaml
|
||||
media_player:
|
||||
|
||||
@ -18,17 +18,18 @@ The `panasonic_viera` platform allows you to control a Panasonic Viera TV.
|
||||
|
||||
Currently known supported models:
|
||||
|
||||
- TX-P42STW50
|
||||
- TC-P65VT30
|
||||
- TX-55CX700E
|
||||
- TX-32AS520E
|
||||
- TX-49DX650B
|
||||
- TX-50DX700B
|
||||
- TX-L42ET50
|
||||
- TX-P50GT60E
|
||||
- TX-55CX700E
|
||||
- TX-65EXW784
|
||||
- TX-32AS520E
|
||||
- TX-L42ET50
|
||||
- TX-P42STW50
|
||||
- TX-P50GT30Y
|
||||
- TX-P50GT60E
|
||||
|
||||
If your model is not on the list then give it a test, if everything works correctly then add it to the list on [GitHub](https://github.com/home-assistant/home-assistant.io).
|
||||
If your model is not on the list then give it a test, if everything works correctly then add it to the list on [GitHub](https://github.com/home-assistant/home-assistant.github.io/blob/next/source/_components/media_player.panasonic_viera.markdown).
|
||||
|
||||
Some Panasonic Viera TVs allow Home Assistant to turn them on, if you specify the MAC address with `mac:`.
|
||||
|
||||
|
||||
@ -57,6 +57,7 @@ Currently known supported models:
|
||||
- K6500AF (port must be set to 8001)
|
||||
- KS8005 (port must be set to 8001, and `pip3 install websocket-client` must be executed)
|
||||
- KU6290 (port must be set to 8001)
|
||||
- KU7000 (port must be set to 8001)
|
||||
- MU6170UXZG (port must be set to 8001, and `pip3 install websocket-client` must be executed)
|
||||
- KS7502 (port must be set to 8001, and `pip3 install websocket-client` must be executed, turn on doesn't work, turn off works fine)
|
||||
- K5600AK (partially supported, turn on works but state is not updated)
|
||||
@ -73,6 +74,8 @@ Currently tested but not working models:
|
||||
- JS9500 - State is always "on" and unable to control (but port 8001 *is* open)
|
||||
- MU6300 - Port set to 8001, `pip3 install websocket-client` must be executed, turning on works, status not working reliably, turning off is not permanent (it comes back on)
|
||||
|
||||
None of the 2014 (H) and 2015 (J) model series (e.g. J5200) will work, since Samsung have used a different (encrypted) type of interface for these.
|
||||
|
||||
If your model is not on the list then give it a test, if everything works correctly then add it to the list on [GitHub](https://github.com/home-assistant/home-assistant.github.io/tree/current/source/_components/media_player.samsungtv.markdown).
|
||||
The first letter (U, P, L, H & K) represent the screen type, e.g. LED or Plasma. The second letter represents the region, E is Europe, N is North America and A is Asia & Australia. The two numbers following that represent the screen size.
|
||||
If you add your model remember to remove these before adding them to the list.
|
||||
|
||||
@ -52,7 +52,7 @@ Configuration variables:
|
||||
have your receiver switched off.
|
||||
- In some cases, auto-discovery fails due to a known bug in the
|
||||
receiver's firmware. It is possible to manually specify the
|
||||
receiver's IP address or via it's hostname (if it is discoverable by
|
||||
receiver's IP address or via its hostname (if it is discoverable by
|
||||
your DNS) then.
|
||||
|
||||
### {% linkable_title Supported operations %}
|
||||
|
||||
@ -12,7 +12,7 @@ ha_category: Voice
|
||||
ha_release: 0.53
|
||||
---
|
||||
|
||||
[Mycroft](https://mycroft.ai) is a open source voice assistant that allows you to send notifications and more to Mycroft from Home Assistant.
|
||||
[Mycroft](https://mycroft.ai) is an open source voice assistant that allows you to send notifications and more to Mycroft from Home Assistant.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
||||
@ -16,7 +16,7 @@ ha_release: 0.56
|
||||
The `clickatell` platform uses [Clickatell](https://clickatell.com) to deliver SMS notifications from Home Assistant.
|
||||
|
||||
### Get your Clickatell API Credentials
|
||||
Go to your [Clickatell SMS Platform Portal](https://portal.clickatell.com/#/) section and create a new SMS integration. There are three screens of information required to creater an integration. Please ensure the following:
|
||||
Go to your [Clickatell SMS Platform Portal](https://portal.clickatell.com/#/) section and create a new SMS integration. There are three screens of information required to create an integration. Please ensure the following:
|
||||
|
||||
1. Give the new Integration an identification name.
|
||||
2. Ensure it is set for 'production' use.
|
||||
|
||||
@ -33,30 +33,32 @@ Configuration variables:
|
||||
|
||||
### {% linkable_title Getting ready for Chrome %}
|
||||
|
||||
1. Create new project at [https://console.cloud.google.com/home/dashboard](https://console.cloud.google.com/home/dashboard).
|
||||
2. Go to [https://console.cloud.google.com/apis/credentials/domainverification](https://console.cloud.google.com/apis/credentials/domainverification) and verify your domain.
|
||||
3. After that, go to [https://console.firebase.google.com](https://console.firebase.google.com) and select import Google project, select the project you created.
|
||||
4. Then, click the cogwheel on top left and select "Project settings".
|
||||
5. Select 'Cloud Messaging' tab, listed beneath Project Credentials will be your 152 character 'Server Key' and 12 digit ID 'Sender ID'.
|
||||
1. Make sure you can access your Home Assistant installation from outside your network over https ([see docs](https://home-assistant.io/docs/configuration/remote/)).
|
||||
2. Create a new project at [https://console.cloud.google.com/home/dashboard](https://console.cloud.google.com/home/dashboard).
|
||||
3. Go to [https://console.cloud.google.com/apis/credentials/domainverification](https://console.cloud.google.com/apis/credentials/domainverification) and verify your domain via Google Webmaster Central / Search Console - [instructions](#verify-your-domain).
|
||||
4. With the domain verified, go to [https://console.firebase.google.com](https://console.firebase.google.com), select import Google project, and select the project you created.
|
||||
5. Then, click the cogwheel on top left and select "Project settings".
|
||||
6. Select 'Cloud Messaging' tab, listed beneath Project Credentials will be your 152 character 'Server Key' and 12 digit ID 'Sender ID' you need for configuring this component.
|
||||
|
||||
#### {% linkable_title Verify your domain with Hass.io %}
|
||||
#### {% linkable_title Verify your domain %}
|
||||
|
||||
1. Set `https://yourdomain/local/` as URL.
|
||||
2. For verifying your domain you need to download a file in step 2.
|
||||
3. Create a directory named "www" in you Hass.io configuration directory.
|
||||
4. Place the file (something like this: google*.html) in the "www" directory.
|
||||
5. Verify the domain.
|
||||
6. Proceed with step 3.
|
||||
Follow these steps to verify domain ownership with Google Webmaster Central / Search Console:
|
||||
1. Enter your domain and add **'/local'** at the end, ie. https://example.com:8123/local
|
||||
2. Select HTML file verification and download the google*.html file.
|
||||
2. Create a directory named "www" in your Home Assistant configuration directory (/config share from Samba add-on).
|
||||
3. Place the downloaded google*.html file in the "www" directory.
|
||||
4. RESTART Home Assistant - this is important!
|
||||
5. Verify the file can be accessed in the browser, ie. **https://example.com:8123/local/google123456789.html** (change filename) - you should a plain text message saying "google-site-verification: ..." - if you see "404: Not Found" or something else, retry the above steps.
|
||||
6. Go back to Google Webmaster Central / Search Console and proceed with the verification.
|
||||
|
||||
### {% linkable_title Requirements %}
|
||||
|
||||
The `html5` platform can only function if all of the following requirements are met:
|
||||
(On Hass.io these requirements are already met.)
|
||||
|
||||
* You are using Chrome and/or Firefox on any desktop platform, ChromeOS or Android.
|
||||
* Your Home Assistant instance is exposed to the world.
|
||||
* If using a proxy, HTTP basic authentication must be off for registering or unregistering for push notifications. It can be re-enabled afterwards.
|
||||
* `pywebpush` must be installed. `libffi-dev`, `libpython-dev`, and `libssl-dev` must be installed prior to `pywebpush` (i.e. `pywebpush` probably won't automatically install).
|
||||
* If you don't run Hass.io: `pywebpush` must be installed. `libffi-dev`, `libpython-dev`, and `libssl-dev` must be installed prior to `pywebpush` (i.e. `pywebpush` probably won't automatically install).
|
||||
* You have configured SSL for your Home Assistant. It doesn't need to be configured in Home Assistant though, i.e. you can be running [NGINX](/ecosystem/nginx/) in front of Home Assistant and this will still work. The certificate must be trustworthy (i.e. not self signed).
|
||||
* You are willing to accept the notification permission in your browser.
|
||||
|
||||
@ -250,7 +252,7 @@ You will receive an event named `html5_notification.closed` when the notificatio
|
||||
|
||||
### {% linkable_title Making notifications work with NGINX proxy %}
|
||||
|
||||
If you use [NGINX](/ecosystem/nginx/) as an proxy with authentication in front of your Home Assistant instance, you may have trouble with receiving events back to Home Assistant. It's because of authentication token that cannot be passed through the proxy.
|
||||
If you use [NGINX](/ecosystem/nginx/) as a proxy with authentication in front of your Home Assistant instance, you may have trouble with receiving events back to Home Assistant. It's because of authentication token that cannot be passed through the proxy.
|
||||
|
||||
To solve the issue put additional location into your nginx site's configuration:
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ ha_release: 0.39
|
||||
|
||||
The [Pushsafer service](https://www.pushsafer.com/) is a platform for the notify component. This allows you to send messages to the user using Pushsafer.
|
||||
|
||||
In order to get an private or alias key you need to go to the [Pushsafer website](https://www.pushsafer.com) and register.
|
||||
In order to get a private or alias key you need to go to the [Pushsafer website](https://www.pushsafer.com) and register.
|
||||
|
||||
To use Pushsafer notifications, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
||||
@ -44,4 +44,21 @@ hass.bus.fire(name, { "wow": "from a Python script!" })
|
||||
}
|
||||
```
|
||||
|
||||
For [`python_script:` examples](/components/python_script/) visit the [Scripts section](https://community.home-assistant.io/c/projects/scripts) in our forum.
|
||||
## {% linkable_title Calling Services %}
|
||||
|
||||
The following example shows how to call a service from `python_script`. This script takes two parameters: `entity_id` (required), `rgb_color` (optional) and calls `light.turn_on` service by setting the brightness value to `255`.
|
||||
|
||||
```python
|
||||
entity_id = data.get('entity_id')
|
||||
rgb_color = data.get('rgb_color', [255, 255, 255])
|
||||
if entity_id is not None:
|
||||
service_data = {'entity_id': entity_id, 'rgb_color': rgb_color, 'brightness': 255 }
|
||||
hass.services.call('light', 'turn_on', service_data, False)
|
||||
```
|
||||
The above `python_script` can be called using the following JSON as an input.
|
||||
|
||||
```json
|
||||
{"entity_id": "light.bedroom", "rgb_color": [255, 0, 0] }
|
||||
```
|
||||
|
||||
For more examples, visit the [Scripts section](https://community.home-assistant.io/c/projects/scripts) in our forum.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Raspihats"
|
||||
description: "Instructions how to integrate Raspihats add-on boards for Raspberry PI into Home Assistant."
|
||||
description: "Instructions how to integrate Raspihats add-on boards for Raspberry Pi into Home Assistant."
|
||||
date: 2017-05-01 04:06
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
||||
@ -135,7 +135,7 @@ If you find a device is recognized differently, with different protocols or the
|
||||
|
||||
### {% linkable_title Technical Overview %}
|
||||
|
||||
- The`rflink` Python module is a asyncio transport/protocol which is setup to fire a callback for every (valid/supported) packet received by the RFLink gateway.
|
||||
- The`rflink` Python module is an asyncio transport/protocol which is setup to fire a callback for every (valid/supported) packet received by the RFLink gateway.
|
||||
- This component uses this callback to distribute 'rflink packet events' over [Home Assistant's event bus](https://home-assistant.io/docs/configuration/events/) which can be subscribed to by entities/platform implementations.
|
||||
- The platform implementation takes care of creating new devices (if enabled) for unseen incoming packet ID's.
|
||||
- Device entities take care of matching to the packet ID, interpreting and performing actions based on the packet contents. Common entity logic is maintained in this main component.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Raspberry PI GPIO"
|
||||
description: "Instructions how to integrate the GPIO capability of a Raspberry PI into Home Assistant."
|
||||
title: "Raspberry Pi GPIO"
|
||||
description: "Instructions how to integrate the GPIO capability of a Raspberry Pi into Home Assistant."
|
||||
date: 2016-08-30 19:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
||||
@ -56,7 +56,7 @@ Configuration variables:
|
||||
- **port** (*Optional*): The port on which the ETHM module listens for clients using integration protocol. Default: `7094`
|
||||
- **partition** (*Optional*): The partition to operate on. Integra can support multiple partitions, this platform only supports one. Default: `1`
|
||||
- **arm_home_mode** (*Optional*): The mode in which arm Satel Integra when 'arm home' is used. Possible options are `1`,`2` or `3`, default being `1`. For more information on what are the differences between them, please refer to Satel Integra manual.
|
||||
- **zones** (*Optional*): This module does not discover currently which zones are actually in use, so it will only monitor the ones defined in the config. For each zone, a proper ID must be given as well as it's name (does not need to match the one specified in Satel Integra alarm). For more information on the available zone types, take a look at the [Binary Sensor](/components/binary_sensor.alarmdecoder/) docs. *Note: If no zones are specified, Home Assistant will not load any binary_sensor components.*
|
||||
- **zones** (*Optional*): This module does not discover currently which zones are actually in use, so it will only monitor the ones defined in the config. For each zone, a proper ID must be given as well as its name (does not need to match the one specified in Satel Integra alarm). For more information on the available zone types, take a look at the [Binary Sensor](/components/binary_sensor.alarmdecoder/) docs. *Note: If no zones are specified, Home Assistant will not load any binary_sensor components.*
|
||||
|
||||
List of all zone IDs can be taken from DloadX program.
|
||||
|
||||
|
||||
@ -112,3 +112,9 @@ script:
|
||||
title: "{% raw %}{{ title }}{% endraw %}"
|
||||
message: "{% raw %}{{ message }}{% endraw %}"
|
||||
```
|
||||
|
||||
### {% linkable_title In the Overview %}
|
||||
|
||||
Scripts in the Overview panel will be displayed with an **ACTIVATE** button if the device has no `delay:` or `wait:` statement, and as a toggle switch if it has either of those.
|
||||
|
||||
This is to enable you to stop a running script.
|
||||
|
||||
@ -14,7 +14,7 @@ ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
|
||||
The `arduino` sensor platform allows you to get an numerical values from an analog input pin of an [Arduino](https://www.arduino.cc/) board. Usually the value is between 0 and 1024.
|
||||
The `arduino` sensor platform allows you to get numerical values from an analog input pin of an [Arduino](https://www.arduino.cc/) board. Usually the value is between 0 and 1024.
|
||||
|
||||
To enable an Arduino sensor with Home Assistant, add the following section to your `configuration.yaml` file:
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `buienradar` platform uses [buienradar.nl](http://buienradar.nl/) as an source for current meteorological data for your location. The weather forecast is delivered by Buienradar, who provides a web service that provides detailed weather information for users in The Netherlands. The relevant weather station used will be automatically selected based on the location specified in the Home Assistant configuration (or in the buienradar weather/sensor component). A map of all available weather stations can be found [here](https://www.google.com/maps/d/embed?mid=1NivHkTGQUOs0dwQTnTMZi8Uatj0).
|
||||
The `buienradar` platform uses [buienradar.nl](http://buienradar.nl/) as a source for current meteorological data for your location. The weather forecast is delivered by Buienradar, who provides a web service that provides detailed weather information for users in The Netherlands. The relevant weather station used will be automatically selected based on the location specified in the Home Assistant configuration (or in the buienradar weather/sensor component). A map of all available weather stations can be found [here](https://www.google.com/maps/d/embed?mid=1NivHkTGQUOs0dwQTnTMZi8Uatj0).
|
||||
|
||||
The selected weather station will provide all weather data, with the exception of the forecasted precipitation. The forecasted precipitation data will be retrieved from buienradar using your actual gps-location (and not the location of the nearest weather station).
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ If you'd like to know how many failed login attempts are made to Home Assistant,
|
||||
sensor:
|
||||
- platform: command_line
|
||||
name: badlogin
|
||||
command: grep -c 'Login attempt' /home/hass/.homeassistant/home-assistant.log
|
||||
command: "grep -c 'Login attempt' /home/hass/.homeassistant/home-assistant.log"
|
||||
```
|
||||
|
||||
Make sure to configure the [logger component](/components/logger) to monitor the [http component](https://home-assistant.io/components/http/) at least the `warning` level.
|
||||
|
||||
@ -10,7 +10,7 @@ footer: true
|
||||
logo: dark_sky.png
|
||||
ha_category: Weather
|
||||
featured: true
|
||||
ha_release: 0.30
|
||||
ha_release: "0.30"
|
||||
redirect_from: /components/sensor.forecast/
|
||||
ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
@ -131,7 +131,7 @@ DSMR is a standard to which Dutch smartmeters must comply. It specifies that the
|
||||
|
||||
The contents of this telegram differ between version but they generally consist of lines with 'obis' (Object Identification System, a numerical ID for a value) followed with the value and unit.
|
||||
|
||||
This module sets up a asynchronous reading loop using the `dsmr_parser` module which waits for a complete telegram, parser it and puts it on an async queue as a dictionary of `obis`/object mapping. The numeric value and unit of each value can be read from the objects attributes. Because the `obis` are know for each DSMR version the Entities for this component are create during bootstrap.
|
||||
This module sets up an asynchronous reading loop using the `dsmr_parser` module which waits for a complete telegram, parser it and puts it on an async queue as a dictionary of `obis`/object mapping. The numeric value and unit of each value can be read from the objects attributes. Because the `obis` are know for each DSMR version the Entities for this component are create during bootstrap.
|
||||
|
||||
Another loop (DSMR class) is setup which reads the telegram queue, stores/caches the latest telegram and notifies the Entities that the telegram has been updated.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ footer: true
|
||||
logo: kwb.png
|
||||
ha_category: Sensor
|
||||
ha_iot_class: "Local Polling"
|
||||
ha_release: 0.40
|
||||
ha_release: "0.40"
|
||||
---
|
||||
|
||||
The `kwb` component integrates the sensors of KWB Easyfire pellet central heating units with the Comfort3 controller (http://www.kwbheizung.de/de/produkte/kwb-comfort-3.html) into Home Assistant.
|
||||
|
||||
@ -20,7 +20,7 @@ Depending on the operating system you're running, you have to configure the prop
|
||||
|
||||
- On [Hass.io](https://home-assistant.io/hassio/installation/): Miflora will work out of the box.
|
||||
- On other Linux systems:
|
||||
- Prefered solution: Install the `bluepy` library (via pip). When using a virtual environment, make sure to use install the library in the right one.
|
||||
- Preferred solution: Install the `bluepy` library (via pip). When using a virtual environment, make sure to use install the library in the right one.
|
||||
- Fallback solution: Install `gatttool` via your package manager. Depending on the distribution, the package name might be: `bluez`, `bluetooth`, `bluez-deprecated`
|
||||
- Windows and MacOS are currently not supported by the [miflora library](https://github.com/open-homeautomation/miflora/).
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ If Home Assistant (`hass`) runs with another user (e.g. `homeassistant` on Hassb
|
||||
|
||||
Depending on what's plugged into your USB ports, the name found above may change. You can lock in a name, such as `/dev/modem`, by following [these instructions](http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/).
|
||||
|
||||
When the sensor detects a new call, it's state changes to 'ring' for each ring and 'callerid' when caller id information is received. It returns to 'idle' once ringing stops. The state event includes an attribute payload that includes the time of the call, name and number.
|
||||
When the sensor detects a new call, its state changes to 'ring' for each ring and 'callerid' when caller id information is received. It returns to 'idle' once ringing stops. The state event includes an attribute payload that includes the time of the call, name and number.
|
||||
|
||||
Some example automations:
|
||||
```yaml
|
||||
|
||||
@ -90,8 +90,9 @@ If you are using the [Owntracks](/components/device_tracker.owntracks/) and enab
|
||||
owntracks/tablet/tablet {"_type":"location","lon":7.21,"t":"u","batt":92,"tst":144995643,"tid":"ta","acc":27,"lat":46.12}
|
||||
```
|
||||
|
||||
Thus the trick is extract the battery level from the payload.
|
||||
Thus the trick is extracting the battery level from the payload.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Example configuration.yml entry
|
||||
sensor:
|
||||
@ -99,8 +100,9 @@ sensor:
|
||||
state_topic: "owntracks/tablet/tablet"
|
||||
name: "Battery Tablet"
|
||||
unit_of_measurement: "%"
|
||||
value_template: {% raw %}'{{ value_json.batt }}'{% endraw %}
|
||||
value_template: '{{ value_json.batt }}'
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### {% linkable_title Get temperature and humidity %}
|
||||
|
||||
@ -116,6 +118,7 @@ office/sensor1
|
||||
|
||||
Then use this configuration example to extract the data from the payload:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Example configuration.yml entry
|
||||
sensor:
|
||||
@ -123,10 +126,37 @@ sensor:
|
||||
state_topic: 'office/sensor1'
|
||||
name: 'Temperature'
|
||||
unit_of_measurement: '°C'
|
||||
value_template: {% raw %}'{{ value_json.temperature }}'{% endraw %}
|
||||
value_template: '{{ value_json.temperature }}'
|
||||
- platform: mqtt
|
||||
state_topic: 'office/sensor1'
|
||||
name: 'Humidity'
|
||||
unit_of_measurement: '%'
|
||||
value_template: {% raw %}'{{ value_json.humidity }}'{% endraw %}
|
||||
value_template: '{{ value_json.humidity }}'
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### {% linkable_title Get sensor value from a device with ESPEasy %}
|
||||
|
||||
Assuming that you have flashed your ESP8266 unit with [ESPEasy](https://github.com/letscontrolit/ESPEasy). Under "Config" set a name ("Unit Name:") for your device (here it's "bathroom"). A "Controller" for MQTT with the protocol "OpenHAB MQTT" is present and the entries ("Controller Subscribe:" and "Controller Publish:") are adjusted to match your needs. In this example the topics are prefixed with "home". Also, add a sensor in the "Devices" tap with the name "analog" and "brightness" as value.
|
||||
|
||||
As soon as the unit is online, you will get the state of the sensor.
|
||||
|
||||
```bash
|
||||
home/bathroom/status Connected
|
||||
...
|
||||
home/bathroom/analog/brightness 290.00
|
||||
```
|
||||
|
||||
The configuration will look like the example below:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Example configuration.yml entry
|
||||
sensor:
|
||||
- platform: mqtt
|
||||
state_topic: 'home/bathroom/analog/brightness'
|
||||
name: Brightness
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `openweathermap` platform uses [OpenWeatherMap](http://openweathermap.org/) as an source for current meteorological data for your location. The `forecast` will show you the condition in 3 h.
|
||||
The `openweathermap` platform uses [OpenWeatherMap](http://openweathermap.org/) as a source for current meteorological data for your location. The `forecast` will show you the condition in 3 h.
|
||||
|
||||
You need an API key which is free but requires a [registration](http://home.openweathermap.org/users/sign_up).
|
||||
|
||||
|
||||
@ -66,6 +66,7 @@ Only these data_type are valid :
|
||||
- *Sound*
|
||||
- *Sensor Status*
|
||||
- *Counter value*
|
||||
- *UV*
|
||||
|
||||
Example configuration:
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ It required that you enable the HTTP feature in the `/etc/supervisord.conf` conf
|
||||
port=127.0.0.1:9001
|
||||
```
|
||||
|
||||
After a restart of `supervisord` you should be able to access the web interface. If needed then this could be added as a [iFrame panel](/components/panel_iframe/).
|
||||
After a restart of `supervisord` you should be able to access the web interface. If needed then this could be added as an [iFrame panel](/components/panel_iframe/).
|
||||
|
||||
<p class='img'>
|
||||
<img src='{{site_root}}/images/screenshots/supervisor.png' />
|
||||
|
||||
@ -9,7 +9,7 @@ sharing: true
|
||||
footer: true
|
||||
logo: ted.png
|
||||
ha_category: Sensor
|
||||
ha_release: 0.30
|
||||
ha_release: "0.30"
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ The `vera` platform allows you to get data from your [Vera](http://getvera.com/)
|
||||
|
||||
They will be automatically discovered if the vera component is loaded.
|
||||
|
||||
Please note that some vera sensors (such as _motion_ and _flood_ sensors) are _armable_ which means that vera will send alerts (email messages to txts) when they are _armed_ an change state.
|
||||
Please note that some vera sensors (such as _motion_ and _flood_ sensors) are _armable_ which means that vera will send alerts (email messages to txts) when they are _armed_ and change state.
|
||||
|
||||
Home Assistant will display the state of these sensors regardless of the _armed_ state.
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `yr` platform uses [YR.no](http://www.yr.no/) as an source for current meteorological data for your location. The
|
||||
The `yr` platform uses [YR.no](http://www.yr.no/) as a source for current meteorological data for your location. The
|
||||
weather forecast is delivered by the Norwegian Meteorological Institute and the NRK.
|
||||
|
||||
To add YR to your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
@ -14,7 +14,7 @@ ha_iot_class: "Cloud Polling"
|
||||
---
|
||||
|
||||
|
||||
The `yweather` platform uses [Yahoo Weather](https://www.yahoo.com/news/weather/) as an source for current meteorological data. The `forecast` will show you the condition for 5 days, 0 is the current day. You can use only `weather`, `temp_min`, and `temp_max` with forecast. It's important to note that a yweather sensor will only show ONE days forecast at a time so to show multiple days forecasts, you will need to use the 'name:' option and give each sensor a unique name.
|
||||
The `yweather` platform uses [Yahoo Weather](https://www.yahoo.com/news/weather/) as a source for current meteorological data. The `forecast` will show you the condition for 5 days, 0 is the current day. You can use only `weather`, `temp_min`, and `temp_max` with forecast. It's important to note that a yweather sensor will only show ONE days forecast at a time so to show multiple days forecasts, you will need to use the 'name:' option and give each sensor a unique name.
|
||||
|
||||
<p class='note warning'>
|
||||
Use of the Yahoo Weather API should not exceed reasonable request volume. Access is limited to 2000 signed calls per day.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: gc100 Switch
|
||||
description: "Instructions on how to set up an gc100 switch within Home Assistant."
|
||||
description: "Instructions on how to set up a gc100 switch within Home Assistant."
|
||||
date: 2017-10-27 17:26
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
||||
@ -119,5 +119,31 @@ switch:
|
||||
For a check you can use the command line tools `mosquitto_pub` shipped with `mosquitto` to send MQTT messages. This allows you to operate your switch manually:
|
||||
|
||||
```bash
|
||||
$ mosquitto_pub -h 127.0.0.1 -t home/bedroom/switch1 -m "ON"
|
||||
$ mosquitto_pub -h 127.0.0.1 -t home/bedroom/switch1 -m "ON"
|
||||
```
|
||||
|
||||
### {% linkable_title Set the state of a device with ESPEasy %}
|
||||
|
||||
Assuming that you have flashed your ESP8266 unit with [ESPEasy](https://github.com/letscontrolit/ESPEasy). Under "Config" is a name ("Unit Name:") set for your device (here it's "bathroom"). A configuration for a "Controller" for MQTT with the protocol "OpenHAB MQTT" is present and the entries ("Controller Subscribe:" and "Controller Publish:") are adjusted to match your needs. In this example the topics are prefixed with "home". There is no further configuration needed as the [GPIOs](https://www.letscontrolit.com/wiki/index.php/GPIO) can be controlled with MQTT directly.
|
||||
|
||||
Manually you can set pin 13 to high with `mosquitto_pub` or another MQTT tool:
|
||||
|
||||
```bash
|
||||
$ mosquitto_pub -h 127.0.0.1 -t home/bathroom/gpio/13 -m "1"
|
||||
```
|
||||
|
||||
The configuration will look like the example below:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Example configuration.yml entry
|
||||
switch:
|
||||
- platform: mqtt
|
||||
name: bathroom
|
||||
state_topic: "home/bathroom/gpio/13"
|
||||
command_topic: "home/bathroom/gpio/13"
|
||||
payload_on: "1"
|
||||
payload_off: "0"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
|
||||
@ -13,10 +13,9 @@ ha_release: 0.26
|
||||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
|
||||
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 Home Assistant 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 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.
|
||||
|
||||
@ -42,20 +41,21 @@ Configuration variables:
|
||||
- **[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.
|
||||
|
||||
Variables for the different codes (`on_code` and `off_code`):
|
||||
|
||||
- **protocol** (*Required*): Protocol to use, eg. `intertechno_old` or `daycom`.
|
||||
- **systemcode** (*Optional*): The systemcode of the device.
|
||||
- **unit** (*Optional*): The unit to use.
|
||||
- **unit** (*Optional*): The unit to use (is equivalent to `pilight-send --unit`).
|
||||
- **unitcode** (*Optional*): The unitcode to use (is equivalent to `pilight-send --unitcode`).
|
||||
- **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 occurring.
|
||||
For possible code entries, look at the [pilight API](https://manual.pilight.org/development/api.html). All commands allowed by [pilight-send](https://manual.pilight.org/programs/send.html) 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 occurring.
|
||||
|
||||
Variables for the different receive codes (`on_code_receive` and `off_code_receive`):
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Raspihats Switch"
|
||||
description: "Instructions how to integrate Raspihats add-on boards for Raspberry PI into Home Assistant as a switch."
|
||||
description: "Instructions how to integrate Raspihats add-on boards for Raspberry Pi into Home Assistant as a switch."
|
||||
date: 2017-05-15 04:20
|
||||
sidebar: true
|
||||
comments: false
|
||||
@ -89,4 +89,4 @@ It will output a table like this:
|
||||
70: -- -- -- -- -- -- -- 77
|
||||
```
|
||||
|
||||
For more details about the Raspihats add-on boards for Raspberry PI, visit [raspihats.com](http://www.raspihats.com/).
|
||||
For more details about the Raspihats add-on boards for Raspberry Pi, visit [raspihats.com](http://www.raspihats.com/).
|
||||
|
||||
@ -50,7 +50,7 @@ Device configuration variables:
|
||||
|
||||
- **name** (*Optional*): Name for the device, defaults to RFLink ID.
|
||||
- **aliases** (*Optional*): Alternative RFLink ID's this device is known by.
|
||||
- **fire_event** (*Optional*): Fire an `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **fire_event** (*Optional*): Fire a `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **signal_repetitions** (*Optional*): Repeat every RFLink command this number of times (default: 1)
|
||||
- **group** (*Optional*): Allow switch to respond to group commands (ALLON/ALLOFF). (default: yes)
|
||||
- **group_aliases** (*Optional*): `aliases` which only respond to group commands.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Raspberry PI GPIO Switch"
|
||||
description: "Instructions how to integrate the GPIO of a Raspberry PI into Home Assistant as a switch."
|
||||
title: "Raspberry Pi GPIO Switch"
|
||||
description: "Instructions how to integrate the GPIO of a Raspberry Pi into Home Assistant as a switch."
|
||||
date: 2015-08-07 14:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
||||
@ -92,17 +92,19 @@ Select <img src='/images/screenshots/developer-tool-services-icon.png' alt='serv
|
||||
}
|
||||
```
|
||||
|
||||
### {% linkable_title Configuration example %}
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
Set a timer called `test` to a duration of 30 seconds.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
||||
# Set a timer called test to a duration of 30 seconds:
|
||||
timer:
|
||||
test:
|
||||
duration: '00:00:30'
|
||||
```
|
||||
|
||||
### {% linkable_title Control a timer from the frontend %}
|
||||
|
||||
```yaml
|
||||
# Example automations.yaml entry
|
||||
- action:
|
||||
@ -131,3 +133,31 @@ timer:
|
||||
entity_id: timer.test
|
||||
```
|
||||
|
||||
### {% linkable_title Control a timer from the frontend %}
|
||||
|
||||
With the [`script`](/components/script/) component you would be able to control a timer (see above for a `timer` configuration sample) manually.
|
||||
|
||||
```yaml
|
||||
script:
|
||||
start_timer:
|
||||
alias: Start timer
|
||||
sequence:
|
||||
- service: timer.start
|
||||
entity_id: timer.test
|
||||
pause_timer:
|
||||
alias: Pause timer
|
||||
sequence:
|
||||
- service: timer.pause
|
||||
entity_id: timer.test
|
||||
cancel_timer:
|
||||
alias: Cancel timer
|
||||
sequence:
|
||||
- service: timer.cancel
|
||||
entity_id: timer.test
|
||||
finish_timer:
|
||||
alias: Finish timer
|
||||
sequence:
|
||||
- service: timer.finish
|
||||
entity_id: timer.test
|
||||
```
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ tts:
|
||||
api_key: 'XXXXX'
|
||||
language: 'de-de'
|
||||
codec: mp3
|
||||
format: 8khz_8bit_mono
|
||||
format: '8khz_8bit_mono'
|
||||
```
|
||||
|
||||
Please note, some media_players require a certain format. For example the Sonos requires a format of '44khz_16bit_stereo'
|
||||
|
||||
@ -11,7 +11,7 @@ logo: home-assistant.png
|
||||
ha_category: Other
|
||||
---
|
||||
|
||||
The `updater` component will check daily for new releases. It will show a badge in the frontend if a new version is found. As [Hass.io](/hassio/) has it's own schedule for release it doesn't make sense to use this component on Hass.io.
|
||||
The `updater` component will check daily for new releases. It will show a badge in the frontend if a new version is found. As [Hass.io](/hassio/) has its own schedule for release it doesn't make sense to use this component on Hass.io.
|
||||
|
||||
The updater component will also collect basic information about the running Home Assistant instance and its environment. The information includes the current Home Assistant version, the time zone, Python version and operating system information. No identifiable information (i.e., IP address, GPS coordinates, etc.) will ever be collected. If you are concerned about your privacy, you are welcome to scrutinize the Python [source code](https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/updater.py#L91). For further information about the Updater's data, please check the [detailed overview](/docs/backend/updater/).
|
||||
|
||||
|
||||
@ -64,5 +64,5 @@ every polling cycle.
|
||||
While this is communicating with a thermostat, geothermal systems
|
||||
operate most efficiently when setbacks are not used, and the home is
|
||||
kept at a constant temperature. It remains useful to collect the data
|
||||
from the system to understand it's performance, but a full climate
|
||||
from the system to understand its performance, but a full climate
|
||||
interface won't be implemented.
|
||||
|
||||
@ -10,7 +10,7 @@ footer: true
|
||||
ha_category: Automation Examples
|
||||
---
|
||||
|
||||
#### {% linkable_title Change Hue light on interval to random color based on state of a input boolean %}
|
||||
#### {% linkable_title Change Hue light on interval to random color based on state of an input boolean %}
|
||||
|
||||
_Note, Philips Hue is currently the only light platform that support the random effect._
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ sensor:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
The `else` part is used to have the sensor keep it's last state if the newest [iCloud](/components/device_tracker.icloud/) update doesn't have any battery state in it (which happens sometimes). Otherwise the sensor will be blank.
|
||||
The `else` part is used to have the sensor keep its last state if the newest [iCloud](/components/device_tracker.icloud/) update doesn't have any battery state in it (which happens sometimes). Otherwise the sensor will be blank.
|
||||
|
||||
### {% linkable_title Android and iOS Devices %}
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ Before beginning make sure that you have the following:
|
||||
|
||||
3. Create a configuration file for the server
|
||||
|
||||
As the `asterisk` user create a `asterisk_mbox.ini` file (You can place this in any directory you choose, but the rommended location is `/etc/asterisk/asterisk_mbox.ini`)
|
||||
As the `asterisk` user create an `asterisk_mbox.ini` file (You can place this in any directory you choose, but the rommended location is `/etc/asterisk/asterisk_mbox.ini`)
|
||||
|
||||
```ini
|
||||
[default]
|
||||
|
||||
@ -53,65 +53,15 @@ logger: debug
|
||||
```
|
||||
This will not print the actual secret's value to the log.
|
||||
|
||||
*Option 2*: View where secrets are retrieved from and the contents of all `secrets.yaml` files used, you can use the `check_config` script from the command line:
|
||||
*Option 2*: View where secrets are retrieved from and the contents of all `secrets.yaml` files used, you can use the [`check_config` script](/docs/tools/check_config/) from the command line:
|
||||
|
||||
```bash
|
||||
$ hass --script check_config --secrets
|
||||
```
|
||||
This will print all your secrets.
|
||||
|
||||
### {% linkable_title Storing passwords in a keyring managed by your OS %}
|
||||
## {% linkable_title Alternatives to `secrets.yaml` %}
|
||||
|
||||
Using [Keyring](https://github.com/jaraco/keyring) is an alternative way to `secrets.yaml`. They can be managed from the command line via the `keyring` script.
|
||||
- [Using a keyring that is managed by your OS to store secrets](/docs/tools/keyring/)
|
||||
- [Storing passwords securely in AWS](/docs/tools/credstash/)
|
||||
|
||||
```bash
|
||||
$ hass --script keyring --help
|
||||
```
|
||||
|
||||
To store a password in keyring, replace your password or API key with `!secret` and an identifier in `configuration.yaml` file.
|
||||
|
||||
```yaml
|
||||
http:
|
||||
api_password: !secret http_password
|
||||
```
|
||||
|
||||
Create an entry in your keyring.
|
||||
|
||||
```bash
|
||||
$ hass --script keyring set http_password
|
||||
```
|
||||
|
||||
If you launch Home Assistant now, you will be prompted for the keyring password to unlock your keyring.
|
||||
|
||||
```bash
|
||||
$ hass
|
||||
Config directory: /home/homeassistant/.homeassistant
|
||||
Please enter password for encrypted keyring:
|
||||
```
|
||||
|
||||
<p class='note warning'>
|
||||
If you are using the Python Keyring, [autostarting](/getting-started/autostart/) of Home Assistant will no longer work.
|
||||
</p>
|
||||
|
||||
### {% linkable_title Storing passwords securely in AWS %}
|
||||
|
||||
Using [Credstash](https://github.com/fugue/credstash) is an alternative way to `secrets.yaml`. They can be managed from the command line via the credstash script.
|
||||
|
||||
Before using credstash, you need to set up AWS credentials either via the `aws` command line tool or using environment variables as explained in the [AWS CLI docs](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) as well as creating a KMS key named `credstash` as explained in the [credstash Readme](https://github.com/fugue/credstash#setting-up-kms). After that is complete, you can use the provided script to add secrets to your Home Assistant secret store in credstash.
|
||||
|
||||
```bash
|
||||
$ hass --script credstash --help
|
||||
```
|
||||
|
||||
To store a password in credstash, replace your password or API key with `!secret` and an identifier in `configuration.yaml` file.
|
||||
|
||||
```yaml
|
||||
http:
|
||||
api_password: !secret http_password
|
||||
```
|
||||
|
||||
Create an entry in your credstash store.
|
||||
|
||||
```bash
|
||||
$ hass --script credstash set http_password
|
||||
```
|
||||
|
||||
@ -27,7 +27,7 @@ Field | Description
|
||||
`state.last_changed` | Time the state changed. This is not updated when there are only updated attributes. Example: `2017-10-28 08:13:36.715874+00:00`.
|
||||
`state.attributes` | A dictionary with extra attributes related to the current state.
|
||||
|
||||
The attributes of an entity are optional. There are a few attributes that are used by Home Assistant for representing the entity in a specific way. Each component will also have it's own attributes to represent extra state data about the entity. For example, the light component has attributes for the current brightness and color of the light. When an attribute is not available, Home Assistant will not write it to the state.
|
||||
The attributes of an entity are optional. There are a few attributes that are used by Home Assistant for representing the entity in a specific way. Each component will also have its own attributes to represent extra state data about the entity. For example, the light component has attributes for the current brightness and color of the light. When an attribute is not available, Home Assistant will not write it to the state.
|
||||
|
||||
When using templates, attributes will be available by their name. For example `state.attributes.assumed_state`.
|
||||
|
||||
|
||||
@ -107,4 +107,4 @@ Of course, if I wanted to make this App or its predecessor reusable, I would hav
|
||||
|
||||
In addition, Apps can write to `AppDaemon`'s log files, and there is a system of constraints that allows you to control when and under what circumstances Apps and callbacks are active to keep the logic clean and simple.
|
||||
|
||||
For full installation instructions, see the [AppDaemon Project Documentation pages](http://appdaemon.readthedocs.io/en/latest/).
|
||||
For full installation instructions, see the [AppDaemon Project Documentation pages](http://appdaemon.readthedocs.io/en/stable/).
|
||||
|
||||
@ -22,13 +22,13 @@ import homeassistant.appapi as appapi
|
||||
class MotionLights(appapi.AppDaemon):
|
||||
```
|
||||
|
||||
When configured as an app in the config file (more on that later) the lifecycle of the App begins. It will be instantiated as an object by AppDaemon, and immediately, it will have a call made to it's `initialize()` function - this function must appear as part of every app:
|
||||
When configured as an app in the config file (more on that later) the lifecycle of the App begins. It will be instantiated as an object by AppDaemon, and immediately, it will have a call made to its `initialize()` function - this function must appear as part of every app:
|
||||
|
||||
```python
|
||||
def initialize(self):
|
||||
```
|
||||
|
||||
The initialize function allows the app to register any callbacks it might need for responding to state changes, and also any setup activities. When the `initialize()` function returns, the App will be dormant until any of it's callbacks are activated.
|
||||
The initialize function allows the app to register any callbacks it might need for responding to state changes, and also any setup activities. When the `initialize()` function returns, the App will be dormant until any of its callbacks are activated.
|
||||
|
||||
There are several circumstances under which `initialize()` might be called:
|
||||
|
||||
@ -93,7 +93,7 @@ class = NewApp
|
||||
|
||||
When AppDaemon sees the following configuration it will expect to find a class called `NewApp` defined in a module called `new.py` in the apps subdirectory. Apps can be placed at the root of the Apps directory or within a subdirectory, an arbitrary depth down - wherever the App is, as long as it is in some subdirectory of the Apps dir, or in the Apps dir itself, AppDaemon will find it. There is no need to include information about the path, just the name of the file itself (without the `.py`) is sufficient. If names in the subdirectories overlap, AppDir will pick one of them but the exact choice it will make is undefined.
|
||||
|
||||
When starting the system for the first time or when reloading an App or Module, the system will log the fact in it's main log. It is often the case that there is a problem with the class, maybe a syntax error or some other problem. If that is the case, details will be output to the error log allowing the user to remedy the problem and reload.
|
||||
When starting the system for the first time or when reloading an App or Module, the system will log the fact in its main log. It is often the case that there is a problem with the class, maybe a syntax error or some other problem. If that is the case, details will be output to the error log allowing the user to remedy the problem and reload.
|
||||
|
||||
## {% linkable_title Steps to writing an App %}
|
||||
|
||||
@ -154,7 +154,7 @@ Callback constraints are a feature of AppDaemon that removes the need for repeti
|
||||
|
||||
Put simply, callback constraints are one or more conditions on callback execution that can be applied to an individual App. An App's callbacks will only be executed if all of the constraints are met. If a constraint is absent it will not be checked for.
|
||||
|
||||
For example, the presence callback constraint can be added to an App by adding a parameter to it's configuration like this:
|
||||
For example, the presence callback constraint can be added to an App by adding a parameter to its configuration like this:
|
||||
|
||||
```ini
|
||||
[some_app]
|
||||
@ -565,7 +565,7 @@ self.cancel_listen_state(self.office_light_handle)
|
||||
|
||||
### {% linkable_title info_listen_state() %}
|
||||
|
||||
Get information on state a callback from it's handle.
|
||||
Get information on state a callback from its handle.
|
||||
|
||||
#### {% linkable_title Synopsis %}
|
||||
|
||||
@ -909,7 +909,7 @@ self.cancel_timer(handle)
|
||||
|
||||
### {% linkable_title info_timer() %}
|
||||
|
||||
Get information on a scheduler event from it's handle.
|
||||
Get information on a scheduler event from its handle.
|
||||
|
||||
#### {% linkable_title Synopsis %}
|
||||
|
||||
@ -944,7 +944,7 @@ All of the scheduler calls above support 2 additional optional arguments, `rando
|
||||
- `random_start` - start of range of the random time
|
||||
- `random_end` - end of range of the random time
|
||||
|
||||
`random_start` must always be numerically lower than `random_end`, they can be negative to denote a random offset before and event, or positive to denote a random offset after an event. The event would be a an absolute or relative time or sunrise/sunset depending on which scheduler call you use and these values affect the base time by the spcified amount. If not specified, they will default to `0`.
|
||||
`random_start` must always be numerically lower than `random_end`, they can be negative to denote a random offset before and event, or positive to denote a random offset after an event. The event would be an absolute or relative time or sunrise/sunset depending on which scheduler call you use and these values affect the base time by the spcified amount. If not specified, they will default to `0`.
|
||||
|
||||
For example:
|
||||
|
||||
@ -1463,7 +1463,7 @@ self.cancel_listen_event(handle)
|
||||
|
||||
### {% linkable_title info_listen_event() %}
|
||||
|
||||
Get information on an event callback from it's handle.
|
||||
Get information on an event callback from its handle.
|
||||
|
||||
#### {% linkable_title Synopsis %}
|
||||
|
||||
@ -1552,7 +1552,7 @@ The custom event `MODE_CHANGE` would be subscribed to with:
|
||||
self.listen_event(self.mode_event, "MODE_CHANGE")
|
||||
```
|
||||
|
||||
Home Assistant can send these events in a variety of other places - within automations, and also directly from Alexa intents. Home Assistant can also listen for custom events with it's automation component. This can be used to signal from AppDaemon code back to Home Assistant. Here is a sample automation:
|
||||
Home Assistant can send these events in a variety of other places - within automations, and also directly from Alexa intents. Home Assistant can also listen for custom events with its automation component. This can be used to signal from AppDaemon code back to Home Assistant. Here is a sample automation:
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
@ -2058,7 +2058,7 @@ OK, time travel sadly isn't really possible but it can be very useful when testi
|
||||
|
||||
### {% linkable_title Choosing a Start Time %}
|
||||
|
||||
Internally, AppDaemon keeps track of it's own time relative to when it was started. This make is possible to start AppDaemon with a different start time and date to the current time. For instance to test that sunset App, start AppDaemon at a time just before sunset and see if it works as expected. To do this, simply use the "-s" argument on AppDaemon's command line. e,g,:
|
||||
Internally, AppDaemon keeps track of its own time relative to when it was started. This make is possible to start AppDaemon with a different start time and date to the current time. For instance to test that sunset App, start AppDaemon at a time just before sunset and see if it works as expected. To do this, simply use the "-s" argument on AppDaemon's command line. e,g,:
|
||||
|
||||
```bash
|
||||
$ appdaemon -s "2016-06-06 19:16:00"
|
||||
|
||||
@ -10,4 +10,4 @@ footer: true
|
||||
redirect_from: /ecosystem/appdaemon/reboot/
|
||||
---
|
||||
|
||||
To run `AppDaemon` at reboot, I have provided a sample init script in the `./scripts` directory. These have been tested on a Raspberry PI - your mileage may vary on other systems. There is also a sample Systemd script.
|
||||
To run `AppDaemon` at reboot, I have provided a sample init script in the `./scripts` directory. These have been tested on a Raspberry Pi - your mileage may vary on other systems. There is also a sample Systemd script.
|
||||
|
||||
@ -23,14 +23,14 @@ So given the importance of Automation, what should Automation allow us to do? I
|
||||
- Is it open and expandable?
|
||||
- Does it run locally without any reliance on the cloud?
|
||||
|
||||
In my opinion, Home Assistant accomplishes the majority of these very well with a combination of Automations, Scripts and Templates, and it's Restful API.
|
||||
In my opinion, Home Assistant accomplishes the majority of these very well with a combination of Automations, Scripts and Templates, and its Restful API.
|
||||
|
||||
So why `AppDaemon`? AppDaemon is not meant to replace Home Assistant Automations and Scripts, rather complement them. For a lot of things, automations work well and can be very succinct. However, there is a class of more complex automations for which they become harder to use, and appdeamon then comes into its own. It brings quite a few things to the table:
|
||||
|
||||
- New paradigm - some problems require a procedural and/or iterative approach, and `AppDaemon` Apps are a much more natural fit for this. Recent enhancements to Home Assistant scripts and templates have made huge strides, but for the most complex scenarios, Apps can do things that Automations can't
|
||||
- Ease of use - AppDaemon's API is full of helper functions that make programming as easy and natural as possible. The functions and their operation are as "Pythonic" as possible, experienced Python programmers should feel right at home.
|
||||
- Reuse - write a piece of code once and instantiate it as an app as many times as you need with different parameters e.g. a motion light program that you can use in 5 different places around your home. The code stays the same, you just dynamically add new instances of it in the config file
|
||||
- Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to it's loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it and restart them to use the new code with out the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple apps and have them picked up dynamically, and for a final trick, removing or adding apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
|
||||
- Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to its loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it and restart them to use the new code with out the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple apps and have them picked up dynamically, and for a final trick, removing or adding apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
|
||||
- Complex logic - Python's If/Else constructs are clearer and easier to code for arbitrarily complex nested logic
|
||||
- Durable variables and state - variables can be kept between events to keep track of things like the number of times a motion sensor has been activated, or how long it has been since a door opened
|
||||
- All the power of Python - use any of Python's libraries, create your own modules, share variables, refactor and re-use code, create a single app to do everything, or multiple apps for individual tasks - nothing is off limits!
|
||||
|
||||
@ -103,7 +103,7 @@ Change below path to where you placed the `usb_backup.sh` and run the following
|
||||
|
||||
This does not automatically mount your USB drive at boot. You need to do that manually or add a line to your `/etc/fstab` file.
|
||||
|
||||
If your drive is on `/dev/sda1`, you could add a entry to your `/etc/fstab` like so:
|
||||
If your drive is on `/dev/sda1`, you could add an entry to your `/etc/fstab` like so:
|
||||
|
||||
```text
|
||||
/dev/sda1 /media ext4 defaults,noatime 0 1
|
||||
|
||||
@ -241,7 +241,7 @@ In cases where your ISP blocks port 80 you will need to change the port forward
|
||||
Now SSH in to the device your Home Assistant is running on.
|
||||
|
||||
<p class='note'>
|
||||
If you're running the 'standard' setup on a Raspberry Pi the chances are you just logged in as the 'pi' user. If not, you may have logged in as the Home Assistant user. There are commands below that require the Home Assistant user to be on the `sudoers` list. If you are not using the 'standard' pi setup it is presumed you will know how to get your Home Assistant user on the `sudoers` list before continuing. If you are running the 'standard' pi setup, from your 'pi' user issue the following command (where `hass` is the Home Assistant user):
|
||||
If you're running the 'standard' setup on a Raspberry Pi the chances are you just logged in as the 'pi' user. If not, you may have logged in as the Home Assistant user. There are commands below that require the Home Assistant user to be on the `sudoers` list. If you are not using the 'standard' Pi setup it is presumed you will know how to get your Home Assistant user on the `sudoers` list before continuing. If you are running the 'standard' Pi setup, from your 'pi' user issue the following command (where `hass` is the Home Assistant user):
|
||||
|
||||
```
|
||||
$ sudo adduser hass sudo
|
||||
|
||||
@ -39,4 +39,4 @@ HADashboard is a modular, skinnable dashboard for [Home Assistant](https://home-
|
||||
|
||||
|
||||
|
||||
For full installation instructions see the HADashboard section in the [AppDaemon Project Documentation](http://appdaemon.readthedocs.io/en/latest/DASHBOARD_INSTALL.html)
|
||||
For full installation instructions see the HADashboard section in the [AppDaemon Project Documentation](http://appdaemon.readthedocs.io/en/stable/DASHBOARD_INSTALL.html)
|
||||
|
||||
@ -109,7 +109,7 @@ Since the configurator script on its own is no service, you will have to take so
|
||||
|
||||
1. Fork the process into the background with the command:
|
||||
`nohup sudo ./configurator.py &`
|
||||
2. If your system is using systemd (that's usually what you'll find on a Raspberry PI), there's a [template file](https://github.com/danielperna84/hass-configurator/blob/master/hass-poc-configurator.systemd) you can use and then apply the same process to integrate it as mentioned in the [Home Assistant documentation](https://home-assistant.io/docs/autostart/systemd/). If you use this method you have to set the `BASEPATH` variable according to your environment.
|
||||
2. If your system is using systemd (that's usually what you'll find on a Raspberry Pi), there's a [template file](https://github.com/danielperna84/hass-configurator/blob/master/hass-poc-configurator.systemd) you can use and then apply the same process to integrate it as mentioned in the [Home Assistant documentation](https://home-assistant.io/docs/autostart/systemd/). If you use this method you have to set the `BASEPATH` variable according to your environment.
|
||||
3. If you have [supervisor](http://supervisord.org/) running on your system, [hass-poc-configurator.supervisor](https://github.com/danielperna84/hass-configurator/blob/master/hass-poc-configurator.supervisor) would be an example configuration you could use to control the configurator.
|
||||
4. A tool called [tmux](https://tmux.github.io/), which should be pre-installed with [HASSbian](https://home-assistant.io/docs/hassbian/).
|
||||
5. A tool called [screen](http://ss64.com/bash/screen.html) (alternative to tmux). If it's not already installed on your system, you can do `sudo apt-get install screen` or `sudo yum install screen` to get it. When it's installed, start a screen session by executing `screen`. Then navigate to your Home Assistant directory and start the configurator like described above. Put the screen session into the background by pressing `CTRL+A` and then `CTRL+D`. It is now safe to disconnect from your SSH session.
|
||||
|
||||
@ -28,8 +28,8 @@ Just follow the component pages for each on how to add them to your Home Assista
|
||||
|
||||
- [DHT Sensor](/components/sensor.dht/).
|
||||
- [Raspberry Pi Cover](/components/cover.rpi_gpio/).
|
||||
- [Raspberry PI GPIO Binary Sensor](/components/binary_sensor.rpi_gpio/).
|
||||
- [Raspberry PI GPIO Switch](/components/switch.rpi_gpio/).
|
||||
- [Raspberry Pi GPIO Binary Sensor](/components/binary_sensor.rpi_gpio/).
|
||||
- [Raspberry Pi GPIO Switch](/components/switch.rpi_gpio/).
|
||||
- [Raspberry Pi RF Switch](/components/switch.rpi_rf/).
|
||||
|
||||
### {% linkable_title Raspberry Pi Camera %}
|
||||
|
||||
@ -61,6 +61,8 @@ Create homeassistant config directory & switch to it
|
||||
|
||||
```bash
|
||||
# mkdir /volume1/homeassistant
|
||||
# chown /volume1/homeassistant homeassistant
|
||||
# chmod 755 /volume1/homeassistant
|
||||
# cd /volume1/homeassistant
|
||||
```
|
||||
Hint: alternatively you can also create a "Shared Folder" via Synology WebUI (e.g. via "File Station") - this has the advantage that the folder is visible via "File Station".
|
||||
@ -175,8 +177,8 @@ esac
|
||||
Create links to python folders to make things easier in the future:
|
||||
|
||||
```bash
|
||||
# ln -s /volume1/@appstore/py3k/usr/local/bin python3
|
||||
# ln -s /volume1/@appstore/py3k/usr/local/lib/python3.5/site-packages/homeassistant
|
||||
# ln -s /volume1/@appstore/py3k/usr/local/bin/python3 python3
|
||||
# ln -s /volume1/@appstore/py3k/usr/local/lib/python3.5/site-packages/homeassistant homeassistant
|
||||
```
|
||||
|
||||
Set the owner and permissions on your config folder
|
||||
|
||||
@ -51,6 +51,14 @@ The payload will be checked like an entry in your `configuration.yaml` file if a
|
||||
|
||||
The `<node_id>` level can be used by clients to only subscribe to their own (command) topics by using one wildcard topic like `<discovery_prefix>/+/<node_id>/+/set`.
|
||||
|
||||
### {% linkable_title Support by third-party tools %}
|
||||
|
||||
The following firmware for ESP8266, ESP32 and Sonoff unit has built-in support for MQTT discovery:
|
||||
|
||||
- [Sonoff-Tasmota](https://github.com/arendst/Sonoff-Tasmota) (starting with 5.11.1e)
|
||||
- [esphomelib](https://github.com/OttoWinter/esphomelib)
|
||||
- [ESPurna](https://github.com/xoseperez/espurna)
|
||||
|
||||
### {% linkable_title Examples %}
|
||||
|
||||
A motion detection device which can be represented by a [binary sensor](/components/binary_sensor.mqtt/) for your garden would sent its configuration as JSON payload to the Configuration topic. After the first message to `config`, then the MQTT messages sent to the state topic will update the state in Home Assistant.
|
||||
@ -93,3 +101,5 @@ Setting up a sensor with multiple measurement values requires multiple consecuti
|
||||
- Configuration topic no2: `homeassistant/sensor/sensorBedroomH/config`
|
||||
- Configuration payload no2: `{"device_class": "sensor", "name": "Humidity", "state_topic": "homeassistant/sensor/sensorBedroom/state", "unit_of_measurement": "%", "value_template": "{% raw %}{{ value_json.humidity}}{% endraw %}" }`
|
||||
- Common state payload: `{ "temperature": 23.20, "humidity": 43.70 }`
|
||||
|
||||
|
||||
|
||||
@ -139,7 +139,7 @@ event_data_template:
|
||||
|
||||
### {% linkable_title Raise and Consume Custom Events %}
|
||||
|
||||
The following automation shows how to raise a custom event called `event_light_turned_on` with `entity_id` as the event data. The action part could be inside a script or an automation.
|
||||
The following automation shows how to raise a custom event called `event_light_state_changed` with `entity_id` as the event data. The action part could be inside a script or an automation.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@ -155,7 +155,7 @@ The following automation shows how to raise a custom event called `event_light_t
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
The following automation shows how to capture the custom event `event_light_turned_on`, and retrieve corresponsing `entity_id` that was passed as the event data.
|
||||
The following automation shows how to capture the custom event `event_light_state_changed`, and retrieve corresponding `entity_id` that was passed as the event data.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
|
||||
20
source/_docs/tools/benchmark.markdown
Normal file
20
source/_docs/tools/benchmark.markdown
Normal file
@ -0,0 +1,20 @@
|
||||
---
|
||||
layout: page
|
||||
title: "benchmark"
|
||||
description: "Script to perform benchmarking of Home Assistant"
|
||||
release_date: 2017-02-23 11:00:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
redirect_from: /docs/tools/scripts/#benchmark
|
||||
---
|
||||
|
||||
For testing the performance of Home Assistant the Benchmark script runs until you exit using Control+C.
|
||||
|
||||
Firing and handling of a million events.
|
||||
|
||||
```bash
|
||||
$ hass --script benchmark async_million_events
|
||||
```
|
||||
|
||||
18
source/_docs/tools/check_config.markdown
Normal file
18
source/_docs/tools/check_config.markdown
Normal file
@ -0,0 +1,18 @@
|
||||
---
|
||||
layout: page
|
||||
title: "check_config"
|
||||
description: "Script to perform a check of the current configuration"
|
||||
release_date: 2017-02-23 11:00:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
redirect_from: /docs/tools/scripts/#configuration-check
|
||||
---
|
||||
|
||||
Test any changes to your `configuration.yaml` file before launching Home Assistant. This script allows you to test changes without the need to restart Home Assistant.
|
||||
|
||||
```bash
|
||||
$ hass --script check_config
|
||||
```
|
||||
|
||||
33
source/_docs/tools/credstash.markdown
Normal file
33
source/_docs/tools/credstash.markdown
Normal file
@ -0,0 +1,33 @@
|
||||
---
|
||||
layout: page
|
||||
title: "credstash"
|
||||
description: "Script to store credentials securely in AWS"
|
||||
release_date: 2017-02-23 11:00:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
redirect_from: /docs/configuration/secrets/#storing-passwords-securely-in-aws
|
||||
---
|
||||
|
||||
Using [Credstash](https://github.com/fugue/credstash) is an alternative way to `secrets.yaml`. They can be managed from the command line via the credstash script.
|
||||
|
||||
Before using credstash, you need to set up AWS credentials either via the `aws` command line tool or using environment variables as explained in the [AWS CLI docs](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) as well as creating a KMS key named `credstash` as explained in the [credstash Readme](https://github.com/fugue/credstash#setting-up-kms). After that is complete, you can use the provided script to add secrets to your Home Assistant secret store in credstash.
|
||||
|
||||
```bash
|
||||
$ hass --script credstash --help
|
||||
```
|
||||
|
||||
To store a password in credstash, replace your password or API key with `!secret` and an identifier in `configuration.yaml` file.
|
||||
|
||||
```yaml
|
||||
http:
|
||||
api_password: !secret http_password
|
||||
```
|
||||
|
||||
Create an entry in your credstash store.
|
||||
|
||||
```bash
|
||||
$ hass --script credstash set http_password
|
||||
```
|
||||
|
||||
72
source/_docs/tools/db_migrator.markdown
Normal file
72
source/_docs/tools/db_migrator.markdown
Normal file
@ -0,0 +1,72 @@
|
||||
---
|
||||
layout: page
|
||||
title: "db_migrator"
|
||||
description: "Script to migrate data in an InfluxDB database"
|
||||
release_date: 2017-02-23 11:00:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
redirect_from: /components/influxdb/#data-migration
|
||||
---
|
||||
|
||||
<p class='note warning'>
|
||||
This script was only use for 0.36 release cycle!
|
||||
</p>
|
||||
|
||||
Starting with 0.36 the [InfluxDB](omponents/influxdb/) component has a new schema to store values in the InfluxDB databases.
|
||||
|
||||
- There will no longer be any tags/fields named `time`.
|
||||
- All numeric fields (int/float/bool) will be stored as float inside InfluxDB database.
|
||||
- All string fields corresponding to state attributes will be renamed as `FIELDNAME_str`, where `FIELDNAME` is the state attribute, to avoid type conflicts.
|
||||
- All string fields corresponding to a state will be renamed as `state` (former value).
|
||||
- Fields named `value` will always be stored as float.
|
||||
- Fields named `state` will always be stored as string.
|
||||
|
||||
## {% linkable_title Migration script %}
|
||||
|
||||
If you need to migrate your database, you may require to run the `influxdb_migrator` script. Run the script after upgrade to 0.36 but before the first regular start of `hass` version 0.36.
|
||||
|
||||
These are the steps the script will perform:
|
||||
|
||||
1. Create a new database (called `DBNAME__old`) to store old data.
|
||||
2. Copy data from `DBNAME` database to `DBNAME__old` database.
|
||||
3. Empty `DBNAME` database (using `drop` then `create`). `DBNAME` database is now considered as the new database.
|
||||
4. For each measurement of `DBNAME__old` database:
|
||||
1. Read all points from the current measurement (in groups of 1000 points by default) and convert them.
|
||||
2. Send group of points to `DBNAME` database.
|
||||
5. Delete the `DBNAME__old` database if needed.
|
||||
|
||||
Example to run the script:
|
||||
|
||||
```bash
|
||||
$ hass --script influxdb_migrator \
|
||||
-H IP_INFLUXDB_HOST -u INFLUXDB_USERNAME -p INFLUXDB_PASSWORD \
|
||||
-d INFLUXDB_DB_NAME
|
||||
```
|
||||
Script arguments:
|
||||
|
||||
```
|
||||
required arguments:
|
||||
-d dbname, --dbname dbname InfluxDB database name
|
||||
|
||||
optional arguments:
|
||||
-h, --help show this help message and exit
|
||||
-H host, --host host InfluxDB host address
|
||||
-P port, --port port InfluxDB host port
|
||||
-u username, --username username
|
||||
InfluxDB username
|
||||
-p password, --password password
|
||||
InfluxDB password
|
||||
-s step, --step step How many points to migrate at the same time
|
||||
-o override_measurement, --override-measurement override_measurement
|
||||
Store all your points in the same measurement
|
||||
-D, --delete Delete old database
|
||||
```
|
||||
|
||||
- If you run the script with only the `-h` option, you will get a help printout with a short explanation of the different options.
|
||||
- The host option defaults to `'127.0.0.1'`.
|
||||
- The port option defaults to `8086`.
|
||||
- You should be able to omit username and password if InfluxDB authentication is disabled, which it is by default.
|
||||
- The step option defaults to `1000`.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user