Imagine a small watering device that stops delivering water. Its tank might be empty. Or there might still be water in the tank while air passes through the delivery tube. Those conditions look the same to the person waiting for water, but they ask different questions of a sensor.
The packaging can make the choice harder. In a Home Assistant community thread from July 2021, a pet-fountain owner wanted level monitoring in a tank only about 20 cm tall, with splash resistance and a useful connection to their home system. That is a practical prototype question: which measurement fits the container and supports the notification?
On our bench we ran two separate experiments with Mysentech sensors on a Raspberry Pi Pico (RP2040) GraftPort carrier. The MER is a long capacitive strip that returns a liquid level. The MWFD watches for liquid at one point on a tube. Neither experiment was a complete dispenser, so this note follows each setup and then asks what it could contribute to one.
If the message is "refill the tank", start with level
The MER is a long sensing strip that connects through a small adapter to the controller. Its shape raises a mechanical question straight away: where will that strip sit relative to the useful water depth in your container? Our bench setup had the strip and the controller, but no filled tank and no reference ruler in the water.
The sensor talks over UART0, the controller's serial interface, with GPIO16 transmitting and GPIO17 receiving. We used our MER driver package with this module revision. The library also contains another MER version, and matching the name alone would not resolve a revision difference, so keep the driver version recorded with the hardware.
The driver exposes named reads for level, temperature and capacitance. Our full example also printed configuration, a ratio and a frequency every second. Those extra fields help when the device answers but the level looks wrong.
The console first printed stored reference levels of 30, 70 and 100 mm, then changing live values including 81, 2, 25 and 83 mm. The calibration calls in the program were commented out. Reading stored reference values is a different operation from establishing new reference levels in your tank, and the live values were not compared with a known water height.
For a refill reminder, the next experiment is to fill the actual container to known heights and record what the MER reports at the intended mounting position. Pay particular attention to the low-water region that will trigger the message. A good full-tank number is less useful if the device cannot tell "enough for another cycle" from "refill now".
If the concern is the delivery line, look at the tube
The MWFD uses two spring electrodes wrapped around transparent tubing. It observes the tube at one location; it does not measure tank height. It is worth evaluating when the question is whether the line contains liquid at that point.
The controller reads it as a digital input with two states. One detail needs checking before you reproduce it: our wiring table and our code disagreed on the GPIO number. The code used GPIO15, configured like this:
from machine import Pin
sensor_pin = Pin(15, Pin.IN, Pin.PULL_DOWN)
Confirm the signal pin against the actual assembly rather than either document. In our program a true reading was labeled "bubble or lack of liquid" and false was labeled "normal liquid".
The program polls the input repeatedly, and an interrupt callback also prints a message when the input changes. The captured run moved from repeated warnings to a "normal liquid" interrupt and then normal polling results, which shows how the two reporting paths appear together in one log.
The next question is how long a warning should last before the product acts. An Arduino forum discussion from October 2017 describes separating useful liquid samples from short bubbles, with different hardware, by timing. It is a reason to record timing in your own tests. It does not establish the MWFD's smallest detectable bubble or any flow rate.
Choose the message before combining the sensors
For a first dispenser prototype, write down the event the user needs to know about:
- "Refill soon" needs a reliable relationship between tank level and usable water at the mounting position.
- "Check the delivery line" needs evidence about what happens at the tube sensor during normal starts and stops, not only when air is present.
Either may be useful. Our two experiments do not establish that a product needs both, and adding both doubles the mounting, wiring and testing work.
Keep the plumbing, sensor position and raw readings together when testing the chosen event. A level strip moved a few millimeters, or a tube detector moved closer to the pump, can change what the readings mean. Once the behavior is repeatable, connect it to a notification, without hiding a guess behind a convincing water icon. If the device also waters plants, deciding when to water is a separate measurement problem from knowing whether water is available.