How to use variables in HA

Configuration
21

That certainly works, but if you are trying to package up a blueprint and have everything self-contained for the user to turn on, my way works better.

22

I dont know why no one is telling you this, but you can actually use global variables in jinja by explicitly defining the scope:

{%- set g = namespace(test_var = 1) %}
{{ g.test_var }}
{% some for loop %}
{% set g.test_var = g.test_var + 1 %}
{% endfor %}
{{ g.test_var }}
23

And that’s not the scope issues that OP was running into. namespace only solves scoping issues inside a single template. OP was attempting to use variables defined in action sections that were not in scope of the action section they were in.

24

Lost in the noise of this discussion is a simple question being asked and the apparent answer:

Are there variables in the Home Assistant Scripting Syntax (scripting language) that have script scope, where such a scope is defined as enabling all sequences no matter how deeply nested to update these variables in a manner such that all of these sequences see the updated value?

The answer to this appears to be no!

I suspect the developers of Home Assistant have sound reasons for why this is the case. They are a group of software engineers and developers that clearly know what they doing. However, in absolute terms it simply can’t be denied that this is a lack of functionality which is a glaring hole for any scripting language. In other words this is a glaring hole in the Scripting Syntax.

For you computer science geeks out there I suspect that this means that the Scripting Syntax is not Turing complete for if it were one of the provided solutions would have provided a solution solely within the context of the Scripting Syntax. Further I suspect that the fundamental reason for this is that it is based on YAML which is a declarative language. Declarative languages, in general, aren’t Turing complete.

It seems, however, that Scripting Syntax taken on its face is just a hair step away from being Turing complete and that this issue with variables of script or automation scope is that hair. (I mean there are conditional statements, loops, etc.-- all the things necessary for Turing completeness-- but variables choke). I can’t, for the life of me, think of why, in principle, it couldn’t be resolved but almost certainly that is because I haven’t thought about it to the degree that the Home Assistant engineers have. My suspicion is it has to do with how YAML is parsed.

All of this said it should be pointed out that Pico1965’s original state of confusion was perfectly reasonable and there was nothing green or uninformed about his/her expectations. The short-coming was never his/her code but rather it truly was a short-coming of Scripting Syntax. Most of the many presented solutions were reasonable, if not necessarily convoluted, under these circumstances. However, having to go through such gyrations simply because a language, which ideally really should be, is not Turing complete is inarguably less than ideal.

As home automation becomes more and more sophisticated and Home Assistant continues to spread its wings to keep up with the challenges of this growing level of sophistication, it sure would be nice, to help reduce the proliferation of Helpers and the like of other otherwise unnecessary external structures, that Scripting Syntax could be made Turing complete.

Just to be clear I am not the one down in the weeds of the code on this issue so perhaps it is just much easier said than done. After all, to reiterate, Home Assistant has some fabulous software engineers and developers. I am sure it has been considered.

25

Hello Christopher C. Mills,

You may make too many assumptions…

Helpers can be used anywhere and any scope.

Also this:

Also the MQTT trick I use above.

26

You misunderstood my post, probably because I was not being clear enough. I know Helpers can address the problem of no global variables within the Scripting Syntax. I know that there are other “work-arounds” posted in this thread. My point is that functional as these may be they are all less than optimal options as they are all external to the Scripting Syntax.

I am a seasoned professional software developer. I have been knocking out code since the 1970s in a plethora of languages. When I am working within the Scripting Syntax I want to stay within it and not build a bunch of structure external to it just to get the script to work. Heck, I avoid Jinja and YAML as much as possible when setting up my Home Assistant even though I am perfectly comfortable using both. I want my setup to be as straight-forward and UI based as possible so that when I come back to it in the future it is understandable quickly.

Keep it simple!

Let me be clear: the thought of creating a Helper just to provide a global variable for a script is just an awful kludge from a programming standpoint. First of all it leads to a proliferation of Helpers that serve no purpose other than supporting a script of which they will not obviously be a part. So a year later when one is trying to understand why they have some arbitrary Helper that they can’t figure out what it is for, they now have to partake on a research project to decide whether to delete it or keep it.

This kind of programming mishegoss just becomes an incredible headache the more one expands their home automation system. Yes, I know the relationship to the script of a Helper will likely show up in a Related listing but this requires spending time digging around to investigate how it is being used, etc…

I could go on about the other solutions presented above too, but hopefully I am getting my point across.

A global variable capability for Scripting Syntax is really what one would expect for any scripting language and Scripting Syntax doesn’t have it! (More accurately, it lacks reasonable variable scoping rules for a scripting language.)

Btw, my expectations here had been low for a long time. I had always thought of the Scripting Syntax as being more declarative-like. However, with the introduction of Actions returning values suddenly making use of such values requires some useful variable capability.

Two final notes:

  1. I wanted to point out clearly that Pico1965, as humble as he/she was in their inquiry, had a correct intuition about their expectation of having a global variable capability. It by all rights should be there. His/her coding expectation was perfectly reasonable. Scripting Syntax is the problem here not Pico1965’s “greenness.” Home Assistant is aimed at developers who are at the level of Pico1965 and the better it gets at meeting their expectations the better Home Assistant becomes.

  2. I am not, by any means, tearing down the remarkable development effort that has gone into Home Assistant when I point out this shortcoming. This Open Source project is simply remarkable! I am sure there is a good reason for this lack of global variables. Even if it is some sort of an oversight they have gotten so much so right on this project, continuing to expand it each and every month. There is just nothing any one could fairly complain about.

This project is a gift.

I have to say, though, it sure would be nice to have a global variable in Scripting Syntax! (I probably should turn this in as a feature request, huh?) :slightly_smiling_face: