cool, thanks for the feedback , let me know if I can help!
It’s just me, trying to sort out the semantics. I initially thought I would add a trigger to an existing Template Sensor (or Template Binary Sensor) but it’s more like I move the exiting Template Sensor to the Template Trigger integration.
In other words, this:
template:
- trigger:
- platform: time
at: '00:00:00'
sensor:
- name: Festive Season
state: "{{ <Festive Season template> }}"
- name: Some Other Sensor
state: "{{ <Some Other template> }}"
NOT this:
sensor:
- platform: template
sensors:
festive_season:
trigger:
- platform: time
at: '00:00:00'
friendly_name: 'Festive Season'
value_template: "{{ <Festive Season template> }}"
some_other:
trigger:
- platform: time
at: '00:00:00'
friendly_name: 'Some Other'
value_template: "{{ <Some Other template> }}"
1 Like
Oh … yes, you are right. The trigger sensors are using the modern config layout that e.g. rest sensors recently moved to. Eventually you should be able to drop trigger: from the new syntax and get a traditional template sensor but that has not been implemented yet.
1 Like
just to grasp this completely:
when a template in the sensor section of the trigger template platform changes state, does the trigger template sensor still update, even if the trigger doesn’t, or is the empty [] ?
that is how I understood it, and hoped it would work, but some remarks in the discord channel get me doubting that…
template:
- trigger:
platform: homeassistant
event: start
sensor:
- name: Unknown entities
state: >
{{ <Unknown entities template> }}
should only change state at startup?
A trigger-based template only updates due to the specified triggers. So [] never updates, except manually. And I actually just learned that manual updates will not work in the initial release so []will be rather useless at first.
(Non-trigger updates are tricky because the templates can reference trigger data that is missing in a normal update)
So you have to catch the error and log it?
Like when people use an incorrect trigger object in their automation templates.
The tricky part is enabling the forced update in a seamless way.
If you have good ideas, this is currently being discussed in #48630.
I know it can be a bit daunting to participate in GitHub discussions. Feel free to make your points in this thread instead and I will forward those that I agree with 
I would but github is blocked where I am right now.
actually, this; https://github.com/home-assistant/core/pull/48630#issuecomment-812846887 was what I had in mind indeed. If that wont be made available for these trigger-based templates, and we need to ‘think’ about the service to use, depending on the domain/integration, it will not be as user friendly as hoped for… and prone to unnecessary confusion.
Would think the backend needs some extra intelligence to keep that from the end-user?
Of course, this is for using it without passing extra variables (which I don’t grasp just yet anyways, because we are talking a sensor here, why should we need to pass extra variables? Or is that for use inside the templates of the sensor?)
Why not build on the homeassistant.update_service to allow for these variables? Dont think it is wise to make the same error confusion again, of creating different sorts of services/options for almost identical integrations, like with the template sensor and template binary sensor, which, because either one lacks the options of the other, will be PR’d after that, and create a lot of discussion which could be prevented.
(in fact, this whole new template-trigger based sensor could be seen as the late realization of what we have been asking for in this thread: dont take out the option of entity_id: …)
1 Like
It includes that as well but it is much bigger: it enables template entities that update from timers, events, webhooks, even templates. And it does it without additional special case syntax or helper entities like sensor.date. So it is more useful and less ugly, hence more acceptable.
(I actually think something like “support any trigger” was proposed here but the thread is so long that I cannot check. Would be interesting to see why it wasn’t picked up back then.)
Yes that is really very nice indeed. But again, if the entity_id: would have been there still, the only thing needed now was having a template sensor in that field?
We can create a template sensor for any of the triggers you mention and use that for entity_id.
I think it was even me who suggested to use the terminology now used in custom:button-card: triggers_update .
Guess all I am saying is: please keep it as simple as can be.
Maybe have a look at the current toolset and check if a simple/small addition can’t be made, before creating a whole new integration which can do many of the existing possibilities but with a superset of options.
No, because webhooks and events wouldn’t trigger it. The whole point of this change was to make event based sensors, where users could use events and push that data to a sensor. The rest that @amelchio is talking about is just the icing on the cake.
Also, entity_id is long gone, bringing it up at this point doesn’t serve any purpose moving forward.
1 Like
correct, and thats why I contemplated:
well, that might well be and we’re fully adjusted to that now
No need to reprimand me, I was merely answering to Amelchio’s
and, I don’t agree with your statement at all. It is never a bad thing to look back to see if things couldn’t have been done better. I won’t argue for bringing back entity_id, in fact the trigger: words even a bit better.
It’s just that we were quite forcefully mouthed down some 6 months ago for mourning the demise of it, and now see it return in different cloths…
1 Like
It’s not returning to solve the entity_id issues that you keep bringing up. It was made allow users to create persistent event based sensors. It’s a happy coincidence that it solves the issues brought up with the removal of entity_id. Also, leveraging the trigger data allows us to reuse existing code and it lets users become instantly familiar with the new integration.
that’s cool. and reason I enthusiastically applauded this development. Don’t get me wrong there.
you really should relax on this somewhat, I’ve mentioned it only twice now, and merely as reference to a past discussion, not advocating bringing it back at all.
water under the bridge now, anxious to see what goodies are coming our way. Though Add trigger service to template by balloob · Pull Request #48630 · home-assistant/core · GitHub is still being discussed to a final decision.
I only keep mentioning it because you keep implying that these changes were meant to solve this issues highlighted with it’s removal. 
You need to understand that these changes will not be made to solve the issues that are highlighted, so do not expect it. If it happens, it happens and we can all go home happy.
It dawned on me that Trigger Templates effectively implement something I had suggested last August (for WTH) namely an “Event Binary Sensor”. Balloob was receptive to the concept and had posted a hypothetical example of the proposed beast.
The end-result appears to be more capable than what I envisioned because it not only supports event-based sensors but addresses an advanced user’s need to control the updating frequency of traditional Template Sensors. Very nice indeed!
Only thing left is to sort out the service call to manually update it. I agree that homeassistant.update_entity seems like the ideal choice but I don’t have a handle on the implementation complexities.
2 Likes
It’s much more than that. The flow that was developed for the new rest integration will end up making it’s way into all the template integrations. Regurgitated code will be a thing of the past. This is just the first step in that direction.
been a while since we met here… but since we discussed the new updating of templates own this thread most fundamentally, and dev’s asked us to post possible left over issues, I do believe I found one…
It is related to the frontend, but testing this in the dev tools template seems to bug the system. It doesnt kill it (completely), like some did before, but still, comes awfully close:
title: Hue & Trädfri batteries
card_mod:
class: class-header-margin
entities:
- type: custom:hui-element
card_type: markdown
card_mod:
style: |
ha-card.type-markdown {
margin: -8px -16px;
box-shadow: none;
}
content: >
Batteries below threshold:
{% set batteries = expand(integration_entities('Ikea Trådfri'),integration_entities('hue'))
|rejectattr('state','in',['unavailable','unknown'])
|selectattr('attributes.device_class','eq','battery') %}
{%- set alert_level = states('input_number.battery_alert_level')|int(default=0) %}
{%- for b in expand(batteries)
if b.state|int(default=0) < alert_level %}
{{- b.name}} in {{ area_id(b.entity_id)|title }} : {{b.state}} %
{% endfor %}
and was even worse when using
{% set batteries = expand(integration_entities('Ikea Trådfri'),integration_entities('hue'))
|rejectattr('state','in',['unavailable','unknown'])
|selectattr('attributes.device_class','eq','battery') %}
{%- set alert_level = states('input_number.battery_alert_level')|int(default=0) %}
{%- for b in expand(batteries)
if b.state|int(default=0) < alert_level %}
{{- b.name.split(' Battery')[0]}} in {{ area_id(b.entity_id)|title }} : {{b.state}} %
{% endfor %}
when this is tested and reloaded after an edit, I can see the system swirl for some time, and, happened more than a few times now, take out the Ping integration, notifying me of all of my Hubs going offline…
now the is a bug in itself, 1 Ping sensors takes out all others (there’s an issue for that since long), but this does seem like a case for the core dev template team… 
related to https://github.com/home-assistant/core/issues/60781
Hope Amelchio is still around to have a look, thanks!