Particle Mesh update — a note from the CEO

I switched from Pycom products to Particle. For me they were not stable (hardware or firmware), were expensive, and had terrible LTE support. The community is pretty stale too. Pycom seems more focused on their PyLife consumer products now. Unless some other bomshell announcement is made, I’m sticking with Particle at least until I have a product that’s selling very well, at which point I may develop my own modules. Particle is still the best and shortest path forward for me at this point.

EDIT: Few other reasons I switched to Particle: No OTA system or user firmware support. Extremely buggy modem firmware. Devices that would simply stop working in the field and not come back online. DOA hardware straight from Pycom, and no response to several inquiries to customer service to get an RMA for them.


@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.