Olen
(Olen)
August 26, 2020, 9:21am
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 }}"
tom_l
August 26, 2020, 9:26am
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
frenck
(Franck Nijhof)
August 26, 2020, 10:05am
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
Hellis81
(Hellis81)
August 26, 2020, 10:14am
4
It would off course be even better if ‘entity_id’ could also be templated just like in node red
frenck
(Franck Nijhof)
August 26, 2020, 10:16am
5
You already can do that using templates. Accepting that directly as an entity_id is technically problematic in the way Home Assistant works.
Mutt
(Muttley)
August 26, 2020, 10:44am
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
tom_l
August 26, 2020, 1:21pm
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
Olen
(Olen)
August 26, 2020, 1:34pm
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)
tom_l
August 26, 2020, 1:37pm
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.
Mutt
(Muttley)
August 26, 2020, 1:48pm
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 ?
either way it should still evaluate correctly
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.
Mutt
(Muttley)
August 26, 2020, 1:51pm
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] }}"
tom_l
August 26, 2020, 1:52pm
13
Frenk indicates above that this will soon be possible for the after time key. And possibly others in future.
hopefully it also fixes the problem I have with the time “difference”.
Mutt
(Muttley)
August 26, 2020, 1:57pm
15
If you mean that these evaluations do not match your local time then you have not set your base os time correctly
I think this request is very similar to this one
Would be great to be able to use helpers / inputs such as input_number / input_datetime / input_select etc directly in automations.
For example have input_datetime setup in Lovelace and once a time is selected it adjusts the trigger time in an automation etc.
Don’t want to just end the discussion on here but is there a way to merge these two?
1 Like