Add support for HTTP SUBSCRIBE verb

mcclurec+flic

I'm trying to implement volume support for Wiim devices via a Flic Twist. Wiims present as a generic UPnP media renderer, so sending them volume change commands is pretty trivial from the Twist. What I want to do is get the volume states back from those devices if another application changes their volume. UPnP uses the SUBSCRIBE HTTP verb with a supplied callback endpoint, which in this case is just the Flic Hub IP address. It looks like you guys restrict the specific verbs which we're allowed to specify. If you're able to allow this new verb, we can make a generic app that supports all UPnP media renderers for native volume control.

mcclurec+flic

@Emil Sorry for the slow reply... There's a few things to look at. Wiim publishes a RESTful api as seen in the first PDF. Under the hood, it's built on an Arylic platform, which has further available RESTful endpoints.

It also presents a general UPnP, self documenting SOAP style API at http://<device-ip>:49152/description.xml. The UPnP spec is what dictates the SUBSCRIBE verb.

One quirk of the Wiim REST API is that it defaults to https with a self signed cert, that Flic doesn't seem to like. To get it to work with Flic, you have to run a proxy (e.g. http > https)

Emil

@mcclurec-flic Hmm is their API documented somewhere? So we can read about that it supports e.g. SUBSCRIBE and UPnP and what other endpoints exist, commands etc.?

mcclurec+flic

@Emil Alright, well I was able to get that going. Thanks for the suggestion.

At the end of the day, what would it take to get an app like this officially into the Flic software? I've got device auto discovery and volume, pause, play, etc. Just picking devices in the Flic app instead of having to make a "virtual device" with the same name as the Wiim would be great. I know there are a lot of other Wiim users out there.

Emil

@mcclurec-flic Right... In the meantime, you can use raw TCP sockets to send the request.