Challenge: Calculate & use a templated delay in an automation

I’m looking to calculate a delay based on the difference between the current state value of cover.iblinds_window_blind_controller_level and the automation triggered payload that was just set via MQTT.

Here is my current automation:

  alias: Blinds - Kitchen 1 (RefreshValue)
  description: OpenZWave/1/command/refreshValue/
  trigger:
  - platform: mqtt
    topic: OpenZWave/1/command/setvalue/
  condition:
  - condition: template
    value_template: '{{ trigger.payload_json[''ValueIDKey''] == 357138449 }}'
  action:
  - delay: 00:00:10
  - service: mqtt.publish
    data:
      topic: OpenZWave/1/command/refreshvalue/
      payload: '{ "ValueIDKey": 357138449 }'
  mode: single

I want to replace the delay: 00:00:10 with: the difference between the current state of the entity and the new value that was set. So if current state is 22% and new value is 77%, an Excel formula would be: ROUND( ABS( 22 - 77 ) * .11, 0 ) = 6. Minimum would be 0 seconds, maximum wound be 11 seconds for 99%.

Challenge accepted :wink:

{{ (((22-77) | abs) * 0.11) | round(0) }}

replace the 22 & 77 with the correct states(‘x’) entities.

1 Like

And to limit the size to the range 0 to 11:

{% set x = (((22-77) | abs) * 0.11) | round(0) %}
{{ ([0, x, 11]|sort)[1] }}
1 Like

I believe from the criteria above that the values shouldn’t ever get above 99. Maybe…unless I misunderstood… So the values should be self limiting to a max of 11.

But never hurts to be failsafe if it’s a concern.

Yeah I just re-read it. Looks like he was saying that would be the range, not that it had to be constrained to that range.

That was a clever way of doing that tho.

I’ll keep that in mind for later if needed.

Which I can’t take credit for: Limit a value to fall within a range

Thank you both!

Now for part 2…
Having trouble implementing the trigger.payload_json into the formula:

  action:
  - delay: {{ ((( cover.iblinds_window_blind_controller_level.current_position - trigger.payload_json["ValueIDKey"]["Value"] ) | abs) * 0.11) | round(0) }}

The error is:
trigger.payload_json error

I got a green check-mark!

  action:
  - delay: "{{ ((( states('cover.iblinds_window_blind_controller_level.current_position') - trigger.payload_json['ValueIDKey']['Value'] ) | abs) * 0.11) | round(0) }}"
1 Like

New issue!
abs is not working…

ABS is not working
ABS is not working result

Try abs( x - n )

In template editor, {{ abs (40 - 84) }} shows blank…

no space between the abs function and brackets.

You’re right it is only available as a filter not a function. Enclose your numbers in brackets as suggested in your other topic.

{{ abs(40-84) }} doesn’t work but {{ (40-84) | abs }} did.

Yep I just tested it. See above.

I had to modify my delay: since I originally tried states() when I should be using state_attr()…

{{ ((( state_attr('cover.iblinds_window_blind_controller_level','current_position') - 50 ) | abs) * 0.11) | round(0) }}

gives me ‘4’ now in the editor.

Final code:

  alias: Blinds - Kitchen 1 (RefreshValue)
  description: OpenZWave/1/command/refreshValue/
  trigger:
  - platform: mqtt
    topic: OpenZWave/1/command/setvalue/
  condition:
  - condition: template
    value_template: '{{ trigger.payload_json[''ValueIDKey''] == 357138449 }}'
  action:
  - delay: "{{ ((( state_attr('cover.iblinds_window_blind_controller_level', 'current_position') - trigger.payload_json.Value ) | abs) * 0.11) | round(0) }}"
  - service: mqtt.publish
    data:
      topic: OpenZWave/1/command/refreshvalue/
      payload: '{ "ValueIDKey": 357138449 }'
  mode: single

I know you got it fixed already but did you see why you got the results you did with that code?

basically what you did was:

{{ 40 - (84 | abs) }}

You only took the absolute value of 84.

Filters work on the parameter directly before them. so “| abs” only worked on 84.

just as this:

{[ 0.5 * 1.9 | int }}

will give you 0.5 since it only int’s the 1.9. Not the whole thing.

Yes, thanks…I did see that. Kind of strange logic compared to a pipe in other languages though! Knowing the order of operator precedence is crucial, and for me, learning something new is always a good thing!

There’s a note right at the bottom of the templating document: https://www.home-assistant.io/docs/configuration/templating/#priority-of-operators other than that it’s BODMAS.

I guess I should RTFM cover to cover! Thanks for pointing that out and teaching an old dog a new acronym.

1 Like