The reliable engineering solution for any Head-End System is to implement Attribute 2 Binding Verification during device discovery.

Instead of assuming .3.255 controls auxiliary outputs or breaker reconnects, the HES must read Attribute 2 (executed_script) of both Class 22 objects. Here is the verified readback from 0.0.15.0.3.255:

00 01 00 01 00 01 00 13 C4 01 C1 00 02 02 09 06 00 00 0A 00 6A FF 12 00 02

Dissecting the script reference:

• 09 06 00 00 0A 00 6A FF: Target script LN 0-0:10.0.106*255 (Disconnect Control Script Table)
• 12 00 02: Script selector 2 (Remote Reconnect)

And here is the production Python snippet demonstrating how to dynamically determine whether .3.255 is safely wired to reconnect or auxiliary output:

from gurux_dlms.objects import GXDLMSSingleActionSchedule

def resolve_reconnect_schedule_obis(client):
    schedule_reconnect = GXDLMSSingleActionSchedule("0.0.15.0.3.255")
    
    # Read Attribute 2: executed_script
    client.read(schedule_reconnect, 2)
    
    target_ln = schedule_reconnect.executedScriptLogicalName
    script_selector = schedule_reconnect.executedScriptSelector
    
    # Verify if vendor mapped .3.255 to Disconnect Control Script 2 (Reconnect)
    if target_ln.to_bytes() == b'\x00\x00\x0A\x00\x6A\xFF' and script_selector == 2:
        return "0.0.15.0.3.255" # Confirmed safe reconnect slot
    
    raise NotImplementedError("Meter does not provide a dedicated Disconnect Control reconnect schedule.")

By verifying the executed script pointer at runtime, the HES guarantees safe automated load management regardless of whether the meter implements unified Class 10 or split Class 22 slots.

Let's analyze the firmware execution overhead. In Class 10 (Schedule) per Blue Book Section 4.5.3, Attribute 2 is an array of complex schedule_table_entry structures containing 10 fields each:

typedef struct {
    uint16_t logical_index;
    bool enabled;
    uint8_t script_ln[6];
    uint16_t script_selector;
    cosem_time_t switch_time;
    uint16_t validity_window;
    uint8_t exec_weekdays_mask;
    uint8_t exec_specdays_mask;
    cosem_date_t begin_date;
    cosem_date_t end_date;
} schedule_table_entry_t;

Implementing Class 10 requires:

1. A dynamic sorting and scheduling engine running on every 1-second RTC tick interrupt;
2. Complex calendar matching against Daylight Saving Time (Class and Special Days (Class 11);
3. Up to 2KB to 4KB of dedicated battery-backed NVRAM for multi-entry tables.

On the other hand, Class 22 is a lean 16-byte comparator. By providing two static Class 22 instances (.1.255 and .3.255), the meter firmware achieves 99% of utility requirements (one scheduled load shed and one scheduled restoration per day) with zero dynamic memory risk.

Look closely at IEC 62056-61 (OBIS Identification System) Section 6.2 and DLMS UA Blue Book (17th Ed.) Table 42. The OBIS hierarchy allocates 0.0.15.0.x.255 codes with distinct physical and logical semantics:

• 0.0.15.0.0.255: End of billing period schedule
• 0.0.15.0.1.255: Disconnect control schedule (Class 70 breaker)
• 0.0.15.0.2.255: Image activation schedule (Class 18 OTA)
• 0.0.15.0.3.255: Output control schedule (Class 71 / Class 1 auxiliary outputs)

If a vendor repurposes .3.255 to execute Disconnect Control Script 2 (Reconnect) without explicit specification, an interoperable utility HES that strictly relies on standard OBIS semantics will interpret .3.255 as controlling physical auxiliary relay contacts (such as ripple control or tariff indicator outputs).

If the HES writes a schedule into .3.255 expecting to control external load contactors, but the meter firmware internally trips or closes the main supply breaker, this can cause unintended grid switching. Standards exist precisely to eliminate undocumented proprietary mappings.