diff --git a/_config.yml b/_config.yml index f8987527d79..868c6051c4d 100644 --- a/_config.yml +++ b/_config.yml @@ -139,12 +139,12 @@ social: # Home Assistant release details current_major_version: 0 -current_minor_version: 59 -current_patch_version: 2 -date_released: 2017-12-06 +current_minor_version: 60 +current_patch_version: 0 +date_released: 2017-12-17 # 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: "#release-0592---december-6" +patch_version_notes: "#" # Minor release (Example #release-0431---april-25): diff --git a/source/_components/ads.markdown b/source/_components/ads.markdown new file mode 100644 index 00000000000..cea2088d32e --- /dev/null +++ b/source/_components/ads.markdown @@ -0,0 +1,59 @@ +--- +layout: page +title: "ADS" +description: Connect Home Assistant to TwinCAT devices via the ADS interface +date: 2017-12-05 12:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: beckhoff.png +ha_category: Hub +ha_release: "0.60" +ha_iot_class: "Local Push" +--- + +The ADS (automation device specification) describes a device-independent and fieldbus independent interface for communication between [Beckhoff](https://www.beckhoff.com/) automation devices running [TwinCAT](http://www.beckhoff.hu/english.asp?twincat/default.htm) and other devices implementing this interface. + +To enable ADS, add the following lines to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +ads: + device: '127.0.0.1.1.1' + port: 48898 +``` + +{% configuration %} + device: + required: true + description: The AMS NetId that identifies the device. + type: string + port: + required: true + description: The port that runs the AMS server on the device, typically this would be 801 or 851. + type: int + ip_address: + required: false + description: The IP address of the ADS device, if not set the first 4 bytes of the device id will be used. + type: string +{% endconfiguration %} + +## {% linkable_title Service %} + +The ADS component will register the service `write_by_name` allowing you to write a value to a variable on your ADS device. + +```json +{ + "adsvar": ".myvariable", + "adstype": "int", + "value": 123 +} +``` + +Service parameters: + +- **adsvar**: Name of the variable on the ADS device. To access global variables on *TwinCAT2* use a prepending dot `.myvariable`, for TwinCAT3 use +`GBL.myvariable`. +- **adstype**: Specify the type of the variable. Use one of the following: `int`, `byte`, `uint`, `bool` +- **value**: The value that will be written in the variable. diff --git a/source/_components/alarm_control_panel.canary.markdown b/source/_components/alarm_control_panel.canary.markdown new file mode 100644 index 00000000000..59125f8746a --- /dev/null +++ b/source/_components/alarm_control_panel.canary.markdown @@ -0,0 +1,18 @@ +--- +layout: page +title: "Canary Alarm Control Panel" +description: "Instructions on how to integrate your Canary devices into Home Assistant." +date: 2017-12-07 22:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: canary.png +ha_category: Alarm +ha_release: "0.60" +ha_iot_class: "Cloud Polling" +--- + +The `canary` alarm control panel platform allows you to integrate your [Canary](https://canary.is) alarm system in Home Assistant. + +To add `canary` alarm control panel to your installation, follow instructions in [Canary component](/components/canary/). diff --git a/source/_components/alarm_control_panel.ialarm.markdown b/source/_components/alarm_control_panel.ialarm.markdown new file mode 100644 index 00000000000..9c58525fc62 --- /dev/null +++ b/source/_components/alarm_control_panel.ialarm.markdown @@ -0,0 +1,48 @@ +--- +layout: page +title: "Antifurto365 iAlarm Control Panel" +description: "Instructions how to integrate iAlarms alarms into Home Assistant." +date: 2017-11-30 20:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: antifurto365-ialarm.png +ha_category: Alarm +ha_release: "0.60" +--- + +The `ialarm` platform provides connectivity with the [Antifurto365](https://www.antifurtocasa365.it/) iAlarm alarm systems. + +This platform supports the following services: `alarm_arm_away`, `alarm_arm_home` and `alarm_disarm`. + +To enable this, add the following lines to your `configuration.yaml`: + +```yaml +# Example configuration.yaml entry +alarm_control_panel: + - platform: ialarm + host: ALARM_SYSTEM_IP + username: YOUR_USERNAME + password: YOUR_PASSWORD +``` + +{% configuration %} + host: + description: The IP address of the iAlarm device on your home network. + required: true + type: string + username: + description: Username used to sign into the iAlarm web client (should be admin by default). + required: true + type: string + password: + description: Password used to sign into the iAlarm web client. + required: true + type: string + name: + description: Name of device in Home Assistant. + required: false + type: string +{% endconfiguration %} + diff --git a/source/_components/alarm_control_panel.manual.markdown b/source/_components/alarm_control_panel.manual.markdown index 0bdb28cd801..86509ebe620 100644 --- a/source/_components/alarm_control_panel.manual.markdown +++ b/source/_components/alarm_control_panel.manual.markdown @@ -25,13 +25,62 @@ Configuration variables: - **name** (*Optional*): The name of the alarm. Default is "HA Alarm". - **code** (*Optional*): If defined, specifies a code to enable or disable the alarm in the frontend. -- **pending_time** (*Optional*): The time in seconds of the pending time before arming the alarm. Default is 60 seconds. +- **code_template** (*Optional*): If defined, returns a code to enable or disable the alarm in the frontend; an empty string disables checking the code. Inside the template, the variables **from_state** and **to_state** identify the current and desired state. Only one of **code** and **code_template** can be specified. +- **delay_time** (*Optional*): The time in seconds of the pending time before triggering the alarm. Default is 0 seconds. +- **pending_time** (*Optional*): The time in seconds of the pending time before effecting a state change. Default is 60 seconds. - **trigger_time** (*Optional*): The time in seconds of the trigger time in which the alarm is firing. Default is 120 seconds. - **disarm_after_trigger** (*Optional*): If true, the alarm will automatically disarm after it has been triggered instead of returning to the previous state. -- **armed_home/armed_away/armed_night/triggered** (*Optional*): State specific settings - - **pending_time**: State specific pending time override. +- **armed_custom_bypass/armed_home/armed_away/armed_night/disarmed/triggered** (*Optional*): State specific settings + - **delay_time** (*Optional*): State specific setting for **delay_time** (all states except **triggered**) + - **pending_time** (*Optional*): State specific setting for **pending_time** (all states except **disarmed**) + - **trigger_time** (*Optional*): State specific setting for **trigger_time** (all states except **triggered**) -In the config example below, armed_home state will have no pending time and triggered state will have pending time of 20 second whereas armed_away state will have a default pending time of 30 seconds. +## {% linkable_title State machine %} + +The state machine of the manual alarm component is complex but powerful. The +transitions are timed according to three values, **delay_time**, **pending_time** +and **trigger_time**. The values in turn can come from the default configuration +variable or from a state-specific override. + +When the alarm is armed, its state first goes to **pending** for a number +of seconds equal to the destination state's **pending_time**, and then +transitions to one of the "armed" states. Note that **code_template** +never receives "pending" in the **to_state** variable; instead, +**to_state** contains the state which the user has requested. However, +**from_state** *can* contain "pending". + +When the alarm is triggered, its state goes to **pending** for a number of +seconds equal to the previous state's **delay_time** plus the triggered +state's **pending_time**. Then the alarm transitions to the "triggered" +states. The code is never checked when triggering the alarm, so the +**to_state** variable of **code_template** cannot ever contain "triggered" +either; again, **from_state** *can* contain "triggered". + +The alarm remains in the "triggered" state for a number of seconds equal to the +previous state's **trigger_time**. Then, depending on **disarm_after_trigger**, +it goes back to either the previous state or **disarmed**. If the previous +state's **trigger_time** is zero, the transition to "triggered" is entirely +blocked and the alarm remains in the armed state. + +Each of the settings is useful in different scenarios. **pending_time** gives +you some time to leave the building (for "armed" states) or to disarm the alarm +(for the "triggered" state). + +**delay_time** can also be used to allow some time to disarm the alarm, but with +more flexibility. For example, you could specify a delay time for the +"armed away" state, in order to avoid triggering the alarm while the +garage door opens, but not for the "armed home" state. + +**trigger_time** is useful to disable the alarm when disarmed, but it can also +be used for example to sound the siren for a shorter time during the night. + +In the config example below: + +- the disarmed state never triggers the alarm; + +- the armed_home state will leave no time to leave the building or disarm the alarm; + +- while other states state will give 30 seconds to leave the building before triggering the alarm, and 20 seconds to disarm the alarm when coming back. ```yaml # Example configuration.yaml entry @@ -40,11 +89,13 @@ alarm_control_panel: name: Home Alarm code: 1234 pending_time: 30 + delay_time: 20 + trigger_time: 4 + disarmed: + trigger_time: 0 armed_home: pending_time: 0 - triggered: - pending_time: 20 - trigger_time: 4 + delay_time: 0 ``` ## {% linkable_title Examples %} diff --git a/source/_components/alarm_control_panel.manual_mqtt.markdown b/source/_components/alarm_control_panel.manual_mqtt.markdown index bf5ba5bdcc7..4f1f90995ce 100644 --- a/source/_components/alarm_control_panel.manual_mqtt.markdown +++ b/source/_components/alarm_control_panel.manual_mqtt.markdown @@ -42,15 +42,21 @@ alarm_control_panel: Configuration variables: -All configuration variables from the base manual alarm platform are available: +The following configuration variables from the base manual alarm platform are available: - **name** (*Optional*): The name of the alarm. Default is "HA Alarm". - **code** (*Optional*): If defined, specifies a code to enable or disable the alarm in the frontend. This code is not required for MQTT interactions. -- **pending_time** (*Optional*): The time in seconds of the pending time before arming the alarm. Default is 60 seconds. +- **code_template** (*Optional*): If defined, returns a code to enable or disable the alarm in the frontend; an empty string disables checking the code. Inside the template, the variables **from_state** and **to_state** identify the current and desired state. Only one of **code** and **code_template** can be specified. +- **delay_time** (*Optional*): The time in seconds of the pending time before triggering the alarm. Default is 0 seconds. +- **pending_time** (*Optional*): The time in seconds of the pending time before effecting a state change. Default is 60 seconds. - **trigger_time** (*Optional*): The time in seconds of the trigger time in which the alarm is firing. Default is 120 seconds. - **disarm_after_trigger** (*Optional*): If true, the alarm will automatically disarm after it has been triggered instead of returning to the previous state. -- **armed_home|armed_away|armed_night|triggered** (*Optional*): State specific settings - - **pending_time**: State specific pending time override. +- **armed_home/armed_away/armed_night/disarmed/triggered** (*Optional*): State specific settings + - **delay_time** (*Optional*): State specific setting for **delay_time** (all states except **triggered**) + - **pending_time** (*Optional*): State specific setting for **pending_time** (all states except **disarmed**) + - **trigger_time** (*Optional*): State specific setting for **trigger_time** (all states except **triggered**) + +See the documentation for the [manual alarm platform](../alarm_control_panel.manual/) for a description. Additionally, the following MQTT configuration variables are also available: @@ -62,7 +68,13 @@ Additionally, the following MQTT configuration variables are also available: - **payload_arm_away** (*Optional*): The payload to set armed-away mode on this Alarm Panel. Default is "ARM_AWAY". - **payload_arm_night** (*Optional*): The payload to set armed-night mode on this Alarm Panel. Default is "ARM_NIGHT". -In the config example below, armed_home state will have no pending time and triggered state will have a pending time of 20 seconds whereas armed_away state will have a default pending time of 30 seconds. +In the config example below: + +- the disarmed state never triggers the alarm; + +- the armed_home state will leave no time to leave the building or disarm the alarm; + +- while other states state will give 30 seconds to leave the building before triggering the alarm, and 20 seconds to disarm the alarm when coming back. ```yaml # Example configuration.yaml entry @@ -71,11 +83,13 @@ alarm_control_panel: state_topic: home/alarm command_topic: home/alarm/set pending_time: 30 + delay_time: 20 + trigger_time: 4 + disarmed: + trigger_time: 0 armed_home: pending_time: 0 - triggered: - pending_time: 20 - trigger_time: 4 + delay_time: 0 ``` ## {% linkable_title Examples %} diff --git a/source/_components/alexa.markdown b/source/_components/alexa.markdown index bccf44f2e77..6b1347a386e 100644 --- a/source/_components/alexa.markdown +++ b/source/_components/alexa.markdown @@ -10,9 +10,13 @@ footer: true logo: amazon-echo.png ha_category: Voice featured: true -ha_release: 0.10 +ha_release: '0.10' --- +
+ Use [Home Assistant Cloud](/components/cloud/) to integrate with Alexa without any effort. +
+ There are a few ways that you can use Amazon Echo and Home Assistant together. - [Build custom commands to use](#i-want-to-build-custom-commands-to-use-with-echo) @@ -325,7 +329,7 @@ Please refer to the [Amazon documentation][flash-briefing-api-docs] for more inf - All other settings are up to you - Hit "Next" - Test - - Having passed all validations to reach this screen, you can now click on "< Back to All Skills" as your flash briefing is now available as in "Development" service. + - Having passed all validations to reach this screen, you can now click on "< Back to All Skills" as your flash briefing is now available as in "Development" service. - To invoke your flash briefing, open the Alexa app on your phone or go to the [Alexa Settings Site][alexa-settings-site], open the "Skills" configuration section, select "Your Skills", scroll to the bottom, tap on the Flash Briefing Skill you just created, enable it, then manage Flash Briefing and adjust ordering as necessary. Finally ask your Echo for your "news","flash briefing", or "briefing". [amazon-dev-console]: https://developer.amazon.com diff --git a/source/_components/binary_sensor.ads.markdown b/source/_components/binary_sensor.ads.markdown new file mode 100644 index 00000000000..753858d9737 --- /dev/null +++ b/source/_components/binary_sensor.ads.markdown @@ -0,0 +1,41 @@ +--- +layout: page +title: "ADS Binary Sensor" +description: "Instructions on how to set up ADS binary sensors within Home Assistant." +date: 2017-10-25 10:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: beckhoff.png +ha_category: Binary Sensor +ha_release: "0.60" +ha_iot_class: "Local Push" +--- + +The `ads` binary sensor platform can be used to monitor a boolean value on your ADS device. + +To use your ADS device, you first have to set up your [ADS hub](/components/ads/) and then add the following to your `configuration.yaml` +file: + +```yaml +# Example configuration.yaml entry +binary_sensor: + - platform: ads + adsvar: .boolean1 +``` + +{% configuration %} + adsvar: + required: true + description: The name of the variable which you want to access on the ADS device. + type: string + name: + required: false + description: An identifier for the light in the frontend. + type: string + device_class: + required: false + description: The [type/class](/components/binary_sensor/) of the sensor to set the icon in the frontend. + type: string +{% endconfiguration %} diff --git a/source/_components/binary_sensor.markdown b/source/_components/binary_sensor.markdown index c25e0fb6b60..6b6d1d8c5d3 100644 --- a/source/_components/binary_sensor.markdown +++ b/source/_components/binary_sensor.markdown @@ -28,6 +28,7 @@ The way these sensors are displayed in the frontend can be modified in the [cust - **plug**: `On` means device is plugged in, `Off` means device is unplugged - **power**: Power, over-current, etc. - **presence**: `On` means Home, `Off` means Away +- **problem**: `On` means a problem was detected, `Off` means the status is OK - **safety**: `On` means unsafe, `Off` means safe - **smoke**: `On` means smoke detected - **sound**: `On` means sound detected, `Off` means no sound diff --git a/source/_components/calendar.caldav.markdown b/source/_components/calendar.caldav.markdown new file mode 100644 index 00000000000..c8f4b973489 --- /dev/null +++ b/source/_components/calendar.caldav.markdown @@ -0,0 +1,104 @@ +--- +layout: page +title: "CalDav" +description: "Instructions on how to integrate a WebDav calendar into Home Assistant." +date: 2017-11-27 23:14 +sidebar: true +comments: false +sharing: true +footer: true +ha_category: Calendar +ha_iot_class: "Cloud Polling" +ha_release: "0.60" +--- + + +The `caldav` platform allows you to connect to your WebDav calendar and generate binary sensors. A different sensor will be created for each individual calendar, or you can specify custom calendars which match a criteria you define (more on that below). These sensors will be `on` if you have an on going event in that calendar or `off` if the event is later in time, or if there is no event at all. The WebDav calendar get updated roughly every 10 minutes. + +### {% linkable_title Prerequisites %} + +You need to have a CalDav server and eventually credentials for it. This component was tested against [Baikal](http://sabre.io/baikal/) but any component complying with the RFC4791 should work. + +You might need some additional system packages to compile the Python caldav library. On a Debian based system, install them by: + +```bash +$ sudo apt-get install libxm2-dev libxslt1-dev zlib1g-dev +``` + +### {% linkable_title Basic Setup %} + +To integrate a WebDav calendar in Home Assistant, add the following section to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +calendar: + - platform: caldav + url: https://baikal.my-server.net/cal.php/calendars/john.doe@test.com/default +``` + +{% configuration %} +url: + required: true + description: The full URL to your calendars. + type: string +username: + required: false + description: Username for authentication. + type: string +password: + required: false + description: Password for authentication. + type: string +calendars: + required: false + description: List of the calendars to filter. Empty or absent means no filtering. + type: list +custom_calendars: + required: false + description: Details on any custom binary sensor calendars you want to create. + type: list + keys: + name: + required: true + description: The name of your custom calendar. + type: string + calendar: + required: true + description: The source calendar to search on. + type: string + search: + required: true + pending_charges: Regular expression for filtering the events + type: string + all_day: + required: false + description: Include events that last the whole day. + type: boolean + default: true +{% endconfiguration %} + + +### {% linkable_title Sensor attributes %} + + - **offset_reached**: If set in the event title and parsed out will be on/off once the offset in the title in minutes is reached. So the title Very important meeting !!-10 would trigger this attribute to be on 10 minutes before the event starts. + - **all_day**: `True/False` if this is an all day event. Will be `False` if there is no event found. + - **message**: The event title with the `search` values extracted. So in the above example for `offset_reached` the message would be set to Very important meeting + - **description**: The event description. + - **location**: The event Location. + - **start_time**: Start time of event. + - **end_time**: End time of event. + +### {% linkable_title Sensor attributes %} + +```yaml +# Example configuration.yaml entry +calendar: + - platform: caldav + url: https://baikal.my-server.net/cal.php/calendars/john.doe@test.com/default + username: john.doe@test.com + password: !secret caldav + custom_calendars: + - name: 'HomeOffice' + calendar: 'Agenda' + search: 'HomeOffice' +``` diff --git a/source/_components/camera.canary.markdown b/source/_components/camera.canary.markdown new file mode 100644 index 00000000000..bf7c029bc73 --- /dev/null +++ b/source/_components/camera.canary.markdown @@ -0,0 +1,18 @@ +--- +layout: page +title: "Canary Camera" +description: "Instructions on how to integrate your Canary devices into Home Assistant." +date: 2017-12-07 22:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: canary.png +ha_category: Camera +ha_release: "0.60" +ha_iot_class: "Cloud Polling" +--- + +The `canary` camera platform allows you to view the latest camera image (triggered by motion) by your [Canary](https://canary.is) device in Home Assistant. + +To add `canary` camera to your installation, follow instructions in [Canary component](/components/canary/). diff --git a/source/_components/canary.markdown b/source/_components/canary.markdown new file mode 100644 index 00000000000..425055f48a4 --- /dev/null +++ b/source/_components/canary.markdown @@ -0,0 +1,53 @@ +--- +layout: page +title: "Canary" +description: "Instructions on how to integrate your Canary devices into Home Assistant." +date: 2017-12-07 22:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: canary.png +ha_category: Hub +ha_release: "0.60" +ha_iot_class: "Cloud Polling" +--- + +The `canary` component allows you to integrate your [Canary](https://canary.is) devices in Home Assistant. + +You will need your Canary login information (username, usually your email address, and password) to use this module. + +To set it up, add the following to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +canary: + username: you@example.com + password: secret +``` + +{% configuration %} + username: + description: The username for accessing your Canary account. + required: true + type: string + password: + description: The password for accessing your Canary account. + required: true + type: string + timeout: + description: Timeout to wait for connections. + required: false + type: int + default: 10 +{% endconfiguration %} + + + +Once loaded, your front end will have the following components: + +* A camera image triggered by motion for each camera. +* An alarm control panel for each location. +* A sensor per camera that reports temperature. +* A sensor per camera that reports humidity. +* A sensor per camera that reports air quality. diff --git a/source/_components/climate.generic_thermostat.markdown b/source/_components/climate.generic_thermostat.markdown index 8b11055f3a1..180f67f04e7 100644 --- a/source/_components/climate.generic_thermostat.markdown +++ b/source/_components/climate.generic_thermostat.markdown @@ -38,6 +38,7 @@ Configuration variables: - **cold_tolerance** (*Optional*): Set a minimum amount of difference between the temperature read by the sensor specified in the *target_sensor* option and the target temperature that must change prior to being switched on. For example, if the target temperature is 25 and the tolerance is 0.5 the heater will start when the sensor equals or goes below 24.5. - **hot_tolerance** (*Optional*): Set a minimum amount of difference between the temperature read by the sensor specified in the *target_sensor* option and the target temperature that must change prior to being switched off. For example, if the target temperature is 25 and the tolerance is 0.5 the heater will stop when the sensor equals or goes above 25.5. - **keep_alive** (*Optional*): Set a keep-alive interval. If set, the switch specified in the *heater* option will be triggered every time the interval elapses. Use with heaters and A/C units that shut off if they don't receive a signal from their remote for a while. +- **initial_operation_mode** (*Optional*): Set the initial operation mode. Valid values are `off` or `auto`. Value has to be double quoted. If this parameter is not set, it is preferable to set a *keep_alive* value. This is helpful to align any discrepancies between *generic_thermostat* and *heater* state. A full configuration example looks like the one below. `min_cycle_duration` and `keep_alive` must contain at least one of the following entries: `days:`, `hours:`, `minutes:`, `seconds:` or `milliseconds:`. @@ -57,4 +58,5 @@ climate: seconds: 5 keep_alive: minutes: 3 + initial_operation_mode: "off" ``` diff --git a/source/_components/cloud.markdown b/source/_components/cloud.markdown index 19541d18047..7349bdc253c 100644 --- a/source/_components/cloud.markdown +++ b/source/_components/cloud.markdown @@ -8,16 +8,19 @@ comments: false sharing: true footer: true logo: home-assistant.png -ha_release: 0.57 +ha_release: 0.60 +ha_category: Voice +ha_iot_class: "Cloud Push" --- --Home Assistant Cloud is currently in private beta. -
+The Home Assistant Cloud allows you to quickly integrate your local Home Assistant with various cloud services. Any processing of services from other cloud services is handled by your local Home Assistant. -The Home Assistant Cloud allows you to quickly integrate your local instance with various cloud services. Any processing of services from other cloud services is handled by your local instance. +```yaml +# Example configuration.yaml entry to enable the cloud component +cloud: +``` -To get started, create an account and log in via the configuration panel in your Home Assistant instance. There is no need to configure your router or expose your instance to the internet in any other way. +Once activated, go to the configuration panel in Home Assistant and create an account and log in. There is no need to configure your router or expose your instance to the internet in any other way. ### {% linkable_title Amazon Alexa %} diff --git a/source/_components/cover.garadget.markdown b/source/_components/cover.garadget.markdown index 1d34384fffa..6ae25d44e8e 100644 --- a/source/_components/cover.garadget.markdown +++ b/source/_components/cover.garadget.markdown @@ -98,3 +98,17 @@ logbook: - sensor.garage_door_time_in_state - sensor.garage_door_wifi_signal_strength ``` + +As of firmware release 1.17 the garadget device has native support for MQTT. The options allow the end-user to configure the device in the following ways 'cloud only', 'cloud and MQTT' or 'MQTT only'. + +For configuration of the garadget as a MQTT cover: + +```yaml +cover: + - platform: mqtt + name: "Garage Door" + command_topic: "garadget/device_name/command" + state_topic: "garadget/device_name/status" + payload_open: "open" + payload_close: "close" +``` diff --git a/source/_components/cover.tellstick.markdown b/source/_components/cover.tellstick.markdown new file mode 100644 index 00000000000..2008ef2a73d --- /dev/null +++ b/source/_components/cover.tellstick.markdown @@ -0,0 +1,25 @@ +--- +layout: page +title: "TellStick Cover" +description: "Instructions how to integrate TellStick covers into Home Assistant." +date: 2017-11-29 16:23 +sidebar: true +comments: false +sharing: true +footer: true +logo: telldus_tellstick.png +ha_category: Cover +ha_iot_class: "Assumed State" +ha_release: "0.60" +--- + + +This `tellstick` cover platform allows you to control your [TellStick](http://www.telldus.se/products/tellstick) covers. + +To use your TellStick device, you first have to set up your [Tellstick hub](/components/tellstick/) and then add the following to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +cover: + - platform: tellstick +``` diff --git a/source/_components/device_tracker.markdown b/source/_components/device_tracker.markdown index 105dec1e7f3..ece347286a7 100644 --- a/source/_components/device_tracker.markdown +++ b/source/_components/device_tracker.markdown @@ -26,15 +26,19 @@ device_tracker: host: 192.168.1.1 username: admin password: YOUR_PASSWORD + new_device_defaults: + track_new_devices: True + hide_if_away: False + ``` The following optional parameters can be used with any platform. However device tracker will only look for global settings under the configuration of the first configured platform: | Parameter | Default | Description | -|---------------------|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `track_new_devices` | True | If new discovered devices are tracked by default | -| `interval_seconds` | 12 | Seconds between each scan for new devices | -| `consider_home` | 180 | Seconds to wait till marking someone as not home after not being seen. This parameter is most useful for households with Apple iOS devices that go into sleep mode while still at home to conserve battery life. iPhones will occasionally drop off the network and then re-appear. `consider_home` helps prevent false alarms in presence detection when using IP scanners such as Nmap. `consider_home` accepts various time representations, (E.g. the following all represents 3 minutes: `180`, `0:03`, `0:03:00`) | +|----------------------|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `interval_seconds` | 12 | Seconds between each scan for new devices | +| `consider_home` | 180 | Seconds to wait till marking someone as not home after not being seen. This parameter is most useful for households with Apple iOS devices that go into sleep mode while still at home to conserve battery life. iPhones will occasionally drop off the network and then re-appear. `consider_home` helps prevent false alarms in presence detection when using IP scanners such as Nmap. `consider_home` accepts various time representations, (E.g. the following all represents 3 minutes: `180`, `0:03`, `0:03:00`) | +| `new_device_defaults`| | Default values for new discovered devices. Available options `track_new_devices` (default: `True`), `hide_if_away` (default: `False`) | The extended example from above would look like the following sample: diff --git a/source/_components/device_tracker.meraki.markdown b/source/_components/device_tracker.meraki.markdown new file mode 100644 index 00000000000..dae482748fd --- /dev/null +++ b/source/_components/device_tracker.meraki.markdown @@ -0,0 +1,37 @@ +--- +layout: page +title: "Meraki" +description: "Instructions on how to integrate Meraki-based presence detection into Home Assistant." +date: 2017-11-22 08:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: meraki.png +ha_category: Presence Detection +ha_release: "0.60" +--- +Use your `Meraki AP` as device tracker. Note that Meraki will see all devices, not only connected to the network. +Follow instructions [here](https://meraki.cisco.com/technologies/location-analytics-api) how to enable Location Analytics. + +After you configure access to the Meraki CMX API, add the following to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +device_tracker: + - platform: meraki + secret: your_secert + validator: meraki_validator +``` + + +{% configuration %} + secret: + description: Secret code added in Meraki + required: true + type: string + validator: + description: Validation string from Meraki + required: true + type: string +{% endconfiguration %} diff --git a/source/_components/frontend.markdown b/source/_components/frontend.markdown index aa7f0cb9263..92c0e8d8dd4 100644 --- a/source/_components/frontend.markdown +++ b/source/_components/frontend.markdown @@ -23,7 +23,7 @@ frontend: description: "Version of the JavaScript to serve to clients. Options: `es5` - transpiled so old browsers understand it. `latest` - not transpiled, so will work on recent browsers only. `auto` - select a version according to the browser user-agent. The value in the config can be overiden by putting `es5` or `latest` in the URL. For example `http://localhost:8123/states?es5` " required: false type: string - default: es5 + default: auto themes: description: Allow to define different themes. See below for further details. required: false diff --git a/source/_components/homematic.markdown b/source/_components/homematic.markdown index 93cf903eb44..73287f74209 100644 --- a/source/_components/homematic.markdown +++ b/source/_components/homematic.markdown @@ -28,58 +28,69 @@ To set up the component, add the following information to your `configuration.ya ```yaml homematic: - hosts: + interfaces: wireless: - ip: 127.0.0.1 + host: 127.0.0.1 ``` Configuration variables (global): -- **hosts** (*Required*): Configuration for each host to integrate into Home Assistant. +- **interfaces** (*Required*): Configuration for each XML-RPC interface to integrate into Home Assistant. +- **hosts** (*Optional*): Configuration for each Hub (CCU/Homegear) to integrate into Home Assistant. - **local_ip** (*Optional*): IP of device running Home Assistant. Override auto-detected value for exotic network setups. - **local_port** (*Optional*): Port for connection with Home Assistant. By default it is randomly assigned. -Configuration variables (host): +Configuration variables (interface): -- **ip** (*Required*): IP address of CCU/Homegear device. +- **host** (*Required*): IP address or Hostname of CCU/Homegear device or Hass.io add-on. - **port** (*Optional*): Port of CCU/Homegear XML-RPC Server. Wireless: 2001, wired: 2000, IP: 2010, thermostatgroups: 9292. - **callback_ip** (*Optional*): Set this, if Home Assistant is reachable under a different IP from the CCU (NAT, Docker etc.). - **callback_port** (*Optional*): Set this, if Home Assistant is reachable under a different port from the CCU (NAT, Docker etc.). - **resolvenames** (*Optional*): [`metadata`, `json`, `xml`] Try to fetch device names. Defaults to `false` if not specified. - **username** (*Optional*): When fetching names via JSON-RPC, you need to specify a user with guest-access to the CCU. - **password** (*Optional*): When fetching names via JSON-RPC, you need to specify the password of the user you have configured above. -- **primary** (*Optional*): Set to `true` when using multiple hosts and this host should provide the services and variables. -- **variables** (*Optional*): Set to `true` if you want to use CCU2/Homegear variables. Should only be enabled for the primary host. When using a CCU credentials are required. - **path** (*Optional*): Set to `/groups` when using port 9292. +Configuration variables (host): + +- **host** (*Required*): IP address of CCU/Homegear device. +- **username** (*Optional*): When fetching names via JSON-RPC, you need to specify a user with guest-access to the CCU. +- **password** (*Optional*): When fetching names via JSON-RPC, you need to specify the password of the user you have configured above. + #### Example configuration with multiple protocols and some other options set: ```yaml homematic: - hosts: + interfaces: rf: - ip: 127.0.0.1 + host: 127.0.0.1 resolvenames: json username: Admin password: secret primary: true variables: true wired: - ip: 127.0.0.1 + host: 127.0.0.1 port: 2000 resolvenames: json username: Admin password: secret ip: - ip: 127.0.0.1 + host: 127.0.0.1 port: 2010 groups: - ip: 127.0.0.1 + host: 127.0.0.1 port: 9292 resolvenames: json username: Admin password: secret path: /groups + hosts: + ccu2: + host: 127.0.0.1 + username: Admin + password: secret + ``` ### {% linkable_title The `resolvenames` option %} @@ -115,7 +126,7 @@ sensor: ### {% linkable_title Variables %} It is possible to read and set values of system variables you have setup on the CCU/Homegear. The supported types for setting values are float- and bool-variables. -The states of the variables are available through the attributes of your hub entity (e.g. `homematic.rf`). Use templates (as mentioned above) to make your variables available to automations or as entities. +The states of the variables are available through the attributes of your hub entity (e.g. `homematic.ccu2`). Use templates (as mentioned above) to make your variables available to automations or as entities. The values of variables are polled from the CCU/Homegear in an interval of 30 seconds. Setting the value of a variable happens instantly and is directly pushed. ### {% linkable_title Events %} @@ -154,8 +165,8 @@ The name depends on if you chose to resolve names or not. If not, it will be the * *homematic.virtualkey*: Simulate a keypress (or other valid action) on CCU/Homegear with device or virtual keys. * *homematic.reconnect*: Reconnect to CCU/Homegear without restarting Home Assistant (useful when CCU has been restarted) -* *homematic.set_var_value*: Set the value of a system variable. -* *homematic.set_dev_value*: Control a device manually (even devices without support). Equivalent to setValue-method from XML-RPC. +* *homematic.set_variable_value*: Set the value of a system variable. +* *homematic.set_device_value*: Control a device manually (even devices without support). Equivalent to setValue-method from XML-RPC. #### {% linkable_title Examples %} Simulate a button being pressed @@ -184,9 +195,9 @@ Set boolean variable to true ```yaml ... action: - service: homematic.set_var_value + service: homematic.set_variable_value data: - entity_id: homematic.rf + entity_id: homematic.ccu2 name: Variablename value: true ``` @@ -200,7 +211,7 @@ Manually turn on a switch actor ```yaml ... action: - service: homematic.set_dev_value + service: homematic.set_device_value data: address: LEQ1234567 channel: 1 @@ -212,7 +223,7 @@ Manually set temperature on thermostat ```yaml ... action: - service: homematic.set_dev_value + service: homematic.set_device_value data: address: LEQ1234567 channel: 4 diff --git a/source/_components/hue.markdown b/source/_components/hue.markdown new file mode 100644 index 00000000000..8fda3584311 --- /dev/null +++ b/source/_components/hue.markdown @@ -0,0 +1,145 @@ +--- +layout: page +title: "Philips Hue" +description: "Instructions on setting up Philips Hue within Home Assistant." +date: 2017-11-29 23:51 +sidebar: true +comments: false +sharing: true +footer: true +logo: philips_hue.png +ha_category: Hub +ha_iot_class: "Local Polling" +featured: true +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/). + +Once discovered, if you have a custom default view, locate `configurator.philips_hue` in the entities list ( < > ) and add it to a group in `configuration.yaml`. Restart Home Assistant so that the configurator is visible in the Home Assistant dashboard. Once Home Assistant is restarted, locate and click on `configurator.philips_hue` to bring up the initiation dialog. This will prompt you to press the Hue button to register the Hue hub in Home Assistant. Once complete, the configurator entity isn't needed anymore and can be removed from any visible group in `configuration.yaml`. + +When you configure the Hue bridge from Home Assistant, it writes a token to a file in your Home Assistant [configuration directory](/docs/configuration/). That token authenticates the communication with the Hue bridge. This token uses the Address of the Hue Bridge. If the IP address for the Hue Bridge changes, you will need to register the Hue Bridge with Home Assistant again. To avoid this you may set up DHCP registration for your Hue Bridge, so that it always has the same IP address. + +Once registration is complete you should see the Hue lights listed as "light" entities; if you don't you may have to restart Home Assistant once more. Add these light entities to configuration.yaml and restart Home Assistant once more to complete the installation. + +If you want to enable the component without relying on the [discovery component](/components/discovery/), add the following lines to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +hue: + bridges: + - host: DEVICE_IP_ADDRESS +``` + +Configuration variables: + +- **host** (*Optional*): IP address of the device, eg. 192.168.1.10. Required if not using the `discovery` component to discover Hue bridges. +- **allow_unreachable** (*Optional*): (true/false) This will allow unreachable bulbs to report their state correctly. +- **filename** (*Optional*): Make this unique if specifying multiple Hue hubs. +- **allow_in_emulated_hue** (*Optional*): )true/false) Enable this to block all Hue entities from being added to the `emulated_hue` component. +- **allow_hue_groups** (*Optional*): (true/false) Enable this to stop Home Assistant from importing the groups defined on the Hue bridge. + +### {% linkable_title Migrating from older configuration %} + +In previous versions of the Hue component the configuration looked different: + +```yaml +# Example configuration.yaml entry +light: + - platform: hue + host: DEVICE_IP_ADDRESS +``` + +You will need to convert each bridge into an entry in the new configuration style. See above for an example. + +### {% 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. + +Add `filename` to your Hue configuration entry in your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +hue: + bridges: + - host: BRIDGE1_IP_ADDRESS + filename: phue.conf + - platform: hue + host: BRIDGE2_IP_ADDRESS + filename: phue2.conf +``` + +### {% linkable_title Using Hue Groups in Home Assistant %} + +The Hue API allows you to group lights. Home Assistant also supports grouping of entities natively, but sometimes it can be useful to use Hue Groups to group light bulbs. By doing so, Home Assistant only needs to send one API call to change the state of all the bulbs in those groups instead of one call for every light in the group. This causes all the bulbs to change state simultaneously. + +These Hue Groups can be a `Luminaire`, `Lightsource`, `LightGroup` or `Room`. The `Luminaire` and `Lightsource` can't be created manually since the Hue bridge manages these automatically based on the discovered bulbs. The `Room` and `LightGroup` can be created manually through the API, or the mobile app. A bulb can only exist in one `Room`, but can exist in multiple `LightGroup`. The `LightGroup` can be useful to link certain bulbs together since. + +The 2nd generation Hue app only allows to create a `Room`. You need to use the first generation app or the API to create a `LightGroup`. + +Example: + +To create a `LightGroup` named `Ceiling lights` that contains the lights 1, 2 and 3, execute the following command: + +```bash +$ curl -XPOST -d '{"name": "Ceiling lights", "lights": ["1", "2", "3"]}' http://+ To support Hue Light Groups, your bridge needs to have at least firmware 1.13 (released on June 3, 2016). +
+ +More information can be found on the [Philips Hue API documentation](https://www.developers.meethue.com/documentation/groups-api#22_create_group) website. + + +### {% 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. + +To avoid user interface overload we don't expose scenes directly. Instead there is a [light.hue_activate_scene](/components/light/#service-lighthue_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. + +For instance: + +```yaml +script: + porch_on: + sequence: + - service: light.hue_activate_scene + data: + group_name: "Porch" + scene_name: "Porch Orange" +``` + +| Service data attribute | Optional | Description | +| ---------------------- | -------- | ----------- | +| `group_name` | no | The group/room name of the lights. Find this in the Hue official app. +| `scene_name` | no | The name of the scene. Find this in the Hue official app. + +*Note*: `group_name` is not linked to Home Assistant group name. + +*** Finding Group and Scene Names *** + +How do you find these names? + +The easiest way to do this is only use the scenes from the 2nd generation Hue app. That is organized by room (group) and scene Name. Use the values of room name and scene name that you see in the app. You can test these work on the `dev-service` console of your Home Assistant instance. + +Alternatively, you can dump all rooms and scene names using this [gist](https://gist.github.com/sdague/5479b632e0fce931951c0636c39a9578). This does **not** tell you which groups and scenes work together but it's sufficient to get values that you can test in the `dev-service` console. + +*** Caveats *** + +The Hue API doesn't activate scenes directly, only on a Hue Group (typically rooms, especially if using the 2nd gen app). But Hue Scenes don't actually reference their group. So heuristic matching is used. + +Neither group names or scene names are guaranteed unique in Hue. If you are getting non deterministic behavior, adjust your Hue scenes via the App to be more identifying. + +The Hue hub has limited spaces for scenes, and will delete scenes if new ones get created that would overflow that space. The API docs say this is based on "Least Recently Used". diff --git a/source/_components/isy994.markdown b/source/_components/isy994.markdown index 8cf050f2383..0b59c64b24e 100644 --- a/source/_components/isy994.markdown +++ b/source/_components/isy994.markdown @@ -34,12 +34,54 @@ Configuration variables: - **host** (*Required*): The host entry should be in full URL format, eg. http://192.168.10.100:80 - **username** (*Required*): The username that used to access the ISY interface. - **password** (*Required*): The password that used to access the ISY interface. -- **sensor_string** (*Optional*): This is the string that is used to identify which devices are to be assumed to be sensors instead of lights of switches. By default, this string is 'sensor'. If this string is found in the device name or folder, Home Assistant will assume it is as a sensor or binary sensor (if the device has on/off or true/false states). +- **sensor_string** (*Optional*): This is the string that is used to identify which devices are to be assumed to be sensors instead of lights of switches. By default, this string is 'sensor'. If this string is found in the device name or folder, Home Assistant will assume it is as a sensor or binary sensor (if the device has on/off or true/false states). This is only necessary for nodes that are not automatically detected as sensors by Home Assistant. Insteon door, window, motion and leak sensors should all be detected automatically. - **hidden_string** (*Optional*): The HIDDEN_STRING is a string that is used to identify which devices are to be hidden on Home Assistant's front page. This string will be stripped from the device's name before being used. By default, this value is '{HIDE ME}'. - **tls** (*Optional*): This entry should reflect the version of TLS that the ISY controller is using for HTTPS encryption. This value can be either 1.1 or 1.2. If this value is not set, it is assumed to be version 1.1. This is the default for most users. ISY994 Pro users may likely be using 1.2. When using HTTPS in the host entry, it is best practice to set this value. Once the ISY controller is configured, it will automatically import any binary sensors, covers, fans, lights, locks, sensors and switches it can locate. +### {% linkable_title Sensors %} + +An Insteon door/window sensor will show up as a single Binary Sensor rather than two discrete devices like it does in the ISY994 admin panel. Note that when in "Two Nodes" mode, the sensor will have an UNKNOWN state until the sensor changes for the first time since the last Home Assistant reboot. If you do not use Insteon scenes that are controlled directly from the door sensor, you may prefer to set the sensor to "One Node" mode using the ISY Admin Panel. + +Each Insteon leak sensor will also show up as a single Binary Sensor as opposed to the two nodes seen in the ISY994. The name of the device will be based on what the parent node is named in the ISY994, which is typically the one with "-Dry" at the end of the name. This may be confusing, because "On" means wet in Home Assistant. You can rename this node either in the ISY994 Admin Panel (which will change the entity_id in Home Assistant) or assign a `friendly_name` in the [Customization section](https://home-assistant.io/docs/configuration/customizing-devices/) of your configuration. + +If your leak or door/window sensor supports heartbeats, a new binary_sensor device will be added to Home Assistant to represent the battery state. The sensor will stay "Off" so long as the daily heartbeats occur. If a heartbeat is missed, the sensor will flip to "On". The name of this device will be based on the heartbeat node in the ISY. + +### {% linkable_title Handling Insteon Control Events %} + +A Home Assistant `isy994_control` event is emitted for every "control" event in the Insteon network. This allows you to write automations that trigger based on Insteon button presses. You can also trigger off of the unique Insteon events, such as double-presses, long-holds etc. + +```yaml +automation: + - alias: turn off living room on double tap lightswitch + trigger: + platform: event + event_type: isy994_control + event_data: + entity_id: light.lr_track_lights_front + control: 'DFOF' + action: + service: light.turn_off + entity_id: light.lr_track_lights_rear +``` + +All `isy994_control` events will have an `entity_id` and `control` parameter in its `event_data`. You'll need to refer to ISY994 documentation for the list of every possible control type, but the common ones are: + +- `DON`: On button +- `DOF`: Off button +- `DFON`: "Fast On", usually from double-tapping an On button +- `DFOF`: "Fast Off", usually from double-tapping an Off button +- `FDUP`: "Fade Up", usually while holding down an On button +- `FDDOWN`: "Fade Down", usually while holding down an Off button +- `FDSTOP`: "Fade Stop", when releasing a long-held button +- `BRT`: "Brighten", from controllers that issue a single command to slightly brighten a light +- `DIM`: "Dim", from controllers that issue a single command to slightly dim a light + +### {% linkable_title Insteon Scenes %} + +All Insteon scenes configured in the ISY994 will show up as switches in Home Assistant. + ### {% linkable_title Creating Custom Devices %} Using the Programs tab in the controller's Administrative Console, custom devices can be created that will appear natively inside of Home Assistant. Home Assistant will scan the following folders and build the device to the associated domains: diff --git a/source/_components/light.ads.markdown b/source/_components/light.ads.markdown new file mode 100644 index 00000000000..b5188cf33e8 --- /dev/null +++ b/source/_components/light.ads.markdown @@ -0,0 +1,42 @@ +--- +layout: page +title: "ADS Light" +description: Instructions how to set up ADS lights within Home Assistant +date: 2017-10-25 10:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: beckhoff.png +ha_category: Light +ha_release: "0.60" +ha_iot_class: "Local Push" +--- + +The `ads` light platform allows you to control your connecte ADS lights. + +To use your ADS device, you first have to set up your [ADS hub](/components/ads/) and then add the following to your `configuration.yaml` +file: + +```yaml +# Example configuration.yaml entry +light: + - platform: ads + adsvar: GVL.enable_light + adsvar_brightness: GVL.brightness +``` + +{% configuration %} + adsvar: + required: true + description: The name of the boolean variable that switches the light on + type: string + adsvar_brightness: + required: false + description: The name of the variable that controls the brightness, use an unsigned integer on the PLC side + type: integer + name: + required: false + description: An identifier for the Light in the frontend + type: string +{% endconfiguration %} diff --git a/source/_components/light.hue.markdown b/source/_components/light.hue.markdown index 871972d4f0c..d4d37548b6b 100644 --- a/source/_components/light.hue.markdown +++ b/source/_components/light.hue.markdown @@ -1,7 +1,7 @@ --- layout: page -title: "Philips Hue" -description: "Instructions how to setup Philips Hue within Home Assistant." +title: "Philips Hue Light" +description: "Instructions how to integrate Philips Hue lights into Home Assistant." date: 2015-03-23 20:09 sidebar: true comments: false @@ -14,119 +14,8 @@ featured: true ha_release: pre 0.7 --- -Philips Hue support is integrated into Home Assistant as a light platform. The preferred way to setup the Philips Hue platform is by enabling the [discovery component](/components/discovery/). +The Philips Hue light platform allows you to control your Philips Hue lights. -Once discovered, if you have a custom default view, locate `configurator.philips_hue` in the entities list ( < > ) and add it to a group in `configuration.yaml`. Restart Home Assistant so that the configurator is visible in the Home Assistant dashboard. Once Home Assistant is restarted, locate and click on `configurator.philips_hue` to bring up the initiation dialog. This will prompt you to press the Hue button to register the Hue hub in Home Assistant. Once complete, the configurator entity isn't needed anymore and can be removed from any visible group in `configuration.yaml`. +This component will automatically add `Lights` configured on your Hue bridges. -When you configure the Hue bridge from Home Assistant, it writes a token to a file in your Home Assistant [configuration directory](/docs/configuration/). That token authenticates the communication with the Hue bridge. This token uses the IP Address of the Hue Bridge. If the IP address for the Hue Bridge changes, you will need to register the Hue Bridge with Home Assistant again. To avoid this you may set up DHCP registration for your Hue Bridge, so that it always has the same IP address. - -Restarting Home Assistant once more should result in the Hue lights listed as "light" entities. Add these light entities to configuration.yaml and restart Home Assistant once more to complete the installation. - -If you want to enable the component without relying on the [discovery component](/components/discovery/), add the following lines to your `configuration.yaml` file: - -```yaml -# Example configuration.yaml entry -light: - - platform: hue - host: DEVICE_IP_ADDRESS -``` - -Configuration variables: - -- **host** (*Optional*): IP address of the device, eg. 192.168.1.10. Required if not using the `discovery` component to discover Hue bridges. -- **allow_unreachable** (*Optional*): (true/false) This will allow unreachable bulbs to report their state correctly. -- **filename** (*Optional*): Make this unique if specifying multiple Hue hubs. -- **allow_in_emulated_hue** (*Optional*): )true/false) Enable this to block all Hue entities from being added to the `emulated_hue` component. -- **allow_hue_groups** (*Optional*): (true/false) Enable this to stop Home Assistant from importing the groups defined on the Hue bridge. - -### {% linkable_title Multiple Hue bridges %} - -If you 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: - -```yaml -# Example configuration.yaml entry -light: - - platform: hue - host: BRIDGE1_IP_ADDRESS - filename: phue.conf - - platform: hue - host: BRIDGE2_IP_ADDRESS - filename: phue2.conf -``` - -### {% linkable_title Using Hue Groups in Home Assistant %} - -The Hue API allows you to group lights. Home Assistant also supports grouping of entities natively, but sometimes it can be useful to use Hue Groups to group light bulbs. By doing so, Home Assistant only needs to send one API call to change the state of all the bulbs in those groups instead of one call for every light in the group. This causes all the bulbs to change state simultaneously. - -These Hue Groups can be a `Luminaire`, `Lightsource`, `LightGroup` or `Room`. The `Luminaire` and `Lightsource` can't be created manually since the Hue bridge manages these automatically based on the discovered bulbs. The `Room` and `LightGroup` can be created manually through the API, or the mobile app. A bulb can only exist in one `Room`, but can exist in multiple `LightGroup`. The `LightGroup` can be useful to link certain bulbs together since. - -The 2nd generation Hue app only allows to create a `Room`. You need to use the first generation app or the API to create a `LightGroup`. - -Example: - -To create a `LightGroup` named `Ceiling lights` that contains the lights 1, 2 and 3, execute the following command: - -```bash -$ curl -XPOST -d '{"name": "Ceiling lights", "lights": ["1", "2", "3"]}' http://- To support Hue Light Groups, your bridge needs to have at least firmware 1.13 (released on June 3, 2016). -
- -More information can be found on the [Philips Hue API documentation](https://www.developers.meethue.com/documentation/groups-api#22_create_group) website. - - -### {% 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. - -To avoid user interface overload we don't expose scenes directly. Instead there is a [light.hue_activate_scene](/components/light/#service-lighthue_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. - -For instance: - -```yaml -script: - porch_on: - sequence: - - service: light.hue_activate_scene - data: - group_name: "Porch" - scene_name: "Porch Orange" -``` - -| Service data attribute | Optional | Description | -| ---------------------- | -------- | ----------- | -| `group_name` | no | The group/room name of the lights. Find this in the Hue official app. -| `scene_name` | no | The name of the scene. Find this in the Hue official app. - -*Note*: `group_name` is not linked to Home Assistant group name. - -*** Finding Group and Scene Names *** - -How do you find these names? - -The easiest way to do this is only use the scenes from the 2nd generation Hue app. That is organized by room (group) and scene Name. Use the values of room name and scene name that you see in the app. You can test these work on the `dev-service` console of your Home Assistant instance. - -Alternatively, you can dump all rooms and scene names using this [gist](https://gist.github.com/sdague/5479b632e0fce931951c0636c39a9578). This does **not** tell you which groups and scenes work together but it's sufficient to get values that you can test in the `dev-service` console. - -*** Caveats *** - -The Hue API doesn't activate scenes directly, only on a Hue Group (typically rooms, especially if using the 2nd gen app). But Hue Scenes don't actually reference their group. So heuristic matching is used. - -Neither group names or scene names are guaranteed unique in Hue. If you are getting non deterministic behavior, adjust your Hue scenes via the App to be more identifying. - -The Hue hub has limited spaces for scenes, and will delete scenes if new ones get created that would overflow that space. The API docs say this is based on "Least Recently Used". +The requirement is that you have setup your [Philips Hue bridge](/components/hue/). diff --git a/source/_components/media_player.ue_smart_radio.markdown b/source/_components/media_player.ue_smart_radio.markdown new file mode 100644 index 00000000000..217b625b8d5 --- /dev/null +++ b/source/_components/media_player.ue_smart_radio.markdown @@ -0,0 +1,38 @@ +--- +layout: page +title: "Logitech UE Smart Radio" +description: "Instructions on how to integrate a Logitech UE Smart Radio player into Home Assistant." +date: 2017-12-09 20:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: ueradio.png +ha_category: Media Player +ha_release: "0.60" +ha_iot_class: "Cloud Polling" +--- + + +The `ue_radio` platform allows you to control a [Logitech UE Smart Radio](https://www.uesmartradio.com) from Home Assistant. This lets you control both Logitech UE Smart Radios and Logitech Squeezebox Radios that have been updated with the UE Smart Radio update. + +To add your UE Smart Radio player to your installation, add the following to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +media_player: + - platform: ue_smart_radio + username: USERNAME + password: PASSWORD +``` + +{% configuration %} +username: + description: The email you use to log in to `uesmartradio.com`. + required: true + type: string +password: + description: The password you use to log in to `uesmartradio.com`. + required: true + type: string +{% endconfiguration %} diff --git a/source/_components/media_player.ziggo_mediabox_xl.markdown b/source/_components/media_player.ziggo_mediabox_xl.markdown new file mode 100644 index 00000000000..5919b19b50b --- /dev/null +++ b/source/_components/media_player.ziggo_mediabox_xl.markdown @@ -0,0 +1,43 @@ +--- +layout: page +title: "Ziggo Mediabox XL" +description: "Instructions how to integrate the Ziggo Mediabox XL into Home Assistant." +date: 2017-11-10 20:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: ziggo.png +ha_category: Media Player +ha_iot_class: "Local Polling" +ha_release: "0.60" +--- + +The `ziggo_mediabox_xl` component allows you to control a [Ziggo](https://www.ziggo.nl/) Mediabox XL from Home Assistant. + +To add a Ziggo Mediabox XL to your installation, add the following to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +media_player: + - platform: ziggo_mediabox_xl + host: 192.168.0.123 + name: Ziggo Mediabox +``` + +{% configuration %} + host: + description: The hostname or address of the device. + required: true + type: string + name: + description: The name of the device used in the frontend. + required: false + type: string +{% endconfiguration %} + +The channel information (numbers and names) are downloaded from ziggo.nl on startup. + +#### {% linkable_title Preparation of the Mediabox %} + +Makes sure to enable the Home Network ("mijn thuisnetwerk") service in the settings menu of the media box. Once you have set up the Media Library ("mediabiblotheek"), we can determine whether the device is turned on or off. Without this, the component will fail to start. diff --git a/source/_components/notify.nfandroidtv.markdown b/source/_components/notify.nfandroidtv.markdown index 3a91a7cba0e..79b3096a7de 100644 --- a/source/_components/notify.nfandroidtv.markdown +++ b/source/_components/notify.nfandroidtv.markdown @@ -14,9 +14,11 @@ ha_iot_class: "Local Polling" --- -Notification platform for [Notifications for Android TV](https://play.google.com/store/apps/details?id=de.cyberdream.androidtv.notifications.google&hl=en) and [Notifications for FireTV](https://play.google.com/store/apps/details?id=de.cyberdream.firenotifications.google). +Notification platform for [Notifications for Android TV](https://play.google.com/store/apps/details?id=de.cyberdream.androidtv.notifications.google) and [Notifications for FireTV](https://play.google.com/store/apps/details?id=de.cyberdream.firenotifications.google). + The notifications are in the global scope of your Android TV device. They will be displayed regardless of which application is running. -The In-App purchases only apply to the client for Android smartphones, so there isn't any limit when pushing notifications from Home Assistant. + +When setting this up be aware, that there are two apps: one for your smartphone to send notifications (not required for this platform) and one for your Android TV device to receive the notifications. The app available in the store of your target device is the one that is needed to display notifications sent from Home Assistant. The In-App purchases only apply to the client for Android smartphones, so there isn't any limit when pushing notifications from Home Assistant. To enable the notification platform, add the following to your `configuration.yaml` file: @@ -50,7 +52,7 @@ This is a fully customized JSON you can use to test how the final notification w "duration":2, "transparency":"0%", "color": "red", - "interrupt": 1 + "interrupt": 1, } } ``` diff --git a/source/_components/scene.vera.markdown b/source/_components/scene.vera.markdown new file mode 100644 index 00000000000..8cef7235eca --- /dev/null +++ b/source/_components/scene.vera.markdown @@ -0,0 +1,21 @@ +--- +layout: page +title: "Vera Scene" +description: "Instructions on how to integrate Vera Scenes into Home Assistant." +date: 2017-11-20 20:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: vera.png +ha_category: Scene +ha_iot_class: "Local Push" +ha_release: "0.60" +--- + +The `vera` platform allows you to control your [Vera](http://getvera.com/) scenes from within Home Assistant. + +They will be automatically discovered if the `vera` component is loaded. + +For more configuration information see the [Vera component](/components/vera/) documentation. + diff --git a/source/_components/sensor.ads.markdown b/source/_components/sensor.ads.markdown new file mode 100644 index 00000000000..0e65a67bb60 --- /dev/null +++ b/source/_components/sensor.ads.markdown @@ -0,0 +1,51 @@ +--- +layout: page +title: "ADS Sensor" +description: "Instructions how to integrate ADS numeric values into Home Assistant." +date: 2017-10-25 10:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: beckhoff.png +ha_category: Sensor +ha_release: "0.60" +ha_iot_class: "Local Push" +--- + +The `ads` sensor platform allows reading the value of a numeric variable on your ADS device. The variable can be of type *INT*, *UINT* or *BYTE*. + +To use your ADS device, you first have to set up your [ADS hub](/components/ads/) and then add the following to your `configuration.yaml` +file: + +```yaml +# Example configuration.yaml entry +sensor: + - platform: ads + adsvar: GVL.temperature + unit_of_measurement: '°C' + adstype: int +``` + +{% configuration %} + adsvar: + required: true + description: The name of the variable which you want to access. + type: string + adstype: + required: false + description: The datatype of the ADS variable, possible values are int, uint, byte. + default: int + type: string + name: + required: false + description: An identifier for the sensor. + type: string + factor: + required: false + description: A factor that divides the stored value before displaying in Home Assistant. + default: 1 + type: integer +{% endconfiguration %} + +The *factor* can be used to implement fixed decimals. E.g., set *factor* to 100 if you want to display a fixed decimal value with two decimals. A variable value of `123` will be displayed as `1.23`. diff --git a/source/_components/sensor.alpha_vantage.markdown b/source/_components/sensor.alpha_vantage.markdown new file mode 100644 index 00000000000..9fb5b85a569 --- /dev/null +++ b/source/_components/sensor.alpha_vantage.markdown @@ -0,0 +1,53 @@ +--- +layout: page +title: "Alpha Vantage" +description: "Instructions how to setup Alpha Vantage within Home Assistant." +date: 2017-12-02 12:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: alpha_vantage.png +ha_category: Finance +ha_iot_class: "Cloud Polling" +featured: false +ha_release: "0.60" +--- + +The `alpha_vantage` sensor platform uses [Alpha Vantage](https://www.alphavantage.co) to monitor the stock market. + +To enable the `yahoo_finance` platform, add the following lines to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +sensor: + - platform: alpha_vantage + api_key: YOUR_API_KEY +``` + +{% configuration %} +api_key: + description: "The API Key from [Alpha Vantage](https://www.alphavantage.co)." + required: true + type: string +symbols: + description: List of stock market symbols for given companies. + required: false + type: string, list + default: GOOGL +{% endconfiguration %} + +## {% linkable_title Examples %} + +In this section you find some real life examples of how to use this sensor. + +### {% linkable_title Red Hat and Google %} + +```yaml +sensor: + - platform: yahoo_finance + symbols: + - RHT + - GOOGL +``` + diff --git a/source/_components/sensor.canary.markdown b/source/_components/sensor.canary.markdown new file mode 100644 index 00000000000..25efd713e39 --- /dev/null +++ b/source/_components/sensor.canary.markdown @@ -0,0 +1,24 @@ +--- +layout: page +title: "Canary Sensor" +description: "Instructions on how to integrate your Canary devices into Home Assistant." +date: 2017-12-07 22:00 +sidebar: true +comments: false +sharing: true +footer: true +logo: canary.png +ha_category: Sensor +ha_release: "0.60" +ha_iot_class: "Cloud Polling" +--- + +The `canary` sensor platform allows you to integrate the sensors of your [Canary](https://canary.is) devices in Home Assistant. + +To add `canary` sensors to your installation, follow instructions in [Canary component](/components/canary/). + +Once loaded, you will see following sensors: + +* A sensor per camera that reports temperature. +* A sensor per camera that reports humidity. +* A sensor per camera that reports air quality. diff --git a/source/_components/sensor.gearbest.markdown b/source/_components/sensor.gearbest.markdown new file mode 100644 index 00000000000..31803acb752 --- /dev/null +++ b/source/_components/sensor.gearbest.markdown @@ -0,0 +1,72 @@ +--- +layout: page +title: "Gearbest" +description: "Instructions on how to integrate a Gearbest sensor into Home Assistant." +date: 2017-11-13 09:08 +sidebar: true +comments: false +sharing: true +footer: true +logo: gearbest.png +ha_category: Sensor +ha_iot_class: "Cloud Polling" +ha_release: "0.60" +--- + + +The `gearbest` sensor will track the price of a product from [Gearbest](https://www.gearbest.com). This information can be used in, e.g., automations to notify you when a price drops. The update interval for every item is currently set to 2 hours. + +To enable this sensor, add the following lines to your `configuration.yaml` file: + +```yaml +# Example configuration.yaml entry +sensor: + - platform: gearbest + currency: EUR + items: + - url: https://www.gearbest.com/.... +``` + +{% configuration %} +currency: + description: "The currency in which the products should be tracked. Currently supported: USD, EUR, GBP, AUD, CAD, CHF, HKD, CNY, NZD, JPY, RUB, BRL, CLP, NOK, DKK, SEK, KRW, ILS, COP, MXN, PEN, THB, IDR, UAH, PLN, INR, BGN, HUF, RON, TRY, CZK, HRK, MAD, AED, SAR, ZAR, SGD, MYR, TWD, RSD, NGN - if the currency could not be found in the conversion rate list, USD will be used as default. Either an ID or an URL must be present." + required: true + type: string +items: + description: List of products that should be tracked. + required: true + type: map + keys: + id: + description: The ID of the product. + required: false + type: int + url: + description: The URL of the product. + required: false + type: string + name: + description: The name of the item. If not set, it is parsed from the website. + required: false + type: string + currency: + description: Overwrite the currency for the current item. + required: false + type: string +{% endconfiguration %} + +### {% linkable_title Extended example %} + +```yaml +# Example configuration.yaml entry +sensor: + - platform: gearbest + currency: EUR + items: + - url: https://www.gearbest.com/3d-printers-3d-printer-kits/pp_779174.html?wid=21 + name: Creality CR-10 upgraded + currency: USD + - id: 779174 + name: Creality CR-10 upgraded #2 + currency: EUR +``` diff --git a/source/_components/sensor.luftdaten.markdown b/source/_components/sensor.luftdaten.markdown index 486b10e5f2a..6417ee5e0a5 100644 --- a/source/_components/sensor.luftdaten.markdown +++ b/source/_components/sensor.luftdaten.markdown @@ -45,16 +45,6 @@ sensor: required: false default: Luftdaten Sensor type: string - resource: - description: The URL of the API endpoint. Usually this has not to be changed. - required: false - default: https://api.luftdaten.info/v1/sensor/ - type: string - verify_ssl: - description: Verify SSL connection. - required: false - default: true - type: boolean monitored_conditions: description: A list of conditions you want to monitor. required: true @@ -65,8 +55,15 @@ sensor: P2: description: Show the particle sensors (particles 2.5 microns and below). temperature: - description: Display the temperature from a weather sensor. + description: Display the temperature from the sensor. humidity: - description: Display the humidity from a weather sensor. + description: Display the humidity from the sensor. + pressure: + description: Display the pressure from the sensor. {% endconfiguration %} +Not all sensors provide all conditions. Also, it's possible that the sensor values are not available all the time. To check what a sensor is publishing use `curl`: + +```bash +$ curl https://api.luftdaten.info/v1/sensor/[sensorid]/ +``` diff --git a/source/_components/sensor.rest.markdown b/source/_components/sensor.rest.markdown index 15a366f78e4..c496c7a0e0e 100644 --- a/source/_components/sensor.rest.markdown +++ b/source/_components/sensor.rest.markdown @@ -89,6 +89,11 @@ json_attributes: description: A list of keys to extract values from a JSON dictionary result and then set as sensor attributes. reqired: false type: list, string +force_update: + description: Sends update events even if the value hasn't changed. Useful if you want to have meaningful value graphs in history. + reqired: false + type: boolean + default: False {% endconfiguration %}diff --git a/source/_components/sensor.yahoo_finance.markdown b/source/_components/sensor.yahoo_finance.markdown index a71ef1ea228..8a55a78dda7 100644 --- a/source/_components/sensor.yahoo_finance.markdown +++ b/source/_components/sensor.yahoo_finance.markdown @@ -15,7 +15,7 @@ ha_release: 0.29 ---
- This sensor doesn't work anymore as [Yahoo!](https://yahoo.uservoice.com/forums/382977-finance/suggestions/32103877-yahoo-stock-quote-api-please-bring-back) decommissioned the service in early November 2017. + This sensor doesn't work anymore as [Yahoo!](https://yahoo.uservoice.com/forums/382977-finance/suggestions/32103877-yahoo-stock-quote-api-please-bring-back) decommissioned the service in early November 2017. A repleacement is the [`alpha_vantage` sensor](/components/sensor.alpha_vantage/).
The `yahoo_finance` platform uses [Yahoo Finance](https://finance.yahoo.com/) to monitor the stock market. diff --git a/source/_components/snips.markdown b/source/_components/snips.markdown index ef4b7d04295..642faabf93d 100644 --- a/source/_components/snips.markdown +++ b/source/_components/snips.markdown @@ -12,26 +12,40 @@ ha_category: Voice ha_release: 0.48 --- -The [Snips Voice Platform](https://www.snips.ai) allows users to add powerful voice assistants to their Raspberry Pi devices without compromising on Privacy. It runs 100% on-device, and does not require an Internet connection. It features Hotword Detection, Automatic Speech Recognition (ASR), Natural Language Understanding (NLU) and Dialog Management. +The [Snips Voice Platform](https://www.snips.ai) allows users to add powerful voice assistants to their Raspberry Pi devices without compromising on privacy. It runs 100% on-device, and does not require an internet connection. It features Hotword Detection, Automatic Speech Recognition (ASR), Natural Language Understanding (NLU) and Dialog Management. + +The latest documentation can be found here: [Snips Platform Documentation](https://github.com/snipsco/snips-platform-documentation/wiki).  -Snips takes voice or text as input, and produces *intents* as output, which are explicit representations of an intention behind an utterance, and which can subsequently be used by Home Assistant to perform appropriate actions. +Snips takes voice or text as input and produces *intents* as output, which are explicit representations of an intention behind an utterance and which can subsequently be used by Home Assistant to perform appropriate actions.  ## {% linkable_title The Snips Voice Platform %} -### Installation +### {% linkable_title Installation %} -The Snips Voice Platform is installed on Raspberry Pi with the following command: +The Snips Voice Platform is installed as a Docker image on Raspberry Pi with the following command: -```sh +```bash (pi) $ curl https://install.snips.ai -sSf | sh ``` -### Creating an assistant +Snips can also be installed on a Debian/Ubuntu machine as well: + +```bash +$ sudo apt-get update +$ sudo apt-get install -y dirmngr +$ sudo bash -c 'echo "deb https://debian.snips.ai/$(lsb_release -cs) stable main" > /etc/apt/sources.list.d/snips.list' +$ sudo apt-key adv --keyserver pgp.mit.edu --recv-keys F727C778CCB0A455 + +$ sudo apt-get update +$ sudo apt-get install -y snips-platform-voice +``` + +### {% linkable_title Creating an assistant %}