I am facing a similar issue which appears to be related. I have a crappy device that after it disconnects it continues to send trailing connectable advertisements but when a connection attempt is made, the device simply does not respond. Its advertisements also cease. Eventually the connection attempt times out, but the system remains 'connected' in some sense and the system is corrupted. If I take a measurement with another device that is known (a bonded reconnect) I get EINVAL 22 errors all over the place. If, instead, I try and connect to the original device that had the trailing advertisements I get a connection event in the aioble event handler but nothing further happens. The only recovery is to reboot that application.

I think I have found the reason for the issue and the solution. When the connection attempt times out, aioble fails to cancel the ongoing connection. If you then make tour device discoverable again, the connection will complete (the IRQ gets handled) but there is no longer any support for it so it goes nowhere. If you try to connect with another device, when aioble calls the ble.gap_connect() method it is already established for a different device and you will get EINVAL 22 errors like crazy.

I was able to solve the issue by calling ble.gap_connect(None) which does a cancel at the low levels in the device.py file

        try:
            if exc_type == asyncio.CancelledError:
                # Case 2, we started a timeout and it's completed.
                if self._timeout_ms and self._timeout_task is None:
                    ble.gap_connect(None)  # Cancel ongoing connection
                    raise asyncio.TimeoutError

I am assuming this timeout get signaled ONLY when the connection attempt times out.

• About ble.gap_connect(None):

  Since DeviceTimeout is used in read/write/notify/indicate for timeout, it is better not to call ble.gap_connect(None) in device.py. It may not have a negative effect, as it only cancels the connection attempt. However, it is better not to run it.
  As ble.gap_connect() is only called in one place in central.py, you can limit the extent of its effect by running ble.gap_connect(None) nearby.

# https://github.com/micropython/micropython-lib/blob/master/micropython/bluetooth/aioble/aioble/client.py#L253

        with self._connection().timeout(timeout_ms):

• About "device._connection = None":

  At the moment I am not sure that it is correct to clear _connection directly in the exception handler as described above. Do you have a better idea?

I would like to be able to call the cancel connect on the timeout of the connect attempt, but it was not clear how to do that. I could not find a way to identify the cause of the timeout so I handled it in the timeout. So far it solves the problem I have and has not introduced a problem.

How would I do this?
you can limit the extent of its effect by running ble.gap_connect(None) nearby.

I could not see how to do it in this block of code

with self._connection().timeout(timeout_ms):

which is where I would really like to do it.

Sorry for the poor explanation. (I use a translator.)

Call ble.gap_connect(None) in the exception handler as follows.
# ble.gap_connect() is only executed at this location, so it is better to execute ble.gap_connect(None) near here.

# https://github.com/micropython/micropython-lib/blob/master/micropython/bluetooth/aioble/aioble/central.py#L107

async def _connect(
    connection, timeout_ms, scan_duration_ms, min_conn_interval_us, max_conn_interval_us
):

                << Omitted >>

    try:
        with DeviceTimeout(None, timeout_ms):
            ble.gap_connect(
                device.addr_type,
                device.addr,
                scan_duration_ms,
                min_conn_interval_us,
                max_conn_interval_us,
            )

            # Wait for the connected IRQ.
            await connection._event.wait()
            assert connection._conn_handle is not None

            # Register connection handle -> device.
            DeviceConnection._connected[connection._conn_handle] = connection
#     except:
    except asyncio.TimeoutError:
        device._connection = None   # Clear connection.
        ble.gap_connect(None)       # Cancel ongoing connection.
        raise
    finally:
        # After timeout, don't hold a reference and ignore future events.
        _connecting.remove(device)

In the following, the DeviceTimeout class is used to show where ‘read’ starts the timeout.

with self._connection().timeout(timeout_ms):

In the code below, gap_connect(None) is called on a 'read' timeout.

        try:
            if exc_type == asyncio.CancelledError:
                # Case 2, we started a timeout and it's completed.
                if self._timeout_ms and self._timeout_task is None:
                    ble.gap_connect(None)  # Cancel ongoing connection
                    raise asyncio.TimeoutError

I statically analyzed the code and found the same issue. There's a missing gap_connect(None) after timeouts. I can make a PR?

Yes, please create a PR.
I've never done PR.
I was wondering what to do.
Thanks.

The company I worked for folded so I am not doing this anymore and have gone back to meteorological research vs Bluetooth health devices. I will say that the fix I used has worked and has not caused any unwanted side effects in operation.

Some other issues you might want to look at in this PR is better handling of disconnects from the remote peer. There needs to be a more direct connection between aioble and the application to assure that the application does not try to do something as if connected when in fact it is disconnected. As it is know, by the time the application gets signaled of the disconnect the application can try and do something that it should not do in the disconnected state. That will cause catastrophic failures in aioble. I had to create an application 'global' that was set in aioble in the disconnect callback. The application would use this variable to check the connection state instead of the aioble APIs.

The other big ticket item is pairing/bonding support. It does not exist for the PICO-W. We had to do a lot of low level work to support bonding and bonded reconnects using the BlueKitchen btStack. We could not operate with many medical health devices without it. In this task one needs to consider

• peripheral security requests
• insufficient authentication errors

which are handled differently in the btStack (unfortunately). The btStack handles the security requests internally (but the application does not know it so you have to add code to tell the application that pairing/encryption has happened). The btStack does not handle the insufficient authentication error and that needs to be passed up to the application so it can invoke pairing/encryption

• pairing passkeys also need to be supported.

The question was more for the maintainers I don't want to make a PR if they're overwhelmed already.