Ability to use wildcards in triggers

[hmmbob]

Describe the feature

It would be great to have wildcard support in state triggers, so one can simplify automations. The idea would be to trigger on any state change of matching entities.

I.e. Trigger on sensor.tgtg_* :

  trigger:
    - platform: state
      entity_id: sensor.tgtg_*

Use cases

The ability to create one automation/script that triggers on the state of multiple possible entities, i.e. battery_level sensors, humidity sensors, Too good to go sensors - you name it - by using a wildcard.

Current workarounds

No response

Anything else?

See also https://community.home-assistant.io/t/how-to-get-wildcard-state-triggers/471625 for a complex workaround.

[chefdeit]

I 2nd your feature request to specify multiple entities in the automation's Trigger without having to individually list them, but I think it should be implemented consistently with how multiple entities are collectively being specified in the automation's Action: by enabling Areas in Trigger same way they are in Target. So all entities or devices assigned to that/those area(s) would be included.

In almost exactly your use case, in lieu of the wildcard feature you request, I had to manually list ALL the trigger entities in the Trigger section, but at least in the Action section I used

target: area_id: "{{ area_id(trigger.entity_id) }}"

meaning "do the Action in whichever area the active trigger was in". This last bit let me massively reduce the number of redundant automations (same stuff, different room) by targeting "the trigger's area".
So I feel, the solution to the issue you rightly point out, can be by specifying the triggering condition (a type of device or state change) in an Area, specifically including "Any Area" as an option, or even "Any area, except ...". The automation's Action would then be able to use "Whatever area the trigger was" as the Target option, hopefully as a UI selectable option and not the Jinja code.

Relevant: https://github.com/orgs/home-assistant/discussions/172

The rationale for Areas based entity grouping in the trigger section rather than entity wildcards boils down to:

1. flexibility (renaming entities to cater to grouping them via wildcards one way might preclude a different naming pattern, catering to grouping them another way)
2. higher abstraction from peculiarities of a given HA instance, thus enabling greater reuse as blueprints.
3. labor. If HA had inherently clean and consistent entity naming hierarchy Instance-DeviceClass-Device-Entity whose tuples were used throughout the UI and integration in places of Areas, Floors, Tags, etc., I'd have preferred the wildcards. But it's difficult to encode all those grouping and hierarchy mesh semantics into a single, flat, user-readable entity name string, while having that string fit on the screen.

[a1studmuffin]

I don't have a specific solution to suggest, but I think it's important to highlight the spirit of the original request, which is to be able to create a single automation that will capture all entities of a certain type (battery percentage being the most obvious example), with any entities added/removed in future automatically being detected by the automation.

In my case, the main problem I'd like to solve is getting a notification if a zigbee sensor (anywhere in my house) is on low battery, without needing to track every zigbee sensor in an automation since there's a lot of them and I'm often adding/removing them.

Wildcards seem like a natural choice here to my programmer brain, but there might be a better UX solution apparent to someone more familiar with the HA framework.

[chefdeit]

Wildcards seem like a natural choice here to my programmer brain

I totally agree. But it being natural to a programmer brain, I've learned to take almost as a sign of trouble insofar as normies are concerned. The folks who have 86 Word docs called "document (1).doc" through "document (86).doc" sitting on their desktop in a bunch of random locations which they get at via "Recent Files". Point being, what trips them up, still creates friction for the rest of us, which we simply overlook due to the callouses and scar tissue we've built up.

Wildcards call for the user to carefully think about their entity naming conventions, then enforce them (sometimes against the integrations' defaults). What can be an alternative to wildcards? Assigning everything to their respective Areas, then having a trigger "this type device in any area" and action "same area as the one that'd triggered".

[a1studmuffin]

Another option might be to select all sensors with with a specific device class. That way you could say "give me all the entities of SensorDeviceClass.BATTERY or SensorDeviceClass.TEMPERATURE".

[nielsrowinbik]

While not the specific solution that was asked for in the original feature request, but we have implemented the original spirit of the request as @a1studmuffin summarised it as part of the new purpose specific triggers and conditions (currently in labs).

To be able to create a single automation that will capture all entities of a certain type (battery percentage being the most obvious example), with any entities added/removed in future automatically being detected by the automation

You can implement the specific example with the newly added battery triggers:

Combine this with the ability to target floors, areas, or labels (to go across everything in your home) and the fact that some of these triggers/conditions are multi-domain, and I'd say that we're basically there.

More information on this feature can be found in the 2026.4 release notes.

[hmmbob]

Yeah, I just unmarked this answer - the topic/feature request should still be open. As you indicate yourself as well: this is not the solution that was asked for. One of the further specifications indicated the battery use-case as an example, and yes: that's now possible - but that was not my request or suggestion.

To illustrate the misalignment:

I don't have a specific solution to suggest, but I think it's important to highlight the spirit of the original request, which is to be able to create a single automation that will capture all entities of a certain type (battery percentage being the most obvious example), with any entities added/removed in future automatically being detected by the automation.

This was not the spirit of the request. I don't want to capture all entities of a certain type, I requested it to be name-based. I can use wildcards in recorder, logbook - why not in automations?

[chefdeit]

The only requirement is for you to use these grouping mechanisms. If that's a dealbreaker, or the grouping mechanisms don't suffice, then let's talk about that.

OK let's. 500 devices, 3000 entities, let's say 20 different wildcards are used. The corresponding groupings contain up to, say, 1,000 entities in them. An integration change calls for a slightly different wildcard approach. How much work is it to alter al these groupings vs just altering a line of code containing the wildcard?

Imagine if in SQL there were no WHERE clause, and you always have to create a table to join, with labels in it, every time you had to select some rows. What would that do to database topology and success of SQL in general?

[chefdeit]

We can use templates pretty much everywhere - why not in triggers....

It could be performance reasons, such as event processing latency or memory constraints, in the context of RPi many users like to run HA on.

For all I care, if HA implements wildcards via internal labels/groupings under the covers, that's fine by me so long as those are automatically re-computed every time the wildcard or a relevant entity is added / deleted / changed.

[nielsrowinbik]

In response to @hmmbob:

I hear all kind of "UI-answers", like labels (can't assign those through YAML) or target-picker. I understand what you are saying, but that was not the request, respectfully.

You're right, the "target picker" I keep referring to is a UI element, however the output of that picker is YAML. In YAML the example I gave, I showed you that you can target labels right from YAML. To be honest, I have no idea why the decision was made to not allow label management and assignment through YAML configuration. I will try and find out. I understand it's frustrating.

When the whole "let's make HA more UI friendly" work started, it was explicitly mentioned that plain YAML work would still be possible.

We still stand by this.

It seems like more and more features are being added as UI-only. That's not a good move if you ask me. Any new UI based functionality should have YAML parity.

We are becoming more and more "UI-first", but at least within my area responsibility (which is automations, scripts, and blueprints), we are very committed to always having a YAML option there. Anything you configure in the UI in the automation editor maps to YAML and that won't change.

And when a new feature for YAML is requested, the answer is "but the UI". That doesn't resonate well with me - still respecting the work everyone is doing.

I understand and I should have more carefully read your messages and not assumed using the UI was an option.

In response to @chefdeit:

OK let's. 500 devices, 3000 entities, let's say 20 different wildcards are used. The corresponding groupings contain up to, say, 1,000 entities in them. An integration change calls for a slightly different wildcard approach. How much work is it to alter al these groupings vs just altering a line of code containing the wildcard?

This is all very hypothetical and honestly doesn't tell me a lot. What would the integration change be? Why would that call for a different wildcard approach? Forgive the amount of questions but I'm honestly just trying to understand the use case and solve the right problem here (typical PM, I know 😅).

In response to @Petro31:

For what it's worth, I attempted to add a template trigger that would solve this and core rejected it. Which is why I'm mentioning templates.

Can you elaborate on what that template trigger would look like? Perhaps you can dig up the PR if you did one back then so I can have a quick look?

[Petro31]

@nielsrowinbik there has been a need in template entities to have a single source of variables from a template:

https://community.home-assistant.io/t/support-variables-in-template-sensors/249082

Ultimately, with state based template entities, users create entities with reused template code all over the place. Not only is it painful to manage because you have to update the same code in multiple spots, it's actually worse for your system. Mainly because there's a listener for each template.

There are 2 ways to tackle this problem.

Option 1:

Allow a variables field with multiple templates to "trigger" state based template entities.

Option 2:

Create a template trigger that will trigger whenever a template updates, and pass the result of the template through the trigger object.

Option one is what everyone asks for, however it would lead to a ridiculous amount of changes and it wouldn't really solve the problem for reducing listeners. It would just apply more listeners because variable sections can have any number of templates.

This is why I'd love to add option 2. Option 2 is a very easy add, we simply create a new trigger that is a template trigger. It will trigger and pass data along. It will be a single listener producing single results.

The original pushback on the first PR was that I was modifying the existing template trigger with an additional option. Now that we have the new trigger system, I believe we can add it to this system.

Here's the original PR: home-assistant/home-assistant.io#33614

I can add the new trigger. I'm willing to write the code and it would be an easy win that solves a frequently requested feature for template entities. The only limiting factor here is the committee rejecting it.

[chefdeit]

In response to @chefdeit:

OK let's. 500 devices, 3000 entities, let's say 20 different wildcards are used. The corresponding groupings contain up to, say, 1,000 entities in them. An integration change calls for a slightly different wildcard approach. How much work is it to alter al these groupings vs just altering a line of code containing the wildcard?

This is all very hypothetical and honestly doesn't tell me a lot. What would the integration change be? Why would that call for a different wildcard approach? Forgive the amount of questions but I'm honestly just trying to understand the use case and solve the right problem here (typical PM, I know 😅).

No worries Niels @nielsrowinbik , here you are:

A client of mine has 5 daughters, and as they approach college age, one by one they move out. As they do, their bedrooms become guest bedrooms. And where there used to be none, next year there'll be a third guest bedroom, and since the good doctor & his wife are very hospitable, the guest bedrooms rarely go empty; even yours truly stayed there. Unlike the daughters, guests have a different level of supervision, and their devices' MAC addresses aren't tied to their HA ID's via the SDN integration. In fact they don't have HA ID's, unless a guest is staying for an extended period and I'm asked to make them one and to hook their phone up to the guest dashboard.

A lot of the triggers and automations in the pre-guest days were quite rigid and simply organized by rooms/floors, whereas now everything guest - from how & when you're woken up to when you're expected to be in your bed sleeping, is a lot more context-based and less schedule-based. Dr and I came up with a pretty good design (that could have used a guest wildcard) and then a PPX guest came (PPX is a hospitality term for actual vip not "bs vip", the abbreviation is from Personne Particulièrement Extraordinaire), causing a redesign.

During that process I kept thinking back on how much easier and cleaner that would have been in MySQL where I could freely select any slice or cross-section of my entity namespace. Hence my analogy of NOT having wildcards is like taking SQL and removing the WHERE clause, where to select any subset you have to create a table tagging a subset of your entities and joining that table to the query, and if your thinking changes or evolves, well, you now have to create a table tagging a different subset. Doable? Sure. But creating incredible friction to the HA admin compared to simply altering the wildcard to effect that change.

My small firm serves NYC's hospitality industry; small hotels; large restaurants; premier residences. I enjoy watching (no affiliation to that channel; I just appreciate its balanced take) things like
https://www.youtube.com/watch?v=wQ7HiiIE81E
and
https://www.youtube.com/watch?v=p0cSepRpLaQ
and
https://www.youtube.com/watch?v=cgRHKx3rlc4
...and dreaming what it would be like to have HA create and tailor/refine beautiful seamless & effortless experiences at those properties, that cradle both the owners and the guests in the true meaning of hospitality.
Will you dream with me?

Wildcards are key for agile, friction-less groupings of things. They by no means replace labels, nor are made redundant by them.

[hmmbob]

For the record (phun intended): recorder and logger settings do allow wildcards 🤷🏻