UPnP binding

[openhab-bot]

From joris.de...@gmail.com on May 03, 2012 14:47:34

It would be nice if the OpenHab has a binding that supports the UPnP AV specification, in particular the Media Server and Control Point would be helpful.

For the Media Server part this means that the OpenHab acts as a source for Media Renderers. For the Control Point the UI can act as a control panel, meaning the OpenHab UI can control other UPnP AV devices, e.g. to start/stop/... a media player such as Playstation 3 and others.

An Java implementatation for UPnP is available at http://4thline.org/projects/cling . An OSGi compatible version can be found http://4thline.org/m2/org/fourthline/cling/ .

Original issue: http://code.google.com/p/openhab/issues/detail?id=85

[openhab-bot]

From kai.openhab on May 04, 2012 14:14:04

Would you have a concrete example of what kind of item type you would bind to what kind of device? Especially the "act as media server" use case is not really clear to me.

[openhab-bot]

From joris.de...@gmail.com on May 07, 2012 05:42:35

An example for the Control Point functionality:

• Switch Room_StartStop "Play/Pause" (Bathroom) { upnp.control="ON::play, OFF::pause" }
• String CurrentSong "Currently playing" {upnp.control=":active"} The Control Point Binding discovers the , meaning the Media Device to be controlled, and executes the action accordingly.

Regarding the Media Server; At first glance it would be nice that OpenHab is a Media Server, but a second glance this doesn't seem the goal of OpenHab... OpenHab is not a Media Center Server...

In my case, I would like to have the following. My TV is connected to a HTPC running XBMC. From the OpenHab UI I want to control XBMC, e.g. selecting content and control the current item. Combined with XBMC control I want to integrate with home domotics based on KNX and Loxone. I prefer to integrate on specification rather than an implementation, therefore I prefer UPnP (same as choosing KNX/X10 rather than vendor based implementation).

[openhab-bot]

From kai.openhab on May 09, 2012 02:04:50

The control point functionality (play/pause, setting/getting current track) should be fine. Using openHAB UIs as a "remote control" for XBMC is rather difficult - there is no easy way to browse through media libraries etc.

Status: Accepted

[openhab-bot]

From karel.go...@gmail.com on June 10, 2012 06:33:24

I have a particular need for a Sonos binding. There does exist a sourceforge project (Janos) that does this trick, and it is based on UPNP as well. It is based on SBB (SuperBonBon Industires) UPNP library (used frequently in open source projects). Therefore, I am open to contribute to a "base" UPNP binding, on with possibly more specific bindings (like Sonos) could be developed. This specialization of the binding is most likely to be necessary because of the complexity of the underlying upnp messages that are used to to communicate with the devices.... It also uses a discovery service to discover devices and so on, and in Sonos' case, XML/Upnp messages are defined to exchange, browse, control,... media libraries, song queues and so forth....

( http://janos.sourceforge.net/ )

K

[openhab-bot]

From karel.go...@gmail.com on June 10, 2012 06:45:17

just had a look at cling. imho very nice library and way to go for the upnp binding

[openhab-bot]

From karel.go...@gmail.com on June 16, 2012 06:44:00

After studying Cling in details there are IMHO two options or routes to implement UPNP bindings:

1. Customize for a given device (example: Sonos audio equipment), thereby implementing all the relevant upnp.org device templates relevant for the device (MediaRenderer, ....), and have the binding defacto hide the upnp specifics
2. Implement a binding that is generic and implements a single given/standard upnp template, do a mapping between OpenHAB Commands and the upnp template Actions, and then do the actual binding to the physical device through its unique UID by means of an entry in the .cfg file. If a device announces that it adheres to the given upnp binding, then, in theory, it should react/act upon all Actions (and thus openhab Commands) define in the template. (reality however is that some devices leave some template Actions unimplemented, so this can lead to unexpected behavior)

[openhab-bot]

From karel.go...@gmail.com on June 23, 2012 04:05:25

For everyone following this Issue: i have started work on the Sonos binding, based on the Cling UPNP library, and I intend to build it in such a way that it can be easily refactored/stripped afterward to form the basis for a more general UPNP binding, e.g. one where there can be a mapping between a given UPNP.org service template and OpenHab Commands.

[openhab-bot]

From teichsta on May 21, 2013 14:17:49

unassigned to make current state more transparent

[openhab-bot]

From kai.openhab on May 22, 2013 01:10:22

Owner: ---

[openhab-bot]

From openhab.lb on June 24, 2013 23:30:32

is there some progress for a general upnp binding ? option 2 from ahead ?

[openhab-bot]

From teichsta on November 05, 2013 14:47:53

Labels: To-Github

[hmerk]

Can be closed, io.transport.upnp and org.jupnp bundle available

Cheers Hans-Jörg

[kaikreuzer]

Not sure I do agree. This feature request was about a generic UPnP binding, not a upnp library that can be used by specific bindings.

[hmerk]

As you know out of the WeMo discussions and Problem with Belkins UPnP implementations, I don't see a generic UPnP binding. This might lead into large discussions if a device does not work properly, like the WeMos. Is the device causing the problem, or is it the binding ????

Your decision ;-)

[mrguessed]

On MiOS/Vera, we've found a generic UPnP Plugin to be extremely handy for talking to a variety AV kit, stuff that typically wouldn't warrant a dedicated Plugin.

Yes, there are device-specific "quirks" but they're not of the scale seen with the WeMo (which, like the Sonos, has it's own Plugin in Vera-land) but it's a great way to get started... at least until you do run into those odd cases ;)

[kaikreuzer]

So let's clearly leave this open :-)

[jandernascimento]

I support a implementation of a binding for UPnP as well (that would avoid plenty of binding that in fact are just a layer over UPnP e.g. Sonos ), cling seems to be a good choise.. or even build something from UPnP basedriver. I ll be loooking at it, building a binding to myself and i ll let you know the result.

[kaikreuzer]

It might make sense to directly build this for openHAB 2 now as we have an io.transport.upnp bundle already in place, used for Sonos, Wemo etc.

[kaikreuzer]

Closing as I'd prefer to follow up on this for openHAB 2.