Time-of-Use Metering

Energy and Metering

Principle

Time-of-use electricity pricing divides a day into peak, flat, and off-peak periods, with different electricity rates for each period, guiding users to shift load. Smart meters need to have a built-in clock, time zone, and rate switching table to accumulate electricity usage for each period separately. The main station issues rate plans and holiday strategies via NB-IoT/4G, and the meter freezes data according to rules. In case of disputes, the frozen records can be checked.

Synchronization

Clock drift can cause period misalignment, so regular network synchronization and battery monitoring are required; daylight saving time and policy changes require remote upgrades of the rate table.

User side

Work with the app to display electricity consumption curves by time periods to help optimize habits; IoT EV charging stations can automatically avoid peak periods.

Clock management on both the meter and module sides

Time-of-use billing relies on the clock and tariff switching table within the meter; any drift may cause incorrect allocation of peak and off-peak electricity and lead to billing disputes. Smart meters should support network time synchronization, clock keeping, and leap second handling, and record alarms and freeze data when clock anomalies occur. NB-IoT and 4G module wake-up intervals must meet the master station polling and synchronization window requirements; PSM deep sleep scenarios need to evaluate the impact of temperature drift and battery voltage on the crystal oscillator. Tariff table upgrades should support breakpoint resume and signature verification to prevent half-set tariffs due to power outages.

Master station, dispute handling, and regulatory interfacing

The master station must save the tariff version, effective time, and operator to facilitate regulatory inspection and user disputes. In case of disputes, frozen registers, event records, and external standard table data are often compared. When the IoT platform displays curves to users, it should indicate time zones and daylight saving rules to avoid the situation where "the curve is understood but the electricity bill is not." If interactive loads such as EV charging stations and energy storage participate in demand response, time-of-use and real-time pricing strategies may overlay, and the billing engine must be layered, clear, and explainable.

Engineering Practice Supplement

Cross-team collaboration for "time-of-use metering": Hardware provides impedance and power budget, RF provides spurious and sensitivity margin, embedded team clarifies thread model and storage lifespan, and cloud team clarifies SLA and rate limiting. For NB-IoT and similar scenarios, the business model must match the wake-up cycle, packet length, and downlink capacity; for vehicle-mounted and mobile scenarios, session retention during handover and roaming must be considered. At project closure, perform a "red team" style review: define behavior for weak network, power outage, certificate expiration, clock jumps, and full storage.

The Clock Must Be Aligned Before a Tariff Switch Takes Effect

Time-of-use metering books energy into different tariff registers according to a published schedule. Inside the meter there is a clock, a calendar, a holiday schedule, and a tariff-switch table. When a period boundary is crossed, the increment goes into the new register and a freeze is left behind. The communication module does not calculate the bill. It is responsible for delivering time sync, the tariff table, and the freeze read reliably, and for bringing the result back. Shift the period by one slot and peak and off-peak energy are recorded the wrong way around for the whole stretch, which is hard to reconstruct from the total alone.

This requires the meter clock to be aligned with the master station, time zone and seasonal-adjustment rules to match policy, and the tariff table to carry a version and an effective time. Transfer must be checkable and resumable. The wake interval of narrowband or LTE must cover the time-sync window. In deep sleep the crystal drifts with temperature and battery voltage, so the first job after waking is to decide whether the clock is still trustworthy. Policy changes are often pushed in a burst. The module has to handle concurrency and a write that stops halfway; it must not reset after overwriting only half of the periods. Meter data items are covered in DL/T 645. Timestamps for transformer-area load have to line up with smart-grid IoT.

Continuing to accumulate on the old periods after the clock is already invalid, with neither an alarm nor a freeze, is an error that creates a dispute directly. Power loss during an upgrade leaves a half-written schedule, and a peak period is stored at the off-peak price. If the platform uses the browser time zone and the meter uses standard time, the curve and the bill diverge. A holiday schedule that was not updated for the year applies a workday tariff to a holiday. If a charger applies both a real-time price and a time-of-use price with no priority between them, the unit price the user sees cannot be explained.

A dispute needs the tariff version, the effective time, the frozen registers, and clock-fault events. A single total-energy record is not enough. Module logs should keep the download summary and the meter return code, so it is possible to tell that the master station never sent it, the module never delivered it, or the meter refused the write.

When the clock is untrustworthy, the meter needs an explicit behavior: pause accumulation across periods, or park the energy in a register pending review and process it after time sync succeeds. Silently following the local clock writes peak and off-peak wrong for a long time. While the module is offline, the master station must not treat a successful send-interface return as proof the tariff is in effect. It has to read the version and effective time back. The time source itself has to resist a jump. One large wrong step cuts a freeze record onto the wrong date. A clock stopped by battery undervoltage should be recorded separately from a communications outage, or an energy gap will be mistaken for a freeze the module failed to deliver.

Related Terms

Return communication modules terminology