A leak alarm under a small appliance has to answer two everyday questions. Will water reach the sensor soon enough to be useful? And when can the user trust that the alarm has cleared? A changing number on a development board answers only part of that.
Placement and operating conditions are part of any leak-detection result. An ABLIC announcement from September 2026 describes leak monitoring evaluated on an actual bridge, with placement and conditions part of the reported evaluation. Its sensor and application are different, so it says nothing about the module below, but it is a reminder to define the event and the evidence before choosing the detector.
On our bench we connected a Mysentech WS61, a round bare-board capacitive water sensor, to a Raspberry Pi Pico (RP2040) on a GraftPort carrier and logged three states: no water, an alarm, and recovery. That sequence is a small, concrete starting point before deciding where to mount the sensor in a product.
Make the rule for clearing the alarm visible
The WS61 connects to the carrier through a small adapter and talks over UART0, with GPIO16 transmitting and GPIO17 receiving. We used our WS61 driver package. One naming detail to watch if you reproduce it: the package and the module file inside it are named differently (ws61_driver and wd61), so keep file and class names together when following the example.
Our program wrote two thresholds to the sensor before it started reading: an alarm threshold of 7.5 pF and a release threshold of 7.0 pF. A picofarad is a unit of capacitance, the electrical quantity the sensor measures. That detail matters: the demonstration changes the sensor's settings rather than merely displaying whatever it finds, so any reading you compare with ours depends on the same thresholds being written. They are example settings; whether they suit your arrangement depends on the actual sensor mounting.
The two thresholds create hysteresis. The alarm turns on when the reading rises above the upper threshold. Once triggered, it stays active between the two thresholds and clears only when the reading falls below the lower one. The gap prevents a small fluctuation around a single boundary from turning the alarm on and off repeatedly, which for a user looks like a faulty product.
Follow the output through alarm and recovery
The first capture reported about 5.82 pF and "No water". It also printed the device address and both thresholds, so anyone reading the log can relate the state to the rule that produced it. Log the rule with the state; a bare "alarm" line hides why it fired.
A second capture contained two useful moments: 31.409 pF with "Water alarm", then 3.975 pF with "No water". The recovery belongs in the record as much as the alarm. For a person using the eventual product, a detector that stays latched, or clears too soon and retriggers, can be as confusing as one that misses the first event.
We did not run a timed wetting-and-drying procedure alongside these captures. They show the reported states and readings, not how many seconds or how much water it took to trigger or to clear. The next physical test has to supply that relationship.
Put the detector on the path the water takes
The WS61 we used is a bare round board. A housed version also exists, fixed with screws through side holes or with adhesive at the side mounting positions; that is a different physical arrangement from our bench test, and a bare board under an appliance raises its own questions about protection and cleaning.
For an appliance prototype, trace where a plausible leak would go before it shows up outside the product. A detector on a raised shelf may stay dry while water collects in a tray below it. Then run the test:
- Place the candidate sensor where the traced water path says it should be.
- Introduce a controlled amount of water at the likely leak point.
- Log the readings and the reported state from the first drop through cleanup and drying, with timestamps.
- Photograph the water path so the result can be repeated and explained.
That test ties together the two questions at the start: whether the placement catches the event, and whether the alarm clears in a way the user understands. Our bench record supplies the readout and the threshold behavior. It does not yet establish coverage of an appliance or a finished waterproof assembly.
When you write the product behavior down, include both halves: what triggers the alarm, and what the user has to do, or wait for, before it clears.