Feature Request - BLE 5 Mesh

Firmware
, ,
1

There are users (including myself) who need the mesh networking capability, despite the discontinuation of Particle mesh.

According to @ScruffR, currently, this feature is not on the roadmap at all, but if community push is big enough, they may reconsider.

Based on the recommendation of this post from @Moors7 I'd like to open a discussion, to clarify the details of this request, because I'm relatively new to mesh technology and the different protocols, which already exists, and could be ported into the Particle ecosystem. I'm not even sure, that BLE 5 Mesh is the right solution here. And if we can have a consensus we may file an "official" request through GitHub.

The current BLE documentation (https://docs.particle.io/tutorials/device-os/bluetooth-le/) states:

Particle devices do not support Bluetooth 5 mesh.

I propose to enable mesh networking over BLE, or any equivalent technology, which enables data transactions over local peer-to-peer connections, and through a gateway (Argon or Boron) to the cloud.

I know the limitations (range, speed) of BLE, and there may be more (e.g. max number of nodes, that can be handled by Gen 3 devices due to memory or other constraints).
I know, that this will not enable OTA firmware updates either. I agree that BLE is not ideal for every use case, but alternative "carriers" (off-board radio modules) are a different topic, so let's discuss that elsewhere.

As a starter I may live with the additional cost of Borons for every node during development, therefore I can update them (I have outdoor applications). If I get it stable, I can deactivate the SIMs, therefore there is no running maintenance cost for the nodes (apart from data overages of the gateway). And for mass production later I may use cheaper Argons with disabled wifi.

What do you think? Based on your recent posts, @RWB, @slacker89, @kubark42, you might be interested in something like this. I'd also like to know the opinion about the feasibility of the Particle developers, especially @will, because they know much better, what is the easiest, fastest, or most beneficial in the long run. For me, timing is also a concern, but I can live with initial limitations if Particle can commit to a clear end goal.

2 Likes
2

Yes BLE is very useful as far as short range & low power communication based on a pretty solid foundation.

I would love to see all the features for BLE 5 opened up to us is possible or where there are features that could be beneficial to creators.

I feel like the Xenons are still good lower cost options when you want a node that communicates over BLE that’s also fine being manually programmed over USB.

I’m left with needing a Argon instead which is fine but does cost more than the Xenon does when all I need is the Xenon to solve the problem.

Let’s leave the Openthread Mesh in the past and maximize the BLE functionality we have.

I’m not needing BLE MESH but having the ability to connect to and read from as many BLE sensors as possible just for maximum flexibility.

@will Are there any known BLE feature set work on the roadmap now that we have confirmed putting Openthread Mesh to sleep?

2 Likes
3

According to @zach

but:

Therefore it depends on our activity if this will be seriously considered. If only a handful of people joins, the chances are low, I'm afraid.

On the other hand, I have a pretty strong reason, why I think this is important for the reputation of the company too:

Many have criticized, that by shutting down Particle mesh, we were basically left alone: the proposed solutions, such as "Develop on OpenThread SDKs directly" or "Reprogram the Xenon with Circuit Python and Adafruit" means that we have to abandon Particle, the cloud, and roll out our standalone solutions. And currently, there is literally no built-in mesh functionality in the active product line (please correct me if I'm wrong).
I think it would look much better if Particle could say: yes, we abandoned THREAD for a multitude of reasons, but have an alternative mesh solution. Probably inferior compared to our dreams of "everything just works", but at least there is some degree of support.
And it's probably much easier and secure (means high quality can bee guaranteed) to provide certain mesh commands and leave all network management and firmware updating problems to the users. If I were Particle, I wouldn't totally exclude myself from the potential mesh "market" of the future.

I have to accept, that the company's focus is now on

But I think a gateway device for whatever local mesh is also in this target group.

1 Like
4

I really like the idea of a BLE Mesh, but as they’re not producing the xenon any more I’d probably end up going with another nRF52 board to get it.

The issue I see with Particle doing this isn’t so much the hardware support, it’s the backend. It still has all the issues like billing per node, how to push code to the BLE Mesh in a secure and reliable fashion, etc.

1 Like
5

Thanks for reacting this threat. I am interested in mesh in general because of reasons I posted in:

If I had to choose how we would do mesh I'd personally rather use 802.15.4 the reason being is because I am already using BLE for something else. Moreover, we have this extra radio that is now just sitting there doing nothing. But if I had no choice or nothing at all, BLE mesh will have my vote. It will now take me a bit of R&D of how to multiplex BLE for mesh and for other peripherals I am using.

My preference is still Mesh as a 3rd party particle library, espically since Particle has pretty done the work which to me, is good enough for prototyping and getting somthing to work. If not BLE Mesh is better than nothing. In addition, how Particle handles mesh (i.e. configurability/UI/pricing etc...), will be applicable regardless of technology whether its BLE/LoRa/ 802.15.4.

"Mesh is hard" any R&D into mesh will help mature so it is "not so hard" in the future.

1 Like
6

@slacker89, @Attila, I am personally happy with either direction. Mesh is the killer app in my case, because it lets my users install a sensor suite without consideration of placement or radio strength.

I don’t have any particular timing requirements, and so for my needs the solution is judged first and foremost by stability and time to develop. If I were a betting man, I would say that Mesh as a 3rd party library is probably easiest for Particle, since they don’t have to maintain it.

However, BLE mesh might be the better long-term bet if non-Particle devices can more easily join the mesh. The deprecation of Xenon is not just a mesh problem, but it also creates a low-end product void. In our case, in order to be vialbe we will need to find some kind of cheap BLE break-out board which has equivalently low power consumption. It’s possibly more likely products support BLE mesh out of the box than OpenThread, and that’s assuming that Particle hasn’t had to customize OpenThread in order to make it compatible with Mesh.

3 Likes
7

If my understanding of system architecture is correct, then Particle is not going to see the mesh nodes, especially if you relay your messages through your gateway via application code, therefore they can not bill for them. The cloud will only see the gateway, therefore you will be billed by "network" (or more precisely by every cloud-connected gateway).

I hope that Particle is not that greedy, to prevent BLE Mesh altogether, because they can not make money off of all nodes, only of the gateways.

I agree this will not be possible by basic BLE mesh commands, without the support of the device OS. This is one of the major weakness compared to the Particle Mesh solution.

8

Since the mobile app already contains a BLE update feature for first setup I have proposed to have that portion of the app broken out into a separate module/app which should also be usable on Xenons after their sunset.

No idea whether this proposal will ever be considered, but it’s worth asking anyhow.

3 Likes
9

I hear what you're saying, but I doubt you'll convince Particle of it. Even if they add some support for BLE Mesh I doubt they'll make the hardware for it.

I suggested in the Mesh Update thread that they continue producing the Xenons. They're a high quality nRF52 board, and as support for the nRF52 boards continues to grow they'll be useful for things exactly like you suggest.

They seem to have no interest in attempting to make money selling hardware though, and even very little interest in the 'hobby hacker' market. I was hopeful they'd be better ESP32 setup, and everyone and their dog would glue them to their dryer to get alerts when it finished.

Look at the previous discussions around billing for Mesh nodes though. I was happy to use mine only doing a Mesh.publish(), but there was no option to connect Xenon's to a mesh without backend support, and without (eventually) paying for it.

So while I'd love to see BLE Mesh support added at some point, it doesn't seem to fit with the direction they're going so I'm not holding my breath.

3 Likes
10

This isn't strictly about ble mesh but hopefully fits with this thread.

The Bluz DK and Bluz Gateway shield made it capable of connecting a BLE only node to the Particle cloud, including OTA updating the BLE board via the gateway. As I understand it, the Bluz DK was essentially (and ironically) a xenon that communicated over BLE instead of Thread. (not BLE mesh though, the Bluz had an nrf51822)

This was before Gen3 hardware so the Bluz gateway shield was necessary to add BLE support to a Photon or Electron. With Gen3 boards, you should have been able to skip the gateway shield and connect a Bluz DK to the cloud directly through an Argon or Boron. I say should because Bluz was considered to be superseded by particle mesh and was depreciated.

So now we are in a situation where Particle built xenons are less functional than the Bluz DKs which they superseded.

Additionally, the Bluz DKs could use a smartphone app as a pseudo gateway to the Particle cloud (pseudo because it didn't 'cloud connect' the end device to provide OTA updates, it just acted as a mitm to publish/receive event on behalf - I think) This would still be possible with a xenon and the Particle SDK however as you won't be able to register new xenons it won't be an option going forward?

If it was possible to combine the particle BLE update feature @ScruffR mentioned above with the Particle SKD to pass events to and from the xenon that would be a fully fledged gateway app akin to nrfcloud which I am sure there would be interest in.

Obviously the addition of BLE mesh would perfect, but for me, a star configuration capable of pushing updates to xenon nodes from a Boron (just like Bluz did) would be more than enough. To quote from the mesh depreciation thread..

sure there are a few (somewhat arduino compatible) nRF boards around but as far as I'm aware there's still not an OTA solution out there that matches up to the Bluz/Particle solution in terms of ease.

note - i never owned a Bluz so please correct me if I've got it wrong on anything above, thanks.

2 Likes
11

Just one clarification here. Each gateway we had for bluz (iOS/Android apps, gateway shield, and the raspberry pi solution) all provided full cloud connectivity to all connected bluz boards, including the ability to OTA update each board individually. Based on hardware restrictions in the nrf51822, it was actually slower to update firmware through the gateway shields and was much faster when using the iOS/Android apps. I believe the nrf52 addressed some of these concerns.

Ultimately, the underlying nrf51822 hardware of bluz sort of limited some of what we could do in terms of speed and number of devices connected to a gateway (which was a max of 6 for our hardware gateways, but theoretically unlimited for iOS/Android apps and the raspberry pi solution). It was hardware from 2014 which is pretty limited by todays standards in terms of processing power and RAM. When the gen3 particle hardware came out based on the nrf52, it addressed many of these concerns which is why we ultimately EOL'd bluz.

It seems there could be a software solution to utilize the gen3 hardware in the same type of format that bluz operated in, with better performance than bluz could produce. That isn't mesh, but would seemingly be possible to create star configurations of devices with OTA updates. Like bluz was produced as a third party add-on, I would think it is possible for this software solution to be created by the community.

8 Likes
12

Thanks very much for the clarification that's really interesting and even better than I thought.

It seems like Bluz had a special relationship with Particle to get devices registered in the cloud which might be a limiting factor for any 3rd party (including xenons) solution now?
Or is that still possible -

Am I missing something here? 3rd party devices can be registered on Particle?
does this still apply?

Edit : I realise I was being obtuse with the quote about LoRa, but connecting Argon/Borons to Particle using a LoRa add-on seems like a bit of an overkill - something that would be better suited to say... a xenon?

13

That would be a good question for the Particle team at this point. Yes, we were able to register bluz devices onto their cloud, as were a few other device manufacturers at the time. I don’t know if that policy has changed or not since then.

14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.