--- slug: agricultural-iot-networks type: pattern summary: "Designing the field, greenhouse, or facility sensor network as a maintained measurement system rather than a pile of devices." created: 2026-05-06 updated: 2026-05-22 section: measurement_traceability related: agricultural-remote-sensing: relation: complements note: "Sensor Networks and IoT in Agriculture ground-check Remote Sensing for Agriculture with field-level observations." soil-carbon-mrv: relation: supports note: "Sensor Networks and IoT in Agriculture support Soil Carbon MRV Pipeline by recording management, weather, moisture, and boundary conditions around field sampling." farm-digital-twin: relation: enables note: "Sensor Networks and IoT in Agriculture supply live observations that Digital Twin for Farms and Facilities needs to stay current." food-blockchain-traceability: relation: informs note: "Sensor Networks and IoT in Agriculture can feed Blockchain Traceability for Food, but they do not solve input-data integrity by themselves." daily-light-integral: relation: measures note: "Sensor Networks and IoT in Agriculture measure Daily Light Integral when quantum sensors and loggers are placed at crop height." vapor-pressure-deficit: relation: measures note: "Sensor Networks and IoT in Agriculture measure the temperature and humidity data used in Vapor Pressure Deficit Control." greenhouse-climate-control: relation: supports note: "Sensor Networks and IoT in Agriculture support Greenhouse Climate Control by making crop-level climate and root-zone conditions visible." vendor-locked-traceability: relation: mitigates note: "Sensor Networks and IoT in Agriculture mitigate Vendor-Locked Traceability when data formats, ownership, and export rights are designed before deployment." --- # Sensor Networks and IoT in Agriculture > **Pattern** > > A named solution to a recurring problem. *Design the field, greenhouse, or facility sensor network as a maintained measurement system, not as a pile of devices.* *Also known as: agricultural IoT, farm sensor network, field instrumentation, CEA sensor stack.* A sensor doesn't create evidence by being installed. It creates evidence when the right instrument sits in the right place, is calibrated on schedule, survives the farm's backhaul conditions, and feeds a decision someone will actually make. Without that discipline, the dashboard fills with numbers the operator doesn't trust. ## Understand This First - [Remote Sensing for Agriculture](agricultural-remote-sensing.md) — the aerial and satellite layer that field sensors ground-check. - [Soil Carbon MRV Pipeline](soil-carbon-mrv.md) — the claim-audit layer that may use sensor records as supporting evidence. - [Greenhouse Climate Control](greenhouse-climate-control.md) — the controlled-environment operating system that depends on crop-level measurement. ## Context Sensor networks sit between biological reality and data claims. In open-field systems, they may include soil-moisture probes, tensiometers, weather stations, flow meters, canopy-temperature sensors, livestock collars, water-quality meters, and cameras. In controlled-environment agriculture, they add quantum sensors, air-temperature and relative-humidity probes, carbon dioxide meters, substrate moisture sensors, pH and electrical-conductivity sensors, drain scales, fertigation meters, and climate-computer logs. The Internet of Things, or IoT, simply means these devices report through a network rather than staying as isolated readings. The network may use LoRaWAN, LTE-M or NB-IoT cellular, Wi-Fi, wired greenhouse controls, Bluetooth, private 5G, satellite IoT, or a data logger that uploads once a day. Many working systems are hybrid: LoRaWAN nodes in the field, a cellular or satellite gateway at the edge, and ordinary internet protocols after that. The label matters less than the architecture: what is measured, how often, at what accuracy, under whose maintenance, in what format, and for what decision. This pattern matters because most agronomic, finance, and certification claims now ask for more than memory. A lender wants irrigation, yield, or energy records. A buyer wants traceability and food-safety data. A grower wants to catch pump failure before a crop wilts. A soil-carbon project wants weather and management context around sampling events. A sensor network can serve all of those uses, but only if it is designed around the decision path. ## Problem Agricultural sensors are easy to buy and hard to trust. A probe can drift, a gateway can lose power, a cable can fail under rodents or frost, a greenhouse sensor can hang above the crop instead of in the canopy, and a cloud platform can turn export rights into a contract fight. The operator then owns both the hardware cost and the doubt. The recurring problem is false observability. A farm or facility may appear measured because a dashboard has maps, alerts, and charts. But if the instruments are poorly placed, uncalibrated, locked inside one vendor's format, or detached from decisions, the system is not observing the operation. It is decorating it. ## Forces - **Coverage versus maintenance.** More sensors catch more variation, but each one needs power, calibration, cleaning, firmware, and interpretation. - **Precision versus decision value.** A more accurate reading is useful only if it changes an irrigation pass, climate recipe, audit file, or risk model. - **Connectivity versus field conditions.** Backhaul that works in the office may fail behind terrain, steel, foliage, water, dust, or electrical noise. - **Vendor convenience versus data portability.** A closed platform can be easy to start and hard to leave. - **Automation versus agronomic judgment.** Sensors can flag a condition; they can't decide whether the crop response, soil, or market warrants action. ## Solution **Start from the decision, then design the measurement chain backward.** Name the decision first: irrigate this block today, vent this greenhouse bay, prove cold-chain custody, diagnose compaction risk, trigger an alarm, support an MRV record, or feed a digital twin. Then choose the sensor, placement, sampling interval, calibration plan, data model, and owner for that decision. Separate four layers. The instrument layer is the physical measurement: probe, meter, camera, scale, weather station, or logger. The edge layer handles power, local storage, filtering, first-pass checks, and enough local analysis to separate a missing reading from an exception that needs attention. The backhaul layer moves data through LoRaWAN, LTE-M, NB-IoT, ordinary cellular, Wi-Fi, Ethernet, private 5G, satellite IoT, or facility controls. The application layer turns records into alerts, dashboards, reports, or machine-readable events. If any layer is vague, the system will fail at the worst time. Placement is part of the measurement, not an afterthought. A soil-moisture probe in the wrong texture zone can mislead irrigation. A VPD sensor above the crop can miss the boundary layer the leaves experience. A DLI logger below a hanging basket may understate the crop's photon budget. A flow meter downstream of a leak can make water use look better than it is. Good design treats siting notes, photos, depth, height, calibration date, and replacement history as part of the data. Write the maintenance contract before relying on the readings. Who cleans the weather-station radiation shield? Who checks pH probes against buffer solutions? Who replaces batteries? Who compares a greenhouse sensor against a handheld instrument? Who owns the raw data, derived data, and export format if the vendor relationship ends? If no one can answer, the sensor network isn't ready to carry a claim. > **⚠️ Do not confuse live data with truth** > > Real-time readings are still measurements made by instruments that drift, fail, and sit in imperfect places. Use alerts to focus attention; use calibration, records, crop walks, and audits to decide what the numbers mean. ## How It Plays Out **A center-pivot irrigation block.** A grower installs soil-moisture probes at two depths in representative management zones, pairs them with a weather station, and checks readings against field feel, root depth, rainfall, and yield maps. The useful output is not a pretty moisture curve. It is a defensible irrigation decision: which pivot runs, when, and for how long. If the probe sits in an old wheel track or a sand lens no one noted, the decision can be worse than before. **A lettuce greenhouse.** The head grower uses crop-height temperature and relative-humidity sensors, quantum sensors, drain EC, pH, and substrate moisture to manage DLI, VPD, fertigation, and tipburn risk. The climate computer can execute the recipe, but the grower still walks the crop. A sensor reading that conflicts with leaf temperature, condensation, or harvest quality gets checked before the setpoint changes. **A soil-carbon project.** The project doesn't use sensors as a replacement for sampling. It uses them as context: rainfall, irrigation, field operations, grazing events, bare-ground alerts, and weather anomalies around the sampling interval. Those records help explain why two fields with the same practice label may produce different carbon results. They also make false practice claims easier to catch. **An open-source farm record.** FarmOS shows the architecture in a plain form: observations, logs, assets, fields, equipment, and tasks can be recorded without making one proprietary dashboard the only place the history exists. That doesn't make FarmOS the right tool for every operation. It shows the design principle: the farm record should outlive any one device or vendor contract. ## Consequences **Benefits** - Operators catch irrigation, climate, pump, water-quality, and crop-condition problems earlier. - Remote sensing, MRV, finance, and certification claims gain field-level context instead of relying only on self-report or imagery. - CEA teams can tie climate recipes to crop response, energy use, root-zone conditions, and saleable yield. - Maintenance, calibration, and data ownership become part of system design rather than emergency work. - Open formats and export rights reduce the risk of vendor-locked traceability. **Liabilities** - Sensor networks add operating work: installation, power, cleaning, calibration, spares, staff training, and data review. - Bad placement or drift can make a decision worse while still looking precise. - Connectivity gaps can create missing data exactly when weather, irrigation, or facility alarms matter most. - A dense network can collect sensitive commercial information about yield, water, crop stress, animal movement, or facility performance. - Automation can train teams to watch the dashboard and miss the crop, soil, or animal signal in front of them. > **Disclaimer** > > Pattern descriptions are not site-specific recommendations. Local conditions, > crop, soil type, facility design, water source, connectivity, labor, and > regulatory context govern application. ## Sources - Sjaak Wolfert, Lan Ge, Cor Verdouw, and Marc-Jeroen Bogaardt's ["Big Data in Smart Farming - A review"](https://doi.org/10.1016/j.agsy.2017.01.023), *Agricultural Systems* (2017), frames agricultural sensing as part of a wider farm-data architecture. - Athanasios Tzounis, Nikolaos Katsoulas, Thomas Bartzanas, and Constantinos Kittas, ["Internet of Things in agriculture, recent advances and future challenges"](https://doi.org/10.1016/j.biosystemseng.2017.09.007), *Biosystems Engineering* (2017), reviews IoT devices, communications, greenhouse uses, and adoption barriers. - FarmOS's [official project documentation](https://farmos.org/) shows an open-source farm-record architecture where observations, assets, fields, equipment, and tasks can outlive a single sensor vendor. - ThingsBoard's [documentation](https://thingsboard.io/docs/) is useful for understanding generic IoT device management, telemetry ingestion, dashboards, and rule engines; treat it as platform documentation, not authority on agronomy. - The LoRa Alliance's [LoRaWAN overview](https://lora-alliance.org/about-lorawan/) explains the low-power wide-area networking pattern often used for field sensors where Wi-Fi is not practical. - 3GPP's [Release 13](https://www.3gpp.org/specifications-technologies/releases/release-13) materials and [standards-for-IoT presentation](https://www.3gpp.org/images/presentations/3gpp_standards_for_iot.pdf) distinguish the cellular IoT families behind LTE-M and NB-IoT. - Lacuna Space's [LoneWhisper satellite IoT documentation](https://lacuna-space.com/technology/lonewhisper/) is a useful vendor description of direct-to-satellite, low-power IoT messages for remote sensors; treat it as implementation evidence, not as neutral market authority. - Cornell CEA's [Hydroponic Lettuce Handbook](https://cea.cals.cornell.edu/files/2019/06/Cornell-CEA-Lettuce-Handbook-.pdf) gives the crop-facing measurement baseline for pH, EC, light, temperature, humidity, carbon dioxide, airflow, and production records in controlled lettuce systems. --- - [Next: EUDR Deforestation-Free Due Diligence](eudr-due-diligence.md) - [Previous: Nutrient Balance and Nitrogen Surplus](nutrient-balance.md)