Heads up! Upcoming breaking change in the Template integration

Configuration
638

No, because webhooks and events wouldn’t trigger it. The whole point of this change was to make event based sensors, where users could use events and push that data to a sensor. The rest that @amelchio is talking about is just the icing on the cake.

Also, entity_id is long gone, bringing it up at this point doesn’t serve any purpose moving forward.

1 Like
639

correct, and thats why I contemplated:

well, that might well be and we’re fully adjusted to that now

No need to reprimand me, I was merely answering to Amelchio’s

and, I don’t agree with your statement at all. It is never a bad thing to look back to see if things couldn’t have been done better. I won’t argue for bringing back entity_id, in fact the trigger: words even a bit better.

It’s just that we were quite forcefully mouthed down some 6 months ago for mourning the demise of it, and now see it return in different cloths…

1 Like
640

It’s not returning to solve the entity_id issues that you keep bringing up. It was made allow users to create persistent event based sensors. It’s a happy coincidence that it solves the issues brought up with the removal of entity_id. Also, leveraging the trigger data allows us to reuse existing code and it lets users become instantly familiar with the new integration.

641

that’s cool. and reason I enthusiastically applauded this development. Don’t get me wrong there.

you really should relax on this somewhat, I’ve mentioned it only twice now, and merely as reference to a past discussion, not advocating bringing it back at all.

water under the bridge now, anxious to see what goodies are coming our way. Though Add trigger service to template by balloob · Pull Request #48630 · home-assistant/core · GitHub is still being discussed to a final decision.

642

I only keep mentioning it because you keep implying that these changes were meant to solve this issues highlighted with it’s removal. :wink: You need to understand that these changes will not be made to solve the issues that are highlighted, so do not expect it. If it happens, it happens and we can all go home happy.

643

It dawned on me that Trigger Templates effectively implement something I had suggested last August (for WTH) namely an “Event Binary Sensor”. Balloob was receptive to the concept and had posted a hypothetical example of the proposed beast.

The end-result appears to be more capable than what I envisioned because it not only supports event-based sensors but addresses an advanced user’s need to control the updating frequency of traditional Template Sensors. Very nice indeed!

Only thing left is to sort out the service call to manually update it. I agree that homeassistant.update_entity seems like the ideal choice but I don’t have a handle on the implementation complexities.

2 Likes
644

It’s much more than that. The flow that was developed for the new rest integration will end up making it’s way into all the template integrations. Regurgitated code will be a thing of the past. This is just the first step in that direction.

645

been a while since we met here… but since we discussed the new updating of templates own this thread most fundamentally, and dev’s asked us to post possible left over issues, I do believe I found one…

It is related to the frontend, but testing this in the dev tools template seems to bug the system. It doesnt kill it (completely), like some did before, but still, comes awfully close:

title: Hue & Trädfri batteries
card_mod:
  class: class-header-margin
entities:

  - type: custom:hui-element
    card_type: markdown
    card_mod:
      style: |
        ha-card.type-markdown {
          margin: -8px -16px;
          box-shadow: none;
        }
    content: >
      Batteries below threshold:

      {% set batteries = expand(integration_entities('Ikea Trådfri'),integration_entities('hue'))
        |rejectattr('state','in',['unavailable','unknown'])
        |selectattr('attributes.device_class','eq','battery') %}
      {%- set alert_level = states('input_number.battery_alert_level')|int(default=0) %}

      {%- for b in expand(batteries)
              if b.state|int(default=0) < alert_level %}
            {{- b.name}} in {{ area_id(b.entity_id)|title }} : {{b.state}} %
      {% endfor %}

and was even worse when using

      {% set batteries = expand(integration_entities('Ikea Trådfri'),integration_entities('hue'))
        |rejectattr('state','in',['unavailable','unknown'])
        |selectattr('attributes.device_class','eq','battery') %}
      {%- set alert_level = states('input_number.battery_alert_level')|int(default=0) %}

      {%- for b in expand(batteries)
              if b.state|int(default=0) < alert_level %}
            {{- b.name.split(' Battery')[0]}} in {{ area_id(b.entity_id)|title }} : {{b.state}} %
      {% endfor %}

when this is tested and reloaded after an edit, I can see the system swirl for some time, and, happened more than a few times now, take out the Ping integration, notifying me of all of my Hubs going offline…

now the is a bug in itself, 1 Ping sensors takes out all others (there’s an issue for that since long), but this does seem like a case for the core dev template team… :wink:

related to https://github.com/home-assistant/core/issues/60781

Hope Amelchio is still around to have a look, thanks!