core icon indicating copy to clipboard operation
core copied to clipboard

Use device name for matter entities

Open piitaya opened this issue 1 year ago • 4 comments

Proposed change

Use device name for matter entities. The translation key will only be used if a suffix is added to the entity name. It will avoid have entity id and entity name suffixed with the domain. (eg. light.bedside_lamp_light will become light.bedside_lamp)

As you can see in the following example, the logic will only be changed when the device have primary attribute on multiple endpoints. A translation key is added to have Switch (1) instead of weird name like (1).

Examples:

1. A regular lamp (one light entity)

Device name : Bedside lamp

Before

Entity ID Entity name Full name (device + entity name)
light.bedside_lamp_light Light Bedside lamp light

After

Entity ID Entity name Full name (device + entity name)
light.bedside_lamp None Bedside lamp

2. A power strip (two switch entity for each outlet)

Device name : Power strip

Before

Entity ID Entity name Full name (device + entity name)
light.power_strip_switch_1 Switch (1) Power strip Switch (1)
light.power_strip_switch_2 Switch (2) Power strip Switch (2)

After

Entity ID Entity name Full name (device + entity name)
light.power_strip_switch_1 Switch (1) Power strip Switch (1)
light.power_strip_switch_2 Switch (2) Power strip Switch (2)

Type of change

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

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:

Checklist

  • [x] The code change is tested and works locally.
  • [x] Local tests pass. Your PR cannot be merged unless tests pass
  • [x] There is no commented out code in this PR.
  • [x] I have followed the development checklist
  • [x] I have followed the perfect PR recommendations
  • [x] The code has been formatted using Ruff (ruff format homeassistant tests)
  • [ ] Tests have been added to verify that the new code works.

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

If the code communicates with devices, web services, or third-party tools:

  • [ ] The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • [ ] New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

piitaya avatar Oct 07 '24 10:10 piitaya

Hey there @home-assistant/matter, mind taking a look at this pull request as it has been labeled with an integration (matter) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of matter can trigger bot actions by commenting:

  • @home-assistant close Closes the pull request.
  • @home-assistant rename Awesome new title Renames the pull request.
  • @home-assistant reopen Reopen the pull request.
  • @home-assistant unassign matter Removes the current integration label and assignees on the pull request, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

home-assistant[bot] avatar Oct 07 '24 10:10 home-assistant[bot]

Are we going to change this for ZHA and Z-Wave as well ? I'm a fan of this change but we should do it consistently

marcelveldt avatar Oct 07 '24 16:10 marcelveldt

It's only a proposal for now. I did that this week end because I was bored to have "light" or "lock" at the end of all my entities 😅 I'm not sure how zha and zwave handle entity naming. I think zha adds "switch" at the end of all switch entities so it can work too. But I'm not sure the implementation can be duplicated easily.

I will add some description to the PR to explain what it does with examples.

piitaya avatar Oct 07 '24 16:10 piitaya

Are we going to change this for ZHA and Z-Wave as well ? I'm a fan of this change but we should do it consistently

We should implement things correctly, and not because two other open standards use it. If this PR is matching our modern approach, we should prefer that, as that will be the consistent path forward across all integrations (and not just the ones you mentioned).

frenck avatar Oct 07 '24 18:10 frenck

We should implement things correctly, and not because two other open standards use it. If this PR is matching our modern approach, we should prefer that, as that will be the consistent path forward across all integrations (and not just the ones you mentioned).

Sure, but this should be AT LEAST universal between all open protocols imo. Even better: consistent across ALL integrations. Currently, my observation is that most often the type (e.g. light, lock etc) gets added to the name. Hence my question if we are going to adjust this consistently everywhere

marcelveldt avatar Oct 16 '24 10:10 marcelveldt

It's only a proposal for now. I did that this week end because I was bored to have "light" or "lock" at the end of all my entities

Yeah, you are totally right. I am annoyed by that as well. Yet my point from above remains, this is the case with MANY integrations (I specifically looked at zigbee and z-wave but there will be others) - shall we adjust this everywhere then ?

marcelveldt avatar Oct 16 '24 10:10 marcelveldt

Sure, but this should be AT LEAST universal between all open protocols imo. Even better: consistent across ALL integrations.

This is transitional, that feature is newer. Everything takes time. There is no need to sync or block it up between other integration at all.

frenck avatar Oct 16 '24 10:10 frenck

This is transitional, that feature is newer. Everything takes time. There is no need to sync or block it up between other integration at all.

All clear so reading between the line I can see that we are a fan of this change and aiming to bring it to the other integrations as well (so it will be consistent/predictable again between integrations).

marcelveldt avatar Oct 16 '24 11:10 marcelveldt

aiming to bring it to the other integrations

When I migrated a lot of integrations to has entity name, I think I did check for that. I did not do bigger integrations like zwave or zha, so no clue how that works there. But I think we do quite a good job on naming now!

joostlek avatar Oct 25 '24 16:10 joostlek