Add mA to SensorDeviceClass.CURRENT units

[SukramJ]

Proposed change

Add mA to SensorDeviceClass.CURRENT unit assignement.
This one was missing in #84366

Fixes: ... is using native unit of measurement 'mA' which is not a valid unit for the device class ('current') it is using; Please update your configuration if your entity is manually configured, ...

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 native unit of measurement 'mA' is not a valid unit for the device class ('current') #84718
• This PR is related to issue:
• Link to dev documentation pull request: Add mA to SensorDeviceClass.CURRENT developers.home-assistant#1593
• Link to documentation pull request: Add mA to Sensor/NumberDeviceClass.CURRENT units home-assistant.io#25408
• Frontend PR: Add support for unit conversion of electric current frontend#14916

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
• The code has been formatted using Black (black --fast 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 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.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

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

Code owner commands

Code owners of sensor can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Change the title of the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign sensor Removes the current integration label and assignees on the issue, add the integration domain after the command.

[epenet]

Please ensure that:

• you update the NumberDeviceClass docstring accordingly
• the documentation is updated for both number and sensor platforms
• both the public and the developer documentation are updated.

[SukramJ]

• you update the NumberDeviceClass docstring accordingly
• the documentation is updated for both number and sensor platforms
• both the public and the developer documentation are updated.

Done

[epenet]

NumberDeviceClass docstring hasn't yet been adjusted

[SukramJ]

Sorry, missing push.

[epenet]

LGTM

[frenck]

This one was not missing; it was never supported, to begin with?

The developer documentation always has been clear about that (which is evident since this PR also adjusts those).

Should this be approved architecturally first? I'm not sure why they weren't supported; there might be reasoning for that.

../Frenck

[SukramJ]

mA is already in use by wled, tuya, homematic, issy994 and custom_components.
What would be your proposal? Convert mA to A? With how many decimal places?

[frenck]

mA is already in use by wled, tuya, homematic, issy994 and custom_components.

Which thus is incorrect according to our current developer documentation.

What would be your proposal?

As per last comment:

Should this be approved architecturally first? I'm not sure why they weren't supported; there might be reasoning for that.

[SukramJ]

I home that discussion helps.

[epenet]

Side note, based on latest comments: Tuya currently implements a conversion function.

core/homeassistant/components/tuya/const.py

Lines 427 to 433 in a701630

	UnitOfMeasurement(
	unit=UnitOfElectricCurrent.MILLIAMPERE,
	aliases={"ma", "milliampere"},
	device_classes={SensorDeviceClass.CURRENT},
	conversion_unit=UnitOfElectricCurrent.AMPERE,
	conversion_fn=lambda x: x / 1000,
	),

[epenet]

Note: there is a conflict from recently added data_size/data_rate converters.

[SukramJ]

Please have a look at the linked frontend PR.
Question regarding the used key: Is it the UNIT_CLASS of the converter?

[epenet]

Please have a look at the linked frontend PR. Question regarding the used key: Is it the UNIT_CLASS of the converter?

Frontend is based on the device class.
I'd need to check the code to remember where UNIT_CLASS is used.

[SukramJ]

Thanks, i fixed the frontend PR.

Stale

[frenck]

Rebased the PR to deal with a merge conflict

[MartinHjelmare]

There's still a conflict it seems.

[frenck]

It is a new conflict caused by the merge of the mV PR, will pick it up.

Edit: Rebased again.