Mesh Solution Architectures

I am considering building some products on mesh/3rd gen and would love to know if there are any solution architecture models / recommended practice / etc. that I could be pointed to?

My products are most likely to be based upon mesh networks of Xenons with (at least) one acting as a gateway and connected to the internet through an ethernet featherwing/equivalent. Argons as the gateway device is also possible, Boron less likely, as the environment is office/within a building.

Right now we don’t have anything like what you’re seeking. For now, here’s how things work:

  • You can have one gateway on a mesh – Argon, Boron, or Xenon/etherwing board
  • Only Xenons can be endpoint/repeaters
  • Xenons are always endpoint/repeaters. Open Thread supports having a given node be one or the other, but that’s not yet available in the API

As we move forward, these things will become available:

  • Multiple gateways on a mesh. However this is considered “high availability”, and will require a paid subscription
  • Argons and Borons will be supported as endpoint/repeaters
  • You will be able to designate any of the devices as an endpoint OR repeater

(My understanding is that repeaters can never sleep, BTW.)

I can’t really think of any “best practices”; I believe that as long as you have all of your mesh nodes within range of at least one other node, and you don’t try to put 1000 devices on the same mesh, things should “just work”. (I don’t believe we’ve characterized the max # of devices on a mesh, but I think it will be in the double-digits due to the limited memory space of the devices where mesh data is stored.)

Thanks for the reply. In the meantime I read the blog articles Particle Mesh 101 and 102. I have also gone through the OpenThread Org primer. Practically, at the moment, I would like to understand how a SED (Sleepy Endpoint Device) is going to be supported by the Particle Device OS presenting API calls to OpenThread. I expect that most endpoint devices will be battery powered and will need to sleep and wake on a timed or interrupt basis (sensor signal or user button press). So if they are to be sent information/commands from the Cloud there will need to be some sort of store and forward mechanism at the gateway (not part of the Device OS). Repeater devices will need to be powered continuously - and I see these as being networking only with no application. Positioning of these repeater devices to ensure a solid mesh network with within number of nodes will require some sort of console tool to present the IPv6 addressing and the RLOC?

An indication of what Particle believes it will deliver in future and what it considers application developers will need to provide would be a good start?

Currently we only know that this will be supported, but due to the currently missing implementation of any sleep mode the implementation of the dependent topics has to wait for that.
Hence we don’t yet know which OpenThread APIs will be accessible - let alone how (i.e. the “Wiring” function call declaration).
(while some options may be available already in some of the development branches, none have been locked down to be exposed for public use)

Not sure, but I’d expect the device OS will actually keep that transparent for the user app and share the work load between gateway and repeaters.
IIRC there should also be hybrids (i.e. repeaters and/or gateways with application tasks).

But all of the above is based on what I’ve heard from Particle, but an official confirmation (or correction if I misinterptreted :blush:) would be good.

@ScruffR Really appreciate your ‘insider’ view. I am a little surprised that the Particle Product Managers aren’t able to give an indication of the desired objective - surely the mesh development is being directed by an overall plan with prioritised requirements?

Sorry, but there I have to contradict.
It’s not inabillity or unwillingness but (IMO) that there are sooooo many open questions and addressing them all at once won’t work for several reasons.

  • You first need to become aware of the question
  • You need to prioritise many questions
  • You need to think up the answer
  • You need to wrap it in understandable language and still keep it concise, friendly, focused and not open more questions than you answer
  • You need to type it all out
  • You still need to respond to other topics you have already answered and now have created more questions (despite above point)

I don’t know if you have noticed how many posts @Will has just recently made, but there you see his commitment.
Maybe this thread here hasn’t been on his radar yet (it’s only 3 days old and your question I “answered” above just 2 hours).

As I see your question, it’s primary target is a topic that is a few steps ahead of the current state of development of the firmware and as such a bit premature for definitive answers.
But I agree, the general intent would be to reiterate (I’m pretty sure it was already outlined in the past but might have become covered over with the other noise).

Yup, exactly. The overall plan has to be somewhat generic, hence definitve questions won’t be directly addressed but implicitly guided by that.
So the hard task is to know when to specify what detail and how to communicate it where.


Hey there, just dropping in on this thread.

@armor, I appreciate the questions you’re asking and understand why you are asking them. Some of these topics are ones that we’ve considered to a greater degree than others, but all of them are on the path to building Particle Mesh into an enterprise-ready suite of development tools.

It sounds like your primary questions are:

  • What sleep modes will be available for Gen 3 devices (specifically, how will we implement the concept of a “sleepy end device” in our firmware APIs per the OpenThread spec)?
  • How will messages from the Cloud be queued and forwarded to such devices?
  • What network topology or administrative tools will be available to support Particle Mesh deployments?

I’m happy to be as transparent as possible but am hesitant to communicate associated timelines for delivery until we’re a bit further along with setup reliability and basic network stability.

If you’re curious, please send me a PM, and we can transition the conversation to PM or email to discuss our early thoughts on the questions above. If you have feedback as to how you’d like to see those features manifest in our Device OS and Console, we’d be happy to hear from you!

cc @jberi


In our application area, unattended and battery powered end sensor nodes are a common requirement. Hence a sleepy end device functionality is essential. Some edge computing by a line powered gateway for the mesh network is envisioned as the appropriate architecture as well. I can believe that integrated support of the sleepy end device support on the Particle Mesh platform is a matter of “when” and not “if”??


In trying to address @ScruffR reply about being more specific in my questions, I have been doing a bit of reading and looking at OpenWeave - this is the open source version of Weave which if I understand it correctly is the application layer from Nest that sits on top of Thread. This appears to provide some of the basic services I am looking into how to support. In OpenWeave these are called Profiles. Some of these services are already provided by the Particle API but how they might work with Sleepy End-node Devices is less clear;

  • Software Update (OTA flash of offline device will fail, not clear how console/product firmware update will work).
  • Data Exchange (I am assuming either a message data load or a function data argument - OpenWeave supports larger file exchange).
  • Echo (Ping from console. Gateway device to SEDs?)
  • Time Service
  • Time Zone

Others I guess will need to be built - it would be nice to know if this sort of thing is on the development roadmap/backlog?

  • Heartbeat (since UDP does not reliably indicate if still connected or not)
  • Status Report (Diagnostics message?)
  • Locale (country, language, etc.)
  • Network Provisioning
  • Schedule
  • Alarm
1 Like