Splitting up the template integration with Event based binary_sensors

First, thanks to Taras for suggesting this - I have a number of kludge-y work arounds that use events with input_booleans that isn’t real satisfying (most all based on the Hue 4-button switch).

With the new template: integration, I can see where I can have an event trigger that can then be used to turn the binary_sensor on and then off with the auto_off: attribute. But like @Mariusthvdb, I’m now trying to figure this out in a larger sense. I have separate sub-directories that each contain files for a specific integration: one for binary_sensors, one for sensors, one for input_numbers, etc. HA knows where they are because I’m using includes, such as:

binary_sensor: !include_dir_merge_list config-include-files/binary-sensors/

I can’t find anywhere if I can do something similar with the template integration. For example, can I do this:

tempate: !include_dir_merge_list config-include-files/templates/

Or will this work with my current file structure (but then I could have template integrations scattered throughout the files - and I don’t think that will work (the last one read at startup or reload would be the one that HA uses?). My question is, what’s the right way to structure this so that I can keep some sort of structure to the binary_sensors and sensors? If it goes in configuration.yaml, then that could become a bit chaotic with the number of templates we all evolve to.

EDIT: After experimenting a bit, I found this has to go in configuration.yaml, at least as far as I can tell. I tried including it in the binary_sensor include directory, restarting, but that didn’t work (no errors, either). I then added the following code into configuration.yaml:

template:
  - trigger: 
      platform: event
      event_type: hue_event
      event_data:
        id: master_bedroom_switch
    binary_sensor:
      - name: Test EVENT
        auto_off: 5
        state: >
          {{ trigger.event.data.event == 4002 }}

This worked as advertised (BTW, for those not familiar with the Hue 4-button dimmer switch, the data 4002 is simply the code that indicates the 4rth button was short-pressed and released). But I’m not sure this is what @123 was asking for - but I’m not sure it’s not, either. I’d much rather have something like the following that would go under the binary_sensor key:

binary_sensor:
  - platform: event
    event_type: hue_event
    event_data:
      id: master_bedroom_switch
    name: Test EVENT
    auto_off: 5
    state: "{{ trigger.event.data.event == 4002 }}"

Then, as @Mariusthvdb wrote and I think @123 intended, it could simply be added to an existing binary_sensor include file - but now we’re back to asking for the event platform in a binary_sensor template, which is what @123 first proposed…

The template integration is an awesome addition, and I certainly appreciate the effort. It would be super awesome if it could go under the binary_sensor key.

I looked at the code for the template integration, binary_sensor.py. There’s a function at line 105 with the name: rewrite_legacy_to_modern_conf. I’m quickly getting out of my element, but it appears to take the existing binary_sensors and rewrite them into this new template integration (I could be way off-base here…). It seems if that can be done, then we can also have the ‘template’ integration under the legacy binary_sensor key.

Thoughts on how to implement this? The main ask is not really a template (we already have that), but an event or trigger in the binary_sensor (legacy) template.

EDIT: Oof - it’s line 105…

The new template sensors can be split up like any other existing items

In my configuration.yaml I have this

template: !include_dir_merge_list template_sensors

I have created a directory called template_sensors

And inside this I have two .yaml files. One for binary template sensors and one for normal sensors

This is the beginning of my sensor file

- sensor:
   
  - name: Test Sensor
    unique_id: test_sensor
    unit_of_measurement: "Bananas"
    state: >
      {{ states('input_number.test_number') }}

and then the first two sensors in binary sensors

- binary_sensor:
  - name: Night Time
    unique_id: night_time
    state: >
      {{ not '06:30' <= as_timestamp(now()) | timestamp_custom('%H:%M') <= '23:00' }}
   
  - name: "Darkness"
    unique_id: darkness_template_sensor
    state: >
      {{ is_state('sun.sun', 'below_horizon') }}

Hope this is useful

1 Like

Thanks for the feedback, @KennethLavrsen! I certainly appreciate the insight on how you manage/organize these - you’ve given me the info I needed to start using these a bit more aggressively. I currently have several yaml files for binary sensors and sensors (as well as input numbers, etc) positioned in their own subdirectories. With this info from you, it seems I can use a very similar org structure using templates - they all just have to be under the include directory, which is fine with me.

Again, thanks for the feedback!

They still can’t be included in packages tho, correct?

Good question - I don’t know the answer to that one. Maybe someone else will know (?) or have tried it. But looking at the docs, you can include other sensor integrations with a template platform, so I don’t immediately see why you can’t include the template integration in a package. I don’t have anything setup at the moment to try… maybe this weekend.

No, they can’t be packaged

Thanks, @petro - saved me some weekend time.