Definition
Remote Control refers to issuing Downstream Command from the platform to devices to achieve remote operations such as power on/off, parameter adjustment, reboot, etc. Based on the Thing Model service definition, it supports synchronous/asynchronous calls and is a core capability of Remote Maintenance.
Implementation Mechanism and Protocols
Remote control issues commands through protocols such as MQTT, HTTP, and CoAP. The platform encapsulates control requests into service calls that conform to the Thing Model, and pushes them to devices via message routing; the devices report results after execution, and the platform can update the Device Shadow. It supports synchronous waiting (request-response) and asynchronous callbacks; timeout and retry strategies can be configured. Sensitive controls (such as shutdown or factory reset) may require secondary confirmation on the device side or human-machine interaction.
Integration with DMP
The platform provides remote control capabilities through the console, API, automation rules, and other entry points. It needs to be used in conjunction with RBAC permission control to restrict the roles and device ranges that can execute control; Audit Log audit logs record each control operation. When integrated with Work Order, maintenance personnel can initiate remote control directly within the work order, and the operation records are associated with the work order for easy traceability. Batch control supports selecting devices by group or tag, suitable for scenarios such as unified configuration deployment and batch reboot.
Use Cases
It is suitable for smart home switch control, industrial equipment parameter adjustment, remote meter valve control, vehicle networking remote lock/start, etc. Remote control is a key combination of "management" and "control" in the Device Management Platform, supporting operations automation and remote business operations.
How a service call differs from a device-shadow desired value
Remote control has two paths that are not interchangeable. A service call asks the device to perform an action within a time limit and return a result: close a breaker, restart, or change an operating mode. A desired value in the shadow says what state the device should eventually reach. The device aligns itself after it comes online, and it does not promise to act immediately. Write an action that needs an immediate receipt as a shadow property, and the screen shows it as saved while the device waits for the next sync. The operator thinks the command was lost and clicks again.
A service-call message should carry a command identifier, parameters, and an expiry time. Before acting, the device checks the expiry and, if it has passed, refuses and writes the reason back instead of acting anyway. The receipt should at least distinguish accepted, executed, failed, and rejected by the device. A network-level delivery alone does not tell the platform whether the relay moved. When delivery quality itself must be confirmed, choose a quality of service level separately. A level 0 publish is not proof that the action ran.
Online and permission conditions that allow a command to be sent
Before a command is sent, all of the following should hold: the target device has a live session, the caller has both the feature permission and the resource scope for that device, the service exists in the thing model for this product version, and the parameters fall inside the model constraints. If any one is missing, the command should not enter the send queue. If the business allows a delay for an offline device, mark it explicitly as pending delivery and set a retention limit. When the limit passes, void the command. Do not let an old shutdown run days later because the device happened to come online.
Batch control is stricter. When some devices in the group are offline and some models do not implement the service, split the task into an executable set and a rejected set, each with its reason. Do not mark the whole batch successful because most devices succeeded. Actions behind a safety interlock, such as a valve or a contactor, should also require the device's local conditions to be met. Platform permission does not override a local emergency stop. The operation record should be traceable to a specific event notification or audit entry, so the receiver can match it to a particular click.
A second send after timeout that executes twice
A timeout means only that the platform did not see a receipt within the limit. It does not mean the device did not act. On a weak network the device has often already acted, and the receipt was lost. If the operator immediately resends the same business action, the device acts again: the valve opens twice, the unit restarts twice, or a counter increments twice. Every send must carry a command identifier that does not change. When the device sees an identifier it has already executed, it replays the previous result and does not drive the actuator again.
Retries on the platform must keep that same identifier. They must not mint a new identifier on every click. A new identifier means a new business action. The screen should separate "waiting for a receipt" from "safe to retry," and disable another submit while it is waiting. If the parameters match and the target state is already reached, the device should return "already in the target state," so a success is not recorded as no response. If a shadow sync and a manual control write the same quantity at the same time, the desired value that arrives later overwrites the result that just ran. The two writers need an agreed priority. Each must not assume it was the last write.
The console should keep the identifier, parameters, send time, effective level, and raw receipt of the latest command on the device record, so the next operation can be checked against them. Without the raw receipt, the operator sees only the word timeout, and cannot tell a device rejection, an illegal parameter, and a lost link apart. For a service that changes a safety-related field state, add a local state read-back: after the command shows success, read the related property once and confirm it matches the target. If the read-back disagrees, leave the task unconfirmed. Do not automatically send a new opposite command to "correct" it. That command can land on top of the first execution when the first one was only late.