Define numeric sensor range by adding min/max entity properties

[frenck]

Context

Our sensors can have all kinds of values, for example, a string value, but most often, the value of sensor values is numeric.

In the case of string values, we provide hints of the possible values by providing an enumeration of the possible values. This way, the UI/editors know what values the sensor can expect and do things like auto-complete/suggest and translations.

For numeric sensors, we have no such definition. In a way, it is a read-only version of the number entity in such cases.

Proposal

While the sensor entity is read-only, we do automate with them, in that case, the input becomes a user input as part of the condition.

To improve the experience with that, it would be helpful if the sensor provided its range, so the UI editor can provide a proper UI and validation of the user input. To achieve this, we need to add the following properties:

• native_max_value
• native_min_value
• mode
• native_step

These are all equal to the versions from the number entity component.

Additionally, the sensor can take the range into account when it gets a new native value from the device or service and provide validation for that (similar to how we test a string sensor value against the enumeration).

Revision history

2024-01-21: Added mode & native_step to the properties, to make it exactly the same experience as number entities.

[MartinHjelmare]

I definitely think native_step makes sense as it makes validating the values between max and min possible. mode can be helpful too when configuring, and I don't see a reason not to include it.

[frenck]

Added both.

[joostlek]

If I understand correctly, the mode would be used in the automation editor? Can't we use a frontend switch to make the user choose which way they want to input their value?

Are there any theories in UX in when to use what so we can use this to pick a default in 80% of the cases? I can imagine someone ever researched it and came up with a "if an input has 10 possible values (Range 1-10, step 1) (range 0-1, step 0,1) a slider is perfect, but anything higher, buttons is required".

[frenck]

In all cases (including the number entities), we automatically try to determine what to use. This logic exists and has been fine-tuned.

However, the mode is still there, as the determined/automatic decision does not make sense for the specific sensor/case/integration in all cases. So, this provides an escape hatch from that.