Some tweaks to usage of input_datetime and input_number in automations and scripts

After 0.115 my automations are getting so much more readable by getting rid of a lot of templates and using input,* directly instead.

But I have come across a few cases that I think it would make sense to allow for the same:

I have quite a few of these triggers:

  - platform: template
    value_template: "{{ states('sensor.fibaro_kontoret_luminance') | int <= states('input_number.lux_dusk') | int }}"

And it would be great and make a lot of sense if I could make them more readable as something like

  - platform: numeric_state
    entity_id: sensor.fibaro_kontoret_luminance
    below: input_number.lux_dusk

Next, I have discovered a race condition(!) in the conditions. There is no

condtion: time
at: ...

So this means that if I have two automations with one condition each.

Automation 1

  condition:
  - condition: time
    before: input_datetime.time_morning

and Automation 2

  condition:
  - condition: time
    after: input_datetime.time_morning

I guess that none of them would run if the automaton is triggered at exactly input_datetime.time_morning

So time-conditions that are before_or_at: <timestamp> or at_or_after: <timestamp> (OR just an at: <timestamp> so you would use a regular “or”-condition between them) would be helpful.

I believe it is planned that what started with conditions and input helpers will be expanded to triggers (only time triggers at the moment). Just a matter of time.

Don’t forget to vote for your own request.

Time triggers already works fine

- platform: time
  at: input_datetime.foobar

But not numeric_state triggers with input_number.

Come thnk of it - the perfect solutin would be that everywhere you can use a number, an input_number is accepted. So you could use an input_number directly as e.g. brightness_pct: in a “light.turn_on” etc. instead of going through a template.

1 Like

Yes that is what I said. And it is going to be expanded to other triggers.