Wiznet makers

ronpang

Published August 22, 2025 © Apache License 2.0 (Apache-2.0)

132 UCC

75 WCC

32 VAR

0 Contests

1 Followers

0 Following

Hardwired TCP/IP Chapter 23: W55MH32 MQTT_OneNET Example

Hardwired TCP/IP Chapter 23: W55MH32 MQTT_OneNET Example

COMPONENTS
PROJECT DESCRIPTION

Hardwired TCP/IP Chapter 23: W55MH32 MQTT_OneNET Example

In this article, we will provide a detailed explanation on how to implement the MQTT protocol on the W55MH32 chip. Through practical examples, we will also explain to you how to use the MQTT protocol of the W55MH32 to connect to the OneNET platform and achieve data interaction with the OneNET object model.

Other network protocols used in this example, such as DHCP and DNS, please refer to the relevant sections. Regarding the initialization process of the W55MH32, please refer to the Network Install section. We will not elaborate on it here.

1 MQTT Introduction

MQTT (Message Queuing Telemetry Transport, a lightweight message transmission protocol based on the publish/subscribe model) is widely used in the Internet of Things (IoT) field, especially in environments with limited network bandwidth and limited device resources. It was proposed by IBM in 1999 and is mainly used for device communication in remote monitoring and control systems. The MQTT protocol has the advantages of low bandwidth, low power consumption, and low latency, and is particularly suitable for communication in embedded systems and IoT devices.

2 MQTT Features

  • Lightweight: The MQTT protocol employs a minimalist protocol header, reducing the size of the message header, making it suitable for devices with limited bandwidth and computing resources.
  • Reliability: MQTT supports three quality of service (QoS) levels, ensuring reliable delivery of data.
  • Real-time: MQTT is suitable for low-latency application scenarios, with messages being pushed to subscribers as soon as possible in real time.
  • Retained Messages: MQTT supports the "retained message" feature, where the broker saves the last published message. When a new device subscribes to a certain topic, the broker will immediately send the retained message.
  • Persistent Sessions: MQTT allows clients to resume session states after disconnection. Messages sent during the disconnection period can continue to be received after the client reconnects.

3 MQTT application scenarios

  • Industrial Automation: In industrial environments, equipment, sensors, controllers, etc. all need to exchange data. The MQTT protocol is suitable for providing real-time communication in complex industrial automation systems.
  • Smart Grid: In smart grid applications, power equipment (such as substations, smart meters, switchgear, etc.) exchange real-time data with the control center via Ethernet and use the MQTT protocol for remote monitoring and control.
  • Remote Equipment Monitoring and Management: Applicable to devices that require remote monitoring and management, such as remote weather stations, environmental monitoring equipment, etc. Real-time sensor data of the equipment can be obtained through the MQTT protocol.

4 MQTT Publish/Subscribe Model

The Publish-Subscribe Pattern is a messaging delivery mode that decouples the client that sends the message (the publisher) from the client that receives the message (the subscriber), eliminating the need for a direct connection between them and for them to know of each other's existence.

The essence of the MQTT Publish/Subscribe pattern lies in the fact that an intermediary role called a broker is responsible for all the routing and distribution of messages. The publisher sends messages with a topic to the broker, and the subscriber subscribes to the topic to receive the messages of interest.

In MQTT, topics and subscriptions cannot be registered or created in advance, so the broker cannot predict whether there will be subscribers for a certain topic and how many there will be. Therefore, it can only forward messages to the current subscribers. If there are no subscribers at the moment, the message will be discarded directly.

The MQTT Publish/Subscribe pattern consists of four main components: publisher, subscriber, broker, and topic.

  • Publisher (Publisher): Responsible for publishing messages to a topic. The publisher can only send data to one topic at a time, and it does not need to care about whether the subscribers are online when publishing messages.
  • Subscriber (Subscriber): Subscribers receive messages by subscribing to topics and can subscribe to multiple topics at once.
  • Broker (Broker): Responsible for receiving messages from publishers and forwarding them to eligible subscribers. Additionally, the broker also needs to handle requests initiated by clients such as connection establishment, disconnection, subscription, and cancellation.

Topic (Topic): Topics are the basis for message routing in MQTT. They are similar to URL paths and use slashes (/) for hierarchical division, such as sensor/1/temperature. A topic can have multiple subscribers, and the broker will forward the messages under that topic to all subscribers; a topic can also have multiple publishers, and the broker will forward the messages in the order they arrive.

The communication flow of the MQTT protocol is as shown in the following figure:

5 MQTT Quality of Service (QoS) Explanation

QoS 0: Messages are sent at most once, they may be lost, and no retry is performed. This is the most basic QoS level, which does not guarantee the transmission or sequence of messages.

Usage scenario: Real-time transmitted updated data, such as temperature and humidity, the loss of messages has a relatively small impact on the application.

QoS 1: Messages are sent at least once. To ensure the message arrives, the sender will repeatedly send the message until it receives the confirmation response (PUBACK) from the receiver. This may result in duplicate message reception.

Usage scenario: Power monitoring data, or scenarios where accurate transmission of status information is required.

QoS 2: Messages are ensured to be sent only once and only once. This level guarantees the reliability, uniqueness, and sequence of messages. Through a four-way handshake process, it ensures that messages are not lost and will not be duplicated.

Applicable scenarios: Applications with high security requirements, such as payment systems, important equipment control, etc., cannot tolerate message duplication or loss.

6 MQTT message

In MQTT, the client can register a will message with the server during the connection process, similar to regular messages. We can set the topic, payload, etc. of the will message. When this client unexpectedly disconnects, the server will send this will message to other clients that have subscribed to the corresponding topic. These receivers can thus take timely actions. This feature is typically used to detect and respond to client failures or disconnection events, and is particularly suitable for use in IoT systems with high reliability and real-time monitoring scenarios.

For the messages of the MQTT protocol, you can refer to: Introduction · MQTT Protocol Chinese Version. This article will not elaborate on it again.

 

7 Introduction to OneNET IoT Platform

OneNET is an IoT open platform developed by China Mobile. It builds an efficient, stable and secure application platform between IoT applications and real devices. This platform supports various network environments and protocol types, enabling the rapid integration of various sensors and intelligent hardware. It provides rich APIs and application templates to support the development of various industry applications and intelligent hardware.

8 Introduction to OneNET Object Model

The object model is an abstract model used in the IoT platform to describe and manage the capabilities of devices. It defines the attributes, behaviors and events of devices, making the interaction between devices and the platform as well as applications more standardized and unified. In the OneNET platform, the object model is the core concept for device management and data interaction. Through the object model, developers can easily model, manage and use devices.

9 MQTT connection process for transmitting and receiving data to/from OneNET

1.Preparation stage

Registration and Real-name Authentication: Users need to register an account on the OneNET platform and complete real-name verification.

Create Products and Add Object Models: Log in to the Alibaba Cloud Internet of Things platform, create a product, and add the following object model functions under the product.

Create Device: Create a device under the recently created product.

2. Record parameters

Connection parameters: The connection parameters required for the MQTT protocol can be found in the official documentation of OneNET - China Mobile's IoT Open Platform. From this document, you can obtain the following three elements: server address and port, as well as security authentication.

The device name created by us is "lientld", the product ID assigned by the platform after creating the product is "usemame", and the password needs to be generated using the token generation tool. Tool instructions and download link: OneNET - China Mobile IoT Open Platform.

 

Publishing Topic: $sys/{pid}/{device-name}/thing/property/post (Property Reporting Message Topic)

Subscription Topic: $sys/{pid}/{device-name}/thing/property/post/reply (Property Reporting Response Topic)

Subscription Topic: $sys/{pid}/{device-name}/thing/property/set (Setting Topic)

Note: In the above two topics, {pid} should be replaced with the product ID and {device-name} with the device name.

3. Connecting, subscribing and publishing messages

Then we can use the connection parameters recorded above to establish the connection. Once the connection is successful, subscribe to the above subscription topic. And report the object model data by publishing the topic.

On the OneNET platform, if the data format selected during the product creation stage is OneJson format, both the receiving and sending data formats will follow the following format:

{
  "id": "123",
  "version": "1.0",
  "params": {
    "Power": {
      "value": "on",
      "time": 1524448722123
    },
    "WF": {
      "value": 23.6,
      "time": 1524448722123
    }
  },
  "method":"thing.{Function type}.{Method}"
}

The field "id" is the unique identifier of the request, with a value of "123", used to track the response of the request; "version" represents the version number of the OneJSON data format, which is "1.0" here; the "params" field contains the attribute data of the device, including the attribute identifier, the corresponding value, and the timestamp; the "method" field specifies the type of operation performed by the device, which is "thing.{function type}.{method}", used to indicate the operation carried out by the device.

4. Message Reception Processing

Receiving Messages: When a message is received, we only need to parse it according to the above JSON format and then carry out the corresponding processing.

10 Implementation Process

Next, let's see how to establish an MQTT connection to OneNET on the W55MH32, and perform subscription, message publishing, and message reception processing.

Note: Since this example requires internet access, please ensure that the network environment and configuration of the W55MH32 can access the internet normally.

Step 1: Initialize the MQTT client

 

1.     mqtt_init(SOCKET_ID, mqtt_send_ethernet_buf, mqtt_recv_ethernet_buf);

Modify MQTT connection parameters:

 1. mqttconn       mqtt_params = {
 2.           .mqttHostUrl = "mqtts.heclouds.com",
 3.           .server_ip   = {
 4.                           0,
 5.                           }, /*Define the Connection Server IP*/
 6.           .port           = 1883, /*Define the connection service port number*/
 7.           .clientid       = "W5100S_W5500", /*Define the client ID*/
 8.           .username       = "70TwP2gxl5", /*Define the user name*/
 9.           .passwd         = "version=2018-10-31&res=products%2F70TwP2gxl5%2Fdevices%2FW5100S_W5500&et=1791400694&method=sha1&sign=0SchVg6Y2MRYn%2B9zItNZwt%2F%2FN4Y%3D", /*Define user passwords*/
10.           .pubtopic       = "$sys/70TwP2gxl5/W5100S_W5500/thing/property/post", /*Define the publication message*/
11.           .pubtopic_reply = "$sys/70TwP2gxl5/W5100S_W5500/thing/property/post/reply",
12.           .subtopic       = "$sys/70TwP2gxl5/W5100S_W5500/thing/property/set", /*Define subscription messages*/
13.           .subtopic_reply = "$sys/70TwP2gxl5/W5100S_W5500/thing/property/set_reply",
14.           .pubQoS         = QOS0, /*Defines the class of service for publishing messages*/
15.           .willtopic      = "/wizchip/will", /*Define the topic of the will*/
16.           .willQoS        = QOS0, /*Defines the class of service for Will messages*/
17.           .willmsg        = "wizchip offline!", /*Define a will message*/
18.           .subQoS         = QOS0, /*Defines the class of service for subscription messages*/
19. };

Modify the clientid, username and password of your own platform, as well as the changes of product and device names for pubtopic and subtopic.

Step 2: Main loop, handling MQTT-related operations (connection, sending, receiving, etc.)

1.     while (1)
2.     {
3.         do_mqtt();
4.     }

Step 3: Enter the do_mqtt() function

 1. void do_mqtt(void)
 2. {
 3.     uint8_t ret;
 4.     switch (run_status)
 5.     {
 6.     case CONN: {
 7.         ret = MQTTConnect(&c, &data); /* Connect to the MQTT server */
 8.         printf("Connect to the MQTT server: %d.%d.%d.%d:%d\r\n", mqtt_params.server_ip[0], mqtt_params.server_ip[1], mqtt_params.server_ip[2], mqtt_params.server_ip[3], mqtt_params.port);
 9.         printf("Connected:%s\r\n\r\n", ret == SUCCESSS ? "success" : "failed");
10.         if (ret != SUCCESSS)
11.         {
12.             run_status = ERR;
13.         }
14.         else
15.         {
16.             run_status = SUB;
17.         }
18.         break;
19.     }
20.     case SUB: {
21.         ret = MQTTSubscribe(&c, mqtt_params.subtopic, mqtt_params.subQoS, messageArrived); /* Subscribe to Topics */
22.         printf("Subscribing to %s\r\n", mqtt_params.subtopic);
23.         printf("Subscribed:%s\r\n\r\n", ret == SUCCESSS ? "success" : "failed");
24.         if (ret != SUCCESSS)
25.         {
26.             run_status = ERR;
27.         }
28.         else
29.         {
30.             run_status = PUB_MESSAGE;
31.         }
32.         ret = MQTTSubscribe(&c, mqtt_params.pubtopic_reply, mqtt_params.subQoS, messageArrived); /* Subscribe to Topics */
33.         printf("Subscribing to %s\r\n", mqtt_params.pubtopic_reply);
34.         printf("Subscribed:%s\r\n\r\n", ret == SUCCESSS ? "success" : "failed");
35.         if (ret != SUCCESSS)
36.         {
37.             run_status = ERR;
38.         }
39.         else
40.         {
41.             run_status = PUB_MESSAGE;
42.         }
43.         break;
44.     }
45.     case PUB_MESSAGE: {
46.         pubmessage.qos        = QOS0;
47.         pubmessage.payload    = "{\"id\":\"123\",\"version\":\"1.0\",\"params\":{\"CurrentTemperature\":{\"value\":26.6}}}";
48.         pubmessage.payloadlen = strlen(pubmessage.payload);
49.         ret                   = MQTTPublish(&c, (char *)&(mqtt_params.pubtopic), &pubmessage); /* Publish message */
50.         if (ret != SUCCESSS)
51.         {
52.             run_status = ERR;
53.         }
54.         else
55.         {
56.             printf("publish:%s,%s\r\n\r\n", mqtt_params.pubtopic, (char *)pubmessage.payload);
57.             run_status = KEEPALIVE;
58.         }
59.         break;
60.     }
61.     case KEEPALIVE: {
62.         if (MQTTYield(&c, 30) != SUCCESSS) /* keepalive MQTT */
63.         {
64.             run_status = ERR;
65.         }
66.         delay_ms(100);
67.     }
68.                 break;
69.     case RECV: {
70.         if (mqtt_recv_flag)
71.         {
72.             mqtt_recv_flag = 0;
73.             json_decode(mqtt_recv_msg);
74.         }
75.         delay_ms(100);
76.         break;
77.     }
78.     case ERR: /* Running error */
79.         printf("system ERROR!");
80.         delay_ms(1000);
81.         break;
82.  
83.     default:
84.         break;
85.     }

After entering this function, the program first attempts to connect to the specified MQTT server. If the connection is successful, it enters the subscription state; if the connection fails, it directly enters the error state and prints the error message.

In the subscription state, two topics are subscribed to: one is the subscription topic for receiving messages, and the other is the publishing topic for sending replies. If both of these topics are successfully subscribed to, it enters the message publishing state; if there is a failure during the subscription process, it enters the error state and prints the error message.

After entering the message publishing state, a message is constructed and attempted to be published. If the publishing is successful, it enters the keep connection state; if the publishing fails, it enters the error state and prints the error message.

In the keep connection state, messages are continuously received and checks are made to see if there are any messages that need to be processed. If any received messages require processing, the corresponding processing is carried out.

At any step, if an error occurs, it immediately enters the error state and prints out detailed error information.

11 Run results

After the burning routine was executed, the PHY link was first detected, then the network address information was obtained through DHCP and the domain name of the DNS resolution server was retrieved. Next, the server was connected and the subscription topic was subscribed to. Finally, the object model data was sent. Subsequently, the successful reporting information sent by the OneNET platform was received. At this point, it was observed that the platform's object model data had been updated and displayed. As shown in the figure below:

Then we used the online device debugging function of the ONENET platform to debug the LWDSwish state, and sent data. At this point, the W55MH32 received the sent message and carried out the corresponding response operation. As follows: Execute LED OFF:

 

12 Summary

This article explains how to implement the MQTT protocol on the W55MH32 chip and connect to the OneNET platform. Through practical examples, it demonstrates the complete process from preparation, connection configuration, message subscription, publishing, and reception processing. The article details the concepts, characteristics, application scenarios, publish/subscribe mode, QoS levels of the MQTT protocol, as well as the knowledge related to the OneNET IoT platform and object models, helping readers understand its practical application value in the interaction between IoT devices and cloud data.

The next article will explain how to set multiple Sockets to the TCP client mode on the W55MH32 and test connecting to the same server. It will also analyze the core principles and applications of multi-Socket connections, and explain the specific steps and key points for implementing this function on the W55MH32. Stay tuned!

 

 

WIZnet is a non-chipfoundry semiconductor company founded in 1998. Its products include the Internet processor iMCU™, which adopts TOE (TCP/IP Offloading Engine) technology and is based on a unique patented fully hardwired TCP/IP. iMCU™ is designed for embedded Internet devices in various applications.

WIZnet has over 70 distributors worldwide, with offices in Hong Kong, South Korea, and the United States, providing technical support and product marketing.

The region managed by the Hong Kong office includes: Australia, India, Turkey, Asia (excluding South Korea and Japan).

Documents
Comments Write