Respect location ssdp header about node-hue-api HOT 3 CLOSED

I am respecting the location header being returned. The search data being returned to me from my bridge has a value of http://192.168.2.150:80/description.xml for the LOCATION value.

The point of the code that you indicate as hard coded is a direct link to the description.xml file, but is not used in the lookup from the SSDP lookups.

I had looked at your library in the past, but I wanted this library to be a small as possible, and your SSDP library includes a lot of extra dependencies that I did not want to pull in for an edge case bridge lookup that over 95% of users of the library would not need. When Hue released an update to finding of the bridges, they now have a broker service, which is the preferred discovery method.

from node-hue-api.

I'm not sure that it is respecting the location header. Take a look at this gist.

If you run server.js, it'll open two http servers - one on port 80, one on 8080 and set up a dgram socket to respond to bridge search requests.

The dgram socket responds with LOCATION: http://localhost:8080/foo.xml in the message, so if node-hue-api respects the location header, it should make a request to port 8080 and request /foo.xml.

search.js contains the upnp example search code from the node-hue-api readme. When I run it I see:

$ sudo node server.js
Socket listening
Responding to bridge search request
Responded to bridge search request
Got request for /description.xml on port 80

$ node search.js
Hue Bridges Found: [{"id":"WRONG PORT!","ipaddress":"localhost"}]

So it's requesting http://localhost:80/description.xml even though the LOCATION header in the search response is http://localhost:8080/foo.xml.

from node-hue-api.

Thanks for that, the penny finally dropped. I had checked that the LOCATION was being returned in the SSDP results, but of course you were right, as after that I defaulted to pulling the discovery xml via an API call, thereby not actually following the URL.

I have switched the code to issue a simplified HTTP GET on the LOCATION that is returned, which has no change on my bridge, as it is returning the http://192.168.2.150:80/description.xml value for me.

This has been released in version 1.1.1 of the library.

from node-hue-api.