Clock aligned metervalues are not really clock aligned. Add configureable alignment of timestamps.

[marcemmers]

Original issue from Zulip chat:

During the working group call last week I already briefly mentioned this issue and some of us have spoken about this before and decided we did not want to go for this option. I would like to have a discussion to see if we need to reconsider.
The issue we are facing regards the clock aligned metervalues, specifically the timestamps we send.

The timestamp we currently use is the time reported by the metervalue data that we receive from everest-core or the equivalant custom software. We are using the actual time of sampling for this. The problem is that we can't really control the time of sampling. Our meters have a 2 second sampling interval and are sampling on their own, we just collect the data. This means that the timestamps will never align perfectly with the clockaligned times required.

The specification is quite vague on this part, I could not find any hard requirements on the timing of these clock aligned values. OCTT however is very strict and requires us to provide data with the timestamps exactly on the dot. We do have a discussion open with them on whether the OCTT is too strict currently but no results there yet.

My suggestion is to correct the timestamps of the clock aligned metervalue messages (both for MeterValueRequest and TransactionEventRequest updated messages) to be exactly on the interval.

One of the arguments against this was that we should not change timestamps because we are then "faking" them. To counter that, the timestamps are probably not exactly correct anyway. The meter might have a slight offset to the real utc time, then there might be communication delays with the meter readout by the software etc.

Decision from the working group on how to proceed:

Faking MeterValue

• Make faking MeterValue and TransactionEvent timestamps a configurable feature

This ticket is meant to implement just that and also fix some other metervalue releated issues.