Vzlogger struggles when Meter shifts from 3 byte to 2 byte in SML #533
Comments
|
without having looked at the code, i wonder if this is a vzlogger or a libsml bug. |
|
Done. I am no Github expert, hope everything was uploaded correctly. I processed the dumps with sml_server and the same effect occurs. Everything fine when 3 bytes are sent, wrong interpretation with 2 bytes. |
|
@fhwe71: |
|
are these the expected values or wrong ones? |
|
Thanks for asking. I expect it's a libsml problem then. Currently I only can tell what I reported above was what I measured and it was incorrect. I will do a check with libsml in January, currently my data and equipment are not available. |
|
Have you guys seen this? volkszaehler/libsml#132 |
In volkszaehler#132 and volkszaehler/vzlogger#533 it was reported that there are DZG meters that fall into the range currently deemed broken (all DZG meters with serial numbers before 6000 0000), but aren't actually broken. The reason for this seemed to be that they're a different type than mine that was broken. Further inquiry with DZG revealed that indeed only DVS74 meters are affected by the encoding issue, and then _those_ only for serial numbers before 6000 0000. They also said that (currently) the serial number ranges - 4200 0000 to 4899 9999, and - 5500 0000 to 5899 9999 are reserved for DVS74 meters. As such, make the workaround detection more specific, and we no longer need to have the check for 6000 0000 either, just need to have a list of affected ranges. To achieve that, refactor the code into a separate function that actually decodes the serial number to an integer, so we can make the comparison more easily and have the list of affected numbers more clearly in the code. This should fix volkszaehler#132 since the serial number there starts with 4005, so it's clearly not in the affected ranges, as explained by my contact at DZG. For volkszaehler/vzlogger#533 I don't have the serial number, but it's the same type of meter as in volkszaehler#132.
In volkszaehler#132 and volkszaehler/vzlogger#533 it was reported that there are DZG meters that fall into the range currently deemed broken (all DZG meters with serial numbers before 6000 0000), but aren't actually broken. The reason for this seemed to be that they're a different type than mine that was broken. Further inquiry with DZG revealed that indeed only DVS74 meters are affected by the encoding issue, and then _those_ only for serial numbers before 6000 0000. They also said that (currently) the serial number ranges - 4200 0000 to 4899 9999, and - 5500 0000 to 5899 9999 are reserved for DVS74 meters. As such, make the workaround detection more specific, and we no longer need to have the check for 6000 0000 either, just need to have a list of affected ranges. To achieve that, refactor the code into a separate function that actually decodes the serial number to an integer, so we can make the comparison more easily and have the list of affected numbers more clearly in the code. This should fix volkszaehler#132 since the serial number there starts with 4005, so it's clearly not in the affected ranges, as explained by my contact at DZG. For volkszaehler/vzlogger#533 I don't have the serial number, but it's the same type of meter as in volkszaehler#132.
In volkszaehler#132 and volkszaehler/vzlogger#533 it was reported that there are DZG meters that fall into the range currently deemed broken (all DZG meters with serial numbers before 6000 0000), but aren't actually broken. The reason for this seemed to be that they're a different type than mine that was broken. Further inquiry with DZG revealed that indeed only DVS74 meters are affected by the encoding issue, and then _those_ only for serial numbers before 6000 0000. They also said that (currently) the serial number ranges - 4200 0000 to 4899 9999, and - 5500 0000 to 5899 9999 are reserved for DVS74 meters. As such, make the workaround detection more specific, and we no longer need to have the check for 6000 0000 either, just need to have a list of affected ranges. To achieve that, refactor the code into a separate function that actually decodes the serial number to an integer, so we can make the comparison more easily and have the list of affected numbers more clearly in the code. This should fix volkszaehler#132 since the serial number there starts with 4005, so it's clearly not in the affected ranges, as explained by my contact at DZG. For volkszaehler/vzlogger#533 I don't have the serial number, but it's the same type of meter as in volkszaehler#132.
In #132 and volkszaehler/vzlogger#533 it was reported that there are DZG meters that fall into the range currently deemed broken (all DZG meters with serial numbers before 6000 0000), but aren't actually broken. The reason for this seemed to be that they're a different type than mine that was broken. Further inquiry with DZG revealed that indeed only DVS74 meters are affected by the encoding issue, and then _those_ only for serial numbers before 6000 0000. They also said that (currently) the serial number ranges - 4200 0000 to 4899 9999, and - 5500 0000 to 5899 9999 are reserved for DVS74 meters. As such, make the workaround detection more specific, and we no longer need to have the check for 6000 0000 either, just need to have a list of affected ranges. To achieve that, refactor the code into a separate function that actually decodes the serial number to an integer, so we can make the comparison more easily and have the list of affected numbers more clearly in the code. This should fix #132 since the serial number there starts with 4005, so it's clearly not in the affected ranges, as explained by my contact at DZG. For volkszaehler/vzlogger#533 I don't have the serial number, but it's the same type of meter as in #132.
I have a DZG meter DWSB20.2TH to measure my power consumption and photovoltaic delivery.
Normally the meter sends 3 bytes with a factor 10^-2, e.g. 54 fe 9a 84 -> (ff ff ff - fe 9a 84 + 1)*0,01 = -915,15 Watt consumption, thus 915,15 Watt are fed into the grid.
When the power consumption goes towards zero, the meter shifts to 2 bytes.
Example 53 80 f7 -> ( ffff-80 f7+1)*0,01 = -325,21 Watt consumption, 325,21W are delivered.
Nevertheless vzlogger assumes it's still 3 byte, and as the value is smaller than 7fffff, it calculates (0x80f7)*0,01 = 330,15 Watt consumption - which is a difference of more than 650 Watt!
This happens in the morning and evening when consumption is around zero. In the night, when it's really less than zero or during day delivery is high, 3 bytes are sent and everything is fine. Photos you can find here: https://www.photovoltaikforum.com/thread/177445-fehler-smart-meter-oder-wechselrichterproblem/?postID=2688274#post2690322
I wonder whether this is specific to DZG meters or happens with all meters. Nevertheless vzlogger is quite useless for me like that.
Can this be corrected?
The text was updated successfully, but these errors were encountered: