Over‑irrigation and under‑irrigation in greenhouses often happen not because you lack a schedule, but because you lack confirmation that water actually moved. A valve “open” command can be received, partially executed, or fail mechanically—and you may discover it only after plants show stress. The robust solution is not just connectivity but a full loop: command, flow confirmation, and deviation alerts.
When you combine MQTT, LoRaWAN, and NB‑IoT, the key is to avoid mixing their roles. MQTT is an application messaging protocol, useful for commands and events; LoRaWAN and NB‑IoT are radio/cellular transport paths for devices in the field. If you treat QoS or “message delivered” as proof of irrigation, you’ll build a system that looks clean on dashboards yet still fails to prevent losses.
In practical deployments, LoRaWAN can cover many greenhouse points quickly with low power use, while NB‑IoT can be a backup—or a direct choice—where you want independence from a local gateway and you have solid operator coverage. Regardless of transport, real confirmation comes from instrumentation: a flow meter/water meter, pressure, and secondarily the zone response (substrate/soil moisture). Below are the technical steps and commissioning checks that matter.
1) Separate the three truths: command, transport, physical proof of irrigation
A correct mechanism starts with three different questions: “was a command sent?”, “did the command arrive?”, and “did water flow?”. MQTT answers the first two well through publish/subscribe topics and delivery levels, but it cannot prove water movement. LoRaWAN/NB‑IoT answer “how do I transport messages and data over radio/cellular?”, yet they also confirm communication, not hydraulic action. Physical proof comes from measuring flow or the volume that passed through the controlled branch.
What you observe in practice: an open command can be followed by zero flow (clogged filter, pump stopped, stuck valve), too little flow (insufficient pressure), or too much flow (valve stuck open, bypass, burst line). The minimum independent verification is a flow/volume indicator installed on the controlled line. Practical decision: don’t mark a cycle “successful” unless measured volume appears within a defined time window. Check the result by comparing confirmed volume to that zone’s own history—not only to the schedule.
2) MQTT in irrigation: topics, QoS, retained messages, and data freshness
MQTT is well suited as a shared “language” between a controller/PLC/gateway, an application, and automation components. Design separate topics for: command (for example open/close with a duration), state (valve reported open/closed), telemetry (flow, pressure, supply voltage), and alarms (deviations). Higher QoS can improve delivery probability, but it never replaces flow confirmation. If you use retained messages, treat them with age checks so an old command is not acted upon after reconnection.
What to watch during commissioning: the offset between the device-emitted timestamp and the reception time, plus event ordering. A classic failure is “new command, old telemetry”: your chart shows flow before the valve opened because of delays or a retained message. Independent verification: a local controller log with real time (RTC/NTP) and a sequence counter in messages. Practical decision: reject commands when system state is uncertain (for example telemetry older than your freshness threshold). Check results with repeatability tests: the same command under similar conditions should produce the same event sequence.
3) LoRaWAN for flow and status sensing: when it fits—and where it can fail
LoRaWAN is a radio network where gateways forward device data to a network server and then an application layer; from there, application data can be exposed via MQTT. In greenhouses it is useful for battery operation, coverage across large structures, and high sensor density—especially for telemetry (pulse flow, pressure, temperature). The main limitation is that downlink (commands to devices) is more constrained than uplink, and latency can vary; for that reason LoRaWAN is often safer for “confirmation and diagnostics” than for time‑critical valve commands.
What you may observe: if you try to command a valve directly over LoRaWAN, opening can be delayed or commands can be missed due to receive windows, and state confirmation may arrive late. Independent verification: for LoRaWAN nodes, track link stability (missed messages, reporting intervals) and compare with a field test—same device, same position, should report consistently through a full day. Practical decision: keep the command local (for example in a controller with outputs) and use LoRaWAN for flow confirmation and alarms. Check the result by reducing cases where “valve open but zero flow” is detected only late.
4) NB‑IoT for valves and critical points: no gateway, but coverage rules
NB‑IoT is cellular: the device connects directly to the operator network, without a private gateway. In a greenhouse this can simplify projects when you don’t want to maintain local radio infrastructure or you have remote points (well/pump, tank, technical room). Success still depends on module band support, indoor operator coverage, and power‑saving settings (PSM/eDRX) that can introduce receive delays. For command paths, those delays must be handled explicitly in logic.
What you’ll see when it goes wrong: the device appears online but responds slowly to commands; it reconnects at certain hours; consumption is higher than expected when signal is weak. Independent verification: signal testing at the final mounting location and a session journal (when it connected and how fast it published telemetry after wake). Practical decision: use NB‑IoT where you need a direct path to cloud and can tolerate latency, and add local protection for critical commands (for example a valve fail‑safe behavior). Check success by measuring time from command to flow confirmation—not by “message received” alone.
5) Flow confirmation: choosing the sensor and interpreting units correctly
Confirmation that actually reduces over/under‑irrigation requires an instrument that measures something physical: flow rate (instant) or volume (cumulative). In practice you’ll see pulse flow sensors (Hall), water meters with pulse/Modbus outputs, or analog transmitters. What matters is defining units at design time: pulses per liter or pulses per cubic meter, flow in L/min or m³/h, and the integration period. A common mistake is comparing instantaneous flow to a volume threshold (or the reverse), generating nuisance alarms.
What you’ll observe on real lines: at cycle start there is a fill and stabilization phase; a threshold that is too strict in the first seconds will falsely report “no flow.” Independent verification: a hypothetical “bucket test” calibration, or at least reading a reference meter in the technical room to validate order of magnitude and pulse polarity. Practical decision: define a confirmation window (first X seconds to detect flow) and a minimum‑volume window to close the cycle as “complete.” Check results by correlating with root‑zone moisture: after a confirmed cycle, a moisture sensor should show the expected trend with a substrate‑specific delay.
6) Prevention logic: rules for “zero flow,” “too much flow,” and “abnormal duration”
A good loop doesn’t just confirm—it classifies failure. “Zero flow after command” suggests a water supply issue, valve/pump problem, or blockage. “Too much flow” can indicate a valve stuck open, hose rupture, open end, or unintended diversion. “Abnormal duration” appears when the command is short but flow continues (valve not closing) or when the command is long but flow stops (cavitation, empty tank). The mechanism is consistent: compare the measured flow profile against that zone’s expected profile.
What to observe and independently verify: for each zone, build a “signature” from 5–10 normal cycles (hypothetical) and note natural variability. Independent checks include first‑alert physical inspection: gauge reading, filter condition, line ends, actual manual valve positions. Practical decision: stop repeated cycles when you have confirmed failure (repeated zero flow) so you don’t compound stress by false expectations; if flow is too high, stop to limit flooding risk. Check effectiveness by fewer between‑zone discrepancies and fewer “after the fact” interventions.
7) Commissioning: scenario tests and protections against stale data
Commissioning an integrated irrigation loop is not just “the sensor appears in the platform.” Run scenario tests: normal valve open, valve commanded with water supply off (zero flow), flow meter disconnected (missing data), and a temporary network outage. For each scenario define what events must appear and in what order. Pay special attention to data freshness. A system can display the last valid flow and you may interpret it as current; therefore you need timestamps and an expiry rule.
What to independently verify: time synchronization across controller, gateway, and server (either NTP or a consistent source timestamp mechanism) and a clear stale‑data rule. Practical decision: if telemetry is older than your threshold, treat confirmation as “unknown” and require a manual check—or repeat a cycle only in controlled conditions. In GrowGuard, status/battery alerts and history can help you spot periods when data stopped being fresh, then adjust reporting intervals. Check results by eliminating contradictory situations (flow “confirmed” while the sensor is offline) and by keeping a coherent cycle journal.
8) Alerts that truly prevent: combine flow with zone moisture and operational context
Flow confirmation prevents “it didn’t water at all” and “it watered too much,” but it cannot alone prove water reached the root zone usefully. In greenhouses, distribution varies: clogged drippers on specific rows, pressure differences, different substrates. Useful alerts therefore combine: (1) irrigation event confirmed by flow/volume, (2) the zone response (substrate/soil moisture), and (3) context (air temperature/humidity, VPD estimated from air T/RH, schedule). Don’t confuse VPD with leaf temperature: leaves can be cooler or warmer than air.
What to observe: if volume is confirmed yet zone moisture doesn’t move in the expected direction, you likely have a distribution problem or poor sensor placement. Independent verification: inspect laterals, check dripper uniformity, and compare with a manual control point (pot weighing, tensiometer, or visual drainage check depending on your system). Practical decision: tune alert rules so “confirmed irrigation with no zone response” is a distinct incident from “unconfirmed irrigation.” In GrowGuard, LoRaWAN/NB‑IoT/MQTT integrations let you bring these signals into one zone‑based view, then validate after intervention whether the next cycles show a consistent response.
Conclusion
MQTT + LoRaWAN + NB‑IoT works well in greenhouses when each part has a single job: MQTT for events and commands, LoRaWAN/NB‑IoT for transporting field data, and flow/volume for physical proof. Real prevention of over/under‑irrigation comes from rules based on flow profiles, data freshness, and independent on‑site checks—not from assumptions about message delivery.
If you want to turn this logic into a consistent zone workflow with alerts that clearly separate “command,” “communication,” and “water delivered,” you can use GrowGuard as the monitoring and sensor-integration platform. For any actual automation, treat it as a separate project: scenario‑tested and validated with physical measurements.