Home Assistant Template Sensors: A Practical Guide for 2026

A template sensor is a sensor whose value Home Assistant computes from other data in your home. This guide explains what template sensors are, the two ways to create them, and three examples taken from the official Template integration documentation: an average of two temperatures, a day counter, and a unit conversion.

How This Guide Was Built

This guide is based on official Home Assistant documentation: the Template integration page, the templating documentation hub, and the automation templating reference. The YAML examples are the documentation’s own examples, reproduced verbatim. The examples were not run on a live Home Assistant instance by the author, and no measurements were taken. Key claims link to their source, so you can verify them against the docs. Before building anything, test on a non-critical sensor first.

What a Template Sensor Is

The Template integration “allows creating entities which derive their values from other data. This is done by specifying templates for properties of an entity, like the name or the state.”

If you want a sensor that shows the average of two room temperatures, a day counter, or a converted unit, a template sensor is the documented way to do it.

Sensors are one of several supported entity types. The Template integration docs also list binary sensors, buttons, covers, lights, numbers, selects, switches, vacuums, weather, and others. The patterns in this guide focus on the sensor platform.

Templates themselves are, in the docs’ words, “short snippets of code you can use wherever Home Assistant needs to figure something out for you. Instead of typing a fixed message or value, you write a small instruction that reads your data and produces the right result.” The text between {% and %}, or between {{ and }}, is the template; Home Assistant replaces it with the computed result (templating docs).

Functions such as is_state() read entity states inside a template. The Template integration docs’ Sun State example uses {% if is_state('sun.sun', 'above_horizon') %} to branch on one entity’s state (Template integration). The functions used in the examples below are states(), is_number(), as_timestamp(), now(), and strptime().

Two Ways to Create One: UI Helper or YAML

The UI helper route

For a state-based sensor, the built-in helper is the most accessible route, and the docs say the UI covers “most use cases” (Template integration). Per the same page, go to Settings > Devices & services. Select the Helpers tab, select Create helper, select Template, then select the entity platform you want (Sensor, for this guide) and follow the on-screen steps.

For helpers to appear in the user interface, the docs say you should have default_config: in your configuration.yaml; they note it “should already be there by default unless you removed it” (Template integration). If you are unsure how configuration files work, start with the configuration basics page.

After creation, you can change the helper’s options in Settings > Devices & services > Helpers. Select the helper, then select Settings (Template integration).

The docs state the trade-off directly: “Configuration using our user interface provides a more limited subset of options, making this integration more accessible while covering most use cases,” and “If you need more specific features for your use case, the manual YAML-configuration section of this integration might provide them” (Template integration).

The YAML route

In YAML, “entities are defined in your YAML configuration files under the template: key. You can define multiple configuration blocks as a list. Each block can define entities of any of the supported types, and can contain optional update triggers” (Template integration).

If you are copying older configurations from the internet, note that the older format, with platform: template under a platform key such as sensor:, is no longer supported. If your configuration still uses it, Home Assistant shows a repair (Template integration). Use the modern template: list format shown in the examples below.

State-Based vs Trigger-Based: Which Do You Need?

This is the key design decision, and it determines which worked example you should copy.

	State-based	Trigger-based
How it updates	Updates as soon as any referenced data in the template changes, such as either source sensor in an average (Template integration)	Only when a trigger reacts; “whenever a trigger reacts, all related entities re-render and have access to the trigger data in the templates” (Template integration)
Where you define it	UI helper or YAML; “You can create state-based template entities from the user interface” (Template integration)	YAML under the template: key, with a triggers: block (Template integration)
Typical use	Continuous derived values, like averaging two temperature sensors, the docs’ own example (Template integration)	Controlled timing, like a nightly day counter, the docs’ own example (Template integration)
Restart behavior	—	“The state, including attributes, of trigger-based template entities is restored when Home Assistant is restarted,” except buttons, images, and update entities (Template integration)
Watch-outs	Updates automatically with referenced data; no trigger wiring needed	Needs an explicit State changed trigger per entity to react to state changes; a trigger on the entity itself can loop and “can make Home Assistant unresponsive” (Template integration)

Two trigger-based details matter. First, “trigger-based entities do not automatically update when states referenced in the templates change. This functionality can be added back by defining a State changed trigger for each entity that you want to trigger updates” (Template integration). Second, “a State changed trigger without from, to, not_from, or not_to also fires when only an attribute of the entity changes. To fire only when the state itself changes, add to: null” (Template integration). Triggers “follow the same format and work exactly the same as triggers in automations,” so the automation trigger reference is your trigger-format reference.

Worked Example 1: Average Two Temperatures (State-Based)

This is the pattern behind any combined derived value: take several source sensors and compute one number.

template:
  - sensor:
      - name: "Average temperature"
        unit_of_measurement: "°C"
        state: >
          {% set bedroom = states('sensor.bedroom_temperature') | float %}
          {% set kitchen = states('sensor.kitchen_temperature') | float %}

          {{ ((bedroom + kitchen) / 2) | round(1, default=0) }}

(Source: Template integration, heading State-based template entities.)

How to read it: {% set %} stores an intermediate value; states('...') fetches an entity’s state, as used throughout the docs’ examples; the | float filter converts it for math (see types and conversion and working with states); | round(1, default=0) rounds the result. Because this is state-based, “Home Assistant updates your template sensor as soon as either source sensor updates” (Template integration). To adapt it, swap in your own entity IDs and a unit that matches your sensors.

The docs also include a dedicated walkthrough of this pattern: the average home temperature tutorial, which describes creating “a template sensor that averages all your temperature sensors.”

Worked Example 2: Days Since a Date (Trigger-Based)

This is the elapsed-time pattern: a counter that updates on a schedule rather than reacting to every state change.

template:
  - triggers:
      - trigger: time_pattern
        # This updates every night
        hours: 0
        minutes: 0
    sensor:
      # Keep track how many days have past since a date
      - name: "Not smoking"
        state: '{{ ( ( as_timestamp(now()) - as_timestamp(strptime("06.07.2018", "%d.%m.%Y")) ) / 86400 ) | round(default=0) }}'
        unit_of_measurement: "Days"

(Source: Template integration, heading Trigger-based template entities.)

How to read it: the time_pattern trigger with hours: 0 and minutes: 0 fires at midnight, matching the docs’ comment “This updates every night.” The state template uses as_timestamp(now()) and as_timestamp(strptime(...)) to get two timestamps, subtracts them, divides by 86400 (seconds in a day), and rounds. For dates and times in templates, see the docs’ dates and times page.

The critical difference from Example 1: trigger-based entities do not automatically update when referenced states change. Here that is fine, because the value only changes at midnight. If you need the sensor to react to a state change too, add a State changed trigger for each entity, keeping the to: null nuance from the table above.

When a trigger fires, your templates can read the trigger data through the trigger variable, for example {{ trigger.to_state.state }} for a state trigger (automation templating). For time pattern triggers, trigger.now is a “DateTime object that triggered the time pattern trigger, in your local time zone” (automation templating).

Worked Example 3: Convert Units Safely with an Availability Template

This example converts a sensor’s unit by doing math on its state, and it shows the documented way to guard against a source sensor that is not currently numeric.

template:
  - sensor:
      - name: "Transmission Down Speed"
        unit_of_measurement: "kB/s"
        state: "{{ states('sensor.transmission_down_speed') | float * 1024 }}"
        availability: "{{ is_number(states('sensor.transmission_down_speed')) }}"

      - name: "Transmission Up Speed"
        unit_of_measurement: "kB/s"
        state: "{{ states('sensor.transmission_up_speed') | float * 1024 }}"
        availability: "{{ is_number(states('sensor.transmission_up_speed')) }}"

(Source: Template integration, heading State based sensor - Changing the unit of measurement of another sensor.)

Why the availability: template? The sensor does math on the source sensor’s state, so the docs use an availability template “to suppress rendering of the state template if the source sensor does not have a valid numeric state” (Template integration). This matters because of the numeric-state rule: if a sensor is numeric, meaning it has a state_class or a unit_of_measurement, the state template “must render to a number or to none. The state template must not render to a string, including unknown or unavailable” (Template integration).

The Sensor Options You’ll Actually Set

These are the sensor configuration variables the Template integration documents for YAML. name and availability appear in the examples above and in the UI option list:

• state (required): the template that gets the sensor’s value. It is subject to the numeric-state rule above.
• unit_of_measurement: the sensor’s unit, if any. When a device_class is set, “the unit must be one of the units listed for that device class.”
• device_class: “used to pick display formatting and the icon in the UI. It does not set the unit_of_measurement.”
• state_class: controls whether the sensor’s history is kept as long-term statistics.
• attributes: templates for attributes of the entity; you can also template the entire attributes field to avoid repetition.
• last_reset: describes when the sensor’s state was last reset. It “Must render to a valid datetime” and is “Only available when state_class is set to total.”

On statistics, the docs state: “Home Assistant keeps statistics for sensors that have a state class, such as measurement, total, or total increasing. Every 5 minutes, it saves short-term statistics, which are deleted after 10 days by default. Every hour, it saves long-term statistics, which are never deleted automatically. The Energy dashboard and statistics cards use them” (Template integration). A state_class is what makes a template sensor eligible for these statistics.

Where to Learn More

The templating hub indexes the full learning path:

• Syntax basics: template syntax and common patterns
• Working with data: working with states, types and conversion, and dates and times
• Control flow: loops and conditions
• Functions: the template functions reference, including the states functions
• Debugging and errors: debugging templates and troubleshooting template errors
• Tutorials: average home temperature and low battery alerts
• Automation templating: trigger data in templates and the automation building blocks

Frequently Asked Questions

Can I do this without touching YAML?

For state-based sensors, yes: Settings > Devices & services > Helpers > Create helper > Template > Sensor, provided default_config: is in your configuration.yaml (Template integration). For anything the UI does not offer, the docs point to YAML.

Why isn’t my trigger-based sensor updating?

Trigger-based entities do not update when referenced states change. Add a State changed trigger for each entity that should drive an update, and add to: null to fire only on state changes (Template integration).

Can a template sensor cause problems?

Yes, if you wire a trigger carelessly. The docs warn that a trigger on the entity itself “fires the trigger again and the loop can make Home Assistant unresponsive” unless the template stops changing (Template integration). Do not trigger a sensor from its own output.

What happens to it after a restart?

For trigger-based template entities, the state and attributes are restored on restart, except for buttons, images, and update entities (Template integration). Buttons do not support the triggers, trigger_variables, or actions options (Template integration).

How do I get it into long-term statistics or the Energy dashboard?

Give the sensor a state_class. The docs name measurement, total, and total increasing as the statistics-eligible values (Template integration). Long-term statistics are saved hourly and never deleted automatically; the Energy dashboard and statistics cards use them (Template integration).

The Bottom Line

For continuous derived values, such as averages, conversions, and combined states, start with the UI helper or state-based YAML. State-based entities update as soon as any referenced data updates (Template integration). For controlled timing, like a nightly counter, trigger-based YAML is the documented path, with triggers that work exactly like automation triggers (Template integration). And carry one safety rule with you: never trigger a template entity from itself or from something computed from it, because the loop “can make Home Assistant unresponsive” (Template integration).

📖 Related Reads

• ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
• NoCode Insider — AI workflow automation with no-code tools, agents, and APIs

Cross-links automatically generated from SmartHome Field Guide.

← Back to guides