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
- How Do I Obtain the Device Access Address?
- Must the X.509 Certificate I Use for Device Connection Be Issued by an Authoritative Organization?
- How Do I Locate the Cause of the Certificate-based Device Connection Failure?
- How Do I Set the Device Name?
- How Do I Activate IoT Devices?
- How Is the Status of a Device Changed?
- How Can I Check the Details of Gateways and Child Devices?
- Why Is the Status of Child Devices Displayed as Online When the Gateway Is Offline?
- What Are the Differences Between Device ID, Node ID, and IMEI and What Are They Used For?
- Can a Device Send Files to the IoT Platform?
- What Do I Do If the IoT Link Plug-in Download Fails When Using the BearPi Development Board?
- What Do I Do If Device Activation Fails When Using the BearPi Development Board?
- What Do I Do If Data Reporting or Command Receiving Fails When Using the BearPi Development Board?
- What Do I Do If a Message is Displayed Indicating that the Device is Occupied During Device Registration?
Show all
Copied.
Device Integration
How Do I Obtain the Device Access Address?
- Log in to the IoTDA console. In the navigation pane, choose IoTDA Instances. Click the target instance card.
Figure 1 Instance management - Changing instance
- In the navigation pane, choose Overview. Click Access Details to check your platform access address.
Figure 2 Obtaining access information
Must the X.509 Certificate I Use for Device Connection Be Issued by an Authoritative Organization?
Not necessary. A custom certificate is also supported, but you are advised to use a certificate issued by an authoritative organization. For details, see Uploading a Device CA Certificate.
How Do I Locate the Cause of the Certificate-based Device Connection Failure?
- Check whether the platform CA entered on the device side is correct.
Platform certificate verification fails on the device side if the following stack information is displayed: Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. In this case, check whether the platform CA entered on the device side is correct.
Use OpenSSL to run the following command to obtain server certificate information:
openssl s_client --connect <brokerAddress:brokerPort>
Figure 3 OpenSSL executionThe obtained certificate chain contains the following certificates:
- Certificate 0 is the platform certificate that identifies the platform.
- Certificate 1 is the intermediate CA that issues the platform certificate.
When verifying the platform identity, a device needs to use the intermediate CA issuer to verify the certificate chain.
Check whether the user information of the platform root CA entered on the device side is consistent the issuer information of the intermediate CA. If consistent, save the intermediate CA displayed in the CLI as a file and run the following command to verify the issuing relationship between the root CA and the intermediate CA:
openssl verify -verbose -CAfile <CAFile> <middleCAFile>
Figure 4 OpenSSL certificate verification - Check whether the device certificate entered on the device side matches the private key of the device certificate.
Run the following commands to extract the MD5 hash values of the certificate and private key file:
openssl x509 -noout -modulus -in <certificate file> | openssl md5
openssl rsa -noout -modulus -in <private key file> | openssl md5
If the two MD5 hash values are different, the certificate and private key do not match. You are advised to enter the correct device certificate and private key.
Figure 5 Comparing MD5 values - Check the binding relationship between the device and the certificate fingerprint.
Enable message tracing for the device and locate the fault based on the traced messages.
How Do I Set the Device Name?
- Set the name of a device when you add the device to the IoTDA console.
- Set the device name when you use the API for registering or creating a device.
How Do I Activate IoT Devices?
When a device is registered on the IoT platform, and gets connected to the platform or starts to report data to the platform, the device is considered to be activated. For details, see Device Connection Authentication.
How Is the Status of a Device Changed?
An NB-IoT device is considered online when it reports data to the IoT platform. If no data is reported within 25 hours since the last data reporting, the device status changes to abnormal. If no data is reported within 49 hours, the device status changes to offline.
An MQTT device is considered online when it is connected to the platform. If the device is disconnected from the platform, it is considered to be offline and its status will be updated on the platform within a minute. You can click the status refresh button to update the status immediately.
For details, see Device Management.
How Can I Check the Details of Gateways and Child Devices?
Log in to the IoTDA console, choose Devices > All Devices in the navigation pane, and click View in the row where a gateway is located. Check the gateway details on the Device Info tab page, and check its child devices on the Child Devices tab page. For details, see Gateways and Child Devices.

Why Is the Status of Child Devices Displayed as Online When the Gateway Is Offline?
The status of child devices is managed by the gateway. When the gateway is offline, it can call the API for Gateway Updating Child Device Status to send the latest status of child devices to the IoT platform.
What Are the Differences Between Device ID, Node ID, and IMEI and What Are They Used For?
On the IoT platform, you need to enter a node ID (nodeId) when registering a device. A node ID is a physical identifier of a device. Generally, an IMEI or MAC address is used. A device ID (deviceId) is a logical identifier of a device on the IoT platform.
- NB-IoT devices: The node ID is carried for access authentication when a device connects to the platform.
- MQTT devices: A device uses the secret and device ID to connect to the platform. The access authentication is the one-device-one-secret mode.
For details, see Device Authentication.
Can a Device Send Files to the IoT Platform?
Yes. For details about the sending process, see File Uploads.
What Do I Do If the IoT Link Plug-in Download Fails When Using the BearPi Development Board?
Download Visual Studio Code 1.49 that matches your computer configuration and install it. Other versions do not support IoT Link.
What Do I Do If Device Activation Fails When Using the BearPi Development Board?
Enter AT+CGATT? and click Send. If +CGATT:1 is returned, the network attach is successful, indicating that the NB-IoT network is normal. If +CGATT:0 is returned, the network attach fails. Check whether the SIM card is correctly inserted, contact the carrier to check the network status, or check whether the IMEI is the same as that entered during device registration on the platform. You can obtain the IMEI by setting the dialing test switch to the AT-PC mode, selecting the STM port, setting the baud rate to 9600, and then running the AT+CGSN=1 command.
What Do I Do If Data Reporting or Command Receiving Fails When Using the BearPi Development Board?
Obtain code from Developing a Smart Street Light Using NB-IoT BearPi or Developing a Smart Smoke Detector Using NB-IoT BearPi. If the code is obtained from other channels, contact technical support of the channel. You can also post your questions about BearPi on the forum.
What Do I Do If a Message is Displayed Indicating that the Device is Occupied During Device Registration?
For an MQTT device, check whether the device ID is unique under your account. For an LwM2M device, check whether the node ID is unique under your account. If the device/node ID is unique, submit a service ticket on the console.
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