Help With Template Binary Sensor Trigger of Platform Type Template

Configuration
1

I’m having a hard time understanding template sensor triggers of type template. Here is my current code:

-   unique_id: 'phone_wifi_connection_state'
-   trigger:
    -   platform: template
        value_template: >
            {{ state_attr('device_tracker.iphone_wifi_mac','ip') != state_attr('binary_sensor.phone_wifi_connection_state','ip') }}
-   binary_sensor:
    -   name: 'Phone Wifi Connection State'
        state: >
                {% if state_attr("device_tracker.iphone_wifi_mac","ip") == None %}
                    0
                {% else %}
                    1   
                {% endif %}
        attributes:
            last_update: "{{ now() }}"
            ip: "{{ state_attr('device_tracker.iphone_wifi_mac','ip') }}"

In short, router updates HA device_tracker Entity when the device joins the network (attribute ‘ip’ is present) or disconnects (attribute ‘ip’ is removed/None). Insofar as setting the State, this works as expected.

For the attributes, I added the ‘ip’ only to make the True/False logic of the template trigger easier (if there is a better way to T/F the presence of an attribute but which can also detect a change in IP, please let me know).

The issue is around the ‘last_update’ attribute, which I would expect to be updated only when the template trigger equates to True. This is not the case. The device_tracker Entity is updated by the router every minute or so reflecting when the router last communicated with the device. Every time the device_tracker Entity’s attribute ‘last_time_reachable’ is updated, so is the template sensor’s ‘last_update’ attribute, despite the template trigger equating to False.

So it appears that I have either incorrectly understood the binary fashion of a template trigger, or the sensor is being evaluated/updated whenever the reference device_tracker Entity updates, regardless of trigger state.

Any help would be appreciated.

2

You have a lot of list delimiters (-) where you should not. It should look something like this:

template:
  - unique_id: 'phone_wifi_connection_state'
    trigger:
      - platform: template
        value_template: >
          {{ state_attr('device_tracker.iphone_wifi_mac','ip') != state_attr('binary_sensor.phone_wifi_connection_state','ip') }}
    binary_sensor:
      - name: 'Phone Wifi Connection State'
        state: >
          {% if state_attr("device_tracker.iphone_wifi_mac","ip") == None %}
              0
          {% else %}
              1   
          {% endif %}
        attributes:
            last_update: "{{ now() }}"
            ip: "{{ state_attr('device_tracker.iphone_wifi_mac','ip') }}"

I haven’t looked at your template logic.

3

I may be missing something. With the original code snippet, the Developer Tools States tool correctly resolves the unique id, shows the correct friendly name, shows the correct State, and under State Attributes includes the friendly name, last update, and ip as expected.

When I remove the delimiters from “trigger” and “binary_sensor” as you indicate, States tool continues to resolve the unique id, shows the correct friendly name, but the state becomes unknown and all attributes except for friendly name are gone.

4

As I said:

I just fixed your syntax, which was far from correct. Look at the examples here:

https://www.home-assistant.io/integrations/template/#trigger-based-template-binary-sensors-buttons-numbers-selects-and-sensors

Also the template editor knows nothing about correct yaml syntax. It just resolves templates. You could write this in the template editor and it wouldn’t complain:


absolutely_gibberish: something
 - whaterver_n_ever: "{{ 'splendid' if true else 'buggernuts' }}"
5

I appreciate your patience. I am also not using the template editor.

Does it make a difference that the code is in an include file and not in the configuration.yaml? I can remove the delimiter from “trigger” and have it not break, but removing from “binary_sensor” does break it. If I format as specified in the link you sent, which is the page I’ve been using, it doesn’t work when I include the trigger section.

6

I have triple read the Template page, slogged thru the inconsistent use of delimiter formatting in the (non-legacy) examples and stripped an example to the below. This sample is the only thing in an include file - and it doesn’t work:

configuration.yaml

template: !include_dir_merge_list sensors/template/

sample.yaml (within the /template/ directory)

- trigger:
  - platform: template
    value_template: >-
        {{ 0 == 0 }}
        
    binary_sensor:
      - name: 'Sample Sensor with Trigger'
        state: 1

Developer Tools\YAML\Check Configuration - and it throws an error

Logger: homeassistant.config
Source: config.py:454
First occurred: 12:23:35 (1 occurrences)
Last logged: 12:23:35

Invalid config for [template]: [binary_sensor] is an invalid option for [template]. Check: template->binary_sensor. (See ?, line ?).

If I chuck out the entire “platform” section, and just delimitate “binary_sensor” - it work as expected.

So is there an issue with using the template in this manner for the trigger? I don’t see any example of using the value_template example except under the legacy configuration format, so possibly not supported?

7

I adjusted the yaml in the top post. Pretty sure you just need to do this:

-   trigger:
    -   platform: template
        value_template: >
            {{ state_attr('device_tracker.iphone_wifi_mac','ip') != state_attr('binary_sensor.phone_wifi_connection_state','ip') }}
    binary_sensor:
    -   name: 'Phone Wifi Connection State'
        unique_id: phone_wifi_connection_state
        state: >
                {% if state_attr("device_tracker.iphone_wifi_mac","ip") == None %}
                    0
                {% else %}
                    1   
                {% endif %}
        attributes:
            last_update: "{{ now() }}"
            ip: "{{ state_attr('device_tracker.iphone_wifi_mac','ip') }}"

Remember that unique id is specific to each sensor, like name. Also trigger and binary sensor are fields in one list item, not separately. Its that way because you can define one trigger and use it to set the state of multiple sensors, binary sensors, selects, etc.

8

Thank you for the markup - that does seem to be in line with what is supposed to be happening (despite the inconsistencies in the documentation) not that I’ve read a ton more :slight_smile: . The post I did right before yours also has this formatting, but I’ve included the error that is generated - almost like the compiler doesn’t know where the value_template block ends. That explains why I was seeing the sensors work when I had them incorrectly in different lists.

I was using unique_id in both places as my understanding of the documentation was that if you have a unique_id at the start, then different ones for each sensor, you wind up with the one at the top being annexed to the specific sensor’s id (e.g., top is “_my_sensor”, one sensor is “this_is” and the resultant would be “this_is_my_sensor”). Is that maybe not the correct case/proper usage? (I also have 4 like-sensors coded withing the file, so was looking for a more consistent naming).

9

You mean this one?

The compiler is right to error there. Look at the tabbing, the binary sensor field is part of the template trigger. That’s invalid, no trigger has a binary sensor field. Binary sensor needs to be a sibling of trigger, not a sibling of platform and value_template. You indented it one level too far.

You’re right. I’m sorry I was unaware of this. I refactored to the new format when it first came out and this “unique id prefix” option didn’t exist then. At least I don’t think so, maybe I overlooked it.

Just to clarify though, unique_id sets the id of the entity in the registry. Its completely behind the scenes. It is not used to set the entity_id you actually see in the front end. The entity id will be generated by “slugifying” whatever you put in name and then can be changed from the front end afterwards. I usually just generate a random 16 char guid for unique_id personally since I never see or use it and just want something unique

10

Thank you - (I really hate YAML…) - I appreciate the time and help.

So moved it back a space and it became the sibling of trigger and no more error. Tossed in a unique_id on the sensor itself and that got picked up as well. Throw in an attributes block to expand on the sample, check it, then reload the template entities - no errors thrown.

- trigger:
  - platform: template
    value_template: >-
        {{ 0 == 0 }}
  binary_sensor:
   - name: 'Sample Sensor with Trigger'
     unique_id: "sample_sensor_with_trigger"
     state: "true"
     attributes:
        last_update: "{{ now() }}"

Still at this stage I don’t see what I would expect. Sensor is present in the list of current entities, but shows a state of unknown, and no attributes. I read somewhere about the sensor launching with unknown if the value_template couldn’t resolve data from an entity on load (suggested using an is_state() function), but as this is a pretty binary evaluation so I wouldn’t expect it to be unresolvable. I’ve also swapped in {{ states('sun.sun') == 'above_horizon' }} just for fun, but that didn’t resolve it either.

11

So the way trigger template sensors works is this, copying relevant section from docs:

Whenever the trigger fires, all related entities will re-render and it will have access to the trigger data in the templates.

Trigger-based entities do not automatically update when states referenced in the templates change. This functionality can be added back by defining a state trigger for each entity that you want to trigger updates.

So reading your config it’s just not going to work right now. You used a template trigger, here’s how those work as a reminder:

Template triggers work by evaluating a template when any of the recognized entities change state. The trigger will fire if the state change caused the template to render ‘true’ (a non-zero number or any of the strings true, yes, on, enable) when it was previously ‘false’ (anything else).

{{ 0 == 0 }} is always true. Its never going to be false so it can never transition from false to true. Which is what is required for a template trigger to fire. Which means it’s never going to evaluate the state or attribute templates you made and the state of that sensor will always be unknown.

Another thing to clarify perhaps, trigger type template sensors are not automatically evaluated on startup of ha like the non-trigger variant. They are initialized to state unknown and only become something else when the trigger occurs.

If you want your state template to be evaluated on started you have to add a home assistant start trigger to tell it that. I would also recommend adding a trigger for the template reload event that fires when you reload template entities from the UI otherwise it won’t evaluate then either.

Trigger template entities give you full control over exactly when their state is set. This is a blessing and a curse. Its good because it works exactly the way you need it too. Its bad because it’s all on you to remember all the times it needs to evaluate and add triggers.

12

Again - thank you. Getting clarification on exactly which delimiters and where, what had to be a sibling to what, and that very clear “how and when” template triggers fire - resolved all my original script issues and now things are running as expected. Have a great rest of your weekend!

1 Like