Because of the async communication mode of the MQTT protocol based on the publish/subscribe pattern, after the server controls a device, it cannot synchronously get the result returned by the device. To solve this problem, IoT Hub uses the Revert RPC (RRPC) technology to implement a sync communication mechanism.
How Communication Works
Communication topics
The subscription message topic $rrpc/rxd/${productID}/${deviceName}/+ is used to subscribe to RRPC request messages sent by the cloud (downstream).
The request message topic $rrpc/rxd/${productID}/${deviceName}/${processID} is used for the cloud to publish (downstream) RRPC request messages.
The response message topic $rrpc/txd/${productID}/${deviceName}/${processID} is used to publish (upstream) RRPC response messages.
Note:
${productID}: product ID
${deviceName}: device name
${processID}: unique message ID generated by the server to identify different RRPC messages. The corresponding RRPC request message can be found through the processID carried in the RRPC response message.
Communication process
1. The device subscribes to the RRPC subscription message topic.
2. The server publishes an RRPC request message by calling the PublishRRPCMessage API.
3. After receiving the message, the device extracts the processID distributed by the cloud in the request message topic, sets it as the processID of the response message topic, and publishes a return message of the device to the response message topic.
4. After IoT Hub receives the return message from the device, it matches the message according to the processID and sends the return message to the server.
Note:
RRPC requests time out in 4s, that is, if the device doesn't respond within 4s, the request will be considered to have timed out.
The flowchart is as follows:
RRPC communication sample
The sample completes device connection through the device-side C-SDK on Linux and calls APIs together with Tencent Cloud API Explorer. The specific steps are as follows:
Creating device in console
Creating product and device
Create an air conditioner product and an airConditioner1 device as instructed in Device Interconnection.
Compiling and running demo (with key-authenticated device as example)
1. Compile the SDK
Modify CMakeLists.txt and make sure that the following options exist:
set(BUILD_TYPE "release")
set(COMPILE_TOOLS "gcc")
set(PLATFORM "linux")
set(FEATURE_MQTT_COMM_ENABLED ON)
set(FEATURE_RRPC_ENABLED ON)
set(FEATURE_AUTH_MODE "KEY")
set(FEATURE_AUTH_WITH_NOTLS OFF)
set(FEATURE_DEBUG_DEV_INFO_USED OFF)
Run the following script for compilation:
./cmake_build.sh
The demo output rrpc_sample is in the output/release/bin folder.
2. Enter the device information
Enter the information of the airConditioner1 device created above in the JSON file aircond_device_info1.json.
{
"auth_mode":"KEY",
"productId":"KL4J2****8",
"deviceName":"airConditioner1",
"key_deviceinfo":{
"deviceSecret":"zOZXUaycuwleP****78dBA=="
}
}
3. Run the rrpc_sample demo
You can see that the airConditioner1 device has subscribed to the RRPC message and then entered the waiting status.
Observe the printout of the airConditioner1 device, and you can see that the RRPC request message has been processed, the RRPC response message has been replied, and the processID is ***.
Observe the response result of the server, and you can see that the RRPC response message has been received. MessageId is ***, and Payload is **** after being Base64-encoded, which is the same as the actual response message of the client after being Base64-encoded. At this point, it can be confirmed that the response message has been received.
