Smart home science fair projects that actually impress judges
Judges reward a measured question, a fair control and clean data, not a gadget that switches on. Here is how to turn a smart home build into a real experiment, with six outlines.
A smart home project wins at a science fair when it answers a number, not when it makes a light turn on. Judges have seen plenty of builds that switch on when you clap or wave. What earns marks is a clear question you can measure, a fair test with a control, and data presented so the result is believable. With the Term 4 expo season here, this is how to take any working build and turn it into a real experiment, plus six project outlines you can adapt.
What judges are actually scoring
A demo shows that a thing happens. An experiment answers whether one thing changes another, and by how much. That gap is where most smart home projects lose marks. A light that comes on when you enter a room is a demo. "Does daylight-aware dimming cut lighting energy without dropping below a usable brightness?" is an experiment.
When you read a scoring rubric, the same items keep appearing: a specific question, a hypothesis, a control to compare against, variables you kept fixed, repeated measurements, and an honest analysis of what the numbers say. Build for those, not for the wow moment.
Turn "it works" into a measurable question
Pick a quantity you can put a unit on, then frame the project as a comparison. Good quantities for a home build include:
- Energy used — estimate it as the device's power rating multiplied by the time it was on. You do not need a fancy meter to compare on-time between two setups.
- Response time (latency) — the seconds between a trigger and the system reacting, timed with a stopwatch or logged timestamps.
- Reliability — out of a set number of trials, how many did it catch, miss, or trigger falsely.
- Control quality — how tightly it holds a target temperature, moisture level or brightness, and how far it overshoots.
Every one of these needs a baseline to compare against. "My fan is smart" means nothing on its own. "My fan holds the room within a narrower band than switching by hand" is testable.
Six smart home science fair projects
Each of these can be built in a weekend and measured over a few evenings. The point is the middle two columns: pair a measurable question with an honest control.
| Project | Measurable question | What to measure | Control |
|---|---|---|---|
| Daylight-aware light | Does automatic dimming to a set brightness use less energy over a day than a fixed always-on bulb? | On-time and power; light level | Same bulb on a manual switch |
| Motion-activated light | How much on-time does motion control save versus leaving the light on, and how often does it miss a person? | Minutes on per hour; missed and false triggers | Light left on the whole session |
| Temperature-controlled fan | Does closed-loop control hold a target temperature more tightly than switching by hand? | Temperature over time; overshoot; time in band | Manual on and off by a person |
| Soil-moisture watering | Does moisture-triggered watering use less water than a fixed daily schedule while keeping soil in a healthy band? | Water volume; soil moisture readings | Fixed once-a-day watering |
| Smart geyser timer | Does heating water only in set windows use less energy than keeping it hot all day, while still being hot at shower time? | Heating on-time; water temperature at use times | Geyser left on continuously |
| Door or window alert | How quickly and reliably does the system report an opening? | Latency from open to alert; false negatives and positives | A person watching by hand |
The geyser timer is worth calling out for a South African audience. A water heater is often the biggest single load in a home, and with load shedding forcing us to think about when energy is used, a project that shifts heating into short windows is both measurable and genuinely useful.
Design a fair test
A fair test changes one thing at a time and keeps everything else constant. That is easy to say and easy to get wrong. Run the smart version and the control under the same conditions: same room, same time of day, same load, same starting temperature. Then repeat. A single run tells a judge almost nothing, because one odd evening can flip the result. Aim for at least five to ten runs of each setup and log every reading with a timestamp.
Write down your sources of error too. A window left open, a cloudy day, a warm afternoon — naming these shows you understand the test, and judges notice.
Present the data so judges believe it
A simple chart beats a wall of text. Put the smart version and the control on the same graph so the difference is visible at a glance, and keep a table of the raw runs underneath so nobody thinks you cherry-picked. Label your axes and state the units. End with one plain sentence that answers your original question, and one sentence on the limits of what you found. A photo of the actual setup, not a stock image, tells the judge you built it yourself.
What to build it on
Most of these run on a single microcontroller and a few sensors: a light sensor, a motion sensor, a temperature sensor, a soil probe, a magnetic reed switch. We build ours on the sheenbot∞ board, which has the inputs and an on-board display for logging readings during a run, and a starter kit from the store covers the common sensors. If you would rather build with guidance, our holiday workshops walk students through a measured project from question to graph. The advice above works with any board, though — the experiment is what scores, not the brand of the chip.
Build-and-test checklist
- Write the question as a comparison with a number in it.
- State a hypothesis and the result that would prove or disprove it.
- Build the smart version and a control you can run side by side.
- Fix everything else: same room, same time, same load.
- Run at least five to ten trials of each and log every reading.
- Chart the treatment against the control; keep the raw table.
- Write one sentence answering the question, and one on the limitations.
- Rehearse a two-minute explanation a judge can follow.
Takeaway
The projects that impress are rarely the flashiest. They are the ones with a sharp question, an honest baseline, and a graph that makes the answer obvious. Pick one build from the table, add a control, measure it properly, and you will have something a judge can actually score. For more project write-ups, browse the newsroom.
How many trials should I run?
More is better. Aim for at least five to ten identical runs so one strange reading does not decide the result. Report the spread of your readings, not only an average.
What if the smart version does not save anything?
A negative result is still a result. Judges reward an honest, well-run test over a staged win. Explain why the numbers came out that way and what you would change next time.
Do I need internet or an app?
No. A project that logs to an on-board display or writes readings to a file is easier to run repeatably, and easier to defend, than one that depends on wifi holding up during judging.
