Three IoT origin stories — and what they still teach about building connected devices

The Internet of Things feels like a recent invention, but the ideas behind it are older than the web. Three origin stories come up again and again — and each one still carries a practical lesson for anyone building a connected device today, whether it’s a commercial sensor fleet or a thesis prototype.

1982: The first IoT device was a Coke machine

Computer science students at Carnegie Mellon were tired of walking to the third-floor Coca-Cola vending machine only to find it empty — or worse, full of warm bottles that had just been restocked. So they wired the machine’s status lights to a computer, connected it to the ARPANET, and wrote a program anyone on the network could query: how many bottles in each slot, and how long they’d been cooling.

A connected device, remote telemetry, queryable state — all the ingredients of IoT, a decade before the web existed.

The lesson: the best IoT projects start with a real, annoying problem. The CMU students didn’t set out to invent a category; they wanted cold soda without a wasted walk. If you’re scoping a device idea — or a thesis project — start from the walk you’re tired of taking, not from the technology.

1999: “Internet of Things” was coined to sell RFID

The phrase itself came from Kevin Ashton, a brand manager at Procter & Gamble, who needed a title for a presentation about putting RFID tags on products in the supply chain. His pitch: computers should gather data about the physical world themselves, through sensors, instead of waiting for humans to type it in. He called that idea the “Internet of Things” because it would get executives’ attention. It did.

The lesson: Ashton’s core argument is still the test for whether a project is really IoT. If a human has to read a dial and enter a number, you have a spreadsheet with extra steps. The value appears when the device reports its own state — which is why sensor selection and reliable connectivity matter more than the dashboard, even though the dashboard gets all the attention.

1999: MQTT was built to watch oil pipelines

The same year, Andy Stanford-Clark of IBM and Arlen Nipper were solving a much harsher problem: monitoring oil pipelines across remote stretches of country, over satellite links that were slow, unreliable, and billed by the byte. The protocol they designed — MQTT — had to sip bandwidth, survive dropped connections, and run on tiny embedded hardware.

That’s why MQTT looks the way it does: a minimal 2-byte header, publish/subscribe instead of polling, three quality-of-service levels, and a “last will” message so the broker can announce when a device drops offline. None of that was academic — every feature paid for itself on a satellite bill.

The lesson: constraints make good protocols, and MQTT’s constraints still match most IoT projects today. An ESP32 on a spotty connection — a farm sensor on patchy 4G in Laguna, a tracker on a jeepney moving through Metro Manila — faces the same fundamentals as a 1999 pipeline: limited bandwidth, intermittent links, battery budgets. It’s why MQTT is still our default for device-to-cloud messaging, twenty-five years later.

What the stories have in common

Each one starts with a concrete pain — a wasted walk, manual data entry, a satellite bill — and ends with a design shaped entirely by that pain. The technology came second.

That’s the order we recommend for any connected-device project: define the telemetry that solves the problem, pick the lightest transport that delivers it reliably, and only then build up the stack — firmware, broker, dashboard. If you’re planning one — a product, a pilot, or a student build — our services cover that full path from PCB to cloud dashboard, and we’re always happy to talk through an idea before you commit to hardware.