select integration currently supports select_option service call only, while input_select supports input_select.select_next and input_select.select_previous which allow to cycle through select options.
select is not much different from input_select, and pairty of features would be great.
Yes, I totally agree. I’d like to use this very feature with the WLED integration to select the next preset and was surprised to find out they are treated separately.
I have no clue if it is a complex thing or not but it would be great to have the srvices select_next and select_previous for the newly introduced select entities. Same as what exists for input_select entities.
An example of usage for example would be to change WLED palets or presets with a remote control.
Hi,
I solved this for me using simple scripts yesterday. Maybe it helps you too.
Script for selecting the next element or (if unknown) the first. This also “cycles”.
next_select_element:
alias: next_select_element
sequence:
- service: select.select_option
data_template:
entity_id: '{{entity}}'
option: '{% if states(entity) == ''unknown'' %}{{state_attr(entity, "options")[0]}}{%
endif %}{% for option in state_attr(entity, "options") -%}{% if states(entity)
== option %}{{loop.nextitem | default(state_attr(entity, "options")[0])}}{%
endif -%}{%- endfor %}'
mode: single
icon: mdi:form-dropdown
Script for selecting the previous element or (if unknown) the last. This also “cycles”.
prev_select_element:
alias: prev_select_element
sequence:
- service: select.select_option
data_template:
entity_id: '{{entity}}'
option: '{% if states(entity) == ''unknown'' %}{{state_attr(entity, "options")[-1]}}{%
endif %}{% for option in state_attr(entity, "options") -%}{% if states(entity)
== option %}{{loop.previtem | default(state_attr(entity, "options")[-1])}}{%
endif -%}{%- endfor %}'
mode: single
icon: mdi:form-dropdown
call the script, e.g. from an automation
service: script.prev_select_element
data:
entity: select.led_og_jonas_preset
Regards,
Marc
All-in-one script to either select the next or previous option.
select_option:
sequence:
- service: select.select_option
target:
entity_id: '{{ entity }}'
data:
option: >
{% set (next, x, s) = ('n' in direction, state_attr(entity, 'options'), states(entity)) %}
{% set l = x | count - 1 %}
{% set i = x.index(s) + 1 * (iif(next, 1, -1)) if s != 'unknown' else 0 %}
{{ x[i if i <= l else l] if next else x[i if i >= 0 else l] }}
Call script.select_option with direction set to next or previous. Actually, the script only cares if the direction value contains the letter n to handle it as next and anything else is handled as previous.
service: script.select_option
data:
entity: select.whatever
direction: next
If you want to make the script more robust, you can include an action condition, prior to the service call, that confirms the supplied entity is a select entity and it’s not unavailable.
...
sequence:
- condition: "{{ expand(entity) | selectattr('domain', 'eq', 'select') | list != [] and states(entity) != 'unavailable' }}"
- service: select.select_option
target:
...came here looking to cycle thru WLED presets. This is exactly what i needed. Thanks a ton.
Actually nevermind about the previous pull request. Seems someone tried this before and core devs rejected the change indefinitely, seems they don’t want it.
Just a guess but I think the rationale is that select is meant to be used by integrations and input_select by users. An integration doesn’t need many services to make a selection.
I created a PR long time ago fixing this, but Frenk rejected it.
I really don’t get the reasoning why. Select is an array, it has ordering, there is no reason not to have next/previous functionality. Frenk’s argument that some integrations might not expect an order in the selections, like heat/cool/auto for example do not have order. But that’s not an array, it’s a set, so implement it as such - set not iterable/array iterable.
Would have been nice to mention that here 
Oh well, a learning experience for me, and a reminder to search harder first next time.
It was worth a try. Never know if and when they have a change of heart on the matter.
FWIW, it would be nice to have the extra services for select because MQTT Select allows you to define and, most importantly, programmatically re-define the members of the set and have the re-defined set survive a restart (stored on the MQTT broker as a retained message).
In contrast, although you can programmatically re-define an input_select’s members, the new set doesn’t survive a restart (it’s initialized with its original members). However, an input_select is more flexible in scripts and automations due to its additional services whereas select is limited to just one service.
Yeah, agree on the survivability. The fact that input_select doesn’t survive a restart really limits its functionality.
Yay it’s coming:
Just ran into this issue and then I find it’ll be included in the next release. @frenck is reading my mind 
Did it ever get included? How do we use it?
Yes.
Through a Service call action. Both select.select_previous and select.select_next are available for use with select entities.