Week 11 · Monday, November 16, 2026 · Room D-221
The system gets a face.
Your bench senses, networks, decides and acts, and only its builders can see any of it. Today the Pi grows a web server, the browser joins the architecture, and anyone on the bench network, laptop or phone, can watch the light level live and set the loop's target from a page you wrote. The framework is Flask; the protocol is the web's own; and with that, the diagram the course opened with has no empty boxes left. The term project opens the same afternoon.
What happens today
Theory · first hour
HTTP, and the second pattern
The web's request/response protocol: URLs, methods, status codes, and just enough HTML. Then the week's big architectural idea: request/response and publish/subscribe are not rivals, they are two tools for two jobs, and your system is about to use both at once, each where it belongs.
Lab · two hours
Serve, bridge, show, steer
Flask installed and serving (one familiar wall, one familiar firewall rule), then the bridge that joins MQTT's push world to HTTP's ask world, then a live dashboard with a status chip and a setpoint control that steers Week 10's loop from the browser. The project opens alongside, with D1 due per the brief.
The diagram, finally complete
Since Week 8 the course has drawn one architecture and filled it in week by week. Today the last box stops being a promise:
In the course outline
This is Week 11 of 420-302-VA and the start of phase 4, interfaces. The LIA term project (40 % of the course) opens today: in pairs, a complete sensing-deciding-acting-showing system on a theme you choose, delivered in five graded milestones, D1 (5 %) due this week, through the public demonstration in Week 15. The project brief on Omnivox governs D1's exact contents and submission; this hub's project page is the method support behind it.
Why a web dashboard, and why Flask
A system you cannot see gets debugged by its builders and trusted by nobody else. Industry solved this long ago: every SCADA room, building-management screen and machine HMI is an interface drawing live values from the plant, because operators, clients and inspectors all meet the system through its face, not its wiring. The browser is the one client every device already ships, so serving HTTP is the cheapest honest face a system can have. Flask is the standard Python way to do it small: a microframework, a server core plus routing plus templates and nothing you did not ask for, which makes it the right size for a Pi, for a bench, and for a five-week project.
Three ideas you will reuse
Two patterns, two jobs
Pub/sub moves machine telemetry on events; request/response answers humans on demand. Week 9 showed why polling devices is wasteful; this week shows where asking is exactly right. Real systems run both, and yours now does.
The bridge is a dictionary
Push world and ask world meet at shared state: MQTT callbacks write the latest values into a dict, HTTP routes read it. One small structure decouples two rhythms, the humblest version of a pattern you will meet in every integration job.
Routes are a contract
A URL maps to a function maps to a response: /api/light answers with JSON, for any client, forever. Designing those paths is Week 9's topic-design craft again, on the other protocol.
What you will be able to do by the end of the week
- Explain HTTP's request/response cycle, read a status code, and anatomize a URL.
- Argue when request/response beats pub/sub and when it loses, with your bench as the worked example.
- Serve pages and JSON from Flask on the Pi, reachable from any device on the bench network, firewall rule included.
- Bridge MQTT into Flask with a background network thread and shared state, and defend the design.
- Build a polling dashboard: live value, status chip from the retained topic, and a setpoint control that steers the Week 10 loop.
- Frame a project idea in control terms (SP, PV, u, disturbances) and scope it as a walking skeleton plus rungs.
Words you will hear all day
| Term | Plain meaning | Common mix-up to avoid |
|---|---|---|
| HTTP | The web's request/response protocol: a client asks, a server answers, done. | Stateless by design: each request stands alone, which is why the bridge holds state. |
| Web server | A program answering HTTP requests; today, Flask's, on the Pi. | A role, not a machine: your Pi is simultaneously server (HTTP, MQTT) and client (of the broker). |
| URL | Scheme, host, port, path: the full address of one resource. | The port matters: the Pi's web face lives on 5000, not the browser's assumed 80. |
| Route | A path-to-function mapping in Flask: @app.route("/api/light"). | Routes match exactly; /api/light/ with a stray slash is a different address. |
| GET / POST | Read a resource / submit something that acts. | GET should change nothing; the setpoint goes by POST because it moves a real LED. |
| Status code | The response's verdict: 200 OK, 404 not found, 500 server error. | 500 means your Python raised; the traceback is in the Flask terminal, read bottom-up. |
| Template | An HTML file with {{ placeholders }} Flask fills per request (Jinja). | Lives in a folder literally named templates/; elsewhere is a 500. |
| JSON API | Routes answering with data, not pages, for scripts and dashboards. | Same JSON as Week 9's payload rung; the format crossed protocols intact. |
| fetch / polling | The browser's way to ask a URL from JavaScript; ours asks every 2 s. | Not Week 9's sin: one browser politely asking one aggregator is the pattern working. |
| The bridge | Shared latest-values state written by MQTT callbacks, read by routes. | It is a cache of now, not a database of history; history is a ladder rung. |
| Dev server | Flask's built-in server: perfect for the bench, not for the internet. | Its warning banner is honesty, not an error; production uses a hardened server. |
| LIA | The term project: 40 %, in pairs, five deliverables, demo in Week 15. | The brief on Omnivox governs contents and grading; the hub supplies method. |
Where this fits in the course
Week 10 · Nov 9
Control: closing the loop
The PID lesson and the supervisory pattern: the setpoint channel your dashboard will drive was built there.
Week 11 · Nov 16 · this hub
Flask & the project
HTTP theory, Flask on the Pi, the MQTT-to-HTTP bridge, a live dashboard, and the project's opening week with D1.
Week 12 · Nov 23
Project studio: the system comes together
Supervised project work with the whole stack at your service; D2 lands as the walking skeleton proves itself end to end.
Working at home
Everything reproduces on the Week 9 home setup, and this week adds a pleasure: once Flask serves on the Pi, any device on your home network reaches the dashboard at the Pi's address, port 5000, no installs. The project makes home time real work from now on: the brief's milestones assume progress between classes, so agree with your partner, today, on who carries which board and how the repo splits the work, the Week 1 habits are about to earn their keep.