In common with many industrial equipment manufacturers, our customers are cautious about over-the-air updates for devices in thier facilities. A common request is for a local approval step in the application of software updates and configuration changes: It should be possible to "stage" an update - i.e send it to a device, but not apply it until a local user authorised the update through the UI of the device itself.
Today, Cumulocity only undersands a simple lifecycle for software and configuration update operations:
PENDING
EXECUTING, then
SUCCESSFUL or FAILED
Since the PENDING state is used to indicate that the device has not recieved, or has yet to responded to the Operation, at least one additional state is required to accurately reflect the use-case outlined above.
We propose the addition of a "STAGED" state, between PENDING and EXECUTING, which can be set by the device when it has recieved an instruction, but has yet to recieve local authorisation to execute it.
That is correct. Thanks for the feedback Neil.
Hi Niko,
If I understand your proposal correctly, the states would then be:
DELIVERING (update has not yet been acknowledge by device)
PENDING (update has been received by the device, but not yet applied/executed)
EXECUTING (update is in progress at the device)
SUCCESSFUL (update completed successfully)
FAILED (update was not successful)
Is that correct? I think this would work for our use-case, yes.
Hi Neil, thanks a lot for raising this. It is correct, that as of Today the pending state is used for both to indicate that the device has either not yet received the operation or not started the processing. However, instead of using the locally staged step, you can also set the operation into executing mode and add properties to the operation that will be visible in the platform indicating that the operation is staged and waiting for manual approval.
Related to this, we have internally discussed a similar solution proposal, the introduction of a new "DELIVERING" state, that is set automatically by the platform to "PENDING", once the message was successfully delivered to the device. I believe that would also address the use-case that you have described here, correct?
Currently, the implementation of that idea has not been prioritised. We will leave a comment here once this changes.