DLMS Short Name parsing issue: object 1.0.15.8.0.255 assigned SN = 0

Hi Mikko,

Thanks for your reply. Let me explain the full context and what I’m seeing on my meter.

1. How I run the program

I’m using the Gurux Python DLMS client in SN referencing mode. From my project directory, I run:

```
python main.py -h 172.16.0.4 -p 5002 -n '03983990' -r sn -g '1.0.15.8.0.255:2'
```

* `-h 172.16.0.4` and `-p 5002` point to the meter’s IP/port.
* `-n '03983990'` is my meter’s logical device number.
* `-r sn` forces Short Name referencing.
* `-g '1.0.15.8.0.255:2'` means “read attribute 2 of OBIS 1.0.15.8.0.255”.

2. What I expect vs. what actually happens

Under normal circumstances, the meter’s **Association View** should list every OBIS code together with a 2-byte short name (SN). Gurux then stores each object with `obj.name = <shortName> (int)`. Examples I see work fine:

* **OBIS** `1.0.15.8.1.255` → **SN** `24` → Gurux sets `obj.name = 24` → I can read it.
* **OBIS** `1.0.15.8.2.255` → **SN** `48` → Gurux sets `obj.name = 48`.

However, when the meter returns the Association View I see this line for `1.0.15.8.0.255`:

```
[SN-PARSE] OBIS: 1.0.15.8.0.255, SN: 0, classID: 3
```

* Here, `classID = 3` means it really is a **Register** object.
* But **SN = 0**. In DLMS/SN referencing, short name `0x0000` is effectively “no usable short name,” so Gurux does not store a numeric SN for that object. Instead, Gurux leaves `obj.name = "1.0.15.8.0.255"` (a string).

3. The exact error I get

When I afterwards try to read that object with Gurux’s `GXDLMSClient.read()`, I see:

```
TypeError: can only concatenate str (not "int") to str
File ".../GXDLMSClient.py", line 1214, in _read
sn += (attributeOrdinal - 1) * 8
TypeError: can only concatenate str (not "int") to str
```

In other words, because `obj.name` is a string (`"1.0.15.8.0.255"`), the internal read logic that expects an integer short name blows up.

4. Why this is happening

* My meter only supports **SN referencing** (it does *not* support LN mode).
* For OBIS `1.0.15.8.0.255`, the meter’s firmware is returning a short name of `0x0000`. By the DLMS standard, `0x0000` is not a valid SN for reading; usually it means “no SN assigned.”
* Gurux sees SN=0 and so stores `obj.name` as the logical OBIS string instead of an integer. This is why the read operation fails.

All other registers in that same response have valid SNs (e.g. 24, 48, 72, etc.), so those read correctly.

5. Answers to your question

> **“Is the object type Register or something else?”**

For `1.0.15.8.0.255`, the `classID` is indeed **3**, which corresponds to `GXDLMSRegister` (a standard “Register” object). The meter is simply giving it a short name of `0x0000`. That means there is no usable SN for it, so Gurux falls back to keeping the OBIS (LN) as a string.

6. Summary

* The meter’s Association View is returning **SN=0** for `1.0.15.8.0.255`.
* That means Gurux cannot assign a numeric short name, so it leaves `obj.name = "1.0.15.8.0.255"`.
* Because my firmware does not support LN referencing,

Please let me know if there is a better way to handle an SN=0 case within Gurux, or if the Gurux SDK could warn me when an object’s SN comes back as zero. If you need any additional logs or hex dumps from the association, I’m happy to share.

Best regards,
Danylo Bosenko

Hi Mikko,

Thank you for your reply. Just to add, the meter I’m working with is:

Manufacturer: Elgama-Elektronika
Model: GAMA300 GB3

Let me know if you’d like a full Association View hex dump or any additional data.

Best regards,
Danylo