Handling multiple bridges

[giampiero7]

It looks like the SDK has not been designed to handle more than one bridge by the same application.
Am I doing something wrong or this is actually the case?
If that is, are you planning to add support for multiple bridges?
Thanks

[SteveyO]

Hi,
This a yes and no answer. The Java SDK was designed to handle multiple bridges and it works. However, as the most common use case is 1 bridge then all our examples quick start apps assume 1 bridge, and our PhHueSDK singleton makes use of the single selected bridge.

For apps that require multi-bridge support the responsibility lies with the developer on handling the correct bridge. I have just written a little paragraph in our Java SDK documentation on how it can be done and the main things you will need to consider.

http://www.developers.meethue.com/documentation/java-sdk-getting-started#multiBridgeSupport

I will close the issue, but if you have any questions then just re-open it and I will answer.

Thanks
Steve

[giampiero7]

@SteveyO The support for multiple bridges is mainly missing when using aPHSDKListener.
To give you a simple example, if the method onError(int code, final String message) is called on my listener, how do I know to which bridge the error is referring to?

P.S.: I cannot reopen the issue

[SteveyO]

@giampiero7 Sorry, didn't realize you could not re-open issues. I have re-opened this myself.

Yes, this is a good question. The short answer is you don't know which bridge the sdklistener is responding too as this is only registered once. Can you elaborate on what kind of problems you anticipate would happen in onError?

They way I see it, is you register your listener as normal, and perform a bridge search. When you get your list of found bridges and the user selects 2 (or more) then I would expect the developer to process each bridge connection (or authentication/pushlink) sequentially so you would always know what callback belongs to each bridge.
The only potential issue I see is if you send commands to multiple bridges in parallel and one of the Bridges stops responding (i.e. you lose connection). In this case you will get a Bridge_Not_Responding without knowing the bridge. You could always show a generic message here, or try pinging all you Bridge IPs.

[giampiero7]

In onError I would want to handle every possible case in which this method is called, the last example you gave is one of those...
But onError is probably the least relevant (still, not to be dismissed) case in which this problem arises. There are other callback methods in PHSDKListener which do not give me a reference to the bridge object.

Moreover, if during discovery I connect to multiple PHAccessPoints (in onAccessPointsFound) in parallel, then when onBridgeConnected is called I don't know what access point is linked to what bridge...

Is there no way to know which accessPoint a bridge is linked to?
And wouldn't it be easier to have a listener for each bridge?

Thanks again!

[SteveyO]

Hi again,
I did check all other callback methods and most seem to either have a Bridge object or a PHAccessPoint (which contains the IP Address) so to me they look fine, apart from the one I mention. If you think I missed one (that could cause problems) let me know and I will check?
When the onBridgeConnected is called, the Bridge object is passed so you can get the bridge IP Address from the cache by:
bridge.getResourceCache().getBridgeConfiguration().getIpAddress()
so you can link this back to the clicked AccessPoint record which also uses the IP address.

Am not sure we could have a listener for each bridge, as the listener is used mainly for finding, connecting and authentication 'to a bridge' and it is registered before we have a bridge object.

Steve

[giampiero7]

Having the link between bridge and access point solved the problem for the other callbacks... I didn't find that long chain of methods to call before :)
I'm actually using the MAC address to be safer:

bridge.getResourceCache().getBridgeConfiguration().getMacAddress()

By "listener for each bridge" I was thinking of a new class designed just for that... anyway, it's just a different way of thinking...

I guess the only missing step for full support of more bridges is a reference to the bridge (or AP) in onError().

Thanks!