Details
-
Bug
-
Resolution: Cannot Reproduce
-
P2: Important
-
None
-
5.11.3
-
None
-
Linux/Other display system
Description
Hi,
I'm using 2 QLowEnergyControl objects for monitoring char changes in 2 different BLE peripherals.
All works fine when both BLE peripherals are powered, but the moment one of them is powered down, the char changes can no longer be trapped in the QLowEnergyControl object that is still connected to the powered BLE peripheral.
The moment the BLE peripheral that was powered down, is powered up again, the changes of both BLE peripheral can be trapped again in both QLowEnergyControl objects accordingly.
Also strange is that the notifications are still trapped if a certain BLE peripheral is powered down. Meaning if I have QLowEnergyControl A and B monitoring respectively BLE peripherals C and D. To be clear A is only monitoring C and B is only monitoring D.
When I power down C it can be that the char changes of D are still trapped in B. But when I power down D it can be be that the char changes of C are no longer trapped in A.
So it is NOT this restriction:
On Linux/BlueZ systems, it is not possible to connect to the same remote device using two instances of this class. The second call to this function may fail with an error. This limitation may be removed in future releases.
I hope I explained the use case clear enough.
Alex that is the reason why I would love to see if a peripheral device is still powered before having to call the connectToDevice function. As the device info is cached I can't use the rSSi value...
Update :
I can solve it by indeed calling the requestPairing with the Unpaired when the QLowEnergyControl catches a disconnect, but then it needs to do always a new pair process before making a new connection, for security reason I would only want to do this during the commissioning process. I will only allow one connection from the BLE central to each BLE peripheral.
Best regards,
Frank
