How to pass the OCTT tast case 2.4.3. EV Side Disconnected

[shengxiang200788]

Hi matth-x,
In OCTT tast case 2.4.3. EV Side Disconnected, the charger doese not have a fixed cable,
[EV driver unplugs cable on EV side.]
21. The Charge Point sends a StopTransaction.req
23, The Charge Point sends a StatusNotification.req, status is finishing

[EV driver unplugs the cable from the Charge Point.]
25. The Charge Point sends a StatusNotification.req, status is Available

[matth-x]

You can use the OccupiedInput to manually keep the connector in Finishing state:

MicroOcpp/src/MicroOcpp.h

Line 304 in 1bf4942

void setOccupiedInput(std::function<bool()> occupied, unsigned int connectorId = 1); //Input if instead of Available, send StatusNotification Preparing / Finishing

More precisely, this callback puts the connector into an Occupied state, i.e. if the connector is Available, it becomes Preparing and if it's about to end charging (i.e. states Charging/SuspendedEV/-EVSE) it becomes Finishing (or remains Finishing if the state was already Finishing).

I think setting a timer which keeps the connector occupied for one second after unplugging should do the trick.

I'm surprised that this is mandatory. Will make this the default behavior in a future release.

[JungHeum-Park]

Hi.
I'm stuck with same test case.
I add timer acting like @matth-x said.
Now there is no problem about Available state.
My new problem is when server send RemoteStopTransaction, library send Rejected.
To pass the testcase, it should send Accepted.

This is log from octt

[09:49:40:967] [info]  ========================== Starting Main Testcase Steps ==========================
[09:49:40:967] [prompt]  Please make the EV stop charging.
[09:49:45:139] [REQUEST]
[09:49:45:139] [msg-in]  [2,"1000008","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"SuspendedEV","timestamp":"2024-06-21T09:49:44.715Z"}]
[09:49:49:279] [info]  Got 'Continue' on the previous API request, continuing.
[09:49:49:279] [api_dismissed]  1691cdd2-5538-4d1e-ab30-660eb06e1a6c
[09:49:49:279] [prompt]  Please unplug your cable on EV side.
[09:49:52:775] [info]  Got 'Continue' on the previous API request, continuing.
[09:49:52:775] [api_dismissed]  82460c1b-bc98-4037-8974-279005698adc
[09:49:52:775] [info]  Waiting for request message of type StatusNotificationRequest
[09:49:52:775] [info]  Received request message of the expected type.
[09:49:52:775] [RESPONSE]
[09:49:52:775] [msg-out]  [3, "1000008", {}]
[09:49:52:776] [REQUEST]
[09:49:52:776] [msg-out]  [2, "671a784b-508c-4328-adca-3643d58a9ff1", "RemoteStopTransaction", {"transactionId":1718953096}]
[09:49:52:776] [info]  Waiting for response message of type RemoteStopTransactionResponse
[09:49:53:575] [REQUEST]
[09:49:53:575] [msg-in]  [2,"1000009","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"SuspendedEVSE","timestamp":"2024-06-21T09:49:45.135Z"}]
[09:49:53:577] [RESPONSE]
[09:49:53:577] [msg-out]  [3, "1000009", {}]
[09:49:53:577] [info]  Automatically replying to StatusNotification request (will not be picked up by the testcase): status has to do with SuspendedEV(SE).
[09:49:53:596] [RESPONSE]
[09:49:53:596] [msg-in]  [3,"671a784b-508c-4328-adca-3643d58a9ff1",{"status":"Rejected"}]
[09:49:53:598] [info]  Received response message of the expected type.
[09:49:53:598] [info]  RemoteStopTransactionResponse.status should be 'Accepted'
[09:49:53:598] [info]  The value of 'Reset CS after testcase' is false
[09:49:53:698] [verdict]  FAIL
[09:49:53:699] [info]  The test case has ended.
[09:49:53:700] [stopped_testcase]  


Test case result : FAIL

[matth-x]

I'm not sure I understand the scenario (don't have the OCTT descriptions at hand). The reason to reject a RemoteStopTransaction is that the transactionId doesn't match any running transaction on the charger. Do you have an idea what's happened with the transaction 1718953096 at that point? My first guess is that the charger state is not fully reset before the test case and the transaction is from a previous test case with a different txId. Furthermore, the prompt instructs you to unplug the cable which normally leads to an immediate transaction end. My second guess is that the transaction is already terminated, but the test tool doesn't print all incoming messages as they arrive but only as they are processed. Depending on the test scenario, maybe StopTransactionOnEVSideDisconnect should have been set false which didn't succeed for some reason.

[JungHeum-Park]

Oh, I was a different test case. The tese case talk about in this issue is 2.3.3 (I think 2.4.3 is a typo) and mine is 2.3.5.
I'm checking my problem, and if I need to leave an issue in the process, I'll create an new issue then