Use the left and right arrow keys to change slides. Home selects the first slide and End selects the last.
Build the system.
Not just the code.
Most IoT courses stop at the dashboard. SenseLink Lab starts at the pin: real boards, edge programs, gateway rules, network faults and a run report that can be defended.
Slide 1 of 4: Pin-level hardware. ESP32, Arduino and physical sensors on one canvas. Every terminal has a role, and every board exposes its real pins.
Controller boards
ESP32 · Arduino · Pi
Sensor models
Climate · presence · range
Actuators
Pumps · fans · locks
Server tick
Deterministic virtual time
Go binary
Plus SQLite & Centrifugo
No fake dashboards.
No happy paths.
No fake dashboards.
Every value comes from a server tick, a wired pin or a delivered packet.
No happy paths.
Sensor drift, dropped commands and power loss are part of the exercise, not an edge case.
No cloud lock-in.
One Go binary, one SQLite file and a realtime container your institution controls.
No evidence, no argument.
The run report is the artefact: metrics, faults, events and the explanation that connects them.
One canvas.
Every layer.
Hardware, edge code and gateway logic are not separate demos. They share one project, one run clock and one evidence trail, so students can see the whole system respond.
Explore the documentationESP32
PIR
RELAY
Auto draw assigns free pins
Board · pin · terminal
Wire the real board.
Drop hardware artwork onto the canvas. Every controller exposes its actual pins, and every sensor or actuator exposes its own power, ground and data terminals.
- 5 controller boards, 18 sensor models and 14 actuators
- Auto draw assigns free pins and tidies the bench
- Schematic generated from the project, not a separate drawing
The sensor is not a number.
It has a pin and a failure mode.
A DHT22 reports a temperature over a data pin. A PIR reports presence as a level. A relay can miss a command and leave a pump running. SenseLink Lab keeps those physical facts in the model instead of hiding them behind a dashboard.
Pin-level terminals
Power, ground, data, signal and network roles are validated by the API.
Physical feedback
A running pump raises soil moisture. A fan changes temperature on the next sample.
Faults stay physical
Sensor drift and actuator failure change the run, not just a status badge.
Climate probe
DHT22
Drift makes a hot room look safe.
Presence sensor
PIR
A level, not an event. It stays true.
Actuation
Relay + pump
A lost command still leaves it running.
Network boundary
LoRa gateway
The cloud decides on stale telemetry.
sense
DHT22
pin
GPIO4
edge
ESP32
link
LoRa
gateway
Rule
actuate
Relay
physical
Pump
Start from a system
that already works.
Every field lab ships with a working device set, pin map, edge program, gateway rules and a fault drill. Change one variable at a time and compare the evidence.
Browse all six field labs
A run is not
a slideshow.
Virtual time advances in 100 ms server ticks. Controller code runs before every telemetry packet. Rules evaluate the last delivered sample. Commands travel back over a link that can delay or drop them.
100 ms
Server tick
250 ms
Rule clock
30 ms
Sandbox watchdog
1 seed
Reproducible runs
Soil A
34.2%
Pump A
ON
Latency
842 ms
Drops
27
From brief to evidence
in four moves.
The lab is designed around a classroom loop, not a feature list. Students build, observe, break and explain. Instructors review the trail instead of reconstructing it.
Design the system
Choose a field lab, then add controllers, sensors and actuators. Wire the real pins and let auto draw tidy the bench.
Program the edge
Write a local control loop that keeps working when the link does not. Compare it with a gateway rule using the same telemetry.
Break it deliberately
Inject sensor drift, actuator failure, battery drain or packet loss. Watch what changes physically, not just on the dashboard.
Defend the result
Export the run, cite event timestamps, compare metrics and explain the design change you would make next.
The run leaves a trail.
The trail becomes the mark.
Rule triggers, fault injections, run metrics and event history are persisted. Students export the evidence; instructors review the same project and run from the dashboard.
Run report
Greenhouse / zone A
Run
#084
Seed
A91-4F2
Scale
2×
Started
10:42
Duration
04:18
Owner
Student
Yours to host.
Yours to audit.
One Go binary, one SQLite file and a Centrifugo container. No external database, no third-party cloud and no student data leaving the institution.
Read the deployment notesOne Go binary
HTTP API and simulation engine in a modular monolith.
One SQLite file
Labs, runs and evidence in a single backupable file.
Centrifugo realtime
Short-lived JWTs and namespaced project channels.
Explicit CORS
Browser origins and realtime origins are allowlists.
$ make dev
centrifugo :8000 · api :3001 · vite :5173
Run the system before
the lab does.
Give students a safe place to wire hardware, write edge code, break the network and defend the result with evidence.
One server
Go API, SQLite and Centrifugo. No external database.
Six field labs
Wiring, edge code, rules and a fault drill in every project.
Run evidence
Metrics, events and reports an instructor can audit.