For more information, please see the SDK documentation. Currently, IoT Hub supports device SDKs for Linux and Android and supports porting to different hardware platforms.
Devices can be connected to the IoT Hub platform through the SDK:
The device SDK supports TLS (for MQTT) and DTLS (for CoAP) for asymmetric and symmetric encryption to protect device communication security:
psKey
, and relevant information will be returned when a device is created in IoT Hub.In addition to connection through the device SDK, IoT Hub also supports HTTP connection, which has low requirements for connection and is suitable for low-power data reporting scenarios over non-persistent connections.
In IoT Hub, the topics that devices can publish and subscribe to are strictly managed. All devices under the same product have the same topic class permissions, including the following by default:
Topic | Description |
---|---|
${productId}/${deviceName}/event | Publishing permission for the device to report data |
${productId}/${deviceName}/control | Subscribing permission for the device to get the data sent by the backend |
For a specific device, the productId
and deviceName
marked with the $
symbol above should be mapped to the specific product ID and device name. For example, if a product named pro
(with the product ID pro_id
) has 2 devices (named dev_1
and dev_2
respectively), then the topics that dev_1
can publish include pro_id/dev_1/event
but not pro_id/dev_2/event
, and the topics that it can subscribe to include pro_id/dev_1/control
but not pro_id/dev_2/control
.
You can edit and modify the topic permissions in the console and add or remove the topic class permissions of products.
To facilitate batch subscription to topics by the device SDK, wildcards can be used to indicate multiple matching topics when a device subscribes to or unsubscribes from topics:
Wildcard | Description |
---|---|
# | This wildcard can only appear at the end of the topic, representing the topics at the current level and all sub-levels; for example, if the wildcard topic is pro_id/dev_1/# , it can represent not only pro_id/dev_1/event but also pro_id/dev_1/event/subeventA |
+ | This wildcard can only appear after deviceName , representing all the topics at the current level; for example, if the wildcard topic is pro_id/dev_1/event/+ , it can represent pro_id/dev_1/event/subeventA and pro_id/dev_1/event/subeventB but not pro_id/dev_1/event/subeventA/close . This wildcard can appear multiple times, such as pro_id/dev_1/event/+/subeventA/+ |
A wildcard must be used as a complete level; for example, both ${productId}/${deviceName}/e#
and ${productId}/${deviceName}/e+
are invalid.
The system topics defined by IoT Hub ($shadow
, $ota
, and $sys
) don't support wildcards.
${productId}/${deviceName}/#
can be used to unsubscribe from all topics.For MQTT data transfer, IoT Hub supports QoS 0 or 1 but not QoS 2. Device messages can be stored offline.
Other parameters are as follows:
Parameter | Description |
---|---|
Topic name length | Up to 64 bytes |
MQTT protocol packet size | Up to 16 KB |
QoS 1 message storage period (if the recipient is offline or online sending fails) | 24 hours |
Number of QoS 1 messages not confirmed by the device | Up to 150 |
Device shadow is essentially a copy of device data in JSON format cached on the server and is mainly used to save:
As an intermediary, device shadow can effectively implement two-way data sync between device and user application:
The figure below is a sample use case of the device shadow in "Getting Started":
Note:Device shadow and device message have different applicable scenarios. In terms of implementation mechanism, the server-side device shadow always saves the last copy of data, and multiple messages that successively arrive do not overwrite one another.
For more information, please see Device Shadow Details.
Based on the rule engine, you can configure rules to do the following:
As devices are connected only to IoT Hub, IoT Hub can write specified device messages to Tencent Cloud CMQ or CKafka queues. From there, third-party services can get the device messages through the SDK APIs of CMQ or CKafka, enabling async message communication between devices and third-party services. Based on this, data storage, computational analysis, and device control logic can be implemented on the backend.
The IoT Hub console provides visual management UIs where you can manage products, devices, and permissions, configure the rule engine, and perform other operations. You can try it out easily.
For the device management flow in IoT scenarios, IoT Hub provides various APIs in Python, PHP, Java, Go, Node.js, and .NET for fast and batch operations on the backend. Currently, it offers APIs related to product, device, task, message, rule engine, and device shadow. For more information, please see TencentCloud API Overview.
When firmware has security risks or functional problems, IoT Hub servers can perform OTA updates to eliminate dangers and reduce security risks.
IoT Hub supports secure access, use, and management of cloud account resources through CAM. Isolation and collaboration of IoT Hub resources are implemented through identity and policy management of sub-accounts and collaborators.
Was this page helpful?