aioble server - what is the correct way to handle 'silent' disconnect?

[lievenleroy]

In the aioble lib server examples, there is an expectation that a connected client will explicitly disconnect (so the server knows to advertise again). But that's not always the case, the client can crash or sleep. In that case, the server never starts advertising again and cannot be discovered again. (Short of resetting the device.)

        async with await aioble.advertise(
            _ADV_INTERVAL_MS,
            name=ADVERTISED_BLUETOOTH_NAME, # "mpy-temp",
            services=[g_uuid_service],  # [_ENV_SENSE_UUID],
            appearance=_ADV_APPEARANCE_GENERIC_THERMOMETER,
        ) as connection:
            print("Connection from", connection.device)
            await connection.disconnected()
            print("Disconnected from", connection.device)

I've tried watching for presence of a client using aioble.indicate() and a timeout for response. But restarting advertising based on that generates internal aioble errors. Is there a better way to do this? Thanks!

[jimmo]

@lievenleroy MicroPython listens for the host stack's "central disconnected" event, which happens regardless of how the host stack realises that it's disconnected (e.g. explicitly or because it's timed out etc). So I think what you're describing means that the host stack (NimBLE) thinks the connection is still active.

I guess the first thing to confirm is that we are indeed not receiving a disconnect event from the host stack. If you're able to put a custom version of aioble's peripheral.py onto the device, then can you add a print to _peripheral_irq to print out something. e.g.

def _peripheral_irq(event, data):
    ...
    elif event == _IRQ_CENTRAL_DISCONNECT:
        print("disconnect", data)  # Just add this line, keep everything else the same
        ...

[lievenleroy]

Hello @jimmo . Thank you for the suggestion! Apologies for my slow reply.

I ended up working around this with:

            async with await aioble.advertise(
                _ADV_INTERVAL_MS,
                name=config.ADVERTISED_BLUETOOTH_NAME, # "mpy-temp",
                services=[g_ble_uuid_service],  # [_ENV_SENSE_UUID],
                appearance=_ADV_APPEARANCE_GENERIC_THERMOMETER,
            ) as connection:
                print("Connection from", connection.device)
                # await connection.disconnected()
                while connection.is_connected():
                    await uasyncio.sleep_ms(500)

This is not ideal, but it does allow me to recover in the scenario I was running into with await connection.disconnected().

If I get time to test your suggestion, I will report back. Thanks again!

[brianreinhold]

I would like to add that in many (most) health device situations it is the server/peripheral that is expected to disconnect. The client remains connected as long as the sensor device has data to send. The client has no idea when measurements will stop. The device could be a streaming pulse oximeter or a real time activity monitor. Communications need to handle both situations.