Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Matter label usage #141113

Closed
wants to merge 5 commits into from
Closed

Conversation

jvmahon
Copy link
Contributor

@jvmahon jvmahon commented Mar 22, 2025

Breaking change

Proposed change

This pull request prevents unintended overwriting of Matter attribute names by an endpoint's FixedLabel or UserLabel attribute values.

For Matter devices, attribute values can set through, e.g., number entities added in the number.py schema. For example, the Onlevel, OnTransitionTime, and OffTransition time attributes of the LevelControl cluster are added through number.py. For these entities, it is desirable to always use the name set in strings.py. However, if the endpoint also has a FixedLabel or UserLabel cluster, the intended name for these attributes from string.py will be overwritten by the label with the result that multiple attributes end up having the same name (quite bad from a user interface perspective). This fix allows you to specify in the discovery schema that the FixedLabel or UserLabel label should be ignored by setting ignore_matter_label_name to True.

This fix closes out the issue I previously raised here: #133233

Tagging @marcelveldt here since he helped me add the initial number.py support - I think this is a simple solution to the problem I described, but maybe he has better ideas.

"Real World" devices that have this problem include Inovelli Fan Switch VTM36 and Inovelli's upcoming Matter Switch (VTM30) which I'm beta testing. Samples of these devices can be sent if needed.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • 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:
  • Link to developer documentation pull request:
  • Link to frontend pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations (at least I think I got this right!)
  • 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:

@home-assistant
Copy link

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.

@jvmahon
Copy link
Contributor Author

jvmahon commented Mar 22, 2025

As a further clarificaction, on the VTM30 device, this is how the attributes look without the fix:

image

As you can see, the attributes all get renamed by the FixedLabel value

After applying this fix, they now are correct and use the names in strings.py:

image

Comment on lines +118 to +120
if (
not hasattr(entity_info.entity_description, "ignore_matter_label_name")
or entity_info.entity_description.ignore_matter_label_name is False
Copy link
Contributor Author

@jvmahon jvmahon Mar 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code change are in these lines 64, and 118-120 - if the attribute ignore_matter_label_name is set to True, then don't use FixedLable or UserLable. For backward-compatibility, if the attribute isn't present, the code operates as it previously did.

The rest of the marked changes are due to the way in which github processed the addition/deletion. It looks like a lot of changes, but the remainder of code down below is what was there before - probably flagged due to additional indenting because o the added "if" statement.

@@ -11,7 +11,8 @@
from matter_server.client.models.node import MatterEndpoint

from homeassistant.const import Platform
from homeassistant.helpers.entity import EntityDescription

from .entity import MatterEntityDescription
Copy link
Contributor Author

@jvmahon jvmahon Mar 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to using MatterEntityDescription instead of EntityDescription so I could access the additional attribute ignore_matter_label_names.

@@ -83,6 +83,7 @@ def _update_from_device(self) -> None:
ha_to_native_value=lambda x: None if x == 255 else int(x),
native_step=1,
native_unit_of_measurement=None,
ignore_matter_label_name=True,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding this attribute now causes the default attribute name to be used, rather than the FixedLabel or UserLabel name.

@jvmahon
Copy link
Contributor Author

jvmahon commented Apr 1, 2025

I realized this weekend there may be another way to address this naming issue. Instead of having an explicit flag to ignore FixedLabel, as I've done here, another approach is to simply ignore "FixedLabel" for any entity type that is EntityCategory.DIAGNOSTIC or EntityCategory.CONFIG. It occurred to me that CONFIG and DIAGNOSTIC entities should not be renamed based on the label. I can redo the PR if reviewers / approvers think that is the better method to address this naming issue.

@jvmahon
Copy link
Contributor Author

jvmahon commented Apr 4, 2025

I think I have a better way of handling this, so closing for now while I investigate alternate solution.

@jvmahon jvmahon closed this Apr 4, 2025
@github-actions github-actions bot locked and limited conversation to collaborators Apr 5, 2025
@jvmahon jvmahon deleted the fix_label_usage branch April 7, 2025 12:41
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant