Hide the entity ID for people who don't need it

[matthiasdebaat]

Many people build their home through the UI and never need the entity ID. It is an address for people who type, for example: YAML files, templates, scripts, developer tools. If you only point at entities in the UI, it is noise.

I want to hide the entity ID for these people, without breaking it for the people who rely on it. The question is how we decide who sees it.

The pain point

Today the only control is a profile setting, Display entity IDs in picker, which shows the full entity ID when you select an entity. It sits deep in the profile, where the people who would benefit from it never look. It also only covers the picker, while the entity ID keeps leaking in elsewhere: when a new entity is created, in more info, in errors and history, and every time someone asks the community for help and gets an answer written in entity IDs.

The entity settings dialog is a clear example. We show the entity ID right there, which urges people to think about it and to make it prettier, even when they never need it for anything.

Part of the problem is that the entity ID looks meaningful. If it was just a UUID, nobody would care about it and nobody would want to see it. Because it reads like a name, we invite people to curate it.

So we lean on one buried toggle to serve two very different users, and it serves neither well.

Going into solution mode

I would rather make this one clear choice than a set of scattered toggles.

For example, we could ask during onboarding whether you want to work with entity IDs, and set a single mode from that answer. Someone who says no gets a UI where the entity ID stays out of the way everywhere, not just in the picker. Someone who says yes keeps everything exactly as it is today. The choice stays changeable later, because people can grow into typing over time.

The rule I want to hold: the person who relies on entity IDs loses nothing. This is about a better default for the people who never asked for them, not about taking anything away.

Open questions

• Where do we make the choice? During onboarding, inferred from behaviour, or a profile setting.
• One mode that hides the entity ID everywhere, or per surface control like today.
• Where does the entity ID leak beyond the picker, so hiding it in one place is not enough?

Curious about your feedback.

[oerix]

I really like the overall proposal! In regards to the onboarding section specifically, we could tweak the framing so newcomers aren't forced to guess what specific technical settings mean.

Instead of asking users to configure individual options during setup, we could offer two clear paths:

• Express Setup (Recommended): Uses optimal defaults so beginners can get up and running in one click without friction.
• Custom Setup: A subtle secondary option for power users who want to tweak advanced settings upfront.

This gives experienced users full control right away while keeping the setup path fast and clear for new users.