Rather than guessing array capabilities, a robust Head-End System must inspect the Association LN (Class 15, OBIS 0.0.40.0.0.255) object_list during commissioning. If 0.0.15.0.1.255 and 0.0.15.0.3.255 are present with Attribute 3 returning Type 1, the HES scheduler should manage two distinct single-shot requests.

Here is the verified working sequence to program a daily 06:20:00 disconnect on 0.0.15.0.1.255:

00 01 00 01 00 01 00 1B C1 01 C1 00 16 00 00 0F 00 01 FF 04 00 01 01 02 02 09 04 06 14 00 00 09 05 FF FF FF FF FF

Meter response:

00 01 00 01 00 01 00 04 C5 01 C1 00

And here is the verified working sequence to program the 06:25:00 reconnect on 0.0.15.0.3.255:

00 01 00 01 00 01 00 1B C1 01 C2 00 16 00 00 0F 00 03 FF 04 00 01 01 02 02 09 04 06 19 00 00 09 05 FF FF FF FF FF

Meter response:

00 01 00 01 00 01 00 04 C5 01 C2 00

Here is the production-tested Python snippet using Gurux.DLMS to handle this fallback gracefully:

from gurux_dlms.objects import GXDLMSSingleActionSchedule
from gurux_dlms.objects.enums import SingleActionScheduleType
from gurux_dlms import GXDateTime

def configure_single_action_schedule(client, obis_code, exec_hour, exec_min):
    schedule = GXDLMSSingleActionSchedule(obis_code)
    client.read(schedule, 3) # Read Attribute 3: type
    
    # Construct date-time structure with wildcards for daily recurring execution
    target_time = GXDateTime(-1, -1, -1, exec_hour, exec_min, 0, 0)
    
    if schedule.type == SingleActionScheduleType.SINGLE_ACTION_SCHEDULE_TYPE1:
        # Firmware strictly enforces Qty = 1
        schedule.executionTime = [target_time]
    else:
        # Extended multi-time support if enabled on advanced meters
        schedule.executionTime.append(target_time)
        
    # Generate and transmit SET-Request APDU for Attribute 4
    return client.write(schedule, 4)

By splitting the schedule across the dedicated .1.255 and .3.255 instances and respecting the Type 1 constraint, all SET requests return Data-Access-Result: success (0x00) without risking breaker desynchronization.

Per DLMS Blue Book Section 4.5.4 and IEC 62056-62 Clause 4.5.4, Class 22 has a single executed_script field in Attribute 2:

executed_script ::= structure {
    script_logical_name : octet-string,
    script_selector     : long-unsigned
}

This establishes a strict 1-to-N binding: one script action bound to $N$ execution timestamps. Class 22 has no mechanism to map 06:20 $\rightarrow$ Script 1 (Trip) and 06:25 $\rightarrow$ Script 2 (Close). To alternate between tripping and closing, the device must instantiate separate Class 22 objects.

Notice the standard OBIS allocations in Blue Book Section 4.5.4 / Table 42:

• 0.0.15.0.1.255: Disconnect control Single action schedule (dedicated to tripping)
• 0.0.15.0.3.255: Output control Single action schedule (borrowed by vendors for reconnecting)
• 0-0:10.0.106*255: Disconnect control Script table (Class 9)

If you genuinely require an arbitrary list of heterogeneous scheduled tasks (e.g., 08:00 Disconnect, 09:30 Reconnect, 12:00 Profile Capture), the proper COSEM object model is Class 10 (Schedule) per Blue Book Section 4.5.3. In Class 10, each entry in Attribute 2 (schedule_table_entry) contains its own script_logical_name, script_selector, switch_time, and validity day masks.

However, because Class 10 has a heavy RAM footprint, most smart meters omit Class 10 and instead provide two fixed Class 22 slots (.1.255 for Trip, .3.255 for Close), both locked to Type 1 single-shot execution.

Look closely at the internal relationship between Attribute 3 (type) and Attribute 4 (execution_time) defined in DLMS UA Blue Book (17th Ed.) Section 4.5.4. Attribute 3 dictates how the meter runtime evaluates the execution schedule:

Type 1: Single execution time (size = 1)
Type 2: Array of n execution times (all elements must share the identical time)
Type 3: Array of n execution times (identical time with wildcards)
Type 4: Array of n execution times (different times allowed, exact dates)
Type 5: Array of n execution times (different times and wildcards allowed)

When you read Attribute 3 of 0.0.15.0.1.255, the meter almost certainly returns 16 01 (enum = 1, Type 1). In embedded firmware running on low-power 32-bit MCUs (such as ARM Cortex-M0+/M3), dynamic heap allocation (malloc) is strictly forbidden for metrological safety. The schedule storage is allocated as a fixed C struct in NVRAM/EEPROM:

typedef struct {
    uint8_t hour, min, sec, hundredths;
    uint8_t year_h, year_l, month, day, day_of_week;
} cosem_single_action_time_t;

// Static buffer sized exactly for Type 1
cosem_single_action_time_t g_disconnect_schedule_slot;

When your SET request arrives with 01 02 (Array Qty = 2), the firmware's A-XDR validator checks both the schema and the active schedule type. Because type == 1, passing an array length greater than 1 violates the semantic constraints of the object. Per DLMS Green Book 10th Ed Section 9.3.4 (Table 46: data-access-result), when a value is outside the device's operational range or semantic capability, returning read-write-denied (0x03) or temporary-failure is the standard conformant behavior.

Moreover, if you attempt to SET Attribute 3 to 16 05 (Type 5), you will also receive 0x03 because the firmware developer sealed Attribute 3 as read-only to prevent runtime heap exhaustion.