Example Major Project

Live Demo

This is the real control code running in your browser. The greenhouse itself is simulated: the physics model stands in for the hardware, so the sensors, controller, model and security code all behave as they would on a microcontroller. One real second is ten simulated minutes at 1× speed.

The Brief

The school's agriculture class grows seedlings in a small greenhouse. Plants die over long weekends and holidays because nobody is there to water them, open the vents on hot days or switch on the grow lamp in winter. Students also want to see what is happening inside the greenhouse from a classroom computer.

Stakeholders

• Agriculture teacher: the client. Needs healthy plants and a record of conditions for lessons.
• Students: view the dashboard, but must not be able to change settings.
• Technician: sets targets, runs the system by hand for maintenance and refills the tank.

Constraints

• Hardware budget under $150: a microcontroller with Wi-Fi, a capacitive soil moisture sensor, a temperature and humidity sensor, a light sensor, a relay board, a 12 V pump, a fan and an LED grow lamp.
• Must fail safe: a broken sensor or an empty tank must never flood the beds or burn out the pump.
• Ten weeks of development time, working alone.

Requirements

Each requirement is written so it can be tested. The last column names the test that proves it, so the evaluation at the end can point to evidence rather than opinion.

Where Each Topic Appears

A strong major project draws on more than one focus area. This one uses all seven. Each card names what the project borrows from that topic and where to see it in the demo.

Class Design

Each class has one job. The controller only decides: it returns the actuator states it wants and never switches hardware itself. That separation is what makes it possible to unit test the control logic without a greenhouse.

class Sensor:
    def __init__(self, name, minimum, maximum):
        self.name = name
        self.minimum = minimum
        self.maximum = maximum
        self.valid = False

    def measure(self):
        raise NotImplementedError   # each subclass reads its own hardware

    def read(self):
        value = self.measure()
        self.valid = self.minimum <= value <= self.maximum
        return value


class MoistureSensor(Sensor):
    def __init__(self, pin):
        super().__init__("Soil moisture", 0, 100)
        self.pin = pin

    def measure(self):
        raw = self.pin.read_u16()              # 0–65535 from the ADC
        return (52000 - raw) / 300      # calibrated: dry air 0 %, water 100 %

The demo runs the same design in JavaScript so it can run in a browser. On the real hardware, MicroPython runs the Python version above.

Key Algorithms

Control loop with hysteresis

Switching the pump on below 35% and off at the same value would make it chatter on and off as the reading wobbles. Using two marks, a low one to start and a high one to stop, gives a dead band in between where nothing changes.

BEGIN ControlCycle
    READ moisture, temperature, light
    IF moisture reading is outside 0–100 THEN
        pump ← OFF
        RAISE ALERT "Moisture sensor fault"
    ELSE
        IF tank level = 0 THEN
            pump ← OFF
            RAISE ALERT "Tank empty"
        ELSE
            IF moisture < lowMark THEN
                pump ← ON
            ELSE
                IF moisture ≥ highMark THEN
                    pump ← OFF
                ENDIF
            ENDIF
        ENDIF
    ENDIF
    IF temperature > maxTemp THEN
        fan ← ON
    ELSE
        IF temperature < maxTemp − 3 THEN
            fan ← OFF
        ENDIF
    ENDIF
    IF hour is between 06:00 and 20:00 AND light < 250 THEN
        lamp ← ON
    ELSE
        IF hour is outside 06:00–20:00 OR light > 700 THEN
            lamp ← OFF
        ENDIF
    ENDIF
    WRITE log record every 10 minutes
END ControlCycle

Learning the evaporation rate

Soil dries faster when it is hot. While the pump is off, the system measures how fast moisture falls over each 10 minutes and pairs it with the temperature at the time. A least-squares line through those points predicts the drying rate at any temperature, which gives the time until the next watering. This is supervised learning: every sample has a known answer, the measured rate.

def fit_line(xs, ys):
    """Return slope a, intercept b and R² for y = a*x + b."""
    n = len(xs)
    mean_x = sum(xs) / n
    mean_y = sum(ys) / n
    sxy = sum((x - mean_x) * (y - mean_y) for x, y in zip(xs, ys))
    sxx = sum((x - mean_x) ** 2 for x in xs)
    a = sxy / sxx
    b = mean_y - a * mean_x
    ss_res = sum((y - (a * x + b)) ** 2 for x, y in zip(xs, ys))
    ss_tot = sum((y - mean_y) ** 2 for y in ys)
    return a, b, 1 - ss_res / ss_tot


def minutes_until_watering(moisture, low_mark, temperature, a, b):
    rate = a * temperature + b             # predicted % lost per minute
    return (moisture - low_mark) / rate

Signing in safely

The system stores a random salt and the SHA-256 hash of salt plus password, never the password. Wrong usernames and wrong passwords get the same message, so an attacker can't learn which accounts exist, and three failures lock sign-in for 20 seconds.

import hashlib, secrets, time

users = {}                 # username -> (salt, hash, role)
failures, locked_until = 0, 0

def add_user(username, password, role):
    salt = secrets.token_hex(8)
    digest = hashlib.sha256((salt + password).encode()).hexdigest()
    users[username] = (salt, digest, role)

def login(username, password):
    global failures, locked_until
    if time.time() < locked_until:
        return None, "Too many attempts. Try again soon."
    salt, digest, role = users.get(username, ("x", None, None))
    if hashlib.sha256((salt + password).encode()).hexdigest() == digest:
        failures = 0
        return role, "Signed in"
    failures += 1
    if failures >= 3:
        failures, locked_until = 0, time.time() + 20
    return None, "Incorrect username or password."

Data Dictionary

One record is written to the log every 10 simulated minutes. The log holds 1,008 records (7 days); the oldest record is dropped when a new one arrives. Records stay in time order, which is what makes binary search possible.

Test Results

These unit tests run the real classes in your browser, separately from the live demo. Each uses a chosen category of test data: normal data the system should accept, boundary data at the exact edge of a range, and erroneous data it must reject.

Evaluation

The evaluation goes back to the brief and the requirements, and judges each one against evidence.

Improvements for the next version

• Add light as a second feature in the model (multiple linear regression) to improve dawn forecasts.
• Add shade cloth on a servo for heatwaves, since venting alone can't hold the maximum.
• Send a phone notification when the tank is low, rather than only showing an alert.
• Replace SHA-256 with a password-hashing algorithm such as bcrypt when moving to a real server.