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.
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, …
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.
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.
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
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.
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.