It’s doable. Would likely need to be in a freestanding (non Vera) codebase, like @futzle’s codebase, for flexibility but the components are all there.
Mhhh it’s very interesting thing … maybe we must think again on the concept.
What do you think about a Little program in Java (for ex.) running in daemon, that do Upnp Controller’s work and provide to each other component (Vera, Openremote and other) an Json API …
It must be pretty doable with the famous Cling Library (http://4thline.org/projects/cling/) …
I think it will be more flexible, more “standardized method” (more software are compatibles with REST method…) and without Vera restriction and overload …
I will look forward into it, but i’m very far of an appkiller developer … or maybe someone know if something like this already exist ?
You have to release that the programming languages on Vera are very limited. You are pretty much restricted to using lua with out installing other software dependencies.
- Garrett
Sure about that, but I’m talking about a software that can running on another computer to help Vera (and other in the same time) to handle Media oriented upnp…
It can be your MediaServer or a little Raspberry Pi or something like this.
Not a vera Plugin, but a Vera companion 
but It’s true it’s going away from the vera plugin concept …
That’s certainly one style of integration, but once you do that you might a well dump Vera altogether (apart from, say, lock support) since you’d end up running both devices.
If you’re interested in that type of thing, check out the OpenHAB project. Just haven’t had enough time to cutover yet, runs on Raspi, Mac, etc… And there are a few other Arm based devices getting Java also, with a bunch if RAM so should get interesting in next 6mth of so.
OpenHab look very interesting, thank you for the link I will take a look !
But sorry to turn away this thread, let’s talk upnp !
Lolodomo, i’m so sorry to don’t have enough skill to help you little more …
This is far over my level of experience with upnp and general coding, therfore I want be able to contribute a lot. Very cool project, keep it up!
Is this only going to be able to send commands or will it also be able to report states back to vera?
I have now fixed the problem of arguments order when requesting a UPnP action.
I created a UPnP utility library that I can share between this new plugin and the Sonos plugin. This library is an extent to the Sonos library, fixing few things and adding stuff relative to the management of the UPnP proxy event.
The next steps:
- create a DLNA utility library that I could share between this new plugin and the Sonos plugin
- improve the extact of media information to make it as generic as possible
- adapt the Player tab
- test all the different Media Renderer controls (the ones I have not yet checked), in particular the SetAVTransportURI
When ready, I will release a first version for the DLNA Media Renderer Controller plugin + a new beta version for the Sonos plugin.
It will allow to send commands and to be informed of updates done by other controllers.
If by “report states”, you mean Vera triggers, currently there is only one trigger defined relative to the playing state (play, pause, stop, …). But we could imagine other triggers. You can propose…
You will use it to control which Media Renderers ?
[quote=“lolodomo, post:48, topic:177228”]I have now fixed the problem of arguments order when requesting a UPnP action.
I created a UPnP utility library that I can share between this new plugin and the Sonos plugin. This library is an extent to the Sonos library, fixing few things and adding stuff relative to the management of the UPnP proxy event.
The next steps:
- create a DLNA utility library that I could share between this new plugin and the Sonos plugin
- improve the extact of media information to make it as generic as possible
- adapt the Player tab
- test all the different Media Renderer controls (the ones I have not yet checked), in particular the SetAVTransportURI
When ready, I will release a first version for the DLNA Media Renderer Controller plugin + a new beta version for the Sonos plugin.[/quote]
Great news Lolodomo !
Do you think the upnp proxy event can do the trick of discovery ? especially our port discovery thing ? or only reporting status ? I’m planning to try to set up a DIY HA Alarm clock with a little Android pad. I will propably use Bubble upnp to play music at the wake up time … and modifying Vera’s config each time I reboot the pad to manage the bubble random port setting will be very annoying…
For the SetAVTransportURI part, I’m able to invok command succefully with upnp spy to my GMediarender on Linux, but I can’t manage to do the same thing with My Sony Home Theater (maybe I must send some commands before or something else). So it seem to be a little more tricky … I will be happy if I can do some beta testing for you.
Keep that way man, I think your work will be a great improvement to the vera capability … It is so bad that this device, who claim is upnp compliant, can’t play with it out of the box … or maybe MIOS team are stuck with the discovery part like us … ( but it seem your are going far away …)
I will use it for xbmc based devices, specifically openelec.
I was involved in the development of the current XBMC plugin, but this ist not upnp based. I also developped a plugin which allowed to control xbmc devices by json calls, but I never finished and published it. And as far as I know, these json based commands are outdated for current versions of xbmc. However, if you think you could use it I can give you the files.
I’d also be happy to do testing if this is any help for you.
Yesterday, I read the part of the UPnP specification relative to the discovery process and I discovered that when you know the IP of a UPnP device, you can send to it a discovery message and get a response in less than 1 second.
UPnP discovery is using SSDP protocol ( based on UDP transport protocol).
The specification tells that it should be the normal way to check if a UPnP device is ON or OFF (currently I try to read the description file).
It should be doable to implement this message.
Of course, it would solve the problem with the port because the port would be automatically discovered.
For the SetAVTransportURI part, I'm able to invok command succefully with upnp spy to my GMediarender on Linux, but I can't manage to do the same thing with My Sony Home Theater (maybe I must send some commands before or something else). So it seem to be a little more tricky ... I will be happy if I can do some beta testing for you.
The URI is certainly provided by the DLNA Media Server. I have not yet read this part of the specification, but maybe there is no real standard to define this URI.
In the future, I will implement media server browsing in order to converge to a real Control Point.
In a first time (only control of the Media Renderer), I will display the values of URI + metadata. It will help the user to understand what URI delivers a particular Media Server and so what values to deliver to SetAVTransportURI .
[quote=“chixxi, post:52, topic:177228”]@lolodomo:
I will use it for xbmc based devices, specifically openelec.[/quote]
That is my final intention too.
We can think about intesresting additional events, like for example an event for mute/unmute.
Concerning the volume, we could imagine a “volume up” or “volume down” event too. Is it something that could be of any interest in the real life ?
[quote=“lolodomo, post:53, topic:177228”]Yesterday, I read the part of the UPnP specification relative to the discovery process and I discovered that when you know the IP of a UPnP device, you can send to it a discovery message and get a response in less than 1 second.
UPnP discovery is using SSDP protocol ( based on UDP transport protocol).
The specification tells that it should be the normal way to check if a UPnP device is ON or OFF (currently I try to read the description file).
It should be doable to implement this message.[/quote]
Technically, I have to open a UDP socket to send the M-SEARCH message using port 1900. Then I have to receive the response. But there could be several responses. Does it mean that I have to call receive several times during a certain time period (5 secondes) ?
The unicast message sent directly to the UPnP device seems to be something implemented only bu UPnP 1.1 devices. I hope that most of our devies (XBMC, WMP, Sonos, …) are UPnP 1.1 devices and not only UPnP 1.0 devices. That is solething to be checked too.
[quote=“lolodomo, post:55, topic:177228”][quote=“lolodomo, post:53, topic:177228”]Yesterday, I read the part of the UPnP specification relative to the discovery process and I discovered that when you know the IP of a UPnP device, you can send to it a discovery message and get a response in less than 1 second.
UPnP discovery is using SSDP protocol ( based on UDP transport protocol).
The specification tells that it should be the normal way to check if a UPnP device is ON or OFF (currently I try to read the description file).
It should be doable to implement this message.[/quote]
Technically, I have to open a UDP socket to send the M-SEARCH message using port 1900. Then I have to receive the response. But there could be several responses. Does it mean that I have to call receive several times during a certain time period (5 secondes) ?
The unicast message sent directly to the UPnP device seems to be something implemented only bu UPnP 1.1 devices. I hope that most of our devies (XBMC, WMP, Sonos, …) are UPnP 1.1 devices and not only UPnP 1.0 devices. That is solething to be checked too.[/quote]
Do you know if I can test an unicast upnp discover with upnp tools ?
If it technically simpler to implement (and if most of device are upnp 1.1 compliant), setup IPs of devices is not very annoying, and maybe we don’t want to add all of the upnp devices in the LAN… or maybe you want to implement stuff like Discover → Device name like “name” → Add.
I just tried to code the discovery code.
I send a M-SEARCH request to IP 239.255.255.250.
Strangely, I only discover UPnP devices from my Vera but no UPnP AV devices (Sonos, XBMC, …). Why ?
What could be wrong in my code ?
Here is my code
local udp = socket.udp()
if (udp == nil) then
log("Call to socket.udp failed")
else
log("Call to socket.udp ok")
local result, message
result, message = udp:setoption("broadcast", true)
if (result == nil) then
log("Call to udp:setoption failed with message " .. message)
else
log("Call to udp:setoption ok")
end
udp:settimeout(5)
log("send UDP")
local datagram = "M-SEARCH * HTTP/1.1\r\n"
.. "HOST: 239.255.255.250:1900\r\n"
.. 'MAN: "ssdp:discover"\r\n'
.. "MX: 5\r\n"
.. "ST: upnp:rootdevice\r\n"
.. "Content-Length: 0\r\n"
.. "\r\n"
result, message = udp:sendto(datagram, "239.255.255.250", 1900)
if (result == nil) then
log("Call to udp:send failed with message " .. message)
else
log("Call to udp:send ok")
for i=1,500 do
datagram, message = udp:receive()
if (datagram == nil) then
log("Call to udp:receive failed with message " .. message)
break
else
--log("UDP datagram received " .. datagram)
local location = datagram:match("LOCATION: (.-)\r\n")
local st = datagram:match("ST: (.-)\r\n")
log("LOCATION " .. (location or "nil"))
log("ST " .. (st or "nil"))
end
end
end
udp:close()
end
Unicast discovery addressed to my PC is not working (nothing received). But it could be simply a consequence of the first problem.
There are quite a few differences between your code and the ssdpSearch() function in the WeMo plugin. The latter works (with my UPnP devices) in both multicast and unicast modes, so it may give you some ideas on what to tweak. I recall that SSDP discovery was as fragile as the rest of UPnP: you had to list the headers in the right order, and capitalization matters.
I did not know that you were doing UPnP discovery in the WeMo plugin.
Fantastic, I should find what is wrong.
I moved udp:settimeout, replaced udp:receive by udp:receivefrom and suppress the “Content-Length” header to have something similar to you.
This is still working (I receive all data from the Vera) except that I receive nothing from outside the Vera.
@futzle, what Vera model do you own ? VeraLite or Vera3 ?
I own a VeraLite.
Maybe the VeraLite is setup to filter all incoming messages when coming from outside ?