GetTransactionStatusRequest for v201

[Pietfried]

No description provided.

[maaikez]

Tested with this pull request (test cases E_28 - E_34). All test cases 'with message in queue' fail because:

• After the CS is online again, a get transaction status request is sent by the csms
• The CS will immediately send its queued transaction messages
• After sending the transaction messages, it sends the get transaction status response stating there are no messages in queue (which is correct because they are just sent)
• So something with the order here. Test case E_31 once failed for another reason, at least at my desk:
  [13:50:02:477] [msg-in] [4,"02dec3dc-0b7b-40dd-92c0-f1b4957e1bbb","SecurityError","",{}]
  After running it again, it had the same issue as the other test, so the security error was only once.

Added the logs of two failing test cases.

ATeam-Maaike-2evse_TC_E_31_CS2023-10-26T13_48_16.339158.log
ATeam-Maaike-2evse_TC_E_29_CS2023-10-26T13_45_14.350661.log

[Pietfried]

Tested with this pull request (test cases E_28 - E_34). All test cases 'with message in queue' fail because:

• After the CS is online again, a get transaction status request is sent by the csms
• The CS will immediately send its queued transaction messages
• After sending the transaction messages, it sends the get transaction status response stating there are no messages in queue (which is correct because they are just sent)
• So something with the order here. Test case E_31 once failed for another reason, at least at my desk:
  [13:50:02:477] [msg-in] [4,"02dec3dc-0b7b-40dd-92c0-f1b4957e1bbb","SecurityError","",{}]
  After running it again, it had the same issue as the other test, so the security error was only once.

Added the logs of two failing test cases.

ATeam-Maaike-2evse_TC_E_31_CS2023-10-26T13_48_16.339158.log ATeam-Maaike-2evse_TC_E_29_CS2023-10-26T13_45_14.350661.log

We are aware of this, @hikinggrass is currently working on that. We need to add a lock to respond to CALL messages first before we initiate own CALL(s)

[hikinggrass]

Tested with this pull request (test cases E_28 - E_34). All test cases 'with message in queue' fail because:

• After the CS is online again, a get transaction status request is sent by the csms
• The CS will immediately send its queued transaction messages
• After sending the transaction messages, it sends the get transaction status response stating there are no messages in queue (which is correct because they are just sent)
• So something with the order here. Test case E_31 once failed for another reason, at least at my desk:
  [13:50:02:477] [msg-in] [4,"02dec3dc-0b7b-40dd-92c0-f1b4957e1bbb","SecurityError","",{}]
  After running it again, it had the same issue as the other test, so the security error was only once.

Added the logs of two failing test cases.
ATeam-Maaike-2evse_TC_E_31_CS2023-10-26T13_48_16.339158.log ATeam-Maaike-2evse_TC_E_29_CS2023-10-26T13_45_14.350661.log

We are aware of this, @hikinggrass is currently working on that. We need to add a lock to respond to CALL messages first before we initiate own CALL(s)

#231 should hopefully fix this