<![CDATA[OBIS 1.0.32.7.0.255 Phase A Voltage Scaler-Unit 0xFF Parsing Bug (-1 vs 255 Exponent)]]>Overview

When querying Class 3 (Register) object 1.0.32.7.0.255 (Phase A Instantaneous Voltage), our data collector parsed a raw voltage value of 2200 with scaler 0xFF and produced a catastrophic measurement reading: 2200000000000000000000 V (2.2 x 10^27 V).

DLMS APDU Response Trace

C4 01 C1 00 00 02 02 12 08 98 02 02 0F FF 16 23

ASN.1 Type Dissection

  • C4 01 C1: GET-Response-Normal (Invoke-Id-And-Priority C1)
  • 00 00: Data-Access-Result success (0)
  • 02 02: Structure of 2 elements
    • 12 08 98: Element 1 -> double-long-unsigned (Value = 2200 / 0x0898)
    • 02 02: Element 2 -> Structure of 2 elements (Scaler_Unit_Type)
      • 0F FF: Scaler -> Integer8 (0xFF)
      • 16 23: Unit -> enum (35 = 0x23 = Volts V)

Root Cause

Per DLMS Blue Book Section 4.3.3, the scaler field is of type Integer8 (signed 8-bit integer) in two's complement representation.

  • 0xFF = -1 (Scaling factor is $10^{-1} = 0.1$)
  • Correct calculation: $2200 \times 10^{-1} = 220.0\text{ V}$
  • The bug: The parsing library treated 0xFF as uint8_t (255), evaluating $2200 \times 10^{255}$ and overflowing database decimal columns!
]]>https://dlms.sharur.org/topic/12/obis-1.0.32.7.0.255-phase-a-voltage-scaler-unit-0xff-parsing-bug-1-vs-255-exponentRSS for NodeFri, 16 Oct 2026 19:50:08 GMTSat, 22 Aug 2026 12:32:50 GMT60<![CDATA[Reply to OBIS 1.0.32.7.0.255 Phase A Voltage Scaler-Unit 0xFF Parsing Bug (-1 vs 255 Exponent) on Sat, 22 Aug 2026 12:35:12 GMT]]>Thanks Elena! We applied the signed int8 cast in the collection pipeline parser. All phase voltages (A/B/C: 1.0.32.7.0.255, 1.0.52.7.0.255, 1.0.72.7.0.255) now correctly read 220.4V, 219.8V, and 220.1V.

]]>https://dlms.sharur.org/post/55https://dlms.sharur.org/post/55Sat, 22 Aug 2026 12:35:12 GMT<![CDATA[Reply to OBIS 1.0.32.7.0.255 Phase A Voltage Scaler-Unit 0xFF Parsing Bug (-1 vs 255 Exponent) on Sat, 22 Aug 2026 12:35:12 GMT]]>Note that for Class 4 (Extended Register) and Class 5 (Demand Register), the scaler-unit structure is identical, but is followed by a status octet-string or bit-string and an optional capture_time (Octet-String, 12 bytes). If you don't enforce signed int8 decoding across all register classes, power factor and reactive energy registers with negative scalers will corrupt downstream analytics.

]]>https://dlms.sharur.org/post/54https://dlms.sharur.org/post/54Sat, 22 Aug 2026 12:35:12 GMT<![CDATA[Reply to OBIS 1.0.32.7.0.255 Phase A Voltage Scaler-Unit 0xFF Parsing Bug (-1 vs 255 Exponent) on Sat, 22 Aug 2026 12:35:11 GMT]]>This is one of the classic pitfalls in DLMS COSEM client implementations!

Here is the safe deserialization snippet in Python:

import struct

def decode_scaler_unit(scaler_byte, unit_enum):
    # 'b' ensures signed 8-bit integer interpretation (-128 to 127)
    signed_scaler = struct.unpack('b', bytes([scaler_byte]))[0]
    multiplier = 10 ** signed_scaler
    return signed_scaler, multiplier

scaler, mult = decode_scaler_unit(0xFF, 35)
print(f"Scaler: {scaler}, Multiplier: {mult}, Voltage: {2200 * mult} V")
# Output: Scaler: -1, Multiplier: 0.1, Voltage: 220.0 V
]]>https://dlms.sharur.org/post/53https://dlms.sharur.org/post/53Sat, 22 Aug 2026 12:35:11 GMT