Customization in OTA flow between IOT device and IOT HUB service

[GauravChoube]

Hi Everyone,

I am working on device update or OTA implementation with azure. Azure has device update feature with IOT hub.
I am utilizing same service for my task.

I want to customized the IOT device update code for OTA operation.
Normally IOT HUB Service initiate the all action(Download, Install, Apply) and based on request device will be acted, once requested action done ,device will update the state to IOT hub service and go ideal state where wait for next action..

I want to add one additional layer or confirmation layer for each action[Download, Install, Apply)] , mean when IOT hub Service request for any action,
device will received as twin properties update. Instead executing the respective process(e.g. downloading the Firmware), device will wait for confirmation/ approval (which is customization part to be implemented ) from external/manual resource.
Once confirmation/approval received, device will resume with flow and execute the respective process( device will start downloading the firmware and update response to IOT HUB Service).

My Question based on above scenario as follow

1. Does it possible to implement above follow with current IOT HUB device update implementation from azure.
2. What will happen if device not reply to IOT hub service for requested action ? Does it discard the whole OTA process ?
3. What is time period of waiting for IOT hub service when it request for any action and waiting for reply ? My target to make wait for 30 days and if no approval or confirmation receive the, reply back to IOT hub service with fail/Discard response.
4. Can I make 30 days waiting period for IOT hub service API response ?

Please answer me as soon as possible. As most of development depend on it.

Regards,
Gaurav Choubey

[jw-msft]

Yes, it should be straightforward to implement.

In the block of std::thread worker, before calling

Download(workflowId, updateType, info) {

it would first make call to your approval service as per its client/server protocol. For example, it could have long-lived keep-alive connection and block to wait for response, or poll over an interval of time and give up after max time (30 days)
, etc.

If the approval is denied, then download worker thread will need to set ADUC_Result result to an failure ResultCode and a reasonable ExtendedResultCode. e.g.

#define E_APPROVAL_DENIED <some 32-bit number>
{
    -1,
    E_APPROVAL_DENIED
} 

It needs to continue calling WorkCompletionCallback so that the state machine can continue it transition to the next state. e.g.

workCompletionData->WorkCompletionCallback(workCompletionData->WorkCompletionToken, result);

What this means for PP Agent is it will send the failure to the cloud for Download UpdateAction and it will show as failed and twin will have extended result code.
For PPR Agent, it will similarly show the entire deployment as failed and twin data will also contain the extended result code.

Exiting early and not transitioning to a final success/fail state and then to Idle will make backend not about device status. For PPR, it will show as in-progress indefinitely and there is no timeout for deployment. It is clearer to allow it to transition to final state so it will show success/failure in portal UX and service operator can see the reason (Approval was denied in this case).

If approved, it would just continue on with the Download() call (and also call WorkCompletionCallback with result of download).

[GauravChoube]

@jw-msft
I have successfully changed the agent with above requirement and its working fine.
Basically i found out the place where code bypass to my customized block of code that do some action and once action fullfilled , i resume agent code by calling same function that should be called in normal flow.
function name is adu_handleaction().