You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/_docs/scripts.markdown
+53-45Lines changed: 53 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,8 @@ script:
21
21
sequence:
22
22
# This is written using the Script Syntax
23
23
- service: light.turn_on
24
-
entity_id: light.ceiling
24
+
data:
25
+
entity_id: light.ceiling
25
26
- service: notify.notify
26
27
data:
27
28
message: 'Turned on the ceiling light!'
@@ -32,21 +33,21 @@ script:
32
33
The most important one is the action to call a service. This can be done in various ways. For all the different possibilities, have a look at the [service calls page].
33
34
34
35
```yaml
35
-
alias: Bedroom lights on
36
-
service: light.turn_on
37
-
data:
38
-
entity_id: group.bedroom
39
-
brightness: 100
36
+
- alias: Bedroom lights on
37
+
service: light.turn_on
38
+
data:
39
+
entity_id: group.bedroom
40
+
brightness: 100
40
41
```
41
42
42
43
### {% linkable_title Test a Condition %}
43
44
44
45
While executing a script you can add a condition to stop further execution. When a condition does not return `true`, the script will finish. There are many different conditions which are documented at the [conditions page].
45
46
46
47
```yaml
47
-
condition: state
48
-
entity_id: device_tracker.paulus
49
-
state: 'home'
48
+
- condition: state
49
+
entity_id: device_tracker.paulus
50
+
state: 'home'
50
51
```
51
52
52
53
### {% linkable_title Delay %}
@@ -55,46 +56,53 @@ Delays are useful for temporarily suspending your script and start it at a later
55
56
56
57
```yaml
57
58
# Waits 1 hour
58
-
delay: 01:00
59
+
- delay: '01:00'
59
60
```
60
61
61
62
```yaml
62
63
# Waits 1 minute, 30 seconds
63
-
delay: 00:01:30
64
+
- delay: '00:01:30'
64
65
```
65
66
66
67
```yaml
67
68
# Waits 1 minute
68
-
delay:
69
-
# supports milliseconds, seconds, minutes, hours, days
70
-
minutes: 1
69
+
- delay:
70
+
# supports milliseconds, seconds, minutes, hours, days
71
+
minutes: 1
71
72
```
72
73
74
+
{% raw %}
73
75
```yaml
74
76
# Waits however many minutes input_number.minute_delay is set to
75
77
# Valid formats include HH:MM and HH:MM:SS
76
-
delay: {% raw %}'00:{{ states.input_number.minute_delay.state | int }}:00'{% endraw %}
Wait until some things are complete. We support at the moment `wait_template` for waiting until a condition is `true`, see also on [Template-Trigger](/docs/automation/trigger/#template-trigger). It is possible to set a timeout after which the script will abort its execution if the condition is not satisfied. Timeout has the same syntax as `delay`.
81
85
86
+
{% raw %}
82
87
```yaml
83
88
# wait until media player have stop the playing
84
-
wait_template: {% raw %}"{{ states.media_player.floor.state == 'stop' }}"{% endraw %}
When using `wait_template` within an automation `trigger.entity_id` is supported for `state`, `numeric_state` and `template` triggers, see also [Available-Trigger-Data](/docs/automation/templating/#available-trigger-data).
This action allows you to fire an event. Events can be used for many things. It could trigger an automation or indicate to another component that something is happening. For instance, in the below example it is used to create an entry in the logbook.
118
126
119
127
```yaml
120
-
event: LOGBOOK_ENTRY
121
-
event_data:
122
-
name: Paulus
123
-
message: is waking up
124
-
entity_id: device_tracker.paulus
125
-
domain: light
128
+
- event: LOGBOOK_ENTRY
129
+
event_data:
130
+
name: Paulus
131
+
message: is waking up
132
+
entity_id: device_tracker.paulus
133
+
domain: light
126
134
```
127
135
128
136
You can also use event_data_template to fire an event with custom data. This could be used to pass data to another script awaiting
129
137
an event trigger.
130
138
131
139
{% raw %}
132
140
```yaml
133
-
event: MY_EVENT
134
-
event_data_template:
135
-
name: myEvent
136
-
customData: "{{ myCustomVariable }}"
141
+
- event: MY_EVENT
142
+
event_data_template:
143
+
name: myEvent
144
+
customData: "{{ myCustomVariable }}"
137
145
```
138
146
{% endraw %}
139
147
@@ -145,13 +153,13 @@ The following automation shows how to raise a custom event called `event_light_s
145
153
```yaml
146
154
- alias: Fire Event
147
155
trigger:
148
-
platform: state
149
-
entity_id: switch.kitchen
150
-
to: 'on'
156
+
- platform: state
157
+
entity_id: switch.kitchen
158
+
to: 'on'
151
159
action:
152
-
event: event_light_state_changed
153
-
event_data:
154
-
state: "on"
160
+
- event: event_light_state_changed
161
+
event_data:
162
+
state: 'on'
155
163
```
156
164
{% endraw %}
157
165
@@ -161,12 +169,12 @@ The following automation shows how to capture the custom event `event_light_stat
161
169
```yaml
162
170
- alias: Capture Event
163
171
trigger:
164
-
platform: event
165
-
event_type: event_light_state_changed
172
+
- platform: event
173
+
event_type: event_light_state_changed
166
174
action:
167
-
service: notify.notify
168
-
data_template:
169
-
message: "kitchen light is turned {{ trigger.event.data.state }}"
175
+
- service: notify.notify
176
+
data_template:
177
+
message: "kitchen light is turned {{ trigger.event.data.state }}"
0 commit comments