Input_select enhancement. Support mapping

An input_select currently allows you to specify a selection list:

input_select:
  my_selector:
    name: My Selector
    options:
    - Kitchen
    - Garage
    - Bedroom
    - Office

The options (Kitchen, Garage, Bedroom, Office) will appear as choices in the selector’s list. However there are situations where the chosen option is not the value we wish to use (in an automation).

For example, “Garage” may represent the temperature value to set for the garage. However, input_select only allows you to define “Garage” but not its associated value. The way to achieve this now is to use a map (key-value pairs) in the automation’s template.

  {% set temp_map =
     { 'Kitchen':'20',
       'Garage':'10',
       'Bedroom':'22',
       'Office':'23' } %}
  {% set state = states('input_select.my_selector') %}
  {% set temp = temp_map[state] if state in temp_map %}
     {{temp}}

Ideally, the mapping should reside with the selector. Automations can refer to the selector and use either the chosen option’s key (Kitchen) or its value (20). Here’s an example of how it would appear:

input_select:
  my_selector:
    name: My Selector
    options:
    - option: Kitchen
      value: '20'
    - option: Garage
      value: '10'
    - option: Bedroom
      value: '22'
    - option: Office
      value: '23'

For reference, this feature was discussed in this thread.


EDIT

Based on discussions in this thread, instead of using key-value pairs, which make the input_select verbose, the neater solution is a list.

input_select:
  my_selector:
    name: My Selector
    options:
    - Kitchen, 20
    - Garage, 10
    - Bedroom, 22
    - Office, 23
input_select:
  my_selector:
    name: My Selector
    options:
    - Low, level1
    - Medium, level2
    - High, level3

I was following the original thread. Great idea because I need to do something similar to pair up some input_booleans with zwave nodes.

How would this look when consuming the key value pairs? How would you know there even was option/value pairs if its a simple input_select? Perhaps HA would need a input_dictionary type?

states('input_dictionary.my_dictionary') would yield {option: "longname", value: 1}?
or what would it look like when setting the value?

Also, I apolgize if the feature requests forum isn’t the right format for me thinking out loud about it. :wink:

Iv voted +1 under the premise that the mapping would remain in the backend , while the frontend would only show the options (of the example)

I use mappings allover, and would very welcome this feature!

great idea
would love to have this

All good questions … that I’m not smart enough to answer! I guess the biggest challenge is to maintain compatibility with how input_select currently works. Unless I’m mistaken, the proposed way to define the key-value pairs isn’t backward-compatible. I converted the YAML into JSON and it produced this:

{
  "options": [
    {
      "option": "Kitchen",
      "value": "20"
    },
    {
      "option": "Garage",
      "value": "10"
    },
    {
      "option": "Bedroom",
      "value": "22"
    },
    {
      "option": "Office",
      "value": "23"
    }
  ]
}

That’s not as straightforward as the current form:

{
  "options": [
    "Kitchen",
    "Garage",
    "Bedroom",
    "Office"
  ]
}

Implementing this feature request might be a breaking change.

Unless it’s ok to introduce a new data-type to the mix. That wouldn’t break, it would just be a new feature.

1 Like

please also consider creating the possibility for value_templates:

input_select:
  my_selector:
  name: My Selector
  options:
    - option: Kitchen
      value_template: >
        {{states('sensor.kitchen_temperature')}}

+1 for this. I want to have an input select with all my speakers, and a list of buttons with playlists and stations I want to play from spotify. I click the playlist, and it plays on whichever speaker group is selected in the input select. I can do it right now with the entity id, but it looks ugly. A mapping would make this SO much better looking.