Adjust heading levels in template sensor docs (#31545)

The headings for _UI_ respectively _YAML configuration_ is incorrectly a `h1`, should be `h2` instead as the `h1` should only be used for the title of the page.

To avoid too much nesting, I've kept the `Examples` heading at the `h2` level.
This commit is contained in:
Oscar Björkman 2024-02-22 08:35:43 +01:00 committed by GitHub
parent 1aaf062793
commit fa57906df2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -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).
<lite-youtube videoid="zrWqDjaRBf0" videotitle="How to create Action Template Sensors in Home Assistant" posterquality="maxresdefault"></lite-youtube>
## 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 %}.