Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Device name changes not reflected in connect to known device #541

Open
GerryWilko opened this issue Sep 26, 2021 · 12 comments · May be fixed by #792
Open

Device name changes not reflected in connect to known device #541

GerryWilko opened this issue Sep 26, 2021 · 12 comments · May be fixed by #792
Labels
os:iOS

Comments

@GerryWilko
Copy link

Thank you so much for this fantastic repo. I have been using it for many years throughout my University career it is really excellent!

The issue I am having is related to a scenario where a peripherals Name is changed in between when it was first seen by the stack and now.

The following logs demonstrate the issue. The device was first seen as InfiniTime. Then I DFU it to my custom firmware. Its new name is then reflected as InfiniTime-295456 (serial number now included in the name). I then proceed to use ConnectToKnownDevice to connect to this peripheral. At which point the BLEDevice's Name is returned as InfiniTime (last line in the incompatible exception). I use the name to determine compatibility for this particular device as it is difficult to otherwise test its compatibility.

Initiating DFU for InfiniTime <534787d6-a4de-e0d1-7d6d-3389135311c9> ...
2021-09-26 22:08:44.225 ActiveBand.Sync.App.iOS[14269:3600102] ADVERTISED: InfiniTime-295456 <> -66 (-100)
2021-09-26 22:08:44.226 ActiveBand.Sync.App.iOS[14269:3600102] InfiniTime-295456 <> ...New!
2021-09-26 22:08:44.227 ActiveBand.Sync.App.iOS[14269:3600102] InfiniTime-295456 <> ...Discovered
2021-09-26 22:08:44.228 ActiveBand.Sync.App.iOS[14269:3600102] InfiniTime-295456 -- MAC address not visible adding to interrogate queue.
2021-09-26 22:08:44.282 ActiveBand.Sync.App.iOS[14269:3600267] InfiniTime-295456 -- Interrogating device.
2021-09-26 22:08:45.462 ActiveBand.Sync.App.iOS[14269:3600266] InfiniTime-295456 <FBD2E8295456> -- Serial discovered.
Fail: Failed to vibrate device (FBD2E8295456) with error -- ActiveBand.Comms.Exceptions.DeviceIncompatibleException: Device InfiniTime is unsupported by this library.

Note: There is often little we can do without a minimal reproducible sample of the issue, so please provide that in a standalone git repository and link it here.

Unfortunately its difficult for me to provide a replication repo for this issue as you need to attempt this with a bluetooth peripheral that can change its name.

Steps to reproduce

  1. Scan for a peripheral, don't connect just yet, observe the device.Name

  2. Change the name of the peripheral (on the peripheral itself, this may be hard to do on some peripherals). Observe that the peripheral advertisements are now showing the new name.

  3. Connect to the peripheral using the ConnectToKnownDevice function.

  4. Observe that the device.Name on the returned connected device is the old name not the new one.

  5. Restarting the application corrects this issue.

Expected behavior

I would expect the device returned after connection to be the latest peripheral not a cached one. Looking in Adapter.cs this seems bizarre as the peripheral is pulled out of the CBManager again each time unless I'm misreading it.

According to this issue the peripheralDidUpdateName will be fired when the name changes but this seems irrelevant as the peripheral is not connected during the name change. The DFU process is also not even using the Plugin.BLE stack so its not like its some weird instance based cache or something.

Actual behavior

Peripheral device.Name is not reflecting new device name.

Configuration

Version of the Plugin: 2.1.2

Platform: iOS 15

Device: iPhone 12 Pro

If anyone has any ideas or some pointers that might set me on the right path that would be great. I'm happy to raise a PR but debugging the stack my side I can't see what's wrong. It just seems that the CBPeripheral is wrong.
@smsissuechecker
Copy link

Hi @GerryWilko,

I'm the friendly issue checker.
Thanks for using the issue template 🌟
I appreciate it very much. I'm sure, the maintainers of this repository will answer, soon.

@janusw janusw added the os:iOS label Apr 12, 2022
@sisaacks
Copy link

was this ever resolved????

@tiwari-kajal
Copy link

Facing the same issue, but in iOS 16 version.

@janusw janusw mentioned this issue Aug 5, 2023
Open
@janusw
Copy link
Member

janusw commented Aug 5, 2023

@GerryWilko @sisaacks @tiwari-kajal Could anyone of you check whether PR #711 makes a difference for this issue?

@janusw janusw mentioned this issue Oct 4, 2023
Open
@baneageorge
Copy link

@janusw Thank you for your work. We do have the same problem and tested with nudget 3.0.0.rc.1 but it doesn't seems to solve this issue.

Tested with:

  • iPhone 11 - iOS 15.3.1
  • iPhone 6 Plus - iOS 12.5.5

Please note that this is not reproducible on Android

I am just putting here our steps to reproduce this

Device name is: UpdC1
StartScan
Advertised Name returns -> UpdC1
ConnectToKnownDeviceAsync | Connected name -> UpdC1
Disconnect

Device name is: DeviceC1
StartScan
Advertised Name returns ->  UpdC1
Advertised Name returns ->  DeviceC1
ConnectToKnownDeviceAsync -> Connected device name returns -> UpdC1

The following would avoid this bug in our case

Device name is: UpdC1
StartScan
Advertised Name returns -> UpdC1
ConnectToKnownDeviceAsync -> Connected device name returns -> UpdC1
Disconnect

Device name is: DeviceC1
StartScan
Advertised Name returns ->  UpdC1
Advertised Name returns ->  DeviceC1
StopScan
StartScan
Advertised Name returns ->  DeviceC1
ConnectToKnownDeviceAsync -> Connected device name returns -> DeviceC1

If you have any directions we are happy to help with test/debugging.

@janusw
Copy link
Member

janusw commented Dec 28, 2023

We do have the same problem and tested with nudget 3.0.0.rc.1 but it doesn't seems to solve this issue.

Any particular reason you're testing with 3.0.0-rc.1 at this point, and not the final version 3.0.0? (The two are almost identical anyway, so it shouldn't make much difference ...)

3.1.0-beta.1 probably also behaves the same way, I assume?

If you have any directions we are happy to help with test/debugging.

It would be very helpful if you could test PR #711 and tell me whether it changes the behavior you're seeing. There is a nupkg generated as an artifact of the CI build. You can download this and set up a local folder as a package source in VS, in order to use it.

@baneageorge
Copy link

@janusw Sorry, I miss understood your comment, I had impression that the 3.0.0-rc.1 includes the PR #711.

I now added the 3.0.0-rc.1-2-ge03790e nuget locally but unfortunately the same behaviour persists. Just to be sure, I also cleared project before and also uninstall the app but no success.

The same happens also with 3.1.0-beta.1.

@janusw
Copy link
Member

janusw commented Dec 29, 2023

@janusw Sorry, I miss understood your comment, I had impression that the 3.0.0-rc.1 includes the PR #711.

No, the PR has not been merged yet, thus it is not part of any release so far. Sorry if I was not clear about that.

I now added the 3.0.0-rc.1-2-ge03790e nuget locally but unfortunately the same behaviour persists.

Too bad. This means that PR #711 does not work. Thanks for checking, though.

@janusw
Copy link
Member

janusw commented Dec 29, 2023

Actually I mentioned a second idea for fixing the problem in #703 (comment). I can create another experimental PR for this, hoping that you can test it, @baneageorge.

@GerryWilko
Copy link
Author

Just my two cents but from my testing after raising this issue this actually appears to be an issue in CoreBluetooth. I found several issues with native stacks that seemed similar. There did not appear to be an easy way around it. LightBlue also seemed to suffer from the same issue for example.

In the end we customised the firmware on the device to add a characteristic for the device name separate to the standard device service. I could then manually query this service for the device name.

It appears that CoreBluetooth caches the device name and there doesn't seem to be a way to bust this without force quitting the application. Re-creating a CBManager doesn't work either.

Unfortunately without being able to do something like what I did (Query some other charac to provide the same information you want from the device name), you may be out of luck.

Thanks again for the fantastic work the maintainers are doing on this repo.

@janusw janusw linked a pull request Dec 29, 2023 that will close this issue
Open
@janusw
Copy link
Member

janusw commented Dec 29, 2023 •
edited

Just my two cents but from my testing after raising this issue this actually appears to be an issue in CoreBluetooth. I found several issues with native stacks that seemed similar. There did not appear to be an easy way around it.

Thanks for the comment, @GerryWilko. That's useful information.

Nevertheless I now opened PR #792, in order to check the second clue we found. Based on @baneageorge's descripton in #541 (comment), I have some hope that this second PR might fix (or mitigate) the problem he describes. I'd be grateful if anyone of you guys could take this PR for a test drive and tell me whether it changes any of the behavior you observe.

Possibly there might be multiple variants of similar or related issues lurking here ...

@janusw
Copy link
Member

janusw commented Feb 22, 2024

Does the same problem also occur when using ConnectToDeviceAsync, or only with ConnectToKnownDeviceAsync?

I think the problem may be due to the DiscoveredDeviceRegistry not being updated properly ...

@janusw janusw mentioned this issue Mar 23, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
os:iOS
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

iOS.Device: update device name upon connecting to peripheral janusw/dotnet-bluetooth-le
6 participants
@janusw @GerryWilko @baneageorge @smsissuechecker @sisaacks @tiwari-kajal