Unlocked device in company approved device won't upgrade to released firmware unless it is reset

Can someone help with this? I’ve added a new device to the company list of approved devices. It is unlocked, another device in the list has been manually updated with a released version of firmware, but this new device never shows an updated last connection despite their being a Particle.connect() added to the main loop. I also tried a periodic Particle.DisconnectI() and then a Particle.connect()in the loop. I’ve also noticed that the Last connection field in the company approved device list doesn’t update (tried refreshing the dashboard page as well). If I reset the device, the last connection field then gets updated and the device will upgrade the firmware.

I have a workaround for now-- we’re only adding beta customers on at a slow rate of a few every week and I can conceivably manually update each one when they go to install, but at some point I’ll want to upgrade all of the devices and would rather not do each one manually.



That might be something for @Charlie_K

Steve, from your description it sounds like you’re doing everything right, so I suspect there’s a bug in your firmware that’s preventing it from disconnecting and reconnecting. That is, I think it’s staying connected except when you hit reset.

You could verify this several ways:

  • if the device uses Wi-Fi, power off the router and then power it back on — the device should pretty obviously disconnect and reconnect.
  • Do you ever see the device LED change when you think it’s offline? Try making it disconnect, wait 60 seconds (you’ll probably see breathing green, depending on what else is going on), and then call Particle.connect().

In all these cases when it reconnects it should get any available upgrades, and it should update the last connection field.

Also try a negative confirmation:

  • when you think the device should be offline, try reading a variable, which shouldn’t work if it’s offline

Let us know how it goes!

Hi Zachary-

Thanks very much for the debugging ideas-- they solved one of the two issues. However the automatic firmware update to the latest version isn’t happening. I have a few suggestions also.

By the way, I continue to be very impressed with the particle.io products and direction – well documented, reasonable cost devices, and very easy to integrate! We have about 10 of these now installed at alpha customer sites for my client’s demand energy monitoring devices at Brayden Automation. It looks like a really good fit-- although we’re running into some situations where we can’t get the devices to connect through the wireless modems. This is still under investigation.

Here are the results of the experiments:

I first tried powering the router down and back-- the device did disconnect and reconnect and the last connection time updated. However the firmware didn’t upgrade. The firmware version field prior to running this experiment is unlocked and was set to v4 and the released version is v5. The only way I was ablet to upgrade it was to do a “lock and flash now”.

  1. I increased the time that the device was disconnected and that solved one of the two issues. The last connection update field is now reliably updating. My main loop has a particle.disconnect() followed immediately by a reconnect() and I’m guessing there needs to be a minimum time of being disconnected-- presumably because of linger settings in the network connection?. I added a delay between the two calls of 10 seconds and that seemed to do the trick. However-- the firmware is still not automatically downloading and updating.

I re-read the documentation and might suggest you make a few changes. In the firmware reference, it states

“In most cases, you do not need to call Particle.connect(); it is called automatically when the device turns on. Typically you only need to call Particle.connect() after disconnecting with Particle.disconnect() or when you change the system mode.”

My understanding now is that you must call Particle.disconnect() and Particle.connect() if you expect firmware updates to occur automatically from a corporate dashboard. In addition, it does sound like you need a minimum time of being disconnected in order for a connect to work properly. If I’m understanding this correctly, you may need to document that as well.

Still would appreciate someone looking into the automatic firmware update to the released version. That still doesn’t appear to work. We do also connect to our Brayden Automation server to send data and disconnect from that in the main loop, and we do update a particle.io variable. These may have some side effects perhaps?


1 Like

Great suggestions for documentation, and helpful information Steve; thank you. I’m super happy you’re having such success with :particle: at Braden Automation! Thank you for the compliments, and it’s this whole community of people just like you who keep making the platform better. :bow:

I’m going to pull @jeiden into this conversation to raise visibility on the failure—at least intermittently—of the following scenario:

Given I have a product in the Particle dashboard
And that product has firmware version 20 released
And I have a device in that product
And that device's firmware version is not locked in the dashboard
And that device is running product firmware version 10
When that device connects to the Particle cloud
Then the device receives an OTA flash of product firmware version 20

The whole team is consumed with some big changes right now, but we can look into this later in August.

One clarification — we do not automatically downgrade firmware. We only upgrade. To downgrade, you must lock a version in the dashboard. Does that change your expectations or explain the behavior you see Steve?

Actually, wait, huge information gap (forehead smack) — are you using an Electron @steveh291 ? If so, it uses UDP, which is connectionless and would likely explain the behavior you’re seeing.

EDIT: Ugh, sorry, you talked about the Wi-Fi router. Never mind. Typed too quickly!

Our docs are open source. I’ve created a github issue with your suggestions:

Hm, the released firmware should definitely be downloaded by the device if the device is not locked to another version. We’ll have to look into it

Completely understand other priorities going on-- and I have a workaround for now-- we can manually do the updates.

That said, I’m afraid having the product disconnect and connect regularly from the cloud presents another issue and I’m not sure it’s a good practice. When using the spark ios libraries-- there are tests done about whether the device is connected or not that will report back an error condition about not being able to claim a device if when the device is checked it is disconnected from the cloud. In the firmware implementation I had the main loop disconnect and reconnect to the cloud, the particle device would end up being disconnected from the cloud maybe 40% of the time. I repeatedly tried resetting the network, and many times the lower level spark ios libraries used to set up the network, etc. would report back an error because at the moment they checked the connect state of the device from the perspective of the cloud, invariably the device would be disconnected. Maybe there’s another way that the cloud can be triggered to check for whether an upgrade update is needed.

Thanks, Jeiden. Hopefully when you guys get a moment you can check this out. It was pretty easy for me to repeat the condition.