In 1991, researchers in the Computer Laboratory at the University of Cambridge had a coffee problem. The department's only filter machine sat in a corridor outside the Trojan Room, and people on other floors kept making the trip only to find an empty pot. So Quentin Stafford-Fraser and Paul Jardetzky pointed a spare camera at the pot, wired it to a frame grabber, and wrote a small client called XCoffee that put a live picture of the pot on everyone's screen.
The image was 128×128 pixels, greyscale, and updated a few times a minute. That was enough. The only question anyone had was "is there coffee?", and a thumbnail answered it perfectly.
In 1993, when the web arrived, the feed was connected to a web server — making the Trojan Room coffee pot the world's first webcam. It ran until August 2001, when the lab moved buildings and switched it off in front of a watching internet. The pot itself was auctioned on eBay for £3,350 to the German news site Spiegel Online.
It's a charming story. It's also, thirty-five years later, still the single best brief for any camera-based IoT project.
One camera, one question
The Trojan Room camera succeeded because it was scoped to answer exactly one question at the minimum quality that question required. Nobody asked for pan-tilt-zoom, colour, or smooth video, because none of that made the answer better.
Most camera IoT projects that stall do the opposite: they start with "stream HD video to the cloud" and then discover what that costs in bandwidth, storage, power, and firmware complexity. Before any hardware decision, write down the question your camera answers. "Is the water level above the marker?" "Is the drying pad covered before the rain hits?" "Is there a queue at the counter?" "Did the feed get dispensed?" Every one of those is a coffee-pot question — answerable with a small, infrequent image, or even a single number extracted from one.
The modern Trojan Room kit costs less than lunch
What took a lab camera, a frame grabber, and a workstation in 1991 is now one board. An ESP32-CAM — an ESP32 with an OV2640 camera module — sells locally for a few hundred pesos and will happily capture a snapshot, compress it to JPEG, and push it over Wi-Fi.
A few hard-won, practical notes if you build with one:
Power it properly. The ESP32-CAM browns out on weak USB power the moment the radio and camera fire together. Give it a solid 5 V supply rated for at least 2 A and short, thick wires. Random resets on camera init are almost always power, not code.
Snapshot, don't stream. Match the Trojan Room cadence: capture a frame on a timer or a trigger (a float switch, a PIR sensor, a schedule), upload it, and sleep. Battery life and bandwidth both improve by an order of magnitude versus continuous streaming.
Send the answer, not always the picture. Often the image is only needed when something looks wrong. Publish a small MQTT message ("level: 82%", "pad: covered") routinely, and attach a photo only on change or alarm. Your dashboard stays light and your SIM card data plan survives the month.
Keep resolution honest. If 320×240 answers the question, 1600×1200 just costs you flash, RAM, and upload time.
Coffee-pot questions are everywhere in the Philippines
The pattern fits local problems unusually well, because so many of them are "I had to travel to check" problems. A water tank in Cavite, a rice-drying pad ahead of an afternoon thunderstorm, a fishpond feeder in Bulacan, a stall queue in a Parañaque market — each is a short question that a cheap camera or sensor can answer remotely, over patchy 4G, without anyone making the trip. That's the same wasted walk the Cambridge researchers refused to keep taking; theirs just ended at a coffee machine.
For thesis students, this is also the most defensible kind of prototype: a narrow question, a measurable answer, and hardware that demonstrably solves it beats a sprawling "smart everything" platform in front of any panel.
Start with the question
The first webcam wasn't a camera project. It was a coffee project that happened to need a camera — the technology was sized to the question, not the other way around. That ordering is how we scope every build at Fluidwire: define the question, pick the smallest sensor and transport that answer it, then grow the stack only when the answer demands it.
If you've got a coffee-pot question of your own — a tank, a field, a queue, a machine you're tired of checking in person — our services cover the full path from board to dashboard, and you can talk to us before you spend a peso on hardware.