Stage 5 of 6 · The project · read before choosing anything

The project begins

The LIA is 40 % of the course: in pairs, a complete sensing-deciding-acting-showing system on a theme you choose, delivered in five milestones and ending in a public demonstration. The brief on Omnivox governs every deliverable's exact contents, submission and grading; what it cannot do for you is pick a good idea and scope it survivably. That method is this page.

The LIA, in one view

40 % of the course, on one line. Note the weights: D1 to D3 are checkpoints; D4 and D5 carry the mass, and Week 13 stacks D3 against the final exam. Plan backwards from that, this week.

From this week to the demonstration, the LIA project hub is the standing reference: every milestone with its evaluation focus, the method, the risk patterns, and the full reference shelf, one place, maintained to the end.

What makes an idea a project

The course's architecture is your project's skeleton: swap the sensor, the rule and the actuator, keep everything between. An idea qualifies when it fills real content into every slot, and the fastest honest test is Week 10's vocabulary. Fill these blanks in one line each; an idea that cannot fill them is a demo, not a project:

Six blanks decide everything. Dashed boxes are yours to invent; solid ones you already own. The rule need not be a PID, a threshold, a schedule or a state machine from Week 5 all count, but it must decide something, and the dashboard must answer one question at a glance. Write the six lines on paper before writing any brief text.

Two instincts keep ideas honest. First, prefer a quantity you can measure on your bench today (light you have; other sensors only as the brief and the kit allow). Second, prefer a loop over a log: "shows the temperature" is half a project; "holds, alerts, or reacts, and shows it" is whole, because deciding and acting are where Weeks 5, 6 and 10 pay off and where grading rubrics look.

Scope it as a skeleton, then rungs

You have watched this method for eleven weeks without its name: every hub built a walking skeleton first, the thinnest end-to-end version that actually runs, then deepened it rung by rung. Apply it to yourselves, calibrated to the timeline above:

By D2, the skeleton walks. Sensor read, one message flowing, one decision firing, one actuation moving, one number on a page. Ugly is fine; end to end is the entire point, because every risk in the project lives at an interface you have now crossed.
Rungs are ranked, not dreamed. List your features as ladder rungs the way every hub did, ordered by value, and climb in order. A rung must leave the system demonstrable; anything that breaks end-to-end for a week is not a rung, it is a cliff.
Week 13 is half-width. The final exam shares D3's week: plan that week's rung small, on purpose, now.
Freeze before D5. The last days before a public demo are for rehearsal and the verification protocol, not for new rungs; demos die of Friday features.

Requirements: Week 5, for real stakes

Whatever D1's exact format, your idea will need stating as requirements, and Week 5's five qualities now grade something that matters: each line testable, unambiguous, atomic, necessary, feasible. Carry the A2 habit forward too: a verification table, one row per requirement, how it will be demonstrated and when, maintained in the repo (docs/, beside your Week 9 topics.md and Week 10 tuning.md, which your project inherits and extends). "The system reacts quickly" is a wish; "the dashboard's reading is at most 3 s old in normal operation" is a requirement, and this week you can even say where the 3 comes from.

Working as a pair

The LIA is in pairs, and the course has already given you the collaboration stack: one shared repository, branches per person, pull-request reviews before merging, the Week 1 conflict ritual when it bites. Three agreements to make today, in writing, in the repo's README: who carries which board between classes; how the work splits (by layer, node vs Pi vs dashboard, or by feature, each owning rungs end to end, both work, choose one); and a fixed sync rhythm, ten minutes at each class's start plus one mid-week check-in. Pairs fail by silence, not by skill.

Idea shapes, if you are stuck

Shapes, not assignments; your theme and the brief's constraints decide:

Hold a quantity: keep light, temperature or level at a target against disturbances, the Week 10 pattern on a theme you care about.
Watch and alert: monitor a condition, decide when it is wrong, act (LED, buzzer, message) and show the history that justifies the alarm.
Count and react: events over time (passages, presses, cycles), a rule on the count, an action and a live tally.
Schedule and verify: act on a timetable, measure that the action truly happened, and show both, the closed-loop upgrade of every timer project.

Checklist for this stage

We have read the brief on Omnivox end to end and logged our questions for the teacher
Our idea fills all six blanks of the frame, in one line each, on paper
Our rung list exists, ranked, with the D2 skeleton marked and Week 13 planned small
Our draft requirements pass the five qualities and each has a verification-table row
Pair agreements (boards, split, rhythm) are written in the repo README

Check yourself

Run the six-blank test on "a plant-watering reminder that shows soil dryness on a page". What passes, what fails, and one fix?

PV (dryness), topics and dashboard fill fine; SP/logic is weak ("remind" decides little) and u is empty, nothing acts. It is watch-without-act, half a project. One fix: close the loop, a threshold rule driving a pump, valve or unmissable indicator, with the dashboard showing level, target, and the last action taken.

Why does the skeleton cross every interface by D2 instead of perfecting the node first?

Because eleven weeks of troubleshoot pages say where projects die: at interfaces, Wi-Fi, topics, payload contracts, bind addresses, firewalls, not inside well-understood components. A thin end-to-end run flushes every interface risk in week one, while "perfect node first" discovers them the weekend before D4, with the heavy milestones already burning.

Grade "the dashboard should update fast" against the five qualities, then repair it.

Fails testable and unambiguous ("fast" by whose watch?), and hides a design decision. Repaired: "the dashboard's displayed reading is at most 3 s older than the sensor's measurement in normal operation", testable with a stopwatch and a shaded sensor, and the 3 s is defensible arithmetic: one publish interval plus one poll interval, this week's sequence figure.

Your partner proposes saving Week 13's time by skipping D3's rung and building two rungs in Week 14. Argue the schedule.

Week 13 is half-width by design (final exam, same day), so planning it small is right; moving its rung into Week 14 is not, because W14 carries D4 at 15 %, the heaviest milestone, and stacking new rungs against it trades the course's biggest grade for the smallest. Keep D3's rung tiny but real, and keep D4's week for D4.

Which existing repo artifacts does the project inherit on day one, and why do markers care?

The working stack (node code, broker config knowledge, monitor, PID, dashboard) plus the documentation spine: docs/topics.md, docs/tuning.md, the verification-table habit, config_example.py with secrets ignored, and the journal. They show method, and method is what the five qualities, the milestones and ultimately the demo are grading; a project that starts from a documented, running system is already demonstrating the course's outcome.