I was trying to see it its the fact you use the template in the wait_template or the template per se causing the issue.
a delay would need a timing though so its not simply replacing the same template to check. You could try playing a media file on a media_player and then use my template to see if that finishes correctly.
About intermediary entity: that’s indeed what I do also. the input sets the active media_player, which then is populating the sensor, which state is again used in the template…
I use another option in my intercom scripts, using subscripts, which holds the template as a condition:
Ok…
For background I am writing a new (hopefully) more flexible and robust notification system.
This automation is one part of it so may not make too much sense in isolation, but here it is.
The whole thing works but is is currently showing the use of the intermediate sensor in the wait_template
#============================================
#=== Notification say published announcement
#============================================
- alias: Notification say published announcement
trigger:
- platform: mqtt
topic: notifications/announcement
condition:
#=== Only continue in normal hours or priority announcement
- condition: or
conditions:
- condition: time
after: '07:00:00'
before: '23:30:00'
- condition: state
entity_id: input_boolean.announcement_priority
state: 'on'
action:
#=== Optional pause before speaking
- delay: >
00:00:{{ '{:02}'.format(states('input_number.announcement_pause') | default(0) | int) }}
#=== Make the announcement
- service_template: >
tts.{{ states('input_select.announcement_voice') }}_say
data_template:
entity_id: >
{{ states('input_text.sonos_group_master') }}
message: >
{{ trigger.payload }}
#=== Wait until announcement starts playing
- wait_template: >
{% if states('sensor.sonos_master_state') == 'playing' %}
True
{% else %}
False
{% endif %}
#=== Now wait until it has finished playing
- wait_template: >
{% if states('sensor.sonos_master_state') == 'paused' %}
True
{% else %}
False
{% endif %}
#=== If Last announcement then continue to clean up
- condition: template
value_template: >
{{ is_state('input_boolean.announcement_last', 'on') }}
#=== Restore Sonos
- service: sonos.restore
data_template:
entity_id: >
{% for boolean in states.input_boolean if 'announcement_on_' in boolean.entity_id and is_state(boolean.entity_id, 'on') -%}
media_player.{{ boolean.entity_id.split('.')[1].split('_media_player')[0] }}{%- if not loop.last %}, {% endif %}
{%- endfor %}
#=== Remove this announcements identity
- service: input_text.set_value
data:
entity_id: input_text.announcement_id_in_progress
value: None
#=== Turn off announcement in progress
- service: input_boolean.turn_off
entity_id: input_boolean.announcement_in_progress
It didn’t care if the input_boolean was on or off and simply waited forever. Attempts to run the script again resulted in the expected error message that the script was already running.
It’s entirely possible that the wait template creates a listener based on input_text.text1 only and not the entity_id contained in states(‘input_text.text1’). I’d be willing to bet that this is the case based on how triggers and sensor templates work.
If my hypothesis is true, it would seem like ‘wait_templates’ could use an enhancement. I.E. Add the entity_id property to them. But yes, the work around would be a template sensor.
EDIT: I bet you could get around this by creating a list of your entities inside the template.
{% set list_that_isnt_used = 'sensor.x', 'sensor.y', 'sensor.z' %}
you could hold that for now please. What ever the reason might be, and @petro is probably right, we should be allowed to expect the same behavior for the same template in the HA system everywhere.
If the template syntax we use successfully in an automation/script as condition or delay doesn’t work when used as a wait_template, this is at least unexpected, undesirable at that, and thus at least a bug in expectation…
as another example this syntax proves to be working just fine:
