mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-07-23 17:27:19 +00:00
Initial creating blueprint docs (#15816)
Co-authored-by: Philip Allgaier <philip.allgaier@bpcompass.com> Co-authored-by: Franck Nijhof <git@frenck.dev>
This commit is contained in:
parent
b6f43edbb3
commit
5b7b457a8e
22
source/_docs/blueprint.markdown
Normal file
22
source/_docs/blueprint.markdown
Normal file
@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Creating blueprints"
|
||||
description: "Documentation on how to get started creating blueprints."
|
||||
---
|
||||
|
||||
<div class='note'>
|
||||
|
||||
If you're looking on how to use blueprints, see the [automation documentation](/docs/automation/using_blueprints/).
|
||||
|
||||
</div>
|
||||
|
||||
An automation blueprint is an automation configuration with certain parts marked as configurable. This allows users to create multiple automations based on the same blueprint, with each having its own configuration.
|
||||
|
||||
Imagine a blueprint that controls a light based on motion, that allows you to configure the motion sensor to trigger on, and the light to control. It is now possible to create two automations that each have their own configuration for this blueprint and that act completely independent, yet are based on the same automation configuration.
|
||||
|
||||
<div class='note'>
|
||||
|
||||
This is an advanced feature and requires knowledge of writing [automations in YAML](/docs/automation/yaml/).
|
||||
|
||||
</div>
|
||||
|
||||
### [Tutorial: Create a blueprint »](/docs/blueprint/tutorial/)
|
83
source/_docs/blueprint/schema.markdown
Normal file
83
source/_docs/blueprint/schema.markdown
Normal file
@ -0,0 +1,83 @@
|
||||
---
|
||||
title: "Blueprint schema"
|
||||
description: "The schema for a valid blueprint."
|
||||
---
|
||||
|
||||
Schema of the blueprint metadata:
|
||||
|
||||
```ts
|
||||
interface BlueprintInput {
|
||||
name?: string;
|
||||
description?: string;
|
||||
selector?: Selector;
|
||||
default?: any;
|
||||
}
|
||||
|
||||
interface Blueprint {
|
||||
blueprint: {
|
||||
domain: string;
|
||||
name: string;
|
||||
input?: Record<string, BlueprintInput | null>;
|
||||
description?: string;
|
||||
source_url?: string;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The [built-in blueprints](https://github.com/home-assistant/core/tree/dev/homeassistant/components/automation/blueprints) are great examples.
|
||||
|
||||
Here is the built-in motion light blueprint:
|
||||
|
||||
```yaml
|
||||
blueprint:
|
||||
name: Motion-activated Light
|
||||
description: Turn on a light when motion is detected.
|
||||
domain: automation
|
||||
source_url: https://github.com/home-assistant/core/blob/dev/homeassistant/components/automation/blueprints/motion_light.yaml
|
||||
input:
|
||||
motion_entity:
|
||||
name: Motion Sensor
|
||||
selector:
|
||||
entity:
|
||||
domain: binary_sensor
|
||||
device_class: motion
|
||||
light_target:
|
||||
name: Light
|
||||
selector:
|
||||
target:
|
||||
entity:
|
||||
domain: light
|
||||
no_motion_wait:
|
||||
name: Wait time
|
||||
description: Time to leave the light on after last motion is detected.
|
||||
default: 120
|
||||
selector:
|
||||
number:
|
||||
min: 0
|
||||
max: 3600
|
||||
unit_of_measurement: seconds
|
||||
|
||||
# If motion is detected within the delay,
|
||||
# we restart the script.
|
||||
mode: restart
|
||||
max_exceeded: silent
|
||||
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: !input motion_entity
|
||||
from: "off"
|
||||
to: "on"
|
||||
|
||||
action:
|
||||
- service: light.turn_on
|
||||
target: !input light_target
|
||||
- wait_for_trigger:
|
||||
platform: state
|
||||
entity_id: !input motion_entity
|
||||
from: "on"
|
||||
to: "off"
|
||||
- delay: !input no_motion_wait
|
||||
- service: light.turn_off
|
||||
target: !input light_target
|
||||
|
||||
```
|
114
source/_docs/blueprint/selectors.markdown
Normal file
114
source/_docs/blueprint/selectors.markdown
Normal file
@ -0,0 +1,114 @@
|
||||
---
|
||||
title: "Selectors"
|
||||
description: "Documentation on available selectors."
|
||||
---
|
||||
|
||||
Selectors can be used to specify what values are accepted for an input.
|
||||
|
||||
## Entity Selector
|
||||
|
||||
Pick an entity. The chosen value will be an entity ID.
|
||||
|
||||
```yaml
|
||||
entity:
|
||||
# All fields are optional
|
||||
integration: zha
|
||||
domain: binary_sensor
|
||||
device_class: motion
|
||||
```
|
||||
|
||||
## Device Selector
|
||||
|
||||
Pick a device. The chosen value will be a device ID.
|
||||
|
||||
```yaml
|
||||
device:
|
||||
# All fields are optional
|
||||
integration: zha
|
||||
manufacturer: Philips
|
||||
model: Remote X1
|
||||
entity: <see entity selector>
|
||||
```
|
||||
|
||||
The `entity` option will limit devices that have an entity matching the entity selector.
|
||||
|
||||
|
||||
## Target Selector
|
||||
|
||||
Pick a target for service calls. Will be a dictionary containing optionally `entity_id`, `device_id` or `area_id` keys with the picked values.
|
||||
|
||||
Meant to be specified as the `target` property in a call service step in a script sequence.
|
||||
|
||||
```yaml
|
||||
target:
|
||||
# All fields are optional
|
||||
entity:
|
||||
integration: zha
|
||||
domain: binary_sensor
|
||||
device_class: motion
|
||||
|
||||
device:
|
||||
integration: zha
|
||||
manufacturer: Philips
|
||||
model: Remote X1
|
||||
```
|
||||
|
||||
## Number Selector
|
||||
|
||||
Pick a number.
|
||||
|
||||
```yaml
|
||||
number:
|
||||
# Required
|
||||
min: 0
|
||||
max: 100
|
||||
# Optional
|
||||
step: 5
|
||||
unit_of_measurement: seconds
|
||||
mode: slider # other valid value 'box'
|
||||
```
|
||||
|
||||
## Boolean Selector
|
||||
|
||||
Pick true or false.
|
||||
|
||||
```yaml
|
||||
boolean:
|
||||
```
|
||||
|
||||
## Time Selector
|
||||
|
||||
Pick a time.
|
||||
|
||||
```yaml
|
||||
time:
|
||||
```
|
||||
|
||||
## Action Selector
|
||||
|
||||
Enter a script action. Will be a list of action steps.
|
||||
|
||||
Meant to be specified as the `action` of an automation or any syntax that accepts actions, like `choose`.
|
||||
|
||||
```yaml
|
||||
action:
|
||||
```
|
||||
|
||||
|
||||
## Area Selector
|
||||
|
||||
Pick an area. The chosen value will be an area ID.
|
||||
|
||||
```yaml
|
||||
area:
|
||||
# All fields are optional
|
||||
entity:
|
||||
integration: zha
|
||||
domain: binary_sensor
|
||||
device_class: motion
|
||||
|
||||
device:
|
||||
integration: zha
|
||||
manufacturer: Philips
|
||||
model: Remote X1
|
||||
```
|
223
source/_docs/blueprint/tutorial.markdown
Normal file
223
source/_docs/blueprint/tutorial.markdown
Normal file
@ -0,0 +1,223 @@
|
||||
---
|
||||
title: "Blueprint tutorial"
|
||||
description: "Tutorial on creating a blueprint."
|
||||
---
|
||||
|
||||
In this tutorial, we're going to create a blueprint that controls a light based on a motion sensor. We will do this by taking an existing automation and converting it to a blueprint.
|
||||
|
||||
For this tutorial, we use a simple automation. The process for converting a complex automation is not any different.
|
||||
|
||||
## Our automation
|
||||
|
||||
To create a blueprint, we first need to have a working automation. The automation we're going to use in this tutorial, which controls a light based on a motion sensor, looks like this:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: binary_sensor.motion_kitchen
|
||||
|
||||
action:
|
||||
service: >
|
||||
{% if trigger.to_state.state == "on" %}
|
||||
light.turn_on
|
||||
{% else %}
|
||||
light.turn_off
|
||||
{% endif %}
|
||||
target:
|
||||
entity_id: light.kitchen
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
## Create the blueprint file
|
||||
|
||||
Automation blueprints are YAML files (with the `.yaml` extension) and live in the `<config>/blueprints/automation/` folder. You can create as many subdirectories in this folder as you want.
|
||||
|
||||
To get started with our blueprint, we're going to copy the above automation YAML and save it in that directory with the name `motion_light_tutorial.yaml`.
|
||||
|
||||
## Add basic blueprint metadata
|
||||
|
||||
Home Assistant needs to know about the blueprint. This is achieved by adding a `blueprint:` section. It should contain the `domain` of the integration it is for (`automation`) and `name`, the name of your blueprint. Optionally, you can also include a `description` for your blueprint.
|
||||
|
||||
Add this to the top of the file:
|
||||
|
||||
```yaml
|
||||
blueprint:
|
||||
name: Motion Light Tutorial
|
||||
description: Turn a light on based on detected motion
|
||||
domain: automation
|
||||
```
|
||||
|
||||
## Define the configurable parts as inputs
|
||||
|
||||
Now we have to decide what steps we want to make configurable. We want to make it as re-usable as possible, without losing its original intent of turning on a light-based on a motion sensor.
|
||||
|
||||
Configurable parts in blueprints are called inputs. To make the motion sensor entity configurable, we're replacing the entity ID with a custom YAML tag `!input`. This YAML tag has to be combined with the name of the input:
|
||||
|
||||
```yaml
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: !input motion_sensor
|
||||
```
|
||||
|
||||
For the light, we can offer some more flexibility. We want to allow the user to be able to define any device or area as the target. The `target` property in the service action can contain references to areas, devices and/or entities, so that's what we will use.
|
||||
|
||||
Inputs are not limited to strings. They can contain complex objects too. So in this case, we're going to mark the whole `target` as input:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
action:
|
||||
service: >
|
||||
{% if trigger.to_state.state == "on" %}
|
||||
light.turn_on
|
||||
{% else %}
|
||||
light.turn_off
|
||||
{% endif %}
|
||||
target: !input target_light
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
## Add the inputs to the metadata
|
||||
|
||||
All parts that are marked as inputs need to be added to the metadata. The minimum is that we add their names as used in the automation:
|
||||
|
||||
```yaml
|
||||
blueprint:
|
||||
name: Motion Light Tutorial
|
||||
description: Turn a light on based on detected motion
|
||||
domain: automation
|
||||
input:
|
||||
motion_sensor:
|
||||
target_light:
|
||||
```
|
||||
|
||||
## Use it via `configuration.yaml`
|
||||
|
||||
With the bare minimum metadata added, your blueprint is ready to use.
|
||||
|
||||
Open your `configuration.yaml` and add the following:
|
||||
|
||||
```yaml
|
||||
automation tutorial:
|
||||
use_blueprint:
|
||||
path: motion_light_tutorial.yaml
|
||||
input:
|
||||
motion_sensor: binary_sensor.kitchen
|
||||
target_light:
|
||||
entity_id: light.kitchen
|
||||
```
|
||||
|
||||
Reload automations and your new automation should popup. Because we configured the exact values as the original automation, they should work exactly the same.
|
||||
|
||||
## Adding user friendly names to the inputs
|
||||
|
||||
Blueprints are easier to use if it's easy to see what each field is used for. We can improve this experience by adding names and descriptions to our inputs:
|
||||
|
||||
```yaml
|
||||
blueprint:
|
||||
name: Motion Light Tutorial
|
||||
domain: automation
|
||||
input:
|
||||
motion_sensor:
|
||||
name: Motion Sensor
|
||||
description: This sensor will be synchronized with the light.
|
||||
target_light:
|
||||
name: Lights
|
||||
description: The lights to keep in sync.
|
||||
```
|
||||
|
||||
## Describing the inputs
|
||||
|
||||
Our blueprint doesn't currently describe what the inputs should contain. Without this information, Home Assistant will offer the user an empty text box.
|
||||
|
||||
To instead allow Home Assistant to offer more assistance, we will use [selectors](/docs/blueprint/selectors/). Selectors describe a type and can be used to help the user pick a matching value.
|
||||
|
||||
The selector for the motion sensor entity should describe that we want entities from the binary sensor domain that have the device class `motion`.
|
||||
|
||||
The selector for the target light should describe that we want to target light entities.
|
||||
|
||||
```yaml
|
||||
blueprint:
|
||||
name: Motion Light Tutorial
|
||||
domain: automation
|
||||
input:
|
||||
motion_sensor:
|
||||
name: Motion Sensor
|
||||
description: This sensor will be synchronized with the light.
|
||||
selector:
|
||||
entity:
|
||||
domain: binary_sensor
|
||||
device_class: motion
|
||||
target_light:
|
||||
name: Lights
|
||||
description: The lights to keep in sync.
|
||||
selector:
|
||||
target:
|
||||
entity:
|
||||
domain: light
|
||||
```
|
||||
|
||||
By limiting our blueprint to working with lights and motion sensors, we unlock a couple of benefits: the UI will be able to limit suggested values to lights and motion sensors instead of all devices. It will also allow the user to pick an area to control the lights in.
|
||||
|
||||
## The final blueprint
|
||||
|
||||
After we have added all the steps, our blueprint will look like this:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
blueprint:
|
||||
name: Motion Light Tutorial
|
||||
description: Turn a light on based on detected motion
|
||||
domain: automation
|
||||
input:
|
||||
motion_sensor:
|
||||
name: Motion Sensor
|
||||
description: This sensor will be synchronized with the light.
|
||||
selector:
|
||||
entity:
|
||||
domain: binary_sensor
|
||||
device_class: motion
|
||||
target_light:
|
||||
name: Lights
|
||||
description: The lights to keep in sync.
|
||||
selector:
|
||||
target:
|
||||
entity:
|
||||
domain: light
|
||||
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: !input motion_sensor
|
||||
|
||||
action:
|
||||
service: >
|
||||
{% if trigger.to_state.state == "on" %}
|
||||
light.turn_on
|
||||
{% else %}
|
||||
light.turn_off
|
||||
{% endif %}
|
||||
target: !input target_light
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
## Use it via the UI
|
||||
|
||||
To configure it via the UI, go to **Configuration** and then **Blueprints**. Find the "Motion Light Tutorial" blueprint and click on "Create Automation".
|
||||
|
||||
<div class='note'>
|
||||
Don't forget to reload automations after you make changes to your blueprint to have the UI and the automation integration pick up the latest blueprint changes.
|
||||
</div>
|
||||
|
||||

|
||||
|
||||
## Share the love
|
||||
|
||||
The final step is to share this blueprint with others. For this tutorial we're going to share it on GitHub Gists.
|
||||
|
||||
- Go to [GitHub Gists](https://gist.github.com/)
|
||||
- Gist description: blueprint tutorial
|
||||
- Filename including extension: `motion_light_tutorial.yaml`
|
||||
- Content is the content of the blueprint file.
|
||||
- Click the "Create Gist" button
|
||||
|
||||
You can now copy the URL of your new Gist and share it with other people. They can import it by going to **Configuration**, **Blueprints** and clicking on the blue "Import Blueprint" button.
|
@ -100,6 +100,14 @@
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<b>{% active_link /docs/blueprint/ Blueprints %}</b>
|
||||
<ul>
|
||||
<li>{% active_link /docs/blueprint/tutorial/ Tutorial %}</li>
|
||||
<li>{% active_link /docs/blueprint/schema/ Schema %}</li>
|
||||
<li>{% active_link /docs/blueprint/selectors/ Selectors %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<b>{% active_link /docs/frontend/ Frontend %}</b>
|
||||
<ul>
|
||||
|
BIN
source/images/blueprints/tutorial-ui.png
Normal file
BIN
source/images/blueprints/tutorial-ui.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 17 KiB |
Loading…
x
Reference in New Issue
Block a user