Enable notifications without going through the callback system?

[JensRestemeier]

• bleak version: 0.22.2 (whatever pip installs right now)
• Python version: 3.12.5
• Operating System: MacOS/Windows

Description

I am trying to communicate with a device that uses a CH9141K BLE to serial bridge to connect user applications. It looks like it requires the host to enable notifications before it starts sending data over BLE.

What I Did

queue = asyncio.Queue()

async def callback(x,data):
    await queue.put(data)

await client.start_notify(uart_receive_uuid, callback)
while True:
      message = await queue.get()
      # stuff
await client.stop_notify(uart_receive_uuid)   

This works fine, though I'm wondering if I can just somehow enable notifications without registering a callback, and then use

message = await client.read_gatt_char(uart_receive_uuid)

to just process messages as they arrive in a loop?

[dlech]

It depends on the characteristic. If the characteristic supports reading, then sure, just read in a loop. If it doesn't, then notifications is the only way.

[JensRestemeier]

service_explorer.py reports:

2024-09-06 17:44:09,395 __main__ INFO: starting scan...
2024-09-06 17:44:09,598 __main__ INFO: connecting to device...
2024-09-06 17:44:11,162 __main__ INFO: connected
2024-09-06 17:44:11,163 __main__ INFO: [Service] 0000180a-0000-1000-8000-00805f9b34fb (Handle: 14): Device Information
2024-09-06 17:44:11,222 __main__ INFO:   [Characteristic] 00002a23-0000-1000-8000-00805f9b34fb (Handle: 15): System ID (read), Value: bytearray(b'\x13\xdey\x00\x00\x10S\\')
2024-09-06 17:44:11,252 __main__ INFO:   [Characteristic] 00002a24-0000-1000-8000-00805f9b34fb (Handle: 17): Model Number String (read), Value: bytearray(b'CH9141')
2024-09-06 17:44:11,282 __main__ INFO:   [Characteristic] 00002a25-0000-1000-8000-00805f9b34fb (Handle: 19): Serial Number String (read), Value: bytearray(b'190420000000')
2024-09-06 17:44:11,312 __main__ INFO:   [Characteristic] 00002a26-0000-1000-8000-00805f9b34fb (Handle: 21): Firmware Revision String (read), Value: bytearray(b'VER1.0')
2024-09-06 17:44:11,342 __main__ INFO:   [Characteristic] 00002a27-0000-1000-8000-00805f9b34fb (Handle: 23): Hardware Revision String (read), Value: bytearray(b'VER1.0')
2024-09-06 17:44:11,372 __main__ INFO:   [Characteristic] 00002a28-0000-1000-8000-00805f9b34fb (Handle: 25): Software Revision String (read), Value: bytearray(b'VER1.0')
2024-09-06 17:44:11,402 __main__ INFO:   [Characteristic] 00002a29-0000-1000-8000-00805f9b34fb (Handle: 27): Manufacturer Name String (read), Value: bytearray(b'WCH')
2024-09-06 17:44:11,432 __main__ INFO:   [Characteristic] 00002a50-0000-1000-8000-00805f9b34fb (Handle: 29): PnP ID (read), Value: bytearray(b'\x019\x07\x00\x00\x10\x01')
2024-09-06 17:44:11,432 __main__ INFO: [Service] 0000fff0-0000-1000-8000-00805f9b34fb (Handle: 31): Vendor specific
2024-09-06 17:44:11,462 __main__ INFO:   [Characteristic] 0000fff1-0000-1000-8000-00805f9b34fb (Handle: 32): Vendor specific (read,notify), Value: bytearray(b'')
2024-09-06 17:44:11,493 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 34): Client Characteristic Configuration, Value: bytearray(b'')
2024-09-06 17:44:11,522 __main__ INFO:     [Descriptor] 00002901-0000-1000-8000-00805f9b34fb (Handle: 35): Characteristic User Description, Value: bytearray(b'UART DATA')
2024-09-06 17:44:11,523 __main__ INFO:   [Characteristic] 0000fff2-0000-1000-8000-00805f9b34fb (Handle: 36): Vendor specific (write-without-response,write), Max write w/o rsp size: 197
2024-09-06 17:44:11,553 __main__ INFO:     [Descriptor] 00002901-0000-1000-8000-00805f9b34fb (Handle: 38): Characteristic User Description, Value: bytearray(b'BLE DATA')
2024-09-06 17:44:11,598 __main__ INFO:   [Characteristic] 0000fff3-0000-1000-8000-00805f9b34fb (Handle: 39): Vendor specific (read,write,notify), Value: bytearray(b'')
2024-09-06 17:44:11,642 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 41): Client Characteristic Configuration, Value: bytearray(b'')
2024-09-06 17:44:11,672 __main__ INFO:     [Descriptor] 00002901-0000-1000-8000-00805f9b34fb (Handle: 42): Characteristic User Description, Value: bytearray(b'BLE CONFIG')
2024-09-06 17:44:11,672 __main__ INFO: [Service] 0000ffe0-0000-1000-8000-00805f9b34fb (Handle: 43): Vendor specific
2024-09-06 17:44:11,672 __main__ INFO:   [Characteristic] 0000ffe1-0000-1000-8000-00805f9b34fb (Handle: 44): Vendor specific (notify)
2024-09-06 17:44:11,732 __main__ INFO:     [Descriptor] 00002902-0000-1000-8000-00805f9b34fb (Handle: 46): Client Characteristic Configuration, Value: bytearray(b'')
2024-09-06 17:44:11,762 __main__ INFO:     [Descriptor] 00002901-0000-1000-8000-00805f9b34fb (Handle: 47): Characteristic User Description, Value: bytearray(b'UART DATA')
2024-09-06 17:44:11,762 __main__ INFO:   [Characteristic] 0000ffe2-0000-1000-8000-00805f9b34fb (Handle: 48): Vendor specific (write-without-response,write), Max write w/o rsp size: 197
2024-09-06 17:44:11,807 __main__ INFO:     [Descriptor] 00002901-0000-1000-8000-00805f9b34fb (Handle: 50): Characteristic User Description, Value: bytearray(b'BLE DATA')
2024-09-06 17:44:11,808 __main__ INFO: disconnecting...
2024-09-06 17:44:11,809 __main__ INFO: disconnected

The characteristic I need to connect to is 0xFFF1. This is a relatively "dumb" device that forwards data from a serial connection to BLE, and from BLE to a serial connection. Processing is done by a separate microcontroller that doesn't know anything about Bluetooth.
The device doesn't start forwarding data to BLE until the other party subscribes to notifications.

So this is pretty much a documentation question: Am I missing something, can I subscribe to notifications without a callback? Or is a callback with a queue the "proper" solution?

[dlech]

Or is a callback with a queue the "proper" solution?

If this is being used for serial data and you don't want to miss any notifications, yes a callback queue is the "proper" solution.

... at least for now - see related feature request: #1501

[JensRestemeier]

To resolve this: my workaround is to create an async context manager to manage the queue and callback:

class NotifyWrapper:
    def __init__(self, client):
        self.queue = asyncio.Queue()
        self.client = client

    async def __aenter__(self):
        async def callback(sender: BleakGATTCharacteristic, data: bytearray):
            await self.queue.put(data)
        await self.client.start_notify(uart_receive_uuid, callback)

        return self

    async def read(self):
        message = await self.queue.get()
        return message
    
    async def __aexit__(self, exc_type, exc, tb):
        await self.client.stop_notify(uart_receive_uuid) 

This is for a command line utility that just temporarily connects to a BLE device. For a desktop application you probably want to register a callback for the lifetime of the application, as the existing examples show.

BTW, this is the project: https://github.com/JensRestemeier/research-WLS-MVAxxx
That seems to work well enough for my tests, key goal was to connect from a custom application to do long term monitoring and logging. (Not sure if I keep this device, or build a custom solution. )