Global variables / long-lived variables in Automations

[victorigualada]

Hi all,

I think we should have a way to define variables in automations/blueprints that could be accessed in different automations instances and that survive different calls. A Global Variable that could be set and got in posterior calls to that automation.

This variable should only be accessible from the automation they were declared.

I’m aware that this can be achieved with an input text helper or through the hass_variables component, but it shouldn’t be necessary to create a different entity just to make data available in an automation. I really think this messes up with some basic coding principles.

Also this could be helpful in Blueprints. I’ve already seen multiple blueprints that require you to separately create a helper to achieve this functionality.

What i suggest would be add a property global_variables apart from the existing variables one.

Then it could be stored as a state for the automation:
states.automations.my_automation.global_variables.

What do you guys think?

[123 (Taras)]

This is a long-standing (at least 4 years) wish that has never been granted. Until it’s implemented, if ever, you can store information using a Trigger-based Template Sensor (no custom integration required).

Example 1

The following example demonstrates how to create a sensor that can store a single value of type string, limited to 255 characters (same as an Input Text).

WTH can't input helpers be read only in UI

Yes. I you can use a trigger template sensor like this: template: - trigger: - platform: event event_type: set_my_sensor sensor: - name: My sensor state: "{{ trigger.event.data.state }}" And then you can change it in a script or automation like this: action: - alias: Update my sensor event: set_my_sensor event_data: state: new_value Can even add attributes if you want, just pass more data in the event and use it in attributes in the sensor config. Plus trigger template …

The example can be enhanced to store a single value of any type without a size limitation by simply storing it as an attribute.

Example 2

Here’s a more sophisticated version. A single sensor that’s able to store multiple values of any type (string, int, float, list, dict, boolean, etc) and size.

WTH can't input helpers be read only in UI

here you go: Trigger based template sensor: template: - trigger: - platform: event event_type: set_variable - platform: event event_type: remove_variable sensor: - unique_id: 4a4c8e53-9e68-4198-9cc5-b336e228ea4d name: Variables state: Variables attributes: variables: > {% set current = this.attributes.get('variables', {}) %} {% if trigger.event.event_type == 'set_variable' %} {% set …

For both examples, you use a native event call to store a value (i.e. no custom service call is employed).

The advantage of using a Trigger-based Template Sensor, instead of Input Helpers, is that the stored value isn’t limited to being a string (under 255 characters long) but any type and size plus it’s read-only in the UI (i.e. a user can’t easily/accidentally/maliciously modify it).