Polite deployments post blinkup

The docs state “Any device which is manually power-cycled will receive and apply the impOS update irrespective of your use of polite deployment”, however it’s unclear if polite upgrades are respected after a blinkup or not.


In general, any device connecting from a cold boot – e.g., power cycling – will be upgraded to the current stable OS and deployed code.

Polite deploys, whether OS or code, are only triggered for devices that are online or warm-booting – they’re meant to be a method of guaranteeing that devices won’t unexpectedly stop what they’re doing due to an upgrade, not a method of stopping a device from upgrading at all.

I’ve been told I could have been clearer…

Polite deploys, whether OS or code, are only triggered … should read Polite deploy handlers, whether OS or code, are only triggered …

So… they will ignore polite deployments post blinkup?

Reason I ask if we have installers installing our devices and post blinkup they have to configure a few things on the device so it’s a bit annoying that they have to wait for an OS update to download and install before they can finish the installations. It would be better if we could delay the upgrade for a minute or two so that they could finish the installation without being held up.

Are there any hooks available agent side to know when a device is going to download a new OS update and will restart? Maybe at least letting the users know what is going on would partially help.

At the moment we just add a 15 second delay in our app post all blink ups to account for if a new OS update is happening. But that in itself slows things down.

The crucial point to remember is that polite deployment only works when Squirrel is running.

This makes sense: only if Squirrel is running can your code intercept the signal from the server to restart and apply the update (impOS or Squirrel).

So is squirrel not running post blink up?

That’s not what I’m saying. I’m just pointing out that until Squirrel is running — and until server.onshutdown() is called — a device’s impOS can be updated.

This is why it’s handy to ensure production devices load their application code after blessing, rather than after first end-user BlinkUp, as their Squirrel will start 10s after power-on, ie. after the initial connection timeout. In this case, by the time BlinkUp has taken place, your polite deployment handler should have been registered and so when the device talks to the upgrade server after it has been enrolled, and the upgrade server tells it there is an impOS update waiting, its polite deployment handler is called.

One of the reasons this happens is because it allows people to use recent APIs in their code without worrying about old OS versions in the field; when a device that has been sitting in stock somewhere comes online (after a blinkup), it’ll get the latest OS version, followed by the latest application squirrel code.

After that point, the device’s polite upgrade handler will be notified of pending OS updates (when they connect) and pending deploys (when they happen, or when they connect, whichever is sooner) and are able to delay or accept the update.

Note that polite upgrades work for devices that are mostly offline (eg ones that run from batteries and ping in regularly). Such devices are allowed to delay receiving updates until convenient too.


Our internal wishlist contains a “BlinkUp SDK should advise of OS updates” story, but that hasn’t made it as far as the internal roadmap.

Other customers have used logic a little like this with success, though:

  • blinkup completes successfully (imp has connected with one-time token)
  • mobile device gets agent ID returned from polling
  • mobile device (or cloud app) tries for a 10 seconds to talk to agent; if the agent still returns 404 after 10 seconds, then the imp is upgrading
  • when the device comes back from upgrade, the agent will be started

This happens because a firmware update happens before the device hits its final “home” server, which is where the agent runs.