I've noticed something odd with the Xenon. A simple program that uses Particle.Publish is very reliable, but add a Mesh.publish and it quickly loses it's connection to the cloud. The Particle.Publish (w/ACK) will start returning false after awhile (~2min), though they will actually make it to the cloud for another few minutes before it starts blinking cyan and then nothing works. Oddly the Particle subscriptions, firmware updates, and function calls no longer make it through to the Xenon after that first failure (~2min). Happens on v1.1.0 as well as 1.2.1-rc.2.
Here's a test app to demonstrate the issue, it typically takes 2min for it to start showing up, regardless of publish interval. After you can reproduce the issue, comment out the Mesh.publish and try again and you'll see it remains connected.
Before boiling this issue down to that test app I tried numerous ways to get the Xenon to reconnect with no success. In v1.1.0 it still thought it was connected the whole time but with the latest 1.2.1-rc.2 firmware it can tell when it disconnects but can't fix the connection on it's own, no amount of turning on/off mesh/network/cloud has any effect. The only thing that works is a system.reset. A reset of the gateway Argon has no real effect, the Xenon will go offline and reconnect but publishes/functions/firmware updates will keep failing.
Well I’m both happy and sad to see you’re seeing the same issue as I was. Where there’s two now I’ve sent a message to support to see if they can look.
@Fragma can you still reproduce this? If so I might ask support to email you rather than me, as I’m not having much luck in reproducing it and they’d like to check some of their logs from when it’s happening.
That “input failed to alloc” is tied to the following line indicating a failure to allocate a packet buffer while processing input on the OpenThread mesh.
For the Xenon any Particle.publish() has to travel across the mesh and out through a gateway so a mesh layer failure would also impact Particle.publish().
Needs confirmation, but it looks like you have a pretty minimal test case that showing possible leak of packet buffers impacting mesh/cloud connectivity on the Xenon. Thanks for the report and I’ll make sure it gets to the right place.
Thanks for reporting this! I’ve managed to reproduce the issue. Please confirm whether you have other nodes within your mesh network doing mesh publishes. If so, a temporary workaround until we include the fix in one of the next releases is to add a dummy Mesh.subscribe() to any event. Without a single subscription we are apparently not reading the data out of the mesh pub/sub socket.
Thanks, I’ve confirmed adding a subscribe to the test program resolves my issue. I do have other devices on the mesh network and they already had a mesh subscription.
I have consistently seen the same results as originally described by Fragma using a number of Xenons with an Argon gateway.
I am using the recently updated Ubidots library to send data to Ubidots (ubidots.setCloudProtocol(UBI_TCP) through the Argon gateway (ubidots.meshLoop() every 20 minutes:
This does continue to work even after the Particle cloud connection is lost, and as Fragma describes, only a reset of the Xenon will resolve the issue temporarily.
I have tried the suggestion of a dummy Mesh.subscribe() without success:
Mesh.publish(“testVar”); on the Xenon, with Mesh.subscribe(“testVar”, myHandler); running the Argon.
There has been some improvement with the addition of pub-sub statements on the Xenon; however, the 4 Xenon’s I have running this code periodically start blinking madly and go off-line for a time, but are able to reconnect to the cloud. The Particle.publish statements did publish initially but no longer, and variables are not visible on the console. My simple code to collect data from a particulate matter sensor below. Thanks very much for your time and help!
Ubidots ubidots(TOKEN, UBI_INDUSTRIAL, UBI_MESH);
int once = 1;
int sendTime = 0;
int testVar = 0; //dummy variable for mesh pub-subcribe
int pulseCount = 0; // pulseCount is incremented with each interupt on D3.
int pulseSum = 0; // pulseSum is the # of pulses counted during the 20 second measurement period.
int measureTime = 0; // measureTime is the 20s measurement period specified in the data sheet.
void setup()
{
Mesh.subscribe("testVar", myHandler); //subscribe statement to dummy variable.
pinMode(D3, INPUT);
attachInterrupt(D3, count, RISING); // minimum pulse with is 0.5ms.
Particle.variable("pulseSum", &pulseSum, INT);
} // End set-up
void loop()
{
if (measureTime == 20) {
pulseSum = pulseCount;
measureTime = 0;
pulseCount = 0;
}
delay(1000);
measureTime ++; //inrement +1 each loop and count to 20 seconds.
//20 minute sample and upload cycle; changed to shift+1 one minute 7/21/2019
sendTime = Time.minute();
if ((((sendTime == 21) || (sendTime == 41)) || (sendTime == 1)) && (once == 1)) {
//will equal 20 until Time increments to 21
transmitdata();
Mesh.publish("testVar", String(testVar)); //mesh publish dummy variable to be received by subscribe statement.
delay(5000); //added delay as test 7/24/2019
Particle.publish("transmitdata ran", String(sendTime), 60, PRIVATE);
once = 0;
} //end upload 3 times per hour
if (((sendTime == 22) || (sendTime == 42)) || (sendTime == 2)) once = 1;
}//End main loop
void myHandler(const char *event, const char *data) // dummy handler function for mesh subscribe statement
{
testVar = atof(data);
Particle.publish("mesh pub-subscribe event", String(testVar), 60, PRIVATE);
}
// Interupt service routine.
void count()
{
pulseCount = pulseCount + 1;
} //End count function.
void transmitdata()
{
//send data through gateway via mesh/tcp to ubidots
ubidots.add("pulseSum", pulseSum); //type, format ??? Not a float value? Could this be an issue?
ubidots.meshPublishToUbidots();
delay(5000);
}//end transmitdata function