Error and change in version 9.0.2409.1701 (that we also get in our code).

By Karl, 19 September, 2024
Forums
DLMSDirector

Change:
In version 8.2.2103.2201, when we read 0.0.96.1.0.255 on our EMH LZQJ Dlms meter, we get the serial number as a readable string (07953704).
When we do the same thing in the latest version 9.0.2409.1701, we get the Hex representation of the serial number like this: {{{48,55,57,53,51,55,48,52}}}.

This also happens in our code, and so it breaks our check that we are talking to the correct meter.

Error:
When I try to read last 1 day of profile generic 1.0.99.1.0.255 on the same EMH meter in version 8, it works fine, but trying the same in version 9 of GXDLMSDirector gives me this error:
"Unable to cast object of type 'System.Object[]' to type 'System.IConvertible."

Karl

2 months 2 weeks ago

Tested different versions of the C# Nuget package Gurux.DLMS, and I can see that the error/change happened in versjon: 9.0.2.2409.11701.

If I downgrade to a version before 9.0.2.2409.11701, things works like before.

Karl

2 months 2 weeks ago

I have now tested, and it is 2 changes to the GXDLMS.cs source code that was introduced in commit 52e31b6e, on line 4427 and 4479 that seem to change how we read the meter id (serial number read using Obis 0.0.96.1.0.255).

If I revert these 2 changes, things seem to work (in our code. I have not tested it in DLMSDirector, but the changes/error seems to be the same).

Kurumi

2 months 2 weeks ago

Hi,

Can you add read and reply as a hex string so I can check what might cause this?
Only those two messages are enough.

BR,
Mikko

Karl

2 months 2 weeks ago

I am not 100% sure what you mean, but here is the log of me reading 0.0.96.1.0.255 (manufaturing number) in the latest GXDLMSDirector (returns "{{{48,55,57,53,51,55,48,52}}}"

09:01:58 Read object type Data index: 2
7E A0 14 00 02 3C F1 41 32 57 72 E6 E6 00 05 01 02 C0 08 CA D5 7E
09:01:58
7E A0 1C 41 00 02 3C F1 52 F4 F2 E6 E7 00 0C 01 00 09 08 30 37 39 35 33 37 30 34 E1 3C 7E

And here I have done the same thing in an older version 8 of GXDLMSDirector:
09:04:09 Read object type Data index: 2
7E A0 14 00 02 3C F1 41 32 57 72 E6 E6 00 05 01 02 C0 08 CA D5 7E
09:04:09
7E A0 1C 41 00 02 3C F1 52 F4 F2 E6 E7 00 0C 01 00 09 08 30 37 39 35 33 37 30 34 E1 3C 7E

Returns "07953704".

As you can see, the returned bytes are the same, but it's how the code handles the returned bytes from the meter, that have changed.

As I wrote in my previous comment, if I remove the 2 changes to GXDLMS.cs on line 4424 and 4479, it seems to work as before.

Kurumi

2 months 2 weeks ago

Hi,

This is the information I asked. I didn't remember that this meter uses the Short Name reference. Can you also add the Logican name (OBIS code) of the object you try to read?

BR,
Mikko

Karl

2 months 2 weeks ago

The Obis code I am reading is: 0.0.96.1.0.255 Device ID 1, manufacturing number.

The other error is when I (on the same EMH LZQJ meter) try to read Profile generic Obis code 1.0.99.1.0.255. Then I get this error in the new GXDLMSDirector (but it works fine in the old version 8).

---------------------------
GXDLMSDirector
---------------------------
Unable to cast object of type 'System.Object[]' to type 'System.IConvertible'.
---------------------------
OK
---------------------------

Karl

2 months 2 weeks ago

When I wrote the line number of the 2 changes in GXDLMS.cs, I had the Compare up in visual studio, and I now see that I wrote the wrong line number for change number 2 (I looked at the left pane in VS, instead of the right), so the correct line numbers are:
4427 and 4487 (I guess you figured that out :) )

Kurumi

2 months 2 weeks ago

Hi,

The old code is returned because it works with old meters. I need to think how to handle newer meters. I didn't remember that some L+G meters are using this differently. Old L+G meters do not use blocks and they are just add all data to a single reply. This is causing the problem.

Update to the version 9.0.2409.2004.

BR,
Mikko

Karl

2 months 2 weeks ago

Ok. I did not know that. We collect data from a lot of old meters. There seem to be a lot of old equipment in this business :)

I have now downloaded the latest nuget package, and tested our code on all metertypes we collect data from (for DLMS this is EMH, L+G and Cewe), and it works, so thanks again for your fast replys and fix!