Add `entity_id` to states panel in developer tools

[TheHolyRoger]

trafficstars

Proposed change

This adds the entity_id to the states panel, as when using the entity picker it only shows the entity name in this panel.

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [X] New feature (thank you!)
• [ ] Breaking change (fix/feature causing existing functionality to break)
• [ ] Code quality improvements to existing code or addition of tests

Additional information

• This PR is related to issue or discussion:
• https://community.home-assistant.io/t/2022-5-streamlining-settings/418477/95?u=theholyroger

As discussed on the forums. The alternative option would be to only use the entity_id when using the entiy picker of course, but think it's nicer to show the name there myself.

Checklist

• [X] The code change is tested and works locally.
• [X] There is no commented out code in this PR.
• [ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• [ ] Documentation added/updated for www.home-assistant.io

[pedolsky]

Really appreciated! Would bring back former workflow.

[frenck]

Why not use the copy entity_id button, that is available on each entry in the table?

[TheHolyRoger]

Why not use the copy entity_id button, that is available on each entry in the table?

This isn't for copying the entity_id, it's to display the entity_id of the selected entity in the states panel, which is currently not displayed at all if you use the entity picker/selector

[ildar170975]

@TheHolyRoger, could you clarify: may this added "entity_id" field be used to SELECT a required entity or this field is read-only and contains an ID of the already selected entity?

Actually, in any case this field will be useful. In the worst case my workflow will be:

1. Type sensor.my_favourite_sensor_xyz in the upper "entity" field.
2. This field contains a friendly_name of the selected sensor (or pseudo friendly_name like " My favourite sensor xyz").
3. The new added "entity_id" field contains the inputted name (step 1).

[TheHolyRoger]

@TheHolyRoger TheHolyRoger, could you clarify: may this added "entity_id" field be used to SELECT a required entity or this field is read-only and contains an ID of the already selected entity?

Actually, in any case this field will be useful. In the worst case my workflow will be:

1. Type sensor.my_favourite_sensor_xyz in the upper "entity" field.
2. This field contains a friendly_name of the selected sensor (or pseudo friendly_name like " My favourite sensor xyz").
3. The new added "entity_id" field contains the inputted name (step 1).

It's a read-only field to display the selected entity

[emufan]

I like this PR, but I would like to see an overall correction of this last changes, not only on dev tools state.

The displayed name is not unique, not here nor in many other areas of HA. So you don't know anymore, which entity is selected and have to double-check e.g. always yaml-more.

So in general, the should be an option (users choice) to display id and name or only name (or perhaps only entity id on top) in such fields.

[TheHolyRoger]

I like this PR, but I would like to see an overall correction of this last changes, not only on dev tools state.

The displayed name is not unique, not here nor in many other areas of HA. So you don't know anymore, which entity is selected and have to double-check e.g. always yaml-more.

So in general, the should be an option (users choice) to display id and name or only name (or perhaps only entity id on top) in such fields.

Can you give me some more examples of where you mean? The entity picker component would be one easy place to change it which is used on lots of pages, but would be great if you can show screens of other areas you mean

[emufan]

Double-check with https://github.com/home-assistant/frontend/discussions/12304 or several other examples in https://github.com/home-assistant/frontend/issues/11938

[eoura2]

Appreciate this pull request - helps with identifying entity_id of an entity quickly when reviewing automations in the yaml, especially when using dev tools to quickly search for an entity.

[zsarnett]

We can just remove the select input at the top and replace it with this field. This page should use the table for sorting the entities and then click one can fill the above.

[spacegaier]

We can just remove the select input at the top and replace it with this field. This page should use the table for sorting the entities and then click one can fill the above.

But those two options behave differently in terms of search logic. The dropdown / selector uses sequence matching (so "msonos" easily finds my Sonos media players) whereas the table requires me to input "m*sonos" to find those.

Plus the dropdown has the entity images for easy visual identification. So I personally always use the selector, never the table where is have to scroll potentially rather far to find what I am looking for (e.g. even with only two Sonos media players since they have a lot of attributes => lot of vertical space).

[zsarnett]

Yes. It will come with a cahnge of search for some. But we can update the search in the table to use the same logic

The selector has no real purpose if you can use the table as well

[spacegaier]

The selector has no real purpose if you can use the table as well

I rather disagree with that statement. It is much faster to find the entity you are looking for in the selector, since in a small list you see all potential matches whereas the table requires scrolling to find what you are looking for (plus no icons / entity images). Then once you clicked the entity in the table, you need to scroll up again to actually do something.

=> So I would consider that quite a big UX downgrade and not in line with our vision to streamline the UI 😜 this year.

[zsarnett]

We can scroll you back up automatically 😉 UX fixed

[emufan]

I rather disagree with that statement. It is much faster to find the entity you are looking for in the selector, since in a small list you see all potential matches whereas the table requires scrolling to find ...

This was/is my workflow as well. I'm using the top part of the page and only sometimes the table. And because of this I already didn't like that was hidden some versions ago. And would still like that my settings (open/close) is remembered.

[bramkragten]

If it is just for finding an entity, the quick bar would be better maybe? (press e)

[spacegaier]

If it is just for finding an entity, the quick bar would be better maybe? (press e)

No, I am still talking about finding an entity here in the context of the dev tools, so finding and then seeing and changing its state. So quick bar does not come into play here.

[github-actions[bot]]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[emufan]

Still valid anyhow. Having no entity_id but friendly twice is still not good.

[github-actions[bot]]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[emufan]

Still valid anyhow. Having no entity_id but friendly twice is still not good. But would even be better to have a general solution everywhere to distinguish, not only here.

[bramkragten]

This has been fixed in the entity picker