IO1: How embedded and IoT systems are different
From sensor to dashboard
🎯You'll be able to
Trace a reading from the physical world to the person who acts on it, and name what can go wrong at each step.
🏠The everyday picture
A letter goes from a village post box to a sorting office, onto a bus, and to a city desk. At each step it can be delayed, lost or delivered twice, so important letters carry a number and get a receipt.
📘What it really is
- Sensing: the sensor turns something physical (distance, temperature, light) into a signal or a number.
- On the device: the firmware reads it, checks it, converts it to useful units, and decides whether to keep or send it.
- Storage on the device: readings wait in flash when the network is down.
- Transport: a radio sends messages, often with a lightweight protocol such as MQTT or CoAP (IO7).
- The broker or gateway: receives messages and passes them on. A gateway can also process data near the devices (edge computing).
- The server: stores readings, removes duplicates, spots gaps and alarms, and feeds dashboards and messages to people.
- What goes wrong: a sensor glitch, a reading lost in a power cut, a message lost or sent twice, a clock that's wrong, a dashboard that shows "online" for a device that died.
📝A worked example
Input: a JalSetu reading at 21:00 shows the tank at 47%.
Steps:
- The LV-20 measures 1,060 mm to the water; the firmware works out 940 mm of water, 47% of the 2,000 mm tank.
- The reading gets sequence number 312 and waits in flash; on the hourly send it goes to the broker with QoS 1.
- The server stores it once, even if it arrives twice, and the dashboard shows 47% with the time it was measured.
Expected output: a step-by-step trace with one possible failure named at each step.
🌍Where it's used
- Cold chains track a vaccine fridge's temperature from the fridge to a district office.
- Factories trace a machine's vibration from a sensor to a maintenance team.
- Smart homes trace a door sensor to a phone notification.
📝Case scenario
A cold-storage company's dashboard showed temperatures from three hours earlier as if they were current, because it used the time the message arrived, not when it was measured. Adding the measurement time to each message fixed the confusion.
🖱️Try it
Trace one JalSetu reading through the parts above and name one thing that could go wrong at each. Success: six steps, six failures.
⚠️Common mistakes
- No time on readings. Sign: delayed readings look current. Fix: send the time each reading was taken.
- No sequence numbers. Sign: duplicates and gaps can't be told apart. Fix: number each reading.
- Trusting "online". Sign: a dead device still looks fine. Fix: a last will and a "last heard" time (IO7).
🛠️For your project
Project 2's messages carry seq and ts for exactly these reasons.
✅Quick check
Why does each reading carry the time it was measured?
Show the answer
So readings delivered late aren't mistaken for current ones.
Why does each reading carry a sequence number?
Show the answer
So the server can spot duplicates and gaps.