Bosch IoT Remote Manager has a near generic support for Bosch IoT Rollouts by implementing the Direct Device Integration API (DDI) of Rollouts (See the Rollouts DDI documentation for more information). This grants Remote Manager the ability to act as a target (device) in Rollouts, allowing you to distribute different updates from Rollouts to Remote Manager.

Update flow

Remote Manager connects on a periodic timer to Rollouts, and recognizes/understands specific update types, (this has to be configured manually in Rollouts):

  • Container - See the Container management page. Json descriptors will go in the Software Repository as "OCI Containers" and the actual containers (in most cases .tar files) will be uploaded as "OCI Images" in the Software Repository.

  • Firmware - See the Perform a Firmware update page.

These types are case insensitive. But you must use exactly "container" or "firmware" as software types.

For type "Container" and type "Firmware" the files will be saved on the file system, due to the possibility of large size (but will be still visible in the Software Repository )

Once you create an update type in Rollouts which Remote Manager recognizes, assigning it to the target will result in Remote Manager downloading it and storing it in the Software Repository. After the artifacts are downloaded, a rule will be created automatically. This rule will be designed to apply (install) this specific update type to all Edge devices connected to Remote Manager. This is the default behavior, but you can edit this rule if you prefer. Since the artifacts are stored in the Software Repository you can use them for further actions (either manually or through the Rule Engine), you do not need to download them from Rollouts again.

Together with the rule, an alert will be created, indicating that the rule is ready for execution. Alerts are usually shown for system errors, but in this case they are used for notification purposes. When you enable the rule this alert will disappear - assuming the Remote Manager admin has acknowledged this update.

From a Rollouts perspective, a successful download is not equal to a successful update. Downloading it is only part of the update. Rollouts will still await feedback from the target (Remote Manager). Multiple status responses can be sent from Remote Manager, until it finishes the update. The executions from the generated rule will be sent as a result to the Rollouts update. If the response is success this means that all devices finished with success. If 99 devices finished with success, and 1 with error, the end result of the rule will still be error.

When Assigning a Distribution Set to Remote Manager, it is best to select the default option which is "Forced". Selecting the "Download only" option will close the update case when the files are downloaded to Remote Manager and you won't see further feedback from the update on the devices.

We would recommend keeping the pattern: 1 update → 1 artifact. It is best to not include more than 1 container or firmware in the update!

Cancel an update:

If the update is in running state (not yet in "Received"), or you just misclicked with an assignment, you can immediately cancel the update by clicking "Force Quit" before Remote Manager downloads it.

If Remote Manager has downloaded the update (status is "Received"), you have to click the "Cancel" action. Then two things can happen:

  • If the Remote Manager admin has not started the update, it will delete the automated rule, and pull down the alert ("notification").

  • If the update has started (the rule is in running state), Remote Manager will try to cancel this execution. However, some devices may have been already updated, and some not.

In both cases Remote Manager with return success feedback, to mark the cancellation as successful, so the Rollouts admin could proceed with the next update.