FarmSync: Ecosystem for Environmental Monitoring of Barns in Agribusiness

Abstract

In the current era of agricultural management practices, known as agricultural 5.0, optimal indoor environments are associated with comfortable temperatures, regulated humidity, and good air quality—essential variables to improve yields. Given this scenario, there is a need for innovative ecosystems that automate indoor environmental monitoring in an affordable and scalable way. This paper presents the scope of the development and validation of an IoT-based ecosystem designed to monitor and control environmental conditions in agricultural barns. The objective is to present a cost-effective and easily accessible environmental monitoring system for barn buildings and agricultural storage areas, promoting the welfare of animals, humans, and crops, and contributing to the sustainable development of the agricultural industry. The system integrates wireless sensors, predictive algorithms, a web interface and cloud infrastructure to optimize temperature and humidity. A proof-of-concept assessment was performed to determine whether the modular architecture offers scalability, while the responsive web interface ensures cross-device accessibility. The results show data accuracy above 95%, prediction efficiency of 96%, and increases in production yields. This solution demonstrates economic and operational advantages over existing technologies, promoting sustainability and automation in agricultural management practices in hangars and barns, in alignment with the United Nations’ Sustainable Development Goals (SDGs).

1. Introduction

In the current phase of agricultural management, known as agricultural 4.0, the integration of Industry 4.0 technologies, such as the Internet of Things (IoT), data analysis, and automation, is revolutionizing agribusiness by increasing efficiency and precision in environmental management [1,2,3]. These innovations enable smarter resource utilization and higher yields across various agricultural operations [4,5,6,7,8]. IoT systems are particularly impactful in livestock management, where they monitor and control environmental conditions to reduce disease risks and enhance animal welfare, thereby boosting productivity [4]. Smart agricultural facilities, such as poultry houses, dairy barns and greenhouses, integrate IoT with machine learning, blockchain, and edge-to-cloud computing architectures to improve system dependability and maintain optimal conditions for both animals and crops [9,10,11,12]. Validated IoT frameworks in real livestock farms have shown strong effectiveness in monitoring temperature and humidity—key variables for maintaining animal welfare—while also enabling the detection of harmful gas concentrations such as ammonia [13].

Similarly, also in crop production, IoT facilitates precise irrigation and fertilization, aligning resources with crop needs to maximize yields [2].

The application of IoT throughout the life cycle of agricultural products, as proposed in a green IoT framework, enhances sustainability and productivity across diverse farming practices [14]. Furthermore, wireless technologies optimize storage conditions by monitoring, for example, temperature, humidity, and gas levels, preserving crop quality and minimizing waste [15,16,17]. Advancements in IoT systems allow for monitoring environmental conditions, providing data-driven insights to mitigate the risks associated with agricultural practices and paving the way for emerging technologies such as Digital Twins, which create virtual replicas of physical farming environments [18,19].

However, the effectiveness of these systems relies not only on data collection but also on intuitive user experience (UX) and user interface (UI) designs that enable farmers and stakeholders to visualize information clearly, interpret trends, and make informed decisions [13,20]. In this context, optimal indoor environments or confinement buildings—associated with comfortable temperatures, regulated humidity, and good air quality, which are essential for improving yields—present intrinsic challenges to the implementation of affordable and scalable environmental monitoring systems. These include complexity, data processing, portability, sensor integration, calibration, power requirements, limited accessibility, and maintenance costs [21]. Although the literature reports progress in monitoring environmental parameters such as temperature, humidity, and animal behavior, many implementations remain limited in automation, scalability, and energy efficiency, highlighting the need for more integrated and sustainable smart farming solutions [22].

In West Africa, for instance, agricultural production faces numerous challenges, including inadequate environmental control and underdeveloped infrastructure—all of which hinder productivity and sustainability. A review focused on Senegal identified structural and climatic constraints as major barriers to improving performance in both crop and livestock systems, particularly in extensive and agropastoral contexts [23]. These findings emphasize the need for accessible, adaptable, and low-cost technological solutions capable of supporting agricultural producers across diverse regions and operational scales.

To address this problem, this study presents FarmSync, an IoT-based ecosystem designed to monitor and control environmental condition parameters, starting with the microclimatic variables of temperature and humidity, in agricultural barns. The objective and innovation are to demonstrate that it is possible to implement a cost-effective and easily accessible environmental monitoring system for barn buildings—one that promotes crops, animal and human welfare while contributing to the sustainable development of the agricultural industry. Designed for flexibility, FarmSync allows integration with any hardware, provided it can communicate with Application Programming Interfaces (APIs) using Hypertext Transfer Protocol (HTTP) requests. By leveraging cloud infrastructure, predictive algorithms, and automated actuators, the system is built to optimize energy consumption and maintain ideal environmental conditions as microclimatic variables evolve. In addition, a web-based user interface enables data visualization, reporting, and the direct control of actuators.

FarmSync addresses the need for sustainable agricultural practices, aligning with ESG principles and the United Nations’ SDGs, such as Zero Hunger, Climate Action, and Responsible Consumption [24]. By bridging gaps in barn management systems, the proposed IoT-driven ecosystem uses science to develop energy efficiency, democratize technology, and empower small- and medium-scale farmers.

The primary aim of this research work is to investigate the feasibility of an IoT-based ecosystem for environmental monitoring and predictive control designed for agricultural barns. Specifically, the study aims at the following:

• Evaluate the effectiveness of low-cost sensor networks in accurately monitoring key environmental parameters, such as temperature and humidity, in confined agricultural environments.
• Develop and validate predictive machine learning models capable of forecasting microclimatic conditions based on sensor and external weather data.
• Assess the ability of predictive control strategies to automate actuator responses, maintaining optimal environmental states in barns.
• Analyze the scalability and reliability of a cloud-based infrastructure designed to store, process, and manage environmental data, supporting system expansion to multiple barns and agricultural facilities.
• Develop and validate a user-centric web interface that enables monitoring, historical data analysis, and the manual or automated control of environmental actuators.
• Quantify system performance metrics, targeting a data collection accuracy of at least 95% and a predictive algorithm efficiency of at least 80%. These targets are supported by previous studies demonstrating sensor data accuracy above 90% in agricultural settings [25] and machine learning prediction accuracies exceeding 80% for temperature and humidity forecasting [26].

2. Related Works

The development of this research work is grounded in prior research that applied IoT and machine learning technologies to environmental control systems in agribusiness settings:

• Wicaksono et al. (2017): Developed an automatic temperature control system for broiler poultry farms using a wireless sensor network, integrating Arduino Nano, DHT11 sensors, and Xbee modules for environmental monitoring [27].
• Ribeiro et al. (2019): Applied artificial neural networks to optimize barn conditions and generate action plans to improve poultry growth and welfare [28].
• Alves et al. (2022): Evaluated the costs of implementing IoT platforms in smart farms using a Total Cost of Ownership (TCO) methodology, highlighting their economic viability [29].

While previous works highlight the potential of IoT in agriculture, FarmSync stands out by integrating low-cost hardware, a cloud-based API, data visualization, and predictive machine learning within a unified and modular system. It extends beyond basic control systems by supporting historical data analysis, error logging, and user interaction through a responsive web interface. The ecosystem is designed to manage and monitor multiple barns simultaneously, enabling centralized oversight and decision-making across distributed agricultural environments. Its hardware-agnostic and cloud-compatible design promotes scalability and accessibility, aligning with practical farming needs and the Sustainable Development Goals (SDGs) [24].

3. Material and Methods

FarmSync adopts an integrated approach that combines the Project Management Institute Directrices (PMI) for structured project management with Agile for flexible development of the API and web interface. PMI ensures clear processes for scope, time, cost, and risk management, while Agile allows incremental development, aligning with the gradual accumulation of sensor data needed for predictive algorithm training [30,31]. The predictive algorithms were developed through a systematic process: data collection, cleaning, feature selection, dataset partitioning, model training, and validation. The integration of software engineering principles described by Ian Sommerville, such as incremental delivery and evolutionary design, ensured quality, adaptability, and iterative refinement of the API and interface, allowing for a scalable system [32,33].

3.1. Definition of Requirements, Risks and Limitations

The project requirements are categorized into functional, non-functional, and technical aspects. Functional requirements focus on monitoring environmental conditions with IoT sensors, automating actuators (fans and climate controllers, for example), and provide a web interface for data visualization and report generation. The system must also execute predictive algorithms to adjust conditions based on collected data. Non-functional requirements include scalability, energy efficiency, high usability, and the integration of low-cost technologies to ensure financial feasibility. Technical requirements include IoT sensors, microcontrollers, firmware, communication protocols, a cloud-based API, a database for data storage, and a web interface for management and visualization. Key constraints include implementation costs, energy resource limitations, dependency on internet connectivity, and microcontroller processing capacities.

Table 1. Research work requirements.

Category	Details
Functional Requirements	Monitor ambient conditions. Automate actuators. Web interface for visualization and reports. Execute predictive algorithms.
Non-Functional Requirements	Scalable and energy-efficient. Usable web interface. Low-cost technology.
Technical Requirements	IoT sensors, microcontrollers. Cloud-based API and database. Web interface and actuator integration.

presents a summary of the project requirements.

The system is subject to a range of potential risks that could affect its performance and reliability, particularly in real-world deployments. These risks include connectivity issues in rural environments, energy constraints in off-grid areas, limitations in processing power, and challenges related to scalability and system maintenance. To address these, appropriate treatment strategies are identified—such as mitigation, transfer, or acceptance—and are detailed in

Table 2. Research work risks and mitigation strategies.

Risk	Treatment	Strategy
Internet connectivity failure in rural areas	Mitigate	Implement modular design that allows for local data caching. Evaluate alternative communication protocols such as LoRaWAN or mesh networks.
Limited energy resources in remote installations	Mitigate	Design for ultra-low-power operation, use sleep modes in microcontrollers, and optimize sensor duty cycles. Consider solar or alternative renewable sources.
Cloud infrastructure scalability	Transfer	Delegate infrastructure management to scalable cloud service providers (e.g., AWS and Azure), using features like auto-scaling, serverless functions, and managed databases.
Microcontroller processing limitations	Mitigate	Offload heavy computations to a centralized cloud API. Keep local firmware lightweight with basic decision logic.
Hardware failure (sensors or actuators)	Accept	Recognized as an inherent risk in IoT deployments. Mitigated partially by designing modular components that are easy to replace and maintain.
Sensor data inconsistency or noise	Mitigate	Use validation logic and filters in the cloud API (e.g., moving averages and outlier detection) to clean and normalize data before processing.
Unexpected system downtime	Mitigate	Include watchdog timers and regular heartbeat messages. Develop alerts and logging to detect and recover from failures.
Security breach in communication or cloud storage	Mitigate	Apply HTTPS encryption, token-based authentication, and role-based access control in the cloud. Use secure API gateways.

, along with the proposed actions to minimize their impact.

In addition to potential risks, the current version of the system presents known limitations that emerged during the project concept and design stage. These limitations reflect the current stage of development and highlight areas for future improvement.

Table 3. System limitations and proposed solutions.

Limitation	Proposed Solution/Future Strategy
Limited real-world testing	Broaden testing scope to include operational farm environments. Collect user feedback to identify performance gaps and unexpected challenges.
Scalability concerns with large-scale farms	Implement distributed sensor clusters and evaluate edge computing to reduce central load. Optimize cloud resources for large data streams.
Limited support for fast and automated expansion of the cloud infrastructure	While the current cloud infrastructure supports modular growth, it lacks mechanisms for seamless and automated scaling during rapid system expansion. Future improvements will focus on implementing auto-scaling policies, infrastructure-as-code practices, and deployment pipelines to ensure robust and efficient scaling.
Dependence on stable internet	Develop offline data caching and synchronization capabilities. Evaluate LoRaWAN and mesh network alternatives for remote areas.
Latency in cloud-based control decisions	Add edge-level intelligence for time-sensitive operations like actuator control. Use hybrid decision models (local + cloud).
No native mobile app support	Improve web interface responsiveness for mobile devices. Consider future development of a PWA or native app for better accessibility.
Firmware updates require manual intervention	Develop an over-the-air (OTA) firmware update mechanism to reduce maintenance complexity.
Use of simple initial hardware with limited sensor capabilities	The initial hardware configuration, composed of basic components such as DHT11 sensors and low-power microcontrollers, was intentionally adopted to validate the feasibility of the FarmSync ecosystem in a low-cost and low-complexity setup. Although suitable for early testing, this limits measurement precision and sensor diversity. Future iterations will leverage the modular architecture to integrate more accurate and specialized sensors (e.g., BME280 and ammonia) for broader environmental monitoring.

summarizes these limitations alongside the proposed solutions or future strategies to address them in subsequent phases of the project.

3.2. Hardware Requirements

The hardware requirements for the environmental monitoring system were selected by the objectives and requirements of the system. The hardware must be capable of monitoring microclimatic variables such as temperature and humidity. In addition, the system requires wireless connectivity to facilitate communication with the cloud, enabling the transmission of collected data to an API for processing and storage. The hardware must also support the activation of actuators to automatically adjust microclimatic conditions based on the predictions generated by the system.

3.3. Selection of Hardware Components

Endeavoring to address principles of cost effectiveness, the hardware components were selected primarily to ensure low cost and validate the functionality of the ecosystem, with a focus on testing its core capabilities. The system was designed to be flexible and adaptable and allows for the replacement or upgrade of the entire hardware architecture based on specific project requirements. This structure allows the integration of any hardware capable of supporting API communication via HTTPS REST.

DHT22 Sensor (Adafruit Industries LLC, New York, NY, USA): selected for temperature and humidity monitoring due to its balance between simplicity, affordability, and reliability in environmental sensing, particularly in agricultural contexts [4,34].

A quotation was obtained from two major electronics distributors—Mouser and Digi-Key—indicating unit prices for small quantities ranging from USD 9.59 to USD 9.95, as shown in

Table 4. DHT22 unit price quotation for small quantities (as of 2 April 2025).

Marketplace	Model	Quantity	Unit Price (USD)	Reference
Mouser Electronics (Mansfield, TX, USA)	DHT22	1	USD 9.59	[37]
Digi-Key Electronics (Thief River Falls, MN, USA)	DHT22	1	USD 9.95	[38]

. The cost effectiveness of the DHT22 was a factor in its selection, as the system was designed with affordability and replicability in mind, particularly for small-scale or resource-constrained deployments. Its accessible pricing, combined with adequate accuracy for temperature and humidity monitoring, made the DHT22 a choice for validating the environmental sensing layer of the FarmSync system [35,36].

ESP32: The ESP32 was selected as the core microcontroller due to its integrated Wi-Fi, low energy consumption, and strong support within the IoT development community, making it well suited for transmitting sensor data to the cloud via HTTP requests [4,5].

Cost effectiveness in small-scale deployments was a key factor in its selection. Price quotations were obtained from two distributors, Mouser and Digi-Key, with unit prices ranging from USD 2.50 to USD 4.84 for small quantities as detailed in

Table 5. ESP32 unit price quotation for small quantities (as of 2 April 2025).

Marketplace	Model	Quantity	Unit Price (USD)	Reference
Mouser Electronics	ESP32-WROOM-32E-N4	1	USD 2.50	[39]
Digi-Key Electronics	ESP32-WROOM-32E-N4	1	USD 4.84	[40]

. The combination of affordability and functionality made the ESP32 a choice for validating the feasibility of the FarmSync ecosystem [35,36].

MSP430FR2355 (Texas Instruments, Dallas, Texas, USA): This microcontroller was selected to complement the ESP32 by addressing specific needs for ultra-low power consumption and energy-efficient continuous sensing. While the ESP32 (Espressif Systems, Shanghai, China) is responsible for connectivity and data transmission, the MSP430FR2355 serves as the primary controller for sensor data acquisition, particularly in scenarios where long-term operation under limited power supply is essential. Its ultra-low power modes and architecture allow operation with minimal energy, making it ideal for battery-powered or off-grid environments [41,42].

As shown in

Table 6. Power consumption comparison between MSP430FR2355 and ESP32 in various power modes.

Power Mode	MSP430FR2355	ESP32
Active	3.40 mA (24 MHz (max frequency))	20–31 mA (80 MHz (normal speed))
Deep Standby	0.62 $\mathsf{\mu }$A	10–150 $\mathsf{\mu }$A depending on RTC/ULP

, the MSP430FR2355 demonstrates lower power consumption across both active and standby modes when compared to the ESP32. These values, derived from the official datasheets of Texas Instruments [43] and Espressif Systems [44], reinforce the suitability of the MSP430 for continuous, energy-efficient sensor monitoring in environments with limited power availability.

Additionally, the MSP430FR2355 offers greater scalability for integrating multiple sensors, providing flexibility for future system expansions. Although its unit price (USD 3.96) is not the lowest among microcontrollers, its energy-saving features and sensor integration capabilities justified its selection. A quotation obtained on 2 April 2025, from Mouser and Digi-Key confirmed the same price across both distributors as shown in

Table 7. MSP430FR2355 unit price quotation for small quantities (as of 2 April 2025).

Distributor	Model	Quantity	Unit Price (USD)	Reference
Mouser Electronics	MSP430FR2355	1	USD 3.96	[45]
Digi-Key Electronics	MSP430FR2355	1	USD 3.96	[46]

 [35,36].

Actuators: For initial testing, 80 × 80 × 25 GC 12 V 0.15 A fans will control airflow, validating the predictions of the system. For real-world applications, larger and more robust actuators can be integrated to meet higher demands.

Figure 1 illustrates the selected hardware components and their interactions. The DHT22 sensor measures temperature and humidity, sending data to the MSP430FR2355 for processing. The MSP430FR2355 communicates with the ESP32, which transmits the data to the server and relays commands back to the MSP430FR2355 to control the actuators.

In this initial development phase, only temperature and humidity sensors components were selected into the system. This choice was based on a review of existing research in IoT applications, environmental monitoring, and machine learning for animal and crop welfare, where temperature and humidity consistently emerged as universally monitored parameters [12,17,47,48,49,50,51]. Focusing on these two variables allowed the project to validate the core functionality of the ecosystem while maintaining low costs, which aligns with the primary objective of this research work—to validate the functionality and viability of an IoT-based environmental monitoring and control ecosystem designed for agricultural barns.

Additionally, while gas sensors capable of detecting compounds such as ammonia, methane, and carbon dioxide are relevant for specific applications, such as dairy farms, their cost remains higher than that of basic environmental sensors  [6,12,13,25]. To maintain the principles of cost effectiveness and feasibility in this initial version, and to ensure that the system fulfilled its primary validation objectives, the integration of gas sensors was deferred. A price quotation of the main gas sensors identified in the recent research works on environmental monitoring was conducted using two major electronic component marketplaces, Digi-Key and Mouser [3,6,22,25,35,36,52]. The results, summarized in

Table 8. Quotation of gas sensors for environmental monitoring applications (as of 2 April 2025).

Distributor	Model	Type	Gas	Unit Price (USD)	Reference
Mouser Electronics	SRAQ-G001 (MG811)	Carbon Dioxide (${\mathrm{CO}}_2$)	${\mathrm{CO}}_2$	USD 135.74	[53]
Digi-Key Electronics	SRAQ-G001 (MG811)	Carbon Dioxide (${\mathrm{CO}}_2$)	${\mathrm{CO}}_2$	USD 146.93	[54]
Digi-Key Electronics	MIKROE-1630 (MQ-135)	Air Quality (Ammonia (${\mathrm{NH}}_3$), Carbon Monoxide (CO) and Methane (${\mathrm{CH}}_4$))	Multiple Gases	USD 20.00	[55]
Mouser Electronics	MIKROE-1630 (MQ-135)	Air Quality (Ammonia (${\mathrm{NH}}_3$), Carbon Monoxide (CO) and Methane (${\mathrm{CH}}_4$))	Multiple Gases	USD 20.00	[56]
Mouser Electronics	SEN0159 (MG811)	Carbon Dioxide (${\mathrm{CO}}_2$)	${\mathrm{CO}}_2$	USD 48.90	[57]
Digi-Key Electronics	SEN0159 (MG811)	Carbon Dioxide (${\mathrm{CO}}_2$)	${\mathrm{CO}}_2$	USD 48.90	[58]

, support the decision by highlighting the higher cost associated with these sensors compared to basic temperature and humidity sensors.

The integration among these components is responsible for providing a flexible and scalable ecosystem, which contributes to the posterior integration of sensors, actuators, and hardware components.

3.4. Hardware Workflow

The hardware workflow is illustrated in Figure 2, which details the interaction between the sensor network and the server to monitor microclimatic conditions and control actuators. The process begins with the Sensor System Network (SSN), which periodically checks whether it is time to measure the temperature and humidity. This time interval is configurable based on the system’s requirements. If the condition is met, the system collects the environmental data and sends them to the server. Upon receiving the data, the server processes the information and sends a response back to the sensor network. If the response is valid, the system adjusts the actuator’s response and calls other endpoints to train the machine learning algorithms based on the commands in the servers. In the case of an invalid response, an alert is triggered using an LED.

3.5. Hardware Assembly

The initial tests will be conducted using a protoboard, connecting the sensor and microcontroller components. This setup will be placed in a living room environment to monitor temperature and humidity, serving as a proof of concept. In addition to the protoboard tests, a Printed Circuit Board (PCB) will also be developed to integrate the same components in a more compact and stable design. Data collected during this phase will be used to validate the system’s functionality and reliability, ensuring it meets the research work’s requirements and objectives.

3.6. Selection of Predictive Algorithms

The selection of predictive algorithms for the project was guided by the characteristics of the microclimatic data and the need to forecast conditions, particularly temperature. The system’s data consist primarily of temperature and humidity measurements collected by sensors in a microcontroller network. These data exhibit a strong temporal component with continuous variations over time, requiring algorithms capable of capturing these dependencies. Additionally, external parameters such as weather forecasts and atmospheric conditions were integrated to enhance predictive capabilities. Based on these factors, the selected algorithms needed to be capable of the following:

• Capture temporal patterns in the data.
• Process multiple microclimatic variables.
• Provide predictions for decision-making.
• Scale with increasing data volumes.

To meet these requirements, the following algorithms were selected:

• Recurrent Neural Networks (RNNs): RNNs were chosen for their ability to handle time-series data and capture long-term dependencies [59].
• Random Forest (RF): Random Forest was selected for its versatility in handling complex, non-linear data, a feature in environmental monitoring systems. Additionally, it mitigates the impact of outliers, enhances accuracy by aggregating predictions from multiple decision trees, and identifies the most important variables [60].

3.7. Selection of Cloud Service Provider

The selection of a cloud service provider for this research work was based on an analysis of technical, functional, and economic requirements. Given the need for a reliable and scalable infrastructure to support data collection, processing, and predictive analysis, specific criteria were established to guide the evaluation. These criteria ensured that the chosen provider could meet the demands of data-intensive operations while maintaining cost efficiency and security. The following aspects were considered:

• Scalability: the ability to expand storage and processing resources as data volume increases and new functionalities are added.
• Cost Effectiveness: a pricing model that balances storage, processing, and data transfer costs, ensuring the economic feasibility of the project.
• Support for Machine Learning: tools for developing, training, and deploying machine learning models for predictive analysis and automated adjustments.
• Security and Compliance: security measures, such as encryption and key management, alongside compliance with international data protection regulations.
• High Availability and Redundancy: guarantees of service availability through redundant infrastructure to ensure reliability.

To determine the most suitable cloud service provider, a detailed evaluation was conducted based on the defined criteria. The assessment focused on scalability, cost effectiveness, machine learning support, security, and high availability. Three major cloud providers were analyzed, each offering distinct advantages and specialized tools for handling IoT-driven data processing and predictive analytics. The comparison included the following.

3.7.1. Amazon Web Services (AWS)

AWS offers a scalable infrastructure and IoT support through AWS IoT Core. It includes services like AWS SageMaker for machine learning and DynamoDB for managing large datasets. AWS is recognized for its global presence, high security, and 99.99% uptime, supported by 108 availability zones in 34 regions [61,62].

3.7.2. Microsoft Azure

Azure provides Azure IoT Hub for managing IoT devices and integrates with Azure Machine Learning. It also supports SQL and NoSQL databases, offering security features and compliance with data regulations [63].

3.7.3. Google Cloud Platform (GCP)

GCP features Google Cloud IoT Core and integrates with TensorFlow, a machine learning framework. It has data analysis tools such as BigQuery, and scalability [64].

After a comparative analysis, AWS was selected as the cloud service provider for this research work. Its flexible on-demand pricing model allows payment only for services used, optimizing cost efficiency. Additionally, the AWS global infrastructure ensures 99.99% availability and redundancy, aligning with the project’s scalability, efficiency, and reliability requirements [61].

3.8. Database Architecture Definition

The system utilizes the NoSQL DynamoDB database to store ecosystem data, enabling queries, retrieval, and long-term storage. The choice of DynamoDB was driven by its ability to provide scalability and flexibility inherent to NoSQL technologies. The database architecture was designed to support the management of multiple controlled environments, allowing the system to monitor and adjust conditions across different locations simultaneously.

The database architecture, depicted in Figure 3, details the entities and their relationships responsible for storing and managing ecosystem data:

• HangarData (1-1): Stores information about controlled environments (e.g., barns or specific facilities). Each environment has a unique configuration in the APIConfiguration table.
• ModuleSensorData (1-n): Represents sensor modules monitoring each environment. A single environment can include multiple modules, each capable of collecting data from multiple sensors, linked to the SensorData table.
• SensorType (1-n): Defines sensor types (e.g., temperature and humidity) used in the system. Modules can include multiple sensor types, and a single type can be shared across modules.
• SensorData (1-n, 1–2): Stores raw data collected by sensors, linked to the following:

  −

  ModuleSensorData (1-n): Multiple data points collected per module.

  −

  WeatherData (1–2): Weather data for the current time and 24-h forecast.

  −

  PredictData (1–1): Predictions for the next measurement in the environment.

• WeatherData (1–2): Holds external meteorological data, linked to SensorData for current and forecasted conditions.
• PredictData (1–1): Stores predictions generated by machine learning algorithms based on sensor data, directly linked to corresponding sensor data.
• ActuatorData (1-n): Maintains information about actuator control (e.g., fans). Each module can manage multiple actuators based on sensor data.
• ControlLogs (1-n): Logs operational failures within the ecosystem. Each module can generate multiple failure records for tracking issues.
• APIConfiguration (1–1): Stores API settings specific to each controlled environment, linked to the HangarData table.

3.9. API Architecture and Requirements

The proposed environmental monitoring and control system integrates multiple components to collect, process, and analyze microclimatic data. The sensor network forms the core of this architecture. Figure 4 illustrates the interaction between these components, highlighting the data flow across the sensor network, APIs, and storage/prediction services.

The sensor network serves as the backbone of the system, responsible for collecting data from microclimatic variables such as temperature and humidity. These data points are sent to the API for further processing and integration with external sources.

3.9.1. Receiving and Processing Data API

The API receives data from the sensor network and integrates them with external information, such as weather forecasts, including humidity, wind speed, and atmospheric pressure, obtained from a weather service like WeatherAPI [65]. This dataset is stored in the database and used to train predictive algorithms. The API also performs the following key tasks:

• Data Enrichment: Combines sensor data with external weather information to provide a dataset for predictive analysis.
• Decision Making: Based on predictions, the API determines whether actuators (e.g., fans) should be activated or deactivated to maintain the ideal conditions.
• Algorithm Training: If required, the API sets the system to train the algorithms, and another API is called by the SSN to perform the training.
• Data Storage: Organizes and stores all processed data in a database for future use in predictions or visualization via the web interface.
• Error Logging and Classification: Any errors encountered during the process are logged, categorized, and saved for future analysis.

In summary, the Receiving and Processing Data API serves as the brain of the system’s decision-making process. It gathers data from sensors, enriches them with external weather forecasts, and stores everything in the cloud. By analyzing these data, the API helps determine whether to activate devices like fans to maintain a stable environment. It also stores all collected data and records the system’s operational behavior, making this information available for later analysis, model training, and diagnostics.

Figure 5 provides a detailed view of the process of the API for handling received data, integrating weather information, and managing actuators.

3.9.2. Database and Cloud Storage

The system relies on both a database and cloud storage to manage and process data.The database handles structured data, storing sensor readings and external weather information. This ensures that data are available for predictive algorithms and can be accessed through the web interface for monitoring and historical analysis.

Meanwhile, cloud storage provides a scalable space for storing machine learning models and related data. This allows the system to retain predictive knowledge, making it possible to update and retrain models as new data become available without overloading the database. Together, these components ensure data management, supporting both operations and long-term system improvements.

3.9.3. API for Training Predictive Algorithms

The Training API utilizes data from the sensor network and the weather forecast service to train machine learning algorithms. These algorithms predict environmental conditions by assessing data from microclimatic variables, such as temperature and humidity, for the next sensor network measurement. The API automates the entire training process, including data preparation, algorithm selection, and storing learned knowledge, as illustrated in Figure 6.

The data formatting and preprocessing process ensures that the dataset is structured and optimized for training, improving model accuracy and reliability. This step includes organizing raw sensor data, integrating external sources, and preparing the dataset for machine learning algorithms. The key tasks involved are as follows:

• Combining data sources: Sensor data are enriched with weather data (e.g., humidity, wind speed, and atmospheric pressure) retrieved from external services, such as WeatherAPI [65].
• Cleaning and validation: The API checks for missing or inconsistent values and applies imputation techniques to ensure data integrity.
• Data splitting: The dataset is divided into training, validation, and test sets for model evaluation.

Once the data are formatted, the training workflow in the API begins with data normalization and feature selection. The dataset is then split into training and validation subsets, enabling the model to learn patterns and be evaluated for accuracy. Finally, the trained model is tested against unseen data before deployment. The API follows these key steps:

• Retrieve Algorithms: The API retrieves all configured algorithms, including regression models and neural networks.
• Prepare Data for Training: The API formats the data to meet the requirements of each algorithm.
• Train Algorithms: The API trains all algorithms with the prepared data and evaluates them using metrics such as accuracy, R-squared, and Mean Absolute Error (MAE).
• Select the Best Algorithm: The API compares the trained algorithms and selects the one with the highest accuracy for the environment.
• Save Trained Model: The selected algorithm and its learned model are stored in both the cloud storage and the database.

The API is designed to handle both successful and failed training processes, ensuring reliability and traceability in model development. It follows a structured approach to manage outcomes as follows:

• Successful Training: The trained model is linked to the specific environment, and its knowledge is saved for use in future predictions. The training configuration for the environment is then unset.
• Failed Training: If the process fails, the API creates an error log that details the issues encountered.

3.9.4. API Development

The APIs were developed using Python Version 3.12, chosen for its flexibility and compatibility with a wide range of data science and machine learning libraries. Python simplifies integration with cloud services such as AWS by leveraging libraries like boto3 for resource management. The implementation relies on several key libraries and tools:

• scikit-learn and TensorFlow/Keras: These libraries were used to provide a infrastructure for building, training, and testing predictive models.
• decouple: Used to facilitate environment variable management, ensuring the secure handling of sensitive configurations.
• requests: Handles HTTP requests, allowing communication with external services such as WeatherAPI [65].
• pandas and numpy: Used for data manipulation, cleaning, and analysis, enabling the processing of large datasets.
• pickle: Used for serializing and deserializing objects, such as saving trained models for reuse.

3.10. Web Interface Architecture and Requirements

The web interface is designed to enable the monitoring, visualization, and management of microclimatic data captured by sensors. The architecture follows a client–server approach, with a front-end for user interaction and a back-end for data processing and database communication.

3.10.1. Front-End (User Interface)

The front-end is built using HTML, CSS, and JavaScript, with the Bootstrap framework to create responsive layouts. This ensures accessibility and usability across different devices, including desktops, tablets, and smartphones. For data visualization, the Chart.js library is employed to generate dynamic and interactive charts, such as line and bar graphs, enabling users to monitor variables like temperature and humidity over time. The key features of the front-end include the following:

• Data Filtering: The system allows users to filter data based on specific parameters and date ranges [66].
• Data Export: Users can export visualized data in formats such as Excel or CSV for offline analysis [67].

3.10.2. Back-End (Database Interaction)

The back-end is responsible for managing data flow and system operations by directly interacting with the DynamoDB database. This interaction ensures configuration management, and actuator control, enabling operation of the IoT ecosystem. The back-end performs the following key functions within the database:

• Retrieving sensor-captured data.
• Managing system configurations.
• Controlling actuators in the network.

To enhance efficiency, the back-end employs a caching strategy, temporarily storing frequently accessed data in memory. This approach reduces database query frequency, lowers AWS service utilization costs, and improves response times for repeated queries.

3.10.3. Functional Requirements

The functional requirements define the essential capabilities that the system must provide to ensure monitoring and control of environmental conditions. These requirements focus on data visualization, historical data management, error monitoring, system configuration, and actuator control. By implementing these features, the system enables users to access and interact and historical data. The key functional requirements are as follows:

• Data Visualization: The system must allow users to access and view data, such as temperature and humidity, captured by sensors.
• Historical Data Visualization: Users must be able to view historical data through interactive and dynamic charts. Data should be filterable by parameters (e.g., temperature and humidity) and date ranges.
• Data Export: The interface should support exporting both and historical data in formats like Excel and CSV.
• Error Monitoring: The system must detect and display ecosystem failures in a report format for user review.
• Hangar Configuration: Users should be able to configure hangar parameters, such as acceptable temperature and humidity limits.
• Actuator Control: The interface must enable users to control actuators (e.g., fans and heaters) within the sensor network.

3.10.4. Non-Functional Requirements

The non-functional requirements define performance and usability aspects that ensure the system operates and remains accessible across different devices. These requirements focus on factors such as responsiveness, scalability, and user experience. The main non-functional requirement is as follows:

• Responsiveness: The web interface must adapt to various screen sizes and devices (e.g., desktops, tablets and smartphones) without compromising usability or user experience.

To support these functional and non-functional requirements, the web interface was developed using Python Version 3.12 and the Django framework Version 5.0.6, chosen for its scalability, modularity, and integration capabilities [68]. Django’s security features, built-in tools, and support for third-party integrations enhance system reliability and facilitate communication with cloud services.

4. Results and Discussion

4.1. Hardware Validation Results

The IoT-based environmental monitoring system was tested in a controlled confinement building to validate its functionality. The first set of the proof of concept, assembled on a protoboard, included the MSP430FR2355 microcontroller, the ESP32 microcontroller, the DHT22 sensor, and the actuators that, in this case, were fans. During the tests, the system successfully collected temperature and humidity data from the sensor and transmitted them to the cloud via the ESP32 microcontroller. The dataset was sent to the API, which was responsible for processing and storing it in the cloud. We also tested the actuators, such as the fans. In this process, the system activated and deactivated the fans based on the system commands. It is noteworthy to mention that the transition from the protoboard to the PCB (Figure 7) did not introduce any functional issues.

After assembling the PCB, the hardware was deployed in situ inside the controlled test environment to validate its performance under real-world conditions. During the deployment, the system continuously monitored ambient temperature and humidity using the DHT22 sensor and successfully activated the actuators. Figure 8a,b illustrate the hardware installed and operating inside the room.

The hardware is powered by a 5 V DC supply, obtained from an HLK-PM01 AC-DC converter module connected to the main power grid (110/220 V AC). The 5 V supply feeds a linear regulator (TPS7A4533), which provides a stable 3.3 V rail for the ESP32 module, the MSP430FR2355 microcontroller, and other 3.3 V components. For networking, the ESP32 microcontroller establishes Wi-Fi communication with the local wireless network.

To optimize power consumption, the system was designed so that the ESP32 remains in deep sleep mode for the majority of the operating cycle. The MSP430FR2355 microcontroller, operating continuously in an ultra-low power mode, is responsible for managing sensor data acquisition. When a data transmission event is scheduled, the MSP430 triggers the ESP32 to wake up, establish a Wi-Fi connection, and transmit the collected sensor data to the cloud server through an HTTPS REST API request. Immediately after completing the communication, the ESP32 returns to deep sleep mode.

Figure 9 illustrates this behavior, presenting the current consumption profile during a typical operation cycle. The graph highlights the minimal baseline current during sleep phases and the temporary peak during active communication. This design reduces the average power consumption of the system, making it suitable for energy-constrained deployments while ensuring reliable and periodic data transmission to the cloud. The measurement was obtained using a Tektronix TBS 1052B Digital Oscilloscope (Beaverton, OR, USA).

In addition to evaluating the ESP32’s current consumption during its operational cycle, measurements were also conducted on the MSP430FR2355 microcontroller during operation. Due to the extremely low current drawn by the MSP430, it was not possible to accurately visualize its consumption using the oscilloscope. Therefore, a Siglent SDM3065X digital amperimeter (Solon, OH, USA) was employed to perform the measurements. The MSP430 exhibited significantly lower current consumption compared to the ESP32, drawing approximately 0.001 mA during continuous operation, whereas the ESP32 exhibited an active consumption of approximately 30.00 mA. Figure 10 presents the current profile of the MSP430, highlighting its minimal energy usage. This behavior validates the design decision to delegate continuous tasks, such as sensor monitoring and actuator control, to the MSP430.

In this initial version of the system, wireless communication is implemented using Wi-Fi technology through the ESP32 microcontroller. As a result, the coverage is inherently limited by the default range of standard Wi-Fi networks. Under typical indoor conditions, the communication range reaches approximately 50 m, which is sufficient for small agricultural facilities, confinement buildings, or controlled environments. However, for larger installations or deployments in areas with significant physical obstructions, coverage extension strategies such as Wi-Fi repeaters, mesh networking, or the integration of long-range communication technologies like LoRa could be considered in future versions of the system.

4.2. Software Validation Results

4.2.1. API Validation

The validation process focused on two APIs: the Data Processing and Prediction API, and the Training API. Both APIs performed as expected, demonstrating their ability to handle data, integrate with the sensor network, and execute their respective tasks. The Data Processing and Prediction API processed environmental data from the sensor network and enriched it with external weather data. It determined appropriate actuator states (e.g., turning actuators on or off) and flagged scenarios requiring additional actions, such as training machine learning algorithms.

As shown in Figure 11a, the system successfully transmitted and received sensor data. In scenarios where training was required, the API set the SetToTrain flag to true, signaling the need for training. After the training process was completed by the Training API, subsequent data sent to the Receiving and Processing Data API, as expected, reset the SetToTrain flag to false, following the configuration of training only during predefined time gaps specified for each hangar. This mechanism ensures that the system operates by avoiding unnecessary training processes while maintaining predictive capabilities tailored to each hangar’s requirements.

The Training API handled the preparation and training of machine learning algorithms. It processed formatted sensor and weather data to train multiple algorithms and selected the model with the best performance metrics. The trained model was saved for future use in both cloud storage and the database. Figure 11b showcases the input and output during the API operation. Once training was complete, the API reset the SetToTrain flag to false, ensuring the Receiving and Processing Data API continued functioning without retriggering training unnecessarily.

4.2.2. Web Interface Validation Results

The web interface was tested, demonstrating its capability to meet the defined functional and non-functional requirements. The results highlight its usability, responsiveness, and integration with the back-end services. The interface was tested for responsiveness and accessibility across multiple devices, including desktops, tablets, and smartphones. As shown in Figure 12, the layout dynamically adapts to different screen sizes.

Beyond responsiveness, the interface enhances user experience by providing a platform for monitoring and managing environmental conditions, integrating access to the latest sensor data, weather conditions, and system predictions as shown in Figure 12. Additionally, users can interact with a dynamic chart, as shown in Figure 13, which visualizes trends in environmental parameters over customizable time ranges.

By providing monitoring and management features, the interface supports data visualization, reports, and error monitoring by enabling the monitoring and management of environmental conditions, providing users with access to the latest sensor data, weather conditions, and system predictions. Additionally, the interface includes reporting capabilities, allowing users to view reports on sensor data, weather data, error logs, predictive analytics, and actuator performance as shown in Figure 14. Filter options enable users to retrieve specific data ranges, while export functionality supports saving reports in Excel or CSV formats for offline analysis.

The web interface includes an actuator control feature that supports both manual and automatic configurations. In manual mode, users can toggle actuators on or off and view their current status. In automatic mode, users can enable or disable the system’s ability to control actuators based on predefined conditions and predictive algorithms. The system analyzes the maximum and minimum temperature thresholds configured for the hangar and the predictive temperature provided by the algorithms to determine whether to activate or deactivate the actuators as shown in Figure 15.

The Algorithm Configuration Interface, as shown in Figure 16, provides a flexible platform for configuring both general and algorithm-specific settings for the predictive system. General settings include the activation of machine learning training steps, training frequency, and displaying the algorithm selected according to the defined criteria for the best performance, based on metrics such as Mean Absolute Error (MAE) and R-squared (R2).

Users can customize configurations for the Random Forest and RNN algorithms, adjusting parameters to optimize predictions for specific operational contexts. This interface eliminates the need for direct code adjustments, enabling adaptation to varying conditions.

To optimize performance, the back-end implements caching, reducing query frequency to the DynamoDB database. This approach improved response times for frequently accessed data by approximately 90%, while also minimizing AWS resource use (Figure 17).

4.3. General Ecosystem

The general ecosystem of the monitoring system was evaluated to analyze its performance in data collection and processing over a period. Between 30 July 2024 and 21 October 2024, the system collected environmental data every 3 h, totaling 624 readings.

This subsection provides insights into the errors encountered during this period and evaluates the system’s alignment with the objectives set for accuracy and efficiency.

The data collection interval was set to three hours to balance operational costs and data accuracy while avoiding higher costs associated with shorter intervals. The use of the DynamoDB in a 30-day period included 24,600 writes and 24,600 reads, calculated at USD 1.25 per million writes and USD 0.25 per million reads, resulting in an estimated monthly cost of USD 19.19 [69]. The breakdown of costs across tables is as follows:

• Sensor Data Table: $\mathrm{14,760}\mathrm{writes}+\mathrm{14,760}\mathrm{reads}=11.51\mathrm{USD}/\mathrm{month}$.
• Weather Data Table: $4920\mathrm{writes}+4920\mathrm{reads}=3.84\mathrm{USD}/\mathrm{month}$.
• Predictions Table: $2460\mathrm{writes}+2460\mathrm{reads}=1.92\mathrm{USD}/\mathrm{month}$.
• Actuator Data Table: $1230\mathrm{writes}+1230\mathrm{reads}=0.96\mathrm{USD}/\mathrm{month}$.
• Hangar Configuration Table: $615\mathrm{reads}=0.08\mathrm{USD}/\mathrm{month}$.
• API Configuration Table: $615\mathrm{reads}=0.08\mathrm{USD}/\mathrm{month}$.

The total cost per cycle (one data collection instance) across all tables is approximately: 0.048 + 0.016 + 0.008 + 0.004 + 0.00034 + 0.00034 = 0.077 USD/cycle.

Reducing the interval to 2 h would increase the number of operations by 50%, increasing costs to approximately USD 28.79 per month. Although this remains below the USD 30.24/month cost of an AWS EC2 instance (t4g.nano in the eastern region of the United States), the small margin introduces a higher financial risk due to potential fluctuations in data volume and additional AWS charges [69]. The 3 h interval was chosen to maintain cost-efficiency and financial predictability while meeting system accuracy and operational requirements, ensuring sustainability without nearing the costs of alternative configurations.

Table 9. AWS billing summary for October 2024.

Description	Usage Quantity	Amount (USD)
DynamoDB	-	29.78
EC2 Container Registry (ECR)	-	0.03
Data Transfer	-	0.02
API Gateway	-	0.00
CloudWatch	-	0.00
Elastic Compute Cloud	-	0.00
Key Management Service	-	0.00
Lambda	-	0.00
Simple Storage Service (S3)	-	0.00
Virtual Private Cloud (VPC)	-	0.00
Total Tax	-	4.12

summarizes the AWS billing for the system from 1 to 21 October 2024. Most of the cost (USD 29.78) was due to DynamoDB operations, while services like EC2 Container Registry (ECR) and Data Transfer incurred minor charges of USD 0.03 and USD 0.02, respectively. No significant charges were observed for other services like API Gateway, CloudWatch, Lambda, or S3.

The AWS free tier offsets the overall costs, particularly for DynamoDB read and write capacity units. However, the total expenses exceeded the initial estimates due to additional activities, such as testing in the development environment, utilizing the web interface for data visualization and reporting, and the inclusion of taxes and other incidental charges.

During the data collection period, 21 processing errors were logged, resulting in an error rate of approximately 3.37%. These errors were analyzed to identify common failure patterns and improve system reliability. The errors were categorized into four main types based on their causes and impact on data processing as shown in Figure 18:

• missing_data_error: Occurs when the system fails to record or retrieve required sensor data, leading to incomplete data entries.
• sensor_data_error: Happens when the sensor readings are invalid or out of the expected range, likely due to hardware issues or environmental interference.
• weather_forecast_fetch_error: Represents failures in retrieving weather forecast data from the external API, possibly due to connectivity issues or API downtime.
• loadingfile_error: Indicates problems in accessing or processing files required for system operations, such as machine learning knowledge.

The distribution of errors reflects the robustness of the system, as it maintained a data accuracy rate above 96%. This performance surpasses the 95% accuracy target established in the objectives.

4.4. Validation of Predictive Algorithms

To address the statistical analysis concerns raised, both Random Forest (RF) and Recurrent Neural Network (RNN) models were trained and validated using historical sensor data collected by the system between July 2024 and September 2024. The evaluation employed standard metrics to assess predictive performance, including Mean Absolute Error (MAE), Root Mean Squared Error (RMSE), Relative Errors, and the R-squared coefficient (R²). These results are presented in

Table 10. Performance metrics for predictive models (testing dataset: 07/2024–09/2024).

Metric	Random Forest	Recurrent Neural Network
Mean Absolute Error (MAE)	0.4114	1.0342
Mean Squared Error (MSE)	0.3550	1.7452
Root Mean Squared Error (RMSE)	0.5959	1.3211
Relative Absolute Error (RAE)	0.2175	0.4483
Relative Squared Error (RSE)	0.0599	0.2110
R-squared (R²)	0.9401	0.7890
Accuracy (%)	98.05	95.20

.

Based on these metrics, the Random Forest model demonstrated superior predictive performance, particularly in terms of error rates and the R² value, which indicates stronger explanatory power. This justified its selection as the primary model for use.

To validate the system’s predictive accuracy in forecasting temperature under real operating conditions, both models were evaluated using data collected in October 2024. In this phase, the models were already trained with historical data, and predictions were generated continuously during the month. At the end of the period, the predicted temperature values were compared with the actual readings recorded at the corresponding time intervals to assess their practical reliability. As shown in Figure 19, the Random Forest model achieved a general accuracy of 96.46%, exceeding the research work’s target of 80%.

Similarly, as illustrated in Figure 20, the RNN model reached a general accuracy of 96.15%, confirming its robustness for prediction, although with slightly lower training metrics compared to Random Forest.

While both models maintained high accuracy during their operational use, the slightly lower performance observed in October compared to the testing phase can be attributed to the dynamic and unpredictable nature of environmental conditions, particularly external weather factors not fully represented in the training dataset. These results reinforce the importance of continuous model evaluation and demonstrate the system’s ability to deliver reliable predictions even under variable field conditions.

5. Future Work

This study successfully validated an IoT-based environmental monitoring and control ecosystem for agricultural applications, demonstrating its accuracy, predictive efficiency, and feasibility for real-world deployment. Nevertheless, several enhancements are necessary to improve scalability, optimize performance, and adapt the system to diverse agricultural contexts.

Although the system was initially tested in a controlled setting, future research will involve long-term field deployments across diverse agricultural environments, including barns, storage facilities, and various geographical regions. Such deployments will enable the evaluation of system robustness under varying operational and environmental conditions, while providing real-world data essential for refining predictive models and optimizing actuator control strategies.

Future investigations will address the following research directions:

• Expansion of Environmental Sensing: Expanding the sensor network by integrating gas sensors for ammonia (NH₃), carbon dioxide (CO₂), carbon monoxide (CO), and methane (CH₄) detection, with the goal of enhancing environmental modeling and improving predictions related to animal welfare and facility management.
• Remote Update Mechanisms: Investigating the feasibility and impact of implementing over-the-air (OTA) firmware update mechanisms, facilitating scalable and maintainable sensor network deployments in agricultural settings.
• System Architecture Optimization: Exploring alternative backend architectures, including transitioning APIs to faster languages such as Golang, to improve system scalability, real-time responsiveness, and operational efficiency under increasing data loads.
• Usability Evaluation: Conducting field-based user studies and participatory design research to evaluate and enhance the web interface’s usability, ensuring it effectively supports operational decision-making for agricultural facility managers.
• Expansion of Predictive Modeling: Extending predictive models to encompass additional environmental parameters, such as humidity, air quality indices, and specific gas concentrations, thereby enhancing the system’s proactive control capabilities.

Furthermore, recent advances in image processing technologies [70,71,72,73] highlight the potential for integrating low-cost image sensors and lightweight visual analysis algorithms. Future iterations of the FarmSync system will explore the incorporation of visual data streams to enable classification and monitoring tasks, moving toward the development of a digital twin framework for agricultural facility management.

These research directions aim to strengthen the system’s operational reliability, broaden its applicability across diverse agricultural environments, and contribute to the advancement of sustainable, technology-driven agricultural practices. By integrating predictive modeling, multisensory data acquisition, and visual analysis, the FarmSync system aspires to evolve into a digital twin platform, offering intelligence and adaptability for agricultural operations.

6. Conclusions

This study developed and validated an IoT-based ecosystem for environmental monitoring and predictive control in agricultural barns, achieving over 95% data accuracy and 96% prediction efficiency with Random Forest and RNN models, exceeding the initial 80% performance target. The modular hardware and software architecture ensures scalability, while the responsive web interface enables seamless data management across a variety of devices.

The system’s cost structure supports scalability, increasing proportionally with the user’s production expansion, and energy efficiency is achieved through intelligent actuator management, optimizing energy consumption by activating actuators only when necessary. These characteristics reinforce the system’s economic and operational viability, particularly when compared to conventional cloud-based agricultural monitoring solutions.

While the system achieved its validation objectives under controlled conditions, future research will focus on deploying and validating the system in real agricultural environments. Further work will explore the expansion of environmental sensing capabilities through the integration of gas sensors, the implementation of over-the-air (OTA) update mechanisms to enhance scalability and maintainability, and the optimization of database performance for large-scale deployments. Additionally, advances in low-cost image sensors and visual processing algorithms will be investigated to extend the system’s capabilities toward image-based environmental analysis, supporting the development of a digital twin framework for agricultural facility management.