I have virtually no experience of templates but I have one (copied below) that works for me when entered in configuration.yaml but I cannot work out how to write it to be used in a helper template, I get loads of error messages about using YAML.
Template Helpers do not support advanced features like triggers, conditions, or attributes. So you cannot get exactly what you have using a Template Helper. You could get something close by using the self-referencing variable, this, but IMO it’s not worth the trouble doing it that way.
YAML is not supported in the helper config flow, only Jinja templating is allowed in the “State” and “Availability template” fields.
The other advantage of using a triggered template sensor is that it is restored after a restart, no need to wait for the source sensor to change. Though most will as soon as home assistant starts.
So what’s the difference between a “helper” template and a regular template sensor (besides the extra limitations stated above)? Is there some benefit using a “helper” over a regular template sensor?
Another feature of Template Helpers that some users find beneficial is that they can be attached to existing Devices. That is not an option for template entities created in YAML.
A bit of background here. I am using a Tuya temperature sensor that under LocalTuya sends data every time the temperature changes, when there are no responses it shows as unavailable. So you might get a set of data three or four times per hour with many unavailable sets. To show a history graph you need to only recognise the data sets and ignore the unavailables. The template above ignores the unavailables by only changing the sensor when valid data occurs.
I could use a helper that works on using the last available data when the current data is unavailable but that itself shows as unavailable until there is a previous data set which is not saved when restarting.
I want to use a template helper rather than a template in configuration.yaml or a called in template.yaml file as I have 36 of these templates to write.
The best solution would be for Local Tuya to understand these sensors and only output the valid data sets. The Tuya cloud service does but I am trying to get away from that.
I find that when needing to recreate a bunch of entities with only minor differences it’s easier to use yaml instead of the UI because of the ability to copy/paste/edit. It saves on a bunch of the clicking around you need to do via the ui.
But to be completely honest I almost never use the UI for anything I don’t have to so I’m probably a bit biased.
Like finity, I don’t understand your logic here. If you have a bunch of sensors that follow the same pattern it’s way easier to do it in YAML than the Helper config flow. You could even use the Template Editor tool to “print” out the config for you to copy/paste into templates.yaml:
#For use in the Template Editor tool only, this will not work directly in a config file
#PUT ALL THE SENSOR ENTITY IDs IN THIS LIST
{%- set sensor_list = [
'sensor.t_h_conservatory_temperature_l',
]%}
{%- for x in sensor_list -%}
{%raw%}- triggers:
- trigger: state
entity_id: {%endraw%}{{x}}{%raw%}
conditions:
- condition: template
value_template: "{{ is_number(states('{%endraw%}{{x}}{%raw%}')) }}"
sensor:
- name: {%endraw%}{{state_attr(x,'friendly_name')}} Stable{%raw%}
unit_of_measurement: "°C"
state: "{{ states('{%endraw%}{{x}}{%raw%}') }}"
state_class: measurement
device_class: temperature
unique_id: 20251218{%endraw%}{{range(1000,99999)|random}}
{%endfor%}
