Intelligente Wasserzählerfunktionen, die nach der Installation am häufigsten von Versorgungsunternehmen genutzt werden

Many smart meter tenders include long feature lists. After installation, teams ignore many options. I focus on the functions that support daily operation.

The smart water meter features utilities use most are remote reading, Ereignisaufzeichnungen, Alarm, Batteriestatus, and diagnostic data. Advanced configuration tools and special testing functions are useful, but they are often used only during commissioning or abnormal troubleshooting.

I usually separate “available functions” from “used functions.” A feature can be technically impressive, but if the utility team has no workflow, alarm rule, platform connection, or field response process, the value stays on the slide.

What Is the Full Menu of Smart Meter Features?

Smart meter menus can become too large. Buyers feel safe adding more functions, but every function adds cost, Ausbildung, and support work.

A smart water meter feature menu may include metering, Fernablesung, Ereignisaufzeichnungen, prepaid mode, postpaid mode, low water alarm, leakage alarm, dry pipe alarm, low battery indication, Kommunikationstests, and optional pressure detection.

The Feature List Is Not the Same as a Use Case

I see many tenders list every possible feature. The list may include metering, TOKEN recharge, STS prepaid operation, switchable prepaid and postpaid mode, low water alarm, und Ereignisaufzeichnungen. It may also include NB-IoT system functions, daily frozen meter data, database storage, and test verification for connectivity and data transmission accuracy. For ultrasonic smart meters, the feature list may include ultrasonic static measurement, R400 measuring range, starting flow down to 0.001 m³/h, optional pressure detection, Schutzart IP68, Leckerkennung, and dry pipe detection.

This full menu is useful during technical selection. But it does not mean every utility will use every feature every week.

I usually divide features into four groups.

ISO 4064 also reminds us that a remote reading device may be used for testing, verification, and remote reading when satisfactory operation of the water meter is guaranteed. It also states that added ancillary devices must not alter the metrological characteristics of the meter. This point is important. I do not treat communication as a decoration. It must support metering without disturbing metrology.

For battery-powered smart meters, I also check whether low battery indication is available. ISO 4064 requires a low battery or exhausted battery indicator, or a meter replacement date, for non-replaceable battery meters. If the register displays “low battery,” there must be at least 180 days of useful display life from the low battery indication to end of life.

The full menu is useful. But the tender should not buy a menu. It should buy a workflow.

Which Features Did Utilities Think They Needed?

Utilities often ask for many advanced functions before installation. They worry about future needs, consultant comments, and tender comparison tables.

Vor der Installation, utilities often think they need every available smart function. In der Praxis, they mainly need reliable data collection, clear event records, actionable alarms, battery visibility, and simple integration with billing or AMI platforms.

The Tender Stage Encourages Over-Specification

At tender stage, the safest-looking meter is often the one with the longest feature list. I understand why this happens. Procurement teams compare datasheets. Consultants ask for options. Managers want future flexibility. Vendors also like to show many functions.

So the tender may request prepaid mode, postpaid mode, TOKEN logic, remote valve rules, Alarmkategorien, handheld configuration, communication tests, frequent upload cycles, history curves, map views, pressure monitoring, and many dashboard modules.

Some of these functions are necessary in the right project. STS prepaid operation, Zum Beispiel, is important when the project uses TOKEN-based prepaid water service. Switchable prepaid and postpaid mode can also matter when the utility needs policy flexibility. Low water alarm and event records may support customer warning and after-sales investigation.

But I ask one practical question: who will use this function after installation?

If the billing department does not use prepaid mode, the prepaid function has little daily value. If the customer service team does not read event records, the record function becomes hidden value. If the field team cannot respond to leakage alarms, the alarm becomes noise. If the platform cannot process pressure data, optional pressure detection may not help the utility make decisions.

For NB-IoT meters, the manual describes a test verification function used to verify connectivity and data transmission accuracy when customers first use the meter. The same material states that this function is rarely used after normal use and is mainly used for on-site diagnosis when the meter is abnormal. This is a good example of a valuable feature that should not be treated as a daily-use feature.

I do not reject advanced features. I only ask buyers to connect each feature to a user, Plattform, and response process.

What Does Post-Installation Reality Show About Usage?

After installation, the real ranking changes. The most expensive-looking features are not always the most used.

Post-installation feedback shows that utilities use remote reading, frozen daily data, Ereignisaufzeichnungen, Alarm, and low battery information most often. Commissioning tools and advanced verification functions are valuable, but they are rarely used after stable operation.

I Separate High-Use Features from Occasional Tools

I do not like inventing precise usage statistics without project data. Instead, I classify usage based on field feedback and system behavior.

Remote reading is usually high-use because it replaces or reduces manual reading work. In an NB-IoT system, the background meter reading system can display frozen water meter data every night and save it in the database without change. This is exactly the kind of feature utilities keep using because it supports billing, consumption review, and routine monitoring.

Event records are also high-value. A prepaid water meter manual lists event records as a core functionality category. In realen Projekten, I see event records used when customers complain, when abnormal consumption appears, or when a utility needs to check what happened before a field visit.

Alarms also stay relevant after installation. Low water alarm is listed as a function in the prepaid water meter manual. Ultrasonic smart meters may support leakage detection and dry pipe detection. ISO 4064 also discusses fault-related messages when meters transmit data to peripheral equipment, and the transmission shall be accompanied by a message indicating the presence of a fault. These functions help utilities detect abnormal conditions earlier, but they do not replace site inspection or repair.

Low battery indication also matters because battery failure creates field cost. ISO 4064 requires low battery or exhausted battery indication, or a replacement date, for non-replaceable battery meters. This makes battery status a practical maintenance feature, not just a technical detail.

The lesson is simple. Utilities use features that appear in daily workflows. They ignore features that have no owner.

Which Features Directly Support Non-Revenue Water Reduction?

NRW work needs field action. A smart meter can support the work, but it cannot repair pipes or correct customer databases by itself.

Smart meter features that support NRW reduction include better low-flow capture, remote consumption visibility, Leckerkennung, Trockenrohrerkennung, reverse or abnormal event records, and alarms that help utilities respond earlier.

The Meter Supports NRW Reduction, but It Does Not Replace Operations

I treat NRW as a system problem. It may include real leakage, scheinbarer Verlust, Unterregistrierung des Zählers, illegale Verbindung, billing data errors, customer data errors, Druckprobleme, delayed repair, and installation problems.

Smart water meters can help in several ways. Erste, they can improve visibility. Remote reading and nightly frozen data allow the utility to see consumption without waiting for manual reading cycles. This supports faster analysis when a district, Gebäude, or customer group shows abnormal use.

Zweite, certain ultrasonic smart meters can support low-flow measurement. The referenced ultrasonic residential smart meter uses ultrasonic measurement technology and has a wide measurement range of Q3/Q1 = R400. The same material states an ultralow starting flow down to 0.001 m³/h. I still separate starting flow from Q1 in technical discussions. Starting flow means the meter begins to register movement, while Q1 is the lower boundary of the certified measuring range. The datasheet or certificate must define the exact Q3 and Q1 before a buyer estimates revenue effect.

Dritte, alarms can support earlier warning. The ultrasonic meter material lists leakage detection and dry pipe detection. ISO 4064 also addresses fault messages during data transmission to peripheral equipment. These warnings can help a utility decide where to inspect first.

I would verify NRW impact in a pilot before full rollout. The meter supports NRW reduction, but it does not replace leak repair, Druckmanagement, illegale Verbindungskontrolle, or billing data cleaning.

Which Features Improve Customer Service and Billing?

Billing complaints often start with missing data. Customer service teams need clear records, not complicated dashboards.

The most useful customer service and billing features are remote readings, frozen historical data, Ereignisaufzeichnungen, alarm records, low battery status, and clear meter indication. These features help explain bills and reduce manual investigation time.

Complaint Handling Needs Evidence, Not Decoration

When a customer disputes a bill, the utility needs a timeline. Remote reading gives consumption data. Frozen data gives a stable reference point. Event records show abnormal events. Alarm history helps explain leakage, trockenes Rohr, low water, Batterie, or fault conditions.

The NB-IoT system manual states that the background meter reading system displays frozen water meter data every night and saves it in the database without change. This is valuable for billing because the data point is time-based and stored. It is also useful for customer service because staff can compare customer claims with recorded readings.

Event records are also important. The prepaid water meter manual lists event records as a function category. In der Praxis, event records help when a customer asks why water was cut, why an alarm appeared, or why the bill changed. If the project uses STS prepaid meters, TOKEN application and switchable prepaid/postpaid mode may also affect customer service workflows.

Clear local indication still matters. ISO 4064 besagt, dass das Anzeigegerät die Lautstärke kontinuierlich anzeigen muss, periodisch, oder auf Anfrage, and it shall be readily available to read. I do not recommend removing local readability just because the system supports remote data. Field technicians and customers still need a clear meter display in many projects.

Battery status also affects service quality. ISO 4064 requires low battery or exhausted battery indication, or a replacement date, for non-replaceable battery meters [6]. This helps utilities avoid surprise failures and plan replacement work.

The best billing feature is not the most complex function. It is the feature that gives reliable, explainable data when a customer asks a difficult question.

Which Features Look Good on Slides but Don’t Get Used?

Some functions are technically real but operationally rare. They should not drive the whole tender decision.

Features that often look good but see low daily use include special connectivity test tools, advanced local configuration, rarely used prepaid options, optional pressure data without analytics, and dashboard modules with no assigned user.

A Rarely Used Feature Can Still Be Necessary

I do not call these features useless. I call them conditional.

The best example is test verification. The NB-IoT manual says the test verification function is used to verify connectivity and data transmission accuracy when the customer first uses the NB-IoT water meter. It also says the function is rarely used after normal use, but can be used for on-site diagnosis when the NB-IoT meter is abnormal. This is a useful maintenance feature. But it should not be presented as a daily operational advantage.

Optional pressure detection is another example. The ultrasonic smart meter material lists integrated pressure detection as optional. This can be valuable in a pressure management or hydraulic analysis project. But if the utility has no pressure analytics, no district model, and no field response process, the pressure data may stay unused.

Prepaid and postpaid switching can also be powerful in the right market. The prepaid meter manual lists switchable prepaid and postpaid mode. But if the utility only uses postpaid billing, the prepaid features may not justify extra cost. If the utility uses STS prepaid billing, TOKEN functions become central.

I also watch battery impact. More frequent reporting and extra sensor functions may increase power demand. ISO 4064 requires that a non-replaceable battery supports correct meter function for at least one year longer than the operational lifetime of the meter. So I always connect feature selection with battery life, Berichtszyklus, and maintenance plan.

A feature that looks impressive is not automatically a bad feature. It becomes a bad purchase when nobody uses it, nobody maintains it, and nobody budgets for its lifecycle.

How Should You Prioritize Features in Your Next Tender?

A tender should not reward the longest feature list. It should reward the clearest operational value and responsibility boundary.

Prioritize smart meter features by daily use, billing impact, alarm value, event traceability, battery maintenance, communication reliability, platform compatibility, and field response capability. Treat rare diagnostic functions as support tools, not main scoring items.

My Tender Priority Method

I start with the core job. The meter must measure correctly within its declared metrological range and rated working conditions. Smart functions should not disturb the metrological characteristics of the meter. ISO 4064 states that ancillary devices must not alter the metrological characteristics of the meter [5]. This is my first boundary.

Then I rank functions by daily value.

Remote reading is usually priority one because it supports billing and reduces manual collection work. Frozen data is also important because the NB-IoT system can display frozen meter data every night and save it in the database without change. Event records and alarm records are priority two because they support complaint investigation and abnormal condition response. Battery indication is priority three because it protects long-term operation and maintenance planning [6].

After that, I add project-specific options. If the project is prepaid, STS TOKEN logic and prepaid/postpaid configuration matter. If the project focuses on NRW, Leckerkennung, Trockenrohrerkennung, and better low-flow measurement may matter. If the project focuses on pressure management, optional pressure detection may matter. But I do not buy optional pressure detection unless the platform and field team can use it.

I also specify the communication system. NB-IoT needs coverage, SIM or operator support, platform connection, and reporting-cycle control. LoRa oder LoRaWAN benötigen möglicherweise Gateways, Leistung, Backhaul, Signalprüfung, and correct installation. M-Bus or RS485 needs cable design and concentrators. The meter supports remote data, but the system must move, speichern, and use that data.

In the next tender, I would ask suppliers to separate “standard included,” “optional,” “project-specific,” and “diagnostic only” functions. This makes cost clearer and reduces the chance of paying for features that nobody will use.

Abschluss

Specify remote reading, Ereignisaufzeichnungen, Alarm, Batteriestatus, Plattformregeln, and response workflows first. Add advanced features only when your team will actually use them.