feature: OCPP 2.1 support

[xBlaz3kx]

Proposed changes

OCPP 2.1:

• Added new profiles: DER Control, Battery swapping, V2X
• Reused and updated existing OCPP 2.0.1 profiles (changed according to spec)
• Unit tests
• Handlers and feature registration

OCPPJ:

• Initial support for SEND and CALLERROR_RESULT messages
• Integration tests for newly supported SEND and CALLERROR_RESULT

Misc:

• Docs updates
• Examples

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of
them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before
merging your code.

• I have read the CONTRIBUTING doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

[xBlaz3kx]

Ill need a couple of reviewers to double check my work - if all the fields are mapped, named and validated correctly.
We can add field docs after the fact.

[sderkacs]

Hi xBlaz3kx,

I noticed that the DynUpdateTime field of ocpp2.1 ChargingProfile is of type DateTime from ocpp2.0.1/types.

[xBlaz3kx]

Hi xBlaz3kx,

I noticed that the DynUpdateTime field of ocpp2.1 ChargingProfile is of type DateTime from ocpp2.0.1/types.

Hey,

thanks for pointing it out! Even though this wouldnt be a cricital issue, it is nice to have everything correctly referenced :)
It has been fixed

[sderkacs]

Hi,

thanks for working on this OCPP 2.1 feature — it’s great to see progress on supporting the newer extensions.

I’m currently working on a charging station project that aims to use a large subset of OCPP 2.1 features (including scenarios combined with ISO 15118-2/20). While evaluating this PR and comparing the Go types against the official OCPP 2.1 JSON schemas, I noticed a few discrepancies that will likely need to be addressed for schema compliance.

In particular:

• some types have RequestID field as optional but it is required by the schema (e.g. GetMonitoringReportRequest, GetReportRequest);
• some types defined in the schema appear to be missing in the Go implementation (e.g. NotifyPriorityChargingRequest/Response, GetCertificateChainStatusRequest/Response);
• some fields that are arrays in the schema are currently modeled as single objects (e.g. BatteryData in BatterySwapRequest, TariffAssignments in GetTariffsResponse);
• several response types (such as DataTransferResponse, GetReportResponse, GetMonitoringReportResponse) seem to be missing the optional statusInfo field defined by the schema;
• there are also a few naming mismatches between the schema and the Go types (for example ClearDisplayRequest vs ClearDisplayMessageRequest, or SelectedChargingSchedule vs SelectedChargingScheduleId).

All of the above is based on the OCPP 2.1 JSON schemas, and I might have missed some context, so please feel free to correct me if that’s the case.

I’m very interested in this work and in helping bring ocpp-go closer to production readiness. If you’re open to it, I’d be happy to help by preparing fixes or aligning parts of this PR more closely with the specification — just let me know what contribution approach would work best for you.

Thanks!

[xBlaz3kx]

• ome types have RequestID field as optional but it is required by the schema (e.g. GetMonitoringReportRequest, GetReportRequest);

Hey,

thanks for pointing out these discrepancies! I'll take a look as soon as I can.
If you wish to contribute - you can create a PR and set this one as the target.

I'm also more actively working on my own fork of this repo - feel free to contribute there as well.