Possible Android Bluetooth Issue

[TPitman-mindfiretechnology]

I am not able to create a good example, so I am posting this here to see how I should report this.

I am subscribing to a characteristic that belongs to a service that uses a 16bit UUID of FE59. When I use the WaitForCharacteristicSubscription extension method to wait for the subscription to complete it times out.

I have the shiny source code and debugged into it and found that the IsNotifying never gets set to true.

In the console log I see this output from shiny:

Shiny.BluetoothLE.IPeripheral: Information: Subscribed to Notification Characteristic FE59 / 8EC90003-F315-4F60-9FB8-838830DAEA50

That seems to indicate that the subscription has happened.

I dug further and modified the IsNotifying method in the Peripheral_Characteristics.cs file for the Android platform. Here is what I changed:

protected bool IsNotifying(string serviceUuid, string characteristicUuid)
{
this.notifications ??= new();
lock (this.notifications)
{
foreach (var notification in this.notifications)
Console.WriteLine($"******************** {notification} looking for key: {NotifyKey(serviceUuid, characteristicUuid)}");
return this.notifications.Contains(NotifyKey(serviceUuid, characteristicUuid));
}
}
``

Notice I added the console output to see what was in the notifications list and what was being searched for.

The output from this was:

[DOTNET] ******************** fe59-8ec90003-f315-4f60-9fb8-838830daea50 looking for key: 0000fe59-0000-1000-8000-00805f9b34fb-8ec90003-f315-4f60-9fb8-838830daea50

As you can see the value that was inserted into the notifications list has the 16bit UUID, but the value being searched for has been normalized to the full 128bit UUID.

I believe the difference is that when doing the search from the FromNative method, it uses the ch.Service.Uuid, but when doing the AddNotify the serviceUuid is passed in. I figure that the Service.Uuid that is contained in the characteristic (ch) is normalize to the full 128bit id at some point.

I am not sure the best way to fix this, but hope you can give some guidance.

[TPitman-mindfiretechnology]

I realize that I can just change my UUID to 0000fe59-0000-1000-8000-00805f9b34fb and have done that, but thought you might still want to know about this.

There is a similar issue with the extension methods like WaitForCharacteristicSubscription because if the user passes in the 16bit UUID to those methods, they are then compared to the ch.Service.Uuid value that has been normalized.

[aritchie]

I can confirm the issue. Should be easy enough to fix. Thanks for the report.

As an FYI, issues don't need to be a full repro in terms of compiling a project from scratch, but they do need to contain a full registration=>discovery=>connect=>function so I can dump them into the device tests.

[TPitman-mindfiretechnology]

Would you like me to make an issue to track or just leave this as the documentation?

[TPitman-mindfiretechnology]

I have tested the latest nuget package 3.0.0-beta-0215 with your changes for this issue.

iOS and MacCatalyst work great now.

I am having an issue with Android now. I updated to the latest 'master' branch so I could debug again. On Android when it gets to the implementation of Extensions_Async.cs : WaitForCharateristicSubscriptionAsync the values for the uuids don't match here:

x.Service.Uuid: 000x0fe59-0000-1000-8000-00805f9b34fb
serviceUuid: FE59

x.Uuid: 8ec90003-f315-4f60-9fb8-838830daea50
characteristicUuid: 8EC90003-F315-4F60-9FB8-838830DAEA50

Believe me when I say I understand the complexities of trying to get both iOS and Android bluetooth working together. Both OSs have different formats for the Uuid values and how they handle them. Thank you for making this cross platform plugin.

[TPitman-mindfiretechnology]

If I change the Service Uuid to 0000FE59-0000-1000-8000-00805F9B34FB then it works on Android, but then doesn't work on iOS anymore.

I can deal with this as a compiler thing, but thought you would want to know.

[aritchie]

I haven't finished everything there. Other fixes sometimes force a push of updates. This is why you should really always create an issue.

[TPitman-mindfiretechnology]

Sorry to have jumped the gun. Thank you!

[aritchie]

No. I appreciate the testing. If you need tracking though or the case isn't as clear cut - please file the defect. For this issue in particular, providing a repro would have been difficult, so the explanation with the logs was more than sufficient.