The Command Channel (also known as Cloud to Device Message) is a messaging mechanism sent from cloud services to IoT devices, enabling the cloud to proactively control devices, issue commands, or push notifications. It is one of the essential foundations for realizing intelligent networked systems.
Use Case
- Remote Control Commands:The cloud notifies devices to perform specific actions, such as turning on lights, rebooting, or updating configurations.
- Notification Push:Pushes real-time notifications or warning messages to devices.
- Software Update Notification:Notifies devices that firmware updates are available for download.
- Scheduled Task Execution:For example, executing an action at a fixed daily time, with commands issued by the cloud.
NeoEdge Positioning and Role
As an IoT gateway middleware, NeoEdge assists you in establishing a communication bridge between Cloud Services (IT Applications) and On-site Equipment (OT Devices), without interfering with your actual application logic. In other words, what kind of messages are sent from the Cloud to the On-site Equipment and what objectives are achieved are entirely defined and controlled by you.
NeoEdge enables Cloud to Device control capabilities through simple Command Channel configuration, eliminating additional development or construction costs at the gateway side. However, depending on the architecture and capabilities of your Cloud Service backend, some development integration work may still be required.
NeoEdge Operational Mechanism
Understanding the operational logic of NeoEdge is a key step to ensuring the smooth integration of your system design.
In the built-in IT Apps of NeoEdge, the cloud services that support the Command Channel include MQTT Broker and AWS IoT Core. Within the built-in OT Device modules, the equipment types capable of receiving Cloud to Device Message Messages includeModbus TCP、Modbus RTU, and OPC UA.
In other words, as illustrated in the diagram below, you can send messages from cloud services (MQTT Broker or AWS IoT Core) via MQTT Topic , and the commands will be forwarded to the designated OT devices (Modbus TCP, Modbus RTU, or OPC UA).

NeoEdge does not validate the correctness of message content;instead, it forwards the received messages intact to your specified device and data points.Since the results after the device executes the messages cannot be returned in real-time, if you need to obtain execution results, it is recommended to additionally define a response mechanism within the original NeoFlow data acquisition process to complete status monitoring or result reporting.
NeoEdge Configuration Steps
1. Create Command Channels in the IT App

Using the example above,you can configure acceptable Command Channels on the MQTT Broker (including the Channel name and its corresponding MQTT Topic). The key point is: each Channel must correspond to a unique MQTT Topic.We recommend using the Gateway ID combined with the Channel Name as the Topic path to ensure naming consistency and easier management.
The list of variables supported by NeoEdge is as follows:
| 變數名稱 | Explanation | 範例內容 | Allow in Channel Name |
| {neoedge.gatewayID} | Gateway ID (a unique value generated by NeoEdge X) | 110281604680911360 | Yes |
| {neoedge.gatewayName} | Gateway Name (a name you assign to the gateway; it must be unique within the same project) | My_Gateway_001 | Yes |
| {neoedge.deviceKey} | Gateway PKI – Private Key (the device private key generated by NeoEdge X) | No | |
| {neoedge.deviceCert} | Gateway PKI – X.509 Certificate (the device certificate issued by NeoEdge Central) | No | |
| {neoedge.ipcVendor} | Gateway Manufacturer | Moxa | Yes |
| {neoedge.ipcModel} | Gateway Model Name | UC-2222A | Yes |
| {neoedge.longitude} | Gateway Longitude | 120.590001 | No |
| {neoedge.latitude} | Gateway Latitude | 24.897777 | No |
In NeoFlow, Connect Command Channel to OT Device Tag

As shown in the figure above,you can use NeoFlow to connect the Channel Name to the corresponding OT Device Tag. It is particularly important to note that only Writable Device Tags are supported for connection and control; please verify the relevant settings to ensure that commands can be successfully delivered to the device.
3. Deploy NeoFlow to the Gateway
Finally, deploy NeoFlow to the Gateway to complete the overall configuration process.
Testing and Monitoring
1. Configure MQTT Broker to Grant Necessary Permissions to the Gateway
You may need to adjust the MQTT Broker authorization to grant the Gateway permission to receive messages. Using AWS IoT Core as an example, you need to grant the "Receive" permission. The complete Policy is as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:iot:*:*:client/${iot:ClientId}"
},
{
"Effect": "Allow",
"Action": "iot:Publish",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iot:Receive",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iot:Subscribe",
"Resource": "*"
}
]
}2. Obtain the Gateway ID
Before sending commands to the IIoT Gateway, you need to obtain the Gateway ID or Gateway Name according to the Command Channel configuration and construct the Command Channel(MQTT Topic). This information can be queried through the NeoEdge Central operation interface or obtained using the provided RESTful API.

According to the settings above, your Command Channel Topic will be:
- neoedge/110281604680911360/c2d-message/Fan_Speed
- neoedge/110281604680911360/c2d-message/Light_Control
3. Send Command
Send a message to the MQTT Topic based on the tools, APIs, or SDKs provided by your MQTT Broker. Using AWS IoT Core as an example, you can send a Cloud to Device Message via the Web UI as follows:

4. Live Monitor
Before sending a Cloud to Device Message, you can open Live Monitor on NeoEdge Central to monitor whether the Gateway has received the message and whether the message has been successfully forwarded to the designated OT Device.




