A profile is a JSON file to define the behavior of simulated devices. Each profile can be used by one or more groups in the simulation.json. See Simulation configuration.

They are inside the profiles directory of your simulation and are identified by the file name without extension. The file name must have a maximum on 100 characters between letters, numbers, dash, underscore, and period, ^[\w\.-]+$.

It is used in simulation.json to associate a profile to a simulated group. Each profile can be reused by multiple groups.

See profile_id property of simulation.json.

{
        "connection_settings": {
            "reconnect_interval": {
                "minimum": "PT30S",
                "maximum": "PT60S"
            },
            "disconnect_interval": {
                "minimum": "PT60S",
                "maximum": "PT60M"
            }
        },
        "maintenance_window": {
            "type": "auto",
            "start_time": "now",
            "duration": "PT60S",
            "frequency": "PT10M"
        },
        "fw_update": {
            "allow_update": true,
            "reconnect_after_update": true,
            "progress_messages": [
                {
                    "until_progress": 25,
                    "message": "Unpacking firmware image..."
                },
                {
                    "until_progress": 70,
                    "message": "Installing firmware image..."
                },
                {
                    "until_progress": 100,
                    "message": "Applying firmware image configurations..."
                }
            ],
            "duration": "PT2M",
            "stage_errors": {
                "verify_stage": {
                    "probability": 15,
                    "error_code": 1
                },
                "download_stage": {
                    "probability": 15,
                    "error_code": 1
                },
                "install_stage": {
                    "probability": 20,
                    "error_code": 1
                }
            }
        },
        "device_requests_id": "my_requests",
        "data_streams": {
            "data_streams_id": "my_streams",
            "batch_upload_frequency": "PT80S"
        },
        "file_system": {
            "base_fs_id": "file_system_01",
            "virtual_fs": true,
            "max_size": 400,
            "reuse_previous_fs": true
        }
    }

1. Profile

Property Required Type Description

connection_settings

Object

Connection behavior of simulated devices.

This object specifies how devices connect and disconnect from Remote Manager:

  • Always connected

  • Scheduled disconnections and reconnections

  • Random connection error

By default, if this is not specified, simulated devices are always connected.

See connection_settings object.

maintenance_window

Object

Maintenance status of simulated devices.

This object defines the maintenance status of devices, for how long, and the frequency of the change.

By default, if this is not specified, simulated devices are in maintenance window mode.

See maintenance_window object.

fw_update

Object

Firmware update process of simulated devices.

This object determines the behavior of the device when a firmware update occurs.

By default, if this is not specified, simulated devices firmware updates are always successful, take 120 seconds, and do not report progress.

See fw_update object.

device_requests_id

String

Set of requests associated to the profile.

This identifier must be the name without extension of a JSON file inside the device_requests directory of your simulation. It must have a maximum on 100 characters between letters, numbers, dash, underscore, and period, ^[\w\.-]+$.

If it is not specified, no device requests are registered.

If the corresponding file is not found, the simulation fails to start.

data_streams

Object

Data streams configuration.

If it is not defined, no data is generated.

See data_streams object.

file_system

Object

Simulated devices file system configuration.

If it is not defined, simulated devices file system is not accessible from Remote Manager.

See file_system object.

1.1. connection_settings

At least one of the properties, reconnect_interval or disconnect_interval, must be defined.

connection_settings property Required Type Description

reconnect_interval

Object

Interval to calculate a random amount of time to reconnect after a disconnection.

By default, if it is not defined, devices will not reconnect after a disconnection. This disconnection can be a random one (see disconnect_interval), or one triggered from the CLI (see Connect or disconnect a device), or from Remote Manager, or caused by another factor, for example interrupted Internet access.

See reconnect_interval object.

disconnect_interval

Object

Interval to calculate a random amount of time to disconnect after a connection.

By default, if it is not defined, devices will not randomly disconnect.

See disconnect_interval object.

1.1.1. reconnect_interval

reconnect_interval property Required Type Description

minimum

String

Minimum amount of time to wait before reconnecting after a disconnection.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 30 seconds.

maximum

String

Maximum amount of time to wait before reconnecting after a disconnection.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 30 seconds.

1.1.2. disconnect_interval

disconnect_interval property Required Type Description

minimum

String

Minimum amount of time to wait before disconnecting after a connection.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 30 seconds.

maximum

String

Maximum amount of time to wait before disconnecting after a connection.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 30 seconds.

1.1.3. Usage examples

There is no way to put a simulated device in low-power mode but it is safe to assume that in those cases, the devices would disconnect from Digi Remote Manager. The following snippet shows a connection_settings configuration to schedule disconnections and reconnections for all devices as if they were in low-power mode.

  • The disconnect_interval object states that after every 60 seconds connected, the device should disconnect, that is, go into low-power mode.

  • The reconnect_interval object makes sure that after every 10 minutes disconnected, it should connect, so it can operate as a normal device would.

{
    "connection_settings": {
        "disconnect_interval": {
            "minimum": "PT60S",
            "maximum": "PT60S"
        },
        "reconnect_interval": {
            "minimum": "PT10M",
            "maximum": "PT10M"
        }
    },
    [...]
}

The IoT Device Simulator allows to test how the devices would behave if they suffered a connection lost issue. For that, configure the connection_settings object accordingly to your test scenario:

  • The disconnect_interval object defines that in a minimum time of a minute and a maximum of 60 minutes, it will randomly disconnect once.

  • The reconnect_interval object makes sure this disconnection lasts at least 160 seconds, with a maximum of 200 seconds.

{
    "connection_settings": {
        "disconnect_interval": {
            "minimum": "PT1M",
            "maximum": "PT60M"
        },
        "reconnect_interval": {
            "minimum": "PT160S",
            "maximum": "PT200S"
        }
    },
    [...]
}

1.2. maintenance_window

maintenance_window property Required Type Description

type

String

Maintenance status generation type.

Possible values:

  • auto: The IoT Device Simulator generates the maintenance status based on the provided start_time, duration, and frequency values.

  • custom: The IoT Device Simulator asks a custom application for a device maintenance status every sampling_rate.

auto if it is not defined.

start_time

String

Starting time of the maintenance time window.

Only for auto type.

The value can be now or a ISO 8601 compliant string.

If configured ISO 8601 string is already past, the Digi IoT Device Simulator assumes now as the configured value.

duration

String

Window of time for maintenance tasks.

Only for auto type.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 10 seconds and no more than 60 hours.

frequency

String

Rate at which maintenance window will start.

Only for auto type.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 10 seconds and no more than 60 hours.

sampling_rate

String

Rate at which maintenance status is sampled, that is when new value is requested to the custom application.

Only for custom type.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 10 seconds and no more than 60 hours.

1.2.1. Usage examples

A device can be in maintenance mode to perform some tasks, such as updating its firmware. With this feature, you can simulate when the first maintenance window starts, how long it lasts, and when it should be repeated.

To configure a maintenance window cycle, add a maintenance_window object, fill the start_time of the first cycle following ISO 8601 format, the frequency, and, finally, configure the duration of the maintenance window.

In this case, the first maintenance window starts on January 10th, 2024 and will be repeated every day at the same time. Each maintenance window lasts 1 hour.

{
    "maintenance_window": {
        "type": "auto",
        "start_time": "2024-01-10T10:34:00.000Z",
        "duration": "PT1H",
        "frequency": "PT24H"
    },
    [...]
}

There are scenarios where the maintenance or in service status of a device depends on external parameters. In such cases, the operating mode of the device can be determined by custom code, using an application. See Custom code implementation for more information about the required code.

For example, a device might enter maintenance mode for one hour when certain conditions occur. To achieve this, custom code must be provided, and the maintenance_window must be configured to use your code:

  1. Set the type to custom.

  2. Set the sampling frequency, sampling_rate, to request a new status every minute.

{
    "maintenance_window": {
        "type": "custom",
        "sampling_rate": "PT1M"
    },
    [...]
}

1.3. fw_update

fw_update property Required Type Description

allow_update

Boolean

Whether firmware update is supported.

By default, if it is not defined, its value is true, firmware updates are allowed.

reconnect_after_update

Boolean

Whether device should reconnect after a firmware update.

By default, if it is not defined, its value is true, the device will reconnect after a firmware update.

progress_messages

Array of objects

List of messages to show while update is in progress on a simulated device, once the firmware is completely downloaded in the device.

If it is not defined, no update progress is reported.

If there are more than one message for the same percentage, the first one is used.

See progress_messages object.

duration

String

Amount of time for updating a simulated device when firmware is already downloaded.

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$, with a minimum value of 1 second and no more than 1 hour. If it is not defined, the update is considered to be completed after the download.

stage_errors

Object

Errors in stages of the update process:

  • During verification stage before starting firmware download from Remote Manager.

  • During firmware download from Remote Manager to the simulated device.

  • During firmware installation after it is downloaded.

If it is defined, at least one error stage must be included.

If it is not defined, firmware updates will always succeed.

See stage_errors object.

1.3.1. progress_messages

progress_messages property Required Type Description

message

String

Progress message

until_progress

Integer

Maximum percentage value to use this progress message.

It must be between 1 and 100.

1.3.2. stage_errors

At least one of the properties, verify_stage, download_stage, or install_stage, must be defined.

stage_errors property Required Type Description

verify_stage

Object

Error during verification before starting firmware download from Remote Manager.

download_stage

Object

Error during firmware download from Remote Manager to the simulated device.

install_stage

Object

Error during firmware installation after it is downloaded.

*_stage property Required Type Description

probability

Integer

Error during verification before starting firmware download from Remote Manager.

Must be an integer between 0, never occurs, and 100, always occurs.

error_code

Integer

Error code for the failure.

Possible values:

  • For verify_stage:

    • 1: User denied firmware upload for indicated target

    • 2: Firmware too large to fit in the current available space on the device

    • 3: Version information is invalid

    • 4: Server has not been authenticated

    • 5: Server is not allowed to provide updates

    • 6: Device is configured to reject all upload requests

    • 7: Firmware encountered an error that precludes the firmware upgrade

  • For download_stage:

    • Not applicable

  • For install_stage:

    • 1: Download completed successfully, but the calculated checksum is not the expected.

    • 2: Download did not complete successfully

1.3.3. Usage examples

The devices of the simulation can have their firmware "updated". This means that you can start a firmware update process and have your simulated devices behave as if they were running the update. In this case, the firmware update is successful for all devices of the simulation. To do so, add and configure the fw_update object:

  1. Allow simulated devices to be updated with allow_update.

  2. Enable reconnect_after_update to make the devices reconnect after the update is completed.

  3. Define the duration of the update process once the firmware is downloaded.

  4. Report this update progress with a progress_messages object:

    1. Configure progress thresholds and their corresponding messages throughout the full update process.

    2. Repeat as many times as needed along the 100 steps of the progress.

In the example the firmware update process takes two minutes and there are three different messages: until 25% of progress, until 70%, and until 100%.

{
    "fw_update": {
        "allow_update": true,
        "reconnect_after_update": true,
        "duration": "PT2M",
        "progress_messages": [
            {
                "until_progress": 25,
                "message": "Unpacking firmware image..."
            },
            {
                "until_progress": 70,
                "message": "Installing firmware image..."
            },
            {
                "until_progress": 100,
                "message": "Applying firmware image configurations..."
            }
        ]
    },
    [...]
}

Most of the time the firmware update works fine, but there may be other times when something unexpected occurs. This example configures your simulated devices to fail randomly in different stages of the firmware update process.

To create a simulation where most of devices fail at certain points of the update add and configure the fw_update object as follows:

  1. Allow simulated devices to be updated with allow_update.

  2. Enable reconnect_after_update to make the devices reconnect after the update is completed.

  3. Define the duration of the update process once the firmware is downloaded.

  4. Configure stage_errors object as follows:

    • In the verify_stage stage, a 15% of the devices will fail with an error code 1.

    • Out of the remaining, in the download_stage, a 20% will also fail with the same error code.

    • Finally, in the update_stage, a 80% of the remaining devices will fail with the same error code.

With this configuration most or all of the devices fails in different stages of the update allowing you to understand how your setup would behave under fatal issues.

To see more information on the different firmware update stages, like their purpose or the error codes they can report, see stage_errors.
{
    "fw_update": {
        "allow_update": true,
        "reconnect_after_update": true,
        "duration": "PT2M",
        "stage_errors": {
            "verify_stage": {
                "probability": 15,
                "error_code": 1
            },
            "download_stage": {
                "probability": 20,
                "error_code": 1
            },
            "install_stage": {
                "probability": 80,
                "error_code": 1
            }
        }
    },
    [...]
}

Some devices support on-the-fly firmware updates, that is the firmware is written directly to the non-active partition while being downloaded.

You can configure your simulated devices to behave this way:

  1. Allow simulated devices to be updated with allow_update.

  2. Enable reconnect_after_update to make the devices reconnect after the update is completed.

  3. Define the duration of the update process to be the minimum possible.

{
    "fw_update": {
        "allow_update": true,
        "reconnect_after_update": true,
        "duration": "PT1S"
    },
    [...]
}

1.4. data_streams

data_streams property Required Type Description

data_streams_id

String

Set of data streams associated to the profile.

This identifier must be the name without extension of a JSON file inside the data_streams directory of your simulation. It must have a maximum on 100 characters between letters, numbers, dash, underscore, and period, ^[\w\.-]+$.

If the corresponding file is not found, the simulation fails to start.

batch_upload_frequency

String

Rate at which data samples will be uploaded in a batch (batch upload)

It must be an ISO 8601 duration string, ^PT(?=\d)(\d{1,3}H)?(\d{1,3}M)?(\d{1,3}S)?$. It must be at least 30 seconds.

There are two data upload methods:

  • Batch upload. All accumulated data gathered during the configured period is uploaded to Remote Manager:

    • Samples are accumulated.

    • When the time to upload the data comes, all samples are bundled into the same packet and uploaded at once.

    • This method runs one upload process every configured upload time but each upload holds more data.

  • Individual upload. Data is uploaded to Remote Manager as it is sampled:

    • The upload frequency depends on the sampling period configured for each individual stream.

    • This method runs an upload process per generated sample, but each upload holds less data.

In any case, if the upload data process fails, data is scheduled for upload on the next upload process along with the newest data samples.

1.4.1. Usage examples

Usually, any device would sample data periodically, such as reading sensors or diagnostics data to identify certain conditions. Then, data is bundled and uploaded to Remote Manager periodically.

To simulate this scenario add and configure the data_streams object as follows:

  1. Configure the identifier of the set of data streams to use. In this case, my_streams, so there must be a file called my_streams.json inside the data_streams directory of the simulation.

  2. Enable the batch upload mode by configuring its frequency. In this case, each device that uses this profile uploads sampled data every 80 seconds.

{
    "data_streams": {
        "data_streams_id": "my_streams",
        "batch_upload_frequency": "PT80S"
    },
    [...]
}

Ideally, the preferred way to upload data is as a batch, although there may be times when data must be uploaded as it is sampled. This generates more traffic with Remote Manager.

To achieve this behavior add and configure the data_streams object as follows:

  1. Configure the identifier of the set of data streams to use. In this case, my_streams, so there must be a file called my_streams.json inside the data_streams directory of the simulation.

  2. Disable the batch upload mode by removing the batch_upload_frequency object.

In this case, each simulated device using this profile uploads sampled data as it is generated. If a sample cannot be uploaded, it is added to a queue and uploaded along with the next sample when it is generated.

{
    "data_streams": {
        "data_streams_id": "my_streams",
    },
    [...]
}

1.5. file_system

file_system property Required Type Description

base_fs_id

String

Identifier of the initial structure of the file system for simulated devices using to the profile.

This identifier must be the name of a directory inside the fs folder of your simulation. It must have a maximum on 100 characters between letters, numbers, dash, underscore, and period, ^[\w\.-]+$.

If the corresponding directory is not found, the simulation fails to start.

If it is not specified, simulated devices starts with an empty file system.

virtual_fs

Boolean

Whether the file system to simulate is virtual.

By default, if it is not defined, its value is true, a virtual file system is used.

File system of simulated devices can be:

  • Virtual (true), the IoT Device Simulator stores the file systems of all the simulated devices in RAM memory, which means:

    • The file system of each device is not accessible from your PC’s file browser.

    • If the simulation ends, the file systems disappears.

    • This implies higher memory consumption.

    • The access to files is faster.

  • Physical (false), the IoT Device Simulator uses directories of your PC to generate and store all files of the file systems of all your simulated devices. This means:

    • The file system of each device is accessible from your PC’s file browser.

    • If the simulation ends, simulated file systems remain in the simulation directory, <device_simulator_root>/simulation/<device_id>/fs.

    • This implies higher storage consumption.

    • The access to files is slower.

max_size

Integer

Maximum size of each simulated device file system in bytes.

Real devices have limited storage to allocate their file system. Use this setting to simulate the limits in space of the devices you want to simulate.

reuse_previous_fs

Boolean

Whether to reuse a previous file system for the simulated devices.

By default, if it is not defined, its value is true.

New simulated devices do not have a previous file system, so they start from scratch or using the configured base file system at base_fs_id.

1.5.1. Usage examples

The IoT Device Simulator allows to handle the file system of the simulated devices virtually or physically. A virtual file system is stored in memory and does not consume disk space. This can be useful when having a great number of simulated devices in order to optimize the resources used by the IoT Device Simulator.

A physical file system is a directory, per device, in your computer. This option allows you to have easier access to each file system, but it can impact the disk storage of your computer.

To use a virtual file system, do the following:

  1. Set the virtual_fs option to true.

  2. Configure the maximum file system size.

  3. For this example, we don’t need to reuse a previous file system.

{
    "file_system": {
        "virtual_fs": true,
        "max_size": 400,
        "reuse_previous_fs": false
    }
    [...]
}

The IoT Device Simulator allows you to set an initial file system to every device associated with a profile. This way, each group of devices can have different initial file systems. Also, if you want to rerun a simulation with the same number of devices as a previous one, you can enable the flag to reuse the previous file systems so all changes done to them are kept for the new simulation. To achieve this, you have to:

  1. Configure the initial file system identifier. In this case, file_system_01, so there must be a directory called file_system_01 inside the fs folder of the simulation.

  2. Set the virtual_fs option to false.

  3. Configure the maximum file system size.

  4. Enable reuse_previous_fs option.

{
    "file_system": {
        "base_fs_id": "file_system_01",
        "virtual_fs": true,
        "max_size": 400,
        "reuse_previous_fs": false
    }
}