I just published a library for Gen3 devices that helps with the use case of locally connecting a group of devices over BLE in order to publish/subscribe data faster/with less latency than going through the Cloud.
It is available in the library listing and can be installed with the name “BLE_Group”, and you can also find it here: https://github.com/particle-iot/ble-group-library
If I’m reading this correctly, this would basically be implementation of bluetooth mesh?
It doesn’t implement BLE Mesh, but a star configuration. One BLE Central, and the rest Peripherals, but the Central does relay the published messages coming from a peripherals to all the other peripheral (as well as “consuming” locally if the application has a subscription to the event).
Thanks for this! Are Gen3 devices capable of making more than 3 BLE connections? I thought I read that in a previous firmware release. I think at some point I’m going to be looking for a way to get a raspberry pi to act as a central for many devices, like Bluz used to do.
This sounds interesting.
I’ll dig in and report back.
Thanks for sharing!
Could be very useful mariano. Thanks!
The examples say Argon or Boron. Will it work on Xenon?
Yes, there is a limit of 3 links, so 4 total devices (1 central and 3 peripherals).
The BLE_Group publish/subscribe will work on Xenons, but the Particle.publish or other cloud functionality will not.
But you could use Xenons as peripherals and have the application on the Central (Argon/Boron) publish under it’s own ID.
If I remember correctly Particle was talking about increasing the BLE connection limit to something like 10 or 20 simultaneous connections vs the current 3 device limit.
@ScruffR Do you have any memory of seeing anything like that? I'm like 99% sure I did read it somewhere on here 
@mariano If Particle did increase this connection limit do you see any problem with your library being able to expand to handle 10-20 links vs 3?
Also the other question is about what drove you to create this library?
I can't say I did - but that doesn't mean it didn't happen 
The issue I can see is performance. The way the library works is that the Central device relays all messages to all peripherals, as each peripherals is keep track of event subscription from the application to run the callback. The more devices linked to the Central, the lower the throughput.
I created this library to help with the issue where a mesh is not necessary, but publish/subscribe capabilities among a group of nearby Gen3 devices is.
I doubt I would ever need 10 BLE devices connected at the same time but 5-6 sensor nodes I could see being useful.
I plan to add BLE sensors to my current device. It currently has three “onboard” sensor jacks for temperature, water leak, float switch, etc. In my head I was thinking that more than 3-4 BLE sensors would probably consume too much RAM given the other code I have. I’m happy with 3 BLE peripherals if that’s the limit, at least for my current application.
@mariano I would like to dig into the performance issue a little bit further - is the total processing time purely related to the number of peripheral devices i.e. O(n) or is there something else limiting the peripherals to 3 per central device? If the central device was an Argon/Boron and was acting purely as a gateway to Particle Cloud then the application could be fairly small. How does your BLE group handle sleeping peripherals?
The limit of 3 links is the limit on connections that Device OS has. As for sleeping peripherals, if the BLE radio goes away, it’ll be removed from the list (and will call the onDisconnect callback), and then if you scan, it will reconnect when it comes back.
So could you have a bunch of “sleepy” BLE peripherals and service them as they appeared ?
Yes, you could do something like that. Have the “sleepy” peripherals do a group->publish() in the onConnect() callback.
Probably want to stay away from having these peripherals subscribe to events, unless they are an immediate response to a publish, since they will miss anything that is published while they are sleeping.
I guess I didn’t ask my question clearly enough. The device OS has a limit of 3 but is there a specific technical limitation for this number?
The sleepy endnode part is easy to handle but requires a fast connection - is the BLE connection as fast as Mesh?
The limit of 3 is due to RAM limitations. To handle more connections, Device OS would have to allocate more RAM to the Bluetooth softdevice, leaving less for the application.
Understood and thank you for explaining that - it does beg the reply - couldn’t that be something/a parameter that could be changed via a Device API - if I have no need for BLE but want to have more RAM for a ML model then I set to 0 if I can do with less RAM and I need 5 or 6 BLE connection?