Automations and blueprints should be able to have 'internal' variables or state

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…

Your request sounds like this one which is effectively the same as one made years ago for global variables.

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.

Nice workaround, but I am not using MQTT and would not want to force blueprint users to use it :man_shrugging:

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.