alias: Add Three or Five Jinja
sequence:
- variables:
if_then_add: |
{% set x = value + 5 if value is odd else value + 3 %}
{{ {'value': x} }}
- stop: Addition complete
response_variable: if_then_add
mode: single
fields:
value:
name: Value
required: true
Using If/Then Actions does not work
Neither of the following will work.
alias: Add Three or Five If/Then Inside
sequence:
- if:
- condition: template
value_template: "{{ value is odd }}"
then:
- variables:
value_plus_three_or_five: |
{{ {'value': value + 5} }}
- stop: Added Five
response_variable: value_plus_three_or_five
else:
- variables:
value_plus_three_or_five: |
{{ {'value': value + 3} }}
- stop: Added Three
response_variable: value_plus_three_or_five
mode: single
alias: Add Three or Five If/Then Outside
sequence:
- if:
- condition: template
value_template: "{{ value is odd }}"
then:
- variables:
value_plus_three_or_five: |
{{ {'value': value + 5} }}
else:
- variables:
value_plus_three_or_five: |
{{ {'value': value + 3} }}
- stop: Added to Value
response_variable: value_plus_three_or_five
mode: single
ok, thank you for clearing this out! I guess I’ll take the easy route and use a helper input boolean instead of a script return variable that I can control during the execution of the script.
This basically means that the whole script visual editor is useless for scripts that return a value.
When programming functions it’s common to either have a bunch of returns or to define a variable, set it as you go along, and then return it at the end. Neither of these are possible using the HA visual script editor.
At the very least we need a way to call stop from within actions (preferably with a value rather than having to define a variable first) but ideally a way to modify sequence-level variables. Since the outer variables are available to read surely it must be close to possible to modify them, even if it’s just a property of a dict.
I agree with this sentiment. I started converting to a more DRY automation base leveraging scripts and response variables. It’s counter intuitive for programmers that you can’t define a variable at top of scope and alter it somewhere nested scope and have that value bubble up the scope.
The result of this design is that you have a TON of repeated code everywhere, which diminishes the value of scripts.
Thank you for your reply.
Yes, your script works but the choose-action will be pretty useless that way?!
My original script is longer and more complex with 3 choose options, this little script was shortened to show what I want.
To be honest, I don’t get it.
Why is the notification filled correctly with the value of the variable when the variable does not get passed inside nested actions?
How can I build an if/else/elsif in a script and return the result to a automation?
You have to build the if, then, else logic in the variables template itself. You can’t build/modify the variables in nested actions because it’s not possible.
Thank you for your help.
I still do not understand why that’s not possible, but that’s not the topic.
I’m pretty sure the responded variable isn’t usable in automations with nested actions too.
(I’ve tried and it doesn’t worked for me) I’m setting the value into an helper entity.
This I can use in nested-actions.
That is the literal reason. If you don’t understand that statement, I suggest you read up on what scope means in the context of coding.
In a programming language, scope refers to the area where a function or variable is visible and accessible to other code . Below are some common terms associated with scope: Global scope refers to a global or public space. Local scope refers to a local or restricted region.
Each nested level has it’s own local scope, and it’s not shared between parent levels.
Hi, all!! can’t get working response_variable using in python script pro integration. so, from trace i see the variable is evaluated, but when i am using services in dev tool, by running this script i do not see response value, although it is defined in script UI. any help from any one? do i misunderstanding response_variable concept?
In practice it doesn’t work. Passing response variables in the specified scope is still blank on the other side. So either the docs are wrong or there is a bug. In addition, what the community has been saying is this is simply not a workable paradigm, even if it did work as documented. Variables init’d outside of a branching scope should be lifted to the outer scope when set.
So if the stop, which passes the response variable, is inside the conditional and the variable is populated inside of the same conditional it doesn’t pass the value. You’re saying this is by design?