Is use of action: variable.set_variable a) documented, b) discouraged or ok?

Configuration
1

Is the use of action: variable.set_variable
a) Documented somewhere?
b) Discouraged or ok?
c) Likely to get deprecated?

I’ve searched the HA Documentation (standard and Developers) and not found this action/service documented or used, that I’ve seen.
Nor is it listed in the HA UI / Developer Tools / Actions tab list of Actions.
However, searching the Forums brings back plenty of usage cases.

I’d like to know it’s intended purpose, limitations and future (if discouraged).
And of course how and where to use it correctly : syntax, correct contexts, limitations, etc. E.g. in scripts and automations, does it effectively work as an assignment (my_var = a_value ) operation on a (pre-declared) variable, allowing its value to be updated?
Thanks for any help on this…

2

There is no such action built into HASS. Presumably anyone posting code using it also has this third party integration installed:

Doesn’t seem to have been updated in many years so personally I wouldn’t want to rely on it. Looking at the project’s Issues it also seems to no longer work at all since July or so…

3

Ok. So is there a reason why HA does not support the “assignment” operator (eg. = or := in most languages)? Except of course in the first declaration of a variable where its value can be set.
Appreciating that YAML is not a programming language (though much HA YAML usage is like one), the assignment operator and its ability to update the value of an existing variable is a fundamental in almost every programming language. So I’m assuming there must be a good reason why it’s not implemented in HA. Does anyone know why please?

4

I don’t understand the question. Updating the value of a variable is the exact same syntax as when first declaring it. It just cannot be done within the same variables: block, as that would not be valid YAML.

5

Hi Magnus.
You say “Updating the value of a variable is the exact same syntax as when first declaring it.”
My understanding is that this just creates a new variable (not updates the old), and that new variable comes into sight/scope, so the old one is not seen. If the old var is at a shallower scope level, then it will come back into sight/scope when processing goes shallower than the 2nd variable’s scope level.
If re-declaring a variable at the same scope level is possible, then I suspect it just creates a new variable of the same name which is seen instead of the original, so it looks and behaves like an updated variable, but isn’t.

Example: mostly taken from Scope of Variables in https://www.home-assistant.io/docs/scripts and slightly extended and .# Var2 comments added to clarify.

script:
  example_script:
    variables:
      people: 9    # Var1
    sequence:
      # Set the people variable
      - variables:
          people: 0   # Var2
      # Try to increment people if Paulus is home
      - if:
          - condition: state
            entity_id: device_tracker.paulus
            state: "home"
        then:
          # At this scope and this point of the sequence, people == 0 ( Var2 is seen)
          - variables:
              people: "{{ people + 1 }}"   # Var3 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" 
# And at the outer level Var1 still has value 9.

As per that HA documentation, " Variables have local scope. This means that if a variable is changed in a nested sequence block, that change will not be visible in an outer sequence block. Inside the if sequence the variables action will only alter the people variable (Var3) for that sequence."

My core problem is that in HA YAML you cannot use a variable, “updated” at a deeper scope, and have its (new) value available at the shallower scope. In every other programming language I’ve used, you can do that (because “assignment” exists) and it makes better, shorter and more efficient code structure easy.

But I don’t know why it’s not there in HA and YAML. Must be a good reason…??? Anyone know?

6

Yes, variables only have local scope, which is an annoyance.

But you can still update existing variables within the same scope, i.e.:

- variables:
    hello: Hello
- variables:
    hello: "{{ hello + ' world!' }}"

Also annoying that you cannot define functions, or something even simpler like goto in Basic.

7

There is a more up-to-date fork than what Magnus linked above.

Keep in mind these are still entities, they should not be confused with the variables used in HA’s script syntax.

The integration is a workaround to simplify storing values (including different data types, not just strings) at a global scope without having to separate those values into individual input entity types, each with their own action.

What the custom integration did is now possible to do using Trigger-based template sensors…

8

Thanks, @Didgeridrew , for the update.
But I note you say variables.set_variable applies to entities, not script variables.

I’ll raise a new topic, as per forum guidelines, re why are (script) variables not updateable…

9

You already asked this question in another topic and the answer is clearly explained in the docs.

I’ll rephrase it for you:

The scope of a variable defined within a nested block is limited to that block.

So if you define a variable within the block that has the same name as a variable outside of the block, it’s still a different variable. Its scope is limited to its block.

10

Thanks Taras, but that’s just repeating what I’ve already said. It states How HA works, but not Why? I know of no other programming environment where variables are not updatable, so I wonder Why… Must be a good reason, given the limitations it brings.

11

It does but, unfortunately, not for you. :man_shrugging: