mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-07-25 10:17:23 +00:00
Merge branch 'current' into next
This commit is contained in:
Paulus Schoutsen
commit
04b4f58407
3
.gitmodules
vendored
3
.gitmodules
vendored
@ -1,4 +1,3 @@
|
||||
[submodule "_deploy"]
|
||||
path = _deploy
|
||||
url = https://github.com/home-assistant/home-assistant.git
|
||||
branch = gh-pages
|
||||
url = https://github.com/home-assistant/home-assistant.github.io.git
|
||||
|
||||
2
_deploy
2
_deploy
@ -1 +1 @@
|
||||
Subproject commit 42e481f37c2a10930f2581c92053b87e25fcdc37
|
||||
Subproject commit 3633483305bb092ff72024ac1b59e66f7c1aacc0
|
||||
@ -215,7 +215,7 @@ article.post, article.page, article.listing {
|
||||
}
|
||||
|
||||
h1, h2, h3 {
|
||||
margin-bottom: 0;
|
||||
margin-bottom: 4px;
|
||||
line-height: 1.2;
|
||||
}
|
||||
}
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Ecobee Sensor"
|
||||
title: "Ecobee Binary Sensor"
|
||||
description: "Instructions how to setup the Ecobee sensors within Home Assistant."
|
||||
date: 2015-11-30 18:00
|
||||
sidebar: true
|
||||
@ -11,4 +11,4 @@ logo: ecobee.png
|
||||
ha_category: Sensor
|
||||
---
|
||||
|
||||
To get your Ecobee sensors working with Home Assistant, follow the instructions for the general [Ecobee component](/components/ecobee/).
|
||||
To get your Ecobee binary sensors working with Home Assistant, follow the instructions for the general [Ecobee component](/components/ecobee/).
|
||||
@ -22,6 +22,7 @@ binary_sensor:
|
||||
monitored_conditions:
|
||||
- 'fan'
|
||||
- 'hvac_ac_state'
|
||||
- 'hvac_heater_state'
|
||||
- 'hvac_aux_heater_state'
|
||||
- 'hvac_heat_x2_state'
|
||||
- 'hvac_heat_x3_state'
|
||||
|
||||
@ -33,7 +33,7 @@ camera:
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **input** (*Required*): A ffmpeg compatible input file, stream or feet.
|
||||
- **input** (*Required*): A ffmpeg compatible input file, stream or feed.
|
||||
- **name** (*Optional*): This parameter allows you to override the name of your camera.
|
||||
- **ffmpeg_bin** (*Optional*): Default 'ffmpeg'.
|
||||
- **extra_arguments** (*Optional*): Extra option they will pass to ffmpeg. i.e. image quality or video filter options.
|
||||
|
||||
@ -34,3 +34,79 @@ Configuration variables:
|
||||
- **max** (*Optional*): Maximum value for the slider.
|
||||
- **step** (*Optional*): Step value for the slider.
|
||||
|
||||
## {% linkable_title Automation Examples %}
|
||||
|
||||
Here's an example of `input_slider` being used as a trigger in an automation.
|
||||
|
||||
```yaml
|
||||
{% raw %}
|
||||
# Example configuration.yaml entry using 'input_slider' as a trigger in an automation
|
||||
|
||||
# Define input_slider
|
||||
input_slider:
|
||||
bedroom_brightness:
|
||||
name: Brightness
|
||||
initial: 254
|
||||
min: 0
|
||||
max: 254
|
||||
step: 1
|
||||
|
||||
# Automation.
|
||||
automation:
|
||||
- alias: Bedroom Light - Adjust Brightness
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: input_slider.bedroom_brightness
|
||||
action:
|
||||
- service: light.turn_on
|
||||
# Note the use of 'data_template:' below rather than the normal 'data:' if you weren't using an input variable
|
||||
data_template:
|
||||
entity_id: light.bedroom
|
||||
brightness: '{{ trigger.to_state.state | int }}'
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
Another code example using `input_slider`, this time being used in an action in an automation.
|
||||
|
||||
```yaml
|
||||
{% raw %}
|
||||
# Example configuration.yaml entry using 'input_slider' in an action in an automation
|
||||
|
||||
# Define 'input_select'
|
||||
input_select:
|
||||
scene_bedroom:
|
||||
name: Scene
|
||||
options:
|
||||
- Select
|
||||
- Concentrate
|
||||
- Energize
|
||||
- Reading
|
||||
- Relax
|
||||
- 'OFF'
|
||||
initial: 'Select'
|
||||
|
||||
# Define input_slider
|
||||
input_slider:
|
||||
bedroom_brightness:
|
||||
name: Brightness
|
||||
initial: 254
|
||||
min: 0
|
||||
max: 254
|
||||
step: 1
|
||||
|
||||
# Automation.
|
||||
automation:
|
||||
- alias: Bedroom Light - Custom
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: input_select.scene_bedroom
|
||||
to: CUSTOM
|
||||
action:
|
||||
- service: light.turn_on
|
||||
# Again, note the use of 'data_template:' rather than the normal 'data:' if you weren't using an input variable.
|
||||
data_template:
|
||||
entity_id: light.bedroom
|
||||
brightness: '{{ states.input_slider.bedroom_brightness.state | int }}'
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
|
||||
@ -19,6 +19,7 @@ Supported devices:
|
||||
- Denon DRA-N5
|
||||
- Denon RCD-N8 (untested)
|
||||
- Denon RCD-N9 (partial support)
|
||||
- Denon AVR receivers with Integrated Network support (partial support)
|
||||
|
||||
To add a Denon Network Receiver to your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
||||
@ -1,21 +1,21 @@
|
||||
---
|
||||
layout: page
|
||||
title: "SnapCast"
|
||||
description: "Instructions on how to integrate SnapCast into Home Assistant."
|
||||
title: "Snapcast"
|
||||
description: "Instructions on how to integrate Snapcast into Home Assistant."
|
||||
date: 2016-02-01 19:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo:
|
||||
logo: snapcast.png
|
||||
ha_category: Media Player
|
||||
featured: false
|
||||
ha_release: 0.13
|
||||
---
|
||||
|
||||
The `snapcast` platform allows you to control [SnapCast](https://github.com/badaix/snapcast) from Home Assistant.
|
||||
The `snapcast` platform allows you to control [Snapcast](https://github.com/badaix/snapcast) from Home Assistant.
|
||||
|
||||
To add SnapCast to your installation, add the following to your `configuration.yaml` file:
|
||||
To add Snapcast to your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
||||
@ -29,7 +29,7 @@ modbus:
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **type** (*Required*): Type of the connection to Modebus.
|
||||
- **type** (*Required*): Type of the connection to Modbus.
|
||||
- **host** (*Required*): The IP address of your router, eg. 192.168.1.1.
|
||||
- **port** (*Required*): The port for the comminication.
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: page
|
||||
title: "PushBullet"
|
||||
title: "Pushbullet"
|
||||
description: "Instructions how to add user notifications to Home Assistant."
|
||||
date: 2015-01-20 22:36
|
||||
sidebar: true
|
||||
@ -12,9 +12,9 @@ ha_category: Notifications
|
||||
featured: true
|
||||
---
|
||||
|
||||
The `pushbullet` notification platform sends messages to [PushBullet](https://www.pushbullet.com/), a free service to send information between your phones, browsers, and friends.
|
||||
The `pushbullet` notification platform sends messages to [Pushbullet](https://www.pushbullet.com/), a free service to send information between your phones, browsers, and friends.
|
||||
|
||||
To enable PushBullet notifications in your installation, add the following to your `configuration.yaml` file:
|
||||
To enable Pushbullet notifications in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
@ -26,12 +26,12 @@ notify:
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **api_key** (*Required*): Enter the API key for PushBullet. Go to https://www.pushbullet.com/ to retrieve your API key.
|
||||
- **api_key** (*Required*): Enter the API key for Pushbullet. Go to https://www.pushbullet.com/ to retrieve your API key.
|
||||
- **name** (*Optional*): Setting the optional parameter `name` allows multiple notifiers to be created. The default value is `notify`. The notifier will bind to the service `notify.NOTIFIER_NAME`.
|
||||
|
||||
### {% linkable_title Usage %}
|
||||
|
||||
PushBullet is a notify platform and thus can be controlled by calling the notify service [as described here](/components/notify/). It will send a notification to all devices registered in the PushBullet account. An optional **target** parameter can be given to PushBullet to specify specific account's devices, contacts or channels.
|
||||
Pushbullet is a notify platform and thus can be controlled by calling the notify service [as described here](/components/notify/). It will send a notification to all devices registered in the Pushbullet account. An optional **target** parameter can be given to Pushbullet to specify specific account's devices, contacts or channels.
|
||||
|
||||
Type | Prefix | Suffix | Example
|
||||
---- | ------ | ------ | -------
|
||||
|
||||
@ -35,7 +35,7 @@ notify:
|
||||
Configuration variables:
|
||||
|
||||
- **name** (*Optional*): Setting the optional parameter `name` allows multiple notifiers to be created. The default value is `notify`. The notifier will bind to the service `notify.NOTIFIER_NAME`.
|
||||
- **api_key** (*Required*): The slack API token to use for sending slack messages. You can get your slack API token here https://api.slack.com/web?sudo=1
|
||||
- **api_key** (*Required*): The slack API token to use for sending slack messages.
|
||||
- **default_channel** (*Required*): The default channel to post to if no channel is explicitly specified when sending the notification message.
|
||||
|
||||
To use notifications, please see the [getting started with automation page](/getting-started/automation/).
|
||||
|
||||
@ -38,11 +38,11 @@ Configuration variables:
|
||||
- **port** (*Optional*): The port that the SMTP server is using, eg. 587 for Google Mail and STARTTLS or 465/993 depending on your SMTP servers. Defaults to 25.
|
||||
- **sender** (*Optional*): E-mail address of the sender.
|
||||
- **username** (*Optional*): Username for the SMTP account.
|
||||
- **password** (*Optional*):Password for the SMTP server that belongs to the given username. If the password contains a colon it need to be wrapped in apostrophes.
|
||||
- **password** (*Optional*): Password for the SMTP server that belongs to the given username. If the password contains a colon it need to be wrapped in apostrophes.
|
||||
- **recipient** (*Required*): Recipient of the notification.
|
||||
- **starttls** (*Optional*): Enables STARTTLS, eg. 1 or 0. Defaults to 0.
|
||||
|
||||
To use the smtp notification, refer to it in an automation or script like in this example:
|
||||
To use the SMTP notification, refer to it in an automation or script like in this example:
|
||||
|
||||
```yaml
|
||||
burglar:
|
||||
@ -61,7 +61,7 @@ To use the smtp notification, refer to it in an automation or script like in thi
|
||||
- /home/pi/snapshot2.jpg
|
||||
```
|
||||
|
||||
The optional **images** field adds in-line image attachments to the email. This sends a text/HTML multi-part message instead of the plain text default.
|
||||
The optional `images` field adds in-line image attachments to the email. This sends a text/HTML multi-part message instead of the plain text default.
|
||||
|
||||
This platform is fragile and not able to catch all exceptions in a smart way because of the large number of possible configuration combinations.
|
||||
|
||||
|
||||
@ -17,6 +17,7 @@ The `rfxtrx` platform supports Siemens/LightwaveRF and RFY roller shutters that
|
||||
First you have to set up your [rfxtrx hub](/components/rfxtrx/).
|
||||
|
||||
### {% linkable_title Configuration %}
|
||||
|
||||
##### Siemens/LightwaveRF
|
||||
The easiest way to find your roller shutters is to add this to your `configuration.yaml`:
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ Configuration variables:
|
||||
|
||||
- **resources** array (*Required*): Contains all entries to display.
|
||||
|
||||
#### Example
|
||||
### {% linkable_title Example %}
|
||||
|
||||
Given the following output from `apcaccess`:
|
||||
|
||||
|
||||
@ -19,11 +19,12 @@ To enable this sensor, add the following lines to your `configuration.yaml` file
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
platform: dte_energy_bridge
|
||||
ip: 192.168.1.11
|
||||
- platform: dte_energy_bridge
|
||||
ip: 192.168.1.11
|
||||
name: DTE Energy
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **ip** (*Required*): The IP address of your bridge.
|
||||
|
||||
- **name** (*Optional*): Name to use in the frontend.
|
||||
|
||||
@ -65,7 +65,7 @@ sensor:
|
||||
|
||||
If you are using a DHT sensor and a NodeMCU board (esp8266), you can retrieve temperature and humidity with a MQTT sensor. A code example can be found [here](https://github.com/mertenats/open-home-automation/tree/master/ha_mqtt_sensor_dht22). A regular MQTT message from this example looks like this:
|
||||
|
||||
```
|
||||
```json
|
||||
office/sensor1
|
||||
{
|
||||
"temperature": 23.20,
|
||||
|
||||
@ -14,7 +14,7 @@ ha_release: 0.26
|
||||
---
|
||||
|
||||
|
||||
The `ohmconnect` sensor will show you the current [OhmConnect](https://ohmconnect.com) status for the given OhmConnect ID.
|
||||
The `ohmconnect` sensor will show you the current [OhmConnect](https://www.ohmconnect.com/) status for the given OhmConnect ID.
|
||||
|
||||
> OhmConnect monitors real-time conditions on the electricity grid. When dirty and unsustainable power plants turn on, our users receive a notification to save energy. By saving energy at that time, California does not have to turn on additional power plants and California's energy authorities pay you for that.
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
logo: network-snmp.png
|
||||
ha_category: Sensor
|
||||
ha_category: System Monitor
|
||||
ha_iot_class: "Local Polling"
|
||||
ha_release: "0.22"
|
||||
---
|
||||
|
||||
@ -45,6 +45,7 @@ sensor:
|
||||
platform: yweather
|
||||
woeid: YOUR_WOEID
|
||||
forecast: 3
|
||||
name: OPTIONAL_NAME
|
||||
monitored_conditions:
|
||||
- weather
|
||||
- temp_min
|
||||
@ -55,6 +56,7 @@ Configuration variables:
|
||||
|
||||
- **woeid** (*Optional*): See above.
|
||||
- **forecast** (*Optional*): Day of forecast. The default is the current day to display conditions.
|
||||
- **name** (*Optional*): The name of the sensor. To easily recognize each sensor when adding more than one Yahoo weather sensor, it is recommended to use the name option.
|
||||
- **monitored_conditions** array (*Required*): Conditions to display in the frontend.
|
||||
- **weather**: A human-readable text summary with picture from yahoo.
|
||||
- **weather_current**: A human-readable text summary with picture from yahoo from current conditon.
|
||||
|
||||
@ -19,3 +19,13 @@ zeroconf:
|
||||
```
|
||||
|
||||
The registration will include metadata about the Home Assistant instance, including a base URL that can be used to access Home Assistant, the currently running Home Assistant version, and whether an API password is needed to access the instance.
|
||||
|
||||
```bash
|
||||
$ avahi-browse -alr
|
||||
+ eth0 IPv4 Home _home-assistant._tcp local
|
||||
= eth0 IPv4 Home _home-assistant._tcp local
|
||||
hostname = [Home._home-assistant._tcp.local]
|
||||
address = [192.168.0.5]
|
||||
port = [8123]
|
||||
txt = ["version=0.27.0.dev0" "base_url=http://192.168.0.5:8123" "requires_api_password=true"]
|
||||
```
|
||||
|
||||
@ -54,6 +54,10 @@ This release includes code contributed by 31 different people. The biggest chang
|
||||
|
||||
- Fix Wemo: have PyWemo play nicely with the latest Requests ([@pavoni])
|
||||
|
||||
### {% linkable_title Hotfix 0.26.3 - August 19 %}
|
||||
|
||||
- Media Player cover art would not work when an API password was set. Thanks to [@maddox] for reporting it and [@balloob] for the fix.
|
||||
|
||||
### {% linkable_title Breaking changes %}
|
||||
|
||||
- A new unit system has superseded the temperature unit option in the core configuration. For now it is backwards compatible, but you should update soon:
|
||||
@ -65,6 +69,7 @@ homeassistant:
|
||||
unit_system: metric
|
||||
```
|
||||
|
||||
[@maddox]: https://github.com/maddox
|
||||
[@pavoni]: https://github.com/pavoni
|
||||
[@mKeRix]: https://github.com/mKeRix
|
||||
[@abcminiuser]: https://github.com/abcminiuser
|
||||
|
||||
130
source/_posts/2016-08-16-we-have-apps-now.markdown
Executable file
130
source/_posts/2016-08-16-we-have-apps-now.markdown
Executable file
@ -0,0 +1,130 @@
|
||||
---
|
||||
layout: post
|
||||
title: "We Have Apps Now"
|
||||
description: "A new subsystem that allows automations to be coded using Python"
|
||||
date: 2016-08-16 06:00:00 -0400
|
||||
date_formatted: "August 16, 2016"
|
||||
author: Andrew Cockburn
|
||||
comments: true
|
||||
categories: How-To
|
||||
---
|
||||
|
||||
I have been working on a new subsystem to complement Home Assistant's Automation and Scripting components. `AppDaemon` is a python daemon that consumes events from Home Assistant and feeds them to snippets of python code called "Apps". An App is a Python class that is instantiated possibly multiple times from `AppDaemon` and registers callbacks for various system events. It is also able to inspect and set state and call services. The API provides a rich environment suited to home automation tasks that can also leverage all the power of Python.
|
||||
|
||||
<!--more-->
|
||||
|
||||
## {% linkable_title Another Take on Automation %}
|
||||
|
||||
If you haven't yet read Paulus' excellent Blog entry on [Perfect Home Automation](https://home-assistant.io/blog/2016/01/19/perfect-home-automation/) I would encourage you to take a look. As a veteran of several Home Automation systems with varying degrees success, it was this article more than anything else that convinced me that Home Assistant had the right philosophy behind it and was on the right track. One of the most important points made is that being able to control your lights from your phone, 9 times out of 10 is harder than using a lightswitch - where Home Automation really comes into its own is when you start removing the need to use a phone or the switch - the "Automation" in Home Automation. A surprisingly large number of systems out there miss this essential point and have limited abilities to automate anything which is why a robust and open system such as Home Assistant is such an important part of the equation to bring this all together in the vast and chaotic ecosystem that is the "Internet of Things".
|
||||
|
||||
So given the importance of Automation, what should Automation allow us to do? I am a pragmatist at heart so I judge individual systems by the ease of accomplishing a few basic but representative tasks:
|
||||
|
||||
- Can the system respond to presence or absence of people?
|
||||
- Can I turn a light on at Sunset +/- a certain amount of time?
|
||||
- Can I arrive home in light or dark and have the lights figure out if they should be on or off?
|
||||
- As I build my system out, can I get the individual pieces to co-operate and use and re-use (potentially complex) logic to make sure everything works smoothly?
|
||||
- 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.
|
||||
|
||||
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 without 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!
|
||||
|
||||
It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatever about what it is controlling or reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner - the bulk of the work after that was adding additonal functions to make things that were already possible easier.
|
||||
|
||||
## {% linkable_title How it Works %}
|
||||
|
||||
The best way to show what `AppDaemon` does is through a few simple examples.
|
||||
|
||||
### {% linkable_title Sunrise/Sunset Lighting %}
|
||||
|
||||
Lets start with a simple App to turn a light on every night at sunset and off every morning at sunrise. Every App when first started will have its `initialize()` function called which gives it a chance to register a callback for `AppDaemons`'s scheduler for a specific time. In this case we are using `run_at_sunrise()` and `run_at_sunset()` to register 2 separate callbacks. The argument `0` is the number of seconds offset from sunrise or sunset and can be negative or positive. For complex intervals it can be convenient to use Python's `datetime.timedelta` class for calculations. When sunrise or sunset occurs, the appropriate callback function, `sunrise_cb()` or `sunset_cb()` is called which then makes a call to Home Assistant to turn the porch light on or off by activating a scene. The variables `args["on_scene"]` and `args["off_scene"]` are passed through from the configuration of this particular App, and the same code could be reused to activate completely different scenes in a different version of the App.
|
||||
|
||||
```python
|
||||
import appapi
|
||||
|
||||
class OutsideLights(appapi.AppDaemon):
|
||||
|
||||
def initialize(self):
|
||||
self.run_at_sunrise(self.sunrise_cb, 0)
|
||||
self.run_at_sunset(self.sunset_cb, 0)
|
||||
|
||||
def sunrise_cb(self, args, kwargs):
|
||||
self.turn_on(self.args["off_scene"])
|
||||
|
||||
def sunset_cb(self, args, kwargs):
|
||||
self.turn_on(self.args["on_scene"])
|
||||
|
||||
```
|
||||
|
||||
This is also fairly easy to achieve with Home Assistant automations, but we are just getting started.
|
||||
|
||||
### {% linkable_title Motion Light %}
|
||||
|
||||
Our next example is to turn on a light when motion is detected and it is dark, and turn it off after a period of time. This time, the `initialize()` function registers a callback on a state change (of the motion sensor) rather than a specific time. We tell `AppDaemon` that we are only interested in state changes where the motion detector comes on by adding an additional parameter to the callback registration - `new = "on"`. When the motion is detected, the callack function `motion()` is called, and we check whether or not the sun has set using a built-in convenience function: `sun_down()`. Next, we turn the light on with `turn_on()`, then set a timer using `run_in()` to turn the light off after 60 seconds, which is another call to the scheduler to execute in a set time from now, which results in `AppDaemon` calling `light_off()` 60 seconds later using the `turn_off()` call to actually turn the light off. This is still pretty simple in code terms:
|
||||
|
||||
```python
|
||||
import appapi
|
||||
|
||||
class MotionLights(appapi.AppDaemon):
|
||||
|
||||
def initialize(self):
|
||||
self.listen_state(self.motion, "binary_sensor.drive", new = "on")
|
||||
|
||||
def motion(self, entity, attribute, old, new, kwargs):
|
||||
if self.sun_down():
|
||||
self.turn_on("light.drive")
|
||||
self.run_in(self.light_off, 60)
|
||||
|
||||
def light_off(self, kwargs):
|
||||
self.turn_off("light.drive")
|
||||
```
|
||||
|
||||
This is starting to get a little more complex in Home Assistant automations requiring an Automation rule and two separate scripts.
|
||||
|
||||
Now lets extend this with a somewhat artificial example to show something that is simple in `AppDaemon` but very difficult if not impossible using automations. Lets warn someone inside the house that there has been motion outside by flashing a lamp on and off 10 times. We are reacting to the motion as before by turning on the light and setting a timer to turn it off again, but in addition, we set a 1 second timer to run `flash_warning()` which when called, toggles the inside light and sets another timer to call itself a second later. To avoid re-triggering forever, it keeps a count of how many times it has been activated and bales out after 10 iterations.
|
||||
|
||||
```python
|
||||
import appapi
|
||||
|
||||
class FlashyMotionLights(appapi.AppDaemon):
|
||||
|
||||
def initialize(self):
|
||||
self.listen_state(self.motion, "binary_sensor.drive", new = "on")
|
||||
|
||||
def motion(self, entity, attribute, old, new, kwargs):
|
||||
if self.self.sun_down():
|
||||
self.turn_on("light.drive")
|
||||
self.run_in(self.light_off, 60)
|
||||
self.flashcount = 0
|
||||
self.run_in(self.flash_warning, 1)
|
||||
|
||||
def light_off(self, kwargs):
|
||||
self.turn_off("light.drive")
|
||||
|
||||
def flash_warning(self, kwargs):
|
||||
self.toggle("light.living_room")
|
||||
self.flashcount += 1
|
||||
if self.flashcount < 10:
|
||||
self.run_in(self.flash_warning, 1)
|
||||
```
|
||||
|
||||
Of course if I wanted to make this App or its predecessor reusable I would have provided parameters for the sensor, the light to activate on motion, the warning light and even the number of flashes and delay between flashes.
|
||||
|
||||
In addition, Apps can write to `AppDaemon`'s logfiles, and there is a system of constraints that allows yout to control when and under what circumstances Apps and callbacks are active to keep the logic clean and simple.
|
||||
|
||||
I have spent the last few weeks moving all of my (fairly complex) automations over to `APPDaemon` and so far it is working very reliably.
|
||||
|
||||
Some people will maybe look at all of this and say "what use is this, I can already do all of this", and that is fine, as I said this is an alternative not a replacement, but I am hopeful that for some users this will seem a more natural, powerful and nimble way of building potentially very complex automations.
|
||||
|
||||
If this has whet your appetite, feel free to give it a try. You can find it, [here](https://github.com/acockburn/appdaemon), including full installation instructions, an API reference, and a number of fully fleshed out examples.
|
||||
|
||||
Happy Automating!
|
||||
@ -143,11 +143,11 @@ If only 1 location is passed in will measure the distance from home.
|
||||
{% raw %}
|
||||
Using Lat Lng coordinates: {{ distance(123.45, 123.45) }}
|
||||
|
||||
Using State: {{ distance(device_tracker.paulus) }}
|
||||
Using State: {{ distance(states.device_tracker.paulus) }}
|
||||
|
||||
These can also be combined in any combination:
|
||||
{{ distance(123.45, 123.45, device_tracker.paulus) }}
|
||||
{{ distance(device_tracker.anne_therese, device_tracker.paulus) }}{% endraw %}
|
||||
{{ distance(123.45, 123.45, 'device_tracker.paulus') }}
|
||||
{{ distance('device_tracker.anne_therese', 'device_tracker.paulus') }}{% endraw %}
|
||||
```
|
||||
|
||||
### {% linkable_title Closest examples %}
|
||||
@ -157,7 +157,7 @@ Find entities closest to the Home Assistant location:
|
||||
```jinja2
|
||||
{% raw %}
|
||||
Query all entities: {{ closest(states) }}
|
||||
Query all entities of a specific domain: {{ closest(states.device_tracker) }}
|
||||
Query all entities of a specific domain: {{ closest('states.device_tracker') }}
|
||||
Query all entities in group.children: {{ closest('group.children') }}
|
||||
Query all entities in group.children: {{ closest(states.group.children) }}{% endraw %}
|
||||
```
|
||||
|
||||
@ -27,9 +27,19 @@ $ tox
|
||||
|
||||
This will run unit tests against python 3.4 and 3.5 (if both are available locally), as well as run a set of tests which validate `pep8` and `pylint` style of the code.
|
||||
|
||||
You can optionally run tests on only one tox target using the `-e` option to select an environment.
|
||||
#### {% linkable_title Testing Tips %}
|
||||
|
||||
For instance `tox -e lint` will run the linters only, `tox -e py34` will run unit tests only on python 3.4.
|
||||
You can optionally run tests on only one tox target using the `-e` option to select an environment. For instance `tox -e lint` will run the linters only, `tox -e py34` will run unit tests only on python 3.4.
|
||||
|
||||
Tox uses virtual environments under the hood to create isolated testing environments. The Tox virtual environments will get out date when requirements change causing test errors. Run `tox -r` to create new Tox virtual environments.
|
||||
|
||||
During development on a specific file, it can speed up your workflow to just run tests and linting related to the file that you're working on. To run individual files:
|
||||
|
||||
```bash
|
||||
$ flake8 homeassistant/core.py
|
||||
$ pylint homeassistant/core.py
|
||||
$ py.test tests/test_core.py
|
||||
```
|
||||
|
||||
### {% linkable_title Prevent Linter Errors %}
|
||||
|
||||
@ -37,7 +47,7 @@ You can save yourself the hassle of extra commits just to fix style errors by en
|
||||
|
||||
```bash
|
||||
$ pip3 install flake8 flake8-docstrings
|
||||
$ flake8 --install-hook
|
||||
$ flake8 --install-hook=git
|
||||
```
|
||||
|
||||
The flake8-docstrings extension will check docstrings according to [PEP257](https://www.python.org/dev/peps/pep-0257/) when running flake8.
|
||||
|
||||
@ -9,7 +9,9 @@ sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
The `configuration.yaml` file contains the configuration options for components and platforms. To ensure that the given configuration provided by the user is valid we use [voluptuous](https://pypi.python.org/pypi/voluptuous) to check it. Certain entries are optional or could be required for the setup of a platform or a component. Others must be of a certain type or out of an already defined list. This will ensure that the users are notified if something is wrong with a platform or component setup before Home Assistant is running.
|
||||
The `configuration.yaml` file contains the configuration options for components and platforms. To ensure that the given configuration provided by the user is valid we use [voluptuous](https://pypi.python.org/pypi/voluptuous) to check it. Certain entries are optional or could be required for the setup of a platform or a component. Others must be of a definied type or out of an already defined list.
|
||||
|
||||
The goal of testing the configuration is to assure that users have a great experience due to notifications if something is wrong with a platform or component setup before Home Assistant is running.
|
||||
|
||||
Beside the [voluptuous](https://pypi.python.org/pypi/voluptuous) default types are a bunch of custom types available. To get a full overview take a look at the [config_validation.py](https://github.com/home-assistant/home-assistant/blob/master/homeassistant/helpers/config_validation.py) helper.
|
||||
|
||||
@ -57,18 +59,17 @@ PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
|
||||
|
||||
### {% linkable_title Port %}
|
||||
|
||||
As all port numbers are coming out of the range 1 till 65535 a range check should be performed.
|
||||
As all port numbers are coming out of the range 1 till 65535.
|
||||
|
||||
```python
|
||||
DEFAULT_PORT = 993
|
||||
|
||||
PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
|
||||
...
|
||||
vol.Optional(CONF_PORT, default=DEFAULT_PORT):
|
||||
vol.All(vol.Coerce(int), vol.Range(min=1, max=65535)),
|
||||
vol.Optional(CONF_PORT, default=DEFAULT_PORT): cv.port,
|
||||
```
|
||||
|
||||
### {% linkable_title Sensor types %}
|
||||
### {% linkable_title Lists %}
|
||||
|
||||
If a sensor has a pre-defined list of available options it should be tested if the configuration entry matches it.
|
||||
|
||||
@ -81,7 +82,7 @@ SENSOR_TYPES = {
|
||||
PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({
|
||||
...
|
||||
vol.Optional(CONF_MONITORED_VARIABLES, default=[]):
|
||||
[vol.In(SENSOR_TYPES)],
|
||||
vol.All(ensure_list, [vol.In(SENSOR_TYPES)]),
|
||||
```
|
||||
|
||||
|
||||
|
||||
@ -14,5 +14,6 @@ There are a bunch of online services which can help you if you are developing fo
|
||||
- [Coveralls](https://coveralls.io/github/home-assistant/home-assistant)
|
||||
- [Travis CI](https://travis-ci.org/home-assistant/home-assistant)
|
||||
- [gemnasium](https://gemnasium.com/github.com/home-assistant/home-assistant)
|
||||
- [Requires.io](https://requires.io/github/home-assistant/home-assistant/requirements/?branch=dev)
|
||||
- [Pivotal Tracker](https://www.pivotaltracker.com/n/projects/1250084)
|
||||
|
||||
|
||||
@ -129,7 +129,7 @@ HomeAssistant will trigger a event when the zwave network stopping.
|
||||
- alias: ZWave network is stopping
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: zwave.network_start
|
||||
event_type: zwave.network_stop
|
||||
```
|
||||
|
||||
**zwave.node_event**
|
||||
|
||||
BIN
source/images/supported_brands/snapcast.png
Normal file
BIN
source/images/supported_brands/snapcast.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
@ -15,8 +15,8 @@ hide_github_edit: true
|
||||
<div class="grid">
|
||||
<div class="grid__item one-third lap-one-third palm-one-whole">
|
||||
<div class='current-version material-card text'>
|
||||
<h1>Current Version: 0.26.2</h1>
|
||||
Released: <span class='release-date'>August 15, 2016</span>
|
||||
<h1>Current Version: 0.26.3</h1>
|
||||
Released: <span class='release-date'>August 19, 2016</span>
|
||||
|
||||
<div class='links'>
|
||||
<a href='/blog/2016/08/13/foursquare-fast-com-ffmpeg-gpsd/'>Release notes</a>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user