4 releases (breaking)

0.4.0 Jul 28, 2024
0.3.0 Jun 8, 2023
0.2.0 Apr 5, 2023
0.1.0 Dec 1, 2022

#339 in Embedded development


Used in drmemd

MIT license

81KB
1.5K SLoC

drmem-drv-sump

This driver monitors the state of a sump pump through a custom, non-commercial interface[^1] and updates a set of devices based on its behavior.

The sump pump state is obtained, via TCP, with a RaspberryPi that's monitoring a GPIO pin for state changes of the sump pump. It sends a 12-byte packet whenever the state changes. The first 8 bytes holds a millisecond timestamp in big-endian format. The following 4 bytes holds the new state.

With these packets, the driver can use the timestamps to compute duty cycles and incoming flows rates for the sump pit. The duty, and in-flow parameters are updated to reflect the last cycle everytime the pump turns off.

Configuration

The driver needs to know where to access the remote service. It also needs to know how to scale the results. Two driver arguments are used to specify this information:

  • addr is a string containing the host name, or IP address, and port number of the machine that's actually monitoring the sump pump (in "hostname:#" or "#.#.#.#:#" format.)
  • gpm is an integer that represents the gallons-per-minute capacity of the sump pump. The pump owner's manual will typically have a table indicating the flow rate based on the rise of the discharge pipe.

Devices

The driver creates these devices:

Base Name Type Units Comment
service bool, RO Set to true when communicating with the remote service.
state bool, RO Set to true when the pump is running.
duty f64, RO % Indicates duty cycle of the last cycle.
in-flow f64, RO gpm Indicates the in-flow rate for the last cycle.
duration f64, RO min Indicates the duration of the previous cycle.

Caveats

The remote process polls the state of the pump at 20Hz so the timestamps will have 50 ms accuracy. Unfortunately the current switch seems to have a little slop in how quickly it turns on. Depending upon how many 60 hz cycles it takes to activate the relay, it could add 30 ms -- or more -- of latency. The relay in the current switch probably has some delays, too. Lastly, it has been observed that long cycle times (> 5 minutes) can vary by 10 seconds or more! This is probably due to, when the pit fills slowly, the float and the attached switch having tremendous slop when activating.

The takeaway is the measurements of the on/off times are probably accurate to less than 100 ms. It's the float that creates the most inaccuracy of the measurements.

History

Added in v0.1.0.

[^1]: The remote end is running on a Raspberry Pi loaded with NetBSD 9.0. The source code can be found here. The GPIO code is specific to NetBSD, so adjustments will have to be made for Linux.

Dependencies

~7–16MB
~191K SLoC