Merge Legacy template documentation into a single page. (#39596)

This commit is contained in:
Petro31 2025-06-18 02:15:16 -04:00 committed by GitHub
parent b95af197e5
commit 74d38cc274
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
9 changed files with 2506 additions and 2522 deletions

View File

@ -1,147 +0,0 @@
---
title: "Template Alarm control panel"
description: "Instructions on how to integrate template alarm control panels into Home Assistant."
ha_category:
- Alarm
- Helper
ha_release: 0.105
ha_iot_class: "Local Push"
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_config_flow: true
ha_platforms:
- alarm_control_panel
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The `template` {% term integration %} creates alarm control panels that combine integrations or adds preprocessing logic to actions.
There are several powerful ways to use this {% term integration %}, including grouping existing integrations into a simpler integrations, or adding logic that Home Assistant will execute when accessed.
For example, if you want to expose a true alarm panel to Google Home, Alexa, or HomeKit - but limit its ability to disarm when there's no one home, you can do that using a template.
Another use case could be grouping a series of sensors and services together to represent various "armed" and "disarmed" states and actions.
This can simplify the GUI and make it easier to write automations.
In optimistic mode, the alarm control panel will immediately change state after every command. Otherwise, the alarm control panel will wait for state confirmation from the template. Try to enable it, if experiencing incorrect operation.
{% include integrations/config_flow.md %}
## YAML Configuration
To enable a template alarm control panel in your installation, add the following to your {% term "`configuration.yaml`" %} file.
{% include integrations/restart_ha_after_config_inclusion.md %}
{% raw %}
```yaml
# Example configuration.yaml entry
alarm_control_panel:
- platform: template
panels:
safe_alarm_panel:
value_template: "{{ states('alarm_control_panel.real_alarm') }}"
arm_away:
action: alarm_control_panel.alarm_arm_away
target:
entity_id: alarm_control_panel.real_alarm
data:
code: !secret alarm_code
arm_home:
action: alarm_control_panel.alarm_arm_home
target:
entity_id: alarm_control_panel.real_alarm
data:
code: !secret alarm_code
disarm:
- condition: state
entity_id: device_tracker.paulus
state: "home"
- action: alarm_control_panel.alarm_disarm
target:
entity_id: alarm_control_panel.real_alarm
data:
code: !secret alarm_code
```
{% endraw %}
{% configuration %}
panels:
description: List of your panels.
required: true
type: map
keys:
alarm_control_panel_name:
description: The slug of the panel.
required: true
type: map
keys:
name:
description: Name to use in the frontend.
required: false
type: string
default: Template Alarm Control Panel
unique_id:
description: An ID that uniquely identifies this alarm control panel. Set this to a unique value to allow customization through the UI.
required: false
type: string
value_template:
description: "Defines a template to set the state of the alarm panel. Only the states `armed_away`, `armed_home`, `armed_night`, `armed_vacation`, `arming`, `disarmed`, `pending`, `triggered` and `unavailable` are used."
required: false
type: template
disarm:
description: Defines an action to run when the alarm is disarmed.
required: false
type: action
arm_away:
description: Defines an action to run when the alarm is armed to away mode.
required: false
type: action
arm_home:
description: Defines an action to run when the alarm is armed to home mode.
required: false
type: action
arm_night:
description: Defines an action to run when the alarm is armed to night mode.
required: false
type: action
arm_vacation:
description: Defines an action to run when the alarm is armed to vacation mode.
required: false
type: action
arm_custom_bypass:
description: Defines an action to run when the alarm is armed to custom bypass mode.
required: false
type: action
trigger:
description: Defines an action to run when the alarm is triggered.
required: false
type: action
code_arm_required:
description: If true, the code is required to arm the alarm.
required: false
type: boolean
default: true
code_format:
description: One of `number`, `text` or `no_code`. Format for the code used to arm/disarm the alarm.
required: false
type: string
default: number
{% endconfiguration %}
### Template and action variables
State-based template entities have the special template variable `this` available in their templates and actions. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an entity's state and attribute in templates and actions.
## Considerations
If you are using the state of an integration that takes extra time to load, the template alarm control panel may get an `unknown` state during startup. This results in error messages in your log file until that integration has completed loading. If you use `is_state()` function in your template, you can avoid this situation.
For example, you would replace {% raw %}`{{ states.switch.source.state == 'on' }}`{% endraw %} with this equivalent that returns `true`/`false` and never gives an unknown result: {% raw %}`{{ is_state('switch.source', 'on') }}`{% endraw %}

View File

@ -1,376 +0,0 @@
---
title: "Template cover"
description: "Instructions on how to integrate template covers into Home Assistant."
ha_category:
- Cover
- Helper
ha_release: 0.48
ha_iot_class: Local Push
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_platforms:
- cover
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The `template` platform can create covers that combine integrations and provides
the ability to run scripts or invoke actions for each of the open,
close, stop, position and tilt commands of a cover.
## Configuration
To enable Template Covers in your installation,
add the following to your {% term "`configuration.yaml`" %} file:
{% raw %}
```yaml
# Example configuration.yaml entry
cover:
- platform: template
covers:
garage_door:
device_class: garage
friendly_name: "Garage Door"
value_template: "{{ states('sensor.garage_door')|float > 0 }}"
open_cover:
action: script.open_garage_door
close_cover:
action: script.close_garage_door
stop_cover:
action: script.stop_garage_door
```
{% endraw %}
{% configuration %}
covers:
description: List of your covers.
required: true
type: map
keys:
friendly_name:
description: Name to use in the frontend.
required: false
type: string
unique_id:
description: An ID that uniquely identifies this cover. Set this to a unique value to allow customization through the UI.
required: false
type: string
value_template:
description: Defines a template to get the state of the cover. Valid output values from the template are `open`, `opening`, `closing` and `closed` which are directly mapped to the corresponding states. In addition, `true` is valid as a synonym to `open` and `false` as a synonym to `closed`. If [both a `value_template` and a `position_template`](#combining-value_template-and-position_template) are specified, only `opening` and `closing` are set from the `value_template`. If the template produces a `None` value the state will be set to `unknown`.
required: false
type: template
position_template:
description: Defines a template to get the position of the cover. Legal values are numbers between `0` (closed) and `100` (open). If the template produces a `None` value the current position will be set to `unknown`.
required: false
type: template
icon_template:
description: Defines a template to specify which icon to use.
required: false
type: template
entity_picture_template:
description: Defines a template for the entity picture of the cover.
required: false
type: template
availability_template:
description: Defines a template to get the `available` state of the entity. If the template either fails to render or returns `True`, `"1"`, `"true"`, `"yes"`, `"on"`, `"enable"`, or a non-zero number, the entity will be `available`. If the template returns any other value, the entity will be `unavailable`. If not configured, the entity will always be `available`. Note that the string comparison is not case sensitive; `"TrUe"` and `"yEs"` are allowed.
required: false
type: template
default: true
device_class:
description: Sets the [class of the device](/integrations/cover/), changing the device state and icon that is displayed on the frontend.
required: false
type: string
open_cover:
description: Defines an action to open the cover. If [`open_cover`](#open_cover) is specified, [`close_cover`](#close_cover) must also be specified. At least one of [`open_cover`](#open_cover) and [`set_cover_position`](#set_cover_position) must be specified.
required: inclusive
type: action
close_cover:
description: Defines an action to close the cover.
required: inclusive
type: action
stop_cover:
description: Defines an action to stop the cover.
required: false
type: action
set_cover_position:
description: Defines an action to set to a cover position (between `0` and `100`). The variable `position` will contain the entity's set position.
required: false
type: action
set_cover_tilt_position:
description: Defines an action to set the tilt of a cover (between `0` and `100`). The variable `tilt` will contain the entity's set tilt position.
required: false
type: action
optimistic:
description: Force cover position to use [optimistic mode](#optimistic-mode).
required: false
type: boolean
default: false
tilt_optimistic:
description: Force cover tilt position to use [optimistic mode](#optimistic-mode).
required: false
type: boolean
default: false
tilt_template:
description: Defines a template to get the tilt state of the cover. Legal values are numbers between `0` (closed) and `100` (open). If the template produces a `None` value the current tilt state will be set to `unknown`.
required: false
type: template
{% endconfiguration %}
### Template and action variables
State-based template entities have the special template variable `this` available in their templates and actions. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an entity's state and attribute in templates and actions.
## Considerations
If you are using the state of a platform that takes extra time to load, the
Template Cover may get an `unknown` state during startup. This results in error
messages in your log file until that platform has completed loading.
If you use `is_state()` function in your template, you can avoid this situation.
For example, you would replace
{% raw %}`{{ states.cover.source.state == 'open' }}`{% endraw %}
with this equivalent that returns `true`/`false` and never gives an unknown
result:
{% raw %}`{{ is_state('cover.source', 'open') }}`{% endraw %}
## Optimistic mode
In optimistic mode, the cover position state is maintained internally. This mode
is automatically enabled if neither [`value_template`](#value_template) or
[`position_template`](#position_template) are specified. Note that this is
unlikely to be very reliable without some feedback mechanism, since there is
otherwise no way to know if the cover is moving properly. The cover can be
forced into optimistic mode by using the [`optimistic`](#optimistic) attribute.
There is an equivalent mode for `tilt_position` that is enabled when
[`tilt_template`](#tilt_template) is not specified or when the
[`tilt_optimistic`](#tilt_optimistic) attribute is used.
## Combining `value_template` and `position_template`
If both a [`value_template`](#value_template) and a [`position_template`](#position_template) are specified only `opening` and `closing` states are set directly from the `value_template`, the `open` and `closed` states will instead be derived from the cover position.
| value_template output | result |
| --------------------- | ------------------------------------ |
| open | state defined by `position_template` |
| closed | state defined by `position_template` |
| true | state defined by `position_template` |
| false | state defined by `position_template` |
| opening | state set to `opening` |
| closing | state set to `closing` |
| <any other output> | No change of state or position |
## Examples
In this section you will find some real-life examples of how to use this cover.
### Garage door
This example converts a garage door with a controllable switch and position
sensor into a cover. The condition check is optional, but suggested if you
use the same switch to open and close the garage.
{% raw %}
```yaml
cover:
- platform: template
covers:
garage_door:
device_class: garage
friendly_name: "Garage Door"
position_template: "{{ states('sensor.garage_door') }}"
open_cover:
- condition: state
entity_id: sensor.garage_door
state: "off"
- action: switch.turn_on
target:
entity_id: switch.garage_door
close_cover:
- condition: state
entity_id: sensor.garage_door
state: "on"
- action: switch.turn_off
target:
entity_id: switch.garage_door
stop_cover:
action: switch.turn_on
target:
entity_id: switch.garage_door
icon_template: >-
{% if states('sensor.garage_door')|float > 0 %}
mdi:garage-open
{% else %}
mdi:garage
{% endif %}
```
{% endraw %}
### Multiple covers
This example allows you to control two or more covers at once.
{% raw %}
```yaml
homeassistant:
customize:
cover_group:
assumed_state: true
cover:
- platform: template
covers:
cover_group:
friendly_name: "Cover Group"
open_cover:
action: script.cover_group
data:
modus: "open"
close_cover:
action: script.cover_group
data:
modus: "close"
stop_cover:
action: script.cover_group
data:
modus: "stop"
set_cover_position:
action: script.cover_group_position
data:
position: "{{position}}"
set_cover_tilt_position:
action: script.cover_group_tilt_position
data:
tilt: "{{tilt}}"
value_template: "{{is_state('sensor.cover_group', 'open')}}"
icon_template: >-
{% if is_state('sensor.cover_group', 'open') %}
mdi:window-open
{% else %}
mdi:window-closed
{% endif %}
sensor:
- platform: template
sensors:
cover_group:
value_template: >-
{% if is_state('cover.bedroom', 'open') %}
open
{% elif is_state('cover.livingroom', 'open') %}
open
{% else %}
closed
{% endif %}
script:
cover_group:
sequence:
- action: "cover.{{modus}}_cover"
target:
entity_id:
- cover.bedroom
- cover.livingroom
cover_group_position:
sequence:
- action: cover.set_cover_position
target:
entity_id:
- cover.bedroom
- cover.livingroom
data:
position: "{{position}}"
automation:
- alias: "Close covers at night"
triggers:
- trigger: sun
event: sunset
offset: "+00:30:00"
actions:
- action: cover.set_cover_position
target:
entity_id: cover.cover_group
data:
position: 25
```
{% endraw %}
### Change the icon
This example shows how to change the icon based on the cover state.
{% raw %}
```yaml
cover:
- platform: template
covers:
cover_group:
friendly_name: "Cover Group"
open_cover:
action: script.cover_group
data:
modus: "open"
close_cover:
action: script.cover_group
data:
modus: "close"
stop_cover:
action: script.cover_group
data:
modus: "stop"
value_template: "{{is_state('sensor.cover_group', 'open')}}"
icon_template: >-
{% if is_state('sensor.cover_group', 'open') %}
mdi:window-open
{% else %}
mdi:window-closed
{% endif %}
```
{% endraw %}
### Change the entity picture
This example shows how to change the entity picture based on the cover state.
{% raw %}
```yaml
cover:
- platform: template
covers:
cover_group:
friendly_name: "Cover Group"
open_cover:
action: script.cover_group
data:
modus: "open"
close_cover:
action: script.cover_group
data:
modus: "close"
stop_cover:
action: script.cover_group
data:
modus: "stop"
value_template: "{{is_state('sensor.cover_group', 'open')}}"
entity_picture_template: >-
{% if is_state('sensor.cover_group', 'open') %}
/local/cover-open.png
{% else %}
/local/cover-closed.png
{% endif %}
```
{% endraw %}

View File

@ -1,266 +0,0 @@
---
title: "Template fan"
description: "Instructions how to setup the template fans within Home Assistant."
ha_category:
- Fan
- Helper
ha_release: 0.69
ha_iot_class: Local Push
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_platforms:
- fan
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The **Template** {% term integration %} creates fans that combine integrations and provides the
ability to run scripts or invoke actions for each of the `turn_on`, `turn_off`, `set_percentage`,
`set_preset_mode`, `set_oscillating`, and `set_direction` commands of a fan.
## Configuration
To enable template fans in your installation, add the following to your
{% term "`configuration.yaml`" %} file:
{% raw %}
```yaml
# Example configuration.yaml entry
fan:
- platform: template
fans:
bedroom_fan:
friendly_name: "Bedroom fan"
value_template: "{{ states('input_boolean.state') }}"
percentage_template: "{{ states('input_number.percentage') }}"
preset_mode_template: "{{ states('input_select.preset_mode') }}"
oscillating_template: "{{ states('input_select.osc') }}"
direction_template: "{{ states('input_select.direction') }}"
turn_on:
action: script.fan_on
turn_off:
action: script.fan_off
set_percentage:
action: script.fans_set_speed
data:
percentage: "{{ percentage }}"
set_preset_mode:
action: script.fans_set_preset_mode
data:
preset_mode: "{{ preset_mode }}"
set_oscillating:
action: script.fan_oscillating
data:
oscillating: "{{ oscillating }}"
set_direction:
action: script.fan_direction
data:
direction: "{{ direction }}"
speed_count: 6
preset_modes:
- 'auto'
- 'smart'
- 'whoosh'
```
{% endraw %}
{% configuration %}
fans:
description: List of your fans.
required: true
type: map
keys:
friendly_name:
description: Name to use in the frontend.
required: false
type: string
unique_id:
description: An ID that uniquely identifies this fan. Set this to a unique value to allow customization through the UI.
required: false
type: string
value_template:
description: "Defines a template to get the state of the fan. Valid values: `on`, `off`"
required: true
type: template
percentage_template:
description: Defines a template to get the speed percentage of the fan.
required: false
type: template
preset_mode_template:
description: Defines a template to get the preset mode of the fan.
required: false
type: template
oscillating_template:
description: "Defines a template to get the osc state of the fan. Valid values: `true`, `false`"
required: false
type: template
direction_template:
description: "Defines a template to get the direction of the fan. Valid values: `forward`, `reverse`"
required: false
type: template
availability_template:
description: Defines a template to get the `available` state of the entity. If the template either fails to render or returns `True`, `"1"`, `"true"`, `"yes"`, `"on"`, `"enable"`, or a non-zero number, the entity will be `available`. If the template returns any other value, the entity will be `unavailable`. If not configured, the entity will always be `available`. Note that the string comparison not case sensitive; `"TrUe"` and `"yEs"` are allowed.
required: false
type: template
default: true
turn_on:
description: Defines an action to run when the fan is turned on.
required: true
type: action
turn_off:
description: Defines an action to run when the fan is turned off.
required: true
type: action
set_percentage:
description: Defines an action to run when the fan is given a speed percentage command.
required: false
type: action
set_preset_mode:
description: Defines an action to run when the fan is given a preset command.
required: false
type: action
set_oscillating:
description: Defines an action to run when the fan is given an osc state command.
required: false
type: action
set_direction:
description: Defines an action to run when the fan is given a direction command.
required: false
type: action
preset_modes:
description: List of preset modes the fan is capable of. This is an arbitrary list of strings and must not contain any speeds.
required: false
type: [string, list]
default: []
speed_count:
description: The number of speeds the fan supports. Used to calculate the percentage step for the `fan.increase_speed` and `fan.decrease_speed` actions.
required: false
type: integer
default: 100
{% endconfiguration %}
### Template and action variables
State-based template entities have the special template variable `this` available in their templates and actions. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an entity's state and attribute in templates and actions.
## Converting from speeds to percentage
When converting a fan with 3 speeds from the old fan entity model, the following percentages can be used:
0 - `off`
33 - `low`
66 - `medium`
100 - `high`
## Examples
### Helper fan
This example uses an input_boolean and an input_number to mimic a fan, and
the example shows multiple actions for `set_percentage`.
{% raw %}
```yaml
fan:
- platform: template
fans:
helper_fan:
friendly_name: "Helper Fan"
value_template: "{{ states('input_boolean.state') }}"
turn_on:
- action: input_boolean.turn_on
target:
entity_id: input_boolean.state
turn_off:
- action: input_boolean.turn_off
target:
entity_id: input_boolean.state
percentage_template: >
{{ states('input_number.percentage') if is_state('input_boolean.state', 'on') else 0 }}
speed_count: 6
set_percentage:
- action: input_boolean.turn_{{ 'on' if percentage > 0 else 'off' }}
target:
entity_id: input_boolean.state
- action: input_number.set_value
target:
entity_id: input_number.percentage
data:
value: "{{ percentage }}"
```
{% endraw %}
### Preset modes fan
This example uses an existing fan with only a percentage. It extends the
percentage value into useable preset modes without a helper entity.
{% raw %}
```yaml
fan:
- platform: template
fans:
preset_mode_fan:
friendly_name: "Preset Mode Fan Example"
value_template: "{{ states('fan.percentage_fan') }}"
turn_on:
- action: fan.turn_on
target:
entity_id: fan.percentage_fan
turn_off:
- action: fan.turn_off
target:
entity_id: fan.percentage_fan
percentage_template: >
{{ state_attr('fan.percentage_fan', 'percentage') }}
speed_count: 3
set_percentage:
- action: fan.set_percentage
target:
entity_id: fan.percentage_fan
data:
percentage: "{{ percentage }}"
preset_modes:
- "off"
- "low"
- "medium"
- "high"
preset_mode_template: >
{% if is_state('fan.percentage_fan', 'on') %}
{% if state_attr('fan.percentage_fan', 'percentage') == 100 %}
high
{% elif state_attr('fan.percentage_fan', 'percentage') == 66 %}
medium
{% else %}
low
{% endif %}
{% else %}
off
{% endif %}
set_preset_mode:
- action: fan.set_percentage
target:
entity_id: fan.percentage_fan
data:
percentage: >-
{% if preset_mode == 'high' %}
100
{% elif preset_mode == 'medium' %}
66
{% elif preset_mode == 'low' %}
33
{% else %}
0
{% endif %}
```
{% endraw %}

View File

@ -1,430 +0,0 @@
---
title: "Template Light"
description: "Instructions on how to integrate Template Lights into Home Assistant."
ha_category:
- Light
- Helper
ha_release: 0.46
ha_iot_class: Local Push
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_platforms:
- light
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The `template` platform creates lights that combine integrations and provides the
ability to run scripts or invoke actions for each of the on, off, and
brightness commands of a light.
To enable Template Lights in your installation, add the following to your
{% term "`configuration.yaml`" %} file:
{% raw %}
```yaml
# Example configuration.yaml entry
light:
- platform: template
lights:
theater_lights:
friendly_name: "Theater Lights"
level_template: "{{ state_attr('sensor.theater_brightness', 'lux')|int }}"
value_template: "{{ state_attr('sensor.theater_brightness', 'lux')|int > 0 }}"
temperature_template: "{{states('input_number.temperature_input') | int}}"
hs_template: "({{states('input_number.h_input') | int}}, {{states('input_number.s_input') | int}})"
effect_list_template: "{{ state_attr('light.led_strip', 'effect_list') }}"
turn_on:
action: script.theater_lights_on
turn_off:
action: script.theater_lights_off
set_level:
action: script.theater_lights_level
data:
brightness: "{{ brightness }}"
set_temperature:
action: input_number.set_value
data:
value: "{{ color_temp }}"
entity_id: input_number.temperature_input
set_hs:
- action: input_number.set_value
data:
value: "{{ h }}"
entity_id: input_number.h_input
- action: input_number.set_value
data:
value: "{{ s }}"
entity_id: input_number.s_input
- action: light.turn_on
data:
entity_id:
- light.led_strip
transition: "{{ transition | float }}"
hs_color:
- "{{ hs[0] }}"
- "{{ hs[1] }}"
set_effect:
- action: light.turn_on
data:
entity_id:
- light.led_strip
effect: "{{ effect }}"
supports_transition_template: "{{ true }}"
```
{% endraw %}
{% configuration %}
lights:
description: List of your lights.
required: true
type: map
keys:
friendly_name:
description: Name to use in the frontend.
required: false
type: string
unique_id:
description: An ID that uniquely identifies this light. Set this to a unique value to allow customization through the UI.
required: false
type: string
value_template:
description: Defines a template to get the state of the light.
required: false
type: template
default: optimistic
level_template:
description: Defines a template to get the brightness of the light.
required: false
type: template
default: optimistic
temperature_template:
description: Defines a template to get the color temperature of the light.
required: false
type: template
default: optimistic
hs_template:
description: Defines a template to get the HS color of the light. Must render a tuple (hue, saturation).
required: false
type: template
default: optimistic
rgb_template:
description: Defines a template to get the RGB color of the light. Must render a tuple or a list (red, green, blue).
required: false
type: template
default: optimistic
rgbw_template:
description: Defines a template to get the RGBW color of the light. Must render a tuple or a list (red, green, blue, white).
required: false
type: template
default: optimistic
rgbww_template:
description: Defines a template to get the RGBWW color of the light. Must render a tuple or a list (red, green, blue, cold white, warm white).
required: false
type: template
default: optimistic
supports_transition_template:
description: Defines a template to get if light supports transition. Should return boolean value (True/False). If this value is `True` transition parameter in a turn on or turn off call will be passed as a named parameter `transition` to either of the scripts.
required: false
type: template
default: false
effect_list_template:
description: Defines a template to get the list of supported effects. Must render a list
required: inclusive
type: template
default: optimistic
effect_template:
description: Defines a template to get the effect of the light.
required: inclusive
type: template
default: optimistic
min_mireds_template:
description: Defines a template to get the min mireds value of the light.
required: false
type: template
default: optimistic
max_mireds_template:
description: Defines a template to get the max mireds value of the light.
required: false
type: template
default: optimistic
icon_template:
description: Defines a template for an icon or picture, e.g., showing a different icon for different states.
required: false
type: template
availability_template:
description: Defines a template to get the `available` state of the entity. If the template either fails to render or returns `True`, `"1"`, `"true"`, `"yes"`, `"on"`, `"enable"`, or a non-zero number, the entity will be `available`. If the template returns any other value, the entity will be `unavailable`. If not configured, the entity will always be `available`. Note that the string comparison not case sensitive; `"TrUe"` and `"yEs"` are allowed.
required: false
type: template
default: true
turn_on:
description: Defines an action to run when the light is turned on. May receive variables `brightness` and/or `transition`.
required: true
type: action
turn_off:
description: Defines an action to run when the light is turned off. May receive variable `transition`.
required: true
type: action
set_level:
description: Defines an action to run when the light is given a brightness command. The script will only be called if the `turn_on` call only has brightness, and optionally transition. Receives variables `brightness` and optionally `transition`.
required: false
type: action
set_temperature:
description: Defines an action to run when the light is given a color temperature command. Receives variable `color_temp`. May also receive variables `brightness` and/or `transition`.
required: false
type: action
set_hs:
description: "Defines an action to run when the light is given a hs color command. Available variables: `hs` as a tuple, `h` and `s`"
required: false
type: action
set_rgb:
description: "Defines an action to run when the light is given an RGB color command. Available variables: `rgb` as a tuple, `r`, `g` and `b`."
required: false
type: action
set_rgbw:
description: "Defines an action to run when the light is given an RGBW color command. Available variables: `rgbw` as a tuple, `rgb` as a tuple, `r`, `g`, `b` and `w`."
required: false
type: action
set_rgbww:
description: "Defines an action to run when the light is given an RGBWW color command. Available variables: `rgbww` as a tuple, `rgb` as a tuple, `r`, `g`, `b`, `cw` and `ww`."
required: false
type: action
set_effect:
description: Defines an action to run when the light is given an effect command. Receives variable `effect`. May also receive variables `brightness` and/or `transition`.
required: inclusive
type: action
{% endconfiguration %}
### Template and action variables
State-based template entities have the special template variable `this` available in their templates and actions. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an entity's state and attribute in templates and actions.
## Considerations
If you are using the state of a platform that takes extra time to load, the
Template Light may get an `unknown` state during startup. This results
in error messages in your log file until that platform has completed loading.
If you use `is_state()` function in your template, you can avoid this situation.
For example, you would replace
{% raw %}`{{ states.switch.source.state == 'on' }}`{% endraw %}
with this equivalent that returns `true`/`false` and never gives an unknown
result:
{% raw %}`{{ is_state('switch.source', 'on') }}`{% endraw %}
Transition doesn't have its own script, it will instead be passed as a named parameter `transition` to the `turn_on`, `turn_off`, `brightness`, `color_temp`, `effect`, `hs_color`, `rgb_color`, `rgbw_color` or `rgbww_color` scripts.
Brightness will be passed as a named parameter `brightness` to either of `turn_on`, `color_temp`, `effect`, `hs_color`, `rgb_color`, `rgbw_color` or `rgbww_color` scripts if the corresponding parameter is also in the call. In this case, the brightness script (`set_level`) will not be called.
If only brightness is passed to `light.turn_on` action, then `set_level` script is called.
## Examples
In this section you will find some real-life examples of how to use this light.
### Theater Volume Control
This example shows a light that is actually a home theater's volume. This
integration gives you the flexibility to provide whatever you'd like to send as
the payload to the consumer including any scale conversions you may need to
make; the [media player integration](/integrations/media_player/) needs a floating
point percentage value from `0.0` to `1.0`.
{% raw %}
```yaml
light:
- platform: template
lights:
theater_volume:
friendly_name: "Receiver Volume"
value_template: >-
{% if is_state('media_player.receiver', 'on') %}
{% if state_attr('media_player.receiver', 'is_volume_muted') %}
off
{% else %}
on
{% endif %}
{% else %}
off
{% endif %}
turn_on:
action: media_player.volume_mute
target:
entity_id: media_player.receiver
data:
is_volume_muted: false
turn_off:
action: media_player.volume_mute
target:
entity_id: media_player.receiver
data:
is_volume_muted: true
set_level:
action: media_player.volume_set
target:
entity_id: media_player.receiver
data:
volume_level: "{{ (brightness / 255 * 100)|int / 100 }}"
level_template: >-
{% if is_state('media_player.receiver', 'on') %}
{{ (state_attr('media_player.receiver', 'volume_level')|float * 255)|int }}
{% else %}
0
{% endif %}
```
{% endraw %}
### Change The Icon
This example shows how to change the icon based on the light state.
{% raw %}
```yaml
light:
- platform: template
lights:
theater_volume:
friendly_name: "Receiver Volume"
value_template: >-
{% if is_state('media_player.receiver', 'on') %}
{% if state_attr('media_player.receiver', 'is_volume_muted') %}
off
{% else %}
on
{% endif %}
{% else %}
off
{% endif %}
icon_template: >-
{% if is_state('media_player.receiver', 'on') %}
{% if state_attr('media_player.receiver', 'is_volume_muted') %}
mdi:lightbulb-off
{% else %}
mdi:lightbulb-on
{% endif %}
{% else %}
mdi:lightbulb-off
{% endif %}
turn_on:
action: media_player.volume_mute
target:
entity_id: media_player.receiver
data:
is_volume_muted: false
turn_off:
action: media_player.volume_mute
target:
entity_id: media_player.receiver
data:
is_volume_muted: true
```
{% endraw %}
### Change The Entity Picture
This example shows how to change the entity picture based on the light state.
{% raw %}
```yaml
light:
- platform: template
lights:
theater_volume:
friendly_name: "Receiver Volume"
value_template: >-
{% if is_state('media_player.receiver', 'on') %}
{% if state_attr('media_player.receiver', 'is_volume_muted') %}
off
{% else %}
on
{% endif %}
{% else %}
off
{% endif %}
icon_template: >-
{% if is_state('media_player.receiver', 'on') %}
{% if state_attr('media_player.receiver', 'is_volume_muted') %}
/local/lightbulb-off.png
{% else %}
/local/lightbulb-on.png
{% endif %}
{% else %}
/local/lightbulb-off.png
{% endif %}
turn_on:
action: media_player.volume_mute
target:
entity_id: media_player.receiver
data:
is_volume_muted: false
turn_off:
action: media_player.volume_mute
target:
entity_id: media_player.receiver
data:
is_volume_muted: true
```
{% endraw %}
### Make a global light entity for a multi-segment WLED light
This example shows how to group together 2 RGBW segments from the same WLED controller into a single usable light
{% raw %}
```yaml
light:
- platform: template
lights:
wled_global:
unique_id: 28208f257b54c44e50deb2d618d44710
friendly_name: "Multi-segment Wled control"
value_template: "{{ states('light.wled_master') }}"
level_template: "{{ state_attr('light.wled_master', 'brightness')|d(0,true)|int }}"
rgbw_template: (
{{ (state_attr('light.wled_segment_0', 'rgbw_color')[0]|d(0) + state_attr('light.wled_segment_1', 'rgbw_color')[0]|d(0))/2 }},
{{ (state_attr('light.wled_segment_0', 'rgbw_color')[1]|d(0) + state_attr('light.wled_segment_1', 'rgbw_color')[1]|d(0))/2 }},
{{ (state_attr('light.wled_segment_0', 'rgbw_color')[2]|d(0) + state_attr('light.wled_segment_1', 'rgbw_color')[2]|d(0))/2 }},
{{ (state_attr('light.wled_segment_0', 'rgbw_color')[3]|d(0) + state_attr('light.wled_segment_1', 'rgbw_color')[3]|d(0))/2 }}
)
effect_list_template: "{{ state_attr('light.wled_segment_0', 'effect_list') }}"
effect_template: "{{ state_attr('light.wled_segment_0', 'effect') if state_attr('light.wled_segment_0', 'effect') == state_attr('light.wled_segment_1', 'effect') else none }}"
availability_template: "{{ not is_state('light.wled_master', 'unknown') }}"
turn_on:
action: light.turn_on
entity_id: light.wled_segment_0, light.wled_segment_1, light.wled_master
turn_off:
action: light.turn_off
entity_id: light.wled_master
set_level:
action: light.turn_on
entity_id: light.wled_master
data:
brightness: "{{ brightness }}"
set_rgbw:
action: light.turn_on
entity_id: light.wled_segment_0, light.wled_segment_1
data:
rgbw_color:
- "{{ r }}"
- "{{ g }}"
- "{{ b }}"
- "{{ w }}"
effect: "Solid"
set_effect:
action: light.turn_on
entity_id: light.wled_segment_0, light.wled_segment_1
data:
effect: "{{ effect }}"
```
{% endraw %}

View File

@ -1,213 +0,0 @@
---
title: "Template Lock"
description: "Instructions on how to integrate Template Locks into Home Assistant."
ha_category:
- Lock
- Helper
ha_release: 0.81
ha_iot_class: Local Push
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_platforms:
- lock
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The `template` platform creates locks that combines components.
For example, if you have a garage door with a toggle switch that operates the motor and a sensor that allows you know whether the door is open or closed, you can combine these into a lock that knows whether the garage door is open or closed.
This can simplify the GUI and make it easier to write automations.
In optimistic mode, the lock will immediately change state after every command. Otherwise, the lock will wait for state confirmation from the template. Try to enable it, if experiencing incorrect lock operation.
## Configuration
To enable Template Locks in your installation, add the following to your {% term "`configuration.yaml`" %} file:
{% raw %}
```yaml
# Example configuration.yaml entry
lock:
- platform: template
name: Garage door
value_template: "{{ is_state('sensor.door', 'on') }}"
lock:
action: switch.turn_on
target:
entity_id: switch.door
unlock:
action: switch.turn_off
target:
entity_id: switch.door
```
{% endraw %}
{% configuration %}
name:
description: Name to use in the frontend.
required: false
type: string
default: Template Lock
unique_id:
description: An ID that uniquely identifies this lock. Set this to a unique value to allow customization through the UI.
required: false
type: string
value_template:
description: Defines a template to set the state of the lock.
required: true
type: template
availability_template:
description: Defines a template to get the `available` state of the entity. If the template either fails to render or returns `True`, `"1"`, `"true"`, `"yes"`, `"on"`, `"enable"`, or a non-zero number, the entity will be `available`. If the template returns any other value, the entity will be `unavailable`. If not configured, the entity will always be `available`. Note that the string comparison not case sensitive; `"TrUe"` and `"yEs"` are allowed.
required: false
type: template
default: true
code_format_template:
description: Defines a template to get the `code_format` attribute of the entity. This template must evaluate to a valid [Python regular expression](https://docs.python.org/3/library/re.html#regular-expression-syntax) or `None`. If it evaluates to a not-`None` value, the user is prompted to enter a code when interacting with the lock. The code will be matched against the regular expression, and only if it matches, the lock/unlock actions will be executed. The actual _validity_ of the entered code must be verified within these actions. If there's a syntax error in the template, the entity will be unavailable. If the template fails to render for other reasons or if the regular expression is invalid, no code will be accepted and the lock/unlock actions will never be invoked.
required: false
type: template
default: None
lock:
description: Defines an action to run when the lock is locked.
required: true
type: action
unlock:
description: Defines an action to run when the lock is unlocked.
required: true
type: action
open:
description: Defines an action to run when the lock is opened.
required: false
type: action
optimistic:
description: Flag that defines if lock works in optimistic mode.
required: false
type: boolean
default: false
{% endconfiguration %}
### Template and action variables
State-based template entities have the special template variable `this` available in their templates and actions. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an entity's state and attribute in templates and actions.
## Considerations
If you are using the state of a platform that takes extra time to load, the Template Lock may get an `unknown` state during startup. This results in error messages in your log file until that platform has completed loading. If you use `is_state()` function in your template, you can avoid this situation. For example, you would replace {% raw %}`{{ state('switch.source') == 'on') }}`{% endraw %} with this equivalent that returns `true`/`false` and never gives an unknown result: {% raw %}`{{ is_state('switch.source', 'on') }}`{% endraw %}
## Examples
In this section, you find some real-life examples of how to use this lock.
### Lock from Switch
This example shows a lock that copies data from a switch.
{% raw %}
```yaml
lock:
- platform: template
name: Garage Door
value_template: "{{ is_state('switch.source', 'on') }}"
lock:
action: switch.turn_on
target:
entity_id: switch.source
unlock:
action: switch.turn_off
target:
entity_id: switch.source
```
{% endraw %}
### Optimistic mode
This example shows a lock in optimistic mode. This lock will immediately change state after command and will not wait for state update from the sensor.
{% raw %}
```yaml
lock:
- platform: template
name: Garage Door
value_template: "{{ is_state('sensor.skylight.state', 'on') }}"
optimistic: true
lock:
action: switch.turn_on
target:
entity_id: switch.source
unlock:
action: switch.turn_off
target:
entity_id: switch.source
```
{% endraw %}
### Sensor and Two Switches
This example shows a lock that takes its state from a sensor, and uses two momentary switches to control a device.
{% raw %}
```yaml
lock:
- platform: template
name: Garage Door
value_template: "{{ is_state('sensor.skylight.state', 'on') }}"
lock:
action: switch.turn_on
target:
entity_id: switch.skylight_open
unlock:
action: switch.turn_on
target:
entity_id: switch.skylight_close
```
{% endraw %}
### Lock from switch with dynamic code
This example shows a lock that copies data from a switch. It needs a PIN code defined as a [secret](/docs/configuration/secrets) to unlock and no code to lock. Note that the actual validity check of the code is part of the `unlock` action and should always happen there or in scripts called from these actions. In this way, you can not only perform code checks against static values, but also dynamic ones (for instance, TOTPs).
{% raw %}
```yaml
lock:
- platform: template
name: Garage Door
value_template: "{{ is_state('switch.source', 'on') }}"
code_format_template: "{{ '\\d{4}' if is_state('switch.source', 'on') else None }}"
lock:
- action: switch.turn_on
target:
entity_id: switch.source
unlock:
- variables:
pin: !secret garage_door_pin
- condition: "{{ code == pin }}"
- action: switch.turn_off
target:
entity_id: switch.source
```
{% endraw %}
In `secrets.yaml`:
{% raw %}
```yaml
garage_door_pin: "1234"
```
{% endraw %}

View File

@ -1,285 +0,0 @@
---
title: "Template Switch"
description: "Instructions on how to integrate Template Switches into Home Assistant."
ha_category:
- Switch
- Helper
ha_release: 0.13
ha_iot_class: Local Push
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_config_flow: true
ha_platforms:
- switch
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The `template` platform creates switches that combines components.
For example, if you have a garage door with a toggle switch that operates the motor and a sensor that allows you know whether the door is open or closed, you can combine these into a switch that knows whether the garage door is open or closed.
This can simplify the GUI and make it easier to write automations.
{% include integrations/config_flow.md %}
{% important %}
To be able to add **{% my helpers title="Helpers" %}** via the user interface, you should have `default_config:` in your {% term "`configuration.yaml`" %}. It should already be there by default unless you removed it.
{% endimportant %}
{% note %}
Configuration using our user interface provides a more limited subset of options, making this integration more accessible while covering most use cases.
If you need more specific features for your use case, the manual [YAML-configuration section](#yaml-configuration) of this integration might provide them.
{% endnote %}
## YAML Configuration
To enable Template Switches in your installation, add the following to your {% term "`configuration.yaml`" %} file:
{% raw %}
```yaml
# Example configuration.yaml entry
switch:
- platform: template
switches:
skylight:
value_template: "{{ is_state('sensor.skylight', 'on') }}"
turn_on:
action: switch.turn_on
target:
entity_id: switch.skylight_open
turn_off:
action: switch.turn_off
target:
entity_id: switch.skylight_close
```
{% endraw %}
{% configuration %}
switches:
description: List of your switches.
required: true
type: map
keys:
friendly_name:
description: Name to use in the frontend.
required: false
type: string
unique_id:
description: An ID that uniquely identifies this switch. Set this to a unique value to allow customization through the UI.
required: false
type: string
value_template:
description: Defines a template to set the state of the switch. If not defined, the switch will optimistically assume all commands are successful.
required: false
type: template
default: optimistic
availability_template:
description: Defines a template to get the `available` state of the entity. If the template either fails to render or returns `True`, `"1"`, `"true"`, `"yes"`, `"on"`, `"enable"`, or a non-zero number, the entity will be `available`. If the template returns any other value, the entity will be `unavailable`. If not configured, the entity will always be `available`. Note that the string comparison not case sensitive; `"TrUe"` and `"yEs"` are allowed.
required: false
type: template
default: true
turn_on:
description: Defines an action or list of actions to run when the switch is turned on.
required: true
type: action
turn_off:
description: Defines an action or list of actions to run when the switch is turned off.
required: true
type: action
icon_template:
description: Defines a template for the icon of the switch.
required: false
type: template
entity_picture_template:
description: Defines a template for the picture of the switch.
required: false
type: template
{% endconfiguration %}
### Template and action variables
State-based template entities have the special template variable `this` available in their templates and actions. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an entity's state and attribute in templates and actions.
## Considerations
If you are using the state of a platform that takes extra time to load, the Template Switch may get an `unknown` state during startup. This results in error messages in your log file until that platform has completed loading. If you use `is_state()` function in your template, you can avoid this situation. For example, you would replace {% raw %}`{{ states.switch.source.state == 'on') }}`{% endraw %} with this equivalent that returns `true`/`false` and never gives an unknown result: {% raw %}`{{ is_state('switch.source', 'on') }}`{% endraw %}
## Examples
In this section you find some real-life examples of how to use this switch.
### Invert a Switch
This example shows a switch that is the inverse of another switch.
{% raw %}
```yaml
switch:
- platform: template
switches:
invert:
value_template: "{{ not is_state('switch.target', 'on') }}"
availability_template: "{{ has_value('switch.target') }}"
turn_on:
action: switch.turn_off
target:
entity_id: switch.target
turn_off:
action: switch.turn_on
target:
entity_id: switch.target
```
{% endraw %}
### Toggle Switch
This example shows a switch that takes its state from a sensor and toggles a switch.
{% raw %}
```yaml
switch:
- platform: template
switches:
blind:
friendly_name: "Blind"
value_template: "{{ is_state_attr('switch.blind_toggle', 'sensor_state', 'on') }}"
turn_on:
action: switch.toggle
target:
entity_id: switch.blind_toggle
turn_off:
action: switch.toggle
target:
entity_id: switch.blind_toggle
```
{% endraw %}
### Multiple actions for turn_on or turn_off
This example shows multiple actions for turn_on and turn_off.
{% raw %}
```yaml
switch:
- platform: template
switches:
copy:
value_template: "{{ is_state('switch.source', 'on') }}"
turn_on:
- action: switch.turn_on
target:
entity_id: switch.target
- action: light.turn_on
target:
entity_id: light.target
data:
brightness_pct: 40
turn_off:
- action: switch.turn_off
target:
entity_id: switch.target
- action: light.turn_off
target:
entity_id: light.target
```
{% endraw %}
### Sensor and Two Switches
This example shows a switch that takes its state from a sensor, and uses two
momentary switches to control a device.
{% raw %}
```yaml
switch:
- platform: template
switches:
skylight:
friendly_name: "Skylight"
value_template: "{{ is_state('sensor.skylight', 'on') }}"
turn_on:
action: switch.turn_on
target:
entity_id: switch.skylight_open
turn_off:
action: switch.turn_on
target:
entity_id: switch.skylight_close
```
{% endraw %}
### Change The Icon
This example shows how to change the icon based on the state of the garage door.
{% raw %}
```yaml
switch:
- platform: template
switches:
garage:
value_template: "{{ is_state('cover.garage_door', 'open') }}"
turn_on:
action: cover.open_cover
target:
entity_id: cover.garage_door
turn_off:
action: cover.close_cover
target:
entity_id: cover.garage_door
icon_template: >-
{% if is_state('cover.garage_door', 'open') %}
mdi:garage-open
{% else %}
mdi:garage
{% endif %}
```
{% endraw %}
### Change The Entity Picture
This example shows how to change the entity picture based on the state of the garage door.
{% raw %}
```yaml
switch:
- platform: template
switches:
garage:
value_template: "{{ is_state('cover.garage_door', 'open') }}"
turn_on:
action: cover.open_cover
target:
entity_id: cover.garage_door
turn_off:
action: cover.close_cover
target:
entity_id: cover.garage_door
entity_picture_template: >-
{% if is_state('cover.garage_door', 'open') %}
/local/garage-open.png
{% else %}
/local/garage-closed.png
{% endif %}
```
{% endraw %}

File diff suppressed because it is too large Load Diff

View File

@ -1,217 +0,0 @@
---
title: "Template vacuum"
description: "Instructions how to setup template vacuums within Home Assistant."
ha_category:
- Vacuum
- Helper
ha_release: 0.96
ha_iot_class: Local Push
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_platforms:
- vacuum
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The `template` platform creates vacuums that combine integrations and provides the
ability to run scripts or invoke actions for each of the start, pause, stop,
return_to_base, clean_spot, locate and set_fan_speed commands of a vacuum.
To enable Template Vacuums in your installation, add the following to your
`configuration.yaml` file:
{% raw %}
```yaml
# Example configuration.yaml entry
vacuum:
- platform: template
vacuums:
living_room_vacuum:
start:
action: script.vacuum_start
```
{% endraw %}
{% configuration %}
vacuums:
description: List of your vacuums.
required: true
type: map
keys:
friendly_name:
description: Name to use in the frontend.
required: false
type: string
unique_id:
description: An ID that uniquely identifies this vacuum. Set this to a unique value to allow customization through the UI.
required: false
type: string
value_template:
description: "Defines a template to get the state of the vacuum. Valid value: `docked`/`cleaning`/`idle`/`paused`/`returning`/`error`"
required: false
type: template
battery_level_template:
description: "Defines a template to get the battery level of the vacuum. Legal values are numbers between `0` and `100`."
required: false
type: template
fan_speed_template:
description: Defines a template to get the fan speed of the vacuum.
required: false
type: template
attribute_templates:
description: Defines templates for attributes of the sensor.
required: false
type: map
keys:
"attribute: template":
description: The attribute and corresponding template.
required: true
type: template
availability_template:
description: Defines a template to get the `available` state of the entity. If the template either fails to render or returns `True`, `"1"`, `"true"`, `"yes"`, `"on"`, `"enable"`, or a non-zero number, the entity will be `available`. If the template returns any other value, the entity will be `unavailable`. If not configured, the entity will always be `available`. Note that the string comparison not case sensitive; `"TrUe"` and `"yEs"` are allowed.
required: false
type: template
default: true
start:
description: Defines an action to run when the vacuum is started.
required: true
type: action
pause:
description: Defines an action to run when the vacuum is paused.
required: false
type: action
stop:
description: Defines an action to run when the vacuum is stopped.
required: false
type: action
return_to_base:
description: Defines an action to run when the vacuum is given a return to base command.
required: false
type: action
clean_spot:
description: Defines an action to run when the vacuum is given a clean spot command.
required: false
type: action
locate:
description: Defines an action to run when the vacuum is given a locate command.
required: false
type: action
set_fan_speed:
description: Defines an action to run when the vacuum is given a command to set the fan speed.
required: false
type: action
fan_speeds:
description: List of fan speeds supported by the vacuum.
required: false
type: [string, list]
{% endconfiguration %}
### Template and action variables
State-based template entities have the special template variable `this` available in their templates and actions. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an {% term entity %}'s state and attribute in templates and actions.
## Examples
### Control vacuum with Harmony Hub
This example shows how you can use a Template Vacuum to control an IR vacuum cleaner using the [Harmony Hub Remote integration](/integrations/harmony).
```yaml
vacuum:
- platform: template
vacuums:
living_room_vacuum:
start:
- action: remote.send_command
target:
entity_id: remote.harmony_hub
data:
command: Clean
device: 52840686
return_to_base:
- action: remote.send_command
target:
entity_id: remote.harmony_hub
data:
command: Home
device: 52840686
clean_spot:
- action: remote.send_command
target:
entity_id: remote.harmony_hub
data:
command: SpotCleaning
device: 52840686
```
### Vacuum with state
This example shows how to use templates to specify the state of the vacuum.
{% raw %}
```yaml
vacuum:
- platform: template
vacuums:
living_room_vacuum:
value_template: "{{ states('sensor.vacuum_state') }}"
battery_level_template: "{{ states('sensor.vacuum_battery_level')|int }}"
fan_speed_template: "{{ states('sensor.vacuum_fan_speed') }}"
start:
action: script.vacuum_start
pause:
action: script.vacuum_pause
stop:
action: script.vacuum_stop
return_to_base:
action: script.vacuum_return_to_base
clean_spot:
action: script.vacuum_clean_spot
locate:
action: script.vacuum_locate_vacuum
set_fan_speed:
action: script.vacuum_set_fan_speed
data:
speed: "{{ fan_speed }}"
fan_speeds:
- Low
- Medium
- High
```
{% endraw %}
### Add custom attributes
This example shows how to add custom attributes.
{% raw %}
```yaml
vacuum:
- platform: template
vacuums:
living_room_vacuum:
value_template: "{{ states('sensor.vacuum_state') }}"
battery_level_template: "{{ states('sensor.vacuum_battery_level')|int }}"
fan_speed_template: "{{ states('sensor.vacuum_fan_speed') }}"
attribute_templates:
status: >-
{% if (states('sensor.robot_vacuum_robot_cleaner_movement') == "after" and states('sensor.robot_vacuum_robot_cleaner_cleaning_mode') == "stop") %}
Charging to Resume
{% elif states('sensor.robot_vacuum_robot_cleaner_cleaning_mode') == "auto" %}
Cleaning
{% else %}
Charging
{% endif %}
```
{% endraw %}

View File

@ -1,148 +0,0 @@
---
title: "Template Weather Provider"
description: "Instructions on how to integrate Template Weather provider into Home Assistant."
ha_category:
- Weather
- Helper
ha_release: 2021.3
ha_iot_class: "Local Push"
ha_quality_scale: internal
ha_codeowners:
- '@home-assistant/core'
ha_domain: template
ha_platforms:
- weather
ha_integration_type: helper
related:
- docs: /docs/configuration/
title: Configuration file
---
The `template` integrations creates weather provider that combines integrations and an existing weather provider into a fused weather provider.
There are several powerful ways to use this {% term integration %}, including localizing your weather provider information with local information from temperature, humidity, pressure sensors that you own.
Another use case could be using temperature and humidity from one weather platform, with forecasts from a different one.
Output will be converted according to the user's unit system or {% term entity %} override, see [documentation](https://developers.home-assistant.io/docs/core/entity/weather/#unit-conversion).
## Configuration
To enable a Template Weather provider in your installation, add the following to your {% term "`configuration.yaml`" %} file:
(Note, be sure to update my_region in the condition and forecast templates to an appropriate value for your setup).
{% raw %}
```yaml
# Example configuration.yaml entry
weather:
- platform: template
name: "My Weather Station"
condition_template: "{{ states('weather.my_region') }}"
temperature_template: "{{ states('sensor.temperature') | float }}"
temperature_unit: "°C"
humidity_template: "{{ states('sensor.humidity') | float }}"
forecast_daily_template: "{{ state_attr('weather.my_region', 'forecast_data') }}"
```
{% endraw %}
{% configuration %}
name:
description: Name to use in the frontend.
required: true
type: template
unique_id:
description: An ID that uniquely identifies this weather entity. Set this to a unique value to allow customization through the UI.
required: false
type: string
condition_template:
description: The current weather condition.
required: true
type: template
temperature_template:
description: The current temperature.
required: true
type: template
dew_point_template:
description: The current dew point.
required: false
type: template
apparent_temperature_template:
description: The current apparent (feels-like) temperature.
required: false
type: template
temperature_unit:
description: Unit for temperature_template output. Valid options are °C, °F, and K.
required: false
type: string
humidity_template:
description: The current humidity.
required: true
type: template
attribution_template:
description: The attribution to be shown in the frontend.
required: false
type: string
pressure_template:
description: The current air pressure.
required: false
type: template
pressure_unit:
description: Unit for pressure_template output. Valid options are Pa, hPa, kPa, bar, cbar, mbar, mmHg, inHg, psi.
required: false
type: string
wind_speed_template:
description: The current wind speed.
required: false
type: template
wind_gust_speed_template:
description: The current wind gust speed.
required: false
type: template
wind_speed_unit:
description: Unit for wind_speed_template output. Valid options are m/s, km/h, mph, mm/d, in/d, and in/h.
required: false
type: string
wind_bearing_template:
description: The current wind bearing.
required: false
type: template
ozone_template:
description: The current ozone level.
required: false
type: template
cloud_coverage_template:
description: The current cloud coverage.
required: false
type: template
visibility_template:
description: The current visibility.
required: false
type: template
visibility_unit:
description: Unit for visibility_template output. Valid options are km, mi, ft, m, cm, mm, in, yd.
required: false
type: string
forecast_daily_template:
description: Daily forecast data.
required: false
type: template
forecast_hourly_template:
description: Hourly forecast data.
required: false
type: template
forecast_twice_daily_template:
description: Twice daily forecast data.
required: false
type: template
precipitation_unit:
description: Unit for precipitation output. Valid options are km, mi, ft, m, cm, mm, in, yd.
required: false
type: string
{% endconfiguration %}
### Template variables
State-based template entities have the special template variable `this` available in their templates. The `this` variable aids [self-referencing](/integrations/template#self-referencing) of an {% term entity %}'s state and attribute in templates.