Particle Mesh Devices and OpenThread Connections in Anticipation of Google Breaking Changes

Particle Mesh Devices and OpenThread Connections in Anticipation of Google Breaking Changes

What is the plan when Google Nests OpenThread platform finds a security issue that needs to be corrected? They do what Google does best and make breaking changes to their platform, like what recently happened with the Google Product, Tensorflowjs .

How will Particle respond to that? The Particle Mesh Platform is based on the Nordic nrf52840 chip which is opensourced at OpenThread.

Anyone with that nrf52840 chip would then download a new Border Router with the corrected code and re-install corrected software to their chips and be up and running reasonably quickly.

But Particle has an Experimental Cloud Border Router instead of the on-site Border Router that OpenThread was designed to work with. Breaking changes will put Particle into a difficult situation: continue with their out-of-date product with the security hole, or upgrade to the new OpenThread that breaks the Particle System.

Easy solution: Particle releases a barebones version of the nrf52840 platform on OpenThread specifically designed for the Particle Mesh Devices, that would allow Particle Owners the choice to use a local Border Router and to install barebones software to their Mesh Devices while waiting for Particle to fix the breaking changes. Businesses need to be able to tell their customers they have backup plans ready and in place. People need to be able to design these backups now.

In a smaller way this is probably PART of the problem with the Particle HA Mesh Networks. OpenThread has probably changed from what worked 12 months ago when the Mesh Devices were being planned. Breaking changes are a matter of fact when working with Google Products. I have been simplifying Machine Learning Examples since 2015 and about every 3-6 months Google creates breaking changes while improving their products. The latest change to Tensorflowjs (see link above) has made obsolete my 78 Deep Learning examples. Over the last several weeks I have updated 33 of them ( ). That is just how it works when using Google Products.

In many ways the Particle Photon is more stable than the Mesh Devices since Particle has made all the software that the Photon needs and does not rely on software from an outside source.

Let’s get our hardware working by beginning able to connect to OpenThread. Remember that connecting to OpenThread is not a big problem for Particle, it is the natural ability that the Nordic nrf52840 chip was designed for.

At the very least, let’s talk about the issues.

If you are interested in OpenThread abilities for your Particle Mesh Devices email me at or follow me at twitter or message me at github


Particle already has a method of updating the OpenThread part of the DeviceOS. If you take a look at the notes in this DeviceOS update post from Feb 19, there is a quote:

  • [Gen 3] OpenThread updated to 20190130 master with the fix for negative clock drift between HFCLK and LFCLK (#1684)

The OpenThread includes in the DeviceOS github are located here:

Are you concerned that Particle will not incorporate security fixes fast enough?

1 Like


I think this image says it all.

I just think that open-source Particle Devices using open-source OpenThread should allow users, who paid money for the hardware, to be able to use the devices like all the other hardware that runs OpenThread.

I would expect in the “openthread/examples/platforms” folder an entry that says “particle” and how to install the software on our Particle devices. Once again “Like every other main platform that runs OpenThread” see above images and links.

I don’t agree with your insistence that Particle must allow you to use their hardware in a way they did not intend it to be used. Or, perhaps that is the wrong wording. They do allow you to use their hardware in any way that you choose since both the hardware and software are open source. You can certainly modify it to suit your needs. Perhaps I should say that I don’t agree with your insistence that Particle must redesign their software and business model to suit your specific needs.

I suppose you can keep prodding as Particle might very well be leaning towards more open compatibility with other OpenThread vendors and products as business opportunities arise… but I feel compelled to voice the counterpoint.

The OpenThread was updated 2 months ago (8 months is missleading because those are templates, examples, etc.). There should be another minor and major release in the next few weeks. Maybe ping @avtolstoy to see if they included the latest security fixes.


I would love to talk with someone from Particle about this issue but @will has stood me up twice claiming tech issues with the calendar.

I have shown this link before but it is kind of relevant here, since Particle is Thread Certified.

Certification indicates to customers that your product is fully Thread compliant, and that it works with other Thread products. Product certification is required to ship a product based on OpenThread, and to claim that a product supports Thread.

I will keep prodding, I teach my students that persistence is really important when learning to Computer Program. I will keep requesting more open compatibility with other OpenThread vendors because that is kind of the point of the "Internet of Things"

Normally I do just quietly solve my computer programming issues on my own, or let my 100 students parallel process to solve the issue. Amazing what 100 students all working on the same problem can solve, but I like Particle. So that brings up the question, why I am taking the diplomatic route on this issue? Why spend all this time writing posts. Why would I request that Particle release methods to connect with OpenThread?

Why not just do it myself, I like a challenge?

I also like to fact-check Particle. I did a few times during the Mesh launch and now I’m in a position to talk with Particle weekly on the Gen 3 Community Council. I cannot find where Particle touts “Thread Certification”. All references I see, on their main Mesh Page, to Thread say “Build on Thread” like this:


Any assumption that they should be openly compatible with other Thread products is inferred. The link you posted to says that the Nordic Semiconductor nRF52840 is a “Thread Certified Component”… it doesn’t say anything about an end product using a nRF52840 chip. Furthermore, the certification for the OpenThread Border Router (OTBR) only applies to the Raspberry Pi 3B which uses an nRF52840. But you already wrestled with this concept in another post:

That’s a selective quote on my part, but for a reason. The second half of the quote I take as a completely separate point:

I take the above as 2 separate, distinct points… one about gaining access to intellectual property (IP)… and the other about what certification means. While Particle may have accomplished gaining access to IP they do not seem to have sought or completed certification. Which makes sense from a business perspective. They were making a (private) ecosystem of IoT devices that communicate over a local network, not a Nest thermostat accessory. Thread provided a technology framework they didn’t have to create from scratch.

If you do find Particle touting Thread Certification please let me know and I will gladly call them out on it in person.


Wow @ninjatill you might be correct. Particle might not be Thread Certified! Not sure if that is a positive that they want everyone to know about. I will keep looking, but this page talks all about Google Nest and OpenThread but never actually mentions that Particle is Thread Certified. Koodos to the Particle advertising department. I sure fell for that trick.

My understanding was that anyone can use openThread as it is openSource but only Certified users could Advertise it as using Google Nest OpenThread. That criteria my have changed.

Anyone from Particle want to clarify that the Particle Mesh Devices are a (private) version of OpenThread and not a certified version.

Doesn’t change my resolve to connect Particle to OpenThread just changes the tactics.:slightly_smiling_face:

1 Like

You might want to mention to Particle that just having the Thread Emblem on their main page creates a bit of advertising confusion, unless it is followed with a very clear. “Particle Mesh is not Thread Certified.”

Another issue is the actual BSD license at

A permissive license similar to the BSD 2-Clause License, but with a 3rd clause that prohibits others from using the name of the project or its contributors to promote derived products without written consent.

I assume even though Particle might not be thread certified that they have gone through the process of getting written consent.

Hey there @rocksetta,

To start,

there are things that I really appreciate about the way you are contributing to the Particle community. Among them:

  • The fact that you are an educator! You are using your skills and interests to inspire your students and teach them how to build and create things.
  • You are both a participant and a contributor to the Particle community. You are providing tips, guidance, and feedback, which benefits Particle and other members of the community. I am thankful for that!

It is also clear that you have a strong desire for Particle to build in out-of-box compatibility with other OpenThread routers and devices to serve your personal use case. You are using this thread, and other threads like it as a means of providing the same feedback in more and different ways to try to compel the same outcome.

It is also clear that, regardless of the response we provide to any particular argument, you will not be satisfied until we have delivered the functionality that you’re seeking. This is evident by your comment in this post:


I would also like to share that I feel extremely frustrated by your approach to providing that feedback. Rather than simply vocalizing a clear use case and need, you are creating narratives that suggest that Particle is compelled to develop our product in the way that serves your personal interests:

1. By suggesting in this thread that we would have a limited or decreased ability to provide a secure product.

As Ninjatill pointed out, we have the ability to upgrade OpenThread within our Device OS, and part of our value proposition to our customers is handling with breaking changes from technology vendors like Google, and to abstract them to the greatest degree possible to our customers.

This is not true – the Photon depends on the WICED Wi-Fi SDK from Cypress which is a proprietary networking stack. Mesh represents a net improvement in our ability to provide a transparent networking stack to our internal developers and customers for troubleshooting and improvements. It should be easier, not harder, for us to provide a stable experience on OpenThread in the long term.

2. By suggesting that, by using OpenThread itself, we are compelled to provide a maximum-flexibility user experience

As I have already stated, our use of OpenThread does not compel us to provide any particular user experience to our customers. Nest’s most recent products (Nest Cam, Nest Secure, Nest Hello) all ship with OpenThread. Their use of OpenThread does not compel them to provide any particular experience other than the usage that is made available to customers through the interfaces that they provide.

3. By suggesting we are in violation of IP grants by not providing a happy path for connectivity with other OpenThread hardware

Not going to dive into this one, since I addressed it in another thread, here.

The problem

with these narratives is that they:

  1. Can be inaccurate or misleading, to the detriment of the Particle
  2. Are occasionally not in accordance with first rule of etiquette in these forums that applies to every single member of these forums.

From here,

We are both aware that we have a separate PM discussion going on where I’ve offered my time and availability to hear your feedback and share more about our product roadmap for our Mesh offering. Though we’ve had trouble coordinating on schedule, the offer continues to stand. You have clear next steps (including my personal email and a link to my calendar) for doing so.

As a company we are very much open to product feedback, but do not feel as compelled to respond to it when it is presented in this way.