search

peter-murray / node-hue-api

Node.js Library for interacting with the Philips Hue Bridge and Lights
Apache License 2.0
1.18k stars 145 forks source link

upnp search returns an empty array #162

Closed thkl closed 4 years ago

thkl commented 4 years ago

i struggled around with the local upnp search. After some debugging i've figured out that my bridge always returns the following:

{"host":"239.255.255.250:1900","ext":"","cache-control":"max-age=100","location":"http://blabla:80/description.xml","server":"Linux/3.14.0 UPnP/1.0 IpBridge/1.33.0","hue-bridgeid":"foobar","st":"urn:schemas-upnp-org:device:basic:1","usn":"uuid:foo-bar-blala"}

hue-bridgeid from the result will not match here : https://github.com/peter-murray/node-hue-api/blob/9bb7f07467f257d777d2a238c234f04493272aae/lib/api/discovery/UPnP.js#L111 to 'hue-bridgeId' and so the upnp search result is allways empty

peter-murray commented 4 years ago

Thanks for the details, that is a clear change to what it has been in the past (and possibly what I get from my bridge, I need to re-run the tests).

Can you possibly provide some more details about version(s) running on the bridge you are targeting? You can get these from the non-authenticated /api/config endpoint, e.g. for a host of ip addresss 192.168.2.1 it would be http://192.168.2.1/api/config.

Once I have that information I can delve deeper in the differences and provide an approriate fix that is also backwards compatibile if required.

thkl commented 4 years ago

Sure :

{"name":"Philips hue","datastoreversion":"83","swversion":"1933144020","apiversion":"1.33.0","mac":"-foobar-","bridgeid":"- blablabla-","factorynew":false,"replacesbridgeid":"-oldblabla-","modelid":"BSB002","starterkitid":""}

thkl commented 4 years ago

Update : after updating the bridge to the latest Firmware the Softwareversion is 1935144040 ; api 1.35.0 ... the hue-bridgeid string is still all lowercase...

peter-murray commented 4 years ago

Thanks, I will put together some tests tomorrow around this as it looks like it has changed.

Incidentally, is there a reason why you are using upnp vs nupnp which is their (signify) preferred method theses days?

thkl commented 4 years ago

Thank you ...

I am using your version 2 lib in one of my projects to connect Hue lights to another home automation system ( https://github.com/thkl/Homematic-Virtual-Interface ) ; and I want to upgrade my implementation to v3 of node-hue-api. For this case i cannot guarantee that the users bridge is connected to the internet so nupnp might fail. So maybe I will use both methods for discovery...

peter-murray commented 4 years ago

Ok, cool. Signify recommend nupnp first, or in parallel with upnp fall back, but nupnp only works of the user has registered the hub with the online portal.

I should be able to release a fix for this by Thursday at the latest, as I have to dig out an old test bridge to do some validation on.

peter-murray commented 4 years ago

4.0.4 has been released to resolve this issue.

Are you updating your API calls to v3 API or are you intending to use the shim? As I would need to update the node-hue-api-v2-shim library to use this latest version if that is what you are using in your code.

thkl commented 4 years ago

Great 👍 i will update all my code to use the v3 API.