Make variables global

Hi ALl,

I make use of the new variable options in many of my automations:

    season: sensor.season
    kay_learning: switch.kay_learning
    peter_early_up: switch.peter_early_up
    guests: switch.scene_guests
    motion_toilet: binary_sensor.motion_detection_toilet
    motion_bedroom: binary_sensor.motion_detection_bedroom
    door_sensor_diningroom: binary_sensor.neo_diningroomdoor_custom_sensor
    door_sensor_bedroom: binary_sensor.neo_bedroomdoor_custom_sensor
    adaptive: "{{ states('sensor.adaptive_lighting_color_temperature')| round(0) }}"

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:

variables: !include package/includes/variables.yaml

Or can I add this in every automation:

!include package/includes/variables.yaml

to include the file into the script?

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.

1 Like

try this

1 Like

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.

1 Like

I remember having read somewhere that the newly introduced variables are just the beginning of solving this WTH and more will come later.

use this custom component and it will allow you to do exactly what you want:

It is a fork of a repo from @rogro82 which had been abandoned. I’ve used the original one for a long time and it works great.

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)

- alias: "Motion Detection - Kitchen On Off"
  mode: restart
    - platform: state
      entity_id: binary_sensor.motion_detection_kitchen
    - platform: state
      entity_id: sun.sun

    goodnight: switch.scene_goodnight
    motion_kitchen: binary_sensor.motion_detection_kitchen
    adaptive: "{{ states('sensor.adaptive_lighting_color_temperature')| round(0) }}"

    - condition: state
        - switch.scene_goodnight
        - switch.scene_cooking
        - switch.sink
      state: "off"

    - condition: state
      entity_id: sun.sun
      state: "below_horizon"

    - service: mqtt.publish
        topic: "homeassistant/ha_motion/kitchen"
        payload: "{{ 1 if is_state(motion_kitchen, 'on') else 0 }}"

Of course you can.

you can make the variable state anything you want. An entity id is just a string. So you can create a variable like this:

    value: 'switch.scene_goodnight'
    restore: true

then you use it just like any other entity state

value_template: "{{ states('variable.goodnight') }}"

which will return ‘switch.scene_goodnight’

And you can even change the entity id (the state of the variable) dynamically and it will survive restarts.

service: variable.set_variable
  variable: goodnight
  value: 'some_other_entity_id'

TBH, I have no idea why HA doesn’t just integrate the custom component as an official integration as-is.

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.

I get what you are saying.

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
value: 0
friendly_name: Variable One
use: “Testing”

Should haas-variables be able to be referenced as show above or is there something I am missing?

No HA states can be referenced like that.

Variables are just another domain like lights, switches, etc.

Thanks for the quick reply.
I will have to find another way to accomplish what I want to do.


After installing and putting following code in my configuration.yaml:

        value: 'Unknown'
        restore: true
            icon: mdi:map-marker
            name: "Last Motion"

I get error that Integration error: variable - Integration ‘variable’ not found.

Can’t get it to work… anyone have a clue ?



Have you actually installed the hass-variables custom integration?