What would I need that for? I want to change the name of the options of an inpt_select variable, not of a sensor value. Sorry, but I don’t get what you want me to tell.
How doest the input select communicate with your example-fan at the moment?
I like the idea of having friendly names in input select, but I’m unsure of the reason if it still uses an automation to fire the activity (as to why You want to avoid mapping it).
It doesn’t communicate at all at the moment. It would use an automation, which would get triggered by the state of the input_select changing. and then set the fans peed of the input_select state directly instead of mapping the values around. Of course I would still need an automation, but that automation would look a lot cleaner.
I was just offering a solution to you wanting items in your input_select that differ (but are mapped to) those used to action your fan.
I’m confused by your dilemma… I have “friendly” names in input_selects and manage to use them in automations. Why do you need different names? It seems you need to explain what you are trying to achieve better
In the other proposal, the additional value is optional.
So your fan can only accept the literal words level1, level2, level3? Or do you mean it only accepts numeric levels?
Using the other proposal, it would look like this:
input_select:
my_selector:
name: My Selector
options:
- option: Low
value: level1
- option: Medium
value: level2
- option: High
value: level3
The proposed data-structure, namely a dictionary (key-value pairs), is just that, a proposal. It could also be a list which makes the YAML form of it more compact:
input_select:
my_selector:
name: My Selector
options:
- Low, level1
- Medium, level2
- High, level3
I assume you’re mappig your friendly option-names in your automations then right?
nope, using them directly
an example of one of my input_selects:
input_select:
radio_station:
name: 'Select Radio Station:'
options:
- Hit 92-9
- Nova 93-7
- Mix 94-5
- 96FM
- 80's
and associated automation:
automation:
- alias: 'Listen Radio'
hide_entity: true
trigger:
- platform: state
entity_id: input_select.radio_station
action:
- service: script.radio
with the script:
script:
radio:
alias: Play Radio on Chromecast Audio
sequence:
- service: media_player.volume_set
data_template:
entity_id: >
{% if is_state("input_select.chromecast_radio", "Lounge") %} media_player.lounge_speakers
{% elif is_state("input_select.chromecast_radio", "Bedroom") %} media_player.bedroom
{% elif is_state("input_select.chromecast_radio", "Office") %} media_player.chromecastaudio3249
{% elif is_state("input_select.chromecast_radio", "Lounge and Office") %} media_player.lounge_and_office
{% elif is_state("input_select.chromecast_radio", "House") %} media_player.house
{% elif is_state("input_select.chromecast_radio", "Everywhere") %} media_player.everywhere
{% endif %}
volume_level: '{{ states.input_number.volume_radio.state }}'
- service: media_player.play_media
data_template:
entity_id: >
{% if is_state("input_select.chromecast_radio", "Lounge") %} media_player.lounge_speakers
{% elif is_state("input_select.chromecast_radio", "Bedroom") %} media_player.bedroom
{% elif is_state("input_select.chromecast_radio", "Office") %} media_player.chromecastaudio3249
{% elif is_state("input_select.chromecast_radio", "Lounge and Office") %} media_player.lounge_and_office
{% elif is_state("input_select.chromecast_radio", "House") %} media_player.house
{% elif is_state("input_select.chromecast_radio", "Everywhere") %} media_player.everywhere
{% endif %}
media_content_id: >
{% if is_state("input_select.radio_station", "Hit 92-9") %} http://ic6ti.scahw.com.au/6ppm_128
{% elif is_state("input_select.radio_station", "Nova 93-7") %} http://streaming.novaentertainment.com.au/nova937
{% elif is_state("input_select.radio_station", "Mix 94-5") %} http://sc01.scahw.com.au/6mix_32
{% elif is_state("input_select.radio_station", "96FM") %} https://icy.ihrcast.arn.com.au/au_012_icy
{% elif is_state("input_select.radio_station", "80's") %} http://19173.live.streamtheworld.com/T_RAD_80S_S01AAC_SC
{% elif is_state("input_select.radio_station", "OldSkool Hits") %} http://sc01.scahw.com.au/loveland_32
{% elif is_state("input_select.radio_station", "Old Skool Anthems") %} http://nebula.shoutca.st:8075/stream
{% elif is_state("input_select.radio_station", "Raw FM (dance)") %} http://stream.rawfm.com.au:8004/;stream/1
{% elif is_state("input_select.radio_station", "181FM Power (Todays Hits)") %} http://listen.181fm.com/181-power_128k.mp3?
{% elif is_state("input_select.radio_station", "181FM 90's Dance") %} http://listen.181fm.com/181-90sdance_128k.mp3
{% elif is_state("input_select.radio_station", "181FM Star 90's") %} http://listen.181fm.com/181-star90s_128k.mp3
{% elif is_state("input_select.radio_station", "181FM The Breeze") %} http://listen.181fm.com/181-breeze_128k.mp3
{% elif is_state("input_select.radio_station", "Heat Radio (RnB)") %} http://174.37.159.206:8106/stream
{% elif is_state("input_select.radio_station", "Fresh 92-7") %} http://live.fresh927.com.au:80/freshaac
{% elif is_state("input_select.radio_station", "DI Chill & Tropical House") %} http://pub1.diforfree.org:8000/di_chillntropicalhouse_hi
{% elif is_state("input_select.radio_station", "DI Disco House") %} http://pub1.diforfree.org:8000/di_discohouse_hi
{% elif is_state("input_select.radio_station", "DI Funky House") %} http://pub1.diforfree.org:8000/di_funkyhouse_hi
{% elif is_state("input_select.radio_station", "DI Liquid D&B") %} http://pub1.diforfree.org:8000/di_liquiddnb_hi
{% elif is_state("input_select.radio_station", "Aloha Joe's Relaxation Island") %} http://s2.voscast.com:7932/
{% elif is_state("input_select.radio_station", "Spectrum Fit") %} http://51.255.235.165:5292/
{% elif is_state("input_select.radio_station", "Energy FM Australia") %} http://s3.viastreaming.net:8502/
{% elif is_state("input_select.radio_station", "Jazz Relax") %} http://199.195.194.94:8036/stream
{% elif is_state("input_select.radio_station", "Australian Country") %} https://streaming.radio.co/s5ea3fdd1c/listen
{% elif is_state("input_select.radio_station", "Rebel FM") %} https://au1.fastcast4u.com/proxy/rblgc?mp=/stream
{% endif %}
media_content_type: 'audio/mp4'
so you can see that the input_select ‘friendly’ name is used in the service call data_template
3 Likes
Yes, it only accepts level1, level2 and level3 as a valid fan speed. Displaying those values in the UI as an input_select to change the speed is not very pretty, therefore the friendly_name.
Mine was a proposal as well. It didn’t get the other feature requests “desire” in having a option (which already shoudld be the “value”) and then having a seperate value again. Which one would then be used as the input_select’s actual state?
So your entity accepts those firendly names, that’s the difference to my dilemma.
My fan doesn’t accept the friendly names. Therefore I want to display them differently in the UI. I really can’t describe the problem much better, I’ve written it down in several ways above.
But here again:
I’ve got a fan, which accepts the speeds “level1”, “level2” and “level3”. I want to change those speeds in my UI. Therefore I want an input_select, with my 3 different speeds. I don’t like them displayed as “level1”, “level2” and “level3” but rather as “low”, “medium” and “high”.
I would then have an automation which would set the fan speed depending on the input_select’s state. Currently I’d have to map those “low”, “medium” and “high” values to “level1”, “level2” and “level3” respectively inside the automation before I’d be able to set the fan speed.
Therefore, if it would be possible to set a different display_name/firendly_name for an input_select option, I would have a friendly name being displayed in the UI and the correct value/state being set inside my automation without to manually map the values around.
And all of that (probably) without causing a breaking change.
.
thats why I’m saying to use template sensors to create ‘friendly’ names that will be accepted by the fan. template sensors ‘follow’ the state of another sensor. did you read the doc I linked to earlier? it literally tells you how to do exactly what you need
it’s getting late here so i’m off to sleep but i can write the code for you in the morning if you post your entities, the names you want are already in the first post so it shouldn’t be too hard
Now I get you. I have plenty of template sensors, so I didn’t read it as I already know them. Your solution would be a workaround, just like mapping the values in the automation. There are lot’s of ways to do this, but I think the best/cleanest way would be to be able to set those firendly_names for input_select options.
1 Like
If expressed as a list, the following in YAML
Low, level1
is equivalent to this in JSON:
["Low", "level1"]
Therefore the source code would use the list’s first item (actually it’s the zeroth) for display in the UI. The optional second item would be for use in automations, etc.
The use of a list to represent the name and (optional) value allows it to retain the current familiar appearance when no value is supplied.
With values:
- Low, 35
- Medium, 65
- High, 100
Without values:
- Low
- Medium
- High
a work-around only because your particular hardware is not allowing the use of other names. I get your point, but i guess it’s something that very few people would ever need, since in almost all situations we can use whatever item names we want in our input_selects
Yes, that solution would aslo be feasable I guess. Nevertheless I think having a seperate “name” looks cleaner.
Yes, sure. I don’t say it’s a must have feature
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. 
- Low, 35
^ ^
| |
| For automations (optional)
|
For the UI
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.
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…
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.