このページは、お客様の言語ではご利用いただけません。Huawei Cloudは、より多くの言語バージョンを追加するために懸命に取り組んでいます。ご協力ありがとうございました。
- 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 Connect Devices to the IoT Platform Through LwM2M over CoAP Protocols?
- How Do I Know the Strength of the NB-IoT Network Signal?
- Why Did the NB-IoT Module Not Attach to the Network?
- What Do I Do If an NB-IoT Module Failed to Be Bound to a Device?
- What Can I Do If an NB-IoT Module Cannot Report Data?
- Why Was a 513 Message Reported During the Connection of an NB-IoT Device?
- Why Does Data Reporting Fails When an NB-IoT Card Is Used in Another Device?
- What Can I Do If I Cannot Connect a Registered NB-IoT Device to the IoT Platform?
Show all
Copied.
LwM2M/CoAP Device Access
How Do I Connect Devices to the IoT Platform Through LwM2M over CoAP Protocols?
- Development on the platform: Create products, develop product models and codecs on the platform, and register devices. For details, see Creating a Product, Developing a Product Model, Developing a Codec, and Registering a Device.
- Development on the device: Use modules and Tiny SDKs on the device side for access. For details, see IoT Device SDK Tiny (C) User Guide.
- (Optional) Develop applications.
How Do I Know the Strength of the NB-IoT Network Signal?
Run the AT+CSQ command to query the NB-IoT signal strength.
The returned value is +CSQ. <rssi>,<ber>
A larger value of rssi indicates a stronger signal. The formula for calculating the signal strength is as follows: Signal strength = 113 dBm + (rssi x 2)
- rssi = 0: The signal is poor.
- rssi = 31: The signal is very strong.
- rssi = 99: There is no signal.
- The ber field is not used. It is fixed at 99.
If there is no signal or the signal is poor, contact the carrier.
Why Did the NB-IoT Module Not Attach to the Network?
- Run the AT+NUESTATS command to check whether there is a network signal.
- If the value of Signal power is 0, there is no network signal. Check whether the frequency band corresponding to the base station has been released, or move the device to somewhere where the signal is stronger and try again.
- Run the AT+NBAND? command to check whether the configured frequency band is the same as that of the module.
What Do I Do If an NB-IoT Module Failed to Be Bound to a Device?
When the NB-IoT module and real NB-IoT network are used to access the IoT platform, the first step is to bind a device.
If the device fails to be bound, you can troubleshoot the error by checking the following items:
- When you register the device on the platform, is the value of nodeId correct? Is the timeout period too short?
The values of nodeId must be the IMEI of the NB-IoT module. In addition, the timeout period should be long enough, so that the device can send a binding request to the platform within the period after the registration is successful.
- Is the product information used during device registration the same as that in the product model?
If you register the device in the IoTDA console, ensure that the correct product model is selected. If you call an API to register the device, make sure the value of deviceInfo is the same as that defined in the profile.
- Is the signal from an NB-IoT base station reaching the module?
Run the AT+CSQ? command to check the NB-IoT signal strength. If there is no signal or the signal strength is weak, contact the carrier.
- Can the NB-IoT module be attached to the network?
Run the AT+CEREG? command to obtain the network registration details. If the returned status is unregistered or rejected, contact the carrier. The version of the NB-IoT module may not match the version of the carrier's base station.
- Can the NB-IoT module ping the Huawei Cloud IoT platform?
Run the AT+NPING command to ping the Huawei Cloud IoT platform. If the platform cannot be pinged, it indicates that the carrier's network cannot reach the public network. Contact the carrier to check if its core network is connected to the public network and if the core network can be connected to only the carrier's IoT platform. Work with the carrier on the connection to the public network.
- Are the domain name and port of the platform correctly set for the NB-IoT module?
Run the AT+NCDP command to set the domain name and port of the platform. To obtain the domain name and port, log in to the IoTDA console and check the connection details of CoAP or CoAPS devices.
- Does the AT command sent to the NB-IoT module end with \r\n?
Each command sent to the NB-IoT module must end with \r\n. If not so, the command is cached in the NB-IoT module.
- Is the transmitted data in the "SENT" status in the NB-IoT module?
Run the AT+NQMGS command to check the status of the commands sent.
PENDING: The data was sent but the platform has not responded.
SENT: The data was sent and the platform has responded.
ERROR: Data reporting is abnormal.
If the status is PENDING or ERROR, there may be network issues. Check the base station and core network.
- Can the AT+NMGS data sent by the NB-IoT module be parsed properly?
Use the codec test tool to check whether the streams to be sent can be parsed.
What Can I Do If an NB-IoT Module Cannot Report Data?
Ensure that the NB-IoT module has been bound to a device. The binding is performed when the NB-IoT module reports the first piece of data to the IoT platform. If the binding fails, the device is not activated on the platform. In this case, resolve the fault by referring to What Do I Do If an NB-IoT Module Failed to Bind to a Device.
Let's assume that the device binding is successful and the device is displayed as online on the platform. Check the following the items:
- Does the AT+NMGS command sent to the NB-IoT module end with \r\n?
Each command sent to the NB-IoT module must end with \r\n. If not so, the command is cached in the NB-IoT module.
- Can the payload of the sent AT+NMGS be parsed by the codec?
Use the codec test tool to check the payload in the code stream to be sent. Check whether the message structure is correct and complies with the definition in the product model.
Why Was a 513 Message Reported During the Connection of an NB-IoT Device?
After being powered on, devices initiate a TUP registration flow to the IoT platform. TUP is a Huawei proprietary protocol over CoAP. It is similar to LwM2M. The TUP registration flow on HiSilicon chipsets cannot exceed 4 seconds. If the TUP registration is not completed within 4 seconds, a 513 message is reported.
When a 513 message is reported, do as follows:
- If a 513 message is reported due to poor network performance, contact the NB-IoT network carrier to check the network status.
- You are advised to restart the device and run AT+NMGS. When you send service data by running AT+NMGS, registration is triggered. If the subscription to the t/d resources (resources for receiving and sending service data) is not received within 4 seconds, an error is returned, but the registration is continued based on the CoAP-layer retransmission. Only when the subscription to the t/d resources is not received within 160 seconds, will the registration fail. The 160 seconds is sufficient for device registration. If an error message is returned after 4 seconds, only the data of the first packet is discarded. You are advised to restart the device and run AT+NMGS to trigger the registration.
You can run AT+NMSTATUS? to query registration status. If +NMSTATUS:MO_DATA_ENABLED is returned, the registration is successful.
Why Does Data Reporting Fails When an NB-IoT Card Is Used in Another Device?
Some carriers' cards are bound to devices. If a device is changed, the card bound to the device may be unavailable. In this case, contact the carrier.
What Can I Do If I Cannot Connect a Registered NB-IoT Device to the IoT Platform?
- Run the AT+CGATT=1 command in the module and see if there is an error reported. If there is, do as follows:
- Contact the NB-IoT network carrier to check if the NB-IoT card works properly.
- Contact the module manufacturer to check if the model works properly.
- If no error is reported, check if the IP address and port number of the platform are correct.
You can obtain the IP address and port number from the platform service provider. Port 5683 is used for unencrypted access, whereas port 5684 is used for encrypted access.
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