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

boron
Tags: #<Tag:0x00007fe22301bd20>

#1

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.


#2

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


#3

Similar to what happens to mine.

Which I beleive is being investigated here:


#4

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


#5

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


#6

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


#7

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.


#8

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


#9

Have you tested with my code?


#10

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


#11

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


#12

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


#13

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?


#14
/*
 * 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


#15

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

#16

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


#17

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


#18

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.


#20

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


#21

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