Photon low power app: how to force firmware upgrade or safe mode remotely

I am working on a low power application on Photon that only wakes up momentarily for few seconds every few minutes or so to connect to cloud and send out a sensor reading as an event. I have been trying to figure out how to remotely trigger a firmware upgrade or alternatively push the device to safe mode. Any ideas on how to perform it?

Below paste of cloud function model that works flawlessly when device is continuously on, but with system deep sleep fails.

Could you elaborate on how it’s failing?

Also I’d not do all that stuff in the Particle.function() but only set a flag in there and do the rest in a normal function that’s called from loop() when the flag is set.
Further I’d only call Particle.connect() from inside the if(!Particle.connected()) block with an additional timeout to prevent multiple connection attempts.
BTW, since you’re not using SYSTEM_MODE/SYSTEM_THREAD in your code, your code would block anyway as soon the connection is lost.

Thanks ScruffR for recommendations, I implemented those
To answer your question: The “safe” cloud function fails 99% of time with a time-out, maybe due Photon being in deep sleep. (about1% I am lucky to issue call at right time - not a solution)

Let me rephrase my question: How do I send signal to Photon that is sleeping 99.99% of time so that the signal goes through - do I need to go the hard way and make a web hook call from Photon to a web server? Or publish an event on Photon and wait a while for other end to instruct sleep or safe mode - both models sound like a hack to me.

For the time being I’d go for a listener (e.g. a node skript) that subscribes to the device connected message (or a dedicated message your code publishes) and then triggers your desired action.
But for that you’d need to keep your device online long enough for the listener to react and trigger the task.

The good news is, that defered function calls, cloud retained variables and pending updates are planned for the not too far future. This would rid us of the need for above workarounds.

Thanks ScruffR,
the listener sounds like a plan. The latencies of two-way message passing are well below the time my device stays online - and I do not have strict requirements it to succeed 100% of time so transient latency changes present no problem.
Also, thanks - retained events & cloud variables or some other easy to use persistent cloud “shared memory” will be a big thing.

1 Like

Hi ScruffR

I also have this same issue with an electron. You mentioned subscribing to a device connected message (ideally it would be an update pending message)

where do we get a list of the available “system” messages that we are able to subscribe to, there might be many useful messages in there.

Additionally can you please post the Particle.publish("…/update_pending"); or similar string so we can use it.

Thanks and Regards

Currently the System.updatesPending() feature is crippled to virtually complete uselessness but we hope this will change with 0.7.0.
Recently I relayed several such trouble reports to Particle which might help giving this issue some momentum.

But here is an overview of the currently documented system events

I’m not aware of a similar list of cloud events tho’

1 Like

Thanks ScruffR

I’ll give the link you posted a look. I had read about the system_update being useless. it would be a good freature to have for these sleepy devices.

On a side note, (perhaps it should be a new post). On occasion when resetting the Electron for a firmware updated it crashes my windows PC with the BSOD, additionally this in turn deleted my entire *.INO file, it filled the file with NULLs have you seen this before, it has happened with both Photon and Electrons.



Never seen this so far. I’d think that’s a driver issue on your machine.
What Win version are you using?
You could remove the drivers entirely and reinstall via the CLI installer.
Also check on another USB port and with a different cable.

@tylercpeacock, you got an idea what that could be?

Hi again - I was trying to subscribe to my own fw_update event that I was generating from the console. the event name was fw_update and the argument is the time to remain online,

This works fine when the device is online, however if the device is offline. I expected it to get the event that it had subscribed to, next time it came online. esp as the TTL is ignored. and additionally the documentation implies that you can subscribe to events prior to coming online and then you will receive them when it is online, although this is a little ambigous as to whether you receive events that have been sent prior to coming online, or only when you are online and the event is sent.

Question. Can I send an event hours in advance of having my device online, and still receive the event? if so how do I do it?


Oh, I read what you have written previosuly more carefully.

Here are the steps as I see it

  1. Wait for the device to come online

  2. Watch for an event it sends at your (own) server

  3. When you see the requiste event immediately publish an event back to the device while it is online to make it stay online long enough to update it’s firmware.

I’ll try it.

1 Like

This happened to me recently also. I get the BSOD if I disconnect while I have terraterm serial window open and then close it.

I backup my code folders using Dropbox and that allowed me to revert to the code file as it was before it was all nulled out which saved my ass on a decent amount of work.

Thanks RWB

I also am using Teraterm, but I’m unsure of the exact method to make it crash, it’s so painful I really don’t want to try too hard.

Disconnecting or sometimes resetting the Photon before disconnecting TerraTerm first would almost always cause the BSOD on my Windows machine.