User Guide: Data Verification Applet

Overview

Data Verification is a monitoring applet in Atria that validates IoT sensor data quality, device configuration, and health. It runs a set of verification rules against device data from Timestream, DynamoDB, and IoT Core to detect issues like misconfigured sensors, dead batteries, missing data, and impossible consumption values.

Access: Monitor > Data Verification

URL: `/monitor/data-verification`

How to Use

Search by Site

1. Select Search by Site ID

2. Enter the site code (e.g., `NCT2`, `BVA1`, `NZMN`)

3. Click View Site

4. Verification runs automatically on all devices at the site

5. Results show a summary (Pass/Warning/Fail counts) and a device table

6. Click any device row to see detailed verification results

Search by Device EUI

1. Select Search by Device EUI

2. Enter the last 5 digits of the device EUI (e.g., `56170`)

3. Click View Device

4. If a device is found, it navigates directly to the device detail

Device Detail View

The device detail page shows:

• Device Information: Dev EUI, Device Type, Vendor/Model, Site, Location, Installation date, Gateway EUI

• Installer Sign-Off: If the device was installed via Atria and signed off, shows who signed off, when, and any notes

• Consumption: Daily (24h) and Monthly (30d) consumption with min/max values (for water and pulse meter devices)

• Verification Issues: List of all failed or warning rules with descriptions

• IoT Connectivity Status: On-demand check of IoT Core connection

• Decoder Status: On-demand check of decoder Lambda logs if needed

• Latest Readings: Raw Timestream data for the device

Verification Results

Each device gets a traffic-light status:

Consumption Display

For water and pulse meter devices, the device detail shows:

Daily Consumption (Last 24 Hours)

• Consumption: difference between max and min meter reading in 24h

• Min Value: lowest meter reading in 24h

• Max Value: highest meter reading in 24h

Monthly Consumption (Last 30 Days)

• Same metrics over a 30-day window

Units: `gal` for water devices (PWM, WM, LWM), `units` for others.

IoT Diagnostic Chain

When a device has no data or stale data, the verification provides a diagnostic chain:

1. Check Timestream: Is there recent data?

2. Check IoT Core: Did the device send uplinks?

3. Check Decoder Logs: Are there decoder errors?

This helps identify whether the problem is at the sensor, gateway, IoT Core, or decoder level.

Verification Rules

Presence Rules

These rules check if the device is sending data.

1. Data Freshness

Checks how long since the device last sent data to Timestream.

When a device has no data or stale data, the rule also checks IoT Core to determine the root cause:

• Decoder failure: IoT Core received data but it didn't reach Timestream

• Device issue: IoT Core also has no recent uplink - likely battery, hardware, or connectivity problem

• Never connected: Device has never sent data to IoT Core

Health Rules

These rules check device hardware health.

1. Battery Low

Checks battery level. Automatically detects whether the sensor reports battery as voltage (Synetica, Vutility, Laird) or percentage (Milesight, Browan).

Detection: If battery value >= 10, it's percentage. If < 10, it's voltage.

Devices without battery data (e.g., mains-powered) pass silently.

2. Signal Weak

Checks GatewayRssi signal strength.

Note: RSSI measures signal strength. Poor RSSI with good SNR indicates distance; good RSSI with poor SNR indicates environmental noise.

Sensibility Rules

These rules check if the data values make sense.

1. Constant Reading Detection

Detects when consumption measures (USGallon, PulseCount1/2/3) stop changing across 20 consecutive readings.

What it catches:

• Pulse counter disconnected from meter

• Sensor not reading flow

• Meter wire disconnected

Applies to: WM, PWM, PGM, PEM devices types

Example issue: "PulseCount1 not changing: 20 consecutive identical readings (value=15.0)"

2. Consumption Check

Checks if daily or monthly consumption exceeds physically plausible limits.

Daily limits (24h delta):

Monthly limits: maxDaily x 30

What it catches:

• Wrong pulse scalar configuration (e.g., scalar of 1 instead of 0.001 causing billions of gallons)

• Sustained misconfiguration that may not be visible in a single day

Example: The NZMN sensor accumulated 382 billion gallons in 30 days. The 24h delta was only 6,526 gal (under the daily limit), but the 30d delta of 382 billion far exceeds the 15 million monthly limit.

3. Negative Consumption

Fails if the cumulative meter reading decreases between readings.

What it catches:

• Meter rollover

• Misconfiguration causing negative values

• Data corruption

Example issue: "Consumption decreased by 5,000.00 in 24h — meter reading went from 80,000.00 down to 75,000.00"

4. Spike Detection

Warns if a single reading-to-reading jump exceeds 10x the rolling average delta.

What it catches:

• Sudden pulse scalar change mid-operation

• Meter malfunction causing a burst of readings

• Intermittent wiring issues

Example: If a sensor normally changes by ~50 gal per reading, but suddenly jumps by 5,000 gal, that's 100x the average — flagged as a spike.

Configuration

• `multiplier`: How many times the average constitutes a spike (default: 10x)

• `minSamples`: Minimum readings needed to calculate average (default: 5)

5. Zero Flow Detection

Warns if daily consumption is zero — the meter reading hasn't changed in 24 hours.

What it catches:

• Pulse counter disconnected from meter

• No actual flow through the meter

• Meter wire disconnected

Applies to: PWM, WM, PGM, PEM device types

Config Rules

These rules check device configuration in DynamoDB.

1. Pulse Scalar Presence

Checks that pulse devices (PWM, PGM, PEM) have a `PulseScalarValue`(Pulse Rate) configured.

2. Device Type Presence

Warns if a device has no `DeviceType` set, which prevents proper classification and rule targeting.

3. LWM No Pulse Inputs

Fails if an LWM (LoRaWAN Water Meter) device has no pulse counter inputs (_P1/_P2/_P3) configured in the device table. LWM base devices without pulse counters cannot collect meter data.

Tips

• Run verification after installing a new sensor to catch configuration issues early

• Check sites periodically — the verification can detect slow-developing problems like pulse scalar misconfiguration that accumulates over time

• Use device search with last 5 digits of the EUI for quick lookups

• Consumption section is collapsible — click the header to expand/collapse