Use a blueprint input in a trigger template

Hi all,

Any help appreciated on this one please :slight_smile:
I’m hopping it is possible :pray:

TLDR: In my blueprint I want to refer to one of the inputs in a trigger template.

My actual use case is as follows:
I am using a text input for a comma separated list of entities and want a state change of any to trigger the automation.

My input in blueprint:

      name: Media Players
      description: "A comma seperated list of media_players in room."

Use of input:

media_players: "media_player.lounge_echo,media_player.lounge_kodi,media_player.lounge_fire_stick"

Then tried using this as follows:

  - platform: template
    value_template: >
      {% set media_players = !input media_players %}
      {{ expand(media_players) }}

I also tried using variables: but I think they are not useable in the trigger.

If I replace !input media_players with the comma separated string it works fine but obviously need this as a variable and not hard coded.

But when referencing the input I get the following error:

invalid template (TemplateSyntaxError: unexpected char '!' at 23) for dictionary value @ data['value_template']. Got None

So I am guessing at this point I cannot access the blueprint inputs in a trigger template.
Or hopefully someone can tell me what I’m doing wrong.

Thanks all!

Try removing the {% set... line and leave the rest as it is.

Thanks for the suggestion! But I got this error:

UndefinedError: 'media_players' is undefined

Which is kind f what I expected as I haven’t then declared media_players as anything.
I also tried:

value_template: "{{ expand(!input media_players) }}"

But to no avail :frowning_face:

Been trying to get this to work myself as I want my phone alarm trigger the automation but only if a boolean in the automation is true. Would be a great to be able to get this to work.

Did anybody find a solution for this?
I have the same problem with

    service_template: >
      {% set curTime = now().strftime( '%H:%M' ) %}
      {% if curTime > !input timeClose %}
      {% elif is_state('binary_sensor.daylight', 'on') %}
      {% else %}
      {% endif %}
    data: {}
    entity_id: !input cover_entity

I get an error about “Blueprint Cover Testing generated invalid automation”
If I replace “!input timeClose” with a fixed string it is parsed without problems.


At a guess, you would need to put the input in a variable and use the variable in the template

  light: !input light
  platform: state
  entity_id: !input light
  service: notify.notify
    message: >
      {% if is_state(light, 'on') %}
        Light is on
      {% else %}
         Light is off
      {% endif %}

Untested, but let us know.

1 Like

Thanks a lot, @anon43302295

With your advice I don’t get any parsing error anymore.
I can tell you tomorrow if everything is working as expected :slight_smile:

My blueprint now looks like this:

  - platform: time
    at: !input timeOpenWork
  - platform: time
    at: !input timeOpenWeekend
  - platform: time
    at: !input timeClose
  - platform: state
    entity_id: binary_sensor.daylight

  timeCloseVar: !input timeClose
  timeOpenWeekendVar: !input timeOpenWeekend
  timeOpenWorkVar: !input timeOpenWork

    service_template: >
      {% set curTime = now().strftime( '%H:%M' ) %}
      {% if curTime > timeCloseVar %}
      {% elif is_state('binary_sensor.workdays', 'on') and curTime < timeOpenWorkVar %}
      {% elif is_state('binary_sensor.workdays', 'off') and curTime < timeOpenWeekendVar %}
      {% elif is_state('binary_sensor.daylight', 'on') %}
      {% else %}
      {% endif %}
    data: {}
    entity_id: !input cover_entity
mode: single

1 Like

Just an observation, but your template only opens the cover if all the previous calculations are false and it’s daylight, it then has 4 other out points that all close the cover - seems like an excessively complicated way to resolve it.

Also service_template is deprecated, just use service.

I didn’t come up with an easier solution. What I wanted to have was:

  • only one automation for opening and closing to have less automations to manage (each room has a different time)
  • open at sunrise but not before a certain time
  • close at sundown but not later than a certain time
  • have different opening time for workdays and vacation days
  • use a light sensor and not the calculated sun rise since the calculation differ from the “experienced” darkness

Yeah, I get that, and I can’t propose an alternative at the minute because I seem to have woken up in a particularly dopey state today, it wasn’t intented as a criticism, just an observation that it seems a bit ‘backwards’ in its logic.

That is to say that regardless of all the arguments that come before it, if binary_sensor.daylight is off - then the cover is being/staying closed. So really that should be the first argument, then if that’s on do the calculation as to whether it should open.

Like I said, I’m having a dopey day so maybe the was you have it is just as efficient as what I could come up with if I was fully awake, it just doesn’t ‘look right’ to me to have a template outputting 5 potential options when 4 of them are the same :slightly_smiling_face:

I’m absolutely in favor of code reviews.
I started with home assistant two days ago and I’m more than happy to learn best practices.
See Trigger closing shades via time and light

I could make only two options out of those four by using “and” and “or” :smiley:
But I find a couple of short if clauses much easier to read and less error prone han lesser but more complicated ones.

What I don’t like with my solution is the time calculation and comparison.
What I understood is that if “now()” is used in an automation that this automation is calculated every minute. I don’t need this. Is it possible to get the time the trigger fired?
And comparing times via string compare is more than ugly. :frowning:

Yeah, you’re probably right - I only brought it up because when I was looking at your code my brain kept nagging me that it was ‘backwards’ logically, but as I say I didn’t actually come up with any solution that would suit you better.

As I understand it (and I must admit I completely lost track of what was going on when the template engine was being re-written, so I may be off) - the recalculation every minute is for template sensors and such like, the templates in actions and conditions are still only evaluated as and when the automation is fired.

I said the comparison of time sucks, right? :wink:

This line didn’t get triggered in the time trigger because if forgot the seconds in the formatting string.

1 Like

Hey, I think you got the same problem as me.
FYI: Value_template ERROR Invalid domain name ' ' | Blueprint for calendar based triggers
unfortunatly it looks like there is no variables usage in value_templates possible right now.
Did you find any workaround for your trigger?