[Question] Why does transaction details show only the first meter value?

[ByungJun25]

Checklist

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

Describe the problem you are trying to solve

Hi, Steve team!

first, I don't know about OCPP spec enough, so it is possible to ask with wrong question..
This question is similar with this issue.
I need to show real time power of connector.

I just noticed now, the transaction detail page shows only the first meter value.

steve/src/main/java/de/rwth/idsg/steve/repository/TransactionRepository.java

Line 42 in 55c7212

return getDetails(transactionPk, true);

And according to comments of codes, it said that the meter value is not changeable, so your team showed only one data.

steve/src/main/java/de/rwth/idsg/steve/repository/impl/TransactionRepositoryImpl.java

Lines 179 to 185 in 55c7212

	// -------------------------------------------------------------------------
	// Step 3: Charging station might send meter vales at fixed intervals (e.g.
	// every 15 min) regardless of the fact that connector's meter value did not
	// change (e.g. vehicle is fully charged, but cable is still connected). This
	// yields multiple entries in db with the same value but different timestamp.
	// We are only interested in the first (or last) arriving entry.
	// -------------------------------------------------------------------------

But it used last meter value for stopping transaction.

steve/src/main/java/de/rwth/idsg/steve/service/TransactionStopService.java

Lines 59 to 61 in 55c7212

	public void stop(Integer transactionPk) {
	TransactionDetails thisTxDetails = transactionRepository.getDetails(transactionPk, false);
	Transaction thisTx = thisTxDetails.getTransaction();

Well, I wonder why it shows only first meter value on transaction detail page and how I can get the real-time power correctly.
Thank you.

[juherr]

Hi @ByungJun25

As I understand the comments, they explain that only the first meter is displayed when the meter value doesn't change.

Could you explain why you think it is a problem for real-time power?

[ByungJun25]

Hi @juherr

Thank you for your answer.

Of course, the power value is not problem because it is same with before. But the problem the other values like timestamp will be shown with old data. Because of this, 3th party app(Or the manager) is not sure about this data is latest data or not.

Here are the screenshots, what I tested.

[goekay]

i think the behaviour and its justification is well documented. it is even an internal boolean flag firstArrivingMeterValueIfMultiple which you can change if this behaviour does not fit you. i don't think it is necessary to externalise this flag though since it's too much implementation detail.

having said that, i cannot follow your argument. in your screenshot from db table (i assume it is from the db table), 1st and 3rd, 2nd and 4th rows contain the exact same business content with the only difference being the the timestamp. it is the same meter value, reported multiple times. and steve here makes a decision that probably you are interested in the first arriving one and not the later redundant copies. if you don't like this, you can change the flag.

[juherr]

Because of this, 3th party app(Or the manager) is not sure about this data is latest data or not.

It is the latest data and I don't understand what you are looking for.

In your example, the transaction is not stopped and you can understand the data is true until you receive the end of the transaction with the last values.
If you want a more precise information, you can get the last time the station was online.

[ByungJun25]

Thank you so much for the detailed description! @goekay and @juherr :)
I see what you mean. 👍

First of all, let me reiterate that I am not familiar with the OCPP spec, and to avoid misunderstanding this question, I will explain my situation in more detail.

The important part for me is whether this feature is defined in the OCPP protocol document or not.
But from what I understand so far, it is steve team's decision to show only the first value of duplicated values and not the protocol specification. Is that right?
If this feature (showing only the first value) is just a decision by steve team then I am totally fine with it. Because it means I can totally customize it for what I want.

When I read the OCPP1.6 protocol document up to now, I read that the charge point decides to send MeterValue data entirely and it can be sent multiple times.
Therefore I thought I could make a simple visualization of the data that the charge point sends even though there are duplicate data.
(As explained in the documentation, the meterValue must send a timestamp unconditionally, so I thought there would be no problem as long as this value was not duplicated.)

But because the central system of steve shows only the first value when there are duplicate values, the first time I was so confused because even though I was getting the data periodically from the charge point, it seemed that it did not send data anymore.

Of course, if I don't want to show all the data coming in at regular intervals, this feature is perfect. No problem at all. xD
But unfortunately, I should show all data even though it is duplicated. ;D (Or if this is defined by the document, then I can excuse why I cannot show all.)

Thanks again for the help. 👍

[goekay]

ocpp is the communication interface between backend and stations. it does not dictate how to render or present the data once it arrived at backend. this is not an ocpp thing. it is a convenience thing by steve.

imagine a vehicle being connected to the station for 2 days even though the charging itself is completed after 2 hours. for the rest of the time, 46 hours, the station sends meter values every 15 mins, because it is not implemented in a way to apply further intelligence checks. you will see on your transaction details page 46 x 4 = 184 other redundant entries that are cluttering your overview. this logic was introduced by me because i had this real-life issue.

[juherr]

In fact, you don't describe your use-case and it won't be easy to propose solutions.

Ocpp is an event based protocol and steve stores and displays them in the way it want with respect of the spec workflow.

For ui/ux, it decided to show only the first event when data don't change.
For end-user, I don't see any good reason to display all events as the values don't change.
And the station connectivity can be checked from another way.

If you want to debug the ocpp implementation of the station, I'm not sure steve will be the best tool for you.

@goekay As all events are stored, why not having an extra param for the details view that allows to display all events? I didn't check but the question is relevant for the api too.

[juherr]

I made pull-request that enable the display of all events via a query param.

[goekay]

As all events are stored, why not having an extra param for the details view that allows to display all events?

sure, we can do that. but it is a little more involved than the open PR.

I didn't check but the question is relevant for the api too.

it is not relevant for the current api, because we do not provide details of a transaction. just the basics you see on transactions page.

[fnkbsi]

In addition to the question of this issue, I would annotate that fluctuating values will suppressed on the output of the Webpage.
Here my attempt to describe the behavior.
The amount of measurand data displayed on the "/transactions/details/n" page is (and should be) reduced compared to the measurands stored in the database.
However, the implemented SQL query suppresses fluctuating values.
This applies, for example, to an active profile in which the current is reduced for a certain period of time.
Example:
Database: 16A 16A 10A 10A 16A 16A
Webpage: 16A 10A
The reason of suppressing the current rising again in the displayed data can be found in the SQL query.
By grouping the measured values and then selecting by the minimum timestamp (min(valuetimestamp)) in the SQL query, only the first occurrence of a value is displayed on the page (in the example 16A and 10A).

[goekay]

i would argue that after #1209 this issue is no more relevant, since its underlying confusion should be gone.