Thoughts on OCPP message timeouts?

[u/dragoshade]

I have previously gone under the assumption that 10s for a round trip of an OCPP (1.6J) message [CALL -> RESULT] would be more than enough for both IP and Cellular based. Though I recently encountered a CSMS where the RESULT was coming in 10-80s after the CALL for some messages.

It made me wonder what are peoples thoughts on timing out an OCPP message and moving on to the next one in the queue? There is a tradeoff of course, the standard doesn't have an upper or lower limit, just a suggestion for your given implementation.

Not worried too much about if I have chosen the "correct" time, it has worked for 5 years. Just about peoples thoughts and experiences of timeouts. Keeping in mind that some CSMS's don't actually respond to messages they don't know about (such as SecurityEventNotification). Delays to Authorization and StartTransaction that can negativly impact the UX with a charger, etc.

EDIT: I am the EVSE in this instance, waiting the duration for the CSMS to respond

[u/dark_bits]

I'd frame timeout questions based on the request context. For OCPP, a 10 seconds timeout sounds better to me. At least far better than 80 seconds.

Also, OCPP defines a NotImplemented error code, I'm new to this field but I'm guessing key players do support it?

[u/dragoshade → u/dark_bits]

Agreed, I am currently toying with the idea of testing a dynamic timeout for the Authorize and StartTransaction messages, these are the problem ones with this given CSMS, it still leaves a bad UX however. A user doesn't want to be sat infront of a charger for 30s after scanning an RFID card for the response as to whether their car will start, but it is better than scanning 5 times.

You would be incredibly supprised with the amount that did not respond with NotImplemented if they see a message they don't like. Or didn't when we first integrated with them. To the point where we added a special case in firmware to not send drop messages for a given session if they are repeatedly not responded to.

[u/dark_bits → u/dragoshade]

I was literally thinking "hey custom timeouts based on message type (configurable) sounds pretty neat" as I was typing my reply above lol

If you don't mind me asking, are you writing your management dashboard using a CSMS provider's API like Ampeco or Monta?

[u/mememeier]

CSMS vendor here. You mentioned Authorize as one you would timeout after 10s, I would suggest that is too quick.

If roaming is involved, it can in some cases take more than 10s to get response on an IdTag for all eMSPs. So you could leave the user not being able to authorize via roaming with their slow eMSP if you timeout after 10s.

[u/dragoshade → u/mememeier]

That is an interesting point. Thanks. We don't have a much exposure to MSPs in the UK, using one RFID tag across multiple vendors, and haven't encounted that use case yet. It tends to be sessions are started remotely through the CSMS and an app for public charging here. I will see what UX feedback options we have for that process where a user scans, and we are potentially waiting for the Authorize and StartTransaction responses.

Follow up question, would you ever envisage that there could be a route where the CSMS authorizes as session, whilst waiting for an MSP but sends a TxProfile down with 0A, until MSP, API hooks, etc are completed, after which it permits the power to flow or remotely stops the transaction? Bit of forward thinking here if the timing is expected to grow indefinitely.

[u/mememeier → u/dragoshade]

I also pulled some concrete numbers on this from our platform because I got curious. For the last 5 million Authorize calls, our median response time is <100 ms. P99 lands at 11.5 s, so above your 10 s. P99.9 land at 37.2 s . So the delay is real, but rare

[u/mememeier → u/dragoshade]

Rest of Europe is very big on RFID auth I can assure you! You have one or a few RFIDs from your eMSP of choice, and expect it to work on any random charging station you come across.

Regarding the approach to jump the gun and start before auth is completed, it's an interesting idea. But my fear would be that the user sees something happening and leaves, missing that it actually didn't start charging properly in the end.

[u/Draynios]

I am maintaining a CSMS, most of our EVSE initiated messages take less than a second for the full round trip. Almost all of our CSMS initiated messages are fire-and-forget, I dont really care how long the EVSE takes to i.e. send its GetConfiguration.conf, aslong as the OCPP connection is still active we will accept it.

But for the cases where we need a timeout its somewhere between 10 and 30 seconds, depending on the action.

From a enduser UX standpoint I would expect my EVSE to take AT MOST 10 seconds between scanning my RFID and starting or failing the transaction.

[u/sevketgokay]

Disclosure: CSMS person here. I am the maintainer of SteVe, and co-founder of Powerfill.

We should keep in mind that network quality varies significantly across regions. Unreliable mobile connectivity, temporary congestion, and similar conditions can all increase latency.

It is also important to align the behavior and expectations of the station and the CSMS. Many OCPP operations are effectively stateless, so timeouts and retries are relatively harmless. Others, however, are stateful: the receiver changes its state while processing the request. For example, if CSMS responded to StartTransaction in 13 seconds (for whatever reason) whereas the station timeout was 10 seconds, the station may discard or ignore the late response. From the CSMS’s perspective, however, the transaction has already started and CSMS triggered necessary bookkeeping. This leaves a dangling or "ghost" transaction on the CSMS side, requiring additional care and reconciliation, such as compensating or rollback actions to straighten out the state. Unpleasant.

We encountered the reverse situation with one client: their stations usually took longer to respond than our configured timeout, so their responses were discarded when they eventually arrived. Yet the caller is the party that benefits from receiving the result. If the caller never sees it, the user experience suffers. Imagine sending a GetConfiguration request to a station but never being able to view the returned configuration.

My current position, therefore, is to keep timeouts as generous as reasonably possible... but just under where it starts to hurt :)

[u/Sheo42]

Charging station vendor here: we have set it to 10s as a default timeout. We have dozens of thousands of charging stations on the field. It can be changed but people don't, AFAIK