Questions rather than issues

[federic0]

Hi, thanks for this work, I have a couple of questions:

1. only one bridge seems o be able to be connected to a nuki (as soon as I connected your bridge it disconnected from my android bridge. If used as fob, I guess you could issue lock/unlock commands and still be connected to the android bridge, is that right?
2. Can your bridge receive notifications of state change from the nuki or do you have to poll it?

Thanks

[jandebeule]

1. This is a restrictment from Nuki. You can only have one bridge that connects to a Nuki lock. You can indeed circumvent this by authenticating as a fob instead of a bridge (IDType argument of the authenticateUser method).
2. You have to 'poll' it using the isNewNukiStateAvailable method. However, this is a passive poll (does not consume any power on the Nuki lock) as it just looks at the iBeacons sent out by the Nuki lock. The Nuki lock changes its iBeacon signature whenever a new state is avaible. The problem with this method is that it only works well if you are using the nukiPyBridge as 'bridge' (and thus not as 'fob'). The reason for this is that the signature of the iBeacons remains changed as long as 'a bridge' does not read the new state of the Nuki lock (readLockState method). As soon as 'a bridge' has invoked this method, the iBeacon signature changes again to its normal state. If you have 2 bridges (android and nukiPyBridge for example) connected to the same lock, you will get race conditions whenever one of the bridges reads the new state from the lock because this will cause the iBeacon signature to be reset and the changed state can be missed by the second bridge. I hope this clarifies the behavior of the Nuki lock.

[federic0]

Thanks a lot, it's very clear.