Bu sayfa henüz yerel dilinizde mevcut değildir. Daha fazla dil seçeneği eklemek için yoğun bir şekilde çalışıyoruz. Desteğiniz için teşekkür ederiz.
- 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.
Application Scenarios
Huawei Cloud IoT Device Access (IoTDA) allows you to connect your physical devices to the cloud, where you can collect device data and deliver commands to devices.
IoV
Requirements: For better management, automotive vendors access vehicles to the cloud platform. The platform needs to support data transmission using protocols such as JT/T808 and MQTT and can clean data for big data analysis and data mining.
Solutions: IoTDA provides secure and reliable connections at a low latency and supports multiple standard protocols. It uploads road, vehicle, and driving behavior data collected by vehicles to the cloud and processes the data with rules and FunctionGraph. In addition, IoTDA stores data in InfluxDB and DWS for big data analysis and uses ModelArts to perform machine learning to mine valuable data.
Reference architecture of the IoV scenario:
- The T-Box on the device side reports data such as vehicle status, driving behavior, and vehicle track to the cloud through MQTT or JT/T808.
- IoTDA transfers data to different cloud services for data cleaning, storage, and analysis, building multiple IoV data applications.
Smart Home
Requirements: Home appliances, such as refrigerators, air conditioners, washing machines, sockets, TVs, and lighting devices, need to be connected to the cloud for data reporting and running status detection. Users can also run commands on applications provided by device vendors to remotely control devices.
Solutions: IoTDA provides a secure and reliable system to support massive device connections. It supports multiple protocols, such as MQTT, CoAP, HTTP, LwM2M, and WebSocket, and allows users to deliver messages and commands from the cloud to control devices in a timely manner.
Smart Manufacturing
Requirements: To manage mechanical devices of various brands and types on the assembly lines, factories need to collect device running and environment monitoring data with a cloud platform. The platform should calculate and analyze device running status in real time, provide device exception or fault prediction and alarm, and allow users to perform remote maintenance and upgrade.
Solutions: Factories can use IoT Edge to collect OT data such as device and environment data, report them to IoTDA through industrial gateways, and transfer them to other cloud services for data conversion and analysis. With this data, factories can monitor devices, receive alarms for abnormal devices, and upgrade and maintain devices remotely.
Reference architecture of the smart manufacturing scenario:
- Edge nodes deployed on devices support protocols such as OPC UA and Modbus, collect running data, status data, and environment monitoring data of various OT devices, and report data from edge gateways to IoTDA.
- IoTDA uses rules to transfer data to DIS. After being processed by DLI-Flink, the data is written to DWS for subsequent data governance. Data can also be transferred to MapReduce Service (MRS) for big data cleaning and processing, facilitating subsequent AI analysis and data mining.
Distributed Photovoltaics (PV)
Requirements: New energy companies need to collect the voltage, current, power, yield, and alarm data of inverters produced by various vendors to the cloud for further data processing and analysis, facilitating data center development, alarm O&M, and operation analysis.
Solutions: IoTDA provides standard object models and supports multi-protocol access. Shielding the format and protocol differences of data reported by devices from multiple PV device vendors, IoTDA uses rules to transfer data to OBS for storage and MRS for further data processing.

Reference architecture of the distributed PV scenario:
- Inverters from different vendors report data such as voltage, current, power, and yield to the cloud through MQTT.
- IoTDA uses rules to transfer data to OBS for storage. After being processed by DLI-Flink, the data is written to DWS for subsequent data governance. Data can also be transferred to MRS for big data cleaning and processing, facilitating subsequent AI analysis and data mining.
Smart Charging Pile
Requirements: Charging pile operators need to collect charging data, meter information, and charging vehicle information of charging piles produced by different vendors to the cloud, so cloud applications can detect the status of user vehicles and charging piles in real time for fee calculation. Applications need to deliver commands to start and stop the charging.
- Solution 1: Charging pile devices from multiple vendors are directly connected to the IoTDA through MQTT. Generic-protocol plug-ins are deployed on the cloud for parsing and multi-protocol access. IoTDA can directly push data to customers' applications and allow applications to deliver commands to control the start and stop of the charging. This solution applies to urban areas or outdoor areas with good network environments.
- Solution 2: IoT Edge is used to collect charging pile data from multiple vendors. Protocol plug-ins can be deployed on edge nodes to shield proprietary protocols of multiple vendors. Some simple computing applications can also be deployed on edge nodes to reduce interaction with the cloud. The edge gateway reports data to the IoTDA through MQTT. IoTDA can directly push data to customers' applications and allow applications to deliver commands to control the start and stop of the charging. This solution applies to areas with poor network environments, such as highway service areas and underground parking lots.

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