Device Simulator

The Device Simulator uses the selected device's identity, native model, and simulation behavior to test state reports, actions, and events in the browser before hardware is ready. It uses the same MQTT protocol as the SDK; with an IoT platform, simulated reports enter that platform's device path. Use an approved test record, which has no permanent simulated or real type.

Validate the Device Flow

The simulator is useful when you need to:

• Confirm that commands, properties, and events match expectations after creating a Device Agent.
• Validate conversation control and status display before a hardware prototype is ready.
• Check field names, command parameters, and event definitions before SDK or MQTT access work starts.
• Demo or debug with a device that can come online immediately and respond to commands.

The simulator does not read real sensors, control actuators, or validate firmware, drivers, network behavior, or system permissions.

Prepare and connect

1. Complete device modeling and check state, actions, events, and simulation behavior.
2. Select a test device or create a test record through the adapter's entry.
3. Confirm no other client uses the same MQTT identity.
4. Choose Connect simulator in the state panel and wait for online status and reported state.

The browser connects that device ID to MQTT and starts reporting its initial status and state. The device record keeps its normal name and ID; no separate simulator record or sim- ID is created.

The browser needs a reachable MQTT WebSocket address and valid device credentials. See MQTT Broker. If the adapter does not offer simulation, validate with its test device or SDK.

The simulator is unavailable while a real device is online or the device is in an error state. Disconnect the real client and refresh device status before connecting. Within one browser tab, each Device Agent keeps one simulation session. If the same device is being simulated in another tab, disconnect that session there first.

State and behavior

Initial values come from the model and valid existing state. Missing or invalid fields use a valid model default, enum value, or value that satisfies the field's type and constraints. These simulated values do not represent sensor readings. After a model change, the simulator keeps compatible state, removes deleted fields, and initializes new or incompatible fields.

After connection, the simulated session keeps the MQTT connection open and regularly reports the current state. The status panel updates as new reports arrive.

If the DeviceSpec includes online or connected, the browser session sets those fields to true in its local state while connected. Disconnecting marks the device lifecycle offline, but it does not necessarily rewrite the last reported property snapshot; those fields are refreshed when the next client reports state.

AI modeling prepares browser behavior to relate actions to state. For example, setting a target temperature can update the target field, while a mode change updates the mode field.

Before connecting, review Simulator behavior when creating or editing the Device Agent. See Review simulation behavior. Use the preview to guide validation:

Simulation behavior	What to check after an action
State updates	The reported field receives the declared parameter, fixed value, or explicit enum mapping
No state change	The action returns its result and existing state remains unchanged
Unspecified	Inspect the result provided by the access option; describe and review generated behavior first if a simulated state change is needed

Keep the browser-connected device selected, then enter a control request in the conversation area:

Set the target temperature to 24 degrees and switch to auto mode.

The Agent generates an available operation and the simulator validates it using the current protocol. Check the action and parameters in the conversation, then compare Reported state with the previewed effect. Invalid parameters or mapped values fail without applying the state change.

When an action has no declared simulation behavior, the access option determines its result:

Access option	Undeclared action behavior
Devices managed directly by Device Agent	Returns an unsupported-action result
EMQX Fleets	Updates state only when every parameter matches a writable property and its constraints; otherwise returns unsupported
ThingsNeural	Acknowledges the service without changing reported state

Custom action names work when the model and simulation behavior declare their exact names and effects. The simulator does not infer effects from an action name, simulate physical processes over time, or generate threshold events automatically.

After changing the model, review simulation behavior and test the affected actions again. Simulation validates the interaction path; validate hardware execution separately.

Report an event manually

Keep the browser connection online and choose Simulator report:

1. Select an event defined by the model.
2. Fill its Payload, or use automatic generation to prepare data.
3. Check field names and types, then choose Emit event. For an event without payload fields, use {}.
4. Inspect Latest reported events and the execution history of matching workflows.

Use only fields declared by that event. Events do not automatically update current state. If state should change too, report a new state through conversation or MQTT. A real SDK or MQTT client continues to report its own events without using this browser action.

Validate automation

After validating the model and interactions, create a simple Workflow and use a simulated event to test its conditions and actions. Use Scheduled Tasks to test timed execution.

If a workflow does not trigger, check the event name, condition fields, enabled state, and device scope. Simulation does not validate firmware, drivers, or device networks. Repeat critical checks after connecting hardware.

Disconnect and switch to hardware

Choose Disconnect to end simulation while retaining the device record. Closing or refreshing the page also ends the browser session.

Before connecting an SDK or real MQTT client with the same identity, disconnect simulation, configure the device program, and explicitly start it. Disconnect the real client before simulating again to prevent identity collisions or mixed reports. Ending either connection only releases the identity—it does not start the other client automatically.

Item	Browser simulator	Real device
Runs in	Current browser	Hardware, gateway, or business service
State source	Defaults, existing state, and simulation behavior	Sensors, actuators, or actual platform data
Action handling	Current adapter simulation behavior	Real device or platform logic
Best for	PoC, demos, and DeviceSpec debugging	Real integration, hardware testing, and production

Continue with SDK Access, MQTT Access, or IoT Platform Integration.