Having a value associatied with a list option would be a tremendous benefit. Any automations or scripts involving input_select are very tedious and error-prone right now (see these great scripts: Chromecast Radio and Logitech Harmony). If you have your config in multiple files you have to carefully copy and past values between files and create if-then-else statement cases for every option. It is akin to an HTML <select> element not supporting a value attribute.
I could see multiple ways of adding a value to a list item. Using an array as suggest above, but that leaves it slightly ambiguous as to which will be the display and which will be the value. And what happens if they make an array > 2 long? Or perhaps, down the road the frontend will support multiple display languages?
I’m not familiar with the Python implementation, but I expect the code could notice the start of a new item (a dictionary?) and act accordingly to treat it as an item with a payload value.
Something like this perhaps:
input_select:
radio_station:
name: 'Select Radio Station:'
options:
- item:
friendly_name: Radio 538
value: http://vip-icecast.538.lw.triple-it.nl:80/RADIO538_MP3
- item:
friendly_name: Q-Music
value: http://icecast-qmusic.cdp.triple-it.nl/Qmusic_nl_live_96.mp3
Alternatively, to minimize backward compatibility headaches even further, you could add a new values entry like this:
input_select:
radio_station:
name: 'Select Radio Station:'
options:
- Radio 538
- Q-Music
values:
- http://vip-icecast.538.lw.triple-it.nl:80/RADIO538_MP3
- http://icecast-qmusic.cdp.triple-it.nl/Qmusic_nl_live_96.mp3
It is not as clean as the item approach above and requires more work to associate the positions in the lists with each other. Also more difficult to support multiple languages on the frontend.
To access the currently selected value of the input_select it could be:
{{input_select.radio_station.value}}
Or if that is not possible, as in the original post above: {{states.input_select.radio_station.attributes.value}}
Friendly name access would remain the same for backward compatibility:
{{input_select.radio_station}}
Once the value and friendly name of the input list items are together, the !include option in YAML can break out the list into its own file and make it easier to manage.
input_select:
radio_station:
name: 'Select Radio Station:'
options: !include radio_station_list.yaml
I hope this feature garners some interest and anyone who has coded a long script with many if-then-else statements should vote for it.