A Radio Is Not a Connection: IoT Connectivity & Cloud

What this is. Opinion + Experience + Fact (45% opinion · 25% experience · 30% fact). Written in collaboration with AI — I discuss, I do not outsource.

Part of the AI Builder series. Adding a radio feels like the moment a product becomes "connected." It isn't — getting online is the easy part, and staying useful when the network misbehaves is the real job. Here's the device-to-fleet-to-data path, why the link dropping is the design problem, and how to use AI on connectivity without shipping confident nonsense.

There's a satisfying moment in a hardware project when the device first phones home. A packet goes out, a dashboard lights up, and it feels done. It isn't done — it's barely begun. A radio is not a connection, in the same way a phone with one bar is not a conversation. The interesting engineering in connected products lives in everything after that first packet: choosing the right link, speaking a protocol that survives bad networks, and turning a stream of bytes into data you can actually trust.

This is the AI Builder series reaching connectivity and cloud. As with the rest of the series, you don't need to be a networking specialist — you need enough awareness to ask the right questions and catch a wrong answer, including from an AI that will happily write you connectivity code that looks right and behaves badly.

---

1. Getting online is the easy part

The first real decision is the radio, and it's a trade-off, not a default. Cellular reaches almost anywhere but costs power and money. Wi-Fi is fast and cheap where it exists and useless where it doesn't. Bluetooth is low-power and short-range. LoRa goes far on tiny power but carries very little data. There's no "best" — there's only best-for-this-product, and the axes are range, power, and cost. Pick for where the device actually lives, not where you're demoing it.

And a link that works on your desk is not the same link the product will meet in the field: a basement, a moving truck, a metal enclosure, the far edge of coverage. The demo environment is the most forgiving one your product will ever see.

▸ First principle. Choosing the radio is a power-and-place decision, not a feature checkbox.

2. The link will drop, so design for it

The single biggest shift in mindset is this: assume the network is unreliable, because it is. Devices go through tunnels, lose power, sit in dead zones, and get throttled. So two things matter. First, speak a protocol built for constrained, unreliable networks — lightweight publish/subscribe protocols like MQTT are popular in IoT for exactly this reason, rather than leaning on heavy request/response web calls when you can avoid them. Second, design the offline behaviour deliberately: buffer readings while disconnected, reconnect automatically, and retry with backoff so a whole fleet doesn't stampede a server the instant connectivity returns.

The question is never whether the network drops — it's what your device does while it's gone and how gracefully it catches up. (This is the connectivity face of the same rule that losing the network is part of the spec.)

▸ First principle. A connected product is really an occasionally-connected one; plan for the gaps.

3. Data is only useful when it lands somewhere

Getting bytes to the cloud is step one and the least of it. The real work is making that data trustworthy and usable: stored, queryable, and tied to the right device and the right firmware version, so that when you look at a number you know exactly what produced it. A pile of unlabelled telemetry is not an asset; it's a liability you pay to store. Connectivity isn't finished when a device sends one message — it's finished when the data on the other end is reliable enough to make a decision on.

This is also where AI both helps and bites. It will scaffold a connectivity client in seconds — and just as quickly invent a power budget, skip the security handshake, or ignore what happens on reconnect. The fix is the same as everywhere in this series: bring the real constraints (the radio, the power budget, the security model, the offline behaviour) or the model fills the gaps with plausible fiction. It's the same reason firmware is not just software.

▸ First principle. Connectivity isn't done at "it sent one message" — it's done when the data is reliable enough to decide on.

A prompt you can actually use

Here's a tested way to make AI safe on connectivity: force it to state the network reality and its own guesses before it writes a client.

You are helping me design the connectivity for [device] that must send [data] to [where].

Before writing any code, list:

1. The link (cellular / Wi-Fi / BLE / LoRa) and why — with the range, power, and cost trade-off. Ask me if unknown.

2. The protocol, and why it suits a flaky, constrained network.

3. Offline behaviour: what the device does while disconnected, how it reconnects, and the retry/backoff.

4. Security: how the device authenticates and what protects the data in transit.

5. What each message is tagged with (device id, firmware version, timestamp).

CHECK: mark every choice [known] or [GUESSED] and flag anything you invented. No code until I confirm.

▸ First principle. Make AI declare the network reality before it writes a client, and its confidence stops being a liability.

Keywords

IoT connectivity, device to cloud, MQTT, cellular vs Wi-Fi vs BLE vs LoRa, offline-first devices, retry and backoff, device telemetry, AI for connectivity, awareness not mastery, AI Builder series.

FAQ

How do you choose a connectivity option for an IoT device?
Treat it as a trade-off between range, power, and cost for where the device actually lives. Cellular reaches almost anywhere but costs power and money; Wi-Fi is fast and cheap where it exists; Bluetooth is low-power and short-range; LoRa goes far on tiny power but carries little data. There's no universal best — only best-for-this-product.

Why is MQTT common for IoT connectivity?
MQTT is a lightweight publish/subscribe protocol designed for constrained devices and unreliable networks, which makes it a good fit for battery-powered devices on flaky links, compared with heavier request/response web calls. It's one common choice among several; the point is to use a protocol built for the network you actually have.

How should a device handle losing its network connection?
Assume the link will drop and design for it: buffer data while offline, reconnect automatically, and retry with backoff so a fleet doesn't stampede the server when connectivity returns. Define what the device does while disconnected — that behaviour is the real design problem, not the happy-path send.

Can AI write connectivity code for a connected product?
It can scaffold a client quickly, but it will also invent power budgets, skip security, or ignore reconnect behaviour with total confidence. Give it the real constraints — link, power budget, security model, offline behaviour, and message tagging — and make it mark its guesses, so you can verify rather than discover the gaps in the field.

Part of the AI Builder series — it compiles into the Handbook. The longer story and how I work live on my profile. — Ritesh | ritzylab.com