Henrik Blidh

There should be more specific exceptions thrown, I agree. But in you application, it must be possible to narrow the scopes of your try-catch blocks to catch what happens in...

I am pretty sure there is no such thing available in the dbus api for BlueZ. At least there wasn't when Bleak was written. It is regrettable that bluetoothctl is...

There is no timeout capability in the `dbus-next` library that Bleak uses, but one could possibly use a `await asyncio.wait_for(self._bus.call(...), timeout=5.0)` (See [Python docs](https://docs.python.org/3/library/asyncio-task.html#asyncio.wait_for)) to stop waiting for a reply....

Maybe that would do the trick. I was content with the `protection_level=1` as a start on Windows. It is not good enough, but it points the way for future expasion...

Forcing a `BleakClient` to forget its device information received from previous scanning is preferable from a Bleak maintainer standpoint, but when you are a user you would like it to...

The board you have, it is a MetaMotion R board? You are sure that it supports sensor fusion data? I have not experienced this particular problem, but I know that...

@how-chen I will make some investigations into the matter during this week. Will get back to you on this.

@how-chen If you are still interested in trying to resolve this issue, I have just released a new version (v0.11.0) of metawear which uses a different BLE library for communication....

This library is no longer up to date with Metawear's releases. The latest release is tailored for metawear==0.7.0, everything else will probably not work. I can not provide any meaningful...

I wanted to keep the notifications method as similar to the other modules as possible, but it breaks possibility to handle the different signals separately. I will have to restructure...