Internet of Things Explained: Connecting the World

The Tank That Overflowed

Meera's family lives on the second floor of an apartment in Pune. Every morning, someone has to climb to the terrace, look inside the overhead water tank, and guess whether it needs filling. If the guess is wrong, one of two bad things happens: the tank overflows and water runs down the stairs for twenty minutes before anyone notices, or nobody fills it and the taps run dry by evening. The pump motor itself has no idea how much water is in the tank — it only knows "ON" and "OFF", and a human has to supply the missing information every single time.

Now imagine a small float sensor sitting inside that tank, wired to a coin-sized microcontroller. The sensor measures the water level every few seconds. When the level drops below a set mark, the microcontroller switches the pump relay on by itself. When the tank is full, it switches the pump off — and also sends a tiny message over Wi-Fi to a phone app, so Meera's family can see the tank's status from their kitchen without climbing any stairs. Nobody had to watch the tank. The tank watched itself, decided what to do, and reported back.

That shift — from objects that only do what a person tells them at that instant, to objects that sense their surroundings, make small decisions, and communicate those decisions over a network — is what this chapter is about. The umbrella name for this idea is the Internet of Things, usually shortened to IoT.

What Is the Internet of Things, Really?

A precise working definition: the Internet of Things is a network of physical objects — "things" — that are fitted with sensors, a small amount of embedded computing, and network connectivity, so that they can collect data about the physical world, exchange that data over a network, and often act on the world automatically, with little or no direct human command at the moment of action.

Notice what is doing the work in that sentence: physical objects. A laptop, a smartphone, or a cloud data-centre server is not, by itself, a "thing" in this sense — those are the general-purpose computers and the network backbone that make the internet what it is. The "things" in IoT are objects that were traditionally not computers at all: a water tank, a soil patch on a farm, a school bus, a wearable fitness band, a streetlight, a shipping container. IoT is what happens when engineers quietly slip a sensor, a tiny processor, and a radio into an ordinary object so that it can join the conversation that computers have been having with each other since the 1990s. The term itself was coined in 1999 by Kevin Ashton, a British technologist working on RFID (radio-frequency identification) tags for supply-chain tracking at MIT — he used it to argue that computers understood the world better when objects, not just people, fed them data directly.

The Sense – Think – Connect – Act Loop

Every IoT system, no matter how simple or advanced, repeats the same four-step loop. Learning to spot these four steps is the single most useful skill in this chapter, because it lets you analyse any IoT system you encounter, from a smart tank to a satellite.

• Sense — a sensor measures something physical: water level, soil moisture, temperature, motion, light, distance.
• Think — a small onboard processor (a microcontroller) compares the sensor reading against a rule or threshold and decides what should happen next.
• Connect — the decision, or the raw data, is transmitted over a network — Wi-Fi, Bluetooth, a mobile network, or another radio link — to another device, a home hub, or a cloud server.
• Act — something physical changes as a result: a pump switches on, an alert appears on a phone, a valve closes, a light turns on.

The loop then repeats, often every few seconds or minutes, for as long as the device is powered. The diagram below traces this loop using the water-tank example.

Notice the order in the diagram: after the microcontroller thinks, it can both act on the physical world (turn the pump on) and connect to report what happened — these two can happen together, and then the loop restarts from Sense a few seconds later.

Inside an IoT Device: Sensors, "Brains", and Actuators

To build any IoT device you need three kinds of hardware, and it helps to be able to name them precisely rather than lump everything together as "the gadget".

Sensors convert a physical quantity into an electrical signal a microcontroller can read. A resistive soil-moisture probe changes resistance depending on how wet the soil is. An ultrasonic distance sensor times how long a sound pulse takes to bounce off the water surface and return, and that time converts to a distance. A DHT11/DHT22 module reports temperature and humidity digitally. A PIR (passive infrared) sensor detects the heat pattern of a moving body. Each sensor answers exactly one question about the physical world, and answers it repeatedly.

The "brain" is a microcontroller — a very small, low-power computer built onto a single chip, with just enough memory to run one small program in an endless loop. Two families are common in school and hobbyist electronics: the Arduino Uno (built around the ATmega328 chip, no built-in wireless) and the ESP8266/ESP32 boards (made by the Chinese company Espressif Systems, with Wi-Fi built directly into the chip). A microcontroller is not a general-purpose computer — it does not run an operating system with multiple apps; it runs one program, forever, reading sensors and making decisions in a tight loop measured in milliseconds.

Actuators are the opposite of sensors: they convert an electrical signal back into physical action. A relay is an electrically-controlled switch strong enough to turn a pump motor or a home appliance on and off. A servo motor turns to an exact angle (useful for a valve or a small robotic arm). A buzzer or LED gives a simple alert. Every "Act" step in the loop runs through one of these.

How Things Talk: Choosing a Connection

The "Connect" step is not one single technology — it is a choice, and the choice always trades off range, power consumption, and how much data can be sent per second. Four connectivity options cover almost every real IoT device:

• Wi-Fi — good range within a building (tens of metres), high data rate, but power-hungry, which is why battery-only sensors rarely use it directly.
• Bluetooth / BLE (Bluetooth Low Energy) — short range (a few to about ten metres), very low power, ideal for a fitness band that only needs to sync with a nearby phone.
• Zigbee — low power, moderate range, and able to form a mesh, where each device relays messages for its neighbours so a signal can hop across an entire house or factory floor without needing a strong direct link to the hub.
• LoRa and NB-IoT — built for long range (LoRa can reach several kilometres in open terrain; NB-IoT rides on the existing mobile network) at very low data rates and very low power, which is exactly the combination a soil sensor on a large, remote farm needs: it only sends a few bytes every few minutes, but it needs to survive on a small battery for months and reach a receiver that may be a kilometre away.

Most home and farm IoT setups also use a gateway — a device that receives data over a short-range protocol like Zigbee or LoRa and forwards it onward over Wi-Fi or a mobile connection to the internet. The gateway is the bridge between the "local things" and "the internet" halves of the phrase Internet of Things.

The Four Layers of an IoT System

Zooming out from a single device to an entire IoT deployment, engineers describe four layers, and every example in this chapter can be sorted into them:

1. Perception layer — the sensors and actuators themselves, physically touching the real world (the float sensor and pump relay in the tank).
2. Network layer — the radios, gateways, and protocols that move data from the device to wherever it needs to go (Wi-Fi from the tank's microcontroller to the home router).
3. Processing layer — where the data is stored and analysed, and where more complex decisions are made. This can be on the device itself (edge processing, e.g. the microcontroller's own threshold check) or on a remote server (cloud processing, e.g. a server that logs a month of water-level history and predicts when the tank will next run dry).
4. Application layer — the dashboard, mobile app, or alert that a human actually sees and interacts with (the phone screen showing "Tank: 80% full").

Keep this four-layer picture in mind — it is exactly the model most CBSE Computer Science and Informatics Practices material uses when asking you to identify or label parts of an IoT system.

Worked Example 1: How Much Data Does a Sensor Really Send?

A common exam-style question asks you to reason about the trade-off between how often a sensor reports data and how much total data it produces. Let's work through it with numbers.

Suppose the tank's water-level sensor sends a small data packet once every 5 minutes, and each packet (device ID, water level, timestamp) is 20 bytes.

Step 1: readings per day. There are 24 × 60 = 1440 minutes in a day. If one reading is sent every T minutes, the number of readings per day is N = 1440 / T. With T = 5: N = 1440 / 5 = 288 readings per day.

Step 2: total data per day. Total data D = 20 bytes × N. D = 20 × 288 = 5760 bytes. Converting to kilobytes: 5760 / 1024 ≈ 5.6 KB per day.

Step 3: what if we sense more often? Suppose the family wants a reading every 1 minute instead of every 5. Then N = 1440 / 1 = 1440 readings per day, and D = 20 × 1440 = 28800 bytes ≈ 28.1 KB per day — exactly 5 times more data, because the interval became 5 times shorter. This is the general rule: data produced per day is inversely proportional to the sampling interval — halve the interval, and you double the data (and, for a battery-powered device, you also roughly double how often the radio has to switch on, which drains the battery faster). This is precisely why engineers choose the sensing interval carefully instead of just sensing "as often as possible" — a soil-moisture sensor on a farm, running on a small solar-charged battery, might only report once every 15 or 30 minutes, because soil moisture does not change fast enough to need second-by-second updates, and the battery cannot afford it.

Worked Example 2: Why a Farm Shouldn't Depend Only on the Cloud

Consider two designs for the same automatic irrigation system: soil-moisture sensor triggers a water pump.

Design A (cloud-decides): the sensor sends its reading to a distant cloud server, the server checks the threshold and decides, then sends the "turn pump on" command back down to the farm.

Design B (edge-decides): the local microcontroller at the farm checks the threshold itself and switches the pump immediately, only sending a status update to the cloud afterward, for record-keeping.

To see why this choice matters, estimate the round-trip time for each, using typical illustrative figures for a rural broadband link: suppose each one-way hop from the farm's gateway to a cloud data centre and back takes about 80 ms one-way (160 ms round trip), plus roughly 20 ms for the server to process the request. Design A's total decision time is then approximately 160 + 20 = 180 ms — almost a fifth of a second before the pump even receives its instruction. Design B's decision happens inside the same microcontroller that read the sensor, so the "network" hop is essentially internal circuitry, on the order of a few milliseconds.

For a pump, 180 ms versus 5 ms rarely matters on its own — irrigation is not a fast process. But the real-world problem is reliability, not speed: rural and field connectivity in many parts of India is patchy, and a mobile or satellite link can drop out for seconds, minutes, or occasionally hours. If Design A is the only way the pump can be told to turn on, then during any connectivity gap, the crop simply does not get watered, no matter how dry the soil becomes. Design B keeps working through the outage, because the decision never needed to leave the farm — it only needs the network later, to log what happened. This local-decision approach is called edge computing, and it is one of the most important practical ideas in real-world IoT design, especially anywhere connectivity cannot be guaranteed every second.

Two Things People Get Wrong About IoT

Misconception 1: "Any internet-connected app that turns a device on and off is IoT." A phone app that lets you switch a bulb on remotely is genuinely useful, and it is often marketed as a "smart" or "IoT" product. But look at it through the Sense-Think-Connect-Act loop: there is a Connect step (the app talks to the bulb over Wi-Fi) and an Act step (the bulb switches), but there is no Sense step and no real Think step — a person is still the one deciding, every single time, just like flipping a physical switch from a different room. This is remote control, not autonomy. It becomes true IoT only when a sensor is added — for example, an ambient-light or occupancy sensor that lets the bulb decide for itself, without waiting for a person to open the app at all. When you are asked in an exam to identify whether a system "is IoT", check specifically for the missing piece: is there a sensor feeding a decision, or is a human supplying every decision manually?

Misconception 2: "IoT devices must always be connected to the internet to function." Worked Example 2 already shows why this is false in practice: the pump's decision to turn on does not require reaching the cloud at all — only the record-keeping does. Many real IoT deployments are designed so that local sensing, deciding, and acting continue to work even when the internet link is down, and only sync accumulated data to the cloud once connectivity returns. The word "Internet" in "Internet of Things" describes the overall system of connected things, not a requirement that every single decision must round-trip through the public internet at the exact moment it is made.

IoT Around You in India

Automated soil-moisture irrigation, of the kind used in Worked Example 2, is already used in a number of Indian agri-tech pilots to cut water use on farms by watering only when the soil actually needs it, rather than on a fixed daily schedule. Indian Railways' train-tracking system relies on GPS devices fitted to locomotives that continuously report location data back to central servers, which is how apps showing "live train running status" know where a train actually is between stations — the locomotive is the sensing "thing", the GPS+cellular link is the Connect step, and the running-status display is the application layer. For positioning that does not depend on a foreign satellite system, ISRO operates NavIC (Navigation with Indian Constellation), a regional satellite navigation system that some Indian IoT and fleet-tracking devices use instead of, or alongside, GPS. Many state electricity boards have also been replacing old mechanical meters with automated smart meters that report usage readings back to the utility over a network, removing the need for a person to physically visit each house to read the meter. And in the background, the government's BharatNet project has been extending fibre broadband to village-level administrative units, because none of the connectivity layer described earlier in this chapter is of any use to a rural sensor if there is no network within reach of its gateway.

Reading the Code: A Soil-Moisture Irrigation Controller

Here is a simplified version of the kind of program that would actually run inside the microcontroller of Design B from Worked Example 2. It is written in the Arduino C-style language used on ESP8266/ESP32 and Arduino boards.

int moistureValue = analogRead(A0);   // read the soil sensor: 0 (very wet) to 1023 (bone dry)
int threshold = 600;                  // pump turns on when reading is above this

if (moistureValue > threshold) {
  digitalWrite(pumpRelayPin, HIGH);   // energise the relay -> pump turns ON
  Serial.println("Soil dry -> pump ON");
} else {
  digitalWrite(pumpRelayPin, LOW);    // de-energise the relay -> pump turns OFF
  Serial.println("Soil moist -> pump OFF");
}

Trace through it with two example readings, exactly as the processor would:

• If moistureValue = 725: the condition 725 > 600 is true, so the program runs the first branch. It writes HIGH to the relay pin, the pump switches on, and the serial monitor prints "Soil dry -> pump ON".
• If moistureValue = 400: the condition 400 > 600 is false, so the program runs the else branch. It writes LOW to the relay pin, the pump stays or switches off, and the serial monitor prints "Soil moist -> pump OFF".

This entire block re-runs inside the microcontroller's main loop every few seconds, forever — which is exactly the "Think" step of the Sense-Think-Connect-Act cycle, expressed as real code. A separate, occasional block of code (not shown here) would package the same moistureValue into a small message, such as {"device_id":"FARM01","moisture":725,"pump":"ON"}, and send it to a cloud server — that packaging and sending is the Connect step, kept deliberately separate from the urgent decision above it.

Check Your Understanding

1. A security guard watches a CCTV monitor and manually opens a gate when he recognises a car. A new system replaces him with a camera that recognises number plates and opens the gate automatically. Which of the four loop steps did the new system add that the old one was missing?
2. A soil sensor sends a 25-byte packet every 10 minutes. How many packets does it send per day, and how much total data is that, in bytes?
3. Why would a LoRa-based sensor be a better choice than Wi-Fi for a moisture sensor placed in the middle of a 2-hectare farm field, far from any router?
4. A student claims: "My smart speaker connects to Wi-Fi and plays music from the internet, so it's a good example of IoT." Using the Sense-Think-Connect-Act loop, explain what is missing from this claim (or defend it, if you think the loop is actually present).
5. Explain, in your own words, why an automatic irrigation controller should still be able to turn the pump on even if its internet connection is temporarily down.

Answers: (1) It added Sense (the camera reading the number plate) and Think (matching it against an allowed list) — Connect and Act (opening the gate) already existed as manual actions before. (2) 1440 / 10 = 144 packets per day; 144 × 25 = 3600 bytes per day. (3) LoRa is built for long range (kilometres) at very low power, which suits a sensor far from infrastructure and running on a small battery; Wi-Fi's range of only tens of metres and higher power draw make it unsuitable at that distance. (4) Largely missing: a smart speaker senses your voice command, which is closer to a Sense step, but if it is simply streaming music on request with no autonomous decision about the physical world, it is closer to remote control/on-demand computing than to the classic sensor-driven IoT loop; a stronger IoT example would be a speaker that also senses room occupancy and auto-adjusts something physical without being asked. (5) Because if the pump's decision depends on reaching a distant server first, any network outage — common in many rural areas — means the crop does not get watered exactly when it needs it; keeping the decision local (edge computing) means watering continues even during outages, and only the record-keeping is delayed.

Summary

• The Internet of Things is physical objects — not laptops or servers — fitted with sensors, a small processor, and network connectivity, so they can sense, decide, and act with little direct human input at the moment of action.
• Every IoT system repeats a Sense → Think → Connect → Act loop; you can classify any real system by checking which of these four steps it actually contains.
• Devices are built from three hardware parts: sensors (measure the world), a microcontroller (decides), and actuators (change the world).
• Connectivity choices — Wi-Fi, Bluetooth/BLE, Zigbee, LoRa, NB-IoT — trade off range, power, and data rate; there is no single "best" one.
• A full IoT deployment is described in four layers: perception, network, processing (edge or cloud), and application.
• Sampling more often produces proportionally more data and drains batteries faster; edge computing keeps critical decisions working even when the network connection to the cloud is unreliable.
• Two common mistakes: assuming any remote-controlled gadget is "true" IoT even without a sensing/decision loop, and assuming every IoT decision must round-trip through the internet at the moment it happens.