Supported Protocols
The IoT Emulator supports multiple IoT communication protocols.
LWM2M (Lightweight M2M)
LWM2M is a device management protocol designed for IoT devices, built on top of CoAP.
Features
-
Device registration and lifecycle management
-
Resource observation and notification
-
Firmware update support
-
Bootstrap support
Default Ports
-
CoAP over UDP: 5683 (unsecured), 5684 (DTLS secured)
-
CoAP over TCP: 5883 (unsecured), 5884 (TLS secured)
The transport (UDP/TCP) and concrete port are chosen in the Protocol Options tab.
Protocol Options
These are the defaults used by the emulator (from lwm2m_gui.properties); the Protocol Options tab exposes many more advanced fields (OSCORE, firmware/software update timing, DTLS CID, content format, thread counts, etc.).
| Option | Default | Description |
|---|---|---|
Version |
1.0 |
LWM2M Enabler version — |
Transport |
UDP |
|
Registration Lifetime |
6000 |
Registration validity in seconds ( |
Registration Timeout |
600 |
Seconds to wait for a registration response ( |
ACK Timeout |
10000 |
CoAP acknowledgment timeout in ms ( |
Bootstrap |
false |
Register against a bootstrap server before the management session ( |
Notification Type |
CON |
|
MQTT
MQTT is a lightweight publish-subscribe messaging protocol.
Protocol Options
The Protocol Options tab for MQTT exposes the fields below (from mqtt_gui.properties).
| Option | Default | Description |
|---|---|---|
Username |
(empty) |
MQTT broker username (optional) |
Password |
(empty) |
MQTT broker password (optional) |
QoS Level |
1 |
Quality of Service for publish/subscribe — |
Port |
1883 |
Broker port — |
CoAP (Constrained Application Protocol)
USP (User Services Platform)
USP (TR-369) is the next-generation protocol for device management, replacing TR-069.
Features
-
Controller-Agent architecture
-
Four Message Transfer Protocols (MTPs): STOMP, CoAP, WebSocket, MQTT
-
Protobuf message encoding
-
Bulk data collection
-
Configurable session handling, onboarding and TLS host-name verification
Default Ports
Each MTP has its own plain/secured port pair (selected in the Protocol Options tab):
| MTP | Plain | Secured |
|---|---|---|
STOMP |
61617 |
61618 |
CoAP |
5783 |
5784 (DTLS) |
WebSocket |
8025 |
4430 (TLS) |
MQTT |
18881 |
18882 (TLS) |
Protocol Options
| Option | Default | Description |
|---|---|---|
MTP |
STOMP |
Message Transfer Protocol — |
Endpoint ID |
auto |
Agent endpoint identifier ( |
Protocol Version |
1.0 |
USP protocol version — |
MQTT QoS |
1 |
QoS for the MQTT MTP — |
MTP Ping Interval |
0 |
Seconds between MTP keep-alive pings, |
MQTT Connect Retry Time |
5 |
Minimum delay (sec) between MQTT reconnect attempts. Maps to |
MQTT Connect Retry Max Interval |
30720 |
Maximum delay (sec) for the exponential reconnect backoff. Maps to |
MQTT Connect Retry Interval Multiplier |
2000 |
Backoff multiplier in units of 0.001 (informational; the underlying Paho v5 client uses its own exponential schedule between min and max). Maps to |
| When the USP agent is bound to MQTT, an unexpected disconnect triggers automatic reconnect with the delay range above. After a successful reconnect the agent re-subscribes to its reply-to topic so that pending controller requests can resume. |
TLS Authentication
When the USP agent communicates with the MQTT broker over TLS, the emulator
supports both mutual (client + server) authentication and server-only
authentication. The mode is controlled by the FT_TLS_AUTH environment
variable (or -Dft.tls.auth JVM property): 1 (default) enables mutual auth,
0 switches to server-only auth.
See TLS Authentication Mode in the Installation Guide for details and examples.
FSH_HUB
Proprietary protocol for FSH Hub smart-home gateways. It is built on top of the MQTT client (JSON-RPC over MQTT) and overrides the default QoS to 2.
Transport
-
MQTT broker, ports 1883 (plain) / 8883 (TLS) — same as MQTT
-
Default QoS 2 (exactly-once delivery)
Topics
The emulated hub subscribes to and publishes on the friendlytech/oneiot/api/v1/… topic namespace:
| Topic | Direction | Purpose |
|---|---|---|
|
subscribe |
Incoming RPC requests ( |
|
subscribe |
Event acknowledgements from the server |
|
publish |
RPC responses back to the server |
|
publish |
Telemetry events and parameter updates |
Protocol Options
In addition to the MQTT fields, the FSH Hub Protocol Options tab (from fsh_hub_gui.properties) exposes a sensor-scanning simulator:
| Option | Default | Description |
|---|---|---|
|
true |
Scan/attach sensors asynchronously instead of blocking |
|
true |
Add all sensors in a single bulk operation |
|
1000 |
Delay in ms between sensor additions (when not bulk) |
|
PowerMeter,DoorBell |
Comma-separated list of sensor categories to generate |
|
1 |
Number of sensors to create per category |
DUSUN
Protocol support for Dusun gateway devices. Like FSH_HUB it rides on the MQTT client (JSON messages over MQTT), but overrides the default QoS to 0 (at-most-once).
Topics
The gateway is addressed by its MAC address:
| Topic | Direction | Purpose |
|---|---|---|
|
subscribe |
Commands addressed to the gateway |
|
publish |
Reports/responses from the gateway |
Message Format
Messages are JSON with a reportAttribute envelope, for example:
{
"type": "reportAttribute",
"from": "GATEWAY",
"to": "CLOUD",
"mac": "30:ae:7b:26:2d:46",
"deviceCode": "...",
"time": 1717579200,
"data": { }
}
DUSUN currently has no dedicated _gui.properties file — it reuses the MQTT connection settings and a fixed gateway MAC. There is no separate *Protocol Options page for it.
|