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 |
---|---|---|---|
Object |
Connection behavior of simulated devices. This object specifies how devices connect and disconnect from Remote Manager:
By default, if this is not specified, simulated devices are always connected. See |
||
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 |
||
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 |
||
String |
Set of requests associated to the profile. This identifier must be the name without extension of a If it is not specified, no device requests are registered. If the corresponding file is not found, the simulation fails to start. |
||
Object |
|||
Object |
Simulated devices file system configuration. If it is not defined, simulated devices file system is not accessible from Remote Manager. See |
1.1. connection_settings
At least one of the properties, reconnect_interval
or disconnect_interval
, must be defined.
connection_settings property |
Required | Type | Description |
---|---|---|---|
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 See |
||
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 |
1.1.1. reconnect_interval
reconnect_interval property |
Required | Type | Description |
---|---|---|---|
String |
Minimum amount of time to wait before reconnecting after a disconnection. It must be an ISO 8601 duration string, |
||
String |
Maximum amount of time to wait before reconnecting after a disconnection. It must be an ISO 8601 duration string, |
1.1.2. disconnect_interval
disconnect_interval property |
Required | Type | Description |
---|---|---|---|
String |
Minimum amount of time to wait before disconnecting after a connection. It must be an ISO 8601 duration string, |
||
String |
Maximum amount of time to wait before disconnecting after a connection. It must be an ISO 8601 duration string, |
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 |
---|---|---|---|
String |
Maintenance status generation type. Possible values:
|
||
String |
Starting time of the maintenance time window. Only for The value can be If configured ISO 8601 string is already past, the Digi IoT Device Simulator assumes |
||
String |
Window of time for maintenance tasks. Only for It must be an ISO 8601 duration string, |
||
String |
Rate at which maintenance window will start. Only for It must be an ISO 8601 duration string, |
||
String |
Rate at which maintenance status is sampled, that is when new value is requested to the custom application. Only for It must be an ISO 8601 duration string, |
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:
-
Set the
type
tocustom
. -
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 |
---|---|---|---|
Boolean |
Whether firmware update is supported. By default, if it is not defined, its value is |
||
Boolean |
Whether device should reconnect after a firmware update. By default, if it is not defined, its value is |
||
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 |
||
String |
Amount of time for updating a simulated device when firmware is already downloaded. It must be an ISO 8601 duration string, |
||
Object |
Errors in stages of the update process:
If it is defined, at least one error stage must be included. If it is not defined, firmware updates will always succeed. See |
1.3.1. progress_messages
progress_messages property |
Required | Type | Description |
---|---|---|---|
String |
Progress message |
||
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 |
---|---|---|---|
Object |
Error during verification before starting firmware download from Remote Manager. |
||
Object |
Error during firmware download from Remote Manager to the simulated device. |
||
Object |
Error during firmware installation after it is downloaded. |
*_stage property |
Required | Type | Description |
---|---|---|---|
Integer |
Error during verification before starting firmware download from Remote Manager. Must be an integer between 0, never occurs, and 100, always occurs. |
||
Integer |
Error code for the failure. Possible values:
|
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:
-
Allow simulated devices to be updated with
allow_update
. -
Enable
reconnect_after_update
to make the devices reconnect after the update is completed. -
Define the
duration
of the update process once the firmware is downloaded. -
Report this update progress with a
progress_messages
object:-
Configure progress thresholds and their corresponding messages throughout the full update process.
-
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:
-
Allow simulated devices to be updated with
allow_update
. -
Enable
reconnect_after_update
to make the devices reconnect after the update is completed. -
Define the
duration
of the update process once the firmware is downloaded. -
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:
-
Allow simulated devices to be updated with
allow_update
. -
Enable
reconnect_after_update
to make the devices reconnect after the update is completed. -
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 |
---|---|---|---|
String |
Set of data streams associated to the profile. This identifier must be the name without extension of a If the corresponding file is not found, the simulation fails to start. |
||
String |
Rate at which data samples will be uploaded in a batch (batch upload) It must be an ISO 8601 duration string, There are two data upload methods:
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:
-
Configure the identifier of the set of data streams to use. In this case,
my_streams
, so there must be a file calledmy_streams.json
inside thedata_streams
directory of the simulation. -
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:
-
Configure the identifier of the set of data streams to use. In this case,
my_streams
, so there must be a file calledmy_streams.json
inside thedata_streams
directory of the simulation. -
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 |
---|---|---|---|
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 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. |
||
Boolean |
Whether the file system to simulate is virtual. By default, if it is not defined, its value is File system of simulated devices can be:
|
||
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. |
||
Boolean |
Whether to reuse a previous file system for the simulated devices. By default, if it is not defined, its value is New simulated devices do not have a previous file system, so they start from scratch or using the configured base file system at |
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:
-
Set the
virtual_fs
option totrue
. -
Configure the maximum file system size.
-
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:
-
Configure the initial file system identifier. In this case,
file_system_01
, so there must be a directory calledfile_system_01
inside thefs
folder of the simulation. -
Set the
virtual_fs
option tofalse
. -
Configure the maximum file system size.
-
Enable
reuse_previous_fs
option.
{
"file_system": {
"base_fs_id": "file_system_01",
"virtual_fs": true,
"max_size": 400,
"reuse_previous_fs": false
}
}