Fix check on non numeric custom sensor device classes

[jbouwh]

Proposed change

Update SensorEntity._numeric_state_expected to match SensorEntity.state

This fixes an issue a where an invalid native_unit_of_measurement setting, state_class or suggested_display_precision has priority over a valid device class which is not numeric.
If for example a sensor has a timestamp device class and a custom UOM (or "") the sensor should be treated as not numeric.

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:

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 pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign sensor Removes the current integration label and assignees on the pull request, add the integration domain after the command.

[epenet]

I am not sure I agree with this.

This fixes an issue a where an invalid native_unit_of_measurement setting, state_class or suggested_display_precision has priority over a valid device class which is not numeric.
If for example a sensor has a timestamp device class and a custom UOM (or "") the sensor should be treated as not numeric.

I think the current check is correct - you should NOT be allowed to set a custom UOM or suggested_display_precision on a timestamp sensor.

I am not sure how best to fix it - but IMO this is not the correct way.

[epenet]

Can you maybe add some tests to make it clearer?
If the issue is only on the "empty string" UOM, then maybe it is sufficient to say or self.native_unit_of_measurement not in {None, ""}

[jbouwh]

Can you maybe add some tests to make it clearer? If the issue is only on the "empty string" UOM, then maybe it is sufficient to say or self.native_unit_of_measurement not in {None, ""}

It is about the empty uom , but I think the same applies to state_class

[emontnemery]

@epenet the problem being fixed is not that the unit of measurement is the empty string. The problem being fixed is that the order of checks in SensorEntity._numeric_state_expected did not match the order of checks in SensorEntity.state which broke sensors which previously worked.

If we think it adds value to again change the order of the checks in SensorEntity.state we should do that together with introducing warnings with a clear date when they will stop working.

[emontnemery]

Looks good, but we should consider adding a test.

[epenet]

The problem being fixed is that the order of checks in SensorEntity._numeric_state_expected did not match the order of checks in SensorEntity.state

I think we should add a comment in the code to make the link explicit then.