TC_068_CS / Stop transaction logic simplication

[razvanphp]

@matth-x what do you think about this? We found this removed a lot of lines of code from our main loop.

If you like the idea, I can add a test-case for it in unit tests.

Still, this test case fails for some reason I can't understand:

[19:20:35.456] [info]  ========================= Starting Testcase Preparation ==========================
[19:20:35.456] [info]  Entering state Charging
[19:20:35.458] [REQUEST]
[19:20:35.458] [msg-out]  [2, "17e3f195-3870-4cd9-808c-378bc34d687f", "GetConfiguration", {"key":["AuthorizeRemoteTxRequests"]}]
[19:20:35.459] [info]  Waiting for response message of type GetConfigurationResponse
[19:20:35.608] [RESPONSE]
[19:20:35.608] [msg-in]  [3,"17e3f195-3870-4cd9-808c-378bc34d687f",{"configurationKey":[{"key":"AuthorizeRemoteTxRequests","readonly":false,"value":"false"}]}]
[19:20:35.618] [info]  Received response message of the expected type.
[19:20:35.619] [REQUEST]
[19:20:35.619] [msg-out]  [2, "7a1624a0-44d3-4e5b-bc3c-f66d8767f42d", "RemoteStartTransaction", {"connectorId":1,"idTag":"042E3BDA6B6B80"}]
[19:20:35.619] [info]  Waiting for response message of type RemoteStartTransactionResponse
[19:20:35.831] [RESPONSE]
[19:20:35.831] [msg-in]  [3,"7a1624a0-44d3-4e5b-bc3c-f66d8767f42d",{"status":"Accepted"}]
[19:20:35.838] [info]  Received response message of the expected type.
[19:20:35.839] [info]  Waiting for request message of type StatusNotificationRequest
[19:20:35.926] [REQUEST]
[19:20:35.926] [msg-in]  [2,"03f67a97-1281-4f89-0a10-9197812771b8","StartTransaction",{"connectorId":1,"idTag":"042E3BDA6B6B80","meterStart":164,"timestamp":"2025-11-28T19:20:35Z"}]
[19:20:35.947] [RESPONSE]
[19:20:35.947] [msg-out]  [3, "03f67a97-1281-4f89-0a10-9197812771b8", {"idTagInfo":{"status":"Accepted"},"transactionId":1764356684}]
[19:20:35.948] [info]  Received unexpected request message: StartTransactionRequest (Waiting for StatusNotificationRequest; )
[19:20:35.949] [info]  The value of 'Reset CS after testcase' is false
[19:20:35.949] [info]  ============================ Starting Final Cleanup ==============================
[19:20:36.122] [verdict]  INCONC
[19:20:36.122] [info]  The test case has ended.
[19:20:36.123] [stopped_testcase]  

2025-11-28 19:22:40.626
msg-in
[
  2,
  "0d7ce563-5334-aae6-b2e0-f5d44d3c247c",
  "StatusNotification",
  {
    "connectorId": 1,
    "errorCode": "NoError",
    "status": "SuspendedEV",
    "timestamp": "2025-11-28T19:22:39Z"
  }
]
2025-11-28 19:22:40.631
msg-out
[
  3,
  "0d7ce563-5334-aae6-b2e0-f5d44d3c247c",
  {}
]
2025-11-28 19:22:42.246
msg-in
[
  2,
  "0838895f-a165-5e53-5247-8c557306eaa7",
  "StatusNotification",
  {
    "connectorId": 1,
    "errorCode": "NoError",
    "status": "Charging",
    "timestamp": "2025-11-28T19:22:41Z"
  }
]
2025-11-28 19:22:42.250
msg-out

[
  3,
  "0838895f-a165-5e53-5247-8c557306eaa7",
  {}
]

so the charger sends the StatusNotification, but after StartTransactionRequest, isn't this expected?

[razvanphp]

I feel like we should add unit test for those cases, especially if OCTT has them.

[matth-x]

@razvanphp In the ESP-IDF example, authorize() replaces the full begin-or-endTransaction block, but the change in authorize() only takes care of stopping the transaction. What is your idea, to change the authorize() function so that it fully handles NFC swipes, or to simplify the stop Tx path through authorize()?

I'm missing a bit of context here: when is authorize() needed, or when is it more useful than beginTransaction() and endTransaction() which handle all the offline cases as well? Would be great if you can prepare an example.

Generally I like the idea of having a function which handles NFC card swipes and you don't need to implement that begin-or-endTransaction logic yourself anymore. That should probably be a new function like swipeNfcCard() which calls begin or endTransaction depending on the current transaction state.

[PlayXboxtion963]

@razvanphp In the ESP-IDF example, authorize() replaces the full begin-or-endTransaction block, but the change in authorize() only takes care of stopping the transaction. What is your idea, to change the authorize() function so that it fully handles NFC swipes, or to simplify the stop Tx path through authorize()?

I'm missing a bit of context here: when is authorize() needed, or when is it more useful than beginTransaction() and endTransaction() which handle all the offline cases as well? Would be great if you can prepare an example.

Generally I like the idea of having a function which handles NFC card swipes and you don't need to implement that begin-or-endTransaction logic yourself anymore. That should probably be a new function like swipeNfcCard() which calls begin or endTransaction depending on the current transaction state.

Dear matth:

I have meet similar problem with nfc card.For example, your library implements reservation processing, but the example will contradict the library's implementation. For instance, the example does not support the parentID part. if you could give us a new example that is very impressive