When you see a line starting with [4, ...] in OCPP logs, you know that a message could not be processed by the other side. This message type is called CALLERROR. A CALLERROR is different from a business rejection (such as an invalid card); it indicates a technical problem with the message itself or with processing it. This article covers the standard error codes and where to look first for each one.

The structure of a CALLERROR

A CALLERROR is a five-element array: message type (4), the MessageId of the request, the error code, a short description and a details object. Example:

[4, "a1b2c3", "PropertyConstraintViolation", "connectorId out of range", {}]

The error code comes from a fixed list defined in the OCPP specification. The description and details are implementation specific; the description field is usually the most valuable clue for understanding the problem.

Standard error codes

NotImplemented

The requested action is not defined on the other side at all. For example, you may get this reply when you send TriggerMessage to an older charger. Fix: check the profiles the charger supports, or do not use this action for that charger.

NotSupported

The action is recognised but not supported. In practice it is handled much like NotImplemented. For example, a charger that does not support the Smart Charging profile may return this to SetChargingProfile.

InternalError

The other side understood the message but an internal error occurred while processing it. This is usually a software bug. If it repeats, report it to the charger manufacturer or software vendor with a log sample.

ProtocolError

The message does not follow OCPP rules; for example, the payload is missing or the array structure is broken. Inspect the raw JSON; it is often a simple issue such as a missing field or an extra comma.

SecurityError

The action was refused for security reasons. It can appear, for example, when the charger receives a request it is not authorised to perform, or when a message is sent before authentication is complete.

FormationViolation

The payload is syntactically wrong; the JSON cannot be parsed or does not match the expected structure. If you are writing your own integration, check how the JSON is produced.

PropertyConstraintViolation

A field value breaks the rules; for example, a connector number that does not exist or a status value that is not in the allowed list.

OccurrenceConstraintViolation

A required field is missing, or a field is used more times than allowed.

TypeConstraintViolation

The field type is wrong; for example, a string was sent where a number was expected ("connectorId": "1" instead of "connectorId": 1).

GenericError

A general error that does not fit the other codes. Reading the description field is essential.

OCPP 2.0.1 and 2.1 add a few more codes, such as MessageTypeNotSupported and RpcFrameworkError, and some names are spelled slightly differently (for example FormatViolation). The logic is the same.

CALLERROR vs business rejection

This distinction is the most frequently confused topic in the field. When an RFID card is not recognised, the CSMS does not send a CALLERROR; it returns "idTagInfo": {"status": "Invalid"} inside a CALLRESULT. If a remote start request cannot be carried out because the charger is busy, the reply is "status": "Rejected". In other words:

  • CALLERROR: "I could not process your message."
  • CALLRESULT + Rejected/Invalid: "I understood your message but I am not accepting your request."

Knowing this lets you tell immediately whether the problem is a technical mismatch or a business rule.

Common scenarios

  • A new charger is connected and some commands return NotImplemented: The charger does not support some optional profiles. Disabling these commands for that model in the dashboard is the cleanest fix.
  • FormationViolation errors started after a firmware update: The manufacturer may have started sending a field in a different format. Compare logs from before and after the update.
  • PropertyConstraintViolation on a specific connector: The number of connectors defined in the dashboard may not match the number reported by the charger.

Connector status errors (such as Faulted and errorCode values) are covered separately in our OCPP error codes guide. For the general structure of the message envelope, see OCPP message structure.

Tips for fast diagnosis

Store every CALLERROR together with its CALL message. Keeping statistics by error code, action name and charger model shows which problem is concentrated in which model. Üreticy's OCPP software keeps all OCPP traffic in searchable logs; you can quickly filter only the errors for a connector or a charger.

Conclusion

A CALLERROR signals a technical problem in OCPP communication. Reading the error code together with its description quickly reveals whether the issue lies in the message format, in an unsupported action or in an internal error on the other side.