Halaman ini belum tersedia dalam bahasa lokal Anda. Kami berusaha keras untuk menambahkan lebih banyak versi bahasa. Terima kasih atas dukungan Anda.
- What's New
- Product Bulletin
- Service Overview
- Billing
-
Getting Started
-
Quick Device Access - Property Reporting and Command Receiving
- Subscribing to IoTDA
- Connecting a Smart Smoke Detector to the Platform (Quick Usage)
- Registering a Simulated Smart Street Light Device
- Using MQTT.fx to Simulate Communication Between the Smart Street Light and the Platform
- Using a Virtual Smart Street Light to Communicate with the Platform (Java SDK)
- Using a Virtual Smart Street Light to Communicate with the Platform (C SDK)
- Quick Device Access - Message Sending and Receiving
- Quick Application Access
-
Quick Device Access - Property Reporting and Command Receiving
-
User Guide
- Overview
- IoTDA Instances
- Resource Spaces
- Device Access
- Message Communications
- Device Management
-
Rules
- Overview
- Data Forwarding Process
- SQL Statements
- Connectivity Tests
- Data Forwarding to Huawei Cloud Services
- Data Forwarding to Third-Party Applications
- Data Forwarding Channel Details
- Data Forwarding Stack Policies
- Data Forwarding Flow Control Policies
- Abnormal Data Target
- Device Linkage
- Monitoring and O&M
- Granting Permissions Using IAM
-
Best Practices
- Introduction
-
Device Access
- Developing an MQTT-based Simulated Smart Street Light Online
- Developing a Smart Street Light Using NB-IoT BearPi
- Developing a Smart Smoke Detector Using NB-IoT BearPi
- Connecting and Debugging an NB-IoT Smart Street Light Using a Simulator
- Developing a Protocol Conversion Gateway for Access of Generic-Protocol Devices
- Connecting a Device That Uses the X.509 Certificate Based on MQTT.fx
- Connecting to IoTDA Based on the BearPi-HM_Nano Development Board and OpenHarmony 3.0
- Testing MQTT Performance Using JMeter
- Device Management
- Data Forwarding
- Device Linkage
-
Developer Guide
- Before You Start
- Obtaining Resources
- Product Development
- Development on the Device Side
- Development on the Application Side
-
API Reference
-
API Reference on the Application Side
- Before You Start
- Calling APIs
- API Overview
-
API
- Product Management
- Device Management
- Device Message
- Device Command APIs
- Device Property
- AMQP Queue Management
- Access Credential Management
- Data Forwarding Rule Management
-
Transition Data
- Push a Device Status Change Notification
- Push a Device Property Reporting Notification
- Push a Device Message Status Change Notification
- Push a Batch Task Status Change Notification
- Push a Device Message Reporting Notification
- Push a Device Addition Notification
- Push a Device Update Notification
- Push a Device Deletion Notification
- Push a Product Addition Notification
- Push a Product Update Notification
- Push a Product Deletion Notification
- Push an Asynchronous Device Command Status Change Notification
- Rule Management
- Device Shadow
- Group Management
- Tag Management
- Instance Management
- Resource Space Management
- Batch Task
- Device CA Certificate Management
- OTA Upgrade Package Management
- Message Broadcasting
- Device Tunnel Management
- Stack policy management
- Flow control policy management
- Device Proxy
- Device Policy Management
- Bridge Management
- Pre-provisioning Template Management
- Custom Authentication
- Codec Function Management
- Permissions and Supported Actions
- Examples
- Appendix
-
MQTT or MQTTS API Reference on the Device Side
- Before You Start
- Communication Modes
- Topics
- Device Connection Authentication
- Device Commands
- Device Messages
- Device Properties
-
Gateway and Child Device Management
- Platform Notifying a Gateway of New Child Device Connection
- Platform Notifying a Gateway of Child Device Deletion
- Gateway Synchronizing Child Device Information
- Gateway Updating Child Device Status
- Responding to a Request for Updating Child Device Statuses
- Gateway Requesting for Adding Child Devices
- Platform Responding to a Request for Adding Child Devices
- Gateway Requesting for Deleting Child Devices
- Platform Responding to a Request for Deleting Child Devices
- Software and Firmware Upgrade
- File Upload and Download
- Device Time Synchronization
- Device Reporting Information
- Device Log Collection
- Remote Configuration
- Device Tunnel Management
- HTTPS API Reference on the Device Side
- LwM2M API Reference on the Device Side
- Security Tunnel WebSocket API Reference
- Module AT Command Reference
- Change History
-
API Reference on the Application Side
- SDK Reference
-
FAQs
- Top FAQs
-
Solution Consulting
- In What Scenarios Can the IoT Platform Be Applied?
- What Are the Changes Brought by the Integration of IoT Device Management and IoTDA?
- Can I Enable IoTDA for IAM Users or Sub-Projects?
- Which Regions of Huawei Cloud Are Supported by the IoT Platform?
- Does Huawei Provide Modules, Hardware Devices, and Application Software?
- What Should I Do If I Want to Call an API But Have No Permissions to Do So as an IAM User? (Is It Edition-specific?)
- Why Was I Prompted to Grant Security Administrator Permissions When I Create a Rule or Set Resource File Storage?
- Which Resource Space Will Be Set As Default on the IoT Platform?
- How Does IoTDA Obtain Device Data?
- Is There Any Limitation on the Number of Resource Spaces and Devices I Can Add on the IoT Platform?
- Does the IoTDA Support Device Registration in Batches?
- Are There Any Limitations on the Use of the IoT Platform?
- What DTLS Encryption Algorithms Are Supported by the IoT Platform?
- Does the IoT Platform Support Conversion Between Big-Endian and Little-Endian for Binary Data?
- What Is NB-IoT?
- What Are the Components of the IoT Platform and What Hardware Architectures Does It Support?
- How Do I Obtain the Platform Access Address?
- Device Integration
- IoT Device SDKs
- LwM2M/CoAP Device Access
- MQTT-based Device Access
- Products Models
- Message Communications
- Subscription and Push
- Codecs
- OTA Upgrades
- Application Integration
- General Reference
Copied.
Usage
Process

Procedure
- Create an authentication template. Specifically, log in to the IoTDA console, in the navigation pane, choose Devices > Custom Authentication, click Custom Template, and click Create Template. The authentication template used in this example is the same as that used in the default authentication.
Figure 2 Custom authentication - Creating a template
The overall content of the template is as follows:
{ "template_name": "system-default-auth", "description": "Example of the default authentication template of Huawei Cloud IoTDA", "status": "ACTIVE", "template_body": { "parameters": { "iotda::mqtt::client_id": { "type": "String" }, "iotda::mqtt::username": { "type": "String" }, "iotda::device::secret": { "type": "String" } }, "resources": { "device_id": { "Ref": "iotda::mqtt::username" }, "timestamp": { "type": "FORMAT", "pattern": "yyyyMMddHH", "value": { "Fn::SubStringAfter": [ "${iotda::mqtt::client_id}", "_0_1_" ] } }, "password": { "Fn::HmacSHA256": [ "${iotda::device::secret}", { "Fn::SubStringAfter": [ "${iotda::mqtt::client_id}", "_0_1_" ] } ] } } } }
Table 1 Authentication template parameters Parameter
Name
Mandatory
Description
template_name
Template name
Yes
Template name. The name must be unique for a single user. Max. length: 128 characters. Use only letters, digits, underscores (_), and hyphens (-).
description
Description
No
Template description. Max. length: 2,048 characters. Use only letters, digits, and special characters (_?'#().,&%@!-).
status
Status
No
Template status. By default, a template is not enabled. A user can only have one enabled template at a time.
parameters
Parameter
Yes
MQTT connection parameters predefined by the platform. When a device uses password authentication, the template must contain the original secret parameter (iotda::device:secret).
The platform predefines the following parameters:
iotda::mqtt::client_id: Client Id in the MQTT connection parameter triplet
iotda::mqtt::username: User Name in the MQTT connection parameter triplet
iotda::certificate::country: device certificate (country/region, C)
iotda::certificate::organization: device certificate (organization, O)
iotda::certificate::organizational_unit: device certificate (organization unit, OU)
iotda::certificate::distinguished_name_qualifier: device certificate (distinguishable name qualifier, dnQualifier)
iotda::certificate::state_name: device_certificate (province/city, ST)
iotda::certificate::common_name: device certificate (common name, CN)
iotda::certificate::serial_number: device certificate (serial number, serialNumber)
iotda::device::secret: original secret of the device
device_id
Device ID function
Yes
Function for obtaining the device ID, in JSON format. The platform parses this function to obtain the corresponding device information.
timestamp
Timestamp verification
No
Whether to verify the timestamp in the device connection information. Recommended: Enable this function if the device connection parameters (clientId and username) contain the timestamp. Verification process: The platform compares the timestamp carried by the device with the platform system time. If the timestamp plus 1 hour is less than the platform system time, the verification fails.
type
Timestamp type
No
UNIX: Unix timestamp. Long integer, in seconds.
FORMAT: formatted timestamp, for example, 2024-03-28 11:47:39 or 2024/03/28 03:49:13.
pattern
Timestamp format
No
Time format template. Mandatory when the timestamp type is FORMAT.
y: year
M: month
d: day
H: hour
m: minute
s: second
S: millisecond
Example: yyyy-MM-dd HH:mm:ss and yyyy/MM/dd HH:mm:ss
value
Timestamp function
No
Function for obtaining the timestamp when the device establishes a connection. Mandatory when timestamp verification is enabled.
password
MQTT password function
No
Password function. Mandatory when the device authentication type is secret authentication. The template parameters must contain the original device secret parameter (iotda::device:secret). For details about the device authentication type, see Registering an Individual Device. Verification process: The platform uses parameters such as the original secret of the device in the function to calculate. If the result is the same as the password carried in the connection establishment request, the authentication is successful. Otherwise, the authentication fails.
- Select a device debugging template. Specifically, click Debug, select a device for debugging, enter MQTT connection parameters, and click Debug to view the result. Note: If clientId in the standard format is used, the platform verifies whether the value of username is the same as the prefix of clientId.
Figure 3 Custom template - Debugging
After the device debugging is successful, click Enable to enable the template. Once the template is enabled, it will be used for authentication of all devices, and the enabled template cannot be modified. You are advised to create a backup template for debugging, and switch to the backup template only when the debugging succeeds.
- Use the MQTT.fx tool to simulate device connection setup. Set Broker Address to the platform access address, choose Overview > Access Information, and set port to 8883.
Figure 4 Device connection establishmentFigure 5 Device list - Device online status
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot