When you install sensors in a tunnel, greenhouse, orchard, or open field, the real question is not “which technology is best?”, but “how does a correct measurement arrive on time in a chart I can trust?”. LoRaWAN, NB-IoT, and MQTT are different pieces of the same puzzle: radio, network access, and messaging. If you mix them up, you get hard-to-debug errors: delayed readings, wrong units, or “frozen” values.
In agriculture, physiology matters as much as connectivity: roots react within hours to water deficit or excess, leaves react to microclimate within minutes, and decisions depend on trends rather than single points. That’s why data freshness and integrity (units, calibration, placement, and context) are as important as “signal strength”. A perfectly connected sensor, interpreted incorrectly, can push you toward unnecessary interventions.
The article below explains the mechanism of each technology in practical terms for a technical farm operator and proposes a commissioning workflow you can repeat for every installation. For each step: what to observe, what to verify independently, what practical decision to make, and how to confirm the outcome. The examples are hypothetical so you can adapt the steps to any sensor supplier and any crop system.
1) The big picture: radio, network, application, and the “payload”
A typical monitoring chain has four layers: the sensor (measures), the radio/cellular transport (moves data off-site), a network service (receives and authenticates), and the application (stores, visualizes, and alerts). LoRaWAN and NB-IoT are ways to carry data from the field to the internet; MQTT is a way to move messages between systems once you are already “on the internet”. In practice, LoRaWAN/NB-IoT don’t compete with MQTT—they can feed it downstream.
What you must observe during commissioning is the separation between “measured value” and “transmitted message”. The message contains a payload (often binary or JSON) that must be decoded into correct units. Verify independently by comparing against a reference thermometer, or by checking EC with a handheld meter in the same medium (EC in irrigation water/nutrient solution is not the same as EC in substrate). Practical decision: don’t set alerts until decoding and units are confirmed; check results via coherent trends and the absence of impossible jumps.
2) LoRaWAN: what happens between the sensor and the gateway
LoRaWAN is a low-power, long-range radio network: the sensor sends short, infrequent transmissions to one or more nearby gateways. The gateway does not “understand” crops; it simply forwards packets to a network server. In the field, the mechanism that matters is the link budget: obstacles, metal structures (common in greenhouses), terrain, antenna orientation, and the settings that trade speed for robustness (often summarized as data rate).
What you may observe: a sensor looks “online” sometimes and “silent” at other times, especially if mounted low between dense rows or close to metal framing. Verify independently by temporarily moving the device 1–2 meters higher or farther from metal and watching whether messages become regular again. Practical decision: if the install is marginal, prioritize a cleaner mounting position or add gateway coverage. Confirm the result through consistent reporting intervals and fewer missing messages, not a single successful “check-in”.
3) The LoRaWAN server and delivery to the application (why MQTT appears here)
After the gateway, data reaches a LoRaWAN network/application server. That is where device authentication, decryption, and metadata attachment happen (time, signal strength, and which gateways heard the uplink). Only then do readings become application events. Many LoRaWAN stacks expose application data via MQTT: an application subscribes to a topic and receives messages when the sensor transmits. This is why MQTT does not replace LoRaWAN—it complements it.
What you observe in practice is that there can be two different “times”: measurement time and application receive time. Verify independently by forcing a transmission (if the device supports it) and comparing the moment you triggered it to the time displayed with the reading; large differences suggest buffering or timestamp problems inside the payload. Practical decision: if freshness is critical (for example, temperature used to assess frost risk), shorten reporting intervals and ensure timestamps are interpreted correctly. Confirm by seeing alerts triggered at the event, not hours later.
4) NB-IoT: when the sensor uses the operator’s network directly
NB-IoT is a cellular technology designed for low-power devices: the sensor connects to the mobile operator network with a SIM/subscription and uses power-saving behavior (sleep modes) between transmissions. The practical advantage is you don’t need a private LoRaWAN gateway. Typical disadvantages are coverage variation by band, operator-specific provisioning, and weak-signal behavior (retries, latency, and higher power draw when the modem struggles to attach).
What you might observe: in an orchard located in a small valley, a sensor reports rarely or in bursts because reconnection is difficult and measurements accumulate. Verify independently by checking operator coverage at the exact location, while remembering that “my phone has bars” is not the same as “this device can transmit stable NB-IoT”. Practical decision: choose an operator/band supported by the device and configure power saving so you don’t sacrifice freshness unnecessarily. Confirm via consistent reporting times and stable battery behavior over time, not just the first weekend.
5) MQTT: messaging between equipment and platforms, not “field coverage”
MQTT is a publish/subscribe protocol: a device or gateway publishes messages to a broker, and applications subscribe to topics. It is efficient for telemetry, but it has traps. QoS confirms delivery to the broker, not a physical action in the field; retained messages can present an “old last value” as if it were new unless you check message age; and security (authentication and transport protection) must be configured explicitly. Treat MQTT as a delivery mechanism, not as proof that the crop experienced an event.
What you may observe: a value appears “fresh” after a reconnect, but it is actually the last retained value being replayed to a new subscriber. Verify independently by looking for a timestamp field or a sequence counter in the payload and comparing it to system time; if it’s missing, request it from the sensor supplier. Practical decision: enforce data-freshness rules (for example, only alert if the latest reading is within an acceptable age) and prevent old retained values from being treated as live telemetry. Confirm by intentionally disconnecting/reconnecting and observing behavior on reconnect.
6) Choosing sensors: measurement, medium, units, and calibration
The most common integration error is not “the network”—it’s a wrong assumption about what the sensor measures. A temperature sensor does not measure EC or pH; those require dedicated probes with their own installation and maintenance needs. EC is electrical conductivity and is reported differently in water/nutrient solution versus substrate or soil; pH needs calibration and can drift. VPD is calculated from air temperature and relative humidity, so it is an estimate; leaf temperature can differ from air temperature, especially under radiation or strong ventilation.
What you may observe in charts: values that look plausible but don’t match reality in the crop (for example, EC that never changes after fertigation events, or a pH that stays “perfect” for months). Verify independently with a manual measurement in the same medium (drip solution, drain, or substrate/soil at the same depth), recording units and temperature, then compare. Practical decision: before thresholds and alerts, define a minimum calibration/validation protocol and a maintenance plan. Confirm through coherent responses to known events (irrigation, rain, ventilation), not a single spot-check.
7) A commissioning workflow: short steps that prevent months of confusion
A practical, repeatable workflow is: (1) inventory the device and identifiers (serial, probe types, units), (2) check power source and battery status, (3) confirm on-site connectivity (LoRaWAN: placement/gateway; NB-IoT: operator/subscription), (4) confirm payload decoding into correct units, (5) validate data freshness and time synchronization, and only then (6) enable alerts. The goal is not perfection; it’s to remove unknowns quickly so you can trust what you see.
What you observe in the first 48 hours: gaps in data, jumps, frozen values, or time offsets. Verify independently with a simple field log (when you irrigated, ventilated, or had rainfall) plus a manual measurement at one point. Practical decision: if you see inconsistencies, stop escalating (don’t change irrigation “because the graph said so”) and treat it as an instrumentation problem—placement, calibration, decoding, or network. Confirm with a week of stable data where known events show up logically. At that point, you can bring the stream into GrowGuard for monitoring and zone-based alerts without assuming the platform automatically “fixes” field errors.
8) Failure cases and how to separate them: sensor, network, interpretation
Three failures are easy to confuse. (A) Sensor drift/fault: values slowly move into nonsense or get stuck. (B) Network trouble: entire reporting intervals are missing, then data returns. (C) Interpretation problems: wrong units, wrong scaling factor, inverted sign, or swapped channels (temperature decoded as humidity). A correct diagnostic approach starts with “does the measurement make physical sense?” and only then asks “did the message arrive?”. That order prevents chasing coverage when the real issue is decoding.
What you may observe: a soil moisture sensor that “jumps” to the exact same value daily could indicate repeated transmission (retained/duplicate) or incorrect quantization, not identical irrigation. Verify independently by comparing against a real event—hypothetically, a small manual watering in a limited area—and checking whether the sensor responds with the expected delay for that sensor type and depth. Practical decision: change only one variable at a time (placement or decoding or interval), otherwise you won’t know what fixed it. Confirm via an A/B check: a reference sensor or reference location on the same technology in the same period.
Conclusion
LoRaWAN solves radio transport through gateways and a network server, NB-IoT solves transport through the operator, and MQTT solves message flow between systems. As a grower or farm operator, you gain most by treating them as a verifiable chain: correct measurement, correct payload decoding, confirmed freshness, then farm-specific thresholds and alerts. This reduces the risk of decisions made on stale or misinterpreted data.
Once the flow is stable, you can use GrowGuard as a single place to view and alert on the data, while keeping the same verification discipline: units, measurement medium, time, and the crop’s response to events. If you want a low-risk start, pick one critical point (for example, one microclimate sensor and one water/root-zone sensor) and run the commissioning workflow before scaling across the farm.