From Sensor to Cloud: How IoT Really Works, Explained for Students

IoT works by carrying one measurement through a fixed chain: a sensor turns something physical into an electrical signal, a microcontroller reads that signal and decides what matters, a radio carries the reading over a network, a server in the cloud stores it, and a dashboard or an actuator does something useful with it. Every connected product you have used, from a smart doorbell to a factory full of machines, is a variation on that one chain.

The phrase "Internet of Things" sounds complicated, but the idea behind it is simple. IoT is just everyday objects that can sense, send and respond. To keep this concrete we will follow one worked example the whole way down: a room temperature monitor built from an ESP32 board and a DHT22 sensor. Let us follow a single piece of data on its journey, from a sensor in your room all the way to your phone and back.

The full chain, in order

Here is the route one temperature reading takes. If you can name these steps in order, you already understand IoT better than most people who use the word.

1. The sensor measures the air and produces a raw signal.
2. Signal conditioning cleans that signal up so it can be trusted.
3. The microcontroller converts it to a number and decides whether it is worth sending.
4. A radio (Wi-Fi, Bluetooth Low Energy, LoRa or cellular) carries the number off the board.
5. A protocol such as MQTT or HTTP defines how that number is worded and addressed.
6. A broker or an API endpoint receives the message and passes it on.
7. The cloud stores the reading in a database built for time-stamped data.
8. A dashboard draws it as a graph you can read on a phone.
9. A rule or a person sends a command back down the same chain, and the fan turns on.

Stage one: the sensor turns the world into a signal

It starts with a sensor, a small component that measures something real: temperature, light, motion, humidity or distance. Think of sensors as the device's senses. A temperature sensor constantly reads how hot or cold the air is and turns that into an electrical signal a circuit can work with.

What the DHT22 actually gives you

Our monitor uses a DHT22, around 200 rupees in India or roughly 12 to 15 dirhams in Dubai. The cheaper DHT11 is accurate to about plus or minus 2 degrees Celsius; the DHT22 to about plus or minus 0.5 degrees, readable once every two seconds. Ask faster and it hands you the previous value, which is why students often see a number repeating in the serial monitor and assume the sensor has failed. Other sensors speak differently: an LM35 gives an analogue voltage, a DS18B20 uses one-wire, a BME280 uses I2C and adds humidity and pressure. Choosing between them is a real engineering decision.

Signal conditioning, the step most tutorials skip

Raw signals are messy. A long wire picks up noise from a nearby motor, and a sensor mounted beside the ESP32's voltage regulator reads a degree or two high because the board itself is warm. Signal conditioning is everything between the sensor and the number you trust: a 4.7k or 10k pull-up resistor on a one-wire data line, a smoothing capacitor across the sensor's power pins, and a software filter that takes five readings and uses the median. That last one costs nothing and removes most of the spikes that make a graph look broken.

Stage two: the microcontroller decides what matters

The signal travels to a tiny computer called a microcontroller (like an Arduino or ESP32). This is the brain. It reads the sensor, runs the code a student wrote, and decides what to do: store the value, react to it, or send it onward.

Two jobs happen here that are easy to miss. The first is conversion. An Arduino Uno has a 10-bit analogue to digital converter, so a voltage arrives as a number between 0 and 1023; an ESP32 has a 12-bit converter, so it arrives between 0 and 4095. Neither means anything until your code maps it back to degrees using the datasheet. That mapping is the first piece of real engineering a student writes, and one reason we often start beginners on the Uno, as we explain in our piece on why Arduino is the right first board for students.

The second job is judgement. A sensor can be read hundreds of times a second, but nobody needs room temperature at that rate, and sending it that often drains a battery and fills a database with noise. So the firmware decides. A sensible monitor reads every thirty seconds, sends only if the value has moved more than 0.2 degrees or five minutes have passed, and sleeps in between. On an ESP32, deep sleep drops current draw from tens of milliamps to a few microamps, the difference between a device that lasts a day and one that lasts months.

Stage three: connectivity, and how to pick the right radio

Using Wi-Fi, the microcontroller sends the reading to the cloud, which simply means a server on the internet. Now that data is no longer trapped inside one device. It can be stored, charted and accessed from anywhere on Earth. But Wi-Fi is one of four common choices, and picking the wrong one is the most expensive mistake in an IoT design.

Wi-Fi

Right for a device indoors, near mains power, sending often. Our room monitor is a textbook fit: plenty of bandwidth, no gateway needed. The cost is power, since an ESP32 draws well over 100 milliamps in bursts while transmitting. School networks with captive portals will also block a microcontroller that cannot fill in a login page.

Bluetooth Low Energy

Right when a phone is nearby to act as the bridge: a wearable, a fitness band, a classroom kit paired to a tablet. BLE runs for months on a coin cell, but its range is roughly ten metres and it has no path to the internet by itself.

LoRa

Right when the device is far away and sends very little: soil moisture across a farm, water level on a tank, cattle trackers. LoRa works in the sub-gigahertz band (865 to 867 MHz in India) and can cover several kilometres in open country. The trade-off is bandwidth, since messages are only a few dozen bytes and duty cycle rules limit how often you may send.

Cellular

Right when the device moves or sits where you control no network: vehicle trackers, vending machines, remote pumps. A SIM7600 or an NB-IoT modem puts it straight on the mobile network. The trade-off is money and power, because there is a SIM to pay for monthly and the modem is the hungriest part of the board.

Before choosing, write down three numbers: how far the data must travel, how many bytes a message contains, and how long the device must run without a battery change. The radio almost chooses itself.

Stage four: protocols, or how the message is worded

Having a radio is not the same as having a conversation. A protocol is the agreed format for the message: what goes in it, who it is addressed to, and what counts as a reply. For student projects the choice is nearly always between HTTP and MQTT.

HTTP

HTTP is the protocol your browser uses. The device opens a connection, sends a POST request carrying a small piece of JSON such as {"room":"lab1","tempC":29.4}, waits for a reply, and closes. It is easy to test from a laptop and every cloud service accepts it. Its weakness is overhead: each message carries a pile of headers and needs a fresh handshake, a lot of radio time for a few bytes of payload.

MQTT

MQTT was designed for this problem. The device opens one connection and holds it, and instead of addressing a server it publishes to a topic, a slash-separated label such as fizon/lab1/temperature. Anything wanting those readings subscribes to it. A message can be a few bytes on the wire, which is why MQTT is the default for battery-powered devices. It runs on port 1883, or 8883 with TLS, and the encrypted version is what any real deployment should use.

The broker

MQTT needs a middleman called a broker, and this is the part students find least intuitive. The ESP32 never talks to the dashboard. It talks only to the broker, software such as Mosquitto or a hosted service such as HiveMQ, whose job is to pass published messages to whoever subscribed. That indirection is the point: our monitor does not know whether one dashboard is listening or fifty, and you can add a logging service later without touching a line of firmware.

Stage five: the cloud, storage and the dashboard

Storage

Temperature data is time series data: every record is a value with a timestamp, records arrive constantly, they are almost never edited, and the questions you ask are about ranges rather than single rows. Nobody wants the reading at 14:32:07; they want Tuesday's average or last month's peak. Databases built for that shape, such as InfluxDB or TimescaleDB, store readings in compressed time-ordered blocks and let you keep every thirty-second reading for two weeks and only hourly averages after that. A classroom project can start with a simple MySQL table and work fine, but knowing why time series databases exist is what separates a student who followed a tutorial from one who understands the system.

The dashboard

On your phone or laptop, an app or dashboard shows the data, perhaps a live graph of room temperature. Grafana, Node-RED, Blynk and ThingSpeak all do this without you writing a website. The dashboard subscribes to the same topic the device publishes to, or reads the database, and redraws when a value arrives. A good one shows more than a graph: the current value, the trend, whether the device is online, and when the last message came in. A chart that has quietly stopped updating looks identical to a room whose temperature has not changed.

Closing the loop: the actuator

And the loop can run in reverse: tap a button on your phone, the command travels back through the cloud to the device, and a fan switches on. That round trip is the heart of every smart home, smart farm and smart city.

The return path mirrors the outbound one. The dashboard publishes to a command topic, say fizon/lab1/fan. The ESP32 has been subscribed since it booted, so the message arrives within a fraction of a second, and the firmware sets a pin high to trigger a relay or a MOSFET. A microcontroller pin supplies only a few tens of milliamps, nowhere near enough for a motor, so the relay is what lets a small logic signal control a large load safely.

The interesting design question is who decides, and each answer is right somewhere.

• The person decides. Someone taps a button. Fine when a human is always around.
• The cloud decides. A rule watches the readings and sends the command. Easy to change and to log, but useless the moment the internet drops.
• The device decides. The ESP32 switches the fan on above thirty degrees and reports afterwards. This keeps working during an outage, which is why safety-critical logic belongs on the device.

One detail catches almost everyone: use two thresholds, not one. If the fan turns on at thirty degrees and off at thirty degrees, it will chatter every few seconds as the reading hovers. Turn it on at thirty and off at twenty-eight. That gap is called hysteresis, and adding it is often the first time a student sees a two-line change fix something that looked like faulty hardware.

"Sense, send, decide, act. Every IoT device, no matter how advanced, is just doing those four things in a loop."

Where students usually get stuck

Across the projects we have built and taught since 2022, the same problems recur. Knowing them in advance saves hours.

• Power, not code. A board on a weak USB port resets whenever the Wi-Fi radio fires. It looks like a software crash; the fix is a better supply.
• Silent Wi-Fi failures. Firmware connects once at boot and never checks again, so a router restart strands the device. Reconnect inside the main loop.
• Sending far too often. A reading every second gives a jittery graph and a flat battery. Send on change, with a heartbeat.
• No timestamp discipline. If the device stamps the message and its clock is wrong, the graph is wrong. Sync time, or let the server stamp on arrival.
• Skipping security. An unencrypted broker with no username is a public noticeboard. Use TLS and credentials, even on a school project.

What to do next

Reading about IoT is one thing; building it is where it clicks. The room monitor above exercises every layer in this article, and the parts cost roughly 1,500 to 2,500 rupees, or about 80 to 140 dirhams. A sensible order to work through:

1. Get a sensor reading printed to the serial monitor, with no networking at all.
2. Add a median filter and confirm the number is steady.
3. Connect to Wi-Fi and publish to an MQTT broker, watching messages arrive on your laptop.
4. Point a dashboard at the same topic and get your first live graph.
5. Add the relay and the command topic, then add hysteresis.

If you want something smaller to start with, our list of beginner IoT projects you can build at home is the right place to begin, and parents often ask us what age a child should start coding and IoT. Students thinking further ahead may find our overview of where IoT skills lead after school useful.

If you would rather learn this with a kit in front of you and someone to check your wiring, that is what our IoT and robotics programme for students aged 8 to 22 is built for. You can also tell us what you want to build and we will point you at the right starting kit.

Written by Ramesh Kannan, CTO at Fizon Tech. He leads the hardware and firmware side of Fizon Tech's client projects and helps shape the IoT curriculum taught to students in Trichy and Dubai.