Twin
Module Twin Page
The Module Twin page provides a side-by-side view of the module’s Desired Twin State and Reported Twin State.
This page is used for monitoring and adjusting the runtime configuration of a deployed module.
What is Module Twin?
The Module Twin is a JSON-based digital representation of a module’s configuration and runtime state on an Edge device.
Module Twins are used my Modules that uses the Nexus SDK or 3rd party Modules that supports Azure IoT Edge.
For other 3rd party modules, the Module Twin will not be used to configure the Module, as these Modules most often uses Environment Variables or Files for configuration.
Module Twins contains two key parts:
Desired Twin State – The configuration you want the module to have
Reported Twin State – The configuration the module actually has applied and is currently running with
The Desired Twin acts as the target configuration that the platform sends to the module, while the Reported Twin is the real-time feedback from the module back to the platform. By comparing the two, you can verify whether the configuration was applied successfully.
This Twin mechanism allows the platform and Edge modules to stay synchronized and makes it possible to:
Remotely configure modules that is allready running on an Edge device, without having to login on the device
Rapidly Verify applied configurations, or impact of trying out different configuration for the module
Debug and temporarily override settings without redeploying the full Asset Hierarchy
Desired Twin State
The Desired Twin represents the configuration settings that you want the module to run with. This is the target configuration that the IoT Hub sends to the device.
You can edit the Desired Twin directly in the interface:
Make changes to the JSON structure in the Desired state editor (left side).
Click Save to send the updated Desired Twin to the device.
The module will apply the new configuration without needing a full redeployment.
Important: Any manual changes made here will be overwritten if a new deployment is made to the device. This means editing the Desired Twin should primarily be used for:
Debugging purposes
Rapid testing of configuration changes
Reported Twin State
The Reported Twin (right side) is the module’s actual current configuration as reported by the device. This shows the applied state after the module has processed and implemented the Desired Twin.
It also shows the exact timestamp a Json property has been applied to the configuration.
Updating and Verifying Twins
After making changes to the Desired Twin:
Click Save.
Wait for the module to apply the configuration.
Click the Refresh button to re-fetch both the Desired and Reported Twin states from the device. This is useful when verifying if a recent change to the Desired Twin has been applied successfully.
Confirm that the Reported State matches the Desired State.
If there’s a mismatch, it could indicate:
The module hasn’t yet synchronized.
There’s an error preventing the new configuration from applying. In this case you can check the Module Log for any warning or errors that may have occurred when applying the desired state. It is recommended to use the Console Log for this.
Differences View
You can click the Differences button to highlight changes between the Desired Twin and the Reported Twin. This makes it easier to spot discrepancies in configuration.
Use Cases of Module Twin
The Module Twin page is especially useful in scenarios where quick configuration changes or troubleshooting is required. Some common use cases include:
Rapid configuration testing When you need to try different parameter values (e.g., log level, polling intervals, or protocol settings) without creating and deploying a new version of the asset hierarchy.
Debugging and issue resolution If a module is not behaving as expected, you can adjust settings in the Desired Twin, apply them immediately, and observe changes in real time.
Verifying deployment success After deploying a module, use the Twin page to confirm that the Reported Twin matches the Desired Twin, ensuring the configuration was applied correctly.
Temporary overrides In situations where a quick fix is needed - such as pointing to a test broker or alternate data source -you can change the Desired Twin for short-term operation, then revert later.
Performance tuning Adjust settings like buffer sizes, batching thresholds, or retry intervals on the fly to find optimal performance parameters.
Last updated
Was this helpful?