The Water Monkey is a water meter monitoring device with cellular connectivity, supporting both single and compound meter configurations. It records and reports 10-minute water usage snapshots for residential, multi-residential, and commercial applications.

Raw Data Variables

Main data points

These are the variables sent directly by the device. Note that each variable contains context data consisting of JSON key-value pairs. See Variable context details.

Variable Name	API Label	Unit / Description
Status	`status`	General device status indicator
Signal	`signal`	`%` — Signal quality percentage
Battery	`battery`	`%` — Estimated remaining battery percentage
Pulse per Interval	`pulse_per_interval`	Number of pulses detected per 10-minute interval

Device configuration and management

Variables used for device configuration and remote management. See Variable context details.

Variable Name	API Label	Description
Command	`command`
Device Configuration	`config`

Alert related variables

Variables that control and report alert conditions. See Variable context details.

Variable Name	API Label	Description
Alert	`alert`
Alert Config	`alert_config`

Variable context details

Note: A — in the API Label column indicates the field belongs to the same parent label as the row above.

API Label	Context	Type	Unit / Description
`status`	`is_overdue`	`bool`	Device missed the expected schedule once
—	`is_offline`	`bool`	Device missed the expected schedule twice
`signal`	`rsrp`	`int`	`dBm` — Strength of the LTE cellular signal
—	`rsrq`	`int`	`dB` — Quality of the LTE cellular signal
—	`snr`	`int`	`dB` — Signal-to-noise ratio, signal clarity
`battery`	`voltage`	`int`	`mV` — Sampled battery level
—	`health`	`string`	Battery health (`good`, `low`, or `critical`)
`command`	`reboot`	`bool`	Issue a reboot request
—	`shutdown`	`bool`	Issue a shutdown request
`config`	`enable_low`	`bool`	Enable or disable low-side pulse detection
—	`enable_high`	`bool`	Enable or disable high-side pulse detection
`alert`	`leak`	`bool`	Leak detected from continuous flow
—	`high_usage`	`bool`	Abnormal usage based on the set threshold
`alert_config`	`leak_alert`	`bool`	Enable or disable leak alerts
—	`high_usage_alert`	`bool`	Enable or disable high usage alerts
`pulse_per_interval`	`low_side`	`int`	Low-side pulses detected per interval
—	`low_floor`	`int`	Minimum low-side pulse count per minute
—	`high_side`	`int`	High-side pulses detected per interval
—	`high_floor`	`int`	Minimum high-side pulse count per minute

Measurement, consumption and analytics variables

Computed variables derived from raw data for consumption analysis and reporting.

Variable Name	API Label	Unit / Description
Actual Cost	`actual_cost`	`$` — Total calculated cost
Water Cost	`water_cost`	`$` — Cost attributed to water usage
Leak Cost	`leak_cost`	`$` — Cost attributed to detected leaks
Actual Consumption	`actual_consumption`	`L` — Total measured consumption
Water Consumption	`water_consumption`	`L` — Total water consumption
Leak Volume	`leak_volume`	`L` — Estimated volume lost to leaks
Daily Minimum	`daily_minimum`	`L` — Minimum daily consumption
Daily Maximum	`daily_maximum`	`L` — Maximum daily consumption
Daily Average	`daily_average`	`L` — Average daily consumption
Total Flow Rate	`total_flow_rate`	`LPM` — Sum of low- and high-side flow rate
Low-side Flow Rate	`low_side_flow_rate`	`LPM` — Low-side flow rate
High-side Flow Rate	`high_side_flow_rate`	`LPM` — High-side flow rate
Run-Off Water Flow Rate	`run_off_water_flow_rate`	`LPM` — Estimated run-off water flow rate
Meter Estimate Low-side	`meter_estimate_low_side`	`L` — Estimated low-side meter reading
Meter Estimate High-side	`meter_estimate_high_side`	`L` — Estimated high-side meter reading
Alert High Use	`alert_high_use`	High usage alert status
Alert Leak	`alert_leak`	Leak alert status
Flow Fraction	`flow_fraction`	Fraction of total flow attributed to low-side

Command Downlink Pipeline

The device is not always reachable. To conserve battery it spends nearly all of its life asleep, waking on its own schedule to report water usage and, in the same brief window, to collect any instructions waiting for it in the cloud. This means commands are never pushed to the device in real time — they are left for the device to pick up the next time it checks in.

The variables in the Internal Configuration, Command, and Alert Config groups above are the channels used to steer the device remotely. Each of these is a writable variable: the cloud writes an instruction into it, and the device reads it back on its next check-in.

How a command flows

A command moves through four stages. The example below uses a remote reboot, but every writable command and config setting follows the same pattern.

Issue the command (cloud → device). An operator (or an automated rule on the dashboard) writes the command by setting the variable's value to 1 and supplying the intended instruction in the variable's context — for example, writing command with a value of 1 and a context of { "reboot": true }. The value of 1 is the signal that a fresh instruction is waiting; the context carries what to do.
Pick-up and execution (on the device). The next time the device wakes and connects, it reads any pending instructions, then carries out the requested action — rebooting, changing a setting, toggling an alert, and so on. Persistent settings (such as enabling or disabling a meter side) are stored on the device so they survive power cycles; one-shot actions (reboot, shutdown) simply execute.
Acknowledgement (device → cloud). On the very same connection, the device confirms it received and acted on the instruction by writing the value back to 0. Crucially, the context is left exactly as the cloud sent it — the device only resets the value, not the instruction. A value of 0 therefore means "no instruction pending / already handled," and a value of 1 means "an instruction is still waiting to be picked up."
Confirmed and idle. With the value back at 0, the command channel is clear and ready for the next instruction. The same write that resets the value also clears the pending instruction on the device side, so a command is never acted on twice.

Reading state from the value field

Because the device drives the value back to 0 itself, the value of a command variable doubles as its status, which the dashboard can poll directly:

Value	Meaning
`1`	Instruction issued — waiting for the device to check in
`0`	Acknowledged — the device received and acted on it

The time between writing 1 and seeing it return to 0 is simply the gap until the device's next scheduled check-in. There is no separate "command accepted" notification — the value flipping back to 0 is the confirmation. (During commissioning and diagnostic windows the device checks in far more frequently, so commands are picked up within minutes rather than hours.)

Acknowledged command and config groups

Two of the writable channels report back a small confirmation block when they are acted on, so the dashboard reflects the device's actual post-command state rather than just an empty value:

command — after a reboot/shutdown instruction, the device sends back command, reboot, and shutdown all reset to 0, confirming the action was consumed.
config — after a configuration change, the device sends back config reset to 0 together with the current enable_low / enable_high states, so the dashboard always shows the settings the device is actually running with.

This makes the dashboard a faithful mirror of the device: what you read back is the device's own confirmed state, not merely the request that was sent.