Support e-MUCS extension

[jspngh]

Belgian smart meters are also based on the DSMR5 standard, but extend it with the e-MUCS specification.

I'd like to add support in this crate under an emucs feature, but can also maintain a fork with this functionality if it's too intrusive.
Currently there's a lot of #[cfg(feature = "emucs")] clutter, so I was thinking of only using it where there is a conflict (e.g., InstantaneousCurrent).

[Wassasin]

Thank you for this addition! Would be great to also support Belgian smart meters.

Could you add a test-file in the /test folder?

I think using a feature is fine. We could try to make it more Rust-y by using composition instead. What do you think?

[jspngh]

Thank you for this addition! Would be great to also support Belgian smart meters.

Could you add a test-file in the /test folder?

Sure! I've added output from my meter in test/flu.txt

I think using a feature is fine. We could try to make it more Rust-y by using composition instead. What do you think?

Sounds good, what did you have in mind? It's mainly the OBIS parsing that I'd like to clean up, but I don't see a straightforward way to use composition there.

[Wassasin]

Cool, thank you! I'll look at it this weekend, and maybe come up with a way to use composition nicely.

[Wassasin]

I have started looking at it, but before I do any changes wanted to add the unit test. I notice that the CRC16-ARC checksum does not match what is in the file.

Do you get an Error::InvalidChecksum when using your code on data you get from the smart meter? Or did you maybe change the test file slightly?

[Wassasin]

Your text editor probably removed the carriage return \r characters from the file as emitted by your smart meter. I have re-added them locally here and the checksum is now correct.

[jspngh]

Sorry about that! Copy pasting it gave it unix line endings. Should be fixed now.

[Wassasin]

Implemented this in https://github.com/Wassasin/dsmr5/tree/feature/emucs . I am not completely sure about the API. Another small issue of this approach is that #[serde(flatten)] is not supported on no-std.

What do you think?

[jspngh]

Looks good enough to me!

Another small issue of this approach is that #[serde(flatten)] is not supported on no-std.

To potentially use this on the parent field of the State structs?
That would have been nice, but, for me at least, it's not a dealbreaker.

Feel free to add your commits here, you should be able to do that as maintainer.