What does "may" mean? Cloud API Special Device Events, Flashing: "success" message not sent - why?


When I use the Particle CLI tool to flash Tinker to an Electron, I see the following events raised (subscribed to via particle subscribe mine - this is all done on a personal Particle account, no Product anything involved):

spark/flash/status: started
spark/flash/status: success

However, when I use the Particle REST API to Flash a Device with a pre-compiled binary, I only see the

spark/flash/status: started


I think the crux of all of this is alluded to in the doc for flashing, where it says “As updates are being delivered via the cloud to your device, you may see some events published by the cloud to help you monitor the update.”

Is there a way that I can use the pre-compiled binary flash API and also receive the “success” and “failure” events for each flash?

I seem to get a different result:

Compiling and flash:

KENMBP:oled-dht22 kennethlimcp$ pcp .

Compiling code for photon

attempting to compile firmware 
downloading binary from: /v1/binaries/5995a65ec60fa44f94382dd5
saving to: photon_firmware_1502979676714.bin
Memory use: 
   text	   data	    bss	    dec	    hex	filename
  21756	   1220	   1760	  24736	   60a0	/workspace/target/workspace.elf

Compile succeeded.
Saved firmware to: /Users/kennethlimcp/Desktop/particle/oled-dht22/photon_firmware_1502979676714.bin
KENMBP:oled-dht22 kennethlimcp$ pf oled *.bin
attempting to flash firmware to your device oled
Flash device OK:  Update started

event stream:

{"name":"spark/flash/status","data":"started ","ttl":60,"published_at":"2017-08-17T14:21:33.231Z","coreid":"x"}
{"name":"spark/flash/status","data":"success ","ttl":60,"published_at":"2017-08-17T14:21:35.430Z","coreid":"x"}

You need to watch the event to get all the messages since the REST API is returning you a response to say that, hey, update has started.

Hmm, the responses I am describing are in the event stream (subscribed to via particle subscribe mine in another terminal via Particle CLI). What does your HTTP request look like? I am not familiar with the pf oled command you are using.

It’s aliases that i use. Basically particle flash DEVICENAME binary_name

Got it. OK, I think that is similar to what I am seeing, and maybe this points me at the answer: what is the difference between what the Particle CLI tool is doing with that command, and my PUT request to the flash device with pre-built binary API.

Like i said, when you use a REST API endpoint, you will be returned with a response and the response will be a one time reply. In this case it will be as you saw: spark/flash/status: started

If you want to look at the events that are published which contains more information about the flashing status, you will need to subscribe to your event stream.

Sorry I am not being clear. I understand that that the events I am looking for are in the event stream, and not responses to the REST API. What I am trying to say, is that when I call the REST API, and monitor the event stream, the event stream is not giving me the spark/flash/status: success event. Because the only difference between what I am doing and what you are showing appears to be your use of the Particle CLI tool and my use of my own client library to do the REST API call, I assume the behavior I am observing is related to how I am calling the REST API.

I was able to reproduce the issue I am having with only the Particle CLI tool. I think this is the same procedure as @kennethlimcp posted above, except instead of a spark/flash/status: success message I receive a spark/status: offline message, followed immediately by my firmware starting up and doing its initial sync with our cloud:

The firmware is running in semi-automatic mode with the system thread enabled. Is there something we might be doing in the firmware that is interfering with this event being raised? I note that sometimes I do see the spark/flash/status: success message when running the flash with the Particle CLI tool, but the majority the cases appear like this.

I have noticed that having SYSTEM_THREAD(ENABLED) sometimes “messes” with OTA updates under some obscure circumstances.
After an apparent reset the device “restarts” but still running the old firmware but when you wait a second or two another proper reset will happen finishing off the update.

This also trips the sucess/fail check by the cloud.

If I want to be in the save I put my device into Safe Mode first before starting the OTA update.