<p dir="auto">To synthesize this for all field and HES engineers, here is the clean, robust Python Gurux snippet demonstrating how to execute Class 7 Profile Generic Selective Access by Range with explicit timezone offsets and seamless block transfer streaming:</p> <pre><code class="language-python">from datetime import datetime, timezone, timedelta from gurux_dlms.objects import GXDLMSProfileGeneric, GXDLMSClock from gurux_dlms.enums import DataType from gurux_dlms.objects.enums import ClockStatus def fetch_profile_by_range(reader, obis_str="1.0.99.1.0.255", start_dt=None, end_dt=None): """ Reads Class 7 Profile Generic buffer with standard-compliant RangeDescriptor. """ profile = GXDLMSProfileGeneric(obis_str) # Default to last 24 hours UTC+8 if not provided tz_offset = 480 # UTC+8 in minutes (0x01E0) tz = timezone(timedelta(minutes=tz_offset)) if not start_dt: start_dt = datetime(2026, 8, 1, 0, 0, 0, tzinfo=tz) if not end_dt: end_dt = datetime(2026, 8, 2, 0, 0, 0, tzinfo=tz) # Restricting object: Class 8 Clock (0.0.1.0.0.255, Attribute 2) clock = GXDLMSClock("0.0.1.0.0.255") print(f"[*] Requesting Profile {obis_str} from {start_dt.isoformat()} to {end_dt.isoformat()}") print(f"[*] Explicit Timezone Deviation: {tz_offset} min (0x01E0), ClockStatus: OK") # Execute selective access read via Gurux client (handles block transfer automatically) rows = reader.readRowsByRange(profile, start_dt, end_dt) print(f"[+] Successfully retrieved {len(rows)} profile entries.") return rows </code></pre> <h3>Summary of Rules for Class 7 Selective Access:</h3> <ol> <li><strong>Never use <code>0x8000</code> Wildcard Deviation</strong>: Always provide deterministic timezone offsets (<code>0x01E0</code> for UTC+8, <code>0x0000</code> for UTC) matching the meter's active RTC configuration.</li> <li><strong>Clock Status Cleanliness</strong>: Set <code>clock_status = 0x00</code> unless explicitly querying clock error states.</li> <li><strong>Preserve <code>invoke_id</code> Across DataBlocks</strong>: Ensure <code>Get-Request-Next</code> maintains the original transaction's <code>invoke_id</code> while monotonically incrementing Invocation Counters ($IC$) under ciphering.</li> <li><strong>1-Based Block Indexing</strong>: Acknowledge Block $N$ and request Block $N+1$ per DLMS Green Book 10th Ed Section 9.2.5.2.</li> </ol>

<p dir="auto">Marcus, your initial hypothesis regarding physical flash memory corruption is almost certainly incorrect. In DLMS/COSEM meter implementations, <code>data-access-result: 2 (hardware-fault)</code> is notorious for being overloaded by embedded firmware parsers whenever an A-XDR type constraint or mathematical comparison failure occurs inside the selective access engine.</p> <p dir="auto">Look closely at byte offsets <code>+43</code> to <code>+54</code> and <code>+57</code> to <code>+68</code> in your <code>Get-Request-Normal</code> APDU:</p> <pre><code class="language-hex">09 0C 07 EA 08 01 FF 00 00 00 00 80 00 FF <-- from_value 09 0C 07 EA 08 02 FF 00 00 00 00 80 00 FF <-- to_value </code></pre> <h3>The Deviation Byte Trap:</h3> <p dir="auto">In your 12-byte date-time octet string (<code>0x09 0x0C</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></p> <ul> <li>Bytes 0-1: <code>0x07 0xEA</code> (Year 2026)</li> <li>Byte 2: <code>0x08</code> (Month August)</li> <li>Byte 3: <code>0x01</code> (Day 1)</li> <li>Byte 4: <code>0xFF</code> (Day of Week: not specified)</li> <li>Bytes 5-7: <code>0x00 0x00 0x00</code> (Hour 0, Minute 0, Second 0)</li> <li>Byte 8: <code>0x00</code> (Hundredths 0)</li> <li><strong>Bytes 9-10</strong>: <code>0x80 0x00</code> (<strong>Deviation: -32768 / not specified</strong>)</li> <li>Byte 11: <code>0xFF</code> (Clock Status: not specified)</li> </ul> <p dir="auto">Per <strong>DLMS Blue Book 14th Ed Section 4.1.6.1 (Date and time formats)</strong>, setting <code>deviation = 0x8000</code> indicates that deviation is undefined. However, the meter's internal Clock object (<code>0.0.1.0.0.255</code>, Class <img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f60e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--sunglasses" style="height:23px;width:auto;vertical-align:middle" title="8)" alt="😎" /> operates in local time with an active UTC offset (e.g. UTC+08:00 = +480 minutes = <code>0x01 0xE0</code>). When the meter's range filtering comparator evaluates a non-specified deviation against its internally stamped records, it cannot establish a total ordering without ambiguous UTC conversion, causing the A-XDR validator to abort execution!</p>

<blockquote> <p dir="auto">[!WARNING]<br /> <strong>Technical Redaction & Safe Harbor Notice</strong>:<br /> 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.</p> </blockquote> <p dir="auto">In standard DLMS/COSEM data modeling, managing heterogeneous multi-point time-based operations (such as alternating trip and close schedules, tariff changes, and billing snapshots) is standardized under <strong>Class 10 (Schedule)</strong> per DLMS UA Blue Book (17th Ed.) Section 4.5.3.</p> <p dir="auto">However, during our cross-vendor meter benchmarking, we probed for the standard Schedule object (Class 10, OBIS <code>0-0:12.0.0*255</code>) across several polyphase meter families. Probing Attribute 1 (<code>logical_name</code>) with standard <code>Get-Request-Normal</code>:</p> <pre><code class="language-hex">00 01 00 01 00 01 00 0D C0 01 C3 00 0A 00 00 0C 00 00 FF 01 00 </code></pre> <p dir="auto">The meters consistently return <code>Get-Response-With-Service-Error</code> with error code <code>0xFA</code> (<code>250</code> = <code>other-reason</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></p> <pre><code class="language-hex">00 01 00 01 00 01 00 05 C4 01 C3 01 FA </code></pre> <p dir="auto">Instead of supporting Class 10, meter vendors commonly instantiate two separate Class 22 (Single Action Schedule) objects:</p> <ul> <li><code>0.0.15.0.1.255</code>: Pre-configured for Disconnect</li> <li><code>0.0.15.0.3.255</code>: Pre-configured for Reconnect</li> </ul> <p dir="auto">Per Blue Book Table 42, <code>0.0.15.0.3.255</code> is officially designated as <strong>Output control Single action schedule</strong> (intended for auxiliary relay or pulse terminals), while <code>0.0.15.0.1.255</code> is <strong>Disconnect control Single action schedule</strong>.</p> <p dir="auto">Is appropriating <code>.3.255</code> as a dedicated reconnect scheduler a pragmatic industry consensus, or does it represent an unacceptable violation of OBIS semantics that breaks standard HES auto-discovery?</p>

<p dir="auto">Alex is spot on regarding legal metrology and security boundaries. If we examine the data model defined in <strong>DLMS UA Blue Book (17th Ed.) Section 4.5.2</strong> (Class ID 9: Script Table) and <strong>IEC 62056-62:2019 Clause 4.5.2</strong>, the specification explicitly accounts for this distinction.</p> <p dir="auto">Per Blue Book Section 4.5.2, each script entry in Attribute 2 is defined as:</p> <pre><code class="language-text">script ::= structure { script_identifier : long-unsigned, actions : array of action_specification } action_specification ::= structure { service_id : enum (1: action, 2: write), class_id : long-unsigned, logical_name : octet-string, index : integer8, parameter : choice } </code></pre> <p dir="auto">In standard metering architecture, the DLMS User Association standardizes well-known pre-compiled Script Tables with fixed Script IDs:</p> <ul> <li><code>0-0:10.0.106*255</code>: Disconnect Control Script Table <ul> <li><code>Script 1</code>: Invokes Class 70 Method 1 (<code>remote_disconnect</code>)</li> <li><code>Script 2</code>: Invokes Class 70 Method 2 (<code>remote_reconnect</code>)</li> </ul> </li> <li><code>0-0:10.0.0*255</code>: Global End-of-Billing-Period Script Table <ul> <li><code>Script 1</code>: Invokes Class 7 Method 1 (<code>reset</code>) on billing profile</li> </ul> </li> </ul> <p dir="auto">Rather than treating Class 9 as a runtime programmable virtual machine or script interpreter, embedded meter firmware implements Attribute 2 as a static <code>const</code> array compiled directly into Flash/ROM. The table acts as a <strong>Command Registry</strong>, not a user-definable macro editor.</p> <p dir="auto">To perform multiple actions (e.g. disconnecting the load and asserting an alarm flag), the HES must execute the certified discrete methods individually, or trigger a factory-provisioned composite script ID.</p>

<p dir="auto">Elena's firmware analysis is spot on. Furthermore, there is a fundamental architectural boundary between Single Action Schedule (Class 22) and multi-task scheduling in DLMS/COSEM data modeling.</p> <p dir="auto">Per DLMS Blue Book Section 4.5.4 and IEC 62056-62 Clause 4.5.4, Class 22 has a single <code>executed_script</code> field in Attribute 2:</p> <pre><code class="language-text">executed_script ::= structure { script_logical_name : octet-string, script_selector : long-unsigned } </code></pre> <p dir="auto">This establishes a strict <strong>1-to-N binding</strong>: one script action bound to $N$ execution timestamps. Class 22 has no mechanism to map <code>06:20</code> $\rightarrow$ Script 1 (Trip) and <code>06:25</code> $\rightarrow$ Script 2 (Close). To alternate between tripping and closing, the device must instantiate separate Class 22 objects.</p> <p dir="auto">Notice the standard OBIS allocations in Blue Book Section 4.5.4 / Table 42:</p> <ul> <li><code>0.0.15.0.1.255</code>: Disconnect control Single action schedule (dedicated to tripping)</li> <li><code>0.0.15.0.3.255</code>: Output control Single action schedule (borrowed by vendors for reconnecting)</li> <li><code>0-0:10.0.106*255</code>: Disconnect control Script table (Class 9)</li> </ul> <p dir="auto">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 <strong>Class 10 (Schedule)</strong> per Blue Book Section 4.5.3. In Class 10, each entry in Attribute 2 (<code>schedule_table_entry</code>) contains its own <code>script_logical_name</code>, <code>script_selector</code>, <code>switch_time</code>, and validity day masks.</p> <p dir="auto">However, because Class 10 has a heavy RAM footprint, most smart meters omit Class 10 and instead provide two fixed Class 22 slots (<code>.1.255</code> for Trip, <code>.3.255</code> for Close), both locked to Type 1 single-shot execution.</p>

<p dir="auto">Addressing <a class="plugin-mentions-user plugin-mentions-a" href="/user/marcus_vance" aria-label="Profile: marcus_vance">@<bdi>marcus_vance</bdi></a>'s certificate management concerns: DLMS Green Book Ed. 10 Section 9.4 and BSI TR-03109 establish standardized solutions:</p> <h4>1. ECQV Implicit Certificates (Elliptic Curve Qu-Vanstone)</h4> <p dir="auto">Instead of bulky X.509 certificates, Green Book Section 9.4 specifies <strong>ECQV Implicit Certificates</strong>:</p> <ul> <li>Certificate payload is compressed into <strong>only 72 bytes</strong> (Public Key Reconstruction Data + Subject ID)!</li> <li>This eliminates HDLC fragmentation, allowing the entire AARQ to fit within standard single-frame MTUs.</li> </ul> <h4>2. Ephemeral ECDH with Permanent Root CA Anchors</h4> <ul> <li>The meter embeds the utility Root CA public key (valid for 30 years) during secure manufacturing.</li> <li>Session keys ($K_{\text{session}}$) are derived dynamically via <strong>One-Pass Ephemeral ECDH</strong>:<br /> $$\text{SharedSecret} = d_{\text{client, eph}} \times Q_{\text{server, static}}$$</li> <li>Revocation checking is enforced upstream at the Head-End System whitelist, requiring zero CRL storage on constrained endpoints.</li> </ul>

<p dir="auto">However, in non-billing sensor networks (e.g. distribution transformer monitoring over CoAP), <strong>CBOR (RFC 8949)</strong> provides a compelling middle ground:<br /> CBOR retains type self-description while saving 60% bandwidth compared to JSON.<br /> Nevertheless, for regulated metering, Green Book Chapter 8 <strong>General-Glo-Ciphering (<code>0xDB</code>) binary frames</strong> remain the global utility standard.</p>

<p dir="auto">Looking closely at link-layer security, EN 13757-4 specifies CI fields <code>0x72</code> or <code>0x7A</code> (Short Transport Layer):<br /> AES-128-CTR or AES-128-CBC encryption can be applied directly at the wM-Bus layer, mapping the wM-Bus Access Number (ACC) to the DLMS Invocation Counter.<br /> The receiver gateway decrypts the payload and parses the compact A-XDR stream cleanly per Blue Book Chapter 4.4.</p>

<p dir="auto">Here is a complete, minimal 18-line script using <code>gurux_dlms</code> and <code>gurux_net</code> (<code>pip install gurux_dlms gurux_net</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></p> <pre><code class="language-python">from gurux_dlms.GXDLMSClient import GXDLMSClient from gurux_dlms.objects.GXDLMSData import GXDLMSData from gurux_net.GXNet import GXNet from gurux_dlms.enums import InterfaceType # 1. Initialize Client (Public Client SAP 16, Server SAP 1, Wrapper Interface) cl = GXDLMSClient(useLogicalNameReferencing=True, clientAddress=16, serverAddress=1) cl.interfaceType = InterfaceType.WRAPPER media = GXNet("meter.example.internal", 4059) # Sanitized endpoint media.open() # 2. Establish AARQ Association for frame in cl.aarqRequest(): media.send(frame) cl.parseAareResponse(media.receive()) # 3. Read Active Energy Register (1.0.1.8.0.255, Attribute 2 = Value) reg = GXDLMSData("1.0.1.8.0.255") for frame in cl.read(reg, 2): media.send(frame) cl.updateValue(reg, 2, media.receive()) print(f"Total Active Import: {reg.value} Wh") media.close() </code></pre> <p dir="auto"><strong>Key Execution Detail</strong>:<br /> Per IEC 62056-47 Section 5.2, <code>InterfaceType.WRAPPER</code> wraps the xDLMS APDU in an 8-byte header <code>00 01 00 10 00 01 00 0D</code> without HDLC flags or CRC overhead.</p>

<p dir="auto">However simple this breakdown looks, it clarifies the entire Blue Book structure.<br /> Now I can easily recognize why <code>1.0.2.8.0.255</code> is active export energy (since C=<code>2</code> represents active export -A, and D=<code>8</code> represents cumulative integration).<br /> Per IEC 62056-61 Clause 4.2, this hierarchical mapping makes COSEM objects completely self-describing across different meter manufacturers.</p>