Issues with Product firmware

Cloud
21

An alert if a device hasn’t come online isn’t something I’m really interested in; besides, Ubidots does allow for an email and SMS alert for this.

For me, it is crucial the device sends the data when it needs to… As it is set to a 6-hour interval, missing a connection means I will receive my data 6 hours after I need it.

I haven’t gotten any long-lasting issues with sending data yet (some devices have been up for nearly half a year now) fortunately. I haven’t been able to tell yet if my devices really can’t connect, or if it’s a Cloud issue; whenever I test it at my desk it seems fine, and even in a metal enclosure with a 5-min interval it wouldn’t miss any connections.

I’m puzzled now as to what to do; seems like it may not even be a connection issue. Perhaps, like you said, I can look for a way to check if the data was sent correctly, and if not the device sends it again.

22

The feature just automatically alerts you if your device has not sent data in within 6 or 12 hours so you know there is an issue with your device not sending data in or not. Ubidots didn't have this feature in the past, can you link to where they have added it? Both platforms allow you to send SMS and Email messages.

I'm not sure why you wouldn't want to be notified if one of your devices stopped checking in vs manually trying to figure it out by checking the logs daily.

From my testing with the Electron using both MQTT and Particle Publish, eventually, your going to start missing data UNLESS you do a full power reset of the device on the regular. I plan on doing this via a Watchdog timer to do a full power reset every 12 or 24 hours.

Eventually, I think it boils down to a cellular network connection issue between it and the Electron that a full power reset always fixes.

If you subscribe to a Particle.Publish and do not receive a reply to confirm it was received then you know you need to send it again or reset the Electron to make it work again. I think that's the only guranteed way to confirm your data was received.

23

Ubidots has it on the Events tab. Just select a Device (or all Devices), select any variable, and then select ''has been inactive for'' and specify the amount of time (e.g. 12 hours). And then (in my case) add an Email alert. I meant that as far as Losant is concerned, I'm not so much interested in whether it has an Alert for it or not, as I already have it through Ubidots.

There is a Deep Sleep power reset whenever the device comes online.

Could be. A Deep Sleep reset doesn't count as a full power reset here though?

Sounds like a good idea to do.

24

Cool, I didn't know Ubidots had that feature now.

Yea but that does not reset the modem which is what needs to be reset to clear the cellular connection issue that can happen.

Nope. @rickkas7 has code to reset the actual modem. I shared this code with you in the past, not sure if you tried it.

Check here if you want to try the modem reset code:

1 Like
25

Thanks a lot, I will definitely try that modem reset today if I got some spare time! :sweat_smile:

1 Like
26

I ended up doing several things to mitigate this issue.

First, I applied Rickkas’ recommendations for rebooting the modem, when my Electron cannot connect.
Secondly, when my Electron can’t connect, before the reboot it will write all its data to EEPROM, and then access that data right after the reset. That way all my data is preserved and it gets to attempt another connection.

I will just have to add in a limiter now to the number of connections, so that it wouldn’t potentially re-run the code forever if for example the antenna gets dislodged (I soldered them; shouldn’t be possible, but still good practice to provide a way out)

27

Sweet!

Looking forward to seeing how these changes work out for you.

So your deploying 40 more units soon? You’re moving forward quickly if so!

28

Yup, 40 more sensors are gonna be deployed in January…exciting!

29

Is that mainly for more research or because the trash company is liking the small-scale testing and want to do more?

30

A bit of both. For sure there is a lot of potential with devices like these.

31

Well, it’s nice to take the ride along with you and figure out which firmware setup works best for managing 50+ Electrons out in the field running 3rd part SIM’s.

32

I feel like there’s another issue here…Whenever my Electrons can’t connect, they’ll do a full reboot. They will do this forever until a connection finally goes through…today I checked and about 15% of the time devices miss their connections still. However, they do appear to run their full code fine, as they still wake up 6 hours later, something that would only be possible if Particle.connected() returns true and they enter Publish state.

So it seems as if Particle.connected() returns true without actually the device being connected…is this a possibility? Is there any way they could return true for this prematurely and end up not connecting at all?

P.S. I rigorously tested my code with an Electron by disconnecting the antenna…if it truly cannot connect it would just re-run the first portion of the code forever, never actually going to sleep for 6 hours.

33

Probably best to post your code so the PRO’s can take a look.

34

This is the relevant part here, the connect and publish state. Next week I will put all Electrons together and observe what's going on, to see if any get stuck in a particular process somehow

case CONNECT: {
    if (Cellular.ready() && millis() - lastConnectSample >= 10000) {
        lastConnectSample = millis();
        Serial.println("connecting to Particle cloud...");
        Particle.connect();
    }
  if (Particle.connected()) {
      Serial.println("connection established!");
  	stateTime = millis();
      state = PUBLISH;
      break;
      }
  if (millis() - anchorTime >= 90000) {
         if (status == 1) {
              statusprom = status;
             	EEPROM.put(addressprom, statusprom);
              Serial.println("writing EEPROM data");    
              }
            System.sleep(SLEEP_MODE_DEEP, 120);
          }
    stateTime = millis();
    }
    break;

case PUBLISH: {
    if (Particle.connected()) {
        CellularSignal sig = Cellular.RSSI();
        int cellsig = sig.rssi;
        int rssi = map(cellsig, -131, -51, 0, 5);
      char data[256];
      float volt = batteryMonitor.getVCell();
      float soc = batteryMonitor.getSoC();
      snprintf(data, sizeof(data), "{ \"vlt\": \"%.03f\", \"soc\": \"%.02f\", \"stt\": \"%i\", \"rss\": \"%i\" }", volt, soc, status, rssi);
      Serial.println(data);
      Particle.publish(eventTest, data, PRIVATE);
      ubidots.add("Voltage", volt);
      ubidots.add("Charge", soc);
      ubidots.add("Status", status);
        ubidots.add("RSSI", rssi);
        ubidots.add("Connect Time", connectTime);
        ubidots.setMethod(TYPE_TCP);
        if(ubidots.sendAll()){
            Serial.println("Values sent by the device");
            }
        delay(5000);
        stateTime = millis();
      state = FIRMWARECHECK;
      break;
        }
    else {
        if (!Particle.connected()) {
            Particle.connect();
            delay(8000);
            }
        if(millis() - stateTime >= 45000) {
            state = FIRMWARECHECK;
            break;
            }
        }
    }
    break;
1 Like
35

Also, mind you I didn’t add in the modem reboot in yet as I was still testing it out a bit and didn’t want to release it yet to my remote devices…but that shouldn’t really impact anything. If the device truthfully cannot connect, it should remain in a loop forever with this and when it does connect, publish the data at some random interval and not exactly after 6 hours (which is the sleep timer I set at the very end of my code, after data has been published)

36

What made you choose Ubidots over Losant?

37

The fact that I already had it set up and it works well for me :slight_smile: Not to say I’m not considering Losant, but it’s not much of a priority for me right now to look into, I rather just have the Electrons work at this point

38

Makes sense to me.

39

Have to re-open this discussion as sadly I ran into the exact same issue again today. I have 40 Particle Electrons next to me, and they were all tagged for a firmware update. I had to leave for a little while, and when I came back I noticed about three-quarter of them still turned on and I had been billed for $60 in the meantime for data usage. When I investigated, I saw that all of these Electrons were re-downloading the same firmware over and over, but for some reason they remained tagged with an old firmware version in my Product.

They publish their data each time they come online, and I can tell they certainly did download the updated firmware correctly as they're publishing my newest variables. The issue really seems to lie with them being tagged with the wrong firmware in the Console so they continue to download repeatedly?

I think this is potentially a major issue for me, as using the the Console Product is the only way of queue'ing firmware updates, but so far it doesn't appear to be reliable at all.

My firmware for updating looks like this:

case PUBLISH: {
    if (Particle.connected()) {
        CellularSignal sig = Cellular.RSSI();
        int cellsig = sig.rssi;
        int rssi = map(cellsig, -131, -51, 0, 5);
        delay(50);
      char data[256];
      float volt = batteryMonitor.getVCell();
      float soc = batteryMonitor.getSoC();
      snprintf(data, sizeof(data), "{ \"vlt\": \"%.03f\", \"soc\": \"%.02f\", \"stt\": \"%i\", \"rss\": \"%i\" }", volt, soc, status, rssi);
      Serial.println(data);
      Particle.publish(eventTest, data, PRIVATE);
      ubidots.add("Voltage", volt);
      ubidots.add("Charge", soc);
      ubidots.add("Status", status);
        ubidots.add("RSSI", rssi);
        ubidots.setMethod(TYPE_TCP);
        if(ubidots.sendAll()){
            Serial.println("Ubidots values sent");
            }
        delay(5000);
        stateTime = millis();
      state = FIRMWARECHECK;
      break;
        }
    else {
        if (!Particle.connected()) {
            Particle.connect();
            delay(8000);
            }
        if(millis() - stateTime >= 45000) {
            state = FIRMWARECHECK;
            break;
            }
        }
    }
    break;
    
case FIRMWARECHECK: {
    if (Time.weekday() < 8) {
        Serial.println("checking for firmware update");
        delay(90000);
        state = CONFIG;
        }
    else {
        state = CONFIG;
        break;
        }
    }

EDIT: Re-plugged the battery and now they seem to download and maintain the new firmware just fine in most cases. Seems like a power reset may be necessary to avoid this issue?

40

@ScruffR Do you think your Webhook Subscribe code hack would help fix this problem also by forcing a handshake sooner than a full power reset would?