DZG workaround not necessary anymore

[volkszaehler]

DZG workaround not necessary anymore

[jmberg]

I was hoping we'd get something from DZG like saying "we fixed it for all devices with serial >= 0x3000000", but who knows ...

[dbeyer]

Or, even better, can we compare an SML message from an old meter with a message from a new meter
(e.g., this one: https://github.com/devZer0/libsml-testing/blob/master/DZG_DVS-7420.2V.G2_mtr2.bin),
and decide about the workaround automatically based on the difference?

Perhaps on the serial numbers?

@jmberg What do you think?

[jmberg]

Hm, that's annoying, but I did tell them about it, so it I guess it's reasonable they'd fix it. Just annoying they decided to fix it in this way, rather than encoding them in some other way that'd be compatible. Though perhaps that'd not even be permitted, I don't know.

I don't remember really this thing really well, and I cannot look right now, maybe later.

For now here's a file from my meter: https://johannes.sipsolutions.net/files/record.bin

Maybe somebody can figure out some versioning identifier or something.

[dbeyer]

@jmberg sml_server can not read the file you posted. (Empty output.) Can you please post another dump as well?

Once it works, can you put your file here: https://github.com/devZer0/libsml-testing/
such that people can test with it? Or give me permission to put your file into that collection?

[jmberg]

Hm, sorry, not sure what was wrong with it. I updated the link with a new file, you have my permission to put it into the collection.

[jmberg]

However - you probably want me to capture one that actually exhibits the bug ... that will have to wait for tomorrow, when the sun is back :-)

[jmberg]

Hm, no, wait, we need a positive value with 327W < value < 368W or so? I can try that ...

Right. Update the link again. sha1sum of the file should be caffcfa373e50c916d3303a8c9d1d17e964dfa9e.

According to my (working) version, that contains the data

"1-0:96.50.1*1": "DZG",
"1-0:96.1.0*255": "0a 01 44 5a 47 00 02 82 22 5e ",
"1-0:1.8.0*255": 5430157.7,
"1-0:2.8.0*255": 26244572.6,
"1-0:16.7.0*255": 356.24

and indeed the 356.24 is (erroneously) encoded as 8b 28

[dbeyer]

This file works with the latest version of sml_server.

Regarding putting it on https://github.com/devZer0/libsml-testing/
could you please tell me the model number,
such that the file name looks something like the following:
DZG_DVS-74?????_jmberg.bin

[dbeyer]

As a comment, I would put:

Value for 16.7.0 was 356.24 but the message wrongly encodes it as -299.12.

[andig]

Sounds as if we should either:

• remove the old workaround
• add a "clean" mode
• hide the old workaround between a "quirks" mode

[dbeyer]

The workaround should be active for @jmberg's meter and inactive for my meter ;-)

I provided a message from a newer DZG meter that does not have the problem and encodes the numbers correctly: devZer0/libsml-testing#15
(In other words, this meter does not have the problem that jmberg's meter has.)

Somebody who understands SML could compare the nicely formatted output of smldump.pl [1] to see if there is a meaningful difference that can be used to activate the workaround for meters that are like the one @jmberg has.

Alternatively, libsml could have a list of serial numbers (or ranges) for which to activate the workaround.

[1] https://github.com/hn/smldump

[jmberg]

Agree with the comment.

The meter is marked as just "DVS7412.2" on the box. There's a production year "2018" and serial # "42082910" (and "1 DZG00 4208 2910") marked on it.

[jmberg]

Here's a picture:

[jmberg]

Sounds as if we should either:

* remove the old workaround

* add a "clean" mode

* hide the old workaround between a "quirks" mode

Personally, I will not really (need to) care, since I'm running my own infrastructure.

But others might be updating their installation, so it's a strange to them perhaps? Might need to at least advertise this change widely so people are aware?

[jmberg]

Alternatively, libsml could have a list of serial numbers (or ranges) for which to activate the workaround.

I suspect that's the only possibility.

FWIW, I reached out to the company last night referring to this issue - last time in 2018 after all they did respond, even if they never told me they fixed it :-)

[dbeyer]

Agree with the comment.

The meter is marked as just "DVS7412.2" on the box. There's a production year "2018" and serial # "42082910" (and "1 DZG00 4208 2910") marked on it.

Can I put the picture also in the testing repo as file?
devZer0/libsml-testing#16
Then I will add pictures of my meters as well.
Might be nice in case some people want to dig deeper.

[jmberg]

I guess I have no objection to making this public, already is here.

[dbeyer]

So, in terms of implementation, the if statement

libsml/sml/src/sml_list.c

Line 194 in d656822

if (l->obj_name && l->obj_name->len == sizeof(dzg_serial_name) &&

needs an additional comparison with the serial # "42082910" (for jmberg).
Perhaps this should be implemented in a flexible way to have a list of serial numbers, just in case there are other users with the same problem.

[jmberg]

They just told me this morning they fixed firmware versions 1.2 and 1.3, I asked again if there's a way to get the firmware version from the serial number.

[jmberg]

Got a very quick response: with firmware version 1.2 and 1.3, the serial number starts with a 6: "1 DZG 00 6.."

That's clearly when expressed in decimal, @dbeyer's had a serial number encoded as "0a 01 44 5a 47 00 03 9e 20 53".

So this would put the cut-off at "0a 01 44 5a 47 00 03 93 87 00", i.e. we can just add

if (... && (memcmp(serial, "\x0a\x01\x44\x5a\x47\x00\x03\x93\x87\x00", 10) < 0))