Wait_template with dynamic timeout. Should this work?

It is well documented elsewhere on this forum that I am not the best at working with times :rofl: :joy: :rofl:

If I want to implement a dynamic timeout in a wait_template, should this work?

      - wait_template: >
          {% set tnow = as_timestamp(now()) | int %}
          {% set timeout = states('input_number.wait_timeout') | int  %}
          {% if timeout != 0 %}
            {{
              is_state('sensor.some_sensor', 'some_state') or
              as_timestamp(now()) | int > tnow + timeout
            }}
          {% else %}
            {{ is_state('sensor.some_sensor', 'some_state') }}
          {% endif %}

No, :rofl:

Ha ha!
Yes and you are one of those who have in the past been on the receiving end of my crapness with time.

So, why not?

Your print statement is boolean Read later

Yikes!!!
Yes indeed it is!

But is the principle sound?

I have absolutely no idea as you have not defined what you expect to do.
I would ‘assume’ that you would want to set a ‘time’ value based on the condition of various sensors but that’s not what you have written.

Hang on, wait_template wants a true or false
The actual timeout needs a time.
I am not using timeout just trying to ‘fake it’

I think what I have makes sense.

The wait_template evaluates to true or false (if my time calculations make sense)

I’m on a tablet, where is the wait documentation?

It looks sound to me except the logic of including this in both cases:

{{ is_state('sensor.some_sensor', 'some_state') }}

If the time-out has expired or the sensor is in state ‘x’ else if the sensor is in state ‘x’.

Pretty sure you can drop the or sensor bit from the first template and it will still do the same thing.

Yeah, found the documentation (is someone deliberately hiding stuff? I had to use Google :roll_eyes:)

You check if timeout is not 0 then go with x (Tom’s term) but if timeout = 0 then now +0 is now anyway, so dispense with the if, get rid of the else and go with the first (like Tom said :rofl: )

Edited

@tom_l & @Mutt

Thanks.
The reason for the ‘if’ is because I want to be able to have no timeout i.e. wait indefinitely for the sensor state ‘x’.

So,
if timeout is not zero wait for the sensor state ‘x’ or a maximum time of ‘timeout’
if timeout is zero wait for the sensor state ‘x’ indefinitely.

1 Like

Okay, let us know how this goes.
@tom_l the reason I’m cautious here is that I have some doubts.
The template is written so that if your input number is say 10 seconds, then with the sensor at ‘some state’ it won’t fire immediately (it should wait 10 secs) but does that mean that the wait: tests the template every second till it fires ?
(okay, there are ‘undocumented’ instances where now() will update in the template)
But I’ve not tested this situation and as far as the docs go there is nothing in the template to trigger an update.

As I said, let us know

This may not work if tnow is continually evaluated. I’m pretty sure it will be.

      - wait_template: >
          {% set tnow = as_timestamp(now()) | int %}
          {% set timeout = states('input_number.wait_timeout') | int  %}
          {% if timeout != 0 %}
            {{
              is_state('sensor.some_sensor', 'some_state') or
              as_timestamp(now()) | int > tnow + timeout
            }}
          {% else %}
            {{ is_state('sensor.some_sensor', 'some_state') }}
          {% endif %}

You could use the automation last_triggered attribute instead of now() for tnow.

1 Like

Very good point.

So obvious it is almost genius.
Thank you!

Is there a shorthand for ‘the current automation/script’ like there is for triggers or is the only way to do this?

{% set tnow = as_timestamp(state_attr('automation.the_name_of_this_automation', 'last_triggered')) | int %}

That’s it. Though you don’t need |int for timestamps.