Why, in HA automations and scripts etc. are Variables not updateable?
I’m sure there must be a good, deep reason, and I’d like to understand it.
In every other programming language/environment I’ve used, there has always been the ability to both declare and update a variable with a (new) value. I.e. there’s an assignment operator, usually = or :=, but in HA not so.
In HA scripts as far as I understand, e.g. “people: value”, creates a new variable (with its own local scope) each time it’s used.
Example:
example_script:
variables:
people: 9 # Var1
sequence:
- variables:
people: 0 # Var2
- if: "{{ some_condition }}"
then:
# At this scope and this point of the sequence, people == 0 ( Var2 is seen)
- variables:
people: "{{ people + 1 }}" # Var3 is created, NOT Var2 updated.
# At this scope, people will now be 1 ... but that's Var3.
- action: notify.notify
data:
message: "There are {{ people }} people home" # "There are 1 people home"
# ... but at this scope 'people' (Var2) will still be 0
- action: notify.notify
data:
message: "There are {{ people }} people home" # "There are 0 people home"
# people (Var1) is still 9, but ?unreachable?
All variables have local scope. The example clearly demonstrates this behavior.
When you define a variable in a nested block with the same name as a variable outside the block, it’s not the same variable, it’s a different variable. Its scope is limited to the block where it’s defined.
Virtually everything in Home Assistant that requires a computed value is done using Jinja2 templating. You don’t redefine a script variable’s value using YAML if-then or choose.
Hi @arturpragacz and thanks for your reply.
Do you say “historical baggage” from long knowledge of HA or being a HA developer, or your own research on the point?
What do you mean by “It will hopefully be fixed soon.”? I’ve not found any posts on implementing script variable mutability, so far.
Re your WTH post, having read through it a few times, I’m not clear exactly what it is you’re asking for. As docs Declaring Automation scope variables. says under Configuration Variables / Variables, what you seem to ask for is already there. Which is why I suspect you’re actually asking for something more - but what? The topic’s forum discussion ranges over much else, mostly wider “Scope” related wants.
Please PM me if you want to discuss your WTH further, rather than digress in this post or resurrect your WTH (last post Dec 2024) - unless you want to…
Variable mutability is what I’d like to see added, and what this post refers to.
Thanks Taras, but I think we’re just repeating the “Local Scope” documentation.
Variable “Scoping” and “Mutability” are totally separate things. It’s the lack of mutability I’m asking Why? about.
Admittedly local scope makes the syntax of variable updating trickier for variables of the same name at different scope levels (i.e. which variable are you updating?), but that’s just a syntax issue. Most computer languages use local scoping and provide variable mutability, including Python, so why not HA in Automations/scripts, etc?
Maybe, as arturpragacz says, the Why is lost in history… or is one of those quirks of choice we make early in big implementations…
Cheers, Ian
Re your WTH post, having read through it a few times, I’m not clear exactly what it is you’re asking for. As docs Declaring Automation scope variables. says under Configuration Variables / Variables, what you seem to ask for is already there. Which is why I suspect you’re actually asking for something more - but what? The topic’s forum discussion ranges over much else, mostly wider “Scope” related wants.
Please PM me if you want to discuss your WTH further, rather than digress in this post or resurrect your WTH (last post Dec 2024) - unless you want to…
That WTH is effectively asking for the same thing you are asking: for the ability to update variable values. And it’s not mine, I’m not the author, I haven’t even posted in it. I’m not resurrecting anything, I’m directing you to the right place.