aioble - multiple connections to a peripheral?

[ser]

How can I have temperature service from aioble examples available for multiple connections?

https://github.com/micropython/micropython-lib/blob/master/micropython/bluetooth/aioble/examples/temp_sensor.py

Currently when there is a connection, the peripheral stops announcements - I want it to NOT stop and serve concurrent clients.

[jimmo]

Roughly you need to do something like:

async def server_task(conn):
  ...

async def peripheral_task():
  while True:
    conn = aioble.advertise(...)
    asyncio.create_task(server_task(conn))

[gooostaw]

Do you know if this is possible on Raspberry Pi Pico W? It didn't work out for me. I wonder if it's a hardware limitation. When the connection is created, advertising ends and other devices do not detect the peripheral.

[ser]

Thanks for explanation, but I believe your code misses necessary await, it should be:

async def server_task(connection):
  print("Connection from", connection.device)
  await connection.disconnected()

async def peripheral_task():
  while True:
    connection = await aioble.advertise(
            _ADV_INTERVAL_MS,
            name="mpy-temp",
            services=[_ENV_SENSE_UUID],
            appearance=_ADV_APPEARANCE_GENERIC_THERMOMETER
    )
    asyncio.create_task(server_task(connection))

This works correctly for me. Thanks again!

[jimmo]

Ah yes, definitely.

Note that there is a limit to the number of concurrent centrals connected (I believe this is 4 for NimBLE on PYBD and WB55, and 3 on ESP32) -- so you might want to do something clever to handle this.

[ser]

I'm really curious what do you mean by "something clever" :) As far as I can understand my other option is to broadcast temperature as Eddystone beacons without need of connection - nearly unlimited amount of clients can listen to that broadcast in such solution. Am I correct and do you have any other ideas than Eddystone beacons?

[jimmo]

Oh I just meant to prevent the loop from advertising until there are fewer than N active connections.

The general idea of broadcasting the data in the advertising payload is common and I actually have some temperature sensors in my house that do exactly that. Not Eddystone specifically but the idea is the same. https://github.com/pvvx/ATC_MiThermometer

[brianreinhold]

In my experience peripherals which connect tend to allow only a single connection - especially medical devices that are concerned about HIPPA requirements and the protection of personal health data. For these devices, a single bonded connection to a client is typical. An environmental sensor, on the other hand, seldom has such requirements and the simplest solution is to broadcast the data in the advertisement for whoever wants to receive it. Programmatically, its a lot simpler to support broadcasting of data than multiple connections to clients. There are a lot of other issues as well if you peripheral supports features like setting the time, the frequency of delivery, RACP transfers/data deletion, etc. It gets messy.

However, if you want to do it, clearly after the connection your device has to re-advertise and centrals already connected to your device have to ignore those advertisements (while its rare for peripherals to support multiple simultaneous connections to centrals, it is quite common for centrals to support multiple simultaneous connections to peripherals).

So if your multiple-connection-peripheral has problems working with a central that might be the reason. The central likely did not consider protecting itself from such peripherals.