Modules

Use the Modules tab to review and set which containerized modules this device will run for the selected configuration version. The modules to deploy are derived from the Applications, Asset Hierarchy and any individual modules assigned to the device.

The Modules tab makes it possible to manage the following:

• Modules to deploy: Adding and removing modules to deploy, for this device only.

• Module versions: Controlling the module versions to deploy. Module versions added from Applications can not be changed here, but must be changed directly in the Application.

• Module Settings: Managing the module settings, including environmental properties and configuration.

Scope precedence

Only one instance of a module is deployed. If the same module appears in multiple scopes, the highest-precedence scope decides the version and settings.

1. Device Configuration — highest priority Per-device override. Use when this specific device needs a different module or version (e.g., testing a fix or handling unique hardware). If a module is set here, it overrides any definition from Asset Hierarchy or Application.

2. Asset Hierarchy — middle priority Required modules are automatically added, when an Asset Hierarchy is assigned to a device. The modules are added in a "Asset Hierarchy" scope, which overrides any Application scoped modules.

3. Application — lowest priority Modules included in Applications, assigned to a device, are added in Application scope.

Adding Modules

Add a new module to this device configuration by clicking the Add module button. This will open the module selection:

By choosing a module, it will be added to the device configuration, with Scope set to Device Configuration.

Managing Versions

It is possible to control the module versions of Device Configuration and Asset Hierarchy scoped modules. To set the desired module version, choose the version from the available versions, by clicking the drop down lists in the Current Version column.

The available versions are managed in the Module Store.

Clicking the Upgrade all button updates all modules to the most recent version.

Module Settings

Use Module settings to fine-tune how each module runs and how it connects to other modules or the cloud.

Only modules settings in Device Configuration or Application scope can be overridden. Modules in Asset Hierarchy scope are controlled by the platform. The symbol indication for each module indicates the module settings override state:

When clicking on the symbol, the Module Settings editor opens:

Create Options

Create Options define how the container (module) should run on the device. This potentially includes restart policies, mounted volumes, exposed ports, and other container-level runtime settings.

These options follow the Docker container create specification and are provided as a JSON object. This setting is optional, but it allows you to control resource usage and runtime behavior in detail.

Routes

The Routes tab defines how messages flow between modules and possibly direct streaming to the cloud.

Each route specifies a source output, a destination input, and optional routing metadata. This controls how modules communicate with each other and how data leaves the device.

Each route specifies the following parameters:

Parameters

The Parameters tab allows you to configure predefined input fields for a module—such as credentials, modes, timeouts, or feature toggles. These values are used to generate both the module’s Desired Twin and the Environment (JSON payloads sent to the module at startup).

This tab is only visible for modules that declare parameters in the Module Store.

Parameters allow module developers to define a structured and user-friendly interface for configuration. Instead of editing raw JSON, you fill in labeled fields with clear names and descriptions. This makes it easier and safer to configure modules. The parameter type determines weather it belongs the Desired Twin or Environment, and is declared by the module developer when importing the module into the Module Store.

The entered value are converted into either a Desired Twin or Environment value, that are delivered when the device is deployed.

Desired Twin

The Desired Twin tab lets you define the configuration that should be delivered to a module at runtime—using a structured JSON format. This configuration is sent as part of the desired properties in the module’s device twin, and is commonly used to provide settings, credentials, or startup instructions.

If the module is not defined with parameters in the Module Store, the Desired Twin tab is shown as a fully editable JSON editor, and You must manually enter the desired configuration in valid JSON format.

If the module uses Parameters (defined in the Module Store), this tab shows a read-only preview of the JSON that will be sent as the desired twin, based on the values entered in the Parameters tab.

Environment

The Environment tab shows a structured preview of all Environment Variable parameters defined for the module. These variables are passed into the container at runtime using Docker’s standard env format.

This tab is only visible for modules that declare parameters of type ENV in the Module Store. It is read-only, and its content is based on the values you’ve entered in the Parameters tab.