Read to the bottom and I think I have supplied your solution -
How about looking at this in a different way. Note my example and then I reframe it into your used case at the end below. For instance I have a sensors that are actually a binary representing if there are one or more devices with a specific attribute - and then the attributes for that sensor are the sensors that currently have that attribute? I know it seems counterintuitive but it may be a way of backing into what you are looking for. Let me show you an example (and see the picture below):
In my configuration.yaml I have several sensors that show any Yolink or Shelly Sensors that are “Unkown” or “Unavailable”. I would suggest that you can have a trigger based upon the attributes of any similar sensors - for “Closed”, “Open”, “On”, “Off” etc. (or having that entity_id - see where I am going with this)?:
Note the picture and then my statement at the bottom:
template:
#
# This binary sensor not only specifies if any entities in the integration are unavailable, but also if
# there are any unavailable, it will contain an attribute that is a list of the entities that are unavailable.
#
- binary_sensor:
- name: "Any Yolink Unavailable"
state: "{{ integration_entities('yolink') | select('is_state', 'unavailable') | list | count > 0 }}"
attributes:
entity_id: "{{ integration_entities('yolink') | select('is_state', 'unavailable') | list }}"
unique_id: any_yolink_unavailable
#
# This binary sensor not only specifies if any entities in the integration are known, but also if
# there are any unknown, it will contain an attribute that is a list of the entities that are unknown.
#
- binary_sensor:
- name: "Any Yolink Unknown"
state: "{{ integration_entities('yolink') | select('is_state', 'unknown') | list | count > 0 }}"
attributes:
entity_id: "{{ integration_entities('yolink') | select('is_state', 'unknown') | list }}"
unique_id: any_yolink_unknown
#
# This binary sensor not only specifies if any entities in the integration are unavailable, but also if
# there are any unavailable, it will contain an attribute that is a list of the entities that are unavailable.
#
- binary_sensor:
- name: "Any Shelly Unavailable"
state: "{{ integration_entities('shelly') | select('is_state', 'unavailable') | list | count > 0 }}"
attributes:
entity_id: "{{ integration_entities('shelly') | select('is_state', 'unavailable') | list }}"
unique_id: any_shelly_unavailable
#
# This binary sensor not only specifies if any entities in the integration are known, but also if
# there are any unknown, it will contain an attribute that is a list of the entities that are unknown.
#
- binary_sensor:
- name: "Any Shelly Unknown"
state: "{{ integration_entities('shelly') | select('is_state', 'unknown') | list | count > 0 }}"
attributes:
entity_id: "{{ integration_entities('shelly') | select('is_state', 'unknown') | list }}"
unique_id: any_shelly_unknown
Note the one that is “true”:
So here are it’s attributes:
Alot of time I don’t care if something is unkown or unavailable, or expect it to be (such as a sensor that I cannot see because a smart plug controlling it is turned off on purpose), but this is good for checking the overall health of your system - especially if you occassionally have connectivity issues.
So for your use case - how about a sensor that represents the names of any entities which have the specific entity ID you are looking for? Then the attribute would have the name - and instead of binary it could just be text - and actually the state (text) could have the actual name to make it even easier to reference in code later - ?