Strange elements in VSF

[ramack]

For the DeltaSolMX there is a "Flow rate sensor 21" in the VSF for offset 104-108, while the packet has only length 104. Also the WMZs 1-4 of the MX have a strange field "Heat quantity" with an offset out of the length.

Is this somehow related to old firmware versions of the MX? And what does it mean?

For the heat quantity a value is returned by pfv.getRawValueDouble(), while for the "Flow rate sensor 21" I read a not so nice null value.

[danielwippermann]

Yes, that most certainly has to do with not-up-to-date firmware versions. But you have obviously encountered two slightly different cases, so let me address them separately:

1) Flow rate sensor 21

The value was introduced in MX firmware version 2.01 and appended at the end of the regular data packet. This also changed the length of the packet from 26 frames (104 bytes of payload) to 27 frames (108 bytes of payload). Older versions of the MX will not transfer a frame payload that big causing the getRawValue...() functions to return null as documented:

/**
 * Get optional raw value from `Packet` payload data as a Long.
 * 
 * @param pfs `PacketFieldSpec` instance of field to get value for.
 * @param buffer Byte array containing `Packet` payload data.
 * @param start Start index into the buffer.
 * @param length Length of the buffer.
 * @return The boxed raw value or `null` if the buffer was too small for a value. 
 */

None of the needed bytes to assemble this value were present in the packet's payload, so you got null back to be able to ignore / skip this value.

2) Heat amount

The heat amount case is a bit different. The Watthours part of the heat amount has been in the HQM packet since day one. But MX firmware version 2.01 added the Gigawatthours part at the end of the packet, extending it from 9 frames (36 bytes) to 10 frames (40 bytes).

If you have an older MX firmware that does not yet transfer the Gigawatthours as part of the HQM packet you will still get the Watthours-only part as a result out of getRawValue...() instead of null. Once you have updated to MX 2.01 or higher the Gigawatthours part will be added to the Watthours to give you a greater range.

[ramack]

Great, thanks. I recognized this behavior while searching for some trouble with the units and wondered what it was. No I figured out, that this was just the "%" sign in the Percent unit, which need to escape before using it in a format string :-) Nevertheless good for met to understand and be aware of these things.

Thanks!