Updates for DTDL V2 and Summer Refresh

[dipannita08]

Summary of Changes:

• Pnp Bridge now uses DTMI and adapts with other DTDL V2 changes (semantic types etc.)
• Remove Interface IDs from bridge core and adapters
• Make use of a top-level root interface and change all previous interface instances to components
• Remove DCMs, update interface models
• Submodule update SDK changes from public-preview-pnp (Interface creation, registration)
• Add telemetry for Bridge components
• Move to IoT Hub SDK & Use Pnp Serialization library (which can be found here)

• Moved bridge core and all adapters to adapt to design changes

  • Summary Of Design Changes:

  • The device adapters no longer use Pnp APIs to handle property and command updates for each interface. They also no longer make use of digital twin client handles for each interface. Instead, they set up all the resources required to complete various types of communication between the device and the cloud service and allow the core of the bridge to enable end-to-end communications by performing arbitration and management of adapter components. There is now only one cloud to device communication channel corresponding to the top level root interface.

  • Device adapters create “component handles” and pull necessary IoT hub device client information from the core of the bridge to facilitate sending of telemetry messages, property updates or responding to command and property updates, when the core of bridge elicits such an action from a particular adapter.

  • Device adapters implement two additional callbacks, to handle cloud to device property update callbacks and to handle callbacks to process commands. These are invoked by the core of the bridge when the payload associated with the IoT Hub device client of the top-level root interface indicates that the intended callback is for a specific component. The Pnp bridge routes this callback to the appropriate adapter that owns the component corresponding to the payload.

  • Adapters must set these property update and command callbacks as a part of the component handle context.

  • User context for property updates, commands and telemetry messages per component is no longer discretely sent to the cloud and captured as a part of callbacks. Instead they are always stored as a part of device context on the component handle.

  • The core of the bridge no longer registers each Pnp interface, instead it builds a contiguous list of modelled component identities and uses this to register the IoT hub device client.

  • The creation and registration of the IoT hub device client is done after the adapter and component resources are set up by the bridge.

  • The core of the bridge also allows retrieval of the IoT hub device client handle by the adapter with the help of another additional adapter API: PnpInterfaceHandleGetIotHubDeviceClient. Adapters may start calling this API any time after the core of the bridge initiates the start of telemetry flow for each component (PNPBRIDGE_INTERFACE_START) to get a valid device client handle

Validation:

• [x] E2E device setup and validation of telemetry flow, property updates, commands of devices using each adapter on Azure IoT Explorer
• [ ] E2E device setup and validation of telemetry flow, property updates, commands of devices using each adapter on Azure IoT Central

Documentation:

• Updated documentation on design changes can be found here

[Shyamal-V]

"pnp_brudge_config_source": "local",

Typo #Resolved

---

Refers to: pnpbridge/docs/schemas/config-modbus.json:18 in f921f8a. [](commit_id = f921f8a807a959937b03e0e731f76bb87c546d04, deletion_comment = False)

[Shyamal-V]

*           DigitalTwin_InterfaceClient_SetCommandsCallback. The adapter must be ready to receive 

• These DigitalTwin_* APIs no longer exist so I think this description needs to be reworked.
• This call back cannot be used to "create a new azure pnp interface client" any more.

Lets discuss this offline. #Resolved

---

Refers to: pnpbridge/src/pnpbridge/inc/pnpadapter_api.h:69 in f921f8a. [](commit_id = f921f8a807a959937b03e0e731f76bb87c546d04, deletion_comment = False)

[Shyamal-V]

*           DigitalTwin_InterfaceClient_SetCommandsCallback. The adapter must be ready to receive 

The adapter should call IoTHubDeviceClient_SetDeviceMethodCallback to register a PnP command callback, IoTHubDeviceClient_SetDeviceTwinCallback for PnP properties #Resolved

---

Refers to: pnpbridge/src/pnpbridge/inc/pnpadapter_api.h:69 in f921f8a. [](commit_id = f921f8a807a959937b03e0e731f76bb87c546d04, deletion_comment = False)

[Shyamal-V]

                                      DigitalTwin_InterfaceClient_Create

Needs an update. Should this now supply IOTHUB_DEVICE_CLIENT_HANDLE to the adapter so it can register its callbacks? Lets discuss offline. #Resolved

---

Refers to: pnpbridge/src/pnpbridge/inc/pnpadapter_api.h:86 in f921f8a. [](commit_id = f921f8a807a959937b03e0e731f76bb87c546d04, deletion_comment = False)