هذه الصفحة غير متوفرة حاليًا بلغتك المحلية. نحن نعمل جاهدين على إضافة المزيد من اللغات. شاكرين تفهمك ودعمك المستمر لنا.
- 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
Show all
Copied.
Forwarding Modes
A device can connect to and communicate with the platform. The device reports data to the platform using custom topics or product models. After the subscription/push configuration on the console is complete, the platform forwards messages about device lifecycle changes, reported device properties, reported device messages, device message status changes, device status changes, and batch task status changes to the application.
The platform supports four data forwarding modes: HTTP/HTTPS, AMQP, MQTT, and M2M communications.
- HTTP/HTTPS mode
- Subscription: You can use an application to call the platform APIs to configure and activate rules, or create a subscription task on the console for obtaining changed device service and management details. Service details involve device lifecycle, device data reporting, device message status, and device status. Management details involve software/firmware upgrade status and result. Related APIs: Create a Rule Triggering Condition, Create a Rule Action, and Modify a Rule Trigger Condition. The URL of the application, also called the callback URL, must be specified during subscription. For details, see How Do I Obtain the Callback URL When Calling the Subscription API? .
- Push: After a subscription is successful, the platform pushes the corresponding change to a specified callback URL based on the type of data subscribed. (For details on the pushed content, see Data Transfer APIs.) If an application does not subscribe to a specific type of data notification, the platform does not push the data to the application even if the data has changed. The platform pushes data, in JSON format, using HTTP or HTTPS. HTTPS requires authentication and is more secure. Therefore, HTTPS is recommended.
For details, see HTTP/HTTPS Data Forwarding.
- AMQP mode
- Subscription: AMQP is short for Advanced Message Queuing Protocol. You can create a subscription task on the IoTDA console, or call platform APIs to configure and activate rules for obtaining changed device service and management details. Service details involve device lifecycle, device data reporting, device message status, and device status. Management details involve software/firmware upgrade status and result. Related APIs: Create a Rule Triggering Condition, Create a Rule Action, and Modify a Rule Triggering Condition. The AMQP message channel must be specified during subscription creation.
- Push: After a subscription is created, the platform pushes the corresponding change to the specified AMQP message queue based on the type of data subscribed. If an application does not subscribe to a specific type of data notification, the platform does not push the data to the application even if the data has changed. You can use the AMQP client to establish a connection with the platform to receive data.
For details, see AMQP Data Forwarding.
- MQTT mode
- Subscription: You can call platform APIs to configure and activate rules for obtaining the changed device service and management details. Service details involve device lifecycle, device data reporting, device message reporting, and device status. Management details involve software/firmware upgrade status and result. Related APIs:Create a Rule Triggering Condition, Create a rule action, and Modify a Rule Triggering Condition. The topic for receiving push messages must be specified during subscription creation.
- Push: After a subscription is created, the platform pushes the corresponding change to the specified topic based on the type of data subscribed. If an application does not subscribe to a specific type of data notification, the platform does not push the data to the application even if the data has changed. You can use the MQTT client to establish a connection with the platform to receive data.
For details, see MQTT Data Forwarding.
- M2M communications
- Subscription: You can create rules on the console or call the platform APIs to configure and activate rules for obtaining messages reported by devices from the platform. Related APIs: Create a Rule Trigger Condition, Create a Rule Action, and Modify the Rule Triggering Condition. Device subscription supports only message reporting.
- Push: After the subscription is successful, the platform pushes messages reported by devices to the specified MQTT topic. After devices are connected to the platform, you can subscribe to the topic to receive data for inter-device message communications.
For details, see M2M Communications.
Data Forwarding Mode |
Application Scenario |
Advantage |
Restrictions |
---|---|---|---|
HTTP/HTTPS subscription/push |
An application functions as the server and passively receives messages from the platform. |
- |
The traffic control limit is 800 TPS per second. HTTP/HTTPS is not recommended for large-traffic push. |
AMQP subscription/push |
An application functions as the client and proactively pulls messages from the platform or passively receives messages from the platform by means of listening. |
Data can be obtained proactively. |
For details, see Connection Specifications. |
MQTT subscription/push |
An application functions as a client and can receive messages from IoT cloud services through subscription. |
- |
For details, see Constraints. |
M2M communications |
|
Communications among devices are supported. |
For details, see Overview. |
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