Hi,
I’ve been searching the community forum for help on this, but let me explain the problem and then what I’ve tried:
I have two firmware versions for a Particle Electron: deployment firmware and live firmware.
The deployment firmware does a System.sleep(SLEEP_MODE_DEEP, 43200) (12 hours), then connects to Particle cloud, runs Particle.process(); for one minute, then publishes the battery percentage and goes back to sleep.
The idea is to run the deployment firmware on these battery-driven devices until they’ve been setup remotely and then enable a roll-out of our live firmware. I’ve added these to a product with the two firmware releases.
However the problem is that I can see that Electron connects and publishes the battery event, but it doesn’t seem to do an OTA upgrade, even though it is marked as queued on the device page.
I’ve tried giving it more time after connection, waiting for the update event to fire, but to no avail.
Any idea what could be preventing it from updating?
It lists the correct PRODUCT_ID, I’m running
SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);
with
// Check whether we're connected
if (Particle.connected() == false) {
Particle.connect();
waitUntil(Particle.connected);
}
Hi @ScruffR
Let me try to answer your questions:
- What system version have you got on your devices?
I’m running 0.8.0-rc.8
- Have you at any instance set System.disableUpdates()?
No, I have not used that function
- Have you notched up the PRODUCT_VERSION() and are both versions using the same PRODUCT_ID()?
Both have same PRODUCT_ID(), but I am trying to “downgrade” from V3 to V2. V2 is released under product firmware, but V3 has been flashed manually onto the Electron
- Have you by any chance locked the version on the respective device?
It has been set to flash and lock (https://www.dropbox.com/s/fxsnfhr1llj8kss/Screenshot%202018-07-10%2012.34.29.png?dl=0)
- How are you calculating the one minute wake time?
I am using the following:
// Process Cloud
unsigned long startTime = millis();
while ((millis() - startTime) <= 60000) {
Particle.process();
delay(10);
}
- Does it include the reconnection time, which may leave too little time for the OTA update to kick in?
It uses “waitUntil(Particle.connected)” before starting the one minut counter, so it should be reconnect time + one minute.
- If you subscribe to firmware_update_pending do you ever get a trigger?
I have not subscribed to this - do you have a code example?
- If you do, you may want to extend the wake time to more than a minute
It could be interesting to test!
This is how you can subscribe to system events
https://docs.particle.io/reference/firmware/photon/#system-events
I'd think this is the actual problem. OTA downgrading is not anything that is supposed to be an automatic feature.
How should i handle the system event?
I’ve tried making it V1 upgrade to V2, but nothing changes. It is like the auto-update event does not fire seen from the events page, only the publish from the device. I’m flashing it manual under development mode, then letting it go to sleep. While it is asleep, I removed development mode, then It sees that it should update from V1 to V2 (or what I can conclude from looking at the device page), but it simply never happens, not the update nor the auto-update event.
If you have marked your device as developer device than it also won’t get an auto-update as this would interfer with the actual development and I’m not sure when the device should be accepted back into the non-dev crowd.
Maybe @rickkas7 can chime in on that.
Alright, that could be the case - but it shows that it’s queuing an update on the device page? but I’ve tried flashing it manually, then it connects and gets the new device firmware. However, then I am unable to test that it can update after a DEEP_SLEEP of 12-24 hours.
I would like to update, it seems that after two and a half hours (running 30 minutes DEEP_SLEEP) that it updated automatically (see screenshot: https://www.dropbox.com/s/9kuaaiewudr66gw/Screenshot%202018-07-10%2020.59.31.png?dl=0) so it is possible, but if it takes five tries, then that’s two and a half days before the live firmware gets updated. Of course, if it’s the same case. But for now, I can live with this - I would like to thank you so much for the help!
That sucks... but it would seem that you designed the product that way. How can I phrase this?... "Is is so critical that the firmware is updated immediately when you are saying that you only want 1-2 data points per day." Will those data points be so inaccurate that new firmware is required ASAP? If you were saying that you do 30 minute sleeps and it took 2.5 days to update, then 48 data points would be inaccurate... which is a much larger number than 5... I too would be looking for answers.
I know there are product firmware deployment nuances that Particle is trying to improve upon, but they haven't rolled that out yet. I assume you are in a low power state trying to conserve battery. Would waking every 6 hours be out of the question?
Hello ninja,
It is not the data points, it is merely that it would be nice to plan these things for deployment and schedule when it becomes live. It doesn’t seem very professional, when you have to tell a customer that the network will go live between now and X days - you could of course wait until the network is live and then plan it out.
It is purely for planning and disemmination for how the product works. However, for now it is fine, as long as I am sure that it will upgrade firmware at some point.
