Correct way for YAML templates to refer to other template sensors (other than by entity ID)?

Configuration
1

I’m hoping to group a number of simple sensors inside a YAML package, referring to each other internally in a “fail-safe” way. Suppose I want to create two template sensors, one of which uses the value of the other:

template:
  sensor:
    - name: "Template One"
      unique_id: "template1"
      state: >
        {{ "value of Template One" }}
    - name: "Template Two"
      unique_id: "template2"
      state: >
        {{ states("sensor.template_one") ~ " plus something extra" }}
        #          ^^^^^^^^^^^^^^^^^^^ (guessed entity ID)

Is there a better way to refer to the value of sensor “Template One” without trying to guess its entity ID, which:

  1. is so dependent on the display name
  2. can be renamed in the UI and break the link between the two sensors
  3. may fail if another sensor already exists in the front end with guessing and hard-coding an entity ID (in this case, sensor.template_one)?

Or is my only hope to re-program the dependent logic directly into every sensor that uses it?

I can appreciate that this may seem like a silly example (after all, why would I knowingly cause an entity ID conflict?). My goal is to avoid an inadvertent breakage sometime in the future when entity IDs (which I don’t have full control over) might collide when I add something new to my setup.

1 Like
2

An entity is referenced by its entity_id. An entity’s entity_id can be modified.

You want a way to reference an entity via something that cannot be modified.

If there was a way to reference an entity via its unique_id then maybe that would fulfill your requirements. However, if you check the Templating documentation, there’s nothing available to do that.

1 Like
3

Any entity_id’s that are created automatically follow a set of criteria that depends on the integration that is creating it.

But those criteria don’t change (typically?) So that shouldn’t be a concern unless you change something in the config (name in this case)

And even if there was a “collision” between one integration entity_id and another the newest one would only be appended a sequential number ( _2) so the original wouldn’t change.

If you change the entity_id manually, well, that’s on you and you should know where you need to change anywhere it’s referenced.

1 Like
4

Thank you both. I was hoping there might be some way that was not yet documented, but you’ve confirmed that that’s not the case at the moment. In the meantime I’ll just need to be very careful about renaming things (remembering that this would also affect links between sensors, and not just the displayed name).

The core Home Assistant team clearly has modularity and reuse at heart with their introduction of the “package” concept, so I think the ability to reference “sibling” package entities more reliably will come eventually.