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:
As we move forward, these things will become available:
(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 
) 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.
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:
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;
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?