Case study
Emelbe Pond septic pump monitor
The Emelbe Pond Homeowners Association relies on four pumps to keep its shared septic system running. A failed or overworked pump can mean an expensive emergency, and nobody had a way to see what the pumps were doing until something went wrong. Five Lakes Studio designed and built a monitoring system that watches every pump around the clock and reports to the board.
Two critical pump failures caught early. Over the last four months the system has caught two separate critical pump failures before they could damage the septic system.
One happened while the board member responsible for the septic system was away on vacation. Because the pumps can be monitored remotely and a summary email arrives every morning, the problem was spotted right away instead of waiting until they got home.
What we built
- Sensing. Current switches on all four pumps (two 110V, two 220V) detect every on and off cycle without modifying the pumps.
- Cellular controller. An Arduino-based controller with its own cellular connection, so it doesn't depend on anyone's Wi‑Fi. It reports each pump event as it happens and checks in with a regular heartbeat that includes battery and signal health.
- Built to keep running. A backup battery keeps the controller alive through power outages. Events are buffered on the device and delivered once the connection returns, and a low-power mode preserves data if an outage runs long.
- Self-hosted backend. A lightweight server exposed securely through a Cloudflare Tunnel, with no open firewall ports and no cloud subscription fees. Every message from the controller is cryptographically signed.
- Live dashboard. Current status for each pump, run time, cycle counts, 14-day trends, and per-pump detail views with calendar heatmaps.
- Alerts and reports. Long pump runs of two hours or more are flagged automatically, the dashboard shows when the controller goes offline, and a daily summary email goes to the board every morning.
- Records. CSV export for any date range and manual meter readings for cross-checking the physical counters.
How we built it
We started with the smallest thing that could be useful and grew it as the board used it. The first working server and dashboard went up the same day the project started, and each feature after that began as a short written plan.
- Early JuneWorking prototype. A server and live dashboard on day one, then pump-meter readings, battery monitoring, and email notifications within the first few days.
- Mid JuneField-ready firmware. Signed messages from the controller, a hardware watchdog, cellular connectivity, and firmware 1.0 within the first week, followed by a run of quick releases as we tuned the cellular link in real conditions.
- Late June to early JulyHardening. A low-power mode for long outages, reboot alerts by email, and recovery for stuck cellular connections. When the microSD card turned out to cause more trouble than it solved, we removed it and moved storage onto the controller's built-in flash.
- JulyReporting. A daily summary email to the board, plus per-pump detail pages with calendar heatmaps and long-run flags.
- August to nowReliability and security. Root-cause fixes to the cellular connection, and ongoing security reviews of the dashboard and server.
Key decisions
- Cellular, not Wi‑Fi. The pumps sit away from any home network, and the system shouldn't stop working because someone changed a router.
- Self-hosted, not a cloud subscription. The association owns its data, and there's no monthly platform fee to justify each year.
- Ride out outages. The controller timestamps and stores each pump event on the device and sends it once the connection returns, so a power or network outage delays reporting instead of erasing it.
- Security from the start. The controller signs every message, and editing the dashboard requires a separate passphrase, so neither one can be used to impersonate the other.
- Simpler beats clever. When a part or feature caused more problems than it solved, like the microSD card, we took it out.
When something goes wrong
In August the controller started failing to reconnect to the cellular network. The first theory was the backup battery. We kept digging and found the real cause the same day: two firmware bugs, one of which made the diagnostic readings themselves misleading. Both were fixed, and the investigation was written up, including the theory that turned out to be wrong, so the next person to look at it starts from the facts.
Results
Over the last four months the system has caught two critical pump failures before they could damage the septic system, including one while the board member who maintains it was out of town. The association now has continuous visibility into pump health, early warning of unusual runs, and a history to support maintenance decisions, all from inexpensive off-the-shelf hardware.
Our approach
People first
We built this with the board member who looks after the system, shaped it around how the board actually uses it, and kept improving it as their needs came up.
AI as an accelerator
We use AI tools to draft, review, and test faster, which keeps costs down and leaves more time for quality. People make the decisions, review every change, and own the result.
Plan, test, write it down
Written plans before building, testing on the bench before the field, and a clear record of what changed and why.
Have equipment you need to keep an eye on?
We'd be glad to hear about it.
Five Lakes Studio