Modeling: action for playlist

Development Add-ons
1

Hello,

I have a modeling question which I would like to share with all of you.

Context

The HEOS addon provides a playlist channel, using a DynamicStateDescriptionProvider. In the BasicUI the end-user can select any of the playlists which he configured in the HEOS app and then they will be played next. This works sufficiently for most use cases.

Feature Request 1

However, the app provides other options besides ‘playing-next’. In the app it looks like this:

heos-select-playlist
heos-select-playlist1082×833 174 KB

[source]

I would like to provide this as an option as well. What I would like is to configure it as an Admin someway on the channel while linking it through the items files / paperUI. I suppose that for most users it would be okay when the same item always performs the same action, eg ‘play-now-and-replace-queue’

Feature Request 2

I also received a second request from an end-user. He wants to select and store one of those dynamically fetched playlists and use it to play as an alarm for example next day, so no action should happen in that case when selecting, but the state should be updated.

Possible Solution

I’m in doubt whether it would make sense to add support for this as a binding specific profile, that could then look like this:

heos:play_now
heos:replace
heos:play_next
heos:add_to_end

And maybe heos:select_only to support the second feature.

Do you have other suggestions or ways to support such a feature, maybe even such that you could switch the action every time you choose a playlist?

Thanks a lot.

2

Your solution with profiles sounds good IMHO, other potential suggestions without profiles involved:

  1. add a stateless channel per action which would all have the playlists as CommandDescriptions - except the ‘Playlist Storage’ (feature request 2) which would have a state. When a command is received the action is performed.
  2. add a Upcoming Playlist channel (different than the Current Playlist i.e. wouldn’t reflect the current playing playlist but would only serve as storage for the upcoming playlist), and a Playlist Action channel with the actions as command descriptions. Perhaps not the best approach since it would mean the upcoming playlist would have to be part of the state of the Thing (or ThingHandler)… Not sure either how to handle multiple links to channels. Maybe have those channels set a property of the Thing on update? (ugly, probably) But having actions as command options means they would render as a menu similar to the app.
  3. add a ‘Playlist Action on Command’ channel which would determine the action when your existing Playlist channel receives an update/command. Same problem with statefulness as 2., for the current playlist action.
3

You may want to take a peek at the pending upnpcontrol binding by @mherwege…

This add-on includes UPnP control point functionality for searching/browsing/playing the contents of a media server, so it may be have similar features to what you are looking to implement.

IMO, the upnpcontrol binding should be considered a potential candidate for generic UPnP control in OHC that other add-ons could be based on and then implement their own specialized device specific features.

4

I might misunderstand you, but UPNP is a protocol but HEOS does not support UPNP and has custom API. So I can of course take a look at the modeling but the upnpcontrol can never be the base of the HEOS binding. My main point being is that you can be correct but it seems a bit off-topic :slight_smile:

@ysc thanks for your comments, I considered your options as well, but especially 2 and 3 looked like abuse because AFAIK handlers should be stateless. And 1 feels redundant but could of course be an option.

I do however have one follow up question, would it make more sense to offer a single profile with arguments of 4/5 different profiles?

5

I have more terrible ideas if you want :wink:
Not really your requirement, but you might consider that only a handful of “favorite” playlists will actually be used in the end; and that you don’t need to present them all to the end user after all, rather let the admin set up this selected set of favorites. Then an option could be to make the thing extendable and define a “playlist” channel type. The playlist in question would be in the channel configuration, and the linked items would simply have the actions for the playlist as command options - trivial to add as buttons opening a menu in UIs.

This could work only if you have a limited number of playlists (say <10) which don’t change often.

6

Sorry about that. The OH documentation mentions that UPnP is used for discovery. I did not see any reference to a proprietary API, so I incorrectly assumed it was using UPnP.

1 Like
7

That explains a lot :blush:

8

I like @ysc’s thinking: Check how it feels best in the openHAB world and don’t try to force the UI concepts of the manufacturer app into openHAB.
Profiles are something pretty static in the sense that the admin selects one of them once and then there isn’t much dynamic about them. It therefore seems to me that they are not the concept that you’re looking for.

9

@kai would you prefer to have separate channel(types) instead of profiles? Because option 2 and 3 from the first suggestions of @ysc would require state in the handler and IRC this is an anti-pattern for openHAB.

The last message of @ysc is a nice addition so I can add it, but solves another problem instead.

Edit: because of @ysc latest suggestion I realize I can also do it using channel configuration instead of profiles, it only seems that there is not that much documented about channel based configuration.