Poolboy
Poolboy gives a pool-control app and CLI one interface for pool equipment. Its Pentair adapter speaks an unpublished cloud protocol I reverse-engineered and tested on a live system.
The app was the documentation
I traced the Android app’s login flow and request signing, recorded its API traffic, then changed one pump setting at a time and compared the state before and after. Those differences revealed what the opaque fields meant: telemetry, programs, schedules, relays, lights, priming, and operating limits.
“Selected” is not “running”
Pentair’s summary retains the last selected program even when a different program is running. Treating that field as live state can put the wrong speed or schedule on screen. Poolboy reads each program’s runtime state to find the active one and keeps selection separate from execution.
A command ends with a state read
A successful cloud response means the request was accepted; the equipment’s next state tells the client what happened. Poolboy reads back after changes to reconcile program state, speed or flow, and other settings. Session renewal stays inside the adapter, so both clients recover through the same login and request-signing path.
One adapter per manufacturer
Everything specific to Pentair stays in its adapter: sign-in, request signing, payloads, and field mapping. The app and CLI use Poolboy’s API to ask what the connected equipment can do, read its current state, and send commands. Supporting another manufacturer means writing one adapter, not teaching both clients a new protocol.
From protocol work to two clients
The core exposes a stable C ABI and an XCFramework for macOS, iOS, and the Simulator. The CLI links directly to it, giving protocol investigation and the native interface the same decoding and command behavior.
On a live Pentair system, Poolboy handles discovery and telemetry, starts and stops pumps, sets speed or flow, edits schedules, configures relays and lights, and adjusts priming and pump limits.