Agri-Synergy: A Hardware-Software Co-Designed Hybrid IoT System for Sensor Interface Standardization and LLM-Driven Interactive Decision Support

1. Introduction

The global agriculture system is facing increasing demands due to population growth, climate change and resource scarcity [1,2]. The advent of smart agriculture powered by the Internet of Things (IoT) and big data along with artificial intelligence provides a vital route towards increased productivity and sustainability [3,4]. Real time collection of environmental parameters like soil moisture, temperature, and humidity through IoT monitoring systems generates the raw data streams which are processed at scale using big data analytics and transformed into actionable insights by artificial intelligence; these form the foundational data and decision layer for precision agriculture [5,6]. As a result of the constant advancements in low-cost sensing technologies, IoT monitoring systems have evolved out of lab demonstrations and started being used in practice. Evaluation of low-cost soil moisture sensors deployed in irrigated orchards has also validated their feasibility when implemented under real cultivation conditions [7].

Despite these advances, widespread adoption of IoT systems across diverse farmland environments frequently encounters a critical bottleneck: data heterogeneity. The coexistence of diverse sensor types, communication protocols, and data formats disrupts data consistency and ultimately undermines the reliability of higher-level analysis [6,8]. This heterogeneity manifests at two distinct levels: communication protocol heterogeneity, where sensors from different manufacturers may use incompatible protocols such as Modbus, SDI-12 (Synchronous Data Interface at 1200 baud), or proprietary interfaces; and data format heterogeneity, where even under the same protocol, variations in data frame length, parity bits, and calibration curves prevent seamless integration. Recently, Miller et al. [9] highlighted that achieving seamless interoperability between heterogeneous sensing platforms remains a fundamental challenge in smart farming adoption.

Existing solutions to sensor heterogeneity predominantly focus on software-based data harmonization at the cloud or gateway layer, employing data fusion techniques, middleware, or cloud-based integration frameworks [10]. Early-stage sensor data fusion pipelines have been explored to reconcile heterogeneous data streams, yet these frameworks still operate downstream of data acquisition [11]. While these solutions demonstrate technical feasibility, they suffer from three fundamental limitations: first, they operate after data acquisition, meaning that heterogeneous data must still travel through the network in non-standardized formats, consuming bandwidth and increasing processing complexity at the gateway; second, they treat the symptom rather than the root cause—non-standardized hardware interfaces—which remains largely unaddressed [9,12]; and third, they rely on cloud connectivity, making them vulnerable to network interruptions and introducing additional latency.

More recent systematic reviews consolidate these observations: Roccatello et al. [13], identify that lack of shared communication standards between IoT devices in precision agriculture presents major challenges since different sensors and systems utilize heterogeneous data formats which are often incompatible with one another. They suggest a connector device translating sensor data into a standard format prior to entering the database – addressing the issue at the data formatting level without considering hardware interface unification. Likewise, Ahoa et al. [14] carried out a systematic review of 72 studies and identified 27 distinct integration challenges covering organizational, technological and data governance aspects, with data interoperability remaining a critical hurdle limiting the development of smart systems such as machine learning and generative AI. Their study identifies that current solutions predominantly focus on point to point and cloud based integration approaches, concentrating on software level data harmonization and ignoring the need for standardizing hardware interfaces. Together, these studies highlight how although there have been attempts to standardize data formats at the software level, unification of hardware interfaces --the foundational step for having consistent data from the source-- remains an underexplored area worth exploring. Our approach tackles these issues by unifying sensor interfaces at the physical layer so that data is standardized from the point of acquisition thus removing heterogeneity before it enters the network.

Beyond hardware-level unification, the system incorporates on-node edge processing to reinforce data standardization at the point of acquisition. Recent work on smart edge computing frameworks has demonstrated the value of shifting data processing from the cloud to the field level for real-time agricultural decision-making [15]. Instead of relying on post-acquisition software-based harmonization, edge processing—including cyclic redundancy check (CRC) validation, physical unit conversion, and JavaScript Object Notation (JSON) formatting—ensures that only structured and validated data enters the network. By performing data quality assurance and formatting directly on the sensor node, edge processing complements hardware standardization and shifts the harmonization burden from the cloud to the data source. Consequently, this approach reduces bandwidth consumption and enables local processing to remain functional even under intermittent connectivity. For resource-constrained agricultural environments characterized by unstable power supplies and limited network coverage, this capability provides a critical safeguard [16].

Alongside these developments, despite the progress in AI driven decision support, its implementation continues to face several barriers. Many AI applications in agri-culture demand local model deployment, special machine learning expertise and complex human computer interaction [17,18]. Amalan and Arul Aram [19] explored the adoption of AI amongst farmers, highlighting some key barriers related to high costs, low digital literacy, inadequate rural infrastructure and linguistic diversity in communication. They conclude that successful adoption requires farmer centric strategies supported by supportive extension services instead of simply offering technological solutions. Such challenges become even more prominent in smallholder settings, where usability and cost barriers hinder adoption [20,21]. To lower the entry barrier for farmers, the system integrates the DeepSeek LLM API with an agricultural knowledge base and real-time dynamic data (e.g., sensor and weather data) for natural language-based decision support, while functioning without local model deployment. Farmers obtain agricultural guidance through natural language queries without requiring specialized machine learning expertise.

This research points to the need for a hardware–software co-design approach—embodied in the proposed Agri-Synergy system, a name that encapsulates both its agricultural focus ("Agri") and its synergistic integration of hardware–firmware co-designed edge processing with AI-driven software interaction. The main contributions of this work are twofold:

(1) A hardware–firmware co-designed edge processing methodology. Unlike conventional approaches that merely adopt RS485 as a physical bus while still tolerating heterogeneous data formats from various sensors, this study designed a universal sensor PCB with an RS485/Modbus interface to unify multi-source sensor access at the physical layer. While RS485/Modbus is not novel per se, its application as a mandatory hardware standard, combined with on-node edge processing (CRC validation, unit conversion, and JSON formatting) to eliminate heterogeneity at the source—rather than reconciling it later—constitutes the methodological contribution of this work.

(2) A low-cost AI interaction paradigm. In contrast to existing agricultural Q&A systems that rely on static knowledge bases or require local deployment of complex models, this paradigm integrates the DeepSeek LLM API with an agricultural knowledge base and dynamically incorporates real-time sensor data and other dynamic data (e.g., local real-time weather), delivering context-aware decision support through natural language queries. The system operates purely as an API client, avoiding the technical and economic costs of local model deployment, thereby significantly lowering the professional barriers for farmers to access intelligent decision-making systems.

The system was deployed in a 200 m² experimental plot planted with perilla (Perilla frutescens) in Yongmei Village, Lianshan County, Guangdong Province, China. Five sensor nodes were installed to enable multi-parameter sensing of soil and air conditions, while two actuator nodes were used to control irrigation and ventilation. Field tests confirmed that the system operated reliably, with performance meeting the expected design goals. Detailed experimental results and analysis are presented in Section 3.

The remainder of this paper is structured as follows: Section 2 presents the system design and implementation; Section 3 presents the experimental setup, procedures, results, and discussion; and Section 4 concludes the paper and outlines future directions.

2. Materials and Methods

This section presents the system design and implementation from a hardware-software co-design perspective. At the hardware layer, a universal sensor PCB integrated with an RS485/Modbus interface is developed to unify multi-source sensor access at the physical layer. At the firmware layer (on-node edge processing), operations including CRC validation, unit conversion, and JSON formatting ensure that data is standardized at the point of acquisition before entering the network. This on-node processing complements hardware unification by enforcing data quality assurance at the source. At the software layer, the DeepSeek LLM API is integrated with an agricultural knowledge base and real-time sensor data, providing context-aware, natural language-based decision support that allows farmers to interact with the system without local model deployment or specialized expertise. Through this co-design approach, the system aims to eliminate data heterogeneity at the source, lower the adoption barrier for smart agricultural systems, and deliver more effective decision support by leveraging dynamic data—offering capabilities that surpass those of static knowledge-based AI solutions. The data and control flow between layers is illustrated in Figure 1.

As shown in Figure 1, the system adopts a four-layer architecture: Perception and Execution Layer, Network Layer, Cloud Layer, and Application Layer. As shown at the bottom of Figure 1, the Perception and Execution Layer contains five sensor nodes (Sensor Nodes 1–5) and two actuator nodes (Actuator Nodes 1–2), connected respectively to sensors measuring soil moisture, temperature, humidity, light intensity, and CO₂ concentration, and to actuators including irrigation pumps and ventilation fans. Above this, the Network Layer consists of a data terminal integrating an ESP32 microcontroller unit (MCU), a 4G module, and a local display screen, which aggregates sensor data from the field and uploads it to the cloud via the 4G module, while also supporting on-site status monitoring through the local display. The Cloud Layer is built on the OneNET IoT platform, which provides Equipment Management and a time-series database (TSDB) for device registration and time-series data storage, and relies on a unified Protocol Broker & Command Relay to handle all data and command forwarding. At the top, the Application Layer contains the mobile application (APP), which communicates with the Cloud Layer via HTTP and integrates external APIs—including the DeepSeek API for AI-driven decision support and the Meteorological Bureau API for weather data—to deliver real-time visualization, remote control, and intelligent advisory.

In terms of data and control flow, uplink sensor data originates from the sensor nodes and is transmitted via ZigBee to the data terminal at the Network Layer. The terminal aggregates the data and uploads it through the 4G module to the Cloud Layer using MQTT, where the OneNET platform stores it in the TSDB and makes it accessible to the Application Layer via HTTP. Downlink control commands follow the reverse path: initiated from the APP at the Application Layer, commands are sent via HTTP to the Cloud Layer, relayed by the Protocol Broker to the 4G module at the Network Layer, and finally forwarded to the target actuator nodes via ZigBee. Additionally, API call-and-response interactions, represented by solid lines without arrows, occur between the Application Layer and the DeepSeek API, as well as between the Cloud Layer and external APIs such as the Meteorological Bureau API, supporting both AI-assisted decision-making and meteorological data integration. This bidirectional flow enables real-time monitoring and remote actuation while mitigating the coverage-bandwidth trade-off inherent in single-technology solutions.

2.1 Hardware Design

The sensor nodes are equipped with commercially available, low-power sensors capable of measuring key agronomic parameters. Table 1 lists the specifications of the integrated sensors from JXCT. These sensors were selected for their compatibility with the RS485/Modbus interface, which enables standardized connection to the universal sensor PCB. The soil temperature accuracy of ±0.5°C and soil moisture accuracy of ±5% meet the requirements for precision agricultural monitoring [5,6].

With the sensor components selected, the hardware design focuses on three dedicated PCB boards. As shown in Figure 2, Figure 3 and Figure 4, the Data Terminal PCB serves as the system gateway; the Universal Sensor PCB standardizes RS485/Modbus sensor connections; and the Execution Module PCB controls irrigation and ventilation actuators.

The data terminal PCB (Figure 2) serves as the system gateway. It is designed to handle unstable power supplies common in farmland by incorporating a wide-voltage input (9–24 V DC). Level-shifting circuitry ensures reliable Universal Asynchronous Receiver-Transmitter (UART) communication between the ESP32, ZigBee coordinator, and 4G module. The gateway aggregates data from all sensor nodes and uploads it to the cloud via a 4G LTE (Long Term Evolution) Category 1 (Cat.1) module using the Message Queuing Telemetry Transport (MQTT) protocol.

The ZigBee module (Ebyte E34-2G4D20D) was selected for its suitability for field environments. Its 2000 m communication range in open areas provides adequate coverage for the 200 m² test plot and allows for future scalability. The full-duplex capability supports simultaneous data transmission and reception, which is essential for real-time monitoring and control applications.

Table 2 presents the specifications of the selected 4G module (Tastek TAS-LTE-4G[E27V]). The LTE Cat.1 standard provides sufficient communication bandwidth for multi-node agricultural data transmission, while the wide operating voltage range improves compatibility with variable field power conditions.

The Universal Sensor PCB (Figure 3), which forms the core of the hardware standardization strategy, is designed to standardize the connection of RS485 sensors using the Modbus protocol. Its circuitry provides stable power regulation and isolates analog/digital signal domains to minimize noise. On each node, an ESP32 handles the complete data acquisition process: sending Modbus commands, receiving responses, CRC validation, physical unit conversion, and JSON formatting. This edge-processing approach ensures that only structured and validated data enters the network, regardless of the sensor model or manufacturer.

Complementing the sensing infrastructure, the execution module PCB (Figure 4) is designed to control actuators such as water pumps and ventilation fans. It features an optocoupler-isolated relay driver circuit that electrically isolates the low-voltage control side from the high-voltage actuator side, protecting the microcontroller. The output interface uses screw terminals, allowing flexible connection of different AC (Alternating Current) and DC (Direct Current) loads under various agricultural deployment scenarios.

2.2 Network Configuration

While the individual PCBs provide the hardware foundation, the uneven cellular coverage typical of agricultural fields renders single-technology communication solutions unreliable, a limitation that system integration must address. To overcome this, a hybrid ZigBee and 4G networking scheme is implemented. The design combines local mesh networking for field-level coverage with cellular backhaul for cloud connectivity.

Within this architecture, ZigBee forms a local mesh network among sensor nodes, providing low-power, self-healing communication within the field. Each node relays data to the gateway, extending coverage without additional infrastructure. The gateway then uses 4G Cat.1 to upload aggregated data to the cloud. This bidirectional data and control flow—uplink sensor data from the perception layer to the application layer, and downlink commands in reverse—enables real-time monitoring and remote actuation. This configuration mitigates the coverage-bandwidth trade-off inherent in single-technology solutions.

2.3 Software Implementation

With the hardware and network layers established, the software architecture is designed to operationalize two principles: (1) processing data at the edge to maintain data standardization, and (2) leveraging cloud-based LLM APIs integrated with an agricultural knowledge base and other dynamic real-time data to deliver AI capabilities without local model deployment. To realize these principles systematically, the software part of the system adopts a three-tier architecture consisting of the edge computing tier (sensor nodes and data terminal), the cloud & AI tier (cloud platform with integrated knowledge base and LLM), and the user interaction tier (mobile application). Figure 5 illustrates the overall system software architecture and data flow across these three tiers.

While Figure 1 depicts the physical network topology, Figure 5 focuses on software-level modular composition and data interaction. Environmental data collected by sensors undergoes edge preprocessing (CRC validation, unit conversion, and JSON formatting), then is transmitted via the Wireless Communication Manager to the Edge Aggregator & Gateway Service, which uploads aggregated data to the cloud tier and simultaneously presents real-time information on the Edge Visualization Panel for on-site monitoring. At the cloud tier, the OneNET platform serves as the core data hub, hosting the HTTP Broker & Command Relay, MQTT Broker & Command Relay, Device Registry & Connectivity module, and Time-series Database, with the Agricultural Knowledge Base, Meteorological Bureau API, and DeepSeek LLM API integrated as independent external modules. Data then flows to the user interaction tier, where the Device Data Access Control Center fetches and displays real-time sensor data, while the Human-AI Interaction Module constructs composite prompts from user queries, sensor data, and knowledge base content for submission to the DeepSeek LLM API. Control commands are dispatched from the Device Data Access Control Center via the cloud tier, or issued locally from the Edge Visualization Panel, and routed to the Actuator Command Executor to activate devices such as irrigation pumps and ventilation fans. The three tiers are described in detail in Section 2.3.1, Section 2.3.2 and Section 2.3.3.

2.3.1 Edge Computing Tier: Data Acquisition and Edge Aggregation

As the foundational layer of the software architecture, the edge computing tier handles real-time data acquisition, standardization, and local aggregation at the point of sensing. This tier operates independently of cloud connectivity, ensuring system reliability under intermittent network conditions.

On each sensor node, firmware performs scheduled data acquisition tasks in sequence: Modbus command transmission, response reception, CRC validation, unit conversion, and JSON formatting. This on-node processing ensures that all data entering the network is already standardized, regardless of sensor manufacturer or model differences. Standardized packets are then transmitted via ZigBee to the data terminal at configurable intervals (default: 30-second reporting period).

The data terminal serves as the edge gateway, aggregating standardized JSON packets from all sensor nodes via the ZigBee mesh network. Upon reception, it performs two primary functions: (1) local display: presenting real-time information on an on-site screen without requiring external devices, enabling field operators to monitor system health and data flow at a glance; (2) cloud synchronization: uploading aggregated data to the OneNET cloud platform via 4G/MQTT protocol at scheduled intervals. The data terminal maintains a real-time buffer capability to handle transient network interruptions, with retry logic for failed transmissions (retransmission threshold: 3 attempts over 60 seconds). Figure 6 shows the on-site data terminal display during field deployment.

The screen presents real-time information including current sensor readings for each node (soil temperature, soil moisture, CO₂ concentration, humidity, light intensity), network status indicators (ZigBee signal strength — received signal strength indicator (RSSI) — for each connected node, 4G connection status, and cloud connectivity), system timestamp and uptime, and data transmission logs showing recent uplink packets and acknowledgments. This display allows field operators to monitor system health and manage devices without requiring a separate computer or mobile device.

2.3.2. Cloud & AI Tier: Knowledge Base and LLM Integration

Intelligent Decision Support at Cloud Tier: We leverage both structured agricultural knowledge and large language model capabilities as a backend service that does not interact directly with users.

Large Language Model Selection. We chose DeepSeek as our underlying large language model due to its comprehensive advantages in terms of cost efficiency, performance within the agricultural domain, and knowledge integration. It costs less than main-stream commercial models by an order of magnitude, which addresses the high cost barrier limiting AI adoption among smallholders [19,20,21]. In the Agri Eval agricultural benchmark spanning seven disciplines, DeepSeek R1 reached a top tier accuracy of 75.49% comparable to leading international models; independent studies verify its superior agricultural knowledge coverage—screening 4.8–49.7× larger literature corpora compared to ChatGPT—as well as its closest match to standard agronomic practices in sowing, nutrient, and irrigation advisory. Combined with proven adaptability in various agricultural deployments, these features make it ideal for leveraging real time sensor data alongside curated agronomic knowledge to deliver context aware recommendations.

Agricultural Knowledge Base Construction. Based on the standardized data streams from the edge, we implement intelligent decision support using a combination of structured agricultural knowledge and large language model capabilities at the cloud & AI tier. Grounded in verified agronomic knowledge, we structure the agricultural knowledge base into three functional categories specifically designed for the monitored crop environment. First, crop cultivation guidelines contain information about the optimal range of growth parameters for the targeted crops, specifying recommended soil temperature, soil moisture thresholds, and air temperature and humidity ranges throughout different growth stages. Second, environmental alert rules map threshold based conditions to actions, e.g., trigger irrigation if soil moisture drops below a specified lower bound, activate ventilation if air temperature exceeds the upper limit etc.. Third, agronomic advisory content contains short, plain language advice regarding fertilization schedules, pest and disease prevention indicators, and seasonal management practices pertinent to the deployment context. Compiled from official crop cultivation standards, public agricultural extension manuals, and published findings in precision agriculture and soil–plant–atmosphere interactions, this knowledge base is cross validated against regional agronomic recommendations, and implemented as a lightweight system prompt appended to every API request to the DeepSeek LLM, grounding the model's responses in domain specific agronomic knowledge without the infrastructure overhead of a dedicated retrieval augmented generation (RAG) system.

Dynamic Data Integration and Prompt Construction. Beyond this static knowledge foundation, the system dynamically incorporates real-time sensor data and weather data into the decision-making process. The OneNET cloud platform serves as the data hub, storing all sensor data collected from the edge tier, managing device registrations and connectivity states, and providing APIs for data access and remote-control commands. Historical data is stored in a time-series database to enable trend analysis and long-term monitoring. In parallel, real-time weather data is obtained from the Meteorological Bureau API as an independent external service. When a request arrives from the application layer, the cloud tier constructs a composite prompt consisting of: (1) the knowledge base system prompt containing cultivation guidelines and alert thresholds, (2) current real-time sensor readings fetched from the cloud database, (3) real-time weather data from the Meteorological Bureau API, and (4) the user's query text. For example, a typical composite prompt might look like: "System: You are an agricultural advisor for perilla. Use the following thresholds: soil moisture 60-80%, soil temperature 20-25°C. Real-time sensor data: Soil moisture = 55%, soil temperature = 24°C. Weather data: Current temperature = 32°C, no rain forecast. User query: 'Does my perilla need watering right now?'" This concatenated input is then submitted to the DeepSeek API. The returned response is sent back to the application layer for presentation. This combination of static agronomic knowledge and dynamic sensor data represents a key advantage over existing agricultural Q&A systems that rely solely on static knowledge bases.

2.3.3. User Interaction Tier: Mobile Application

Serving as the primary interface between the farmer and the intelligent system, the user interaction tier is implemented through a mobile application that enables both manual control and AI-assisted decision support. The mobile application is divided into two complementary functional parts: Device Data Access Control and AI Interaction.

Device Data Access Control allows farmers to view real-time sensor data updated from the cloud platform and manually dispatch control commands to actuators. This mode provides direct access to current environmental parameters and enables emergency manual intervention when needed.

AI Interaction implements the natural language-based decision support workflow. As illustrated in Figure 7, the user inputs a question in natural language through the mobile application interface. The application sends the query to the cloud tier, where the composite prompt described in Section 2.3.2 is constructed and the DeepSeek LLM API is called. The returned response is parsed and presented in a conversational format.

Figure 7 shows a representative interaction captured during field deployment. Upon receiving the user's natural language query, the system retrieved the current real-time sensor readings from the OneNET cloud platform and injected them into the composite prompt alongside the knowledge base thresholds. The DeepSeek API returned a two-part response. The first part provides a parameter-by-parameter assessment, in which each sensor value is explicitly compared against its corresponding optimal range and assigned a status indicator. For parameters flagged as Critical or Alert, the response further provides specific, actionable recommendations. The second part consolidates all assessments into a structured summary table, listing each parameter's current value, optimal range, status, and recommended action, enabling the user to quickly identify critical issues without reading through the full narrative response.

The interface shows a complete interaction with parameter-by-parameter environmental assessment and a consolidated summary table. The response explicitly references real-time sensor values against knowledge base thresholds, assigns status indicators, and provides actionable recommendations. This interaction demonstrates the system's capability to deliver actionable, data-grounded agricultural guidance through natural language interaction. By treating AI as a cloud-accessible service rather than an in-house system component requiring local deployment, the system addresses the usability barriers identified in previous studies and enables ordinary farmers to obtain agricultural guidance through natural language queries without requiring specialized machine learning expertise.

Upon user confirmation of an AI-generated suggestion, or when a manual command is issued directly, a control command is triggered. Commands are sent from the mobile application to the cloud platform. The data terminal receives commands from the cloud, parses and routes instructions via ZigBee to target actuator nodes, which activate relays to perform actions (e.g., irrigation, ventilation). The entire system operates in a closed loop: data acquisition – transmission – cloud upload – user interaction (manual or AI-assisted) – command execution – data acquisition, enabling real-time monitoring and remote control of agricultural environments. To further enhance system accessibility and lower adoption barriers, the mobile application incorporates multi-language support to address one of the major adoption barriers identified in [19]—linguistic diversity. The mobile application and data terminal interface support multiple languages, including Chinese and English, allowing farmers and agricultural technicians to interact with the system in their preferred language. Language selection defaults to automatic switching based on device location, while users can also configure it during initial setup or adjust it in real-time through the settings menu. This localization capability is achieved through a resource-based internationalization framework, where all user-facing text strings are stored in external language files and dynamically loaded based on user preference.

3. Experimental Verification

Herein, we present the experimental validation of the proposed Agri Synergy IoT system and discuss its performance based on field tests, including a comparative analysis with existing systems. For evaluating the system under real field conditions, we select a 200 m² experimental farmland plot located in Yongmei Village, Lianshan County, Guangdong Province (Figure 8), which has a mid subtropical monsoon climate characterized by an annual average temperature of 18.9°C, annual rainfall of 1753 mm, and relative humidity of 82%.We conduct the field trial in mid to late July, corresponding to the vegetative growth stage of perilla-a critical period where environmental conditions have direct impact on biomass accumulation and subsequently yield formation. July in this region is characterized by high temperatures (daily maximums frequently exceeding 33°C), high relative humidity (above 80%), and intermittent afternoon thundershowers. Although the weather was generally stable during the test period with no extreme events, these conditions represent the common and challenging environment for agricultural monitoring in this area. The deployment allowed comprehensive testing of data acquisition, network communication, and control functionality under typical summer stressors.

The system was deployed with five sensor nodes and two actuator nodes. Sensor nodes were configured to measure soil parameters—including moisture, temperature, pH, and nitrogen, phosphorus, and potassium (NPK) content—as well as air temperature, humidity, light intensity and CO₂ concentration. Actuator nodes were connected to irrigation and ventilation control devices to enable remote management.

Functional tests verified data acquisition accuracy (based on sensor specifications in Table 1), ZigBee and 4G connectivity, and remote-control functionality via the mobile application. Performance analysis compared single-node and multi-node transmission latency. Testing revealed that concurrent transmissions from multiple nodes caused packet collisions in the ZigBee network, increasing latency and introducing packet loss.

3.1 Data Acquisition Accuracy

Sensor nodes successfully acquired and transmitted environmental data throughout the test period. All sensor readings remained within the manufacturer-specified accuracy ranges listed in Table 1, confirming that the standardized interface PCB and edge processing maintained data integrity throughout the acquisition and transmission chain, without introducing data corruption or transmission errors. Data transmission was continuous, with each node reporting at 30-second intervals. A total of approximately 2,400 data points were collected across all nodes during the test period.

3.2 Network Connectivity and Stability

The ZigBee network maintained connectivity among all five sensor nodes throughout the test period. Signal strength indicators remained stable, with RSSI values ranging from –65 dBm to –72 dBm for nodes at varying distances from the gateway. The 4G Cat.1 module maintained continuous connection to the OneNET cloud platform with no disconnections recorded. Data upload to the cloud occurred within 1-2 seconds of reception at the gateway under normal conditions, demonstrating adequate bandwidth for real-time monitoring.

3.3 Remote Control Reliability

Twenty remote control commands were sent via the mobile application to the two actuator nodes. All commands were successfully executed, achieving a 100% success rate under the test conditions. Actuation occurred within 4–6 s of command initiation, verifying the functionality of the bidirectional communication path (mobile app – cloud – gateway – ZigBee – actuator node).

3.4 Performance Analysis

With the system's basic functionality verified, the analysis proceeded to examine network performance under varying load conditions. A key observation was the difference in latency between single-node and multi-node scenarios. Table 3 summarizes the measured performance parameters.

Multi-node concurrent transmission increased latency to 200-500 ms due to packet collisions at the ZigBee coordinator, triggering retransmissions. Overall packet loss remained below 0.5%, which is acceptable for non-real-time monitoring but potentially limiting for time-sensitive applications. Previous studies have demonstrated that optimizing wireless sensor network deployment strategies and communication scheduling mechanisms can improve network coverage efficiency and extend operational lifetime by dynamically adjusting node activity states [22]. These findings indicate that further optimization at the communication protocol level may provide additional improvements in scalability when extending the proposed system to larger agricultural areas.

Table 4 presents ZigBee communication quality at different distances, measured by transmitting 500 packets at each distance point.

Signal strength degrades predictably with distance; packet loss becomes noticeable beyond 300 m. In the current 200 m² deployment, all nodes were within 200 m of the gateway, ensuring reliable communication. For larger-scale deployments, the ZigBee mesh topology supports multi-hop relay to extend coverage, and the addition of dedicated relay nodes can further maintain link quality at greater distances.

Table 5 quantifies the impact of network congestion by presenting multi-node concurrent transmission performance under varying node counts. This data was obtained by synchronizing all active nodes to transmit at the same moment and logging the resulting latency and packet loss at the gateway. Each test run consisted of 100 transmission cycles.

The results presented in Table 5 demonstrate that increasing the number of simultaneously transmitting nodes resulted in a gradual increase in communication latency and packet loss. This behavior is consistent with the characteristics of contention-based wireless communication protocols, where multiple devices compete for access to the same wireless channel. For the current five-node agricultural deployment, the measured average latency of 245 ms and packet loss rate of 0.3% remained within acceptable ranges for environmental monitoring and remote agricultural control applications. However, the performance degradation observed when increasing the number of nodes to 8–10 indicates that additional communication optimization strategies may be required for larger-scale deployments.

Taking into account the shortcomings of the existing CSMA/CA-based ZigBee communication mechanism, we envision expanding our system by including MAC-layer optimization methods like time division multiple access (TDMA) to minimize channel contention and enhance network scalability. Prior research has demonstrated how adaptive scheduling strategies can significantly improve the efficiency of wireless sensor networks in an agricultural environment [23].

3.5 AI Decision Support Evaluation

The AI assisted decision support functionality was tested using a structured testing protocol. We developed a set of 20 typical agricultural queries which covered four main types: irrigation advice (e.g., "Does my perilla need watering right now?"), environmental assessment (e.g., "Are the current conditions suitable for perilla growth?"), pest and disease inquiries (e.g., "The leaves are turning yellow, what could be the cause?") and fertilization guidance (e.g., "When should I apply fertilizer at this stage?). Each query was issued three times during different times of day (morning, midday, and evening, corresponding to differing sensor readings), resulting in 60 test interactions overall.

Responses were evaluated against two quantitative criteria: (1) Factual Accuracy — whether the response contained agronomically correct information, verified against the agricultural knowledge base and published cultivation guidelines; and (2) Contextual Relevance — whether the response explicitly referenced real-time sensor values and adapted recommendations accordingly. All criteria were independently evaluated by two reviewers, with disagreements resolved through discussion. To further validate the necessity of dynamic data integration, an ablation test was conducted: the same 20 queries were re-submitted with the real-time sensor data component removed from the prompt, and contextual relevance was re-evaluated under this condition. The results are summarized in Table 6.

Footnote: "Contextual Relevance" is defined as whether the response provides quantitative, situation-specific comparisons (e.g., "Current soil moisture is 55%, below the 60% threshold") and personalized actionable recommendations derived therefrom (e.g., "Turn on irrigation for 10 minutes"). Generic agronomic heuristics (e.g., "Irrigate when soil moisture is low") do not satisfy this criterion.

Among the 60 interactions, 58 yielded factually accurate responses; the two errors involved outdated pest control recommendations, which were subsequently corrected through knowledge base refinement. Contextual relevance was confirmed across all 60 interactions: every response incorporated current sensor readings, and the response content varied across the three time points in accordance with changing sensor values—for instance, correctly determining that morning readings indicated no immediate need for irrigation, while late afternoon conditions triggered an irrigation recommendation after a full day of transpiration. In the ablation test, removing real-time sensor data from the prompt caused responses to become generic (e.g., "Irrigation is recommended when soil moisture is low"), and the contextual relevance rate dropped from 100% to 0%. This result quantitatively confirms that dynamic sensor data integration is not merely an enhancement but a necessity for actionable decision support—a distinction that has been largely overlooked in prior agricultural chatbot studies.

To assess the accessibility and practical usability of the AI interaction paradigm – complementing the decision quality assessment above – a structured usability test was performed involving 30 farmers recruited from Yongmei Village and its surrounding area in Lianshan Zhuang and Yao Autonomous County. Due to the rural and mountainous nature of the region, there was skew towards older age groups and lower education levels among the participants ranging in age between 32 and 68 years old; their education level spans primary school or below (9 participants), junior/senior high school (15 participants), and college or above (6 participants); none of them had any previous experience working with AI systems, and most only had minimal experience using smartphone based applications other than basic communication and social media.

The test procedure comprised three phases. First, a brief training session (approximately 10 minutes) demonstrated how to view sensor data, interact with the AI assistant through natural language queries, and issue manual control commands via the mobile application. Second, participants completed three predefined tasks within a 20-minute free-use session: (1) checking the current soil moisture reading; (2) asking the AI assistant "Does my perilla need watering right now?" and executing a suggested irrigation command if recommended; and (3) remotely turning off the irrigation pump via the application after task 2. Third, each participant completed the System Usability Scale (SUS) questionnaire and a supplementary satisfaction survey (5 items on a 1–5 Likert scale). Task completion time, the need for external assistance, and AI suggestion adoption rate were recorded throughout.

The results are summarized as follows. The mean SUS score was 78.4 ± 9.5 (SD), corresponding to a "good" rating on the standardized SUS interpretation scale (scores of 70–80). Twenty-seven of 30 participants (90.0%) completed all three tasks without external assistance; the remaining three participants required guidance on navigating the mobile application interface, all of whom were aged 60 or above with primary school education. Among the 25 participants who received AI-generated irrigation recommendations during their test sessions (five were excluded because their soil moisture readings were already within the optimal range, rendering the irrigation advisory inapplicable), 21 followed the AI suggestion, yielding an 84.0% adoption rate. The mean satisfaction score was 4.0 ± 0.8 out of 5.

These findings indicate that the API based interaction paradigm is accessible to farmers of all ages, educational levels, and technical backgrounds—including those who lack prior digital experience in resource constrained rural settings—as the vast majority of participants were able to complete the assigned tasks without prior expertise or extensive digital skills. Further interface simplifications–enhanced voice based interaction or larger touch targets--will likely benefit the most vulnerable user groups.

3.6 Discussion

The results illuminate the comparative advantages of the proposed approach over existing alternatives. At the hardware level, field validation confirmed that the standardized interface PCB and on-node edge processing maintained data integrity throughout the acquisition and transmission chain, with all sensor readings remaining within manufacturer-specified accuracy ranges and the hybrid ZigBee/4G network sustaining stable connectivity throughout the test period. This source-level standardization fundamentally differs from the connector-based translation approach proposed by Roccatello et al. [13], which still operates at the data formatting stage. At the software level, existing agricultural Q&A systems typically rely on static knowledge bases that provide generic, decontextualized advice. The controlled experiment in Section 3.5 empirically demonstrates this limitation: when real-time sensor data was removed from the prompt, the contextual relevance rate dropped from 100% to 0%. This finding quantitatively confirms that dynamic sensor data integration is not merely an enhancement but a necessity for actionable decision support—a distinction that has been largely overlooked in prior agricultural chatbot studies [14,15].

Table 7 compares the proposed system with commercial IoT platforms based on market research and literature.

Footnote: Commercial A and B refer to specific commercial IoT platforms from Shaoxing Tianjieyun Intelligent Technology Co., Ltd. and Yantai Lanxian Electronic Technology Co., Ltd., respectively. Commercial platform cost data are from the authors' market survey (May 2026) of official manufacturer websites.

Compared to commercial IoT platforms, the proposed system offers comparable sensing accuracy at a 3–7× lower hardware cost and 10× lower single-node latency, while additionally providing AI-driven natural language interaction that commercial platforms typically lack. The per-node hardware cost of the proposed system is approximately 41 to 46 US dollars, with the cost breakdown as follows: 20 to 30 dollars for the multi-parameter sensors (soil moisture, temperature, and electrical conductivity probes), approximately 7 dollars for the custom-designed universal sensor PCB (with integrated power supply circuitry), 3 dollars for the ESP32 MCU, 4 dollars for the ZigBee communication module, and 2 dollars for the waterproof enclosure and mounting accessories. This cost-performance advantage, combined with the source-level data standardization and dynamic AI decision support discussed above, positions Agri-Synergy as a practical alternative for resource-constrained agricultural settings.

The multi-node communication experiments further revealed the influence of network congestion on system scalability. When the number of simultaneously transmitting nodes increased, both communication latency and packet loss showed an increasing trend. Specifically, the latency increased from below 100 ms under single-node transmission to 200–500 ms during multi-node communication, while the packet loss rate increased to approximately 0.5% when five sensor nodes transmitted simultaneously (Table 3, Table 4 and Table 5).

This performance degradation is mainly related to the CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) mechanism adopted by ZigBee communication. Under concurrent transmission conditions, multiple sensor nodes compete for access to the shared wireless channel. This competition increases the probability of packet collisions and retransmission requirements, resulting in additional communication delays. Similar scalability issues have also been reported in agricultural IoT applications, where increasing numbers of connected devices introduce additional communication overhead and may affect network performance [24,25]. For the current experimental deployment consisting of five sensor nodes, the measured communication performance remained within acceptable limits for environmental monitoring and agricultural control applications. However, the observed performance reduction when expanding the number of nodes indicates that further optimization may be required for large-scale agricultural deployment.

Considering that the current limitation mainly originates from the communication scheduling mechanism rather than hardware capability, a TDMA (Time Division Multiple Access)-based scheduling strategy is proposed for future system expansion. In this approach, the ZigBee coordinator assigns dedicated transmission periods to individual sensor nodes, thereby reducing competition for channel access and improving communication stability. The frame length can be expressed as:

$$T_{\mathrm{frame}}={\sum }_{i=1}^n(T_{\mathrm{slot}}+T_{\mathrm{guard}})$$

(1)

where $n$ is the number of nodes, $T_{\mathrm{slot}}$ is the transmission duration per node (including data packet and acknowledgment), and $T_{\mathrm{guard}}$ is a guard interval to accommodate clock drift.

For the current deployment with 5 nodes, assuming a 50-byte data packet transmitted at 250 kbps, $T_{\mathrm{slot}}\approx 2.5$ ms. With a guard interval $T_{\mathrm{guard}}=1$ ms, the total frame length $T_{\mathrm{frame}}=5\times \left(2.5+1\right)=17.5$ ms, which would reduce the worst-case latency from the current 245 ms (CSMA/CA) to under 20 ms under TDMA scheduling. This optimization can be implemented through firmware modification without changing the existing hardware structure. Previous studies have reported that MAC-layer optimization strategies can improve communication efficiency in agricultural wireless sensor networks [23,24,25]. Therefore, the communication characteristics observed in this study provide a basis for further investigating TDMA-based scheduling approaches in future large-scale deployments.

Notwithstanding these demonstrated capabilities, several limitations constrain the generalizability of the current findings. First, the field test was conducted in the subtropical monsoon climate of Guangdong Province, where mild temperatures and abundant rainfall favor system operation; performance under extreme conditions such as arid heat, high-altitude cold, or heavy snowfall remains untested. Second, the validation covered a 200 m² plot with only five sensor nodes, and signal degradation beyond 300 m (Table 4) indicates that larger-scale or spatially dispersed deployments would require careful node placement or additional relay infrastructure. Third, the electromagnetic environment at the test site was relatively clean; performance in settings with competing 2.4 GHz signals—such as Wi-Fi networks or co-located ZigBee systems—requires further investigation. Fourth, the field trial was conducted over a limited duration in mid-to-late July, covering only the vegetative growth stage of perilla. The system's performance across the full growth cycle remains to be validated. We acknowledge this limitation and plan to conduct extended trials spanning the complete growth cycle in future work.

An unanticipated observation from the field deployment was that the local display on the data terminal proved particularly valuable for on-site troubleshooting during initial setup. This observation was particularly evident when an intermittent 4G disconnection lasting several minutes occurred during the trial: throughout the interruption, the data terminal continued to receive and buffer sensor data via the ZigBee mesh network, while the local display maintained real-time presentation of all sensor readings and network status indicators. Upon 4G restoration, the buffered data was automatically uploaded to the cloud using the built-in retry mechanism (retransmission threshold: 3 attempts over 60 seconds, as described in Section 2.3.1), with no data loss recorded at the cloud database. This experience suggests that edge-side visualization, combined with the terminal's local caching and retransmission capabilities, provides a critical operational fallback under weak or disconnected network conditions, and warrants further exploration as a complementary interaction modality alongside the mobile application.

4. Conclusion

This paper presented Agri-Synergy, a hybrid IoT system that addresses two persistent challenges in smart agriculture—sensor data heterogeneity and the barriers to effective AI-driven decision support—through a hardware-software co-design approach.

Field validation demonstrated that the hardware–firmware co-designed edge processing methodology effectively eliminated data heterogeneity at the source: all sensor readings remained within manufacturer-specified accuracy ranges throughout the test period, and the hybrid ZigBee/4G network achieved single-node latency under 100 ms—a 10× improvement over traditional General Packet Radio Service (GPRS)-based systems [22]—with multi-node concurrent transmission packet loss below 0.5%. At the software level, the low-cost AI interaction paradigm enabled context-aware decision support without local model deployment: the DeepSeek LLM API integration achieved a 100% context-relevant response rate in structured evaluation with 20 agricultural queries, and a structured usability test with 30 local farmers confirmed that all participants obtained actionable guidance without prior machine learning expertise. The system achieves a 3–7× hardware cost reduction compared to commercial IoT platforms (detailed in Section 3.6), while additionally providing AI-driven natural language interaction that commercial alternatives typically lack.

In summary, the contribution of this work is twofold and mutually reinforcing: at the hardware–firmware layer, the universal sensor PCB with RS485/Modbus interface and on-node edge processing eliminates data heterogeneity at the source; at the software layer, the DeepSeek API-based AI interaction paradigm democratizes access to data-driven agricultural guidance. Together, these two innovations address the root causes—rather than the symptoms—of the two persistent challenges in smart agriculture adoption.

Future work will proceed along four directions: (1) geographically extended deployments across diverse climatic zones to evaluate robustness beyond the subtropical monsoon environment; (2) implementation and validation of the proposed TDMA-based MAC protocol in larger-scale networks (e.g., 10–20 nodes across multiple adjacent smallholder plots); (3) investigation of 2.4 GHz interference effects in electromagnetically congested environments through controlled experiments; and (4) extended-duration field trials covering the full growth cycle of target crops to evaluate long-term system robustness, sensor calibration stability, and network performance under evolving field conditions.