What Actually Happens When You Connect a Device to the Internet

The first thing nobody tells you

A student in our evening class bought a $9 temperature sensor kit last month. It came with a WiFi module, a small breadboard, and a datasheet written for engineers. After three evenings of wiring, he had the LED blinking. Then he asked the question that stops everyone: "How do I get this number onto my phone?"

The answer is not one thing. It's a chain of five distinct jobs, each with its own rules. Once you see the chain, every IoT project becomes the same project. You're just swapping out the parts.

The chain is: sensor, device, network, broker, application. Let's walk through each one with a concrete example we use in class: a temperature logger for a server room.

The sensor and the device

The sensor is the part that measures something. In our case, it's a thermistor. It changes electrical resistance with temperature. The device is the microcontroller that reads that resistance. We use an ESP32 because it has WiFi built in and costs about $6.

The ESP32 has an analog-to-digital converter. It samples the voltage from the thermistor about once per second. That voltage maps to a temperature. The code is boring and that's good:

float readTemperature() {
  int raw = analogRead(THERMISTOR_PIN);
  float voltage = raw * (3.3 / 4095.0);
  return (voltage - 0.5) * 100.0;
}

The conversion formula is rough. We calibrate it against a known thermometer and adjust the offset. Nobody does this perfectly on the first try.

The device has one more job: it must form the data into a message. We create a small JSON string with a timestamp and the reading. The timestamp matters more than people expect. If you don't record when the reading happened, you can't draw a meaningful graph later.

The network: where data learns to travel

This is where most beginners get lost. They imagine the device "sending data to the internet" as one single act. It isn't.

The ESP32 connects to your WiFi router. The router forwards packets to your internet service provider. The ISP routes them through several other networks until they reach a server. This happens in under a second, but every hop is a place where things can fail.

Here's the part that surprises people: the device doesn't need to know where the server is. It only needs to know the server's IP address or hostname. The internet handles the rest. We give the ESP32 a hostname like api.example.com and port 8883.

The network layer cares about one thing: getting bytes from point A to point B. It does not care what those bytes mean. That's the job of the protocol.

The protocol: HTTP is not enough

Most tutorials start with HTTP. You make a POST request to a server with your data. The server replies 200 OK. Done.

HTTP works for occasional updates. But IoT devices send data constantly. Imagine a server room with 200 sensors, each sending one reading per minute. That's 3.3 requests per second. HTTP has overhead. Each request includes headers, connection setup, and teardown. It works, but it's wasteful.

More importantly, HTTP is request-response. The device asks, the server answers. But what if you want the server to push a command to the device? You'd have to poll continuously. That's inefficient and slow.

We use MQTT instead. MQTT is a publish-subscribe protocol designed for low-bandwidth, high-latency, or unreliable networks. It's been around since 1999 and it's everywhere in IoT.

Here's how it works. A central server called a broker sits in the middle. Devices connect to the broker and publish messages to topics. Other devices subscribe to topics and receive those messages. The publisher doesn't know who's listening. The subscriber doesn't know who's publishing. They only know the topic.

Our temperature sensor publishes to server-room/temperature. A dashboard subscribes to that same topic. When the sensor publishes a reading, the broker forwards it to the dashboard. If the dashboard goes offline, the broker holds the message until it comes back (if we set a retained flag).

The protocol overhead is tiny. An MQTT message with a topic and payload is often under 100 bytes. Compare that to a full HTTP request which can be 500 bytes or more just in headers.

The broker: the post office you forgot you needed

The broker is a separate piece of software. It runs on a server, often a small cloud instance. Mosquitto is the most common open-source broker. It's written in C, it's fast, and it runs on a Raspberry Pi.

The broker doesn't store data permanently. It routes messages and forgets them. If you want historical data, you need a database. That's a separate service, often InfluxDB or PostgreSQL.

So your architecture now has three moving parts: the device, the broker, and the database. The device publishes to the broker. A small service subscribes to the broker, gets the message, and writes it to the database. Then a web dashboard reads from the database and draws a graph.

This seems overcomplicated for a temperature sensor. But the separation is what makes it scalable. You can add 50 more sensors without touching the broker. You can add a new dashboard without touching the sensors. Each piece is replaceable.

Putting the pieces together

Here's a minimal Python script that subscribes to our broker and inserts readings into a SQLite database. It's the glue between the broker and the database:

import paho.mqtt.client as mqtt
import sqlite3, json

conn = sqlite3.connect("readings.db")
conn.execute("CREATE TABLE IF NOT EXISTS temps (ts TEXT, value REAL)")

def on_message(client, userdata, msg):
    payload = json.loads(msg.payload)
    conn.execute("INSERT INTO temps VALUES (?, ?)",
                 (payload["timestamp"], payload["temperature"]))
    conn.commit()
    print(f"Saved {payload['temperature']}°C")

client = mqtt.Client()
client.on_message = on_message
client.connect("localhost", 1883)
client.subscribe("server-room/temperature")
client.loop_forever()

The script blocks forever, waiting for messages. That's fine for a small project. For production, you'd use something more robust, but this shows the core idea.

Security: the part we don't know enough about

We should be honest here: IoT security is a mess. The ESP32 has no user authentication built in. The WiFi password is the only thing keeping your device off the public internet. That's fine for a lab project. It's not fine for a real deployment.

For production, you'd use TLS encryption between the device and the broker. You'd also set up username and password authentication on the broker itself. And you'd think carefully about what happens if someone gains access to your device. Can they reach other devices on your network? In most home setups, yes.

We tell students: don't put an IoT device on the same network as your main computer unless you've thought about what happens if it's compromised. A $6 chip with a known default password is a backdoor into your home.

Power and reliability

The ESP32 draws about 0.3 watts when active. That's nothing. But it adds up if you have 50 devices. And if the device is battery-powered, every transmission matters. WiFi is power-hungry. A battery-powered sensor that sends data every minute will drain a 18650 battery in about a week.

This is why many IoT devices use LoRaWAN or Zigbee instead of WiFi. These protocols trade bandwidth for range and power efficiency. A LoRa device can run for months on two AA batteries. But it sends data at about 0.3 kilobits per second, so you're not streaming audio.

For our class project, we keep it simple: the ESP32 is plugged into a USB charger. We accept the power draw because the alternative adds complexity we don't need.

What we tell everyone starting out

Start with one sensor. Not a fleet, not a platform, not a fancy dashboard. One sensor, one broker, one database. Get the chain working end to end. Then scale up.

The mistake people make in week two is buying a multi-sensor kit and trying to build a complete smart home system before they understand the message flow. They get frustrated and quit. The people who succeed are the ones who spend a weekend getting a single number from a board to a screen.

The second mistake is choosing tools before understanding the concepts. People ask "Should I use AWS IoT or Azure?" before they know what a broker does. The platform doesn't matter if you don't understand publish-subscribe. Learn the concepts with free tools first. The platforms will still be there in a year.

Common questions

How much does it cost to run a small IoT project for a year?

For a single sensor with a cloud broker and a small database, expect about $5 per month. A Raspberry Pi at home as a broker costs about $3 per month in electricity. Managed cloud services start around $10 per month and go up. The sensor hardware itself is under $15.

Can I use my phone as an MQTT broker?

Not realistically. MQTT brokers are server software that need to run continuously. Phones sleep, switch networks, and have limited background processing. You can install Mosquitto on an old Android phone using Termux, but it's unreliable. A cheap used Raspberry Pi or a free cloud tier on a service like CloudMQTT is a better choice.

What happens if the WiFi goes down in the middle of a transmission?

The MQTT client on the ESP32 will try to reconnect. If the broker had a retained message, the device will get the last known state when it reconnects. But readings taken during the outage are lost unless the device stores them locally. That's a real design decision. For a temperature sensor, losing 10 minutes of data is fine. For a medical device, it's not. The ESP32 has enough flash memory to buffer thousands of readings, but you have to write that logic yourself.

Do I need to learn C++ to do IoT?

The ESP32 uses C++ via the Arduino framework. It's a small subset of the language. If you already know Python, you can pick up the Arduino syntax in a weekend. There are also options like MicroPython, which runs a Python interpreter directly on the board. It's slower and uses more memory, but for simple projects it's fine. We teach C++ because it's what most tutorials and libraries use.