Selective Access by Range on Profile Generic (Class 7) Returning Empty Buffer

[marcus_vance]

Issue Description

When requesting 15-minute Load Profile data from Class 7 (Profile Generic) object 1.0.99.1.0.255 using RangeDescriptor (Selective Access Type 1), the meter responds with an empty buffer (01 00 -> Array with 0 entries), even though the buffer holds 30 days of data.

Request Parameters

• Restricting Object: 0.0.1.0.0.255 (Clock, Attribute 2 - date_time)
• From Value: 2026-08-20 00:00:00.000 (Octet-String 12 bytes)
• To Value: 2026-08-21 00:00:00.000 (Octet-String 12 bytes)

Why the Read Returns Empty

In the DLMS date_time structure (12 bytes):

07 EA 08 14 FF 00 00 00 00 80 00 00

• Bytes 0-1: Year (0x07EA = 2026)
• Byte 2: Month (0x08)
• Byte 3: DayOfMonth (0x14 = 20)
• Byte 4: DayOfWeek (0xFF = not specified)
• Byte 5: Hour (0x00)
• Byte 6: Minute (0x00)
• Byte 7: Second (0x00)
• Byte 8: Hundredths (0x00)
• Bytes 9-10: Deviation (0x8000 = not specified)
• Byte 11: Clock status (0x00)

The culprit: In our request, Byte 4 (DayOfWeek) was populated with the actual day of week (0x04 for Thursday), and Clock Status (Byte 11) was set to 0x80. Many meter implementations require wildcard (0xFF) for DayOfWeek and 0x00 or 0xFF for Clock Status in range filters, otherwise the equality match against the captured buffer timestamps fails!

[david_miller]

Also verify that the first capture object in capture_objects (Attribute 3) of the Profile Generic is indeed the Clock object (0.0.1.0.0.255, class_id: 8, attr_index: 2). If the meter firmware captured the status register first, restricting_object must reference index 1 instead of index 2.

[david_miller]

Also verify that the first capture object in capture_objects (Attribute 3) of the Profile Generic is indeed the Clock object (0.0.1.0.0.255, class_id: 8, attr_index: 2). If the meter firmware captured the status register first, restricting_object must reference index 1 instead of index 2.