Would it be possible to build a mesh network from Xenons without a gateway (Boron/Argon)?
I’d like to sync up some lights, but I don’t have directly an interest on connecting that to the Internet.
With a Photon I’d do this by broadcasting UDP messages over WiFi.
That -will be- possible, and with the mesh.publish and mesh.subscribe, that should be relatively easy 
Thanks! Any idea’s of speed limitations regarding OpenThread?
I just got my four xenons and I didn’t get an argon or boron. However, it says I neet to select a mesh network and on other places on the forums people say I need a boron or argon to have them work. How would I use the xenons without a gateway??? How do I even set them up?
It seems I spoke too soon 
Yes, it’s not possible to set up a mesh network without a gateway at this time. Or a standalone Xenon without Ethernet.
You should have gotten an email warning about that, however. Everyone who ordered a problematic configuration, such as only Xenons without Ethernet or an Argon or Boron should have received a warning. Also LTE out of the United States.
Any idea why it’s not possible? I can understand that you can’t connect the Xenons to the cloud and use the online IDE.
However is it also not possible to use the CLI and use SYSTEM_MODE(MANUAL)?
At least that’s what I use now with some Photons, I don’t even let them connect to the cloud because I don’t have that need (of course I understand this appliance doesn’t serve Particle’s business model, but is it now actively blocked in the 3rd generation?).
It wasn't said that it won't be possible in future, but currently isn't implemented.
However, as you said, since it doesn't do a lot for Particle's business model decissions haven't been made whether or not to implement it at all, let alone when.
Also some thoughts that might not immediately come to mind.
If you have no dedicated gateway, which device needs to stay awake all the time to keep the network alive?
What if a node wakes and doesn't find a gateway or repeater, should it become a router and stop going back to sleep, till some other node takes over?
How would they negotiate who has to take the batton?
These are just a few of the questions the device OS needs to implement and APIs for the developers need to be created and documented. That'll take time and as long there are more important features to be implemented for "standard" networks with gateways, time will be spent better there IMO.
On the other hand, not having the ability to run Xenons as offline devices might just be an oversight on the mobile app side.
If you have no dedicated gateway, which device needs to stay awake all the time to keep the network alive?
What if a node wakes and doesn’t find a gateway or repeater, should it become a router and stop going back to sleep, till some other node takes over?
How would they negotiate who has to take the batton?
Interesting. So right now a Boron or Argon will keep the network alive I suppose.
Would it be necessary to connect the Argon to the cloud then in order to keep the network alive? Can I use the Argon as offline device (like I can use the Photon) and have it in a network with Xenons?
I noticed for my application I don't need the Cloud integration really much, but the option to make a small sync network is interesting. With the BBC micro:bit I use the Gazell network for this. I thought OpenThread was something similar.
Opinion warning
Argons, Borons and Xenons with Ethernet are by default dedicated as gateways and hence are (commonly) supposed to be awake “permanently” (so should router nodes) - but not necessarily cloud connected.
Since that is the perceived “common” use, that’s what was tested to release a Minimum Viable Product.
The network can “survive” gateway/router outages by default, but little testing has been done for all possible edge cases.
Anything beyond that may be considered work-in-progress.
You do need a gateway (Argon, Boron, or Xenon with Ethernet) to set up a network. This is the primary use case of Particle devices, and how the mobile app works. Without a gateway you can’t use any cloud feature, OTA code flash, etc…
It might (or might not) be possible to set up an entirely standalone network in the future, but you currently cannot.
However I just tested using a Xenon+Ethernet and 2 more Xenon and this code:
#include "Particle.h"
SerialLogHandler logHander;
void meshSubscriptionHandler(const char *event, const char *data);
const unsigned long MESH_PUBLISH_PERIOD_MS = 5000;
unsigned long lastMeshPublishMs = 0;
int meshPublishCount = 0;
char lastMsg[256];
void setup() {
Serial.begin();
Mesh.subscribe("meshTest1", meshSubscriptionHandler);
}
void loop() {
if (millis() - lastMeshPublishMs >= MESH_PUBLISH_PERIOD_MS) {
lastMeshPublishMs = millis();
char buf[256];
snprintf(buf, sizeof(buf), "%s: %d", Mesh.localIP().toString().c_str(), meshPublishCount++);
Mesh.publish("meshTest1", buf);
Log.info("mesh publish %s", buf);
}
}
void meshSubscriptionHandler(const char *event, const char *data) {
Log.info("subscriptionHandler: %s", data);
}
It uses Mesh.publish to do a mesh network only publish and subscribe (uses UDP multicast internally) and it works fine if I power off the gateway. The two remaining isolated Xenons continue to publish back and forth between each other.
Then if I power the gateway back on, it eventually rejoins the mesh and all three of them communicate again.
@rickkas7 @ScruffR Thanks for all the clarifications.
Is there some more low-level access to the nRF52 chip? Any pointers in the firmware?
In other words, can I use the Xenon just for the nRF52. I know Particle acquired Red Bear who previously offered nRF52 solutions.
Apart from the mesh, could I use the Xenon as a standalone peripheral (so for example connect my phone over bluetooth with the device).
Right now, it’s not practical to use a Xenon standalone, only with BLE, because it’s not really possible to set it up with the mobile app. And there is no BLE API for Particle system firmware, though one is planned.
However you could do that by creating custom binaries. The mesh system firmware is in the same place as the legacy devices: https://github.com/particle-iot/firmware but in the mesh-develop branch. You can create a monolithic build, containing both the system and user parts in one binary. The advantage of a monolithic build is that it has full access to the nRF52 soft devices and libraries so you can access pretty much anything the hardware supports.
Do you have any good resources to start with building firmware yourself and making a monolithic build?
I don’t have experience with this, but I’m always eager for some challenges and learn something new.
If you still have that simple Xenon+Ethernet/Xenon/Xenon setup around: Could you do the same test except turn off all the devices and just bring up the Xenons and see if they can still get organized with each other without the Xenon+Ethernet gateway?
A lot of ideas I want to cover with a mesh network do not have ready access to the cloud or even fully stable power (solar). If they did have both, I wouldn’t need the mesh network in the first place.
It’d be wonderful to know sooner rather than later so I can hopefully cancel my preorder before it ships and continue on with my now-quite-mature homebrewed approach.
As long as you add:
SYSTEM_THREAD(ENABLED);
the example above will work if you power on the Xenons without a gateway. They’ll communicate between each other just fine. You could probably also use SYSTEM_MODE(SEMI_AUTOMATIC) and only bring up mesh using Mesh.connect() as well.
I have the same problem and would like to know this too.
I did not receive such email!
I am very interested in this ability as I am getting good results with 3 Xenons when setup with an Argon but then turning the Argon off.
Using SYSTEM_THREAD(ENABLED); will that dramatically effect using the Argon? I would like both abilities. Works fine with the Argon can flash Xenons etc, but when the Argon is off the Xenons work fine locally. Any suggestions. I think I will just insert the code above and see what happens.
....
So I tried
SYSTEM_THREAD(ENABLED);
which did not seem to let a Xenon connect to working Xenons without a gateway. Note: for me once running with a gateway my Xenons are reasonably stable once the gateway has been turned off.
Xenons can be reset, but cannot power down and reconnect to the local mesh. Using threaded seems to offset the timing a bit. before all local devices blinked at exactly the same time, not using threaded they are offset a few microseconds
Will try
SYSTEM_MODE(SEMI_AUTOMATIC)
but I need to be able to connect to an Argon if it is available. Might try a 60 second delay to connect on boot.
A little scared to run this code in my setup using SYSTEM_MODE(SEMI_AUTOMATIC)
Mesh.connect();
delay(60000);
if (! Mesh.ready()){
Mesh.disconnect();
}
@rickkas7 any suggestions for code to try to allow the Xenons to wake without a gateway.
I added SYSTEM_THREAD(ENABLED); to my Argon gateway and if it stays connected an hour I consider myself lucky. If I add it to all the Xenon code, they’ll chug along fine with a breathing cyan, but could have been disconnected from the mesh and cloud long before. That was absolutely driving me mad thinking everything was ok, till I started using the serial log… I was seeing all bad things there.
I have one test mesh setup just trying to sync up clocks off of GPS periodically while passing some magnetometer data around. Keeping 3 Xenons connected took way more housekeeping than it should have.
I gave up on not having a gateway in the mix. (also gave up on thinking about any kind of reliable OTA update over the mesh).
I have a Xenon that hasn’t been powered up in nearly a week that is still showing up on the “devices” page with a breathing cyan. 