Variables in automations

Configuration
1

In order to make automations more efficient, I do use some global variable declarations, like they are used for blueprints. Very handy to define some global variables at start, see examples below. These variables have limitations , like you can’t use them inside any loop, but still usefull and worked for years. Unfortunately not anymore since last releases.

Why? and what might be alternatives?

Example1: using a variable to ‘hold’ the initial state:

- id: '3bc00eb3-de8a-4274-9e6c-c94d1c23d2d8'
  alias: example
  mode: single
  variables:
    inital_state: '{{ is_state("switch.light_bathroom", "on") }}'
  trigger:
  - platform: state
    entity_id: binary_sensor.bathroom_hygrostat
    to: 'on'
    from: 'off'
  condition:
    - condition: time
      after: "06:00:00"
      before: "23:30:00"
  action:
  - service: logbook.log
    data:
      name: example
      message: 'initial light state {{ inital_state }} '

Example2: using variables to match temperature modes that can be preset globaly. These presets will be used an more than one point in the automation.

- id: '3ee8531e-f420-4f95-8e44-de4273e07f20'
  alias: Thermostat_sync
  description: Sync thermostat with radiators
  mode: parallel
  max: 10

  variables:
    thermostat_modes:
      -  mode: Eco
         temp: '{{ states("input_number.temp_eco") |float(0) }}'
      -  mode: Comfort 
         temp: '{{ states("input_number.temp_comfort") |float(0) }}'
      -  mode: Spaarstand 
         temp: '{{ states("input_number.temp_low") |float(0) }}'
      -  mode: Uit 
         temp: 10
    matched_temp: >-
          {{ thermostat_modes
              | selectattr('mode', 'eq', states('input_select.thermostatmode_living'))
              | map(attribute='temp')
              | list |first |float(0) | default(0) }}
    matched_mode: >-
          {%- if states('input_number.temperature_living') |float(0) == states('input_number.temperature_dining') |float(0) %}
            {{ thermostat_modes
                | selectattr('temp', 'eq', states('input_number.temperature_living') |float(0))
                | map(attribute='mode')
                | list |first |default('none') }}
          {%- else -%}
            none
          {%- endif -%}

 # rest of the automation..
1 Like
2

Hi, can’t help you with the technical issue but maybe it might help to add not working anymore (since HA v xxxx.x.x)? to your topic title.
This might attract the right people to help you.

Now it can be interpreted as a statement, that you are sharing information, …

3

Home Assistant doesn’t natively support the concept of global variables.

In Home Assistant, a script variable’s scope is limited to the script (or automation) in which it’s defined. Its scope can even be narrower if it’s defined within a script’s if or choose or repeat. A true global variable could be defined in one script and referenced in another script.

Reference:
Scope of variables

The value of a script variable defined outside a loop (repeat) can be accessed inside the loop. However, if its value is modified inside the loop, that’s equivalent to defining a new variable whose scope is limited to the loop. In other words, its new value will not be accessible outside the loop. This behavior is due to a variable’s scope (see reference link posted above).

I’m using version 2023.7.3 and script variables are working the same way as they did in previous versions.

4

Agreed, this appears to be working the same way if did before.

5

Sorry, as you can see in the examples, it is indeed about local variables, but at script level…

6

I examinated this, and it turns out that it works for me some times. Example 2 has been used in multiple scripts, and seems to work in one of them. Time to puzzle further… #workedyesterdaysyndrom

7

Then I suggest you replace the adjective “global” from your first post with either the word
“script” or nothing at all.

You said that script variables “works for me some times”. Under what circumstances did it fail to work?

8

like I said: example 2 has been used in multiple scripts, and seems to work in just one of them.

9

Post the one failing script employing example 2.

10

Don’t know why, but seems working again!
Thank you all for your suggestions and comments!

11

So is the Solution to wait a month for the problem to disappear? :thinking:

Nothing changed since August 4th? Like maybe a restart, reboot, or an upgrade?

12

Haha… no, I don’t think so. I tried various solutions. In most cases like the first example, I simply worked around by not using a variable. Then I thought: if one of them is working, then variables should be working anyway. So I copied the working version (as shown in the second example) and adapted the sensors referred in it, removed blank lines and shortened the id (without dashes in it). And oh yea, had a couple of updates and reboots in the mean time. No clue what actually was the real trick, but it works.

13

In that case, the post marked with the Solution tag offers no actual solution for users who are experiencing the same problem.

The tag’s purpose is to identify the post that answers a question or explains how to fix a problem. In this case, it doesn’t do any of that; it’s unclear what corrective action(s) served to eliminate the problem.

Should the problem ever recur, take note of the exact steps taken to eliminate it. The steps themselves will help others and may even shed light on the underlying cause of the problem.

1 Like