"This replaces the generic StatusNotification and the sometimes cryptic vendorErrorCodes from OCPP 1.6 with precise, actionable information." — I would say this is not as good as suggested.
Indeed, with OCPP 2.0.1, you now know which specific component is faulted (has a problem), which is a step forward. However, a single component can still have many different types of problems.
In practice, the StatusNotification.vendorErrorCode from OCPP 1.6 has simply moved to NotifyEventRequest.eventData.techCode in OCPP 2.0.1. Consequently, the actual content remains the same: vendor-specific error codes.
You're right, thanks for pointing this out Karol. The vendor error code is still important context for resolving the issue. At least you have better overall visibility on what's happening on your charger, plus the ability to set monitors for preventive maintenance. And until we arrive at real Unified Error Codes (I know that's a topic close to your heart, see https://github.com/unified-error-codes/uec-stack), we'll still be stuck with interpreting vendor-specific error codes for the foreseeable future.
It is also worth noting that the CharIn Working Group is actively addressing the standardization of error codes. Significantly, this effort has recently transitioned to a public forum on github to allow for broader industry contribution: https://github.com/charinev/unified-error-codes.
I anticipate that this work will influence the OCPP Device Model. Specifically, it may need to define new components—not currently included in the OCPP standard components—against which these specific error codes can be raised. We will see how this evolves as the group progresses.
Thanks for the feedback, and glad my article made this concept more clear for you. The OCPP specification does not provide any guidance on operational best-practices regarding your specific scenario. That's left to each charge point operator. Ideally, a CPO comes up with automatic detection and degradation mitigation workflows instead of involving a human every time a degradation occurs. That's the difference between operations at scale and being scaled by the network size.
Great article, Mark. I could not have described the OCPP device model any better.
-Franc
Thanks for this great feedback, Franc. Means a lot from the author of the Device Model itself!
Exceptional article. Thanks for this lesson.
"This replaces the generic StatusNotification and the sometimes cryptic vendorErrorCodes from OCPP 1.6 with precise, actionable information." — I would say this is not as good as suggested.
Indeed, with OCPP 2.0.1, you now know which specific component is faulted (has a problem), which is a step forward. However, a single component can still have many different types of problems.
In practice, the StatusNotification.vendorErrorCode from OCPP 1.6 has simply moved to NotifyEventRequest.eventData.techCode in OCPP 2.0.1. Consequently, the actual content remains the same: vendor-specific error codes.
You're right, thanks for pointing this out Karol. The vendor error code is still important context for resolving the issue. At least you have better overall visibility on what's happening on your charger, plus the ability to set monitors for preventive maintenance. And until we arrive at real Unified Error Codes (I know that's a topic close to your heart, see https://github.com/unified-error-codes/uec-stack), we'll still be stuck with interpreting vendor-specific error codes for the foreseeable future.
It is also worth noting that the CharIn Working Group is actively addressing the standardization of error codes. Significantly, this effort has recently transitioned to a public forum on github to allow for broader industry contribution: https://github.com/charinev/unified-error-codes.
I anticipate that this work will influence the OCPP Device Model. Specifically, it may need to define new components—not currently included in the OCPP standard components—against which these specific error codes can be raised. We will see how this evolves as the group progresses.
Thanks for the feedback, and glad my article made this concept more clear for you. The OCPP specification does not provide any guidance on operational best-practices regarding your specific scenario. That's left to each charge point operator. Ideally, a CPO comes up with automatic detection and degradation mitigation workflows instead of involving a human every time a degradation occurs. That's the difference between operations at scale and being scaled by the network size.