Probably not, since a firmware update should cause a handshake anyway due to the change in the app-hash.
But this might be a side issue (post #39) @zachary may want to know about while already dealing with the OTA handshake issue outlined here
If the extra cost on data consumption is caused by a bug in the system, Particle may want to look into that in particular.
Also, it should be noted that in my Particle Dashboard, the Last Handshake for devices usually only occurs when there is a power reset (i.e. re-plugging the battery). Regular wakeups, or pressing the Reset button, doesnāt work. I had 40 devices each connect 5 times since 4pm yesterday, and for all of them their last handshake dates from before 4pm (when I power resetted most of them)
So yes, I assume the Cloud communicates to the device that they require an update, but then the devices donāt make the handshake afterwards to notify the Cloud that they are running the newest firmware.
In my firmware, after connecting my devices publish data (taking approx. 8-9 seconds), and then enter the FIRMWARECHECK state (as listed in my code above) for one minute and a half.
@liddlem Was having similar issues where his devices were not checking in for the updates.
He added some code that subscribed to a fake Particle Variable which forced a handshake which then caused his Electrons to handshake and do an update. Iām wondering if this same method is a hack that would fix your problem until @zachary and the team figure out how to get things working properly.
How many units do you have out in the field now?
The 10 that I had in the field stopped working as well as a result, so now I have everything at my desk to troubleshoot the issues.
I will have a look at liddlemās topic later today.
Man, thatās ruff 
The product firmware updates should just work, especially since itās a paid service. Your not the first I have heard talking about the updates not working right or reliably. Your a pretty good test case to work with to get them all working reliably on 3rd part SIM cards though.
Itās alright, itās part of the job 
The technology behind all of this is quite overwhelming, so itās understandable things donāt always work right away.
Well, Iām happy to be following along with you on this to see how it all goes as you scale it out because I plan on doing the same thing for a few different markets this year.
Iām going to set up an Electron outside with a solar panel to see how it does in this -10F weather. I also want to test the updates via the Product console like your doing.
What kind of projects are you looking to work on?
Also mind you, the LiSOCl2 batteries have been powering up the Electrons non-stop while they were trying to connect to the network for 5-6 days in a row and still work perfectly fine (LiPo batteries went dead looong before that) 
Maybe consider using them if your solar panels end up not working. I got these batteries for only $5 a piece, with the JST-PH2 connector already on it. If you put 2 of them together, the Electron will have some serious lifespan on it with nearly 30Ah.
One is an actual product, portable solar systems that will have Wifi or Cellular for web communication.
Then there are other applications for businesses that do routine pickups that I want to try to work with to try to increase their efficiency and profit margins to create some extra passive monthly income for both of us.
I'm waiting to see how long the batteries last in the real world for you. I have a battery tester that you set to pulse a certain load over certain time frames that would give a good picture of what you could expect to get from the batteries under those conditions but I don't have one of the batteries to test. If I ever do order some of those cells I will test them.
This is the battery tester I have: CBA IV - Computerized Battery Analyzer - West Mountain Radio
Ideally, I would use a LiFEPo4 battery that has 5000 charge/discharge cycles when you don't discharge below 70% on a regular basis. I would need a special charging and boost circuit for that though. This along with solar could easily give you a 20-year lifespan. It would cost a little more up front but much less over the long haul compared to changing the batteries every few years. Just depends on your application.
Cool! What do you mean by routine pickups? Are they like freight companies?
As a means of testing, I put an antenna on the outside of a waste container earlier. After 5 days, it had already been smashed really bad (the entire thing was just gone, except for a tiny wire strand). I think with the way people handle things in this (waste) business, anything that's on the outside is just gonna get thrashed sooner or later. Otherwise the solar panel could've been an option for me too
Trash makes sense, so I would like to explore that more with local companies. Paper Shredding services was another one that potentially makes sense.
There are these drop off containers in our area for clothes and donation stuff that could use them to know when to or not to make a pickup based on how full the container is. There are lots of Farmers in my area so soil and crop monitoring are a potential avenue also.
I'm interested in seeing how this all works out for you because I would be dealing with the same issue when scaling out.
Ah yes, thereās many people that do projects similar to this - on the Arduino forum Iāve seen some people discussing various distance sensors for use in oil (or other liquid) tankers as wellā¦
I think professional companies that specialize in this may already have technology like this, but I think thereās a lot of potential with smaller businesses that do not have the time and/or experience to manage their efficiency.
I think my connectivity issue was fixed yesterday when I added in some more code to properly shut off the modem before re-running my code when a connection failed. so Iām now looking at a largely finished product as all other components behave pretty accurately.
I agree. They just need somebody to show them whats possible by starting small.
So was that code from Rick's Electron troublshooting sketch?
Actually no, it was simply adding in:
Cellular.off();
delay(5000);
Before entering sleep mode (I didn't realize this is required even for resets). I think the other code that I saw before is only necessary on devices running older firmware.
Yea, it was my understanding that this was taken care of a while back and was no longer required.
So you're saying the Electrons would properly handshake and update firmware via the Product mass firmware update tool only if you used the 5-second delay before calling Cellular.off();
@BDub Should a 5-second delay still be required to get the cellular modem to go to sleep before calling a sleep mode?
No, the Cellular.off () command is necessary to allow the Electron to connect after Deep Sleep. Without it, if it fails to connect a reset with Deep Sleep wont fix the connectivity issue.
Regarding the handshake, Iām not sure. I really planned to look at this today but ended up not having the time for it. Surely Monday I can work on it though!