While I dive more into automations I often find that in many cases you need to go and create some kind of helper entity to store certain state regarding an automation.
While this works fine, I find it cumbersome. I think automations should allow users to define states so the whole process can be ‘self contained’.
Scripts already have a similar feature, you can define variables and use it across your script. The main difference here is that they would be stateful and persist across invocations of the automation.
I know I could simply go to another browser tab and do it, but it would make it easier for people to use some automations. Many blueprints people share here require you to go an create helpers in advance to use them. Imagine if the blueprint could simply declare them. (and for bonus points, being removed if I delete the automation)
example of use case (from smarthome junkie): An automation to cycle across scenes. You need to generate a dropdown helper to store the current scene
I always thought automations should have an internal register that is available in any scope inside the running automation. this.register or similar.
You mention variables, which are available in both scripts and automations BTW, but they loose scope inside nested actions like for, repeat, etc.
A register that we could store stuff and be able to update it in the inner loop, then read it in the outer loop (thru scope changes) would be awesome. While this can be done with input helpers now, when you are setting up a blueprint to share with others, you don.t really want to have to make them set-up a helper as another step to complete. Also if the data is transient, there should be no reason to generate an external entity to store it.
There is a form of this FR that’s been there since blueprints were introduced for the blueprint end…
I think automations, and especially blueprints, should be able to define internal variables with default scope of the whole automation, and optionally available globally (perhaps as attributes of the automation). They would be persistent in the same way as helpers (unlike the variables we have now), but be defined within the automation / blueprint. At the moment, one does not only have to set up the helpers separately (by UI or YAML) but you then have to identify them all to the blueprint. That is unnecessarily tedious and error-prone.
For an example of how tedious this is, see the present implementation of Heating X2: Schedule Thermostats with Calendars . I would like to be able to declare global variables directly inside my blueprint definition using syntax like a helper created in YAML:
blueprint:
name: "Hypothetical example"
description: "Illustration"
domain: automation
input:
## bla bla bla (a list, as now)
### My suggestion for persistent (global) variables
persistent_variables: # my idea
- example_one:
name: "Example One"
type: text # cf. input_text
max: 2048 # no 255 limit
initial: “”
icon: mdi:card-text-outline
public: true # can be read outside this automation
restore: true
- example_two:
name: "Example Two"
type: number # cf. input_number
max: 100
initial: “”
icon: mdi:number
public: true # can be read outside this automation
restore: true
- example_three:
name: "Example Three"
type: datetime # cf. input_datetime
initial: “00:00:00"
icon: mdi:calendar
public: false # cannot be read outside this automation ,
restore: true
- example_four:
name: "Example Four"
type: timer # cf. timer helper
duration: "00:15:00"
restore: true
icon: mdi:clock
public: false # cannot be read outside this automation
### Local (non-persistent) variables as they are now
variables:
example_a: "a volatile variable that lasts on for one run through (as now)"
example_b: !input b
trigger:
## bla bla bla (a list, as now)
# Example four timer end
- platform: state
entity_id: this.example_four
from: active
to: idle
id: example_four_timer_end
action:
## bla bla bla (a list, as now)
Inside the automation, access persistent variables the same way as local variables.
Outside the automation (if public: true), access with a service (like helpers) using <automation_name>.<variable_name> as the entity_id.
Similarly they should be accessible where allowed in templates using {{ states('<automation_name>.<variable_name>') }}
Or within the automation as {{ states('this.<variable_name>') }}
or just {{ states(<variable_name>) }}
As not awesome as it is, you could use MQTT discovery to create them.
I do it with blueprints that are controlling things that already require MQTT, like Z2M, Tasmota, or Octoprint.
Yes, it pretty much is. I like your suggestion for using a template sensor as a repository for all required variables. Using attributes would also get around the 255 character string limit in helpers.
For multiple automations from the same blueprint, I would have to be creative to make the variable name depend on the automation name (or have a separate sensor for each automation).
A lot of my helpers are timers. Is there a way I could set a timer in a template sensor and have it trigger the automation when it expires or is cancelled etc?
For my part, the feature request still stands. It would move HA a step towards object-oriented programming.
