Device no longer connecting to Cloud

The bit of code responsible for connectivity is pasted below. What I observe is that my Electron will briefly attempt to connect to the Particle Cloud (rapid cyan blinking) and within 2 seconds will show three red blinks, and then go back to connecting to the cellular network again (green blinking).

Any thoughts? I already tried "particle keys doctor" but the issue is persisting.

    if (!Cellular.ready() && millis() - connectTime >= 8000) {
        Serial.println("connecting to the cellular network");
        connectTime = millis();
        Cellular.connect();
        }
    if (Cellular.ready() && millis() - connectTime >= 8000) {
        Serial.println("connecting to the Particle cloud");
        connectTime = millis();
        Particle.connect();      
        }

You should restore Tinker to the device and make sure it’s not a cloud-related issue, but I’m pretty sure it’s that code.

You should only call Cellular.connect() or Particle.connect() once. They internally retry until connected once you start the process.

It looks like you call Cellular.connect(), then every 8 seconds you call it again. That can prevent ever connecting because when you Cellular.connect() again it restarts the process, so it’s possible that it will never complete if it takes longer than 8 seconds.

The same thing can happen for Particle.connect.

3 Likes

Really? I didn't know that - for some reason I always thought Cellular.connect() and Particle.connect() had to be re-called every once in a while....not sure where I got that from.

So this would be better to use?

if (!Cellular.ready() && !cellularConnect) {
    Serial.println("connecting to the cellular network");
    cellularConnect = true;
    Cellular.connect();
    }
if (Cellular.ready() && !particleConnect) {
    Serial.println("connecting to the Particle Cloud");
    particleConnect = true;
    Particle.connect();      
    }

Yes, that should work better.

Another question: is it okay to call Cellular.connect() right after Cellular.on(), or is it advised to add a delay in to allow the modem to boot up?

Also, I experience the same problem still with this code:

if (!Cellular.ready() && !cellularConnect) {
    Serial.println("connecting to the cellular network");
    cellularConnect = true;
    Cellular.connect();
    }
if (Cellular.ready() && !particleConnect) {
    Serial.println("connecting to the Particle Cloud");
    particleConnect = true;
    Particle.connect();      
    }

If SYSTEM_THREAD(ENABLED) is used, then you need to wait or use cellular_on(NULL) instead of using Cellular.on().

It’s possible that it’s something else, as well, so make sure you try with Tinker or safe mode to make sure it’s a firmware issue before going too far.

I already do use cellular.on(NULL), so I'll try restoring Tinker. For reference, here's the full code for this switch state:

case CONNECT:
    xl.readXYZTData(X, Y, Z, T);
    if (!initialized) {
        Serial.print("connecting to the cellular network. Please allow up to 90 seconds.");
        EEPROM.get(addMode, mode);
        EEPROM.get(addCollection, collection);
        EEPROM.get(addX1, X1);
        EEPROM.get(addRebootno, rebootNo);
        cellular_on(NULL);
        delay(1000);
        Cellular.connect();
        initialized = true;
        }
    if (isValid(X) && millis() - sampleTime >= 500) {
	    sampleTime = millis();
	    X2 = std::abs(X-X1);
	    if (!collection && X2 >= 400) {
            state = XL;
            break;
          }   
	    }
    if (Cellular.ready() && !particleConnect) {
        Serial.println(" connecting to the Particle cloud");
        particleConnect = true;
        Particle.connect();      
        }
    if (Particle.connected()) {
        initialized = false;
	    Serial.println("connection established!");
	    if (mode == 1) {
	        stateTime = millis();
	        state = GPS;
	        break;
	        }
	    else {
	        stateTime = millis();
          state = PUBLISH;
          break;
            }
        }
    if (millis() - stateTime >= 90000) {
        if (rebootNo < 3) {
            reboot = true;
            rebootNo = rebootNo++;
            EEPROM.put(addReboot, reboot);
            EEPROM.put(addRebootno, rebootNo);
            snprintf(buffer, sizeof(buffer), "%i previous connection attempts have been made. re-attempting in 10 seconds.", rebootNo);
          Serial.println(buffer);
            Cellular.off();
            delay(2000);
          System.sleep(SLEEP_MODE_DEEP, 10);
          break;
            }
        else {
            Serial.println("connection attempt threshold reached");
            state = SLEEP;
            break;
            }
        }
    break;

I re-flashed Tinker which didn’t fix it…Cloud-side looks good with other devices still happily connecting. For this simcard I’ve only used up 0.4 out of 200MB this month.

If you don't intend to have some time with the cellular module on but not connected, you can omit Cellular.on() entirely since Cellular.connect() and Particle.connect() initiate all the prerequisite steps as needed.

1 Like

Thanks for the suggestion, it does clear up my code a little bit…unfortunately I still have the same issue.

The device was working fine yesterday evening so I simply left it (it’s set to connect a few times per day). When I came back it was no longer connecting anymore. Not sure at what exact point the issues started.

Ok people, found a fix:

I ran “particle keys doctor [deviceID]” which didn’t work. However, “particle keys server” did work. Any thought on how this may have happened? The rest of my devices continued to connect fine.

I’m interested in understanding this issue better as it came out of nowhere, and once my devices are out in the field I won’t be able to physically access them anymore to run this command if the issue emerges again.

Could it be that that one particular device wasn’t connected to the cloud for a long periode (e.g. weeks)?

Actually I was testing around with that device most of the day yesterday (last connection at 5.20pm). Then either at 12am or 8am, it woke up from Deep Sleep and must’ve started to experience this issue on its own.

Another possible reason could be some kind of brown-out condition which can also cause the dim blue D7 LED issue where the power condition may trigger a partial corruption of undpredictable flash areas.
The underlying cause for that is yet unknown and seems to only hit some devices and others not at all.

It’s a 3G Electron and was connected by USB to my Desktop which was in sleep mode. I haven’t come across this issue before yet, and I connect my Electrons in this manner all the time, but you think this could’ve been the cause?

Wondering if someone could help me out a bit more with this.

I started to see a pattern where whenever I cut power to one of my Electrons, there’s a small chance this will invoke the “5 red led blinks” issue that’s only fixable by running “particle keys server” + “particle keys doctor”. In a few weeks I’m planning to have a couple dozen of these devices in remote areas and they may in fact lose power at some point (which can be restored by someone else - but that person wouldn’t know how to run these commands). This is happening across several Electrons, so it’s not isolated to a single device. It has also happened several times to the same device, and even a 2-minute power outage is sufficient for this to happen.

For clarity, here’s the code:

    case CONNECT:
        if (!initialized) {
            Serial.println("connecting to the cellular network and Particle Cloud. Please allow up to 90 seconds.");
            Particle.connect();
            initialized = true;
            }
        if (Particle.connected()) {
    	    Serial.println("connection established!");
            Particle.syncTime();
    	    stateTime = millis();
    	    state = GPS;
    	    break;
    	    }
    break;

LED blinks green, then cyan for a few seconds, then blinks red 5 times, continues to show cyan and eventually goes back to green.

Is there any way to avoid this problem? Or is the only solution ensuring that they are always powered up?

You might want to implement the Device Keys Helper written by @rickkas7 in your code. It is supposed to help you restore the device keys when the config memory gets corrupted. It sounds like what you are describing.

1 Like

Any thought why the example @Rickkas7 posted in that link only works when I build it for Photons, not Electrons? https://go.particle.io/shared_apps/5ba94994bac8afd0a8000425

I simply get "lib/DeviceKeyHelperRK/DeviceKeyHelperRK.cpp:39:87: ‘dct_read_app_data_copy’ was not declared in this scope’’

It’s most likely the system firmware version on your Electron. Make sure your Electron has 0.7.0 or later on it, otherwise it probably won’t work.

If you really need to use 0.6.x I can modify the library so it works, but it was an oversight that it doesn’t right now.

1 Like

Thanks a lot, I’ll be giving this a try tomorrow :slight_smile: All my Electrons are running 0.6.2 so yeah, it’s likely the issue.