Proposal: New multiselect entity type

[raman325]

Background

The select entity supports single select use cases but does not support multiselect use cases. A multiselect is useful in cases where e.g. days of the week, supported modes, or any other case where multiple items for the same parameter need to be selected.

Proposal

Create a new multiselect entity type using the multiselect domain.

Properties:

• options: list of all available options
• current_options: list of all selected options of len >=0
• supported_features: SUPPORT_EMPTY_SELECTION would indicated whether len >=0 or len >= 1 is required.

State:

• JSON dump of current_options

Services:

• select_options: Takes list of options as an input. Does error handling based on supported_features

Alternatives considered

• Extend select platform: We could do this but the trend has been towards making simpler, building block type entities rather than overloading existing ones.

[elupus]

I would vote for extending current select entity with this. Feel like a reasonable extension.

One consideration, dont know if json for the state of such entity would be good since state is generally in the end a string.

[raman325]

right but what's the alternative? dump would be a string representation of the list so that it could easily be parsed

[raman325]

alternative is that we make it a comma separated string but store the list in an attribute to make access easier and not require deserialization each time

[ScottG489]

At least thinking of this from a technical perspective, I don't think this should be the same as the current select. The current select is like an enum and a multi-select is like an array/list (scalar vs vector).

Also from having worked with config flows, I know there's already a UI representation of this. Perhaps this should be a helper as well?

Otherwise, I know I've definitely found myself wanting some sort of collection entity type, so this would be really nice!

[TheFes]

What if the state would be the number of selected options, and the selected options would be in an attribute:

name: Fruitbowl
state: 2
attributes:
  options:
    - Banana
    - Apple
    - Orange
    - Lemon
    - Durian
  selected:
    - Apple
    - Durian

[bdraco]

I think that lends a lot better to the new state translations model than some of the other proposals here.

Note sure on state or even if it needs to be anything more than on/off for if anything is selected at all or not

[frenck]

My grind with the proposal is:

State:
JSON dump of current_options

I don't think we should dump data structures in there... (but I also lack a better suggestion 😅)

[Petro31]

Ideas for state:

• Timestamp on last selection, allowing users to get list of selected items from option attribute.

  Pros:

  • Each state change would be unique and trigger.
  • We already have this behavior with Button entities

  Cons:

  • The state really has no meaning.

• Count of selected items, allowing users to get list of selected items from option attribute.

  Pros:

  • Each state change would be unique and trigger.
  • We already have this behavior with zones.

  Cons:

  • Some state changes could be missed. If a user somehow selects an item while simultaneously deselecting another item, the state will not change.

• A value that somehow tells the frontend how to translate the state into it's selections. E.g. AB means options 1 and 2 were selected, or a hex representation of each selection. I.e. 55 items in the list would be a hex string representing binary of on/off for each selection, where the position in the binary representation is the index. E.g. all 55 items are selected, state would be 7FFFFFFFFFFFFF, if only the 55th item is selected... 40000000000000. We'd need to ensure that the value is not converted to an integer, and remain a hex string.

  Pros:

  • Each state change will cause a trigger. No room for error here, would behave the same way as the timestamp version in regards to triggers.
  • Should easily work with enums when entity is provided by integration.
  • The translated state will show all options selected
  • The under the hood state will be templateable to get the actual selections
  • The under the hood state will always be less than 254 characters.

  Cons:

  • Will confuse people who look at the state under the hood.

Personally, I vote for the 3rd option as it will give everyone what they need and we could add a template filter/function that converts the value to a list of options (if needed).

[Petro31]

But if the hexadecimal representation is used, and again foo and bar are selected (and foobar not) the state would be "6"
However if then the option whale is added, the state will be recalculated to "C" Als when the order of the options changes for [ 'foo', 'bar', 'foobar'] to [ 'foobar', 'bar', 'foo' ] the state would change to "3"
This would mean a state change, where the actual selected options did not change.

If whale was added, it would be added as a higher int. The state would not change. It's not added at the beginning, the hex representation is opposite the list. I.e. your first item is the last bit. Your last item is the first bit (going left to right). Meaning the representation of the list would not change when items are added. It would change if items are inserted. I would expect a state change in that regard. Regardless, if you add/remove items from the list, selections typically need to happen again anyways. What happens when you remove a selection that was selected? Normal behavior when removing/adding items is to clear your current selections.

[Petro31]

e.g.

Your list [ a, b, c ] where a and b are selected, would have a binary representation of 011 (i.e. cba, abc reversed) and a hex representation of 3.

You decide to add d to the list.

Your list is now [ a, b, c, d ] where a and b are still selected. Your binary representation of the is is now 0011 (dcba, abcd reversed) and a hex representation of 3.

[TheFes]

Ah right, thanks!

[parautenbach]

I would definitely go for @Petro31's third suggestion. It's very common in application development (called feature flags) to control application features, rollouts, and such. In lower levels of development it would often be called bit masks and such (also used in networking e.g. your subnet mask). In other words, this is a very common and good use of this idea. In fact, the media player features I've worked with in HA when building my custom component does this too.

In terms of the listed con, since states are anyways always strings, I'd hex encode it, and even consider prefixing it with 0x which is commonly used to indicate a hex value. I'd do this rather than an integer representation. It is true the a string representation would be quite bloated compared to its true binary representation, but I think that's a small price to pay.

Back to media players and feature flags: The attribute in that case is actually represented as an integer (example supported_features: 450487). In other words, it would be consistent to use an integer representation (and more compact), but personally I'd prefer the hex string.

[ScottG489]

I'm not sure I'm all for option 3. The value doesn't have any face value to the user, and I think it's too technical of a detail being exposed too high up in the stack. I also don't think we have a precedence for doing something like this for other states?

Also if we're comfortable exposing a technical detail like this at this level, why not just use JSON for the state?

I almost want to say option 1 would be the best of the 3 proposed here. I think we have some precedence for using timestamps for state and putting the selected values in the attributes seems to work well enough. That said, I'm still not really a fan of this and I feel like there has been some decisions recently that indicate we want to move away from attributes for this kind of information.

Otherwise, I don't really have an alternative to suggest. However, I do know I've wished I had ways to store more complicated data in HA (objects, collections, etc) without a great option. Perhaps there not being a clean solution here for how to represent the state indicates a deeper problem.

[TheFes]

It would be great if the options could have a different label and value
For example if you would want to have a multiselect to send a TTS message to speakers around your house

options:
  - label: Livingroom
    value: media_player.livingroom
  - label: Bedroom
    value: media_player.this_is_where_the_magic_happens
  - label: Kids Room
    value: media_player.only_baby_shark_here

[ScottG489]

This is definitely a must. I believe this is possible with the existing multi-select that's available as part of the config flow (and maybe elsewhere).

[Phrede]

The perspective of a long time user... The long standing method across many platforms is using ctrl+ and shft+ to multi select items from a list. It appears there may be some overthinking going on here.

This is sorely needed. My example is that Amazon Alexa is greatly reducing their UI while increasing the problem areas. There currently is no way to delete multiple devices. Nor is there a global delete all that on could reinstall the needed ones. This required me to delete 300+ devices ONE AT A TIME! Amazon will not address this, of course, maybe HA will.

[starkillerOG]

@raman325 do you have any short term plans for implementing this?
I would love to use this for the Reolink integration, but if there are no short term plans, I will just implement a bunch of extra switch entities.

[raman325]

I can work up the selected proposal, but do we actually have consensus on this solution?

[starkillerOG]

I think the best solution is propsed by @TheFes here: #927 (comment)

But I do not know when and how a final dicission is normally made on a arch discussion.

[gjohansson-ST]

So far I looks more like several ideas rather than a complete proper proposal somewhere

[AJediIAm]

A multi select is basically a group of booleans. Implementing it as such (group of switches) with a value of true if one of the options is selected could also be an option.

[mikey0000]

Same here this is perfect for selecting mowing zones!

[frenck]

As I spotted some activity on this proposal, I wanted to provide a heads up / status update atm.

We discussed this proposal in a recent core architectural meeting and decided not to act on it yet. So, we keep it in the current proposal state on purpose. The reasoning is that we have some more ideas and goals for our information architecture in the short term that might impact entity proposals (like this one).

../Frenck

[raman325]

ack thanks for the heads up. Let us know when this is ready to be worked again, I would be happy to work on the PoC once we decide on an approach

[starkillerOG]

Thanks for the update frenck!

[Daniel-dev22]

Any updates on this?