Unable to fetch list of bridges due to non-existing bridges showing up in list

[Kordonme]

I'm unable to get a list of bridges using the API. This is because my https://discovery.meethue.com/ is returning three bridges even though I only have one. This is an issue by itself, but I should at least be able to get a list.

The reason it's not working is because the discovery API us not only returning a list, but trying to get its description:

node-hue-api/lib/api/discovery/index.js

Lines 37 to 43 in 80a6e44

	function loadConfigurations(results) {
	const promises = results.map(result => {
	return bridgeValidator.getBridgeConfig(result);
	});
	return Promise.all(promises);
	}

The getBridgeConfig method resolves each bridge to get some additional info. Because my bridge list returns 3 even though I only own one, the other IP adresses doesn't response and Promise.all is rejected.

Bridge list:

[
   {
      "id":"001788fffeb02653",
      "internalipaddress":"192.168.1.68"
   },
   {
      "id":"001788fffe6b9a6a",
      "internalipaddress":"192.168.1.227"
   },
   {
      "id":"001788fffe2b03d8",
      "internalipaddress":"192.168.1.209"
   }
]

[peter-murray]

Those values returned are all bridges registered against your use account at, https://account.meethue.com/bridge

If you sign into the above url, then you can remove the invalid bridges.

Currently it expects these bridges to all be valid, as these are all bridges that have been bound to your portal account at some point. The code needs to validate these to ensure it is a hue bridge before allowing you to proceed.

I will look into some potential error handling here, but I need to think about what to do with errors on any bridges, as it will not be valid to return them.

[Kordonme]

Is it necessary to get additional info when listing bridges? If yes, maybe it's a posibility to give the bridge 1-2 seconds to respond and simply return the list of bridges with a state as not responding?

[peter-murray]

It is, as the info retrieved is used to validate the self signed ssl certificate as well as proving that the reported values are real bridges in the client network.

I might consider returning invalid/offline bridges, but I need to properly think about how I want to do that, if at all. This discovery service is not heavily document by signify, but I need to only return real and valid bridges to the user.

[peter-murray]

In your case though, if you have only one bridge, then you do need to clear out the invalid bridges from your account, and this will all work as intended.

[Kordonme]

Yes, I see. Of course. The problem is I'm thinking about shipping node-hue-api in an Electron app. So I don't really have control over other users bridges. My only option for now is to do the discovery myself, maybe use node-hue-api to validate the certificate? Don't know if these mehods are public.

Maybe even ask the user to fill in the IP manually is better at this point :-)

Side note: how is it possible to delete old bridges? I don't see an option for it. Only this:

2 bridges were recently seen on your network. If you'd like to link a different bridge to your account, unlink your bridge at the bottom of this page and follow the instructions when adding a bridge.

And an option to unlink my current (and working) bridge.

[peter-murray]

You don’t have to run discovery, the api will support you specifying the IP address of a valid bridge, it will perform the necessary validations of the self signed ssl cert upon connection.

The discovery code perform validations on the proposed bridges, so that any results it returns are in fact real bridges.

I have two bridges myself, one for my network, the other for testing the api, but these are always resolvable and valid. In your case, the discovery portal is reporting three bridges for your network/account, I have never seen, or had reported previously, invalid bridges being reported by users.

I am looking at various options currently, but depending upon the solution, which I cannot fully test as I cannot manifest your use case, this may result in a major release as it will likely be in a change of behaviour.

[peter-murray]

I have released a test candidate for you into npm registry, 5.0.0-alpha.1 or next tag for you to try, it has error handling around the resolving of the bridge results.

Can you please let me know if that works, as I cannot manifest your failure condition easily so this has not been tested properly yet.

Any results it cannot connect to and resolve the configuration for will be reported in error objects, as documented https://github.com/peter-murray/node-hue-api/blob/master/docs/discovery.md#n-upnp-search

[Kordonme]

Thanks, will test it today!

[Kordonme]

It does seem to work. Even though the request takes about 10 sec per non-responding bridge:

[
   {
      "name":"Philips hue",
      "ipaddress":"192.168.1.227",
      "modelid":"BSB002",
      "swversion":"1937045000"
   },
   {
      "error":{
         "message":"Problem connecting to bridge '192.168.1.209': connect ETIMEDOUT 192.168.1.209:80",
         "description":"Failed to connect and load configuration from the bridge at ip address undefined",
         "ipaddress":"192.168.1.209",
         "id":"001788fffe2b0335"
      }
   },
   {
      "error":{
         "message":"Problem connecting to bridge '192.168.1.68': connect ETIMEDOUT 192.168.1.68:80",
         "description":"Failed to connect and load configuration from the bridge at ip address undefined",
         "ipaddress":"192.168.1.68",
         "id":"001788fffeb02635"
      }
   }
]

[peter-murray]

It will be using the default timeout of 10 seconds on the request, I can tweak that down, but 5 seconds would be the minimum I would do, as the bridges can take some time to respond on this end point when under load.

In your use case though it would be extremely valuable to me to find out how you have these other bridges in your account if you have only ever had one. I would recommend raising a support ticket with signify to find out what is going on here. I have never had anything like this reported before, and I have two bridges that come and go from the portal as expected. There could be a bug, or some old data issues on the signify side.

[Kordonme]

It seems that my issue is a cornercase. But at the same time it should be handled somehow. I think the current solution is a good compromise. We can leave this issue open and see if other people have any suggestions maybe?

[peter-murray]

If you really only have one bridge as you stated, then I need to understand how you ended up with three, all with unique Mac addresses registered against your account. That is the only real way to finalise a solution to this problem. I have never seen this, and it is either a bug, or there is something else going on here that to support I would need to know about.

Please, if you really only have one bridge, then raise a support ticket with signify on this so that it can be properly diagnosed, resolved and then the details fed back to this ticket so it can be properly resolved for all users in the future.

In the meantime, I will add a timeout to the nupnp function so it can shortened and then prepare this change for an upcoming 5.x release, as I have some more API changes that I need to make before I can cut that release.

[peter-murray]

I came across this discussion thread today https://developers.meethue.com/forum/t/n-upnp-shows-me-more-bridges-than-my-own/6073

It seems to think that the n-UPnP discover operates off of an external IP Address that the hue systems see. So for example if you are in situation where multiple homes are behind a common IP Address the service can report extra bridges that you do not own.

[nikolajjepsen]

Hello,

I seem to be running into the same issue as @Kordonme. I too only have a single bridge on my network, but discovery.meethue.com reports 3. I too don't have an option to remove non-existing bridges. The few apps I have installed all report a single bridge, but I'd imagine they filter non-reachable bridges.

I'm getting the following error @ 4.0.9:
ApiError: Problem connecting to bridge '192.168.1.154': connect EHOSTUNREACH 192.168.1.154:80

Upon updating the repository to next I too get the following response:
[ { "name": "Philips hue", "ipaddress": "192.168.1.194", "modelid": "BSB002", "swversion": "1940094000" }, { "error": { "message": "Problem connecting to bridge '192.168.1.201': connect EHOSTUNREACH 192.168.1.201:80", "description": "Failed to connect and load configuration from the bridge at ip address undefined", "ipaddress": "192.168.1.201", "id": "001788fffe28e505" } }, { "error": { "message": "Problem connecting to bridge '192.168.1.154': connect EHOSTUNREACH 192.168.1.154:80", "description": "Failed to connect and load configuration from the bridge at ip address undefined", "ipaddress": "192.168.1.154", "id": "001788fffe7fa6ee" } } ]

My requests seem to be quite a bit faster though, with responses between 500ms - 3.5s

[peter-murray]

So 192.168.1.194 is the functional bridge there in that response, the other two are not reachable.

I have been working on some other changes that will be incorporated in to the next release as due to this being a mjaor change I can modify some of the APIs.

To fix this problem, I am going to have to bump the major, as the current 4.x releases are not set up to cater for the multiple return result with the errors.

I am also on the fence here are to how to present this data via the API. Your feedback here would be appreciated. Are you only interested in the successful bridges, or do you potentially want to see all and the details as to why a possible match "failed". I can think of scenarios where by a real bridge is returned, but does not respond in time (due to load or other networking related issues) so it is useful to see that it was detected but had a failure.