Add OCPP 2.0.1 and multi-protocol support #239
Conversation
Add a new sub-project named "ocpp-v2", intended to support all OCPP 2.x versions in addition to OCPP 1.6, which it has a dependency on. As a first step, add Java classes for all OCPP 2.0.1 messages and types as well as client and server event handler interfaces and function classes corresponding to the OCPP 2.0.1 "functional blocks."
Add support for auto-negotiation of the protocol version to use in the WebSocket handshake, to offer and accept both OCPP 1.6 and OCPP 2.0.1. To facilitate this, add multiple protocol capable variants of the JSONClient, JSONServer, SessionFactory, WebSocketListener and WebSocketTransmitter classes. Add new IMultiProtocolClientAPI and IMultiProtocolServerAPI interfaces which extend IClientAPI and IServerAPI, respectively, with the methods needed for multi-protocol support. Specifically, methods to add feature profiles (OCPP 1.6) and functions (OCPP 2.0.1 or later) for a specific protocol version. The IMultiProtocolClientAPI interface has an additional method to retrieve the protocol version selected by the server. The IMultiProtocolServerAPI interface has an additional method to retrieve the port number the server is listening on, which is useful for tests where the server is started with port number 0 to let it pick any available port. The MultiProtocolJSONClient and MultiProtocolJSONServer classes are implementations of these two APIs: - Both take a list of protocol versions to offer/accept as a constructor argument, instead of the OCPP 1.6 CoreProfile, which is now optional. - The client has the new getProtocolVersion() API to retrieve the protocol version selected by the server after connecting. - The server makes the selected protocol version available through the getProtocolVersion() API added to the SessionInformation object passed to the ServerEvents#newSession() API. Refactor the existing Client, Server and Session classes and interfaces to make the Session provide the feature repository to Client and Server, to allow selecting or configuring it to the protocol version selected in the WebSocket handshake. Adapt the tests to the removal of the feature repository from the constructor parameters. Add the protocol version to the feature repository interface and implementation. Add an exemplary unit test for serialization and deserialization of the OCPP 2.0.1 BootNotificationRequest message. More unit tests should be added. Add integration tests for the protocol version auto-negotiation between client and server.
Implement sending OCPP 2.0.1 RPC Framework Error Codes with corrected spelling instead of the incorrect "legacy" OCPP 1.6 ones if connected with a newer protocol version. Implement sending CALLERROR responses with the newly added error codes "MessageTypeNotSupported" and "RpcFrameworkError" if parsing fails at RPC message level. Note that these error codes will be sent even if connected with OCPP 1.6, where they were not specified. But this is deemed better than providing no response at all like before.
... and use it in the MultiProtocolJSONClient
Add a new JSONConfiguration parameter "CONNECT_NON_BLOCKING" of Boolean type, which, if true, causes the OCPP-J clients to make non-blocking connect() and disconnect() calls to the underlying WebSocket library. The completion of the connection or disconnection attempt will be communicated via the callbacks in the ClientEvents object passed to the OCPP library's connect() method. Note that a failed connection attempt (connection refused or timeout, if configured) yields a call to the connectionClosed() callback.
Bump the overall library version to 1.2, and all subproject versions and dependencies to 1.2.0.
|
great idea. Sounds more flexible than what we have in v2 branch. |
|
So what's happening with this PR? |
|
Hi, First of all thanks to @robert-s-ubi for this incredible piece of contribution. I really appreciate all the work and effort you have put into this library. Sorry for my silence. I started a code review some time ago, but due to summer vacation and work-related pressure, I haven't continued for a while. It is a huge body of work and many lines of code, which I'm checking for consistency with the specification by OCA. So far I haven't written many comments (and I'm guessing the once I have aren't public until I finish the review). I'm nearly halfway through the files, so I'm guessing it's going to be at least a month more before I'm done. I don't have a lot of spare time anymore. |
There was a problem hiding this comment.
First of all thanks for this great contribution. I really appreciate the effort that you have put into this.
I'm sorry the code review took so long, but the good news is that I have only few comment and I think the quality of the PR is high.
My main question now is, if the change to the server interface should be introduced to the main branch or to the v2.0 branch?
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/feature/function/ClientAuthorizationFunction.java
Show resolved
Hide resolved
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/feature/function/ClientAvailabilityFunction.java
Show resolved
Hide resolved
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/feature/function/ClientProvisioningFunction.java
Show resolved
Hide resolved
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/feature/function/ClientSmartChargingFunction.java
Show resolved
Hide resolved
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/model/messages/AuthorizeRequest.java
Show resolved
Hide resolved
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/model/messages/GetDisplayMessagesRequest.java
Show resolved
Hide resolved
...in/java/eu/chargetime/ocpp/v201/model/messages/PublishFirmwareStatusNotificationRequest.java
Outdated
Show resolved
Hide resolved
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/model/messages/SetMonitoringLevelRequest.java
Show resolved
Hide resolved
ocpp-v2/src/main/java/eu/chargetime/ocpp/v201/model/types/SetMonitoringData.java
Show resolved
Hide resolved
Add the missing array string length validation.
|
Okay, I have merged this PR into main. This is cause for a celebration! Thank you @robert-s-ubi for this incredible PR which has solved the multi version obstacle and paved the way to push forward from 1.6 to version 2.0.1. This was one of the main reasons why I created this library some 8 years ago, and you made the dream come true. Thank you for that. Sincerely, |
|
Hi Thomas, thank you for starting this project, allowing us and probably many many others to get started with OCPP! It is only fair if we give something back. And ideally, the way is now paved for OCPP beyond 2.0.1 as well... |
|
P.S.: The README.md could use an update now, it still says "Currently we support 1.6 SOAP or Web socket." - it should mention OCPP 2.0.1 and Multiprotocol support. The linked project plan is also a bit outdated now... |
|
Hi @robert-s-ubi, I am interested in knowing how to use the multiprotocol package that you have developed, however, I cannot find any documentation on how to use it. Could you give me a quick example of how to start? |
These commits add support for OCPP 2.0.1 in a most backwards-compatible manner:
Additionally, the OCPP-J clients are enhanced to optionally employ non-blocking connect() and disconnect() calls for applications which prefer asynchronous operation.
The MultiProtocolJSONClient disables the non-compliant transactionQueue. This should be correctly implemented by the application.
The overall library version is bumped to 1.2 and all sub-projects to version 1.2.0.