This is the metering layer — integrate smart electricity and water meters over DLMS/COSEM, capture per-unit consumption automatically, flag leaks and offline meters — then hand the readings to billing. It proves the number; billing turns it into a bill.
For RWA Hon. Treasurers, Secretaries & Property Managers · DLMS/COSEM · 15-min reads · leak + offline-meter flags · feeds billing, doesn't invoice.
IoT Utility is the meter-to-reading layer. It integrates smart electricity and water meters over DLMS/COSEM (IEC 62056) — BIS IS 16444, IS 13779, IS 779 — captures per-unit consumption automatically (15-minute reads → daily → monthly), raises a leak-detection signal on anomalies and a read-failure alert when a meter goes offline, reconciles common-area meters by tower, and allows a resident self-read for legacy units. It produces the trustworthy per-unit number and feeds it to billing. It does not generate the invoice — that's billing (tariffs, late fees, reminders); the ledger is accounting; the leak repair is the helpdesk; the water-cut notice is communication. The meter reads the number; billing charges for it.
Mr. Reddy's society stopped sending someone door to door. Here's what the metering layer produces per unit in a cycle — the reads, the flags — and the last column shows the one thing it does not do: make the bill. That reading is handed to billing.
| Unit | Monthly consumption | Flag | Reading goes to |
|---|---|---|---|
| A-1204 (water) | 14.2 kL | normal | → billing |
| A-1204 (elec) | 312 kWh | normal | → billing |
| B-0706 (water) | 61.8 kL | leak signal | repair → helpdesk |
| C-0302 (elec) | — offline | read-failure >24h | investigate · self-read |
| Tower common | per-tower agg. | reconciled | reads → billing · ledger → accounting |
A reading is jotted wrong or guessed, the resident contests the bill, and the treasurer spends the month arguing over a number nobody can actually verify after the fact.
A toilet runs all month behind a wall; with monthly manual reads there's no way to see it until a shocking bill arrives — by which time thousands of litres are gone.
A meter quietly stops working, and it's only discovered when the bill can't be produced — leaving a gap that has to be estimated and inevitably disputed.
Lift, pump and lighting consumption gets lumped into one unexplained number, so the society can't apportion or question shared usage with any confidence.
Smart electricity and water meters are integrated over DLMS/COSEM (IEC 62056) — BIS IS 16444 single-phase, IS 13779 three-phase, IS 779 reference — so the society reads them digitally instead of sending someone to each riser with a notebook.
Consumption is captured at 15-minute intervals and rolled up to daily totals and monthly aggregates per unit, so each flat's usage is recorded continuously and accurately rather than estimated from a once-a-month reading.
A consumption anomaly raises a leak-detection signal, and a meter offline for more than 24 hours raises a read-failure alert — so a running tap or a dead meter is caught early. The actual repair is the helpdesk's ticket workflow.
Common-area meters are reconciled through per-tower aggregation, and any legacy non-smart unit can be entered through a resident self-read manual override — so the whole estate, smart or not, lands in one consistent dataset.
The verified per-unit consumption is handed to the billing module, which generates the invoices, late fees and reminders, while accounting records the ledger entry. IoT Utility's job ends at the trustworthy reading; billing turns it into a bill.
The international protocol for smart-meter data exchange — read-out, billing intervals, time-of-use. Speaking the standard rather than a proprietary protocol means a society isn't locked to one meter vendor.
BIS IS 16444 for single-phase smart meters, IS 13779 for three-phase smart meters, and IS 779 for electromechanical reference meters — so the module reads the Indian-standard meters a society actually installs.
The Central Electricity Authority regulations that frame smart-meter deployment in India — the regulatory context the metering layer is designed to sit within.
Standards references: DLMS/COSEM (IEC 62056) smart-meter data exchange; BIS IS 16444 (single-phase) / IS 13779 (three-phase) / IS 779 (reference meters); CEA Distribution Regulations 2014 (smart-meter deployment framework). This page owns the meter integration and the per-unit reading only. Invoice generation, tariffs and late fees are the billing module; ledger entries are accounting; leak repair is the helpdesk; water-cut notices are communication; the meter-to-flat mapping is the unit-management canonical record.
EstateDeck keeps the metering layer distinct from billing on purpose — the metering layer's job is an accurate, verifiable reading; billing's job is to turn that reading into money. Keeping them apart means this page ranks for smart-meter and consumption tracking and never competes with billing over "utility bills."
The meter integration is the same; what the society needs from the data shifts.
A society that sub-meters water needs each flat's real consumption, not a flat split — so the reads here feed billing for a usage-based charge that residents accept because it's measured.
An older tower with hidden plumbing needs early anomaly signals so a continuous-flow leak is flagged within a day — and the helpdesk ticket goes out before the bill shocks anyone.
A society mid-upgrade has some smart meters and some old ones; per-tower aggregation plus resident self-read keeps the whole estate in one dataset until every meter is replaced.
"Every month it was the same ritual — a man with a notebook walking the risers, readings I couldn't verify, and then a fortnight of residents disputing their water bills. What changed with this is subtle but it's the whole point: it reads the meters over the standard DLMS protocol every fifteen minutes, so by the 1st I already have a clean, defensible number per flat — and when a flat in B-block showed sixty kilolitres, the leak signal caught a running tap in days, not at the bill. The thing I appreciate as a treasurer is that it knows its lane. It gives me the reading; it does not pretend to be my billing or my ledger. The number flows into our billing module, which makes the invoice, and into accounting for the books. A vendor who'd told me one tool would 'do the metering and the billing and the accounts' is exactly the kind of muddle I was trying to escape — this is clean because each part does one thing."
What every Hon. Treasurer asks before retiring the notebook-on-the-1st.
We'll show you DLMS/COSEM smart-meter integration, automatic per-unit consumption reads, leak and offline-meter flags, and per-tower reconciliation — feeding clean readings to your billing module — on your society's actual meters.
See IoT Metering →