Boron + 5-Xenon Setup Questions

I have the following setup and running:

1 x LTE Boron
5 x Xenon

They are running the default tinker software, and I’m just letting these run to see how stable the connection is over time with this current firmware.

I have seen all the Xenon’s start flashing Cyan and Green at different times and sometimes they would stay in that state for a long time even though the Boron was breathing Cyan indicating it was connected just fine.

I’m assuming Tinker has all the devices running in an Automatic mode which causes all the MESH devices to start flashing Green if the internet connection from a Boron or Argon is lost?

How would I go about making sure the MESH network stays operational even if the Boron or Argons internet connection goes down?

Do I need run custom code to put the Xenon’s into System Threaded mode, so the loop still runs even when internet connection goes away?

This is new to me I just don’t want all the MESH endpoints to stop working because of a Wifi or LTE outage.

When I turn off the Boron, the MESH stays breathing cyan for around 5-10 mins and then it starts flashing Green and so far usually takes a while to reconnect after the Boron is turned back on and breathing Cyan.

Appreciate any help with this.


1 Like

@RWB, since all your devices are running tinker and are (by default) running SYSTEM_MODE(AUTOMATIC), all your devices are trying to connect to the Particle Cloud. When the Boron drops out, the Xenons will eventually lose the Cloud connection but not the mesh connection.

Cue the Mesh.publish() and Mesh.subscribe() functions. These are for intra-mesh communications allowing Xenons to keep communicating with each other (and the Boron) without the need for a Cloud connection. I have a Xenon/Ethernet gateway with a couple of Xenon nodes. The gateway runs in SYSTEM_MODE(AUTOMATIC) while the nodes are in SYSTEM_MODE(SEMI_AUTOMATIC) mode. The gateway uses a webhook to get a five day weather forecast and does a Mesh.publish() of a reduced set of data I filtered using a response template. One of the nodes is connected to a Waveshare 2.9b display. It does a Mesh.subscibe() to capture the weather data, parse it and display it nicely on the screen. Because of the mesh, I could have many of these nodes throughout the house subscribing to the weather data to display. One node might use a colour TFT or and OLED display.

I have another Xenon node which does a Mesh.publish() every 10 seconds are a heartbeat message. The node with the Waveshare also subscribes to this message and blinks the D7 LED every time it receives it.

Now, when the gateway no longer connects to the Cloud, I still get the mesh heartbeat blinking the LED. Mesh brings in new way to think about how you approach solutions and how you code them. It will take time for the mesh paradigm to sink in before we see cool projects.

1 Like

Thanks for that info!

That gives me a better idea of what I need to do to accomplish what I’m wanting.

MESH does require a good understanding of the new features to get the most from the technology and its benefits.

I love the heartbeat feature! Going to have to put that to use.

Have you tested range yet with and without external Bluetooth antennnas? Are external Bluetooth antennas available form Particle?

Since the High Avalibility MESH Network options are not available yet does that mean I can’t add more than 10 devices to a Network currently?

@RWB, mesh is not done using BLE! I haven’t seen an external mesh antenna. And yes, for now, HA meshes are not available so max 10 Xenons.

1 Like

I knew that, but forgot :blush:

Any word on when this may be released for larger projects?

I may need to find a way to link 10 unit MESH networks together that still work when there is no WiFi or Cellular. Thinking linking them together via LORA radios until the HA Networks are up and running reliably.

1 Like

@peekay123, in your setup, when the argon drops its internet connection does the argon continue to receive the mesh heartbeat? If left in default SYSTEM_MODE(AUTOMATIC), does that only apply to the WiFi connection or also to the mesh? How would one go about ensuring the mesh traffic is still received a and processed? Thanks for the insight so far. I too like the heartbeat idea.

When the Xenon’s start flashing and then going yellow real quick what is actually happening on the Xenon? Is it resetting completely or just trying to reconnect?

The Boron does not show that it has lost a connection to Particle and when the Xenons start flashing Cyan I can ping the Boron from the Particle Console and it instantly pings back as connected or reachable.

When I ping the Xenon’s when they are flashing Cyan they do not respond so they are not connected.

All 5 Xenons did reconnect a few mins after this video.

Just wondering why the Boron is connected and reachable while the Xenon’s loose their connection for some reason.

They are all running the default Tinker sketch.

They have mainly been connected breathing Cyan most of the time.

@ninjatill, I don’t use an Argon gateway as I had issues after an OTA. This has been raised with Particle. I have a Xenone/Ethernet gateway and a Boron gateway on another mesh. The heartbeat is not currently received by the gateway(s) but it will be easy to add and test later today.

1 Like

@RWB, I haven’t seen this with my Boron mesh but I only have a single Xenon connected to it.

1 Like

Folks, I have just tested a Xenon/ethernet gateway and single Xenon node with a heartbeat generated by the node. It is important to note that both are NOT running with SYSTEM_THREAD(ENABLED) and both have non-blocking loop() code design. The gateway and node are running my weather forecast code. The node has a single Particle.variable().

With the gateway connected to the Cloud, the heartbeat is sent from the node and appears on the gateway, indicated by a 1sec blink of the D7 LED (on the node as well). When I unplug the ethernet from the gateway, both the gateway and the node start to fast green blink but the heartbeat D7 LED blinks continue as before indicating the mesh is healthy. When I replug the ethernet, both the gateway and node come back online with the heartbeat still unaffected.

I will be doing a similar test my Boron gateway.


If you can share your code I will run the same test on a Boron LTE and 5 Xenons.

They are all breathing cyan now but one of them will not respond to Pings while all the others do. I had to manually reset the Xenon that I could not ping even though it was breathing cyan and it was pingabe shortly after that.

The Boron LTE looks to be pretty stable as it so far stays breathing cyan and so far has always been pingable.

The Xenon mesh network is flashing cyan frequently and usually takes a long time to recover, not as stable as I was hoping it would be.

Can you elaborate on this a little? Is the Argon usable as a gateway with its current firmware?

Most of today so far the 5 Xenons running the default Tinker program have remained in a flashing cyan state while the Boron remains connected and pingable the whole time.

Not very reliable or useable at this point.

All Xenons are about 15 feet apart from each other.

When all 5 Xenons are breathing Cyan they are not all pingable even though they are in a breathing cyan state and the Boron responds to pings instantly.

Hoping the next firmware update fixes this.

So, here is my simple Boron gateway/Xenon node heartbeat test code.



Note that I can query the variables on both devices successfully. I am working on getting the Boron to NOT be able to connect to Cell to see what happens to the mesh.

1 Like

I have 3 Xenons with 1 Argon as the gateway over wifi.

I was thinking the same thing as RWB at first, but now I realize that the blinking cyan means “I can’t see the internet cloud but I can see the local mesh”.

So Tinker will not work because it is using Particle.publish. But the Mesh.publish is working fine in the blinking cyan state. Doesn’t make sense that if the mesh network is working then it should see the internet but maybe it’s a bug or limitation. Blinking cyan versus Breathing cyan seems to correspond to the NFC reception. It’s easier to get breathing cyan if you’re closer to the gateway (but no guarantee). Also, the frustrating thing is you can only flash the Xenon when it’s in the breathing cyan state and even that is hit or miss…I have to hit the reset button to interrupt the running program and force it to check in with the cloud. One feature request would be to enable the gateway Argon or Boron to send firmware updates to the Xenons using mesh network if that makes sense or even better, update all the Xenon’s at once via the mesh.

I made a simple “heartbeat” program on each Xenon like this:

String name = "test";

String message = System.deviceID();
int led = D7;

void setup() {
  pinMode(led, OUTPUT);

void loop() {
    //Send a mesh publish "test" with device id as message
    Mesh.publish(name, message);

   //Toggle the onboard led
    digitalWrite(led, HIGH);
    digitalWrite(led, LOW);

Then the Argon listens for the “test” event and then publishes it to the cloud:

//Event listener for "test" event from Xenons
void myHandler(const char *event, const char *data)
//Cast char*data to String class
 String parse = data;
 String id = parse.substring(0,24);

//Parse the device id's to the actual names
 String name = "ERROR"
 else if (id.equals("put_your_device_id_here"))
 else if (id.equals("put_your_device_id_here"))
 else if (id.equals("put_your_device_id_here"))

//Publish to the cloud.
 Particle.publish(event, name + " says hello.");

void setup() {
  Mesh.subscribe("test", myHandler);

void loop() {

This is working great with blinking cyans. It doesn’t work with blinking green which I think means “I am looking for the mesh but can’t find it” and the program doesn’t run until it can find the mesh.

I was even able to send Mesh.publish events at high speed like every 20 milliseconds from one Xenon to the Argon. The Argon would flash it’s onboard led when it got what I called the “fast” event and I was impressed that it would keep up (with the occasional hiccup). At the same time, the Argon still captured the “test” event emitted by the other Xenons every 4 seconds and then would “retweet” that to the cloud.

The NFC range that I’m seeing is around 15 feet like someone else posted but when you overlap the meshes, I was able to extend the network from one end off my house to the other…like 60 feet. But if I wanted to reflash a Xenon, I would have to move it close to the gate way to get the breathing cyan.

I’m starting to realize that this Mesh concept is probably better suited for very specific scenarios and for a hobbyist like me, I’m better off sticking to Photons and wifi. You can still use a bunch of Photons and communicated between them without using the cloud. Also, wifi range is awesome with the built in antenna in the Photon versus the Mesh range of 15ft. Yeah I know the Mesh can be extended and heal itself but it takes a long time for the Xenons to join the mesh (5-30 seconds) vs the Photon connecting to wifi. The only advantage I see is Xenon’s lower power requirements and the mesh network if you don’t have wifi.

But to be honest, I’m still trying to wrap my head around the Mesh concept and I’m having fun experimenting with this.


I got @peekay123’s heartbeat code up and running on an Argon and a single Xenon. I modified the Argon code slightly to add a Prticle.publish() when it receives a heartbeat from the Xenon.

A few observations… I had to run the setup for the Argon several times and it hung up right after pushing the firmware update. After 2 failures, I went to the particle setup website to see if there was something there I missed. I stepped through the online setup until it said to run the mobile app. This time the mobile app flew through the setup and continued on to configuring the mesh network.

When I was flashing code to the mesh devices, it was way too easy to accidentally flash the Xenon code to the Argon and vice versa. It would be good if there was a compiler directive to not flash if the code is meant for a Xenon but flashed to an Argon.

The heartbeat code is great as there is no discernable latency. Perhaps I’ll connect a GPIO between the Xenon and Argon to measure the actual latency. Now to add some other endpoints and experiment with distance, fault tolerance, etc.

@ninjatill I tried Peekays code but it didn’t work right on 5 Xenons, I think his was setup for a single xenon.

Using tooyoon’s code you get a better idea which Xenons are actually online and reaching the Argon because you can see publish events for each Xenon in the Particle Console. Just put more space between publishes since they happen quickly with his 4 second delay when you have multiple Xenons.

What I see with 5 xenon’s is that most of the time one or two of the Xenons mesh publishes are not being received by the Argon and not being pushed to the cloud so you do not see them in the Published event list.

When my Wifi goes down the Argon starts flashing cyan but never automatically reconnects when wifi is back online like the Photons do and requires a manual reset to bring it back online. Try that for yourself and see if you experience the same thing.

In the image below you can see only 3 of the 5 Xenons are pushing data even though they are connected.

Also the Xenons loose their Particle Cloud connection a lot and take forever to reconnect and sometimes never reconnect without a manual reset.

I just quit trying to use the Particle publish feature on the Xenons and stick with the mesh sub pub features since they stay up longer. But still that is not stable for me either.

I took control of the Xenons LED to show solid green when Mesh.connected is True so I would not have to see the constant cyan flashing on all of them since they were constantly loosing the Particle Clould connection.

Let me know what you experience.


Yea I see that publishing the node names would be good. Maybe when I get more running I’ll tweak that so that the Argon waits until all 4 Xenon nodes report in before publishing. Perhaps the Argon can send out a mesh.publish to get all of the nodes synced on the same publish schedule. That would test possible mesh deadlocks. Like playing “Marco-Polo” in the pool.

I was curious about the network resiliency so I cut power to the Argon gateway. The Xenon kept breathing cyan for a long period of time. I waited until the Xenon went to blinking green which took about 2-3 minutes. When the Argon came back online to breathing cyan, the Xenon went to blinking cyan. As soon as the Argon was back up, the mesh heartbeats were received by the Argon and relayed/published to the cloud. But the Xenon is still sitting at fast blinking cyan with periodic red flashes. After about 3 minutes, the Xenon finally recovered to breathing cyan. It took about the same length of time that it took to go to blinking green after the Argon was purposefully powered down.

Pretty cool.


Yea the heartbeat just tells you at least one of the Xenons are online which is only half of the story.

I still only have 3 of 5 xenons working, a manual reset is required to bring the missing 2 Xenons back online.

I’ll be more than happy to test some of your code also when it’s ready.

There is. You can use PLATFORM_ID and throw an #error when you are targeting the wrong platform.

@RWB, if you are publishing an event from the Argon each time you receive a publish from one of your Xenons, you might be hitting the rate limit of 4/second since the outbound limit of the Argon against the cloud is still governed by that and is not increased to (4 * NumberOfMeshNodes) / second.
Also in case of congestion mesh publishes might get “queued” (retried) and the catch-up may run into the limit.