Add new Number entity component

[Shulyaka]

Context

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.

Proposal

The proposal is to create new analog_switch integration.

The integration 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:

• Media player volume control
• Smart kettle temperature settings
• Camera brightness
• Setting of cover level
• rpi_gpio and arduino PWM output
• Bayesian sensor probability adjustments
• coinmarketcap events on configurable threshold
• Transmission or rtorrent download speed control
• Modbus write register representation
• Support a more continuous speed setting for a fan

Consequences

This is a new base entity that would allow those integrations that need it to represent entities in a more natural and user friendly way.

[balloob]

I approve of this idea.

Some comments:

• The name is too confusing. Maybe we just call it number ?
• Initial implementation should be super simple, MVP. So require a min, max and step and only a basic service to set the value.
• Not all your examples are valid. For example, cover level is already implemented as part of the cover entity. It should not be used to duplicate data across multiple entities. Same for fan speed. Also a user configurable threshold also is wrong, this should be done in automations that act to the events. This is not meant to be a "there is no other place, so I am just going to dump it in number" integration.
• Examples like GPIO, Modbus and other "protocol" level integrations on which people build things on top is a perfect use case for this.

[Shulyaka]

Thanks a lot! Agree with the comments.

[frenck]

Yeah, I agree with the comments by balloob as well.

A lot of integrations can benefit from an input_number-a-like entity-component. I think it would help solve an often put out request, where integrations want to use the input_number at this point.