Error with transaction ID

[putongyong]

Hi everyone,

I found this library very useful and I started to apply that to create a csms for some chargepoints.

First of all, thanks for your extremely honorable contribution !

Now I encountered an issue. Maybe due to a previous bug in my csms, I got some transaction MeterValues data from one of the chargerpoints in a very strange format.

INFO:ocpp:[IMEI ID of the charger]: receive message [2,"5236","MeterValues",{"connectorId":1,"transactionId":9223372036854775807,"meterValue":[{"timestamp":"2024-03-03T05:19:09Z","sampledValue":[{"value":"5995441.000","context":"Sample.Periodic","measurand":"Energy.Active.Import.Register","location":"Outlet","unit":"Wh"},{"value":"0.000","context":"Sample.Periodic","measurand":"Power.Active.Import","location":"Outlet","unit":"W"},{"value":"0.000","context":"Sample.Periodic","measurand":"Current.Import","location":"Outlet","unit":"A","phase":"L1"},{"value":"0.000","context":"Sample.Periodic","measurand":"Current.Import","location":"Outlet","unit":"A","phase":"L2"},{"value":"0.000","context":"Sample.Periodic","measurand":"Current.Import","location":"Outlet","unit":"A","phase":"L3"},{"value":"232.670","context":"Sample.Periodic","measurand":"Voltage","location":"Outlet","unit":"V","phase":"L1-N"},{"value":"0.000","context":"Sample.Periodic","measurand":"Voltage","location":"Outlet","unit":"V","phase":"L2-N"},{"value":"0.000","context":"Sample.Periodic","measurand":"Voltage","location":"Outlet","unit":"V","phase":"L3-N"}]}]}]

Here the problem is that the transationID is extremely big and is not matching any of my existing transaction data in DB.

The bug in my csms has been fixed, and after uploading all queued data by this chargepoint, this issue stopped for a while. But when I started a new transaction on this chargepoint, the issue came back and became a nightmare.

Do you know what could be the possible reason? If not, do you know how to return a correct call error messsage in this case so that maybe the chargepoint can stop sending the same strange MeterValues?

Thanks again,

Yong

[OrangeTux]

9223372036854775807 looks familiar... It's the maximum value an i64 can represent. That hints that something unusual going on on the charger.

[putongyong]

Yes yes, thank you I knew that is the maximum value too. Do you know with this library, how to return an call error instead of call result? Because in ocpp1.6 documentation, I saw this and thought about it as an solution. But it seems to me that I need to customize the call error message:

3.7.1. Error responses to transaction-related messages

It is permissible for the Charge Point to skip a transaction-related message if and only if the Central System repeatedly reports a `failure to process the message'. Such a stipulation is necessary, because otherwise the requirement to deliver every transaction-related message in chronological order would entail that the ChargePoint cannot deliver any transaction-related messages to the Central System after a software bug causes the Central System not to acknowledge one of the Charge Point’s transaction-related messages.

What kind of response, or failure to respond, constitutes a 'failure to process the message' is defined in the documents OCPP JSON Specification and OCPP SOAP Specification.

The number of times and the interval with which the Charge Point should retry such failed transaction-related messages MAY be configured using the TransactionMessageAttempts and TransactionMessageRetryInterval configuration keys.

When the Charge Point encounters a first failure to deliver a certain transaction-related message, it SHOULD send this message again as long as it keeps resulting in a failure to process the message and it has not yet encountered as many failures to process the message for this message as specified in its TransactionMessageAttempts configuration key. Before every retransmission, it SHOULD wait as many seconds as specified in its TransactionMessageRetryInterval key, multiplied by the number of preceding transmissions of this same message.

As an example, consider a Charge Point that has the value "3" for the TransactionMessageAttempts configuration key and the value "60" for the TransactionMessageRetryInterval configuration key. It sends a StopTransaction message and detects a failure to process the message in the Central System. The Charge Point SHALL wait for 60 seconds, and resend the message. In the case when there is a second failure, the Charge Point SHALL wait for 120 seconds, before resending the message. If this final attempt fails, the Charge Point SHOULD discard the message and continue with the next transaction-related message, if there is any.

[OrangeTux]

You can raise any of the OCPPError in your handler. This is turned into a a CallError response

[putongyong]

Thanks a lot ! So do I need to import anything if I already import Call and CallResult ? Do I need to import OCPPError or CallError ?

[OrangeTux]

Yes, you need to bring the error you'd like to raise in the scope. I guess the PropertyConstraintViolationError fits best in your situation.

from ocpp.exceptions import PropertyConstraintViolationError

[putongyong]

Hi thank you very much, let me try that and come back later!

[jainmohit2001]

Closing this issue for now. If you are facing the same problem, please open a new issue.