Skip to content
© 2026 The ThingsBoard Authors
Try for free

ThingsBoard Cloud

Choose your data region

Your data stays in the region you choose, for residency and compliance. No credit card required.

Rather run it yourself? Install on your own servers

RPC and device commands

Remote Procedure Calls (RPC) let you send commands to a device and, optionally, receive a response. ThingsBoard Edge supports the same two RPC directions as the server: server-side RPC (platform sends a command to the device) and client-side RPC (device sends a request and waits for a response).

RPC calls are processed by the Edge rule engine. Server-side RPC reaches the device through the Edge transport layer (MQTT, HTTP, or CoAP). The device does not need a direct connection to the cloud server.

Server-side RPC is divided into two subtypes:

  • One-way: The platform sends a command and does not wait for a response. Use for fire-and-forget actions like toggling a relay or sending a configuration update.
  • Two-way: The platform sends a command and waits for the device to respond within a configurable timeout. Use when the result of the action must be confirmed.
  1. Log in to your Edge instance and go to Entities → Devices.

  2. Open the device and select the RPC tab.

  3. Select One-way or Two-way, enter the Method name and Params JSON, and click Send RPC command (►).

    The response appears in the Response field for two-way calls.

Use the RPC call request action node to send an RPC command programmatically. Attach it to any rule chain that processes a message you want to convert into a device command.

The node sends the message as an RPC request to the device identified by the originator. Configure the method name and parameters as a transformation in a preceding script node if the values depend on the message content.

For the full rule node reference, see RPC call request.

Send RPC from a device API (protocol reference)

Section titled “Send RPC from a device API (protocol reference)”

The device subscribes to an RPC topic or endpoint to receive commands sent from Edge or the server:

Subscribe to server-side RPC commands:

Terminal window
mosquitto_sub -d \
-h $EDGE_HOST \
-t "v1/devices/me/rpc/request/+" \
-u "$ACCESS_TOKEN"

Respond to a two-way RPC command (replace {requestId} with the ID from the received message):

Terminal window
mosquitto_pub -d \
-h $EDGE_HOST \
-t "v1/devices/me/rpc/response/{requestId}" \
-u "$ACCESS_TOKEN" \
-m '{"result": "done"}'

Client-side RPC lets the device send a request to Edge and receive a response. The device originates the call; the rule engine processes it and replies.

Typical use cases: requesting the current timestamp, fetching a configuration value stored on Edge, or delegating a decision to a third-party service via an external call node.

When a device sends a client-side RPC request, Edge generates a message with type TO_SERVER_RPC_REQUEST. The requestId metadata field identifies the request. After processing, use the RPC call reply action node to send the response back to the device.

device RPC request
│
▼ (msg type: TO_SERVER_RPC_REQUEST)
┌──────────────┐ Success ┌────────────────┐
│ script node │──────────────▶│ RPC call reply │──▶ device
│ (build reply)│ │ (send reply) │
└──────────────┘ └────────────────┘

Example script that replies to a getCurrentTime request:

var response;
if (msg.method === 'getCurrentTime') {
response = new Date().getTime();
} else {
response = 'Unknown method: ' + msg.method;
}
return { msg: response, metadata: metadata, msgType: msgType };

For the full rule node reference, see RPC call reply.

Send a client-side RPC from a device (MQTT)

Section titled “Send a client-side RPC from a device (MQTT)”
Terminal window
mosquitto_pub -d \
-h $EDGE_HOST \
-t "v1/devices/me/rpc/request/1" \
-u "$ACCESS_TOKEN" \
-m '{"method": "getCurrentTime", "params": {}}'

Subscribe on a separate terminal to receive the reply:

Terminal window
mosquitto_sub -d \
-h $EDGE_HOST \
-t "v1/devices/me/rpc/response/1" \
-u "$ACCESS_TOKEN"

By default, RPC calls are lightweight — they exist only in memory and expire after the timeout. If the device is offline or on a poor connection, the command is lost.

Persistent RPC stores the command in the database and retries it according to a configurable retry count and expiration time. Use persistent RPC when the device may be offline for extended periods.

For the full RPC API reference including persistent RPC fields and protocol-specific details, see: