Tackling the $13B Water Damage Problem
Water damage claims cost U.S. insurers an estimated $13 billion annually. Yet the failed pipe or water heater is often only a fraction of the final cost. The real damage comes from everything downstream: flooded units, displaced tenants, mold remediation, reconstruction, business interruption, and insurance claims spanning multiple floors.
At first, the market appeared well served. Floor-mounted leak detectors alert occupants when escaped water reaches them. More sophisticated systems install directly into a building’s main supply line, monitor flow, pressure, and temperature, and can automatically shut off the water when they detect an abnormality.
I saw an opportunity at a different layer of the system: monitoring the condition and behavior of individual pipes and water heaters without cutting into the plumbing.
Revere’s design hypothesis was that physical degradation might reveal itself through changes in structure-borne acoustics, mechanical vibration, pipe temperature, and equipment current draw before it produced enough escaping water to trigger a conventional detector. A clamp-on sensor could be installed directly on high-risk assets—water heaters, sprinkler lines, and pipes inside vacant units—while LTE-M connectivity removed dependence on building Wi-Fi.
This was not yet a proven predictive capability. It was a measurement architecture built to test whether those early physical signals contained useful information.
Customer Discovery Process
After building StreetSide, I knew that customer discovery needed to come before any engineering. It was the process that determined which failures mattered, who would pay to prevent them, where the sensors should be installed, and what the hardware needed to measure.
I began with a broad predictive-maintenance concept, but property operators repeatedly redirected me toward water damage. Each conversation exposed a different failure mode—and changed the product requirements.
A New Jersey property manager responsible for 2,100 condos described repeated water-heater ruptures. Water from an upper-floor unit could travel through every residence below it, turning one equipment failure into multiple insurance claims. He committed to piloting Revere in 10 units in his portfolio.
Another conversation with the owner of a commercial real estate firm in NJ described the most severe case. Burst plumbing in one apartment complex created approximately $2.5 million in losses. The cost extended far beyond repairing the pipes: tenants required long-term hotel accommodations, sections of the building needed substantial reconstruction, and the plumbing system itself had to be restored.
Lastly, the owner of a real estate firm specializing in student housing explained college tenants have left water running for weeks while properties were vacant over the summer. Without anyone living in his units, abnormal water use and plumbing failures could continue unnoticed.
Together, these conversations transformed Revere from a generic sensor kit into a focused system with clear requirements:
Non-invasive installation: The device needed to clamp onto existing plumbing without interrupting service.
Asset-level visibility: It needed to monitor specific water heaters, sprinkler lines, and high-risk pipes—not only aggregate whole-building flow.
Multiple physical signals: Acoustic, vibration, temperature, and current sensing were selected because each customer problem appeared differently in the physical system.
Independent connectivity: Cellular communication avoided relying on tenant or building Wi-Fi, especially in vacant units.
Testable failure modes: Water-heater operation, persistent flow, pipe events, and controlled leaks became defined experimental cases rather than a vague promise of “predictive maintenance.”
These conversations ultimately produced three signed letters of intent and access to prospective pilot environments.
Converging Onto Multimodal Sensing
No single sensor could describe the behavior of an entire plumbing system, so I designed a multimodal prototype around complementary measurements.
A 20 mm piezoelectric disc, connected through a MAX9814 amplifier and read through the Particle Boron’s ADC, acted as a contact microphone for structure-borne acoustic activity. An ADXL345 accelerometer communicated over I²C and measured lower-frequency mechanical vibration such as water hammer, pump operation, and pipe movement.
A DS18B20 temperature probe used 1-Wire to monitor pipe-surface temperature for heating cycles and freeze risk. For water-heater installations, an SCT-013 split-core current transformer provided a non-invasive measurement of heating-element operation through a second ADC channel.
The prototype ran on a Particle Boron 404X, which combined an nRF52840 microcontroller with LTE-M connectivity. Cellular service avoided requiring Wi-Fi credentials or network access from each customer site.
Each signal provided a different view of the asset. A heating cycle could appear in temperature and current, while a mechanical event could appear in both acceleration and acoustic energy. The working prototype demonstrated that these channels could be acquired together. It did not yet prove that they could distinguish specific failures.
Mechanical Design
I used a rigid sensor-to-pipe contact, with thermal paste filling microscopic surface gaps and a stainless hose clamp or rigid adhesive maintaining consistent pressure. The electronics enclosure remained mechanically separated and connected through a wire harness.
This created a non-invasive installation while keeping the acoustic path direct. The mounting method still required controlled testing across pipe materials, diameters, and installation forces, but the design established an important principle: signal quality begins at the mechanical interface, before the measurements reach the ADC.
Feature Extraction at the Edge
Continuously transmitting raw acoustic waveforms over cellular would have be expensive and unnecessary for the prototype. I moved the first stage of signal processing onto the Boron.
The embedded firmware computed:
RMS to measure overall signal energy
Peak amplitude to capture large transient events
Kurtosis to describe how impulsive the signal was
Skewness to measure asymmetry
Accelerometer RMS and peak vibration
RMS current draw
These features preserve more information than a simple average. Two signals can contain the same overall energy while one is steady and the other contains occasional sharp impulses. RMS alone would make them appear similar; peak and kurtosis help expose the difference.
The firmware also generated a 32-value acoustic-energy profile by dividing the signal into time windows and calculating the energy within each segment.
Impossible Data Exposed Bad Assumptions
A principle that every mechatronics engineer must internalize is that actuators and sensors constantly lie; I encountered this early.
The current channel reported approximately 39 A with no conductor inside the clamp, while the stationary accelerometer indicated substantial motion. The acoustic signal also contained an unexplained DC offset.
The original firmware assumed ideal baseline values: a bias circuit would sit at exactly half the ADC range, and the stationary accelerometer would match its theoretical gravity offset. Real resistor tolerances, amplifier behavior, sensor orientation, and ADC variation shifted every baseline. Because RMS, kurtosis, and related statistics depend on the signal’s distance from its true center, an incorrect offset corrupted every downstream feature.
I replaced the hardcoded constants with a boot-time calibration routine that measured the actual acoustic midpoint, current-channel offset, and accelerometer gravity baseline on the specific hardware.
A future anomaly model trained on biased measurements would learn the sensor error instead of the pipe’s behavior. Calibration was therefore part of the machine-learning pipeline, even though it occurred before any model existed.
Designing the Data Budget
The working pipeline connected:
Sensors → Particle Boron → Particle Cloud → webhook → Firebase → React dashboard
The Boron transmitted compact feature summaries every two minutes and the 32-value energy profile every ten minutes. Higher-resolution feature logs were written to microSD every five seconds for offline analysis.
Raw cellular streaming would have required roughly 400 times more bandwidth per reading. The tiered system was estimated to use approximately 30,000 Particle operations per month against an allowance of 100,000.
This split computation and storage according to their strengths: the microcontroller reduced the raw measurements to useful features, cellular provided remote visibility, and local storage retained detail that was too costly to transmit.
Designing the Experiment Before the Model
The operating prototype collected signals and extracted features. It did not predict leaks.
Working with a professor from the Industrial Engineering department, I designed an accelerated life testing experiment that would use water heaters, pipes, and rapid cycling to collect the ground-truth dataset necessary to train an unsupervised autoencoder that could learn the feature patterns of healthy vs. damaged pipe.
Testing multiple leak sizes, pressures, pipe materials, mounting conditions, and sensor positions would establish repeatability and expose false positives from valves, pumps, normal flow, and water hammer.
That experiment—not a more complicated model—was the next critical milestone. Without it, an anomaly score could look sophisticated while having no validated relationship to pipe health.
What Revere Proved
I led customer discovery, defined the sensor architecture, selected and wired the components, designed the analog bias circuit, specified the firmware and data schemas, diagnosed the major hardware and software failures, and designed the acoustic mount and validation program. Firmware and frontend implementation was collaborative, supported by my cofounder and AI coding tools working from the technical specifications I created.
Revere demonstrated an end-to-end cellular monitoring prototype capable of acquiring multiple physical signals, processing them locally, preserving detailed data, and presenting live measurements remotely. Three signed letters of intent established customer interest and access to prospective pilot sites.
Revere taught me that an edge-ML system begins long before model training: sensor selection, mechanical coupling, calibration, synchronized sampling, and controlled testing must produce trustworthy data before feature extraction can preserve the physical behavior that matters. Only then can you train a reliable deep learning model and validate its accuracy in a real-world deployment.