An agricultural machine housekeeper platform internet of things system based on MQTT communication protocol

Abstract

The application relates to the technical field of Internet of Things agricultural machine equipment communication, in particular to an agricultural machine housekeeper platform Internet of Things system based on an MQTT communication protocol, which is deeply customized on the basis of a standard MQTT5.0 protocol: QoS is fixed as 1, a heartbeat interval is 5 seconds, and a timeout threshold is 180 seconds; a unique DT special protocol header is created, built-in business instructions, sensor types and operation type fields are arranged; a four-stage serial authentication mechanism is used to check ClientID, an account password, IMEI and ICCID; double-layer topic subscription is used to balance single-device precise management and control and cluster batch operation and maintenance; terminal uplink contains 5-second-period operation reporting and 200-millisecond connection breakage and retransmission; platform downlink supports remote upgrading, parameter configuration, image evidence and log acquisition; MQTT signaling and TCP image double-link transmission is used, image data is packeted at 200-millisecond intervals and is integrated with multidimensional verification; and a hierarchical abnormal response system is matched. The application improves the scene adaptability, weak network stability and compliance of agricultural machine communication and is suitable for the whole-process digital management and control of various intelligent agricultural machines.

Description

Technical Field

[0001] This invention relates to the field of IoT agricultural machinery equipment communication technology, specifically to an IoT system for an agricultural machinery management platform based on the MQTT communication protocol. Background Technology

[0002] With the large-scale promotion of smart agriculture technology, various intelligent agricultural machinery terminals and IoT data collection devices have been widely used in agricultural operations such as sowing, deep plowing, rotary tillage, spraying, and harvesting. This enables remote status monitoring, operation data collection, intelligent fault alarms, and remote operation and maintenance management of agricultural machinery equipment, and has become a core necessity for the intelligent upgrading of modern agriculture. As the core platform for the overall management of various agricultural machinery terminals, the agricultural machinery management platform urgently needs to rely on a stable, efficient, and standardized proprietary communication protocol to achieve reliable two-way data interaction between the platform and a large number of field terminal devices.

[0003] Currently, most agricultural machinery IoT communication in the industry uses the outdated MQTT 3.1.1 general protocol or scattered device-specific protocols. The general IoT protocol is not adapted to the industry characteristics of agricultural machinery mobile operations in the field, weak network fluctuations, and mixed networking of multiple implements. It has many technical shortcomings and cannot meet the standardized management and control needs of large-scale agricultural machinery clusters. The specific defects are as follows: 1. The general MQTT protocol does not have agricultural-specific business fields, and cannot distinguish agricultural machinery operation types such as sowing, deep loosening, spraying, and harvesting. It also cannot identify agricultural-specific sensor types such as attitude, pressure, and photoelectric sensors. When multiple types of agricultural machinery are networked together, data parsing errors and business data confusion are likely to occur.

[0004] 2. Traditional protocols lack adaptation and transmission strategies for weak networks in agricultural machinery. Network fluctuations are frequent in farmland operation areas, and equipment may experience short-term offline situations. Fixed-frequency transmission mechanisms are prone to loss of core agricultural data such as operation trajectory, operation area, and fault location. Furthermore, there is no supporting data retransmission mechanism, which cannot guarantee the integrity of operation data.

[0005] 3. Agricultural machinery and equipment are characterized by open-air deployment, cross-regional transfer, and mobile operation. The single account password authentication mode of general equipment cannot meet the industry regulatory requirements for compliance traceability, prevention of illegal access, and prevention of theft of network access for agricultural machinery and equipment. The security and traceability of equipment access are insufficient.

[0006] 4. Traditional protocols have a narrow functional coverage and are not adapted to the unique business of agricultural machinery, such as operation image evidence collection, equipment calibration, remote firmware upgrade, operation log traceability, and cross-platform data synchronization, making it difficult to support the digital management and control of agricultural machinery throughout its entire life cycle.

[0007] 5. The anomaly handling mechanism is highly general but lacks specificity. It does not have standardized response and handling logic designed for agricultural-specific fault scenarios such as agricultural machinery self-test failures, continuous operation alarms, abnormal image packet transmission, and cross-platform forwarding failures. As a result, the fault location efficiency is low and remote operation and maintenance is difficult.

[0008] In summary, existing general IoT protocols and traditional agricultural machinery proprietary protocols generally suffer from problems such as incompatible architecture with agricultural scenarios, lack of dedicated business fields, insufficient weak network transmission capabilities, security authentication systems that do not meet agricultural machinery regulatory requirements, and incomplete coverage of operation and maintenance functions. The industry lacks a standardized communication system specifically designed for scenarios such as multi-machine networking, mobile operation in weak networks, large-scale cluster management and control, and equipment compliance traceability. As a result, agricultural machinery management platforms suffer from poor compatibility with various agricultural machinery terminals, low data transmission accuracy, and high remote operation and maintenance costs, which seriously restricts the standardization and large-scale implementation of smart agriculture. Summary of the Invention

[0009] The purpose of this invention is to provide an IoT system for an agricultural machinery management platform based on the MQTT communication protocol, thereby solving the problems mentioned in the background art.

[0010] An IoT system for an agricultural machinery management platform based on the MQTT communication protocol includes a protocol basic parameter configuration module, which fixes the QoS level to 1, the Retain flag to false, the heartbeat sending interval to 5 seconds, the connection timeout threshold to 180 seconds, and the disconnection data resending interval to 200 milliseconds.

[0011] The general fixed communication header structure module, in addition to the three basic commands of device connection, topic subscription and heartbeat reporting, all agricultural business interaction data is equipped with DT exclusive protocol header. The protocol header includes at least 2 bytes of agricultural machinery exclusive data identifier header, 1 byte of protocol version, 1 byte of agricultural business command flag, 1 byte of uplink and downlink response flag, dual time sequence timestamp, sensor type field and operation type field;

[0012] The device connection and authentication mechanism module allows the terminal to initiate a connection request via a CONNECT message, performing four levels of serial verification: ClientID verification, account password verification, IMEI verification, and ICCID verification. Once all verifications are successful, a persistent long connection is established.

[0013] The topic subscription mechanism module allows the terminal to subscribe to both device-specific private topics and global public configuration topics via SUBSCRIBE messages. Both types of topics are configured with QoS1 service level.

[0014] The terminal uplink data reporting system module includes terminal information reporting, 5-second cycle operation data reporting, and alarm reporting after equipment self-test anomalies. The operation data reporting is configured with a 200-millisecond disconnection retransmission mechanism.

[0015] The platform's downlink command control system module executes commands for remote upgrades, parameter settings, parameter queries, data retransmission, image acquisition control, and remote log retrieval through PUBLISH / PUBACK bidirectional message interaction.

[0016] The module features dual-link transmission of MQTT signaling and TCP image data. Signaling data is transmitted via the MQTT 5.0 link, while image data is transmitted in packets at 200-millisecond intervals using a customized TCP protocol. The image data packets integrate device identification, operation time, latitude and longitude positioning, packet sequence number, and cumulative checksum.

[0017] The hierarchical anomaly handling and response mechanism module, equipped with standardized response codes and fault descriptions, automatically executes reconnection, retransmission, and alarm recording and handling logic.

[0018] Furthermore, the ClientID adopts a fixed 12-digit numerical encoding rule. The first 6 digits are the agricultural machinery equipment type code, used to distinguish various types of agricultural machinery equipment such as seeders, rotary tillers, and harvesters. The last 6 digits are the unique serial number of the equipment. The platform verifies whether the current ClientID has been registered and is in a normal activation state by searching the local equipment registration database. Unregistered, deregistered, or disabled device IDs will be directly identified as illegal network access devices, and communication connections will be refused.

[0019] Further defining the terminal information reporting in the terminal uplink data reporting system, the triggering conditions include: active full reporting after the device powers on and completes authentication, immediate incremental reporting when core hardware or network parameters change, passive response reporting when receiving a platform parameter query instruction, and timed full reporting every 24 hours.

[0020] Further specifying, the alarm reporting triggering logic is as follows: after the device is powered on, it automatically completes a self-test. If a persistent hardware or communication failure is detected after 5 minutes of operation, an alarm report is triggered. Similar failures are repeatedly pushed in a 1-minute cycle.

[0021] Furthermore, in the MQTT signaling and TCP image dual-link transmission module, the image data packets uniformly carry a DT fixed information header, a unique terminal number, a photo type, a camera location, a data length, a collection time, latitude and longitude coordinates, a total number of packets, a current packet sequence number, image payload data, an accumulation and checksum, and a fixed tail identifier. The server verifies data integrity through the accumulation and checksum, splices and integrates legitimate packets, and directly discards abnormal or incomplete data packets and triggers a retransmission mechanism.

[0022] Furthermore, the hierarchical anomaly handling and response mechanism module addresses the following anomaly scenarios: invalid ClientID, incorrect account password verification, failed IMEI / ICCID verification, incorrect message parameters, incorrect platform parameter settings, failed firmware download, failed firmware MD5 verification, and failed firmware upgrade. Each anomaly scenario corresponds to a unique response code and standardized handling logic.

[0023] Furthermore, the terminal remote upgrade command in the platform's downlink command control system module includes firmware download address, file name, MD5 checksum, and FTP account and password parameters. The terminal completes remote secure firmware download, integrity verification, and automated upgrade based on these parameters.

[0024] Furthermore, the system is configured with a tiered automatic reconnection mechanism for terminals: the first 5 reconnections are spaced 2 seconds apart, the 5th to 15th reconnections are spaced 10 seconds apart, and if more than 15 reconnections fail consecutively, the reconnection interval is increased to 30 seconds. After a successful reconnection, the system automatically re-executes the four-level authentication and two-level topic subscription, and batch resends the cached data from the period of disconnection.

[0025] Furthermore, the image acquisition and control system of the platform's downlink command system supports real-time photo capture and evidence collection using a single or dual camera, as well as customizable photo capture intervals, enabling visualized traceability of the entire farmland operation process.

[0026] Furthermore, the system is based on MQTT 5.0 custom user attributes to achieve protocol iteration and expansion, supporting the addition of new device parameters, business instructions, data types and operation scenarios, without requiring modification to the core protocol architecture.

[0027] Beneficial effects

[0028] The advantages of this invention compared to the prior art are as follows:

[0029] 1. Deeply adapted to agricultural scenarios, it abandons the inherent defects of the general MQTT protocol, such as lack of industry attributes and weak scenario adaptability. It is customized and developed entirely around the core agricultural needs of multi-machine collaborative operation, multi-sensor fusion data collection, farmland visualization and evidence collection, equipment compliance traceability, and large-scale cluster management. It has created a unique agricultural machinery-specific protocol header, a full-business instruction coding system, and an agricultural-specific data format, which comprehensively covers various agricultural machinery operation scenarios and solves the problems of poor adaptability of general IoT protocols to agricultural scenarios, the messiness and inconsistency of traditional agricultural machinery private protocols, and insufficient equipment compatibility.

[0030] 2. Optimize the weak network adaptive transmission mechanism: Customize QoS1 reliable transmission, 5-second high-frequency heartbeat keep-alive, and a dual-mode transmission strategy of regular reporting + high-speed retransmission, which improves the data transmission success rate by more than 30% compared with traditional protocols.

[0031] 3. Adaptable to clustered management and control mode: It features a unique two-layer topic subscription mechanism that balances precise operation and maintenance of a single machine with batch management and control of the entire domain. It also leverages MQTT 5.0's custom extended attributes to flexibly adapt to new devices and new scenarios.

[0032] 4. Construct a comprehensive compliance traceability system. The four-level access verification mechanism enables traceability of equipment access and accountability for anomalies. It is equipped with functions such as remote firmware upgrade, log verification, and parameter configuration, which significantly reduces field operation and maintenance costs. Detailed Implementation

[0033] To enable those skilled in the art to better understand the technical solution of the present invention, the technical solution of the present invention will be further described below in conjunction with embodiments.

[0034] Example:

[0035] An IoT system for an agricultural machinery management platform based on the MQTT communication protocol includes a protocol basic parameter configuration module, a general fixed communication header structure module, a device connection and authentication mechanism module, a topic subscription mechanism module, a terminal uplink data reporting system module, a platform downlink command control system module, an MQTT signaling and TCP image dual-link transmission module, and a hierarchical anomaly handling and response mechanism module.

[0036] The protocol's basic parameter configuration module fixes the QoS level to 1, the Retain flag to false, the heartbeat sending interval to 5 seconds, the connection timeout threshold to 180 seconds, and the disconnection data retransmission interval to 200 milliseconds. After completing network authentication and topic subscription, the terminal starts an independent hardware timer to actively send PINGREQ heartbeat messages to the platform at a fixed 5-second interval. The local timer is reset after each heartbeat transmission. If no PINGRESP response message is received from the platform after sending the heartbeat message, the terminal will retry 3 times consecutively, with a 2-second interval between each retry. If no response is received after three retries, the local communication link is deemed to have failed, and an automatic reconnection process is immediately triggered.

[0037] The platform records the last heartbeat reception time of each terminal in real time and continuously monitors the online status of the link. The platform's offline determination rule is that when the difference between the current system time and the terminal's last heartbeat reception time is ≥180s, the terminal is determined to be offline. After confirming offline, the platform actively sends a DISCONNECT message to close the long connection, simultaneously records the device's offline status in the database, and pushes offline alarm information to the agricultural machinery management backend, realizing real-time perception and visual monitoring of the device's offline status;

[0038] After the terminal detects a link failure or is actively disconnected by the platform, it initiates a tiered reconnection strategy adapted to weak network fluctuation scenarios, balancing the real-time reconnection requirements with the low-power operation requirements of the device: the first 5 reconnection intervals are set to 2 seconds to quickly repair the momentary network disconnection; the reconnection intervals from the 5th to the 15th are adjusted to 10 seconds; if more than 15 reconnection failures occur consecutively, the reconnection interval is increased to 30 seconds, effectively reducing terminal power consumption and network resource consumption. After the terminal successfully reconnects, it will automatically re-execute the four-level network access authentication and two-layer topic subscription process, and batch resend all job data and alarm data cached during the disconnection period to ensure continuous, complete, and uninterrupted business data.

[0039] Addressing the technical pain points of traditional general protocols' inability to distinguish between agricultural machinery types, operating modes, and sensor types, leading to data mixing and parsing errors in multi-device networking, this invention innovatively creates a standardized fixed communication header structure specifically for agricultural machinery. Besides the three basic signaling commands—device connection, topic subscription, and heartbeat reporting—all other agricultural business interaction data carries a customized DT-specific protocol header. This header incorporates highly adaptable fields tailored to agricultural scenarios, including a 2-byte agricultural machinery-specific data identifier header (DT), a 1-byte protocol version, a 1-byte agricultural business command flag, a 1-byte uplink / downlink response flag, dual-timestamp, a sensor type field, and an operating type field. This enables precise classification and independent parsing of data from different agricultural machinery, different sensors, and different operating scenarios at the data level, completely resolving data crosstalk and parsing anomalies in multi-device mixed networking. It constructs a comprehensive, standardized agricultural machinery-specific business command encoding system, filling the technical gap of the general MQTT protocol lacking industry-specific commands, and accurately matching the business needs of agricultural machinery throughout its entire lifecycle management. This instruction system covers equipment information reporting (0x00), operation data uploading (0x01), equipment alarm push (0x02), terminal parameter setting (0x03), equipment parameter query (0x04), real-time operation photo evidence collection (0x05), custom setting of photo interval (0x06), agricultural machinery equipment calibration (0x10), retransmission of historical operation data (0xFD), remote upgrade of terminal firmware (0xFE), and synchronization of equipment work logs (0xFF), realizing standardized and normalized instruction interaction for all agricultural machinery business scenarios.

[0040] The device connection and authentication mechanism module addresses the pain points of agricultural supervision, such as the difficulty in controlling illegal equipment access to the network and the lack of equipment traceability, due to the open-air deployment and cross-regional transfer of agricultural machinery. Based on the general MQTT 5.0 connection mechanism, it has created a unique four-level serial identity verification access system adapted to the agricultural machinery industry, replacing the traditional single authentication mode. This system enables compliant, traceable, anti-theft, and anti-tampering of equipment access to the network. The terminal initiates a communication connection request through the CONNECT message, adapting to the needs of continuous 24 / 7 operation of agricultural machinery. The session clearing function is disabled by default, and the online session state of the device is persistently retained to ensure communication stability during long-term continuous operation in the field.

[0041] A four-level serial verification mechanism is adopted, consisting of a 12-digit agricultural machinery-specific ClientID, a network access account password, a terminal IMEI hardware serial number, and a data SIM card ICCID. The four levels of verification are executed sequentially and are indispensable. Failure at any level will immediately terminate the network access process, reject device access, and return a corresponding fault response code. The specific verification rules and execution process are as follows:

[0042] 1. Level 1 Verification: 12-bit ClientID device unique identifier verification:

[0043] The ClientID uses a fixed 12-digit numeric encoding rule. The first 6 digits are the agricultural machinery equipment type code, used to distinguish various types of agricultural machinery equipment such as seeders, rotary tillers, and harvesters. The last 6 digits are the unique serial number of the equipment. The platform checks whether the current ClientID has been registered and is in normal use by searching the local equipment registration database. Unregistered, deregistered, or disabled device IDs will be directly identified as illegal network access devices and communication connections will be refused.

[0044] 2. Secondary verification: Verification of network access account and password

[0045] Extract the Username and Password fields from the terminal's CONNECT message and accurately compare them with the device's exclusive account and password registered on the platform to complete the terminal's network access permission verification. This effectively prevents unauthorized devices from accessing the platform without authorization. If the account and password do not match, the device's network access process will be terminated directly.

[0046] 3. Level 3 Verification: Terminal IMEI Hardware Serial Number Verification

[0047] The IMEI hardware serial number in the custom extended attributes of the CONNECT message is read and compared with the device-specific IMEI information filed with the platform to complete the terminal hardware legality verification, effectively preventing the risk of illegal network access after illegal modification or module replacement of the device.

[0048] 4. Level 4 Verification: Data SIM Card ICCID Verification

[0049] The system reads the unique ICCID code of the data SIM card in the extended attributes of the message to verify the binding and matching relationship between the data SIM card and the agricultural machinery equipment. This prevents illegal scenarios where multiple devices share a single data SIM card for fraudulent network access. It achieves full-link traceability and control of equipment hardware, network media, and network access identity. Only after all four levels of verification pass can the platform establish a persistent long connection with the terminal and distinguish various access anomalies and faults through a dedicated CONNACK response code. This achieves standardized, regulated, and traceable control of the agricultural machinery equipment network access process.

[0050] Main subscription mechanism module: Addressing the dual business scenarios of precise operation and maintenance of single agricultural machinery devices and batch management of multi-device clusters, this module features a unique dual-layer topic subscription mechanism specifically for agriculture. It overcomes the functional limitations of a single topic in general MQTT. Terminals complete dual-topic subscription configuration via SUBSCRIBE messages. The first is a device-specific private topic bound to a unique agricultural machinery ClientID, enabling precise point-to-point management and independent data interaction for a single device, completely avoiding data crosstalk issues across multiple devices. The second is a globally shared configuration topic (shared / config), supporting the platform in issuing configuration commands in batches to all online agricultural machinery devices and uniformly updating operating parameters, adapting to the operation and maintenance needs of large-scale farmland cluster operations. Both types of topics are configured with QoS1 service level to ensure accurate, complete, and lossless delivery of agricultural management commands.

[0051] The terminal uplink data reporting system module combines dedicated business logics for routine agricultural machinery operation data collection, weak network disconnection retransmission, and proactive fault warning. It constructs a differentiated, scenario-based, and fully closed-loop terminal uplink data reporting system. All reporting strategies are deeply aligned with actual field operation scenarios, balancing data real-time performance, completeness, and continuity. Specific types are as follows: Terminal Information Reporting: Clearly defines standardized reporting trigger conditions, full-scale reporting parameters, data types, and value ranges to achieve standardized and unified management of basic equipment information. Reporting Trigger Conditions: After the device powers on and completes four-level authentication and topic subscription, it proactively reports a full data once. Incremental reporting is triggered immediately when core hardware and network parameters such as terminal hardware version, firmware version, ICCID, and IMEI change. The terminal passively responds and reports when the platform issues a 0x04 parameter query command. The device completes a full parameter report every 24 hours, synchronously updating the latest operating configuration status of the device.

[0052] The system reports operational data to adapt to continuous field operations of agricultural machinery. It sets a 5-second steady-state reporting frequency and synchronizes core business data such as equipment trajectory, operating area, operating depth, driving speed, operating time, and latitude and longitude coordinates in real time. For scenarios involving network fluctuations in the field or temporary equipment disconnection, a 200ms high-speed retransmission mechanism is configured. After the equipment reconnects, it automatically retransmits historical operational data for the period of network interruption in batches, completely eliminating the problems of missing operational data and statistical distortion. This ensures that agricultural operational data is fully traceable, verifiable, and reproducible. At this time, the complete composition of the reporting message is a standardized DT protocol header + time sequence timestamp + sensor type code + operation type code + 4-byte unique data ID + 1-byte data length + CAN format operational payload data + message check bit.

[0053] Terminal alarm reporting is implemented to meet the emergency management needs of agricultural machinery field faults. It is configured with agriculture-specific alarm triggering logic: after powering on, the equipment automatically completes a self-check, mitigating the risk of operating machinery with defects from the source. If a persistent hardware or communication fault is detected 5 minutes after the equipment starts running, an alarm report is immediately triggered. Similar faults are repeatedly pushed in a 1-minute cycle, accurately covering high-frequency field faults in agricultural machinery such as GPS positioning anomalies, sensor failures, communication module anomalies, and power supply failures. This ensures the platform can perceive equipment anomalies in real time, quickly handle operational hazards, and reduce agricultural production losses. The complete reporting message consists of a standardized DT protocol header + alarm timestamp + 1-byte alarm type code + fault latitude and longitude location information + device ClientID + fault description payload + checksum.

[0054] The platform's downlink command control system module addresses industry pain points such as the dispersed deployment of agricultural machinery in the field, wide operational coverage, high difficulty in on-site maintenance, and high troubleshooting costs. It establishes a complete agricultural-specific platform-based remote control system, relying on a standardized PUBLISH / PUBACK two-way message exchange mechanism to achieve remote operation and maintenance control of agricultural machinery across all scenarios. This replaces the traditional manual on-site debugging mode, significantly improving agricultural machinery operation and maintenance efficiency and reducing field operation and maintenance costs. Specific control functions are as follows:

[0055] Remote terminal upgrade: The platform sends core parameters such as firmware download address, file name, MD5 checksum, FTP account and password to support secure remote download, integrity verification and automated upgrade of terminal firmware, without the need for on-site disassembly to update device programs.

[0056] Terminal parameter settings: Supports remote configuration and dynamic modification of various terminal operating parameters, such as cross-platform forwarding rule switching, terminal number configuration, device payment status update, and camera quantity adaptation, to meet the device parameter control needs of different operating scenarios.

[0057] Terminal parameter query: The platform can proactively issue parameter query commands, and the terminal can return all device configuration parameters through custom user attributes, realizing remote visual verification and ledger calibration of device operating status and configuration information.

[0058] Resend operation data: Supports targeted resending of historical operation data and operation image data by specified date, duration, target platform, and data type, ensuring that historical operation ledgers are complete, traceable, and reconcilable.

[0059] Image acquisition and control: Adapts to the regulatory needs of modern agricultural operation certification and field condition monitoring, supports real-time photo taking and certification by single / dual cameras, and customizable operation photo intervals, realizing full-process visual traceability of farmland operations, and meeting the core business requirements of agricultural operation quality verification, production supervision, and compliance certification.

[0060] Remote Log Acquisition: The platform remotely retrieves terminal work logs via FTP service, distributing parameters such as FTP address, account, password, and log query date. The terminal actively uploads local operation logs, fault logs, and communication logs, enabling remote fault location and troubleshooting, and full-dimensional traceability of operational status, significantly reducing the difficulty and cost of field equipment maintenance.

[0061] All downlink commands are uniformly composed of a standard DT protocol header + service command code + uplink / downlink response flags + platform-issued timestamp + corresponding service payload parameters + checksum. After the terminal completes the command execution, it sends back the execution result and standardized response code via a PUBACK message, forming a complete two-way closed-loop interaction.

[0062] Addressing the industry pain points of large data volumes, easily damaged data transmission in weak field networks, and high packet loss rates in high-definition evidence collection images of agricultural machinery operations, this product features a unique dual-link collaborative architecture combining MQTT signaling control and TCP big data image transmission. This architecture overcomes the performance bottleneck of the common single MQTT transmission architecture and employs a differentiated transmission logic with separate links: lightweight equipment control, status reporting, and command interaction signaling data are transmitted via the low-latency MQTT 5.0 link, while large-capacity farmland operation image evidence collection data is transmitted via a customized TCP protocol in packetized form. The 200ms transmission interval per packet precisely adapts to the fluctuating environment of weak field networks. Simultaneously, an agricultural-specific image data packet structure is constructed, integrating multi-dimensional traceability information such as equipment identification, operation time, latitude and longitude positioning, packet sequence number, accumulation, and checksum. This enables linked traceability of image data, operation location, and operation time period. Multiple data verification mechanisms automatically identify and discard abnormal data packets, effectively ensuring the integrity, validity, and compliance of agricultural evidence collection images, meeting industry regulatory evidence collection standards.

[0063] The TCP image transmission protocol is deeply adapted to agricultural machinery image acquisition and compliance evidence collection scenarios. It adopts a standardized packet transmission mechanism. All image data packets are uniformly equipped with a fixed DT header, a unique terminal number, image type, camera location, data length, acquisition time, latitude and longitude coordinates, total number of packets, current packet sequence number, image payload data, cumulative checksum, and fixed tail identifier. Through multiple verification mechanisms, it ensures accurate splicing and fusion of packet data. Incomplete, failed verification, or abnormally tampered data packets are directly discarded. At the same time, it is equipped with a dedicated response message to provide real-time feedback on the reception status, comprehensively ensuring the accuracy, integrity, and reliability of field image data transmission.

[0064] The graded anomaly handling and response mechanism module is specifically adapted to agricultural-specific anomaly scenarios such as device authentication failure, weak network data packet loss, abnormal operation parameter configuration, incomplete image transmission, firmware upgrade failure, historical data retransmission conflict, and equipment offline shutdown. It is equipped with standardized response codes, fault descriptions, and dedicated handling logic, which can quickly and accurately locate communication failures and equipment anomalies, and adapt to the business needs of remote troubleshooting and rapid operation and maintenance of agricultural machinery in the field.

[0065] The communication protocol system can be deployed collaboratively with the platform server program and the embedded program on the agricultural machinery terminal. The specific implementation method is as follows:

[0066] Protocol initialization and deployment: The server builds a standardized MQTT 5.0 service, solidifies core communication parameters such as QoS level, heartbeat duration, and timeout threshold, and preloads agricultural machinery-specific instruction codes, operation types, sensor types, and alarm type mapping rules; the agricultural machinery terminal has a built-in dedicated protocol parsing program, solidifies standard protocol headers, subscription topics, and data field parsing rules, and completes the protocol adaptation initialization between the server and the terminal.

[0067] Device compliance access authentication: After the agricultural machinery terminal is powered on, it carries unique identification parameters such as ClientID, login account and password, IMEI, and ICCID and initiates a network access request through a CONNECT message; the server performs four levels of compliance verification step by step. After all verifications are passed, a persistent long connection is established and the access result is returned through a CONNACK message, thus completing the device compliance network access authentication.

[0068] Communication Topic Subscription Configuration: After the terminal is powered on, it automatically completes the dual subscription operation of the device's exclusive private topic and the public configuration topic. The server verifies the subscription permission and confirms the successful subscription through the SUBACK message, thus building a two-way exclusive, secure and reliable communication channel between the platform and the terminal.

[0069] Routine data reporting from terminals: Terminals periodically report equipment parameters, operating status, and work data at a fixed 5-second interval. When equipment self-checks abnormalities, alarm information is proactively reported according to specific rules. All uplink data carries standardized protocol headers and timing parameters. The server confirms data reception via PUBACK messages, automatically logs abnormal data, and triggers platform alarms.

[0070] Platform remote command control: Based on business operation and maintenance needs, the platform issues control commands such as parameter configuration, firmware upgrade, photo evidence collection, data retransmission, and log acquisition through downlink PUBLISH messages; the terminal accurately parses the exclusive command code and business parameters and executes the corresponding operation. After the execution is completed, the execution result and standardized status code are sent back through PUBACK messages to complete the closed-loop interaction of the whole process.

[0071] Image data packet transmission: After the platform issues the photo collection and evidence collection command, the terminal collects field operation images and completes packet transmission at a fixed interval of 200ms through a customized TCP protocol. The server verifies the data integrity by accumulating and checking the check code, accurately splices and integrates the legitimate packets, and directly discards abnormal or incomplete data packets. At the same time, it returns a receiving response and triggers a data retransmission mechanism when necessary to ensure the integrity and validity of the image evidence collection data.

[0072] Abnormal Keep-Alive and Handling: The terminal actively reports a heartbeat message every 5 seconds to maintain a long connection. If there is no response from the platform after 3 consecutive attempts, a tiered reconnection mechanism is triggered. If the platform does not detect a heartbeat message from the terminal for 180 seconds, it immediately determines that the device is offline, actively disconnects the connection, and retains an alarm log. When problems such as malformed data packets, incorrect parameters, authentication failures, transmission anomalies, or firmware upgrade anomalies occur during communication, both ends strictly locate the anomaly type according to the standardized response code lookup table and automatically execute corresponding handling logic such as reconnection, retransmission, log recording, and alarm push, ensuring the stable and reliable operation of the system in all aspects.

[0073] Protocol Iteration and Extension Adaptation: Relying on the high scalability of MQTT 5.0's custom user attributes, device parameters, business commands, data types, and operating scenarios can be flexibly added without modifying the core protocol architecture. It can quickly adapt to new agricultural machinery and new agricultural business scenarios, ensuring the long-term availability of the protocol and its ability to adapt to business iterations.

[0074] The above provides a detailed description of an IoT system for an agricultural machinery management platform based on the MQTT communication protocol provided by the present invention. The description of the specific embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made to the present invention without departing from the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims

1. An IoT system for agricultural machinery management platform based on the MQTT communication protocol, characterized in that: This includes a protocol basic parameter configuration module, which fixes the QoS level to 1, the Retain flag to false, the heartbeat sending interval to 5 seconds, the connection timeout threshold to 180 seconds, and the disconnection data retransmission interval to 200 milliseconds. The general fixed communication header structure module, in addition to the three basic commands of device connection, topic subscription and heartbeat reporting, all agricultural business interaction data is equipped with DT exclusive protocol header. The protocol header includes at least 2 bytes of agricultural machinery exclusive data identifier header, 1 byte of protocol version, 1 byte of agricultural business command flag, 1 byte of uplink and downlink response flag, dual time sequence timestamp, sensor type field and operation type field; The device connection and authentication mechanism module allows the terminal to initiate a connection request via a CONNECT message, performing four levels of serial verification: ClientID verification, account password verification, IMEI verification, and ICCID verification. Once all verifications are successful, a persistent long connection is established. The topic subscription mechanism module allows the terminal to subscribe to both device-specific private topics and global public configuration topics via SUBSCRIBE messages. Both types of topics are configured with QoS1 service level. The terminal uplink data reporting system module includes terminal information reporting, 5-second cycle operation data reporting, and alarm reporting after equipment self-test anomalies. The operation data reporting is configured with a 200-millisecond disconnection retransmission mechanism. The platform's downlink command control system module executes commands for remote upgrades, parameter settings, parameter queries, data retransmission, image acquisition control, and remote log retrieval through PUBLISH / PUBACK bidirectional message interaction. The module features dual-link transmission of MQTT signaling and TCP image data. Signaling data is transmitted via the MQTT 5.0 link, while image data is transmitted in packets at 200-millisecond intervals using a customized TCP protocol. The image data packets integrate device identification, operation time, latitude and longitude positioning, packet sequence number, and cumulative checksum. The hierarchical anomaly handling and response mechanism module, equipped with standardized response codes and fault descriptions, automatically executes reconnection, retransmission, and alarm recording and handling logic.

2. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The ClientID uses a fixed 12-digit numerical encoding rule. The first 6 digits are the agricultural machinery equipment type code, used to distinguish various types of agricultural machinery equipment such as seeders, rotary tillers, and harvesters. The last 6 digits are the unique serial number of the equipment. The platform checks whether the current ClientID has been registered and is in normal use by searching the local equipment registration database. Unregistered, deregistered, or disabled device IDs will be directly identified as illegal network access devices and communication connections will be refused.

3. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The terminal information reporting in the terminal uplink data reporting system is triggered by the following conditions: active full reporting after the device powers on and completes authentication; immediate incremental reporting when core hardware or network parameters change; passive response reporting when receiving a parameter query instruction from the platform; and timed full reporting every 24 hours.

4. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The alarm reporting triggering logic is as follows: after the device is powered on, it automatically completes a self-test. If a persistent hardware or communication failure is detected after 5 minutes of operation, an alarm report is triggered. Similar failures are repeatedly pushed in a 1-minute cycle.

5. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that... In the MQTT signaling and TCP image dual-link transmission module, the image data packets uniformly carry a DT fixed information header, a unique terminal number, a photo type, a camera location, a data length, a collection time, latitude and longitude coordinates, a total number of packets, a current packet sequence number, image payload data, an accumulation and checksum, and a fixed tail identifier. The server verifies the data integrity through the accumulation and checksum, splices and integrates legitimate packets, and directly discards abnormal or incomplete data packets and triggers a retransmission mechanism.

6. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The hierarchical exception handling and response mechanism module addresses the following exception scenarios: invalid ClientID, incorrect account password verification, failed IMEI / ICCID verification, incorrect message parameters, incorrect platform parameter settings, failed firmware download, failed firmware MD5 verification, and failed firmware upgrade. Each exception scenario corresponds to a unique response code and standardized handling logic.

7. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The terminal remote upgrade command in the platform's downlink command control system module includes firmware download address, file name, MD5 checksum, and FTP account and password parameters. The terminal completes remote secure firmware download, integrity verification, and automated upgrade based on these parameters.

8. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The system is also configured with a tiered automatic reconnection mechanism for terminals: the first 5 reconnections are spaced 2 seconds apart, the 5th to 15th reconnections are spaced 10 seconds apart, and the reconnection interval is increased to 30 seconds if more than 15 reconnections fail consecutively. After a successful reconnection, the system automatically re-executes the four-level authentication and two-level topic subscription, and batch resends the cached data from the period of disconnection.

9. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The image acquisition and control system of the platform's downlink command system supports real-time photo capture and evidence collection using a single or dual camera, as well as customizable photo capture intervals, enabling visualized traceability of the entire farmland operation process.

10. The agricultural machinery management platform IoT system based on the MQTT communication protocol according to claim 1, characterized in that: The system is based on MQTT 5.0 and uses custom user attributes to implement protocol iteration and expansion, supporting the addition of new device parameters, business instructions, data types and operation scenarios without modifying the core protocol architecture.