Rendering of command options

[lolodomo]

Command options is a new feature that is not yet supported neither in Basic UI nor in Classic UI. And I doubt it is in Android App too.

Before adding the support of this feature in Basic UI (and in few bindings), I would like to be sure to understand what is expected.

Command options can be different from state options.

I see 3 different cases:

1. the channel has only command options but no state (for example the clear queue channel of the Sonos binding)
2. the channel has command options and a state without state options
3. the channel has command options and a state with state options

I imagine the command options have to be considered when the user uses the switch or the selection sitemap element.

For the cases 1 and 2, we should render the command options as buttons for the switch element and as a selection for the selection element, the same as we do currently when having state options.

For the case 3, does it mean we have to consider command options + state options, meaning building one button for each command option + one button for each state option ? In this case, we have to consider only one item when one command option is the same as one item option ?

Last question is relative (again) to switch item. If I come back to my example, the clear queue channel is associated to a switch item. This channel should have only one command option: CLEAR. Is it acceptable for a switch element having command options to render it with buttons or a selection list ? I ask the question because it was recently rejected to render like that a switch item with state options. Or should we update the item type of this channel to String and only consider String and Number items for command options ?

@maniac103 @mueller-ma for Android App

[cweitkamp]

I looked into this topic today and see what you are meaning. I tried to model some channel typed from Kodi binding to support command options instead of state option. Here is the result from my testings in Paper UI and Basic UI:

Paper UI - command option are rendered as Push button(s) - state options are rendered as both Selection and Button(s):

Basic UI - Both Selection and Switch elements are empty:

systemcommand ("Systembefehl" in German) uses command options and playfavorite ("Favoriten" in German) uses state options.

Maybe it is a simple change in the ItemUIRegistryImpl - Exchange item.getStateDescription(); by item.getCommandDescription() - maybe not.

But a little bit more theory in advance: State options are - in general - command options too. The getCommandDescription() first tries to return a command description, if none is found the state description will be converted to a matching command description. IIRC for both applies that dynamic descritons are preferred.

What should be the Default element for command option? Selection too? Or just Push button(s) - because they have no state?

To your questions - I additionally like to suggest to take the label and pattern into account.:

1. I agree with your proposal. Patterns in labels should be removed completely.

2. I agree with your proposal. The state should be taken into account for the label similar to state options. Personally I don not think that a combination of command options and a state does not make sense.

3. This is the most interesting question. Did you read Extend ChannelType by command options eclipse-archived/smarthome#5131 and try to find an answer or it? As above I personally do not think that a combination of both makes sense and state options should be preferred if needed. Command options should be only used for a matching use-case.

[cweitkamp]

@ghys Can you give me a short insight in how the new UI handles CommandOptions? Otherwise I will add Switch as Default element for rendering.

[ghys]

Simple: currently, it doesn't. But it's definitely something to consider and I suppose an action sheet would be an appropriate UI for those.

[cweitkamp]

Cool. Thanks. Looks nice. So it does not matter what we use here to solve this issue.