I’m sorry but I need some clarity about this. I created the following sensor:
template:
- sensor:
name: "Day after tomorrow"
unique_id: day_after_tomorrow_formatted
So I thought the entity ID will become “sensor.day_after_tomorrow_formatted” like mentioned in the yaml.
but it got the entity ID: sensor.day_after_tomorrow
and the name: day after tomorrow
The unique ID gives you the means to alter the sensor in the UI, meaning that by giving it one you can edit the entity in the UI and change the entity ID to whatever you like, as it will default to the name you chose. Because you do have a unique ID it will know to always set up as the new entity ID you provide.
For me, I always create my template entities in the Studio Code Server where there’s a handy right-click context menu that lets you set a UUID for that value, always ensuring you never (or highly unlikely to) duplicate any entities unique ID in your system. I used to name them like you did and it has bitten me a couple of times.
The documentation for an MQTT Sensor’s unique_id does not mention that it will use it, instead of name, to create the entity’s entity_id. It’s an identifier that’s used internally to distinguish one entity from another (like a serial number).
Compare that to object_id which does mention it supercedes name when creating the entity’s entity_id.
EDIT
I used the wrong integration (MQTT) and should have used the Template integration. Nonetheless, the inclusion of unique_id doesn’t supersede name for creating the entity’s entity_id.
Yeah that’s my mistake; I was speed-running through several posts and used the wrong integration to answer your post.
Nevertheless, the rule remains the same for the Template integration. unique_id is used internally to distinguish one entity from another. It’s not used to automatically generate the entity’s entity_id (nor does the documentation mention that it does) … unless you omit name entirely; see Petro’s post below for more details.
Unlike an MQTT Sensor, a Template Sensor doesn’t support an object_id option so name is the sole control you have over the entity’s entity_id.
The legacy method of configuring a Template Sensor allowed you to specify the friendly_name and entity_id separately. The modern method does not; the name option serves to produce both the friendly_name and entity_id.
The entity_id will be slugified based on the name, if a name is not provided, it uses the unique_id (for the template integration its template + unique_id). If neither are provided, you get a default one.
That’s correct and you can optionally change the entity’s name and entity_id via the UI after it has been created.
Keep in mind that if you omit name and only supply unique_id, the resulting entity_id will be the string template_ followed by the value of unique_id (with any spaces and hyphens replaced by underscores).
In other words, the entity_id produced by the following configuration would be sensor.template_day_after_tomorrow_formatted.