Friendly name for input_select options

Feature Requests
21

Actually, that’s how the input_select works now. The input_select’s options are the so-called “friendly_names”; they are the ones exposed to the UI. However, they also happen to be the same names supplied to automations which isn’t always desirable (as you’ve pointed out).

We both have the same goal, show one thing in the UI but provide something else for automations, but we’re using different terminology to describe the same things. :slight_smile:

- Low, 35
  ^    ^
  |    |
  |    For automations (optional)
  |
  For the UI
22

I didn’t get your point originally, as your example in your request was looking quite different to what you’ve posted here. But yes, If you update your request and it isn’t a breaking change the way you describe it, I’ll close mine and vote for yours.

23

That way it would be a breaking change, though. You’d have to swap the two around.
Forget what I’ve said, I’m wrong…

24

It’s the same principle except it is using key-value pairs instead of a list.

Key-value:

- option: Low
  value: level1

List:

- Low, level1

In retrospect, key-value pairs are overly verbose so I think a list is the neater solution. I will amend my Feature Request.

Think about how input_select works now.

- Low
- Medium
- High

Each option allows for only one value. That value is used by the UI and everything else (i.e. automations).

The proposed list-based approach doesn’t change that. The first item in the list continues to be used by the UI. The difference is that automations would have access to both items in the list.

EDIT
As per our discussion, the other proposal has been updated with regards to the use of a list, as opposed to a dictionary.