Bug in the Limiter 'emergency_profile_group_id_list' write

By MetersGuru , 9 February, 2024
Forums
Gurux.DLMS

Hi there. I was using the Python library alongside the GuruX Director and I stumbled upon a bug when trying to write the Limiter 'emergency_profile_group_id_list' attribute.

Basically both the Python library and the GuruX Director write the wrong values for that attribute. You can replicate it very easily on both sides.

My Python version is 3.10
My Director version is 9.0.2311.1001

I'll leave here both logs so you can see the problem from that as well.
The array I am trying to write is: [1, 2, 3, 4]

DIRECTOR LOGS:
13:16:18 Writing object 0.0.17.0.0.255, interface Limiter
TX: 7E A0 2A 00 44 44 D1 03 FE 96 1D E6 E6 00 C1 01 C1 00 47 00 00 11 00 00 FF 09 00 01 04 12 00 01 12 00 02 12 00 03 12 00 04 B6 8C 7E
13:16:19
RX: 7E A0 13 03 00 44 44 D1 1E EB 51 E6 E7 00 C5 01 C1 00 50 89 7E
13:16:19 Reading object 0.0.17.0.0.255, interface Limiter
TX: 7E A0 1C 00 44 44 D1 03 10 61 9D E6 E6 00 C0 01 C1 00 47 00 00 11 00 00 FF 09 00 33 CC 7E
13:16:19
RX: 7E A0 21 03 00 44 44 D1 30 66 78 E6 E7 00 C4 01 C1 00 01 04 12 12 00 12 01 12 12 00 02 12 12 00 37 0D 7E

PYTHON LOGS:
TX: 13:17:01 7E A0 27 03 03 76 7C 2E E6 E6 00 C1 01 C1 00 47 00 00 11 00 00 FF 09 00 01 04 12 00 01 12 00 02 12 00 03 12 00 04 B6 8C 7E
RX: 13:17:02 7E A0 10 03 03 96 A1 D2 E6 E7 00 C5 01 C1 00 50 89 7E

Please let me know if and when this will be fixed. Thank you in advance.

Kurumi

2 years 3 months ago

Hi,

Why do you think that this is wrong? There are four long-unsigned in an array as defined in the DLMS standard. The meter also replies success. I believe that your group IDs don't match with emergency_profile_id and values are not updated because of that.

You can't write any values you want to.

BR,
Mikko

MetersGuru

2 years 3 months ago

The values themselved were correct with respect to the present ids; the problem is that the values are actually changed during the write and they are changed to wrong values. Both the Python library and the GuruX Director, when trying to correctly write [1, 2, 3, 4], instead write [274, 4608, 2, 530].

I think I have identified the problem in the hex string.
In it, the part corresponding to the given list [1, 2, 3, 4] is "00 01 12 00 02 12 00 03 12 00 04", and it should be correctly set to 1 (0001), 2 (0002), 3 (0003) and 4 (0004), with the "12" separators".
The problem is that it takes the wrong values by mixing them and the separators as well, so it wrongly sets those four values to 274 (0112), 4608 (1200), 2 (0002) and 530 (0212).

You can try with both the Python library and the GuruX Director and I believe you will see for yourself this problem. Let me know if you will try this, thanks.

Kurumi

2 years 3 months ago

Hi,

Data is an array of UInt16 values. There are four values: 1, 2, 3 and 4.

01 04 //Array with 4 values.
12 00 01 //1st UInt16 value.
12 00 02 //2nd UInt16 value.
12 00 03 //3rd UInt16 value.
12 00 04 //4th UInt16 value.

So written values are correct.

BR,
Mikko

MetersGuru

2 years 3 months ago

Sorry, it seems I relayed the wrong information. The Python library and the GuruX Director are not the problem, the hex message is correctly sent over by them, however, the problem seems to lie in the GuruX C library (version 20231212.1) that we use on the server side, that wrongly interprets that hex string in the following way.

Given the correct hex "01 04 12 00 01 12 00 02 12 00 03 12 00 04", corresponding to the given list [1, 2, 3, 4], it should be correctly set to 1 (0001), 2 (0002), 3 (0003) and 4 (0004), with the "12" type separators.
The problem is that the GuruX C library takes the wrong values by mixing them and the separators as well, so it wrongly sets those four values to 274 (0112), 4608 (1200), 2 (0002) and 530 (0212).

Our investigations seem to point to the problem being there rather than on our own code, so if you could investigate as well and let us know if you find anything it would be of great help, thank you.

MetersGuru

2 years 3 months ago

Hi,
The tests with the new version of the C library go smoothly now, thank you for the quick fix.
Also, once again, sorry for relaying the wrong information at first, the problem was always on the C side and not on the Python/Director side as I confusely implied at first.