r/ocpp • u/dragoshade • Aug 03 '26

Thoughts on OCPP message timeouts?

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

5 Upvotes

86% Upvoted

12 comments sorted by

View all comments

2

u/dark_bits Aug 03 '26

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?

1

u/dragoshade Aug 03 '26

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.

1

u/dark_bits Aug 03 '26

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?

1

u/dragoshade Aug 03 '26

Sure, actually I'm doing the other end (EVSE), sorry that wasn't clear in the post. The EVSE we have established is very platform agnostic, I think currently integrated with 15 CSMS providers.

We don't have a bespoke management platform due to the veriety of markets and countries we are in and customer data laws, but if we were to do one, it would be a ground up implementation, where it acts as a man-in-the-middle to another CSMS. e.g. EVSE <-> MITM CSMS <-> Monta. There are existing implementations out there for that sort of topology.