|
0x7F => labels.push(ValueLabel::NextVIFEAndDataOfThisBlockAreManufacturerSpecific), |
In consume_orthhogonal_vife (m-bus-application-layer/src/value_information.rs), the 0x7F arm ("next VIFE and data are manufacturer-specific") only pushes a label — it doesn't stop the loop. So VIFE bytes after the escape, which are vendor data, keep being matched against the standard table, including the 0x70..=0x77 multiplicative-correction arm. This corrupts decimal_scale_exponent.
Real example — ABB B21 energy record, base VIF 0x04 (energy, ×10¹) followed by VIFEs FF F2 00:
- FF (0x7F) → manufacturer escape (should stop here)
- F2 (0x72) → wrongly hit by 0x70..=0x77 → adds −4 to the exponent
- Result: scale becomes ×10⁻³ instead of ×10¹ — value comes out 10⁴ too small (e.g. 11187940 Wh decodes as 1118.794).
Expected: after 0x7F, remaining VIFEs are manufacturer-specific and must not be interpreted as standard codes.
Fix: break out of the loop when hitting 0x7F (consistent with the existing 0xFC handling above it). libmbus handles this correctly for comparison.
m-bus-parser/crates/m-bus-application-layer/src/value_information.rs
Line 964 in ffc1660
In consume_orthhogonal_vife (m-bus-application-layer/src/value_information.rs), the 0x7F arm ("next VIFE and data are manufacturer-specific") only pushes a label — it doesn't stop the loop. So VIFE bytes after the escape, which are vendor data, keep being matched against the standard table, including the 0x70..=0x77 multiplicative-correction arm. This corrupts decimal_scale_exponent.
Real example — ABB B21 energy record, base VIF 0x04 (energy, ×10¹) followed by VIFEs FF F2 00:
Expected: after 0x7F, remaining VIFEs are manufacturer-specific and must not be interpreted as standard codes.
Fix: break out of the loop when hitting 0x7F (consistent with the existing 0xFC handling above it). libmbus handles this correctly for comparison.