Particle Mesh update — a note from the CEO

@picsil thanks for the heads up!

Every startup company has to pivot and make tough decisions sometimes. Particle could have handled this announcement a little better, but they haven’t lost my trust. I was already looking into mesh alternatives that better suited my application and had seen that the challenges Zach and team laid out were exactly what I was going to face. So fortunately I had nothing invested in mesh. But I do in Boron LTE. My thought is get to market quickly at a reasonable cost, and then optimize and scale from there.

At that point I will likely have to pivot. It’s part of building a business and I look forward to it, bumpy a road as it may be.


So not sure if anybody has asked this yet but is Particle planning on leveraging all that BLE 5 has to offer as far as BLE Mesh capabilities go?

Seems like the range is the same as the other MESH provided but on more stable Bluetooth foundation.

It would be nice to be able to have a Bluetooth Mesh capability for reading multiple mesh sensor nodes that would be within close proximity.

@will any info you can provide about BLE and your plans to maximize its features and usability into the future?

BLE on the Boron and Argons are allow me to create a nice solution to a widespread problem so I’m happy with the Gen3 product line.


@RWB I think I asked something very similar, but got no answer so far.

The possibility (BLE 5 capable hardware) is given, my main question is whether BLE mesh, or something similar will be officially supported or not. Timing is also critical for me, because I can not afford to wait for many months.

As far as I have heard - when I was lobbying for it - it’s not high on the priority list (if at all) and “definetly” not happening 2020.

However, if demand (an pressure for that) is high enough, reconsideration may (hopefully) be an option :wink:


Thank you @Scruffr, based on your comment, I’ve opened a new thread to discuss the BLE 5 Mesh support possibility, and reach some consensus, what we really need.

An immidiate discontinuing og the Xenon HW is a total no-no for IoT and’s own mission statement. Unless a replacement stock is in fact being kept for already launched products for at least a year, this is worth noting for future reference.


I wouldn’t pin any hopes on BLE 5 Mesh happening with Particle. The little talked about issue with any type of Mesh produce for Particle is how would they make money out of it - further development of BLE and NFC would be welcome but I am not expecting anything given the focus on cellular LTE and the solutions.

We don’t have any current plans to invest in BLE Mesh. We haven’t seen widespread adoption of BLE Mesh, and the early indications that we received when we researched it were that it wasn’t as robust as Thread.

We’re happy to see and respond to feature requests, and it is absolutely the case that our plans are based on customer demand, so @Attila thank you for opening your thread and we’ll keep our eye on it.

1 Like

Is there any chance that the Xenon devices will continue to be supported in Device OS if the device is connected to an Ethernet shield?

1 Like

We don’t plan to discontinue the Ethernet Featherwing and will continue to allow activations via Ethernet for all Gen 3 hardware.

1 Like

For the use case of having local communications among a group of Gen3 devices, please see the library just published:


So if I have an Ethernet Featherwing, then in 2022, I can take a brand new, never used Xenon out of the box, register it to your cloud service accessing it via ethernet, and program it via your web IDE, and access particle variables and functions and use particle.publish and .subscribe on it?

This should be good incentive for someone to write a BLE message relay library of some sort…

1 Like

So long as you are doing so with Device OS v1.6.X or earlier (the last Device OS release for Xenons) and have a Xenon in your possession (we will discontinue new production this year) we have no plans to prevent this at the Particle Cloud level.

1 Like

Take a look at this library that does the relaying of messages via a BLE Central device:


Well this is incredibly disappointing as the mesh functionality was great. To be quite frank, I really don’t see what issues there were with the mesh functionality. I purchased my Xenons and Argon specifically for the mesh networking and now all I have Xenons which will no-longer support OTA updates and a voucher for a fraction of the amount I spent. OTA updating is a core feature of your platform, the whole “it just works” thing.

Worse is that the Bluz project was ended specifically because of the mesh hardware you were releasing - You killed off the project which could very well have been your dedicated mesh team.

You say that customers using mesh are better served using bluetooth but the cheapest hardware you now offer for Bluetooth is the Argon at $27 - Nearly three times the cost of the Xenon at $11. I fail to see why we are being forced onto a more expensive line with less functionality just because some customers can’t use mesh over long distances or inside metal boxes. Surely a better option would have been to extend your mesh platform to support LoRa Mesh via a gateway device.


Thanks, I spotted that after I had already posted, and I’ve already starred the repo on Github. :slight_smile:

1 Like

I noticed early on that this was doomed to fail how it’s currently implemented, but I had hoped Particle would have changed direction with their implementation before giving up.

Trying to monetize and centralize the setup and management of a MESH network that may sometimes NOT have a central location was the mistake that caused the project failure, nothing else.

A few thoughts for those who perceive this announcement as a death-blow to their development process. I know this is hard to hear, but IMHO they’re doing us a favor by making us answer hard due diligence questions now, before we get in too deep.

If our business ideas are going to survive and thrive they cannot be dependent on a sole supplier who has yet to make a profit. Our due diligence should have highlighted this supply-chain risk right away, and we bear some responsibility for not fully recognizing this. Fortunately, Particle also has open-sourced everything, including the schematics, so things look a little differently than at first glance.

What the Xenon is losing is free future development of deviceOS, free cloud services, and cost at quantities of scale. If we have viable and robust business cases, then these aren’t deal-breaking value adds. Surely some of the investor money could go to producing a hardware run, or developing a proprietary cloud solution, or maintaining a fork of deviceOS.

Yes, this is inconvenient, but what would be really inconvenient is if Particle went out of business because it sacrificed itself on the altar of sunk costs. Because they’ve open-sourced everything except their crypto keys, they’ve gone as far as they can possibly go without bringing the whole thing crumbling down.

We’re right to feel wary, there are definitely some trust issues going forward. I image our investors would feel the same way if the biz they backed made-- and lost-- a gamble on an unproven technology. I imagine we would be much happier if our investors would give us the chance afterwards to rebuild the relationship rather than burn it to the ground.

Can we not extend to Particle the same generosity that we want to see from our investors?