Value_template ERROR Invalid domain name ' ' | Blueprint for calendar based triggers

Hey, first time posting :slight_smile:
I’m running into the following error for a while now. The following code snippet from my blueprint is from a trashcalendar reminder that triggers a telegrambot notification.

  time: !input time
  type: !input type
  now: '{{now()}}'
- platform: template
  value_template: "{{ as_timestamp(states[type].attributes.start_time) - as_timestamp(now)/(60*60) | int <= float(time) }}"

Unfortunately it is not triggering and sequencially throwing the following error.

What am I missing? I did not find any help to the specific error (homeassistant.exceptions.TemplateError: TemplateError: str: Invalid domain name ‘’)

Home Assistant doesn’t currently support the use of variables in a Template Trigger.

If you would like this ability to be added, please consider voting for:

1 Like

Thank you for the quick reply! are there any workarounds for this problem available?

I’m not sure the advice to “use another kind of trigger” constitutes a workaround but that’s what you will have to do.

I’ve read through some of your posts. You mentioned that it is possible to use variables in templates outside triggers. So would a repeating timed trigger with the same template as a condition work?

  time: !input time
  type: !input type
  now: '{{now()}}'

- platform: time
  at: '00:10'
- condition: template
  value_template: "{{ as_timestamp(states[type].attributes.start_time) - as_timestamp(now)/(60*60) | int <= float(time) }}"


Seems not to work.


  time: !input time
  type: !input type
  now: '{{now()}}'

- platform: time
  at: !input time

If that doesn’t work, try making a sensor or binary sensor using platform: template in your configuration and passing that as a selector into your blueprint

Also, i struggle with the intricacies of the syntax, but should:
as_timestamp(now)/(60*60) | int <= float(time)
as_timestamp(now) | int / (60*60) <= float(time)

In your blueprint, what kind of entity is selected for time?

first off thanks for your reply!

as_timestamp(now)/(60*60) | int <= float(time)

works as tested in a response which gives out the right values.

Next step I will try your concept of using the sensor as a selector.
ps. I’m very new to this type of code so I will need my time to try it out :stuck_out_tongue:

ditto :slightly_smiling_face:

1 Like
      name: Benachrichtigung X Stunden vorher
      default: 10
          min: 0
          max: 24
          unit_of_measurement: hours

Do you mean this part of the code?

So time is simply a number representing hours.

What is the selector you are using for type?

Type is from the domain “calendar” and represents a google api calendar with the upcoming events (trash bins).

      name: Kalender Typ
      default: calendar.trashes
          domain: calendar

Ok, so the attribute start_time is part of a calendar entity. Please post an example of a start_time value.

Do you want the raw value or just an example of the code needed to retrieve it?



where type stands for i.e:


example code:


The attribute’s value.

By the way, you said this works:

as_timestamp(now)/(60*60) | int <= float(time)

It surprises me to hear that it works. as_timestamp(now()) produces a Unix timestamp which is a large value, much larger than 24. Therefore it will always be larger than the value of time (even after division by 60*60).


{{ (as_timestamp(states.calendar.papier.attributes.start_time) -
    as_timestamp(now()))/(60*60) | int <= float(6) }}

gives back False. Increasing 6 to 600 gives back True.

The raw value of the attribute ist formatted like this:

2021-02-10 06:00:00

“as_timestamp()” gives out this:


as_timestamp() should give back the time in seconds since our calendar (gregorian) hast started (or at least I understood it this way). Because of this assumption I divide by 3600 to get it into hours and take the difference to compare to.

Edit: I just saw that one of my code snippets only contains the second part of the equation. My bad! Since I’m subtracting the timestamps off another, the value stays in a processable range.

That’s what I was referring to. In contrast, the complete template, containing the attribute, makes sense.

Because of the referred answer I put the focus on the switched position of the “casting” to int. Thats why I’ve shortened the snippet.