What you'll learn
Quick Answer
Work through four stages: output (Blink), input (a sensor), decision (act on a threshold), and reliability (handle bad readings). The fourth stage is what separates a demo from a project, because real sensors lie and real buttons bounce.
What you actually need to start
Less than most kit listings suggest. To do everything in this article you need an Arduino UNO, a USB cable, a breadboard, some jumper wires, a few LEDs with resistors, and one or two sensors. Buying a large starter kit is fine, but you will use about a fifth of it.
You also need somewhere to write the code. The official Arduino IDE works. If you would rather see the code being built rather than typed from scratch, Priodemy Labs is a free Windows application where you drag blocks and the equivalent Arduino C++ appears next to them — and it includes a simulator, so you can run all of stage one and two before your parts arrive.
That last point matters more than it sounds. The single biggest reason beginners stall is a wiring fault they cannot distinguish from a code fault. Being able to run the program on a virtual board first tells you which half of the problem you are looking at.
Stage 1 — Output: make something happen
This is Blink, and there is no shame in starting here. It proves your board, cable, drivers and upload process all work — which is genuinely the thing most likely to be broken on day one.
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
digitalWrite(LED_BUILTIN, HIGH);
delay(1000);
digitalWrite(LED_BUILTIN, LOW);
delay(1000);
}Two functions, and they explain the whole Arduino model: setup() runs once when the board powers on, and loop() runs forever afterwards. Every project in this article is a variation on that.
The natural next step is a traffic light — three LEDs cycling red, green, yellow. It adds nothing conceptually new, which is exactly why it is a good confidence build before the harder stages.
Stage 2 — Input: let the board sense something
Now the board reads the world instead of only acting on it. The cheapest useful sensor is an LDR, a light-dependent resistor, wired to an analog pin.
void setup() {
Serial.begin(9600);
}
void loop() {
int light = analogRead(A0);
Serial.println(light);
delay(200);
}Open the Serial Monitor and cover the sensor with your hand. The numbers move. This is the moment Arduino stops being a toy, because you now have real data — and real data has a property tutorials rarely mention, which is that it is noisy.
analogRead() returns a value from 0 to 1023 on an UNO. It does not return light in any unit. Turning that raw number into something meaningful is called calibration, and it is a genuinely good thing to be able to discuss in a viva.
Stage 3 — Decision: act on a threshold
Combine the first two stages and you have an actual device: read a value, compare it to a threshold, do something. An automatic night lamp is the classic version.
const int LAMP = 8;
const int DARK_BELOW = 300;
void setup() {
pinMode(LAMP, OUTPUT);
Serial.begin(9600);
}
void loop() {
int light = analogRead(A0);
if (light < DARK_BELOW) {
digitalWrite(LAMP, HIGH);
} else {
digitalWrite(LAMP, LOW);
}
delay(200);
}Same idea, different sensor, and you have most of the popular beginner projects: a soil moisture sensor gives you automatic plant watering, a gas sensor gives you an air quality monitor, and a temperature and humidity sensor gives you a weather station.
At this point you have a working demo. You do not yet have a project, because of what happens in stage four.
Stage 4 — Reliability: the stage that makes it a real project
Real sensors produce occasional nonsense. A loose wire, electrical interference, or a momentary drop in supply voltage will give you one wildly wrong reading in the middle of a stable run. If your threshold check sees that reading, your pump switches on.
The instinct is to average the last few readings. That does not work, because an average is dragged by the outlier. With five readings of 512, 515, 9999, 511, 514, the average is 2410 — a number that appears nowhere in reality and is above almost any threshold you would set.
Take the median instead. Sort the five values and use the middle one, and the same readings give 514, which is correct.
const int N = 5;
int buf[N];
int idx = 0;
int median5() {
int tmp[N];
for (int i = 0; i < N; i++) tmp[i] = buf[i];
// insertion sort -- N is 5, so this is plenty fast
for (int i = 1; i < N; i++) {
int key = tmp[i];
int j = i - 1;
while (j >= 0 && tmp[j] > key) {
tmp[j + 1] = tmp[j];
j--;
}
tmp[j + 1] = key;
}
return tmp[N / 2];
}
void loop() {
buf[idx] = analogRead(A0);
idx = (idx + 1) % N;
int stable = median5();
Serial.println(stable);
delay(200);
}The second reliability problem is bouncing. A mechanical button, or an RFID card held near a reader, does not produce one clean event — it produces a burst. A card held for two seconds while the loop polls every 100 milliseconds generates 20 scan events. Without debouncing, a parking system bills that card twenty times.
The fix is to ignore repeat readings of the same value within a time window, which reduces those 20 events to 1. Our RFID parking build handles exactly this case.
There is a third, and it is the one worth talking about in a viva: what happens when the sensor fails completely? If a moisture sensor dies and reports permanently dry, a naive watering system runs the pump until the plant drowns. A fail-safe — a maximum run time per watering, regardless of what the sensor claims — turns a project that works into a project that is engineered.
Where to go after the UNO
Once threshold-and-reliability feels routine, the interesting direction is connectivity. An ESP32 costs about the same as an UNO and has Wi-Fi built in, which turns any of the above into an IoT project: the same sensor, but readings sent to a dashboard you can open on your phone.
That is a genuine step up in difficulty, because you inherit an entire second category of failure — the network. Readings buffer when Wi-Fi drops, timestamps need to come from somewhere, and you have to decide what happens to data collected while offline.
If you want to see finished versions with the wiring and the code written out, the IoT track in our projects catalogue has several builds you can read through end to end.