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.
I completely agree that local variable scope should not be the only way variables are scoped in HA scripts/automations. It would be useful with the force of a thousand suns to be able to change a variable within an if block, for example, so that the change persists once the if block is exited.
I recently worked around the distinct-but-somewhat-related problem touched on by some of the replies here, namely the limitations of using helpers for global state, by using trigger-based sensors with attributes. Because I don’t have to create a new helper for each piece of state I want to track–I can store all of this in attributes with dictionaries, lists, etc.–this approach has really opened up a lot of possibilities.
But this approach is also limited by the original issue, i.e. the local variable scope.
More specifically, trigger-based sensors have the really nice feature that an “action” block can be executed, and then top-level variables defined in that action block are available as variables in templates for the various attributes.
But… because it’s the top-level variables that are made available in the attribute templates, all of the logic to set those variables basically has to be done in Jinja: either at the top level of the action block, or in the attribute definitions. HA’s script constructs, like if/choose blocks, are incapable of modifying the top-level variables, so they can’t be used for this purpose.
There’s nothing wrong with Jinja, except for complex logic it gets a little difficult to debug. Moreover, where HA’s if/choose/etc flow is used to take actual actions, any attempt to record state from those actions means that it’s almost impossible to avoid at least some logic duplication between the HA constructs and the Jinja code used to set the variables.
