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?