IoT for Assam Tea Gardens: Soil, Weather and Pest Alerts on a Budget

For a small Assam tea garden, a useful IoT setup is a handful of solar-powered sensor nodes that log soil moisture, air temperature, humidity and rainfall, send the readings over GSM, and raise simple alerts: soil drying out, a long dry spell, a run of hot humid days. It won't spot pests by itself on a small budget, but it can tell the garden team when conditions favour an outbreak and which sections to scout first.

A note on where this comes from. I haven't deployed a system in a tea estate. What I have built is a garden automation system that combines a capacitive soil moisture sensor, a DHT22 temperature and humidity sensor, a rain sensor and a GSM/GPRS link to a web dashboard. The design below is how I'd scale that idea up for tea, with the parts I'm unsure about called out.

What a sensor network can and can't do

It helps to be honest about this up front, because "smart farming" pitches often promise more than the hardware can deliver.

The first three rows are where the value is. They're cheap, reliable and they replace guesswork with a record you can look back on.

The sensors I'd start with

Soil moisture at two depths. One probe near the surface and one deeper in the root zone tells you whether rain actually soaked in or just ran off. I'd use capacitive probes rather than the bare resistive kind, because resistive probes pass current through the soil and corrode over time.

Air temperature and humidity. In my garden build I used a DHT22. For a permanent outdoor node in Assam's monsoon I'd put whichever sensor I choose inside a ventilated radiation shield, so it reads air temperature and not the inside of a sun-baked box.

Rainfall. A rain sensor tells you "is it raining now". A tipping-bucket gauge tells you how much fell, which is what you need to spot a dry spell.

Soil pH, but not as a live sensor. Tea prefers acidic soil, and the commonly cited optimum is a pH of about 4.5 to 5.5. A 2022 study of 7,300 soil samples from 115 estates in the Dooars found only about 54% fell inside that range, so it's worth tracking. But low-cost pH probes drift and need regular calibration. I'd log manual or lab results into the same dashboard instead, so all the data sits in one place.

Pest alerts: prompting scouting, not detecting bugs

This is the part people usually want, so it deserves care.

Red spider mite is a good example of a pest whose risk follows the weather. Research on the pest in north-east India describes its severe season as March to June, practically disappearing with the monsoon rains, and the same work links prolonged dry weather early in the flushing season, and unshaded areas, to heavier attacks. A sensor network can't see mites, but it can notice that a section hasn't had meaningful rain in a set number of days during that window, and send a message: "Section 4, no significant rain for 12 days, check for red spider."

The tea mosquito bug is harder to tie to a single weather signal. Reports quote tea researchers linking heavy rain to conditions that help it multiply, but I couldn't find clear thresholds for Assam. For that pest I'd only log the data at first, and let the garden's own scouting records show whether any pattern is worth alerting on.

The rule I'd follow: the thresholds come from the garden's agronomist or Tocklai guidance, not from me. My job is to make the alert fire reliably and reach the right phone.

Getting data out of a garden with patchy signal

Tea sections can be far from the factory and mobile coverage varies. A few design choices make that manageable:

1. Store first, send later. Each node writes readings to flash and uploads in batches. If the network drops for a day, nothing is lost.
2. One gateway instead of a SIM in every node. Nodes in the far sections can talk to a single gateway over LoRa, and only the gateway needs GSM or Wi-Fi. LoRa in India uses the 865–867 MHz band, commonly described as licence-free for low-power devices. Many modules are sold as 868 MHz, so they must be set to stay inside the Indian band. Check the current WPC rules before you deploy.
3. Small payloads. Sending a compact message every half hour is cheap on data. I wrote up how I structure telemetry in MQTT telemetry best practices.
4. Sleep between readings. A node that wakes, reads, saves and sleeps can run on a small solar panel and battery. The details are in my note on ESP32 deep sleep and power optimisation.

Surviving Assam's weather

Hardware fails outdoors for boring reasons more often than clever ones:

• Moisture gets in. Use sealed enclosures, cable glands, and a small vent or desiccant so condensation doesn't pool inside.
• Heat builds up. A dark box in direct sun gets much hotter than the air. Light-coloured enclosures and shade help both the electronics and the readings.
• Cables get chewed or cut. Run them in conduit where you can, and keep the probe cable short.
• Updates need to happen without a site visit. If a threshold or a bug needs fixing, over-the-air updates save a trip to every node.

Keeping it on a small budget

I'm not going to quote prices here because component costs move and depend on quantities. The cost drivers are predictable though, and I covered them in what IoT hardware prototyping costs. For a tea garden, the main levers are:

• Fewer, well-placed nodes. One node per representative section (shaded and unshaded, slope and flat) tells you more than many nodes in similar spots.
• One connectivity bill. A LoRa gateway with one SIM is usually cheaper to run than a SIM in every node.
• A pilot before a rollout. Two or three nodes through one dry season and one monsoon will show what's worth expanding.
• An existing phone as the screen. Alerts by SMS or a simple web dashboard avoid paying for a custom app on day one.

What I'd do

If a tea garden asked me to start, I'd build what I already know works from my garden automation project and keep the scope tight:

1. Three nodes: one in a shaded section, one unshaded, one near the office as a reference and gateway.
2. Two-depth soil moisture, air temperature and humidity, and a rain gauge on at least one node.
3. Readings every 30 minutes, stored locally and uploaded in batches over GSM.
4. A simple dashboard plus SMS alerts for two things only: soil drying past a threshold, and a dry spell during the red spider season.
5. Soil pH and scouting results entered by hand into the same dashboard.

After one season you'd know whether the alerts matched what the scouts saw, which sections dry out first, and whether it's worth adding more nodes or a camera. That's a small, honest step, and it's the kind of thing a garden manager can judge on results rather than promises.

If you run a garden or estate in Assam and want to try a pilot like this, my IoT development page for Assam explains how I work, or you can get in touch.