IO8: Store-and-forward and edge computing
Edge computing: deciding on the device
🎯You'll be able to
Filter, summarise and act on data at the edge, and decide when a gateway is worth adding.
🏠The everyday picture
A security guard doesn't phone the office every minute to say "still quiet". They call when something happens, and check in once an hour so the office knows they're fine.
📘What it really is
- Edge computing: processing data on or near the device instead of sending everything to the cloud.
- Deadband: keep a reading only when it has changed by more than a set amount (JalSetu: 10 mm). Small noise isn't sent.
-
Heartbeat: send at least one reading every so often (JalSetu: hourly) even if nothing changed, so silence means a problem, not a steady tank.
-
Alarms bypass filters: a low-tank alarm is sent straight away, whatever the filter says.
- Summaries: send the minimum, maximum and average for a period instead of every sample, when the detail isn't needed.
-
Gateways: a nearby hub that collects data from small devices (often over a low-power radio), filters it, and forwards it. It can also keep working when the internet is down.
-
Keep the raw data where it matters: filtering throws information away. Keep enough to answer the questions people will ask.
📝A worked example
Input: a full tank that isn't being used for 8 hours (32 wakes).
Steps:
- Without filtering, 32 readings are stored and sent.
- With a 10 mm deadband and an hourly heartbeat, 8 readings are kept.
- When people start using water and the level falls 40 mm, every reading is kept again. When the tank goes below the alarm level, the device sends at once.
Expected output: about one reading an hour when nothing happens, full detail when it does, and alarms straight away.
🌍Where it's used
- Factory machines: vibration analysed on the device; only alerts and summaries go to the cloud.
- Cameras: detect motion locally and upload only the clips that matter.
- Smart buildings: a gateway per floor collects from hundreds of sensors.
📝Case scenario
A cold-room sensor sent a temperature every 10 seconds. The data bill was high and the dashboard was hard to read. With a 0.5 °C deadband, a 15-minute heartbeat and immediate alarms, traffic fell by over 90% while every temperature excursion was still recorded. These figures are illustrative.
🖱️Try it
Choose a deadband and heartbeat for a room temperature sensor where only changes of 0.5 °C matter and the team must know within an hour if a sensor dies. Success: 0.5 °C and a heartbeat of an hour or less, with a reason.
⚠️Common mistakes
- No heartbeat. Sign: a quiet sensor and a dead sensor look the same. Fix: a regular heartbeat.
- Filtering alarms. Sign: an urgent event waits for the next send. Fix: alarms bypass the filter.
- Filtering away what people need. Sign: questions the data can't answer. Fix: agree the detail needed first.
🛠️For your project
Project 2's test 9 checks that a steady tank keeps at most 60 readings in 192 wakes, and that an alarm is sent straight away.
✅Quick check
Why does a filtered sensor still need a heartbeat?
Show the answer
So silence means something is wrong, not just that nothing changed.
What does a gateway add between small devices and the cloud?
Show the answer
It collects, filters and forwards their data, and can keep working when the internet is down.
