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.

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

BLE devices names inconsistent between Linux & Windows #73

Closed
corentinbettiol opened this issue Jun 12, 2019 · 5 comments
Closed

BLE devices names inconsistent between Linux & Windows #73

corentinbettiol opened this issue Jun 12, 2019 · 5 comments
Assignees
Labels
Backend: BlueZ Issues and PRs relating to the BlueZ backend Backend: pythonnet Issues or PRs relating to the .NET/pythonnet backend Opinions Appreciated Please add an opinion on your desired resolution on this issue!

Comments

@corentinbettiol
Copy link

  • bleak version: 0.4.2
  • Python version: 3.7.3
  • Operating System: Windows 10 & Xubuntu 19.04

Description

When launching discover function on Linux, we get a list of devices. And if the device name is unknown, it is replaced by its address.
On Windows however, the names are just "Unknown".
Will the output be the same in the next version ? Or is it a normal behavior ?

image

The Windows "Unknown" problem seems to be located here:

e.Advertisement.LocalName or "Unknown",

@hbldh
Copy link
Owner

hbldh commented Jun 24, 2019

It is not a problem per se, but an effect of how the OS specific systems work.

If there is no Name property in Ubuntu/BlueZ I use the Alias property:
https://github.com/hbldh/bleak/blob/master/bleak/backends/bluezdbus/discovery.py#L39
This is as good as it gets there; if no Alias exists either, than Unknown is set.

On Windows on the other hand, there is nothing else than LocalName and if it does not exist there is nothing else I can do.

For the discovery method I aim to be consistent on the platform, so that discovery via other OS native methods give similar results to Bleak gives.

@hbldh hbldh self-assigned this Jun 24, 2019
@dlech
Copy link
Collaborator

dlech commented Jun 24, 2019

I observed the same thing on Windows. Even though the device has the proper advertising data (confirmed by using nRF Connect on Android), the Windows Bluetooth stack does not seem to get the name from this for some reason.

@hbldh hbldh added Backend: pythonnet Issues or PRs relating to the .NET/pythonnet backend Backend: BlueZ Issues and PRs relating to the BlueZ backend Opinions Appreciated Please add an opinion on your desired resolution on this issue! labels Jun 24, 2019
@hbldh
Copy link
Owner

hbldh commented Oct 9, 2019

I do not think I can do anything more in regards to this issue. Closing it.

@hbldh hbldh closed this as completed Oct 9, 2019
@dlech
Copy link
Collaborator

dlech commented Oct 9, 2019

I was wondering if #99 might fix this, but I haven't had a chance to try yet.

@hbldh
Copy link
Owner

hbldh commented Oct 9, 2019

I have little hope of fixing the difference problem, but I think I see an improvement in the Windows discovery, albeit not enough that I feel comfortable saying that this is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backend: BlueZ Issues and PRs relating to the BlueZ backend Backend: pythonnet Issues or PRs relating to the .NET/pythonnet backend Opinions Appreciated Please add an opinion on your desired resolution on this issue!
Projects
None yet
Development

No branches or pull requests

3 participants