How the Device Talks: Network and Protocols

The device has a JSON message. Now it needs to send it to the cloud. How? We need to understand two ideas: transport and protocol.

Transport vs Protocol

Transport is how the message travels physically:

• Wi-Fi
• Ethernet (wired)
• Cellular (4G/5G)
• Bluetooth (for short range)

Protocol is the language the device and cloud use to talk:

• HTTP
• MQTT
• CoAP
• WebSocket

Think of it like this: Transport is the road (Wi-Fi). Protocol is the language (HTTP or MQTT).

HTTP: Request and Response

HTTP is what web browsers use. Your device can use it too.

How it works:

1. Device creates a POST request
2. Puts the JSON in the request body
3. Sends it to a URL (like https://api.example.com/telemetry)
4. Cloud responds with “OK” or an error

Example:

import requests

message = {
    "device_id": "room-101",
    "timestamp": "2025-06-01T10:00:00Z",
    "temperature_c": 23.4
}

response = requests.post(
    "https://api.example.com/telemetry",
    json=message,
    headers={"Authorization": "Bearer your-api-key"}
)

if response.status_code == 200:
    print("Message sent successfully")

When to use HTTP:

• Simple, familiar
• Works with any web server
• Good for occasional messages
• Easy to debug (you can test with curl)

Downsides:

• Each message needs a response (overhead)
• Not great for many devices sending frequently
• More data per message (HTTP headers)

MQTT: Publish and Subscribe

MQTT is designed for IoT. It’s lighter than HTTP.

How it works:

1. Device connects to an MQTT broker (server)
2. Device publishes a message to a topic (like building/room-101/temperature)
3. Cloud subscribes to that topic
4. Broker delivers the message
5. No response needed (unless you want one)

Example:

import paho.mqtt.client as mqtt

message = {
    "device_id": "room-101",
    "timestamp": "2025-06-01T10:00:00Z",
    "temperature_c": 23.4
}

client = mqtt.Client()
client.connect("mqtt.example.com", 1883)
client.publish("building/room-101/temperature", json.dumps(message))
client.disconnect()

When to use MQTT:

• Many devices sending frequently
• Low bandwidth (small message size)
• One-way data flow (device to cloud)
• Need to handle many connections

Downsides:

• Need an MQTT broker (extra service)
• Less familiar than HTTP
• More complex setup

Compare Them Side by Side

Loading...

The Message Journey

Watch how a message travels from device to cloud:

Step 1: Device formats JSON

• Takes sensor reading
• Adds device_id, timestamp
• Creates JSON string

Step 2: Message travels over Wi-Fi

• Device sends over network
• Uses HTTP POST or MQTT publish
• Goes through router to internet

Step 3: Cloud receives and stores

• Cloud service receives message
• Validates it
• Stores in database

Request/Response vs Publish/Subscribe

HTTP uses Request/Response:

• Device asks: “Here’s my data, did you get it?”
• Cloud answers: “Yes, I got it” (or an error)
• Like a phone call: you talk, they respond

MQTT uses Publish/Subscribe:

• Device says: “Here’s my data” (to a topic)
• Cloud listens (subscribes) to that topic
• No response needed
• Like a radio broadcast: you broadcast, listeners hear it

Which Should You Use?

Use HTTP if:

• You’re sending data occasionally
• You want simple, familiar code
• You need responses (confirmation)
• You’re building a web API anyway

Use MQTT if:

• You have many devices
• Devices send data frequently
• You want low bandwidth usage
• You need one-way data flow

For our simple room sensor, either works. HTTP is simpler to start with.

What’s Next?

The cloud has received the message. Now what? In the next page, we’ll see how the cloud stores it and how dashboards display it.