Why does Disconnect Control (Class 70) Method 2 return Success (0x00) while output_state remains false?

[carlos_mendez]

[!WARNING]
Technical Redaction & Safe Harbor Notice:
All communication captures, system titles, and cryptographic parameters in this thread have been sanitized and neutralized. Real utility meter identifiers, production encryption keys (GUEK/GAK/MK), SIM IMSIs, and proprietary network envelopes have been substituted with standard IEC 62056 synthetic test vectors. Do not post unredacted production captures or live cryptographic keys.

We are troubleshooting an unexpected relay issue during field commissioning of 200 polyphase commercial smart meters over IEC 62056-47 TCP/IP (port 4059). After a remote load-shedding event, our HES sends a remote reconnection command via Class 70 (Disconnect Control, OBIS 0.0.96.3.10.255), invoking Method 2 (remote_reconnect).

The meter returns an immediate Action-Response-Normal indicating success (0x00

00 01 00 01 00 01 00 05 C7 01 C1 00 00

However, when we immediately read back Attribute 2 (output_state) to verify contact closure, the meter returns 03 00 (boolean: false

00 01 00 01 00 01 00 04 C4 01 C2 00 03 00

The downstream load remains completely de-energized. We contacted the meter manufacturer's FAE, and the classic response was "It works fine on our lab bench tool." Meanwhile, the Wireshark DLMS dissector confirms our Action APDU is 100% syntactically valid. Why is the meter acknowledging reconnection with success (0x00) while physically refusing to close the breaker?

[david_miller]

Carlos, before suspecting a faulty relay coil or broken firmware, look closely at the Disconnect Control state machine in DLMS UA Blue Book (17th Ed.) Section 4.5.3 and IEC 62056-62 Clause 4.5.3.

Your assumption that invoking Method 2 (remote_reconnect) guarantees immediate physical contact closure is where the trap lies. In COSEM Class 70, breaker behavior is governed by Attribute 4 (control_mode) and Attribute 3 (control_state

• control_mode = 1 (Manual): Meter cannot be remotely reconnected.
• control_mode = 2 (Remote only): Method 2 transitions the breaker directly from Disconnected (0) to Connected (1), immediately closing the contact (output_state = true).
• control_mode = 3 (Manual reconnect / Consumer safety): Method 2 only transitions control_state from Disconnected (0) to Ready_for_reconnection (2)! Physical closure requires the end-user to press the physical push-button on the meter terminal.
• control_mode = 5 / 6: Timed reconnection modes with safety arming.

Because of European electrical safety regulations (preventing unattended energization of consumer premises), factory default meters are almost universally shipped with control_mode = 3.

When you send Method 2, returning 0x00 (Success) means the state transition from Disconnected to Ready_for_reconnection succeeded. Have you read Attribute 3 and Attribute 4 to inspect the active control_state?

[carlos_mendez]

David, you nailed it. We just ran a readback on Attribute 3 (control_state) and Attribute 4 (control_mode) on our bench unit:

00 01 00 01 00 01 00 06 C4 01 C3 00 16 02 16 03

• 16 02: control_state = 2 (Ready_for_reconnection)
• 16 03: control_mode = 3

As soon as we manually pressed the optical/display button on the meter front panel, the contactor gave a loud mechanical click, and output_state immediately flipped to 03 FF (true).

This explains why this meter batch passed official DLMS CTT (Conformance Test Tool) certification with flying colors—CTT only checks that the APDU returns 0x00, completely ignoring whether physical voltage was restored downstream! For our unmanned rooftop solar installations, we cannot have technicians pushing buttons. How do we safely reconfigure control_mode to Mode 2 over the air?

[marcus_vance]

To enable direct remote reconnection without human button intervention, your HES must reconfigure Attribute 4 (control_mode) to Mode 2 (Remote only) under the Management Association.

Here is the verified Set-Request-Normal APDU writing control_mode = 2 (enum 0x16 0x02

00 01 00 01 00 01 00 0F C1 01 C4 00 46 00 00 60 03 0A FF 04 00 16 02

Meter response (Set-Response-Normal, success):

00 01 00 01 00 01 00 04 C5 01 C4 00

Once control_mode is set to 2, invoking Method 2 immediately energizes the trip coil, moving control_state directly to Connected (1) and setting output_state to true (0x03 0xFF).

Here is the complete Gurux.DLMS Python snippet to handle this automated commissioning flow:

from gurux_dlms.objects import GXDLMSDisconnectControl
from gurux_dlms.objects.enums import ControlMode, ControlState

def force_remote_reconnect(client, obis_code="0.0.96.3.10.255"):
    relay = GXDLMSDisconnectControl(obis_code)
    
    # 1. Read current control mode
    client.read(relay, 4)
    
    # 2. Reconfigure to Mode 2 (Remote Only) if armed for manual button
    if relay.controlMode != ControlMode.MODE_2:
        relay.controlMode = ControlMode.MODE_2
        client.write(relay, 4)
        
    # 3. Invoke Method 2 (remote_reconnect)
    client.method(relay, 2, 0, "integer8")
    
    # 4. Verify output state is confirmed true
    client.read(relay, 2)
    if not relay.outputState:
        raise RuntimeError("Physical breaker failed to close.")
        
    return True

By enforcing control_mode = 2 prior to reclosing, unmanned substations can be restored automatically without field truck rolls.