Pass trigger.id to Script without YAML syntax?

[Sawtaytoes]

I’m able to pass a variable to the scene selector and stay in the visual editor mode rather than YAML mode:

This is the YAML just to prove it really is a variable (and I tested it working):

I was wondering if it’s possible to do the same with "{{ trigger.id }}"?

This is what it looks like when I try to call my Script:

If it weren’t for that dynamic Trigger ID, I could have a nice clean UI like this:

Why is it that only scene selection allows variables in the visual editor? Also, is there a way I can fix my Trigger ID field to allow dynamic values like the scene selector?

[Sawtaytoes]

Well, this kinda sucks, but I can do a Template for the Trigger ID instead of a Select:

That works, but it doesn’t give me any documentation as to the names I’m expecting in the script for these trigger names. Is there a way to document that cleanly?

[Didgeridrew]

Why not just keep the select, but make it not required… then template in a default of trigger.id if the input field’s value is undefined?

[Sawtaytoes]

I didn’t realize I could do that! Great idea ! I’ll try that out.

[Sawtaytoes]

I tried that:

But then it kept me in the YAML mode as soon as I did it.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

This is me calling a script that accepts data:

    - service: script.siren_on
      data:
        on_time_fld: 240
        volume_fld: 100

That’s all it takes.

Calling this script:

siren_on:
  description: 'Cycle pattern and timer for siren(s)'
  trace:
    stored_traces: 10
  fields:
    on_time_fld:
      name: Run the siren this long in seconds
      description:
        Number of seconds that the timer should sound
      required: true
      selector:
        number:
          min: 10
          max: 360
          step: 10
          mode: slider
      example: "35"
    volume_fld:
      name: How loud the siren
      description:
        Number from 0 to 100% volume level.
      required: false
      selector:
        number:
          min: 0
          max: 100
          step: 1
          mode: slider
      example: "45"
  variables:
    cycles: >
      {% if on_time_fld > 14 %}
        {{ (on_time_fld/15) | round(0,1) | int }}
      {% else %}
        1
      {% endif %}
    volume: >
      {% if volume_fld | default(0) %}
        {# Scale back down to 0 > 1. #}
        {{ volume_fld / 100 }}
      {% else %}
        0
      {% endif %}
  sequence:
  - service: switch.turn_on
    data: {}
    target:
      entity_id:
        - switch.front_panorama_l_siren_on_event
        - switch.front_panorama_r_siren_on_event
  - repeat:
      count: '{{ cycles }}'
      sequence:
      - alias: "Cycle siren 'cycles' times"
        service: siren.turn_on
        data:
          volume_level: '{{ volume }}'
          duration: "4"
        target:
          entity_id:
          - siren.front_panorama_siren
          - siren.front_panorama_siren_2
      - delay:
          seconds: 15
  - service: switch.turn_off
    data: {}
    target:
      entity_id:
        - switch.front_panorama_l_siren_on_event
        - switch.front_panorama_r_siren_on_event
  mode: restart
  icon: mdi:volume-high

I think any form you make trigger_id will make it look like a template.

[Didgeridrew]

Don’t try to define it in the selector… define it elsewhere:

fields:
  trigger_id:
    selector:
      select:
        options:
          - One
          - Two
          - Default
    name: trigger_id
    default: Default
    required: true
sequence:
  - variables:
      trigger_id: "{{ trigger.id if trigger_id == 'Default' else trigger_id }}"

[Sawtaytoes]

Thanks for offering a possible solution!

I’ve been unsuccessful at getting variables to work in the past.

What is this code doing? Automatically setting the trigger_id in the script? Aren’t scripts lacking the trigger context?

[Didgeridrew]

@Sawtaytoes

I’ve been unsuccessful at getting variables to work in the past.

You likely ran afoul of the scoping rules.

@Sawtaytoes

What is this code doing?

Assuming you have an input field trigger_id and some value passed from the originating automation trigger.id, it overwrite the value of trigger_id with the value from trigger.id if the value of the input field is “Default”.

@Sawtaytoes

Aren’t scripts lacking the trigger context?

Wasn’t the whole thing from your original post that you were passing the trigger variable from you originating automation?

When you don’t post the current version of the script in question we can only guess what you are trying to do…

[Sawtaytoes]

I lost this thread, but I wanted to show an update because I’ve had it working for months now.

This is how I’m doing it in my automations that call the script:

And this is how my script handles it through a field:

Because I set the variable as a template, I also get the pretty form, and I can default it to {{ trigger.id }} to make automations simpler.

I can now do everything in a single script call, and that script will call other scripts (quite a few of them):

The worst part about this is tracing down issues. For some reason, there’s no global trace where I can look up and automation and find each path it took all the way down the chain, but I’ve got this set finally.

Ideally, I’d have some sort of Blueprint that allowed adding triggers much easier than just calling into a script. Then I could build in the Trigger ID for a set of devices, but that’s not something Home Assistant makes easy. Blueprints are supposed to be a way to make Automations easier to create, but they’re all YAML, and they’re incredibly difficult to debug.

[123 (Taras)]

@Sawtaytoes

Blueprints are supposed to be a way to make Automations easier to create,

Not exactly. It’s a way to make it easier to distribute customizable automations.

The end-user fills out a form and a customized version of your automation is produced. The end-user never sees or uses any YAML in the process.

Creating the blueprint remains a coding task in YAML.

[Sawtaytoes]

Yeah. I’d like to create Blueprints like I create Automations or Scripts. I want it to be a first-class citizen. That way, not only can I share Blueprints with my folks, I can create them for myself too. One place to manage the code for a bunch of Automations.

[123 (Taras)]

I suggest you consider creating a Feature Request (unless there’s already an existing one for a visual blueprint editor).

[Sawtaytoes]

Where do I request a feature?

[Didgeridrew]

???

WTH can't we create or edit blueprints with the UI

I’m running into the same issue. I kept looking up “Templates” thinking they were what “Blueprints” are. I’ve been struggling with this for 2 weeks now. Home Assistant has great docs provided you know which term to look up. If I could’ve clicked “Blueprints” in the UI using “+ Add Blueprint”, it would’ve been obvious how they work. Blueprints need to be first-class citizens. Scripts are a clutch for me. I finally got to the point where I was trying to write advanced scripts with Trigger IDs and…

[Sawtaytoes]

Well then, looks like I went back in time!