User Guide

When each device needs its own target server, data model or credentials, use Single Emulator mode instead of the group settings:

Every device created this way is written to configuration/devices.json, appears in the Device library, and is recreated automatically the next time the emulator session is initialized. Full reference: Single Emulator Mode.

Use the CPE Amount controls in the toolbar to scale beyond a single device:

Beside the CPE Amount title the page shows the total the two fields make — Groups × Concurrent devices, which is what Initialize tree creates once Save settings has sent the values — and calls it a large run, in the warning colour, above 1000 devices. That threshold is a hint, not a limit.

Set the values, then Initialize tree and Start as usual. Every device appears as a row in Active Devices.

Instead of the bundled *_resources.xml, the emulator can pull a parameter tree from an existing device record. Full field reference: Extract CPE from DB.

In the web interface this is the Extract CPE from DB section in the left column. The emulator must reach the database over the network (from its pod, when it runs in Kubernetes). The shipped image carries the MySQL driver only.

To make a parameter change on its own while the emulator runs (e.g. a fluctuating sensor reading), give it an Autoupdate config: a numeric range with a step and a period, or a pipe-separated Dataset (v1|v2|v3) to cycle through fixed values, optionally applied to every device that owns the same parameter. Detailed fields: Set a Parameter Value.

In the web interface this is the Autoupdate section under Set value; it works for session devices and for devices started from Single mode.

A rule runs JavaScript on every parameter update of every device, whatever the rendering — the body of onParamUpdated(param, device, ctx), persisted to rules.js. In the web interface it is edited in the Rules dialog (controls bar). See Rules.

Capture the current device list and parameter values, then restore them later. The set is kept on the server, in configuration/snapshot.json; nothing is downloaded to the browser.

See Active Devices. The same actions are available over REST — see Snapshot endpoints.

Every UI action has a REST equivalent for scripting and CI. The base URL is http://localhost:8556/api and Swagger UI is at http://localhost:8556/swagger-ui.html.

Full reference: REST API.

The dialog renders the options declared in <protocol>_gui.properties for the active protocol as checkboxes, dropdowns and text fields — for LWM2M for instance transport, bootstrap, version, Lifetime(sec), the thread counts and the OSCORE keys. Save writes them through POST /api/protocolOptions so they apply to the devices started afterwards; Cancel discards the edits.

Each device is one card showing its Client ID, serial number, protocol, serverIp:serverPort, a security badge when the mode is not UNSECURE, and the live status reported by the protocol stack (for example SN-0001→registered or SN-0001→no connection).

Each card also carries a connection badge — a coloured dot and a word saying whether the device is connected to its own server, as its protocol reports it. Hover the badge for the same explanation.

A USP device keeps Connected when its MTP connection drops and no further traffic arrives: the emulator does not detect that.

The status line and the badge can disagree — an MQTT device’s status keeps reading connected after the broker drops it — and the badge is the one to go by. The header’s count of connected devices counts the cards that read Connected.

Every device created in this mode is written to configuration/devices.json. The Device library panel lists those stored configurations with their state (Active when the device is currently held by the emulator, Offline otherwise), protocol, target server and security mode.

Devices in the library are recreated automatically when the emulator session is initialized, so restarting the container brings the same devices back.

Open on a device card opens a dialog built from four blocks:

Close the dialog with the X in the header or by clicking the dimmed backdrop.

Shows the current emulator state:

Configure security settings for the connection:

Protocol-specific settings rendered dynamically from {protocol}_gui.properties. Values are persisted to the server-side properties file immediately on change — there is no need to click Save settings afterwards.

Examples per protocol:

Choose which XML device tree the next Initialize tree loads, and maintain the list:

The Parameters tree button opens a near-fullscreen modal (≈90% of viewport) that shows all parameters of the chosen device.

Features:

Modify a device parameter in real-time. Pick a parameter from the Parameters tree viewer first.

Click Set value to push the new value into the running device.

Configure how the emulator periodically mutates a parameter while running, per parameter.

Click Apply. A running device starts sending the new values on the next period; a stopped one keeps the setting for its next start.

The values the selected parameter has taken on its device, newest first, each with the time it was recorded (UTC), up to the last 50. Values are recorded while rendering is FULL or LAZY; with OFF nothing is recorded and the section says so. The reload button fetches the list again; Set value reloads it too.

Edit the JavaScript rule the emulator runs on every parameter update of every device. The rule is the body of function onParamUpdated(param, device, ctx) and is persisted to configuration/rules.js. In the web interface, Rules in the controls bar opens it in a dialog; the desktop shows it as a tab.

A rules.js that does not compile at startup leaves no rule active; the dialog says why. The last error a running rule raised is shown under the editor until the next successful compile.

Three lists under the panel header narrow the docked table without opening anything else:

Each list matches its field exactly, All turns it off, and the three combine. They apply to the rows already in the table and to every row that arrives while they are set; when nothing matches, the table says No entries match the filters. The lists keep their names through Clear logs, so a choice survives a clear.

Expand in the panel header opens the log over the whole page. It shows the same entries with the whole payload, and has a text filter of its own: type any part of a row — its time, device, direction, event, options or payload — to keep only the rows that contain it, and the counter says how many match. The docked Device, Direction and Event lists do not apply here. The view has its own Pause, Clear and Close; Esc first empties the filter, then closes the view.

Click any row, in either table, to open that entry’s detail — the analogue of the desktop GUI’s double-click. In the fullscreen view each row also ends in a Raw message button, which is the way in from the keyboard. The detail’s heading line gives the moment exactly as it was sent, the device, the direction and the event; below it are the whole Options, Payload and Raw message. Close or Esc closes it, and when it was opened over the fullscreen view, Esc closes the detail first and the view with the next press.

Copy payload puts the payload on the clipboard. A browser lets a page write to the clipboard only over https or from localhost; when the emulator is opened over plain http under a host name or an IP address, the button selects the payload in the dialog instead, and a message tells you to press Ctrl+C. The button is disabled for an entry with no payload.

Pause — in the panel header, or in the fullscreen view — stops the polling for both tables, so the rows hold still while you read them. Both buttons then read Resume, and the one in the panel header is highlighted as well. Resume fetches what arrived in the meantime.

Clear logs — in the control bar, and as Clear in the fullscreen view — asks for confirmation, then empties both tables and the server-side ring buffer: nothing is kept anywhere to scroll back to.

Whether raw protocol messages are written to the ring buffer at all is the footer’s logging option (see Footer Options).