Description
PR #390 introduced a change to how peripheral names are formatted to discovery observers on platforms using Core Bluetooth. Unfortunately, this change introduces a non-standard format for the name, which consequently introduces inconsistency within the btleplug library. I'd like to explore how to address this inconsistency and ensure a better experience for end users across platforms.
Expected behavior
Wherever possible, btleplug should behave consistently across platforms. When a peripheral is discovered, the name should be predicable as much as possible, regardless of whether the discovery is being performed on Windows, macOS, or Linux. In cases where that isn't possible (due to underlying limitations in the host BLE stack, for instance), the behavior should match what is provided or documented by the platform - unless otherwise justified.
On Apple platforms that provide the Core Bluetooth framework, the name property is well-documented and the behavior is predictable:
A peripheral may have two different name types: one that the device advertises and another that the device publishes in its database as its Bluetooth low energy Generic Access Profile (GAP) device name. If a peripheral has both types of names, this property returns its GAP device name.
During discovery, the local_name property of a peripheral should be consistent, and its underlying source should be documented. Ideally, the library would be capable of providing both the broadcast name, as well as the GAP name, making it the responsibility of an integrating application to determine what end users see (or how the applications behaves on behalf of users).
Actual behavior
However, the current implementation of btleplug changes this behavior, instead doing extra work to format a name that presents both of these values. While this might be useful during development, it is problematic in production scenarios where these names are shown directly to end users.
The specifics of our current situation are related to a device name change after a firmware update. Our application can deal with receiving an old name (which is what Core Bluetooth reports as the peripheral.name) as well as the new name (which is inside the advertising data). Unfortunately, neither of those is provided to the discovery event. Instead, we receive a string formatted like this:
Old Name [New Name]
Additional context
The current implementation was introduced to address name inconsistency with a particular device. I would suggest that this issue was more likely an implementation detail - or possibly a bug - within that specific peripheral.
However, a reasonable enhancement to btleplug would be to provide both of those name values during the discovery process. I suspect that may have been a workable path forward in that situation, as well as others (like mine).
I'm happy to provide either:
- feedback/discussion on a potential changes to the
PeripheralPropertiesstruct to support both names (and potentially an implementation for at least Windows and Core Bluetooth). - a PR that reverts the name change logic introduced in fix: make local_name in corebluetooth more descriptive #390
Please let me know if there's interest in pursuing either of these approaches, or if there's another path forward you'd prefer. My current preference is the first option, but I might not have enough context outside of my own use case right now.
I'm happy to try and support where I can. Thanks!