Notify channel receiving duplicated values

[grubesa]

Hi,

I found bug with receiving multiple consecutive notifications from same characteristic. I'm expecting 6 consecutive notifications from my bluetooth device with different values but getting 6 notifications with some duplicated values. Firmware on device is not an issue because everything works fine on iOS app.

I have subscribed on characteristic with connection.openNotificationSubscription(notifyCharacteristic)
and try to receive values with receiveChannel.receive().value in while loop and also with receiveChannel.consumeEach{ } and nothing worked properly, still getting duplicates.

Then I dug deeper and noticed that I'm alway getting same BluetoothGattCharacteristic object so I put breakpoint on 279 line in https://github.com/Beepiz/BleGattCoroutines/blob/master/core/src/androidMain/kotlin/com/beepiz/bluetooth/gattcoroutines/GattConnectionImpl.kt and realised that value in BluetoothGattCharacteristic object is changed before it's consumed by channel.

To prove my theory, I fork your project https://github.com/arsfutura/BleGattCoroutines/tree/fix-notification-channel and instead of your line:

launch { characteristicChangedChannel.send(characteristic) }

I have put this:

val newCharacteristic = BluetoothGattCharacteristic(characteristic.uuid, characteristic.properties, characteristic.properties)
newCharacteristic.value = characteristic.value
launch { characteristicChangedChannel.send(newCharacteristic) }

and everything was fine. So I'm creating new BluetoothGattCharacteristic object with same value before sending to channel so value doesn't get overwritten. Not sure what is the best approach to this but I'm sure that it's a bug.

[LouisCAD]

Thanks for the report and the solution suggestion. Another user reach out to me and confirmed the copying of the BGC solved it. I'll see how I can fix it right into the library.

[odahcam]

I can confirm this too. Copying the characteristic solved the issue. Is a PR welcome?

[LouisCAD]

If it doesn't change the API, yes. Otherwise, please wait a few weeks for me to complete #62.

[odahcam]

It would't change the API at all, but I was unable to find time to do a proper tested PR, sorry.