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.

Showing Module Twin (Module Configuration)

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 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

Module Twin Example

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

You can change the Desired Twin of a Module at any time. However as soon as a redployment to the device is done, the Desired Twin may be overwritten with a new configuration.

It is recommended to change the Desired Twin for debugging and testing purposes.

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:

  1. Make changes to the JSON structure in the Desired state editor (left side).

  2. Click Save to send the updated Desired Twin to the device.

  3. 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:

  1. Click Save.

  2. Wait for the module to apply the configuration.

  3. 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.

  4. 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?