Use device name for matter entities
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:
- [ ] Documentation added/updated for www.home-assistant.io
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 runningpython3 -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:
- [ ] I have reviewed two other open pull requests in this repository.
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 closeCloses the pull request.@home-assistant rename Awesome new titleRenames the pull request.@home-assistant reopenReopen the pull request.@home-assistant unassign matterRemoves the current integration label and assignees on the pull request, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.
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
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.
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).
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
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 ?
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.
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).
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!