Esta página ainda não está disponível no idioma selecionado. Estamos trabalhando para adicionar mais opções de idiomas. Agradecemos sua compreensão.
- 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.
Using MQTT.fx to Simulate Communication Between the Smart Street Light and the Platform
Connecting the Simulated Street Light to the Platform
Use MQTT.fx to activate the device registered on IoTDA.
- Download MQTT.fx (64-bit OS) or MQTT.fx (32-bit OS) and install it.
- Go to the device details page, find MQTT Connection Parameter, and click View to check the clientId, username, password, and hostname.
Figure 1 Device - Device detailsFigure 2 Device - Device details - MQTT connection parameters
- Open MQTT.fx and click the setting icon.
Figure 3 MQTT.fx Settings
- Click the User Credentials tab and set authentication parameters by referring to the following table.
Figure 4 Configuring authentication parameters
Table 1 Parameter description Parameter
Description
Broker Address
Host name, which is obtained in 2. The access address is a domain name. For devices that cannot be connected to the platform using a domain name, run the ping Domain name command in the CLI to obtain the IP address. The IP address is variable and needs to be set using a configuration item.
Broker Port
8883. In this example, port 8883 is used for secure connection.
Client ID
Enter the device client ID obtained in 2.
User Name
Enter the device ID obtained in 2.
Password
Enter the encrypted device secret obtained in 2.
- Click the SSL/TLS tab and then select Enable SSL/TLS. Recommended: Set Protocol to TLSv1.2. Click CA certificate file, go to the certificate resources page to download the certificate file of the corresponding region and instance version, and enter the complete local path of the certificate file in the text box. Click Apply, and then click Cancel to exit the configuration page.
Figure 5 Setting SSL/TLS parameters
- Click Connect. If the icon in the upper right corner turns green, the device simulator has been authenticated and connected. The device status displayed on the platform is Online.
Figure 6 Device simulator connectedFigure 7 Device online status
Reporting Light Intensity Data
Use MQTT.fx to report light intensity data to the IoT platform. If a device reports data through the MQTT channel, the data needs to be sent to a specific topic in the format $oc/devices/{device_id}/sys/properties/report. For devices that each has a different secret, set device_id to the device ID returned upon successful device registration.
- Enter the API URL, for example, $oc/devices/{device_id}/sys/properties/report.
Figure 8 Enter a topic name.
- Enter the data to report in the blank area in the middle of the tool and click Publish.
Table 2 Service data list Field
Mandatory/Optional
Type
Description
services
Mandatory
List<ServiceProperty>
Service data list. (For details, see the ServiceProperty structure below.)
Table 3 ServiceProperty structure Field
Mandatory/Optional
Type
Description
service_id
Mandatory
String
Service ID.
properties
Mandatory
Object
Service properties, which are defined in the product model associated with the device.
eventTime
Optional
String
UTC time when the device reports data. The format is yyyyMMddTHHmmssZ, for example, 20161219T114920Z.
If this parameter is not carried in the reported data or is in incorrect format, the time when IoTDA receives the data is used.
Request example:
{ "services": [{ "service_id": "BasicData", "properties": { "luminance": 30 } } ] }
- Check whether the device successfully reports data on the device details page. As shown in the following figure, the luminance is updated to 30.
Figure 9 Viewing reported data - MQTT
Remotely Delivering Commands for Turning On the Light
Deliver a command on the console to remotely control smart street lights.
- In the navigation pane, choose Devices > All Devices, locate the target device, and click View to access its details page.
- Click the Cloud Delivery tab, click Deliver Command, set Command to LightControl: Switch, and set Value to ON to deliver a command for turning on the light.
Figure 10 Command delivery - Synchronous command deliveryFigure 11 Command delivery - LightControl
NOTE:
MQTT devices support only synchronous command delivery. NB-IoT devices support only asynchronous command delivery.
- In the MQTT.fx simulator, click the Subscribe tab and enter the command delivery topic. After the subscription, check the delivered command parameters. The format of the command delivery topic is $oc/devices/{device_id}/sys/commands/#. As shown in the following figure, the MQTT.fx simulator has received the command whose command_name is Switch and value is ON.
Figure 12 Checking the delivered command parameters
NOTE:
The device needs to respond to the delivered synchronous command in a timely manner. However, MQTT.fx does not automatically report the command response. Therefore, the console page may display a message indicating that the command request times out. For details about the command response, see Platform Delivering a Command.
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