Why a command stays queued, times out, expires, fails or is refused – command states, persistence and expiry, tiers and permissions, plain sessions and limits.
This page helps when a command sent from the device page, a board control, a SCADA symbol, a rule, a flow or the API does not do what you expect. Start from the command’s history: open the device’s Commands tab and the command in History. Its state and its Progress usually say what happened.
Read the state
State
Meaning
Next step
Queued
Stored, waiting for the device
See “Stays queued” below
Sent
Sent, not yet confirmed by the device
Wait; if it stays, the device may not handle the topic
Delivered
The device received it
Wait for the answer
Successful
The device answered with success
If nothing changed physically, check the device side
Failed
The device answered with an error
Read the Response
Timed out
No answer arrived in time
The command may still have run: “No answer: the outcome is unknown”. Check the device before you send again.
Expired
It expired before it could be delivered
The device was offline longer than Give up after
Cancelled
Someone cancelled it
It stays queued or expires
Cause
Fix
The device is offline and the command is persistent
It waits until the device comes back, at most until Give up after (24 hours by default, at most 7 days)
The device is offline and the command is not persistent
It fails at once: “The device is offline: without “persistent” the command fails at once.” Send it as persistent, or when the device is online.
The device has not subscribed to v1/rpc/req/+ on this connection
Commands are delivered only after that subscription. The device must subscribe again after every connect.
The session is in clear (plain MQTT or plain HTTP)
Commands travel only over TLS sessions, except the ones listed in the profile’s Commands allowed without TLS. Others wait for a TLS session or their expiry.
The device is behind a gateway
Commands to devices behind a gateway are in development. Send commands to the gateway, or to devices that connect themselves. See Commands to devices behind a gateway.
An HTTP device does not poll
HTTP devices wait for commands with GET /api/v1/rpc (long poll). Only one poll per device may be open (409). See Device HTTP API.
It times out
Cause
Fix
The device runs the command but does not answer on v1/rpc/res/{id}
Make it answer with the same id, or send the command as one-way
The answer timeout is too short
Answer timeout (seconds) is 1 to 600 (10 by default)
A long-running job
The device should accept at once ("accepted": true, "job_id": …) and report the result later in the rpc_result client attribute
The answer came after the end
Shown as Answered after the end
A command may reach the device twice. The device must remember the last 32 request ids for 10 minutes and never run one twice. See Sending commands to devices.
It is refused before it is sent
Message or reason
Cause
Fix
bad_params
The parameters do not match the command
Fill every required parameter within its range
confirm_required, confirm_text_mismatch
A high-impact command needs a confirmation, or the typed phrase is wrong
Confirm; type the phrase exactly
method_refused
Factory reset, pairing, Wi-Fi forget and forgetting the cloud are never sent from the cloud
Do these on the device
rpc_method_reserved
The method belongs to a module of its own (for example remote access)
Use that module
rpc_not_supported_by_profile
The profile uses only the Legacy compatible topic scheme, which carries no commands
Send settings as shared attributes, or move the profile to the current scheme
device_not_active
The device is disabled or quarantined
Enable or activate it
payload_too_large
The request is larger than the device accepts (64 KiB by default, 4 KiB for licensed devices)
Send less
device_rate_limited
More than 10 commands to this device in a minute
Wait a minute
“Too many requests for your plan…”
More than 600 commands in the organisation in a minute
A missing button or a permission error means your role or groups lack the tier’s permission. See Groups and permissions.
From a dashboard, a rule or a flow
Where
Common cause
A board control
Only Basic commands are offered to board controls. A command not in the list is not in the profile’s catalog or is of a higher tier. A greyed control has an old or unknown reading, or you lack the permission. See Control cards.
A board control that seems to do nothing
The control asks before it sends (Ask before running is on by default); the command runs only after Confirm
A Rules-card rule
History shows “skipped: device is in Manual” when the device or a place above it is in Manual, or a failed command step. See Manual and auto modes.
A flow
Commands and settings from flows to one device are limited to 30 a minute by default. The command is looked up in each device’s profile; devices whose profile lacks it get nothing. Late messages send no commands. See Alarm, command and notify blocks.
Siteyi çalıştırmak için zorunlu çerezleri kullanıyoruz. İzninizle analiz ve pazarlama çerezlerini de kullanırız. Seçiminizi istediğiniz zaman değiştirebilirsiniz. Çerez politikası
