Yes! As I’ve applauded your suggestion on Discord, please add the option indeed. Adding
trigger: []
to replace the former ‘entity_id’ and have it not updated using that is a great tool to add. allowing 100% enduser control (in a non hacky way 
)
I saw the PR awhile ago, thought it was a very good addition, but didn’t fully appreciate the extent of this new feature’s usefulness. Thanks for explaining some of the long-standing pain points it mitigates.
For example, I recently wanted a simple Template Binary Sensor to indicate the Christmas season. Basically, it would be on for about a month and a half. However, the template’s time calculation, employing now(), would be computed every minute (when it only needs to be done every day). In other words, the template only needs 365 evaluations annually, not the 365 * 1440 it will perform.
I believe the trigger-based template sensor will allow me to trigger on sensor.date (i.e. once a day) then compute the template’s time calculation. Regardless of how many spare CPU cycles are available, this is simply a more efficient technique. I look forward to trying it when released next week. 
as Frenck explained, it can trigger on any trigger we now have in automations, that includes template trigger.
Which makes this a hugely powerful sensor platform. adding the suggested trigger: [] would make this an ultimate solution to, well, to anything really.
just wait for variables too
Yeah … or you can use a time: trigger to trigger at: 00:00:00 and avoid the sensor.date helper.
(However, I think binary sensors are not supported in the initial implementation)
1 Like
Good tip, thanks! I was still thinking in the old (and deprecated) “entity_id” mindset.
Good to know; fortunately, a Template Sensor (with on/off states) will work for my intended application. If and whenever Template Binary Sensor is supported, I’ll re-configure the entity.
Hmm, I think I didn’t grasp the concept correctly. This is effectively a new integration, namely Trigger Template, and not a modification of the existing Template (or Template Binary) integration. Nevertheless, it’s still a perfect fit for my intended application.
There are implementation details that cause little code reuse but I don’t see how that changes the concept per se?
… ah, maybe it doesn’t 
It turns out that this is already supported, I must have been confused when I did my test.
Furthermore, we have identified differences between the config syntax in the beta documentation vs. the implementation so it will currently be hard to actually test this feature. This is being worked on.
1 Like
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.