We established a high-confidence working estimate that my pool contains 26,600 gallons, then inferred Pump 1’s filtration flow in gallons per minute from the RPM and watts Home Assistant was already recording.
The problem surfaced during six days in July, when both pool pumps ran at 3,400 RPM while I fought an algae bloom. When the water finally cleared, my automation could tell me exactly how long each pump had run. It could not tell me how much water Pump 1 had actually sent through the filter.
It counted minutes.
Minutes are not water.
To control filtration by water processed, I needed two missing quantities: the volume of the pool and Pump 1’s filtration flow at each operating state. The pool came with the house, and the plumbing had no flow meter. I assumed the next step was new instrumentation.
Instead, Codex helped me discover that Home Assistant had already recorded fragments of the experiments I needed: cold fill water disturbing a warm pool, heating cycles revealing thermal mass, and Pump 1’s electrical load changing as the hydraulic circuit changed.
Those traces converged on the volume estimate and a conservative model of filtration flow. But the numbers are not the most interesting result.
The larger lesson is that operational data collected for one purpose can become evidence for another, if AI can reconstruct enough context to determine what each observation is allowed to mean.
Home Assistant orchestrates a custom controller I built around an ESP32. It manages two variable-speed pool pumps, automatic filling, sand filtration, boiler-driven heating through a Carlson 5.0 ST stainless steel plate heat exchanger, and chlorination.
The two pumps have different jobs. Pump 1 serves filtration, heating, and the floor cleaning heads. It is the pump whose inferred flow can count toward filtered gallons. Pump 2 serves circulation and cleaning heads on the benches, sides, and steps. It helps mix the pool during fill and heating episodes, but its flow bypasses the sand filter and is not counted as filtration.
How the evidence connected
| Missing quantity | Existing evidence | Physical relationship | Result |
|---|---|---|---|
| Pool volume | Fill gallons, fill-water temperature, mixed pool-temperature response, normal cooling | Mixing and thermal balance | Working range around 26,600 gallons |
| Second volume estimate | Heat-exchanger temperatures, heating duration, circulation state, pool warming | Heat balance | Convergent mid-20,000-gallon estimate |
| Pump 1 filtration flow | RPM, watts, plumbing topology, certified pump tests | Pump curve, system curve, operating-point constraints | Conservative inferred GPM |
| Daily water processed | Valid Pump 1 GPM estimates over time | Flow integration | Pool-volume equivalents processed |
The estimates did not come from one clever correlation. They came from several incomplete observations becoming mutually constraining when placed inside the correct physical model.
Before the math, reconstruct the state
Codex did not begin by rewriting my automation. It began by asking about the physical system. Which Pentair pump was installed? What were the filter and heat-exchanger specifications? Where were the temperature sensors? What changed when a valve moved? When did fill pulses belong to the same refill episode?
This was not a one-shot prompt. I supplied the installed-equipment identities, plumbing topology, sensor locations, controller behavior, and access to the recorded history. Codex proposed relationships worth testing, asked for missing constraints, identified candidate episodes, and helped reject readings that did not represent the physical state we needed. I checked those interpretations against the installed equipment and the other evidence available.
That division of work mattered because the first problem was not the math. It was deciding what each observation meant.
A temperature reading taken with Pump 1 off was not the temperature of the pool. It was the temperature of stagnant water in a pipe, slowly drifting toward the equipment room. Several auto-fill activations could be safety-limited pieces of one refill. A temperature slope meant something different when the boiler was on, when cold water was entering, or when circulation had just restarted.
RPM needed context too. Pump 1 could hold the same speed while its electrical load changed because a rotating cleaning valve had changed the circuit around it. Codex did not make the data useful by averaging more of it. It made the data useful by determining what each observation was allowed to mean.
The auto-fill had already run an experiment
The controller knew how many gallons of fresh water entered the pool. That water was colder than the pool, so a refill created a measurable thermal disturbance.
Fill volume + fill temperature + mixed pool-temperature response → inferred thermal mass → estimated pool volume
One useful episode added 1,427 gallons of 69.5 °F municipal water. Both pumps ran throughout the event, keeping the pool mixed, and the boiler remained off. The pool temperature fell by 2.38 °F over the episode.
The fill analysis also had to subtract the cooling that would have happened without a refill. Across the retained fill history, the dilution method centered near 28,000 gallons but remained broad because the thermal signal from an ordinary refill was similar in size to night-to-night cooling variation. That made it useful evidence, not a precise standalone measurement.
The heater gave us a second estimate
The heater ran the experiment in the other direction. During stable boiler episodes, the sensors recorded the temperature change across the heat exchanger while the bulk pool warmed.
Estimated heat transfer ÷ observed warming rate → inferred thermal mass → estimated pool volume
The useful intervals had steady circulation, no fill activity, a stable hydraulic state, and enough duration for the warming trend to separate from sensor noise. Pump-off readings and transition periods were excluded.
One August run produced a central estimate of 24,234 gallons. A June run produced 28,040 gallons. Six additional stable runs ranged more widely, but a two-season heat-balance solve placed the useful range at roughly 24,700 to 29,400 gallons.
Why 26,600 gallons was good enough
| Method | Estimated value or range | Main uncertainties |
|---|---|---|
| Cold-fill dilution history | About 28,000 gallons; broad range | Fill temperature, mixing lag, cooling baseline, sensor state |
| Stable August heating episode | 24,234 gallons | Heat-transfer estimate, environmental loss, sensor error |
| Stable June heating episode | 28,040 gallons | Heat-transfer estimate, environmental loss, sensor error |
| Two-season heating analysis | About 24,700–29,400 gallons | State stability, heat-loss and flow assumptions |
| Adopted controller value | 26,600 gallons | Rounded, revisable working value |
These methods are not fully independent in every input, but they use different disturbances and failure modes. Cold-water dilution does not depend on the heating model. Heating episodes depend on exchanger behavior and Pump 1 flow but provide a much larger thermal signal. Independent physical relationships converged on the same useful operating range.
I have high confidence in 26,600 gallons as a working engineering value because different physical relationships converged on the same useful range. That is an engineering judgment, not a formal statistical confidence interval, and the value remains easy to replace if a direct measurement later produces a better answer.
Power revealed the hidden hydraulic state
Volume was only half the problem. I still needed Pump 1 filtration flow.
Pump 1 is a Pentair IntelliFlo VS. Its RPM does not uniquely determine GPM because flow also depends on the resistance of the sand filter, heat exchanger, plumbing, fittings, and whichever cleaning zone is active. Watts do not directly measure GPM either. They show the electrical load at that speed and help distinguish which hydraulic state is plausible.
The model used the installed pump identity and nameplate, Pentair’s IntelliFlo performance curves, the EPA’s ENERGY STAR certified IntelliFlo VS test record, and the known equipment topology. The filter is a Pentair Triton II TR60, whose published commercial flow rating is 63 GPM.
Pump 1 speed curve + estimated system curve + observed electrical power → constrained operating point → inferred filtration flow
RPM selects the relevant speed curve. The plumbing and equipment constrain the likely system curve. Their intersection represents an operating point. Electrical power provides another constraint on which point is physically plausible.
The same-RPM example made the value of watts obvious. At 2,400 RPM, Pump 1 averaged about 573 watts in one retained period and about 620 watts in another. The speed had not changed, but the circuit had. The model therefore applies only to observed or appropriately characterized states, and Pump 2 remains outside filtered-volume integration.
From runtime to pool-volume equivalents
If filtration flow remains constant, pool volume divided by flow gives the theoretical turnover time. Pump 1 does not remain at one flow, so the more useful calculation is to integrate its inferred filtration flow over time.
Estimated filtered gallons = Σ(Pump 1 inferred GPM × minutes in each valid operating state)
Pool-volume equivalents processed = estimated filtered gallons ÷ 26,600 gallons
One pool-volume equivalent means that a volume of water equal to the working pool volume has passed through the filter in aggregate. Continuous mixing means it does not represent one filtration pass for every individual molecule.
What changes in the controller
The current Home Assistant implementation already exposes calculated flow and turnover sensors, but they still use an older factor model and a minute-based scheduler. I do not treat those values as the finished implementation.
The next controller revision will integrate inferred Pump 1 flow instead of counting minutes. It will treat the 26,600-gallon pool volume and the flow model as versioned assumptions, so direct measurement or better evidence can replace them later without redesigning the automation.
The best next validation is a temporary direct flow measurement on Pump 1 across known valve states. Additional cold-fill and stable-heating episodes would test the volume model, while repeated observations as the filter loads would show when the hydraulic model needs another state.
What this model does not claim
- 26,600 gallons is a high-confidence working engineering estimate, not a direct volume measurement.
- Pump 1 GPM is inferred, not measured by a calibrated flow meter.
- The flow model applies only to hydraulic states represented or appropriately characterized by the evidence.
- Pump 2 contributes circulation and mixing but is not counted in filtered gallons.
- One pool-volume equivalent does not mean every molecule passed through the filter.
- Filtration does not replace sanitizer, pH, stabilizer, temperature, bather-load, or other water-chemistry management.
What AI changed
None of the individual ideas required alien intelligence. A controls engineer might recognize the state machine. A thermodynamicist might formulate the heat balance. A statistician might challenge the estimate. A pump specialist might interpret the certification curves. AI made that team-shaped investigation practical for one person.
A residential pool is a small system, but the pattern is not small. Buildings, factories, data centers, networks, vehicles, and software services all produce telemetry optimized for immediate operation and diagnosis. Some of that exhaust may contain natural experiments capable of answering questions it was never collected to answer.
The logs did not contain the answer. They contained fragments: a slug of cold water, a heater cycle, Pump 1 holding its speed while its electrical load changed, and a temperature probe becoming unreliable when circulation stopped.
The physical models supplied the relationships. Codex made it practical to connect those fragments across controls engineering, thermodynamics, statistics, hydraulics, and software history, and to test what each observation could legitimately support.
Digital exhaust did not become truth. It became evidence.
The pool had been leaving clues all along.
What data is your system collecting for one purpose that might contain evidence for another?