I think there’s still some misunderstanding. I’m not trying to get to work the above examples per se, some of them can also be achieved in other ways. The issue is that the event_template_reloaded trigger is not working for any of my templates even the simple ones (see the first example). All templates work fine otherwise, they just stay on unknown for too long. So I know for sure that the template part of the sensors is correct, there’s something wrong on the trigger side.
Hi Again,
As event_template_reloaded just works on my HASS install, I’m going to go back to suggesting creating a separate test trigger just for debug. There may be some complex parser issue with the code you already have, hence the idea of stripping things right back to the simplest example, and building back up again in stages.
This comes from years of dealing with vendor 3d line support who demanded a minimal code example to demonstrate an issue before escalation. Creating the test case often explained what was really going on!
Q: Does my test code above work in your install? If no, can you remove other triggers until it does?
As an aside, note that 2022.04 adds an alternative to the id: syntax - Variables on Trigger. This does suggest that the trigger code is changing behind the scenes.
I’m not quite sure in how many ways I can explain that I’ve already confirmed it is just the event_template_reloaded trigger that is not working. Frankly, I’ve a hard time imagining a simpler example than my first one anyway.
All your example does is show me what I already know, that all sensors are working fine in every other way.
Having said that, on recent tests it has gotten better, but in that weird “sometimes it suddenly works” kinda way. I suspect there’s some sort of race condition going on for this reason.
I’d rather not bump old topics, but after all this time I’m still having this issue with most of my template entities. I was just making a new very simple one, and it again shows as unknown on reloading the templates where it should just read off. Since I can’t find any bug report on this, I feel like I’m going crazy, I have to be doing something wrong, but I can’t figure out what.
The yaml is as follows:
- trigger:
- platform: numeric_state
entity_id: sensor.power_consumption_phase_l3
above: 0.4
id: "on"
- platform: numeric_state
entity_id: sensor.power_consumption_phase_l3
below: 0.1
for:
seconds: 180
id: "off"
# template entities reloaded or hass restarted
- platform: event
event_type: event_template_reloaded
id: "reload"
- platform: homeassistant
event: start
id: "reload"
binary_sensor:
name: "koken"
state: >
{{ trigger.id == "on" and states('sensor.power_consumption_phase_l1')|float(0) < 0.5 }}
Old topic, but you are right!
For trigger based entities, at template reload, the previous entiteit state is restored. That also happens without adding the related trigger.
But for new entities there is no previous state, so it remains unknown, till another trigger kicks in.
When you add the reload trigger, it won’t change that behavior. In my opion that is a bug. When the reload trigger is defined, the entity state should be recalculated. The same as for none trigger based template entities.
I will make a ticket.
I’d argue strongly against that. Recalculating the template when not specifically triggered could cause unexpected values to be resolved by the template. e.g. I only want to calculate a value just before midnight in many templates.
Reloaded @tom_l
What is the purpose of being able to add the reloaded trigger of it doesn’t trigger?
When I add that trigger, I deliberately want that template to be re-evaluated every time the templates are reloaded. Otherwise I would not add it.
1 Like
Geez. I even quoted you saying that. Sorry it’s late and I somehow thought you meant all triggered templates.
Apologies.
No problem👍
If the reloaded trigger, as the name suggests, triggers after the reload, all values should be settled , good night Eric
I found a simple work around!
Just create simple automation to monitor the event_template_reloaded event and then fire a my_event_template_reloaded event. That event will trigger your template entity, if you add the my_ prefix.
The automation:
alias: Template reloaded
description: ""
trigger:
- platform: event
event_type: event_template_reloaded
condition: []
action:
- event: my_event_template_reloaded
event_data: {}
mode: single
The trigger in the template entity:
- platform: event
event_type: my_event_template_reloaded
Thanks, I will try this out next time I run into the issue. I don’t understand your explanation of the bug though and I’m surprised your solution works, because in the end it really is the same thing isn’t it? The event is just ‘renamed’ this way.
@sophof The bug is basically that the reload event is ignored when declared as a trigger. Just relaying it to another event, does work.
Default behavior for trigger based templates is that the previous value is restored at a reload. Most of the time, that will be equal to doing a recalculation. But since this change, the event declared as an explicit trigger, seems disabled (the bug). During developing new templates, we need these recalculations to evaluate without a restart. Fixed with my workaround 
It’s not a bug. The template integration is reloading when the event is fired, therefor the template entities that rely on the event don’t see the trigger because they are reloading themselves. Your work around seems to work because the automation is forwarding the event, you can still run into issues if you don’t add a slight delay to your automation between the trigger and action.
e.g.
alias: Template reloaded
description: ""
trigger:
- platform: event
event_type: event_template_reloaded
condition: []
action:
- delay: "00:00:01"
- event: my_event_template_reloaded
event_data: {}
mode: single
That sounds like it is correct to me, since it would also explain the ‘race condition’ nature of this issue. I do wonder if it isn’t a bug though, surely the event should wait until the reload is complete? Or is there no way to know when that has happened?
I would assume that is the case once all entities are created (still starting with an unknown status in that case, but very quickly evaluating based on the trigger).
The name is ‘reloaded’. So if that is named correctly, there will be no race condition and there is no reason not to pass the event to the template entities as a trigger.
@petro thanks for the suggested delay. Note: I didn’t see any race conditions yet without this delay. But I’m not using any other template entities in the sensors that use this reloaded trigger. If people do that, the delay probably is a good idea
I would swear that the event used to be posted after the Template integration finished reloading (not before).
In fact, way back in 2021, I created an FR asking for such an event (signal when Template integration finished reloading) and then discovered it already existed in the form of event_template_reloaded. I used it successfully in several Trigger-based Template Sensors.
Back then, a Trigger-based Template entity’s state did not survive a restart. So I wanted an event, to trigger a Trigger-based Template Sensor, whenever the Template integration was finished reloading (like on startup and whenever the Template integration was reloaded to add a new Template entity). The Event Trigger became unnecessary after the Template integration was enhanced to store the state of a Trigger-based Template entity.
If the event now occurs during the reload phase, then that’s a Breaking/Backwards Incompatible change I don’t recall seeing in the release notes.
Maybe it was never documented in Breaking Changes and is the side-effect of some other PR. For example like when a PR sought to improve performance and expand ceased to sort its output. That seemingly innocuous change, buried in “All Changes”, quietly broke templates that relied on expand’s previous behavior.
I don’t know when, but it seems to work in core 2024.4.3.
Today I created this sensor to detect in case it would work in the future. To my surprise the sensor got initialized and the counter increases with every template reload:
# detect if the reloaded event works in the future
- trigger:
- platform: event
event_type: event_template_reloaded
binary_sensor:
- unique_id: no_hist_last_event_reloaded
name: no hist last event reloaded
state: "{{ this.attributes.last|default(0) > 0 }}"
attributes:
last: "{{ this.attributes.last|default(0) + 1 }}"
Yes, I also recently noticed that it now works properly (like it used to in the past) and the event is posted after Template entities are reloaded. Not sure which version corrected it.
Nice, you confirmed. I closed my core issue.
1 Like
Noticed a behaviour like “template not triggered by event” and posted this thread:
Trigger-based sensor: is it reliable to listen to event_template_reloaded?
Taras said that the issue seems to be fixed, and I wonder may be I am getting smth wrong.