The first Internet of Things device was not a thermostat, a doorbell or a watch. It was a Coca-Cola vending machine on the third floor of Wean Hall at Carnegie Mellon University, and it went online in 1982 — seventeen years before anyone thought to call this category the Internet of Things.
Three flights of stairs
The computer science department's Coke machine sat on the third floor. The graduate student offices did not. Walking down to a machine that turned out to be empty was an ordinary annoyance, and a slightly worse one existed underneath it: even when the machine was stocked, a freshly loaded bottle had not been in the cooler long enough to be cold. You could make the trip, find the machine full, pay, and still lose.
David Nichols, Mike Kazar, Ivor Durham and John Zsarnay did what computer science graduate students do with an ordinary annoyance. They wired micro-switches into the machine's six dispensing columns, connected them to the department's PDP-10, and wrote a small server that reported the state of each column. Because the machine's lights indicated a column had been reloaded, the software could also track how long each column had been full — long enough to be cold, or not.
The status was queryable over the ARPANET. Anyone on the network — including people at other institutions, who had no plausible use for the information — could ask a vending machine in Pittsburgh whether it was worth the walk.
Why it counts as the first
It is tempting to file this as a campus prank, and it was partly that. But it satisfies every requirement of a connected device in the modern sense, and it is hard to find an earlier system that does.
There is a physical asset in the world whose state changes. There are sensors instrumenting that state directly, rather than a human reporting it. There is an embedded link from the sensors to a computer, a network protocol carrying the state off-site, and a remote client acting on data it did not gather itself. Nothing in that description would look out of place in a specification written this year.
What it did not have was the vocabulary. Kevin Ashton coined the phrase "Internet of Things" in 1999, in a presentation to Procter & Gamble about putting RFID tags on supply chain inventory. By then the pattern had been running unremarked for the better part of two decades.
The pattern has not changed
Strip out the PDP-10 and the ARPANET and the architecture is exactly what we deploy for clients today: a sensor on the physical thing, a microcontroller reading it, a network carrying the state somewhere useful, and a person or system consuming that state instead of guessing.
Modern versions of the same problem are more consequential than a warm bottle. A fuel tank at a remote site that gets checked with a dipstick once a week. A cold-chain freezer whose failure is discovered the following morning, along with the spoiled contents. A production line whose downtime is reconstructed from memory at the end of a shift. A water level that somebody drives out to read. In every case the fix is structurally identical to the Coke machine: measure it directly, publish it continuously, stop sending a person to look.
The hardware has become almost trivially cheap. An ESP32 costs a few hundred pesos, has Wi-Fi and Bluetooth on the die, and does more than that PDP-10 could. The engineering that still matters is everything around the sensor — what happens when the network drops (buffer locally, reconcile on reconnect), how the firmware gets updated once the device is installed somewhere inconvenient, what the power budget allows, and whether the thresholds and alerts are set so that people actually act on them rather than learning to ignore them.
The part that is easy to miss
The students did not build a dashboard because dashboards were valuable. They built it because they were tired of walking. The value of a connected device is almost never the data — it is the specific human action the data removes or triggers.
That is the useful test when scoping an IoT project. Not "what could we measure?" but "what does somebody currently walk over and check, guess at, or find out too late?" If there is no honest answer, the sensors will get installed, the dashboard will get built, and nobody will open it after the first month.
If there is an answer, the project usually pays for itself faster than anyone expects.
Fluidwire designs and builds connected systems for businesses in the Philippines — sensors, firmware, and the software that makes the data usable. Take a look at our IoT and web services, or tell us what you currently have to walk over and check.
