Enforce validation and suspect flagging rules for StartTransaction events

[juherr]

1. Duplicate start on an already started session

If a StartTransaction is received for a transaction that is already started (i.e., an active session already exists with a recorded start):

• The event must be marked as suspect.
• It should not overwrite or alter the existing transaction state.

2. Start on a connector with an active or previous transaction conflict

If a StartTransaction is received while:

• another transaction is currently active on the same connector, or
• a previous transaction lifecycle on that connector is not yet properly closed or reconciled,

the event must be marked as suspect.

This prevents overlapping or inconsistent transaction lifecycles on the same port.

3. Temporal regression at station level

If a StartTransaction.timestamp is earlier than the last StartTransaction.timestamp received from the same station:

• The event must be marked as suspect.

This detects clock drift, replayed messages, or out-of-order delivery at station level.

4. Start timestamp in the future

If a StartTransaction.timestamp is significantly in the future (beyond a configurable tolerance window):

• The event must be marked as suspect.

This protects against incorrect station clocks and replay or manipulation scenarios.

5. Meter regression compared to last stop

If meterStart is smaller than the meterStop of the last completed transaction on the same connector:

• The event must be marked as suspect.

This detects meter rollback, counter reset, or data corruption scenarios that would break billing continuity.

Related to #1296 and #1962

[goekay]

#1977 addresses "4. Start timestamp in the future" already

[goekay]

we should treat these suggestions/rules with real care, because see #1991 and #1992

[juherr]

@goekay This is indeed sensible behavior, as observed in #1991 and #1992, but I don't think those are directly related to this issue.

I would strongly expect chargers to consistently respect these rules, including older ones. Otherwise, it becomes challenging to rely on them, especially when financial aspects are involved.

[goekay]

but I don't think those are directly related to this issue.

they are not directly and literally related, but indirectly related: whatever we derive from the spec/theory as sensible rules of strictness might fail to consider some aspects. the rules might be correct in the problem/solution subspace they consider (i.e. one part of the picture) but they still might be incomplete (i.e. not covering the whole picture). here, i am referring to the notions of correctness and completeness from computer science.

lets look at the recent monotonicity topic as an example. i realize the following: expectation of monotonicity was perfectly fine from a textbook perspective. it makes sense, right? but it was too simple and broad of a rule. it was painting with a broad brush. it was missing nuance and complexity/heterogeneity of real-world. now, if you ask me, the example message from the station is not faulty. the structure makes sense from station's perspective. it just decided to order in a different way. but it is not wrong. the spec does not dictate a behavior. so, the rule of monotonicity was correct in the narrow sense but not complete, if you ask me.

what if the rules from above fall into the same trap? this is my concern and point.

[juherr]

@goekay I agree that the message from the station is not faulty per se, but I would still consider it somewhat ambiguous from a CSMS perspective.

When it comes to billing, we ultimately rely on StartTransaction, StopTransaction, and MeterValues to reconstruct the session, right?

In that context, how do you see price calculation working if timestamps are not consistent or become hard to interpret? For example, when values that seem related are not temporally aligned, it becomes unclear how to safely aggregate or compare them.

Do you see this as something that should be handled at the billing layer (i.e. making sense of imperfect OCPP data), or would you expect some level of consistency to be enforced earlier in the pipeline?

I’d be interested to hear how you approach this trade-off between flexibility and data reliability.

[goekay]

emphasis of my stance from earlier:

we should treat these suggestions/rules with real care ...

dont get me wrong. i am not against doing validation. i am just saying that maybe these rules are a) simple and broad, and might miss nuances, or b) need some relaxation. a steve that is very strict and correct but cannot work with any charger in the field is not a happy steve.

therefore, i encourage anyone wanting to contribute to be critical and careful about the initial framing of rules. i am just worried that some AI-powered contributor will take them literally, at face value, and auto-generate some code/PR as a ticking bomb. these are the times we are living in.

as an example, again in the case of recent monotonicity topic i gave a hint what might be good direction: segregation of measurements into contexts, and expecting monotonicity only within a context. there, immediately, i also hinted at the next hurdle: how to group? etc etc. i think these steps towards a solution are more nuanced, intelligent and to be frank better than "all meter values timestamps should be monotonic".

PS: this comment was created without any AI help. it is the product of my thinking and writing ;)

[juherr]

@goekay I think we actually agree on the fundamentals, with maybe a difference in emphasis.

My intention is not to enforce strict rules that would reject valid real-world data, but rather to make validation more flexible and observable.

What I have in mind is:

• making rules configurable (potentially per charger model or even firmware version),
• and most importantly, only flagging inconsistencies instead of rejecting them.

This way, we can:

• remain compatible with real-world charger behavior,
• while still being able to audit and understand data quality issues,
• especially in contexts where correctness matters (e.g. billing).

In that context, false positives are acceptable as long as they remain visible and explainable.

To me, this strikes a balance between robustness and reliability: we don’t break on imperfect data, but we also don’t ignore potential inconsistencies.

Also, I fully agree with your point about being careful with how rules are framed. Given how easily things can be taken literally (especially with AI-assisted contributions), I think we need to be explicit about intent, scope, and limitations. I’ll update this issue and the related ones accordingly.

Curious to hear if this approach aligns better with your concerns.

PS: this comment was created without any AI help. it is the product of my thinking and writing ;)

I’m personally very comfortable using AI to help with wording and clarity — not everyone has the same level of fluency in English, and I see it as a tool to improve communication rather than replace thinking.