I used openHAB for quick prototyping. Mainly I used upnp to search all MediaRenderer devices on network and played different audio and video contents.
I investigated also available bindings to get understanding how upnp is implemented in openHAB. I found out that currently there is approach that every manufacture different hw device needs their own binding. Is it something what stays so? upnp is well standardised and it gives enough information about every upnp service on network. Instead of creating different bindings I think that one upnp controlling binding is enough to scan, identify and control upnp devices. Only problem is that most tv’s have also some rpc or else api’s to control some custom functionality. For that there can be some thing extending system so that every upnp device is handled by upnp control binding and based on some id (manufacture, product id. etc ) this upnp control binding channels can be extended if needed.
I think it is not that easy to have one general UPnP binding to control every capable device.
UPnP is standardised, but there is no standard for naming services used by devices, so we could have different service names for controlling the volume of different tv models.
To have them in one binding, a database for service names would need to be implemented and maintained, like this is actally done for zwave.
Under the bottom line, I would vote for having individual bindings, like it is today.
UPnP has both standard serviceId’s and vendor-specific serviceId’s. It also allows vendors to make vendor-specific extensions to the standard serviceId’s (as Sonos does)
All this is part of the UPnP spec and, while I agree there’s a lot of non-standard stuff going on in the UPnP space, it’s absolutely possible to build a generic swiss-army-knife ™ UPnP Binding - esp for some of the more DLNA centric Media components… and that can be used to drive a fairly wide array of stuff… without the need to go custom “up front”.
Things like Volume control are standardized (ref: RenderingControl), along with a variety of other Media services - although responses to calls can vary slightly across vender implementations, the core AV services are fairly consistent.
It’s obviously tricker to offer 100% control, over all features, but it is possible (and useful) to get started.
@lolodomo did it a few yrs back for another platform, after getting the core/generic components built out for the Sonos binding he built for that same platform.
Yes it looks very complicated and not 100% doable. But how I was planning it in my head was:
As I understand then upnp shares info about services and commands/actions etc what this service has. And they all have name, direction, data type etc. upnp has also standardised services what may have extra custom commands/actions etc.
Also in openHAB there is possible to add/remove channesl dynamically.
All upnp data types and standardised services commands/actions etc can be defined in thing-types.xml as as channel-type and channels. After discovery all not detected commands/actions can be removed and all what where not defined in xml can be added. This way you have connection to the device and commands/actions etc are mapped to openHAB channels. Then you can start to use all the standardised services or start to figure out how non standardised services, commands are implemented in this specific device.
