Command & Control
iRis Cloud RPC (Remote Procedure Call) enables command exchange from the platform to devices through server-side RPC. The platform sends instructions to a device and can optionally wait for the device's response.
Server-Side RPC
Section titled “Server-Side RPC”The platform sends a command to a device — turn a relay on, change a setpoint, trigger a reboot. Commands can be sent from a dashboard widget or directly via REST API.
One-Way vs. Two-Way
Section titled “One-Way vs. Two-Way”| One-Way | Two-Way | |
|---|---|---|
| Device reply | Not expected | Required within timeout |
| Use case | Fire-and-forget commands (turn on LED) | Commands that need confirmation or a result |
| REST response | 200 OK when iRis Cloud sent the command to the device — no visibility into whether the device processed it or succeeded | Device’s reply payload |
Lightweight vs. Persistent
Section titled “Lightweight vs. Persistent”Lightweight RPC is short-lived and memory-resident. If the device is offline when the command is sent, the command is lost. Good for real-time control of always-connected devices.
Persistent RPC is stored in the database with a configurable TTL. If the device is offline, the command waits until the device reconnects. Good for devices with intermittent connectivity or power-saving modes.
Request Fields
Section titled “Request Fields”| Field | Required | Description |
|---|---|---|
method | Yes | Command name, e.g. setTemperature |
params | Yes | JSON parameters. Use {} if none. |
timeout | No | Milliseconds to wait for delivery (default: 10 000, min: 5 000) |
expirationTime | No | Epoch ms timestamp — overrides timeout |
persistent | No | true to store in DB and survive device offline (default: false) |
retries | No | Retry attempts for persistent RPC on timeout |
additionalInfo | No | Metadata attached to persistent RPC records |
Persistent RPC States
Section titled “Persistent RPC States”Persistent commands move through a state machine. Each transition updates the persistent RPC status so you can track command progress.
| State | Meaning |
|---|---|
QUEUED | Saved; awaiting delivery |
SENT | Platform sent to device |
DELIVERED | Device acknowledged (terminal for one-way) |
SUCCESSFUL | Device replied (terminal for two-way) |
TIMEOUT | Delivery timed out; retrying if retries remain |
EXPIRED | TTL elapsed before delivery |
FAILED | All retries exhausted |
Sending Commands from Dashboards
Section titled “Sending Commands from Dashboards”Control widgets such as command buttons, switches, and value controls send server-side RPC commands using the same REST API under the hood. You configure the method name and parameters directly in the widget settings — no code required.
Configuration Reference
Section titled Configuration Reference| Environment Variable | Default | Description |
|---|---|---|
ACTORS_RPC_MAX_RETRIES | 5 | Max delivery retries for persistent RPC |
ACTORS_RPC_SUBMIT_STRATEGY_TYPE | BURST | RPC submit strategy: BURST, SEQUENTIAL_ON_ACK_FROM_DEVICE, or SEQUENTIAL_ON_RESPONSE_FROM_DEVICE |
MQTT_TIMEOUT | 10000 | MQTT delivery timeout (ms) |
COAP_TIMEOUT | 10000 | CoAP delivery timeout (ms) |
LWM2M_TIMEOUT | 120000 | LwM2M delivery timeout (ms) |
SQL_TTL_RPC_ENABLED | true | Enable automatic cleanup of expired persistent RPCs |
SQL_RPC_TTL_CHECKING_INTERVAL | 7200000 | How often expired RPCs are cleaned up (ms) |