Nice.
I’ll see what I can do with the automation based on this.
Great work thanks!
This shows the input_select.folderlist2 correctly with a pull-down selection
but it does not update the State when viewed in the Developer Tool.
action:
- service: input_select.set_options
target:
entity_id: input_select.folderlist2
data:
options: >-
- Select {{ state_attr('sensor.pop_modern', 'file_list') |
map('replace', '/media/Music/Pop Modern/', '') | list }}
so when I add a second service to update input_text value it fails.
- service: input_text.set_value
target:
entity_id: input_text.folderlist2
data:
value: {{ state('input_select.folderlist2') }}
For the input_select.set_options service call, the value assigned to options must be a list. I don’t believe the combination of YAML and template you have there is understood to be a list. The line continuation character (>-) immediately tells the YAML processor that the rest is a Jinja2 template. That means the hyphen becomes part of the template’s result as opposed to being handled by the YAML processor as a list item.
The template in your second example is missing outer quotes.
I have this as a now valid automation
trigger:
- platform: state
entity_id: input_select.folderlist2
condition: []
action:
- service: input_select.set_options
target:
entity_id: input_select.folderlist2
data:
options: >-
Select,
''{{ ['Select'] + state_attr('sensor.pop_modern', 'file_list') | map('replace', '/media/Music/Pop Modern/', '') | list }}''
- service: input_text.set_value
target:
entity_id: input_text.folderlist2
data:
value: >-
"{{ states('input_select.folderlist2') }}"
but it is not updating the input_select state and so the input_text state does not get a value set.
Should I be using a template for the trigger instead of a change of state? Please excuse these noob stumbles.
EDIT: Just found this: Invalid state encountered for entity ID: input_select.folderlist2. State max length is 255 characters.
I have heaps more than 255 chars. Looks like I need to find a work-around.
Same mistake as described in my previous post (it’s not supplying the input_select’s options with a valid list).
The state value of all entities is restricted to a maximum length of 255 characters (and its type is always string). This constraint doesn’t exist for an entity’s attributes. However, assigning data to an entity’s attributes is more challenging because there’s no service call to do that. It’s typically done via the entity’s configuration. For example, in the case of a Template Sensor via its attributes option and via json_attributes_template for an MQTT Sensor.
I believe you will need to step back and rethink how you want to achieve your goal.
- That’s a very old post offering a way of doing something that wasn’t possible with an automation at the time (but now is).
- Nothing in that example will help you get around the 255 character restriction for storing content in
input_select.folderlist2.
Sounding like that 's the end of this endeavour.
I don’t think it’s entirely hopeless. I performed a simple experiment to set an input_select’s options and was successful. The key is how you present the data to options (as mentioned previously, your example doesn’t present it as a valid list).
I don’t have an entity with an attribute containing all the songs so I hard-coded it into the template, but the principle remains the same.
Try this script:
alias: Load tunes
sequence:
- service: input_select.set_options
target:
entity_id: input_select.tunes
data:
options: >
{{ ['/media/Music/Pop Modern/Daddys Coolest','/media/Music/Pop
Modern/The Divinyls - Desperate','/media/Music/Pop Modern/Emerson Lake
and Palmer - Pictures At An exhibition - 2 CDs -Progressive Rock - 2008
- BigGod','/media/Music/Pop Modern/THE MOODY BLUES, THE -
COLLECTED','/media/Music/Pop Modern/The Moody Blues Threshold of a
Dream','/media/Music/Pop Modern/Led Zeppelin I','/media/Music/Pop
Modern/Phys Graf','/media/Music/Pop Modern/Linda
Rondstadt','/media/Music/Pop Modern/Carly Simon - No Secrets (1972)'] |
map('replace', '/media/Music/Pop Modern/', '') | list }}
mode: single
If it works, modify it to get the tunes directly from the sensor’s attribute.
alias: Load tunes
sequence:
- service: input_select.set_options
target:
entity_id: input_select.tunes
data:
options: "{{ state_attr('sensor.pop_modern', 'file_list') | map('replace', '/media/Music/Pop Modern/', '') | list }}"
mode: single
1 Like
I was struggling with this for quite some time and now, based of @Taras post I revisited this and can confirm that it works! Here is my automation code:
# Automatically filling in playlists
- id: 'Load Volumio Playlists'
alias: Load Volumio Playlists
initial_state: True
trigger:
- platform: time_pattern
minutes: '/01'
action:
- service: input_select.set_options
target:
entity_id: input_select.playlists
data:
options: >
{{ state_attr('media_player.volumio', 'source_list') | list }}
So basically it looks at media_player.volumio available playlists, that are stored as source_list attribute, convert this to jinja list and loads into input_select.playlists.
Definitely something changed, as in the past HA versions it was not possible to create jinja list from template.
That’s true; in the past the output of a template was always handled as a string. When support for ‘native types’ was introduced (last November in version 0.118), the type of the template’s output is inferred from its appearance (i.e. is if looks like a list, its type becomes list).
BTW, you automation uses a time_pattern trigger to set the input_select’s options every minute. Wouldn’t it be more efficient to use a State Trigger that monitor’s the media_player’s source_list attribute? In other words, it would trigger only if the source_list’s contents change.
1 Like
Perhaps yes! That was very quickly created automation, just to check how it works. Even updating it every minute does not make sense, since based on experience I create maybe 1 playlist per month 
In reality I’ll now need to move this concept from Volumio (that I’m phasing out) to new HEOS integration for my new, just installed marantz. So I’ll need to dig more into this. To be honest at this stage I’m not even sure how to make it working with HEAS, as at the moment it does not provide proper source_list - only physical inputs (that anyhow I’d filter out for this purpose) and is not showing favorites not play lists… But this is clealry HEOS issue.
Anyhow it is excellent idea let changes of attribute trigger updates rather than force updates by timer!
You may also need to add an Event Trigger for startup. As you may already know, any options you set with the set_options service call will not survive a restart. So you may want the automation to execute on startup to ensure the input_select is loaded with the desired options and not its default ones.
Fo volumio I solved this setting up initial value of input_select to some already known list… but indeed here I expect this to be more dynamic, so manaully updating configuration does not kmake sense 
My aim with this post was to get a selection from the list in the input_select and copy that into an input_text. I had thought it was necessary to have 2 actions in the automation but I was over-complicating it. With your assistance I now have this working to do this:
alias: Album Select
description: ''
trigger:
- platform: state
entity_id: input_select.tunes
condition: []
action:
- service: input_text.set_value
target:
entity_id: input_text.folderlist2
data_template:
value: '{{ states.input_select.tunes.state }}'
mode: single
Of course the ultimate aim was to select firstly a category (Pop Modern, Classical etc.) then an album (or folder) name and play the content. I have another automation that plays the tracks within one particular folder but have now realised that I would need to have a folder sensor for every album. In my case that would be hundreds. Not practical.
This all comes about because the Media Browser in core can only play a single selection. No random continuous play or sequential play of tracks.
Maybe I just need to wait for the next step in the development of the Media Browser to become a comprehensive player.
Two things:
data_template was deprecated in favor of data many versions ago. It still works but is now considered to be archaic, especially when the service call also employs target which is a comparatively new term.
The preferred method of getting an entity’s state value is to use the states() function.
alias: Album Select
description: ''
trigger:
- platform: state
entity_id: input_select.tunes
condition: []
action:
- service: input_text.set_value
target:
entity_id: input_text.folderlist2
data:
value: "{{ states('input_select.tunes') }}"
mode: single
Ok. Thanks for the updating.
Just found your suggestion and it works! Unfortunately I get duplicates in the generated list so it throws an error. Is there a simple way to ignore or filter out duplicates when piping the list command, or do I have to loop?
Answer: {{state_attr(‘light.wled’, ‘effect_list’)|unique|list}}
The original example involved an Input Select so I was going to ask how/why do you have duplicates in an Input Select but I now see you are using a light’s attribute.