Smart agriculture IoT means putting sensors and actuators in fields, greenhouses and barns so decisions about water, climate and animals are based on measurements rather than guesswork. This guide explains which sensors are worth deploying, how to connect sites with no Wi-Fi or mains power, how to design one MQTT topic structure for the whole farm, and how to keep the system reliable through a full growing season.
What Smart Agriculture IoT Actually Measures
Farms are varied, but the useful measurements fall into a handful of groups. Start with the one that answers your most expensive question, usually water, and add the others once the data path works.
| Area | Typical sensors | Decisions it supports |
|---|---|---|
| Soil | Capacitive or TDR moisture, soil temperature, EC (salinity) | When and how long to irrigate, fertiliser timing |
| Weather | Air temperature, humidity, rain gauge, wind, solar radiation, leaf wetness | Frost warnings, spray windows, evapotranspiration estimates |
| Irrigation | Flow meters, pressure sensors, valve position, pump current | Leak detection, confirming water was actually delivered |
| Protected cropping | Greenhouse climate, CO2, light | Ventilation, heating, misting, shading |
| Livestock | Water trough level, barn climate, GPS collars, feed bin level | Animal welfare, theft and escape alerts, refill scheduling |
| Storage | Grain bin temperature and humidity, cold room temperature | Spoilage prevention |
A common mistake is buying a large sensor kit before deciding what action each reading will trigger. A soil moisture value that nobody acts on is just a graph. Write down the decision first, then the measurement and the sampling interval it needs.
Placement matters as much as the sensor itself. One soil probe per field tells you little if the field has sandy and clay patches; one probe per irrigation zone, placed in a representative spot at root depth, is a better starting rule. Weather stations need open ground away from buildings and trees, and barn sensors should sit at animal height rather than near the roof.
Connectivity Without Wi-Fi
Fields are rarely covered by Wi-Fi, and running cables across them is impractical. The choice of radio shapes battery life, cost and what payloads you can send.
| Option | Range | Power | Best for |
|---|---|---|---|
| Wi-Fi | Tens of metres | High | Greenhouses, barns, near buildings |
| LoRaWAN | Several kilometres in open terrain | Very low | Field sensors sending small readings every few minutes |
| NB-IoT / LTE-M | Wherever the operator has coverage | Low to moderate | Remote sites with no gateway, mobile assets |
| Cellular (4G) router | Operator coverage | High (mains or large solar) | Pump houses, gateways, cameras |
For most farms the pattern that works is a mix: Wi-Fi or Ethernet inside buildings, LoRaWAN for battery-powered field sensors, and a cellular router at the gateway if the farm has no fixed internet. LoRaWAN payloads are tiny (tens of bytes), so devices send compact binary data that a network server decodes into JSON.
One Broker for the Whole Farm
Whatever the radio, the data should end up in one place where every tool can use it. MQTT fits this role well: devices or gateways publish, and dashboards, irrigation controllers, alerting and storage subscribe independently. Adding a new consumer never requires touching a sensor.
Field sensors --LoRaWAN--> Gateway --> TTN / ChirpStack --+
Greenhouse ESP32 --Wi-Fi/TLS---------------------------+ |
Pump controller --4G router---------------------------+| |
vvv v
MQTT broker (cloud)
| | |
Node-RED logic Dashboard Python logger
LoRaWAN network servers expose their own MQTT interfaces. A small bridge subscribes there and republishes decoded readings into your farm's topic tree, as shown in the The Things Network MQTT and ChirpStack tutorials. Wi-Fi devices such as an ESP32 in a greenhouse publish to the broker directly.
Running that broker yourself on a farm PC means it dies when the power does, and remote access requires port forwarding. A cloud MQTT broker is reachable from every field, every phone and every contractor without opening the farm network.
Designing Topics for a Farm
A consistent hierarchy makes wildcards useful and keeps the system understandable years later. A pattern that works:
<farm>/<site>/<zone>/<device>/<kind>
greenfield/north/field3/soil-07/telemetry
greenfield/north/field3/soil-07/status
greenfield/north/field3/valve-02/set
greenfield/north/field3/valve-02/state
greenfield/barn/climate/th-01/telemetry
greenfield/barn/trough-2/level-01/telemetry
With that structure, greenfield/north/+/+/telemetry gives you every sensor on the north site, and greenfield/+/+/+/status gives you every device's online state. Keep payloads in JSON with units in the field names or a fixed schema:
{
"ts": "2026-10-16T06:15:00Z",
"moisture_pct": 31.5,
"soil_temp_c": 14.2,
"battery_v": 3.71,
"rssi": -112
}
Including battery voltage and radio signal strength in every message costs a few bytes and saves hours of field visits, because you can see a failing sensor before it stops reporting. Publish a retained status message with a last will of offline from every connected device, so dashboards know immediately which ones disappeared.
If you think in terms of enterprise, site, area and asset, this is the same idea as an ISA-95 hierarchy, and ConnectMQ's devices view groups topics by those levels automatically.
A Minimal Aggregator in Python
Once data flows, the first useful consumer is often a simple subscriber that flags stale or out-of-range sensors. This example uses the public test broker with a unique prefix so you can try it immediately.
import json
import time
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/f7q2m1/farm"
STALE_AFTER_S = 3 * 3600
last_seen = {}
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.subscribe(f"{PREFIX}/+/+/+/telemetry", qos=1)
def on_message(client, userdata, msg):
device = "/".join(msg.topic.split("/")[4:7])
last_seen[device] = time.time()
try:
data = json.loads(msg.payload)
except ValueError:
print("bad payload from", device)
return
if data.get("battery_v", 4.0) < 3.4:
print(f"LOW BATTERY {device}: {data['battery_v']} V")
if data.get("moisture_pct", 50) < 20:
print(f"DRY SOIL {device}: {data['moisture_pct']} %")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="farm-agg-f7q2m1")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()
while True:
now = time.time()
for device, ts in list(last_seen.items()):
if now - ts > STALE_AFTER_S:
print(f"STALE {device}: no data for {int((now - ts) / 60)} min")
time.sleep(300)
Publish a test reading with mosquitto_pub -h broker.connectmq.com -p 1883 -i t-f7q2m1 -t 'connectmq/demo/f7q2m1/farm/north/field3/soil-07/telemetry' -m '{"moisture_pct":18,"battery_v":3.3}' and both warnings print.
Power and Enclosures
Field hardware lives in rain, dust, heat and frost. Practical lessons that apply to almost every deployment:
- Budget power first. A sensor that sleeps between readings and transmits over LoRaWAN can run for a long time on batteries; a Wi-Fi device that stays connected cannot. Small solar panels with a charge controller suit gateways and controllers.
- Use rated enclosures and cable glands. Condensation inside a box kills more electronics than rain outside it. Add a breathable vent and desiccant.
- Mount above crop height and away from machinery paths. Tractors and mowers are a real hazard to cables and stakes.
- Label every device with its ID and topic, so whoever finds it in the field knows what it is.
- Plan for the off-season. Retrieve or winterise sensors that are not needed, and record calibration values before removal.
Security and Data Ownership
Farm data reveals yields, practices and when nobody is on site. Encrypt every connection that leaves the farm with TLS, use separate credentials per gateway or controller, and never publish real data to a public test area. Actuators deserve the most care: anyone who can publish to a valve's set topic can open it. The MQTT security best practices guide covers the essentials, and a managed MQTT broker takes care of TLS certificates, authentication and keeping the broker patched.
Where to Start
Start small: one soil sensor, one weather reading, one broker and one dashboard. The soil moisture sensor MQTT build is a good first device, and once readings are trustworthy, the automatic irrigation system tutorial closes the loop by driving valves. For broader patterns across homes, buildings and farms, the IoT automation guide ties everything together.
Build Your Farm Network on ConnectMQ
ConnectMQ gives your farm a private MQTT broker with TLS, generated credentials, a live topic explorer, a dashboard and threshold alert rules for critical values like frost or dry soil. Create a free Serverless broker at app.connectmq.com, no credit card required, and connect your first field sensor today.
Frequently Asked Questions
Is LoRaWAN or Wi-Fi better for smart agriculture IoT?
LoRaWAN for battery-powered sensors spread across fields, Wi-Fi for devices inside or close to buildings. Many farms use both, joined at the MQTT broker.
How often should farm sensors report?
Soil moisture changes slowly, so every 15 to 60 minutes is usually enough. Frost and greenhouse climate warrant faster updates, every one to five minutes.
Do I need a server on the farm?
Not necessarily. Gateways and controllers can publish straight to a cloud broker over cellular or fixed internet, and logic can run in Node-RED or Python wherever is convenient.
Can MQTT work over unreliable rural connections?
Yes. MQTT is lightweight, supports persistent sessions and QoS 1 redelivery, and clients reconnect automatically, which suits patchy cellular links.



