Input_select options with 'friendly name' and 'payload'

I wish this was possible:

input_select:
  spotify_playlist:
    name: Spotify playlist
    options:
      - ['Todd Terje List 1','spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p']
      - ['Todd Terje List 2','spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p']
      - ['Todd Terje List 3','spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p']
      - ['Todd Terje List 4','spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p']
      - ['Todd Terje List 5','spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p']
      - ['Todd Terje List 6','spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p']
      - ['Todd Terje List 7','spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p']

where

states.input_select.spotify_playlist = ‘Todd Terje List 3’

states.input_select.spotify_playlist.attributes.payload = ‘spotify:user:tangoterje:playlist:0mXe7dAb0OAxIflEFuRO5p’

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.

3 Likes

Hi @upsert

Good suggestions!

I’ve put together an example along these lines:

I see this very useful, too.
Adding not only the friendly_name and value properties, but an ID tag, would even allow to support multi language here.

Any chance you still have those files? The links seem to be broken. I guess you removed the repos from your Github account?