Context and scope
A prototype monitoring system for an aquaponics setup, running on real hardware rather than simulated inputs. The design concern is getting sensor readings from a microcontroller to a person, both while they are watching and while they are not.
System design
Hardware
A Raspberry Pi 3 paired with an Arduino Mega or Uno, carrying an HIH6130 humidity and temperature sensor, a DS18B20 waterproof temperature probe for the water itself, and a BMP280 for temperature and barometric pressure.
Acquisition
A Node.js and Express service reads the Arduino sensors through Johnny-Five over the Firmata protocol, so the microcontroller runs a standard firmware and the read logic lives in application code on the Pi rather than in a sketch that would need reflashing to change.
Transport
Readings stream to a browser interface over Socket.io, so the display updates as values arrive rather than on a polling interval.
Interface and access
A React frontend renders the live readings, with Passport handling authentication.
Out-of-threshold behavior
An unattended dashboard is the failure mode this system exists to cover, because the condition it watches for, water chemistry drifting out of range, develops over hours and does not wait for someone to be looking at a browser tab.
Each reading is compared against a configured threshold band on arrival. A reading outside its band sends an SMS through Twilio, which moves the notification off the screen and onto a device the operator carries.
This is the one path in the system that assumes no observer. Everything upstream of it, the Firmata reads, the Socket.io stream, the React display, is a live view that only has value while someone is watching it.
Design decisions
| Decision | Rationale |
|---|---|
| Read the Arduino through Johnny-Five and Firmata | Keeps the sensor logic in application code on the Pi, so changing what is read or how it is interpreted does not mean reflashing the microcontroller. |
| Push readings over Socket.io rather than polling | The consumer is a live dashboard, and polling either wastes requests at rest or adds latency under change. |
| Send SMS on threshold breach | A dashboard only works while someone is looking at it. The failure this system exists to catch, water chemistry drifting overnight, happens when nobody is. |
Verification status
Verified from a detailed README and a presentation of the working prototype, rather than by a full source read.
What that substantiates: the hardware inventory, the acquisition path through Firmata, the real-time transport, and the alerting integration, all running on assembled hardware.
Not verified: sensor accuracy against calibrated reference instruments, uptime over a sustained deployment, or alert reliability.
Known limitations
Maturity
A prototype. There is no production deployment, no persistence strategy beyond the running system, and no recovery behavior if the Pi restarts mid-session.
Companion service
A separate aquaponic-api Node service provides sensor routes, but it is thin, at four commits, and is better described as a stub than as a second component.