Mine’s a Lite too, set to get a (reserved) address over DHCP.
What’s upstream of your Vera? Routers have a habit of not always forwarding multicast packets, especially across segments. I’ve got my Vera on a separate subnet so I have to run a multicast proxy program on my router to allow the packets to cross the subnet boundary. See: Multicast routing UPnP traffic with Linux « bda's blog (but this should not be an issue for unicast packets unless you are deliberately filtering them out).
See what happens when you run your Lua discovery code on a real computer, perhaps somewhere where you can run Wireshark. Capturing packets was essential to my debugging process; it’s what identified the parts of the UPnP spec that the WeMo UPnP stack was a stickler about.
“To test UPnP calls you can use the Intel Device Spy utility available here. It should pick up Vera, show you all the devices, like light switches, thermostats, etc., let you expand the services and see the actions and variables. Click an action, like SetTarget, to specify the arguments and click ‘Invoke’ to run the action, such as turning on and off the light.”
But for me too, I don’t see anything related to vera in Device Spy … and whole of my House Lan is in the same subnet… strange …
I have now tested my lua code on my Windows PC using a lua interpreter and I can confirm that this code is working well. It discovers Sonos, XBMC, BubbleUPnP … and Vera.
I have noticied that in the received message, we can have either LOCATION or Location (in case of XBMC and BubbleUPnP).
The code is only not working to discover Windows Media Player. Something to investiguate.
So the lua code is clearly not the problem. The problem is that, when run on my VeraLite, it does not behave like on my PC.
I see two possibilities:
1 - either the SSDP SEARCH message does not leave the VeraLite (blocked by the Vera ?)
2 - either the return messages coming from outside the VeraLite are filtered, by the Vera or something else.
What is strange is that @futzle succeeded to have a working UPnP discovery inside a VeraLite.
Yes, but with Device Sniffer, you can look that Vera Advertise whole Z-wave devices (dimmable lights, Media Renderer, etc.)
This is somewhat contradictory … ???
I’ve spent my morning in google and Mios Wiki to find if we need to configure something, but with no luck .
Regarding the unicast SSDP, it does not work better on my PC but I think it is simply because addressed devices (Sonos, XBMC, …) are UPnP 1.0 devices and not UPnP 1.1 devices. It is what I read in the received messages (SERVER).
[quote=“macfly92, post:68, topic:177228”]Yes, but with Device Sniffer, you can look that Vera Advertise whole Z-wave devices (dimmable lights, Media Renderer, etc.)
This is somewhat contradictory … ???[/quote]
I don’t understand how the Sniffer is working exactly. When I run my code on the PC, I receive feedbacks from Vera devices while the sniffer show nothing… Maybe the sniffer does not detect response to M-SEARCH ?
And on my side, the Sniffer does not see Vera Advertise (NOTIFY messages). Should I wait several minutes to see them ?
Edit: ok, I found that I can launch “Search all devices” in Sniffer and then Vera devices appears in the Sniffer.
Regarding Device Spy, if Vera devices are not listed, it maybe a bug in Device Spy ?
I didn’t configure my Vera Lite’s network in any way when developing the WeMo plugin. Nor will its users have, and there have been users who’ve successfully just installed the plugin and had it work.
So. There’s something else. Clutching at straws:
Vera lite has more than one interface. Perhaps the multicast request is going out on the wrong interface? I remember having to use getsockname() in the WeMo code to figure out the source address, which varies across each interface. But I don’t think that’s it.
How long are you waiting for discovery responses to come back? In the WeMo plugin I wait for 5 seconds, and only give up when there’s been a timeout.
[ul][li]
If I launch a search of devices in Device Sniffer, I get the Vera devices. I have the same result from my own lua code run on the Windows PC. This is OK.
[/li]
[li]
Device Spy does not show my Vera devices. It could be a bug in Device Spy ?
[/li]
[li]
My lua code (the same code) run on the Vera only discovers Vera devices but no other devices from my local network. This is a major problem and I don’t understand why.
[/li]
[li]
The unicast discovery does not work for Sonos, XBMC, but it could be simply because they are UPnP 1.0 compliant (not UPnP 1.1).
[/li][/ul]
Do you think I should use setsockname to bind to the local IP address of my Vera (192.168.1.xxx) ?
You have a good idea, I will check the result of getsockname first.
How long are you waiting for discovery responses to come back? In the WeMo plugin I wait for 5 seconds, and only give up when there's been a timeout.
Same here.
I tried with 10 seconds and even more and it changes nothing.
log(“Call to socket.udp failed”)
else
log(“Call to socket.udp ok”)
local result, message
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: ssdp:all\r\n”
… “ST: upnp:rootdevice\r\n”
– … “ST: urn:schemas-upnp-org:device:MediaRenderer:1\r\n”
– … “ST: urn:schemas-upnp-org:device:MediaServer:1\r\n”
… “\r\n”
result, message = udp:sendto(datagram, “239.255.255.250”, 1900)
if (result == nil) then
log("Call to udp:sendto failed with message " … message)
else
udp:settimeout(5)
log(“Call to udp:sendto ok”)
for i=1,500 do
datagram, message = udp:receivefrom()
if (datagram == nil) then
log("Call to udp:receivefrom failed with message " … message)
break
else
–log("UDP datagram received " … datagram)
local location = datagram:match(“LOCATION: (.-)\r\n”)
if (location == nil) then
location = datagram:match(“Location: (.-)\r\n”)
end
local st = datagram:match(“ST: (.-)\r\n”)
local server = datagram:match(“SERVER: (.-)\r\n”)
if (server == nil) then
server = datagram:match(“Server: (.-)\r\n”)
end
log("LOCATION " … (location or “nil”))
log("ST " … (st or “nil”))
log("SERVER " … (server or “nil”))
end
end
end
udp:close()
end[/code]
I think it is identical to your code in WeMo plugin (except the decoding of the received message - but the problem is not here).
Regarding getsockname, if I call it just after calling sendto, I get IP 0.0.0.0 and a port number like 37770.
On the PC, I get another port number but the IP is 0.0.0.0 too.
Should I first call setsockname with “192.168.1.xx” and a port number ?
I tried to add this part of code before calling sendto:
result, message = udp:setsockname("192.168.1.xx", 0)
if (result == nil) then
log("Call to udp:setsockname failed with message " .. message)
else
log("Call to udp:setsockname ok")
end
With 192.168.1.xx the IP of my Vera (or my PC).
The new code still work on the Windows PC.
On the Vera, it is even worst, now I have no answer at all, even from Vera devices.
When I run ifconfig on my VeraLite, I see one interface eth0:0 with inet addr 192.168.1.xx but I see another interface eth0 with inet addr 192.168.81.x. Is it normal and could it be the source of my current problem ?
I ran that from a shell on my Veralite and I got responses from twelve devices on my LAN (one of which was Vera itself) before it timed out. The WeMo was among them along with a NAS and my cat-spying security webcams.
I agree, your code is good. Time to see what your upstream connection is doing. Perhaps the router isn’t forwarding multicast packets symmetrically. Something that occurs to me is that you haven’t said if your PC is connected over Ethernet or Wi-Fi.