diff --git a/source/_integrations/template.markdown b/source/_integrations/template.markdown index 28d844f0d9e..1ed54346405 100644 --- a/source/_integrations/template.markdown +++ b/source/_integrations/template.markdown @@ -55,15 +55,15 @@ Button, image, number, and select template entities are defined in your YAML con _For old sensor/binary sensor configuration format, [see below](#legacy-binary-sensor-configuration-format)._ -# UI configuration +## UI configuration Sensor template and binary sensor template can be configured using the user interface at **{% my helpers title="Settings > Devices & Services > Helpers" %}**. Select the **+ Add helper** button and then select the **{% my config_flow_start domain=page.ha_domain title=page.title %}** helper. To be able to add **{% my helpers title="Helpers" %}** via the user interface, you should have `default_config:` in your `configuration.yaml`. It should already be there by default unless you removed it. -# YAML configuration +## YAML configuration -## State-based template binary sensors, buttons, images, numbers, selects and sensors +### State-based template binary sensors, buttons, images, numbers, selects and sensors Template entities will by default update as soon as any of the referenced data in the template updates. @@ -86,7 +86,7 @@ template: {% endraw %} -## Trigger-based template binary sensors, buttons, images, numbers, selects and sensors +### Trigger-based template binary sensors, buttons, images, numbers, selects and sensors If you want more control over when an entity updates, you can define a trigger. Triggers follow the same format and work exactly the same as [triggers in automations][trigger-doc]. This feature is a great way to create entities based on webhook data ([example](#trigger-based-sensor-and-binary-sensor-storing-webhook-information)), or update entities based on a schedule. @@ -405,16 +405,16 @@ template: [trigger-doc]: /docs/automation/trigger -### Video tutorial +#### Video tutorial This video tutorial explains how to set up a Trigger based template that makes use of an action to retrieve the weather forecast (precipitation). -## Template and action variables +### Template and action variables State-based and trigger-based template entities have the special template variable `this` available in their templates and actions. The `this` variable is the [state object](/docs/configuration/state_object) of the entity and aids [self-referencing](#self-referencing) of an entity's state and attribute in templates and actions. Trigger-based entities also provide [the trigger data](/docs/automation/templating/). -## Rate limiting updates +### Rate limiting updates When there are entities present in the template and no triggers are defined, the template will be re-rendered when one of the entities changes states. To avoid this taking up too many resources in Home Assistant, rate limiting will be automatically applied if too many states are observed. @@ -455,9 +455,9 @@ template: If the template accesses every state on the system, a rate limit of one update per minute is applied. If the template accesses all states under a specific domain, a rate limit of one update per second is applied. If the template only accesses specific states, receives update events for specifically referenced entities, or the `homeassistant.update_entity` service is used, no rate limit is applied. -## Considerations +### Considerations -### Startup +#### Startup If you are using the state of a platform that might not be available during startup, the Template Sensor may get an `unknown` state. To avoid this, use the `states()` function in your template. For example, you should replace {% raw %}`{{ states.sensor.moon.state }}`{% endraw %} with this equivalent that returns the state and never results in `unknown`: {% raw %}`{{ states('sensor.moon') }}` {% endraw %}.