IO10: Capstone: a tank monitor that lasts, copes and updates safely
Demo, self-review and case studies
🎯You'll be able to
Run all 28 tests together, write design notes on hardware, more parts, device and cloud, and the fleet, record a demo that shows failures as well as fixes, and write honest case studies.
🏠The everyday picture
A mechanic handing back a tractor shows what was fixed, starts it in front of the owner, points to the part that will need replacing next season, and says what they couldn't test without a field.
📘What it really is
- All together:
pytestwith 28 of 28 passing in one run (about 5 seconds in the reference; not verified on Windows or macOS). -
Design notes (
capstone/design-notes-template.md): choosing a microcontroller and MicroPython, C or C++ (IO1, IO2); one more part and protecting the electronics from water and weather (IO5, IO6); what the device decides and what the server decides, and a week without network (IO7, IO8); and provisioning, staged updates, watching for quiet devices, and what to do if a signing key is exposed (IO9). Label figures and mark anything untried "not verified". -
The demo (
capstone/demo-script.md, 10 to 15 minutes): the starter's battery life, your driver and deep sleep, Wi-Fi switched off and a power cut, the backlog arriving once each in a standard MQTT client, a refused update and a rollback, and the tests. -
Case studies (
capstone/case-study-template.md): three short ones, one per project: the problem, what you did, before and after, results with figures labelled as practice-kit data, limits, and what you learned. -
Self-review: your work against the marking guides, with "not verified" for anything you couldn't run (for example a real board, a real sensor, real Wi-Fi, a real bootloader, Windows or macOS).
📝A worked example
Input: a case study draft: "I built a water monitor that runs for over two years and loses no data at all."
Steps:
- Check each claim: the kit simulates the board, the sensor, Wi-Fi and the battery. The battery figure is the simulator's estimate from illustrative currents, and "loses no data at all" goes beyond what the tests checked.
- Rewrite: "In the practice kit, my firmware's simulated battery life rose from a few days on the starter to about 870 days, using the kit's illustrative current figures. The kit's ten buffer tests, with power cuts, a lost acknowledgement and a day without Wi-Fi, found no reading lost or stored twice (practice-kit data)."
- Add a limit, such as "battery life and behaviour on a real board are not verified", and what you'd measure there.
Expected output: a case study a hiring manager can trust, because every figure says where it comes from.
🌍Where it's used
- Job applications for embedded, firmware and IoT roles.
- Freelance proposals, where a past project with honest results wins trust.
- Internal reviews, where teams present what they built and learned.
📝Case scenario
Two candidates presented similar sensor projects. One showed a dashboard; the other switched off Wi-Fi during the demo, cut the power in the middle of a write, switched both back, and showed every reading arriving once. The interviewers chose the second candidate, saying they'd seen the device cope with the conditions it would face.
🖱️Try it
Write the opening paragraph of one case study using the template, with every figure labelled. Success: a reader can tell which numbers came from the kit and which are illustrative.
⚠️Common mistakes
- Only showing successes. Sign: a demo with no failures. Fix: show Wi-Fi down, a power cut, a refused update, and one limit.
- Unlabelled figures. Sign: "two years on a battery" with no source. Fix: "simulated, practice-kit data" beside it.
- Claims beyond the kit. Sign: "works on any board", "unhackable". Fix: say what the tests checked, and mark the rest not verified.
🛠️For your project
The capstone is complete when all 28 tests pass together, the design notes, demo, case studies and self-review are done, and the capstone self-check on the Projects page is ticked.
✅Quick check
What should the demo show besides the finished work?
Show the answer
At least one failure and how it's handled, such as Wi-Fi down and a power cut with every reading arriving once, and the limits.
How should the battery figure be described in a case study?
Show the answer
As the simulator's estimate from illustrative currents in the practice kit, not verified on a real board.