Skip to main content

OTA Firmware update

Customization

Connhex is dedicated to hardware manufacturers: their firmware update strategies, albeit with some commonalities, vary a lot. This is why, for the time being, Connhex offers basic support for OTA updates: you can contact us to see how your current firmware update process fits with Connhex.

OS updates

As of today, Connhex only supports user-space software updates.

Pull update strategy​

Broadly speaking, IoT firmware updates can be separated in:

  • push updates: updates are split into chunks, then sent to the device - typically as MQTT(s) packets, if the protocol is available. The device then recreates the entire update, checks its integrity and applies it.
  • pull updates: the device requests for available updates. If at least one is present, it is obtained as a file download through the HTTP(s) protocol.

By default, Connhex only implements pull updates, since they are better suited for heavy updates. Should your situation be better suited for push updates, you can contact us as usual!

Flow​

The update flow starts with building a firmware package: this can either be stored on a Connhex Remote Init database or on any other file hosting system.

Once the update is available, a re_init message can be sent to any device - either manually or programmatically1. Upon receiving the re-initialization message2, Connhex Edge will:

  • download the update, by authenticating with the usual init_id and init_key credentials
  • overwrite the update folder (typically /opt/connhex/updates)
  • perform the initialization process once again

For additional security, upon the receival of a download request, a token can be generated and exchanged before downloading the file.

  1. This depends on the type of rollout. A common practice is to select a few devices to start and then progressively extend to more.↩
  2. Here's where the custom logic is usually implemented. Want to wait for user approval? Automatically update if inside a given time window?↩