WTH can't we have simple automation/script scope variables?

I was recently working on an automation where it is triggered by a specific state and I wanted to check for additional states then WAIT and check if those states where still the same.

Turns out you can set variables in automations but for some reason can’t have a variable that has a scope of an automation? So I needed to go create a helper entities and set and check that.

So why don’t we have variables that are for the scope of a single automation or script? They would be very useful? I don’t really like creating persistent helper entities as a workaround.

Edit: To clarify it is the current limitation of them not working across the whole automation as per the scope of variables example.

### Scope of variables

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.

You can create variables only for automation:

Do you mean persists the variable across multiples execution of the same automation?

2 Likes

As in Static vs Instance?
A feature within a feature! :wink:

Variables that can be used across multiple automation runs would indeed be very useful. Especially for blueprint creators.
Bonus points if they could restore their state after a HA restart.

I had a talk with Frenck about that once - he mentioned it could lead to race conditions - especially with lists. And that there was a PR once that would introduce a key-value-store that could tackle the same problem. https://github.com/frenck/spook/pull/509
IMHO it’s not as practical though since the automation would need to scope the key somehow and would have to do some kind of cleanup when deleted. But maybe I didn’t get the idea 100% right.

1 Like

That is exactly what helpers are for, typed global variables that you set and change easily, even from your dashboard.

1 Like

Your point makes sense, since helpers are accessible via UI, templates, etc.
Speaking from the programmer POV, using a helper for something like a static variable just feels … clunky. Coarse-grained. “Stone knives and bearskins.”
That said, I still think your point is well-taken; that helpers are perhaps the best form for statics to take in a hybrid environment (where scripts and fingertip-UI have to coexist).

4 Likes

Sorry I completely misread that WTH. I thought they wanted variables for use across different automations.

Variables for use in one automation or script actually already exist. See: https://www.home-assistant.io/docs/scripts#variables I think the issue here they are trying to highlight is their limited scope inside the automation (also explained at the same link).

They want a global variable with the scope of one automation or script.

+1 from me.

5 Likes

Correct, the SCOPE OF VARIABLES disclaimer outlines the problem.

1 Like

Scope is the problem that we don’t have a nice easy solution for.
I believe a this.x variable that we can load or read and has global scope within the script / automation would be awesome. This would beat namespace templates and be easier to teach new people as well.

I have WTH and [FR]'ed this before, but it needs to be brought up again.

1 Like

Yes, a variable with global scope would be very usefull. Something you can actually change in an if-then, repeat or choose and then still access outside of it, without the need to use helpers only for that automation run.

3 Likes

Yes, exactly. When I saw the WTH Month blog post, this is what came to mind first, and I’m glad to see it’s already being discussed.

I would like to add something, though: I’d like to be able to set variables from the UI, not just YAML. I’m imaginging:

  1. Enhance the Define Variable building-block action:
    • add a “Global” checkbox
    • Make it a friendly field, rather than requiring YAML and a template
    • possibly, a selector for data type (Number, Text, Boolean…)
    • options to set the initial value from an entity, an entity attribute, a fixed number, another variable, or a template
  2. A way to use global values in the UI in building blocks, of course.
  3. Increment and Decrement building blocks.
    • these could optionally have limits, and (optional) actions to take if a limit is hit
  4. Perhaps: a Variable Math building block which would take take four parameters: the variable to take the result, a first value, an operator (add, subtract, multiply, divide), and the second value. As above, the vaules could be an entity, an attribute, etc.
    • this could just be advanced options for Define Variable, probably renamed to Set Variable
    • Probably should encourage people to use templates for anything more complicated than “a = b + c” kind things.

Also FWIW, I think it makes sense to leave global state and long-term storage to Helper entities.

Homey might be the GOAT of Smart Home UX. It wouldn’t be fair to steal their designs, but it also wouldn’t make sense to ignore what they have achieved.