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:
https://community.particle.io/t/library-for-creating-a-local-group-of-devices-using-ble/54467
6 Likes
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:
4 Likes
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.
7 Likes
Thanks, I spotted that after I had already posted, and I’ve already starred the repo on Github. 
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?
15 Likes
You’re spot on, @kubark42. I’m building out the major cloud infrastructure on my own, so that I’m not tied to one single vendor and their platform. I understand that my goals and those of Particle don’t necessarily align, and we’ve had some discussions about that. I try to make reasonable choices and tradeoffs knowing that some tech in my stack probably will go away or end up not being viable. That’s already happened once with another IoT connected device startup company that I had to move away from. I was able to retool and redevelop with new hardware (Particle Boron).
I know the story of extremely quick time to market, simple development, etc. is enticing, but I am willing to take the longer road to build what works best for my company and use Particle and others where they best fit, and as a bridge while I develop my own stack. For example, I did just switch to using Particle Cloud, but only as a mechanism for OTA updates and getting data to my cloud. I will replace those tasks with my own code so I am not completely reliant on Particle as a platform. But for now it’s a good way to get MVP out in the field while I work on a more robust long-term infrastructure.
I don’t fault Particle for discontinuing Mesh development. To be honest, it was pretty tenous from the start. But regardless, this is the risk we all take when working on the bleeding edge of any tech. Some things succeed. Some things don’t. It’s how we adapt that makes the difference.
6 Likes
Are particle going to open source the hardware design for the Xenon? then we can build our own…
You mean this - which was availble all allong?
yep - that’s awesome, good on particle, if you are desperate for them you can build your own!
…or you could use this
https://www.adafruit.com/product/3406 - same base chip and Arduino IDE compatible
Nope, not quite the same.
Particle Gen3 is based on the nRF52840 thist Adafruit device is based on nRF52832.
However, Adafruit also has nRF52840 based devices.
1 Like
I agree!