sml_server does not decode data from device DZMeteringGmbH_WS_7412.1 (negative values)

[chrischris616]

there are negative values for electric power, electric energy counter increases while electrical power is negative. bin and hex files are attached to this issue.
DZMeteringGmbH_WS_74121.zip

[r00t-]

can you be a bit more explicit please?
i.e. specifically describe expected behaviour vs. observed behaviour?

[chrischris616]

The expectation is to get only positive values for actual power in this setup. Unfortunately there are negative values. At the display of the DZ Meter are shown positive values in the same time.

[r00t-]

looking at this,
i am guessing that power should always be positive, while it's jumping between positive and negative erratically?

have you checked if this is maybe a known bug with your meter?
i can't imagine how libsml might be creating this behavior (not saying it's impossible!)

[~/libsml_r00t]$ ./examples/sml_server DZMeteringGmbH_WS_74121_pos_and_neg_values.bin|grep 36\\.7
1-0:36.7.0*255#311.03#W
1-0:36.7.0*255#306.58#W
1-0:36.7.0*255#-324.49#W
1-0:36.7.0*255#-317.22#W
1-0:36.7.0*255#-316.64#W
1-0:36.7.0*255#-320.19#W
1-0:36.7.0*255#320.89#W
1-0:36.7.0*255#307.13#W
1-0:36.7.0*255#299.37#W
1-0:36.7.0*255#314.03#W
1-0:36.7.0*255#302.43#W
1-0:36.7.0*255#302.62#W
1-0:36.7.0*255#-322.19#W
1-0:36.7.0*255#327.03#W
1-0:36.7.0*255#309.94#W
1-0:36.7.0*255#312.24#W
1-0:36.7.0*255#326.59#W

[r00t-]

with some hacking around (extract single messages, combine to to only contain the differing power reading, and disabled crc check),
this is the encoding of the positive vs. negative value(s):

[~/libsml]$ diff <(./examples/sml_server pos) <(./examples/sml_server hacked)
< 1-0:36.7.0*255#311.03#W
> 1-0:36.7.0*255#-324.49#W
[~/libsml]$ diff <(xxd pos) <(xxd hacked)
< 000000c0: fe53 797f 0101 0163 312f 0076 056e 35c5
> 000000c0: fe53 813f 0101 0163 6128 0076 0574 35c5

i'm not fluent in sml and never debugged it at this level,
but we need to find what exactly the differece in the encoding is.

[r00t-]

looks like this is a meter bug that was already reported: #59

[r00t-]

i wonder how this bug relates to the one discussed in #105

[chrischris616]

looking at this, i am guessing that power should always be positive, while it's jumping between positive and negative erratically?

have you checked if this is maybe a known bug with your meter? i can't imagine how libsml might be creating this behavior (not saying it's impossible!)

[~/libsml_r00t]$ ./examples/sml_server DZMeteringGmbH_WS_74121_pos_and_neg_values.bin|grep 36\\.7
1-0:36.7.0*255#311.03#W
1-0:36.7.0*255#306.58#W
1-0:36.7.0*255#-324.49#W
1-0:36.7.0*255#-317.22#W
1-0:36.7.0*255#-316.64#W
1-0:36.7.0*255#-320.19#W
1-0:36.7.0*255#320.89#W
1-0:36.7.0*255#307.13#W
1-0:36.7.0*255#299.37#W
1-0:36.7.0*255#314.03#W
1-0:36.7.0*255#302.43#W
1-0:36.7.0*255#302.62#W
1-0:36.7.0*255#-322.19#W
1-0:36.7.0*255#327.03#W
1-0:36.7.0*255#309.94#W
1-0:36.7.0*255#312.24#W
1-0:36.7.0*255#326.59#W

seems to be an issue with the meter

[chrischris616]

This is a photo of the device.

[r00t-]

i guess it would still be valid to implement a workaround, as intended in #59 ,
but i'm not sure what the best approach here is.

the discussion in #105 might be helpful.
the ideal solution is to exactly identify the affected meters by their serial number,
but that's also rather complex.

i guess for you it would work to just hardcode a fix into your libsml build?

[chrischris616]

i guess it would still be valid to implement a workaround, as intended in #59 , but i'm not sure what the best approach here is.

the discussion in #105 might be helpful. the ideal solution is to exactly identify the affected meters by their serial number, but that's also rather complex.

i guess for you it would work to just hardcode a fix into your libsml build?

yes in #105 the workaround was mentioned:

/*
* Work around DZG meters before serial numbers starting with
* 6 (in decimal) - they encode the consumption wrongly:
* The value uses a scaler of -2, so e.g. 328.05 should be
* encoded as an unsigned int:
* 63 80 25 (0x8025 == 32805 corresponds to 328.05W)
* or as a signed int:
* 64 00 80 25
* but they encode it as
* 53 80 25
* which reads as -32731 corresponding to -327.31W.
*
* Luckily, it doesn't attempt to do any compression on
* negative values, they're always encoded as, e.g.
* 55 ff fe 13 93 (== -126061 -> -1260.61W)
*
* Since we cannot have positive values >= 0x80000000
* (that would be 21474836.48 W, yes, >21MW), we can
* assume that for 1, 2, 3 bytes, if they look signed,
* they really were intended to be unsigned.
*
* Note that this will NOT work if a meter outputs negative
* values compressed as well - but mine doesn't.
/***

[r00t-]

@chrischris616:
so you are positive that the bug being talked about there is the same as this one and #59?
i'm not so sure, because #59 mentions a specific range that is encoded incorrectly.
but if that is the case, then we need to find why the existing workaround does not work for your meter.

[r00t-]

@chrischris616:
so you are positive that the bug being talked about there is the same as thing on and #59?
i'm not so sure, because #59 mentions a specific range that is encoded incorrectly.
but if that is the case, then we need to find why the existing workaround does not work for your meter.

[chrischris616]

@chrischris616:
so you are positive that the bug being talked about there is the same as thing on and #59?
i'm not so sure, because #59 mentions a specific range that is encoded incorrectly.
but if that is the case, then we need to find why the existing workaround does not work for your meter.

yes it seems to be that there is an exact serial number of devices which are affected. my device is affected. the workaround of #105, where the topic was already discussed, unfortunately doesn't work for me.

[chrischris616]

i created a pull request for a fix of the existing workaround with this affected device. chrischris616#1

[jmberg]

Your PR seems to be in the wrong tree or something, it has far too many patches?

Also, now with mine (#136) having been merged, I guess you'll need to rebase that. My meter doesn't have L1, I think, so that's why I didn't notice - but it makes sense to convert both.

IMHO it'd also make sense to refactor the

} else if (workarounds->old_dzg_dvs74 && l->obj_name &&
		   l->obj_name->len == sizeof(dzg_power_name) &&
		   memcmp(l->obj_name->str, dzg_power_name, sizeof(dzg_power_name)) == 0 && l->value &&
		   (value_len_more == 1 || value_len_more == 2 || value_len_more == 3)) {

condition because the "fix the value" code is exactly the same in both cases:

	l->value->type &= ~SML_TYPE_FIELD;
	l->value->type |= SML_TYPE_UNSIGNED;