In a modern greenhouse, the problem is rarely a lack of sensors. It’s that data and automation come from different sources: weather stations, ventilation controllers, dosing systems, loggers, gateways. MQTT is one of the most used integration “languages” between these devices because it can quickly move events and measurements to a broker and then to applications that consume them.
To connect a greenhouse correctly to a monitoring platform, you must separate three things: measurement (which instrument, and in what medium it measures), transport (how messages arrive, how fresh they are, what happens during outages), and action (who actually drives a relay, a valve, or a vent motor). MQTT solves transport and signaling, not “truth” on the ground.
This article explains MQTT fundamentals that matter in greenhouses and a usable commissioning workflow: how to choose topics, payload and units, how to use QoS and retained messages, what security is the minimum for production, and which independent checks help you distinguish a real issue (for example, high humidity) from an integration issue (wrong timestamp, stuck sensor, repeated message).
1) What MQTT is in practice: broker, topics, and role separation
MQTT is a publish/subscribe protocol: devices publish messages to topics, and consumers subscribe to the topics they need via a broker. In a greenhouse, that means a temperature node can publish periodically, a controller can publish vent position, and an integrator can publish “commands” toward a PLC. The key mechanism: the broker routes messages, but it does not validate what they mean agronomically or operationally.
What to observe: topic consistency and consistent meaning. Verify independently: write down, on-site, which sensor is physically where and compare it with the topic and identifier in the message; a labeling mistake creates wrong decisions even if data “flows.” Practical decision: define from day one who publishes measurements and who publishes commands to avoid loops. Result check: ensure the same event appears once in the system, not duplicated from two sources.
2) Topic design: hierarchy, zones, and operational clarity
In greenhouses, topics should be stable and readable: a hierarchy like farm/greenhouse/zone/device/medium/quantity reduces confusion. A hypothetical example: “farm1/gh2/zoneA/sensor7/air/temperature” versus “temp1”. Include the measured medium (air, substrate, water) and the quantity (temperature, rh, co2, ec, ph). A temperature sensor does not measure EC/pH; EC/pH require dedicated probes, and you should clarify whether EC is measured in drainage water, irrigation solution, or a substrate extract.
What to observe: whether the topic helps you localize the value physically and agronomically. Verify independently: make a simple zone map and spot-check two points (for example zone A and B) with a handheld instrument to confirm the topic mapping is correct. Practical decision: if you have distinct microclimates, keep zone-level topics rather than aggregated ones. Result check: after one day, compare trends across zones; differences should make sense (shading, ventilation, end bays).
3) Payload and units: JSON, required fields, and controlled conversions
MQTT does not impose a payload format; for integration, it must be explicit. Commonly, JSON is used with clear fields: value, unit, timestamp, quality. A hypothetical example: {"v": 24.6, "u":"°C", "ts":"2026-09-12T10:21:00Z", "q":"ok"}. For relative humidity, state %; for CO2, ppm; for EC, state the unit (for example mS/cm) and the measurement medium (drain water versus solution). For VPD, remember it is an estimate derived from air temperature and RH; leaf temperature can differ, especially in sun or under water stress.
What to observe: sudden changes that look like “unit jumps” (for example °C becoming °F). Verify independently: take 2–3 raw payload values and manually compute a conversion or compare with a second instrument. Practical decision: standardize units at the source (the publisher), not in three different downstream places. Result check: run 24 hours and scan for “plateaus” or saw-tooth artifacts that indicate rounding, resampling, or wrong mapping.
4) QoS, duplicates, and why delivery does not mean physical action
MQTT QoS levels describe delivery guarantees between client and broker, not confirmation of a physical action in the greenhouse. Even if transport is configured for “exactly once,” that does not mean a valve opened or a pump started; you must confirm that separately using a state/feedback signal from the actuator controller or PLC. Also, certain reconnect scenarios can generate duplicate messages, and consumers must be tolerant of repeats.
What to observe: whether reconnecting produces bursts of old or repeated messages. Verify independently: inspect broker logs and a sequence counter (if included in the payload) to detect duplication. Practical decision: for commands, always design a separate “status” channel published by the equipment that executes the action. Result check: after a hypothetical “open vent” command, confirm the reported state (for example opening percentage) changes and remains stable—rather than only proving that “a message was sent.”
5) Retained messages and data freshness: avoiding decisions on “aged” values
Retained messages make the broker store the last message on a topic and immediately send it to new subscribers. In greenhouses this is useful for “last known state,” but risky if you do not check data age: a client can start and instantly receive an old temperature that looks valid. That is why timestamp and a freshness rule are essential: any consumer that triggers alerts or actions must verify that ts is recent and coherent with current time.
What to observe: values that seem “frozen” (no variation) without a sensor alarm. Verify independently: compare ts in the payload against a reference clock, and validate in the greenhouse that the environment actually changed (for example, open a door briefly and a change should be visible). Practical decision: define “data stale” thresholds and treat them as an integration incident, not greenhouse reality. Result check: simulate a network interruption and confirm that, on recovery, the system does not act on old retained values.
6) Security and authentication: the minimum that matters in production
In production, treat MQTT as critical infrastructure: authentication and transport security are not optional. An exposed broker or an uncontrolled client can publish into command topics and create unsafe behavior. Even for monitoring-only, falsified data can trigger unnecessary alerts and wrong decisions. Configure separate users for publish and subscribe, restrict permissions by topic, and use secure transport where the architecture allows.
What to observe: new, unplanned topics appearing, or messages with unexpected structures. Verify independently: perform a permissions audit on the broker and keep an “allow list” of accepted topics. Practical decision: clearly separate test versus production environments and do not reuse credentials across sites. Result check: after rotating a password, confirm only the expected clients reconnect and there are no anonymous publications.
7) A 10-step commissioning workflow: from sensor to an operational dashboard
A usable commissioning workflow starts with an inventory: which quantities you measure, with which probe, and in which medium. Then: (1) define topics and units; (2) configure broker and permissions; (3) publish from a single “pilot” sensor; (4) verify timestamp, units, fields; (5) verify on-site with an independent instrument; (6) only then scale to the rest. If you integrate into GrowGuard via MQTT, treat payload interpretation as a separate step from physical sensor installation.
What to observe: gaps between “what you think you connected” and what actually appears as a data stream. Verify independently: for each sensor type, run a simple stimulation test: gentle warming for temperature, breathing/ventilation changes for CO2, controlled humidification for humidity (without damaging equipment). Practical decision: do not enable alerts until you have at least 24–48 hours of coherent data and a cross-check. Result check: after enabling, confirm alerts correlate with real events (vents opened, irrigation started), not resets or reconnect bursts.
8) Automation via MQTT: commands, interlocks, and confirmation by feedback
Connecting automation through MQTT is usually a separate integration project: a controller/PLC receives commands (a “setpoint” or “request” topic) and publishes states (a “status” topic). The correct mechanism is “request + confirmation”: the command is not truth; truth is the state reported by the device that executed. In greenhouses, interlocks are critical: ventilation may depend on wind, temperature, screen position, and a simple command can be refused by the PLC for safety reasons.
What to observe: commands that are accepted as messages but produce no state change, or states that oscillate (a control loop). Verify independently: physically check the actuator (position, current draw, local indicator) and compare with the published status. Practical decision: define timeouts and “fault” states (for example command sent but no confirmation). Result check: after a hypothetical action, validate the expected climate effect (temperature/RH/VPD) and confirm the change is explained by the action, not weather or another system.
Conclusion
MQTT can unify greenhouse sensors and automation into a coherent architecture, but result quality depends on discipline: clear topics, payloads with units and timestamps, freshness rules, security, and—most importantly—separating “message delivered” from “action executed.” Good commissioning is something you can verify on-site, not only in charts.
If you want to use data in daily operations, build the integration so every alert or command has an independent check and a way to confirm the outcome. For MQTT integration projects with GrowGuard, start with one pilot sensor and expand only after the data flow, meaning, and feedback signals are stable.