A Cost-Effective IoT Smart Irrigation Node with Soil-Moisture-Triggered Watering and Cloud Reporting

Abstract

This paper reports the design of a low-cost Internet-of-Things irrigation node intended for smallholder use, in which a soil moisture probe and a temperature and humidity sensor feed an ESP8266 microcontroller that switches water only when the soil requires it and publishes every channel to an Adafruit IO cloud channel that the farmer can open in a browser. The stated aim of the project is to irrigate only on demand and to compare the resulting water use across three soil types, being sand, clay and sandy clay, against traditional practice. This paper formalises the soil-water, triggering and water-accounting relations that such a comparison rests on, and then examines what the comparison requires. Two findings follow, and both are quantitative. First, the published water-retention bands for these three textures do not overlap in the way a single firmware threshold assumes: sand reaches field capacity between about 0.10 and 0.18 cubic metres per cubic metre while clay does not reach its permanent wilting point until about 0.25 to 0.30, so a soil reading of 0.20 is above field capacity for sand and below wilting point for clay. A single threshold applied to all three soils therefore triggers at a different plant-water state in each, and the resulting water use differs for that reason before any property of the controller is considered. Second, a soil moisture probe of this class outputs an uncalibrated analogue count rather than a volumetric water content, and the calibration relating the two is itself soil-specific, so the three-soil comparison depends on exactly the calibration that such builds ordinarily omit. A percentage water saving additionally requires both a metered delivered volume and a defined baseline practice, and the component set described contains no flow measurement. The paper computes the per-event refill depth each soil requires, specifies the three additions that would make the comparison valid, and states clearly that it was prepared from the project abstract alone, so every status entry is marked for confirmation against the full record rather than asserted.