Channel Configuration vs Properties

So I’m redoing the sony binding and I’ve run into a situation that I’m unsure how to handle.

In a nutshell - the sony binding dynamically generates all it’s channels from the device (the device could be anything - tv, avr, soundbar, etc). For discussion purpose - let’s say each channel is uniquely defined by 4 attributes that help me track the source back to the device (service, scheme, source, index). Example: a TV speaker would have a service of ‘audio’, a scheme of ‘speaker’, a source of ‘tv’ and an index of ‘1’.

Prior to this rewrite - I encoded those four attributes into the channel ID and decoded when needed. For various reasons - that was a bad approach.

In the rewrite - I’d like to make those either properties or configuration parameters of the channel. Looking through our bindings for examples - some use properties (global cache as an example), others use configuration (kodi as an example)

Before I continue - I’d like to know what others think and how you’d differentiate a channel property from a channel configuration. I’m leaning towards configuration because that’s it ‘feels’ like (ie I’m configuration this channel to point to system/scheme/source/index)…

Don’t put too much weight in the fact that I used properties in the globalcache binding. It was the first binding I ever wrote. :smile:

I seem to recall that I used properties because the values were not something that the user should be able to change.

hmm - actually a good point as well. These are NOT values that the user should EVER change because they are coming from the underlying device. Basically the device tells me it’s capabilities in the form of API calls and I configure channels based on that. So the channel will ALWAYS be tied to the device identifiers (service,scheme,source,index)…

Are these device identifiers not part of the thing? and are they for all channels on 1 specific thing the same?
It’s not completely clear to me what problem your are trying to solve. Can you give some concrete examples of what is needed for a channel?

Nope - everything is dynamic with Sony.

Here’s a really simplified steps (it’s much more complicated):

  1. The discovery receives a UPNP packet for a Sony WebScalar device (could be a TV, could be an AVR, could be a soundbar, etc - don’t know and don’t really car). I create a WebScalarThing with the URL of the device
  2. This is really simplified but after going through a pairing process - the thing will try to go online.
  3. I call the service URL to receive a list of webscalar services (example: audio, av, browser, video screen, cec, system, etc). Which services returned are fully depended on the device (tv will generally have all of them - although it depends on the year, avr won’t have video screen and likely cec [depends on version], etc).
  4. For each scalar service - I iterate through all their properties of the service. The property is likely a group which can contains other groups and/or leafs (iteratively). Example: the audio service may have a speaker and headphone group. The speaker group would have a current, min, max volume. Again - this is a simplified version - reality is much more complex (especially with video inputs).
  5. For each of those properties - I create a channel for that property with the key to get to it. In our example from step 4 - the key would be “audio/speaker/volume”, “audio/speaker/minvolume”, etc. Please note their is really no limit to the number ‘paths parts’ that I can have as it depends on what the device tells me.

Coming back around to the original point - I’d have encoded the full path into the channelid “sony:webscalar:audio#speaker-volume” (can’t exactly remember the encoding right now - but it was something like that.

What I’d like to do is to take the path out of the channelid and either make it a property or configuration of the channel (and simplify the channelid - in reality, the channel id became unreadibly long and I had to account for illegal characters)

Based on the very good point about users specifying it - I’m thinking properties right now because the user should not modify the path at all (since it’s being generated from the device).

Hope that explains it?