Scaling does not work with profile and non-standard attribute index

Hi everyone.

We're reading Landis+Gyr E650/ZMD410/ZMD310 meters with the .Net implementation.

I've been trying to fix an intermittent scaling issue for the past couple of days. I came to the following:

Before reading the buffer, check if each of the Register (includes ExtendedRegister) and DemandRegister objects need its scalar to be read. If its scalar hasn't been read yet, read it now.

Populate the key in the capture objects with the scalars and units.

Now read the load profile.

This has worked great, until I cleared the object cache completely and started from scratch.

This time, my code read the scalars all nicely. They are in the saved object cache, as can be seen here:

https://pastesio.com/lng-e650-object-cache

The issue is that the scalars are only applied to attribute id 2 of Registers, but the meter uses attribute 11 in the profile's capture objects.

Attribute 11 does not exist in the DLMS standard for a Register class, so we queried this with the manufacturer. They didn't have a solid definite answer, so the best they could provide us is "it's not an attribute index on the register, but rather some or other offset into an array".

In either case, I need to understand a) why did Gurux.DLMS scale my values previously and b) how can I coerce the library to do it reliably or how can I reliably prevent it from happening to do it myself.

These values are obviously unscaled and need to be scaled by 0.01. We have 230V supplies here, and the values are ~22000 - 25000. The current values are also out by a factor 100 from the instantaneous values we typically see.

I have had issues with double scaling in the past, which is obviously also undesirable.

It is also not as simple to just decide to scale everything myself, as on this same meter in the billing profile, we have max demand attributes 2 and 5, where 5 is the clock object captured at the time of the max value. This means that I will need to understand what the value is for in order to know if I should read it.

The registers with the max demand are ExtendedRegister type, so that could be used to help. However, I'd rather not guess.