Avoid f32 fields for representing quantities like money and meter values

[huntc]

Unfortunately, the interpretation of the JSON schema number type here is f32. This is not correct due to the potential loss of fractional data. This becomes very important with SampledValueType and its value field, which represents a metering value. Inaccurate conveyancing of meter values can lead to incorrect billing calculations.

Section 2.1.3 of the OCPP v2.0.1 spec, Primitive Datatypes, declares the following:

For data being reported by the Charging Station, the full resolution of the source data must be preserved. The decimal sent towards the Charging Station SHALL NOT have more than six decimal places.

I'd suggest replacing most occurences of f32 with Decimal per https://crates.io/crates/fpdec.

I'm happy to raise a PR if there's agreement here.

[huntc]

Also, here is our own, perhaps more constrained fixed-point library: https://github.com/cuprous-au/fixed-point. We use this on an EV charging system we developed for a customer.

[tommymalmqvist]

Hello again @huntc - Great find and I'd gladly take a PR.

About which lib to use, I'm not sure. https://crates.io/crates/rust_decimal Seems to be very used in this space.

I could not find a crate for fixed-point, it is not published yet?

fpdec look promising but it's not used as much as rust_decimal from what I can see in the download section.

[huntc]

Yeah, we’ve not published fixed-point. I like the recommendation you came up with though. I’ll create a PR for us over the weekend. Cheers.

[huntc]

You can now see a PR for this - I applied the PR to my own code base and it required very little change.