Boron LTE SEMI and MANUAL modes - Connection Issues (To Particle)

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.

Can you show some code?
Maybe we can get a feeling why you haven’t got any luck with your attempts.

Similar to what happens to mine.

Which I beleive is being investigated here:

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.

It seems for the Boron this limit might be 3?

Tim

Have you confirmed that you are actually using the latest device OS version?
Anything prior 1.2.1-rc.3 would experience this issue

1 Like

Sorry I forgot to include that. Running device OS v1.4.0

Granted, I haven’t tested this with an LTE Boron but with my Boron 2G/3G on 1.4.0 this code works as expected

SYSTEM_MODE(SEMI_AUTOMATIC)

void setup() {
  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.connect();
  waitUntil(Particle.connected);
}

void test(const char* event, const char* data) {
    Serial.printlnf("%s: %s", event, data);
}

Sending an event d will printout the exected data.

1 Like

The issue is that the Boron in our case will not connect to the cloud. Keeps cycling between flashing green and cyan. Output messages in failure mode:

Hello World!
Rev 0.25 - Boron Build date/time: Oct 10 2019 12:24:58 Particle: 1.4.0
Reloading global state…
free memory (bytes) : 57216
DEVICE ID : e00fce6862b7acb9cab1d1fe
0000002487 [app] INFO: connectionEvent event=0 data=0
0000002489 [app] INFO: connectionEvent event=18 data=140
Battery (V) = 4.03
Fuel (%) = 81.07
PMIC Safety Timer Disabled
0000070525 [gsm0710muxer] ERROR: The other end has not replied to keep alives (d
0000072379 [comm.protocol] ERROR: Channel failed to send message with error-cod>
0000072385 [comm.protocol] ERROR: Event loop error 20
0000072387 [system] WARN: Communication loop error, closing cloud socket

Have you tested with my code?

I have not. I will try to put together a basic example exhibiting the issue so I share.

1 Like

Your code does work. Trying to figure out what else needs to be added to break it.

Hi ScruffR,

The issue is with the (total?) length of the event names. With event names like “a”, “b”, “c”, “d” it works but with event names like:

“hook-response/GS-subscribe”,
“hook-sent/GS-publish”,
“hook-response/GET-xmlsetup-dropbox”,
“hook-sent/GS-batchPublish”

it does not. Is there any indication in the documentation that the event signatures have a limit?

Thanks!
Tim

The limit is documented here
https://docs.particle.io/reference/device-os/firmware/photon/#cloud-functions

But none of your event names exceeds the 64 character limit and it should be per event not in total.

Can you provide a stripped down example that exhibits the problem?

/*
 * 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,
Tim

This is not advisable since an ongoing connection attempt may be hindered by a subsequent Particle.connect() call.
This would be a better approach

void loop() {
  if (!Particle.connected()) {
    Particle.connect();
    waitFor(Particle.connected, 60000);
  }
}
3 Likes

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);
}

I’ll have to test and see - maybe @marekparticle can also chime in here.

I corroborate @ScruffR’s earlier observation, but as applied to your recent edit:

#include "Particle.h"

SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC); 

void setup() {
  delay(2000);

  Serial.begin(9600);
  Serial.println("Hello World");

   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);
}

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.

1 Like

@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.

1 Like

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…

Tim

2 Likes