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

Example of a modules defined in a device 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. {% hint style="info" %} If a modules Current Version is not the same as the Latest Version, a yellow triangle is shown as an indication, that a newer version is available. {% endhint %} The available versions are managed in the [Module Store](/management-portal/designer/modules/module-store.md). Clicking the **Upgrade all** button updates all modules to the most recent version.

Selecting the desired Current Version for a module, from the available versions.

*** ### 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:

Edit Module Settings - currently set to default values (not overridden).

Edit Module Settings - currently overridden

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

Module Settings editor showing the Create Options tab

*** #### 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](https://docs.docker.com/reference/api/engine/version/v1.41/#tag/Container/operation/ContainerCreate) 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:

Field	Description
Source	The module and output endpoint that emits the message. Example: `ConfigModule/outputs/configcommands`
Destination	The module and input endpoint that should receive the message, or `$upstream` to send data to the cloud. Example: `DataDistributionModule/inputs/configcommands`
Priority	A number that influences route selection when multiple routes match. Lower values mean higher priority (default: `0`).
Time to Live (TTL)	How long (in seconds) the message is allowed to live before being dropped. This prevents message buildup. Default: `7200` (2 hours).

{% hint style="info" %} Setting the destination to **`$upstream`** will stream messages to the Management Endpoint in the cloud. {% endhint %} *** #### 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**](/management-portal/designer/modules/module-store.md).

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. {% hint style="info" %} Module developers can declare both **required** and **optional** parameters.\ Parameters marked with an asterisk **(\*)** are **required**.\ You must enter a value to make the configuration valid. {% endhint %} The entered value are converted into either a **Desired Twin** or **Environment** value, that are delivered when the device is deployed. {% hint style="info" %} Click **Restore to defaults** to reset all parameter values to their original default values (as defined in the Module Store). This is useful if you want to undo changes or start fresh. {% endhint %} *** #### 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.

Editing the Desired Twin for a module that does not have Parameters defined.

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.

Example of Environment payload, based upon Parameters of type ENV.

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tricloudnexus.io/management-portal/management/device-configuration/modules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.