Stop Requiring template magic in triggers and conditions

Archive Month of "What the heck?!" (2020)
,
1

Ref Stop requiring magic to enable templates

Why can’t i use templates in regular triggers and conditions?

trigger: 
  - platform: state
    to: "{{ input_text.alert_state }}"
    entity_id: 'sensor.foobar'

condition:
  - condition: numeric_state
    entity_id: 'sensor.temperature'
    below: "{{ input_number.low_temperature_limit }}"

  - condition: time
    after: "{{ input_datetime.my_time }}"
2

Or more technically correct (the best kind of correct):

trigger: 
  - platform: state
    to: "{{ states('input_text.alert_state') }}"
    entity_id: 'sensor.foobar'

condition:
  - condition: numeric_state
    entity_id: 'sensor.temperature'
    below: "{{ states('input_number.low_temperature_limit') }}"

  - condition: time
    after: "{{ states('input_datetime.my_time') }}"

Though that last one could still require adjustment if it contains a date and a time.

1 Like
3

For the time condition, a follow up of https://github.com/home-assistant/core/pull/38698 is expected.

- condition: time
  after: input_datetime.my_time

(but out of scope / not an response to the rest of this WTH post)

Nevertheless, in a lot of the original examples, I can see a future where we can accept a template OR a input_* entity on those.

2 Likes
4

It would off course be even better if ‘entity_id’ could also be templated just like in node red

5

You already can do that using templates. Accepting that directly as an entity_id is technically problematic in the way Home Assistant works.

6

I like your example but why would the time require adjustment ?
It’s either after a time or not, if no date is specified its just the time component compared, else a time and date.
It should be made transparent.

1 Like
7

It’s an input_datetime. So it could be a time, which would work as written or it could be a date and time in which case the date would have to be stripped off for it to be a valid value. I’m going to ignore the case where it’s just a date. No one is that stupid, he says with trepidation.

1 Like
8

But could not the trigger (or condition) be both

at: 2020-08-26 15:00:00
or 
after: 2020-08-26 15:00:00

(at a spcific date)
or

at: 15:00:00
or
before: 15:00:00

(every day)
etc?

Maybe we even should accept a spcific date, without a year

at: *-12-24 17:00:00
action:
  ho ho ho

(But that is another PR obviously)

9

Yes, time currently only accepts hh:mm:ss or hh:mm, so if you wanted to add dates as well that would probably be another wth.

10

but the test on the ‘time’ element, first checks if the test value is greater than 86,400 (60 * 60 * 24, 1 day) if it is, treat it like a date-time, if less treat it like just a time.
A minor extra calculation and the result would bo so much more flexible.
You are right about : -

But unfortunately ‘some people’ may be that stupid - but if so - no problem, it’s just treated as 00:00 on that day as it ‘should’ be later than 1970/01/01
… remind me again what a newly created input_datetime (without time) defaults to ?
:rofl:
either way it should still evaluate correctly

11

I wish I could just do a trigger based on time and then use the input_datetime helper with a time set through the gui.

12

You can, that’s what a standard time trigger does ???
Sorry, but yes, you need to template that : -

    trigger:
      - platform: template
        value_template: "{{ states('sensor.time') == states('input_datetime.id_project_lamp_start') [0:5] }}"
13

Frenk indicates above that this will soon be possible for the after time key. And possibly others in future.

14

hopefully it also fixes the problem I have with the time “difference”. :slight_smile:

15

If you mean that these evaluations do not match your local time then you have not set your base os time correctly

16

I think this request is very similar to this one

Don’t want to just end the discussion on here but is there a way to merge these two?

1 Like