Support select.select_next and select.select_previous

Feature Requests
1

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.

2

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.

3

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.

4

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

4 Likes
5

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

NOTE

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:
  ...
1 Like
6

came here looking to cycle thru WLED presets. This is exactly what i needed. Thanks a ton.

8

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.

9

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.

10

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.

11

Would have been nice to mention that here :stuck_out_tongue: Oh well, a learning experience for me, and a reminder to search harder first next time.

12

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.

13

Yeah, agree on the survivability. The fact that input_select doesn’t survive a restart really limits its functionality.

14

Yay it’s coming:

1 Like
15

Just ran into this issue and then I find it’ll be included in the next release. @frenck is reading my mind :smiley:

16

Did it ever get included? How do we use it?

17

Yes.

Through a Service call action. Both select.select_previous and select.select_next are available for use with select entities.

Select integration documentation and examples