Skip to content
woodfrog
Analytics
Water utilitiesUse case, savings not yet measured

See every tank, valve and meter in one place.

Tanks, valves, water meters and sensors each report somewhere different. To check one device you open one tool, to pull a report another, and to send it a spreadsheet. One workspace puts live status, stored history and scheduled reports together.

A monitoring dashboard showing valve status, device communication, energy, switches, water meter flow and analog sensor readings for one project
The dashboard: device connectivity, valves, switches, water meters, sensors and energy in one view.
6Operational areas in one dashboard
8Historical data sources stored for fast reports
31 daysLongest custom report range
2Scheduled report formats: PDF and Excel
TypeUse case, from a platform we built. Savings have not been measured yet, so none are claimed.
ForWater and utility operators with tanks, valves and meters on remote controllers
EngagementWeek 1 audit, then build, fixed scope, fixed fee
Runs onYour controller cloud, a PostgreSQL store for history, a scheduler and email delivery
Before and after

From many tools and manual reports to one workspace.

Before
  • Status, history and reports live in different screens and files
  • Finding the right device in a large inventory takes searching and guessing
  • Recurring reports are collected, formatted and emailed by hand
  • Every historical report asks the cloud service again, and fails when it is down
After
  • Status, history and reports in one workspace, from overview down to one device
  • Search, status filters and alert-only filters narrow hundreds of devices to the few that need attention
  • Reports generate on a schedule and arrive as PDF or Excel, with no browser left open
  • Completed days are stored, so history opens without calling the cloud again
The problem

Hundreds of devices, and no quick way to see which one matters.

A water network is spread across a district: main tanks, overhead tanks, valves on timers, meters and level sensors, each on its own controller. Every device has something useful to say, but the answer to a simple question such as which tank is low and why is spread across screens, exports and phone calls.

A map of tanks across a district, each marked with its code and a green online dot
Every tank on the map, with live communication status.
What was broken
  • Looking at one device means opening one tool, and looking at its history means another.
  • A large device list gives no hint about which few need attention first.
  • Weekly and monthly reports are rebuilt by hand, every time.
  • History is requested again from the cloud service on every view, so it is slow and breaks when the service does.
  • When one controller fails, a whole report can come back empty.
You might be here if
  • Someone exports readings to a spreadsheet every Monday.
  • A low tank is found by a call from the field, not by a screen.
  • Operators search several places to answer one question.
  • Month-end reviews rely on whoever remembered to save the data.

Why it mattered. Time spent collecting data is time not spent fixing the leak, the valve or the tank that needs attention.

The approach

Organise the network the way operators think about it.

We do not add one more screen per device type. We map the network into layers, from the main reservoir to each overhead tank, so a controller sits in the same place in the dashboard, the monitoring views and the reports. Then everything is read from the same model: live status for now, stored history for later.

A dashboard grouped by layer, showing online and offline counts, water meter flow and switch status for each layer
The same network by layer: online and offline counts, flow and door switches for each.
Where it lives today
Controllers in the field
The cloud service
Spreadsheets and emails
woodfrog method
Map the network into layersReservoir to tank to device
Store every completed dayIn PostgreSQL, 8 data sources
Schedule the reportsPDF and Excel by email
What changes
One place to look
Fast, steady history
Reports without the manual work
One workspace for operations
Deliberately not doneReplacing your controllers or the cloud service. They keep running as they are.
The controllers and cloud service stay as they are. We add the layer above them.schematic
The solution

Monitoring, history and reports on one model.

What we build
  • A dashboard that brings 6 areas together: device connectivity, valve status, switch status, water meter readings, analog sensor readings and energy.
  • Monitoring in tree, table and map views, with search, device-status filters, an alert-only filter and layer-based navigation.
  • A store of completed-day history for 8 data sources: irrigation, analog input, power, switch indicators, water meter flow, valve flow, valve accumulation and water meter accumulation.
  • Reports for the last 30 days or a custom range of up to 31 days, searchable, filterable and sortable, with stored readings kept on screen during a refresh.
  • Scheduled reports in PDF and Excel, delivered by email once the scheduler and email service are set up.
  • Valve schedules and programs in one list, so what is running, paused or idle is visible without opening each controller.
History for completed days is read from the store, so opening a past day makes no call to the cloud service. A cached reading is only replaced by a newer successful one, never by a failure.
A table of controllers with communication status, alerts, valve, water meter, switches, version and energy columns
Table view: every controller, with status, valve, meter, switches and energy side by side.
A list of valve programs showing status, weekdays, start time and volume for each tank
Valve programs: which are running, paused, idle or offline, and the volume each is set to.
Reports

Reports that open fast and send themselves.

A bar chart comparing demand and supply in cubic metres for each of the last seven days
Water accumulation: demand against supply, day by day, with a Schedule report button.
A line chart of valve flow over seven days with high, nominal and low flow thresholds drawn as dashed lines
Valve flow against its high, nominal and low thresholds, where the line turns red above the limit.
One controller fails, the rest still reportEach controller refreshes on its own. When one fails, the readings already stored stay on screen instead of the whole report going blank.
Big date ranges are split before they breakLarge requests are cut into smaller windows before they reach the cloud service's 10,000-result limit. A 50,000-reading cap on valve flow has been removed, and an error is shown if a window cannot be split safely.
Failed reports try again, but never twiceA scheduled report that fails is retried up to 3 times, 5 minutes apart. Each run is recorded, and the same scheduled report cannot be picked up twice.
The impact

What it could be worth, and how we would measure it.

What it could free up, on stated assumptionsA scenario to test against your own numbers. Not a measured result.
Illustrative
Assumes the two activities do not overlap. Eight-hour working days. Your team size, report count and time per task will change the result.
What we would measureNo client values yet
Investigation timeAverage minutes to find and assess a device issue
Reporting effortStaff hours spent on recurring reports
Report speedTime to open and move through historical data
Delivery reliabilityShare of scheduled reports delivered
Data freshnessTime since the last successful controller update

The platform provides the capability. Lower costs, faster incident response and less water lost are outcomes to measure in use, not results to claim before they are measured.

Put your whole network on one screen.A short call, or record a message. A person replies within one business day.
Contact usCertified Services Partner, Claude Partner Network