WTH why is template trigger limited to only False -> True?

petro · December 1, 2024, 12:23pm

Right now, template triggers will only trigger when the template itself switches from resolving False to resolving True.

Template entities update whenever the template updates, why can’t we have a trigger that does the same thing?

User87 · December 1, 2024, 12:57pm

I’m not the brightest bulb in the group, so you probably understand something deeper about HA than I. But, can you not use binary template helpers as triggers for automations? I have a few of these and use ‘not’ statements to inverse the ‘false → true’ all the time.

{% set varA = is_state('binary_sensor.xyz','off') %}
{% set varB = is_state('binary_sensor.abc','on') %}
{% set varC = is_state('binary_sensor.def','off') %}
{{ (varA or varB) and not varC }}

petro · December 1, 2024, 1:00pm

See this closed PR for reference on what type of templates this effects

github.com/home-assistant/core

Add option to trigger template triggers when the template updates

home-assistant:dev ← Petro31:value-template-trigger

opened 04:53PM - 07 Jul 24 UTC

Petro31

+91 -9

## Proposed change  Currently, template triggers only trigger when the template previously renders `false` and then renders `true`. This limits template triggers and forces users to create template entities. Adding the ability to optionally trigger off any template change opens up functionality for automations and template entities. This solves 2 commonly asked questions that haven't been possible in the past: e.g. A user would now be able to create a trigger based template sensor where there's shared templates across states and attributes. ``` template: - trigger: - platform: template value_template: "{{ states.binary_sensor | map(attribute='entity_id') | select('is_state_attr', 'device_class', 'battery') | select('is_state', 'on') | list }}" trigger_on_new_value: True sensor: - name: Binary Sensor On Entities state: "{{ trigger.value | count }}" attributes: entity_id: "{{ trigger.value }}" ``` People can trigger off entities inside a group. e.g. You can now trigger when any light is turned on (or off) in a group. In this scenario, `trigger.value` will provide the list of entities that are on. Users can discern whether or not the trigger.entity_id was turned on or off to perform specific actions. ``` trigger: - platform: template value_template: > {{ expand('light.living_room') | map(attribute='entity_id') | select('is_state', 'on') | list }} condition: - platform: template value_template: > {# Only perform the action if the triggering entity was turned on (it should be in trigger.value if it was) #} {{ trigger.entity_id in trigger.value }} action: ... ``` The options here are endless because we can utilize templates to enact any trigger. This can also be combined with `label_entities`, `device_entities`, `integration_entities`, and any other `*_entities` that I might be forgetting. The only downside to using these functions is that the template will not update if you add or remove a label, a restart of the system is required. This stipulation should be added to the documentation or a separate PR should be created to allow templates to render when the lists change. e.g. ``` trigger: - platform: template value_template: "{{ label_entities('living_room') | select('is_state', 'on') | list }}" ``` ## Type of change  - [ ] Dependency upgrade - [ ] Bugfix (non-breaking change which fixes an issue) - [ ] New integration (thank you!) - [x] New feature (which adds functionality to an existing integration) - [ ] Deprecation (breaking change to happen in the future) - [ ] Breaking change (fix/feature causing existing functionality to break) - [ ] Code quality improvements to existing code or addition of tests ## Additional information  - This PR fixes or closes issue: fixes # - This PR is related to issue: - Link to documentation pull request: https://github.com/home-assistant/home-assistant.io/pull/33614 ## Checklist  - [x] The code change is tested and works locally. - [x] Local tests pass. **Your PR cannot be merged unless tests pass** - [x] There is no commented out code in this PR. - [x] I have followed the [development checklist][dev-checklist] - [x] I have followed the [perfect PR recommendations][perfect-pr] - [x] The code has been formatted using Ruff (`ruff format homeassistant tests`) - [x] Tests have been added to verify that the new code works. If user exposed functionality or configuration variables are added/changed: - [x] Documentation added/updated for [www.home-assistant.io][docs-repository] If the code communicates with devices, web services, or third-party tools: - [ ] The [manifest file][manifest-docs] has all fields filled out correctly. Updated and included derived files by running: `python3 -m script.hassfest`. - [ ] New or updated dependencies have been added to `requirements_all.txt`. Updated by running `python3 -m script.gen_requirements_all`. - [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.  To help with the load of incoming pull requests: - [ ] I have reviewed two other [open pull requests][prs] in this repository. [prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure  [dev-checklist]: https://developers.home-assistant.io/docs/development_checklist/ [manifest-docs]: https://developers.home-assistant.io/docs/creating_integration_manifest/ [quality-scale]: https://developers.home-assistant.io/docs/integration_quality_scale_index/ [docs-repository]: https://github.com/home-assistant/home-assistant.io [perfect-pr]: https://developers.home-assistant.io/docs/review-process/#creating-the-perfect-pr

User87 · December 1, 2024, 1:10pm

Got it! So you’re looking for non-binary changes to a template.