Adding calculated Consumption for Transactions Table

[maslo90]

Checklist

• [X ] I checked other issues already and found no answer
• [X ] I checked the documentation and found no answer
• [X ] I am running the latest version and the feature i am requesting is not implemented there

Describe the problem you are trying to solve

In the Transactions-Overview we have a starting and an end value for charging.
Its a little bit of annoying to count the consumption manually but an easy fix would be to calculate the consumption next to the start-value and end-value just by substracting the startvalue from the endvalue.

the transactionspage needs an overhaul and restructuring, because the start and enddate should be next to each other and the startvalue and endvalue + consumption too, for better comparison, we might also would want to add the username instead of just the ocppTagId to the table.

• Transaction ID
• Wallbox ID
• Connector ID
• Tag ID
• Username
• Started
• Ended
• Start Value
• End Value
• Consumption (W)
• Stop Reason

...

Describe the solution you'd like

In my transactions.jsp i have added the following line:

${ta.stopValue - ta.startValue} and added a table header with "consumption (w)" it might not be reliable (i dont know yet) but it works for me currently and i have a total consumption in watts in the transactionstable maybe there is a better way to solve this issue.

...

...

Additional context

i would also like to add the username to the table next to the ocppTagId instead of just the ocppTagId.
added a screenshot how it looks in my deployment
...

[goekay]

i could swear there was a work-in-progress PR by a contributor who was trying to do this, but i could not find it right now.

basically, he did some initial work but there were some edge cases which i pointed out, but he did not continue. so PR died i guess.

[nikhilkandari77]

Calculating energy using only the start and stop events works in most cases, but it may fail in scenarios like dual-gun charging mode or when a stop event is missed. For accurate energy calculation, we should consider the sequence: start event → periodic meter values → stop event. This can be reliably handled using a cron job and a transactionId queue.

[goekay]

@nikhilkandari77 can you please elaborate? how does dual-gun charging affect OCPP semantics?

... when a stop event is missed.

in this case, the transaction will never stop. period. it is the responsibility of the charger to send the stop event no matter what at the end of the charging session, no? otherwise, whatever we might infer from the "last meter values event" would be error-prone. what if we miss the final last meter values event as well? as in: what we observed as last meter values event is not the last one.

[nikhilkandari77]

How I Handle Missed Stop Events ->

If, for some reason, a stop event is not received from the charge point, the only fallback is to use the latest MeterValues packet. To handle this in a robust way:

I maintain a transaction ID queue where every incoming meter value packet updates the corresponding transaction.

A background cron job periodically checks this queue to determine whether transactions have become stale (i.e., no new meter values for a defined timeout).

Such transactions are marked as "stop event not received" in reports, ensuring transparency that they were closed by inference rather than by a proper OCPP stop event.

This way, the backend can gracefully handle abnormal sessions while still being compliant with OCPP semantics.

Dual-Gun Charging Specifics ->

Dual-gun chargers add complexity:

Some implementations use one transaction ID across both connectors (shared session).

Others use independent transaction IDs per connector (the clean OCPP-compliant approach).

If there is one shared transaction ID:

The backend cannot close the session until both connectors stop sending meter values.

Otherwise, one active gun could be prematurely cut off.

Therefore, the only safe option is again to rely on the latest meter value packets, combined with inactivity timeouts, before marking the transaction as closed.

[juherr]

That’s a common issue when dealing with “bad” chargers.

The request makes sense, and a solid CSMS UI should offer the option to manually close transactions that have been left open for a long time (though I’m not convinced automating this would be wise).

That said, I don’t think it’s a top priority for Steve to implement right now, and since the code is open, anyone is free to tweak it or propose improvements. 😉

[goekay]

The request makes sense, and a solid CSMS UI should offer the option to manually close transactions that have been left open for a long time ...

steve has this already:

and it functions similar to what was described: find the last meter value of that transaction and use its value as stop value, OR (and this is the more interesting addition IMO): find the next subsequent transaction on that charger and connecter and use start value of this N+1 as the stop value of N transaction.

[goekay]

and i want to emphasize something: the recent discussion is not the topic of this issue IMO. i see the following topics as 2 distinct areas:

1. deciding the stop value of a transaction: the value from StopTransaction or heuristics/workarounds (discussed above)
2. rendering the consumption (if stop value is there): this ticket

obviously, 1 is the prerequisite for 2. 2 will not happen, if 1 is not there.

[juherr]

@goekay Oops, sorry, I hadn’t noticed that before. It looks like Steve already has a solid UI. 😉