On a Belgian (Fluvius) smart meter, the P1 telegram reports CurrentL1 with two decimal places instead of a whole number:
1-0:31.7.0 = 012.15*A
Telegram.CurrentL1 (and presumably CurrentL2/CurrentL3) is implemented as:
public UnitValue? CurrentL1 => ParseIntUnit(OBISRegistry.CurrentL1);
Since ParseIntUnit expects an integer, a value like 012.15 doesn't parse and the property silently returns null — no exception, just a missing reading. This is easy to miss, since nothing indicates a parsing failure occurred.
For comparison, VoltageL1/L2/L3 use ParseDecimalUnit and handle this fine, since voltage is defined as a UnitValue.
It looks like at least some Fluvius/Belgian meters report current with decimal precision, deviating from the base (Dutch) DSMR convention of whole-Ampere current readings that ParseIntUnit assumes.
Suggestion: either change CurrentL1/L2/L3 (and CurrentL2/CurrentL3) to use ParseDecimalUnit (matching how Voltage is already handled), or expose them as UnitValue? for consistency — whichever fits the library's design better. Happy to test a fix against real Fluvius telegram data if useful.
Environment: DSMRParser.Net 2.0.0, Belgian Fluvius digital meter (P1 companion standard).
On a Belgian (Fluvius) smart meter, the P1 telegram reports CurrentL1 with two decimal places instead of a whole number:
1-0:31.7.0 = 012.15*A
Telegram.CurrentL1 (and presumably CurrentL2/CurrentL3) is implemented as:
public UnitValue? CurrentL1 => ParseIntUnit(OBISRegistry.CurrentL1);
Since ParseIntUnit expects an integer, a value like 012.15 doesn't parse and the property silently returns null — no exception, just a missing reading. This is easy to miss, since nothing indicates a parsing failure occurred.
For comparison, VoltageL1/L2/L3 use ParseDecimalUnit and handle this fine, since voltage is defined as a UnitValue.
It looks like at least some Fluvius/Belgian meters report current with decimal precision, deviating from the base (Dutch) DSMR convention of whole-Ampere current readings that ParseIntUnit assumes.
Suggestion: either change CurrentL1/L2/L3 (and CurrentL2/CurrentL3) to use ParseDecimalUnit (matching how Voltage is already handled), or expose them as UnitValue? for consistency — whichever fits the library's design better. Happy to test a fix against real Fluvius telegram data if useful.
Environment: DSMRParser.Net 2.0.0, Belgian Fluvius digital meter (P1 companion standard).