I’m curious if (and how) it’s possible to put an Electron into safe mode (or whatever mode is needed for flashing new firmware OTA) via a separate device. So for example, let’s say I have an Electron and a Photon in an enclosure side-by-side and I want to use the Photon merely as a means to setting the Electron into a listening/safe mode when it either gets stuck in a loop, is in deep sleep, or for whatever reason that prevents a remote OTA update flash. I do realize that OTA flashing uses up a large chunk of data, but I want to experiment a little with an Electron remotely. Can I do this purely though hardware, i.e. setting the Electron’s RST pin high via the Photon, or does there also need to be a programmed interrupt and function on the Electron which puts it into this desired mode? Thanks in advance.
There would be several ways for doing something like that, but most of them won’t require a device of the Photon’s caliber.
Actually I’d think there is no need for external devices at all, since the Electron could do that just as well.
On the other hand if you had a Photon (or other device) how would you tell this one to take action?
For this case
you’d use the internal watchdog
you could use the Particle Console (or even your own server) to do an update on next wake (provided you’ve got some code in place to support that - which you’d otherwise had to have on the external device too)
That would also need specific action of the external device which might just as well be done by the Electron itself.
BTW, RST would need pulling LOW to reset the Electron.
From what I’ve read in threads like the one here: Updating firmware after deep sleep power savings, it seems like there isn’t a simple or straightforward way to queue up an OTA update for the next time the device wakes from its sleep.
For initiating the Photon to take action, it would be connected to a wifi network and serving only to put the Electron in an OTA update listening mode.
This thread is OLD, https://console.particle.io and the free tier for developers was introduced since, which makes deferred OTA updates possible for everybody now
So you are in relative proximity to the devices, since you have WiFi but no internet via that WiFi?
And with that proximity other “conventional” means might be accessible too.
Perhaps I’m not using the correct terminology or I just don’t understand how flashing firmware can be done now. When I say that I would like to do a remote OTA update on an Electron that is sleeping, I mean to say that I would like to push a newly compiled program out to an Electron that is over 2,000 km away. My Electron takes various environmental measurements, publishes the data, and then goes into deep sleep. It’s awake for roughly 5-10 seconds during the time it’s reading sensors before going into deep sleep. If I try to flash a new program over the air to a sleeping device, it produces a timeout error.
Thus my question about having a Photon next to the Electron. I could expose a function on the Photon which would trigger it to put the Electron into a listening mode for an OTA flash.
That other thread is a bit old, however it is addressing the exact issue I’m trying to confront.
With the Particle Console you can upload a binary to the Particle servers which will wait for your device to wake up and check in with the cloud. At that moment the cloud will send a “pending update” notification to your device which your device can accept or decline.
If it accepts (which is the default) the OTA update will be triggered by the cloud - your device just has to stay awake a bit longer when it “sees” the pending update info.
And hence the old thread is not telling the whole story anymore - new info/development supercedes old info.
@ScruffR, this functionality only works when you create a Product, right?
Yes, but since the new pricing scheme has gone live, everybody can create a product, even if it’s only one device.
There never was a question how this would work but only inststance that it won’t work
Hence my focus on clarifying the possibility first, before going into details about the HowTo
@ScruffR, free up to 25 devices, just to be clear.
To be even clearer (AFAIK) 25 devices per product ID but no known limit of product IDs per developer
That’s great info, thanks!! When the device is triggered with an OTA update by the cloud, will the update process prevent it from going back to sleep until it’s finished (or will I need to add a short delay after each connection)?