An example — assembled from the event and one tap
02:14Tank 2 · pH 7.62, below range
02:19responded: water change
04:40Tank 2 · back in range, 8.04
For stores and racks
Nobody is watching the building when you are closed
A controller is built to automate a tank. A store does not need that. You have staff with their hands in the water twelve hours a day, and they are better at it than software is. What no store has is a record of the other twelve hours. This is built for documentation and display, not automation.
Documentation, not automation
For a hobbyist this is a control system. For you it is a witness: it watches, it writes down what happened, and it shows you the history. Control is something to add later, if you ever want it. It is the same hardware the reef version runs — what would change is that the three-node cap comes off, and that the screen is built for a building rather than a tank.
None of that store build exists yet. The hardware is the same hardware, in build and testing now. The screen described below — the sump bank, the incident timeline, the alert that asks a question, the alarms that go quiet during known work — is designed and decided, not built. This page is here to be argued with before any of it gets made, and that is what the questions further down are for.
You are closed half the day
And all weekend, in some casesEvery system you run is another chance that one of them fails tonight. The failure itself is rarely the expensive part. The twelve hours before anyone walks in and sees it are.
Shared sumps cut both ways
The thing that saves you also scales the damageOne sump per bank is efficient, and it means a single heater running away takes the rack rather than the tank. Centralization is an argument for watching the system, not an argument that the system watches itself.
Alerts that fire during normal work are worse than none
Muted once is decorative foreverDaily water changes across many systems will trip a naive threshold constantly, and a product that cries wolf during a water change gets silenced in week one. So known work has to suppress alarms on the systems being worked on. Designed and decided, not built — and of everything on this page, it is the piece the rest of it depends on.
The parameter that kills you cannot be sensed
In a fish-only rack the thing that wipes a system is ammonia after a death. One fish dies overnight, ammonia spikes, the bank follows. There is no continuous ammonia probe worth trusting in saltwater, and the reason is not the one I used to give.
So the answer is not a better sensor. It is capturing what happened and what was done about it, at the moment it happens, without relying on anyone deciding to write it down.
The alert asks the question
When something fires, the alert itself asks what happened, with preset answers: water change, added carbon, removed a fish, nothing, other. Two taps and the record exists. Nobody has to keep a journal, because a blank journal screen gets used for three weeks and an alert that asks one question gets used for years.
Two years of that, across every system in the building, is the thing worth having. It turns scattered incidents into a trail you can actually follow back. It also gives you nothing in month one. The value compounds, which means the first month is thin.
What is on the store screen
A store tank that dies overnight is far more likely to have gone to a leak, a heater that stuck on or a pump that stopped than to chemistry drifting. Every one of those shows up first as a level or a temperature, not as an alkalinity number. So that is what the screen watches, per system rather than per tank, along with the record of what happened while nobody was in the building.
That is my reasoning and not a measurement. I went looking for somebody who had counted it and did not find them, so it is the one claim on this page resting on judgement rather than on something you can check.
Sump bank
Every sump on site, level and trend, on one screen. A sudden drop on system 3 overnight is a leak or a failed top-off, and it is an alert nobody currently gets.
Temperature by system
Per rack rather than per tank, because the rack is the unit that actually shares water and shares failures.
Incident timeline
Events with the responses attached to them. This is the part that is hard to replace once you have two years of it.
Water change history
Per system: how often, when last, how long since. A level reading answers a different question — is water leaving this system. It cannot tell you when the system was last serviced, because a topped-off sump sits at the same height whether the last change was Tuesday or in March. That answer only exists if something recorded it at the time.
What sump level does not tell you
Sump level does not tell you a water change is due. It tells you about evaporation, leaks and top-off failure. Those are two different features and I build them as two different features.
How level is measured
Why a number and a trend are a different instrument from a float switch.
Your turn
What I need to know from a store
Nothing here is a promise and nothing is being sold. Five questions, none of them required, from someone who has stood in front of a rack and has never run one. The last one is a box to write in, and it is the one I actually want.
Before anything goes on your systems
Nothing goes into a working building on trust. Where it starts, what it is allowed to touch, and what happens if a system crashes are settled before an install rather than after an incident.
It starts on your least valuable system
A frag tank, a holding system, quarantine. Never the display tank at the front of the store, and never on a system whose loss you would actually feel.
Beta
What every beta tester signs up for, and what gets agreed in writing before a
unit ships.