Feature request: Populate Selection elements in sitemaps automatically

[cweitkamp]

In Paper UI you automatically have a select menu when the channel-type definition contains an options list. e.g.

<channel-type id="systemcommand" advanced="true">
    <item-type>String</item-type>
    <label>Send system command</label>
    <description>Sends a system command to Kodi. This allows to shutdown/suspend/hibernate/reboot Kodi</description>
    <state>
        <options>
            <option value="Shutdown">Shutdown</option>
            <option value="Suspend">Suspend</option>
            <option value="Hibernate">Hibernate</option>
            <option value="Reboot">Reboot</option>
        </options>
    </state>
</channel-type>

This is not possible in a sitemap for Basic UI without using a mapping parameter. A mapping parameter is static which makes it impossible to use dynamically created channels in a sufficient way or handle manipulated state descriptions during runtime.

String kodiLivingRoomSystemCommand { channel="kodi:kodi:XXXXXXXX:systemcommand" }

sitemap demo label="Kodi Media Center" {
    Frame label="Wohnzimmer (System)" {
        Default item=kodiLivingRoomSystemCommand
        Selection item=kodiLivingRoomSystemCommand
        Selection item=kodiLivingRoomSystemCommand mappings=[Shutdown="Herunterfahren", Suspend="Bereitschaft", Reboot="Neustart"]
    }
}

[lolodomo]

This new feature request does not concern only Basic UI but all UIs based on sitemap ?

[kaikreuzer]

I agree with @lolodomo - this needs to be a feature of the sitemaps, which could dynamically provide the mapping information, which would make this available in Android, iOS, etc., too.

[cweitkamp]

Absolutely. Even better if it's available in all UIs.

[mgeramb]

I want use a DynamicStateDescriptionProvider in my amazonechoncontrol binding (openhab) for selecting the bluetooth device and have the same problem that it is useless in sitemaps. If this can be done easily in the sitemap implementation, it would be nice.

[mhilbush]

It also would be nice if the mappings could be populated from an Item.

My use case is to display a list of Favorites from a music player (Squeezebox, Sonos, etc.) in Basic UI (using sitemap Selection widget) and in HABpanel using HABpabel's selection widget. When the Favorites list is updated in the music player, a favorites channel on the music player's binding would be updated with the new Favorites. The Selection widget would automatically reflect the update using the Item linked to the favorites channel.

I've already opened an enhancement request for HABpanel here

Edit: I'd like to see support for comma-separated choices for mappings (like what's supported today e.g. command1="label1",command2="label2",...), as well as JSON.

[cweitkamp]

@mhilbush I understand what you want to do but I'm wondering why you need two items for that? Correct me if I'm wrong: You want to have one item containing a comma separated list of all favorites as mapping for another item which starts playing one of those favorites? My idea is similar: I like to implement a channel for playing a TV channel in the Kodi binding. The list of TV channels depends on the users settings. In my opinion you can dynamically change the StateDescription during runtime by reassigning a new list of StateOptions to it. Those should be used to populate the Selection elements in the sitemaps. Wdyt?

[mhilbush]

In the case of squeezebox I was thinking that the server would have a channel for the favorites list, and each player would have a channel that allowed you to play any favorite from that list on that player.

I wasn't aware that the state description could be updated dynamically at runtime. So how would that work with the above? Would each player have a channel whose state description could be modified during runtime to reflect the latest favorites list from the server?

Am I understanding it correctly? If so, I'll need to see if HABpanel can deal with it when the options update dynamically.

Edit: Also, is the updated state description available to a rule? How would the rule know the state description has changed?

I think sonos has a similar model, so what would work for squeezebox might also work for sonos.

Edit: FYI. I submitted a WIP PR for what I was thinking.

[cweitkamp]

So how would that work with the above? Would each player have a channel whose state description could be modified during runtime to reflect the latest favorites list from the server?

Exactly.

Am I understanding it correctly? If so, I'll need to see if HABpanel can deal with it when the options update dynamically.

Yes, you have to check that. afaik only Paper UI can handle it right now.

Also, is the updated state description available to a rule?

I'm afraid that's currently not possible. But nice to have - we should open a new issue for that, shouldn't we?

Let's continue our discussion about the best practice how to implement that feature in a bindings to your PR openhab/openhab2-addons#3190.

[mhilbush]

Ok, great. Then I'm on the right track. :-)

Thanks for the pointer in the other thread. I'll look at DynamicStateDescriptionProvider.

I think I'll keep the channel on the server thing for now. I'm already finding it useful...

[Tony080]

Hello, I'm a new guy to the community. And I'm still trying to learn more about Eclipse Smarthome. Please correct me if I'm wrong. Thank you!

I'm wondering that as we do some settings in paper UI(or other UIs as well), is it possible to automatically generate a "sitemap" with all the existing settings in paper UI rather than manually creating the sitemap? And, perhaps the auto-generated sitemap has a special name like "auto_config.sitemap". In this case, people don't have to update their own sitemaps immediately when they finish configuring with paper UI. Whatsmore, people can do some part of copy&paste from part of the auto-generated sitemap.

In this case, the "auto_config.sitemap" will always available on mobile clients.

[sjsf]

Welcome to the community, @Tony-Hu! Of course, asking questions is absolutely the right thing to do and I'm pretty sure there are numerous people around who are willing to help. Nevertheless, may I kindly ask you to not hijack any existing issues/discussions for your questions? You are always welcome to create new issues if you think something is not working as expected or you would like to suggest new features, or simply post questions and trigger discussions in the forum. The reasoning for this is that otherwise we'll simply end up in total chaos here 😄

[Tony080]

@sjka Acknowledged! I'm sorry to make a distraction of the topic.

[sjsf]

All good. I didn't mean this to be offensive or anything. Just go ahead and create a new issue for that - your idea sounds absolutely plausible definitely is worth discussing!

[Tony080]

@sjka It's OK! I just created my idea as a separate issue. Thanks for the suggestion!

[lolodomo]

As I can see, the options are provided through the REST API (inside the item data). So it could be handled by any UI. I think there is nothing to change in the framework for that enhancement.

Currently Basic UI and Classic UI only consider sitemap static mappings for a selection widget but my feeling is that we could easily enhance it to provide the same rendering but using options when no mapping is provided.

This should be very easy for Classic UI becvause the page is rebuilt at each update.

For Basic UI, I see a difficulty because the page is built by the back-end when opened, not when a widget is updated. That means the selection will contain the options available for the item when the page was opened. So if the list of options is updated while a page is already loaded, this will not be taken into account in UI. Rebuilding the list of options in one opened page would be more difficult to implement because to be done in the front-end (JavaScript) rather than the back-end as done today.

I will try it to implement that except the last point I mentioned for Basic UI.

[lolodomo]

This is now implemented in Classic UI.

[lolodomo]

This is now implemented in Basic UI too.

[mueller-ma]

As I can see, the options are provided through the REST API (inside the item data).

I updated my oh snapshot to 2.4.0~20180601235947-1, configured the kodi thing via Paper UI and added the item and sitemap from the first post, but options is empty:

[lolodomo]

I did my tests with the Netatmo binding and 2 of the channels that have options defined: temperature tendance and pressure tendance.

And I just updated the Sonos binding to create dynamic options for favorites, playlists, ... and it works.

[lolodomo]

Oups, after retesting I am now like you in the case where the options are empty for the netatmo channels ! But still ok with my updated version of the Sonos binding that implements a dynamic state description provider. Maybe we encounter the known problem that it depends which state description is finally used.

[lolodomo]

Ok, I found the issue, the problem is that any dynamic state description state provider (like the Kodi one) should return null when the requested channel is not handled by the current binding. If not, it resets options for other bindings ! I discovered that with my similar implementation for the Sonos binding.

[lolodomo]

@mueller-ma : please try without installing the Kodi binding until my PR fixing the bug in the Kodi binding is fixed. Then you can try with any channel that defines static options in the channel type.

[lolodomo]

I have now handled sitemap Selection element but we could consider the sitemap Switch element too. For a switch element without mappings defined but with state options for the linked item, we could create a button for each state option. Of course, we have to consider a limit. If there are 50 state options, the UI will not be able to display 50 buttons.

[lolodomo]

As this is now implemented in Basic UI and Classic UI, I think this issue can be closed. Another issue was opened for the Android app.