Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
+
Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
It’s time for the August release and there is some serious good stuff this time. The core of Home Assistant has gone some serious clean up and a bump in test coverage thanks to @balloob. If you’re a developer, make sure you read up on the deprecation notices. @fabaff did another great round of documentating all the various components.
MQTT Support
- The big new addition in this release is the support for the MQTT protocol by @fabaff with some help from @balloob. It will now be possible to integrate any IoT device that talks via MQTT. For the initial release we support connecting Home Assistant to a broker (no TLS yet). Components can now subscribe and publish to MQTT topics (see the example) and also support for the automation component has been added. For more information, see the MQTT component page.
+ The big new addition in this release is the support for the MQTT protocol by @fabaff with some help from @balloob. It will now be possible to integrate any IoT device that talks via MQTT. For the initial release we support connecting Home Assistant to a broker (no TLS yet). Components can now subscribe and publish to MQTT topics (see the example) and also support for the automation component has been added. For more information, see the MQTT component page.
# Example configuration.yaml entry
diff --git a/blog/2015/08/26/laundry-automation-with-moteino-mqtt-and-home-assistant/index.html b/blog/2015/08/26/laundry-automation-with-moteino-mqtt-and-home-assistant/index.html
index 018845fe3c..61de75ccc4 100644
--- a/blog/2015/08/26/laundry-automation-with-moteino-mqtt-and-home-assistant/index.html
+++ b/blog/2015/08/26/laundry-automation-with-moteino-mqtt-and-home-assistant/index.html
@@ -132,7 +132,7 @@
Status of the dryer and washer in Home Assistant
-
Next I wrote scripts that are run whenever the washer or dryer completes a load. This is triggered by the automation component. When the laundry is complete I have the lights in the house turn red and notify me via PushBullet. Once the laundry is taken care of another script runs that sets the lights back to normal. So far it has been very helpful and very reliable.
+
Next I wrote scripts that are run whenever the washer or dryer completes a load. This is triggered by the automation component. When the laundry is complete I have the lights in the house turn red and notify me via PushBullet. Once the laundry is taken care of another script runs that sets the lights back to normal. So far it has been very helpful and very reliable.
As part of this release we did some cleanup which introduced backwards incompatible changes:
Heat Control thermostat no longer includes scheduling features.
-This feature has been removed completely. Use the automation component instead to control target temperature.
+This feature has been removed completely. Use the automation component instead to control target temperature.
Config changed for calling a service from a script. execute_service: has been replaced with service:. See component page for example. The old method will continue working for some time.
Thanks to Python, users are running Home Assistant on the most popular Linux distributions and other operating systems including OS X and Microsoft Windows. One quarter of the operating systems are unknown which leads to the assumption that it is possible to run Home Assistant on most of the available operation systems today. We hope that *BSD users have fun too. The Hardware platform of choice seems to be x86_64 and ARM.
-
Of course most users are running with the automation component otherwise it would make much sense to use Home Assistant. The sun component is used a lot too. We hope that this is not because this component is enabled by default.
+
Of course most users are running with the automation component otherwise it would make much sense to use Home Assistant. The sun component is used a lot too. We hope that this is not because this component is enabled by default.
The Alarm control panels and the camera component are both used by around one third of the participants of the survey. It’s safe to say that they cover a niche, but they will gain momentum when people discover how they can build alarm systems with Home Assistant.
diff --git a/blog/2016/01/30/insteon-lifx-twitter-and-zigbee/index.html b/blog/2016/01/30/insteon-lifx-twitter-and-zigbee/index.html
index 087612ea2a..5d815b7fe9 100644
--- a/blog/2016/01/30/insteon-lifx-twitter-and-zigbee/index.html
+++ b/blog/2016/01/30/insteon-lifx-twitter-and-zigbee/index.html
@@ -131,7 +131,7 @@ Example of the new views in the frontend. Learn mor
Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
+
Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
+
Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
Thanks to Python, users are running Home Assistant on the most popular Linux distributions and other operating systems including OS X and Microsoft Windows. One quarter of the operating systems are unknown which leads to the assumption that it is possible to run Home Assistant on most of the available operation systems today. We hope that *BSD users have fun too. The Hardware platform of choice seems to be x86_64 and ARM.
-
Of course most users are running with the automation component otherwise it would make much sense to use Home Assistant. The sun component is used a lot too. We hope that this is not because this component is enabled by default.
+
Of course most users are running with the automation component otherwise it would make much sense to use Home Assistant. The sun component is used a lot too. We hope that this is not because this component is enabled by default.
The Alarm control panels and the camera component are both used by around one third of the participants of the survey. It’s safe to say that they cover a niche, but they will gain momentum when people discover how they can build alarm systems with Home Assistant.
diff --git a/blog/categories/user-stories/atom.xml b/blog/categories/user-stories/atom.xml
index a0b526ced5..7587e8fc00 100644
--- a/blog/categories/user-stories/atom.xml
+++ b/blog/categories/user-stories/atom.xml
@@ -4,7 +4,7 @@
<![CDATA[Category: User-Stories | Home Assistant]]>
- 2016-04-23T18:30:58+00:00
+ 2016-04-24T07:01:43+00:00https://home-assistant.io/
@@ -42,7 +42,7 @@
Status of the dryer and washer in Home Assistant
-
Next I wrote scripts that are run whenever the washer or dryer completes a load. This is triggered by the automation component. When the laundry is complete I have the lights in the house turn red and notify me via PushBullet. Once the laundry is taken care of another script runs that sets the lights back to normal. So far it has been very helpful and very reliable.
+
Next I wrote scripts that are run whenever the washer or dryer completes a load. This is triggered by the automation component. When the laundry is complete I have the lights in the house turn red and notify me via PushBullet. Once the laundry is taken care of another script runs that sets the lights back to normal. So far it has been very helpful and very reliable.
Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
+
Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson)
diff --git a/blog/posts/2/index.html b/blog/posts/2/index.html
index f59cc893b2..f09c9aa5d0 100644
--- a/blog/posts/2/index.html
+++ b/blog/posts/2/index.html
@@ -434,7 +434,7 @@ Example of the new views in the frontend. Learn mor
diff --git a/blog/posts/3/index.html b/blog/posts/3/index.html
index bbf650a97c..17dc4705f8 100644
--- a/blog/posts/3/index.html
+++ b/blog/posts/3/index.html
@@ -635,7 +635,7 @@ Home Assistant will keep track of historical values and allow you to integrate i
diff --git a/blog/posts/4/index.html b/blog/posts/4/index.html
index b081651473..40d380c1f5 100644
--- a/blog/posts/4/index.html
+++ b/blog/posts/4/index.html
@@ -516,7 +516,7 @@ Inspried by a @balloob. If you’re a developer, make sure you read up on the deprecation notices. @fabaff did another great round of documentating all the various components.
MQTT Support
- The big new addition in this release is the support for the MQTT protocol by @fabaff with some help from @balloob. It will now be possible to integrate any IoT device that talks via MQTT. For the initial release we support connecting Home Assistant to a broker (no TLS yet). Components can now subscribe and publish to MQTT topics (see the example) and also support for the automation component has been added. For more information, see the MQTT component page.
+ The big new addition in this release is the support for the MQTT protocol by @fabaff with some help from @balloob. It will now be possible to integrate any IoT device that talks via MQTT. For the initial release we support connecting Home Assistant to a broker (no TLS yet). Components can now subscribe and publish to MQTT topics (see the example) and also support for the automation component has been added. For more information, see the MQTT component page.
# Example configuration.yaml entry
diff --git a/components/automation/index.html b/components/automation/index.html
index 25059f200d..6837b6bf1c 100644
--- a/components/automation/index.html
+++ b/components/automation/index.html
@@ -89,396 +89,7 @@
-
This page will go into more detail about the various options the automation component offers. If you haven’t yet, read the getting started page on automation.
-
-
A configuration section of an automation requires a trigger and an action section. condition and condition_type are optional. To keep this page compact, all following sections will not show the full configuration but only the relevant part.
# Example of entry in configuration.yaml
-automation:
-# Turns on lights 1 hour before sunset if people are home
-# and if people get home between 16:00-23:00
-- alias: 'Rule 1 Light on in the evening'
- trigger:
- # Prefix the first line of each trigger configuration
- # with a '-' to enter multiple
- - platform: sun
- event: sunset
- offset: '-01:00:00'
- - platform: state
- entity_id: group.all_devices
- state: 'home'
- condition:
- # Prefix the first line of each condition configuration
- # with a '-'' to enter multiple
- - platform: state
- entity_id: group.all_devices
- state: 'home'
- - platform: time
- after: '16:00:00'
- before: '23:00:00'
- action:
- service: homeassistant.turn_on
- entity_id: group.living_room
-
-# Turn off lights when everybody leaves the house
-- alias: 'Rule 2 - Away Mode'
- trigger:
- platform: state
- entity_id: group.all_devices
- state: 'not_home'
- action:
- service: light.turn_off
- entity_id: group.all_lights
-
-# Notify when Paulus leaves the house in the evening
-- alias: 'Leave Home notification'
- trigger:
- platform: zone
- event: leave
- zone: zone.home
- entity_id: device_tracker.paulus
- condition:
- platform: time
- after: '20:00'
- action:
- service: notify.notify
- data:
- message: 'Paulus left the house'
-
-
-
-
-
Triggers
-
-
Triggers are what starts the processing of an automation rule. It is possible to specify multiple triggers for the same rule. Once a trigger starts, Home Assistant will validate the conditions, if any, and call the action.
-
-
Event trigger
-
Triggers when an event is being processed. Events are the raw building blocks of Home Assistant. You can match events on just the event name or also require specific event data to be present.
On state change of a specified entity, attempts to parse the state as a number and triggers if value is above and/or below a threshold.
-
-
-
automation:
- trigger:
- platform: numeric_state
- entity_id: sensor.temperature
- # Optional
- value_template: '{{ state.attributes.battery }}'
- # At least one of the following required
- above: 17
- below: 25
-
-
-
-
-
State trigger
-
-
Triggers when the state of an entity changes. If only entity_id given will match all state changes.
-
-
-
automation:
- trigger:
- platform: state
- entity_id: device_tracker.paulus
- # Optional
- from: 'not_home'
- to: 'home'
- # If given, will trigger when state has been the to state for X time.
- for:
- hours: 1
- minutes: 10
- seconds: 5
-
-
-
-
-
- Use quotes around your values for from and to to avoid the YAML parser interpreting values as booleans.
-
-
-
Sun trigger
-
Trigger when the sun is setting or rising. An optional time offset can be given to have it trigger for example 45 minutes before sunset, when dusk is setting in.
-
-
-
automation:
- trigger:
- platform: sun
- # Possible values: sunset, sunrise
- event: sunset
- # Optional time offset. This example is 45 minutes.
- offset: '-00:45:00'
-
-
-
-
-
Template trigger
-
-
Template triggers work by evaluating a template on each state change. The trigger will fire if the state change caused the template to render ‘true’. This is achieved by having the template result in a true boolean expression ({{ is_state('device_tracker.paulus', 'home') }}) or by having the template render ‘true’ (example below).
Time can be triggered in many ways. The most common is to specify after and trigger at a specific point in time each day. Alternatively, you can also match if the hour, minute or second of the current time has a specific value. You can prefix the value with a / to match whenever the value is divisible by that number. You cannot use after together with hour, minute or second.
-
-
-
automation:
- trigger:
- platform: time
- # Matches every hour at 5 minutes past whole
- minutes: 5
- seconds: 0
-
-automation 2:
- trigger:
- platform: time
- # When 'after' is used, you cannot also match on hour, minute, seconds.
- # Military time format.
- after: '15:32:00'
-
-automation 3:
- trigger:
- platform: time
- # You can also match on interval. This will match every 5 minutes
- minutes: '/5'
- seconds: 0
-
-
-
-
-
Zone trigger
-
-
Zone triggers can trigger when an entity is entering or leaving the zone. For zone automation to work, you need to have setup a device tracker platform that supports reporting GPS coordinates. Currently this is limited to the OwnTracks platform as well as the iCloud platform.
-
-
-
automation:
- trigger:
- platform: zone
- entity_id: device_tracker.paulus
- zone: zone.home
- # Event is either enter or leave
- event: enter
-
-
-
-
-
Conditions
-
-
Conditions are an optional part of an automation rule and be used to prevent an action from happening when triggered. Conditions look very similar to triggers but are very different. A trigger will look at events happening in the system while a condition only looks at how the system looks right now. A trigger can observe that a switch is being turned on. A condition can only see if a switch is currently on or off.
-
-
An automation rule can have multiple conditions. By default the action will only fire if all conditions pass. An optional key condition_type: 'or' can be set on the automation rule to fire action if any condition matches. In the example below, the automation would trigger if the time is before 05:00 OR after 20:00.
-
-
-
automation:
- condition_type: or
- condition:
- - platform: time
- before: '05:00'
- - platform: time
- after: '20:00'
-
-
-
-
-
If your triggers and conditions are exactly the same, you can use a shortcut to specify conditions. In this case, triggers that are not valid conditions will be ignored.
-
-
-
automation:
- condition: use_trigger_values
-
-
-
-
-
Numeric state condition
-
-
This type of condition attempts to parse the state of specified entity as a number and triggers if the value matches all of the above or below thresholds.
-Either above or below, or both need to be specified. If both are used, the condition is true when the value is >= before *and** < after.
-You can optionally use a value_template to make the value of the entity the same type of value as the condition.
automation:
- condition:
- platform: state
- entity_id: device_tracker.paulus
- state: not_home
- # optional: trigger only if state was this for last X time.
- for:
- hours: 1
- minutes: 10
- seconds: 5
-
-
-
-
-
Sun condition
-
-
The sun condition can test if the sun has already set or risen when a trigger occurs. The before and after keys can only be set to sunset or sunrise. They have a corresponding optional offset value (before_offset, after_offset) that can be added, similar to the sun trigger.
-
-
-
automation:
- condition:
- platform: sun
- after: sunset
- # Optional offset value
- after_offset: "-1:00:00"
-
-
-
-
-
Template condition
-
-
The template condition will test if the given template renders a value equal to true. This is achieved by having the template result in a true boolean expression or by having the template render ‘true’.
The time condition can test if it is after a specified time, before a specified time or if it is a certain day of the week
-
-
-
automation:
- condition:
- platform: time
- # At least one of the following is required.
- after: '15:00:00'
- before: '23:00:00'
- weekday:
- - mon
- - wed
- - fri
-
-
-
-
-
Valid values for weekday are (sun, mon, tue, wed, thu, fri & sat)
-
-
Zone condition
-
-
Zone conditions test if an entity is in a certain zone. For zone automation to work, you need to have setup a device tracker platform that supports reporting GPS coordinates. Currently this is limited to the OwnTracks platform as well as the iCloud platform.
When an automation rule fires, it calls a service. For this service you can specify the entity_id that it should apply to and optional service parameters (to specify for example the brightness).
-
-
-
automation:
- # Change the light in the kitchen and living room to 150 brightness and color red.
- action:
- service: homeassistant.turn_on
- entity_id:
- - light.kitchen
- - light.living_room
- data:
- brightness: 150
- rgb_color: [255, 0, 0]
-
-
-
-
-
-
automation:
- # Notify me on my mobile phone of an event
- action:
- service: notify.notify
- data:
- message: Something just happened, better take a look!
-
-
-
-
-
If you want to specify multiple services to be called, or to include a delay, have a look at the script component. If you want to describe the desired state of certain entities, check out the scene component.
-
-
Troubleshooting
-
-
You can verify that your automation rules are being initialized correctly by watching both the realtime logs (homeassistant.log in the configuration directory) and also the Logbook. The realtime logs will show the rules being initialized (once for each trigger), example:
-
-
-
INFO [homeassistant.components.automation] Initialized rule Rainy Day
-INFO [homeassistant.components.automation] Initialized rule Rainy Day
-INFO [homeassistant.components.automation] Initialized rule Rainy Day
-INFO [homeassistant.components.automation] Initialized rule Rain is over
-
-
-
-
-
The Logbook component will show a line entry when an automation is triggered. You can look at the previous entry to determine which trigger in the rule triggered the event.
-
-
+
Please see the getting started section for in-depth documentation on how to use the automation compnoent.
diff --git a/components/mqtt/index.html b/components/mqtt/index.html
index 4082140a07..409ff75c8b 100644
--- a/components/mqtt/index.html
+++ b/components/mqtt/index.html
@@ -265,7 +265,7 @@ Home Assistant will automatically load the correct certificate if you connect to
For Google Mail (smtp.gmail.com) an additional step in the setup process is needed. Google has some extra layers of protection
which need special attention. By default, the usage by external applications, especially scripts, is limited. Visit the Less secure apps page and enable it.
The notification component supports specifying templates for both the message and the title. This will allow you to use the current state of Home Assistant in your notifications.
-
In an action of your automation setup it could look like this with a customized subject.
+
In an action of your automation setup it could look like this with a customized subject.
The proximity component allows you to monitor the proximity of devices to a particular zone and the direction of travel. The result is an entity created in Home Assistant which maintains the proximity data.
-
This component is useful to reduce the number of automation rules required when wanting to perform automations based on locations outside a particular zone. The zone and state based triggers allow similar control but the number of rules grows exponentially when factors such as direction of travel need to be taken into account.
+
This component is useful to reduce the number of automation rules required when wanting to perform automations based on locations outside a particular zone. The zone and state based triggers allow similar control but the number of rules grows exponentially when factors such as direction of travel need to be taken into account.
# Example configuration.yaml entry
diff --git a/components/zone/index.html b/components/zone/index.html
index 8a3e7f6fe9..d74570404c 100644
--- a/components/zone/index.html
+++ b/components/zone/index.html
@@ -89,7 +89,7 @@
-
Zones allow you to specify certain regions on earth (for now). When a device tracker sees a device to be within a zone, the state will take the name from the zone. Zones can also be used as a trigger or condition inside automation setups.
+
Zones allow you to specify certain regions on earth (for now). When a device tracker sees a device to be within a zone, the state will take the name from the zone. Zones can also be used as a trigger or condition inside automation setups.
Zones support the usual method to specify multiple zones, use keys zone:, zone 2: etc.
This is a community curated list of different ways to use Home Assistant. Most of these examples are using the automation component and other built-in automation related and organization components available.
+
This is a community curated list of different ways to use Home Assistant. Most of these examples are using the automation component and other built-in automation related and organization components available.
When an automation rule fires, it calls a service. For this service you can specify the entity_id that it should apply to and optional service parameters (to specify for example the brightness).
+
+
+
automation:
+ # Change the light in the kitchen and living room to 150 brightness and color red.
+ action:
+ service: homeassistant.turn_on
+ entity_id:
+ - light.kitchen
+ - light.living_room
+ data:
+ brightness: 150
+ rgb_color: [255, 0, 0]
+
+
+
+
+
+
automation:
+ # Notify me on my mobile phone of an event
+ action:
+ service: notify.notify
+ data:
+ message: Something just happened, better take a look!
+
+
+
+
+
If you want to specify multiple services to be called, or to include a delay, have a look at the script component. If you want to describe the desired state of certain entities, check out the scene component.
Conditions are an optional part of an automation rule and be used to prevent an action from happening when triggered. Conditions look very similar to triggers but are very different. A trigger will look at events happening in the system while a condition only looks at how the system looks right now. A trigger can observe that a switch is being turned on. A condition can only see if a switch is currently on or off.
+
+
An automation rule can have multiple conditions. By default the action will only fire if all conditions pass. An optional key condition_type: 'or' can be set on the automation rule to fire action if any condition matches. In the example below, the automation would trigger if the time is before 05:00 OR after 20:00.
+
+
+
automation:
+ condition_type: or
+ condition:
+ - platform: time
+ before: '05:00'
+ - platform: time
+ after: '20:00'
+
+
+
+
+
If your triggers and conditions are exactly the same, you can use a shortcut to specify conditions. In this case, triggers that are not valid conditions will be ignored.
+
+
+
automation:
+ condition: use_trigger_values
+
+
+
+
+
Numeric state condition
+
+
This type of condition attempts to parse the state of specified entity as a number and triggers if the value matches all of the above or below thresholds.
+Either above or below, or both need to be specified. If both are used, the condition is true when the value is >= before *and** < after.
+You can optionally use a value_template to make the value of the entity the same type of value as the condition.
automation:
+ condition:
+ platform: state
+ entity_id: device_tracker.paulus
+ state: not_home
+ # optional: trigger only if state was this for last X time.
+ for:
+ hours: 1
+ minutes: 10
+ seconds: 5
+
+
+
+
+
Sun condition
+
+
The sun condition can test if the sun has already set or risen when a trigger occurs. The before and after keys can only be set to sunset or sunrise. They have a corresponding optional offset value (before_offset, after_offset) that can be added, similar to the sun trigger.
+
+
+
automation:
+ condition:
+ platform: sun
+ after: sunset
+ # Optional offset value
+ after_offset: "-1:00:00"
+
+
+
+
+
Template condition
+
+
The template condition will test if the [given template][template] renders a value equal to true. This is achieved by having the template result in a true boolean expression or by having the template render ‘true’.
The time condition can test if it is after a specified time, before a specified time or if it is a certain day of the week
+
+
+
automation:
+ condition:
+ platform: time
+ # At least one of the following is required.
+ after: '15:00:00'
+ before: '23:00:00'
+ weekday:
+ - mon
+ - wed
+ - fri
+
+
+
+
+
Valid values for weekday are (sun, mon, tue, wed, thu, fri & sat)
+
+
Zone condition
+
+
Zone conditions test if an entity is in a certain zone. For zone automation to work, you need to have setup a device tracker platform that supports reporting GPS coordinates. Currently this is limited to the OwnTracks platform and the iCloud platform.
Before we dive deeper into what every piece of automation can do, let’s look at a simple automation rule: Turn on the lights when the sun sets
+
+
In this example, we are defining a trigger to track the sunset and tell it to fire when the sun is setting. When this event is triggered, the service light.turn_on is called without any parameters. Because we specify no parameters, it will turn on all the lights.
+
+
+
# Example configuration.yaml entry
+automation:
+ alias: Turn on light when sun sets
+ trigger:
+ platform: sun
+ event: sunset
+ action:
+ service: light.turn_on
+
+
+
+
+
After a few days of running this automation rule you come to realize that this automation rule is not good enough. It was already dark when the lights went on and the one day you weren’t home, the lights turned on anyway. Time for some tweaking. Let’s add an offset to the sunset trigger and a condition to only turn on the lights if anyone is home.
+
+
+
# Example configuration.yaml entry
+automation:
+ alias: Turn on light when sun sets
+ trigger:
+ platform: sun
+ event: sunset
+ offset: "-01:00:00"
+ condition:
+ platform: state
+ entity_id: group.all_devices
+ state: home
+ action:
+ service: light.turn_on
+
+
+
+
+
Now you’re happy and all is good. You start to like this automation business and buy some more lights, this time you put them in the bedroom. But what you now realize is that when the sun is setting, the lights in the bedroom are also being turned on! Time to tweak the automation to only turn on the living room lights.
+
+
The first thing you do is to look at the entities in the developer tools (second icon) in the app. You see the names of your lights and you write them down: light.table_lamp, light.bedroom, light.ceiling.
+
+
Instead of hard coding the entity IDs of the lights in the automation rule, we will set up a group. This will allow us to see the living room separate in the app and be able to address it from automation rules.
+
+
So we tweak the config to add the group and have the automation rule only turn on the group.
+
+
+
# Example configuration.yaml entry
+group:
+ living_room:
+ - light.table_lamp
+ - light.ceiling
+
+automation:
+ alias: Turn on light when sun sets
+ trigger:
+ platform: sun
+ event: sunset
+ offset: "-01:00:00"
+ condition:
+ platform: state
+ entity_id: group.all_devices
+ state: home
+ action:
+ service: light.turn_on
+ entity_id: group.living_room
+
+
+
+
+
Christmas is coming along and you decide to buy a remote switch to control the Christmas lights from Home Assistant. You can’t claim to live in the house of the future if you’re still manually turning on your Christmas lights!
+
+
We hook the switch up to Home Assistant and grab the entity ID0 from the developer tools: switch.christmas_lights. We will update the group to include the switch and will change our action. We are no longer able to call light.turn_on because we also want to turn on a switch. This is where homeassistant.turn_on comes to the rescue. This service is capable of turning any entity on.
+
+
+
# Example configuration.yaml entry
+group:
+ living_room:
+ - light.table_lamp
+ - light.ceiling
+ - switch.christmas_lights
+
+automation:
+ alias: Turn on light when sun sets
+ trigger:
+ platform: sun
+ event: sunset
+ offset: "-01:00:00"
+ condition:
+ platform: state
+ entity_id: group.all_devices
+ state: home
+ action:
+ service: homeassistant.turn_on
+ entity_id: group.living_room
+
# Example of entry in configuration.yaml
+automation:
+# Turns on lights 1 hour before sunset if people are home
+# and if people get home between 16:00-23:00
+- alias: 'Rule 1 Light on in the evening'
+ trigger:
+ # Prefix the first line of each trigger configuration
+ # with a '-' to enter multiple
+ - platform: sun
+ event: sunset
+ offset: '-01:00:00'
+ - platform: state
+ entity_id: group.all_devices
+ state: 'home'
+ condition:
+ # Prefix the first line of each condition configuration
+ # with a '-'' to enter multiple
+ - platform: state
+ entity_id: group.all_devices
+ state: 'home'
+ - platform: time
+ after: '16:00:00'
+ before: '23:00:00'
+ action:
+ service: homeassistant.turn_on
+ entity_id: group.living_room
+
+# Turn off lights when everybody leaves the house
+- alias: 'Rule 2 - Away Mode'
+ trigger:
+ platform: state
+ entity_id: group.all_devices
+ state: 'not_home'
+ action:
+ service: light.turn_off
+ entity_id: group.all_lights
+
+# Notify when Paulus leaves the house in the evening
+- alias: 'Leave Home notification'
+ trigger:
+ platform: zone
+ event: leave
+ zone: zone.home
+ entity_id: device_tracker.paulus
+ condition:
+ platform: time
+ after: '20:00'
+ action:
+ service: notify.notify
+ data:
+ message: 'Paulus left the house'
+
Triggers are what starts the processing of an automation rule. It is possible to specify multiple triggers for the same rule. Once a trigger starts, Home Assistant will validate the conditions, if any, and call the action.
+
+
Event trigger
+
Triggers when an event is being processed. Events are the raw building blocks of Home Assistant. You can match events on just the event name or also require specific event data to be present.
On state change of a specified entity, attempts to parse the state as a number and triggers if value is above and/or below a threshold.
+
+
+
automation:
+ trigger:
+ platform: numeric_state
+ entity_id: sensor.temperature
+ # Optional
+ value_template: '{{ state.attributes.battery }}'
+ # At least one of the following required
+ above: 17
+ below: 25
+
+
+
+
+
State trigger
+
+
Triggers when the state of an entity changes. If only entity_id given will match all state changes.
+
+
+
automation:
+ trigger:
+ platform: state
+ entity_id: device_tracker.paulus
+ # Optional
+ from: 'not_home'
+ to: 'home'
+ # If given, will trigger when state has been the to state for X time.
+ for:
+ hours: 1
+ minutes: 10
+ seconds: 5
+
+
+
+
+
+ Use quotes around your values for from and to to avoid the YAML parser interpreting values as booleans.
+
+
+
Sun trigger
+
Trigger when the sun is setting or rising. An optional time offset can be given to have it trigger for example 45 minutes before sunset, when dusk is setting in.
+
+
+
automation:
+ trigger:
+ platform: sun
+ # Possible values: sunset, sunrise
+ event: sunset
+ # Optional time offset. This example is 45 minutes.
+ offset: '-00:45:00'
+
+
+
+
+
Template trigger
+
+
Template triggers work by evaluating a [template] on each state change. The trigger will fire if the state change caused the template to render ‘true’. This is achieved by having the template result in a true boolean expression ({{ is_state('device_tracker.paulus', 'home') }}) or by having the template render ‘true’ (example below).
Time can be triggered in many ways. The most common is to specify after and trigger at a specific point in time each day. Alternatively, you can also match if the hour, minute or second of the current time has a specific value. You can prefix the value with a / to match whenever the value is divisible by that number. You cannot use after together with hour, minute or second.
+
+
+
automation:
+ trigger:
+ platform: time
+ # Matches every hour at 5 minutes past whole
+ minutes: 5
+ seconds: 0
+
+automation 2:
+ trigger:
+ platform: time
+ # When 'after' is used, you cannot also match on hour, minute, seconds.
+ # Military time format.
+ after: '15:32:00'
+
+automation 3:
+ trigger:
+ platform: time
+ # You can also match on interval. This will match every 5 minutes
+ minutes: '/5'
+ seconds: 0
+
+
+
+
+
Zone trigger
+
+
Zone triggers can trigger when an entity is entering or leaving the zone. For zone automation to work, you need to have setup a device tracker platform that supports reporting GPS coordinates. Currently this is limited to the OwnTracks platform as well as the iCloud platform.
+
+
+
automation:
+ trigger:
+ platform: zone
+ entity_id: device_tracker.paulus
+ zone: zone.home
+ # Event is either enter or leave
+ event: enter
+
You can verify that your automation rules are being initialized correctly by watching both the realtime logs (homeassistant.log in the configuration directory) and also the Logbook. The realtime logs will show the rules being initialized (once for each trigger), example:
+
+
+
INFO [homeassistant.components.automation] Initialized rule Rainy Day
+INFO [homeassistant.components.automation] Initialized rule Rainy Day
+INFO [homeassistant.components.automation] Initialized rule Rainy Day
+INFO [homeassistant.components.automation] Initialized rule Rain is over
+
+
+
+
+
The Logbook component will show a line entry when an automation is triggered. You can look at the previous entry to determine which trigger in the rule triggered the event.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/getting-started/automation/index.html b/getting-started/automation/index.html
index 0e976e3faf..b080211e75 100644
--- a/getting-started/automation/index.html
+++ b/getting-started/automation/index.html
@@ -89,7 +89,7 @@
-
When all your devices are set up it’s time to put the cherry on the pie: automation. Home Assistant offers a few built-in automations but mainly you’ll be using the automation component to set up your own rules.
+
When all your devices are set up it’s time to put the cherry on the pie: automation. Home Assistant offers a few built-in automations but mainly you’ll be using the automation component to set up your own rules.
The basics of automation
@@ -138,113 +138,13 @@
A service can be called to have Home Assistant perform an action. Turn on a light, run a script or enable a scene. Each service has a domain and a name. For example the service light.turn_on is capable of turning on any light device in your system. Services can be passed parameters to for example tell which device to turn on or what color to use.
-
Creating your first automation rule
-
-
Before we dive deeper into what every piece of automation can do, let’s look at a simple automation rule: Turn on the lights when the sun sets
-
-
In this example, we are defining a trigger to track the sunset and tell it to fire when the sun is setting. When this event is triggered, the service light.turn_on is called without any parameters. Because we specify no parameters, it will turn on all the lights.
-
-
-
# Example configuration.yaml entry
-automation:
- alias: Turn on light when sun sets
- trigger:
- platform: sun
- event: sunset
- action:
- service: light.turn_on
-
-
-
-
-
After a few days of running this automation rule you come to realize that this automation rule is not good enough. It was already dark when the lights went on and the one day you weren’t home, the lights turned on anyway. Time for some tweaking. Let’s add an offset to the sunset trigger and a condition to only turn on the lights if anyone is home.
-
-
-
# Example configuration.yaml entry
-automation:
- alias: Turn on light when sun sets
- trigger:
- platform: sun
- event: sunset
- offset: "-01:00:00"
- condition:
- platform: state
- entity_id: group.all_devices
- state: home
- action:
- service: light.turn_on
-
-
-
-
-
Now you’re happy and all is good. You start to like this automation business and buy some more lights, this time you put them in the bedroom. But what you now realize is that when the sun is setting, the lights in the bedroom are also being turned on! Time to tweak the automation to only turn on the living room lights.
-
-
The first thing you do is to look at the entities in the developer tools (second icon) in the app. You see the names of your lights and you write them down: light.table_lamp, light.bedroom, light.ceiling.
-
-
Instead of hard coding the entity IDs of the lights in the automation rule, we will set up a group. This will allow us to see the living room separate in the app and be able to address it from automation rules.
-
-
So we tweak the config to add the group and have the automation rule only turn on the group.
-
-
-
# Example configuration.yaml entry
-group:
- living_room:
- - light.table_lamp
- - light.ceiling
-
-automation:
- alias: Turn on light when sun sets
- trigger:
- platform: sun
- event: sunset
- offset: "-01:00:00"
- condition:
- platform: state
- entity_id: group.all_devices
- state: home
- action:
- service: light.turn_on
- entity_id: group.living_room
-
-
-
-
-
Christmas is coming along and you decide to buy a remote switch to control the Christmas lights from Home Assistant. You can’t claim to live in the house of the future if you’re still manually turning on your Christmas lights!
-
-
We hook the switch up to Home Assistant and grab the entity ID0 from the developer tools: switch.christmas_lights. We will update the group to include the switch and will change our action. We are no longer able to call light.turn_on because we also want to turn on a switch. This is where homeassistant.turn_on comes to the rescue. This service is capable of turning any entity on.
-
-
-
# Example configuration.yaml entry
-group:
- living_room:
- - light.table_lamp
- - light.ceiling
- - switch.christmas_lights
-
-automation:
- alias: Turn on light when sun sets
- trigger:
- platform: sun
- event: sunset
- offset: "-01:00:00"
- condition:
- platform: state
- entity_id: group.all_devices
- state: home
- action:
- service: homeassistant.turn_on
- entity_id: group.living_room
-
-
-
-
Further reading
We went over the basics of creating a home automation rule. Now, go automate!
diff --git a/getting-started/autostart-macos/index.html b/getting-started/autostart-macos/index.html
index d59f6dd0e8..61c2b2c6b8 100644
--- a/getting-started/autostart-macos/index.html
+++ b/getting-started/autostart-macos/index.html
@@ -146,10 +146,18 @@ Home Assistant has been uninstalled.
diff --git a/getting-started/configuration/index.html b/getting-started/configuration/index.html
index 1a6954629f..381bf2e7f4 100644
--- a/getting-started/configuration/index.html
+++ b/getting-started/configuration/index.html
@@ -244,10 +244,18 @@ The other properties (like name) are specified using mappings. Note that the sec
diff --git a/getting-started/customizing-devices/index.html b/getting-started/customizing-devices/index.html
index 8749ac847b..b8e12bc899 100644
--- a/getting-started/customizing-devices/index.html
+++ b/getting-started/customizing-devices/index.html
@@ -156,10 +156,18 @@ You may have to create the www directory yourself as it is not made
diff --git a/getting-started/devices/index.html b/getting-started/devices/index.html
index fc351c684a..fb3212e204 100644
--- a/getting-started/devices/index.html
+++ b/getting-started/devices/index.html
@@ -192,10 +192,18 @@ Each group exists of a name and a list of entity IDs. Entity IDs can be retrieve
diff --git a/getting-started/installation-docker/index.html b/getting-started/installation-docker/index.html
index 68c6cbe715..8c75aebf58 100644
--- a/getting-started/installation-docker/index.html
+++ b/getting-started/installation-docker/index.html
@@ -150,10 +150,18 @@ When using boot2docker on OS X you are unable to map the local time to your Dock
diff --git a/getting-started/installation-synology/index.html b/getting-started/installation-synology/index.html
index 1e231dc9f0..a2475fb090 100644
--- a/getting-started/installation-synology/index.html
+++ b/getting-started/installation-synology/index.html
@@ -373,10 +373,18 @@ That’s it… you’re all set to go
diff --git a/getting-started/presence-detection/index.html b/getting-started/presence-detection/index.html
index ab4b8cb70b..cf8c20a1d2 100644
--- a/getting-started/presence-detection/index.html
+++ b/getting-started/presence-detection/index.html
@@ -121,7 +121,7 @@ OwnTracks communicates directly with your MQTT broker, no data will pass through
-
Home Assistant will know the location of your device if you are using OwnTracks. By setting up zones you will be able to add names to the locations of your devices. This way you can easily spot on the state page where the people in your house are and use it as triggers and conditions for automation.
+
Home Assistant will know the location of your device if you are using OwnTracks. By setting up zones you will be able to add names to the locations of your devices. This way you can easily spot on the state page where the people in your house are and use it as triggers and conditions for automation.
diff --git a/getting-started/troubleshooting-configuration/index.html b/getting-started/troubleshooting-configuration/index.html
index 824c94aa52..6dd6bbe005 100644
--- a/getting-started/troubleshooting-configuration/index.html
+++ b/getting-started/troubleshooting-configuration/index.html
@@ -207,10 +207,18 @@ Whenever you report an issue, be aware that we are volunteers who do not have ac
The big new addition in this release is the support for the MQTT protocol by 
+ 
![diff --git a/blog/categories/website/atom.xml b/blog/categories/website/atom.xml index fa3cdab27c..5f13852ef7 100644 --- a/blog/categories/website/atom.xml +++ b/blog/categories/website/atom.xml @@ -4,7 +4,7 @@ <![CDATA[Category: Website | Home Assistant]]> - 2016-04-23T18:30:58+00:00 + 2016-04-24T07:01:43+00:00 https://home-assistant.io/ diff --git a/blog/index.html b/blog/index.html index f2f72762e9..47f3cba2c8 100644 --- a/blog/index.html +++ b/blog/index.html @@ -680,7 +680,7 @@ player state attributes. This change affects automations, scripts and scenes.Sensor: Neurio energy sensor now supported (@infamy) Binary Sensor: nx584 support added (@kk7ds) Improve and clarify CI testing (@sdague) - Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson) + Automation: State triggers and conditions now takes optional for config parameter to only trigger when a state hasn’t changed for a certain period of time (@pavoni, @stefan-jonasson) Sensor: Nest weather data added (@w1ll1am23) Device Tracker: Ubiquiti Unifi now supported (@kk7ds) Binary Sensor: MySensors now supported (@MartinHjelmare) diff --git a/blog/posts/2/index.html b/blog/posts/2/index.html index f59cc893b2..f09c9aa5d0 100644 --- a/blog/posts/2/index.html +++ b/blog/posts/2/index.html @@ -434,7 +434,7 @@ Example of the new views in the frontend. Learn mor Insteon hub support added (@FreekingDean) Statsd component added (@michaelkuty) Light: Rfxtrx platform now supports dimming (@turbokongen) - Time scheduling (including time automation) now works with intervals (ie. /5) (@kennedyshead) + Time scheduling (including time automation) now works with intervals (ie. /5) (@kennedyshead) Sensor: onewire support added (@deisi) Zigbee support added (@flyte) Device Tracker: OwnTracks can now track iBeacons (@pavoni) @@ -552,7 +552,7 @@ Example of the new views in the frontend. Learn mor Full refactor of RPi GPIO. Now includes binary sensor and switch (@sfam) Sensor: YR platform added (@danielhiversen) Device Tracker: Geofancy platform has been renamed to Locative (@philipbl) - Automation: Add sun condition (@philipbl) + Automation: Add sun condition (@philipbl) Switch: command_switch can now poll for state (@happyleavesaoc) Switch: wemo now uses subscription to states instead of polling (@pavoni) Telldus Live support added (@molobrakos) diff --git a/blog/posts/3/index.html b/blog/posts/3/index.html index bbf650a97c..17dc4705f8 100644 --- a/blog/posts/3/index.html +++ b/blog/posts/3/index.html @@ -635,7 +635,7 @@ Home Assistant will keep track of historical values and allow you to integrate i OwnTracks platform for the device tracker to get locations for devices - Brand new zone component to define zones to identify locations and trigger automation + Brand new zone component to define zones to identify locations and trigger automation A map in the UI to see all this (see it in action in the demo) diff --git a/blog/posts/4/index.html b/blog/posts/4/index.html index b081651473..40d380c1f5 100644 --- a/blog/posts/4/index.html +++ b/blog/posts/4/index.html @@ -516,7 +516,7 @@ Inspried by a @balloob. If you’re a developer, make sure you read up on the deprecation notices. @fabaff did another great round of documentating all the various components.](https://home-assistant.io/images/blog/2015-08-laundry-automation/moteino-and-sensors.jpg){kind=link}