If a field technician with an optical probe cannot trust what 0.0.15.0.1.255 says locally because the true schedule lives only in our cloud Redis instance, we are creating an untraceable split-brain condition. When cellular towers go dark during a typhoon, having meters stranded because their schedule loop was severed upstream is unacceptable for grid reliability.

We agree to abandon the rolling rewrite hack. Here is our finalized, standard-compliant path forward:

1. For Real-Time Demand Response: When online, the HES will issue explicit, synchronous Action-Request-Normal APDUs invoking Class 70 Method 1/2 directly, ensuring immediate transaction confirmation without corrupting schedule state.
2. For Autonomous Multi-Task Scheduling: We will submit an official engineering change request to the meter vendor to implement Class 10 (Schedule, OBIS 0-0:12.0.0*255) per Blue Book Section 4.5.3, ensuring all recurring entries are verified and stored locally inside the meter's certified NVRAM.
3. For Current Fixed Cycles: We will strictly utilize the dual Class 22 slots (0.0.15.0.1.255 for Disconnect, 0.0.15.0.3.255 for Reconnect) as static, auditable daily setpoints.

Engineering pragmatism cannot come at the expense of field maintainability and self-contained meter truth.

We have RabbitMQ dead-letter queues, exponential backoff retries, and high-availability database clusters. Modern smart meter SPI NOR Flash / EEPROM typically has an endurance of 100,000 write cycles. Writing 4 timestamps a day equals 1,460 writes per year—giving us over 68 years of flash endurance!

Why is a battle-tested, pragmatic cloud queue worse than telling the utility executive board that our $15M AMI infrastructure cannot perform basic automated load control today?

Let me lay out two devastating operational realities that you will face:

1. Field Triage & Optical Probe Blindness

When a communication concentrator fails in a substation and a field technician drives out to troubleshoot with a handheld optical probe (IEC 62056-21 Mode E), what will they see? They will read 0.0.15.0.1.255 Attribute 4 and see a single timestamp from 3 days ago. They will have zero visibility into your cloud Redis queue, conclude that the meter's schedule table is broken or corrupt, and needlessly replace perfectly good meters.

2. Documentation Rot & Knowledge Evaporation (Loss of Historical Context)

However, consider the long-term flaw in this approach. In 3 to 5 years, when the original developers who built this HES daemon leave the utility and the backend is refactored into a new cloud platform, nobody will remember that these 40,000 physical meters depend on a proprietary rolling overwrite loop. The first time the background worker crashes, the entire metering fleet becomes unmanageable.

Per DLMS UA Blue Book (17th Ed.) Section 4.5.4 and IEC 62056-62 Clause 4.5.4, COSEM objects are designed to be self-contained and auditable. Turning Class 22 into a volatile scratchpad violates the integrity of the meter as the legal system of record.

You are converting an autonomous metrological device into a distributed state-machine slave tethered to continuous cellular availability. Consider what happens during a severe winter storm or cellular base-station failure: the meter successfully executes the 08:00 load trip, but the HES fails to deliver the 12:00 follow-up rewrite due to backhaul packet loss. The schedule halts permanently, leaving industrial consumers disconnected or in an undefined state.

Furthermore, per DLMS UA Green Book 10th Ed Section 9.3.4, every SET request consumes cryptographic Invocation Counters (IC) and triggers non-volatile flash sector writes. You are introducing continuous network traffic and active attack surface for a job that should be statically autonomous.

By treating the meter's Class 22 Attribute 4 as a single-item hardware execution mailbox that the HES periodically repopulates, we bypass the immense headaches of debugging Class 10 schedule_table_entry calendar math and Daylight Saving Time edge cases across multiple vendor stacks. We could deploy this service across our 40,000 meters tomorrow.