Spark.sleep() and firmware updates

Firmware
1

In my project ( outdoor thermometer ) spark is alive for about 5-10 seconds every 10 minutes to measure the temperature and to send an event to the cloud then it goes into sleep again. This is fine.

Spark clearly connects to the cloud since temperature value is sent as an event and I do receive the readings.

Problem: When spark becomes alive I would expect it to pickup firmware update if I requested so. This doesn’t happen. The only way to update the firmware in this project is to reset Spark. This is quite annoying since every little tweak in software requires me to fetch the box with Spark and to plug it in to laptop for reset and update.

My hope was that firmware update request can wait in the cloud until the core becomes available and then would be picked up by the core and executed. Feels like this is not the case. Core has to be online when I request the update otherwise update will not happen.

Any advice? I would like to avoid extending time Spark is alive since saving battery is important.

2

@ciukes you are correct. There’s no easy way right now to do what you want to do.

Would you be opposed to adding a TCP client call to your code? You could:

  1. Wake Up
  2. Publish the temp
  3. Connect to a 3rd party website (probably one you own) via TCP Client and see if you want to flash it
  4. If yes for flash, publish a “ready to flash event” which you are listening for, and stay awake for a minute or so
  5. If no for flash or minute is up go back to sleep

Does that make sense?

3

Does that make sense?

Sure thing - check for updates:) This is a plan of what In thought is implemented in the core itself.

Thanks for the advice!

4

I believe it’s on the roadmap but not currently implemented

5

I’m replying from my phone so I will be brief. I have several similar apps that shut down the network to minimize power usage. I was hoping I could start up a cloud connection and pick up any spark.function requests that I could use to tell my core to stay online for a firmware update. Unfortunately the cloud does not keep messages for a core if it is unable to deliver them immediately. With only having the network on for a few seconds every ten minutes I can’t get the cloud to recognize the core as being ‘up’. The suggestion for a 3rd party server to provide offline messages seems like a cloud replacement. It would be very useful to have the cloud keep messages for a configurable amount of time so when a device connects to the cloud it can get the messages.

6

Yes, it would be nice for cloud to keep the last N messages where N might be configurable. Perhaps this is in the pipeline? I’m not exactly sure. Sorry I couldn’t be of more help

7

maybe something like this could work:

bool isFirmwareUpdateRequired = false;
int requestFirmwareUpdate(String command){
    if(command.toLowerCase() == "true")
        isFirmwareUpdateRequired = true;
}

void setup()
{
    Spark.function("requestFirmwareUpdate", requestFirmwareUpdate);
}
void loop()
{
    if(!isFirmwareUpdateRequired) Spark.sleep();
}

and after a curl to set the flag you have the core ready for update:

curl https://api.spark.io/v1/devices/{DEVICE_ID}/requestFirmwareUpdate\
     -d access_token={access_token}\
     -d "args=true"

do you think this is doable?

8

I just realize the stupidity of trying to call a function when the core has no connectivity.

please ignore me :frowning:

1 Like
9

Heya All!

Actually I do have a experimental behavior that I’m testing called a flash with “persistence” (it needs a better name). You can flash a firmware to your core and pass a “persist” property and set it to true. When your core connects next, it should see there is an update pending, and start an OTA immediately. This is still very experimental, but it’s meant to help address this case. It’s not released yet, but I’m testing it on our staging and experimental environments. – I also like the idea of extending this same concept to function calls, so you could have a delayed / deferred function call when your device comes online… hmmm… :slight_smile:

There is also a special auto-update feature when you’re building a product using Spark. You have the option to release firmware that can be auto-updated to your products. :slight_smile:

Thanks,
David

6 Likes
10

I am also very interested in a more automatic solution to this same problem. My current plan is to check an input bit state just prior to sleeping that will keep me connected if true. A toggle switch on the side of the enclosure would activate this input. Toggling to the “no sleep” position would allow me to flash an update after the next time my core wakes up. Toggling back after the update allows sleep again. Not ideal but workable.

A core that could check the spark cloud for pending update requests would be really helpful.

11

I do use a pin with a pull-up mode and a test at the top of loop() to go into a tight “reprogram me” loop. Works great if you have physical access to the device.

I think that @botosu 's idea would work if you can do positive control from the remote host. Let’s say your core wakes every 10 minutes and sends a publish event out as above but the host looking for that event then sends a command via a Spark.function() to the core to either go back to sleep or to wait for reprogramming. You could even add a timeout in the core that says if you don’t get a positive acknowledgement from the web host to either sleep or wait in some amount of time, then go back to sleep and try again. That would mean that the core was only awake for extra time when something goes wrong or it needs to be re-flashed.

3 Likes
12

@Dave
I’m glad to hear that the work is on its way:) Please let me know If I can help in any way.

As for the name I would suggest “asynchronous update”. This would be in line with “synchronous update” we have available already. Hope we will not only get “post asynchronous update” but also “cancel asynchronous update” to be able to avoid all those f**k ups we all make:)

@bko
I think you would end up with obfuscated variation of what @harrisonhjones described. I love his idea more until @Dave’s development is done and available.

1 Like
13

What would be nice in addition to the queuing of events for the Spark would be for “cloud variables”

These would be similar to the ones you publish from the Spark its self but instead would be published from the Spark Cloud

The variables could be used to allow the Spark to pick up from a previous run, or in this case allow for you to set a variable indicating you want the Spark to wait for an update etc

Another use would be if you want to adjust the behaviour of the Spark core with out updating the Spark each time, or needing to use flash/EEPROM to save the variables

What does everyone else think?

14

ThingSpeak TalkBack API (TalkBack allows any device to act upon queued commands) should be an interesting way to help (and/or do many others things/actions)
https://thingspeak.com/docs/talkback

15

There’s an issue for firmware control of OTA updates - https://github.com/spark/firmware/issues/375

1 Like
16

I too have trouble flashing new firmware to a sleeping photon. I tried to add a 10 second delay, but it’s clearly not enough. I’ve been looking through the forums, but most of the information I find is old and I don’t know if it’s still applicable.

What’s the status of these functions? I see the github issue isn’t closed even though they’re listed in the documentation, although there’s practically no information about them. Have they been implemented? Can I do something like this?

while (System.updatesPending()) {
  delay(2000);
}

Ideally, I’d like to be able to hit Flash on the Web IDE and have the photon update the next time it wakes up. Is this doable now?

17

I’ve done a bit of testing with the single Photon I’m doing development work on, but pressing the lighting bolt to send a firmware update just times out if the Photon is asleep.

I’d like to have this as an option as well (even if I need a little code to deal with it) as I too have an app that needs to sleep for 30-60 min at a time, and getting a firmware update to it in the field is pretty tricky.

18

@Alex_ I vote for your idea.

1 Like
19

I asked Particle’s CTO last night about this (via their YouTube broadcast), and there’s not a good way to do this now. However, when the Electron ships at the end of Jan (~90 days from now) he said there will be the ability to do this as they have to build it into the Electron. Functions from the Electron that makes sense for the Photon will be ported (my words, not his exact words).

For obviously reasons, he said they were putting 100% of their development effort into the Electron and its firmware, and doing only bug fixes with the Photon until then.

So not great news for now, but it sounds like it’s just a matter of time.

1 Like