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:

2 Likes

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.

is this already implemented now?

The answer is in the documentation for Input Select.

(No.)

But there were indications in the 2022 WTH month that this is coming.

1 Like

I could use that really well. Like for example for a list of ip adresses, where the friendly name is the name of the device and the value the ip.

1 Like

I have numerous instances of both things mentioned. I can see some issues with the second one (template-based population). What I have done in the past is I create an input_select with only one option and then use an automation at start that populates those options.

The downside you have to consider is what happens if you have an automation that triggers when the value changes.

Take for example my TV remotes. I designed them with input_select’s that allow quick access to all the frequent apps (HDMI-1/DirectTV, Netflix, Hulu, etc.) and that list is by TV. Kids TVs have some, other TVs different lists. To save space I added “Power off” as one of them. I create an input_select and there is a JSON file with all the TVs information including this list (and many other things). There is only oine option in the input_select which is “Power off” as it is common among all TVs. The whole remote is populated including the input_select when HA starts.

And there is the issue. At start, the list gets “rebuilt” and the “Power off” option is first. BOOM. All TVs turn off as it fires the automation that the input_select value changed. I am not sure there is a fix to this, I do not see how you could build an input_select dynamically without causing this to happen.

Did anyone figure out a workaround for this or are we still hoping for the feature to be implemented 4 years later? I do have a workaround but it is limited to MQTT.
Would also be great to have the option to always reset to the first option or some type of “please select:” default upon selection. This would ensure it is possible to select the same option multiple times.
Fingers crossed this will make it for an upcoming release.
cheers,

They’re not an exact answer to the original request, but have you looked at Template selects?

1 Like

I’m also looking for a table, or even better somthing like an array, to store values.

My actual usecase would be the target-pressure for the tires of my car. By now I have for each target-value one input_number-helper and select the right one in dependance of an input_boolean-helper / input_select-helper. For example:

  • targetpressure-winter-front-lowload,
  • targetpressure-winter-front-highload,
  • targetpressure-winter-rear-lowload,
  • targetpressure-winter-rear-highload
  • etc.

That’s in my case 8 number-helper (summer / winter, front / rear, lowload / highload), which makes it really confusing.
If there where an array, I could store it (in pseudo-code):

- targetpressure[winter][front][lowload]
  .value = 2.6 
  .unit_of_measurement = bar
- targetpressure[winter][front][highload] 
  .value = 3.0 
  .unit_of_measurement = bar

unit_of_measurement is not really needed, but would be a goody. Storing pure value would help already. If you cold use the array-member (ie. winter / summer) to fill an input_selector would be also quite nice.

There are a lot more usecases, to store values in an array. For example

  • target-temperature of a room, depending on
    • summer / winter,
    • day-of-week,
    • workingday / weekend / vacation
    • user present / away
  • turn on heater/target-temperature of aircondition, depending on
    • actual temperature
    • forecast temperature
    • day / night
    • user present / away
    • power of PV-system

The HA-community will find many more usecases.

Example:
I would like to set inverter discharge power based on the state of charge of the battery. I’m searching easy way to maintain a 2 dimensions table like:

SOC | Power
45% | 1000W
60% | 2000W
etc

In a helper, that would be great.

Vote +1

2 Likes

Added a link from 2024 WTH

1 Like

When searching for instructions on how to use a button to cycle through scenes, I always skipped the complex looking solutions and 18 minute long YouTube videos thinking it can’t be that hard, surely? Turns out it is! And it has been for a long time too. If input_select could support key value pairs, it would remove mapping code, avoid bugs and make life so much easier for new-comers to Home Assistant.

Attached below are just a few discussions I found on this subject, many feature requests and even Home Assistant documentation that suggests hard coded mappers from dropdown values. Imagine how simple these solutions in the docs would be with labels and values supported in the input_select. Is it super complicated to fix under the hood?

This feature isn’t wanted, it’s needed! Please!!! :pray:

Discussions:
2018 - Input_select with value and label?
2019 - Map values for an input_select?
2021 - Input_select and input_number display value vs actual value
2021 - Input select labem / value pairs?

Duplicate feature requests:
2022 Add both name and value for the input_select integration options
2022 WTH can't input_select have label and key in options?
2022 Select helper with label and values

Suggested solutions that would be so much simpler:
2018 source being copied still in 2023 - Cycle through scenes with a button? Home assistant - cycle scenes with a single button | tamarisk.it
Home assistant docs: Perform actions based on input select - Home Assistant 中文网

Interesting tid bit, when dropdowns were added to the HTML v2 spec in 1995, they also supported key value pairs.

@123, do you think the title of this feature request is clear enough as to what you are requesting? As a software developer, I might not understand mapper without more context. Could the title be “input_select enhancement - add value to options to simplify mapping” please?

I love this idea! How about the dictionary use a JSON object data structure to make it more useful (and complex)? This way you could specify more than just the option and value pairs by adding custom JSON-format data. To provide some backward compatibility the ‘option’ attribute (if in the JSON) would function like the current list select does, and the additional JSON attributes would be available for use in scripts and automations (and could be used by standard JSON functions).

???

e.g.

{
  "options": [
    {
      "option": "Kitchen",
      "value": "20",
      "set_temp": 25,
      "disable_motion_sensor": true
      "entity_id": "motion_bedroom_1"
    },
    {
      "option": "Garage",
      "value": "10",
      "set_temp": 10,
      "set_alarm": true
    },
    {
      "option": "Bedroom",
      "value": "22",
      "set_temp": 25
    },
    {
      "option": "Office",
      "value": "23",
      "set_temp": 25,
      "set_timeout": 5
    }
  ]
}