From Web to IoT: Scope, Architecture and Hardware Choice

In Project II the data came from people typing into forms. In Project III the data comes from the physical world: a probe in the soil, a temperature sensor on a pole. This adds a new kind of trouble.

Sensors are noisy, batteries run out, Wi-Fi drops in the hills, and a wrong reading can make a farmer waste water or lose a crop. This unit shows what changes, how to state the problem with numbers, and how to choose the hardware.

1.1 What changes in Project III

A system that senses and acts is judged on more than a working screen. Five things change.

Because of these changes, the Project III report needs a hardware chapter, a data-quality chapter and an offline behaviour section.

Examiners ask "what does the app show when the sensor stops sending?" and "how do you know the sensor is accurate?". Units 2 to 4 prepare those answers.

1.2 The running example: KhetSense

KhetSense is invented for this book. A cooperative of 40 farmers in a hill village grows tomato and cucumber on terraces. Farmers water by habit: every morning, whether or not the soil is dry.

Problem statement, version 1. "Forty farmers of a hill cooperative irrigate every morning by habit.

Measurements on 12 test plots show that on 4 of 10 days the soil was already wet enough, so about 35 percent of the water is wasted, and the water tank is empty by April.

Without a better rule, the shortage worsens as the plots are extended."

Objectives (SMART).

Scope table.

Notice objective O2. It is a measurable accuracy target. A project that only says "the sensor works" cannot be examined; one that says "mean error 2.1 points over 10 samples" can.

1.3 The four-layer IoT architecture

Almost every IoT project has the same four layers, and each layer solves one problem.

1. Sense layer: sensors that turn a physical quantity (moisture, temperature, humidity) into a voltage or digital value.
2. Edge layer: a small board (ESP32, Arduino, Raspberry Pi) that reads the sensor, filters noise, packs a message and sends it. It runs on a battery.
3. Cloud (server) layer: a broker that receives messages and a database that stores them; analysis code runs here.
4. Application layer: the phone app or web page that shows values and advice to the farmer.

Figure 1.1 also shows where each risk lives. The probe can drift, the node can run out of battery, the Wi-Fi link can drop, and the phone can be offline. A good Project III names the failure of each arrow and says what the system does about it.

(a) ESP32 development board

(b) Raspberry Pi 4 gateway

(c) Arduino Uno clone

1.4 Choosing the sensors and the board

Choose hardware from the requirements, not from what looks exciting. Plate 1.2 shows the sensing and watering side of KhetSense.

(a) Resistive soil probe

(b) DHT22 temperature and humidity sensor

(c) Drip emitter

The following script prices both versions of the kit against objective O5. The prices are rough, invented orders of magnitude.

items = {  # name: (price in Rs, v1 qty, v2 qty)
    "ESP32 board": (1200, 7, 7),
    "Capacitive soil probe": (350, 6, 6),
    "DHT22 sensor": (700, 7, 1),
    "18650 cell + holder": (600, 7, 7),
    "1 W solar panel": (500, 7, 7),
    "Weatherproof box": (400, 7, 7),
    "Raspberry Pi 4 gateway": (9000, 1, 0),
    "Pi Zero 2 class gateway": (5000, 0, 1),
}
BUDGET = 30000
for v in (1, 2):
    total = sum(price * qty[v - 1] for price, *qty in items.values())
    verdict = "within" if total <= BUDGET else "OVER"
    print(f"Version {v}: Rs {total:,}  ->  {verdict} budget of Rs {BUDGET:,}  (margin {BUDGET - total:+,})")

Version 1: Rs 34,900  ->  OVER budget of Rs 30,000  (margin -4,900)
Version 2: Rs 26,700  ->  within budget of Rs 30,000  (margin +3,300)

Version 1 fails objective O5, so the team revises it. This is normal: a project plan is a series of measured revisions, and the report should show both versions and the reason for each change.

1.5 Requirements as user stories and measurable checks

Write each need as a user story and give it a check that can be shown in the demo.

1.6 Eight reasons sensor projects fail, and the cure

1. The sensor was never calibrated. The team trusts the raw number from the datasheet. Compare the sensor with a reference (oven-dry sample, lab thermometer) at several points and fit a line, as in Unit 2.
2. The battery dies in a week. The node stays awake and sends every few seconds. Sleep between readings, send in batches, and calculate the battery life before buying, as in Section 2.5.
3. No plan for a missing reading. The chart shows a flat line or zero when Wi-Fi drops. Mark gaps as missing, never as zero, and store a timestamp with every reading.
4. Noise is mistaken for events. A single spike triggers an irrigation alert. Use a median or moving average and a rule that needs two consecutive high readings.
5. Hardware not protected from the weather. Electronics get wet in the first monsoon night. Use a sealed box, cable glands, a drip loop on the cable and a silica-gel pack.
6. The phone app needs the internet for everything. In the field there is no signal and the screen is blank. Keep a local cache and sync later, as in Unit 4.
7. Clock errors. Nodes without a real-time clock stamp readings wrongly, so the series is out of order. Let the server add its own receive time and keep the node's tick count as a second field.
8. Testing only on the desk. Everything works on the table and fails on the terrace because of distance, rain and sunlight. Run a field test of at least 48 hours and report the result honestly (Unit 5).

(a) A LoRa radio module, the long-range link for a sensor node far from the Wi-Fi router

(b) LoRa link budget: how far can a node reach?

Formula and fact sheet

• Four layers: sense, edge, cloud, application. Each arrow can fail.
• Accuracy target = mean absolute error over paired readings (sensor against reference).
• Budget check: total = sum of (unit price × quantity); keep a margin of at least 5 to 10 percent.
• Missing is not zero: store gaps as missing, with a timestamp.
• ESP32: Wi-Fi + Bluetooth, deep sleep; Arduino Uno: no network; Raspberry Pi: full Linux gateway.

Practice

1. List the five concerns that change when a web project becomes a sensor project.
2. Write a four-part problem statement for a project that monitors water level in a village tank.
3. Name the four layers of KhetSense and one failure of each.
4. Why is "the sensor works" a weak objective? Rewrite it as a measurable one.
5. Why is a resistive soil probe a poor choice for a one-year project?
6. State two differences between an ESP32 and an Arduino Uno.
7. Why should a missing reading never be stored as zero?
8. Why does the budget script report version 1 as over budget? Give the cost difference between the two gateways.
9. Rank four user stories of a tank-level monitor with MoSCoW.
10. Version 2 costs Rs 26,700 and the budget is Rs 30,000. What percentage of the budget is the margin?

Model answers: medium (5 marks) and long (10 marks) questions

Q1 (5 marks). Explain the four-layer architecture of an IoT system with a diagram reference and an example.

Introduction. An IoT (Internet of Things) system connects physical sensors to software through four layers, each solving one problem. Separating them lets each part be built, tested and replaced on its own.

The layers.

1. Sense layer. Sensors convert a physical quantity into an electrical signal, such as a voltage from a soil probe or a digital value from a DHT22.
2. Edge layer. A small board such as the ESP32 reads the sensor through an analogue-to-digital converter, filters noise, packs a short JSON message and sleeps to save battery.
3. Cloud layer. A broker receives the messages and a database stores them; analysis code finds anomalies and makes forecasts.
4. Application layer. A phone app or web page shows values and advice and keeps a local cache for offline use.

Example and figure. In Figure 1.1 a KhetSense node reads moisture every 15 minutes and sends it over Wi-Fi to the gateway; the server stores it and the Android app asks the REST API for the latest value.

Why use it. (i) Each layer can be tested separately. (ii) Only the edge layer needs low-power code. (iii) The same cloud data can feed many apps.

Conclusion. The four-layer view gives the examiner a map of the system and tells the student where to place each failure and each security control.

Q2 (5 marks). Compare ESP32, Arduino Uno and Raspberry Pi for use as a battery-powered sensor node. Which would you choose and why?

Introduction. The three boards are all popular in student projects, but they are designed for different jobs. The right choice depends on networking, power use, cost and the amount of computing needed.

Choice. For a battery node, the ESP32: it has built-in Wi-Fi, sleeps at very low current and costs little. The Uno cannot send data without an extra module, and the Pi uses too much power for a solar node but is suitable as the gateway.

Conclusion. Match the board to the layer: ESP32 at the edge, Raspberry Pi class device at the gateway.

Q3 (10 marks). Describe how you would plan an IoT and mobile-app project from problem to architecture. Use a soil-moisture monitor as an example and discuss requirements, hardware, data quality, power, connectivity and risks.

Introduction. An IoT project joins hardware, networking, data and a mobile app, so planning must cover all four layers. The example is KhetSense, a soil-moisture monitor for a hill cooperative that wastes about 35 percent of its irrigation water.

1. Problem and objectives. Write a four-part problem statement (who, what, how big, what if nothing changes) and measurable objectives: read every 15 minutes, error at most 3 points, 30-day battery life, offline app, kit under Rs 30,000.

2. Architecture. Draw the four layers (Figure 1.1): sensors, ESP32 node, gateway and server, Android app. Mark every arrow as a possible failure.

3. Hardware choice. Select parts from requirements: capacitive probe for lasting accuracy, DHT22 for air readings, ESP32 for Wi-Fi and sleep, solar-charged 18650 cell. Check the total with a bill of materials; version 1 cost Rs 34,900 and was revised to Rs 26,700.

4. Data quality. Calibrate against an oven-dry reference, filter noise with a median or moving average, and store gaps as missing with a timestamp.

5. Power and connectivity. Sleep between readings, send batches, and calculate battery life before buying. Plan for the network to drop: the node buffers and the app caches.

6. Risks and testing. Weather, corrosion, clock errors and desk-only testing are the usual causes of failure; plan a 48-hour field test.

Conclusion. A well-planned IoT project states measurable targets, chooses hardware by numbers, and designs for noise, gaps and outages from the first day.