I have not had any luck getting the Boron to work in SEMI_AUTOMATIC or MANUAL modes. If I do anything other than full AUTOMATIC, the Boron simply never connects to the cloud. Same thing happens if I try to enable SYSTEM_THREAD (which is actually recommended). In full AUTOMATIC mode it is cycling pretty well. The connection time is not as good as it could be coming out of sleep. I get the following messages consistently from the system debug:
0051925415 [gsm0710muxer] ERROR: The other end has not replied to keep alives (TESTs) 5 times, considering muxed connection dead
0051943932 [comm.protocol] ERROR: Event loop error 3 0051943933 [system] WARN: Communication loop error, closing cloud socket
0051943936 [system] ERROR: Failed to load session data from persistent storage
It hangs at the first message the longest if I remember correctly. Tried searching for Event error loop 3 but didn’t find any clear definitions for what that means yet. The last error regarding session data was reported to be not really an error on one forum post I found.
Performing a System.reset immediately after waking up makes the connections very fast and with no errors but I think we would give up the ability to batch-update readings overnight as the persistent data storage for the readings is in RAM.
In full auto mode, we won’t have a way to not startup the radio each time as that would happen automatically - no more preserving the batteries overnight.
I work with wests on this project as the software help and I found the source of the issue - looking for suggestions to workaround the problem. I have 4 Particle.subscribe() handlers setup and connected to Webhooks. If I comment out any one of them so I only have 3 or fewer handlers, the Boron will connect successfully to the cloud in SEMI_AUTOMATIC mode. The fourth breaks it. From the Boron documentation: NOTE 1: A device can register up to 4 event handlers. This means you can call Particle.subscribe() a maximum of 4 times; after that it will return false.
/*
* Project boron_issue
* Description:
* Author:
* Date:
*/
#include "Particle.h"
// System threaded mode is not required here, but it's a good idea with 0.6.0 and later.
// https://docs.particle.io/reference/firmware/electron/#system-thread
SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC); // setup() and loop() run immediately. Use Particle.connect() to start cellular connect.
// setup() runs once, when the device is first turned on.
void setup() {
delay(2000);
Serial.begin(115200);
Serial.println("Hello World");
// Put initialization like pinMode and begin functions here.
// Particle.subscribe("a", test, MY_DEVICES);
// Particle.subscribe("b", test, MY_DEVICES);
// Particle.subscribe("c", test, MY_DEVICES);
// Particle.subscribe("d", test, MY_DEVICES);
Particle.subscribe("hook-response/GS-subscribe", test, MY_DEVICES);
Particle.subscribe("hook-sent/GS-publish", test, MY_DEVICES);
Particle.subscribe("hook-response/GET-xmlsetup-dropbox", test, MY_DEVICES);
Particle.subscribe("hook-sent/GS-batchPublish", test, MY_DEVICES);
}
// loop() runs over and over again, as quickly as it can execute.
void loop() {
if (!Particle.connected()) Particle.connect();
}
void test(const char* event, const char* data) {
Serial.printlnf("%s: %s", event, data);
}
The code above will never connect to the cloud. Swapping the commented sections of setup() and it will connect.
Thanks for the tip. I guess I was making a bad assumption that the Particle.connect() call was blocking but maybe that’s not the case when SYSTEM_TRHEAD is ENABLED? Anyway, I updated the code per you recommendation, and same issue persists.
/*
* Project boron_issue
* Description:
* Author:
* Date:
*/
#include "Particle.h"
// System threaded mode is not required here, but it's a good idea with 0.6.0 and later.
// https://docs.particle.io/reference/firmware/electron/#system-thread
SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC); // setup() and loop() run immediately. Use Particle.connect() to start cellular connect.
// setup() runs once, when the device is first turned on.
void setup() {
delay(2000);
Serial.begin(115200);
Serial.println("Hello World");
// Put initialization like pinMode and begin functions here.
// Particle.subscribe("a", test, MY_DEVICES);
// Particle.subscribe("b", test, MY_DEVICES);
// Particle.subscribe("c", test, MY_DEVICES);
// Particle.subscribe("d", test, MY_DEVICES);
Particle.subscribe("hook-response/GS-subscribe", test, MY_DEVICES);
Particle.subscribe("hook-sent/GS-publish", test, MY_DEVICES);
Particle.subscribe("hook-response/GET-xmlsetup-dropbox", test, MY_DEVICES);
Particle.subscribe("hook-sent/GS-batchPublish", test, MY_DEVICES);
}
// loop() runs over and over again, as quickly as it can execute.
void loop() {
if (!Particle.connected()) {
Particle.connect();
waitFor(Particle.connected, 60000);
}
}
void test(const char* event, const char* data) {
Serial.printlnf("%s: %s", event, data);
}
connects without issue. Upon a name change to those specified in @Tim-D’s code above, my device cannot connect. Let me loop in someone who can speak to this apparent restriction.
@Tim-D, this is a really weird problem - thanks for bringing it to our attention! I'd like to find a long-term answer that addresses the underlying issue here, but in the meantime @rickkas7 has a great suggestion:
The easiest workaround is to just subscribe to "hook-". The parameter is a prefix so it will respond to all hook-sent and hook-response for this device with just a single subscription.
Ultimately, I don't believe this to be an issue with THREADing or with SEMI_AUTOMATIC or MANUAL mode - but rather (as discussed above) with the event nomenclature. I'll update this thread as my understanding of the issue develops.
I agree with your assessment. I think SEMI_AUTO vs AUTO just changed the order in which connection happens relative to the subscriptions. I will give @rickkas7’s suggestion a try and will report back when I get a chance. In case it helps, I believe this code works on the Electron although I don’t think I’ve tried with device OS 1.4.0. Hope that doesn’t muddy the waters…
