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.
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.
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).
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).
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.
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.
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:
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
A way to use global values in the UI in building blocks, of course.
Increment and Decrement building blocks.
these could optionally have limits, and (optional) actions to take if a limit is hit
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.
In some cases helpers are the right solution, but in others they simply aren’t user friendly. If designing a blueprint that needs to store persistent information between runs, or even across one run due to the restrictive scoping of variables, the blueprint needs to ask the unvitting user to select/create a helper. WTH?
This is not something the user should ever have to see or think about, it should Just Work™. It is not user friendly and needs to be addressed if the goal is for Home Assistant to be adoptable by a larger audience of less technically literate.
I don’t even want persistent data between runs I just want data to be “available” across the whole automation execution, regardless of nesting of logic within that one automation.
