Suppose your prototype should warn someone to close a window when it rains. A sensor that changes state when wet is a useful start, but the message still needs a rule. Should one droplet trigger it? What happens when the surface briefly dries between drops, or is wet with morning dew?
Those are real questions. In a Home Assistant community thread started in November 2021, the owner of a different rain sensor wanted to respond to sustained rain rather than to every brief wet state. That is the application question this note is about.
On our bench we connected a Mysentech CDS1081 capacitive rain sensor to a Raspberry Pi Pico (RP2040) on a GraftPort carrier, read its settings and compared two recorded states. That covers the first part of the experiment. It does not yet supply the outdoor event history needed to choose a window-alert rule.
Establish what the controller is reading
The sensor board connects through a cable and adapter to the carrier's UART0, with GPIO16 transmitting and GPIO17 receiving. We used our CDS1081 driver package. Keep the driver version recorded with the wiring: a driver for another rain-sensor family may interpret the device's data differently.
Before reading anything, our program wrote three values to the sensor: a calibration value of 6000, which the driver's description equates to 6 pF, an alarm threshold of 40000 and a clear threshold of 20000. Those writes need to stay visible in any shortened version of the program and in the test log. Otherwise someone could mistake the result for an unchanged, factory-configured module.
These are sensor configuration values, not amounts of rainfall. For a window reminder they are the starting configuration from which later physical tests proceed, and they should be logged with every result.
Keep the state and the measurement together
The first capture showed rain status 0, a temperature of 33.8 °C and a capacitance of 4.583 pF. Capacitance is the electrical quantity the sensor measures, reported here in picofarads. The program also printed a Count0 field and the configured settings, which gives more context than a bare "dry" label.
The second capture showed status 1, 34.2 °C and 24.735 pF, with Count0 at 1752. The two records show the sensor returning two different states. There was no timed rainfall procedure alongside them, so they cannot tell us how long rain should last before an alert. The count field changes too, but two captures do not establish any formula connecting it to rain intensity.
In a future log, keep the status, the capacitance, the temperature and the settings together on every line. If the alert misbehaves later, you will want to know whether the state changed because the reading crossed a threshold or because the threshold itself was different.
Add the missing timeline before choosing an alert rule
For the next experiment, mount the sensor in its planned orientation and timestamp the readings. Alongside the log, record what physically happened: a few drops, continued wetting, drying, condensation. The controller sees a signal; the user cares about an event outside the device, and only the paired record connects the two.
A persistence rule, such as "alert only after the wet state has held for some minutes", may reduce unwanted notifications, but it also delays the response. Choose that tradeoff from observed events and the product's purpose, not by borrowing a duration from an unrelated forum setup. Things worth recording in that test:
- how long the wet state lasts after the first drops in light rain;
- how quickly the surface returns to dry after rain stops, and whether that depends on the mounting angle;
- whether dew or condensation produces the same state as rain;
- what happens when dirt, leaves or water film sit on the surface.
A reminder can be evaluated on its own, before anyone builds a motorized window mechanism, which brings its own control and mechanical work.
After those observations the question becomes more useful than "does the sensor work?" You can ask whether the recorded wet states separate the situations in which your user wants a notification, and what placement or software change would improve that separation.