Is there any possible way to make those global? Or new feature request to put them in a variables.yaml file. in configuration can you split up everything so in my case will be:
Also handy , I will make for all my entities a variable then.
When I need to change a entity, I only have to change it on 1 place in the variables file.
The initial WTH that lead to the implementation of the variables, asked for global variables as well. I think at this point we just need to wait for the devs.
The limitation of using an input_select as a global variable is that whatever values one sets dynamically are lost after a restart. In other words, it’s useful for holding constants but if the goal is to have an automation store a value, it will be lost after a restart.
The WTH regarding Global Variables received almost 150 votes but, unfortunately, wasn’t interesting enough to attract any developer’s attention (to implement it).
The enhancement that was introduced is effectively Local Variables which is very useful but falls short of being global. Nevertheless, it’s a promising development and perhaps someday we will have true Global Variables.
tried this one. But I don’t see that you can give a variable a entity id
Ad you can see I use the variables to replace the entity_id names. My idea is to remove the variables part into 1 file so everywhere I can use them. (as spoken already earlier)
You have also illustrated the main difference between hass-variables and true global variables.
Hass-variables creates entities. Data is stored in the entity’s State value, where its type can only be string, or in its attributes where its type isn’t restricted to string. That’s just a bit more flexible than using an input_text (lacks a service to assign attributes). Retrieving a value is the same as with any other entity, either by using its fully qualified name, states.variable.whatever.state, or using a function, states('variable.whatever').
A true global variable would work like the new (local) variables. The type can be anything and you retrieve its value directly, by simply using its name.
For example, in poudenes first post, there is a variable called adaptive. If it were a true global variable, its type would be int (or float) and a template could refer to it by name:
{{ 12 + adaptive }}
In a nutshell, true global variables wouldn’t be entities and the syntax for using them (set/get a value) would be a bit more compact.
Of course, I’m describing vaporware; if someone needs that functionality now, they can use an input_text or the hass-variables custom component.
But you would still have to declare the variable somewhere along with it’s declared data type. Otherwise, if it’s an imputed data type derived from it’s properties then I can see it getting messed up as it is now with the way templates types are being determined. And we can see how that is starting to have it’s limitations being exposed (which is why I wanted a specified data type to be declared instead of the “fuzzy logic” situation we have now).
And it would have to be stored somewhere in the system to be accessible outside its local environment.
So with all of that you might as well save it to the state table as any other entity is stored along with it’s state and attributes. Unless you think that creating some other mechanism for storing/accessing the “thing” would be a benefit.
If it’s outside of the current schema then we would have to all learn a different way of doing things but only for that one type of “thing” that wouldn’t act like any other “thing” (I’m not even sure how to reference it other than “thing” since calling it a variable implies to me an “entity” that has defined properties).
And that’s why I’ve used the hass-variables component way more than the input_text - which I literally don’t use at all.
I know this is an old topic, but it is one of the few I can find about hass-variables.
I have created 3 variables and {{ states.variable | count }} returns 3. But I cannot reference them as an array {{ states.variable[0].value }}. This returns nothing. {{ states.variable[0].attributes.friendly_name }} produces error: ‘None’ has no attribute ‘attributes’. The variable is defined as
variable:
variable1:
value: 0
attributes:
friendly_name: Variable One
use: “Testing”
Should haas-variables be able to be referenced as show above or is there something I am missing?