Add new number entity integration

[Shulyaka]

Breaking change

N/A

Proposed change

Add new integration for an analog switch, a new entity type that other platforms may use to get a value from user.
We already have a number of integrations that allow the user to set a certain value within a range, such as light, climate, humidifier, input_number, and media_player. However we lack the generic integration that other integrations or platforms could use for a value input, along with sensor for value output, binary_sensor for boolean output, and switch for boolean input.
This PR adds this support. It would allow to create a separate entity to control a volume for something that is not a media player (i.e. an alarm clock), or to control volume of more than 1 channel for a media player that needs it (multichannel or equalizer may be?), or to control the brightness of indicator LEDs of an air purifier device, or to set PWM level for a ZHA XBee device, all without complicated setup that involved manual input_numbers, automations, and services, or using entities that not exactly fit the actual device.
Other examples of the possible usage include:

• rpi_gpio and arduino PWM output
• Transmission or rtorrent download speed control
• Modbus write register representation
• Other "protocol" level integrations

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)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

• This PR fixes or closes issue: Fixes Add new Number entity component architecture#453
• This PR is related to issue: N/A
• Link to documentation pull request: Add Number entity support home-assistant.io#15516
• Link to developer documentation pull request: Add new number entity support developers.home-assistant#712

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.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

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

[probot-home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as its been labeled with an integration (demo) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[kukulich]

Would not be better to modify input_* integrations so inputs can be added via other integrations?

https://community.home-assistant.io/t/allow-to-connect-input-number-input-select-input-boolean-etc-to-integrations/219550

[Shulyaka]

No. I already tried that in the past. Please see home-assistant/architecture#328

[kukulich]

No. I already tried that in the past. Please see home-assistant/architecture#328

Ok :(

Btw I don't know better name but I'm not sure if analog_switch is right. It can be used for digital devices as well. And it looks it's not "switch". Yeah, the best name would be input_number 😄

[frenck]

This PR adds a new entity component.

New entity components need to be discussed using an architecture issue first. Please open an architecture issue.

[Shulyaka]

Done: home-assistant/architecture#453

[Shulyaka]

Will update the PR today according to the architecture issues comments.

[Shulyaka]

Who has the power to fix the "integration: analog_switch" label of this PR?

[Shulyaka]

Could someone re-trigger the pipeline please? I want to see it all green)

[JeffLIrion]

Could someone re-trigger the pipeline please? I want to see it all green)

You can close and re-open the pull request.

[Shulyaka]

How do I fix this mypy error? If I satisfy its requirements to define the return type for async_setup_entry and async_unload_entry as bool, it starts complaining that the functions can return Any. And I don't understand how other integrations pass this requirement...

[JeffLIrion]

How do I fix this mypy error? If I satisfy its requirements to define the return type for async_setup_entry and async_unload_entry as bool, it starts complaining that the functions can return Any. And I don't understand how other integrations pass this requirement...

Probably like this:

core/homeassistant/components/media_player/__init__.py

Line 120 in a6f47ac

# mypy: allow-untyped-defs, no-check-untyped-defs

[Shulyaka]

Probably like this:

core/homeassistant/components/media_player/__init__.py

Line 120 in a6f47ac

# mypy: allow-untyped-defs, no-check-untyped-defs

Already tried this: f1f6617

[Shulyaka]

It works! Thanks @frenck!

[frenck]

👍 Looks good.

I would like to see a second opinion before merging though.