Describe the bug
We noticed an issue with the startNotifications callback order.
For background, we also saw this problem 4 years ago with the cordova plugin. See https://github.com/don/cordova-plugin-ble-central/issues/625 of @timburke. Thanks to him.
This was fixed by adding a second parameter to the callback to leave the client checking and reordering the sequences order. This fix has been included in version 1.2.4. the PR
To Reproduce
Not systematic issue. It occurs on a lot of BLE sequences to read, sometimes the read sequence is not the waited sequence but it's the next sequence
Expected behavior
startNotifications callback should be called in the order of BLE sequence. If it cannot be guaranted, the callback should have a parameter to leave the client checking and reordering the sequences order
Plugin version:
@capacitor-community/bluetooth-le: 3.0.2
Smartphone (please complete the following information):
Describe the bug We noticed an issue with the startNotifications callback order. For background, we also saw this problem 4 years ago with the cordova plugin. See https://github.com/don/cordova-plugin-ble-central/issues/625 of @timburke. Thanks to him. This was fixed by adding a second parameter to the callback to leave the client checking and reordering the sequences order. This fix has been included in version 1.2.4. the PR
To Reproduce Not systematic issue. It occurs on a lot of BLE sequences to read, sometimes the read sequence is not the waited sequence but it's the next sequence
Expected behavior startNotifications callback should be called in the order of BLE sequence. If it cannot be guaranted, the callback should have a parameter to leave the client checking and reordering the sequences order
Plugin version:
Smartphone (please complete the following information):