How the Raspberry Pi, the database and the screens fit together, and which device actually controls each part of the tank.
Published
Purpose
This page answers how the monitoring system is built and where control sits. It is the reference for anyone weighing a similar build, and the map the other documentation pages hang from.
Background
The tank runs on devices that each have their own controller: a Neptune Apex for outlets and probes, a Chihiros light, an EHEIM filter and a Red Sea doser. None of them shares data with the others. Pearl is the layer that reads all of them, stores what it finds in one database and presents it on a dashboard, a wall screen and a desk display. It was built to observe first; the few things it controls are listed under Methodology, and none of them is life support.
Methodology
01A Raspberry Pi beside the tank runs small services on timers. Each does one job and writes its result to the database rather than talking to the other services.
02The Apex is read over the local network every few minutes for pH, temperature, outlet states, power draw and its safety inputs. A faster loop keeps a near-live snapshot for the screens.
03The filter and the doser are read over their local interfaces. The light, the heater and the wavemaker are read over Bluetooth. Conductivity comes from an Atlas Scientific EZO circuit on the Pi, temperature-compensated with the live tank temperature.
04Everything lands in one Postgres database: a readings table that forms the spine of every chart, a journal of events, test-kit results, a PAR survey, an equipment inventory and one current-state document per device.
05A web application reads that database and renders the same board three ways: a scrolling dashboard, a wall screen fitted to an older tablet, and a widescreen desk display.
06Control is deliberately narrow. The Apex switches the outlets and runs the CO₂ on a timer; the light and doser keep their own schedules. Pearl controls three things: a water-change mode on the Apex, the filter's calmer daytime and stronger overnight flow, and the brightness curve of a light screen behind the tank.
07Alerting runs in two places so that one failure cannot silence both. Grafana on the Pi evaluates rules against the database. A separate watchdog on the web host checks that the Pi is still reporting, and checks the things the Apex has no way to know: whether the light has power during its photoperiod, whether the heater's own sensor agrees with the Apex probe, whether the doser has lost its clock, whether water-change mode was left on.
08A compressed snapshot of the whole database is written to private storage each night and kept for fourteen days.
Observations
·Keeping the Pi out of the control path for CO₂, heat, light and dosing means that when the Pi, the database or the web host fails, the tank carries on unchanged.
·Services that read their settings straight from the database keep running the last saved schedule through a hosting outage.
·Every figure is labelled by where it came from: read from a device, calculated from a schedule, or unavailable. The light is the standing example. Its controller does not report live output and the outlet feeding it stays powered all day, so its state is calculated from the programmed schedule and said to be.
·Dissolved CO₂ is not measured. The measured quantity is the pH swing between the day's high and low, and the display leads with that.
·A written daily review produced by a language model is only as good as the facts it is given. Told plainly what controls the CO₂, what the fertiliser contains and how old the last test result is, it is useful. Without those it gives confident advice about a different tank.
·A backup that fails silently is the same as no backup. The nightly snapshot outgrew its upload limit and failed for some time before the failure was recorded anywhere a person would see it.
Scope
·What does the Raspberry Pi read, and how?
·Which device controls the CO₂, the light, the filter and the dosing?
·What happens to the tank if the monitoring system fails?
·How is the data stored and backed up?
·Which values are measured and which are calculated?
·How do alerts reach a phone, and what catches a failure of the Pi itself?