Cliffnotes version: My Particle Product (Product created in the Console) can get into a state where it can connect and publish successfully, receive a subscribed event successfully, but won’t update “Last Connection Time” in the Console, or receive queued firmware updates (I’m running Particle Firmware 0.6.1-rc2). I currently have a device in this state and am hoping Particle can troubleshoot this while it is occurring.
I’m designing an industrial product using an Electron that needs to be left unattended and run for over a year with an occasional (min daily) cloud connection. The reliability of the cloud connection is critical so I’ve been testing the connection with a couple devices set to connect to the Particle Cloud once every 10 minutes, publish and check for firmware updates, then disconnect and go back to Deep Sleep. The connection and publish are reliable, but I noticed that the device sometimes won’t receive a queued firmware update, and I’ve been troubleshooting. I notice three symptoms when the device (or the cloud) is in this state: the
firmware_update_pending event isn’t received (and the Log doesn’t show a
auto-update event), the timestamp of “Last Connection” in the Particle Console isn’t updated, and the Log doesn’t show the
spark/device/last_reset event for the device.
I currently have a device that has been in this state for over 17 hours, connecting and publishing successfully >100 times while in this state, but “Last Connection” hasn’t been updated, and the device hasn’t seen any firmware update requests though it is queued to receive an update. (I’m disabling firmware updates just for testing using
System.disableUpdates() so I can look for the firmware update event to come in each time I connect, but not actually update the firmware).
Two devices, both have connected and published within the last 10 minutes (as of 2017-03-21 10:50AM EST) but one hasn’t updated “Last Connection” for over 17 hours:
Some details on how I connect, disconnect, sleep. Unfortunately I can’t share the code running on these devices as it was written for another company:
- I use
SYSTEM_MODE(MANUAL)as sometimes I need to wake without connecting, and need to control when I make a (potentially long) call to
- I connect in stages:
- I publish the data I need collected via
Particle.publish(), then publish a second “sleep” event which I subscribed to back in
setup(). I don’t start disconnecting until the “sleep” event (containing my device ID) makes a roundtrip from Electron to Cloud and back. I call Particle.Process() every half second while waiting for the response.
- Next, to make sure I’ve waited long enough for “server sent confirmable messages to be acknowledged”, I make a call to
Spark_Sleep()indirectly by calling
System.sleep(D0,RISING,1,SLEEP_NETWORK_STANDBY)to sleep for 1 second with the modem connected. (I need this workaround as
Spark_Sleep()isn’t available directly)
- At this point I disconnect with
Particle.disconnect(), wait a half second, then enter Deep Sleep
Given the efforts I’ve made to make sure there is a solid connection with the Particle Cloud - I’ve seen the publish I made, and the device has seen a publish go to the cloud and come back as a subscription event, and I made a call to
Spark_Sleep() to make sure all confirmable messages have been sent - I believe the device has stayed connected long enough to get a firmware update event, let alone update “Last Connection” in the Particle Console. I think there’s something wrong here out of my control.
A manual reset, manual firmware update through USB, or manual entry to safe mode seem to fix this (at least sometimes, I haven’t seen this often enough to reproduce a reliable way of getting the device back in a working state), as well as just waiting. I can’t do any of those things besides wait if the device is installed in a unattended environment.
I’ll try to make time to isolate my code down to just the code involved in connecting and share it, but I wanted to post this issue now as I have a device actively showing the problem. This is relatively rare, I’ve had these devices set up for 12 days before one showed the problem.