Template Binary sensor: make delay_on and delay_off templatable

Feature Requests
1

I would really like the template binary sensor component be able to accept templates for delay_on and delay_off.

Here is an example of what I am trying to do:-

- platform: template
  sensors:
    hallway_dark:
      entity_id: sensor.sn5_ldr
      value_template: >-
        {% if is_state('switch.hallway_lamp_2','on') %}
          {{ states('sensor.sn5_ldr') | int < states('input_number.hallway_light_threshold') | int }}
        {% else %}
          {{ states('sensor.sn5_ldr') | int < states('input_number.hallway_dark_threshold') | int }}
        {% endif %}
      delay_on:
        minutes: "{{ states('input_number.hallway_light_on_delay')|int }}"
      delay_off:
        minutes: "{{ states('input_number.hallway_light_off_delay')|int }}"

The theory being, that if a LDR has been either above or below a certain threshold for a templatable amount of time, it turns the light either on or off.

The above code fails a configuration check as delay_on and delay_off does not accept templates - it must be hardcoded.

Invalid config for [binary_sensor.template]: expected int for dictionary value @ data['sensors']['hallway_dark']['delay_off']['minutes']. Got "{{ states('input_number.hallway_light_delay')|int }}"
expected int for dictionary value @ data['sensors']['hallway_dark']['delay_on']['minutes']. Got "{{ states('input_number.hallway_light_delay')|int }}". (See ?, line ?). Please check the docs at https://home-assistant.io/components/binary_sensor.template/

I noticed that HA 0.96.x made the for: parameter in automations that use number state triggers templatable, when it had not been previously.

I was hoping the template binary sensor could be given similar treatment to the automation number state trigger to make it templatable.

2

Use an automation to turn the light on and off. Triggered by your LDR level. Triggers have a ‘for’ option, so you can include a time the LDR has to be above or below a certain level before the trigger activates.

See the examples here:

3

I did play around with doing a trigger directly, but then I would also need to work out something with the conditions of the automation which don’t support the for variable at all, let alone being templatable.

Ideally templates would be available to use for everything, but I realise that is a very broad, sweeping statement and a lot easier said than done.

4

What conditions do you need timed?

5

I am not trying to be dismissive, but I am not sure it really matters what conditions need to be timed - you can’t use templates in for: in any conditions.

I am currently trying to re-do the automations to use other mechanisms, but my previous comment still stands - Ideally templates would be available to use for everything, but I realise that is a very broad, sweeping statement and a lot easier said than done.

Being more specific, binary sensors, automation triggers, automation conditions, script conditions at a minimum … anywhere where you can specify if a state has been in a state for an amount of time.

Not sure if it has been a specific decision to allow it in some places and not others, but fact is at the moment you can’t to it everywhere, and that is less than ideal.

The documentation for condition states that it is more or less the same syntax as a trigger, but does not note that you can’t use templates in conditions. A lot of people just assume you can which is not correct.

6

I’m not sure where you got that idea, see the example here: Conditions - Home Assistant

You can specify times in sensors / binary sensors using jinja templates and any of the time sensors and the sensor’s last changed attribute.

I’m not saying you idea isn’t worthwhile, just that it can be currently done (allbeit with a little more complexity).

7

@tom_l

I am not interested in arguing semantics, but there are no templates specific to the for: parameter in any of the conditions on that page. There are examples of the for: parameter, but they are all hard-coded numbers.

Irrespective of this, I tried and got configuration errors.

8

Yeah sorry, I missed ‘template’ even though I quoted it. Doh.

9

It is terrible, to bury parameters somewhere in yaml.
It would be great to have “delay_on” and “delay_off” templatable so we can adjust the parameter in the gui through “input_number”.
This is already the case in several other places, where [time] has to be specified.

10

I looking to for this always imposible to do?

11

I need this for configurable delays to some IKEA motion sensors.

The delay_off solves the exact case, where the occupancy sensor needs to be consistently off for some time. But the time has to be a constant in the configuration :frowning:

If delay_off (and delay_on) were templateable (like trigger’s for) this would be a one-liner.

The alternative is an input_boolean, which gets updated from the IKEA sensor and automation timers to delay the copy input input_boolean.

In addition to being cumbersome, it is error-prone and it puts a sensor in the input_* domain, which it is not. It smells like a hack from a long way away :slight_smile: